DETAILED ACTION
Claims 1-3, 6-10, 13-16, and 19-20 are pending.
Claims 1-3, 6-10, 13-16, and 19-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 .
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/05/2026 has been entered.
Priority
This application is a continuation of application number 14/132,176 filed 12/18/2013.
Statutory Review under 35 USC § 101
Claims 1-3 and 6-7 are directed toward a system and have been reviewed.
Claims 1-3 and 6-7 initially appear to remain statutory under 35 USC § 101, as they include hardware (a hardware processor).
Claims 1-3 and 6-7 appear to remain patent-eligible as they perform a method comprising a judicial exception is integrated into a practical application as per (Revised) Step 2A, Prong Two of the patent subject matter eligibility determination.
Specifically, the claims recite additional elements demonstrating that the claim as a whole integrates the exception into a practical application. The claims have been evaluated to ensure that the claims reflect the disclosed improvement: the claims are drawn to performing a synchronization between servers via a single connection by identifying the contents to be synchronized at once instead of reading and/or acting upon a plurality of separate content synchronization messages.
These additional claim elements improve the functioning of a computer or any other technology or technical fields, thus integrating the abstract exception into a practical application.
Claims 8-10 and 13 are directed towards a method and have been reviewed.
Claims 8-10 and 13 appear to remain patent-eligible as they perform a method comprising a judicial exception is integrated into a practical application as per (Revised) Step 2A, Prong Two of the patent subject matter eligibility determination.
Specifically, the claims recite additional elements demonstrating that the claim as a whole integrates the exception into a practical application. The claims have been evaluated to ensure that the claims reflect the disclosed improvement: the claims are drawn to performing a synchronization between servers via a single connection by identifying the contents to be synchronized at once instead of reading and/or acting upon a plurality of separate content synchronization messages.
These additional claim elements improve the functioning of a computer or any other technology or technical fields, thus integrating the abstract exception into a practical application.
Claims 14-16 and 19-20 are directed toward an article of manufacture and have been reviewed.
Claims 14-16 and 19-20 initially appear to remain statutory, as the article of manufacture excludes transitory signals (claim says non-transitory).
Claims 14-16 and 19-20 appear to remain patent-eligible as they perform a method comprising a judicial exception is integrated into a practical application as per (Revised) Step 2A, Prong Two of the patent subject matter eligibility determination.
Specifically, the claims recite additional elements demonstrating that the claim as a whole integrates the exception into a practical application. The claims have been evaluated to ensure that the claims reflect the disclosed improvement: the claims are drawn to performing a synchronization between servers via a single connection by identifying the contents to be synchronized at once instead of reading and/or acting upon a plurality of separate content synchronization messages.
These additional claim elements improve the functioning of a computer or any other technology or technical fields, thus integrating the abstract exception into a practical application.
Response to Arguments
35 U.S.C. 103
Applicant’s arguments with respect to claim(s) 1, 8, and 14 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Dependent claims 2-3, 6-7, 9-1, 13, 15-16, and 19-20 remain rejected at least by virtue of their dependence on rejected base claims.
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, 3, 6-8, 10, 13-14, 16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Quinlan et al., U.S. Patent Application Publication No. 2003/0130984 (hereinafter Quinlan) in view of De Atley et al., U.S. Patent Application Publication No. 2011/0252236 (hereinafter De Atley) in further view of Holt et al., U.S. Patent Application Publication No. 2012/0233251 (hereinafter Holt).
Regarding claim 1, Quinlan teaches:
A system for optimizing synchronization of content management servers, the system comprising: (Quinlan ¶ 0003: synchronizing information among two or more devices; Quinlan ¶ 0113-0114: Another alternative is to configure at least one synchronizing user device to operate as a control or "server" user device)
a hardware processor; and a non-transitory computer-readable medium storing instructions that are executable by the processor to: (Quinlan ¶ 0060: When implemented in software (e.g. as an application program, object, agent, downloadable, servlet, and so on in whole or part), a system 100 element can be communicated transitionally or more persistently from local or remote storage to memory (or cache memory, etc.) for execution, or another suitable mechanism can be utilized, and elements can be implemented in compiled or interpretive form. Input, intermediate or resulting data or functional elements can further reside more transitionally or more persistently in a storage media, cache or other volatile or non-volatile memory, (e.g. storage device 307 or memory 308) in accordance with a particular application)
a digital signature, (Quinlan FIG. 12, ¶ 0155: In step 1217, the first device optionally encrypts the modification indicator(s), if the modification indicator(s) is/are to be transferred in encrypted form)
a plurality of separate content synchronization messages, each of the separate content synchronization messages comprising a content identifier identifying a corresponding update which has been made to content stored on a content server, (Quinlan FIG. 12, ¶ 0155: In step 1217, the first device optionally encrypts the modification indicator(s), if the modification indicator(s) is/are to be transferred in encrypted form; see also Quinlan ¶ 0157-0158: in step 1111 (FIG. 11), the first device transfers the modification indicator (or synchronization message) to a routing system, such that the modification is capable of being received by the second device ... The routing system further receives from the first device a modification indicator indicating a modification to first device data in step 1303 [shows a content identifier identifying a corresponding update]; see also Quinlan ¶ 0063-0065: a more capable user device might be implemented to store, transfer or receive more synchronization messages [fortifying a plurality of synchronization messages]; Quinlan ¶ 0113-0114: Another alternative is to configure at least one synchronizing user device to operate as a control or "server" user device [shows device corresponding to a server])
the digital signature being generated, (Quinlan FIG. 12, ¶ 0155: In step 1217, the first device optionally encrypts the modification indicator(s), if the modification indicator(s) is/are to be transferred in encrypted form; see also Quinlan ¶ 0164: step 1411, the first device decrypts the modification indicator, if the indicator is encrypted)
verify, by the caching server, the digital signature… (Quinlan FIG. 12, ¶ 0151: wherein the first device retrieves recipient device identification and, if encrypted, decrypts the identification in step 1201; Quinlan FIG. 14, ¶ 0164: In step 1411, the first device decrypts the modification indicator, if the indicator is encrypted)
…
identify, by the caching server, a plurality of contents for synchronization corresponding to the plurality of separate content synchronization messages… (Quinlan FIG. 14, ¶ 0163: In step 1407, the first device receives from the routing system a modification indicator indicating a modification to second device data that was transferred to the routing system in response to an asynchronously triggering second device trigger (at least with respect to the first device trigger). In step 1409, the first device optionally determines whether the modification meets security requirements for synchronization)
synchronize, at the caching server, the plurality of contents by sending the digital signature in a request for synchronization, the synchronizing …comprising: (Quinlan FIG. 14, ¶ 0163: In step 1407, the first device receives from the routing system a modification indicator indicating a modification to second device data ... In step 1409, the first device optionally determines whether the modification meets security requirements for synchronization ... In step 1411, the first device decrypts the modification indicator, if the indicator is encrypted, and in step 1413, the first device synchronizes the second device modification with corresponding first device data, e.g., by adding, updating or deleting first device data)
establishing a … connection to the content server for … synchronizing the plurality of contents, (Quinlan FIGs. 11-14; see notably Quinlan FIG. 14, ¶ 0163-0164: It will be appreciated that all or a portion of modification indicators stored by a routing system may be retrieved from a routing system at once, in one synchronization "session" or in successive synchronization sessions)
wherein the digital signature is validated … for the plurality of separate content synchronization messages to authorize synchronization of the plurality of contents. (Quinlan FIG. 12, ¶ 0151-0152: wherein the first device retrieves recipient device identification and, if encrypted, decrypts the identification in step 1201; Quinlan FIG. 14, ¶ 0164: In step 1411, the first device decrypts the modification indicator, if the indicator is encrypted, and in step 1413, the first device synchronizes the second device modification with corresponding first device data, e.g., by adding, updating or deleting first device data ... (It will be appreciated that all or a portion of modification idicators stored by a routing system may be retrieved from a routing system at once, in one synchronization "session" or in successive synchronization sessions)
Quinlan does not expressly disclose:
receive, by a caching server, a wrapper message pointing to a synchronization file, the wrapper message being associated with a digital signature, the synchronization file comprising: a plurality of separate content synchronization messages,
the digital signature being generated from the plurality of separate content synchronization messages while excluding the content identifiers of the plurality of separate content synchronization messages;
Quinlan further does not expressly disclose the digital signature corresponding to the received wrapper message.
Quinlan further does not expressly disclose:
responsive to verifying the digital signature corresponding to the received wrapper message, download, by the caching server, the synchronization file pointed to by the wrapper message;
Quinlan further does not expressly disclose the plurality of separate content synchronization messages included in the downloaded synchronization file.
Quinlan further does not expressly disclose the synchronizing being based on the downloaded synchronization file.
Quinlan further does not expressly disclose:
establishing a single connection to the content server for collectively synchronizing the plurality of contents, wherein the digital signature is validated once for the plurality of separate content synchronization messages…
However, De Atley addresses this by teaching:
receive, by a caching server, a wrapper message pointing to a synchronization file, the wrapper message being associated with a digital signature, (De Atley FIG. 16, ¶ 0097-0098: The system 100 receives a backup ticket, a backup secret, and a host identifier at a first device (1610). The system also receives encrypted backup files, the backup key bag and associated metadata 1710 including encrypted file keys (1620) at the first device ... The host can provide the backup ticket and backup secret to unlock the escrow key bag as before [interpreted as pointing to the escrow key bag])
the synchronization file comprising: a plurality of separate content synchronization messages, (De Atley FIG. 7, ¶ 0083: A third key bag 730, the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
the digital signature being generated from the plurality of separate content synchronization messages while excluding the content identifiers of the plurality of separate content synchronization messages; (De Atley FIG. 6, ¶ 0074: The system 100 encrypts the class encryption keys based on a combination of one or more of a user passcode, a public encryption key and a unique device specific code depending on the type of key bag in which the keys are stored ... each key bag encrypts individual class keys in a unique way based, for example, on a unique combination of the user passcode, the public encryption key, and the unique device specific code; see De Atley FIG. 7, ¶ 0080-0083: the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
De Atley further teaches the digital signature corresponding to the received wrapper message. (De Atley FIG. 16, ¶ 0097-0098: The system decrypts the protection class keys in the backup key bag with the backup ticket (1630) and decrypts the file encryption keys with the corresponding decrypted protection class keys from the backup key bag (1640) on the first device)
De Atley further teaches:
responsive to verifying the digital signature corresponding to the received wrapper message, download, by the caching server, the synchronization file pointed to by the wrapper message; (De Atley FIG. 16, ¶ 0097-0098: The system 100 receives a backup ticket, a backup secret, and a host identifier at a first device (1610) ... Once the device decrypts the protection class keys and the file encryption keys [shows responsive to verification], the first device retrieves an escrow key bag containing original protection class keys (1650) [shows downloading of a synchronization file]; see notably De Atley ¶ 0098: The host can provide the backup ticket and backup secret to unlock the escrow key bag as before [interpreted as pointing to the escrow key bag]; see 'downloading' also in De Atley ¶ 0089: In one aspect, part of the escrow key bag is stored on the first device and part is stored on the second device. The second device can then combine the locally stored portion of the escrow key bag with the retrieved portion of the escrow key bag received from the first device to reconstitute the escrow key bag)
De Atley further teaches the plurality of separate content synchronization messages included in the downloaded synchronization file. (De Atley FIG. 16, ¶ 0097-0098: the first device retrieves an escrow key bag containing original protection class keys (1650); see this in light of De Atley FIG. 7, ¶ 0083: A third key bag 730, the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
De Atley further teaches the synchronizing being based on the downloaded synchronization file. (De Atley FIG. 16, ¶ 0097-0099: the first device retrieves an escrow key bag containing original protection class keys (1650), re-encrypts the decrypted file encryption keys with the original protection class keys (1660), and restores the encrypted backup files based on the re-encrypted file keys on the first device (1670) ... If the backup agent is restoring files from multiple backup repositories, such as files that were backed up during an incremental backup, the host is responsible for sending the appropriate backup key bag to the device; see also more explicit synchronization in De Atley FIGs. 18-22, notably ¶ 0104-0106: Once the system decrypts the files, the system can synchronize data with the second device (2340))
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 computing device synchronization of Quinlan with the device synchronization of De Atley.
In addition, both of the references (Quinlan and De Atley) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as device synchronization techniques.
Motivation to do so would be to improve the functioning of the teachings of Quinlan involving synchronizing data between devices with the teachings in similar reference De Atley involving synchronizing data between devices but with the improvement of layered encryption techniques.
Motivation to do so also would be the teaching, suggestion, or motivation in David to allow data stored in the system to implement desired levels of file security as seen in De Atley ¶ 0073.
Quinlan in view of De Atley does not expressly disclose:
establishing a single connection to the content server for collectively synchronizing the plurality of contents, wherein the digital signature is validated once for the plurality of separate content synchronization messages…
However, Holt addresses this by teaching:
establishing a single connection to the content server for collectively synchronizing the plurality of contents, wherein the digital signature is validated once for the plurality of separate content synchronization messages… (Holt FIGs. 12-13, ¶ 0130-0134: FIG. 12 shows a third embodiment with multiple containers linked in a synchronization tree. In such a configuration, a first container 812 is configured to sync simultaneously to a second container 814, a third container 816, and a fourth container 818 ... In some embodiments, it may not be desirable to use a single shared key [shows a single key serving as the primary/initial embodiment]. For example, a synchronization tree that provided content from a single upstream provider to a number of competitive downstream providers may not want to use a single key providing access to all of the containers in the tree, including the upstream container)
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 computing device synchronization of Quinlan as modified with the container synchronization of Holt.
In addition, both of the references (Quinlan as modified and Holt) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as synchronization techniques.
Motivation to do so would be to improve the functioning of the teachings of Quinlan as modified involving synchronizing data across a network with the teachings in similar reference De Atley also involving synchronizing data across a network but with the improvement of synchronization chains.
Motivation to do so also would be the teaching, suggestion, or motivation in David to allow data stored in the system to provide a better-functioning cloud computing system with superior operational capabilities as seen in Holt ¶ 0004.
Regarding claim 8, Quinlan teaches:
A computer-implemented method for optimizing synchronization of content management servers, the method comprising: (Quinlan ¶ 0003: synchronizing information among two or more devices; Quinlan ¶ 0113-0114: Another alternative is to configure at least one synchronizing user device to operate as a control or "server" user device)
a digital signature, (Quinlan FIG. 12, ¶ 0155: In step 1217, the first device optionally encrypts the modification indicator(s), if the modification indicator(s) is/are to be transferred in encrypted form)
a plurality of separate content synchronization messages, each of the separate content synchronization messages comprising a content identifier identifying a corresponding update which has been made to content stored on a content server, (Quinlan FIG. 12, ¶ 0155: In step 1217, the first device optionally encrypts the modification indicator(s), if the modification indicator(s) is/are to be transferred in encrypted form; see also Quinlan ¶ 0157-0158: in step 1111 (FIG. 11), the first device transfers the modification indicator (or synchronization message) to a routing system, such that the modification is capable of being received by the second device ... The routing system further receives from the first device a modification indicator indicating a modification to first device data in step 1303 [shows a content identifier identifying a corresponding update]; see also Quinlan ¶ 0063-0065: a more capable user device might be implemented to store, transfer or receive more synchronization messages [fortifying a plurality of synchronization messages]; Quinlan ¶ 0113-0114: Another alternative is to configure at least one synchronizing user device to operate as a control or "server" user device [shows device corresponding to a server])
the digital signature being generated, (Quinlan FIG. 12, ¶ 0155: In step 1217, the first device optionally encrypts the modification indicator(s), if the modification indicator(s) is/are to be transferred in encrypted form; see also Quinlan ¶ 0164: step 1411, the first device decrypts the modification indicator, if the indicator is encrypted)
verifying, by the caching server, the digital signature… (Quinlan FIG. 12, ¶ 0151: wherein the first device retrieves recipient device identification and, if encrypted, decrypts the identification in step 1201; Quinlan FIG. 14, ¶ 0164: In step 1411, the first device decrypts the modification indicator, if the indicator is encrypted)
…
identifying, by the caching server, a plurality of contents for synchronization corresponding to the plurality of separate content synchronization messages… (Quinlan FIG. 14, ¶ 0163: In step 1407, the first device receives from the routing system a modification indicator indicating a modification to second device data that was transferred to the routing system in response to an asynchronously triggering second device trigger (at least with respect to the first device trigger). In step 1409, the first device optionally determines whether the modification meets security requirements for synchronization)
synchronizing, at the caching server, the plurality of contents by sending the digital signature in a request for synchronization, the synchronizing …comprising: (Quinlan FIG. 14, ¶ 0163: In step 1407, the first device receives from the routing system a modification indicator indicating a modification to second device data ... In step 1409, the first device optionally determines whether the modification meets security requirements for synchronization ... In step 1411, the first device decrypts the modification indicator, if the indicator is encrypted, and in step 1413, the first device synchronizes the second device modification with corresponding first device data, e.g., by adding, updating or deleting first device data)
establishing a … connection to the content server for … synchronizing the plurality of contents, (Quinlan FIGs. 11-14; see notably Quinlan FIG. 14, ¶ 0163-0164: It will be appreciated that all or a portion of modification idicators stored by a routing system may be retrieved from a routing system at once, in one synchronization "session" or in successive synchronization sessions)
wherein the digital signature is validated … for the plurality of separate content synchronization messages to authorize synchronization of the plurality of contents. (Quinlan FIG. 12, ¶ 0151-0152: wherein the first device retrieves recipient device identification and, if encrypted, decrypts the identification in step 1201; Quinlan FIG. 14, ¶ 0164: In step 1411, the first device decrypts the modification indicator, if the indicator is encrypted, and in step 1413, the first device synchronizes the second device modification with corresponding first device data, e.g., by adding, updating or deleting first device data ... (It will be appreciated that all or a portion of modification idicators stored by a routing system may be retrieved from a routing system at once, in one synchronization "session" or in successive synchronization sessions)
Quinlan does not expressly disclose:
receiving, by a caching server, a wrapper message pointing to a synchronization file, the wrapper message being associated with a digital signature, the synchronization file comprising: a plurality of separate content synchronization messages,
the digital signature being generated from the plurality of separate content synchronization messages while excluding the content identifiers of the plurality of separate content synchronization messages;
Quinlan further does not expressly disclose the digital signature corresponding to the received wrapper message.
Quinlan further does not expressly disclose:
responsive to verifying the digital signature corresponding to the received wrapper message, download, by the caching server, the synchronization file pointed to by the wrapper message;
Quinlan further does not expressly disclose the plurality of separate content synchronization messages included in the downloaded synchronization file.
Quinlan further does not expressly disclose the synchronizing being based on the downloaded synchronization file.
Quinlan further does not expressly disclose:
establishing a single connection to the content server for collectively synchronizing the plurality of contents, wherein the digital signature is validated once for the plurality of separate content synchronization messages…
However, De Atley addresses this by teaching:
receiving, by a caching server, a wrapper message pointing to a synchronization file, the wrapper message being associated with a digital signature, (De Atley FIG. 16, ¶ 0097-0098: The system 100 receives a backup ticket, a backup secret, and a host identifier at a first device (1610). The system also receives encrypted backup files, the backup key bag and associated metadata 1710 including encrypted file keys (1620) at the first device ... The host can provide the backup ticket and backup secret to unlock the escrow key bag as before [interpreted as pointing to the escrow key bag])
the synchronization file comprising: a plurality of separate content synchronization messages, (De Atley FIG. 7, ¶ 0083: A third key bag 730, the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
the digital signature being generated from the plurality of separate content synchronization messages while excluding the content identifiers of the plurality of separate content synchronization messages; (De Atley FIG. 6, ¶ 0074: The system 100 encrypts the class encryption keys based on a combination of one or more of a user passcode, a public encryption key and a unique device specific code depending on the type of key bag in which the keys are stored ... each key bag encrypts individual class keys in a unique way based, for example, on a unique combination of the user passcode, the public encryption key, and the unique device specific code; see De Atley FIG. 7, ¶ 0080-0083: the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
De Atley further teaches the digital signature corresponding to the received wrapper message. (De Atley FIG. 16, ¶ 0097-0098: The system decrypts the protection class keys in the backup key bag with the backup ticket (1630) and decrypts the file encryption keys with the corresponding decrypted protection class keys from the backup key bag (1640) on the first device)
De Atley further teaches:
responsive to verifying the digital signature corresponding to the received wrapper message, downloading, by the caching server, the synchronization file pointed to by the wrapper message; (De Atley FIG. 16, ¶ 0097-0098: The system 100 receives a backup ticket, a backup secret, and a host identifier at a first device (1610) ... Once the device decrypts the protection class keys and the file encryption keys [shows responsive to verification], the first device retrieves an escrow key bag containing original protection class keys (1650) [shows downloading of a synchronization file]; see notably De Atley ¶ 0098: The host can provide the backup ticket and backup secret to unlock the escrow key bag as before [interpreted as pointing to the escrow key bag]; see 'downloading' also in De Atley ¶ 0089: In one aspect, part of the escrow key bag is stored on the first device and part is stored on the second device. The second device can then combine the locally stored portion of the escrow key bag with the retrieved portion of the escrow key bag received from the first device to reconstitute the escrow key bag)
De Atley further teaches the plurality of separate content synchronization messages included in the downloaded synchronization file. (De Atley FIG. 16, ¶ 0097-0098: the first device retrieves an escrow key bag containing original protection class keys (1650); see this in light of De Atley FIG. 7, ¶ 0083: A third key bag 730, the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
De Atley further teaches the synchronizing being based on the downloaded synchronization file. (De Atley FIG. 16, ¶ 0097-0099: the first device retrieves an escrow key bag containing original protection class keys (1650), re-encrypts the decrypted file encryption keys with the original protection class keys (1660), and restores the encrypted backup files based on the re-encrypted file keys on the first device (1670) ... If the backup agent is restoring files from multiple backup repositories, such as files that were backed up during an incremental backup, the host is responsible for sending the appropriate backup key bag to the device; see also more explicit synchronization in De Atley FIGs. 18-22, notably ¶ 0104-0106: Once the system decrypts the files, the system can synchronize data with the second device (2340))
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 computing device synchronization of Quinlan with the device synchronization of De Atley.
In addition, both of the references (Quinlan and De Atley) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as device synchronization techniques.
Motivation to do so would be to improve the functioning of the teachings of Quinlan involving synchronizing data between devices with the teachings in similar reference De Atley involving synchronizing data between devices but with the improvement of layered encryption techniques.
Motivation to do so also would be the teaching, suggestion, or motivation in David to allow data stored in the system to implement desired levels of file security as seen in De Atley ¶ 0073.
Quinlan in view of De Atley does not expressly disclose:
establishing a single connection to the content server for collectively synchronizing the plurality of contents, wherein the digital signature is validated once for the plurality of separate content synchronization messages…
However, Holt addresses this by teaching:
establishing a single connection to the content server for collectively synchronizing the plurality of contents, wherein the digital signature is validated once for the plurality of separate content synchronization messages… (Holt FIGs. 12-13, ¶ 0130-0134: FIG. 12 shows a third embodiment with multiple containers linked in a synchronization tree. In such a configuration, a first container 812 is configured to sync simultaneously to a second container 814, a third container 816, and a fourth container 818 ... In some embodiments, it may not be desirable to use a single shared key [shows a single key serving as the primary/initial embodiment]. For example, a synchronization tree that provided content from a single upstream provider to a number of competitive downstream providers may not want to use a single key providing access to all of the containers in the tree, including the upstream container)
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 computing device synchronization of Quinlan as modified with the container synchronization of Holt.
In addition, both of the references (Quinlan as modified and Holt) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as synchronization techniques.
Motivation to do so would be to improve the functioning of the teachings of Quinlan as modified involving synchronizing data across a network with the teachings in similar reference De Atley also involving synchronizing data across a network but with the improvement of synchronization chains.
Motivation to do so also would be the teaching, suggestion, or motivation in David to allow data stored in the system to provide a better-functioning cloud computing system with superior operational capabilities as seen in Holt ¶ 0004.
Regarding claim 14, Quinlan teaches:
A computer program product, comprising a non-transitory computer-readable medium having a computer-readable program code embodied therein to be executed by one or more processors, the program code including instructions to: (Quinlan ¶ 0060: When implemented in software (e.g. as an application program, object, agent, downloadable, servlet, and so on in whole or part), a system 100 element can be communicated transitionally or more persistently from local or remote storage to memory (or cache memory, etc.) for execution, or another suitable mechanism can be utilized, and elements can be implemented in compiled or interpretive form. Input, intermediate or resulting data or functional elements can further reside more transitionally or more persistently in a storage media, cache or other volatile or non-volatile memory, (e.g. storage device 307 or memory 308) in accordance with a particular application)
a digital signature, (Quinlan FIG. 12, ¶ 0155: In step 1217, the first device optionally encrypts the modification indicator(s), if the modification indicator(s) is/are to be transferred in encrypted form)
a plurality of separate content synchronization messages, each of the separate content synchronization messages comprising a content identifier identifying a corresponding update which has been made to content stored on a content server, (Quinlan FIG. 12, ¶ 0155: In step 1217, the first device optionally encrypts the modification indicator(s), if the modification indicator(s) is/are to be transferred in encrypted form; see also Quinlan ¶ 0157-0158: in step 1111 (FIG. 11), the first device transfers the modification indicator (or synchronization message) to a routing system, such that the modification is capable of being received by the second device ... The routing system further receives from the first device a modification indicator indicating a modification to first device data in step 1303 [shows a content identifier identifying a corresponding update]; see also Quinlan ¶ 0063-0065: a more capable user device might be implemented to store, transfer or receive more synchronization messages [fortifying a plurality of synchronization messages]; Quinlan ¶ 0113-0114: Another alternative is to configure at least one synchronizing user device to operate as a control or "server" user device [shows device corresponding to a server])
the digital signature being generated, (Quinlan FIG. 12, ¶ 0155: In step 1217, the first device optionally encrypts the modification indicator(s), if the modification indicator(s) is/are to be transferred in encrypted form; see also Quinlan ¶ 0164: step 1411, the first device decrypts the modification indicator, if the indicator is encrypted)
verify, by the caching server, the digital signature… (Quinlan FIG. 12, ¶ 0151: wherein the first device retrieves recipient device identification and, if encrypted, decrypts the identification in step 1201; Quinlan FIG. 14, ¶ 0164: In step 1411, the first device decrypts the modification indicator, if the indicator is encrypted)
…
identify, by the caching server, a plurality of contents for synchronization corresponding to the plurality of separate content synchronization messages… (Quinlan FIG. 14, ¶ 0163: In step 1407, the first device receives from the routing system a modification indicator indicating a modification to second device data that was transferred to the routing system in response to an asynchronously triggering second device trigger (at least with respect to the first device trigger). In step 1409, the first device optionally determines whether the modification meets security requirements for synchronization)
synchronize, at the caching server, the plurality of contents by sending the digital signature in a request for synchronization, the synchronizing …comprising: (Quinlan FIG. 14, ¶ 0163: In step 1407, the first device receives from the routing system a modification indicator indicating a modification to second device data ... In step 1409, the first device optionally determines whether the modification meets security requirements for synchronization ... In step 1411, the first device decrypts the modification indicator, if the indicator is encrypted, and in step 1413, the first device synchronizes the second device modification with corresponding first device data, e.g., by adding, updating or deleting first device data)
establishing a … connection to the content server for … synchronizing the plurality of contents, (Quinlan FIGs. 11-14; see notably Quinlan FIG. 14, ¶ 0163-0164: It will be appreciated that all or a portion of modification idicators stored by a routing system may be retrieved from a routing system at once, in one synchronization "session" or in successive synchronization sessions)
wherein the digital signature is validated … for the plurality of separate content synchronization messages to authorize synchronization of the plurality of contents. (Quinlan FIG. 12, ¶ 0151-0152: wherein the first device retrieves recipient device identification and, if encrypted, decrypts the identification in step 1201; Quinlan FIG. 14, ¶ 0164: In step 1411, the first device decrypts the modification indicator, if the indicator is encrypted, and in step 1413, the first device synchronizes the second device modification with corresponding first device data, e.g., by adding, updating or deleting first device data ... (It will be appreciated that all or a portion of modification idicators stored by a routing system may be retrieved from a routing system at once, in one synchronization "session" or in successive synchronization sessions)
Quinlan does not expressly disclose:
receive, by a caching server, a wrapper message pointing to a synchronization file, the wrapper message being associated with a digital signature, the synchronization file comprising: a plurality of separate content synchronization messages,
the digital signature being generated from the plurality of separate content synchronization messages while excluding the content identifiers of the plurality of separate content synchronization messages;
Quinlan further does not expressly disclose the digital signature corresponding to the received wrapper message.
Quinlan further does not expressly disclose:
responsive to verifying the digital signature corresponding to the received wrapper message, download, by the caching server, the synchronization file pointed to by the wrapper message;
Quinlan further does not expressly disclose the plurality of separate content synchronization messages included in the downloaded synchronization file.
Quinlan further does not expressly disclose the synchronizing being based on the downloaded synchronization file.
Quinlan further does not expressly disclose:
establishing a single connection to the content server for collectively synchronizing the plurality of contents, wherein the digital signature is validated once for the plurality of separate content synchronization messages…
However, De Atley addresses this by teaching:
receive, by a caching server, a wrapper message pointing to a synchronization file, the wrapper message being associated with a digital signature, (De Atley FIG. 16, ¶ 0097-0098: The system 100 receives a backup ticket, a backup secret, and a host identifier at a first device (1610). The system also receives encrypted backup files, the backup key bag and associated metadata 1710 including encrypted file keys (1620) at the first device ... The host can provide the backup ticket and backup secret to unlock the escrow key bag as before [interpreted as pointing to the escrow key bag])
the synchronization file comprising: a plurality of separate content synchronization messages, (De Atley FIG. 7, ¶ 0083: A third key bag 730, the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
the digital signature being generated from the plurality of separate content synchronization messages while excluding the content identifiers of the plurality of separate content synchronization messages; (De Atley FIG. 6, ¶ 0074: The system 100 encrypts the class encryption keys based on a combination of one or more of a user passcode, a public encryption key and a unique device specific code depending on the type of key bag in which the keys are stored ... each key bag encrypts individual class keys in a unique way based, for example, on a unique combination of the user passcode, the public encryption key, and the unique device specific code; see De Atley FIG. 7, ¶ 0080-0083: the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
De Atley further teaches the digital signature corresponding to the received wrapper message. (De Atley FIG. 16, ¶ 0097-0098: The system decrypts the protection class keys in the backup key bag with the backup ticket (1630) and decrypts the file encryption keys with the corresponding decrypted protection class keys from the backup key bag (1640) on the first device)
De Atley further teaches:
responsive to verifying the digital signature corresponding to the received wrapper message, download, by the caching server, the synchronization file pointed to by the wrapper message; (De Atley FIG. 16, ¶ 0097-0098: The system 100 receives a backup ticket, a backup secret, and a host identifier at a first device (1610) ... Once the device decrypts the protection class keys and the file encryption keys [shows responsive to verification], the first device retrieves an escrow key bag containing original protection class keys (1650) [shows downloading of a synchronization file]; see notably De Atley ¶ 0098: The host can provide the backup ticket and backup secret to unlock the escrow key bag as before [interpreted as pointing to the escrow key bag]; see 'downloading' also in De Atley ¶ 0089: In one aspect, part of the escrow key bag is stored on the first device and part is stored on the second device. The second device can then combine the locally stored portion of the escrow key bag with the retrieved portion of the escrow key bag received from the first device to reconstitute the escrow key bag)
De Atley further teaches the plurality of separate content synchronization messages included in the downloaded synchronization file. (De Atley FIG. 16, ¶ 0097-0098: the first device retrieves an escrow key bag containing original protection class keys (1650); see this in light of De Atley FIG. 7, ¶ 0083: A third key bag 730, the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
De Atley further teaches the synchronizing being based on the downloaded synchronization file. (De Atley FIG. 16, ¶ 0097-0099: the first device retrieves an escrow key bag containing original protection class keys (1650), re-encrypts the decrypted file encryption keys with the original protection class keys (1660), and restores the encrypted backup files based on the re-encrypted file keys on the first device (1670) ... If the backup agent is restoring files from multiple backup repositories, such as files that were backed up during an incremental backup, the host is responsible for sending the appropriate backup key bag to the device; see also more explicit synchronization in De Atley FIGs. 18-22, notably ¶ 0104-0106: Once the system decrypts the files, the system can synchronize data with the second device (2340))
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 computing device synchronization of Quinlan with the device synchronization of De Atley.
In addition, both of the references (Quinlan and De Atley) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as device synchronization techniques.
Motivation to do so would be to improve the functioning of the teachings of Quinlan involving synchronizing data between devices with the teachings in similar reference De Atley involving synchronizing data between devices but with the improvement of layered encryption techniques.
Motivation to do so also would be the teaching, suggestion, or motivation in David to allow data stored in the system to implement desired levels of file security as seen in De Atley ¶ 0073.
Quinlan in view of De Atley does not expressly disclose:
establishing a single connection to the content server for collectively synchronizing the plurality of contents, wherein the digital signature is validated once for the plurality of separate content synchronization messages…
However, Holt addresses this by teaching:
establishing a single connection to the content server for collectively synchronizing the plurality of contents, wherein the digital signature is validated once for the plurality of separate content synchronization messages… (Holt FIGs. 12-13, ¶ 0130-0134: FIG. 12 shows a third embodiment with multiple containers linked in a synchronization tree. In such a configuration, a first container 812 is configured to sync simultaneously to a second container 814, a third container 816, and a fourth container 818 ... In some embodiments, it may not be desirable to use a single shared key [shows a single key serving as the primary/initial embodiment]. For example, a synchronization tree that provided content from a single upstream provider to a number of competitive downstream providers may not want to use a single key providing access to all of the containers in the tree, including the upstream container)
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 computing device synchronization of Quinlan as modified with the container synchronization of Holt.
In addition, both of the references (Quinlan as modified and Holt) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as synchronization techniques.
Motivation to do so would be to improve the functioning of the teachings of Quinlan as modified involving synchronizing data across a network with the teachings in similar reference De Atley also involving synchronizing data across a network but with the improvement of synchronization chains.
Motivation to do so also would be the teaching, suggestion, or motivation in David to allow data stored in the system to provide a better-functioning cloud computing system with superior operational capabilities as seen in Holt ¶ 0004.
Regarding claims 3 and 10, Quinlan in view of De Atley and Holt teaches all the features with respect to claims 1 and 8 above respectively including:
further comprising the content server, (De Atley ¶ 0052, "The basic components are known to those of skill in the art and appropriate variations are contemplated depending on the type of device, such as whether the device 100 is a small, handheld computing device, a desktop computer, or a computer server" and ¶ 0077, "The backup host can be a computer, another mobile device, a server or collection of servers, a web service, or just a drive")
wherein the content server is configured to generate and store the synchronization file, (De Atley FIG. 6, ¶ 0074: The system 100 encrypts the class encryption keys based on a combination of one or more of a user passcode, a public encryption key and a unique device specific code depending on the type of key bag in which the keys are stored ... each key bag encrypts individual class keys in a unique way based, for example, on a unique combination of the user passcode, the public encryption key, and the unique device specific code; see De Atley FIG. 7, ¶ 0080-0083: the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
wherein in response to verifying the digital signature corresponding to the wrapper message, the caching server is configured to download the synchronization file from the content server via the single connection. (De Atley FIG. 16, ¶ 0097-0098: The system 100 receives a backup ticket, a backup secret, and a host identifier at a first device (1610) ... Once the device decrypts the protection class keys and the file encryption keys [shows responsive to verification], the first device retrieves an escrow key bag containing original protection class keys (1650) [shows downloading of a synchronization file]; see 'downloading' also in De Atley ¶ 0089: In one aspect, part of the escrow key bag is stored on the first device and part is stored on the second device. The second device can then combine the locally stored portion of the escrow key bag with the retrieved portion of the escrow key bag received from the first device to reconstitute the escrow key bag)
Regarding claim 16, Quinlan in view of De Atley and Holt teaches all the features with respect to claim 14 above including:
wherein the synchronization file is generated and stored by the content server, (De Atley FIG. 6, ¶ 0074: The system 100 encrypts the class encryption keys based on a combination of one or more of a user passcode, a public encryption key and a unique device specific code depending on the type of key bag in which the keys are stored ... each key bag encrypts individual class keys in a unique way based, for example, on a unique combination of the user passcode, the public encryption key, and the unique device specific code; see De Atley FIG. 7, ¶ 0080-0083: the escrow key bag, contains all class encryption keys encrypted by the unique device specific code and a public key 210 relating to an asymmetric key pair. The system 100 utilizes the escrow key bag 730 during synchronization and/or backup operations)
wherein the caching server downloads the synchronization file from the content server. (De Atley FIG. 16, ¶ 0097-0098: The system 100 receives a backup ticket, a backup secret, and a host identifier at a first device (1610) ... Once the device decrypts the protection class keys and the file encryption keys [shows responsive to verification], the first device retrieves an escrow key bag containing original protection class keys (1650) [shows downloading of a synchronization file]; see 'downloading' also in De Atley ¶ 0089: In one aspect, part of the escrow key bag is stored on the first device and part is stored on the second device. The second device can then combine the locally stored portion of the escrow key bag with the retrieved portion of the escrow key bag received from the first device to reconstitute the escrow key bag)
Regarding claims 6, 13, and 19, Quinlan in view of De Atley and Holt teaches all the features with respect to claims 1, 8, and 14 above including:
wherein the caching server synchronizes the plurality of contents identified from the plurality of content synchronization messages based on the verifying of only the digital signature corresponding to the wrapper message. (De Atley FIG. 16, ¶ 0097-0098: The system 100 receives a backup ticket, a backup secret, and a host identifier at a first device (1610). The system also receives encrypted backup files, the backup key bag and associated metadata 1710 including encrypted file keys (1620) at the first device ... Once the device decrypts the protection class keys and the file encryption keys, the first device retrieves an escrow key bag containing original protection class keys (1650) ... The host can provide the backup ticket and backup secret to unlock the escrow key bag as before)
Regarding claims 7 and 20, Quinlan in view of De Atley and Holt teaches all the features with respect to claims 1 and 14 above including:
wherein at least some of the plurality of contents for synchronization is synchronized to the content server by another caching server. (De Atley ¶ 0105-0110: a first exemplary data synchronization method embodiment for a host device. A first device sends a stored sync ticket to the second device having file-level data protection (2210) and synchronizes data with the second device ... the device and host, whether backup host or synchronization host, store different key bags; see also De Atley ¶ 0098-0100, "The system 100 can restore a backup to the same device that was the original source for the backup data or to another device" and "restoring a backup to a different device with the backup key bag"; see that devices can be servers in at least De Atley ¶ 0052, "The basic components are known to those of skill in the art and appropriate variations are contemplated depending on the type of device, such as whether the device 100 is a small, handheld computing device, a desktop computer, or a computer server" and ¶ 0077, "The backup host can be a computer, another mobile device, a server or collection of servers, a web service, or just a drive")
Claims 2, 9, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Quinlan in view of De Atley in further view of Holt in further view of David et al., U.S. Patent Application Publication No. 2014/0108474 (previously utilized in the rejection of the independent claims; filed October 16, 2012; hereinafter David).
Regarding claims 2, 9, and 15, Quinlan in view of De Atley and Holt teaches all the features with respect to claims 1, 8, and 14 above but does not expressly disclose:
wherein receiving the wrapper message comprises determining whether the wrapper message is expired, and wherein downloading the synchronization file comprises downloading the synchronization file in response to a determination that the wrapper message is not expired.
However, David addresses this by teaching:
wherein receiving the wrapper message comprises determining whether the wrapper message is expired, and (David ¶ 0240: The metadata container 1208 includes a plurality of metadata attributes; Time-to-live attribute 1306 specifies the amount of time data associated with metadata container 1208 is to be cached by the CDN 1102; the time-to-live attribute 1306 attribute and others are returned to the CDN 1102 as headers in an HTTP response [this shows the claimed 'receiving']. The CDN 1102 will then requery the data from the origin server after the specified amount of time)
wherein downloading the synchronization file comprises downloading the synchronization file in response to a determination that the wrapper message is not expired. (David FIG. 14, ¶ 0243-0244: At step 1408, the metadata stored in the hash container is retrieved. At step 1410, the metadata is checked to determine whether the requested data is CDN enabled. In one embodiment, this check involves checking if the "cdn_enabled" attribute from the metadata is set to True; At step 1416, the requested data is retrieved from the data path. At step 1418, a response is built including the received data [retrieving requested data is relevant to the claimed "downloading" of the file, occurring after the checking of metadata in steps 1408-1410]; ¶ 0240 shows checking metadata (in conjunction with a response) includes a time-to-live attribute: Time-to-live attribute 1306 specifies the amount of time data associated with metadata container 1208 is to be cached by the CDN 1102; the time-to-live attribute 1306 attribute and others are returned to the CDN 1102 as headers in an HTTP response)
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 content synchronization of Quinlan as modified with the provision of data to a content delivery network provider based on received requests shown in David.
In addition, both of the references (Quinlan as modified and David) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as data transfer and propagation associated with requests.
Motivation to do so would be to improve the functioning of the teachings of Quinlan as modified involving synchronizing data across a network with the teachings in similar reference David involving synchronizing data across a network but further involving returning data to requests based on verification of a signature provided alongside the request.
Motivation to do so also would be the teaching, suggestion, or motivation in David to allow data stored in the system to be replicated and served by a content delivery network and to integrate a high performance, scalable origin server into a cloud computing system as seen in David (¶ 0011).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Aharonov, U.S. Patent Application Publication No. 2009/0113215; see Aharonov FIGs. 3-4; see Aharonov ¶ 0025-0030 describing computing and updating signatures for higher levels of a hierarchy once rather than each time a (lower) data block changes; see Aharonov ¶ 0050 reading signatures at different levels of a hierarchy. These teachings are relevant to at least the independent claim limitations involving a digital signature being generated from a plurality of messages and involving validating a digital signature once.
GTOPIA Blog, “DER vs. CRT vs. CER vs. PEM Certificates and How To Convert Them”, https://web.archive.org/web/20190804070022/http://www.gtopia.org/blog/2010/02/der-vs-crt-vs-cer-vs-pem-certificates/ (February 4, 2010, archived on August 4, 2019, retrieved April 3, 2026); see notably pp1-2 referring to extensions for files for certificates and keys, relevant to the key bags in De Atley.
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 April 3, 2026
/KRIS E MACKES/Primary Examiner, Art Unit 2153