DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 01/14/2026. Claims 1, 5-7, 9, 11, and 15 are amended. Claims 4, and 12 are cancelled. Claims 1-3, 5-11, and 13-19 are pending in this examination.
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 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. This examination is in response to US Patent Application No. 18/277,277.
Examiner Note
Applicant’s amendment to claim 7 obviates previously raised claim 7 claim objections.
Applicant’s amendment to claims 2, 4, 7-8, 12-14, and 16-17 obviates previously raised claim rejection 35USC112(b) , second paragraph rejection.
Applicant is encouraged to schedule an interview with the examiner prior to the next communication to compact prosecution of the case.
Response to Arguments
Applicant stated on page 8 of remark filed on 01/14/2026 that Provided herewith are three (3) Replacement Drawing Sheets in which FIGS. 1- 4 are reproduced with enhanced line and image quality. The drawings satisfy all U.S. requirements; withdrawal of the objection is requested.
However, examiner did not locate these replacement drawing, hence maintains the drawing objection.
Applicant's arguments filed 01/14/2026 have been fully considered but they are not persuasive:
Applicant submits on pages 9-11 of remarks filed on 01/14/2026 regarding claim 1 that the reference at least fails to provide a list of security mechanisms and reader acceptance, as recited in amended claim 1. Claim 1, as amended, expressly requires that "the key exchange phase comprises ... receiving a list of security mechanisms proposed by the controller ... and emitting ... a security mechanism accepted by the reader, said security mechanism being chosen from among the list of security mechanisms."
Examiner respectfully disagrees with applicant argument for claim 1 filed on 01/14/2026 on pages 9-11 of remarks for the first and second set of rejection.
Altin discloses :
[¶108, As illustrated in FIG. 11, in one embodiment, the secure key storage on each IoT device 101 is implemented using a programmable subscriber identity module (SIM) 1101. In this embodiment, the IoT device 101 may initially be provided to the end user with an un-programmed SIM card 1101 seated within a SIM interface 1100 on the IoT device 101. In order to program the SIM with a set of one or more encryption keys, the user takes the programmable SIM card 1101 out of the SIM interface 500 and inserts it into a SIM programming interface 1102 on the IoT hub 110. Programming logic 1125 on the IoT hub then securely programs the SIM card 1101 to register/pair the IoT device 101 with the IoT hub 110 and IoT service 120. In one embodiment, a public/private key pair may be randomly generated by the programming logic 1125 and the public key of the pair may then be stored in the IoT hub's secure storage device 411 while the private key may be stored within the programmable SIM 1101. In addition, the programming logic 525 may store the public keys of the IoT hub 110, the IoT service 120, and/or any other IoT devices 101 on the SIM card 1401 (to be used by the security logic 1302 on the IoT device 101 to encrypt outgoing data). Once the SIM 1101 is programmed, the new IoT device 101 may be provisioned with the IoT Service 120 using the SIM as a secure identifier (e.g., using existing techniques for registering a device using a SIM). Following provisioning, both the IoT hub 110 and the IoT service 120 will securely store a copy of the IoT device's public key to be used when encrypting communication with the IoT device 101], and [¶135, In one embodiment, the IoT service 120 transmits its session public key generated using the HSM 1630 to the IoT device 101 at 1701. The IoT device uses its HSM 1631 to generate its own session public/private key pair and, at 1702, transmits its public key of the pair to the IoT service 120. In one embodiment, the encryption engines 1660-1661 use an Elliptic curve Diffie-Hellman (ECDH) protocol, which is an anonymous key agreement that allows two parties with an elliptic curve public-private key pair, to establish a shared secret. In one embodiment, using these techniques, at 1703, the encryption engine 1660 of the IoT service 120 generates the secret using the IoT device session public key and its own session private key. Similarly, at 1704, the encryption engine 1661 of the IoT device 101 independently generates the same secret using the IoT service 120 session public key and its own session private key. More specifically, in one embodiment, the encryption engine 1660 on the IoT service 120 generates the secret according to the formula secret=IoT device session pub key*IoT service session private key, where “*” means that the IoT device session public key is point-multiplied by the IoT service session private key. The encryption engine 1661 on the IoT device 101 generates the secret according to the formula secret=IoT service session pub key*IoT device session private key, where the IoT service session public key is point multiplied by the IoT device session private key. In the end, the IoT service 120 and IoT device 101 have both generated the same secret to be used to encrypt communication as described below. In one embodiment, the encryption engines 1660-1661 rely on a hardware module such as the KSGMs 1640-1641 respectively to perform the above operations for generating the secret ], and ¶158, In one embodiment, the message is sent to the IoT device on the negotiation channel (described below). The IoT device parses the message and: [0159] 1. Verifies the signature of the factory certificate (only if present in the message payload) [0160] 2. Verifies the signature of the unique ID using the key identified by the unique ID [0161] 3. Verifies the IoT service session public key signature using the IoT service's public key from the unique ID [0162] 4. Saves the IoT service's public key as well as the IoT service's session public key [0163] 5. Generates the IoT device session key pair. [0164] C. The IoT device then generates a message containing the following: [0165] 1. IoT device's unique ID [0166] IoT device serial number [0167] Timestamp [0168] ID of factory key used to sign this unique ID [0169] Class of unique ID (i.e., IoT device) [0170] IoT device's public key [0171] Signature of unique ID [0172] 2. IoT device's session public key [0173] 3. Signature of (IoT device session public key+IoT service session public key) signed with IoT device's key], and [¶213, At 2301, the IoT Service creates a packet containing serial number and public key of the IoT Service. At 2302, the IoT Service signs the packet using the factory private key. At 2303, the IoT Service sends the packet over an encrypted channel to the IoT hub and at 2304 the IoT hub forwards the packet to IoT device over an unencrypted channel. At 2305, the IoT device verifies the signature of packet and, at 2306, the IoT device generates a packet containing the serial number and public key of the IoT Device. At 2307, the IoT device signs the packet using the factory private key and at 2308, the IoT device sends the packet over the unencrypted channel to the IoT hub].
Bender discloses :
3.1 Protocol Description, Figure 1 illustrates the PACE/AA protocol with both options of authentication at the end. The scheme itself uses a block cipher C(K_; _) : f0; 1g` ! f0; 1g` and a hash function H, with values 1; 2… in fixed-length encoding prepended to make evaluations somewhat independent. The chip already holds a certicate certC ( contains serial number) for its public key XA under the authorities' public key pkCA, and (authenticated) group parameters G = (a; b; p; q; g; k) describing a subgroup of order q, generated by g, of an elliptic curve for parameters a; b; p for security parameter k. We also note that, throughout the paper, we use the multiplicative notation for group operations. It is understood that, if working with elliptic curves, multiplications correspond to additions and exponentiations to multiplications. Then the parties run the PACE protocol, with the chip sending a nonce encrypted under the password, running the Diffie-Hellman based Map2Point protocol to derive another generator ^g on which another Diffie-Hellman key exchange is then performed. In this Map2Point step the chip uses some secret exponent yA to send YA = gyA. The parties in the There are essentially two possible instantiations. One is based on the Schnorr signature scheme [Sch90] where the chip uses the values yA and YA as the (private resp. public) randomness and TB as the challenge for creating the signature under its long-term signature key XA. We call this option Active Authentication via Schnorr signatures. Alternatively, the chip card might prove its authenticity by providing a DSA signature where again yA and YA are used as the randomness for the signature generation [Kra95]. This version is called Active Authentication via DSA signatures. We note that the computation of the final signatures requires only modular multiplications (and, in case of DSA, an inversion) instead of exponentiations.
[ see section 4], and [see page 12, section 5. Security Analysis of PACE/AA. In this section, we discuss the security of the PACE/AA protocol when active authentication is done via Schnorr signatures; the case of DSA signatures follows, too, because we do not use any specific properties of the underlying signature scheme (except for the robust unforgeability). That is, we assume that the chip, holding public key XA = gxA with certificate certC, signs the message YB with key xA and randomness YA. The signature is given by _ = yA + cxA mod q for c = H(5jjYA; TB). After the final authentication step of PACE, the chip sends (using already a secure channel) the values _ and certC to the reader who verifies the signatures and the certificate (and aborts in case one of the verifications fails).
Drawings
New corrected drawings in compliance with 37 CFR 1.121(d) are required in this application because [the drawing filed on 08/15/2023 does not describe what the item numbers are in the FIG 1 -FIG 2]. Applicant is advised to employ the services of a competent patent draftsperson outside the Office, as the U.S. Patent and Trademark Office no longer prepares new drawings. The corrected drawings are required in reply to the Office action to avoid abandonment of the application. The requirement for corrected drawings will not be held in abeyance.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Frist Set of Rejection:
Claims 1-3, 5-11, and 13-19 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Altin (US2018/0146367).
Regarding claims 1, Altin discloses A method for secure exchanges between a reader and a controller configured to communicate with each other via a communication channel, the method comprising the following phases implemented by the reader [¶97, FIG. 10 illustrates a high level architecture which uses public key infrastructure (PKI) techniques and/or symmetric key exchange/encryption techniques to encrypt communications between the IoT Service 120, the IoT hub 110 and the IoT devices 101-102]; and
a phase of reading at least one information by the reader [¶36, One embodiment of the invention comprises an Internet of Things (IoT) platform which may be utilized by developers to design and build new IoT devices and applications. In particular, one embodiment includes a base hardware/software platform for IoT devices including a predefined networking protocol stack and an IoT hub through which the IoT devices are coupled to the Internet. In addition, one embodiment includes an IoT service through which the IoT hubs and connected IoT devices may be accessed and managed], and [¶107] the invention may be implemented using various different encryption techniques. For example, while some embodiments discussed above use asymmetric public/private key pairs, an alternate embodiment may use symmetric keys securely exchanged between the various IoT devices 101-102, IoT hubs 110, and the IoT service 120. Moreover, in some embodiments, the data/command itself is not encrypted, but a key is used to generate a signature over the data/command (or other data structure). The recipient may then use its key to validate the signature], and [¶108, As illustrated in FIG. 11, in one embodiment, the secure key storage on each IoT device 101 is implemented using a programmable subscriber identity module (SIM) 1101. In this embodiment, the IoT device 101 may initially be provided to the end user with an un-programmed SIM card 1101 seated within a SIM interface 1100 on the IoT device 101. In order to program the SIM with a set of one or more encryption keys, the user takes the programmable SIM card 1101 out of the SIM interface 500 and inserts it into a SIM programming interface 1102 on the IoT hub 110. Programming logic 1125 on the IoT hub then securely programs the SIM card 1101 to register/pair the IoT device 101 with the IoT hub 110 and IoT service 120. In one embodiment, a public/private key pair may be randomly generated by the programming logic 1125 and the public key of the pair may then be stored in the IoT hub's secure storage device 411 while the private key may be stored within the programmable SIM 1101. In addition, the programming logic 525 may store the public keys of the IoT hub 110, the IoT service 120, and/or any other IoT devices 101 on the SIM card 1401 (to be used by the security logic 1302 on the IoT device 101 to encrypt outgoing data). Once the SIM 1101 is programmed, the new IoT device 101 may be provisioned with the IoT Service 120 using the SIM as a secure identifier (e.g., using existing techniques for registering a device using a SIM). Following provisioning, both the IoT hub 110 and the IoT service 120 will securely store a copy of the IoT device's public key to be used when encrypting communication with the IoT device 101]; and
a phase of exchanging a public key (BspubK) of the readepubK) of the controller [¶108, As illustrated in FIG. 11, in one embodiment, the secure key storage on each IoT device 101 is implemented using a programmable subscriber identity module (SIM) 1101. In this embodiment, the IoT device 101 may initially be provided to the end user with an un-programmed SIM card 1101 seated within a SIM interface 1100 on the IoT device 101. In order to program the SIM with a set of one or more encryption keys, the user takes the programmable SIM card 1101 out of the SIM interface 500 and inserts it into a SIM programming interface 1102 on the IoT hub 110. Programming logic 1125 on the IoT hub then securely programs the SIM card 1101 to register/pair the IoT device 101 with the IoT hub 110 and IoT service 120. In one embodiment, a public/private key pair may be randomly generated by the programming logic 1125 and the public key of the pair may then be stored in the IoT hub's secure storage device 411 while the private key may be stored within the programmable SIM 1101. In addition, the programming logic 525 may store the public keys of the IoT hub 110, the IoT service 120, and/or any other IoT devices 101 on the SIM card 1401 (to be used by the security logic 1302 on the IoT device 101 to encrypt outgoing data). Once the SIM 1101 is programmed, the new IoT device 101 may be provisioned with the IoT Service 120 using the SIM as a secure identifier (e.g., using existing techniques for registering a device using a SIM). Following provisioning, both the IoT hub 110 and the IoT service 120 will securely store a copy of the IoT device's public key to be used when encrypting communication with the IoT device 101], and [¶135, In one embodiment, the IoT service 120 transmits its session public key generated using the HSM 1630 to the IoT device 101 at 1701. The IoT device uses its HSM 1631 to generate its own session public/private key pair and, at 1702, transmits its public key of the pair to the IoT service 120. In one embodiment, the encryption engines 1660-1661 use an Elliptic curve Diffie-Hellman (ECDH) protocol, which is an anonymous key agreement that allows two parties with an elliptic curve public-private key pair, to establish a shared secret. In one embodiment, using these techniques, at 1703, the encryption engine 1660 of the IoT service 120 generates the secret using the IoT device session public key and its own session private key. Similarly, at 1704, the encryption engine 1661 of the IoT device 101 independently generates the same secret using the IoT service 120 session public key and its own session private key. More specifically, in one embodiment, the encryption engine 1660 on the IoT service 120 generates the secret according to the formula secret=IoT device session pub key*IoT service session private key, where “*” means that the IoT device session public key is point-multiplied by the IoT service session private key. The encryption engine 1661 on the IoT device 101 generates the secret according to the formula secret=IoT service session pub key*IoT device session private key, where the IoT service session public key is point multiplied by the IoT device session private key. In the end, the IoT service 120 and IoT device 101 have both generated the same secret to be used to encrypt communication as described below. In one embodiment, the encryption engines 1660-1661 rely on a hardware module such as the KSGMs 1640-1641 respectively to perform the above operations for generating the secret [; and
a phase of generating a sequence of session keys [¶102, In one embodiment, if the security module 1012 in the IoT hub is trusted, the service 120 could negotiate a session key with the hub security module 1312 and then the security module 1012 would negotiate a session key with each device 120], and [¶127] Turning first to FIG. 16A, the IoT service 120 includes an encryption engine 1660 which manages a set of “service session keys” 1650 and each IoT device 101 includes an encryption engine 1661 which manages a set of “device session keys” 1651 for encrypting/decrypting communication between the IoT device 101 and IoT service 120. The encryption engines may rely on different hardware modules when performing the security/encryption techniques described herein including a hardware security module 1630-1631 for (among other things) generating a session public/private key pair and preventing access to the private session key of the pair and a key stream generation module 1640-1641 for generating a key stream using a derived secret. In one embodiment, the service session keys 1650 and the device session keys 1651 comprise related public/private key pairs. For example, in one embodiment, the device session keys 1651 on the IoT device 101 include a public key of the IoT service 120 and a private key of the IoT device 101. As discussed in detail below, in one embodiment, to establish a secure communication session, the public/private session key pairs, 1650 and 1651, are used by each encryption engine, 1660 and 1661, respectively, to generate the same secret which is then used by the SKGMs 1640-1641 to generate a key stream to encrypt and decrypt communication between the IoT service 120 and the IoT device 101], and [¶134, In one embodiment, the encryption engine 1660 of the IoT service 120 sends a command to the HSM 1630 (e.g., which may be such as a CloudHSM offered by Amazon®) to generate a session public/private key pair. The HSM 1630 may subsequently prevent access to the private session key of the pair. Similarly, the encryption engine on the IoT device 101 may transmit a command to the HSM 1631 (e.g., such as an Atecc508 HSM from Atmel Corporation®) which generates a session public/private key pair and prevents access to the session private key of the pair]; and
a phase (104) of confirming the sequence of keys based on the use of a first session key of the sequence of session keys[¶127, Turning first to FIG. 16A, the IoT service 120 includes an encryption engine 1660 which manages a set of “service session keys” 1650 and each IoT device 101 includes an encryption engine 1661 which manages a set of “device session keys” 1651 for encrypting/decrypting communication between the IoT device 101 and IoT service 120. The encryption engines may rely on different hardware modules when performing the security/encryption techniques described herein including a hardware security module 1630-1631 for (among other things) generating a session public/private key pair and preventing access to the private session key of the pair and a key stream generation module 1640-1641 for generating a key stream using a derived secret. In one embodiment, the service session keys 1650 and the device session keys 1651 comprise related public/private key pairs. For example, in one embodiment, the device session keys 1651 on the IoT device 101 include a public key of the IoT service 120 and a private key of the IoT device 101. As discussed in detail below, in one embodiment, to establish a secure communication session, the public/private session key pairs, 1650 and 1651, are used by each encryption engine, 1660 and 1661, respectively, to generate the same secret which is then used by the SKGMs 1640-1641 to generate a key stream to encrypt and decrypt communication between the IoT service 120 and the IoT device 101], and [¶134, In one embodiment, the encryption engine 1660 of the IoT service 120 sends a command to the HSM 1630 (e.g., which may be such as a CloudHSM offered by Amazon®) to generate a session public/private key pair. The HSM 1630 may subsequently prevent access to the private session key of the pair. Similarly, the encryption engine on the IoT device 101 may transmit a command to the HSM 1631 (e.g., such as an Atecc508 HSM from Atmel Corporation®) which generates a session public/private key pair and prevents access to the session private key of the pair]; and
a protocol phase for secure communication between the reader and the controller
[¶¶101-102] Using a symmetric key implementation, each device 101 enters into a secure key exchange protocol to exchange a symmetric key with the IoT hub 110. A secure key provisioning protocol such as the Dynamic Symmetric Key Provisioning Protocol (DSKPP) may be used to exchange the keys over a secure communication channel (see, e.g., Request for Comments (RFC) 6063). However, the underlying principles of the invention are not limited to any particular key provisioning protocol. Once the symmetric keys have been exchanged, they may be used by each device 101 and the IoT hub 110 to encrypt communications. Similarly, the IoT hub 110 and IoT service 120 may perform a secure symmetric key exchange and then use the exchanged symmetric keys to encrypt communications], and [¶106, 0106] A different set of keys may be used to encrypt communication from the IoT device 101 to the IoT hub 110 and to the IoT service 120. For example, using a public/private key arrangement…], and [¶127, in one embodiment, to establish a secure communication session, the public/private session key pairs, 1650 and 1651, are used by each encryption engine, 1660 and 1661, respectively, to generate the same secret which is then used by the SKGMs 1640-1641 to generate a key stream to encrypt and decrypt communication between the IoT service 120 and the IoT device 101], and [¶195] While the above techniques are described with respect to an “IoT service” and an “IoT device,” the underlying principles of the invention may be implemented to establish a secure communication channel between any two devices including user client devices, servers, and Internet services]; and
wherein the key exchange phase comprises: a step of receiving the public key (AspubK) of the controller, and of receiving a list of security mechanisms proposed by the controller and of receiving a security parameter generated by the controller; a step of emitting to the controller, the public key (BspubK) of the reader, and a serial number of the reader, and a security mechanism accepted by the reader, said security mechanism chosen from among the list of security mechanisms, and a security parameter generated by the reader [¶108, As illustrated in FIG. 11, in one embodiment, the secure key storage on each IoT device 101 is implemented using a programmable subscriber identity module (SIM) 1101. In this embodiment, the IoT device 101 may initially be provided to the end user with an un-programmed SIM card 1101 seated within a SIM interface 1100 on the IoT device 101. In order to program the SIM with a set of one or more encryption keys, the user takes the programmable SIM card 1101 out of the SIM interface 500 and inserts it into a SIM programming interface 1102 on the IoT hub 110. Programming logic 1125 on the IoT hub then securely programs the SIM card 1101 to register/pair the IoT device 101 with the IoT hub 110 and IoT service 120. In one embodiment, a public/private key pair may be randomly generated by the programming logic 1125 and the public key of the pair may then be stored in the IoT hub's secure storage device 411 while the private key may be stored within the programmable SIM 1101. In addition, the programming logic 525 may store the public keys of the IoT hub 110, the IoT service 120, and/or any other IoT devices 101 on the SIM card 1401 (to be used by the security logic 1302 on the IoT device 101 to encrypt outgoing data). Once the SIM 1101 is programmed, the new IoT device 101 may be provisioned with the IoT Service 120 using the SIM as a secure identifier (e.g., using existing techniques for registering a device using a SIM). Following provisioning, both the IoT hub 110 and the IoT service 120 will securely store a copy of the IoT device's public key to be used when encrypting communication with the IoT device 101], and [¶135, In one embodiment, the IoT service 120 transmits its session public key generated using the HSM 1630 to the IoT device 101 at 1701. The IoT device uses its HSM 1631 to generate its own session public/private key pair and, at 1702, transmits its public key of the pair to the IoT service 120. In one embodiment, the encryption engines 1660-1661 use an Elliptic curve Diffie-Hellman (ECDH) protocol, which is an anonymous key agreement that allows two parties with an elliptic curve public-private key pair, to establish a shared secret. In one embodiment, using these techniques, at 1703, the encryption engine 1660 of the IoT service 120 generates the secret using the IoT device session public key and its own session private key. Similarly, at 1704, the encryption engine 1661 of the IoT device 101 independently generates the same secret using the IoT service 120 session public key and its own session private key. More specifically, in one embodiment, the encryption engine 1660 on the IoT service 120 generates the secret according to the formula secret=IoT device session pub key*IoT service session private key, where “*” means that the IoT device session public key is point-multiplied by the IoT service session private key. The encryption engine 1661 on the IoT device 101 generates the secret according to the formula secret=IoT service session pub key*IoT device session private key, where the IoT service session public key is point multiplied by the IoT device session private key. In the end, the IoT service 120 and IoT device 101 have both generated the same secret to be used to encrypt communication as described below. In one embodiment, the encryption engines 1660-1661 rely on a hardware module such as the KSGMs 1640-1641 respectively to perform the above operations for generating the secret ], and ¶158, In one embodiment, the message is sent to the IoT device on the negotiation channel (described below). The IoT device parses the message and: [0159] 1. Verifies the signature of the factory certificate (only if present in the message payload) [0160] 2. Verifies the signature of the unique ID using the key identified by the unique ID [0161] 3. Verifies the IoT service session public key signature using the IoT service's public key from the unique ID [0162] 4. Saves the IoT service's public key as well as the IoT service's session public key [0163] 5. Generates the IoT device session key pair. [0164] C. The IoT device then generates a message containing the following: [0165] 1. IoT device's unique ID [0166] IoT device serial number [0167] Timestamp [0168] ID of factory key used to sign this unique ID [0169] Class of unique ID (i.e., IoT device) [0170] IoT device's public key [0171] Signature of unique ID [0172] 2. IoT device's session public key [0173] 3. Signature of (IoT device session public key+IoT service session public key) signed with IoT device's key], and [¶213, At 2301, the IoT Service creates a packet containing serial number and public key of the IoT Service. At 2302, the IoT Service signs the packet using the factory private key. At 2303, the IoT Service sends the packet over an encrypted channel to the IoT hub and at 2304 the IoT hub forwards the packet to IoT device over an unencrypted channel. At 2305, the IoT device verifies the signature of packet and, at 2306, the IoT device generates a packet containing the serial number and public key of the IoT Device. At 2307, the IoT device signs the packet using the factory private key and at 2308, the IoT device sends the packet over the unencrypted channel to the IoT hub].
Regarding claim 2, Altin discloses, wherein the key exchange phase is carried out during a phase of configuring the reade[¶141, each factory which manufactures IoT devices is assigned its own factory key pair which may then be used to authenticate IoT service keys and IoT device keys. For example, in one embodiment, a factory private key is used to generate a signature over IoT service public keys and IoT device public keys. These signatures may then be verified using the corresponding factory public key. Note that these IoT service/device public keys are not the same as the “session” public/private keys described above with respect to FIGS. 16A-B. The session public/private keys described above are temporary (i.e., generated for a service/device session) while the IoT service/device key pairs are permanent (i.e., generated at the factory)], and [¶134, In one embodiment, the encryption engine 1660 of the IoT service 120 sends a command to the HSM 1630 (e.g., which may be such as a CloudHSM offered by Amazon®) to generate a session public/private key pair. The HSM 1630 may subsequently prevent access to the private session key of the pair. Similarly, the encryption engine on the IoT device 101 may transmit a command to the HSM 1631 (e.g., such as an Atecc508 HSM from Atmel Corporation®) which generates a session public/private key pair and prevents access to the session private key of the pair. Of course, the underlying principles of the invention are not limited to any specific type of encryption engine or manufacturer], and [¶158-163, In one embodiment, the message is sent to the IoT device on the negotiation channel (described below). The IoT device parses the message and: 1. Verifies the signature of the factory certificate (only if present in the message payload) 2. Verifies the signature of the unique ID using the key identified by the unique ID 3. Verifies the IoT service session public key signature using the IoT service's public key from the unique ID 4. Saves the IoT service's public key as well as the IoT service's session public key 5. Generates the IoT device session key pair].
Regarding claim 3, Altin discloses wherein the information received, respectively emitted, during the key exchange phase is encapsulated in an IP frame [¶¶108, 135]
Regarding claim 5, Altin discloses wherein the public key of the controller is received in a certificate of the controller, and wherein the public key of the reader is emitted in a certificate of the reader [¶98, Embodiments which use public/private key pairs will first be described, followed by embodiments which use symmetric key exchange/encryption techniques. In particular, in an embodiment which uses PKI, a unique public/private key pair is associated with each IoT device 101-102, each IoT hub 110 and the IoT service 120. In one embodiment, when a new IoT hub 110 is set up, its public key is provided to the IoT service 120 and when a new IoT device 101 is set up, it's public key is provided to both the IoT hub 110 and the IoT service 120. Various techniques for securely exchanging the public keys between devices are described below. In one embodiment, all public keys are signed by a master key known to all of the receiving devices (i.e., a form of certificate) so that any receiving device can verify the validity of the public keys by validating the signatures. Thus, these certificates would be exchanged rather than merely exchanging the raw public keys], and [¶¶122, 1153-154, 158, 210].
Regarding claim 6, Altin discloses the serial number of the reader is transformed or encrypted. [¶158, In one embodiment, the message is sent to the IoT device on the negotiation channel (described below). The IoT device parses the message and: [0159] 1. Verifies the signature of the factory certificate (only if present in the message payload) [0160] 2. Verifies the signature of the unique ID using the key identified by the unique ID [0161] 3. Verifies the IoT service session public key signature using the IoT service's public key from the unique ID [0162] 4. Saves the IoT service's public key as well as the IoT service's session public key [0163] 5. Generates the IoT device session key pair. [0164] C. The IoT device then generates a message containing the following: [0165] 1. IoT device's unique ID [0166] IoT device serial number [0167] Timestamp [0168] ID of factory key used to sign this unique ID [0169] Class of unique ID (i.e., IoT device) [0170] IoT device's public key [0171] Signature of unique ID [0172] 2. IoT device's session public key [0173] 3. Signature of (IoT device session public key+IoT service session public key) signed with IoT device's key], and [¶213, At 2301, the IoT Service creates a packet containing serial number and public key of the IoT Service. At 2302, the IoT Service signs the packet using the factory private key. At 2303, the IoT Service sends the packet over an encrypted channel to the IoT hub and at 2304 the IoT hub forwards the packet to IoT device over an unencrypted channel. At 2305, the IoT device verifies the signature of packet and, at 2306, the IoT device generates a packet containing the serial number and public key of the IoT Device. At 2307, the IoT device signs the packet using the factory private key and at 2308, the IoT device sends the packet over the unencrypted channel to the IoT hub].
Regarding claim 7, Altin discloses wherein the phaseK) of the readerpubK) of the controlle¶ 41, 36, 97, 102, 108, 127, 134-135, 158-171, 213].
Regarding claim 8, Altin discloses, wherein the step[¶77, In one embodiment, the IoT hub 110 and IoT service 120 communicate at periodic intervals. If the IoT service 120 detects that the connection to the IoT hub 110 has been lost (e.g., by failing to receive a request or response from the IoT hub for a specified duration), it will communicate this information to the end user's device 135 (e.g., by sending a text message or app-specific notification)], and [¶92, At 801, an IoT device which is out of range of the IoT hub periodically collects data (e.g., opening of the refrigerator door, food items used, etc). At 802 the IoT device periodically or continually checks for connectivity with a mobile device (e.g., using standard local wireless techniques for establishing a connection such as those specified by the BTLE standard). If the connection to the mobile device is established, determined at 802, then at 803, the collected data is transferred to the mobile device at 803. At 804, the mobile device transfers the data to the IoT hub, an external service and/or a user. As mentioned, the mobile device may transmit the data immediately if it is already connected (e.g., via a WiFi link)], and [¶95, At 900 new program code or data updates are made available on the IoT hub and/or an external service (e.g., coupled to the mobile device over the Internet). At 901, the mobile device receives and stores the program code or data updates on behalf of the IoT device. The IoT device and/or mobile device periodically check to determine whether a connection has been established at 902. If a connection is established, determined at 903, then at 904 the updates are transferred to the IoT device and installed], and [¶133, FIG. 17 illustrates a key exchange and key stream generation which may initially be performed between the IoT service 120 and the IoT device 101. In one embodiment, this key exchange may be performed each time the IoT service 120 and IoT device 101 establish a new communication session. Alternatively, the key exchange may be performed and the exchanged session keys may be used for a specified period of time (e.g., a day, a week, etc)], and [0140] As mentioned, in one embodiment, the session public/private key pairs 1650-1651 exchanged between the IoT service 120 and IoT device 101 may be generated periodically and/or in response to the initiation of each new communication session], and [¶143, A. In one embodiment, the IoT service 120 initially generates a message containing the following: [0144] 1. The IoT service's unique ID: [0145] The IoT service's serial number; [0146] a Timestamp; [0147] The ID of the factory key used to sign this unique ID; [0148] a Class of the unique ID (i.e., a service); [0149] IoT service's public key [0150] The signature over the unique ID. [0151] 2. The Factory Certificate including: [0152] A timestamp [0153] The ID of the master key used to sign the certificate [0154] The factory public key [0155] The signature of the Factory Certificate [0156] 3. IoT service session public key (as described above with respect to FIGS. 16A-B) [0157] 4. IoT service session public key signature (e.g., signed with the IoT service's private key], and [0164] C. The IoT device then generates a message containing the following: [0165] 1. IoT device's unique ID [0166] IoT device serial number [0167] Timestamp [0168] ID of factory key used to sign this unique ID [0169] Class of unique ID (i.e., IoT device) [0170] IoT device's public key [0171] Signature of unique ID [0172] 2. IoT device's session public key [0173] 3. Signature of (IoT device session public key+IoT service session public key) signed with IoT device's key], and [ ¶74].
Regarding claim 9 Altin discloses wherein the phase[¶103, In one embodiment, to prevent a compromise on the hub security module 1012 a one-time (permanent) installation key may be negotiated between the device 101 and service 120 at installation time. When sending a message to a device 101 the service 120 could first encrypt/MAC with this device installation key, then encrypt/MAC that with the hub's session key. The hub 110 would then verify and extract the encrypted device blob and send that to the device].
Regarding claim 10, Altin discloses: [0142, With the foregoing relationships between master keys, factory keys, service/device keys in mind, one embodiment of the invention performs the following operations to provide additional layers of authentication and security between the IoT service 120 and IoT device 101], and [0143] A. In one embodiment, the IoT service 120 initially generates a message containing the following: [0144] 1. The IoT service's unique ID: [0145] The IoT service's serial number; [0146] a Timestamp; [0147] The ID of the factory key used to sign this unique ID; [0148] a Class of the unique ID (i.e., a service); [0149] IoT service's public key [0150] The signature over the unique ID. [0151] 2. The Factory Certificate including: [0152] A timestamp [0153] The ID of the master key used to sign the certificate [0154] The factory public key [0155] The signature of the Factory Certificate [0156] 3. IoT service session public key (as described above with respect to FIGS. 16A-B) [0157] 4. IoT service session public key signature (e.g., signed with the IoT service's private key [0158] B. In one embodiment, the message is sent to the IoT device on the negotiation channel (described below). The IoT device parses the message and: [0159] 1. Verifies the signature of the factory certificate (only if present in the message payload) [0160] 2. Verifies the signature of the unique ID using the key identified by the unique ID [0161] 3. Verifies the IoT service session public key signature using the IoT service's public key from the unique ID [0162] 4. Saves the IoT service's public key as well as the IoT service's session public key [0163] 5. Generates the IoT device session key pair. [0164] C. The IoT device then generates a message containing the following: [0165] 1. IoT device's unique ID [0166] IoT device serial number [0167] Timestamp [0168] ID of factory key used to sign this unique ID [0169] Class of unique ID (i.e., IoT device) [0170] IoT device's public key [0171] Signature of unique ID [0172] 2. IoT device's session public key [0173] 3. Signature of (IoT device session public key+IoT service session public key) signed with IoT device's key. [0174] D. This message is sent back to the IoT service. The IoT service parses the message and: [0175] 1. Verifies the signature of the unique ID using the factory public key [0176] 2. Verifies the signature of the session public keys using the IoT device's public key [0177] 3. Saves the IoT device's session public key. [0178] E. The IoT service then generates a message containing a signature of (IoT device session public key+IoT service session public key) signed with the IoT service's key. [0179] F The IoT device parses the message and: [0180] 1. Verifies the signature of the session public keys using the IoT service's public key [0181] 2. Generates the key stream from the IoT device session private key and the IoT service's session public key [0182] 3. The IoT device then sends a “messaging available” message. [0183] G. The IoT service then does the following: [0184] 1. Generates the key stream from the IoT service session private key and the IoT device's session public key [0185] 2. Creates a new message on the messaging channel which contains the following: [0186] Generates and stores a random 2-byte value [0187] Set attribute message with the boomerang attribute Id (discussed below) and the random value. [0188] H. The IoT device receives the message and: [0189] 1. Attempts to decrypt the message [0190] 2. Emits an Update with the same value on the indicated attribute Id.[0194] J. IoT device receives the message and sets his paired state to true.[0195] While the above techniques are described with respect to an “IoT service” and an “IoT device,” the underlying principles of the invention may be implemented to establish a secure communication channel between any two devices including user client devices, servers, and Internet services. The above techniques are highly secure because the private keys are never shared over the air (in contrast to current Bluetooth pairing techniques in which a secret is transmitted from one party to the other). An attacker listening to the entire conversation will only have the public keys, which are insufficient to generate the shared secret. These techniques also prevent a man-in-the-middle attack by exchanging signed public keys. In addition, because GCM and separate counters are used on each device, any kind of “replay attack” (where a man in the middle captures the data and sends it again) is prevented. Some embodiments also prevent replay attacks by using asymmetrical counters.
Regarding claim 11, this claim is interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 13, Altin discloses wherein the phase of generating a sequence of session keys comprises the following steps: - a step of calculating a secret, shared by the reader and by the controller, the secret being calculated from a private key (Asprivx) of the controller and from the public key (Bspubx) of the reader;- a step of calculating the sequence of session keys from the shared secret, and from the serial number of the reader, and from the security parameter generated by the reader, and the security parameter generated by the controller. [¶¶ 41, 36, 97, 102, 108, 127, 134-135, 158-171, 213].
Regarding claim 14, Altin discloses wherein the step of calculating the sequence of session keys from the shared secret may be triggered by a fulfillment of a triggering condition among the following triggering conditions: - an idle time of the controller greater than a predetermined threshold; - a number of events greater than a predetermined threshold, the number of events being counted by a counter common to the reader and to the controller; - a command of the controller. [¶¶ 74,77,92,95,133,140,164, 170-172].
Regarding claim 15, Altin discloses wherein the phase of confirming the sequence of keys comprises: - a step of emitting a first authentication code calculated by the controller according to the first session key of the sequence of session keys, and according to an identifier of the controller, and an identifier of the reader, and the security parameter generated by the reader, and the security parameter generated by the controller;- a step of receiving a second authentication code calculated by the reader according to the first session key of the sequence of session keys, and according to an identifier of the controller, and an identifier of the reader, and the security parameter generated by the reader, and the security parameter generated by the controller;- a step of verifying the second authentication code received [103].
Regarding claim 16 Altin discloses , wherein the controller (A) is configured to communicate with a plurality of readers (B1, B21, B22, B23), a reader (BI) among the plurality of readers being a master reader (BI), the security mechanism being accepted by the master reader (BI) during a phase of exchange of keys between the controller (A) and the master reader (B1), the security mechanism accepted by the master reader then being the only one proposed to the other readers (B21, B22, B23) of the plurality of readers (BI, B21, B22, B23), during another phase of exchange of keys between the controller (A) with each of the other readers (B21, B22, B23) of the plurality of readers (BI, B21, B22, B23) [¶42, FIG. 1B illustrates additional connection options for a plurality of IoT hubs 110-111, 190 In this embodiment a single user may have multiple hubs 110-111 installed onsite at a single user premises 180 (e.g., the user's home or business). This may be done, for example, to extend the wireless range needed to connect all of the IoT devices 101-105. As indicated, if a user has multiple hubs 110, 111 they may be connected via a local communication channel (e.g., Wifi, Ethernet, Power Line Networking, etc). In one embodiment, each of the hubs 110-111 may establish a direct connection to the IoT service 120 through a cellular 115 or WiFi 116 connection (not explicitly shown in FIG. 1B). Alternatively, or in addition, one of the IoT hubs such as IoT hub 110 may act as a “master” hub which provides connectivity and/or local services to all of the other IoT hubs on the user premises 180, such as IoT hub 111 (as indicated by the dotted line connecting IoT hub 110 and IoT hub 111). For example, the master IoT hub 110 may be the only IoT hub to establish a direct connection to the IoT service 120. In one embodiment, only the “master” IoT hub 110 is equipped with a cellular communication interface to establish the connection to the IoT service 120. As such, all communication between the IoT service 120 and the other IoT hubs 111 will flow through the master IoT hub 110. In this role, the master IoT hub 110 may be provided with additional program code to perform filtering operations on the data exchanged between the other IoT hubs 111 and IoT service 120 (e.g., servicing some data requests locally when possible)], and [¶44, In this embodiment, the master IoT hub 110 and one or more slave IoT hubs 111 may connect over a local network which may be a WiFi network 116, an Ethernet network, and/or a using power-line communications (PLC) networking (e.g., where all or portions of the network are run through the user's power lines). In addition, to the IoT hubs 110-111, each of the IoT devices 101-105 may be interconnected with the IoT hubs 110-111 using any type of local network channel such as WiFi, Ethernet, PLC, or Bluetooth LE, to name a few], and [¶¶108, 135].
Regarding claim 17, Altin discloses wherein the plurality of readers comprises a first group (Bix) of readers (B1, B12, Bin) configured to protect the access to a first area, and wherein the plurality of readers comprises at least one second group (B2x) of readers (B21, B22, B23) configured to protect the access to at least one second area, and wherein the master reader (BI) belongs to the first group of readers, the security mechanism being accepted by the master reader (BI) during a phase of exchange of keys between the controller (A) and the master reader (B1), the security mechanism accepted by the master reader then being the only one proposed to the other readers (B12, Bin) of the first group of readers (B1, B12, Bin), during another phase of exchange of keys between the controller (A) with each of the other readers (B12, Bin) of the first group of readers (B1, B12, Bin)
[¶¶ 42, 44, 108, 135].
Regarding claims 18, Altin discloses an access control reader (B) for controlling access to an area or IOT hub, configured to communicate at least one information, read on a badge, to a controller (A), according to a method (100) according to any of claims 1.
[ see FIGs 1A-1B and corresponding text for more details].
Regarding claim 19, Aktin discloses a controller (A) of an access control reader or an IOT hub configured to communicate with the access control reader or an IOT hub according to a method (200) according to any of claims 11
[ see FIGs 1A-1B and corresponding text for more details].
Second Set of Rejection:
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, and 11 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by JENS BENDER ET AL: "The PACEIAA Protocol for Machine Readable Travel Documents, and its Security", IACR, INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH., hereinafter, “Bender”. (Filed with IDS 08/15/2023).
Regarding claims 1, and 11, Bender discloses A method
[Abstract, we discuss an efficient combination of the cryptographic protocols adopted by the International Civil Aviation Organization (ICAO) for securing the communication of machine-readable travel documents and readers. Roughly, in the original protocol the parties first run the Password-Authenticated Connection Establishment (PACE) protocol to establish a shared key and then the reader (optionally) invokes the Active Authentication (AA) protocol to verify the passport’s validity. Here we show that by carefully re-using some of the secret data of the PACE protocol for the AA protocol one can save one exponentiation on the passports’s side. We call this the PACE|AA protocol. We then formally prove that this more efficient combination not only preserves the desirable security properties of the two individual protocols but also increases privacy by preventing misuse of the challenge in the Active Authentication protocol]; and
a phase
[ Page 4, 1st paragraph, each pair of users initially shares a secret password π —which in the passport scenario is transferred from the chip to the terminal by entering it at the reader or by reading the machine-readable zone. The password π may be used multiple times to generate session keys…]; and
a phasepubK) of the readepubK) of the controller
[ Page 8, 2nd paragraph, Then the parties run the PACE protocol, with the chip sending a nonce encrypted under the password, running the Diffie-Hellman based Map2Point protocol to derive another generator ˆg on which another Diffie-Hellman key exchange is then performed], and [Page 2, 3rd paragraph, the Map2Point step can be instantiated by different means and allows a modular design. The most common instantiations are based on another Diffie-Hellman step (used within the German identity card], and [see FIG. 2, public key]; and
a phase
[ Page 4, 1st paragraph, each pair of users initially shares a secret password π —which in the passport scenario is transferred from the chip to the terminal by entering it at the reader or by reading the machine-readable zone. The password π may be used multiple times to generate session keys…]; and
a phase
[ Page 8, 2nd paragraph, Then the parties run the PACE protocol, with the chip sending a nonce encrypted under the password, running the Diffie-Hellman based Map2Point protocol to derive another generator ˆg on which another Diffie-Hellman key exchange is then performed], and [Page 2, 3rd paragraph, the Map2Point step can be instantiated by different means and allows a modular design. The most common instantiations are based on another Diffie-Hellman step (used within the German identity card…Then the parties run the PACE protocol…The parties in the PACE protocol finally exchange message authentication codes TA, TB., see FIG 1]; and
a protocol phase
[Page 1, Introduction, 1st paragraph, The Diffie-Hellman key is subsequently used to secure the communication].
wherein the key exchange phase comprises: a step of receiving the public key (AspubK) of the controller, and of receiving a list of security mechanisms proposed by the controller and of receiving a security parameter generated by the controller; a step of emitting to the controller, the public key (BspubK) of the reader, and a serial number of the reader, and a security mechanism accepted by the reader, said security mechanism chosen from among the list of security mechanisms, and a security parameter generated by the reader [see pages 7-8, see fig.1 for PACE/AA protocol , 3.1 Protocol Description
Figure 1 illustrates the PACE/AA protocol with both options of authentication at the end. The
scheme itself uses a block cipher C(K_; _) : f0; 1g` ! f0; 1g` and a hash function H, with values
1; 2;… in fixed-length encoding prepended to make evaluations somewhat independent.
The chip already holds a certicate certC ( contain serial number) for its public key XA under the authorities' public
key pkCA, and (authenticated) group parameters G = (a; b; p; q; g; k) describing a subgroup of order q, generated by g, of an elliptic curve for parameters a; b; p for security parameter k. We also note that, throughout the paper, we use the multiplicative notation for group operations. It is
understood that, if working with elliptic curves, multiplications correspond to additions and exponentiations to multiplications. Then the parties run the PACE protocol, with the chip sending a nonce encrypted under the password, running the Diffie-Hellman based Map2Point protocol to derive another generator ^g on which another Diffie-Hellman key exchange is then performed. In this Map2Point step the chip uses some secret exponent yA to send YA = gyA. The parties in the There are essentially two possible instantiations. One is based on the Schnorr signature scheme [Sch90] where the chip uses the values yA and YA as the (private resp. public) randomness and TB as the challenge for creating the signature under its long-term signature key XA. We call this option Active Authentication via Schnorr signatures. Alternatively, the chip card might prove its authenticity by providing a DSA signature where again yA and YA are used as the randomness for the signature generation [Kra95]. This version is called Active Authentication via DSA signatures. We note that the computation of the final signatures requires only modular multiplications (and, in case of DSA, an inversion) instead of exponentiations.
[ see section 4], and [see page 12, section 5. Security Analysis of PACE/AA. In this section, we discuss the security of the PACE/AA protocol when active authentication is done via Schnorr signatures; the case of DSA signatures follows, too, because we do not use any specific properties of the underlying signature scheme (except for the robust unforgeability). That is, we assume that the chip, holding public key XA = gxA with certificate certC, signs the message YB with key xA and randomness YA. The signature is given by _ = yA + cxA mod q for c = H(5jjYA; TB). After the final authentication step of PACE, the chip sends (using already a secure channel) the values _ and certC to the reader who verifies the signatures and the certificate (and aborts in case one of the verifications fails).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See submitted 892 for more relevant references.
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 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 SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights