Gradual refresh of user interface screens

Abstract

This provides a novel method for detecting and / or updating the contents of outdated caches. [Solution] One embodiment may include determining the UI screen of an application navigated by the user interface (UI) of a software application. This embodiment may also include receiving interactions with the UI components of the current UI screen, and, based on the reception of these interactions, determining the next UI screen that is expected to be displayed after the current UI screen. Furthermore, this embodiment may include sending a query to a server device for an updated version of the next UI screen prior to receiving a request to navigate to the next UI screen, receiving a response from the server device containing the updated version of the next UI screen, and, based on the reception of a request to navigate to the next UI screen, displaying the updated version of the next UI screen based on the response.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the priority of U.S. Patent Application No. 17 / 590,792, filed on February 1, 2022, and incorporates all of its contents herein by reference.

Background Art

[0002] A software application can be configured to cache at least a portion of the responses received from a server device. According to such caching, since at least a portion of a given user request may be satisfied based on the cached data, the apparent responsiveness of the software application to user navigation requests can be improved. However, since the cached data may become stale over time, the display of such data may not be desirable. Therefore, it is beneficial to detect and / or update the contents of stale cache.

Summary of the Invention

[0003] A software application can be configured to operate by displaying a plurality of user interfaces (UIs). In some cases, these UIs can be arranged as UI screens each including one or more UI components, and / or grouped as tabs each including one or more related UI screens. The UI screens can be generated by a server device instead of the software application. Also, the server device can maintain the underlying data on which the UI screens are based and / or the underlying data displayed by the UI screens. The software application can be a native application and / or a web browser - based application.

[0004] To improve the responsiveness of a software application to user input, a software application may be configured to cache UI screens that it has previously navigated and / or displayed (for example, as part of a given usage session). This allows requests to revisit previously displayed UI screens to be fulfilled using the cache rather than network calls to a server. However, if two or more UI screens depend on the same underlying data, modifications to that data performed using one of these UI screens may cause the cached version of another of those UI screens to become outdated. Therefore, if a particular UI screen modifies the underlying data, the server may be configured to (i) replay and send an updated version of that particular UI screen, and possibly (ii) replay and send updated versions of one or more previously displayed UI screens affected by the modification. However, this approach may unnecessarily consume computational and / or communication resources because the software application may not use the updated versions of one or more previously displayed UI screens affected by the modification.

[0005] Therefore, a software application may, as an alternative, be configured to track previously displayed UI screens, identify their older subsets, and progressively anticipate UI screens that are expected to reappear next. Specifically, since the software application is used for navigating its UI screens, it may be configured to track multiple navigated UI screens and / or maintain an ordered list indicating the order in which these UI screens were visited. If underlying data is modified by interaction with UI components of the currently displayed UI screen, the software application may be configured to determine an old set of UI components that may contain a subset of multiple UI components that have become outdated by the modification. The old set may be identified, for example, based on the tab to which the currently displayed UI component belongs, and / or based on a dependency map indicating UI screens and / or UI components that utilize the modified data. The old set may be updated when an updated version of the UI screen is obtained and / or when additional modifications are made.

[0006] Furthermore, the software application may be configured to identify the next UI screen that is expected to reappear after the currently displayed UI screen, and, if the next UI screen is outdated, to preemptively retrieve the next UI screen before the software application receives a user request for it. Therefore, when the software application receives a user request for the next UI screen, it may be able to provide an updated version of the next UI screen from the cache instead of the outdated version, potentially eliminating the user's need to wait for the updated version of the next UI screen to be retrieved from the server. Additionally, because the cache may already contain the updated version of the next UI screen, the user may not need to manually determine whether to request a refresh of the next UI screen, thus avoiding unnecessary refresh requests.

[0007] User navigation of a software application can determine the next UI screen that is expected to be displayed, and these screens can be anticipated one at a time, thus avoiding the generation and / or transmission of updated versions of UI screens that the user may not actually re-navigate to. In one example, the next and / or subsequent UI screens may be determined based on the reverse of the order in which multiple UI screens were initially navigated, with the most recently displayed UI screen being the first to be anticipated. In another example, the next and / or subsequent UI screens may be determined based on a workflow model that defines the intended sequence and / or empirically observed sequence of UI screen displays.

[0008] Accordingly, the first exemplary embodiment may include a computer system comprising a processor, memory, and a software application stored in memory and configured to perform an operation when executed by the processor. The operation may include determining a plurality of UI screens of the software application, which are navigated by the user interface (UI) of the software application. The operation may also include the UI receiving an interaction with the UI components of the current UI screen among the plurality of UI screens, and, based on the reception of the interaction, determining the next UI screen among the plurality of UI screens that are expected to be redisplayed after the current UI screen. Furthermore, the operation may include sending a query to a server device for an updated version of the next UI screen prior to receiving a request to navigate to the next UI screen. The operation may further include receiving a response from the server device containing the updated version of the next UI screen, and, based on the reception of a request to navigate to the next UI screen, the UI displaying the updated version of the next UI screen based on the response.

[0009] A second exemplary embodiment may include determining a plurality of UI screens of a software application that are navigated by the UI of the software application. The second exemplary embodiment may also include the UI receiving an interaction with the UI components of the current UI screen among the plurality of UI screens, and, based on the reception of the interaction, determining the next UI screen among the plurality of UI screens that are expected to be redisplayed after the current UI screen. Furthermore, the second exemplary embodiment may include sending a query to a server device for an updated version of the next UI screen prior to receiving a request to navigate to the next UI screen. The second exemplary embodiment may further include receiving a response from the server device containing the updated version of the next UI screen, and, based on the reception of a request to navigate to the next UI screen, the UI displaying the updated version of the next UI screen based on the response.

[0010] In a third exemplary embodiment, the product may include a non-temporary computer-readable medium containing program instructions that, when executed by a computer system, cause the computer system to perform the operations described in the first and / or second exemplary embodiments.

[0011] In a fourth exemplary embodiment, the computer system may include, in addition to at least one processor, memory and program instructions. The program instructions may be stored in memory and, when executed by at least one processor, cause the computer system to perform the operations described in the first and / or second exemplary embodiment.

[0012] In a fifth exemplary embodiment, the system may include various means for performing each of the operations of the first and / or second exemplary embodiments.

[0013] Those skilled in the art will find the above and other embodiments, aspects, advantages, and alternatives apparent by reading the following detailed description, with reference to the accompanying drawings as necessary. Furthermore, since this abstract and other descriptions and drawings contained herein are intended to illustrate embodiments only as examples, many modifications are possible. For example, structural elements and process steps can be rearranged, combined, distributed, removed, or modified while remaining within the scope of embodiments such as those claimed. [Brief explanation of the drawing]

[0014] [Figure 1] This is a schematic diagram of computer equipment according to an exemplary embodiment. [Figure 2] This is a schematic diagram of a server equipment cluster according to an exemplary embodiment. [Figure 3] This diagram shows a remote network management architecture according to an exemplary embodiment. [Figure 4] This diagram shows a communication environment including a remote network management architecture according to an exemplary embodiment. [Figure 5A] This diagram shows another communication environment, including a remote network management architecture, according to an exemplary embodiment. [Figure 5B] This is a flowchart according to an exemplary embodiment. [Figure 6] This figure shows an embodiment of a software application according to an exemplary embodiment. [Figure 7A] This is a message flow diagram according to an exemplary embodiment. [Figure 7B] This is a message flow diagram according to an exemplary embodiment. [Figure 7C] This is a message flow diagram according to an exemplary embodiment. [Figure 8] This is a flowchart according to an exemplary embodiment. [Modes for carrying out the invention]

[0015] This specification describes exemplary methods, devices, and systems. In this specification, it is to be understood that the words "example" and "exemplary" are used to mean "functioning as an instance, case, or illustration". Any embodiment or feature described herein as "example" or "exemplary" is not necessarily to be construed as more preferred or advantageous than other embodiments or features, unless otherwise stated. Thus, other embodiments can be utilized and other changes can be made without departing from the scope of the subject matter presented herein.

[0016] Therefore, the exemplary embodiments described herein are not meant to be limiting. It is readily understood that aspects of the present disclosure, as described throughout this specification and shown in the drawings, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations. For example, the separation of functions to "client" and "server" components can be implemented in many ways.

[0017] Furthermore, unless otherwise suggested by context, the features shown in each drawing can be used in combination with each other. For this reason, the drawings should generally be regarded as showing aspects of the components of one or more overall embodiments, and it is understood that not all of the features shown are necessary for each embodiment.

[0018] Also, any enumeration of elements, blocks, or steps in this specification or the claims is for purposes of clarity. Thus, such enumeration should not be construed as requiring or implying compliance with a particular arrangement of these elements, blocks, or steps or performance in a particular order.

[0019] I. Introduction Large enterprises are complex entities with many interrelated operations. Among these are those found throughout the enterprise, such as human resources (HR), supply chain, information technology (IT), and finance. However, each enterprise also has its own unique operations that lead to the provision of essential capabilities and / or the building of competitive advantages.

[0020] To support widely implemented operations, enterprises typically use off-the-shelf software applications such as customer relationship management (CRM) and human capital management (HCM) packages. However, custom software applications may also be required to meet the enterprise's own unique requirements. Large enterprises often have dozens or hundreds of these custom software applications. In contrast, the advantages provided by the embodiments of this specification are not limited to large enterprises and are considered applicable to enterprises or other types of organizations of all sizes.

[0021] Many such software applications are developed by individual departments within the enterprise. These range from simple spreadsheets to custom software tools and databases. However, there are many drawbacks to the prevalence of custom software applications without collaboration with other departments. This has an adverse impact on the enterprise's ability to operate and grow its business, technological innovation, and response to regulatory requirements. Enterprises may find it difficult to integrate, rationalize, and enhance their operations because they do not have a single system to integrate their subsystems and data.

[0022] To efficiently generate custom applications, enterprises will benefit from a remote-hosted application platform that eliminates unnecessary development complexity. The goal of such a platform is to reduce time-consuming repetitive application development tasks so that software engineers and other individuals on the task can focus on developing highly valuable unique functions.

[0023] To achieve this goal, the concept of aPaaS (Application Platform as a Service) is introduced to intelligently automate enterprise-wide workflows. While the aPaaS system is hosted remotely from the enterprise, it provides secure connectivity to enterprise data, applications, and services. Such aPaaS system offers numerous advantages and characteristics. These advantages and characteristics are expected to improve enterprise operations and workflows in IT, HR, CRM, customer service, application development, and security. However, the embodiments described herein are not limited to enterprise use or environments and are more broadly applicable.

[0024] aPaaS systems can support the development and execution of Model-View-Controller (MVC) applications. MVC applications enable efficient code reuse and parallel development by separating the representation of information from how it is presented to the user, by dividing each function into three interconnected parts (model, view, and controller). These applications can be web-based and provide create, read, update, and delete (CRUD) functionality. This allows new applications to be built on a common application infrastructure. In some cases, applications with structures different from MVC, such as those using unidirectional data flow, may be adopted.

[0025] an aPaaS system can support standardized application components, such as a standardized set of widgets for graphical user interface (GUI) development. Thus, applications built using an aPaaS system will have a common look and feel. Other software components and modules may also be standardized. In some cases, this look and feel can be branded or skinned with a company's custom logo and / or color scheme.

[0026] aPaaS systems can support the ability to configure application behavior using metadata. This allows for quick adaptation of application behavior to meet specific needs. This approach reduces development time and increases flexibility. Furthermore, aPaaS systems can support GUI tools that simplify metadata creation and management, thereby reducing metadata errors.

[0027] Because aPaaS systems can support clearly defined interfaces between applications, software developers can avoid unnecessary inter-application dependencies. Therefore, aPaaS systems can implement a service layer where persistent state information and other data are stored.

[0028] Because aPaaS systems can support a rich set of integration capabilities, applications on the system can interact with legacy and third-party applications. For example, an aPaaS system could support a custom employee training system that integrates with legacy HR, IT, and accounting systems.

[0029] aPaaS systems can support enterprise-level security. Furthermore, because aPaaS systems can be hosted remotely, security procedures should also be utilized when interacting with enterprise systems or third-party networks and services hosted outside the enterprise. For example, aPaaS systems may be configured to detect and identify common security threats by sharing data among parties such as enterprises.

[0030] Other features, functions, and advantages of aPaaS systems may also exist. This description is illustrative and not intended to be limiting.

[0031] As an example of the aPaaS development process, a software developer might be instructed to create a new application using an aPaaS system. The developer might first define a data model specifying the types of data the application will use and the relationships between them. The developer then inputs (for example, uploads) the data model through the aPaaS system's GUI. The aPaaS system automatically creates all the corresponding database tables, fields, and relationships, which are accessible via an object-oriented service layer.

[0032] Furthermore, aPaaS systems enable the creation of fully functional applications with client-side interfaces and server-side CRUD logic. These generated applications can serve as a foundation for further user development. This is convenient for developers as they do not need to spend much time on the application's basic functionality. Additionally, since the application can be web-based, it is accessible from any internet-enabled client device. Alternatively or additionally, access to a local copy of the application may be provided, for example, when internet services are unavailable.

[0033] Furthermore, aPaaS systems can support a rich set of predetermined functions that can be added to applications. These functions include support for search, email, templates, workflow design, reporting, analytics, social media, scripting, mobile output, and customizable GUIs.

[0034] Such aPaaS system can represent a GUI in various ways. For example, the server equipment of the aPaaS system may generate a representation of the GUI using a combination of HTML and JAVASCRIPT®. JAVASCRIPT® may include client-side executable code, server-side executable code, or both. The server equipment may transmit or provide this representation to the client equipment so that the client equipment displays it on its screen according to a locally defined appearance and feel. Alternatively, the representation of the GUI may take other forms, such as an intermediate form (e.g., JAVA® bytecode) that the client equipment can use to directly generate graphic output. Other possibilities exist as well.

[0035] Furthermore, user interactions with GUI elements such as buttons, menus, tabs, sliders, checkboxes, and toggles may also be referred to as "selection," "activation," or "operation," respectively. These terms can be used regardless of whether the interaction with the GUI element is via keyboard, pointing device, touchscreen, or other mechanism.

[0036] The aPaaS architecture is particularly effective when integrated with an enterprise network and used for managing such networks. The following embodiments describe exemplary aPaaS system architectures and functional aspects, as well as their respective features and advantages.

[0037] II. Exemplary Computer Equipment and Cloud-Based Computing Environments Figure 1 is a simplified block diagram illustrating computer equipment 100, showing some of the components included in the computer equipment and configured to operate according to the embodiments herein. Computer equipment 100 can be a client device (for example, a device actively operated by a user), a server device (for example, a device that provides computing services to client devices), or any other type of computing platform. Some server devices may occasionally operate as client devices to perform specific operations, and some client devices may have server functionality built in.

[0038] In this example, the computer device 100 comprises a processor 102, memory 104, a network interface 106, and an input / output unit 108, all of which may be coupled by a system bus 110 or a similar mechanism. In some embodiments, the computer device 100 may also comprise other components and / or peripherals (e.g., removable storage, printer, etc.).

[0039] The processor 102 may be one or more of any type of computer processing element, such as a central processing unit (CPU), a coprocessor (e.g., a mathematical, graphics, or cryptographic coprocessor), a digital signal processor (DSP), a network processor, and / or an integrated circuit or controller that performs processor operations. In some cases, the processor 102 may be one or more single-core processors. In other cases, the processor 102 may be one or more multi-core processors with multiple independent processing units. The processor 102 may also include register memory for temporarily storing instructions to be executed and associated data, as well as cache memory for temporarily storing recently used instructions and data.

[0040] Memory 104 may be any form of computer-usable memory, including but not limited to random access memory (RAM), read-only memory (ROM), and non-volatile memory (e.g., flash memory, hard disk drives, semiconductor drives, compact discs (CDs), digital video discs (DVDs), and / or tape storage). Therefore, memory 104 represents both the main memory unit and long-term storage. Other types of memory include biological memory.

[0041] Memory 104 may store program instructions and / or data on which the program instructions can be executed. For example, memory 104 may store these program instructions in a non-temporary computer-readable medium so that they can be executed by the processor 102 to perform any of the methods, processes, or operations disclosed herein or in the accompanying drawings.

[0042] As shown in Figure 1, memory 104 may include firmware 104A, kernel 104B, and / or application 104C. Firmware 104A may be program code used to start or begin some or all of the computer equipment 100. Kernel 104B may be an operating system including modules for memory management, processor scheduling and management, input / output, and communication. Kernel 104B may also include device drivers that enable the operating system to communicate with hardware modules of the computer equipment 100 (e.g., memory units, network interfaces, ports, and buses). Application 104C may be one or more user-space software programs such as a web browser or email client, as well as any software libraries used by these programs. Memory 104 may also store data used by the above and other programs and applications.

[0043] The network interface 106 may be in the form of one or more wired interfaces, such as Ethernet (e.g., Fast Ethernet, Gigabit Ethernet). The network interface 106 may also support communication over one or more non-Ethernet media, such as coaxial cable or power lines, or wide-area media, such as Synchronous Optical Networking (SONET) or Digital Subscriber Line (DSL) technology. Furthermore, the network interface 106 may be in the form of one or more wireless interfaces, such as IEEE 802.11 (Wi-Fi), Bluetooth®, Global Positioning System (GPS), or wide-area wireless interfaces. However, other forms of physical layer interfaces and other types of standard or proprietary communication protocols may be used via the network interface 106. In addition, the network interface 106 may include multiple physical interfaces. For example, some embodiments of the computer device 100 may include Ethernet, Bluetooth®, and Wi-Fi interfaces.

[0044] The input / output unit 108 can facilitate interaction between the user and peripheral devices with the computer equipment 100. The input / output unit 108 may include one or more types of input devices (keyboard, mouse, touchscreen, etc.). Similarly, the input / output unit 108 may include one or more types of output devices (screen, monitor, printer, and / or one or more light-emitting diodes (LEDs), etc.). As an addition or alternative, the computer equipment 100 can communicate with other devices, for example, by using a Universal Serial Bus (USB) or High Definition Multimedia Interface (HDMI) port interface.

[0045] In some embodiments, the aPaaS architecture may be supported by the deployment of one or more computer devices, such as computer device 100. The exact physical location, connectivity, and configuration of these computer devices may be known and / or irrelevant to the client devices. Thus, the computer devices may be referred to as “cloud-based” devices that can be housed in various remote data center locations.

[0046] Figure 2 shows a cloud-based server cluster 200 according to an exemplary embodiment. In Figure 2, the operation of computer equipment (e.g., computer equipment 100) may be distributed among server equipment 202, data storage 204, and router 206, all of which may be connected by a local cluster network 208. The number of server equipment 202, data storage 204, and router 206 in the server cluster 200 may depend on the computing tasks and / or applications assigned to the server cluster 200.

[0047] For example, server device 202 can be configured to perform various computational tasks of computer device 100. Therefore, computational tasks can be distributed among one or more server devices 202. Such task distribution can reduce the total time required to complete these tasks and return results, as long as these tasks can be executed in parallel. For simplicity, both the server cluster 200 and individual server devices 202 may be referred to as "server devices." This naming is understood to imply that one or more different server devices, data storage devices, and cluster routers may be involved in the operation of the server devices.

[0048] The data storage 204 may be a data storage array including a drive array controller configured to manage read / write access to multiple groups of hard disk drives and / or semiconductor drives. The drive array controller may also be configured, either alone or in conjunction with the server equipment 202, to manage backups or redundant copies of the data stored in the data storage 204, as protection against drive failures or other types of failures that would prevent one or more server equipment 202 from accessing the data storage 204 units. Other types of memory besides drives may be used.

[0049] Router 206 may include network equipment configured to provide internal and external communications to the server cluster 200. For example, Router 206 may include one or more packet switching and / or routing devices (including switches and / or gateways) configured to provide (i) network communications between server equipment 202 and data storage 204 via the local cluster network 208, and / or (ii) network communications between the server cluster 200 and other equipment via a communication link 210 to network 212.

[0050] Furthermore, the configuration of router 206 may be based at least in part on the data communication requirements of server equipment 202 and data storage 204, the latency and throughput of local cluster network 208, the latency, throughput, and cost of communication link 210, and / or other factors that may contribute to the cost, speed, fault tolerance, resilience, efficiency, and / or other design objectives of the system architecture.

[0051] One possible example is that data storage 204 may include any form of database, such as a Structured Query Language (SQL) database. In such a database, various types of data structures can store information, including, but not limited to, tables, arrays, lists, trees, and tuples. Furthermore, any database in data storage 204 may be monolithic or distributed across multiple physical devices.

[0052] The server device 202 may be configured to send data to and / or receive data from the data storage 204. This transmission and retrieval may be in the form of SQL queries or other types of database queries, or the output of such queries. Similarly, text, images, videos, and / or audio may be additionally included. Furthermore, the server device 202 may organize the received data as a representation of a web page or web application. Such a representation may be in the form of a markup language such as Hypertext Markup Language (HTML), Extended Markup Language (XML), or any other standardized or proprietary format. Furthermore, the server device 202 may be capable of executing various types of computerized scripting languages, including but not limited to Perl, Python, PHP Hypertext Preprocessor (PHP), Active Server Pages (ASP), and JAVASCRIPT®. Computer program code written in these languages ​​can provide web pages to client devices and facilitate interaction with web pages on client devices. As an alternative or addition, Java® may be used to facilitate the generation of web pages and / or to provide web application functionality.

[0053] III. Exemplary Remote Network Management Architecture Figure 3 shows a remote network management architecture according to an exemplary embodiment. This architecture includes three main components: a managed network 300, a remote network management platform 320, and a public cloud network 340, all connected by the Internet 350.

[0054] A. Managed Network The managed network 300 may be an enterprise network used by entities for data storage, as well as for computing and communication tasks. For this purpose, the managed network 300 may comprise client devices 302, server devices 304, a router 306, a virtual machine 308, a firewall 310, and / or a proxy server 312. The client devices 302 may be embodied by computer devices 100, the server devices 304 may be embodied by computer devices 100 or a server cluster 200, and the router 306 may be any type of router, switch, or gateway.

[0055] A virtual machine 308 may be embodied by one or more of the computer equipment 100 and the server cluster 200. Generally, a virtual machine is an emulation of a computer system that mimics the functions of a physical computer (e.g., processor, memory, and communication resources). A single physical computer system, such as a server cluster 200, can support up to several thousand individual virtual machines. In some embodiments, the virtual machine 308 may be managed by a centralized server equipment or application that facilitates performance and error reporting, in addition to allocating physical computing resources to individual virtual machines. Enterprises often adopt virtual machines to efficiently allocate computing resources as needed. Providers of virtualized computer systems include VMware® and Microsoft®.

[0056] The firewall 310 may be one or more dedicated routers or server devices that protect the managed network 300 from unauthorized access attempts to internal devices, applications, and services while allowing legitimate communications originating from the managed network 300. The firewall 310 may also provide intrusion detection, web filtering, virus scanning, application layer gateways, and other applications or services. In some embodiments not shown in Figure 3, the managed network 300 may include one or more virtual private network (VPN) gateways for communicating with a remote network management platform 320 (see below).

[0057] Furthermore, the managed network 300 may comprise one or more proxy servers 312. One embodiment of the proxy server 312 may be a server application that facilitates the communication and movement of data between the managed network 300, the remote network management platform 320, and the public cloud network 340. In particular, the proxy server 312 may be capable of establishing and maintaining a secure communication session with one or more compute instances of the remote network management platform 320. Such a session may enable the remote network management platform 320 to discover and manage the architecture and configuration of the managed network 300 and its components. In some cases, with the assistance of the proxy server 312, the remote network management platform 320 may also be capable of discovering and managing the configuration of the public cloud network 340 used by the managed network 300.

[0058] Firewalls such as firewall 310 typically reject all incoming communication sessions via the Internet 350 unless the session ultimately originates behind the firewall (i.e., on a device on the managed network 300) and the firewall is explicitly configured to support the session. By placing the proxy server 312 behind firewall 310 (for example, by placing it within the managed network 300 and protecting it with firewall 310), the proxy server 312 may be able to initiate these communication sessions through firewall 310. This may eliminate the need for firewall 310 to be specially configured to support incoming sessions from the remote network management platform 320, thus avoiding a potential security risk to the managed network 300.

[0059] In some cases, the managed network 300 may consist of a small number of devices and networks. In other deployments, the managed network 300 may extend to multiple physical locations and include hundreds of networks and hundreds of thousands of devices. Therefore, the architecture shown in Figure 3 can be scaled up or down by orders of magnitude.

[0060] Furthermore, the number of proxy servers 312 deployed internally can be varied depending on the size, architecture, and connectivity of the managed network 300. For example, each proxy server 312 may be responsible for communication with the remote network management platform 320 for a portion of the managed network 300. Alternatively or additionally, load balancing, redundancy, and / or availability can be improved by assigning multiple sets of two or more proxy servers to such portions of the managed network 300.

[0061] B. Remote Network Management Platform The remote network management platform 320 is a hosted environment that provides aPaaS services to users, particularly operators of the managed network 300. These services may take the form of a web-based portal using, for example, the web-based technologies described above. This allows users to securely access the remote network management platform 320 from, for example, client equipment 302 or potentially client equipment outside the managed network 300. The web-based portal enables users to design, test, and deploy applications, generate reports, review analyses, and perform other tasks. The remote network management platform 320 may also be referred to as a multi-application platform.

[0062] As shown in Figure 3, the remote network management platform 320 includes four compute instances 322, 324, 326, and 328. Each of these compute instances may represent one or more nodes and / or one or more database nodes operating a dedicated copy of the aPaaS software. On physical server equipment and / or virtual machines, the servers and databases can be flexibly positioned and may be modified based on the enterprise's needs. In combination, these nodes can provide a set of web portals, services, and applications (e.g., a fully functional aPaaS system) available to a particular enterprise. In some cases, a single enterprise may use multiple compute instances.

[0063] For example, the managed network 300 may be an enterprise customer of the remote network management platform 320, and may also use compute instances 322, 324, and 326. One reason for providing multiple compute instances to a single customer is that the customer may want independent development, testing, and deployment of their applications and services. For this reason, compute instance 322 may be dedicated to application development associated with the managed network 300, compute instance 324 may be dedicated to testing these applications, and compute instance 326 may be dedicated to the live operation of the tested applications and services. Compute instances may also be referred to as hosted instances, remote instances, customer instances, or any other designation. Any application deployed on a compute instance is considered a scoped application in that access to the database within the compute instance may be restricted to certain internal elements (e.g., one or more specific database tables or specific rows within one or more database tables).

[0064] For simplicity, in this disclosure, the configuration of application nodes, database nodes, aPaaS software running on them, and the underlying hardware is referred to as a “computation instance.” Users may colloquially refer to the graphical user interface provided thereunder as an “instance.” Unless otherwise defined herein, a “computation instance” is a computer system located within the remote network management platform 320.

[0065] The multi-instance architecture of the Remote Network Management Platform 320 offers several advantages in contrast to traditional multi-tenant architectures. In a multi-tenant architecture, data from different customers (e.g., corporations) is mixed in a single database. While these customer data are isolated from each other, this isolation is enforced by the software operating the single database. As a result, a security breach in this system affects all customer data, posing an additional risk, especially for entities subject to government, healthcare, and / or financial regulations. Furthermore, any database operation affecting one customer can potentially affect all customers sharing that database. Therefore, in the event of an outage due to a hardware or software error, this outage will affect all such customers. Similarly, if the database is upgraded to meet the needs of one customer, all customers will be unavailable during the upgrade process. Such maintenance timeframes are often lengthy due to the size of the shared database.

[0066] In contrast, the multi-instance architecture provides each customer with its own database on a dedicated compute instance. This prevents the mixing of customer data and allows for independent management of each instance. For example, if one customer's instance goes down due to an error or upgrade, other compute instances remain unaffected. Because each database contains data for only one customer, maintenance downtime is limited. Furthermore, the simpler design of the multi-instance architecture allows redundant copies of each customer's database and instance to be deployed geographically diversified. This promotes high availability and allows for the migration of a live version of a customer's instance when failure detection or maintenance is performed.

[0067] In some embodiments, the remote network management platform 320 may include one or more central instances controlled by the entity operating the platform. Similar to compute instances, the central instances may include several application and database nodes deployed on several physical server devices or virtual machines. Such a central instance may function as a repository for a specific configuration of data that may be shared by compute instances, as well as at least some of them. For example, a central instance may contain definitions of common security threats that may occur on compute instances, software packages commonly found on compute instances, and / or an application store for applications deployable to compute instances. Compute instances may communicate with the central instance through a clearly defined interface to obtain this data.

[0068] To efficiently support multiple computing instances, the remote network management platform 320 may configure multiple such instances to run on a single hardware platform. For example, if the aPaaS system is running on a server cluster such as server cluster 200, it may run virtual machines that allocate varying amounts of computing, storage, and communication resources to instances. However, full virtualization of server cluster 200 is not required, and instances may be isolated by other mechanisms. In some examples, each instance may have a dedicated account and one or more dedicated databases on server cluster 200. Alternatively, computing instances such as computing instance 322 may span multiple physical devices.

[0069] In some cases, a single server cluster of the remote network management platform 320 may support multiple independent enterprises. Furthermore, as described below, the remote network management platform 320 may comprise multiple server clusters deployed in geographically diverse data centers to facilitate load balancing, redundancy, and / or high availability.

[0070] C. Public Cloud Network The public cloud network 340 may be remote server equipment (e.g., multiple server clusters such as server cluster 200) available for outsourced computing, data storage, communications, and service hosting operations. These servers may be virtualized (i.e., virtual machines). Examples of the public cloud network 340 include AMAZON WEB SERVICES® and MICROSOFT® AZURE®. Similar to the remote network management platform 320, multiple server clusters supporting the public cloud network 340 may be deployed in geographically diverse locations for load balancing, redundancy, and / or high availability.

[0071] The managed network 300 may use one or more public cloud networks 340 to deploy applications and services to its clients and customers. For example, if the managed network 300 provides an online music streaming service, the public cloud network 340 may store the music files and provide a web interface and streaming functionality. In this way, the company in the managed network 300 does not need to build and maintain its own servers for these operations.

[0072] The remote network management platform 320 may include modules that, through integration with the public cloud network 340, expose its internal virtual machines and managed services to the managed network 300. These modules may enable users to request virtual resources, discover allocated resources, and report flexibly to the public cloud network 340. To establish this functionality, users of the managed network 300 may first create an account in the public cloud network 340 and request a set of relevant resources. The user may then enter their account information into an appropriate module of the remote network management platform 320. These modules may then automatically discover the manageable resources for the account and provide usage, performance, and billing-related reports.

[0073] D. Communications support and other operations Internet 350 may represent a portion of the global internet. However, Internet 350 may also represent different types of networks, such as private wide-area or local area packet-switched networks.

[0074] Figure 4 further illustrates the communication environment between the managed network 300 and the compute instance 322, and introduces additional features and alternative embodiments. In Figure 4, all or part of the compute instance 322 is replicated in both data centers 400A and 400B. These data centers may be geographically separated from each other, possibly in different cities or countries. Each data center is equipped with the managed network 300 as well as support facilities to facilitate communication with remote users.

[0075] In data center 400A, network traffic to external devices flows through VPN gateway 402A or firewall 404A. VPN gateway 402A may peer with VPN gateway 412 of managed network 300 using a security protocol such as Internet Protocol Security (IPSEC) or Transport Layer Security (TLS). Firewall 404A may be configured to allow access from legitimate users such as user 414 and remote user 416, and to deny access from unauthorized users. Firewall 404A allows these users to access compute instance 322 and optionally other compute instances. Load balancer 406A may be used to distribute traffic among one or more physical or virtual server devices hosting compute instance 322. Load balancer 406A can simplify user access by hiding the internal configuration of data center 400A (e.g., compute instance 322) from client devices. For example, if the compute instance 322 includes multiple physical or virtual computer devices that share access to multiple databases, the load balancer 406A may distribute network traffic and processing tasks among these computer devices and databases so that no computer device or database is significantly busier than others. In some embodiments, the compute instance 322 may include a VPN gateway 402A, a firewall 404A, and a load balancer 406A.

[0076] Data center 400B may have its own version of the components of data center 400A. Therefore, VPN gateway 402B, firewall 404B, and load balancer 406B may perform the same or similar operations as VPN gateway 402A, firewall 404A, and load balancer 406A, respectively. Furthermore, computing instances 322 may exist simultaneously in data centers 400A and 400B through real-time or near-real-time database replication and / or other operations.

[0077] As shown in Figure 4, data centers 400A and 400B can facilitate redundancy and high availability. In the configuration of Figure 4, data center 400A is active and data center 400B is passive. Therefore, data center 400A serves all traffic to managed network 300, while the version of compute instance 322 in data center 400B is updated in near real-time. Other configurations, such as a configuration in which both data centers are active, may be supported.

[0078] If data center 400A experiences any failure or becomes unavailable to users, data center 400B can take over as the active data center. For example, a Domain Name System (DNS) server that associates the domain name of compute instance 322 with one or more Internet Protocol (IP) addresses of data center 400A may reassociate the domain name with one or more IP addresses of data center 400B. After this reassociation is complete (which is thought to take less than a second or a few seconds), users can access compute instance 322 through data center 400B.

[0079] Figure 4 also shows a possible configuration of the managed network 300. As mentioned above, the proxy server 312 and user 414 can access the compute instance 322 through the firewall 310. The proxy server 312 can also access the configuration item 410. In Figure 4, the configuration item 410 may represent any or all of the client device 302, server device 304, router 306, and virtual machine 308, any applications or services running on them, as well as the relationships between devices, applications, and services. Therefore, the term "configuration item" may be an abbreviation representing any physical or virtual device, any application or service that can be remotely discovered or managed by the compute instance 322, or the relationships between discovered devices, applications, and services. The configuration item may be represented in the configuration management database (CMDB) of the compute instance 322.

[0080] As described above, VPN gateway 412 may provide a dedicated VPN to VPN gateway 402A. Such a VPN may be useful when there is a large amount of traffic between managed network 300 and compute instance 322, or when security policies suggest or require the use of a VPN between these sites. In some embodiments, any equipment in managed network 300 and / or compute instance 322 that communicates directly over the VPN is assigned a public IP address. Other equipment in managed network 300 and / or compute instance 322 may be assigned a private IP address (for example, an IP address selected from the ranges 10.0.0.0 to 10.255.255.255 or 192.168.0.0 to 192.168.255.255, respectively, abbreviated as subnets 10.0.0.0 / 8 and 192.168.0.0 / 16).

[0081] IV. Discovery of Exemplary Devices, Applications, and Services The remote network management platform 320 may first determine the devices, applications, and services present in the managed network 300, their configurations and operating states, the applications and services they provide, and the relationships between discovered devices, applications, and services, in order to manage the devices, applications, and services of the managed network 300. As described above, each device, application, service, and relationship may be referred to as a configuration item. The process of defining the configuration items within the managed network 300 is called discovery, which can be facilitated, at least partially, by the proxy server 312.

[0082] For the purposes of this specification, “Application” may represent one or more processes, threads, programs, client modules, server modules, or any other software running on a device or group of devices. “Service” may represent an advanced function provided by multiple applications running on one or more devices that work together. For example, an advanced web service may include multiple web application server threads running on one device that access information from a database application running on another device.

[0083] Figure 5A is a logical depiction of how configuration items may be detected and how the detected configuration items and related information may be stored. For simplicity, the remote network management platform 320, the public cloud network 340, and the internet 350 are not shown.

[0084] In Figure 5A, the CMDB 500 and task list 502 are stored in the compute instance 322. The compute instance 322 may send a discovery command to the proxy server 312. In response, the proxy server 312 may send probes to various devices, applications, and services in the managed network 300. These devices, applications, and services may send responses to the proxy server 312, which may then provide information about the discovered configuration items to the CMDB 500 for storage. The configuration items stored in the CMDB 500 represent the environment of the managed network 300.

[0085] Task list 502 represents a list of actions that the proxy server 312 will perform on behalf of the computation instance 322. When detection occurs, input is made to task list 502. The proxy server 312 repeatedly queries task list 502, retrieves the next task from it, and executes this task until task list 502 becomes empty or another termination condition is met.

[0086] To facilitate detection, the proxy server 312 may be configured with information about one or more subnets in the managed network 300 that are reachable by the proxy server 312. For example, the proxy server 312 may be given the IP address range 192.168.0 / 24 as a subnet. The compute instance 322 may then store this information in the CMDB 500 and place tasks in the task list 502 for the detection of devices at each of these addresses.

[0087] Furthermore, Figure 5A shows the devices, applications, and services in the managed network 300 as configuration items 504, 506, 508, 510, and 512. As described above, these configuration items represent a set of physical and / or virtual devices (e.g., client devices, server devices, routers, or virtual machines), applications running on them (e.g., web servers, email servers, databases, or storage arrays), the relationships between them, and services that include multiple individual configuration items.

[0088] Placing a task in task list 502 can trigger or initiate detection by the proxy server 312. Alternatively or additionally, detection may be triggered manually or automatically based on a trigger event (for example, detection may start automatically once a day at a specific time).

[0089] Generally, detection can involve four logical stages: scanning, classification, identification, and exploration. Each stage of detection includes various types of probe messages that the proxy server 312 sends to one or more devices in the managed network 300. Responses to these probes may be received and processed by the proxy server 312, and their respective representations may be sent to the CMDB 500. In this way, each stage can detect and store more configuration items in the CMDB 500.

[0090] During the scanning phase, the proxy server 312 may determine the general type of device by probing each IP address within a specified range of IP addresses for open Transmission Control Protocol (TCP) and / or User Datagram Protocol (UDP) ports. The presence of such open ports at an IP address indicates that a particular application is running on the device assigned to that IP address, thereby allowing identification of the operating system used by that device. For example, if TCP port 135 is open, the device is likely running the WINDOWS® operating system. Similarly, if TCP port 22 is open, the device is likely running a UNIX® operating system such as LINUX®. If UDP port 161 is open, the device may be identifiable separately through Simple Network Management Protocol (SNMP). Other possibilities exist. Once the presence of a device and its open ports at a particular IP address is detected, these configuration items are stored in the CMDB 500.

[0091] During the classification stage, the proxy server 312 may further probe each detected device to determine its operating system version. The probes used for a particular device are based on the information collected about that device during the scanning stage. For example, if a device with TCP port 22 open is found, a set of UNIX®-specific probes may be used. Similarly, if a device with TCP port 135 open is found, a set of WINDOWS®-specific probes may be used. In either case, a suitable set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to log on to or access information from a particular device. For example, if TCP port 22 is open, the proxy server 312 may be instructed to initiate a Secure Shell (SSH) connection to the particular device and retrieve information about the operating system on the device from a specific location in the file system. Based on this information, the operating system may be determined. For example, UNIX® devices with TCP port 22 open are classified as AIX®, HPUX, LINUX®, MACOS®, or SOLARIS®. This classification information may be stored in CMDB500 as one or more configuration items.

[0092] During the identification stage, the proxy server 312 may determine specific details about the classified device. The probes used in this stage may be based on information collected about the specific device during the classification stage. For example, if the device is classified as LINUX®, a set of LINUX®-specific probes may be used. Similarly, if the device is classified as WINDOWS® 2012, a set of WINDOWS® 2012-specific probes may be used. As in the classification stage, a suitable set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to read information from the specific device, such as basic input / output system (BIOS) information, serial number, network interface information, media access control addresses assigned to these network interfaces, and IP addresses used by the specific device. This identification information may be stored in the CMDB 500 as one or more configuration items.

[0093] During the discovery phase, the proxy server 312 may determine additional details regarding the operating status of the classified devices. The probes used in this phase may be based on information collected about specific devices during the classification and / or identification phases. In this case as well, a suitable set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to read additional information from the specific device, such as processor information, memory information, and a list of running processes (applications). Again, the discovery information may be stored in the CMDB 500 as one or more configuration items.

[0094] When performing discovery on network devices such as routers, SNMP may be used. As an alternative to or addition to determining a list of running processes or other application-related information, discovery may involve the router determining known additional subnets and the operational status of the router's network interfaces (e.g., active, inactive, queue length, number of dropped packets, etc.). The IP addresses of the additional subnets may be candidates for other discovery procedures. For this reason, discovery may proceed iteratively or recursively.

[0095] Once detection is complete, snapshot representations of each detected device, application, and service become available in CMDB500. For example, after detection, it may store the operating system versions, hardware configurations, and network configuration details of client devices, server devices, and routers in the managed network 300, as well as the applications running on them. This collected information can be presented to the user in various ways, allowing them to verify the hardware configuration and operating status of devices, as well as the characteristics of services spanning multiple devices and applications.

[0096] Furthermore, CMDB500 may include entries relating to dependencies and relationships between configuration items. More specifically, applications running on a particular server device, as well as services that depend on this application, may be represented in CMDB500 in this way. For example, suppose a database application runs on a server device, and this database application is used for a new employee training service as well as a payroll service. Therefore, if the server device is shut down for maintenance, the employee training service and the payroll service will clearly be affected. Similarly, dependencies and relationships between configuration items can represent services that would be affected if a particular router fails.

[0097] Generally, dependencies and relationships between configuration items can be displayed in a web-based interface and represented hierarchically. Therefore, adding, modifying, or deleting such dependencies and relationships can be achieved through this interface.

[0098] Furthermore, users of Managed Network 300 can develop workflows that enable the execution of specific coordinated actions across multiple detected devices. For example, an IT workflow could allow a user to change the common administrator password for all detected LINUX® devices in a single operation.

[0099] To enable the detection described above, the proxy server 312, CMDB 500, and / or one or more authentication information stores may be configured with authentication information for one or more of the devices to be detected. The authentication information may include any type of information necessary to access the device. This may include user ID / password pairs, certificates, etc. In some embodiments, this authentication information may be stored in an encrypted field of CMDB 500. The proxy server 312 may include a decryption key for this authentication information so that logon to or access to the devices to be detected using the authentication information is possible.

[0100] Figure 5B shows the detection process as a flowchart. In block 520, the task list in the computation instance is populated with, for example, various IP addresses. In block 522, the scan phase occurs. The proxy server probes the IP addresses of devices using these IP addresses and attempts to determine the operating systems running on these devices. In block 524, the classification phase occurs. The proxy server attempts to determine the version of the operating system of the detected devices. In block 526, the identification phase occurs. The proxy server attempts to determine the hardware and / or software configuration of the detected devices. In block 526, the exploration phase occurs. The proxy server attempts to determine the operational state and the applications running on the detected devices. In block 530, separate editing of configuration items representing the detected devices and applications may occur. This editing can be automated and / or performed manually.

[0101] The blocks shown in Figure 5B are examples. The detection may be a highly configurable procedure, with the number of steps being either increased or decreased, and the operation of each step may differ. In some cases, one or more steps may be customized or deviate from the exemplary description above.

[0102] Thus, a remote network management platform can discover and list the hardware, software, and services deployed and provided on a managed network. As mentioned above, this data may be stored as configuration items in the CMDB of the relevant compute instance. For example, individual hardware components (e.g., computer equipment, virtual servers, databases, routers, etc.) may be represented as hardware configuration items, while applications installed and / or run on them may be represented as software configuration items.

[0103] The relationships between software configuration items installed or executed within hardware configuration items can take various forms, such as hosting, execution, or dependency. For example, a database application installed on a server device may indicate that it is hosted on the server device by having a "hosting" relationship with it. In some embodiments, a server device may indicate that it is used by a database application by having a "use" relationship with it. These relationships may be automatically discovered using the detection procedures described above, but they can also be configured manually.

[0104] Furthermore, the relationship between a service and one or more software configuration items can take various forms. For example, a web service may include web server software configuration items and database application software configuration items, each installed on different hardware configuration items. While a web service may have a “dependence” relationship with both of these software configuration items, the software configuration items have a “usage” relationship with the web service. A service may not be determined entirely by discovery procedures, but instead may rely on service mapping (e.g., probing configuration files and / or performing network traffic analysis to determine service level relationships between configuration items) and, if applicable, some degree of manual configuration.

[0105] Relevant information, regardless of how it is obtained, can be beneficial to the operation of a managed network. In particular, IT personnel can quickly determine where a specific software application is deployed and the configuration items that make up the service. This allows them to quickly pinpoint the root cause of service outages or degradation. For example, if two different services are slow to respond, a query to the CMDB (among many possible actions) can determine that the root cause is high processor utilization of the database applications used by both services. This allows IT personnel to address the database application without wasting time examining the health and performance of other configuration items that make up the service.

[0106] V. Exemplary Software Applications Figure 6 shows an exemplary configuration of a software application. The software application 600 may be a native software application and / or a software application accessible by a web browser, configured, for example, to run on a specific mobile platform. Specifically, the software application 600 may comprise a navigation stack controller 602, a refresh controller 604, and a network component 634. These components of the software application 600 may operate to refresh old UI screens before the old UI screens of the software application 600 are requested and / or displayed by the UI.

[0107] Specifically, the software application 600 may be configured to provide a plurality of UI screens, each of which may contain one or more corresponding UI components. Optionally, the plurality of UI screens may be organized as one or more tabs, each defining a corresponding group consisting of one or more UI screens. The plurality of UI screens and their corresponding UI components may provide the intended functionality of the software application 600, which may vary from embodiment to embodiment, upon user viewing and / or interaction. The software application 600 may request one of the plurality of UI screens from a server device based on and / or in response to user input, and the server device may be configured to generate the requested UI screen and send it to the software application 600. The software application 600 may also be configured to cache UI screens received from the server device.

[0108] Data dependencies can exist between different UI screens among multiple UI screens. That is, each of the multiple UI screens may depend on (for example, use and / or display) the same data and / or UI components. Therefore, since modifications to specific data and / or specific UI components performed by the first UI screen may affect the second UI screen, if the second UI screen is not regenerated and sent to the software application 600 after the server equipment has completed the modifications, the second UI screen will display an older version of the specific data and / or specific UI component.

[0109] The server equipment may generate updated versions of all UI screens affected by a modification to specific data and / or specific UI components (or all previously displayed UI screens affected by this modification) and provide these updated versions of UI screens to the software application 600. However, such an approach may be inefficient and wasteful because the updated versions of these UI screens may not be displayed by the software application 600. For example, the user may request the display of other UI screens and / or the termination of the usage session as an alternative, unnecessarily consuming the server equipment's computing resources and communication bandwidth between the software application 600 and the server equipment.

[0110] Therefore, the navigation stack controller 602, refresh controller 604, and network component 634 may, alternatively, operate to perform predictive and gradual refresh and / or update of older UI screens of the software application 600. Specifically, the navigation stack controller 602 may be configured to determine a set of UI screens navigated by the UI of the software application 600. These UI screens navigated by the UI may include, for example, UI screens requested and / or displayed by the UI during a particular usage session and / or time window, and are therefore cached in the memory used by the software application 600.

[0111] In the example shown in Figure 6, the multiple UI screens of the software application 600 may be arranged as multiple tabs, represented by tabs 610 to 620 (i.e., tabs 610 to 620). For this reason, the navigation stack controller 602 may be configured to track one or more UI screens belonging to each of the tabs 610 to 620 that have been navigated by the UI. In some embodiments, the navigation stack controller 602 may be configured to generate an ordered list (e.g., a stack) of one or more UI screens for each of the tabs 610 to 620, based on the order in which the one or more UI screens were navigated.

[0112] For example, for tab 610, the ordered list could include, in reverse order, the current UI screen 618, UI screen 616 (current-1), and UI screens 614 (current-2) through 612 (current-N) (i.e., UI screens 612 through 618 as a whole). Thus, UI screens 612 through 618 can form a stack, with UI screen 612 (current-N) at the bottom of this stack, indicating that this UI screen 612 was the first to be displayed under tab 610, and the current UI screen 618 at the top of this stack, indicating that the current UI screen 618 was the most recently displayed and / or currently displayed under tab 610. Similarly, for tab 620, the ordered list could include, in reverse order, form 628, web view 626, and list 624 through home screen 622 (i.e., UI screens 622 through 628 as a whole).

[0113] Thus, concrete examples of UI screens include, among many possibilities, home screens, lists, web views, and forms, as well as overlays, modal windows, cards, and / or tables. Concrete examples of UI components that make up a UI screen include, among many possibilities, individual data fields, data entries, buttons, text fields, checkboxes, radio buttons, dropdowns, and / or icons. Generally, a tab can consist of a group of one or more UI screens that can be displayed at different times using the same area of ​​the UI, and / or at the same time using different areas of the UI. A UI screen can consist of one or more UI components that define the visual appearance and / or functionality of that UI screen. Depending on the context, a UI element may be considered a screen (for example, a direct subset of a tab) or a component (for example, a direct subset of a UI screen). In some cases, the UI screens of a given tab may be related to each other. For example, the UI screens of a given tab may be able to perform actions on the same or similar data and / or related functions. Therefore, in some cases, the UI screens of a given tab may be data-dependent on each other, while the UI screens of different tabs may be data-independent. In other cases, data dependencies may exist between tabs.

[0114] The refresh controller 604 may be configured to (i) track the age of several previously displayed UI components identified by the navigation stack controller 602, and (ii) determine the next UI screen 632 that has been previously displayed, is old, and is expected to require a refresh for re-navigation and / or re-display. Specifically, the refresh controller 604 may be configured to generate and update old sets 630-640 (i.e., old sets 630-640). Old set 630 may correspond to tab 610, old set 640 may correspond to tab 620, and each other old set (indicated by ellipses separating old sets 630 and 640) may be associated with a corresponding other tab (indicated by ellipses separating tabs 610 and 620).

[0115] In the example shown in Figure 6, the old set 630 indicates that UI screen 616 (currently -1) and UI screens 614 to 612 (currently -2) are old, while the old set 640 is empty. Therefore, the old set 630 indicates that the current UI screen 618 is the latest, and the old set 640 indicates that UI screens 622 to 628 are the latest. Thus, in some embodiments, each old set among the old sets 630 to 640 may store the representation of each UI screen when it is old, but as shown in Figure 6, it may not include the representation of each UI screen when it is the latest. In other embodiments, each old set among the old sets 630 to 640 may represent each UI screen of its corresponding tab and store an indicator of whether each UI screen is old or new.

[0116] The modification action controller 638 of the network component 634 may be configured to notify the refresh controller 604 of the timing of modifications made via a UI screen. In some embodiments, the modification may be referred to as a write-back operation, as it may include writing back the updated data to the server equipment. Specifically, the modification action controller 638 may be configured to generate and provide a modification notification 642 to the refresh controller 604. The modification notification 642 may indicate the UI screen from which the modification of the underlying data was requested. For example, the modification action controller 638 may be configured to monitor queries added to the query queue 636 and identify (i) queries that include a request to perform an operation involving modification of the underlying data, and (ii) the corresponding UI screen from which these queries originate. The modification action controller 638 may be configured to determine whether a query requests modification of the underlying data, for example, based on the address to which the query is headed and / or the content of the request.

[0117] If an action occurs that affects the first UI screen as a result of interaction with the UI components of the second UI screen, the refresh controller 604 may be configured to mark the first UI screen as outdated. For example, this action may include changes to the data and / or UI components displayed by the first UI screen. Therefore, the outdated status of the first UI screen may be based on the fact that the first and second UI screens share data dependencies, which may affect the content and / or visual appearance of both UI screens.

[0118] In some embodiments, the refresh controller 604 may be configured to treat all UI screens of a given tab as sharing data dependencies. Therefore, if a modification is made using one of several UI screens of a given tab, the refresh controller 604 may mark all previously displayed UI screens of the given tab as outdated. Thus, for example, if a modification is made using the current UI screen 618, UI screens 612 (current-N) through 616 (current-1) may be marked as outdated, as shown in Figure 6.

[0119] In particular, UI screens of a given tab that have not been previously navigated may not be marked as outdated because the representation of these previously unviewed screens may not be cached by the software application 600. Therefore, if one of these previously unviewed UI screens is requested, such a UI screen will be retrieved from the server device, which will generate the latest version reflecting any prior modifications to the underlying data. Furthermore, the UI screen being modified (for example, the current UI screen 618) may not be marked as outdated because the execution of this modification involves communication between the software application 600 and the server device, and the server device may provide the software application 600 with an updated version of this UI screen in response to a request to perform the modification.

[0120] In another embodiment, the refresh controller 604 may be configured to treat all UI screens on all tabs as sharing data dependencies. Therefore, if a modification is made using one of the multiple UI screens of the software application 600, the refresh controller 604 may mark all previously displayed UI screens across all tabs as outdated. In such an embodiment, for example, if a modification is made using the current UI screen 618, UI screens 612 (current-N) through 616 (current-1) on tab 610, UI screens 622 through 628 on tab 620, and any other previously displayed UI screens on any other tab may be marked as outdated.

[0121] In other embodiments, the refresh controller 604 may have access to a dependency map showing shared data dependencies between multiple UI screens of the software application 600. The dependency map may be alternatively referred to as a dependency graph and / or dependency model, and may be obtained, among many other possibilities, for example, as part of the installation of the software application 600 and / or during the retrieval of one or more UI screens from a server device.

[0122] A dependency map can provide screen-level dependencies and / or component-level dependencies. For example, a screen-level dependency map might show, for each of the multiple UI screens of the software application 600, zero or more other UI screens that may be affected by modifications made by any UI component of that UI screen. In this example, the zero or more UI screens affected by modifications made by the first UI screen may be different from the zero or more UI screens affected by modifications made by the second UI screen. In another example, a component-level dependency map might show, for each of the multiple UI components included as part of the multiple UI screens of the software application 600, zero or more other UI components that may be affected by modifications made by that UI component. In this example, the zero or more UI components affected by modifications made using the first UI component may be different from the zero or more UI components affected by modifications made using the second UI component.

[0123] Each of the different methods described above for determining old tabs may be associated with different trade-offs, some of which may become more pronounced as the number of UI screens and / or UI components in the software application 600 increases. For example, a component-level dependency map may allow for accurate determination of old UI screens, but it may use more storage and / or processing resources than a screen-level dependency map and / or tab-based method. Conversely, a screen-level dependency map and / or tab-based method may retrieve updated versions of UI components that are not affected by a given modification, but it may use less memory and / or processing resources. The specific method for determining old tabs may be a user-controllable and / or programmer-controllable parameter of the software application 600, and may be selected based on, among many possibilities, the availability of memory and / or computing resources, the structure of the software application 600, and / or the available communication bandwidth between the software application 600 and the server equipment.

[0124] The refresh controller's predictive model 608 may be configured to determine the next UI screen 632. Specifically, the next UI screen 632 may be selected from older sets 630-640, and may be expected to reappear after the current UI screen currently displayed by the software application 600 (for example, the current UI screen 618). In some cases, the next UI screen 632 may be expected to reappear immediately after the current UI screen. In other cases, after the current UI screen, one or more intermediate UI screens that have not been previously navigated may be requested before the reappearance of the next UI screen 632 is requested. The next UI screen 632 may represent, for example, one of the UI screens 612 (current-N) to UI screens 616 (current-1).

[0125] The next UI screen 632 may be provided to the query queue 636 of the network component 634, which may cause the server equipment to have the network component 634 retrieve an updated version of the next UI screen 632. The query queue 636 is already shown as containing the UI screen 650, which may have been requested based on, for example, user interaction with the software application 600, and / or may have been navigated to in the past. By adding the next UI screen 632 to the query queue 636, the software application 600 may be configured to at least request, and possibly retrieve, an updated version of the next UI screen 632 before user interaction indicates re-navigation to the next UI screen 632. Thus, the display of an older version of the next UI screen 632 can be avoided because the updated version of the next UI screen 632 is requested and / or anticipated before the next UI screen 632 is displayed again.

[0126] In some cases, adding a user-initiated request for a UI screen other than the next UI screen 632 to the query queue 636 may take precedence over the next UI screen 632, causing the next UI screen 632 to be removed from the query queue 636, and / or canceling the query for the next UI screen 632. For example, upon receiving a query in response to a user-initiated request by the server equipment, the server equipment may avoid and / or terminate the generation of an updated version of the next UI screen 632. This would cause the next UI screen 632 to remain outdated, for example, until it is selected again for preemption.

[0127] In some embodiments, the forward-looking prediction model 608 may be configured to identify the next UI screen 632 based on each ordered list of previously displayed UI screens maintained in each of the tabs 610-620. Specifically, the forward-looking prediction model 608 may be configured to select the UI screen preceding the currently displayed UI screen in the corresponding ordered list of the current tab as the next UI screen 632. For example, if the current UI screen 618 is displayed by the software application 600, UI screen 616 (current-1) may be selected as a candidate for the next UI screen 632. Based on the selection of UI screen 616 (current-1) as a candidate for the next UI screen 632, the forward-looking prediction model 608 may be configured to determine whether UI screen 616 (current-1) is old by using the old set 630. Based on the determination that UI screen 616 (current-1) is old, it may be selected as the next UI screen 632.

[0128] In another example, if UI screen 616 (current-1) is currently displayed by software application 600, UI screen 614 (current-2) will be selected as the next UI screen 632. In yet another example, if form 628 is currently displayed by software application 600, web view 626 will not be selected as the next UI screen 632 because web view 626 is not part of the old set 640. However, if web view 626 is part of the old set 640, it will be selected as the next UI screen 632. Thus, anticipating older UI screens can be based on the expectation that the user may re-navigate past UI screens in the reverse order of the order in which they were first requested.

[0129] In another embodiment, the predictive model 608 may be configured to select the next UI screen based on the workflow model 606. The workflow model 606 may define the sequence in which the UI screens of the software application 600 are displayed, as well as the sequence in which the UI screens of the software application 600 are displayed, as empirically observed. For example, the workflow model 606 may represent each UI screen of the software application as a node, and the edges / arrows between the nodes may indicate the most likely sequence of actions through the node. Thus, the predictive model 608 may be configured in the workflow model 606 to select the UI screen that follows the currently displayed UI screen as the next UI screen 632. If multiple edges / arrows included in a node point to different subsequent nodes, each edge / arrow may be associated with a value indicating the likelihood of following that edge / arrow. Thus, the predictive model 608 may be configured in the workflow model 606 to select the UI screen that is most likely to follow the currently displayed UI screen as the next UI screen 632. In some cases, the forward-looking prediction model 608 may be configured in the workflow model 606 to select two or more UI screens that follow the currently displayed UI screen as the next UI screen 632.

[0130] In other embodiments, the predictive model 608 may be configured to determine the next UI screen 632 based on multiple inputs. For example, the predictive model 608 may include a machine learning model, such as an artificial neural network, trained to determine the next UI screen 632 based on multiple inputs. The multiple inputs may include, among many other possible inputs, an ordered list of tabs 610-620, old sets 630-640, the workflow model 606, and / or the most recently modified UI component. Thus, the machine learning model can consider the navigation history, the intended use and / or empirical use of the software application 600, and / or the cause of data modification when determining the next UI screen 632.

[0131] VI. Detection and anticipation of exemplary old UI screens Figures 7A, 7B, and 7C are message flow diagrams illustrating the operation of GUI 702, software application 600, and server application 700 involved in anticipating the old UI screen. Specifically, GUI 702 may be provided by a client computer device on which software application 600 is running, and may be configured to display the UI screen of software application 600. Server application 700 may be run by a server device responsible for hosting backend services and / or providing them to software application 600. In some embodiments, server application 700 may be provided by a compute instance of remote network management platform 320, and / or GUI 702 and software application 600 may be located within a managed network 300.

[0132] Figure 7A illustrates the generation of a navigation stack based on navigation between UI screens of the software application 600 and the associated operations. Specifically, GUI 702 may be configured to send a request for a particular UI screen to network component 634, as indicated by arrow 706. The particular UI screen requested by arrow 706 may not have been previously navigated to and / or displayed by the software application 600, and therefore its representation may not be cached by the software application 600. Based on the receipt of the request at arrow 706, and / or in response to the receipt of the request at arrow 706, network component 634 may be configured to send a request / query for a particular UI screen to server application 700, as indicated by arrow 708. Based on the receipt of the request / query at arrow 708, and / or in response to the receipt of the request / query at arrow 708, server application 700 may be configured to generate a particular UI screen, as indicated by block 710. Based on the generation of a specific UI screen in block 710, and / or in response to the generation of a specific UI screen in block 710, the server application 700 may be configured to provide a specific UI screen to the network component 634, as indicated by arrow 712.

[0133] Based on and / or in response to the reception of a specific UI screen at arrow 712, network component 634 may be configured to provide the specific UI screen to GUI 702 as indicated by arrow 714. Based on and / or in response to the reception of a specific screen at arrow 714, GUI 702 may be configured to display the specific UI screen as indicated by block 716.

[0134] Furthermore, based on and / or in response to the reception of a specific UI screen at arrow 712, the network component 634 may be configured to provide the navigation stack controller 602 with an indicator to add the specific UI screen to the navigation stack, as shown by arrow 718. Based on and / or in response to the indicator at arrow 718, the navigation stack controller 602 may be configured to update the navigation stack, as shown by block 720. For example, in embodiments where UI screens are grouped as tabs, the navigation stack controller 602 may be configured to track a set of UI screens displayed within a tab by updating the navigation stack of the tab to which a particular UI screen belongs. Optionally, the navigation stack controller 602 may also maintain, as an addition or alternative, (i) a global navigation stack that tracks UI screens previously displayed independently of the tab to which a UI screen belongs, and / or (ii) a tab navigation stack that tracks the order in which different tabs were displayed by accessing one or more UI screens.

[0135] Based on and / or in response to an update to the navigation stack in block 720, the navigation stack controller 602 may be configured to provide the updated navigation stack to the refresh controller 604, as indicated by arrow 722. Based on and / or in response to the receipt of the updated navigation stack in arrow 722, the refresh controller 604 may be configured to update its own representation of the navigation stack, as indicated by block 724. For example, the refresh controller 604 may be configured to provide the refresh controller 604 with a pool of candidate UI screens that may be marked as obsolete in future modifications by adding specific UI screens to their corresponding obsolete set and marking them as up-to-date (i.e., not obsolete).

[0136] In some embodiments, the actions of arrow 722 and block 724 may be omitted and / or performed later. For example, the refresh controller 604 may be configured to retrieve an updated navigation stack from the navigation stack controller 602 in the event of a future modification. Thus, each old set of refresh controllers 604 may be used to represent an old UI screen, but may not be used to represent a UI screen that may become old but is not yet old.

[0137] Based on and / or in response to the reception of a specific UI screen at arrow 712, the network component 634 may be further configured to store the specific UI screen in the memory of the client computer device. Thus, if a request to redisplay the specific UI screen is later received from GUI 702, the specific UI screen can be provided to GUI 702 without querying the server application 700. Additional UI screens may be acquired through one or more iterations of the operation of arrows 706 to block 726, as shown by arrow 704, resulting in a larger navigation stack and more UI screens being stored in memory. A specific UI screen stored in memory may become outdated as a result of modifications resulting from interactions with other UI screens.

[0138] Figure 7B illustrates the determination of the old UI screen and related operations based on interactions performed by the UI screens of the software application 600. Specifically, GUI 702 may be configured to display the current UI screen, as shown in block 728. The current UI screen may be any of the multiple UI screens provided by the software application 600 and may be designated as "current" in that it is currently displayed by GUI 702. Based on the display of the current screen in block 728 and the interaction with its UI components, and / or in response to the display of the current screen in block 728 and the interaction with its UI components, GUI 702 may be configured to provide the network component 634 with a representation of the interaction with the UI components of the current UI screen, as shown by arrow 730.

[0139] Based on and / or in response to the reception of the interaction at arrow 730, network component 634 may be configured to send a request / query to server application 700 to perform the action indicated by the interaction, as shown by arrow 732. Based on and / or in response to the reception of the request / query at arrow 732, server application 700 may be configured to perform the action, as shown by block 734. Performing the action may include modifying data maintained by server application 700 on behalf of software application 600. Thus, at least a portion of the current UI screen, and possibly a portion of one or more other UI screens, may be affected by the modification. This action could be based, among many other possibilities, on a user editing a text box, selecting an option from a dropdown menu, and / or checking or unchecking a checkbox.

[0140] Therefore, based on and / or in response to the execution of the action in block 734, the server application 700 may be configured to generate an updated version of the current UI screen, as shown in block 736. Based on and / or in response to the generation of the updated version of the current UI screen in block 736, the server application 700 may be configured to send the updated version of the current UI screen to the network component 634, as shown by arrow 738. In particular, at this point, updated versions of one or more other UI screens affected by the modification may not be generated. This is because the generation and / or transmission of these updated versions would be wasted unless they are actually requested to be displayed by the GUI 702 after being received by the software application 600.

[0141] Based on and / or in response to the reception of an updated version of the current UI screen at arrow 738, network component 634 may be configured to provide the updated version of the current UI screen to GUI 702, as indicated by arrow 740. Based on and / or in response to the reception of an updated version of the current UI screen at arrow 740, GUI 702 may be configured to display the updated version of the current UI screen, as indicated by block 742. This may cause GUI 702 to provide visual feedback indicating the success of the action performed by the interaction at arrow 730.

[0142] Furthermore, based on and / or in response to the reception of an updated version of the current UI screen at arrow 738, network component 634 may be configured to store the updated version of the current UI screen in the memory of the client device, as shown in block 744. Based on and / or in response to the reception of an updated version of the current UI screen at arrow 738, network component 634 may be further configured to provide an indicator to the refresh controller 604 that the current UI screen has been updated based on an interaction, as shown in arrow 746. This indicator at arrow 746 may notify the refresh controller 604 that, as a result of successfully performing the action indicated by the interaction, the corresponding data has been corrected and, in some cases, one or more cached UI screens have become outdated.

[0143] Therefore, based on and / or in response to the reception of the indicator at arrow 746, the refresh controller 604 may be configured to update one or more old sets that it maintains based on updates to the current UI screen, as shown in block 748. The update of one or more old sets may be based on the actual and / or approximate dependencies of one or more UI screens with respect to data modified by the performance of the action shown by the interaction of arrow 730, as discussed with respect to Figure 6.

[0144] Figure 7C illustrates the operation associated with updating older UI screens by gradually anticipating updated versions. Specifically, the refresh controller 604 may be configured to determine the next UI screen in the navigation stack that is expected to be redisplayed, as shown in block 750. The operation in block 750 may be performed, for example, based on a change in the UI screen currently displayed by GUI 702, and / or in response to a change in the UI screen currently displayed by GUI 702. That is, the prediction of the next UI screen may be updated each time the user navigates to a different UI screen by GUI 702. The refresh controller 604 may also be configured to determine that GUI 702 has switched from displaying one UI screen to another, for example, based on a notification from network component 634, as shown by arrow 722.

[0145] Based on the determination of the next UI screen in block 750, and / or in response to the determination of the next UI screen in block 750, the refresh controller 604 may be configured to determine whether the next UI screen is old. In the example in Figure 7C, the refresh controller is shown to determine that the next UI screen is old, as shown in block 752. The next UI screen may be determined to be old if it is indicated as old by at least one set of old elements (for example, an old set of tabs to which the next UI screen belongs).

[0146] Based on the determination in block 752 that the next UI screen is outdated, and / or in response to the determination in block 752, the refresh controller 604 may be configured to send a request to the network component 634 to anticipate an updated version of the next UI screen, as indicated by arrow 754. Based on the receipt of the request in arrow 754, and / or in response to the receipt of the request in arrow 754, the network component 634 may be configured to send a request / query to the server application 700 for an updated version of the next UI screen, as indicated by arrow 756. Based on the receipt of the request / query in arrow 756, and / or in response to the receipt of the request / query in arrow 756, the server application 700 may be configured to generate an updated version of the next UI screen, as indicated by block 758. The updated version of the next UI screen may be based on and / or represent any modifications resulting from the execution of the action in block 736 of Figure 7B.

[0147] Based on the generation of an updated version of the next UI screen, and / or in response to the generation of an updated version of the next UI screen, the server application 700 may be configured to send the updated version of the next UI screen to the network component 634, as indicated by arrow 760. Based on the reception of the updated version of the next UI screen at arrow 760, and / or in response to the reception of an updated version of the current UI screen at arrow 760, the network component 634 may be configured to store the updated version of the next UI screen in the memory of the client device, as indicated by block 762.

[0148] Based on the reception and / or storage of the updated version of the next UI screen in arrow 760 and / or block 762, and / or in response to the reception and / or storage of the updated version of the next UI screen in arrow 760 and / or block 762, network component 634 may be configured to send an indicator to refresh controller 604 that the updated version of the next UI screen has been obtained, as indicated by arrow 772. Based on the reception of the indicator in arrow 772, and / or in response to the reception of the indicator in arrow 772, refresh controller 604 may be configured to update the old set based on the update to the next UI screen, as indicated by block 774. For example, refresh controller 604 may be configured to indicate that the next UI screen is no longer old by removing the next UI screen from the old set and / or modifying the representation of the next UI screen in the old set. This means that the next UI screen may not be preempted again until it becomes old by another modification performed by another UI screen.

[0149] GUI702 may be configured to provide network component 634 with a request for the next UI screen, as indicated by arrow 764. Based on the receipt of the request at arrow 764, and / or in response to the receipt of the request at arrow 764, network component 634 may be configured to provide GUI702 with an updated version of the next UI screen, as indicated by arrow 766. Based on the receipt of the updated version of the next UI screen at arrow 766, and / or in response to the receipt of the updated version of the next UI screen at arrow 766, GUI702 may be configured to display the updated version of the next UI screen, as indicated by block 768. Thus, GUI702 may display a version of the next UI screen that reflects modifications made in the past by the operation shown in Figure 7B, rather than displaying an older version of the next UI screen.

[0150] In the example shown in Figure 7C, the request at arrow 764 is shown as having been generated after block 762, but in other embodiments, the request at arrow 764 may have been generated after arrow 760 or between arrow 760 and block 762. That is, GUI 702 may have been used to request the next screen before the network component 634 retrieves the updated version. In such a case, anticipating the updated version of the next UI component can still be beneficial, because although the updated version of the next UI screen may appear to take a long time to load, GUI 702 can ultimately display the updated version rather than the old version of the next UI screen.

[0151] As indicated by arrow 770, the operation of blocks 750 to 768 may be repeated to anticipate updated versions of one or more subsequent UI screens. In particular, anticipating updated versions of UI screens can be considered stepwise, in that the software application 600 may request a refresh of, for example, one old UI screen at a time, rather than all old UI screens at once. This can reduce and / or eliminate the consumption of computational and / or communication resources related to refreshing old UI screens that are not ultimately redisplayed.

[0152] Furthermore, without the preemptive action shown in Figure 7C, GUI702 may instead display older versions of these subsequent UI screens. Such subsequent screens can be refreshed based on and / or in response to manual refresh requests accepted by GUI702, but the user may not know if a manual refresh is necessary. As a result, the user may end up using manual refresh when it is not necessary, which may result in wasted computation and / or communication resources, and / or ultimately lead to insufficient use of manual refresh by the user and operation based on outdated data.

[0153] VII. Exemplary Operation Figure 8 is a flowchart illustrating an exemplary embodiment. The process shown in Figure 8 may be executed by computer equipment such as computer equipment 100 and / or a cluster of computer equipment such as a server cluster 200. However, this process can also be executed by other types of equipment or equipment subsystems. For example, this process can be executed by a portable computer such as a laptop or tablet device and / or a software application 600.

[0154] The embodiment shown in Figure 8 can be simplified by removing one or more of the features shown therein. Furthermore, these embodiments may be combined with any of the features, aspects, and / or embodiments described in the above drawings or herein.

[0155] Block 800 may include determining multiple UI screens of a software application that are navigated by the UI of the software application.

[0156] Block 802 may include receiving interactions with UI components of the current UI screen among multiple UI screens via the UI.

[0157] Block 804 may include determining the next UI screen from among several UI screens that are expected to reappear after the current UI screen, based on the reception of the interaction.

[0158] Block 806 may include sending a query to the server device for an updated version of the next UI screen prior to receiving a request to navigate to the next UI screen.

[0159] Block 808 may include receiving a response from the server device that includes an updated version of the following UI screen.

[0160] Block 810 may include, based on the receipt of a request to navigate to the next UI screen, the UI displaying an updated version of the next UI screen based on the response.

[0161] In some embodiments, multiple UI screens may be received from a server device and stored in memory. Based on the interaction, it may be determined that the memory contains an older version of the next UI screen. A query for an updated version of the next UI screen may be sent to the server device based on the determination that the memory contains an older version of the next UI screen.

[0162] In some embodiments, a software application may include a set of UI screens arranged as a set of tabs. The current UI screen and the next UI screen may constitute part of a first tab among the set of tabs. Determining the set of UI screens may include determining, for each tab among the set of tabs, a corresponding list of one or more UI screens navigated by the UI. Determining that memory contains an older version of the next UI screen may include marking each UI screen in the corresponding list of the first tab as old, based on the interaction with the UI components of the current UI screen, and determining that the next UI screen (i) exists in the corresponding list of the first tab and (ii) is marked as old.

[0163] In some embodiments, a software application may include a set of UI screens arranged as a set of tabs. The current UI screen may constitute part of a first tab among the set of tabs, and the next UI screen may constitute part of a second tab among the set of tabs. Determining the set of UI screens may include determining, for each tab among the set of tabs, a corresponding list of one or more UI screens navigated by the UI. Determining that memory contains an older version of the next UI screen may include marking each UI screen in the corresponding list for each tab among the set of tabs as old, based on the interaction with the UI components of the current UI screen, and determining that the next UI screen (i) exists in the corresponding list for the second tab and (ii) is marked as old.

[0164] In some embodiments, determining that memory contains an older version of the next UI screen may include obtaining a dependency map showing data dependencies shared by at least the current UI screen and the next UI screen, and determining, based on the dependency map, that the version of the next UI component stored in memory has become outdated due to modifications made through interaction.

[0165] In some embodiments, the interaction with the UI component may be configured to modify the data displayed by the current UI screen.

[0166] In some embodiments, interaction with a UI component may be configured to modify the data displayed by the next UI screen. The updated version of the next UI screen may be based on the data modification.

[0167] In some embodiments, determining a set of UI screens may involve determining an ordered list of UI screens based on the order in which the UI navigated through them. Determining the next UI screen may involve selecting from the ordered list a UI screen that precedes the current UI screen within the ordered list.

[0168] In some embodiments, a software application may include a workflow model that defines the expected order in which the navigation of the software application's UI screens will occur. Determining the next UI screen may include selecting the next UI screen based on the workflow model.

[0169] In some embodiments, determining the next UI screen may involve selecting the next UI screen using a machine learning model trained to determine which UI screen is expected to be displayed next by the UI, based on one or more of the following: (i) the current UI screen, (ii) the UI components of the current UI screen, (iii) a number of UI screens, and / or (iv) a workflow model of the software application.

[0170] In some embodiments, the subsequent UI screen may be determined from among a plurality of UI screens expected to reappear after the next UI screen based on the display of an updated version of the next UI screen. Prior to receiving a second request to navigate to the subsequent UI screen, a second query for an updated version of the subsequent UI screen may be sent to the server device. The server device may receive a second response containing the updated version of the subsequent UI screen. Based on the reception of the second request to navigate to the subsequent UI screen, the UI may display the updated version of the subsequent UI screen based on the second response.

[0171] In some embodiments, the subsequent UI screen among a plurality of UI screens expected to be displayed next may be determined. Prior to receiving a second request to navigate to the subsequent UI screen, the computer system may generate an instruction configured to cause the server device to send a second query for an updated version of the subsequent UI screen. Prior to receiving a second response from the server device containing the updated version of the subsequent UI screen, a third request to navigate to an intermediate UI screen may be received. Based on the receipt of the third request to navigate to the intermediate UI screen, the second query may be canceled by clearing the instruction or by sending a cancel request to the server device corresponding to the second query.

[0172] In some embodiments, based on the reception of the interaction, a second query for an updated version of the current UI screen may be sent to the server device. The server device may receive a second response containing the updated version of the current UI screen. Based on the reception of the second response, the UI may display the updated version of the current UI screen based on the second response.

[0173] In some embodiments, a second request to navigate to an intermediate UI screen may be received prior to the reception of a request to navigate to the next UI screen. Based on the reception of the second request to navigate to the intermediate UI screen, a second query for the intermediate UI screen may be sent to the server device. The server device may receive a second response containing the intermediate UI screen. Based on the reception of the second response, the UI may display the intermediate UI screen based on the second response.

[0174] VIII. Conclusion This disclosure is not limited in terms of the specific embodiments described herein, which are intended to illustrate various aspects. As will be apparent to those skilled in the art, many improvements and modifications are possible without departing from its scope. From the foregoing description, functionally equivalent methods and apparatus within the scope of this disclosure, in addition to those described herein, will be apparent to those skilled in the art. Such improvements and modifications will also be included in the appended claims.

[0175] The above detailed description, with reference to the accompanying drawings, describes various features and operations of the disclosed systems, equipment, and methods. The exemplary embodiments described herein and in the drawings are not limiting in any way. Other embodiments are available and other modifications can be made without departing from the scope of the subject matter presented herein. It will be readily apparent that the aspects of this disclosure described throughout this specification and shown in the drawings can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations.

[0176] With respect to any or all of the message flow diagrams, scenarios, and flowcharts in the figures, as discussed herein, each step, block, and / or communication may represent the processing and / or transmission of information in an exemplary embodiment. The scope of these exemplary embodiments includes alternative embodiments. In these alternative embodiments, for example, actions described as steps, blocks, transmissions, communications, requests, responses, and / or messages may be performed out of the order shown or described (including substantially concurrently or in reverse order), depending on the function involved. Furthermore, in any of the message flow diagrams, scenarios, and flowcharts discussed herein, the number of blocks and / or actions used may be increased or decreased, and some or all of these message flow diagrams, scenarios, and flowcharts can be combined with one another.

[0177] Steps or blocks representing the processing of information can correspond to circuits that can be configured to perform specific logical functions of the method or technique described herein. Alternatively or in addition, steps or blocks representing the processing of information can correspond to modules, segments, or portions of program code (including associated data). The program code may include one or more instructions that can be executed by a processor to perform specific logical operations or actions in the method or technique described above. The program code and / or associated data can be stored in any type of computer-readable medium, such as a memory device including RAM, disk drives, semiconductor drives, or other storage media.

[0178] Furthermore, computer-readable media may include non-temporary computer-readable media such as register memory and processor cache, which store data for short periods. Non-temporary computer-readable media may further include non-temporary computer-readable media that store program code and / or data for long periods. Therefore, non-temporary computer-readable media may include secondary or persistent long-term storage such as ROM, optical or magnetic disks, semiconductor drives, or compact disk read-only memory (CD-ROM). Other volatile or non-volatile storage systems are also possible as non-temporary computer-readable media. Non-temporary computer-readable media can be thought of as, for example, computer-readable storage media or tangible storage devices.

[0179] Furthermore, a step or block representing one or more information transmissions may correspond to information transmissions between software and / or hardware modules within the same physical device. However, other information transmissions are also possible between software and / or hardware modules in different physical devices.

[0180] The specific arrangement shown in the drawings should not be considered limiting in any way. It should be understood that in other embodiments, the number of each element shown in the drawings may be increased or decreased. Furthermore, some of the illustrated elements may be combined or omitted. Moreover, an exemplary embodiment may include elements not shown in the drawings.

[0181] While various aspects and embodiments are disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for illustrative purposes only and are not intended to limit in any way; the true scope is given by the following claims.

Claims

1. Processor and memory and When stored in the memory and executed by the processor, Determining a plurality of UI screens of the software application navigated by the user interface (UI) of the software application, The aforementioned UI receives interaction with the UI components of the current UI screen among the plurality of UI screens, Based on the reception of the aforementioned interaction, determine the next UI screen among the plurality of UI screens that are expected to be displayed again after the current UI screen, Prior to receiving a request to navigate to the next UI screen, a query for an updated version of the next UI screen is sent to the server device. The server device receives a response including the updated version of the following UI screen, Based on the receipt of the request to navigate to the next UI screen, the UI displays the updated version of the next UI screen based on the response, A software application configured to perform actions including, A computer system equipped with the following features.

2. The aforementioned multiple UI screens are received from the server device and stored in the memory. The aforementioned operation, Based on the interaction, it is determined that the memory contains an older version of the next UI screen, and the query for the updated version of the next UI screen is sent to the server device based on the determination that the memory contains an older version of the next UI screen. The computer system according to claim 1, further comprising:

3. The software application includes a group of UI screens arranged as multiple tabs, and the current UI screen and the next UI screen constitute a part of the first tab among the multiple tabs. Determining the plurality of UI screens includes determining, for each of the plurality of tabs, a corresponding list of one or more UI screens navigated by the UI, Determining that the memory contains the older version of the next UI screen, Based on the interaction with the UI component of the current UI screen, each UI screen in the corresponding list of the first tab is marked as old. The following UI screen is determined to (i) exist in the corresponding list of the first tab, and (ii) be marked as old. The computer system according to claim 2, including the above.

4. The software application includes a group of UI screens arranged as a group of tabs, the current UI screen constitutes a part of a first tab among the group of tabs, and the next UI screen constitutes a part of a second tab among the group of tabs. Determining the plurality of UI screens includes determining, for each of the plurality of tabs, a corresponding list of one or more UI screens navigated by the UI, Determining that the memory contains the older version of the next UI screen, Based on the interaction with the UI component of the current UI screen, each UI screen in the corresponding list of each of the tabs among the multiple tabs is marked as old. The following UI screen is determined to (i) exist in the corresponding list of the second tab, and (ii) be marked as old. The computer system according to claim 2, including the above.

5. Determining that the memory contains the older version of the next UI screen, This involves obtaining a dependency map that shows the data dependencies shared by at least the current UI screen and the next UI screen, Based on the dependency map, it is determined that the version of the next UI component stored in the memory has become outdated due to the modifications made by the interaction. The computer system according to claim 2, including the above.

6. The computer system according to claim 1, wherein the interaction with the UI component is configured to modify the data displayed by the current UI screen.

7. The computer system according to claim 1, wherein the interaction with the UI component is configured to modify the data displayed by the next UI screen, and the updated version of the next UI screen is based on the modification of the data.

8. Determining the plurality of UI screens includes determining an ordered list of the plurality of UI screens based on the order in which the UI navigated through them. The computer system according to claim 1, wherein determining the next UI screen includes selecting a UI screen from the ordered list that precedes the current UI screen within the ordered list.

9. The software application includes a workflow model that defines the expected order in which the navigation of the software application's UI screens is expected, and determining the next UI screen is: Select the next UI screen based on the aforementioned workflow model. The computer system according to claim 1, including the above.

10. Determining the next UI screen is (i) the current UI screen, (ii) the UI components of the current UI screen, (iii) the multiple UI screens, or (iv) the workflow model of the software application, by using a machine learning model trained to determine which UI screen is expected to be displayed next. The computer system according to claim 1, including the above.

11. The aforementioned operation, Based on the display of the updated version of the next UI screen, the subsequent UI screen among the plurality of UI screens that are expected to be displayed again after the next UI screen is determined. Prior to receiving a second request to navigate to the subsequent UI screen, a second query for an updated version of the subsequent UI screen is sent to the server device. The server device receives a second response, which includes the updated version of the subsequent UI screen. Based on the receipt of the second request to navigate to the subsequent UI screen, the UI displays the updated version of the subsequent UI screen based on the second response. The computer system according to claim 1, further comprising:

12. Next, determine the subsequent UI screen from among the multiple UI screens that are expected to be displayed again, Prior to receiving a second request to navigate to the subsequent UI screen, the computer system generates an instruction configured to cause the server device to send a second query for an updated version of the subsequent UI screen. Prior to receiving a second response from the server equipment that includes the updated version of the subsequent UI screen, a third request is received to navigate to an intermediate UI screen. Based on the receipt of the third request for navigating to the intermediate UI screen, the second query is canceled by deleting the command or sending a cancellation request corresponding to the second query to the server equipment. The computer system according to claim 1, further comprising:

13. The aforementioned operation, Based on the reception of the aforementioned interaction, a second query for the updated version of the current UI screen is sent to the server device, The server device receives a second response, which includes the updated version of the current UI screen. Based on the receipt of the second response, the UI displays the updated version of the current UI screen based on the second response. The computer system according to claim 1, further comprising:

14. The aforementioned operation, Prior to receiving the request to navigate to the next UI screen, a second request to navigate to an intermediate UI screen is received. Based on the receipt of the second request for navigating to the intermediate UI screen, a second query for the intermediate UI screen is sent to the server device. The server device receives a second response, including the intermediate UI screen. Based on the receipt of the second response, the UI displays the intermediate UI screen based on the second response. The computer system according to claim 1, further comprising:

15. Determining multiple UI screens of the software application, which are navigated by the user interface (UI) of the software application; The aforementioned UI receives interaction with the UI components of the current UI screen among the plurality of UI screens, Based on the reception of the aforementioned interaction, determine the next UI screen among the plurality of UI screens that are expected to be displayed again after the current UI screen, Prior to receiving a request to navigate to the next UI screen, a query for an updated version of the next UI screen is sent to the server device. The server device receives a response including the updated version of the following UI screen, Based on the receipt of the request to navigate to the next UI screen, the UI displays the updated version of the next UI screen based on the response, A computer execution method, including...

16. The plurality of UI screens are received from the server device and stored in the memory of a computer device configured to run the software application, and the method is Based on the interaction, it is determined that the memory contains an older version of the next UI screen, and the query for the updated version of the next UI screen is sent to the server device based on the determination that the memory contains an older version of the next UI screen. The computer execution method according to claim 15, further comprising:

17. The software application includes a group of UI screens arranged as multiple tabs, and the current UI screen and the next UI screen constitute a part of the first tab among the multiple tabs. Determining the plurality of UI screens includes determining, for each of the plurality of tabs, a corresponding list of one or more UI screens navigated by the UI, Determining that the memory contains the older version of the next UI screen, Based on the interaction with the UI component of the current UI screen, each UI screen in the corresponding list of the first tab is marked as old. The following UI screen is determined to (i) exist in the corresponding list of the first tab, and (ii) be marked as old. The computer execution method according to claim 16, including the method described in claim 16.

18. The software application includes a group of UI screens arranged as a group of tabs, the current UI screen constitutes a part of a first tab among the group of tabs, and the next UI screen constitutes a part of a second tab among the group of tabs. Determining the plurality of UI screens includes determining, for each of the plurality of tabs, a corresponding list of one or more UI screens navigated by the UI, Determining that the memory contains the older version of the next UI screen, Based on the interaction with the UI component of the current UI screen, each UI screen in the corresponding list of each of the tabs among the multiple tabs is marked as old. The following UI screen is determined to (i) exist in the corresponding list of the second tab, and (ii) be marked as old. The computer execution method according to claim 16, including the method described in claim 16.

19. Determining the plurality of UI screens includes determining an ordered list of the plurality of UI screens based on the order in which the UI navigated through them. The computer execution method according to claim 15, wherein determining the next UI screen includes selecting a UI screen that precedes the current UI screen from the ordered list.

20. Execution by a computer system, Determining multiple UI screens of the software application, which are navigated by the user interface (UI) of the software application; The aforementioned UI receives interaction with the UI components of the current UI screen among the plurality of UI screens, Based on the reception of the aforementioned interaction, determine the next UI screen among the plurality of UI screens that are expected to be displayed again after the current UI screen, Prior to receiving a request to navigate to the next UI screen, a query for an updated version of the next UI screen is sent to the server device. The server device receives a response including the updated version of the following UI screen, Based on the receipt of the request to navigate to the next UI screen, the UI displays the updated version of the next UI screen based on the response, A manufactured product including a non-temporary computer-readable medium containing program instructions that cause the computer system to perform an operation including the above.

Images