DETAILED ACTION
The objection to the specification is withdrawn based on the amendments filed 12/09/2025.
Claims 1-20 are rejected.
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 .
Response to Arguments
Applicant’s arguments, filed 12/09/25, with respect to claim(s) 1, 11, and 16 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Regarding applicant’s argument, on page 3 of the remarks, that Ng teaches away from the claim limitation, Examiner respectfully disagrees. Applicant argues that Claim 1 requires that the first entity is not configurable to generate the random number generator, where in fact, the claim requires that the second entity is not configurable to generate the random number, which Ng teaches in Fig. 2, element 250. Applicant further argues that Ng is used to teach “transmitting, by the first entity, a second random number to the second entity to initiate a process for authenticating the second entity”, however, Examiner did not use Ng to teach that claim limitation. Examiner used Harada to teach the limitation “transmitting, by the first entity, a second random number to the second entity to initiate a process for authenticating the second entity”. Further Ng does disclose that the second entity is being authenticated in para.[0070]. Therefore, Ng does not teach away from the limitation.
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claim(s) 1-7 and 11-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20250280295 A1 to Garcia et al. (Garcia) in view of US 20150012737 A1 to Newell (Newell).
Regarding claim 1, Garcia teaches a computer-implemented method, comprising: generating, by a first entity a secure session key and an initialization vector for integrity protecting messages transmitted between the first entity and a second entity (Garcia [0286], e.g., derive this SK by the UE (100); [0239]-[0240], e.g., Note that a MitM might still “replace” the encrypted key by a different key K′ of its wish…… To avoid this situation, the key K can be placed next to a field that requires verification or is used in a subsequent authentication procedure…… Note that it is also beneficial if the key is encrypted next to a parameter that prevents replay attacks such as, e.g., a nonce or a time-based counter), wherein the secure session key is generated based on a first random number and a pre-shared secret (Garcia [0286], e.g., This shared key SK might be directly generated from the master secret MS using as input, e.g., nonces generated by UE (100) and CN (103)), wherein the first random number is shared via a transmission by the first entity of a first random number message to the second entity (Garcia [0286], e.g., If the SK is derived in a different way additional checks might also be applicable, e.g., whether a nonce sent by the UE in message 110 is used for the key derivation) and wherein the first entity receives the pre-shared secret of the second entity during provisioning (Garcia [0286], e.g., a shared key SK derived from a master secret MS shared between UE (100) and the home core network already upon reception of the initial message 111; Note master secret is shared prior to generation of session key), wherein the first entity increments the initialization vector subsequent to sending each message of a plurality of messages from the first entity to the second entity to prevent a replay attack via prior messages by a malicious entity (Garcia [0239]-[0240], e.g., Note that a MitM might still “replace” the encrypted key by a different key K′ of its wish…… To avoid this situation, the key K can be placed next to a field that requires verification or is used in a subsequent authentication procedure…… Note that it is also beneficial if the key is encrypted next to a parameter that prevents replay attacks such as, e.g., a nonce or a time-based counter).
Garcia does not explicitly teach, but Newell teaches transmitting, by the first entity, a second random number to the second entity to initiate a process for authenticating the second entity (Newell [0053], e.g., At reference numeral 106, the Secure SoC FPGA 52 generates a nonce using its internal TRNG 66…… At reference numeral 112, the nonce generated at reference numeral 106 is passed to the AES-based CBC-MAC to begin generation of a unique message authentication code (MAC) tag; [0054], e.g., At reference numeral 116, the nonce is served by the Secure SoC FPGA 52 to the target processor 72 over the SPI bus 86; Note secure SoC = first entity, target processor = second entity), wherein the second entity is resource constrained relative to the first entity and is not configurable to generate the second random number (Newell Fig. 3, Secure SoC FPGA comprises TRNG and target processor does not comprise TRNG), wherein the first entity authenticates the second entity, in response to receiving the second random number that was transmitted to the second entity, back from the second entity (Newell [0055]-[0056], e.g., After it completes the MAC calculation, the target processor writes the calculated MAC tag back to the Secure SoC FPGA 52 via the SPI bus 86…… At reference numeral 126, the Secure SoC FPGA 52 compares the recreated MAC tag received from the target processor 72 with the MAC it previously generated internally. If the two MAC values are the same, the process continues to the procedures shown in FIG. 5; Note that the nonce is part of the MAC calculation), and wherein, in response to authenticating the second entity by the first entity, the second entity is allowed to continue booting (Newell [0056], e.g., If the two MAC values are the same, the process continues to the procedures shown in FIG. 5; [0016], e.g., The secure chip sends the target processor (e.g., as part of the code upload) an unpredictable nonce (number used only once, such as a large enough random number), and the target processor has to respond correctly, proving it has loaded and is executing exactly the delivered code and has the current nonce…… If this response is correct, the secure chip is assured that the process has not been subverted, and it allows the target processor to execute the now-trusted code).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Garcia with the teachings of Newell with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of guaranteeing that a target processor is running authentic code (Newell [0021], e.g., The present invention entails using an external root of trust chip (such as SmartFusion®2) to provide the required assurance that the target processor is executing trusted code. If the root of trust chip detects that the process has been tampered with, then it provides a penalty that makes further tampering or exploitation more difficult for the adversary).
Regarding claim 2, most of the limitations of this claim have been noted in the rejection of claim 1. Garcia does not teach, but Newell teaches transmitting, by the first entity, a read message to the second entity, wherein the read message includes a request that the second entity return the second random number to the first entity (Newell [0054]-[0055], e.g., At reference numeral 116, the nonce is served by the Secure SoC FPGA 52 to the target processor 72 over the SPI bus 86…… After it completes the MAC calculation, the target processor writes the calculated MAC tag back to the Secure SoC FPGA 52 via the SPI bus 86; Note secure SoC = first entity, target processor = second entity). The motivation to combine is the same as that of claim 1.
Regarding claim 3, most of the limitations of this claim have been noted in the rejection of claim 2. Garcia does not explicitly teach, but Newell teaches receiving, by the first entity from the second entity, a second random number message that is integrity protected using a Machine Authentication Code (MAC) (Newell [0055], e.g., After it completes the MAC calculation, the target processor writes the calculated MAC tag back to the Secure SoC FPGA 52 via the SPI bus 86; Note secure SoC = first entity, target processor = second entity) that is calculated using the secure session key and the initialization vector (Newell [0053], e.g., the Secure SoC FPGA 52 either fetches an AES key from eNVM 60 or generates a new AES key using the TRNG 66, or some deterministic method. At reference numeral 110, the AES-based CBC-MAC algorithm is configured in the Secure SoC FPGA 52 by initializing it with an initialization vector (IV) with a value of zero, as per the CBC-MAC standard. At reference numeral 112, the nonce generated at reference numeral 106 is passed to the AES-based CBC-MAC to begin generation of a unique message authentication code (MAC) tag), wherein the second random number message contains the second random number (Newell [0053], e.g., the nonce generated at reference numeral 106 is passed to the AES-based CBC-MAC to begin generation of a unique message authentication code (MAC) tag).
The motivation to combine is the same as that of claim 1.
Regarding claim 4, most of the limitations of this claim have been noted in the rejection of claim 3. Garcia does not explicitly teach, but Newell teaches authenticating the second entity by the first entity via operations comprising: confirming a validity of the second random number message based on the MAC (Newell [0056], e.g., At reference numeral 126, the Secure SoC FPGA 52 compares the recreated MAC tag received from the target processor 72 with the MAC it previously generated internally. If the two MAC values are the same, the process continues to the procedures shown in FIG. 5); and confirming that a number of the second random number message matches the second random number (Newell [0056], e.g., If the two MAC values are the same, the process continues to the procedures shown in FIG. 5).
The motivation to combine is the same as that of claim 1.
Regarding claim 5, most of the limitations of this claim have been noted in the rejection of claim 1. Garcia does not explicitly teach, but Newell teaches wherein the first entity is a Root-of-Trust (RoT) chiplet (Newell [0015], e.g., a more secure chip such as a secure SoC FPGA…… The terms “secure chip”, “root of trust”, and “secure root of trust” are used interchangeably herein) and the second entity is another chiplet in a System in a Package (SiP) (Newell [0006], e.g., In the context of this invention, “processor” refers to an electronic circuit that is programmed or configured with object code…… Some types of processors envisioned for use in the invention include, without limitation, single or multi-chip microprocessors (MPUs)… system-on-chip (SoC) integrated circuits), and wherein the RoT has a capability to prevent the second entity from becoming operational (Newell [0035], e.g., According to one aspect of the present invention, response to an invalid digital signature or MAC tag triggers one or more penalty responses, such as asserting reset on the target processor, disabling I/O on the board, disrupting power to the board, and disrupting communications facilities or interfaces on the board).
The motivation to combine is the same as that of claim 1.
Regarding claim 6, most of the limitations of this claim have been noted in the rejection of claim 1. Garcia does not explicitly teach, but Newell teaches wherein the second entity has lower processing power in comparison to the first entity (Newell [0011], e.g., Securely booting non-secure processors is challenging when the target processor has no built-in security capabilities…… These processors typically have no security capability and are especially vulnerable to attack; [0019], e.g., The present invention allows one to achieve a relatively high level of assurance in processors that do not have such built-in secure boot features as described above. For instance, many digital signal processor (DSP) ICs do not include any secure boot features, nor do many embedded processors, and even quite a few application processors do not yet support secure boot intrinsically), and wherein resources in the second entity are inadequate for executing a random number generator to generate the second random number (Newell Fig. 3, target processor does not contain TRNG, so it cannot generate a random number).
The motivation to combine is the same as that of claim 1.
Regarding claim 7, most of the limitations of this claim have been noted in the rejection of claim 1. Garcia does not explicitly teach, but Newell teaches wherein the second entity has lower processing power in comparison to the first entity (Newell [0011], e.g., Securely booting non-secure processors is challenging when the target processor has no built-in security capabilities…… These processors typically have no security capability and are especially vulnerable to attack; [0019], e.g., The present invention allows one to achieve a relatively high level of assurance in processors that do not have such built-in secure boot features as described above. For instance, many digital signal processor (DSP) ICs do not include any secure boot features, nor do many embedded processors, and even quite a few application processors do not yet support secure boot intrinsically), and wherein resources in the second entity are used for performing operations that do not include generation of the second random number via a random number generator (Newell Fig. 3, target processor does not contain TRNG, so it cannot generate a random number; [0055], e.g., the nonce is fed to the AES-based CBC-MAC algorithm in the target processor after it is initialized to start calculating the MAC tag).
The motivation to combine is the same as that of claim 1.
Regarding claim 11, Garcia teaches a system, comprising: a memory (Garcia [0021], e.g., a memory adapted to store information); and a processor coupled to the memory (Garcia [0918], e.g., A single processor or other unit may fulfil the functions of several items recited in the claims). The rest of the claim recites a system of the method of claim 1, and is similarly analyzed.
Regarding claim 12, the claim recites a system of the method of claim 2, and is similarly analyzed.
Regarding claim 13, the claim recites a system of the method of claim 3, and is similarly analyzed.
Regarding claim 14, the claim recites a system of the method of claim 4, and is similarly analyzed.
Regarding claim 15, the claim recites a system of the method of claim 5, and is similarly analyzed.
Regarding claim 16, Garcia teaches a computer program product comprising a computer readable storage medium having computer readable program code embodied therewith (Garcia [0920], e.g., The described operations like those indicated in, e.g., FIGS. 4, 5 and 6 be implemented as program code means of a computer program and/or as dedicated hardware of the related network device or function, respectively. The computer program may be stored and/or distributed on a suitable medium). The rest of the claim recites a computer readable storage medium of the method of claim 1, and is similarly analyzed.
Regarding claim 17, the claim recites a computer readable storage medium of the method of claim 2, and is similarly analyzed.
Regarding claim 18, the claim recites a computer readable storage medium of the method of claim 3, and is similarly analyzed.
Regarding claim 19, the claim recites a computer readable storage medium of the method of claim 4, and is similarly analyzed.
Regarding claim 20, the claim recites a computer readable storage medium of the method of claim 5, and is similarly analyzed.
Claim(s) 8-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Garcia in view of Newell, and in further view of US 20200211004 A1 to Ng et al. (Ng).
Regarding claim 8, most of the limitations of this claim have been noted in the rejection of claim 1. Garcia and Newell do not explicitly teach, but Ng teaches wherein a third random number is used by the second entity to authenticate the first entity (Ng [0066], e.g., In various first embodiments, the sending of the second random number associated with the first device from the first device to the second device and the sending of the third random number associated with the second device from the second device to the first device may be considered or referred to as the first and second device exchanging the second and third random numbers for authentication purpose; Note that the second random number = the third random number of the instant application and third random number = the second random number).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the combined teachings of Garcia and Newell with the teachings of Ng with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of improving security (Ng [0063], e.g., the authentication method is performed based on the verification of the above-mentioned first random number between the server and the first device, which for example is helpful to defend against man-in-the-middle (MITM) attacks on the communication link between the server and the first device. In addition, the authentication method is further performed based on the verification of the above-mentioned second random number between the server and the second device for further verifying the identity of the first device, which for example is helpful to defend against replay attacks. In various embodiments, the authentication method is further strengthened by utilizing public key cryptography challenged responses in various steps thereof, which for example is helpful to secure against impersonation attack).
Regarding claim 9, most of the limitations of this claim have been noted in the rejection of claim 8. Garcia and Newell do not explicitly teach, but Ng teaches wherein both the first entity and the second entity mutually authenticate each other (Ng [0066], e.g., may be considered or referred to as the first and second device exchanging the second and third random numbers for authentication purpose; Note that the second random number = the third random number of the instant application and third random number = the second random number), wherein the second random number and the third random number can be transmitted simultaneously (Ng [0097], e.g., Furthermore, one or more of the steps of a computer program/module or method described herein may be performed in parallel rather than sequentially, [0088], e.g., receive the second random number and the third random number from the second device 250 and the first device 230, respectively, for authenticating the first device 230 and the second device 250 for the transaction based on the second random number and the third random number), and wherein the third random number is integrity protected (Ng [0068], e.g., Similarly, in various first embodiments, the method 100 further comprises sending, by the second device, a digital signature of the second random number generated based on a second key of the third private-public key pair (e.g., the second device's private key) to the server for authenticating the first device for the transaction further based on the digital signature of the second random number; Note that second random number = the third random number of the instant application).
The motivation to combine is the same as that of claim 8.
Regarding claim 10, most of the limitations of this claim have been noted in the rejection of claim 9. Garcia does not explicitly teach, but Newell teaches a second random number message and a second MAC that allow the first entity to authenticate the second entity (Newell [0053], e.g., the nonce generated at reference numeral 106 is passed to the AES-based CBC-MAC to begin generation of a unique message authentication code (MAC) tag; [0054], e.g., At reference numeral 116, the nonce is served by the Secure SoC FPGA 52 to the target processor 72 over the SPI bus 86; [0055], e.g., After it completes the MAC calculation, the target processor writes the calculated MAC tag back to the Secure SoC FPGA 52 via the SPI bus 86).
The motivation to combine is the same as that of claim 1.
Garcia and Newell do not explicitly teach, but Ng teaches wherein the mutual authentication is performed via: the third random number [and a first MAC] that allow the second entity to authenticate the first entity (Ng [0066], e.g., the first and second device exchanging the second and third random numbers for authentication purpose).
The motivation to combine is the same as that of claim 8.
Garcia, Newell, and Ng do not explicitly teach sending a third random number and a first MAC that allow the second entity to authenticate the first entity, however, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have modified the Newell’s MAC generation to send Ng’s third random number because the Newell already provides a current system of generating and sending messages using message authentication code.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE TRUONG whose telephone number is (571)272-6973. The examiner can normally be reached Monday - Friday, 8:00 am - 4 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, Ali Shayanfar can be reached at (571) 270-1050. 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.
/LAWRENCE TRUONG/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434