DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the application filed on 12/11/2025.
Claims 4, 15 and 23-47 were previously cancelled.
Claims 1-3, 5-11, and 22 are withdrawn.
Claim 12 is amended.
Claims 12-14, 16-21 are currently pending and have been examined.
Response to Arguments
Applicant’s arguments, filed 12/11/2025, with respect to 35 U.S.C. § 101 have been fully considered and are persuasive. The 35 U.S.C. § 101 rejection of claims of 12-14, 16-21 has been withdrawn.
However upon further review a prior art rejection has been made.
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.
Claims 12-14, 16-17 and 19-21 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Jones et al. (US 2015/0186864 A1).
Regarding Claim 12
A payment method, applied to a user terminal, the user terminal including an e-commerce application program of a merchant, a first SDK integrated with the e-commerce application program, a plurality of different host programs, and each host program being integrated with a second SDK, the method comprising: (See at least Jones [0028] For example, during a transaction at a merchant, a consumer may use their phone to pay for goods at a merchant POS. The consumer may open a mobile application (e.g., mobile wallet application) on the phone associated with multiple cards that have been provisioned onto the phone. Each of the cards may be provisioned as a separate mobile payment application on the device. The consumer may tap their phone to an NFC reader at the POS.
in response to that the e-commerce application program triggers a payment, calling, by the e-commerce application program on the user terminal, the first SDK to obtain a first host program list from a network-wide payment platform of a card organization, wherein the first host program list includes host program identifiers of at least part of host programs supported by the network-wide payment platform. wherein the host programs being front-end service application programs of different card issuers; the first SDK and the second SDK are provided by the card organization to the user terminal, and are configured to facilitate communication and interaction between the user terminal and the network-wide payment platform of the card organization; (See at least Jones [0028] and [0068]: [0028] The POS receives payment information comprising multiple AIDs from the phone. The POS determines which AIDs it supports by comparing the list of AIDs to a list of supported AIDs stored in the POS. If there is a match between AIDs, the POS determines that the AID is supported. Where there are multiple supported payment applications, the POS may determine a preferred application for processing the transaction based on a priority order of the supported AIDs and/or relationships between received AIDs. And [0068] The application selection module 130 may include any sub-application, code, or software module installed on the mobile device 110 that is capable of performing the methods and functionality described herein. The application selection module 130 may be implemented as part of a mobile application 113 (as shown) or may be an independent application configured to interface with a mobile application 113. The application selection module 130 and the processor 111 may be configured to manage, identify, and communicate a list of AIDs associated with provisioned or installed payment applications on a secure element 120 (or other memory of the mobile communication device 110) as well as the corresponding priorities for the AIDs. The application selection module 130 may be configured to interact with mobile payment applications 140A-140N on the secure element 120. In some embodiments, the application selection module 130 may interact with the mobile application 113 and the application selection module may be implemented in the secure element 120.
determining, by the first SDK, a target host program from the first host program list ,and calling up the target host program, the first host program list comprising the plurality of host programs, wherein the plurality of host programs are integrated with unified second SDKs to provide unified payment technical specifications and unified payment identifiers among the different card issuers, each host program corresponds to one of a plurality of host program backend platforms of the card issuers, the host program backend platforms are configured to interface with the same network-wide payment platform of the card organization to authorize resource card binding and resource deduction channels and provide the user terminal with payment access through the corresponding host programs; and (See at least Jones [0068] and [0072]: [0068]The application selection module 130 may include any sub-application, code, or software module installed on the mobile device 110 that is capable of performing the methods and functionality described herein. The application selection module 130 may be implemented as part of a mobile application 113 (as shown) or may be an independent application configured to interface with a mobile application 113. The application selection module 130 and the processor 111 may be configured to manage, identify, and communicate a list of AIDs associated with provisioned or installed payment applications on a secure element 120 (or other memory of the mobile communication device 110) as well as the corresponding priorities for the AIDs. The application selection module 130 may be configured to interact with mobile payment applications 140A-140N on the secure element 120. In some embodiments, the application selection module 130 may interact with the mobile application 113 and the application selection module may be implemented in the secure element 120. [0072] The multiple application selection module 153 may include any application, code, and/or any other software configured to select a supported application on a mobile device 110 in which to initiate a transaction. For example, the multiple application selection module 153 and the processor 151 may be configured to obtain the list of available payment applications from the communication module 152, determine supported AIDs from the list of available AIDs, and obtain payment credentials associated with the selected AIDs.
calling the second SDK by the target host program to interact with the network-wide payment platform, so that the network-wide payment platform interacts with a target host program platform in the plurality of host program backend platforms to complete the payment using a target card, comprising: (See at least Jones [0083] Once the application selection module 130 of the mobile device 110 receives terminal transaction data 310, the application selection module 130 may send a set of transaction processing information 312 including the payment credentials and any other relevant transaction processing information to the access device 150. In some embodiments, the transaction processing information 312 can be sent in the form of a "get processing options" (GPO) response. In some embodiments, the transaction processing information may include one or more application file locators (AFLs) that can be used as file addresses by access device 150 to read account data stored on the mobile device 110, and an application interchange profile (AIP) that can be used to indicate the capabilities of the mobile payment application.
calling, by the target host program on the user terminal, the second SDK to query whether the target host program has a corresponding first identifier, wherein the first identifier indicates that a user account in a host program has a function of making payments using the network-wide payment platform; and (See at least Jones [0085] The card verification results (CVR) may include information about the CVM verifying entity and the CVM verified type for the transaction. The CVM verifying entity is used to indicate which entity is performing the verification of the CVM for the transaction. The verification entity may be the access device 150 (or terminal), a co-residing secure application, a trusted execution environment application, the mobile application 113 itself, a remote server (e.g., the cloud), or the mobile operating system. The CVM verified type is used to indicate the CVM method used for the transaction. The CVM method may be a passcode, biometric (e.g., fingerprint), pattern lock (e.g., for a screen lock), signature, or online PIN. In some embodiments, if the terminal transaction data 310 received from access device 150 indicates that the CVM supported by access device 150 is an online PIN or a signature, the CVM verifying entity in the CVR can be set to the access device 150 (or terminal) to indicate that access device 150 is the verifying entity, and the CVM verified type can be set accordingly (e.g., online PIN or signature).
in response to that the target host program has a corresponding first identifier, calling, by the target host program, the second SDK to send a first payment message to the network-wide payment platform, so that the network-wide payment platform sends the first payment message to the target host program platform, and the target host program platform performs a resource deduction of the target card to complete the payment using the target card, wherein the first payment message includes a host program identifier of the target host program and the first identifier corresponding to the target host program, (See at least Jones [0090] After the access device 150 receives the transaction processing information 312, the access device 150 may send an account data request 314 to the application selection module 130 of mobile device 110 to read additional account data 316 that may be stored on the mobile device 110. In some embodiments, the account data request 314 may be in the form of a "read record" command, and may include an application file locator (AFL) indicating the location of the account data that access device 150 is attempting to read. The AFL included in the account data request 314 may correspond to an AFL in the transaction processing information 312 that was provided to access device 150 from mobile device 110.
wherein the target card is a resource card bound to the target host program. (See at least Jones [0026] For example, a mobile phone may have various card data (e.g., debit card, credit card, etc.) provisioned into multiple payment applications which may be identified by application identifiers (AIDs).
Regarding Claim 13
sending a first payment request message to the network-wide payment platform through the e-commerce application program, wherein the first payment request message includes a user identifier and is used to instruct the network-wide payment platform to generate the first host program list based on historical payment data corresponding to the user identifier and/or a pre- stored payment priority strategy, and the first host program list includes host program identifiers of N host programs arranged from high to low priority, wherein N is a positive integer; and (See at least Jones [0040] A "first priority application identifier" or "preferred application identifier" may be an AID that has been determined to have the highest priority by an access device. The priority of each AID may be determined through any suitable method. For example, priority of AIDs may be based on consumer input (e.g., a consumer chooses their top three supported payment applications), closest match with configuration options for a device (e.g., applications associated with a preferred type of processing by the device are given priority), transaction security (e.g., applications that require a high level of authentication in order to process a transaction are given higher priority than other applications, payment networks with a better security track-record are provided priority), transaction processing speed (e.g., applications associated with a particular payment network that is faster than other payment networks are given higher priority), and/or any other information or processes may be used to prioritize AIDs associated with applications on the mobile device.
receiving a first payment feedback message sent by the network-wide payment platform, wherein the first payment feedback message includes the first host program list. (See at least Jones [0078] and [0079]: [0078] Upon receiving the available applications request 302, the application selection module 130 of the mobile device 110 may identify and process the request by recognizing the payment environment identifier (e.g., PPSE name) included in the request, and respond by sending an available applications response 304 back to access device 150. The available applications response 304 may include a list of available AIDs, application configuration options associated with available AIDs, and may include the payment environment identifier (e.g., PPSE name) as the dedicated file name. [0079] In some embodiments, the available applications response 304 may be in the form of a "select PPSE" response and may include PPSE file control information (FCI). For example, the available applications response 304 may include a directory entry for each available AID on the mobile device 110. Each directory entry may include information such as the AID, an application label associated with the AID (e.g., a mnemonic associated with the AID), an application priority indicator indicating the priority of the AID, a kernel identifier indicating the application's kernel preference, and/or additional information relating to the particular AID. The available applications response 304 may also include other data such as FCI issuer discretionary data.
Regarding Claim 14
The method according to claim 12, wherein, before calling up the target host program, the method further comprises: calling the first SDK to obtain a second host program list locally, wherein the second host program list includes host program identifiers of host programs owned by the user terminal; and (See at least Jones [0068] The application selection module 130 may include any sub-application, code, or software module installed on the mobile device 110 that is capable of performing the methods and functionality described herein. The application selection module 130 may be implemented as part of a mobile application 113 (as shown) or may be an independent application configured to interface with a mobile application 113. The application selection module 130 and the processor 111 may be configured to manage, identify, and communicate a list of AIDs associated with provisioned or installed payment applications on a secure element 120 (or other memory of the mobile communication device 110) as well as the corresponding priorities for the AIDs.
calling the first SDK to obtain an intersection of the first host program list and the second host program list and display the intersection, and in response to a first user input, determining, from the intersection, a host program corresponding to a host program identifier indicated in the first user input to be the target host program; or calling the first SDK to obtain an intersection of the first host program list and the second host program list, and determining a host program with a highest priority corresponding to a host program identifier in the intersection as the target host program. (See at least Jones [0040] A "first priority application identifier" or "preferred application identifier" may be an AID that has been determined to have the highest priority by an access device. The priority of each AID may be determined through any suitable method. For example, priority of AIDs may be based on consumer input (e.g., a consumer chooses their top three supported payment applications), closest match with configuration options for a device (e.g., applications associated with a preferred type of processing by the device are given priority), transaction security (e.g., applications that require a high level of authentication in order to process a transaction are given higher priority than other applications, payment networks with a better security track-record are provided priority), transaction processing speed (e.g., applications associated with a particular payment network that is faster than other payment networks are given higher priority), and/or any other information or processes may be used to prioritize AIDs associated with applications on the mobile device.
Regarding Claim 16
The method according to claim 12, wherein calling the second SDK by the target host program to interact with the network-wide payment platform, so that the network-wide payment platform interacts with the host program platform to complete the payment using a target card further comprises: when the target host program does not have a corresponding first identifier, calling the target host program to request a first identifier corresponding to the target host program from the network-wide payment platform through the host program platform; (See at least Jones [0119] Additionally, in some embodiments, the transaction initiation module 156 may determine that the selected mobile payment application and/or the payment credentials associated with the selected mobile payment application are not compatible for the transaction. For example, the payment network may be down or out of order during transaction processing. As another example, the transaction amount may be so large that a particular type of CVM is required that the application is not compatible with. Any other suitable methods may be implemented to determine that the transaction cannot or should not be completed.
calling the target host program to receive the first identifier corresponding to the target host program assigned by the network-wide payment platform through the host program platform; and (See at least Jones [0120] At step 408, the transaction initiation module 156 of the access device 150 may initiate a second transaction using the stored second transaction payload from the temporary memory. The transaction initiation module 156 of the access device 150 may determine the next highest priority transaction payload that is stored in the memory for the transaction, may obtain the transaction payload from the memory, and may initiate the transaction using similar steps as those described above in reference to step 406. For example, the transaction initiation module 156 may determine the CVM associated with the second mobile payment application, obtain the requisite cardholder verification method input from the consumer, verify the accuracy of the CVM input, and may generate an authorization request message and/or pass the transaction payload to a merchant computer 160 for generation of the authorization request message.
calling the second SDK to send a second payment message to the network-wide payment platform, so that the network-wide payment platform sends the second payment message to the host program platform, and the host program platform performs a resource reduction of the target card to complete the payment using the target card, wherein the second payment message includes the host program identifier of the target host program and the first identifier corresponding to the target host program. (See at least Jones [0121] At step 409, the transaction initiation module 156 of the access device 150 completes the processing of the transaction using the secondary transaction payload. For example, the transaction ignition module may send an authorization request message including the second transaction payload to an associated merchant computer 160, acquirer computer 170, and/or payment processing network for processing. Additional details regarding the remaining transaction flow and processing of the transaction is provided below in reference to the method shown in FIG. 5.
Regarding Claim 17
The method according to claim 16, wherein calling the target host program to request the first identifier corresponding to the target host program from the network- wide payment platform through the host program platform comprises: when logging in to the target host program, calling the target host program to send a first identifier request message to the host program platform, wherein the first identifier request message includes user identity information and is used to instruct the host program platform to send a second identifier request message to the network-wide payment platform, wherein the second identifier request message is used to request the first identifier, and the second identifier request message includes the user identity information and the host program identifier; and (See at least Jones [0099] At step 402, the multiple application selection module 153 of the access device 150 determines two or more AIDs for use in processing the transaction. For example, the access device 150 may determine a first AID and a second AID from the list of AIDs received from the mobile device 110. The access device 150 may be configured to initiate a transaction using the two or more AIDs and the access device 150 may determine the two or more AIDs through any suitable method. For example, a pre-selection process may be performed where the access device 150 determines the first and second highest priority AID based on the processing capabilities, configuration options, and processing capabilities associated with each AID.
calling the target host program to receive a first identifier feedback message sent by the host program platform, wherein the first identifier feedback message includes the first identifier, and the first identifier feedback message is generated based on a second identifier feedback message sent to the host program platform by the network-wide payment platform, wherein the second identifier feedback message includes the first identifier, and the first identifier is generated by the network-wide payment platform according to the user identity information, the host program identifier and pre-stored activated user identity information. (See at least Jones [0108] At step 403, the multiple application selection module 153 may obtain payment credentials associated with the primary AID and the secondary AID stored on the mobile device 110. Any suitable methods may be implemented for obtaining the payment credentials and any other transaction processing information may also be obtained. For example, obtaining the payment credentials may include sending one or more of the selected AIDs to the mobile device 110 and receiving the payment credentials and transaction processing information associated with the mobile payment application identified by the AID from the mobile device 110. In some embodiments, separate selection messages may be sent for each determined AID. Thus, the selection process may be repeated for a secondary selected AID and/or any other number of times for each of the selected AIDs. Alternatively, a single selection message may be sent that includes all of the determined AIDs.
Regarding Claim 19
The method according to claim 17, wherein the activated user identity information includes user identity information sent by the host program platform to the network- wide payment platform when the user applies for a resource card. (See at least Jones [0036] "Payment information" may include any data that may be used to identify an account and use the account for a payment transaction. For example, payment information may include payment credentials (e.g., primary account identifier (PAN), expiration date, card verification value (CVV), device authentication information (e.g., transaction cryptogram), dynamic authentication information (e.g., a dynamic cryptogram), etc.), personal information associated with a user or a consumer (e.g., name, billing address, residential address, date of birth, etc.), account information (e.g., issuer identifier (BIN), account issuance date, etc.), cardholder verification information (e.g., passcode, password, personal identification number (PIN), etc.), an indication of an authentication process for transaction processing (e.g., online PIN, signature, etc.) which may also be referred to as a cardholder verification method (CVM), and/or any other suitable or relevant information for performing a transaction.
Regarding Claim 20
The method according to claim 12, wherein, before calling the first SDK to obtain the first host program list from the network-wide payment platform, the method further comprises: in response to a second user input, obtaining order information from the network-wide payment platform through the e-commerce application program; and (See at least Jones [0078] Upon receiving the available applications request 302, the application selection module 130 of the mobile device 110 may identify and process the request by recognizing the payment environment identifier (e.g., PPSE name) included in the request, and respond by sending an available applications response 304 back to access device 150. The available applications response 304 may include a list of available AIDs, application configuration options associated with available AIDs, and may include the payment environment identifier (e.g., PPSE name) as the dedicated file name.
in response to a third user input to an order page, triggering the payment, wherein the order page includes the order information. (See at least Jones [0090] After the access device 150 receives the transaction processing information 312, the access device 150 may send an account data request 314 to the application selection module 130 of mobile device 110 to read additional account data 316 that may be stored on the mobile device 110. In some embodiments, the account data request 314 may be in the form of a "read record" command, and may include an application file locator (AFL) indicating the location of the account data that access device 150 is attempting to read. The AFL included in the account data request 314 may correspond to an AFL in the transaction processing information 312 that was provided to access device 150 from mobile device 110.
Regarding Claim 21
The method according to claim 12, further comprising: calling the second SDK to obtain a payment code from the network-wide payment platform, wherein the payment code is used for scanning by a payment acceptance terminal to initiate a payment request to the network-wide payment platform; or calling the second SDK to scan a collection code and initiate a payment request to the network-wide payment platform. (See at least Jones [[0077] The communication module 112 and the processor 111 of the mobile device 110 may be configured to identify the presence of an access device 150 within communication range. For example, the communication module 112 may ping or otherwise attempt to find suitable devices to communicate with periodically. When the access device 150 detects the presence of mobile device 110 in proximity to a contactless reader of the access device 150, the multiple application selection module 153 of the access device 150 may initiate a transaction by sending an available applications request 302 to the mobile device 110 to request information on which payment applications (e.g., a list of AIDs) may be available on the mobile device 110.
Allowable Subject Matter
Claim 18 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Prior Art of Record Not Currently Relied Upon
Selman et al. (US 2023/0043318 A1) Teaches: Client provisioned credentials for accessing third party data.
Marianne (US 2020/0346599 A1) Teaches: System for managing checkout experience based on merchant criteria.
Beadles et al. (US 2020/0258061 A1) Teaches: Universal subscription and cryptocurrency payment management platform.
Nitsch et al (US 20208/0202321 A1) Teaches: Integrated customer experience functionality in point of sale.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY MARK JAMES whose telephone number is (571)272-5155. The examiner can normally be reached M-F 8:30am - 5:00pm 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, Ryan Donlon can be reached at 571-270-3602. 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.
/GREGORY M JAMES/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692