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 Amendment
2. This is in response to the amendments filed on 04/01/2026. Claims 1-34 are currently pending and have been considered below.
Response to Arguments
3. Applicant’s arguments filed on 04/01/2026 have been fully considered but they are not persuasive. On the Remarks, Applicant argues that;
Zeh in view of Nitschke fails to teach “generating, with the second private key, a timestamp for the digital signature”.
Zeh in view of Nitschke fails to teach "deleting the first private key of the first cryptographic key pair from the device; and storing the second public and private keys on the device after the first private key of the first cryptographic key pair is deleted from the device."
There is no motivation to combine Arora with Zeh and/or Nitschke.
The examiner respectfully disagrees.
First, in response to applicant's argument that Zeh in view of Nitschke fails to teach “generating, with the second private key, a timestamp for the digital signature”. It is noted that, Zeh at Para.0064 discloses, “…. device-specific key pair {SK-A, PK-A} …. generates a signature …. obtains a certificate”, which the examiner interpreted as being the claimed “…. generating, with the second private key…... the digital signature…”. Also, NITSCHKE at Para.0003 and Para.0035 discloses “an electronic certificate is digitally signed by an …certification authority…. digitally signed with the private part of an asymmetric key pair of the certification authority”, “generate a digitally signed timestamp which associates the device certificate …. the point in time at which the timestamp is generated…. with the current time indication, for example in the form of date and time, is digitally signed using a …. key”, which the examiner interpreted as being the claimed “…. generating, with the …. private key, a timestamp for the digital signature…”. Thus, it is clearly indicated that Zeh in view of Nitschke teach “generating, with the second private key, a timestamp for the digital signature”.
Second, in response to applicant's argument that Zeh in view of Nitschke fails to teach "deleting the first private key of the first cryptographic key pair from the device; and storing the second public and private keys on the device after the first private key of the first cryptographic key pair is deleted from the device. It is noted that, Zeh at Para.0065, Para.0005 discloses; “MCU …. stores its …. device-specific key pair {SK-A, PK-A….”,” microcontroller unit (MCU) within ….. a communication endpoint”, which the examiner interpreted as being the claimed “…. storing the second public and private keys on the device”, as the claimed “second public and private keys” are equivalent to [key pair {SK-A, PK-A}] of Zeh. Also, Zeh at Para.0042 discloses; “{SK, PK} represents a key pair consisting of a secret key SK and a public key PK”, which the examiner interpreted as being the claimed “…..the first private key of the first cryptographic key pair….”, …” because the claimed “first private key” is equivalent to SK of Zeh.
Moreover, it is noted that, Arora at Para.0034 discloses; “a first ….. key of a first key pair and the corresponding ….public key…. the first …. key is deleted from the memory …. in the …. computing device”, which the examiner interpreted as being the claimed “…. deleting the first…. key of the first …. key pair from the device…”. In addition, Arora at Para.0034, Para.0007 and Para.0023 discloses; “The memory …. store a second …. key …. which may replace the first …. key …. such that the first …. key is deleted from the memory …. in the …. computing device”, “to replace the first … key with the second …. key, wherein replacement of the first ….key includes deletion of the first …. key from the computing device”, “Prior to …. the blockchain transaction …. computing device … generate a ….key pair that is comprised of a …private key and a … corresponding public key, …”, which the examiner interpreted as being the claimed “storing the second …. keys on the device after the first …. key of the first …. key pair is deleted from the device”, because the broadest reasonable interpretation of the claimed “storing the second …. keys on the device after the first …. key of the first …. key pair is deleted from the device” includes replacement of the first key with the second key from the computing device following usage of the first key which is equivalent to the claimed ‘after the first key is deleted from the memory of the device, the second keys are stored in the computing device’.
Finally, in response to applicant's argument that there is no motivation to combine Arora with Zeh and/or Nitschke. It is noted that, Zeh discloses “first private key of the first cryptographic key pair….” and “…. storing the second public and private keys on the device”. NITSCHKE discloses “…. generating, with the …. private key, a timestamp for the digital signature…”. Arora discloses “…. deleting the first…. key of the first …. key pair from the device” and “storing the second …. keys on the device after the first …. key of the first …. key pair is deleted from the device”, (disclosed above). Thus, it is indicated that a proper primafacie case of obviousness has been established by combining the references of Zeh, NITSCHKE, and Arora.
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.
4. Claims 1-3, 16-21,24-28,31 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Zeh et al (US 20210075606 A1) in view of NITSCHKE et al (US 20170054566 A1) and further in view of Arora et al (US 20180276663 A1)
Regarding Claim 1:
Zeh discloses:
a. A method (Para.0052; “methods for deploying key material….”) comprising:
storing a first private key and a first public key of a first cryptographic key pair on a device; (Para.0064, Para.0042, Para.0056; “…. stores a key pair {SK, PK} … to the TPM 3 for secured storage”, “{SK, PK} represents a key pair consisting of a secret key SK and a public key PK”, “TPM 3, being a …. hardware device… may be a secure server….” SK is construed as first private key and PK is construed as first public key)
b. digitally signing, with the first private key of the first cryptographic key pair, (Para. 0047; “…. signed by secret key SK of key pair {SK, PK}”) a second cryptographic key pair of second public and private keys (Para.0064, Para.0058; “…. device-specific key pair {SK-A, PK-A} …. generates a signature …. obtains a certificate” Certificate is obtained from the signature, signature is generated through key pair [SK-A, PK-A], certificate is signed by secret key SK/first private key, “…. generates …. key pair {SK-A, PK-A}, where SK-A is a “use-only” secret key ….” [SK-A, PK-A] are construed as second cryptographic key pair of second public and private keys) node-locked to the device; (Para.0064, Para.0053; “device-specific key pair {SK-A, PK-A}”, “use-only” …. secret keys…. cannot be …. viewed or inspected…. device-specific key (pair) …. corresponds to a certain hardware …. injected during production…..” device-specific key pair {SK-A, PK-A} are for a specific device or node, construed as node-locked to the device)
…. generating, with the second private key…... the digital signature… (Para.0064; “…. device-specific key pair {SK-A, PK-A} …. generates a signature …. obtains a certificate”)
c. …. the first private key of the first cryptographic key pair from the device; (disclosed above) and
…. storing the second public and private keys on the device (Para.0065, Para.0005; “MCU …. stores its …. device-specific key pair {SK-A, PK-A….”,” microcontroller unit (MCU) within ….. a communication endpoint”) …. the first private key of the first cryptographic key pair…..(disclosed above)
d. wherein the second private key is to later …. node-lock the license to the device. (Para.0065, “a device-specific key ….SK-A…. considered to be “bound” to the MCU …” bound to an MCU/ specific device indicates that at a later time no other device can use the certificate) …...
however, Zeh does not explicitly disclose:
b. …. generating, with the …… private key, a timestamp for the digital signature…
c. …. deleting the first…. key of the first ….. key pair from the device; and
storing the second …. keys on the device after the first …. key of the first …. key pair is deleted from the device,
d. … wherein the ….. private key is to later time-restrict a license and node-lock the license to the device, using the timestamp of the digital signature. [Zeh discloses second private key is to later …. node-lock the license to the device but Zeh does not disclose the ….. private key is to later time-restrict a license and node-lock the license to the device, using the timestamp of the digital signature]
In an analogous reference NITSCHKE discloses:
b. …. generating, with the …. private key, (Para.0003; “an electronic certificate is digitally signed by an …certification authority…. digitally signed with the private part of an asymmetric key pair of the certification authority” private part of an asymmetric key pair is construed as the private key) a timestamp for the digital signature… (Para.0035; “generate a digitally signed timestamp which associates the device certificate …. the point in time at which the timestamp is generated…. digitally signed timestamp is …. generated …. with the current time indication, for example in the form of date and time, is digitally signed using a …. key”)
d. … wherein the … private key is to later time-restrict a license (Para.0179, Para.0063; “a device certificate will be …. valid until its validity period …. or the validity period of the corresponding timestamp has expired”, “a ….key used …. for signing device certificates” device certificate or digitally signed [with the private part of an asymmetric key pair] timestamp associated with the device certificate will be valid until its validity period of the corresponding timestamp has expired, which is construe as the private key is to later time-restrict a license using the timestamp of the digital signature) and node-lock the license to the device, using the timestamp of the digital signature. (Para.0179, Para.0047; “the timestamp associated with the device certificate is checked for validity according to …. its binding to the device certificate is verified”, “…. the validity period of the …. Certificate…..whether a binding of the device certificate to the device exists” private key is used for signing device certificates and the timestamp associated with the device certificate is checked for validity, thus the validity of the device certificate to a specific device is construed as node-lock the license to the device, using the timestamp of the digital signature)
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Zeh’s method for deploying key material (e.g., secret and/or public keys) for cryptographic functions by enhancing Zeh’s method to include NITSCHKE’s method for creating device certificates and checking the validity of device certificates.
The motivation: By using cryptographic methods, authenticity and integrity check of electronic certificates for confirming the identity of a device is important, as providing a digitally signed piece of status information for the device certificate, exhibits the proof that the device certificate was created by an authorized entity.
however, Zeh in view of NITSCHKE does not explicitly disclose:
c. …. deleting the first…. key of the first ….. key pair from the device; and
storing the second …. keys on the device after the first …. key of the first …. key pair is deleted from the device,
In an analogous reference Arora discloses:
c. …. deleting the first…. key of the first …. key pair from the device; and (Para.0034; “a first ….. key of a first key pair and the corresponding ….public key…. the first …. key is deleted from the memory …. in the …. computing device”) and
storing the second …. keys on the device after the first …. key of the first …. key pair is deleted from the device, (Para.0034, Para.0007 and Para.0023; “The memory …. store a second …. key …. which may replace the first …. key …. such that the first …. key is deleted from the memory …. in the …. computing device”, “to replace the first … key with the second …. key, wherein replacement of the first ….key includes deletion of the first …. key from the computing device”, “Prior to …. the blockchain transaction …. computing device … generate a ….key pair that is comprised of a …private key and a … corresponding public key, …” replacement of the first key with the second key from the computing device following usage of the first key is construed as after the first key is deleted from the memory of the device, the second keys are stored in the computing 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 Zeh in view of NITSCHKE’s method for deploying key material (e.g., secret and/or public keys) for cryptographic functions by enhancing Zeh in view of NITSCHKE’s method to include Arora’s method for Offline Transmission.
The motivation: Replacing a provider's private key/ first key with a customer's private key/ second key would primarily benefit security by giving the customer complete control over their data encryption, ensuring that only they can decrypt sensitive information, thus significantly reducing the risk of unauthorized access by the provider or any third party, effectively implementing "end-to-end encryption" where the provider cannot see the plain text data.
With respect to independent claims 18 and 26, a corresponding reasoning was given earlier in this section with respect to claim 1; therefore, claims 18 and 26 rejected, for similar reasons, under the grounds as set forth for claim 1.
Regarding Claim 2:
Zeh in view of NITSCHKE also in view of Arora discloses:
e. The method of claim 1, wherein the license is node-locked to the device …. at which the license is digitally signed by the second private key, (Zeh, Para.0064, Para.0050, Para.0053; “…. device-specific key ….SK-A…. generates a signature …. obtains a certificate”, “device-specific…. signature R generated using SK-A”, “…. device-specific key (pair) …. corresponds to a certain hardware ….” device-specific signature R is used to generate a certificate/license using SK-A/second private key, when the license is generated/signed, the device is node locked as the private key SK-A is device specific)
… the license is …. time-restricted to a time at which the license is digitally signed by the …. private key, (NITSCHKE, Para.0035; “generate a digitally signed timestamp which associates the device certificate …. the point in time at which the timestamp is generated…. digitally signed timestamp is …. generated …. with the current time indication, for example in the form of date and time, is digitally signed using a …. key”)
the …. private key deleted upon digital signature of the license, (NITSCHKE, Para.0218, Para.0003; “As soon as …. keys for generating device certificates is detected …. the associated …. certificates are permanently revoked”, “an electronic certificate is digitally signed …. the digital signature forms part of the certificate…. with the private part of an asymmetric key ….”)
and wherein the license is:
node-locked to the device due to the second private key being node-locked to the device, (Zeh, Para.0065; “a device-specific key pair {SK-A, PK-A}, signature …. and certificate …. considered to be “bound” to the MCU ….”) and
authenticable against the second public key stored on the device
(Zeh, Para.0053; “authenticate the keys….by determining that the microcontroller is a genuine ….by verifying that its corresponding device-specific key (pair), which corresponds to a certain hardware ….”) and the second public key is authenticable against the first public key stored on the device. (Zeh, Para.0048, Para.0047; “certificate verifying algorithm …. performed using public key PK …. either accepts or rejects the authenticity of the public key PK-A”, “certificate …. of public key PK-A signed by … PK”)
With respect to dependent claims 19, 20 and 27, a corresponding reasoning was given earlier in this section with respect to claim 2; therefore, claims 19, 20 and 27 rejected, for similar reasons, under the grounds as set forth for claim 2.
Regarding Claim 3:
Zeh in view of NITSCHKE also in view of Arora discloses:
f. The method of claim 1, further comprising: storing software governed by the license stored on the device. (NITSCHKE, Para.0177, Para.0106; “the device owner …. uses a software tool …. The software tool may … be provided by the device manufacturer”, “the software tool … installed in a …computer …. prompts the device”)
With respect to dependent claims 21 and 28, a corresponding reasoning was given earlier in this section with respect to claim 3; therefore, claims 21 and 28 rejected, for similar reasons, under the grounds as set forth for claim 3.
Regarding Claim 16:
Zeh in view of NITSCHKE also in view of Arora discloses:
The method of claim 1, further comprising:
storing the license digitally signed using the private key. (NITSCHKE, Abstract, Para.0003; “key is used for …. signing the device certificate…. a device certificate is stored in a memory of the device”, “an electronic certificate is digitally signed …. the digital signature forms part of the certificate…. with the private part of an asymmetric key ….”)
With respect to dependent claim 24, a corresponding reasoning was given earlier in this section with respect to claim 16; therefore, claims 24 rejected, for similar reasons, under the grounds as set forth for claim 16.
Regarding Claim 17:
Zeh in view of NITSCHKE also in view of Arora discloses:
The method of claim 16, further comprising:
…. second private key …. (Zeh, disclosed in claim 1)
deleting the …. private key from the device after the license is digitally signed using the … private key. (NITSCHKE, Para.0218, Para.0003; “As soon as …. keys for generating device certificates is detected …. the associated …. certificates are permanently revoked”, “an electronic certificate is digitally signed …. the digital signature forms part of the certificate…. with the private part of an asymmetric key ….”)
With respect to dependent claim 25, a corresponding reasoning was given earlier in this section with respect to claim 17; therefore, claim 25 rejected, for similar reasons, under the grounds as set forth for claim 17.
Regarding Claim 31:
Zeh in view of NITSCHKE also in view of Arora discloses:
The device of claim 26, wherein the device is a portable storage device. (Zeh, Para.0057; “An entity may be a communication endpoint …..for example, …. a mobile consumer device”)
Claims 4, 22, 23, 29 and 30,32-34 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Zeh et al (US 20210075606 A1) in view of NITSCHKE et al (US 20170054566 A1) also in view of Arora et al (US 20180276663 A1) and further in view of Nix et al (US 20210211279 A1)
Regarding Claim 4:
Zeh in view of NITSCHKE also in view of Arora discloses:
g. The method of claim 3, …. digitally signing the second cryptographic key pair occurs …. (Zeh, Para.0064, Para.0047; “…. device-specific key pair {SK-A, PK-A} …. generates a signature ….”, “…. signed by secret key SK of key pair {SK, PK}”)
however, Zeh in view of NITSCHKE also in view of Arora does not explicitly disclose:
…. the software comprises a standalone operating system executable from the device,
and wherein digitally signing the …. cryptographic key pair occurs at first boot of and during execution of the operating system from the device.
In an analogous reference Nix discloses:
…. the software comprises a standalone operating system executable from the device, (Nix, Para.0061, Para.0043; “software installed on device”, “a mobile handset …. comprise …. operating systems”)
and wherein digitally signing the …. cryptographic key pair occurs at first boot of (Nix, Para.0017, Para.0018, Para.0013; “…the signature using … key in a certificate”, “The device …receive … certificate …. as well as the configuration files …. associated …private key …. public key for the device… completing configuration step …”, “transition from a manufactured state …. to an operational state, …. comprise a configuration step” in configuration step, after the device is manufactured, the device receives certificate with signed key pairs) and during execution of the operating system from the device. (Nix, Para.0061, Para.0014; “software installed on device …. upon manufacturing… configuration files …. contains the originally installed versions of these files in device”, “The configuration data …. include … “configuration app” for the …. operating system”)
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Zeh in view of NITSCHKE also in view of Arora’s method for deploying key material (e.g., secret and/or public keys) for cryptographic functions by enhancing Zeh in view of NITSCHKE also in view of Arora’s method to include Nix’s method for securely configuring a secure processing environment within a transducer device.
The motivation: a mobile handset can communicate with the network by using configuration data for the device. configuration files/data for device contains the originally installed versions of these files. The configuration data can also include a certificate and authentication parameters, which helps to authenticate any device.
With respect to dependent claims 22, 23, 29 and 30, a corresponding reasoning was given earlier in this section with respect to claim 4; therefore, claims 22, 23, 29 and 30 rejected, for similar reasons, under the grounds as set forth for claim 4.
Regarding Claim 32:
Zeh in view of NITSCHKE also in view of Arora and further in view of Nix discloses:
The method of claim 4, wherein the first boot is performed at a manufacturing facility. (Nix, Para.0061, Para.0049, Para.0203, Para.0012; “configuration…..comprises the …. software installed on device …. upon manufacturing….. configuration files ….. contains the originally installed versions of these files in device”, “Device identity ….. recorded …..by device manufacturer ….upon device manufacturing”, “device identity ….could be …. inside a certificate”, “the manufacturer records a certificate for the device …..”)
Regarding Claim 33:
Zeh in view of NITSCHKE also in view of Arora discloses:
The method of claim 17, wherein …..the second private key….(Zeh, disclosed in claim 1)
…..the deleting of the …..private key from the device occurs after a …..boot. (Arora, Para.0034, Para.0007, Abstract; “a …..private key ….. is deleted from the memory …. in the …. computing device”, “the …… private key includes deletion of the …. private key from the computing device”, “executing a query to replace the ….. private key ….. wherein replacement of the …. private key includes deletion of the …….private key from the computing device”)
however, Zeh in view of NITSCHKE also in view of Arora does not explicitly disclose:
the ….. key ….. after a second boot.
In an analogous reference Nix discloses:
the ….. key ….. after a second boot. (Nix, Para.0218, Para.0018; “device ….. perform a reboot, so that ……restart with the new files from software package”, “The device can …. reboot, using …..software package….. and conduct a key exchange with a …. system”)
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Zeh in view of NITSCHKE also in view of Arora’s method for deploying key material (e.g., secret and/or public keys) for cryptographic functions by enhancing Zeh in view of NITSCHKE also in view of Arora’s method to include Nix’s method for securely configuring a secure processing environment within a transducer device.
The motivation: is the same as claim 4.
Regarding Claim 34:
Zeh in view of NITSCHKE also in view of Arora and further in view of Nix discloses:
The method of claim 33, wherein the second boot is performed by a user. (Nix, Para.0218, Para.0040; “device 101 …. perform a reboot”, “device 101 can include a …..user”)
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 SAYEDA SALMA NAHAR whose telephone number is (703)756-4609. The examiner can normally be reached M-F 12:00 PM to 6:00 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Amir Mehrmanesh can be reached on (571) 270-3351. 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.
/SAYEDA SALMA NAHAR/Examiner, Art Unit 2435
/BEEMNET W DADA/Primary Examiner, Art Unit 2435
Prosecution Insights