Asynchronous write request management

Systems and methods provide techniques for more effective read/write management in collaborative data interaction frameworks. In response, embodiments of the present invention provide methods, apparatuses, systems, computing devices, and/or the like that are configured to enable effective and efficient read/write management in collaborative data interaction frameworks. For example, certain embodiments of the present invention provide methods, apparatuses, systems, computing devices, and/or the like that are configured to read/write management in collaborative data interaction frameworks using techniques that utilize asynchronous write request management along with partially decoupled read request management.

BACKGROUND

Various methods, apparatuses, and systems are configured to provide techniques for read/write management in collaborative data interaction frameworks. Applicant has identified many deficiencies and problems associated with existing methods, apparatuses, and systems for read/write management in collaborative data interaction frameworks. Through applied effort, ingenuity, and innovation, these identified deficiencies and problems have been solved by developing solutions that are in accordance with the embodiments of the present invention, many examples of which are described in detail herein.

BRIEF SUMMARY

In general, embodiments of the present invention provide methods, apparatuses, systems, computing devices, and/or the like that are configured to enable effective and efficient read/write management in collaborative data interaction frameworks. For example, certain embodiments of the present invention provide methods, apparatuses, systems, computing devices, and/or the like that are configured to read/write management in collaborative data interaction frameworks using techniques that utilize asynchronous write request management along with partially decoupled read request management.

In accordance with one aspect, a computer-implemented method is provided. In one embodiment, the computer-implemented method comprises: receiving a read request for a data object identifier from a client computing device; in response to receiving the read request, determining a match status for the data object identifier based on an unprocessed write request ledger, wherein the match status describes an affirmative match status when the unprocessed write request ledger comprises one or more unprocessed sequence numbers that describe one or more unprocessed write requests for the data object identifier; in response to determining that the match status describes the affirmative match status, generating an update data object associated with the data object identifier based on a latest state of target data associated with the data object identifier as soon as one of a plurality of data retrieval conditions is satisfied, wherein the plurality of data retrieval conditions comprise a first data retrieval condition that is satisfied when all of the one or more unprocessed write requests are marked as processed and a second data retrieval condition that is satisfied when a waiting period is expired; and transmitting the update data object to the client computing device.

In accordance with another aspect, a computer program product is provided. The computer program product may comprise at least one computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising executable portions configured to: receive a read request for a data object identifier from a client computing device; in response to receiving the read request, determine a match status for the data object identifier based on an unprocessed write request ledger, wherein the match status describes an affirmative match status when the unprocessed write request ledger comprises one or more unprocessed sequence numbers that describe one or more unprocessed write requests for the data object identifier; in response to determining that the match status describes the affirmative match status, generate an update data object associated with the data object identifier based on a latest state of target data associated with the data object identifier as soon as one of a plurality of data retrieval conditions is satisfied, wherein the plurality of data retrieval conditions comprise a first data retrieval condition that is satisfied when all of the one or more unprocessed write requests are marked as processed and a second data retrieval condition that is satisfied when a waiting period is expired; and transmit the update data object to the client computing device.

In accordance with yet another aspect, an apparatus comprising at least one processor and at least one memory including computer program code is provided. In one embodiment, the at least one memory and the computer program code may be configured to, with the processor, cause the apparatus to: receive a read request for a data object identifier from a client computing device; in response to receiving the read request, determine a match status for the data object identifier based on an unprocessed write request ledger, wherein the match status describes an affirmative match status when the unprocessed write request ledger comprises one or more unprocessed sequence numbers that describe one or more unprocessed write requests for the data object identifier; in response to determining that the match status describes the affirmative match status, generate an update data object associated with the data object identifier based on a latest state of target data associated with the data object identifier as soon as one of a plurality of data retrieval conditions is satisfied, wherein the plurality of data retrieval conditions comprise a first data retrieval condition that is satisfied when all of the one or more unprocessed write requests are marked as processed and a second data retrieval condition that is satisfied when a waiting period is expired; and transmit the update data object to the client computing device.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

Overview

Various embodiments of the present invention address technical problems associated with managing read and write requests in an environment that enables multiple users to collaboratively and substantially simultaneously both read and write data accessed by a data server computing device. An example of such an environment is a Confluence® knowledge management environment developed and owned by Atlassian PTY LTD, which enables multiple users to collaboratively and simultaneously edit (e.g., leave comments on) a page or page and view such page or page.

Managing read and write requests can be challenging in such a collaborative real-time environment. It is desirable but difficult to achieve for such a collaborative system to operate in a manner that increases the likelihood that read requests promptly return the most updated versions of shared data objects while also decreasing both write request processing latency (i.e., the time it takes for a write request to be processed) and read request processing latency (i.e., the time it takes for a read request to be processed, and the time for any response to the read request to be generated and returned to the client device).

To illustrate one aspect of this challenge, consider the following scenario. A first user, Tom, has created a first content data item describing updates to a new human resources policy. A second user, Jane, annotates the first content data item with a second content data item (“Looks good Tom”) using her client device thereby generating a write request that is transmitted to a data server computing device at time t0. At approximately the same time, a third user, Fred, annotates the page with a third content data item (“Tom let's also consider a HIPAA section”) using his client device thereby generating a second write request that is transmitted to the data server computing device. At substantially the same time, a fourth user, Sally, attempts to load the first content data item using her client device thereby transmitting a read request to the data server computing device. The data server and computing device must be configured to process Jane's first write request and Fred's write request in order to provide Sally with the most up to date content data without introducing undue read latency.

To address the above-noted challenges concerning processing of temporally proximate write requests and read requests, various embodiments of the present invention disclose and implement two related concepts: asynchronous write request management and partially decoupled read request management. Asynchronous write request management means that write requests are processed through a procedure that is performed independent of and irrespective of any temporally proximate read requests. Partially decoupled read request management means that, when processing a read request for a data object that is associated with one or more unprocessed write requests, a computer system waits for the unprocessed write requests to be processed, but this waiting time cannot exceed a maximum waiting period that is selected to mitigate read latency concerns. Accordingly, in various embodiments, while processing a read request takes into account whether a corresponding data object is associated with unprocessed write requests prior to generating output data corresponding to the read request, this consideration is limited in duration in order to reduce read request processing latency.

By using asynchronous write request management and partially decoupled read request management, a computer system can process read requests for a data object identifier through a procedure that is partially decoupled from the procedure for processing write requests for the data object identifier, a technique that in turn can reduce read request processing latency without introducing data reliability risks imposed by a total decoupling of read request processing procedures and write request processing procedures. Accordingly, by introducing techniques for performing asynchronous write request management and partially decoupled read request management, various embodiments of the present invention make important technical contributions to improving efficiency and reliability of read/write management in collaborative data interaction systems and networks.

Definitions

The terms “computer-readable storage medium” refers to a non-transitory, physical or tangible storage medium (e.g., volatile or non-volatile memory), which may be differentiated from a “computer-readable transmission medium,” which refers to an electromagnetic signal.

The term “client computing device” refers to a combination of computer hardware and/or software that is configured to access a service made available by a server. The server is often (but not always) on another computer system, in which case the client accesses the service by way of a network. Client computing devices may include, without limitation, smart phones, tablet computers, laptop computers, wearables, personal computers, enterprise computers, and the like.

The term “server computing device” refers to a combination of computer hardware and/or software that is configured to provide a service to a client device. An example of a server computing device is the data server computing device106ofFIG. 1. In some embodiments, a server computing device communicates with one or more client computing devices using one or more computer networks.

The term “read request” describes a data entity generated by a client computing device and transmitted to a data server computing device by the client computing device, where the data entity describes a request by the client computing device to retrieve an update data object describing a latest state of target data associated with a corresponding data object identifier. The data entity is further configured to trigger operations by the data server computing device to generate the update data object and transmit the update data object to the client computing device. Examples of read requests include requests generated when a user profile requests to open a user interface that is configured to display target data associated with a data object identifier, requests generated when a user profile requests to refresh an already-opened user interface that is configured to display target data associated with a data object identifier, and requests generated when a client computing device seeks to automatically (e.g., periodically) refresh an already-opened user interface that is configured to display target data associated with a data object identifier. In some embodiments, the read request is generated by a client computing device and subsequently transmitted to a data server computing device in response to an end-user request by an end-user of the client computing device to refresh a page data object being hosted on a storage subsystem associated with the data server computing device. An example of a read request is the request triggered by Sally's action in the exemplary scenario described in the Overview section of the present document.

The term “write request” describes a data entity generated by a client computing device and transmitted to a data server computing device by the client computing device, where the data entity identifies a corresponding data object identifier. The write request describes a request by the client computing device to append write request data associated with the write request to target data associated with the corresponding data object identifier. The data entity is further configured to trigger operations by the data server computing device to persistently store the write request data as part of the target data. Examples of write requests include requests to add content to a page object identifier, requests to add annotations to a page object identifier, requests to add comments to a page object identifier, etc. In some embodiments, the write request is generated by a client computing device and subsequently transmitted to a data server computing device in response to an end-user request by an end-user of the client computing device to modify a page data object being hosted on a storage subsystem associated with the data server computing device. Examples of write requests include requests triggered by actions of Jane and Fred in the scenario described in the Overview section of the present document.

The term “unprocessed sequence number” describes a data entity generated by a data server computing device in response to receiving a write request for a data object identifier, where the data entity uniquely identifies the write request. The unprocessed sequence number is configured to be stored as part of an unprocessed write request ledger in a storage subsystem associated the data server computing device until the corresponding write request is processed. In some embodiments, given an unprocessed write request that is associated with a particular content data item that is added to a particular data object identifier, the unprocessed sequence number for the write request is stored as part of an unprocessed write request ledger for the data object identifier until the related data associated with the particular content data item is persistently stored as part of the related data associated with the data object identifier. The unprocessed sequence number for a particular write request may be a randomly-generated number, may be an incrementing sequence number, or may be a number that is generated by the data server computing device by incrementing the write request for a previously-received write request.

The term “target data” describes one or more data collections generated by a data server computing device and maintained in a storage subsystem associated with the data server computing device. The target data is generated based on processed write requests associated with a corresponding data object identifier. The target data is used by the data server computing device to generate update data objects in response to receiving read requests associated with the corresponding data object. In some embodiments, the target data associated with a data object identifier includes content target data that describes contents of the data object identifier (e.g., contents of a page object identifier, such as contents of comments appended to the page object identifier) and target metadata of the data object identifier (e.g., target metadata of a page object identifier, such as target metadata of comments appended to the page object identifier). In some embodiments, the content target data and the target metadata are stored in separate (e.g., distributed) data storage units. Examples of target data include data describing the content data created by Tom in the scenario described in the Overview section of the present document, as modified via processing the write requests generated as a result of Jane's actions and Fred's action.

The term “write request data” describes one or more portions of a write request that collectively describe features of one or more modifications to the corresponding data object identifier that is associated with the write request. The write request data is configured to be stored as part of the target data associated with the corresponding data object identifier. An example of a write request data is the data associated with a user-provided comment for a page object identifier. In some embodiments, write request data for a corresponding write request include write request content data associated with the corresponding write request and write request metadata associated with the corresponding write request. Examples of write request content data include data describing contents of a comment, while examples write request metadata include metadata features associated with a comment, such as data describing author of a comment, a posting time of a comment, etc. Examples of write request data include data associated with the first content data item, the second content data item, and the third content data item as described in the exemplary embodiment described in the Overview section of the present document.

The term “unprocessed write request” describes a write request whose corresponding write request data have not been persistently stored as part of the target data for a corresponding data object identifier. In contrast, the term “processed write request” describes a write request whose corresponding write request data have been persistently stored as part of the target data for a corresponding data object identifier. In some embodiments, when a data server computing device first receives a write request from a client computing device, the write request is deemed unprocessed until the data server computing device persistently stores the write request data associated with the write request as part of the target data for the corresponding data object identifier, after which the write request is deemed processed. In some embodiments, to identify unprocessed write requests associated with a data object identifier, a data server computing device stores identifiers for the unprocessed write requests (e.g., unprocessed sequence numbers for the unprocessed write requests) as part of an unprocessed write request ledger for the data object identifier. In some embodiments, to process an unprocessed write request, a data server computing device stores write request data associated with the unprocessed write request (e.g., write request content data associated with the write request and/or write request metadata associated with the write request) as part of the target data associated with a corresponding data object identifier. For example, with respect to the exemplary scenario described in the Overview section of the present document, when a write request corresponding to the second content data item or the third content data item is first received, the noted write request is deemed unprocessed until the write request data associated with the write request is integrated into the target data associated with the first content data item, at which point the write request is deemed processed.

The term “unprocessed write request ledger” describes a data entity that is generated by a data server computing device and stored as part of a storage subsystem associated with the data server computing device. The unprocessed write request ledger describes each unprocessed sequence number for an unprocessed write request that is associated with a corresponding data object identifier. The unprocessed write request ledger may, for example, be a queue data object that is updated in a first-in-first-out manner. An example of an unprocessed write request ledger is a data entity that identifies all incoming comments for a page object identifier whose corresponding comment data (e.g., whose corresponding comment content data and/or corresponding comment metadata) have not been persistently stored as part of the page data for the page object identifier. In some embodiments, in response to processing an unprocessed write request by storing the write request data associated with the write request as part of the target data for a corresponding data object identifier, the unprocessed write request ledger for the corresponding data object identifier is updated by removing the previously-unprocessed write request from the unprocessed write request ledger. For example, with respect to the exemplary scenario described in the Overview section of the present document, when a write request corresponding to the second content data item or the third content data item is deemed unprocessed, an unprocessed sequence number associated with the write request is deemed as part of the unprocessed write request ledger and in a portion (e.g., a queue) of the unprocessed write request ledger that is associated with the first content data item.

The term “update data object” describes a data entity that is generated by a data server computing device, where the data entity is transmitted by the data server computing device to a client computing device in response to receiving a read request for a corresponding data object identifier. The data server computing device is configured to describe one or more modifications to target data associated with the corresponding data object identifier and enable the client computing device to display the one or more modifications as part of a user interface configured to display the target data associated with the corresponding data object identifier. In some embodiments, the update data object for a corresponding data object identifier describes all of the available target data associated with the corresponding data object identifier. In some other embodiments, the update data object for a corresponding data object identifier comprises all of the modifications to the target data associated with the corresponding data object identifier that have not been described by previously-transmitted updated data objects that have been transmitted by the data server computing device to an applicable client computing device. For example, upon receiving a request to refresh a page object identifier, instead of transmitting an update data object that describes all of the data fields associated with the page object identifier, the data server computing device may transmit only the modifications to the page object identifier that have been recorded/processed since a previously-processed refreshing of the page object identifier. In some embodiments, an update data object for a corresponding data object identifier may be generated based on expediated retrieval data associated with the corresponding data object identifier that are stored on an in-memory cash storage framework of the data server computing device.

The term “set of data retrieval conditions” describes a data entity that is stored by a storage subsystem associated with a data server computing device as part of the configuration data for the data server computing device. The data retrieval conditions are a group of two or more conditions, where the configuration data further describes that satisfaction of one of (e.g., an earliest-satisfied one of) the two or more conditions is a sufficient prerequisite for generating an updated data object for a corresponding data object identifier based on a latest state of target data for the corresponding data object identifier that is available at the time of the satisfaction. For example, in some embodiments, the set of data retrieval conditions consist of two conditions: a first condition that is satisfied if one or more identified unprocessed write requests for a corresponding data object identifier are marked as processed and a second condition that is satisfied if a waiting period (e.g., a waiting period of 300 milliseconds after receiving a read request for the corresponding data object identifier from a client computing device) expires. Thus, in some embodiments, upon receiving a read request for a corresponding data object identifier that is associated with one or more unprocessed write requests and in response to determining an affirmative match status for the corresponding data object identifier, the data server computing device waits until the earlier of the expiration of a waiting period or processing of the one or more unprocessed write requests before generating the update data object based on the latest state of the target data associated with the corresponding data object identifier.

The term “expediated retrieval data” describes a data entity that is generated by a data server computing device based on a latest state of the target data associated with a corresponding data object identifier. The expediated retrieval data is stored as part of an in-memory cache storage unit for the data server computing device in order to facilitate expediated data retrieval of data associated with the corresponding data object identifier when responding to a read request associated with the corresponding data object identifier. The data entity is further used to generate an update data object for the corresponding data object identifier in response to the read requests associated with the corresponding data object identifier. The expediated retrieval data may at each time describe which write requests associated with a corresponding data object identifier have been processed. In some embodiments, the expediated retrieval data are graph-based data, such as data describing comments to a corresponding page object identifier as graph-based relationships (e.g., edges) of a central node associated with the corresponding page object identifier. In some of the noted embodiments, the read request associated with the corresponding page object identifier is a graph-based query, such as Graph Query Language (GraphQL) query. For example, with respect to the exemplary scenario described in the Overview section of the present document, expediated retrieval data for the first content data item may be generated based on whether the second content data item has been processed and based on whether the third content data item has been processed.

The term “match status” describes a data entity that is generated by a data server computing device based on the unprocessed write request ledger for the data server computing device. The match status describes whether the unprocessed write request ledger includes at least one unprocessed sequence number for an unprocessed write request that is associated with a corresponding data object identifier. In some embodiments, the match status embodies a determination that the unprocessed write request ledger includes at least one unprocessed sequence number that is associated with an unprocessed write request for the data object identifier. Accordingly, if the unprocessed write request ledger includes at least one unprocessed sequence number for the data object identifier, the match status for the data object identifier describes an affirmative match status, which indicates that at least one write request associated with the data object identifier remains unprocessed at the time of processing the read request associated with the write request. Moreover, if the processed write request ledger includes no unprocessed sequence numbers for the data object identifier, the match status for the data object identifier describes a negative match status, which indicates that no write request associated with the data object identifier remains unprocessed at the time of processing the read request associated with the write request.

Example System Architecture

FIG. 1depicts an exemplary architecture100for performing asynchronous write request management along with partially decoupled read request management. The architecture100includes one or more client computing devices102and a data server computing device106. The client computing devices102may be configured to transmit read requests and write requests to the data server computing device106, and the data server computing device106may be configured to process the read requests and the write requests and return output data to the client computing devices102in response to the read requests.

The client computing devices102and the data server computing device106may communicate over one or more networks. A network may include any wired or wireless communication network including, for example, a wired or wireless local area network (LAN), personal area network (PAN), metropolitan area network (MAN), wide area network (WAN), or the like, as well as any hardware, software and/or firmware required to implement it (such as, e.g., network routers, etc.). For example, a network may include a cellular telephone, an 802.11, 802.16, 802.20, and/or WiMax network. Further, a network may include a public network, such as the Internet, a private network, such as an intranet, or combinations thereof, and may utilize a variety of networking protocols now available or later developed including, but not limited to Transmission Control Protocol/Internet Protocol (TCP/IP) based networking protocols. For instance, the networking protocol may be customized to suit the needs of the page management system. In some embodiments, the protocol is a custom protocol of JavaScript Object Notation (JSON) objects sent via a Websocket channel. In some embodiments, the protocol is JSON over RPC, JSON over REST/HTTP, and the like.

The depicted data server computing device106includes a workflow manager111, a real-time event manager112, an in-flight service114, a write request processing manager116, and a read interface118. The data server computing device106may also be configured to store, on the storage subsystem108of the data server computing device106, an unprocessed write request ledger113and target data117for data object identifiers. Furthermore, the storage subsystem108may include an in-memory cache storage unit115. The storage subsystem108of the data server computing device106may include one or more storage units, where each storage unit may store at least one of one or more data assets and/or one or more data about the computed properties of one or more data assets. Moreover, each storage unit may include one or more non-volatile storage or memory media including but not limited to hard disks, ROM, PROM, EPROM, EEPROM, flash memory, MMCs, SD memory cards, Memory Sticks, CBRAM, PRAM, FeRAM, NVRAM, MRAM, RRAM, SONOS, FJG RAM, Millipede memory, racetrack memory, and/or the like.

The depicted workflow manager111is configured to manage higher-level workflows that cause the data server computing device106to perform asynchronous write request management along with partially decoupled read request management. For example, the workflow manager111may trigger write request processing operations by communicating with the real-time event manager, which in turn may cause the real-time event manager to communicate with the write request processing manager116to cause the write request processing manager116to process unprocessed write requests. As another example, the workflow manager1111may generate unprocessed sequence numbers for incoming write requests and store the unprocessed sequence numbers as part of the unprocessed write request ledger113. As yet another example, the workflow manager111may generate update data objects based on read requests and based on the expediated retrieval data stored in the in-memory cache storage unit115of the storage subsystem108.

The real-time event manager112may be configured to facilitate expediated processing of write requests by transmitting real-time processing requests to the write request processing manager116and the in-flight service114. For example, the real-time event manager112may cause the write request processing manager116to process a write request by transmitting a corresponding message to the write request processing manager116. As another example, the real-time event manager112may cause the in-flight service114to retrieve target data117and update the expediated retrieval data that is stored on the in-memory cache storage unit115based on the retrieved target data117. In some embodiments, the real-time event manager112is an Apache Kafka engine. Relatedly, the in-flight service114may be configured to update expediated retrieval data based on a latest state of the target data117that is stored on the storage subsystem108, while the write request processing manager116may be configured to process a write request by storing the write request data associated with the write request as part of the target data117for the data object identifier that is associated with the write request. In some embodiments, the write request processing manager116is further configured to, subsequent to processing a write request, remove the unprocessed sequence number for the write request from the unprocessed write request ledger113.

The read interface118may be configured to provide an interface for processing of read requests that are received from the client computing devices102. For example, the read interface118may be configured to receive read requests, provide the read requests to the workflow manager111, obtain update data objects for read requests from the workflow manager111, and provide the update data objects to the client computing devices102in response to the received read requests. In some embodiments, the read interface118is a graph-based database interface, such as a GraphQL interface.

The unprocessed write request ledger113and the target data117that are stored as part of the storage subsystem108are discussed in greater detail throughout the data. As alluded to above, the storage subsystem108also stores expediated retrieval data on the in-memory cache storage unit115. The in-memory cache storage unit115is a fast storage medium that can facilitate expediated retrieval of the noted expediated retrieval data.

Exemplary Data Server Computing Device

The data server computing device106may be embodied by one or more computing systems, such as apparatus200shown inFIG. 2. The apparatus200may include processor202, memory204, input/output circuitry206, communications circuitry208, and a page presentation module210. The apparatus200may be configured to execute the operations described herein. Although these components202-210are described with respect to functional limitations, it should be understood that the particular implementations necessarily include the use of particular hardware. It should also be understood that certain of these components202-210may include similar or common hardware. For example, two sets of circuitries may both leverage use of the same processor, network interface, storage medium, or the like to perform their associated functions, such that duplicate hardware is not required for each set of circuitries.

In some preferred and non-limiting embodiments, the processor202may be configured to execute instructions stored in the memory204or otherwise accessible to the processor202. In some preferred and non-limiting embodiments, the processor202may be configured to execute hard-coded functionalities. As such, whether configured by hardware or software methods, or by a combination thereof, the processor202may represent an entity (e.g., physically embodied in circuitry) capable of performing operations according to an embodiment of the present invention while configured accordingly. Alternatively, as another example, when the processor202is embodied as an executor of software instructions, the instructions may specifically configure the processor202to perform the algorithms and/or operations described herein when the instructions are executed.

The communications circuitry208may be any means such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to receive and/or transmit data from/to a network and/or any other device, circuitry, or module in communication with the apparatus200. In this regard, the communications circuitry208may include, for example, a network interface for enabling communications with a wired or wireless communication network. For example, the communications circuitry208may include one or more network interface cards, antennae, buses, switches, routers, modems, and supporting hardware and/or software, or any other device suitable for enabling communications via a network. Additionally or alternatively, the communications circuitry208may include the circuitry for interacting with the antenna/antennae to cause transmission of signals via the antenna/antennae or to handle receipt of signals received via the antenna/antennae.

The page presentation module210may be any means such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to present user interface data associated with a page that is associated with a read request to a requesting computing device. In some embodiments, the page presentation module210may be configured to process read requests in accordance with techniques disclosed herein for partially decoupled processing of read requests.

Exemplary Client Computing Device

Referring now toFIG. 3, a client computing device (e.g., a client computing device that is a limited interaction device or a client computing device that is a non-limited interaction device) may be embodied by one or more computing systems, such as apparatus300shown inFIG. 3. The apparatus300may include processor302, memory304, input/output circuitry306, communications circuitry308, and a page interaction module310. Although these components302-310are described with respect to functional limitations, it should be understood that the particular implementations necessarily include the use of particular hardware. It should also be understood that certain of these components302-310may include similar or common hardware. For example, two sets of circuitries may both leverage use of the same processor, network interface, storage medium, or the like to perform their associated functions, such that duplicate hardware is not required for each set of circuitries.

In some preferred and non-limiting embodiments, the processor302may be configured to execute instructions stored in the memory304or otherwise accessible to the processor302. In some preferred and non-limiting embodiments, the processor302may be configured to execute hard-coded functionalities. As such, whether configured by hardware or software methods, or by a combination thereof, the processor302may represent an entity (e.g., physically embodied in circuitry) capable of performing operations according to an embodiment of the present invention while configured accordingly. Alternatively, as another example, when the processor302is embodied as an executor of software instructions (e.g., computer program instructions), the instructions may specifically configure the processor302to perform the algorithms and/or operations described herein when the instructions are executed.

In some embodiments, the apparatus300may include input/output circuitry306that may, in turn, be in communication with processor302to provide output to the user and, in some embodiments, to receive an indication of a user input. The input/output circuitry306may comprise a user interface and may include a display, and may comprise a web user interface, a mobile application, a query-initiating computing device, a kiosk, or the like.

In embodiments in which the apparatus300is embodied by a limited interaction device, the input/output circuitry306includes a touch screen and does not include, or at least does not operatively engage (i.e., when configured in a table mode), other input accessories such as tactile keyboards, track pads, mice, etc. In other embodiments in which the apparatus is embodied by a non-limited interaction device, the input/output circuitry306may include may include at least one of a tactile keyboard (e.g., also referred to herein as keypad), a mouse, a joystick, a touch screen, touch areas, soft keys, and other input/output mechanisms. The processor and/or user interface circuitry comprising the processor may be configured to control one or more functions of one or more user interface elements through computer program instructions (e.g., software and/or firmware) stored on a memory accessible to the processor (e.g., memory304, and/or the like).

The communications circuitry308may be any means such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to receive and/or transmit data from/to a network and/or any other device, circuitry, or module in communication with the apparatus300. In this regard, the communications circuitry308may include, for example, a network interface for enabling communications with a wired or wireless communication network. For example, the communications circuitry308may include one or more network interface cards, antennae, buses, switches, routers, modems, and supporting hardware and/or software, or any other device suitable for enabling communications via a network. Additionally or alternatively, the communications circuitry308may include the circuitry for interacting with the antenna/antennae to cause transmission of signals via the antenna/antennae or to handle receipt of signals received via the antenna/antennae.

The page interaction module310may be any means such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to receive an update data object for a page and present the update data object using a user interface that is configured to display content data associated with the page. For example, the page interaction module310may be configured to display the user interface using a native user interface rendering engine and/or using a web-based user interface rendering engine, such as a web-based user interface engine that is configured to display user interfaces using a web browser.

Example Data Flows and Operations

Provided below are techniques for performing asynchronous write request management along with partial decoupling of read request management from write request management. By using the below-described techniques, the data server computing device106can reduce read request processing latency without tolerating extreme data reliability risks imposed by a total decoupling of read request processing procedures and write request processing procedures. However, while various embodiments of the present invention describe the asynchronous write request management concepts and the partially decoupled read request management concepts of the present invention as being implemented collectively, a person of ordinary skill in the relevant technology will recognize that each of the asynchronous write request management concepts and the partially decoupled read request management concepts can be implemented without implementing the other.

The below-described techniques can address technical problems associated with managing read and write requests in an environment that enables multiple users to collaboratively and substantially simultaneously both read and write data accessed by a data server computing device. To address the challenges concerning processing of temporally proximate write requests and read requests, various embodiments of the present invention disclose and implement two related concepts: asynchronous write request management and partially decoupled read request management. For example, in various embodiments of the present invention, while processing a read request takes into account whether a corresponding data object is associated with unprocessed write requests prior to generating output data corresponding to the read request, this consideration is limited in duration in order to reduce read request processing latency. By using the described techniques, the noted embodiments of the present invention can reduce read request processing latency without introducing data reliability risks imposed by a total decoupling of read request processing procedures and write request processing procedures.

Asynchronous Write Request Management

FIG. 4is a flowchart diagram of an example process400for asynchronously processing a write request. Via the various operations of the process400, the data server computing device106can process write requests for a data object identifier through a procedure that is partially decoupled from the procedure for processing read requests for the data object identifier, a technique that in turn can reduce read request processing latency without tolerating the data reliability risks imposed by a total decoupling of read request processing procedures and write request processing procedures.

The process400begins at operation401when the data server computing device106receives the write request for the data object identifier from a client computing device102. As discussed above, a write request may describe a request by the client computing device102to append write request data associated with the write request to target data associated with the corresponding data object identifier. In some embodiments, the write request is configured to trigger operations by the data server computing device106to persistently store the write request data as part of the target data for the data object identifier. Examples of write requests include requests to add content to a page object identifier, requests to add annotations to a page object identifier, requests to add comments to a page object identifier, etc. In some embodiments, a write request is generated by a client computing device102and subsequently transmitted to a data server computing device106in response to an end-user request by an end-user of the client computing device to modify a page data object being hosted on a storage subsystem associated with the data server computing device106.

An operational example of performing the operation401is depicted inFIG. 6A. As depicted inFIG. 6A, to perform the operation401in order to receive the write request for the data object identifier from the client computing device A102A, the workflow manager111of the data server computing device106performs operation611that is configured to receive the write request from the client computing device A102A. With respect to the exemplary scenario described in the Overview section of the present document, at operation611, the workflow manager111may receive two write requests: a first write request that is generated based on Jane's actions and a second write request that is generated based on Fred's actions. For example, the workflow manager111of a data server computing device106that is associated with a collaborative page management system (e.g., the Confluence® system) may receive a write request for a page object identifier that describes addition of one or more content data items (e.g., one or more comment data items, one or more page data items, one or more document data items, and/or the like) to the page object identifier. As further depicted inFIG. 6A, in some embodiments, subsequent to receiving the write request from the client computing device A102A at operation611, the workflow manager111proceeds to operation612, which is configured to transmit data describing the write request to the real-time event manager112of the data server computing device106. With respect to the exemplary scenario described in the Overview section of the present document, at operation612, the workflow manager111may transmit data describing each write request to the real-time event manager112. For example, in embodiments in which the real-time event manager112is an Apache Kafka engine, the workflow manager111may perform operation612by pushing one or more Kafka messages corresponding to events defined based on the received write request to the Apache Kafka engine.

Returning toFIG. 4, at operation402, the data server computing device106updates an unprocessed write request ledger for the data object identifier based on the write request. As discussed above, the unprocessed write request ledger may describe each unprocessed sequence number for an unprocessed write request that is associated with the data object identifier, for example as part of a component of the unprocessed write request ledger that includes all of the unprocessed write requests for the particular data object identifier. The unprocessed write request ledger may, for example, be a queue data object that is updated in a first-in-first-out manner. An example of an unprocessed write request ledger is a data entity that identifies all incoming comments for a page object identifier whose corresponding comment data (e.g., whose corresponding comment content data and/or corresponding comment metadata) have not been persistently stored as part of the page data for the page object identifier.

An operational example of performing the operation402is depicted inFIG. 6B. As depicted inFIG. 6B, to perform the operation402in order to update an unprocessed write request ledger for the data object identifier to include the write request, the workflow manager111of the data server computing device106performs operation613, which is configured to generate an unprocessed sequence number for the write request and update the unprocessed write request ledger by adding the unprocessed sequence number for the write request. With respect to the exemplary scenario described in the Overview section of the present document, at operation613, the workflow manager111generates two unprocessed sequence numbers: one unprocessed sequence number for the write request associated with Jane's actions and another unprocessed sequence number for the write request associated with Fred's actions. For example, in some embodiments, in order to perform the operation613, the workflow manager111adds the write sequence number for the write request that is associated with the data object identifier to a queue of the unprocessed write request ledger that is associated with the data object identifier. As another example, in some embodiments, in order to perform the operation613, the workflow manager111adds the write sequence number for the write request that is associated with the data object identifier to a queue of the unprocessed write request ledger that is associated with the data object identifier.

Returning toFIG. 4, at operation403, the data server computing device106processes the write request. As discussed above, to process the write request, the data server computing device106stores write request data associated with the unprocessed write request (e.g., write request content data associated with the write request and/or write request metadata associated with the write request) as part of the target data associated with a corresponding data object identifier. Accordingly, in some embodiments, when the data server computing device106first receives a write request from the client computing device102, the write request is deemed unprocessed until the data server computing device106persistently stores the write request data associated with the write request as part of the target data for the corresponding data object identifier, after which the write request is deemed processed.

An operational example of performing the operation403is depicted inFIG. 6C. As depicted inFIG. 6C, to perform the operation403in order to process the write request, the real-time event manager112of the data server computing device106performs operation614, which is configured to transmit a request to the write request processing manager116of the data server computing device106to process the write request by storing write request data associated with the write request as part of the target data117stored on the storage subsystem108. With respect to the exemplary scenario described in the Overview section of the present document, at operation614, the real-time event manager112transmits two requests: a first request to the write request processing manager116to process the write request associated with Jane's actions and a second request to the write request processing manager116to process the write request associated with Fred's actions. For example, when the real-time event manager112is an Apache Kafka engine, the Apache Kafka engine generates a Kafka event that is configured to cause the write request processing manager116to process the write request by storing write request data associated with the write request as part of the target data117stored on the storage subsystem108, and subsequently transmits the generated Kafka event to the write request processing manager116. As further depicted inFIG. 6, to perform the operation403in order to process the write request, subsequent to performing operation614in order to transmit a request to the write request processing manager116to process the write request, the write request processing manager116proceeds to operation615by processing the write request by storing write request data associated with the write request as part of the target data117stored on the storage subsystem108. With respect to the exemplary scenario described in the Overview section of the present document, at operation615, the write request processing manager116may sequentially store the data associated with the two write requests generated in that exemplary scenario as part of the target data for the first content data item. For example, the write request processing manager116may store the write request content data associated with the write request as part of the target content data portion of the target data117and store the write request metadata associated with the write request as part of the target metadata portion of the target data117.

Returning toFIG. 4, at operation404, the data server computing device106removes the write request from the unprocessed write request ledger. In some embodiments, subsequent to processing the write request by persistently storing the write request data associated with the write request as part of the target data for the data object identifier, the write request is deemed processed, and thus the data server computing device106proceeds to remove the now-processed write request from the unprocessed write request ledger. In some embodiments, to remove the write request from the unprocessed write request ledger, the data server computing device106removes the write request from the portion of the write request ledger that corresponds to the data object identifier.

An operational example of performing the operation404is depicted inFIG. 6D. As depicted inFIG. 6D, to perform the operation404in order to remove the write request from the unprocessed write request ledger, the write request processing manager116of the data server computing device106performs operation616, which is configured to transmit a request to the unprocessed write request ledger113to remove the write request from the unprocessed write request ledger. With respect to the exemplary scenario described in the Overview section of the present document, at operation616, after processing each write request by persistently storing the write request data associated with that write request in the target data for the first content data item, the write request processing manager116proceeds to remove the unprocessed sequence number for the processed write request from the portion of the unprocessed write request ledger that is associated with the first content data item. In some embodiments, to perform operation615, the write request processing manager116removes the unprocessed sequence number associated with the write request from a portion of the write request ledger that corresponds to the data object identifier, for example, from a queue of unprocessed sequence numbers associated with the data object identifier that is stored as part of the unprocessed write request ledger.

Returning toFIG. 4, at operation405, the data server computing device106updates the expediated retrieval data based on the updated target data. In some embodiments, subsequent to updating the target data by persistently storing the write request content data associated with the write request as part of the target data at operation403, the data server computing device106proceeds to move the updated target data to a cache storage medium by updating expediated retrieval data stored on the cache storage medium based on the updated target data. As discussed above, expediated retrieval data is stored as part of an in-memory cache storage unit for the data server computing device106in order to facilitate expediated data retrieval of data associated with the corresponding data object identifier when responding to a read request associated with the corresponding data object identifier. In some embodiments, expediated retrieval data is used to generate an update data object for the corresponding data object identifier in response to the read requests associated with the corresponding data object identifier. In some embodiments, the expediated retrieval data are graph-based data, such as data describing comments to a corresponding page object identifier as graph-based relationships (e.g., edges) of a central node associated with the corresponding page object identifier. In some of the noted embodiments, the read request associated with the corresponding page object identifier is a graph-based query, such as a GraphQL query.

An operational example of performing the operation405is depicted inFIG. 6E. As depicted inFIG. 6E, to perform the operation405to update the expediated retrieval data based on the updated target data, the real-time event manager112of the data server computing device106performs operation617, which is configured to transmit a request to the in-flight service114of the data server computing device106to update the expediated retrieval data stored on the in-memory cache storage unit115based on the target data117as updated in accordance with the operation615. With respect to the exemplary scenario described in the Overview section of the present document, at operation617, the real-time event manager transmits a request to the in-flight service114to update the expediated retrieval data after successful processing of each of the two write requests generated in that exemplary scenario. For example, if the real-time event manager112is an Apache Kafka engine, the noted Apache Kafka engine generates a Kafka event that causes the in-flight service114to store updates to the target data117as part of the expediated retrieval data stored on the in-memory cache storage unit115. As further depicted inFIG. 6E, to perform the operation405to update the expediated retrieval data based on the updated target data, in response to receiving the request to update the expediated retrieval data stored on the in-memory cache storage unit115based on the target data117as updated, the in-flight service114proceeds to perform the operation618, which is configured to update the expediated retrieval data by doing at least one of: (i) making changes to the expediated retrieval data based on the updates to the target data117, or (ii) replacing the existing expediated retrieval data based on the target data117as updated. With respect to the exemplary scenario described in the Overview section of the present document, at operation618, the in-flight service114updates the expediated retrieval based on the updated status of the target data for the first content data item subsequent to integration of each write request data for a write request of the two write requests generated in that exemplary scenario with the target data.

Partially Decoupled Read Request Management

FIG. 5is a flowchart diagram of an example process500for asynchronously processing a read request. Via the various operations of the process500, the data server computing device106can process read requests for a data object identifier through a procedure that is partially decoupled from the procedure for processing write requests for the data object identifier, a technique that in turn can reduce read request processing latency without tolerating the data reliability risks imposed by a total decoupling of read request processing procedures and write request processing procedures.

The process500begins at operation501when the data server computing device106receives a read request for a data object identifier from a client computing device102. As discussed above, the read request may describe a request by a client computing device102to retrieve an update data object which is configured to describe a latest state of target data associated with the data object identifier. In some embodiments, the read request is configured to trigger operations by the data server computing device106to generate the update data object and transmit the update data object to the client computing device102. Examples of read requests include requests generated when a user profile requests to open a user interface that is configured to display target data associated with a data object identifier, requests generated when a user profile requests to refresh an already-opened user interface that is configured to display target data associated with a data object identifier, and requests generated when a client computing device seeks to automatically (e.g., periodically) refresh an already-opened user interface that is configured to display target data associated with a data object identifier. In some embodiments, the read request is generated by a client computing device102and subsequently transmitted to the data server computing device106in response to an end-user request by an end-user of the client computing device102to refresh a page data object being hosted on a storage subsystem associated with the data server computing device106.

An operational example of performing the operation501is depicted inFIG. 6F. As depicted inFIG. 6F, to perform the operation501in order to receive the read request associated with the data object identifier, the read interface118of the data server computing device106performs the operation619, which is configured to receive the read request from the client computing device A102A. With respect to the exemplary scenario described in the Overview section of the present document, at operation619, the read interface118receives a write request that is generated based on Sally's actions. In some embodiments in which the read interface is a GraphQL query processing engine, the GraphQL processing engine receives the read requests as GrapQL queries, e.g., as GraphQL queries transmitted to an application programming interface (API) of the GraphQL processing engine.

Returning toFIG. 5, at operation502, the data server computing device106determines a match status for the data object identifier based on the unprocessed write request ledger. As described above, the match status may be configured to describe a determination about whether the unprocessed write request ledger includes at least one unprocessed sequence number that is associated with an unprocessed write request for the data object identifier. Accordingly, if the unprocessed write request ledger includes at least one unprocessed sequence number for the data object identifier, the match status for the data object identifier describes an affirmative match status, which indicates that at least one write request associated with the data object identifier remains unprocessed at the time of processing the read request associated with the write request. Moreover, if the processed write request ledger includes no unprocessed sequence numbers for the data object identifier, the match status for the data object identifier describes a negative match status, which indicates that no write request associated with the data object identifier remains unprocessed at the time of processing the read request associated with the write request.

An operational example of performing the operation502is depicted inFIG. 6G. As depicted inFIG. 6G, to perform the operation502to determine the match status for the data object identifier, the read interface118of the data server computing device106performs the operation620, which is configured to retrieve information about whether the unprocessed write request ledger113includes at least one unprocessed sequence number that is associated with the data object identifier which is subject to the read request. With respect to the exemplary scenario described in the Overview section of the present document, at operation620, the read interface118retrieves the portion of the unprocessed write request ledger113that is associated with the first content data item and analyzes the portion to determine whether the first content data item is associated with at least one unprocessed write request. In some embodiments, to perform the operation621, the read interface118transmits a request to obtain the information about whether the unprocessed write request ledger113includes at least one unprocessed sequence number that is associated with the data object identifier to the storage subsystem108, and the storage subsystem108generates the information based on the then-existing state of the unprocessed write request ledger113and transmits the information to the read interface118. As further depicted inFIG. 6G, to perform the operation502to determine the match status for the data object identifier, subsequent to retrieving the information about whether the unprocessed write request ledger113includes at least one unprocessed sequence number that is associated with the data object identifier, the read interface118proceeds to perform the operation621, which is configured to transmit the write request (e.g., the write request that includes a GraphQL query) to the workflow manager111. With respect to the exemplary scenario described in the Overview section of the present document, at operation621, the read interface118transmits the read request generated based on Sally's actions to the workflow manager111.

Returning toFIG. 5, at operation503, in response to determining that the match status the data server computing device106describes an affirmative match status, the data server computing device106first proceeds to operation504, at which the data server computing device106waits until an earlier one of the data retrieval conditions is satisfied, and subsequently the data server computing device106generates the update data object based on a latest state of target data associated with the data object identifier as soon as one of a plurality of data retrieval conditions is satisfied. Moreover, in response to determining that the match status the data server computing device106describes a negative match status, the data server computing device106directly proceeds to operation504, at which the data server computing device106generates the update data object based on a latest state of target data.

As discussed above, the data retrieval conditions include a group of conditions, where the configuration data for the data server computing device106describes that satisfaction of one of (e.g., an earlier-satisfied one of) the noted conditions is a sufficient prerequisite for generating an update data object for a corresponding data object identifier based on a latest state of target data for the corresponding data object identifier that is available at the time of the satisfaction. For example, in some embodiments, the data retrieval conditions consist of two conditions: a first condition that is satisfied if one or more identified unprocessed write requests for a corresponding data object identifier are marked as processed and a second condition that is satisfied if a waiting period (e.g., a waiting period of 300 milliseconds after receiving a read request for the corresponding data object identifier from a client computing device) expires. Thus, in some embodiments, upon receiving a read request for a corresponding data object identifier that is associated with one or more unprocessed write requests and in response to determining an affirmative match status for the corresponding data object identifier, the data server computing device106waits until the earlier of the expiration of a waiting period or processing of the one or more unprocessed write requests before generating the update data object based on the latest state of the target data associated with the corresponding data object identifier.

An operational example of performing the operation504is depicted inFIG. 6H. As depicted inFIG. 6H, to perform the operation504to determine an update data object, the workflow manager111of the data server computing device106first performs the operation622, which is configured to retrieve the expediated retrieval data from the in-memory cache storage unit115and use the retrieved expediated retrieval data to generate the update data object, where the expediated retrieval data are configured to describe the latest state of the target data117for the corresponding data object identifier. With respect to the exemplary scenario described in the Overview section of the present document, at operation622, the workflow manager111retrieves the expediated retrieval data for the first content data item and uses the noted expediated retrieval data to generate the update data object for the read request generated based on Sally's actions. As further depicted inFIG. 6H, to perform the operation504to determine an update data object, subsequent to retrieving the expediated retrieval data describing the latest state of the target data117and using the retrieved expediated retrieval data to generate the update data object, the workflow manager111transmits the update data object to the read interface118of the data server computing device106at operation623. With respect to the exemplary scenario described in the Overview section of the present document, at operation623, the workflow manager111transmits the update data object for the read request associated with Sally's request to the read interface118.

Returning toFIG. 5, at operation505, subsequent to determining the update data object (which describes the latest state of the target data for the data object identifier at a desired time, where the desired time is determined based on the techniques described in relation to the operation502and503), the data server computing device106proceeds to transmit the update data object to the client computing device102. For example, as depicted inFIG. 6I(which is an operational example of performing the operation505in order to transmit the update data object to the client computing device102), at operation624, the read interface118of the data server computing device106transmits the noted update data object that the read interface118has received from the workflow manager111of the data server computing device106to the client computing device A102A. With respect to the exemplary scenario described in the Overview section of the present document, at operation624, the read interface118transmits the update data object to a client computing device102that is associated with Sally in response to the read request generated based on Sally's actions.

An operational example of performing partially decoupled read request management according to the process500ofFIG. 5is depicted inFIGS. 7A-7C.FIGS. 7A-7Cdepict the states of the unprocessed write request ledger portion701for a data object identifier and the expediated retrieval data702for the data object identifier at three times: the time associated withFIG. 7A, which is the earliest of the three times and occurs prior to the expiration of the waiting period for the corresponding system; the time associated withFIG. 7B, which occurs after the time associated with theFIG. 7Abut prior to the time associated withFIG. 7Cand which occurs prior to the expiration of the waiting period for the corresponding system; and the time associated withFIG. 7Cwhich is the latest of the three times and occurs at the time of the expiration of the waiting period for the corresponding.

Accordingly, at the time associated withFIG. 7A, because the unprocessed write request ledger portion701for the data object identifier includes two unprocessed sequence numbers, the data object identifier is associated with an affirmative match status. As a result, in some embodiments, the data server computing device106waits until an earlier of the following two conditions are satisfied: the waiting period expires or both of the unprocessed sequence numbers are deemed processed and thus included in the expediated retrieval data702for the data object identifier. Neither of the two conditions is satisfied at the time associated withFIG. 7B, as at that time the waiting period has not expired and one unprocessed sequence number is still in the unprocessed write request ledger portion701and not included in the expediated retrieval data702. However, the waiting period expiration condition is satisfied at the time associated withFIG. 7C, and thus the update data object may be determined based on the state of the expediated retrieval data702at the time associated withFIG. 7C.

Another operational example of performing partially decoupled read request management according to the process500ofFIG. 5is depicted inFIGS. 8A-8C.FIGS. 8A-8Cdepict the states of the unprocessed write request ledger portion801for a data object identifier and the expediated retrieval data802for the data object identifier at three times: the time associated withFIG. 8A, which is the earliest of the three times and occurs prior to the expiration of the waiting period for the corresponding system; the time associated withFIG. 8B, which occurs after the time associated with theFIG. 8Abut prior to the time associated withFIG. 8Cand which occurs prior to the expiration of the waiting period for the corresponding system; and the time associated withFIG. 8Cwhich is the latest of the three times and occurs at the time of the expiration of the waiting period for the corresponding.

Accordingly, at the time associated withFIG. 8A, because the unprocessed write request ledger portion801for the data object identifier includes two unprocessed sequence numbers, the data object identifier is associated with an affirmative match status. As a result, in some embodiments, the data server computing device106waits until an earlier of the following two conditions are satisfied: the waiting period expires or both of the unprocessed sequence numbers are deemed processed and thus included in the expediated retrieval data802for the data object identifier. The latter of the two conditions is satisfied at the time associated withFIG. 8B, as at that time the waiting period has not expired but no unprocessed sequence number for the data object is still in the unprocessed write request ledger portion801and not included in the expediated retrieval data802. Thus, the update data object may be determined based on the state of the expediated retrieval data802at the time associated withFIG. 8B, assuming that the time associated withFIG. 8Bis the earliest time at which no unprocessed sequence number for the data object is still in the unprocessed write request ledger portion801and not included in the expediated retrieval data802.

Additional Implementation Details

Although example processing systems have been described in the figures herein, implementations of the subject matter and the functional operations described herein can be implemented in other types of digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them.

Embodiments of the subject matter and the operations described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described herein can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on computer-readable storage medium for execution by, or to control the operation of, information/data processing apparatus. Alternatively, or in addition, the program instructions can be encoded on an artificially-generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information/data for transmission to suitable receiver apparatus for execution by an information/data processing apparatus. A computer-readable storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer-readable storage medium is not a propagated signal, a computer-readable storage medium can be a source or destination of computer program instructions encoded in an artificially-generated propagated signal. The computer-readable storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

To provide for interaction with a user, embodiments of the subject matter described herein can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information/data to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending pages to and receiving pages from a device that is used by the user; for example, by sending web pages to a web browser on a user's query-initiating computing device in response to requests received from the web browser.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits information/data (e.g., a Hypertext Markup Language (HTML) page) to a query-initiating computing device (e.g., for purposes of displaying information/data to and receiving user input from a user interacting with the query-initiating computing device). Information/data generated at the query-initiating computing device (e.g., a result of the user interaction) can be received from the query-initiating computing device at the server.

Conclusion

Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation, unless described otherwise.