Notice of Pre-AIA or AIA Status
1. 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
2. Applicant’s arguments filed on 11/07/2025, with respect to the 35 U.S.C. § 103 rejection of claims 1-5 and 8 as allegedly being unpatentable over U.S. Patent No. 10,511,436 to Machani (hereinafter ““Machani’) in view of U.S. Patent Application Publication No. 2019/0140834 by Medivinsky (hereinafter “Medivinsky’), claims 9-12 stand rejected as allegedly being unpatentable over Machani and Medivinsky and further in view of U.S. Patent No. 9,806,883 to Doumen (hereinafter “Doumen’’) have been fully considered. However, upon further consideration, a new ground(s) of rejection is made in view of amended claims.
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.
3. Claims 1-5, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No.10511436 hereinafter Machani in view of U.S. Patent No. 10140612 hereinafter Murray.
As per claim 1, Machani discloses:
A method for providing a white-box cryptography module (Col. 1 Lines 36-45 “Methods and apparatus are provided for protecting key material using white-box cryptography and split key techniques. In one embodiment, an exemplary method comprises splitting a secret key of a software application provider into a plurality of key shares, wherein a subset of the plurality of key shares is needed to reconstruct the secret key; using one of the plurality of key shares to encrypt the remaining key shares of the plurality of key shares to obtain a set of wrapped key shares; applying the one key share to a white- box cryptography compiler to generate a white-box cryptographic program.”),
the method implemented by a server comprising a cryptographic module
configured to encrypt or decrypt a message based on input parameters comprising said message, a key and a response to a challenge (Col. 3 Lines 32- 45 “Generally, as discussed further below in conjunction with FIGS. 3 and 4, when a user executes the software application 125 embedding the white-box cryptography program 130 on the user device 120 and the software application 125 attempts to access a resource at the relying party 110, the relying party 110 server returns a challenge to the user device 120 and the wrapped second key share via a secure protocol exchange to the software application 125. The software application 125 then uses the wrapped second key share and the relying party server 110 challenge as input data to the white-box cryptography program 130 to compute a signature on the challenge, and then returns the signature to the relying party server 110 to authenticate and access the resource that is protected by the relying party 110.” Col. 4 Lines 5-22 “In various embodiments of the disclosure discussed herein, as discussed further below in conjunction with FIGS. 3 and 4, respectively, the white- box cryptography program compiler 170 generates a first white-box cryptography program 130-1 or a second white-box cryptography program 130-2. Generally, the first white-box cryptography program 130-1 performs a key wrapping function and key reconstruction using a threshold secret sharing scheme, and the cryptographic operations (such as data encryption/decryption or signing) using the reconstructed key. For example, the first white-box cryptography program 130-1 takes as input one or more wrapped key shares and challenge data produces and returns a signature on the data. The second white-box cryptography program 130-2 performs a key wrapping function and key reconstruction using a threshold secret sharing scheme. The second white-box cryptography program 130-2 takes as input one or more wrapped key shares and produces and returns the original key.”), the method comprising:
a step of obtaining a key for a terminal (Col. 5 Lines 5-12 “The exemplary authentication process 300 is initiated, for example, by the software application 125 executing on the user device 120, when the user attempts to access a resource (not shown) protected by a relying party server, such as relying party server 110-j. Relying party server 110-j returns a challenge and the wrapped key share Enc(skj, SKO) of the relying party server 110-j to the software application 125 during step 310.”);
a step of generating a white-box cryptography module, said white-box cryptography module being a white-box implementation of the cryptographic module of the server for said key obtained for this terminal (Col. 3 Lines 21-31 “n at least one embodiment, as discussed further below in conjunction with FIG. 2, the software application provider 160 generates a private key and a public key certificate, splits the private key into at least first and second key shares, uses the first key share as input into a white-box cryptography program compiler 170 that produces a white-box cryptography program 130 for a specific cryptography algorithm, uses the first key share to wrap the second key share, sends the wrapped second key share and the public key certificate to the RP 110, and optionally discards the original key and derived key shares.” Col. 3 Lines 57-60 “White-box cryptography technology comprises a program- generating compiler that takes as input a secret key and produces a program that implements a specific cryptographic algorithm with the specified secret key.”)
said white-box cryptography module being configured to encrypt or decrypt a message from said symmetric key buried in this module and input parameters comprising a message and a response to a challenge; and a step of providing said white-box cryptography module to said terminal (Col. 7 Line 51- Col. 8 Line 7 “One or more embodiments of the disclosure provide methods and apparatus for protecting key material using white-box cryptography and split key techniques. In one or more embodiments, a secret key of a software application provider is split into a plurality of key shares and one of the plurality of key shares is used to encrypt the remaining key shares of the plurality of key shares to obtain a set of wrapped key shares. The one key share is applied to a white- box cryptography compiler to generate a white-box cryptographic program. In addition, the software application provider generates a user application that is linked to the white-box cryptography program and is distributed to at least one user. The software application provider provides one of the set of wrapped key shares to a relying party. Upon the user application attempting to access a protected resource protected by the relying party, the relying party provides a challenge and the one wrapped key share of the relying party to the user application. The user application provides at least the one wrapped key share of the relying party to the white-box cryptographic program to obtain a digital signature in response to the challenge to provide to the relying party. The relying party verifies the signature to determine whether the user device is authorized to access the protected resource.”)
Machani does not disclose:
generating a white-box cryptography module with said symmetric key buried inside said white-box cryptography module
said symmetric key which is buried in this module
providing said white-box cryptography module with said symmetric key buried inside said white-box cryptography module, to said terminal
communicating with a terminal by using a key
Murray discloses:
generating a white-box cryptography module with said symmetric key buried inside said white-box cryptography module, said symmetric key which is buried in this module and providing said white-box cryptography module with said symmetric key buried inside said white-box cryptography module, to said terminal , communicating with a terminal by using a key (Col. 7 Lines 11-12 “Local encryption key 402 can be a symmetric or asymmetric encryption key. Local encryption key 402 can be a public key associated with a public key certificate that is stored in a secure memory on secure card reader 400 which is either injected into the secure card reader in a key injection room in a manufacturing facility or injected into the secure card reader using a remote key injection (RKI) procedure. Local encryption key 402 can be used as part of a white box encryption protocol to facilitate secure communication with smartphone 410 without delivering local encryption key 402 itself to smartphone 410. White box encryption conducted on smartphone 410 can use any number of encryption protocols or techniques. In particular, secure card reader 400 can generate, and smartphone 410 can use, white box instructions that implement the AES block cipher to encrypt the PIN in a format defined under the ISO 9564-1 (“PIN Block”) format. The ISO 9564-1 format may be used to encrypt both the PIN and the PAN to generate the PIN block. However, in certain approaches, it is beneficial to not transfer the PAN from secure card reader 400 unless it is encrypted with secret key 401. As such, a random number generated on secure card reader 400 could be used in place of the PAN when generating the white box instructions. The random number would be stored by secure card reader 400 in association with, or as part of, local encryption key 402 so that it could be used to decrypt the PIN. The random number could be a changed each time a set of white box instructions were generated by secure card reader 400.” Col. 8 Lines 49-61 “Although local encryption key 402 is never transferred from secure card reader 400 to smartphone 410, communications from the smartphone 410 to the secure card reader 400 can be conducted over a secure channel as secured by the encryption protocol of local encryption key 402 using white box encryption. As illustrated, secure card reader 400 can use local encryption key 402 as the input to white box encryption
generator 403 to generate a set of executable instructions that can be used to implement the encryption protocol of local encryption key
402 without being capable of revealing the key itself. White box encryption generator 403 can be a module instantiated on secure card reader 400 using a secure processor and memory.” Col. 9 Lines 11-17 “White box encryption can be conducted on smartphone 410 using the executable code generated by white box encryption generator 403 directly. The executable code can be transmitted from secure card reader 400 to smartphone 410 and executed by a processor on smartphone 410 using the sensitive data.” Col. 9 Lines 29-34 “Data representation generator 405 may take in the white box encryption instructions as an input and produce a complete data representation of the instructions.”)
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 the methods and apparatus are provided for protecting key material using white-box cryptography of Machani to include generating a white-box cryptography module with said symmetric key buried inside said white-box cryptography module, as taught by Murray.
The motivation would have been to provide secure communication between secure card reader and smartphone without transferring local encryption key to smartphone (Murray Col. 8 Lines 27-30 )
As per claim 2, Machani in view of Murray discloses:
The provision method according to of claim 1, this method further comprising a step of receiving and recording at least one challenge/response pair from said terminal (Machani Col. 3 Lines 32-45 and Col. 7 Line 51- Col. 8 Line 7).
As per claim 3, the implementation of the method of claim 1 will execute the method for encrypting a message of claim 3. The claim is analyzed in view of claim 1.
As per claim 4, the implementation of the method of claim 1 will execute the method for decrypting a message of claim 4 including response received from the terminal corresponding to a response of a challenge/response pair received from the terminal in a prior enrollment phase (Machani Col. 7 Line 51- Col. 8 Line 7). The claim is analyzed in view of claim 1.
As per claim 5, the implementation of the method of claim 1 will execute the server of claim 5. The claim is analyzed in view of claim 1.
As per claim 8, Machani discloses:
A method for obtaining a white-box cryptography module, the method
implemented by a terminal, (Col. 1 Lines 36-45 “Methods and apparatus are provided for protecting key material using white-box cryptography and split key
techniques. In one embodiment, an exemplary method comprises splitting a secret key of a software application provider into a plurality of key shares, wherein a subset of the plurality of key shares is needed to reconstruct the secret key; using one of the plurality of key shares to encrypt the remaining key shares of the plurality of key shares to obtain a set of wrapped key shares; applying the one key share to a white-box cryptography compiler to generate a white- box cryptographic program.”),
the method comprising:
sending an identifier of the terminal to a server comprising a cryptographic module configured to encrypt or decrypt a message based on input parameters comprising said message (Col. 4 Lines 53-57 “Meanwhile, the software application provider 160 sends the first key share, sK.sub.0, to the white-box crypto compiler 170 during step 250 and generates the white-box crypto program 130 during step 255, which is optionally stored in a white-box program library 260.”),
a response to a challenge and a key (Col. 5 Line 5-12 “The exemplary authentication process 300 is initiated, for example, by the software application 125 executing on the user device 120, when the user attempts to access a resource (not shown) protected by a relying party server, such as relying party server 110-j. Relying party server 110-j returns a challenge and the wrapped key share Enc(skj, SKO) of the relying party server 110-j to the software application 125 during step 310.”):
receiving a white-box cryptography module constituting a white-box
implementation of the cryptographic module of said server for said key said white-box cryptography module being configured to encrypt or decrypt a message from said key buried in this module and input parameters comprising a message and a response to a challenge terminal (Col. 7 Line 51- Col. 8 Line 7 “One or more embodiments of the disclosure provide methods and apparatus for protecting key material using white-box cryptography and split key techniques. In one or more embodiments, a secret key of a software application provider is split into a plurality of key shares and one of the plurality of key shares is used to encrypt the remaining key shares of the plurality of key shares to obtain a set of wrapped key shares. The one key share is applied to a white-box cryptography compiler to generate a white-box cryptographic program. In addition, the software application provider generates a user application that is linked to the white- box cryptography program and is distributed to at least one user. The software application provider provides one of the set of wrapped key shares to a relying party. Upon the user application attempting to access a protected resource protected by the relying party, the relying party provides a challenge and the one wrapped key share of the relying party to the user application. The user application provides at least the one wrapped key share of the relying party to the white-box cryptographic program to obtain a digital signature in response to the challenge to provide to the relying party. The relying party verifies the signature to determine whether the user device is authorized to access the protected resource.”)
Machani does not disclose:
receiving a white-box cryptography module with said symmetric key buried inside, the white-box cryptography module constituting a white-box implementation and said symmetric key which is buried in this module
Murray discloses:
receiving a white-box cryptography module with said symmetric key buried inside, the white-box cryptography module constituting a white-box implementation and said symmetric key which is buried in this module (Col. 7 Lines 11-12 “Local encryption key 402 can be a symmetric or asymmetric encryption key. Local encryption key 402 can be a public key associated with a public key certificate that is stored in a secure memory on secure card reader 400 which is either injected into the secure card reader in a key injection room in a manufacturing facility or injected into the secure card reader using a remote key injection (RKI) procedure. Local encryption key 402 can be used as part of a white box encryption protocol to facilitate secure communication with smartphone 410 without delivering local encryption key 402 itself to smartphone 410. White box encryption conducted on smartphone 410 can use any number of encryption protocols or techniques. In particular, secure card reader 400 can generate, and smartphone 410 can use, white box instructions that implement the AES block cipher to encrypt the PIN in a format defined under the ISO 9564-1 (“PIN Block”) format. The ISO 9564-1 format may be used to encrypt both the PIN and the PAN to generate the PIN block. However, in certain approaches, it is beneficial to not transfer the PAN from secure card reader 400 unless it is encrypted with secret key 401. As such, a random number generated on secure card reader 400 could be used in place of the PAN when generating the white box instructions. The random number would be stored by secure card reader 400 in association with, or as part of, local encryption key 402 so that it could be used to decrypt the PIN. The random number could be a changed each time a set of white box instructions were generated by secure card reader 400.” Col. 8 Lines 49-61 “Although local encryption key 402 is never transferred from secure card reader 400 to smartphone 410, communications from the smartphone 410 to the secure card reader 400 can be conducted over a secure channel as secured by the encryption protocol of local encryption key 402 using white box encryption. As illustrated, secure card reader 400 can use local encryption key 402 as the input to white box encryption
generator 403 to generate a set of executable instructions that can be used to implement the encryption protocol of local encryption key
402 without being capable of revealing the key itself. White box encryption generator 403 can be a module instantiated on secure card reader 400 using a secure processor and memory.” Col. 9 Lines 11-17 “White box encryption can be conducted on smartphone 410 using the executable code generated by white box encryption generator 403 directly. The executable code can be transmitted from secure card reader 400 to smartphone 410 and executed by a processor on smartphone 410 using the sensitive data.” Col. 9 Lines 29-34 “Data representation generator 405 may take in the white box encryption instructions as an input and produce a complete data representation of the instructions.”)
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 the methods and apparatus are provided for protecting key material using white-box cryptography of Machani to include receiving a white-box cryptography module with said symmetric key buried inside, the white-box cryptography module constituting a white-box implementation and said symmetric key which is buried in this module, as taught by Murray.
The motivation would have been to provide secure communication between secure card reader and smartphone without transferring local encryption key to smartphone (Murray Col. 8 Lines 27-30)
As per claim 9, Machani in view of Murray discloses:
The method of claim 1, wherein the symmetric key used by the terminal is not stored in a memory of the terminal, the symmetric key being hidden in a code of the white-box cryptography module generated by the server (Murray Col. 7 Lines 11-12 “Local encryption key 402 can be a symmetric or asymmetric encryption key. Local encryption key 402 can be a public key associated with a public key certificate that is stored in a secure memory on secure card reader 400 which is either injected into the secure card reader in a key injection room in a manufacturing facility or injected into the secure card reader using a remote key injection (RKI) procedure. Local encryption key 402 can be used as part of a white box encryption protocol to facilitate secure communication with smartphone 410 without delivering local encryption key 402 itself to smartphone 410. White box encryption conducted on smartphone 410 can use any number of encryption protocols or techniques. In particular, secure card reader 400 can generate, and smartphone 410 can use, white box instructions that implement the AES block cipher to encrypt the PIN in a format defined under the ISO 9564-1 (“PIN Block”) format. The ISO 9564-1 format may be used to encrypt both the PIN and the PAN to generate the PIN block. However, in certain approaches, it is beneficial to not transfer the PAN from secure card reader 400 unless it is encrypted with secret key 401. As such, a random number generated on secure card reader 400 could be used in place of the PAN when generating the white box instructions. The random number would be stored by secure card reader 400 in association with, or as part of, local encryption key 402 so that it could be used to decrypt the PIN. The random number could be a changed each time a set of white box instructions were generated by secure card reader 400.” Col. 8 Lines 49-61 “Although local encryption key 402 is never transferred from secure card reader 400 to smartphone 410, communications from the smartphone 410 to the secure card reader 400 can be conducted over a secure channel as secured by the encryption protocol of local encryption key 402 using white box encryption. As illustrated, secure card reader 400 can use local encryption key 402 as the input to white box encryption
generator 403 to generate a set of executable instructions that can be used to implement the encryption protocol of local encryption key
402 without being capable of revealing the key itself. White box encryption generator 403 can be a module instantiated on secure card reader 400 using a secure processor and memory.” Col. 9 Lines 11-17 “White box encryption can be conducted on smartphone 410 using the executable code generated by white box encryption generator 403 directly. The executable code can be transmitted from secure card reader 400 to smartphone 410 and executed by a processor on smartphone 410 using the sensitive data.” Col. 9 Lines 29-34 “Data representation generator 405 may take in the white box encryption instructions as an input and produce a complete data representation of the instructions.” The motivation would have been to provide secure communication between secure card reader and smartphone without transferring local encryption key to smartphone (Murray Col. 8 Lines 27-30))
4. Claims 9-12 are rejected under 35 U.S.C. 103 as being unpatentable over Machani in view of Murray, and further in view of U.S. Patent no. 9,806,883 hereinafter Doumen.
As per claim 9, Machani in view of Murray discloses:
The method of claim 8 further comprising of obtaining at least one challenge/response pair of sending said at least one challenge/response pair to said server (Machani Col. 7 Line 51- Col. 8 Line 7)
Machani in view of Murray does not disclose:
said response being obtained from said challenge and from a probabilistic function implementing a physical unclonable function of the terminal
Doumen discloses:
said response being obtained from said challenge and from a probabilistic function implementing a physical unclonable function of the terminal (Col. 5 Line 31-50 “Therefore, the second parameter may, with its property of not being able to be predefined by the request unit or of being used completely without influence by the request unit, also be generated by the provision unit on the basis of specific data. If an identifier is included in the determination of the second parameter, the derived key is individualized, in particular, for the specimen or the device on which the digital circuit area is set up. The identifier may be a chip identification tag, a serial number, or an identifier, which is produced by the challenge-response inquiry of a physically unclonable function. Furthermore, memory contents of a configuration memory or program memory or the memory contents of a connected peripheral device such as, in particular, a sensor, an actuator or a memory card, may be included in the generation of the second
parameter. In addition, the dependence on a random number is advantageous, in particular for key diversification. The second parameter may depend on one or more of the variants described or may be derived directly from one or more of the variants described.”)
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 the methods and apparatus are provided for protecting key material using white-box cryptography of Machani in view of Murray to include said response being obtained from said challenge and from a probabilistic function implementing a physical unclonable function of the terminal, as taught by Doumen.
The motivation would have been to utilize a physical unclonable function to increase the security of challenge and response by a terminal.
As per claim 10, the implementation of the method of claims 8 and 9 will execute the method for encrypting a message of claim 10. The claim is analyzed in view of claim 1.
As per claim 11, the implementation of the method of claims 8 and 9 will execute the method for decrypting a message of claim 11. The claim is analyzed in view of claim 1.
As per claim 12, the implementation of the method of claims 8 and 9 will execute terminal of claim 12. The claim is analyzed in view of claim 1.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GARY S GRACIA whose telephone number is (571)270-5192. The examiner can normally be reached Monday-Friday 9am-6pm.
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, Ashok Patel can be reached at 5712723972. 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.
/GARY S GRACIA/Primary Examiner, Art Unit 2499