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 .
This written action is responding to the amendment dated on 04/22/2026.
Claims 1, 10 and 15 have been amended, Claim 6 has been canceled and Claim 21 is newly added. All other Claims are previously presented.
Claims 1-5 and 7-21 are submitted for examination.
Claims 1-5 and 7-21 are pending.
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.
Priority
This application filed on September 23, 2024 claims priority of Provisional application 63/657,696 filed on June 07, 2024.
Information Disclosure Statement
The following Information Disclosure Statements in the instant application submitted in compliance with the provisions of 37 CFR 1.97, and thus, have been fully considered:
IDS filed on 06 November 2025.
IDS filed on 04 February 2026.
IDS filed on 22 April 2026.
Response to Arguments
Applicant’s amendment, filed on April 22, 2026, has claims 1, 10 and 15 amended, claim 21 newly added and all other claims previously presented. Among the amended claims, claim 1, 10 and 15 are independent ones, and thus, the amendment necessitates a new ground of rejection.
The prior 35 U.S.C. 101 rejection of Claims 15-20 has been withdrawn in view of the amendment received on April 22, 2026.
Applicant’s remark, filed on April 22, 2026 on top of page 9 regarding, “The independent claims have been amended to recite, in pertinent part, "determining, by the application, a data exchange account associated with a third party service provider, the data exchange account comprising a default data exchange option" and "obtaining, by the application from a server device, a data exchange option corresponding to the data exchange account and provided by the third party service provider, the data exchange option different from the default data exchange option and comprising information usable by the third party service provider to validate a data cryptogram transmitted from the application to the terminal device according to a first validation process, wherein the first validation process is different from a default validation process for validating data cryptograms transmitted from the application to the terminal device." Applicant respectfully submits that neither Law nor Ludin teach or make obvious at least these elements of the amended claims” has been considered and found persuasive, however updated search resulted in a newly found art by Pirillo (US PGPUB. # US 2019/0325472) discloses, “the mobile rewards application 105 requests a points update 134 from the mobile rewards control center 102. The center 102 in turn requests and obtains a points update 131 from the loyalty platform 107 or 108. The mobile rewards control center 102 sends the points update confirmation data to the mobile rewards application 105. The data includes member 115 profile information including current points balance. The points update request 134 is initiated automatically upon each instance the mobile rewards application 105 is started or upon a specific request by the member via the mobile device 115. The application 105 presents the member via the member's device 115 with the available redemption retailers 122 participating in the program 107, 108, which retailers 122 may be indicated by a filter applied to the ghost card 121. The application 105 also presents the member via the member's device 115 with the available funds based on the amount of points indicated by the points update confirmation data and based on an individual currency exchange rate of points to currency according to the loyalty platform 107, 108. The individual currency exchange rate may be part of the confirmation data or it may be embedded in the application 105. The mobile rewards control center 102 will store all details associated to the individual client programs 107 or 108, as well as participating redemption retailers 122. Also, the center may store the individual currency exchange rate and provide it to the application 105”. (¶30-¶31). “The application 115 presents the member with the retailer 122 specific redemption options or offerings at 404 and the points value for each, e.g., redeem 1200 points for $100 at Retailer ‘A’ or redeem 700 points for $500 at Retailer ‘A’. In one embodiment, the member can select the number of points to be redeemed or the member can select a dollar value to be applied to the debit/credit account.” (¶33). The mobile rewards management system 100 confirms that the member 115 has sufficient points by requesting a points check with the loyalty platform 107, 108, and requests a confirmation 132 that the member is in good standing at 408. The mobile rewards management system 100 deducts the redeemed points 133 from the members account 107, 108. The mobile rewards management system 100 sends via the control center 102 a currency request 128 to the administrator's card management system 101 to issue the redeemed for dollar value to the ghost card 121. The prepaid card management system 101 issues the dollar value to the member's ghost card account 121 making the monies available for the transaction. The prepaid card management system 101 confirms at 129 that the monies have been successfully deposited into the members account associated with their ‘ghost’ card 121. The mobile rewards management system 100 confirms and communicates successful completion of the transaction to the member through the mobile rewards mobile application 115. The member 115 now has the redeemed for funds available to spend at the retailer 122A at which they are located. The funds are stored on the issued ghost card 121, which in turn is securely stored within the mobile wallet 104 of the device 115. The member can pay for products/services through a split tender transaction or single tender transaction if they have redeemed currency (points) for sufficient funds to pay for the entire purchase. At 118, the member completes the transaction with the device 115 through the wallet 104 and application 105 communicating with a mobile payments protocol 113 such as NFC (Near Field Communications) 106 by ‘tapping’ their device 115 to the contactless POS terminal 117 of the retailer 122A. This initiates a standard credit transaction. The currency redeemed for will only be available for use at the identified rewards partners utilizing the filtering process of the card issuer. The transaction will be transparent to the person and the retailer (i.e., the same as any other debit/credit card transaction). The account is usable for the particular transaction at the amount selected by the person and the person is not aware of and does not otherwise have access to the account. After the transaction, of the member transacted for less then they redeemed the balance would remain on the card until their next transaction or could be returned to points based on the individual rules of the program. Although the currency is interchangeable amongst the participating retailers 122, all marketing communications to the person may be specific to the individual retailer 122A, e.g. you have redeemed 1200 points for $100 at Retailer ‘A’ or you have redeemed 700 points for $500 at Retailer ‘A’. At this point marketing messages from the program owner 120, 119 can be delivered in real-time to the member 80, via the mobile rewards application, through the Mobile rewards control center. (Fig. 4, ¶35-¶39). Ludin teaches, “During online token processing, POS device 130 may then communicate with transaction processor 140, such as over a network connection and using a token processor network including components and processor for token processing with transaction processor 140, to process a payment request 332. The payment request 332 may include transaction information, a digital token, and/or an application cryptogram for processing and authorization of payment to POS device 130. Transaction processor 140 may respond with a response 334, such as an approval or denial of the transaction or a request for additional data based on the provided data and corresponding funds available for transaction processing using the digital token. Thereafter, POS device 130 may communicate with user device 110 to communicate and process a transaction processing completion 336, which may provide a receipt or other transaction history documenting the transaction processing”. (Fig. 3B, ¶78). “At step 412, the application cryptogram is processed for the payment. NFC sales application 132 may then process digital token 134, or other data such as an application cryptogram or the like generated for digital token 134, with transaction processor 140 over network 150 or over another token processor network. For example, POS 204 may communicate with full wallet platform 212 or credit card processor 216 over token processor networks 206 for processing of application cryptogram and/or corresponding digital token. Full wallet platform 212 or credit card processor 216 may be selected for processing of the electronic transaction based on the received digital token and token/token processor network preference, which may then lead to an approval or denial of the transaction and corresponding payment, transaction rejection, and transaction history generation”. (Fig. 4 (412), ¶89). Law teaches, “the cardholder 101 registers one or many funding cards and their mobile device with a virtual card issuer 401 . It can be appreciated that any funding card can be registered, and is not limited or dependent on the mobile phone carrier having an agreement with the funding card issuer. In other words, even if the funding card and the mobile phone carrier do not have any agreement or connecting computer infrastructure, according to the proposed systems and methods, the user's one or many funding cards and the user's mobile device can be registered with the virtual card issuer 401 . It can also be appreciated that any number of funding cards can be registered in association with the mobile device. The cardholder's mobile device includes a payment application that can interact with the virtual card issuer 401 . [0074] In an example embodiment of the registration, for each funding card the user wishes to register, the user enters in (e.g. types in) card details into the mobile device (e.g. card details include the name printed on the funding card, the PAN printed on the funding card, the expiry date printed on the funding card, and the static security code printed on the funding card). The mobile device sends this data, plus a user provided PIN and the mobile device ID to the payment gateway server. For each funding card, the payment gateway server computes a funding card identifier which identifies the given funding card. The payment gateway server stores the funding card identifier in association with the funding card details, mobile device ID and PIN, and it sends the funding card identifier to the mobile device for storage. In an example embodiment, the funding card identifier is a value that is different from the PAN, expiry date or static security code of the funding card. For example, the funding card identifier is a random value so that, if intercepted by an adversary, would not be able to recognize any funding card details. In an example embodiment, the mobile device does not store any funding card details but only stores limited funding card details (e.g. the name funding card issuer and the last 4 digits of the PAN). The mobile device stores the funding card identifier, which it sends to the payment gateway server to indicate a specific funding card. It can be appreciated that there are other methods to capture the funding card details (e.g. besides the user typing in the data), which can be used with the principles described herein”. (¶73-¶74). “The end user 101 sees the message from the POS terminal device 502 and starts the payment application 620 on the mobile device 501 (block 702). For example, the user selects an icon for the payment application 620 on a home screen of the mobile device 501 , thereby launching the payment application 620. The payment application 620 determines if the user has successfully registered to the service (block 703), and if so, shows a menu (block 704) of supported actions by the application. If the user has not registered, the menu offers the user to register with the service (e.g. register one or more funding cards, provide a PIN, link a mobile device identifier to the registration record)”. (Fig. 7(703), ¶91). Thus combination of Law, Pirillo and Ludin teaches the recited claim limitations. The motivation/suggestion for doing so would be to provide a real-time or near real-time point redemption during a point-of-sale transaction.
Applicant further recites similar remarks as listed above for dependent claims, 2-5, 7-9, 11-14 and 16-21. Please see response for remarks in above paragraph 11 that clearly shows how the cited prior arts Law, Pirillo and Ludin clearly teaches the claimed limitations.
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.
Claims 1-5 and 7-21 are rejected under 35 U.S.C. 103 as being unpatentable over Law et al. (WIPO PUB. # WO 2013/155627, hereinafter “Law”), and further in view of Carlo Pirillo (US PGPUB. # US 2019/0325472, hereinafter “Pirillo”), and further in view of Ludin et al. (WIPO PGPUB. # WO 2025/0718996, hereinafter “Ludin”, priority based on application 18/475,770 filed on 09/27/2023).
Referring to Claims 1, 10 and 15:
Regarding Claim 1, Law teaches,
A computer-implemented method, comprising:
initiating, by an application executing on a user device, a data exchange session with a terminal device; (Fig. 7(701, 702), ¶90, “the user can tap their mobile device 501 or a contactless funding card. The examples described herein relate to tapping the mobile device 501”, ¶91, “starts the payment application 620 on the mobile device 501 (block 702)”, i.e. an application on a user device starts a data exchange session with a POS terminal)
determining, by the application, a data exchange account associated with a third party service provider, the date exchange account comprising a default data exchange option; (¶73, “the user's one or many funding cards and the user's mobile device can be registered with the virtual card issuer 401”, ¶74, “the user enters in (e.g. types in) card details into the mobile device (e.g. card details include the name printed on the funding card, the PAN printed on the funding card, the expiry date printed on the funding card, and the static security code printed on the funding card)”, Fig. 7(703), ¶91, “The payment application 620 determines if the user has successfully registered to the service (block 703), and if so, shows a menu (block 704) of supported actions by the application”, i.e. Examiner submits that credit card data are saved on the payment gateway (credit card issued by various issuers (third party) and the application determines selected card (data exchange account) based on the user selection and registration of the card data. Paying with a registered credit card is interpreted as a default data exchange option)
Law does not teach explicitly,
obtaining, by the application from a server device, a data exchange option corresponding to the data exchange account and provided by the third party service provider, wherein the data exchange option is different from the default data exchange option and comprising information usable by the third party service provider to validate a data cryptogram transmitted from the application to the terminal device according to a first validation process, wherein the first validation process is different from a default validation process for validating data cryptograms transmitted from the application to the terminal device, and wherein the server device maintains association information for the third party service provider;
receiving, by the application, an indication that the data exchange option was selected;
responsive to the indication, transmitting, by the application to the server device, a confirmation request associated with the data exchange option;
receiving, by the application from the server device, a confirmation that the data exchange option is approved by the third party service provider;
responsive to the confirmation, transmitting, by the application to the terminal device within the data exchange session, the data cryptogram comprising information usable to identify the data exchange account.
However, Pirillo teaches,
obtaining, by the application from a server device, a data exchange option corresponding to the data exchange account and provided by the third party service provider, wherein the data exchange option is different from the default data exchange option (Fig. 4, ¶30-¶31, ¶33, i.e. an application obtains rewards points options from the mobile rewards control section (server). The rewards points (data exchange) is different from credit card, debit card (default data exchange option), and comprising information usable by the third party service provider [to validate a data cryptogram transmitted from the application to the terminal device] according to a first validation process, wherein the first validation process is different from a default validation process for validating data cryptograms transmitted from the application to the terminal device, (¶35-¶39, i.e. rewards points information is usable by the third party service provider and points funds are validated (first validation process) which is different than validating credit card/debit card balance (default validation process)) and wherein the server device maintains association information for the third party service provider; (Fig. 2, ¶18, “one or more award programs 107, 108 (e.g., operated by a server)”, ¶19, ¶21, ¶30, i.e. server device maintains association information)
receiving, by the application, an indication that the data exchange option was selected; (Fig. 4(406), ¶34, “The member 115 selects the desired offering at 406 and confirms their desire to redeem”, i.e. an indication is received regarding data exchange option)
responsive to the indication, transmitting, by the application to the server device, a confirmation request associated with the data exchange option; (Fig. 4(408), ¶35, “The mobile rewards management system 100 confirms that the member 115 has sufficient points by requesting a points check with the loyalty platform 107, 108, and requests a confirmation”)
receiving, by the application from the server device, a confirmation that the data exchange option is approved by the third party service provider; (Fig. 4, ¶35-¶36, i.e. a confirmation is received that the data exchange option is approved)
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Pirillo with the invention of Law.
Law teaches, a payment application on a user device that provides various payment options to a user and the user selects one of the payment option. Pirillo teaches, providing a payment application to pay with rewards points based on validating with a sever for available rewards points. Therefore, it would have been obvious to provide a payment application to pay with rewards points based on validating with a sever for available rewards points of Pirillo with a payment application on a user device that provides various payment options to a user and the user selects one of the payment option of Law for a real-time or near real-time point redemption during a point-of-sale transaction.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Combination of Law and Pirillo does not teach explicitly,
[wherein the data exchange option is different from the default data exchange option and comprising information usable by the third party service provider] to validate a data cryptogram transmitted from the application to the terminal device [according to a first validation process, wherein the first validation process is different from a default validation process for validating data cryptograms transmitted from the application to the terminal device],
responsive to the confirmation, transmitting, by the application to the terminal device within the data exchange session, the data cryptogram comprising information usable to identify the data exchange account.
However, Ludin teaches,
[wherein the data exchange option is different from the default data exchange option and comprising information usable by the third party service provider] to validate a data cryptogram transmitted from the application to the terminal device (Fig. 3B, ¶78, “The payment request 332 may include transaction information, a digital token, and/or an application cryptogram for processing and authorization of payment to POS device 130. Transaction processor 140 may respond with a response 334, such as an approval or denial of the transaction” Fig. 4(412), ¶89) [according to a first validation process, wherein the first validation process is different from a default validation process for validating data cryptograms transmitted from the application to the terminal device],
responsive to the confirmation, transmitting, by the application to the terminal device within the data exchange session, a data cryptogram comprising information usable to identify the data exchange account. (Fig. 3B, ¶77, “a cryptogram generation 330 may be performed to generate an application and/or token cryptogram or the like by user device 110 with POS device 130 that validates use of the digital token and a payment to be made via the digital token”, Fig. 4(410, 412), ¶88, “application 202 may generate the cryptogram for POS 204, where application 202 may generate the cryptogram on device or using an online platform. After generating, the cryptogram may be made available to POS device 130 and/or transmitted to POS device 130”, ¶89, i.e. a data cryptogram having information to identify the data exchange session is transmitted to the terminal device by the application).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Ludin with the invention of Law in view of Pirillo.
Law in view of Pirillo teaches, a payment application on a user device that provides various payment options to a user and the user selects one of the payment option and providing a payment application to pay with rewards points based on validating with a sever for available rewards points. Ludin teaches, payment application transmitting a cryptogram having information to identify the data exchange session to the terminal. Therefore, it would have been obvious to have a payment application transmitting a cryptogram having information to identify the data exchange session to the terminal of Ludin in view of Law and Pirillo to identify the transaction initiation mode to identify attributes associated with the transaction, which may have different risk, security and convenience characteristics that may be used during payment transaction processing.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 10, it is a user device claim of above method claim 1 and therefor claim 10 is rejected with the same rationale as applied with claim 1.
Law teaches a user device in Figure 6 having a processor (Fig. 6(302)) and memory. (Fig. 6(614, 615)).
Regarding Claim 15, it is a computer-readable media claim of above method claim 1 and therefor claim 15 is rejected with the same rationale as applied with claim 1.
Law teaches, a computer-readable media. (¶87).
Referring to Claims 2, 11 and 16:
Regarding Claim 2, rejection of Claim 1 is included and for the same motivation, Law teaches,
The computer-implemented method of claim 1, wherein initiating the data exchange session comprises initiating the data exchange session using a near-field communication protocol. (Abstract, “When a payment is initiated, the virtual card data is sent through the NFC system from a point of sale terminal”, ¶3, ¶69, ¶76, i.e. data exchange is initiated with near-field communication protocol (NFC).
Regarding Claim 11, rejection of Claim 10 is included Claim 11 is rejected with the same rationale as applied against Claim 2 above,
Regarding Claim 16, rejection of Claim 15 is included Claim 16 is rejected with the same rationale as applied against Claim 2 above,
Referring to Claims 3, 12 and 17:
Regarding Claim 3, rejection of Claim 1 is included and for the same motivation, Law teaches,
The computer-implemented method of claim 1, wherein initiating the data exchange session comprises initiating the data exchange session using a network resource provided by the terminal device. (Fig. 7, ¶102, “the mobile device 501 sends the virtual card data to the POS terminal device 502, using the mobile device's NFC subsystem 609”, ¶103, “the POS terminal device 502 will send the virtual card details to the merchant acquirer, along with other transaction data (e.g. cost for transaction, merchant ID, etc.)”, i.e. data initiating exchange session utilized terminal device network resources).
Regarding Claim 12, rejection of Claim 10 is included Claim 12 is rejected with the same rationale as applied against Claim 3 above,
Regarding Claim 17, rejection of Claim 15 is included Claim 17 is rejected with the same rationale as applied against Claim 3 above,
Referring to Claims 4, 13 and 18:
Regarding Claim 4, rejection of Claim 1 is included and for the same motivation, Law teaches,
The computer-implemented method of claim 1, further comprising:
responsive to the initiation of the data exchange session, obtaining, by the application, a plurality of data exchange accounts from the server device; (¶73, “the user's one or many funding cards and the user's mobile device can be registered with the virtual card issuer 401 “, “The cardholder's mobile device includes a payment application that can interact with the virtual card issuer 401”, ¶91-¶93) and
presenting the plurality of data exchange accounts at a display of the user device. (Fig. 14, ¶171).
Regarding Claim 13, rejection of Claim 10 is included Claim 13 is rejected with the same rationale as applied against Claim 4 above,
Regarding Claim 18, rejection of Claim 15 is included Claim 18 is rejected with the same rationale as applied against Claim 4 above,
Referring to Claims 5, 14 and 19:
Regarding Claim 5, rejection of Claim 4 is included and for the same motivation, Law teaches,
The computer-implemented method of claim 4, wherein determining the data exchange account comprises receiving a selection of the data exchange account from the plurality of data exchange accounts presented at the display of the user device. (Fig. 14, ¶171, Fig. 15, ¶175).
Regarding Claim 14, rejection of Claim 13 is included Claim 14 is rejected with the same rationale as applied against Claim 5 above,
Regarding Claim 19, rejection of Claim 18 is included Claim 19 is rejected with the same rationale as applied against Claim 5 above,
Claim 6 – Canceled
Regarding Claim 7, rejection of Claim 1 is included and for the same motivation, Law teaches,
The computer-implemented method of claim 1, wherein obtaining the data exchange option comprises receiving, from the server device, a plurality of data exchange options determined based at least in part on the association information and the data exchange account. (¶73, “the user's one or many funding cards and the user's mobile device can be registered with the virtual card issuer 401 “, “The cardholder's mobile device includes a payment application that can interact with the virtual card issuer 401”, ¶74, “For each funding card, the payment gateway server computes a funding card identifier which identifies the given funding card. The payment gateway server stores the funding card identifier in association with the funding card details, mobile device ID and PIN, and it sends the funding card identifier to the mobile device for storage”, “the funding card identifier is a value that is different from the PAN, expiry date or static security code of the funding card”, Fig. 14, ¶171, Fig. 15, ¶175).
Referring to Claims 8 and 20:
Regarding Claim 8, rejection of Claim 1 is included and for the same motivation, Law teaches,
The computer-implemented method of claim 1, wherein the terminal device does not maintain the association information for the third party service provider. (¶73-¶74, “The payment gateway server stores the funding card identifier in association with the funding card details, mobile device ID and PIN, and it sends the funding card identifier to the mobile device for storage”, ¶107 i.e. terminal device does not maintain association information for the third party providers).
Regarding Claim 20, rejection of Claim 15 is included Claim 20 is rejected with the same rationale as applied against Claim 8 above,
Regarding Claim 9, rejection of Claim 1 is included and for the same motivation, Law does not teach explicitly,
The computer-implemented method of claim 1, wherein the data cryptogram does not comprise information identifying the data exchange option.
However, Ludin teaches,
The computer-implemented method of claim 1, wherein the data cryptogram does not comprise information identifying the data exchange option. (Fig. 3B, ¶77, “the application cryptogram may be seeded and/or generated between user device 110 and POS device 130 using information including an unpredictable number (e.g., a value providing variability and uniqueness to cryptogram generation)”, i.e. data cryptogram does not identify data exchange option).
Regarding Claim 21, rejection of Claim 1 is included and for the same motivation, Law does not teach explicitly,
The computer-implemented method of claim 1, wherein the first validation process comprises structuring a resolution of the data exchange according to the data exchange option.
However, Pirillo teaches,
The computer-implemented method of claim 1, wherein the first validation process comprises structuring a resolution of the data exchange according to the data exchange option. (Fig. 4, ¶33-¶35, “The mobile rewards management system 100 confirms that the member 115 has sufficient points by requesting a points check with the loyalty platform 107, 108, and requests a confirmation 132 that the member is in good standing at 408”, ¶39, i.e. resolution of the date exchange is structured according to the data exchange option).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Griggs et al. (US PGPUB. # US 2014/0114857) discloses, methods that allow for determining a transaction initiation mode used to conduct a transaction and applying a specific set of rules associated with the transaction initiation mode to the transaction. A transaction authorization request message is received at a server computer. The transaction authorization message is for a transaction between a consumer and a merchant and includes a plurality of data elements. The server computer determines a transaction initiation mode, from among at least three different transaction initiation modes, used to conduct the transaction based at least in part on the data elements. The server computer applies a specific set of rules associated with the transaction initiation mode to the transaction.
Meckler et al. (US PGPUB. # US 2024/0346477) discloses, Techniques are disclosed for customizing the feedback provided to a user at a point-of-sale (POS) terminal upon completion of an electronic payment transaction. The feedback may include the content of one or more media files that may be customized by a user in response to different conditions being met, and which may be specified as part of a user profile. Additional or alternative feedback may be specified by an entity identified with the user's payment account, such as a bank or creditor, which may comprise additional or alternative media file(s) that may be identified in response to specific predetermined conditions being met upon the electronic payment transaction being initiated. The feedback may be sent to the POS terminal and/or to a different device based upon the type of electronic payment transaction and/or the capabilities of the POS terminal.
Smets et al. (WIPO PUB. # WO 2022/265732) discloses, a method of verifying data during a transaction process between the payment device and a terminal is described. The method comprises providing, by the terminal to the payment device, a request to generate cryptogram data for verification. The method further comprises the following steps, performed by the payment device: generating a first digest over a plurality of transaction data items relating to the transaction process, the transaction data items being exchanged between the payment device and the terminal during the transaction process; generating a cryptogram unique to the 'transaction process, using the first digest and a subset of the plurality of transaction data items; generating, a cryptogram response message containing the cryptogram, the first digest and the subset of transaction data items used to generate the cryptogram; and transmitting the cryptogram response message to the terminal. The method further comprises the following steps, performed by the terminal: generating a second digest 'using a stored plurality of transaction da ta items exchanged between the payment device and the terminal during the: transaction process; comparing the first digest with the second digest; and (i) if the first digest matches the second digest, proceeding with further authentication and subsequently generating an authorisation request message for provision io an authorisation system; or (ii) if the first digest does not match the second digest, aborting, by 'the terminal, the transaction process.
Pezewski et al. (US PGPUB. # US 2023/0391874) discloses, Systems and methods for executing filtered electronic transactions are disclosed. One method includes receiving, by an acquirer system of a filtered transaction processing system, a transaction request including transaction data from a merchant system, the transaction data including enhanced data or non-enhanced data. A status of the merchant system may be determined based on the transaction data, the status of the merchant system indicative of a participating status or a non-participating status. Upon determining the status of the merchant system indicative of the participating status, the transaction request may be transmitted to a first transaction network. The first transaction network may forward the transaction request to a categorization engine of the filtered transaction processing system. The categorization engine may categorize one or more items associated with the transaction request into one or more categories. The transaction request may be executed based on the one or more categories.
Osborn et al. (US PGPUB. # US 2021/0097535) discloses, systems and methods for data transmission between a contactless card and a client device in support of a FIDO authentication are provided. In an embodiment, upon receipt of a challenge issued by a server in connection with a pending transaction, the contactless card may authorize the client device to utilize a FIDO private key to respond to the challenge. If the response to the challenge is successful, the FIDO authentication may proceed and the transaction may be completed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARSHAN I DHRUV whose telephone number is (571)272-4316. The examiner can normally be reached M-F 9:00 AM-5: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, Yin-Chen Shaw can be reached at 571-272-8878. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DARSHAN I DHRUV/ Primary Examiner, Art Unit 2498
Prosecution Insights