Managing disconnected investigations

[0001] The present disclosure generally relates to distributed computing systems.

[0002] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

[0003] Client-server computer systems are a pervasive form of distributed computing architecture. Client-server systems often employ a database for storing and retrieving data. A typical database is an organized collection of related data stored as “records” having “fields” of data. In a typical client-server system employing a database, client computing devices (clients) request services of server computing devices (servers) over a data network and servers modify and retrieve database data as part of servicing requests from clients.

[0004] As an intermediary between clients and the database, servers allow multiple clients to modify and retrieve database data concurrently while at the same time providing a consistent view of database data to all clients. Sharing new information between clients is a matter updating data in the database so that clients can retrieve the new information from the database. In essence, the database is the centralized and authoritative repository of information and the servers act as gatekeepers of the information through which all requests from clients to modify and retrieve the information must pass.

[0005] Typical client-server database systems are useful to users so long as the network connecting the clients to the servers is highly reliable. In these systems, servers execute much of the logic for modifying and retrieving database data and clients repeatedly request servers over a network to perform various data selection and manipulation functions. Thus, if the network between clients and servers is only periodically available, is completely unavailable, or is non-existent, then users of the clients cannot practically conduct an analysis on database data. However, some users (e.g., in-field or forward operating personnel) may wish to perform analysis on database data in locations where a network connecting clients and servers is only periodically available, is unreliable, or does not exist. In addition, these disconnected users may need to update database data at their remote location and incorporate their updates back into the central authoritative repository of database data shared with other users, all without any network access to the central authoritative repository. For these “disconnected” users, typical client-server database systems requiring a highly-available network connection are not adequate.

[0016] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

[0017] In an embodiment, a system and a method of using the system enable an information analyst to use a stand-alone computer-based investigation application to conduct a disconnected investigation in a remote location where network access to servers of the system might be only periodically available, unreliable, or non-existent. In addition, the system and method enable the disconnected investigation to incrementally incorporate ongoing updates made to investigative data stored in a shared repository of data, and to periodically synchronize disconnected investigative data with the shared data repository thereby incorporating investigative updates made to investigative data back into the shared data repository. Unlike prior approaches, an investigation can be conducted entirely without having any network connectivity at the investigation location.

[0018] As used herein, the term “investigation” refers to a separate line of inquiry or analysis on a subset of shared database data drawn from a shared data repository. Investigations allow information analysts to explore competing hypotheses. For example, if one analyst has a first hypothesis regarding a subset of database data, and another analyst has a second competing hypothesis regarding the same subset of database data, investigations allow both analysts to pursue their own hypothesis on the subset without interfering or contradicting each other.

[0019] During an investigation, changes made to the subset of data are not visible to other database users and do not conflict with changes to the subset made by other users either in another investigation or to the base copy of the subset in the shared data repository from which the investigative subset was drawn. Changes made during an investigation are made visible to other database users by “publishing” the changes to the shared data repository. Publishing changes to the shared data repository may require reconciliation with other changes made outside the context of the investigation. In some cases, reconciliation occurs automatically. In other cases, manual reconciliation is required.

[0020] In one embodiment, the system comprises two types of investigation application installations: a single base installation (also referred to herein as the base instance) and one or more disconnected installations (also referred to herein as disconnected instances). As used herein, the term “investigation application” refers to a software and/or hardware-based computing application for conducting investigations on database data. One non-limiting example of an investigation application is the Palantir Government platform available from Palantir Technologies of Palo Alto, Calif. In one embodiment, the base installation comprises a full-featured installation of an investigation application on one or more high-powered server computing devices while each disconnected installation comprises a subset-featured installation of the investigation application on a relatively lower powered computing device such as a laptop computer.

[0021] In operation, a user uses the base installation to create disconnected investigations, which are distributed to disconnected installations. Remote analysts use the investigation application in the disconnected installations to conduct these investigations and send back data to the base installation, where the data can be integrated into the shared data repository. If a network connection exists between the base and disconnected installations, investigations and investigative data can be exchanged online; otherwise they can be exchanged by using physical portable media, such as flash memory devices, compact-discs (CDs), digital versatile discs (DVDs), etc.

[0022] During an investigation, a disconnected installation can incorporate updates made to the shared data repository with only minimal interruption to the investigation. For example, the disconnected installation may only require a reboot or a restart after incorporating an update. Significantly, the updates can be incorporated at the disconnected installation without requiring the disconnected installation to communicate with the base installation. Thus, in contrast to prior approaches, the disconnected installation can incorporate updates without any network connectivity to the base installation. Further, incorporating shared data repository updates into a disconnected installation is a simple end-user operation. In one embodiment, incorporating shared data repository updates into a disconnected installation involves a remote analyst using a pointing device such as a mouse to double-click on a file containing the updates. Also, a disconnected installation can periodically synchronize disconnected investigate data with the shared data repository at the base installation with only minimal or insubstantial interruption to the investigation. In particular, network connectivity between the disconnected installation and the base installation is not required to synchronize disconnected investigate data with the shared data repository. Advantageously, incorporating shared data repository updates into a disconnected installation, updating disconnected investigative data at the disconnected installation, and synchronizing disconnected investigative data with the shared data repository are not dependent on each other and can be performed in any order without requiring network connectivity from the disconnected installation to the base installation and without blocking or holding up the investigation at the disconnected installation.

[0023] Disconnected Investigations

[0024] In one embodiment, a disconnected investigation is initially created in the base installation by users who can provide an initial data set of the investigation from the shared data repository, add new data sets to the investigation, and update existing data sets of the investigation. Disconnected investigations and updates from the shared data repository are provided to disconnected installations in what will be referred to herein as “.base” files. Note that the name of the file is arbitrary and is not limited to any particular file name or format. Remote analysts load the .base files into their disconnected installations to conduct disconnected investigations. Periodically, the remote analysts provide results from the disconnected investigations to the base installation in what will be referred to herein as “.dsco” files. Again, the name of the file is arbitrary and is not limited to any particular file name or format. Information from .dsco files is integrated into the base copy of the disconnected investigation at the base installation and published to the shared data repository.

[0025] In one embodiment, the initial .base file created for a disconnected investigation contains the actual investigation and may include, among other information, one or more of: investigation metadata, investigative data, data sources where the investigation data originated, a quantity of globally unique random identifiers, and current setting of system properties in the base installation. Subsequent .base files created for the same disconnected investigation are smaller than the initial .base file, and may include, among other information, one or more of: information about new, changed, or deleted investigative data, any associated data source not already provided, additional globally unique random identifiers, if needed, and current settings of any changed system properties changed in the base installation. Techniques for generating subsequent .base files for the same disconnected investigation that are smaller than the initial .base file are described in greater detail below.

[0026] In one embodiment, remote analysts create .dsco files in disconnected installations and use them to deliver interim and final results of their disconnected investigations to the base installation. Each .dsco file may include, among other information, one or more of: investigation metadata, information about all new, changed, or deleted investigation data, and any new data sources imported into the investigation.

Base Installation

[0027] FIG. 1 is a block diagram illustrating a base installation 100 according to an embodiment of the invention. A database 122 managed by a database management system 120 is coupled to investigation application logic 110 which implements functions describe herein for managing disconnected investigations. A user terminal (not shown) is coupled to front-end logic 105 which is coupled to investigation application logic 110. The user terminal may be any host computer of an intelligence analyst, database administrator, or other user who interacts with database 122 through application logic 110. Front-end logic 105 can be web-based in which the host computer is configured with a standard web browser application for interacting with front-end logic 105. Front-end logic 105 may also be “thick” client-based in which case the host computer is configured with a specific desktop application that is configured specifically for interacting with front-end logic 105. Base installation 100 can be implemented by multiple computing devices within TCP/IP network in a headquarters environment.

[0028] In one embodiment, database 122 comprises both a shared data repository 126, where all shared data is stored and published, and an investigation repository 124, where investigations including base copies of disconnected investigations are stored. Users 101 and 103 in the base installation 100 support remote analysts in disconnected installations by creating and managing their disconnected investigations, and by integrating the results of their investigations into base installation 100.

[0029] Users 101 and 103 in base installation 100 prepare sources of data in shared data repository 126 for disconnected investigations. Users 101 and 103 can also review results of disconnected investigations and selectively publish investigation data to shared data repository 126. Users 101 and 103 use sources of data in shared data repository 126 to add new and changed data to disconnected investigations being conducted by remote analysts. Users 101 and 103 package the investigations and investigation updates in .base files, and provide the files to remote analysts. Users 101 and 103 receive .dsco files from the remote analysts, un-package the data they contain, and make the data available for users 101 and 103 to review and publish selectively.

[0030] Disconnected Installation

[0031] FIG. 2 is a block diagram illustrating a disconnected installation 200 according to an embodiment of the invention. Disconnected installation 200 is a version of the investigation application for use by remote analyst 202 as a mobile, stand-alone system that is not connected directly to base installation 100. Disconnected installation 200 might reside, for example, on a powerful laptop computer that is deployed within a designated area of responsibility.

[0032] A remote analyst 202 begins or updates a disconnected investigation by loading .base files generated by base installation 101 into disconnected installation 200. The remote analyst 202 conducts the disconnected investigation by using front-end logic 205 and investigation application logic 210 in disconnected installation 200. The remote analyst 202 periodically synchronizes disconnected investigation data 224 with base installation 100 by packaging updated disconnected investigative data in .dsco files, and providing the files to base installation 100 either over a network or on transportable physical computer-readable media physically delivered to base installation 100 by mail, courier, etc.

[0033] In one embodiment in which a network connection is available or periodically available between base installation 100 and disconnected installation 200, remote analyst 202 connects to and logs on to a web server in base installation 100 to (1) generate and download .base files containing new disconnected investigations, or updates to existing investigations and to (2) upload .dsco files, and integrate the data they contain into base installation 100. In another embodiment in which there is no network connection available between base installation 100 and disconnected installation 200, remote analyst 202 receives .base files from base installation 100 and sends .dsco files to base installation 100 on portable physical media, such as flash memory devices, compact-discs (CDs), digital versatile discs (DVDs), etc.

[0034] Revisioning Database System

[0035] In one embodiment, base installation 100 employs a revisioning database system 130 to track all changes made to shared data repository 126, to provide separate data spaces for investigations, and to provide granular sharing of investigative changes through the shared data repository 126. Revisioning database system 130 may be implemented in whole or in part by both investigation application 110 and database management system 120. In addition, all or part of revisioning database system 130 may be implemented by a system separate from both investigation application 110 and database management system 120. In one embodiment, revisioning database system 130 comprises computer-executable logic implementing functions and features of a revisioning database system described herein using a traditional database management system. In this embodiment then, database management system 120 may be a commercially available database management system such as those available from the Oracle Corporation of Redwood Shores, Calif. and the Microsoft Corporation of Redmond, Wash. and revisioning database system 130 comprises computer-executable logic implementing functions and features of a revisioning database system described herein using the commercially available database management system.

[0036] In one aspect, revisioning database system 130 differs from other types of database systems in that revisioning database system 130 is capable of answering a query about the state of data stored in shared data repository 126 at a point in time in the past as opposed to only being able to answer a query about the current state of data. With revisioning database system 130, in combination with front-end logic 105, users can determine when a particular piece of data was added or edited in shared data repository 126 and the data source of the addition or edit. In this context, the term “data source” refers to a source of database data stored in shared data repository 126. Generally, there are two types of data sources: (1) manually entered data from users and (2) automatically imported data from data sources such as spreadsheets, documents, other systems, etc. Thus, revisioning database system 130, through its capability to track all changes to data stored in shared data repository 126, enables users to determine what was “known” about database data at a particular point in time in the past.

[0037] In one embodiment, revisioning database system 130 is capable of tracking all changes made to shared data repository 126. As used herein, the term “data object” or just “object” refers broadly and generally to data that represents an entity (person, place, or thing), event, or document. Each object can have one or more object components. Non-limiting examples of types of object components include properties and links. As used herein, the term “property” refers broadly and generally to data represents a feature or characteristic of an object. Different types of objects may have different types of properties. For example, a “Person” object might have an “Eye Color” property and an “Event” object might have a “Date” property. Objects can have connections or associations through links. A used herein, the term “link” refers broadly and generally to data that represents connections or associations between objects including relationships, events, and matching properties. Links may contain multiple connections. For example, two “Person” objects representing a husband and a wife could be connected through a relationship (“Spouse Of”), a matching object property (“Address”), and an event (“Wedding”).

[0038] In one embodiment, to track all changes made to shared data repository 126, revisioning database system 130 creates a new database record in database 122 for every creation, edit, or deletion of an object or an object component. Once a database change record is created, it is not modified thereby preserving a historical record of the corresponding change. To track the ordering of changes, revisioning database system 130 employs a logical clock that models all changes as a linear sequence of database events. The logical clock provides a total ordering for all changes in shared data repository 126. In addition, the logical clock provides atomicity for changes as multiple changes can occur at the same point in the linear sequence of database events represented by the logical clock.

[0039] FIG. 5 illustrates tracking changes made to shared data repository 126 by an example and according to an embodiment of the invention. As shown in FIG. 5, each record 502, 504, 506, 508, and 510 in table 501 represents a creation, edit, or deletion of an object or an object component. The fields of each change record include a ‘obj_comp_id’ field identifying the object or the object component that was created, edited, or deleted by the change, an ‘obj_id’ field identifying the object that was created, edited, or deleted by the change, a ‘logical_clk’ field that identifies the order of the change in a total ordering of all changes made to shared data repository 126, a ‘deleted’ field indicating whether the change was a deletion of an object or an object component, and a ‘<values’> field indicating, for changes that create or edit a value, the value that resulted from the change or, for changes that delete a value, the value that was deleted.

[0040] For example, referring to FIG. 5, at logical clock event 1, an object of type “Person” was created. Also at logical clock event 1, a “Name” property of the object was created and given the value “John Smith”. Later, at logical clock event 2, a “Phone #” property of the object was created and given the value “415-222-1234”. At logical clock event 3, the “Name” property of the object that was created at logical clock event 2 was edited with the value “Jonathan Smith”. At logical clock event 4, the “Phone #” property that was created at logical clock event 3 was deleted. The state of the object at logical clock event 4 as a result of these changes is an object of type “Person” with the property “Name” having a value “Jonathan Smith”.

[0041] By preserving all changes made to an object in the form of change records, revisioning database system 130 is able to provide the state of an object at a point in time in the past. For example, referring again to FIG. 5, it can be seen from change records 502, 504, and 506 that the state of the object at logical clock event 2 was an object of type “Person” with a property “Name” having a value “John Smith” and a property “Phone#” having a value “415-222-1234”.

[0042] FIG. 5 illustrates but one example scheme that revisioning database system 130 could employ to track all changes to shared data repository 126 and embodiments of the invention should not be construed as being limited to only the one example scheme or be construed as requiring all details of the one example scheme. For example, instead of storing all change records for an object in a single table as depicted in FIG. 5, the change records might be stored across multiple tables, or change records for multiple objects might be stored in a single table. Further, the change records may contain other fields that are not depicted in FIG. 5. For example, each change record may have an additional version field that serves as a single primary key for the change record as opposed to using a combination of the ‘obj_comp_id’ and the ‘logical_clk’ fields as the primary key. Other useful fields could include a ‘time created’ field storing the date/time the corresponding object or object component was created, a ‘created by’ field for storing an identifier of a user that created the change record, and a ‘last modified’ time field storing the date/time the correspond change was made.

[0043] Overall Disconnected Investigation Workflow

[0044] FIGS. 3 and 4 in combination depict an overall workflow for managing a disconnected investigation at a base installation and a disconnected installation according to an embodiment of the invention. FIG. 3 depicts the portion 300 of the workflow for managing the disconnected investigation at the base installation. FIG. 4 depicts the portion 400 of the workflow for managing the disconnected investigation at the disconnected installation. The overall workflow will now be explained with reference to base installation 100 of FIG. 1 and disconnected installation 200 of FIG. 2.

[0045] Preparing Sources of Data for the Disconnected Investigation

[0046] The overall workflow starts at base installation 100 where, at step 301, sources of data for the disconnected investigation are prepared. In general, preparing sources of data for the disconnected investigation includes specifying criteria to investigation application logic 110 for use by investigation application logic 110 in identifying objects stored in shared data repository 126 that will be the subject of the disconnected investigation. The investigation subject criteria can be in the form of a query or a filter or a combination of queries and filters. A query specifies selection criteria that objects in shared data repository 126 must satisfy (or not satisfy as the query may specify) to be selected by the query. A query may contain simple search terms, such as strings of text, or various types of complex expressions in which multiple search terms and search expressions are combined using logical operators such as AND, OR, and NOT. A filter selects objects in shared data repository 126 by examining objects within a specific group of objects and selecting objects with the specific group that satisfy the filter's selection criteria. A query may be combined with a filter such that the query selects a specific group of objects to which the filter is applied to produce a final set of selected objects.

[0047] By virtue of the investigation subject criteria, the objects in shared data repository that are the subject of a disconnected investigation may change over the course of the disconnected investigation. For example, when a new disconnected investigation is created, a first set of objects may be initially selected by the investigation subject criteria. Thereafter, when an update for the disconnected investigation is generated, the investigation subject criteria may select of a second set of objects that includes the first set of objects in addition to a set of additional objects not included in the first set of objects.

[0048] Techniques are described herein for generating an update .base file that includes only the investigative data needed to bring a disconnected installation up-to-date according to the investigation subject criteria. For example, according to one embodiment, an update .base file generated for the disconnected investigation would include changes to the first set of objects that were made between when the disconnected investigation was created and when the update was generated, but the update .base file would not include any changes to the first set of objects that were made before the disconnected investigation was created. In addition, the update .base file will include all changes to the additional objects in the second set of objects.

[0049] This example is illustrated in chart form in FIG. 6. As shown in FIG. 6, change set 601 includes changes made to the first set of objects between an initial logical clock event and a logical clock event corresponding approximately or exactly to when the initial .base file was generated. As shown by darker shading in FIG. 6, change set 602 includes only those changes made to the first set of objects between the logical clock event corresponding to when the initial .base file was generated and a logical clock event corresponding approximately or exactly to when the update .base file was generated. In addition, change set 602 includes all changes made to the additional set of objects in the second set of objects between the initial logical clock event and the logical clock event corresponding to when the update .base file was generated. Thus, change set 602 includes only the changes needed to bring a disconnected installation having applied change set 601 up-to-date.

[0050] Creating the Disconnected Investigation

[0051] The overall workflow proceeds to step 302 where the disconnected investigation in the form an initial .base file is created. Creating the disconnected investigation includes generating an identifier that uniquely identifies the disconnected investigation within database 122 and applying the investigation subject criteria specified in step 301 against shared data repository 126 to identify an initial set of objects that are initially the subject of the disconnected investigation. In one embodiment, the initial .base file corresponding to the new disconnected investigation sent to disconnected installation 200 includes change records for the initial set of objects as maintained by revisioning database system 130.

[0052] When the new disconnected investigation is created, an initial change set for the disconnected investigation is identified based on the initial set of objects selected by the investigation subject criteria. In particular, for each object in the initial set of objects, change records for the object are selected from shared data repository 126. The change records selected for each object in the initial set of objects correspond to change records for the object having a logical clock value that is greater than an initial logical clock value and less than a current logical clock value. In one embodiment, creating a new disconnected investigation (including selecting the initial set of objects and the change records for the initial set of objects) is an atomic operation that is assigned its own logical clock value. In one embodiment, the current logical value is the logical clock value assigned to the operation of creating the new disconnected investigation. In another embodiment, creating a new disconnected investigation does not increment the logical clock and the current logical clock value is a current value of the logical clock at or near the time the new disconnected investigation is created. In one embodiment, the initial logical clock value is the earliest logical clock value (e.g., 0). In another embodiment in which the disconnected investigation need not start with the entire history of changes made to the initial set of objects, the initial logical clock value may be greater than the earliest logical clock value.

[0053] To track what change sets have been generated for the disconnected investigation, two relations are maintained in database 122 by investigation application logic 110 in base installation 100. An “investigation-change set” relation associates disconnected investigations, change sets, and logical clock values. A “change set-object” relation associates change sets and objects. These relations may be implemented in database 122 in any convenient manner using a number of database models such as, for example, a relational model, a object-relational model, an object model, a hierarchical model, combinations thereof, etc.

[0054] At a high level, the investigation-change set relation identifies what change sets have been generated for which investigations and when those change sets were generated according to the logical clock at base installation 100. The change set-object relation identifies what objects were selected by investigation subject criteria for inclusion in which change sets.

[0055] FIG. 7 illustrates a change set-object relation 701 and an investigation-change set relation 702 by an example and according to an embodiment of the invention. Assume the investigation subject criteria for the new disconnected investigation selected objects 6 and 7 as the initial set of objects. In a practical embodiment, the initial set of objects may include many hundreds or even many thousands of objects. As mentioned above, once the initial set of objects is obtained, an initial change set for the initial set of objects is selected. The initial change set for the initial set of objects is assigned an identifier uniquely identifying the change set at least among all change sets that will be generated for the disconnected investigation. In this example, initial change set 1 includes all change records for objects 6 and 7 that were created between an initial logical clock value (e.g., 0) and a current logical clock value. A record of what objects were selected for the initial change set is stored in database 122 according to the change set-object relation. For example, FIG. 7 shows two records 703 and 705 indicating that objects 6 and 7 were selected for initial change set 1.

[0056] In addition to keeping a record in database 122 of what objects were selected for the initial change set, a record is also kept of when the initial change set was generated for the new disconnected investigation according to the logical clock at base installation 100. For example, FIG. 7 shows record 706 indicating that initial change set 1 was generated for disconnected investigation 1 at local clock event 101. Note that order in which change sets were generated for a particular disconnected investigation can be determining from the investigation-change set relation based on the logical clock field.

[0057] Providing the Disconnected Investigation to the Disconnected Installation

[0058] Next, the overall workflow proceeds to step 303 where the initial .base file generated in step 302 is provided to disconnected installation 200. In one embodiment, providing the initial .base file to disconnected installation 200 includes making the initial .base file available for download over a periodically available network connecting base installation 100 and disconnected installation 200. In another embodiment in which there is no network connection available between base installation 100 and disconnected installation 200, the initial .base file is stored in a portable device or computer-readable medium such as a flash drive, a Compact Disc (CD), or a Digital Versatile Disc (DVD), and delivered manually to disconnected installation 200.

[0059] Loading the Disconnected Investigation

[0060] Turning to FIG. 4, at step 401, the initial .base file is loaded into disconnected installation 200. It should be noted that there is no requirement that the initial .base file be loaded into a disconnected installation before an update to the initial .base file is generated at the base installation. Therefore, step 304 of process 300 may performed, even repeatedly, before and after step 401 of process 400.

[0061] In one embodiment, loading the new disconnected investigation is performed manually by the remote analyst at disconnected installation 200. The initial .base file is placed by the remote analyst on a filesystem accessible by a computing device hosting the stand-alone investigation application. Loading the initial .base file into disconnected installation 200 includes the remote analyst double-clicking on the initial .base as presented in a file system browsing application provided by an operating system of the computing device thereby causing investigation application logic 210 to incorporate the change records stored in the initial .base file into database 222. Incorporating the change records into database 222 includes investigation application logic 210 instantiating disconnected investigation 224 in database 222 with the change records stored in the initial .base file. Other actions may be performed by remote analyst to accomplish the same. For example, starting the stand-alone investigation application and using a file browser provided by the investigation application to locate and open the initial .base file. As another example, the remote analyst may use a pointing device such a mouse to drag and drop the initial .base file onto a desktop icon representing the stand-alone investigation application.

[0062] Conducting the Disconnected Investigation

[0063] Once an initial .base file has been loaded, the remote analyst at disconnected installation 200 is ready to conduct the disconnected investigation. During the course of the disconnected investigation, the remote analyst may load updates to the disconnected investigation in the form of update .base files received from base installation 100 and may generate interim or final results of the disconnected investigation in the form of .dsco files. The remote analyst may conduct the disconnected investigation, load updates, and generate results without a network connection to the base installation.

[0064] The complete set of potential disconnected investigative activities the remote analyst can perform at disconnected installation 200 using investigation application logic 220 is beyond the scope of this application. However, potential disconnected investigative activities performed using investigation application logic 220 can include: viewing, creating, changing, and deleting objects, object metadata, object components and links stored in database 222; searching for information in database 222 using queries and filters; tagging text in documents to create or change objects, object properties, and links stored in database 222; adding objects to graphs and working with graphs to create objects and link objects together in database 222; searching for, visualizing, analyzing, exporting, printing, or saving data stored in database 222; working with graphical maps to search for information using route, radius, and polygon geosearches; creating and using heatmaps; visualizing, analyzing, exporting, printing, and saving geographical information; creating, changing, and using filters to find objects in database 222 and adding found objects to graphs and maps; creating and using graphical timelines to find time ranges among object and property data, creating visual chronologies of related behaviors and events, and analyzing the chronologies to discover patterns and trends; creating and using histograms to discover correlations between objects, properties, and links, interconnections between objects, and patterns and trends among activities and behavior; and highlighting information in graphs, maps, and data sources by selecting different groups of objects, properties, or links within histograms.

[0065] In one embodiment, conducting the disconnected investigation in disconnected installation 200 involves use of revisioning database system 230 such that all changes made by the remote analyst 201 to objects that are part of the disconnected are tracked. Revisioning database system 230 ensures that change records incorporated into database 224 from an initial .base file or an update. base file are not modified preserving the historical record of changes to objects at disconnected installation 200. At the same time, revisioning database system 230 allows the remote analyst 201 to make changes to objects based on change records for those objects received from base installation 100.

[0066] Generating an Update for the Disconnected Investigation

[0067] Returning to FIG. 3, at step 304 an update for the disconnected investigation is generated at base installation 100 in the form of an update. base file. In one embodiment, generating an update for the disconnected investigation includes applying investigation subject criteria against shared data repository 126 to identify the update set of objects that are the subject of the disconnected investigation. For the purpose determining what change records are part of the update for the disconnected investigation, the update set of objects supersedes the initial set of objects and any previous update set of objects selected for the disconnected investigation.

[0068] The investigation subject criteria used to identify the update set of objects can be the same investigation subject criteria used to select the initial set of objects or a previous update set of objects. Alternatively, new investigation subject criteria may be specified to investigation application logic 110 for selecting the update set of objects. In any case, the update set of objects selected for the update may include new objects that were not previously the subject of the disconnected investigation. In one embodiment, the update .base file generated for the disconnected investigation and sent to disconnected installation 200 includes only the change records necessary to bring the disconnected investigation at disconnected installation 200 up-to-date with respect to the change records included in the initial .base file and any previous update .base files that have already been incorporated into disconnected installation 200.

[0069] To generate the update for the disconnected investigation, an update change set for the disconnected investigation is identified based on the update set of objects selected by the investigation subject criteria. Identifying the update change set for the disconnected investigation includes identifying any objects in the update set of objects that are new to the disconnected investigation and identifying any objects in the update set of objects that are already part of the disconnected investigation by virtue of being included in a previous change set generated for the disconnected investigation. In one embodiment, an object is never “deleted” from a disconnected investigation. Instead, objects that were included in a previous change set but that are not selected by the investigation subject criteria for inclusion in the update set of objects are treated as if they were selected by the investigation subject criteria for inclusion in the update set of objects. However, change records included in the update .base file for these “deleted” objects may include information indicating that the change records are not currently active. If such an object is selected for inclusion in a subsequent update set of objects, then the update .base file generated the subsequent update can include information indicating that the change records for the object included in the previous update are now active. In this way, change records for a “deleted” object that is re-included in the disconnected investigation are sent only once from the base installation to the disconnected installation.

[0070] For objects in the update set of objects that are new to the disconnected investigation, all change records stored in shared data repository 126 for the new objects may be needed to bring the disconnected installation up-to-date. In one embodiment, identifying objects in the update set of objects that are new to the disconnected investigation involves use of the change set-object relation and information provided by the disconnected installation about the change set in the ordered set of change sets generated for the disconnected investigation that was last incorporated by the disconnected installation. Information about the change set in the ordered set of change sets generated for the disconnected investigation that was last incorporated by the disconnected installation can be provided by disconnected installation to base installation in a variety of manners including, for example, over a periodically available network connection between the base installation and the disconnected installation or in a .dsco file provided by the disconnected installation to the base installation. The change set in an ordered set of change sets generated for a disconnected investigation that was last incorporated by a corresponding disconnected installation is referred to herein as the “last acknowledged change set” for the disconnected investigation.

[0071] At a high level, identifying objects in the update set of objects that are new to the disconnected investigation includes determining the set of objects in the update set of objects that are not included in any previous set of objects generated for the disconnected investigation either as part of creating the disconnected investigation or generating a previous update for the disconnected investigation. In one embodiment, the change records included in the update .base file for an object new to the disconnected investigation correspond to the change records for the object stored in shared data repository 126 that would be included if a new disconnected investigation (i.e., an initial .base file) were being generated at the same logical clock event corresponding to generation of the update .base file.

[0072] Returning to the example discussed above with respect to FIG. 7, assume the investigation subject criteria for the update to the disconnected investigation selected objects 6, 7, and 8 as the update set of objects. As indicated by change-set-object relation 701, only objects 6 and 7 were included in change set 1 when the disconnected investigation was created. A set operation involving the objects included in change set 1 and the update set of objects reveals that object 8 is new to the disconnected investigation. Accordingly, the change records included in the update .base file for object 8 correspond to the change records for object 8 stored in shared object repository 126 having a logical clock value greater than an initial logical clock value and less than a current logical clock value.

[0073] For each object newly added to a disconnected investigation by an update, a record is created and stored in database 122 according to the change set-object relation that indicates the change set for the disconnected investigation in which the new object was first selected for inclusion. For example, as shown in FIG. 8, a new record 801 is added according to the change set-object relation 701 indicating that new object 8 was first selected for inclusion in change set 2.

[0074] In addition, a record is created and stored in database 122 according to the investigation-change set relation identifying the update change set generated for the disconnected investigation and when the update change set was generated according to the logical clock at base installation 100. For example, as shown in FIG. 8, a new record 802 is added according to the investigation-change set relation 702 identifying that update change set 2 was generated for disconnected investigation 1 at logical clock event 105. It should be noted that there is no requirement that a .base file include change records of only one change set and a .base file may include change records of more than one change set. Thus, the .base file may be viewed as a container for one or more change sets.

[0075] In addition to change records for objects new to the disconnected investigation, the update .base file also includes change records for objects in the update set of objects set that are already included in the disconnected investigation that are necessary to bring the corresponding disconnected installation up-to-date with respect to the already included objects. However, in contrast to objects in the update set of objects that are new to the disconnected investigation, the change records selected from shared data repository 126 for each already included object in the update set of objects correspond to the change records for the object having a logical value that is greater than the logical clock value for the lack acknowledged change set according to the investigation-change set relation and less than a current logical clock value. For example, referring to the example of FIG. 8, assume the last acknowledged change set by disconnected installation 200 when change set 2 is being generated is change set 1. The change records for object 6 selected from shared data repository 126 for inclusion in the update .base file for change set 2 correspond to the change records for object 6 having a logical clock value greater than the logical clock for change set 1 (101) and less than a current logical clock value (105). Similarly for object 7. Thus, in contrast to object 8, the change records for objects 6 and 7 included in the update .base file include only those change records necessary to bring disconnected installation 200 up-to-date with respect to previously incorporated change set 1.

[0076] This example is depicted in chart form in FIG. 9. In FIG. 9, change set 1 comprises change records 901 and 902 and change set 2 comprises change records 903, 904, and 905. Change records 901 included in change set 1 correspond to changes made to object 6 in shared data repository 126 between an initial logical clock event at base installation 100 and a logical clock event corresponding to when change set 1 was generated at base installation 100. Similarly, change records 902 included in change set 1 correspond to changes made to object 7 between the initial logical clock value and the logical clock event corresponding to when the disconnected investigation was created. Turning to change set 2 generated for an update to the disconnected investigation, change records 903 included in change set 2 correspond to changes made to object 8 between the initial logical clock event and a logical clock event corresponding to when change set 2 was generated at base installation 100. Change records 904 included in change set 2 correspond to change made to object 6 between the logical clock event corresponding to when the initial .base file was generated and the logical clock event corresponding to when the update .base file generated. Similarly, change records 905 included in change set 2 correspond to change made to object 7 between the logical clock event corresponding to when the initial .base file was generated and the logical clock event corresponding to when the update .base file generated. Thus, assuming disconnected installation 200 had acknowledged incorporating change set 1 to base installation 100 at the time change set 2 is generated, then change set 2 includes only the change records necessary to bring disconnected installation 200 up-to-date with respect to change set 1.

[0077] Providing the Update for the Disconnected Investigation to the Disconnected Installation

[0078] At step 305, the update .base file generated in step 304 is provided to disconnected installation 200. Providing the update .base file to disconnected installation 200 may be performed in the same manner in which the initial .base file was provided to disconnected installation 200. In one embodiment, providing the update .base file to disconnected installation 200 includes making the update .base file available for download over a periodically available network connecting base installation 100 and disconnected installation 200. In another embodiment in which there is no network available between base installation 100 and disconnected installation 200, the update .base file is stored in a portable device or computer-readable medium such as a flash drive, a Compact Disc (CD), or a Digital Versatile Disc (DVD), and delivered manually to disconnected installation 200.

[0079] In one embodiment, steps 304 and 305 are performed periodically to keep disconnected installation 200 up-to-date with the respect to changes made by other users and other investigations to investigative objects in shared data repository 126.

[0080] Loading the Update for the Disconnected Investigation

[0081] Turning to FIG. 4, at step 403, the update .base file provided to disconnected installation 200 at step 305 of FIG. 3 is loaded into disconnected installation 200. Loading the update for the disconnected investigation causes the change records in the update .base file to be incorporated into database 222. In one embodiment, loading the update for the disconnected investigation is performed manually by a remote analyst at disconnected installation 200 in a similar manner used to load the initial .base file at step 401, for example, by double-clicking on the update .base file.

[0082] In the case where the change records in the update .base file do not conflict with changes made to investigative data in database 222, the change records are added to the existing change records stored in database 222 such as those received in prior .base files and any change records in database 222 added by the remote analyst. However, an update. base file may contain change records from the shared data repository 126 that conflict with changes made to investigative data in database 222. For example, before loading an update .base file that includes a change record from shared data repository 126 for a change to a property of an object, a remote analyst at the disconnected installation 200 may have changed the same property of the same object in database 222. In one embodiment, incorporate .base file logic 212 of investigation application logic 210 includes logic for determining a total ordering of change records in an update .base file and database 222 and logic for detecting potential causality violations at disconnected installation 200. In the context of loading an update .base file, a potential causality violation occurs when the update .base file includes a change record corresponding to a change made to shared data repository 126 at base installation 100 that was not, but should have been, based on a change made to database 122 at disconnected installation 200. Specific techniques for determining a total ordering of change records in an update .base file and database 222 and techniques for detecting potential causality violations are beyond the scope of this application but could include, for example, use of vector clocks, Lamport timestamps, version vectors, matrix clocks, etc. In one embodiment, disconnected installation 200 employs its own logical clock separate from the logical clock at base installation 100 for the purpose of determining a total ordering of change records in an update .base file and database 222 and for the purpose of detecting potential causality violations at disconnected installation 200. In one embodiment, the update .base file received at disconnected installation 200 includes logical clock information for determining a total ordering of change records in an update .base file and database 222 and for detecting potential causality violations at disconnected installation 200.

[0083] Generating Interim and Final Results of the Disconnected Investigation

[0084] At step 404 of FIG. 4, interim or final results of the disconnected investigation are generated at disconnected installation 200 in the form of a .dsco file. In one embodiment, generating results of the disconnected investigation includes the remote analyst interfacing with generate .dsco file logic 214 of investigation application logic 210 through front-end logic 205 to export change records from database 222 to a .dsco file created and stored on a filesystem accessible to the computing device hosting the stand-alone investigation application. For example, creating and storing the .dsco file may be caused by the remote analyst invoking an “Export Data” feature of the stand-alone investigation application.

[0085] In one embodiment, the change records from database 222 exported to the .dsco file correspond to only the latest or most recent changes made at disconnected installation 200 to investigative objects. Thus, the generated .dsco file does not include any change records for objects that have not been updated at disconnected installation 200 or any change records for changes that are superseded by later changes.

[0086] Providing Results of the Disconnected Investigation to the Base Installation

[0087] At step 405, the .dsco file generated in step 304 is provided to base installation 100. In one embodiment, providing the .dsco file to base installation 100 includes uploading the .dsco file to base installation 100 from disconnected installation 200 over a periodically available network connecting base installation 100 and disconnected installation 200. In another embodiment in which there is no network available between base installation 100 and disconnected installation 200, the .dsco file is stored in a portable device or computer-readable medium such as a flash drive, a Compact Disc (CD), or a Digital Versatile Disc (DVD), and delivered manually to base installation 100.

[0088] In one embodiment, steps 404 and 405 are performed periodically to keep shared data repository 126 at base installation 100 up-to-date with the respect to results of the disconnected investigation being conducted at disconnected installation 200.

[0089] Loading and Publishing Results of the Disconnected Investigation

[0090] At steps 306 and 307, the .dsco file provided by disconnected installation 200 is loaded at base installation 100 thereby integrating the change records stored therein into database 122. In one embodiment, a user at base installation 100 has the option of either (a) loading and unconditionally publishing the change records stored in the .dsco file to shared data repository 126 or (b) loading and selectively publishing the change records stored in the .dsco file to shared data repository 126. When selectively publishing, the user can specify criteria to investigation application 110 through front-end logic 105 to select some change records stored in the .dsco file for publishing to the shared data repository 126 while discarding other change records. Non-limiting examples of such criteria include ‘created by’ criterion for selecting change records created by a specific remote analyst, ‘created after’ criterion for selecting change records that were created after a specific date, ‘created before’ criterion for selecting change records that were created before a specific date, ‘modified after’ criterion for selecting change records that were modified after a specific date, and ‘modified before’ criterion for selecting change records that were modified before a specific date.

[0091] As with change records received by a disconnected installation 200 in an update .base file, change records received by a base installation 100 in a .dsco file can conflict with other changes. In one embodiment, load .dsco file logic 112 of investigation application 110 includes logic for determining a total ordering of change records in shared data repository 126 and change records in a .dsco file that are to be published to shared data repository 126 and logic for detecting potential causality violations at base installation 100.

[0092] In one embodiment, a .dsco file received from a disconnected installation 200 by a base installation 100 includes an indication of the last change set received from base installation 100 to be incorporated into database 222. In response, investigation application logic 110 at base installation 100 creates and stores a record for the disconnected investigation in database 122 that identifies this last change set acknowledged by the corresponding disconnected installation 200. As explained in greater detail elsewhere in this document, update .base file logic 112 of investigation application logic 110 uses information stored in this record when determining which change records stored in shared data repository 126 to include in an update change set for the disconnected investigation.

[0093] Random Database Identifiers for Disconnected Installations

[0094] In one embodiment, to aide in controlling access to information stored in database 122, database identifiers are encrypted using a secret encryption key that is private to base installation 100. This effectively generates pseudo-random database identifiers for database data making it virtually impossible to acquire information illicitly by comparing two identifiers. For example, if identifiers were allocated sequentially instead, and two objects had identifiers that differed by just one, then a malicious user or software could discover that the two objects came from the same data source, which would be an information leak.

[0095] According to one embodiment, a certain quantity of random identifiers is sent to disconnected installation 200 in the initial .base file generated for the disconnected investigation. Thereafter, disconnected installation 200 consumes random identifiers when making changes to data in database 222. Base installation 100 calculates the number of available random identifiers remaining at disconnected installation 200 based upon the contents of the .dsco files received from the disconnected installation. When the number of available random identifiers at disconnected installation 200 drops below a certain threshold, base installation 100 automatically includes an additional quantity in the next update .base file generated for that disconnected installation.

[0096] If a remote analyst makes many changes to database 222, but does not also provide .dsco files to base installation 100 often enough, the disconnected installation 100 could run low of available random identifiers. In one embodiment, investigation application logic 210 warns the remote analyst through front-end logic 205 informing the remote analyst of the problem, and initiating the .dsco generation process. If the remote analyst successfully creates a .dsco file and provides it to base installation 100, an additional supply of random identifiers is provided automatically to the disconnected installation in the next .base file.

[0097] Base Installation User Interfaces

[0098] FIGS. 10-15 are screen shots of various web pages served by one or more web servers at base installation 100 to either a base web user 103 at base installation 100 or a remote analyst 201 at a disconnected installation 200 according to an embodiment of the invention. In one embodiment, web pages 1000, 1100, 1200, 1300, 1400, and 1500 are provided from one or more web servers at base installation 100 to a remote analyst 201 at a disconnected installation 200 over a periodically available network connecting base installation 100 and disconnected installation 200.

[0099] FIG. 10 is a screen shot of a web page 1000 provided by investigation application logic 110 through front-end logic 105 according to an embodiment of the invention. Web page 1000 includes Manage button 1001, Send Random ID's button 1002, Download .base file button 1003, and Upload .dsco file button 104. Using the manage button 1001 opens a new web page for creating a new disconnected investigation or updating an existing disconnected investigation. Using the Send Random ID's button 1002 opens a new web page for sending additional random identifiers for a particular disconnected investigation to a corresponding disconnected installation. Using the Download .base file button 1003 opens a new web page for generating and downloading a .base file for a disconnected investigation. Using the Upload .dsco file button 104 opens a new web page for uploading a .dsco file to database 122 at base installation 100.

[0100] FIG. 11 is a screen shot of a web page 1100 provided by investigation application logic 110 through front-end logic 105 in response to a user using Manage button 1004 of web page 1000 according to an embodiment of the invention. Web page 1100 includes Step 1 Panel 1101 that includes a select disconnected investigation panel 1103 for choosing an existing disconnected investigation to change by selecting its corresponding radio button, filter panel 1105 for finding and selecting an existing disconnected investigation to change, and new disconnected investigation panel 1107 to begin creating a new disconnected investigation by entering its name and a short description of the new investigation. Web page 1100 also includes next step link 1102 for proceeding to the next step in creating or updating a disconnected investigation.

[0101] FIG. 12 is a screen shot of a web page 1200 provided by investigation application logic 110 through front-end logic 105 in response to a user using next step link 1102 on web page 1100 according to an embodiment of the invention. Web page 1200 includes Step 2 Panel 1201 that includes an add data from template panel 1203, a filter panel 1205, an add data from filter panel 1207, and set default data sources panel 1209. Web page 1202 also includes a previous step link 1202 for returning to Step 1 Panel 1101 and an apply changes button 1204 for applying changes made to an existing disconnected investigation or for creating a new investigation that was specified. With the add data from template panel 1203, a user can choose existing investigations to use a source of data in shared data repository 126 for a disconnected investigation by clicking with a pointing device the corresponding plus signs (+) next to the investigation names, or remove base investigations added previously by clicking the corresponding Xs. In one embodiment, a template is an investigation curated by an analyst at a base installation. The template can be used as a “folder” for objects to add to a disconnected investigation and to complement filters. For example, if in addition to every object satisfying certain filter criteria, it was desired to include objects A, B, and C in a disconnected investigation, those objects could be added to a template investigation and the template investigation added to the disconnected investigation using the add data from template panel 1203. Filter panel 1205 provides controls for filtering existing investigations 124 stored in database 122 to use as a source of data in shared data repository 126 for a disconnected investigation to be created or changed. Add data from filter panel 1207 provides controls for optionally choosing one or more canned filters to use as source of data in shared data repository 126 for a disconnected investigation. Set default data sources panel 1209 provides controls for indicating whether to use the chosen sources of data in shared data repository 126 only for the next .base file that is generated for the disconnected investigation, or for all future .base files generated for the disconnected investigation.

[0102] FIG. 13 is a screen shot of a web page 1300 provided by investigation application logic 110 through front-end logic 105 in response to a user using Send Random ID's button 1002 on web page 1000 according to an embodiment of the invention. Web page 1300 includes send additional random IDs for this investigation panel 1301 for selecting the disconnected investigation to send additional random IDs to and send random Ids button 1302 for including additional random IDs in the next .base file generated for the selected disconnected investigation.

[0103] FIG. 14 is a screen shot of a web page 1400 provided by investigation application 110 through front-end logic 105 in response to a user using Download .base file button 1003 on web page 1000 according to an embodiment of the invention. Web page 1400 includes download base updates for this investigation panel 1401 for selecting the disconnected investigation for which to generate and download a .base file containing the investigation, or an update to the disconnected investigation. Web page 1400 also includes base update summary panel 1402 for viewing information about the sources of published data used to add data to the .base file, and the .base file name. Web page 1400 also includes generate .base button 1403 for generating and downloading a .base file for the selected disconnected investigation. In one embodiment, a downloaded .base file is stored in a portable device or computer-readable medium such as a flash drive, a Compact Disc (CD), or a Digital Versatile Disc (DVD) for manual delivery to disconnected installation 200. Web page 1400 also includes recent .base files generated panel 1404 for viewing a list of recently generated .base files, and optionally downloading a .base file by clicking with a pointing device on the corresponding hyperlink. With web page 1400, generating an update to an existing disconnected investigation is a matter of selecting the existing disconnected investigation using panel 1401 and downloading an update .base file for the disconnected investigation by using the generate .base button 1403.

[0104] FIG. 15 is a screen shot of a web page 1500 provided by investigation application 110 through front-end logic 105 in response to a user using Upload .dsco file button 1004 on web page 1000 according to an embodiment of the invention. Web page 1500 includes select a .dsco file panel 1501 for selecting the .dsco file from a locally available filesystem to upload. Question panel 1502 includes controls for choosing whether to upload the investigative data from the selected .dsco file and publish all the investigative data immediately and unconditionally to shared data repository 126, or upload the investigative data only and set the disconnected investigation status to “Awaiting Review”, requiring a base user 101 or a base web user 103 to review the data and publish it selectively to shared data repository 126. Web page 1500 also includes upload .dsco file button 1503 for uploading the .dsco file that is selected in panel 1501 and for processing the selected .dsco file according to the publishing option selected in panel 1502. In one embodiment, a .dsco file is made available for upload from a portable device or computer-readable medium such as a flash drive, a Compact Disc (CD), or a Digital Versatile Disc (DVD) provided to base installation 100 from disconnected installation 200.

[0105] Implementing Mechanisms—Hardware Overview

[0106] According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. The special-purpose computing devices may be hard-wired to perform the techniques, or may include digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques, or may include one or more general purpose hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices may also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the techniques. The special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices or any other device that incorporates hard-wired and/or program logic to implement the techniques.

[0107] For example, FIG. 16 is a block diagram that illustrates a computer system 1600 upon which an embodiment of the invention may be implemented. Computer system 1600 includes a bus 1602 or other communication mechanism for communicating information, and a hardware processor 1604 coupled with bus 1602 for processing information. Hardware processor 1604 may be, for example, a general purpose microprocessor.

[0108] Computer system 1600 also includes a main memory 1606, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 1602 for storing information and instructions to be executed by processor 1604. Main memory 1606 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 1604. Such instructions, when stored in non-transitory media accessible to processor 1604, render computer system 1600 into a special-purpose machine that is customized to perform the operations specified in the instructions.

[0109] Computer system 1600 further includes a read only memory (ROM) 1608 or other static storage device coupled to bus 1602 for storing static information and instructions for processor 1604. A storage device 1610, such as a magnetic disk or optical disk, is provided and coupled to bus 1602 for storing information and instructions.

[0110] Computer system 1600 may be coupled via bus 1602 to a display 1612, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 1614, including alphanumeric and other keys, is coupled to bus 1602 for communicating information and command selections to processor 1604. Another type of user input device is cursor control 1616, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 1604 and for controlling cursor movement on display 1612. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

[0111] Computer system 1600 may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system 1600 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 1600 in response to processor 1604 executing one or more sequences of one or more instructions contained in main memory 1606. Such instructions may be read into main memory 1606 from another storage medium, such as storage device 1610. Execution of the sequences of instructions contained in main memory 1606 causes processor 1604 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

[0112] The term “non-transitory media” as used herein refers to any storage media that stores data and/or instructions that cause a machine to operation in a specific fashion. Such non-transitory media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 1610. Volatile media includes dynamic memory, such as main memory 1606. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.

[0113] Non-transitory media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between non-transitory media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 1602. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

[0114] Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 1604 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 1600 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 1602. Bus 1602 carries the data to main memory 1606, from which processor 1604 retrieves and executes the instructions. The instructions received by main memory 1606 may optionally be stored on storage device 1610 either before or after execution by processor 1604.

[0115] Computer system 1600 also includes a communication interface 1618 coupled to bus 1602. Communication interface 1618 provides a two-way data communication coupling to a network link 1620 that is connected to a local network 1622. For example, communication interface 1618 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 1618 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 1618 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0116] Network link 1620 typically provides data communication through one or more networks to other data devices. For example, network link 1620 may provide a connection through local network 1622 to a host computer 1624 or to data equipment operated by an Internet Service Provider (ISP) 1626. ISP 1626 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 1628. Local network 1622 and Internet 1628 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 1620 and through communication interface 1618, which carry the digital data to and from computer system 1600, are example forms of transmission media.

[0117] Computer system 1600 can send messages and receive data, including program code, through the network(s), network link 1620 and communication interface 1618. In the Internet example, a server 1630 might transmit a requested code for an application program through Internet 1628, ISP 1626, local network 1622 and communication interface 1618.

[0118] The received code may be executed by processor 1604 as it is received, and/or stored in storage device 1610, or other non-volatile storage for later execution.

[0119] In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.