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 .
DETAILED ACTION
1. Claims 2 - 21 are pending. Claims 2, 10, 17 are independent. Claim 1 is cancelled. File data is 11-27-2024.
Claim Rejections - 35 USC § 103
2. 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.
3. Claims 2 - 8, 10 - 21 are rejected under 35 U.S.C. 103 as being unpatentable over Phoenix et al. (US PGPUB No. 20190379636) in view of Roennow et al. (Patent No. WO 2018/162789).
Regarding Claims 2, 10, 17, Phoenix discloses a computer-implemented method and a system and one or more non-transitory computer-readable media, comprising:
a) receiving an indication that a first record has been updated, wherein the first record is associated with a domain name; (Phoenix ¶ 013: The gaining registrar may receive a confirmation (indication) of the transfer of the domain name from the registry. The gaining registrar may transmit a message to the client device of the registrant that the transfer for the domain name from the losing registrar to the gaining registrar is complete.; ¶ 002: for a registrant of a domain name, after registering the domain name with a losing registrar, to transfer the domain name from a losing registrar to a gaining registrar)
b) based on receiving the indication, determining a gaining registrant associated with the domain name; (Phoenix ¶ 013: The gaining registrar may receive a confirmation (indication) of the transfer of the domain name from the registry. The gaining registrar may transmit a message to the client device of the registrant that the transfer for the domain name from the losing registrar to the gaining registrar is complete.) and
c) causing a second record associated with the domain name to be updated to reflect the gaining registrant, the second record being a domain name system (DNS) record. (Phoenix ¶ 046: in coordination with a registry 130 responsible for a TLD of the domain name(s), register the domain name to the registrant 100. The registrant contact information and registered one or more domain names may also be stored in the WHOIS database by the registry 130 as part of the domain name registration process.)
Phoenix does not explicitly disclose for a) domain name information stored on a blockchain network
However, Roennow discloses wherein for a) domain name information stored on a blockchain network. (Roennow ¶ 018: recording a domain registration transaction to a blockchain, the domain registration transaction comprising a domain name, a domain primary key corresponding to a domain public key and domain certificate information for a server node; 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;)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Phoenix for a) domain name information stored on a blockchain network as taught by Roennow. One of ordinary skill in the art would have been motivated to employ the teachings of Roennow for the benefits achieved from enhanced security of the storage of secure infornatuin such as domain name management information within a blockchain data structure. (Roennow ¶ 018)
Furthermore, Phoenix discloses wherein one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed, cause the system to perform operations. (Phoenix ¶ 037: The Internet 120 user may use a client, such as, as non-limiting examples, a cell phone, PDA, tablet, laptop computer, or desktop computer to access a website via a computer network,; ¶ 044: The gaining registrar 200 is hereby defined to be a particular machine, that is a different particular machine from the losing registrar 210, that comprises a domain name registrar, at least one or more hardware servers, electrical communication equipment to interface with one or more computer networks, routing servers to communicate with a plurality of registrars and software to automate the various processes attributed to the gaining registrar)
Furthermore, Phoenix discloses wherein one or more non-transitory computer-readable media storing instructions executable by one or more processors, wherein the instructions, when executed, cause the one or more processors to perform operations. (Phoenix ¶ 037: The Internet 120 user may use a client, such as, as non-limiting examples, a cell phone, PDA, tablet, laptop computer, or desktop computer to access a website via a computer network,; ¶ 044: The gaining registrar 200 is hereby defined to be a particular machine, that is a different particular machine from the losing registrar 210, that comprises a domain name registrar, at least one or more hardware servers, electrical communication equipment to interface with one or more computer networks, routing servers to communicate with a plurality of registrars and software to automate the various processes attributed to the gaining registrar)
Regarding Claims 3, 11, 18, Phoenix-Roennow discloses the computer-implemented method of claim 2 and the system of claim 10 and the one or more non-transitory computer-readable media of claim 17, wherein the indication is generated by a domain contract of the blockchain network, and wherein generating the indication comprises:
a) receiving a first request to update the first record to represent the gaining registrant; (Phoenix ¶ 008: receive from the client device of the registrant a request to transfer the domain name from the losing registrar to the registrant account of the gaining registrar.)
b) based on receiving the first request, sending a second request to the blockchain network, the second request being associated with updating the first record to represent the gaining registrant; and c) based on sending the second request, generating the indication. (Phoenix ¶ 013: The gaining registrar may receive a confirmation (indication) of the transfer of the domain name from the registry. The gaining registrar may transmit a message to the client device of the registrant that the transfer for the domain name from the losing registrar to the gaining registrar is complete.; ¶ 002: for a registrant of a domain name, after registering the domain name with a losing registrar, to transfer the domain name from a losing registrar to a gaining registrar)
Phoenix does not explicitly disclose for b) a deed contract of the blockchain network (smart contract).
However, Roennow discloses wherein for b) a deed contract of the blockchain network. (Roennow ¶ 106: history data of earlier transaction data, user profiles, settings, agreements, smart contracts, and blockchains may be maintained at the server 130,)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Phoenix for b) a deed contract of the blockchain network (smart contract) as taught by Roennow. One of ordinary skill in the art would have been motivated to employ the teachings of Roennow for the benefits achieved from enhanced security of the storage of secure information such as domain name management and security information within a blockchain data structure. (Roennow ¶ 018)
Regarding Claims 4, 12, 19, Phoenix-Roennow discloses the computer-implemented method of claim 3 and the system of claim 11 and the one or more non-transitory computer-readable media of claim 18, wherein: the first request is received from an executable program of the blockchain network, and the executable program is configured to generate the first request based on receiving a re-registration request. (Phoenix ¶ 008: receive from the client device of the registrant a request to transfer (i.e. re-registration request) the domain name from the losing registrar to the registrant account of the gaining registrar.)
Regarding Claims 5, 13, 20, Phoenix-Roennow discloses the computer-implemented method of claim 2 and the system of claim 10 and the one or more non-transitory computer-readable media of claim 17, wherein causing the second record to be updated comprises:
a) determining a losing registrar associated with a losing registrant of the domain name and a gaining registrar associated with the gaining registrant; (Phoenix ¶ 008: The gaining registrar may receive from the client device of the registrant a request to transfer the domain name from the losing registrar to the registrant account of the gaining registrar.)
b) providing a request for authorization information to the losing registrar; (Phoenix ¶ 019: If the domain name is registered to the registrant and the domain name is available for transfer, the losing registrar may receive a request from the gaining registrar for the contact information for the registrant.) and
c) receiving, from the losing registrar, the authorization information; and d) providing the authorization information to the gaining registrar. (Phoenix ¶ 020: The losing registrar may read from the database the contact information of the registrant and transmit the contact information for the registrant to the gaining registrar. The contact information may be used by the gaining registrar to authenticate the registrant at the gaining registrar who is requesting the transfer of the domain name.)
Regarding Claims 6, 14, 21, Phoenix-Roennow discloses the computer-implemented method of claim 5 and the system of claim 13 and the one or more non-transitory computer-readable media of claim 20, wherein the gaining registrar is configured to, based on receiving the authorization information, perform operations comprising; providing a second request to a registry, the second request representing the authorization information. (Phoenix ¶ 020: The losing registrar may read from the database the contact information of the registrant and transmit the contact information for the registrant to the gaining registrar. The contact information may be used by the gaining registrar to authenticate the registrant at the gaining registrar who is requesting the transfer of the domain name.)
Regarding Claims 7, 15, 16, Phoenix-Roennow discloses the computer-implemented method of claim 5 and the system of claim 13 and the system of claim 13, wherein determining the losing registrant and the gaining registrant. (Phoenix ¶ 008: receive from the client device of the registrant a request to transfer the domain name from the losing registrar to the registrant account of the gaining registrar.; (querying request indicates losing registrant information and gaining registrant information))
Phoenix does not explicitly disclose a blockchain network and a deed contract of the blockchain network (smart contract).
However, Roennow discloses a blockchain network (Roennow ¶ 018: recording a domain registration transaction to a blockchain, the domain registration transaction comprising a domain name, a domain primary key corresponding to a domain public key and domain certificate information for a server node; 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;) ), a deed contract of the blockchain network (smart contract). (Roennow ¶ 106: history data of earlier transaction data, user profiles, settings, agreements, smart contracts, and blockchains may be maintained at the server 130, )
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Phoenix for a blockchain network and a deed contract of the blockchain network (smart contract) as taught by Roennow. One of ordinary skill in the art would have been motivated to employ the teachings of Roennow for the benefits achieved from enhanced security of the storage of secure informationn such as domain name management information within a blockchain data structure. (Roennow ¶ 018)
Regarding Claim 8, Phoenix-Roennow discloses the computer-implemented method of claim 2.
Phoenix does not explicitly disclose a record is stored on at least one of a blockchain directory of the blockchain network or a deed contract of the blockchain network.
However, Roennow discloses wherein the first record is stored on at least one of a blockchain directory of the blockchain network or a deed contract of the blockchain network. (Roennow ¶ 122 - 125: a single blockchain keeps track of both registered domain names and server nodes to form a plurality of blockchain node layers 200A, 200B, 200C. Thus different blockchain node layers correspond to different roles within the system 200 and the DNS usage rather than separate blockchains.; [00123] The domain name node layer 200A comprises at least one domain name node 230 configured to control the domain name system and the domain certificate information of the server nodes 210.; [00124] The server node layer 200B comprises at least one server node 210 configured to register with the domain name node layer 200A. The server node 210 may also comprise a plurality of servers delivering one site;[ 00125] The client node layer 200C comprises at least one client node 220 configured to query and respond with the domain name node layer 200A for utilizing secure communication with the server node layer 200B. The client node 220 may comprise a browser application, for example.; (selected: stored on at least one of a blockchain directory))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Phoenix for a record is stored on at least one of a blockchain directory of the blockchain network or a deed contract of the blockchain network as taught by Roennow. One of ordinary skill in the art would have been motivated to employ the teachings of Roennow for the benefits achieved from enhanced security of the protected storage of secure information such as domain name management and security information within a blockchain data structure. (Roennow ¶ 018)
4. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Phoenix in view of Roennow and further in view of UA 132044 U et al. (Patent No. UA 132044 U referred to as “UA132044U”).
Regarding Claim 9, Phoenix-Roennow discloses the computer-implemented method of claim 2.
Phoenix does not explicitly disclose the blockchain network comprises a blockchain market.
However, UA132044U discloses wherein the blockchain network comprises a blockchain market. (Phoenix page 8: Under the server of a decentralized web platform of electronic smart protocols based on blockchain chains (smart market) is meant an electronic platform (which can be in the form of a domain name, public page, etc.), where active links to electronic smart protocol are placed, created on the basis of blockchain technology.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Phoenix for the blockchain network comprises a blockchain market as taught by UA132044U. One of ordinary skill in the art would have been motivated to employ the teachings of UA132044U for the benefits achieved from the flexibility of a system that enables multiple entities such as blockchain marketplaces to be utilized in the processing of domain name type information. (Phoenix page 8)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kyung H Shin whose telephone number is (571)272-3920. The examiner can normally be reached M - F: 12pm - 8pm.
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, Joon H Hwang can be reached at 571-272-4036. 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.
/KYUNG H SHIN/ 6-5-2026Primary Examiner, Art Unit 2447
Prosecution Insights