DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after 16 March 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to papers filed on 5 December 2024. Claims 1-20 were canceled and replaced with new claims 21-40 via Preliminary Amendment, filed on 5 December 2024. In addition, the Specification was amended via Preliminary Amendment to indicate priority and cross-reference to related applications. The amendments to the Specification and Claims are proper have been entered.
Claims 21, 28, and 37 are independent. Claims 21-40 are pending.
Priority
Acknowledgment is made of Applicant’s claim for domestic benefit priority under 35 U.S.C. 120 of Application No. 17/644,195, filed 14 December 2021. The current application is a continuation of Application No. 17/644,195.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 37-40 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claim 37:
Claim 37 recites the limitation “decipher the encrypted protocol key based on the protocol access key to recover the protocol key”. There is insufficient antecedent basis for this limitation in the claim. Claim 37 recites “a protocol access key” and “an encrypted protocol key” but does not recite “a protocol key”. Unlike independent claims 21 and 28, independent claim 37 does not introduce “a protocol key”. For purposes of examination, the Examiner interprets “the protocol key” as the plaintext key recovered by deciphering the previously recited “encrypted protocol key”. Appropriate correction is required.
As per claim 38:
Claim 38 recites: “… wherein the memory is a shared memory which is shared between the host processor and the controller of the communication platform.”. The term “the host processor” makes the claim indefinite as it lacks proper antecedent basis. In addition, claim 37 is rejected under 35 U.S.C. 112(b), as stated above, as being indefinite for failing to particularly point out and distinctly claim the subject matter. Thus, claim 38 is rejected under 35 U.S.C. 112(b) by virtue of their dependency from claim 37.
As per claim 39:
Claim 39 recites the limitations “wherein the CHA is further configured to store the protocol key in a local memory of the communication platform which is not accessible to the host processor”. There is insufficient antecedent basis for these limitations in the claim. As stated above with respect to claims 37 and 38, neither “a protocol key” nor “a host processor” is recited in claims 37 and 38, from which claim 39 depends.
As per claim 40:
Claim 40 recites the limitations “wherein the protocol access key is accessible to the controller of the communication platform and the protocol key which is in plain-text is secure from access by the host processor”. There is insufficient antecedent basis for these limitations in the claim. As stated above with respect to claims 37 and 38, neither “a protocol key” nor “a host processor” is recited in claim 37, from which claim 40 depends.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 21-22, 26, 28-29, 33, and 37-38 are rejected under 35 U.S.C. 103 as being unpatentable over Buer et al., US 2004/0005061 A1 (hereinafter, “Buer ‘061”) in view of Paaske et al., US 2020/0342091 A1 (hereinafter, “Paaske ‘091”).
As per claim 21: Buer ‘061 discloses:
A method for securing protocol keys in a communication node having a secure host platform and communication platform, the method comprising: (a method for managing cryptographic keys in a system comprising a host processor 224 that establishes connections and communicates with other host processors 226, 228 over a packet network 222, where the host processors cooperate to establish a set of keys for each session, and where such keys are uniquely associated with a session and are referred to as session keys 230, 232, 234; the keys are secured even when they leave the secure bounds 126 of the host processor [Buer ‘061, ¶¶Abstract, 35, 40-42; Figs.1-2])
transferring a protocol access key stored in (a key encryption key (KEK) 130, 238 is established between a key manager in the host processor 120 and a key manager 132 in the cryptographic accelerator 128, where a security module 1020 creates KEK B 1032 and KEK A 1040, encrypts them, and sends them to the cryptographic accelerator 1026, and where the KEKs 238 are stored in a non-volatile data memory that is located on the same integrated circuit as the key manager and the cryptographic accelerator 236 [Buer ‘061, ¶¶35-36, 39, 47, 88; Figs.1-2, Fig.10]);
encrypting a protocol key stored in (the host processor 224 encrypts each of the session keys using the KEK, where the encrypted session keys are formed as security associations [Buer ‘061, ¶¶35, 46, 73; Fig.2, Fig.6]);
transferring the encrypted protocol key from (the host processor 224 sends the encrypted session keys to the network controller/packet processor 220, where the network controller/packet processor 220 stores the encrypted security associations in a database 240, and where the database device 240 does not need to be protected because the security associations are encrypted [Buer ‘061, ¶¶46, 48-49, 73; Fig.2, Fig.6]);
providing, by a communication controller of the communication platform, the encrypted protocol key stored in the memory to the CHA in response to the communication controller initiating decipher of the encrypted protocol key (the network controller/packet processor 220 is responsible for identifying the session of a given packet and sending the corresponding session key to the cryptographic accelerator 236, where the network controller/packet processor 220 reads the identifier in the packet to determine which security association should be used, reads the data from that address in the database 240, and sends the packet and the security association to the cryptographic accelerator 236 for decryption [Buer ‘061, ¶¶44-46, 76; Fig.2, Fig.6]);
receiving, by the CHA of the communication platform, the protocol access key from the secure key store (the primary function of the key manager 520 is to provide the KEK or associated stream to a decryption engine that decrypts security associations such as session keys, where the key manager loads the KEK values into internal registers [Buer ‘061, ¶¶47, 60, 67; Fig.5, Fig.7]); and
deciphering, by the CHA, the encrypted protocol key based on the protocol access key to recover the protocol key (the cryptographic accelerator 236 decrypts the security association using the KEK 238 to recover the session key, where the initial parsing unit 422A, 422B decrypts the security association and sends the decrypted security association to the cipher engine 424A, 424B [Buer ‘061, ¶¶44, 47, 57-59; Fig.2, Fig.4]).
As stated above, while the network controller/packet processor 220 of Buer ‘061 receives the encrypted session keys from the host processor 224 and the cryptographic accelerator 236 receives the KEK 238 from the key manager, Buer ‘061 does not explicitly disclose the limitations “... transferring a protocol access key stored in a secure enclave of the secure host platform comprising a host processor to a secure key store in the communication platform via a secure bus arranged between the secure enclave and secure key store, wherein the protocol access key is secure from access by the host processor ... encrypting a protocol key stored in the secure enclave ... transferring the encrypted protocol key from the secure enclave to a memory of the communication platform over an unsecure bus arranged between the secure host platform and the communication platform ...”, as recited in claim 21.
Paaske ‘091, however, discloses:
... transferring a protocol access key stored in a secure enclave of the secure host platform comprising a host processor to a secure key store in the communication platform via a secure bus arranged between the secure enclave and secure key store, wherein the protocol access key is secure from access by the host processor ... (a system on a chip (SOC) 10 comprising a central processing unit (CPU) complex 14 and a security enclave processor (SEP) 16, where the SEP 16 is isolated from the rest of the SOC 10 except for a carefully-controlled interface, thus forming a secure enclave; a second encryption circuit 36B within the SEP 16 is configured to output a wrapping key in hardware via a secure bus 72 to cryptographic circuits within the SOC 10 and external to the SEP 16, where the wrapping keys are sent via the secure bus 72 rather than through the filter 62 and the communication fabric 27 in order to avoid exposure of the wrapping key to any software processes that may be running in the CPU complex 14 [Paaske ‘091, ¶¶21-22, 25, 34-35, 40; Fig.1, Fig.2]);
... encrypting a protocol key stored in the secure enclave to an encrypted protocol key (the second encryption circuit 36B within the SEP 16 is responsible for secure key generation, where the output wrapping key is used to encrypt a secure key, thereby producing an encrypted key [Paaske ‘091, ¶¶22, 40-41; Fig.2]);
... transferring the encrypted protocol key from the secure enclave to a memory of the communication platform over an unsecure bus arranged between the secure host platform and the communication platform (the encrypted key is provided to software, preventing the unencrypted secure key from being exposed to the software, where the software provides the encrypted key to the SOC cryptographic unit, and where the SEP 16 may send the message to a processor in the CPU complex 14 which stores the message in a memory accessible by the cryptographic units, the message being conveyed over the communication fabric 27 rather than the secure bus 72 [Paaske ‘091, ¶¶40-41, 66; Fig.1, Fig.4]) …
Buer ‘061 and Paaske ‘091 are analogous art because they are from the same field of endeavor, namely that of protecting cryptographic keys utilized by a cryptographic accelerator from exposure to a host processor. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Buer ‘061 and Paaske ‘091 before them, to modify the method in Buer ‘061 to include the teachings of Paaske ‘091, namely to implement the host processor of Buer ‘061 to include a secure enclave, as disclosed in Paaske ‘091, in which the session keys are stored and encrypted; and further to deliver the KEK of Buer ‘061 to the key manager of the cryptographic accelerator over a dedicated secure bus, as disclosed in Paaske ‘091, rather than over the same bus that conveys the encrypted session keys. A motivation for doing so would be to avoid exposure of the key encryption key to any software processes running on the host processor, such that the transfer of the key does not itself introduce a vulnerability to attacks (see Paaske ‘091, ¶¶4, 25, 40).
As per claim 22: Buer ‘061 in view of Paaske ‘091 discloses all limitations of claim 21, as stated above, from which claim 22 is dependent upon. Furthermore, Buer ‘061 discloses:
wherein the memory is a shared memory which is shared between the host processor and the communication controller of the communication platform (the host processor 224 encrypts each of the session keys and sends them to the network controller/packet processor 220 for storage in the database 240, where the network controller/packet processor 220 subsequently reads the security associations from that address in the database 240, and where the host processor 224 also sends the associated security association to the cryptographic accelerator 236 when a packet is to be transmitted, such that the database 240 is accessed by both the host processor 224 and the network controller/packet processor 220 [Buer ‘061, ¶¶46, 49, 73, 76; Fig.2, Fig.6]).
As per claim 26: Buer '061 in view of Paaske '091 discloses all limitations of claim 21, as stated above, from which claim 26 is dependent upon. Furthermore, Buer '061 discloses:
wherein the protocol key is a connectivity protocol key (the session keys 230, 232, 234 are established between host processors for connections established over the packet network 222 in accordance with communication protocols such as the Internet Security Protocol (IPsec) and the Secure Sockets Layer (SSL) protocol, and are used to decrypt the data encrypted by the other host processor [Buer ‘061, ¶¶4-5, 41-43; Fig.2]).
As per claims 28-29 and 33: Claims 28-29 and 33 define a communication node that recites substantially similar subject matter as the method of claims 21-22 and 26, respectively. Specifically, claims 28-29 and 33 are directed to a communication node comprising a secure host platform having a host processor and a secure enclave, and a communication platform having a controller, a secure key store, and a cryptographic hardware accelerator (CHA), the communication node being configured to perform the method of claims 21-22 and 26, respectively. Thus, the rejection of claims 21-22 and 26 is equally applicable to claims 28-29 and 33, respectively.
As per claims 37-38: Claims 37-38 define a communication platform that recites substantially similar subject matter as the method of claims 21-22, respectively. Specifically, claims 37-38 are directed to a communication platform comprising a secure bus interface, an unsecure bus interface, a controller, a secure key store, a memory, and a cryptographic hardware accelerator (CHA), the communication platform being configured to perform the method of claims 21-22, respectively. Thus, the rejection of claims 21-22 is equally applicable to claims 37-38, respectively.
Claims 27 and 34-35 are rejected under 35 U.S.C. 103 as being unpatentable over Buer ‘061, in view of Paaske ‘091, and further in view of Enke, US 2016/0099936 A1 (hereinafter, “Enke ‘936”).
As per claim 27: Buer ‘061 in view of Paaske ‘091 discloses all limitations of claim 21, as stated above, from which claim 27 is dependent upon. Buer ‘061 in view of Paaske ‘091 does not explicitly disclose the limitations of claim 27. Enke ‘936, however, discloses:
wherein the protocol key is an identity resolving key for to resolve a private address to authenticate communication with the communication node (an identity resolution key is a 128-bit key used to generate and resolve private addresses, where a private address resolution module 125 of the Bluetooth Low Energy controller 120 receives the identity resolution key and a private address from a connecting client device 110 for decryption, and where an authentication is granted if the result of the decryption matches the public address in the trusted database 123 [Enke ‘936, ¶¶19-20; Fig.1]).
Buer ‘061 (modified by Paaske ‘091) and Enke ‘936 are analogous art because they are from the same field of endeavor, namely that of managing cryptographic keys used by a communication controller to secure communications with another node. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Buer ‘061 (modified by Paaske ‘091) and Enke ‘936 before them, to modify the method in Buer ‘061 (modified by Paaske ‘091) to include the teachings of Enke ‘936, namely to implement the session keys of Buer ‘061 as identity resolution keys used by the controller to resolve and authenticate private addresses of connecting devices, as disclosed in Enke ‘936. A motivation for doing so would be to prevent device tracking by allowing a different private address to be generated as many times as necessary while still permitting the connecting device to be authenticated (see Enke ‘936, ¶¶19-20).
As per claim 34: Claim 34 defines a communication node that recites substantially similar subject matter as the method of claim 27. Specifically, claim 34 is directed to a communication node comprising a secure host platform having a host processor and a secure enclave, and a communication platform having a controller, a secure key store, and a cryptographic hardware accelerator (CHA), the communication node being configured to perform the method of claim 27. Thus, the rejection of claim 27 is equally applicable to claim 34.
As per claim 35: Buer ‘061 in view of Paaske ‘091 discloses all limitations of claim 28, as stated above, from which claim 35 is dependent upon. Buer ‘061 in view of Paaske ‘091 does not explicitly disclose the limitations of claim 35. Enke ‘936, however, discloses:
wherein a host control interface (HCI) bus serves as an interface between the host platform and the communication platform (a host controller interface 150 is a communication interface between the host processor 130 and the Bluetooth Low Energy controller 120, where the host controller interface 150 bridges the different levels of protocol abstraction at which the host processor 130 and the controller 120 operate, and where the host controller interface 150 may be implemented in communication busses such as a universal asynchronous receiver/transmitter (UART), a serial peripheral interface (SPI), or a Universal serial bus (USB) [Enke ‘936, ¶¶16, 25; Fig.1]).
Buer ‘061 (modified by Paaske ‘091) and Enke ‘936 are analogous art because they are from the same field of endeavor, namely that of managing cryptographic keys used by a communication controller to secure communications with another node. For the reasons stated in claim 27, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Buer ‘061 (modified by Paaske ‘091) and Enke ‘936 before them, to modify the communication node in Buer ‘061 (modified by Paaske ‘091) to include the teachings of Enke ‘936.
Claim 36 is rejected under 35 U.S.C. 103 as being unpatentable over Buer ‘061, in view of Paaske ‘091, further in view of Enke ‘936, and further in view of Ma et al., US 2003/0021262 A1 (hereinafter, “Ma ‘262”).
As per claim 36: Buer ‘061 in view of Paaske ‘091, and further in view of Enke ‘936 discloses all limitations of claims 28 and 35, as stated above, from which claim 36 is dependent upon. Buer ‘061 in view of Paaske ‘091, and further in view of Enke ‘936 does not explicitly disclose the limitations of claim 36. Ma ‘262, however, discloses:
wherein the HCI bus is coupled to the memory (a Bluetooth system including a Bluetooth Host 20, a Bluetooth Host Controller 30, and a physical interface between the host and the host controller, where the Bluetooth Host 20 includes a HCI driver 24 and a physical bus interface 26 and the Bluetooth Host Controller 30 includes a corresponding physical bus interface 32, and where the HCI data packets are transmitted through a physical link 56 by the host 20 to the host controller 30 and stored in buffers 52; a large L2CAP packet is transferred from the host memory 44 through the host controller interfaces 24 and 34 to the buffers 52 [Ma ‘262, ¶¶4, 7, 114; Fig.1, Fig.2, Figs.14A-14B]).
Buer ‘061 (modified by Paaske ‘091 and Enke ‘936) and Ma ‘262 are analogous art because they are from the same field of endeavor, namely that of transferring data between a host processor and a communication controller over a host controller interface. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Buer ‘061 (modified by Paaske ‘091 and Enke ‘936) and Ma ‘262 before them, to modify the communication node in Buer ‘061 (modified by Paaske ‘091 and Enke ‘936) to include the teachings of Ma ‘262, namely to couple the host controller interface bus of Enke ‘936 to the memory of the communication platform, as disclosed in Ma ‘262, such that data transmitted by the host over the host controller interface is stored in buffers of the host controller. A motivation for doing so would be to relieve the central processor of the burden of performing the conversion and transfer operations at time critical points, thereby reducing the performance requirement for the processor and the likelihood that a high-performance microprocessor will be needed (see Ma ‘262, ¶¶34-35, 125).
Claim 39 is rejected under 35 U.S.C. 103 as being unpatentable over Buer ‘061, in view of Paaske ‘091, further in view of Patariu et al., US 2004/0247129 A1 (hereinafter, “Patariu ‘129”).
As per claim 39: Buer ‘061 in view of Paaske ‘091 discloses all limitations of claims 37-38, as stated above, from which claim 39 is ultimately dependent upon. Buer ‘061 in view of Paaske ‘091 does not explicitly disclose the limitations of claim 39. Patariu ‘129, however, discloses:
wherein the CHA is further configured to store the protocol key in a local memory of the communication platform which is not accessible to the host processor, the local memory being different from the shared memory (a chip 302 comprising a key and encryption/decryption select and control block 304, a serial link 310, and an on-chip bus interface block 312, where the on-chip bus interface block 312 includes at least one key register of memory 312a, 312b and a control logic block 314, and where the key registers 312a, 312b may only be accessed, written, and read by the key and encryption/decryption select and control block 304 such that other devices that may be connected to the on-chip bus interface block 312 may not be able to read or modify the key [Patariu ‘129, ¶¶38, 40-41, 43; Fig.3, Fig.4]).
Buer ‘061 (modified by Paaske ‘091) and Patariu ‘129 are analogous art because they are from the same field of endeavor, namely that of restricting access to cryptographic keys transferred to and stored within a bus interface block that performs encryption and decryption operations. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Buer ‘061 (modified by Paaske ‘091) and Patariu ‘129 before them, to modify the method in Buer ‘061 (modified by Paaske ‘091) to include the teachings of Patariu ‘129, namely to store the recovered session key of Buer ‘061 in a key register of the communication platform that is accessible only by the controller of that platform, as disclosed in Patariu ‘129, and that is separate from the database in which the encrypted security associations are stored. A motivation for doing so would be to securely maintain the integrity of the key data transferred to and stored within the bus interface block, such that other devices connected to that block are unable to read or modify the key (see Patariu ‘129, ¶¶41, 43).
Allowable Subject Matter
Claims 23-25 and 30-32 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.
Claim 40 is dependent upon a rejected base claim but may be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, as well as rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) set forth in this Office action. See Claim Rejections - 35 USC § 112 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Barzic et al., US 20210264066 A1: A peripheral component supports a secure-in-and-non-secure-out state in which the hardware filter logic is configured to prevent non-secure bus transactions from accessing the hardware register of the peripheral component, but to allow secure bus transactions to access the peripheral component.
Xing, US 20170288875 A1: A first secure enclave and second secure enclave each perform a cryptographic operation on a message using A message authentication code as a cryptographic key.
Moran, US 20210406404 A1: A secure enclave circuitry allows a portion of code to be protected against outside access and potentially encrypted at rest, thereby allowing a higher degree of security (for example for credentials and keys).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN L KONG whose telephone number is (571)272-2646. The examiner can normally be reached Monday-Friday 9:00am-5:30pm EST.
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, JUNG (JAY) KIM can be reached on (571)272-3804. 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.
/ALAN L KONG/
Examiner, Art Unit 2494
/KAVEH ABRISHAMKAR/Primary Examiner, Art Unit 2494
Prosecution Insights