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 .
Response to Amendment
Applicant’s Amendments, filed May 5, 2026, have been entered. Claims 1-3, 5, 8, 12-15, 18, and 20 have been amended, claims 4 and 10 cancelled, claims 21 and 22 added, and claims 1-3, 5-9, and 11-22 are currently pending.
Response to Arguments
Applicant’s arguments, see Remarks pp. 13-15, filed May 5, 2026, with respect to the rejections of claims 1-20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Acharya (Pub. No. US 2022/0253474 A1, hereinafter “Acharya”) and Labovich et al. (Patent No. US 11,288,285 B2, hereinafter “Labovich”).
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-3, 5-8, 12-18, 20-22 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 Acharya in view of Labovich.
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 different 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 (i.e. different forms), 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:
each database of the first group of object databases having different capabilities suited to manage a different one of the forms
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, and responsively 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 is completed in the second object database, and responsively 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, Acharya teaches:
each database of the first group of object databases having different capabilities suited to manage a different one of the forms (Acharya – the instantiation of an Ontology may need to be stored in multiple databases, each with its own schema and pipeline. For example, the same data, as structured in an Ontology, may be stored in traditional Relational databases, Labeled Property-Graphs, RDF-Triple Stores, in-memory array databases, and more. Each database has its own data model, data-definition language (DDL), and query language [0027].)
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 Acharya before them, to modify the system of Garrod with the teachings of Acharya, as shown above. One would have been motivated to make such a modification to efficiently provide access to data stored in one or more databases as the amount of data increases and a data Ontology becomes more complex (Acharya [0006]).
Garrod modified by Acharya 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, and responsively 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 is completed in the second object database, and responsively 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, Labovich 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, and responsively returning the current version of the first [ontology] entity in response to the first read request (Labovich – in Fig. 8, block 840, a request to read data (i.e. first read request) for the project is received, for example, at the region stack. The request will be handled depending on the state for the project. In block 850, it is determined whether the global clone for the project is in the invalid state (i.e. but not a second object database). If so, the read request will be served by the global database (i.e. current version) [Col. 10 lines 54-67, Col. 11 lines 1-4). New projects (i.e. first new version) may automatically be placed in the invalid state. Accordingly, all requests to read data that are processed while the project is in the invalid state will produce data from the global database [Col. 7 lines 47-51].)
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 is completed in the second object database, and responsively 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 (Labovich – in block 870, it is determined whether the global clone is in the ready state, in which it has been updated with the data that was in the global database at the recorded timestamp (i.e. completed in the second object database). If the global clone is in the ready state, the read request may be served by reading data (i.e. the first new version) from the clone database [Col. 11 lines 5-9].)
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, Acharya, and Labovich before them, to modify the system of Garrod and Acharya with the teachings of Labovich, as shown above. One would have been motivated to make such a modification to provide for consistent reads in a global database that is replicated to one or more global clones (Labovich [Col. 1 lines 50-53]).
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 different 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 (i.e. different forms), 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:
each database of the second group of object databases having different capabilities suited to manage a different one of the forms
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, Acharya teaches:
each database of the second group of object databases having different capabilities suited to manage a different one of the forms (Acharya – the instantiation of an Ontology may need to be stored in multiple databases, each with its own schema and pipeline. For example, the same data, as structured in an Ontology, may be stored in traditional Relational databases, Labeled Property-Graphs, RDF-Triple Stores, in-memory array databases, and more. Each database has its own data model, data-definition language (DDL), and query language [0027].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Acharya, as shown above. One would have been motivated to make such a modification to efficiently provide access to data stored in one or more databases as the amount of data increases and a data Ontology becomes more complex (Acharya [0006]).
Garrod modified by Acharya 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, Labovich 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 (Labovich – in Fig. 8, block 840, a request to read data (i.e. third read request) for the project is received, for example, at the region stack. The request will be handled depending on the state for the project. In block 850, it is determined whether the global clone for the project is in the invalid state (i.e. but not a second object database). If so, the read request will be served by the global database [Col. 10 lines 54-67, Col. 11 lines 1-4). New projects may automatically be placed in the invalid state. Accordingly, all requests to read data that are processed while the project is in the invalid state will produce data from the global database [Col. 7 lines 47-51].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Labovich, as shown above. One would have been motivated to make such a modification to provide for consistent reads in a global database that is replicated to one or more global clones (Labovich [Col. 1 lines 50-53]).
Claim 14 corresponds to claim 2 and is rejected accordingly.
Regarding claim 3, Garrod teaches:
a second ontology entity of the plurality of ontology entities being represented in multiple different 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 (i.e. different forms), 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:
each database of the second group of object databases having different capabilities suited to manage a different one of the forms
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, Acharya teaches:
each database of the second group of object databases having different capabilities suited to manage a different one of the forms (Acharya – the instantiation of an Ontology may need to be stored in multiple databases, each with its own schema and pipeline. For example, the same data, as structured in an Ontology, may be stored in traditional Relational databases, Labeled Property-Graphs, RDF-Triple Stores, in-memory array databases, and more. Each database has its own data model, data-definition language (DDL), and query language [0027].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Acharya, as shown above. One would have been motivated to make such a modification to efficiently provide access to data stored in one or more databases as the amount of data increases and a data Ontology becomes more complex (Acharya [0006]).
Garrod modified by Acharya 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, Labovich 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 (Labovich – when the global database is updated, the updates may be replicated (i.e. write requests) to the regional database in chunks [Col. 8 lines 46-50]. In Fig. 8, block 840, a request to read data (i.e. third read request) for the project is received, for example, at the region stack. The request will be handled depending on the state for the project. In block 850, it is determined whether the global clone for the project is in the invalid state (i.e. but not a second object database). If so, the read request will be served by the global database [Col. 10 lines 54-67, Col. 11 lines 1-4). New projects may automatically be placed in the invalid state. Accordingly, all requests to read data that are processed while the project is in the invalid state will produce data from the global database [Col. 7 lines 47-51].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Labovich, as shown above. One would have been motivated to make such a modification to provide for consistent reads in a global database that is replicated to one or more global clones (Labovich [Col. 1 lines 50-53]).
Claim 15 corresponds to claim 3 and are rejected accordingly.
Regarding claim 5, Garrod teaches:
a second ontology entity of the plurality of ontology entities being represented in multiple different 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 (i.e. different forms), 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:
each database of the second group of object databases having different capabilities suited to manage a different one of the forms
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, Acharya teaches:
each database of the second group of object databases having different capabilities suited to manage a different one of the forms (Acharya – the instantiation of an Ontology may need to be stored in multiple databases, each with its own schema and pipeline. For example, the same data, as structured in an Ontology, may be stored in traditional Relational databases, Labeled Property-Graphs, RDF-Triple Stores, in-memory array databases, and more. Each database has its own data model, data-definition language (DDL), and query language [0027].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Acharya, as shown above. One would have been motivated to make such a modification to efficiently provide access to data stored in one or more databases as the amount of data increases and a data Ontology becomes more complex (Acharya [0006]).
Garrod modified by Acharya 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, Labovich 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 (Labovich – when the global database is updated, the updates may be replicated (i.e. write requests) to the regional database in chunks. When the global database is updated, the updates may be replicated to the regional database in chunks. As the project is updated one or more rows may be added, deleted, or modified [Col. 8 lines 46-53]. In Fig. 8, block 840, a request to read data for the project is received, for example, at the region stack. The request will be handled depending on the state for the project. In block 850, it is determined whether the global clone for the project is in the invalid state. If so, the read request will be served by the global database [Col. 10 lines 54-67, Col. 11 lines 1-4). New projects may automatically be placed in the invalid state. Accordingly, all requests to read data that are processed while the project is in the invalid state will produce data from the global database [Col. 7 lines 47-51].)
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 (Labovich – when the global database is updated, the updates may be replicated (i.e. write requests) to the regional database in chunks. When the global database is updated, the updates may be replicated to the regional database in chunks. As the project is updated one or more rows may be added, deleted, or modified [Col. 8 lines 46-53]. In Fig. 8, block 840, a request to read data for the project is received, for example, at the region stack. The request will be handled depending on the state for the project. In block 850, it is determined whether the global clone for the project is in the invalid state. If so, the read request will be served by the global database [Col. 10 lines 54-67, Col. 11 lines 1-4). New projects may automatically be placed in the invalid state. Accordingly, all requests to read data that are processed while the project is in the invalid state will produce data from the global database [Col. 7 lines 47-51].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Labovich, as shown above. One would have been motivated to make such a modification to provide for consistent reads in a global database that is replicated to one or more global clones (Labovich [Col. 1 lines 50-53]).
Regarding claim 6, Garrod modified by Acharya does not appear to teach:
terminating representation of the first new version of the second ontology entity in the fourth object database
However, Labovich teaches:
terminating representation of the first new version of the second ontology entity in the fourth object database (Labovich – when the global database is updated, the updates may be replicated to the regional database in chunks. As the project is updated one or more rows may be added, deleted, or modified [Col. 8 lines 46-53].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Labovich, as shown above. One would have been motivated to make such a modification to provide for consistent reads in a global database that is replicated to one or more global clones (Labovich [Col. 1 lines 50-53]).
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, [each database of the second group of object databases having different capabilities suited to manage a different from of the second ontology entity], 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:
each database of the second group of object databases having different capabilities suited to manage a different from of the second ontology entity
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, Acharya teaches:
each database of the second group of object databases having different capabilities suited to manage a different from of the second ontology entity (Acharya – the instantiation of an Ontology may need to be stored in multiple databases, each with its own schema and pipeline. For example, the same data, as structured in an Ontology, may be stored in traditional Relational databases, Labeled Property-Graphs, RDF-Triple Stores, in-memory array databases, and more. Each database has its own data model, data-definition language (DDL), and query language [0027].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Acharya, as shown above. One would have been motivated to make such a modification to efficiently provide access to data stored in one or more databases as the amount of data increases and a data Ontology becomes more complex (Acharya [0006]).
Garrod modified by Acharya 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, Labovich 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 (Labovich – in Fig. 8, block 840, a request to read data (i.e. first read request) for the project is received, for example, at the region stack. The request will be handled depending on the state for the project. In block 850, it is determined whether the global clone for the project is in the invalid state (i.e. but not a second object database). If so, the read request will be served by the global database (i.e. current version) [Col. 10 lines 54-67, Col. 11 lines 1-4). New projects (i.e. first new version) may automatically be placed in the invalid state. Accordingly, all requests to read data that are processed while the project is in the invalid state will produce data from the global database [Col. 7 lines 47-51].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Labovich, as shown above. One would have been motivated to make such a modification to provide for consistent reads in a global database that is replicated to one or more global clones (Labovich [Col. 1 lines 50-53]).
Claim 18 corresponds to claim 8 and is rejected accordingly.
Regarding claim 12, Garrod teaches:
a second ontology entity of the plurality of ontology entities being represented in multiple different 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 (i.e. different forms), 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.)
Garrod does not appear to teach:
each database of the second group of object databases having different capabilities suited to manage a different one of the forms
However, Acharya teaches:
each database of the second group of object databases having different capabilities suited to manage a different one of the forms (Acharya – the instantiation of an Ontology may need to be stored in multiple databases, each with its own schema and pipeline. For example, the same data, as structured in an Ontology, may be stored in traditional Relational databases, Labeled Property-Graphs, RDF-Triple Stores, in-memory array databases, and more. Each database has its own data model, data-definition language (DDL), and query language [0027].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Acharya, as shown above. One would have been motivated to make such a modification to efficiently provide access to data stored in one or more databases as the amount of data increases and a data Ontology becomes more complex (Acharya [0006]).
Regarding claim 16, 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 modified by Acharya 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, Labovich 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 (Labovich – the maintenance activity in the region control plane store may also detect transactions for projects in the clone pending state. For example, the maintenance activity may detect that a threshold number of reads or writes for the project have occurred. The threshold number may be one or more. When this occurs, the maintenance activity may determine whether the project should be transitioned to the clone_ready state [Col. 8 lines 10-26].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Labovich, as shown above. One would have been motivated to make such a modification to provide for consistent reads in a global database that is replicated to one or more global clones (Labovich [Col. 1 lines 50-53]).
Regarding claim 21, Garrod does not appear to teach:
wherein the first object database is a relational database and the second object database is not a relational database
However, Acharya teaches:
wherein the first object database is a relational database and the second object database is not a relational database (Acharya – the instantiation of an Ontology may need to be stored in multiple databases, each with its own schema and pipeline. For example, the same data, as structured in an Ontology, may be stored in traditional Relational databases, Labeled Property-Graphs, RDF-Triple Stores, in-memory array databases, and more. Each database has its own data model, data-definition language (DDL), and query language [0027].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Acharya, as shown above. One would have been motivated to make such a modification to efficiently provide access to data stored in one or more databases as the amount of data increases and a data Ontology becomes more complex (Acharya [0006]).
Regarding claim 22, Garrod does not appear to teach:
wherein the second object database is a graph database
However, Acharya teaches:
wherein the second object database is a graph database (Acharya – the instantiation of an Ontology may need to be stored in multiple databases, each with its own schema and pipeline. For example, the same data, as structured in an Ontology, may be stored in traditional Relational databases, Labeled Property-Graphs, RDF-Triple Stores, in-memory array databases, and more. Each database has its own data model, data-definition language (DDL), and query language [0027].)
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, Acharya, and Labovich before them, to modify the system of Garrod, Acharya, and Labovich with the teachings of Acharya, as shown above. One would have been motivated to make such a modification to efficiently provide access to data stored in one or more databases as the amount of data increases and a data Ontology becomes more complex (Acharya [0006]).
Claims 9, 11, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Garrod in view of Acharya in view of Labovich further in view of Shams et al. (Patent No. US 9,330,271 B1, hereinafter “Shams”).
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 modified by Acharya and Labovich 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, Acharya, Labovich, and Shams before them, to modify the system of Garrod, Acharya, and Labovich 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 11, Garrod modified by Acharya and Labovich 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, Acharya, Labovich, and Shams before them, to modify the system of Garrod, Acharya, and Labovich 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]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
