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 Amendments and Arguments
Applicant has cancelled claim 1 and filed new claim set of claims 2-21 and stated that the new amended claims has overcome rejection 103 issued in the previous action. However, the Applicant provided no evidence. Examiner has considered newly filed claims 2-21 on the basis of merits and issued instant Final office action.
Double Patenting
At the request of the Applicant the Double Patenting rejection issued in the previous office action has been held in abeyance.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper time-wise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 2-21 of instant Application US 18/895,098 is rejected on the ground of nonstatutory anticipatory type double patenting as being unpatentable over claims 1-22 of US patent US12132820. Although the conflicting claims are not identical, they are not patentably distinct from each other because the claims both in the present application and the US patent discloses a method providing association of Network Identifier and Blockchain address
The table below shows the comparison of claim of the instant application with that of the US patent US12132820.
Claim No.
Limitations of Instant Application US18/895098.
Limitations of the US patent US12132820.
Claim No.
1
2. (New) A method of associating a blockchain address of a blockchain with a network identifier, the method comprising: receiving, over a computer network and by an identifier infrastructure operator, an identifier associated with a first action; determining, by the identifier infrastructure operator, an association between the identifier and the blockchain address of the blockchain; signing, using a private key associated with the identifier infrastructure operator, a value to represent the association between the identifier and the blockchain address; and transmitting, over the computer network and by the identifier infrastructure operator, the signed value in place of the association between the identifier and the blockchain address..
1. A method of associating a blockchain address with a network identifier, the method comprising: receiving, over a computer network and by a network identifier infrastructure operator, a request for a registration status of the network identifier; retrieving, by the network identifier infrastructure operator and in response to the receiving the request, an association of the network identifier with the blockchain address; signing, using a private key associated with the network identifier infrastructure operator and in response to the retrieving the association, a unique identifier to prevent replay attacks and the association of the network identifier with the blockchain address, wherein a signed association is determined based at least in part on the signing the association of the network identifier with the blockchain address; and providing, in response to the signing and by the network identifier infrastructure operator, the signed association of the network identifier with the blockchain address over the computer network.
1
14. (New) A system comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions executable by the one or more processors, wherein the instructions, when executed, cause the one or more processors to perform operations comprising: receiving, over a computer network and by an identifier infrastructure operator, an identifier associated with a first action; determining, by the identifier infrastructure operator, an association between the identifier and a blockchain address of a blockchain; signing, using a private key associated with the identifier infrastructure operator, a value to represent the association between the identifier and the blockchain address; and transmitting, over the computer network and by the identifier infrastructure operator, the signed value in place of the association between the identifier and the blockchain address.
10. (Currently Amended) A system comprising: a memory containing instructions; and a processor, operably connected to the memory, that executes the instructions to perform operations comprising: receiving, over a computer network and by a network identifier infrastructure operator, a request for a registration status of the network identifier; retrieving, by the network identifier infrastructure operator and based at least in part on in response to the receiving the request, an association of the network identifier with a blockchain address; signing, using a private key associated with the network identifier infrastructure operator in response to the retrieving the association, a unique identifier to prevent replay attacks and the association of the network identifier with the blockchain address, wherein a signed association is determined based at least in part on the signing the unique identifier and the association of the network identifier with the blockchain address; and providing, in response to the signing over the computer network and by the network identifier infrastructure operator, the signed association of the network identifier with the blockchain address over the computer network.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 2-3, 5, 7-9, 12, 14-15, 17 & 19-20 are rejected under 35 USC 103 as being unpatentable over Kaizer (WO 2020005753 A1-original in English is attached) in view of Noonan (US 20200013026 A1)
Regarding claim 2, Kaizer teaches:
a method of associating a blockchain address of a blockchain with a network identifier, the method comprising: receiving, over a computer network and by an identifier infrastructure operator, an identifier associated with a first action; [0011] Various optional features of the above method embodiments include the following. The method may include, prior to the sending the request for a proof of registrar of record for the domain name: receiving, by the DNS registrar (identifier infrastructure operator) for the domain name, a request for an access token, wherein the request comprises a browser redirection from a service provider from which the registrant has requested that the domain name (identifier) be assigned as a blockchain user address (a first action) of the registrant in the blockchain network; authenticating, by the DNS registrar, the registrant; responding to the request, by the DNS registrar, with an access token and a redirection back to the service provider; and receiving, by the DNS registrar, the access token, the domain name, and an existing blockchain user address for the registrant. The request may further include the existing blockchain user address for the registrant. The sending, by the DNS registrar, and to the blockchain network, the request to assign the domain name as a blockchain user address for the registrant,
signing, using a private key associated with the identifier infrastructure operator, a value to represent the association between the identifier and the blockchain address; and [0013] ] Various optional features of the above embodiments include the following. The at least one electronic server computer may be further configured to sign, using the private key, a top level domain name corresponding to the domain name and a blockchain address of the registry signature verification program to form a message (signed value of association of domain name and blockchain address) and provide (transmit) the message (the signed value) to the blockchain network for inclusion in the blockchain. The EPP interface may be further configured to respond to the request for a proof of registrar of record for the domain name by confirming that the registrar is a registrar of record for the domain name and then providing the proof of registration message, the domain name, and the existing blockchain user address for the registrant to the blockchain network for processing by the registry signature verification program. The request may further include the existing blockchain user address for the registrant. The registry signature verification program may be further configured to await confirmation sent from an electronic wallet of the registrant before requesting assignment of the domain name as a blockchain user address of the registrant in the blockchain network. The registry may be further configured to: store in persistent memory a voiceprint of a contact for a registration of the domain name; receive a request to verify a new voiceprint; verify the new voiceprint by matching to the voiceprint of the contact for the registration of the domain name; and provide a voiceprint verification to the registrar.]
transmitting, over the computer network and by the identifier infrastructure operator, the signed value in place of the association between the identifier and the blockchain address. [0013] Various optional features of the above embodiments include the following. The at least one electronic server computer may be further configured to sign, using the private key, a top level domain name corresponding to the domain name and a blockchain address of the registry signature verification program to form a message (signed value of association of domain name and blockchain address) and provide (transmit) the message (the signed value) to the blockchain network for inclusion in the blockchain. ]
Although Kaizer teaches the identifier infrastructure operator, he does not explicitly teach, however, Noonan teaches determining, by 100 may also include servers 110 associated with an entity 112. The entity 112 may be a company, an individual, or any other legal entity with an identity that can be authenticated by servers 108. For example, a CA can verify a name, mailing address, Internet domain name, and Bitcoin address (blockchain address) of an entity. Optionally, and also for example, a CA can establish ownership of a blockchain identifier (e.g., a Bitcoin address) by requiring an entity to prove ownership of a private key corresponding to the blockchain identifier (e.g., by providing a digital signature constructed using a private key corresponding to a Bitcoin address). It is obvious to an ordinary skilled person that CA can be replaced/substituted by the entity “identifier infrastructure operator”.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Kaizer with the disclosure of Noonan. The motivation or suggestion would have been to implement a system that will provide an improved technique for increasing the efficiencies and security of the blockchain transactions. (abstract, paras 0002-0011, Noonan).
Regarding claim 3, although, Kaizer teaches internet domain name, he does not explicitly teach, however, Noonan teaches determining the association comprises associating the internet domain name with the blockchain address. [0049] System 100 may also include servers 110 associated with an entity 112. The entity 112 may be a company, an individual, or any other legal entity with an identity that can be authenticated by servers 108. For example, a CA can verify a name, mailing address, Internet domain name, and Bitcoin address (blockchain address) of an entity. Optionally, and also for example, a CA can establish ownership of a blockchain identifier (e.g., a Bitcoin address) by requiring an entity to prove ownership of a private key corresponding to the blockchain identifier (e.g., by providing a digital signature constructed using a private key corresponding to a Bitcoin address). It is obvious to an ordinary skilled person that CA can be replaced/substituted by the entity “identifier infrastructure operator”.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Kaizer with the disclosure of Noonan. The motivation or suggestion would have been to implement a system that will provide an improved technique for increasing the efficiencies and security of the blockchain transactions. (abstract, paras 0002-0011, Noonan).
5. (New) The method of claim 2,
Regarding claim 5, Kaizer teaches wherein the identifier infrastructure operator comprises a Domain Name System (DNS) registry. [[0074] Fig. 6 is a schematic diagram of a system 600 including server computer 618 according to various embodiments. System 600 includes, for example, registrant 202 (identified with their computer), DNS registry 602, DNS registrar 604, and server computer 618, all communicatively coupled to the internet 604. System 600 may also include blockchain network 608, which itself may include a plurality of networked nodes, which themselves may be networked through the internet 604. Server computer 618 may be, for example, a server computer of registry 102, registrar 104, or trusted service provider 502, according to various embodiments. Registry 602 may be registry 102, and/or registrar 604 may be registrar 104, consistent with server computer 618 being either registry 102 or registrar 104, according to various embodiments. That is, Fig. 6 is intended to display the various components networked together, as well as the internal workings of a server computer consistent with the various, e.g., registry and registrar, servers disclosed herein. Please also see paragraph 0075.]
Regarding claim 7, Kaizer teaches wherein the first action comprises a storage action, and the method further comprising: receiving, from a network identifier registration facilitator, a request to store the identifier associated with the blockchain; and storing, in a memory and by the identifier infrastructure operator, a representation of the association between the identifier and the blockchain address of the blockchain. [0008] According to various embodiments, a domain name system (DNS) registry facilitated method of assigning a DNS domain name registered to a registrant as a blockchain user address in a blockchain network is disclosed. The method includes: obtaining, by the DNS registry for the domain name, a cryptographic asymmetric proof key pair comprising a public key and a private key; providing, by the DNS registry, the public key and a computer executable registry signature verification program for addition to a block in a blockchain of the blockchain network, wherein the registry signature verification program is configured to use the public key to validate signatures made using the private key; receiving, by the DNS registry, a request for a proof of registrar of record for the domain name from a registrar of record for the domain name, wherein the request comprises the domain name; confirming, by the DNS registry, that the registrar is a registrar of record for the domain name; providing, by the DNS registry, a proof of registration message, wherein the proof of registration message comprises a signature by the private key and confirms that the registrar is a registrar of record for the domain name; whereby the registry signature verification program validates the signature using the public key, and whereby the blockchain network receives and stores in the blockchain an association between the domain name and an existing blockchain user address for the registrant Please also see paragraphs 0009-0010]
Regarding claim 8, Kaizer teaches wherein the request to store the identifier associated with the blockchain comprises a datum signed by the private key of an asymmetric key pair of a holder of the identifier. [0009] According to various embodiments, a domain name system (DNS) registry facilitated method of assigning a DNS domain name registered to a registrant as a blockchain user address in a blockchain network is disclosed. The method includes: obtaining, by the DNS registry for the domain name, a cryptographic asymmetric proof key pair comprising a public key and a private key; providing, by the DNS registry, the public key and a computer executable registry signature verification program for addition to a block in a blockchain of the blockchain network, wherein the registry signature verification program is configured to use the public key to validate signatures made using the private key; receiving, by the DNS registry, a request for a proof of registrar of record for the domain name from a registrar of record for the domain name, wherein the request comprises the domain name; confirming, by the DNS registry, that the registrar is a registrar of record for the domain name; providing, by the DNS registry, a proof of registration message, wherein the proof of registration message comprises a signature by the private key and confirms that the registrar is a registrar of record for the domain name; whereby the registry signature verification program validates the signature using the public key, and whereby the blockchain network receives and stores in the blockchain an association between the domain name and an existing blockchain user address for the registrant.
Regarding claim 9, Kaizer teaches wherein receiving the identifier is associated with a request for a registration status of the identifier. [0009] Various optional features of the above method embodiments include the following. The method may further include: using the private key, signing, by the DNS registry, a top level domain name corresponding to the domain name and a blockchain address of the registry signature verification program to form a message; and providing the message to the blockchain network for inclusion in the blockchain. The providing, by the DNS registry, the proof of registration message may include providing, by the DNS registry, the domain name, the existing blockchain user address for the registrant, and the proof of registration message to the blockchain network for processing by the registry signature verification program. The request may further include the existing blockchain user address for the registrant. The registry signature verification program may be further configured to await confirmation sent from an electronic wallet of the registrant before requesting assignment of the domain name as a blockchain user address of the registrant in the blockchain network. The method may further include: storing in persistent memory a voiceprint of a contact for a registration of the domain name; receiving a request to verify a new voiceprint; verifying the new voiceprint by matching to the voiceprint of the contact for the registration of the domain name; and providing a voiceprint verification to the registrar. Please also see paragraphs 0010-0012.]
12. (New) The method of claim 2,
Regarding claim 12, Kaizer teaches receiving a message, and the method further comprising: signing the message with the private key of the identifier infrastructure operator. [0013] Various optional features of the above embodiments include the following. The at least one electronic server computer may be further configured to sign, using the private key, a top level domain name corresponding to the domain name and a blockchain address of the registry signature verification program to form a message and provide the message to the blockchain network for inclusion in the blockchain. The EPP interface may be further configured to respond to the request for a proof of registrar of record for the domain name by confirming that the registrar is a registrar of record for the domain name and then providing the proof of registration message, the domain name, and the existing blockchain user address for the registrant to the blockchain network for processing by the registry signature verification program. The request may further include the existing blockchain user address for the registrant. The registry signature verification program may be further configured to await confirmation sent from an electronic wallet of the registrant before requesting assignment of the domain name as a blockchain user address of the registrant in the blockchain network. The registry may be further configured to: store in persistent memory a voiceprint of a contact for a registration of the domain name; receive a request to verify a new voiceprint; verify the new voiceprint by matching to the voiceprint of the contact for the registration of the domain name; and provide a voiceprint verification to the registrar.]
Regarding claim 14, this claim is interpreted to be similar to claim 2 and rejected for the same reasons as set forth for claim 2.
Regarding claim 15, this claim is interpreted to be similar to claim 3 and rejected for the same reasons as set forth for claim 3.
Regarding claim 17, this claim is interpreted to be similar to claim 5 and rejected for the same reasons as set forth for claim 5.
Regarding claim 19, this claim is interpreted to be similar to claim 7 and rejected for the same reasons as set forth for claim 7.
Regarding claim 20, this claim is interpreted to be similar to claim 9 and rejected for the same reasons as set forth for claim 9.
Claims 4 & 16 are rejected under 35 USC 103 as being unpatentable over Kaizer in view of Noonan and Kuchar (US 20190279215 A1)
Regarding claim 4, although, Kaizer and Noonan teach the identifier they do not teach explicitly, however, Kuchar teaches determining the association comprises associating the social media identifier with the blockchain address. [0052] In some implementations, the data acquisition module 200-1 may be configured to acquire fraud data from targeted locations, such as locations on the internet specified by web uniform resource locators (URLs) and/or usernames (e.g., a specific social media account). In some implementations, a customer of the trust system 100 may provide locations (e.g., web URLs) that the data acquisition module 200-1 may monitor for fraudulent activity. For example, a customer may provide a web address to a social media page associated with a specific blockchain address. In this example, the data processing module 200-2 may identify fraudulent behavior if a blockchain address other than the specified blockchain address appears in the web contents at the web address. In another example, if there is a known contribution address of an initial coin offering (ICO), accounts and blockchain addresses fraudulently attempting to acquire funds (e.g., phish) may be detected. The trust system 100 may then notify the customer of the fraudulent address and use the evidence of fraudulent activity as described herein.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Kaizer and Noonan with the disclosure of Kuchar. The motivation or suggestion would have been to implement a system that will provide an improved technique of using a trust score for detecting likelihood fraudulent activities.(abstract, paras 0002-0005, Kuchar).
Regarding claim 16, this claim is interpreted to be similar to claim 4 and rejected for the same reasons as set forth for claim 4.
Claims 6 & 18 are rejected under 35 USC 103 as being unpatentable over Kaizer in view of Noonan and Japanese01 (JP 2021524978 A)
Regarding claim 6, although, Kaizer and Noonan teach the association, they do not teach explicitly, however, Japanese01 teaches wherein determining the association between the identifier and the blockchain address of the blockchain comprises looking up the association in a first database, and the method further comprising: publishing the association in a second database accessible by a computing device associated with the blockchain. [page, last paragraph of the attached translated copy: In a preferred embodiment of the method according to the invention, in connection with the first dataset 2, the following information: transaction hash, block hash, block height, and said, corresponding to the transaction generated in step e). The block time stamps of the registration corresponding to the block mentioned in step g) are stored in a separate database. This data can be stored in another database on a server or computer that is permanently or temporarily connected to the blockchain database. The separate database may be duplicated, transferred and stored on a separate computer or server. The database can be modified in any way and does not have to be an incremental database like a blockchain. Arbitrary operations on records such as duplication, writing, deleting, reading, editing, and merging are possible. The database also stores additional information about the digital file (digital property), such as file size, file type, file owner, file creator, file version, file summary, file content, entire digital property, or file. be able to. A separate database sends additional information about the source of the digital good, such as the IP address of the node, the blockchain address, the ID or name of the user who is the author or owner of the digital good, the number of owners, the blockchain. The time, the time stamp of the registration of the block in the blockchain, the blockchain type, etc. can be stored. Of course, all this information can also be stored in the blockchain database itself. However, the advantage of registering this information in a separate, preferably dedicated database is that it can be quickly retrieved when information about a particular digital file is required, for example for the purpose of its verification. Retrieving information from a separate, dedicated database can be much faster than retrieving information from a blockchain database. Information retrieved from a separate database can be used to find relevant blocks and transactions in the blockchain database, where the transaction contains complete information about the contents and source of the digital file and the associated registration time. It is stored with the stamp.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Kaizer and Noonan with the disclosure of Japense01. The motivation or suggestion would have been to implement a system that will provide improved and convenient procedures for registering data in a blockchain database. (abstract, page 03, paras 03-05, Japense01).
Regarding claim 18, this claim is interpreted to be similar to claim 6 and rejected for the same reasons as set forth for claim 6.
Claims 10 & 21 are rejected under 35 USC 103 as being unpatentable over Kaizer Noonan and Cona (US20190333054)
Regarding claim 10, although Kaizer and Noonan teach request for registration status, they do not teach explicitly, however, Cona teaches wherein receiving the identifier associated with the first action comprises one of: a Registration Data Access Protocol (RDAP) request, a Repository-based Data Dissemination (RDD) protocol request, or a WHOIS request. [0077] Anonymous RDAP Service. ICANN is currently conducting a pilot program to test a new Registration Data Access Protocol (“RDAP”) for accessing Whois data. Under RDAP, a limited amount of domain name record data may still be accessed anonymously using an RDAP service provided by registrars or other authorized service providers in the ecosystem for a given TLD. Some available open source RDAP servers that may be used for this purpose include those from CNNIC, NICMx, Reddog, DNS Belgium, and ARIN.[0078] With an anonymous RDAP service, any user may request Whois data from a registrar or other service provider (i.e., no user authentication is required). However, for anonymous RDAP access only a “thin registry” dataset need be returned. Anonymous users do not have access to the bulk of the record data for a domain name that is typically provided by a “thick registry” dataset (such as the registrant name and contact information, or the identifying information for other contacts listed in the domain record).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Kaizer and Noonan with the disclosure of Cona. The motivation or suggestion would have been to implement a system that will provide improved and convenient procedures for utilizing RDAP or Whois protocols/services for accessing registry dataset. (paragraphs 0076-0079, Cona).
Regarding claim 21, this claim is interpreted to be similar to claim 10 and rejected for the same reasons as set forth for claim 10
Claim 11 is rejected under 35 USC 103 as being unpatentable over Kaizer Noonan and Ravinathan (US 11587071 B2)
Regarding claim 11, wherein the first action represents a request from an electronic wallet of a blockchain user engaging in a blockchain transaction with an owner of the blockchain address.[Col 9 & 10, lines 45-65 & 1-15, respectively: In the system 100, the issuer processing server 102 may submit a blockchain transaction to a node in the blockchain network 116 for payment of a suitable amount of cryptocurrency (e.g., based on the transaction amount in the fiat payment transaction and the exchange rate provided by the exchange server 114, or as directly provided by the exchange server 114) from a blockchain wallet associated with the consumer's transaction account or the issuer processing server 102 generally for payment to a blockchain wallet of the merchant, such as stored in the point of sale device 108 or other computing device associated with the merchant. The blockchain transaction may include the cryptocurrency amount, the blockchain address for receipt by the merchant, one or more unspent transaction outputs, and a digital signature generated using the private key of the blockchain wallet from which payment is being made. In an exemplary embodiment, the private key and unspent transaction outputs may be stored in an account profile for the consumer's transaction account, such as identified using the transaction account number included in the authorization request routed to the issuer processing server 102 via the payment rails. The node in the blockchain network 116 may receive the blockchain transaction and process the blockchain transaction using traditional methods, such as by confirming the transaction and including it in a new block that is confirmed by other nodes in the blockchain network 116 and then added to the blockchain. As part of the processing of the blockchain transaction, the node may identify a transaction identifier, which is a unique value for the blockchain transaction, which may be returned to the issuer processing server 102 as confirmation of the blockchain transaction. In some embodiments, the issuer processing server 102 may await posting of the blockchain transaction in the blockchain and identify the transaction identifier therefrom.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Kaizer and Noonan with the disclosure of Ravinathan. The motivation or suggestion would have been to implement a system that will allow consumer pay for a fiat transaction with cryptocurrency while utilizing legacy point of sale devices and systems for merchants, also enabling the merchant to be paid immediately via cryptocurrency, without having to wait for standard processing and settlement. (abstract, Col 1& 2, lines 01-65 & 01-50, Ravinathan).
Claim 13 is rejected under 35 USC 103 as being unpatentable over Kaizer Noonan and Kasimov (US 20200409942 A1)
Regarding claim 13, although, Kaizer and Noonan teach the association, they do not teach explicitly, however, Kasimov teaches comprises human readable text. [0036] In addition to the consensus algorithm, the blockchain system 502 can include other software that underlie the rules of how the blockchain system 502 operates. In some implementations, the blockchain system 502 includes a virtual machine layer which can provide a virtual machine environment for programmers or developers to build distributed services and or software on the blockchain. A blockchain naming service can be one of the services provided on the blockchain system 502. The blockchain naming service allows an address to be typecast in a human readable format, in a similar manner that the DNS allows typecasting IP addresses in human readable formats. For example, the address “1Y761KZXjcopfXpSMjH9g5MxDDTPi4zEWq” can be typecast as “boo.art”. So instead of working with the address, a developer, programmer, or a user can merely refer to “boo.art”.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Kaizer and Noonan with the disclosure of Kasimov. The motivation or suggestion would have been to implement a system that will provide an improved DNS registry which is further configured to manage one or more domains in a blockchain system, wherein the first domain is included in the one or more domains, and wherein managing the one or more domains in the blockchain system includes creating a duplicate record of the “Whois” record in the blockchain system. (abstract, paras0003-0008, Kasimov).
Examiner’s Note: The prior art made of record and not relied upon is considered pertinent to applicant's disclosure are following:
1. Roennow (US 20200021446 A1) discloses computer-implemented method for
secure de-centralized domain name system, the method comprising: 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; transmitting, by a client node, a domain name request to a domain name node; receiving, by 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 initiating a secure communication between the client node and the server node using at least one of the domain public key and the domain certificate information.
LU (CN102045413A-translated copy with original attached)) teaches a DNS
mapping system through DHT expansion and method of realizing DNS safety. The mapping system comprises a mainframe comprising a DNS analyzer, local and authorised DNS servers and a DHT server in a DHT ring, the DNS server and the DHT server manage mapping information from identity to position as mapping servers and inquire mapping information for the mainframe. The system synthesizes the advantages of DNS and DHT, which not only adsorbs DNS tree shape structure, supports layering inquiring of the mapping information and comprises a reasonable commercial and trustful model; but also succeeds the advantages of DHT of redundancy backups, strong robustness and so on; the system can be realized based on improvement of current DNS mapping system, a mass of financial resources and manpower for constructing network is reduced. The invention establishes a complete trust chain between the DHT ring and the upper layer DNS server, uses an ID management server positioned separating framework of the identify and position to distribute TSIG secret key automatically, and ensures that original DNSSEC and TSIG safety mechanism of the DNS still can be realized completely in the DNS mapping system through DHT expansion.
Arora (US20180276663) discloses a method for offline transmission of
blockchain details includes: storing, in a computing device, a first private key and a currency amount; receiving a first destination address associated with a blockchain network and a transaction amount; generating a second private key; generating a second destination address associated with the blockchain network using the second private key; generating a blockchain transaction including at least the first destination address, the transaction amount, the second destination address, and a remainder amount based on at least the currency amount and the transaction amount; signing the generated blockchain transaction using the first private key; executing a query to replace the first private key with the second private key, wherein replacement of the first private key includes deletion of the first private key from the computing device; and transmitting the generated blockchain transaction.
Wang (CN112765684A-translated copy and original attached) discloses the
embodiment of the invention relates to the technical field of blockchain, specifically relates to a terminal management method of the blockchain, a device, a device and a storage medium. The method comprises: obtaining the signature field and the public key sent by the terminal of the blockchain, the signature field by the trusted password module in the terminal of the blockchain using the private key in the asymmetric key, the target data signature calculation to obtain the public key is the public key of the asymmetric key; checking the signature field based on the public key; if the signature field verification is passed, sending the admittance credential to the blockchain node terminal, so that the blockchain obtaining the signature result returned by the blockchain node terminal; checking the signature result; if the verification is passed, allowing the access of the terminal of the blockchain By using the method, the invention uses the cryptology mechanism to construct the trust chain, so as to effectively improve the reliability of the computing environment formed by adding the terminal of the blockchain
Liu (CN112671950A-a translated copy with original is attached) teaches a
domain name processing method based on blockchain, device, electronic device and storage medium, relating to the technical field of blockchain, which can be used for cloud computing and cloud service. The specific implementation scheme is as follows: obtaining the domain name processing transaction request including the domain name information to be processed; calling the domain name processing contract; executing the domain name processing transaction request according to the domain name data recorded in the blockchain wherein the domain name data at least comprises domain name registration information; the domain name registration information comprises a mapping relationship between the registered domain name and the IP address, and the held party account information of the registered domain name. The invention can improve the domain name processing efficiency.
Special Note: Although few priors are mentioned above, in fact, the prior arts made of record and listed on the PTO-892 and not relied upon are considered pertinent to applicant’s disclosure.
CONCLUSION
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 SHER A KHAN whose telephone number is (571)272-8574. The examiner can normally be reached M-F 8:00 am-500pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni A Shiferaw can be reached at 571-272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/SHER A KHAN/Primary Examiner, Art Unit 2497