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 .
Status of Claims
Claims 1, 3-20 are pending of which claims 1, 10 and 18 are in independent form.
Claims 1, 3-20 are rejected under 35 U.S.C. 101.
Claims 1, 3-20 are rejected under 35 U.S.C. 103.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 3-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Regarding 35 USC 101 (Abstract Idea)
Applicant argues that the claims are directed to improvements in distributed database migration technology, including: phased migration, shadow copy operations, reduced downtime, controlled delegation of ownership, and record specific ownership transfer policies. However, the claims, as drafted, recite result oriented data management rules and ownership transfer decision rather than a specific asserted improvement in computer functionality.
Applicant argument regarding reduced downtime and phased migration is not corresponding with the scope of the claims because do not recite any specific technological mechanism for achieved improved performance beyond generalized function results.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
The claim(s) recite(s) custom scale out in a hybrid database architecture.
With respect to step 1 of the patent subject matter eligibility analysis, the claims are directed to a process, machine, manufacture, or composition of matter.
Independent claim 1 is directed to a method, which is a process.
Independent claim 10 is directed to a system, which lack hardware and therefore rejected under 101.
Independent claim 18 directed to tangible computer-readable storage media, which is directed to one of the four statutory subject matters (non-transitory according to the specification [0095]).
Independent All other claims depend on claims 1 and 18. As such, claims 1-9 and 18-20 are directed to a statutory category.
Regarding claims 1, 10 and 18:
With respect to step 2A, prong one (Judicial Exception), the claims recite an abstract idea, law of nature, or natural phenomenon. Specifically, the following limitations recite mathematical concepts and/or mental processes and/or certain methods of organizing human activity.
The claim recites the following limitations directed to an abstract idea:
Receiving a write request for a data record (Certain methods of organizing human activity),
Assigning ownership of the data record (Certain methods of organizing human activity),
Writing a primary copy of the data record to a first database (Mathematical concepts/data manipulation),
Detecting changes and propagating them to shadow copy (Mental process/Mathematical concepts/Data manipulation),
Identifying…a record specific ownership transfer policy,
Assigning ownership,
Transferring ownership of the data record (Mental process/Mathematical concepts/Data manipulation);
Directing future updates to the new owner (Certain methods of organizing human activity/Mathematical concepts/Data manipulation).
Selecting an ownership-transfer policy and checking criteria constitutes rule-based decision making (Mental Process)
These limitations involve data manipulation, data storage, synchronization, classification, routing of updates, and ownership assignment, which constitute abstract mental process (e.g. observing, evaluating, organizing, updating) and methods of organizing information, identified categories of judicial exception. See Electric Power Group, LLC v. Alstom S.A, 830 F.3d 150 (Fed. Cir. 2016); Content Extraction & Transmission LLC v. Wells Fargo Bank, 776 F.3d 1343 (Fed. Cir. 2014).
With respect to step 2A, Prong Two (Particular Application), the claims do not recite additional elements that integrate the judicial exception into a practical application. The following limitations are considered “additional elements” and explanation will be given as to why these “additional elements” do not integrate the judicial exception into a practical application.
The claims recite the use of:
A hybrid database storage system,
A first database,
A second database,
Control layer.
What we were looking for was “an improvement to database technology”, “a specific technical solution”, “unconventional technical architecture” or “a transformation of the physical technology”, however, NONE of these improvements have been presented in this claim. All the of the mentioned technology presented in the claims are generic computer components to carry out abstract steps mentioned in the claims.
The claims do not improve database technology itself, do not recite a particular improvement to computer functionality, and do not provide any specific technical mechanism for replication, concurrency control, failover, consistency, schema versioning, or transaction processing.
Instead the claims recite conventional and generic computer functions performed in a routine manner, which does not amount to a practical application. See DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014); MPEP 2016.05(a)-(c), (e)-(h).
With respect to Step 2B. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The recited components “hybrid database storage system”, “first database”, “second database”, “control layer” and “change logs”, are merely generic computer/database elements performing their routine, well-understood, and conventional functions. See Alive, MPEP 2016.05(d).
The steps mentioned in the independent claims merely constitutes standard distributed-database behavior, such and basic replication, mirroring, and ownership transfer. Courts have consistently helped such high level information management operations are conventional.
The claims recite only functional, result oriented language (“detecting”, “propagating”, “transferring”,…), without specifying any technical mechanism for performing these operations in a non-conventional manner.
Considering claims as a whole, the ordered combination of elements also reflects nothing more than the typical workflow of distributed systems, and therefore DOES NOT add “significantly more” than the abstract idea.
Such generic, high‐level, and nominal involvement of a computer or computer‐based elements for carrying out the invention merely serves to tie the abstract idea to a particular technological environment, which is not enough to render the claims patent‐eligible, as noted at pg.74624 of Federal Register/Vol. 79, No. 241, citing Alice, which in turn cites Mayo. Further, See, e.g., Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 134 S. Ct. 2347, 2359‐60, 110 USPQ2d 1976, 1984 (2014). See also OIP Techs. v. Amazon.com, 788 F.3d 1359, 1364, 115 USPQ2d 1090, 1093‐94 (Fed. Cir. 2015) ("Just as Diehr could not save the claims in Alice, which were directed to 'implement[ing] the abstract idea of intermediated settlement on a generic computer', it cannot save O/P's claims directed to implementing the abstract idea of price optimization on a generic computer.") (citations omitted). See also, Affinity Labs of Texas LLC v. DirecTV LLC, 838 F.3d 1253, 1257‐1258 (Fed. Cir. 2016) (mere recitation of a GUI does not make a claimpatent‐eligible); Intellectual Ventures I LLC v. Capital One Bank, 792 F.3d 1363, 1370 (Fed. Cir. 2015) ("the interactive interface limitation is a generic computer element".).
The additional elements are broadly applied to the abstract idea at a high level of generality ("similar to how the recitation of the computer in the claims in Alice amounted to mere instructions to apply the abstract idea of intermediated settlement on a generic computer,") as explained in MPEP § 2106.05(f)) and they operate in a well‐understood, routine, and conventional manner.
MPEP § 2106.0S(d)(II) sets forth the following:
The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity.
• Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec ... ; TLI Communications LLC v. AV Auto. LLC ... ; OIP Techs., Inc., v. Amazon.com, Inc ... ; buySAFE, Inc. v. Google, Inc ... ;
• Performing repetitive calculations, Flook ... ; Bancorp Services v. Sun Life ... ;
• Electronic recordkeeping, Alice Corp ... ; Ultramercial ... ;
• Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc ... ;
• Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank ... ; and
• A web browser's back and forward button functionality, Internet Patent
• Corp. v. Active Network, Inc. ...
. . . Courts have held computer-implemented processes not to be significantly more than an abstract idea (and thus ineligible) where the claim as a whole amounts to nothing more than generic computer functions merely used to implement an abstract idea, such as an idea that could be done by a human analog (i.e., by hand or by merely thinking).
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrate the abstract idea into a practical application. Their collective functions merely provide conventional computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that the ordered combination amounts to significantly more than the abstract idea itself.
The dependent claims have been fully considered as well, however, similar to the findings for claims above, these claims are similarly directed to the “Mental Processes” grouping of abstract ideas set forth in the 2019 PEG, without integrating it into a practical application and with, at most, a general purpose computer that serves to tie the idea to a particular technological environment, which does not add significantly more to the claims. The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to significantly more than the abstract idea.
Looking at the claim as a whole does not change this conclusion and the claim is ineligible.
Regarding claims 2: (canceled)
Regarding claims 3, 11, 12 and 19:
With respect to step 2A, prong one (Judicial Exception):
Policy selection and deletion rules are admin lifecycle management, a mental process and organizing human activity which are abstract idea.
With respect to step 2A, Prong Two (Particular Application):
No specific cleanup algorithm or improved deletion technique is provided. No technical integration into a practical application.
With respect to Step 2B:
Retention policies and rule-based deletion are well-known and routine (garbage collection, log compaction), therefore it does not provide any inventive concept.
Regarding claims 4 and 13:
With respect to step 2A, prong one (Judicial Exception):
Identifying creation and redundancy policies and designating “primary” and “Shadow” database is information organization and abstract role assignment, a mental process and organizing human activity which are abstract idea.
With respect to step 2A, Prong Two (Particular Application):
Designation primary/shadow roles is a generic replication model. No improvement to replication, consistency, or redundancy. No technical integration into a practical application.
With respect to Step 2B:
Primary/shadow replication is routine and conventional. The claim adds only high-level labels, not a technical improvement, therefore it does not provide any inventive concept.
Regarding claims 5, 14, and 20:
With respect to step 2A, prong one (Judicial Exception):
Evaluating data characteristics to select a policy is a mental process and rule-based information classification which are abstract idea.
With respect to step 2A, Prong Two (Particular Application):
No specific policy evaluation mechanism or technical transformation. It’s merely a logical selection. No technical integration into a practical application.
With respect to Step 2B:
Generic routine/ownership rules in a sharded or partition distributed system. Therefore, it does not provide any inventive concept or add significantly more.
Regarding claims 6, 15 and 18:
With respect to step 2A, prong one (Judicial Exception):
Schema mapping and constructing write queries based on change logs are data transformation operation, an abstract idea under Electric Power Group.
With respect to step 2A, Prong Two (Particular Application):
The claim recites only the result (map values, construct write query), not any novel mapping technique or improved log-processing mechanism. No technical integration into a practical application.
With respect to Step 2B:
Cross-schema ETL task and log-based replication are routine, conventional database practice. Therefore, it does not provide any inventive concept or add significantly more.
Regarding claims 7 and 16:
With respect to step 2A, prong one (Judicial Exception):
Making a record or shadow copy to indicate ownership is metadata tagging, a known abstract idea information-organization operation.
With respect to step 2A, Prong Two (Particular Application):
No new metadata structure or marking mechanism is provided. This is generic labeling. No technical integration into a practical application.
With respect to Step 2B:
Ownership flag/metadata bits are standard in replicated storage systems. Therefore, it does not provide any inventive concept or add significantly more.
Regarding claims 8 and 17:
With respect to step 2A, prong one (Judicial Exception):
Construct read/write requests, checking ownership, and routine updates is conditional information routing, a known abstract idea.
With respect to step 2A, Prong Two (Particular Application):
The claim does not specify a technical ownership resolution protocol. Only describes high-level functional behavior. This is generic labeling. No technical integration into a practical application.
With respect to Step 2B:
Ownership checks and routing logic are routine in distributed systems (directory based or metadata driven routing). Therefore, it does not provide any inventive concept or add significantly more.
Regarding claims 9:
With respect to step 2A, prong one (Judicial Exception):
Adding identifiers to an index, monitoring changes, and propagating updates is data monitoring and synchronization, a known abstract idea.
With respect to step 2A, Prong Two (Particular Application):
The claim recites no specific index structure, monitoring algorithm, or propagation mechanism-only results. No technical integration into a practical application.
With respect to Step 2B:
Shadow indexing and change-data-capture propagation and conventional techniques. Therefore, it does not provide any inventive concept or add significantly more.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1, 5, 7, 8, 10, 14, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Chercoles Sanchez; Jose Maria et al. (US 20130151558 A1) [Sanchez] in view of Muse; Jon Kevin et al. (US 20210271662 A1) [Muse].
Reading claims 1 and 10, Sanchez discloses, a method comprising: receiving, at a hybrid database storage system, a write request for a data record (receiving requests within a distributed database system ¶ [0082]-[0084], [0098]-[0100], [0114]-[0116], [0128]-[0130]);
in response to receipt of the write request for the data record, assigning [ownership of the data record] to a first database of the hybrid database storage system (assigning/allocating ownership of a data instance to a database instance ¶ [0041], [0084]-[0087], [0100]-[0103]);
writing a primary copy of the data record to the first database of the hybrid database storage system (original data instance stored at the origin database instance ¶ [0013], [0016], [0026], [0084]-[0087]);
while the first database retains ownership of the data record and remains accessible to end users (origin/original database instance retains ownership while data remains accessible and replicated ¶ [0040], [0084]-[0089], [0100]-[0106]),
detecting changes to the primary copy of the data record made in the first database (updates/modifications to the owner/original data instances ¶ [0089]-[0090], [0106], [0122]) and propagating the changes to a shadow copy of the data record to a second database of the hybrid database storage system (replica data/copy data instances and asynchronous replication of updates/modifications to replica instances ¶ [0013], [0016], [0026], [0089]-[0090], [0103]-[0106], [0121]-[0122]).
identifying, from a plurality of [record-specific] ownership transfer policies, a [record- specific] ownership transfer policy [that applies to the data record and that identifies one or more characteristics of the data record] (ownership transfer policies and policy based transfer criteria ¶ [0015], [0040], [0046]-[0066]);
transferring ownership [of the data record] from the first database to the second database (transferring ownership between database instances/nodes ¶ [0041], [0085]-[0087], [0101]-[0103]) [in response to satisfaction of one or more ownership transfer criteria] specified within the [record- specific] ownership transfer policy (ownership transfer conditions specified within transfer policies ¶ [0046]-[0066]);
subsequent to transferring ownership, directing updates to the data record to the second database (E4. The data distribution and location function therefore initiates a distributed transaction using a two-phase commit or three-phase commit algorithm. To do so, the data distribution and location function contacts the origin database instance in order to request a transfer ownership of the data instance from the origin database instance. In order to determine if ownership should be transferred, the ownership metadata stored with the first/original data instance is evaluated against the ownership policies. For example, the evaluation of the ownership policy could take into account any of the conditions described above using information provided by the ownership metadata. In this example, evaluation of the ownership policy results in the request to transfer ownership of the data instance being granted. The data distribution and location function then updates the ownership metadata stored with the first data instance in the origin database instance to identify the new owner database instance for this data instance, and completes the distributed transaction between the origin database instance and the new owner database instance. E5. In accordance with the replication policies of the distributed database, changes to the first data instance will be replicated onto the replica data instances, such that the metadata stored with the owner, replica data instance will be updated to indicate that this database instance is the new owner database instance ¶ [0102]-[0103]. M7. If, at step M6, the node determines that the request is granted/allowed, then the node initiates an update of the ownership metadata associated with the data instance. For example, if the local database instance stores the first/original data instance, then the node updates the ownership metadata stored with the locally stored data instance. It may also initiate an update of the ownership metadata stored with any remotely stored replica data instances in accordance with a replication policy. If the local database instance stores a replica data instance, the node initiates an update of the ownership metadata stored with the first/original data instance. The ownership metadata stored with the locally stored owner, replica data instance is then updated by replication of the changes to the first/original data instance ¶ [0163]. Also see ¶ [0043], [0051]-[0053], [0107]).
However, Sanchez does not explicitly facilitate ownership of the data record; record-specific ownership transfer policies, that applies to the data record and that identifies one or more characteristics of the data record; in response to satisfaction of one or more] ownership transfer criteria.
Muse discloses, ownership of the data record (ownership associated with specific data elements/record data objects ¶ [0003], [0006], [0007]);
record-specific ownership transfer policies (ownership transfer rules applied to specific data elements ¶ [0102]-[0103], ownership associated with specific data elements/record data objects ¶ [0006], [0007], [0099], [0104]), that applies to the data record (transfer ownership of specific data elements/record data objects ¶ [0006], [0007], [0099], [0101]-[0104]) and that identifies one or more characteristics of the data record (ownership attributes associated with individual data elements ¶ [0003], metadata and ownership information associated with specific data elements ¶ [0006]-[0007], ownership transfer rule based on user/device conditions and ownership attributes ¶ [0075], [0102], [0103]);
in response to satisfaction of one or more ownership transfer criteria (determining whether authorization/conditions are satisfied before transfer ¶ [0102]-[0104]).
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of the cited references because Muse’s system would have allowed Sanchez to facilitate ownership of the data record; record-specific ownership transfer policies, that applies to the data record and that identifies one or more characteristics of the data record; in response to satisfaction of one or more] ownership transfer criteria. The motivation to combine is apparent in the Sanchez’s reference, because there is a need to improve data ownership of a single record data object comprising a plurality of individual data elements.
Regarding claim 2, (Canceled).
Regarding claims 5 and 14, the combination of Sanchez and Muse discloses, evaluating one or more characteristics of the data record to identify an ownership transfer policy applicable to the data record (Sanchez: The implementation of a concept of ownership, and an ownership policy that determines when ownership transfers should occur, therefore provides for the dynamic distribution/redistribution of data throughout the distributed database, and for the dynamic allocation/assignment of the role of owner/principal data instance. Consequently, the ownership policy can be configured so as to ensure that data access is optimized, thereby reducing the response times and bandwidth usage of the distributed database ¶ [0040]. . For example, the evaluation of the ownership policy could take into account any of the conditions described above using information provided by the ownership metadata. In this example, evaluation of the ownership policy results in the request to transfer ownership of the data instance being granted. The data distribution and location function therefore retrieves a copy of the first/original data instance ¶ [0086]. Also see ¶ [0102], [0118]).
Regarding claims 7 and 16, the combination of Sanchez and Muse discloses, wherein transferring ownership of the data record includes marking at least one of the primary copy of the data record and the shadow copy of the data record to indicate that the second database is now owner of the primary copy of the data record (Sanchez: The method involves implementing a concept of data ownership, wherein a database instance that that has been assigned/allocated ownership of a data instance is the database instance that should be contacted in order to fulfil a data request relating to the data instance. Consequently, one of multiple possible versions of a data instance that exist within the distributed database is identified as the `owner` data instance. The owner data instance could also be referred to as the principal or primary data instance ¶ [0039]-[0040] and [0043]).
Regarding claims 8 and 17, the combination of Sanchez and Muse discloses, wherein directing updates to the data record to the second database without updating data in the first database further comprises: receiving an update request to update the data record; in response to the update request, constructing and transmitting a read request to at least one of the first database and the second database (Sanchez: As with the modifications/updates of a first/original data instance, the ownership metadata stored with a first/original data instance is also replicated onto any replica data instance in accordance with a replication policy. The ownership metadata of a replica data instance can therefore also be used to identify the owner database instance and thereby locate the data instance that should be used to fulfil a data request, if required ¶ [0081], [0107]); based on data received in response to the read request, determining whether the data record exists and whether the data record is owned by the first database or the second database; in response to determining that the data record exists and is owned by the second database, constructing and transmitting a write query to update the data record in the second database (Sanchez: M7. If, at step M6, the node determines that the request is granted/allowed, then the node initiates an update of the ownership metadata associated with the data instance. For example, if the local database instance stores the first/original data instance, then the node updates the ownership metadata stored with the locally stored data instance. It may also initiate an update of the ownership metadata stored with any remotely stored replica data instances in accordance with a replication policy. If the local database instance stores a replica data instance, the node initiates an update of the ownership metadata stored with the first/original data instance. The ownership metadata stored with the locally stored owner, replica data instance is then updated by replication of the changes to the first/original data instance ¶ [0163]-[0164], [0171]-[0172], [0177]).
Claim(s) 3, 4, 9, 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez in view of Muse in view of TELAGAMSETTI; Sunil Babu et al. (US 20250077358 A1) [Sunil].
Regarding claims 3, 11 and 12, the combination of Sanchez and Muse discloses teaches all the limitation of claim 1.
However, neither Sanchez nor Muse explicitly facilitate subsequent to transferring ownership of the data record from the first database to the second database, identifying a clean-up policy applying to the data record from a plurality of clean-up policies stored in association with different data records or data record characteristics, the clean-up policy defining clean-up criteria applicable to the data record; and in response to determining that the clean-up criteria are satisfied for the data record, implementing the clean-up policy by deleting the data record from the first database.
Sunil, subsequent to transferring ownership of the data record from the first database to the second database, identifying a clean-up policy applying to the data record from a plurality of clean-up policies stored in association with different data records or data record characteristics, the clean-up policy defining clean-up criteria applicable to the data record (Sunil: may have a data protection schedule or data protection plan for conducting backup operations; may be associated with certain data protection preferences, such as encryption and/or deduplication ¶ [0006]. Data movement operations can include by way of example, backup operations, archive operations, information lifecycle management operations such as hierarchical storage management operations, replication operations (e.g., continuous data replication), snapshot operations, deduplication or single-instancing operations, auxiliary copy operations, disaster-recovery copy operations, and the like ¶ [0129]); and
in response to determining that the clean-up criteria are satisfied for the data record, implementing the clean-up policy by deleting the data record from the first database (Sunil: At this point, the backup job may be considered complete. After the 30-day retention period expires, storage manager 140 instructs media agent 144A to delete backup copy 116A from disk library 108A and indexes 150 and/or 153 are updated accordingly ¶ [0192]. Other preferences in management database 446, which may be associated with pseudo-client 401, may include a backup schedule, backup plan, or backup interval; whether secondary copies 116 are to be encrypted and/or deduplicated; retention times for secondary copies 116, etc ¶ [0234]. Also see ¶ [0134]).
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of the cited references because Sunil’s system would have allowed Sanchez and Muse to facilitate subsequent to transferring ownership of the data record from the first database to the second database, identifying a clean-up policy applying to the data record from a plurality of clean-up policies stored in association with different data records or data record characteristics, the clean-up policy defining clean-up criteria applicable to the data record; and in response to determining that the clean-up criteria are satisfied for the data record, implementing the clean-up policy by deleting the data record from the first database. The motivation to combine is apparent in the Sanchez and Muse’s reference, because there is a need to improve conducting scheduled backups, preventing loss of valuable data, and timely restore or migrate data.
Regarding claims 4 and 13, the combination of Sanchez, Muse and Sunil discloses, in response to receiving the data record at a control layer, identifying, based on one or more characteristics of the data record, at least one of a record creation policy and a redundancy policy applicable to the data record; and based on at least one of the record creation policy or the redundancy policy: designating the first database as a primary database to execute access requests targeting the data record (Sunil: Multi-node database management systems (DBMS), such as PostgreSQL and like technologies, are configured to appoint a so-called “master node” (hereinafter the “principal node”), which intakes writes from one or more applications that write to the DBMS. The principal node is tasked with replicating incoming data to one or more other subordinate “replica nodes” or “standby nodes.” ¶ [0003]. The enhanced data agents include new features that determine what the cluster's present configuration happens to be, including determining which node is the designated principal node, and which nodes are currently operational, i.e., determining the working nodes of the cluster ¶ [0007]-[0009]. The ); and designating the second database as a shadow database to store the shadow copy of the data record and update the shadow copy based on change logs documenting updates to the primary copy of the data record in the first database (Sunil: The system is also suitable for other replicated multi-node systems that feature role changes among nodes ¶ [0005]. Preferably, secondary copies are restored concurrently to all the working nodes, and in this scenario, the media agent associated with the secondary copy/copies establishes a data pipe to each data agent on the working nodes such that the restore operations occur substantially concurrently. After the restore operation is completed, the principal node resumes its role as distributor of new and changed data to the replica nodes ¶ [0009]).
Regarding claim 9, the combination of Sanchez, Muse and Sunil discloses, in response to assigning ownership of the data record to the first database, adding an identifier of the data record to a shadow mode index; and monitoring changes made to a primary copy of each data record in the shadow mode index; in response to detecting a change to a primary copy of a select data record identified in the shadow mode index, propagating the change to a corresponding shadow copy of the data record that is stored in a different database than the primary copy (Sunil: Backup operations can include full backups, differential backups, incremental backups, “synthetic full” backups, and/or creating a “reference copy.” A full backup (or “standard full backup”) in some embodiments is generally a complete image of the data to be protected. However, because full backup copies can consume a relatively large amount of storage, it can be useful to use a full backup copy as a baseline and afterwards only store changes relative to the full backup copy. A differential backup operation (or cumulative incremental backup operation) tracks and stores changes that occurred since the last full backup. Differential backups can grow quickly in size, but can restore relatively efficiently because a restore can be completed in some cases using only the full backup copy and the latest differential copy. An incremental backup operation generally tracks and stores changes since the most recent backup copy of any type, which can greatly reduce storage utilization ¶ [0131]-[0132] and [0260]).
Claim(s) 6, 15 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez in view of Muse in view of Singhal; Prateek (US 12141161 B1) [Singhal].
Regarding claims 6 and 15, the combination of Sanchez and Muse teaches all the limitations of claims 1 and 10.
However neither Sanchez nor Muse explicitly facilitates wherein the first database stores data according to a first database schema and the second database stores data according to a second database schema and wherein propagating the changes to the shadow copy of the data record includes: receiving a change log from the first database, the change log identifying one or more updated values and corresponding database schema components of the first database schema; utilizing a schema mapping to map the one or more updated values of the first database schema to corresponding database schema components of the second database schema; and based on the schema mapping, constructing a write query to update the shadow copy of the data record according to the second database schema.
Singhal discloses, wherein the first database stores data according to a first database schema and the second database stores data according to a second database schema and wherein propagating the changes to the shadow copy of the data record includes: receiving a change log from the first database, the change log identifying one or more updated values and corresponding database schema components of the first database schema; utilizing a schema mapping to map the one or more updated values of the first database schema to corresponding database schema components of the second database schema; and based on the schema mapping, constructing a write query to update the shadow copy of the data record according to the second database schema (Once the change log stream 154 and/or the streaming data 150 is provided to the non-relational to relational database data stream conversion service 102, the data stream conversion engine 140 may use the non-relational database attribute to relational database schema mapping 156 from the schema used to configure 132 the relational database 130 to convert the change log stream 154 to relational database event stream 160 that is associated with the change made to the non-relational database. The data stream conversion engine 140 may utilize a non-relational change log stream to relational event stream conversion 158 to make a replica of changes made to the non-relational database 104 to the relational database 130. In some embodiments, a change to one attribute of an item in the non-relational database 104 may affect a plurality of associated relational database 130 fields for the corresponding entry. In some embodiments, the data stream generated from the change log stream to capture changes happening in non-relational database may occur using an event-based approach wherein the changes take the form of various events reflecting that change. Each event can be processed individually or in batches to transform and then publish the data to the initialized relational database 130, as further discussed in FIG. 5 [col. 6, ll. 35-57]. Also see [col. 12, ll. 9-col. 14, ll. 5], [col. 14, ll. 22-col. 15, ll. 25]).
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of the cited references because Singhal’s system would have allowed Sanchez and Muse to facilitate wherein the first database stores data according to a first database schema and the second database stores data according to a second database schema and wherein propagating the changes to the shadow copy of the data record includes: receiving a change log from the first database, the change log identifying one or more updated values and corresponding database schema components of the first database schema; utilizing a schema mapping to map the one or more updated values of the first database schema to corresponding database schema components of the second database schema; and based on the schema mapping, constructing a write query to update the shadow copy of the data record according to the second database schema. The motivation to combine is apparent in the Sanchez and Muse’s reference, because there is a need to improve relational databases organizing data into a defined schema with one or more tables of columns and rows, with unique keys identifying each row, which may be beneficial for some systems.
Regarding claim 18, the combination of Sanchez, Muse and Singhal discloses clearly show a device for performing the methods of claims 1 and 6. Therefore, the rejection of claims 1 and 6 applies to claim 18.
Regarding claim 19, the combination of Sanchez, Muse and Singhal discloses clearly show a device for performing the methods of claim 3. Therefore, the rejection of claim 3 applies to claim 19.
Regarding claim 20, the combination of Sanchez, Muse and Singhal discloses clearly show a device for performing the methods of claim 5. Therefore, the rejection of claim 5 applies to claim 20.
Conclusion
THIS ACTION IS MADE FINAL. 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 MOHAMMAD S ROSTAMI whose telephone number is (571)270-1980. The examiner can normally be reached Mon-Fri From 9 a.m. to 5 p.m..
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, Boris Gorney can be reached at (571)270-5626. 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.
5/20/2026
/MOHAMMAD S ROSTAMI/Primary Examiner, Art Unit 2154
Prosecution Insights