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 .
Response to Amendment
The amendment filed 02/19/2026 has been entered. Claims 22, 23, 29 and 31 have been amended. Claims 1-14 have been/remain canceled. Claims 15-19 are withdrawn. No Claims have been newly added. Claims 15-33 remain pending in the application, claims 20 and 29 are independent.
Response to Arguments
Regarding Applicant’s arguments, on page 11-12 of the remark filed on 02/19/2026, Applicant’s election without traverse of Group II: Claims 20-33 in the reply filed on 02/19/2026 is acknowledged.
Specification
The use of the term “Bluetooth” and “Zigbee” on Par. (0092) of the specification, which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Claim Objections
Claims 21, 23 and 28 are objected to because of the following informalities:
In regards to Claims 21, 23 and 28, the applicant recites the preamble limitation “the process of claim 20” without the appropriate punctuation. This is a typographical error that should read “the process of claim 20,” with appropriate “ , “ comma. Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 20-33 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-8 and 10-14, of U.S. Patent No. 12,107,966. Although the claims at issue are not identical, they are not patentably distinct from each other because the examined application claim is obvious over the conflicting patent claim. See the table below.
Instant Application
U.S Patent
U.S Application No. 18,823,682
U.S Patent No. 12,107,966
Claim 1:
A process for an unenrolled lightweight node having memory and a processor executing lightweight blockchain consensus instructions, the unenrolled lightweight node connected on a decentralized network with at least a trusted node and a plurality of peers that include at least one enrolled lightweight node,
the unenrolled lightweight node and the peers running a lightweight blockchain consensus algorithm, the process comprising: storing a token that includes a signature that includes at least a signature of at least a first identifier signed with a private key of the trusted node, the first identifier being associated with a public key of the unenrolled lightweight node; and
broadcasting a request for blockchain enrollment of the unenrolled lightweight node to the plurality of peers,
including to the at least one enrolled lightweight node, the authentication request including at least a second identifier that is associated with at least a public key of the unenrolled lightweight node, a signature created with at least the second identifier and a corresponding private key of the unenrolled lightweight node, and the token.
Claim 1:
A plurality of unenrolled lightweight nodes on a decentralized network with at least a trusted node and a plurality of peers that include at least one enrolled lightweight node,
each respective unenrolled lightweight node and the peers running a lightweight blockchain consensus algorithm, each respective unenrolled lightweight node comprising: circuitry for locally storing a T0 transaction in the respective lightweight node, the T0 transaction comprising: a transaction body comprising a first identifier and a public key of the trusted node, the first identifier being associated with a public key of the trusted node; a signature of the transaction body comprising the first identifier and the public key of the trusted node, all signed by the private key of the trusted node; a header comprising a hash of the transaction body and the signature of the transaction body; a genesis block comprising a block header and a block body; the block header comprising at least metadata, a block identifier (block_id), a transaction Merkle root, and a data Merkle root; the block body of the genesis block comprising the T0 transaction and a revocation list;
circuitry for broadcasting an authentication request for blockchain enrollment of the respective unenrolled lightweight node to the plurality of peers,
including to the at least one enrolled lightweight node, the authentication request comprising a T1 transaction, the T1 transaction comprising: a first field comprising a second identifier and the public key of the respective unenrolled lightweight node; a T1 token comprising the second identifier, the public key of the respective unenrolled lightweight node, and a timestamp, all signed by the private key of the trusted node; a second field comprising the second identifier and the public key of the respective unenrolled lightweight node, all signed by the private key of the respective unenrolled lightweight node; a hash of the first field, the T1 token, and the second field; each respective enrolled node verifying a respective received T1 transaction for enrollment of the respective unenrolled lightweight node by the lightweight blockchain consensus algorithm by: verifying the associated T1 token using the public key of the trusted node; verifying a signature of a the respective received T1 transaction second field using the public key from the received T1 transaction first field whereby a change in the revocation list causes a Merkle root of the revocation list to be recomputed and the transaction Merkle root to be recomputed using the recomputed Merkel root of the revocation list, the recomputed transaction Merkle root stored in the genesis block.
Claim 21:
The process of claim 20 wherein the first identifier includes at least a hash of the public key of the unenrolled lightweight node, and wherein the second identifier includes at least a hash of the public key of the unenrolled lightweight node.
Claim 2:
The plurality of unenrolled lightweight nodes of claim 1, wherein the first identifier includes at least one hash of the public key of the trusted node, and wherein the second identifier includes at least a hash of the public key of the respective unenrolled lightweight node.
Claim 22:
The process of claim 20, wherein the hashes of the public key of the of the unenrolled lightweight node were created with a SHA-3 hash algorithm.
Claim 3:
The plurality of unenrolled lightweight nodes of claim 2, wherein the at least one hash of the public key of the respective unenrolled lightweight node were created with a SHA-3 hash algorithm.
Claim 23:
The process of claim 20 wherein the signature with the private key of the trusted node was created by the first identifier, the public key of the unenrolled lightweight node, and a timestamp, each being signed with the private key of the trusted node; and
wherein the signature with the private key of the unenrolled lightweight node was created with the second identifier, the token, and the public key of the unenrolled lightweight node being signed with the private key of the unenrolled lightweight node.
Claim 4:
The plurality of unenrolled lightweight nodes of claim 1, wherein the T1 token was created by the second identifier, the public key of the respective unenrolled lightweight node, and a timestamp each being signed with the private key of the trusted node; and
wherein the second field was created with the second identifier, and the public key of the respective unenrolled lightweight node, being together signed with the private key of the respective unenrolled lightweight node.
Claim 24:
The process of claim 20, wherein the authentication request further includes the public key of the unenrolled lightweight node.
Claim 5:
The plurality of unenrolled lightweight nodes of claim 1, wherein the authentication request further includes the public key of the respective unenrolled lightweight node.
Claim 25:
The process of claim 20, further comprising receiving from at least one peer decentralized network a block for authentication and inclusion in a blockchain, the block including at least a transaction for enrollment of the unenrolled lightweight node, the transaction including at least the request for blockchain enrollment.
Claim 6:
The plurality of unenrolled lightweight nodes of claim 1, further comprising: circuitry for receiving from at least one peer decentralized network a block for authentication and inclusion in a blockchain, the block including at least a transaction for enrollment of the respective unenrolled lightweight node, the transaction including at least the authentication request for blockchain enrollment.
Claim 26:
The process of claim 25, further comprising utilizing the lightweight consensus algorithm to reach a consensus with the plurality of peers of the decentralized network, the consensus being a consensus to approve the block and to add the block to the blockchain or to reject the block and to not add the block to the blockchain.
Claim 7:
The plurality of unenrolled lightweight nodes of claim 6, further comprising: circuitry for utilizing a lightweight consensus algorithm to reach a consensus with the plurality of peers of the decentralized network, the consensus being a consensus to approve the block and to add the block to the blockchain or to reject the block and to not add the block to the blockchain.
Claim 27:
The process of claim 26, further comprising adding the block to a blockchain responsive to a consensus to add the block to the blockchain, wherein the unenrolled lightweight node thereupon becomes enrolled in the decentralized network; and storing a block identifier of the block and an intermediate Merkle tree hash associated with the block in memory of the now enrolled lightweight node.
Claim 8:
The plurality of unenrolled lightweight nodes of claim 7, further comprising: circuitry for adding the block to a blockchain responsive to a consensus to add the block to the blockchain, wherein the respective unenrolled lightweight node thereupon becomes enrolled in the decentralized network; and circuitry for storing a block identifier of the block and an intermediate Merkle tree hash associated with the block in a memory of the enrolled lightweight node.
Claim 29:
A process for an enrolled lightweight node having a memory and a processor executing lightweight blockchain consensus instructions on a decentralized network with at least one unenrolled lightweight node and one trusted node, process comprising: receiving from the unenrolled lightweight node an authentication request that includes at least: a) a token created with at least a first identifier signed with a private key of the trusted node, the first identifier being associated with a public key of the unenrolled lightweight node; and b) a second identifier that is associated with at least a public key of the unenrolled lightweight node and a second signature created with at least at least the second identifier and a corresponding private key of the unenrolled lightweight node; and broadcasting the authentication request to at least one other enrolled lightweight node of the decentralized network.
Claim 10:
An enrolled lightweight node on a decentralized network with at least one unenrolled lightweight node and one trusted node, the enrolled lightweight node comprising: circuitry for receiving from the unenrolled lightweight node an authentication request that includes at least: a) a first field comprising a first identifier of the unenrolled lightweight node and a public key of the unenrolled lightweight node; b) a token that includes at least a hash of the public key of the unenrolled lightweight node, the public key of the unenrolled lightweight node, and a timestamp, the token signed using a private key of the trusted node; c) a second field comprising a hash of the public key of the unenrolled lightweight node, and a public key of the unenrolled lightweight node, the second field signed with a private key of the unenrolled lightweight node; d) a hash of: the first field, the token, and the second field; circuitry for broadcasting the authentication request to at least one other enrolled lightweight node of the decentralized network; the at least one other enrolled lightweight node maintaining a local revocation list containing Merkle roots of stations no longer participating in the decentralized network, upon authentication of the unenrolled node, the at least one other enrolled lightweight node generating a locally stored block chain that includes the authentication request as a transaction block of the block chain, the transaction block including a transaction Merkle root, the Merkle root of the transaction block recomputed when the revocation list changes.
Claim 30:
The process of claim 29, further comprising: authenticating the first signature at least in part with the public key of the trusted node; and authenticating the second signature at least in part with the public key of the unenrolled node.
Claim 11:
The enrolled lightweight node of claim 10, further comprising: circuitry for authenticating the signature of the token at least in part with the public key of the trusted node; and circuitry for authenticating the signature of the second field at least in part with the public key of the unenrolled lightweight node.
Claim 31:
The process of claim 30, further comprising: responsive to successful authentication of the first and second signatures, creating a block that includes at least the authentication request and utilizing the lightweight blockchain consensus algorithm for reaching consensus regarding whether to accept or reject the block.
Claim 12:
The enrolled lightweight node of claim 11, further comprising: circuitry for creating a block that includes at least the authentication request, the circuitry responsive to successful authentication of the signed token and signed second field; and circuitry for utilizing the lightweight blockchain consensus algorithm for reaching consensus regarding whether to accept or reject the block.
Claim 32:
The process of claim 31, further comprising: adding the block to a block chain responsive to a consensus to add the block to the blockchain, wherein the unenrolled lightweight node thereupon becomes enrolled in the decentralized network.
Claim 13:
The enrolled lightweight node of claim 12, further comprising: circuitry for adding the block to a blockchain responsive to a consensus to add the block to the blockchain, wherein the unenrolled lightweight node thereupon becomes enrolled in the decentralized network.
Claim 33:
The process of claim 29, wherein the at least one enrolled node is configured to store at least a lightweight blockchain with at least one block with a block header that includes a data Merkle root computed at least in part from a least one Merkle tree node containing a hash value computed directly or indirectly from a hash value computed from a combination of a public key and a validity value for the public key.
Claim 14:
The enrolled lightweight node of claim 10, wherein the at least one enrolled node is configured to store at least a lightweight blockchain with at least one block with a block header that includes a data Merkle root computed at least in part from a least one Merkle tree node containing a hash value computed directly or indirectly from a hash value computed from a combination of a public key and a validity value for the public key.
Furthermore, Claims 20, 23 and 29-30 are rejected on the grounds of nonstatutory obviousness-type double patenting as being unpatentable over claim 1, 4, 10 and 11 of U.S Patent No. 12,107,966 in view of U.S Patent No. 20210044976 issued to Avetisov et al.
As to claim 20, U.S Patent No. 12,107,966 does not disclose storing a token that includes a signature that includes at least a signature of at least a first identifier signed with a private key of the trusted node, the first identifier being associated with a public key of the unenrolled lightweight node; and the authentication request including at least a second identifier that is associated with at least a public key of the unenrolled lightweight node, a signature created with at least the second identifier and a corresponding private key of the unenrolled lightweight node, and the token.
However Avetisov teaches storing a token that includes a signature that includes at least a signature of at least a first identifier signed with a private key of the trusted node, (Par. (0120) “a token for one or more associated identifiers, and the server 145 may store the token within the UID repository 160 in association with one or more identifiers. [..] The token may include an associated timestamp or time-stamps that indicate when the token was created or when it expires. [..]The server 145 may determine, from information stored within the UID repository 160 in response to receiving a token from the client device 135, whether the received token matches a valid token received from the authentication server 155. The server 145 may also determine, from an association between the valid token and an identifier [..] to cryptographically hash a specific set (and optionally order) of determinable information received from or about the client device 135 to create an identifier.”; storing a token that includes a signature of at least a first identifier signed (storing token associated with identifier that is signed/hashed)), (Par. (0101) “the authentication application 120 may request the TEE 103 output signed data with a timestamp or include identifying information associated with a particular notification such that signed data may be considered valid for a particular notification or at a particular point in time to prohibit reuse.[..] one stored by the server during a registration process), and 3) signed 3) signed data, which may be a signature of an output data string of (1) and (2), e.g., {representation, notification ID or timestamp}, is verifiable by a public key provided by the TEE during a registration process.”; signature of a first identifier (signed data or signature corresponding to notification ID)), (Par. (0269); notification ID corresponding to User ID, credentials and identifying information of mobile device)), (Par. (0048) “For example, a private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key.”; signed with private key)), (Par. (0209); trusted node (mobile device with Trusted execution environment that has private key))
the first identifier being associated with a public key of the unenrolled lightweight node; and (Par. (0103) “the authentication application 120 may provide the identifier encrypted with the public key [..]the identifier may be a public key of a key pair, and the TEE 103 may return a shared key to the authentication application 120, encrypted with the identifier (public key),”; first identifier being associated with a public key)), (Figure 1A label 101, 103 and Par. (0092-0093); lightweight node (module of mobile device corresponding to lightweight)), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
the authentication request including at least a second identifier that is associated with at least a public key of the unenrolled lightweight node, a signature created with at least the second identifier and a corresponding private key of the unenrolled lightweight node, and the token. (Par. (0010) “second data indicative of an identifier generated by the web-service; in response to identifying a correspondence between the value and the identifier, [..] an authentication request to authenticate to the web-service to be accessed from the second computing device and, in association with the authentication request, authentication data”; authentication request including a second identifier (second data corresponding identifier associated with authentication request)), (Par. (0115) “For example, the UID repository 160 may store identifying information including one or more of user identifiers, device identifiers, identifying tokens for user or devices, locations of devices on a network, and the like. The UID repository 160 may also store associations between one or more identifiers, for example, a user identifier may be associated with one or more device identifiers to which that user is permitted access or otherwise uses to access the server.”; second identifier (one or more identifiers)), (Par. (0103) “the authentication application 120 may provide the identifier encrypted with the public key in a transmission to the TEE 103, and the identifier may serve as a shared key for encrypted data transmitted during the session. In some embodiments, the identifier may be a public key of a key pair, and the TEE 103 may return a shared key to the authentication application 120, encrypted with the identifier (public key),”; second identifier being associated with a public key)), (Par. (0048) “For example, a private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key.”; corresponding private key)), (Figure 1A label 101, 103 and Par. (0092-0093); lightweight node (module of mobile device corresponding to lightweight)), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified U.S Patent No. 12,107,966 to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of enhancing the authentication process to prevent illegitimate access of devices that are not registered to mitigate vulnerabilities, attacks on identity and attempts by sending information such as tokens, credentials and notification to registered devices using blockchain systems. (Avetisov Par. (0002-0004 and 0014))
As to claim 23, U.S Patent No. 12,107,966 does not disclose wherein the signature with the private key of the trusted node was created by the first identifier, the public key of the unenrolled lightweight node, and a timestamp, each being signed with the private key of the trusted node; and wherein the signature with the private key of the unenrolled lightweight node was created with the second identifier, the token, and the public key of the unenrolled lightweight node being signed with the private key of the unenrolled lightweight node.
However Avetisov teaches wherein the signature with the private key of the trusted node was created by the first identifier, the public key of the unenrolled lightweight node, and a timestamp, each being signed with the private key of the trusted node; and (Par. (0120)”; a signature created by the first identifier (identifier that is signed/hashed)), (Par. (0101); signature created by the first identifier (signed data or signature corresponding to notification ID)), (Par. (0269); notification ID corresponding to User ID, credentials and identifying information of mobile device)), (Par. (0048)”; signed with private key)), (Par. (0209); trusted node (mobile device with Trusted execution environment that has private key)), (Par. (0186); certificate/signature includes public key, timestamp signed by private key)
wherein the signature with the private key of the unenrolled lightweight node was created with the second identifier, the token, and the public key of the unenrolled lightweight node being signed with the private key of the unenrolled lightweight node. (Par. (0055 and 0269); second signature (plurality of signatures verified), (Par. (0120); signature with token and identifier), (Par. (0186); certificate/signature includes public key, timestamp signed by private key), (Par (0269-0270); registration of user/computing node), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified U.S Patent No. 12,107,966 to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of using digital signatures, signed data and tokens to enhance a trusted environment and grant proper access based on data with indications. By verifying signatures with the corresponding keys a secure environment can be retained and used as form of comparison. (Avetisov Par. (0048 and 0055))
As to claim 29, U.S Patent No. 12,107,966 does not disclose a) a token that includes a first signature created with at least a first identifier signed with a private key of the trusted node, the first identifier being associated with a public key of the unenrolled lightweight node; and b) a second identifier that is associated with at least a public key of the unenrolled lightweight node and a second signature created with at least at least the second identifier and a corresponding private key of the unenrolled lightweight node; and
However Avetisov teaches a) a token that includes a first signature created with at least a first identifier signed with a private key of the trusted node, (Par. (0048-0050); transmitting request to entity associated with token, signature and identifier)), (Par. (0120) “a token for one or more associated identifiers, and the server 145 may store the token within the UID repository 160 in association with one or more identifiers. [..] The token may include an associated timestamp or time-stamps that indicate when the token was created or when it expires. [..]The server 145 may determine, from information stored within the UID repository 160 in response to receiving a token from the client device 135, whether the received token matches a valid token received from the authentication server 155. The server 145 may also determine, from an association between the valid token and an identifier [..] to cryptographically hash a specific set (and optionally order) of determinable information received from or about the client device 135 to create an identifier.”; storing a token that includes a signature of at least a first identifier signed (storing token associated with identifier that is signed/hashed)), (Par. (0101) “the authentication application 120 may request the TEE 103 output signed data with a timestamp or include identifying information associated with a particular notification such that signed data may be considered valid for a particular notification or at a particular point in time to prohibit reuse.[..] one stored by the server during a registration process), and 3) signed 3) signed data, which may be a signature of an output data string of (1) and (2), e.g., {representation, notification ID or timestamp}, is verifiable by a public key provided by the TEE during a registration process.”; signature of a first identifier (signed data or signature corresponding to notification ID)), (Par. (0269); notification ID corresponding to User ID, credentials and identifying information of mobile device)), (Par. (0048) “For example, a private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key.”; signed with private key)), (Par. (0209); trusted node (mobile device with Trusted execution environment that has private key))
the first identifier being associated with a public key of the unenrolled lightweight node; and (Par. (0103) “the authentication application 120 may provide the identifier encrypted with the public key [..]the identifier may be a public key of a key pair, and the TEE 103 may return a shared key to the authentication application 120, encrypted with the identifier (public key),”; first identifier being associated with a public key)), (Figure 1A label 101, 103 and Par. (0092-0093); lightweight node (module of mobile device corresponding to lightweight)), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
b) a second identifier that is associated with at least a public key of the unenrolled lightweight node and a second signature created with at least at least the second identifier and a corresponding private key of the unenrolled lightweight node; and (Par. (0048-0050); request corresponding to identifiers and public key)) (Par. (0010) “second data indicative of an identifier generated by the web-service; in response to identifying a correspondence between the value and the identifier, [..] an authentication request to authenticate to the web-service to be accessed from the second computing device and, in association with the authentication request, authentication data”; authentication request including a second identifier (second data corresponding identifier associated with authentication request)), (Par. (0115) “For example, the UID repository 160 may store identifying information including one or more of user identifiers, device identifiers, identifying tokens for user or devices, locations of devices on a network, and the like. The UID repository 160 may also store associations between one or more identifiers, for example, a user identifier may be associated with one or more device identifiers to which that user is permitted access or otherwise uses to access the server.”; second identifier (one or more identifiers)), (Par. (0103) “the authentication application 120 may provide the identifier encrypted with the public key in a transmission to the TEE 103, and the identifier may serve as a shared key for encrypted data transmitted during the session. In some embodiments, the identifier may be a public key of a key pair, and the TEE 103 may return a shared key to the authentication application 120, encrypted with the identifier (public key),”; second identifier being associated with a public key)), (Par. (0048) “For example, a private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key.”; corresponding private key)), (Figure 1A label 101, 103 and Par. (0092-0093); lightweight node (module of mobile device corresponding to lightweight)), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified U.S Patent No. 12,107,966 to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of enhancing the authentication process to prevent illegitimate access of devices that are not registered to mitigate vulnerabilities, attacks on identity and attempts by sending information such as tokens, credentials and notification to registered devices using blockchain systems. (Avetisov Par. (0002-0004 and 0014))
As to claim 30, U.S Patent No. 12,107,966 does not disclose authenticating the first signature at least in part with the public key of the trusted node; and authenticating the second signature at least in part with the public key of the unenrolled node.
However Avetisov teaches authenticating the first signature at least in part with the public key of the trusted node; and (Par. (0058); verifying signature based on public key of trusted node (trusted execution environment of mobile device)
authenticating the second signature at least in part with the public key of the unenrolled node. (Par. (0269-0270); second signature (one or more signatures corresponding to public keys and unenrolled node (confirming registration of device)), (Par. (0058); verifying signature based on public key of trusted node (trusted execution environment of mobile device)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified U.S Patent No. 12,107,966 to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of using digital signatures, signed data and tokens to enhance a trusted environment and grant proper access based on data with indications. By verifying signatures with the corresponding keys a secure environment can be retained and used as form of comparison. (Avetisov Par. (0048 and 0055))
Furthermore, Claim 31 is rejected on the grounds of nonstatutory obviousness-type double patenting as being unpatentable over claim 12 of U.S Patent No. 12,107,966 in view of U.S Patent No. 20210044976 issued to Avetisov et al. further in view of U.S Patent No. 20200244652 issued to Iyer et al.
As to claim 31, U.S Patent No. 12,107,966 and Avetisov do not disclose responsive to successful authentication of the first and second signatures, creating a block that includes at least the authentication request,
However Iyer teaches responsive to successful authentication of the first and second signatures, (Par. (0158); validating signatures))
creating a block that includes at least the authentication request, (Par. (0146); validating signature then generating blocks in distributed ledger), (Par. (0125); authentication of the first and second signature (verifying digital signature of each block) with successful results that are affirmed of verification process))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified U.S Patent No. 12,107,966 and Avetisov to incorporate the teaching of Iyer to utilize the above feature because of the analogous concept of digital signature verification in blockchain system, with the motivation of creating multifactor authentication by verifying payloads and signature to return authentication results to users in blockchain network for assessment. (Yang Par. (0014 and 0125))
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 20, 23-26 and 28-30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bacher et al. (U.S Patent No. 20200372154, hereinafter referred to as “Bacher”) and Avetisov et al. (U.S Patent No. 20210044976, hereinafter referred to as “Avetisov”) further in view of Stöcker et al. (U.S Patent No. 20190393722, hereinafter referred to as “Stöcker”)
In regards to Claim 20, Bacher teaches a process for an unenrolled lightweight node having memory and a processor executing lightweight blockchain consensus instructions, (Par. (0098-0100); registering/ registration of Light nodes SN nodes start registration process)), (Par. (0027, 0047); consensus protocol of blockchain))
the unenrolled lightweight node connected on a decentralized network with at least a trusted node and a plurality of peers that include at least one enrolled lightweight node, (Par. (0080); SN light node with at least one security node i.e. SN full node and master node in blockchain)), (Par. (0098-0101); trusted node and a plurality of peers that include at least one enrolled lightweight node (during registration process trusted node (SN full nodes) with peers of unenrolled lightweight nodes (SN light nodes that are in registration process and awaiting successful registration))
the unenrolled lightweight node and the peers running a lightweight blockchain consensus algorithm, the process comprising: (Par. (0103); SN light node running on consensus protocol))
Bacher does not explicitly teach storing a token that includes a signature that includes at least a signature of at least a first identifier signed with a private key of the trusted node, the first identifier being associated with a public key of the unenrolled lightweight node; and broadcasting a request for blockchain enrollment of the unenrolled lightweight node to the plurality of peers, including to the at least one enrolled lightweight node, the authentication request including at least a second identifier that is associated with at least a public key of the unenrolled lightweight node, a signature created with at least the second identifier and a corresponding private key of the unenrolled lightweight node, and the token.
Wherein Avetisov teaches storing a token that includes a signature that includes at least a signature of at least a first identifier signed with a private key of the trusted node, (Par. (0120) “a token for one or more associated identifiers, and the server 145 may store the token within the UID repository 160 in association with one or more identifiers. [..] The token may include an associated timestamp or time-stamps that indicate when the token was created or when it expires. [..]The server 145 may determine, from information stored within the UID repository 160 in response to receiving a token from the client device 135, whether the received token matches a valid token received from the authentication server 155. The server 145 may also determine, from an association between the valid token and an identifier [..] to cryptographically hash a specific set (and optionally order) of determinable information received from or about the client device 135 to create an identifier.”; storing a token that includes a signature of at least a first identifier signed (storing token associated with identifier that is signed/hashed)), (Par. (0101) “the authentication application 120 may request the TEE 103 output signed data with a timestamp or include identifying information associated with a particular notification such that signed data may be considered valid for a particular notification or at a particular point in time to prohibit reuse.[..] one stored by the server during a registration process), and 3) signed 3) signed data, which may be a signature of an output data string of (1) and (2), e.g., {representation, notification ID or timestamp}, is verifiable by a public key provided by the TEE during a registration process.”; signature of a first identifier (signed data or signature corresponding to notification ID)), (Par. (0269); notification ID corresponding to User ID, credentials and identifying information of mobile device)), (Par. (0048) “For example, a private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key.”; signed with private key)), (Par. (0209); trusted node (mobile device with Trusted execution environment that has private key))
the first identifier being associated with a public key of the unenrolled lightweight node; and (Par. (0103) “the authentication application 120 may provide the identifier encrypted with the public key [..]the identifier may be a public key of a key pair, and the TEE 103 may return a shared key to the authentication application 120, encrypted with the identifier (public key),”; first identifier being associated with a public key)), (Figure 1A label 101, 103 and Par. (0092-0093); lightweight node (module of mobile device corresponding to lightweight)), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
the authentication request including at least a second identifier that is associated with at least a public key of the unenrolled lightweight node, a signature created with at least the second identifier and a corresponding private key of the unenrolled lightweight node, and the token. (Par. (0010) “second data indicative of an identifier generated by the web-service; in response to identifying a correspondence between the value and the identifier, [..] an authentication request to authenticate to the web-service to be accessed from the second computing device and, in association with the authentication request, authentication data”; authentication request including a second identifier (second data corresponding identifier associated with authentication request)), (Par. (0115) “For example, the UID repository 160 may store identifying information including one or more of user identifiers, device identifiers, identifying tokens for user or devices, locations of devices on a network, and the like. The UID repository 160 may also store associations between one or more identifiers, for example, a user identifier may be associated with one or more device identifiers to which that user is permitted access or otherwise uses to access the server.”; second identifier (one or more identifiers)), (Par. (0103) “the authentication application 120 may provide the identifier encrypted with the public key in a transmission to the TEE 103, and the identifier may serve as a shared key for encrypted data transmitted during the session. In some embodiments, the identifier may be a public key of a key pair, and the TEE 103 may return a shared key to the authentication application 120, encrypted with the identifier (public key),”; second identifier being associated with a public key)), (Par. (0048) “For example, a private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key.”; corresponding private key)), (Figure 1A label 101, 103 and Par. (0092-0093); lightweight node (module of mobile device corresponding to lightweight)), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of enhancing the authentication process to prevent illegitimate access of devices that are not registered to mitigate vulnerabilities, attacks on identity and attempts by sending information such as tokens, credentials and notification to registered devices using blockchain systems. (Avetisov Par. (0002-0004 and 0014))
Bacher and Avetisov do not explicitly teach broadcasting a request for blockchain enrollment of the unenrolled lightweight node to the plurality of peers, including to the at least one enrolled lightweight node,
Wherein Stöcker teaches broadcasting a request for blockchain enrollment of the unenrolled lightweight node to the plurality of peers, including to the at least one enrolled lightweight node, (Par. (0151-0152); broadcasting a request for blockchain enrollment (peer-to peer module transmitting registering request) to plurality of peers (peer-to-peer application 220), (Par. (0098); peer-to-peer module is light node)), (Par. (0027-0028); of the unenrolled lightweight node (process of registering nodes corresponding to peer-to-peer module by first sending registering request message), (Figure 2 labels 226.1 and 220; broadcasting a request for blockchain enrollment of the unenrolled lightweight node (unenrolled peer-to-peer module send registration request) to plurality of peers (registration request message sent to plurality of peer-to-peer modules 220), (Par. (0041); including to the at least one enrolled lightweight node, (already registered peer-to-peer modules))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher and Avetisov to incorporate the teaching of Stöcker to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system, with the motivation of preventing data being tampered and promoting high security by using blockchain network to preserve transactions and attest data based on registration process that containing identifying information. (Stöcker Par. (0008-0009, 0027 and 0101)
In regards to Claim 23, the combination of Bacher, Avetisov and Stöcker teach the process of claim 20, Avetisov further teaches wherein the signature with the private key of the trusted node was created by the first identifier, the public key of the unenrolled lightweight node, and a timestamp, each being signed with the private key of the trusted node; and (Par. (0120)”; a signature created by the first identifier (identifier that is signed/hashed)), (Par. (0101); signature created by the first identifier (signed data or signature corresponding to notification ID)), (Par. (0269); notification ID corresponding to User ID, credentials and identifying information of mobile device)), (Par. (0048)”; signed with private key)), (Par. (0209); trusted node (mobile device with Trusted execution environment that has private key)), (Par. (0186); certificate/signature includes public key, timestamp signed by private key)
wherein the signature with the private key of the unenrolled lightweight node was created with the second identifier, the token, and the public key of the unenrolled lightweight node being signed with the private key of the unenrolled lightweight node. (Par. (0055 and 0269); second signature (plurality of signatures verified), (Par. (0120); signature with token and identifier), (Par. (0186); certificate/signature includes public key, timestamp signed by private key), (Par (0269-0270); registration of user/computing node), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher and Stöcker to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of using digital signatures, signed data and tokens to enhance a trusted environment and grant proper access based on data with indications. By verifying signatures with the corresponding keys a secure environment can be retained and used as form of comparison. (Avetisov Par. (0048 and 0055))
In regards to Claim 24, the combination of Bacher, Avetisov and Stöcker teach the process of claim 20, Avetisov further teaches wherein the authentication request further includes the public key of the unenrolled lightweight node. (Par. (0010)”; authentication request including an identifier (second data corresponding identifier associated with authentication request)), ((Par. (0103) “the authentication application 120 may provide the identifier encrypted with the public key in a transmission to the TEE 103, and the identifier may serve as a shared key for encrypted data transmitted during the session. In some embodiments, the identifier may be a public key of a key pair, and the TEE 103 may return a shared key to the authentication application 120, encrypted with the identifier (public key),”; second identifier being associated with a public key)), (Par. (0055); authentication request (request for credentials for authentication application) includes public key of the unenrolled lightweight node (public key provided with request of TEE of mobile device)), (Figure 1A label 101, 103 and Par. (0092-0093); of the enrolled lightweight node (TEE module of mobile device corresponding to lightweight)), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher and Stöcker to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of creating a verification of proofs using public keys to indicate a successful or failed authentication and to help verify signatures as a form of comparison to disseminate public key encryption more effectively. (Avetisov Par. (0048 and 0079))
In regards to Claim 25, the combination of Bacher, Avetisov and Stöcker teach the process of claim 20, Avetisov further teaches receiving from at least one peer decentralized network a block for authentication and inclusion in a blockchain, (Par. (0285); entity in blockchain publishing transactions and blocks by consensus based on determined authentication))
the block including at least a transaction for enrollment of the unenrolled lightweight node, (Figure 2 labels 23; block with transaction 4)), (Par. (0285); block that is inclusion in a blockchain (published block with transaction) corresponding to unenrolled lightweight node (mobile device)), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
the transaction including at least the request for blockchain enrollment. (Par. (0054, 0232, 0251); request for blockchain enrollment.(registration process for devices) with transaction)), (Par. (0358-0360); transaction (record) in request for registration))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher and Stöcker to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of publishing and including block and transaction data into blockchain to create a better consensus and allow nodes to determine authentication based on committed records and better authenticate a user in decentralized system. (Avetisov Par. (0203-0204 and 0233))
In regards to Claim 26, the combination of Bacher, Avetisov and Stöcker teach the process of claim 20, Bacher further teaches the process of clam 25, further comprising utilizing the lightweight consensus algorithm to reach a consensus with the plurality of peers of the decentralized network, (Par. (0103); SN light node running on consensus protocol)), (Par. (0098-0101); with the plurality of peers of the decentralized network (SN light nodes that are in registration process and awaiting successful registration))
Bacher does not explicitly teach the consensus being a consensus to approve the block and to add the block to the blockchain or to reject the block and to not add the block to the blockchain.
Wherein Avetisov teaches the consensus being a consensus to approve the block and to add the block to the blockchain or to reject the block and to not add the block to the blockchain. (Par. (0023); consensus of nodes to commit and publication of transaction record))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher and Stöcker to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of implementing a consensus to publish validated transaction records and blocks into blockchain to allow plurality of nodes to identify verification results to trigger and flag possible invalid data and protect the impact and integrity of data. (Avetisov Par. (0245, 0249 and 0256))
In regards to Claim 28, the combination of Bacher, Avetisov and Stöcker teach the process of claim 20, Bacher further teaches the process of claim 20 further comprising receiving the token from the trusted node. (Par. (0050); trusted node (mobile computing device with trusted application) is provided results that include a token that is submitted))
In regards to Claim 29, Bacher teaches a process for an enrolled lightweight node having a memory and a processor executing lightweight blockchain consensus instructions on a decentralized network with at least one unenrolled lightweight node and one trusted node, process comprising: (Par. (0098-0100); registering/ registration of Light nodes SN nodes start registration process)), (Par. (0027, 0047); consensus protocol of blockchain)), (Par. (0080); SN light node with at least one security node i.e. SN full node and master node in blockchain)), (Par. (0098-0101); trusted node and at least one enrolled lightweight node (during registration process trusted node (SN full nodes) with peers of unenrolled lightweight nodes (SN light nodes that are in registration process and awaiting successful registration)), (Par. (0146); processor and memory))
receiving from the unenrolled lightweight node an authentication request that includes at least: (Par. (0098 and 0103); accepting a request from light node))
Bacher does not explicitly teach a) a token created with at least a first identifier signed with a private key of the trusted node, the first identifier being associated with a public key of the unenrolled lightweight node; and b) a second identifier that is associated with at least a public key of the unenrolled lightweight node and a second signature created with at least at least the second identifier and a corresponding private key of the unenrolled lightweight node; and broadcasting the authentication request to at least one other enrolled lightweight node of the decentralized network.
Wherein Avetisov teaches a) a token created with at least a first identifier signed with a private key of the trusted node, (Par. (0048-0050); transmitting request to entity associated with token, signature and identifier)), (Par. (0120) “a token for one or more associated identifiers, and the server 145 may store the token within the UID repository 160 in association with one or more identifiers. [..] The token may include an associated timestamp or time-stamps that indicate when the token was created or when it expires. [..]The server 145 may determine, from information stored within the UID repository 160 in response to receiving a token from the client device 135, whether the received token matches a valid token received from the authentication server 155. The server 145 may also determine, from an association between the valid token and an identifier [..] to cryptographically hash a specific set (and optionally order) of determinable information received from or about the client device 135 to create an identifier.”; storing a token that includes a signature of at least a first identifier signed (storing token associated with identifier that is signed/hashed)), (Par. (0101) “the authentication application 120 may request the TEE 103 output signed data with a timestamp or include identifying information associated with a particular notification such that signed data may be considered valid for a particular notification or at a particular point in time to prohibit reuse.[..] one stored by the server during a registration process), and 3) signed 3) signed data, which may be a signature of an output data string of (1) and (2), e.g., {representation, notification ID or timestamp}, is verifiable by a public key provided by the TEE during a registration process.”; signature of a first identifier (signed data or signature corresponding to notification ID)), (Par. (0269); notification ID corresponding to User ID, credentials and identifying information of mobile device)), (Par. (0048) “For example, a private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key.”; signed with private key)), (Par. (0209); trusted node (mobile device with Trusted execution environment that has private key))
the first identifier being associated with a public key of the unenrolled lightweight node; and (Par. (0103) “the authentication application 120 may provide the identifier encrypted with the public key [..]the identifier may be a public key of a key pair, and the TEE 103 may return a shared key to the authentication application 120, encrypted with the identifier (public key),”; first identifier being associated with a public key)), (Figure 1A label 101, 103 and Par. (0092-0093); lightweight node (module of mobile device corresponding to lightweight)), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
b) a second identifier that is associated with at least a public key of the unenrolled lightweight node and a second signature created with at least at least the second identifier and a corresponding private key of the unenrolled lightweight node; and (Par. (0048-0050); request corresponding to identifiers and public key)) (Par. (0010) “second data indicative of an identifier generated by the web-service; in response to identifying a correspondence between the value and the identifier, [..] an authentication request to authenticate to the web-service to be accessed from the second computing device and, in association with the authentication request, authentication data”; authentication request including a second identifier (second data corresponding identifier associated with authentication request)), (Par. (0115) “For example, the UID repository 160 may store identifying information including one or more of user identifiers, device identifiers, identifying tokens for user or devices, locations of devices on a network, and the like. The UID repository 160 may also store associations between one or more identifiers, for example, a user identifier may be associated with one or more device identifiers to which that user is permitted access or otherwise uses to access the server.”; second identifier (one or more identifiers)), (Par. (0103) “the authentication application 120 may provide the identifier encrypted with the public key in a transmission to the TEE 103, and the identifier may serve as a shared key for encrypted data transmitted during the session. In some embodiments, the identifier may be a public key of a key pair, and the TEE 103 may return a shared key to the authentication application 120, encrypted with the identifier (public key),”; second identifier being associated with a public key)), (Par. (0048) “For example, a private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key.”; corresponding private key)), (Figure 1A label 101, 103 and Par. (0092-0093); lightweight node (module of mobile device corresponding to lightweight)), (Par. (0008-0010); unenrolled lightweight node (registering the lightweight node (mobile device with lightweight))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of enhancing the authentication process to prevent illegitimate access of devices that are not registered to mitigate vulnerabilities, attacks on identity and attempts by sending information such as tokens, credentials and notification to registered devices using blockchain systems. (Avetisov Par. (0002-0004 and 0014))
Bacher and Avetisov do not explicitly teach broadcasting the authentication request to at least one other enrolled lightweight node of the decentralized network.
Wherein Stöcker teaches broadcasting the authentication request to at least one other enrolled lightweight node of the decentralized network. (Par. (0151-0152); broadcasting a request for blockchain enrollment (peer-to peer module transmitting registering request) to plurality of peers (peer-to-peer application 220), (Par. (0098); peer-to-peer module is light node)), (Par. (0027-0028); of the unenrolled lightweight node (process of registering nodes corresponding to peer-to-peer module by first sending registering request message), (Figure 2 labels 226.1 and 220; broadcasting a request for blockchain enrollment of the unenrolled lightweight node (unenrolled peer-to-peer module send registration request) to plurality of peers (registration request message sent to plurality of peer-to-peer modules 220), (Par. (0041); including to the at least one enrolled lightweight node, (already registered peer-to-peer modules))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher and Avetisov to incorporate the teaching of Stöcker to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system, with the motivation of preventing data being tampered and promoting high security by using blockchain network to preserve transactions and attest data based on registration process that containing identifying information. (Stöcker Par. (0008-0009, 0027 and 0101)
In regards to Claim 30, the combination of Bacher, Avetisov and Stöcker teach the process of claim 29, Avetisov further teaches authenticating the first signature at least in part with the public key of the trusted node; and (Par. (0058); verifying signature based on public key of trusted node (trusted execution environment of mobile device)
authenticating the second signature at least in part with the public key of the unenrolled node. (Par. (0269-0270); second signature (one or more signatures corresponding to public keys and unenrolled node (confirming registration of device)), (Par. (0058); verifying signature based on public key of trusted node (trusted execution environment of mobile device)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher and Stöcker to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of using digital signatures, signed data and tokens to enhance a trusted environment and grant proper access based on data with indications. By verifying signatures with the corresponding keys a secure environment can be retained and used as form of comparison. (Avetisov Par. (0048 and 0055))
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bacher et al. (U.S Patent No. 20200372154, hereinafter referred to as “Bacher”) Avetisov et al. (U.S Patent No. 20210044976, hereinafter referred to as “Avetisov”) and Stöcker et al. (U.S Patent No. 20190393722, hereinafter referred to as “Stöcker”) further in view of Wang et al. (U.S Patent No. 20210136042, hereinafter referred to as “Wang”)
In regards to Claim 21, the combination of Bacher, Avetisov and Stöcker do not explicitly teach wherein the first identifier includes at least a hash of the public key of the unenrolled lightweight node, and wherein the second identifier includes at least a hash of the public key of the unenrolled lightweight node.
Wherein Wang teaches wherein the first identifier includes at least a hash of the public key of the unenrolled lightweight node, and (Par. (0176); identifier of unenrolled lightweight node (DLS account) may be hash of public key)), (Par. (0043); of the unenrolled lightweight node (DLS corresponding to light DLN node of distributed ledger)), (Par. (0102, 0136-0137); unenrolled lightweight node (DLS registration of nodes)),
wherein the second identifier includes at least a hash of the public key of the unenrolled lightweight node. (Par. (0165-0166 and 0270); the second identifier (plurality of identifier corresponding to list of DLS and identifier with public key of each DLS)), (Par. (0176); identifier of unenrolled lightweight node (DLS account) may be hash of public key)), (Par. (0043); of the unenrolled lightweight node (DLS corresponding to light DLN node of distributed ledger)), (Par. (0102, 0136-0137); unenrolled lightweight node (DLS registration of nodes))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher and Avetisov, Stöcker to incorporate the teaching of Wang to utilize the above feature because of the analogous concept of hash-based verification and exchanging of keys using light nodes in a blockchain system, with the motivation of using light nodes and hashing of public keys to prevent single points of failure and tampering for only permissioned users as well as using identifier of records to indicate to nodes in the network confirmation. (Wang Par. (0050-0056 and 0119))
Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bacher et al. (U.S Patent No. 20200372154, hereinafter referred to as “Bacher”) Avetisov et al. (U.S Patent No. 20210044976, hereinafter referred to as “Avetisov”), Stöcker et al. (U.S Patent No. 20190393722, hereinafter referred to as “Stöcker”) and Wang et al. (U.S Patent No. 20210136042, hereinafter referred to as “Wang”) further in view of Pettit et al. (U.S Patent No. 20230006840, hereinafter referred to as “Pettit”)
In regards to Claim 22, the combination of Bacher, Avetisov, Stöcker and Wang do not explicitly teach wherein the hashes of the public key of the unenrolled lightweight node were created with a SHA-3 hash algorithm.
Wherein Pettit teaches wherein the hashes of the public key of the unenrolled lightweight node were created with a SHA-3 hash algorithm. (Par. (0042) “the address associated with a transaction output is a hash of a public key.”; hashes of the public key))(Par. (0037) “The result of a hash function may be called a hash value, fingerprint, hash result, or equivalent. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2.”; SHA-3 hash algorithm)), (Par. (0079) “This enables lightweight SPVs and similar nodes to collaborate with other nodes in generating transactions that incorporate automatic digital certificate validation”; 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 have modified Bacher, Avetisov, Stöcker and Wang to incorporate the teaching of Pettit to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain network, with the motivation of providing secure validation using public keys to easily verify data recorded on blockchain and hash based verification to determine accurate outputs and results. (Pettit Par. (0015-0016 and 0045))
Claim(s) 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bacher et al. (U.S Patent No. 20200372154, hereinafter referred to as “Bacher”) Avetisov et al. (U.S Patent No. 20210044976, hereinafter referred to as “Avetisov”) and Stöcker et al. (U.S Patent No. 20190393722, hereinafter referred to as “Stöcker”) further in view of Yang et al. (U.S Patent No. 20210160053, hereinafter referred to as “Yang”)
In regards to Claim 27, the combination of Bacher, Avetisov and Stöcker teach the process of claim 20, Bacher further teaches the process of claim 26, further comprising wherein the unenrolled lightweight node thereupon becomes enrolled in the decentralized network; and (Par. (0100); light nodes registering and successful registration in blockchain))
now enrolled lightweight node. (Par. (0100); light nodes registering and successful registration in blockchain))
Bacher does not explicitly teach adding the block to a blockchain responsive to a consensus to add the block to the blockchain, storing a block identifier of the block and an intermediate Merkle tree hash associated with the block in memory of the … lightweight node.
Wherein Avetisov teaches adding the block to a blockchain responsive to a consensus to add the block to the blockchain, (Par. (0023); consensus of nodes to commit and publication of transaction record))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher and Stöcker to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of implementing a consensus to publish validated transaction records and blocks into blockchain to allow plurality of nodes to identify verification results to trigger and flag possible invalid data and protect the impact and integrity of data. (Avetisov Par. (0245, 0249 and 0256))
Bacher, Avetisov and Stöcker do not explicitly teach storing a block identifier of the block and an intermediate Merkle tree hash associated with the block in memory of the … lightweight node.
Wherein Yang teaches storing a block identifier of the block and an intermediate Merkle tree hash associated with the block in memory of the … lightweight node. (Par. (0113); transaction identifier recorded on each node), (Par. (0084); light node with transaction and block identifier and Merkle tree)), (Par. (0036); an intermediate Merkle tree hash associated with the block in memory of the now enrolled lightweight node (root hash of merkle tree of block stored in light node))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher, Avetisov, and Stöcker to incorporate the teaching of Yang to utilize the above feature because of the analogous concept of lightweight nodes in a blockchain system and authentication using hashes and identifiers, with the motivation of preventing stolen secrets and damage to reputation using blockchain to record data and keep normal operations as well as using Merkle paths and hashes to enhance verification and a form of comparison when deeming successful blocks in network. (Yang Par. (0003-0005 and 0036-0039))
Claim(s) 31-32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bacher et al. (U.S Patent No. 20200372154, hereinafter referred to as “Bacher”), Avetisov et al. (U.S Patent No. 20210044976, hereinafter referred to as “Avetisov”) and Stöcker et al. (U.S Patent No. 20190393722, hereinafter referred to as “Stöcker”) further in view of Iyer et al. (U.S Patent No. 20200244652, hereinafter referred to as “Iyer”)
In regards to Claim 31, the combination of Bacher, Avetisov and Stöcker teach the process of claim 29, Avetisov further teaches utilizing the lightweight blockchain consensus algorithm for reaching consensus regarding whether to accept or reject the block. (Par. (0023); consensus of nodes to commit and publication of transaction record))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher and Stöcker to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of implementing a consensus to publish validated transaction records and blocks into blockchain to allow plurality of nodes to identify verification results to trigger and flag possible invalid data and protect the impact and integrity of data. (Avetisov Par. (0245, 0249 and 0256))
Bacher, Avetisov and Stöcker do not explicitly teach responsive to successful authentication of the first and second signatures, creating a block that includes at least the authentication request, and
Wherein Iyer teaches responsive to successful authentication of the first and second signatures, (Par. (0158); validating signatures))
creating a block that includes at least the authentication request, and (Par. (0146); validating signature then generating blocks in distributed ledger), (Par. (0125); authentication of the first and second signature (verifying digital signature of each block) with successful results that are affirmed of verification process))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher, Avetisov and Stöcker to incorporate the teaching of Iyer to utilize the above feature because of the analogous concept of digital signature verification in blockchain system, with the motivation of creating multifactor authentication by verifying payloads and signature to return authentication results to users in blockchain network for assessment. (Yang Par. (0014 and 0125))
In regards to Claim 32, the combination of Bacher, Avetisov and Stöcker teach the process of claim 29, Bacher further teaches the process of claim 31, further comprising: wherein the unenrolled lightweight node thereupon becomes enrolled in the decentralized network. (Par. (0100); light nodes registering and successful registration in blockchain))
Bacher does not explicitly teach adding the block to a block chain responsive to a consensus to add the block to the blockchain,
Wherein Avetisov teaches adding the block to a block chain responsive to a consensus to add the block to the blockchain, (Par. (0023); consensus of nodes to commit and publication of transaction record))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher, Stöcker and Iyer to incorporate the teaching of Avetisov to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using consensus protocol, with the motivation of implementing a consensus to publish validated transaction records and blocks into blockchain to allow plurality of nodes to identify verification results to trigger and flag possible invalid data and protect the impact and integrity of data. (Avetisov Par. (0245, 0249 and 0256))
Claim(s) 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bacher et al. (U.S Patent No. 20200372154, hereinafter referred to as “Bacher”), Avetisov et al. (U.S Patent No. 20210044976, hereinafter referred to as “Avetisov”) and Stöcker et al. (U.S Patent No. 20190393722, hereinafter referred to as “Stöcker”) further in view of Nandakumar et al. (U.S Patent No. 20200201964, hereinafter referred to as “Nandakumar”)
In regards to Claim 33, the combination of Bacher, Avetisov and Stöcker do not explicitly teach wherein the at least one enrolled node is configured to store at least a lightweight blockchain with at least one block with a block header that includes a data Merkle root computed at least in part from a least one Merkle tree node containing a hash value computed directly or indirectly from a hash value computed from a combination of a public key and a validity value for the public key.
Wherein Nandakumar teaches wherein the at least one enrolled node is configured to store at least a lightweight blockchain with at least one block with a block header that includes a data Merkle root computed at least in part from a least one Merkle tree node containing a hash value computed directly or indirectly from a hash value computed from a combination of a public key and a validity value for the public key. (Par. (0105-0106); at least one enrolled node (blockchain with enrolling users as nodes), (Par. (0161 and 0163); lightweight blockchain (thin client corresponding to blockchain)), (Par. (0056); store at least a lightweight blockchain with at least one block with a block header that includes a data Merkle root (storing in block of blockchain root from nodes of merkle tree)), (Par. (0075); store at least a lightweight blockchain with at least one block with a block header that includes a data Merkle root computed at least in part from a least one Merkle tree node (transaction of blockchain with root hashes of nodes from merkle tree)), (Par. (0044); block headers with hash)), (Par. (0069-0075); Merkle tree with leaf nodes that contain hash value (chameleon hash) that is computed directly from a hash value computed from a combination of a public key and a validity value for the public key. (chameleon hash includes public key and validity value (number “-1” of chameleon hash))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Bacher, Avetisov and Stöcker to incorporate the teaching of Nandakumar to utilize the above feature because of the analogous concept of enrolling lightweight nodes in a blockchain system using digital signatures and verifications, with the motivation of making sure all nodes are consistent in the blockchain with blocks that link hashes and append to blockchain more efficiently. (Nandakumar Par. (0044))
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
CONLEY; JOHN P. (U.S Pub. No. 20210073212) “BLOCKCHAIN METHODS, NODES, SYSTEMS AND PRODUCTS”. Considered this reference because it addressed enrolling nodes in a blockchain environment using token based verification.
RUIZ; Emmanuel. (U.S Pub. No. 20210073795) “DEVICE FOR STORING DIGITAL KEYS FOR SIGNING TRANSACTIONS ON A BLOCKCHAIN”. Considered this application because it relates hashing or digitally signing keys in a blockchain network using SHA-3 hashing algorithms
WATANABE; Hiroshi (U.S Pub. No. 20230370264) “IC CHIP WITH AUTO-IDENTIFICATION”. Considered this application because it addressed registering devices in a blockchain network.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HASSAN A HUSSEIN whose telephone number is (571)272-3554. The examiner can normally be reached on 7:30am-5pm.
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, Eleni Shiferaw can be reached on (571)272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HASSAN A HUSSEIN/ Examiner, Art Unit 2497
Prosecution Insights