DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the amendment filed on 10/16/2025.
Claims 1, 4, 6, 11, 12, 14, and 16 have been amended and are hereby entered.
Claims 2 has been canceled.
Claims 1 and 3-20 are currently pending and have been examined.
This action is made FINAL.
Response to Arguments
Applicant’s arguments, see pages 17-18, filed 10/16/2026, with respect to claims 1 and 3-20 rejected under 35 USC 101 have been fully considered and are persuasive. The 103 rejection of claims 1 and 3-19 has been withdrawn.
Applicant's arguments filed 10/16/2025 with respect to claims 1 and 3-20 rejected under 35 USC 101 have been fully considered but they are not persuasive. Applicant argues that the payment token comprising the payment token issuer identifier is a tool that improves account security in that token server can identify the issuer based on the token issuer ID and issuers cannot be identified merely by reviewing or parsing a token. The Examiner respectfully disagrees, these are record keeping task similar to Alice Corp., and ineligible for the same reasons, in which the Court walked through the test and found:
The Court identified the additional elements in the claim, e.g., by noting that the method claims recited steps of using a computer to "create electronic records, track multiple transactions, and issue simultaneous instructions", and that the product claims recited hardware such as a "data processing system" with a "communications controller" and a "data storage unit" (573 U.S. at 224-26, 110 USPQ2d at 1984-85);
The Court considered the additional elements individually, noting that all the computer functions were "‘well-understood, routine, conventional activit[ies]' previously known to the industry," each step "does no more than require a generic computer to perform generic computer functions", and the recited hardware was "purely functional and generic" (573 U.S. at 225-26, 110 USPQ2d at 1984-85); and
In the instant application, the issuer ID’s are akin to creating electronic records for tracking the payment tokens. MPEP 2106.05(f) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);
With respect to communication interfaces, this is generally the idea to a particular environment, and the prior art shows the use of APIs to send and receive data was well known as evident by NPL API 101: What is an API?, which discloses “Put simply, an API is an interface that applications can use to share data. Instead of directly sharing data from the application's source, an API is used as a safe go-between… Think of an API as a side door that allows you to retrieve data from a guarded room. Once you’ve gained access, you’re able to share data with the owner of the API and use their data to suit your needs... Many popular web applications provide a portion of their data using APIs.” and there for the use of the interfaces in the instant application does not amount to a practical application, rather this is generally linking the idea to particular environment (computers). Mere instructions to apply the judicial exception using generic computer components and limiting the judicial exception to a particular environment are not indicative of a practical application (see MPEP 20106.05(f) and MPEP 20106.05(h)).
With respect to DDR, the claims here are not like those the Court found patent eligible in DDR, in which the inventive concept was in the modification of conventional mechanics behind website display to produce a dual-source integrated hybrid display because applicant’s claims here do not address problems unique to the Internet or require an arguably inventive device or technique for displaying information, rather the claims are directed towards fundamental economic practices for assigning, generating and using payment tokens for accounts associated with an issuer, and using tokenizing transaction information to obtain information about the token so that they can assess whether the token is legitimate, and/or whether the transaction is a fraudulent transaction could be considered risk mitigation steps and further describes the abstract idea.
With respect to applicant’s arguments on page 13 and that the claims enable parties to obtain the information that they need (and are authorized to), to perform, for example, fraud analyses, as initial matter, these features are not reflected in the claims, regardless, MPEP 2106.05(d) shows receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 224-26, 110 USPQ2d 1984-1985 (2014) (see also creating and maintaining "shadow accounts", "create electronic records, track multiple transactions, and issue simultaneous instructions" (, Alice Corp. Pty. Ltd. v. CLS Bank Int'l 573 U.S. at 224-26, 110 USPQ2d at 1984-85);, Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log) are WURC. The same applies for mapping the issuer identifier, as these are recording keeping steps and address abstract business problem and not technical problems. For the same reasons as discussed above, and as MPEP 2106.05(f) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);, the claims fail to amount to significantly more or a practical application.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 and 3-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more and fails step 2 of the analysis because the focus of the claims is not on the devices themselves or a practical application but rather directed towards an abstract idea, the analysis is provided below.
Step 1 (Statutory Categories) - The claims pass step 1 of the subject matter eligibility test (see MPEP 2106(III)) as the claims are directed towards a system, and method.
Step 2A – Prong One (Do the claims recite an abstract idea?) - The idea is recited in the claims, in part, by:
assign a payment token issuer identifier to an issuer, wherein the payment token issuer identifier is static for the issuer for all accounts issued by the issuer;
generate a payment token corresponding to an account identifier issued by the issuer, the payment token comprising the payment token issuer identifier of the issuer that replaces and obfuscates a publicly available real identification number of the issuer, wherein all payment tokens generated for accounts issued by the issuer including the real identification number of the issuer instead include the same payment token issuer identifier;
transmit the payment token to a token requestor, wherein the token requestor is authorized to receive the payment token;
receive, from an acquirer, an authorization request message comprising the payment token, wherein the authorization request message is associated with a transaction;
identify the issuer identified by the payment token issuer identifier;
identify an issuer communication interface provided by the system; and
transmit the authorization request message to the issuer identified by the payment token issuer identifier, wherein the issuer is authorized to obtain a real account identifier.
The steps recited above under Step 2A Prong One of the analysis and under the broadest reasonable interpretation covers fundamental economic principles or practices but for the recitation of generic computer components. That is other than reciting one or more processors, a non-transitory computer readable medium, a token requestor communication interface provided by the system, an acquirer computer, an acquirer communication interface, and an issuer communication interface nothing in the claim elements are directed towards anything other than fundamental economic principles or practices assigning, generating and using payment tokens for accounts associated with an issuer. If a claim limitation, under its broadest reasonable interpretation, covers fundamental economic principles or practices, then it falls within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas. Accordingly, the claims recite an abstract idea.
Step 2A – Prong Two (Does the claim recite additional elements that integrate the judicial exception into a practical application?) - This judicial exception is not integrated into a practical application. In particular, the claims only recite the additional elements of one or more processors, a non-transitory computer readable medium, a token requestor communication interface provided by the system, an acquirer computer, an acquirer communication interface, and an issuer communication interface. The one or more processors, non-transitory computer readable medium, token requestor communication interface provided by the system, acquirer computer, acquirer communication interface, and issuer communication interface are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular environment of computers. The acquirer communication interface and issuer communication interface are defined in the specification [0084] as “An "interface" may include any software module configured to process communications. For example, an interface may be configured to receive, process, and respond to a particular entity in a particular communication format… In some embodiments, an interface may include an application programming interface (API) or other communication format or protocol that may be provided to third parties or to a particular entity to allow for communication with a device.” In light of the description, the use of the interfaces in the instant application fails to integrate the claims into a practical application as they are merely being used as tools and instructions to receive, process, and respond to a particular entity in a particular communication format according to a communication format or protocol. As MPEP 2106.05(f) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);. Additionally, the prior art shows the use of APIs to send and receive data was well known as evident by NPL API 101: What is an API?, which discloses “Put simply, an API is an interface that applications can use to share data. Instead of directly sharing data from the application's source, an API is used as a safe go-between… Think of an API as a side door that allows you to retrieve data from a guarded room. Once you’ve gained access, you’re able to share data with the owner of the API and use their data to suit your needs... Many popular web applications provide a portion of their data using APIs.” and there for the use of the interfaces in the instant application does not amount to a practical application, rather this is generally linking the idea to particular environment (computers). Mere instructions to apply the judicial exception using generic computer components and limiting the judicial exception to a particular environment are not indicative of a practical application (see MPEP 20106.05(f) and MPEP 20106.05(h)). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed towards an abstract idea.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) - The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, with respect to integration of the abstract idea into a practical application, using the additional elements of one or more processors, a non-transitory computer readable medium, a token requestor communication interface provided by the system, an acquirer computer, an acquirer communication interface, and an issuer communication interface to perform the steps recited in Step 2A Prong One of the analysis amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular environment. Mere instructions to apply an exception using generic computer components and limiting the judicial exception to a particular environment does not provide an inventive concept. The additional elements have been considered separately, and as an ordered combination, and do not add significantly more (also known as an “inventive concept”) to the judicial exception. Further, MPEP 2106.05(d)(ii) provides that receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 224-26, 110 USPQ2d 1984-1985 (2014) (see also creating and maintaining "shadow accounts", "create electronic records, track multiple transactions, and issue simultaneous instructions" (, Alice Corp. Pty. Ltd. v. CLS Bank Int'l 573 U.S. at 224-26, 110 USPQ2d at 1984-85);, Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); and use of API’s as discussed above, are well-understood routine and conventional, similar to the instant application claims which recites and sending and receiving data over network, and performing recording keeping task akin to Alice for assigning, generating and using payment tokens for accounts associated with an issuer. The claims are not patent eligible.
The dependent claims have been given the full analysis including analyzing the additional limitations both individually and in combination as a whole. For instance, claims 3-8 are all steps that fall within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas, generally linking the use of the judicial exemption to a particular technical computing environment similar to as discussed above with respect to merchant computer. With respect to claim 9-10, applying domain restrictions and restricting the use of the token to particular channels, does not amount to significant more or a practical application as this could be considered risk mitigation steps and do not result in a technical improvement or practical application, but for generally linking the idea to a particular environment, see also Restricting public access to media by requiring a consumer to view an advertisement, Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716-17, 112 USPQ2d 1750, 1755-56 (Fed. Cir. 2014); and a general method of screening emails on a generic computer, Symantec, 838 F.3d at 1315-16, 120 USPQ2d at 1358-59; . The Dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 for the same reasoning as above and the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional limitations of the dependent claims when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Brooks, et al. (US Patent Application Publication 20120209734) discloses “The universal product-transaction identifier 41 may be a numerical identifier that includes an IIN 51, i.e., a number, typically six (6) digits, for example, used to identify the issuing bank or other issuer so that messages can be routed through the payment network; a unique product identifier number 53 used for identifying a specific product, and a checksum digit 55. In operation, a manufacturer or product supplier working with an issuer or processor, or the issuer, itself, assigns a different payment network compatible payment card number received from the issuer to each product. In addition, an individual issuer could assign multiple IIN numbers for different product providers, and the payment network would route each of the IIN numbers to the same issuer for processing, i.e., parsing the universal product transaction identifier number 41, by manufacturer and then associating the product identifier number to the product. For example, as shown in FIG. 6, the issuer could assign Soft Drink Company X the IIN 400001 and Soft Drink Company X could associate the product identifier 4000 . . . 01 for its Orange 12 oz; 4000 . . . 02 for its Orange 32 oz; 4000 . . . 03 for its Grape 12 oz, and so on, which can then be associated with a UPC or SKU. The end result is that each different UPC or SKU 49 has assigned a corresponding card number (universal product-transaction identifier 41) that has a format that conforms to a financial services electronic payment network's specifications.”
Uzo (US Patent Application Publication 20080040274) discloses “In an electronic payment network, where each member of the network issues a payment instrument accepted by every other member, the IIN of the instrument is used to identify both the network and the issuer. Aliases do not contain information on the issuer which means that aliases must first be resolved to the actual IIN of the payment instrument in order to identify the issuer and route payment requests to it. Each member of a payment network needs to be able to resolve an alias to the issuer or to the IIN for a payment instrument issued by any member of the network. This may be achieved by having each member of the network write its alias records to a shared database or to both a shared database and its own local database. The shared database includes all aliases in the network and can be queried by each network member or by a gateway or by a POS device to obtain the IIN of a payment instrument. When the issuer maintains its alias data in a local database, the alias record in the shared database need not map the alias to the payment instrument IIN, but instead maps the alias to the issuer so that payment requests can be routed to it. The issuer can then use its local alias table to obtain the IIN and process payment. Other embodiments are possible. In any event, the objective is to enable any member of a network to use the alias for a payment instrument issued by a member of that network to route a payment request to that issuer. This is also desirable where an issuer distributes payment processing across many computers or delegates issuing and/or processing of payment instruments to one or more other entities. Each issuer can resolve the alias by querying a shared database that maps aliases to issuer for all members, or aliases to IINs for all payment instruments. In another embodiment, access to the shared database is delegated to a gateway, which each issuer queries to resolve an alias. The gateway itself may categorize or distribute the alias tables in a fashion which reduces processing load. In an illustrative embodiment described, the POS device for a merchant in an electronic payment network acts as a gateway and first resolves any alias to the issuer by querying the shared database. It then forwards the alias along with the payment instrument IIN, PIN and amount to the issuer. Each issuer maintains alias to IIN mappings for each alias in the alias tables of its local database and also writes into a shared alias database a mapping of the alias to the issuer's number for that network. The merchant POS device therefore always sends the payment request to the payment instrument issuer.”
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 S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm.
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, Bennett Sigmond can be reached at 303-297-4411. 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 S. CUNNINGHAM II
Primary Examiner
Art Unit 3694
/GREGORY S CUNNINGHAM II/Primary Examiner, Art Unit 3694
Prosecution Insights