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 .
Response to Amendment
The amendment filed July 8, 2026 has been entered. Claims 21-40 remain pending in the application. Applicant’s amendments to the Claims have overcome each and every and 102 rejections previously set forth in the Non-Final Office Action mailed April 8, 2026.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
Claim(s) 21-40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Flurscheim (US 20160140545 A1) in view of Phillips (US 20130297512 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 physical payment card received by the payment device to satisfy a cost of a payment transaction, the first information comprising an identity of an entity issuing the physical payment card, …; obtain, at the payment device, second information corresponding to a communication device associated with the physical payment card and …, 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, 0028, 0032 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; card emulation technology (e.g., Host Card Emulation (HCE), etc.) to emulate a smartcard on a communication device (e.g., a portable communication device) to allow a mobile application running on the portable communication device to conduct contactless transactions; The portable communication device can be configured to transmit and receive data or communications to and from other devices. A portable communication device may be in the form of a mobile device such as a mobile phone (e.g., smart phone, cellular phone, etc.), tablets, portable media player, personal digital assistant devices (PDAs), wearable device (e.g., watch, health monitoring device such as a fitness tracker, etc.), electronic reader device, etc., or in the form of a card (e.g., smart card) or a fob, etc.); 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 physical payment card 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, 0028, 0032 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).
However, Flurscheim does not explicitly teach wherein the first information is obtained based at least on interaction between the payment device and the physical payment card, and 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, and a communication device... physically distinct from the physical payment card.
Phillips from same or similar field of endeavor teaches wherein the first information is obtained based at least on interaction between the payment device and the physical payment card, and 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, and a communication device... physically distinct from the physical payment card (Phillips: Paragraph(s) 0020-0022 teach(es) the personalization information for a particular user's mobile telephone is loaded into a contactless IC card from the issuer's server computer and then the contactless IC card is sent to the user. The user/cardholder then brings the contactless IC card into proximity with the mobile telephone to permit loading of the personalization information via RF communication from the IC card to the mobile telephone).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Flurscheim to incorporate the teachings of Phillips for wherein the first information is obtained based at least on interaction between the payment device and the physical payment card, and 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.
There is motivation to combine Phillips into Flurscheim because Phillips’s teachings of personalization would facilitate to use a payment card for transactions (Phillips: Paragraph(s) 0020-0022).
Regarding Claims 22, 30, and 38, the combination of Flurscheim and Phillips 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 physical payment card 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, 0028, 0032 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, the combination of Flurscheim and Phillips 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 physical payment card, the relationship indicating that the physical payment card 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 physical payment card (Flurscheim: Paragraph(s) 0232-0234, 0028, 0032 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, the combination of Flurscheim and Phillips 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, the combination of Flurscheim and Phillips teaches all the limitations of claims 21 and 29 above; and Flurscheim further teaches wherein the first information further comprises whether the physical payment card includes a magnetic strip that stores payment information or a chip that stores the payment information (Flurscheim: Paragraph(s) 0048-0049, 0028, 0032 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, the combination of Flurscheim and Phillips 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 physical payment card issued by the entity (Flurscheim: Paragraph(s) 0311, 0028, 0032 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, the combination of Flurscheim and Phillips 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) the type of the physical payment card; and (d) a brand of the physical payment card (Flurscheim: Paragraph(s) 0107, 0122, 0028, 0032 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, the combination of Flurscheim and Phillips 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 physical payment card the input (Flurscheim: Paragraph(s) 0107, 0116, 0112, 0028, 0032 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, the combination of Flurscheim and Phillips 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, the combination of Flurscheim and Phillips 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 physical payment card, the relationship indicating that the physical payment card 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 physical payment card (Flurscheim: Paragraph(s) 0148-0149, 0087, 0232-0234, 0028, 0032).
Response to Arguments
Applicant's arguments filed July 8, 2026 have been fully considered but they are not persuasive.
Regarding applicant’s argument under Claim Rejections - 35 USC § 103 that “the transactions Flurscheim describes do not originate from a physical payment card, but rather "the access device may process the transaction as if the portable communication device is a magnetic stripe card." Id., [0048],” examiner respectfully argues that Flurscheim teaches smartcard and Flurscheim’s magnetic stripe card is also a physical card (Flurscheim: Paragraph(s) 0028, 0032, 0048). In addition, Phillips reference teaches that the contactless IC card associated with the user’s mobile telephone (Phillips: Paragraph(s) 0020-0022).
It is noted that the limitations “the first information comprising an identity of an entity issuing the physical payment card, wherein the first information is obtained based at least on interaction between the payment device and the physical payment card, and 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” in claims 21, 29, and 37 may be interpreted as “non-descriptive” language. It is recommended for the applicant to amend the claims by reciting the limitations as one or more steps for setting up the payment transaction, before the first step of “obtain”.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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.
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 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.
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