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 02/19/2026. Claims 1-11 are cancelled. Claims 12-20 are mended. Claims 21-26 newly added. cancelled. Claims 12-26 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/404,728.
Response to Restriction Requirement
Election: With respect to the restriction of the above-referenced office action of Group 1 claims 1-8 and Group 2 claims 12-20, applicant elects Group 2 claims 12-20 without traverse and cancels claims 1-8.
Applicant amends claims 12-14 and 16-20 for matters of form and antecedence.
Applicant adds new claims 21-26 drawn to elected Group.
Examiner, therefore, has examined claims 12-26 in this instant office action.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 18, and 19 recite “obtaining the data Merkle root”, and “ the stored data Merkle root” . There is insufficient antecedent basis for these limitations in the claim.
Claim 20 recites “the intermediate hashes “the data Merkle root”. There is insufficient antecedent basis for this limitation in the claim.
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 rejections:
Claims 12-13, and 21-22 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by NPL issued to Achraf Fayad ( A Blockchain-based Lightweight Authentication Solution for IoT) issued in 2019, hereinafter, “Fayad”.
Regarding claims 12, and 21, Fayad discloses a method for authentication within a decentralized network, the decentralized network having a plurality of lightweight nodes including a first and a second lightweight node, the method comprising [ Page 28, 2nd column, we propose an efficient and lightweight decentralized authentication mechanism for IoT devices. We implemented our approach relying on Ethereum blockchain and benefiting from its smart contracts mechanism], and [See page 29 , III. BLOCKCHAIN-BASED AUTHENTICATION APPROACH FOR IOT SYSTEMS], and . [Page 30, 1st column, C. System’s functioning: Let O1 and O2 be two objects. In order to establish a communication session between these two objects, the authentication is a mandatory requirement and there are two defined scenarios: (1) simple authentication or (2) mutual authentication], and [ Table 1: Node type: Raspberry PI 3 Model B]; and
Initiating an authentication sequence from the first to the second lightweight node, including at least [ Page 30 , 1st column, B. Initialization phase Our approach relies mainly on the usage of a blockchain. Thus, when a new device is added to the network, the user that adds it must register it. This is provided by sending a transaction to the blockchain, which contains: (1) the object’s identifier (Object ID) and (2) the object’s public key. When the transaction is treated and stored in the blockchain, the device obtains the transaction identifier (Transaction ID). C. System’s functioning: Let O1 and O2 be two objects. In order to establish a communication session between these two objects, the authentication is a mandatory requirement and there are two defined scenarios: (1) simple authentication or (2) mutual authentication]; and
Self-verifying a validity of the first lightweight node on the blockchain
[ Page 30 , 1st column, B. Initialization phase Our approach relies mainly on the usage of a blockchain. Thus, when a new device is added to the network, the user that adds it must register it. This is provided by sending a transaction to the blockchain, which contains: (1) the object’s identifier (Object ID) and (2) the object’s public key. When the transaction is treated and stored in the blockchain, the device obtains the transaction identifier (Transaction ID)], and [ see page 30 2nd column, see for Basic operations of a node ( Algorithm 1), Page 32 for Algorithm 2: proposed approach: simple authentication use case scenario , and Algorithm 3: proposed approach: mutual authentication use case approach , for more detail see Pages 30-32].
Ensuring a valid public key is enrolled in the decentralized network; Verifying ownership of the public key assigned to the second lightweight node by and the first lightweight node [ see page 30 2nd column, see for Basic operations of a node ( Algorithm 1), Page 32 for Algorithm 2: proposed approach: simple authentication use case scenario , and Algorithm 3: proposed approach: mutual authentication use case approach , for more detail see Pages 30-32].
Regarding claims 13, 22, further comprising a step of sending a hello message from the first lightweight node to the second lightweight node [ [ see page 30 2nd column, see for Basic operations of a node ( Algorithm 1), Page 32 for Algorithm 2: proposed approach: simple authentication use case scenario , and Algorithm 3: proposed approach: mutual authentication use case approach , for more detail see Pages 30-32].
Claims 14, 17, 23, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over NPL issued to Achraf Fayad ( A Blockchain-based Lightweight Authentication Solution for IoT) issued in 2019, hereinafter, “Fayad”., and further in view of JING, Bo (CN 111741012 A), hereinafter, “JING”.
Regarding claims 14, and 23, Fayad does not explicitly disclose, however, JING discloses , further comprising a step of identifying most recent block to identify a revocation list [Page 4, 2nd para. the authorization signature generation node is deployed with lightweight node authority authentication service; the key of the target certificate party corresponding to the digital certificate of the lightweight node can be used; verifying the digital certificate, such as the lightweight node applying for digital certificate to the CA1 certificate authority service party, then the authorization signature generation node needs to use the public key of the CA1 certificate authority service party to verify whether the digital certificate is valid; after verifying the digital certificate is valid, the authorization signature generation node further can call the revoked certificate query service, confirming whether the digital certificate of the lightweight node is revoked, wherein, according to the different of the digital certificate issuer, calling the revoked certificate query service corresponding to the certificate issuer. In the query process, the authorization signature generation node can interact with different certificate parties, obtaining certificate revocation list provided by the sender, then storing in the local, matching by the list, confirming whether the digital certificate of the lightweight node is revoked. if it is determined that the digital certificate of the lightweight node is valid and is not revoked, then the lightweight node authority signature generation service can be invoked, generating an authorization signature for the lightweight node].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Fayad, by incorporating “implementing a lightweight node with digital certificate”, as taught by JING. One could have been motivated to do so in order to obtain certificate revocation list and confirming whether the digital certificate of the lightweight node is revoked. if it is determined that the digital certificate of the lightweight node is valid and is not revoked, then the lightweight node authority signature generation service can be invoked, generating an authorization signature for the lightweight node [ JING, Page 4, 2nd para].
Regarding claims 17, and 26, Fayad does not explicitly disclose, however, JING discloses further comprising a step of the first lightweight node
accessing a last block on blockchain to access a revocation list; and identifying if a block associated with enrollment of the second lightweight node is references by the revocation list. [Page 4, 2nd para. the authorization signature generation node is deployed with lightweight node authority authentication service; the key of the target certificate party corresponding to the digital certificate of the lightweight node can be used; verifying the digital certificate, such as the lightweight node applying for digital certificate to the CA1 certificate authority service party, then the authorization signature generation node needs to use the public key of the CA1 certificate authority service party to verify whether the digital certificate is valid; after verifying the digital certificate is valid, the authorization signature generation node further can call the revoked certificate query service, confirming whether the digital certificate of the lightweight node is revoked, wherein, according to the different of the digital certificate issuer, calling the revoked certificate query service corresponding to the certificate issuer. In the query process, the authorization signature generation node can interact with different certificate parties, obtaining certificate revocation list provided by the sender, then storing in the local, matching by the list, confirming whether the digital certificate of the lightweight node is revoked. if it is determined that the digital certificate of the lightweight node is valid and is not revoked, then the lightweight node authority signature generation service can be invoked, generating an authorization signature for the lightweight node].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Fayad, by incorporating “implementing a lightweight node with digital certificate”, as taught by JING. One could have been motivated to do so in order to obtain certificate revocation list and confirming whether the digital certificate of the lightweight node is revoked. if it is determined that the digital certificate of the lightweight node is valid and is not revoked, then the lightweight node authority signature generation service can be invoked, generating an authorization signature for the lightweight node [ JING, Page 4, 2nd para].
Claims 15, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over NPL issued to Achraf Fayad ( A Blockchain-based Lightweight Authentication Solution for IoT) issued in 2019, hereinafter, “Fayad”, and in view of US2016/0345188 issued to Chen.
Regarding claims 15,and 24, Fayad does not explicitly disclose, however, Chen discloses, further comprising sending a first challenge nonce from the first lightweight node to the second lightweight node and then a second challenge nonce from the second lightweight node to the first lightweight challenge node[ Abstract, Aspects of the disclosure are related to a method for generating random numbers based on WLAN signal measurements, comprising: measuring WLAN signals; harvesting entropy based on the WLAN signal measurements; and generating a random number based on the harvested entropy], and [¶4, Random numbers are often used in generating appropriate security parameters in a computer system. It is, however, a challenging task to generate high quality random numbers, i.e., sequences of unpredictable and non-deterministic numbers that are close to being truly random, with a computer system. Moreover, the particular configuration and relative low cost of IoT devices pose challenges for random number generation], and [ [0041] Referring to FIG. 4, a flowchart illustrating an example method 400 for generating random numbers based on WLAN signal measurements is shown. At block 410, a processor of device 110 (FIG. 1) may measure WLAN signals. At block 420, a processor of device 110 may harvest entropy based on the WLAN signal measurements. Various examples of WLAN signal measurements that may serve as entropy sources have been described in detail above. At block 430, a processor of device 110 may generate one or more random numbers based on the harvested entropy. Additionally, one or more de-biasing techniques may be applied to reduce or eliminate bias in the generated random numbers. The generated random numbers may be used, for example, for key derivation in a cryptographic operation], and [¶42, Therefore, by utilizing embodiments of disclosure described herein, an IoT device with no or limited input devices and/or no disk may generate high quality random numbers for use in cryptographic operations based on various WLAN signal measurements without reliance on a costly hardware random number generator].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Fayad by incorporating “ random numbers generation based on WLAN signal measurements”, as taught by Chen. One could have been motivated to do so in order to generate random numbers for IoT devices with no or limited input devices based on the harvested entropy for use in cryptographic operations [ Chen, Abstract, ¶¶ 4, 4143].
Claims 16, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over NPL issued to Achraf Fayad ( A Blockchain-based Lightweight Authentication Solution for IoT) issued in 2019, hereinafter, “Fayad”, and in view of (US2023/0089134) issued to Wang.
Regarding claims 16, and 25, Faya does not explicitly disclose, however, WANG discloses further comprising the steps of generating a genesis block with a trusted node and sending the genesis block from the trusted node to each lightweight node comprising the plurality of lightweight nodes. [¶55, One identical blockchain is stored in each node 201 in the data sharing system 100. The blockchain is formed by a plurality of blocks. FIG. 1B is a schematic structural diagram of a blockchain according to an embodiment of this application. The blockchain is formed by a plurality of blocks. Each block includes a block header and a block body, a block header of a genesis block stores an input information feature value, a version number, a timestamp, and a difficulty value, a block header of a block other than the genesis block stores an input information feature value, a version number, a timestamp, a block header feature value of a parent block, and a difficulty value, and a block body of each block stores input information In this application, in addition to transactions initiated by the nodes, the input information may further include a statistical proof transaction list generated based on these transactions, and the statistical proof transaction list may also be considered as a transaction], and [¶83, In a possible implementation, if the data synchronization request includes identity information of the lightweight node, the full node may obtain the identity information of the lightweight node from the data synchronization request, and then the full node may check the obtained identity information of the lightweight node. During specific implementation, the identity information may include a digital signature of the lightweight node, and the digital signature is obtained after the lightweight node signs the data synchronization request according to a private key of the lightweight node; and after receiving the identity information from the lightweight node, the full node may check the digital signature of the lightweight node according to a public key of the lightweight node, and when the digital signature is checked successfully, it indicates that identity check on the lightweight node is successful. Through this manner, validity of the identity of the lightweight node is checked, to help improve security of data between the lightweight node and the full node, thereby ensuring that the data is transmitted to the valid lightweight node], and [¶94].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Fayad by incorporating “ peer to peer (P2P) network formed between nodes with blockchain”, as taught by Wang. One could have been motivated to do so in order to , the full node transmits, when the identity information of the lightweight node check is checked by the full node successfully, the statistical proof transaction list, the target index, the associated transactions, and the encrypted path set to the lightweight node. Additionally, the full node may further transmit a block header of the associated block to the lightweight node, where the block header of the associated block includes but not limited to: a version number of the associated block, an input information feature value, a timestamp, a difficulty value, a block Merkle root and the like. [ Wang, Abstract, ¶¶ 4, 94].
Second set of rejections:
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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 of this title, 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 12, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 2023/0089134 issued to WANG, and in view of US Patent Application No. (2017/0195826) issued to SHAIKH, and further in view of (US2021/0256113) issued to Stott, and further in view of BEDEROV, DENIS(RU 2791865 C2), hereinafter, “DENIS”.
Regarding claims 12, and 21, Wang discloses a method for authentication within a decentralized network, the decentralized network having a plurality of lightweight nodes including a first and a second lightweight node, the method comprising [ see figs 1A, and 2 for lightweight nodes 101, [¶58, FIG. 2 is a schematic diagram of an architecture of a data communication system according to an embodiment of this application. The architecture of the system includes: a lightweight node cluster 100 and a full node cluster 200, where the lightweight node cluster 100 includes a lightweight node 101, a lightweight node 102, a lightweight node 103, and a lightweight node 104, and the full node cluster 200 includes a full node 201, a full node 202, a full node 203, and a full node 204. The lightweight node cluster 100 is located in a first blockchain network, the full node cluster 200 is located in a second blockchain network, the first blockchain network is different from the second blockchain network, and the first blockchain network is an underlying network of the second blockchain network].
Wang does not explicitly disclose; however, SHAIKH discloses:
Initiating an authentication sequence from the first to the second lightweight node, including at least [¶26, FIG. 1B shows a relationship between a set of nodes 110 and a set of base stations 120 according to one example. Each node 110 forwards a packet to another node 110 or to a base station 120. In one example, when a node 110 sends a packet the node 110 is considered a sender node 111 and when a node 110 receives a packet the node 110 is considered a receiver node. The receiver node can also be a destination node 113 or an intermediate node 112], and [¶¶28-29, In an aspect, the geographical location 131 of each node 110 is known to the node 110. Each node 110 may have a unique node identity or a node identity. In one example, the node identity of a node 110 will not be shared with another node 110 in the network 100. In another example, the node identity of the node 110 will be shared with the receiver node and the base station 120. In another example, the node identity and the geographical location 131 of the receiver node are known to each node 110 in the network 100. The node identity can be used in a variety of ways. For example, a trust model can use the node identity to maintain a past history information which can be used for building the trustworthiness reputation of another node 110. The network routing protocol uses a node identity for forwarding the packet to the final destination].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of WANG, by incorporating “a unique node identity”, as taught by SHAIKH. One could have been motivated to do so in order for a trust model can use the node identity to maintain a past history information which can be used for building the trustworthiness reputation of another node . The network routing protocol uses a node identity for forwarding the packet to the final destination. [ SHAIKH, ¶29].
Wang, and SHAIKH so not explicitly disclose, however, Stott discloses :
Self-verifying a validity of the first lightweight node on the blockchain[ see FIG 2, lightweight node (250A), and lightweight node (250B), [¶¶61-62, Lightweight node computing device(s) 250A and 250B may request execution of network functions related to blockchain 226 in decentralized P2P network 270. In order to request execution of network functions, processors of lightweight node computing device(s) 250A and 250B may execute network commands to broadcast the network functions to decentralized P2P network 270 comprising full node computing device(s) 210A-210F. For example, lightweight node computing device 250A may request execution of a network function related to blockchain 226 in decentralized P2P network 270, which may entail a data transfer from a private/public key associated with lightweight node computing device 250A to a private/public key associated with lightweight node 250B. In doing so, processors of lightweight node computing device 250A may execute network commands to broadcast a network function request 280 or communication to decentralized P2P network 270. Network function request 280 may further include the public key associated with lightweight node computing device 250B. Processors of lightweight node computing device 250A may execute digital signature algorithms to digitally sign network function request 280 with the private key associated with lightweight node computing device 250A ], and [ ¶71, For another example, lightweight node computing device 250B may request a network function related to blockchain 226 in decentralized P2P network 270, which may facilitate a dual data transfer between a private/public key associated with lightweight node computing device 250B and a private/public key associated lightweight node computing device 250A. Processors of lightweight node computing device 250B may execute network commands to broadcast network function request 290 to decentralized P2P network 270. Network function request 290 may include details about an event or data transfer, as well as any related or associated variable to full node computing device(s) 210A-210F of decentralized P2P network 270 for executing network function request 290. Network function request 290 may further include the public key associated therewith. Processors of lightweight node computing device 250B may execute digital signature algorithms to digitally sign software, versions, malware-free certifications, authorized transfers or purchase relating to network function request 290 with the private key associated with lightweight node computing device 250B], and [¶39].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of WANG, and SHAIKH by incorporating “private and public key of lightweight node”, as taught by Stott. One could have been motivated to do so in order for each lightweight node to provide public key and digital signature in a decentralized P2P network data transfer for the purposes of identity and/or authenticity verification [ Stott, ¶¶43, 61-62, 71].
WANG, and SHAIKH, and Stott do not explicitly disclose, however, BEDEROV discloses:
Ensuring a valid public key is enrolled in the decentralized network [Page 3, claim 2, If the public key of the first node is valid, other nodes can accept the transaction and/or the block generated by the first node. However, if the public key of the first node is not valid, then other nodes will reject the transaction and/or the block generated by the first node. In connection with the use of a trusted entity, it is possible to invalidate and/or invalidate the public key of a blockchain node, which causes the node for which the public key has been invalidated to no longer be able to produce valid transactions and/or blocks. Thus, the trusted entity can exclude, for example, malicious nodes from generating correct transactions and/or from validating blockchain blocks. Therefore, these malicious nodes can no longer interfere with the blockchain. In this way, the risk posed by malicious nodes can be eliminated, which greatly improves the security of the blockchain], and [Page 5 5th para. a public key infrastructure (PKI) is used to check if the public key of the first node is valid. The PKI allows the creation, management, distribution, use, storage and/or revocation of encryption keys, in particular public keys. For this purpose, the PKI may use a set of fixed policies and procedures. A PKI may contain multiple computing objects, which may be located separately from each other, and which perform the functions of the PKI. The use of PKI makes it easy and secure to implement the mechanisms needed to verify that the public key (that is, the public key of the first node) is valid. With the security standards implemented in the PKI, the security of the blockchain can be further enhanced].
Verifying ownership of the public key assigned to the second lightweight node by and the first lightweight node[Page 3, claim 2, If the public key of the first node is valid, other nodes can accept the transaction and/or the block generated by the first node. However, if the public key of the first node is not valid, then other nodes will reject the transaction and/or the block generated by the first node. In connection with the use of a trusted entity, it is possible to invalidate and/or invalidate the public key of a blockchain node, which causes the node for which the public key has been invalidated to no longer be able to produce valid transactions and/or blocks. Thus, the trusted entity can exclude, for example, malicious nodes from generating correct transactions and/or from validating blockchain blocks. Therefore, these malicious nodes can no longer interfere with the blockchain. In this way, the risk posed by malicious nodes can be eliminated, which greatly improves the security of the blockchain], and
[Page 5 5th para. a public key infrastructure (PKI) is used to check if the public key of the first node is valid. The PKI allows the creation, management, distribution, use, storage and/or revocation of encryption keys, in particular public keys. For this purpose, the PKI may use a set of fixed policies and procedures. A PKI may contain multiple computing objects, which may be located separately from each other, and which perform the functions of the PKI. The use of PKI makes it easy and secure to implement the mechanisms needed to verify that the public key (that is, the public key of the first node) is valid. With the security standards implemented in the PKI, the security of the blockchain can be further enhanced].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of WANG, and SHAIKH, and Stott by incorporating “a method of generating a blockchain transaction and verifying the validity of a blockchain block.”, as taught by BEDEROV. One could have been motivated to do so in order to generates a transaction by the first node of the blockchain, adds a cryptographic signature to the transaction using the private key of the first node, thereby creating a signed transaction, broadcasts the signed transaction to a plurality of other nodes in the blockchain, while the other nodes verify the cryptographic signature of the signed transaction using the public key of the first node, wherein said other nodes check with the trusted entity whether the public key of the first node is valid, and the trusted entity is a blockchain node, if the public key is not valid, said other nodes reject the transaction generated by the first node. [ BEDEROV, Abstract].
Allowable Subject Matter
Claims 18-20 are rejected as there is no standing prior art rejection, However, these claims are rejected under claim Rejections-35 USC 112(b) , and would be allowable if the outstanding rejections are overcome, without broadening the scope of independent claims,
and being dependent upon a rejected base claim but, would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The reason for allowance will be furnished upon allowance of the application.
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.
Hwang ( KR102613703B1) corresponding to Hwang (US2022/0038910) [ see FIG. 1 , communication between drones 11, and 12, [¶50, In the present invention, the terminals 11 and 12 may be drones. The terminals 11 and 12 may transmit and receive broadcast packets or unicast packets, which are transmitted and received in a one-to-one manner, at steps S210 and S220], and [¶67, First, a first terminal 11 may transmit a packet to a second terminal 12 at step S310. That is, the source address of the packet is the address of the first terminal 11, and the destination address thereof is the address of the second terminal 12. Here, the packet may be, for example, a path negotiation packet transmitted and received between the first terminal 11 and the second terminal 12], and [¶19, Here, the trust inquiry packet may include at least one of the address of the first terminal, which is a source address, the address of the second terminal, which is a destination address, a data field, a trust field, and information about the time at which the packet is received].
Lou (US2018/0184290) [see FIG 6, 0037] If the IoT device's ID is in the counter party's ACL in step 607, initialization process 600 is no longer required and the protocol may proceed to the authentication protocol in step 608 (discussed in more detail in FIG. 7). If the IoT device's ID is not in the counter party's ACL, the counter party may check the IoT device's ID with a web server or online database of the manufacturer of the device containing the IoT device to ensure that the device is actually made by the manufacturer and not compromised in step 610. In one embodiment, step 610 may be deferred to a time when internet connectivity is available to the counter party. In another embodiment, the counter party may request a user to verify a chip ID that may be printed on the device containing the IoT device is identical to the ID that is presented in the IoT devices certificate. If they are identical, the initialization process may continue.[0038] The counter party device may then send an Initialization Request, comprising the counter party's ID or certificate, to the IoT device in step 612. If the IoT device's ACL is not empty in step 613 and the counter party's ID is not in the IoT device's ACL but in a pending ACL, the IoT device may respond to the Initialization Request with an Introduction Challenge with a nonce in step 614. The counter party may then calculate a hash value of the nonce with the manufacturer's low-entropy key (stored in the pending ACL with the counter party's ID) in step 616. The counter party may then send an Introduction Response with the hash in step 618. The IoT device may then calculate the same hash and ensure the two hashes (from the counter party and from the IoT device) match in step 620.
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