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 the Application
Claims 1-5, 8-12, and 15-19 have been examined in this application.
The filling date of this application number recited above is 24-January-2023. No priority has been claimed in the Application Data Sheet, thus the examination will be undertaken in consideration of effective filing date as the priority date.
No information disclosure statement (IDS) has been filed to date.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 8, and 15 (and claims 2-5, 9-12, and 16-19 due to dependency), are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 8, and 15 recite the limitation "the vault database" in the limitation “determining, by the payment network backend, … based on a mapping stored on the vault database accessed by the payment network backend”. There is insufficient antecedent basis for this limitation in the claim.
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-5, 8-12, and 15-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The Claims are directed to an abstract idea, Methods of Organizing Human Activity. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional computer elements, which are recited at a high level of generality, provide conventional computer functions that do not add meaningful limits to practicing the abstract idea.
As per Claims 1, 8, and 15, the claim recites “a method comprising:
receiving, at a merchant … through a merchant [intermediary] and from a [customer], [a transaction] request including payment details including an account number and an instruction to store the payment details, wherein the account number is for a payment product;
sending, by the merchant … through a payment [intermediary] to a [payment entity], the account number;
receiving, from the [payment entity] through the payment [intermediary] and at the merchant …, a token, wherein the token is mapped to the account number;
synchronizing, by the [payment entity] and an issuer …, mappings of accounts to tokens;
determining, by the payment [intermediary], an account comprising the account number and a customer account data associated with the token based on a mapping stored on the vault … accessed by the payment [intermediary];
sending, by the merchant … and through the issuer [intermediary] to the issuer …, a communication including a request for a payment option, the token, a payment amount to be charged to the payment product, and a transaction identifier;
generating, by a payment option [worker] executed by the issuer …, the payment option using a [mathematical] model, wherein the payment option is generated based on a customer's amount of credit available with respect to the payment product, wherein the payment option is an installment plan;
storing, by the payment option [worker] executed by the issuer …, the transaction identifier with a reference to the payment option with the account number as a lookup key;
receiving, by the merchant … through the issuer [intermediary] and from the issuer …, the payment option; and
indicating, by the merchant … through the merchant [intermediary] and to the [customer], the payment option with respect to a transaction associated with the payment details, the payment option being provided as a parameter of [a message] in response to the [transaction] request.“
The limitation of the claims recited above, considering the claims without the additional elements (e.g. computer, processor, API, etc.), under its broadest reasonable interpretation (BRI), recite Certain Methods of Organizing Human Activities, specifically under fundamental economic principles or practices and/or commercial or legal interactions. The method recited above is a process of performing a transaction, which involves series of interactions between the necessary parties (e.g. merchant, bank, etc.) to communicate information (e.g. transaction information, payment options, account information, etc.), wherein the communication involves an intermediary used to receive and transmit messages. The process of performing a transaction is fundamental economic principles or practices, and the interactions involved to exchange information and data regarding the transaction is commercial or legal interactions, which are both under certain methods of organizing human activities. Therefore, the claims recite an abstract idea.
This judicial exception is not integrated into practical application. In particular, the claims recite an additional element of “backend”, “payment application”, “electronic device”, “application programming interface (API)”, “API gateway”, “engine”, “system”, and “non-transitory computer readable storage medium” to perform the method recited above by instructing the abstract idea to be performed “by” these generic computer components. These general computer components are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer system. These elements are generic, off-the-shelf components available to the public, and does not require any specialized hardware or equipment to perform the claimed method, and are merely applied to perform its basic functionalities, such as: send data, receive data, synchronize data, store data, and generate data, as disclosed by Specification:
[0075] “These may be a general-purpose computer, a computer server, a host machine, etc.” and
[0077] “As noted above, the processing machine used to implement the invention may be a general-purpose computer.”,
Mere instructions to implement the abstract idea on a generic computer system, or merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of integration into a practical application; see MPEP 2106.05(f). Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to send, receive, or store data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activities) 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); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). 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 to an abstract idea.
The claims also recite an additional element regarding “machine learning model”, as disclosed “generating, by a payment option engine executed by the issuer backend, the payment option using a machine learning model, wherein the payment option is generated based on a customer's amount of credit available with respect to the payment product, wherein the payment option is an installment plan”. This additional element is recited at a mere “apply it” level, wherein the machine learning model is provided as a mere black-box application used to provide an output (e.g. generate payment option), without any further technical details. Specification
[0052] “Payment option engine 144 may include machine learning models and other algorithms/rules that generate a customized payment option for the customer”
discloses that the machine learning model is merely applied and does not provide any technological improvement, change, control, modification, or alterations to the underlying technology or the machine learning model itself. As similarly discussed above, mere “apply it” is not indicative of integration into a practical application.
The claims also recite additional elements regarding the “API”, such as “API request”, “API gateway”, and “API call”. As similarly discussed above, these additional elements are generic computer components merely applied to implement the abstract idea by performing its basic functionalities (e.g. communicate via API), wherein mere “apply it” is not indicative of integration into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, the additional element of using a computer based system is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer system. The claims lack sufficient technical details to provide how these limitations may provide technological steps or technical details on how it is particularly implemented on a computer to improve its system or any of its underlying hardware or components (e.g. how it is performed on the computer, how it could improve the computer itself, how it could manipulate the computer to function in a specific way other than its generic functionality, and/or how it could improve any of the underlying technology), but merely applies the generic computer system to perform its generic functionalities. Merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of an inventive concept (aka “significantly more”). In view of the Specification cited above, the judicial exception is not applied with or used by a particular machine. As held in Parker v. Flook, 437 U.S. 584, 590, 198 USPQ 193, 199 (1978) and Bancorp Services v. Sun Life, 687 F.3d 1266, 1276, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012), “the routine use of a computer to perform calculations cannot turn an otherwise ineligible mathematical formula or law of nature into patentable subject matter.” The claims are not patent eligible.
Regarding dependent claims, they are still directed to an abstract idea without significantly more.
Claims 2, 9, and 16 recite “comprising: displaying the payment option via a frontend computer application executing on an electronic device.” The claims provide additional element of “frontend computer application executing on a electronic device”. As similarly discussed above with their parent claims, the additional element is a generic computer system merely applied to implement the abstract idea of displaying payment options, which is not indicative of integration into a practical application.
Claims 3, 10, and 17 recite “wherein the payment option is selectable by a user of the electronic device.” The claims provide additional element of “electronic device”. As similarly discussed above with their parent claims, the additional element is a generic computer system merely applied to implement the abstract idea of selecting payment option, which is not indicative of integration into a practical application.
Claims 4, 11, and 18 recite “wherein the payment option is displayed in association with the transaction.” The claims provide further steps of displaying information. As similarly discussed above with their parent claims, the additional element is a generic computer system merely applied to implement the abstract idea of displaying information, which is not indicative of integration into a practical application.
Claims 5, 12, and 19 recite “wherein the indication to use the payment option with respect to the transaction is received from the electronic device.” The claims provide further steps of receiving information. As similarly discussed above with their parent claims, the additional element is a generic computer system merely applied to implement the abstract idea of receiving information, which is not indicative of integration into a practical application.
These additional steps of each claims fail to remedy the deficiencies of their parent claim above because they are merely further limiting the rules used to conduct the previously recited abstract idea, and are therefore rejected for at least the same rationale as applied to their parent claim above.
Claims 2-5, 9-12, and 16-19, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitations fail to establish that the claims are sufficient to integrate into a practical application and do not amount to significantly more than the judicial exception. Similarly to the independent claims, each claim recites using a generic computer component to perform the abstract idea as mentioned above. Mere instructions to implement an abstract idea on a generic computer system, or merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of an inventive concept (aka “significantly more”). Therefore, prong 2 and step 2B analysis are similar to above and these claims are not eligible.
Therefore, Claims 1-5, 8-12, and 15-19 are not drawn to eligible subject matter as they are directed to an abstract idea without significantly more.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis 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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 8-12, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Ortiz (US 11599879 B2), in view of SPENCE et al. (US 20230123311 A1) in further view of Lopreiato et al. (US 20150339663 A1), and in view of Atieque et al. (US 11386488 B2).
As per Claims 1, 8, and 15, Ortiz teaches a method (See Figure 1 and Figure 2 for system) comprising:
receiving, at a merchant backend through a merchant API gateway and from a payment application executed by an electronic device, an application programming interface ("API") request including payment details including an account number and an instruction to store the payment details, wherein the account number is for a payment product (See Figure 3 – step 2404, as disclosed [Col 16 Lines 16-27] “Having received such a preferred funding source instruction request (or “request to add card”) data set, at 2404 the merchant application 114 or virtual wallet application 112 can, in accordance with rules represented by logical structures associated with the application, generate one or more preferred funding source identification request data sets (or “eligible accounts list request data sets”) adapted to cause polling of one or more FI systems 120 associated with accounts or other funding sources controlled by or otherwise available to the user 190 in satisfying payment transaction requests for data identifying all or some such available funding sources” and with respect to the API request, see [Col 14 Lines 22-28] “For example, invocation of the command item 634 can cause one or more processors 602 of the device 100 to generate, in accordance with instructions incorporated within logical structures associated with the My Store merchant API 114, a preferred or select payment or funding source instruction request data set (also referred to as a “request to add card” data set)”);
sending, by the merchant backend through a payment network API gateway to a payment network backend, the account number ([Col 16 Lines 28-40] “For example, on receipt of the “request to add card” command data set, a virtual wallet application 112 associated with a specific bank can parse the data set and, using flags or other identifiers as described above, execute known table look-up and value comparison techniques to determine routing information for the one or more FI systems 120 to which the request is to be routed, subject to any merchant preferences for funding FIs expressed by means of explicit or implicit special processing request identifiers” or see also [Col 14 Lines 44-46] “In such a case a “request to add card” command data set generated by a merchant API 114 and routed to a multi-FI wallet application”);
receiving, from the payment network backend through the payment network API gateway and at the merchant backend, a token (See Figure 3 – step 2418, as disclosed [Col 22 Lines 36-47] “Thus, for example, at 2418 a merchant application 114 can generate a select merchant token confirmation data set, comprising data representing one or more secure purchaser identifiers associated with the prospective purchaser 190 and/or device 110 and the same or another select merchant payment token, and route the select merchant token confirmation data set to a merchant transaction management system 130, in order enable the merchant backend system 130, 136 associated with the merchant application 114 to store the select merchant token and optionally the secure purchaser identifiers in secure persistent storage” wherein the token may also be an API token, as disclosed [Col 22 Lines 13-19] “In other cases, generation of the Merchant API token can be created in advance simply in order to speed transaction processing at the time a transaction is desired, while uniquely identifying all applicable payment rules, including special discounts, loyalty rewards, and accounts to be used as transaction funding sources”);
…
sending, by the merchant backend and through an issuer API gateway to the issuer backend, a communication including a request for a payment option, the token, a payment amount to be charged to the payment product, and a transaction identifier (See Figure 3 – step 2420, as disclosed [Col 22 Lines 61-67] “In addition, at 2420, the merchant back-end system can route the token to banking/token management services associated with FI system(s) 120, 160 a request for confirmation, with identifiers representing any special transaction processing requests, and/or for generation of a separate unpredictable identifier to be associated by the merchant system 130 with the user 190 in processing of any transactions initiated by the user, etc.”);
…
storing, by the payment option engine executed by the issuer backend, the transaction identifier with a reference to the payment option with the account number as a lookup key ([Col 20 Lines 39-55] “For example, a secure token generation service 120, 160 associated with the FI system 120 responsible for managing accounts accessible by the requesting user can generate and store in secure persistent memory, such as a suitably secure database of select merchant payment token data sets, an unpredictable select merchant payment token (or “selected merchant payment token”) to serve as a unique identifier of (i) the merchant(s) or merchant account(s) to which payments associated with use of the token are to be made; and (ii) the accounts to be used as funding sources for transactions between the merchants) and the requesting user. The token can also be linked, e.g., through a table-look up process, with any special business functions or requests associated with the token request, including for example any special loyalty account rules, discounts, etc., specified or requested by the corresponding merchants, users, or FI(s) 120”);
receiving, by the merchant backend through the issuer API gateway and from the issuer backend, the payment option (See Figure 3 – step 2422, as disclosed [Col 24 Lines 20-23] “At 2422, the responsible FI 120 can return a suitably-formatted select merchant payment token, or confirmation of an earlier-generated token, to the requesting merchant backend system 130 for use as described herein”); and
indicating, by the merchant backend through the merchant API gateway and to the payment application executed by the electronic device, the payment option with respect to a transaction associated with the payment details, the payment option being provided as a parameter of an API call in response to the API request (See Figure 8 – button 660 “MY WALLET”, as disclosed [Col 28 Lines 62-67] “At 2504, for example, a user of a merchant application 114 associated with a merchant “My Store” as described above who has used one or more GUIs generated by the merchant application 114 to identify one or more items for purchase can be presented with a GUI 650 such as that shown in FIG. 8, comprising … one or more command items 658, 660 associated with payment options”).
Although the teachings from the referenced prior art may not explicitly disclose the steps as being performed by the “merchant backend”, it would be obvious to one of ordinary skill in the art to recognize the system to apply the backend system to perform the necessary steps of receiving, transmitting, or storing data, which would have yielded predictable results because the level of ordinary skill in the art demonstrated by the reference applied shows the ability to incorporate such backend systems, with the motivation of offering to provide [Col 1 Lines 47-52] “generation and secure and efficient execution of electronic signal exchanges, and more particularly to improved systems, methods, and programming structures for the secure negotiation, authorization, execution, and confirmation of multi-party and multi-device transactional data processes” with improved [Col 1 Lines 56-67] “speed, security, reliability, and convenience” resulting in an improved system that would allow more efficient communications.
Additionally, although the referenced prior art may not explicitly disclose all and every step as being associated with an “API”, it would be obvious to one of ordinary skill in the art to recognize the system to apply the “API” technology to perform the necessary steps of communicating and exchanging data (e.g. API request or API call), which would have yielded predictable results because the level of ordinary skill in the art demonstrated by the reference applied shows the ability to incorporate an “API”, with the motivation of offering [Col 14 Lines 51-57 to Col 15 Line 1] “Among the significant advantages offered by such aspects of the invention is the enablement of merchants and/or merchant associations associated with API(s) 114 to have increased input to and control of transactions conducted with specific purchasers, or classes of purchasers, and/or transactions involving accounts controlled or otherwise administered by specific banks or FIs associated with payment authorization management system(s) 120”, resulting in an improved system that would allow more efficient communications.
Ortiz may not explicitly disclose, but SPENCE teaches:
[maintaining], by the payment network backend and an issuer backend, mappings of accounts to tokens ([0040] “The computing system 200 may also be an account database 206. The account database 206 may be configured to store one or more account profiles 208 using a suitable data storage format and schema … Each account profile 208 may be a structured data set configured to store data related to a transaction account, which may include, for example, token identifier, transaction account numbers, controlled payment numbers, account details, transaction controls, mapping data, authentication information, contact information for computing devices 102, etc.”);
determining, by the payment network backend, an account comprising the account number and a customer account data associated with the token based on a mapping stored on the vault database accessed by the payment network backend ([0050] “In step 316, the processing server 114 may identify (e.g., in an account profile 208 via a query to an account database 206 by a querying module 214) a transaction account number, also referred to herein as a “primary account number” (PAN), that is associated with the transaction account that corresponding to the received token identifier”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize mapping of the account profile associated with the token with the transaction account number stored on a database as in SPENCE in the system executing the method of Ortiz, with the motivation of offering to [0001-0005] increase security protecting transaction account numbers while maintaining a high level of convenience and ease of use for consumers as taught by SPENCE over that of Ortiz.
Although SPENCE teaches of an account database comprising account profiles and transaction account numbers used to store and map to the tokens, the prior art reference does not seem to explicitly disclose of the two systems (i.e. payment network backend and issuer backend) synchronizing with the vault database that store token mappings with the account numbers. However, Lopreiato discloses:
synchronizing, by the payment network backend and an issuer backend, mappings of accounts to tokens ([0027] “In some cases, either in response to an event report 202 or on its own initiative, the issuer 112 may send a database update request (reference numeral 204) to the token service provider 104. As indicated at 206, either on its own initiative or following the database update request 204, the token service provider 104 may engage in a token entry update operation 206 to update one of the token entries maintained in the token vault 110. If the token entry update operation 206 followed a database update request 204 from the issuer 112, then the token service provider 104 may follow up the token entry update operation 206 with an update response (reference numeral 208) to the issuer 112 to confirm that the token entry update operation 206 has occurred”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize synchronizing the database for the issuer and the service provider with the token update as in Lopreiato in the system executing the method of SPENCE, with the motivation of offering to [0001-0009] provide convenience to the relevant parties while arranging establishment of a proper communication channel as taught by Lopreiato over that of SPENCE.
Ortiz may not explicitly disclose, but Atieque teaches:
generating, by a payment option engine executed by the issuer backend, the payment option using a machine learning model, wherein the payment option is generated based on a customer's amount of credit available with respect to the payment product, wherein the payment option is an installment plan (Claim 1 "responsive to the request to initiate the checkout process for the online shopping cart, performing the checkout process for the online shopping cart, wherein an installment plan is offered for the checkout of the online shopping cart based on the first and second machine learning models, the performing including: determining that the installment plan option should be offered for checkout of the online shopping cart" and see also [Col 20 Lines 35-42] "The customer-specific variable may be based on, for example one or more of: ... locally maintained, or 3rd party credit information—this can be used to minimize identity fraud; note this can factor in a consideration of the amount of the purchase, and the credit available to the specific customer. In some embodiments, the credit available for IP purchases for a given purchaser is adjusted over time as a function of historical activity");
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize generating payment option (e.g. installment plans) using machine learning models as in Atieque in the system executing the method of Ortiz, wherein the system in Ortiz already teaches of providing payment options, with the motivation of offering to [Col 1 Lines 13-36] “reduce the likelihood of chargebacks and make installment payments more convenient for merchants, customers, and underwriters” as taught by Atieque over that of Ortiz.
As per claims 2, 9, and 16, Ortiz teaches the method of claim 1, the system of claim 8, and the non-transitory computer readable storage medium of claim 15, comprising:
displaying the payment option via the frontend computer application executing on an electronic device (See Figure 8 wherein an electronic device is displaying the application with payment options).
As per claims 3, 10, and 17, Ortiz teaches the method of claim 2, the system of claim 9, and the non-transitory computer readable storage medium of claim 16, wherein the payment option is selectable by a user of the electronic device (See Figure 8 wherein an electronic device is displaying the application with payment options, which is selectable by the user).
As per claims 4, 11, and 18, Ortiz teaches the method of claim 3, the system of claim 10, and the non-transitory computer readable storage medium of claim 17, wherein the payment option is displayed in association with the transaction (See Figure 8 wherein an electronic device is displaying the application with payment options along with the transaction details).
As per claims 5, 12, and 19, Ortiz teaches the method of claim 4, the system of claim 11, and the non-transitory computer readable storage medium of claim 18, wherein the indication to use the payment option with respect to the transaction is received from the electronic device (See Figure 8, as disclosed [Col 29 Lines 5-8] “Selection of command item 660 “My Wallet” can cause processor(s) 602 of the user's device to invoke a virtual wallet application 112, and process payment in accordance with logical structures associated with the application 112”).
Response to Arguments
Applicant's arguments, see pages 9 to 12, filed 05 August 2025, with respect to 35 U.S.C. 101 rejection have been fully considered but they are not persuasive.
Applicant contends, see pages 9 to 10, that the claims do not recite a judicial exception. Examiner respectfully disagrees. As discussed above under 35 U.S.C. 101 rejection, considering the claims without the additional elements (e.g. computer, processor, API, etc.), under its broadest reasonable interpretation (BRI), recite a process of performing a transaction, which involves series of interactions between the necessary parties (e.g. merchant, bank, etc.) to communicate information (e.g. transaction information, payment options, account information, etc.), wherein the communication involves an intermediary used to receive and transmit messages. The process of performing a transaction is fundamental economic principles or practices, and the interactions involved to exchange information and data regarding the transaction is commercial or legal interactions, which are both under certain methods of organizing human activities. Therefore, the claims recite an abstract idea.
Applicant contends, see pages 10 to 12, that the claims are not directed to an abstract idea under Step 2A Prong Two. Examiner respectfully disagrees. As discussed above under 35 U.S.C. 101 rejection, the additional elements are generic computer system merely applied to implement the abstract idea, and the additional elements “machine learning model” and “API” are also recited at a mere “apply it” level. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to send, receive, or store data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activities) 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); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). The claims, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, the additional element of using a computer based system is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer system. The claims lack sufficient technical details to provide how these limitations may provide technological steps or technical details on how it is particularly implemented on a computer to improve its system or any of its underlying hardware or components (e.g. how it is performed on the computer, how it could improve the computer itself, how it could manipulate the computer to function in a specific way other than its generic functionality, and/or how it could improve any of the underlying technology), but merely applies the generic computer system to perform its generic functionalities. Therefore, the 35 U.S.C. 101 rejection is maintained.
Applicant’s arguments, see pages 12 to 13, with respect to 35 U.S.C. 103 rejection have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ghani et al. (US 20220076240 A1) discloses [0061] “In some implementations, token service 317 may be in communication with data store 318 where the generated tokens are stored. Specifically, data store 318 may maintain a mapping between a token and the real account identifier (e.g., PAN) represented by the token and associated with a specific entity”;
Adcock et al. (US 20220156355 A1) discloses [0040] “For example, the server device may create a transaction token (e.g., an identifier) that maps to account information associated with the account. The transaction token may map to the one or more access parameters such that when a transaction is initiated using the transaction token, the server device (and/or a transaction backend) may identify the account information and the one or more access parameters”.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HENRY H JUNG whose telephone number is (571)270-5018. The examiner can normally be reached Mon - Fri 9:30 - 5:30.
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, Christine M Tran (Behncke) can be reached at (571) 272-8103. 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.
/HENRY H JUNG/ Examiner, Art Unit 3695
/CHRISTINE M Tran/ Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights