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 .
This action is responsive to application filed on 12/18/2024. Claims 1-20 are presented for examination.
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.
Claim(s) 1-3 and 13-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Dye et al (USPN. 20220229829).
Regarding claim 1, Dye discloses a tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors effectuate operations comprising (fig. 1, system, Dye):
updating, by a computing system and based on a database update, database data stored in a database within a multi-tenant environment, wherein the database data stored in the database includes tenant data that is associated with one or more tenants and respective tenant data for a respective tenant is maintained by one or more participant nodes as one or more respective database replicas of the respective tenant data (fig. 1, items 132 and 136, pars. 32-33, update sequence is updated and replica update is delayed by the system and applier 136 prior to updating replica database 140, and multiple provider network using lagging data replicas, par. 36);
generating, the computing system, one or more database update messages, wherein each database update message is generated with respect to each tenant for which there are database events corresponding to that tenant since a last transmitted database update message for that tenant (fig. 1, par. 32, multi-message conversation between the update sender and update applier with respect to replicating data); and
transmitting, the computing system, the one or more database update messages to one or more participant nodes that maintain a data replica for the respective tenant identified in the one or more database update messages (fig. 1 and 2, par. 32, multi-message conversation between the update sender and update applier with respect to replicating data are transmitted. See also pars. 37, 39 and 41 embodiment of plurality of clients and nodes such as provider network regions 200a and 200b).
2. Dye discloses the tangible, non-transitory, machine-readable medium of claim 1, wherein the computing system is a centralized node of the multi-tenant environment (fig. 1-3, pars. 47-48, database management may be internal/central validator or external/other service).
3. Dye discloses the tangible, non-transitory, machine-readable medium of claim 1, wherein database update may include a plurality of database events occurring between a last database update (fig. 1, items 132 and 136, pars. 32-33, update sequence is updated, sequence comprises a plurality of events).
Regarding claim 13, Dye discloses a tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors effectuate operations comprising (fig. 1, system, Dye):
receiving, by a computing system that maintains a first database replica for a first tenant, a first database update message, wherein the first database replica for the first tenant is a replica of first tenant data of the first tenant stored in a database within a multi-tenant environment that is maintained by a centralized node, wherein the first database update message includes database events corresponding to the first tenant data for the first tenant since a last transmitted database update message for the first tenant, and wherein the database events include block information (fig. 1 and 2, items 132 and 136, pars. 32-33, multi-message conversation, update sequence is updated at primary DB 120 and replica update is delayed by the system and applier 136 prior to updating target replica database 140 or lagging data replicas in multiple provider network, see par. 36.);
updating, by the computing system, first database replica tenant data in the first database replica based on the database events in the first database update message corresponding to the first tenant associated with the first database replica (fig. 1, items 132 and 136, pars. 32-33, update sequence is updated and replica update is delayed by the system and applier 136 prior to updating replica database 140, and multi-message conversation between the update sender and update applier with respect to replicating data);
in response to determining there is a block update in the block information provided in the database events, verifying, by the computing system, whether a database replica data state matches that of a database data state of the database maintained by the centralized node and included in the block information (fig. 1, validator 160, see par. 45 and 92, validating data blocks, metadata associated with data blocks and their state is maintained and update sequence is performed in real-time or delayed, and pars. 47-48, database management may be internal/central validator or external/other service); and
in response to determining that the database replica data state does not match the database data state, transmitting a message to the centralized node to resend a block of database events transmitted in the first database update message for the first tenant since a last block update (pars. 32 and 39, update may be questionable or invalid, when the update becomes validated based on the delay the message would be resend, note that state is maintained and update sequence is performed in real-time or delayed, Dye).
14. Dye discloses the tangible non-transitory, machine-readable medium of claim 13, wherein the operations further comprise: unwinding, by the computing system, one or more operations performed within the first database replica to return the first database replica to a prior state of the last block update; receiving, by the computing system, the block of database events transmitted in the first database update message for the first tenant since the last block updated; and updating, by the computing system, the first database replica at the prior state with the database events since the last block update (par. 32 and 92, “multi-message conversation between the update sender 132 and update applier 136”, delay replica, “transaction log”, “redo” “information used in performing functions of the distributed storage systems”, store data blocks and replicas of data blocks, metadata associated with data blocks and their state, teach communicating and going back and forth on different storages based on configuration and policies, Dye).
15. Dye discloses the tangible, machine-readable medium of claim 14, wherein the database replica data state includes a tenant hash that is a hash determined based on before values and after values performed on the first database replica tenant data since the last block update, and the database data state includes a component tenant hash determined by the centralized node that was based on before values and after values of the first tenant data at the database since the last block update (par. 45 and 92, metadata associated with data blocks and their state is equated to incrementing a block number of a block and header for the block. Note that status update of a block and any information anticipates relevant data for performing the system method, Dye. Dye also teaches journal entries to comprise a hash for updates and transacting).
16. Dye discloses the tangible, non-transitory, machine-readable medium of claim 13, wherein the block information is cryptographically signed with a private key by the centralized node to include a signature and the operations further comprise par. 28, hash/keys are used for cryptographic encoding, Dye):
verifying, by the computing system, the signature with a public key this is a key pair with the private key (par. 28, match and verification to validate update sequence using cryptographic encoding, this requiress key/signature comparison).
17. Dye discloses the tangible, non-transitory, machine-readable medium of claim 13, wherein the operations further comprise: updating block information in one or more block tables with the block information received in the first database update message (par. 45, writing to data blocks, comprises updates to rows in a database table, and par. 32, interactive messaging, Dye).
18. Dye discloses the tangible, non-transitory, machine-readable medium of claim 13, wherein the computing system is a participant node of the multi-tenant environment (pars. 32 and 36, multi-message multi provider network, Dye).
19. Dye discloses the tangible, non-transitory, machine-readable medium of claim 13, wherein the operations further comprise: receiving, by the computing system that maintains a second database replica for a second tenant, a second database update message, wherein the second database replica for the second tenant is a replica of second tenant data of the second tenant stored in the database that is maintained by the centralized node, and wherein the second database update message includes database events corresponding to the second tenant data for the second tenant since a last transmitted database update message for the second tenant (fig. 2, 8, pars. 32, 36 and 72, “another secondary database”, replication and validation, Dye); and updating, by the computing system, second replica tenant data in the second database replica based on the database events in the second database update message corresponding to the second tenant associated with the second database replica (pars. 32, 36 and 72, multi-message provider and update validator B, Dye).
20. Dye discloses a method, comprising:
receiving, by a computing system that maintains a first database replica for a first tenant, a first database update message, wherein the first database replica for the first tenant is a replica of first tenant data of the first tenant stored in a database within a multi-tenant environment that is maintained by a centralized node, wherein the first database update message includes database events corresponding to the first tenant data for the first tenant since a last transmitted database update message for the first tenant, and wherein the database events include block information (fig. 1 and 2, items 132 and 136, pars. 32-33, multi-message conversation, update sequence is updated at primary DB 120 and replica update is delayed by the system and applier 136 prior to updating target replica database 140 or lagging data replicas in multiple provider network, see par. 36);
updating, by the computing system, first database replica tenant data in the first database replica based on the database events in the first database update message corresponding to the first tenant associated with the first database replica (fig. 1, items 132 and 136, pars. 32-33, update sequence is updated and replica update is delayed by the system and applier 136 prior to updating replica database 140, and multi-message conversation between the update sender and update applier with respect to replicating data);
in response to determining there is a block update in the block information provided in the database events, verifying, by the computing system, whether a database replica data state matches that of a database data state of the database maintained by the centralized node and included in the block information; (fig. 1, validator 160, see par. 45 and 92, validating data blocks, metadata associated with data blocks and their state is maintained and update sequence is performed in real-time or delayed, and pars. 47-48, database management may be internal/central validator or external/other service); and
in response to determining that the database replica data state does not match the database data state, transmitting a message to the centralized node to resend a block of database events transmitted in the first database update message for the first tenant since a last block update (pars. 32 and 39, update may be questionable or invalid, when the update becomes validated based on the delay the message would be resend, note that state is maintained and update sequence is performed in real-time or delayed, Dye).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 4-12 are rejected under 35 U.S.C. 103 as being unpatentable over Dye et al (USPN. 20220229829) in view of Giliyaru et al (USPN. 2024/0330315).
Regarding claim 4, Dye teaches the tangible, non-transitory, machine-readable medium of claim 1 as rejected above, and further teaches wherein the transmitting the one or more database update messages to the one or more participant nodes causes each participant node to (fig. 1 and 2, par. 32, multi-message conversation between the update sender and update applier with respect to replicating data are transmitted. See also pars. 37, 39 and 41 embodiment of plurality of clients and nodes such as provider network regions 200a and 200b) and updates a database replica ((fig. 1, items 132 and 136, pars. 32-33, update sequence is updated and replica update is delayed by the system and applier 136 prior to updating replica database 140) but does not explicitly teach the updating a database replica is associated with a tenant identified in a database update message of the one or more participant nodes received by that participant node based on the database events in the database update message corresponding to the tenant associated with the database replica. However, Giliyaru teaches updating a database replica is associated with a tenant identified in a database update message of the one or more participant nodes received by that participant node based on the database events in the database update message corresponding to the tenant associated with the database replica (fig. 1, par. 35, “orchestrater services can receive and aggregate event messages… according to event types, entity identifiers, tenant identifiers”. Tenants can refer to enterprises that utilize the management services, Giliyaru). It would have been obvious to one of ordinary skill in the art at the effective filing date of the application to include tenant identifiers and integrate orchestrator service 136 in Dye replication system by including the functionality of the orchestrator in Dye validation system (fig. 1 and 2, replication process and validation system, Dye). One would have been motivated to replicate events to each confirmed entity type and tenant identifier (fig. 4, par. 63-64, orchestrator service can replicate event data to relevant replication pipelines, Giliyaru).
5. Dye in view of Giliyaru teach the tangible, non-transitory, machine-readable medium of claim 4, wherein the operations further comprise :in response to determining that a block update condition is satisfied, determining block header data and other information for updating one or more block tables and updating a block information in the one or more block tables (pars. 45 and 92, block data and replicas of block data and associated metadata with the blocks and state comprise header information/identifier and is stored and updated upon validation, Dye).
6. Dye in view of Giliyaru teach the tangible, non-transitory, machine-readable medium of claim 5, wherein the database events include the update to the block information in the one or more block tables (par. 45, writing to data blocks, comprises updates to rows in a database table, Dye).
7. Dye in view of Giliyaru teach the tangible non-transitory, machine-readable medium of claim 5, wherein the updating the block information in the one or more block tables includes an update to a block data table indicating an increment in a block number of a block and an update to a block header table to indicate block header data for the block (par. 45 and 92, metadata associated with data blocks and their state is equated to incrementing a block number of a block and header for the block. Note that status update of a block and any information anticipates relevant data for performing the system method, Dye).
8. Dye in view of Giliyaru teach the tangible non-transitory, machine-readable medium of claim 7, wherein the block header data for the block may include a state hash and a plurality of component tenant hashes on which the state hash is based, wherein each tenant hash of the plurality of component tenant hashes is based on a running sum of hashes of before and after data values from a subset of database events identified as associated with that tenant for the block (par. 45 and 92, metadata associated with data blocks and their state is equated to incrementing a block number of a block and header for the block. Note that status update of a block and any information anticipates relevant data for performing the system method, Dye. Dye also teaches journal entries to comprise a hash for updates and transacting).
9. Dye in view of Giliyaru teach the tangible, non-transitory, machine-readable medium of claim 8, wherein the block header data is signed with a private key of a key pair using a cryptographic signature algorithm (see claim 8 rejection above regarding block header data, and see par. 28, hash/keys are used for cryptographic encoding, Dye).
10. Dye in view of Giliyaru teach the tangible, non-transitory, machine-readable medium of claim 6, wherein the transmitting the one or more database update messages to the one or more participant nodes causes each participant node to: in response to determining there is a block update in the block information provided in the database events, verify whether a database replica data state matches that of the database (fig. 1, validator 160, see par. 45 and 92, validating data blocks, metadata associated with data blocks and their state is maintained and update sequence is performed in real-time or delayed, Dye).
11. Dye in view of Giliyaru teach the tangible, machine-readable medium of claim 10, wherein the operations further comprise: receiving, by the computing system, a message to resend a block, from a participant node in response to that participant node determining that the database replica data state does not match that of the database (pars. 32 and 39, update may be questionable or invalid, when the update becomes validated based on the delay the message would be resend, Dye, in view of fig. 1, par. 35, “orchestrator services can receive and aggregate event messages… according to event types, entity identifiers, tenant identifiers”. Tenants and event types require multiple messaging, Giliyaru).
12. Dye in view of Giliyaru teach the tangible, machine-readable medium of claim 10, wherein the operations further comprise steps for: identifying a participant node associated with the tenant data (par. 35, specific event and Tenants are tagged using particular set of entity identifiers and set of tenant identifiers in environment, Giliyaru).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARCIN R FILIPCZYK whose telephone number is (571)272-4019. The examiner can normally be reached M-F 7-4 EST.
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, Kavita Stanley can be reached at 571-272-8352. 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.
January 8, 2026
/MARCIN R FILIPCZYK/Primary Examiner, Art Unit 2153