DETAILED ACTION
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 Arguments
The previous rejections of the claims under 35 USC §§112 and 102 have been withdrawn, in light of the amendments. New rejections under 35 USC §§101 and 103 have been set forth, in light of the amendments.
Applicants’ arguments regarding the previous rejection of the claims filed 12/18/2025 and concerning the previous art rejections of the claims have been fully considered but they are not persuasive.
Regarding the previous art rejection of the claims, Applicants argue on pages 10-13 that Dierks does not teach the claim language directed to mutual exclusivity, intertwining and alternating between active and inactive.
The Office respectfully disagrees, noting that the references as a whole teach the recited claim language. First it is noted that the claim language appears to be much broader than what is asserted in the arguments/remarks. For instance, the claims seem to assert contradictory elements (mutual-exclusivity vs intertwining). And, since there are no implementation details that would clarify exactly what a tag chain system is and how it operates, it was reasonable to apply the teachings of Dierks, as the cited reference passage does discuss the use of two blockchains (i.e., a “target” blockchain and a “second” blockchain). Had they been one blockchain, they would not be referred to in such a manner.
Second, as was noted in the interview of 7/29/2025, the meaning of “intertwining” was not explicit from a reading of the disclosure. The term “intertwined” was merely used once in paragraph [0146] of the Specification. It was never defined, especially as to what it means in the context of Applicants’ subject matter. In the interview, Figure 10 was presented as teaching the concept of “intertwined” blockchains, but it was pointed out this was merely a drawing of even number boxes connected by lines and odd numbered boxes connected by lines. There is no discussion of what constitutes “intertwined” blockchains. Are they individual blocks physically stored next to / between each other? There are no claimed implementation details that would require a particular meaning of these claim terms, nor details that guarantee that an “intertwining” requirement results in a particular storage arrangement. (NOTE: the published application, US 2024/0160622, was referenced because the Patent Office did not appear to put paragraph numbers in the “as filed” Application which was viewed electronically within the DAV system.)
It is also noted even with the additional claim language directed to using one or the other blockchain (or one at a time), the claimed invention appears to be merely using two block chains. E.g., having a banking or retail system that permits transactions optionally using Bitcoin or Ethereum.
And, it is also noted that the newly amended claim language presents a new combination of elements.
Therefore, it is believed that the references have been reasonably interpreted as teaching the recited claim language.
Applicants further argue on page 13 that the independent claims reciting substantially similar limitations, and all dependent claims are allowable for the reasons argued above.
The Office respectfully disagrees, and counter-asserts the rationale set forth above.
Applicants’ arguments on pages 14-16 concerning claims 16-19 are moot in light of the new art that has been applied to these newly added claims.
Claim Rejections – 35 U.S.C. § 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 16-19 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter.
These claims are rejected under 35 USC §101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites at a very level, creating two linked lists (i.e., two data structures). Thus, the claims encompass the performance of the limitations via a mental process or using paper and pencil, that are not tied to a practical application.
Regarding the independent claims:
Step 1: Yes, claim 16 recites a method (therefore a process). Thus, the claim is directed to a statutory category.
Step 2A, Prong 1 (Judicial Exception Recited?): Yes. Claim 16 recites limitations directed to an abstract idea: “selecting a first blockchain as an active blockchain; adding the first block to the first blockchain; selecting a second blockchain as an active blockchain; and adding the second block to the second blockchain”. As drafted, each of these limitations recites a mentally performable process as one can organize data into a data structure via a mental process or using paper and pencil.
Step 2A, Prong 2 (Integrated into a Practical Application?): No. Claim 16 recites the following additional elements, "computer” and “blockchain”. Each of these are merely high-level recitations of generic computer (hardware and software) components and represent mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
Additionally, claim 16 recites “receiving a request to add a first block” and “receiving a request to add a second block”, which represent insignificant extra-solution activity as retrieval/receiving of data (i.e. mere data gathering) such as 'obtaining information' as identified in MPEP 2106.05(g), and does not provide integration into a practical application.
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea. Viewing the additional limitations together and the claims as a whole, nothing provides integration into a practical application. Therefore, the claim is directed to an abstract idea.
Step 2B (Inventive Concept Provided?): No. As discussed with respect to Step 2A, the elements (i.e., steps of “receiving a request to add a first block” and “receiving a request to add a second block”) in the claim amount to no more than mere instructions to apply the exception. Mere instructions to apply an exception using generic computer components (e.g., a computer and software/blockchain data structures) cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
With respect to the “receiving …” limitations discussed above, and when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and thus remains insignificant extra-solution activity that does not provide significantly more.
Therefore, each of the claims, taken as a whole, does not change this conclusion and the claim is ineligible.
Claims 17-19 depend upon claim 16, and do not correct the issues set forth above. Claim 17 performs essentially the same limitations as claim 16 for an additional generic software element (i.e., data structure). Claim 18 repeats the performance of the limitations of claim 16. Claim 19 merely adds that the claim 16 limitations are performed on one generic software element (i.e., data structure) at a time. These claims are likewise rejected for essentially the same rationale as set forth for independent claim 16.
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 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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 6-8, 10-11, 13 and 15 are rejected under 35 U.S.C. §103 as being unpatentable over Dierks et al. (US Patent Application Publication No. 2018/0083786, hereafter referred to as “Dierks”) in view of Frankel et al (US Patent Application Publication No. 2018/0337781, hereafter referred to as “Frankel”). It is further noted that the Spasovski reference (cited below as: Spasovski, Jason, et al., “Proof of Stake Blockchain: Performance and Scalability for Groupware Communications”, Medes ‘17, Bangkok, Thailand, November 7-10,2017, pp. 251-258) provides evidence that a signature/hash encompasses a checksum.
Regarding independent claim 1: Dierks teaches A computer-implemented tag chain blockchain system comprising: A. a first blockchain; and B. a second blockchain, wherein the first blockchain and the second blockchain are mutually-exclusive. (See Dierks Abstract in the context of Figure 3 and paragraph 0049 indicating the linking of two mutually exclusive blockchains [i.e., a “target” blockchain and a “second blockchain”] in a “lattice” system.)
However, Dierks does not explicitly teach the remaining limitations as claimed. Frankel, though, teaches and wherein the first blockchain and the second blockchain are intertwined within the same blockchain system and wherein the first and second blockchains alternate between being active and inactive. (See Frankel paragraph 0029 teaching the publishing of an entry in a first ledger/blockchain, then subsequently [i.e., at a later time] updating at least one other ledger/blockchain, in the context of Figure 1 showing a network system of distributed ledgers containing mutually exclusive blockchains – which is analogous to Applicants’ disclosure (published as 2024/0160622) at paragraph [0146] which does not define any particular meaning of the term “intertwined”, and displays two blockchains in Fig. 10 as being mutually exclusive.)
It 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 to apply the teachings of Frankel for the benefit of Dierks, because to do so provided a designer with options for implementing a system for providing enhanced data security, as taught by Frankel in paragraph 0005. These references were all applicable to the same field of endeavor, i.e., blockchain system management.
Regarding claim 2: Dierks discloses wherein the first chain and the second chain are stored on the same server. (See Dierks paragraph 0038 disclosing that the target and second blockchains may be associated with one server.)
Regarding claim 3: Dierks discloses wherein the first chain and the second chain are stored on different servers. (See Dierks Abstract and paragraph 0048 indicating that a blockchain system be distributed. See also, paragraph 0038 indicating that the target and second blockchains may be on more than one server.)
Regarding claim 4: Dierks discloses wherein only a single blockchain is active at any given time. (See Dierks paragraph 0005 discussing identifying a block of a second blockchain, where the second blockchain is not a part of the target blockchain.)
Regarding claim 6: Dierks discloses wherein a link in the first blockchain is a checksum, and wherein a link in the second blockchain is a checksum. (See Dierks Abstract discussing the associating/linking of a target blockchain and a second blockchain via signatures. See also, paragraphs 0037 and 0047-0049 discussing the linking together of blocks via a signature hash.) It is further noted that the Spasovski reference (at page 253, ~5th paragraph) provides evidence that a signature/hash is a checksum.
Regarding claim 7: Dierks discloses wherein the checksums alternate between different blockchains. (See Dierks Figure 3 in the context of 0047 discussing signature generation only for blocks to which it is linked. See also, paragraph 0036 discussing that the target block might not immediately precede the existing block.)
Regarding independent claim 8: Dierks discloses A method for forming a computer-implemented tag chain blockchain system comprising the steps of: A. generating a first link in a first blockchain; and B. generating a first link in a second blockchain, wherein the first link in the first blockchain is not linked to the first link in the second blockchain; … wherein the first blockchain and the second blockchain are mutually exclusive, and wherein each link comprises a checksum. (See Dierks Abstract in the context of Figure 3 and paragraph 0049 indicating the linking of two mutually exclusive blockchains [i.e., a “target” blockchain and a “second blockchain”] in a “lattice” system. See also, Figure 3 showing links between blocks of a target blockchain and a second blockchain, and which blocks are not linked. And, refer to the Abstract in the context of paragraphs 0037, 0044 and 0047-0049 discussing linking via a signature cryptographic/hash mechanism.)
However, Dierks does not explicitly teach the remaining limitations as claimed. Frankel, though, teaches C. intertwining the first blockchain and the second blockchain within the same blockchain system; and D. alternating the first blockchain and the second blockchain between being active and inactive. (See Frankel paragraph 0029 teaching the publishing of an entry in a first ledger/blockchain, then subsequently [i.e., at a later time] updating at least one other ledger/blockchain, in the context of Figure 1 showing a network system of distributed ledgers containing mutually exclusive blockchains – which is analogous to Applicants’ disclosure (published as 2024/0160622) at paragraph [0146] which does not define any particular meaning of the term “intertwined”, and displays two blockchains in Fig. 10 as being mutually exclusive.)
It 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 to apply the teachings of Frankel for the benefit of Dierks, because to do so provided a designer with options for implementing a system for providing enhanced data security, as taught by Frankel in paragraph 0005. These references were all applicable to the same field of endeavor, i.e., blockchain system management.
Claim 10 is substantially similar to claim 7, and therefore likewise rejected.
Regarding claim 11: Dierks discloses further comprising a step of separating the links of the first blockchain and the second blockchain, wherein the step of separating the links of the first blockchain and the second blockchain comprises a separation method, wherein the separation method is selected from the group consisting of sequence logic, a period of time, a number of checksums, a portion of a checksum, a modification of a checksum, a modulo method, a device or a plurality of devices, an address, a unique identifier, and a combination thereof. (See Dierks paragraphs 0006, 0032, 0038, 0048 and 0069 indicating that blockchain data may be distributed/separated across multiple system, thus requiring a plurality of devices/addresses/unique identifiers.)
Regarding claim 13: Dierks does not explicitly teach the remaining limitations as claimed. Frankel, though, teaches wherein only a single blockchain is active at any given time. (See Frankel paragraph 0029 teaching the publishing of an entry in a first ledger/blockchain, then subsequently [i.e., at a later time] updating at least one other ledger/blockchain, in the context of Figure 1 showing a network system of distributed ledgers containing mutually exclusive blockchains.)
Regarding claim 15: Dierks does not explicitly teach the remaining limitations as claimed. Frankel, though, teaches wherein only a single blockchain is active at any given time. (See Frankel paragraph 0029 teaching the publishing of an entry in a first ledger/blockchain, then subsequently [i.e., at a later time] updating at least one other ledger/blockchain, in the context of Figure 1 showing a network system of distributed ledgers containing mutually exclusive blockchains.)
Claims 12 and 14 are rejected under 35 U.S.C. §103 as being unpatentable over Dierks et al. (US Patent Application Publication No. 2018/0083786, hereafter referred to as “Dierks”) in view of Frankel et al (US Patent Application Publication No. 2018/0337781, hereafter referred to as “Frankel”) and Awasthy (US Patent No. 11,501,365, hereafter referred to as “Awasthy”).
Regarding claim 12: Dierks in view of Frankel does not explicitly teach the remaining limitations as claimed. Awasthy, though, teaches wherein the tag chain blockchain system adds an additional chain upon reaching a predetermined criteria. (See Awasthy col. 4 lines 43-49 discussing the generation of a new blockchain upon the predetermined criterion of receiving communications not associated with any existing blockchain.)
It 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 to apply the teachings of Awasthy for the benefit of Dierks in view of Frankel, because to do so provided a designer with options for implementing a system to manage communications between a blockchain network and a user, as taught by Awasthy in the Abstract. These references were all applicable to the same field of endeavor, i.e., blockchain system management.
Regarding claim 14: Dierks in view of Frankel does not explicitly teach the remaining limitations as claimed. Awasthy, though, teaches wherein the tag chain blockchain system adds an additional chain upon reaching a predetermined criteria. (See Awasthy col. 4 lines 43-49 discussing the generation of a new blockchain upon the predetermined criterion of receiving communications not associated with any existing blockchain.)
Claims 16 and 18 are rejected under 35 U.S.C. §103 as being unpatentable over Kilpatrick (US Patent Application Publication No. 2018/0240165, hereafter referred to as “Kilpatrick”) in view of Dillenberger et al (US Patent Application Publication No. 2017/0212781, hereafter referred to as “Dillenberger”).
Regarding independent claim 16: Kilpatrick teaches A method for forming a computer-implemented tag chain blockchain system comprising the steps of: A. receiving a request to add a first block; B. selecting a first blockchain as an active blockchain; C. adding the first block to the first blockchain; (See Kilpatrick paragraph 0038 discussing an activation request transaction, and committing a block to a blockchain.)
However, Kilpatrick does not explicitly teach the remaining limitations as claimed. Dillenberger, though, teaches D. receiving a request to add a second block; E. selecting a second blockchain as an active blockchain; and F. adding the second block to the second blockchain. (See Dillenberger paragraphs 0039-0040 discussing the receiving of a request from a user/entity and subsequent adding of a new block to a blockchain.)
It 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 to apply the teachings of Dillenberger for the benefit of Kilpatrick, because to do so provided a designer with options for implementing a system having the ability to confirm when and what sequence a transaction became journaled as part of a blockchain, as taught by Dillenberger in the Abstract. These references were all applicable to the same field of endeavor, i.e., blockchain system management.
Regarding claim 18: The claim repeats the performance of its parent: wherein the method repeats steps A-F.
Kilpatrick teaches A method for forming a computer-implemented tag chain blockchain system comprising the steps of: A. receiving a request to add a first block; B. selecting a first blockchain as an active blockchain; C. adding the first block to the first blockchain; (See Kilpatrick paragraph 0038 discussing an activation request transaction, and committing a block to a blockchain.)
However, Kilpatrick does not explicitly teach the remaining limitations as claimed. Dillenberger, though, teaches D. receiving a request to add a second block; E. selecting a second blockchain as an active blockchain; and F. adding the second block to the second blockchain. (See Dillenberger paragraphs 0039-0040 discussing the receiving of a request from a user/entity and subsequent adding of a new block to a blockchain.)
Claim 17 is rejected under 35 U.S.C. §103 as being unpatentable over Kilpatrick (US Patent Application Publication No. 2018/0240165, hereafter referred to as “Kilpatrick”) in view of Dillenberger et al (US Patent Application Publication No. 2017/0212781, hereafter referred to as “Dillenberger”) and Carey et al (US Patent Application Publication No. 2018/0165476, hereafter referred to as “Carey”).
Regarding claim 17: Kilpatrick in view of Dillenberger does not explicitly teach the remaining limitations as claimed. Carey, though, teaches wherein the computer-implemented tag blockchain chain system further comprises a third blockchain, and wherein a third block is added to the third blockchain. (See Carey paragraphs 0003 and 0005 discussing the appending of a new data block to a blockchain.)
It 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 to apply the teachings of Carey for the benefit of Kilpatrick in view of Dillenberger, because to do so provided a designer with options for implementing a system to prevent blockchain vulnerabilities, as taught by Carey in the Abstract. These references were all applicable to the same field of endeavor, i.e., blockchain system management.
Claim 19 is rejected under 35 U.S.C. §103 as being unpatentable over Kilpatrick (US Patent Application Publication No. 2018/0240165, hereafter referred to as “Kilpatrick”) in view of Dillenberger et al (US Patent Application Publication No. 2017/0212781, hereafter referred to as “Dillenberger”) and Frankel et al (US Patent Application Publication No. 2018/0337781, hereafter referred to as “Frankel”).
Regarding claim 19: Kilpatrick in view of Dillenberger does not explicitly teach the remaining limitations as claimed. Frankel, though, teaches wherein only a single blockchain is active at a time. (See Frankel paragraph 0029 teaching the publishing of an entry in a first ledger/blockchain, then subsequently [i.e., at a later time] updating at least one other ledger/blockchain, in the context of Figure 1 showing a network system of distributed ledgers containing mutually exclusive blockchains.)
It 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 to apply the teachings of Frankel for the benefit of Kilpatrick in view of Dillenberger, because to do so provided a designer with options for implementing a system for providing enhanced data security, as taught by Frankel in paragraph 0005. These references were all applicable to the same field of endeavor, i.e., blockchain system management.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Relevance is provided in at least the Abstract of each cited document.
Non-Patent Literature
Luo, Kan, et al., “A Multiple Blockchains Architecture On Inter-Blockchain Communication”, QRS-C 2018, Portugal, Lisbon, July 16-20, 2018, pp. 139-145.
Blockchain is a new technology for data sharing between untrusted peers. However, it does not work well with massive transactions. Besides, there are high barriers between heterogeneous blockchain systems. In this paper, we proposed an innovative component-based framework for exchanging information across arbitrary blockchain system called interactive multiple blockchain architecture. In our architecture, a dynamic network of multi-chain is created for inter-blockchain communication. We propose the inter-blockchain connection model for routing management and messages transferring. Additionally, our proposed protocols provide transactions with atomicity and consistency in crossing-chain scene. In the end, our experiment results based on a network of private multiple blockchain systems show that the throughput is increased by a number of chains parallel running. (page 139, Abstract).
Hardjono, Thomas, et al., “Towards a Design Philosophy for Interoperable Blockchain Systems”, arXiv, Cornell University archive, document no: arXiv:1805.05934v1, 15 May 2018, pp. 1-27.
In this paper we discuss a design philosophy for interoperable blockchain systems, using the design philosophy of the Internet architecture as the basis to identify key design principles. Several interoperability challenges are discussed in the context of cross-domain transactions. We illustrate how these principles are informing the interoperability architecture of the MIT Tradecoin system. (page 1, Abstract). N different blockchain systems (page 8, Figure 2). For blockchain systems we re-interpret the term “survivability” in the sense of the completion of an application-level transaction. Completion here means from its transmission by an end-user application (or by a smart contract on an origin blockchain) to its confirmation on a single blockchain system or multiple systems. The application-level transaction may be composed of multiple ledger-level transactions (sub-transaction) and which may be intended for multiple distinct blockchain systems (e.g. sub-transaction for asset transfer, simultaneously with sub-transaction for payments and sub-transaction for taxes). Thus the notion of packets routing through multiple domains being opaque to the communications application (e.g. email application, browser) is re-cast to the notion of sub-transactions confirmed on a spread of blockchain systems being opaque to the user application. (page 8, 2nd paragraph of section “3.1 Survivability”). Figure 2 illustrates the scenario. The application transmits data-bytes (hash) to a blockchain system No. 1, and waits for confirmation (of the successful recording to the ledger) to become available. After waiting for some predetermined time unsuccessfully (i.e. time out), the application transmits the same data-bytes to a different blockchain system No. 2. The application continues this process until it is able to obtain the desired confirmation. Thus for the application “survivability” means that the simple transaction has been success fully confirmed on some blockchain (i.e. on all nodes of that ledger), even if soon after the blockchain ceases being able to process future transactions due to attacks. The side effect maybe that the same transaction is confirmed independently on multiple blockchain systems, but the application does not care about this possible side effect so long as “the transaction got through”. (page 9, 1st full paragraph).
Vranken, Harald, “Sustainability of bitcoin and blockchains”, Current Opinion in Environmental Sustainability, Volume 28, October 2017, Elsevier, Science Direct, pp. 1-9.
Bitcoin is an electronic currency that has become increasingly popular since its introduction in 2008. Transactions in the bitcoin system are stored in a public transaction ledger (‘the blockchain’), which is stored in a decentralized, peer-to-peer network. Bitcoin provides decentralized currency issuance and transaction clearance. The security of the blockchain depends on a compute-intensive algorithm for bitcoin mining, which prevents double spending of bitcoins and tampering with confirmed transactions. This ‘proof-of-work’ algorithm is energy demanding. (page 1, Abstract). Each node independently verifies the transactions received, propagates valid transactions, and builds a pool of valid transactions. The valid transactions are added to the blockchain in a process called bitcoin mining. Each node collects a number of valid transactions into a block and tries to compute a crypto graphic hash of the block that meets certain constraints (based on the ideas of Hashcash [16]). A cryptographic hash is a kind of checksum for the block, that is one-way (meaning that it is easy to compute a hash of a given block, but difficult to compute a block that matches a given hash) and collision resistant (meaning that it is difficult to find two blocks that yield the same hash). (page 2, middle of the 1st paragraph in section entitled “Overview of the bitcoin system”). Each block does not only contain transactions, but also the hash of the previously accepted block in the block chain. Hence, the blocks in the blockchain are linked to each other: they form a chain of blocks, thence the term ‘blockchain’. (page 2, 2nd paragraph in section entitled “Overview of the bitcoin system”).
Wang, Hui, et al., “Blockchain Router: A Cross-Chain Communication Protocol”, IEFA ‘17, Jeju, Republic of Korea, March 29-31, 2017, pp. 94-97.
Cross-chain communication is one of the major design considerations in current blockchain systems [4-7] such as Ethereum [8]. Currently, Blockchain operates like information isolated island, they cannot obtain external data or execute transactions on their own. Motivated by recent studies [1-3] on blockchain's multiChain framework, we investigate the cross-chain communication. We introduce blockchain router, which empowers blockchains to connect and communicate cross chains. By establishing an economic model, blockchain router enables different blockchains in the network communicate with each other same like Internet network. In the network of blockchain router, some blockchain plays the role of a router which, according to the communication protocol, analyzes and transmits communication requests, dynamically maintaining a topology structure of the blockchain network. (page 94, Abstract). Blockchain Router Network’s telecommunication protocol is delegated as follows. At first, the cross-chain communication request should be written into sub-chain in the form of transaction. Then, the connector collect the blocks of sub-chain and detect the cross-chain communication request. Once a cross-chain communication transaction is triggered, the connector send the transaction with proof to validators. At last, validators verifies the transaction and record the result on validators’ block. The connectors of target sub-chain collect the blocks of blockchain router and forward the information and corresponding proof information to target sub-chain. (page 95, section “3.3 Communication Protocol”).
Back, Adam, et al., “Enabling Blockchain Innovations with Pegged Sidechains”, http://www. opensciencereview. com/papers/123/enablingblockchain-innovations-with-pegged-sidechains, 2014 Oct 22, vol. 72, 25 pages.
We propose a new technology, pegged sidechains, which enables bitcoins and other ledger assets to be transferred between multiple blockchains. This gives users access to new and innovative cryptocurrency systems using the assets they already own. By reusing Bitcoin’s currency, these systems can more easily interoperate with each other and with Bitcoin, avoiding the liquidity shortages and market fluctuations associated with new currencies. Since sidechains are separate systems, technical and economic innovation is not hindered. Despite bidirectional transferability between Bitcoin and pegged sidechains, they are isolated: in the case of a cryptographic break (or malicious design) in a sidechain, the damage is entirely confined to the sidechain itself. (page 1, Abstract). To synchronise
the two chains, we need to define two waiting periods: The confirmation period of a transfer between sidechains is a duration for which a coin must be locked on the parent chain before it can be transferred to the sidechain. The purpose of this confirmation period is to allow for sufficient work to be created such that a denial of service attack in the next waiting period becomes more difficult. (page 9, section “3.2 Symmetric two-way peg).
Dilley, Johnny, et al., “Strong Federations: An Interoperable Blockchain Solution to Centralized Third-Party Risks”, arXiv, Cornell University, document no: arXiv:1612.05491v3 30 Jan. 2017, pp. 1-14.
Pegged sidechains allow parties to transfer assets by providing explicit proofs of possession in transactions [showing a system containing mutually exclusive blockchains labelled A and C]. (page 3, Fig. 2). The authors of “Enabling Blockchain Innovations with Pegged Sidechains” [22] suggested a way to deploy federated sidechains [i.e., a system] without requiring any alterations to the consensus rules of Bitcoin’s blockchain. In their methodology, a sidechain used a k-of-n federation of mutually distrusting participants, called the functionaries, who validate and sign the blocks of the chain (blocksigners) and the pegs (watchmen) respectively. A Federated Peg is a mechanism that uses functionaries to move assets between two chains. The functionaries observe at least the two chains– the Bitcoin blockchain and the sidechain– to validate asset transfers between them. To meet the criteria of a Strong Federation, a set of geographically and jurisdic-tionally distributed servers is used, creating a compromise resistant network of functionaries. This network retains a number of the beneficial properties of a fully decentralized security model. (page 4, 1st and 2nd paras of section “A. Federated Peg”).
US Patent Application Publications
Frankel 2018/0337781
Links are formed by storing the cryptographic checksum identifier of one block 108 in the metadata of another block 108, such that the former block 108 becomes the predecessor of the latter block 108. In this way, the blocks 108 form a chain that can be navigated from block-to-block by retrieving the cryptographic checksum of a particular's block's predecessor from the particular block's own metadata. Each block 108 is computationally impractical to modify once it has been in the block chain 106 because every block 108 after it would also have to be regenerated. When a network node 102 publishes an entry (e.g. a block 108) in its ledger 104, the block chain 106 for all of the other network nodes 102 in the distributed network 100 is also updated with the new entry. Thus, data published in a block chain 106 is available and accessible to every network node 102 with a ledger 104. (para 0029).
Zhang 2021/0334268
A block can include a hash of a previous block immediately before it such that the blocks are anchored with each other to form a blockchain (or a block storage stream). In such a way, the blocks do not store details of the transactions. The details of the transactions can be stored in the transaction storage stream in the ledger server 320 or a separate repository in the centralized ledger system 310. (para 0120).
Madl 2022/0252202
In this example, the pilot generates a flight exam session entry 412, and stores it in its own blockchain 410. The key may be a reference to a name of the class or some other value, and the value field may includes the description of the flight exam, as well as its date. Here, a transaction ID Tim is created when the block is stored in the blockchain 410. The pilot may digitally sign the transaction ID Tim with its private key, and sends it over to the instructor. In response, the instructor may perform a lookup with the authority based on the pilot's name. The instructor may then verify the authenticity of the message using the public key of the pilot. After the flight exam is over, the instructor may generates a new block in the blockchain 420. The key of the block contains the transaction id received from the pilot Tim as the key. The value field contains the passing designation, as well as the time when the pilot passed the exam. In response to the transaction being stored on the blockchain 420, a new transaction ID is created T.sub.ID2. Here, the instructor may sign the newly generated transaction identifier T.sub.ID2 with his private key, and sends it to the authority. In response, the authority may verify the authenticity of the message based on the public key of the instructor. Further, the authority may perform a lookup in blockchain 420 using transaction T.sub.ID2 to confirms that the pilot's exam with transaction id Tim had a passing grade. The FAA then performs a lookup in blockchain 410 to confirm the flight exam and date. After this cross-validation (across blockchains 410 and 420), the authority may issue a new license to the pilot by generating a new block 432 that contains the pilot's name as a key, and a value field that includes the pilot's blockchain address 411, public key, and the pilot license designation 433. (paras 0063-0064).
Kilpatrick 2018/0240165
For purposes of illustration, assume that the block-issuing node 16.sub.BIN authorizes the activation request transaction, generates an authorized transaction, and adds the authorized transaction to pending blockchain block (step 124). The activation request transaction may include certain information, such as the date and time that the authorized transaction was generated, the software instance type, and an amount of time that the software instance 22 is permitted to execute before requesting a renewal. The pending blockchain block may not yet be committed to the blockchain 18. The block-issuing node 16.sub.BIN may wait until a predetermined length of time has elapsed before committing the pending blockchain block to the blockchain 18 (para 0038).
Dillenberger 2017/0212781
FIG. 4 is a flow diagram 400 illustrating storing content in a blockchain. The process begins in step 402 and immediately proceeds to step 404. A computing node receives a request from a user or entity. The computing node is one of multiple computing nodes in a system using a blockchain protocol to share a data file including transactions and blocks. As described above, the blocks 250 are data to be stored in the blockchain 200 and the record blocks 210 are records that confirm when and in what sequence certain transaction became journaled as part of the blockchain 200. Typically the request received is signed by a user system 306, 308 to include a new transaction with a plurality of transactions each with additional data to add as a new block 318 in the blockchain 310 in step 406. (paras 0039-0040).
Carey 2018/0165476
A typical blockchain includes three primary functions: read, write, and validate. For example, a user of the blockchain must have the ability to read the data that resides on the blockchain. A user of the blockchain must also have the ability to write, e.g. append, data to the blockchain. Every write operation starts out as a proposed transaction that is posted on the network. The transaction may be submitted for addition to the blockchain by a user of the blockchain, for example, a wallet application or other application program interface (API). Once submitted, the proposed transaction is added to a pool of available transactions for addition to the blockchain. Validator nodes associated with the blockchain may then select transactions from the pool for addition to a new block. (para 0003). Once ordered, the transactions are packaged into a new block, and the new block is voted on by the validator nodes associated with the blockchain to determine whether to add the new block to the blockchain. If a consensus to add the new block is reached, e.g., a threshold number of “for” votes, the new block may be appended to the blockchain. Each new block that is appended to the blockchain also includes a hash of the previous block. Accordingly, as each new block is added, the security and integrity of the entire blockchain is further enhanced. It is important to note that once data is written to the blockchain, for example, once a block including a set of transactions has been appended to the blockchain, that data can no longer be altered or modified. (para 0005).
US Patents
Awasthy 11,501,365
Information associated with loans on personal property assets, such as vehicles or buildings, may be managed. An access computing device may be configured to access a blockchain network including a plurality of node computing devices that store a respective copy of a plurality of blockchains, each blockchain including a sequence of one or more blocks. The access computing device may manage communication of data between the blockchain network and a loan applicant or loan provider. The access computing device may transmit instructions to a node computing device to generate new blocks in the blockchain associated with new and/or updated loans on a personal property asset. (Abstract). Access computer device 104 may be further communicatively coupled to a database 120 that stores data. For instance, database 120 may be a local or remote database 120 associated with a loan provider and configured to store data not stored in blockchain network 108 and/or store a local copy of certain data stored in blockchain network 108. (col. 11 lines 13-18).
Fisher 11,831,748
Contemplated within the scope of the invention is a system of nonfederated nodes configured for a form of blockchain fork resolution. Such system comprises: one or more identifiers of subordinate blockchain forks that indicate a plurality of potential competing subchains; one or more calculators of a proof-of-publication score of each alternative blockchain that results from mapping of the potential competing subchains; one or more recorders of the proof-of-publication scores; one or more subchain removers; and one or more subchain incorporators. (col. 6 lines 46-55). FIG. 7 illustrates the relationship between the subordinate and master blockchain with regards to data publication. The block header (or other blockchain state data) from the subordinate blockchain 702 is published to the master blockchain 703, and then a proof of that publication is constructed 705 and published to the subordinate blockchain 704 which demonstrates the existence of data proving the subordinate block header 702 inside the master block header 701. This publication and proof of publication process is done by a PoP miner, who takes blockchain state data from the subordinate blockchain (a block header, in this instance), publishes it to the master blockchain, waits for a block on the master blockchain (col 7 line 66 – col. 8 line 11).
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 extension fee 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 date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner ROBERT STEVENS whose telephone number is (571) 272-4102. The examiner can normally be reached Mon - Fri 6:00 - 2: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, Amy Ng can be reached on (571) 270-1698. 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.
/ROBERT STEVENS/Primary Examiner, Art Unit 2164
March 31, 2026
Prosecution Insights