DETAILED ACTION
Examiner's Note: The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
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 .
Response to Arguments
Applicant’s remarks filed on 01/22/2026 have been considered.
Regarding claim[s] 21 – 40, under the obviousness rejection, applicant’s remarks are not persuasive, such remarks will be answered by the examiner in the office action below.
The examiner will respond to all other remarks that do not concern the prior art rejections, if any, in the office action below.
Applicant states on page[s] 11 of the remarks as filed: “Applicant respectfully disagrees with the characterizations of the claims made in the Office Action. Applicant further submits that the cited references fail to disclose or suggest each and every element of the rejected claims. (See M.P.E.P. § 2143.03).
Nevertheless, to facilitate prosecution and without acquiescing to the rejection, Applicant has amended claims 21-40. For example, amended independent claim 21 recites, inter alia:
receiving, by a transaction processor server and from a third-party data service server, a request for a low-value token, the request comprising a high-value token and a set of sensitive data associated with a user;
in response to receiving the request, providing, by the transaction processor server, the low-value token to the third-party data service server, wherein the low-value token is associated with the set of sensitive data associated with the user;
receiving, by the transaction processor server and from the third-party data service server, a request for the set of sensitive data, the request comprising the low-value token;
de-tokenizing, by the transaction processor server, the low-value token to obtain the set of sensitive data;
providing, by the transaction processor server, the set of sensitive data to the third-party data service server;
receiving, by the transaction processor server and from the third-party data service server, the low-value token and a transaction authorization request;
determining, by the transaction processor server, an authorization response based on the low-value token and authorization request; and
providing, by the transaction processor server, the authorization response to the third-party data service server. (Emphasis added).
Applicant respectfully requests reconsideration of the rejection of the claims under 35 U.S.C. § 103 in light of the amendments.”
In response, the examiner isn’t persuaded, the examiner points to the prior art combination of prior art of: Gaddam 9391 and Gaddam 8550. The prior art does teach the applicant’s bolded claim limitations in the following manner:
Applicant’s claim 1, and associated argued claim limitations:
receiving, by a transaction processor server and from a third-party data service server, a request for a low-value token, the request comprising a high-value token and a set of sensitive data associated with a user [Gaddam 9391, Figure # 3, and paragraph: 0057, FIG. 3 is a flow diagram of a method for implementing a low value token buffer in a transaction processing network according to embodiments of the present invention. At step S301, a user device 110 [i.e. applicant’s user] initiates a transaction with access device 120 by providing a high value token for a payment, for example. At step S302, access device 120 may provide the transaction data [i.e. applicant’s set of sensitive data] and the high value token [i.e. applicant’s high value token] to the resource provider computer 130 [i.e. applicant’s third-party data service], or may generate an authorization request message using the high value token and the transaction data and send the authorization request message to the resource provider computer 130. At step S304, the resource provider computer 130 receives the authorization request message containing the high value token (or generates it if it was not previously generated by the access device 120), and forwards the authorization request message [i.e. applicant’s request for low-value token] containing the high value token to a transport computer 140. At step S305, the transport computer 140 determines the relevant transaction processing network and/or the relevant token server (i.e., low value token server 151), and forwards the authorization request message containing the high value token to the low value token server 151 [i.e. applicant’s…transaction processor server].
Then further of Figure # 3, and paragraph: 0058, At step S310, the low value token server 151 [i.e. applicant’s…transaction processor server] receives the high value token and determines a low value token that is associated with the high value token. The low value token server 151 may determine a low value token through any suitable method. For example, the low value token server 151 may search a database for a low value token that has already been associated with the high value token, may generate a random low value token and associate the low value token with the high value token, may generate a low value token by applying a low value tokenization algorithm to the high value token, and/or may perform any number of additional methods of determining a low value token to associate with the high value tokens.];
in response to receiving the request, providing, by the transaction processor server, the low-value token to the third-party data service server, wherein the low-value token is associated with the set of sensitive data associated with the user [Gaddam 8850, paragraph: 0059, lines 1 – 6, For example, an authorizing entity might issue a payment account that is identified by a PAN [i.e. applicant’s…in response to receiving]. The authorizing entity might want to provision a payment token [i.e. applicant’s low value token] associated with the PAN to a merchant [i.e. applicant’s third-party data service server], mobile device, digital wallet provider, or any other suitable entity];
---------
de-tokenizing, by the transaction processor server, the low-value token to obtain the set of sensitive data [Gaddam 8550, paragraph: 0022, In some embodiments, a credential requestor, such as a merchant, can obtain a tokenization certificate from a certificate authority. The tokenization certificate can indicate whether the credential requestor is authorized to de-tokenize tokens (and receive associated credentials), and can serve to validate the identity of the credential requestor. Thus, a token provider can be confident that an incoming credential request is from a legitimate credential requestor.];
providing, by the transaction processor server, the set of sensitive data to the third-party data service server [Gaddam 8550, paragraph: 0046, lines 1 – 4, A mobile device may also include any suitable device that may be used to conduct a financial transaction, such as to provide payment credentials to a merchant.];
***The examiner’s response above applies to the same or similar claim limitations made on page[s] 12 of the remarks as filed.
Applicant states on page[s] 13 of the remarks as filed: “In the Office Action, claims 21-40 are rejected on the ground of non-statutory double patenting as allegedly unpatentable over one or more claims of U.S. Patent No. 12, 052,252 and U.S. Patent No. 11,777,937. (Office Action at pgs. 7-8). Although Applicant does not necessarily agree with this double patenting rejection, to obviate this rejection and to expedite prosecution and allowance of this application, Applicant files herewith a Terminal Disclaimer.”
In response, the examiner isn’t persuaded, the examiner points out that applicant has not filed a terminal disclaimer to overcome the issued non – statutory obvious type double patent rejection. Therefore, the rejection is maintained at this time.
Applicant states on page[s] 14 of the remarks as filed: “Further, in the Office Action, claims 21-40 are rejected under non-statutory double patenting as allegedly unpatentable over one or more claims of U.S. Patent No. 12,299,660 and U.S. Patent No. 11,100,486. (Office Action at pgs. 6-7). Applicant requests reconsideration of this double patenting rejection. Neither U.S. Patent No. 12,299,660 nor U.S. Patent No. 11,100,486 discloses or suggests, inter alia:
receiving, by a transaction processor server and from a third-party data service server, a request for a low-value token, the request comprising a high- value token and a set of sensitive data associated with a user;
in response to receiving the request, providing, by the transaction processor server, the low-value token to the third-party data service server, wherein the low- value token is associated with the set of sensitive data associated with the user;
receiving, by the transaction processor server and from the third-party data service server, a request for the set of sensitive data, the request comprising the low-value token;
de-tokenizing, by the transaction processor server, the low-value token to obtain the set of sensitive data; providing, by the transaction processor server, the set of sensitive data to the third-party data service server;
receiving, by the transaction processor server and from the third-party data service server, the low-value token and a transaction authorization request; determining, by the transaction processor server, an authorization response based on the low-value token and authorization request; and
providing, by the transaction processor server, the authorization response to the third-party data service server.
as recited in independent claim 21.
For at least this reason, Applicant requests that this double patenting rejection be withdrawn.”
In response, the examiner isn’t persuaded, the examiner points out that applicant’s claim amendments do make the claims distinct or dissimilar from the reference patent based on the subject matter of the pending application and the patent – still overlap in using high and low value tokens to protect sensitive data during transations.
Applicant states on page[s] 14 and 15 of the remarks as filed: “Still further, with regard to the provisional, non-statutory double patenting
rejection of claims 21-40 over U.S. Application No. 18/496,376, Applicant does not necessarily agree with the Examiner's characterizations concerning the claims set forth in this application, as well as those set forth in the 18/496,376 application. Furthermore, since none of the allegedly conflicting claims have issued, no action need be taken by Applicant at this time because it is unknown whether the claims in the 18/496,376 application will even issue in their current form. Therefore, no Terminal Disclaimer is needed at this time with respect to these provisional double patenting rejections.”
In response, the examiner isn’t persuaded, the examiner points to MPEP 804. Specifically, the doctrine of double patenting seeks to prevent the unjustified extension of patent exclusivity beyond the term of a patent. The public policy behind this doctrine is that:
The public should . . . be able to act on the assumption that upon the expiration of the patent it will be free to use not only the invention claimed in the patent but also modifications or variants which would have been obvious to those of ordinary skill in the art at the time the invention was made, taking into account the skill in the art and prior art other than the invention claimed in the issued patent.
PNG
media_image1.png
18
19
media_image1.png
Greyscale
In re Zickendraht, 319 F.2d 225, 232, 138 USPQ 22, 27 (CCPA 1963) (Rich, J., concurring). Double patenting results when the right to exclude granted in one patent is unjustly extended by the grant of another patent or patents. In re Van Ornum, 686 F.2d 937, 943-44, 214 USPQ 761, 766-67 (CCPA 1982).
Response to Amendment
Status of the instant application:
Claim[s] 21 – 40 are pending in the instant application.
Regarding claim[s] 21 – 40, under the obviousness rejection, applicant’s claim amendments have been considered, however, they are not persuasive. The examiner has addressed such claim amendments in the office action below.
Regarding claim[s] 21 – 40, under the indefiniteness rejection, applicant’s claim amendments have been considered, therefore, the rejections are withdrawn.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based e-Terminal Disclaimer may be filled out completely online using web-screens. An e-Terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about e-Terminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim[s] 21 – 40 are rejected on the ground of non - statutory double patenting as being unpatentable over claim[s] 21 - 40 of U.S. Patent No. 11100486.
Although the claims at issue are not identical, they are not patentably distinct from each other because the subject matter of the pending application and the reference patent are the same or similar in scope and are not distinct in the following manner:
enabling transaction processor server interoperability, comprising receiving, from an transaction processor server, a request for a low-value token, the low-value token being associated with a subset of sensitive data associated with a user; providing the low-value token to the electronic data server; receiving a request for the subset of sensitive data, from a third-party data service server, the request comprising the low-value token.
Claim[s] 21 – 40 are rejected on the ground of non - statutory double patenting as being unpatentable over claim[s] 21 – 37, 39 - 40 of U.S. Patent No. 12299660.
Although the claims at issue are not identical, they are not patentably distinct from each other because the subject matter of the pending application and the reference patent are the same or similar in scope and are not distinct in the following manner:
enabling merchant system, comprising receiving, by an transaction processing server, a request for a low-value token, the low-value token being associated with a subset of sensitive data associated with a user; providing the low-value token to the electronic data server; receiving a request for the subset of sensitive data, from a third-party data service server, the request comprising the low-value token; de-tokenizing the low-value token to obtain the subset of sensitive data; providing the subset of sensitive data to the third- party data service server; receiving, from an electronic data server, the low-value token and a transaction authorization request; determining, based on the low-value token and authorization request, an authorization response; and providing the authorization response to the electronic data server.
Claim[s] 21 – 40 are rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 21 - 40 of U.S. Patent No. 11777937.
Although the claims at issue are not identical, they are not patentably distinct from each other because the subject matter of the pending application and the reference patent are the same or similar in scope and are not distinct in the following manner:
enabling third-party data service interoperability, comprising receiving, from an transaction processor server, a request for a low-value token, the low-value token being associated with a subset of sensitive data associated with a user; providing the low-value token to the electronic data server; receiving a request for the subset of sensitive data, from a third-party data service server, the request comprising the low-value token; de-tokenizing the low-value token to obtain the subset of sensitive data; providing the subset of sensitive data to the third- party data service server; receiving, from an electronic data server, the low-value token and a transaction authorization request; determining, based on the low-value token and authorization request, an authorization response; and providing the authorization response to the electronic data server.
Claim[s] 21 – 40 are rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 21 - 40 of U.S. Patent No. 12052252.
Although the claims at issue are not identical, they are not patentably distinct from each other because enabling third-party data service interoperability, comprising receiving, from an transaction processor server, a request for a low-value token, the low-value token being associated with a subset of sensitive data associated with a user; providing the low-value token to the electronic data server; receiving a request for the subset of sensitive data, from a third-party data service server, the request comprising the low-value token; de-tokenizing the low-value token to obtain the subset of sensitive data.
Claim[s] 1 – 20 are provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 21 - 40 of co-pending Application No. 18496376(reference application).
Although the claims at issue are not identical, they are not patentably distinct from each other because the subject matter of the pending application and the reference patent are the same or similar in scope and are not distinct in the following manner:
enabling third-party data service interoperability, comprising receiving, from an transaction processor server, a request for a low-value token, the low-value token being associated with a subset of sensitive data associated with a user; providing the low-value token to the electronic data server; receiving a request for the subset of sensitive data, from a third-party data service server, the request comprising the low-value token.
This is a provisional non-statutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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 (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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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 non-obviousness.
Claim(s) 21 – 23, 25 – 30, 32 – 37, 39, 40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gaddam et al. [US PGPUB # 2016/0269391], hereinafter Gaddam 9391 in view of Gaddam et al. [US PGPUB # 2016/0028550], hereinafter Gaddam 8550.
As per claim 21. Gaddam 9391 does teach a method for maintaining electronic transaction data security with a third-party service [paragraph: 0006, Embodiments are directed to providing an interchanging tokenization scheme that can provide a low value token buffer (i.e., a buffer that uses tokens that are not directly capable of being used to initiate transactions and/or are not directly tied to real credentials) within an organization to reduce access to high value tokens (i.e., tokens that are directly tied to real credentials and/or that can be used to initiate or conduct transactions) within the organization.], comprising:
receiving, by a transaction processor server and from a third-party data service server, a request for a low-value token, the request comprising a high-value token and a set of sensitive data associated with a user [Figure # 3, and paragraph: 0057, FIG. 3 is a flow diagram of a method for implementing a low value token buffer in a transaction processing network according to embodiments of the present invention. At step S301, a user device 110 [i.e. applicant’s user] initiates a transaction with access device 120 by providing a high value token for a payment, for example. At step S302, access device 120 may provide the transaction data [i.e. applicant’s set of sensitive data] and the high value token [i.e. applicant’s high value token] to the resource provider computer 130 [i.e. applicant’s third-party data service], or may generate an authorization request message using the high value token and the transaction data and send the authorization request message to the resource provider computer 130. At step S304, the resource provider computer 130 receives the authorization request message containing the high value token (or generates it if it was not previously generated by the access device 120), and forwards the authorization request message [i.e. applicant’s request for low-value token] containing the high value token to a transport computer 140. At step S305, the transport computer 140 determines the relevant transaction processing network and/or the relevant token server (i.e., low value token server 151), and forwards the authorization request message containing the high value token to the low value token server 151 [i.e. applicant’s…transaction processor server].
Then further of Figure # 3, and paragraph: 0058, At step S310, the low value token server 151 [i.e. applicant’s…transaction processor server] receives the high value token and determines a low value token that is associated with the high value token. The low value token server 151 may determine a low value token through any suitable method. For example, the low value token server 151 may search a database for a low value token that has already been associated with the high value token, may generate a random low value token and associate the low value token with the high value token, may generate a low value token by applying a low value tokenization algorithm to the high value token, and/or may perform any number of additional methods of determining a low value token to associate with the high value tokens.];
determining, by the transaction processor server, an authorization response based on the low-value token and authorization request [paragraph: 0062, The transaction processing computer 152 receives the result of the various application processes and continues processing the transaction. The application processing responses include the low value token 220 and do not include the associated high value token or the associated real credentials.]; and
providing, by the transaction processor server, the authorization response to the third-party data service server [paragraph: 0062, The transaction processing computer 152 may send the authorization request message including the low value token and the results of the application processes completed in step S320 to a high value token server 156 at step S325 that may be configured to exchange the low value token for the real credentials. In some embodiments, instead of using the low value token to real credential mapping, the system may exchange the low value token for a high value token and then exchange the high value token for real credentials.].
Gaddam 9391 does not teach clearly the claim limitation of:
“in response to the receiving, providing, by the transaction processor server, the low-value token to the third-party data service server, wherein the low-value token is associated with the set of sensitive data associated with the user;”
“receiving, by the transaction processor server and from the third-party data service server, a request for the set of sensitive data, the request comprising the low-value token;”
“de-tokenizing, by the transaction processor server, the low-value token to obtain the set of sensitive data;”
“providing, by the transaction processor server, the set of sensitive data to the third-party data service server.”
“receiving, by the transaction processor server and from the third-party data service server, the low-value token and a transaction authorization request.”
However, Gaddam 8550 does teach the claim limitation of:
“in response to the receiving, providing, by the transaction processor server, the low-value token to the third-party data service server, wherein the low-value token is associated with the set of sensitive data associated with the user [paragraph: 0059, lines 1 – 6, For example, an authorizing entity might issue a payment account that is identified by a PAN [i.e. applicant’s…in response to receiving]. The authorizing entity might want to provision a payment token [i.e. applicant’s low value token] associated with the PAN to a merchant [i.e. applicant’s third-party data service server], mobile device, digital wallet provider, or any other suitable entity];”
“receiving, by the transaction processor server and from the third-party data service server, a request for the set of sensitive data, the request comprising the low-value token [paragraph: 0091, The credential request module 130L may comprise code that causes the processor 130A to request sensitive information. For example, the credential request module 130L may contain logic that causes the processor 130A to generate a credential request message including a payment token [i.e. applicant’s low – value token] and a tokenization certificate, and to send the request to any suitable entity, such as a token provider computer. The credential request module 130L may also be able to receive a credential response message including a PAN, and store the PAN along with an associated payment token in the credential database 130D.];”
“de-tokenizing, by the transaction processor server, the low-value token to obtain the set of sensitive data [paragraph: 0022, In some embodiments, a credential requestor, such as a merchant, can obtain a tokenization certificate from a certificate authority. The tokenization certificate can indicate whether the credential requestor is authorized to de-tokenize tokens (and receive associated credentials), and can serve to validate the identity of the credential requestor. Thus, a token provider can be confident that an incoming credential request is from a legitimate credential requestor.];”
“providing, by the transaction processor server, the set of sensitive data to the third-party data service server [paragraph: 0046, lines 1 – 4, A mobile device may also include any suitable device that may be used to conduct a financial transaction, such as to provide payment credentials to a merchant.].”
“receiving, by the transaction processor server and from the third-party data service server, the low-value token and a transaction authorization request [paragraph: 0060, When a transaction is being processed in such a situation, the merchant [i.e. applicant’s third-party data service server] may send an authorization request message [i.e. applicant’s transaction authorization request] including the third payment token [i.e. applicant’s low-value token] to the acquirer. The acquirer may de-tokenize by replacing the third payment token with the second payment token, and then forward the authorization request message with the second payment token to the transaction processing network. In such a manner, each token layer can be de-tokenized until the authorization request reaches the authorizing entity, which can then authorize the transaction based on the actual PAN.].”
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Gaddam 9391 and Gaddam 8550 in order for the securing of transactions with use of a low value token and high value token stored in a relation database of transaction processing system of Gaddam 9391 to include encrypting the relationships between the low value and high value tokens of Gaddam 8550. This would allow for the prevention of compromise of the credentials to linked to the low and high value tokens while stored. See paragraph: 0067 of Gaddam 8550.
As per claim 22. Gaddam 9391 does teach the method of claim 21, further comprising:
receiving, from the third-party data service server, third-party data security service data [Gaddam 9391, Figure # 3, and paragraph: 0057, lines 11 – 21, At step S304, the resource provider computer 130 [i.e. applicant’s third-party data service] receives the authorization request message containing the high value token (or generates it if it was not previously generated by the access device 120), and forwards the authorization request message containing the high value token [i.e. applicants third-party data service] to a transport computer 140. At step S305, the transport computer 140 determines the relevant transaction processing network and/or the relevant token server (i.e., low value token server 151), and forwards the authorization request message containing the high value token to the low value token server 151.]; and
determining the authorization response based on the low-value token, the authorization request, and the third-party data security service data [Gaddam 9391, paragraph: 0047, lines 5 – 14, When a transaction involves a payment account associated with the authorizing entity computer 160, the authorizing entity computer 160 may verify the account and respond with an authorization response message to the transaction processing network 150. Transaction processing network 150 may perform the reverse functions when receiving the authorization response message from the authorizing entity computer 160 (i.e., convert the real credential into a low value token, convert the low value token into a high value token). The authorization response message including the high value token can be provided to the transport computer 140, which forwards it to the resource provider computer 130, which may forward it to the access device 120.].
As per claim 23. Gaddam 9391 does teach the method of claim 21, wherein the authorization response is provided with the high-value token, the high-value token being associated with the set of sensitive data associated with the user and being usable by the third – party data service server to execute subsequent electronic transactions [Gaddam 9391, paragraph: 0079, lines 5 – 12, At step S550, the low value and high value token server 158 may obtain the high value token associated with the real credentials, and update the authorization response message to include the high value token instead of the real credentials. At step S570, the low value and high value token server 158 may send the response including the high value token to the transport computer 140. The transport computer 140 may forward the authorization response message to the resource provider computer 130 [i.e. applicant’s third – party data service server] at step S571. At step S573, the response may be provided to the access device 120, which may, in some embodiments, provide the user with an indication of whether or not the transaction was authorized.].
As per claim 25. Gaddam 9391 does teach the method of claim 21, wherein the low-value token is a limited- use token configured to obtain a subset of the set of sensitive data associated with the user [Gaddam 9391, paragraph: 0085, lines 12 – 16, In some embodiments, token generation module 612 may generate a response with the requested token or requested sensitive information, a token expiration date associated with the token, and/or a token assurance level associated with the token.].
As per claim 26. Gaddam 9391 as modified does teach the method of claim 21, wherein the third-party data service server performs a fraud check based on the set of the sensitive data associated with the user [Gaddam 8550, paragraph: 0173, Having received the payment credentials, the merchant computer 830 [i.e. applicant’s third-party data service server] can proceed to carry out a number of operations that involve the payment credentials. For example, the merchant computer 830 may use the payment credentials to track user activity (e.g., via the consumer analysis module 130M). The merchant computer 830 can also use the payment token to perform fraud risk analysis (e.g., check a blacklist and determine transaction velocity), process loyalty-related services, process returns, and perform any other suitable operations.].
As per claim 27. Gaddam 9391 does teach the method of claim 21, wherein the set of the sensitive data associated with the user comprises social security data, account data, credit card data, or a personal account number (PAN) [Gaddam 9391, paragraph: 0003, primary account number, credit card number].
As per system claim 28 that includes the same or similar claim limitations as method claim 21, and is similarly rejected.
**The examiner notes that applicant’s recited: “data storage device storing instructions,” “one or more processors,” and “instructions,” is taught by the prior art of Gaddam 9391 at paragraph: 0096 – 0098.
As per system claim 29 that includes the same or similar claim limitations as method claim 22, and is similarly rejected.
As per system claim 30 that includes the same or similar claim limitations as method claim 23, and is similarly rejected.
As per system claim 32 that includes the same or similar claim limitations as method claim 25, and is similarly rejected.
As per system claim 33 that includes the same or similar claim limitations as method claim 26, and is similarly rejected.
As per system claim 34 that includes the same or similar claim limitations as method claim 27, and is similarly rejected.
As per non – transitory computer-readable medium claim 35 that includes the same or similar claim limitations as method claim 21, and is similarly rejected.
As per non – transitory computer-readable medium claim 36 that includes the same or similar claim limitations as method claim 22, and is similarly rejected.
As per non – transitory computer-readable medium claim 37 that includes the same or similar claim limitations as method claim 23, and is similarly rejected.
As per non – transitory computer-readable medium claim 39 that includes the same or similar claim limitations as method claim 25, and is similarly rejected.
As per non – transitory computer-readable medium claim 40 that includes the same or similar claim limitations as method claim 26, and is similarly rejected.
Claim(s) 24, 31, 38 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gaddam et al. [US PGPUB # 2016/0269391], hereinafter Gaddam 9391 in view of Gaddam et al. [US PGPUB # 2016/0028550], hereinafter Gaddam 8550 as applied to claim[s] 22 above, and further in view of Hammad et al. [US PGPUB # 2011/0119155]
As per claim 24. Gaddam 9391 and Gaddam 8850 do teach what is taught in the rejection of claim 22 above.
Gaddam 9391 and Gaddam 8550 do not clearly teach the method of claim 21, wherein the third-party data security service data is 3-D Secure response data.
However, Hammad does teach the method of claim 22, wherein the third-party data security service data is 3-D Secure response data [paragraph: 0105, lines 1 – 14, Validation entity 80 can process identification information transmitted from a plurality of different verification tokens 40 (e.g., millions of tokens), and can process any number of transmissions by a particular token 40. Validation entity 80 applies one or more validation tests to verification token 40 and/or the identification information to obtain a level of confidence that the portable consumer device 5 was actually presented to verification token 40 to request 3-D Secure datum and optionally the dCVV2 value. When the one or more validation tests are passed, and preferably when none of the tests are failed, validation entity 80 sends a 3-D secure participation indication and 3-D secure datum to verification token 40, and optionally a dCVV2 value token 40 and payment processing network 70 along with the account number present in the identification].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Gaddam 9391 and Hammad in order for the securing of transactions with use of a low value token and high value token stored in a relation database of transaction processing system of Gaddam 9391 to include encrypting the relationships between the low value and high value tokens of Hammad. This would allow for the prevention of compromise of the credentials to linked to the low and high value tokens while stored. See paragraph: 0106 of Hammad.
As per system claim 31 that includes the same or similar claim limitations as method claim 24, and is similarly rejected.
As per non – transitory computer-readable medium claim 38 that includes the same or similar claim limitations as method claim 24, and is similarly rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Grassadionia et al. [US PAT # 12277556], who does teach a payment service system-implemented method of assigning payment card numbers for individual user accounts associated with the payment service system includes receiving payment card numbers activated by a third-party server that are unassigned to accounts registered. The method includes receiving a first transaction authorization request for one of the payment card numbers and denying the request, without notifying the third-party server, based on the number being unregistered with the payment service system. The method includes receiving, via an executable application, a request to register a user account for a payment service system user, and in response, generating a record assigning the payment card number to the user account. The method includes receiving a second transaction authorization request for the payment card number, authorizing the request based on the number being assigned to the user account, and notifying the third-party server, causing user account's balance to be modified.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANT SHAIFER - HARRIMAN whose telephone number is (571)272-7910. The examiner can normally be reached M - F: 9am to 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, Kambiz Zand can be reached at 571- 272- 3811. 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.
/DANT B SHAIFER HARRIMAN/ Primary Examiner, Art Unit 2434