DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
Claims 1-20 are presented for examination. Applicant filed a response to non-final Office action on 12/04/2025 amending claims 1-2, 4, and 8-9. In light of Applicant’s amendments, Examiner has withdrawn the previous objection of claims 2 and 9; and § 101 rejection of claims 1-20. Examiner has, however, established a new § 101 rejection for claims 1-20 and maintained the previous grounds of § 103 rejection of claims 1-20 in the instant Office action. Since the new § 101 rejection was necessitated by Applicant’s amendments and Examiner has maintained the previous grounds of § 103 rejection, the instant rejection of claims 1-20 is FINAL rejection of the claims.
Examiner’s Remarks
§ 101 Rejection:
Applicant argues in pages 9-12 of Applicant’s Remarks:
The instant claims are rooted in payment network technology and provide an improvement over existing payment network technology.
Thus, the claims are directed to a technological improvement in a recognized technological area and satisfy the conditions of Prong 1 of the Alice test.
This gap in network-wide visibility, preventing issuers and cardholders from knowing where payment card details are stored when no transaction has occurred, is a technological problem rooted in payment network infrastructure technology.
The claimed invention, with respect to claims 1 and 9 solves this payment-network-specific problem by utilizing non-financial advice messages (a distinct message type within payment network protocols) to communicate COF relationships established during non-transaction events, thereby extending the payment network's tracking functionality beyond transaction-based monitoring. Claim 13 is directed to a practical application of the purported abstract idea by ultimately, "providing, for display at the GUI for the application, the merchant profiles for each identified merchant such that a cardholder of the particular payment card is aware of which entities are storing the payment card information of the particular payment card, even when no transaction has occurred at that entity."
The instant claims provide technological improvement upon the underlying payment network technology, specifically by changing how the payment network operates to track and communicate COF relationships.
These limitations recite specific technical implementations within payment network infrastructure that distinguish between different types of network events (transaction vs. non- transaction) and utilize specific network message types (non-financial advice messages with COF notices) to solve a technical problem arising in payment network technology/payment network infrastructure.
Therefore, Applicant submits that the instant claims, when considered in ordered combination and the claim is considered as a whole, do integrate the abstract idea into a practical application.
Therefore, even if the Examiner finds that the claims recite a judicial exception in a separate claim element, the identification of all merchants associated with the particular payment card, including any merchants that received the payment card details during non-transaction events and providing, for display at a GUI, the merchant profiles for each identified merchant such that a cardholder of the particular payment card is aware of which entities are storing the payment card information of the particular payment card, even when no transaction has occurred at that entity are both limitations that when considered alone, and when considered within the claim as a whole, are not well-understood, routine, or conventional under Step 2B of the Alice test, and therefore provides an inventive concept. See MPEP 2106.05(d).
Examiner respectfully disagrees. Applicant’s claims recite no technological improvements or technological solution to a problem of technology. Instant claims are recited in high level of abstraction lacking details and specific as to how a technological solution to a problem of technology are carried out. The claims are merely using “a system on a payment network” (independent claim 1), “one or more processors, at least one storage system, instructions stored on at least one storage system, and a payment network” (independent claims 8), and “a storage resource and a graphical user interface” (independent claim 13) in improving a business process or providing a solution to a business problem. Thus, Applicant’s claims are reciting use of technology instead of improvement of technology. As such, Applicant’s claims fail to integrate an abstract idea into a practical solution under Step 2A of the Alice/Mayo Test, and the claims provide additional elements or combination of additional elements that are entirely well-understood, routine, or conventional under Step 2B of the Alice/Mayo Test. Therefore, instant claims 1-20 are not patent eligible under 35 U.S.C. § 101 in view of the Alice/Mayo Test.
§ 103 Rejection:
Applicant argues in pages 13-15 of Applicant’s Remarks:
[1] Turning to the § 103 rejection of claims 1 and 8, Applicant asserts that Dill and Khan, alone or in combination, fail to teach or suggest at least "identifying, by the system on the payment network, from the payment card information, an issuer associated with the payment card details," as recited similarly.
For clarity purposes, Applicant notes that the claim element of the claimed "non-financial advice message" comprises the "payment card information of a payment card." In other words, the payment card information of a payment card was not received with no association to a transaction.
[2] Additionally, Applicant asserts that Khan and Dill, alone or in combination, fail to teach or suggest "sending, by the system on the payment network, a COF message indicating storage of the payment card details at the merchant to the issuer," or "receiving, by the system on the payment network, from the issuer, confirmation that the payment card is recorded as a COF," as recited in claim 1 and similarly recited in claim 8. The Examiner admits that Dill does not show either of these limitations and therefore relies on Khan for teaching these limitations.
[3] Turning to the §103 rejection of claim 13, Applicant asserts that Dill and Khan, alone or in combination, fail to teach or suggest at least "receiving, at a graphical user interface (GUI) for an application, a request to identify entities that have payment card information of the particular payment card stored on file; identifying, from the COF information at the storage resource, all merchants associated with the particular payment card, including any merchants that received the payment card details during non-transaction events; obtaining a merchant profile for each identified merchant associated with the particular payment card," as recited in claim 13.
Examiner respectfully disagrees:
[1] Dill specifically teaches in [0033] that issuers can provision tokens to third parties when customer is enrolling in a payment service; and in [0051] that the token format allows entities in the system to identify issues associated with the token. Further, Dill discloses in [0056] and [0108] that the tokens may be non-payment tokens or payment tokens, and in [0052] that non-payment tokens may comprise issuer identifiers. Thus, Dill discloses:
identifying, by the system on the payment network, from the payment card information, an issuer associated with the payment card details.
[2] Kahn specifically teaches in [0035], [0049], and [0123] storing a card on file (COF) information in datastore, providing information regarding non-payment and payment transactions, and using tokens to represent non-payment transactions. Therefore, Khan discloses:
sending, by the system on the payment network, a COF message indicating storage of the payment card details at the merchant to the issuer; and
receiving, by the system on the payment network, from the issuer, confirmation that the payment card is recorded as a COF.
[3] Dill specifically teaches: using non-payment tokens by merchant and acquirer systems to keep track of transactions in [0007]; registering, by a consumer, with one or more merchants for card-on-file services [0091]; providing an issuer identifier routing table to relevant entities in a payment system [0051], wherein: a card-on-file (COF) holder may include any entity that stores account details (e.g., card details, payment account identifiers, PANs, etc.) for use in the transactions [0081]; a token can support interoperability and can be accepted, processed and routed by the entities (e.g., merchants, acquirer, issuers, processors, networks, etc.) within the payment system [0035]; a registered entity may provide a token requestor identifier, a transaction identifier, a transaction amount, a transaction date and time, a merchant identifier, a merchant address, an MSISDN, a UUID, an IMEL etc. [0118]; and a reporting module may be configured to provide reporting for token payment transactions and it may provide reports for each country and regions based on token attributes such as token number and token ranges, a token requestor identifier, a consumer token assurance level, a token expiration date, a COF (card on file) indicator, and a token presentment mode [0189].
Thus, Dill discloses:
receiving, at a graphical user interface (GUI) for an application, a request to identify entities that have payment card information of the particular payment card stored on file;
identifying, from the COF information at the storage resource, all merchants associated with the particular payment card, including any merchants that received the payment card details during non-transaction events; [and]
obtaining a merchant profile for each identified merchant associated with the particular payment card.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 USC § 101 because they are directed to non-statutory subject matter. The rationale for this finding is explained below.
The Supreme Court in Mayo laid out a framework for determining whether an applicant is seeking to patent a judicial exception itself or a patent-eligible application of the judicial exception. See Alice Corp., 134 S. Ct. at 2355,110 USPQ2d at 1981 (citing Mayo, 566 U.S. 66, 101 USPQ2d 1961). This framework, which is referred to as the Mayo test or the Alice/Mayo test (“the test”), is described in detail in Manual of Patent Examining Procedure (”MPEP”) (see MPEP § 2106(III) for further guidance). The step 1 of the test: It need to be determined whether the claims are directed to a patent eligible (i.e., statutory) subject matter under 35 USC § 101. Step 2A of the test: If the claims are found to be directed to a statutory subject matter, the next step is to determine whether the claims are directed to a judicial exception i.e., law of nature, natural phenomenon, and abstract idea (Prong 1). If the claims are found to be directed to an abstract idea, it needs to be determined whether the claims recite additional elements that integrate the judicial exception into a practical application (Prong 2). Step 2B of the test: If the claims are directed to a judicial exception, the next and final step is to determine whether the claims recite additional elements that amount to significantly more than the judicial exception.
Step 1 of the Test:
When considering subject matter eligibility under 35 USC § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. Here, the claimed invention of claims 1-7 and 13-20 is a series of steps, which is method (i.e., a process) and, thus, one of the statutory categories of invention. Further, the claimed invention of claims 5-12 is a system, which is also one of the statutory categories of invention.
Conclusion of Step 1 Analysis: Therefore, claims 1-20 are statutory under 35 USC § 101 in view of step 1 of the test.
Step 2A of the Test:
Prong 1: Claims 1-20, however, recite an abstract idea of tracking storage of payment card details at various entities. The creation of tracking storage of payment card details at various entities, as recited in the independent claims 1, 8, and 13, belongs to certain methods of organizing human activity (i.e., commercial interactions) that are found by the courts to be abstract ideas. The limitations in independent claims 1, 8, and 13, which set forth or describe the recited abstract idea, are found in the following steps:
“identifying, from the plurality of transaction messages and non-financial advice messages, a non-financial advice message comprising a card-on-file (COF) notice, a merchant identifier (ID), and payment card information of a payment card, wherein the merchant ID corresponds to a merchant that received payment card details comprising the payment card information during a non-transaction event” (claims 1 and 8);
“identifying, from the payment card information, an issuer associated with the payment card details” (claims 1 and 8);
“managing card-on-file (COF) information for payment cards the COF information comprising merchant identifiers (IDs) of merchants storing payment card details of a particular payment card during non-transaction events and merchant IDs of merchants storing the payment card details of the particular payment card as part of a transaction that includes COF authorization” (claim 13); and
“identifying, from the COF information, all merchants associated with the particular payment card, including any merchants that received the payment card details during non-transaction events” (claim 13).
Prong 2: In addition to abstract steps recited above in Prong 1, independent claims 1, 8, and 13, recite additional elements:
“a system on a payment network” (claim 1);
“one or more processors” (claim 8);
“at least one storage system” (claim 8);
“instructions stored on the at least one storage system” (claim 8);
“a payment network” (claim 8);
“a storage resource” (claim 13); and
“a graphical user interface (GUI) for an application” (claim 13).
These additional elements are recited at a high level of generality (e.g., as a generic processor performing a generic computer functions) such that they amount to no more than mere instructions to apply the exception using a generic computer components. Further, the following limitations recite insignificant extra solution activity (for example, data gathering):
“receiving a plurality of transaction messages and non-financial advice messages” (claims 1 and 8);
“sending a COF message indicating storage of the payment card details at the merchant to the issuer” (claims 1 and 8);
“receiving, from the issuer, confirmation that the payment card is recorded as a COF” (claims 1 and 8);
“receiving a request to identify entities that have payment card information of the particular payment card stored on file” (claim 13);
“obtaining a merchant profile for each identified merchant associated with the particular payment card” (claim 13); and
“providing the merchant profiles for each identified merchant such that a cardholder of the particular payment card is aware of which entities are storing the payment card information of the particular payment card, even when no transaction has occurred at that entity” (claim 13).
These additional limitations do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception. The additional elements/limitations of independent claims 1, 8, and 13, here do not render improvements to the functioning of a computer or to any other technology or technical field (see MPEP § 2106.05(a)), nor do they integrate the abstract idea into a practical application under MPEP § 2106.05(b) (particular machine); MPEP § 2106.05(c) (particular transformations); or MPEP § 2106.05(e) (other meaningful limitations). Further, the combination of these additional elements/limitations is no more than mere instructions to apply the exception using a generic device. Accordingly, even in combination, these additional elements/ limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Conclusion of Step 2A Analysis: Therefore, independent claims 1, 8, and 13, are non-statutory under 35 USC § 101 in view of step 2A of the test.
Step 2B of the Test: The additional elements of independent claims 1, 8, and 13, (see above under Step 2A - Prong 2) are described by instant Specification in following terms:
[0108] Referring to Figure 5, operating environment 550 can include a plurality of users 501, including user 501a and user 501b (e.g., user 100 as described with respect to Figures 1, 2A-2B, 3A-3B, and 4A-4E) and various computing systems (e.g., formed of one or more processors, storage systems, networking interfaces and optional user interface components) associated with different entities. These various computing systems include a plurality of user devices, including user device 502a and user device 502b, a plurality of merchant systems 510 (e.g., for merchant 110 as described with respect to Figures 1, 2A-2B, 3A-3B, and 4A-4E), a plurality of acquirer systems 515 (e.g., for acquirer 115 as described with respect to Figures 1, 2A-2B, 3A-3B, and 4A-4E), a payment network 520 (e.g., payment network 120 as described with respect to Figures 1, 2A-2B, 3A-3B, and 4A-4E), a plurality of issuer systems 525, including issuer A 525a, issuer B 525b, and issuer C 525c(e.g., issuer 125 as described with respect to Figures 1, 2A-2B, 3A-3B, and issuer A 126 and issuer B 127 as described with respect to Figures 4A-4E). The operating environment 550 further includes an issuer application 540 (e.g., issuer application 305 as described with respect to Figures 3A- 3B), and a digital wallet application 545 (e.g., digital wallet application 410 as described with respect to Figures 4A-4E), which can be executed at user devices. The payment network 520 can include a COF tracking system 530 (e.g., COF tracking system 200 described with respect to Figures 2A-2B, 3A-3B, and 4A-4E).
This is a description of general-purpose computing system. Thus, individually, the additional elements of independent claims 1, 8, and 13, are well-understood, routine, and conventional elements that amount to no more than implementing the abstract idea with a computerized system. Further, the additional limitations of “receiving,” “sending,” “obtaining,” and “providing” information amount to no more than mere instructions to apply the exception using generic computer components. For the same reason these additional limitations are not sufficient to provide an inventive concept. The additional limitations of “receiving,” “sending,” “obtaining,” and “providing” information were considered as insignificant extra-solution activity in Step 2A - Prong 2. Re-evaluating here in Step 2B, they are also determined to be well-understood, routine, and conventional activity in the field. Similarly to OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network), and 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), the additional limitations of independent claims 1, 8, and 13, “receive,” “send,” “obtain,” and “provide” information over a network in a merely generic manner. Further, similarly to Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015) and OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93, the additional limitations of independent claims 1, 8, and 13, store and retrieve information in memory. The courts have recognized “receiving,” “sending,” “obtaining,” and “providing” information functions as well-understood, routine and conventional when claimed in a merely generic manner. Therefore, the additional limitations of independent claims 1, 8, and 13, are well-understood, routine, and conventional. Further, taken as combination, the additional elements/limitations add nothing more than what is present when the additional elements/limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
Conclusion of Step 2B Analysis: Therefore, independent claims 1, 8, and 13, are non-statutory under 35 USC § 101 in view of step 2B of the test.
Dependent Claims: Dependent claims 2-7 depend on independent claim 1; dependent claims 9-12 depend on independent claim 8; and dependent claims 14-20 depend on independent claim 13. The elements in dependent claims 2-7, 9-12, and 14-20, which set forth or describe the abstract idea, are:
“identifying, from the plurality of transaction messages and non-financial advice messages, a transaction message comprising a COF indicator, a second merchant ID, second payment card information corresponding to a second payment card, and transaction information, wherein the second merchant ID corresponds to a second merchant at which a second payment card is authorized as a COF; identifying, from the second payment card information, a second issuer associated with the second payment card; requesting authorization or preauthorization for a second payment card corresponding to the second payment card information; receiving, from the second issuer, authorization or preauthorization for the second payment card corresponding to the second payment card information; and receiving, from the second issuer, confirmation that the second payment card is recorded as a second COF” (claim 2: where “identifying” steps are further narrowing the recited abstract idea; and where “requesting” and “receiving” steps are insignificant extra solution activity);
“receiving a removal request message indicating that a user is requesting removal of the payment card as a COF at a particular merchant, wherein the removal request message comprises the merchant ID of the merchant; identifying, from the merchant ID, the merchant associated with the merchant ID; and sending a COF removal instruction to the merchant” (claim 3: where “identifying” step is further narrowing the recited abstract idea; and where “receiving” and “sending” steps are insignificant extra solution activity);
“the removal request message is received from the issuer” (claim 4: further narrowing the recited abstract idea);
“the removal request message is received from a digital wallet application” (claim 5: further narrowing the recited abstract idea);
“sending the COF removal instruction to the merchant comprises sending the COF removal instruction via a notification API of the payment network for which the merchant is registered” (claim 6: insignificant extra solution activity);
“sending the COF removal instruction to the merchant comprises sending a non-financial advice message to an acquirer for communicating with the merchant” (claim 7: insignificant extra solution activity);
“identify, from the plurality of transaction messages and non-financial advice messages, a transaction message comprising a COF indicator, a second merchant ID, second payment card information corresponding to a second payment card, and transaction information, wherein the second merchant ID corresponds to a second merchant at which a second payment card is authorized as a COF; identify, from the second payment card information, a second issuer associated with the second payment card; request authorization or preauthorization for a second payment card corresponding to the second payment card information; receive, from the second issuer, authorization or preauthorization for the second payment card corresponding to the second payment card information; and receive, from the issuer, confirmation that the second payment card is recorded as a second COF” (claim 9: where “identifying” steps are further narrowing the recited abstract idea; and where “requesting” and “receiving” steps are insignificant extra solution activity);
“receive a removal request message indicating that a user is requesting removal of the payment card as a COF at a particular merchant, wherein the removal request message comprises the merchant ID of the merchant; identify, from the merchant ID, the merchant associated with the merchant ID; and send a COF removal instruction to the merchant” (claim 10: where “identifying” step is further narrowing the recited abstract idea; and where “receiving” and “sending” steps are insignificant extra solution activity);
“send the COF removal instruction via a notification API of the payment network for which the merchant is registered” (claim 11: insignificant extra solution activity);
“send a non-financial advice message to an acquirer for communicating with the merchant” (claim 12: insignificant extra solution activity);
“receiving, from a payment network, a non-financial advice (NFA) message comprising a COF notice, a first merchant ID, and first payment card information associated with the particular payment card, wherein the first merchant ID corresponds to a first merchant that received payment card details comprising the first payment card information during a non- transaction event; determining that the first merchant associated with the first merchant ID is not listed in the COF information for the particular payment card at the storage resource; storing the first merchant as COF information for the particular payment card at the storage resource; and sending confirmation to the payment network that the particular payment card is recorded as a COF associated with the first merchant” (claim 14: where “determining” step is further narrowing the recited abstract idea; and where “receiving,” “storing,” and “sending” steps are insignificant extra solution activity);
“receiving, from the payment network, an authorization or preauthorization request associated with a transaction made using the particular payment card, the authorization or preauthorization request comprising a COF indicator, a second merchant ID, second payment card information associated with the particular payment card, and transaction information; determining that a second merchant associated with the second merchant ID is not listed in the COF information for the particular payment card at the storage resource; storing the second merchant as COF information for the particular payment card at the storage resource; and sending confirmation to the payment network that the particular payment card is recorded as a COF with the second merchant” (claim 15: where “determining” step is further narrowing the recited abstract idea; and where “receiving,” “storing,” and “sending” steps are insignificant extra solution activity);
“receiving, at the graphical user interface for the application, a command indicating a request to remove the particular payment card as a COF at a selected merchant; and sending a removal request message to a payment network, the removal request message indicating that a user is requesting removal of the particular payment card as a COF at a particular merchant, wherein the removal request message comprises a merchant ID associated with the selected merchant” (claim 16: insignificant extra solution activity);
“the removal request message is a non-financial advice message” (claim 17: further narrowing the recited abstract idea);
“receiving, from the payment network, confirmation that the selected merchant has removed the particular payment card as a COF; updating the COF information for the particular payment card to remove the selected merchant from the COF information for the particular payment card; and providing, for display at the GUI, confirmation that the selected merchant has removed the particular payment card as a COF” (claim 18: where “updating” step is further narrowing the recited abstract idea; and where “receiving” and “providing” steps are insignificant extra solution activity);
“receiving an information request for the COF information for the particular payment card from a payment network to provide the COF information to a digital wallet application, wherein the digital wallet application is storing the particular payment card as a virtual payment card” (claim 19: insignificant extra solution activity); and
“the merchant profile includes a merchant name and context information, and the context information indicates for the cardholder whether the particular payment card was used at the merchant associated with the merchant name during a transaction including COF authorization or during a non-transaction event” (claim 20: further narrowing the recited abstract idea).
Conclusion of Dependent Claims Analysis: Dependent claims 2-7, 9-12, and 14-20, do not correct the deficiencies of independent claims 1, 8, and 13, and they are, thus, rejected on the same basis.
Conclusion of the 35 USC § 101 Analysis: Therefore, claims 1-20 are rejected as directed
to an abstract idea without “significantly more” under 35 USC § 101.
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 § 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Dill (US 2022/0172199 A1) in view of Khan (US 2020/0058047 A1).
As to independent claims 1 and 8
Dill shows:
one or more processors, at least one storage system, and instructions stored on the at least one storage system that when executed by the one or more processors, direct the COF tracking system (Dill: page 13, ¶ 136) to:
identify, from the plurality of transaction messages and non-financial advice messages, a non-financial advice message comprising a card-on-file (COF) notice, a merchant identifier (ID), and payment card information of a payment card, wherein the merchant ID corresponds to a merchant that received payment card details comprising the payment card information during a non-transaction event (Dill: page 1, ¶ 7; pages 2-3, ¶ 33; page 3, ¶ 42; page 4, ¶¶ 51-52; page 5, ¶ 56; page 7, ¶ 81; page 8, ¶ 91; page 10; ¶ 108; page 12, ¶ 126; page 19, ¶ 189; and Fig. 8); and
identify, from the payment card information, an issuer associated with the payment card details (Dill: page 1, ¶ 7; pages 2-3, ¶ 33; page 3, ¶ 42; page 4, ¶¶ 51-52; page 5, ¶ 56; page 7, ¶ 81; page 8, ¶ 91; page 10; ¶ 108; page 12, ¶ 126; page 19, ¶ 189; and Fig. 8).
Dill does not show:
receiving, over a payment network, a plurality of transaction messages and non-financial advice messages;
sending a COF message indicating storage of the payment card details at the merchant to the issuer; and
receiving, from the issuer, confirmation that the payment card is recorded as a COF.
Khan shows:
receiving, over a payment network, a plurality of transaction messages and non-financial advice messages (Khan: page 3, ¶ 35; page 4, ¶ 49; page 11, ¶ 123; and Fig. 1);
sending a COF message indicating storage of the payment card details at the merchant to the issuer (Khan: page 3, ¶ 35; page 4, ¶ 49; page 11, ¶ 123; and Fig. 1); and
receiving, from the issuer, confirmation that the payment card is recorded as a COF (Khan: page 3, ¶ 35; page 4, ¶ 49; page 11, ¶ 123; and Fig. 1).
Motivation to Combine Dill and Khan:
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method and the system of Dill by receiving, over a payment network, a plurality of transaction messages and non-financial advice messages; sending a COF message indicating storage of the payment card details at the merchant to the issuer; and receiving, from the issuer, confirmation that the payment card is recorded as a COF of Khan in order to perform secure mobile payment and non-payment transaction (Khan: page 1, ¶ 2).
As to claims 2 and 9: Dill in view of Khan shows all the elements of claims 1 and 8. Dill also shows identifying, from the plurality of transaction messages and non-financial advice messages, a transaction message comprising a COF indicator, a second merchant ID, second payment card information corresponding to a second payment card, and transaction information, wherein the second merchant ID corresponds to a second merchant at which a second payment card is authorized as a COF; identifying, from the second payment card information, a second issuer associated with the second payment card; requesting authorization or preauthorization for a second payment card corresponding to the second payment card information; receiving, from the second issuer, authorization or preauthorization for the second payment card corresponding to the second payment card information; and receiving, from the second issuer, confirmation that the second payment card is recorded as a second COF (Dill: page 1, ¶ 12; and page 7, ¶ 82).
As to claims 3 and 10: Dill in view of Khan shows all the elements of claims 1 and 8. Dill also shows receiving a removal request message indicating that a user is requesting removal of the payment card as a COF at a particular merchant, wherein the removal request message comprises the merchant ID of the merchant; identifying, from the merchant ID, the merchant associated with the merchant ID; and sending a COF removal instruction to the merchant (Dill: page 3, ¶ 42).
As to claim 4: Dill in view of Khan shows all the elements of claim 3. Dill also shows that the removal request message is received from the issuer (Dill: page 3, ¶ 42).
As to claim 5: Dill in view of Khan shows all the elements of claim 3. Dill also shows that the removal request message is received from a digital wallet application (Dill: page 1, ¶ 11).
As to claims 6 and 11: Dill in view of Khan shows all the elements of claims 3 and 10. Dill also shows that sending the COF removal instruction to the merchant comprises sending the COF removal instruction via a notification API of the payment network for which the merchant is registered (Dill: page 12, ¶ 126).
As to claims 7 and 12: Dill in view of Khan shows all the elements of claims 3 and 10. Dill does not show sending the COF removal instruction to the merchant comprises sending a non-financial advice message to an acquirer for communicating with the merchant. Khan shows sending the COF removal instruction to the merchant comprises sending a non-financial advice message to an acquirer for communicating with the merchant (Khan: page 4, ¶ 49). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method and the system of Dill by sending the COF removal instruction to the merchant comprises sending a non-financial advice message to an acquirer for communicating with the merchant of Khan in order to perform secure mobile payment and non-payment transaction (Khan: page 1, ¶ 2).
As to independent claim 13
Dill shows:
managing, at a storage resource, information for payment cards the COF information comprising merchant identifiers (IDs) of merchants storing payment card details of a particular payment card during events and merchant IDs of merchants storing the payment card details of the particular payment card as part of a transaction that includes COF authorization (Dill: page 1, ¶ 7; pages 2-3, ¶ 33; page 3, ¶ 35 and ¶ 42; page 4, ¶¶ 51-52; page 5, ¶ 56; page 7, ¶ 81; page 8, ¶ 91; page 10; ¶ 108; page 12, ¶ 118 and ¶ 126; page 19, ¶ 189; and Fig. 8);
receiving, at a graphical user interface (GUI) for an application, a request to identify entities that have payment card information of the particular payment card stored on file (Dill: page 1, ¶ 7; pages 2-3, ¶ 33; page 3, ¶ 35 and ¶ 42; page 4, ¶¶ 51-52; page 5, ¶ 56; page 7, ¶ 81; page 8, ¶ 91; page 10; ¶ 108; page 12, ¶ 118 and ¶ 126; page 19, ¶ 189; and Fig. 8);
identifying, from the COF information at the storage resource, all merchants associated with the particular payment card, including any merchants that received the payment card details during non-transaction events (Dill: page 1, ¶ 7; pages 2-3, ¶ 33; page 3, ¶ 35 and ¶ 42; page 4, ¶¶ 51-52; page 5, ¶ 56; page 7, ¶ 81; page 8, ¶ 91; page 10; ¶ 108; page 12, ¶ 118 and ¶ 126; page 19, ¶ 189; and Fig. 8);
obtaining a merchant profile for each identified merchant associated with the particular payment card (Dill: page 1, ¶ 7; pages 2-3, ¶ 33; page 3, ¶ 35 and ¶ 42; page 4, ¶¶ 51-52; page 5, ¶ 56; page 7, ¶ 81; page 8, ¶ 91; page 10; ¶ 108; page 12, ¶ 118 and ¶ 126; page 19, ¶ 189; and Fig. 8); and
providing, for display at the GUI for the application, the merchant profiles for each identified merchant such that a cardholder of the particular payment card is aware of which entities are storing the payment card information of the particular payment card, even when no transaction has occurred at that entity (Dill: page 1, ¶ 7; pages 2-3, ¶ 33; page 3, ¶ 35 and ¶ 42; page 4, ¶¶ 51-52; page 5, ¶ 56; page 7, ¶ 81; page 8, ¶ 91; page 10; ¶ 108; page 12, ¶ 118 and ¶ 126; page 19, ¶ 189; and Fig. 8).
Dill does not show:
a storage resource including a card on file (COF) information; and
the events being non-payment transactions.
Khan shows:
a storage resource including a card on file (COF) information (Khan: page 3, ¶ 35; page 11, ¶ 123; and Fig. 1); and
the events being non-payment transactions (Khan: page 3, ¶ 35; page 11, ¶ 123; and Fig. 1).
Motivation to combine Dill and Khan:
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Dill by a storage resource including a card on file (COF) information; and the events being non-payment transactions of Khan in order to perform secure mobile payment and non-payment transaction (Khan: page 1, ¶ 2).
As to claim 14: Dill in view of Khan shows all the elements of claim 13. Dill also shows receiving, from a payment network, a non-financial advice (NFA) message comprising a COF notice, a first merchant ID, and first payment card information associated with the particular payment card, wherein the first merchant ID corresponds to a first merchant that received payment card details comprising the first payment card information during a non- transaction event; determining that the first merchant associated with the first merchant ID is not listed in the COF information for the particular payment card at the storage resource;
storing the first merchant as COF information for the particular payment card at the storage resource; and sending confirmation to the payment network that the particular payment card is recorded as a COF associated with the first merchant (Dill: page 7, ¶ 81; page 8, ¶ 91; and page 12, ¶ 126).
As to claim 15: Dill in view of Khan shows all the elements of claim 14. Dill also shows receiving, from the payment network, an authorization or preauthorization request associated with a transaction made using the particular payment card, the authorization or preauthorization request comprising a COF indicator, a second merchant ID, second payment card information associated with the particular payment card, and transaction information; determining that a second merchant associated with the second merchant ID is not listed in the COF information for the particular payment card at the storage resource; storing the second merchant as COF information for the particular payment card at the storage resource; and sending confirmation to the payment network that the particular payment card is recorded as a COF with the second merchant (Dill: page 1, ¶ 7 and ¶ 12; and Fig. 8).
As to claim 16: Dill in view of Khan shows all the elements of claim 13. Dill also shows receiving, at the graphical user interface for the application, a command indicating a request to remove the particular payment card as a COF at a selected merchant; and sending a removal request message to a payment network, the removal request message indicating that a user is requesting removal of the particular payment card as a COF at a particular merchant, wherein the removal request message comprises a merchant ID associated with the selected merchant (Dill: page 3, ¶ 42).
As to claim 17: Dill in view of Khan shows all the elements of claim 16. Dill also shows that the removal request message is a non-financial advice message (Dill: page 1, ¶ 7 and ¶ 12; and Fig. 8).
As to claim 18: Dill in view of Khan shows all the elements of claim 16. Dill also shows receiving, from the payment network, confirmation that the selected merchant has removed the particular payment card as a COF; updating the COF information for the particular payment card to remove the selected merchant from the COF information for the particular payment card; and providing, for display at the GUI, confirmation that the selected merchant has removed the particular payment card as a COF (Dill: page 7, ¶ 81; page 8, ¶ 91; and page 12, ¶ 126).
As to claim 19: Dill in view of Khan shows all the elements of claim 13. Dill also shows receiving an information request for the COF information for the particular payment card from a payment network to provide the COF information to a digital wallet application, wherein the digital wallet application is storing the particular payment card as a virtual payment card (Dill: page 1, ¶ 11).
As to claim 20: Dill in view of Khan shows all the elements of claim 13. Dill also shows that the merchant profile includes a merchant name and context information, wherein the context information indicates for the cardholder whether the particular payment card was used at the merchant associated with the merchant name during a transaction including COF authorization or during a non-transaction event (Dill: page 12, ¶ 118).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bussolotti (WO 2025006236 A1) discloses: “A method of enrolling a payment card as a card on file by a payment processing platform. The method comprising the steps of: receiving, from a card issuer platform associated with the payment card, a registration request comprising data associated with the payment card; storing, on a secure storage means, the data associated with the payment card; sending, to the card issuer platform, a registration receipt; receiving, from a merchant platform, the registration receipt; generating a merchant token; and sending, to the merchant platform, the merchant token useable as a card on file.”
Duffy (EP 3712828 A1) discloses: “A method of obtaining tokenized payment card data at a computing device for use in a transaction, the computing device comprising a digital wallet containing a preregistered payment card, the method comprising: receiving, at the computing device, a request for tokenized payment card data corresponding to the preregistered payment card; sending, from the computing device to a token service provider, the request for tokenized payment card data; receiving, from the token service provider, tokenized payment data corresponding to the preregistered payment card, the tokenized payment card data being suitable for use in the transaction; using the received tokenized payment card data to complete the transaction.”
Plateaux, Aude, et al. "A comparative study of card-not-present e-commerce architectures with card schemes: What about privacy?." Journal of information security and applications 40 (2018): 103-110.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIRPI H. KANERVO whose telephone number is 571-272-9818. The examiner can normally be reached on Monday – Friday, 10 am – 6 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Abhishek Vyas can be reached on 571-270-1836. 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.
/VIRPI H KANERVO/Primary Examiner, Art Unit 3691