DETAILED ACTION
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 .
Priority
The instant application claims priority to US provisional applications 63/583,711 and 63/583,716. The priority claim for 63/583,711 complies with all applicable rules and regulations. Therefore, the effective filing date of the claims is 19 September 2023.
Information Disclosure Statement
The Information Disclosure Statement filed on 15 January 2026 complies with all applicable rules and regulations. Therefore, the information referred to therein has been considered.
Specification
No issues have been found with the amendment to the title.
Response to Arguments
Applicant’s arguments, see pages 9-10, filed 08 January 2026, with respect to the rejection of claims 1, 14, and 21 under 35 U.S.C. 102 (a)(1) have been fully considered and are persuasive in view of the new claim amendments. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Liu et al. (US 2022/0294614 A1) in view of Schaap et al. (US 2017/0201380 A1).
See the 35 U.S.C. 103 section below for a detailed analysis.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 4, 7, 14, 15, 16, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al. (US 2022/0294614 A1) in view of Schaap et al. (US 2017/0201380 A1).
Regarding claim 1, Liu teaches a first device, e.g., computing system 100/computing system 400 (Fig. 1, el. 100; Fig. 8, el. 400), wherein the computing system 100 can be a first device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle, an Internet of Things (loT) enabled device, an embedded computer, or such a first device that includes memory and a processing device (Para. 14), comprising:
a processor, e.g., processing device 118/processing device 402 (Fig. 1, el. 118; Fig. 8, el. 402);
memory, e.g., main memory 404/data storage system 418 (Fig. 8, el. 404, 418), accessible to the processor and having program instructions stored therein that are executable by the processor, e.g., the processing device 402 is configured to execute instructions 426 for performing the operations and steps discussed herein (Fig. 8, el. 426; Para. 121); the instructions 426 can also reside, completely or at least partially, within the main memory 404 and/or within the processing device 402 during execution thereof by the computer system 400 (Para. 122), to:
request performance of a key exchange to establish a shared secret with a second device, e.g., server 201/second device/remote first device (Fig. 4, el. 201; Para. 49); in block 502, the method receives a request to establish a communications session, wherein the request is received from an application running on a host system and identifies a remote first device, such as a server 201, to connect to (Fig. 5, el. 502; Para. 71); a host system 120 may issue commands to the memory device 130 via a bus and interface, wherein the device supports a command instructing the memory device 130 to communicate with a remote device (Fig. 1, el. 130; Para. 72); in block 504, the method establishes a shared symmetric key with a remote first device (Fig. 5, el. 504; Para. 77), wherein the shared symmetric key will ultimately be shared between the memory device and the remote first device, wherein the method establishes the shared symmetric key via an ECDH key exchange (Para. 78); and
a cryptographic circuit, e.g., crypto-processor 199 (Fig. 2, el. 199), coupled to a secure memory, e.g., memory device 130/memory regions 131-133 (Figs. 1, 2, el. 130; Fig. 2, el. 131 to 133), inaccessible to the processor, e.g., the controller 116 controls the communications over a bus coupled between the host system 120 and the memory sub-system 110, and the controller 116 can send commands or requests to the memory sub-system 110 for desired access to memory devices 130, 140 (Fig. 1, el. 110, 116; Para. 18), wherein the controller 116 is separate from the package of the processing device 118 (Para. 19),
wherein the cryptographic circuit is configured to:
…verifying a…data structure signed by a key authority…, e.g., the memory device will validate the message by validating a digital signature signed by the application using a public key stored on the memory device (Para. 116); and
…perform the key exchange including deriving the shared secret using private key material maintained in the secure memory, e.g., the memory device 130 may additionally include program logic and/or hardware for performing other cryptographic operations, wherein this program logic and/or hardware may be implemented as a crypto co-processor 199 in the memory device 130, wherein crypto co-processor 199 may be implemented in a memory sub-system 110 alternatively, or in addition to, implemented in the memory device 130, wherein these operations include the generation of a symmetric key (Para. 49); in block 504, the method establishes a shared symmetric key with a remote first device (Fig. 5, el. 504; Para. 77), wherein the shared symmetric key will ultimately be shared between the memory device and the remote first device, wherein the method establishes the shared symmetric key via an ECDH key exchange (Para. 78); Each device independently generates a shared key based on the public_random key and the device's private_key, wherein the memory sub-system 110 and a remote endpoint can share secret key without exposing secret data to intermediary devices, such as a host system 120 (Para. 80).
Liu does not clearly teach wherein the cryptographic circuit is configured to:
determine whether the key exchange is authorized by verifying a key authorization data structure signed by a key authority external to the first device to indicate that the first device is authorized to participate in the key exchange with the second device; and
in response to determining that the key exchange is authorized, perform the key exchange including deriving the shared secret using private key material maintained in the secure memory.
Schaap teaches wherein the cryptographic circuit, e.g., Secure Enclave Processor (SEP) 125 (Fig. 1, el. 125), wherein cryptographic operations performed by device 120 are performed by SEP 125, and SEP 125 is a dedicated secure circuit configured to securely store encryption keys used by device 120 and includes circuitry for performing cryptographic operations using those keys (Para. 23), is configured to:
determine whether the key exchange is authorized by verifying a key authorization data structure signed by a key authority, e.g., Trusted Server 130 (Fig. 1, el. 130), external to the first device to indicate that the first device is authorized to participate in the key exchange with the second device, e.g., peripheral device 110 (Fig. 1, el. 110);
devices 110 and/or 120 may then verify the signed data using the public key identified in the server's public-key certificate, wherein devices 110 and 120 may perform an initial pairing operation that begins with computing device 120 collecting authentication information from peripheral device 110 and conveying that information along with authentication information for device 120 to server 130 in a request 132, and in response to a successful verification of this authentication information and the hash value, server 130 may produce verification information 134 by generating signed data—key authorization data structure-- (i.e., one or more digital signatures) from all or a portion of the received authentication information and the received hash value (Fig. 1, el. 120; Para. 27);
server 130 maintains a list of authorized devices that are permitted to pair with one another, wherein this list may include authentication information that is able to uniquely identify a given device 110 or 120 (Para. 25);
Trusted server 130 may then verify the information in request 132 by using the maintained list, and in response to a successful verification, trusted server 130 may provide a verification information 134 at 416 in FIG. 1 that includes a digital signature generated from the information included in request 132 (Para. 53); and
in response to determining that the key exchange is authorized, perform the key exchange including deriving the shared secret using private key material maintained in the secure memory, e.g., after the new firmware 124 is booted, peripheral device 110 may perform a key exchange at 422 in order to establish a shared key to be used in exchanging encrypted information over connection 122 (Fig. 4A, el. 422; Para. 55);
the pairing operation includes performance of a key exchange, such as a Diffie-Hellman (DH) key exchange, in order to establish a shared secret, wherein device 120 may determine the shared key based a locally stored private key corresponding to the public key sent to device 110 and a public key that is received from device 120 corresponding to device 120's private key (Para. 23).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu to include wherein the cryptographic circuit is configured to: determine whether the key exchange is authorized by verifying a key authorization data structure signed by a key authority external to the first device to indicate that the first device is authorized to participate in the key exchange with the second device; and in response to determining that the key exchange is authorized, perform the key exchange including deriving the shared secret using private key material maintained in the secure memory, using the known method of receiving signatures of the data in the request from the server, and verifying the signatures at the devices, as taught by Schaap, in combination with the shared secret generation system of Liu, for the purpose of aiding in the assurance that the public key data is truly associated with each device, thereby increasing the security level of the devices and the system as a whole.
Regarding claim 2, Liu in view of Schaap teaches the first device of claim 1, further comprising: a read only memory (ROM) having immutable program instructions stored therein that are executable by the cryptographic circuit to perform the key exchange, e.g., the memory device 130 can be based on read-only memory (ROM) (Liu-Para. 23); the memory device 130 may additionally include program logic and/or hardware for performing other cryptographic operations, wherein this program logic and/or hardware may be implemented as a crypto co-processor 199 in the memory device 130, wherein crypto co-processor 199 may be implemented in a memory sub-system 110 alternatively, or in addition to, implemented in the memory device 130, wherein these operations include the generation of a symmetric key (Liu-Para. 49).
Regarding claim 4, Liu in view of Schaap teaches the first device of claim 1.
Liu does not clearly teach wherein the key authorization data structure includes a public key associated with the first device and a public key associated with the second device.
Schaap further teaches wherein the key authorization data structure includes a public key associated with the first device and a public key associated with the second device, e.g., computing device 120 then sends a verification request 132 at 414 asking for a signature of device 120's public key Cpub (corresponding to a public key from a pair 318), and this request 132 may also include additional information for signing such as a public key of device 110, and in response to a successful verification, trusted server 130 may provide a verification information 134 at 416 in FIG. 1 that includes a digital signature generated from the information included in request 132 (Para. 53).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu to include wherein the key authorization data structure includes a public key associated with the first device and a public key associated with the second device, using the known method of receiving signatures of the data in the request from the server, and verifying the signatures at the devices, as taught by Schaap, in combination with the shared secret generation system of Liu, using the same motivation as in claim 1.
Regarding claim 7, Liu in view of Schaap teaches the first device of claim 4, wherein the private key material includes a public key pair attested to using a private key of one of the public keys in the key authorization data structure; and wherein deriving the shared secret includes: performing Elliptic-curve Diffie–Hellman (ECDH) using the private key material, e.g., in an ECDH key exchange, both devices generate random key-pairs using the private key of the key-pair, and an ECC elliptic curve with generator point G, and the devices can then exchange public_random keys over an insecure network, and each device independently generates a shared key based on the public_random key and the device's private_key: shared_key =public_random*private_key (Liu-Para. 80);
Also note Schaap discloses the pairing operation includes performance of a key exchange, such as a Diffie-Hellman (DH) key exchange, in order to establish a shared secret, wherein device 120 may determine the shared key based a locally stored private key corresponding to the public key sent to device 110 and a public key that is received from device 120 corresponding to device 120's private key (Para. 23).
Regarding claim 14, the claim is analyzed with respect to claim 1. Liu in view of Schaap further teaches one or more non-transitory computer readable media, e.g., main memory 404/data storage system 418 (Liu-Fig. 8, el. 404, 418), having program instructions stored therein that are executable by a first device, e.g., computing system 100/computing system 400 (Liu-Fig. 1, el. 100; Fig. 8, el. 400), wherein the computing system 100 can be a first device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle, an Internet of Things (loT) enabled device, an embedded computer, or such a first device that includes memory and a processing device (Liu-Para. 14), to cause the first device perform the operations, e.g., the processing device 402 is configured to execute instructions 426 for performing the operations and steps discussed herein (Liu-Fig. 8, el. 426; Para. 121); the instructions 426 can also reside, completely or at least partially, within the main memory 404 and/or within the processing device 402 during execution thereof by the computer system 400 (Liu-Para. 122).
Regarding claim 15, Liu in view of Schaap teaches the computer readable media of claim 14, wherein the computer readable media include: a read only memory (ROM) having program instructions stored therein that are executable by the cryptographic circuit to perform the key exchange, e.g., the memory device 130 can be based on read-only memory (ROM) (Liu-Para. 23); the memory device 130 may additionally include program logic and/or hardware for performing other cryptographic operations, wherein this program logic and/or hardware may be implemented as a crypto co-processor 199 in the memory device 130, wherein crypto co-processor 199 may be implemented in a memory sub-system 110 alternatively, or in addition to, implemented in the memory device 130, wherein these operations include the generation of a symmetric key (Liu-Para. 49).
Regarding claim 16, Liu in view of Schaap teaches the computer readable media of claim 14.
Liu does not clearly teach wherein the operations further comprise: determining whether the key exchange is authorized by verifying a plurality of attestations associated with public key pairs exchanged during the key exchange.
Schaap further teaches determining whether the key exchange is authorized by verifying a plurality of attestations associated with public key pairs exchanged during the key exchange, e.g., devices 110 and 120 may perform an initial pairing operation that begins with first device 120 collecting authentication information from peripheral device 110 and conveying that information along with authentication information for device 120 to server 130 in a request 132, and in response to a successful verification of this authentication information and the hash value, server 130 may produce verification information 134 by generating signed data (i.e., one or more digital signatures)—plurality of attestations-- from all or a portion of the received authentication information and the received hash value, and devices 110 and/or 120 may then verify the signed data using the public key identified in the server's public-key certificate, and discontinuing of the paring operation may occur prior to performance of any key exchange as the signed authentication information may be used to establish a shared key between devices 110 and 120 (Fig. 1, el. 110, 120, 130, 132, 134; Para. 27); first device 120 then sends a verification request 132 at 414 asking for a signature of device 120's public key Cpub (corresponding to a public key from a pair 318), the nonce, the received epoch 236, and the generated hash value, wherein this request 132 may also include additional information for signing such as the serial number, a public key of device 110, etc. (Fig. 4A, el. 414; Para. 53); public key pairs 232 are public and private keys used by device 110 to communicate with second devices such as first device 120 (Fig. 2, el. 232; Para. 33); pairs 318 are public and private keys used by device 120 to communicate with second devices such as device 110 (Fig. 3, el. 318; Para. 43).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu to include wherein the operations further comprise: determining whether the key exchange is authorized by verifying a plurality of attestations associated with public key pairs exchanged during the key exchange, using the known method of sending the public keys of both devices in a request to a server, receiving signatures of the data in the request from the server, and verifying the signatures at the devices, as taught by Schaap, in combination with the shared secret generation system of Liu, for the purpose of aiding in the assurance that the public key data is truly associated with each device, thereby increasing the security level of the devices and the system as a whole.
Regarding claim 21, Liu teaches a method, comprising:
request, by a processor, e.g., processing device 118/processing device 402 (Fig. 1, el. 118; Fig. 8, el. 402), of a first device, e.g., computing system 100/computing system 400 (Fig. 1, el. 100; Fig. 8, el. 400), wherein the computing system 100 can be a first device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle, an Internet of Things (loT) enabled device, an embedded computer, or such a first device that includes memory and a processing device (Para. 14), performance of a key exchange to establish a shared secret with a second device, e.g., server 201/second device/remote first device (Fig. 4, el. 201; Para. 49); in block 502, the method receives a request to establish a communications session, wherein the request is received from an application running on a host system and identifies a remote first device, such as a server 201, to connect to (Fig. 5, el. 502; Para. 71); a host system 120 may issue commands to the memory device 130 via a bus and interface, wherein the device supports a command instructing the memory device 130 to communicate with a remote device (Fig. 1, el. 130; Para. 72); in block 504, the method establishes a shared symmetric key with a remote first device (Fig. 5, el. 504; Para. 77), wherein the shared symmetric key will ultimately be shared between the memory device and the remote first device, wherein the method establishes the shared symmetric key via an ECDH key exchange (Para. 78);
determining, by a cryptographic circuit, e.g., crypto-processor 199 (Fig. 2, el. 199) with memory device 130/memory regions 131-133 (Figs. 1, 2, el. 130; Fig. 2, el. 131 to 133),…verifying a…data structure signed…, wherein the…data structure is signed by a key authority…, e.g., the memory device will validate the message by validating a digital signature signed by the application using a public key stored on the memory device (Para. 116); and
…performing, by the cryptographic circuit, the key exchange including deriving the shared secret using private key material maintained in a secure memory, e.g., memory device 130/memory regions 131-133 (Figs. 1, 2, el. 130; Fig. 2, el. 131 to 133), coupled to the cryptographic circuit and inaccessible to the processor, e.g., the memory device 130 may additionally include program logic and/or hardware for performing other cryptographic operations, wherein this program logic and/or hardware may be implemented as a crypto co-processor 199 in the memory device 130, wherein crypto co-processor 199 may be implemented in a memory sub-system 110 alternatively, or in addition to, implemented in the memory device 130, wherein these operations include the generation of a symmetric key (Para. 49); in block 504, the method establishes a shared symmetric key with a remote first device (Fig. 5, el. 504; Para. 77), wherein the shared symmetric key will ultimately be shared between the memory device and the remote first device, wherein the method establishes the shared symmetric key via an ECDH key exchange (Para. 78); Each device independently generates a shared key based on the public_random key and the device's private_key, wherein the memory sub-system 110 and a remote endpoint can share secret key without exposing secret data to intermediary devices, such as a host system 120 (Para. 80);
the controller 116 controls the communications over a bus coupled between the host system 120 and the memory sub-system 110, and the controller 116 can send commands or requests to the memory sub-system 110 for desired access to memory devices 130, 140 (Fig. 1, el. 110, 116; Para. 18), wherein the controller 116 is separate from the package of the processing device 118 (Para. 19).
Liu does not clearly teach determining, by a cryptographic circuit, whether the key exchange is authorized by verifying a key authorization data structure signed to indicate that the first device is authorized to participate in the key exchange with the second device, wherein the key authorization data structure is signed by a key authority distinct from the first device and the second device; and
in response to determining that the key exchange is authorized, performing, by the cryptographic circuit, the key exchange including deriving the shared secret using private key material maintained in a secure memory coupled to the cryptographic circuit and inaccessible to the processor.
Schaap teaches determining, by a cryptographic circuit, e.g., Secure Enclave Processor (SEP) 125 (Fig. 1, el. 125), wherein cryptographic operations performed by device 120 are performed by SEP 125, and SEP 125 is a dedicated secure circuit configured to securely store encryption keys used by device 120 and includes circuitry for performing cryptographic operations using those keys (Para. 23), whether the key exchange is authorized by verifying a key authorization data structure signed to indicate that the first device, e.g., computing device 120 (Fig. 1, el. 120), is authorized to participate in the key exchange with the second device, e.g., peripheral device 110 (Fig. 1, el. 110);
devices 110 and/or 120 may then verify the signed data using the public key identified in the server's public-key certificate, wherein devices 110 and 120 may perform an initial pairing operation that begins with computing device 120 collecting authentication information from peripheral device 110 and conveying that information along with authentication information for device 120 to server 130 in a request 132, and in response to a successful verification of this authentication information and the hash value, server 130 may produce verification information 134 by generating signed data—key authorization data structure-- (i.e., one or more digital signatures) from all or a portion of the received authentication information and the received hash value (Fig. 1, el. 120; Para. 27);
server 130 maintains a list of authorized devices that are permitted to pair with one another, wherein this list may include authentication information that is able to uniquely identify a given device 110 or 120 (Para. 25);
Trusted server 130 may then verify the information in request 132 by using the maintained list, and in response to a successful verification, trusted server 130 may provide a verification information 134 at 416 in FIG. 1 that includes a digital signature generated from the information included in request 132 (Para. 53);
wherein the key authorization data structure is signed by a key authority, e.g., Trusted Server 130 (Fig. 1, el. 130), distinct from the first device and the second device, e.g., in response to a successful verification of this authentication information and the hash value, server 130 may produce verification information 134 by generating signed data—key authorization data structure-- (i.e., one or more digital signatures) from all or a portion of the received authentication information and the received hash value (Fig. 1, el. 120; Para. 27);
Trusted server 130 may then verify the information in request 132 by using the maintained list, and in response to a successful verification, trusted server 130 may provide a verification information 134 at 416 in FIG. 1 that includes a digital signature generated from the information included in request 132 (Para. 53); and
in response to determining that the key exchange is authorized, performing, by the cryptographic circuit, the key exchange including deriving the shared secret using private key material maintained in a secure memory coupled to the cryptographic circuit and inaccessible to the processor, e.g., after the new firmware 124 is booted, peripheral device 110 may perform a key exchange at 422 in order to establish a shared key to be used in exchanging encrypted information over connection 122 (Fig. 4A, el. 422; Para. 55);
the pairing operation includes performance of a key exchange, such as a Diffie-Hellman (DH) key exchange, in order to establish a shared secret, wherein device 120 may determine the shared key based a locally stored private key corresponding to the public key sent to device 110 and a public key that is received from device 120 corresponding to device 120's private key (Para. 23);
SEP 125 is a dedicated secure circuit configured to securely store encryption keys used by device 120 and includes circuitry for performing cryptographic operations using those keys, and (as used herein, the term “secure circuit” refers to a circuit that protects an isolated, internal resource from being directly accessed by an external circuit.) (Para. 23).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu to include determining, by a cryptographic circuit, whether the key exchange is authorized by verifying a key authorization data structure signed to indicate that the first device is authorized to participate in the key exchange with the second device, wherein the key authorization data structure is signed by a key authority distinct from the first device and the second device; and in response to determining that the key exchange is authorized, performing, by the cryptographic circuit, the key exchange including deriving the shared secret using private key material maintained in a secure memory coupled to the cryptographic circuit and inaccessible to the processor, using the known method of receiving signatures of the data in the request from the server, and verifying the signatures at the devices, as taught by Schaap, in combination with the shared secret generation system of Liu, for the purpose of aiding in the assurance that the public key data is truly associated with each device, thereby increasing the security level of the devices and the system as a whole.
Claims 3, 12, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Schaap and further in view of Sykora et al. (US 2017/0373844 A1).
Regarding claim 3, Liu in view of Schaap teaches the first device of claim 1.
Liu further teaches wherein the cryptographic circuit is configured to: execute a sequence of program instructions in a particular order to perform the key exchange, e.g., the memory device 130 may additionally include program logic and/or hardware for performing other cryptographic operations, wherein this program logic and/or hardware may be implemented as a crypto co-processor 199 in the memory device 130, wherein crypto co-processor 199 may be implemented in a memory sub-system 110 alternatively, or in addition to, implemented in the memory device 130, wherein these operations include the generation of a symmetric key (Liu-Para. 49); in block 504, the method establishes a shared symmetric key with a remote first device (Liu-Fig. 5, el. 504; Para. 77), wherein the shared symmetric key will ultimately be shared between the memory device and the remote first device, wherein the method establishes the shared symmetric key via an ECDH key exchange (Liu-Para. 78).
Liu in view of Schaap does not clearly teach to: prevent out of order execution of the sequence by clearing, in response to receiving a given program instruction in the sequence, a portion of the secure memory used by the next program instruction in the particular order.
Sykora teaches wherein the cryptographic circuit, e.g., a secure enclave processor (SEP) 114 (Fig. 3, el. 114), is configured to:
execute a sequence of program instructions in a particular order to perform the key exchange, e.g., Secure enclave processor (SEP) 114 is one embodiment of a secure circuit or a secure component, wherein the term “secure circuit” refers to a circuit that protects an isolated, internal resource from being directly accessed by an external circuit, wherein this internal resource may also be circuitry that performs services/operations associated with sensitive data., wherein these services may include various cryptographic services such as authentication, encryption, decryption, etc., wherein secure services may include secure key generation, which may include shared secret keys and asymmetric keys (Para. 21); and
prevent out of order execution of the sequence by clearing, in response to receiving a given program instruction in the sequence, a portion of the secure memory used by the next program instruction in the particular order, e.g., each subcommand sequence from sequencer 342 may include subcommands performed after the result is determined for a given command, to overwrite the memory locations in memory 346 that were used during processing of the given command (Fig. 3, el. 342, 346; Para. 55).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu in view of Schaap to include wherein the cryptographic circuit is configured to: prevent out of order execution of the sequence by clearing, in response to receiving a given program instruction in the sequence, a portion of the secure memory used by the next program instruction in the particular order, using the known method of overwriting memory locations that were used during the processing of the given command by a sequencer, as taught by Sykora, in combination with the shared secret generation system of Liu in view of Schaap, for the purpose of further enhancing security (Sykora-Para. 55), by rendering the memory locations unreadable.
Regarding claim 12, Liu in view of Schaap teaches the first device of claim 1.
Liu in view of Schaap does not clearly teach further comprising: a fuse bank coupled to the cryptographic circuit and inaccessible to the processor, wherein the fuse bank is configured at fabrication of the cryptographic circuit to store key material usable by the cryptographic circuit to derive a portion of the private key material stored in the secure memory.
Sykora teaches a fuse bank, e.g., fuses 332 (Fig. 3, el. 332), coupled to the cryptographic circuit, e.g., a secure enclave processor (SEP) 114 (Fig. 3, el. 114), and inaccessible to the processor, e.g., SEP 114 is isolated from instructions executable on CPU 112 (e.g., applications 132) except through a mailbox mechanism in SEP 114 (Para. 24),
wherein the fuse bank is configured at fabrication of the cryptographic circuit to store key material usable by the cryptographic circuit to derive a portion of the private key material stored in the secure memory, e.g., PKA IP circuit 344 may be configured to receive private keys from key storage 330 and/or fuses 332 (Para. 47); fuses 332 may maintain one or more keys that are stored at fabrication of SEP 114 (Para. 54); memory 346 may store private keys or values derived from private keys in key storage 330 and fuses 332 (Fig. 3, el. 346; Para. 55).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu in view of Schaap to include a fuse bank coupled to the cryptographic circuit and inaccessible to the processor, wherein the fuse bank is configured at fabrication of the cryptographic circuit to store key material usable by the cryptographic circuit to derive a portion of the private key material stored in the secure memory, using the known method of deriving and storing private keys from private keys in fuses, as taught by Sykora, in combination with the shared secret generation system of Liu in view of Schaap, for the purpose of using key material that is unable to overwritten thereby aiding in the prevention of an attacker compromising the system.
Regarding claim 13, Liu in view of Schaap teaches the first device of claim 1.
Liu in view of Schaap does not clearly teach wherein the cryptographic circuit is a public key accelerator.
Sykora teaches wherein the cryptographic circuit is a public key accelerator, e.g., SEP 114 includes a public key accelerator (PKA) (Fig. 3, el. 114; 230A; Para. 30); security peripheral 230A is public key accelerator (PKA) (Para. 47).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu in view of Schaap to include a wherein the cryptographic circuit is a public key accelerator, using the known system that includes a public key accelerator, as taught by Sykora, in combination with the shared secret generation system of Liu in view of Schaap, for the purpose of improving system performance and security by offloading cryptography tasks, thereby enhancing the speed of the tasks.
Claims 5 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Schaap in view of Balfanz et al. (US 2004/0103280 A1) and further in view of Leyfman et al. (US 2019/0304507 A1).
Regarding claim 5, Liu in view of Schaap teaches the first device of claim 4.
Liu in view of Schaap further teaches wherein the key authorization data structure indicates an authorization for a key exchange between a first device…and a second device…, e.g., the memory device 130 may additionally include program logic and/or hardware for performing other cryptographic operations, wherein this program logic and/or hardware may be implemented as a crypto co-processor 199 in the memory device 130, wherein crypto co-processor 199 may be implemented in a memory sub-system 110 alternatively, or in addition to, implemented in the memory device 130, wherein these operations include the generation of a symmetric key (Liu-Para. 49);
computing device 120 then sends a verification request 132 at 414 asking for a signature of device 120's public key Cpub (corresponding to a public key from a pair 318), and this request 132 may also include additional information for signing such as a public key of device 110, and in response to a successful verification, trusted server 130 may provide a verification information 134 at 416 in FIG. 1 that includes a digital signature generated from the information included in request 132 (Schaap-Para. 53).
Liu in view of Schaap does not clearly teach wherein the key authorization data structure indicates an authorization for a key exchange between a first device group and a second device group;
wherein the public key associated with the first device is of a first participant authority authorized to identify the first device as a member of the first device group; and
wherein the public key associated with the second device is of a second participant authority authorized to identify the second device as a member of the second device group.
Balfanz teaches wherein the public key associated with the first device is of a first participant authority authorized to identify the first device as a member of the first device group, e.g., the laptop 12(1)—first participant authority-- updates the group member list 30 by retrieving the laptop 12(2) public key, sent to the laptop 12(1) at step 420, from its temporary memory, and adding it to the group member list 30 stored in the laptop 12(1) memory (Fig. 6, el. 420; Para. 43); at step 620, the laptop 12(3) server software server software authenticates itself to the server software of the other file sharing group members' machines, which in this case also includes laptops 12(1), 12(2), and the laptop 12(3) sends its public key to the laptops 12(1), 12(2), each of which inspects its locally stored updated member list to determine whether the laptop 12(3) is a member of the group (Fig. 9, el. 620; Par. 68); and
wherein the public key associated with the second device is of a second participant authority authorized to identify the second device as a member of the second device…, e.g., at step 510, the laptop 12(2)—key authority-- updates its group member list 32 by retrieving the laptop 12(3) public key, sent to the laptop 12(2) at step 420, from its temporary memory and adding it the group member list 32 stored in the laptop 12(2) memory (Fig. 7, el. 510; Para. 64); at step 520, the laptop 12(2)—key authority-- sends the updated group member list 32 to the other group members, such as laptops 12(1), 12(3) (Fig. 7, el. 520; Para. 65); at step 620, the laptop 12(3) server software server software authenticates itself to the server software of the other file sharing group members' machines, which in this case also includes laptops 12(1), 12(2), and the laptop 12(3) sends its public key to the laptops 12(1), 12(2), each of which inspects its locally stored updated member list to determine whether the laptop 12(3) is a member of the group (Fig. 9, el. 620; Par. 68).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective fling date of the claimed invention to modify Liu in view of Schaap to include wherein the key authorization data structure indicates an authorization for a key exchange between a first device group and a second device; wherein the public key associated with the first device is of a first participant authority authorized to identify the first device as a member of the first device group; and wherein the public key associated with the second device is of a second participant authority authorized to identify the second device as a member of the second device, using the known method of enabling a laptop to add another laptop’s public key to the group list and send the updated group list to all group members, wherein the group list includes the public keys of each group member, and comparing a received public key from a laptop to the group list to determine if it is a group member, as taught by Balfanz, in combination with the shared secret generation system of Liu in view of Schaap, for the purpose of making it easy for users to securely share resources (Balfanz-Para. 19).
Liu in view of Schaap in view of Balfanz does not explicitly teach wherein the key authorization data structure indicates an authorization for a key exchange between a first device group and a second device group; and
wherein the public key associated with the second device is of a second participant authority authorized to identify the second device as a member of the second device group.
Leyfman teaches wherein the…authorization data structure indicates an authorization for pairing between a first device group and a second device group, e.g., user device 1210 may include a home application 332 that allows the user of user device 1210 to specify users and/or user devices that are authorized to user playback devices within the user's home or other environment, wherein authorized user database 1212 can include device identifiers for each authorized user device (Fig. 12, el. 1210, 1212; Para. 114); user device 1220 can store the received authorized user database 1212 as authorized user database 1222 or update authorized user database 1222 with the data and/or tokens in authorized user database 1212, and after saving or updating authorized user database 1222, database 1222 now has the pairing token generated for the device identifier of user device 1220 and/or the user identifier of the user of user device 1220 by playback device 320, wherein when user device 1220 attempts to pair with playback device 320 for the first time, user device 1220 can send the pairing token and its device identifier and/or user identifier to playback device 320 (Para. 118); the group member attributes can include a group leader flag, wherein if the playback device (e.g., playback device 320) is the group leader (e.g., primary playback device), the group leader flag will be set to true (Para. 58); and
wherein the group attributes associated with the second device is of a second participant authority authorized to identify the second device as a member of the second device group, e.g., the group member attributes can include a group identifier, wherein the group identifier can be assigned to playback devices by the primary playback device (Para. 57); the group member attributes can include a group leader flag, wherein if the playback device (e.g., playback device 320) is the group leader (e.g., primary playback device), the group leader flag will be set to true (Para. 58).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu in view of Schaap in view of Balfanz to include wherein the key authorization data structure indicates an authorization for a key exchange between a first device group and a second device group; and wherein the public key associated with the second device is of a second participant authority authorized to identify the second device as a member of the second device group, using the known system of having a group of user devices and a group of playback devices and a database in each device that indicates the user devices that are authorized to pair with the playback devices, as taught by Leyfman, in combination with the shared secret generation system of Liu in view of Schaap in view of Balfanz, for the purpose of providing for aiding in the prevention of inappropriately pairing with a neighbor’s device.
Regarding claim 17, Liu in view of Schaap teaches the computer readable media of claim 16.
Liu in view of Schaap further teaches wherein the plurality of attestations include:
a first key attestation identifying a public key of the first device…, e.g., in response to a successful verification of this authentication information and the hash value, server 130 may produce verification information 134 by generating signed data (i.e., one or more digital signatures)—plurality of attestations-- from all or a portion of the received authentication information and the received hash value, and devices 110 and/or 120 may then verify the signed data using the public key identified in the server's public-key certificate (Schaap-Fig. 1, el. 110, 120, 130, 132, 134; Para. 27); first device 120 then sends a verification request 132 at 414 asking for a signature of device 120's public key Cpub (corresponding to a public key from a pair 318), the nonce, the received epoch 236, and the generated hash value, wherein this request 132 may also include additional information for signing such as the serial number, a public key of device 110, etc. (Schaap-Fig. 4A, el. 414; Para. 53); and
a second key attestation identifying a public key of the second device…, e.g., in response to a successful verification of this authentication information and the hash value, server 130 may produce verification information 134 by generating signed data (i.e., one or more digital signatures)—plurality of attestations-- from all or a portion of the received authentication information and the received hash value, and devices 110 and/or 120 may then verify the signed data using the public key identified in the server's public-key certificate (Schaap-Fig. 1, el. 110, 120, 130, 132, 134; Para. 27); first device 120 then sends a verification request 132 at 414 asking for a signature of device 120's public key Cpub (corresponding to a public key from a pair 318), the nonce, the received epoch 236, and the generated hash value, wherein this request 132 may also include additional information for signing such as the serial number, a public key of device 110, etc. (Schaap-Fig. 4A, el. 414; Para. 53).
Liu in view of Schaap does not clearly teach wherein the plurality of attestations include:
a first key attestation identifying a public key of the first device as corresponding to a member of a first device group; and
a second key attestation identifying a public key of the second device as corresponding to a member of a second device group.
Balfanz teaches wherein the plurality of attestations include:
a first key attestation identifying a public key of the first device as corresponding to a member of a first device group, e.g., the laptop 12(1)—first participant authority-- updates the group member list 30 by retrieving the laptop 12(2) public key, sent to the laptop 12(1) at step 420, from its temporary memory, and adding it to the group member list 30 stored in the laptop 12(1) memory (Fig. 6, el. 420; Para. 43); at step 620, the laptop 12(3) server software server software authenticates itself to the server software of the other file sharing group members' machines, which in this case also includes laptops 12(1), 12(2), and the laptop 12(3) sends its public key to the laptops 12(1), 12(2), each of which inspects its locally stored updated member list to determine whether the laptop 12(3) is a member of the group (Fig. 9, el. 620; Par. 68); and
a second key attestation identifying a public key of the second device as corresponding to a member of a second device…, e.g., at step 510, the laptop 12(2)—key authority-- updates its group member list 32 by retrieving the laptop 12(3) public key, sent to the laptop 12(2) at step 420, from its temporary memory and adding it the group member list 32 stored in the laptop 12(2) memory (Fig. 7, el. 510; Para. 64); at step 520, the laptop 12(2)—key authority-- sends the updated group member list 32 to the other group members, such as laptops 12(1), 12(3) (Fig. 7, el. 520; Para. 65); at step 620, the laptop 12(3) server software server software authenticates itself to the server software of the other file sharing group members' machines, which in this case also includes laptops 12(1), 12(2), and the laptop 12(3) sends its public key to the laptops 12(1), 12(2), each of which inspects its locally stored updated member list to determine whether the laptop 12(3) is a member of the group (Fig. 9, el. 620; Par. 68).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu in view of Schaap to include wherein the plurality of attestations include: a first key attestation identifying a public key of the first device as corresponding to a member of a first device group; and a second key attestation identifying a public key of the second device as corresponding to a member of a second device, using the known method of enabling a laptop to add another laptop’s public key to the group list and send the updated group list to all group members, wherein the group list includes the public keys of each group member, and comparing a received public key from a laptop to the group list to determine if it is a group member, as taught by Balfanz, in combination with the shared secret generation system of Liu in view of Schaap, for the purpose of making it easy for users to securely share resources (Balfanz-Para. 19).
Liu in view of Schaap in view of Balfanz does not clearly teach wherein the plurality of attestations include:
a second key attestation identifying a public key of the second device as corresponding to a member of a second device group.
Leyfman teaches a second…attestation identifying…the second device as corresponding to a member of a second device group, e.g., the group member attributes can include a group identifier, wherein the group identifier can be assigned to playback devices by the primary playback device (Para. 57); the group member attributes can include a group leader flag, wherein if the playback device (e.g., playback device 320) is the group leader (e.g., primary playback device), the group leader flag will be set to true (Para. 58).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu in view of Schaap in view of Balfanz to include wherein the plurality of attestations include: a second key attestation identifying a public key of the second device as corresponding to a member of a second device group, using the known system of having a group of user devices and a group of playback devices and a database in each device that indicates the user devices that are authorized to pair with the playback devices, as taught by Leyfman, in combination with the shared secret generation system of Liu in view of Schaap in view of Balfanz, for the purpose of providing for aiding in the prevention of inappropriately pairing with a neighbor’s device.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Schaap and further in view of Lage Serrano et al. (US 2025/0045632 A1).
Regarding claim 8, Liu in view of Schaap teaches the first device of claim 1.
Liu further teaches wherein the program instructions are executable by the processor to: exchange with the second device a…key encrypted using the derived shared secret, e.g., this shared key may be used as the shared key or may an input into another cryptographic primitive (e.g., hash function) to generate an alias or derived key (Liu-Para. 80); the method creates a derived volatile key from the shared symmetric key (Liu-Para. 82).
Liu in view of Schaap does not explicitly teach wherein the program instructions are executable by the processor to: exchange with the second device a symmetric key encrypted using the derived shared secret.
Lage Serrano teaches to: exchange with the second device a symmetric key encrypted using the derived shared secret, e.g., the symmetric key must be shared with the participating data owners 102, 104, 105 and 107, so that they can decipher the model, and the symmetric key is encrypted with a shared secret protocol or with an integrated encryption scheme (IES), wherein the symmetric key can be encrypted with a shared secret Discrete Logarithm Integrated Encryption Scheme (DLIES) or with a shared secret Elliptic Curve Integrated Encryption Scheme (ECIES) (Para. 65).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu in view of Schaap to include to: exchange with the second device a symmetric key encrypted using the derived shared secret, using the known method of using a shared secret to encrypt the symmetric key that is shared with second device, as taught by Lage Serrano, in combination with the shared secret generation system of Liu in view of Schaap, for the purpose of enabling the system to reducing the number of active encryption/decryption keys while also reducing the changes that an attacker is able to intercept and utilize the symmetric key.
Claims 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Schaap and further in view of Gan et al. (US 2022/0272077 A1).
Regarding claim 9, Liu in view of Schaap teaches the first device of claim 1.
Liu in view of Schaap does not clearly teach wherein the program instructions are executable by the processor to: exchange with the second device an authentication credential encrypted using the derived shared secret.
Gan teaches wherein the program instructions are executable by the processor, e.g., control device 10 (Fig. 7, el. 10), to: exchange with the second device an authentication credential encrypted using the derived shared secret, e.g., after encrypting the identity credential of the control device 10 and the public key information of the control device 20 by using the shared key, the control device 10 sends the encrypted identity credential of the control device 10 and public key information of the control device 20 to the home hub 30 (Fig. 7, el. S702; Para. 146); when the control device 10 is connected to the home hub 30, identity authentication is performed by using the originally configured public key information of the identity credential of the control device 10 (Para. 64).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu in view of Schaap to include to: exchange with the second device an authentication credential encrypted using the derived shared secret, using the known method of using a shared secret to encrypt the identity credential that is shared with second device, as taught by Gan, in combination with the shared secret generation system of Liu in view of Schaap, for the purpose of aiding in the prevention of a malicious user gaining control of the plaintext credential, thereby increasing the security for the corresponding devices.
Regarding claim 10, Liu in view of Schaap teaches the first device of claim 1.
Liu in view of Schaap does not clearly teach wherein the program instructions are executable by the processor to: exchange with the second device a transaction credential encrypted using the derived shared secret.
Gan teaches wherein the program instructions are executable by the processor, e.g., control device 10 (Fig. 7, el. 10), to: exchange with the second device a transaction credential encrypted using the derived shared secret, e.g., after encrypting the identity credential of the control device 10 and the public key information of the control device 20 by using the shared key, the control device 10 sends the encrypted identity credential of the control device 10 and public key information of the control device 20 to the home hub 30 (Fig. 7, el. S702; Para. 146); when the control device 10 is connected to the home hub 30, identity authentication is performed by using the originally configured public key information of the identity credential of the control device 10 (Para. 64).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu in view of Schaap to include to: exchange with the second device a transaction credential encrypted using the derived shared secret, using the known method of using a shared secret to encrypt the identity credential that is shared with second device, as taught by Gan, in combination with the shared secret generation system of Liu in view of Schaap, for the purpose of aiding in the prevention of a malicious user gaining control of the plaintext credential, thereby increasing the security for the corresponding devices.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Schaap and further in view of Mesh et al. (US 11,228,421 B1).
Regarding claim 11, Liu in view of Schaap teaches the first device of claim 1.
Liu in view of Schaap does not clearly teach further comprising: a random number generator circuit coupled to the cryptographic circuit and inaccessible to the processor, wherein the random number generator circuit is configured to: provide a random value to the cryptographic circuit for storage in the secure memory as a portion of the private key material.
Mesh teaches a random number generator circuit coupled to the cryptographic circuit, e.g., e.g., a random number generator in the secure element (Col. 4, lines 52-54), and inaccessible to the processor, e.g., a secure element includes secure memory that is not accessible to systems outside of the secure element; thus, while a processor within the secure element may be given access to read and use a secret value stored in the secure memory, a processor or other hardware component outside of the secure element cannot get access to that secret value (Col. 3, lines 48-54),
wherein the random number generator circuit is configured to: provide a random value to the cryptographic circuit for storage in the secure memory as a portion of the private key material, e.g., in operation 201, a first secret value is stored in a non-volatile memory in a secure element, wherein this first secret value is generated by using, for example, a random number generator in the secure element (Fig. 3, el. 201; Col. 4, lines 46-54); Then in operation 205, a second secret value is generated using, in one embodiment, a first key derivation function (KDF) that uses, as inputs to the first KDF at least the first secret value (e.g. first secret value 23) and the user's credential (e.g., the user's passcode) (Fig. 3, el. 205; Col. 4, lines 63-67); the method shown in FIG. 3 can be performed with two secure elements in one embodiment, and in an alternative embodiment can be performed with one secure element (Col. 5, lines 34-37).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Liu in view of Schaap to include a random number generator circuit coupled to the cryptographic circuit and inaccessible to the processor, wherein the random number generator circuit is configured to: provide a random value to the cryptographic circuit for storage in the secure memory as a portion of the private key material, using the known method of storing a random number generated by a random number generator for use as secret material, as taught by Mesh, in combination with the shared secret generation system of Liu in view of Schaap, for the purpose of enhancing the security of a generated key by using random values.
Allowable Subject Matter
Claims 6, 18, and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 6, the prior art of record fails to disclose the combination of features as claimed and arranged by applicant when read in light of the specification. In this case, the allowance is based on the combination of the limitations in claim 6 and not on any single limitation.
The cited references— Liu et al. (US 2022/0294614 A1), Sykora et al. (US 2017/0373844 A1), Balfanz et al. (US 2004/0103280 A1), Leyfman et al. (US 2019/0304507 A1), Mesh et al. (US 11,228,421 B1), Lage Serrano et al. (US 2025/0045632 A1), Gan et al. (US 2022/0272077 A1), Schaap et al. (US 2017/0201380 A1), and Mathias et al. (US 2020/0052905 A1)—do not alone or in an obvious combination teach “wherein the program instructions are executable by the processor to: receiving a disaster recovery (DR) key pair generated by the key authority in response to issuing the key authorization data structure,” and “in response to the key authority being subsequently revoked, using the DR key pair to establish another key authority” of claim 6 in combination with the remaining limitations claim 6.
Not cited, but relevant prior art, Kumar et al. (US 9,251,097 B1) discloses a single disaster recovery key may be used to encrypt one or more key encrypting keys, which may be rotated over time for the purpose of security. Key encrypting keys may be encrypted by the disaster recovery key and (in encrypted form) stored in a file, referred to as a disaster recovery file, that is redundantly stored in the data storage system. For example, the disaster recovery file may be stored in multiple data storage devices that also store the data objects (perhaps in shard form). In some embodiments, every data storage device of the data storage system that stores a shard also stores the disaster recovery file. The disaster recovery file may also associate key encrypting keys with identifiers of the key encrypting keys. In this manner, should access to a key encrypting key be lost, the disaster recovery file can be used to decrypt the key encrypting key from the disaster recovery file (Col. 3, line 63-Col. 4, line 11).
However, the cited prior art and Kumar do not alone or in an obvious combination teach “wherein program instructions are executable by the processor to: receiving a disaster recovery (DR) key pair generated by the key authority in response to issuing the key authorization data structure,” and “in response to the key authority being subsequently revoked, using the DR key pair to establish another key authority” of claim 6 in combination with the remaining limitations claim 6.
Regarding claim 18, the prior art of record fails to disclose the combination of features as claimed and arranged by applicant when read in light of the specification. In this case, the allowance is based on the combination of the limitations in claim 18 and not on any single limitation.
The cited references— Liu et al. (US 2022/0294614 A1), Sykora et al. (US 2017/0373844 A1), Balfanz et al. (US 2004/0103280 A1), Leyfman et al. (US 2019/0304507 A1), Mesh et al. (US 11,228,421 B1), Lage Serrano et al. (US 2025/0045632 A1), Gan et al. (US 2022/0272077 A1), Schaap et al. (US 2017/0201380 A1), and Mathias et al. (US 2020/0052905 A1)—do not alone or in an obvious combination teach “wherein the plurality of attestations include: a key authorization identifying 1) a first public key of a first participant authority that identified the public key of the first device as corresponding to a member of the first device group and 2) a second public key of a second participant authority that identified the public key of the second device as corresponding to a member of the second device group” of claim 18 in combination with the remaining limitations claim 18.
Claim 19 is dependent on claim 18 and, therefore is allowable for the same reasons as claim 18.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Movva et al. (US 2022/0394428 A1)—Movva discloses embodiments that relate to pairing and finding a group of accessory devices (Abstract).
Kumar et al. (US 9,251,097 B1)—Kumar discloses a single disaster recovery key may be used to encrypt one or more key encrypting keys, which may be rotated over time for the purpose of security. Key encrypting keys may be encrypted by the disaster recovery key and (in encrypted form) stored in a file, referred to as a disaster recovery file, that is redundantly stored in the data storage system. For example, the disaster recovery file may be stored in multiple data storage devices that also store the data objects (perhaps in shard form). In some embodiments, every data storage device of the data storage system that stores a shard also stores the disaster recovery file. The disaster recovery file may also associate key encrypting keys with identifiers of the key encrypting keys. In this manner, should access to a key encrypting key be lost, the disaster recovery file can be used to decrypt the key encrypting key from the disaster recovery file (Col. 3, line 63-Col. 4, line 11).
Bussard et al. (US 2007/0168332 A1)—Bussard discloses each group member gets the list of group members and credentials (e.g. public keys) that can be used for setting access control rules or for establishing secure channels (Para. 39).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
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, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
03 February 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498