DETAILED ACTION
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 .
Status of Claims
Claims 1-20 are pending. Claims 1-12 have been examined.
Information Disclosure
The information disclosure statement(s) (IDS) submitted 03/12/2026, 06/10/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) has/have been considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-16 of U.S. Patent No. 12,499,426 (“ ‘426 patent”).
Claims 1-10 of the present application
Although the conflicting claims are not identical, they are not patentably distinct from each other. Claim 1 of the ‘426 patent recites a method, comprising:
receiving, by at least one computing system, an exchange request from a merchant point-of-sale (POS) system, the exchange request for an amount, the exchange request corresponding with a math based currency (MBC) credit card account of a customer and a fiat currency credit card account of the customer, wherein the exchange request is initiated upon triggering an exchange using a physical credit card via a card reading mechanism of the merchant POS system;
determining, by the at least one computing system, the merchant POS system accepts MBC payments;
identifying, by the at least one computing system, a first MBC entry in an overlay ledger that reflects an MBC balance of the MBC credit card account of the customer and a second MBC entry in the overlay ledger that reflects an MBC balance for an MBC account of the merchant POS system;
generating or identifying, by the at least one computing system, a first public and private key pair of the MBC account of the merchant POS system;
exchanging, by the at least one computing system on a published blockchain, an amount of MBC equal to the amount using the first public and private key pair of the MBC account of the merchant POS system;
storing, by the at least one computing system, the first public and private key pair of the MBC account of the merchant POS system in a pooled account database, wherein the pooled account database stores a total amount of MBC deposits and MBC credits of an institution;
updating, by the at least one computing system, the first MBC entry of the overlay ledger to modify the MBC balance of the MBC credit card account held by the customer by the amount of MBC and the second MBC entry of the overlay ledger to increase the MBC balance of the MBC account of the merchant POS system by a corresponding amount;
broadcasting, by the at least one computing system, the exchange to a plurality of MBC verification nodes for verification;
responsive at least in part to the verification, identifying, by the computing system using the overlay ledger, updated MBC balances for the customer and the merchant POS system decoupled from the total amount of MBC deposits and MBC credits of the institution and the first public and private key pair stored in the pooled account database; and
executing, by the at least one computing system, one or more MBC operations based on the updated MBC balances reflected in the overlay ledger;
wherein the overlay ledger comprises a plurality of MBC entries corresponding with amounts of MBC stored separately from a plurality of private and public key pairs of the pooled account database, and wherein the MBC account of the merchant POS system is an MBC entry of the plurality of MBC entries in the overlay ledger.
Claim 1 of the ‘426 patent differs since it further recites additional claim limitations, “point-of-sale (POS) system,” “the exchange request corresponding with a math based currency (MBC) credit card account of a customer and a fiat currency credit card account of the customer,” “a physical credit card via a card reading mechanism of the merchant POS system,” “determining, by the at least one computing system, the merchant POS system accepts MBC payments,” “identifying, by the at least one computing system, a first MBC entry in an overlay ledger that reflects an MBC balance of the MBC credit card account of the customer and a second MBC entry in the overlay ledger that reflects an MBC balance for an MBC account of the merchant POS system;” “responsive at least in part to the verification, identifying, by the computing system using the overlay ledger, updated MBC balances for the customer and the merchant POS system decoupled from the total amount of MBC deposits and MBC credits of the institution,” “executing, by the at least one computing system, one or more MBC operations based on the updated MBC balances reflected in the overlay ledger;” “wherein the overlay ledger comprises a plurality of MBC entries corresponding with amounts of MBC stored separately from a plurality of private and public key pairs of the pooled account database, and wherein the MBC account of the merchant POS system is an MBC entry of the plurality of MBC entries in the overlay ledger.” However, it would have been obvious to a person of ordinary skill in the art to modify claim 1 of the ‘426 patent by removing the limitations directed to determining the merchant POS system accepting MBC payment, looking up MBC balances and updated balances of the MBC accounts of the customer and the merchant in the overlay ledger, executing MBC operations in the overlay ledger in claim 1 of the present application since the claim of the present application and the claim recited in the ‘426 patent actually perform a similar function. It is well settled that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson, 136 USPQ 184 (CCPA 1963). Also note Ex parte Rainu, 168 USPQ 375 (Bd. App. 1969). Omission of a reference element whose function is not needed would be obvious to one of ordinary skill in the art.
Claims 11-20 of the present application
Although the conflicting claims are not identical, they are not patentably distinct from each other. Claim 9 of the ‘426 patent recites a system, comprising:
at least one processing circuit configured to:
receive an exchange request from a merchant point-of-sale (POS) system, the exchange request for an amount, the exchange request corresponding with a math based currency (MBC) credit card account of a customer and a fiat currency credit card account of the customer, wherein the exchange request is initiated upon triggering an exchange using a physical credit card via a card reading mechanism of the merchant POS system;
determine the merchant POS system accepts MBC payments;
identify a first MBC entry in an overlay ledger that reflects an MBC balance of the MBC credit card account of the customer and a second MBC entry in the overlay ledger that reflects an MBC balance for an MBC account of the merchant POS system;
generate or identify a first public and private key pair of the MBC account of the merchant POS system;
exchange, on a published blockchain, an amount of MBC equal to the amount using the first public and private key pair of the MBC account of the merchant POS system;
store the first public and private key pair of the MBC account of the merchant POS system in a pooled account database, wherein the pooled account database stores a total amount of MBC deposits and MBC credits of an institution;
update the first MBC entry of the overlay ledger to modify the MBC balance of the MBC credit card account held by the customer by the amount of MBC and the second MBC entry of the overlay ledger to increase the MBC balance of the MBC account of the merchant POS system by a corresponding amount;
broadcast the exchange to a plurality of MBC verification nodes for verification;
responsive at least in part to the verification, identify, using the overlay ledger, updated MBC balances for the customer and the merchant POS system decoupled from the total amount of MBC deposits and MBC credits of the institution and the first public and private key pair stored in the pooled account database; and
execute one or more MBC operations based on the updated MBC balances reflected in the overlay ledger; wherein the overlay ledger comprises a plurality of MBC entries corresponding with amounts of MBC stored separately from a plurality of private and public key pairs of the pooled account database, and
wherein the MBC account of the merchant POS system is an MBC entry of the plurality of MBC entries in the overlay ledger.
Claim 9 of the ‘426 patent differs since it further recites additional claim limitations, “point-of-sale (POS) system,” “the exchange request corresponding with a math based currency (MBC) credit card account of a customer and a fiat currency credit card account of the customer,” “a physical credit card via a card reading mechanism of the merchant POS system,” “determine the merchant POS system accepts MBC payments,” “identify a first MBC entry in an overlay ledger that reflects an MBC balance of the MBC credit card account of the customer and a second MBC entry in the overlay ledger that reflects an MBC balance for an MBC account of the merchant POS system;” “responsive at least in part to the verification, identify, using the overlay ledger, updated MBC balances for the customer and the merchant POS system decoupled from the total amount of MBC deposits and MBC credits of the institution,” “execute one or more MBC operations based on the updated MBC balances reflected in the overlay ledger;” “wherein the overlay ledger comprises a plurality of MBC entries corresponding with amounts of MBC stored separately from a plurality of private and public key pairs of the pooled account database, and wherein the MBC account of the merchant POS system is an MBC entry of the plurality of MBC entries in the overlay ledger.” However, it would have been obvious to a person of ordinary skill in the art to modify claim 9 of the ‘426 patent by removing the limitations directed to one processing circuit configured to determine the merchant POS system accepting MBC payment, look up MBC balances and updated balances of the MBC accounts of the customer and the merchant in the overlay ledger, executing MBC operations in the overlay ledger in claim 11 of the present application since the claim of the present application and the claim recited in the ‘429 patent actually perform a similar function. It is well settled that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson, 136 USPQ 184 (CCPA 1963). Also note Ex parte Rainu, 168 USPQ 375 (Bd. App. 1969). Omission of a reference element whose function is not needed would be obvious to one of ordinary skill in the art.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,511,626 (“ ‘626 patent”).
Claims 1-10 of the present application
Although the conflicting claims are not identical, they are not patentably distinct from each other. Claim 1 of the ‘626 patent recites a method comprising:
receiving, by at least one computing system and from a customer computer system, a remote exchange request for an amount, the remote exchange request corresponding with a math based currency (MBC) account of a customer and a fiat currency account of the customer, wherein the remote exchange request is initiated upon triggering a remote exchange for a remote, card-based exchange with an online merchant;
identifying, by the at least one computing system, a first MBC entry in an overlay ledger that reflects an MBC balance of the MBC account of the customer and a second MBC entry in the overlay ledger that reflects an MBC balance for an MBC account of the online merchant;
generating or identifying, by the at least one computing system, a first public and private key pair of the MBC account of the online merchant;
exchanging, by the at least one computing system on a published blockchain, an amount of MBC equal to the amount using the first public and private key pair of the MBC account of the online merchant;
storing, by the at least one computing system, the first public and private key pair of the MBC account of the online merchant in a pooled account database, wherein the pooled account database stores a total amount of MBC deposits and MBC credits of an institution;
updating, by the at least one computing system, the first MBC entry of the overlay ledger to modify the MBC balance of the MBC account held by the customer by the amount of MBC and the second MBC entry of the overlay ledger to increase the MBC balance of the MBC account of the online merchant by a corresponding amount;
broadcasting, by the at least one computing system, the remote exchange to a plurality of MBC verification nodes for verification;
identifying, by the at least one computing system using the overlay ledger, updated MBC balances for the customer and the online merchant decoupled from the total amount of MBC deposits and MBC credits of the institution and the first public and private key pair stored in the pooled account database; and
executing, by the at least one computing system, one or more MBC operations based on the updated MBC balances reflected in the overlay ledger;
wherein the overlay ledger comprises a plurality of MBC entries corresponding with amounts of MBC stored separately from a plurality of private and public key pairs of the pooled account database, and wherein the MBC account of the online merchant is an MBC entry of the plurality of MBC entries in the overlay ledger.
Claim 1 of the ‘626 patent differs since it further recites additional claim limitations, “the remote exchange request corresponding with a math based currency (MBC) credit card account of a customer and a fiat currency credit card account of the customer,” “online merchant,” “identifying, by the at least one computing system, a first MBC entry in an overlay ledger that reflects an MBC balance of the MBC account of the customer and a second MBC entry in the overlay ledger that reflects an MBC balance for an MBC account of the online merchant;” “identifying, by the at least one computing system using the overlay ledger, updated MBC balances for the customer and the online merchant decoupled from the total amount of MBC deposits and MBC credits of the institution and the first public and private key pair stored in the pooled account database,” “executing, by the at least one computing system, one or more MBC operations based on the updated MBC balances reflected in the overlay ledger;” “wherein the overlay ledger comprises a plurality of MBC entries corresponding with amounts of MBC stored separately from a plurality of private and public key pairs of the pooled account database, and wherein the MBC account of the online merchant is an MBC entry of the plurality of MBC entries in the overlay ledger.” However, it would have been obvious to a person of ordinary skill in the art to modify claim 1 of the ‘626 patent by removing the limitations directed to looking up MBC balances and updated balances of the MBC accounts of the customer and the online merchant in the overlay ledger, executing MBC operations in the overlay ledger in claim 1 of the present application since the claim of the present application and the claim recited in the ‘626 patent actually perform a similar function. It is well settled that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson, 136 USPQ 184 (CCPA 1963). Also note Ex parte Rainu, 168 USPQ 375 (Bd. App. 1969). Omission of a reference element whose function is not needed would be obvious to one of ordinary skill in the art.
Claims 11-20 of the present application
Although the conflicting claims are not identical, they are not patentably distinct from each other. Claim 9 of the ‘626 patent recites a system, comprising:
at least one processing circuit configured to:
receive, from a customer computer system, a remote exchange request for an amount, the remote exchange request corresponding with a math based currency (MBC) account of a customer and a fiat currency account of the customer, wherein the remote exchange request is initiated upon triggering a remote exchange for a remote, card-based exchange with an online merchant;
identify a first MBC entry in an overlay ledger that reflects an MBC balance of the MBC account of the customer and a second MBC entry in the overlay ledger that reflects an MBC balance for an MBC account of the online merchant;
generate or identify a first public and private key pair of the MBC account of the online merchant;
exchange, on a published blockchain, an amount of MBC equal to the amount using the first public and private key pair of the MBC account of the online merchant;
store the first public and private key pair of the MBC account of the online merchant in a pooled account database, wherein the pooled account database stores a total amount of MBC deposits and MBC credits of an institution;
update the first MBC entry of the overlay ledger to modify the MBC balance of the MBC account held by the customer by the amount of MBC and the second MBC entry of the overlay ledger to increase the MBC balance of the MBC account of the online merchant by a corresponding amount;
broadcast the remote exchange to a plurality of MBC verification nodes for verification;
identify, using the overlay ledger, updated MBC balances for the customer and the online merchant decoupled from the total amount of MBC deposits and MBC credits of the institution and the first public and private key pair stored in the pooled account database; and
execute one or more MBC operations based on the updated MBC balances reflected in the overlay ledger;
wherein the overlay ledger comprises a plurality of MBC entries corresponding with amounts of MBC stored separately from a plurality of private and public key pairs of the pooled account database, and wherein the MBC account of the online merchant is an MBC entry of the plurality of MBC entries in the overlay ledger.
Claim 9 of the ‘626 patent differs since it further recites additional claim limitations, “the remote exchange request corresponding with a math based currency (MBC) credit card account of a customer and a fiat currency credit card account of the customer,” “online merchant,” “identify a first MBC entry in an overlay ledger that reflects an MBC balance of the MBC account of the customer and a second MBC entry in the overlay ledger that reflects an MBC balance for an MBC account of the online merchant;” “identify, using the overlay ledger, updated MBC balances for the customer and the online merchant decoupled from the total amount of MBC deposits and MBC credits of the institution and the first public and private key pair stored in the pooled account database;” “exchange, on a published blockchain, an amount of MBC equal to the amount using the first public and private key pair of the MBC account of the online merchant;” “wherein the overlay ledger comprises a plurality of MBC entries corresponding with amounts of MBC stored separately from a plurality of private and public key pairs of the pooled account database, and wherein the MBC account of the online merchant is an MBC entry of the plurality of MBC entries in the overlay ledger.” However, it would have been obvious to a person of ordinary skill in the art to modify claim 9 of the ‘626 patent by removing the limitations directed to looking up MBC balances and updated balances of the MBC accounts of the customer and the online merchant in the overlay ledger, executing MBC operations in the overlay ledger in claim 11 of the present application since the claim of the present application and the claim recited in the ‘626 patent actually perform a similar function. It is well settled that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson, 136 USPQ 184 (CCPA 1963). Also note Ex parte Rainu, 168 USPQ 375 (Bd. App. 1969). Omission of a reference element whose function is not needed would be obvious to one of ordinary skill in the art.
Claim Rejections – 35 USC §101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
In the instance case, claims 1-10 are directed to a method (‘process), and claims 11-20 are directed to a system (‘machine’). Therefore, these claims fall within the four statutory categories of invention.
Independent Claims 1 and 11
Step 2A Prong One
The claims recite (i.e., sets forth or describes) an abstract idea of currency exchange. Specifically, the following underlined claim elements recite abstract ideas while the nonunderlined claim elements recite additional elements according to MPEP 2106.04(a). The claims recite:
receiving, by at least one computing system and from another system, a request for an amount, the request corresponding with an account of a customer, wherein the request is initiated upon triggering a credit-based exchange with a merchant;
generating or identifying, by the at least one computing system, a first public and private key pair of the merchant;
exchanging, by the at least one computing system on a published blockchain, an amount of MBC equal to the amount using the first public and private key pair of the merchant;
storing, by the at least one computing system, the first public and private key pair of the online merchant in a pooled account database, wherein the pooled account database stores a total amount of MBC deposits and MBC credits of an institution;
updating, by the at least one computing system, a first MBC entry of an overlay ledger to modify an MBC balance held by the customer by the amount of MBC and a second MBC entry of the overlay ledger to increase the MBC balance of an account of the merchant by a corresponding amount; and
broadcasting, by the at least one computing system, the exchange to a plurality of MBC verification nodes for verification.
More specifically, but for the additional elements, the claims, under its broadest reasonable interpretation, recite the abstract idea because the claims describe a process of currency exchange including receiving a request for currency exchange, performing the currency exchange, updating balances in one party’s account, another party’s account and pooled account for the currency exchange, and verifying the currency exchange, grouped within “certain methods of organizing human activity” grouping of the abstract ideas. The claim limitations reciting the abstract idea are grouped within the “certain methods of organizing human activity” grouping of abstract ideas because the limitations describe fundamental economic principles or practices, including mitigating risk, and describe commercial or legal interactions, including advertising, marketing or sales activities or behavior, and business relations. Furthermore, the limitations, “generating…public and private key pair…”, “exchanging…an amount of MBC equal to the amount…”are also an abstract idea grouped within “mathematical concepts” (i.e., mathematical relationships, mathematical formulas or equations, and mathematical calculations). The claims are still abstract idea because merely combining several abstract ideas does not render the combination any less abstract.
Step 2A Prong Two
This judicial exception is not integrated into a practical application. The non-underlined additional elements of “computing system,” “another system,” “published blockchain,” “pooled account database,” “overlayed ledger,” “verification nodes,” recited in claim 1, as well as “one or more non-transitory computer-readable storage media having instructions stored thereon that, when executed by at least one processing circuit, cause the at least one processing circuit to” recited in claim 17, merely use computers as a tool to perform the abstract idea and it amounts to no more than mere instructions to apply the exception using generic computer components. Accordingly, the additional elements, individually and in combination, do not integrate the judicial exception into a practical application. The claims are directed to an abstract idea.
Step 2B
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely use computers as a tool to perform the abstract idea and it amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Viewed as a whole, the additional elements, taken individually and in combination, do not result in the claims, amounting to significantly more than the judicial exception. Therefore, the claims do not provide an inventive concept, and thus, is not patent eligible.
Dependent Claims 2-10, 12-20
Claims 2 and 12 recite details of the request. Claims 3 and 13 recite characteristics of a recipient computer system. Claims 4 and 12 recite characteristics of a distributed ledger network. Claims 7 and 15 recite characteristics of the at least one processing circuit. Claims 8 and 16 recite further characteristics of the specific asset. Claims 10 and 20 recite characteristics of the request. Therefore, the claims further recite the abstract idea of currency exchange.. The claims do not introduce any new additional element. Therefore, the claims do not integrate the judicial exception into a practical application or amount to significantly more than the judicial exception.
Claims 5 and 15 recite the following underlined claim elements as abstract ideas while the nonunderlined claim elements recite additional elements according to MPEP 2106.04(a).
wherein updating the overlay ledger is responsive to determining that the merchant is registered with the institution without validating the exchange with the plurality of MBC verification nodes.
As above, the claim further recites the abstract idea of currency exchange. The claim does not introduce any new additional element. Therefore, the claim does not integrate the judicial exception into a practical application or amount to significantly more than the judicial exception.
Claims 6 and 16 recite the following underlined claim elements as abstract ideas while the nonunderlined claim elements recite additional elements according to MPEP 2106.04(a).
wherein the remote exchange request is received in response to the customer manually inputting MBC account information corresponding to checkout for products or services of the merchant.
As above, the claim further recites the abstract idea of currency exchange. The claim does not introduce any new additional element. Therefore, the claim does not integrate the judicial exception into a practical application or amount to significantly more than the judicial exception.
Claims 9 and 19 recite the following underlined claim elements as abstract ideas while the nonunderlined claim elements recite additional elements according to MPEP 2106.04(a).
determining, by the at least one computing system, that the merchant is not registered with the institution;
transmitting, by the at least one computing system, an MBC exchange token to the plurality of MBC verification nodes comprising the first public and private key pair and a hash corresponding with a public key of the first public and private key pair; and
verifying, by the at least one computing system, the exchange on the published blockchain.
As above, the claim further recites the abstract idea of currency exchange. The claim does not introduce any new additional element. Therefore, the claim does not integrate the judicial exception into a practical application or amount to significantly more than the judicial exception.
Claim Rejections – 35 USC §112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 9 and 19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 9 and 19 each recites the limitations, “wherein updating the overlay ledger is responsive to: determining, by the at least one computing system, that the merchant is not registered with the institution; transmitting, by the at least one computing system, an MBC exchange token to the plurality of MBC verification nodes comprising the first public and private key pair and a hash corresponding with a public key of the first public and private key pair...” Even though the limitations appear in claim portions of applicant’s disclosure (PGPub US 20260187608A1), applicant’s specification does provide written descriptions on the limitations of determining that the merchant is not registered with the institution, transmitting an MBC exchange token to the verification nodes comprising the first public and private key pair and a hash corresponding with a public key of the first public and private key pair. According to paragraphs [0049] and [0050], “if the holder is not registered, the financial institution registeres the holder (406). …if the holder is registered…the MBC transaction processor 216 creates a new private key (“PrKp”) and a public key (“PuKp”)…The PrKp and PuKp will ultimately be stored in the pooled account 126…” Therefore, the specification is silent on the limitations, “wherein updating the overlay ledger is responsive to: determining, by the at least one computing system, that the merchant is not registered with the institution; transmitting, by the at least one computing system, an MBC exchange token to the plurality of MBC verification nodes comprising the first public and private key pair and a hash corresponding with a public key of the first public and private key pair...” Furthermore, the specification is silent on the term, “MBC exchange token” and “transmitting…an MBC exchange token to the plurality of the MBC verification cnodes…”
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Lack of Antecedent Basis
Claim 1 recites “storing…the first public and private key pair of the online merchant…” There is insufficient antecedent basis for this limitation, “the online merchant.” Claim 11 is also rejected on the same basis as it recites similar language.
Claims 2 and 12 each recites “…wherein associations of the amounts of MBC with the at least one of the MBC account or the fiat currency account are decoupled from the total amount of MBC deposits and MBC credits of the institution.” There is insufficient antecedent basis for this limitation, “the amounts of MBC.”
Claims 6 and 16 each recites “wherein the remote exchange request is received in response to the customer manually inputting MBC account information corresponding to checkout for products or services of the merchant.” There is insufficient antecedent basis for this limitation, “the remote exchange request.”
Claims 10 and 20 each recites “wherein the request comprises an indication of the institution of a plurality of financial institutions as a credit card issuer based on the merchant POS system determining the institution of the physical credit card..” There is insufficient antecedent basis for this limitation, “the merchant POS system.”
Claims 2-10 are also rejected as each depends upon claim 1. Claims 12-20 are also rejected as each depends upon claim 11.
Unclear Scope
Claim 8 recites “creating, by the at least one computing system, a second public and private key pair associated with an amount of MBC equivalent to the MBC balance of the customer in response to the update of the first MBC entry…” Even though the limitations appear in claim portions of applicant’s disclosure (PGPub US 20260187608A1), applicant’s specification does not provide descriptions of creating a second public and private key pair associated with an amount of MBC equivalent to the MBC balance of the customer in response to the update of the first MBC entry. The specification describes that the systems and process described therein may also be used in connection with other types of card-based transaction, such as debit cards, stored value cards, and so on. (see paragraph [0081] of the specification. Therefore, the claim is unclear because the claims are not in line with the specification. Claim 18 is also rejected on the same basis as it recites similar language.
Claim Rejections – 35 USC §103
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Shtylman, R. (US 2015/0262139A1 (“Shtylman”)) in view of MacGregor et al. (US 2015/0269539A1 (“MacGregor”)).
Per Claims 1 and 11: Shtylman discloses a method, comprising:
receiving, by at least one computing system and from another system, a request for an amount, the request corresponding with an account of a customer, wherein the request is initiated upon triggering a credit-based exchange with a merchant; (Fig. 55; ¶¶129)
generating or identifying, by the at least one computing system, [information] of the merchant; (¶¶6, 84, 103, 181-182)
exchanging, by the at least one computing system on a published blockchain, an amount of MBC equal to the amount using the first public and private key pair of the merchant; (Fig. 66, Fig. 55; ¶¶8, 14, 135 )
storing, by the at least one computing system, the [information] of the online merchant in a pooled account database (Fig. 73a-73f; ¶¶134, 208-209, 210-215), wherein the pooled account database stores a total amount of MBC deposits and MBC credits of an institution; (Fig. 73a-73f; ¶¶210-215)
updating, by the at least one computing system, a first MBC entry of an overlay ledger to modify an MBC balance held by the customer by the amount of MBC and a second MBC entry of the overlay ledger to increase the MBC balance of an account of the merchant by a corresponding amount; and (Fig. 3, Fig. 45, Fig. 55, Fig. 73a-73f; ¶¶38, 87, 103, 136-140)
broadcasting, by the at least one computing system, the exchange to a plurality of MBC verification nodes for verification. (¶¶38, 82, 104)
Additionally, for claim 11, Shtylman discloses a system (Fig. 1), comprising: at least one processing circuit configured to: (¶226)
Shtylman discloses information of the merchant being generated and the address information being derived from public key of the merchant (¶6, 84, 103, 181-182) and storing the merchant information in a pooled account database (Fig. 73a-73f; ¶¶134, 208-209, 210-215). However, Shtylman does not explicitly disclose a first public and private key pair of the merchant being generated. Also, Shtylman does not explicitly disclose the first public and private key pair of the online merchant being stored in a database.
MacGregor discloses generating or identifying a first public and private key pair of the merchant (¶¶105), and storing first public and private key pair of the online merchant in a database. (¶¶105)
It would have been obvious to one of ordinary skill in the art to include in the method, as disclosed by Shtylman, generating and storing merchant public and private key pair in a database, as taught by MacGregor, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one or ordinary skill in the art would have recognized that the results of the combination were predictable. It further would have been obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to modify the method of Shtylman for streamlining and improving the customer experience (MacGregor: ¶122).
Furthermore, the recitation, “wherein the request is initiated upon triggering a credit-based exchange with a merchant,” does not move to distinguish over prior art as the recitation does not affect the claimed method of claim 1 and the claimed system of claim 11. The language, “initiated,” does not further describe a previous act of initiating and there is no claimed step/function of initiating. Nor the expression affect the recited system in claim 11 structurally or functionally.
Moreover, the language, “wherein the pooled account database stores a total amount of MBC deposits and MBC credits of an institution,” recite intended use language of the pooled account database. The recitation of the intended use of the claimed invention does not serve to differentiate the claim from the prior art. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use (MPEP §2103 I C).
Per Claims 2 and 12: Shtylman in view of MacGregor discloses all the limitations of claims 1 and 11.
Shtylman discloses comprising:
wherein the request corresponds at least one of an MBC account or a fiat currency account of the customer (Fig. 55; ¶¶129), wherein associations of the amounts of MBC with the at least one of the MBC account or the fiat currency account are decoupled from the total amount of MBC deposits and MBC credits of the institution. (Fig. 73a-73f; ¶¶8, 134, 208-209, 210-215)
Furthermore, the recitation, “wherein associations of the amounts of MBC with the at least one of the MBC account or the fiat currency account are decoupled from the total amount of MBC deposits and MBC credits of the institution,” does not move to distinguish over prior art as the recitation does not affect the claimed method in claim 1 and the claimed system in claim 11. The language, “decoupled,” does not further describe a previous act of decoupling and there is no claimed step/function of decoupling. Nor the expression affect the recited system of claim 11 structurally or functionally.
Per Claims 3 and 13: Shtylman in view of MacGregor discloses all the limitations of claims 1 and 11.
Shtylman discloses comprising:
wherein a recipient computer system is associated with the merchant remote from the customer computer system. (Fig. 55; ¶¶129)
Per Claims 4 and 14: Shtylman in view of MacGregor discloses all the limitations of claims 1 and 11.
Shtylman discloses comprising:
wherein receiving the request further comprises receiving an exchange identifier that correlates to the account of the customer (Fig. 55; ¶¶19, 129), and wherein the amounts of MBC associated in the overlay ledger is less than a total amount of MBC on deposit at the institution. (¶¶211)
Per Claims 5 and 15: Shtylman in view of MacGregor discloses all the limitations of claims 1 and 11.
Shtylman discloses comprising:
wherein updating the overlay ledger is responsive to determining that the merchant is registered with the institution without validating the exchange with the plurality of MBC verification nodes. (Fig. 55; ¶¶17, 104, 129)
Furthermore, the recitation, “the merchant is registered with the institution without validating the exchange with the plurality of MBC verification nodes,” does not move to distinguish over prior art as the recitation does not affect the claimed method of claim 1 and the claimed system of claim 11. The language, “registered,” does not further describe a previous act of registering and there is no claimed step/function of registering. Nor the expression affect the recited system in claim 11 structurally or functionally.
Per Claims 6 and 16: Shtylman in view of MacGregor discloses all the limitations of claims 1 and 11.
Shtylman discloses comprising:
wherein the remote exchange request is received in response to the customer manually inputting MBC account information corresponding to checkout for products or services of the merchant. (Fig. 55; ¶129)
Per Claims 8 and 18: Shtylman in view of MacGregor discloses all the limitations of claims 1 and 11.
Shtylman discloses comprising:
creating, by the at least one computing system, a second [information] associated with an amount of MBC equivalent to the MBC balance of the customer in response to the update of the first MBC entry; and (Fig. 45; ¶¶6, 84, 103, 181-182)
updating, by the at least one computing system, the pooled account database with the second [information]. (Fig. 45; ¶¶6, 84, 103, 181-182)
MacGregor discloses generating or identifying a first public and private key pair of the merchant (¶¶105), and storing first public and private key pair of the online merchant in the database. (¶¶105)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of Shtylman in view of MacGregor to incorporate the teachings of generating and storing user public-private key pair, as disclosed in MacGregor, for streamlining and improving the customer experience (MacGregor: ¶122).
Per Claims 9 and 19: Shtylman in view of MacGregor discloses all the limitations of claims 1 and 11.
Shtylman discloses updating the overlay ledger is responsive to (Fig. 3, Fig. 45, Fig. 55; ¶¶87, 103, 136-140):
determining, by the at least one computing system, that the merchant is not registered with the institution; (¶¶85, 88)
transmitting, by the at least one computing system, an MBC exchange token to the plurality of MBC verification nodes comprising the first public and private key pair and a hash corresponding with a public key of the first public and private key pair; and (¶¶8, 10, 38, 82, 102, 104)
verifying the exchange on the published blockchain. (¶¶38, 82, 104)
Furthermore, the claims reciting the step of determining that the merchant is not registered with the institution and transmitting an MBC exchange token comprising the first public and private key pair and a hash corresponding with a public key of the first public and private kay pair. However, claims 1 and 11, which claims 9 and 19 depend upon, recite the generated first public and private key pair of the merchant being stored in the pooled account database, which indicates that the merchant is registered based on paragraphs [0049] and [0050] of the specification, “if the holder is registered…the MBC transaction processor 216 creates a new private key (“PrKp”) and a public key (“PuKp”)…The PrKp and PuKp will ultimately be stored in the pooled account 126…” Therefore, the limitations in claims 9 and 19 are mutually exclusive from claims 1 and 11, and are not performed because whether the limitations of claims 1 and 11 can be performed or limitations of claims 9 and 19 can be performed but not both. Therefore, it does not get patentable weight (MPEP 2111.04).
Claims 7, 10 and 17, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shtylmanin view of MacGregor as applied to claims 1 and 11 in further view of DeCastro, E. (US 2015/0170112A1 (“DeCastro”)).
Per Claims 7 and 17: Shtylmanin view of MacGregor discloses all the limitations of claims 1 and 11.
Shtylmanin view of MacGregor does not explicitly disclose:
wherein the MBC account of the customer corresponds with a limit, and wherein in response to determining the online merchant does not accept MBC payments, process the request as a fiat currency payment using an open loop processing network.
DeCastro discloses:
wherein the MBC account of the customer corresponds with a limit, and wherein in response to determining the online merchant does not accept MBC payments, process the request as a fiat currency payment using an open loop processing network. (¶¶23, 37-38, 74)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of Shtylman in view of MacGregor to incorporate the teachings of processing of user transaction using multi-currency (MBC or fiat), as disclosed in DeCastro, for enabling the seamless integration of emerging digital assets like cryptocurrencies and fiat currency. (DeCastro: ¶22).
Per Claims 10 and 20: Shtylman in view of MacGregor discloses all the limitations of claims 1 and 11.
Shtylmanin view of MacGregor does not explicitly disclose:
wherein the request comprises an indication of the institution of a plurality of financial institutions as a credit card issuer based on the merchant POS system determining the institution of the physical credit card.
DeCastro discloses:
wherein the request comprises an indication of the institution of a plurality of financial institutions as a credit card issuer based on the merchant POS system determining the institution of the physical credit card. (¶¶35, 74)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of Shtylman in view of MacGregor to incorporate the teachings of determination of issuer of credit card transactions, as disclosed in DeCastro, for enabling the seamless integration of emerging digital assets like cryptocurrencies and fiat currency. (DeCastro: ¶22).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Durbin et al. (US 2015/0262173A1) teaches a method for wire transfers using cryptocurrency.
Cranberry et al. (US 2013/0080331A1) teaches a system for performing a retail payment between a customer and a merchant is provided. The system includes a signed scrip having a public key, a credit value, a signed scrip validation stamp, a credit value, and a validation stamp; a signed invoice comprising a transaction list and an invoice validation stamp; and a private key complementary to the public key, wherein the public key is used to decode the signed scrip; the private key is stored in a server coupled to a network; and the private key is used by the server to validate the authenticity of the signed invoice.
Minor, H. (US 2015/0332256A1) teaches a method for converting cryptocurrency to virtual assets whose value is substantiated by a reserve of assets.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENYUH KUO whose telephone number is (571)272-5616. The examiner can normally be reached on Monday-Friday 8-4 PM EST.
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, John W. Hayes can be reached on (571)272-6708. 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.
/CHENYUH KUO/Primary Examiner, Art Unit 3697
Prosecution Insights