DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Garrod et al. (Pub. No. US 2012/0016849 A1, hereinafter “Garrod”) in view of Shams et al. (Patent No. US 9,330,271 B1, hereinafter “Shams”).
Regarding claim 1, Garrod teaches:
managing an ontology including a definition for each ontology entity type of a plurality of ontology entity types and a plurality of ontology entities instantiated from the plurality of ontology entity types, (Garrod – see [0038-0039], where in Fig. 2, a data object can represent an entity (i.e. ontology entity) such as a person, a place, an organization, or other noun. Each data object can have a type. In one embodiment, the set of data object types and the set of property types for each type of data object supported by the system are defined according to a pre-defined or user-defined ontology or other hierarchical structuring of knowledge through sub-categorization of object types and property types according to their relevant and/or cognitive qualities.)
a first ontology entity of the plurality of ontology entities being represented in multiple forms respectively in a first group of object databases of a plurality of object databases, (Garrod – see [0022-0023], where a multimaster database system and computer-based method provides sharing and deconfliction of data changes amongst a plurality of replication sites. Data changes at sites to data objects are tracked by each site on a per-data object basis using per-data object version vectors. Also see [0030, 0037], where the data may be stored in different types of databases, including relational databases, hierarchical databases, and object-oriented databases.)
a current version of the first ontology entity being represented in all object databases of the first group of object databases (Garrod – see [0048-0050], where a version vector is utilized to track changes in the distributed systems. Version vectors are employed on a per-site basis, where each site uses a single version vector to track all changes made to the copy of the database maintained by that site.)
starting, at a first time, representation of a first new version of the first ontology entity in each object database of the first group of object databases (Garrod – see [0071-0072], where Fig. 5 illustrates that each site 101, 102, and 103 maintains a version vector for the data object and are initially identical. At event 503, at site 101, a local change is made to site 101’s copy of the data object (i.e. first new version).)
first ontology entity (Garrod – see [0022-0023], where a multimaster database system and computer-based method provides sharing and deconfliction of data changes amongst a plurality of replication sites. Data changes at sites to data objects are tracked by each site on a per-data object basis using per-data object version vectors. Also see [0030, 0037], where the data may be stored in different types of databases, including relational databases, hierarchical databases, and object-oriented databases.)
first ontology entity (Garrod – see [0022-0023], where a multimaster database system and computer-based method provides sharing and deconfliction of data changes amongst a plurality of replication sites. Data changes at sites to data objects are tracked by each site on a per-data object basis using per-data object version vectors. Also see [0030, 0037], where the data may be stored in different types of databases, including relational databases, hierarchical databases, and object-oriented databases.)
Garrod does not appear to teach:
receiving, at a second time after the first time, a first read request to read the first [ontology] entity; determining, at the second time, that the representation of the first new version of the first [ontology] entity is completed in a first object database of the first group of object databases but not a second object database of the first group of object databases; returning the current version of the first [ontology] entity in response to the first read request
receiving, at a third time after the second time, a second read request to read the first [ontology] entity; determining, at the third time, that the representation of the first new version of the first [ontology] entity is completed in the first object database and a difference between the third time and the second time exceeds a threshold; returning the first new version of the first [ontology] entity in response to the second read request, wherein the method is performed by one or more processors
However, Shams teaches:
receiving, at a second time after the first time, a first read request to read the first [ontology] entity; determining, at the second time, that the representation of the first new version of the first [ontology] entity is completed in a first object database of the first group of object databases but not a second object database of the first group of object databases; returning the current version of the first [ontology] entity in response to the first read request (Shams – see [Col. 3 lines 66-67, Col. 4 lines 1-17], where distributed data stores may reflect a data consistency pattern that can be described as eventual consistency. This term refers to updated data that is not immediately available (i.e. first new version not at second object database), in updated form, even after an update has been committed. For example, an update might be committed in a distributed data store with three replication partners. An update might be committed and also stored in two of the three replication partners, but not a third. If a query were to rely on the third replication partner, the results would reflect a previous version of the data, rather than the currently committed version of the data. Also see [Col. 7 lines 11-25], where distributed databases may have behaviors related to eventual consistency. In one embodiment, read requests are modified to sometimes return pre-modification values in order to simulate an effect of eventual consistency. In a distributed data store, an update applied to one node (i.e. first object database) might take some time to propagate from one data store to another data store acting as a replication partner (i.e. second object database). In addition, there may be a delay in updating data structures such as indexes. Accordingly, returning a pre-modification value (i.e. returned the current version) may simulate an effect of using a replication partner as the source of the data.)
receiving, at a third time after the second time, a second read request to read the first [ontology] entity; determining, at the third time, that the representation of the first new version of the first [ontology] entity is completed in the first object database and a difference between the third time and the second time exceeds a threshold; returning the first new version of the first [ontology] entity in response to the second read request, wherein the method is performed by one or more processors (Shams – see [Col. 7 lines 11-30], where the pattern of returning old (i.e. current version) and new (i.e. first new version) values may be based partly on a simulated pattern of accessing replication patterns for workload distribution, such as with a round robin scheme. For example, in a three-node replication scheme the emulation could return a new value 33.3% of the time and an old value 66.6% of the time (i.e. threshold). To simulate the effect of delayed index updates, queries (i.e. read requests) may return results that would be accurate under the old data, but inaccurate after considering the effect of the new data. Also see [Col. 4 lines 62-66] for processor.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Garrod and Shams before them, to modify the system of Garrod with the teachings of Shams, as shown above. One would have been motivated to make such a modification to provide synchronization techniques between data stores (Shams [Col. 2, lines 1-4]).
Claims 13 and 20 correspond to claim 1 and are rejected accordingly.
Regarding claim 2, Garrod teaches:
a second ontology entity of the plurality of ontology entities being represented in multiple forms respectively in a second group of object databases of the plurality of object databases, (Garrod – see [0022-0023], where a multimaster database system and computer-based method provides sharing and deconfliction of data changes amongst a plurality of replication sites. Data changes at sites to data objects are tracked by each site on a per-data object basis using per-data object version vectors. Also see [0030, 0037], where the data may be stored in different types of databases, including relational databases, hierarchical databases, and object-oriented databases.)
a current version of the second ontology entity being represented in all object databases of the second group of object databases (Garrod – see [0048-0050], where a version vector is utilized to track changes in the distributed systems. Version vectors are employed on a per-site basis, where each site uses a single version vector to track all changes made to the copy of the database maintained by that site.)
the method further comprising: starting, at a fourth time, representation of a first new version of the second ontology entity in each object database of the second group of object databases (Garrod – see [0071-0072], where Fig. 5 illustrates that each site 101, 102, and 103 maintains a version vector for the data object and are initially identical. At event 503, at site 101, a local change is made to site 101’s copy of the data object (i.e. first new version).)
second ontology entity (Garrod – see [0022-0023], where a multimaster database system and computer-based method provides sharing and deconfliction of data changes amongst a plurality of replication sites. Data changes at sites to data objects are tracked by each site on a per-data object basis using per-data object version vectors. Also see [0030, 0037], where the data may be stored in different types of databases, including relational databases, hierarchical databases, and object-oriented databases.)
Garrod does not appear to teach:
receiving, at a fifth time after the fourth time, a third read request to read the second [ontology] entity; determining, at the fifth time, that the representation of the first new version of the second [ontology] entity is completed in a third object database of the second group of object databases but not a fourth object database of the second group of object databases; returning the first new version of the second [ontology] entity in response to the third read request
However, Shams teaches:
receiving, at a fifth time after the fourth time, a third read request to read the second [ontology] entity; determining, at the fifth time, that the representation of the first new version of the second [ontology] entity is completed in a third object database of the second group of object databases but not a fourth object database of the second group of object databases; returning the first new version of the second [ontology] entity in response to the third read request (Shams – see [Col. 7 lines 11-30], where the pattern of returning old (i.e. current version) and new (i.e. first new version) values may be based partly on a simulated pattern of accessing replication patterns for workload distribution, such as with a round robin scheme. For example, in a three-node replication scheme the emulation could return a new value 33.3% of the time and an old value 66.6% of the time. To simulate the effect of delayed index updates, queries (i.e. read requests) may return results that would be accurate under the old data, but inaccurate after considering the effect of the new data.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Garrod and Shams before them, to modify the system of Garrod and Shams with the teachings of Shams, as shown above. One would have been motivated to make such a modification to provide synchronization techniques between data stores (Shams [Col. 2, lines 1-4]).
Claim 14 corresponds to claim 2 and are rejected accordingly.
Regarding claim 3, Garrod teaches:
a second ontology entity of the plurality of ontology entities being represented in multiple forms respectively in a second group of object databases of the plurality of object databases, (Garrod – see [0022-0023], where a multimaster database system and computer-based method provides sharing and deconfliction of data changes amongst a plurality of replication sites. Data changes at sites to data objects are tracked by each site on a per-data object basis using per-data object version vectors. Also see [0030, 0037], where the data may be stored in different types of databases, including relational databases, hierarchical databases, and object-oriented databases.)
a current version of the second ontology entity being represented in all object databases of the second group of object databases (Garrod – see [0048-0050], where a version vector is utilized to track changes in the distributed systems. Version vectors are employed on a per-site basis, where each site uses a single version vector to track all changes made to the copy of the database maintained by that site.)
the method further comprising: starting, at a fourth time, representation of a first new version of the second ontology entity in each object database of the second group of object databases (Garrod – see [0071-0072], where Fig. 5 illustrates that each site 101, 102, and 103 maintains a version vector for the data object and are initially identical. At event 503, at site 101, a local change is made to site 101’s copy of the data object (i.e. first new version).)
queuing, at the fifth time, the first write request (Garrod – see [0064], where if the conflict cannot be automatically deconflicted, then the receiving site holds the update in a pending update queue for the data object until it can be deconflicted with the aid of user input. While an update to a data object remains in the receiving site’s pending update queue for the data object, the receiving site can continue to make changes to the data object and accept and apply updates to the data object received from other sites until the user either discards or accepts the update.)
Garrod does not appear to teach:
receiving, at a fifth time after the fourth time, a first write request to write a second new version of the second ontology entity; determining, at the fifth time, that the representation of the first new version of the second ontology entity is completed in a third object database of the second group of object databases but not a fourth object database of the second group of object databases
However, Shams teaches:
receiving, at a fifth time after the fourth time, a first write request to write a second new version of the second ontology entity; determining, at the fifth time, that the representation of the first new version of the second ontology entity is completed in a third object database of the second group of object databases but not a fourth object database of the second group of object databases (Shams – see [Col. 3 lines 66-67, Col. 4 lines 1-17], where distributed data stores may reflect a data consistency pattern that can be described as eventual consistency. This term refers to updated data that is not immediately available, in updated form, even after an update has been committed. For example, an update might be committed in a distributed data store with three replication partners. An update might be committed (i.e. write request) and also stored in two of the three replication partners, but not a third (i.e. or not a fourth object database). If a query were to rely on the third replication partner, the results would reflect a previous version of the data, rather than the currently committed version of the data.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Garrod and Shams before them, to modify the system of Garrod and Shams with the teachings of Shams, as shown above. One would have been motivated to make such a modification to provide synchronization techniques between data stores (Shams [Col. 2, lines 1-4]).
Claim 15 corresponds to claim 3 and are rejected accordingly.
Regarding claim 4, Garrod teaches:
at the sixth time, dequeuing the first write request and starting representation of the second new version of the second ontology entity in each object database of the second group of object databases (Garrod – see [0064], where if the conflict cannot be automatically deconflicted, then the receiving site holds the update in a pending update queue for the data object until it can be deconflicted with the aid of user input. While an update to a data object remains in the receiving site’s pending update queue for the data object, the receiving site can continue to make changes to the data object and accept and apply updates to the data object received from other sites until the user either discards or accepts (i.e. dequeuing) the update.)
Garrod does not appear to teach:
determining, at a sixth time after the fifth time, that the representation of the first new version of the second ontology entity is completed in the third object database and a difference between the sixth time and the fifth time exceeds a second threshold
However, Shams teaches:
determining, at a sixth time after the fifth time, that the representation of the first new version of the second ontology entity is completed in the third object database and a difference between the sixth time and the fifth time exceeds a second threshold (Shams – see [Col. 7 lines 11-30], where the pattern of returning old and new (i.e. first new version) values may be based partly on a simulated pattern of accessing replication patterns for workload distribution, such as with a round robin scheme. For example, in a three-node replication scheme the emulation could return a new value 33.3% of the time and an old value 66.6% of the time (i.e. threshold). To simulate the effect of delayed index updates, queries may return results that would be accurate under the old data, but inaccurate after considering the effect of the new data.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Garrod and Shams before them, to modify the system of Garrod and Shams with the teachings of Shams, as shown above. One would have been motivated to make such a modification to provide synchronization techniques between data stores (Shams [Col. 2, lines 1-4]).
Claim 16 corresponds to claim 4 and are rejected accordingly.
Regarding claim 5, Garrod teaches:
a second ontology entity of the plurality of ontology entities being represented in multiple forms respectively in a second group of object databases of the plurality of object databases, (Garrod – see [0022-0023], where a multimaster database system and computer-based method provides sharing and deconfliction of data changes amongst a plurality of replication sites. Data changes at sites to data objects are tracked by each site on a per-data object basis using per-data object version vectors. Also see [0030, 0037], where the data may be stored in different types of databases, including relational databases, hierarchical databases, and object-oriented databases.)
a current version of the second ontology entity being represented in all object databases of the second group of object databases (Garrod – see [0048-0050], where a version vector is utilized to track changes in the distributed systems. Version vectors are employed on a per-site basis, where each site uses a single version vector to track all changes made to the copy of the database maintained by that site.)
the method further comprising: starting, at a fourth time, representation of a first new version of the second ontology entity in each object database of the second group of object databases (Garrod – see [0071-0072], where Fig. 5 illustrates that each site 101, 102, and 103 maintains a version vector for the data object and are initially identical. At event 503, at site 101, a local change is made to site 101’s copy of the data object (i.e. first new version).)
Garrod does not appear to teach:
receiving, at a fifth time after the fourth time, a first write request to write a second new version of the second ontology entity; determining, at the fifth time, that the representation of the first new version of the second ontology entity is completed in a third object database of the second group of object databases but not a fourth object database of the second group of object databases
starting, at the fifth time, representation of the second new version of the second ontology entity in each object database of the second group of object databases in response to the first write request
However, Shams teaches:
receiving, at a fifth time after the fourth time, a first write request to write a second new version of the second ontology entity; determining, at the fifth time, that the representation of the first new version of the second ontology entity is completed in a third object database of the second group of object databases but not a fourth object database of the second group of object databases (Shams – see [Col. 3 lines 66-67, Col. 4 lines 1-17], where distributed data stores may reflect a data consistency pattern that can be described as eventual consistency. This term refers to updated data that is not immediately available, in updated form, even after an update has been committed. For example, an update might be committed in a distributed data store with three replication partners. An update might be committed (i.e. write request) and also stored in two of the three replication partners, but not a third (i.e. or not a fourth object database). If a query were to rely on the third replication partner, the results would reflect a previous version of the data, rather than the currently committed version of the data.)
starting, at the fifth time, representation of the second new version of the second ontology entity in each object database of the second group of object databases in response to the first write request (Shams – see [Col. 3 lines 66-67, Col. 4 lines 1-17], where distributed data stores may reflect a data consistency pattern that can be described as eventual consistency. This term refers to updated data that is not immediately available, in updated form, even after an update has been committed. For example, an update might be committed in a distributed data store with three replication partners. An update might be committed (i.e. write request) and also stored in two of the three replication partners, but not a third (i.e. or not a fourth object database). If a query were to rely on the third replication partner, the results would reflect a previous version of the data, rather than the currently committed version of the data. However, because the update has been committed, the update will eventually be applied to the third replication partner (i.e. or the fourth object database).)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Garrod and Shams before them, to modify the system of Garrod and Shams with the teachings of Shams, as shown above. One would have been motivated to make such a modification to provide synchronization techniques between data stores (Shams [Col. 2, lines 1-4]).
Regarding claim 6, Garrod does not appear to teach:
terminating representation of the first new version of the second ontology entity in the fourth object database
However, Shams teaches:
terminating representation of the first new version of the second ontology entity in the fourth object database (Shams – see [Col. 3 lines 66-67, Col. 4 lines 1-17], where distributed data stores may reflect a data consistency pattern that can be described as eventual consistency. This term refers to updated data that is not immediately available, in updated form, even after an update has been committed. For example, an update might be committed in a distributed data store with three replication partners. An update might be committed (i.e. write request) and also stored in two of the three replication partners, but not a third (i.e. or not a fourth object database). If a query were to rely on the third replication partner, the results would reflect a previous version of the data, rather than the currently committed version of the data. However, because the update has been committed, the update will eventually be applied to the third replication partner (i.e. or the fourth object database, terminating the first new version).
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Garrod and Shams before them, to modify the system of Garrod and Shams with the teachings of Shams, as shown above. One would have been motivated to make such a modification to provide synchronization techniques between data stores (Shams [Col. 2, lines 1-4]).
Regarding claim 7, Garrod teaches:
the ontology further including a mapping associating each ontology entity type of the plurality of ontology entity types with one or more object databases of the plurality of object databases, including associating a first ontology entity type from which the first ontology entity is instantiated with the first group of object databases (Garrod – see [0048-0050], where a version vector is a known mechanism for tracking (i.e. mapping) changes in distributed systems. Each site 101, 102, 103, etc. maintains version vectors on a per-data object basis.)
Claim 17 corresponds to claim 7 and is rejected accordingly.
Regarding claim 8, Garrod teaches:
the mapping further associating a second ontology entity type from which a second ontology entity is instantiated with a second group of object databases and designating a particular object database of the second group of object databases as a canonical object database for the second ontology entity type, a current version of the second ontology entity being represented in all object databases of the second group of object databases; the method further comprising: starting, at a fourth time, representation of a first new version of the second ontology entity in each object database of the second group of object databases (Garrod – see [0071-0072], where Fig. 5 illustrates that each site 101, 102, and 103 maintains a version vector for the data object and are initially identical. At event 503, at site 101, a local change is made to site 101’s copy of the data object (i.e. first new version).)
second ontology entity (Garrod – see [0022-0023], where a multimaster database system and computer-based method provides sharing and deconfliction of data changes amongst a plurality of replication sites. Data changes at sites to data objects are tracked by each site on a per-data object basis using per-data object version vectors. Also see [0030, 0037], where the data may be stored in different types of databases, including relational databases, hierarchical databases, and object-oriented databases.)
second ontology entity type (Garrod – see [0038-0039], where in Fig. 2, a data object can represent an entity (i.e. ontology entity) such as a person, a place, an organization, or other noun. Each data object can have a type. In one embodiment, the set of data object types and the set of property types for each type of data object supported by the system are defined according to a pre-defined or user-defined ontology or other hierarchical structuring of knowledge through sub-categorization of object types and property types according to their relevant and/or cognitive qualities.)
Garrod does not appear to teach:
receiving, at a fifth time after the fourth time, a third read request to read the second [ontology] entity; determining, at the fifth time, that the representation of the first new version of the second [ontology] entity is not completed in the canonical object database for the second [ontology] entity type; returning the current version of the second [ontology] entity in response to the third read request
However, Shams teaches:
receiving, at a fifth time after the fourth time, a third read request to read the second [ontology] entity; determining, at the fifth time, that the representation of the first new version of the second [ontology] entity is not completed in the canonical object database for the second [ontology] entity type; returning the current version of the second [ontology] entity in response to the third read request (Shams – see [Col. 7 lines 11-30], where the pattern of returning old (i.e. current version) and new (i.e. first new version) values may be based partly on a simulated pattern of accessing replication patterns for workload distribution, such as with a round robin scheme. For example, in a three-node replication scheme the emulation could return a new value 33.3% of the time and an old value 66.6% of the time. To simulate the effect of delayed index updates, queries (i.e. read requests) may return results that would be accurate under the old data, but inaccurate after considering the effect of the new data.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Garrod and Shams before them, to modify the system of Garrod and Shams with the teachings of Shams, as shown above. One would have been motivated to make such a modification to provide synchronization techniques between data stores (Shams [Col. 2, lines 1-4]).
Claim 18 corresponds to claim 8 and is rejected accordingly.
Regarding claim 9, Garrod teaches:
receiving a set of data source updates for one or more datasets from one or more data sources; receiving one or more sets of user edits to the ontology (Garrod – see [0055], where Fig. 3 illustrates a method 300 for sharing a data change to a data object in a multimaster database system using per-object version vectors. Method 300 begins at step 305 where a site makes a change to a local copy of a data object stored in the site’s copy of the body of data. For example, a user may use a database application at the site to add, delete, or edit one or more properties of the data object.)
transforming the set of data source updates to a set of changes to the ontology based on a first mapping between the one or more data sources and the plurality of ontology entity types; merging the set of changes to the ontology with the one or more sets of user edits to obtain a merged dataset, the merged dataset including a representation of the first new version of the first ontology entity (Garrod – see [0056], where as part of changing a data object at a site, each change results in a new version of the data object (i.e. merged dataset) at the site. At step 310, the site’s local logical clock in the version vector for the data object is incremented by a fixed value to reflect the new version of the data object at the site where the change was made.)
based on a second mapping between the plurality of ontology entity types and the plurality of object databases (Garrod – see [0056], where as part of changing a data object at a site, each change results in a new version of the data object (i.e. merged dataset) at the site. At step 310, the site’s local logical clock in the version vector for the data object is incremented (i.e. second mapping) by a fixed value to reflect the new version of the data object at the site where the change was made.)
Garrod does not appear to teach:
generating index data for one or more object databases of the plurality of object databases [based on a second mapping between the plurality of ontology entity types and the plurality of object databases]; transmitting the index data to the one or more object databases
However, Shams teaches:
generating index data for one or more object databases of the plurality of object databases [based on a second mapping between the plurality of ontology entity types and the plurality of object databases]; transmitting the index data to the one or more object databases (Shams – see Col. 3 lines 50-67, Col. 4 lines 1-17, where various operations on data in a distributed data store may be made more efficient through the use of index structures, which may be over the primary key. Once an update is committed, the update will eventually be applied to the third replication partner and the data may be said to be eventually consistent. A similar pattern may be seen with index structures. Some indexes may not be immediately updated to reflect an update to the data store, however, eventually the index will be updated.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Garrod and Shams before them, to modify the system of Garrod and Shams with the teachings of Shams, as shown above. One would have been motivated to make such a modification to provide synchronization techniques between data stores (Shams [Col. 2, lines 1-4]).
Claim 19 corresponds to claim 9 and is rejected accordingly.
Regarding claim 10, Garrod teaches:
a user edit of the one or more sets of user edits being a change to an ontology entity of the plurality of ontology entities, each set of user edits of the one or more sets of user edits leading to a single new version of an ontology entity (Garrod – see [0055], where Fig. 3 illustrates a method 300 for sharing a data change to a data object in a multimaster database system using per-object version vectors. Method 300 begins at step 305 where a site makes a change to a local copy of a data object stored in the site’s copy of the body of data. For example, a user may use a database application at the site to add, delete, or edit one or more properties of the data object.)
Regarding claim 11, Garrod does not appear to teach:
the managing comprising responding to all read requests to read ontology entities of a first ontology entity type from which the first ontology entity is instantiated according to a first common strategy and all write requests to write ontology entities of the first ontology entity type according to a second common strategy, the returning of the first new version of the first ontology entity in response to the second read request being performed according to the first common strategy
However, Shams teaches:
the managing comprising responding to all read requests to read ontology entities of a first ontology entity type from which the first ontology entity is instantiated according to a first common strategy and all write requests to write ontology entities of the first ontology entity type according to a second common strategy, the returning of the first new version of the first ontology entity in response to the second read request being performed according to the first common strategy (Shams – see [Col. 7 lines 11-30], where the pattern of returning old (i.e. current version) and new (i.e. first new version) values may be based partly on a simulated pattern of accessing replication patterns for workload distribution, such as with a round robin scheme. For example, in a three-node replication scheme the emulation could return a new value 33.3% (i.e. first common strategy) of the time and an old value 66.6% of the time. To simulate the effect of delayed index updates, queries (i.e. read requests) may return results that would be accurate under the old data, but inaccurate after considering the effect of the new data.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Garrod and Shams before them, to modify the system of Garrod and Shams with the teachings of Shams, as shown above. One would have been motivated to make such a modification to provide synchronization techniques between data stores (Shams [Col. 2, lines 1-4]).
Regarding claim 12, Garrod teaches:
a second ontology entity of the plurality of ontology entities being represented in multiple forms respectively in a second group of object databases of the plurality of object databases, (Garrod – see [0022-0023], where a multimaster database system and computer-based method provides sharing and deconfliction of data changes amongst a plurality of replication sites. Data changes at sites to data objects are tracked by each site on a per-data object basis using per-data object version vectors. Also see [0030, 0037], where the data may be stored in different types of databases, including relational databases, hierarchical databases, and object-oriented databases.)
a current version of the second ontology entity being represented in all object databases of the second group of object databases (Garrod – see [0048-0050], where a version vector is utilized to track changes in the distributed systems. Version vectors are employed on a per-site basis, where each site uses a single version vector to track all changes made to the copy of the database maintained by that site.)
the method further comprising: receiving, at a fourth time, a first write request to write a first new version of the second ontology entity (Garrod – see [0071-0072], where Fig. 5 illustrates that each site 101, 102, and 103 maintains a version vector for the data object and are initially identical. At event 503, at site 101, a local change is made to site 101’s copy of the data object (i.e. first new version).)
determining that the first new version of the second ontology entity is an update to a specific version of the second ontology entity older the current version of the second ontology entity; rejecting the first write request (Garrod – see [0064], where if the conflict cannot be automatically deconflicted, then the receiving site holds the update in a pending update queue for the data object until it can be deconflicted with the aid of user input. While an update to a data object remains in the receiving site’s pending update queue for the data object, the receiving site can continue to make changes to the data object and accept and apply updates to the data object received from other sites until the user either discards (i.e. rejects) or accepts the update.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RANJIT P DORAISWAMY whose telephone number is (571)270-5759. The examiner can normally be reached Monday-Friday 9:00 AM - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sanjiv Shah can be reached at (571) 272-4098. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RANJIT P DORAISWAMY/Examiner, Art Unit 2166
/SANJIV SHAH/Supervisory Patent Examiner, Art Unit 2166