PRIORITY DOCUMENTS

[0001] The present application claims priority from U.S. Provisional Patent Application No. 63/126,397 titled “SYSTEMS AND METHODS FOR USER INTERFACE AUTOMATION AND API INTEGRATION” and filed on December 16, 2020.

FIELD

[0002] The present disclosure relates to systems and methods to provide an open platform or interactive space to build, deploy, modify and interrelate application programming interface (“API”)-driven objects and interfaces. The interactive space includes an intuitive and user friendly interface, lowers the cost of future modifications, and provides a centralized API enabling access to a variety of third-party platforms and other servers and core legacy systems. A unique user digital profile is used to validate a user’s identity to the various API providers.

BACKGROUND

[0003] Core systems can be very costly and time consuming to design, to build, to maintain, and to later change. These systems often must interface with many third-party servers, and custom- designed solutions tend to be costly to build and difficult or impossible to amend. Furthermore, it may be difficult or impossible to work with core legacy servers, which may not offer an API interface or other external data access and modification capabilities. In addition, individual identity verification may be required for each third-party service. Accordingly, an improved system and method for user interface automation and API integration, including user identity verification and validation, is desired.

SUMMARY

[0004] One aspect of the present disclosure describes an open platform on which customers may relatively easily and intuitively design, import, and build interactive, API-driven objects and interfaces. The open platform facilitates the customization, integration, and interrelation of a wide variety of appropriate APIs, enabling end users to control and design their own implementations with a simple drag-and-drop interface. Because of its powerful customization options, this open platform is industry-agnostic, and can be used in a wide variety of industries, offering nearly unlimited customization for end users based on their needs. The open platform is configured to work with a wide variety of third-party servers, to allow for the rapid integration of third-party data from multiple external services, including identity verification and validation. The open platform also offers the opportunity to work with core legacy servers which do not offer APIs using specialized legacy connectivity functions and devices.

[0005] Various implementations of systems, methods, and devices within the scope of the appended claims each have several aspects, no single one of which is solely responsible for the desirable attributes described herein. Without limiting the scope of the appended claims, some prominent features are described herein.

[0006] Details of one or more implementations of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims. Note that the relative dimensions of the following figures may not be drawn to scale. [0007] One aspect of the present disclosure provides a user interface which allows a user to design, maintain, and amend API-connected widgets and technologies an intuitive and easy-to-use drag-and-drop interface. The present disclosure also provides for a central API gateway server, which is configured to amalgamate the functions of multiple APIs into a single, convenient API for each end user. The central API gateway server may associate a given user ID with a unique API, while the API gateway server communicates with a plurality of third-party API servers, assigning the user with API keys for each of those servers. The central API gateway server may act as an identity validation engine for each user, when communicating with the plurality of third-party API servers. The central API gateway server may also be configured to connect to legacy systems, such as older mainframe computers and other devices, to provide a convenient API interface for devices that do not otherwise support such an interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 illustrates an exemplary embodiment of the architecture of the frontend of the platform according to one aspect of the present disclosure.

[0009] FIG. 2 illustrates an exemplary embodiment of the architecture of the backend of the platform according to one aspect of the present disclosure.

[0010] FIG. 3 illustrates an exemplary customer-driven build and integration on the platform according to one aspect of the present disclosure.

[0011] FIG. 4 illustrates an exemplary legacy connectivity appliance according to one aspect of the present disclosure.

DETAILED DESCRIPTION

[0012] Various aspects of the novel systems, apparatuses, and methods are described more fully hereinafter with reference to the accompanying drawings. The teachings disclosure can, however, be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Based on the teachings herein one skilled in the art should appreciate that the scope of the disclosure is intended to cover any aspect of the novel systems, apparatuses, and methods disclosed herein, whether implemented independently of or combined with any other aspect of the invention. For example, an apparatus can be implemented, or a method can be practiced using any number of the aspects set forth herein. In addition, the scope of the invention is intended to cover such an apparatus or method which is practiced using other structure, functionality, or structure and functionality in addition to or other than the various aspects of the invention set forth herein. Any aspect disclosed herein may be embodied by one or more elements of a claim.

[0013] Although aspects are described herein, many variations and permutations of these aspects fall within the scope of the disclosure. Although some benefits and advantages of the preferred aspects are mentioned, the scope of the disclosure is not intended to be limited to benefits, uses, or objectives. The detailed description and drawings are merely illustrative of the disclosure rather than limiting. In the following description, specific details are given to provide a thorough understanding of the examples. However, the examples may be practiced without these specific details.

[0014] It can often by a difficult and time-consuming task to design widgets, processes, and microservices for business purposes, such as those which may be used to generate reports, for private intranet sites, for public internet sites, and for other purposes. These processes often include custom-designed software, which is designed from the ground up by software engineers. It can take months and millions of dollars to build and rebuild these types of widgets, processes, and microservices. A given business will often have a variety of systems for a given space, which may not work well together. For example, a single supply chain may involve front-end ordering software, financial software, reservations, a wholesale inventory monitor, payment technology, accounting software, HR software, and sales CRM systems.

[0015] These various systems are unlikely to be designed to work with one another, so a businessperson may be forced to go into each system to manually extract the data they wish to use for a given process or report. Similarly, these various systems may have duplication between them, and duplicated data stores in multiple systems may require conciliation. This siloed approach is common and can lead to many difficulties, especially when systems need to be adjusted or rebuilt, or when systems that do not work together must be adjusted to work with one another. The process can be complicated by having to work with a wide variety of customers and third-party servers, including third-party servers which offer proprietary application programming interface (“API”) access and even legacy servers which do not offer an API. Furthermore, the results of such a design process can often be difficult to modify and/or expand later, leading to additional costs when changes are needed.

[0016] The present application is directed towards providing a robust open ecosystem or platform with an intuitive user interface which allows a user to design and modify widgets and apps without programming knowledge. The ecosystem also allows for integration with a wide variety of third-party data, such as that from various API servers, and also allows a user to re-design the financial software without need to perform additional programming and without having to re-write the software, which is typically required for legacy solutions. The ecosystem may be offered on a server and be available to multiple customers who are each able to build their own secure implementations based on their own needs. The ecosystem may leverage an intuitive user interface development framework to allow users to rapidly develop their banking and financial applications. The ecosystem may further be configured to both create and to use APIs, creating APIs for users to use and utilizing third-party APIs offered by external vendors, customers, and service providers. The ecosystem may be further configured to connect to legacy environments, such as those which do not offer API access. The ecosystem may be further configured to provide trusted user identity validation to the plurality of third-party APIs, related service providers and legacy systems. The ecosystem may allow business professionals to modify their own sites and integrations without the need to outsource to information technology (“IT”) or other technical professionals. The ecosystem can also allow users to maintain and extent their current branding, without having to dump and rebuild their site and software.

[0017] The ecosystem is industry agnostic and can be used in a wide variety of potential industries, thanks to its versatile, open nature. The ecosystem can find applications in, e.g., the insurance industry, wealth management, industrial and manufacturing sectors, natural resource sectors such as energy, oil and gas, in commercial real estate (asset management, construction, leasing, property management, building system automation), in banking, tourism, consumer goods, eCommerce and retail, professional services, information and communications technology, life sciences, textiles and apparel, infrastructure (construction and management), clean tech, in agriculture, aerospace, automobile manufacturing, and in the arts & culinary industries. In each of these sectors, the ecosystem is versatile and can be used to interconnect various systems and processes within a given company or across companies. The ecosystem can be used to build reports and can provide insight by allowing the connection of previously disparate data points.

[0018] For example, the ecosystem may allow a user to select a variety of third-party servers, so that the data from those servers may be used in a widget, app, or other application that is created using the robust creation ecosystem. Each third-party server may operate their own servers and may offer methods to interact with those servers, such as providing an API, and each of those APIs may offer a different variety of data fields. This selection may take the form of a list of third-party servers, for example. The user may further select data fields from one or more third-party servers which will be used in a particular implementation. These data fields may be selected for each third-party server, or alternatively, data fields may be selected for the implementation itself, and the platform or ecosystem may be configured to determine which of those data fields are relevant to each third-party server. In the foregoing, these third party service provided are referred to as Anytech providers. In the foregoing, third party service providers related to financial services are referred to as Fintech providers.

[0019] The platform may be configured to implement these user selections without requiring that a user manually set up to access various third-party servers. For example, the platform may be configured to include means to automatically authenticate the user, to request API keys from the selected third-party servers, to assign those API keys to the user. In one aspect, the platform may operate as an API gateway server and may be configured to request API keys, assign those API keys to a user, and to load the API keys into the gateway. The API gateway may be further configured to offer a variety of API functions to a user’s program, operating as an intermediary between the various third-party servers and the user’s implementation built on using the user-friendly ecosystem. Thus, the platform may be configured to connect and mediate services from customers to a plurality of third-party servers. The API gateway may aggregate data from multiple APIs from various sources and combine this into a single consumable API, allowing for much easier and more robust application development.

[0020] One aspect of the present disclosure includes a user interface (“UI”) extender including an ingestion engine as part of the platform. The UI extender offers a rapid development environment for users without requiring any coding from those users. The UI extender may be configured to import, ingest or receive an existing customer site, widget, app, or other inputs, processing the data in that site, rebuilding the site, and enabling that site to be viewed and modified in an easy-to-use UI. In embodiments, the ingestion engine processes code from an existing site to identify functionality and connections, disconnects all objects that the site was connected to, wraps the identified functionality to standardize operation on the platform server, and reconnects all connections through the standardized interface so that the ingested site is available to users on the platform server, Various types of input data may be imported, ingested or received by the UI extender by means of the ingestion engine, including an external website, an internal intranet site, an app, an internal widget forming a portion of an intranet or internet offering, or other input data. In embodiments, the ingestion engine is configured to ingest a wide variety of other input data. In embodiments, the platform provides an import function which ingest at least a portion of an import site. For ease of reference, we will refer to a “site” here, but other input data can also be accepted and ingested and imported into the robust ecosystem. For example, the platform may offer an import function which can ingest an existing site, importing the site into the platform. The site may be ingested whole or in part, such as a given web page, a given portion of a web page, or a given subsection of an entire website, based on the needs of a particular project. As above, the platform can be configured to selectively connect and mediate services from customers to a plurality of ingested sites.

[0021] After a site has been imported or developed on the platform, the site may be modified and extended using the UI of the platform itself. The UI extender may be configured to create re-usable business objects, each with unique versions for each customer of the platform. For example, this may allow a given user to re-use their objects such as data elements and connections to databases and other structures across multiple deployments. The UI extender may provide a user with easy ways to modify and present these structures, such as through a drag and drop user interface with data field selection via drop-down menus.

[0022] The platform ecosystem may be used to provide a convenient intermediary between the consumer and the supplier, such as third-party APIs, which allows a user to create and modify their deployments with no coding knowledge and without needing to create new connections to APIs and other back-end systems. The UI extender may be configured to work on a wide variety of platforms, such as on PC, Macs, tablets, and mobile devices. The UI extender may be used for projects on intranets or on the internet for public-facing web services. The UI extender may also have application versioning control.

[0023] One aspect of the present disclosure provides for an API Gateway appliance which is used by the platform to connect to a wide variety of systems using one comprehensive interface. The platform may be further configured to register an API or a legacy environment with the API gateway, once an API is made available to the ecosystem. The appliance connects to third-party servers through API interfaces, including requesting API keys for a given user and assigning and storing those API keys for that user. The API gateway only allows authorized users or tenants to access the services requested from the webpage or workflow tool. The appliance is further configured to itself provide an API to the platform and users of the platform. This allows applications built using the platform to use only a single API, rather than requiring that each application interface with the APIs of every provider that is used on the platform, allowing for streamlined development. The use of the API Gateway may also help protect customer data, by playing a role in customer data marshalling, storage, and protection.

[0024] The ecosystem may be further configured to provide trusted user identity validation to the plurality of third-party APIs, related service providers and legacy systems by means of a unique digital user ID. Data and information associated with a user including but not limited to username, password, date of birth and social insurance number, biometric information, and associated documents including but not limited to, for example, passport and driver’s license, is used to construct a unique user profile or digital identification (ID). Once this information is validated and a user has been verified, the ecosystem validates the identity of an individual associated with the unique digital user ID for each of the plurality of third-party services via the associated APIs or legacy systems, without the user having to re-submit documents and information. In this manner, the ecosystem verify the identity of an individual associated with a digital user ID with third party service providers, thereby acting as a certification manager.

[0025] FIG. 1 illustrates an exemplary embodiment of the architecture of the frontend of the platform according to one aspect of the present disclosure. As illustrated, multiple customers can use the internet to connect to the ecosystem platform servers. The platform servers offer features like entitlements, webpage creation, workflow tool, subscription to select third party vendors. Access to the services provided by the platform servers is grouped by tenants. Tenants are each configured to define the subset of services available to each of the customers or subtenants, from the set of all services provided by the platform servers. Tenants may have subtenants, each of which is configured to define the subset of services available for each of their respective users or customers. In turn, each user or customer has information associated with them, such as but not limited to, roles and tenant information, that is used to determine access to the services and information on the platform servers. In embodiments, the user- associated information is the unique digital user ID. [0026] The platform servers stores data using the tenant information as an identifier. Information for each tenant such as the number of users, the number of subtenants, the number and identification of the Anytech providers available for each tenant is readily obtained based on these identifiers. In addition, determinations with respect to billing cycles, number and types of subscriptions for each of the plurality of Anytech providers, user roles and user entitlements are also obtained based on the tenant identifier.

[0027] As illustrated in FIG. 1 the platform servers 100 include an application router (app routing) 110, which configures Pages 120 and Components 130 to be rendered to a user 10 and Actions 140 to be performed by the components, based on previously established workflows or processes. A database 150 is also associated with the ecosystem platform servers 100. In addition to tenant and user configuration data, this database also stores templates and configuration information for each of the plurality of Anytechs.

[0028] Based on a user’s configuration, the app routing determines which pages are displayed to the user and which external services are available to be accessed by the user. Determining a user’s configuration may also include determining the configuration of the tenant. Pages 120 and Components 130 access the platform service database for user and/or tenant authentication, to store or retrieve data, and render the appropriate Pages accordingly. When a user interacts with a Page 120, user selections are operable to direct Components 130 to carry out Actions 140. Actions include but are not limited to requesting information from an external service, receiving information from an external service, accessing information from the platform service database, storing information in the platform service database, receiving information from a component, and sending information to a component.

[0029] The platform servers also include workflow tool services (Process Orchestration/Workflow) 150, webpage services (Webpages) 160, and external or third party service selection services (Anytech Selection) 170 as further illustrated in FIG. 1. A user uses these services to carry out standard process orchestration tasks using drag and drop operations. The Anytech Selection allows a user to select a plurality of external services from which data will be requested or sent to. The Process Orchestration 150 service allows a user to define modular instructions to be carried out with respect to both the selected external services and internally within the ecosystem. The Processes Orchestration 150 connects to data sources selected or subscribed to by the tenant. Entitlements are rules on who can create, edit or delete the workflows in the platform. The Webpage 160 services allow a user to create an interface for inputting and displaying information as necessary. In the platform server, users select the third-party vendors and the platform server prepares all the connections in the background to make the data available in the platform server by means to be ready for drag and drop operations carried out by the user. A user selects which of all data fields they want to use on the webpage through a drag and drop interface, using icons, figures, shapes and connectors to represent sources and sinks of information, operations, and relationships between them. Users configure Actions to be carried out by the Components 130. Actions also access and validate information retrieved from the server database. Users also use the Process Orchestration 150 tool to modify existing Pages 120, Components 130, and Actions 140, in order to provide flexibility. In embodiments, Pages 120 are grouped or listed together, and this subset of Pages 120 becomes an application.

[0030] When an Action is carried out that requires a connection to an Anytech provider, a user must enter the appropriate verification or authentication information, which is relayed by the platform servers. The authentication information is stored by the system to make future requests for the data.

[0031] The data available from each of the plurality of Anytech services providers are represented to the user creating a Page or a Webpage as a plurality of data points. Only data available from the subset of the plurality of Anytech providers available for the tenant is displayed. In embodiments, the data points are rendered on screen as selectable options which depending on the use case can be selected to display on the webpage. In embodiments, a user manipulates the data points using drag-and-drop operations in order to create, modify or delete relationships between the datapoints and the Webpages or Pages, and consequently, the how the data from the plurality of Anytech providers is used.

[0032] For example, a user may use the Process Orchestration tool to create a process. The Workflow tool includes draggable components like start, end or stop, decision, step and a page. The user selects, for example three Anytech providers, such as an email service, a scheduling or calendarization service, and a user profile service. Using the Process Orchestration tool, the user creates a Page that retrieves and provides data to and from these services to, for example, review and identify emails of interest and extract information from this service, schedule a meeting with a subset of the extracted information on the calendar service, and create a user profile with a second subset of the extracted information on the user profile service.

[0033] For example, a user may use the Process Orchestration tool to create a human resource uptake process. The user selects, for example three Anytech providers, such as a user profile service, a third party service provider and a third party legacy system service provider. The user creates a Page to collect information on an employee. When accessed, a user inputs information into the Page, and the relevant information is directed by the system to each one of the user profile service, the third party service provider and the third party legacy system service provider. In this manner, a user only provides the information once, and the platform server ecosystem directs the relevant information to each service, as described below in more detail.

[0034] For example, the user may use the Process Orchestration tool to trigger a supply chain process. The user can select five Anytech providers, such as an order taking service, an inventory manager, a dispatch tool or call center trigger, a delivery mechanism including an armored car service, an accounting system. Using the Process Orchestration tool, the user creates a portal page with an authenticated permissioned user with the authorizations in place to trigger data to be sent and retrieved from all of these services, for example, input the order which automatically triggers and changes inventory, send order to dispatch, and the process continues to push information through the stages and retrieves state of order for invoicing and payments.

[0035] The system as described herein provides flexibility for a user to select the information that they need. The platform server connects with API Gateway to access the data from different vendors/Fintechs/Anytechs from the platform server or Root API layer. The platform server inbuilt database is used to store the content like pages. The platform allows a user to select data which is needed for an implementation from a plurality of third-party servers and other data sources. If any customer wants their application to be output as an android app this is done through the platform.

[0036] FIG. 2 illustrates an exemplary embodiment of the architecture of the backend 200 of the platform according to one aspect of the present disclosure. This specific embodiment refers to applications in the financial or wealth space, but the ecosystem can be used in a wide variety of different industries and applications thanks to its versatility. These applications are configured to work with a wide variety of external servers 250. For example, given customers may operate their own legacy systems 240 such as mainframes, AS/400 systems, and other legacy systems. The applications may also be configured to interact with various modem financial technology servers which may offer API access to those servers. An API gateway may be used to communicate with these various servers. All requests from the Frontend as describe above in relation to FIG. 1 are forwarded with API Gateway to platform server API Layer. A configuration service (Config Service) 210 is responsible for configuration of tenant integrations with Anytechs/Fintechs. The Config service creates Worker service instance 220 per each tenant. Worker service is responsible for data retrieval from Fintechs/Anytechs. Worker services may share Worker Database 230 instance or have separate ones.

[0037] Communications with customer legacy devices may be managed by a legacy connectivity appliance 240 which may be uniquely configured for these legacy devices 260 which may not otherwise offer any type of API or other access capabilities. The platform or ecosystem itself may also offer other services, such as storing data for clients to allow that data to be easily accessed and used for reporting and insight functions. In embodiments, if a client or tenant want their data to be stored for reporting dashboards this service is also be provided. The platform can also offer transaction services, allowing direct service offerings to customers and able to quickly adapt to changes in privacy laws and other laws related to holding customer and other data, including both domestic and international legal regimes. In some respects, the functions of the platform server, the API gateway, and the connectivity appliances may be spread across multiple devices as illustrated or could, in some instances, be combined onto fewer different devices. The API gateway itself may therefore be configured to connect to a wide variety of different services using a wide variety of protocols. The API gateway is configured to generate a unique, secure API for each customer deployment which allows customer applications to only require the use of a single API, which renders updating the customer application and/or configuring the external APIs significantly more efficient. [0038] In further cases, providing access to one of the plurality of Anytech legacy services that do not have any API’s by means of an On Cloud Edge Appliance. An Appliance allows the system to connect to banking host systems which include AS 400, mainframes or other legacy systems. A platform Worker Application then interacts with the On Cloud Edge Appliance to provide the relevant services to the platform users.

[0039] FIG. 3 illustrates an exemplary customer-driven build and integration on the platform according to one aspect of the present disclosure. Each customer may be able to custombuild a deployment on the platform server. As with the previous example, this exemplary embodiment relates to applications in the financial and wealth space, but the underlying technologies are versatile enough to be used in a wide variety of applications and are industry agnostic. For example, each customer may be able to select from a variety of third-party data providers, such as Fintech companies, for the implementation, widget, or app to interact with. For each of those providers, a customer may be presented with a list of data available from the given provider and may select which data is used from each provider. The customer may be able to quickly and efficiently design an interface and outputs for their deployment based on this available data in an easy-to-use environment, such as a drag-and-drop interface, and avoid programming.

[0040] After the customer selects providers and selects data from each of those providers, this information may be communicated to an API gateway server. The API gateway server may be configured to work with a variety of third-party servers through their APIs and other interfaces. The API gateway server may be further configured to request API keys from each of the third-party servers for a given customer and to assign those API keys to that customer. The API gateway server may generate its own custom API for each customer and may publish those APIs to allow customers to use them. Each customer deployment may communicate with the API gateway server using their assigned custom API. The use of this custom API allows a customer deployment to communicate solely with the API gateway server, rather than needing to communicate directly with each of the individual third-party servers. Similarly, in embodiments, the API gateway server is configured to communicate with each of the various servers, allowing it to be more agile when those outside sources make changes to their APIs without requiring that customers individually change their deployments and their software.

[0041] FIG. 4 illustrates an exemplary legacy connectivity appliance according to one aspect of the present disclosure. The legacy connectivity appliance works with the API gateway server to provide legacy connectivity to back end systems 240, such as backend databases, mainframe systems, AS/400 systems, MQ systems, Tandem® system, and other devices which do not natively have an API interface. For example, the legacy connectivity appliance may be configured to connect via a wide variety of protocols including IP connections and through a usemame/password to these older systems to send and receive data from the legacy system. The legacy connectivity appliance, in conjunction with the API Gateway, may be used to provide an API support for legacy customer systems, allowing for much easier integration of those systems into the easy-to-use development environment offered by the platform. The legacy connectivity appliance may be implemented on the API gateway server, may be colocated at a customer location, or may be deployed on the cloud. The legacy connectivity appliance may be accessible over the internet or over a private connection and may offer the API gateway server access to material which is not otherwise accessible using convention APIs. The legacy connectivity appliance is used to extend the functions of the deployed applications built on the platform, potentially offering additional services that would not otherwise be possible with legacy systems. The legacy connectivity appliance may be secured to maintain the security of the data contained on the legacy devices. For example, private keys may be used to encrypt data sent by, received by, and potentially stored on the legacy connectivity appliance.

[0042] Implementations disclosed herein provide systems and methods for building banking and financial software in an easier and more extendible manner, including offering an API gateway for legacy and other devices. The present invention may be applied to other server and API environments, including, for instance, in the medical and consumer platform areas. The phrase “based on” does not mean “based only on,” unless expressly specified otherwise. In other words, the phrase “based on” describes both “based only on” and “based at least on.” In the foregoing description, specific details are given to provide a thorough understanding of the examples. However, it will be understood by one of ordinary skill in the art that the examples may be practiced without these specific details. For example, the shape and size of various components may be changed for a given implementation or to match design preferences. Certain components may be combined with one another or may be excluded from some implementations. In other instances, such components, other structures, and techniques may be shown in detail to further explain the examples.

[0043] Headings are included herein for reference and to aid in locating various sections. These headings are not intended to limit the scope of the concepts described with respect thereto. Such concepts may have applicability throughout the entire specification.

[0044] The previous description of the disclosed implementations is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these implementations will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other implementations without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the implementations shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.