DETAILED ACTION
This is an office action on the merits in response to the communication filed on 6/18/2025.
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 .
Claims’ Status
Claim 1 is canceled. Claims 2-21 are pending and are considered in this office action.
Priority
CONTINUATION
This application is a continuation application of U.S. application NO. 17/339,096 filed on June 4, 2021, which is also a continuation of U.S. application NO. 15/295,859 filed on October 17, 2016. See MPEP §201.07. In accordance with MPEP §609.02 A. 2 and MPEP §2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also in accordance with MPEP §2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicants desire the information to be printed on a patent issuing from this application. See MPEP §609.02 A. 2. Finally, Applicants are reminded that the prosecution history of the Parent Application is relevant in this application. See e.g., Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1350, 69 USPQ2d 1815, 1823 (Fed. Cir. 2004) (holding that statements made in prosecution of one patent are relevant to the scope of all sibling patents).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 20-21 are non-provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-16 of Patent No. US12314944B2 (Instant token issuance). Although the claims at issue are not identical, they are patentably distinct from each other because the scope of claim 20 of the instant application is broader than and fully encompasses the species claimed in claim 1 of Patent US12314944B2, in which they have common limitations and the same inventive entity. The narrower scope of claim 1 of the Patent No. US12314944B2 anticipates the broader scope of claim 20 of the instant application because a species always anticipates a genus. Therefore, it would have been obvious to one of ordinary skill in the art to remove or add the additional limitations in the patents/co-pending applications above to result in the instant claims.
Claim 20 of the Instant application
Claim 1 of Patent No. US12314944B2
enrolling, by a server computer, a plurality of resource providing entities in a tokenization program;
receiving, by the server computer from an authorization computer, a real account identifier associated with a user account newly generated by the authorization computer for a user;
sending, by the server computer to the authorization computer, a list of participating resource providing entities based on the plurality of resource providing entities enrolled in the tokenization program, wherein the authorization computer provides the list of participating resource providing entities to a user device of the user;
receiving, by a server computer, a plurality of selected resource providing entities by a user of a user account;
receiving, by the server computer, a plurality of selected resource providing entities selected among the participating resource providing entities by the user of the user account;
receiving, by the server computer, a request to issue a payment token for each of the plurality of selected resource providing entities;
receiving, by the server computer, a request to issue a payment token for each of the plurality of selected resource providing entities;
performing, by the server computer, a token provisioning process for each of the plurality of selected resource providing entities, the token provisioning process comprising:
generating, by the server computer, a payment token associated with the user account, wherein the payment token substitutes a real account identifier associated with the user account generated by an authorization computer for the user, and the payment token is specific to the selected resource providing entity;
performing, by the server computer, a token provisioning process for each of the plurality of selected resource providing entities, the token provisioning process comprising:
generating, by the server computer, a payment token associated with the user account, wherein the payment token substitutes the real account identifier, and the payment token is specific to the selected resource providing entity;
determining, by the server computer, that an authentication process requested by the authorization computer is supported by each of the plurality of selected resource providing entities;
determining, by the server computer, that an authentication process requested by the authorization computer is supported by each of the plurality of selected resource providing entities;
facilitating, by the server computer, the authentication process between the user and each of the plurality of selected resource providing entities, facilitating comprising:
when the server computer determines that a user of the user account does not have an account with a first selected resource providing entity among the plurality of selected resource providing entities, generating, by the server computer, the account with the first selected resource providing entity; and
facilitating, by the server computer, the authentication process between the user and each of the plurality of selected resource providing entities, facilitating comprising:
when the server computer determines that a user of the user account does not have an account with a first selected resource providing entity among the plurality of selected resource providing entities, generating, by the server computer, the account with the first selected resource providing entity; and
loading user authentication information available to the server computer to an interface to transmit the user authentication information to the plurality of selected resource providing entities; and
loading user authentication information available to the server computer to an interface to transmit the user authentication information to the plurality of selected resource providing entities; and
sending, by the server computer, the payment token and the user authentication information directly to a selected resource providing entity computer associated with each one of the plurality of selected resource providing entities;
sending, by the server computer, the payment token and the user authentication information directly to a selected resource providing entity computer associated with each one of the plurality of selected resource providing entities;
receiving, by the server computer from the selected resource providing entity, an authorization request message associated with a transaction, wherein the authorization request message includes the payment token shared with the selected resource providing entity; and
receiving, by the server computer from the selected resource providing entity, an authorization request message associated with a transaction, wherein the authorization request message includes the payment token shared with the selected resource providing entity; and
transmitting, by the server computer, the authorization request message to the authorization computer, wherein the authorization computer authorizes or declines the transaction.
transmitting, by the server computer, the authorization request message to the authorization computer, wherein the authorization computer authorizes or declines the transaction.
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 2-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03
Per Step 1, Claims 2-10 and 20-21 are drawn to a method; claim 11-19 are drawn to an apparatus, which are all within the four statutory categories (i.e., a process).
Independent claim 2 recites: (claims 11 being similar in scope):
Claim 2:
receiving a payment token and account identifying information associated with the payment token directly from a server computer, wherein the payment token is an identifier for an account of a user that substitutes a real account identifier associated with the account;
storing the payment token in association with an account-on-file for the user at a storage accessible by the resource providing entity computer;
receiving, from a user device of the user, a request to conduct a transaction;
identifying the payment token associated with the user; and
processing the transaction using the payment token, wherein processing the transaction includes:
generating a transaction authorization request message including the payment token;
transmitting the transaction authorization request message to the server computer; and
receiving a transaction authorization response message from the server computer indicating whether the transaction is authorized
Claim 20:
receiving, by a server computer, a plurality of selected resource providing entities by a user of a user account;
receiving, by the server computer, a request to issue a payment token for each of the plurality of selected resource providing entities;
performing, by the server computer, a token provisioning process for each of the plurality of selected resource providing entities, the token provisioning process comprising:
generating, by the server computer, a payment token associated with the user account, wherein the payment token substitutes a real account identifier associated with the user account generated by an authorization computer for the user, and the payment token is specific to the selected resource providing entity;
determining, by the server computer, that an authentication process requested by the authorization computer is supported by each of the plurality of selected resource providing entities;
facilitating, by the server computer, the authentication process between the user and each of the plurality of selected resource providing entities, facilitating comprising:
when the server computer determines that a user of the user account does not have an account with a first selected resource providing entity among the plurality of selected resource providing entities, generating, by the server computer, the account with the first selected resource providing entity; and
loading user authentication information available to the server computer to an interface to transmit the user authentication information to the plurality of selected resource providing entities; and
sending, by the server computer, the payment token and the user authentication information directly to a selected resource providing entity computer associated with each one of the plurality of selected resource providing entities;
receiving, by the server computer from the selected resource providing entity, an authorization request message associated with a transaction, wherein the authorization request message includes the payment token shared with the selected resource providing entity; and
transmitting, by the server computer, the authorization request message to the authorization computer, wherein the authorization computer authorizes or declines the transaction.
Step 2A Prong 1: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04
The limitations, as drafted, constitute a process that, under its broadest reasonable interpretation, covers: 1) commercial interaction in the form of business relation, but for the recitation of generic computer components. The abstract idea, recited above, includes: receiving a payment token and account identifying information associated with the payment token directly from a server computer; storing the payment token in association with an account-on-file for the user at a storage accessible by the resource providing entity computer; receiving, from a user device of the user, a request to conduct a transaction; identifying the payment token associated with the user; and processing the transaction using the payment token, wherein processing the transaction includes: generating a transaction authorization request message including the payment token; transmitting the transaction authorization request message to the server computer; and receiving a transaction authorization response message from the server computer indicating whether the transaction is authorized. If a claim limitation, under its broadest reasonable interpretation, covers performance of limitations commercial interactions, but for the recitation of generic computer components, it falls within the Certain Methods of Organizing Human Activity – 1) commercial interaction in the form of business relation, grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Similarly for claim 20, the abstract idea includes: receiving a plurality of selected resource providing entities by a user of a user account; receiving a request to issue a payment token for each of the plurality of selected resource providing entities; generating a payment token associated with the user account, wherein the payment token substitutes a real account identifier associated with the user account generated by an authorization computer for the user, and the payment token is specific to the selected resource providing entity; facilitating the authentication process between the user and each of the plurality of selected resource providing entities, facilitating comprising:
when the server computer determines that a user of the user account does not have an account with a first selected resource providing entity among the plurality of selected resource providing entities, generating, by the server computer, the account with the first selected resource providing entity; and
loading user authentication information available to the server computer to an interface to transmit the user authentication information to the plurality of selected resource providing entities; and sending the payment token and the user authentication information directly to a selected resource providing entity computer associated with each one of the plurality of selected resource providing entities; receiving an authorization request message associated with a transaction and transmitting the authorization request message to the authorization computer.
Step 2A Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
The recited computing elements (claim 2 and 20: user device; server computer; resource providing entity computer; claim 11: a processor; a computer readable medium) are recited at a high-level of generality, i.e. as generic computing element performing generic computer functions such that it amounts to no more than mere instructions to apply the exception using generic computer components (see MPEP 2106.05(f)). Simply adding a general purpose computer or computer components after the fact to an abstract idea does not integrate a judicial exception into a practical application or provide significantly more, since it amounts to no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer, as set forth in MPEP 2106.05(f).
Furthermore with respect to claim 20 only, the additional elements are “performing a token provisioning process for each of the plurality of selected resource providing entities, the token provisioning process comprising: determining that an authentication process requested by the authorization computer is supported by each of the plurality of selected resource providing entities” , which amount to linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Accordingly, these additional claim elements, alone and in combination do not integrate the abstract idea into a practical application, because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05(a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05(b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05(e) and the Vanda memo). Therefore, per Step 2A, Prong Two, the claim is directed to an abstract idea not integrated into a practical application.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B of the eligibility analysis concludes that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Examiner carries over the analysis from Step 2A related to the generic computing elements being no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer (MPEP 2106.05(f)). The additional claim elements are simply linking the use of the judicial exception to a particular technological environment or field of use” are mere instructions to implement an abstract idea on a computer, are carried over for further analysis in Step 2B.
When the independent claims are considered as a whole, as a combination, the claim elements noted above do not amount to any more than they amount to individually. The operations appear to merely apply the abstract concept to a technical environment in a very general sense, i.e. a processor; a computer program product; various modules; etc. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified as an abstract idea. Therefore, it is concluded that the elements of the independent claims are directed to one or more abstract ideas and do not amount to significantly more. (MPEP 2106.05)
Further, Step 2B of the analysis takes into consideration all dependent claims as well, both individually and as a whole, as a combination:
Claims 3-10 are further directed to additional abstract ideas because the steps performed are simply narrowing the scope of the abstract idea of claim 2 since their individual and combined significance is still not significantly more than the abstract concept at the core of the claimed invention. For example, claim 3 further describes performing authentication; claim 4 describes requesting the payment token from the server computer; claim 5 describes transmitting a request to participate in a tokenization program; claim 6 describes receiving a selection of the payment token; claim 7 describes prefilling the checkout page with payment token information; claim 8 on transaction being imitated at a transaction terminal; claim 9 on generating a new account-on-file; claim 10 on receiving authentication information from the server; etc, which all of the limitation are narrowing the steps performed in claim 2. Similarly to claim 21, it further narrows claim 20 by reciting prompting a user for the user authentication information for the selected resource providing entity.
Moreover, the claims in the instant application do not constitute significantly more also because the claims or claim elements only serve to implement the abstract idea using computer components to perform computing functions (Enfish, see MPEP 2106.05(a)). The other dependent claims, claims 12-19 are similar in scope to claims 3-10 are also rejected for the same reasons provided above.
The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the associated computing devices are facilitating the abstract concept is not enough to confer statutory subject matter eligibility. In sum, the additional elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not heavier than the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more either. (see MPEP 2106.05)
In sum, claims 2-21 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 2-?? are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Powell et al. (US20150127547A1).
With respect to claim 2 and 11
Powell discloses:
receiving a payment token and account identifying information associated with the payment token directly from a server computer ([0113], Upon receiving the token request message from the token requestor 114, the payment network 210 may generate a token for the PAN provided in the token request message….. the payment network 210 may also generate a token assurance level associated with the generated token. The token assurance level may represent a level of trust in an association between the generated payment token and the PAN represented by the payment token. The payment network 210 may store the association between the PAN and the generated token along with the token assurance level and the data used to generate the token assurance level in the vault 218. The payment network 210 may provide the token to the token requestor 114 in a token request reply message.), wherein the payment token is an identifier for an account of a user that substitutes a real account identifier associated with the account ([0033], A “token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN).);
storing the payment token in association with an account-on-file for the user at a storage accessible by the resource providing entity computer ([0070], In some embodiments, the token may be passed through a near field communication (NFC) (e.g. point-of-sale use case). Yet in other embodiments, the merchant 106 may already know the PAN of the account holder 102 (e.g. card-on-file use case). For example, the card-on-file merchant may store the account information of the account holder 102 on file (e.g., at a merchant database) for future payment purposes, such as various types of periodic payments (e.g., monthly utilities payments);
receiving, from a user device of the user, a request to conduct a transaction ([0103], As illustrated in FIG. 2, the account holder 102 may wish to conduct a payment transaction with the merchant 106. The account holder 102 may be able to initiate a transaction using a payment account identifier (e.g. a primary account number (PAN)). In addition, the account holder 102 may be capable to utilize a consumer device to initiate a transaction using any suitable transaction channel such as through a scan of a mobile device (e.g., using a QR™ code or bar code), a tap of a mobile device to a merchant access device (e.g., near-field communication (NFC) transaction or other contactless/proximity transaction), a click on a computer or other mobile device in order to initiate an e-commerce transaction (e.g., online transaction), or through any other channel in which a transaction may be initiated and a token may be passed to a merchant computer);
identifying the payment token associated with the user ([0104], If the account holder 102 is in possession of a payment device which includes a token representing the account number, the account holder 102 may present the token to the merchant 106 via scanning or tapping the payment device to a payment terminal of the merchant 106.); and
processing the transaction using the payment token, wherein processing the transaction includes: generating a transaction authorization request message including the payment token; transmitting the transaction authorization request message to the server computer ([0114], The token requestor 114 may present the token to the merchant 106, who may generate a payment authorization request message including the token. The merchant 106 may send the payment authorization request message to the acquirer 108, who may then pass the payment authorization request message to the payment network 210.);
receiving a transaction authorization response message from the server computer indicating whether the transaction is authorized ([0116], The payment network 210 may send the payment modified authorization response message to the merchant 106 via the acquirer 108. Based on the authorization response message, the merchant 106 may finalize the transaction with the account holder 102.)
With respect to claim 3 and 12
Powell teaches the limitation of claim 2 and 11 respectively. Powell further teaches: prior to receiving the payment token from the server computer: receiving authentication information from the user device; performing an authentication method using the authentication information to authenticate the user; providing results of the authentication method to the server computer ([0077-0078], According to various embodiments, when the token service provider 116 issues a token for a PAN associated with an account, the account holder 102 may not know that the token has been issued to represent the account. In some embodiments, the account holder 102 may be asked to participate in the identification and verification (ID&V) process during token generation. For example, the account holder 102 may be asked to provide an identification information to ensure that the token is being generated for an account rightfully owned by the account holder 102….. Based on the type of the ID&V performed, the token service provider 116 may also generate a token assurance level associated with the generated token during the issuance of the token. The token assurance level may represent a level of trust in an association between the payment token and the PAN represented by the payment token. For example, a high token assurance level represents a trusted association of the token to the PAN from an authorized account holder, that may support secure and reliable payment transactions initiated with payment. The generated token assurance level may be different from the requested token assurance level that may be optionally provided to the token service provider 116 by the requestor 114 in the token request message.)
With respect to claim 8 and 17
Powell teaches the limitation of claim 2 and 11 respectively. Powell further teaches: wherein the transaction is initiated at a transaction terminal of the resource providing entity ([0120], Referring now to FIG. 3, the mobile NFC at point-of-sale use case 300 refers to using a NFC-enabled mobile device 302 to initiate contactless payment at a merchant terminal 302.)
With respect to claim 9 and 18
Powell teaches the limitation of claim 2 and 11 respectively. Powell further teaches: determining the user already has an existing account-on-file; or generating a new account-on-file for the user prior to storing the payment token ([0070], In some embodiments, the token may be passed through a near field communication (NFC) (e.g. point-of-sale use case). Yet in other embodiments, the merchant 106 may already know the PAN of the account holder 102 (e.g. card-on-file use case). For example, the card-on-file merchant may store the account information of the account holder 102 on file (e.g., at a merchant database) for future payment purposes, such as various types of periodic payments (e.g., monthly utilities payments). In some implementations, an account holder 102 may register with one or more merchants 106 for card-on-file services.)
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 of this title, 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 4-5 and 13-14 are rejected under 35 U.S.C 103 as being obvious over Powell et al. (US20150127547A1) in view of Dill et al. (US20150032626A1).
With respect to claim 4 and 13
Powell teaches the limitation of claim 2 and 11 respectively. Powell doesn’t explicitly disclose, but Dill teaches: prior to receiving the payment token from the server computer:
requesting the payment token from the server computer ([0149], In one embodiment, the merchant token interface 210 may allow the e-commerce merchants to initiate token generation requests for cards-on-file during checkout processes using those cards on file. For example, the token generation module 312 may receive a token requestor identifier, a card-on-file PAN, a CVV2, an expiration date, and optionally a consumer identifier for the e-commerce web application.)
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 teaching of Dill with the teaching of Powell as they relate to management of payment token. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified a system of generating a payment token in Powell to include a method of requesting the payment token from the server computer as taught by Dill for the predicated result of improved and secured method of conducting a transaction using a payment token.
With respect to claim 5 and 14
Powell teaches the limitation of claim 2 and 11 respectively. Powell doesn’t explicitly disclose, but Dill teaches: prior to receiving the payment token from the server computer:
transmitting, to the server computer, a request to participate in a tokenization program offered by an entity associated with the server computer ([0099], In one embodiment, each token requestor 204 may have to undergo an onboarding or registration process to ensure that the token requestor meets integration and security standards in order to use the tokenization services provided by the network token system 202. For example, the network token system 202 may provide services such as card registration, token generation, token issuance, token authentication and activation, token exchange, and token life-cycle.)
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 teaching of Dill with the teaching of Powell as they relate to management of payment token. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified a system of generating a payment token in Powell to include a method of including a tokenization program as taught by Dill for the predicated result of improved and secured method of conducting a transaction using a payment token.
Claims 6 and 15 are rejected under 35 U.S.C 103 as being obvious over Powell et al. (US20150127547A1) in view of Chatterjee et al. (US8577803B2).
With respect to claim 6 and 15
Powell teaches the limitation of claim 2 and 11 respectively. Powell doesn’t explicitly disclose, but Chatterjee teaches: retrieving a list of (see claim 1, identify, via the computing processor of the payment network server, a plurality of card selection options to provide securely to the user mobile device of the user via the network communication device,); providing, to the user, the list of (see claim 1, provide via the network communication device, upon determining that the user is authorized to access the virtual wallet, a secure user virtual wallet card selection request including a list of user payment cards for selection to the user mobile device…); receiving a selection of the (see claim 1, obtain, via the network communication device at a payment network server, user selection of a virtual wallet card account from the plurality of securely provided card selection options, from the user mobile device via the network communication device.) and processing the transaction using the (payment card) (see claim 1, provide, via the network communication device, an encrypted purchase transaction request message for transaction processing, using the user selection of the virtual wallet card account.)
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 teaching of Dill with the teaching of Chatterjee as they relate to management of payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified a system of generating a payment token in Powell to include a method of receiving a selection of the payment card options as taught by Chatterjee for the predicated result of improved and secured method of conducting a transaction using a payment token.
Powell teaches: payment token ([0046], A payment token may include a high value token that can be used in place of a real account identifier (e.g., PAN) to generate original and/or subsequent transactions for a consumer account and/or card.)
Claims 7, 10, 16, and 19 are rejected under 35 U.S.C 103 as being obvious over Powell et al. (US20150127547A1) in view of Anderson et al. (US20150052061A1).
With respect to claim 7 and 16
Powell teaches the limitation of claim 2 and 11 respectively. Powell doesn’t explicitly disclose, but Anderson teaches: wherein the transaction is an electronic transaction, the method further comprising: providing a checkout page associated with the electronic transaction, wherein payment information associated with the payment token is prefilled by the resource providing entity computer on the checkout page ([0034], The commerce application 104 can auto-fill the payment information into checkout payment fields. As mentioned above, auto-filling the payment fields using payment information from the e-commerce payment facilitator 106, can increase the ease of the checkout process for the user. In at least one embodiment, the e-commerce payment facilitator 106 does not send the complete payment card number to the commerce application 104. Instead, the e-commerce payment facilitator 106 can send a card number label (i.e., “X's” for all of the digits of the payment card except the last for digits) and the payment token.)
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 teaching of Anderson with the teaching of Powell as they relate to management of payment token. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified a system of generating a payment token in Powell to include a method of prefilling the checkout page with payment information as taught by Anderson for the predicated result of improved and secured method of conducting a transaction using a payment token.
With respect to claim 10 and 19
Powell teaches the limitation of claim 2 and 11 respectively. Powell doesn’t explicitly disclose, but Anderson teaches: receiving, from the server computer, authentication information associated with the user ([0047], The order module 156 may also initiate a financial transaction to finalize the purchase of the good or service. In one embodiment, the order module 156 may receive payment credentials from the authorization server 106.)
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 teaching of Anderson with the teaching of Powell as they relate to management of payment token. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified a system of generating a payment token in Powell to include a method of receiving authentication information from the server computer as taught by Anderson for the predicated result of improved and secured method of conducting a transaction using a payment token.
Allowable Subject Matter Over the Prior Art
The following is a statement of reasons for the indication of allowable subject matter: Claim 20 contains allowable subject matter. As per claim 20, 1) Powell et al. (US20150127547A1); 2) Dill et al. (US20150032626A1), fail to teach or suggest the ordered combination “determining, by the server computer, that an authentication process requested by the authorization computer is supported by each of the plurality of selected resource providing entities; facilitating, by the server computer, the authentication process between the user and each of the plurality of selected resource providing entities, facilitating comprising: when the server computer determines that a user of the user account does not have an account with a first selected resource providing entity among the plurality of selected resource providing entities, generating, by the server computer, the account with the first selected resource providing entity; and loading user authentication information available to the server computer to an interface to transmit the user authentication information to the plurality of selected resource providing entities” and the priority date of the instant application is October 15. Therefore, the cited prior arts, taken alone or in combination, fail to explicitly teach each and every limitation of claim 20. The missing claimed elements/features cannot be found in a reasonable number of reference(s). Yet even if the missing claimed elements/features were found in a reasonable number of references, a person of ordinary skill in the art at the time the invention was made would not have been motivated to include these missing elements in an embodiment. Hence, the claims are allowable over the cited prior art. Dependent claims are also allowable for the same reason(s) described above.
Conclusion
THIS ACTION IS MADE Non-FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YIN Y CHOI whose telephone number is (571)272-1094 or yin.choi@uspto.gov. The examiner can normally be reached on M-F 7:30 - 5:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached on 571-270-1492. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/YIN Y CHOI/Examiner, Art Unit 3699 9/12/2026
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699
Prosecution Insights