Progressive refresh of user interface screens

Abstract

An embodiment may include determining a UI screen of the application navigated to by a user interface (UI) of the software application. The embodiment may also include receiving an interaction with a UI component of a current one of the UI screens, and determining a next one of the UI screens expected to re-display after the current UI screen based on receiving the interaction. The embodiment may further 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 including the updated version of the next UI screen, and displaying the updated version of the next UI screen based on the response based on receiving the request to navigate to the next UI screen.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Patent Application No. 17 / 590,792, filed February 1, 2022, the entire contents of which are incorporated herein by reference. [Background technology]

[0002] The software application may be configured to cache at least a portion of the responses received from the server equipment. Such caching may improve the software application's apparent responsiveness to user navigation requests, since a given user request may be satisfied, at least in part, based on the cached data. However, the cached data may become stale over time, and displaying such data may be undesirable. Thus, detecting and / or updating stale cache contents is beneficial. Summary of the Invention

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

[0004] To improve the responsiveness of a software application to user input, the software application may be configured to cache UI screens that the software application has previously navigated to and / or displayed (e.g., as part of a given usage session). Thus, a request to revisit a previously displayed UI screen may be satisfied using the cache rather than a network call to the server device. However, if two or more UI screens rely on the same underlying data, a modification of the underlying data performed using one of those UI screens may cause a cached version of another one of those UI screens to become out of date. Thus, when a particular UI screen makes a modification to the underlying data, the server device may be configured to (i) play and transmit an updated version of the particular UI screen, and possibly (ii) play and transmit an updated version of one or more previously displayed UI screens that are affected by the modification. However, such an approach may unnecessarily consume computational and / or communication resources, since the software application may not be used to display an updated version of one or more previously displayed UI screens that are affected by the modification.

[0005] Thus, the software application may alternatively be configured to track previously displayed UI screens, identify a stale subset thereof, and incrementally preempt UI screens expected to be next redisplayed. In particular, the software application may be configured to track navigated UI screens and / or maintain an ordered list indicating the order in which these UI screens were displayed, as they are used to navigate the UI screen. If the underlying data is modified due to an interaction with a UI component of a currently displayed UI screen, the software application may be configured to determine a stale set of UI components, which may include a subset of the UI components that may have become stale due to the modification. The stale 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 stale set may be updated when an updated version of the UI screen is obtained and / or when additional modifications are performed.

[0006] The software application may also be configured to identify a next UI screen that is expected to be re-displayed after a currently displayed UI screen and, if the next UI screen is out of date, to pre-fetch the next UI screen prior to a user request therefor being received by the software application. Thus, 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 rather than an outdated version, and the user may not have to wait for the updated version of the next UI screen to be retrieved from the server device. Furthermore, because the cache may already contain an updated version of the next UI screen, the user may not have to determine whether to manually request a refresh of the next UI screen, avoiding unnecessary refresh requests.

[0007] As a user navigates through the software application, subsequent UI screens expected to be displayed next may be determined and prefetched 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 inverse of the order in which the UI screens were initially navigated, with the most recently displayed UI screen being prefetched first. In another example, the next and / or subsequent UI screens may be determined based on a workflow model that specifies an intended and / or empirically observed sequence of UI screen presentations.

[0008] Accordingly, a first exemplary embodiment may include a computer system comprising a processor, a memory, and a software application stored in the memory and configured to perform operations when executed by the processor. The operations may include determining a plurality of UI screens of the software application navigated by a user interface (UI) of the software application. The operations may also include receiving, by the UI, an interaction with a UI component of a current UI screen of the plurality of UI screens, and determining, based on the receiving of the interaction, a next UI screen of the plurality of UI screens that is expected to re-display after the current UI screen. Furthermore, the operations 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 operations may further include receiving a response from the server device including the updated version of the next UI screen, and displaying, by the UI, the updated version of the next UI screen based on the receiving of the request to navigate to the next UI screen, based on the response.

[0009] The second exemplary embodiment may include determining, by the UI of the software application, a plurality of UI screens navigated to. The second exemplary embodiment may also include receiving, by the UI, an interaction with a UI component of a current UI screen of the plurality of UI screens, and determining, based on receiving the interaction, a next UI screen of the plurality of UI screens that is expected to re-display after the current UI screen. The second exemplary embodiment may further include sending, to the server device, a query for an updated version of the next UI screen prior to receiving the request to navigate to the next UI screen. The second exemplary embodiment may further include receiving, from the server device, a response including the updated version of the next UI screen, and, based on receiving the request to navigate to the next UI screen, displaying, by the UI, the updated version of the next UI screen based on the response.

[0010] In a third exemplary embodiment, an article of manufacture may include a non-transitory computer-readable medium having stored thereon 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, a computer system may include at least one processor as well as a memory and program instructions that may be stored in the memory and that, when executed by the at least one processor, may cause the computer system to perform the operations described in the first and / or second exemplary embodiments.

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

[0013] These and other embodiments, aspects, advantages, and alternatives will become apparent to those skilled in the art upon reading the following detailed description, with reference to the accompanying drawings, as appropriate. Moreover, this summary, as well as other descriptions and figures set forth herein, are intended to illustrate embodiments by way of example only, and many variations are possible. For example, structural elements and process steps can be rearranged, combined, distributed, removed, or otherwise modified while remaining within the scope of the embodiments, as claimed. [Brief description of the drawings]

[0014] [Figure 1] FIG. 2 is a schematic diagram of a computing device according to an exemplary embodiment. [Diagram 2] FIG. 2 is a diagram of a server device cluster in accordance with an exemplary embodiment. [Diagram 3] FIG. 1 illustrates a remote network management architecture according to an exemplary embodiment. [Figure 4] FIG. 1 illustrates a communication environment including a remote network management architecture according to an exemplary embodiment. [Figure 5A] FIG. 2 illustrates another communication environment including a remote network management architecture according to an exemplary embodiment. [Figure 5B] 1 is a flow chart according to an exemplary embodiment. [Figure 6] FIG. 2 illustrates aspects of a software application, according to an exemplary embodiment. [Figure 7A] FIG. 4 is a message flow diagram according to an exemplary embodiment. [Figure 7B] FIG. 4 is a message flow diagram according to an exemplary embodiment. [Figure 7C] FIG. 4 is a message flow diagram according to an exemplary embodiment. [Figure 8] 1 is a flow chart according to an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Exemplary methods, apparatus, and systems are described herein. It should be understood that the words "example" and "exemplary" are used herein to mean "serving as an example, instance, or illustration." Any embodiment or feature described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or features, unless so 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] Accordingly, the exemplary embodiments described herein are not meant to be limiting in any way. It will be readily understood that the aspects of the present disclosure as described throughout this specification and illustrated in the drawings can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations. For example, the separation of functionality into "client" and "server" components can be implemented in many ways.

[0017] Moreover, unless the context indicates otherwise, the features shown in each of the drawings can be used in combination with one another, with the understanding that the drawings should generally be viewed as component aspects of one or more overall embodiments, and that not all of the illustrated features are required for each embodiment.

[0018] Additionally, any recitation of elements, blocks, or steps in the specification or claims is for purposes of clarity, and therefore such recitation should not be construed as requiring or implying adherence to a particular arrangement of those elements, blocks, or steps, or performance in a particular order.

[0019] I. Introduction Large enterprises are complex entities with many interrelated activities. Some of these can be found across the enterprise, such as human resources (HR), supply chain, information technology (IT), and finance. However, each enterprise also has its own unique activities that provide critical capabilities and / or build competitive advantage.

[0020] To support a wide range of business 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 unique requirements of the enterprise. Large enterprises often have dozens or even hundreds of these custom software applications. In contrast, the advantages provided by embodiments herein are not limited to large enterprises, but may be applicable to enterprises of any size or other types of organizations.

[0021] Many such software applications are developed by individual departments within a company. These range from simple spreadsheets to bespoke software tools and databases. However, the proliferation of disconnected, custom software applications has many drawbacks. This negatively impacts a company's ability to operate and grow its business, innovate, and meet regulatory requirements. Without a single system that integrates its subsystems and data, companies may find it difficult to integrate, streamline, and enhance their operations.

[0022] To efficiently generate custom applications, enterprises would benefit from remotely hosted application platforms that eliminate unnecessary development complexity. The goal of such platforms is to reduce time-consuming, repetitive application development tasks, allowing software engineers and other individuals to focus on developing high-value, unique functionality.

[0023] To achieve this goal, the concept of aPaaS (Application Platform as a Service) is introduced to intelligently automate workflows across an enterprise. The aPaaS system is hosted remotely from the enterprise, but has access to data, applications, and services within the enterprise through a secure connection. Such an aPaaS system has many advantageous features and characteristics. These advantages and characteristics are believed to improve the operations and workflows of an enterprise with respect to IT, HR, CRM, customer service, application development, and security. In contrast, the embodiments herein are not limited to enterprise applications or environments, but are more broadly applicable.

[0024] aPaaS systems may 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 the way that information is presented to the user by dividing each functionality into three interconnected parts (model, view, and controller). These applications may 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 may be structured differently from MVC, such as those that use unidirectional data flow.

[0025] An aPaaS system may support standardized application components, such as a standardized set of widgets for graphical user interface (GUI) development. In this way, applications built using an aPaaS system have a common look and feel. Other software components and modules may be standardized as well. 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 may support the ability to configure application behavior using metadata, allowing applications to quickly adapt their behavior to meet specific needs. Such an approach reduces development time and increases flexibility. Additionally, aPaaS systems may support GUI tools that make metadata creation and management easier, reducing metadata errors.

[0027] An aPaaS system may support well-defined interfaces between applications, allowing software developers to avoid unnecessary inter-application dependencies. To this end, an aPaaS system may implement a service layer where data such as persistent state information is stored.

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

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

[0030] There may also be other features, functions, and advantages of an aPaaS system. This description is for illustrative purposes and is not intended to be limiting in any way.

[0031] As an example of an aPaaS development process, a software developer may be tasked with creating a new application using an aPaaS system. The developer may first specify a data model that specifies the types of data the application will use and the relationships between each. The developer then inputs (e.g., uploads) the data model via the aPaaS system's GUI. The aPaaS system automatically creates all of the corresponding database tables, fields, and relationships, which are accessible through an object-oriented services layer.

[0032] The aPaaS system can also build a fully functional application with a client-side interface and server-side CRUD logic. This generated application can serve as a basis for the user's further development. Developers do not need to spend a lot of time on the basic functionality of the application, which is convenient. Furthermore, the application can be web-based, so that it can be accessed from any internet-enabled client device. Alternatively or additionally, a local copy of the application can be accessed, for example, when internet service is not available.

[0033] Additionally, aPaaS systems may support a rich set of predefined features that can be added to applications, including search, email, templates, workflow design, reporting, analytics, social media, scripting, mobile output, and support for customized GUIs.

[0034] Such an aPaaS system may represent the GUI in a variety of ways. For example, a server machine in the aPaaS system may generate a representation of the GUI using a combination of HTML and JAVASCRIPT. The JAVASCRIPT may include client-side executable code, server-side executable code, or both. The server machine may send or otherwise provide this representation to the client machine so that the client machine displays it on its screen according to a locally defined look and feel. Alternatively, the representation of the GUI may be in some other form, such as an intermediate form (e.g., JAVA bytecode) that the client machine can use to generate graphical output directly. There are other possibilities.

[0035] Additionally, user interaction with GUI elements, such as buttons, menus, tabs, sliders, checkboxes, toggles, etc., may be referred to as "selecting," "activating," or "actuating," respectively. These terms may be used regardless of whether the interaction with the GUI element is through a keyboard, a pointing device, a touch screen, or another mechanism.

[0036] The aPaaS architecture is particularly effective when integrated with and used to manage an enterprise's network. The following embodiments describe the architecture and functional aspects of an exemplary aPaaS system, as well as respective features and advantages.

[0037] II. Exemplary Computing Device and Cloud-Based Computing Environment 1 is a simplified block diagram illustrating a computing device 100 showing some of the components that may be included on the computing device and configured to operate in accordance with embodiments herein. The computing device 100 may be a client device (e.g., a device that is actively operated by a user), a server device (e.g., a device that provides computing services to client devices), or some other type of computing platform. Some server devices may act as client devices at times to perform certain operations, and some client devices may incorporate server functionality.

[0038] In this example, computing device 100 includes a processor 102, memory 104, a network interface 106, and input / output units 108, all of which may be coupled by a system bus 110 or similar mechanism. In some embodiments, computing device 100 may include other components and / or peripherals (e.g., removable storage, printers, 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 co-processor (e.g., a mathematical, graphics, or encryption co-processor), a digital signal processor (DSP), a network processor, and / or in the form of 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 a register memory for temporarily storing instructions and associated data to be executed, as well as a 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, solid state drives, compact disks (CDs), digital video disks (DVDs), and / or tape storage). Thus, memory 104 represents both a main memory unit and long term storage. Other types of memory include biological memory.

[0041] The memory 104 may store program instructions and / or data on which the program instructions may operate. As an example, the memory 104 may store program instructions on a non-transitory computer-readable medium such that, upon execution by the processor 102, these instructions may perform any of the methods, processes, or operations disclosed herein or in the accompanying drawings.

[0042] As shown in FIG. 1, the memory 104 may include firmware 104A, kernel 104B, and / or applications 104C. The firmware 104A may be program code used to boot or start some or all of the computing device 100. The kernel 104B may be an operating system including modules for memory management, processor scheduling and management, input / output, and communication. The kernel 104B may also include device drivers that allow the operating system to communicate with the hardware modules (e.g., memory units, network interfaces, ports, and buses) of the computing device 100. The applications 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. The memory 104 may also store data used by these 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 line, or wide area media, such as Synchronous Optical Networking (SONET) or Digital Subscriber Line (DSL) technologies. The network interface 106 may also be in the form of one or more wireless interfaces, such as IEEE 802.11 (Wifi), 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 over the network interface 106. Furthermore, the network interface 106 may include multiple physical interfaces. For example, some embodiments of the computing device 100 may include Ethernet, BLUETOOTH, and Wifi interfaces.

[0044] The input / output unit 108 may facilitate user and peripheral interaction with the computing device 100. The input / output unit 108 may include one or more types of input devices, such as a keyboard, a mouse, a touch screen, etc. Similarly, the input / output unit 108 may include one or more types of output devices, such as a screen, a monitor, a printer, and / or one or more light emitting diodes (LEDs). Additionally or alternatively, the computing device 100 may communicate with other devices, for example, by using a Universal Serial Bus (USB) or a High Definition Multimedia Interface (HDMI) port interface.

[0045] In some embodiments, an aPaaS architecture may be supported by the deployment of one or more computing devices, such as computing device 100. The exact physical location, connectivity, and configuration of these computing devices may not be known and / or important to the client devices. Thus, the computing devices may be referred to as "cloud-based" devices that may be housed in a variety of remote data center locations.

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

[0047] For example, server devices 202 may be configured to perform various computational tasks for computer device 100. Thus, computational tasks may be distributed to one or more server devices 202. To the extent that these computational tasks can be performed in parallel, such distribution of tasks may reduce the total time to complete these tasks and return results. For simplicity, both server cluster 200 and individual server devices 202 may be referred to as "server devices." This nomenclature should be understood as an implication that one or more different server devices, data storage devices, and cluster routers may be involved in the operation of a server device.

[0048] Data storage 204 may be a data storage array including a drive array controller configured to manage read and write access to a set of hard disk drives and / or solid state drives. The drive array controller may also be configured, alone or in conjunction with server devices 202, to manage backup or redundant copies of data stored on data storage 204 to protect against drive failure or other types of failure that would prevent one or more server devices 202 from accessing units of data storage 204. Other types of memory besides drives may also be used.

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

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

[0051] As one possible example, 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 may 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 transmit data to and / or receive data from the data storage 204. The transmission and retrieval may be in the form of SQL queries or other types of database queries and the output of such queries, respectively. Similarly, text, images, video, and / or audio may additionally be 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), Extensible Markup Language (XML), or some 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), JAVASCRIPT, and the like. Computer program code written in these languages ​​may facilitate the provision of web pages to client devices as well as the client devices' interaction with the web pages. Alternatively or additionally, JAVA may be used to facilitate the generation of web pages and / or provide web application functionality.

[0053] III. Exemplary Remote Network Management Architecture 3 illustrates a remote network management architecture according to an example embodiment, which 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 Managed network 300 may be, for example, an enterprise network used by an entity for computing and communication tasks as well as storage of data. To this end, managed network 300 may include client devices 302, server devices 304, routers 306, virtual machines 308, firewalls 310, and / or proxy servers 312. Client devices 302 may be embodied by computing devices 100, server devices 304 may be embodied by computing devices 100 or server clusters 200, and routers 306 may be any type of router, switch, or gateway.

[0055] The virtual machine 308 may be embodied by one or more of the computer device 100 and the server cluster 200. In general, a virtual machine is an emulation of a computer system that mimics the functionality (e.g., processor, memory, and communication resources) of a physical computer. A single physical computer system, such as the server cluster 200, can support up to thousands of individual virtual machines. In some embodiments, the virtual machines 308 may be managed by a centralized server device or application that facilitates allocation of physical computing resources to the individual virtual machines, as well as performance and error reporting. Enterprises often employ virtual machines to efficiently allocate computing resources as needed. Providers of virtualized computer systems include VMWARE® and MICROSOFT®.

[0056] Firewall 310 may be one or more dedicated routers or server devices that protect managed network 300 from unauthorized attempts to access internal devices, applications, and services while allowing legitimate communications originating from managed network 300. 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 FIG. 3, 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] The managed network 300 may also include one or more proxy servers 312. An embodiment of the proxy server 312 may be a server application that facilitates 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 secure communication sessions with one or more computing instances of the remote network management platform 320. Such sessions may enable the remote network management platform 320 to discover and manage aspects of the architecture and configuration of the managed network 300 and its components. In some cases, the proxy server 312 may also assist the remote network management platform 320 to discover and manage aspects of the public cloud network 340 that the managed network 300 uses.

[0058] A firewall such as firewall 310 typically denies all communication sessions coming in via Internet 350 unless such sessions ultimately originate behind the firewall (i.e., a device on managed network 300) and the firewall is explicitly configured to support the sessions. Locating proxy server 312 behind firewall 310 (e.g., by being located within managed network 300 and protected by firewall 310) may allow proxy server 312 to initiate these communication sessions through firewall 310. This may mean that firewall 310 does not need to be specially configured to support incoming sessions from remote network management platform 320, thus avoiding a potential security risk to managed network 300.

[0059] In some cases, managed network 300 may consist of just a few devices and a few networks. In other deployments, managed network 300 may span multiple physical locations and include hundreds of networks and hundreds of thousands of devices. Thus, the architecture shown in FIG. 3 can be scaled up or down by orders of magnitude.

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

[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 be in the form of a web-based portal, for example using the web-based technologies mentioned above. This allows users to securely access the remote network management platform 320, for example from the client device 302 or potentially from a client device outside the managed network 300. The web-based portal allows users to design, test, and deploy applications, generate reports, review analytics, and perform other tasks. The remote network management platform 320 may also be referred to as a multi-application platform.

[0062] As shown in FIG. 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 running a dedicated copy of the aPaaS software and / or one or more database nodes. Flexible placement of servers and databases on physical server equipment and / or virtual machines may be allowed and may change based on the needs of the enterprise. In combination, these nodes may provide a set of web portals, services, and applications available to a particular enterprise (e.g., a fully functional aPaaS system). In some cases, a single enterprise may use multiple compute instances.

[0063] For example, managed network 300 may be an enterprise customer of remote network management platform 320 and may use compute instances 322, 324, and 326. A reason for providing multiple compute instances to a customer may be that the customer desires to independently develop, test, and deploy its applications and services. Thus, compute instance 322 may be dedicated to developing applications associated with managed network 300, compute instance 324 may be dedicated to testing these applications, and compute instance 326 may be dedicated to live operation of the tested applications and services. Computing instances may also be referred to as hosted instances, remote instances, customer instances, or some other designation. Any application deployed to a computing instance may be considered a scoped application in that access to the database within the computing instance may be restricted to specific elements therein (e.g., specific database table(s) or specific rows within one or more database tables).

[0064] For simplicity, this disclosure refers to the configuration of application nodes, database nodes, the aPaaS software running thereon, and the underlying hardware as a "computing instance." Note that users may colloquially refer to the graphical user interface provided thereby as an "instance." However, unless otherwise defined herein, a "computing instance" is a computer system disposed within the remote network management platform 320.

[0065] The multi-instance architecture of the remote network management platform 320 provides several advantages as opposed to traditional multi-tenant architectures. In a multi-tenant architecture, data from different customers (e.g., enterprises) is mixed in a single database. The data of these customers is isolated from each other, but this isolation is enforced by the software that operates the single database. As a result, a security breach in the system affects all of the customers' data, creating additional risks, especially for government, healthcare, and / or financial regulated entities. Furthermore, any database operation that affects one customer may affect all customers that share the database. Thus, in the case of an outage due to a hardware or software error, the outage affects all such customers. Similarly, when a database is upgraded to meet the needs of one customer, the upgrade process makes it unavailable to all customers. Such maintenance windows are often long due to the size of the shared database.

[0066] In contrast, a multi-instance architecture provides each customer with its own database in a dedicated compute instance. This prevents intermingling 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 are not affected. Maintenance downtime is limited because the database contains only one customer's data. In addition, the simpler design of a multi-instance architecture allows redundant copies of each customer database and instance to be deployed geographically diversely. This promotes high availability and allows the live version of a customer's instance to be moved when a failure is detected 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 that operates the platform. Similar to the computing instances, the central instance may include several application and database nodes distributed on several physical server devices or virtual machines. Such a central instance may act as a repository for the computing instances as well as a particular configuration of data that may be shared by at least some of the computing instances. For example, there may be definitions of common security threats that may occur on the computing instances, software packages commonly found on the computing instances, and / or an application store for applications that may be deployed on the computing instances. The computing instances may communicate with the central instance by well-defined interfaces to obtain this data.

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

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

[0070] C. Public Cloud Networks 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, communication, and service hosting activities. These servers may be virtualized (i.e., virtual machines). Examples of public cloud network 340 include AMAZON WEB SERVICES® and MICROSOFT® AZURE®. Similar to remote network management platform 320, multiple server clusters supporting public cloud network 340 may be deployed in diverse geographic locations for load balancing, redundancy, and / or high availability purposes.

[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 capabilities. In this way, the businesses in the managed network 300 do not need to build and maintain their own servers for these operations.

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

[0073] D. Communications Support and Other Operations Internet 350 may represent a portion of the global Internet, although Internet 350 may alternatively 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 managed network 300 and computing instances 322, introducing additional features and alternative embodiments. In Figure 4, all or a portion of computing instances 322 are replicated in both data centers 400A and 400B. These data centers may be geographically separate from one another, perhaps in different cities or different countries. Each data center includes managed network 300 as well as supporting facilities that facilitate communication with remote users.

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

[0076] Data center 400B may have its own versions of the components of data center 400A, such that 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. Additionally, computing instances 322 may exist simultaneously in data centers 400A and 400B, with real-time or near real-time database replication and / or other operations.

[0077] Data centers 400A and 400B as shown in Figure 4 may facilitate redundancy and high availability. In the configuration of Figure 4, data center 400A is active and data center 400B is passive. Thus, data center 400A serves all traffic for managed network 300 while the versions of computing instances 322 in data center 400B are 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 some kind of 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 computing 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 may take less than a second or a few seconds), computing instance 322 is made accessible to users by data center 400B.

[0079] FIG. 4 also illustrates possible configurations of managed network 300. As described above, proxy server 312 and users 414 can access compute instance 322 through firewall 310. Proxy server 312 can also access configuration items 410. In FIG. 4, configuration items 410 may represent any or all of client device 302, server device 304, router 306, and virtual machine 308, any applications or services running thereon, as well as relationships between the devices, applications, and services. Thus, the term "configuration item" may be shorthand for any physical or virtual device, any application or service capable of being remotely discovered or managed by compute instance 322, or relationships between discovered devices, applications, and services. Configuration items may be represented in a configuration management database (CMDB) of compute instance 322.

[0080] As mentioned 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 device of managed network 300 and / or compute instance 322 that communicates directly through the VPN may be assigned a public IP address. Other devices of managed network 300 and / or compute instance 322 may be assigned a private IP address (e.g., an IP address selected from the ranges 10.0.0.0-10.255.255.255 or 192.168.0.0-192.168.255.255, abbreviated as subnets 10.0.0.0 / 8 and 192.168.0.0 / 16, respectively).

[0081] IV. EXEMPLARY DEVICE, APPLICATION, AND SERVICE DISCOVERY To manage the devices, applications, and services of the managed network 300, the remote network management platform 320 may initially determine the devices present in the managed network 300, the configurations and operational states of those devices, and the applications and services they provide, as well as the relationships between the discovered devices, applications, and services. As mentioned above, each device, application, service, and relationship may be referred to as a configuration item. The process of defining the configuration items in the managed network 300 is referred to as discovery, and may be facilitated, at least in part, by the proxy server 312.

[0082] For purposes of embodiments herein, an "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. A "service" may represent advanced functionality provided by multiple applications running on one or more devices acting in conjunction with each other. For example, an advanced web service may include multiple web application server threads running on one device accessing information from a database application running on another device.

[0083] 5A is a logical depiction of how configuration items may be discovered, as well as how information associated with the discovered configuration items may be stored. For simplicity, the remote network management platform 320, the public cloud network 340, and the Internet 350 are not shown.

[0084] 5A, the CMDB 500 and task list 502 are stored in the computation instance 322. The computation 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] The task list 502 represents a list of actions that the proxy server 312 is to perform on behalf of the computation instance 322. Once a detection is made, an entry is made in the task list 502. The proxy server 312 repeatedly queries the task list 502 to obtain the next task therein and executes this task until the task list 502 is empty or another stopping condition is reached.

[0086] To facilitate discovery, a proxy server 312 may be configured with information about one or more subnets in 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 computing instance 322 may then store this information in the CMDB 500 and place tasks in the task list 502 to discover devices at each of these addresses.

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

[0088] Placing a task in the task list 502 may trigger or cause the proxy server 312 to initiate detection. Alternatively or additionally, detection may be manually or automatically triggered based on a triggering event (e.g., detection may be initiated automatically once a day at a particular time).

[0089] In general, discovery can take place in four logical stages: scanning, classification, identification, and exploration. Each stage of discovery involves different types of probe messages being sent by the proxy server 312 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 a representation of each may be sent to the CMDB 500. Thus, with each stage, more configuration items may be discovered and stored in the CMDB 500.

[0090] During the scan 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 to which that IP address is assigned, which may identify the operating system used by the device. For example, if TCP port 135 is open, the device is likely running a 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 otherwise identifiable through Simple Network Management Protocol (SNMP). There are other possibilities. 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 phase, 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 information collected about the device during the scan phase. For example, if a device is found with TCP port 22 open, a set of UNIX-specific probes may be used. Similarly, if a device is found with TCP port 135 open, a set of WINDOWS-specific probes may be used. In either case, an appropriate 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 the particular device. For example, if TCP port 22 is open, the proxy server 312 may be instructed to open a Secure Shell (SSH) connection to the particular device and retrieve information about the operating system on the device from a particular location in the file system. Based on this information, the operating system may be determined. As an example, a UNIX® device with an open TCP port 22 may be classified as AIX®, HPUX, LINUX®, MACOS®, or SOLARIS®. This classification information may be stored in the CMDB 500 as one or more configuration items.

[0092] During the identification phase, the proxy server 312 may determine specific details about the classified device. The probes used during this phase may be based on information collected about the particular device during the classification phase. 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 with the classification phase, an appropriate 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 retrieve information from the particular device, such as basic input / output system (BIOS) information, serial numbers, network interface information, media access control addresses assigned to those network interfaces, IP addresses used by the particular device, etc. 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 further details regarding the operational status of the classified device. The probes used during this phase may be based on information collected about the particular device during the classification and / or identification phase. Again, 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 retrieve additional information from the particular device, such as processor information, memory information, list of running processes (applications), etc. Here again, the detection information may be stored in the CMDB 500 as one or more configuration items.

[0094] Discovery may be performed on network devices such as routers using SNMP. As an alternative or in addition to determining a list of running processes or other application related information, discovery may involve the router determining additional subnets known to it and the operational state (e.g., active, inactive, queue lengths, number of dropped packets, etc.) of the router's network interfaces. The IP addresses of the additional subnets may be candidates for further discovery procedures. Thus, discovery may proceed in an iterative or recursive manner.

[0095] Once discovery is complete, a snapshot representation of each discovered device, application, and service is available in CMDB 500. For example, after discovery, operating system versions, hardware configurations, and network configuration details of client devices, server devices, and routers in managed network 300 may be stored, as well as the applications running on them. This collected information may be presented to a user in a variety of ways to allow the user to view the hardware configuration and operational status of devices, as well as the characteristics of services across multiple devices and applications.

[0096] Further, the CMDB 500 may include entries regarding dependencies and relationships between configuration items. More specifically, applications running on a particular server device as well as services that depend on the applications may be represented in this manner in the CMDB 500. For example, a database application may be running on a server device and may be used for a new employee training service as well as a payroll service. Thus, if the server device is taken out of service for maintenance, the employee training service and the payroll service will obviously be affected. Similarly, dependencies and relationships between configuration items may represent services that are affected if a particular router fails.

[0097] Typically, dependencies and relationships between configuration items may be displayed in a web-based interface and represented as a hierarchy, so that adding, modifying, or deleting such dependencies and relationships may be accomplished through this interface.

[0098] Additionally, users of managed network 300 can develop workflows that allow for the performance of specific coordinated actions across multiple discovered devices. For example, an IT workflow could allow a user to change a common administrator password for all discovered LINUX devices in a single operation.

[0099] To allow such discovery to occur, the proxy server 312, the CMDB 500, and / or one or more credential stores may be configured with credentials for one or more of the devices to be discovered. The credentials may include any type of information required to access the devices. These may include user ID / password pairs, certificates, etc. In some embodiments, these credentials may be stored in encrypted fields in the CMDB 500. The proxy server 312 may include decryption keys for these credentials so that the credentials can be used to log on to or access the devices to be discovered.

[0100] FIG. 5B illustrates the discovery process as a flow chart. In block 520, a task list in a computing instance is populated with, for example, various IP addresses. In block 522, a scanning phase occurs, whereby the proxy server probes the IP addresses for devices using these IP addresses and attempts to determine the operating systems running on these devices. In block 524, a classification phase occurs, whereby the proxy server attempts to determine the operating system version of the detected devices. In block 526, an identification phase occurs, whereby the proxy server attempts to determine the hardware and / or software configuration of the detected devices. In block 526, a discovery phase occurs, whereby the proxy server attempts to determine the operational state and applications running on the detected devices. In block 530, further editing of configuration items representing the detected devices and applications can occur. This editing can be automated and / or manual in nature.

[0101] The blocks depicted in Figure 5B are examples. Detection may be a highly configurable procedure, with more or fewer stages possible, and each stage may operate differently. In some cases, one or more stages may be customized or may deviate from the exemplary description above.

[0102] In this manner, the remote network management platform can discover and inventory the hardware, software, and services deployed and provided on the managed network. As described above, this data may be stored as configuration items in the CMDB of the associated computing instance. For example, individual hardware components (e.g., computing devices, virtual servers, databases, routers, etc.) may be represented as hardware configuration items, while applications installed and / or executed thereon may be represented as software configuration items.

[0103] The relationships of software configuration items installed or executed on a hardware configuration item may be in various forms, such as hosting, executing, or depending. Thus, a database application installed on a server device may have a "hosting" relationship with the server device to indicate that the database application is hosted on the server device. In some embodiments, a server device may have a "using" mutual relationship with the database application to indicate that the server device is used by the database application. While these relationships may be discovered automatically using the discovery procedures described above, the relationships may also be configured manually.

[0104] Also, the relationship between a service and one or more software configuration items may take various forms. As an example, a web service may include a web server software configuration item and a database application software configuration item, each installed on a different hardware configuration item. The web service may have a "depends" relationship with both of these software configuration items, while the software configuration item has a "uses" interrelationship with the web service. Services may not be fully determined by a discovery procedure, 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 possibly some degree of manual configuration.

[0105] Regardless of how it is obtained, relationship information can be beneficial to the operation of a managed network. Among other things, IT personnel can quickly determine where specific software applications are deployed and the configuration items that make up the services. This allows for quick identification of the root cause of a service outage or degradation. For example, if two different services have slow response times, a CMDB query can determine (among other possible actions) that the root cause is high processor utilization in a database application used by both services. IT personnel can then address the database application without wasting time considering the health and performance of other configuration items that make up the services.

[0106] V. Exemplary Software Applications 6 illustrates aspects of an exemplary software application. Software application 600 may be, for example, a native software application configured to run on a particular mobile platform and / or a software application accessible by a web browser. In particular, software application 600 may include a navigation stack controller 602, a refresh controller 604, and a network component 634. These components of software application 600 may operate to update older UI screens of software application 600 before they are requested and / or displayed by the UI.

[0107] In particular, software application 600 may be configured to provide multiple UI screens, each of which may include one or more corresponding UI components. In some cases, the multiple UI screens may be organized as one or more tabs, each of which may define a corresponding group of one or more UI screens. The multiple UI screens and their corresponding UI components, upon viewing and / or interaction by a user, may provide intended functionality of software application 600, which may vary from implementation to implementation. Software application 600 may request one of the multiple UI screens from a server device based on and / or in response to user input, and the server device may be configured to generate and send the requested UI screen to software application 600. Software application 600 may also be configured to cache UI screens received from the server device.

[0108] Data dependencies may exist between different ones of the UI screens. That is, each of the UI screens may depend on (e.g., use and / or display) the same data and / or UI components. Thus, modifications of particular data and / or particular UI components performed by a first UI screen may affect a second UI screen such that the second UI screen will display an older version of the particular data and / or particular UI component unless the second UI screen is regenerated and transmitted to software application 600 after the modifications are completed by the server device.

[0109] Based on the modification of particular data and / or a particular UI component, the server equipment may be able to generate updated versions of all UI screens that the modification affects (or all previously displayed UI screens that the modification affects) and provide the updated versions of these UI screens to the software application 600. However, such an approach may be inefficient and wasteful since the updated versions of these UI screens may not be displayed by the software application 600. For example, the user may instead request the display of other UI screens and / or the end of the usage session, unnecessarily consuming the computing resources of the server equipment and the communications bandwidth between the software application 600 and the server equipment.

[0110] Accordingly, navigation stack controller 602, refresh controller 604, and network component 634 may alternatively operate to predictively and incrementally refresh and / or update older UI screens of software application 600. In particular, navigation stack controller 602 may be configured to determine a number of UI screens navigated by the UI of software application 600. The number of 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 therefore cached in memory utilized by software application 600.

[0111] 6, multiple UI screens of software application 600 may be arranged as multiple tabs, as represented by tabs 610-620 (i.e., tabs 610-620). To this end, navigation stack controller 602 may be configured to track, for each of tabs 610-620, one or more UI screens that belong to the respective tab and that have been navigated through the UI. In some embodiments, navigation stack controller 602 may be configured to generate, for each of tabs 610-620, an ordered list (e.g., a stack) of one or more UI screens based on the order in which the one or more UI screens have been navigated.

[0112] For example, for tab 610, the ordered list may include, in reverse order, current UI screen 618, (current-1) UI screen 616, and (current-2) UI screen 614 through (current-N) UI screen 612 (i.e., UI screens 612 through 618 as a whole). In this manner, UI screens 612 through 618 may form a stack with (current-N) UI screen 612 at the bottom of the stack, indicating that UI screen 612 was first displayed under tab 610, and current UI screen 618 at the top of the stack, indicating that current UI screen 618 was most recently displayed and / or is currently displayed under tab 610. Similarly, for tab 620, the ordered list may 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, examples of UI screens include home screens, lists, webviews, and forms, as well as overlays, modal windows, cards, and / or tables, among other possibilities. Examples of UI components that make up a UI screen include individual data fields, data entries, buttons, text fields, checkboxes, radio buttons, dropdowns, and / or icons, among other possibilities. In general, a tab may include a group of one or more UI screens that may each 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 may include one or more UI components that may define the visual appearance and / or functionality of the UI screen. Depending on the context, a UI element may be considered a screen (e.g., if it is a direct subset of a tab) or a component (e.g., if it is 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 operate on the same or similar data and / or perform related functions. Thus, in some cases, the UI views of a given tab may be data dependent on one another, while the UI views of different tabs may be data independent of one another. In other cases, data dependencies may exist between tabs.

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

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

[0116] The corrective action controller 638 of the network component 634 may be configured to notify the refresh controller 604 of the timing of modifications made by the UI screen. In some embodiments, the modifications may alternatively be referred to as write-back operations, since they may include writing the updated data back to the server device. Specifically, the corrective 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 for which the modification of the underlying data is requested. For example, the corrective action controller 638 may be configured to monitor queries added to the query queue 636 and identify (i) queries that include requests to perform operations that involve modification of the underlying data and (ii) the corresponding UI screens from which these queries originate. The corrective 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 directed and / or the content of the request.

[0117] The refresh controller 604 may be configured to mark the first UI screen as stale if an interaction with a UI component of the second UI screen results in a modification that affects the first UI screen. For example, the modification may include a change in the data and / or UI components displayed by the first UI screen. Thus, the staleness of the first UI screen may be based on the first UI screen and the second UI screen sharing a data dependency, which may affect the content and / or visual appearance of both UI screens.

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

[0119] In particular, UI screens for a given tab that have not been navigated to previously may not be marked as stale because representations of these previously undisplayed screens may not be cached by software application 600. Thus, when one of these previously undisplayed UI screens is requested, such UI screen will be retrieved from the server device, which will generate an updated version that reflects any prior modifications to the underlying data. Furthermore, the UI screen for which the modification is made (e.g., current UI screen 618) may not be marked as stale because making the modification involves communication between software application 600 and the server device, which may provide an updated version of the UI screen to software application 600 in response to a request to make the modification.

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

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

[0122] The dependency map may provide screen-level dependencies and / or component-level dependencies. In one example, the screen-level dependency map may indicate, for each respective UI screen of the plurality of UI screens of the software application 600, zero or more other UI screens that may be affected by modifications performed by any UI component of the respective UI screen. In an example, the zero or more UI screens that are affected by modifications performed by a first UI screen may differ from the zero or more UI screens that are affected by modifications performed by a second UI screen. In another example, the component-level dependency map may indicate, for each respective UI component of the plurality of UI components included as part of the plurality of UI screens of the software application 600, zero or more other UI components that may be affected by modifications performed by the respective UI component. In an example, the zero or more UI components that are affected by modifications performed using the first UI component may differ from the zero or more UI components that are affected by modifications performed using the second UI component.

[0123] Each of the above different approaches for determining stale 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 of the software application 600 increases. For example, a component-level dependency map may enable accurate determination of stale UI screens, but may utilize more storage and / or processing resources than a screen-level dependency map and / or tab-based approach. Conversely, a screen-level dependency map and / or tab-based approach may retrieve updated versions of UI components that are not affected by a given modification, but may utilize less memory and / or processing resources. The particular approach for determining stale tabs may be a user-controllable and / or programmer-controllable parameter of the software application 600, and may be selected based on, for example, 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 a server device, among other possibilities.

[0124] The refresh controller's look-ahead prediction model 608 may be configured to determine the next UI screen 632. Specifically, the next UI screen 632 may be selected from the old set 630-640 and may be expected to re-display after a current UI screen (e.g., current UI screen 618) that the software application 600 is currently displaying. In some cases, the next UI screen 632 may be expected to re-display immediately after the current UI screen. In other cases, one or more intermediate UI screens that have not been navigated to before the re-display of the next UI screen 632 is required after the current UI screen. The next UI screen 632 may represent, for example, one of the (current-N) UI screens 612-616 (current-1).

[0125] The next UI screen 632 may be provided to a query queue 636 of the network component 634, which may be configured to cause the network component 634 to retrieve an updated version of the next UI screen 632 from a server device. The query queue 636 is shown as already including UI screen 650, which may have been requested based on, for example, a user interaction with the software application 600, and / or which 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 also retrieve, an updated version of the next UI screen 632 before a user interaction indicates re-navigation to the next UI screen 632. Thus, the display of an older version of the next UI screen 632 may be avoided because an updated version of the next UI screen 632 is requested and / or pre-fetched before the next UI screen 632 is redisplayed.

[0126] In some cases, the addition to the query queue 636 of another user-initiated request for a UI screen other than next UI screen 632 may be prioritized over next UI screen 632, causing next UI screen 632 to be removed from query queue 636, and / or causing the query for next UI screen 632 to be canceled. For example, receipt by the server device of a query corresponding to a user-initiated request may cause the server device to avoid and / or terminate generating an updated version of next UI screen 632. This may cause next UI screen 632 to remain stale until it is selected again, for example, for preemption.

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

[0128] In another example, if (current-1) UI screen 616 is currently being displayed by software application 600, then (current-2) UI screen 614 would be selected as the next UI screen 632. In another example, if form 628 is currently being displayed by software application 600, then web view 626 would not be selected as the next UI screen 632 because web view 626 is not part of old set 640. However, web view 626 would be selected as the next UI screen 632 if it were part of old set 640. Thus, preempting old UI screens may be based on an expectation that a user may re-navigate through previously displayed UI screens in the reverse order that they were originally requested.

[0129] In other embodiments, the look-ahead prediction model 608 may be configured to select the next UI screen based on the workflow model 606. The workflow model 606 may specify a sequence in which the UI screens of the software application 600 are intended and / or designed to be displayed and / or a sequence in which the UI screens of the software application 600 are empirically observed to be displayed. For example, the workflow model 606 may represent each UI screen of the software application as a node, and edges / arrows between the nodes may indicate a likely sequence through the nodes. In this manner, the look-ahead prediction model 608 may be configured to select a UI screen that follows a currently displayed UI screen in the workflow model 606 as the next UI screen 632. In the case where a node includes multiple edges / arrows leading to different subsequent nodes, each edge / arrow may be associated with a value indicating the likelihood of following that edge / arrow. In this manner, the look-ahead prediction model 608 may be configured to select a UI screen that is most likely to follow a currently displayed UI screen in the workflow model 606 as the next UI screen 632. In some cases, the look-ahead prediction model 608 may be configured to select two or more of the UI screens following the currently displayed UI screen in the workflow model 606 as the next UI screens 632.

[0130] In other embodiments, the look-ahead prediction model 608 may be configured to determine the next UI screen 632 based on multiple inputs. For example, the look-ahead prediction 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, for example, an ordered list of tabs 610-620, an old set 630-640, a workflow model 606, and / or a most recently modified UI component, among other possible inputs. Thus, the machine learning model may consider navigation history, intended and / or empirical use of the software application 600, and / or causes of data modifications in determining the next UI screen 632.

[0131] VI. Exemplary Outdated UI Screen Detection and Preemption Operation 7A, 7B, and 7C are message flow diagrams illustrating the operations of the GUI 702, the software application 600, and the server application 700 involved in pre-fetching of outdated UI screens. In particular, the GUI 702 may be provided by a client computing device on which the software application 600 executes and may be configured to display the UI screens of the software application 600. The server application 700 may be executed by a server device responsible for hosting and / or providing back-end services to the software application 600. In some embodiments, the server application 700 may be provided by a computing instance of the remote network management platform 320 and / or the GUI 702 and the software application 600 may be disposed within the managed network 300.

[0132] 7A illustrates operations associated with generating a navigation stack based on navigation between UI screens of software application 600. 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 at arrow 706 may not have been previously navigated to and / or displayed by software application 600, and therefore a representation thereof may not be cached by software application 600. Based on and / or in response to receiving the request at arrow 706, network component 634 may be configured to send a request / query for the particular UI screen to server application 700, as indicated by arrow 708. Based on and / or in response to receiving the request / query at arrow 708, server application 700 may be configured to generate the particular UI screen, as indicated by block 710. Based on and / or in response to generating the particular UI screen at block 710, the server application 700 may be configured to provide the particular UI screen to the network component 634, as indicated by arrow 712.

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

[0134] Also, based on and / or in response to receiving the particular UI screen at arrow 712, network component 634 may be configured to provide an indication to navigation stack controller 602 to add the particular UI screen to a navigation stack, as indicated at arrow 718. Based on and / or in response to the indication at arrow 718, navigation stack controller 602 may be configured to update the navigation stack, as indicated at block 720. For example, in an implementation in which UI screens are grouped as tabs, navigation stack controller 602 may be configured to track the sequence of UI screens displayed within a tab by updating the navigation stack of the tab to which the particular UI screen belongs. In some cases, navigation stack controller 602 may additionally or alternatively maintain (i) a global navigation stack that tracks UI screens that have been previously displayed independent of the tab to which the 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 updating the navigation stack at block 720, the navigation stack controller 602 may be configured to provide an updated navigation stack to the refresh controller 604, as indicated at arrow 722. Based on and / or in response to receiving the updated navigation stack at arrow 722, the refresh controller 604 may be configured to update its own representation of the navigation stack, as indicated at 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 stale upon future revision by adding a particular UI screen to a corresponding stale set and marking it as up-to-date (i.e., not stale).

[0136] In some implementations, the actions of arrow 722 and block 724 may be omitted and / or performed at a later time. For example, refresh controller 604 may instead be configured to obtain an updated navigation stack from navigation stack controller 602 upon future modifications. Thus, each stale set of refresh controller 604 may be used to represent stale UI screens, but may not be used to represent UI screens that may be stale but are not yet stale.

[0137] Based on and / or in response to receiving the particular UI screen at arrow 712, network component 634 may be further configured to store the particular UI screen in memory of the client computing device. Thus, if a request to redisplay the particular UI screen is subsequently received from GUI 702, the particular UI screen may be provided to GUI 702 without querying server application 700. As indicated by arrow 704, additional UI screens may be obtained by one or more repetitions of the operations of arrow 706 through block 726, resulting in a larger navigation stack and more UI screens stored in memory. As a result of modifications due to interactions with other UI screens, the particular UI screen stored in memory may become stale.

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

[0139] Based on and / or in response to receiving the interaction at arrow 730, network component 634 may be configured to send a request / query to server application 700 to perform an action indicated by the interaction, as indicated by arrow 732. Based on and / or in response to receiving the request / query at arrow 732, server application 700 may be configured to perform an action, as indicated 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 portions of one or more other UI screens, may be affected by the modification. The action may be based on a user editing a text box, selecting an option from a drop-down menu, and / or checking or unchecking a check box, among other possibilities.

[0140] Thus, based on and / or in response to performing the operation at block 734, the server application 700 may be configured to generate an updated version of the current UI screen, as indicated at block 736. Based on and / or in response to generating the updated version of the current UI screen at block 736, the server application 700 may be configured to transmit the updated version of the current UI screen to the network component 634, as indicated by arrow 738. Notably, updated versions of one or more other UI screens affected by the modification may not be generated at this point, as such generation and / or transmission may be wasted if those updated versions are not actually required for display by the GUI 702 after receipt by the software application 600.

[0141] Based on and / or in response to receiving the 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 at arrow 740. Based on and / or in response to receiving the 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 at block 742. In this way, GUI 702 may provide visual feedback indicating successful execution of the action indicated by the interaction at arrow 730.

[0142] Also, based on and / or in response to receiving the 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 a memory of the client device, as indicated at block 744. Based on and / or in response to receiving the updated version of the current UI screen at arrow 738, network component 634 may be further configured to provide an indication to refresh controller 604 that the current UI screen has been updated based on the interaction, as indicated at arrow 746. The indication at arrow 746 may thereby inform refresh controller 604 that successful execution of the action indicated by the interaction has resulted in corresponding data being modified and, in some cases, one or more cached UI screens becoming stale.

[0143] Thus, based on and / or in response to receiving the indication at arrow 746, refresh controller 604 may be configured to update one or more stale sets that it maintains based on updates to the current UI screen, as indicated at block 748. The updating of the one or more stale sets may be based on actual and / or approximate dependencies of one or more UI screens on data modified by performance of an action indicated by interaction of arrow 730, as discussed with respect to FIG.

[0144] 7C illustrates operations associated with updating an older UI screen by incrementally pre-fetching an updated version. Specifically, the refresh controller 604 may be configured to determine a next UI screen in the navigation stack that is expected to be next redisplayed, as indicated by block 750. The operations of block 750 may be performed, for example, based on and / or in response to a change in the UI screen currently displayed by the GUI 702. That is, the prediction of the next UI screen may be updated with each user navigation to a different UI screen by the GUI 702. The refresh controller 604 may be configured to determine that the GUI 702 has switched from displaying one UI screen to displaying another UI screen, similar to arrow 722, for example, based on a notification from the network component 634.

[0145] Based on 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 stale. In the example of FIG. 7C, the refresh controller is shown determining that the next UI screen is stale, as shown in block 752. The next UI screen may be determined to be stale if it is indicated as stale by at least one stale set (e.g., the stale set of the tab to which the next UI screen belongs).

[0146] Based on and / or in response to the determination at block 752 that the next UI screen is stale, refresh controller 604 may be configured to send a request to network component 634 to pre-fetch an updated version of the next UI screen, as indicated by arrow 754. Based on and / or in response to receiving the request at arrow 754, network component 634 may be configured to send a request / query to server application 700 for an updated version of the next UI screen, as indicated by arrow 756. Based on and / or in response to receiving the request / query at arrow 756, 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 as a result of performing the operation at block 736 of FIG. 7B .

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

[0148] Based on and / or in response to receiving and / or storing an updated version of the next UI screen at arrow 760 and / or block 762, network component 634 may be configured to send an indication to refresh controller 604 that an updated version of the next UI screen has been obtained, as indicated at arrow 772. Based on and / or in response to receiving the indication at arrow 772, refresh controller 604 may be configured to update the stale set based on the update to the next UI screen, as indicated at block 774. For example, refresh controller 604 may be configured to indicate that the next UI screen is no longer stale, by removing the next UI screen from the stale set and / or modifying a representation of the next UI screen in the stale set. This may prevent the next UI screen from being prefetched again until it becomes stale due to another modification performed by another UI screen.

[0149] The GUI 702 may be configured to provide a request for the next UI screen to the network component 634, as indicated by arrow 764. Based on and / or in response to receiving the request at arrow 764, the network component 634 may be configured to provide an updated version of the next UI screen to the GUI 702, as indicated by arrow 766. Based on and / or in response to receiving the updated version of the next UI screen at arrow 766, the GUI 702 may be configured to display the updated version of the next UI screen, as indicated by block 768. Thus, rather than displaying an older version of the next UI screen, the GUI 702 may display a version of the next UI screen that reflects modifications previously performed via the operations illustrated in FIG.

[0150] 7C, the request at arrow 764 is shown as being generated after block 762, although in other embodiments, the request at arrow 764 may be generated after arrow 760 or between arrow 760 and block 762. That is, GUI 702 may be used to request the next screen before the updated version is obtained by network component 634. In such a case, pre-fetching the updated version of the next UI component may still be beneficial because although the updated version of the next UI screen may appear to take a long time to load, GUI 702 may eventually display the updated version rather than an older version of the next UI screen.

[0151] Repeating the operations of blocks 750-768 may prefetch updated versions of one or more subsequent UI screens, as indicated by arrow 770. Notably, the prefetching of updated versions of UI screens may be considered incremental in that software application 600 may request refreshes of, for example, one older UI screen at a time, rather than all older UI screens at once. Thus, the consumption of computational and / or communication resources associated with refreshing older UI screens that will not ultimately be redisplayed may be reduced and / or eliminated.

[0152] Also, without the preemptive action of Figure 7C, the GUI 702 may instead display older versions of these subsequent UI screens. Although such subsequent screens may be refreshed based on and / or in response to a manual refresh request received by the GUI 702, the user may not know that a manual refresh is necessary. As a result, the user may end up using a manual refresh when it is not necessary, thereby wasting computational and / or communication resources, and / or ultimately causing the user to underuse manual refresh and operate on stale data.

[0153] VII. Exemplary Operations Figure 8 is a flow chart illustrating one exemplary embodiment. The process illustrated by Figure 8 may be performed by a computing device, such as computing device 100, and / or a cluster of computing devices, such as server cluster 200. However, the process may also be performed by other types of devices or device subsystems. For example, the process may be performed by a portable computer, such as a laptop or tablet device, and / or a software application 600.

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

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

[0156] Block 802 may include receiving, by the UI, an interaction with a UI component of a current UI screen of the plurality of UI screens.

[0157] Block 804 may include determining, based on receiving the interaction, a next UI screen of the plurality of UI screens that is expected to be re-displayed after the current UI screen.

[0158] Block 806 may include sending a query to the server device for an updated version of the next UI screen prior to receiving the 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 next UI screen.

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

[0161] In some embodiments, the plurality of UI screens may be received from a server device and stored in a memory. Based on the interaction, the memory may be determined to include 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 a determination that the memory includes an older version of the next UI screen.

[0162] In some embodiments, the software application may include a plurality of UI screens arranged as a plurality of tabs. The current UI screen and the next UI screen may comprise a portion of a first tab of the plurality of tabs. Determining the plurality of UI screens may include, for each tab of the plurality of tabs, determining a corresponding list of one or more UI screens navigated by the UI. Determining that the memory includes an out-of-date version of the next UI screen may include marking each UI screen in the corresponding list of the first tab as out-of-date based on an interaction with a UI component of the current UI screen, and determining that the next UI screen (i) is present in the corresponding list of the first tab and (ii) is marked as out-of-date.

[0163] In some embodiments, the software application may include a plurality of UI screens arranged as a plurality of tabs. The current UI screen may comprise a portion of a first tab of the plurality of tabs, and the next UI screen may comprise a portion of a second tab of the plurality of tabs. Determining the plurality of UI screens may include determining, for each respective one of the plurality of tabs, a corresponding list of one or more UI screens navigated by the UI. Determining that the memory includes an out-of-date version of the next UI screen may include marking each respective UI screen in the corresponding list of each respective one of the plurality of tabs as out-of-date based on an interaction with a UI component of the current UI screen, and determining that the next UI screen (i) is present in the corresponding list of the second tab and (ii) is marked as out-of-date.

[0164] In some embodiments, determining that the memory contains an outdated version of the next UI screen may include obtaining a dependency map indicating 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 the memory has become outdated due to modifications made through the interaction.

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

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

[0167] In some embodiments, determining the plurality of UI screens may include determining an ordered list of the plurality of UI screens based on an order in which the plurality of UI screens are navigated through the UI, and determining the next UI screen may include selecting, from the ordered list, a UI screen that precedes the current UI screen in the ordered list.

[0168] In some embodiments, the software application may include a workflow model that defines an expected order in which navigation of UI screens of the software application is expected, and 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 include selecting the next UI screen using a machine learning model trained to determine a UI screen expected to be next redisplayed by the UI based on one or more of: (i) the current UI screen, (ii) UI components of the current UI screen, (iii) the plurality of UI screens, and / or (iv) a workflow model of the software application.

[0170] In some embodiments, a subsequent UI screen of the plurality of UI screens expected to be re-displayed after the next UI screen may be determined based on the display of an updated version of the next UI screen. A second query for an updated version of the subsequent UI screen may be sent to the server device prior to receiving the second request to navigate to the subsequent UI screen. A second response including the updated version of the subsequent UI screen may be received from the server device. Based on receiving the second request to navigate to the subsequent UI screen, the UI may display an updated version of the subsequent UI screen based on the second response.

[0171] In some embodiments, a subsequent UI screen of the plurality of UI screens expected to be next redisplayed may be determined. Instructions may be generated that are configured to cause the computer system to send to the server device a second query for an updated version of the subsequent UI screen prior to receiving the second request to navigate to the subsequent UI screen. A third request to navigate to the intermediate UI screen may be received prior to receiving from the server device a second response including an updated version of the subsequent UI screen. Based on receiving the third request to navigate to the intermediate UI screen, the second query may be cancelled by clearing instructions or by sending to the server device a cancel request corresponding to the second query.

[0172] In some embodiments, based on receiving the interaction, a second query for an updated version of the current UI screen may be sent to the server device. A second response may be received from the server device, the second response including the updated version of the current UI screen. Based on receiving the second response, the UI may display an updated version of the current UI screen based on the second response.

[0173] In some embodiments, prior to receiving the request to navigate to the next UI screen, a second request to navigate to the intermediate UI screen may be received. Based on receiving 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. A second response including the intermediate UI screen may be received from the server device. Based on receiving the second response, the UI may display the intermediate UI screen based on the second response.

[0174] VIII. Conclusion The present 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 modifications and variations are possible without departing from the scope thereof. From the foregoing description, functionally equivalent methods and apparatuses within the scope of the present disclosure, in addition to those described herein, will be apparent to those skilled in the art. Such modifications and variations are also intended to fall within the scope of the appended claims.

[0175] In the above detailed description, various features and operations of the disclosed system, apparatus, and method are described with reference to the accompanying drawings. The exemplary embodiments described herein and in the drawings are not meant to be limiting in any way. Other embodiments may be utilized and other changes may be made without departing from the scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure as described throughout this specification and illustrated 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, each step, block, and / or communication may represent information processing and / or information transmission according to an exemplary embodiment, as discussed herein. The scope of these exemplary embodiments includes alternative embodiments. In these alternative embodiments, for example, operations described as steps, blocks, transmissions, communications, requests, responses, and / or messages may be performed out of the order shown or described (including substantially simultaneously or in reverse order), depending on the functionality involved. Furthermore, any of the message flow diagrams, scenarios, and flowcharts discussed herein may use more or fewer blocks and / or operations, and some or all of these message flow diagrams, scenarios, and flowcharts may be combined with each other.

[0177] The steps or blocks representing the processing of information may correspond to circuitry that may be configured to perform certain logical functions of the methods or techniques described herein. Alternatively or additionally, the steps or blocks representing the processing of information may correspond to modules, segments, or portions of program code (including associated data). The program code may include one or more instructions executable by a processor to perform certain logical operations or actions in the methods or techniques. The program code and / or associated data may be stored in any type of computer-readable medium, such as a storage device, including a RAM, a disk drive, a solid-state drive, or another storage medium.

[0178] Computer readable media may also include non-transitory computer readable media, such as non-transitory computer readable media that store data for a short period of time, such as register memory and processor cache. Non-transitory computer readable media may further include non-transitory computer readable media that store program code and / or data for a long period of time. Thus, non-transitory computer readable media may include secondary or permanent long-term storage, such as, for example, ROM, optical or magnetic disks, solid-state drives, or compact disk read-only memories (CD-ROMs). Non-transitory computer readable media may also be any other volatile or non-volatile storage system. Non-transitory computer readable media may be considered, for example, computer readable storage media or tangible storage devices.

[0179] Furthermore, steps or blocks depicting one or more information transfers may correspond to information transfers between software and / or hardware modules in the same physical device, although other information transfers are possible between software and / or hardware modules in different physical devices.

[0180] The particular arrangement depicted in the figures should not be construed as limiting in any way. It is understood that other embodiments may show more or fewer elements in a given figure. Further, some of the depicted elements may be combined or omitted. Additionally, an example embodiment may include elements that are not shown in the figures.

[0181] Various aspects and embodiments are disclosed herein, and other aspects and embodiments will be apparent to those of ordinary skill in the art. The various aspects and embodiments disclosed herein are intended to be illustrative and not limiting, with the true scope being indicated by the following claims.

Claims

1. A processor; Memory and When stored in the memory and executed by the processor, determining a plurality of user interface (UI) screens of the software application navigated by a UI of the software application; receiving, by the UI, an interaction with a UI component of a current UI screen of the plurality of UI screens; determining a next UI screen of the plurality of UI screens that is expected to be redisplayed after the current UI screen based on receiving the interaction; 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, the response including the updated version of the next UI screen; upon receiving the request to navigate to the next UI screen, displaying, by the UI, the updated version of the next UI screen based on the response; a software application configured to perform operations including: A computer system comprising:

2. the plurality of UI screens are received from the server device and stored in the memory; The operation, determining, based on the interaction, that the memory contains an older version of the next UI screen, and wherein the query for the updated version of the next UI screen is sent to the server device based on a determination that the memory contains the older version of the next UI screen. The computer system of claim 1 further comprising:

3. the software application includes a plurality of UI screens arranged as a plurality of tabs, the current UI screen and the next UI screen constituting a portion of a first tab of the plurality of tabs; determining the plurality of UI screens includes, for each respective tab of the plurality of tabs, determining a corresponding list of one or more UI screens navigated by the UI; determining that the memory contains the old version of the next UI screen; marking each UI screen in the corresponding list of the first tab as outdated based on the interaction with the UI component of the current UI screen; determining that the next UI screen (i) is in the corresponding list of the first tab and (ii) is marked as old; 3. The computer system of claim 2, comprising:

4. the software application includes a plurality of UI screens arranged as a plurality of tabs, the current UI screen constituting a portion of a first tab of the plurality of tabs and the next UI screen constituting a portion of a second tab of the plurality of tabs; determining the plurality of UI screens includes, for each respective tab of the plurality of tabs, determining a corresponding list of one or more UI screens navigated by the UI; determining that the memory contains the old version of the next UI screen; marking each respective UI screen in the corresponding list for each respective tab of the plurality of tabs as outdated based on the interaction with the UI components of the current UI screen; determining that the next UI screen (i) is in the corresponding list of the second tab and (ii) is marked as old; 3. The computer system of claim 2, comprising:

5. determining that the memory contains the old version of the next UI screen; obtaining a dependency map indicating data dependencies shared by at least the current UI screen and the next UI screen; determining, based on the dependency map, that a version of the next UI component stored in the memory has become out of date due to a modification made by the interaction; 3. The computer system of claim 2, comprising:

6. The computer system of claim 1 , wherein the interaction with the UI component is configured to make a modification to data displayed by the current UI screen.

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

8. determining the plurality of UI screens includes determining an ordered list of the plurality of UI screens based on an order in which the plurality of UI screens are navigated by the UI; 2. The computer system of claim 1, wherein determining the next UI screen comprises selecting from the ordered list a UI screen that precedes the current UI screen in the ordered list.

9. The software application includes a workflow model that defines an expected order in which navigation of UI screens of the software application is expected, and determining the next UI screen comprises: Selecting the next UI screen based on the workflow model.

2. The computer system of claim 1, comprising:

10. determining the next UI screen; selecting the next UI screen using a machine learning model trained to determine a UI screen expected to be next re-displayed by the UI based on one or more of: (i) the current UI screen; (ii) the UI components of the current UI screen; (iii) the plurality of UI screens; or (iv) a workflow model of the software application.

2. The computer system of claim 1, comprising:

11. The operation, determining a subsequent UI screen of the plurality of UI screens that is expected to be re-displayed after the next UI screen based on the display of the updated version of the next UI screen; sending a second query to the server device for an updated version of the subsequent UI screen prior to receiving a second request to navigate to the subsequent UI screen; receiving a second response from the server device, the second response including the updated version of the subsequent UI screen; upon receiving the second request to navigate to the subsequent UI screen, displaying, by the UI, the updated version of the subsequent UI screen based on the second response; The computer system of claim 1 further comprising:

12. determining a subsequent UI screen among the plurality of UI screens that is expected to be redisplayed next; generating instructions configured to cause the computer system to send a second query to the server device for an updated version of the subsequent UI screen prior to receiving a second request to navigate to the subsequent UI screen; receiving a third request to navigate to an intermediate UI screen prior to receiving a second response from the server device including the updated version of the subsequent UI screen; canceling the second query by erasing the instruction or sending a cancel request corresponding to the second query to the server device upon receiving the third request to navigate to the intermediate UI screen; and The computer system of claim 1 further comprising:

13. The operation, sending a second query to the server device for an updated version of the current UI screen based on receiving the interaction; receiving a second response from the server device, the second response including the updated version of the current UI screen; upon receiving the second response, displaying, by the UI, the updated version of the current UI screen based on the second response; and The computer system of claim 1 further comprising:

14. The operation, receiving a second request to navigate to an intermediate UI screen prior to receiving the request to navigate to the next UI screen; sending a second query for the intermediate UI screen to the server device based on receiving the second request to navigate to the intermediate UI screen; receiving a second response from the server device, the second response including the intermediate UI screen; upon receiving the second response, displaying, by the UI, the intermediate UI screen based on the second response; The computer system of claim 1 further comprising:

15. determining a plurality of user interface (UI) screens of a software application navigated by a UI of the software application; receiving, by the UI, an interaction with a UI component of a current UI screen of the plurality of UI screens; determining a next UI screen of the plurality of UI screens that is expected to be redisplayed after the current UI screen based on receiving the interaction; 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, the response including the updated version of the next UI screen; upon receiving the request to navigate to the next UI screen, displaying, by the UI, the updated version of the next UI screen based on the response; 4. A computer-implemented method comprising:

16. the plurality of UI screens are received from the server device and stored in a memory of a computing device configured to run the software application, the method comprising: determining, based on the interaction, that the memory contains an older version of the next UI screen, and wherein the query for the updated version of the next UI screen is sent to the server device based on a determination that the memory contains the older version of the next UI screen.

16. The computer-implemented method of claim 15, further comprising:

17. the software application includes a plurality of UI screens arranged as a plurality of tabs, the current UI screen and the next UI screen constituting a portion of a first tab of the plurality of tabs; determining the plurality of UI screens includes, for each respective tab of the plurality of tabs, determining a corresponding list of one or more UI screens navigated by the UI; determining that the memory contains the old version of the next UI screen; marking each UI screen in the corresponding list of the first tab as outdated based on the interaction with the UI component of the current UI screen; determining that the next UI screen (i) is in the corresponding list of the first tab and (ii) is marked as old; 20. The computer-implemented method of claim 16, comprising:

18. the software application includes a plurality of UI screens arranged as a plurality of tabs, the current UI screen constituting a portion of a first tab of the plurality of tabs and the next UI screen constituting a portion of a second tab of the plurality of tabs; determining the plurality of UI screens includes, for each respective tab of the plurality of tabs, determining a corresponding list of one or more UI screens navigated by the UI; determining that the memory contains the old version of the next UI screen; marking each respective UI screen in the corresponding list for each respective tab of the plurality of tabs as outdated based on the interaction with the UI components of the current UI screen; determining that the next UI screen (i) is in the corresponding list of the second tab and (ii) is marked as old; 20. The computer-implemented method of claim 16, comprising:

19. determining the plurality of UI screens includes determining an ordered list of the plurality of UI screens based on an order in which the plurality of UI screens are navigated by the UI; 16. The computer-implemented method of claim 15, wherein determining the next UI screen comprises selecting a UI screen from the ordered list that precedes the current UI screen in the ordered list.

20. By execution by a computer system, determining a plurality of user interface (UI) screens of a software application navigated by a UI of the software application; receiving, by the UI, an interaction with a UI component of a current UI screen of the plurality of UI screens; determining a next UI screen of the plurality of UI screens that is expected to be redisplayed after the current UI screen based on receiving the interaction; 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, the response including the updated version of the next UI screen; upon receiving the request to navigate to the next UI screen, displaying, by the UI, the updated version of the next UI screen based on the response; 20. An article of manufacture comprising a non-transitory computer-readable medium having stored thereon program instructions that cause said computer system to perform operations including:

Images