DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013 is being examined under the AIA first inventor to file provisions.
Power of Attorney
While the power of attorney documents were filed on 08/01/2024, the Office mailed a notice of regarding informal power of attorney on 08/21/2024. The notice indicates the power of attorney forms have not been accepted because they are not signed by applicant for patent. The examiner is noting this issue as it appears to be unresolved at the time this action is being prepared.
Status of Claims
The following is a FINAL Office Action in response to Applicant’s amendments filed on 01/29/2026.
a. Claims 1-4 are amended
b. Claims 5-8 are cancelled
Overall, Claims 1-4 are pending and have been considered below.
Claim Objections
Claim 1 objected to because of the following informalities: Claim 1 recites, “… from one or processors …” should read “… from one or more processors …”. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 USC 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-4 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more.
Per Step 1 of the multi-step eligibility analysis, claims 1-4 are directed to a computer implemented method.
Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention.
Per Step 2A.1. Claim 1 is rejected under 35 USC 101 because the claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application. The limitations of the independent claim 1 recite an abstract idea, shown in bold, while the non-bolded claim elements recite additional element according to MPEP 2106.04(a).
[A] A method for settling cryptocurrency transactions, comprising:
[B] entering a smart contract, on a cryptocurrency network, between a user and a service provider account (SPA), wherein entering the smart contract comprises:
[C] generating the smart contract, on the cryptocurrency network, allowing the transfer of a maximum number of tokens from a user's wallet to a Service Provider wallet associated with the Service Provider, wherein generating the smart contract comprises:
[D] accessing terms of agreement of the smart contract, utilizing a user device; and
[E] inputting acquiescence to the agreement utilizing the user device; and
[F] recording the smart contract on a ledger on the cryptocurrency network;
[G] entering a second smart contract, on the cryptocurrency network, between a merchant and the SPA, wherein entering the second smart contract comprises recording the second smart contract on the ledger on the cryptocurrency network;
[H] receiving, at one or more processors associated with a Service Provider, from one or processors associated with a merchant, a request from a merchant to approve an amount for a point-of-sale (POS) transaction;
[I] determining, by the one or more processors associated with the service provider, whether to approve the amount for the POS transaction based on spending power associated with the user, the spending power calculated as a wallet balance associated with a user minus a card balance associated with the user, wherein the card balance comprises a cumulative total of unsettled transactions associated with the user;
[J] approving, utilizing the one or more processors associated with the Service Provider, the request from the merchant based on the determined approval;
[K] updating, utilizing the one or more processors, the card balance associated with the user and a merchant account balance, based on approving the amount for the transaction;
[L] forwarding a new on-chain transaction request and a second on-chain transaction request to the cryptocurrency network after updating the card balance, from the one or more processors associated with the Service Provider, to execute the smart contract and the second smart contract; and
[M] initiating a token transfer and a second token transfer, on the cryptocurrency network, by executing the smart contract and the second smart contract.
Claim 1 recites: settling cryptocurrency transaction ([A]); entering and generating a contract ([B]-[C], [G]); accessing, agreeing and recording the contract ([D]-[F]); receiving a request ([H]); determining whether to approve the amount ([I]); approving the request ([J]); updating the balance ([K]); and forwarding a new request and initiating a transfer ([L]-[M]), which, based on the claim language and in view of the application disclosure, represents a process aimed at processing cryptocurrency transaction.
The overall combination, covers agreement in form of agreement in the form of contracts, sales activities or behaviors, business relationships because the claim language recites accessing, agreeing and recording the contract, approving transaction, updating the balance after approval. Additionally, the applicant’s specification recites on [0011] “to initiate a transaction, users, merchants, and a service provider may enter an exemplary smart contract”. The one of skill in the art can determine that a transaction in being performing utilizing a contract. Additionally, the recited claim limitation above falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is reasonable to conclude that claim 1 recites an abstract idea that corresponds to a judicial exception.
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)). For example, the added elements “smart,” “token,” and “device,” “one or more processors,” “POS” recite computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of processing cryptocurrency transaction. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application.
The additional elements in the independent claims, shown not bolded above, recite: smart ([B]-[D], [F]-[G], [L]-[M]), token ([C], [M]), device ([D], [E]), one or more processor ([H]-[L]), point of sale (POS) ([H]-[I]). When considered individually, they amount to nothing more than reception, transmission and/or general computation (i.e., not specific enough computation) of claim elements that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea.
Therefore, the additional steps of claim 1 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Therefore, when considered as a whole and as an ordered combination, the additional elements in the claim amount to instructions to apply the abstract idea on a computer. Moreover, as noted above, there is nothing the computing and additional elements (limitations [B]-[M]), that is significant or meaningful to the underlying abstract idea because the identified abstract idea of processing cryptocurrency transaction could have been reasonably performed when provided with the relevant data and/or information. Therefore, it is concluded that independent claim 1 is deemed ineligible.
Dependent Claims: Claims 2-4 are analyzed for subject matter eligibility. However, these claims fails to recite patent eligible subject matter for following reasons:
Claim 2, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] updating a ledger on the cryptocurrency network.
The claim further recites the abstract idea of processing cryptocurrency transaction. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 3, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein: initiating the token transfer comprises initiating the token transfer, on the cryptocurrency network, by executing the smart contract previously recorded on the ledger on the cryptocurrency network, wherein executing the smart contract comprises transferring a quantity of tokens corresponding to the user's card balance from the user's wallet; and
[B] initiating the second token transfer comprises initiating the second token transfer, on the cryptocurrency network, by executing the second smart contract previously recorded on the ledger on the cryptocurrency network, wherein executing the second smart contract comprises
[C] transferring a second quantity of tokens corresponding to the merchant account balance to a merchant wallet.
The claim further recites the abstract idea of processing cryptocurrency transaction. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 3, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein initiating the second another token transfer occurs before initiating the token transfer.
The claim further recites the abstract idea of processing cryptocurrency transaction. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
When the dependent claims are considered as a whole, as an ordered combination, the claim elements noted above appear to merely apply the abstract concept to a technical environment in a very general sense, i.e., a computer receives information from another computer, processes that information and then sends a response based on processing results. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the computing devices are facilitating the abstract concept is not enough to confer subject matter eligibility. Overall, the further elements do not confer subject matter eligibility to the invention since their individual and combined significance are not changing the nature of the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly
more. (See MPEP 2106.05).
In sum, Claims 1-4 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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 non-obviousness.
Claims 1-4 are rejected under 35 U.S.C. 103 as being unpatentable over Sells (US 20220051219 A1), in view of Brock (US 20190034889 A1), in further view of Abbas (US 20240386427 A1).
Regarding Claim 1. Sells discloses:
entering a smart contract, on a crypto currency network, between a user and a service provider account (SPA), wherein entering the smart contract comprises: [see at least Fig. 1 (0054) the platform 100 may include an orchestration services system 102, including automated services 104 that may utilize smart contracts 108 … managing a wallet, such as a cryptocurrency wallet 112 using the native interfaces. (0056) The platform 100 may further include … a financial service provider (FSP) system 212]
smart contract, on the cryptocurrency network, allowing the transfer of a maximum number of tokens from a user's wallet to a Service Provider wallet associated with the Service Provider [see at least (0013) the exchange may be automatically performed by the platform based at least in a part on a rule stored in a smart contract. The rule may relate to a minimum cryptocurrency valuation to be met prior to making the exchange, a maximum cryptocurrency valuation, a range of cryptocurrency valuations, a fiat currency valuation (such as an exchange rate with one or more other forms of fiat or cryptocurrencies), an interest rate range, a transaction size (minimum, maximum, or range)]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific
teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that in order to perform transaction using smart contract, one of the rule is the maximum cryptocurrency evaluation (i.e. maximum number of token). And, therefore one of skill in the art would have understood the reference to teach the limitation.
entering a second smart contract, on the cryptocurrency network, between a merchant and the SPA, wherein entering the second smart contract comprises recording the second smart contract on the ledger on the cryptocurrency network [see at least Fig. 1 (0054) the platform 100 may include an orchestration services system 102, including automated services 104 that may utilize smart contracts 108 … managing a wallet, such as a cryptocurrency wallet 112 using the native interfaces. (0056) The platform 100 may further include … a financial service provider (FSP) system 212]
receiving, at one or more processors associated with a Service Provider, from one or processors associated with a merchant, a request from a merchant to approve an amount for a point-of-sale (POS) transaction; [see at least Fig. 10, [0098] The user may initiate a fiat currency payment transaction funded by a cryptocurrency on the user's application … The request may be received at the user's bank. The bank may relay the request to the third-party financier and the user's wallet holder … the wallet holder may transfer an amount of cryptocurrency to an account of the third-party financier … The merchant may receive the currency selected for the purchase of a good or service or other transaction type as an outcome of this process 1018. (0100) The user may complete a transaction at a point-of-sale 1206, which may be an in-store purchase in a brick-and-mortar merchant establishment, an online merchant establishment, or some other transaction location.]
determining, by the one or more processors associated with the service provider, whether to approve the amount for the POS transaction based on spending power associated with the user, the spending power calculated as a wallet balance associated with a user minus a card balance associated with the user, wherein the card balance comprises a cumulative total of unsettled transactions associated with the user; [see at least Figs. 10, 15, (0098) Upon receipt of the cryptocurrency, the third-party financier may transfer a sum of fiat currency to an account associated with the bank. Upon receipt of the funds, the bank may authorize the payment. (0100) The user may complete a transaction at a point-of-sale 1206, which may be an in-store purchase in a brick-and-mortar merchant establishment, an online merchant establishment, or some other transaction location. (0130) a user may have selected fiat and only has and insufficient amount 1502, for example $1,000 available on a purchase that requires $2,000. If the user has available cryptocurrency in excess of the difference, the system may enable the user to spend both forms of currency]
approving, utilizing the one or more processors associated with the Service Provider, the request from the merchant based on the determined approval; [see at least Figs. 10, (0098) Upon receipt of the cryptocurrency, the third-party financier may transfer a sum of fiat currency to an account associated with the bank. Upon receipt of the funds, the bank may authorize the payment.]
forwarding a new on-chain transaction request and a second on-chain transaction request to the cryptocurrency network …, from the one or more processors associated with the Service Provider, to execute the smart contract and the second another smart contract; and [see at least (0013) the exchange may be automatically performed by the platform based at least in a part on a rule stored in a smart contract. (0087) a smart contract that facilitates transaction execution. (0098) The bank may relay the request to the third-party financier and the user's wallet holder … the wallet holder may transfer an amount of cryptocurrency to an account of the third-party financier.]
initiating a token transfer and a second another token transfer, on the cryptocurrency network, by executing the smart contract and the second another smart contract. [see at least (0011) the cryptocurrency amount corresponds to the request for payment based on the cryptocurrency valuation, exchanging the cryptocurrency amount for a fiat currency amount of corresponding value, and transferring the fiat currency amount to the entity to satisfy the request for payment. (0098) the wallet holder may transfer an amount of cryptocurrency to an account of the third-party financier.]
Sells discloses performing transaction using smart contract, however, Sells does not disclose:
generating the smart contract … wherein generating the smart contract comprises:
accessing terms of agreement of the smart contract, utilizing a user device; and
inputting acquiescence to the agreement utilizing the user device; and
recording the smart contract on a ledger on the cryptocurrency network;
updating, utilizing the one or more processors, the card balance associated with the user and a merchant account balance, based on approving the amount for the transaction;
Nonetheless, Brock discloses:
updating, utilizing the one or more processors, the card balance associated with the user and a merchant account balance, based on approving the amount for the transaction; [see at least (0078) Payment service can then debit cryptocurrency ledger 204 for the value calculated at step 312 and credit payment service 108's cryptocurrency ledger 219 with the same value.]
In addition, 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 the features of Sells to include the features of Brock. A person a having the ordinary skill in the art would have been motivated to accurately perform transaction using the smart contract as taught by Sells and updating the balance as taught by Brock. Sells discloses using smart contract to perform transaction. Brock teaches updating the balance to debit the account. Because both Sells as well as Brock are implemented through field of performing transaction in the blockchain and the technique of updating the balance as taught by Brocks would have used the smart contract of Sells to perform blockchain transaction. Moreover, since the features disclosed by Sells as well as Brock 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 Sells/Brock.
The combination of Sells in view of Brock discloses performing transaction using smart contract. However, the above combination does not disclose:
generating the smart contract … wherein generating the smart contract comprises:
accessing terms of agreement of the smart contract, utilizing a user device; and
inputting acquiescence to the agreement utilizing the user device; and
recording the smart contract on a ledger on the cryptocurrency network;
However, Abbas discloses:
generating the smart contract…wherein generating the smart contract comprises: [see at least (0073) When a smart contract is created, it is compiled into bytecode and stored on the blockchain network 200]
accessing terms of agreement of the smart contract, utilizing a user device; and [see at least (0082) The indication of acceptance may include an acknowledgement to one or more terms of the smart contract. (0089) a graphical user interface may be displayed that includes terms and conditions of an agreement]
inputting acquiescence to the agreement utilizing the user device; and [see at least (0082) The indication of acceptance may include an acknowledgement to one or more terms of the smart contract. (0089) the mobile application, the server computer system 120 may cause the client device 110 to display a request for the voice input to trigger execution of the smart contract … a message requesting voice input such as for example “Please confirm that you agree to these terms and conditions.”]
recording the smart contract on a ledger on the cryptocurrency network; [see at least (0073) When a smart contract is created, it is compiled into bytecode and stored on the blockchain network 200, along with a set of rules that determine how the smart contract will execute.]
In addition, 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 the features of Sells, Brock to include the features of Abbas. A person a having the ordinary skill in the art would have been motivated to perform blockchain transaction using the smart contracts as taught by Sells, Brock and using the specified agreement of the smart contract as taught by Abbas. Sells, Brock discloses performing transaction using smart contract. Abbas teaches specifying terms of the smart contract. Because both Sells, Brock as well as Abbas are implemented through field of completing blockchain transaction and terms and agreement of smart contract as taught by Abbas would have used the cryptocurrency transaction of Sells, Brock to securely perform the transaction. Moreover, since the features disclosed by Sells, Brock as well as Abbas 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 Sells, Brock/Abbas.
Regarding Claim 2. Sells, Brock, Abbas discloses the limitations of Claim 1. Brock further discloses:
comprising updating a ledger on the cryptocurrency network.[see at least Fig. 4A (0039) transactions involving cryptocurrency, payment service 108 can communicate over network(s) 110 with cryptocurrency network 145. [0040] merchants 102 sending the transaction data directly to the payment service 108 as part of the request to authorize the payment instrument]
In addition, 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 the features of Sells, Brock, Abbas to include the additional features of Brock. A person a having the ordinary skill in the art would have been motivated to accurately record transaction using the cryptocurrency transaction of Sells, Brock, Abbas and using the technique of updating the ledger as taught by Brock. Sells, Brock, Abbas discloses performing transaction using smart contract. Brock teaches updating the ledger. Because both Sells, Brock, Abbas as well as Brock are implemented through field of performing blockchain transaction and the technique of updating the ledger as taught by Brock, and using the cryptocurrency transaction of Sells, Brock, Abbas to accurately record the transaction. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 3. Sells, Brock, Abbas discloses the limitations of Claim 2. Sells further discloses:
initiating the token transfer comprises initiating the token transfer, on the cryptocurrency network, by executing the smart contract previously recorded on the ledger on the crypto currency network,, wherein executing the smart contract comprises transferring a quantity of tokens corresponding to the user’s card balance from the user’s wallet; and [see at least (0011) the cryptocurrency amount corresponds to the request for payment based on the cryptocurrency valuation, exchanging the cryptocurrency amount for a fiat currency amount of corresponding value, and transferring the fiat currency amount to the entity to satisfy the request for payment. (0098) the wallet holder may transfer an amount of cryptocurrency to an account of the third-party financier.]
initiating the second token transfer comprises initiating the second token transfer, on the cryptocurrency networking, by executing the second smart contract previously recorded on the ledger on the cryptocurrency network, wherein executing the second smart contract comprises transferring a second quantity of tokens corresponding to the user’s card balance from the user’s wallet; and [see at least (0011) the cryptocurrency amount corresponds to the request for payment based on the cryptocurrency valuation, exchanging the cryptocurrency amount for a fiat currency amount of corresponding value, and transferring the fiat currency amount to the entity to satisfy the request for payment. (0098) the wallet holder may transfer an amount of cryptocurrency to an account of the third-party financier.]
Regarding Claim 4. Sells, Brock, Abbas discloses the limitations of Claim 3. Sells further discloses:
wherein initiating the second token transfer occurs before initiating the token transfer. [see at least (0098) the wallet holder may transfer an amount of cryptocurrency to an account of the third-party financier.]
Note: The Glover reference does not expressly disclose: initiating the second token transfer occurs before initiating the token transfer. However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). The reference is provided for the purpose of compact prosecution.
Response to Amendments/Arguments
With respect to Applicant’s Remarks as to the claims objection(s):
Applicant submits: “Claims 1 and 2 were objected to due to allegedly informalities. Without acquiescing to the propriety of the objections, the Applicant has amended the claims to overcome the objection.”
Examiner Responds: Examiner has fully considered applicant’s arguments, and based on the amendment, claim objection has been withdrawn.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101:
Applicant submits: “This is followed by an on-chain execution of smart contracts (that are recorded on the ledger) triggered only after authorization, via forwarding of distinct on-chain transaction requests. Specifically, the claim 1 recites in part: forwarding a new on-chain transaction request and a second on-chain transaction request to the cryptocurrency network after updating the card balance, from the one or more processors associated with the Service Provider, to execute the smart contract and the second smart contract; and initiating a token transfer and a second token transfer, on the cryptocurrency network, by executing the smart contract and the second-smart contract. (Emphasis added) Accordingly, Applicant respectfully asserts that independent claim 1 does not recite”
Examiner Responds: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant that claim 1 does not recite abstract idea. The amended claim 1 recites accessing, agreeing and recording the contract, approving transaction, updating the balance after approval. Additionally, the applicant’s specification recites on [0011] “to initiate a transaction, users, merchants, and a service provider may enter an exemplary smart contract”. The one of skill in the art can determine that a transaction in being performing utilizing a contract. The recited claim limitation are in agreement in the form of contracts, sales activities or behaviors, business relationships. Additionally, the recited claim limitation above falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)). See the updated rejection above. Thus the rejection is proper and has been maintained.
Applicant submits: “Even assuming arguendo that the claims involve an abstract concept, Applicant respectfully asserts that they integrate that concept into a practical application. Specifically, Applicant asserts that amended claim 1 requires a specific sequencing and enforcement architecture in which: 1. smart contracts are first generated and recorded on the ledger; 2. authorization for a POS transaction is computed using a cumulative unsettled balance maintained by the system; 3. balances are updated upon approval of a request associated with a POS transaction; and 4. on-chain execution is initiated only after approval via distinct on-chain transaction requests. The claimed architecture and exemplary embodiments consistent with the claimed architecture decouple authorization from settlement and enforces authorization constraints at the level of blockchain execution, which is a technical solution to a problem arising from the operation of distributed ledger systems. Claims that control how a networked computer system operates rather than merely using the system as a tool integrate abstract ideas into a practical application. As in Enfish, the proper Step 2A inquiry is whether 'focus of the claims is on the specific asserted improvement in computer capabilities' rather than an abstract idea for which computers are invoked merely as a tool. Here, the claim focus is a specific execution-control architecture for a distributed ledger environment.”
Examiner Responds: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the MPEP 2106.04(d) discloses that “an important consideration to evaluate when determining whether the claim as a whole integrates a judicial exception into a practical application is whether the claimed invention improves the functioning of a computer or other technology In short, first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art Second, if the specification sets forth an improvement in technology. the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement.” (Emphasis added) “That is, the claimed invention may integrate the judicial exception into a practical application by demonstrating that it improves the relevant existing technology although it may not be an improvement over well-understood, routine, conventional activity.” (Emphasis added). Thus, the rejection is proper and has been maintained.
Applicant submits: “generate smart contracts with predefined token transfer limits that are recorded on the ledger; . maintain a cumulative unsettled card balance separate from wallet balance; . compute authorization of a POS transaction using that balance; or . initiate multiple on-chain transaction requests only after approval of the POS transaction. Conclusory statements that elements are conventional are insufficient under Berkheimer v. HP Inc., 881 F.3d 1360, 1369 (Fed. Cir. 2018). The claims recite anon-generic arrangement of technical steps that meaningfully constrain the claim scope and amount to significantly more than any alleged abstract idea. Accordingly, Applicant asserts that the Office Action further fails to establish that the ordered combination of these elements, as recited in claim 1, was well-understood, routine, or conventional.”
Examiner Responds: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant that office action fails to establish that the ordered combination of these elements, as recited in claim 1, was well-understood, routine, or conventional. The office action recites the additional elements of processor, smart, token, device, POS are used as a tool to perform the abstract idea. See the updated rejection above.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits: “Claim 1 expressly requires "generating the smart contract ... allowing the transfer of a maximum number of tokens from a user's wallet to a Service Provider wallet" and "recording the smart contract on a ledger on the cryptocurrency network." Thus, the claim is not directed to ad hoc token transfers, but to the advance creation and on-chain recording of a smart contract that encodes predefined transfer authority. None of the cited references discloses or suggests generating and ledger-recording a smart contract that limits token transfers based on pre-authorized spending authority, as opposed to executing transfers at the time of settlement. The claim further requires "entering a second smart contract ... between a merchant and the [SPA]" and "recording the second smart contract on the ledger on the cryptocurrency network." This limitation recites the existence of two distinct ledger-recorded smart contracts serving different transactional roles, both of which are executed as part of a single transaction flow. The cited art does not disclose or suggest coordinating execution of multiple ledger- recorded smart contracts in response to a single authorized transaction.
Claim 1 additionally requires determining whether to approve a transaction based on "spending power ... calculated as a wallet balance associated with the user minus a card balance associated with the user, wherein the card balance comprises a cumulative total of unsettled transactions associated with the user." The cited references do not disclose maintaining a cumulative unsettled transaction balance that is distinct from the user's wallet balance and used to constrain subsequent authorization decisions. Nor do they teach computing authorization eligibility as a function of both on-chain wallet balance and accumulated unsettled transaction state. Most significantly, claim 1 requires "forwarding a ... on-chain transaction request and a second ... on-chain transaction request ... to execute the smart contract and the second smart contract" only after approval, followed by "initiating a token transfer and a second ... token transfer ... by executing the smart contract and the second ... smart contract." Thus, the claim expressly requires that multiple on-chain transaction requests are initiated only after authorization, and that multiple smart contracts are executed in a coordinated manner to complete a single authorized transaction. The cited references do not disclose or suggest deferring the initiation of on-chain transaction requests until after a separate authorization step, nor do they teach coordinated execution of multiple smart contracts conditioned on prior approval. Accordingly, Applicant respectfully asserts that to arrive at the claimed invention, the cited art would need to be modified to introduce (i) ledger-recorded smart contracts with predefined transfer limits, (ii) cumulative unsettled transaction tracking, (iii) authorization- driven balance updates occurring prior to execution, and (iv) authorization-gated forwarding of multiple on-chain transaction requests. The cited references do not recognize the technical problem addressed by exemplary embodiments consistent with the claimed invention, and therefore provide no motivation to combine their teachings in this manner absent hindsight. Further, Applicant respectfully asserts that the ordering of the steps recited in claim 1 is functional and non-arbitrary. Authorization must occur before on-chain execution, and balances must be updated before transaction requests are forwarded. Reordering these steps would defeat the purpose of the claimed invention. The Office Action improperly treats this sequencing as an obvious design choice when it is, in fact, central to the claimed technical solution. Accordingly, Applicant respectfully requests withdrawal of the rejection of claim 1. Dependent claims 2-4 are allowable at least by virtue of their respective dependencies on independent claim 1, in addition to their own allowable features. For example, with further respect to claim 4, the cited references fail to disclose the claimed elements. For example, "initiating the second token transfer occurs before initiating the token transfer" would be against the principles of operation of the cited art. In the cited references, settlement follows authorization and user debit, not the reverse, and reordering these steps would undermine the references' stated transaction flow. Accordingly, claim 4 is allowable for this additional reason. Accordingly, Applicant respectfully requests the allowance of this application. ”
Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the applicant’s arguments are directed towards the amended claim language and not original set of claims. Additionally, claim 1 has been rejected using the combination of Sells, Brock, Abbas. The Abbas reference recites generating smart contract (see Abbas [0073]). Thus the rejection is proper and has been maintained
Relevant Prior Art Not Relied Upon
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20230169413 A1 Augustine; Scott et al. DAMPENING TOKEN ALLOCATIONS BASED ON NON-ORGANIC SUBSCRIBER BEHAVIORS - Determining portions of instances of a cryptographic token to be allocated to record providers, like providers of an asset indicated by a record, wherein: the portions are determined based on network effects associated with the records the record provider supplied on performance of a computer-implemented network in which both record providers and record consumers participate, patterns indicative of inorganic consumption may be determined from one or more of interactions of individual consumers, interactions of collections of consumers, or consumer interactions in the aggregate for a given provider or record; and the effects on network performance are adjusted responsive to designation of one or more entities as exhibiting inauthentic behavior; and appending to a distributed ledger, records indicating the respective portions, and adjustments, are allocated to record providers.
US 20200311816 A1 Calvin; Ross Way DISTRIBUTED LEDGER INVESTMENT GOVERNANCE PLATFORM - A cryptographic system and mechanism for combining the authenticating of industrial activity and processes and placing investments. Embodiments of the present invention can provide a system that allows for transmitting and filtering oil and gas transactions through a comprehensive, interlocking distributed ledger-based supply chain ecosystem and cryptocurrency-enabled capital funding mechanism, so that such transactions can be monetized to reduce costs, execution times, and risk, while elevating information quality.
US 20240078536 A1 Dashkov; Ivan SYSTEMS AND METHODS USING DIGITAL ASSETS - A method of using a non-fungible token includes the steps of generating a first digital asset with a virtual object and minting a first non-fungible token to secure ownership of the first digital asset to a blockchain. The method further includes the steps of providing the first digital asset on a digital platform and transferring the first non-fungible token to a user wallet. The method also includes the steps of generating a second digital asset and a third digital asset, initiating a first redemption sequence upon occurrence of a first redemption event, and burning the first digital asset.
US 20240330902 A1 Dashkov; Ivan SYSTEMS AND METHODS FOR GENERATING GRAPHICS FOR CRYPTOGRAPHIC TOKENS - A method of generating graphics for digital assets includes receiving an input identifying a first digital wallet. One or more non-fungible tokens associated with the first digital wallet are identified, and at least one non-fungible token is selected from the one or more non-fungible tokens, each token of the selected at least one non-fungible token being associated with a corresponding digital asset including at least one attribute. A graphic is generated based on the at least one attribute of the digital assets corresponding to each of the selected at least one non-fungible token. The graphic is provided to a virtual environment and displayed within the virtual environment.
US 20220261882 A1 Youb; Christopher et al. METHOD FOR CREATING COMMODITY ASSETS FROM UNREFINED COMMODITY RESERVES UTILIZING BLOCKCHAIN AND DISTRIBUTED LEDGER TECHNOLOGY - A token system and method, employing a token representing an interest in a smart contract, comprising: a distributed ledger, storing parameters of a smart contract, the smart contract representing an agreement, secured by a security interest in property, to execute the security interest unless a token is returned within a period; a communication port configured to interface with an automated communication network for communications between a plurality of cryptographic hardware processors; and an automated distributed virtual state machine, hosted by the plurality of cryptographic hardware processors, employing a distributed consensus model for transaction validation, the automated distributed virtual state machine being configured to: communicate distributed consensus messages through the automated communication network; communicate the token; execute the smart contract defined by the parameters, receiving inputs and producing outputs on a blockchain; and communicate an immutable message for exercise of the security interest.
US 11361289 B1 Housser; Chris et al. Distributed cryptographic tokens with downstream administrative control - Disclosed is a platform That enables centralized control over updates to a distributed cryptocurrency network through inclusion of an administrative user to a set of tokens that operate on a base cryptocurrency network but include rule sets that are separate from those of the base cryptocurrency. A plurality of customized token types are generated by a platform provider for respective administrative users. The platform provider may provide software updates that are implemented at the sole discretion of the respective administrative users.
US 20240330906 A1 2024-10-03 Ellis; Mark et al. TOKEN STANDARD IMPLEMENTATION FOR TOKENIZED SECURITIES - Techniques for enforcing transfer restrictions on a regulated securities token include configuring, an account associated with a cryptocurrency wallet to receive a securities token by setting one or more transfer restrictions based in part on one or more identified characteristics associated with the account. Requests to transfer the securities token to a recipient account associated with a regulated transfer group are managed.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6:00pm.
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 at (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.
/M.S.H./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698 *