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 .
Claims 1-13 have been examined.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/05/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Analysis of claims under 35 USC § 101
The examiner analyzed the claims and determined them to be statutory. Specifically, claim 1 is directed to a system comprising a first host processor, a first secure element, and a second secure element. Paragraph [0051] of the published specification states that the processor refers to a data processing circuit. Therefore, claim 1 is directed to a system comprising of hardware which is statutory.
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.
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.
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-4, 7, 8, and 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over US 20220414224 to Sachdeva et al (hereinafter Sachdeva) and US 20230072349 to Mukhtar et al (hereinafter Mukhtar).
As per claims 1 and 13, Sachdeva teaches:
A data processing system, comprising:
a first host processor (Sachdeva: Fig. 1, [0054]: Control circuitry 140 may be any suitable processor);
a first secure element operatively coupled to the first host processor; and a second secure element operatively coupled to the first host processor (Sachdeva: Fig. 1, [0035] The gateway 120 includes control circuitry 140, a processing element 130, and one or more secure elements 150 and 152. Fig. 1 shows the secure elements 150 and 152 coupled to the control circuitry 140),
wherein the first secure element is configured to function as a server and the second secure element is configured to function as a client in a client-server relationship between the first secure element and the second secure element (Sachdeva: Fig. 1, [0055]: the control circuitry 140 selects the first secure element 150 as a manager and the second secure element 152 as a target), and
wherein the first secure element is configured to transmit synchronization data to the second secure element through the first host processor, wherein the synchronization data have been encrypted using a cryptographic key shared only between the first secure element and the second secure element (Sachdeva: [0055]: After performing mutual authentication with the first secure element 150, a first pair of ephemeral session specific key material (SFKP1) is generated and stored by the first secure element 150 and by the second secure element 152. At this point, the first and second secure elements 150 and 152 are able to securely exchange data that is encrypted and signed using the SFKP1. [0056]: The first secure element 150 encrypts and signs each chunk of the firmware file received from the element 150 using the SFKP1 of the second secure element 152 to generate respective data packets. Namely, the first secure element 150 provides the data packet (e.g., the encrypted and signed firmware file chunk) to the second secure element 152 either directly or indirectly via the control circuitry 140. In the case of sending the data packet (e.g., the encrypted and signed file chunk) indirectly, the first secure element 150 returns to the control circuitry 140 the data packet that includes the file chunk that has been encrypted and signed using the SFKP1 of the second secure element 152. Then, the element 150 sends the data packet to the second secure element 152. Namely, the element 150 may act as a blind and dumb conduit of data exchanged between the first and second secure elements 150 and 152. The first secure element 150 repeats the process of encrypting and signing each chunk of the firmware file (synchronization data) until all chunks have been sent to the second secure element 152).
Sachdeva teaches that the first secure element 150 is a manager and the second secure element 152 is a target but does not teach: wherein the first secure element is configured to function as a server and the second secure element is configured to function as a client in a client-server relationship between the first secure element and the second secure element. However, Mukhtar teaches:
wherein the first secure element is configured to function as a server and the second secure element is configured to function as a client in a client-server relationship between the first secure element and the second secure element (Mukhtar: [0007] Typical vehicle systems include hardware or software modules that may need to exchange cryptographic key or keys (e.g., an ephemeral keys) to encrypt messages sent between each other. Designating one client as a server and assigning a symmetric key to every other client permanently provisioned between that client and the server. [0096]: To deploy the solution, one node in the network may be designated as a key server, and the rest designated as key clients. As a first step every client has a symmetric key permanently provisioned between itself and the server. [0098]: the server may reply to client 1 with a message that includes the newly provisioned key. [0101]: The response message to client 2 1005 may include: … (b) the same key that was provisioned at the request of client 1).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Mukhtar in the invention of Sachdeva to include the above limitations. The motivation to do so would be to be secure against eavesdropping and man-in-the-middle attacks (Mukhtar: [0096]).
As per claim 2, Sachdeva in view of Mukhtar teaches:
The data processing system of claim 1, wherein the first host processor is configured to trigger the first secure element to share the cryptographic key with the second secure element (Sachdeva: [0055]: the control circuitry 140 selects the first secure element 150 as a manager and the second secure element 152 as a target. The first secure element 150 performs mutual authentication with the second secure element 152 using the MFKP of the second secure element 152 that is stored on the first secure element 150. The mutual authentication between the two secure elements may be performed by the secure elements communicating directly with each other or indirectly by the secure elements exchanging communications via the control circuitry 140. After performing mutual authentication with the first secure element 150, a first pair of ephemeral session specific key material (SFKP1) is generated and stored by the first secure element 150 and by the second secure element 152).
As per claim 3, Sachdeva in view of Mukhtar teaches:
The data processing system of claim 2, wherein the first host processor is further configured to trigger the first secure element to transmit the synchronization data after the cryptographic key has been shared (Sachdeva: [0055]: At this point, the first and second secure elements 150 and 152 are able to securely exchange data that is encrypted and signed using the SFKP1. [0056] The control circuitry 140 provides each chunk of the firmware file to the first secure element 150. The first secure element 150 encrypts and signs each chunk of the firmware file received from the element 150 using the SFKP1 of the second secure element 152 to generate respective data packets. Namely, the first secure element 150 provides the data packet (e.g., the encrypted and signed firmware file chunk) to the second secure element 152 either directly or indirectly via the control circuitry 140. he first secure element 150 repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the second secure element 152).
As per claim 4, Sachdeva in view of Mukhtar teaches:
The data processing system of claim 2, wherein the first host processor is configured to trigger the first secure element to share the cryptographic key and transmit the synchronization data in response to the second secure element being operatively coupled to the first host processor (Sachdeva: Fig. 1, [0035] The gateway 120 includes control circuitry 140, a processing element 130, and one or more secure elements 150 and 152. In some cases, the gateway 120 includes 16 secure elements. Each secure element 150 and 152 of gateway 120 is configured to perform the same function. Fig. 1 shows secure element 152 operatively coupled to the control circuitry. [0055]: After or before receiving the firmware file, the control circuitry 140 selects the first secure element 150 as a manager and the second secure element 152 as a target. The first secure element 150 performs mutual authentication with the second secure element 152. After performing mutual authentication with the first secure element 150, a first pair of ephemeral session specific key material (SFKP1) is generated and stored by the first secure element 150 and by the second secure element 152. At this point, the first and second secure elements 150 and 152 are able to securely exchange data that is encrypted and signed using the SFKP1. [0056]: The first secure element 150 encrypts and signs each chunk of the firmware file received from the element 150 using the SFKP1 of the second secure element 152 to generate respective data packets. Namely, the first secure element 150 provides the data packet (e.g., the encrypted and signed firmware file chunk) to the second secure element 152 either directly or indirectly via the control circuitry 140. In the case of sending the data packet (e.g., the encrypted and signed file chunk) indirectly, the first secure element 150 returns to the control circuitry 140 the data packet that includes the file chunk that has been encrypted and signed using the SFKP1 of the second secure element 152. Then, the element 150 sends the data packet to the second secure element 152. Namely, the element 150 may act as a blind and dumb conduit of data exchanged between the first and second secure elements 150 and 152. The first secure element 150 repeats the process of encrypting and signing each chunk of the firmware file (synchronization data) until all chunks have been sent to the second secure element 152)).
As per claim 7, Sachdeva in view of Mukhtar teaches:
The data processing system of claim 1, wherein the second secure element is configured to decrypt the synchronization data using the cryptographic key and to apply the synchronization data to one or more applications stored in the second secure element (Sachdeva: [0056]: The security enclave implemented by the processing element 130 repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the second secure element (the target) 152. Claims 13: updating firmware of the second secure element after the firmware file is transmitted to the first secure element. It is inherent that the second secure element decrypts all the chunks of the firmware file in order to update).
As per claim 8, Sachdeva in view of Mukhtar teaches:
The data processing system of claim 1, wherein the synchronization data comprise a reference to an application on which an update should be performed as well as instructions and data for performing the update (Sachdeva: [0054] As shown in FIG. 4, the remote source 130 transmits the firmware file with the firmware update to the control circuitry 140. [0056]: The security enclave implemented by the processing element 130 repeats the process of encrypting and signing each chunk of the firmware file (data for performing the update) until all chunks have been sent to the second secure element (the target) 152. It is inherent that the reference to the application on which the update is be performed is the firmware and it was well known to one of ordinary skill in the art before the effective filing date of the claimed invention that a firmware update includes instructions for performing the update).
As per claim 11, Sachdeva in view of Mukhtar teaches:
The data processing system of claim 1, comprising at least one second host processor, wherein the second secure element is operatively coupled to the first host processor through the second host processor (Sachdeva: Fig.1, [0035] The gateway 120 includes control circuitry 140, a processing element 130, and one or more secure elements 150 and 152. [0037]: a security enclave, such as a trusted execution environment, implemented by the processing element 130 (second host processor). In such cases, the security enclave may run applications that make use of crypto support and offer isolation from the general computing environment. In some implementations, the security enclave implemented by the processing element 130 includes symmetric or asymmetric key material that is used by the security enclave to communicate with another device. Fig. 1 shows the second secure element 152 operatively coupled to the control circuitry (first host processor) through the processing element 130 (second host processor)).
As per claim 12, Sachdeva in view of Mukhtar teaches:
The data processing system of claim 1, wherein the first secure element and the second secure element are configured to perform a mutual authentication before the cryptographic key is shared between the first secure element and the second secure element (Sachdeva: [0055]: The first secure element 150 performs mutual authentication with the second secure element 152 using the MFKP of the second secure element 152 that is stored on the first secure element 150. The mutual authentication between the two secure elements may be performed by the secure elements communicating directly with each other or indirectly by the secure elements exchanging communications via the control circuitry 140. After performing mutual authentication with the first secure element 150, a first pair of ephemeral session specific key material (SFKP1) is generated and stored by the first secure element 150 and by the second secure element 152).
Claims 5 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Sachdeva in view of Mukhtar as applied to claim 1 above, and further in view of applicant provided prior art US 20070255679 to Hosoi et al (hereinafter Hosoi).
As per claim 5, Sachdeva in view of Mukhtar does not teach the limitations of claim 5. However, Hosoi teaches:
wherein the first secure element is further configured to keep track of a synchronization state of the second secure element (Hosoi: [0013]: That is, the transmitting node produces synchronization data to be inserted in transmission data and then transmits the transmission data including the synchronization data. The synchronization data is used to confirm synchronization of the running key between the transmitting and receiving nodes. When the receiving node legitimately receives the synchronization data, the receiving node transmits a synchronization confirmation signal to the transmitting node. When the transmitting node legitimately receives the synchronization confirmation signal, the transmitting node continues to modulate transmission data into multi-valued data using the running key).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Hosoi in the invention of Sachdeva in view of Mukhtar to include the above limitations. The motivation to do so would be to confirm synchronization of the running key between the transmitting and receiving nodes (Hosoi: [0011]).
As per claim 10, Sachdeva in view of Mukhtar does not teach the limitations of claim 10. However, Hosoi teaches:
wherein the second secure element is configured to generate a synchronization acknowledgement and to transmit the acknowledgement to the first secure element through the first host processor (Hosoi: [0013]: That is, the transmitting node produces synchronization data to be inserted in transmission data and then transmits the transmission data including the synchronization data. The synchronization data is used to confirm synchronization of the running key between the transmitting and receiving nodes. When the receiving node legitimately receives the synchronization data, the receiving node transmits a synchronization confirmation signal to the transmitting node. When the transmitting node legitimately receives the synchronization confirmation signal, the transmitting node continues to modulate transmission data into multi-valued data using the running key).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Hosoi in the invention of Sachdeva in view of Mukhtar to include the above limitations. The motivation to do so would be to confirm synchronization of the running key between the transmitting and receiving nodes (Hosoi: [0011]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Sachdeva in view of Mukhtar as applied to claim 1 above, and further in view of US 10313123 to Grubin et al (hereinafter Grubin).
As per claim 6, Sachdeva in view of Mukhtar does not teach the limitations of claim 6. However, Grubin teaches:
wherein the first secure element is further configured to delete the synchronization data after transmitting the synchronization data (Grubin: column 4, lines 18-67 and column 5, lines 1-11: The particular HSM generates a new key in accordance with the key-generation request. The new key has an associated key identifier that includes the supplied prefix. The particular HSM returns the key identifier to the HSM cluster server, an encrypted version of the new cryptographic key, and any status information associated with the key-generation request. The encrypted version of the new cryptographic key is encrypted with a cluster key stored on the HSMs in the HSM cluster in plaintext form. The cluster key is used to share cryptographic information between HSMs in the HSM fleet. After receiving the encrypted version of the new cryptographic key, the key identifier, and the status information from the particular HSM, the HSM cluster client performs actions to replicate the new cryptographic key across the HSM cluster. Each key-replication request includes the encrypted version of the new cryptographic key and the key identifier. Each HSM cluster server forwards the key-replication request to an associated HSM. The associated HSM uses the cluster key to acquire the new cryptographic key from the encrypted version of the new cryptographic key. Deleting a cryptographic key from the HSM cluster is accomplished by applying a tombstone, or pending deletion flag, to the cryptographic key to be deleted, and synchronizing the tombstone across the HSM cluster. To delete a cryptographic key from the HSM cluster, an application submits a tombstone request for a particular cryptographic key to the HSM cluster client on the client computer system hosting the application. The HSM cluster client submits the tombstone request to each HSM in the HSM cluster via the HSM cluster servers. The tombstone is registered by each HSM in the HSM cluster, thereby blocking further access to the cryptographic key. After the HSM cluster is determined to be in a synchronized state and the tombstone is replicated across all HSMs in the sum cluster, the HSM cluster servers cause the HSMs in the HSM cluster to commit the tombstone by deleting the tombstones and the associated cryptographic keys).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Grubin in the invention of Sachdeva in view of Mukhtar to include the above limitations. The motivation to do so would be to improves the reliability and performance of cryptographic processing (Grubin: column 2, lines 51-55).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Sachdeva in view of Mukhtar as applied to claim 8 above, and further in view of US 8824686 to Ishii et al (hereinafter Ishii).
As per claim 9, Sachdeva in view of Mukhtar does not teach the limitations of claim 9. However, Ishii teaches:
wherein the synchronization data further comprise a monotonic counter value which is indicative of a specific synchronization event (Ishii: column 5, lines 5-20: As a new object, typically an encryption key object, is added or an existing encryption key object modified, the content of the local sequence counter is assigned to that object and then incremented, illustratively monotonically, in anticipation of receiving the next object. Column 3, line 63-column 4, line 15: In a cluster of security appliance nodes, each node in the cluster has a unique identification and a separate identified space for storing key objects and a local sequence number space counter. Those key objects are assigned unique object identification and sequence numbers. Each key object, inserted into a node is identified by that node's ID, its own unique object identification number and a sequence number generated from its local sequence counter. In some applications other fields, e.g., version numbers, etc. may be appended to the above data fields within a key object. That newly inserted object, with the node's ID, the sequence number and any other appended fields, is then sent to all the nodes in the cluster. At the recipient node, each object is stored along with the sending node's (peer identification) ID, the received sequence number, the object's unique identification and any other fields. In this manner, the system is able to advantageously synchronize objects belonging to all the clustered nodes, even if a node goes offline).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Ishii in the invention of Sachdeva in view of Mukhtar to include the above limitations. The motivation to do so would be to allow synchronization of the identified spaces, as compared to synchronizing appliances (Ishii: column 3, lines 18-20).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20160065548 to Brouwer et al: Some embodiments provide non-transitory machine-readable medium that stores a program which when executed by at least one processing unit of a device synchronizes a set of keychains stored on the device with a set of other devices. The device and the set of other devices are communicatively coupled to one another through a peer-to-peer (P2P) network. The program receives a modification to a keychain in the set of keychains stored on the device. The program generates an update request for each device in the set of other devices in order to synchronize the set of keychains stored on device with the set of other devices. The program transmits through the P2P network the set of update requests to the set of other devices over a set of separate, secure communication channels.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MADHURI R HERZOG whose telephone number is (571)270-3359. The examiner can normally be reached 8:30AM-4:30PM.
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, Taghi Arani can be reached at (571)272-3787. 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.
MADHURI R. HERZOG
Primary Examiner
Art Unit 2438
/MADHURI R HERZOG/Primary Examiner, Art Unit 2438
Prosecution Insights