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 .
DETAILED ACTION
Status of the Claims
Claims 1-20 are cancelled
Claims 21-40 are pending
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 21-40 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.
The terms “low value” and “high value“ in independent claims 21,28,35 is a relative term which renders the claim indefinite. The term “low value” and “high value“ is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Applicant’s dependent claims are rejected for similar reasons.
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 21-40 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. Regarding independent claims 21,28,35 the claimed invention is directed to an abstract idea without significantly more. The claims recites the abstract idea of authorizing a transaction which is a mental process. Other than reciting a server nothing in the claims precludes the steps from being performed mentally. But for the server the limitations on receiving sensitive data from a user, receiving low value token from third party, providing sensitive data to third party, receiving authorization request from merchant, providing authorization response to merchant is a process that under its broadest reasonable interpretation could be performed by mentally but for the recitation of generic computer elements. If claim limitations, under the broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Further the above limitations related to authorizing a transaction stripped of the identified additional and insignificant elements could also be considered a “Method of Organizing Human Activity” relating to the managing human behavior and interactions (fundamental economic activity). Thus, the claims recite an abstract idea.
The judicial exception is not integrated into a practical application. The computers are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer components. The additional element(s) does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Simply implementing the abstract idea on a generic computer environment is not a practical application of the abstract idea and does not take the claim out of the mental process or method of organizing human activity grouping.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above, with respect to integration of the abstract idea into a practical application, the additional element of a server amounts to no more than mere instructions to apply the exception using a generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept Collecting, analyzing and displaying information, and receiving and transmitting over a network are conventional in the computing arts. (MPEP 2106.05h; See also MPEP 2106.05, Alice v. CLS, “. Nearly every computer will include a ‘communications controller’ and ‘data storage unit’ capable of performing the basic calculation, storage, and transmission functions required by the method claims.”). The claims are not patent eligible.
Regarding the dependent claims, these claims are directed to limitations which serve to limit the transaction authorizing steps. The subject matter of claims 22/29/36 (providing low value token to user, user provides low value token to third party), 23/30/37 (provide low value token directly to third party), 24/31/38 (validate third party based on low value token), 25/32/39 (authorization includes third party service data provided by third party), 26/33/40 (service data is 3D secure), 27/34 (determining sensitive data using detokenization) appear to add additional steps to the abstract idea, implemented by generic computers. These claims neither introduce a new abstract idea nor additional limitations which are significantly more than an abstract idea. They provide descriptive details that offer helpful context, but have no impact on statutory subject matter eligibility.
Therefore the limitations on the invention, when viewed individually and in ordered combination are directed to in-eligible subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21-40 are rejected under 35 U.S.C. 103 as being unpatentable over Powell 20150127547 in view of “MasterCard SecureCode Merchant Implementation Guide”, 7/2014, https://www.mastercard.us/content/dam/mccom/en-us/documents/SMI_Manual.pdf
Regarding Claim 21,
receiving, by a transaction processor, sensitive data from a user browser;
Powell is directed to an account tokenization system. (Powell, abstract). Powell discloses that a holder of a payment account number may request an access token from a payment system. (Powell, para0050, “During token requestor registration, the token service provider may formally process token requestor's application to participate in the token service system. The token service provider may collect information pertaining to the nature of the requestor and relevant use of tokens to validate and formally approve the token requestor and establish appropriate domain restriction controls. Successfully registered token requestors may be assigned a token requestor identifier that may also be entered and maintained within the token vault. Token requestors be revoked or assigned new token requestor identifiers. This information may be subject to reporting and audit by the token service provider.”; para 0113, “[0113] Upon receiving the token request message from the token requestor 114, the payment network 210 may generate a token for the PAN provided in the token request message. The payment network 210 may inquire about the type of ID&V performed to confirm whether the person conducting the transaction is the legitimate account holder. Based on the type of ID&V performed and information about the entity performing the ID&V, the payment network 210 may also generate a token assurance level associated with the generated token. The token assurance level may represent a level of trust in an association between the generated payment token and the PAN represented by the payment token. The payment network 210 may store the association between the PAN and the generated token along with the token assurance level and the data used to generate the token assurance level in the vault 218. The payment network 210 may provide the token to the token requestor 114 in a token request reply message.”). The token process may be performed via web browser. (Powell, para 0049, “[0049] "Token exchange" or "de-tokenization" is a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with a corresponding primary account number (PAN) that was associated with the payment token during tokenization of the PAN. Thus, the de-tokenization may refer to the process of redeeming a token for the associated PAN value based on a token-to-PAN mapping stored, for example, in a token vault. The ability to retrieve a PAN in exchange for the associated token may be restricted to specifically authorized entities, individuals, applications, or systems. Further, de-tokenization or token exchange may be applied to any other information. In some embodiments, token exchange may be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request).”)
receiving, by the transaction processor, an authorization request including the low-value token from a merchant system; and
(Powell, fig.3,element 310)
providing, by the transaction processor, an authorization response including a high-value token to the merchant system.
(Powell, para 0144-45, “The payment network 512 may generate a modified authorization response message 520 including data elements such as one or more of the token, the token assurance level, last 4 digits of PAN and PAN product ID. The payment network 512 may send the modified authorization response message 520 to the acquirer 508. The acquirer which may then pass an authorization response message 522 to the merchant terminal 504. The authorization response message 522 may include the same data fields as the modified authorization response message 520. The authorization response message 519 and the modified authorization response messages 520 and 522 may indicate whether the issuer 516 approved the transaction initiated by the account holder using the mobile device 502. After the authentication response message 522 is provided to the merchant terminal 504, the account holder may be notified of the success or failure of the transaction.”
Powell does not explicitly disclose
receiving, by the transaction processor, a low-value token associated with the sensitive data from a third-party service;
providing, by the transaction processor, the sensitive data to the third-party service;
However the limitation is obvious in view of Mastercard. Mastercard is directed to a manual for implementation of Mastercard security improvements to ecommerce transactions. (Mastercard, p.1-1; p.2-1, “All MasterCard® SecureCode™ solutions define and provide a base level of security around performing this authentication process. For this solution specifically, MasterCard is deploying its own implementation of 3-DSecure under the MasterCard SecureCode program branding for MasterCard® and Maestro®. This implementation of 3-D Secure includes support for the Secure Payment Application™(SPA) algorithm and Universal Cardholder Authentication Field™(UCAF) without any changes to the 3-D Secure specification, messages, or protocol.”). Mastercard discloses a user registers their account number with Mastercard. (Mastercard, F-1, “The merchant invites the customer to register on its website by choosing a username and password, or similar credentials acceptable to MasterCard, and must provide the customer with the option to register a MasterCard® or Maestro® card account number for use in future e-commerce transactions.”). Mastercard discloses that its implementation of 3D Secure adds a layer of cardholder authentication and additional information that must be provided to a merchant device to pass in a transaction authorization. (Mastercard, p.2-9, “After cardholder authentication is complete, the merchant is required to pass the corresponding SecurePaymentApplication™(SPA)Accountholder Authentication Value(AAV) to the acquirer via the UniversalCardholder AuthenticationField™(UCAF) within the authorization message. This value is then passed from the acquirer to the issuer as part of the authorization message.”). Although Mastercard is silent on the use of a tokenized account number, the examiner respectfully suggests that teaching is known based on Powell. That is, Powell discloses that a customer may obtain and use a token that obscures their true account number, and entities needing the true account number necessarily would need to perform a detokenization process. (Powell, figs. 3-8). Accordingly, if the 3D Secure system of Mastercard were to register an actual customer account number in the system, then a customer employing a tokenized account number would necessitate the system of Mastercard to consult a detokenizer to obtain the actual account number to perform its authentication process. The 3D secure server of Mastercard would need to forward the “low value” token proffered by the customer to obtain the actual account number from the detokenizer. Using the actual account number, 3D secure could authenticate the customer in the normal manner. It would have been obvious to one of ordinary skill in the before the filing date of the invention to combine Powell with the data of Mastercard with the motivation of adding security to transactions. (Mastercard, p.2-9)
Regarding Claim 22, Powell and Mastercard disclose the method of claim 21.
providing, by the transaction processor, the low-value token to the user browser,
See prior art rejection of claim 20 regarding Mastercard
wherein the user browser provides the low-value token to the third-party service.
(Mastercard, p.2-8, “SSL-1 The cardholder shops at the merchant and, when ready to checkout, enters the appropriate payment information—including the account number. SSL-2 The Merchant Plug-In queries the Directory to verify the enrollment status for a specific issuer using the verification request messages. SSL-3 If the directory indicates that an issuer is participating, then the directory must forward a request to the issuer’s Access Control Server to check the enrollment status of a specific cardholder. The configuration information in the Directory will indicate exactly which Access Control Server will perform the check. The resulting response will flow back over the same links to the Merchant Plug-In.”) It would have been obvious to one of ordinary skill in the before the filing date of the invention to combine Powell with the data of Mastercard with the motivation of adding security to transactions. (Mastercard, p.2-9)
Regarding Claim 23, Powell and Mastercard disclose the method of claim 21.
providing, by the transaction processor, the low-value token directly to the third- party service.
Powell discloses that a detokenizer may provide an actual account number in addition to the token that was detokenized. (Powell, para 0124, “The payment network 312 may then modify the authorization request message 314 to generate a modified authorization request message 318. In the modified authorization message, the token may be replaced with the PAN in data field F2; the token expiry date may be replaced with the PAN expiry date in data field F14; POS Entry Mode may be passed in data field F22; an indicator may be included in in data field F60.6 to convey to the issuer that an on-behalf-of validation has been completed by the token service provider of the token; a product ID may be passed in data field F62.23; and various token-related fields may be included. For example, the token-related fields may include the token passed in data field F123-DSI 68 Tag1, the token expiry date, the token assurance level passed in data field F123-DSI 68 Tag2, the token assurance data, and the token requestor ID passed in data field F123-DSI 68 Tag3. Upon generating the modified authorization request message 318, the payment network 312 may send the modified authorization request message 318 to the issuer 316.”)
Regarding Claim 24, Powell and Mastercard disclose the method of claim 21.
validating, by the transaction processor, the third-party service based on receiving the low-value token from the third-party service.
See prior art rejection of claim 21. The examiner interprets the detokenization process to be a validation of the payment token.
Regarding Claim 25, Powell and Mastercard disclose the method of claim 21.
wherein the authorization request includes third-party service data that is generated by the third-party service based on the sensitive data and that is provided to the merchant system by the third-party service.
See prior art rejection of claim 21 regarding Mastercard.
Regarding Claim 26, Powell and Mastercard disclose the method of claim 25.
wherein the third-party service data is 3-D Secure Data.
See prior art rejection of claim 21 regarding Mastercard.
Regarding Claim 27, Powell and Mastercard disclose the method of claim 21.
determining, by the transaction processor, the sensitive data using a de- tokenization procedure, based on receiving the low-value token from the third-party service.
See prior art rejection of claim 1 regarding Powell.
Regarding Claims 28-40,
See prior art rejections of claims 21-27,21-26
Conclusion
Relevant art not relied on but made of record include
Crowe, “Is Payment Tokenization Ready for Primetime?”, 2015, https://www.bostonfed.org/publications/payment-strategies/is-payment-tokenization-ready-for-primetime.aspx
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALLEN C CHEIN whose telephone number is (571)270-7985. The examiner can normally be reached Monday-Friday 8am -5pm.
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, Fahd Obeid can be reached on (571) 270-3324. 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.
/ALLEN C CHEIN/ Primary Examiner, Art Unit 3627