DETAILED ACTION
This is a final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 17 in application 17/695998.
Claims 1-17 are pending.
Claims 1-9 are withdrawn.
Claim 10 is amended.
Claims 10-17 are examined on the merits.
Response to Arguments
Claim Rejections - 35 USC § 103
Applicant's arguments filed 08/07/2025 have been fully considered but they are not persuasive. Noe and Fiebiger each disclose local lists of identifiers used by a transit merchant to determine whether access to closed-loop service is supported and Noe further teaches generating an FSP from an FPAN and checking that FSP against blacklists/whitelists stored at the terminal, as well as updating those lists based on issuer responses. Tang discloses implementing such lists as lookup tables of unique identifiers and associated cryptographic keys at the payment terminal. The differences emphasized by applicant is whether the list is conceptualized as a “blacklist” or “allow-list,” and whether a token denied in an open-loop authorization is then placed on a local list for different future treatment which represents routine design choices in view of the combined teachings.
Under the broadest reasonable interpretation, a “closed-loop list identifying tokens for which a closed-loop service is supported” reasonably encompasses any stored list of token values (or identifiers derived from payment credentials) used locally by a service provider terminal to determine whether a user device may access a particular service. Nothing in claim 10 requires that the list contain only “allowed” tokens or that it cannot be implemented as a deny-list or as a combination of negative and positive entries.
Accordingly, the combination of Fiebiger, Noe, and Tang continues to teach all the limitations of the amended claims. Please see the updated rejection below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after 16 March 2013, is being examined under the first inventor to file provisions of the AIA .
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 inquires set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1066), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 10 – 17 are rejected under 35 U.S.C. § 103 as being unpatentable over Fiebiger et al. (US2008/0033880A1) hereinafter Fiebiger in view of Noe et al. (US2019/0005496A1), hereinafter Noe and in further view of Tang et al. (US2014/0337234A1), hereinafter Tang.
Regarding Claim 10. Fiebiger teaches (in BOLD): An enrolment method of a mobile terminal to a closed-loop service, comprising: receiving, by a first service provider terminal which is configured to support a service to a user of the mobile terminal, from the mobile terminal via a wireless communication standard,
Fiebiger – An antenna 120 can be provided for contactless communication (¶ 0022). As noted, cards 102, 112 are examples of a variety of payment devices that can be employed with techniques of the present invention. The primary function of the payment devices may not be payment, for example, they may be cellular phone handsets that implement techniques of the present invention. Such devices could include cards having a conventional form factor, smaller or larger cards, cards of different shape, key fobs, personal digital assistants (PDAs), appropriately configured cell phone handsets, or indeed any device with the capabilities to implement techniques of the present invention. The cards, or other payment devices, can include body portions (e.g., laminated plastic layers of a payment card, case or cabinet of a PDA, chip packaging, and the like), memories 108, 118 associated with the body portions, and processors 106, 116 associated with the body portions and coupled to the memories. The memories 108, 118 can contain appropriate applications. The processors 106, 116 can be operative to execute one or more method steps. The applications can be, for example, application identifiers (AIDs) linked to software code in the form of firmware plus data in a card memory such as an electrically erasable programmable read-only memory (EEPROM). Again, note that “smart” cards are not necessarily required and a conventional magnetic stripe card can be employed (¶ 0026). Such terminals can include a contact terminal (first service provider terminal) 122 configured to interface with contact-type device 102, a wireless terminal (mobile terminal) 124 configured to interface with wireless device (¶ 0027). The communications module can include, for example, the contacts 110 or antennas 120 together with appropriate circuitry (such as the aforementioned oscillator or oscillators and related circuitry) that permits interfacing with the terminals via contact or wireless communication (¶ 0029).
a unique encrypted token stored in a chip of the mobile terminal and linked to a Funding Primary Account Number which the unique encrypted token indicates that the mobile terminal is configured to be used in financial transactions;
Fiebiger - The memory portions or units 108, 118 may include different types of memory, such as volatile and non-volatile memory and read-only and programmable memory. The memory units can store transaction card data such as, e.g., a user's primary account number (“PAN”) (FPAN) and/or personal identification number (“PIN”). The memory portions or units 108, 118 can store the operating system of the cards 102, 112. The operating system loads and executes applications and provides file management or other basic card services to the applications. One operating system that can be used to implement the present invention is the MULTOS® operating system licensed by StepNexus Inc. Alternatively, JAVA CARD™-based operating systems, based on JAVA CARD™ technology (licensed by Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, Calif. 95054 USA), or proprietary operating systems available from a number of vendors, could be employed. Preferably, the operating system is stored in read-only memory (“ROM”) within memory portion 108, 118. In an alternate embodiment, flash memory or other non-volatile and/or volatile types of memory may also be used in the memory units 108, 118 (¶ 0024).
receiving, by the first service provider terminal from the financial institute server via a wireless communication standard, a denial signal as well as the FPAN;
Fiebiger - The communications module can include, for example, the contacts 110 or antennas 120 together with appropriate circuitry (such as the aforementioned oscillator or oscillators and related circuitry) that permits interfacing with the terminals via contact or wireless communication (¶ 0029). In AFC solution 1200, PayPass Card/device 1210 may be an ISO 14443 smart card or other device (e.g. key fob) containing the MasterCard PayPass application. Gate Reader 1220 may be a conventional turnstile or gate, which is augmented with an ISO 14443 card reader and a PayPass terminal application. Similarly, Bus Fare Box 1240 may be a conventional bus fare box, which is augmented with an ISO 14443 card reader and a PayPass terminal application. Ticket Vending Machine 1230 may be a conventional ticket vending machine, which is similar to those currently deployed by the MTA at subway stations. Station controller 1250 may be a conventional station controller, which is modified to process PayPass transactions and handle the negative file. Transit System Host 1260 may be an existing system host used by the MTA. Transit fare payment transactions may be routed via Host 1260 and Transaction Payment Platform 1270 to MasterCard Network 1292, which is presently deployed to process and route MasterCard transactions in the US and world-wide. Alternatively, the fare payment transactions may be routed to MasterCard Network 1292 via a separate gateway host (e.g., Network Gateway 296). Use of Network Gateway 1296 as an alternate to route fare payment transactions may minimize the processing load or impact on the existing system host used by the MTA.) (¶ 0122). As shown in Table 1, PayPass transit card processing procedure 1300 includes checks on the usage of PayPass cards at two stages. First, the presented card is checked against a negative file at gate 1220 (step 1312). Next, the presented card checked at Transit Payment Platform 1320 ( payment authorization steps 1322 a, 1323 a, and ride entitlement check step 1324 a). If either check fails, the card may be added to the negative file (¶ 0125). Further, Transit Payment Platform 1270 generates or maintains a negative file (denial signal), which is passed back to the MTA Transit System Host 1260 for distribution to station controllers 1250 (¶ 0123). If a pre-registered card account balance is depleted and not reloaded, the card will be added to the negative file (¶ 0140).
Fiebiger does not explicitly teach, however, Noe teaches (in Bold):
a unique encrypted token stored in a chip of the mobile terminal and linked to a Funding Primary Account Number which the unique encrypted token indicates that the mobile terminal is configured to be used in financial transactions;
Noe - This is because, for security reasons, when each new secondary payment device is set up to provide payment functionalities (e.g. by NFC, near field communication, with payment terminals), it is provisioned with a unique token known as a DPAN (device PAN), different to the FPAN (funding PAN) on the card linked to the account. The DPAN is the PAN the device passes to merchant terminals to make payments (¶ 0002). Tokenization may also be used as a way of securing chip and contactless card transactions, i.e. when a chip or contactless card communicates with a payment terminal, it provides a tokenized PAN as a surrogate for the PAN (¶ 0003). The DPAN and the FSP could be received in a signed or encrypted record (¶ 0015). calculated from an FPAN in a known way (e.g. via hashing). The FSP could be provided to secondary payment devices such as smartphones in addition to or in place of a DPAN (¶ 0073).
determining, by the first service provider terminal, that the unique token is not present on a closed-loop list stored in the first service provider terminal, the closed-loop list identifying tokens for which a closed-loop service is supported;
Noe - This is because, for security reasons, when each new secondary payment device is set up to provide payment functionalities (e.g. by NFC, near field communication, with payment terminals), it is provisioned with a unique token known as a DPAN (device PAN), different to the FPAN (funding PAN) on the card linked to the account. The DPAN is the PAN the device passes to merchant terminals to make payments (¶ 0002). According to a second aspect there is provided a method of blocking an electronic transaction, said method comprising a payment terminal: receiving a transaction request comprising one or more credentials from a payment device; determining whether said credentials comprise a funding source proxy (FSP) and, if not, generating the FSP from one or more of said credentials according to a predetermined algorithm stored on said payment terminal; determining that said FSP is present on a blacklist stored on the payment terminal; and declining said transaction request; wherein the FSP is derived from a funding primary account number (FPAN) of a funding source of said payment device (¶ 0007). According to a third aspect there is provided a method of blocking an electronic transaction, said method comprising a payment terminal: receiving a transaction, request comprising one or more credentials from a payment device; determining whether said credentials comprise a funding source proxy (FSP) and, if not, generating the FSP from one or more of said credentials according to a predetermined algorithm stored on said payment terminal; determining that said FSP is not present on a whitelist stored on the payment terminal; and declining said transaction request; wherein the FSP is derived from a funding primary account number (FPAN) of a funding source of said payment device (¶ 0008). According to a fourth aspect there is provided a method of authorizing an electronic transaction, said method comprising a payment terminal: receiving a transaction request comprising one or more credentials from a payment device; determining whether said credentials comprise a funding source proxy (FSP) and, if not, generating the FSP from one or more of said credentials according to a predetermined algorithm stored on said payment terminal; determining that said FSP is not present on a blacklist stored on the payment terminal; and authorizing said transaction request; wherein the FSP is derived from a funding primary account number (FPAN) of a funding source of said payment device (¶ 0009).
initiating, by the first service provider terminal, an open-loop financial transaction process, in response to an absence of the unique encrypted token from the closed-loop list, wherein the open-loop financial transaction process determines if the service is approved by a financial institute server associated with the unique encrypted token;
Noe - The method could further comprise the payment terminal, subsequent to issuing said request comprising the DPAN to said payment network, receiving a secondary payment device transaction approved message from the payment network (¶ 0022). Note: Noe’s transit flow likewise describes a transit agency passing transaction requests to the merchant’s bank and then to the issuer over a payment system network, where the issuer “determine whether to authorize or decline the payment (¶ 0060)” and responds with an approval or decline. This is an open-loop process involving issuer 150 as the financial institution server.
in response to the denial signal, linking, by the first service provider terminal, the FPAN to the unique encrypted token and adding the unique encrypted token to the closed-loop list.
Noe - According to a fourth aspect there is provided a method of authorizing an electronic transaction, said method comprising a payment terminal: receiving a transaction request comprising one or more credentials from a payment device; determining whether said credentials comprise a funding source proxy (FSP) and, if not, generating the FSP from one or more of said credentials according to a predetermined algorithm stored on said payment terminal; determining that said FSP is not present on a blacklist stored on the payment terminal; and authorizing said transaction request; wherein the FSP is derived from a funding primary account number (FPAN) of a funding source of said payment device (¶ 0009). The DPAN and the FSP could be received in a signed or encrypted record (¶ 0015).
enrolling the unique encrypted token of the mobile terminal to the closed-loop service such that the user of the mobile terminal is allowed.
Noe - The FSP can be checked against a list and provision of goods or services can be permitted or declined according to whether the FSP is present on the list (¶ 0074). On finding a match the payment terminal stops the customer 310 from obtaining the product or service they were attempting to access. This may for example be by way of a warning to a terminal operator, or by a gate to a transit service remaining closed (¶ 0081).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the account number of Fiebiger with the unique token of Noe because doing so allows a unique token to be linked to an account number to be used in financial transactions.
The combination of Fiebiger and Noe does not teach, however Tang teaches (in Bold):
in response to the denial signal, linking, by the first service provider terminal, the FPAN to the unique encrypted token and adding the unique token to the closed-loop list.
Tang - The mutual authentication process can be expedited, for example by transferring a public key in place of a complete certificate and/or by maintaining at each device a database of pre-authenticated certificates indexed by a lookup table (¶ 0007). If the pre-authentication is successful, the now-trusted L1, L2, and L3 public keys can be stored in the certificate repository 316 with a corresponding unique identifier being added to the lookup table 314 (¶ 0050). As also noted above, the payment terminal 102 can be configured to store new certificates obtained at runtime (e.g., from the mobile device 104) and to add them to the lookup table 314 to facilitate faster processing in the future. An exemplary process for storing a new certificate and adding it to the lookup table (¶ 0087).
enrolling the unique encrypted token of the mobile terminal to the closed-loop service such that the user of the mobile terminal is allowed.
Tang - The mutual authentication process can be expedited, for example by transferring a public key in place of a complete certificate and/or by maintaining at each device a database of pre-authenticated certificates indexed by a lookup table (¶ 0007). If the pre-authentication is successful, the now-trusted L1, L2, and L3 public keys can be stored in the certificate repository 316 with a corresponding unique identifier being added to the lookup table 314 (¶ 0050). As also noted above, the payment terminal 102 can be configured to store new certificates obtained at runtime (e.g., from the mobile device 104) and to add them to the lookup table 314 to facilitate faster processing in the future. An exemplary process for storing a new certificate and adding it to the lookup table (¶ 0087).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the account number of Fiebiger with the unique token of Noe and with the adding of unique identifier of Tang because doing so allows a unique token to be encrypted and linked to an account number via a wireless communication channel to be used in financial transactions.
Regarding Claim 11. The combination Fiebiger, Noe, and Tang further teaches: The enrolment method of claim 10, comprising: wherein the open-loop financial transaction process, by the first service provider terminal, sending the unique encrypted token to the financial institute server, mapping, by the financial institute server, the unique encrypted token to the linked FPAN,
Fiebiger - Thus, by way of example and not limitation, instructions executing on one processor might facilitate an action carried out by instructions executing on a remote processor, by sending appropriate data or commands to cause or aid the action to be performed. At block 506, a step of facilitating passing of the account number to the active file manager 208 is conducted. For example, the account number can be passed through the acquiring entity to manager 208 (¶ 0047). The web based customer interface also may allow cardholders to enroll and un-enroll for pre-funded accounts. FIG. 10 shows a process 1400 by which a customer who is mailed a PayPass card by an issuing bank can pre-register the PayPass card for use on a transit system, and link the card to a pre-funded transit account. At step 1441 of process 1400, the bank mails the PayPass card to the cardholder. At step 1442, the cardholder may elect to register the card with the transit system. If the cardholder does not elect to register the card, the cardholder can still use the card for post-paid fare transactions on the transit system. If the cardholder elects to register the card, PayPass Transit Payment Platform 1510 at step 1443 sets up a pre-funded account associated with the card at an Automated Credit Service (ACS). The cardholder may further choose at step 1444 to activate automatic reload features for the pre-funded account. If the cardholder does not choose to activate automatic reload, a pre-funded account is assigned a onetime value (step 1446). Conversely, if the cardholder chooses to activate automatic reload features, account load limits are set up for automatic reloading at step 1445. Step 1445 may utilize a conventional address verification service (AVS) to check cardholder qualifications. The issuing bank may be notified if for three consecutive enrollment attempts the AVS check fails. However, the failing card may not be automatically hot listed. The issuing bank will have the necessary information and may choose to either hot list the card or allow the AVS checking parameters to be reset (¶ 0139).
sending, by the financial institute server via wireless communication standard, a pre-authorization request for a financial settlement to a dedicated bank server the pre-authorization request including the linked FPAN, and
Fiebiger - In addition to, or in lieu of, setting a spending limit to zero, one could instead set a flag to indicate that the issuer declined the authorization. If the transaction is approved, a spending limit equal to the activity limit amount for a certain time period (e.g. the pre-authorization amount for a day), preferably (but optionally) less the value of the first transaction, can be established, again, e.g., via an appropriate entry in the active file (¶ 0039).
receiving, by the financial institute server via a wireless communication standard, a denial message to the pre- authorization request from the dedicated bank server.
Fiebiger - Terminal controller 1150 responds by either accepting or rejecting the card. The customer is accordingly given or denied access through the turnstile. Terminal controller 1150 software communicates a transaction data record to PayPass Transit Payment Platform 1160. Pay Pass Transit Payment Platform 1160 provides necessary authorizations and batch settlement processing functions for transactions, as well as continued maintenance of the card terminal software (¶ 0107).
Regarding Claim 12. The combination Fiebiger, Noe, and Tang further teaches: The enrolment method of claim 11, comprising: sending the dedicated bank server via a wireless communication standard, after the dedicated bank server has received the pre-authorization request from the financial institute server a push message to the mobile terminal indicating that the unique encrypted token has been registered for the closed-loop service.
Fiebiger - Principles of the present invention provide techniques for authorization of usage of a payment device. The payment device could be used, for example, at a merchant (broadly understood to include any entity providing products and/or services or acting for such an entity). The payment device can have an associated account number. In one or more embodiments, authorization can be conducted effectively, yet sufficiently quickly, even for relatively low cost and/or high volume environments, such as transit systems and the like. An exemplary embodiment of a method (which can be computer-implemented), according to one aspect of the invention, for such authorization, includes the steps of facilitating an issuer of the device obtaining an authorization message for the account number, based on desired spending limit parameters established by at least one of the merchant and the issuer; facilitating obtaining an issuer authorization decision; and responsive to the issuer authorization decision, facilitating setting a spending limit for the account number based on at least an appropriate one of the parameters. The spending limit parameters could include, for example, an aggregation limit for a post-funded payment device and/or a decrementing limit for a pre-funded payment device. In some instances, other fare types (e.g. time based, transfers, special class, and the like) can be accommodated, and can be funded on either a pre or post basis (¶ 0008).
Regarding Claim 13. The combination Fiebiger, Noe, and Tang further teaches: The enrolment method of claim 10, comprising: after receiving the unique encrypted token from the mobile terminal via a wireless communication standard, by the service provider terminal performing the method according to any of the claims 1-7 in which the unique encrypted token is said account number.
Fiebiger - Attention should now be given to FIG. 1, which depicts an exemplary embodiment of a system 100, according to an aspect of the present invention, and including various possible components of the system. System 100 can include one or more different types of portable payment devices. For example, one such device can be a contact device such as card 102. Card 102 can include an integrated circuit (IC) chip 104 having a processor portion 106 and a memory portion 108. A plurality of electrical contacts 110 can be provided for communication purposes. In addition to or instead of card 102, system 100 can also be designed to work with a contactless device such as card 112. Card 112 can include an IC chip 114 having a processor portion 116 and a memory portion 118. An antenna 120 can be provided for contactless communication, such as, for example, using radio frequency (RF) electromagnetic waves. An oscillator or oscillators, and/or additional appropriate circuitry for one or more of modulation, demodulation, downconversion, and the like can be provided. Note that cards 102, 112 are exemplary of a variety of devices that can be employed with techniques of the present invention. Other types of devices could include a conventional card 150 having a magnetic stripe 152, an appropriately configured cellular telephone handset, and the like. Indeed, techniques of the present invention can be adapted to a variety of different types of cards, terminals, and other devices (¶ 0022).
A method of providing a service to a user comprising: receiving, by a first service provider terminal, an account number stored in a chip of a mobile device configured to be used in open-loop financial transactions, from the mobile device.
Fiebiger – As noted, cards 102, 112 are examples of a variety of payment devices that can be employed with techniques of the present invention. The primary function of the payment devices may not be payment, for example, they may be cellular phone handsets that implement techniques of the present invention. Such devices could include cards having a conventional form factor, smaller or larger cards, cards of different shape, key fobs, personal digital assistants (PDAs), appropriately configured cell phone handsets, or indeed any device with the capabilities to implement techniques of the present invention. The cards, or other payment devices, can include body portions (e.g., laminated plastic layers of a payment card, case or cabinet of a PDA, chip packaging, and the like), memories 108, 118 associated with the body portions, and processors 106, 116 associated with the body portions and coupled to the memories. The memories 108, 118 can contain appropriate applications. The processors 106, 116 can be operative to execute one or more method steps. The applications can be, for example, application identifiers (AIDs) linked to software code in the form of firmware plus data in a card memory such as an electrically erasable programmable read-only memory (EEPROM). Again, note that “smart” cards are not necessarily required and a conventional magnetic stripe card can be employed (¶ 0026). Such terminals can include a contact terminal (first service provider terminal) 122 configured to interface with contact-type device 102, a wireless terminal (mobile terminal) 124 configured to interface with wireless device (¶ 0027). The memory portions or units 108, 118 may include different types of memory, such as volatile and non-volatile memory and read-only and programmable memory. The memory units can store transaction card data such as, e.g., a user's primary account number (“PAN”) (FPAN) and/or personal identification number (“PIN”). The memory portions or units 108, 118 can store the operating system of the cards 102, 112. The operating system loads and executes applications and provides file management or other basic card services to the applications. One operating system that can be used to implement the present invention is the MULTOS® operating system licensed by StepNexus Inc. Alternatively, JAVA CARD™-based operating systems, based on JAVA CARD™ technology (licensed by Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, Calif. 95054 USA), or proprietary operating systems available from a number of vendors, could be employed. Preferably, the operating system is stored in read-only memory (“ROM”) within memory portion 108, 118. In an alternate embodiment, flash memory or other non-volatile and/or volatile types of memory may also be used in the memory units 108, 118 (¶ 0024).
“the method according to any of the claims 1-7” - Claim 1: receiving, by a first service provider terminal, an account number stored in a chip of a mobile device configured to be used in open-loop financial transactions, from the mobile device;
Fiebiger - The memory portions or units 108, 118 may include different types of memory, such as volatile and non-volatile memory and read-only and programmable memory. The memory units can store transaction card data such as, e.g., a user's primary account number (“PAN”) (FPAN) and/or personal identification number (“PIN”). The memory portions or units 108, 118 can store the operating system of the cards 102, 112. The operating system loads and executes applications and provides file management or other basic card services to the applications. One operating system that can be used to implement the present invention is the MULTOS® operating system licensed by StepNexus Inc. Alternatively, JAVA CARD™-based operating systems, based on JAVA CARD™ technology (licensed by Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, Calif. 95054 USA), or proprietary operating systems available from a number of vendors, could be employed. Preferably, the operating system is stored in read-only memory (“ROM”) within memory portion 108, 118. In an alternate embodiment, flash memory or other non-volatile and/or volatile types of memory may also be used in the memory units 108, 118 (¶ 0024).
checking, by the first service provider terminal if the received account number is present on a closed-loop list stored in the first service provider terminal, the closed-loop list identifying account numbers for which a closed-loop service is supported;
Fiebiger - Exemplary implementations of solution 1100 based on MasterCard's PayPass may be configured to be consistent or compatible with pre-existing the fare structures and card or ticket types that are used by the transit system. Appendix A shows a fare structure for MTA/NY Transit. Further, Appendix B shows in tabular form a comparison of the transit fare structure features supported by each of the three card types discussed above. Solution 1100 may be configured to support any number of AFC architectures or schemes. An exemplary AFC architecture—“Host plus Distributed Negative File,” is based on the use of standard PayPass payment cards. In this architecture, there is no need for any special transit application to be loaded onto the payment cards. A customer presents a standard PayPass card 1110 to turnstile 1130/reader 1132 for fare collection. Turnstile 1130 validates the card data (e.g., personal account number, Expiry Date, and card validation code) and checks whether the card is listed in a negative file or hot list. If the card is listed in the negative file, turnstile 1130/terminal 1150 deny the customer access to the gated pay areas of the transit system. Conversely, if the card is not listed in the negative file, turnstile 1130/terminal 1150 activates a gate to allow the customer access to the pay areas of the transit system. Turnstile 1130/terminal 1150 concurrently or later forwards a raw transaction data record associated with the card use to the transit payment platform 1160, which may be configured to process single-ride, pay-per-ride and unlimited ride transactions. Transit payment platform 1160 receives raw transactions from transit system (e.g., MTA) and processes them against registered customer accounts. Where appropriate, transit payment platform host 1140 may forward the single-ride transaction data to an acquirer 1170 for further processing. Transit payment platform host 1140 generates and maintains the negative file, which is distributed to turnstiles 1130, for example, via terminal controller 150 (¶ 0116). FIG. 8 shows AFC solution 1200, which is an exemplary implementation of the Host plus Distributed Negative File AFC architecture in a mass transit system. The structural components of this solution include entities such as PayPass issuers 1290, and software and hardware components such as a standard PayPass Card/device 1210, a Gate Reader 1220, Ticket Vending Machine 1230, Bus Fare Box 1240, station controller 1250, a Transit System Host 1260, a Transit Payment platform 1270, PayPass Card issuers 1290, a rePower Host 1280 and electronic payments network (MasterCard Network 1292) (¶ 0121).
if so, forwarding, by the first service provider terminal, the received account number to a service provider server configured to either approve or deny, respectively, the closed-loop service and
Fiebiger - In AFC solution 1200, PayPass Card/device 1210 may be an ISO 14443 smart card or other device (e.g. key fob) containing the MasterCard PayPass application. Gate Reader 1220 may be a conventional turnstile or gate, which is augmented with an ISO 14443 card reader and a PayPass terminal application. Similarly, Bus Fare Box 1240 may be a conventional bus fare box, which is augmented with an ISO 14443 card reader and a PayPass terminal application. Ticket Vending Machine 1230 may be a conventional ticket vending machine, which is similar to those currently deployed by the MTA at subway stations. Station controller 1250 may be a conventional station controller, which is modified to process PayPass transactions and handle the negative file. Transit System Host 1260 may be an existing system host used by the MTA. Transit fare payment transactions may be routed via Host 1260 and Transaction Payment Platform 1270 to MasterCard Network 1292, which is presently deployed to process and route MasterCard transactions in the US and world-wide. Alternatively, the fare payment transactions may be routed to MasterCard Network 1292 via a separate gateway host (e.g., Network Gateway 296). Use of Network Gateway 1296 as an alternate to route fare payment transactions may minimize the processing load or impact on the existing system host used by the MTA.) (¶ 0122). As shown in Table 1, PayPass transit card processing procedure 1300 includes checks on the usage of PayPass cards at two stages. First, the presented card is checked against a negative file at gate 1220 (step 1312). Next, the presented card checked at Transit Payment Platform 1320 ( payment authorization steps 1322 a, 1323 a, and ride entitlement check step 1324 a). If either check fails, the card may be added to the negative file (¶ 0125). Further, Transit Payment Platform 1270 generates or maintains a negative file (denial signal), which is passed back to the MTA Transit System Host 1260 for distribution to station controllers 1250 (¶ 0123). ). If a pre-registered card account balance is depleted and not reloaded, the card will be added to the negative file (¶ 0140).
receiving, from the service provider server, either an approval signal or denial signal;
Fiebiger - Optional rePower Host 1280 may be any host system that is configured to reload value based and time based (pre-funded) card accounts automatically or in response to requests. rePower is MasterCard's branded facility for loading value to pre-funded accounts. The rePower host may have suitable interfaces that facilitate reload requests, for example, via the Internet, text message, or telephone. rePower Host 1280 provides updated reload information to linked Transit Payment Platform 1270. When a customer presents PayPass Card/device 1210 for fare payment, solution 1200 may use an exemplary PayPass transit card processing procedure 1300 for AFC according to the fare type (e.g., single ride, value based pay-per-ride, or time based). Exemplary process steps and outcomes that take place at Gate Reader 1220 and/or at Transit Payment Platform 1270 are listed in Table 1 (reproduced in FIGS. 12A and B) (¶ 0124). Solution 1200 may be configured to provide a cardholder with an automatic top-up option, which replenishes value to a pre-funded transit account from an associated debit or credit card when the account balance falls below a certain level. In a transaction for loading value, rePower Host 1280 may first deduct fares for unpaid rides or alternatively add refunds to the designated load amount for the transit account. Further, negative file entries associated with the re-loaded card are deleted (¶ 0131).
if not, either denying the service or initiating, by the first service provider terminal, an open-loop financial transaction process in which it is checked if the service is approved by a financial institute server associated with the received account number
Fiebiger - Optional rePower Host 1280 may be any host system that is configured to reload value based and time based (pre-funded) card accounts automatically or in response to requests. rePower is MasterCard's branded facility for loading value to pre-funded accounts. The rePower host may have suitable interfaces that facilitate reload requests, for example, via the Internet, text message, or telephone. rePower Host 1280 provides updated reload information to linked Transit Payment Platform 1270. When a customer presents PayPass Card/device 1210 for fare payment, solution 1200 may use an exemplary PayPass transit card processing procedure 1300 for AFC according to the fare type (e.g., single ride, value based pay-per-ride, or time based). Exemplary process steps and outcomes that take place at Gate Reader 1220 and/or at Transit Payment Platform 1270 are listed in Table 1 (reproduced in FIGS. 12A and B) (¶ 0124). Solution 1200 may be configured to provide a cardholder with an automatic top-up option, which replenishes value to a pre-funded transit account from an associated debit or credit card when the account balance falls below a certain level. In a transaction for loading value, rePower Host 1280 may first deduct fares for unpaid rides or alternatively add refunds to the designated load amount for the transit account. Further, negative file entries associated with the re-loaded card are deleted (¶ 0131).
Regarding Claim 14. The combination Fiebiger, Noe, and Tang further teaches: The enrolment method of claim 10, comprising: after said action of receiving by the first service provider terminal from the financial institute server said denial signal as well as said FPAN, sending at least said unique token to said PTO server-sending, by said PTO terminal, said unique token to other PTO terminal and;
Fiebiger - In an implementation of payment solution 1100, customers may set-up and register pre-funded transit accounts, which are linked to the customers' PayPass cards. In practice, a customer presents or “taps” or his or her PayPass card 1110 at card reader 1130 mounted on transit turnstile 1132 to gain access to the gated pay areas of the transit system. Data encoded in the card is read and transmitted to terminal controller 1150. Terminal controller 1150 responds by either accepting or rejecting the card. The customer is accordingly given or denied access through the turnstile. Terminal controller 1150 software communicates a transaction data record to PayPass Transit Payment Platform 1160. Pay Pass Transit Payment Platform 1160 provides necessary authorizations and batch settlement processing functions for transactions, as well as continued maintenance of the card terminal software (¶ 0107).
storing, by said other PTO terminals, said received unique token.
Fiebiger - The memory portions or units 108, 118 may include different types of memory, such as volatile and non-volatile memory and read-only and programmable memory. The memory units can store transaction card data such as, e.g., a user's primary account number (“PAN”) and/or personal identification number (“PIN”). The memory portions or units 108, 118 can store the operating system of the cards 102, 112. The operating system loads and executes applications and provides file management or other basic card services to the applications. One operating system that can be used to implement the present invention is the MULTOS® operating system licensed by StepNexus Inc. Alternatively, JAVA CARD™-based operating systems, based on JAVA CARD™ technology (licensed by Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, Calif. 95054 USA), or proprietary operating systems available from a number of vendors, could be employed. Preferably, the operating system is stored in read-only memory (“ROM”) within memory portion 108, 118. In an alternate embodiment, flash memory or other non-volatile and/or volatile types of memory may also be used in the memory units 108, 118 (¶ 0024).
Regarding Claim 15. The combination Fiebiger, Noe, and Tang further teaches: A system comprising a first service provider terminal wherein the first service provider terminal is configured to perform the method of claim 10.
Fiebiger - A number of different types of terminals can be employed with system 100. Such terminals can include a contact terminal 122 configured to interface with contact-type device 102, a wireless terminal 124 configured to interface with wireless device 112, a magnetic stripe terminal 125 configured to interface with a magnetic stripe device 150, or a combined terminal 126. Combined terminal 126 is designed to interface with any type of device 102, 112, 150. Some terminals can be contact terminals with plug-in contactless readers. Combined terminal 126 can include a memory 128, a processor portion 130, a reader module 132, and optionally an item interface module such as a bar code scanner 134 and/or a radio frequency identification (RFID) tag reader 136. Items 128, 132, 134, 136 can be coupled to the processor 130. Note that the principles of construction of terminal 126 are applicable to other types of terminals and are described in detail for illustrative purposes. Reader module 132 can be configured for contact communication with card or device 102, contactless communication with card or device 112, reading of magnetic stripe 152, or a combination of any two or more of the foregoing (different types of readers can be provided to interact with different types of cards e.g., contacted, magnetic stripe, or contactless). Terminals 122, 124, 125, 126 can be connected to one or more processing centers 140, 142, 144 via a computer network 138. Network 138 could include, for example, the Internet, or a proprietary network. More than one network could be employed to connect different elements of the system. Processing centers 140, 142, 144 can include, for example, a host computer of an issuer of a payment device. Further details regarding one specific form of network will be provided below (¶ 0027).
Regarding Claim 16. The combination Fiebiger, Noe, and Tang further teaches: The system of claim 15, wherein the system also comprises a financial institute server.
Fiebiger - One or more inventive embodiments may address the aforementioned issues by making a fast decision, using the same criteria as in normal credit card authorization, but on a high-speed, transit-specific platform (or platform specific to other applications with fast transaction time requirements). The aforementioned AFM may function as a gateway to a payment processing network, such as the MasterCard Banknet® communications network, and may typically be resident on a merchant's or acquirer's premises—in one or more instances, the AFM may be a server that the operator of a payment network places on the merchant's or acquirer's premises to help facilitate such parties performing authorizations. As noted elsewhere herein, the AFM may have access to files or lists such as Restricted Card Lists (RCLs), a restricted list from a transit authority, and so on—such lists may include, for example, account numbers associated with fraudulently used, stolen, and/or lost cards, and the like. Advantageously, in one or more preferred inventive embodiments, the RCL and the like reside on the AFM and not in a terminal such as a turnstile (¶ 0061).
Regarding Claim 17. The combination Fiebiger, Noe, and Tang further teaches: The system of claim 15, wherein the system also comprises a dedicated bank server.
Fiebiger - In one or more embodiments, a high-speed telecommunications network, with a minimum speed of 768 kbps, can be employed, for example, from the turnstile (fare gate) to the server. The server may be resident, for example, on merchant (transit authority) premises, on an acquirer's premises, or housed in a facility of an operator of a payment card network (such as MasterCard International Incorporated) or a facility of a third party processor, and the server may be operated, for example, by the aforementioned operator of a payment card network, or by a third party vendor. In one or more embodiments, the aforementioned server functionality may be embodied, for example, in the payment platform 704. In general terms, the platform and AFM can physically reside anywhere; for example, the Transit Agency premises, premises of a Third Party Processor/AFM Integrator, or even on the Premises of the operator of a payment card network, such as MasterCard International Incorporated. It is, however, desirable that there are high speed connections between the Terminal estate, the platform, the AFM, and payment processing system (such as MasterCards BankNet network or the like (¶ 0053).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Campos (US2013/0304642A1) - In some embodiments, fast and secure communication can be achieved (e.g., in a fueling environment payment system) with systems and methods that validate an authentication request based on one or more pre-validated cryptographic keys.
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 CHRISTINA C STEVENSON whose telephone number is (571)270-7280. The examiner can normally be reached on Monday - Friday from 8am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick Mcatee, can be reached at telephone number 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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights