DETAILED ACTION
This action is in reply to the request for continued examination filed on 07/29/2025.
Claims 2, 7-20 were previously canceled.
Claims 3, 22, and 27 have been cancelled.
Claims 1, 21, 26 and 29 have been amended.
Claims 1, 4-6, 21, 23-26, 28-30 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/29/2025 has been entered.
Response to Arguments
With regard to the 101 rejection, the arguments have been considered but they are not persuasive. The Applicant asserted in page 8 that “[these] additional elements integrate the alleged judicial exception into a practical application. Specifically, the ledger interoperability service orchestrates postings to the client demand deposit account . . .”. However, the claim limitations are directed to conducting and managing cryptocurrency transactions in which the transactions are based on distributed ledger. In other words, these are steps that describe a transfer of funds between an omnibus account to a beneficiary bank account. Hence, the claims are directed to sales behavior - commercial interactions (Certain Methods of Organizing Human Activities).
Furthermore, in Step 2A Prong Two, the limitations are not indicative of integration into a practical application. They are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). Therefore, since the limitations are not indicative of integration into a practical application and directed to an abstract idea, the claim is not patent eligible.
With regard to the 103 rejection, the Applicant has amended the independent claims. Bhos, however, still discloses the added limitation. The independent claims are still rejected over Bhos et al. (US 11,182,776 B1) in view of Castinado et al. (US 2021/0112063 A1)) in further view of Kilgore et al. (US 2021/0158443 A1). Please see the 103 rejection for further details.
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, 4-6, 21, 23-26, 28-30 are directed to a method, a product, and a system which are one of the statutory categories of invention. (Step 1: YES).
Claims 1, 4-6, 21, 23-26, 28-30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional computer elements, which are recited at a high level of generality, provide conventional computer functions that do not add meaningful limits to practicing the abstract idea.
Claim 1 is disclosed. Claim 1, for instance, recites, in part, a method for digital coin issuance, comprising: receiving, at a ledger interoperability service and from a gateway communication service, a request to deposit a digital coin balance for an amount of funds for a client to a client digital coin wallet on a distributed ledger, wherein the ledger interoperability service is configured to transfer balances between a standard deposit account operating ledger for a financial institution and the distributed ledger; receiving, at an omnibus account on the standard deposit account operating ledger, a transfer of the funds from a client demand deposit account on the standard deposit account operating ledger for the client; identifying, by the ledger interoperability service, an address on the distributed ledger for the client digital coin wallet using an address book comprising a mapping of registered clients to distributed ledger addresses on the distributed ledger for digital coin wallets; generating, by the ledger interoperability service, a unique identifier that is mapped to a request to issue the digital coin balance to the address on the distributed ledger for the client digital coin wallet on the distributed ledger and to generate postings for the digital coin balance for the distributed ledger; submitting, by the ledger interoperability service, the request and the unique identifier to the gateway communication service, wherein the request is secured using public key encryption; receiving, by the ledger interoperability service, confirmation from gateway communication service of writing the digital coin balance to the client digital coin wallet; and orchestrating, by the ledger interoperability service, the postings to the client demand deposit account and the client digital coin wallet using the gateway communication service. The concept here is similar to the concept of conducting and managing transactions between accounts. Such concept is directed to business relations (commercial interactions). Hence, they fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
Claim 21 recites, in part, a non-transitory computer readable storage medium, including instructions stored thereon, which when read and executed by one or more computer processors, cause the one or more computer processors to perform steps comprising: receiving, at a ledger interoperability service and from a gateway communication service, a request to deposit a digital coin balance for an amount of funds for a client to a client digital coin wallet on a distributed ledger, wherein the ledger interoperability service is configured to transfer balances between a standard deposit account operating ledger for a financial institution and the distributed ledger; receiving, at an omnibus account on the standard deposit account operating ledger, a transfer of the funds from a client demand deposit account on the standard deposit account operating ledger for the client; identifying, by the ledger interoperability service, an address on the distributed ledger for the client digital coin wallet using an address book comprising a mapping of registered clients to distributed ledger addresses on the distributed ledger for digital coin wallets; generating, by the ledger interoperability service, a unique identifier that is mapped to a request to issue the digital coin balance to the address on the distributed ledger for the client digital coin wallet on the distributed ledger and to generate postings for the digital coin balance for the distributed ledger; submitting, by the ledger interoperability service, the request and the unique identifier to the gateway communication service; receiving, by the ledger interoperability service, confirmation from gateway communication service of writing the digital coin balance to the client digital coin wallet; and orchestrating, by the ledger interoperability service, the postings to the client demand deposit account and the client digital coin wallet using the gateway communication service. The concept here is similar to the concept of conducting and managing transactions between accounts. Such concept is directed to business relations (commercial interactions). Hence, they fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
Claim 26 is grouped together. Claim 26, for instance, recites, in part, a system, comprising: a distributed ledger comprising a plurality of digital coin wallet and a gateway communication service; a core banking platform comprising a standard deposit account operating ledger; and a ledger interoperability service in communication with the distributed ledger and the core banking platform, wherein the ledger interoperability service is configured to transfer balances between the standard deposit account operating ledger for a financial institution and the distributed ledger and comprises an address book comprising a mapping of addresses on the distributed ledger for registered clients to distributed ledger addresses on the distributed ledger for digital coin wallets; wherein: the ledger interoperability service receives, from the gateway communication service, a request to deposit a digital coin balance for an amount of funds for a client to a client digital coin wallet on the distributed ledger; an omnibus account on the standard deposit account operating ledger receives a transfer of the funds from a client demand deposit account on the standard deposit account operating ledger for the client; the ledger interoperability service identifies an address on the distributed ledger for the client digital coin wallet using the address book; the ledger interoperability service generates a unique identifier that is mapped to a request to issue the digital coin balance to the address on the distributed ledger for the client digital coin wallet on the distributed ledger and to generate postings for the digital coin balance for the distributed ledger; the ledger interoperability service submits the request and the unique identifier to the gateway communication service; and the ledger interoperability service receives confirmation from gateway communication service of writing the digital coin balance to the client digital coin wallet; and the ledger interoperability service orchestrates the postings to the client demand deposit account and the client digital coin wallet using the gateway communication service. The concept here is similar to the concept of conducting and managing transactions between accounts. Such concept is directed to business relations (commercial interactions). Hence, they fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
This judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements such as a non-transitory computer readable storage medium, one or more processors, a gateway communication service, a distributed ledger, a digital coin wallet, a banking platform, a ledger interoperability service, account operating ledger, a financial institution, a client, an omnibus account, a standard deposit account operating ledger, a unique identifier and other generic computer components to perform requesting, identifying, validating, transferring, and recording. The generic computer components are recited at a high-level of generality (requesting, identifying, transferring and recording) such that it amounts no more than mere instructions to apply the exception using a generic computer component. In addition, the ledgers and crypto are generally linking to the technology of cryptocurrency on a blockchain. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Hence, the claim is directed to an abstract idea
Next the claim as a whole is analyzed to determine whether any element, or combination of elements, is sufficient to ensure the claim amounts to significantly more than an abstract idea. Claims 1, 21 and 26 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). There is no improvement to computer technology or computer functionality MPEP 2106.05(a) nor a particular machine MPEP 2106.05(b) nor a particular transformation MPEP 2106.05(c). Additionally, the limitation of sending a request or message over network is recognized as well-understood, routine, conventional activity. 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) see MPEP 2106.05(d). Given the above reasons, a generic processing device associated with the managing and conducting transactions between accounts is not an Inventive Concept. Thus, the claim is not patent eligible.
The dependent claims have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The Dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea.
Claims 4, 23, 28 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) a method of signing the request to issue the coin balance. This judicial exception is not integrated into a practical application because the limitations are Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The claim(s) does/do not include additional elements (such as ledger interoperability service, gateway communication service, client digital coin wallet, distributed ledger) that are sufficient to amount to significantly more than the judicial exception because the limitations are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Claims 5, 24, 29 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) a method of issuing the digital coin balance and generating postings to the ledger. This judicial exception is not integrated into a practical application because the limitations are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The claim(s) does/do not include additional elements (such as gateway communication service, digital coin wallet, distributed ledger, a client) that are sufficient to amount to significantly more than the judicial exception because the limitations are Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Claims 6, 25, 30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) a method of issuing the digital coin balance and generating postings to the ledger. This judicial exception is not integrated into a practical application because the limitations are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The claim(s) does/do not include additional elements (such as the gateway communication service, distributed ledger, application programmable interference call) that are sufficient to amount to significantly more than the judicial exception because the limitations are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Therefore, claims 1, 4-6, 21, 23-26, 28-30 are not drawn to eligible subject matter as they are directed to an abstract idea without significantly more.
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, 4-6, 21, 23-26, 28-30 are rejected under 35 U.S.C. 103 as being unpatentable over Bhos et al. (US 11,182,776 B1) in view of Castinado et al. (US 2021/0112063 A1)) in further view of Kilgore et al. (US 2021/0158443 A1).
The present application recites a concept of transferring digital currency on a distributed ledger with the use of an omnibus account to clear the transactions.
The independent claim 1 is disclosed. Bhos teaches: A method for digital coin issuance, comprising: receiving, at a ledger interoperability service and from a gateway communication service, a request to deposit a digital coin balance for an amount of funds for a client to a client digital coin wallet on a distributed ledger (Col. 10 ln 4-12, “The network interface 300 includes program logic and/or components that facilitate connection of the provider computing system 104 to the network 116. Accordingly, the network interface 300 supports communication between the provider computing system 104 and other components of the system 100, such as the customer device 102, the partner provider computing system 106, the issuer computing system 108, and the one or more distributed ledger computing systems 110 . . .” (note: network interface corresponds to gateway communication service) & Col. 8 ln 2-6 “. . . the mobile wallet application 206 may facilitate the customer in making a transfer from a payment account (e.g., a demand deposit account) held by the customer to the customer's mobile wallet . . .”) Interpretation: the cited portion discloses depositing funds to a wallet account operated as part of the distributed ledger , wherein the ledger interoperability service is configured to transfer balances between a standard deposit account operating ledger for a financial institution and the distributed ledger (“. . . FIG. 4 illustrates a block diagram depicting a currency exchange using multiple customer accounts, according to an example embodiment. At 350, the customer holds an account 356 in U.S. dollars. At 352, the customer has initiated a currency exchange from dollars to Euros. As such, the currency exchange circuit 306 sets up a new account 358 for the customer in Euros (e.g., because this is the first time the customer has made an exchange to Euros). At 354, the customer's U.S. dollars account 356 is debited $100.00, and the customer's Euros account 358 is credited €86.73 (e.g., at an exchange rate of 0.8673). The customer may now make payments, transfers, and/or exchanges from the Euros account 358 using the currency that has been received in the exchange . . .” & “. . . . In various embodiments, the system 100 includes the issuer computing system 108 as part of a distributed ledger currency rail used for currency transfers. The issuer computing system 108 is associated with an issuer, which serves as a neutral third party in a currency transfer between the provider computing system 104 and the partner provider computing system 106 . . .”) Interpretation: the cited portion discloses transferring balance between a standard account to an account on a distributed ledger using currency rail;
receiving, at an omnibus account on the standard deposit account operating ledger, a transfer of the funds from a client demand deposit account on the standard deposit account operating ledger for the client (Col. 19 ln 56-Col. 20 ln 5; Examiner’s Interpretation: the cited portion discloses concept of requesting a transfer from the payor to a general account recorded on the distributed ledger & Col. 19 ln 44-55) The amount is debited from the payor’s account and credited on the ledger account;
and receiving, by the ledger interoperability service, confirmation from gateway communication service of writing the digital coin balance to the client digital coin wallet (Bhos, Col. 20 ln 1-21 “. . .In some arrangements, the provider computing system 104 uses the general ledger to determine an amount of fiat currency to transfer to the issuer computing system 108, which creates a corresponding amount of digital tokens in the omnibus account on the distributed ledger. In other arrangements, recording the credit to the general ledger directly results in the creation of a corresponding amount of digital tokens in the omnibus account (e.g., such that the issuer computing system 108 may not be needed or play a lesser role in the system 100) . At 1006, the provider computing system 104 communicates with the partner provider computing system 106 regarding the currency transfer. As an example, the provider computing system 104 sends the partner provider computing system 106 a secure message (e.g., through an existing communication channel or through a communication channel for the distributed ledger currency rail), with the secure message identifying the recipient and the transfer amount. The secure message may further identify the account of the recipient that the currency transfer should be provided to (e.g., based on information provided by the customer, based on preset preferences by the recipient, etc.”) Interpretation: under BRI, the general ledger created, or confirmed, the digital coin balance in the ledger and such balance is used to transfer to the recipient account;
and orchestrating, by the ledger interoperability service, the postings to the client demand deposit account and the client digital coin wallet using the gateway communication service (Bhos, Col. 14 ln 62- Col. 15 ln 15) the system operates the posting between the accounts on the distributed ledgers.
Bhos does not disclose the following; however, Castinado teaches:
identifying, by the ledger interoperability service, an address on the distributed ledger for the client digital coin wallet using an address book (Castinado, see at least par. [0049] “. . . In general, as described in greater detail below, the customer 101 initiates a P2P payment using an alias by communicating an alias 117 and an associated payment amount to the financial institution. The financial institution then accesses an alias database, or other type of data repository, to determine if the entered alias 117 has been registered by the alias holder and is, thereby, associated with a particular financial institution account . . .”; Interpretation: beneficiary name corresponds to alias and is associated with a financial account), comprising a mapping of registered clients to distributed ledger addresses on the distributed ledger for digital coin wallets (Castinado, see at least par. [0043] “. . . retrieve an alias-to-entity mapping from the accessed distributed ledger, wherein the alias-to-entity mapping indicates at least an entity to which the alias is mapped . . .” & see at least par. [0184] “. . . nodes 1300 must validate the authenticity of the alias before the transaction may be approved. A specific example would be a customer having an alias of “customer@email.com” that requests a P2P transaction using the block chain distributed network. This alias may be linked (i.e., mapped) to BANK1 on the distributed ledger on the block chain. The alias may also be linked (i.e., mapped) to ACCOUNT1 maintained at BANK1. The mapping of the alias to ACCOUNT1 is a contained on a private register held by BANK1. . . .” & par. [0190]) Interpretation: the alias is an address which used to link to Bank1 on the distributed ledger on the blockchain. The alias may be linked to Account 1 and also linked to a digital coin wallet (which in turn is associated with an account).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhos by including identifying a beneficiary digital coin wallet distributed ledger address for a beneficiary digital coin wallet for the beneficiary name and/or beneficiary account number on a distributed ledger as taught by Castinado, because using an alias to identify payment account helps to improve a P2P payment (Castinado, par. [0049]) . Therefore, the claimed invention is obvious in view of the cited references.
Bhos in view Castinado does not disclose the following; however, Kilgore teaches:
generating, by the ledger interoperability service, a unique identifier that is mapped to a request to issue the digital coin balance to the address on the distributed ledger for the client digital coin wallet on the distributed ledger (Kilgore, par. [0160]) Interpretation: unique identifier corresponds to transaction identifier, which helps to identify a transaction, and is included, or generated, as part of the transaction, and to generate postings for the digital coin balance for the distributed ledger (Par. [0165] & [0170]) Interpretation: the balance is calculated and posted, or reflected, on the ledger account);
submitting, by the ledger interoperability service, the request and the unique identifier to the gateway communication service, wherein the request is secured using public key encryption; (Kilgore, Par. [0162]) Interpretation: the contract code which includes the request and the transaction identifier is submitted, or proceeded, as part of the “on-chain” transaction.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhos in view of Castinado by including generating postings to the distributed ledger and to the payor digital coin wallet and to the beneficiary wallet as taught by Kilgore because generating postings to the distributed ledger helps to improve the system by keeping the transactional information confidential and private (Kilgore, par. [0087]) . Therefore, the claimed invention is obvious in view of the cited references.
The independent claim 21 is disclosed as follows: Bhos teaches: a non-transitory computer readable storage medium, including instructions stored thereon, which when read and executed by one or more computer processors, cause the one or more computer processors to perform steps comprising: receiving, at a ledger interoperability service and from a gateway communication service, a request to deposit a digital coin balance for an amount of funds for a client to a client digital coin wallet on a distributed ledger (Col. 10 ln 4-12, “The network interface 300 includes program logic and/or components that facilitate connection of the provider computing system 104 to the network 116. Accordingly, the network interface 300 supports communication between the provider computing system 104 and other components of the system 100, such as the customer device 102, the partner provider computing system 106, the issuer computing system 108, and the one or more distributed ledger computing systems 110 . . .” (note: network interface corresponds to gateway communication service) & Col. 8 ln 2-6 “. . . the mobile wallet application 206 may facilitate the customer in making a transfer from a payment account (e.g., a demand deposit account) held by the customer to the customer's mobile wallet . . .”) Interpretation: the cited portion discloses depositing funds to a wallet account operated as part of the distributed ledger, wherein the ledger interoperability service is configured to transfer balances between a standard deposit account operating ledger for a financial institution and the distributed ledger (“. . . FIG. 4 illustrates a block diagram depicting a currency exchange using multiple customer accounts, according to an example embodiment. At 350, the customer holds an account 356 in U.S. dollars. At 352, the customer has initiated a currency exchange from dollars to Euros. As such, the currency exchange circuit 306 sets up a new account 358 for the customer in Euros (e.g., because this is the first time the customer has made an exchange to Euros). At 354, the customer's U.S. dollars account 356 is debited $100.00, and the customer's Euros account 358 is credited €86.73 (e.g., at an exchange rate of 0.8673). The customer may now make payments, transfers, and/or exchanges from the Euros account 358 using the currency that has been received in the exchange . . .” & “. . . . In various embodiments, the system 100 includes the issuer computing system 108 as part of a distributed ledger currency rail used for currency transfers. The issuer computing system 108 is associated with an issuer, which serves as a neutral third party in a currency transfer between the provider computing system 104 and the partner provider computing system 106 . . .”) Interpretation: the cited portion discloses transferring balance between a standard account to an account on a distributed ledger using currency rail;
receiving, at an omnibus account on the standard deposit account operating ledger, a transfer of the funds from a client demand deposit account on the standard deposit account operating ledger for the client (Col. 19 ln 56-Col. 20 ln 5; Examiner’s Interpretation: the cited portion discloses concept of requesting a transfer from the payor to a general account recorded on the distributed ledger & Col. 19 ln 44-55) The amount is debited from the payor’s account and credited on the ledger account;
and receiving, by the ledger interoperability service, confirmation from gateway communication service of writing the digital coin balance to the client digital coin wallet (Bhos, Col. 20 ln 1-21 “. . .In some arrangements, the provider computing system 104 uses the general ledger to determine an amount of fiat currency to transfer to the issuer computing system 108, which creates a corresponding amount of digital tokens in the omnibus account on the distributed ledger. In other arrangements, recording the credit to the general ledger directly results in the creation of a corresponding amount of digital tokens in the omnibus account (e.g., such that the issuer computing system 108 may not be needed or play a lesser role in the system 100) . At 1006, the provider computing system 104 communicates with the partner provider computing system 106 regarding the currency transfer. As an example, the provider computing system 104 sends the partner provider computing system 106 a secure message (e.g., through an existing communication channel or through a communication channel for the distributed ledger currency rail), with the secure message identifying the recipient and the transfer amount. The secure message may further identify the account of the recipient that the currency transfer should be provided to (e.g., based on information provided by the customer, based on preset preferences by the recipient, etc.”) Interpretation: under BRI, the general ledger created, or confirmed, the digital coin balance in the ledger and such balance is used to transfer to the recipient account;
and orchestrating, by the ledger interoperability service, the postings to the client demand deposit account and the client digital coin wallet using the gateway communication service (Bhos, Col. 14 ln 62- Col. 15 ln 15) the system operates the posting between the accounts on the distributed ledgers.
Bhos does not disclose the following; however, Castinado teaches:
identifying, by the ledger interoperability service, an address on the distributed ledger for the client digital coin wallet using an address book (Castinado, see at least par. [0049] “. . . In general, as described in greater detail below, the customer 101 initiates a P2P payment using an alias by communicating an alias 117 and an associated payment amount to the financial institution. The financial institution then accesses an alias database, or other type of data repository, to determine if the entered alias 117 has been registered by the alias holder and is, thereby, associated with a particular financial institution account . . .”; Interpretation: beneficiary name corresponds to alias and is associated with a financial account), comprising a mapping of registered clients to distributed ledger addresses on the distributed ledger for digital coin wallets (Castinado, see at least par. [0043] “. . . retrieve an alias-to-entity mapping from the accessed distributed ledger, wherein the alias-to-entity mapping indicates at least an entity to which the alias is mapped . . .” & see at least par. [0184] “. . . nodes 1300 must validate the authenticity of the alias before the transaction may be approved. A specific example would be a customer having an alias of “customer@email.com” that requests a P2P transaction using the block chain distributed network. This alias may be linked (i.e., mapped) to BANK1 on the distributed ledger on the block chain. The alias may also be linked (i.e., mapped) to ACCOUNT1 maintained at BANK1. The mapping of the alias to ACCOUNT1 is a contained on a private register held by BANK1. . . .” & par. [0190]) Interpretation: the alias is an address which used to link to Bank1 on the distributed ledger on the blockchain. The alias may be linked to Account 1 and also linked to a digital coin wallet (which in turn is associated with an account).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhos by including identifying a beneficiary digital coin wallet distributed ledger address for a beneficiary digital coin wallet for the beneficiary name and/or beneficiary account number on a distributed ledger as taught by Castinado, because using an alias to identify payment account helps to improve a P2P payment (Castinado, par. [0049]) . Therefore, the claimed invention is obvious in view of the cited references.
Bhos in view Castinado does not disclose the following; however, Kilgore teaches:
generating, by the ledger interoperability service, a unique identifier that is mapped to a request to issue the digital coin balance to the address on the distributed ledger for the client digital coin wallet on the distributed ledger (Kilgore, par. [0160]) Interpretation: unique identifier corresponds to transaction identifier, which helps to identify a transaction, and is included, or generated, as part of the transaction (Par. [0165] & [0170]) Interpretation: the balance is calculated and posted, or reflected, on the ledger account);
submitting, by the ledger interoperability service, the request and the unique identifier to the gateway communication service, wherein the request is secured using public key encryption; (Kilgore, Par. [0162]) Interpretation: the contract code which includes the request and the transaction identifier is submitted, or proceeded, as part of the “on-chain” transaction.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhos in view of Castinado by including generating postings to the distributed ledger and to the payor digital coin wallet and to the beneficiary wallet as taught by Kilgore because generating postings to the distributed ledger helps to improve the system by keeping the transactional information confidential and private (Kilgore, par. [0087]) . Therefore, the claimed invention is obvious in view of the cited references.
The independent claim 26 is disclosed: Bhos teaches: a system, comprising: a distributed ledger comprising a plurality of digital coin wallet and a gateway communication service; a core banking platform comprising a standard deposit account operating ledger; and a ledger interoperability service in communication with the distributed ledger and the core banking platform (Bhos, Col. 3 ln 57 – Col. 4 ln 12) The cited portion discloses core banking platform for mobile wallet account transfer which is recorded on a distributed ledger, wherein the ledger interoperability service is configured to transfer balances between the standard deposit account operating ledger for a financial institution and the distributed ledger and comprises an address book comprising a mapping of addresses on the distributed ledger for registered clients to distributed ledger addresses on the distributed ledger for digital coin wallets (Col. 10 ln 4-12, “The network interface 300 includes program logic and/or components that facilitate connection of the provider computing system 104 to the network 116. Accordingly, the network interface 300 supports communication between the provider computing system 104 and other components of the system 100, such as the customer device 102, the partner provider computing system 106, the issuer computing system 108, and the one or more distributed ledger computing systems 110 . . .” (note: network interface corresponds to gateway communication service) & Col. 8 ln 2-6 “. . . the mobile wallet application 206 may facilitate the customer in making a transfer from a payment account (e.g., a demand deposit account) held by the customer to the customer's mobile wallet . . .”) Interpretation: the cited portion discloses transferring funds to a wallet account operated as part of the distributed ledger; wherein: the ledger interoperability service receives, from the gateway communication service, a request to deposit a digital coin balance for an amount of funds for a client to a client digital coin wallet on the distributed ledger (“. . . FIG. 4 illustrates a block diagram depicting a currency exchange using multiple customer accounts, according to an example embodiment. At 350, the customer holds an account 356 in U.S. dollars. At 352, the customer has initiated a currency exchange from dollars to Euros. As such, the currency exchange circuit 306 sets up a new account 358 for the customer in Euros (e.g., because this is the first time the customer has made an exchange to Euros). At 354, the customer's U.S. dollars account 356 is debited $100.00, and the customer's Euros account 358 is credited €86.73 (e.g., at an exchange rate of 0.8673). The customer may now make payments, transfers, and/or exchanges from the Euros account 358 using the currency that has been received in the exchange . . .” & “. . . . In various embodiments, the system 100 includes the issuer computing system 108 as part of a distributed ledger currency rail used for currency transfers. The issuer computing system 108 is associated with an issuer, which serves as a neutral third party in a currency transfer between the provider computing system 104 and the partner provider computing system 106 . . .”) Interpretation: the cited portion discloses transferring balance between a standard account to an account on a distributed ledger using currency rail;
an omnibus account on the standard deposit account operating ledger receives a transfer of the funds from a client demand deposit account on the standard deposit account operating ledger for the client (Col. 19 ln 56-Col. 20 ln 5; Examiner’s Interpretation: the cited portion discloses concept of requesting a transfer from the payor to a general account recorded on the distributed ledger & Col. 19 ln 44-55) The amount is debited from the payor’s account and credited on the ledger account;
the ledger interoperability service receives confirmation from gateway communication service of writing the digital coin balance to the client digital coin wallet (Bhos, Col. 20 ln 1-21 “. . .In some arrangements, the provider computing system 104 uses the general ledger to determine an amount of fiat currency to transfer to the issuer computing system 108, which creates a corresponding amount of digital tokens in the omnibus account on the distributed ledger. In other arrangements, recording the credit to the general ledger directly results in the creation of a corresponding amount of digital tokens in the omnibus account (e.g., such that the issuer computing system 108 may not be needed or play a lesser role in the system 100) . At 1006, the provider computing system 104 communicates with the partner provider computing system 106 regarding the currency transfer. As an example, the provider computing system 104 sends the partner provider computing system 106 a secure message (e.g., through an existing communication channel or through a communication channel for the distributed ledger currency rail), with the secure message identifying the recipient and the transfer amount. The secure message may further identify the account of the recipient that the currency transfer should be provided to (e.g., based on information provided by the customer, based on preset preferences by the recipient, etc.”) Interpretation: under BRI, the general ledger created, or confirmed, the digital coin balance in the ledger and such balance is used to transfer to the recipient account;
and the ledger interoperability service orchestrates the postings to the client demand deposit account and the client digital coin wallet using the gateway communication service. (Bhos, Col. 14 ln 62- Col. 15 ln 15) the system operates the posting between the accounts on the distributed ledgers.
Bhos does not disclose the following; however, Castinado teaches:
the ledger interoperability service identifies an address on the distributed ledger for the client digital coin wallet using the address book (Castinado, see at least par. [0049] “. . . In general, as described in greater detail below, the customer 101 initiates a P2P payment using an alias by communicating an alias 117 and an associated payment amount to the financial institution. The financial institution then accesses an alias database, or other type of data repository, to determine if the entered alias 117 has been registered by the alias holder and is, thereby, associated with a particular financial institution account . . .”; Interpretation: beneficiary name corresponds to alias and is associated with a financial account), comprising a mapping of registered clients to distributed ledger addresses on the distributed ledger for digital coin wallets (Castinado, see at least par. [0043] “. . . retrieve an alias-to-entity mapping from the accessed distributed ledger, wherein the alias-to-entity mapping indicates at least an entity to which the alias is mapped . . .” & see at least par. [0184] “. . . nodes 1300 must validate the authenticity of the alias before the transaction may be approved. A specific example would be a customer having an alias of “customer@email.com” that requests a P2P transaction using the block chain distributed network. This alias may be linked (i.e., mapped) to BANK1 on the distributed ledger on the block chain. The alias may also be linked (i.e., mapped) to ACCOUNT1 maintained at BANK1. The mapping of the alias to ACCOUNT1 is a contained on a private register held by BANK1. . . .” & par. [0190]) Interpretation: the alias is an address which used to link to Bank1 on the distributed ledger on the blockchain. The alias may be linked to Account 1 and also linked to a digital coin wallet (which in turn is associated with an account).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhos by including identifying a beneficiary digital coin wallet distributed ledger address for a beneficiary digital coin wallet for the beneficiary name and/or beneficiary account number on a distributed ledger as taught by Castinado, because using an alias to identify payment account helps to improve a P2P payment (Castinado, par. [0049]) . Therefore, the claimed invention is obvious in view of the cited references.
Bhos in view Castinado does not disclose the following; however, Kilgore teaches:
the ledger interoperability service generates a unique identifier that is mapped to a request to issue the digital coin balance to the address on the distributed ledger for the client digital coin wallet on the distributed ledger and to generate postings for the digital coin balance for the distributed ledger (Kilgore, par. [0160]) Interpretation: unique identifier corresponds to transaction identifier, which helps to identify a transaction, and is included, or generated, as part of the transaction (Par. [0165] & [0170]) Interpretation: the balance is calculated and posted, or reflected, on the ledger account);
the ledger interoperability service submits the request and the unique identifier to the gateway communication service (Kilgore, Par. [0162]) Interpretation: the contract code which includes the request and the transaction identifier is submitted, or proceeded, as part of the “on-chain” transaction.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhos in view of Castinado by including generating postings to the distributed ledger and to the payor digital coin wallet and to the beneficiary wallet as taught by Kilgore because generating postings to the distributed ledger helps to improve the system by keeping the transactional information confidential and private (Kilgore, par. [0087]) . Therefore, the claimed invention is obvious in view of the cited references.
Dependent claim 4, 23, 28 are grouped together. Claim 4, for instance, is disclosed by: Bhos in view of Castinado in further view of Kilgore teaches the method of claim 1. Bhos, however, further teaches: further comprising: digitally signing, by the ledger interoperability service, the request to the gateway communication service to issue the digital coin balance to the client digital coin wallet and to generate postings for the digital coin balance for the distributed ledger (Bhos, Col. 16 ln 45-53) The cited portion discloses digital signing the request to perform coin transfer and posting.
Dependent claim 5, 24, 29 are grouped together. Claim 5, for instance, disclosed by: Bhos in view of Castinado in further view of Kilgore teaches the method of claim 1. Bhos, however, further teaches: wherein the request to the gateway communication service to issue the digital coin balance to the client digital coin wallet and to generate postings for the digital coin balance for the distributed ledger comprises an identifier for the client on the distributed ledger, the address for the client digital coin wallet, and the amount of digital coins to be deposited to the client digital coin wallet (Bhos, see at least Col. 19 ln 21-41 “. . . The customer also inputs the amount of the currency the customer would like to transfer from the customer's mobile wallet and/or the amount of currency the customer would like the recipient to receive. Further, in certain embodiments, the customer also inputs one or more types of currency the customer would like the transfer to be exchanged into. As an example, the customer may identify the recipient by inputting an account token for the recipient (e.g., the recipient's email address or phone number) into the mobile wallet application 206. In some embodiments, the provider computing system 104 identifies the recipient and the partner provider via a global registry that maps recipient account tokens to recipients and their financial institutions (e.g., the partner provider).”) .
Dependent claim 6, 25 and 30 are grouped together. Claim 6, for instance, is disclosed by: Bhos in view of Castinado in further view of Kilgore teaches the method of claim 1. Kilgore, however, further teaches: wherein the request to the gateway communication service to issue the digital coin balance to the client digital coin wallet and to generate postings for the digital coin balance for the distributed ledger comprises an application programmable interface call (Kilgore, Par. [0086]) Interpretation: posting of the requested transaction is generated and added to the blockchain.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bhos in view of Castinado in further view of Kilgore by including generating postings to the distributed ledger and to the payor digital coin wallet and to the beneficiary wallet as taught by Kilgore because generating postings to the distributed ledger helps to improve the system by keeping the transactional information confidential and private. Therefore, the claimed invention is obvious in view of the cited references.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOAN DUC BUI whose telephone number is (571)272-0833. The examiner can normally be reached M-F 8-5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO suppl