DETAILED ACTION
Response to Amendment
This communication is in response to the amendment filed on 07/07/2026 for application 18/903,910. Claims 1-20 are pending in this application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicants’ arguments filed with respect to claim 12 have been fully considered but they are moot in view of new rejection. After further research and a thorough examination of the present application, claims 12-17 remain rejected.
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.
Claims 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Kaitha (US 2023/0246918 A1) in view of Muthyala et al (US 2015/0269032 A1) further in view of Jolfaei (US 2017/0017677 A1).
As per claim 12, Kaitha teaches an apparatus, comprising: one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to cause the apparatus to (see Fig. 5 and paragraphs [0063]-[0066], e.g., computing system 500 includes processor 520, memory 530, communication component 560, and computer-readable instructions/components configured to perform the disclosed message-management and event-monitoring operations):
receive, by a destination system and from a source system via a network, a pull notification that indicates an event is being performed in the source system (see paragraphs [0030], [0033], [0048], [0056]-[0060], e.g., the message management system 410, corresponding to the destination system, monitors an event source system 430, corresponding to the source system; paragraph [0033] expressly teaches querying the event source system to “pull the event notification from the event source system”; paragraph [0048] teaches that an update is processed by the event source system and that the event source system may process an event associated with the status; and Fig. 4/paragraphs [0056]-[0060] show message management system 410 and event source system 430 communicating through network 440);
retrieve, by the destination system and from the source system via the network based at least in part on the pull notification, data that is modified by the event in the source system, wherein the pull notification indicates a type of the event that is being performed in the source system (see paragraphs [0033], [0035], [0048], e.g., paragraph [0033] teaches querying the event source system to pull an event notification and receiving a response from the event source system; paragraph [0035] teaches the message management system determining an update based on a characteristic of the event and teaches that returned event information may identify a change to a status, a change to a parameter associated with providing a service, and a characteristic including a “type of the event”; paragraph [0048] teaches that the event source system processes an event and an associated update, including adding a new record to a record log associated with occurrence of the event, and that the message management system detects the source-side update);
Kaitha does not explicitly teach wherein the destination system is operable to provide backup and recovery services for the source system, and wherein the destination system is within a cloud computing environment and the source system comprises a computing system;
However, Muthyala teaches wherein the destination system is operable to provide backup and recovery services for the source system, and wherein the destination system is within a cloud computing environment and the source system comprises a computing system ([0021], e.g., wherein discloses an environment system 100 in which data backup and recovery to and from a cloud storage service can be implemented, the environment system 100 includes a storage server 105 that can back up data from a primary storage system 110 to a destination storage system 115, the storage server 105 can also recover data from the destination storage system 115 to restore the primary storage system 110 and [0029], e.g., a networked storage system for backing up and restoring data to and from a cloud storage service).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Muthyala with the teachings of Kaitha in order to efficiently enable a destination system receiving pulled event information from a source computing system to provide cloud-based backup and recovery services for the source system, thereby allowing event-related source updates to be identified and maintained at a remote cloud backup destination (Muthyala).
Kaitha and Muthyala do not explicitly teach synchronize, by the destination system, a database of the destination system based at least in part on the data retrieved from the source system.
However, Jolfaei teaches synchronize, by the destination system, a database of the destination system based at least in part on the data retrieved from the source system (see paragraph [0046], e.g., destination system 106 includes memory 136 storing database tables and database-related information; paragraph [0052], e.g., event bridge 222 replicates information among systems and keeps the information “in sync across affected systems,” including automatically synchronizing persisted business objects; and paragraphs [0066]-[0069], e.g., a changed data object is requested in response to an event notification, the request is provided to backend/source system 104, the changed/updated data is provided from the source, and the updated data is supplied to the target/destination system).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Jolfaei with the teachings of Kaitha and Muthyala in order to efficiently enable the destination system to synchronize its database using changed data retrieved from the source system in response to event information, thereby maintaining source-side changes in synchronization with the corresponding data stored at the remote cloud backup destination (Jolfaei).
As per claim 13, wherein receiving the pull notification is based at least in part on input, to the source system, that triggers the event in the source system ([0031]-[0035], e.g., teaches that the event may involve a user interacting with the user account and specifically teaches detecting an event based on a user input, such as an input to make a payment or to update the user's location/authorized area. It further teaches that the event source system processes event information associated with such activity, and that the message-management system may query the event source system to pull the event notification, Kaitha).
As per claim 14, wherein: the pull notification comprises metadata that indicates an identifier of the event, a type of the event, a time associated with the event, a size of the data changed by the event, or any combination thereof; and retrieving the data is based at least in part on the metadata ([0035] teaches that the response/event information can identify characteristics including when the event occurred and a type of the event, together with changes to status/service parameters. Because the claim is written using “or any combination thereof,” disclosure of the event type and/or time is sufficient for the listed metadata alternatives, Kaitha).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Kaitha (US 2023/0246918 A1) in view of Muthyala et al (US 2015/0269032 A1) in view of Jolfaei (US 2017/0017677 A1) further in view of Bapat et al (US 2020/0117680 A1).
As per claim 15, Kaitha, Muthyala and Jolfaei do not explicitly teach wherein: the pull notification comprises metadata that identifies the data and the metadata indicates rows or tables of a database of the source system that are modified by the event.
However, Bapat teaches wherein: the pull notification comprises metadata that identifies the data and the metadata indicates rows or tables of a database of the source system that are modified by the event (see paragraph [0096], discloses that the information flow includes an event path carrying change metadata (information defining changes having been made in the source repository 110), while the corresponding data content is pulled or retrieved from the source repository and [0097]-[0101], disclose an example in which rows are inserted into a table of the source repository and the event includes information describing that change).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Bapat with the teachings of the Kaitha, Muthyala and Jolfaei in order to efficiently identify, in event metadata, the particular database table and rows modified by a source-side event so that the destination system can use the metadata to selectively retrieve the corresponding changed data from the source system (Bapat).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Kaitha (US 2023/0246918 A1) in view of Muthyala et al (US 2015/0269032 A1) in view of Jolfaei (US 2017/0017677 A1) further in view of Mikolajczuk et al (US 11,539,791 B1).
As per claim 16, Kaitha, Muthyala and Jolfaei do not explicitly teach wherein the one or more processors are individually or collectively further operable to execute the code to cause the apparatus to: generate a data synchronization request based at least in part on the pull notification, wherein the data synchronization request comprises metadata associated with the event and publish the data synchronization request to a message queue supported by the destination system, wherein retrieving the data from the source system is based at least in part on retrieving the data synchronization request from the message queue.
However, Mikolajczuk teaches wherein the one or more processors are individually or collectively further operable to execute the code to cause the apparatus to: generate a data synchronization request based at least in part on the pull notification, wherein the data synchronization request comprises metadata associated with the event and publish the data synchronization request to a message queue supported by the destination system, wherein retrieving the data from the source system is based at least in part on retrieving the data synchronization request from the message queue (see col.32, lines 1–10, e.g., discloses that the synchronization request message may be stored in an outbound message queue table object and that the in-cloud application service system may retrieve the synchronization request message from the outbound message queue table and transmit the synchronization request to the on-premises application service system, col.63, lines 1-25 and col.64, lines 35-48, discloses that the in-cloud application service system receives in-cloud data object update metadata and that the update metadata indicates “one or more edits, updates, and/or changes” associated with an in-cloud data object and add[s] the synchronization request message to the outbound message queue table object of the in-cloud application service system).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Mikolajczuk with the teachings of the Kaitha, Muthyala and Jolfaei in order to efficiently generate a data synchronization request based on event/update information obtained from the source-system notification, include metadata identifying the data to be synchronized, publish the synchronization request to a message queue supported by the destination system, retrieve the synchronization request from the queue, and use the retrieved synchronization request to identify and retrieve the corresponding data from the source system (Mikolajczuk).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Kaitha (US 2023/0246918 A1) in view of Muthyala et al (US 2015/0269032 A1) in view of Jolfaei (US 2017/0017677 A1) further in view of Mukku et al (US 2022/0091942 A1).
As per claim 17, Kaitha, Muthyala and Jolfaei do not explicitly teach wherein, to retrieve the data from the source system, the one or more processors are individually or collectively operable to execute the code to cause the apparatus to: retrieve the data from the source system in accordance with metadata associated with the data, wherein the metadata comprises a snapshot metadata format based at least in part on the event being associated with a snapshot.
However, Mukku teaches wherein, to retrieve the data from the source system, the one or more processors are individually or collectively operable to execute the code to cause the apparatus to: retrieve the data from the source system in accordance with metadata associated with the data, wherein the metadata comprises a snapshot metadata format based at least in part on the event being associated with a snapshot (see paragraph [0114], discloses receiving an instruction to back up a snapshot and teaches that the instruction may include an identifier of the storage unit and an identifier of the snapshot to be backed up and paragraph [0127] teaches receiving an instruction to restore a subject snapshot and evaluating snapshot metadata of the subject snapshot identifier to identify VSIDs of deleted segments and paragraphs [0129]-[0130] teach identifying the requested segments using snapshot metadata and restoring the identified segments).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Mukku with the teachings of the Kaitha, Muthyala and Jolfaei in order to efficiently retrieve data using metadata associated with the data when the source-side event is associated with a snapshot, wherein the metadata provides a snapshot-specific format identifying the snapshot and the data segments corresponding to that snapshot (Mukku).
Reasons for Allowance
The following is an examiner’s statement of reasons for allowance:
The prior art made of record does not teach or fairly suggest the combination of elements as recited in independent claims 1 and 18.
The prior art Muthyala disclosed for backing up data to and recovering data from a destination storage system that stores data in a format different form that of a primary storage system ("the technology"). A replication stream having the data of multiple files, metadata of the files, and reference maps including a mapping of the corresponding file to a portion of the data of the corresponding file is generated at the primary storage system. The replication stream is sent to a parser to map or convert the data, the files, and the reference maps to multiple storage objects in a format the destination storage system is configured to store. Various types of storage objects are generated, including a first type of the storage objects having the data, a second type of storage objects storing the reference maps, and a third type of the storage objects storing metadata of the files. Prior art, Jayanti Venkata disclosed for communicating to remote devices information about change events related to changes in access to an enterprise system. A device access management system may facilitate communication about a change event to the remote devices. Information about a change event may be stored in a change event object based on the type of change event (e.g., a policy change, an application change, and a settings change). A change event queue may persistently store information corresponding to change events. One or more computing nodes may be scheduled to execute an action process for each change event based on the type of the change event. A computing node may communicate information (e.g., an instruction to implement adjust access) about a change event to remote devices. A change event may persist on the queue until all remote devices are notified about the change event. However, more specifically, the prior art made of record does not specifically suggest the combination of “transmit, by a destination system and to a source system via a network, a push notification that indicates a request to initiate an event in the source system and that indicates metadata associated with the event, wherein the destination system is operable to provide backup and recovery services for the source system, and wherein the destination system is within a cloud computing environment and the source system comprises a computing system; transmit, by the destination system and to the source system via the network based at least in part on the push notification, a status request for status information that indicates a status of the event being performed in the source system; retrieve, by the destination system and from the source system via the network in accordance with the status of the event and using the metadata associated with the event, data that is modified by the event; and synchronize, by the destination system, a database of the destination system based at least in part on the data retrieved from the source system” in combination with all the other limitations in the independent claims 1 and 18. The scope of the independent claim is allowable because the complete scope of the claims is not found to be taught in the prior art. These features together with other limitations of the independent claims are novel and non- obvious over the prior art of record. The dependent claims being definite, enabled by the specification, and further limiting to the independent claims are also allowable.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohammad A Sana whose telephone number is (571)270-1753. The examiner can normally be reached Monday-Friday 9-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sanjiv Shah can be reached at 5712724098. 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.
/Mohammad A Sana/Primary Examiner, Art Unit 2166
Prosecution Insights