DETAILED ACTION
Claim Status
This is first office action on the merits in response to the application filed on 7/23/2025.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 21-40 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 9/9/2025 is(are) in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 21-40 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,387,212. Although the claims at issue are not identical, they are not patentably distinct from each other because it recites the additional features of “wherein a type of the physical payment card is at least one of a chip-enabled card, a magnetic strip card, a NFC-enabled card, or a RFID-enabled card”. Since U.S. Patent No. 12,387,212 and the claims at issue of the present application perform similar functions, it would have been obvious to a person of ordinary skill in the art to modify claims 1-20 of U.S. Patent No. 12,387,212 by removing the additional features. It is well settled that omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karison, 136 USPQ 184 (CCPA 1963) Also note Ex parte Rainu, 168 USPQ 375 (Bd. App. 1969). Thus, omission of a reference element whose function is not needed would be obvious to one of ordinary skill in the art.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 21-40 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Flurscheim (US 20160140545 A1).
Regarding Claims 21, 29, and 37, Flurscheim teaches A system comprising: one or more processors; and one or more computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to: (Flurscheim: Paragraph(s) 0032-0033): A method comprising (Flurscheim: Paragraph(s) 0038-0039, 0122): One or more non-transitory computer-readable media of a payment device, the one or more non-transitory computer-readable media storing instructions executable by one or more processors that, when executed by the one or more processors, cause the one or more processors to perform acts comprising (Flurscheim: Paragraph(s) 0032-0033, 0279):
obtain, at a payment device, first information associated with a payment instrument received by the payment device to satisfy a cost of a payment transaction, the first information comprising an identity of an entity associated with the payment instrument; obtain, at the payment device, second information corresponding to a communication device associated with the payment instrument, the second information including a device identifier of the communication device; send, from the payment device to a device associated with the entity and via a payment processing system, the first information and the second information (Flurscheim: Paragraph(s) 0038-0039, 0051, 0083, 0087, 0122 teach(es) An “authorization request message” may be an electronic message that is sent to request authorization for a transaction. The authorization request message can be sent to a payment processing network (i.e., via a card network associated with the payment card) and/or an issuer (i.e., server computing devices of an issuer) of a payment card (i.e., identifier of the payment card); The cloud-based transactions system according to some embodiments provides a set of functionalities to manage the deployment and usage of account parameters (i.e., identifier of the payment card) for transactions conducted using a portable communication device; The account parameters can be provided or provisioned to a portable communication device to enable the portable communication device to conduct transactions on the user's account (e.g., by placing the portable communication device in proximity to a contactless reader of an access device such as a point-of-sale (POS) terminal (i.e., at the POS device), or by a portable communication device generating an emulated magnetic signal in proximity to a magnetic stripe reader of an access device); the portable communication device is a standard card (e.g., ID-1 card type as specified in ISO 7811), a mini-card, a non-card form factor (e.g., key fob, watch, wristband, ring, sticker, etc.), or a mobile phone); receive, from the device associated with the entity and at the payment processing system, a verification order different from a default verification order, wherein the verification order is configured by the entity to be presented to a customer associated with the payment instrument to authorize the payment transaction, and wherein the verification order is based on an indication that an application associated with the entity is installed on the communication device; receive, at the payment device and from the payment processing system, the verification order different from the default verification order (Flurscheim: Paragraph(s) 0083, 0087, 0107, 0116, 0119-0122, 0284, 0248-0249 teach(es) Applications environment of portable communication device (i.e., communication device) may host a mobile application (i.e., an application has been installed on a communication device) provided by a mobile application provider; Once portable communication device and mobile application have been provisioned with the account parameters (i.e., utilizing the identifier of the physical payment card), portable communication device can conduct cloud-based transactions (i.e., for management of the payment transaction) by interacting with contactless reader of access device (e.g., at a merchant point-of-sale (POS) location); The mobile application on the portable communication device may receive, store, and/or support generation of information related to the account to enable the mobile application to respond with the necessary information to a contactless reader as well as provide cardholders with information about the account via the portable communication device's user interface, including account configuration information, which may include which consumer verification method(s) (CVM(s)) (e.g., online PIN, consumer device CVM, signature, etc.) (i.e., a cardholder verification method (CVM)) are supported by the account (i.e., by the one or more server computing devices of the issuer) and their priority; If a CDCVM is used, then the two-tap scenario (i.e., default CVM) for high-value transactions may not be necessary. Conversely, to reduce barriers to use, if an issuer decides (i.e., determining, by the one or more server computing devices of the issuer) to opt for not asking for a CDCVM in Manual Mode, then the consumer will be able to conduct transactions once the conditions for Manual Mode operation are met); and request, by the payment device, an input from the customer according to the verification order (Flurscheim: Paragraph(s) 0340-0341, 0333, 0284, 0248 teach(es) When the consumer initiates a contactless payment with the screen in an unlocked state, the contactless reader may request CDCVM entry. Where a device-level CDCVM is used, mobile application may instruct the consumer to tap (i.e., input according to the CVM) portable communication device to the contactless reader (i.e., POS device). Where a mobile application level CDCVM is used, mobile application may present the CDCVM entry screen to the consumer, and then instruct the consumer to tap portable communication device to the contactless reader once a successful CDCVM has been entered).
Regarding Claims 22, 30, and 38, Flurscheim teaches all the limitations of claims 21, 29, and 37 above; and Flurscheim further teaches wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: determine a relationship between the communication device and the payment instrument based at least in part on the application being installed on the communication device, wherein the relationship is established at a time of registration of the communication device with the application associated with the entity (Flurscheim: Paragraph(s) 0105-0106 teach(es) During installation of the mobile application, the mobile application may register its proximity payment system environment (PPSE) name as well as all Application Identifiers (AIDs) covered by the mobile application to ensure that transactions using those AIDs are routed to the mobile application (e.g., this can be achieved through a declaration in the manifest of the mobile application to the mobile operating system).
Regarding Claim 23, Flurscheim teaches all the limitations of claim 21 above; and Flurscheim further teaches wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: determine a relationship between the communication device and the payment instrument, the relationship indicating that the payment instrument is associated with the device identifier (Flurscheim: Paragraph(s) 0105-0106, as stated above with respect to claim 22); and determine a risk level associated with the payment transaction based in part on the relationship between the communication device and the payment instrument (Flurscheim: Paragraph(s) 0232-0234 teach(es) The set of account related data may also include risk management parameters (e.g., limited-use thresholds such as number of consecutive transactions allowed and time-to-live) that will indicate to issuer/host system how it is supposed to use the transaction data).
Regarding Claims 24 and 32, Flurscheim teaches all the limitations of claims 23 and 30 above; and Flurscheim further teaches wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: determine a first location of the communication device; and determine a distance between the communication device and the payment device based at least in part on a comparison of the first location of the communication device and a second location of the payment device, wherein determining the relationship is based at least in part on the distance being less than a threshold distance (Flurscheim: Paragraph(s) 0148-0149, 0087 teach(es) To initiate a magnetic stripe reader transaction, a user may launch the payment application on the portable communication device, and place the portable communication device in proximity (i.e., within a distance of the POS device) to a magnetic stripe reader of an access device; Once portable communication device 101 and mobile application 115 have been provisioned with the account parameters, portable communication device 110 can conduct cloud-based transactions by interacting with contactless reader 162 of access device 160 (e.g., at a merchant point-of-sale (POS) location). Contactless reader 162 may include one or more RF transceivers that can send and receive communications using NFC or other radio frequency or wireless communication protocols such as BLUETOOTH™, BLE, WiFi, iBEACON™, etc.).
Regarding Claims 25 and 33, Flurscheim teaches all the limitations of claims 21 and 29 above; and Flurscheim further teaches wherein the first information further comprises whether the payment instrument includes a magnetic strip that stores payment information or a chip that stores the payment information (Flurscheim: Paragraph(s) 0048-0049 teach(es) A contactless reader transaction can be a magnetic stripe based transaction or an integrated chip based transaction, depending on the capabilities of the access device).
Regarding Claims 26 and 34, Flurscheim teaches all the limitations of claims 21 and 29 above; and Flurscheim further teaches wherein the default verification order is a generic value set by a card network processor for the payment instrument issued by the entity (Flurscheim: Paragraph(s) 0311 teach(es) The user may populate the consumer's chosen mobile application password by invoking a password change process and provide the current or default password and the consumer's newly chosen password. The consumer may choose this option to change previously chosen passcode/password. Mobile application may prompt the consumer to enter the current password and new password (depending on the implementation and the manner in which passwords are masked or not, the consumer may be prompted to input the new password twice to ensure correct entry)).
Regarding Claims 27, 35, and 40, Flurscheim teaches all the limitations of claims 21, 29, and 37 above; and Flurscheim further teaches wherein generating the verification order is based at least in part on one or more of: (a) specifications of the payment device; (b) the cost of the payment transaction; (c) a type of the payment instrument; and (d) a brand of the payment instrument (Flurscheim: Paragraph(s) 0107, 0122 teach(es) The account configuration information may include the AID(s) of the account, which consumer verification method(s) (CVM(s)) (e.g., online PIN, consumer device CVM, signature, etc.) are supported by the account (or by the respective AID if multiple AIDs are present) and their priority (i.e., a specific order of obtaining), whether the account supports magnetic stripe based transactions).
Regarding Claims 28 and 36, Flurscheim teaches all the limitations of claims 21, 29, and 37 above; and Flurscheim further teaches further comprising a touch-sensitive display to display information regarding the payment transaction and to receive from the customer associated with the payment instrument an input corresponding to the verification order (Flurscheim: Paragraph(s) 0107, 0116, 0112 teach(es) The account configuration information may include the AID(s) of the account, which consumer verification method(s) (CVM(s)) (e.g., online PIN, consumer device CVM, signature, etc.) are supported by the account; the terminal transaction data (e.g., terminal transaction qualifiers (TTQ)) may include a transaction type indicator indicating whether access device (i.e., POS device) supports integrated chip based transactions or magnetic stripe based transactions (i.e., hardware associated with the POS device). Thus, in the integrated chip based transaction illustrated in FIG. 3, access device may send a transaction type indicator in the terminal transaction data to indicate that access device supports integrated chip based transactions; the terminal transaction data (e.g., terminal transaction qualifiers (TTQ)) may also include a consumer verification method (CVM) requirement indicator to indicate whether a CVM is required by access device for the transaction, and also one or more CVM type indicators indicating the types of CVM supported by access device. Examples of CVMs that may be supported (i.e., a dedicated hardware device for receiving personal identification numbers (PINs)) by access device can include online PIN, signature, and/or consumer device CVM (CDCVM) such as a passcode used on portable communication device to unlock the screen or mobile application).
Regarding Claim 31, Flurscheim teaches all the limitations of claim 29 above; and Flurscheim further teaches further comprising determining a risk level associated with the payment transaction based in part on the application being installed on the communication device (Flurscheim: Paragraph(s) 0232-0234 teach(es) The set of account related data may also include risk management parameters (e.g., limited-use thresholds such as number of consecutive transactions allowed and time-to-live) that will indicate to issuer/host system how it is supposed to use the transaction data).
Regarding Claim 39, Flurscheim teaches all the limitations of claim 37 above; and, as stated above with respect to claims 31-32, Flurscheim further teaches the acts further comprising: determining a first location of the communication device; determining a distance between the communication device and the payment device based at least in part on a comparison of the first location of the communication device and a second location of the payment device, based at least in part on the distance being less than a threshold distance, determining a relationship between the communication device and the payment instrument, the relationship indicating that the payment instrument is associated with the device identifier; and determining a risk level associated with the payment transaction based in part on the relationship between the communication device and the payment instrument (Flurscheim: Paragraph(s) 0148-0149, 0087, 0232-0234).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Phillips (US 20130297512 A1) teaches Cardholder Verification Rule Applied In Payment-Enabled Mobile Telephone, including that issuer server incorporates the selected CVM rule in data that is to be loaded into the mobile telephone as part of the personalization process, updating the CVM rule that has previously been stored in the mobile telephone, and issuer determine CVM.
Balasubramanian (US 20140279113 A1) teaches System And Method To Reduce Misuse Of A Financial Instrument At A Point-of-Sale Location, point-of-sale, location, distance, threshold, and application.
Molino (WO 2016134400 A1) teaches Multi-Function Transaction Card, including that depending on payment brand rules and issuer preference, chip cards are personalized with one or more CVMs in order to be accepted in as wide a variety of locations as possible, and Different terminal types support different CVMs.
Radu (US 20150254662 A1) teaches Verifying Transaction Context Data At Wallet Service Provider, including that the issuer of the payment card account may specify one or more CVMs instead of or in addition to CVM(s) required by the payment network.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CLAY LEE whose telephone number is (571)272-3309. The examiner can normally be reached Monday-Friday 8-5pm EST.
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, Neha Patel can be reached at (571)270-1492. 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.
/CLAY C LEE/Primary Examiner, Art Unit 3699
Prosecution Insights