text:
|Publication number
|Publication type
|Application number
|Publication date
|Mar 6, 2012
|Filing date
|Mar 31, 2008
|Priority date
|Mar 30, 2007
|Fee status
|Also published as
|Publication number
|Siew Yong Sim-Tang
|Original Assignee
|Quest Software, Inc.
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (232), Non-Patent Citations (20), Referenced by (20), Classifications (8), Legal Events (5)
|External Links: USPTO, USPTO Assignment, Espacenet
This application is based on and claims priority to Ser. No. 60/909,098, filed Mar. 30, 2007.
This application is related to the following commonly-owned applications:
Ser. No. 10/841,398, filed May 7, 2004, titled "Method and system for automated, no downtime, real-time, continuous data protection,"
Ser. No. 10/842,286, filed May 10, 2004, titled "Method and system for real-time event journaling to provide enterprise data services,"
Ser. No. 10/863,117, filed Jun. 8, 2004, titled "Method and system for no downtime, real-time, continuous data protection,"
Ser. No. 10/862,971, filed Jun. 8, 2004, titled "Method and system for no downtime, resynchronization for real-time, continuous data protection,"
Ser. No. 11/185,313, filed Jul. 20, 2005, titled "Method and system for virtual on-demand recovery for real-time, continuous data protection," and
Ser. No. 10/943,541, filed Sep. 17, 2004, titled "Method and system for data protection."
Ser. No. 11/638,253, filed Apr. 26, 2007, titled "Method and system for managing real-time data history of a file system."
Today's legacy data protection and recovery solutions are highly fragmented across a wide variety of applications, systems, and storage models. The overhead and data management maze that existing approaches bring to the network, storage, tape, and application infrastructure has caused increasing expenditures with little tangible returns for the enterprise. Worse, manual recovery techniques compound the problem with the same issues that cause downtime in the first place—human errors and process issues constitute 80% of unplanned downtime.
One recently-introduced technique for addressing the complex problem of providing heterogeneous, enterprise-wide data management is illustrated in
As described in co-pending application Ser. No. 10/841,398, the DMS system associates a "host driver" 128 with one or more of the application(s) running in the application servers 116 to transparently and efficiently capture the real-time, continuous history of all (or substantially all) transactions and changes to data associated with such application(s) across the enterprise network. This facilitates real-time, so-called "application aware" protection, with substantially no data loss, to provide continuous data protection and other data services including, without limitation, data distribution, data replication, data copy, data access, and the like. In operation, a given host driver 128 intercepts data events between an application and its primary data storage, and it may also receive data and application events directly from the application and database. The host driver 128 may be embedded in the host application server 116 where the application resides; alternatively, the host driver is embedded in the network on the application data path. By intercepting data through the application, fine grain (but opaque) data is captured to facilitate the data service(s). To this end, and as also illustrated in
As described in co-pending application Ser. No. 11/123,994, each DMS node executes an object runtime environment. This object runtime environment includes an object manager that manages the lifecycle of all the DMS objects during runtime. The object manager creates DMS objects, and the object manager saves them in the shared storage. The objects continually undergo modification as the system protects data in the enterprise's primary storage. In an illustrative embodiment, the system automatically creates a trail of objects called versions; typically, the versions do not actually exist on primary storage, outside of the data management system. The DMS manages the creation, storage, display, recovery to primary storage, deletion (automatic via policy, or manual) and the like, of these versions. The host drivers protect data into the continuous object data store. Using this architecture, data in primary storage can be recovered to any point-in-time.
A data management method is provided for storing a real-time history of a file system, or a component thereof, such as a directory or a file. The real-time history is stored as an object-oriented logical representation comprising at least a set of version metadata objects, and a set of one or more links that associate given objects of the set of version metadata objects. As one or more events occur in the real-time history, the logical representation is restructured dynamically. The logical representation is useful to provide any point-in-time reconstruction of the file system component on an as-needed basis.
A data management system (DMS) includes a continuous real-time object store that captures all real-time activities, with associated object metadata information. The DMS is capable of reintroducing any point-in-time view of data ranging from a granular object to an entire file system. A set of algorithms (for creation of a file or directory, modification of a file or directory, deletion of a file or directory, and relocation/renaming of a file or directory) are used to generate and maintain a file system history in the DMS and to ensure that a latest version of a directory always refers to a latest version of its children until the directory changed. Any point-in-time recovery is implemented using the file system history in one of various ways to provide strong individual file integrity, exact point-in-time crash consistency, and/or recovery of last version of all files.
The foregoing has outlined some of the more pertinent features of the invention. These features should be construed to be merely illustrative. Many other beneficial results can be attained by applying the disclosed invention in a different manner or by modifying the invention as will be described
For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
As described in U.S. Ser. Nos. 10/841,398 and 11/123,994, the DMS provides real time data services, such as continuous data protection, data replication, data distribution, any-point-in-time recovery, and any-point-in-time snapshot. To support these services, preferably the DMS host driver resides in an application host or the network, monitoring and capturing application events and data changes in real time, and then processing and forwarding actual data changes, events, and metadata to a DMS node. The host driver preferably performs delta reduction (e.g., to extract byte level changes), identifies metadata changes such as access control, detects application checkpoint events, and then forwards this information as a stream to a DMS node in a DMS cluster. A DMS cluster is a group of DMS nodes that share a storage module. These nodes work as a cooperative unit. Preferably, they obey a set of access rules such as acquiring lock of different classes, and they honor the access locks of the others so as to perform parallel access to the storage module. These nodes also watch for the health of one another and when one node fails, the other nodes preferably repair any partially modified or corrupted data that may be caused by the failure, and take over the tasks of the failed node.
The DMS nodes are the entities that provides real-time data services. When providing continuous data protection and data distribution as subscriber, the nodes take incoming data streams, preferably translate the streams into an object-oriented data structure (or another structure that provides similar data associations and indices), and save the data in a storage module that is referred to herein as an object store. The object store is designed with the purpose of managing real-time continuous history. When providing data replication, data recovery, and generating a snapshot, the DMS node navigates its object store, reconstructs a desired point-in-time data object, and forms outbound data streams that are then delivered to target nodes or host machines. To provide continuous replication, once replicating a point-in-time data object, the DMS node also forwards, to a remote DMS or a remote host server, a continuous redo log of the objects (in the form of a real-time event journal). A goal of the DMS is to store fine grain and real-time data history. Thus, the DMS object store is designed to track fine grain data changes without using excessive storage. The DMS preferably also indexes by time and events all fine grain objects, application checkpoints, and metadata globally across DMS clusters. The events may include any object events such as email arrival, transaction activity, a file open, a file modification, a file close, a directory change, an application checkpoint, a system upgrade, a virus detection (such as from an external network service), a business event tag, or the like.
The DMS nodes create distributed object storage to provide the necessary real-time data management services. The objects created by the DMS nodes are sometimes referred to herein as active objects. The active objects at any moment in time may be dormant in the storage or instantiated by the DMS nodes to handle requests and to perform activities. The details of active objects are discussed in the following sections.
The distributed object store can be built above raw storage devices, a traditional file system, a special purpose file system, a clustered file system, a database, and so on. Preferably, DMS chooses to build the distributed object store over a special purpose file system for storage and access efficiency. The files in the special purpose file system and the active objects in the DMS preferably are all addressed by a (e.g., 128 bit) global unique identifier (GUID). During runtime, a GUID can be de-referenced to a physical address in a storage device. By doing so, this allows the object store to scale beyond a single storage device, such that an object (1) in a device (A) can refer to another object (2) in device (B), e.g., by referring to the GUID of object (2).
Preferably, each DMS node executes an object runtime environment. This object runtime environment includes an object manager that manages the lifecycle of all the DMS objects during runtime. The object manager creates DMS objects, namely the active objects, and the object manager saves them in the shared storage. When requested, the object manager loads an existing active object from the storage, and then routes object requests directly to the instantiated active object. Once an active object is created or loaded (instantiated) into the memory, it is responsible for executing requests routed from the object manager. The object manager may perform authentication and/or authorization before allowing any access to an active object. An active object, upon request, may update its internal information, execute an object specific program, and terminate itself from the runtime environment. Both the object manager and the active objects are responsible for acquiring shared lock as necessary so that all the nodes can have parallel access to the same objects. The object manager is also responsible for permanently removing active objects from the shared storage when requested. In a non object-oriented embodiment, an object manager may not be required. Also, while the use of an object manner is preferred, it is also possible to implement the present invention by storing the object information in a different manner while still achieving similar results, and the processes and object functions that change the information may be modified accordingly.
Preferably, an instance of an active object has a set of properties, with each property having a label and value pair. For example, an active object may have one property labeled as "name" with an associated value being "The design of a PC," and another property labeled "content" which associated value is a binary blob. A property has a value type definition, for example, the value of the "name" property is a string, and the value of the "content" property is an opaque binary chunk of data.
In the context of a traditional file system, preferably all properties beside the "content" property are classified as metadata whereas, in the DMS, preferably all properties including the "content" itself are managed as metadata. Preferably, the DMS active objects store metadata from the protected server as well as metadata generated by the DMS itself. In DMS active object point of view, all the properties are metadata, including the binary content from the external world, while binary content is just a specific property type (random access binary blob type).
A property on an active object preferably also has specific attributes such as—modifiable, modifiable-internal, read-able, versionable, single-value vs multi-value, inheritable, index, mandatory, replicate-able, and the like. Some object properties, such as ObjectClass, ObjGUID, Creator, ExternalCreationDateTime, and DMSCreationDateTime do not change once the object is created, while the other properties can be modified. There are also properties, such as Version, DMSModifiedDateTime, and DMSTerminationDateTime, that are not modifiable by any external entity besides the Object Manager and the object itself.
To track real-time changes, some object properties are defined as version-able. In the DMS, an object data structure for tracking data history is as shown in
In DMS, preferably all the anchor and version metadata pages are combined together into a variable sized file. If desired, each one of the pages can be stored in a separate file, or in raw storage blocks. When stored in files, each file is also named by GUID. There are page GUID to file GUID mappings, and file GUID to physical address mappings so that the physical data of an object can be retrieved. An object can be reference by the GUID of its anchor page, or the GUID of its version metadata page. When referred by the GUID of its version metadata page, a point-in-time object is presented.
According to another aspect of the inventive DMS, an active object has a basic set of behaviors and some specific set of behaviors that are schema dependent and may be created specifically for the class definition. These functions may be implemented readily in software code, i.e., as a set of program instructions executable in a processor. CreateObject( ) creates a physical active object in the DMS object store, while DestroyObject( ) removes the physical object completely. Once created, an active object can be instantiated by ObjectOpen( ) and it can be manipulated. ObjectClose( ) ends the execution cycle of an object. ObjectTerminate( ) terminates an object version and prevents a new version from ever be created. ObjectGet( ) and ObjectSet( ) are for accessing a single value property; the generic behavior for setting a property is to first validate the property type before allowing the update to occur. ObjectMVGetFirst( ), ObjectMVGetNext( ), ObjectMVGet( ), ObjectMVAdd( ), and ObjectMVDelete( ) are for accessing a multi-value property. A multi-value property has unique key, for example, CHILDREN may be a multi-value property, and its unique key may be the name or the GUID of the child. ObjectRead( ), ObjectWrite( ), and ObjectApply( ) are for accessing metadata of a random access binary blob type. ObjectRecordAppend( ), ObjectRecordGetFirst( ), ObjectRecordGetNext( ), and ObjectRecordGetAt( ) are for accessing metadata of sequential access binary blob type.
The above object interfaces are a representative subset of the actual basic object behaviors of the DMS. There are merely illustrative of the functional behavior of the active objects. If desired, an object class may define its own set of specific behaviors.
In DMS, and as will be described in more detail below, preferably there are many data source active object classes, for example, a directory object, a file object, database object, and the like.
Active object binary data management is designed for managing history of random access binary blob property type. As shown in
For the active objects to manage history of sequential access binary blob such as database journal activities, a binary page of sequentially appended records structure can be used in the DMS. Records management is designed for managing property type of sequential access binary blob. There are three different types of record management namely—formatted records, unformatted records, and file object associated records. Formatted records are a sequence of well defined records, each record is of specific structure of fields, and each field has well defined data type and length. A record schema (record structure definition) is defined for formatted record property type. This type of record can be used to track SQL requests of a database history, or email activities of an email server history. A formatted record can also be used to track real-time events associated with any data object. Unformatted records are a sequence of binary record chunks, in this case, the record chunks may be appended continuously to a binary data page with or without a header that specifies the length of the record. Alternatively, records can be appended to a binary data page without a header, in which case, the boundary of each record chunk is tracked separately. The boundary of unformatted records can be tracked using formatted record management structure. This type of record can be used to track sequential binary journal of a database or sequential journal file of any application. The characteristic of this type of binary journal is that records are always appended to the end and never override previous records. File object associated records are sequences of meta-information containing binary data updates to an associated file object. A file object associated record is used to track the location and length of each modification to a file object. Besides tracking the file modifications, a file object associated record can also be used to track checkpoints that occur with respect to the file.
Once an object schema is created, an active object instance can be created from the schema. The active object instance has the defined metadata and behavior. As in any object-oriented system, an object schema may be defined based on another object schema so that metadata and behaviors can be inherited, or so that coded functions can be reused. In DMS, a generic object is clsObject, which defines basic metadata such as name, creation date and time, creator, modification data and time, and so on. It also defines the basic object behavior. Preferably, other object schemas are defined based on clsObject (i.e., they inherit from clsObject). The object inheritance feature is an advantage of the object-oriented embodiment, however, it is not a limitation of the invention.
Thus, to provide real-time data management services, DMS preferably defines a set of data management specific object schemas as shown in
The schema clsDMSSystem is a class for creating a DMS cloud active object 520 that represents the logical network of the entire DMS system (with multiple DMS clusters over multiple regions). Preferably, there is only one instance of clsDMSSystem in a DMS network, as it is the root object instance of the entire DMS network. Preferably, this object is used for tracking DMS regions 512 (each as an instance of a clsRegion schema as described below) and DMS functional groups that own data across regions 516 (each as an instance of a clsGroup schema as described below). The instance typically has a randomly assigned unique identifier. The instance preferably is created automatically by the DMS network when a first cluster is configured, i.e. it is created by a first node. This object instance is populated to all the storage clusters in the entire DMS network. Preferably, there is only one master copy of this object, which is the original copy, the one that was created first. When the properties of the instance change, the properties are populated to all replicas.
The schema clsRegion is a class for creating DMS region active objects 512 that represents and tracks a DMS cluster network, data network, and server network. Preferably, there is one instance of clsRegion in each physical location. An active object instance of clsRegion is used for tracking all the DMS clusters 530 (each as an instance of a clsCluster schema as described below), repositories 514 (each as an instance of a clsRepository schema as described below), and host servers 528 (each as an instance of a clsHost schema as described below) in the region. Because each region may have multiple storage clusters, the local instance of the clsRegion object is replicated to all the local storage clusters. The GUID of each instance of clsRegion are randomly assigned when created. Preferably, policies are encoded as properties in clsDMSSystem, clsRegion, clsRepository, clsGroup, and clsXXDataSource.
The schema clsRepository is a class for creating a DMS data container 514 for storing protected data sources. A repository instance may have sub-repository instances 514 and/or protected data sources 518. A root repository object that is directly under a region represents a segment of a data network. A repository may be a child of a region or a child of another repository. The child of a region is the root of a DMS data object hierarchy. The repository object provides regional data grouping and policy enforcement. The policies in a repository are executed against all the data sources within the scope of the repository. Alternatively, a separate policy object may be defined and used for storing policies explicitly in the data hierarchy. If policy object instances are used, they can be attached to any one of the data container object instances.
The schema clsXXDataSource is a class for creating data source instances 518. Preferably there are three basic data source schemas, clsFSDataSource, clsDatabaseDataSource, clsCompoundDataSource. If desired, there may be more schemas for application data other than the file system and one or more databases. An active object instance of a clsXXDataSource is a root container for a protected data source where a data source from a host is streamed. An instance of clsFSDataSource contains a file, a directory, or a volume of a file system and its history, while an instance of a clsDatabaseDataSource contains one or more databases and their history from a database server. An instance of a clsCompoundDataSource is a container for multiple data source instances. Unlike a repository that only provides logical containership, a compound data source instance preferably provides activity sequencing and indexing, as well as consistency marking to the real-time activities of its related group of data sources so that group consistency can be maintained.
The class clsFile is a schema for creating object instances for the DMS to store the information of a file 520 from a host server and also to track the history of that file in the host. An instance of a clsFile is similar to a file in a file system, except that an instance captures, indexes and manages file history. In DMS, this object is used for data protection, with each instance of clsFile used to represent an external file in an external host.
The class clsDirectory is a schema for creating object instances for the DMS to store the information of a directory 522 from a host server and also to track the history of that directory in the host. An instance of a directory simply represents a container of files and other sub-directories.
The class clsDatabase is a schema for creating object instances for the DMS to store the information of a database 524 within a database server, and also for tracking and indexing the history and checkpoints of that database in the server. This object is used to provide database protection services. An instance of a clsDatabase represents a continuous consistent image of a database, across a range of time, from an external host server.
The class clsJournalGroup is a schema for creating object instances 526 for the DMS to journal the redo and undo log (journal) activities of a database. The database journal activities may be a sequence of updates to a group of related journal log files, or application level transaction records.
The class clsRecordFile is a schema for creating object instances 527 for the DMS to track sequential journal entries within a journal group.
An active object instance of the clsHost is created whenever a host driver from a new host server first connects to the DMS network. This object allows the DMS to track the data services provided to the information on the host 528. This object also associates the protected data sources in the DMS to the data source on its host server. An instance of clsHost preferably contains information such as the platform of the host, the operating system, the host configuration, data sources that are protected from the host, DMS data sources that are replicated to the host, and the like. The protected or replicated data source properties preferably include the host path, the size of the sources in the host, the activities and statistical information about those data sources, and the GUID of the clsXXDataSource instance.
An active object instance of the clsDMSCluster schema represents a DMS cluster 530 with one or more DMS nodes and the DMS storage. This instance provides statistics and status information of its specific cluster. Typically, there is only instance per storage cluster, thus the processes (e.g., the object runtime environment) of all the nodes use this instance as shared memory to keep information such as node availability, master election, and the like. Information about a DMS cluster (as instances of a clsDMSCluster), a DMS node (as instances of clsDMSNode), and DMS storage (as instances of clsDMSStorage) may be stored together with the other active objects or may be in a specific volume used exclusively by the cluster manager.
An active object instance of the clsDMSNode schema represents a DMS node 532 within a DMS cluster. This instance provides statistics and status information about the DMS node it represents. Preferably, the object runtime environment of a node is responsible for locating a cluster and joining that cluster. Once joined in a cluster, the runtime environment creates the clsDMSNode instance.
An active object instance of the clsDMSStorage schema represents the storage volumes 534 of a DMS cluster. This instance allows the DMS storage to be configured, and it also provides statistics and status information of the storage volumes.
An active object instance of the clsGroup schema is a data container that also represents a logical group 516 in an organization. This allows user to map data sources from one or multiple repositories in one or more regions to a functional group of an organization. Its purpose is to enable an administrator or other permitted entity to assign data management policy across multiple regions.
As described above, in the
Similar to an instance of a clsPolicyProfile object, an active object instance of a clsPolicyOverride can be introduced that may also contain a subset of data management policies. When assigned to a data container or data object, the policies in the override object takes precedent over the default policy on an assigned policy profile objects.
The DMS object definition discussed above is merely one way of organizing the control, data and functional structure for the DMS to provide real-time data management services. One could easily reorganize the structure to achieve that goal, and the present invention is not limited to any specific organization. Thus, for example, clsRegion may be broken down in to multiple hierarchies to represent local lines of business and departments, clsDMSCluster may include and nodes and storage so as to eliminate clsDMSNode and clsDMSStorage definitions, clsJournalGroup may be part of clsDatabase definition, and so on. Also, as described above, the effect of this object-oriented hierarchy can be realized in different non object-oriented structures, such as a relational database. All of these variants are within the scope of the present invention.
Whenever a DMS host driver is installed into a host server, the host driver reports to the DMS, and this operation results in an instance of host object 528 being created in the DMS. As noted above, preferably a host object 528 contains information such as the host OS and platform about the host server. Once a host object is created, IT administrators can identify host data to be protected, and then configure for the host data to be protected. An IT administrator can also configure for DMS protected data to be replicated to a host server. As noted above, the host active object refers to the data source(s) that are protected from its host server or data sources that are replicating to its host (as illustrated by the link between 518 and 528). The host objects in the DMS form an external host server network 506.
A region may have one or more DMS clusters, with all DMS clusters preferably tracked by the DMS via DMS cluster active objects 530. Each cluster has a representation active object that refers to the node active objects 532 and storage active objects 534. The cluster object also contains cluster statistic and status information. A node object 532 contains configuration information, statistics and status about the node. The storage object contains storage volume information, and storage group information. Volume information includes all the raw storage volumes that are provisioned to the DMS. It also includes the DMS partitioning of the raw storage volumes, and the assignment of the partitions to storage groups. In the DMS, a protected data source has its own storage space that is called a storage group. A storage group is an aggregated DMS storage partitions carved out from the volume groups. The cluster, storage, and node objects form a DMS server network 504.
File System Data History
The following section describes representative object schemas defined for protecting a file system. Preferably, and with reference to
In the context of a file system at a host server, typically all properties except the content are usually known as metadata. As described above, the DMS active objects store metadata from the protected host server as well as metadata generated by the DMS itself. In the DMS, all the properties are metadata including the binary content from the external world. For a clsFile object, binary content is a "content" property with random access binary blob type.
This is a schema of a file system data source; as noted above, this object preferably serves as a container for the history of a protected file system or folder in a host. It is also a data service entity for managing inbound and outbound traffic for the file system, the policy management entity for its data, and a security guard for any access to the protected data history.
The properties of this object class typically include the configuration of the protected data source. The following table illustrates representative property examples of this object class:
Properties of
Name of the data source
GUID of its parent container (a repository object)
Timestamp when this data source container is created
The user ID of the creator
Key or GUID to the access control list of this object
File system
Protecting, replicating, disconnected from host, and the like
Active, archived
GUID of the original protected data source (if this is a replica)
GUID of the replicas that need input from this object
GUID of the associated host object where the data source resides
The path name in the host that is protected by this object
Timestamp when protection begun
Timestamp when this data source became idle
The root directories or files in this container
List of entries with event and timestamp. The events are in data source
level, may be set by users.
The above table is a subset of properties used in the DMS; one may add more or remove some of the above properties. For example, policy may be added, and one may not need RuntimeStates. In one embodiment, the properties of this object are not versioned so that the history of the object is not tracked. Alternatively, one can version some of the properties, such as HostPath, ProtectedDateTime, ArchivedDateTime, and Children, such that these configuration changes are recorded in time. When properties are versioned, it is desirable to track the version begin and end timestamp.
The ClsDirectory schema is defined for tracking the history of a directory (folder) in a file system. This schema is used for protecting a directory, and it is capable of recovering a directory to any point-in-time in the past.
The properties of this object class preferably include the following:
Properties of
GUID of this object instance, also GUID of this anchor page
GUID of its protection data source container
Timestamp when this object is created (from the protected host)
The user ID of the creator
Timestamp when this object is deleted (from the protected host)
List of entries with event and timestamp. The event tags may be set by
users for tracking purposes.
GUID of the first version
GUID of the latest version
Total number of versions
Versioned Properties:
The version GUID of this object, also GUID of this page
The GUID of the anchor page (i.e., the GUID of this object)
The version GUID of the previous version
The version GUID of the next version
GUID of parent object which can either be the data source container or
another directory
Name of the directory
Timestamp when the version is created (or when the modification occurs)
ID of a user who modified the directory
Timestamp when this version is ended (i.e., a new modification results in
another version being created and old version ended)
Key or GUID to the access control list of this object
Number of children
A list of its children which can be sub-directories or files. Each entry is a
reference to the version ID of a child.
These properties are merely illustrative of what a directory active object contains. One may include more properties, such as a full path name, children name, policies, metadata from the host server, and more.
As can be seen, the above table shows the logical information of a directory object. Whenever a new child is added, an existing child is deleted, the directory is moved, the directory is renamed, or the name of its child has changed (if child name is also captured in this object), a new logical version of the directory is created. Whenever a new version is created, preferably a previous version is terminated. DateTimeModified of a new version must be after or same as the DateTimeEnd of the previous version. ModifiedBy indicates the user who made the modification to create the new version. If desired, an Event tag may be added; preferably, it is a sequence list of entries each having a timestamp.
This logical layout may map directly into a physical store (e.g., overlaying a file system or a database), but this is not required. With respect to persistent storage, preferably DMS stores multiple logical versions of a directory in one physical store unit. Or, DMS may also combine multiple versions into one directory journal. For example, one physical storage unit of a directory object may contain the initial directory baseline information and all the changes to a directory within a period of time. A directory journal entry may be "version ID, DateTimeModified, add new child, child GUID, . . . " and so on. Once that is done, a logical version of a directory can be constructed on demand (i.e., upon request) by applying the necessary activities to a baseline directory image. The present invention is not limited to any physical layout of the object in the physical store.
In this example, in the first version 612, the directory object only has the version 1 of a subdirectory object, namely, DOO 617. At some point in time, the subdirectory object changed its name to WOO; thus, a version 2 of the subdirectory object was created and is represented by reference number 618. In this example, the directory active object tracks its children's name; thus, version 2 of FOO 613 was created to link to the version 2 of the subdirectory WOO 618. On version 3 of FOO 614, a new file of the name GOO under the directory FOO was created. This is illustrated by reference numeral 619. The links, shown as dotted arrows, are references of the CHILDREN property of the directory object. As can be seen, these links allow active objects to build up object relationships or object hierarchy (e.g., a parent-child relationship). The result is a logical view of the directory data structure. To conserve data storage usage, the directory version pages may be combined into a table or a journal, and the table or journal may be stored in a physical storage unit. For simplicity, it should be appreciated that the above diagram does not show the complete subdirectory and file objects (for example, the anchor pages of the file and subdirectory objects are not shown).
The ClsFile schema is defined for tracking the history of a file from a file system. This schema is used for protecting a file, and it allows for the recovery of the protected file to any point-in-time in the past.
The properties of this object class preferably include the following:
Properties of clsFile
GUID of this object instance, also the GUID of this anchor page
GUID of its protection data source container
Timestamp when this object is created (from the protected host)
The user ID of the creator
Timestamp when this object is deleted (from the protected host)
List of entries with timestamp, user id, and access mode.
List of entries with event and timestamp. The event tags may be set by
users for tracking purposes.
GUID of the first version
GUID of the latest version
Total number of versions
Versioned Properties:
The version GUID of this object, also GUID of this page
The GUID of the anchor page (the ID of this object)
The version GUID of the previous version
The version GUID of the next version
GUID of parent object which can either be the data source container or a
Name of this file at this version
Timestamp when the version is created (or when the modification occurs)
ID of a user who modified the file
Timestamp when this version is ended (i.e., a new modification results in
another version being created and an old version ended)
Consistency, DMS checkpoint, suspect
Key or GUID to the access control list of this object
A hash key of the entire content (e.g. MD5, SHA-1, CRC, or the like)
A sequence of hash keys each generated from a contiguous chunk of the
The sparse index of this version. Sparse index is byte level reference to
the binary content. Binary contents are in baseline binary pages and delta
Additional metadata and
Information from the original document
The above table is merely illustrative; other properties, such as a full path name, policies, and the like, may be included. As can be seen, the non-versioned properties preferably include a timestamp when the object is created, creator information, identification of access journal for forensic purposes, and event tags for tracking user events across time line. The versioned properties preferably include name, modification information, status, ACL, and content. Preferably, a new logical version is created when the name of the document changes, the content of the document changes, the ACL changes, document metadata or attributes change, or when the document is moved. When the document is deleted from the protected data source, the file object at the DMS is terminated with (DateTimeTerminated timestamped), and the last version ended.
In the DMS file object, preferably each version has an associated property called "CONTENT," and this property is of the type random access binary blob. The binary value of this property type may be stored inside or outside of the metadata page. In this example, the binary data of version 1 is in the binary page 716, which has its own GUID. The changes (deltas) that are made to the file for version 2 are stored as a sequence of forward deltas in the delta page 717. The changes (deltas) of version 3 are appended to the same delta page 717 or another new delta page. A file object may have one or multiple binary pages. The binary pages contain the baseline data. A file object also may have one or multiple delta pages for all its changes. The sparse index refers to the data in both the baseline and the deltas to make up the content for the version. The binary and delta pages may be stored in one physical storage unit; alternatively, the pages may be broken up and stored in multiple physical storage units. As one of ordinary skill will appreciate, the above-described example is simply one way in which DMS structures the binary data. Alternatively, each version may have its own binary pages so that no delta has to be kept. Yet another alternative is to store reverse deltas or multiple baselines at different versions with a combination of reverse and forward deltas.
This file object structure and the associated metadata allows DMS to track a file history, e.g., what information has changed at what time, by whom, through what event, and what meaningful events to this object occurred during the object's lifecycle. To conserve data storage usage, preferably the metadata of the version pages may be combined into a table or a journal, and preferably the table or journal may be stored in a physical storage unit. Also, this structure can be stored over a raw storage device, or by overlaying a file system or a database.
History of Protected File System
In this example, it is assumed that the entire file system is uploaded to the DMS for protection from a host server at T1. This is represented by FSDS 801 (DataSource 1). At T1, there is a version 1 of the directories 811 and 821, and of the files 841 and 851. While this representation refers to a time T1, this time may be a time range or period, as upload of the entire file system typically takes a given amount of time.
At T2, the content of the file by the name "fo1" changed, which is represented by the new object 842. Because this is a content change, the parent "do1" v1 (reference numeral 811) is unaffected.
At T3, the directory by the name "do2" changed its name to "dox" (as now indicated by object 822). Because in this example a directory also tracks the name of its children, this change causes parent "do1" (which has reference to this object) to also generate a new version 812.
At T4, a new file by the name "fo3" is added to "do1" (as now indicated by object 831); thus, a third version of "do1" is generated as indicated by reference 813.
As can be seen, within this DMS file system history, preferably there are version links, parent-child links (i.e., object relationships), as well as the data links to binary and delta pages (852, 843, 844). Therefore, this structure forms a three dimensional (3-D) object store. Navigating this object store enables DMS to identify the history and state of the DataSource 1 at any point-in-time, as will be described in more detail below.
As mentioned in the above sections, physical structure of the object versions can be organized in any fashion to optimize for the storage usage at the DMS.
As also mentioned, an alternate non object-oriented embodiment may be implemented with techniques that link and index the object versions, object relationships and data changes by applying a schema over a relational database, together with a set of processes (described below) that update the database according to the invention.
File System Events and DMS Operations
The above sections discuss the DMS logical object data structure for file system protection. The following sections discuss the functional behavior of file system protection in more detail.
The following is directed to the end-to-end process (e.g., from host driver to active objects in one cluster, or from active objects in one cluster to active objects in another cluster) that changes the DMS logical object store structure when a file system history is captured. In particular, this disclosure also describes the processes involved in the storing of real-time history of a file system, and the use of the real-time history for any point-in-time recovery for guaranteed consistency. The DMS file system history structure changes are triggered by one or more events from file system, users, or applications.
Thus, as illustrated in
DMS Processes for File System
The following sections describe the DMS (host driver and active object) processes and the associated data history structure changes in response to specific file system events. Illustrations of sample DMS file system history are shown for each case. For illustrative purposes,
Creation of a File or a Directory
The creation of a file or a directory in the DMS file system history structure is initiated by a CREATE event captured by a DMS host driver operating to provide data protection, or by a similar event distributed from one data source to another data source. This function is illustrated in the process flow of
This process begins with the DMS host driver capturing a file or directory CREATE event at step 1071. The host driver then issues an Object Create command to the associated DMS file system data source to create an active object with the following parameters—object class, parent path, object name, creation timestamp, owner, ACL, and other attributes. This is step 1073. An object manager at the DMS handles the request for the DMS file system data source object by opening the parent active object and creating a new version thereof. This is step 1075, and this operation has been described and illustrated above. The DateTimeEnded of the parent's previous version is set to T, and the DateTimeModified of its new version is set to T as well. The object manager also creates a new file or directory object with a first version and sets all the properties as necessary. This is step 1077. The DateTimeCreated property in the anchor of the new object is set to T, as is the DateTimeModified property in the first version. Preferably, the state of the first version of this new object is temporarily set to SUSPECT, as it has not closed yet. Once the object is created, it is linked to its parent, preferably by adding its GUID to the CHILDREN property of its parent's latest version. This also occurs in step 1077. Thereafter, the parent object is closed and the new child handle remain open; this handle is passed over to the host driver, which can issue more updates to the new child. This is step 1079. If any failures occur during the above-described steps of the process, the transaction is rolled back at step 1081 and the host driver is notified; the host driver then performs a resynchronization on that object at step 1084. The host driver keeps the child handle in an open handle list at step 1083. If the new object is a file object, the host driver forwards data (via a MODIFY event) to the DMS file object handle and then closes the file handle to generate a consistent (State=CONSISTENT) version. At this point, the new object state is SUSPECT not CONSISTENT.
In the data distribution scenario, a master DMS data source object is forwarding events and a data stream to a target DMS replicated data source object. The process described in the flowchart of
Modification of a File or a Directory
A file or a directory modification in the DMS object store preferably is represented by the creation of a new object version. The modification of a file system object preferably is broken into three phases, and each phase involves a set of events. The three phases of active object modification cycle are (1) instantiating an active object, (2) modifying the object properties, and (3) freezing the version.
As noted above, phase 1 is instantiation of the target active object, which can either be a CREATE (as in
Phase 2 is the actual modification of the target object, which occurs either in block 1225 or in block 1209. The events that modify object properties preferably include MODIFY (metadata) and WRITE (binary data). There may be many more modification events depending on the application and system to which the DMS is applied. The test at step 1208 determines which event has occurred. A MODIFY event changes file system object metadata (such as access control list (ACL), object title, company name, document statistics and other user defined properties) that is associated with a file system object. The flow sub-diagram at block 1225 describes the process to modify object metadata. In particular, in response to capture of the modification event (steps 1207 and 1208), at step 1226 the host driver issues an object MODIFY event to the target active object (via the opened object handle) at the DMS, which target object then changes the object property in the latest object version at step 1227.
The WRITE event is for file object only; it represents binary content updates. In this path, when host driver captures the WRITE event (steps 1207 1208), it enters the processing block 1209 in the file modification process. Host driver first decides if it should buffer the changes. This is step 1210. For a database log file, for example, the host driver would not buffer the log entries; however, when dealing with a regular document changes are buffered. If changes are buffered, then the host driver decides if it is time to forward the changes to the DMS target active file object. This is step 1211. If no data should be forwarded at the meantime, the host driver continues to watch for events at step 1207. Otherwise, the host driver decides if delta reduction should be applied on the changes to extract the actual changed byte range. This is step 1212. Again, for database log entries, delta reduction is not necessary because log entries are appended onto the file. If no delta reduction is necessary, the changed data is packaged with a WRITE event and forwarded to the DMS target active object. This is step 1213. Otherwise, the host driver retrieves the last binary content signatures and, for one or more byte ranges that actually changed (deltas), the host driver calculates and forwards those deltas to the DMS target object. This is done using a host driver-generated (namely, APPLYDELTA) event and occurs at step 1214. The target DMS file object receives both WRITE and APPLYDELTA events, applies second stage delta reduction as necessary to extract the exact bytes changed, saves the deltas or binary data in the binary or delta pages, and then creates or updates the sparse index in the working (last) object version. This is step 1215. If the file has not been closed, the host driver continues to capture more modification events for the file at step 1207; otherwise, the closing process continues, which is step 1222. If any failure occurs, the host driver abandons all the events associated with the target file and performs resynchronization of the entire object at step 1230. In the preferred embodiment, the host driver uses a FLUSH event as one of the events to decide if buffered data should be forwarded to the DMS without causing the DMS target object to generate new version.
Phase 3 freezes the changes into an object version. This is block 1221. The possible events that cause a DMS target file or directory active object to freeze the latest object version (and thus to prevent any more changes into that version) are CLOSE, CHECKPOINT, and FORCE-CLOSE. The flow diagram in block 1221 illustrates the processing of handling of these events to freeze a DMS active file or directory object version. A CLOSE is a file system event. When this event is detected by the host driver, the associated file is consistent. A CHECKPOINT may be generated by an application with or without user initiative, or it may be generated by the host driver. A CHECKPOINT event is generated when the associated application or the host driver have taken some appropriate action to ensure that the version to be frozen is consistent in its application point of view. For example, a database manager periodically flushes its memory and generates an internal CHECKPOINT, during which a set of database files are consistent. The CHECKPOINT event from a database manager can be detected by the host driver, which indicates that the group of files belonging to the particular database is consistent and a DMS version of each of the files should be frozen. In yet another example, an application or the host driver may generate a CHECKPOINT to all the system state files (or even the entire file system) to create a snapshot of all the files all at once (an exact time). This CHECKPOINT forces all the related files to freeze their latest version all at once. If a CLOSE or CHECKPOINT event is detected by the host driver at step 1208, the host driver checks if there is any buffered data for that object. This is step 1220. If so, the host driver first forces the data to be forwarded to the target DMS object. After that, the host driver forwards the event to the DMS target object. This is step 1222. Both CLOSE and CHECKPOINT events generate a consistent DMS object version with the State property of the frozen version set to "Consistent." This is step 1223.
As noted above, another event that freezes a file or a directory object is FORCE-CLOSE. This event may be generated by an application or the host driver itself (step 1207), or it can be generated by the DMS (step 1225) when an error is encountered. The error could be that the host driver connection to the DMS has failed. The FORCE-CLOSE event generated by an application or host driver goes through the same process as the CLOSE and CHECKPOINT events (steps 1220, 1209, 1222, and 1223). FORCE-CLOSE freeze the latest version, as it is in Suspect state (i.e., the consistency is unknown). This is step 1223. Any DMS object that ends with Suspect state is eventually resynchronized with its corresponding file system object in the host, which is step 1230.
In one embodiment, the DMS data source object automatically creates a new object version when it handles a CREATE or OPEN event. In this case, step 1223 involves freeing an unmodified object version. An alternate embodiment forces the DMS data source object to create a new object version when it receives the first modification event.
The above described process with respect to the given events is merely illustrative. Other events and/or other handling techniques may be implemented. Thus, e.g., an alternative embodiment may choose to freeze file system objects more frequently (by using events such as FLUSH or possibly the WRITE events with TIMEOUT in step 1221). Another embodiment includes other application and host driver generated events, such as AUTO-SAVE. Also, with alternate embodiments, the process may be somewhat different than as illustrated in
In the data distribution scenario as noted above, a master DMS data source object is forwarding events and a data stream to a target DMS replicated data source object. The process described in
In particular,
Deletion of a File or a Directory
In a data distribution scenario, as described above a master DMS data source object forwards events and the data stream to a target DMS replicated data source object. The process described
In the "fo1" file object, the DateTimeTerminated property in the anchor page (not shown) is set to T4 to indicate that the object does not exist beyond T4. The latest version of "fo1," which is version 2 (object 942) is ended by its DateTimeEnded property set to T4. As can be seen, preferably the object "fo1" does not get removed physically from the DMS object store when it is deleted. Instead, its history terminates at T4. Preferably, the DMS object store keeps growing its history until a user explicitly prunes the history, either manually or via retention policy, during which older versions of the active objects get dropped off at the tail end.
Relocating or renaming a File or a Directory
In this section, renaming a file system object refers to changing the name of the object without moving it away from its directory. While relocating a file system object refers to moving an object from one directory to another different directory, the name of the object may also change during relocation. Relocation is a superset of renaming; one can relocate from within the same directory for changing an object's name path. In either case, the destination name either of the rename or relocate operation may already exist and be used by another object, in which case the original destination object is deleted and the target object to be renamed or relocated takes over the destination name.
In some file systems, a MOVE event is used for both renaming a file system object (file or directory) as well as relocating (moving) a file system object from one directory to another. In other file systems, a RENAME event may be used for both renaming and relocating of a file system object. There are also file systems where a MOVE event is used for relocating file system objects while a RENAME event is used for re-labeling (renaming) file system objects. In one embodiment of this invention, both MOVE and RENAME events are treated the same, in other words, both events initiate renaming and relocating of file system objects.
As described previously, in the data distribution scenario the host driver in the process flow is replaced by a master DMS file system data source, and the DMS file system data source is a replication data source. Otherwise, the process flow in
In the versioned by object path model of
The DMS may also include a temporary file handling process to minimize storage and bandwidth usage, e.g., by not transferring and storing potentially useless temporary files in the file system history. For example, Microsoft Word creates a temporary file when a Word document is modified. The updates are entered into a temporary file; upon a save event, the temporary file is renamed to the original file name. In this case, preferably creation and/or modification of the temporary file may be avoided; thus, preferably, only when the RENAME occurs are the above relocation process applied and object history linked together by pathname.
The above algorithm implements relocation of a file object; relocation of a directory object is more complex, as a directory may have children. Similar to relocating a file, the history management of relocation of a directory can also be based on model 1 (versioned by object instance) or model 2 (versioned by path). Also, one may connect the relocated object with a dead historical object while versioned by path or without connecting the relocated object with the historical object.
As can be seen, the versioned by object path model has relatively high processing and storage cost when relocating a directory, although it is much simpler to traverse. The alternative is to have a versioned by object path and versioned by object instance hybrid as shown in
Point-in-time Recovery with Guaranteed File System Structure Consistency and Integrity
The following section provides additional details regarding how to generate a point-in-time snapshot or recovery with guaranteed file system structure consistency and file content integrity.
As described above, the DMS continuous real-time object store captures all real-time activities, with associated object metadata information. Thus, the DMS is capable of reintroducing any point-in-time view of data ranging from a granular object to the entire file system. It is also capable of producing application consistent data because consistent events are captured and stored.
The algorithms described above for generating and maintaining a file system history in the DMS always ensure that the latest version of a directory always refers to the latest version of its children until the directory changed. This means that the DateTimeEnded of a parent version can only be the same or prior to the DateTimeEnded of its children, namely:
DateTimeEnded (a version of a parent)=<DateTimeEnded (the reference version of its child)
In example 1110, version 1 (1111) of the Parent is referring (by the CHILDREN property) to version 1 of Child (1114) until the Parent changes, which may be an addition of a new child. The new version (i.e. version 2, 1112) of the Parent continues to refer to version 1 (1114) of the Child until the Child changed, which changed the Parent's CHILDREN property to refer to version 2 of the child (1115). So, before time T1 (1150), version 2 (1112) of Parent refers to version 1 (1114) of Child 1, and after T1 (1150), version 2 (1112) of Parent refers to version 2 (1115) of Child. At T3 (1154), the Parent changed again, so version 3 (1113) of Parent is created and continues to refer to the latest Child 1, which is version 2 (1115). As one can see, at the end of Parent version 1 (1111), the CHILDREN property of the parent refers to Version 1 of Child 1. The DateTimeEnded of 1111 is prior to that of 1114. The DateTimeEnded of 1113 and 1115 are NULL simply because these versions are either in the process of being modified (in memory, or state is Suspect), or they are already modified successfully (even though the version has not be changed and the content is still valid at the current time).
In example 1120, Child 1 is modified three times (1125, 1126, and 1127) during the version 2 (1122) lifetime of Parent. Again, at the end of each version of the parent, the DateTimeEnded of the Parent is before the DateTimeEnded of Child 1.
Example 1130 shows versions of two children corresponding to the Parent. Suppose one wants to reconstruct the snapshot view of the file system at T1. At time T1, the correct version of the Parent is version 2 (1132); this is because the T1 is within range of DateTimeModified and DateTimeEnded of 1132 of Parent. If one would to navigate down from Parent to Child 1 using the most current data structure, 1132 (version 2) is referring to version 3 (1136) of Child 1. Because version 3 (1136) of Child 1 has a DateTimeModified that is much later then T, one must traverse back the history to locate the T1 point-in-time version of Child 1. By referring back to the previous version, version 2 (1135) can be located, and that T1 in this case, is within the time range of this version. Same for Child 2, the version of Child 2 connected to 1132 is version 2 (1138), one must traverse backward to locate an older version that covers T1, that older version would be version 1 (1137).
While traversing a DMS file system history to generate a point-in-time snapshot of a file system for recovery (the algorithm is discussed below), one should consider the consistency of the recovered data in the application point of view. There are file systems that contain only files that are individual owned by different applications; these files have nothing to do with one another and at any moment in time some of them are partially modified. The only time this type of file is guaranteed to have integrity is when the files are flushed and closed. There are also file systems that are used by applications that own a group of files; the only time that these files are consistent is when the applications generate a checkpoint or when the applications are shutdown. There are also files that are opened for update most of the time and rarely closed. There are yet some applications that can handle any partial update, in which case, a snapshot data of an exact point-in-time may be desired during recovery.
The current invention provides three different types of recovery consistency and integrity characteristic for different application needs. File object state is a key for determining recovery consistency.
In one embodiment of the current invention, there are two major states—Suspect or Consistent. The state of a version of a file object is Suspect when the version is still being worked on (in process, being modified), in which case, the object is opened, or when the version is closed (modification completed) but a version is not generated and therefore the consistency of the file is in question. Consistent state is when a file object version is completed, and that the version is generated as a result of a CHECKPOINT or CLOSE. In an alternate embodiment, there may be more then two states with object version generated by CHECKPOINT and CLOSE being recognized as two different states. In each version, content changes to all the files are entered in chunks or in the form of a delta string preserving the write order and tracked with sequence numbers. The host driver knows the application behavior and decides if the changes to a file must be sent immediately, or if it is fine to accumulate the changes for delta reduction. For example, preferably a database page should be accumulated and sent in full, not partial.
For data recovery, the current invention is capable of re-constructing a snapshot of any point-in-time in the past with any of three possible recovery consistency characteristics—1) strong individual file integrity, 2) exact point-in-time crash consistency, and 3) last version of all files. Strong individual file integrity recovery (
These innovative ways of recovery are useful for all types of applications that use a file system as storage media; the existing conventional solutions are not capable of providing this varied type of recovery characteristic all at once.
One can begin traversing a data source by starting the process at 1301 with root set to a specific DMS file system data source (FSDS), and both pit and option set accordingly. The first step the process does it to get all the children from the current root (1303). If one would to begin from the FSDS, the list of children retrieved are the most recent version, so if pit is not NULL, it must be prior to the DateTimeEnded timestamp of the children. Note that DateTimeEnded of the children may be NULL, it which case, it just means that the DateTimeEnded is sometime in the future (not ended yet). Starting from 1305, the process iterates all the children in the list (of this current root). When all the children are visited, the process ended for this root (1307). At step 1309, the process open up the object, which includes opening of the anchor and the version page that is referred to by the current root, and BT is set to DateTimeModified, ET is set to DateTimeEnded of the current version of the opened child object. Step 1311 is for version time check, if the requested traversal time (pit) is for a specific point-in-time in the past (i.e., pit !=NULL), and that pit falls in a older version of this object (pit<BT), then the process opens the previous version of this current child (1313). At 1313, if there is no previous version, then the object does not exist at the requested point-in-time, the process move on to the next child (1331), otherwise, the process move back to 1311 to perform time check again. If requested traversal time is current (i.e. pit=NULL) or pit falls within the current opened version, then the process moves on to 1315. At 1315, object type is check. If the object is a directory, then the entire 1300 process is used to traverse the child directory, with the root set to this directory (1317), 1300 is a recursive process until the entire FSDS is traversed. When a child directory is completely traversed, the processing thread of traversing the child directory ends at 1307, and returns to 1317 of the parent's thread, and the process at the parent's thread moves on to the next child 1331. If the current child is a file object, and the traversal time is current (pit=NULL), 1319 branched to 1321 to "visit" the current file content. If the traversal time is set to a point-in-time in the past, then the traversal process checks the traversal options 1323. If option "a" is requested, the content at the exact pit is desired, in which case, the version prior to the current opened version is opened, changes from the prior version up to the desire pit is applied, and that would be the content "visited". If there is no prior version, then there would be no content to be visited (ie. file result=NULL), 1325. If option "b" is requested, then a completed version prior to pit is desired. If the current version is not ended, the process moves backward to an older version, the content of a full version is "visited", and if there is no full version, the visited content would be NULL, 1327. If option "c" is requested, then a full completed version that is consistent is requested. If current version is not ended, the process moves backward to an older version that is consistent (i.e. state=CONSISTENT) to visit its content, 1329. The process may move back several older versions to locate a consistent one. If no consistent version is found, then the file is considered to be none existing for the pit (file result is NULL) 1329.
While the present invention has been described in the context of a method or process, the present invention also relates to apparatus for performing the operations herein. In an illustrated embodiment, the apparatus is implemented as a processor and associated program code that implements a finite state machine with a plurality of states and to effect transitions between the states. As described above, this apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
While the above written description also describes a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary, as alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, or the like. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic.
Having described my invention, what I now claim is as follows.
|Cited Patent
|Filing date
|Publication date
|Oct 21, 1964
|Jan 12, 1971
|Bell Telephone Labor Inc
|Data character assembler
|Oct 5, 1967
|Jan 12, 1971
|Rca Corp
|Multiplex synchronizing circuit
|Jan 12, 1968
|Jan 12, 1971
|Electronic sweep magnetic scanning transducer
|Dec 6, 1967
|Jan 12, 1971
|Honeywell Inc
|Optimizing system for a plurality of temperature conditioning apparatuses
|Nov 13, 1970
|Mar 7, 1972
|Digital video display system using cathode-ray tube
|Jan 30, 1978
|Jul 24, 1979
|Gould Inc., Modicon Div.
|Digital input/output system and method
|Dec 15, 1980
|Aug 30, 1983
|U.S. Philips Corporation
|Multi-processor computer system
|Nov 12, 1981
|Nov 15, 1983
|Obo Bettermann Ohg
|Electrical stud welding device for welding studs of different diameters without pre-testing adjusting welds
|Oct 17, 1980
|May 22, 1984
|Northern Telecom Limited
|Digital signal subscriber loop and interface circuit
|Aug 30, 1982
|May 29, 1984
|Skidmore Donald D
|Data-terminal service outlet
|Oct 22, 1981
|Jun 19, 1984
|Schoenhuber Max J
|System for recording data relating to specific lots of materials, particularly to milk lots
|Dec 18, 1978
|Feb 26, 1985
|Burroughs Corporation
|Spiral recording and associated system
|Sep 13, 1982
|Apr 16, 1985
|U.S. Philips Corporation
|Data processing device for processing multiple-symbol data-words based on a symbol-correcting code and having multiple operating modes
|Mar 30, 1987
|Jan 3, 1989
|Scs Telecom, Inc.
|Schilling-Manela forward error correction and detection code method and apparatus
|Jul 15, 1988
|Nov 21, 1989
|Bbc Brown Boveri Ag
|Signal transmission method
|May 12, 1988
|Apr 10, 1990
|Radar Control Systems Corporation
|Radar system for headway control of a vehicle
|May 1, 1989
|Nov 20, 1990
|Cylink Corporation
|Integer encryptor
|Nov 30, 1989
|Apr 2, 1991
|Communications Test Design, Inc.
|Method and apparatus as for testing a telephone line interface card
|Mar 20, 1991
|Sep 15, 1992
|International Business Machines Corp.
|Authentication protocols in communication networks
|Oct 19, 1990
|Jan 5, 1993
|International Business Machines Corporation
|Image data processing of correlated images
|May 1, 1989
|Jun 29, 1993
|Motorola, Inc.
|Asynchronous operation in a database management system
|Mar 9, 1990
|Dec 28, 1993
|Hewlett-Packard Company
|Tape storage device for storing audio data in the amble frames of a DDS format tape
|Nov 5, 1990
|Jan 18, 1994
|Deutsche Itt Industries Gmbh
|Two-way data transfer apparatus
|Dec 31, 1991
|Feb 15, 1994
|Silicon Graphics, Inc.
|File alteration monitor for computer operating and file management system
|Apr 12, 1991
|Apr 12, 1994
|Radio Satellite Corporation
|Integrated radio satellite response system and method
|Mar 6, 1992
|Apr 19, 1994
|Data General Corporation
|High availability disk arrays
|Feb 1, 1993
|May 10, 1994
|Trimble Navigation Limited
|Event-activated reporting of vehicle location
|Apr 28, 1993
|Jun 7, 1994
|International Business Machines Corporation
|Pixel depth converter for a computer video display
|Mar 12, 1992
|Jun 14, 1994
|Kabushiki Kaisha Toshiba
|Electrically erasable and programmable non-volatile memory system with write-verify controller using two reference levels
|Nov 9, 1992
|Nov 8, 1994
|Motorola, Inc.
|Mobile ISDN radio system
|Aug 16, 1991
|Nov 15, 1994
|Pinpoint Communications, Inc.
|Communication system and method for determining the location of a transponder unit
|Mar 25, 1993
|Dec 13, 1994
|Hewlett-Packard Company
|Method and an apparatus for limited variable speed scanning
|Mar 3, 1993
|Dec 27, 1994
|Nishiishigaki; Kenji
|Apparatus for preparing map data with regional properties
|May 24, 1993
|Jan 17, 1995
|Fuji Photo Film Co., Ltd.
|Photographic-film product
|Apr 19, 1994
|Jan 31, 1995
|Kabushiki Kaisha Toshiba
|Electrically erasable and programmable non-volatile memory system with write-verify controller using two reference levels
|Feb 14, 1994
|Feb 7, 1995
|Thermo King Corporation
|Communications adapter for converting wire-based communication to wireless communication
|Dec 17, 1992
|Feb 7, 1995
|Vlsi Technology, Inc.
|FIFO memory using single output register
|Dec 18, 1992
|Feb 21, 1995
|Abbott Laboratories
|Method and apparatus for providing a data interface between a plurality of test information sources and a database
|Oct 15, 1992
|Mar 7, 1995
|International Computers Limited
|Apparatus and method for interfacing between processing computers in a computer system
|Apr 15, 1993
|May 16, 1995
|Bellsouth Corporation
|System for communicating with an ADSI-compatible telephone via a service circuit node
|Aug 31, 1993
|Jun 13, 1995
|Victor Company Of Japan, Ltd.
|Orthogonal transform coding apparatus and decoding apparatus
|Aug 22, 1994
|Jul 4, 1995
|Motorola, Inc.
|Adaptive weight adjusting circuit for an neural network
|Dec 22, 1993
|Aug 8, 1995
|International Business Machines Corporation
|Selecting a data unit candidate to be demoted to a backing store from a front store based upon thresholds individual to each of the data candidates
|Nov 16, 1994
|Nov 21, 1995
|Kabushiki Kaisha Toshiba
|Electrically erasable and programmable non-volatile memory system with write-verify controller using two reference levels
|Mar 23, 1994
|Dec 19, 1995
|Mitsubishi Denki Kabushiki Kaisha
|Memory device to detect and compensate for defective memory cells
|Mar 30, 1993
|Dec 26, 1995
|Squibb Data Systems, Inc.
|Apparatus and method for reconstructing a file from a difference signature and an original file
|Sep 22, 1994
|Jan 2, 1996
|Kabushiki Kaisha Toshiba
|Optical disk apparatus for recording/erasing information in the M-CAV format by using gain switching to increase the speed of the master clock
|Apr 14, 1995
|Mar 19, 1996
|Thermo King Corporation
|Methods and apparatus for converting a manually operable refrigeration unit to remote operation
|Mar 2, 1995
|Mar 26, 1996
|Victor Company Of Japan, Ltd.
|Orthogonal transform coding apparatus and decoding apparatus
|May 1, 1995
|Apr 9, 1996
|Mitsubishi Denki Kabushiki Kaisha
|Microcomputer incorporating communication device
|May 16, 1994
|Apr 9, 1996
|Allegro Microsystems, Inc.
|FM data-system radio receiver
|Aug 6, 1993
|Apr 23, 1996
|Rockoff; Todd E.
|Multi-clock SIMD computer and instruction-cache-enhancement thereof
|Jul 18, 1994
|Jun 11, 1996
|Pinpoint Communications, Inc.
|Communication system and method for determining the location of a transponder unit
|Jan 30, 1995
|Jul 23, 1996
|Brother Kogyo Kabushiki Kaisha
|Sewing data modifying apparatus
|Aug 29, 1994
|Sep 24, 1996
|Lucent Technologies Inc.
|System for providing automatic power control for highly available n+k processors
|Oct 19, 1995
|Oct 1, 1996
|Ando Electric Co., Ltd.
|Self-diagnostic device for semiconductor memories
|Jan 24, 1994
|Dec 10, 1996
|Matsushita Electric Industrial Co., Ltd.
|Image generating apparatus and method of generating an image by parallel processing thread segments
|Apr 1, 1994
|Feb 11, 1997
|Boulware; Jim L.
|Apparatus for accurately determining a moving ball's position and speed
|May 10, 1995
|Feb 25, 1997
|Mci Communications Corporation
|Centralizing storage and verification element for telephone network
|May 6, 1996
|Jun 17, 1997
|International Business Machines Corporation
|Quantization method for image data compression employing context modeling algorithm
|Jun 28, 1995
|Jul 1, 1997
|Sybase, Inc.
|Database system with improved methods for B-tree maintenance
|Mar 6, 1996
|Jul 22, 1997
|Trw Inc.
|Modular high-capacity solid-state mass data storage device for video servers including a switch for simultaneous multi-viewer access
|May 8, 1995
|Aug 12, 1997
|Protocol Systems, Inc.
|High-quality, low-bit-rate method of compressing waveform data
|Jan 24, 1996
|Oct 14, 1997
|Seagate Technology, Inc.
|Network management system having historical virtual catalog snapshots for overview of historical changes to files distributively stored across network domain
|Dec 8, 1995
|Nov 4, 1997
|Victor Company Of Japan, Ltd.
|Orthogonal transform coding apparatus and decoding apparatus
|Nov 14, 1995
|Nov 4, 1997
|Western Atlas International, Inc.
|Method for bit-stream data compression
|Oct 8, 1996
|Nov 4, 1997
|Kabushiki Kaisha Toshiba
|Optical disk apparatus
|Jan 11, 1996
|Mar 3, 1998
|Western Atlas International, Inc.
|Distributed seismic data-gathering system
|Nov 30, 1995
|Mar 17, 1998
|Deltatech Research, Inc.
|Computer apparatus and method for merging system deltas
|Jul 13, 1995
|Apr 7, 1998
|Mci Communications Corporation
|Network information architecture having centralizing storage and verification element
|Apr 11, 1995
|Apr 21, 1998
|Trimble Navigation Limited
|Personal tracking system integrated with base station
|Dec 13, 1995
|Apr 21, 1998
|Caterpillar Inc.
|Position referenced data for monitoring and controlling
|Mar 26, 1996
|May 19, 1998
|Unisys Corporation
|Transaction service independent HTTP server-to-transaction gateway
|Feb 6, 1996
|Jun 9, 1998
|Golden Bridge Technology, Inc.
|Intelligent power management for a programmable matched filter
|May 2, 1996
|Jun 16, 1998
|Northern Telecom Limited
|Method of simulating AC timing characteristics of integrated circuits
|Aug 25, 1995
|Jul 7, 1998
|Emerson; Mark L.
|Data village system
|Mar 10, 1995
|Jul 14, 1998
|Northern Telecom Limited
|Radio terminal interfaces for voice and data telecommunications, and methods for their operation
|Aug 27, 1996
|Jul 21, 1998
|Transsky Corp.
|Wideband code-division-multiple access system and method
|Dec 16, 1996
|Aug 11, 1998
|Tandem Computers, Inc.
|Remote duplicate database facility featuring safe master audit trail (safeMAT) checkpointing
|Apr 15, 1997
|Sep 8, 1998
|Time Warner Entertainment Co. L.P. Time Warner Cable
|Virtual assets in an interactive television cable system
|Dec 6, 1996
|Sep 22, 1998
|International Business Machines Corporation
|Data management system and method for concurrent engineering
|Oct 16, 1995
|Oct 6, 1998
|Network Specialists, Inc.
|Real time backup system
|Feb 28, 1997
|Oct 13, 1998
|Sybase, Inc.
|Database system with methods for improving query performance with cache optimization strategies
|Dec 6, 1996
|Oct 20, 1998
|International Business Machines Corporation
|Data management system having shared libraries
|Jun 3, 1997
|Nov 3, 1998
|Kabushiki Kaisha Toshiba
|Electrically erasable programmable read-only memory with threshold value controller for data programming and method of programming the same
|May 15, 1997
|Nov 24, 1998
|Fujitsu Limited
|Semiconductor memory device facilitating use of a high frequency clock signal
|Jul 3, 1996
|Nov 24, 1998
|Northern Telecom Limited
|Telecommunications switch apparatus and method for time switching
|Aug 10, 1995
|Dec 8, 1998
|Motorola, Inc.
|Method of and apparatus for communicating messages
|Apr 21, 1995
|Dec 29, 1998
|Mci Communications Corporation
|Network information concentrator
|May 30, 1996
|Jan 19, 1999
|Northern Telecom Limited
|Telecommunications apparatus and method
|Dec 6, 1996
|Jan 26, 1999
|International Business Machines Corporation
|Data management system for problems, releases and parts
|Dec 11, 1997
|Mar 2, 1999
|Klink; James
|Medical identification bracelet
|Dec 6, 1996
|Mar 2, 1999
|International Business Machines Corporation
|Data management system and process
|Jul 22, 1997
|Apr 6, 1999
|Deltatech Research, Inc.
|Computer apparatus and method for merging system deltas
|Oct 29, 1997
|Apr 13, 1999
|Golden Bridge Technology, Inc.
|Parallel correlator architecture for synchronizing direct sequence spread-spectrum signals
|Feb 12, 1998
|Jun 1, 1999
|Transsky Corp.
|Wideband code-division multiple access system and method
|Mar 11, 1996
|Jun 29, 1999
|Aprex Corporation
|Contactless communication system
|Dec 30, 1996
|Jun 29, 1999
|Northern Telecom Limited
|Shared memory control algorithm for mutual exclusion and rollback
|Dec 6, 1996
|Jul 6, 1999
|International Business Machines Corporation
|Data management system having data management configuration
|Dec 6, 1996
|Jul 6, 1999
|International Business Machines Corporation
|Data management control system for file and database
|Aug 8, 1996
|Jul 27, 1999
|Wang; Pong-Sheng
|System and process for delivering digital data on demand
|Sep 15, 1995
|Jul 27, 1999
|Accumed International, Inc.
|System for simplifying the implementation of specified functions
|Sep 24, 1996
|Jul 27, 1999
|Rco Software Limited
|Computer aided risk management in multiple-parameter physical systems
|May 7, 1997
|Aug 3, 1999
|3Com Corporaton
|System for ISDN terminal adapter DCE for automatically negotiating data compression with it's PPP peer when DTE is unable or unwilling to negotiate compression
|May 30, 1997
|Aug 10, 1999
|Bellsouth Corporation
|Routing information within an adaptive routing architecture of an information retrieval system
|Nov 10, 1997
|Aug 17, 1999
|International Business Machines Corporation
|System for the distribution and storage of electronic mail information
|Dec 6, 1996
|Sep 7, 1999
|International Business Machines Corporation
|Computerized design automation method using a single logical PFVL paradigm
|Dec 23, 1997
|Sep 14, 1999
|Microsoft Corporation
|Using sparse file technology to stage data that will then be stored in remote storage
|Mar 20, 1997
|Sep 28, 1999
|Firstsense Software, Inc.
|Systems and methods for monitoring distributed applications including an interface running in an operating system kernel
|Dec 2, 1997
|Oct 12, 1999
|International Business Machines Corporation
|Method for managing a plurality of data processes residing in heterogeneous data repositories
|Oct 2, 1998
|Oct 26, 1999
|Network Specialists, Inc.
|Real time backup system
|Jan 17, 1995
|Nov 9, 1999
|Intertech Ventures, Ltd.
|Computer-based system, methods and graphical interface for information storage, modeling and stimulation of complex systems
|Jun 4, 1998
|Dec 7, 1999
|Golden Bridge Technology, Inc.
|Intelligent power management for a programmable matched filter
|May 7, 1997
|Dec 21, 1999
|3Com Corporation
|Apparatus for an improved ISDN terminal adapter having automatic SPID configuration and methods for use therein
|Dec 9, 1998
|Dec 21, 1999
|Bellsouth Intellectual Property Corp.
|Using a routing architecture to route information between an orignation module and a destination module in an information retrieval system
|May 7, 1997
|Feb 29, 2000
|3Com Corporation
|Apparatus for an improved ISDN terminal adapter having baud rate unblocking and methods for use therein
|Dec 6, 1996
|Mar 7, 2000
|International Business Machines Machine
|Data management system for concurrent engineering
|Jun 27, 1996
|Apr 4, 2000
|Hewlett-Packard Company
|Creation and migration of distributed streams in clusters of networked computers
|Mar 4, 1998
|May 16, 2000
|International Business Machines Corporation
|Synchronizing recovery log having time stamp to a remote site for disaster recovery of a primary database having related hierarchial and relational databases
|Nov 18, 1997
|Jun 6, 2000
|Fujitsu Limited
|Charged-particle-beam exposure device and method capable of high-speed data reading
|Dec 6, 1996
|Jul 11, 2000
|International Business Machines Corporation
|Data management system for file and database management
|Jun 24, 1998
|Jul 25, 2000
|International Business Machines Corporation
|Data management system for file and database management
|Mar 4, 1997
|Aug 22, 2000
|Ericsson Inc
|System and method for data link synchronization
|Sep 17, 1998
|Aug 22, 2000
|Nynex Science And Technology Inc.
|Methods and apparatus for automating the detection, reporting and correction of operator input errors
|Sep 1, 1994
|Nov 28, 2000
|International Business Machines Corporation
|Method and system for performing resource updates and recovering operational records within a fault-tolerant transaction-oriented data processing system
|Nov 14, 1997
|Dec 5, 2000
|Delta-Tek Research, Inc.
|System and apparatus for merging a write event journal and an original storage to produce an updated storage using an event map
|May 29, 1998
|Dec 19, 2000
|Sun Microsystems, Inc.
|Method and apparatus for file system disaster recovery
|Dec 10, 1998
|Jan 23, 2001
|Seiko Epson Corporation
|Semiconductor memory device, semiconductor device, and electronic apparatus using the semiconductor device
|Sep 15, 1999
|Jan 30, 2001
|Nec Corporation
|Semiconductor memory device having circuit for controlling data-output timing
|Jun 12, 1998
|Feb 13, 2001
|Microsoft Corporation
|Journaling ordered changes in a storage volume
|Jun 3, 1998
|May 22, 2001
|Fujitsu Limited
|Semiconductor memory device having scan flip-flops
|Jun 4, 1999
|Jun 5, 2001
|Massachusetts Institute Of Technology
|Very-high-density memory device utilizing a scintillating data-storage medium
|Dec 12, 1998
|Jun 19, 2001
|Joseph Reid Henrichs
|Magnetic data storage fixed hard disk drive using stationary microhead array chips in place of flying-heads and rotary voice-coil actuators
|Dec 31, 1998
|Apr 2, 2002
|Computer Associates Think, Inc.
|Method and apparatus for the dynamic filtering and routing of events
|Jul 17, 1998
|Apr 2, 2002
|Storactive, Inc.
|Systems and methods for electronic data storage management
|May 28, 1999
|May 14, 2002
|Redleaf Group, Inc.
|File system performance enhancement
|Dec 10, 1998
|May 21, 2002
|Compaq Computer Corporation
|Error self-checking and recovery using lock-step processor pair architecture
|Oct 26, 1998
|May 28, 2002
|Vmware, Inc.
|Virtualization system including a virtual machine monitor for a computer with a segmented architecture
|Dec 31, 1998
|Sep 3, 2002
|Computer Associates Think, Inc.
|System and method for dynamic correlation of events
|Dec 16, 1999
|Oct 1, 2002
|Livevault Corporation
|Systems and methods for backing up data files
|Jan 4, 2000
|Oct 8, 2002
|Netspeak Corporation
|Method for designing object-oriented table driven state machines
|Dec 31, 1998
|Nov 26, 2002
|Emc Corporation
|Apparatus and methods for copying, backing up, and restoring data using a backup segment size larger than the storage block size
|May 24, 1999
|Nov 26, 2002
|Hewlett-Packard Company
|Apparatus and method for a multi-client event server
|Oct 6, 1999
|Dec 17, 2002
|International Business Machines Corporation
|Method for database assisted file system restore
|Mar 25, 1999
|Dec 31, 2002
|Lucent Technologies Inc.
|Real-time event processing system with analysis engine using recovery information
|Aug 9, 2000
|Feb 11, 2003
|1Vision Software, Inc.
|Internet storage manipulation and navigation system
|Dec 16, 1999
|Feb 25, 2003
|Livevault Corporation
|Systems and methods for backing up data files
|May 15, 2000
|Apr 15, 2003
|Oracle Corporation
|Event notification system tied to a file system
|Aug 31, 1999
|Aug 26, 2003
|Accenture Llp
|System, method and article of manufacture for implementing a hybrid network
|Dec 16, 1999
|Sep 23, 2003
|Livevault Corporation
|Systems and methods for backing up data files
|Mar 2, 2000
|Sep 30, 2003
|Nec Corporation
|System and method of enabling file revision management of application software
|Oct 12, 1999
|Dec 30, 2003
|Gateway, Inc.
|Persistent usage context
|Feb 27, 2001
|Jun 15, 2004
|Sun Microsystems, Inc.
|Method, system, and program for monitoring system components
|Dec 16, 1999
|Aug 17, 2004
|Livevault Corporation
|Systems and methods for backing up data files
|Aug 28, 1998
|Aug 31, 2004
|Hewlett Packard Development Company, L.P.
|Data backup and recovery systems
|Jul 20, 1995
|Nov 9, 2004
|Timespring Software Corporation
|Apparatus and method for reconstructing a file from a difference signature and an original file
|Sep 26, 2000
|Nov 23, 2004
|Emc Corporation
|Data storage system and method for uninterrupted read-only access to a consistent dataset by one host processor concurrent with read-write access by another host processor
|Feb 13, 2001
|Nov 30, 2004
|Avamar Technologies, Inc.
|System and method for data protection with multidimensional parity
|Nov 13, 2000
|Dec 28, 2004
|Nortel Networks Limited
|Time simulation techniques to determine network availability
|Jan 12, 2001
|Jan 4, 2005
|Hewlett-Packard Development Company, L.P.
|Integration of a database into file management software for protecting, tracking, and retrieving data
|Dec 27, 2002
|Jan 4, 2005
|Veritas Operating Corporation
|System and method for performing virtual device I/O operations
|Dec 16, 1999
|Jan 25, 2005
|Livevault Corporation
|Systems and methods for backing up data files
|Oct 2, 2001
|Jun 14, 2005
|Ntt Docomo, Inc.
|Fault notification method and related provider facility
|Jan 15, 2002
|Jan 31, 2006
|International Business Machines Corporation
|Method, apparatus, and program for a state machine framework
|Jun 30, 2003
|Apr 11, 2006
|Veritas Operating Corporation
|System and method for performing virtual device I/O operations
|Apr 19, 2002
|May 2, 2006
|Network Appliance, Inc.
|System and method for checkpointing and restarting an asynchronous transfer of data between a source and destination snapshot
|Aug 30, 2004
|May 30, 2006
|Veritas Operating Corporation
|System and method for performing virtual device I/O operations
|May 30, 2001
|Jun 27, 2006
|Opentv, Inc.
|On-demand interactive magazine
|Apr 15, 2002
|Jul 18, 2006
|International Business Machines Corporation
|Multidimensional data clustering scheme for query processing and maintenance in relational databases
|Dec 31, 2001
|Aug 15, 2006
|Samsung Electronics Co., Ltd.
|Asynchronous transfer mode (ATM) based delay adaptive scheduling apparatus adaptive according to traffic types and method thereof
|May 7, 2004
|Aug 22, 2006
|Asempra Technologies, Inc.
|Method and system for automated, no downtime, real-time, continuous data protection
|Dec 10, 2002
|Apr 3, 2007
|L-3 Communications Corporation
|System and method for fast data encryption/decryption using time slot numbering
|Nov 17, 2000
|Apr 17, 2007
|Oracle International Corporation
|Asynchronous transcription object management system
|Jun 10, 2005
|Apr 24, 2007
|Brooks Automation, Inc.
|Wide-range combination vacuum gauge
|Oct 26, 2001
|Sep 18, 2007
|Intel Corporation
|Method and system for managing distributed content and related metadata
|Sep 8, 2000
|Oct 30, 2007
|Oracle International Corporation
|Monitoring latency of a network to manage termination of distributed transactions
|Feb 4, 2004
|Jan 29, 2008
|Network Appliance, Inc.
|Method and system for data recovery in a continuous data protection system
|Aug 21, 2006
|Apr 22, 2008
|Asempra Technologies, Inc.
|Method and system for automated, no downtime, real-time, continuous data protection
|Jun 8, 2004
|Apr 14, 2009
|Asempra Technologies, Inc.
|Method and system for no downtime, initial data upload for real-time, continuous data protection
|Jul 21, 2009
|Siew Yong Sim-Tang
|Method and system for real-time event journaling to provide enterprise data services
|Feb 15, 2001
|Oct 11, 2001
|Takako Miyazaki
|System and method for efficiently performing data transfer operations
|May 10, 2001
|Nov 22, 2001
|Soo-Han Park
|Compatible optical disk player and data recording and reproducing method
|Jan 4, 2001
|Feb 21, 2002
|Elliot Cooperstone
|Method and system for remotely managing business and employee administration functions
|Oct 3, 2001
|Jul 11, 2002
|Surgient Networks, Inc.
|Systems and methods for resource management in information storage environments
|Nov 29, 2000
|Aug 8, 2002
|Gobeille Robert C.
|Data structure and storage and retrieval method supporting ordinality based searching and data retrieval
|Jan 31, 2002
|Oct 3, 2002
|Kondo Thomas J.
|System recovery from errors for processor and associated components
|Dec 16, 1998
|Oct 10, 2002
|Domenico Raguseo
|Dynamic redirection
|Mar 29, 2001
|Nov 21, 2002
|International Business Machines Corporation
|Method and system for network management providing access to application bandwidth usage calculations
|Jan 29, 2002
|Nov 28, 2002
|Hitoshi Ueno
|System for managing layered network
|Jun 22, 2001
|Dec 26, 2002
|Garney John I.
|Method and apparatus for preservation of failure state in a read destructive memory
|Jun 29, 2001
|Jan 9, 2003
|International Business Machines Corporation
|Method and system for network management with topology system providing historical topological views
|Jan 19, 2001
|Mar 13, 2003
|Carter Ernst B.
|Network surveillance and security system
|Nov 2, 2001
|May 8, 2003
|Caulfield David D
|Array calibration and quality assurance
|Dec 7, 2001
|Jun 26, 2003
|Nokia Corporation
|Method and system for optimizing power consumption during data read/Write operation in disk-based memory
|Apr 12, 2002
|Oct 23, 2003
|Geipel Barry L.
|System and method for active configuration management
|Mar 5, 2003
|Oct 30, 2003
|Ori Software Development Ltd.
|Efficient traversals over hierarchical data and indexing semistructured data
|Jun 9, 2003
|Jan 15, 2004
|Slater Alastair Michael
|Method of satisfying a demand on a network for a network resource, method of sharing the demand for resources between a plurality of networked resource servers, server network, demand director server, networked data library, method of network resource management, method of satisfying a demand on an internet network for a network resource, tier of resource serving servers, network, demand director, metropolitan video serving network, computer readable memory device encoded with a data structure for managing networked resources, method of making available computer network resources to users of a
|Jun 12, 2003
|Feb 26, 2004
|Jordahl Jena J.
|Data storage, retrieval, manipulation and display tools enabling multiple hierarchical points of view
|Jun 9, 2003
|Mar 11, 2004
|Slater Alastair Michael
|Method of maintaining availability of requested network resources, method of data storage management, method of data storage management in a network, network of resource servers, network, resource management server, content management server, network of video servers, video server, software for controlling the distribution of network resources
|Jun 19, 2003
|Apr 29, 2004
|Pixion, Inc.
|Real-time, multi-point, multi-speed, multi-stream scalable computer network communications system
|Sep 15, 2003
|May 20, 2004
|Husain Syed Mohammad Amir
|Distributed computing infrastructure including multiple collaborative sessions
|Sep 15, 2003
|May 20, 2004
|Husain Syed Mohammad Amir
|System and method for creating complex distributed applications
|Sep 15, 2003
|May 20, 2004
|Husain Syed Mohammad Amir
|System and method for multi-functional XML-capable software applications on a peer-to-peer network
|Sep 15, 2003
|May 20, 2004
|Husain Syed Mohammad Amir
|System and method for reducing user-application interactions to archivable form
|Nov 24, 2003
|Jun 17, 2004
|Sang-Hyuck Ha
|Method and apparatus for controlling turbo decoder input
|Mar 27, 2003
|Sep 30, 2004
|Microsoft Corporation
|File system for displaying items of different types and from different physical locations
|Apr 2, 2003
|Oct 7, 2004
|Sun Microsystems, Inc.
|Distributed data system with incremental data updates
|May 20, 2004
|Dec 9, 2004
|Fish Edmund J.
|User interface for presence and geographic location notification based on group identity
|Jun 22, 2004
|Jan 6, 2005
|Nikon Corporation
|Electronic still camera and system and program for same
|Feb 27, 2004
|Jan 27, 2005
|Prasad Peddada
|System and method for communications between servers in a cluster
|Oct 7, 2003
|Apr 7, 2005
|International Business Machines Corporation
|Method, system, and program for retaining versions of files
|Jan 28, 2004
|Jul 28, 2005
|Vronay David P.
|System and method for ordering events
|May 10, 2004
|Nov 10, 2005
|Sim-Tang Siew Y
|Method and system for real-time event journaling to provide enterprise data services
|May 6, 2005
|Nov 24, 2005
|Sim-Tang Siew Y
|System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services
|Jun 24, 2005
|Dec 29, 2005
|Meshnetworks, Inc.
|System and method for adaptive rate selection for wireless networks
|Jul 12, 2005
|Jan 26, 2006
|Michel Prompt
|System and method for providing access to databases via directories and other hierarchical structures and interfaces
|Sep 30, 2005
|Feb 2, 2006
|Permabit, Inc.
|History preservation in a computer storage system
|Sep 8, 2004
|Mar 9, 2006
|Sony Corporation
|Method and apparatus for transmitting a coded video signal
|Sep 17, 2004
|Mar 23, 2006
|Sim-Tang Siew Y
|Method and system for data reduction
|Nov 1, 2005
|May 11, 2006
|Sim-Tang Siew Y
|Management interface for a system that provides automated, real-time, continuous data protection
|Sep 9, 2003
|Jun 15, 2006
|Sadahiro Hirayama
|Requirement defining method, method for developing software, and method for changing requirement word, and newly defining method
|Oct 28, 2005
|Jun 22, 2006
|Samsung Electronics Co., Ltd.
|Apparatus and method of generating and detecting prevention and control data for verifying validity of data
|Apr 14, 2005
|Oct 19, 2006
|Dell Products L.P.
|System and method for rebuilding a storage disk
|May 11, 2006
|Nov 16, 2006
|Swoboda Gary L
|High Speed Data Recording With Input Duty Cycle Distortion
|Jun 10, 2005
|Dec 14, 2006
|Helix Technology Corporation
|Wide-range combination vacuum gauge
|Sep 22, 2006
|Mar 22, 2007
|Gtess Corporation
|Data file correlation system and method
|Dec 13, 2006
|Apr 26, 2007
|Asempra Technologies, Inc.
|Method for managing real-time data history of a file system
|Nov 30, 2005
|Jul 19, 2007
|Microsoft Corporation
|Remote location failover server application
|Mar 10, 2006
|Sep 13, 2007
|Oracle International Corporation
|Detecting database events using recovery logs
|Jan 21, 2010
|Jun 10, 2010
|Siew Yong Sim-Tang
|Method Of Creating Hierarchical Indices For A Distributed Object System
|May 10, 1996
|Oct 13, 1998
|Trimble Navigation Limited
|Event-activated reporting of vehicle location
|Apr 6, 2000
|Jan 27, 2004
|Axs Technologies, Inc.
|Method and apparatus for a parallel data storage and processing server
|Abel-Jalil, Neveen, "International Search Report" for PCT/US05/32958 as mailed Jul. 8, 2008. (1 page).
|Beausoliel, Rob, "International Search Report" for PCT/US05/15651 as mailed Sep. 29, 2005. (1 page).
|Burton H. Bloom, Space/Time Trade-offs in Hash Coding with Allowable Errors, Communications of the ACM, vol. 13/No. 7/Jul. 1970, pp. 422-426.
|Housel et al. "WebExpress: A client/intercept based system for optimizing Web browsing in a wireless environment", Mobile Network and Applications, vol. 3, pp. 419-431, 1998, Baltzer Science Publishers.
|Microsoft Windows Storage Server 2003, NSI Software, "Improving Business Continuity Using Windows Storage Server 2003", White Paper, Oct. 2003, pp. 1-15.
|Psounis, "Class-based Delta-encoding: A Scalable Scheme for Caching Dynamic Web Content", Proceedings of the 22nd International Conference on Distributed Computing Systems Workshops, 2002 IEEE (pp. 1-7).
|Thomas Plagemann, Towards Middleware Services for Mobile Ad-Hoc Network Applications, May 2003,IEEE (FTDCS'03), pp. 1-7.
|Thomson, William, "International Search Report" for PCT/US05/39709 as mailed Oct. 16, 2007. (1 page).
|U.S. Appl. No. 10/862,971, Sim-Tang.
|U.S. Appl. No. 10/862,971.
|U.S. Appl. No. 11/185,168, Sim-Tang.
|U.S. Appl. No. 11/185,313, Siew Yong Sim-Tang.
|U.S. Appl. No. 12/099,837, Sim-Tang, Siew Yong.
|U.S. Appl. No. 12/488,657, Sim-Tang.
|U.S. Appl. No. 12/696,691, Sim-Tang.
|U.S. Appl. No. 12/845,215, Sim-Tang.
|U.S. Appl. No. 12/901,824, Siew Yong Sim-Tang.
|U.S. Appl. No. 12/901,888, Siew Yong Sim-Tang.
|Vo, Tim, "International Search Report" for PCT/US05/15662 as mailed Feb. 1, 2008. (2 pages).
|Zhen, Li B., "International Search Report" for PCT/US05/15653 as mailed Nov. 30, 2006. (3 pages).
|Citing Patent
|Filing date
|Publication date
|Jan 29, 2013
|Quest Software, Inc.
|Method and system for virtual on-demand recovery
|Feb 12, 2013
|Quest Software, Inc.
|Method and system for virtual on-demand recovery
|Sep 21, 2010
|Aug 6, 2013
|Amazon Technologies, Inc.
|System and method for logical deletion of stored data objects
|Dec 20, 2012
|Jan 28, 2014
|Dell Software Inc.
|Method and system for virtual on-demand recovery
|Dec 23, 2010
|Feb 11, 2014
|Amazon Technologies, Inc.
|System and method for fetching the latest versions of stored data objects
|Jun 1, 2012
|Feb 11, 2014
|Dell Software Inc.
|Method and system for data reduction
|Jan 28, 2013
|Apr 29, 2014
|Dell Software Inc.
|Recovering a database to any point-in-time in the past with guaranteed data consistency
|Dec 23, 2010
|Sep 30, 2014
|Amazon Technologies, Inc.
|System and method for clustering distributed hash table entries
|Dec 14, 2012
|Mar 3, 2015
|Dell Software Inc.
|Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity
|Jul 29, 2013
|Mar 31, 2015
|Amazon Technologies, Inc.
|System and method for logical deletion of stored data objects
|Feb 10, 2014
|Jun 9, 2015
|Amazon Technologies, Inc.
|System and method for fetching the latest versions of stored data objects
|Apr 23, 2012
|Sep 29, 2015
|Google Inc.
|Controlling access by web applications to resources on servers
|Apr 23, 2012
|Nov 3, 2015
|Google Inc.
|Installation of third-party web applications into a container
|Apr 23, 2012
|Nov 24, 2015
|Google Inc.
|Application-specific file type generation and use
|Mar 30, 2015
|Jan 12, 2016
|Amazon Technologies, Inc.
|System and method for logical deletion of stored data objects
|Apr 23, 2012
|Feb 16, 2016
|Google Inc.
|Third-party indexable text
|Mar 6, 2013
|Apr 19, 2016
|Google Inc.
|System and method for detecting and integrating with native applications enabled for web-based storage
|Oct 22, 2013
|May 24, 2016
|Google Inc.
|Systems and methods for providing just-in-time preview of suggestion resolutions
|Mar 15, 2013
|Aug 30, 2016
|Google Inc.
|System and method for anchoring third party metadata in a document
|May 14, 2013
|Oct 4, 2016
|Google Inc.
|Systems and methods for providing third-party application specific storage in a cloud-based storage system
|U.S. Classification
|International Classification
|Cooperative Classification
|European Classification
|Jul 23, 2009
Owner name: BAKBONE SOFTWARE, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SIM-TANG, SIEW YONG;REEL/FRAME:022994/0627
Effective date: 20090721
Owner name: BAKBONE SOFTWARE, INC.,CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SIM-TANG, SIEW YONG;REEL/FRAME:022994/0627
Effective date: 20090721
|Jun 20, 2011
Owner name: QUEST SOFTWARE, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BAKBONE SOFTWARE INCORPORATED;REEL/FRAME:026482/0359
Effective date: 20110410
|Aug 20, 2013
Owner name: DELL SOFTWARE INC., CALIFORNIA
Free format text: CHANGE OF NAME;ASSIGNOR:QUEST SOFTWARE, INC.;REEL/FRAME:031043/0281
Effective date: 20130701
|Jan 2, 2014
Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, TE
Free format text: PATENT SECURITY AGREEMENT (ABL);ASSIGNORS:DELL INC.;APPASSURE SOFTWARE, INC.;ASAP SOFTWARE EXPRESS,INC.;AND OTHERS;REEL/FRAME:031898/0001
Effective date: 20131029
Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH
Free format text: PATENT SECURITY AGREEMENT (TERM LOAN);ASSIGNORS:DELL INC.;APPASSURE SOFTWARE, INC.;ASAP SOFTWARE EXPRESS, INC.;AND OTHERS;REEL/FRAME:031899/0261
Effective date: 20131029
Owner name: BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS FI
Free format text: PATENT SECURITY AGREEMENT (NOTES);ASSIGNORS:APPASSURE SOFTWARE, INC.;ASAP SOFTWARE EXPRESS, INC.;BOOMI, INC.;AND OTHERS;REEL/FRAME:031897/0348
Effective date: 20131029
|Sep 7, 2015
|Fee payment
Year of fee payment: 4