DETAILED ACTION
This Non-Final Office action is in response to Applicant’s Amendment on 12/11/2024. Claims 2-21 are pending. The effective filing date of the claimed invention is 09/30/2021.
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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 2-21 are rejected under 35 U.S.C. 101 because the claims are found to be directed to abstract idea.
Step 1 – Claims 2-12 are process claims; claims 13-18 are manufacture claims; and, claims 19-21 are machine claims. Step 1 is satisfied.
Step 2A, Prong 1 – Exemplary claim 2 recites the following abstract idea: A method, comprising:
receiving, at a first application platform, a request to transfer a specified amount of a first digital currency from a first account for a first user on the first application platform to a second account for a second user on a second application platform implementing a second digital currency, wherein the first digital currency is implemented specifically by the first application platform (e.g. MPEP 2106.04(a)(2)(III)(A) citing Electric Power Grp.);
identifying, at the first application platform, the second account for the second user on the second application platform based on at least one user account lookup endpoint associated with the second application platform accessed by the first application platform (e.g. MPEP 2106.04(a)(2)(III)(A) citing Electric Power Grp.);
determining, at the first application platform, a specified amount of the second digital currency corresponding to the specified amount of the first digital currency based on at least one currency conversion endpoint associated with the second application platform accessed by the first application platform (e.g. MPEP 2106.04(a)(2)(III)(A) citing Electric Power Grp.);
withdrawing the specified amount of the first digital currency from the first account (see MPEP 2106.04(a)(2)(II)(A-B)); and
transferring the specified amount of the second digital currency into the second account (see MPEP 2106.04(a)(2)(II)(A-B)).
Accordingly, when viewed alone and in ordered combination, the examiner finds that exemplary claim 2 (and similarly 13 and 19) recites abstract idea.
Step 2A, Prong 2 – Claim 2 is not found to integrate the abstract idea into practical application. Claim 2 recites the following additional elements: a first application platform and a second application platform. The examiner refers to MPEP 2106.05(f) mere instruction to apply an exception, or the ”apply it” rationale for why this is not practical application. When viewed alone and in ordered combination, exemplary claim 2 (and 13, 19) is found to be directed to abstract idea.
Step 2B – Claim 2 is not found to include significantly more than then underlying abstract idea. The additional element analysis is equally applied at Step 2B. Another consideration when determining whether a claim recites significantly more than a judicial exception is whether the additional element(s) are well-understood, routine, conventional (WURC) activities previously known to the industry. This consideration is only evaluated in Step 2B of the eligibility analysis. See MPEP 2106.05(d)(II). The courts have recognized the following computer functions as WURC functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity.
The limitations relating to receiving/transmitting data, found to be WURC. MPEP 2106.05(d)(II) i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) (“Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink.” (emphasis added));
The limitations of claim 2 relating to electronic recordkeeping, storing and retrieving data have been found by the courts to be WURC. See MPEP 2106.05(d)(II)(iii-iv).
Accordingly, when viewed alone and in ordered combination, exemplary claim 2 is found to be directed to abstract idea.
Dependent claims – Claim 3 recites abstract idea (MPEP 2106.04(a)(2)(II)) performed in “apply it” manner. Claim 4 is more abstract idea. MPEP 2106.04(a)(2)(II). Claim 5-6 recites more abstract idea. MPEP 2106.04(a)(2)(II)(A-B). Claim 7 recites abstract idea. MPEP 2106.04(II)(A)(2) citing RecogniCorp, LLC v. Nintendo Co., 855 F.3d 1322, 1327, 122 USPQ2d 1377 (Fed. Cir. 2017) (“Adding one abstract idea (math) to another abstract idea (encoding and decoding) does not render the claim non-abstract”). Claims 8 and 14 recite more abstract idea. MPEP 2106.04(a)(2)(III). Claim 9 recites more abstract idea. MPEP 2106.04(a)(2)(III). Claim 10 recites more abstract idea. MPEP 2106.04(a)(2)(III). Claims 11-12 recite abstract idea. MPEP 2106.04(a)(2)(II). Claim 15 recites abstract idea. MPEP 2106.04(a)(2)(II)(A-B). Claims 16-18 20-21 recite more abstract idea. MPEP 2106.04(a)(2)(II).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pat. Pub. No. 2019/0180558 to Merati (“Merati”) in view of U.S. Pat. Pub. No. 2019/0311357 to Madisetti (“Madisetti”).
With regard to claims 2, 13, 19, Merati discloses the claimed method:
receiving, at a first application platform, a request to transfer a specified amount of a first digital currency from a first account for a first user on the first application platform to a second account for a second user on a second application platform implementing a second digital currency, wherein the first digital currency is implemented specifically by the first application platform (Merati e.g. abstract, The IGO server receives gaming and non-gaming transactions from gaming operator systems, comprising gaming platforms and merchants associated with each gaming operator system. Each gaming operator system issues its own casino crypto currency (C3) for use in gaming and non-gaming transactions. For each transaction that is processed by the IGO, the IGO debits and credits user accounts in accordance with the particular C3 involved in each transaction. [0123] FIG. 5 is an overall block diagram of a system 500 that uses C3 to allow gaming and non-gaming transactions. The system 500 comprises gaming operator systems 502 and 526, for example, casinos, that offers various gaming platforms to its patrons, such as table games via a table game interface 504/528, electronic gaming via gaming machines 506/530 and sports betting via a sports betting server 508/532. Each of the platforms may communicate with a respective casino gaming server 510/534 that manages some or all of the functionality of the various gaming platforms. Merati focuses on transfer between first account and second account of the same user, not clearly from a first user’s account to a second user’s account. Madisetti cures this deficiency by expressly teaching a user-to-user transfer at abstract, [0066-67], Figs. 6-7, Fig. 7 user A initiates a cross-chain value transfer request to user B, where user B receives the value in an equivalent number of a different token on a different blockchain network.);
identifying, at the first application platform, the second account for the second user on the second application platform based on at least one user account lookup endpoint associated with the second application platform accessed by the first application platform (Merati discloses account identification logic, at [0150-151], including identification of an account and identification of a platform/operator-associated sub-account; Merati does not disclose that identification using a user account lookup endpoint associated with the second application platform and accessed by the first application platform; Madisetti teaches the endpoint/API architecture, such as at [0098] FIG. 15, an exemplary VTTP reference architecture, is described in more detail. Users 800 may use VTTP clients 802, 806 to communicate with VTTP servers 810, 812, 814 through an API gateway 804. The VTTP servers 810, 812, 814 sit under a load balancer 808 and expose a number API endpoints. The API gateway 804 makes these APIs available to the VTTP clients. Each API has an endpoint (for example, vttp://example.com/ethereum) and a set of VTTP methods or commands which are supported for the endpoint (such as GET, SEND, REQUEST, etc.). The API gateway 804 may use an API key to enable authentication for APIs.; Madisetti at [0068] Referring now to FIG. 8, VTTP commands are described in more detail.
PNG
media_image1.png
412
611
media_image1.png
Greyscale
Madisetti [0097] Fig. 14 smart contracts may verify sender and receiver addresses, Madisetti teaches using an endpoint-accessed API call to retrieve account information and validate the destination user/address, which cures Merati’s lack of explicit “user account lookup endpoint”);
determining, at the first application platform, a specified amount of the second digital currency corresponding to the specified amount of the first digital currency based on at least one currency conversion endpoint associated with the second application platform accessed by the first application platform (Merati expressly discloses currency conversion between the first and second digital currencies, see published claim 8; Merati abstract, the IGO debits and credits user accounts in accordance with the particular C3 involved in each transaction; Merati [0144] describes sub accounts each associated with a respective C3);
withdrawing the specified amount of the first digital currency from the first account (Merati, published claim 8, abstract, [0145-149]; Madisetti e.g. [0067] (not needed)); and
transferring the specified amount of the second digital currency into the second account (Merati, published claim 8 “crediting the second account by the second amount.”; as found above, and not claimed in this limitation, Merati does not disclose where the second account is a second user’s account; See Madisetti curing this deficiency, above.).
Therefore, it would have been obvious to one of ordinary skill in the transaction art before the effective filing date of the claimed invention to modify Merati’s crypto currency systems and method transfer from account-to-account, to include Madisetti’s transfer from first user account to second user account, and the user account lookup endpoint, as shown in Madisetti above, where the advantage is that this allows different users to particupate in the transaction system of Merati, and further brings in the different platforms of Madisetti so that now money can be transfer not only from account-to-account, but from user to user, and from one platform to another platform, where this adds convenience, efficiency, and added ability for the user to transfer money the way it is needed for that particular user. See Madisetti, throughout.
With regard to claim 3, 21, Merati further discloses the first digital currency is implemented by the first application platform specifically for use in transactions conducted on the first application platform (e.g. Merati abstract, Figs. 5, 13A-13C).
With regard to claim 4, Merati further discloses a value of the first digital currency is based on its use in the transactions conducted on the first application platform (e.g. Merati [0096] In addition, C3 may be used to conduct non-wagering transactions, such as the purchase of food and beverages, clothing, jewelry, or other goods or services, associated with a particular gaming establishment, in one embodiment.).
With regard to claims 5, 6, 20, Merati further discloses the first application platform is integrated with the second application platform through a mapping tool that links the second digital currency to the second application platform and registers the second digital currency with the first application platform (Merati discloses integration between different operator systems through the IGO server, and it discloses that different operator systems issue different digital currencies. Merati Fig. 5 for architecture. Merati Fig. 13C shows operator-to-operator transfer processing through the IGO). Merati does not disclose a mapping tool that links the second digital currency to the second application platform and registers that second digital currency with the first application platform. Madisetti teaches these limitations. Madisetti e.g. [0098] Fig. 15 describes an API gateway exposing endpoints for different systems, with each API having an endpoint and supported methods, and the linking of them via e.g. separate relational or non-relational databases. While not word for word with “mapping tool” and the like, Madisetti is a strong teaching for mapping/integration layer linking a resource/token/network to a corresponding target platform.). For claim 6, see Madisetti [0068] FIG. 8, VTTP commands are described in more detail. The VTTP GET command 452 is used to retrieve information about an account, contract, transaction, and an exchange rate for a token. For example, the VTTP GET command 452 to retrieve balance of an account may look as follows, and [0098].
Therefore, it would have been obvious to one of ordinary skill in the transaction art before the effective filing date of the claimed invention to modify Merati’s crypto currency systems and method transfer from account-to-account, to include Madisetti’s transfer from first user account to second user account, and the user account lookup endpoint, as shown in Madisetti above, where the advantage is that this allows different users to participate in the transaction system of Merati, and further brings in the different platforms of Madisetti so that now money can be transfer not only from account-to-account, but from user to user, and from one platform to another platform, where this adds convenience, efficiency, and added ability for the user to transfer money the way it is needed for that particular user. See Madisetti, throughout.
With regard to claim 7, Merati further discloses the first application platform is integrated with the second application platform through registration of an application key at the first application platform, wherein the application key is located on the second application platform, and wherein the registration of the application key provides the first application platform access to resources on the second application platform (Merati discloses general system-to-system communication and account creation, but not application-key registration as claimed. Madisetti teaches this at [0098] Fig. 15, VTTP clients 802, 806 to communicate with VTTP servers 810, 812, 814 through an API gateway 804. The VTTP servers 810, 812, 814 sit under a load balancer 808 and expose a number API endpoints. The API gateway 804 makes these APIs available to the VTTP clients. Each API has an endpoint (for example, vttp://example.com/ethereum) and a set of VTTP methods or commands which are supported for the endpoint (such as GET, SEND, REQUEST, etc.). The API gateway 804 may use an API key to enable authentication for APIs.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Merati to include such API key, as shown in Madisetti, where this provides the advantage of “enable[s] authentication for APIs.” Madisetti, [0098].
With regard to claim 8, 14, Merati does not disclose claim 8. Madisetti teaches [0098]/Fig 15 expressly teaches API endpoints, [0068]/Fig. 8 teach GET requests to receive information about accounts, contracts, transaction, and exchange rates of other platforms, which teaches the claimed limitations. See motivation to combine from claim 2.
With regard to claim 9, Merati further discloses where the first application platform being integrated with the second application platform includes linking the one or more endpoints to the second application platform in a registration at the first application platform to provide access on the first application platform to the lookup locations for the resources on the second application platform associated with the endpoints (Merati discloses multi-platform communication through IGO, but not this endpoint-registration structure. Madisetti cures these deficiencies at [0098]/Fig. 15 that the API gateway makes the APIs available to the clients, that the servers expose multiple endpoints, and that those endpoints correspond to specific resources and commands). See motivation to combine from claim 2.
With regard to claim 10, Merati further discloses providing a first notification to the first user and a second notification to the second user indicating the transferring of the specified amount of the first digital currency from the first account to the specified amount of the second digital currency into the second account (Merati claim 9, Fig. 13C, teaches notifications, but primarily notifications to operating/gaming servers. Merati does not disclose the claimed notifications to first and second user. Madisetti Fig. 21, element 6 and 7, teaches this). See motivation to combine from claim 2.
With regard to claim 11, Merati further discloses where the specified amount of the first digital currency is withdrawn from the first account when the second account receives the specified amount of the second digital currency (Merati e.g. claim 8, Fig. 13C).
With regard to claim 12, Merati does not disclose limitations of claim 12. Madisetti teaches e.g. Fig. 7, disclosure is not limited to a platform-specific application currency, it is directed to blockchain/token value transfer across networks, including cross-chain exchange and transaction of equivalent value. See motivation to combine from claim 2.
With regard to claim 15, Merati further discloses where the currency conversion endpoint identifies a resource to find a conversion rate between the first digital currency and the second digital currency in the second application platform (Merati abstract, claim 8 discloses conversion between a first digital currency and a second digital currency in the multi-operator gaming environment. Merati does not disclose a conversion endpoint that identifies a source of the exchange rate. Madisetti teaches that a VTTP GET command can retrieve information about . . . an exchange rate for a token, also teaches endpoint based API framework in which each API has an endpoint and supported methods such as GET, SEND, and REQUEST.). See combination of references from claim 2.
With regard to claim 16, Merati further discloses the first application platform is a first gaming platform, and wherein the second application platform is a second gaming platform (see Merati Fig. 5, and throughout).
With regard to claim 17, Merati further discloses the first digital currency is currency that is distinctly managed, stored, or exchanged by designated software specific to the first application platform (Merati e.g. [0145-147]).
With regard to claim 18, Merati further discloses identifying a resource to a wallet for depositing the second digital currency in the second application platform based on a wallet deposit endpoint for the second account for the second user on the second application platform (e.g. [0147], [0151]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Peter Ludwig whose telephone number is (571)270-5599. The examiner can normally be reached Mon-Fri 9-5.
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, Fahd Obeid can be reached at 571-270-3324. 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.
/PETER LUDWIG/Primary Examiner, Art Unit 3627
Prosecution Insights