Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This communication is a Non-Final Office Action rejection on the merits. Claims 1-26 are currently pending and have been addressed below.
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-26, are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-13 are directed to a machine (i.e., an apparatus), and claim 14-26 are directed to a process (i.e., a method), therefore, these claims fall within the four statutory categories of invention. Thus, the eligibility analysis proceeds to Step 2A.1.
The limitations of independent claim 14, which is representative of independent claim 1, have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 14 are identified in bold below:
[A] A method for probing channel balances, comprising:
[B] transmitting [i.e., sending] a transfer command through a path from an initial node, through at least one intervening node, to a terminal node, wherein the at least one intervening node includes at least a nominal quantitative value;
[C] receiving, from the at least one intervening node, a first proof of transfer, wherein the first proof of transfer is generated as a function of the transfer command and the at least a nominal quantitative value;
[D] receiving, from the terminal node, a second proof of transfer; and
[E] verifying the first proof of transfer as a function of the second proof of transfer.
Limitations A-E under the broadest reasonable interpretation covers steps or
functions of certain methods of organizing human activity, specifically managing
personal/commercial behavior (e.g., probing, transmitting [e.g., sending], receiving,
generate, verifying). For example, the disclosure establishes sending a request to
transfer funds between entities, receiving confirmation of the transfer from the entities
involved and verify proof of transfers, which is a form of commercial and legal activities,
fits squarely within the “certain methods of organizing human activity” grouping of
abstract ideas.
Accordingly, claim 14, recite at least one abstract idea and the analysis proceed to Step
2A.2. The judicial exception is not integrated into a practical application. In particular,
claim 14, recites the additional elements in bold below:
[A] A method for probing channel balances, comprising:
[B] transmitting [i.e., sending] a transfer command through a path from an initial node, through at least one intervening node, to a terminal node, wherein the at least one intervening node includes at least a nominal quantitative value;
[C] receiving, from the at least one intervening node, a first proof of transfer, wherein the first proof of transfer is generated as a function of the transfer command and the at least a nominal quantitative value;
[D] receiving, from the terminal node, a second proof of transfer; and
[E] verifying the first proof of transfer as a function of the second proof of transfer.
[F] Additionally, claim 1 recites an apparatus for probing channel balances, the apparatus comprising: at least a processor; and a memory communicatively connected to the at least processor, the memory containing instructions configuring the at least processor to: identify a path, wherein the path includes: an initial node; a terminal node; and
at least one intervening node communicatively connecting the initial node to the terminal node, wherein the at least one intervening node includes at least a nominal quantitative value;
The additional elements (“an initial node, through at least one intervening node, to a terminal node”, “an apparatus for probing channel balances, the apparatus comprising: at least a processor; and a memory communicatively connected to the at least processor, the memory containing instructions configuring the at least processor to: identify a path, wherein the path includes: an initial node; a terminal node; and at least one intervening node communicatively connecting the initial node to the terminal node, wherein the at least one intervening node”), are no more than a generic computer performing operations to automate the transfer transaction. When the additional elements are considered individually and as an ordered combination, the claim as a whole, amounts to no more than or mere instructions to implement an abstract idea on a computer/a decentralized distributed ledger, or merely uses a computer as a tool to perform an abstract idea. Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment (e.g., “an initial node, through at least one intervening node, to a terminal node”, “an apparatus for probing channel balances, the apparatus comprising: at least a processor; and a memory communicatively connected to the at least processor, the memory containing instructions configuring the at least processor to: identify a path, wherein the path includes: an initial node; a terminal node; and at least one intervening node communicatively connecting the initial node to the terminal node, wherein the at least one intervening node”), defined by high level recitations of a computer/a decentralized distributed ledger and the Internet. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than generally link the abstract idea to a technological environment through “instructions” performed by a generic computer. Because those instructions embody the abstract idea, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer. This is not enough to provide an inventive
concept. Therefore, claims 1 and 14 are not patent eligible.
Dependent claims 2-8, which is a representative of claim 15-21, further recites
wherein the first proof of transfer comprises a secure proof that can be used to validate the identity of the at least one intervening node; wherein the second proof of transfer comprises a secure proof that can be used to validate the identity of the terminal node; wherein the first proof of transfer comprises a secure proof that can be used to validate the time at which the secure proof was generated; wherein the second proof of transfer comprises a secure proof that can be used to validate the time at which the secure proof was generated; wherein the first proof of transfer comprises information on whether the at least a nominal quantitative value is below a value; wherein the second proof of transfer comprises information on whether the at least a nominal quantitative value is below a value; wherein the second proof of transfer is generated as a function of the transfer command and the at least a nominal quantitative value. Under the broadest reasonable interpretation covers steps or functions of certain methods of organizing human activity, specifically managing personal/commercial behavior. For example, the claims establish sending a request to transfer funds between entities, receiving confirmation of the transfer from the entities involved and verify proof of transfers, which is a form of commercial and legal activities, fits squarely within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of Step 2A. The claims do not recite any new additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, claims 2-8 and 15-21 are not patent eligible.
Dependent claims 9-13, which is a representative of claim 22-26, further recites wherein the memory contains instructions configuring the at least processor to transmit the transfer command without disclosing a valid preimage for the transfer command; wherein the transfer command comprises a randomly generated hash; wherein the initial node, the at least one intervening node, and the terminal node are nodes within a network of channels that facilitates off-blockchain transactions enforceable on a blockchain; wherein the blockchain is a bitcoin blockchain; wherein the network is the lightning network. Under the broadest reasonable interpretation covers steps or functions of certain methods of organizing human activity, specifically managing personal/commercial behavior. For example, the claims establish obfuscating the request [i.e., command] to transfer funds between entities, by protecting and secure the transaction data, which is a form of commercial and legal activities, fits squarely within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of Step 2A. The claims do not recite any new additional elements (despite the mention of bitcoin and lightning blockchain), that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. As discussed under Step 2A.2, above, the additional element(s) amount to no more than generally link the abstract idea to a technological environment through “instructions” performed by a generic computer. Because those instructions embody the abstract idea, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer. Therefore, claims 9-13 and 22-26 are not patent eligible.
In summary, the dependent claims considered both individually and as an
ordered combination do not provide meaningful limitations to transform the abstract idea
into a patent eligible application of the abstract idea such that the claims amount to
significantly more than the abstract idea itself. The claims do not recite an improvement
to another technology or technical field, an improvement to the functioning of the
computer itself, or provide meaningful limitations beyond generally linking an abstract
idea to a particular technological environment. Therefore, the claims 1-26 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC §102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless -
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-12 and 14-25 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Stefan et al., (WO 2017060816 A1).
Regarding claims 1 and 14, Stefan, teaches an apparatus for probing channel balances, the apparatus comprising: at least a processor; and a memory communicatively connected to the at least processor, the memory containing instructions configuring the at least processor to: {see at least ¶¶ 76, 114}, and a method for probing channel balances, comprising:
transmitting a transfer command through a path from an initial node, through at least one intervening node, to a terminal node, wherein the at least one intervening node includes at least a nominal quantitative value {see at least Fig. 11, ¶ 159 “…A transfer chain may have one intermediary computing device, the intermediary computing device 100, which may also be a trusted system for the transfer chain. At time 1110, the sender computing device 300 may send a hold authorization to the intermediary computing device 100. At time 1120, the intermediary computing device 100 may instruct the resource tracking computing device 200, which may act as a sender-intermediary resource tracking system, to put a hold on resources owned by the sending party. The instruction may include the hold authorization from the sender computing device 300. The intermediary computing device 100 may instruct the resource tracking computing device 600, which may act as an intermediary-receiver resource tracking system, to put a hold on resources owned by the intermediary party that uses the intermediary computing device 100…”}.
receiving, from the at least one intervening node, a first proof of transfer, wherein the first proof of transfer is generated as a function of the transfer command and the at least a nominal quantitative value {see at least ¶ 159 “…At time I 130, the intermediary
computing device I 00 may receive prepared transfer receipts from the resource tracking computing devices 200 and 600, indicating that holds have been placed on the sending party's resource and the intermediary party's resources. At time 1140, the intermediary computing device 100 may send both the signed message and execute
instructions to both the resource tracking computing devices 200 and 600. At time 1150, the resource tracking computing devices 200 and 600, which may have executed their respective transfers on receiving the signed message and execute instruction from the intermediary computing device 100, may send transfer confirmation receipts to the intermediary computing device 100…”}.
receiving, from the terminal node, a second proof of transfer {see at least ¶ 159 “…The resource tracking computing device 600 may also send a notification that the transfer of resources was completed to a receiver computing device 1100, which may be any suitable computing device used by the receiving party. At time 1160, the intermediary computing device 100 may notify the sender computing device 300 that the transfer is complete”}, and
verifying the first proof of transfer as a function of the second proof of transfer {see at least ¶ 56 “…The initiator or coordinator may send the receipt to the member nodes the temporary consensus network The receiver may also send the receipt directly to the member nodes of the temporary consensus network The member nodes of the temporary consensus network may verify the receipt from the receiver, for example, verifying a cryptographic signature on the receipt to ensure it is from the receiver or system of the party to whom the receiving party delegated responsibility. The member nodes may approve the transfer by notarizing the receipt, for example, over signing the
receipt and timestamping the receipt with the time the receipt was submitted to the member nodes of the temporary consensus network”}.
Regarding claims 2 and 15, Stefan, teaches wherein the first proof of transfer comprises a secure proof that can be used to validate the identity of the at least one intervening node {see at least ¶ 37 “…for example, the receiving of a signed message from a computing device or system trusted by all of the parties participating in the transfer indicating that the transfer can proceed, the receiving of a receipt, such as a pre-agreed upon signed message, from a specified party which may be the receiving party or some third-party to whom the receiver has delegated responsibility. The specified third party may be, for example, one of the intermediaries or resource tracking systems in the transfer chain, a third-party notary, or some other suitable party”}.
Regarding claims 3 and 16, Stefan, teaches, wherein the second proof of transfer comprises a secure proof that can be used to validate the identity of the terminal node {see at least ¶ 37}.
Regarding claims 4 and 17, Stefan teaches wherein the first proof of transfer comprises a secure proof that can be used to validate the time at which the secure proof was generated {see at least ¶ 45 “…The member nodes may also verify timestamps on the prepared transfer receipts, to ensure that the resources were held before a transfer deadline or timeout”, and also ¶ 56 “…The member nodes may approve the transfer by notarizing the receipt, for example, over signing the receipt and timestamping the receipt with the time the receipt was submitted to the member nodes of the temporary consensus network The over signed receipt may be sent back the initiator or coordinator, which may present the over signed receipt to the sender, receiver, intermediaries, and resource tracking systems as proof that the transfer was approved”}.
Regarding claims 5 and 18, Stefan teaches, wherein the second proof of transfer comprises a secure proof that can be used to validate the time at which the secure proof was generated {see at least ¶¶ 45, 56}.
Regarding claims 6 and 19, Stefan teaches, wherein the first proof of transfer comprises information on whether the at least a nominal quantitative value is below a value {see at least ¶ 39 “…The resources for both the sending party and for the next party in the transfer chain may be of the same type. Once the hold has been authorized, the next party in the transfer, for example, an intermediary party using an intermediary computing device, or "intermediary," may cause the resource tracking system to implement the hold on the resources as authorized by the sending party. This may lock up some quantity of the sending party's resources, preventing other transfers from reducing the quantity of the sending party's resources on the sender-intermediary resource tracking system below the held quantity for some time period. The sender-intermediary resource tracking system may send a hold receipt (a "prepared transfer receipt") that may indicate that the requested hold has been placed on the resource in preparation for the planned transfer”, and ¶ 52 “…In some implementations, the receiver may automatically reject transfers for any suitable reason without intervention by the receiving party. For example, the receiver may be configured to automatically reject transfers when the receipt from the intermediary-receiver resource tracking system indicates the amount or value of the resources being held for transfer to the receiving party's account is wrong”}.
Regarding claims 7 and 20, Stefan teaches, wherein the second proof of transfer comprises information on whether the at least a nominal quantitative value is below a value {see at least ¶¶ 39, 52}.
Regarding claims 8 and 21, Stefan teaches, further comprising estimating the at least a nominal quantitative value {see at least ¶¶ 39, 52}.
Regarding claims 9 and 22, Stefan teaches, wherein the initial node does not disclose to the terminal node or to the at least one intervening node a valid preimage for the transfer command {see at least ¶¶ 39 “…The resources for both the sending party and for the next party in the transfer chain may be of the same type. Once the hold has been authorized, the next party in the transfer, for example, an intermediary party using an intermediary computing device, or "intermediary," may cause the resource tracking system to implement the hold on the resources as authorized by the sending party”}.
Regarding claims 10 and 23, Stefan teaches, wherein the transfer command comprises a randomly generated hash {see at least ¶ 54 “…The receipt sent by the receiver may be implemented using, for example, a one-way function, such as a hash function. For example, the receiver may, when a transfer chain is set up, publish a value derived from subjecting a secret value to a one-way function so that it may be accessed by other systems in the transfer chain. For example, the derived value may be a hash that results from hashing the secret value, and the receiver may publish the hash so that it may be accessed by the intermediaries and resource transfer systems in the transfer chain. The derived value may be published in any suitable manner, for example, being made available at a publicly available network location, a pre-agreed upon network location, or by being sent directly to each of the systems in the transfer chain by the receiver or a coordinator of the transfer, or by being passed sequentially or in any other suitable manner between systems in the transfer chain”}.
Regarding claims 11 and 24, Stefan teaches, wherein the initial node, the at least one intervening node, and the terminal node are nodes within a network of channels that facilitates off-blockchain transactions enforceable on a blockchain {see at least ¶ 66 “…A resource tracking system may be any suitable system for tracking resources owned by various parties, and for transferring resources between parties. A resource tracking system may be any suitable computing device or system, with any suitable combination of hardware and software, such as, for example, a system run by a financial institution, a hardware or software component of a server system or computing device, or a distributed system, such as, for example, a cryptocurrency ledger or blockchain which may exist on a number of different computing devices and be reconciled in a collaborative fashion, or may be centralized”}.
Regarding claims 12 and 25, Stefan teaches, wherein the blockchain is a bitcoin blockchain {see at least ¶ 66 “…A resource tracking system may be any suitable computing device or system, with any suitable combination of hardware and software, such as, for example, a system run by a financial institution, a hardware or software component of a server system or computing device, or a distributed system, such as, for example, a cryptocurrency ledger or blockchain…”}.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 3
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, 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.
Claims 13 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over by Stefan et al., (WO 2017060816 A1) in view of Reese et al., (US 20200167775 A1).
With respect to claims 13 and 26, Stefan teaches all the subject matter as disclosed in claims 9 and 25 above, but does not explicitly disclose wherein the network is the lightning network.
However, Reese discloses wherein the network is the lightning network {see at least ¶ 0040 “…The private transaction manager may be a subsystem of a specific blockchain platform/system that implements privacy and permissioning, and/or validates blocks for inclusion in a blockchain. Off-chain transactions involve the movement of value outside of a blockchain, while on-chain transactions modify the blockchain and depend on the blockchain to validate transactions. Off-chain transactions rely on other mechanisms to record and validate transactions, such as payment channels (e.g., Hashed Timelock Contracts (HTLCs) or Lightning Network), sidechains, credit/debit-based solutions, trusted third parties, and the like”}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Stefan to include the elements of Reese to have a subsystem of a specific blockchain platform/system that implements privacy and permissioning, and/or validates blocks for inclusion in a blockchain. Furthermore, Stefan discloses having a resource tracking system in a financial transaction. Reese is merely relied upon to illustrate the functionality of having a subsystem of a specific blockchain platform/system that implements privacy and permissioning, and/or validates blocks for inclusion in a blockchain, in a financial transaction. Because both having a resource tracking system in a financial transaction, as well as having a subsystem of a specific blockchain platform/system that implements privacy and permissioning, and/or validates blocks for inclusion in a blockchain, and are implemented through well-known computer technologies, combining their features as outlined above, would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Stefan, as well as Reese would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Stefan/Reese.
Conclusion
The prior art made of record and not relied upon:
1) (US 20080162348 A1) – Lee et al., Blockchain-based Shared Appreciation Note – relates to an electronic-purse (e-purse) transaction system and method therefor, for instance for making payments, in particular by mobile telephone.
2) (US 20210357916 A1) – Anna Vladi, Systems and Methods for Blockchain-Based Transaction Settlement – relates to a system that include a blockchain network, a trust entity, and multiple user devices. A smart contract of the blockchain network may be configured to receive data from the trust entity and transfer digital stable tokens to a first user's cryptocurrency wallet. The first user may generate a blockchain transaction on the blockchain network in order to transfer some digital stable tokens to a second user.
3) (US Pat. 11734676 B2) – Rule et al., Using A Contactless Card To Securely Share Personal Data Stored In A Blockchain - relate to sharing data, and more specifically, to using a contactless card to securely share personal data stored in a blockchain.
4) (US 20240281796 A1) – Finlow-Bates et al., Systems And Methods For Facilitating Digital Wallet-Based Transactions - generally relates to token storage, and more specifically, to digital wallet security.
5) (US Pat. 12243056 B2) – Wright et al., Computer-implemented Systems And Methods For Implementing Transfers Over A Blockchain Network - relates generally to the communication and transfer of resources via a network, and more particularly to transfers conducted over blockchain networks, and also digital wallets.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number 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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form
/V.I./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698