DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/02/2026 has been entered. Claims 1, 12 and 18 have been amended. 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 .
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 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Muthyala et al (US 2015/0269032 A1) in view of Jayanti Venkata et al (US 2016/0087854 A1).
As per claim 1, Muthyala 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:
transmit, by a destination system and to a source system via a network, 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);
Muthyala does not explicitly teach a push notification that indicates a request to initiate an event in the source system and that indicates metadata associated with the event; 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.
However, Jayanti Venkata teaches a push notification that indicates a request to initiate an event in the source system ([0010], e.g., the device access management system communicate a change event to remote devices using a notification service (e.g., a push notification service)) and that indicates metadata associated with the event ([0097], e.g., a change event object may include metadata that identifies the change event);
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 ([0117], [0207], e.g., computing node 222-1 may transmit result information 342 indicating a result of action process 1 for change event 1, result information 342 may indicate a status of acknowledgement regarding action process 1 for endpoint devices identified in change event entry 302 and network(s) 1010 facilitate communications and exchange of data between client computing devices and cloud infrastructure 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 ([0074], [0097], e.g., for each of the change event entries on change event queue 124, one or more of servers 122 may be requested by device access management system 120 to initiate an action process, an action process may be initiated for a type of change event corresponding to the action process class for that type of change event, the action process class may include communicating information about a change event (e.g., the change event object) to remote devices affected by a change corresponding to the change event, a change event object may include metadata that identifies the change event and [0095], e.g., the communication system may communicate with remote devices via one or more communication networks); 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 ([0071], e.g., device access management system 120 may schedule one or more servers 122 to execute an action process for each change event identified on change event queue, the information about the change event may be communicated asynchronously to the remote devices).
Thus, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to apply the teachings of Jayanti Venkata with the teachings of Muthyala in order to efficiently enabling a system to communicate information about a change event to remote devices in an asynchronous manner (Jayanti Venkata).
As per claim 2, wherein the one or more processors are individually or collectively further operable to execute the code to cause the apparatus to: receive, by the destination system, input that triggers the event in the source system, wherein transmitting the push notification is based at least in part on receiving the input by the destination system ([0010], e.g., the device access management system may communicate a change event to remote devices using a notification service (e.g., a push notification service, Jayanti Venkata).
As per claim 3, wherein the one or more processors are individually or collectively further operable to execute the code to cause the apparatus to: generate, by the destination system based at least in part on the push notification, the status request comprising the metadata associated with the event ([0010], [0097], [0116], e.g., the device access management system may communicate a change event to remote devices using a notification service (e.g., a push notification service), a status of a change event in change event entry, a change event object may include metadata that identifies the change event, Jayanti Venkata).
As per claim 4, wherein the one or more processors are individually or collectively further operable to execute the code to cause the apparatus to: publish the status request to a message queue supported by the destination system, wherein transmitting the status request to the source system for the status information is based at least in part on retrieving the status request from the message queue ([0104], e.g., device access management system 120 may implement change event queue 124 to manage change events in a persistent fashion to ensure that remote devices affected by change events are notified, Jayanti Venkata).
As per claim 5, wherein the one or more processors are individually or collectively further operable to execute the code to cause the apparatus to: store, after generating the status request, the status request in the database of the destination system; and retrieve the status request from the database of the destination system, wherein transmitting the status request to the source system for the status information is based at least in part on retrieving the status request from the database of the destination system ([0074], [0097], e.g., for each of the change event entries on change event queue 124, one or more of servers 122 may be requested by device access management system 120 to initiate an action process, an action process may be initiated for a type of change event corresponding to the action process class for that type of change event, the action process class may include communicating information about a change event (e.g., the change event object) to remote devices affected by a change corresponding to the change event, a change event object may include metadata that identifies the change event, Jayanti Venkata).
As per claim 6, wherein the metadata indicates a type of the event, an identifier of the event, a periodicity associated with the event, or any combination thereof ([0134], e.g., the metadata may include data obtained from a change event entry, a change event object may be created by instantiating a change event class for a type of change event, a data structure 510 representing a change event object may include the type of information defined by the change event class that was instantiated, Jayanti Venkata).
As per claim 7, wherein, to retrieve the data, the one or more processors are individually or collectively operable to execute the code to cause the apparatus to: retrieve the data during execution of the event in the source system based at least in part on the status information indicating that the event is pending and based at least in part on a type of the event indicated via the metadata ([0138], e.g., the change event status may include, pending, retry, or acknowledged, Jayanti Venkata).
As per claim 8, wherein: the status information indicates a time duration for which the event has been pending at the source system; and the type of the event comprises an incremental even associated with changes to the data incrementally over time while the event is pending ([0146], e.g., the change event status may include, pending, retry, and acknowledged, Jayanti Venkata).
As per claim 9, wherein, to retrieve the data, the one or more processors are individually or collectively operable to execute the code to cause the apparatus to: retrieve the data after a completion of the event based at least in part on the status information indicating that the event is complete and a type of the event indicated via the metadata ([0110], [0119], e.g., a change event object for change event 1 may include persisted metadata that defines the change event 1 in a change event entry, result information 346 may indicate that action process 1 was completed for change event entry 304, Jayanti Venkata).
As per claim 10, wherein, to transmit the status request, the one or more processors are individually or collectively operable to execute the code to cause the apparatus to: transmit, in accordance with polling the source system for the status information, a plurality of status requests in accordance with a periodicity, wherein the periodicity is based at least in part on previous data synchronization scenarios ([0140], e.g., the retry configuration may indicate the number of times the action process may be attempted, a computing node and device access management system 120 may use retry configuration to determine whether to invoke an action process again for a change event that was not acknowledged by a remote device, Jayanti Venkata).
As per claim 11, wherein, to poll the source system for the status information, the one or more processors are individually or collectively operable to execute the code to cause the apparatus to: poll the source system in accordance with the periodicity for a first time period and poll the source system in accordance with a second periodicity different than the periodicity for a second time period after the first time period ([0080], e.g., each of change events 1-3 may occur at different times, a change event entry may be added to change event queue 124, where it can be accessed by one or more of computing nodes, Jayanti Venkata).
As per claim 12, Muthyala 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:
receive, by a destination system and from a source system via a network, 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);
Muthyala does not explicitly teach a pull notification that indicates an event is being performed in the source system, 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 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.
However, Jayanti Venkata teaches a pull notification that indicates an event is being performed in the source system ([0099], e.g., the remote device may communicate a pull request to the communication system to obtain information about the change event), 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 ([0099], e.g., the communication system may communicate with one of computing nodes 222 to obtain information from a change event entry corresponding to the change event indicated by the pull request from an endpoint device and [0095], e.g., the communication system may communicate with remote devices via one or more communication networks) 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 ([0071], e.g., device access management system 120 may schedule one or more servers 122 to execute an action process for each change event identified on change event queue, the information about the change event may be communicated asynchronously to the remote devices).
Thus, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to apply the teachings of Jayanti Venkata with the teachings of Muthyala in order to efficiently enabling a system to communicate information about a change event to remote devices in an asynchronous manner (Jayanti Venkata).
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 ([0099], e.g., the communication system may communicate with a computing node that sent a notification to the endpoint device about the change event indicated by the pull request, Jayanti Venkata).
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 ([0097], [0113], a change event object may include metadata that identifies the change event, a remote device may communicate with the communication system (e.g., send a pull request) to obtain information about a change event identified by a notification, Jayanti Venkata).
As per claim 15, 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 ([0133], e.g., data stored in a change event entry may include metadata about a change event, Jayanti Venkata).
As per claim 16, 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 ([0097], [0113], [0133], a change event object may include metadata that identifies the change event, a remote device may communicate with the communication system (e.g., send a pull request) to obtain information about a change event identified by a notification, the change event entry may be managed on a queue (e.g., change event queue 124) for a computing node to perform an action for the change event indicated by the change event entry, Jayanti Venkata).
As per claim 17, 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 ([0041], e.g., a metadata class may be defined for each different type of change event, the metadata class may define one or more fields of information that can be stored in a change event object defined based on that metadata class, a new metadata class may be defined for as new or different types of change events are defined, Jayanti Venkata).
Regarding claim 18, claim 18 is rejected for substantially the same reason as claim 1 above.
Regarding claims 19-20, claims 19-20 are rejected for substantially the same reason as claims 2-3 above.
Citation of Pertinent Prior Arts
The prior art made of record and not relied upon in form PTO-892, if any, is considered pertinent to applicant's disclosure.
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