DETAILED CORRESPONDENCE
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Application
Claims 1-18 have been examined in the application. This communication is the first action on the merits.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on November 14, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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-18 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.
Claims 1-18 are directed to the abstract idea of: Claim 1 -: 1. An implemented method for use in enhanced transactions, the method comprising: receiving, by a processing, a request for a fund transfer from mobile, in lieu of a request from a financial institution, the fund transfer between a source account and a destination account, mobile associated with one of a sender user and a receiver user, the request including an amount of the fund transfer and a credential associated with the destination account; identifying, by the processing, an acquiring credential of a financial institution that issued the source account; transmitting, by the processing, an authorization request for the fund transfer to the financial institution, whereby the financial institution approves the fund transfer; and based on the approval from the financial institution, initiating the fund transfer between the source account and the destination account. (fundamental economic principles or practices, commercial or legal interactions, managing personal behavior or relationships or interactions between people, concepts performed in the human mind, (including an observation, evaluation, judgment, opinion). ) Claim 2 -: 2. The implemented method of claim 1, wherein the financial institution is an issuer of the source account to the sender user. Claim 3 -: 3. The implemented method of claim 2, further comprising: transmitting an approval from the financial institution to mobile; and receiving a fund transfer instruction, in response to the approval, from mobile; and wherein initiating the fund transfer includes initiating the fund transfer in response to the fund transfer instruction. Claim 4 -: 4. The implemented method of claim 1, wherein the credential associated with the destination account includes a proxy; and further comprising resolving, by the processing, the proxy into an account number, prior to initiating the fund transfer. Claim 5 -: 5. The implemented method of claim 1, wherein the destination account is issued by a financial institution in a foreign country; and wherein initiating the fund transfer includes initiating the fund transfer from the source account to an intermediate financial institution in the foreign country, whereby the intermediate financial institution initiates the fund transfer to the destination account. (fundamental economic principles or practices, commercial or legal interactions, managing personal behavior or relationships or interactions between people, concepts performed in the human mind, (including an observation, evaluation, judgment, opinion). ) Claim 6 -: 6. for use in enhanced transactions, comprising a processing configured to: receive a request for a fund transfer from mobile, in lieu of a request from a financial institution, the fund transfer between a source account and a destination account, mobile associated with one of a sender user and a receiver user, the request including an amount of the fund transfer and a credential associated with the destination account; identify an acquiring credential of a financial institution that issued the source account; transmit an authorization request for the fund transfer to the financial institution, whereby the financial institution approves the fund transfer; and based on the approval from the financial institution, initiate the fund transfer between the source account and the destination account. (fundamental economic principles or practices, commercial or legal interactions, managing personal behavior or relationships or interactions between people, concepts performed in the human mind, (including an observation, evaluation, judgment, opinion). ) Claim 7 -: 7. The of claim 6, wherein the financial... [id. at 2], Claim 8 -: 8. The of claim 6, wherein the credential... [id. at 4], wherein the processing is further configured to resolve the proxy into an account number, prior to transmitting the authorization request for the fund transfer to the financial institution. Claim 9 -: 9. The implemented method of claim 6, wherein the destination... [id. at 5], wherein the processing is configured, in order to initiate the fund transfer, to initiate the fund transfer from the source account to an intermediate financial institution in the foreign country, whereby the intermediate financial institution initiates the fund transfer to the destination account. (fundamental economic principles or practices, commercial or legal interactions, managing personal behavior or relationships or interactions between people, concepts performed in the human mind, (including an observation, evaluation, judgment, opinion). ) Claim 10 -: 10. An implemented method for use in facilitating a contactless transaction, the method comprising: soliciting, by mobile specific to a sender user, details of a person-to-person (P2P) fund transfer, the details including a name of a receiver user and an amount of the P2P fund transfer; receiving, at mobile, the details of the P2P fund transfer; prompting, by mobile, a contactless for the receiver user to be presented at mobile, whereby one of the sender user and the receiver user presents the contactless receiver user to mobile; in response to the contactless being presented at mobile, contactlessly capturing, by mobile, a credential specific to a receiver account from the contactless receiver user; validating, by mobile, with an issuer of the receiver account, the name of the receiver user included in the details of the P2P fund transfer; and in response to the name being valid, initiating, by mobile, through a payment service provider (PSP), a request for the P2P fund transfer from a source account to the receiver account based on the credential. (fundamental economic principles or practices, commercial or legal interactions, managing personal behavior or relationships or interactions between people, concepts performed in the human mind, (including an observation, evaluation, judgment, opinion). ) Claim 11 -: 11. The implemented method of claim 10, wherein receiving the details of the P2P fund transfer includes receiving, at an input of mobile, manual entry at a pad- entry of the name and the amount. Claim 12 -: 12. The implemented method of claim 10, wherein the credential from the contactless receiver user includes a deposit only credential for the receiver account, the credential including an account number. Claim 13 -: 13. The implemented method of claim 10, further comprising soliciting and receiving, by mobile, a selection of a source account of the sender user for the P2P fund transfer; and wherein the request for the P2P fund transfer includes an account number specific to the source account. Claim 14 -: 14. The implemented method of claim 10, further comprising: compiling- and transmitting, by the PSP, an authorization request specific to the P2P fund transfer to a financial institution, which issued the sender account; reviving, by the PSP, an authorization reply from the financial institution; and returning, by the PSP, a confirmation of the P2P fund transfer being complete. Claim 15 -: 15. The implemented method of claim 10, further comprising determining, by mobile, eligibility of the receiver account to receive the P2P fund transfer; and wherein initiating the fund transfer is further in response to determining the receiver account is eligible for the P2P fund transfer. Claim 16 -: 16. The implemented method of claim 10, wherein the contactless is a contactless card-. Claim 17 -: 17. The implemented method of claim 16, wherein the contactless card- is a, passive enabled card-, consistent with the standard. Claim 18 -: 18. The implemented method of claim 10, wherein the contactless is a enabled tag-. (fundamental economic principles or practices, commercial or legal interactions, managing personal behavior or relationships or interactions between people, concepts performed in the human mind, (including an observation, evaluation, judgment, opinion). ) . The identified limitation(s) falls within the subject matter groupings of abstract ideas enumerated in Section I of the 2019 Revised Patent Subject Matter Eligibility Guidance: b) Certain methods of organizing human activity – fundamental economic principles or practices, commercial or legal interactions, managing personal behavior or relationships or interactions between people, c) Mental processes – concepts performed in the human mind, (including an observation, evaluation, judgment, opinion).
These limitation excerpts, under their broadest reasonable interpretation, fall within the grouping(s) of abstract ideas of: Certain methods of organizing human activity – since: systems and methods provided for use in enhanced network transactions; including receiving, by a processing network, a request for a fund transfer from a mobile device, in lieu of a request from a financial institution, the fund transfer between a source account and a destination account, the mobile device associated with one of a sender user and a receiver user, the request including an amount of the fund transfer and a credential associated with the destination account; identifying, by the processing network, an acquiring credential of a financial institution that issued the source account; transmitting, by the processing network, an authorization request for the fund transfer to the financial institution, whereby the financial institution approves the fund transfer; and based on the approval from the financial institution, initiating the fund transfer between the source account and the destination account as recited in the claim limitations, under their broadest reasonable interpretation, covers performance of the limitation(s) as fundamental economic principles or practices, (including hedging, insurance, mitigating risk); commercial or legal interactions, (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions). Mental processes – since: the above-underlined as recited in the claim limitations, under their broadest reasonable interpretation, covers performance of the limitation(s) as concepts performed in the human mind, (including an observation, evaluation, judgment, opinion). Therefore, the limitations fall within the above-identified grouping(s) of abstract ideas.
While independent claims 1, 6, and 10 do not explicitly recite verbatim this identified abstract idea, the concept of this identified abstract idea is described by the steps of independent claim 1 and is described by the steps of independent claim 6 and is described by the steps of independent claim 10.
Claim 1: Specifically with respect to the analysis under Step 2A of the Office's § 101 Subject Matter Eligibility Test for Products and Processes, independent claim 1 further to the abstract idea includes additional elements of "computer-", "network", and "device". However, independent claim 1 does not include additional elements that are sufficient to integrate the exception into a practical application because "computer-", "network", and "device" of independent claim 1 recite generic computer and/or field of use components pertaining to the particular technological environment that are recited a high-level of generality that perform functions ("A computer-implemented method for use … transactions, the method comprising", "receiving, by a processing network, … with the destination account", "identifying, by the processing network, … issued the source account", "transmitting, by the processing network, … the fund transfer; and" and "based on the approval from … and the destination account") that merely perform, conduct, carry out, implement, and/or narrow the abstract idea itself (e.g. all or portion(s) of the noted recited steps) and/or that recite generic computer and/or field of use functions that are recited at a high-level of generality that include only steps narrowing the abstract idea [Step 2A Prong I] (e.g. all or portion(s) of the noted recited steps) and/or because the additional method steps comprise or include: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, [Step 2A Prong II] adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea -- see MPEP 2106.05(f) (all or portions of the noted step(s)), and adding insignificant extra-solution activity to the judicial exception -- see MPEP 2106.05(g) (all or portions of the "receiving, by a processing network, … with the destination account", "transmitting, by the processing network, … the fund transfer; and" step(s)), and generally linking the use of the judicial exception to a particular technological environment or field of use -- see MPEP 2106.05(h) (all or portions of the "A computer-implemented method for use … transactions, the method comprising", "receiving, by a processing network, … with the destination account", "identifying, by the processing network, … issued the source account", "transmitting, by the processing network, … the fund transfer; and" step(s)). Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the additional elements do not amount to more than a recitation of the words "apply it" (or an equivalent) or are not more than mere instructions to implement an abstract idea or other exception on a computer, and the additional elements do not add more than insignificant extra-solution activity to the judicial exception, and the additional elements do not amount to more than generally linking the use of a judicial exception to a particular technological environment or field of use. Furthermore, the additional method steps comprise or include: reciting additional elements in implementing the abstract idea that do not constitute significantly more than the abstract idea because they comprise or include well-understood, routine, and conventional activities previously known to the industry (e.g. all or portion(s) of the "receiving, by a processing network, … with the destination account", "transmitting, by the processing network, … the fund transfer; and", (insignificant extra-solution activity) steps), see Alice Corp., 134 S. Ct. at 2360, and/or that are otherwise not significant toward constituting any inventive concept beyond the abstract idea. (E.g. The above-italicized grounds of rejection apply at least to all or portion(s) of the noted recited steps.) For example regarding well-understood, routine, and conventional activities, the cited rationale have recognized the following computer function as well-understood, routine, and conventional functions when it is claimed or as insignificant extra-solution activity: receiving or transmitting data over a network, e.g., using the Internet to gather data, Intellectual Ventures I v. Symantec Corp., 838 F.3d at 1321, 120 USPQ2d at 1362 (2016) (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); and the cited rationale have found the following type of activity to be well-understood, routine, and conventional activity when it is claimed or as insignificant extra-solution activity: recording a customer's order, Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1244, 120 USPQ2d 1844, 1856 (Fed. Cir. 2016), and identifying undeliverable mail items, decoding data on those mail items, and creating output data, Return Mail, Inc. v. U.S. Postal Service, -- F.3d --, -- USPQ2d --, slip op. at 32 (Fed. Cir. August 28, 2017). None of the additional elements taken individually or when taken as an ordered combination amount to significantly more than the abstract idea. Accordingly, independent claim 1 is ineligible.
Claim 6: Specifically regarding the analysis under Step 2A of the Office's § 101 Subject Matter Eligibility Test for Products and Processes, independent claim 6 further to the abstract idea includes additional elements of "system", "network", "computing", and "device". However, independent claim 6 does not include additional elements that are sufficient to integrate the exception into a practical application because "system", "network", "computing", and "device" of independent claim 6 recite generic computer and/or field of use components pertaining to the particular technological environment that are recited a high-level of generality that perform functions ("A system for use in … computing device configured to", "receive a request for a … with the destination account", "identify an acquiring credential of … issued the source account", "transmit an authorization request for … the fund transfer; and" and "based on the approval from … and the destination account") that merely perform, conduct, carry out, implement, and/or narrow the abstract idea itself (e.g. all or portion(s) of the noted recited steps) and/or that recite generic computer and/or field of use functions that are recited at a high-level of generality that include only steps narrowing the abstract idea [Step 2A Prong I] (e.g. all or portion(s) of the noted recited steps) and/or because the additional method steps comprise or include: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, [Step 2A Prong II] adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea -- see MPEP 2106.05(f) (all or portions of the noted step(s)), and adding insignificant extra-solution activity to the judicial exception -- see MPEP 2106.05(g) (all or portions of the "receive a request for a … with the destination account", "transmit an authorization request for … the fund transfer; and" step(s)), and generally linking the use of the judicial exception to a particular technological environment or field of use -- see MPEP 2106.05(h) (all or portions of the "A system for use in … computing device configured to", "receive a request for a … with the destination account", "identify an acquiring credential of … issued the source account", "transmit an authorization request for … the fund transfer; and" step(s)). Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 1 also applies hereto. Additionally, the additional method steps comprise or include: reciting additional elements in implementing the abstract idea that do not constitute significantly more than the abstract idea because they comprise or include well-understood, routine, and conventional activities previously known to the industry (e.g. all or portion(s) of the "receive a request for a … with the destination account", "transmit an authorization request for … the fund transfer; and", (insignificant extra-solution activity) steps), see Alice Corp., 134 S. Ct. at 2360, and/or that are otherwise not significant toward constituting any inventive concept beyond the abstract idea. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) See discussion above regarding Claim 1 for pertinent previously cited rationale finding well-understood, routine, and conventional activities. None of the additional elements taken individually or when taken as an ordered combination amount to significantly more than the abstract idea. Accordingly, independent claim 6 is ineligible.
Claim 10: Particularly pertaining to the analysis under Step 2A of the Office's § 101 Subject Matter Eligibility Test for Products and Processes, independent claim 10 further to the abstract idea includes additional elements of "computer-", "network", "smartphone", "device", "push", and "computing". However, independent claim 10 does not include additional elements that are sufficient to integrate the exception into a practical application because "computer-", "network", "smartphone", "device", "push", and "computing" of independent claim 10 recite generic computer and/or field of use components pertaining to the particular technological environment that are recited a high-level of generality that perform functions ("A computer-implemented method for use … transaction, the method comprising", "soliciting, by a smartphone mobile … push P2P fund transfer", "receiving, at the smartphone mobile … push P2P fund transfer", "prompting, by the smartphone mobile … the smartphone mobile device", "in response to the contactless … of the receiver user", "validating, by the smartphone mobile … P2P fund transfer; and" and "in response to the name … based on the credential") that merely perform, conduct, carry out, implement, and/or narrow the abstract idea itself [Step 2A Prong I] (e.g. all or portion(s) of the noted recited steps) and/or that recite generic computer and/or field of use functions that are recited at a high-level of generality and/or because the additional method steps comprise or include: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, [Step 2A Prong II] adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea -- see MPEP 2106.05(f) (all or portions of the noted step(s)), and generally linking the use of the judicial exception to a particular technological environment or field of use -- see MPEP 2106.05(h) (all or portions of the noted step(s)). Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the additional elements do not amount to more than a recitation of the words "apply it" (or an equivalent) or are not more than mere instructions to implement an abstract idea or other exception on a computer, and the additional elements do not amount to more than generally linking the use of a judicial exception to a particular technological environment or field of use. None of the additional elements taken individually or when taken as an ordered combination amount to significantly more than the abstract idea. Accordingly, independent claim 10 is ineligible.
Independent Claims: Nothing in independent claims 1, 6, and 10 improves another technology or technical field, improves the functioning of any claimed computer device itself, applies the abstract idea with any particular machine, solves any computer problem with a computer solution, or includes any element that may otherwise be considered to amount to significantly more than the abstract idea.
None of the dependent claims 2-5, 7-9, and 11-18 when separately considered with each dependent claim's corresponding parent claim overcomes the above analysis because none presents any method step not directed to the abstract idea that amounts to significantly more than the judicial exception or any physical structure that amounts to significantly more than the judicial exception.
Claim 9: Dependent claim 9 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, "computer-" of dependent claim 9 recite generic computer and/or field of use components pertaining to the particular technological environment that are recited a high-level of generality. No additional element introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea.
Claim 11: Dependent claim 11 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, "key pad" of dependent claim 11 recite generic computer and/or field of use components pertaining to the particular technological environment that are recited a high-level of generality. No additional element introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea.
Claim 14: Dependent claim 14 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, "compiling" of dependent claim 14 recite generic computer and/or field of use components pertaining to the particular technological environment that are recited a high-level of generality. No additional element introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea.
Claim 16: Dependent claim 16 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, "card" of dependent claim 16 recite generic computer and/or field of use components pertaining to the particular technological environment that are recited a high-level of generality. No additional element introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea.
Claim 17: Dependent claim 17 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, "plastic", "NFC-", and "ISO/IEC 7810" of dependent claim 17 recite generic computer and/or field of use components pertaining to the particular technological environment that are recited a high-level of generality. No additional element introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea.
Claim 18: Dependent claim 18 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, "NFC-", and "fob, tag, or sticker" of dependent claim 18 recite generic computer and/or field of use components pertaining to the particular technological environment that are recited a high-level of generality. No additional element introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea.
Claims 2 and 7: Dependent claims 2 and 7 add an additional method step of "wherein the financial institution is an issuer of the source account to the sender user". However, the additional method step of dependent claim 2 and 7 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited step) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited step.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claims 2 and 7 are ineligible.
Claim 3: Dependent claim 3 adds an additional method step of "transmitting an approval from the financial institution to the mobile device; and", "receiving a fund transfer instruction, in response to the approval, from the mobile device; and", "wherein initiating the fund transfer includes initiating the fund transfer in response to the fund transfer instruction". However, the additional method step of dependent claims 3 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 3 is ineligible.
Claim 4: Dependent claim 4 adds an additional method step of "wherein the credential associated with the destination account includes a proxy; and", "further comprising resolving, by the processing network, the proxy into an account number, prior to initiating the fund transfer". However, the additional method step of dependent claims 4 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 4 is ineligible.
Claim 5: Dependent claim 5 adds an additional method step of "wherein the destination account is issued by a financial institution in a foreign country; and", "wherein initiating the fund transfer includes initiating the fund transfer from the source account to … country, whereby the intermediate financial institution initiates the fund transfer to the destination account". However, the additional method step of dependent claims 5 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 5 is ineligible.
Claim 8: Dependent claim 8 adds an additional method step of "wherein the credential associated with the destination account includes a proxy; and", "wherein the processing network computing device is further configured to resolve the proxy into an … prior to transmitting the authorization request for the fund transfer to the financial institution". However, the additional method step of dependent claims 8 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 8 is ineligible.
Claim 9: Dependent claim 9 adds an additional method step of "wherein the destination account is issued by a financial institution in a foreign country; and", "wherein the processing network computing device is configured, in order to initiate the fund transfer, … country, whereby the intermediate financial institution initiates the fund transfer to the destination account". However, the additional method step of dependent claims 9 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 9 is ineligible.
Claim 11: Dependent claim 11 adds additional method steps of "wherein receiving the details of the push P2P fund transfer includes receiving, at an input … device, manual entry at a key pad entry of the name and the amount". However, the additional method steps of dependent claims 11 are directed to the abstract idea noted above and do not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method steps merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrow the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method steps comprise or include: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 11 is ineligible.
Claim 12: Dependent claim 12 adds an additional method step of "wherein the credential from the contactless device of the receiver user includes a deposit only credential for the receiver account, the credential including an account number". However, the additional method step of dependent claims 12 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 12 is ineligible.
Claim 13: Dependent claim 13 adds additional method steps of "further comprising soliciting and receiving, by the smartphone mobile device, a selection of a source account of the sender user for the push P2P fund transfer; and", "wherein the request for the push P2P fund transfer includes an account number specific to the source account". However, the additional method steps of dependent claims 13 are directed to the abstract idea noted above and do not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method steps merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrow the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method steps comprise or include: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 13 is ineligible.
Claim 14: Dependent claim 14 adds additional method steps of "compiling and transmitting, by the PSP computing device, an authorization request specific to the push P2P fund transfer to a financial institution, which issued the sender account", "reviving, by the PSP computing device, an authorization reply from the financial institution; and", "returning, by the PSP computing device, a confirmation of the push P2P fund transfer being complete". However, the additional method steps of dependent claims 14 are directed to the abstract idea noted above and do not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method steps merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrow the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method steps comprise or include: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 14 is ineligible.
Claim 15: Dependent claim 15 adds an additional method step of "determining, by the smartphone mobile device, eligibility of the receiver account to receive the push P2P fund transfer; and", "wherein initiating the fund transfer is further in response to determining the receiver account is eligible for the push P2P fund transfer". However, the additional method step of dependent claims 15 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 15 is ineligible.
Claim 16: Dependent claim 16 adds an additional method step of "wherein the contactless device is a contactless card device". However, the additional method step of dependent claims 16 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited step) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited step.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 16 is ineligible.
Claim 17: Dependent claim 17 adds an additional method step of "wherein the contactless card device is a plastic, passive NFC-enabled card device, consistent with the ISO/IEC 7810 standard". However, the additional method step of dependent claims 17 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 17 is ineligible.
Claim 18: Dependent claim 18 adds an additional method step of "wherein the contactless device is a NFC-enabled fob, tag, or sticker". However, the additional method step of dependent claims 18 is directed to the abstract idea noted above and does not otherwise alter the analysis presented above, and do not integrate the exception into a practical application, because the additional method step merely perform, conduct, carry out, and/or implement the abstract idea itself and/or only narrows the abstract idea (e.g. all or portion(s) of the noted recited steps) and/or because the additional method step comprises or includes: evaluated additional elements individually and in combination for which the courts have identified examples in which a judicial exception has not been integrated into a practical application, as previously discussed regarding Claim 10 above. Regarding Step 2B treatment of the evaluated additional elements individually and in combination, the same previously-stated legal authority and/or rationale supporting the grounds of rejection applied to the above Claim 10 also applies hereto. (E.g. These previously-stated grounds of rejection that were italicized when applied to the referenced previous Claim(s) apply at least to all or portion(s) of the noted recited steps.) No additional step introduced in this claim taken individually or when taken as an ordered combination amounts to significantly more than the abstract idea. Accordingly, dependent claim 18 is ineligible.
PNG
media_image1.png
930
645
media_image1.png
Greyscale
PNG
media_image2.png
200
400
media_image2.png
Greyscale
§101 Subject Matter Eligibility Test for Products and Processes
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
1-st Prior Art Category: Claims 1-4, 6-8, and 10-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication No. US 2023/0385817 A1 of ILINCIC; Rajko et al., (hereinafter "ILINCIC").
Claim 1, EXAMINER's Analysis: Claim 1 is rejected as being anticipated by ILINCIC. Claim 1 is an independent claim. ILINCIC discloses the claimed subject matter of claim 1 as follows and as explained below.
Regarding and as per CLAIM 1, a computer-implemented method for use in enhanced network transactions, the method comprising: Reference (ILINCIC: discloses e.g. "[a] computer-implemented method" Claim 1 and e.g. "[e]mbodiments herein generally relate to mobile computing platforms, and more specifically, to near-field communication (NFC) mobile currency transfers" par. [0002] or "[e]mbodiments disclosed herein provide systems, methods, articles of manufacture, and computer-readable media for NFC mobile currency transfers" par. [0004] and e.g. "enhanced security for the involved devices and the overall financial transaction" par. [0013])
• 1 ¶ 2 • receiving, by a processing network, a request for a fund transfer from a mobile device, in lieu of a request from a financial institution, the fund transfer between a source account and a destination account, the mobile device associated with one of a sender user and a receiver user, the request including an amount of the fund transfer and a credential associated with the destination account; Reference (ILINCIC: discloses e.g. "[s]ending funds from one account to another account" par. [0003] or "server may receive, from the application executing on the first device, an encrypted request to transfer funds from the first account to a second account, the encrypted request generated responsive to the first device coming into communications range with a second device associated with the second account[; t]he server may then decrypt the encrypted request to transfer funds from the first account to the second account, and authorize the request to transfer funds from the first account to the second account" par. [0004] or "request to transfer funds from the first account to the second account" Claims 1, 5, 9, 12, 16, 19 and "a server to process the payment" par. [0011] or "[t]he server 120 is representative of any type of computing device, such as a server, workstation, compute cluster, cloud computing platform, virtualized computing system, and the like" par. [0017] or "the server 120 via the network 130" par. [0024] or "the server 120 to implement key diversification for the contactless card 101[; t]he output of the encryption may be the same diversified key value 106 that was created by the contactless card 101[; t]he management application 123 may then decrypt the encrypted data received via the network 130" par. [0025] and e.g. "[n]FC-based mobile currency transfers[; a] mobile payment may be programmatically initialized when at least two mobile devices come into NFC communications range[; a] payment card associated with an account used to fund the currency transfer may be tapped to one or more of the devices to allow a server to validate the currency transfer" Abstract and e.g. "transactions originating from a mobile device" par. [0083] or "[f]IG. 1B[; i]n such an embodiment, as shown, a contactless card 101 is tapped to mobile device 110-2[; t]he contactless card 101 may belong to the user of mobile device 110-2 (e.g., the payor's contactless card)[; i]n response, the contactless card 101 follows the encryption procedure detailed above with reference to FIG. 1A (e.g., using the master key 105, counter 104, and diversified key 106) to generate encrypted data comprising the customer identifier 107[; t]he contactless card 101 may transmit the generated encrypted data to the mobile device 110-2, which receives the encrypted data via the NFC card reader 118[; o]nce received, the account application 113 of the mobile device 110-2 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; u]pon decrypting the data received from the mobile device" par. [0030] and e.g. "each individual may possess a contactless card, and may be customers of the same issuing financial institution, but it is not necessary[; e]ach of these individuals may receive a push notification on their device, via the application, to split the purchase[; r]ather than accepting only one card tap to indicate payment, other contactless cards may be used[; i]n some examples, individuals who have different financial institutions may possess contactless cards 101 to provide information to initiate one or more payment requests from the card-tapping individual" par. [0093] and e.g. "any of the mobile devices 110-1, 110-2 may initiate the transfer request[; f]or example, the user of mobile device 110-2 may specify to pay the user of mobile device 110-1, and the "tap" of the mobile devices when in NFC communications range provides the account application 113 of mobile device 110-2 with the account information of the user of mobile device 110-1 necessary to submit, approve, and process the transaction" par. [0031] and e.g. "any of the mobile devices 110-1, 110-2 may initiate the transfer request" par. [0031] and e.g. "user of mobile device 110-2 may specify to pay the user of mobile device 110-1" par. [0031] or "user of mobile device 110-2" pars. [0028]-[0031], [0033] and e.g. "user of mobile device 110-1" pars. [0028]-[0032] and e.g. "an application executing on the second mobile device may receive data describing the payment request (e.g., account information, payment amount, etc.) from the application executing on the first mobile device[; t]he second user may then approve the request, which may cause the second mobile device to transmit an indication to a server to process the payment" par. [0011] or "[t]he indication may include at least a receiving account number (e.g., an account number of the user of mobile device 110-1) and the requested amount[; w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029] or "the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 to the management application 123 of the server 120[; t]he account application 113 may further transmit, to the management application 123 of server 120, an indication of the requested payment of funds from the second account to the first account" par. [0074] or "the account application 113 of the first mobile device 110-1 transmits the data received from the contactless card 101 at block 585 to the management application 123 of the server 120[; t]he account application 113 of the first mobile device 110-1 may further include an indication of the requested payment from the second account to the first account" par. [0079] and e.g. "the logic flow 400 begins at block 410, where the account application 113 of the first mobile device 110-1 receives valid authentication credentials for a first user account[; a]s stated, the authentication credentials may include a username/password combination, biometric credentials, or any other type of authentication credentials[; a]t block 420, the account application 113 of the second mobile device 110 receives valid authentication credentials for a second user account[; a]t block 430, the account application 113 of the first mobile device 110-1 generates a request to receive payment from the second account associated with the second mobile device 110-1[; f]or example, the first user may provide input to the account application 113 of the mobile device 110-1 specifying to receive a specified sum (e.g., $50) from the second account of the second user" par. [0072])
• 1 ¶ 3 • identifying, by the processing network, an acquiring credential of a financial institution that issued the source account; Reference (ILINCIC: discloses e.g. "the contactless card 101 to generate encrypted data (e.g., an encrypted customer identifier 107) using the master key 105, counter value 104, and diversified key 106 as described above (e.g., blocks 320-350 of logic flow 300)[; t]he contactless card 101 may then transmit the data (which may include the counter value 104) to the account application 113 of the second mobile device 110-2" par. [0073] and "[a]t block 480, the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 to the management application 123 of the server 120[; t]he account application 113 may further transmit, to the management application 123 of server 120, an indication of the requested payment of funds from the second account to the first account[; a]t block 490, the management application 123 of the server 120 processes the received data to validate the data generated by the contactless card 101 using key diversification (e.g., as described in blocks 360-390 of the logic flow 300)" par. [0074] where "[a]t block 370, the management application 123 decrypts the encrypted data received from the contactless card 101 via the mobile device 110 using the diversified key 106 and a cryptographic algorithm[; d]oing so may yield at least the customer identifier 107[; b]y yielding the customer identifier 107, the management application 123 may validate the data received from the contactless card 101 at block 380[; f]or example, the management application 123 may compare the customer identifier 107 to a customer identifier for the associated account in the account data 124, and validate the data based on a match" par. [0070] and e.g. "[t]he account data 124 includes account-related data for a plurality of users and/or accounts[; t]he account data 124 may include at least a master key 105, counter 104, a customer ID 107, an associated contactless card 101, and biographical information for each account" par. [0020] and "when a contactless card 101 is manufactured, a unique master key 105 may be programmed into the memory 102 of the contactless card 101[; s]imilarly, the unique master key 105 may be stored in a record of a customer associated with the contactless card 101 in the account data 124 of the server 120 (and/or stored in a different secure location)[; t]he master key may be kept secret from all parties other than the contactless card 101 and server 120, thereby enhancing security of the system 100" par. [0021] or "the management application 123 may verify the data transmitted by the contactless card 101 via the mobile device 110 by comparing the decrypted customer ID 107 to a customer ID in the account data 124 for the account, where a match of the customer ID values verifies the data received from the contactless card 101" par. [0025] and "[u]pon decrypting the data received from the mobile device 110-2, the server 120 may compare the customer identifier 107 to an expected customer identifier value (e.g., a customer identifier provided by the account application 113, a customer identifier stored in the account data 124, etc.)[; u]pon verifying the presence of the contactless card 101 associated with the payor's account, the server 120 may approve and process the payment, and transmit an indication of the same to the mobile devices 110-1 and/or 110-2" par. [0030])
• 1 ¶ 4 • transmitting, by the processing network, an authorization request for the fund transfer to the financial institution, whereby the financial institution approves the fund transfer; and Reference (ILINCIC: discloses e.g. "e.g. "[o]nce received, the account application 113 of the mobile device 110-1 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; t]he server 120 may generally compare the decrypted customer identifier 107 to an expected customer identifier value (e.g., the customer identifier 107 received in from device 110-2 in FIG. 1C, etc.) to approve the transaction[; f]urthermore, in at least one embodiment, upon receiving the data from the mobile device 110-1, the server 120 may determine whether an amount of time that has elapsed since the data received from device 110-2 in FIG. 2B exceeds a threshold amount of time (e.g., 30 seconds)[; d]oing so allows the server 120 to ensure that both users are in proximity of each other and the contactless card 101[; t]he server 120 may then approve and process the payment, and transmit an indication of the same to the mobile devices 110-1 and/or 110-2" par. [0033] or "point of sale (POS) systems submit transactions including a transaction value to a card issuer[; w]hether the issuer approves or denies the transaction may be based on if the card issuer recognizes the transaction value[; m]eanwhile, in certain embodiments of the present disclosure, transactions originating from a mobile device lack the transaction value associated with the POS systems[; t]herefore, in some embodiments, a dummy transaction value (i.e., a value recognizable to the card issuer and sufficient to allow activation to occur) may be passed as part of the example authentication communication protocol" par. [0083] and e.g. "[a]t block 370, the management application 123 decrypts the encrypted data received from the contactless card 101 via the mobile device 110 using the diversified key 106 and a cryptographic algorithm[; d]oing so may yield at least the customer identifier 107[; b]y yielding the customer identifier 107, the management application 123 may validate the data received from the contactless card 101 at block 380[; f]or example, the management application 123 may compare the customer identifier 107 to a customer identifier for the associated account in the account data 124, and validate the data based on a match[; a]t block 390, the management application 123 may transmit an indication of the validation (e.g., validation success) to the account application 113 of the mobile device 110" par. [0070])
• 1 ¶ 5 • based on the approval from the financial institution, initiating the fund transfer between the source account and the destination account. Reference (ILINCIC: discloses e.g. "e.g. "[o]nce received, the account application 113 of the mobile device 110-1 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; t]he server 120 may generally compare the decrypted customer identifier 107 to an expected customer identifier value (e.g., the customer identifier 107 received in from device 110-2 in FIG. 1C, etc.) to approve the transaction[; f]urthermore, in at least one embodiment, upon receiving the data from the mobile device 110-1, the server 120 may determine whether an amount of time that has elapsed since the data received from device 110-2 in FIG. 2B exceeds a threshold amount of time (e.g., 30 seconds)[; d]oing so allows the server 120 to ensure that both users are in proximity of each other and the contactless card 101[; t]he server 120 may then approve and process the payment, and transmit an indication of the same to the mobile devices 110-1 and/or 110-2" par. [0033] or "point of sale (POS) systems submit transactions including a transaction value to a card issuer[; w]hether the issuer approves or denies the transaction may be based on if the card issuer recognizes the transaction value[; m]eanwhile, in certain embodiments of the present disclosure, transactions originating from a mobile device lack the transaction value associated with the POS systems[; t]herefore, in some embodiments, a dummy transaction value (i.e., a value recognizable to the card issuer and sufficient to allow activation to occur) may be passed as part of the example authentication communication protocol" par. [0083] and e.g. "the management application 123 of the server 120 authorizes the requested payment and processes the payment of funds from the first account to the second account" par. [0074] or "the management application 123 of the server 120 may then process the transfer of funds from the second account to the first account" par. [0080] or "server 120 may [] approve and process the payment" pars. [0030], [0033])
Claim 2, EXAMINER's Analysis: Claim 2 is rejected as being anticipated by ILINCIC. Claim 2 is a dependent claim that directly depends upon parent claim 1, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 1, ILINCIC discloses the claimed subject matter of claim 2 as follows and as explained below.
Regarding and as per CLAIM 2, the computer-implemented method of claim 1, Reference (ILINCIC: discloses e.g. "[a] computer-implemented method" Claim 1)
• 2 ¶ 2 • wherein the financial institution is an issuer of the source account to the sender user. Reference (ILINCIC: discloses e.g. "each individual may possess a contactless card, and may be customers of the same issuing financial institution, but it is not necessary[; e]ach of these individuals may receive a push notification on their device, via the application, to split the purchase[; r]ather than accepting only one card tap to indicate payment, other contactless cards may be used[; i]n some examples, individuals who have different financial institutions may possess contactless cards 101 to provide information to initiate one or more payment requests from the card-tapping individual" par. [0093] and e.g. "for the contactless card 101, a different unique identifier is derived which may be related to the application primary account number (PAN) and PAN sequence number, which is encoded in the card[; t]he key diversification may be configured to receive the identifier as input with the master key such that one or more keys may be created for each contactless card[; i]n some examples, these diversified keys may comprise a first key and a second key[; t]he first key may include an authentication master key (Card Cryptogram Generation/Authentication Key-Card-Key-Auth)[; t]he second key may comprise an encryption master key (Card Data Encryption Key-Card-Key-DEK)[; t]he first and second keys may be used by the one or more applets 240 to generate session keys that may be used to generate a MAC cryptogram, authenticate the card, and to encipher it, respectively[; i]n some examples, the first and the second keys may be created by diversifying the issuer master keys by combining them with the card's unique ID number (pUID) and the PAN sequence number (PSN) of a payment applet, as specified in EMV key diversion algorithm Option A of EMV 4.3 Book 2 A1.4 Master Key Derivation[; t]he pUID may comprise a 16-digit numerical value[; t]he pUID may comprise a 16-digit BCD encoded number[; i]n some examples, pUID may comprise a 14-digit numerical value" par. [0052] or "[r]egarding master key management, two issuer master keys may be required for each part of the portfolio on which the one or more applets is issued[; f]or example, the first master key may comprise an Issuer Cryptogram Generation/Authentication Key (Iss-Key-Auth) and the second master key may comprise an Issuer Data Encryption Key (Iss-Key-DEK)[; i]n some examples, a network profile record ID (pNPR) and derivation key index (pDKI), as back office data, may be used to identify which Issuer Master Keys to use in the cryptographic processes for authentication[; t]he system performing the authentication may be configured to retrieve values of pNPR and pDKI for a contactless card at the time of authentication" par. [0053] or "to complete a payment transaction with a card issuer/payment processor per se, some data values are not needed, and authentication may be performed without involving real-time online connectivity to the card issuer/payment processor[; a]s is known in the art, point of sale (POS) systems submit transactions including a transaction value to a card issuer[; w]hether the issuer approves or denies the transaction may be based on if the card issuer recognizes the transaction value[; m]eanwhile, in certain embodiments of the present disclosure, transactions originating from a mobile device lack the transaction value associated with the POS systems[; t]herefore, in some embodiments, a dummy transaction value (i.e., a value recognizable to the card issuer and sufficient to allow activation to occur) may be passed as part of the example authentication communication protocol" par. [0083] and e.g. "[s]ending funds from one account to another account" par. [0003] or "server may receive, from the application executing on the first device, an encrypted request to transfer funds from the first account to a second account, the encrypted request generated responsive to the first device coming into communications range with a second device associated with the second account[; t]he server may then decrypt the encrypted request to transfer funds from the first account to the second account, and authorize the request to transfer funds from the first account to the second account" par. [0004] or "request to transfer funds from the first account to the second account" Claims 1, 5, 9, 12, 16, 19 and e.g. "user of mobile device 110-2 may specify to pay the user of mobile device 110-1" par. [0031] or "user of mobile device 110-2" pars. [0028]-[0031], [0033])
Claim 3, EXAMINER's Analysis: Claim 3 is rejected as being anticipated by ILINCIC. Claim 3 is a dependent claim that directly depends upon parent claim 2, which is also a dependent claim, and thus the instant claim indirectly depends upon claim 1, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claims 2 and 1, ILINCIC discloses the claimed subject matter of claim 3 as follows and as explained below.
Regarding and as per CLAIM 3, the computer-implemented method of claim 2, further comprising: Reference (ILINCIC: discloses e.g. "[a] computer-implemented method" Claim 1)
• 3 ¶ 2 • transmitting an approval from the financial institution to the mobile device; and Reference (ILINCIC: discloses e.g. "[a]t block 390, the management application 123 may transmit an indication of the validation (e.g., validation success) to the account application 113 of the mobile device 110" par. [0070] and e.g. "[a]t block 370, the management application 123 decrypts the encrypted data received from the contactless card 101 via the mobile device 110 using the diversified key 106 and a cryptographic algorithm[; d]oing so may yield at least the customer identifier 107[; b]y yielding the customer identifier 107, the management application 123 may validate the data received from the contactless card 101 at block 380[; f]or example, the management application 123 may compare the customer identifier 107 to a customer identifier for the associated account in the account data 124, and validate the data based on a match[; a]t block 390, the management application 123 may transmit an indication of the validation (e.g., validation success) to the account application 113 of the mobile device 110" par. [0070] and e.g. "each individual may possess a contactless card, and may be customers of the same issuing financial institution, but it is not necessary[; e]ach of these individuals may receive a push notification on their device, via the application, to split the purchase[; r]ather than accepting only one card tap to indicate payment, other contactless cards may be used[; i]n some examples, individuals who have different financial institutions may possess contactless cards 101 to provide information to initiate one or more payment requests from the card-tapping individual" par. [0093] and e.g. "transactions originating from a mobile device" par. [0083] or "[f]IG. 1B[; i]n such an embodiment, as shown, a contactless card 101 is tapped to mobile device 110-2[; t]he contactless card 101 may belong to the user of mobile device 110-2 (e.g., the payor's contactless card)[; i]n response, the contactless card 101 follows the encryption procedure detailed above with reference to FIG. 1A (e.g., using the master key 105, counter 104, and diversified key 106) to generate encrypted data comprising the customer identifier 107[; t]he contactless card 101 may transmit the generated encrypted data to the mobile device 110-2, which receives the encrypted data via the NFC card reader 118[; o]nce received, the account application 113 of the mobile device 110-2 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; u]pon decrypting the data received from the mobile device" par. [0030])
• 3 ¶ 3 • receiving a fund transfer instruction, in response to the approval, from the mobile device; and Reference (ILINCIC: discloses e.g. "[a]t block 480, the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 to the management application 123 of the server 120[; t]he account application 113 may further transmit, to the management application 123 of server 120, an indication of the requested payment of funds from the second account to the first account[; a]t block 490, the management application 123 of the server 120 processes the received data to validate the data generated by the contactless card 101 using key diversification (e.g., as described in blocks 360-390 of the logic flow 300)[; t]he management application 123 of the server 120 may further identify the indication of the requested payment, which may be processed once the server validates the data generated by the contactless card 101[; a]t block 495, the management application 123 of the server 120 authorizes the requested payment and processes the payment of funds from the first account to the second account" par. [0074])
• 3 ¶ 4 • wherein initiating the fund transfer includes initiating the fund transfer in response to the fund transfer instruction. Reference (ILINCIC: discloses e.g. "[a]t block 480, the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 to the management application 123 of the server 120[; t]he account application 113 may further transmit, to the management application 123 of server 120, an indication of the requested payment of funds from the second account to the first account[; a]t block 490, the management application 123 of the server 120 processes the received data to validate the data generated by the contactless card 101 using key diversification (e.g., as described in blocks 360-390 of the logic flow 300)[; t]he management application 123 of the server 120 may further identify the indication of the requested payment, which may be processed once the server validates the data generated by the contactless card 101[; a]t block 495, the management application 123 of the server 120 authorizes the requested payment and processes the payment of funds from the first account to the second account" par. [0074])
Claim 4, EXAMINER's Analysis: Claim 4 is rejected as being anticipated by ILINCIC. Claim 4 is a dependent claim that directly depends upon parent claim 1, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 1, ILINCIC discloses the claimed subject matter of claim 4 as follows and as explained below.
Regarding and as per CLAIM 4, the computer-implemented method of claim 1, See Prior Comment(s) at Claim 2 Par. 1;
• 4 ¶ 2 • wherein the credential associated with the destination account includes a proxy; and Reference (ILINCIC: discloses e.g. "[w]hen the mobile devices 110-1, 110-2 enter in NFC communications range, the account application 113 of mobile device 110-1 may generate and transmit an indication of the requested payment to the mobile device 110-2 via the NFC card reader 118[; t]he indication may include at least a receiving account number (e.g., an account number of the user of mobile device 110-1) and the requested amount[; w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029])
• 4 ¶ 3 • further comprising resolving, by the processing network, the proxy into an account number, prior to initiating the fund transfer. Reference (ILINCIC: discloses e.g. "[w]hen the mobile devices 110-1, 110-2 enter in NFC communications range, the account application 113 of mobile device 110-1 may generate and transmit an indication of the requested payment to the mobile device 110-2 via the NFC card reader 118[; t]he indication may include at least a receiving account number (e.g., an account number of the user of mobile device 110-1) and the requested amount[; w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029])
Claim 6, EXAMINER's Analysis: Claim 6 is rejected as being anticipated by ILINCIC. Claim 6 is an independent claim. ILINCIC discloses the claimed subject matter of claim 6 as follows and as explained below.
Regarding and as per CLAIM 6, a system for use in enhanced network transactions, the system comprising a processing network computing device configured to : Reference (ILINCIC: discloses e.g. "system" pars. [0017], [0019], [0021], [0053], [0085], [0095], [0097]-[0110] or "systems" pars. [0004], [0015], [0019], [0083], [0095], [0101] and e.g. "[e]mbodiments herein generally relate to mobile computing platforms, and more specifically, to near-field communication (NFC) mobile currency transfers" par. [0002] or "[e]mbodiments disclosed herein provide systems, methods, articles of manufacture, and computer-readable media for NFC mobile currency transfers" par. [0004] and e.g. "enhanced security for the involved devices and the overall financial transaction" par. [0013] and "a server to process the payment" par. [0011] or "[t]he server 120 is representative of any type of computing device, such as a server, workstation, compute cluster, cloud computing platform, virtualized computing system, and the like" par. [0017] or "the server 120 via the network 130" par. [0024] or "the server 120 to implement key diversification for the contactless card 101[; t]he output of the encryption may be the same diversified key value 106 that was created by the contactless card 101[; t]he management application 123 may then decrypt the encrypted data received via the network 130" par. [0025] and e.g. "server 120" pars. [0017], [0020]-[0027], [0029]-[0030], [0033], [0046]-[0047], [0050], [0068]-[0069], [0074], [0078]-[0080], [0095] or "management application 123 of the server 120" pars. [0025], [0069], [0074], [0078]-[0080] or "management application 123" pars. [0020], [0025], [0069]-[0070], [0074], [0078]-[0080], [0102])
• 6 ¶ 2 • receive a request for a fund transfer from a mobile device, in lieu of a request from a financial institution, the fund transfer between a source account and a destination account, the mobile device associated with one of a sender user and a receiver user, the request including an amount of the fund transfer and a credential associated with the destination account; Reference (ILINCIC: discloses e.g. "[s]ending funds from one account to another account" par. [0003] or "server may receive, from the application executing on the first device, an encrypted request to transfer funds from the first account to a second account, the encrypted request generated responsive to the first device coming into communications range with a second device associated with the second account[; t]he server may then decrypt the encrypted request to transfer funds from the first account to the second account, and authorize the request to transfer funds from the first account to the second account" par. [0004] or "request to transfer funds from the first account to the second account" Claims 1, 5, 9, 12, 16, 19 and e.g. "[n]FC-based mobile currency transfers[; a] mobile payment may be programmatically initialized when at least two mobile devices come into NFC communications range[; a] payment card associated with an account used to fund the currency transfer may be tapped to one or more of the devices to allow a server to validate the currency transfer" Abstract and e.g. "transactions originating from a mobile device" par. [0083] or "[f]IG. 1B[; i]n such an embodiment, as shown, a contactless card 101 is tapped to mobile device 110-2[; t]he contactless card 101 may belong to the user of mobile device 110-2 (e.g., the payor's contactless card)[; i]n response, the contactless card 101 follows the encryption procedure detailed above with reference to FIG. 1A (e.g., using the master key 105, counter 104, and diversified key 106) to generate encrypted data comprising the customer identifier 107[; t]he contactless card 101 may transmit the generated encrypted data to the mobile device 110-2, which receives the encrypted data via the NFC card reader 118[; o]nce received, the account application 113 of the mobile device 110-2 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; u]pon decrypting the data received from the mobile device" par. [0030] and e.g. "each individual may possess a contactless card, and may be customers of the same issuing financial institution, but it is not necessary[; e]ach of these individuals may receive a push notification on their device, via the application, to split the purchase[; r]ather than accepting only one card tap to indicate payment, other contactless cards may be used[; i]n some examples, individuals who have different financial institutions may possess contactless cards 101 to provide information to initiate one or more payment requests from the card-tapping individual" par. [0093] and e.g. "any of the mobile devices 110-1, 110-2 may initiate the transfer request[; f]or example, the user of mobile device 110-2 may specify to pay the user of mobile device 110-1, and the "tap" of the mobile devices when in NFC communications range provides the account application 113 of mobile device 110-2 with the account information of the user of mobile device 110-1 necessary to submit, approve, and process the transaction" par. [0031] and e.g. "any of the mobile devices 110-1, 110-2 may initiate the transfer request" par. [0031] and e.g. "user of mobile device 110-2 may specify to pay the user of mobile device 110-1" par. [0031] or "user of mobile device 110-2" pars. [0028]-[0031], [0033] and e.g. "user of mobile device 110-1" pars. [0028]-[0032] and e.g. "an application executing on the second mobile device may receive data describing the payment request (e.g., account information, payment amount, etc.) from the application executing on the first mobile device[; t]he second user may then approve the request, which may cause the second mobile device to transmit an indication to a server to process the payment" par. [0011] or "[t]he indication may include at least a receiving account number (e.g., an account number of the user of mobile device 110-1) and the requested amount[; w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029] or "the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 to the management application 123 of the server 120[; t]he account application 113 may further transmit, to the management application 123 of server 120, an indication of the requested payment of funds from the second account to the first account" par. [0074] or "the account application 113 of the first mobile device 110-1 transmits the data received from the contactless card 101 at block 585 to the management application 123 of the server 120[; t]he account application 113 of the first mobile device 110-1 may further include an indication of the requested payment from the second account to the first account" par. [0079] and e.g. "the logic flow 400 begins at block 410, where the account application 113 of the first mobile device 110-1 receives valid authentication credentials for a first user account[; a]s stated, the authentication credentials may include a username/password combination, biometric credentials, or any other type of authentication credentials[; a]t block 420, the account application 113 of the second mobile device 110 receives valid authentication credentials for a second user account[; a]t block 430, the account application 113 of the first mobile device 110-1 generates a request to receive payment from the second account associated with the second mobile device 110-1[; f]or example, the first user may provide input to the account application 113 of the mobile device 110-1 specifying to receive a specified sum (e.g., $50) from the second account of the second user" par. [0072])
• 6 ¶ 3 • identify an acquiring credential of a financial institution that issued the source account; Reference (ILINCIC: discloses e.g. "the contactless card 101 to generate encrypted data (e.g., an encrypted customer identifier 107) using the master key 105, counter value 104, and diversified key 106 as described above (e.g., blocks 320-350 of logic flow 300)[; t]he contactless card 101 may then transmit the data (which may include the counter value 104) to the account application 113 of the second mobile device 110-2" par. [0073] and "[a]t block 480, the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 to the management application 123 of the server 120[; t]he account application 113 may further transmit, to the management application 123 of server 120, an indication of the requested payment of funds from the second account to the first account[; a]t block 490, the management application 123 of the server 120 processes the received data to validate the data generated by the contactless card 101 using key diversification (e.g., as described in blocks 360-390 of the logic flow 300)" par. [0074] where "[a]t block 370, the management application 123 decrypts the encrypted data received from the contactless card 101 via the mobile device 110 using the diversified key 106 and a cryptographic algorithm[; d]oing so may yield at least the customer identifier 107[; b]y yielding the customer identifier 107, the management application 123 may validate the data received from the contactless card 101 at block 380[; f]or example, the management application 123 may compare the customer identifier 107 to a customer identifier for the associated account in the account data 124, and validate the data based on a match" par. [0070] and e.g. "[t]he account data 124 includes account-related data for a plurality of users and/or accounts[; t]he account data 124 may include at least a master key 105, counter 104, a customer ID 107, an associated contactless card 101, and biographical information for each account" par. [0020] and "when a contactless card 101 is manufactured, a unique master key 105 may be programmed into the memory 102 of the contactless card 101[; s]imilarly, the unique master key 105 may be stored in a record of a customer associated with the contactless card 101 in the account data 124 of the server 120 (and/or stored in a different secure location)[; t]he master key may be kept secret from all parties other than the contactless card 101 and server 120, thereby enhancing security of the system 100" par. [0021] or "the management application 123 may verify the data transmitted by the contactless card 101 via the mobile device 110 by comparing the decrypted customer ID 107 to a customer ID in the account data 124 for the account, where a match of the customer ID values verifies the data received from the contactless card 101" par. [0025] and "[u]pon decrypting the data received from the mobile device 110-2, the server 120 may compare the customer identifier 107 to an expected customer identifier value (e.g., a customer identifier provided by the account application 113, a customer identifier stored in the account data 124, etc.)[; u]pon verifying the presence of the contactless card 101 associated with the payor's account, the server 120 may approve and process the payment, and transmit an indication of the same to the mobile devices 110-1 and/or 110-2" par. [0030])
• 6 ¶ 4 • transmit an authorization request for the fund transfer to the financial institution, whereby the financial institution approves the fund transfer; and Reference (ILINCIC: discloses e.g. "e.g. "[o]nce received, the account application 113 of the mobile device 110-1 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; t]he server 120 may generally compare the decrypted customer identifier 107 to an expected customer identifier value (e.g., the customer identifier 107 received in from device 110-2 in FIG. 1C, etc.) to approve the transaction[; f]urthermore, in at least one embodiment, upon receiving the data from the mobile device 110-1, the server 120 may determine whether an amount of time that has elapsed since the data received from device 110-2 in FIG. 2B exceeds a threshold amount of time (e.g., 30 seconds)[; d]oing so allows the server 120 to ensure that both users are in proximity of each other and the contactless card 101[; t]he server 120 may then approve and process the payment, and transmit an indication of the same to the mobile devices 110-1 and/or 110-2" par. [0033] or "point of sale (POS) systems submit transactions including a transaction value to a card issuer[; w]hether the issuer approves or denies the transaction may be based on if the card issuer recognizes the transaction value[; m]eanwhile, in certain embodiments of the present disclosure, transactions originating from a mobile device lack the transaction value associated with the POS systems[; t]herefore, in some embodiments, a dummy transaction value (i.e., a value recognizable to the card issuer and sufficient to allow activation to occur) may be passed as part of the example authentication communication protocol" par. [0083] and e.g. "[a]t block 370, the management application 123 decrypts the encrypted data received from the contactless card 101 via the mobile device 110 using the diversified key 106 and a cryptographic algorithm[; d]oing so may yield at least the customer identifier 107[; b]y yielding the customer identifier 107, the management application 123 may validate the data received from the contactless card 101 at block 380[; f]or example, the management application 123 may compare the customer identifier 107 to a customer identifier for the associated account in the account data 124, and validate the data based on a match[; a]t block 390, the management application 123 may transmit an indication of the validation (e.g., validation success) to the account application 113 of the mobile device 110" par. [0070])
• 6 ¶ 5 • based on the approval from the financial institution, initiate the fund transfer between the source account and the destination account. See Prior Comment(s) at Claim 1 Par. 5;
Claim 7, EXAMINER's Analysis: Claim 7 is rejected as being anticipated by ILINCIC. Claim 7 is a dependent claim that directly depends upon parent claim 6, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 6, ILINCIC discloses the claimed subject matter of claim 7 as follows and as explained below.
Regarding and as per CLAIM 7, the system of claim 6, Reference (ILINCIC: discloses e.g. "system" pars. [0017], [0019], [0021], [0053], [0085], [0095], [0097]-[0110] or "systems" pars. [0004], [0015], [0019], [0083], [0095], [0101])
• 7 ¶ 2 • wherein the financial institution is an issuer of the source account to the sender user. See Prior Comment(s) at Claim 2 Par. 2;
Claim 8, EXAMINER's Analysis: Claim 8 is rejected as being anticipated by ILINCIC. Claim 8 is a dependent claim that directly depends upon parent claim 6, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 6, ILINCIC discloses the claimed subject matter of claim 8 as follows and as explained below.
Regarding and as per CLAIM 8, the system of claim 6, Reference (ILINCIC: discloses e.g. "system" pars. [0017], [0019], [0021], [0053], [0085], [0095], [0097]-[0110] or "systems" pars. [0004], [0015], [0019], [0083], [0095], [0101])
• 8 ¶ 2 • wherein the credential associated with the destination account includes a proxy; and See Prior Comment(s) at Claim 4 Par. 2;
• 8 ¶ 3 • wherein the processing network computing device is further configured to resolve the proxy into an account number, prior to transmitting the authorization request for the fund transfer to the financial institution. Reference (ILINCIC: discloses e.g. "[w]hen the mobile devices 110-1, 110-2 enter in NFC communications range, the account application 113 of mobile device 110-1 may generate and transmit an indication of the requested payment to the mobile device 110-2 via the NFC card reader 118[; t]he indication may include at least a receiving account number (e.g., an account number of the user of mobile device 110-1) and the requested amount[; w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029] and e.g. "[a]t block 390, the management application 123 may transmit an indication of the validation (e.g., validation success) to the account application 113 of the mobile device 110" par. [0070])
Claim 10, EXAMINER's Analysis: Claim 10 is rejected as being anticipated by ILINCIC. Claim 10 is an independent claim. ILINCIC discloses the claimed subject matter of claim 10 as follows and as explained below.
Regarding and as per CLAIM 10, a computer-implemented method for use in facilitating a contactless network transaction, the method comprising: Reference (ILINCIC: discloses e.g. "[a] computer-implemented method" Claim 1 and e.g. "[e]mbodiments herein generally relate to mobile computing platforms, and more specifically, to near-field communication (NFC) mobile currency transfers" par. [0002] or "[e]mbodiments disclosed herein provide systems, methods, articles of manufacture, and computer-readable media for NFC mobile currency transfers" par. [0004] and e.g. "contactless card 101" [and] "server 120" and/or "network 130" and/or "management application 123" and/or "transaction" pars. [0020]-[0026], [0030]-[0031], [0033], [0047]-[0048], [0051], [0054], [0068]-[0070], [0074], [0078]-[0081], [0084], [0086], [0090])
• 10 ¶ 2 • soliciting, by a smartphone mobile device specific to a sender user, details of a push person-to-person (P2P) fund transfer, the details including a name of a receiver user and an amount of the push P2P fund transfer; Reference (ILINCIC: discloses e.g. "[t]he user of mobile device 110-1 has specified to request a payment of $5 from "[u]ser A", where User A corresponds to the user of mobile device 110-2[; f]urthermore, as shown, the user of mobile device 110-1 has specified an additional passcode value of "1234" which may be used to secure data sent between the devices 110-1, 110-2[; t]he users may share the passcode (e.g., verbally or in writing)" par. [0028] or "[w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient" [par. [0029] or "the embodiment depicted in FIG. 1C, the account application 113 transmits the encrypted data received from the contactless card 101 subsequent to transmitting a request to process the transaction[; f]urthermore, any of the mobile devices 110-1, 110-2 may initiate the transfer request[; f]or example, the user of mobile device 110-2 may specify to pay the user of mobile device 110-1, and the "tap" of the mobile devices when in NFC communications range provides the account application 113 of mobile device 110-2 with the account information of the user of mobile device 110-1 necessary to submit, approve, and process the transaction" par. [0031] and e.g. "[t]he mobile devices 110 are representative of any type of network-enabled computing devices, such as smartphones, tablet computers, wearable devices, laptops, portable gaming devices, and the like" par. [0017] or "if the contactless card tap is directed to a device [] smartphone or tablet, the contactless card can [] transmit appropriate and data to communicate with this device (such as the encrypted identity information necessary for authentication by the methods described herein)" par. [0085] and e.g. "transactions originating from a mobile device" par. [0083] or "[f]IG. 1B[; i]n such an embodiment, as shown, a contactless card 101 is tapped to mobile device 110-2[; t]he contactless card 101 may belong to the user of mobile device 110-2 (e.g., the payor's contactless card)[; i]n response, the contactless card 101 follows the encryption procedure detailed above with reference to FIG. 1A (e.g., using the master key 105, counter 104, and diversified key 106) to generate encrypted data comprising the customer identifier 107[; t]he contactless card 101 may transmit the generated encrypted data to the mobile device 110-2, which receives the encrypted data via the NFC card reader 118[; o]nce received, the account application 113 of the mobile device 110-2 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; u]pon decrypting the data received from the mobile device" par. [0030] and e.g. "user of mobile device 110-2 may specify to pay the user of mobile device 110-1" par. [0031] or "user of mobile device 110-2" pars. [0028]-[0031], [0033] and e.g. "[e]ach of these individuals may receive a push notification on their device" par. [0093] and e.g. "a first user may use an application executing on a first mobile device to initiate a request to receive payment from a second user[; w]hen the first mobile device of the first user is within NFC communications range with a second mobile device of the second user, an application executing on the second mobile device may receive data describing the payment request (e.g., account information, payment amount, etc.) from the application executing on the first mobile device[; t]he second user may then approve the request, which may cause the second mobile device to transmit an indication to a server to process the payment" par. [0011] or "the user of mobile device 110-2 may specify to pay the user of mobile device 110-1" par. [0031] and e.g. "[n]FC-based mobile currency transfers[; a] mobile payment may be programmatically initialized when at least two mobile devices come into NFC communications range[; a] payment card associated with an account used to fund the currency transfer may be tapped to one or more of the devices to allow a server to validate the currency transfer" Abstract and e.g. "to request a payment of $5 from "[u]ser A", where User A corresponds to the user of mobile device 110-2" par. [0028] or " the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient" par. [0029] and e.g. "user of mobile device 110-1" pars. [0028]-[0032] and e.g. "an application executing on the second mobile device may receive data describing the payment request (e.g., account information, payment amount, etc.) from the application executing on the first mobile device[; t]he second user may then approve the request, which may cause the second mobile device to transmit an indication to a server to process the payment" par. [0011] or "[t]he indication may include at least a receiving account number (e.g., an account number of the user of mobile device 110-1) and the requested amount[; w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029] or "the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 to the management application 123 of the server 120[; t]he account application 113 may further transmit, to the management application 123 of server 120, an indication of the requested payment of funds from the second account to the first account" par. [0074] or "the account application 113 of the first mobile device 110-1 transmits the data received from the contactless card 101 at block 585 to the management application 123 of the server 120[; t]he account application 113 of the first mobile device 110-1 may further include an indication of the requested payment from the second account to the first account" par. [0079])
• 10 ¶ 3 • receiving, at the smartphone mobile device, the details of the push P2P fund transfer; Reference (ILINCIC: discloses e.g. "[t]he user of mobile device 110-1 has specified to request a payment of $5 from "[u]ser A", where User A corresponds to the user of mobile device 110-2[; f]urthermore, as shown, the user of mobile device 110-1 has specified an additional passcode value of "1234" which may be used to secure data sent between the devices 110-1, 110-2[; t]he users may share the passcode (e.g., verbally or in writing)" par. [0028] or "[w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient" [par. [0029] or "the embodiment depicted in FIG. 1C, the account application 113 transmits the encrypted data received from the contactless card 101 subsequent to transmitting a request to process the transaction[; f]urthermore, any of the mobile devices 110-1, 110-2 may initiate the transfer request[; f]or example, the user of mobile device 110-2 may specify to pay the user of mobile device 110-1, and the "tap" of the mobile devices when in NFC communications range provides the account application 113 of mobile device 110-2 with the account information of the user of mobile device 110-1 necessary to submit, approve, and process the transaction" par. [0031] and e.g. "[t]he mobile devices 110 are representative of any type of network-enabled computing devices, such as smartphones, tablet computers, wearable devices, laptops, portable gaming devices, and the like" par. [0017] or "if the contactless card tap is directed to a device [] smartphone or tablet, the contactless card can [] transmit appropriate and data to communicate with this device (such as the encrypted identity information necessary for authentication by the methods described herein)" par. [0085] and e.g. "transactions originating from a mobile device" par. [0083] or "[f]IG. 1B[; i]n such an embodiment, as shown, a contactless card 101 is tapped to mobile device 110-2[; t]he contactless card 101 may belong to the user of mobile device 110-2 (e.g., the payor's contactless card)[; i]n response, the contactless card 101 follows the encryption procedure detailed above with reference to FIG. 1A (e.g., using the master key 105, counter 104, and diversified key 106) to generate encrypted data comprising the customer identifier 107[; t]he contactless card 101 may transmit the generated encrypted data to the mobile device 110-2, which receives the encrypted data via the NFC card reader 118[; o]nce received, the account application 113 of the mobile device 110-2 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; u]pon decrypting the data received from the mobile device" par. [0030] and e.g. "[e]ach of these individuals may receive a push notification on their device" par. [0093] and e.g. "a first user may use an application executing on a first mobile device to initiate a request to receive payment from a second user[; w]hen the first mobile device of the first user is within NFC communications range with a second mobile device of the second user, an application executing on the second mobile device may receive data describing the payment request (e.g., account information, payment amount, etc.) from the application executing on the first mobile device[; t]he second user may then approve the request, which may cause the second mobile device to transmit an indication to a server to process the payment" par. [0011] or "the user of mobile device 110-2 may specify to pay the user of mobile device 110-1" par. [0031] and e.g. "[n]FC-based mobile currency transfers[; a] mobile payment may be programmatically initialized when at least two mobile devices come into NFC communications range[; a] payment card associated with an account used to fund the currency transfer may be tapped to one or more of the devices to allow a server to validate the currency transfer" Abstract)
• 10 ¶ 4 • prompting, by the smartphone mobile device, a contactless device for the receiver user to be presented at the smartphone mobile device, whereby one of the sender user and the receiver user presents the contactless device of the receiver user to the smartphone mobile device; Reference (ILINCIC: discloses e.g. "the account application 113 transmits the encrypted data received from the contactless card 101 prior to transmitting a request to process the transaction[; i]n other embodiments, e.g., the embodiment depicted in FIG. 1C, the account application 113 transmits the encrypted data received from the contactless card 101 subsequent to transmitting a request to process the transaction[; f]urthermore, any of the mobile devices 110-1, 110-2 may initiate the transfer request[; f]or example, the user of mobile device 110-2 may specify to pay the user of mobile device 110-1, and the "tap" of the mobile devices when in NFC communications range provides the account application 113 of mobile device 110-2 with the account information of the user of mobile device 110-1 necessary to submit, approve, and process the transaction" par. [0031] and e.g. "any of the mobile devices 110-1, 110-2 may initiate the transfer request" par. [0031])
• 10 ¶ 5 • in response to the contactless device being presented at the smartphone mobile device, contactlessly capturing, by the smartphone mobile device, a credential specific to a receiver account from the contactless device of the receiver user; Reference (ILINCIC: discloses e.g. "the account application 113 transmits the encrypted data received from the contactless card 101 prior to transmitting a request to process the transaction[; i]n other embodiments, e.g., the embodiment depicted in FIG. 1C, the account application 113 transmits the encrypted data received from the contactless card 101 subsequent to transmitting a request to process the transaction[; f]urthermore, any of the mobile devices 110-1, 110-2 may initiate the transfer request[; f]or example, the user of mobile device 110-2 may specify to pay the user of mobile device 110-1, and the "tap" of the mobile devices when in NFC communications range provides the account application 113 of mobile device 110-2 with the account information of the user of mobile device 110-1 necessary to submit, approve, and process the transaction" par. [0031])
• 10 ¶ 6 • validating, by the smartphone mobile device, with an issuer of the receiver account, the name of the receiver user included in the details of the push P2P fund transfer; and Reference (ILINCIC: discloses e.g. "[a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029] and "the authentication service to validate the one or more cryptograms provided by the one or more applets, the following data must be conveyed from the one or more applets to the mobile device in the clear during an authentication session: version number to determine the cryptographic approach used and message format for validation of the cryptogram" par. [0066] or "the management application 123 may validate the data received from the contactless card 101 at block 380[; f]or example, the management application 123 may compare the customer identifier 107 to a customer identifier for the associated account in the account data 124, and validate the data based on a match[; a]t block 390, the management application 123 may transmit an indication of the validation (e.g., validation success) to the account application 113 of the mobile device 110" par. [0070] or "[a]t block 490, the management application 123 of the server 120 processes the received data to validate the data generated by the contactless card 101 using key diversification (e.g., as described in blocks 360-390 of the logic flow 300)[; t]he management application 123 of the server 120 may further identify the indication of the requested payment, which may be processed once the server validates the data generated by the contactless card 101[; a]t block 495, the management application 123 of the server 120 authorizes the requested payment and processes the payment of funds" par. [0074] and e.g. "for the contactless card 101, a different unique identifier is derived which may be related to the application primary account number (PAN) and PAN sequence number, which is encoded in the card[; t]he key diversification may be configured to receive the identifier as input with the master key such that one or more keys may be created for each contactless card[; i]n some examples, these diversified keys may comprise a first key and a second key[; t]he first key may include an authentication master key (Card Cryptogram Generation/Authentication Key-Card-Key-Auth)[; t]he second key may comprise an encryption master key (Card Data Encryption Key-Card-Key-DEK)[; t]he first and second keys may be used by the one or more applets 240 to generate session keys that may be used to generate a MAC cryptogram, authenticate the card, and to encipher it, respectively[; i]n some examples, the first and the second keys may be created by diversifying the issuer master keys by combining them with the card's unique ID number (pUID) and the PAN sequence number (PSN) of a payment applet, as specified in EMV key diversion algorithm Option A of EMV 4.3 Book 2 A1.4 Master Key Derivation[; t]he pUID may comprise a 16-digit numerical value[; t]he pUID may comprise a 16-digit BCD encoded number[; i]n some examples, pUID may comprise a 14-digit numerical value" par. [0052] or "[r]egarding master key management, two issuer master keys may be required for each part of the portfolio on which the one or more applets is issued[; f]or example, the first master key may comprise an Issuer Cryptogram Generation/Authentication Key (Iss-Key-Auth) and the second master key may comprise an Issuer Data Encryption Key (Iss-Key-DEK)[; i]n some examples, a network profile record ID (pNPR) and derivation key index (pDKI), as back office data, may be used to identify which Issuer Master Keys to use in the cryptographic processes for authentication[; t]he system performing the authentication may be configured to retrieve values of pNPR and pDKI for a contactless card at the time of authentication" par. [0053] or "to complete a payment transaction with a card issuer/payment processor per se, some data values are not needed, and authentication may be performed without involving real-time online connectivity to the card issuer/payment processor[; a]s is known in the art, point of sale (POS) systems submit transactions including a transaction value to a card issuer[; w]hether the issuer approves or denies the transaction may be based on if the card issuer recognizes the transaction value[; m]eanwhile, in certain embodiments of the present disclosure, transactions originating from a mobile device lack the transaction value associated with the POS systems[; t]herefore, in some embodiments, a dummy transaction value (i.e., a value recognizable to the card issuer and sufficient to allow activation to occur) may be passed as part of the example authentication communication protocol" par. [0083])
• 10 ¶ 7 • in response to the name being valid, initiating, by the mobile device, through a payment service provider (PSP) computing device, a request for the push P2P fund transfer from a source account to the receiver account based on the credential. Reference (ILINCIC: discloses e.g. "[a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029] and "the authentication service to validate the one or more cryptograms provided by the one or more applets, the following data must be conveyed from the one or more applets to the mobile device in the clear during an authentication session: version number to determine the cryptographic approach used and message format for validation of the cryptogram" par. [0066] or "the management application 123 may validate the data received from the contactless card 101 at block 380[; f]or example, the management application 123 may compare the customer identifier 107 to a customer identifier for the associated account in the account data 124, and validate the data based on a match[; a]t block 390, the management application 123 may transmit an indication of the validation (e.g., validation success) to the account application 113 of the mobile device 110" par. [0070] or "[a]t block 490, the management application 123 of the server 120 processes the received data to validate the data generated by the contactless card 101 using key diversification (e.g., as described in blocks 360-390 of the logic flow 300)[; t]he management application 123 of the server 120 may further identify the indication of the requested payment, which may be processed once the server validates the data generated by the contactless card 101[; a]t block 495, the management application 123 of the server 120 authorizes the requested payment and processes the payment of funds" par. [0074] and e.g. "the management application 123 of the server 120 authorizes the requested payment and processes the payment of funds from the first account to the second account" par. [0074] or "the management application 123 of the server 120 may then process the transfer of funds from the second account to the first account" par. [0080] or "server 120 may [] approve and process the payment" pars. [0030], [0033] and e.g. "server 120" pars. [0017], [0020]-[0027], [0029]-[0030], [0033], [0046]-[0047], [0050], [0068]-[0069], [0074], [0078]-[0080], [0095] or "management application 123 of the server 120" pars. [0025], [0069], [0074], [0078]-[0080] or "management application 123" pars. [0020], [0025], [0069]-[0070], [0074], [0078]-[0080], [0102] and e.g. "[s]ending funds from one account to another account" par. [0003] or "server may receive, from the application executing on the first device, an encrypted request to transfer funds from the first account to a second account, the encrypted request generated responsive to the first device coming into communications range with a second device associated with the second account[; t]he server may then decrypt the encrypted request to transfer funds from the first account to the second account, and authorize the request to transfer funds from the first account to the second account" par. [0004] or "request to transfer funds from the first account to the second account" Claims 1, 5, 9, 12, 16, 19 and e.g. "the account application 113 transmits the encrypted data received from the contactless card 101 prior to transmitting a request to process the transaction[; i]n other embodiments, e.g., the embodiment depicted in FIG. 1C, the account application 113 transmits the encrypted data received from the contactless card 101 subsequent to transmitting a request to process the transaction[; f]urthermore, any of the mobile devices 110-1, 110-2 may initiate the transfer request[; f]or example, the user of mobile device 110-2 may specify to pay the user of mobile device 110-1, and the "tap" of the mobile devices when in NFC communications range provides the account application 113 of mobile device 110-2 with the account information of the user of mobile device 110-1 necessary to submit, approve, and process the transaction" par. [0031])
Claim 11, EXAMINER's Analysis: Claim 11 is rejected as being anticipated by ILINCIC. Claim 11 is a dependent claim that directly depends upon parent claim 10, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 10, ILINCIC discloses the claimed subject matter of claim 11 as follows and as explained below.
Regarding and as per CLAIM 11, the computer-implemented method of claim 10, Reference (ILINCIC: discloses e.g. "[a] computer-implemented method" Claim 1)
• 11 ¶ 2 • wherein receiving the details of the push P2P fund transfer includes receiving, at an input device of the smartphone mobile device, manual entry at a key pad entry of the name and the amount. Reference (ILINCIC: discloses e.g. "[f]IG. 1B depicts an example where a mobile device 110-1 and 110-2 initiate an NFC-based currency transfer[; a]s shown, the mobile devices 110-1, 110-2 execute instances of the account application 113[; t]he user of mobile device 110-1 has specified to request a payment of $5 from "[u]ser A", where User A corresponds to the user of mobile device 110-2[; f]urthermore, as shown, the user of mobile device 110-1 has specified an additional passcode value of "1234" which may be used to secure data sent between the devices 110-1, 110-2[; t]he users may share the passcode (e.g., verbally or in writing)" par. [0028] and "[w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient" par. [0029] and e.g. "[a] user can enter commands and information into the computing system 602 through one or more wire/wireless input devices, for example, a keyboard 638 and a pointing device, such as a mouse 640[; o]ther input devices may include microphones, infra-red (IR) remote controls, radio-frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like[; t]hese and other input devices are often connected to the processor 604 through an input device interface 642 that is coupled to the system bus 608, but can be connected by other interfaces such as a parallel port, IEEE 1394 serial port, a game port, a USB port, an IR interface, and so forth" par. [0103] where "the computing architecture 600 may be representative, for example, of a system that implements one or more components of the system 100[; i]n some embodiments, computing system 602 may be representative, for example, of the mobile devices 110 and server 120 of the system 100[; t]he embodiments are not limited in this context[; m]ore generally, the computing architecture 600 is configured to implement all logic, applications, systems, methods, apparatuses, and functionality described herein with reference to FIGS. 1-5" par. [0095] and "[t]he computing system 602 includes various common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, power supplies, and so forth" par. [0097])
Claim 12, EXAMINER's Analysis: Claim 12 is rejected as being anticipated by ILINCIC. Claim 12 is a dependent claim that directly depends upon parent claim 10, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 10, ILINCIC discloses the claimed subject matter of claim 12 as follows and as explained below.
Regarding and as per CLAIM 12, the computer-implemented method of claim 10, See Prior Comment(s) at Claim 11 Par. 1;
• 12 ¶ 2 • wherein the credential from the contactless device of the receiver user includes a deposit only credential for the receiver account, the credential including an account number. Reference (ILINCIC: discloses e.g. "[w]hen the mobile devices 110-1, 110-2 enter in NFC communications range, the account application 113 of mobile device 110-1 may generate and transmit an indication of the requested payment to the mobile device 110-2 via the NFC card reader 118[; t]he indication may include at least a receiving account number (e.g., an account number of the user of mobile device 110-1) and the requested amount[; w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029] and e.g. "[w]hen the mobile devices 110-1, 110-2 enter in NFC communications range, the account application 113 of mobile device 110-1 may generate and transmit an indication of the requested payment to the mobile device 110-2 via the NFC card reader 118[; t]he indication may include at least a receiving account number (e.g., an account number of the user of mobile device 110-1) and the requested amount[; w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029])
Claim 13, EXAMINER's Analysis: Claim 13 is rejected as being anticipated by ILINCIC. Claim 13 is a dependent claim that directly depends upon parent claim 10, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 10, ILINCIC discloses the claimed subject matter of claim 13 as follows and as explained below.
Regarding and as per CLAIM 13, the computer-implemented method of claim 10, See Prior Comment(s) at Claim 11 Par. 1;
• 13 ¶ 2 • further comprising soliciting and receiving, by the smartphone mobile device, a selection of a source account of the sender user for the push P2P fund transfer; and Reference (ILINCIC: discloses e.g. "[a]t block 460, the account application 113 of the second mobile device 110-2 outputs an indication specifying to tap the contactless card 101 associated with the second account to the second mobile device 110-2[; a]t block 470, the contactless card 101 associated with the second account is tapped to the mobile device 110-2" par. [0073] or "account application 113 of the second mobile device 110-2 then outputs the indication to tap the contactless card 101 to the second mobile device 110-2" par. [0076] and e.g. "[d]oing so causes the contactless card 101 to generate encrypted data (e.g., an encrypted customer identifier 107) using the master key 105, counter value 104, and diversified key 106 as described above (e.g., blocks 320-350 of logic flow 300)" par. [0073] and e.g. "to tap the contactless card 101 associated with the second account to the second mobile device 110-2" par. [0073])
• 13 ¶ 3 • wherein the request for the push P2P fund transfer includes an account number specific to the source account. Reference (ILINCIC: discloses e.g. "[d]oing so causes the contactless card 101 to generate encrypted data (e.g., an encrypted customer identifier 107) using the master key 105, counter value 104, and diversified key 106 as described above (e.g., blocks 320-350 of logic flow 300)[; t]he contactless card 101 may then transmit the data (which may include the counter value 104) to the account application 113 of the second mobile device 110-2" par. [0073] and "[a]t block 480, the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 to the management application 123 of the server 120[; t]he account application 113 may further transmit, to the management application 123 of server 120, an indication of the requested payment of funds from the second account to the first account[; a]t block 490, the management application 123 of the server 120 processes the received data to validate the data generated by the contactless card 101 using key diversification (e.g., as described in blocks 360-390 of the logic flow 300)[; t]he management application 123 of the server 120 may further identify the indication of the requested payment, which may be processed once the server validates the data generated by the contactless card 101[; a]t block 495, the management application 123 of the server 120 authorizes the requested payment and processes the payment of funds" par. [0074] or "[a]t block 510, the contactless card 101 generates the diversified key 106 using the counter value 104 and the master key 105 in the memory 102 and a cryptographic algorithm[; a]s stated, the contactless card 101 may increment the counter value 104 prior to generating the diversified key 106, e.g., after receiving the read data request from the account application 113 of the second mobile device 110-2[; a]t block 520, the contactless card 101 encrypts data (e.g., the customer identifier 107) using the diversified key 106 and the cryptographic algorithm, generating encrypted data[; a]t block 530, the contactless card 101 transmits the encrypted data generated at block 520 to the account application 113 of the second mobile device 110-2[; a]s stated, the contactless card 101 may further transmit the current counter value 104 to the account application 113 of the second mobile device 110-2" par. [0077] and e.g. "[w]hen the mobile devices 110-1, 110-2 enter in NFC communications range, the account application 113 of mobile device 110-1 may generate and transmit an indication of the requested payment to the mobile device 110-2 via the NFC card reader 118[; t]he indication may include at least a receiving account number (e.g., an account number of the user of mobile device 110-1) and the requested amount[; w]hen received by the mobile device 110-2, the account application 113 may prompt the user to enter the passcode[; a]s shown, the user enters the correct passcode, and the account application 113 outputs a graphical user interface (GUI) with the details of the requested payment (e.g., the amount and recipient "[u]ser B")[; a]lthough "[u]ser B" is depicted as the recipient, in some embodiments, an account number may additionally and/or alternatively be used to identify the recipient[; o]nce the user of mobile device 110-2 approves the transaction, the account application 113 of mobile device 110-2 may transmit an indication of the approved transaction to the server 120, which may process the payment accordingly" par. [0029] and e.g. "[a]t block 540, the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 at block 530 to the management application 123 of the server 120[; a]t block 550, the management application 123 of the server 120 decrypts the received encrypted data using the master key 105, diversified key 106, counter value 104, and a cryptographic algorithm[; a]s stated, the management application 123 of the server 120 may generate the diversified key 106 using the counter value 104, master key 105, and the cryptographic algorithm[; i]n one embodiment, the counter value 104 is received from the contactless card 101[; i]n other embodiments, the management application 123 of the server 120 increments the counter 104 in the memory 122 to generate the diversified key 106[; a]t block 560, the management application 123 of the server 120 may validate the data received from the contactless card 101 via the mobile device 110-2 by matching the decrypted customer identifier 107 with a customer identifier of the user stored in the account data 124" par. [0078] where "customer identifier 107 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 101, and the identifier may distinguish the user of the contactless card from other contactless card users[; i]n some examples, the customer identifier 107 may identify both a customer and an account assigned to that customer and may further identify the contactless card associated with the customer's account" par. [0038] and "[a]t block 370, the management application 123 decrypts the encrypted data received from the contactless card 101 via the mobile device 110 using the diversified key 106 and a cryptographic algorithm[; d]oing so may yield at least the customer identifier 107[; b]y yielding the customer identifier 107, the management application 123 may validate the data received from the contactless card 101 at block 380[; f]or example, the management application 123 may compare the customer identifier 107 to a customer identifier for the associated account in the account data 124, and validate the data based on a match[; a]t block 390, the management application 123 may transmit an indication of the validation (e.g., validation success) to the account application 113 of the mobile device 110" par. [0070])
Claim 14, EXAMINER's Analysis: Claim 14 is rejected as being anticipated by ILINCIC. Claim 14 is a dependent claim that directly depends upon parent claim 10, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 10, ILINCIC discloses the claimed subject matter of claim 14 as follows and as explained below.
Regarding and as per CLAIM 14, the computer-implemented method of claim 10, further comprising: Reference (ILINCIC: discloses e.g. "[a] computer-implemented method" Claim 1)
• 14 ¶ 2 • compiling and transmitting, by the PSP computing device, an authorization request specific to the push P2P fund transfer to a financial institution, which issued the sender account; Reference (ILINCIC: discloses e.g. "each individual may possess a contactless card, and may be customers of the same issuing financial institution, but it is not necessary[; e]ach of these individuals may receive a push notification on their device, via the application, to split the purchase[; r]ather than accepting only one card tap to indicate payment, other contactless cards may be used[; i]n some examples, individuals who have different financial institutions may possess contactless cards 101 to provide information to initiate one or more payment requests from the card-tapping individual" par. [0093] and e.g. "e.g. "[o]nce received, the account application 113 of the mobile device 110-1 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; t]he server 120 may generally compare the decrypted customer identifier 107 to an expected customer identifier value (e.g., the customer identifier 107 received in from device 110-2 in FIG. 1C, etc.) to approve the transaction[; f]urthermore, in at least one embodiment, upon receiving the data from the mobile device 110-1, the server 120 may determine whether an amount of time that has elapsed since the data received from device 110-2 in FIG. 2B exceeds a threshold amount of time (e.g., 30 seconds)[; d]oing so allows the server 120 to ensure that both users are in proximity of each other and the contactless card 101[; t]he server 120 may then approve and process the payment, and transmit an indication of the same to the mobile devices 110-1 and/or 110-2" par. [0033] or "point of sale (POS) systems submit transactions including a transaction value to a card issuer[; w]hether the issuer approves or denies the transaction may be based on if the card issuer recognizes the transaction value[; m]eanwhile, in certain embodiments of the present disclosure, transactions originating from a mobile device lack the transaction value associated with the POS systems[; t]herefore, in some embodiments, a dummy transaction value (i.e., a value recognizable to the card issuer and sufficient to allow activation to occur) may be passed as part of the example authentication communication protocol" par. [0083] and e.g. "[a]t block 370, the management application 123 decrypts the encrypted data received from the contactless card 101 via the mobile device 110 using the diversified key 106 and a cryptographic algorithm[; d]oing so may yield at least the customer identifier 107[; b]y yielding the customer identifier 107, the management application 123 may validate the data received from the contactless card 101 at block 380[; f]or example, the management application 123 may compare the customer identifier 107 to a customer identifier for the associated account in the account data 124, and validate the data based on a match[; a]t block 390, the management application 123 may transmit an indication of the validation (e.g., validation success) to the account application 113 of the mobile device 110" par. [0070] and e.g. "each individual may possess a contactless card, and may be customers of the same issuing financial institution, but it is not necessary[; e]ach of these individuals may receive a push notification on their device, via the application, to split the purchase[; r]ather than accepting only one card tap to indicate payment, other contactless cards may be used[; i]n some examples, individuals who have different financial institutions may possess contactless cards 101 to provide information to initiate one or more payment requests from the card-tapping individual" par. [0093] and e.g. "for the contactless card 101, a different unique identifier is derived which may be related to the application primary account number (PAN) and PAN sequence number, which is encoded in the card[; t]he key diversification may be configured to receive the identifier as input with the master key such that one or more keys may be created for each contactless card[; i]n some examples, these diversified keys may comprise a first key and a second key[; t]he first key may include an authentication master key (Card Cryptogram Generation/Authentication Key-Card-Key-Auth)[; t]he second key may comprise an encryption master key (Card Data Encryption Key-Card-Key-DEK)[; t]he first and second keys may be used by the one or more applets 240 to generate session keys that may be used to generate a MAC cryptogram, authenticate the card, and to encipher it, respectively[; i]n some examples, the first and the second keys may be created by diversifying the issuer master keys by combining them with the card's unique ID number (pUID) and the PAN sequence number (PSN) of a payment applet, as specified in EMV key diversion algorithm Option A of EMV 4.3 Book 2 A1.4 Master Key Derivation[; t]he pUID may comprise a 16-digit numerical value[; t]he pUID may comprise a 16-digit BCD encoded number[; i]n some examples, pUID may comprise a 14-digit numerical value" par. [0052] or "[r]egarding master key management, two issuer master keys may be required for each part of the portfolio on which the one or more applets is issued[; f]or example, the first master key may comprise an Issuer Cryptogram Generation/Authentication Key (Iss-Key-Auth) and the second master key may comprise an Issuer Data Encryption Key (Iss-Key-DEK)[; i]n some examples, a network profile record ID (pNPR) and derivation key index (pDKI), as back office data, may be used to identify which Issuer Master Keys to use in the cryptographic processes for authentication[; t]he system performing the authentication may be configured to retrieve values of pNPR and pDKI for a contactless card at the time of authentication" par. [0053] or "to complete a payment transaction with a card issuer/payment processor per se, some data values are not needed, and authentication may be performed without involving real-time online connectivity to the card issuer/payment processor[; a]s is known in the art, point of sale (POS) systems submit transactions including a transaction value to a card issuer[; w]hether the issuer approves or denies the transaction may be based on if the card issuer recognizes the transaction value[; m]eanwhile, in certain embodiments of the present disclosure, transactions originating from a mobile device lack the transaction value associated with the POS systems[; t]herefore, in some embodiments, a dummy transaction value (i.e., a value recognizable to the card issuer and sufficient to allow activation to occur) may be passed as part of the example authentication communication protocol" par. [0083])
• 14 ¶ 3 • reviving, by the PSP computing device, an authorization reply from the financial institution; and Reference (ILINCIC: discloses e.g. "[f]IG. 1D depicts an embodiment where additional verification is required to process the transaction requested by the user of mobile device 110-1 in FIG. 1B[; i]n some embodiments, the operations performed in FIG. 1D are in addition to the operations performed in FIGS. 1B and 1C[; i]n other embodiments, the operations performed in FIG. 1D are in addition to the operations performed in FIG. 1B[; f]or the purpose of illustration, and not limitation, FIG. 1D is discussed with respect to embodiments where the operations performed in FIG. 1D are in addition to the operations performed in FIGS. 1B and 1C" par. [0032] and "as shown, the contactless card 101 is tapped to mobile device 110-1[; t]he contactless card 101 may belong to the user of mobile device 110-2 (e.g., the payor's contactless card)[; i]n response, the contactless card 101 follows the encryption procedure detailed above (e.g., using the master key 105, counter 104, and diversified key 106) to generate an encrypted data comprising the customer identifier 107, which is then sent to the mobile device 110-1 via NFC[; h]owever, in one embodiment, the contactless card 101 re-transmits the encrypted data transmitted in FIG. 1C[; o]nce received, the account application 113 of the mobile device 110-1 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; t]he server 120 may generally compare the decrypted customer identifier 107 to an expected customer identifier value (e.g., the customer identifier 107 received in from device 110-2 in FIG. 1C, etc.) to approve the transaction[; f]urthermore, in at least one embodiment, upon receiving the data from the mobile device 110-1, the server 120 may determine whether an amount of time that has elapsed since the data received from device 110-2 in FIG. 2B exceeds a threshold amount of time (e.g., 30 seconds)[; d]oing so allows the server 120 to ensure that both users are in proximity of each other and the contactless card 101[; t]he server 120 may then approve and process the payment, and transmit an indication of the same to the mobile devices 110-1 and/or 110-2" par. [0033])
• 14 ¶ 4 • returning, by the PSP computing device, a confirmation of the push P2P fund transfer being complete. Reference (ILINCIC: discloses e.g. "[f]IG. 1C depicts an embodiment where additional verification is required to process the transaction requested by the user of mobile device 110-1 in FIG. 1B[; i]n such an embodiment, as shown, a contactless card 101 is tapped to mobile device 110-2[; t]he contactless card 101 may belong to the user of mobile device 110-2 (e.g., the payor's contactless card)[; i]n response, the contactless card 101 follows the encryption procedure detailed above with reference to FIG. 1A (e.g., using the master key 105, counter 104, and diversified key 106) to generate encrypted data comprising the customer identifier 107[; t]he contactless card 101 may transmit the generated encrypted data to the mobile device 110-2, which receives the encrypted data via the NFC card reader 118[; o]nce received, the account application 113 of the mobile device 110-2 transmits the encrypted data to the server 120, which verifies the encrypted data as described above (e.g., using the master key 105, counter 104, and diversified key 106)[; u]pon decrypting the data received from the mobile device 110-2, the server 120 may compare the customer identifier 107 to an expected customer identifier value (e.g., a customer identifier provided by the account application 113, a customer identifier stored in the account data 124, etc.)[; u]pon verifying the presence of the contactless card 101 associated with the payor's account, the server 120 may approve and process the payment, and transmit an indication of the same to the mobile devices 110-1 and/or 110-2" par. [0030])
Claim 15, EXAMINER's Analysis: Claim 15 is rejected as being anticipated by ILINCIC. Claim 15 is a dependent claim that directly depends upon parent claim 10, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 10, ILINCIC discloses the claimed subject matter of claim 15 as follows and as explained below.
Regarding and as per CLAIM 15, the computer-implemented method of claim 10, further comprising Reference (ILINCIC: discloses e.g. "[a] computer-implemented method" Claim 1)
• 15 ¶ 2 • determining, by the smartphone mobile device, eligibility of the receiver account to receive the push P2P fund transfer; and Reference (ILINCIC: discloses e.g. "the logic flow 400 begins at block 410, where the account application 113 of the first mobile device 110-1 receives valid authentication credentials for a first user account[; a]s stated, the authentication credentials may include a username/password combination, biometric credentials, or any other type of authentication credentials[; a]t block 420, the account application 113 of the second mobile device 110 receives valid authentication credentials for a second user account[; a]t block 430, the account application 113 of the first mobile device 110-1 generates a request to receive payment from the second account associated with the second mobile device 110-1[; f]or example, the first user may provide input to the account application 113 of the mobile device 110-1 specifying to receive a specified sum (e.g., $50) from the second account of the second user" par. [0072] and "[a]t block 440, the account application 113 of the first mobile device 110-1 transmits the request to the account application 113 of the second mobile device 110-2 when the devices are within NFC communications range[; t]he account application 113 of the second mobile device 110-2 may then output an indication of the requested payment to the second user[; a]t block 450, the account application 113 of the second mobile device 110-2 receives input from the second user approving the requested payment" par. [0073])
• 15 ¶ 3 • wherein initiating the fund transfer is further in response to determining the receiver account is eligible for the push P2P fund transfer. Reference (ILINCIC: discloses e.g. "the management application 123 of the server 120 authorizes the requested payment and processes the payment of funds from the first account to the second account" par. [0074] or "the management application 123 of the server 120 may then process the transfer of funds from the second account to the first account" par. [0080] or "server 120 may [] approve and process the payment" pars. [0030], [0033] and e.g. "[a]t block 460, the account application 113 of the second mobile device 110-2 outputs an indication specifying to tap the contactless card 101 associated with the second account to the second mobile device 110-2[; a]t block 470, the contactless card 101 associated with the second account is tapped to the mobile device 110-2[; d]oing so causes the contactless card 101 to generate encrypted data (e.g., an encrypted customer identifier 107) using the master key 105, counter value 104, and diversified key 106 as described above (e.g., blocks 320-350 of logic flow 300)[; t]he contactless card 101 may then transmit the data (which may include the counter value 104) to the account application 113 of the second mobile device 110-2" par. [0073] and "[a]t block 480, the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 to the management application 123 of the server 120[; t]he account application 113 may further transmit, to the management application 123 of server 120, an indication of the requested payment of funds from the second account to the first account[; a]t block 490, the management application 123 of the server 120 processes the received data to validate the data generated by the contactless card 101 using key diversification (e.g., as described in blocks 360-390 of the logic flow 300)[; t]he management application 123 of the server 120 may further identify the indication of the requested payment, which may be processed once the server validates the data generated by the contactless card 101[; a]t block 495, the management application 123 of the server 120 authorizes the requested payment and processes the payment of funds" par. [0074])
Claim 16, EXAMINER's Analysis: Claim 16 is rejected as being anticipated by ILINCIC. Claim 16 is a dependent claim that directly depends upon parent claim 10, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 10, ILINCIC discloses the claimed subject matter of claim 16 as follows and as explained below.
Regarding and as per CLAIM 16, the computer-implemented method of claim 10, See Prior Comment(s) at Claim 11 Par. 1;
• 16 ¶ 2 • wherein the contactless device is a contactless card device. Reference (ILINCIC: discloses e.g. "the account application 113 transmits the encrypted data received from the contactless card 101 prior to transmitting a request to process the transaction[; i]n other embodiments, e.g., the embodiment depicted in FIG. 1C, the account application 113 transmits the encrypted data received from the contactless card 101 subsequent to transmitting a request to process the transaction[; f]urthermore, any of the mobile devices 110-1, 110-2 may initiate the transfer request[; f]or example, the user of mobile device 110-2 may specify to pay the user of mobile device 110-1, and the "tap" of the mobile devices when in NFC communications range provides the account application 113 of mobile device 110-2 with the account information of the user of mobile device 110-1 necessary to submit, approve, and process the transaction" par. [0031] and e.g. "[f]IG. 2A illustrates a contactless card 101, which may comprise a payment card, such as a credit card, debit card, and/or a gift card[; a]s shown, the contactless card 101 may be issued by a service provider 205 displayed on the front or back of the card 101[; i]n some examples, the contactless card 101 is not related to a payment card, and may comprise, without limitation, an identification card[; i]n some examples, the payment card may comprise a dual interface contactless payment card[; t]he contactless card 101 may comprise a substrate 210, which may include a single layer or one or more laminated layers composed of plastics, metals, and other materials[; e]xemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyesters, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials[; i]n some examples, the contactless card 101 may have physical characteristics compliant with the ID-1 format of the ISO/IEC 7810 standard, and the contactless card may otherwise be compliant with the ISO/IEC 14443 standard[; h]owever, it is understood that the contactless card 101 according to the present disclosure may have different characteristics, and the present disclosure does not require a contactless card to be implemented in a payment card" par. [0034])
Claim 17, EXAMINER's Analysis: Claim 17 is rejected as being anticipated by ILINCIC. Claim 17 is a dependent claim that directly depends upon parent claim 16, which is also a dependent claim, and thus the instant claim indirectly depends upon claim 10, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claims 16 and 10, ILINCIC discloses the claimed subject matter of claim 17 as follows and as explained below.
Regarding and as per CLAIM 17, the computer-implemented method of claim 16, Reference (ILINCIC: discloses e.g. "[a] computer-implemented method" Claim 1)
• 17 ¶ 2 • wherein the contactless card device is a plastic, passive NFC-enabled card device, consistent with the ISO/IEC 7810 standard. Reference (ILINCIC: discloses e.g. "[f]IG. 2A illustrates a contactless card 101, which may comprise a payment card, such as a credit card, debit card, and/or a gift card[; a]s shown, the contactless card 101 may be issued by a service provider 205 displayed on the front or back of the card 101[; i]n some examples, the contactless card 101 is not related to a payment card, and may comprise, without limitation, an identification card[; i]n some examples, the payment card may comprise a dual interface contactless payment card[; t]he contactless card 101 may comprise a substrate 210, which may include a single layer or one or more laminated layers composed of plastics, metals, and other materials[; e]xemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyesters, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials[; i]n some examples, the contactless card 101 may have physical characteristics compliant with the ID-1 format of the ISO/IEC 7810 standard, and the contactless card may otherwise be compliant with the ISO/IEC 14443 standard[; h]owever, it is understood that the contactless card 101 according to the present disclosure may have different characteristics, and the present disclosure does not require a contactless card to be implemented in a payment card" par. [0034] and e.g. "the coil of contactless card 101 may act as the secondary of an air core transformer[; t]he terminal may communicate with the contactless card 101 by cutting power or amplitude modulation[; t]he contactless card 101 may infer the data transmitted from the terminal using the gaps in the contactless card's power connection, which may be functionally maintained through one or more capacitors[; t]he contactless card 101 may communicate back by switching a load on the contactless card's coil or load modulation[; l]oad modulation may be detected in the terminal's coil through interference[; m]ore generally, using the antennas 255, processing circuitry 225, and/or the memory 102, the contactless card 101 provides a communications interface to communicate via NFC, Bluetooth, and/or Wi-Fi communications" par. [0041])
Claim 18, EXAMINER's Analysis: Claim 18 is rejected as being anticipated by ILINCIC. Claim 18 is a dependent claim that directly depends upon parent claim 10, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 10, ILINCIC discloses the claimed subject matter of claim 18 as follows and as explained below.
Regarding and as per CLAIM 18, the computer-implemented method of claim 10, See Prior Comment(s) at Claim 11 Par. 1;
• 18 ¶ 2 • wherein the contactless device is a NFC-enabled fob, tag, or sticker. Reference (ILINCIC: discloses "e.g[; t]he contactless cards 101 may comprise one or more chips (not depicted), such as a radio frequency identification (RFID) chip, configured to communicate with the mobile devices 110 via NFC, the EMV standard, or other short-range protocols in wireless communication, or using NFC Data Exchange Format (NDEF) tags" par. [0017] or "[n]FC data transfer between the contactless card 101 and the card reader 118 of the mobile device 110[; a]fter communication has been established between mobile device 110 and contactless card 101, the contactless card 101 generates a message authentication code (MAC) cryptogram[; i]n some examples, this may occur when the contactless card 101 is read by the account application 113[; i]n particular, this may occur upon a read, such as an NFC read, of a near field data exchange (NDEF) tag" par. [0023] or "contactless cards 101 may be built on a software platform operable on smart cards or other devices having limited memory, such as JavaCard, and one or more or more applications or applets may be securely executed[; a]pplets may be added to contactless cards to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases[; a]pplets may be configured to respond to one or more requests, such as near field data exchange requests, from a reader, such as a mobile NFC reader (e.g., of the mobile device 110), and produce an NDEF message that comprises a cryptographically secure OTP encoded as an NDEF text tag" par. [0042] or "to emulate an RFID tag[; t]he RFID tag may include one or more polymorphic tags[; i]n some examples, each time the tag is read, different cryptographic data is presented that may indicate the authenticity of the contactless card[; b]ased on the one or more applications, an NFC read of the tag may be processed, the data may be transmitted to a server, such as the server 120, and the data may be validated at the server" par. [0046] or "[n]FC may be enabled and the device 110 may be configured to read available tags" par. [0049] or "the contactless card can recognize the [] operating system and transmit data appropriate data to communicate with this device[; f]or example, the contactless card 101 can provide the encrypted identity information necessary to authenticate the card using NDEF tags via, e.g., NFC" par. [0085])
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:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
2-nd Prior Art Category: Claims 5 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over ILINCIC in view of U.S. Patent Application Publication No. US 2008/0249930 A1 of Hill; Dennis J. et al., (hereinafter "HILL").
Claim 5, EXAMINER's Analysis: Claim 5 is rejected as being unpatentable over ILINCIC and HILL. Claim 5 is a dependent claim that directly depends upon parent claim 1, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 1, the combined disclosures and teachings of ILINCIC and HILL taken together render obvious the claimed subject matter of claim 5 as follows and as explained below.
Regarding and as per CLAIM 5, the computer-implemented method of claim 1, See Prior Comment(s) at Claim 2 Par. 1;
• 5 ¶ 2 • wherein the destination account is issued by a financial institution in a foreign country; and Reference (ILINCIC: discloses e.g. "for the contactless card 101, a different unique identifier is derived which may be related to the application primary account number (PAN) and PAN sequence number, which is encoded in the card[; t]he key diversification may be configured to receive the identifier as input with the master key such that one or more keys may be created for each contactless card[; i]n some examples, these diversified keys may comprise a first key and a second key[; t]he first key may include an authentication master key (Card Cryptogram Generation/Authentication Key-Card-Key-Auth)[; t]he second key may comprise an encryption master key (Card Data Encryption Key-Card-Key-DEK)[; t]he first and second keys may be used by the one or more applets 240 to generate session keys that may be used to generate a MAC cryptogram, authenticate the card, and to encipher it, respectively[; i]n some examples, the first and the second keys may be created by diversifying the issuer master keys by combining them with the card's unique ID number (pUID) and the PAN sequence number (PSN) of a payment applet, as specified in EMV key diversion algorithm Option A of EMV 4.3 Book 2 A1.4 Master Key Derivation[; t]he pUID may comprise a 16-digit numerical value[; t]he pUID may comprise a 16-digit BCD encoded number[; i]n some examples, pUID may comprise a 14-digit numerical value" par. [0052] or "[r]egarding master key management, two issuer master keys may be required for each part of the portfolio on which the one or more applets is issued[; f]or example, the first master key may comprise an Issuer Cryptogram Generation/Authentication Key (Iss-Key-Auth) and the second master key may comprise an Issuer Data Encryption Key (Iss-Key-DEK)[; i]n some examples, a network profile record ID (pNPR) and derivation key index (pDKI), as back office data, may be used to identify which Issuer Master Keys to use in the cryptographic processes for authentication[; t]he system performing the authentication may be configured to retrieve values of pNPR and pDKI for a contactless card at the time of authentication" par. [0053] or "to complete a payment transaction with a card issuer/payment processor per se, some data values are not needed, and authentication may be performed without involving real-time online connectivity to the card issuer/payment processor[; a]s is known in the art, point of sale (POS) systems submit transactions including a transaction value to a card issuer[; w]hether the issuer approves or denies the transaction may be based on if the card issuer recognizes the transaction value[; m]eanwhile, in certain embodiments of the present disclosure, transactions originating from a mobile device lack the transaction value associated with the POS systems[; t]herefore, in some embodiments, a dummy transaction value (i.e., a value recognizable to the card issuer and sufficient to allow activation to occur) may be passed as part of the example authentication communication protocol" par. [0083]); (ILINCIC: doesn't expressly and explicitly recite in a foreign country; and --- however HILL: clearly discloses, teaches, and/or suggests the feature -- e.g. "two such FIs are shown in FIG. 1, namely the financial institution (sending FI 104) that issued the payment card account of the sender of a remittance, and the financial institution (receiving FI 106) that issued the payment card account of the recipient of the remittance[; a]s indicated respectively at 108 and 110, the sending FI 104 and the receiving FI 106 are both connected by suitable data communication paths to the payment system 102[; i]t may be assumed that the receiving FI 106 is located in a different country from FI 104 so that any remittance transmitted between the two FIs 104, 106 is an international remittance" par. [0032] or "[f]or purposes of FIG. 2, it may be assumed that the acquiring FI 202 and the funding FI 204 may be in the same country, and that the receiving FI 106 is in a different country, such that a funds transfer originating from acquiring FI 202 and funded through the sender's payment card account at funding FI 204, and routed via the payment system 102 to the receiving FI 106, is an international remittance[; a]lternatively, for example, all three FIs depicted in FIG. 2 may be in mutually different countries from each other[; a]s another alternative, funding FI 204 and receiving FI 106 may be in the same country, and acquiring FI 202 may be in a different country[; s]till another possibility may be that the acquiring FI 202 and the receiving FI 106 are in the same country and the funding FI 204 may be in a different country" par. [0038] or "sending FI for purposes of illustration) which is located in country X and has an established relationship both with the MNO 302 and with an existing payment system 306 such as the Banknet system that was previously referred to[; s]imilarly, the remittance system 100 b incorporates an MNO 308 that operates a mobile network and as an RSP in country Y (a different country from country X)[; a]lso in country Y is another FI 310 that has established relationships with the MNO 308 and with the payment system 306" par. [0040] or "[a] funds transfer system comprising: a first mobile telephone; a first mobile telephone operating company operating in a first country for providing telephone services to the first mobile telephone and other mobile telephones; a first financial institution located in the first country for exchanging data communications regarding funds transfer requests with the first mobile telephone operating company, the first financial institution having the owner of the first mobile telephone as a registered customer; a second mobile telephone; a second mobile telephone operating company operating in a second country, different from the first country, for providing telephone services to the second mobile telephone and other mobile telephones; a second financial institution located in the second country for exchanging data communications regarding funds transfer requests with the second mobile telephone company, the second financial institution having the owner of the second mobile telephone as a registered customer; and a payment processing network operating company for transferring funds from the first financial institution to the second financial institution to benefit the owner of the second mobile telephone at the request of the owner of the first mobile telephone" Claim 12; See also "first financial institution [] in [] first country [] second financial institution [] in [] second country" Claims 11-12, 20), [See Remarks Below]
With respect to above-noted claimed element "a financial institution in a foreign country" which is disclosed by HILL: the teachings and/or suggestions within the disclosure of ILINCIC thus far relied upon fails to include within its explanations an explicit and express recital of a financial institution in a foreign country as required by the instant claim. However, herein relied upon are portions of the disclosure of HILL which sufficiently teaches the feature apposite to the claimed invention as commented about above with reference(s) to exemplary disclosures within HILL that teach and/or suggest the claimed feature. At the time of effective filing date, it would have been obvious for one of ordinary skill in the art to have modified the relied upon teachings of ILINCIC by adding or substituting the feature a financial institution in a foreign country as taught and/or suggested by HILL, with a reasonable expectation of success of arriving at the claimed invention. The addition or substitution of this known feature by one of ordinary skill in the art at the time of the effective filing date would have yielded predictable results that were simply ascertainable to that ordinarily skilled one person in the art at that time. At the time of the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to have modified the teachings of ILINCIC with these aforementioned teachings of "a financial institution in a foreign country" sufficiently taught, suggested, and/or disclosed in HILL because that one skilled artisan having ordinary skill in the art at the time of the effective filing date of the invention would have had a motivation of e.g. "[f]ormal commercial remittance channels are generally labor-intensive and expensive to use[; m]any people who send or receive remittances may lack ongoing relationships with banks or other financial institutions and therefore face additional transaction costs in connection with remittances[; i]nformal channels for remittances are also labor-intensive and may not provide adequate protection for the funds remitted[; m]any of the people who make or receive international remittances are not wealthy and can ill-afford the costs and risks presented by conventional remittance channels", (HILL: par. [0004]); or "[m]ore generally, senders and recipients of remittances frequently find conventional remittance channels to be time-consuming and inconvenient[; i]t is not unusual for the sender to be required to bring cash to a store operated by a remittance services provider (RSP)[; a]ccordingly, the sender is constrained to accommodate himself or herself to the store's operating hours, must carry cash on his or her person, and may have to wait in line or otherwise experience poor service at the RSP's store[; t]he recipient also may be required to pick up the remitted funds at an RSP's store, thereby possibly suffering the same disadvantages and inconveniences that the sender was subject to". (HILL: par. [0005]).
• 5 ¶ 3 • wherein initiating the fund transfer includes initiating the fund transfer from the source account to an intermediate financial institution in the foreign country, whereby the intermediate financial institution initiates the fund transfer to the destination account. Reference (ILINCIC: discloses e.g. "[a]t block 480, the account application 113 of the second mobile device 110-2 transmits the data received from the contactless card 101 to the management application 123 of the server 120[; t]he account application 113 may further transmit, to the management application 123 of server 120, an indication of the requested payment of funds from the second account to the first account[; a]t block 490, the management application 123 of the server 120 processes the received data to validate the data generated by the contactless card 101 using key diversification (e.g., as described in blocks 360-390 of the logic flow 300)[; t]he management application 123 of the server 120 may further identify the indication of the requested payment, which may be processed once the server validates the data generated by the contactless card 101[; a]t block 495, the management application 123 of the server 120 authorizes the requested payment and processes the payment of funds from the first account to the second account" par. [0074]); (ILINCIC: doesn't expressly and explicitly recite to an intermediate financial institution in the...the fund transfer to the destination account. --- however HILL: clearly discloses, teaches, and/or suggests the feature -- e.g. "two such FIs are shown in FIG. 1, namely the financial institution (sending FI 104) that issued the payment card account of the sender of a remittance, and the financial institution (receiving FI 106) that issued the payment card account of the recipient of the remittance[; a]s indicated respectively at 108 and 110, the sending FI 104 and the receiving FI 106 are both connected by suitable data communication paths to the payment system 102[; i]t may be assumed that the receiving FI 106 is located in a different country from FI 104 so that any remittance transmitted between the two FIs 104, 106 is an international remittance" par. [0032] or "[f]or purposes of FIG. 2, it may be assumed that the acquiring FI 202 and the funding FI 204 may be in the same country, and that the receiving FI 106 is in a different country, such that a funds transfer originating from acquiring FI 202 and funded through the sender's payment card account at funding FI 204, and routed via the payment system 102 to the receiving FI 106, is an international remittance[; a]lternatively, for example, all three FIs depicted in FIG. 2 may be in mutually different countries from each other[; a]s another alternative, funding FI 204 and receiving FI 106 may be in the same country, and acquiring FI 202 may be in a different country[; s]till another possibility may be that the acquiring FI 202 and the receiving FI 106 are in the same country and the funding FI 204 may be in a different country" par. [0038] or "sending FI for purposes of illustration) which is located in country X and has an established relationship both with the MNO 302 and with an existing payment system 306 such as the Banknet system that was previously referred to[; s]imilarly, the remittance system 100 b incorporates an MNO 308 that operates a mobile network and as an RSP in country Y (a different country from country X)[; a]lso in country Y is another FI 310 that has established relationships with the MNO 308 and with the payment system 306" par. [0040] or "[a] funds transfer system comprising: a first mobile telephone; a first mobile telephone operating company operating in a first country for providing telephone services to the first mobile telephone and other mobile telephones; a first financial institution located in the first country for exchanging data communications regarding funds transfer requests with the first mobile telephone operating company, the first financial institution having the owner of the first mobile telephone as a registered customer; a second mobile telephone; a second mobile telephone operating company operating in a second country, different from the first country, for providing telephone services to the second mobile telephone and other mobile telephones; a second financial institution located in the second country for exchanging data communications regarding funds transfer requests with the second mobile telephone company, the second financial institution having the owner of the second mobile telephone as a registered customer; and a payment processing network operating company for transferring funds from the first financial institution to the second financial institution to benefit the owner of the second mobile telephone at the request of the owner of the first mobile telephone" Claim 12; See also "first financial institution [] in [] first country [] second financial institution [] in [] second country" Claims 11-12, 20), [See Remarks Below]
With respect to above-noted claimed elements [1] "an intermediate financial institution in the foreign country," and [2] "the intermediate financial institution initiates the fund transfer to the destination" which are disclosed by HILL: the teachings and/or suggestions within the disclosure of ILINCIC thus far relied upon omits to mention within its explanations an explicit and express recitation of [1] "an intermediate financial institution in the foreign country," and [2] "the intermediate financial institution initiates the fund transfer to the destination" as required by the claim under examination. Nonetheless, herein relied upon are portions of the disclosure of HILL which sufficiently teaches the features apposite to the claimed invention as commented about above with reference(s) to exemplary disclosures within HILL that teach and/or suggest the claimed features. At the time of effective filing date, it would have been obvious for one of ordinary skill in the art to have modified the relied upon teachings of ILINCIC by adding or substituting the features [1] "an intermediate financial institution in the foreign country," and [2] "the intermediate financial institution initiates the fund transfer to the destination" as taught and/or suggested by HILL, with a reasonable expectation of success of arriving at the claimed invention. The addition or substitution of these known features by one of ordinary skill in the art at the time of the effective filing date would have yielded predictable results that were plainly reckonable to that one person of ordinary skill in the art at that time. At the time of the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to have modified the teachings of ILINCIC with these aforementioned teachings of [1] "an intermediate financial institution in the foreign country," and [2] "the intermediate financial institution initiates the fund transfer to the destination" sufficiently taught, suggested, and/or disclosed in HILL because that skilled one artisan having ordinary skill in the art at the time of the effective filing date of the invention would have had a motivation of e.g. "[f]ormal commercial remittance channels are generally labor-intensive and expensive to use[; m]any people who send or receive remittances may lack ongoing relationships with banks or other financial institutions and therefore face additional transaction costs in connection with remittances[; i]nformal channels for remittances are also labor-intensive and may not provide adequate protection for the funds remitted[; m]any of the people who make or receive international remittances are not wealthy and can ill-afford the costs and risks presented by conventional remittance channels", (HILL: par. [0004]); or "[m]ore generally, senders and recipients of remittances frequently find conventional remittance channels to be time-consuming and inconvenient[; i]t is not unusual for the sender to be required to bring cash to a store operated by a remittance services provider (RSP)[; a]ccordingly, the sender is constrained to accommodate himself or herself to the store's operating hours, must carry cash on his or her person, and may have to wait in line or otherwise experience poor service at the RSP's store[; t]he recipient also may be required to pick up the remitted funds at an RSP's store, thereby possibly suffering the same disadvantages and inconveniences that the sender was subject to". (HILL: par. [0005]).
Claim 9, EXAMINER's Analysis: Claim 9 is rejected as being unpatentable over ILINCIC and HILL. Claim 9 is a dependent claim that directly depends upon parent claim 6, which is an independent claim. Further to and in conjunction with the disclosures and teachings of the prior art recited in the parent as applied to the limitations of claim 6, ILINCIC and HILL disclose and render obvious as previously combined the claimed subject matter of claim 9 as follows and as explained below.
Regarding and as per CLAIM 9, the computer-implemented method of claim 6, Reference (ILINCIC: discloses e.g. "[a] computer-implemented method" Claim 1)
• 9 ¶ 2 • wherein the destination account is issued by a financial institution in a foreign country; and See Prior Comment(s) at Claim 5 Par. 2;
• 9 ¶ 3 • wherein the processing network computing device is configured, in order to initiate the fund transfer, to initiate the fund transfer from the source account to an intermediate financial institution in the foreign country, whereby the intermediate financial institution initiates the fund transfer to the destination account. Reference (ILINCIC: discloses e.g. "server 120" pars. [0017], [0020]-[0027], [0029]-[0030], [0033], [0046]-[0047], [0050], [0068]-[0069], [0074], [0078]-[0080], [0095] or "management application 123 of the server 120" pars. [0025], [0069], [0074], [0078]-[0080] or "management application 123" pars. [0020], [0025], [0069]-[0070], [0074], [0078]-[0080], [0102]); (ILINCIC: doesn't expressly and explicitly recite to an intermediate financial institution in the...the fund transfer to the destination account. --- however HILL: clearly discloses, teaches, and/or suggests the feature -- e.g. "two such FIs are shown in FIG. 1, namely the financial institution (sending FI 104) that issued the payment card account of the sender of a remittance, and the financial institution (receiving FI 106) that issued the payment card account of the recipient of the remittance[; a]s indicated respectively at 108 and 110, the sending FI 104 and the receiving FI 106 are both connected by suitable data communication paths to the payment system 102[; i]t may be assumed that the receiving FI 106 is located in a different country from FI 104 so that any remittance transmitted between the two FIs 104, 106 is an international remittance" par. [0032] or "[f]or purposes of FIG. 2, it may be assumed that the acquiring FI 202 and the funding FI 204 may be in the same country, and that the receiving FI 106 is in a different country, such that a funds transfer originating from acquiring FI 202 and funded through the sender's payment card account at funding FI 204, and routed via the payment system 102 to the receiving FI 106, is an international remittance[; a]lternatively, for example, all three FIs depicted in FIG. 2 may be in mutually different countries from each other[; a]s another alternative, funding FI 204 and receiving FI 106 may be in the same country, and acquiring FI 202 may be in a different country[; s]till another possibility may be that the acquiring FI 202 and the receiving FI 106 are in the same country and the funding FI 204 may be in a different country" par. [0038] or "sending FI for purposes of illustration) which is located in country X and has an established relationship both with the MNO 302 and with an existing payment system 306 such as the Banknet system that was previously referred to[; s]imilarly, the remittance system 100 b incorporates an MNO 308 that operates a mobile network and as an RSP in country Y (a different country from country X)[; a]lso in country Y is another FI 310 that has established relationships with the MNO 308 and with the payment system 306" par. [0040] or "[a] funds transfer system comprising: a first mobile telephone; a first mobile telephone operating company operating in a first country for providing telephone services to the first mobile telephone and other mobile telephones; a first financial institution located in the first country for exchanging data communications regarding funds transfer requests with the first mobile telephone operating company, the first financial institution having the owner of the first mobile telephone as a registered customer; a second mobile telephone; a second mobile telephone operating company operating in a second country, different from the first country, for providing telephone services to the second mobile telephone and other mobile telephones; a second financial institution located in the second country for exchanging data communications regarding funds transfer requests with the second mobile telephone company, the second financial institution having the owner of the second mobile telephone as a registered customer; and a payment processing network operating company for transferring funds from the first financial institution to the second financial institution to benefit the owner of the second mobile telephone at the request of the owner of the first mobile telephone" Claim 12; See also "first financial institution [] in [] first country [] second financial institution [] in [] second country" Claims 11-12, 20), [See Remarks after Claim 5 Par. 3 herein]
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
USPGPub No. US 20200126052 A1 by Deliwala; Manish et al. discloses TRANSFERS USING CREDIT ACCOUNTS.
USPGPub No. US 20150134540 A1 by Law; Simon et al. discloses SYSTEMS AND METHODS FOR FACILITATING A TRANSACTION USING A VIRTUAL CARD ON A MOBILE DEVICE.
USPGPub No. US 20130060689 A1 by Oskolkov; Ilya et al. discloses ELECTRONIC MONEY TRANSFER SERVICE.
USPGPub No. US 20180144328 A1 by Finch; Paul et al. discloses SECURE REAL-TIME TRANSACTIONS.
USPGPub No. US 20130041817 A1 by Greenwald; Gary et al. discloses Methods and Systems for Activating an Electronic Payments Infrastructure.
USPGPub No. US 20110196782 A1 by ALLEN; Morgan et al. discloses Transferring Funds Using Mobile Devices.
USPGPub No. US 20240193603 A1 by Wolfs; Rudolph Christian et al. discloses SYSTEMS AND METHODS FOR PERFORMING ATM FUND TRANSFER USING ACTIVE AUTHENTICATION.
USPGPub No. US 20240220946 A1 by Malhotra; Sandeep et al. discloses SYSTEMS AND METHODS FOR USE IN TRANSFERRING FUNDS BETWEEN PAYMENT ACCOUNTS.
USPGPub No. US 20180144327 A1 by Finch; Paul et al. discloses SECURE REAL-TIME TRANSACTIONS.
USPGPub No. US 20120239579 A1 by Wolfs; Rudolph Christian et al. discloses Systems and methods for performing ATM fund transfer using active authentication.
USPGPub No. US 20210342824 A1 by BERGER; Jonathan et al. discloses SYSTEMS AND METHODS FOR PROCESSING FINANCIAL TRANSACTIONS USING COMPROMISED ACCOUNTS.
USPGPub No. US 20180144329 A1 by Finch; Paul et al. discloses SECURE REAL-TIME TRANSACTIONS.
USPGPub No. US 20090119190 A1 by Realini; Carol discloses Virtual Pooled Account for Mobile Banking.
USPGPub No. US 20220114571 A1 by ORTIZ; Edison U. et al. discloses SYSTEMS, METHODS, AND DEVICES FOR SECURE GENERATION AND PROCESSING OF DATA SETS REPRESENTING PRE-FUNDED PAYMENTS.
USPGPub No. US 20230401554 A1 by ORTIZ; Edison U. et al. discloses SYSTEMS, METHODS, AND DEVICES FOR SECURE GENERATION AND PROCESSING OF DATA SETS REPRESENTING PRE-FUNDED PAYMENTS.
USPGPub No. US 20180293573 A1 by ORTIZ; Edison U. et al. discloses SYSTEM AND METHOD FOR LOCATION-BASED TOKEN TRANSACTION PROCESSING.
USPGPub No. US 20220391883 A1 by ORTIZ; Edison U. et al. discloses SYSTEM AND METHOD FOR LOCATION-BASED TOKEN TRANSACTION PROCESSING.
USPGPub No. US 20230267429 A1 by Hecht; Alan W. et al. discloses SYSTEMS AND METHODS FOR FUNDS TRANSFERS VIA A FEDERATED DIRECTORY.
USPGPub No. US 20190156335 A1 by Safak; Ilgin et al. discloses BIN-CONSERVING TOKENIZATION TECHNIQUES GENERATING TOKENS IN REVERSE ORDER AND EMPLOYING COMMON DEVICE PAN WITH DIFFERING PAN SEQUENCE NUMBER VALUES ACROSS TOKEN INSTANCES.
USPGPub No. US 20240249259 A1 by Rappoport; Benjamin discloses TOUCH PHONE TRANSACTIONS.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SLADE E. SMITH whose telephone number is 571- 272-8645. The examiner can normally be reached Monday from 8:00 AM to 5:00 PM and Friday from 8:00 AM to 12:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Matthew S. Gart can be reached on 571-272-3955. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Sincerely,
/SLADE E SMITH/Primary Examiner, Art Unit 3696 07/23/2026
Prosecution Insights