DETAILED ACTION
This is office action on the merits in response to the application filed on 09/29/2025.
Claims 1-20 have been filed by the applicant.
Claims 1, 4, 7-8, 11, 14-15 and 18 are currently amended.
Claims 1-20 are currently pending and have been examined.
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 Argument
Rejection under 112:
The amendment overcomes previous 112 rejections. 112 rejections have been withdrawn.
Rejection under 103:
The applicant argues that the cited prior art does not teach “receiving, by an application….a selection of a first financial institution….presented by the application”. The examiner respectfully disagrees. Scott discloses prompting user for selecting of payment source. (the virtual wallet may also prompt the user for a selection of one or more of the stored payment options for use with the current transaction. the virtual wallet may respond to the merchant application, via communications subsystems of the requesting device, with a token or credential representing the selected method(s) or source(s) of payment of the user.)[0050-0051].
The applicant further argues that the cited prior art does not teach “generating, by the application, a URI that is directed to another application…the URI including merchant id, user id, session id and action id”. The examiner agrees that the previously cited arts do not teach the limitation. New prior is provided, see 103 rejections below.
In addition, with respect to “the another application being registered with the first financial institution in a mobile operation system of the device” is intended use of the device and does not limit the scope of the claims. It has been held language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use (MPEP §2103 I C).
In addition, with respect to “the IDs included in the URI” this is nonfunctional descriptive material as it only describes the data that is contained in the URI, while the data contained in the URI is not used to perform any of the recited method steps. Therefore, it has been held the nonfunctional descriptive material will not distinguish the invention from the prior art in term of patentability. (In re Gulack, 217 USPQ 401 (Fed. Cir. 1983), In re Ngai, 70 USPQ2d (Fed. Cir. 2004), In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994); MPEP 2111.05), Ex parte Nehls 88 USPQ2d 1883 (BPAI 2008) (precedential).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Scott et al. (US 20170017958 A1), and further in view of Isaacson (JP 2020523716 A) and Tsui et al. (US 20160026997 A1) and Maclin et al. (US 20020032662 A1).
With respect to claim 1, 8 and 15:
Scott teaches (in italic):
receiving, by an application executing on a processor of a device, a selection of a first financial institution from a list of financial institutions presented by the application. (the virtual wallet may also prompt the user for a selection of one or more of the stored payment options for use with the current transaction. the virtual wallet may respond to the merchant application, via communications subsystems of the requesting device, with a token or credential representing the selected method(s) or source(s) of payment of the user. [0050-0051])
receiving, by a software development kit (SDK) in an application executing on a processor of a device, an indication of a selection of a uniform resource locator (URL) in a form for a transaction, wherein the transaction is associated with a merchant. (When a user navigates to a web page or site that requires a payment, an option may be presented in order to enable selection by the user of payment using a virtual or electronic wallet installed on the user's request communication device. a virtual wallet 112 of a device 110, 110′ may be made accessible to other applications 114, 115 installed on otherwise accessible by the device. For example, a merchant application 114 may be authorized or otherwise enabled to access information from within a wallet application 112 of a trusted device 110′ through implementation of a pull architecture, which may be facilitated by providing on the trusted device 110′ a system level application programming interface (API) 116 that is common to or otherwise accessible by both the wallet and merchant application. Such an API can, for example, be provided in the form of a separate payment options application API 116 (“Pay with your bank SDK”), as shown in FIG. 12; alternatively, such an API 116 may itself serve as a common, or universal wallet 112, by polling applications 112, 114, and servers 120, 160 etc. [0059, 0167])
presenting, by the SDK, an SDK interface overlaid on an interface of the application. (the GUI 1407 provided in FIG. 14B can be provided in the form of an interactive “overlay” screen 1409, either by causing the display to generate a new GUI 1407 and overwrite the previous screen completely, or for example by using ‘fade’ or ‘grey-out’ imaging techniques to allow the user 190 to interact with the payment options 116 and/or wallet 114 without otherwise terminating or interrupting a checkout session or process being executed by the merchant system 130 [0182])
receiving, by the SDK, selection of an interface element in the SDK interface, the interface element associated with using payment information associated with a contactless card for the transaction; presenting, by the SDK in the SDK interface based on the selection of the interface element […]. (mobile device 110, 110′, 600 may be configured to act in a card emulation (CE) mode whereby mobile device 110, 600 emulates a contactless payment card through storage of payment credentials within a secure element 617. enable the user to scroll the GUI 1407 so as to view further payment options available through the wallet 114, options application 116, and or an associated FI 120, 160; and optionally to control payment using a combination of accounts or fund sources. [0115, 0178-0182])
presenting, by the SDK in the SDK interface based on the authentication result, a permissions element, the permissions element selectable to permit use of the payment information for the transaction. (In response to being queried by the merchant application, in some cases, a virtual wallet application may cause presentation on an output screen of the requesting communication device of a user interface soliciting authorization to proceed (a ‘prompt’ for confirmation of authorization). [0050, 0098])
transmitting, by the application based on the input specifying to process the transaction, the payment information to a server associated with the merchant to process the transaction. (application toward the transaction; and at 1542 the merchant system 136, 136′ can return an order confirmation data set to the merchant app 114, for presentation to the user via an output display device 610 [0206])
Scott does not explicitly teach the following limitations. However,
Isaacson teaches:
generating, by the application, a uniform resource identifier (URI) that is directed to another application, the another application being registered with the first financial institution in a mobile operating system of the device. (A browser or web browser is a software application for retrieving, presenting, and traversing information resources on the World Wide Web. Information resources are identified by a uniform resource identifier (URI/URL) and can be web pages, images, videos, or other content. The hyperlinks present in the resource allow the user to easily navigate the browser to related resources. Each link contains the URI of the resource that will go. When the link is clicked, the browser navigates to the resource indicated by the target URI of the link and begins the process of bringing the content back to the user. [0319-0326])
the URI including a merchant identifier (ID) parameter, a user ID parameter, a session ID parameter, and an action ID parameter. (Therefore, this embodiment provides a merchant.com API through API so that the site can process the purchase of the product according to the normal payment processing structure. Includes interaction between the browser and the merchant (such as http://www.merchant.com) through an API to manage the requesting and sending of payment data to the com site). The com website inspects browser cookies from other sites and uses them to collect user data, search history, or any other stored in or made available via cookies. Information can be collected. User payment and address information, as well as any other type of data, can be stored within or accessible by the browser. The system may, for example, use a session cookie to determine that the user has or had an active session with a particular website, and uses the information in the session cookie to provide the user with the information. The system may also analyze based on a corpus of existing contexts for the user, such as recently viewed or opened web pages and recent actions performed by the user on the computing device. Recent actions were viewed on the user's calendar information, location data, recent purchases or other transactions, social networking data including posts, messages sent to friends, friend's birthday, YouTube®. It can include videos and the like. [0134, 0140-0141, 0324])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Scott to generating URI for transaction with the technique as disclosed by Isaacson to reduces the number of interactions during transaction as Isaacson suggested [0135].
Scott in view of Isaacson does not explicitly teach the following limitations. However,
Tsui teaches:
presenting, […] orientation instructions depicting an orientation of the contactless card relative to the device, the orientation to enable wireless communications between the contactless card and the device. (If the proximity based communication circuitry or module of the electronic communication device 201 is successfully accessed (153), in step 109 the merchant's or other entity's website 202 prompts the user 200 to tap a proximity based communication enabled payment card 203 against the electronic communication device 201. [0073])
receiving, […], the payment information and a cryptogram from the contactless card via wireless communications. (The proximity based communication circuitry or module of the electronic communication device 201 extracts available data from the payment card 203. In some implementations where encrypted values are extracted from the card, the process 1400 transmits (1460) the encrypted values to the server or a third party for the transaction. See at least [0073-0074] [0169])
filling, […] based on selection of the permissions element, the payment information in one or more fields of the form; receiving, by the application, input specifying to process the transaction using the payment information filled into the one or more fields of the form. (The communication circuitry is configured to submit data from the data entry fields to the server to facilitate the completion of the information exchange. Referring to steps 117 and 118, the payment data collected by the website 202 is sent for verification and payment processing 204. See at least Abstract and [0077])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Scott in view of Isaacson to receive cryptogram from contactless card and autofill the payment information with the technique as disclosed by Tsui to greatly expedites the transaction or information exchange as Tsui suggested [0012].
Scott in view of Isaacson and Tsui does not explicitly teach the following limitations. However,
Maclin teaches:
transmitting, […], the cryptogram to an authentication server. (After the secure link is established, the customer application running on the customer computer 102 sends encrypted variables to the credit card server 110 (step 308). See at least [0029])
receiving, […], an authentication result specifying the authentication server decrypted the cryptogram. (After a processing time, the credit card server 110 returns a credit card number to the customer computer 110 that will be used for the current transaction (step 310). See at least [0029])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Scott in view of Isaacson and Tsui to have authentication server decrypting cryptogram with the technique as disclosed by Maclin to reduce risks as Maclin suggested [0007].
Claim 8, a CRM with the same scope as claim 1, is rejected.
Claim 15, a computing apparatus with the same scope as claim 1, is rejected.
With respect to claim 2, 9 and 16:
Scott further teaches wherein the application comprises a web browser or a native application associated with the merchant. (When a user navigates to a web page or site that requires a payment, an option may be presented in order to enable selection by the user of payment using a virtual or electronic wallet installed on the user's request communication device. a virtual wallet 112 of a device 110, 110′ may be made accessible to other applications 114, 115 installed on otherwise accessible by the device. For example, a merchant application 114 may be authorized or otherwise enabled to access information from within a wallet application 112 of a trusted device 110′ through implementation of a pull architecture [0059, 0167])
Claim 9, a CRM with the same scope as claim 2, is rejected.
Claim 16, a computing apparatus with the same scope as claim 2, is rejected.
With respect to claim 3, 10 and 17:
Scott further teaches wherein the SDK is a non-persistent on-demand application associated with an issuer of the contactless card. (Such an API can, for example, be provided in the form of a separate payment options application API 116 (“Pay with your bank SDK”), as shown in FIG. 12; alternatively, such an API 116 may itself serve as a common, or universal wallet 112, by polling applications 112, 114, and servers 120, 160 etc. [0167])
Claim 10, a CRM with the same scope as claim 3, is rejected.
Claim 17, a computing apparatus with the same scope as claim 3, is rejected.
With respect to claim 4, 11 and 18:
Scott further teaches wherein the non-persistent on-demand application comprises one or more of a JavaScript SDK, an Android SDK, an iOS SDK, or an App Clip. (Accordingly, one or more different merchant transaction communication applications 114, 630 or other programs may be installed by a user of a device 110, 110′, 600 into mobile or other OS 608. merchant application 115 may display an option to the user to pay for the transaction using a wallet application 112, 612 installed in mobile OS 608. [0118 0124])
Claim 11, a CRM with the same scope as claim 4, is rejected.
Claim 18, a computing apparatus with the same scope as claim 4, is rejected.
With respect to claim 5, 12 and 19:
Tsui further teaches wherein the payment information and the cryptogram are received via Near-Field Communication (NFC) and according to an NFC Forum data format (NDEF). (The proximity based communication circuitry or module of the electronic communication device 201 extracts available data from the payment card 203. In some implementations where encrypted values are extracted from the card, the process 1400 transmits (1460) the encrypted values to the server or a third party for the transaction. See at least [0073-0074] [0169])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Scott to communicate using NFC with the technique as disclosed by Tsui to greatly expedites the transaction or information exchange as Tsui suggested [0012].
Claim 12, a CRM with the same scope as claim 5, is rejected.
Claim 19, a computing apparatus with the same scope as claim 5, is rejected.
With respect to claim 6, 13 and 20:
Scott further teaches wherein the payment information comprises a virtual account number associated with the contactless card, an expiration date associated with the virtual account number, and a card verification value (CVV) associated with the virtual account number. (In the processing of transactions and transaction data through the use of computer communication networks, the provision of a user's credit card information, such as the card issuer, credit card number, expiry date, etc. [0010])
Claim 13, a CRM with the same scope as claim 6, is rejected.
Claim 20, a computing apparatus with the same scope as claim 6, is rejected.
With respect to claim 7 and 14:
Scott further teaches wherein the URL is a deep link URL or a universal link URL. (When a user navigates to a web page or site that requires a payment, an option may be presented in order to enable selection by the user of payment using a virtual or electronic wallet installed on the user's request communication device. a virtual wallet 112 of a device 110, 110′ may be made accessible to other applications 114, 115 installed on otherwise accessible by the device. [0059, 0167])
Claim 14, a CRM with the same scope as claim 7, is rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 11138486 B1: In some examples, this identifying information may be encrypted and external card reader 130 may send the encrypted information to server 138 to decrypt the identifying information. Server 138 may then determine whether the cardholder has process access rights. Alternatively, server 138 may transmit the decrypted identifying information to external card reader 130 and controller 132 may use it to identify the cardholder and determine whether the cardholder has proper access rights.
US 20200202360 A1: When the online fingerprint feature is received by the host computer, the host computer encrypts the online fingerprint feature to obtain the encrypted online fingerprint feature, sends the encrypted fingerprint feature to the server; after the server receives the encrypted online fingerprint feature, the server decrypts the encrypted online fingerprint feature to obtain the online fingerprint feature and verifies the decrypted fingerprint feature according to self-stored fingerprint feature.
US 20200252745 A1: Upon receiving the application selection, the application of the portable device 102 may send a terminal transaction data request to request transaction data from access device 104 which may be needed to execute the transaction using the selected application/AID.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZESHENG XIAO whose telephone number is (571)272-6627. The examiner can normally be reached 10:00am-4:30pm M-F.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/Z.X./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698