DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
2. Applicant filed the amendment on 10/06/2025. Claims 1-2, 4-5, and 7-21 are pending. Claims 1-2, 4-5, and 7-21 are amended. Claims 1-2, 4-5, and 7-21 are rejected. After careful consideration of applicant arguments, the examiner finds them to be not persuasive.
Rejection under 35 USC § 101
3. Applicant is of the opinion that the amended independent claims 1, 9, and 16 will overcome 35 U.S.C. § 101 rejection.
4. Examiner respectfully disagrees.
Analysis of claims show that the amended claims 1, 9, and 16 directed to an abstract idea grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)). (See below).
Rejections under 35 U.S.C. § 112(a)
5. Rejections of claims 1-2, 4-5, and 7-21 due to amendments claims 1, 9, and 16 are withdrawn.
Rejections under 35 U.S.C. § 112(b)
6. Rejections of claims 1-2, 4-5, and 7-21 due to amendments claims 1, 9, and 16 are withdrawn.
Claim Interpretation
Intended Use
7. Intended use language is generally not given patentable weight. See MPEP 2114(II) ("A claim containing a 'recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim. Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987).”); see also MPEP 2103(C). Examples of claim limitations that are often found to precede intended use include “adapted to,” “capable of,” “sufficient to,” “whereby,” and “for.”
8. Claim 11 recites “…facilitating … to allow the merchant system to settle …”.
Claims 14 and 20 recite “… processing the client information to confirm …”
Claim 17 recites “wherein the instructions further cause … for facilitating … to allow the merchant system to settle …”
The underlined limitations represent intended use and are not given patentable weight.
Claim Rejections - 35 USC §101
9. 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.
10. Claims 1-2, 4-5, and 7-21 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.
11. In the instant case, claims 1, 9, and 16 are directed to a “method, system, and a non-transitory computer readable storage medium for data security with modular website integration”.
12. Claim 1 recites “transmitting a tokenized account number for processing a purchase transaction”. Specifically, claim recites “receiving … a purchase transaction associated …; …; receiving … a selection … wherein the selection … is associated …; facilitating transmission … wherein the facilitated transmission includes … and wherein the facilitated transmission is based on the received selection; receiving … wherein receiving … and wherein …; facilitating transmission … wherein transmission is based on receipt … and wherein transmission is facilitated between …; facilitating activation …; receiving … an indication that … has been closed; facilitating access … to a tokenized account number associated with …, wherein facilitation is based on the received indication; and facilitating transmission of the tokenized account number … wherein transmission is facilitated …”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
13. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as “facilitating a display, by a merchant system, wherein the display is facilitated on a website on a client device”, “facilitating a display, by the merchant system, wherein the display is facilitated on an interface within the website, wherein the interface includes a checkout element associated with an account security system”, “a checkout communication associated with the account security system”, “a client token”, “the client token is associated with the account security system”, “a modal between the client device and the account security system”, and “the activated modal associated with the client device” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. With respect to “receiving, by the merchant system, a purchase transaction associated with the client device”, “receiving, by the merchant system, a selection of the checkout element, wherein the selection of the checkout element is associated with the client device”, “facilitating transmission, by the merchant system, wherein the facilitated transmission includes a checkout communication associated with the account security system, and wherein the facilitated transmission is based on the received selection”, “receiving a client token, by the merchant system, wherein receiving the client token is based on the checkout communication, and wherein the client token is associated with the account security system”, “facilitating transmission of the client token, by the merchant system, wherein transmission is based on receipt of the client token, and wherein transmission is facilitated between the merchant system and the client device”, “receiving, by the merchant system, an indication that the activated modal associated with the client device has been closed”, and “facilitating transmission of the tokenized account number, by merchant system, wherein transmission is facilitated between the merchant system and a payment system” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)). The additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of transmitting a tokenized account number for processing the purchase transaction.
14. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of transmitting a tokenized account number for processing the purchase transaction using computer technology. Therefore, as the use of these additional elements do no more than employ a computer as a tool to automate and/or implement the abstract idea, they cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
15. Hence, claim 1 is not patent eligible.
16. Claims 9 and 16 also recite “transmitting a tokenized account number for processing the purchase transaction”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
17. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of the claims 9 and 16 such as “an account security system”, “a memory”, “one or more processors”, “facilitating a display, by a merchant system, wherein the display is facilitated on a website on a client device”, “facilitating a display, by the merchant system, wherein the display is facilitated on an interface within the website, wherein the interface includes a checkout element associated with an account security system”, “a checkout communication associated with the account security system”, “a client token”, “the client token is associated with the account security system”, “a modal between the client device and the account security system”, and “the activated modal associated with the client device”, “a non-transitory computer readable storage medium”, and “a processor” represent the use of a computer as a tool to perform an abstract idea and/or do no more than generally link the abstract idea to a particular field of use. With respect to “receiving, by the merchant system, a purchase transaction associated with the client device”, “receiving, by the merchant system, a selection of the checkout element, wherein the selection of the checkout element is associated with the client device”, “facilitating transmission, by the merchant system, wherein the facilitated transmission includes a checkout communication associated with the account security system, and wherein the facilitated transmission is based on the received selection”, “receiving a client token, by the merchant system, wherein receiving the client token is based on the checkout communication, and wherein the client token is associated with the account security system”, “facilitating transmission of the client token, by the merchant system, wherein transmission is based on receipt of the client token, and wherein transmission is facilitated between the merchant system and the client device”, “receiving, by the merchant system, an indication that the activated modal associated with the client device has been closed”, and “facilitating transmission of the tokenized account number, by merchant system, wherein transmission is facilitated between the merchant system and a payment system” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)). The additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of transmitting a tokenized account number for processing the purchase transaction.
18. When analyzed under step 2B (MPEP 2106.04 II), the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describe the concept of transmitting a tokenized account number for processing the purchase transaction using computer technology. Therefore, as the use of these additional elements do no more than employ a computer as a tool to automate and/or implement the abstract idea, they cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
19. Hence, claims 9 and 16 are not patent eligible.
20. Dependent claims 2 and 10 further describe the abstract idea of transmitting a tokenized account number for processing the purchase transaction as each recites “wherein … authorizes payment with … as part of the purchase transaction”. The additional elements such as “the merchant system”, “a system independent”, and “the account security system” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claims 4, 12, and 18 further describe the abstract idea of transmitting a tokenized account number for processing the purchase transaction as each recites “receiving … an account lookup request without an account number associated with the tokenized account number”. The additional element such as “the account security system” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claims 5, 13, and 19 further describe the abstract idea of transmitting a tokenized account number for processing the purchase transaction as each recites “receiving … an account verification request and an account number associated with the tokenized account number”. The additional element such as “the account security system” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 7 further describes the abstract idea of transmitting a tokenized account number for processing the purchase transaction as recites “opening a secure channel with … prior to receipt of the client token, wherein the client token is received from … using the secure channel; and receiving a request for the tokenized account number from … wherein the request is generated … subsequent to an indication that … is closed, and wherein the tokenized account number is transmitted to … subsequent to the request”. The additional elements such as “the client device”, “the activated modal on the client device”, and “a merchant device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 8 further describes the abstract idea of transmitting a tokenized account number for processing the purchase transaction as recites “wherein the checkout communication is received as using a secured post channel; wherein the client token is transmitted to … with a postback identifier using the secured post channel; and wherein … is opened on … and the secure channel is established between … subsequent to the client token as communicated to …”. The additional elements such as “the checkout communication”, “the merchant device”, “wherein the activated modal is opened on the client device”, and “the account security system” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 11 further describes the abstract idea of transmitting a tokenized account number for processing the purchase transaction as recites “wherein … are further configured to perform operations comprising facilitating the purchase transaction by sharing the tokenized account number with … to allow …to settle payment for the purchase transaction with … without … having access to client information”. The additional elements such as “the one or more processors”, “the system”, and “the merchant system” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 14 further describes the abstract idea of transmitting a tokenized account number for processing the purchase transaction as recites “wherein … are further configured to perform operations further comprising processing client information to confirm that the client information is from …”. The additional elements such as “the one or more processors” and “a secure client device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 15 further describes the abstract idea of transmitting a tokenized account number for processing the purchase transaction as recites “wherein … are further configured to perform operations comprising: opening a secure channel with … prior to receipt of the client token, wherein the client token is received from … using the secure channel; receiving a request for the tokenized account number from …, wherein the request is generated … subsequent to closure of …, and wherein the tokenized account number is transmitted to … subsequent to the request, wherein the checkout communication is received as using …; wherein the client token is transmitted to … with a postback identifier using …; and wherein … is opened on … and the secure channel is established between … subsequent to the client token as communicated …”. The additional elements such as “the one or more processors”, “the communication channel”, “the client device”, “the checkout communication”. “the modal on the client device”, “a merchant device”, “a secured post channel”, and “the account security system” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 17 further describes the abstract idea of transmitting a tokenized account number for processing the purchase transaction as recites “wherein … authorizes payment with … as part of the purchase transaction; and wherein when executed by…, the instructions further cause … to perform operations for facilitating the secure transaction by sharing the tokenized account number with … to allow … to settle payment for the purchase transaction … without … having access to client information”. The additional elements such as “the merchant system”, “a system independent”, “the account security system”, “the processor”, and “the merchant system” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 20 further describes the abstract idea of transmitting a tokenized account number for processing the purchase transaction as recites “wherein when executed, the instructions further cause … to perform operations including processing client information to confirm that the client information is from …”. The additional elements such as “the processor” and “a secure client device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 21 further describes the abstract idea of transmitting a tokenized account number for processing the purchase transaction as recites “wherein the client token is used to verify … and wherein verification includes using … channel, and … to verify …”. The additional elements such as “the merchant system”, “the client device”, “the communication channel”, and “the activated modal” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Conclusion
21. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
22. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
23. 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 (i.e., changing from AIA to pre-AIA ) 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.
24. 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.
25. The factual inquiries 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.
26. Claims 1-2, 4-5, and 7-21 are rejected under 35 U.S.C. 103 as being unpatentable over US20120316992A1 to Oborne in view of US8763142B2 to McGuire et al.
27. As per claims 1, 9, and 16:
Oborne discloses the following limitations:
receiving, by the merchant system, a purchase transaction associated with the client device ([0035] “…the user may direct a browser application executing on the client device to a website of the merchant, and may select a product from the website via clicking on a hyperlink presented to the user via the website…”, [0036] “…a browser application executing on the client may provide, on behalf of the user, a (Secure) Hypertext Transfer Protocol ("HTTP(S)") GET message including the product order details for the merchant server…”)
facilitating a display, by the merchant system, wherein the display is facilitated on an interface within the website, wherein the interface includes a checkout element associated with an account security system ([0027] “…the app may utilize the default settings of the user to initiate the purchase transaction. In some implementations, the app may allow the user to utilize other accounts (e.g., Google.TM. Checkout, Paypal.TM. account, etc.) to pay for the purchase transaction …”, [0040] “The client may render, e.g., 421, the tokenization invitation and application form, and display, e.g., 422, the invitation and application form for the user”)
receiving, by the merchant system, a selection of the checkout element, wherein the selection of the checkout element is associated with the client device ([0040] “… the user … may provide token creation input to complete the application form, e.g., 423 …”)
facilitating transmission, by the merchant system, wherein the facilitated transmission includes a checkout communication associated with the account security system, and wherein the facilitated transmission is based on the received selection ([0040] “…The client may generate a competed application form, and provide, e.g., 424, the token application to the token server…”)
receiving a client token, by the merchant system, wherein receiving the client token is based on the checkout communication, and wherein the client token is associated with the account security system ([0041] “The token server may obtain the application form, and parse the form to extract data fields and values from the form to generate a token data record, e.g., 425…”, [0048] “…The token server may also provide a token identifier, e.g., 517 to the client…”)
facilitating transmission of the client token, by the merchant system, wherein transmission is based on receipt of the client token, and wherein transmission is facilitated between the merchant system and the client device ([0048] “… The token server may also provide a token identifier, e.g., 517 to the client. The token may be provided as a data structure via HTTP(S) POST, as a file (via file transport protocols), as an attachment (e.g., via email), and/or otherwise provided to the client device for later use. The client may store the token identifier and/or display the token identifier for the user…”)
facilitating activation of a modal between the client device and the account security system ([0030] “…In some implementations, the app executing on the user's device may provide a “VerifyChat” feature for fraud prevention (e.g., by activating UI element 213 in FIG. 2)… the PPT may initiate a video challenge for the user, e.g., 301. For example, the user may need to present him/her-self via a video chat, e.g., 302…”, [0031] “In some implementations, the PPT may utilize a text challenge procedure to verify the authenticity of the user, e.g., 306 … The PPT may pose a challenge question, e.g., 308, for the user. The app may provide a user input interface element(s) (e.g., virtual keyboard 309) to answer the challenge question …”)
receiving, by the merchant system, an indication that the activated modal associated with the client device has been closed ([0030] “…In some implementations, the user may not have initiated the transaction, e.g., the transaction is fraudulent. In such implementations, the user may cancel, e.g., 305, the challenge. The PPT may then cancel the transaction…”, [0031] “…the user may cancel, e.g., 307, 310, the text challenge. The PPT may then cancel the transaction, and/or initiate fraud investigation procedures on behalf of the user.”)
facilitating access, by the merchant system, to a tokenized account number associated with the client device and the account security system, wherein facilitation is based on the received indication ([0053] “… the token server may parse the token arbitration request message, and extract the payment token from the message. The token server may determine the payment options to utilize (or determine whether to request the user to provide payment options details) for processing the transaction, using the payment token.”, [0057] “In some implementations, the token server may provide the token data, issuer data, and/or user payment options input, e.g., 634, to a pay network server…”)
facilitating transmission of the tokenized account number, by merchant system, wherein transmission is facilitated between the merchant system and a payment system ([0057] “…The pay network server may process the transaction so as to transfer funds for the purchase into an account stored on an acquirer of the merchant… the acquirer may be a financial institution maintaining an account of the merchant…”, [0065] “… The pay network server may generate an individual payment request, e.g., 664, for each transaction for which it has extracted transaction data, and provide the individual payment request, e.g., 665, to the issuer server…”)
Oborne does not disclose, however, McGuire et al., as shown, teaches the following limitations:
facilitating a display, by a merchant system, wherein the display is facilitated on a website on a client device (Col.8, lines 50-56 “Web store 110 includes one or more computers containing an application used by an end user (e.g., a consumer making a purchase from an online web merchant) to purchase one or more goods and/or services. During the payment portion of a purchase transaction, web store 110 employs an application-programming interface (API) to transmit a payment-card number to tokenizer 120”.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a data-processing system, such as a payment processing system, including a tokenizer, such as a card encryption and storage system (CES) employing a tokenization feature of McGuire et al. (‘142, col.2, lines 34-37) with teaching of Oborne of transforming payment token-based purchase orders via tokenization systemin components into multi-issuer purchase payment funds transfers (‘992, [0022]) for providing to a user a user interface while purchasing one or more goods and/or services from the merchant’s website (‘142, Col.8, lines 51-53).
As per claim 9 Oborne additionally discloses the following limitations:
a memory (Fig.15, item 1529, [0119] “A computer systemization 1502 may comprise… a memory 1529…”)
one or more processors (Fig.15, item 1503, [0119] “A computer systemization 1502 may comprise … central processing unit (“CPU(s)” and/or “processor(s)…”)
As per claim 16 Oborne additionally discloses the following limitations:
A non-transitory computer readable storage medium (Fig.15, item 1514, [0132] “… A storage device 1514 may be any conventional computer system storage…”)
one or more processors (Fig.15, item 1503, [0119] “A computer systemization 1502 may comprise … central processing unit (“CPU(s)” and/or “processor(s)…”)
28. As per claims 2 and 10:
Oborne discloses the following limitations:
wherein the merchant system authorizes payment with a system independent of the account security system as part of the purchase transaction ([0037] “In some implementations, the merchant server may obtain the purchase order message from the client, and may parse the purchase order message to extract details of the purchase order from the user. Based on the parsing, the merchant server may determine that the purchase order message is not tokenized, e.g., 414…”, [0053] “In various implementations, the token server may be part of the merchant system (e.g., a merchant process), or part of the payment network (e.g., a pay network server), or an independent server operating in conjunction with the merchant, issuer, acquirer and payment network…”, [0063] “…The merchant may obtain the authorization message, and determine from it that the user possesses sufficient funds in the card account to conduct the transaction. The merchant server may add a record of the transaction for the user to a batch of transaction data relating to authorized transactions…”)
29. As per claims 4, 12, and 18:
Oborne discloses the following limitations:
receiving, at the account security system, an account lookup request without an account number associated with the tokenized account number ([0051] “… the merchant server may utilize a hypertext preprocessor (“PHP”) script including Structured Query Language (“SQL”) commands to query a relational database for an address of a token arbitrator…”, [0053] “… the token server may parse the token arbitration request message, and extract the payment token from the message. The token server may determine the payment options to utilize … using the payment token … For example, the token server may issue, e.g., 619, a user issuer query to a database, e.g., token database 606, using the payment token as search term in the query…”)
30. As per claims 5, 13, and 19:
Oborne discloses the following limitations:
receiving, at the account security system, an account verification request and an account number associated with the tokenized account number ([0041] “…The token server may obtain the application form, and parse the form to extract data fields and values from the form to generate a token data record, e.g., 425…”, [0048] “… The token server may store the token data structure to a token database…”, [0060] “…an issuer server may parse the authorization request(s), and based on the request details may query a database, e.g., user profile database 610 a-n, for data associated with an account linked to the user's payment token…”, [0148] “…A Tokens table 1519 h may include fields such as, but not limited to: token_id, token_phrase, token_issuer, token_md5, token security, user_id, password, token_composition_list, account_link…”)
31. As per claim 7:
Oborne discloses the following limitations:
opening a secure channel with the client device prior to receipt of the client token, wherein the client token is received from the client device via the activated modal on the client device using the secure channel ([0030] “…In some implementations, the app executing on the user's device may provide a “VerifyChat” feature for fraud prevention … the PPT may initiate a video challenge for the user, e.g., 301. For example, the user may need to present him/her-self via a video chat, e.g., 302…”, [0040] “… the user … may provide token creation input to complete the application form, e.g., 423. The client may generate a competed application form, and provide, e.g., 424, the token application to the token server…”, [0161] “…the PPT controller may be executing a PHP script implementing a Secure Sockets Layer (“SSL”) socket server via the information server, which listens to incoming communications on a server port to which a client may send data, e.g., data encoded in JSON format…”)
receiving a request for the tokenized account number from a merchant device, wherein the request is generated by the merchant device subsequent to an indication that the activated modal on the client device is closed, and wherein the tokenized account number is transmitted to the merchant device subsequent to the request ([0030] “…In some implementations, the user may not have initiated the transaction, e.g., the transaction is fraudulent. In such implementations, the user may cancel, e.g., 305, the challenge. The PPT may then cancel the transaction…”, [0052] “…The merchant server may generate a token arbitration request, e.g., 617, and provide the token arbitration request, e.g., 618, to a token server…”, [0063] “… In some implementations, the pay network server may forward an authorization success message, e.g., 646, to the token server, which may in turn forward the authorization success message, e.g., 647, to the merchant server…”)
32. As per claim 8:
Oborne discloses the following limitations:
wherein the checkout communication is received as using a secured post channel ([0036] “…For example, a browser application executing on the client may provide, on behalf of the user, a (Secure) Hypertext Transfer Protocol (“HTTP(S)”) GET message including the product order details for the merchant server…Below is an example HTTP(S) GET message including an XML-formatted purchase order message…”)
wherein the client token is transmitted to the merchant device with a postback identifier using the secured post channel ([0039] “…The XML structure includes: <invitation_request> <timestamp>2011-02-22 15:22:43</timestamp><user_ID> john.q.public@gmail.com</user_ID>…<merchant_params><merchant_id>3FBCR4INC</merchant_id>…<merchant_auth_key>1NNF484MCP59CHB27365</merchant_auth_key> … the token server may provide a HTTP(S) POST message including XML data representative of the tokenization input form 420…”, [0040] “… The client may render, e.g., 421, the tokenization invitation and application form, and display, e.g., 422, the invitation and application form for the user…”)
wherein the activated modal is opened on the client device and the secure channel is established between the account security system and the client device subsequent to the client token as communicated to the client device from the merchant device ([0039] “… In some implementations, the token server may parse the invitation request message, and extract details of the user and client from the message. The token server may generate, e.g., 419, a tokenization invitation and an application form for the user to complete … The token server may provide, e.g., 420, the tokenization invitation and the application form to the client…”, [0161] “…in some implementations, the PPT controller may be executing a PHP script implementing a Secure Sockets Layer (“SSL”) socket server via the information server, which listens to incoming communications on a server port to which a client may send data…”)
33. As per claim 11:
Oborne discloses the following limitations:
facilitating the purchase transaction by sharing the tokenized account number with the system to allow the merchant system to settle payment for the purchase transaction with the system without the merchant system having access to client information ([0028] “In some implementations, the user may select to conduct the transaction using a one-time token, e.g., an anonymized credit card number…the PPT may utilize a tokenized and anonymized set of card details…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…”, [0050] “…In some implementations, the client may generate a tokenized purchase order message, e.g., 612, and provide, e.g., 613, the tokenized purchase order message to the merchant server…”, [0052] “… The merchant server may generate a token arbitration request, e.g., 617, and provide the token arbitration request, e.g., 618, to a token server…”, [0057] “…the token server may provide the token data, issuer data, and/or user payment options input, e.g., 634, to a pay network server…”, [0068] “… the merchant server may process the transaction as a normal card-based transaction, and bypass the token interpretation process…”)
34. As per claims 14 and 20:
Oborne discloses the following limitations:
processing client information to confirm that the client information is from a secure client device ([0026] “…As another example, device fingerprinting may be utilized. For example, a client device of a user may be a device that is used exclusively by the user, such as a smartphone, tablet computer, laptop computer, and/or the like. In some implementations, a custom hardware authentication chip, e.g., 103, may be disposed in communication with the client. In various implementations, the chip may be embedded into the client, come pre-installed in the client, attached as a periphery to the client, and/or the like. In some implementations, the user may perform an authentication procedure with the client and a user's card linked to the user's payment token…”)
35. As per claim 15:
Oborne discloses the following limitations:
opening a secure channel with the client device prior to receipt of the client token, wherein the client token is received from the client device via the activated modal on the client device using the secure channel ([0030] “…In some implementations, the app executing on the user's device may provide a “VerifyChat” feature for fraud prevention … the PPT may initiate a video challenge for the user, e.g., 301. For example, the user may need to present him/her-self via a video chat, e.g., 302…”, [0040] “… the user … may provide token creation input to complete the application form, e.g., 423. The client may generate a competed application form, and provide, e.g., 424, the token application to the token server…”, [0161] “…the PPT controller may be executing a PHP script implementing a Secure Sockets Layer (“SSL”) socket server via the information server, which listens to incoming communications on a server port to which a client may send data, e.g., data encoded in JSON format…”)
receiving a request for the tokenized account number from a merchant device, wherein the request is generated by the merchant device subsequent to closure of the modal on the client device, and wherein the tokenized account number is transmitted to the merchant device subsequent to the request, wherein the checkout communication is received as using a secured post channel ([0030] “…In some implementations, the user may not have initiated the transaction, e.g., the transaction is fraudulent. In such implementations, the user may cancel, e.g., 305, the challenge. The PPT may then cancel the transaction…”, [0036] “…For example, a browser application executing on the client may provide, on behalf of the user, a (Secure) Hypertext Transfer Protocol (“HTTP(S)”) GET message including the product order details for the merchant server…Below is an example HTTP(S) GET message including an XML-formatted purchase order message…”, [0052] “…The merchant server may generate a token arbitration request, e.g., 617, and provide the token arbitration request, e.g., 618, to a token server…”, [0063] “… In some implementations, the pay network server may forward an authorization success message, e.g., 646, to the token server, which may in turn forward the authorization success message, e.g., 647, to the merchant server…”)
wherein the client token is transmitted to the merchant device with a postback identifier using the secured post channel ([0039] “…The XML structure includes: <invitation_request> <timestamp>2011-02-22 15:22:43</timestamp><user_ID> john.q.public@gmail.com</user_ID>…<merchant_params><merchant_id>3FBCR4INC</merchant_id>…<merchant_auth_key>1NNF484MCP59CHB27365</merchant_auth_key> … the token server may provide a HTTP(S) POST message including XML data representative of the tokenization input form 420…”, [0040] “… The client may render, e.g., 421, the tokenization invitation and application form, and display, e.g., 422, the invitation and application form for the user…”)
wherein the modal is opened on the client device and the secure channel is established between the account security system and the client device subsequent to the client token as communicated to the client device from the merchant device ([0039] “… In some implementations, the token server may parse the invitation request message, and extract details of the user and client from the message. The token server may generate, e.g., 419, a tokenization invitation and an application form for the user to complete … The token server may provide, e.g., 420, the tokenization invitation and the application form to the client…”, [0161] “…in some implementations, the PPT controller may be executing a PHP script implementing a Secure Sockets Layer (“SSL”) socket server via the information server, which listens to incoming communications on a server port to which a client may send data…”)
36. As per claim 17:
Oborne discloses the following limitations:
wherein the merchant system authorizes payment with a system independent of the account security system as part of the purchase transaction ([0037] “In some implementations, the merchant server may obtain the purchase order message from the client, and may parse the purchase order message to extract details of the purchase order from the user. Based on the parsing, the merchant server may determine that the purchase order message is not tokenized, e.g., 414…”, [0053] “In various implementations, the token server may be part of the merchant system (e.g., a merchant process), or part of the payment network (e.g., a pay network server), or an independent server operating in conjunction with the merchant, issuer, acquirer and payment network…”, [0063] “…The merchant may obtain the authorization message, and determine from it that the user possesses sufficient funds in the card account to conduct the transaction. The merchant server may add a record of the transaction for the user to a batch of transaction data relating to authorized transactions…”)
wherein when executed by the processor, the instructions further cause the processor to perform operations for facilitating the purchase transaction by sharing the tokenized account number with the system to allow the merchant system to settle payment for the purchase transaction with the system without the merchant system having access to client information ([0028] “In some implementations, the user may select to conduct the transaction using a one-time token, e.g., an anonymized credit card number…the PPT may utilize a tokenized and anonymized set of card details…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…”, [0050] “…In some implementations, the client may generate a tokenized purchase order message, e.g., 612, and provide, e.g., 613, the tokenized purchase order message to the merchant server…”, [0052] “… The merchant server may generate a token arbitration request, e.g., 617, and provide the token arbitration request, e.g., 618, to a token server…”, [0057] “…the token server may provide the token data, issuer data, and/or user payment options input, e.g., 634, to a pay network server…”, [0068] “… the merchant server may process the transaction as a normal card-based transaction, and bypass the token interpretation process…”)
37. As per claim 21:
Oborne discloses the following limitations:
wherein the client token is used to verify the merchant system at the client device, and wherein verification includes using a communication channel and the activated modal to verify the merchant system at the client device ([0030] “… In some implementations, the app executing on the user's device may provide a “VerifyChat” feature for fraud prevention … In various implementations, the PPT may send electronic mail message, text (SMS) messages, Facebook® messages, Twitter™ tweets, text chat, voice chat, video chat (e.g., Apple FaceTime), and/or the like to communicate with the user…”, [0038] “… For example, the merchant server may provide a HTTP(S) POST message including the tokenization invitation request…”, [0039] “… <merchant_params><merchant_id>3FBCR4INC</merchant_id><merchant_name>Books & Things, Inc.</merchant_name> <merchant_auth_key>1NNF484MCP59CHB27365 </merchant_auth_key>… The token server may generate, e.g., 419, a tokenization invitation and an application form for the user to complete to sign up for tokenization services. The token server may provide, e.g., 420, the tokenization invitation and the application form to the client…”, [0040] “…The client may render, e.g., 421, the tokenization invitation and application form, and display, e.g., 422, the invitation and application form for the user…”, [0054] “…In some implementations, the token server may determine whether the user token is authenticated, e.g., 621. For example, if no XML data is available associated with the payment token, the token server may determine that the user has not signed up for payment tokenization services…”)
Conclusion
38. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20170262832A1 – Deshpande et al. – Discloses systems and methods for use in facilitating payment account transactions, through consumer communication devices, at merchant locations, wherein a merchant indicator for a merchant in connection with a payment account transaction at the merchant for at least one product and receiving a checkout token for the payment account transaction from a person-to-merchant engine.
US20180293573A1 – Ortiz et al. – Discloses systems, methods, and machine-executable data structures for the processing of data for the secure creation, administration, manipulation, processing, and storage of electronic data useful in the processing of electronic payment transactions.
US20150206137A1 – Mazarim Fernandes – Discloses a transaction system for avoiding the storage of any single information item that can be used to provide access to sensitive information wherein to gain access to the sensitive information, information elements from at least two different databases must be provided, none of the information elements being sufficient to gain access to the sensitive information.
US11461766B1 – Kurani et al. – Discloses a mobile wallet computer server wherein the fund access request is made in connection with a payment transaction and the mobile wallet server generates a tokenized card number, transmits the tokenized card number to the user device, and receives the tokenized card number from a card network computer system after having been routed from the user device via a merchant computer system and via an acquirer processor computer system.
39. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
40. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692