DETAILED ACTION
This Office Action is in response to the application 18/926,283 filed on 10/24/2024.
Claims 1-20 have been examined and are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This Action is made Non-FINAL.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 04/07/2025 and 12/08/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Priority
This patent application is continuation-in-part of and claims priority benefit under 35 U.S.C §120 to co-pending and commonly-owned U.S. Pat. App. No. 18/646,912, filed on 26 APRIL 2024.
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 discloses as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lie, Jr et al. (“Lie, Jr,” US 20170279781, published Sept. 28, 2017) in view of Ford et al. (“Ford,” US 20160352518, published Dec. 1, 2016).
Regarding claim 1, Lie, Jr. discloses A processor-implemented method for enabling recovery of a data object that has been secured comprising:
obtaining one or more secure measurements that represent one or more states or configurations of a computing device (Lie, Jr. [0036]. PCRs 402 are used for storing integrity measurements of software components present on the host platform 124. A software component may be, for example, an application executable, a configuration file or a data file. As is typical, measuring is done by hashing the software component with a hash function, such as SHA-1. The result is the integrity measurement of that software component. An integrity measurement may be stored in a particular PCR 402 by extending the PCR using the conventional extend operation: extend (PCR, new measurement)=SHA-1 (PCR+new measurement). A new measurement value is concatenated with the current PCR value and then hashed by SHA-1.);
obtaining a first input related to at least one secure measurement of the one or more secure measurements (Lie, Jr. [0036]. PCRs 402 are used for storing integrity measurements of software components present on the host platform 124. A software component may be, for example, an application executable, a configuration file or a data file. As is typical, measuring is done by hashing the software component with a hash function, such as SHA-1. The result is the integrity measurement of that software component. An integrity measurement may be stored in a particular PCR 402 by extending the PCR using the conventional extend operation: extend (PCR, new measurement)=SHA-1 (PCR+new measurement). A new measurement value is concatenated with the current PCR value and then hashed by SHA-1.);
obtaining a [recovery] key of a trusted entity (Lie, Jr. [0030], [0047]. VMM 208 includes a VM Validation Server (VMVS) 207. As described in more detail below, VMVS 207 enables a user computer 110 to validate the integrity and authenticity of an associated VM 210 in a confidential manner. In response to REG_REQ, VMVS 207 running on platform 124 creates a new entry in CDB 506 along with a unique client ID 314. VMVS 207 then transmits an acknowledgement message (REG_ACK) to user computer 110. The REG_ACK message may include the CP public keys CPK_PUB 404 a and CPSK_PUB 406 a, which may be retrieved and stored by VMVC 307 for later use as described below. CPK_PUB 404 a and CPSK_PUB 406 a may be certified and signed by a trusted certification authority (CA). Thus, VMVC 307 may verify the validity of the certificate before proceeding.);
obtaining a second input related to the [recovery] key of the trusted entity (Lie, Jr. [0030], [0047]. VMM 208 includes a VM Validation Server (VMVS) 207. As described in more detail below, VMVS 207 enables a user computer 110 to validate the integrity and authenticity of an associated VM 210 in a confidential manner. In response to REG_REQ, VMVS 207 running on platform 124 creates a new entry in CDB 506 along with a unique client ID 314. VMVS 207 then transmits an acknowledgement message (REG_ACK) to user computer 110. The REG_ACK message may include the CP public keys CPK_PUB 404 a and CPSK_PUB 406 a, which may be retrieved and stored by VMVC 307 for later use as described below. CPK_PUB 404 a and CPSK_PUB 406 a may be certified and signed by a trusted certification authority (CA). Thus, VMVC 307 may verify the validity of the certificate before proceeding.); and
using the first input and [the second input] as inputs to a secure OR policy module to secure a data object, in which the secure OR policy module unseals the secured data object if the secure OR policy module receives either the first input or the second input (Lie, Jr. [0023], [0028], [0034], [0038]. As shown, trusted platform 124 includes platform hardware 206, a virtual machine monitor (VMM) 208, and a number of virtual machines (VMs) 210 a-210 c. In some embodiments, HSM 204 is a TPM which is compliant with TCG Specification Version 1.2. VMM 208 includes a VM Validation Server (VMVS) 207. As described in more detail below, VMVS 207 enables a user computer 110 to validate the integrity and authenticity of an associated VM 210 in a confidential manner. VMM 208 may be configured to obtain keys CPK_PRV 404 b, CPSK_PRV 406 b, and TCK 408 from HSM 204 on an as-needed basis, and to erase those keys from its local memory when they are no longer needed. In such case, each time VMM 208 attempts to obtain a key from HSM 204, HSM 204 ascertains whether VMM 208 is trustworthy prior to releasing the key to it, for example by again checking that the value of the appropriate PCR 402 matches a predetermined value that defines a trusted software stack. [Note that the Specification [0210] explains that “the secure OR policy module (e.g., PolicyPCR [PCR is a platform configuration register]) may also be used to unseal objects.” The specification at [0158] also explains “PCRs, which were discussed above, are special registers in the TPM that store hash values representing the system’s configuration state. PCRs may be updated based on measurements taken during system boot and other critical events.”]).
Lie, Jr. does not explicitly disclose: a recovery key and using the first input and the second input as inputs to a secure OR policy module to secure a data object.
However, in an analogous art, Ford discloses a method, comprising the step of:
a recovery key and using [the first input and] the second input as inputs to a secure OR policy module to secure a data object (Ford [0069], [0073], [0078]. The process then encrypts (at 710) the private key of the device (i.e., the private key of the key pair for which the public key is shared with the other related devices and which is used to encrypt the master recovery key stored with the backup) using the generated escrow key in order to create a device-specific recovery object. As shown in FIG. 8, the public escrow key 815 (the output of the key generation function 810) is used as the key for the encryption function 820, which encrypts the private recovery key 825 (or seed data from which the private recovery key is deterministically generated). In some embodiments, the same encryption function is used for encrypting the recovery key as for encrypting the backup keybag and/or encrypting the master recovery key. The output of the encryption function 820 is a recovery object 830 for the particular device, which is the private key wrapped in a first layer of encryption. The high-security modules perform the decryption of the escrow objects (described below in Section II) and form secure connections with devices attempting to recover the registered private keys, but the proxy servers store the escrow objects and only send the objects to the high-security modules when a user provides the private escrow key verification data and requests the registered private recovery key in return. In some embodiments, when the device is initially set up (e.g., when the user first turns on the device, sets up the operating system, etc., the recovery key pair generator 930 generates a key pair for the device. This public/private key pair may be used by the device to sign itself into a synchronization circle with the other devices 910, protect data stored on the device, and enable recovery of backup data stored by the device 900 or any of the other devices 910.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Lie. Jr. and Ford to include the steps of: a recovery key and using the first input and the second input as inputs to a secure OR policy module to secure a data object. One would have been motivated to provide users with a means for using a pair of asymmetric keys as inputs to recover sensitive data that are backed up at other devices or servers. (See Ford [0078].)
Regarding claim 2, Lie, Jr. and Ford disclose the method of claim 1. Lie, Jr. further discloses wherein the step of obtaining a first input related to at least one secure measurement of the one or more secure measurements comprises: using at least one secure measurement of the one or more secure measurements or data related to at least one secure measurement as input to a secure policy module to obtain the first input (Lie, Jr. [0036], [0038]. PCRs 402 are used for storing integrity measurements of software components present on the host platform 124. A software component may be, for example, an application executable, a configuration file or a data file. As is typical, measuring is done by hashing the software component with a hash function, such as SHA-1. The result is the integrity measurement of that software component. An integrity measurement may be stored in a particular PCR 402 by extending the PCR using the conventional extend operation: extend (PCR, new measurement)=SHA-1 (PCR+new measurement). A new measurement value is concatenated with the current PCR value and then hashed by SHA-1. In such case, each time VMM 208 attempts to obtain a key from HSM 204, HSM 204 ascertains whether VMM 208 is trustworthy prior to releasing the key to it, for example by again checking that the value of the appropriate PCR 402 matches a predetermined value that defines a trusted software stack.).
Regarding claim 3, Lie, Jr. and Ford disclose the method of claim 2. Lie, Jr. further discloses wherein the at least one secure measurement of the one or more secure measurements or data related to at least one secure measurement comprises: one or more platform configuration register values (Lie, Jr. [0034], [0036]. As shown, HSM 204 includes a set of Platform Configuration Registers (PCRs) 402. PCRs 402 are used for storing integrity measurements of software components present on the host platform 124. A software component may be, for example, an application executable, a configuration file or a data file. As is typical, measuring is done by hashing the software component with a hash function, such as SHA-1.).
Regarding claim 4, Lie, Jr. and Ford disclose the method of claim 1. Lie, Jr. further discloses wherein the step of obtaining a second input related to the recovery key of the trusted entity comprises: using the [recovery] key and a policy authorization module to generate the second input (Lie, Jr. [0030], [0047]. VMM 208 includes a VM Validation Server (VMVS) 207. As described in more detail below, VMVS 207 enables a user computer 110 to validate the integrity and authenticity of an associated VM 210 in a confidential manner. In response to REG_REQ, VMVS 207 running on platform 124 creates a new entry in CDB 506 along with a unique client ID 314. VMVS 207 then transmits an acknowledgement message (REG_ACK) to user computer 110. The REG_ACK message may include the CP public keys CPK_PUB 404 a and CPSK_PUB 406 a, which may be retrieved and stored by VMVC 307 for later use as described below. CPK_PUB 404 a and CPSK_PUB 406 a may be certified and signed by a trusted certification authority (CA). Thus, VMVC 307 may verify the validity of the certificate before proceeding.)
Ford further discloses a recovery key (Ford [0073], [0078]. The high-security modules perform the decryption of the escrow objects (described below in Section II) and form secure connections with devices attempting to recover the registered private keys, but the proxy servers store the escrow objects and only send the objects to the high-security modules when a user provides the private escrow key verification data and requests the registered private recovery key in return. In some embodiments, when the device is initially set up (e.g., when the user first turns on the device, sets up the operating system, etc., the recovery key pair generator 930 generates a key pair for the device. This public/private key pair may be used by the device to sign itself into a synchronization circle with the other devices 910, protect data stored on the device, and enable recovery of backup data stored by the device 900 or any of the other devices 910.).
The motivation is the same as that of claim 1 above.
Regarding claim 5, Lie, Jr. and Ford disclose the method of claim 1. Ford further discloses responsive to change in the computing device which causes the first input to be a different value and fails to unseal the secure data object, entering a recovery mode to unseal the secure data object (Ford [0090], [0093], [0095]. However, when the escrow key attempt received from the requesting device is not correct (because, e.g., the user entered the wrong passcode or entered the passcode for the wrong device in order to generate the escrow key), the process adds (at 1030) to the count of incorrect attempts at acquiring the particular escrow object. As mentioned, some embodiments only allow a certain number of attempts (e.g., 5, 10, 25, 50, etc.) at a particular escrow object before locking the user out of the escrow object and not permitting any further attempts. In some embodiments, the device informs the user that the backup needs to be recovered with a passcode for a different one of the devices that have registered escrow objects, if such additional recovery objects exist with the secure escrow service. In other embodiments, the interface may ask the user for a series of inputs (e.g., questions only the user would know) as an alternative to or in addition to the device passcode.).
The motivation is the same as that of claim 1 above.
Regarding claim 6, Lie, Jr. and Ford disclose the method of claim 5. Lie, Jr. further discloses wherein the step of entering a recovery mode to unseal the secure data object comprise (Lie, Jr. [0038]. In such case, each time VMM 208 attempts to obtain a key from HSM 204, HSM 204 ascertains whether VMM 208 is trustworthy prior to releasing the key to it, for example by again checking that the value of the appropriate PCR 402 matches a predetermined value that defines a trusted software stack.):
sending one or more current secure measurements to a trusted management system (Lie, Jr. [0036]. [0052]. PCRs 402 are used for storing integrity measurements of software components present on the host platform 124. A software component may be, for example, an application executable, a configuration file or a data file. As is typical, measuring is done by hashing the software component with a hash function, such as SHA-1. The result is the integrity measurement of that software component. At steps 802, a registered user computer 110 indicates to platform 124 that it wishes platform 124 to execute a registered VM 210 by transmitting an execution request (EXE_REQ) message containing a nonce to platform 124. As is appreciated, a nonce is a unique cryptographic token that is only used once and is typically added to messages in order to prevent replay attacks.);
responsive to receiving a signed message from the trusted management system which is generated following the trusted management system’s validation of the one or more current secure measurements (Lie, Jr. FIG. 8, [0036], [0050], [0052], [0054]. A software component may be, for example, an application executable, a configuration file or a data file. As is typical, measuring is done by hashing the software component with a hash function, such as SHA-1. The result is the integrity measurement of that software component. Before transmitting the VM image, VMVC 307 running on user computer 110 signs and encrypts the VM image using client signing key 312 and client key 310. VMVC 307 then transmits the signed and encrypted VM image inside a message TX_VM. In response to the TX_VM message, VMVS 207 running on platform 124 retrieves from CKDB 504 encrypted copies of keys 310, 312 associated with the particular user computer 110, obtains TCK 408 from HSM 204, decrypts the encrypted copies of keys 310, 312 using TCK 408, and uses the decrypted copies of keys 310, 312 to decrypt the received VM image and verify its signature. At steps 802, a registered user computer 110 indicates to platform 124 that it wishes platform 124 to execute a registered VM 210 by transmitting an execution request (EXE_REQ) message containing a nonce to platform 124. As is appreciated, a nonce is a unique cryptographic token that is only used once and is typically added to messages in order to prevent replay attacks. VMVS 207 then obtains TCK 408 from HSM 204, decrypts the encrypted copies of keys 310, 312 using TCK 408, and uses the decrypted copies of keys 310, 312 to decrypt the retrieved VM image and verify its signature. Once the signature on the VM image is verified, VMVS 207 computes a freshness hash for the VM image, signs the freshness hash using client signing key 312, and transmits a check freshness hash (CHECK_FRESH) message containing the signed freshness hash and the received nonce to user computer 110. Advantageously, when such a snapshot occurs, the platform 124 provides the client with an updated freshness hash of the running VM so that, should a failure occur, the client can verify the integrity of the snapshot before execution resumes from the stored snapshot [through signature, see [0055]-[0056]]. FIG. 9 illustrates a sequence diagram for updating the client with a freshness hash of a provisioned and running VM 210 executing on a platform 124, according to an embodiment of the disclosure.),
using the [recovery] key of the trusted entity and the received signed message to validate the one or more current secure measurements; responsive to validating the received signed message (Lie, JR. [0050]. Once the signature on the VM image is verified, VMVS 207 computes a freshness hash of the VM image using the capabilities of HSM 204 in known manners. For example, this could be accomplished by computing a cryptographic hash, such as SHA-1, over the VM image. VMVS 207 then re-encrypts the VM image using client key 310, and stores the signed-and-encrypted VM image in VMIDB 502. VMVS 207 then signs the freshness hash using client signing key 312, and transmits an acknowledgement message (ACK_VM_RX) containing the signed freshness hash to user computer 110 acknowledging that TX_VM has been successfully processed. Upon receiving the ACK_VM_RX message, VMVC 307 verifies the signature on the received freshness hash, and stores the freshness hash.).
Ford further discloses a recovery key, supplying the second input to the secure OR policy module; and responsive to the second input satisfying one branch of the secure OR policy module, unsealing the secure data object (Ford [0069], [0073], [0078]. The process then encrypts (at 710) the private key of the device (i.e., the private key of the key pair for which the public key is shared with the other related devices and which is used to encrypt the master recovery key stored with the backup) using the generated escrow key in order to create a device-specific recovery object. As shown in FIG. 8, the public escrow key 815 (the output of the key generation function 810) is used as the key for the encryption function 820, which encrypts the private recovery key 825 (or seed data from which the private recovery key is deterministically generated). In some embodiments, the same encryption function is used for encrypting the recovery key as for encrypting the backup keybag and/or encrypting the master recovery key. The output of the encryption function 820 is a recovery object 830 for the particular device, which is the private key wrapped in a first layer of encryption. The high-security modules perform the decryption of the escrow objects (described below in Section II) and form secure connections with devices attempting to recover the registered private keys, but the proxy servers store the escrow objects and only send the objects to the high-security modules when a user provides the private escrow key verification data and requests the registered private recovery key in return. In some embodiments, when the device is initially set up (e.g., when the user first turns on the device, sets up the operating system, etc., the recovery key pair generator 930 generates a key pair for the device. This public/private key pair may be used by the device to sign itself into a synchronization circle with the other devices 910, protect data stored on the device, and enable recovery of backup data stored by the device 900 or any of the other devices 910.).
The motivation is the same as that of claim 5 above.
Regarding claim 7, Lie, Jr. and Ford disclose the method of claim 5. Lie, Jr. further discloses
wherein the step of entering a recovery mode to unseal the secure data object comprise (Lie, Jr. [0038]. In such case, each time VMM 208 attempts to obtain a key from HSM 204, HSM 204 ascertains whether VMM 208 is trustworthy prior to releasing the key to it, for example by again checking that the value of the appropriate PCR 402 matches a predetermined value that defines a trusted software stack.):
sending one or more current secure measurements to a trusted management system (Lie, Jr. [0036], [0052]. PCRs 402 are used for storing integrity measurements of software components present on the host platform 124. A software component may be, for example, an application executable, a configuration file or a data file. As is typical, measuring is done by hashing the software component with a hash function, such as SHA-1. The result is the integrity measurement of that software component. At steps 802, a registered user computer 110 indicates to platform 124 that it wishes platform 124 to execute a registered VM 210 by transmitting an execution request (EXE_REQ) message containing a nonce to platform 124. As is appreciated, a nonce is a unique cryptographic token that is only used once and is typically added to messages in order to prevent replay attacks.);
responsive to receiving a signed message from the trusted management system which is generated following the trusted management system’s validation of the one or more current secure measurements (Lie, Jr. FIG. 8, [0036], [0050], [0052], [0054]. A software component may be, for example, an application executable, a configuration file or a data file. As is typical, measuring is done by hashing the software component with a hash function, such as SHA-1. The result is the integrity measurement of that software component. Before transmitting the VM image, VMVC 307 running on user computer 110 signs and encrypts the VM image using client signing key 312 and client key 310. VMVC 307 then transmits the signed and encrypted VM image inside a message TX_VM. In response to the TX_VM message, VMVS 207 running on platform 124 retrieves from CKDB 504 encrypted copies of keys 310, 312 associated with the particular user computer 110, obtains TCK 408 from HSM 204, decrypts the encrypted copies of keys 310, 312 using TCK 408, and uses the decrypted copies of keys 310, 312 to decrypt the received VM image and verify its signature. At steps 802, a registered user computer 110 indicates to platform 124 that it wishes platform 124 to execute a registered VM 210 by transmitting an execution request (EXE_REQ) message containing a nonce to platform 124. As is appreciated, a nonce is a unique cryptographic token that is only used once and is typically added to messages in order to prevent replay attacks. VMVS 207 then obtains TCK 408 from HSM 204, decrypts the encrypted copies of keys 310, 312 using TCK 408, and uses the decrypted copies of keys 310, 312 to decrypt the retrieved VM image and verify its signature. Once the signature on the VM image is verified, VMVS 207 computes a freshness hash for the VM image, signs the freshness hash using client signing key 312, and transmits a check freshness hash (CHECK_FRESH) message containing the signed freshness hash and the received nonce to user computer 110. Advantageously, when such a snapshot occurs, the platform 124 provides the client with an updated freshness hash of the running VM so that, should a failure occur, the client can verify the integrity of the snapshot before execution resumes from the stored snapshot [through signature, see [0055]-[0056]]. FIG. 9 illustrates a sequence diagram for updating the client with a freshness hash of a provisioned and running VM 210 executing on a platform 124, according to an embodiment of the disclosure.),
using the [recovery] key of the trusted entity and the received signed message to validate the one or more current secure measurements; and responsive to validating the received signed message (Lie, JR. [0050]. Once the signature on the VM image is verified, VMVS 207 computes a freshness hash of the VM image using the capabilities of HSM 204 in known manners. For example, this could be accomplished by computing a cryptographic hash, such as SHA-1, over the VM image. VMVS 207 then re-encrypts the VM image using client key 310, and stores the signed-and-encrypted VM image in VMIDB 502. VMVS 207 then signs the freshness hash using client signing key 312, and transmits an acknowledgement message (ACK_VM_RX) containing the signed freshness hash to user computer 110 acknowledging that TX_VM has been successfully processed. Upon receiving the ACK_VM_RX message, VMVC 307 verifies the signature on the received freshness hash, and stores the freshness hash.):
obtaining a new first input related to at least one of the one or more current secure measurements (Lie, JR. [0055]-[0056]. After this is complete, platform 124 computes a freshness hash for the VM image, signs the freshness hash using client signing key 312 (which may have been retrieved from CKDB 504 and decrypted using TCK 408), and transmits a new freshness hash (NEW_FRESH) message containing the signed freshness hash to user computer 110. In response to the NEW_FRESH message, VMVC 307 running on registered computer 110 verifies the signature on the freshness hash using client signing key 312. VMVC 307 then stores the newly received freshness hash for future use, and transmits an ACK_NEW_FRESH message to platform 124.); and
using the new first input and [the second input] as inputs to the secure OR policy module to resecure the data object, in which the secure OR policy module unseals the secured data object if the secure OR policy module receives either the new first input or the second input (Lie, Jr. [0023], [0028], [0034], [0038]. As shown, trusted platform 124 includes platform hardware 206, a virtual machine monitor (VMM) 208, and a number of virtual machines (VMs) 210 a-210 c. In some embodiments, HSM 204 is a TPM which is compliant with TCG Specification Version 1.2. VMM 208 includes a VM Validation Server (VMVS) 207. As described in more detail below, VMVS 207 enables a user computer 110 to validate the integrity and authenticity of an associated VM 210 in a confidential manner. VMM 208 may be configured to obtain keys CPK_PRV 404 b, CPSK_PRV 406 b, and TCK 408 from HSM 204 on an as-needed basis, and to erase those keys from its local memory when they are no longer needed. In such case, each time VMM 208 attempts to obtain a key from HSM 204, HSM 204 ascertains whether VMM 208 is trustworthy prior to releasing the key to it, for example by again checking that the value of the appropriate PCR 402 matches a predetermined value that defines a trusted software stack. [Note that the Specification [0210] explains that “the secure OR policy module (e.g., PolicyPCR [PCR is a platform configuration register]) may also be used to unseal objects.” The specification at [0158] also explains “PCRs, which were discussed above, are special registers in the TPM that store hash values representing the system’s configuration state. PCRs may be updated based on measurements taken during system boot and other critical events.”]).
Ford discloses a method, comprising the step of:
a recovery key and using [the first input and] the second input as inputs to a secure OR policy module to resecure the data object (Ford [0069], [0073], [0078]. The process then encrypts (at 710) the private key of the device (i.e., the private key of the key pair for which the public key is shared with the other related devices and which is used to encrypt the master recovery key stored with the backup) using the generated escrow key in order to create a device-specific recovery object. As shown in FIG. 8, the public escrow key 815 (the output of the key generation function 810) is used as the key for the encryption function 820, which encrypts the private recovery key 825 (or seed data from which the private recovery key is deterministically generated). In some embodiments, the same encryption function is used for encrypting the recovery key as for encrypting the backup keybag and/or encrypting the master recovery key. The output of the encryption function 820 is a recovery object 830 for the particular device, which is the private key wrapped in a first layer of encryption. The high-security modules perform the decryption of the escrow objects (described below in Section II) and form secure connections with devices attempting to recover the registered private keys, but the proxy servers store the escrow objects and only send the objects to the high-security modules when a user provides the private escrow key verification data and requests the registered private recovery key in return. In some embodiments, when the device is initially set up (e.g., when the user first turns on the device, sets up the operating system, etc., the recovery key pair generator 930 generates a key pair for the device. This public/private key pair may be used by the device to sign itself into a synchronization circle with the other devices 910, protect data stored on the device, and enable recovery of backup data stored by the device 900 or any of the other devices 910.).
The motivation is the same as that of claim 5 above.
Regarding claim 8, claim 8 is directed to a non-transitory computer-readable medium corresponding to the method of claim 1. Claim 8 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 9, claim 9 is directed to a non-transitory computer-readable medium corresponding to the method of claim 2. Claim 9 is similar to claim 2 and is therefore rejected under similar rationale.
Regarding claim 10, claim 10 is directed to a non-transitory computer-readable medium corresponding to the method of claim 3. Claim 10 is similar to claim 3 and is therefore rejected under similar rationale.
Regarding claim 11, claim 11 is directed to a non-transitory computer-readable medium corresponding to the method of claim 4. Claim 11 is similar to claim 4 and is therefore rejected under similar rationale.
Regarding claim 12, claim 12 is directed to a non-transitory computer-readable medium corresponding to the method of claim 5. Claim 12 is similar to claim 5 and is therefore rejected under similar rationale.
Regarding claim 13, claim 13 is directed to a non-transitory computer-readable medium corresponding to the method of claim 6. Claim 13 is similar to claim 6 and is therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed to a non-transitory computer-readable medium corresponding to the method of claim 7. Claim 14 is similar to claim 7 and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to an information handling system corresponding to the method of claim 1. Claim 15 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is directed to an information handling system corresponding to the method of claim 2. Claim 16 is similar to claim 2 and is therefore rejected under similar rationale.
Regarding claim 17, claim 17 is directed to an information handling system corresponding to the method of claim 4. Claim 17 is similar to claim 4 and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is directed to an information handling system corresponding to the method of claim 5. Claim 18 is similar to claim 5 and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is directed to an information handling system corresponding to the method of claim 6. Claim 19 is similar to claim 6 and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is directed to an information handling system corresponding to the method of claim 7. Claim 20 is similar to claim 7 and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
