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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 22 April 2026 has been entered.
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 31 March 2026 complies with all applicable rules and regulations. Therefore, the information referred to therein has been considered.
Response to Arguments
Applicant’s arguments, see pages 10-11, filed 31 March 2026, with respect to the rejection of claims 1, 14, and 21 under 35 U.S.C. 103 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), Schaap et al. (US 2017/0201380 A1), and Leyfman et al. (US 2019/0304507 A1).
Applicant's arguments filed 31 March 2026 have been fully considered but they are not persuasive.
In response to applicant’s arguments that “Leyfman’s database does not appear to be described with respect to multiple groups”, and that Leyfman fails to satisfy “indicate that a first group…including the second device” and “verifying” on page 11. The examiner respectfully disagrees.
The “key” limitations are shown to be taught by Schaap et al. (US 2017/0201380 A1). Leyfman is not being relied upon to teach the “key” limitations.
Schaap discloses trusted server 130 is configured to generate verification information 134 that cryptographically binds the identities of one or both of devices 110 and 120 to the particular firmware 124 to be executed by device 110. 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. 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) from all or a portion of the received authentication information and the received hash value. Devices 110 and/or 120 may then verify the signed data using the public key identified in the server's public-key certificate (Para. 27).
Schaap further discloses the authentication information may include a public key certificate for each device where each certificate includes the public key used by that device (Para. 25).
Schaap also discloses the signed authentication information may be used to establish a shared key between the device (Para. 27).
Schaap’s trusted server signs the received authentication information and one or both of the devices may verify it. The signed information would be the “key authorization data structure”.
Leyfman discloses that the authorized users database specifies user devices, e.g., device group, that are authorized to pair with playback devices, e.g., device group (Para. 113, 114).
Leyfman further discloses user device 1210 can send the authorized user database 1212, or a portion of the database 1212 that includes the device identifiers for the authorized users in authorized user database 1212, to playback device 320. Playback device 320 can store the received portion of authorized user database 1212 as authorized user database 1202 (Para. 116). User device 1210 can send a portion of the authorized user database 1212 related to the user of user device 1220, including the pairing tokens generated by playback device 320, to user device 1220. For example, user device 1220 can receive and store in authorized user database 1222 the devices identifiers, and/or pairing tokens associated with the user of user device 1220 (Para. 117).
Leyfman also discloses 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 to playback device 320. When playback device 320 receives the device identifier and the pairing token from user device 1220, playback device 320 can compare the pairing token with the pairing tokens stored in authorized user database 1202 to verify that the received pairing token is the same as the pairing token generated by playback device 320 for the identified user or device (Para. 118).
Therefore, the combination of the cited prior art teaches the aforementioned limitations.
Note: the examiner suggests clarifying in the independent claims how the key authorization data structure is verified and clarifying how the device groups are indicated in the key authorization data structure. For example, the group language in the claims may be interpreted to be different device types or some other logical grouping of devices. The claims do not require any explicit group identification or name in the key authorization data structure.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, stated on page 11, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007).
In this case, Schaap discloses a process for pairing a computing device and a peripheral device, where the computing device may be “any suitable computing device such as desktop computer, laptop computer, mobile device (e.g., mobile phone, tablet, etc.), server computer, etc.” (Para. 22), and where the peripheral device may be “a device configured to perform input and/or output operations for computing device 120” (Para. 21). These devices could then be interpreted to be “playback devices” and “user devices”.
The motivation to combine Liu and Schaap with Leyfman provided in the Office action is “reducing the burden of pairing user devices with playback devices by automatically pairing authorized user devices using a database that specifies user devices that are authorized to pair with playback devices” (Para. 113, 114).
Therefore, the combination is valid.
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, 17, 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) and further in view of Leyfman et al. (US 2019/0304507 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 a first group of devices including the first device is authorized to participate in key exchanges with a second group of devices including 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 key exchanges 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 key exchanges 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.
Liu in view of Schaap 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 a first group of devices including the first device is authorized to participate in key exchanges with a second group of devices including the second device.
Leyfman teaches determine whether the…exchange is authorized by verifying a…authorization data structure, e.g., authorized user database 1212/1222/1202 (Fig. 12, el. 1202, 1212, 1222),…to indicate that a first group of devices including the first device, e.g., user devices that include user device 1220 (Fig. 12, el. 1220; Para. 114), wherein the user devices may be streaming devices or remote control devices (Para. 113), is authorized to participate in…exchanges with a second group of devices including the second device, e.g., playback devices including playback device 320 (Figs. 3, 12, el. 320);
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, and if the user devices have already been paired with some playback devices, the authorized user database 1212 can include pairing tokens generated and provided by the paired playback devices, wherein authorized user database 1212 can include a mapping of authorized user device identifiers to corresponding pairing tokens generated for each of the authorized user device identifiers (Para. 114);
after pairing with playback device 320, user device 1210 can automatically pair the user devices identified in authorized user database 1212 with playback device 320, where to initiate the pairing of the user devices identified in authorized user database 1212 with playback device 320, user device 1210 can send authorized user database 1212 to playback device 320 (Para. 116);
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);
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: 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 a first group of devices including the first device is authorized to participate in key exchanges with a second group of devices including the second device, 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 and pairing method of Liu in view of Schaap, for the purpose of reducing the burden of pairing user devices with playback devices by automatically pairing authorized user devices using a database that specifies user devices that are authorized to pair with playback devices (Leyfman-Para. 113, 114).
Regarding claim 2, Liu in view of Schaap in view of Leyfman 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 in view of Leyfman 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 in view of Leyfman 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, Liu teaches one or more non-transitory computer readable media, e.g., main memory 404/data storage system 418 (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 (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), to cause the first device perform operations, 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), comprising:
requesting, 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…,…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
…causing 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), of the first device to perform 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 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 a first group of devices is authorized to participate in key exchanges with a second group of devices; and
determining whether the first device is a member of the first group and whether the second device is a member of the second group; and
based on the determining, causing a cryptographic circuit of the first device to perform 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 whether the key exchange is authorized by: verifying a key authorization data structure signed by a key authority external to the first device, e.g., computing device 120 (Fig. 1, el. 120), to indicate that…is authorized to participate in key exchanges with…, 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
…; and
based on the determining, causing a cryptographic circuit of the first device to perform 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 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 a first device is authorized to participate in key exchanges with a second device; and based on the determining, causing a cryptographic circuit of the first device to perform 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.
Liu in view of Schaap does not clearly teach determining 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 a first group of devices is authorized to participate in key exchanges with a second group of devices; and
determining whether the first device is a member of the first group and whether the second device is a member of the second group.
Leyfman teaches determining whether the…exchange is authorized by: verifying a…authorization data structure, e.g., authorized user database 1212/1222/1202 (Fig. 12, el. 1202, 1212, 1222),…to indicate that a first group of devices, e.g., user devices that include user device 1220 (Fig. 12, el. 1220; Para. 114), wherein the user devices may be streaming devices or remote control devices (Para. 113), is authorized to participate in…exchanges with a second group of devices, e.g., playback devices including playback device 320 (Figs. 3, 12, el. 320); and determining whether the first device is a member of the first group and whether the second device is a member of the second 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, and if the user devices have already been paired with some playback devices, the authorized user database 1212 can include pairing tokens generated and provided by the paired playback devices, wherein authorized user database 1212 can include a mapping of authorized user device identifiers to corresponding pairing tokens generated for each of the authorized user device identifiers (Para. 114);
after pairing with playback device 320, user device 1210 can automatically pair the user devices identified in authorized user database 1212 with playback device 320, where to initiate the pairing of the user devices identified in authorized user database 1212 with playback device 320, user device 1210 can send authorized user database 1212 to playback device 320 (Para. 116);
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);
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 determining 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 a first group of devices is authorized to participate in key exchanges with a second group of devices; and determining whether the first device is a member of the first group and whether the second device is a member of the second 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 and pairing method of Liu in view of Schaap, for the purpose of reducing the burden of pairing user devices with playback devices by automatically pairing authorized user devices using a database that specifies user devices that are authorized to pair with playback devices (Leyfman-Para. 113, 114).
Regarding claim 15, Liu in view of Schaap in view of Leyfman 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 in view of Leyfman 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 17, Liu in view of Schaap in view of Leyfman 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 the first device group; and
a second key attestation identifying a public key of the second device as corresponding to a member of the second device group.
Leyfman teaches wherein the plurality of attestations include: a first key attestation identifying a…of the first device as corresponding to a member of the first device group; and a second key attestation identifying a…of the second device as corresponding to a member of the 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, and if the user devices have already been paired with some playback devices, the authorized user database 1212 can include pairing tokens generated and provided by the paired playback devices, wherein authorized user database 1212 can include a mapping of authorized user device identifiers to corresponding pairing tokens generated for each of the authorized user device identifiers (Para. 114);
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);
a single playback device can be part of multiple different dynamic playback groups (Para. 36);
streaming device 510 may be both a streaming device that streams media to playback device 320 (Fig. 5, el. 510; Para. 65);
the persistent group can include streaming device 510 (e.g., a set-top-box, streaming media player, etc.) and one or more playback devices (Para. 93);
in some instances, streaming device 1410 can be a playback device 320 that performs the media streaming functions described with reference to streaming device 510 (Fig. 14, el. 1410; Para. 124);
a dynamic playback group can be created that includes multiple streaming devices 1410 (Para. 133).
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 the first device group; and a second key attestation identifying a public key of the second device as corresponding to a member of the second device group, using the known system of providing group identifications for each device, as taught by Leyfman, in combination with the shared secret generation system of Liu in view of Schaap, using the same motivation as in claim 14.
Regarding claim 21, Liu teaches a method, comprising:
requesting, 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), of the first device,…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 of the first device, whether the key exchange is authorized by: verifying a key authorization data structure signed to indicate that a first device group is authorized to participate in the key exchange with a second device group, wherein the key authorization data structure is signed by a key authority distinct from the first device and the second device;
confirming that the first device is a member of the first device group and that the second device is a member of the second device group; 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 of the first device, 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…first device…, e.g., computing device 120 (Fig. 1, el. 120), is authorized to participate in key exchanges with…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
…; 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 key exchanges 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.
Liu in view of Schaap does not clearly teach determining, by a cryptographic circuit of the first device, whether the key exchange is authorized by: verifying a key authorization data structure signed to indicate that a first device group is authorized to participate in the key exchange with a second device group; and
confirming that the first device is a member of the first device group and that the second device is a member of the second device group.
Leyfman teaches determining, by a…circuit of the first device, e.g., user devices that include user device 1220 (Fig. 12, el. 1220; Para. 114), wherein the user devices may be streaming devices or remote control devices (Para. 113), whether the…exchange is authorized by: verifying a…authorization data structure, e.g., authorized user database 1212/1222/1202 (Fig. 12, el. 1202, 1212, 1222),…to indicate that a first device group is authorized to participate in the…exchange with a second device group, e.g., playback devices including playback device 320 (Figs. 3, 12, el. 320); and confirming that the first device is a member of the first device group and that the second device is a member of the 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, and if the user devices have already been paired with some playback devices, the authorized user database 1212 can include pairing tokens generated and provided by the paired playback devices, wherein authorized user database 1212 can include a mapping of authorized user device identifiers to corresponding pairing tokens generated for each of the authorized user device identifiers (Para. 114);
after pairing with playback device 320, user device 1210 can automatically pair the user devices identified in authorized user database 1212 with playback device 320, where to initiate the pairing of the user devices identified in authorized user database 1212 with playback device 320, user device 1210 can send authorized user database 1212 to playback device 320 (Para. 116);
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);
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 determining, by a cryptographic circuit of the first device, whether the key exchange is authorized by: verifying a key authorization data structure signed to indicate that a first device group is authorized to participate in the key exchange with a second device group; and confirming that the first device is a member of the first device group and that the second device is 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 and pairing method of Liu in view of Schaap, for the purpose of reducing the burden of pairing user devices with playback devices by automatically pairing authorized user devices using a database that specifies user devices that are authorized to pair with playback devices (Leyfman-Para. 113, 114).
Claims 3, 12, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Schaap in view of Leyfman and further in view of Sykora et al. (US 2017/0373844 A1).
Regarding claim 3, Liu in view of Schaap in view of Leyfman 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 in view of Leyfman 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 in view of Leyfman 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 in view of Leyfman, for the purpose of further enhancing security (Sykora-Para. 55), by rendering the memory locations unreadable.
Regarding claim 12, Liu in view of Schaap in view of Leyfman teaches the first device of claim 1.
Liu in view of Schaap in view of Leyfman 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 in view of Leyfman 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 in view of Leyfman, 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 in view of Leyfman teaches the first device of claim 1.
Liu in view of Schaap in view of Leyfman 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 in view of Leyfman 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 in view of Leyfman, for the purpose of improving system performance and security by offloading cryptography tasks, thereby enhancing the speed of the tasks.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Schaap in view of Leyfman and further in view of Balfanz et al. (US 2004/0103280 A1).
Regarding claim 5, Liu in view of Schaap in view of Leyfman teaches the first device of claim 4.
Liu in view of Schaap does not clearly teach 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.
Leyfman teaches wherein the…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…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 to include 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, using the known system of providing group identifications for each device, as taught by Leyfman, in combination with the shared secret generation system of Liu in view of Schaap, using the same motivation as in claim 1.
Liu in view of Schaap in view of Leyfman does not clearly teach 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 in view of Leyfman 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 in view of Leyfman, for the purpose of making it easy for users to securely share resources (Balfanz-Para. 19).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Schaap in view of Leyfman and further in view of Lage Serrano et al. (US 2025/0045632 A1).
Regarding claim 8, Liu in view of Schaap in view of Leyfman 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 in view of Leyfman 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 in view of Leyfman 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 in view of Leyfman, 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 in view of Leyfman and further in view of Gan et al. (US 2022/0272077 A1).
Regarding claim 9, Liu in view of Schaap in view of Leyfman teaches the first device of claim 1.
Liu in view of Schaap in view of Leyfman 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 in view of Leyfman 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 in view of Leyfman, 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 in view of Leyfman teaches the first device of claim 1.
Liu in view of Schaap in view of Leyfman 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 in view of Leyfman 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 in view of Leyfman, 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 in view of Leyfman and further in view of Mesh et al. (US 11,228,421 B1).
Regarding claim 11, Liu in view of Schaap in view of Leyfman teaches the first device of claim 1.
Liu in view of Schaap in view of Leyfman 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 in view of Leyfman 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 in view of Leyfman, 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: receive 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: receive 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.
Lee et al. (US 2017/0202046 A1)—Lee discloses the wireless communications system 400 illustrates an example where the managing device 205 (e.g., the UE 115-a) manages multiple groups (e.g., subgroups 410) of group devices 210 (Para. 68).
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
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.
13 July 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498
Prosecution Insights