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 .
Continuation Application
This Application is a continuation of US Application No. PCT/IB2023/059344 filed on 09/23/2023. See MPEP § 201.07. In accordance with MPEP § 609.02 (II)(A)(2) and MPEP § 2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also, in accordance with MPEP § 2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) is/are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicant(s) desires the information to be printed on a patent issuing from this application. See MPEP § 609.02 (II)(A)(2).
Acknowledgements
This Office Action is in response to the amendment received on 09/15/2025.
Claims 1-14, 16-20 and 30 were amended.
Claims 15 and 21-29 were canceled.
Claims 1-14, 16-20 and 30 are pending.
Claims 1-14, 16-20 and 30 were examined.
Information Disclosure Statement
The Information Disclosure Statement filed 09/19/2025 was considered. An initialed copy of the Form PTO-1449 is enclosed herewith.
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-14, 16-20 and 30 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 43-45 58-60 of copending Application No. 18/963,448 and claims 1-24 of copending Application No. 19/239,915 (reference applications). Although the claims at issue are not identical, they are not patentably distinct from each other because they present minimal preamble language modifications and/or recitation of the transmission of a (same) transaction from either the source or the destination (i.e. “executing a sent transaction” vs. “executing a receive transaction”).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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, 2, 6, 12, 16 and 17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
According to MPEP 2106 II, It is essential that the broadest reasonable interpretation (BRI) of the claim be established prior to examining a claim for eligibility. Further, MPEP 2103 I C establishes that the subject matter of a properly construed claim is defined by the terms that limit the scope of the claim when given their broadest reasonable interpretation. It is this subject matter that must be examined. Regarding the independent claims, claim 1 is a method claim and recites “the remote initiator being the holder of a biometrically enabled security device”, language directed to not positively recited method steps.
In the instant case, claims 1-14 are directed to a method, claims 16-20 are directed to a system, and claim 30 are directed to a media. Therefore, these claims fall within the four statutory categories of invention.
Specifically, the language of the claims that recite an abstract idea are marked in bold below:
a. “receiving an encrypted initiate send transaction message from a remote initiator, the remote initiator being the holder of a biometrically enabled security device”;b. “receiving an encrypted authorize/verify send transaction message from a remote authorizer”;c. “executing a sent transaction in accordance with the encrypted initiate send transaction message”; andd. “completing the send transaction on the blockchain custody system.”
Therefore, the portions highlighted in bold above recite transaction processing, which is an abstract idea grouped within the certain methods of organizing human activity and mental processes grouping of abstract ideas in prong one of step 2A of the Alice/Mayo two-part test (see MPEP 2106.04). The claims are grouped within certain methods of organizing human activity because the steps recited describe the commercial or legal interaction of processing information through a clearing-house. Additionally, the claims are also grouped within mental processes because the steps recited describe collecting information, analyzing it, and displaying certain results of the collection and analysis, which is a concept that can be performed in the human mind or by pen and paper. In situations like this where a series of steps recite judicial exceptions, examiners should combine all recited judicial exceptions and treat the claim as containing a single judicial exception for purposes of further eligibility analysis. See MPEP 2106.04 and 2106.05(II). Thus, the language identified in the certain methods of organizing human activity and mental processes groupings were considered as a single abstract idea. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. Specifically, with respect to using at least one processor, one or more non-transitory computer readable media to perform the recited steps/functions, these additional elements performs the steps or functions such as: “receiving… message… ”, “receiving… message….”, “executing… transaction…”, “completing… transaction…”. These additional elements are recited at a high-level of generality such that it represents no more than mere instructions to apply the exception using a generic computer component, which only serves to use computers as a tool to perform the abstract idea. Therefore, these elements do not integrate the abstract idea into a practical application because they require no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional element(s) of a biometrically enabled security device; a blockchain custody system amount to generally linking the use of the judicial exception to a particular technological environment or field of use. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, following the analysis of step 2A, prong two, the claims are still directed to an abstract idea.
With respect to step 2B of the analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the claims recite additional computer elements, such as at least one processor, one or more non-transitory computer readable media, a biometrically enabled security device; a blockchain custody system. The at least one processor, one or more non-transitory computer readable media perform the steps/functions of “receiving… message… ”, “receiving… message….”, “executing… transaction…”, “completing… transaction…”, and amount 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 beyond the abstract idea of transaction processing. The additional element(s) of a biometrically enabled security device; a blockchain custody system amount to generally linking the use of the judicial exception to a particular technological environment or field of use. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions that correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of transaction processing. Therefore, the claims are not eligible.
Dependent claims 2-14 and 17-20 further recite the following additional language, in which elements which merely further define the identified abstract idea are marked in bold below:
e) further comprising: prior to the receiving an encrypted initiate send transaction message from a remote initiator, initiating, by a remote initiator, the asset send transaction. f) in which the step of initiating the asset send transaction by a remote initiator includes: logging into, via a remote initiator, a custody system; selecting, via a remote initiator, an organization from a list of organizations to which the remote initiator has access; selecting, via a remote initiator, an account from a list of accounts to which the remote initiator has access of the selected organization; selecting, via a remote initiator a wallet from a list of wallets to which the remote initiator has access of the selected accounts to which the remote initiator has access; selecting, via a remote initiator an asset from a list of assets to which the remote initiator has access of the selected wallets to which the remote initiator has access; presenting, to a remote initiator with a balance and any other relevant information of the selected asset; entering, via a remote initiator device, the relevant information required to which the selected asset should be transferred including, a destination address and an amount/value; and confirming and /or authorizing, via a remote initiator the asset send transaction. g) in which the step of initiating the asset send transaction includes the step of displaying customizable fields to a remote initiator. h) in which the step of entering a destination address to which the selected asset should be transferred includes entering the destination address manually; scanning the destination address which is presented in the form of a unique visual code, such as a QR code; selecting the destination address from a pre-populated list of destination addresses. i) in which the step of initiating the asset send transaction includes the additional step of displaying a transaction fee and any other fees after the remote initiator entered an amount of the selected asset that should be transferred. j) in which the step of initiating the asset send transaction includes the additional step of entering custom field values. k) which includes, prior to receiving an encrypted authorize/verify send transaction message from a remote authorizer the step, by at least one remote authorizer, of authorizing the asset send transaction. l) in which the step of authorizing the asset send transaction includes a remote authorizer logs into a custody system; a remote authorizer selects an organization from a list of organizations to which the remote authorizer has access; a remote authorizer selects a pending send transaction from a list of pending send transactions; a remote authorizer views details of the selected pending send transaction; and a remote authorizer then confirms/authorizes the send transaction. m) in which the step of authorizing the asset send transaction includes the additional step of displaying custom field values to the remote authorizer. n) in which the step of authorizing the asset send transaction includes the step of entering custom field values. o) in which the step of executing a sent transaction in accordance with the encrypted initiate send transaction message includes the blockchain custody system receives the encrypted initiate send transaction; the blockchain custody system receives the encrypted authorize verify send transaction messages; the blockchain custody system checks the send transaction against policy rules and predefined values; the blockchain custody system then sends the encrypted messages to an asset owner's biometrically enabled security device (being hosted on a security module in the blockchain custody system); the blockchain custody system receives the signed blockchain transaction from the asset owner's biometrically enabled security device; and the blockchain custody system sends the signed blockchain transaction to remote processors to be mined. p) in which the step of executing a send transaction includes the intermediary steps, between the sending of the encrypted messages to the initiator's biometrically enabled security device and the receiving of the signed blockchain transaction from the asset owner's biometrically enabled security device, of the owner's biometrically enabled security device authenticates and validates the initiator's encrypted message and other encrypted messages and checks the send transaction against policy rules and predefined values; and the owner's biometrically enabled security device signing the blockchain transaction using the encrypted messages. q) in which the step of completing the send transaction on the blockchain custody system in the method of initiating an asset send transaction includes the following sequential steps: monitoring the blockchain transaction being sent for mining until the required threshold number of transaction confirmations have been met; and marking the send transaction as complete once the required number of transaction confirmations has been met.
Examiner notes that, for elements recited in the dependent claims which were previously analyzed as additional elements of the independent claims above (i.e. at least one processor, one or more non-transitory computer readable media), the assessment of these elements under step 2A and step 2B for the dependent claims is inherited from the analysis of the independent claims and omitted for brevity, unless noted by Examiner below.
With respect to the eligibility analysis of claims 2 and 17, the claims recite item e) above, which represents the additional elements/functions of initiating a transaction. This language further elaborates the abstract idea of transaction processing identified in the analysis of independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 6, the claim recites item i) above, which represents the additional elements/functions of displaying fees. This language further elaborates the abstract idea of transaction processing identified in the analysis of independent claim 1. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 12, the claim recites item o) above. This language further elaborates the abstract idea of transaction processing identified in the analysis of independent claim 1. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims. Examiner notes claim 12 does not present additional positively recited method steps.
With respect to the eligibility analysis of claim 13, the claim recites item p) above, which represents the additional elements/functions of signing a transaction. This language further elaborates the abstract idea of transaction processing identified in the analysis of independent claim 1. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 14, the claim recites item q) above, which represents the additional elements/functions of monitoring transactions and marking a transaction as complete, as part of the completing step. This language further elaborates the abstract idea of transaction processing identified in the analysis of independent claim 1. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
Therefore, while the additional language e), i), o)- q) of dependent claims 2, 6, 12-14 and 17 slightly modify the analysis provided with respect to independent claims 1 and 16, these additional elements/functions are insufficient to render the dependent claims eligible, as detailed above. Therefore, these dependent claims are also ineligible.
With respect to claims 3, 18 and 30, the claims are directed to item f) above, which represents the additional elements/functions of details of actions performed via a remote initiator. This language further elaborates the abstract idea of transaction processing identified in the analysis of independent claims 1, 16 and 30. The additional elements/functions integrate the abstract idea into a practical application by applying the judicial exception in some other meaningful way.
Therefore, the additional language f)-h) and j)-n) of dependent claims 3- 5, 7-11, 18-20 significantly alter the analysis provided with respect to independent claims 1 and 16. This language is also recited by independent claim 30. These additional elements/functions are sufficient to render the dependent claims eligible, as detailed above. Therefore, dependent claims 3- 5, 7-11, 18, 19, 20 and independent claim 30 are eligible due to the language found in claims 1/2/3 and 16/17/18.
Claim Rejections - 35 USC § 112
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-14, 16-20 and 30 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 16 recite the language “the send transaction ” in lines 9 and 16, respectively. There is insufficient antecedent basis for this language in the claims since it is unclear which “a send transaction message and a sent transaction” the claims are referring to (Claims 1 and 16 introduce “a send transaction message and a sent transaction” more than once, in multiple lines). See MPEP 2173.05(e): “… if two different levers are recited earlier in the claim, the recitation of “said lever” in the same or subsequent claim would be unclear where it is uncertain which of the two levers was intended”. Dependent claims 2-14, 17-20 and 30 are also rejected since they depend on claims 1 and 16, respectively. For purposes of Examination, “the send transaction” is being interpreted as inheriting antecedent basis from “a sent transaction”.
Claims 2 and 17 recite the language “the asset send transaction” in lines 4 and 3, respectively. There is insufficient antecedent basis for this language in the claims. Dependent claims 3-14, 17-20 and 30 are also rejected since they depend on claims 2 and 17, respectively.
Claims 3, 6 and 18 recite the language “the remote initiator” in multiple lines. There is insufficient antecedent basis for this language in the claims since it is unclear which “a remote initiator” the claims are referring to (Claims 1-3 and 16-18 introduce “a remote initiator” more than once, in multiple lines). See MPEP 2173.05(e): “… if two different levers are recited earlier in the claim, the recitation of “said lever” in the same or subsequent claim would be unclear where it is uncertain which of the two levers was intended”. Dependent claims 4-14, 19, 20 and 30 are also rejected since they depend on claims 3 and 18, respectively.
Claim 5 recites “in which the step of entering a destination address to which the selected asset should be transferred includes entering the destination address manually; scanning the destination address which is presented in the form of a unique visual code, such as a QR code; selecting the destination address from a pre-populated list of destination addresses.”. This language is unclear as the claims lack a conjunction "and" or "or". Therefore, it is unclear whether the claim is directed to a sequence of steps or alternatives for entering a destination address.. For purposes of examination, Examiner considers the language as alternative, since the three instances refer to "entering a destination address" in distinct ways. Dependent claims 7-11 are also rejected since they depend on claim 5.
Claims 9 and 10 recite the language “the remote authorizer” in lines 6 and 3. There is insufficient antecedent basis for this language in the claims since it is unclear which “a remote authorizer / at least one remote authorizer” the claims are referring to (Claims 1, 8 and 9 introduce “a remote authorizer / at least one remote authorizer” more than once, in multiple lines). See MPEP 2173.05(e): “… if two different levers are recited earlier in the claim, the recitation of “said lever” in the same or subsequent claim would be unclear where it is uncertain which of the two levers was intended”. Dependent claim 10 is also rejected since it depends on claim 9.
Claim 11 recites “the step of entering custom field values” in line 2. There is insufficient antecedent basis for this language in the claim.
Claims 12 and 13 recite the language “ the encrypted messages ” in line 9. There is insufficient antecedent basis for this language in the claims since it is unclear which “the encrypted… transaction, the encrypted authorized and verify send transaction messages” the claims are referring to (Claim 12 introduces “the encrypted… transaction, the encrypted authorized and verify send transaction messages” more than once, in multiple lines). See MPEP 2173.05(e): “… if two different levers are recited earlier in the claim, the recitation of “said lever” in the same or subsequent claim would be unclear where it is uncertain which of the two levers was intended”. Dependent claim 13 is also rejected since it depends on claim 12.
Claim 12-14 recite “the signed blockchain transaction / the blockchain transaction” in multiple lines. There is insufficient antecedent basis for this language in the claim. Dependent claim 13 is also rejected since it depends on claim 12.
Claim 13 recites “the initiator's encrypted message and other encrypted messages” in multiple lines. There is insufficient antecedent basis for this language in the claim.
Claim 14 recites “the required threshold / the required number of transaction confirmations”. There is insufficient antecedent basis for this language in the claim.
Claim 14 recites “the required threshold / the required number of transaction confirmations”. There is insufficient antecedent basis for this language in the claim.
Claims 16-20 are indefinite because it is unclear to one of ordinary skill in the art whether Applicants are claiming the subcombination of a “system comprising: at least one processor; and one or more non-transitory computer readable media (BRI: a processor and a non-transitory media)” or the combination of a “system comprising: at least one processor; and one or more non-transitory computer readable media (BRI: a processor and a non-transitory media)” and a “remote initiator”. If it is Applicants’ intent to claim only the subcombination, the body of the claims must be amended to remove any positive recitation of the combination. If it is Applicants’ intent to claim the combination, the preamble of the claim must be amended to be consistent with the language in the body of the claim. For purposes of Examination, Examiner is considering the scope set by the preamble of the claims Dependent claims 17-20 and 30 are also rejected since they depend on claim 16.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-13, 16-20 and 30 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Kang et al. (US 2018/0204195 A1), in view of Sheehan et al. (US 2017/0046697 A1) and in view of Monica et al. (US 2020/0266997 A1).
With respect to claims 1, 16 and 30, Kang et al. teach a system comprising: at least one processor; and one or more non-transitory computer readable media in operative communication with the at least one processor; one or more non-transitory computer readable media (see FIGS. 9, 10, and 11, multi-payment gateway, paragraph [0113]: “FIGS. 9, 10, and 11 show payment transaction systems according to the present invention that incorporate a customer initiated mobile terminal (CIMT) portal 600. The CIMT portal 600 may include one or more servers that facilitate payment from a mobile device 200 to a merchant 300 through multiple payment methods. The CIMT portal 600 may be alternatively described as a multi-payment gateway); and a method of initiating an asset send transaction in a blockchain custody system (System and method for customer initiated payment transaction using customer's mobile device and card) comprising:
receiving an... initiate send transaction message from a remote initiator, the remote initiator being the holder of a biometrically enabled security device (see Fig. 10, paragraph [0114], "...the digital wallet sending the payment authorization request to the CIMT portal 600..."; paragraph [0078]: “The mobile device 10 may be a cellular phone, mobile phone, smart phone, tablet computing device, personal digital assistant (PDA), or the like. Here, the mobile device 10 also includes the application installed therein to implement the system of the present invention.”; paragraph [0131]: “It is to be understood that a password as used throughout this disclosure may include an alphanumeric password of a predetermined length, but may be an additional or alternative form of security, such as a fingerprint scan or facial recognition feature.”);
executing a sent transaction in accordance with the... initiate send transaction message; and (see Fig. 10, paragraph [0114]: “...the digital wallet sending the payment authorization request to the CIMT portal 600; the CIMT portal 600 communicating to the merchant 300 a result of a payment transaction..”); and
completing the send transaction on the blockchain custody system (see Fig. 10, paragraph [0114]: “... the digital wallet receiving a result of the payment authorization request from the CIMT 600. As shown in FIG. 10, the CIMT portal may communicate with a payment vendor 400. Examples of a payment vendor 400 include credit card vendors, a bank, cryptocurrency such as Bitcoin, loyalty points issuer, gift card issuer, and the like.”).
Kang et al. do not explicitly disclose a method, system and media comprising: receiving an encrypted authorize/verify send transaction message from a remote authorizer; the initiate send transaction message encrypted.
However, Sheehan et al. disclose a method, system and media (Payment approval platform) comprising:
receiving an... authorize/verify send transaction message from a remote authorizer (see paragraph [0066]: “In such e-commerce embodiments, the platform may receive, from a requestor, a request for a purchase, where the request comprises request details associated with the purchase and a link associated with an online merchant. Next, the platform may provide the request to a decision maker associated with the requestor. In some embodiments, the request provided to the decision maker may comprise the link. Then, the platform may receive an approval of the request from the decision maker. Subsequently, the platform may enable a processing of a transaction”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the three-tier authorization as disclosed by Sheehan et al. in the method, system and media of Kang et al., the motivation being to enable a “purchasing party” to remotely request and receive approval for A transaction from a “decision maker party” (see Sheehan et al., paragraph [0044]).
The combination of Kang et al. and Sheehan et al. does not explicitly disclose a method, system and media comprising: the initiate send transaction and authorize/verify send transaction messages are encrypted.
However, Monica et al. disclose a method, system and media (Cryptoasset custodial system with different cryptographic keys controlling access to separate groups of private keys) comprising:
the (initiate send transaction and authorize/verify send transaction) messages are encrypted (see paragraph [0005]: “One or more aspects of the subject matter described in this specification can be embodied in one or more methods that include receiving a request to take an action in a cryptoasset custodial system; identifying for the action an associated private-keys group out of multiple different private-keys groups managed by the cryptoasset custodial system, wherein each of the multiple different private-keys groups has an associated cryptographic group key; decrypting, at a first computer, a first level of encryption of a private key associated with the action using the associated cryptographic group key for the associated private-keys group out of the multiple different private-keys groups managed by the cryptoasset custodial system; decrypting, at a second computer that is distinct from the first computer, a second level of encryption of the private key associated with the action using a hardware-based cryptographic key used by the second computer; using, at the second computer, the private key associated with the action in a process of digitally signing data to authorize the action; and sending the digitally signed data to a third computer to effect the action.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the multiple hardware security modules and double encryption mechanisms as disclosed by Monica et al. in the method, system and media of Kang et al. and Sheehan et al., the motivation being to improving security, reducing damage from a breach of security in a cryptoasset custodial system and facilitates moving protected information from one group to another within the cryptoasset custodial system, allowing the groupings to be readily changed as system requirements evolve over time (see Monica et al., paragraph [0004]).
With respect to the BRI of the claims, Examiner notes that claim 1 is a method claim and recites “the remote initiator being the holder of a biometrically enabled security device”, language directed to a not positively recited method step. In the system claims, this language is insufficient to alter the function of “receiving an encrypted initiate send transaction message, as the description of “the initiator” does not alter the claimed function (i.e. the encrypted message is not even required to be sent by “a biometrically enabled security device” held by the initiator).
With respect to claims 2, 17 and 30, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method, system and media as described above with respect to claims 1, 16 and 16. Furthermore, Kang et al. disclose a method, system and media further comprising: prior to the receiving an encrypted initiate send transaction message from a remote initiator, initiating, by a remote initiator, the asset send transaction (see Fig. 10, paragraph [0114]: “As shown in FIG. 10, the system for customer initiated payment transactions may include a payment transaction process including steps of: a customer launching a digital wallet on a mobile device 200; ; paragraph [0095]: “The mobile device 20 may receive the merchant information from the merchant by: wireless communication from the merchant; tapping the mobile device 20 to an NFC tag or RFID tag of the merchant which stores the merchant information; or typing the merchant information to the mobile device 20 either by the customer or the merchant. Additionally, SMS, beacon, infrared communication may be used. Alternatively, the merchant may use QR code or bar code to store and transmit the merchant information.”).
The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 3, 18 and 30, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method, system and media as described above with respect to claims 2, 17 and 17. Furthermore, Kang et al. disclose a method, system and media in which
the step of initiating the asset send transaction by a remote initiator includes: logging into, via a remote initiator, a custody system (see Fig. 27, login, paragraph [0141]: “FIG. 27 is a diagram showing an overview of processes for using a payment transaction application, such as a digital wallet, in a customer mode according to the present invention. As a customer, the digital wallet provides the options of: login, register payment method, settings, payment, and view history”);
selecting, via a remote initiator, an organization from a list of organizations to which the remote initiator has access (see Fig. 10, paragraph [0114]: “As shown in FIG. 10, the system for customer initiated payment transactions may include a payment transaction process including steps of: ...the digital wallet receiving merchant information and payment information of a merchant 300..."; paragraph [0133]: “FIG. 21 shows exemplary screens on a digital wallet of a customer's mobile device 200 during a process for an offline payment authorization using the mobile phone 200 according to the present invention. First, a global positioning system (GPS) sensor of the mobile phone may be activated to detect the customer's location. The digital wallet may display a list of merchants 300 that are in close vicinity of the customer. As a way of example, in FIG. 21, the digital wallet suggests “CU Yeouido Branch” and “Good Pharmacy” as possible merchants based on the customer's location....");
selecting, via a remote initiator, an account from a list of accounts to which the remote initiator has access of the selected organization (see paragraph [0119]: “A digital wallet of the mobile device 200 may facilitate payment by a plurality of payment means. In FIG. 12, a digital wallet is designated as an “A-Wallet.” The A-Wallet may be registered by multiple payment methods. The multiple payment methods may include a credit card having an NFC chip for NFC payments. Another payment method may be an IOC, which enables payment via a Bluetooth network. An MFD card 100 having multiple payment cards as described above may also be registered to be used by the A-Wallet. Additionally, an over-the-air (OTA) card issued by a trusted server manager (TSM) may be registered on the A-Wallet. Other virtual cards, such as those associated with a loyalty point program or a mileage program may be registered to the A-Wallet. As shown in FIG. 12, the mobile device 200 having the A-Wallet communicates with the multi-payment gateway (MPG) 600 during a payment transaction. Advantageously, the system of the present invention allows for payment transaction using various technologies”);
selecting, via a remote initiator a wallet from a list of wallets to which the remote initiator has access of the selected accounts to which the remote initiator has access (see paragraph [0139]: “An advantageous feature of the system having the multi-payment gateway 600 is that the customer may select a plurality of different payment options to make a payment. For example, FIG. 24 shows a payment method selection screen according to the present invention, wherein a purchase may be split into payments from mileage points, cryptocurrency, a gift card, and a credit card. Such purchases may be paid from different percentages of various payment accounts. Such a payment option is facilitated by the multi-payment gateway 600”);
selecting, via a remote initiator an asset from a list of assets to which the remote initiator has access of the selected wallets to which the remote initiator has access (see paragraph [0120]: “Additionally, a variety of payment currencies may be used in the system. Such currencies include but are not limited to conventional currencies, cryptocurrency, and loyalty points. For credit card payments, the MPG 600 may authorize payment to a merchant 300 by communication with a EMV Terminal Server. For cryptocurrency and loyalty points payments, the MPG 600 may communicate with an appropriate acquirer, such as a cryptocurrency issuer. Additionally, such an acquirer may communicate with the EMV terminal server.”; paragraph [0121]: “Cryptocurrency may include Bitcoin or another cryptocurrency. FIG. 13 shows a system for a payment transaction using Bitcoin according to the present invention. It is to be understood that another form of cryptocurrency may be alternatively or additionally used in the present invention.”);
presenting, to a remote initiator with a balance and any other relevant information of the selected asset (see paragraph [0067]: “FIG. 26 is an image showing an exemplary screen for viewing account balances for multiple payment options according to the present invention”);
entering, via a remote initiator device, the relevant information required to which the selected asset should be transferred including, a destination address and an amount/value (see Fig. 13, paragraph [0122]: “As illustrated in FIG. 13, after receiving payment information and merchant information from the merchant POS device 350, the digital wallet of the mobile device 200 of the customer may send a cryptocurrency payment request to the MPG 600 using a public cryptographic address of the MPG 600. The value of the cryptocurrency may be calculated by an exchange rate at the time of the payment and cryptocurrency used for payment may be exchanged to a currency accepted by the merchant. If the MPG 600 has a pre-existing contract for payment with the merchant, the MPG 600 may facilitate the payment directly with the merchant 300. If the merchant 300 does not have such a contract, the MPG 600 may request payment to a credit card company 400 or a bank having a payment method accepted by the merchant 300, which in turn may communicate the payment transaction with the merchant 300. Accordingly, cryptocurrency may be used by the customer for a payment, but the merchant 300 may receive a currency that is not cryptocurrency.”; Fig. 25, paragraph [0139]: “An advantageous feature of the system having the multi-payment gateway 600 is that the customer may select a plurality of different payment options to make a payment. For example, FIG. 24 shows a payment method selection screen according to the present invention, wherein a purchase may be split into payments from mileage points, cryptocurrency, a gift card, and a credit card. Such purchases may be paid from different percentages of various payment accounts. Such a payment option is facilitated by the multi-payment gateway 600”); and
confirming and /or authorizing, via a remote initiator the asset send transaction (see Fig. 15, paragraph [0125]: “... Finally, the digital wallet may display a receipt screen of payment completion and send a message to the merchant...").
The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 4 and 19, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method and system as described above with respect to claims 3 and 18. Furthermore, Kang et al. disclose a method and system in which the step of initiating the asset send transaction includes the step of displaying customizable fields to a remote initiator (see Payment amount input field, paragraph [0125]: “In the process illustrated in FIG. 15, the customer may select a product for purchase. Upon launching the digital wallet, A-Wallet, on a mobile device 200, the customer may receive merchant information by scanning the merchant QR code or by NFC. The customer may then input a payment amount and a payment method...").
The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 5, 20 and 30, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method, system and media as described above with respect to claims 3 and 18. Furthermore, Kang et al. disclose a method, system and media in which
the step of entering a destination address to which the selected asset should be transferred includes entering the destination address manually; scanning the destination address which is presented in the form of a unique visual code, such as a QR code; selecting the destination address from a pre-populated list of destination addresses (see Fig. 24, paragraph [0133]: "...Merchant information may also be scanned in using a merchant information QR code. Additionally, or alternatively, merchant information may be received by the digital wallet of the customer's mobile device 200 by another communication network such as NFC or Wi-Fi.”).
The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 6, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method as described above with respect to claim 2. Furthermore, Kang et al. disclose a method in which the step of initiating the asset send transaction includes the additional step of displaying a transaction fee and any other fees after the remote initiator entered an amount of the selected asset that should be transferred (see paragraph [0146]: “FIG. 29 is a diagram showing processes for using a payment transaction application in a multi-payment gateway (MPG) mode. As shown in FIG. 29 and described above, the multi-payment gateway plays a central role in the various embodiments of the present invention. The multi-payment gateway may sign up merchants and set fees for merchants, payment methods, and various credit card companies. Additionally, the multi-payment gateway may view transaction history and provide the information for the transaction history viewed by the merchant and various payment entities, such as credit card companies, cryptocurrency issuers, mileage points companies, and gift card companies.”;).
The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 7, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method as described above with respect to claim 5. Furthermore, Kang et al. disclose a method in which the step of initiating the asset send transaction includes the additional step of entering custom field values (see Payment amount input, paragraph [0125]: “In the process illustrated in FIG. 15, the customer may select a product for purchase. Upon launching the digital wallet, A-Wallet, on a mobile device 200, the customer may receive merchant information by scanning the merchant QR code or by NFC. The customer may then input a payment amount and a payment method...").
The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 8, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method as described above with respect to claim 7. Furthermore, Kang et al. disclose a method which includes, prior to receiving an encrypted authorize/verify send transaction message from a remote authorizer the step, by at least one remote authorizer, of authorizing the asset send transaction (see paragraph [0130]: “FIG. 19 shows a process for a purchase on a mobile shopping platform according to the present invention. In a mobile shopping mall, the customer may select a product for purchase. The customer may then launch a digital wallet, A-Wallet, on the mobile device and select a payment transaction method, such as a credit card, Bitcoin, or mileage points. Other payment methods may be used. The digital wallet may optionally request a password for authorizing the payment transaction. Finally, the digital wallet may display a result screen and notify the merchant 300 of the payment completion.”; paragraph [0131]: “It is to be understood that a password as used throughout this disclosure may include an alphanumeric password of a predetermined length, but may be an additional or alternative form of security, such as a fingerprint scan or facial recognition feature.”).
The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 9, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method as described above with respect to claim 8. Furthermore, Sheehan et al. disclose a method in which
the step of authorizing the asset send transaction includes a remote authorizer logs into a custody system; a remote authorizer selects an organization from a list of organizations to which the remote authorizer has access; a remote authorizer selects a pending send transaction from a list of pending send transactions; a remote authorizer views details of the selected pending send transaction; and a remote authorizer then confirms/authorizes the send transaction (see paragraph [0010]: “A platform for providing a three-tier authorization may be provided. The platform may receive a requestor login from a requestor including requestor access credentials, as well as a purchase request. The platform may provide a first level of authentication upon authenticating the requestor access credentials. The platform may further receive decision maker access credentials and provide a second authentication by receiving approval of the purchase request and authenticating the decision maker access credentials. The platform may further receive payment details and authenticate the payment details to authorize the payment, providing a third authorization. Upon the first, second and third authorization, the platform may enable a transaction.”; paragraph [0048]: “The platform may then notify the parent (e.g., decision maker party associated with the purchasing party) of the desired purchase pending approval including the details of the desired purchase. Notification may be received by the parent through, for example, but not limited to, a similar mobile phone based application associated with the platform. The platform may then enable the parent to, for example, approve, reject approval, or modify the purchase request (e.g., reduce the amount available for spending) and then approve the desired purchase. The platform may further require decision maker account authentication, for example, by requiring the decision maker to log in. A login may be performed, for example, by requiring a username, password, biometric indicator (e.g., fingerprint scan), confirmation via a mobile phone or device associated with the decision maker, or various other methods for authenticating decision maker identity.”; paragraph [0049]: “Upon receiving approval from the decision maker, a transaction may be executed by the requestor..." ).
Regarding the BRI of the claim, Examiner notes that claim 9 is a method claim and recites “a remote authorizer selects…...”“a remote authorizer views…...”; “a remote authorizer then confirms/authorizes…...” , language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 10, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method as described above with respect to claim 9. Furthermore, Sheehan et al. disclose a method in which the step of authorizing the asset send transaction includes the additional step of displaying custom field values to the remote authorizer (see edit the desired purchase request information, paragraph [0078]: "...The decision maker may receive purchase request information 605 corresponding to information received from the requestor's input prompts 310. The decision maker may receive a selection of response options 610, such as, for example, accept, reject, call requestor, and message requestor. The platform may further enable the user to edit the desired purchase request information, or provide further purchase limits (e.g., a spending limit, credit limit, account balance, day, time and location). In addition, the platform may enable the user to request to be notified at a later time.”;).
The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 11, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method as described above with respect to claim 9. Furthermore, Sheehan et al. disclose a method in which the step of authorizing the asset send transaction includes the step of entering custom field values (see edit the desired purchase request information, paragraph [0078]: "...The decision maker may receive purchase request information 605 corresponding to information received from the requestor's input prompts 310. The decision maker may receive a selection of response options 610, such as, for example, accept, reject, call requestor, and message requestor. The platform may further enable the user to edit the desired purchase request information, or provide further purchase limits (e.g., a spending limit, credit limit, account balance, day, time and location). In addition, the platform may enable the user to request to be notified at a later time.”;).
The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 12, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Monica et al. disclose a method in which
the step of executing a sent transaction in accordance with the encrypted initiate send transaction message includes the blockchain custody system receives the encrypted initiate send transaction (see Fig. 5B, 501, paragraph [0081]: “An example of the withdrawal process is further shown in FIG. 5B. The online server 2 initially receives 501 the withdrawal request 31 from the customer…");
the blockchain custody system receives the encrypted authorize verify send transaction messages (see Fig. 5B, 501, paragraph [0081]: “An example of the withdrawal process is further shown in FIG. 5B. The online server 2 initially receives 501 the withdrawal request 31 from the customer…");
the blockchain custody system checks the send transaction against policy rules and predefined values (see Fig. 5B, 502, paragraph [0081]: “...The online server 2 then checks 502 the approval policy for the cryptoasset that is the subject of the transaction, as indicated in the vault of the cryptoasset, to determine which individuals' authorizations (endorsements) may be used to satisfy a quorum to approve the withdrawal…");
the blockchain custody system then sends the encrypted messages to an asset owner's biometrically enabled security device (being hosted on a security module in the blockchain custody system) (see Fig. 5B, 503, paragraph [0081]: "...The online server 2 then sends 503 endorsement requests to the mobile devices 8A, 8B of those individuals (the mobile devices have been previously registered with the CCS 1)…"; paragraph [0080]: “During this process users are required to review the transaction and approve it, where each user's approval is subject to biometric authentication (e.g., fingerprint, facial recognition and/or voice recognition)...");
the blockchain custody system receives the signed blockchain transaction from the asset owner's biometrically enabled security device (see Fig. 5B, 504, paragraph [0081]: "In response to these requests, one or more endorsement messages may be received from users' mobile devices 8A, 8B, where the endorsement messages were signed locally by the users' respective private keys stored securely in their respective mobile devices and subjected to one or more biometric authentication technique.."); and
the blockchain custody system sends the signed blockchain transaction to remote processors to be mined (see Fig. 5B, 508 and 509,paragraph [0082]: “The risk analysis stage 4 performs a risk analysis 506, which as noted above may be fully or partially automated, or in some embodiments may be performed entirely by one or more human beings (based on computer output data). If the transaction passes risk analysis 506, then control flow is passed to the HSM 5, which verifies 508 that the quorum requirement has been satisfied, by performing the same determination as determination 504 or a similar determination, as does the risk analysis 506 (described further below). If satisfaction of the quorum is verified by the HSM 5, the HSM signs the withdrawal transaction with the private key of the blockchain address and submits the transaction onto the blockchain 11 to execute the withdrawal 509”).
Regarding the BRI of the claim, Examiner notes that claim 12 is a method claim and recites “the blockchain custody system sends/receives...”“the blockchain custody system checks...”; “the blockchain custody system then sends…...”; , language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 13, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method as described above with respect to claim 12. Furthermore, Monica et al. disclose a method in which the step of executing a send transaction includes the intermediary steps, between the sending of the encrypted messages to the initiator's biometrically enabled security device and the receiving of the signed blockchain transaction from the asset owner's biometrically enabled security device, of the owner's biometrically enabled security device authenticates and validates the initiator's encrypted message and other encrypted messages and checks the send transaction against policy rules and predefined values (see paragraph [0083]: “As mentioned above, when a user endorses a transaction request, they are subjected to one or more forms of authentication by their mobile device and/or the CCS 1, to establish that they are the expected person taking the action. These authentication forms may include one or more biometric authentication techniques, such as fingerprint verification, voiceprint verification, speech recognition, facial recognition and/or gesture recognition. The user's mobile device (e.g., smartphone) may perform one or more of these authentication techniques”; paragraph [0084]: “Additionally, or alternatively, the user may be required to upload to the CCS 1 a video, captured by their mobile device, from which their identity can be proven by, for example: identifying the user's face in the video against images of known faces (e.g., previous videos of the user); identifying the user's voice in the video against their trained voice profile; requiring the user to say certain words or take certain actions in the video based on the transaction (see further discussion below); requiring the user to make a previously specified gesture, or a distress gesture if they are in distress; requiring the user to identify on video the expected room they are in; and/or other performing any other actions that are considered to increase the level of confidence that the user is who he or she purports to be.”; paragraph [0085]: “When determined to be necessary, a user may be asked to complete challenges to authenticate that he or she is in fact the person who is authorized to act on the transaction. These challenges may be generated deterministically based on the context of the transaction. For example, based on critical information in a transaction such as the ID, amount, destination, etc., the CCS 1 may generate a random number that can be used to select a few (e.g., three to five) words from a set of known words. The CCS 1 may present those words to the user and have the user speak them in a video captured by the user's mobile device, which the user's mobile device then transmits to the CCS 1. When reviewing the transaction, the reviewing mechanism or a human reviewer can independently generate the expected words based on transaction data and verify that the user spoke those words. The video can also be subject to facial and/or voice recognition. By performing this type of deterministic challenge generation, an attacker can be prevented from faking a transaction by capturing and reusing previously transmitted authentication videos from the user.”); and
the owner's biometrically enabled security device signing the blockchain transaction using the encrypted messages (see paragraph [0086]: “The main role of the HSM 5 is to verify the validity of operations. The HSM 5 carries out the will of the signers and authenticates that the signers are the authorized parties of an operation through the HSM's privileged access to keys. Keys needed for signing transactions can be stored securely in the HSM 5 and never leave it. In some embodiments, the HSM 5 enforces these policies through a Secure Execution Environment (SEE) that runs code that cannot be changed except through physical access to the HSM 5 and requires a set of smartcards held securely by multiple employees of the Cryptoasset Custodian.”;).
Regarding the BRI of the claim, Examiner notes that claim 13 is a method claim and recites “the owner's biometrically enabled security device authenticates and validates the initiator's encrypted message and other encrypted messages and checks the send transaction against policy rules and predefined values…...”, language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Kang et al. (US 2018/0204195 A1), in view of Sheehan et al. (US 2017/0046697 A1), in view of Monica et al. (US 2020/0266997 A1), and in further view of Rhie et al. (US 2018/0293583 A1).
With respect to claim 14, the combination of Kang et al., Sheehan et al. and Monica et al. teaches all the subject matter of the method as described above with respect to claim 1. The combination of Kang et al., Sheehan et al. and Monica et al. does not explicitly teach a method in which the step of completing the send transaction on the blockchain custody system in the method of initiating an asset send transaction includes the following sequential steps: monitoring the blockchain transaction being sent for mining until the required threshold number of transaction confirmations have been met; and marking the send transaction as complete once the required number of transaction confirmations has been met.
However, Rhie et al. discloses a method (Method for calculating confirmation reliability for blockchain based transaction and blockchain network monitoring system for performing the method) in which
the step of completing the send transaction on the blockchain custody system in the method of initiating an asset send transaction includes the following sequential steps: monitoring the blockchain transaction being sent for mining until the required threshold number of transaction confirmations have been met (see Fig. 7, monitoring unit 110, paragraph [0067]: “Looking at each constituent element, the monitoring unit 110 acquires in real time the monitoring information of the blockchain data of each blockchain node constituting the blockchain network. At this time, the monitoring information may include information on the branch formed on the blockchain data.”); and
marking the send transaction as complete once the required number of transaction confirmations has been met (see paragraph [0069]: “The transaction confirmation reliability confirmation unit 150 adjusts or confirms the transaction confirmation reliability predicted by the transaction confirmation reliability prediction unit 130 on the basis of information on the branch at the second timing provided by the monitoring unit 110. That is, the transaction confirmation reliability confirmation unit 150 compares the predicted value whether a branch occurs with the actual observation information at the second timing, on the basis of information on the branch at the first timing, thereby adjusting or confirming the predicted transaction confirmation reliability....”; Fig. 13, paragraph [0103]: “When the predicted value of the transaction confirmation reliability is “100%” and the branch does not occurred as predicted, since the predicted value is accurate, the transaction confirmation reliability calculating apparatus 100 confirms the transaction confirmation reliability as in the predicted value (S530, S570)”; ).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the financial transaction confirmation reliability as disclosed by Rhie et al. in the method of Kang et al., Sheehan et al. and Monica et al., the motivation being to enabling prediction as to whether or not to change the block position of the transaction data according to the branch formed on the blockchain data (see Rhie et al., paragraph [0010]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Parker et al. (US 2023/0325815 A1) disclose non-custodial, recoverable wallet that stores private key amongst multiple secure storage mechanisms, including a self-custodial, yet recoverable wallet—recovery via 2FA and biometrics..
Kurani et al. (US 2023/0410089 A1) disclose instant wallet credit card, including dynamically updating, by the mobile device, the mobile wallet interface responsive to determining that the user interaction is a user selection of a second payment vehicle.
Gaddam et al. (US 2021/0027283 A1) disclose federated custodian, including a federated interaction system that includes one or more members that utilize a blockchain network to authenticate and authorize transactions.
Corcillo et al. (US 2024/0013172 A1) disclose blockchain supported resource transfer communication protocol, including digital wallets configurable to support a variety of functionalities. Digital wallets, for instance, support secure encrypted storage for verifiable credentials.
Greco et al. (US 2019/0034923 A1) disclose secure and confidential custodial transaction system, method and device using zero-knowledge protocol, including enforcing business rules of the system by requesting zero-knowledge proofs from participants to the transaction (e.g. sender and recipient) in place of actual data for the transaction.
Williams et al. (US 2024/0037515 A1) disclose graphical user interface and card system for engaging in cryptocurrency transactions, including a graphical user interface including an option for linking one or more digital wallets to an account.
Ridenour et al. (US 2022/0230239 A1) disclose special purpose systems, including customizable rules for different cryptocurrencies and operating state information that initialize containerized lending applications.
Torkelson et al. (US 2019/0260788 A1) disclose transient transaction server, including improved techniques for protecting transactions, and the data accessed by such transactions, against attacks.
Stollman et al. (US 2022/0277261 A1) disclose systems and methods to ensure asset and supply chain integrity, including using encryption technology to register assets that are to be transferred and whose chain of custody is to be ensured.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698
Prosecution Insights