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 .
DETAILED ACTION
This is the initial office action that has been issued in response to patent application, 19/020,407, filed on 09/15/2020. Claims 1-18 are currently pending and have been considered below. Claims 1 and 14 are independent claims.
Priority
The application claims foreign priority of France 2400497, filed on 01/18/2024.
Drawings
The drawings filed on 01/14/2025 are accepted by the examiner.
Information Disclosure Statement
The information disclosure statements (IDS’s) submitted on 09/15/2020, 09/16/2020 and 09/30/2021 are in compliance with provisions of 37 CFR 1.97. Accordingly, the information disclosure statement.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
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.
Claims 1-18 are rejected under 35 U.S.C. 103 as being unpatentable over Ashkenazi (US Publication No. 20140317417 A1) and Miller(US Publication No. 20150127946 A1) in view of Braams(US Publication No. 2010/0058317 A1).
Regarding Claim 1:
Ashkenazi discloses:
A method, comprising: a) receiving, by an electronic device, a software module of a first application, (Ashkenazi, [0035], a public key used to authenticate software authorized for execution on wireless device 100. The software may be signed based on a private key);
b) generating, by a cryptographic circuit of the electronic device, an encryption key based on both a secret key of the electronic device and one of: the public key or an identification value derived from the public key(Ashkenazi, [0005], working key based on a hardware secret key as well as at least one security parameter of the device. [0007], the at least one security parameter may include a public key);
c) generating, by the cryptographic circuit, one or a plurality of protected data items by applying a cryptographic operation on one or a plurality of first data items associated with the first application and based on the encryption key(Ashkenazi,Abstract, the working key may be used to encrypt, sign, decrypt, or verify data for the device.);
Ashkenazi does not disclose:
and d) storing the one or plurality of protected data items in a first portion of a memory of the electronic device
Miller discloses:
and d) storing the one or plurality of protected data items in a first portion of a memory of the electronic device(Miller, [0048], The encrypted data of storage device 150N is represented by encrypted data 170N. The key, along with another value specific to the storage device, may be conveyed from each storage device 150 to key encryption unit 130.).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Ashkenazi’s generation of working security key based on security parameters by enhancing Ashkenazi’s systems for storing protected data items resulting from cryptographic operations in a defined portion of memory to ensure organized and secure placement of encrypted data within device storage as taught by Miller in order to enhance data protection and structured memory management within the electronic device. The motivation is to ensure that encrypted or protected data is stored in a specific memory region to improve security, data isolation, and efficient retrieval.
Ashkenazi in view Miller do not disclose:
the software module comprising a public key associated with signature values for an entity that designed and supplied the software module of the first application
Braams discloses:
the software module comprising a public key associated with signature values for an entity that designed and supplied the software module of the first application(Braams, [0015], The host is used to obtain and store a software module for an electronic device, including a payload (which may comprise the actual program code, a firmware image)… the signature over the payload… the signature over the software module should be generated by the entity whose public key is pre-loaded in the electronic device…[0020], The host may also advantageously verify the signature provided in the software module… The public key may be found in one of the certificates, if certificates are present in the software module…[0006], Such signature must be generated with the software provider's private key, and can be verified with the software provider's corresponding public key, which should be provided and certified to the electronic device, or pre-loaded in the electronic device.)
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Ashkenazi in view of Miller’s generation of working security key based on security parameters by enhancing Ashkenazi’ in view of Miller’s systems to associate the public key included with the software module with signature values generated by the software provider as taught by Braams in order to enhance verification of the origin and authenticity of the software module The motivation is to ensure that the received software module originates from an authorized software provider and has not been improperly modified prior to use by the electronic device.
Regarding Claim 2:
The method according to claim 1, Ashkenazi and Miller in view of Braams disclose wherein the cryptographic operation comprises encrypting, by using the encryption key, the one or plurality of first data items(Ashkenazi, [0006], the working key may be used to encrypt, sign, decrypt, or verify data for the device. The working key may be used directly or indirectly by the software for the at least one security function.).
Regarding Claim 3:
The method according to claim 1, Ashkenazi and Miller in view of Braams disclsoe wherein the cryptographic operation comprises calculating one or a plurality of first signature values associated with the one or plurality of first data items by using the encryption key, the one or plurality of protected data items comprising the one or plurality of first signature values(Ashkenazi, [0006], the working key may be used to encrypt, sign, decrypt, or verify data for the device. The working key may be used directly or indirectly by the software for the at least one security function.).
Regarding Claim 4:
The method according to claim 1, Ashkenazi and Miller in view of Braams disclose wherein the encryption key corresponds to a secret key derived by applying a key derivation function by the cryptographic circuit based on the identification value, the identification value resulting from a hashing of the public key(Ashkenazi,[0058], Various key derivation functions may be used for key derivation function 522 at secure server 510 and device 550. [0062], the at least one security parameter may comprise a public key).
Regarding Claim 5:
The method according to claim 1, Ashkenazi and Miller in view of Braams disclose wherein the software module comprises an execution code, and a second signature value associated with the execution code, the method further comprising, prior to generating the one or plurality of protected data items, authenticating the software module based on a verification of the second signature value via the public key(Ashkenazi, [0042], A secure hash function 330 may hash software loaded onto wireless device 100 and may provide a hash digest…Signature SX may be stored in memory 150. Sign function 332 may implement the RSA, DSA, or some other cryptographic algorithm. The software may be stored in memory 150 (or some other memory) on wireless device 100. [0043], public key X′ from certificate CR, verify signature SR with public root key R′, and provide public key X′ if signature SR is verified. [0044], A verify function 390 may receive digest S′ from secure hash function 380, digital signature SX from memory… Verify function 390 may verify digital signature SX with public key X′ and digest S′ and may indicate whether or not digital signature SX is verified…If digital signature SX is verified, then the software may be provided for use).
Regarding Claim 6:
The method according to claim 5, Ashkenazi and Miller in view of Braams disclose further comprising storing the execution code in a second portion of the memory distinct from the first portion(Ashkenazi, [0020],an internal memory 130, a secure memory 140, a memory controller 148, and an input/output (I/O) controller 158, all of which may communicate with one another via one or more data buses 160. [0021] Internal memory 130 may store software 132 and/or data used by the processors and controllers within digital module 120. Memory 130 may be implemented with static random).
Regarding Claim 7:
The method according to claim 1, Ashkenazi and Miller in view of Braams disclose wherein steps a) to d) are carried out via a software platform of the electronic device(Ashkenazi, [0020], Digital module 120 may include various processing, interface, and memory units to support digital processing for wireless device 100. [0021], . Internal memory 130 may store software 132 and/or data used by the processors and controllers [0056], Key derivation function 522 and crypto engine 530 may be implemented with hardware, software, and/or firmware and may be implemented by (e.g., executed on) a processor 521 within secure server 510.).
Regarding Claim 8:
The method according to claim 1, Ashkenazi and Miller in view of Braams disclose further comprising, prior to carrying out step b): generating a verification value by applying a hash function to the public key(Ashkenazi, [0042], A secure hash function 330 may hash software loaded onto wireless device 100 and may provide a hash digest S. Secure hash function 330 may implement SHA-1, SHA-2, MD-5, or some other secure hash algorithm. [0058], A key derivation function may utilize one or more cryptographic hash functions such as SHA-1 (Secure Hash Algorithm), SHA-2 (which includes SHA-224, SHA-256, SHA-384 and SHA-512), MD-4 (Message Digest), MD-5, etc);
comparing the verification value with the identification value(Ashkenazi, [0044], A verify function 390 may receive digest S′ from secure hash function 380, digital signature SX from memory 150, and public key X′ from verify function 370. Verify function 390 may verify digital signature SX with public key X′ and digest S′ and may indicate whether or not digital signature SX is verified. Public key X′ is authenticated with public root key R′.);
and when the verification value and the identification value do not match, removing the software module(Ashkenazi, [0044], Public key X′ is authenticated with public root key R′. Hence, any tampering with digital signature SX and/or the software by a third party can be easily detected by digital signature SX not verifying, [0046], software that has been authorized for wireless device 100 can be executed on wireless device 100).
Regarding Claim 9:
The method according to claim 1, Ashkenazi and Miller in view of Braams disclose further comprising generating, by the cryptographic circuit, the identification value by applying a hash function to the public key(Ashkenazi, [0058], A key derivation function may utilize one or more cryptographic hash functions such as SHA-1 (Secure Hash Algorithm), SHA-2 (which includes SHA-224, SHA-256, SHA-384 and SHA-512), MD-4 (Message Digest), MD-5, etc [0062], the at least one security parameter may comprise a public key).
Regarding Claim 10:
The method according to claim 1, Ashkenazi and Miller in view of Braams disclose wherein the secret key of the electronic device is one of: a hardware unique key or a key derived from a hardware unique key(Ashkenazi, [0026], a hardware (HW) secret key on wireless device 100 (step 1). The key provisioning entity may be an integrated circuit (IC) chip manufacture of an IC chip (e.g., an ASIC) used in wireless device 100 (as shown in FIG. 2) or some other entity. The hardware secret key may be stored in secure memory 140 on wireless device 100. [0051], generating a working key based on a hardware secret key as well as at least one security parameter, which may be related to software authorized for the device. [0055], 0, key derivation function 522 may generate the working key for device 550 based on hardware secret key 542 and at least one security parameter 544 of device 550.).
Regarding Claim 11:
The method according to claim 1, Ashkenazi and Miller in view of Braams disclose further comprising modifying the public key during an update of the first application(Ashkenazi, [0035], a public key used to authenticate software authorized for execution on wireless device 100 . [0027], The device manufacturer typically loads software, loads security parameters, and enables security functions on wireless device 100 (step 2).).
Regarding Claim 12:
The method according to claim 1, Ashkenazi and Miller in view of Braams disclose further comprising executing, by a processor of the device, the first application by retrieving the one or plurality of first data items associated with the first application, by: extracting the public key and performing a new generation of the encryption key based on both a secret key of the electronic device and one of: the public key or an identification value derived from the public key(Ashkenazi, [0019], Digital module 120 may process (e.g., demodulate and decode) the input baseband signal to recover data sent to wireless device 100. [0021], software 132 and/or data used by the processors and controllers within digital module 120. Memory 130 may be implemented with static random access memory (SRAM) or other types of memory. [0043], Verify function 370 may extract signature SR and public key X′ from certificate CR, verify signature SR with public root key R′, and provide public key X′ if signature SR is verified; [0043], Verify function 370 may extract signature SR and public key X′ from certificate CR, verify signature SR with public root key R′, and provide public key X′ if signature SR is verified [0055], key derivation function 522 may generate the working key for device 550 based on hardware secret key 542 and at least one security parameter 544 of device 550. );
applying a new cryptographic operation to the one or plurality of protected data items stored in the first portion of the memory(Ashkenazi, [0055], A crypto engine 570 may receive the encrypted data from secure server 510 and may decrypt the encrypted data with the working key to obtain decrypted data. );
and retrieving the one or plurality of first data items(Ashkenazi, [0055], encrypted data from secure server 510 and may decrypt the encrypted data with the working key to obtain decrypted data.).
Regarding Claim 13:
The method according to claim 12, Ashkenazi and Miller in view of Braams disclose wherein retrieving the one or plurality of first data items is performed via a software platform of the electronic device(Ashkenazi, [0021], Modem processor 122 may perform processing for data transmission and reception, e.g., encoding, modulation, demodulation, decoding, etc. CPU/RISC processor 124 may perform general-purpose processing for wireless device 100, e.g., processing for audio, video, graphics, and/or other applications. Main controller 126 may direct the operation of various units within digital module 12. [0023], Memory controller 148 may facilitate transfer of data between an external memory 150 and digital module 120. External memory 150 may provide mass/bulk storage for the processing units).
Regarding Claim 14:
Ashkenazi discloses:
An electronic device, configured to receive a software module from a first application, the electronic device comprising: a cryptographic circuit configured to: generate an encryption key based on one of: the public key or an identification value derived from the public key(Ashkenazi, [0035], a public key used to authenticate software authorized for execution on wireless device 100. The software may be signed based on a private key; [0005], working key based on a hardware secret key as well as at least one security parameter of the device. [0007], the at least one security parameter may include a public key);
generate one or a plurality of protected data items by applying a cryptographic operation to one or a plurality of first data items associated with the first application based on the encryption key(Ashkenazi, Abstract, the working key may be used to encrypt, sign, decrypt, or verify data for the device.);
Ashkenazi does not disclose:
and a memory configured to store the one or the plurality of protected data items
Miller discloses:
and a memory configured to store the one or the plurality of protected data items(Miller, [0048], The encrypted data of storage device 150N is represented by encrypted data 170N. The key, along with another value specific to the storage device, may be conveyed from each storage device 150 to key encryption unit 130.).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Ashkenazi’s generation of working security key based on security parameters by enhancing Ashkenazi’s systems for storing protected data items resulting from cryptographic operations in a defined portion of memory to ensure organized and secure placement of encrypted data within device storage as taught by Miller in order to enhance data protection and structured memory management within the electronic device. The motivation is to ensure that encrypted or protected data is stored in a specific memory region to improve security, data isolation, and efficient retrieval.
Ashkenazi in view of Miller does not disclose:
the software module comprising a public key associated with signature values for an entity that designed and supplied the software module
Braams disclose:
the software module comprising a public key associated with signature values for an entity that designed and supplied the software module(Braams, [0015], The host is used to obtain and store a software module for an electronic device, including a payload (which may comprise the actual program code, a firmware image)… the signature over the payload… the signature over the software module should be generated by the entity whose public key is pre-loaded in the electronic device…[0020], The host may also advantageously verify the signature provided in the software module… The public key may be found in one of the certificates, if certificates are present in the software module…[0006], Such signature must be generated with the software provider's private key, and can be verified with the software provider's corresponding public key, which should be provided and certified to the electronic device, or pre-loaded in the electronic device.)
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Ashkenazi in view of Miller’s generation of working security key based on security parameters by enhancing Ashkenazi’ in view of Miller’s systems to associate the public key included with the software module with signature values generated by the software provider as taught by Braams in order to enhance verification of the origin and authenticity of the software module The motivation is to ensure that the received software module originates from an authorized software provider and has not been improperly modified prior to use by the electronic device.
Regarding Claim 15:
The electronic device according to claim 14, Ashkenazi and Miller in view of Braams disclose further comprising a software platform configured to control the access to the memory(Ashkenazi, [0021], Main controller 126 may direct the operation of various units within digital module 120. Internal memory 130 may store software 132 and/or data used by the processors and controllers [0023], Memory controller 148 may facilitate transfer of data between an external memory 150 and digital module 120, [0046], wireless device 100 may perform secure boot to authenticate software loaded onto wireless device 100 prior to execution of the software).
Regarding Claim 16:
The electronic device according to claim 14, Ashkenazi and Miller in view of Braams disclose wherein the cryptographic operation comprises an encryption, by using the encryption key, of the one or plurality of first data items(Ashkenazi, [0006], the working key may be used to encrypt, sign, decrypt, or verify data for the device. The working key may be used directly or indirectly by the software for the at least one security function.).
Regarding Claim 17:
The electronic device according to claim 14, Ashkenazi and Miller in view of Braams disclose wherein the cryptographic operation comprises a calculation of one or a plurality of first signature values associated with the one or plurality of first data items by using the encryption key, the one or plurality of protected data items comprising the one or plurality of first signature values(Ashkenazi, [0006], the working key may be used to encrypt, sign, decrypt, or verify data for the device. The working key may be used directly or indirectly by the software for the at least one security function.).
Regarding Claim 18:
The electronic device according to claim 14, Ashkenazi and Miller in view of Braams disclose wherein the secret key of the electronic device is one of: a hardware unique key or a key derived from a hardware unique key(Ashkenazi, [0026], a hardware (HW) secret key on wireless device 100 (step 1). The key provisioning entity may be an integrated circuit (IC) chip manufacture of an IC chip (e.g., an ASIC) used in wireless device 100 (as shown in FIG. 2) or some other entity. The hardware secret key may be stored in secure memory 140 on wireless device 100. [0051], generating a working key based on a hardware secret key as well as at least one security parameter, which may be related to software authorized for the device. [0055], 0, key derivation function 522 may generate the working key for device 550 based on hardware secret key 542 and at least one security parameter 544 of device 550.).
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 MAYASA SHAAWAT whose telephone number is (571)272-3939. The examiner can normally be reached on M-F, 8 AM TO 5 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, JEFFREY PWU can be reached on (571)272-6789. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAYASA SHAAWAT/
Examiner, Art Unit 2433
/JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433
Prosecution Insights