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 Office Action is in response to an AMENDMENT entered April 10, 2025 for the patent application 19/174,396.
Status of Claims
Claims 1 – 20 are pending in the application.
Claim 1 is currently amended in the application.
Claims 7 - 20 are added in the application.
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.
Claim(s) 1 – 20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 - 20 are either directed to a method or system or computer readable medium, which are statutory categories of invention. (Step 1: YES).
The Examiner has identified method claim 1 as the claim that represents the claimed invention for analysis and is similar to method claim 13 and system claim 20. Claim 1 recites the limitations of:
( A ) presenting an initial interface screen on a display of a terminal depicting a blockchain- based media of value transaction option and a non-blockchain-based transaction option;
( B ) obtaining a workflow and process the workflow based on a selection of the blockchain- based media of value transaction option selected by a user operating the terminal;
( C ) receiving, by the workflow, a transaction identifier for a blockchain-based transaction provided by the user through a second interface screen presented to the user based on the selection;
( D ) processing, by the workflow, a blockchain application programming interface (API) to request conditions for the blockchain-based transaction from a smart contract over a blockchain using the transaction identifier;
( E ) receiving, by the workflow, an amount of fiat currency from the smart contract;
( F ) presenting, by the workflow, a third interface screen to the user requesting that the user provide the amount of the fiat currency as a payment for the blockchain-based transaction;
( G ) verifying, by the workflow, the amount of the fiat currency was received from the user; and
( H ) notifying the smart contract using the API that the amount was verified and received at the terminal.
These limitations without the bolded limitations above, cover performance of the limitations as certain methods of organizing human activity under their broadest reasonable interpretation.
More specifically, these limitations cover performance of the limitations as a fundamental economic practice such.
In summary, if claim 1 limitations, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic practice, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Claims 13 and 20 are also abstract for similar reasons. (Step 2A-Prong 1: YES. The claims are abstract).
The use of the blockchain application programming interface (API) or any of the bolded limitations in claim 1 are just applying generic computer components to the recited abstract limitations. Similar arguments apply to claims 13 and 20.
Therefore, the above mentioned judicial exception is not integrated into a practical application by merely applying generic computer components (bolded elements).
Furthermore, the “presenting”, “obtaining” and “receiving” steps are recited at a high level of generality and amounts to mere data gathering/transmitting, which are forms of insignificant extra-solution activity (See MPEP 2106.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
In addition, supported by specification, the computer hardware are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component., see MPEP 2106.05(f), where applying a computer or using a computer is not indicative of a practical application).
Claim 1, limitations ( A ) and ( C ) above in Applicant’s specification para [0029], which discloses “Assuming that the buyer is going to fulfill the obligation to pay, the buyer goes to an SST 140 to fulfill that obligation. Transaction interface 143 presents a smart con-tract option on an interface screen of the SST 140. When this is selected by the buyer, a smart contract or blockchain-based workflow is executed on the SST 140. The buyer is asked to enter the transaction identifier provided by decentralized transaction service 113 when the smart contract 133 was created. The workflow then uses blockchain API 144 to interact with the smart contract 133 to obtain any conditions needed by the SST 140 to process this portion of the transaction on the SST 140, such as an amount due by the buyer in fiat currency, an amount of blockchain-based media of value that will be transferred to the buyer's wallet, type of blockchain-based media of value, etc. The conditions are displayed on a workflow interface screen to the buyer. The buyer is then asked to deposit the fiat currency in the amount in a media depository of the SST 140. The buyer deposits the fiat currency into the media depository and the workflow, utilizing existing peripherals and currency verification techniques, verifies that the fiat currency is legitimate or is not counterfeit and verifies that the amount deposited matches the amount expected by smart contract 133.“.
Also, claim 1, limitations ( A ) and ( H ) above in Applicant’s specification para [0068], which discloses “At 310 (shown in FIG. 3A), transaction interface presents an initial interface screen or splash screen on a display of a terminal 140. The splash screen depicts a blockchain-based media of value transaction option and a non-blockchain-based media of value transaction option. The non-blockchain-based media of value transaction option may include a fiat currency-related transaction, a reservation transaction, an information-related transaction, etc.“.
Also, claim 1, limitations ( A ) and ( B ) above in Applicant’s specification para [0040], which discloses “System 100 provides an intermediary to P2P buy-lock chain-based media of value and sellers of blockchain-based media of value for fiat currency. The fiat currency can be any government-backed currency note, such as dollars, euros, etc. The seller can receive the fiat currency through SST withdrawals or via automatic financial account transfer. Alternatively, the seller may request that the fiat currency be used to purchase stable cryptocurrency or a different type of cryptocurrency/NFTs from the sold block-chain-based media of value which is automatically transferred to the seller's wallet. The buyers may provide the fiat currency to the SSTs 140 through deposits of government-backed notes or cash at the SSTs 140, debit card transactions at the SSTs 140, and/or credit card transactions at the SSTs 140.“.
Also, claim 1, limitations ( E ) and ( H ) above in Applicant’s specification para [0028], which discloses “Decentralized transaction service 113 then generates an instance of a smart contract 133 that embeds the conditions and enforces the conditions of the transaction. Decentralized transaction service 113 also generates a trans-action identifier for accessing the smart contract 133 over the blockchain. The transaction identifier is sent to the seller and buyer through their service apps 123. Next, decentralized transaction service 113 activates source code instructions for smart contract 133 on the blockchain via the blockchain devices 130 using a blockchain API associated with APIs 114. The smart contract may be provided the blockchain-based media of value within the source code of the smart contract or may be provided a wallet identifier for a wallet that is associated with the decentralized transaction service 113. The blockchain-based media of value is held in escrow for the seller and the buyer and controlled by the conditions of the contract, which are enforced through execution of the smart contract 133 on the blockchain. The contract conditions may include a time period during which the buyer needs to fulfill the condition or obligation to pay for the blockchain-based media of value of the transaction such that when the time period expires, the smart contract will process instructions that transfers the blockchain-based media of value to the seller's wallet. It is noted that a variety of other conditions may be established, each of which are enforced by the smart contract 133 during its execution on the blockchain.“.
Also, claim 1, limitations ( D ) and ( H ) above in Applicant’s specification para [0033], which discloses “In an embodiment where the seller does not directly receive the fiat currency associated with the sale into the seller's financial account, the seller may visit an SST 140 and provide the transaction identifier for the smart contract 133 through transaction interface 143. SST 140 retrieves and processes the blockchain-based workflow associated with blockchain-based media of value transactions and identifies a request made through the transaction interface 143 as a fiat currency withdrawal requested by the seller. The financial account is associated with the decentralized transaction service 113 based on the transaction identifier and the workflow utilizes service API 145 to verify that the withdrawal is permissible and an amount that is authorized for withdrawal by the seller. Decentralized transaction service 113 provides verification and amount using an API 114 and the workflow permits dispensing of the fiat currency in the amount through the media depository of the SST 140. In an embodiment, the seller may not be required to withdraw the full amount of the fiat currency associated with the trans-action, in such cases decentralized transaction service 113 maintains a ledger and debits the ledger associated with the seller when the withdrawn amount is less than the full amount associated with the fiat currency.“. Similar arguments apply to claims 13 and 20.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Therefore, Claims 1, 13 and 20 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application).
The claims 1 , 13 and 20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements (bolded elements above) amount to no more than mere instructions to apply the abstract idea using generic computer components. In conclusion, merely "applying" the exception using generic computer components cannot provide an inventive concept. Therefore, the claims 1, 13, and 20 are not patent eligible under 35 USC 101. (Step 2B: NO. The claims do not provide significantly more).
Dependent Claims
Dependent claims 2 – 12 and 14 - 19 are also rejected under 35 U.S.C. 101. Dependent claims 2 – 12 and 14 - 19 are further define the abstract idea or further define the extra-solution activities that are present in independent claim 1 thus abstract idea correspond to certain methods of organizing human activity as presented above. Claims 2 – 12 and 14 - 19 clearly further define the abstract idea as stated above and further define extra-solution activities such as presenting data and transmitting/receiving data.
Furthermore, dependent claims 2 – 12 and 14 - 19 do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Regarding claim 2, this claim merely recite, "crediting, by the workflow, an account identified in the conditions with the amount of the fiat currency, wherein the account is associated with a second user of the blockchain-based transaction.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 3, this claim merely recite additional steps that amount to no more than insignificant extra-solution activity. Specifically, claim 3 states “crediting, by the workflow, an account with the amount of the fiat currency, wherein the account is identified as being associated with an enterprise that generated and instantiated the smart contract on the blockchain on behalf of the user and a second user.”. These steps amount to no more than mere data gathering/analysis, which is a form of insignificant extra- solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly than the abstract idea, because the courts have found the concept of data gathering to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)).
Regarding claim 4, this claim merely recite, "verifying further includes activating, by the workflow, a media depository to receive the fiat currency as government-backed notes and verifying, by the workflow, the government-backed notes are non-counterfeit and, in the amount, wherein the media depository is a peripheral of the terminal.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 5, this claim merely provide further detail regarding, “verifying further includes activating, by the workflow, a card reader to identify an account associated with the user and processing, by the workflow, the amount through a financial network to transfer the amount from the account to a second account associated with a second user of the blockchain-based transaction or associated with an enterprise that generated and instantiated the smart contract on the blockchain on behalf of the user and a second user, wherein the card reader is a peripheral of the terminal.”. This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
Regarding claim 6, this claim merely recite, "verifying further includes notifying, by the workflow, one or more of: an enterprise that generated and instantiated the smart contract on the blockchain on behalf of the user and a second user that the amount was received and verified from the user for the blockchain-based transaction; and the second user that the amount was received and verified from the user for the blockchain-based transaction.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 7, this claim merely provide further detail regarding the media depository, recited in claim 1. Merely stating “the terminal includes a media depository that receives and verifies the fiat currency as government-backed notes are non-counterfeit before crediting an account with deposited funds." This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
Regarding claim 8, this claim merely add further description to the process of “identifying the blockchain-based transaction further includes matching a first user to a second user based on first terms posted by the first user and second terms posted by the second us.” This amount to no more than mere data gathering/outputting as described in reference to claims 1, 10 and 16 (see analysis above). Merely describing the comparing the new claim information does not integrate the abstract idea into a practical application, or amount to significantly more than the judicial exception, because it does not impose any meaningful limitations on practicing the abstract idea.
Regarding claim 9, this claim merely add further description to the process of “wherein the conditions for the blockchain-based transaction are defined based on the first terms and the second terms,”, which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 10, this claim merely recite, "wherein the smart contract includes source code generated for instructions that are processed on the blockchain.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 11, this claim merely provide further detail regarding, “the smart contract includes a wallet identifier that comprises blockchain-based media of value within the instructions that are processed on the blockchain.”. This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
Regarding claim 12, this claim merely recite, "maintaining a ledger for a first user, a second user, the blockchain-based transaction, and the smart contract.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 14, this claim merely recite, "receiving the fiat currency at the terminal, wherein the terminal identifies the transaction identifier as a transaction type associated with the blockchain.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 15, this claim merely provide further detail regarding the application programming interface (API, recited in claim 1. Merely stating “wherein the terminal uses an application programming interface (API) to interact with the smart contract over the blockchain by providing the transaction identifier." . This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
Regarding claim 16, this claim merely add further description to the process of “wherein the terminal confirms the amount matches the amount provided by the smart contract and credits an account with deposited funds.”. This amount to no more than mere data gathering/outputting as described in reference to claims 1, 10 and 16 (see analysis above). Merely describing the comparing the new claim information does not integrate the abstract idea into a practical application, or amount to significantly more than the judicial exception, because it does not impose any meaningful limitations on practicing the abstract idea.
Regarding claim 17, this claim merely add further description to the process of “wherein the terminal includes a media depository that receives and verifies the fiat currency as government-backed notes are non-counterfeit before crediting the account with the deposited funds,”, which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 18, this claim merely recite, "transferring the blockchain-based media of value to a user's wallet using a wallet identifier that was registered by the user.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 19, this claim merely provide further detail regarding the processing the transfer of fiat currency. Merely stating, “transferring the fiat currency to an account registered to a seller of the blockchain-based media of value.”. This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
As a result, such limitations do not overcome the requirements as described above. Therefore, claims 2 – 12 and 14 - 19 are directed to an abstract idea. Thus, claims 1 - 20 are not patent eligible.
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.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being obvious over Amitt Mahajan et al. (Pub. # US 2019/0354945 A1 – herein referred to as Mahajan) in view of Brian J. Mullins et al. (Pat. # US 11,423,398 B1 – herein referred to as Mullins).
Re: Claim 1, Mahajan discloses a method, comprising:
presenting an initial interface screen on a display of a terminal depicting a blockchain- based media of value transaction option and a non-blockchain-based transaction option (Mahajan, [0036] – FIG. 3B is a flow diagram showing a process 301 performed by the fiat to blockchain-based items system in some embodiments for purchasing blockchain-based goods using a credit card purchase transaction via strip integration (fiat currency settlement). One of ordinary skill in the art would understand that several of the actors and operations illustrated in FIG. 3B that are similar to those illustrated in FIG. 3A, perform functions similar to those described above in reference to FIG. 3A. Their description will not be repeated here. Process 301 begins at act 2 when the buyer initiates payment (for example, swipes a credit card at an end terminal, such as at a website that sells blockchain-based goods/assets). The purchase transaction (including details of the purchase record, such as buyer's name, identifier, credit card number, credit card company, expiration date, Credit card Validation Value (CVV), billing address, and so on) are forwarded to a payment processor 325. At act 2e, the payment processor 325 clears and settles payment in fiat currency with one or more fiat currency financial institutions 316 (such as banking institutions, credit card companies, and so on). The blockchain smart contract platform 310 can have an account with one of the fiat currency financial institutions 316 such that when the payment is cleared and settled, a commensurate payment amount (for example, commensurate to a royalty schedule) is transferred to the blockchain smart contract platform's bank account. Once the payment is cleared and settled, the payment processor 325, at act 2/, can transfer a portion (or all) of the purchase price to the seller 305 (for example, by crediting the seller's account with a fiat currency financial institution 316). According to terms of the listing, the purchase price can be equal to, greater than, or less than the listing price.);
obtaining a workflow and process the workflow based on a selection of the blockchain- based media of value transaction option selected by a user operating the terminal (Mahajan, [0029] – FIG. 3A is a flow diagram showing a process 300 performed by the fiat to blockchain-based items system in some embodiments for purchasing blockchain-based goods using traditional payment means. A seller 305 can list a good/asset (e.g., a blockchain-based good/asset) for sale with a blockchain smart contract platform 310 (e.g., the blockchain-based goods marketplace 250 in FIG. 2) by providing details about the good/asset (e.g., identifier, name, description, image, price, auction price, auction type, etc.) (act (1)). The price for the blockchain-based item can be provided in fiat currency (e.g., U.S. dollars, CAD dollars, etc.) or cryptocurrency (e.g., ETH, bitcoin, etc.), or both. FIG. SA is a display diagram illustrating an example user interface 500 for listing a blockchain-based item for sale in terms of cryptocurrency. When an item is listed for sale, the fiat to blockchain-based items system can display the following information: description (and/or image) 505, listing price in cryptocurrency 510, listing price in fiat currency 515, and so on. The user interface 500 provides an option to the seller to activate the listing by, for example, starting an auction for the item (using control 520). FIG. 5B is a display diagram illustrating an example user interface 550 for listing a blockchain-based item for sale in terms of fiat currency. When an item is listed for sale, the fiat to blockchain-based items system can display the following information: description (and/or image) 555, listing price in fiat currency 560, and so on. The user interface 550 provides an option to the seller to activate the listing by, for example, starting an auction for the item (using control 565).);
receiving, by the workflow, a transaction identifier for a blockchain-based transaction provided by the user through a second interface screen presented to the user based on the selection (Mahajan, [0042] – In several embodiments, instead of immediately transferring a purchased blockchain-based item to a buyer's electronic wallet, a system holds the item good in "custody" for the buyer until the buyer is ready to transfer it to his/her own account. The item can either be minted immediately or minted at the time the transfer is requested. One of the benefits of holding the item in custody is that the buyer does not need an electronic wallet at the time of purchase, only when he/she wants to claim the item. FIG. 6 is a display diagram illustrating an example user interface 600 for transferring a blockchain-based item to a buyer's electronic wallet according to various implementations. The buyer can select a blockchain-based item 605 for transfer to a selected electronic wallet identified by a unique address 610 via control 615. FIG. 7 is a display diagram illustrating an example user interface 700 displaying transaction history of a blockchain-based item according to various implementations. The system enables a buyer, seller, or any other authorized user to view one or more details of a blockchain-based item's transaction history. In several embodiments, the system imposes fees on either the buyer or seller or both for a variety of services (e.g., match making, currency conversion, etc.).).
However, Mahajan does not expressly disclose:
processing, by the workflow, a blockchain application programming interface (API) to request conditions for the blockchain-based transaction from a smart contract over a blockchain using the transaction identifier;
receiving, by the workflow, an amount of fiat currency from the smart contract;
presenting, by the workflow, a third interface screen to the user requesting that the user provide the amount of the fiat currency as a payment for the blockchain-based transaction;
verifying, by the workflow, the amount of the fiat currency was received from the user; and
notifying the smart contract using the API that the amount was verified and received at the terminal.
In a similar field of endeavor, Mullins discloses:
processing, by the workflow, a blockchain application programming interface (API) to request conditions for the blockchain-based transaction from a smart contract over a blockchain using the transaction identifier (Mullins, col. 22 - 23, lines 52 - 13 – In particular embodiments, the blockchain-enforced con-tract may be configured to directly receive an input from a customer client system, a merchant client system, or third-party system. As an example and not by way of limitation, the payment service system 108 may provide an application for installation on the customer client system, the merchant client system, or a third-party system. The application may receive an input from one or more of the parties (e.g., interaction with a button confirming product delivery, input in a field for filing a dispute). The application may formulate information associated with the input into a blockchain transaction associated with the blockchain-enforced contract and send the blockchain transaction to the blockchain network 145. As another example and not by way of limitation, the blockchain-enforced contract may be configured to receive an input by placing an application programming interface (API) call to a third-party service provider (e.g., a shipping agent). As yet another example and not by way of limitation, the blockchain-enforced contract may be configured to call an oracle service to obtain information regarding one or more contract conditions. The oracle may find and verify occurrence of events in the real world based on, for example, information available on the internet. It may interface with the blockchain network 145 and provided the information to the blockchain for use by smart contracts. In particular embodiments, the blockchain- 10 enforced contract may be executed based on the input it directly receives without the involvement of the payment service system 108.);
receiving, by the workflow, an amount of fiat currency from the smart contract (Mullins, col. 8, lines 12 - 39 – Each account ledger (204, 206) may reflect a pos1t1ve balance when customer 104 funds the accounts. An account may be funded by transferring currency in the form associated with the account from an external account (e.g., transferring a value of cryptocurrency to payment service and the value is credited as a balance in cryptocurrency ledger 204), or by purchasing currency in the form associated with the account from the payment service using currency in a different form (e.g., buying a value of cryptocurrency from payment service 108 using a value of fiat currency reflected in fiat currency ledger 206, and crediting the value of cryptocurrency in cryptocurrency ledger 204), or by conducting a transaction with another user (customer or merchant) of the payment service wherein the account receives incoming currency. In some embodiments customer profile 132 may include preferences for maintaining balances in cryptocurrency. In such embodiments, payment service 108 may automatically debit fiat currency ledger 206 to increase cryptocurrency ledger 204, or a payment card associated with customer profile whenever cryptocurrency balances fall below a stated level. Conversely, in some embodiments, payment service 108 may automatically credit fiat currency ledger 206 to decrease cryptocurrency ledger 204 whenever cryptocurrency balances rise above a stated level. In some embodiments, automatic transactions may be further defined by an exchange rate between the cryptocurrency and the fiat currency such that transactions to buy or sell cryptocurrency may occur when exchange rates are favorable.);
presenting, by the workflow, a third interface screen to the user requesting that the user provide the amount of the fiat currency as a payment for the blockchain-based transaction (Mullins, col. 30, lines 12 - 44 – In particular embodiments, communication interface 610 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 600 and one or more other computer systems 600 or one or more networks. As an example and not by way of limitation, communication interface 610 may include a network inter-face controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface 610 for it. As an example and not by way of limitation, computer system 600 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 600 may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or other suitable wireless network or a combination of two or more of these. Computer system 600 may include any suitable communication interface 610 for any of these networks, where appropriate. Communication interface 610 may include one or more communication interfaces 610, where appropriate. Although this disclosure describes and illustrates a particular communication inter-face, this disclosure contemplates any suitable communication interface.);
verifying, by the workflow, the amount of the fiat currency was received from the user (Mullins, col. 8, lines 12 - 39 – Each account ledger (204, 206) may reflect a pos1t1ve balance when customer 104 funds the accounts. An account may be funded by transferring currency in the form associated with the account from an external account (e.g., transferring a value of cryptocurrency to payment service and the value is credited as a balance in cryptocurrency ledger 204), or by purchasing currency in the form associated with the account from the payment service using currency in a different form (e.g., buying a value of cryptocurrency from payment service 108 using a value of fiat currency reflected in fiat currency ledger 206, and crediting the value of cryptocurrency in cryptocurrency ledger 204), or by conducting a transaction with another user (customer or merchant) of the payment service wherein the account receives incoming currency. In some embodiments customer profile 132 may include preferences for maintaining balances in cryptocurrency. In such embodiments, payment service 108 may automatically debit fiat currency ledger 206 to increase cryptocurrency ledger 204, or a payment card associated with customer profile whenever cryptocurrency balances fall below a stated level. Conversely, in some embodiments, payment service 108 may automatically credit fiat currency ledger 206 to decrease cryptocurrency ledger 204 whenever cryptocurrency balances rise above a stated level. In some embodiments, automatic transactions may be further defined by an exchange rate between the cryptocurrency and the fiat currency such that transactions to buy or sell cryptocurrency may occur when exchange rates are favorable.); and
notifying the smart contract using the API that the amount was verified and received at the terminal (Mullins, col. 15, lines 55 - 67 – The payment service system 108 may prompt for a message or script to be sent from a client or POS device associated with the merchant or customer containing a digital signature created based on a corresponding private key. The message or script may be sent to the payment service system 108 or directly to the blockchain-enforced contract stored on a 60 public blockchain. The payment service system 108 may confirm that such a message or script has been sent by one party of a transaction and notify the other party accordingly. As an example and not by way of limitation, the payment service system 108 may detect that a customer has send a script to sign a blockchain-enforced contract. It may then notify a merchant to ship a product purchased.).
Therefore, in light of the teachings of Mullins 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 method of Mahajan, motivation according to one KSR Exemplary Rationale where a known technique is used to improve similar methods and systems in the same way by providing a way to automatically analyze data associated with parties to an upcoming invoice and intelligently suggest terms of the invoice or a corresponding smart contract to the parties.
Re: Claim 2, Mahajan discloses the method of claim 1
further comprising crediting, by the workflow, an account identified in the conditions with the amount of the fiat currency, wherein the account is associated with a second user of the blockchain-based transaction (Mahajan, [0036] –FIG. 3B is a flow diagram showing a process 301 performed by the fiat to blockchain-based items system in some embodiments for purchasing blockchain-based goods using a credit card purchase transaction via strip integration (fiat currency settlement). One of ordinary skill in the art would understand that several of the actors and operations illustrated in FIG. 3B that are similar to those illustrated in FIG. 3A, perform functions similar to those described above in reference to FIG. 3A. Their description will not be repeated here. Process 301 begins at act 2 when the buyer initiates payment (for example, swipes a credit card at an end terminal, such as at a website that sells blockchain-based goods/assets). The purchase transaction (including details of the purchase record, such as buyer's name, identifier, credit card number, credit card company, expiration date, Credit card Validation Value (CVV), billing address, and so on) are forwarded to a payment processor 325. At act 2e, the payment processor 325 clears and settles payment in fiat currency with one or more fiat currency financial institutions 316 (such as banking institutions, credit card companies, and so on). The blockchain smart contract platform 310 can have an account with one of the fiat currency financial institutions 316 such that when the payment is cleared and settled, a commensurate payment amount (for example, commensurate to a royalty schedule) is transferred to the blockchain smart contract platform's bank account. Once the payment is cleared and settled, the payment processor 325, at act 2/, can transfer a portion (or all) of the purchase price to the seller 305 (for example, by crediting the seller's account with a fiat currency financial institution 316). According to terms of the listing, the purchase price can be equal to, greater than, or less than the listing price.).
Re: Claim 3, Mahajan discloses the method of claim 1
further comprising, crediting, by the workflow, an account with the amount of the fiat currency, wherein the account is identified as being associated with an enterprise that generated and instantiated the smart contract on the blockchain on behalf of the user and a second user (Mahajan, [0021] – In several embodiments, instead of using a cryptocurrency reserve system, the fiat to blockchain-based items system purchases cryptocurrency directly from a digital currency exchange using the traditional payment methods provided by the user. The fiat to blockchain-based items system can prepurchase blockchain-based goods and hold them directly in its own account/wallet instead of using a smart contract. The fiat to blockchain-based items system pays for the blockchain-based goods using its own crypto-currency wallet(s) and then re-sells the goods on its own marketplace platform where users can then purchase the blockchain-based goods using traditional payment methods. When a buyer purchases a pre-purchased blockchain-based good, the fiat to blockchain-based items system verifies the traditional payment (e.g., U.S. dollar payment using a credit card) and transfers the pre-purchased blockchain-based good from the system's own account/wallet to the buyer's wallet. This allows guaranteed delivery of goods.).
Re: Claim 4, Mahajan discloses the method of claim 1,
wherein verifying further includes activating, by the workflow, a media depository to receive the fiat currency as government-backed notes and verifying, by the workflow, the government-backed notes are non-counterfeit and, in the amount, wherein the media depository is a peripheral of the terminal (Mahajan, [0002] – The Bitcoin system was developed to allow electronic cash to be transferred directly from one party to another without going through a financial institution, as described in the white paper entitled "Bitcoin: A Peer-to-Peer Electronic Cash System" by Satoshi Nakamoto. A bitcoin (e.g., an electronic coin) is represented by a chain of transactions that transfers ownership from one party to another party. To transfer ownership of a bitcoin, a new transaction is generated and added to a stack of transactions in a block. The new transaction, which includes the public key of the new owner, is digitally signed by the owner with the owner's private key to transfer ownership to the new owner as represented by the new owner public key. Once the block is full, the block is "capped" with a block header that is a hash digest of all the transaction identifiers within the block. The block header is recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy called a "blockchain." To verify the current owner, the blockchain of transactions can be followed to verify each transaction from the first transaction to the last transaction. The new owner need only have the private key that matches the public key of the transaction that transferred the bitcoin. The blockchain creates a mathematical proof of ownership in an entity represented by a security identity (e.g., a public key), which in the case of the Bitcoin system is pseudo anonymous.).
Re: Claim 5, Mahajan discloses the method of claim 1,
wherein verifying further includes activating, by the workflow, a card reader to identify an account associated with the user and processing, by the workflow, the amount through a financial network to transfer the amount from the account to a second account associated with a second user of the blockchain-based transaction or associated with an enterprise that generated and instantiated the smart contract on the blockchain on behalf of the user and a second user, wherein the card reader is a peripheral of the terminal (Mahajan, [0003] – To ensure that a previous owner of a bitcoin did not double-spend the bitcoin (i.e., transfer ownership of the same bitcoin to two parties), the Bitcoin system maintains a distributed ledger of transactions. With the distributed led-ger, a ledger of all the transactions for a bitcoin is stored redundantly at multiple nodes (i.e., computers) of a block-chain network. The ledger at each node is stored as a blockchain. In a blockchain, the transactions are stored in the order that the transactions are received by the nodes. Each node in the blockchain network has a complete replica of the entire blockchain. The Bitcoin system also implements techniques to ensure that each node will store the identical blockchain, even though nodes may receive trans-actions in different orderings. To verify that the transactions in a ledger stored at a node are correct, the blocks in the blockchain can be accessed from oldest to newest, generating a new hash of the block and comparing the new hash to the hash generated when the block was created. If the hashes are the same, then the transactions in the block are verified.).
Re: Claim 6, Mahajan discloses the method of claim 1,
wherein verifying further includes notifying, by the workflow, one or more of:
an enterprise that generated and instantiated the smart contract on the blockchain on behalf of the user and a second user that the amount was received and verified from the user for the blockchain-based transaction (Mahajan, [0004] – Although the Bitcoin system has been very successful, it is limited to transactions in bitcoins or other cryptocurrencies. Efforts are currently underway to use blockchains to support transactions of any type, such as those relating to the sale of vehicles, sale of financial derivatives, sale of collectible goods, sale of stock, payments on contracts, and so on. Such transactions use identity tokens, which are also referred to as digital bearer bonds, to uniquely identify something that can be owned or can own other things. An identity token for a physical or digital asset is generated using a cryptographic one-way hash of information that uniquely identifies the asset. Tokens also have an owner that uses an additional public/private key pair. The owner public key is set as the token owner identity and when performing actions against tokens, ownership proof is established by providing a signature generated by the owner private key and validated against the public key listed as the owner of the token. A person can be uniquely identified, for example, using a combination of a user name, social security number, and biometric (e.g., fingerprint). A product (e.g., refrigerator) can be uniquely identified, for example, using the name of its manufacturer and its serial number. The identity tokens for each would be a cryptographic one-way hash of such combinations. The identity token for an entity (e.g., person or company) may be the public key of a public/private key pair, where the private key is held by the entity. Identity tokens can be used to identify people, institutions, commodities, contracts, computer code, equities, derivatives, bonds, insurance, loans, documents, and so on. Identity tokens can also be used to identify collections of assets.); and
the second user that the amount was received and verified from the user for the blockchain-based transaction (Mahajan, [0005] – To record a simple transaction in a blockchain, each party and asset involved with the transaction needs an account that is identified by a digital token. For example, when one person wants to transfer a car to another person, the current owner and next owner create accounts, and the current owner also creates an account that is uniquely identified by its vehicle identification number. The account for the car identifies the current owner. The current owner creates a transaction against the account for the car that indicates that the transaction is a transfer of ownership transfer, indicates the public keys (i.e., identity tokens) of the current owner and the next owner, and indicates the identity token of the car. The transaction is signed by the private key of the current owner and the transaction is evidence that the next owner is now the current owner.).
Re: Claim 7, Mahajan discloses the method of claim 1,
wherein the terminal includes a media depository that receives and verifies the fiat currency as government-backed notes are non-counterfeit before crediting an account with deposited funds (Mahajan, [0036] – FIG. 3B is a flow diagram showing a process 301 performed by the fiat to blockchain-based items system in some embodiments for purchasing blockchain-based goods using a credit card purchase transaction via strip integration (fiat currency settlement). One of ordinary skill in the art would understand that several of the actors and operations illustrated in FIG. 3B that are similar to those illustrated in FIG. 3A, perform functions similar to those described above in reference to FIG. 3A. Their description will not be repeated here. Process 301 begins at act 2 when the buyer initiates payment (for example, swipes a credit card at an end terminal, such as at a website that sells blockchain-based goods/assets). The purchase transaction (including details of the purchase record, such as buyer's name, identifier, credit card number, credit card company, expiration date, Credit card Validation Value (CVV), billing address, and so on) are forwarded to a payment processor 325. At act 2e, the payment processor 325 clears and settles payment in fiat currency with one or more fiat currency financial institutions 316 (such as banking institutions, credit card companies, and so on).).
Re: Claim 8, Mahajan discloses the method of claim 1,
wherein identifying the blockchain-based transaction further includes matching a first user to a second user based on first terms posted by the first user and second terms posted by the second user (Mahajan, [0002] – To transfer ownership of a bitcoin, a new transaction is generated and added to a stack of transactions in a block. The new transaction, which includes the public key of the new owner, is digitally signed by the owner with the owner's private key to transfer ownership to the new owner as represented by the new owner public key. Once the block is full, the block is "capped" with a block header that is a hash digest of all the transaction identifiers within the block. The block header is recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy called a "blockchain." To verify the current owner, the blockchain of transactions can be followed to verify each transaction from the first transaction to the last transaction. The new owner need only have the private key that matches the public key of the transaction that transferred the bitcoin. The blockchain creates a mathematical proof of ownership in an entity represented by a security identity (e.g., a public key), which in the case of the Bitcoin system is pseudo-anonymous.).
Re: Claim 9, Mahajan discloses the method of claim 8,
wherein the conditions for the blockchain-based transaction are defined based on the first terms and the second terms (Mahajan, [0038] – FIG. 3C is a flow diagram showing a process 303 performed by the fiat to blockchain-based items system in some embodiments for purchasing blockchain-based goods using a credit card purchase transaction via simplex integration (cryptocurrency settlement). One of ordinary skill in the art would understand that several of the actors and operations illustrated in FIG. 3C that are similar to those illustrated in FIG. 3A, perform functions similar to those described above in reference to FIG. 3A. Their description will not be repeated here. Process 303 begins at act 2 when the buyer initiates a purchase transaction (for example, swipes a credit card at an end terminal). The purchase transaction (including details of the purchase record, such as buyer's name, identifier, credit card number, credit card company, expiration date, CVV, billing address, and so on) are forwarded to a payment processor 325. At act 2i, the payment processor 325 determines a corresponding purchase price in cryptocurrency to emit for the purchase of the asset/good. For example, based on the current market rate, the payment processor 325 computes the purchase price in a selected cryptocurrency.).
Re: Claim 10, Mahajan discloses the method of claim 1,
wherein the smart contract includes source code generated for instructions that are processed on the blockchain (Mahajan, [0007] – When a message is sent to a smart contract to record a transaction, the message is sent to each node that maintains a replica of the blockchain. Each node executes the computer code of the smart contract to implement the transaction. For example, if 100 nodes each maintain a replica of a blockchain, then the computer code executes at each of the 100 nodes. When a node completes execution of the computer code, the result of the transaction is recorded in the blockchain. The nodes employ a consensus algorithm to decide on which transactions to keep and which transactions to discard. Although the execution of the computer code at each node helps ensure the authenticity of the blockchain, it requires large amounts of computer resources to support such redundant execution of the computer code.).
Re: Claim 11, Mahajan discloses the method of claim 10,
wherein the smart contract includes a wallet identifier that comprises blockchain-based media of value within the instructions that are processed on the blockchain (Mahajan, [0035] – The purchased good/asset is then transferred to the buyer (act 4). For example, by default, when the smart contract is executed, the blockchain smart contract platform 310 transfers the purchased good/asset to the buyer's block-chain wallet 340 (act 4b). In several embodiments, when the buyer does not provide a cryptocurrency address (e.g., an address associated with a digital currency exchange/block-chain wallet), the blockchain smart contract platform 310 can provision a wallet for the buyer 335 so that the purchased good/asset can be transferred to it (act 4a). For example, the blockchain smart contract platform 310 can set up a wallet for the buyer 335 directly with a digital currency exchange (e.g., Ethereum) and associate it with a user identifier (e.g., email address, telephone number, personally identifiable information (PII) number, etc.). As another example, the blockchain smart contract platform 310 can use a third-party service (e.g., BitGo) to set up a wallet (e.g., a "multiple-signature" account) for the buyer 335. In some embodiments, the system mints the blockchain-based item at the time of transfer to the buyer.).
Re: Claim 12, Mahajan discloses the method of claim 1,
further comprising maintaining a ledger for a first user, a second user, the blockchain-based transaction, and the smart contract (Mahajan, [0003] – To ensure that a previous owner of a bitcoin did not double-spend the bitcoin (i.e., transfer ownership of the same bitcoin to two parties), the Bitcoin system maintains a distributed ledger of transactions. With the distributed ledger, a ledger of all the transactions for a bitcoin is stored redundantly at multiple nodes (i.e., computers) of a blockchain network. The ledger at each node is stored as a blockchain. In a blockchain, the transactions are stored in the order that the transactions are received by the nodes. Each node in the blockchain network has a complete replica of the entire blockchain. The Bitcoin system also implements techniques to ensure that each node will store the identical blockchain, even though nodes may receive trans-actions in different orderings. To verify that the transactions in a ledger stored at a node are correct, the blocks in the blockchain can be accessed from oldest to newest, generating a new hash of the block and comparing the new hash to the hash generated when the block was created. If the hashes are the same, then the transactions in the block are verified.).
Re: Claim 13, Claim 13 is a method claim corresponding to method claim 1. Therefore, claim 13 is analyzed and rejected as previously discussed with respect to claim 1.
Re: Claim 14, Mahajan discloses the method of claim 13,
further comprising receiving the fiat currency at the terminal, wherein the terminal identifies the transaction identifier as a transaction type associated with the blockchain (Mahajan, [0040] – In several embodiments, the fiat to blockchain-based items system 315 pre-purchases goods/assets from sellers and holds them directly in its own wallet(s) instead of using a smart contract. The fiat to blockchain-based items system can also create/generate/mint its own goods/assets and list them for sale. When a buyer 320 purchases a good/asset owned by the blockchain smart contract platform 310, the blockchain smart contract platform 310 verifies the payment (using traditional payment means) and transfers the purchased good/asset from the wallet of the blockchain smart contract platform 310 to a wallet of the buyer (or a provisional wallet of the buyer when the buyer has not provided a cryptocurrency address). For auction-type trans-actions, the fiat to blockchain-based items system 315 can determine and/or maintain a "limit-order" where users can place their orders before the price reaches a certain point (for descending price auctions), after which the fiat to block-chain-based items system 315 automatically executes the transaction on behalf of the winning user via the previously set smart contract. Alternatively, or additionally, the fiat to blockchain-based items system 315 can perform an auction bidding process for the blockchain-based good/asset off-chain and then execute the actual swap between the buyer and seller on-chain.).
Re: Claim 15, Mahajan in view of Mullins discloses the method of claim 14,
wherein the terminal uses an application programming interface (API) to interact with the smart contract over the blockchain by providing the transaction identifier (Mullins, col. 22 - 23, lines 52 - 13 – In particular embodiments, the blockchain-enforced con-tract may be configured to directly receive an input from a customer client system, a merchant client system, or third-party system. As an example and not by way of limitation, the payment service system 108 may provide an application for installation on the customer client system, the merchant client system, or a third-party system. The application may receive an input from one or more of the parties (e.g., interaction with a button confirming product delivery, input in a field for filing a dispute). The application may formulate information associated with the input into a blockchain transaction associated with the blockchain-enforced contract and send the blockchain transaction to the blockchain network 145. As another example and not by way of limitation, the blockchain-enforced contract may be configured to receive an input by placing an application programming interface (API) call to a third-party service provider (e.g., a shipping agent). As yet another example and not by way of limitation, the blockchain-enforced contract may be configured to call an oracle service to obtain information regarding one or more contract conditions. The oracle may find and verify occurrence of events in the real world based on, for example, information available on the internet. It may interface with the blockchain network 145 and provided the information to the blockchain for use by smart contracts. In particular embodiments, the blockchain- 10 enforced contract may be executed based on the input it directly receives without the involvement of the payment service system 108.). The rationale for support of motivation, obviousness and reason to combine see claim 13 above.
Re: Claim 16, Mahajan discloses the method of claim 15,
wherein the terminal confirms the amount matches the amount provided by the smart contract and credits an account with deposited funds (Mahajan, [0017] – Traditional processes for purchasing blockchain-based items (also called crypto-goods) (e.g., digital items, tickets, deeds, etc.) using cryptocurrency are convoluted and complicated for a typical end-user. These blockchain-based items, their owners, and their pricing data are stored on a blockchain and can be interacted with using, for example, a smart contract. The smart contract allows listing of goods, purchasing of listed goods, and the transfer of goods. All of these transactions occur "on-chain" and are denominated in a cryptocurrency. Currently, a user who wishes to purchase physical or digital items using blockchain is first required to obtain an account with a digital currency exchange (e.g., Gemini, Coinbase, Kraken, etc.). The user then verifies the account by uploading a wide variety of documents providing the identity of the user. Verification of the uploaded information takes a few days. Once the account is verified, the user deposits regular (or fiat) currency (e.g., U.S. dollars) into the exchange. Depending on the source banking institution and the wire transfer, this step typically takes 3-5 business days. Once the user receives the USD in his/her exchange account, the user can use it to purchase cryptocurrency (e.g., bitcoin, ether ("ETH"), etc.). After purchasing the cryptocurrency, the user obtains a blockchain wallet (e.g., an Ethereum wallet). After acquiring the blockchain wallet, the user funds the blockchain wallet with the purchased cryptocurrency. The user is then able to execute a purchase transaction (purchase blockchain-based items) using the cryptocurrency in the blockchain wallet. As a result, traditional processes tend to take a long period of time to complete and introduce a lot of latency in the process for a user to acquire blockchain-based items.).
Re: Claim 17, Mahajan discloses the method of claim 16,
wherein the terminal includes a media depository that receives and verifies the fiat currency as government-backed notes are non-counterfeit before crediting the account with the deposited funds (Mahajan, [0002] – The Bitcoin system was developed to allow electronic cash to be transferred directly from one party to another without going through a financial institution, as described in the white paper entitled "Bitcoin: A Peer-to-Peer Electronic Cash System" by Satoshi Nakamoto. A bitcoin (e.g., an electronic coin) is represented by a chain of transactions that transfers ownership from one party to another party. To transfer ownership of a bitcoin, a new transaction is generated and added to a stack of transactions in a block. The new transaction, which includes the public key of the new owner, is digitally signed by the owner with the owner's private key to transfer ownership to the new owner as represented by the new owner public key. Once the block is full, the block is "capped" with a block header that is a hash digest of all the transaction identifiers within the block. The block header is recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy called a "blockchain." To verify the current owner, the blockchain of transactions can be followed to verify each transaction from the first transaction to the last transaction. The new owner need only have the private key that matches the public key of the transaction that transferred the bitcoin. The blockchain creates a mathematical proof of ownership in an entity represented by a security identity (e.g., a public key), which in the case of the Bitcoin system is pseudo anonymous.).
Re: Claim 18, Mahajan discloses the method of claim 13,
further comprising transferring the blockchain-based media of value to a user's wallet using a wallet identifier that was registered by the user (Mahajan, [0040] – In several embodiments, the fiat to blockchain-based items system 315 pre-purchases goods/assets from sellers and holds them directly in its own wallet(s) instead of using a smart contract. The fiat to blockchain-based items system can also create/generate/mint its own goods/assets and list them for sale. When a buyer 320 purchases a good/asset owned by the blockchain smart contract platform 310, the blockchain smart contract platform 310 verifies the payment (using traditional payment means) and transfers the purchased good/asset from the wallet of the blockchain smart contract platform 310 to a wallet of the buyer (or a provisional wallet of the buyer when the buyer has not provided a cryptocurrency address). For auction-type trans-actions, the fiat to blockchain-based items system 315 can determine and/or maintain a "limit-order" where users can place their orders before the price reaches a certain point (for descending price auctions), after which the fiat to block-chain-based items system 315 automatically executes the transaction on behalf of the winning user via the previously set smart contract. Alternatively, or additionally, the fiat to blockchain-based items system 315 can perform an auction bidding process for the blockchain-based good/asset off-chain and then execute the actual swap between the buyer and seller on-chain.).
Re: Claim 19, Mahajan discloses the method of claim 13,
further comprising transferring the fiat currency to an account registered to a seller of the blockchain-based media of value (Mahajan, [0027] – FIG. 2 illustrates an example of a communications environment 200 in which some embodiments of the fiat to blockchain-based items system can be utilized. In various embodiments, environment 200 comprises a fiat to block-chain-based items system 220. Seller(s) 205 can use various electronic devices (e.g., mobile device 210a, laptop/PC 210b, tablet 210c, etc.) to list one or more goods/assets for sale on the blockchain. In several embodiments, seller(s) 205 can list the blockchain goods/assets for sale directly at a blockchain-based goods marketplace 250, a blockchain smart contract platform based on, for example, Ethereum, and so on via a communications network 215a, such as a Local Area Network (LAN), Wide Area Network (WAN), the Internet, and the like. Seller(s) 205 can also communicate with a fiat to blockchain-based items system 220 via communications network 215a (e.g., using web services) regarding goods/assets listed for sale. In several embodiments, the blockchain-based goods marketplace 250 is integrated with the fiat to blockchain-based items system 220 (e.g., as an integrated e-commerce platform for blockchain-based goods/assets).).
Re: Claim 20, Claim 20 is a system claim corresponding to method claim 1. Therefore, claim 20 is analyzed and rejected as previously discussed with respect to claim 1.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN H. HOLLY whose telephone number is (571)270-3461. The examiner can normally be reached on MON. - FRI 10 AM - 8 PM.
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, MATTHEW S. GART can be reached on 571-272-3955. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/John H. Holly/Primary Examiner, Art Unit 3696
Prosecution Insights