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-20 are pending of which claims 1, 10 and 18 are in independent form.
Claims 10-17 are subject to claim interpretation.
Claims 10-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph.
Claims 1-20 are rejected under 35 U.S.C. 101.
Claims 1-20 are rejected under 35 U.S.C. 103.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“a control layer” in claims 10-17.
The corresponding structure is described in ¶ [0025]-[0027] of the specification, reciting: “The control layer is a logic layer including software components...”, a logical layer maybe interpreted as software. Software components with no detail are generic, like a “module” or “unit”. “The control layer is bidirectionally coupled … over a network” generic network coupling is not an algorithm nor a structure, it’s simply a connective state. “The control layer stores data management policies…” storage of policies is data, not structure nor an algorithm to execute the claimed functional steps. Therefore, regarding Claims 10-17 are subject to 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the limitation “a control layer that…” (placeholder) recites nothing more that a software component performing a list of purely functioning operations without recitation of any corresponding structure in the claims.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 10-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim limitation “a control layer” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function.
As stated in the 35 U.S.C. 112(f) analysis above, the disclosed structures in paragraphs [0025]-[0027] of the Specification fails to disclose sufficient corresponding structure (for computer implemented functions or algorithms) for performing each recited functions. Examiner further specifies that ¶ [0025]-[0027], do not constitute an algorithm or structure implementation for performing claimed functions. The claimed “control layer” is defined exclusively by what it does, NOT what it is. The claims recite a list of high-level operational results. Each one of the steps describe an intended result, there are no indication of and hardware linked to the “control layer” to generate operational results. In the absence of such structural or algorithmics disclosures, the Examiner cannot determine the metes and bounds of the claims with reasonable certainty.
Accordingly, claims 10-17 are indefinite under 35 USC 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph.
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Regarding dependent Claims 11-17, these claims inherit the deficiencies of their parent claims and are therefore also being rejected based upon the same reason(s) stated for their parent claims.
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 10-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Regarding claims 10-17, the claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claims fail to place the invention squarely within one statutory class of invention. More specifically, the claim recites “database storage system comprising: … and a control layer”. In ¶ [0025]-[0027] of the instant specification, applicant has provided evidence that applicant intends the “control layer” to be a software (35 USC 112(f) provoked). As such, the claims lack hardware structure and therefore considered software per se. which is not one of the four statutory categories and therefore rejected under 35 USC 101.
Claims 1-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),
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).
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:
With respect to step 2A, prong one (Judicial Exception):
Selecting an ownership-transfer policy and checking criteria constitutes rule-based decision making, a mental process and organizing human activity which are abstract idea.
With respect to step 2A, Prong Two (Particular Application):
The claim applies the policy using generic logic with no improved ownership transfer mechanism. No technical integration into a practical application.
With respect to Step 2B:
The ownership criteria evaluation is a routine, conventional operation in distributed systems (e.g. leader transition rules), therefore it does not provide any inventive concept.
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-14 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over TELAGAMSETTI; Sunil Babu et al. (US 20250077358 A1) [Sunil] in view of Chercoles Sanchez; Jose Maria et al. (US 20130151558 A1) [Sanchez].
Reading claims 1 and 10, Sunil discloses, a method comprising: receiving, at a hybrid database storage system, a write request for a data record (multi-node database management systems (DBMS), such as PostgreSQL, and/or the technologies enumerated above without limitation, are configured to appoint a principal node, which intakes writes from one or more applications (e.g., 110) that write to the DBMS. ¶ [0225]. Also see ¶ [0227] and [0237]. Examiner hereby specifies that PostgreSQL is considered a hybrid database system, also multi-node or multi-modal database management systems are also considered hybrid database systems);
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 (multi-node database management systems (DBMS), such as PostgreSQL, and/or the technologies enumerated above without limitation, are configured to appoint a principal node, which intakes writes from one or more applications (e.g., 110) that write to the DBMS. ¶ [0225]. Also see ¶ [0227] and [0237]);
writing a primary copy of the data record to the first database of the hybrid database storage system (client computing device(s) 102 and corresponding applications 110 may create, access, modify, write, delete, and otherwise use primary data 112. Primary data 112 is generally in the native format of the source application 110. Primary data 112 is an initial or first stored body of data generated by the source application 110 ¶ [0077]. At step 1, the source data agent(s) 242a and source media agent(s) 244a work together to write backup or other secondary copies of the primary data generated by the source client computing devices 202a into the source secondary storage device(s) 208a ¶ [0206]);
[while the first database retains ownership of the data record], detecting changes to the primary copy of the data record made in the first database and propagating the changes to a shadow copy of the data record to a second database of the hybrid database storage system (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]. 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 [0140]).
However, Brodt does not explicitly facilitate assigning ownership of the data record to a first database; while the first database retains ownership of the data record; transferring ownership of the data record from the first database to the second database; and subsequent to transferring ownership, directing updates to the data record to the second database.
Sanchez discloses, assigning ownership of the data record to a first database; while the first database retains ownership of the data record (The processor is configured to fulfil the data request using a version of the data instance that is stored by a database instance of the distributed database that has been assigned ownership of the data instance [Abstract]. Also see ¶ [0010]-[0016]);
transferring ownership of the data record from the first database to the second database (In this regard, an original data instance is the first occurrence of a data instance to be stored in the distributed database, a replica data instance is a replica of an original data instance generated in accordance with a replication policy implemented by the distributed database, and a copy data instance, a copy data instance being a copy of a data instance generated as a result of a transfer of ownership of the data instance ¶ [0013]. Also see ¶ [0016], [0018], [0040], [0101]-[0102], [0107], [0124]-[0126]);
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]).
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of the cited references because Sanchez’s system would have allowed Sunil to facilitate assigning ownership of the data record to a first database; while the first database retains ownership of the data record; transferring ownership of the data record from the first database to the second database; and subsequent to transferring ownership, directing updates to the data record to the second database. The motivation to combine is apparent in the Sunil’s reference, because there is a need to improve operating a distributed database that optimizes the distribution of data among the nodes of the distributed database.
Regarding claim 2, the combination of Sunil and Sanchez discloses, identifying, from a plurality of stored ownership transfer policies, an ownership transfer policy that applies to the data record and that defines one or more ownership transfer criteria (Sanchez: In order to determine if ownership of the data instance should be transferred to a local database instance, the processor may be further configured to evaluate an ownership policy. The node may then further comprise a memory configure to store the ownership policy that is to be evaluated by the processor. The ownership policy may including one or more of conditions relating to the data instance, conditions relating to the current owner database instance, conditions relating to local database instances, and conditions relating to the overall status of the distributed database ¶ [0015]. An ownership policy can then be implemented by the distributed database that must be evaluated in order to determine if ownership of a data instance should be transferred from the database instance currently assigned/allocated ownership of a data instance to a different database instance. On this basis, if it is determined that ownership of a data instance should be transferred to a database instance that does not already store a version of data instance, then the data instance is copied to the database instance to which ownership is to be transferred. 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 optimised, thereby reducing the response times and bandwidth usage of the distributed database ¶ [0040]); and
transferring the ownership of the data record in response to determining the one or more ownership transfer criteria are satisfied for the data record (Sanchez: An ownership policy can then be implemented by the distributed database that must be evaluated in order to determine if ownership of a data instance should be transferred from the database instance currently assigned/allocated ownership of a data instance to a different database instance. On this basis, if it is determined that ownership of a data instance should be transferred to a database instance that does not already store a version of data instance, then the data instance is copied to the database instance to which ownership is to be transferred. 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 optimised, thereby reducing the response times and bandwidth usage of the distributed database ¶ [0040]. Also see ¶ [0086], [0102], [0151], [0177]).
Regarding claims 3, 11 and 12, the combination of Sunil and Sanchez discloses, 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]).
Regarding claims 4 and 13, the combination of Sunil and Sanchez 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 claims 5 and 14, the combination of Sunil and Sanchez discloses, evaluating one or more characteristics of the data record to identify an ownership transfer policy applicable to the data record from a plurality of ownership transfer policies defined for different data records in the hybrid database storage system, the ownership transfer policy defining the ownership transfer criteria for 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 optimised, 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 Sunil and Sanchez 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 Sunil and Sanchez 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]).
Regarding claim 9, the combination of Sunil and Sanchez 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 Sunil in view of Sanchez in view of Singhal; Prateek (US 12141161 B1) [Singhal].
Regarding claims 6 and 15, the combination of Sunil and Sanchez teaches all the limitations of claims 1 and 10.
However neither Sunil nor Sanchez 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 Sunil and Sanchez 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 Sunil and Sanchez’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 Sunil, Sanchez 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 Sunil, Sanchez 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 Sunil, Sanchez 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
The examiner requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
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.
11/15/2025
/MOHAMMAD S ROSTAMI/ Primary Examiner, Art Unit 2154
Prosecution Insights