DETAILED ACTION
Status of Claims
This Office Action is in response to Claims filed on 11/12/2024.
Claims 1-18 are pending and are examined hereon.
Examiner reached out to Applicant’s Rep. (Zalevsky, Marina (Reg. No. 53,825)) and presented an Examiner Amendment as done for the parent applications to put the instant claims in condition for allowance via e-mail, but the proposal have been declined.
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 .
Priority
This application is a continuation or continuation-in-part or divisional application of 17/847,610, 16/032,950, PCT/US18/41686 and Provisional Application 62,531,301. See MPEP § 201.06 (divisional), MPEP § 201.07 (continuation), or MPEP § 201.08 (continuation-in-part). 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 prior-filed applications. Also in accordance with MPEP §2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the prior-filed applications are now considered cited or ‘of record’ in this application. Additionally, applicant is reminded that a listing of the information cited or ‘of record’ in the prior-filed applications need not be resubmitted in this application unless applicant desires the information to be printed on a patent issuing from this application. See MPEP §609.02 A. 2. Finally, applicant is reminded that the prosecution history of the prior-filed applications 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).
Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 120 as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the prior-filed application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. § 112. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed applications, Application Nos. 17/847,610, 16/032,950, PCT/US18/41686 and Provisional Application 62,531,301 (including any material incorporated by reference), fail to provide adequate support in the manner required by 35 U.S.C. § 112 for one or more claims of this application. The above-listed applications fail to provide support for claims 1-2, 4-8, 10-11 and 13-17. The applications at least do not disclose, transmitting, by the initiator server to a first secure remote transaction server associated with the selected account, a transaction request, wherein the first secure remote transaction server generates a transaction identifier after invoking a facilitator application on the client device to authenticate the user; receiving, by the initiator server from the first secure remote transaction server, the transaction identifier; transmitting, by the initiator server, the transaction identifier to the client device; receiving, by the initiator server from the resource provider computer, a request for an account credential, the request comprising the transaction identifier; and transmitting, by the initiator server to the resource provider computer, the account credential associated with the selected account.” (Claims 1 and 10), “prior to the providing the list of accounts, receiving, by the initiator server from the resource provider computer, user identifying information; transmitting, by the initiator server to a plurality of secure remote transaction servers, the user identifying information, wherein each secure remote transaction server determines if the secure remote transaction server is associated with one or more accounts associated with the user based on the user identifying information; and receiving, by the initiator server from the plurality of secure remote transaction servers, accounts associated with a plurality of first secure remote transaction servers among the plurality of secure remote transaction servers, the first secure remote transaction server being one of the plurality of first secure remote transaction servers.” (Claims 2 and 11) “wherein each account of the accounts is associated with one corresponding secure remote transaction server among the plurality of secure remote transaction servers.” (Claims 4 and 13) “wherein the resource provider computer subsequently uses the account credential to complete a transaction.” (Claims 5 and 14) “wherein the account credential includes a token.” (Claims 6 and 15) “wherein the request for the transaction identifier includes information identifying the selected account.” (Claims 7 and 16) “wherein operations of the receiving the request for the account credential and the transmitting the account credential are performed through a communication channel that excludes the client device, so that the client device does not have access to the account credential.” (Claims 8 and 17)
Therefore, as claims 1-2, 4-8, 10-11 and 13-17 of the present application are not supported by the disclosure of prior-filed Provisional Application 62,531,301 and the current claims 1-2, 4-8, 10-11 and 13-17 of the present application do not receive priority to the filing dates of applications Provisional Application 62,531,301.
For the above reasons, the claims affected and their dependents are being compared to the prior art based on a filing date of 07/11/2017 (the filing date of the instant application).
Although 37 CFR 1.55(g)(1) permits the filing of priority papers up to and including the date for payment of the issue fee, it is advisable that such papers be filed promptly after filing the 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-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Analysis
In the instant case, claims 1-9 are directed to a “Method” (Process). Claims 11-18 are directed to “A server computer comprising: a processor; and a non-transitory computer readable medium…” (Machine). Therefore, these claims fall within the four statutory categories of invention.
The claims recite an abstract idea of processing payment transaction, which is an abstract idea. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “Certain Methods of Organizing Human Activity,” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test since the steps include commercial interactions and managing relationships (See MPEP 2106.04 & 2106.04(a)). The use of a physical aid to help perform Organized Human Activity and Mathematical Concept steps does not negate the Organized Human Activity and Mathematical Concept nature of the limitations, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a Methods of Organized Human Activity even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract idea are grouped within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas as they relate to processing checkout requests for payment transactions in an interaction between customers and payment service providers based on relationship of the customers’ accounts information. More specifically, the following non-underlined claim elements recite the abstract idea while the underlined, bolded claim elements recite additional elements according to MPEP 2106.04(a).
Claims 1, as similarly as 10,
A server computer comprising: a processor; and a non-transitory computer readable medium comprising code that, when executed by the processor, causes the processor to perform a method including:
receiving, from a resource provider computer, a checkout request;
providing, to a client device operated by a user, a list of accounts;
receiving, from the client device, a selected account in the list of accounts;
transmitting, to a first secure remote transaction server associated with the selected account, a transaction request, wherein the first secure remote transaction server generates a transaction identifier after invoking a facilitator application on the client device to authenticate the user;
receiving, from the first secure remote transaction server, the transaction identifier;
transmitting the transaction identifier to the client device;
receiving, from the resource provider computer, a request for an account credential, the request comprising the transaction identifier; and
transmitting, to the resource provider computer, the account credential associated with the selected account.
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106.04(d)), the additional elements are merely used as circuitry and tools to perform an abstract idea and generally link the use of a judicial exception to a particular technological environment. Specifically, these additional elements perform the steps or functions of the abstract idea. Viewed as a whole, the use of the additional elements as a tools to implement the abstract idea and generally linking the use of the abstract idea to a particular technological environment does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106.05), using the additional elements to perform the steps amounts to no more than using a computer or processor to automate and implement the abstract idea. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions of the abstract idea. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of processing payment transaction. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and implement the abstract idea. The use of a computer or processor to merely automate and implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05 (f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-9 and 11-18 further describe the abstract idea of processing payment transaction. That is, although claims 2-3 recites further functional steps, each of the dependent claims simply further describe the abstract idea. Further, claims 9 and 18 recite additional elements of resource provider computer hosts an online webpage comprising a checkout element embedded therein, but this additional element do not integrate the abstract idea into a practical application or provide significantly more than the abstract idea. The rest of the dependent claims also do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
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 7 and 16 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 pre-AIA the applicant regards as the invention.
Claims 7 and 16 recite “wherein the request for the transaction identifier.” There is insufficient antecedent basis for this limitation in the claim. Therefore, the scope of the claim is unclear. (See In re Zletz, 893 F.2d 319, 13 USPQ2d 1320 (Fed. Cir. 1989)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8-15 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Chatterjee (US 2012/0310826A1) in view of Dill et al. (US 2015/0032627 A1) in further view of Kennedy et al (US 2018/0315047 A1).
With respect to claims 1 and 10, Chatterjee discloses: a method and a server computer (“pay network server”) comprising: a processor; and a non-transitory computer readable medium comprising code that, when executed by the processor, causes the processor to perform a method including: (Fig. 1; Par. [0029])
receiving, from a resource provider computer (“merchant server”), a checkout request; (Figs. 13, 15A; Pars. [0135] “The PoS client may generate a card authorization request, e.g., 1606, using the obtained transaction authorization input from the user wallet device, and/or product/checkout data…” [0136] “the PoS client may provide the generated card authorization request to the merchant server. The merchant server may forward the card authorization request to a pay gateway server,” [0114])
providing, to a client device operated by a user, a list of accounts (“card selection options”); (Fig. 1A-C; Par. [0031], “In response to obtaining the virtual wallet card selection query, e.g., 119, the pay network database may provide, e.g., 120, the requested virtual wallet card selection options to the pay network server. The pay network server may generate a request for a selection of one of the payment options from the user's virtual wallet, and provide, e.g., 122, the virtual wallet card selection request to a user device, e.g., 102 b,” [0035], [0067])
receiving, from the client device, a selected account in the list of accounts; (Fig. 1; Pars. [0033] “The user device may generate a virtual wallet card selection response based on the user's card selection input, and provide, e.g., 125, the virtual wallet card selection response to the pay network server…” [0057])
transmitting, to a first secure remote transaction server (“issuer server”) associated with the selected account, a transaction request, (Figs. 4B; Pars. [0058] “the pay network server may utilize the issuer server data to generate a card authorization request, e.g., 430, to redirect the card authorization request from the acquirer server, via the user's virtual wallet card selection, to the issuer server. The pay network server may provide the card authorization request, e.g., 431, to the issuer server.”)
transmitting the transaction identifier to the client device; (Fig. 1C; Par. [0039] “For example, the receipt may include a purchase identifier, e.g., 116c.” [0114] “the payment network may provide notifications to the user, such as a payment receipt…”)
account credential (“AnonCard1,” “AnonCard2”). (Figs. 2, 8A; Pars. [0041] “the user may select to conduct the transaction using a one-time anonymized credit card number, see e.g., 205 b. For example, the VWCS may utilize a pre-designated anonymized set of card details (see, e.g., “AnonCard1,” “AnonCard2”). As another example, the VWCS may generate, e.g., in real-time, a one-time anonymous set of card details to securely complete the purchase transaction (e.g., “Anon It 1X”).” [0085])
Chatterjee does not explicitly disclose wherein the first secure remote transaction server generates a transaction identifier after invoking a facilitator application on the client device to authenticate the user. However, this limitation is an intended use/functional language of the first secure remote transaction server and does not have patentable weight as it describes the intended use of the first secure remote transaction server. As the claimed invention is directed to functions of the initiator server, the recitation of the intended use/functional language of the first secure remote transaction server of the claimed invention does not serve to differentiate the claims from the prior art. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use. (See (MPEP §2103 I C)).
Further, Chatterjee does not explicitly disclose:
receiving, from the resource provider computer, a request for an account credential, the request comprising the transaction identifier;
transmitting, to the resource provider computer, the account credential associated with the selected account.
However, Dill disclose:
receiving, from the resource provider computer (“merchant computer 140”), a request for an account credential, (Par. [0127] “the merchant token interface 210 may allow the merchant computer 140 to communicate with the network token system 202 for… token exchange… For example, the merchant computer 140 may use the merchant token interface 210 to request PAN information associated with a given token from the network token system 202… the token exchange may be requested for bulk tokens.”)
the request comprising the transaction identifier; (Par. [0225] “a merchant… with an ISO connection may use the provisioning request to request a token through the existing payment processing network… the request message may include the… transaction Identifier”) and
transmitting, to the resource provider computer, the account credential (Par. [0226] “In step 810, the network token system 202 generates and/or determines a token associated with the token request and provides the token 804 to the token requestor in response to the token request. For example, referring back to FIG. 3, the network token system 202 may provide a token value (e.g., token number)… to the token requestor 204. In some embodiments, the network token system 202 may generate the token value based on the real issuer identifier (e.g., BIN) of the account identifier (e.g., PAN) provided in the token request.”
associated with the selected account. (Par. [0097] “The consumer 110 may be able to initiate a transaction using a payment account identifier that may be payment card branded such as Visa®, MasterCard®, American Express®, Discover®, etc.”)
Therefore, 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 to substitute one equivalent technique for another to accomplish the same. That is, simply substituting the card query request used to generate a card authorization request redirected from the merchant to the pay network server before providing authorization response including user account data (Fig. 15B; Pars. [0029] “the acquirer server may generate a card authorization request, e.g., 116, using the obtained card query request, and provide the card authorization request, e.g., 117, to a pay network server, e.g., 105. For example, the acquirer server may redirect the HTTP(S) POST message in the example above from the merchant server to the pay network server.” [0130] “the pay network server may generate a transaction data record from the… authorization response… For example, the pay network server may issue PHP/SQL commands… account? Name… account_num” [0131] “the pay network server may forward a transaction authorization response, e.g., 1532, to the… PoS client, and/or merchant server…”) of Chatterjee in view of Dill in order to provide authorization for payment transaction using user linked payment data (Chatterjee, Par. [0128] “obtaining the user account(s) data, e.g., 1528, the issuer server may determine whether the user can pay for the transaction using funds available in the account, 1529. For example, the issuer server may determine whether the user has a sufficient balance remaining in the account… Based on the determination, the issuer server(s) may provide a funds authorization response, e.g., 1530, to the pay network server.”) and to improve transaction security and increase transparency by using account credentials (“tokens”) that are associated with the user account for completing secure transactions (Dill, Par. [0029] “Tokens can also improve transaction security and increase service transparency. Furthermore, tokenization can reduce merchant and issuer costs by improving data security and reducing or eliminating the need to be PCI-DSS compliant.”). ("Express suggestion to substitute one equivalent technique for another need not be present to render such substitution obvious"; In re Fout, 213 USPQ 532 (CCPA 1982), In re Siebentritt, 152 USPQ 618 (CCPA 1967); Ex Parte Smith, 83 USPQ2d 1509 (Bd. Pat. App. & Int. 2007); KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007)).
Neither Chatterjee nor does Dill explicitly disclose receiving, from the first secure remote transaction server, the transaction identifier.
Kennedy disclose receiving, from the first secure remote transaction server, the transaction identifier. (Par. [0037] “The receiving device 202 may be configured to receive data signals electronically transmitted by issuing institutions 106 that are superimposed or otherwise encoded with chargeback requests, which may include at least a specific transaction identifier associated with a payment transaction corresponding to the chargeback request.”)
Therefore, 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 to substitute one equivalent technique for another to accomplish the same. That is, simply substituting the payment confirmation that contains payment request ID associated with the transaction which is generated by the issuer and transmitted to Pay Network (Fig. 17B; Par. [0145] “The issuer server may provide an individual payment confirmation, e.g., 1728, to the pay network server… An example listing of an individual payment confirmation 1728, substantially in the form of a HTTP(S) POST message including XML-formatted data… request_ID”) of Chatterjee, Dill in view of Kennedy in order to corelate transaction data with the merchant before completing the transaction (Chatterjee, Pars. [0065] “the acquirer server may parse the funds transfer message, and correlate the transaction (e.g., using the request_ID field in the example above) to the merchant. The acquirer server may then transfer the funds specified in the funds transfer message to an account of the merchant, e.g., 460.”) and to record transaction data in a transactions databased only after verifying the transaction associated data based on transaction ID (Kennedy, Par. [0049] “In step 308, the generation module 216 of the processing server 102 may generate a first blockchain data value. The first blockchain data value may include at least the specific transaction identifier as well as an indication that a chargeback has been requested for the related payment transaction.”). ("Express suggestion to substitute one equivalent technique for another need not be present to render such substitution obvious"; In re Fout, 213 USPQ 532 (CCPA 1982), In re Siebentritt, 152 USPQ 618 (CCPA 1967); Ex Parte Smith, 83 USPQ2d 1509 (Bd. Pat. App. & Int. 2007); KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007)).
With respect to claims 2 and 11, Chatterjee, Dill in view of Kennedy disclose all the limitations as described above. Additionally, Chatterjee discloses:
prior to the providing the list of accounts, (Fig. 1A; Step 115 (“card authorization request”) is prior to Step 112 (“the user device may render, e.g., 511, the virtual wallet card selection options provided by the pay network server,”))
receiving, by the initiator server from the resource provider computer, user identifying information (“account name>John Q. Publics, account name>...”); (Pars. [0028] “the merchant server may provide a HTTP(S) POST message including… account name>John Q. Publics, account name>... [0029] “the acquirer server may redirect the HTTP(S) POST message in the example above from the merchant server to the pay network server.” [0120])
transmitting, by the initiator server to a plurality of secure remote transaction servers, the user identifying information, (Fig. 15B; Pars. [0125]-[0126] “the pay network server may utilize the issuer server data to generate funds authorization request(s), e.g., 1526, for each of the issuer server(s) selected based on the pre-defined payment settings associated with the user's virtual wallet, and/or the user's payment options input, and provide the funds authorization request(s) to the issuer server(s)… An example listing of a funds authorization request 1526, substantially in the form of a HTTP(S) POST message including XML-formatted data… <account name>John Q. Publics, account name>”) and
receiving, by the initiator server from the plurality of secure remote transaction servers (“issuer server(s)”), accounts associated with a plurality of first secure remote transaction servers among the plurality of secure remote transaction servers, (Figs. 15B; Pars. [0126] “HTTP(S) POST message including XML-formatted data… <account numbers>…” [0128] “Based on the determination, the issuer server(s) may provide a funds authorization response, e.g., 1530, to the pay network server. For example, the issuer server(s) may provide a HTTP(S) POST message similar to the examples above.” [0145])
the first secure remote transaction server being one of the plurality of first secure remote transaction servers. (Figs. 15B; Par. [0138] “Issuer server(s) of the issuer(s) may maintain details of the user's account(s).”)
Although Chatterjee disclose wherein each secure remote transaction server determines if the secure remote transaction server is associated with one or more accounts associated with the user based on the user identifying information (Fig. 15B; Pars. [0127] “an issuer server may parse the authorization request(s), and based on the request details may query a database, e.g., user profile database 1506 b, for data associated with an account linked to the user… An example user account(s) query 1527, substantially in the form of PHP/SQL commands… Squery = "SELECT issuer user id user name user balance account type FROM” [0128] “on obtaining the user account(s) data, e.g., 1528, the issuer server may determine whether the user can pay for the transaction using funds available in the account, 1529. For example, the issuer server may determine whether the user has a sufficient balance remaining in the account, sufficient credit associated with the account, and/or the like. Based on the determination, the issuer server(s) may provide a funds authorization response, e.g., 1530, to the pay network server.”), this limitation is an intended use/functional language of each secure remote transaction server and does not have patentable weight as it describes the intended use of the secure remote transaction servers. As the claimed invention is directed to a function of the initiator server, the recitation of the intended use/functional language of the secure remote transaction servers of the claimed invention does not serve to differentiate the claims from the prior art. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use. (See (MPEP §2103 I C)).
With respect to claims 3 and 12, Chatterjee, Dill in view of Kennedy disclose all the limitations as described above. Additionally, Chatterjee discloses identifying, by the initiator server, the user using the user identifying information. (Pars. [0035] “The pay network may identify, e.g., 108, based on the universal card details, that the user associated with the universal card has access to a virtual wallet of cards.” [0042] “The VWCS may utilize the VerifyChat feature to communicate with the user, and verify the authenticity of the originator of the purchase transaction.”)
With respect to claims 4 and 13, Chatterjee, Dill in view of Kennedy disclose all the limitations as described above. Additionally, Chatterjee discloses:
wherein each account of the accounts is associated with one corresponding secure remote transaction server among the plurality of secure remote transaction servers. (Figs. 15B; Pars. [0071], [0125] “the pay network server may generate a query, e.g., 1524, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions (“issuers”), such as banking institutions, which issued the account(s) for the user… Issuer server(s), e.g., 1506 a, of the issuer(s) may maintain details of the user's account(s). In some embodiments, a database, e.g., pay network database 1505 b, may store details of the issuer server(s) associated with the issuer(s). In some embodiments, the pay network server may query a database, e.g., pay network database 1505 b, for a network address of the issuer(s) server(s), for example by using a portion of a user payment card number, or a user ID (such as an email address) as a keyword for the database query…” [0127])
With respect to claims 5 and 14, Chatterjee, Dill in view of Kennedy disclose all the limitations as described above.
Although Chatterjee disclose wherein the resource provider computer subsequently uses the account credential to complete a transaction (Fig. 2; Par. [0120]-[0121], [0041] “In some implementations, the user may select to conduct the transaction using a one-time anonymized credit card number, see e.g., 205 b. For example, the VWCS may utilize a pre-designated anonymized set of card details (see, e.g., “AnonCard1,” “AnonCard2”). As another example, the VWCS may generate, e.g., in real-time, a one-time anonymous set of card details to securely complete the purchase transaction (e.g., “Anon It 1X”). In such implementations, the app may automatically set the user profile settings such that the any personal identifying information of the user will not be provided to the merchant and/or other entities.”), this limitation is an intended use/functional language of the resource provider computer and does not have patentable weight as it describes the intended use of the resource provider computer. As the claimed invention is directed to a function of the initiator server, the recitation of the intended use/functional language of the resource provider computer of the claimed invention does not serve to differentiate the claims from the prior art. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use. (See (MPEP §2103 I C))
With respect to claims 6 and 15, Chatterjee, Dill in view of Kennedy disclose all the limitations as described above. Additionally, Chatterjee discloses wherein the account credential includes a token. (Fig. 2; Pars. [0041], [0219])
With respect to claims 8 and 17, Chatterjee, Dill in view of Kennedy disclose all the limitations as described above.
Chatterjee does not explicitly disclose wherein operations of the receiving the request for the account credential and the transmitting the account credential are performed through a communication channel that excludes the client device, so that the client device does not have access to the account credential.
However, Dill disclose wherein operations of the receiving the request for the account credential and the transmitting the account credential are performed through a communication channel that excludes the client device, so that the client device does not have access to the account credential. (Fig. 2; Pars. [0096] “The system 200 may also include token interfaces 208-218 with the network token system 202 including a token requestor interface 208…”)
Therefore, 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 to substitute one equivalent technique for another to accomplish the same. That is, simply substituting the card query request used to generate a card authorization request redirected from the merchant to the pay network server before providing authorization response including user account data (Fig. 15B; Pars. [0029], [0131]) of Chatterjee in view of Dill in order to provide authorization for payment transaction using user linked payment data (Chatterjee, Par. [0128]) and to improve transaction security and increase transparency by using account credentials (tokens) that are associated with the user account for completing secure transactions (Dill, Par. [0029] “Tokens can also improve transaction security and increase service transparency. Furthermore, tokenization can reduce merchant and issuer costs by improving data security and reducing or eliminating the need to be PCI-DSS compliant.”). ("Express suggestion to substitute one equivalent technique for another need not be present to render such substitution obvious"; In re Fout, 213 USPQ 532 (CCPA 1982), In re Siebentritt, 152 USPQ 618 (CCPA 1967); Ex Parte Smith, 83 USPQ2d 1509 (Bd. Pat. App. & Int. 2007); KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007)).
With respect to claims 9 and 18, Chatterjee, Dill in view of Kennedy disclose all the limitations as described above.
Although Chatterjee disclose wherein the resource provider computer hosts an online webpage comprising a checkout element embedded therein (Fig. 3; Par. [0112]-[0113] “The client may generate a checkout request, e.g., 1312, and provide the checkout request, e.g., 1313, to the merchant server. For example, the client may provide a (Secure) Hypertext Transfer Protocol (“HTTP(S)”) POST message including the product details for the merchant server in the form of data formatted according to the eXtensible Markup Language (“XML”). An example listing of a checkout request 1312, substantially in the form of a HTTP(S) POST message including XML-formatted data… Host: www.merchat.com... ”), this limitation is an intended use/functional language of the resource provider computer and does not have patentable weight as it describes the intended use of the resource provider computer. As the claimed invention is directed to a function of the initiator server, the recitation of the intended use/functional language of the resource provider computer of the claimed invention does not serve to differentiate the claims from the prior art. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use. (See (MPEP §2103 I C))
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Chatterjee (US 2012/0310826 A1) in view of Dill et al. (US 2015/0032627 A1) in view of Kennedy et al (US 2018/0315047 A1) in further view of Ong (US 2005/0246293 A1).
With respect to claims 7 and 16, Chatterjee, Dill in view of Kennedy disclose all the limitations as described above.
Neither Chatterjee, Dill nor Kennedy disclose wherein the request for the transaction identifier includes information identifying the selected account.
Ong discloses wherein the request for the transaction identifier includes information identifying the selected account. (Fig. 10; Par. [0145] “The process starts at 82. At 84 the user submits a request for a transaction identification number to the transaction manager. At 86 the transaction manager receives the request for the transaction identification number and performs a validation of the user's account, including whether the user has an account and whether the account is active. The user making the request also provides either their account number or their account alias to the transaction manager to identify the user.”)
Therefore, 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 to substitute one equivalent technique for another to accomplish the same. That is, simply substituting the user’s request for checkout transaction made using a selected payment method (Fig. 3; Par. [0112]-[0113]) of Chatterjee, Dill, Kennedy in view of Ong in order to for the user to receive a payment receipt identifying the selected payment used for the payment transaction with associated transaction identifier (Chatterjee, Par. [0039] “The user may utilize the purchase confirmation receipt obtained from the VWCS via the app on the client device to provide such proof of product purchase, e.g., 116 a. For example, the receipt may include a purchase identifier, e.g., 116 c.”) and to verify user associated account before approving the request for specific transaction (Ong, Par. [0145] “A check is performed at 88 of the validity of the user's account. If rejected the process returns to the start at 82. If accepted the process moves to 90. The transaction manager approves the request and supplies the user with one or more transaction identification numbers.”). ("Express suggestion to substitute one equivalent technique for another need not be present to render such substitution obvious"; In re Fout, 213 USPQ 532 (CCPA 1982), In re Siebentritt, 152 USPQ 618 (CCPA 1967); Ex Parte Smith, 83 USPQ2d 1509 (Bd. Pat. App. & Int. 2007); KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007)).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
PGPub Cornick et al. (US 2019/0257033 A1) discloses: identifying, by the initiator server, the user using the user identifying information. (Par. [0048] “The merchant payment system is then configured and operable to transmit the user identification token and scanned user biometrics to the central processing system 210 for verification (step 520). The central processing system 210 is configured and operative to confirm a biometric match between biometric data stored for the user 290 on the user identification token and the matching biometric features of the user 290 collected at the time of verification by the merchant payment system (step 525). If there is a match, the user's identity is verified and authenticated, and an authorizing signal is preferably sent back to the merchant payment system to authorize the financial transaction as well as provide a Return Session ID Token (step 530).”)
PGPub Hwang et al. (US 2016/0078432 A1) discloses wherein the request for the transaction identifier includes information identifying the selected account. (Par. [0012] “The method includes transmitting, to a service server, a transaction Identification (ID) request for the transaction service with a service provider; receiving, from the service server, a transaction ID that is generated by the service server in response to the transaction ID request”)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WODAJO GETACHEW whose telephone number is (469)295-9069. The examiner can normally be reached M-F 8:00-6:00 CST.
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, John W Hayes can be reached at (571) 272-6708. 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.
/WODAJO GETACHEW/Examiner, Art Unit 3697
Prosecution Insights