DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed on 01/12/2026
Claims 1, 4-9, 12, and 16 are currently amended
Claims 2 and 3 are cancelled
Claims 21 and 22 are newly added
Claims 1 and 4-22 are pending
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
Examiner has fully considered Applicant’s amendments to the Claims in the arguments filed on 01/12/2026. Claims 2 and 3 have been cancelled and claims 21 and 22 are newly added. Claims 1 and 4-22 remain pending in the application.
Response to Arguments
Applicant’s arguments filed 01/12/2026, with respect to the rejections of claims 1, 3, 6, and 7
under 35 USC 103 have been fully considered and are persuasive. Therefore, the
rejections have been withdrawn. However, upon further consideration, new grounds of rejection are
made in view of the previously applied references from Yi, Kaizer, and Kaizer ‘889, in addition to the previously applied reference from Bai. Specifically, Bai is sufficient to teach the amended limitations “wherein the blockchain includes one or more forks, a plurality of layers that are each fork associated with a particular top-level domain, of one or more top-level domains” and “a fork, of the one or more forks, that is associated with a top-level domain, of the one or more top-level domains, corresponding to a top-level domain associated with the domain being registered”. It is additionally submitted that Bai is sufficient to teach the claim 1 limitations previously rejected based on teachings from Roennow.
Applicant’s arguments with respect to the rejections of claims 8 and 10-13 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new grounds of rejection are made in view of the previously applied references from Salman, Kaizer, Roennow, and Yi, in addition to the previously applied reference from Bai. Specifically, Bai is sufficient to teach the amended limitations “wherein the blockchain includes one or more forks, each fork associated with a particular top-level domain, of one or more top-level domains” and “a fork, of the one or more forks”.
Applicant’s arguments with respect to the rejections of claims 15-19 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new grounds of rejection are made in view of the previously applied references from Salman, Kaizer, Glasser, and Roennow, in addition to the previously applied reference from Bai. Specifically, Bai is sufficient to teach the amended limitations “wherein the blockchain includes one or more forks, each fork associated with a particular top-level domain, of one or more top-level domains” and “a fork, of the one or more forks”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 6, and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yi (WO 2019221468 A1), hereinafter Yi, in view of Kaizer (US 11632236 B1), hereinafter Kaizer, Kaizer et al. (US 20220376889 A1), hereinafter Kaizer ‘889, and Bai (FI 20215009 A1), hereinafter Bai.
Regarding Claim 1:
Yi teaches a method, comprising (Yi – P. 2: The present invention relates to a personal domain name service method and system for extracting and providing additional information matching a personal domain name using the personal domain description) receiving, by a device, a request to register a domain (Yi – P. 3: The method includes: receiving, by a domain management server, a domain registration request message from the user terminal) on a blockchain (Yi – P. 3: The method may further include generating and storing the blockchain in the blockchain. The storing in the blockchain may include determining whether a block including the private domain name, the destination public key, and the user public key is already stored in the blockchain, if the blockchain network is not stored. A new block can be created and stored in the blockchain) wherein the request includes data that indicates: a public key for with the domain (Yi – P. 3: the domain registration request message including a personal domain name, additional information, a destination public key, and an electronic signature); and a unique identifier associated with the domain (Yi – P. 3: the domain registration request message including a personal domain name, additional information, a destination public key, and an electronic signature); and generating, by the device, a domain information block based on the request (Yi – P. 3: Generating, by the domain management server, a domain registration transaction in the blockchain network including the private domain name, the destination public key, the additional information, and the electronic signature; And the blockchain network obtains a user public key by verifying an electronic signature included in the domain registration transaction, and extracts a new block including the user public key, the private domain name, the destination public key, and the additional information. The method may further include generating and storing the block(chain) in the blockchain), wherein the domain information block includes the public key for with the domain (Yi – P. 3: a new block including the user public key, the private domain name, the destination public key, and the additional information) and providing, by the device … the domain information block to a set of blockchain nodes to add the domain information block (Yi – P. 3: the blockchain network obtains a user public key by verifying an electronic signature included in the domain registration transaction, and extracts a new block including the user public key, the private domain name, the destination public key, and the additional information; and P. 4: The blockchain network 500 is connected to a plurality of nodes and performs verification of a transaction. In addition, each node belonging to the blockchain network 500 performs a verification on this transaction when a transaction occurs; Examiner’s Comment: The completion of the domain registration transaction includes the provision of the newly generated block to the blockchain network of nodes to be added to the blockchain upon verification by the nodes).
Yi does not expressly teach and a blockchain identifier that is based on the unique identifier associated with the domain.
However, Kaizer teaches and a blockchain identifier that is based on the unique identifier associated with the domain (Kaizer – Col. 34, Lines 9-11: FIG. 11 is a flowchart of a method 1100 for assigning subdomains as blockchain addresses according to various embodiments; and Col. 34, Lines 19-26: By way of non-limiting example, method 1100 is shown and described herein as associating the domain name name.tld with the blockchain address 0x0123, associating the subdomain name personal.name.tld with the blockchain address 0x4567, and associating the subdomain name business.name.tld with the blockchain address 0x8910. However, any second-level domain name and subdomains may be used; and Col. 35, Lines 5-10: At block 1110, the blockchain smart contract calls the blockchain name services program to generate a record for the domain name name.tld. The blockchain name services program may further set the owner of name.tld as the blockchain address of the blockchain smart contract as part of this block; Examiner’s Comment: Examiner submits that this teaching from Kaizer expresses that a domain name (or, more specifically, a subdomain name) may be assigned as a blockchain address. Therefore, the subdomain name taught by Kaizer may serve as both the blockchain identifier and the unique identifier on which the blockchain identifier is based. The blockchain address taught by Kaizer may also be considered “a blockchain identifier that is based on the unique identifier associated with the domain”). It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Yi, further incorporating Kaizer to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kaizer’s teaching to include a blockchain identifier based on an identifier of a domain in each domain information block into Yi’s method for registering a domain on a blockchain to a requesting device. This combined functionality enhances Yi’s method by adding more traceability for data added to the blockchain.
The combination of Yi and Kaizer does not expressly teach and providing, by the device and based on a domain expiration event indicated in the domain information block, the domain information block to a set of blockchain nodes.
However, Kaizer ‘889 teaches and providing, by the device and based on a domain expiration event indicated in the domain information block, the domain information block to a set of blockchain nodes (Kaizer ‘889 – Paragraph [0167]: an association of a blockchain address with a domain name may have an expiration in the blockchain. The expiration may indicate that the domain name is available for registration in the DNS environment … expiration may open the ability for a new registrant to register the domain in the DNS environment ... Using embodiments as disclosed herein, after expiration, any entity can remove the stale association in the blockchain; and Paragraph [0138]: the extended Renew command may update an expiration datum for an association of the domain name with a blockchain address as recorded in the blockchain environment. For example, some blockchains may store an expiration, e.g., in terms of date and time, for each stored association of a domain name with a blockchain address; and Paragraph [0146]: per method 600 for renewing an association, blockchain directory 110 implements 356 the instruction to renew any blockchain address associations with the provided domain name. The actions of implementing 356 the instruction may be include updating one or more expirations of the association. The updated expirations may represent expirations of the registration of the domain name, for example).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Yi and Kaizer, further incorporating Kaizer ‘889 to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kaizer ‘889’s addition of new domain information blocks to a blockchain based on some expiration event associated with the domain into Yi and Kaizer’s method for registering a domain on a blockchain to a requesting device. This addition provides further context and situational applicability of the method acting responsive to domain expirations, potentially accounting for protection against replay attacks by former registrants of expired associations.
The combination of Yi, Kaizer and Kaizer ‘889 does not expressly teach wherein the blockchain includes one or more forks, each fork associated with a particular top-level domain, of one or more top-level domains; and … add the domain information block to a fork, of the one or more forks, that is associated with a top-level domain, of the one or more top-level domains, corresponding to a top-level domain associated with the domain being registered.
However, Bai teaches wherein the blockchain includes one or more forks, each fork associated with a particular top-level domain, of one or more top-level domains (Bai – Figure 1: a structural diagram of a smart-contract based domain name management service, including forks that branch based on TLDs); and … add the domain information block to a fork, of the one or more forks, that is associated with a top-level domain, of the one or more top-level domains, corresponding to a top-level domain associated with the domain being registered (Bai – Paragraph [0052]: The nodes in which the root domain contract is deployed are further configured to: receive a registration transaction, and initiate, based on the registration transaction, a voting transaction to a plurality of nodes in which the root domain contract is deployed. The plurality of nodes in which the root domain contract is deployed are further configured to: return a voting result based on the voting transaction, and accept or reject a newly added domain name corresponding to the registration transaction based on statistical voting results. Finally, the nodes in which the root domain contract is deployed are further configured to: generate a top-level domain contract based on the registration transaction, newly add record data corresponding to the registration transaction to the root domain contract, and record the top-level domain contract and the record data into a subchain block; and Paragraph [0060]: For example, for a top-level domain service (TLD), in an actual registration — process, a transaction may be first initiated to a root domain contract to trigger the root domain contract to be executed; and then root domain contract owners decide whether to accept the TLD domain name through voting or other manners. The root domain contract owners choose to accept or reject the TLD domain name by initiating a transaction to the root domain contract. If the registration is accepted, the new addition transaction succeeds, a new TLD contract is generated and deployed based on the root domain contract, and a corresponding record pointing to the new TLD contract is newly added to the root domain contract, to complete a process of the new addition).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Yi, Kaizer, and Kaizer ‘889, further incorporating Bai to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bai’s addition of new domain information blocks to a blockchain based on the top-level domain with which the to-be-registered domain name is associated into Yi, Kaizer, and Kaizer ‘889’s method for registering a domain on a blockchain to a requesting device. Bai’s teachings provide structural organization to the domain name blockchain for efficiency in processing new domain registrations as well as accessing existing domain information.
Regarding Claim 6:
Yi, Kaizer, Kaizer ‘889, and Bai combine to teach the method of Claim 1.
Bai further teaches at least one of the one or more forks (Bai – Figure 1: a structural diagram of a smart-contract based domain name management service, including forks that branch based on TLDs).
Kaizer ‘889 further teaches [at least one of the one or more forks is] associated with one or more domain expiration events. (Kaizer ‘889 – Paragraph [0167]: an association of a blockchain address with a domain name may have an expiration in the blockchain. The expiration may indicate that the domain name is available for registration in the DNS environment … expiration may open the ability for a new registrant to register the domain in the DNS environment ... Using embodiments as disclosed herein, after expiration, any entity can remove the stale association in the blockchain; and Paragraph [0138]: the extended Renew command may update an expiration datum for an association of the domain name with a blockchain address as recorded in the blockchain environment. For example, some blockchains may store an expiration, e.g., in terms of date and time, for each stored association of a domain name with a blockchain address; and Paragraph [0146]: per method 600 for renewing an association, blockchain directory 110 implements 356 the instruction to renew any blockchain address associations with the provided domain name. The actions of implementing 356 the instruction may be include updating one or more expirations of the association. The updated expirations may represent expirations of the registration of the domain name, for example).
The motivation to combine the arts is the same as that of claim 1.
Regarding Claim 7:
Yi, Kaizer, Kaizer ‘889, and Bai combine to teach the method of Claim 6.
Bai further teaches wherein the domain information block is added to the fork (Bai – Figure 1: a structural diagram of a smart-contract based domain name management service, including forks that branch based on TLDs; and Paragraph [0052]: The nodes in which the root domain contract is deployed are further configured to: receive a registration transaction, and initiate, based on the registration transaction, a voting transaction to a plurality of nodes in which the root domain contract is deployed. The plurality of nodes in which the root domain contract is deployed are further configured to: return a voting result based on the voting transaction, and accept or reject a newly added domain name corresponding to the registration transaction based on statistical voting results. Finally, the nodes in which the root domain contract is deployed are further configured to: generate a top-level domain contract based on the registration transaction, newly add record data corresponding to the registration transaction to the root domain contract, and record the top-level domain contract and the record data into a subchain block).
Kaizer ‘889 further teaches based on the domain expiration event associated with the domain being registered corresponding to a domain expiration event included in the one or more domain expiration events associated with the [fork] (Kaizer ‘889 – Paragraph [0167]: an association of a blockchain address with a domain name may have an expiration in the blockchain. The expiration may indicate that the domain name is available for registration in the DNS environment … expiration may open the ability for a new registrant to register the domain in the DNS environment ... Using embodiments as disclosed herein, after expiration, any entity can remove the stale association in the blockchain; and Paragraph [0138]: the extended Renew command may update an expiration datum for an association of the domain name with a blockchain address as recorded in the blockchain environment. For example, some blockchains may store an expiration, e.g., in terms of date and time, for each stored association of a domain name with a blockchain address; and Paragraph [0146]: per method 600 for renewing an association, blockchain directory 110 implements 356 the instruction to renew any blockchain address associations with the provided domain name. The actions of implementing 356 the instruction may be include updating one or more expirations of the association. The updated expirations may represent expirations of the registration of the domain name, for example).
The motivation to combine the arts is the same as that of Claim 1.
Claim(s) 4 and 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yi, in view of Kaizer, Kaizer ‘889, Bai, and Rahardja (AU 2021100212 A4), hereinafter Rahardja.
Regarding Claim 4:
Yi, Kaizer, Kaizer ‘889, and Bai combine to teach the method of Claim 1.
Kaizer further teaches blockchain identifiers (Kaizer – Col. 34, Lines 9-11: FIG. 11 is a flowchart of a method 1100 for assigning subdomains as blockchain addresses according to various embodiments; and Col. 34, Lines 19-26: By way of non-limiting example, method 1100 is shown and described herein as associating the domain name name.tld with the blockchain address 0x0123, associating the subdomain name personal.name.tld with the blockchain address 0x4567, and associating the subdomain name business.name.tld with the blockchain address 0x8910. However, any second-level domain name and subdomains may be used; and Col. 35, Lines 5-10: At block 1110, the blockchain smart contract calls the blockchain name services program to generate a record for the domain name name.tld. The blockchain name services program may further set the owner of name.tld as the blockchain address of the blockchain smart contract as part of this block; Examiner’s Comment: The blockchain address taught by Kaizer is interpreted as the claimed blockchain identifier).
The combination of Yi, Kaizer, Kaizer ‘889, and Bai does not expressly teach wherein each of the one or more forks is associated with a particular range of blockchain identifiers.
However, Rahardja teaches wherein each of the one or more forks (Rahardja – P. 9: The fork block 203 allows the chain to be forked such that both the genesis chain and the fork chain are considered valid chains) is associated with a particular range of [blockchain identifiers] (Rahardja – P. 9: The fork block 203 is special because it works like a standard block, but additionally includes a reference identifying the first block, or root block 204, in the valid fork. In one embodiment of the present invention, the new protocol, Rules_2, is stored as the payload of the fork block and applied to the root block 204 and each subsequent standard block that chains from the root block 204; and P. 9: The Rules_1, Rules_2, and other protocols are not defined by this specification, but defined by users of the system at runtime. These protocols are customizable based on a scripting, or programming language. According to one embodiment, a new protocol can only be defined for a forked chain and the original protocol remains fixed and applied to the genesis chain; Examiner’s Comment: Rahardja is sufficient to teach a blockchain having multiple forks which are defined by having separate protocols for adding new blocks to each forked chain. Examiner submits that one of ordinary skill in the art will appreciate that the protocols defining the different forked layers are arbitrary with regard to the novelty of this invention, as a skilled user would be granted the capability to establish their own protocols for adding blocks to each forked chain, according to Rahardja. For example, a user could associate each forked layer of the blockchain with a certain range of blockchain identifiers).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Yi, Kaizer, Kaizer ‘889, and Bai, further incorporating Rahardja to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Rahardja’s teaching of a forked blockchain capable of supporting multiple forked chains with differing protocols for adding new blocks to each chain into Yi, Kaizer, Kaizer ‘889, and Bai’s combined method for registering a domain on a blockchain to a requesting device. This combination would allow the blockchain to functionally include different layers which could have different requirements for adding new blocks to each of the layers.
Regarding Claim 5:
Yi, Kaizer, Kaizer ‘889, Bai, and Rahardja combine to teach the method of Claim 4.
Yi further teaches wherein the domain information block is added (Yi – P. 3: the blockchain network obtains a user public key by verifying an electronic signature included in the domain registration transaction, and extracts a new block including the user public key, the private domain name, the destination public key, and the additional information; and P. 4: The blockchain network 500 is connected to a plurality of nodes and performs verification of a transaction. In addition, each node belonging to the blockchain network 500 performs a verification on this transaction when a transaction occurs; Examiner’s Comment: The completion of the domain registration transaction includes the provision of the newly generated block to the blockchain network of nodes to be added to the blockchain upon verification by the nodes); and the domain being registered (Yi – P. 3: Generating, by the domain management server, a domain registration transaction in the blockchain network including the private domain name, the destination public key, the additional information, and the electronic signature).
Kaizer further teaches based on the blockchain identifier associated with the domain (Kaizer – Col. 34, Lines 9-11: FIG. 11 is a flowchart of a method 1100 for assigning subdomains as blockchain addresses according to various embodiments; and Col. 34, Lines 19-26: By way of non-limiting example, method 1100 is shown and described herein as associating the domain name name.tld with the blockchain address 0x0123, associating the subdomain name personal.name.tld with the blockchain address 0x4567, and associating the subdomain name business.name.tld with the blockchain address 0x8910. However, any second-level domain name and subdomains may be used; and Col. 35, Lines 5-10: At block 1110, the blockchain smart contract calls the blockchain name services program to generate a record for the domain name name.tld. The blockchain name services program may further set the owner of name.tld as the blockchain address of the blockchain smart contract as part of this block; Examiner’s Comment: Examiner submits that this teaching from Kaizer expresses that a domain name (or, more specifically, a subdomain name) may be assigned as a blockchain address).
Bai further teaches block is added to the fork (Bai – Figure 1: a structural diagram of a smart-contract based domain name management service, including forks that branch based on TLDs; and Paragraph [0052]: The nodes in which the root domain contract is deployed are further configured to: receive a registration transaction, and initiate, based on the registration transaction, a voting transaction to a plurality of nodes in which the root domain contract is deployed. The plurality of nodes in which the root domain contract is deployed are further configured to: return a voting result based on the voting transaction, and accept or reject a newly added domain name corresponding to the registration transaction based on statistical voting results. Finally, the nodes in which the root domain contract is deployed are further configured to: generate a top-level domain contract based on the registration transaction, newly add record data corresponding to the registration transaction to the root domain contract, and record the top-level domain contract and the record data into a subchain block).
Rahardja further teaches block is added to the fork based on … the domain being registered being within the particular range of blockchain identifiers associated with the fork (Rahardja – P. 9: The Rules_1, Rules_2, and other protocols are not defined by this specification, but defined by users of the system at runtime. These protocols are customizable based on a scripting, or programming language. According to one embodiment, a new protocol can only be defined for a forked chain and the original protocol remains fixed and applied to the genesis chain; Examiner’s Comment: Examiner submits that one of ordinary skill in the art will appreciate that the protocols defining the different forked layers are arbitrary with regard to the novelty of this invention. For example, a user could associate each forked layer of the blockchain with a certain range of blockchain identifiers).
The motivation to combine the arts is the same as that of Claim 4.
Claim(s) 8 and 10-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Salman (US 20210021597 A1), hereinafter Salman, in view of Kaizer, Roennow, Yi, and Bai.
Regarding Claim 8:
Salman teaches a device, comprising: one or more processors configured to (Salman – Paragraph [0060]: Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code components executed by one or more computer systems or computer processors comprising computer hardware): receive a first message from a client device (Salman – Paragraph [0035]: At operation 420, an authentication challenge message is transmitted from the authentication server system 200 to the client device 100), wherein the first message indicates a random parameter (Salman – Paragraph [0036]: The authentication challenge message may include a randomly generated string); generate, using a private key, a digital signature based on the random parameter (Salman – Paragraph [0036]: The client device 100 may respond by creating a response message including a signature created using private key 113 associated with the client blockchain address 112. For example, a signature may be created by using the private key 113 to apply a hash function to the randomly generated string or the randomly generated string and a secret value); provide, to the client device, a second message that indicates: the digital signature (Salman – Paragraph [0037]: the authentication server 200 receives a response to the challenge message including the signature); and a blockchain identifier (Salman – Paragraph [0037]: the authentication server 200 receives a response to the challenge message including the signature. For example, a response 103 as depicted in FIG. 1 may be transmitted. As discussed above, the signature may be created using the private key 113 of the client device 100 associated with client blockchain address 112); wherein the blockchain identifier enables the client device to retrieve the public key [associated with the domain] from a blockchain (Salman – Paragraph [0038]: authentication server system 200 may use blockchain network 300 to determine if the private key used by the client device to sign the challenge message (e.g., private key 113) is associated with the blockchain address (e.g., blockchain address 112) transmitted by the client device by attempting to verify the signed response to the challenge message using a public key (e.g., public key 114) corresponding to the blockchain address. Given the response message, the signature, and retrieved public key, authentication server system 200 may determine the authenticity of the response) and to validate the digital signature using the public key (Salman – Paragraph [0038]: authentication server system 200 may use blockchain network 300 to determine if the private key used by the client device to sign the challenge message (e.g., private key 113) is associated with the blockchain address (e.g., blockchain address 112) transmitted by the client device by attempting to verify the signed response to the challenge message using a public key (e.g., public key 114) corresponding to the blockchain address. Given the response message, the signature, and retrieved public key, authentication server system 200 may determine the authenticity of the response); based on the client device validating the digital signature using the public key (Salman – Paragraph [0039]: Upon successful validation of the signature, the authentication server 200 may deem the authentication as successful and allow network access to the client device 100 … as depicted by FIG. 1, depending upon whether the signature was successfully validated, a grant/denial of network access 104 may occur).
**Examiner’s Comment: The above limitations of Claim 8 are described throughout the specification as being carried out by a client device. However, the claimed client device and other device or network device are attributed no special capability or discerning quality which functionally distinguish one from the others. Therefore, Examiner submits that the authentication processes can be performed both ways between any devices having access to the same blockchain.
Salman does not expressly teach a blockchain identifier that is based on a unique identifier associated with a domain that corresponds to the device, wherein the blockchain identifier corresponds to a domain information block … based on a top-level domain associated with the domain.
However, Kaizer teaches a blockchain identifier that is based on a unique identifier associated with a domain that corresponds to the device (Kaizer – Col. 34, Lines 9-11: FIG. 11 is a flowchart of a method 1100 for assigning subdomains as blockchain addresses according to various embodiments; and Col. 34, Lines 19-26: By way of non-limiting example, method 1100 is shown and described herein as associating the domain name name.tld with the blockchain address 0x0123, associating the subdomain name personal.name.tld with the blockchain address 0x4567, and associating the subdomain name business.name.tld with the blockchain address 0x8910. However, any second-level domain name and subdomains may be used; and Col. 35, Lines 5-10: At block 1110, the blockchain smart contract calls the blockchain name services program to generate a record for the domain name name.tld. The blockchain name services program may further set the owner of name.tld as the blockchain address of the blockchain smart contract as part of this block; Examiner’s Comment: Examiner submits that this teaching from Kaizer expresses that a domain name (or, more specifically, a subdomain name) may be assigned as a blockchain address. Therefore, the subdomain name taught by Kaizer may serve as both the blockchain identifier and the unique identifier on which the blockchain identifier is based. The blockchain address taught by Kaizer may also be considered “a blockchain identifier that is based on the unique identifier associated with the domain”), wherein the blockchain identifier corresponds to a domain information block … based on a top- level domain associated with the domain (Kaizer – Col. 17, Line 25-38: registry 102 may submit to the blockchain network for inclusion in the blockchain a message that includes the top-level domain name(s) (e.g., dot com, dot net, dot edu, etc.) for which registration is handled by registry 102 and the blockchain address of the signature verification program 106, signed by the private key of the blockchain key pair of registry 102. The message may be submitted to the blockchain network for inclusion in a block to indicate that registry 102 has, in a blockchain transaction sense, conveyed ownership of the top-level domain name to the registry proof verification program at the provided blockchain address, at least for purposes of assigning domain names under the top-level domain name as blockchain addresses in the blockchain network; and Col. 33, Line 65-67 and Col. 34, Line 1-6: As used herein, the term “second-level domain name” means a domain name that includes both a top-level domain name and a domain name directly below a top-level domain name. For example, example.com is a second-level domain name. Further as used herein, the term “subdomain” means a domain name that includes a top-level domain name, a domain name directly below a top-level domain name, and at least one additional domain name below a domain name directly below a top-level domain name; and Col. 35, Lines 5-10: At block 1110, the blockchain smart contract calls the blockchain name services program to generate a record for the domain name name.tld. The blockchain name services program may further set the owner of name.tld as the blockchain address of the blockchain smart contract as part of this block).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, further incorporating Kaizer to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kaizer’s teaching to include a blockchain identifier based on an identifier of a domain in each domain information block which is added to the blockchain based on a top-level domain associated therewith into Salman’s system for registering a domain on a blockchain to a requesting device. This combined functionality enhances Salman’s system by adding more traceability for data added to the blockchain, supporting further convenience and efficiency in tracking and identifying records of ownership.
The combination of Salman and Kaizer does not expressly teach store, on a blockchain, … a public key associated with a domain; a/the public key associated with the domain; and perform a secure communication protocol with the client device.
However, Roennow teaches store, on a blockchain, … a public key associated with a domain that corresponds to the device (Roennow – Paragraph [0020]: recording a domain security transaction, comprising the domain public key, to the blockchain to generate a domain name record comprising the domain name, an associated IP address, the domain public key and the domain certificate information, wherein the domain security transaction being signed using the domain primary key); the public key associated with the domain (Roennow – Paragraph [0020]: recording a domain security transaction, comprising the domain public key, to the blockchain to generate a domain name record comprising the domain name, an associated IP address, the domain public key and the domain certificate information, wherein the domain security transaction being signed using the domain primary key); and perform a secure communication protocol with the client device (Roennow – Paragraph [0225]: The client node 221 transmits a domain name request 222 to a domain name node 230 relating to the server node 215. The domain name request 222 may comprise at least one of the following: a domain name and an IP address associated with the domain name of the server node 215. In response to the received domain name request 222, the domain name node 230 transmits, to the client node 221, a domain name response 223. The domain name response 223 comprises the domain public key, the domain certificate information and the associated IP address retrieved from the domain name record of the blockchain system 200. After that a secure communication between the client node 221 and the server node 215 may be initiated using at least one of the domain public key and the domain certificate information).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman and Kaizer, further incorporating Roennow to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Roennow’s teaching of a domain public key for use in device authentication enabling secure communication into Salman and Kaizer’s system for registering a domain on a blockchain to a requesting device. This combination establishes a domain as a credential for authenticating devices for the purpose of secure communication or transactions among the blockchain.
The combination of Salman, Kaizer, and Roennow does not expressly teach store, on a blockchain, a public key associated with the device and a public key associated with a domain that corresponds to the device.
However, Yi teaches store, on a blockchain, a public key associated with the device and a public key associated with a domain that corresponds to the device (Yi – P. 3: the blockchain network obtains a user public key by verifying an electronic signature included in the domain registration transaction, and extracts a new block including the user public key, the private domain name, the destination public key, and the additional information. The method may further include generating and storing the block(chain) in the blockchain; Examiner’s Comment: the user public key is interpreted as the claimed “public key associated with the device” and the destination public key is interpreted as the claimed “public key associated with a domain that corresponds to the device”).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, Kaizer, and Roennow, further incorporating Yi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Yi’s teaching to store a device public key with a public key associated with a domain on a blockchain into Salman, Kaizer, and Roennow’s system for registering a domain on a blockchain to a requesting device. This addition would further bolster the security of the system by associating a device public key with a public key associated with a domain for verifying ownership and transactions involving that domain.
The combination of Salman, Kaizer, Roennow, and Yi does not expressly teach wherein the blockchain includes one or more forks, each fork associated with a particular top-level domain, of one or more top-level domains; and block included in a fork, of the one or more forks, based on a top-level domain associated with the domain.
However, Bai teaches wherein the blockchain includes one or more forks, each fork associated with a particular top-level domain, of one or more top-level domains (Bai – Figure 1: a structural diagram of a smart-contract based domain name management service, including forks that branch based on TLDs); and block included in a fork, of the one or more forks, based on a top-level domain associated with the domain (Bai – Paragraph [0052]: The nodes in which the root domain contract is deployed are further configured to: receive a registration transaction, and initiate, based on the registration transaction, a voting transaction to a plurality of nodes in which the root domain contract is deployed. The plurality of nodes in which the root domain contract is deployed are further configured to: return a voting result based on the voting transaction, and accept or reject a newly added domain name corresponding to the registration transaction based on statistical voting results. Finally, the nodes in which the root domain contract is deployed are further configured to: generate a top-level domain contract based on the registration transaction, newly add record data corresponding to the registration transaction to the root domain contract, and record the top-level domain contract and the record data into a subchain block; and Paragraph [0060]: For example, for a top-level domain service (TLD), in an actual registration — process, a transaction may be first initiated to a root domain contract to trigger the root domain contract to be executed; and then root domain contract owners decide whether to accept the TLD domain name through voting or other manners. The root domain contract owners choose to accept or reject the TLD domain name by initiating a transaction to the root domain contract. If the registration is accepted, the new addition transaction succeeds, a new TLD contract is generated and deployed based on the root domain contract, and a corresponding record pointing to the new TLD contract is newly added to the root domain contract, to complete a process of the new addition).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, Kaizer, Roennow, and Yi, further incorporating Bai to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bai’s addition of new domain information blocks to a blockchain based on the top level domain with which the to-be-registered domain name is associated into Salman, Kaizer, Roennow, and Yi’s device for registering a domain on a blockchain to a requesting device. Bai’s teachings provide structural organization to the domain name blockchain for efficiency in processing new domain registrations as well as accessing existing domain information.
Regarding Claim 10:
The combination of Salman, Kaizer, Roennow, Yi, and Bai teaches the device of Claim 8.
Kaizer further teaches wherein the unique identifier is a domain name (Kaizer – Col. 18, Lines 27-33: The domain name assignment method 200 may be initiated by registrant 202 by requesting 206 assignment of a specified domain name that is registered to registrant 202 and, for method 200 according to some embodiments, a blockchain address to which to assign the domain name. Registrant 202 may send a request message with this data to registrar 104).
The motivation to combine the arts is the same as that of Claim 8.
Regarding Claim 11:
The combination of Salman, Kaizer, Roennow, Yi, and Bai teaches the device of Claim 8.
Kaizer further teaches wherein the unique identifier is based on information provided by an owner of the domain to a domain name registrar (Kaizer – Col. 18, Lines 27-33: The domain name assignment method 200 may be initiated by registrant 202 by requesting 206 assignment of a specified domain name that is registered to registrant 202 and, for method 200 according to some embodiments, a blockchain address to which to assign the domain name. Registrant 202 may send a request message with this data to registrar 104), and wherein the information is stored in a domain name registry associated with the domain name registrar (Kaizer – Col. 18, Lines 44-49: Next, per method 200, registry 102 confirms 210 that the registrar that sent the request is the registrar of record for the provided domain name, e.g., using the originating IP address of the request, to identify the requesting registrar. Registry 102 may check the IP address (or other identifier) against its stored registrar records).
The motivation to combine the arts is the same as that of Claim 8.
Regarding Claim 12:
The combination of Salman, Kaizer, Roennow, Yi, and Bai teaches the device of Claim 8.
Yi further teaches wherein the public key associated with the domain is included in the domain information block (Yi – P. 3: the blockchain network obtains a user public key by verifying an electronic signature included in the domain registration transaction, and extracts a new block including the user public key, the private domain name, the destination public key, and the additional information. The method may further include generating and storing the block(chain) in the blockchain).
The motivation to combine the arts is the same as that of Claim 8.
Regarding Claim 13:
The combination of Salman, Kaizer, Roennow, Yi, and Bai teaches the device of Claim 8.
Roennow further teaches wherein the public key associated with the domain is bound to an identity associated with an owner of the domain (Roennow – Paragraph [0148]: a secure de-centralized domain name system 100 further comprises a domain name node 130 for recording a domain registration transaction to a blockchain 170, the domain registration transaction comprising a domain name, a domain primary key and domain certificate information for a server node 110. The domain primary key may correspond to the public key of the intended domain owner, for example).
The motivation to combine the arts is the same as that of Claim 8.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Salman, in view of Kaizer, Roennow, Yi, Bai, and Glasser (US 20210109902 A1), hereinafter Glasser.
Regarding Claim 9:
The combination of Salman, Kaizer, Roennow, Yi, and Bai teaches the device of Claim 8.
Roennow further teaches the domain information block (Roennow – Paragraph [0020]: recording a domain security transaction, comprising the domain public key, to the blockchain to generate a domain name record comprising the domain name, an associated IP address, the domain public key and the domain certificate information, wherein the domain security transaction being signed using the domain primary key).
The combination of Salman, Kaizer, Roennow, Yi, and Bai does not expressly teach wherein the blockchain identifier enables the client device to retrieve the unique identifier from the domain information block and validate the unique identifier based on information.
However, Glasser teaches wherein the blockchain identifier enables the client device to retrieve the unique identifier from the [domain information] block (Glasser – Paragraph [0044]: the blockchain manager then receives the block record identifier (typically a sequential number) for added block 250 from the blockchain, which represents the location of the data block in the blockchain … After the new block is attached to the chain and the reference number for the block is known, the computer authenticates the new block record number with the DNS manager 270, verifying that the reference number is not already in-use. When this is accomplished, a new DNS entry is created in which the “domain name” contains persona information to make it searchable, including block number on the blockchain and any other relevant non-sensitive data 280, such as the person's legal name or the organization or individual performing the biometric template creation, for ease of searching, for instance “Encoder=8 KHZ acoustic data; Location=10099.”) and validate the unique identifier based on information (Glasser – Paragraph [0044]: This record is propagated using known techniques 290 for DNS propagation. After a block is propagated, and the DNS record is propagated, both with the pertinent and correct information, a user may be identified through this system by entering claimed identification credentials similar to those stored unencrypted in the DNS file such as “Encoder=8 KHZ acoustic data; Location=10099,” have their identification matched against a DNS record, at which time the DNS record may be pulled and the information about the matching block in the blockchain is also made available. The block may then be requested from the blockchain and the data decrypted using the method it was originally used to encrypt it depending on the vendor or operator of the system, and the data may be verified using existing biometric techniques at this point) that is stored in a domain name registry (Glasser – Paragraph [0043]: The purpose and function of a DNS manager 125 is to communicate with a network-connected biometric DNS 145 and to maintain a local repository of DNS references 130; Examiner’s Comment: the local repository of DNS references 130 is interpreted to represent a domain name registry).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, Kaizer, Roennow, Yi, and Bai, further incorporating Glasser to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Glasser’s teaching to use a blockchain identifier to retrieve information from a blockchain in order to validate that information into Salman, Kaizer, Roennow, Yi, and Bai’s system for registering a domain on a blockchain to a requesting device. This combined functionality would increase the system’s efficiency in identifying and verifying records stored on the blockchain.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Salman, in view of Kaizer, Roennow, Yi, Bai, and Kaizer ‘889.
Regarding Claim 14:
The combination of Salman, Kaizer, Roennow, Yi, and Bai teaches the device of Claim 8.
Yi further teaches a domain information block on the blockchain (Yi – P. 3: the blockchain network obtains a user public key by verifying an electronic signature included in the domain registration transaction, and extracts a new block including the user public key, the private domain name, the destination public key, and the additional information. The method may further include generating and storing the block(chain) in the blockchain); and the domain information block (Yi – P. 3: the blockchain network obtains a user public key by verifying an electronic signature included in the domain registration transaction, and extracts a new block including the user public key, the private domain name, the destination public key, and the additional information. The method may further include generating and storing the block(chain) in the blockchain).
The combination of Salman, Kaizer, Roennow, Yi, and Bai does not expressly teach wherein the domain information block includes information that indicates an expiration event associated with the domain.
However, Kaizer ‘889 teaches and wherein the domain information block includes information that indicates an expiration event associated with the domain (Kaizer ‘889 – Paragraph [0167]: an association of a blockchain address with a domain name may have an expiration in the blockchain. The expiration may indicate that the domain name is available for registration in the DNS environment … expiration may open the ability for a new registrant to register the domain in the DNS environment ... Using embodiments as disclosed herein, after expiration, any entity can remove the stale association in the blockchain; and Paragraph [0138]: the extended Renew command may update an expiration datum for an association of the domain name with a blockchain address as recorded in the blockchain environment. For example, some blockchains may store an expiration, e.g., in terms of date and time, for each stored association of a domain name with a blockchain address; and Paragraph [0146]: per method 600 for renewing an association, blockchain directory 110 implements 356 the instruction to renew any blockchain address associations with the provided domain name. The actions of implementing 356 the instruction may be include updating one or more expirations of the association. The updated expirations may represent expirations of the registration of the domain name, for example).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, Kaizer, Roennow, Yi, and Bai, further incorporating Kaizer ‘889 to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kaizer ‘889’s teaching to incorporate domain expiration events into domain information blocks on the blockchain into Salman, Kaizer, Roennow, Yi, and Bai’s combined method for registering a domain on a blockchain to a requesting device. This combination would ensure that the domain records on the blockchain were up to date and continuously verified.
Claim(s) 15-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Salman, in view of Kaizer, Glasser, Roennow, and Bai.
Regarding Claim 15:
Salman teaches a non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that (Salman – Paragraph [0054]: In this document, the terms “machine readable medium,” “computer readable medium,” and similar terms are used to generally refer to non-transitory mediums, volatile or non-volatile, that store data and/or instructions that cause a machine to operate in a specific fashion), when executed by one or more processors of a client device, cause the client device to (Salman – Paragraph [0055]: These and other various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to a processing device for execution. Such instructions embodied on the medium, are generally referred to as “instructions” or “code.” Instructions may be grouped in the form of computer programs or other groupings. When executed, such instructions may enable a processing device to perform features or functions of the present application as discussed herein): provide a first message to a network device, wherein the first message indicates a random parameter (Salman – Paragraph [0035]: At operation 420, an authentication challenge message is transmitted from the authentication server system 200 to the client device 100; and Paragraph [0036]: The authentication challenge message may include a randomly generated string); receive, from the network device, a second message, wherein the second message includes a digital signature based on the random parameter (Salman – Paragraph [0036]: The client device 100 may respond by creating a response message including a signature created using private key 113 associated with the client blockchain address 112. For example, a signature may be created by using the private key 113 to apply a hash function to the randomly generated string or the randomly generated string and a secret value; and Paragraph [0037]: the authentication server 200 receives a response to the challenge message including the signature) and a blockchain identifier (Salman – Paragraph [0034]: the authentication server system 200 receives a blockchain address transmitted by the client device 100 during network access authentication, the blockchain address corresponding to a blockchain network. For example, device 100 may provide a stored client blockchain address 112 in conjunction with network access request 101 as its identity for authentication purposes) and a public key [for the domain] from a blockchain based on the blockchain identifier (Salman – Paragraph [0038]: authentication server system 200 may use blockchain network 300 to determine if the private key used by the client device to sign the challenge message (e.g., private key 113) is associated with the blockchain address (e.g., blockchain address 112) transmitted by the client device by attempting to verify the signed response to the challenge message using a public key (e.g., public key 114) corresponding to the blockchain address. Given the response message, the signature, and retrieved public key, authentication server system 200 may determine the authenticity of the response); and the digital signature, wherein the digital signature is verified using the public key (Salman – Paragraph [0038]: authentication server system 200 may use blockchain network 300 to determine if the private key used by the client device to sign the challenge message (e.g., private key 113) is associated with the blockchain address (e.g., blockchain address 112) transmitted by the client device by attempting to verify the signed response to the challenge message using a public key (e.g., public key 114) corresponding to the blockchain address. Given the response message, the signature, and retrieved public key, authentication server system 200 may determine the authenticity of the response); and authenticate the network device based on verifying the [domain name and] the digital signature (Salman – Paragraph [0039]: Upon successful validation of the signature, the authentication server 200 may deem the authentication as successful and allow network access to the client device 100).
**Examiner’s Comment: The above limitations of Claim 15 are described throughout the specification as being carried out by a client device. However, the claimed client device and other device or network device are attributed no special capability or discerning quality which functionally distinguish one from the others. Therefore, Examiner submits that the authentication processes can be performed both ways between any devices having access to the same blockchain.
Salman does not expressly teach a blockchain identifier associated with a domain that corresponds to the network device; and wherein the blockchain identifier corresponds to a domain information block …based on a top-level domain associated with the domain.
However, Kaizer teaches a blockchain identifier associated with a domain that corresponds to the network device (Kaizer – Col. 34, Lines 9-11: FIG. 11 is a flowchart of a method 1100 for assigning subdomains as blockchain addresses according to various embodiments; and Col. 34, Lines 19-26: By way of non-limiting example, method 1100 is shown and described herein as associating the domain name name.tld with the blockchain address 0x0123, associating the subdomain name personal.name.tld with the blockchain address 0x4567, and associating the subdomain name business.name.tld with the blockchain address 0x8910. However, any second-level domain name and subdomains may be used; and Col. 35, Lines 5-10: At block 1110, the blockchain smart contract calls the blockchain name services program to generate a record for the domain name name.tld. The blockchain name services program may further set the owner of name.tld as the blockchain address of the blockchain smart contract as part of this block; Examiner’s Comment: Examiner submits that this teaching from Kaizer expresses that a domain name (or, more specifically, a subdomain name) may be assigned as a blockchain address. Therefore, the subdomain name taught by Kaizer may serve as both the blockchain identifier and the unique identifier on which the blockchain identifier is based. The blockchain address taught by Kaizer may also be considered “a blockchain identifier that is based on the unique identifier associated with the domain”); and wherein the blockchain identifier corresponds to a domain information block …based on a top-level domain associated with the domain (Kaizer – Col. 17, Line 25-38: registry 102 may submit to the blockchain network for inclusion in the blockchain a message that includes the top-level domain name(s) (e.g., dot com, dot net, dot edu, etc.) for which registration is handled by registry 102 and the blockchain address of the signature verification program 106, signed by the private key of the blockchain key pair of registry 102. The message may be submitted to the blockchain network for inclusion in a block to indicate that registry 102 has, in a blockchain transaction sense, conveyed ownership of the top-level domain name to the registry proof verification program at the provided blockchain address, at least for purposes of assigning domain names under the top-level domain name as blockchain addresses in the blockchain network; and Col. 33, Line 65-67 and Col. 34, Line 1-6: As used herein, the term “second-level domain name” means a domain name that includes both a top-level domain name and a domain name directly below a top-level domain name. For example, example.com is a second-level domain name. Further as used herein, the term “subdomain” means a domain name that includes a top-level domain name, a domain name directly below a top-level domain name, and at least one additional domain name below a domain name directly below a top-level domain name; and Col. 35, Lines 5-10: At block 1110, the blockchain smart contract calls the blockchain name services program to generate a record for the domain name name.tld. The blockchain name services program may further set the owner of name.tld as the blockchain address of the blockchain smart contract as part of this block). It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, further incorporating Kaizer to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kaizer’s teaching to establish an association between a blockchain identifier and a device domain, the identifier corresponding to a domain information block added to the blockchain based on a top-level domain into Salman’s instructions for registering a domain on a blockchain to a requesting device. Kaizer’s additional teachings provide the method with traceability for domain data stored on the blockchain.
The combination of Salman and Kaizer does not expressly teach obtain a domain name … based on the blockchain identifier.
However, Glasser teaches obtain a domain name … based on the blockchain identifier (Glasser – Paragraph [0044]: the blockchain manager then receives the block record identifier (typically a sequential number) for added block 250 from the blockchain, which represents the location of the data block in the blockchain … After the new block is attached to the chain and the reference number for the block is known, the computer authenticates the new block record number with the DNS manager 270, verifying that the reference number is not already in-use. When this is accomplished, a new DNS entry is created in which the “domain name” contains persona information to make it searchable, including block number on the blockchain and any other relevant non-sensitive data 280, such as the person's legal name or the organization or individual performing the biometric template creation, for ease of searching, for instance “Encoder=8 KHZ acoustic data; Location=10099.”).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman and Kaizer, further incorporating Glasser to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Glasser’s teaching to use a blockchain identifier to retrieve information from a blockchain in order to validate that information into Salman and Kaizer’s combined instructions for registering a domain on a blockchain to a requesting device. This combined functionality would increase a system’s efficiency in identifying and verifying records stored on the blockchain.
The combination of Salman, Kaizer, and Glasser does not expressly teach a public key for the domain; verify the domain name; and authenticate the network device based on verifying the domain name.
However, Roennow teaches a public key for the domain (Roennow – Paragraph [0095]: transmit, to the client node, a domain name response from the domain name node, the domain name response comprising the domain public key, the domain certificate information and the associated IP address retrieved from the domain name record of the blockchain; and Paragraph [0020]: recording a domain security transaction, comprising the domain public key, to the blockchain to generate a domain name record comprising the domain name, an associated IP address, the domain public key and the domain certificate information, wherein the domain security transaction being signed using the domain primary key); verify the domain name (Roennow – Paragraph [0220]: Like regular transactions in cryptocurrencies, domain address, domain name and domain public key pairs need to get confirmations from other nodes 210-230 during new block generation for the blockchain; and Paragraph [0223]: In an embodiment, after the server node 210 related registration and certification transactions 211, 212 are validated and associated domain information updated to the domain name record in the blockchain system 200, secure communication between the server node 210 and the client node 220 is enabled; and Table 2: representation of a domain security transaction including information to be validated by the blockchain prior to secure communication between nodes in the blockchain network); and authenticate the network device based on verifying the domain name (Roennow – Paragraph [0220]: Like regular transactions in cryptocurrencies, domain address, domain name and domain public key pairs need to get confirmations from other nodes 210-230 during new block generation for the blockchain; and Paragraph [0223]: In an embodiment, after the server node 210 related registration and certification transactions 211, 212 are validated and associated domain information updated to the domain name record in the blockchain system 200, secure communication between the server node 210 and the client node 220 is enabled; and Table 2: representation of a domain security transaction including information to be validated by the blockchain prior to secure communication between nodes in the blockchain network).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, Kaizer, and Glasser, further incorporating Roennow to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Roennow’s layered blockchain structure, in addition to the teaching to use a registered domain name as a credential for device verification into Salman, Kaizer, and Glasser’s combined instructions for registering a domain on a blockchain to a requesting device. These additional elements would enhance the organization and security of the system by incorporating another degree into authorizing participating parties.
The combination of Salman, Kaizer, Glasser, and Roennow does not expressly teach wherein the blockchain includes one or more forks, each fork associated with a particular top-level domain, of one or more top-level domains; and block included in a fork, of the one or more forks, based on a top-level domain associated with the domain.
However, Bai teaches wherein the blockchain includes one or more forks, each fork associated with a particular top-level domain, of one or more top-level domains (Bai – Figure 1: a structural diagram of a smart-contract based domain name management service, including forks that branch based on TLDs); and block included in a fork, of the one or more forks, based on a top-level domain associated with the domain (Bai – Paragraph [0052]: The nodes in which the root domain contract is deployed are further configured to: receive a registration transaction, and initiate, based on the registration transaction, a voting transaction to a plurality of nodes in which the root domain contract is deployed. The plurality of nodes in which the root domain contract is deployed are further configured to: return a voting result based on the voting transaction, and accept or reject a newly added domain name corresponding to the registration transaction based on statistical voting results. Finally, the nodes in which the root domain contract is deployed are further configured to: generate a top-level domain contract based on the registration transaction, newly add record data corresponding to the registration transaction to the root domain contract, and record the top-level domain contract and the record data into a subchain block; and Paragraph [0060]: For example, for a top-level domain service (TLD), in an actual registration — process, a transaction may be first initiated to a root domain contract to trigger the root domain contract to be executed; and then root domain contract owners decide whether to accept the TLD domain name through voting or other manners. The root domain contract owners choose to accept or reject the TLD domain name by initiating a transaction to the root domain contract. If the registration is accepted, the new addition transaction succeeds, a new TLD contract is generated and deployed based on the root domain contract, and a corresponding record pointing to the new TLD contract is newly added to the root domain contract, to complete a process of the new addition).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, Kaizer, Glasser, and Roennow, further incorporating Bai to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bai’s addition of new domain information blocks to a blockchain based on the top level domain with which the to-be-registered domain name is associated into Salman, Kaizer, Glasser, and Roennow’s mechanism for registering a domain on a blockchain to a requesting device. Bai’s teachings provide structural organization to the domain name blockchain for efficiency in processing new domain registrations as well as accessing existing domain information.
Regarding Claim 16:
The combination of Salman, Kaizer, Glasser, Roennow, and Bai teaches the non-transitory computer-readable medium of claim 15, wherein the one or more instructions, that cause the client device to obtain the domain name and the public key associated with the domain from the blockchain based on the blockchain identifier.
Glasser further teaches cause the client device to: retrieve the domain name … from the [domain information] block (Glasser – Paragraph [0044]: the blockchain manager then receives the block record identifier (typically a sequential number) for added block 250 from the blockchain, which represents the location of the data block in the blockchain … After the new block is attached to the chain and the reference number for the block is known, the computer authenticates the new block record number with the DNS manager 270, verifying that the reference number is not already in-use. When this is accomplished, a new DNS entry is created in which the “domain name” contains persona information to make it searchable, including block number on the blockchain and any other relevant non-sensitive data 280, such as the person's legal name or the organization or individual performing the biometric template creation, for ease of searching, for instance “Encoder=8 KHZ acoustic data; Location=10099.”).
Salman further teaches retrieve … the public key from the [domain information] block (Salman – Paragraph [0038]: authentication server system 200 may use blockchain network 300 to determine if the private key used by the client device to sign the challenge message (e.g., private key 113) is associated with the blockchain address (e.g., blockchain address 112) transmitted by the client device by attempting to verify the signed response to the challenge message using a public key (e.g., public key 114) corresponding to the blockchain address. Given the response message, the signature, and retrieved public key, authentication server system 200 may determine the authenticity of the response).
Roennow further teaches the domain information block (Roennow – Paragraph [0020]: recording a domain security transaction, comprising the domain public key, to the blockchain to generate a domain name record comprising the domain name, an associated IP address, the domain public key and the domain certificate information, wherein the domain security transaction being signed using the domain primary key).
The motivation to combine the arts is the same as that of Claim 15.
Regarding Claim 17:
The combination of Salman, Kaizer, Glasser, Roennow, and Bai teaches the non-transitory computer-readable medium of claim 15.
Salman further teaches wherein the one or more instructions (Salman – Paragraph [0054]: In this document, the terms “machine readable medium,” “computer readable medium,” and similar terms are used to generally refer to non-transitory mediums, volatile or non-volatile, that store data and/or instructions that cause a machine to operate in a specific fashion).
Roennow further teaches that cause the client device to verify the domain, cause the client device to (Roennow – Paragraph [0220]: Like regular transactions in cryptocurrencies, domain address, domain name and domain public key pairs need to get confirmations from other nodes 210-230 during new block generation for the blockchain; and Paragraph [0223]: In an embodiment, after the server node 210 related registration and certification transactions 211, 212 are validated and associated domain information updated to the domain name record in the blockchain system 200, secure communication between the server node 210 and the client node 220 is enabled; and Table 2: representation of a domain security transaction including information to be validated by the blockchain prior to secure communication between nodes in the blockchain network): determine that the domain name is stored in a domain name registry (Roennow – Paragraph [0222]: In an embodiment, the Domain Name System (DNS) based blockchain system 200 is running on a permissioned chain; and Paragraph [0223]: In an embodiment, after the server node 210 related registration and certification transactions 211, 212 are validated and associated domain information updated to the domain name record in the blockchain system 200, secure communication between the server node 210 and the client node 220 is enabled; Examiner’s Comment: the validation of at least the security transaction 212 taught by Roennow serves as an affirmation that the domain name is stored in the Domain Name System based blockchain system 200, which is interpreted to represent a domain name registry); and verify the domain name (Roennow – Paragraph [0220]: Like regular transactions in cryptocurrencies, domain address, domain name and domain public key pairs need to get confirmations from other nodes 210-230 during new block generation for the blockchain; and Paragraph [0223]: In an embodiment, after the server node 210 related registration and certification transactions 211, 212 are validated and associated domain information updated to the domain name record in the blockchain system 200, secure communication between the server node 210 and the client node 220 is enabled; and Table 2: representation of a domain security transaction including information to be validated by the blockchain prior to secure communication between nodes in the blockchain network) based on determining that the domain name is stored in the domain name registry (Roennow – Paragraph [0222]: In an embodiment, the Domain Name System (DNS) based blockchain system 200 is running on a permissioned chain; and Paragraph [0223]: In an embodiment, after the server node 210 related registration and certification transactions 211, 212 are validated and associated domain information updated to the domain name record in the blockchain system 200, secure communication between the server node 210 and the client node 220 is enabled).
The motivation to combine the arts is the same as that of Claim 15.
Regarding Claim 18:
The combination of Salman, Kaizer, Glasser, Roennow, and Bai teaches the non-transitory computer-readable medium of claim 15.
Roennow further teaches wherein the public key is bound to an identity associated with an owner of the domain (Roennow – Paragraph [0238]: In an embodiment, a node identifier is assigned to each node 210,215,220-221,230 of the trusted domain system 200, wherein the node identifier may comprise a public key).
The motivation to combine the arts is the same as that of Claim 15.
Regarding Claim 19:
The combination of Salman, Kaizer, Glasser, Roennow, and Bai teaches the non-transitory computer-readable medium of claim 15.
Kaizer further teaches wherein the domain name is stored in a domain name registry associated with a domain name registrar (Kaizer – Col. 18, Lines 44-49: Next, per method 200, registry 102 confirms 210 that the registrar that sent the request is the registrar of record for the provided domain name, e.g., using the originating IP address of the request, to identify the requesting registrar. Registry 102 may check the IP address (or other identifier) against its stored registrar records).
The motivation to combine the arts is the same as that of Claim 15.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Salman, in view of Kaizer, Glasser, Roennow, Bai, and Kaizer ‘889.
Regarding Claim 20:
The combination of Salman, Kaizer, Glasser, Roennow, and Bai teaches the non-transitory computer-readable medium of claim 15.
Roennow further teaches a domain information block that is on the blockchain (Roennow – Paragraph [0020]: recording a domain security transaction, comprising the domain public key, to the blockchain to generate a domain name record comprising the domain name, an associated IP address, the domain public key and the domain certificate information, wherein the domain security transaction being signed using the domain primary key).
The combination of Salman, Kaizer, Glasser, Roennow, and Bai does not expressly teach wherein the domain information block includes information that indicates a domain expiration event associated with the domain.
However, Kaizer 889’ teaches wherein the domain information block includes information that indicates a domain expiration event associated with the domain (Kaizer ‘889 – Paragraph [0167]: an association of a blockchain address with a domain name may have an expiration in the blockchain. The expiration may indicate that the domain name is available for registration in the DNS environment … expiration may open the ability for a new registrant to register the domain in the DNS environment ... Using embodiments as disclosed herein, after expiration, any entity can remove the stale association in the blockchain; and Paragraph [0138]: the extended Renew command may update an expiration datum for an association of the domain name with a blockchain address as recorded in the blockchain environment. For example, some blockchains may store an expiration, e.g., in terms of date and time, for each stored association of a domain name with a blockchain address; and Paragraph [0146]: per method 600 for renewing an association, blockchain directory 110 implements 356 the instruction to renew any blockchain address associations with the provided domain name. The actions of implementing 356 the instruction may be include updating one or more expirations of the association. The updated expirations may represent expirations of the registration of the domain name, for example).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, Kaizer, Glasser, Roennow, and Bai, further incorporating Kaizer ‘889 to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kaizer ‘889’s teaching to incorporate domain expiration events in domain information blocks on the blockchain into Salman, Kaizer, Glasser, Roennow, and Bai’s combined instructions for registering a domain on a blockchain to a requesting device. This combination would ensure that the domain records on the blockchain were up to date and continuously verified.
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Salman, in view of Kaizer, Roennow, Yi, Bai, and Rahardja.
Regarding Claim 21:
The combination of Salman, Kaizer, Roennow, Yi, and Bai teaches the device of claim 8.
Yi further teaches wherein the domain information block is included (Yi – P. 3: the blockchain network obtains a user public key by verifying an electronic signature included in the domain registration transaction, and extracts a new block including the user public key, the private domain name, the destination public key, and the additional information; and P. 4: The blockchain network 500 is connected to a plurality of nodes and performs verification of a transaction. In addition, each node belonging to the blockchain network 500 performs a verification on this transaction when a transaction occurs; Examiner’s Comment: The completion of the domain registration transaction includes the provision of the newly generated block to the blockchain network of nodes to be added to the blockchain upon verification by the nodes).
Kaizer further teaches based on the blockchain identifier (Kaizer – Col. 34, Lines 9-11: FIG. 11 is a flowchart of a method 1100 for assigning subdomains as blockchain addresses according to various embodiments; and Col. 34, Lines 19-26: By way of non-limiting example, method 1100 is shown and described herein as associating the domain name name.tld with the blockchain address 0x0123, associating the subdomain name personal.name.tld with the blockchain address 0x4567, and associating the subdomain name business.name.tld with the blockchain address 0x8910. However, any second-level domain name and subdomains may be used; and Col. 35, Lines 5-10: At block 1110, the blockchain smart contract calls the blockchain name services program to generate a record for the domain name name.tld. The blockchain name services program may further set the owner of name.tld as the blockchain address of the blockchain smart contract as part of this block; Examiner’s Comment: Examiner submits that this teaching from Kaizer expresses that a domain name (or, more specifically, a subdomain name) may be assigned as a blockchain address).
Bai further teaches block is included in the fork (Bai – Figure 1: a structural diagram of a smart-contract based domain name management service, including forks that branch based on TLDs; and Paragraph [0052]: The nodes in which the root domain contract is deployed are further configured to: receive a registration transaction, and initiate, based on the registration transaction, a voting transaction to a plurality of nodes in which the root domain contract is deployed. The plurality of nodes in which the root domain contract is deployed are further configured to: return a voting result based on the voting transaction, and accept or reject a newly added domain name corresponding to the registration transaction based on statistical voting results. Finally, the nodes in which the root domain contract is deployed are further configured to: generate a top-level domain contract based on the registration transaction, newly add record data corresponding to the registration transaction to the root domain contract, and record the top-level domain contract and the record data into a subchain block).
The combination of Salman, Kaizer, Roennow, Yi, and Bai does not expressly teach block is included in the fork based on the blockchain identifier being within a range of blockchain identifiers that are particular to the fork.
However, Rahardja teaches block is included in the fork based on the blockchain identifier being within a range of blockchain identifiers that are particular to the fork (Rahardja – P. 9: The Rules_1, Rules_2, and other protocols are not defined by this specification, but defined by users of the system at runtime. These protocols are customizable based on a scripting, or programming language. According to one embodiment, a new protocol can only be defined for a forked chain and the original protocol remains fixed and applied to the genesis chain; Examiner’s Comment: Examiner submits that one of ordinary skill in the art will appreciate that the protocols defining the different forked layers are arbitrary with regard to the novelty of this invention. For example, a user could associate each forked layer of the blockchain with a certain range of blockchain identifiers).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, Kaizer, Roennow, Yi, and Bai, further incorporating Rahardja to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Rahardja’s teaching of a forked blockchain capable of supporting multiple forked chains with differing protocols for adding new blocks to each chain into Salman, Kaizer, Roennow, Yi, and Bai’s combined method for registering a domain on a blockchain to a requesting device. This combination would allow the blockchain to functionally include different layers which could have different requirements for adding new blocks to each of the layers.
Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Salman, in view of Kaizer, Glasser, Roennow, Bai, and Rahardja.
Regarding Claim 22:
The combination of Salman, Kaizer, Glasser, Roennow, and Bai teaches the non-transitory computer-readable medium of claim 15.
Yi further teaches wherein the domain information block is included (Yi – P. 3: the blockchain network obtains a user public key by verifying an electronic signature included in the domain registration transaction, and extracts a new block including the user public key, the private domain name, the destination public key, and the additional information; and P. 4: The blockchain network 500 is connected to a plurality of nodes and performs verification of a transaction. In addition, each node belonging to the blockchain network 500 performs a verification on this transaction when a transaction occurs; Examiner’s Comment: The completion of the domain registration transaction includes the provision of the newly generated block to the blockchain network of nodes to be added to the blockchain upon verification by the nodes).
Kaizer further teaches based on the blockchain identifier (Kaizer – Col. 34, Lines 9-11: FIG. 11 is a flowchart of a method 1100 for assigning subdomains as blockchain addresses according to various embodiments; and Col. 34, Lines 19-26: By way of non-limiting example, method 1100 is shown and described herein as associating the domain name name.tld with the blockchain address 0x0123, associating the subdomain name personal.name.tld with the blockchain address 0x4567, and associating the subdomain name business.name.tld with the blockchain address 0x8910. However, any second-level domain name and subdomains may be used; and Col. 35, Lines 5-10: At block 1110, the blockchain smart contract calls the blockchain name services program to generate a record for the domain name name.tld. The blockchain name services program may further set the owner of name.tld as the blockchain address of the blockchain smart contract as part of this block; Examiner’s Comment: Examiner submits that this teaching from Kaizer expresses that a domain name (or, more specifically, a subdomain name) may be assigned as a blockchain address).
Bai further teaches block is included in the fork (Bai – Figure 1: a structural diagram of a smart-contract based domain name management service, including forks that branch based on TLDs; and Paragraph [0052]: The nodes in which the root domain contract is deployed are further configured to: receive a registration transaction, and initiate, based on the registration transaction, a voting transaction to a plurality of nodes in which the root domain contract is deployed. The plurality of nodes in which the root domain contract is deployed are further configured to: return a voting result based on the voting transaction, and accept or reject a newly added domain name corresponding to the registration transaction based on statistical voting results. Finally, the nodes in which the root domain contract is deployed are further configured to: generate a top-level domain contract based on the registration transaction, newly add record data corresponding to the registration transaction to the root domain contract, and record the top-level domain contract and the record data into a subchain block).
The combination of Salman, Kaizer, Glasser, Roennow, and Bai does not expressly teach block is included in the fork based on the blockchain identifier being within a range of blockchain identifiers that are particular to the fork.
However, Rahardja teaches block is included in the fork based on the blockchain identifier being within a range of blockchain identifiers that are particular to the fork (Rahardja – P. 9: The Rules_1, Rules_2, and other protocols are not defined by this specification, but defined by users of the system at runtime. These protocols are customizable based on a scripting, or programming language. According to one embodiment, a new protocol can only be defined for a forked chain and the original protocol remains fixed and applied to the genesis chain; Examiner’s Comment: Examiner submits that one of ordinary skill in the art will appreciate that the protocols defining the different forked layers are arbitrary with regard to the novelty of this invention. For example, a user could associate each forked layer of the blockchain with a certain range of blockchain identifiers).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Salman, Kaizer, Glasser, Roennow, and Bai, further incorporating Rahardja to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Rahardja’s teaching of a forked blockchain capable of supporting multiple forked chains with differing protocols for adding new blocks to each chain into Salman, Kaizer, Glasser, Roennow, and Bai’s combined method for registering a domain on a blockchain to a requesting device. This combination would allow the blockchain to functionally include different layers which could have different requirements for adding new blocks to each of the layers.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Xin et al. (CN 113438214 A) teaches a blockchain based domain name management system in which each top level domain has a corresponding sub-chain branching from a root chain
He et al. (CN 109672755 A) teaches a method and system for updating and maintaining domain name records via blockchain
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights