Patent Application
20240004740
A portion of the disclosure of this patent document contains material, which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
The disclosed technology relates generally to software operations and more specifically to integrating applications operating in different processing platforms.
Computing platforms have long been well defined. The local processor runs the operating system (OS), wherein applications run thereon. OS-level modules allow for communication between these applications. For example, a clipboard allows cutting and pasting of text between applications.
While there have been improvements in desktop OS software and network connectivity, there are restrictions for executing applications operating within an OS based platform. For example, a common application for accessing network resources is a browser application. Brower applications read hypertext mark-up language (HTML) data files and enable executables for interacting with the HTML, for example Javascript. The combination of HTML text file(s) and executable code is referred herein as HTML solutions.
Current HTML solutions offer a limited view of interoperability. Browsers executing the HTML solutions engage between the local OS, such as through application program interfaces (APIs), and network microservices through transfer protocols. Current HTML solutions, extending through version four of HTML standards, referred to as HTML4, lack the ability for multiple browser applications to interact or interoperate without a network server. Browser applications and HTML solutions must maintain a secure sandbox.
The current trend in computing resources is the integration of HTML solutions into the space of desktop applications, operating on the local OS. Current HTML capabilities and architecture revolve around independently operating windows, each running in their own secure sandbox.
The new HTML standard, referred to as HTML5, has opened the ability for browser applications to interact and cross-communication directly. It is not realistic in the modern computing environment to rely on one or more servers for coordinating multiple browser windows. In addition to latency issues, you have to tie up a portion of server operations. There are security concerns as well as interoperability concerns between HTML solutions from different developers.
HTML5 enabled browser containers. A browser container includes at least a part of browser executable, enabling reading mark-up language and related executables, as well as operating system hooks. Browser containers allow for multiple applications to be run in separate browser windows.
In prior systems, a key reason for limiting browser interoperability is because security restrictions within a browser environment. Using browser containers allows for relaxing security restrictions, but current solutions do not facilitate interoperability of mark-up language applications executable within a browser container.
For example, current HTML5 applications can include pre-loaded scripts or have these scripts actively loaded therein. The scripts enable API communication between the application running in the browser and the browser container. Solutions are being proposed under the Financial Desktop Connectivity and Collaboration Consortium (FDC3) and the development of FDC3 standards
As HTML solutions migrate into the space of desktop applications, there is a need for enabling multiple mark-up language applications to execute in separate browser windows, as well as communicate with each other above the OS level. Furthermore, as the emerging HTML solutions include stand-alone browser windows, there is a need for improving the management of these multiple windows, both at the operation level and in conformance with FDC3 standards.
The method and system provides for interoperability between mark-up language applications executing in browser containers. The method and system includes executing a first application in an application layer executing within a microservices layer, the first application is a browser-based executable application and executing a second application in the application layer, the second application is a browser-based executable application. The method and system further includes executing a microservices module within a browser container, the microservices module facilitating communication between the first application and the second application via the browser container. The method and system includes executing a first overlay application within the first application, the first overlay application transmitting via the microservices module. Therein, based on an interaction in the first application, the method and system includes transmitting, from the first overlay application to the microservices module, a first command transmission having a raised intent data call and a raised intent data field therein. The method and system includes executing a response operation in the second application based at least on the raised intent data call and the raised intent data field within the first command transmission.
A better understanding of the disclosed technology will be obtained from the following detailed description of the preferred embodiments taken in conjunction with the drawings and the attached claims.
Embodiments of the disclosed technology providing for a method and system integrating multiple applications across a processing platform. Operating within a browser platform allows for integration of multiple mark-up language applications.
The user 102 may be any suitable user accessing a computing device 104. The device 104 may be any suitable processing device operative to execute the applications thereon. For example, the device 104 may be a mobile computer, a laptop, a desktop computer, a tablet computer, a smart phone, or any other device providing for network connection and executing a browser application within a browser container.
The network 106 may be any type of network operative to interconnect the computing device 104 to the server, such as but not limited to the Internet, a virtual private network, an intranet, etc. It is recognized that omitted from
The server 108 may be any suitable type of network-accessible server engaged by the computing device 104 using a browser application running thereon. Each application 110, 112, and 114 is illustrated as being disposed on the server 108. The applications 110-114 are executable instructions executed by the browser application on the computing device 104 or executed by the server 108. The applications 110-114 are illustrated with storage devices 116-120 having the executable stored therein. It is recognized that additional libraries and related data may be stored in the storage device 116-120 allowing for execution as described herein. For example, if the application 110 is written in an executable JavaScript code, the storage device 116 may include library information usable with the executable.
It is recognized that in one embodiment, the server 108 may be disposed within the processing device 104, accessible as an internal application. For example, if the user 102 engages the browser on the processing device 104 to retrieve a local mark-up language file, the computing device therein acts as the server 108, such that the present method and system is not expressly limited to or requires network connectivity.
The method and system integrates multiple applications, which can be locally stored and/or network-stored. For example, one embodiment may include a combination of local and network storage, where applications are network-stored, downloaded by the browser and then locally-executed. Whereas, another embodiment may include network-based execution of the applications with the browser enabling the interfacing functionality via the local processing device.
It is further recognized that the server 108 may be any number of servers 108 and is not expressly limited to a single server 108. Rather, it is recognized that via the network 106, the applications 110-114 may be across a distributed processing environment.
The operating system level 146 includes input/output interface executable 148. By way of example, the native operating system may be a Linux® operating platform, Apple® OS, Microsoft Windows®. The i/o interface 148 enables typical user interaction in accordance with known techniques.
The browser container 150 executes on the operating system layer 146. The browser container includes at least a portion of browser executable, such as for example Google Chrome®, Mozilla Firefox®, Apple Safari®, Microsoft Internet Explorer®, etc. As used herein, at least a portion of the browser executable is any application or applications executed on the native operating system platform 146 that reads hypertext mark-up language files and enables related executables. The container further includes operating system hooks.
On top of the browser layer 144 is the microservices layer 142. Within the microservices layer 142 is the microservices module 152. In one embodiment, the microservices module 152 executes in a computer language compatible or executable with the browser container 150. For example, in one embodiment the microservices module 152 is written in a JavaScript language. The microservices module 152 executes on top of the browser layer 144 and includes exchange scripts for transmission to executables on the application layer 140.
The microservices module 152 includes a plurality of processing modules facilitating communication between applications (e.g. applications 154, 156, and 158). The microservices module 152 is not exclusively connectivity, but also an electronic brain between the applications. Via numerous microservices modules, including but not limited to embodiments expressly disclosed herein, microservices modules use interoperability functions to transform communications between applications, including for example conditional transformations based on system-defined or user-defined definitions, where conditional transformations allows a single action in a first application to means different results or operations in other applications. Intelligence within the microservices modules orchestrated interoperability between applications.
Applications 154, 156, and 158 execute on the application layer 140. In one embodiment, these applications receive exchange scripts from the microservices module 142. In another embodiment, these exchange scripts are preloaded. As described in further detail below, the inclusion of the exchange scripts facilitates communications between applications 154-158 across the microservices layer 142. This cross-application communication occurs above the operating system layer 146.
As used herein, the browser container 150 operating on the browser layer 144 refers to back-end processing. From a front-end perspective, the viewable output to users provides for individual browser windows. Each browser window is a separate application, such as applications 154-158. In back-end processing, this does not translate to separate browser containers 150. Therefore, as used herein a browser window in the front end illustrates a separate application, a stand-alone instantiation of an application running on the browser layer 144.
The processing system used herein operates within the browser container, which provides functionality to the desktop while at the same time insulating that functionality from any operating system specifics. The applications are independent of the operating system and can transparently run on the browser containers across any number of operating systems.
In the screenshot 180, the user engages the first application 182 for performing an operation or otherwise interacting. By way of example, the first application 182 may be a stockwatcher application that allows for entering a stock symbol and seeing one or more stock charts. Dashed arrows in the screenshot represent non-visible interaction between applications enabled by the microservices module 152 of
In the example of the stock watcher application 182, the user may enter a stock symbol into a search bar, retrieving the current daily stock price chart. Staying within the microservices layer (144 of
Continuing with this example, application three 186 may be a newsfeed. Thus, upon search results in the first application 182, the third application 186 updates a news feed with current news articles relating to the selected company.
Multiple degrees of interactivity are within the present invention. Thus, in addition to applications two and three (184, 186) being in communication with application one 182, the fourth application 188 can be in communication with the second application 184. Using the above example of the first application 182 being a stock price engine and the second application 184 being a buy/sell application, the fourth application 188 can be an accounting application showing the available funds for the user for any buying transaction or share listings for any selling transactions.
Therefore, by inclusion of a microservices module with exchange scripts into the applications 182-188, and the applications being in hypertext mark-up language operating on the browser layer, the present method and system enables interoperability between these multiple applications. The integration of stand-alone applications in independent executable browser windows opens for cross-application data sharing not previously available because of the secure sandbox concerns associated with browser executables.
While
In one embodiment, the applications 182-188 and the microservices module 190 can collectively form a single general application. For example, using the example of
Where each application 182, 184, 186 and/or 188 can be stand-alone executable applications, the microservices module 190 allows for collective integration. For example, the applications may be all written by different companies. The inclusion of the microservices module enables otherwise independent applications to become interoperable above the operating system platform, significantly improving productivity. Moreover, the microservices module allows for easy access and integration of proprietary and/or legacy applications with additional third-party software.
The APIs 202 enable the communication of the window component 200 with the microservices module 190 and subsequent interactivity by using defining interactive characteristics and executable instructions.
In accordance with known program techniques, the APIs 202 are available and loadable as part of a library in conjunction with the HTML text file. The launching of APIs 202 provide for executable functionality allowing for inter-application communication through the microservices module 190.
As recognized by one skilled in the art, numerous APIs provide for varying degrees of functionality and interoperability with other applications running in the browser container. By way of example, a Router API contains programming language sending and receiving events between applications. In the Router API, event router callbacks for incoming messages are in the form callback(error, event). If error is null, then the incoming data is always in event.data. If error is set, it contains a diagnostic object and message. On error, the event parameter is not undefined.
In another example, a Linker API provides a mechanism for synchronizing components on a piece of data. For instance, a user might link multiple components by “stock symbol”. Using the Linker API, a developer could enable their component to participate in this synchronization. The developer would use LinkerClient #subscribe to receive synchronization events and they would use LinkerClient #publish to send them.
In another example, in order for components to be linked, they must understand the data format that will be passed between them (the “context”), and agree on a label to identifies that format (the “dataType”). For instance, components might choose to publish and subscribe to a dataType called “symbol”. They would then also need to agree that a “symbol” looks like, for instance, {symbol: “IBM”}. The Linker API doesn't proscribe any specific format for context or set of labels (some would call this a “taxonomy”). In the case that components used different taxonomies, prior art platforms would fail to deliver interoperability, but the present invention could intermediate the intended action, utilize a microservice to translate from one taxonomy to another, and then deliver the message to the second application. Thereby, multiple applications, each understanding its own taxonomy, can effectively be integrated.
End users create linkages by assigning components to “channels”. One embodiment represents channels by color. When a component is assigned to channel “purple”, publish and subscribe messages are only received by other components assigned to that channel. The Linker API exposes functionality to manage channels programmatically, including building a Linker Component using a different paradigm, or apply intelligently link components based on business logic.
In one embodiment, the processing core 222 is packaged as a NPM module to simplify updates. The most common scenario for processing users (i.e., developers) is to build new components on top of the core module 222. Developers can connect independent components, existing prebuilt components, and third-party components to the processing core to form a single application.
In further embodiments, the processing core further supports adding new microservices and corresponding client APIs as developed and integrated.
The processing Library is a set of client APIs connecting to one or more microservices. For example, a Launcher Client connects to the Launcher microservices. Likewise, a Router Client connects to the Router microservices. The Router microservices (via the Router Client) acts as an inter-window event hub, providing communication between all components and microservices.
As illustrated in
The processing architecture of
A special class of components, called presentation components, are provided as samples to provide common UI functionality to end users. An example is the toolbar component that end users can use to launch or control other components.
Similar to components, microservices can be pluggable, delivering centralized functionality. In the processing environment, microservices are less likely to change (or be interchanged) than components since they provide a basic building block functionality. Nevertheless, developers can create their own microservices with corresponding client APIs, essentially extending the processing library.
In one embodiment, connector microservices communicate externally to public or private servers (e.g., data feeds, databases, or cloud-based microservices).
In one embodiment, each individual component and microservices are independently threaded in its own Chromium window that sits on top of a secure operating layer.
As used herein, a client API is a JavaScript API that interfaces with one or more microservices using router messages. Some client APIs are defined for specific microservices, like the Launcher Client API is specifically for the Launcher microservices. Other client APIs may provide composite functionality out of one or more existing microservices, like the Dialog Manager Client API which builds on the Launcher Client. Depending on the microservices, some parts of the API functionality may be implemented on the client side with the centralized functionality residing on the microservices side.
As used herein, a processing component is a piece of functionality built with mark-up language and executables, such as HTML5/JavaScript, that lives in a processing window. A processing component is the basic building block of the collective application. A component may have multiple active instances within the collective application, each running in its own window (e.g., multiple chart windows, multiple chat windows).
The processing framework is a cooperating set of software components and microservices used to build HTML5 desktop applications on top of the operating layer. For example, a processing framework may enable one or more collective applications to be integrated as described herein, such as via the microservices and event messages.
A library is a set of client APIs that have been packaged together for easy component access. A router is a microservice that is the center point for all processing framework communication. The router sends and receives messages between windows, enabling communication between all components and microservices through multiple types of messaging: such as Listen/Transmit, Query/Response, and Publish/Subscribe.
A window is a browser container, sitting on top of an operating layer. A microservice is an active, independently-threaded JavaScript module providing centralized functionality throughout a processing application. Microservices provide capabilities to processing components as well as other microservices. Exemplary microservices include the router microservice, launcher microservice, linker microservice, chat microservice, etc. Microservices typically don't have a UI; instead, they can be interacted with using a corresponding client API. Communication to and from microservices is through the router (itself a microservice).
Within the above architecture,
While not expressly noted in
Step 242 is accessing a first exchange script in the first application and a second exchange script in the second application. The exchange scripts, in one embodiment, are executable instructions executed by the browser application, for example a JavaScript code inserted into or compatible with existing JavaScript libraries. The exchange scripts provide functionality for detection or recognition of a particular activity within the application, as well as communication of this detection.
Step 244 is executing a microservices module, which is in communication with the first application and the second application. By way of example,
Step 246 is, via the first exchange script, communicating between the first application and the microservices module. Step 248 is, via the second exchange script, communicating between the second application and the microservices module. Therefore, via steps 246, 248, the microservices module acts as a central location for communications with applications.
Step 250 is determining an interaction in the first application via the microservices module. By way of example, an interaction in the first application may be a user entering a text, selecting an icon, selecting a hyperlink, etc.
Step 252 is generating an action command for the second application via the microservices module. For example, if the first application is a stock chart application, a user may enter a ticker symbol in a search bar to retrieve the stock chart. Where the first application generates the stock chart, the microservice module determines the interaction of the stock selection. The action command may be based on the application and the type of generated actions. In the example of a stock selection, the action command may be a notification of a stock ticker symbol. Moreover, the action command may trigger general functionality located in the application's preloaded scripts, i.e. the microservices layer 142 if
Step 254 is performing a processing operation in the second application based on the action command. This step may be performed by the second exchange script. In the example of a stock ticker and the second application is a news feed, action command may include translating the stock ticker to the company name and retrieving recent news stories about the company. The processing operation in the second application may then include displaying recent new articles or headlines relating to the company associated with the stock ticker.
It is further noted, the performing of the processing operation by the second application does not require a visual front-end display. For example, the processing operation can be to simply track or log the information from the action command, but a change in output display is not expressly required.
The steps of
In one embodiment, the integration between applications may additionally include data fields as part of the interaction in the first application. Where the above example is a stock ticker symbol, data fields may include additional information directly usable by the second application beyond a general notification of action within the first application. For example, a first application may be a financial accounting application that includes a secure login. Login credentials for the first application may be usable for the second application, which can include processing a first data field within the interaction in the first application to generate a second data field for the action command. For example, if the data field is a secure login, the data field may be processed for being usable to generate additional an additional login or identity verification for the second application.
It is further noted, the present embodiments above describe multiple applications, where the number of applications is not expressly limited. For example, a user may have any number of applications in co-execution by the browser container with interoperability across the microservices module.
The present method and system improves interoperability using features available in HTML5. The present description is not expressly restricted to HTML5 but is applicable to all future mark-up language programming language standards having corresponding functionality as found within HTML5.
Moreover, one embodiment provides for applications in the financial services industry, such as the Finsemble™ software. HTML5 is rapidly being adopted by the financial industry because it is both light-weight and is the only cross-platform language supported by all major technology vendors including Google®, Microsoft® and Apple®. However, modern web browsers which are typically used to run HTML5, do not provide the capabilities needed by real-time trading applications. In one embodiment, based on Google Chromium®, containers provide a controlled, high-performance HTML5 engine purpose-built for desktops at banks and buy-side firms.
Within the processing system described herein, the method and system allows for further functionality through integrating non-browser applications with applications executing on a browser container. Non-browser applications are applications that do not within a browser container, and in some embodiments can run on an operating system level. By way of example, a non-browser application may be any suitable application running on a Windows, MacOS, or Linux platform, but are not HTML encoded running within a browser.
Therefore, to include the non-browser application functionality,
The system 300 includes a browser container 306 running on the operating system 304. The browser container 306 includes at least a portion of a browser executable and OS hooks. The browser container 306 includes a microservices layer 308 having a microservices bridge module 310 therein. A first application 312 and a second application 314 run on the browser container 306. The first application 312 and second application 314 may be any suitable applications similar to the elements described in
It is further noted, the OS 304 may be the same OS for both the non-browser application 302 and the browser container 306. Or, in another embodiment the OS 304 may be different between the non-browser application 302 and the browser container 306. For example, the non-browser application 302 may be disposed in a networked environment, running on a server with the browser container 306 being locally executed. In another embodiment, non-browser application 302 and browser 306 could all be executed locally.
Processing steps for assimilating the non-browser application 302 with the browser container 306 are described with respect to
The microservices bridge module 310 operates on the microservices module 308 by including one or more application program interfaces (APIs). The APIs provide translation between the operating system 304 for the non-browser application 302 and the browser 306 and to the microservices 308 built thereon. Moreover, the microservices bridge module 310 communicates with the operating system bridge 316 running on the operating system using known communication protocols common to both the operating system and the browser container, such as sockets by way of example.
Application 312 is HTML encoded, such as HTML5. Inclusion of appropriate scripts, including JavaScript calls, enables the microservices bridge module 310 for referencing APIs. Through these APIs, data calls are translated, allowing for execution of the non-browser application 302 within its appropriate OS 304, but output generation translatable to applications 312, 314 operating within the browser container 306.
The bridge module 310 provides for a shell module or other wrap around a display window of the non-browser application 302. Through inclusion of the shell module or wrap, the non-browser application 302 can share additional display functionalities, including grouping of windows.
The method includes a first step, step 360, of executing a microservices module disposed between the first application and the browser container. Step 362 is executing a bridge disposed between the non-browser application and the first application. By way of example, in
Step 364 is displaying the first application in a browser window on an output display. By way of example,
Step 368 is grouping the browser window and the non-browser window on the output display in response to a user group input command. A user group input command may be any suitable user input command that indicates the grouping of two or more windows. Various embodiments are discussed in more detail below, including but not limited to moving two windows in positional proximity on screen, a pull-down menu selection, a key command, an icon selection, tabbing operations, etc.
Therein, step 370 is detecting an adjustment to the browser window and then adjusting the non-browser window in response thereto. For example, adjustments of the browser window and the subsequent non-browser window adjustment may be in size, position, content display, etc. It is further noted, the adjustment of browser window and non-browser window are interchangeable as described herein, including adjustments to the non-browser window affecting adjustments to the browser window.
Therein, the non-browser application (302 of
As part of the bridge module, the method of
It is further noted, the operating system bridge 316 does not need to be aware of specifics of a particular non-browser application, such as the APIs/protocols it communicates through) when communicating with the microservices bridge module 310. A further embodiment provides that the non-browser application does not require direct communication to any specific application running in a browser container. Rather, assimilation may be integration of the non-browser application without modification of non-browser application code into the browser container processing environment. This assimilation allows for integration of browser and non-browser applications as described herein, such as for example snapping, docking, and grouping, as well as tabbing, as described in greater detail below.
The bridge may include additional functionality aside from receiving and translating between applications. For example, the bridge may further read a configuration file, e.g. a JSON file, allowing for identification of which non-browser applications are allowed for assimilation. For example, a configuration file may include a list of prohibited or authorized non-browser applications. Therefore, the bridge may either enable authorized applications and/or prohibit assimilation of unauthorized applications. In another example, the bridge may need to throttle data coming from the non-browser application into the browser container. For example, native mouse movements may be generated at a rate of 1 mouse-movement event per millisecond, but there is no need to pass into the browser container mouse movements finer grain than 20 milliseconds.
In addition to integration of non-browser applications, the present method and system further provides improved cross-application functionality. When integrating browser containers, including HTML-encoded applications and non-browser applications, varying hotkey commands do not automatically translate. A hotkey command is a predefined combination of keystrokes that generate a defined operation or result. For example, a combination hotkey would be CMD-S as a dual-button keystroke that initiates an automated save function.
Various applications have their own keystrokes. Similarly, when multiple applications are bundled for cross-communication using the microservices layer, these keystrokes may not be available or may complicate processing. For example, different applications may have different functions associated with a hotkey input command. As these applications are not interconnected and communicate, the present method and system enables hotkey functions across multiple applications.
Operations of the system 400 are described with respect to the flowchart of
Step 422 is a determination if a hotkey is detected. If no, the method reverts to step 420 to continue monitoring. If yes, step 424 is translating the hotkey input command into a first application hotkey command. In one embodiment, the translating may include accessing the hotkey translation database 406.
In one embodiment, the hotkey translation database 406 may include general hotkey commands recognized for the application 410 or the operation system 408. For example, a user may set predefined keystrokes for the application 410, such predefined keystrokes stored in the hotkey translation database 406. Similarly, where there are conflicting commands generated by a hotkey input command, the monitor 404 may further detect which application 410 is being used by the user for generating a proper command.
Hotkeys may also be local hotkeys or global hotkeys. For example, a local hotkey may be local to an application in focus. As used herein, an application in focus refers to one or more applications being actively used by the user, such as for example an application into which a user is actively typing. A global hotkey may be a hotkey and subsequent input command usable across all applications.
Step 426 is executing the hotkey input command in the first application using the first application hotkey command. Based on the microservices layer, step 426 may additionally include executing the hotkey command in connected or integrated applications.
Where the present method and system allows for integrating multiple applications, these integrated applications may not originally share the same hotkey input commands. The keystroke monitor 404 in combination with the hotkey translation database 406 allows for inter-application interoperability without hotkey mistranslation.
Mark-up language applications running within the browser containers can register for hotkey events. Registration can include a priority setting so the browser container having the microservices module can route hotkey events between application in a configured order. Each application receiving the hotkey can decide to act on it and then consume it, e.g. not to pass it on, act on it then pass it on, only consumer, or only pass it on.
Hotkey recognition and distribution is another example of functionality available to non-browser applications without modification of the non-browser application code. Using the bridge as described above, hotkey keystrokes can be translated and inserted directly into the non-browser application. Another example of non-browser application assimilation without modification of the non-browser application code is generating groupings or interconnections between non-browser applications and applications via the user interface and/or processing, as described below.
In addition to interoperability of multiple browser applications, the present method and system literally interconnects these multiple windows. In the output display, each window is an independent instantiation of a browser container having an executable application therein. The present method and system allows for a unified multi-window application through the snapping, docking, and grouping (SDG) of windows, also collectively referred to as grouping.
Where SDG presents a visual front-end display of two or more windows, processing enables further functional interoperability as described herein. For example, when two windows are connected on the screen, they are also functionally grouped via the microservices module. It is noted, the SDG is equally applicable to one or more non-browser applications assimilated into browser window(s).
The microservices module facilitates interoperability, but the visual display includes any number of common display attributes. For example, when windows are integrated as described below, the integration includes window display attributes, as recognized by one skilled in the art. Window display attributes can include common color coding, common toolbars, common header controls, etc. Thus, windows subject to SDG can present a common visual interface to the user, as well as functional interoperability as described herein.
The method for integrating applications executable within the browser container including displaying the applications in separate windows. As noted above, each window is a separate application running in the browser container.
For a visual representation of SDG,
While
In
As illustrated in
Based on tracking the position of the application window, a tracking module running on the operating system level detects when one browser window gets in close proximity to another window. Upon reaching a defined positional proximity, for example within a proximity of one-eighth of an inch or within a distance of 15 pixels, the tracking module can then initiate a grouping operation. The grouping operation highlights or otherwise visually modifies a portion of the application windows and then graphically engages the two window frames together, as illustrated in
In one embodiment, when docked together the application display can be modified to include an undock tab 464. The undock tab 464, in response to a user selection, engages an undock module that graphically separates the applications, such as reverting back to spacing illustrated in
When the windows 450, 452, and 454 are grouped in the display, they are also grouped via processing operations. As described above, the present method and system includes interoperability between unique browser applications across the microservices module. The snapping, grouping, and docking of two or more windows creates the application-to-application association for the service layer to directly communicate between applications.
Using the example of the screenshots of
The present method and system provides for further modifications of groupings of windows. For example,
Here, in
The present method and system allows users to rapidly create groups of windows that join and move together. Users can swiftly spawn necessary components and bring them together into unified configurations that can be relocated to different locations on the screen, even moved across different monitors. Groupings can also be readily resized as well as broken up and new groups formed.
From a visual and user-interface perspective, the single window 470 offers additional benefits and functionality to the user. For example,
By contrast,
It is noted any one or more of the applications in windows 450, 452, and 454 may be a non-browser application as described above. Therefore, the grouping operations described herein, including both display and processing, are applicable to a non-browser application as well as browser applications. For example, upon grouping windows 450, 452, and 454, an update in the news application 450 by loading a news story about a specific company, could automatically generate the stock chart to be displayed in the application 452 and list a customer's share information in the account services application 454.
The inclusion of the microservices layer further allows for tabbing of separate applications into a user interface consistent with current tabbing displays found in modern browsers. Prior browser tabs suffer from the same secure sandbox prohibitions prohibiting communication from tabbed window to tabbed window.
In one embodiment, the user interface may include a graphical user interface or instruction, such as but not limited to a pull-down menu, menu bar button, a hotkey that allows a user to group multiple windows. These grouped windows can then be integrated into a tabbed display, as shown in
In this example, the single display 474 includes one focused application and two hidden applications based on the tabbed designation.
While the front-end display of
In addition to the above-described interoperability of multiple applications via the service module, the present method and system provides for interoperability improving emitter and receptor techniques. These techniques improve the interoperability and communication between applications, as well as improving functionality made available via the service layer (e.g. service layer 142 of
The applications 488, 490 are similar to the applications 154, 156 of
The system 480 further includes the rules engine 492, which provides functionality as described herein. The rules engine 492 is a microservices module. The rules engine 492 is illustrated as a separate component for clarity purposes and to illustrate its position between the applications 488, 490 and the browser container 484. Therefore, the rules engine 492 may be disposed within the microservices module 486.
In one embodiment, the method and system uses one or more APIs to facilitate emitter and receptor functionality.
The emitter 502 may be any suitable component or service within the processing platform, such as the system 100 of
The rules engine 504 is an intermediate processing module that receives strands 510 and determines if there is a rule to be applied to the strand 510. The engine 504 reviews the strand 510 and then accesses the rule database 506. If the database 506 includes one or more rules, the rule is retrieved therefrom and applied to the strand 510.
Within the present invention, the rules engine database 506 may be populated with system-defined rules, as well as user-defined rules. Within normal processing operations may store rules within the database 506 for access by the engine 504. Moreover, the database 506 is not necessarily a unitary storage device, may be any suitable number of storage locations having rules stored therein.
The engine 504 generates a modified strand 512 based on a rule. The engine 504 then broadcasts this modified strand 512, where it is received by the receptor 508. Similar to the emitter 502, the receptor 508 may be any suitable component or service within the processing platform, such as the system 100 of
The receptor 508 therein converts the modified strand to an action command. In the example of the receptor 508 being the application 490, the application may perform a processing operation based thereon.
Within the present method and system, the processing of strands may be subject to conditional statements as well as transformations. As part of the rule system, conditional rules allow for system-wide distribution of strands and conditional statements allowing for strand transformation. Thus, rules can define these conditional statements and transformations providing additional interoperability between applications. Moreover, the processing of strands does not necessarily require transformations, as original strands may be used as instructions or further routed as necessary. For example, a user-generated set of rules for a third-party application running in the browser container facilitates interoperability with other applications.
By way of example,
These conditions and transforms may be disposed in various receptors. Where
This method and system allows usage of general strands, where specific strands do not need to be unique to specific receptors. Strands may include more than one key and keys are hierarchical, which allows for restrictive or inclusive access to these one or more keys.
A strand contains one or more keys ordered with increasing specificity. A “key” is simply a string, and so a strand is essence an ordered list of strings. An exemplary taxonomy of “native” types provide the building blocks for strands, such as:
With these basic types, an application can emit a strand (for example, when beginning a drag and drop operation) while another application can advertise a receptor for that strand as outlined in the following pseudocode:
The protocol does not define a transport, relying on intermediary layers of code to send and receive messages as well as to implement discovery for advertising receptors. For instance, within a single application, two components might accomplish data transfer using drag and drop. Applications running on a single machine might use an interop relay. Between desktops, strands might be delivered via a chat network.
In one embodiment, strands contain a sequence of keys. For example, consider an embodiment provide for the transfer of market data:
An application could also emit multiple strands:
In one embodiment, this allows third-parties to implement their own protocols via namespacing:
With the ability for vendors to namespace, standards can be safely defined for common data types:
The simple nature of strands allows them to be transported across nearly any layer in the processing platform. Encoding can likewise be left to higher layers. That said, strands are designed as a user interface interoperability protocol. Web standards such as UTF-16 and base64 encoding (for binary data) can be articulated as de facto standards while allowing additional layers to translate data to other form factors when necessary.
Likewise, no protocol envelope is specifically required. Strands may be transmitted through function calls as over a network. The simple nature of strands would allow them to be packaged into any envelope (XML, FIX, etc) and intermediary layers could be relied upon to handle format conversion.
With reference back to
In
The present method and system, in this embodiment via the rule engine 504, allows for users to create their own customized integration between components. By establishing rules associated the data field and/or command field, single emitter strands can be perpetuated amongst a large number of receptors, with different results (actions) for different receptors.
Users may create customized integrations by supporting user-define strands and user-defined actions. One embodiment may include direct mappings to and from a document object model (DOM) associated with the mark-up language encoding. Customized integrations can be created using an interactive tool, pulling data from HTML/DOM and allowing a user to define mappings. These mappings can be imported into the rules engine.
A DOM is an API for mark-up language documents, defining logical structures of the document, as well as means for accessing and manipulating the document. Users may be able to build documents, navigate the document structure, add, modify, or delete elements and content using the DOM. Therefore, where the present emitter and receptor are elements within a processing platform run a browser platform and mark-up language applications, direct mappings to a DOM thereby directly translates to functionality and interoperability.
With respect to
In another embodiment allowing interoperability, the present method and system can integrate with a governing workflow solution, also referred to as a platform context structure. For example, one embodiment may include a Financial Desktop Connectivity and Collaboration Consortium (FDC3) workflow solution.
Via the rules engine, a transform command 516b can generate a selected action 534 for direct mapping to the FDC3 workflow solution 536. In this embodiment, the mapping may be to the FDC3 content plus the intent plus the data messages. The FDC3 intents define a standard set of nouns and verbs that can be used to put together common cross-application workflows.
The present method and system, as part of the interoperability, generates an operational function within the receptor. This operational function varies depending on the receptor itself. For example, if the receptor is an application, the operational function may be changing a value or output in the application, such as a display screen modification.
The receptor may be any suitable component or service, therefore the operational function of the receptor could be generating another emitter for a cascading result of numerous operations.
In another embodiment, the platform context structure action 544 can trigger action 546 received by the emitter 502.
In this exemplary embodiment, a phone application 560 acts as the emitter, emitting a strand that includes a phone number. The rules engine 492 receives strand and applies a rule to the strand. In this example, one rule may be to access a database receptor 562, a customer relations management (CRM) receptor 564, and a stock list receptor 566, and then finally a component launcher 568.
The rules engine 492 provides the strand to the database receptor 562, receiving contact information in response. For example, if the phone number is a 10-digit telephone number, the contact information may be full address and account information.
The rules engine 492 then provides the contact information to CRM receptor 564 and the stock list receptor 566. The CRM receptor 564 may process the strand for CRM tracking functions. The stock list receptor 566 can utilize the account information within the contact information to detect the person associated with the phone number holds stock in IBM and Apple (AAPL). The receptor 566 can then following the instructions to emit stock chart information for IBM and for Apple to the rules engine 492.
The engine 492, following a rule can then emit stock chart information to the launcher 568, which generates stock charts for IBM and AAPL on one or more stock charting applications 570, 572 respectively.
A data store, as used herein, is a mechanism for state management and simplifies building a user interface including using a data store field. The data store solves a one to many state management complexity and has benefits from being unidirectional. A data store with a data store field is set in a unidirectional manner, but notifications regarding changes are broadcast to one or more listeners. The present data store improves over prior techniques by being shareable and workable across window boundaries. The data store field, herein, includes a key value pair.
Components can leverage the distributed data store to side-step explicit dependencies. It is noted that some components may not utilize the data store, or may partly use the data store and have other dependencies through the router. Components in this architecture can be designed so that they depend only on a shared data model, Herein, the distributed data store enables interoperability between multiple browser applications in unique browser windows through the central disposition of the distributed data store and its data store field value through the microservices module.
Data stores are used to save and retrieve data either locally or globally. You can add listeners at multiple levels or at an individual attribute level within the stores values and get the updated data as it is updated in the data store.
The method and system includes various processing operations for the data store, including creating, storing, accessing, deleting, etc. The method and system also utilizes listeners to help monitor stores, including distributing/routing stores, including data store fields, as necessary.
In one embodiment, the data store supports database transactions. For example, one client of the distributed data store can lock store access until a set of transactions are completed. This embodiment can then insure store consistency across multiple fields.
Part of the distributed store is the routing of messages within the microservices module.
In one embodiment, the distributed data store can utilize a listen/transmit model. A component can set a listener request with the store 604. This listener request instructs the store 604 to transmit a notification when the store has changed value. More specifically, a transmit event is duplicated by the Router Service and sent to each of the corresponding listeners, whose callback is then invoked with the transmit data.
The router operations may be in accordance with known router techniques. The utilization of the distributed data store within the microservices facilitates an improved interoperability between multiple windows in one or more displays. The distributed data store facilitates harmonizing data amongst multiple applications via the microservices layer using a global store.
In a further embodiment, the computerized method and system provides for additional improved interoperability between applications. Here, the applications are browser-based executables applications. The interoperability is between any number of applications, include by way of example a first application and a second application. In another embodiment, one or more applications may be native applications using the assimilation methodology noted in
This embodiment facilitates interoperability through the incorporating a raised intent data call and a raised intent data field, also referred to as a context, associated therewith. This embodiment improves interoperability between applications through use of overlay applications executing within the same layer as the affiliated application. Here, the use of the overlay application eliminates the need for any modifications of the affiliated application, the computerized method and system can use the affiliated application in its original form.
The computerized method and system operates within the same computing framework noted above.
System 700 further includes a first application 702, a second application 704, and a third application 706. The applications 702-706 execute on top of the microservices module 152, which executes on top of the browser container 150, which executes on the I/O executable 148.
In this embodiment, the first application 702 includes a first overlay application 712. The second application 704 includes a second overlay application 714, and the third application 706 includes a third overlay application 716.
The applications 702, 704, and 706 can be any suitable application capable of being executed within the application layer. Moreover, it is recognized the three applications are exemplary only and not limiting in nature whereby the method and system can operate with any suitable number of applications.
When the application is a native application, such as application 302, the method and system may include bridging functionality 316, 318, as illustrated in
In one embodiment, the applications 702-706 may relate to or provide functionality associated with financial applications, including at least some processing operations in accordance with FDC3 guidelines.
The overlay applications 712, 714, 716 can be any suitable application for communicating with its associated application. For example, in one embodiment the overlay application is a module or application program interface (API). The overlay application facilitates interoperability without requiring coding modifications for the associated application and the overlay applications can include various processing operations in accordance with FDC3 guidelines.
Where
In this embodiment, step 720 is executing a first application in an application layer within a microservices layer, the first application being a browser-based executable application. For example, in
In one example, this application may be a financial account management application for a user to view and track financial information. For example, the application can be a user interface for a financial brokerage account showing account balances and investment holdings.
Step 722 is executing a second application in the application layer, the second application also being a browser-based executable application. As illustrated in
In one example, the second application may be a stock tracking application, including acquiring real-time stock pricing information and generating graphics.
Step 724 is executing a microservices module within a browser container, the microservices module facilitating communication between the first application and the second application in the browser container. As illustrated in
Step 726 is executing a first overlay application within the first application, the first overlay application transmitting via the microservices module. As illustrated in
Step 728 is, based on an interaction in the first application, transmitting, from the first overlay application to the microservices module, a first command transmission having a raised intent data call and a raised intent data field therein. Where the FDC3 standards include communication techniques for sharing information from one application to another, the FDC3 standard does not include a specific raised intent data call for associating, grouping, or otherwise connecting groups of applications beyond basic listening configuration protocols.
Continuing with the above example of the first application being an account management application, an interaction may be a selection of a particular stock, via a graphical user interface, entering a text field, a search field, or any other suitable input technique. The first overlay application detects the interaction based on processing routines monitoring the interactions in the first application.
As illustrated in
By contrast, the inclusion of the raised intent data call provides for interoperability by using the microservices module for command transmissions.
The overlay application operates using API or ancillary functionality to the application itself. The inclusion of the overlay application eliminates the requirement for specific coding modification of the application, and instead the overlay application includes FDC3 standard protocols as well as the communication improvements noted herein.
The first overlay application, upon detecting the event, generates the raised intent command transmission, referenced as the first command transmission above. The command transmission includes, but is not expressly limited to, the raised intent data call and the raised intent data field. The raised intent data call is an expressly identified data call providing for identified or understood status within the process environment. The raised intent data call defines an instruction that a particular function or operation has been performed in the first application. Correlating therewith, the raised intent data field is a data field identified with or associated with the function or operation, also referred to as a context.
Continuing with the example of the first application being an account management application and the user identifying a stock symbol, the raised intent data call can identify the function as a stock symbol data retrieval and the raised intent data field being the actual stock symbol, such as the unique letter or letter/number combination identifier.
Referring back to
The nature of the raised intent call facilitates dynamic operation by the second application.
The second overlay application helps make this happen acting as the interface with the second application. Similar to the first application, the second application can respond to the raise intent data call and field based on the second overlay application without requiring modifications to the code of the second application. For example, the first application and the second application can be executable browser-based applications performing coded instructions independent of the raised intent data call and field.
By contrast, the first application and the second application include coding instructions for engaging and communicating with its affiliated overlay application. Raised intent functionality of the first application and the second application is facilitated based on the applications communicating and/or engaging with the overlay application.
In one embodiment, communication between applications provides interoperability or interop with applications being on a common channel. Information passed between applications is then transmittable and viewable across this channel.
There are two primary categories of data used herein: context data and intents. Context is a type of data exchange where apps can listen (subscribe) and/or broadcast (publish) context changes. An intent, by contrast, is where a second application fulfills an action on its behalf. The above exemplary embodiment of a financial account application and a stock charting application, the stock charting application completes the action on its own, based on the action in the first application, selecting a stock symbol.
FDC3 uses context as part of broadcasting operations, but under the raised intent processing operations, context is a parameter for raised intent functions. For example, the raised intent API data call raises an intent for another application to handle including the context parameter. For example, coding a raised intent may include: button.addEventListenera(“onClick”, ( )=>{fdc3.raiseIntent(“ViewChart”, {type: “fdc3.instrument”, id: {ticker: “AAPL”}});}).
On the secondary side of a raised intent is listening. An overlay application can listen for intents raised by other apps. For example, coding a listening for a raised intent may include: fdc3.addIntentListener(“ViewChart”, (content)=>{const{type}=context; if (type==“fdc3.instrument”){myAppLoadSymbol(context.id.ticker); }}).
By contrast, the application 750 using an overlay application (not expressly illustrated), similar to overlay application 712, provides for select connect rules improving microservice functionality over the FDC3 functionality. Herein, the application 750 includes functionality for forward or copy a context to either or both a different channel or a specified software module.
For example, as illustrated in
In another embodiment, the context can be transmitted or shared across a different channel. Under FDC3 standards, the application 758 must actively listen to a specific channel, including knowing what channel application 750 is transmitting on. By contrast, under the improved microservice functionality, the application 758 or the microservice module at a control level, for example at the channel module 754, creates an association to a dedicated or known channel.
In one embodiment, the rule to forward or cross-distribute across multiple channels can be controlled at the context level. For example, the rules may be specified by the context name, the application sending the context, and/or a specified software module.
In one example, the rule can be within an application's configuration to copy a broadcast of the contextType “fdc3.instrument” sent to or from the application to a workspace manage that will persist the context state and restore it on a workspace reload. For example, on coding embodiment may be: “selectConnect”: [{“contextType”: “fdc3.instrument”, “cc”: “#workspace” } ].
In a further embodiment, the improved microservices functionality of
In one embodiment, each application can set its own authorization rules. For example, rules may include the name and/or domain of applications that are authorized to send or receive broadcasts. In another embodiment, a wildcard or general identifier may be used to identify a set or group of applications.
In a further improvement over FDC3 protocols, the application 758 may include auto-join operations for connecting to one or more channels. In this embodiment, instances of an application 758 can be automatically associated with the channel by meeting predefined criteria.
In one embodiment, the criteria for automatically associating applications may be dynamically determined through a parent relationship, for example all children spawned by the parent application can be automatically associated. In another embodiment, association can be performed by matching configurations.
Here, by having auto-join functionality, the improved microservices functionality further associates or connects various applications beyond the FDC3 broadcast and listen standards.
When an application raises and intent, the intent's resolution (i.e., which applications can receive the intent) might be affected by an application association for intents. When enabled, only applications in the same association are in scope for resolving which application will receive the intent. Applications not in the association, and therefore out of scope, will be ignored.
In the
Again, the criteria for automatically associating applications might be dynamically determined through a parent relationship (e.g., all children spawned by the parent application will be associated), or statically determined by matching configuration identifiers within each application's configuration.
Another microservices functionality beyond the FDC3 standards include a remembering operation between applications. This function can operate in lieu of a parent/child relationship or an association identifier configuration setting.
Where a raised intent resolution does not filter down to a single destination (application), microservice functionality can provide for prompting the user to choose a destination application. Application selection can be within the FDC3 standards, but these selections are transitory. An improved microservice functionality includes a user selection for enabling a remembering function to store the association for future dynamic selection.
In one embodiment, during user selection, the user can be presented with a user interface operation to enable the remembering function. Therefore, the next time the microservices platform encounters the same scenario between applications, the microservices platform does not prompt the user for intent resolution, but rather automatically reuses the prior selection.
Here, remembered choices are bound to the application that originates the intent and to the specific intent name. If either the originating application or the destination application is closed, then the remembered choice is discarded; otherwise, it will persist across workspace reloads microservice platform restarts. The user can optionally manage choices using a dedicated UI. This allows the user to discard a previously remembered choice (without having to close the originating or destination app).
The microservice platform functionality further improves over the FDC3 standard for active and dynamic association between multiple applications and separate instances of applications. For example, in a platform having multiple instances of applications, a first instance of an application can be associated with another application and a second instance of the application can be associated with a different application. This dynamic association and cross-communication and interoperability is based on raised intents and select connect rules beyond the FDC3 standard.
In one example, a user can launch two instances of a news application and two instances of a charting application. Under the microservices functionality herein, the user can associate the first news application instance with the first charting application instance, as well as associate second news application instance with the second instance of the charting application. In varying embodiments, the association between application instances can be based on prior selections, user selections, grouping rules, or other association embodiments noted above.
Under this arrangement, the user reading a news article on the first news application instance can cause the first charting application instance to launch a stock chart of one or more companies listed in the news article. Similarly, the user can engage the separate application window for the second news application instance, select or review an article, and cause the second charting application instance to launch a stock chart of the one or more companies listed in the article. This is performed using raised intent operations as noted above, providing for directed association and contextual distribution between grouped applications.
Moreover, the remembering function allows for direct association between applications to be maintained in different execution sessions. For instance, if the user closes and later launches the first instance of the news application, this instance can directly associated again with the first instance of the charting application.
The foregoing description of the specific embodiments so fully reveals the general nature of the invention that others can, by applying knowledge within the skill of the relevant art(s) (including the contents of the documents cited and incorporated by reference herein), readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Such adaptations and modifications are therefore intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein.
The present application is a continuation-in-part of and claims priority to U.S. patent application Ser. No. 16/941,857 entitled “SYSTEM AND METHOD FOR INTEGRATING MULTIPLE APPLICATIONS” filed Jul. 29, 2020, which is continuation of and claims priority to U.S. patent application Ser. No. 15/980,981 entitled “SYSTEM AND METHOD FOR INTEGRATING MULTIPLE APPLICATIONS” filed May 16, 2018. The present application claims priority to Provisional Patent Application Ser. No. 63/358,654 entitled “INTEROPERABILITY COMPUTING METHOD AND SYSTEM” filed Jul. 6, 2022.
| Number | Date | Country | |
|---|---|---|---|
| 63358654 | Jul 2022 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15980981 | May 2018 | US |
| Child | 16941857 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16941857 | Jul 2020 | US |
| Child | 18218860 | US |
