GATHERING TRANSACTION DATA ASSOCIATED WITH LOCALLY STORED DATA FILES

[0001] Client computing devices may request data files such as web pages, from one or more servers over a network. A client computing device that receives pages or other files from a server may locally store such pages or other files. The locally stored copies of the data files may be presented for display again in the future from the local store without sending a second request to the server, and without requesting the data files from the server a second time. For example, a client computing device may receive from a server a page, such as a HyperText Markup Language (“HTML”) page, that includes references to one or more data files that are to be obtained as part of processing the HTML page. The client computing device may then request the one or more data files from the appropriate server and process the requested data files for display. The client computing device may additionally store one or more of the requested data files in a data store local to or accessible to the client computing device. These locally stored copies of the one or more data files may then be used in a subsequently requested page that includes references to the same data files.

[0002] In this manner, the local saving of data files facilitates the reduction of the number of requests to the server in order to obtain data files. However, if changes to the locally stored data files are needed, such as to include transaction and interaction data associated with the data files, then the client computing device typically must reconnect to the server to receive an updated version of the data files or utilize a non-updated version of the data files.

[0009] Generally described, aspects of the present disclosure relate to systems and methods for gathering transaction data associated with a data file received from a server and locally stored by a client computing device, such that the client computing device may make changes to the data file by collecting the transaction data locally, without needing to immediately reconnect to the server. As discussed above, existing systems may enable a client computing device to store a local copy of a data file. Additionally, in existing systems, a locally stored copy of a data file cannot be managed without the client computing device connecting to the server. For example, transaction data associated with the data file cannot be updated without connection to the server. Finally, locally saved data files are associated with expiration data that causes the client computing device to consider the locally saved version as stale or no longer valid. For data files that may be subject to change or volatile in nature, such data files are typically associated with short expiration data that typically necessitate a reconnection to the server via the network. A drawback to such an approach when used with existing systems, however, is that the changes to the data file can typically not be made by the client computing device until a network connection is established.

[0010] Aspects of the present disclosure enable a data file to include changes in a manner that minimizes connection requests to a server, while also enabling one or more portions of the data file to be separately stored as local copies by the client computing device, such that the one or more portions may be managed by the client computing device.

[0011] In certain embodiments, a server as disclosed herein may receive a request from a client system for a data file. In response to the request, the server may send to the client system the data file. The response sent to the client system may also include a script enabling the client system to manage the data file. The script sent from the server may include executable code that performs a number of functions. In one aspect, the executable code may enable the client system to verify the availability of a network connection between the client system and the server. In another aspect, the executable code may enable the client system to collect and process transaction data associated with the data file. In yet another aspect, the executable code may enable synchronization of the transaction data between the client system and the server. Upon network connection availability, the server may receive the changes to the data file from the client system, and thereby create an updated version of the data file that includes the changes that were collected and processed by the client system.

[0012] FIG. 1 depicts an illustrative operating environment 100 in which a client computing device 102 may request one or more data files from a server 120, and then may locally store portions of one or more of the received data files in the local data store 112. The depicted environment 100 includes a client computing device 102 and a server 120 communicatively connected by a network 108, such as the Internet. Those skilled in the art will recognize that the client computing device 102 may be any of a number of computing devices that are capable of communicating over a network including, but not limited to, a laptop, personal computer, tablet computer, electronic book reader, personal digital assistant (PDA), hybrid PDA/mobile phone, mobile phone, and the like. In some embodiments, the client computing device 102 may include computer hardware and software components similar to those described below with respect to the server 120.

[0013] As further illustrated in FIG. 1, the server 120 includes or communicates with a general data store 122. The general data store 122 may include data files of one or more types, including, but not limited to, video files, audio files pages, and the like. Those skilled in the art will appreciate that the general data store 122 may be local to the server 120, may be remote to the server 120, and/or may be a network-based service itself.

[0014] As illustrated, the client computing device 102 includes or communicates with a local data store 112. The local data store 112 may include shared portions of one or more data files that have been received by the client computing device 102 from the server 120, and may include changes to the one or more data files. In some embodiments, the changes may consist of transaction data recorded on the client computing device 102. Those skilled in the art will appreciate that the network 108 may be any wired network, wireless network or combination thereof. In addition, the network 108 may be a personal area network, local area network, wide area network, cable network, satellite network, cellular telephone network, etc., or combination thereof. Protocols and components for communicating via the Internet or any of the other aforementioned types of communication networks are well known to those skilled in the art of computer communications and, thus, need not be described in more detail herein.

[0015] FIG. 2A is a block diagram illustrating the client computing device 102 within the operating environment 100 of FIG. 1. As illustrated in FIG. 2A, the client computing device 102 requests a first data file from the server 120. The client computing device 102 also stores the data file, a script and transaction data in the local data store 112. For purposes of this example, the “first data file” refers to a first data file that is requested and received by the client computing device 102 prior to any changes to the first data file being collected and processed by the client computing device 102 and prior to being stored in the local data store 112. As illustrated, the client computing device 102 sends a first data file request to the server 120. The first data file request may be, for illustrative purposes, a request for a page. The page may include code, such as HTML code, as well as other text, links to other data files, or other executable code. The client computing device 102 may send the first data file request, for example, as a result of a page request generated by a web browser installed on the client computing device 102.

[0016] Once the server 120 receives the first data file request, the server 120 may retrieve the first requested data file from the general data store 122. The server 120 may then send the first requested data file to the client computing device 102. The response sent to the client computing device 102 may also include executable code that manages additional functionality provided by the client computing device on behalf of a client computing device In one aspect, the executable code may enable the client computing device 102 to verify the availability of a network connection between the client computing device 102 and the server. In another aspect, the executable code may enable the client computing device 102 to collect and process transaction data associated with the data file. In yet another aspect, the executable code may enable synchronization of the transaction data between the client computing device 102 and the server 120.

[0017] Illustratively, the script may comprise executable code which can be independent of any other applications and/or operating systems running on the client computing device 102. The executable code may be a Java-script file which facilitates management of the client computing device 102. For example, when a user operates on a local user interface of the client computing device 102, the Java-script file on the client computing device 102 may enable integration of transaction data entered on the client computing device 102 with the first data file received. The Java-script file also enables to provide a user interface on the client computing device 102 which supports a user with or without connection to the remote server. Management of the client computing device 102 may also include using the Java-script file to determine whether there is a network connection with the server 120 and to enable the client computing device 102 to send the transaction data to the server 120 whenever network connection is established again between the client computing device 102 and the server 120. The transaction data may be sent for each transaction performed on the client computing device 102. The transaction data may also be sent periodically from the client computing device 102 to the server 120, independent of transactions performed.

[0018] When the client computing device 102 receives the first data file from the server 120, the client computing device 102 may processes the first data file, such as by rendering graphical images on a user interface. For example, if the first data file is a page, video, or other file that may be displayed, the client computing device may present the first data file for display. If the first data file includes audio data, the client computing device may cause playback of the audio data. If the first data file includes embedded references to additional data files, such as an image, a file containing additional code, a video, and the like, the client computing device 102 may request the additional data files from the server 120 and/or one or more additional servers (not illustrated). The content of the page, optionally including additional data files that are associated with or referenced by the page, may be presented for display, for example, as a user interface displayed via a navigation interface such as a web browser installed on the client computing device 102.

[0019] As discussed above, the client computing device 102 may store in the local data store 112 any changes made to the first data file, as indicated transaction data input on the client computing device. For example, the first data file may be a file associated with the delivery of a shipment to a customer. The client computing device 102 may be a hand-held device used by a delivery associate. The delivery associate may wish to enter transaction data associated with attempts to deliver the shipment to the customer. The associates failed attempts to reach the customer to make the shipment, and the successful delivery of the shipment may each be examples of transaction data that may be entered by the delivery associate, on the hand-held device, without a connection to the server.

[0020] In some embodiments, the first data file may be associated with short expiration data. In such instances, successive changes made to the first data file may overwrite previous changes made to the data file and stored on the local data store 112. In the example above, the successful delivery of the shipment may overwrite the previously recorded failed attempts. Alternatively, all changes made to the first data file may be stored with associated sequence identifiers on the local data store 112, and only the most recent changes may be transmitted to the server 120 upon reconnection. In the above example, the failed attempts would be stored on the local data store 112, while the successful delivery details would be transferred to the server upon reconnection. In yet other embodiments, all changes made may be transmitted to the server 120, along with the associated sequence identifiers. In the above example, details for all of the failed and successful attempts would be transferred to the server. In various embodiments, the script may be associated with expiry criteria. In some aspects, the expiry criteria may be based on a version identifier associated with the script. The version identifier may comprise a version number, a time stamp, and the like. Similarly, the decision of which data to transmit to the server 120 may be based on expiry criteria. Expiry criteria may comprise a period of time. Expiry criteria may also comprise a threshold number of successive changes made to the data file.

[0021] In some embodiments, code, such as JavaScript, included in the first data file received from the server 120 (or in an additional data file received from the server 120) may be executed by the client computing device 102 in order to manage the client computing device, including to enter such transaction data. The information stored in the local data store may include, for example, the script, along with transaction data recorded at the client computing device 102.

[0022] FIG. 2B is a block diagram illustrating the client computing device 102 within the operating environment 100 of FIG. 1 sending transaction data to the server 120, and receiving a second data file from the server 120. For purposes of this example, the “second data file” refers to a data file that is received by the client computing device 102 after transaction data has been sent to the server 120. For example, a second data file may include both the first data file previously sent to the client computing device 102 and the transaction data sent by the client computing device 102. As illustrated, the blocks depicted in FIG. 2B occur after the blocks in FIG. 2A have occurred, although other data files (not illustrated) may have been received by the client computing device 102 in between the first data file described above with respect to FIG. 2A being received and the second data file described below with respect to FIG. 2B being received.

[0023] As illustrated in FIG. 2B, the client computing device 102, after using the script to determine that a network connection exists, sends transaction data to the server 120. The transaction data may be, for illustrative purposes, information recorded on the client computing device 102 in relation to a transaction performed, as discussed above. The transaction performed may be a delivery, and the transaction data may include delivery details. Once network connection is established between the client computing device 102 and the server 120, the server 120 may receive the transaction data and may incorporate the transaction data with one or more data files from the general data store 122.

[0024] The server 120 may send a second data file to the client computing device 102. As will be appreciated, it is not necessary that the server 120 actually store the modified second data file. For example, in some embodiments, the modified second data file may be sent to the client computing device 102 as it is constructed by the server 120.

[0025] When the client computing device 102 receives the modified second data file from the server 120, the client computing device 102 may retrieve from the local data store 112 the script included in, or with the first data file. The client computing device 102 may then present the content of the second data file (as determined from the content of the modified first data file) for display, playback, and the like, as appropriate for the given data file type. The client computing device 102 may then record additional transaction data on the modified second data file loaded using the script. Such transaction data may be stored locally on the local data store 112 until a network connection is established with the server 120 again.

[0026] FIG. 3 depicts a general architecture of a client computing device 102 for requesting data files from a server 120 and for storing data files, scripts and transaction data to a local data store 112. The embodiment of client computing device 102 depicted in FIG. 3 includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. Those skilled in the art will appreciate that the client computing device 102 may include many more (or fewer) components than those shown in FIG. 3. It is not necessary, however, that all of these generally conventional components be shown in order to provide an enabling disclosure. As illustrated in FIG. 3, the client computing device 102 includes a processing unit 304, a network interface 306, a computer readable medium drive 307 and an input/output device interface 320, all of which may communicate with one another by way of a communication bus. As illustrated, the client computing device 102 is optionally associated with, or in communication with, a display 302, and an input device 324. The network interface 306 may provide the client computing device 102 with connectivity to one or more networks or computing systems. The processing unit 304 may thus receive information and instructions from other computing systems or services via a network. The processing unit 304 may also communicate to and from memory 310 and further provide output information for an optional display 302 via the input/output device interface 320. The input/output device interface 320 may accept input from the optional input device 324, such as a keyboard, mouse, digital pen, touch screen, or gestures recorded via motion capture.

[0027] The memory 310 contains computer program instructions that the processing unit 304 executes in order to implement one or more embodiments of the present disclosure. The memory 310 generally includes RAM, ROM and/or other persistent or non-transitory memory. The memory 310 may store an operating system 314 that provides computer program instructions for use by the processing unit 304 in the general administration and operation of the client computing device 102. The memory 310 may further include other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 310 includes a user interface module 312 that facilitates generation of user interfaces (such as by providing instructions therefor) for display upon a computing device. For example, a user interface may be displayed via a navigation interface such as a web browser installed on the computing device 102. In addition, memory 310 may include or communicate with a local data store 112, discussed above.

[0028] In addition to the user interface module 312, the memory 310 may include a local storage module 325 that may be executed by the processing unit 304. In one embodiment, the local storage module 325 may be used to implement various aspects of the present disclosure, such as comparing one or more data files to identify transaction data that may have been locally stored by the client computing device, as described further below. In certain embodiments of the present disclosure, the server 120 may include several components that operate similarly to the components illustrated as part of the client computing device 102, including a user interface module, processing unit, computer readable medium drive, and the like.

[0029] FIG. 4 is a flow diagram of an illustrative method 400 implemented by the client computing device 102 to synchronize data files and transaction data between the local data store 112 and the server 120. The illustrative method 400 may be implemented at least in part by the caching module 325. While the method 400 is illustrated using the example of a single data file or grouped data files, in some embodiments, the illustrated method may be implemented for each data file in general data store 122, and/or each data file in the local data store, or for a subset of the data files. For example, in some embodiments, the server 120 may modify each data file in general data store 122 to include transaction data received on a periodic basis, such as nightly, weekly, etc. In other embodiments, the server 120 may modify one or more data files in general data store 122 to include transaction data received in response to a triggering event, such as the creation or modification of transaction data or a new data file being stored in the general data store 122. In other embodiments, the illustrated method 400 may be implemented in response to a client computing device, such as the client computing device 102, requesting a data file from the server 120.

[0030] The method 400 begins at block 402, then proceeds to block 404, where the client computing device 102 receives a first data file and a script from server 120 or another server. The first data file may be any data file stored in the general data store 122, or in another data store. The script may be one of a variety of executable codes, such a Java-script file, or another type of file to enable various management and control functions implemented on the client computing device 102. As previously described, the management and control functions can include collection and processing of transaction data, verification of network connectivity between the client computing device 102 and the server, and integration of transaction data with the first data file on the client computing device 102 and on the server.

[0031] At block 406, the script on the client computing device 102 enables collection and processing of transaction data on the first data file by accepting operations on a local user interface of the client computing device. If the script on the client computing device 102 determines at block 408 that there is no connection to a network in order to send transaction data to the server 120, the client computing device 102 continues to record transaction data, and saves the collected and processed transaction data on the local data store 112. If instead the script on the client computing device 102 determines at block 408 that there is a connection to a network, the script on the client computing device 102 proceeds to block 410, where the client computing device 102 sends transaction data to the server 120 in order to get synchronized with the server 120. The server 120 may save such transaction data on the general data store 122. At block 410, when a network connection is determined to be present, the server 120 may also send updated data to the client computing device 102.

[0032] The above methods discussed throughout the present disclosure may result in smaller, and/or less data files being sent from the server 120 to the client computing device 102, because previously locally stored shared portions may be sent only once, rather than being sent again for subsequent data file requests. The above methods may additionally or alternatively result in decreasing the number of connections or requests from the client computing device 102 to the server 120, because content may be included in a single data file, where the same content might otherwise be split into multiple data files in order to take advantage of the existing full file caching of other systems. As will be appreciated, enabling caching of portions of a data file and other aspects of the present disclosure may be implemented for a variety of data file types. Accordingly, many types of content accessible over a network may benefit from aspects of the present disclosure.

[0033] It is to be understood that not necessarily all objects or advantages may be achieved in accordance with any particular embodiment described herein. Thus, for example, those skilled in the art will recognize that certain embodiments may be configured to operate in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other objects or advantages as may be taught or suggested herein.

[0034] All of the processes described herein may be embodied in, and fully automated via, software code modules executed by one or more general purpose computers or processors. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all the methods may alternatively be embodied in specialized computer hardware. In addition, the components referred to herein may be implemented in hardware, software, firmware or a combination thereof.

[0035] Conditional language such as, among others, “can,” “could,” “might” or “may,” unless specifically stated otherwise, are otherwise understood within the context as used in general to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

[0036] Any process descriptions, elements or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or elements in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown, or discussed, including substantially concurrently or in reverse order, depending on the functionality involved as would be understood by those skilled in the art.

[0037] It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.