DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a non-final office action on application 18/375,638 filed on October 2, 2023 and in response to the applicant’s amendment received on November 11, 2025 (“Amendment”) which has been entered with the applicant’s filing of RCE on December 24, 2025.
Claims 1, 2, 4-6, 8, 11, 12, 15-17, 19, and 20 have been amended. Claims 1-20 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 has been amended to recite “receive, from a first node of a plurality of nodes, a request to perform a transaction of an asset between the first node and a second node of the plurality of nodes, the first node corresponding to a first node and a second node of the plurality of nodes, the first node corresponding to a first physical entity in a virtual environment, the second node corresponding to a second physical entity in the virtual environment; generate a certificate for the request; sign the certificate with a private key of the system; transmit the signed certificate to the first node; receive the signed certificate from the first node; determine whether the double signed certificate was validated by the first node, wherein the first node validates the signed certificate by signing the signed certificate with a private key of the first node; in response to the signed certificate being validated by the first node, generate a block comprising: i) a pointer, ii) a block identification, and iii) data associated with the transaction; transmit the block to each of the plurality of nodes; receive, from the first node, a first message indicating a first validation of the transaction; receive, from the second node, a second message indicating a second validation of the transaction; and in response to receiving the first message and the second message, append the block onto a blockchain, the blockchain comprising a plurality of blocks each associated with a respective transaction between two nodes of the plurality of nodes.”
The claim is rejected as the Specification finds no support for the particular sequence of functions as claimed in the claim. For example, the claim clearly suggests that a certificate that is signed with a private key of the system is transmitted to the first node. Upon receiving the signed certificate from the first node, the one or more processor determines whether the double signed certificate was validated by the first node. The one or more processor in response to the signed certificate being validated by the first node, generates a block and transmit the block to each of the plurality of nodes. The aspect of signing certificate is supported in paragraph [0033]. The paragraph clearly describes that the validation checker can issue a certificate for the transaction request and sign the certificate with a private key of the computing system. The validation checker may transmit the certificate (and any other data of the transaction request 116, the block 120) to the nodes 128 for validation. In other word, the block is generated prior to the issuance of the signed certificate to nodes 128 in the Specification.
The claim(s) having been amended significantly from the originally presented claim(s), the applicant is advised to provide citation in the specification for the claimed limitations.
Furthermore, the claim is rejected as the claim misrepresents paragraph [0033] as the claim recites transmitting of the signed certificate to a particular node, particularly the node that originates the transaction request; receiving the signed certificate to the particular node; determining whether the double signed certificate was validated by the particular node; in response to the signed certificate being validated by the particular node, generating a block while the specification in paragraph [0033] discloses that the signed certificate is transmitted to nodes 128; the nodes may parse the certificate for information that supports the validity of the transaction request; the nodes may verify the certificate via the public key; the nodes 128 may sign the certificate with a respective private key and transmit the signed certificate to the computing system 102. In other word, the specification discloses interaction involving the certificate between the computing system 102 and plurality of nodes 128, not only between the computing system 102 and the particularly the node.
Furthermore, in interpreting the claim in light of the specification, particularly that the plurality of nodes being a non-fungible token (see [0029]), the Specification does not show how a non-fungible token that is able to perform suggested function(s) of receiving, transmitting, signing, and validating of the certificate.
Claims 11 and 19 are significantly similar to claim 1, hence they are rejected also.
The dependent claims are rejected as they depend on the independent claim(s) above.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Per claim 1, the scope of the claim is unclear. The claim recites “a first physical entity in a virtual environment” and “a second physical entity in the virtual environment”. The claim is rejected as one of ordinary skill would appreciate that a physical and virtual are contradictory terms and the claim clearly recites the physical entities being in the virtual environment. While virtual representations of the physical entities are able to be in a virtual environment, the physical entities cannot. As such, the metes and boundaries of the claim is unclear.
Furthermore, the claim recites “the double signed certificate” in “determine whether the double signed certificate was validated by the first node”. The scope of the claim is unclear as the claim previously recite that the certificate is signed with a private key of the system and does not mention doubly signing the certificate.
Claims 11 and 19 are significantly similar to claim 1, hence they are rejected also.
In further reference to claim 11, the claim recites “the validation” in “in response to receiving the first message and the second message, appending, by the one or more processors, the block onto a blockchain based on receiving the validation, the blockchain comprising a plurality of blocks each associated with a respective transaction between two nodes of the plurality of nodes”. The scope of the claim is unclear as there are multiple validations in the claim and it is unclear as to which one of the previously recited validation(s) refer to “the validation”.
The dependent claim(s) are rejected as they depend on the claim(s) above.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does not fall within at least one of the four categories of patent eligible subject matter because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
MPEP 2106 provides step(s) in determining eligibility under 35 U.S.C. § 101. Specifically, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any additional elements in the claim must integrate the judicial exception into a practical application. If not, the inquiry continues to see whether any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself. Examples of abstract ideas include mathematical concepts, mental processes, and certain methods of organizing human activities.
Under Step 1, claims 1-10 (group I) are directed to a system, claims 11-18 (group II) directed to a method (i.e. process), while claim 19-20 are directed to a non-transitory computer-readable storage medium. Thus, the claimed inventions are directed towards one of the four statutory categories under 35 USC § 101. Nevertheless, the claims also fall within the judicial exception of an abstract idea without significantly more.
Step 2A, 1st prong:
Claim 11 recites: A method comprising:
a) receiving, by one or more processors from a first node of a plurality of nodes, a request to perform a transaction of an asset between the first node and a second node of the plurality of nodes, the first node corresponding to a first physical entity in a virtual environment, the second node corresponding to a second physical entity in the virtual environment;
b) generating a certificate for the request;
c) signing the certificate with a private key of the one or more processors;
d) transmitting the signed certificate to the first node;
e) receiving the signed certificate from the first node;
f) determining whether the double signed certificate was validated by the first node, wherein the first node validates the signed certificate by signing the signed certificate with a private key of the first node;
g) in response to the signed certificate being validated by the first node, generating, by the one or more processors, a block at least comprising: i) a pointer, ii) a block identification, and iii) data associated with the transaction;
e) transmitting, by the one or more processors, the block to each of the plurality of nodes;
f) receiving, by the one or more processors from the first node, a first message indicating a first validation of the transaction;
g) receiving, by the one or more processors from the second node, a second message indicating a second validation of the transaction; and
h) in response to receiving the first message and the second message, appending, by the one or more processors, the block onto a blockchain based on receiving the validation, the blockchain comprising a plurality of blocks each associated with a respective transaction between two nodes of the plurality of nodes.
(Emphasis added on the additional element(s))
The claim recites a process of that facilitates a transaction of an asset between two entities and recording of the transaction on a ledger, particularly the claim recites a) receiving from a first entity a request for the transaction (transaction of an asset between the first entity and a second entity); b) generating a certificate (i.e., document containing a certifying statement) for the request, c) signing the certificate (i.e., certifying the document); d) transmitting the signed certificate to the first entity, e) receiving the signed certificate from the first entity; f) determining whether the double signed certificate was validated by the first entity, wherein the first entity validates the signed certificate by signing the signed certificate (i.e., the first entity also certifies the document by signing the document); g) in response to the signed certificate being validated by the first entity (i.e., certificate signed by the first entity), generate a block (record) at least comprising: i) a pointer, ii) a block identification, and iii) data associated with the transaction; e) transmitting the block (record) to each of the plurality of validators (validators including the first entity and the second entity); f) receiving from the first entity, a first message indicating a first validation of the transaction; g) receiving from the second entity a second message indicating a second validation of the transaction; and h) in response to receiving the first message and the second message, appending the block (record) onto a ledger based on receiving the validation, the ledger comprising plurality of records each associated with a respective transaction between two parties of the plurality of entities. As such, the claim recites a certain method of organizing human activity (i.e., commercial or legal interactions and/or fundamental economic principles in facilitation of transaction).
Regards to the signing using private key(s), the examiner finds that the concept is mental practice/mathematical concepts. As such, the claim further recites abstract idea.
Independent claims 1 and 19 are significantly similar to claim 11. As such, claims 1 and 19 also recite abstract idea.
Under the Step 2A (prong 2), this judicial exception is not integrated into a practical application. Specifically, the additional elements in the claim(s), i.e., processor(s) coupled to a memory, node(s), description of what nodes correspond to, blockchain comprising a plurality of blocks, a non-transitory computer-readable storage medium storing computer program, are recited at a high-level generality such that it amounts to no more than mere instructions to implement the abstract idea and/or merely uses a computer as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular technology (i.e., blockchain in ledgering of transaction between entities) – see MPEP 2106.05(f). These limitation, e.g. abstract idea as described above, do not represent: Improvements to the functioning of the one or more processor(s), nodes, or blockchain individually or in combination or to any other technology or technical field - see MPEP 2106.05(a); or Applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception - see MPEP 2106.05(e).
Under Step 2B, examiners should evaluate additional elements individually and in combination to determine whether they provide an inventive concept (i.e. whether the additional elements amount to significantly more than the exception itself). Here, the claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Specifically, the claims as a whole, taken individually and in combination, do not provide an inventive concept. As explained above with respect to the integration of the abstract idea into a practical application, the additional elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea and/or merely uses a computer as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular technology (i.e., blockchain in ledgering of transaction of asset). Mere instructions to implement the abstract idea on a computer, or merely using the computer as a tool to perform an abstract idea to apply the exception using a generic computer component cannot provide an inventive concept. Looking at the limitations as a combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of the elements improves the functioning of the recited one or more processor(s), node(s), and/or blockchain individually or in combination.
For these reasons, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Dependent claims 2, 12, and 20 further recite the judicial exception of sharing of the ledger without further additional element(s).
Dependent claims 3 and 14 merely recite what the request comprises. As such the claims do not recite further additional element(s).
Dependent claims 4 and 15 further recite verifying of the signature of the request using a public key and transmitting the request to a second entity. However, these recitations fall under the judicial exception, i.e., abstract idea, i.e., mental process and mathematical concepts.
Dependent claims 5 and 16 further recite the abstract idea of receiving a message comprising the request and a second signature, transmitting the message to each of the entities, and receiving the message that is signed by the each of the entities. The concept of signature associated with private key is a mental practice/mathematical concept.
Dependent claims 6 and 17 further recite what the physical entities may represent, i.e., ATM, cash vault, etc. These additional elements are recited at high level amounting no more than generally linking the use of the judicial exception to a particular technological environment.
Dependent claims 7 and 18 recite description of data without reciting further additional element.
Dependent claim 8 recites that each block is encrypted by a key established using a quantum key distribution. The encryption technique using a quantum key distribution is a mathematical concept. Even if the However, the quantum key distribution is recited at high level generality resulting in “apply it”.
Dependent claims 9 and 13 recite that each of the plurality of nodes comprises a proof of identity, therefore, do not recite further additional element.
Dependent claim 10 recites what the transaction comprises, i.e., a transfer of the asset between the entities. Hence, the claim does not recite further additional element.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-5, 7, 9-16, 18, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Mastering Bitcoin” (“Antonopoulos”) in view of US Patent Publication No. 20080257952 (“Zandonadi”) and US Patent Publication No. 20080141033 (“Ginter”).
Per claims 1, 10, 11, and 19, Antonopoulos discloses a method comprising:
receiving, by one or more processors from a first node of a plurality of nodes, a request to perform a transaction of an asset between the first node and a second node of the plurality of nodes wherein the transaction comprises a transfer of the asset between the first node and the second node (see page 6, “full node” a client that stores the entire history of bitcoin transaction, manages the user’s wallets and can initiate transactions directly on the bitcoin network; page 26, network node that receives a valid transaction it has not seen before will immediately forward it to other nodes .. the transaction rapidly propagates out across the peer-to-peer network; page 31, full network node);
generating, by the one or more processors, a block at least comprising: i) a pointer, ii) a block identification, and iii) data associated with the transaction (see page 163, each blockchain is identified by a hash and also references a previous block; page 165, block identifier; page 170, summary of all transactions in the block using Merkle Tree);
transmitting, by the one or more processors, the block to each of the plurality of nodes (see page 148, full blockchain node receives updates about new blocks of transaction, which it then verifies and incorporates into its local copy of the blockchain; page 201);
receiving, by the one or more processors from the first node, a first message indicating a first validation of the transaction; receiving, by the one or more processors from the second node, a second message indicating a second validation of the transaction (see pages 201-202, validation by every node on the network before propagating it to its peers … all transactions within the block are valid); and
in response to receiving the first message and the second message, appending, by the one or more processors, the block onto a blockchain based on receiving the validation, the blockchain comprising a plurality of blocks each associated with a respective transaction between two nodes of the plurality of nodes (see pages 202-203, assembly of blocks into chains).
Antonopoulos further teaches one or more processors coupled with memory (see page 2, page 4; page 27; page 139, computers that participate in the P2P network (computer necessarily teaches one or more processors couple with memory)).
Antonopoulos does not particularly teach generating a message for the request; transmitting the message to the first node; receiving the message from the first nodes, and determining whether the message was validated by the node, and that the generating of the block is in response to the message being validated by the first node.
Zandonadi, however, teaches generating a message for the request; transmitting the message to the first node (i.e., payer); receiving the message from the first nodes, and determining whether the message was validated by the node, and that the generating of the block is in response to the message being validated by the first node (see [0020], generating and dispatching confirmation request from the payer; [0063] sending a confirmation request and receiving the confirmation request; [0071]).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to include the teaching of Zandonadi as described above to Antonopoulos as the combination improves upon usability by providing a payer to review the transaction and confirm the transaction prior to the completion of the transaction.
In reference to the generating of the block in response to the message being validated by the first node, by Zandonadi disclosing the first node validating the message prior to the transaction occurring which is equivalent to the block being generated, the combination of Antonopoulos and Zandonadi teaches this element.
The Antonopoulos/Zandonadi does not particularly teach that the document is a certificate; signing the certificate with a private key of the one or more processors; and determining wherein the first node validates the signed certificate by signing the signed certificate with a private key of the first node.
Ginter, however, teaches a signing of the certificate with a private key of the one or more processors; and determining wherein the first node validates the signed certificate by signing the signed certificate with a private key of the first node ([0314], contract passes from one party to another and iteratively signed at the respective signers’ location … signed copies are distributed to all parties; [0349], digital signature using private key used to encrypt).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to combine the teaching of signing of messages (certifying) to Antonopoulos/Zandonadi to ensure the authenticity and validity of the message.
Antonopoulos/Zandonadi/Ginter does not particularly teach that the first node corresponding to a first physical entity in a virtual environment and that the second node corresponding to a second physical entity in a virtual environment. However, descriptions of what the first node and the second node correspond to do not move to further distinguish over prior art as the description does not affect the one or more processors either functionally or structurally nor do the description affect the positively recited steps in the method claim.
As per claims 2, 12, and 20, Antonopoulos/Zandonadi/Ginter further teaches responsive to appending the block onto the blockchain, transmitting, to each of the plurality of nodes by the one or more processors, a copy of the blockchain (see Antonopoulos: page 148).
As per claims 3 and 14, Antonopoulos/Zandonadi/Ginter further teaches wherein the request comprises a first identification for the first node, a second identification for the second node, an amount for the transaction, and a signature associated with a private key of the first node (Antonopoulos: pages 18-25, transaction also contains a digital signature from the owner).
The applicant is reminded that description of request, i.e., what the request comprises, is non-functional descriptive material.
As per claims 4 and 15, Antonopoulos/Zandonadi/Ginter further teaches verifying, by the one or more processors, the signature of the request via a public key based on receiving the request; and transmitting, by the one or more processors to the second node, the request based on the verification to cause the second node to verify the request (see Antonopoulos: page 54, digital signature makes this transaction verifiable; page 61, digital signature based on key pair; page 62, signatures validated using the public key; page 26, network node that receives a valid transaction it has not seen before will immediately forward it to other nodes .. the transaction rapidly propagates out across the peer-to-peer network; pages 201-202, validation by every node on the network before propagating it to its peers … all transactions within the block are valid). The applicant is reminded that “to cause the second node to verify the request” is merely intended use of the request or result of the transmitting.
As per claims 5 and 16, Antonopoulos/Zandonadi/Ginter further teaches receiving, by the one or more processors from the second node, a third message comprising the request and a second signature associated with a second private key of the second node; and responsive to receiving the third message comprising the second signature, transmitting, by the one or more processors to each of the plurality of nodes, the second/third message (see Ginter: [0314], contract passes from one party to another and iteratively signed at the respective signers’ location … signed copies are distributed to all parties; [0349], digital signature using private key used to encrypt).
As per claims 7 and 18, Antonopoulos/Zandonadi/Ginter further teaches wherein the data is structured according to a data structure formulated based on: i) a destination identification field, ii) an amount field associated with the transaction, and iii) a source identification field (see page 163, each blockchain is identified by a hash and also references a previous block; page 165, block identifier; page 170, summary of all transactions in the block using Merkle Tree). The applicant is reminded that the description of data, i.e., how it was formulated, does not move to distinguish over prior art as the data is merely non-functional descriptive material.
As per claims 9 and 13, Antonopoulos/Zandonadi/Ginter further teaches wherein each of the plurality of nodes (i.e., participants) comprises a proof of identity (see Ginter: [0349], private key; [0544]; [0681]; [0682]).
Claim(s) 6 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Antonopoulos", “Zandonadi”, and “Ginter” as applied to claim 1 above, and further in view of US Patent Publication No. 20240296453 (“Singh”).
Per claims 6 and 17, Antonopoulos/Zandonadi/Ginter does not specifically teach wherein at least one of the first physical entity or the second physical entity comprises one of an automated teller machine (ATM), a teller view, a cash vault, a branch vault, a teller cash line, a teller cash recycler (TCR), or a cash deposit recycler (CDR), and the plurality of nodes at least comprises one of an ATM node, a teller view node, a cash vault node, a branch vault node, a teller cash line node, a TCR node, or a CDR node.
Singh, however, teaches ATM being a part of nodes in the blockchain (see ¶0012; ¶0016, each of the ATMs may operate as a blockchain node; ¶0033).
It would have been obvious to one of ordinary still in the art to include in the blockchain system of Antonopoulos/Zandonadi/Ginter the technique of nodes being an ATM as taught by Singh since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Furthermore, descriptions of what the first node and the second node correspond to do not move to further distinguish over prior art as the description does not affect the one or more processors either functionally or structurally nor do the description affect the positively recited steps in the method claim.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Antonopoulos", “Zandonadi”, and “Ginter” as applied to claim 1 above, and further in view of US Patent Publication No. 20230401553 (“Navarro”).
Per claim 8, Antonopoulos/Zandonadi/Ginter does not specifically teach wherein the block is encrypted by a key established using a quantum key distribution (QKD).
Navarro, however, teaches wherein the block is encrypted by a key established using a quantum key distribution (QKD) (see ¶0153, decryption is performed based on the type of encryption in each block; ¶0161-¶0163, quantum key distribution).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to include the technique of encrypting of each block as taught by Navarro to Antonopoulos/Zandonadi/Ginter in order to keep data protected from unauthorized user.
Response to the Argument(s)
Claims remain rejected under 112(a) and 112(b) for the reasons outlined above in the 112 sections.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure
US Patent No. 11880228 discloses a method and system for processing a blockchain. A transaction request indicating a sale made by an agent of the entity may be received at a first node. A block including a sales record indicating the sale made by the agent may be added to a blockchain and transmitted to another node for validation. The patent discloses assignment of a public/private key for a node when the node joins the blockchain. The node sends a message to another node of the blockchain by including digital signature using the private key of the node.
US Patent Publication No. US 20200186506 discloses a technique in which data is verified by a server then the server creates a signed certificate signifying or acknowledging the attestation to the source data. The signed certificate allows a verifying recipient device to confirm that the source data has been attested to by the server based on the signed certificate.
US Patent Publication No. 20190394047 discloses a method for mining a block in a decentralized blockchain consensus network and signing a block of a blockchain.
US Patent Publication No. 20090158414 and 20140013107 discloses twice signing of digital certificate.
US Patent Publication No. 20080141033 discloses use of digital certificates including signatures of multiple parties.
Applied Cryptography discloses uses of digital certificate and signatures.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN S KIM whose telephone number is (571)270-5287. The examiner can normally be reached Monday -Friday: 7:00 - 3:30.
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, Patrick McAtee can be reached on 571-272-7575. 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.
/STEVEN S KIM/Primary Examiner, Art Unit 3698