DETAILED ACTION
This Office action is in response to original application filed on 11/14/2023.
Claims 1-20 are pending.
Claims 9 and 19 are objected to.
Claims 1-8, 10-18, and 20 are rejected.
Notice of 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 .
Examiner Notes
¶ 0022 of the instant specification recites “the second server is a subscriber server configured to received change notifications” and should likely recite “the second server is a subscriber server configured to receive[[d]] change notifications.”
¶ 0043 of the instant specification recites an extra ending parenthesis after “environment ID.”
¶ 0079 of the instant specification recites “generating a signed upload URL can take an input an optional generation ID” and should likely recite “generating a signed upload URL can take as[[an]] input an optional generation ID.”
Appropriate correction may be required.
Claim 11 is objected to as it recites “the data locality being associated with a first server,” while claims 1 and 10 both recite “the data locality configuration being associated with a first server.”
Statutory Review under 35 USC § 101
Claims 1-10 are directed toward a system and have been reviewed.
Claims 1-10 initially appear to be statutory, as the system includes hardware (at least one processor; at least one memory component storing instructions) as disclosed in ¶ 0083 of the applicant’s specification.
Claims 1-3 and 5-10 also appear to be statutory as they recite patent-eligible subject matter and do not recite a judicial exception as per Step 2A, Prong One of the patent subject matter eligibility determination.
Claim 4 also appears to be statutory as they perform a method (detecting) integrated into a practical application as per Step 2A, Prong Two of the patent subject matter eligibility determination.
Claims 11-19 are directed towards a method and have been reviewed.
Claims 11-13 and 15-19 appear to be statutory as they recite patent-eligible subject matter and do not recite a judicial exception as per Step 2A, Prong One of the patent subject matter eligibility determination.
Claims 14 appear to be statutory as they perform a method (detecting) integrated into a practical application as per Step 2A, Prong Two of the patent subject matter eligibility determination.
Claim 20 is directed toward an article of manufacture and has been reviewed.
Claim 20 initially appears to be statutory, as the article of manufacture excludes transitory signals (claim says non-transitory).
Claim 20 also appears to be statutory as it recites patent-eligible subject matter and does not recite a judicial exception as per Step 2A, Prong One of the patent subject matter eligibility determination.
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.
Claims 1-2, 11-12, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Karlsson et al., U.S. Patent No. 11,724,191 (published August 15, 2023; hereinafter Karlsson) in view of Lurey et al., U.S. Patent Application Publication No. 2014/0157390 (hereinafter Lurey).
Regarding claim 1, Karlsson teaches:
A system, comprising: at least one processor; at least one memory component storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations comprising: (Karlsson col. 22, lines 39-45: All of the processes described herein may be embodied in, and fully automated via, software code modules executed by a computing system that includes one or more computers or processors. The code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device)
configuring a database (DB) engine to access a DB, the DB engine and the DB being configured based on a data locality configuration of a plurality of data locality configurations, (Karlsson FIG. 1, col. 8, lines 1-25: The game editor client 120 may identify game editor tools 122 that are available for download by the user, game editor tools 122 that are available for streaming by the user, and/or game editor tools 122 that have been previously installed on the user computing system ... the game editor client 120 may require that any assets modified or created using the tool are saved in a network-based data store (e.g., account data store 138) and prevent the user from saving assets locally on the user computing system; Karlsson col. 8, line 49-col. 9, line 10: The game editor client 120 can provide an interface through which the user can access the asset hub 132 and source asset data store 140)
the data locality configuration being associated with a first server, (Karlsson FIG. 1, col. 8, lines 12-25: the game editor client 120 may require that any assets modified or created using the tool are saved in a network-based data store (e.g., account data store 138) and prevent the user from saving assets locally on the user computing system; see also Karlsson FIGs. 1, 3, col. 5, line 54-col. 6, line 8: The game application may be configured to execute a game application stored and/or executed in a distributed environment using a client/server architecture … the user computing system 102 may execute a portion of a game application and the interactive computing system 130, or an application host system 132 of the interactive computing system 130, may execute another portion of the game application ... the game application may be a massively multiplayer online role-playing game (MMORPG) that includes a client portion executed by the user computing system 102 and a server portion executed by one or more application host systems 132)
the DB engine being configured to process access requests… (Karlsson 191 FIG. 5, col. 19, lines 27-36: At block 510, the interactive computing system 130 receives transactions from the user computing system 102 to modify the game application 110 ... At block 512, the interactive computing system 130 modifies the game application based on the transactions received from the user computing system)
configuring a data interface to receive access requests associated with the DB and… (Karlsson FIG. 5, col. 19, lines 26-31: At block 510, the interactive computing system 130 receives transactions from the user computing system 102 to modify the game application 110. The transactions can be changes to existing source assets and/or the creation of new source assets; see Karlsson col. 8, lines 12-25 showing involvement of the DB as claimed: the game editor client 120 may require that any assets modified or created using the tool are saved in a network-based data store (e.g., account data store 138) and prevent the user from saving assets locally on the user computing system)
retrieve results of the access requests associated with the DB; and (Karlsson FIG. 5, col. 19, lines 32-44: At block 512, the interactive computing system 130 modifies the game application based on the transactions received from the user computing system ... The updates can be visualized as soon as they are complete by other users. For example, in a shared virtual development environment, modifications made to the tree by the first user could be updated for display to the second user)
Karlsson does not expressly disclose:
the DB engine being configured to … be inactive outside of processing the access requests;
Karlsson further does not expressly disclose:
configuring a software module to enable downloading of a first version of the DB from remote storage to local storage associated with the first server,
and enable uploading of a second version of the DB from the local storage to the remote storage.
However, Lurey addresses this by teaching:
the DB engine being configured to … be inactive outside of processing the access requests; (Lurey FIG. 16, ¶ 0123: asynchronous auto synchronization begins at a block 2052, which checks to determine whether the application has been newly opened or, optionally, whether a particular time has elapsed from the last synchronization operation. If neither event has occurred, control pauses at the block 2052)
configuring a software module to enable downloading of a first version of the DB from remote storage to local storage associated with the first server, (Lurey FIG. 15, ¶ 0115: When the data are uploaded to the central server, a synchronization operation is performed on the server side, based on the previously uploaded data having the same subscription code and cipher keys (if such data exists). The resulting database is then downloaded by the user's application and overrides the user's current database. By maintaining a copy of the most recently merged database on the server side, the user is able to perform asynchronous auto-sync of his/her information across mobile devices and computer(s))
and enable uploading of a second version of the DB from the local storage to the remote storage. (Lurey FIG. 15, FIG. 16, ¶ 0123: the programming to implement the asynchronous auto synchronization begins at a block 2052 ... control passes to a block 2054 that uploads the encrypted user data to the central server. The server checks the uploaded data to determine if such data are valid and, if so, the fields of the database maintained on the central server are updated for the particular records where data has changed since the last synchronization operation)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the database access of Karlsson with the database synchronization of Lurey.
In addition, both of the references (Karlsson and Lurey) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as propagating data changes.
Motivation to do so would be to improve the functioning of Karlsson applying changes to remotely stored data with the ability in Lurey to also apply changes to remotely stored data but with the improvement of various synchronization techniques.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement easier and more secure data access as seen in Lurey ¶ 0005-0006.
Regarding claim 11, Karlsson teaches:
A computer-implemented method, comprising: configuring a database (DB) engine to access a DB, the DB engine and the DB being configured based on a data locality configuration of a plurality of data locality configurations, (Karlsson FIG. 1, col. 8, lines 1-25: The game editor client 120 may identify game editor tools 122 that are available for download by the user, game editor tools 122 that are available for streaming by the user, and/or game editor tools 122 that have been previously installed on the user computing system ... the game editor client 120 may require that any assets modified or created using the tool are saved in a network-based data store (e.g., account data store 138) and prevent the user from saving assets locally on the user computing system; Karlsson col. 8, line 49-col. 9, line 10: The game editor client 120 can provide an interface through which the user can access the asset hub 132 and source asset data store 140)
the data locality being associated with a first server, (Karlsson FIG. 1, col. 8, lines 12-25: the game editor client 120 may require that any assets modified or created using the tool are saved in a network-based data store (e.g., account data store 138) and prevent the user from saving assets locally on the user computing system; see also Karlsson FIGs. 1, 3, col. 5, line 54-col. 6, line 8: The game application may be configured to execute a game application stored and/or executed in a distributed environment using a client/server architecture … the user computing system 102 may execute a portion of a game application and the interactive computing system 130, or an application host system 132 of the interactive computing system 130, may execute another portion of the game application ... the game application may be a massively multiplayer online role-playing game (MMORPG) that includes a client portion executed by the user computing system 102 and a server portion executed by one or more application host systems 132)
the DB engine being configured to process access requests… (Karlsson 191 FIG. 5, col. 19, lines 27-36: At block 510, the interactive computing system 130 receives transactions from the user computing system 102 to modify the game application 110 ... At block 512, the interactive computing system 130 modifies the game application based on the transactions received from the user computing system)
configuring a data interface to receive access requests associated with the DB and… (Karlsson FIG. 5, col. 19, lines 26-31: At block 510, the interactive computing system 130 receives transactions from the user computing system 102 to modify the game application 110. The transactions can be changes to existing source assets and/or the creation of new source assets; see Karlsson col. 8, lines 12-25 showing involvement of the DB as claimed: the game editor client 120 may require that any assets modified or created using the tool are saved in a network-based data store (e.g., account data store 138) and prevent the user from saving assets locally on the user computing system)
retrieve results of the access requests associated with the DB; and (Karlsson FIG. 5, col. 19, lines 32-44: At block 512, the interactive computing system 130 modifies the game application based on the transactions received from the user computing system ... The updates can be visualized as soon as they are complete by other users. For example, in a shared virtual development environment, modifications made to the tree by the first user could be updated for display to the second user)
Karlsson does not expressly disclose:
the DB engine being configured to … be inactive outside of processing the access requests;
Karlsson further does not expressly disclose:
configuring a software module to: enable downloading of a first version of the DB from remote storage to local storage associated with the first server, and
enable uploading of a second version of the DB from the local storage to the remote storage.
However, Lurey addresses this by teaching:
the DB engine being configured to … be inactive outside of processing the access requests; (Lurey FIG. 16, ¶ 0123: asynchronous auto synchronization begins at a block 2052, which checks to determine whether the application has been newly opened or, optionally, whether a particular time has elapsed from the last synchronization operation. If neither event has occurred, control pauses at the block 2052)
configuring a software module to: enable downloading of a first version of the DB from remote storage to local storage associated with the first server, and (Lurey FIG. 15, ¶ 0115: When the data are uploaded to the central server, a synchronization operation is performed on the server side, based on the previously uploaded data having the same subscription code and cipher keys (if such data exists). The resulting database is then downloaded by the user's application and overrides the user's current database. By maintaining a copy of the most recently merged database on the server side, the user is able to perform asynchronous auto-sync of his/her information across mobile devices and computer(s))
enable uploading of a second version of the DB from the local storage to the remote storage. (Lurey FIG. 15, FIG. 16, ¶ 0123: the programming to implement the asynchronous auto synchronization begins at a block 2052 ... control passes to a block 2054 that uploads the encrypted user data to the central server. The server checks the uploaded data to determine if such data are valid and, if so, the fields of the database maintained on the central server are updated for the particular records where data has changed since the last synchronization operation)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the database access of Karlsson with the database synchronization of Lurey.
In addition, both of the references (Karlsson and Lurey) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as propagating data changes.
Motivation to do so would be to improve the functioning of Karlsson applying changes to remotely stored data with the ability in Lurey to also apply changes to remotely stored data but with the improvement of various synchronization techniques.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement easier and more secure data access as seen in Lurey ¶ 0005-0006.
Regarding claim 20, Karlsson teaches:
A non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium including instructions that, when executed by one or more computer processors, cause the one or more computer processors to perform operations, the operations comprising: (Karlsson col. 22, lines 39-45: All of the processes described herein may be embodied in, and fully automated via, software code modules executed by a computing system that includes one or more computers or processors. The code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device)
configure a database (DB) engine to access a DB, the DB engine and the DB being configured based on a data locality configuration of a plurality of data locality configurations, (Karlsson FIG. 1, col. 8, lines 1-25: The game editor client 120 may identify game editor tools 122 that are available for download by the user, game editor tools 122 that are available for streaming by the user, and/or game editor tools 122 that have been previously installed on the user computing system ... the game editor client 120 may require that any assets modified or created using the tool are saved in a network-based data store (e.g., account data store 138) and prevent the user from saving assets locally on the user computing system; Karlsson col. 8, line 49-col. 9, line 10: The game editor client 120 can provide an interface through which the user can access the asset hub 132 and source asset data store 140)
the data locality configuration being associated with a first server, (Karlsson FIG. 1, col. 8, lines 12-25: the game editor client 120 may require that any assets modified or created using the tool are saved in a network-based data store (e.g., account data store 138) and prevent the user from saving assets locally on the user computing system; see also Karlsson FIGs. 1, 3, col. 5, line 54-col. 6, line 8: The game application may be configured to execute a game application stored and/or executed in a distributed environment using a client/server architecture … the user computing system 102 may execute a portion of a game application and the interactive computing system 130, or an application host system 132 of the interactive computing system 130, may execute another portion of the game application ... the game application may be a massively multiplayer online role-playing game (MMORPG) that includes a client portion executed by the user computing system 102 and a server portion executed by one or more application host systems 132)
the DB engine being configured to process access requests… (Karlsson 191 FIG. 5, col. 19, lines 27-36: At block 510, the interactive computing system 130 receives transactions from the user computing system 102 to modify the game application 110 ... At block 512, the interactive computing system 130 modifies the game application based on the transactions received from the user computing system)
configure a data interface to receive access requests associated with the DB and… (Karlsson FIG. 5, col. 19, lines 26-31: At block 510, the interactive computing system 130 receives transactions from the user computing system 102 to modify the game application 110. The transactions can be changes to existing source assets and/or the creation of new source assets; see Karlsson col. 8, lines 12-25 showing involvement of the DB as claimed: the game editor client 120 may require that any assets modified or created using the tool are saved in a network-based data store (e.g., account data store 138) and prevent the user from saving assets locally on the user computing system)
retrieve results of the access requests associated with the DB; and (Karlsson FIG. 5, col. 19, lines 32-44: At block 512, the interactive computing system 130 modifies the game application based on the transactions received from the user computing system ... The updates can be visualized as soon as they are complete by other users. For example, in a shared virtual development environment, modifications made to the tree by the first user could be updated for display to the second user)
Karlsson does not expressly disclose:
the DB engine being configured to … be inactive outside of processing the access requests;
Karlsson further does not expressly disclose:
configure a software module to: enable downloading of a first version of the DB from remote storage to local storage associated with the first server, and
enable uploading of a second version of the DB from the local storage to the remote storage.
However, Lurey addresses this by teaching:
the DB engine being configured to … be inactive outside of processing the access requests; (Lurey FIG. 16, ¶ 0123: asynchronous auto synchronization begins at a block 2052, which checks to determine whether the application has been newly opened or, optionally, whether a particular time has elapsed from the last synchronization operation. If neither event has occurred, control pauses at the block 2052)
configuring a software module to: enable downloading of a first version of the DB from remote storage to local storage associated with the first server, and (Lurey FIG. 15, ¶ 0115: When the data are uploaded to the central server, a synchronization operation is performed on the server side, based on the previously uploaded data having the same subscription code and cipher keys (if such data exists). The resulting database is then downloaded by the user's application and overrides the user's current database. By maintaining a copy of the most recently merged database on the server side, the user is able to perform asynchronous auto-sync of his/her information across mobile devices and computer(s))
enable uploading of a second version of the DB from the local storage to the remote storage. (Lurey FIG. 15, FIG. 16, ¶ 0123: the programming to implement the asynchronous auto synchronization begins at a block 2052 ... control passes to a block 2054 that uploads the encrypted user data to the central server. The server checks the uploaded data to determine if such data are valid and, if so, the fields of the database maintained on the central server are updated for the particular records where data has changed since the last synchronization operation)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the database access of Karlsson with the database synchronization of Lurey.
In addition, both of the references (Karlsson and Lurey) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as propagating data changes.
Motivation to do so would be to improve the functioning of Karlsson applying changes to remotely stored data with the ability in Lurey to also apply changes to remotely stored data but with the improvement of various synchronization techniques.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement easier and more secure data access as seen in Lurey ¶ 0005-0006.
Regarding claims 2 and 12, Karlsson in view of Lurey teaches:
wherein the data locality configuration specifies that the DB engine and the DB are embedded within a server process of the first server. (Karlsson FIGs. 1, 3, col. 5, line 54-col. 6, line 8: The game application may be configured to execute a game application stored and/or executed in a distributed environment using a client/server architecture … the user computing system 102 may execute a portion of a game application and the interactive computing system 130, or an application host system 132 [relevant to DB engine] of the interactive computing system 130, may execute another portion of the game application ... the game application may be a massively multiplayer online role-playing game (MMORPG) that includes a client portion executed by the user computing system 102 and a server portion executed by one or more application host systems 132 ; Karlsson FIG. 1, col. 8, lines 1-25: the game editor client 120 may require that any assets modified or created using the tool are saved in a network-based data store (e.g., account data store 138) [relevant to DB] and prevent the user from saving assets locally on the user computing system; Karlsson col. 8, line 49-col. 9, line 10: The game editor client 120 can provide an interface through which the user can access the asset hub 132 and source asset data store 140 [also relevant to DB])
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Karlsson in view of Lurey in further view of Bastawala et al., U.S. Patent Application Publication No. 2022/0046036 (hereinafter Bastawala).
Regarding claims 3 and 13, Karlsson in view of Lurey does not expressly disclose:
the access requests associated with the DB comprise one of at least a read access request and a write access request;
the data interface is configured to provide, to the first server, read access to the DB and write access to the DB; and
the data interface is configured to provide, to a second server, read access to the DB and disallow, to the second server, write access to the DB.
However, Bastawala addresses this by teaching:
the access requests associated with the DB comprise one of at least a read access request and a write access request; (Bastawala FIG. 1A, ¶ 0086-0087: Request(s) to perform database operation(s), which are received from client applications A . . . I . . . N by DBMS 110 … a request received by DBMS 110 may be in the form of a PL/SQL statement or an SQL statement, including either a query such as a SELECT statement or a DML operation, such as an INSERT or UPDATE statement, or any other statement in a database access language)
the data interface is configured to provide, to the first server, read access to the DB and write access to the DB; and (Bastawala ¶ 0031: a mirage instance may access the same database as a regular instance, and use the database for read and write operations identical to the regular instance, e.g. by executing at least some or (or in some embodiments, all of) the same software, as the regular instance; see also Bastawala ¶ 0125: Mirage instance(s) 120 of a first class (also called first feature class) are similar or identical in features to regular instance(s) 130 in all respects, and differ only in name)
the data interface is configured to provide, to a second server, read access to the DB and disallow, to the second server, write access to the DB. (Bastawala ¶ 0032: mirage instance(s) are configured to open a database for read operations only; see also similar Bastawala ¶ 0104: in embodiments that only check or simulate a request, mirage instance 120A opens database 1002 for read only operations or opens a database replica 1092 (FIG. 1A) that contains a copy of the data in database 1002; see also Bastawala ¶ 0125: Mirage instance(s) 120 of a third class (also called third feature class) are limited to opening database 1002 for only read operations ... Mirage instance(s) 120 of a fourth class (also called fourth feature class) are limited to simulating the processing of, but not actually processing, requests for database operations)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the database access of Karlsson as modified with the database instances of Bastawala.
In addition, both of the references (Karlsson as modified and Bastawala) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as database server management.
Motivation to do so would be to improve the functioning of Karlsson as modified performing database reads and writes with the ability in Bastawala to also perform database reads and writes but with the improvement of various read/write permissions.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to improve data request handling as seen in Bastawala ¶ 0004.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Karlsson in view of Lurey in further view of Bastawala in further view of Boyd et al., U.S. Patent Application Publication No. 2014/0074409 (hereinafter Boyd).
Regarding claims 4 and 14, Karlsson in view of Lurey and Bastawala does not expressly disclose:
transmit a notification to the second server responsive to detecting a change to the DB, the second server being a subscriber server configured to receive change notifications.
However, Boyd addresses this by teaching:
transmit a notification to the second server responsive to detecting a change to the DB, the second server being a subscriber server configured to receive change notifications. (Boyd ¶ 0057: At step 530 all updated files are uploaded to all subscriber and placed in long term storage system 545. Master database 310 is provided with a database list to allow it to provide a list of approved databases with subscriptions. At step 550 update records are created for all subscribers and also placed in long term storage system 545; see also Boyd ¶ 0058-0059: saving a corresponding event record to subscriber's account in the storage DB. Each event record contains information such as the update type, the reference to uploaded file (if any) and the serialized object that specifies the information about update's content)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the database access of Karlsson as modified with the database subscriptions of Boyd.
In addition, both of the references (Karlsson as modified and Boyd) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as propagating data changes.
Motivation to do so would be to improve the functioning of Karlsson as modified applying changes to remotely stored data with the ability in Boyd to also apply changes to remotely stored data but with the improvement of various notification techniques.
Claims 5-6 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Karlsson in view of Lurey in further view of Mandadi et al., U.S. Patent No. 10,901,768 (published January 26, 2021; hereinafter Mandadi).
Regarding claims 5 and 15, Karlsson in view of Lurey does not expressly disclose:
wherein the DB is associated with metadata comprising one or more of a DB ID, a DB version number, a file path associated with the first server, or a bucket ID corresponding to a remote storage bucket.
However, Mandadi addresses this by teaching:
wherein the DB is associated with metadata comprising one or more of a DB ID, a DB version number, a file path associated with the first server, or a bucket ID corresponding to a remote storage bucket. (Mandadi col. 8, lines 35-49: the backup proxy 146 can upload the data to one or more buckets or folders created by the backup proxy 146 to store the data at the storage service 108 and, in return from the storage service 108, may receive one or more Uniform Resource Locators (URLs) or other identifier of the location(s) at which the data is stored [shows the claimed DB ID] [addresses entirety of the claim as required by the language 'one or more of' and 'or'])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the database access of Karlsson as modified with the data identifiers of Mandadi.
In addition, both of the references (Karlsson as modified and Mandadi) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as propagating data changes.
Motivation to do so would be to improve the functioning of Karlsson as modified applying changes to remotely stored data with the ability in Mandadi to also apply changes to remotely stored data but with the improvement of various types of metadata.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement improved data migration techniques as seen in Mandadi col. 4, lines 50-61.
Regarding claims 6 and 16, Karlsson in view of Lurey and Mandadi teaches:
wherein downloading the first version of the DB from the remote storage to the first server comprises: transmitting a request for a signed download URL to a service API, (Mandadi FIG. 1, interface(s) (e.g., APIs, console) 112, col. 8, lines 18-49: the backup proxy 146 can upload the data to one or more buckets or folders created by the backup proxy 146 to store the data at the storage service 108 and, in return from the storage service 108, may receive one or more Uniform Resource Locators (URLs) or other identifier of the location(s) at which the data is stored. In some embodiments, the URL can be a “pre-signed” URL which grants time-limited permission to one or more other entities to access (for example, to download or copy) the data stored at the location identified by the pre-signed URL)
the request including the DB ID, (Mandadi col. 8, lines 35-49: the backup proxy 146 can upload the data to one or more buckets or folders created by the backup proxy 146 to store the data at the storage service 108 and, in return from the storage service 108, may receive one or more Uniform Resource Locators (URLs) or other identifier of the location(s) at which the data is stored)
the service API communicating with a remote storage backend associated with the remote storage; (Mandadi col. 4, lines 4-31: Users may interact with a provider network 100 across one or more intermediate networks 110 (for example, the internet) via one or more interface(s) 112, such as through use of application programming interface (API) calls, via a console implemented as a website or application, etc. The interface(s) 112 may be part of, or serve as a front-end to, a control plane 114 of the provider network 100 that includes “backend” services supporting and enabling the services that may be more directly offered to customers)
receiving, from the service API, the signed download URL, the signed download URL specifying a location of a current version of the DB at the remote storage; and (Mandadi FIG. 1, interface(s) (e.g., APIs, console) 112, col. 8, lines 18-49: ...in return from the storage service 108, may receive one or more Uniform Resource Locators (URLs) or other identifier of the location(s) at which the data is stored. In some embodiments, the URL can be a “pre-signed” URL which grants time-limited permission to one or more other entities to access (for example, to download or copy) the data stored at the location identified by the pre-signed URL)
using the signed download URL, retrieving from the remote storage the current version of the DB as the first version of the DB. (Mandadi col. 9, lines 5-20: A “createVM” request may include, for example, one or more of the following parameters: a user's service provider account identifier, a pre-signed URL identifying a manifest file (which identifies a location of the replication data and configuration data), an identifier of the destination server 136, an identifier of the current migration job, and other possible information; see also Mandadi FIG. 3, col. 15, line 65-col. 16, line 17: At block 310, a management agent running at the second computing device creates a migrated copy of the server at the second computing device based on the replication data by executing the installation script and configuring the migrated copy of the server based on the configuration data ... creation of the migrated copy of the server may include one or more of: creating a storage volume, converting the replication data to a format for storage in one or more storage volumes to obtain the migrated copy of the server, storing the migrated copy of the server in the storage volume)
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Karlsson in view of Lurey in further view of Mandadi in further view of Whitaker et al., U.S. Patent Application Publication No. 2023/0169093 (published June 1, 2023; hereinafter Whitaker).
Regarding claims 7 and 17, Karlsson in view of Lurey and Mandadi teaches:
wherein uploading the second version of the DB from the local storage associated with first server to the remote storage comprises: generating the second version of the DB by modifying the first version of the DB; (Lurey FIG. 15, FIG. 16, ¶ 0123: the programming to implement the asynchronous auto synchronization begins at a block 2052 ... control passes to a block 2054 that uploads the encrypted user data to the central server. The server checks the uploaded data to determine if such data are valid and, if so, the fields of the database maintained on the central server are updated for the particular records where data has changed since the last synchronization operation)
Mandadi teaches:
transmitting a request for a signed upload URL to the service API that communicates with the remote storage backend, the request including the DB ID; (Mandadi FIG. 4, col. 14, line 64-col. 15, line 38: operations 400 include operations performed by a backup proxy 146 in response to receiving the migration command (for example, a migration command 134) ... a backup proxy 146 may receive a migration command from a component of a service provider network 100 using either a push or pull mechanism. In an embodiment, the migration command includes an identifier of the server to be migrate ... the storage service 108 generates a pre-signed URL or other identifier of the storage location storing the uploaded data and sends the identifier to the backup proxy 146)
receiving, from the service API, a signed upload URL specifying an upload location at the remote storage; and using the signed upload URL, uploading the second version of the DB to the upload location. (Mandadi FIG. 4, col. 15, lines 27-38: the backup proxy 146 may create a folder, “bucket,” or other type of storage location at a storage service 108 of the service provider network 100 and upload the replication data 144 and configuration data 142 to the created storage location (for example, using a URL or other identifier associated with the storage location). In an embodiment, the storage service 108 generates a pre-signed URL or other identifier of the storage location storing the uploaded data and sends the identifier to the backup proxy 146)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the database access of Karlsson as modified with the data identifiers of Mandadi.
Motivation to do so would be to improve the functioning of Karlsson as modified applying changes to remotely stored data with the ability in Mandadi to also apply changes to remotely stored data but with the improvement of various types of metadata.
Karlsson in view of Lurey and Mandadi does not expressly disclose:
storing the second version of the DB in temporary storage of the first server;
However, Whitaker addresses this by teaching:
storing the second version of the DB in temporary storage of the first server; (Whitaker FIG. 2, ¶ 0022: Upon a database node making a change to its “own” view of the (shared) volume, the data may be written to a separate underlying storage area specific to that volume alone, effectively “forking” the underlying volume into a separate version based on the original)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the database access of Karlsson as modified with the database scaling of Whitaker.
In addition, both of the references (Karlsson as modified and Whitaker) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as database migration techniques.
Motivation to do so would be to improve the functioning of Karlsson as modified performing database migration with the ability in Whitaker to also perform database migration but with the improvement of allowing new database nodes to be launched/configured for use incredibly fast when compared to existing techniques.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to provide improved provider network client performance as seen in Whitaker ¶ 0016.
Claims 8, 10, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Karlsson in view of Lurey in further view of Mandadi in further view of Whitaker in further view of Singh et al., U.S. Patent No. 11,868,800 (filed June 16, 2021; hereinafter Singh).
Regarding claims 8 and 18, Karlsson in view of Lurey and Mandadi and Whitaker teaches:
the received signed download URL comprises a … ID … the signed upload URL is updated to comprise the generation ID; and (Mandadi FIG. 4, col. 15, lines 27-38: the backup proxy 146 may create a folder, “bucket,” or other type of storage location at a storage service 108 of the service provider network 100 and upload the replication data 144 and configuration data 142 to the created storage location (for example, using a URL or other identifier associated with the storage location). In an embodiment, the storage service 108 generates a pre-signed URL or other identifier of the storage location storing the uploaded data and sends the identifier to the backup proxy 146)
using the signed upload URL to upload the second version of the DB further comprises receiving a status code… (Mandadi FIG. 3, col. 16, lines 30-37: At block 314, the management agent generates a notification indicating a status of the migration. For example, the management agent 138 provides an indication of the migration status to the server configuration service 104, which in turn can provide the indication to the server migration service 102. The server migration service 102 can then report the status to the user 130 via the console 112 or other interface)
Karlsson in view of Lurey and Mandadi and Whitaker does not expressly disclose a generation ID corresponding to the current DB version stored at the remote storage.
Karlsson in view of Lurey and Mandadi and Whitaker further does not expressly disclose based on a comparison between the generation ID and a most recent generation ID of a most recent DB version stored at the remote storage.
However, Singh addresses this by teaching a generation ID corresponding to the current DB version stored at the remote storage. (Singh FIG. 3, Steps 304-306, col. 16, line 17-col. 17, line 41: The latest version of the file known to the cache may have a local version identifier (LID) if the file has not yet been uploaded to the cloud, or it may have a cloud version identifier (CID) if the file has been uploaded to the cloud; If the file has a cloud version identifier, then the cloud version identifier may be mapped to the local version identifier that previously existed for the file; At step 306, the method 300 may include comparing a client-provided version identifier to the local version identifier associated with the hybrid cloud cache and/or to the cloud version identifier associated with the cloud obtained via step 304)
Singh also teaches based on a comparison between the generation ID and a most recent generation ID of a most recent DB version stored at the remote storage. (Singh FIG. 3, Step 308, col. 16, line 17-col. 17, line 41: the method may include determining that a conflict does not exist based on the client-provided version identifier because that identifier matches either the local version identifier or the cloud version identifier mapped to the local version identifier ... determining that a conflict does exist based on the client-provided version identifier not matching either the local version identifier or the cloud version identifier mapped to the local version identifier)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the database access of Karlsson as modified with the data identifiers of Singh.
In addition, both of the references (Karlsson as modified and Singh) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as propagating data changes.
Motivation to do so would be to improve the functioning of Karlsson as modified applying changes to remotely stored data with the ability in Singh to also apply changes to remotely stored data but with the improvement of various types of metadata.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to provide more effective handling of data versions in a hybrid cloud computing environment as seen in Singh col. 3, lines 27-41.
Regarding claim 10, Karlsson in view of Lurey and Mandadi and Whitaker and Singh teaches:
wherein the operations further comprise: transmitting a request for a second signed download URL to the service API, the request including the DB ID; and (Mandadi FIG. 1, interface(s) (e.g., APIs, console) 112, col. 8, lines 18-49: the backup proxy 146 can upload the data to one or more buckets or folders created by the backup proxy 146 to store the data at the storage service 108 and, in return from the storage service 108, may receive one or more Uniform Resource Locators (URLs) or other identifier of the location(s) at which the data is stored [one or more URLs shows second URL as claimed]. In some embodiments, the URL can be a “pre-signed” URL which grants time-limited permission to one or more other entities to access (for example, to download or copy) the data stored at the location identified by the pre-signed URL [shows signed download URL])
receiving, from the service API, the second signed download URL, the signed download URL comprising a second generation ID generated, at the remote storage, for the second version of the DB. (Mandadi FIG. 1, interface(s) (e.g., APIs, console) 112, col. 8, lines 18-49: At circle “4,” a backup proxy 146 sends, or uploads, the replication data 144, configuration data 142, and optionally the manifest file 140 to a storage service 108 [uploading to storage service shows second version of DB] ... the backup proxy 146 can upload the data to one or more buckets or folders created by the backup proxy 146 to store the data at the storage service 108 and, in return from the storage service 108, may receive one or more Uniform Resource Locators (URLs) or other identifier of the location(s) at which the data is stored [one or more URLs shows second URL]. In some embodiments, the URL can be a “pre-signed” URL which grants time-limited permission to one or more other entities to access (for example, to download or copy) the data stored at the location identified by the pre-signed URL)
Singh teaches:
the status code is a success code indicating the generation ID matches the current generation ID; (Singh FIG. 3, Step 310, col. 16, line 17-col. 17, line 41: At step 308, the method 300 may include determining if the client-provided version identifier of the file (or object) refers to the latest uploaded version of the file (or object) based on the comparison from step 306; This would occur if the client-provided version identifier of the file matches the CID or if the client-provided version identifier of the file is a LID that is mapped to the OD)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the database access of Karlsson as modified with the data identifiers of Singh.
Motivation to do so would be to improve the functioning of Karlsson as modified applying changes to remotely stored data with the ability in Singh to also apply changes to remotely stored data but with the improvement of various types of metadata.
Allowable Subject Matter
Claims 9 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Yang et al., U.S. Patent Application Publication No. 2019/0102260; see Yang FIG. 2, ¶ 0029-0031 describing applications on servers with an active or inactive status, relevant to at least the independent claims involving a DB engine configured to process access requests and be inactive outside of processing access requests.
While utilized above in some of the dependent claims, Whitaker FIG. 2, ¶ 0077-0079 describes a wait occurring for open transactions to quiesce (e.g., terminate, or otherwise enter a period of inactivity), relevant to at least the independent claims involving a DB engine being inactive outside of processing access requests.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEDIDIAH P FERRER whose telephone number is (571)270-7695. The examiner can normally be reached Monday-Friday 12:00pm-8:00pm.
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.
/J.P.F/Examiner, Art Unit 2153 March 4, 2026
/KAVITA STANLEY/Supervisory Patent Examiner, Art Unit 2153