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 . Claims 1-20 are presented for examination.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/27/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
First of Three Rejections
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8 & 16 of U.S. Patent No. 11,687,519, respectively.
Although the claims at issue are not identical, they are not patentably distinct from each other because the independent claims of the present application are broader than and anticipated by the corresponding independent claims of the reference patent. Claims 1 of the reference patent and claim 1 of the present application are representative of the independent claims of each and are mapped below. The remaining dependent claims are rejected due to their dependency on a rejected independent claim.
USPN 11,687,519 – Claim 1
Application No. 19/311,739 – Claim 1
At least one computer-readable storage medium, excluding transitory signals and carrying instructions to ensure availability and integrity of data associated with a transaction across multiple geographical regions, which, when executed by at least one data processor of a system, cause the system to:
receive, by a first stack operating in a first geographical region, the data associated with the transaction from a user, wherein the data includes an identification (ID) of an item, and a quantity of the item; obtain reference data, wherein the reference data is independent of the data associated with the transaction, and wherein the reference data is independent of the user; obtain context data, wherein the context data is associated with the user, and wherein the context data is independent of the data associated with the transaction;
dehydrate the data associated with the transaction by stripping the data associated with the transaction of derivable data to obtain dehydrated data, wherein the derivable data comprises data that can be derived from the dehydrated data, the context data, and the reference data, and wherein the derivable data comprises a price associated with the item;
stream the dehydrated data to a global database, wherein the global database is available and redundant across the multiple geographical regions including the first geographical region and a second geographical region, and wherein the global database is available to the first stack operating in the first geographical region and a second stack operating in the second geographical region;
obtain an indication that the first stack operating in the first geographical region has failed; and, resume the transaction by the second stack operating in the second geographical region by: retrieving, by the second stack operating in the second geographical region, the dehydrated data from the global database; retrieving the context data and the reference data; hydrating the dehydrated data by recreating the data associated with the transaction based on the dehydrated data, the context data, and the reference data; and resuming the transaction.
A method comprising:
monitoring health metrics associated with multiple service stacks in a distributed service platform;
identifying a failure of a first service stack to process a transaction associated with a user-initiated service request to the distributed service platform;
retrieving, using a second service stack, dehydrated data associated with the transaction from a database,
wherein the dehydrated data is stored during processing of the transaction using the first service stack;
generating, using the second service stack, rehydrated data for the transaction based at least on the dehydrated data; and
resuming, using the second service stack, processing of the transaction using the rehydrated data.
Second of Three Rejections
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8 & 15 of U.S. Patent No. 12,045,226, respectively.
Although the claims at issue are not identical, they are not patentably distinct from each other because the independent claims of the present application are broader than and anticipated by the corresponding independent claims of the reference patent. Claims 1 of the reference patent and claim 1 of the present application are representative of the independent claims of each and are mapped below. The remaining dependent claims are rejected due to their dependency on a rejected independent claim.
USPN 12,045,226 – Claim 1
Application No. 19/311,739 – Claim 1
One or more non-transitory machine-readable storage media, instructions that, when executed by one or more data processors of a system, cause the system to:
receive, by a first stack, data associated with a transaction; separate the data associated with the transaction into derived data and stripped data,
wherein the derived data comprises data that is derived based on the stripped data; send the stripped data to a database, wherein the database is accessed by the first stack and a second stack;
obtain an indication that the first stack has failed; resume, by the second stack, the transaction by: retrieving, by the second stack, the stripped data from the database; recreating the data associated with the transaction based on the stripped data; and resuming the transaction.
A method comprising:
monitoring health metrics associated with multiple service stacks in a distributed service platform;
identifying a failure of a first service stack to process a transaction associated with a user-initiated service request to the distributed service platform;
retrieving, using a second service stack, dehydrated data associated with the transaction from a database,
wherein the dehydrated data is stored during processing of the transaction using the first service stack;
generating, using the second service stack, rehydrated data for the transaction based at least on the dehydrated data; and
resuming, using the second service stack, processing of the transaction using the rehydrated data.
Third of Three Rejections
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 9 & 17 of U.S. Patent No. 12,411,836, respectively.
Although the claims at issue are not identical, they are not patentably distinct from each other because the independent claims of the present application are broader than and anticipated by the corresponding independent claims of the reference patent. Claims 1 of the reference patent and claim 1 of the present application are representative of the independent claims of each and are mapped below. The remaining dependent claims are rejected due to their dependency on a rejected independent claim.
USPN 12,411,836 – Claim 1
Application No. 19/311,739 – Claim 1
A system comprising:
at least one processor; and
at least one memory storing executable instructions that, when executed by the at least one processor, cause the at least one processor to:
implement a first stack of a distributed service platform, the first stack being coupled to a database of the distributed service platform that is further coupled to a second stack of the distributed service platform;
subsequent to the second stack failing to process a transaction, retrieve, by the first stack, a dehydrated data associated with the transaction from the database, the dehydrated data being stored and updated, during a processing of the transaction by the second stack, in the database via a data stream from the second stack to the database;
generate, by the first stack, rehydrated data for the transaction, the rehydrated data comprising the dehydrated data retrieved from the database and derived data that is generated based at least on the dehydrated data; and
resume, by the first stack, the processing of the transaction at the first stack using the rehydrated data, the rehydrated data reducing a data loss time window associated with the second stack failing to process the transaction.
A method comprising:
monitoring health metrics associated with multiple service stacks in a distributed service platform;
identifying a failure of a first service stack to process a transaction associated with a user-initiated service request to the distributed service platform;
retrieving, using a second service stack, dehydrated data associated with the transaction from a database,
wherein the dehydrated data is stored during processing of the transaction using the first service stack;
generating, using the second service stack, rehydrated data for the transaction based at least on the dehydrated data; and
resuming, using the second service stack, processing of the transaction using the rehydrated data.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by “Amazon Aurora: On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes” by Verbitski et al. (published in 2018, hereinafter “Verbitski”).
Verbitski teaches:
1. A method comprising:
monitoring health metrics associated with multiple service stacks in a distributed service platform [Verbitski, page 794, § 4.1, Using Quorum Sets to Change Membership];
identifying a failure of a first service stack to process a transaction associated with a user-initiated service request to the distributed service platform [Verbitski, page 792, Fig. 4 and § 2.4, Crash Recovery in Aurora];
retrieving, using a second service stack, dehydrated data associated with the transaction from a database [Verbitski, page 792, Fig. 4 and § 2.4, Crash Recovery in Aurora],
wherein the dehydrated data is stored during processing of the transaction using the first service stack [Verbitski, page 789, Fig. 1 and § 1, Introduction];
generating, using the second service stack, rehydrated data for the transaction based at least on the dehydrated data [Verbitski, page 792, Fig. 4 and § 2.4, Crash Recovery in Aurora]; and
resuming, using the second service stack, processing of the transaction using the rehydrated data [Verbitski, page 792, Fig. 4 and § 2.4, Crash Recovery in Aurora].
2. The method of claim 1, wherein the distributed service platform includes a gateway that routes incoming transactions to the multiple service stacks [Verbitski, page 793, § 3.2, Scaling Reads Using Read Replicas], and
wherein the method comprises:
determining a routing identifier associated with the transaction [Verbitski, page 793, § 3.2, Scaling Reads Using Read Replicas];
applying a distribution algorithm to determine a service stack to process the transaction [Verbitski, page 793, § 3.2, Scaling Reads Using Read Replicas]; and
routing the transaction to the determined service stack according to configured distribution parameters [Verbitski, page 793, § 3.2, Scaling Reads Using Read Replicas].
3. The method of claim 1, comprising:
distributing incoming transactions among the multiple service stacks [Verbitski, page 793, § 3.3, Structural Consistency in Aurora Replicas];
categorizing the incoming transactions based on transaction attributes [Verbitski, page 793, § 3.3, Structural Consistency in Aurora Replicas]; and
adjusting the distributed incoming transactions based on characteristics of the multiple service stacks [Verbitski, page 793, § 3.3, Structural Consistency in Aurora Replicas].
4. The method of claim 1, comprising:
creating a test service stack [Verbitski, page 794, § 4.1, Using Quorum Sets to Change Membership];
controlling transaction allocation to the test service stack [Verbitski, page 794, § 4.1, Using Quorum Sets to Change Membership]; and
adjusting the transaction allocation based on performance of the test service stack [Verbitski, page 794, § 4.1, Using Quorum Sets to Change Membership].
5. The method of claim 1, wherein said monitoring comprises:
tracking performance indicators of the multiple service stacks [Verbitski, page 794, § 4.1, Using Quorum Sets to Change Membership];
detecting performance issues in the first service stack [Verbitski, page 794, § 4.1, Using Quorum Sets to Change Membership]; and
initiating transfer of the transaction based on said performance issues [Verbitski, page 794, § 4.1, Using Quorum Sets to Change Membership].
6. The method of claim 1, comprising:
distributing incoming transactions among the multiple service stacks based on load balancing parameters [Verbitski, page 795, § 4.2, Using Quorum Sets to Reduce Costs]; and
dynamically adjusting a distribution of the incoming transactions to increase resource utilization across the multiple service stacks [Verbitski, page 795, § 4.2, Using Quorum Sets to Reduce Costs].
7. The method of claim 1, comprising:
generating an identifier for the dehydrated data based on transaction information [Verbitski, page 792, Fig. 4 and § 2.4, Crash Recovery in Aurora];
storing the dehydrated data using the identifier [Verbitski, page 792, Fig. 4 and § 2.4, Crash Recovery in Aurora]; and
performing recovery of the transaction across different service channels of the distributed service platform [Verbitski, page 792, Fig. 4 and § 2.4, Crash Recovery in Aurora].
Claims 8-14 recite limitations similar to those recited in claims 1-7, respectively, and are rejected for the same reasons discussed above.
Claims 15-20 recite limitations similar to those recited in claims 1-6, respectively, and are rejected for the same reasons discussed above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Scott A. Waldron whose telephone number is (571)272-5898. The examiner can normally be reached Monday - Friday 9:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ajay Bhatia can be reached on (571) 272-3906. 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.
/Scott A. Waldron/Primary Examiner, Art Unit 2156
Prosecution Insights