DETAILED ACTION
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 11/06/2025 have been fully considered.
Regarding claim[s] 1 – 11 under the various anticipatory and obviousness rejections, applicant’s remarks are not persuasive, therefore, see the examiner’s response to such remarks in the office action below.
Regarding claim[s] 12 – 20 under the various anticipatory and obviousness rejections, applicant’s remarks are moot because the new ground of rejection does not rely on all the reference[s] applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Therefore, see the office action below.
The examiner will address all other remarks that do not concern the prior art rejection, if any, in the office action below.
Applicant states on page[s] 6 of the remarks as filed: “Claims 1-11, 19, and 20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-11, 19, and 20 of U.S. Patent No. 10,200,407. Claims 1-10, and 12-20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-10 and 12-20 of U.S. Patent No. 11,818,116.
Applicant respectfully requests these rejections be held in abeyance until prosecution of the present application has advanced to the point where the double patenting rejections are the sole remaining issues related to allowance or appeal. To be sure, any amendments would moot the present double patenting rejection, which would (if a terminal disclaimer were to presently be filed) require a subsequent petition to remove the disclaimer from the prosecution history.”
In response, the examiner points out that applicant can file a terminal disclaimer or amendment the claim language is such a manner where there is NO overlap content between the pending claims and the reference claims..etc. The rejection is maintained at this time.
Applicant states on page[s] 8 of the remarks as filed: “Claim 1 recites that the message comprises a payload comprising a token and content destined for a second party. This language describes a unified payload structure where the token coexists with separate, additional content that is ultimately destined for the second party. The token is merely one component within a larger payload that contains other substantive content. Keresman does not disclose or suggest such a unified payload structure. In Keresman, the authorization message is a focused, purpose-built transaction authorization request. The token in Keresman's message is not accompanied by separate "content destined for a second party" within the same payload. Rather, the token (and subsequently the PAN) is the essential data element for the authorization transaction, and any other fields in the authorization message (such as amount, merchant ID, timestamp) are transaction parameters, not separate content destined for a second party.”
In response, the examiner isn’t persuaded, the examiner points to the prior art of Keresman. Specifically, at Figure # 3, and paragraph: 0068, Next (at step 7), the TTSP 140 [i.e. applicant’s first party] provides [i.e. applicant’s destined….] the merchant 130 [i.e. applicant’s second party] with the token (e.g., retrieved from the token value 146) [i.e. applicant’s token] for use in connection with the transaction, e.g., by posting the token to the merchant's web site 134. Optionally, the TTSP 140 may provide [i.e. applicant’s destined…] the merchant 130 with additional information beyond just the token (e.g., reputation, history, score, etc.) [i.e. applicant’s content].
***The examiner notes, respectfully, applicants recited “content,” can be any data or data type generated under the sun. Applicant has intentionally kept this feature broad in scope. Therefore, the examiner’s logic and reasoning over the prior art of Keresman is fair and reasonable.
***The examiners response above equally applies to applicant’s same or similar types of remarks regarding claim # 1, made on page[s] 9, 10, 11, 12, 13, 15 of the remarks as filed.
Applicant states on page[s] 9 of the remarks as filed: “Second, Keresman paragraph 0068's "additional information" is optional metadata about the tokenization transaction itself, not separate business content that the merchant needs to transmit to a payment network or issuer. The examples given—reputation, history, score—are risk assessment metrics generated by the tokenization service to inform the merchant about the transaction. This metadata is fundamentally different from "content destined for a second party” as recited in claim 1. Claim 1 contemplates a first party having substantive business content (such as a purchase order, invoice, data file, or transaction details) that must be transmitted to a second party, with a token embedded within that content to represent sensitive information. The optional risk metrics in Keresman paragraph 0068 are not business content destined for the payment network or issuer; they are decisional information provided to the merchant.”
In response, the examiner isn’t persuaded, the examiner points out that applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., Claim 1 contemplates a first party having substantive business content (such as a purchase order, invoice, data file, or transaction details) that must be transmitted to a second party,) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
***The examiners response above equally applies to applicant’s same or similar types of remarks regarding claim # 1, made on page[s] 9, 10, 11, 12, 13, 14 of the remarks as filed.
Applicant states on page[s] 11 of the remarks as filed: “The distinction is that claim 1 contemplates a gateway that acts as a transparent intermediary, receiving a message with a payload containing both a token and business content, performing the token substitution, and forwarding the entire payload with all its content to the second party. The second party receives the substantive content they were meant to receive, now augmented with the sensitive information that was represented by the token. This architecture enables the first party to transmit sensitive information securely (as a token) while still delivering complete business content to the second party.”
In response, the examiner isn’t persuaded, the examiner points out that applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., The distinction is that claim 1 contemplates a gateway that acts as a transparent intermediary, receiving a message with a payload containing both a token and business content) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
***The examiners response above equally applies to applicant’s same or similar types of remarks regarding claim # 1, made on page[s] 12 of the remarks as filed.
Applicant states on page[s] 13, 14 of the remarks as filed: “The differences between claim 1 and Keresman are not merely semantic or superficial. They reflect fundamentally different system architectures. Claim 1 describes a transparent gateway system that enables secure transmission of complete messages containing both sensitive information and business content. Keresman describes a payment authorization system where tokens are converted to PANs for the limited purpose of obtaining authorization from payment networks or issuers. These are distinct technical solutions to different technical problems. To the extent the Office relies on Official Notice to fill gaps in Keresman's disclosure, Applicant respectfully traverses this attempted use of Official Notice as improper. Official Notice is only permissible for facts of a notorious character that are capable of instant and unquestionable demonstration. MPEP §2144.03(A). It is never appropriate to rely solely on Official Notice as the principal evidence upon which a rejection is based. Instead, Official Notice is only appropriate for facts that serve to fill in minor gaps in a rejection. MPEP §2144.03(A).
The missing limitations in Keresman are not minor gaps that can be filled with Official Notice. The concept of a payload containing both a token and separate content destined for a second party is not a matter of common knowledge or capable of instant and unquestionable demonstration. The architecture of receiving such a payload, replacing the token with sensitive information within that payload, and forwarding the complete payload to the second party is a specific technical implementation that must be disclosed in the reference to establish anticipation.
Recent decisions by the Board of Patent Appeals and Interferences have defined what types of information are and are not capable of instant and unquestionable demonstration. In Ex parte Chapman (Appeal No. 2009-010238), the Board reversed the Office's use of Official Notice where the Office claimed it is well known in the art that a customer contacts a customer service representative via telephone or email. The Board noted that simply asserting something is well known in the art without evidentiary support is unsupported speculation by the Office, which does not amount to a finding supportive of the Office's obviousness conclusion.”
In response, the examiner has not taken official notice as alleged by applicant.
Applicant states on page[s] 20 of the remarks as filed: “Claim 2 is rejected under 35 U.S.C. §103 as allegedly being unpatentable over Keresman in view of Gluck (U.S. Publication No. 2011/0321148, hereinafter “Gluck”). Applicant traverses. Applicant’s arguments with respect to claim 1| as pertaining to Keresman are equally applicable to claim 2 and will not be repeated but are incorporated by reference. The addition of Gluck does not remedy these deficiencies. Withdrawal of the rejection is respectfully requested.”
In response, applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant states on page[s] 20, 21 of the remarks as filed: “Claim 6 is rejected under 35 U.S.C. § 103 as allegedly being unpatentable over Keresman in view of Elleuch (U.S. Publication No. 2010/0121961). Applicant traverses. Applicant's arguments with respect to claim 1 as pertaining to Keresman are equally applicable to claim 6 and will not be repeated but are incorporated by reference. The addition of Elleuch does not remedy these deficiencies of Keresman. Elleuch relates to session mobility in telecommunications networks and does not address tokenization, payload structures containing both tokens and business content, or gateway-based token replacement systems. Withdrawal of the rejection is respectfully requested.”
In response, applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant states on page[s] 21, 22 of the remarks as filed: “Keresman does not disclose or suggest this fallback mechanism. Keresman describes a payment authorization flow where a merchant sends an authorization request with a token to a tokenization service, the tokenization service converts the token to a PAN, and the PAN is forwarded to a payment network or issuer for authorization. Keresman does not describe any scenario where the tokenization service fails to forward the authorization request and the merchant then handles the token-to-PAN conversion itself and sends directly to the payment network or issuer. Such a scenario would be contrary to Keresman's architecture, where the merchant does not have access to the PAN (that is the whole point of tokenization) and cannot perform the token-to-PAN conversion itself.”
In response, the examiner isn’t persuaded, the examiner points to the priopr art of Robertson. Specifically, at paragraph 0088, Consequently `Type B` web proxy server 110b processes the received request by: Then at paragraph 0089, returning an error message to the user and not forwarding any data into the rest of the system
***The examiners response above equally applies to applicant’s same or similar types of remarks regarding claims # 8,9, made on page[s] 22,23 of the remarks as filed.
Applicant states on page[s] 22 of the remarks as filed: “Robertson does not disclose or suggest a first party replacing a token with sensitive information and transmitting directly to a second party upon receiving a failure message.
Robertson's entire purpose is to detect security vulnerabilities by comparing proxy outputs. When a difference is detected and an alert is generated, Robertson blocks the outputs to prevent potential security breaches. Robertson does not describe any fallback routing mechanism, any alternative delivery path, or any scenario where the originating party retrieves sensitive information and sends directly to the intended recipient. Robertson is concerned with preventing potentially malicious content from reaching its destination, not with ensuring reliable delivery through alternative paths.”
In response, the examiner isn’t persuaded, the examiner points out that applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e.,…..not with ensuring reliable delivery through alternative path) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
***The examiners response above equally applies to applicant’s same or similar types of remarks regarding claims # 8,9, made on page[s] 23 of the remarks as filed.
Applicant states on page[s] 23 of the remarks as filed: “The architectures and purposes of Robertson and claims 8-9 are fundamentally incompatible. Claims 8-9 describe a reliability feature that ensures message delivery even when the primary gateway path fails. Robertson describes a security feature that prevents message delivery when suspicious activity is detected. Claims 8-9 contemplate the first party having the capability to retrieve sensitive information and send directly to the second party as a backup mechanism. Robertson contemplates blocking suspicious content and alerting security personnel. There is no overlap between these concepts.”
In response, the examiner isn’t persuaded, the examiner out that there is a improvement by receiving of the tokenized data and message content of Keresman to include scanning the received tokenized data and message for anomalies of Robertson in order to prevent data compromise. This would allow for the trusted tokenization system of Keresman to generate an alert of detection of a security data breach. See paragraph 0010, lines 1 - 4, and paragraph 0011 of Robertson.
Applicant states on page[s] 23, 24 of the remarks as filed: “Claim 13 is rejected under 35 U.S.C. § 103 as allegedly being unpatentable over Weber in view of Rollet (U.S. Publication No. 2016/0337333). Applicant traverses. Applicant's arguments with respect to claim 12 as pertaining to Weber are equally applicable to claim 13 and will not be repeated but are incorporated by reference. The addition of Rollet does not remedy these deficiencies of Weber. Rollet relates to HTTP client signatures and classification of TCP connections as trusted or untrusted, and does not address client-executed gateway messaging applications, token replacement schemes, or the specific fallback mechanism where a client redirects messages to a receiving system upon gateway failure. Withdrawal of the rejection is respectfully requested.”
In response, applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant states on page[s] 24 of the remarks as filed: “Claim 15 is rejected under 35 U.S.C. § 103 as allegedly being unpatentable over Weber in view of Kidder (U.S. Publication No. 2012/0255036). Applicant traverses. Applicant's arguments with respect to claim 12 as pertaining to Weber are equally applicable to claim 15 and will not be repeated but are incorporated by reference. The addition of Kidder does not remedy these deficiencies of Weber. Withdrawal of the rejection is respectfully requested.”
In response, applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant states on page[s] 24 of the remarks as filed: “Claim 16 is rejected under 35 U.S.C. § 103 as allegedly being unpatentable over Weber in view of Kidder. Applicant's arguments with respect to claim 12 as pertaining to Weber are equally applicable to claim 16 and will not be repeated but are incorporated by reference. The addition of Kidder does not remedy these deficiencies of Weber. Withdrawal of the rejection is respectfully requested.”
In response, applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant states on page[s] 24, 25 of the remarks as filed: “Claim 17 depends from claim 12 and further recites that the message comprises a batch file that comprises a plurality of tokens that are each defined by a particular location in the message, and the network gateway is configured to replace one or more of the plurality of tokens with corresponding sensitive data. This claim describes a scenario where a single message contains multiple tokens at known positions, and the gateway processes this batch file by locating and replacing each token with its corresponding sensitive information. This batch processing capability enables efficient handling of messages that require multiple pieces of sensitive information to be inserted at different locations within the payload.
The batch file architecture of claim 17 is distinct from single-token systems in several important ways. First, the message contains multiple tokens rather than a single token, meaning the gateway must handle multiple substitution operations within one message. Second, each token is defined by a particular location in the message, meaning the system must track and manage multiple token positions. Third, the gateway is configured to replace one or more of the plurality of tokens with corresponding sensitive data, meaning the gateway must correctly match each token to its corresponding sensitive information and perform multiple replacements accurately. This architecture enables complex messages where multiple sensitive data elements must be incorporated at specific positions within the message structure.
Weber does not disclose or suggest a batch file containing multiple tokens at particular locations that are each replaced with corresponding sensitive data. Weber describes a broker system that receives order messages and transforms them for downstream transmission. Weber may describe order messages with various data fields, but Weber does not teach or suggest a batch file architecture where multiple tokens at defined positions are each replaced with corresponding sensitive information. Weber's broker transforms and repackages messages to accommodate different party requirements, but this is fundamentally different from processing a batch file with multiple tokens at specific locations and replacing each token with its corresponding sensitive data while preserving the batch file structure.
The Office has cited Schenk to supply the missing batch processing feature, but Schenk does not teach or suggest what claim 17 recites. While the PDF for Schenk could not be fully extracted due to file corruption, based on the Office's characterization, Schenk appears to relate to data tokenization and field-level protection in network communications. However, Schenk does not cure Weber's deficiencies with respect to batch file processing with multiple tokens at particular locations.”
In response, the examiner isn’t persuaded, the examiner points to the prior art of Schenk. Specifically, at paragraph 0087, As should now be appreciated, interposition of processing unit 25 in the connection between device 14 and server 50 allows payload data in communications between computing device 14 to be secured. Sensitive data is stored at data vaulting and tokenization server 36, and replaced in request messages with tokens. Tokens in response data may be replaced with sensitive data retrieved from data vaulting and tokenization server 36, or a proxy therefor (e.g. additional data). In this way, the message exchange between device 14 and server 50 over the established connection need not any provide any sensitive data to server 50
***The examiners response above equally applies to applicant’s same or similar types of remarks regarding claims # 17, made on page[s] 26 of the remarks as filed.
Applicant states on page[s] 25 and 26 of the remarks as filed: “The concept of a batch file with multiple tokens each defined by a particular location is a specific architectural implementation. This architecture implies that the system maintains a mapping or index of token positions within the batch file structure, and the gateway must process multiple token locations sequentially or simultaneously to perform all the necessary replacements. The gateway must ensure that each token is replaced with its correct corresponding sensitive data, meaning there must be coordination between token positions, token identifiers, and the sensitive data repository. This level of architectural sophistication is not taught or suggested in Weber or Schenk.”
In response, the examiner isn’t persuaded, the examiner points out that applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e.,…This architecture implies that the system maintains a mapping or index of token positions within the batch file structure, and the gateway must process multiple token locations sequentially or simultaneously to perform all the necessary replacements…) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant states on page[s] 26 of the remarks as filed: “A person of ordinary skill in the art would not combine Weber and Schenk to arrive at claim 17. Weber teaches message transformation in a trading context, which involves repackaging entire messages rather than performing multiple surgical token replacements at specific positions. Schenk, to the extent it addresses tokenization, does not appear to teach batch file processing with multiple tokens at particular locations that must each be replaced with corresponding sensitive data. There is no motivation in either reference to create a batch file architecture that maintains multiple token positions and performs coordinated replacements of multiple tokens with their corresponding sensitive data while preserving the batch file structure.”
In response, the examiner isn’t persuaded, the examiner points out that in order for the improvement of a completion of a tokenized transaction by the downstream party or merchant of Weber is by encrypting the tokenized transaction data that is in route to the merchant or downstream party of Schenk. The message is secured from attack or compromise while in transit to the merchant or downstream party. See paragraphs 0003, 0004 of Schenk.
Applicant states on page[s] 27 of the remarks as filed: “Applicant has amended claim 19 to specify that the token locator is a "client-generated token locator." This amendment clarifies that the client creates the token locator rather than the token locator being provided by or generated by the gateway or another entity. The client determines where to place the token within the payload and generates the token locator that communicates this location information to the gateway. This amendment is fully supported by the specification at paragraph 47, which states "In some embodiments, the client 110 is configured to dynamically or randomly place the token 204 within the payload 208 of the message 200 so as to increase security. The client 110 then creates the token locator 206, which can be read by the gateway 105."”
In response, the examiner isn’t persuaded, the examiner points to the prior art of Keresman. Specifically, at paragraph: 0037, lines 1 – 4, Having received the PAN, the TTSP 140 [i.e. applicant’s client] produces a corresponding token. For example, the equipment 142 is optionally provisioned and/or programmed with (or otherwise has access to) a token generator 144 which generates a token for the received PAN.
***The examiners response above equally applies to applicant’s same or similar types of remarks regarding claims # 19, made on page[s] 27- 32 of the remarks as filed.
Response to Amendment
Status of the instant application:
Claim[s] 1 – 20 are pending in the instant application.
Regarding claim[s] 12 – 20 under the various anticipatory and obviousness rejections, applicant’s claim amendments have been considered, therefore, the rejections are withdrawn. However, there are new prior art rejections issued to address applicant’s newly added claim amendments in the office action below.
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] 1 – 11, 19, 20 are rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1 – 11, 19, 20 of U.S. Patent No. 10200407.
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 scope and are not distinct in the following manner:
receiving a message from a first entity, where the message includes a payload and a token. The token corresponds with the sensitive information. Replacing the token with the sensitive information within the message and forwarding the message with the sensitive information to a second entity, where the replacing of the token with the sensitive information does not interfere with the forwarding of token from first entity to the second entity communication.
Pending US Application # 18/377456 US PAT # 10200407
1 – 11, 19, 20 1 – 11, 19, 20
Claim[s] 1 – 10, 12 – 20 are rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1- 10, 12 - 20 of U.S. Patent No. 11818116.
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 scope and are not distinct in the following manner:
receiving a message from a first entity, where the message includes a payload and a token. The token corresponds with the sensitive information. Replacing the token with the sensitive information within the message and forwarding the message with the sensitive information to a second entity, where the replacing of the token with the sensitive information does not interfere with the forwarding of token from first entity to the second entity communication.
Pending US Application # 18/377456 US PAT # 11818116
1 – 10, 12 – 20 1 – 10, 12 - 20
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 3, 4, 5, 7, 10, 11 is/are rejected under 35 U.S.C. 102(a)(2) as being taught by Keresman III et al. [US PGPUB # 2017/0017959]
As per claim 1. Keresman does teach a method [paragraph 0003, lines 1 – 6, in the field of data security, tokenization generally refers to a process whereby a real data element is replaced with a surrogate or substitute that is commonly referred to as a token. Generally, it is desirable to keep the value of the real data element secret or otherwise provide only limited access thereto to particular selected entities], comprising:
receiving a message from a first party that comprises a payload comprising a token and content [Figure # 3, and paragraph: 0068, Next (at step 7), the TTSP 140 provides the merchant 130 with the token (e.g., retrieved from the token value 146) for use in connection with the transaction, e.g., by posting the token to the merchant's web site 134. Optionally, the TTSP 140 may provide the merchant 130 with additional information beyond just the token (e.g., reputation, history, score, etc.).] destined for a second party, the token being associated with sensitive information [paragraph 0010, (d) providing the generated token to a first party that uses the token in place of the sensitive data element in a request for authorization to complete a transaction, the request being sent from the first party. Then at paragraph: 0011, (e) intercepting the request for authorization including the token];
replacing the token with the sensitive information within the payload [paragraph 0012, (f) using the token contained in the intercepted request to look-up and retrieve the correlated sensitive data element in the memory device; then at paragraph 0013 (g) replacing the token contained in the request with the sensitive data element retrieved from the memory device]; and
forwarding the message with the sensitive information to the second party [paragraph 0014, forwarding the request containing the sensitive data element to a second party which employs the sensitive data element to determine whether completion of the transaction should be authorized or declined].
As per claim 3. Keresman does teach the method according to claim 1, further comprising generating a token replacement scheme by the first party [paragraph 0015, lines 3 – 16, the system includes: a first hardware server in operative communication with a data communications network, the first hardware server being operated by a trusted tokenization service provider and operative to receive the sensitive data element over said data communications network; a token generator, the token generator generating a token corresponding to the sensitive data element in response to the first hardware server receiving the sensitive data element; and a memory device that stores the generated token and the sensitive data element received by the first hardware server such that they are correlated with one another. The first hardware server is further provisioned to: provide the generated token to a second server over the data communications network]; and
applying the token replacement scheme, by a network gateway, to locate the token within the payload [paragraph 0015, lines 19 – 25, the second server [i.e. applicant’s network gateway] being operated by a first party that uses the token in place of the sensitive data element in a request for authorization to complete a transaction, the request being sent from the second server; receive the request for authorization including the token sent from the second server; use the token contained in the request to look-up and retrieve the correlated sensitive data element in the memory device; replace the token contained in the request with the sensitive data element retrieved from the memory device].
As per claim 4. Keresman does teach the method according to claim 1, further comprising storing the token and the sensitive information in a digital vault of a network gateway prior to receiving the message from the first party [paragraph 0015, lines 3 – 14, the system includes: a first hardware server in operative communication with a data communications network, the first hardware server being operated by a trusted tokenization service provider and operative to receive the sensitive data element over said data communications network; a token generator, the token generator generating a token corresponding to the sensitive data element in response to the first hardware server receiving the sensitive data element; and a memory device that stores the generated token and the sensitive data element received by the first hardware server such that they are correlated with one another].
As per claim 5. Keresman does teach the method according to claim 1, further comprising:
receiving a tokenization request that comprises the sensitive information [paragraph 0007, (a) receiving the sensitive data element, the sensitive data element being received over a data communications network at a hardware computing device of a trusted tokenization service provider];
generating the token from the sensitive information [paragraph 0008, (b) generating a token corresponding to the received sensitive data element];
replacing the sensitive information in the tokenization request with the token at a location of the sensitive information [paragraph 0015, lines 19 – 25, the second server [i.e. applicant’s network gateway] being operated by a first party that uses the token in place of the sensitive data element in a request for authorization to complete a transaction, the request being sent from the second server; receive the request for authorization including the token sent from the second server; use the token contained in the request to look-up and retrieve the correlated sensitive data element in the memory device; replace the token contained in the request with the sensitive data element retrieved from the memory device]; and
transmitting the tokenization request back to the first party that includes the token in place of the sensitive information [paragraph 0015, lines 8 – 19, a token generator, the token generator generating a token corresponding to the sensitive data element in response to the first hardware server receiving the sensitive data element; and a memory device that stores the generated token and the sensitive data element received by the first hardware server such that they are correlated with one another. The first hardware server is further provisioned to: provide the generated token to a second server over the data communications network, the second server being operated by a first party that uses the token in place of the sensitive data element in a request for authorization to complete a transaction].
As per claim 7. Keresman does teach the method according to claim 1, further comprising transmitting the token or the sensitive information to the first party from a digital vault [paragraph 0009, (c) storing the token and sensitive data element in a memory device such that they are correlated with one another].
As per claim 10. Keresman does teach the method according to claim 1, further comprising applying a token replacement scheme to the message to locate the token, wherein the token is located at a particular location within the message and the token replacement scheme comprises instructions for finding the location of the token [paragraph 0015, lines 19 – 25, receive the request for authorization including the token sent from the second server; use the token contained in the request to look-up and retrieve the correlated sensitive data element].
As per claim 11. Keresman does teach the method according to claim 1, wherein the token is embedded and wrapped with token identifying data [paragraph 0003, lines 6 – 9, conventionally, the value of the token by itself may have no specific or readily discernable meaning. Rather, the token is merely a reference or identifier]; and
a network gateway locates the token by searching the message for the token identifying data or locating the token using a pre-negotiated token replacement scheme [paragraph 0015, 19 – 25, the second server [i.e. applicant’s network gateway] being operated by a first party that uses the token in place of the sensitive data element in a request for authorization to complete a transaction, the request being sent from the second server; receive the request for authorization including the token sent from the second server; use the token contained in the request to look-up and retrieve the correlated sensitive data element].
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.
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] 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keresman, III et al. [US PGPUB # 2017/0017959] in view of Gluck [US PGPUB # 2011/0321148]
As per claim 2. Keresman does teach what is taught in the rejection of claim # 1 above.
Keresman does not clearly teach the method according to claim 1, wherein the message comprises a network-based protocol request and a token replacement scheme is incorporated into a header of the network-based protocol request or another location in the message that is not the payload.
However, Gluck does teach the method according to claim 1, wherein the message comprises a network-based protocol request and a token replacement scheme is incorporated into a header of the network-based protocol request or another location in the message that is not the payload [paragraph 0028, lines 4 - 13, A HyperText Transfer protocol (HTTP) request, for example, can contain a token in the headers [i.e. applicant’s header], etc. In addition, if the firewall agent (i.e., the agent in the component sensing the events on a sub-systems) is in-line of the event, it can remove the token before forwarding the request to the sub-system. One or more components of the system (e.g., firewall, application, sub-system agents, subsystems) can use the tokens [i.e. applicant's token] and/or related information to correlate [i.e. applicant's token replacement scheme], collect context information, generate context information, evaluate and/or react].
It would have been would have been obvious to one of ordinary skilled in the art before the effective filing date of applicant’s claimed invention to combine the teachings of Keresman and Gluck in order for the recipient to obtain the de-tokenized sensitive data of Keresman to include authorizing the recipient for access to the merchant network by firewall of Gluck. This would allow for the merchant to create and maintain policies that are implemented by a firewall to allow or block accesses by a requesting recipient. See paragraph 0021 of Gluck.
Claim[s] 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keresman III et al. [US PGPUB # 2017/0017959] in view of Elleuch et al. [US PGPUB # 2010/0121961]
As per claim 6. Keresman does teach what is taught in the rejection of claim 1 above.
Keresman does not clearly teach the method according to claim 1, wherein the payload comprises a pre-negotiated message format for the second party.
However, Elleuch does teach the method according to claim 1, wherein the payload comprises a pre-negotiated message format for the second party [paragraph 0031, lines 1 – 6, negotiated in the body of part of the signaling messages].
It would have been would have been obvious to one of ordinary skilled in the art before the effective filing date of applicant’s claimed invention to combine the teachings of Keresman and Elleuch in order for the recipient to obtain the de-tokenized sensitive data of Keresman to include negotiating the data format of the sensitive data of Elleuch. This would allow for the recipient to view the sensitive data in a supported data format. See paragraph 0004, lines 1 - 3, and paragraph 0005, lines 5 - 7 of Elleuch.
Claim[s] 8, 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keresman III et al. [US PGPUB # 2017/0017959], hereinafter Keresman, in view of Robertson [US PGPUB # 2016/0164840]
As per claim 8. Keresman does teach what is taught in the rejection of claim 7 above.
Keresman does not clearly teach the method according to claim 7, further comprising receiving, by the first party, a failure message that indicates that a network gateway has failed to forward the message.
However, Robertson does teach method according to claim 7, further comprising receiving, by the first party, a failure message that indicates that a network gateway has failed to forward the message [paragraph 0088, Consequently `Type B` web proxy server 110b processes the received request by: Then at paragraph 0089, returning an error message to the user and not forwarding any data into the rest of the system].
It would have been would have been obvious to one of ordinary skilled in the art before the effective filing date to combine the teachings of Keresman and Robertson in order for the receiving of the tokenized data and message content of Keresman to include scanning the received tokenized data and message for anomalies of Robertson. This would allow for the trusted tokenization system to generate an alert at time of detection of a security breach. See paragraph 0010, lines 1 - 4, and paragraph 0011 of Robertson.
As per claim 9. Keresman as modified does teach the method according to claim 8, further comprising:
replacing, by the first party, the token with the sensitive information [Keresman, paragraph 0010, (d) providing the generated token to a first party that uses the token in place of the sensitive data element in a request for authorization to complete a transaction, the request being sent from the first party]; and
transmitting, by the first party, the message directly to the second party when the first party receives the failure message [Robertson, paragraph 0088, Consequently `Type B` web proxy server 110b processes the received request by from the client: at paragraph 0089 returning an error message [i.e. applicants failure message] to the user and not forwarding any data into the rest of the system of web proxy servers [i.e. applicant’s second party], or at paragraph 0090 truncates the user supplied data until it is of a valid length and only forwards [i.e. applicant’s transmitting by first party the message directly to the second party] the remaining data into the rest of network system 100].
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) 12, 14, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Weber et al. [US PGPUB # 2014/0032418] in view of Salama et al. [US PGPUB # 2020/0082403]
As per claim 12. Weber does teach a system [paragraph 0006, embodiments of the invention relate to providing a token broker to assist upstream trading partners, downstream trading partners, and merchant ordering systems communicate during an order or payment process using one or more order messages (e.g., a first, second, third, and fourth order message)], comprising:
a client executing a gateway messaging application [Figure # 2, and paragraph 0064, lines 3 – 5, the system 200 may include an upstream trading partner system 210 or customer 211 [i.e. client] that submits an order message to a broker system 220 [i.e. applicant’s network gateway]]; and
a network gateway that acts agnostically to payload format or content [Figure # 7 and paragraph: 0056, lines 4 – 9, In an embodiment, a merchant ordering system 140 transmits a reply message 180 to a broker system 120, which forwards the message to an upstream trading partner system 110 without substantial processing. An exemplary reply message is provided in FIG. 7.], the network gateway being coupled to the client [Figure # 1, and paragraph 0046, lines 1 – 6, At step 1, the broker system 120 may receive an order message from an upstream trading partner system 110. The broker system 120 may be located (in an operational sense) between the upstream trading partner system 110, tokenization service system 130, merchant ordering system 140, and/or downstream trading partner system 150] and configured to:
receive a message from the client that comprises a payload comprising a token, the token representing sensitive information [Figure # 2, and paragraph 0065, At step 21, the broker system 220 can accept the order message through a hosted IFRAME. The order message may comprise an order and confidential account identifier. The hosted, embeddable IFRAME may also translate data as is it transferred between entities. Then at paragraph 0066, at step 22, the broker system 220 can transmit the account identifier (e.g., primary account number) to a tokenization service system 230 so that the tokenization service system can convert the account identifier to an account token. The tokenization service system can transmit the token back to the broker system 220];
apply a……… token replacement scheme to the message to locate the token [Figure # 2, and paragraph 0068, lines 1 – 5, the broker system 220 may also implement a transaction decision engine in order to accept payment requests from the merchant ordering system's proxy. In an embodiment, the transaction decision engine can invoke the tokenization service to tokenize/de-tokenize payment data];
exchange the token with the sensitive information [paragraph 0068, lines 1 – 5, In an embodiment, the transaction decision engine can invoke the tokenization service to tokenize/de-tokenize payment data]; and
forward the message with the sensitive information to a receiving system without altering the payload [Figure # 2, and paragraph 0067, lines 1 – 3, at step 23, the broker system 220 can transmit the order message to the merchant ordering system 240. The order message may comprise an order and account token].
Weber does not clearly teach the claim limitation of: “..pre-negotiated…., wherein the pre-negotiated token replacement scheme is established between the client and the network gateway in advance.”
However, Salama do teach the claim limitation of: “..pre-negotiated…., wherein the pre-negotiated token replacement scheme is established between the client and the network gateway in advance [Figure # 7 and paragraph: 0091, lines 7 – 23, For example, vault 146 may determine, based on one or more conditions assessed by vault 146 relating to the transaction account signal, that the transaction account may be at risk. In such an instance, vault 146 may perform a process to replace the token using, for example, a different token generation scheme (e.g., use different fields, portions of data fields, combinations of data or data fields, etc.), Vault 146 may be configured to create new key information for the replacement token, and provide the necessary information to payment network 130 to ensure it is able to detect when it receives a tokenized transaction account from merchant system 150. Vault 146 may provide the new tokenized transaction account to client device 104 for storage and subsequent use during later transactions, consistent with the disclosed embodiments (step 740). As noted above, vault 146 may determine to replace a token dynamically or periodically based one or more conditions.].”
It would have been obvious to one of ordinary skilled in the art at before the effective filing date of applicant's claimed invention to combine the teachings of Weber as modified and Salama in order for the completion of the transaction by the downstream party or merchant of Weber as modified to include a dynamic authorization levels of access of Salama. This would allow for the merchant to maintain access control to the data during the transaction, preventing compromise of the merchant data. See paragraph: 0034 of Salama.
As per claim 14. Weber does teach the system according to claim 12, wherein the client is configured through the gateway messaging application to replace the token with the sensitive information prior to redirecting the message to the receiving system [Weber, paragraph 0063, lines 13 – 14, the broker system can interact with the tokenization service system 130 to de-tokenize the token. Then at paragraph 0063, lines 14 – 17, and the broker system 120 can provide the de-tokenized order to the downstream trading partner system 150 for order and payment processing].
As per claim 18. Weber does teach the system according to claim 12, wherein the client is configured through the gateway messaging application to replace an endpoint of the message such that it directs to the network gateway [Weber, Figure # 2, and paragraph 0064, lines 3 – 5, the system 200 may include an upstream trading partner system 210 or customer 211 that submits an order message to a broker system 220].
Claim[s] 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Weber et al. [US PGPUB # 2014/0032418] in view of Salama et al. [US PGPUB # 2020/0082403] as applied in the rejection of claim 12 above, further in view of Rollet [US PGPUB # 2016/0337333]
As per claim 13. Weber and Salama do teach what is taught in the rejection of claim 12 above.
Weber and Salama do not teach clearly the system according to claim 12, wherein the client is configured through the gateway messaging application to:
receive a failure message when the network gateway is unable to forward the message; and
redirect the message to the receiving system.
However, Rollet does teach the system according to claim 12, wherein the client is configured through the gateway messaging application to:
receive a failure message when the network gateway is unable to forward the message [Figure # 3, and paragraph: 0101, In a following optional step S503, the analyser device 130 checks the IP destination address obtained in the step S502 from the detected HTTP request message. To achieve this, the analyser device 130 compares said IP destination address with the contents of the IP addresses database 310. In the scope of the modular arrangement shown in FIG. 3, the step S503 is performed by the URL/IP-based classifier module 303. When the IP destination address is contained in the IP address database 310 and the associated safety indicator is different from "0", then it means that the TCP connection is non-trusted and an error event is consequently generated toward the alarm generator 306. Classifying the TCP connections by relying on such IP destination address allows classifying more easily legitimate HTTP client applications that access one or few domains, such as software update HTTP client applications.]; and
redirect the message to the receiving system [paragraph 0025, According to a particular embodiment, the authentication procedure comprises: sending a response to a device having originated the detected HTTP request message, said response redirecting the device having originated the detected HTTP request message toward another URL; receiving from the device having originated the detected HTTP request message another HTTP request message referring to said another URL; sending in response to said another HTTP request message a web page via which the user is able to enter authentication information; and, when valid authentication information is received, considering the TCP connection as trusted, otherwise considering the TCP connection as untrusted.].
It would have been obvious to one of ordinary skilled in the art at before the effective filing date of applicant's claimed invention to combine the teachings of Weber as modified and Rollet in order for the completion of the transaction by the downstream party or merchant of Weber as modified to include authenticating the requester of the transaction before the transaction is completed of Rollet. This would allow for the merchant to maintain black lists or white lists to allow or deny the requestor access to the service or resource after the transaction is completed. See paragraph 0008 of Rollet.
***The examiner notes that the underlined claim limitation above is viewed by the examiner as field of use claim limitation. The claim limitation doesn't further limit the claim language.
Claim[s] 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Weber et al. [US PGPUB # 2014/0032418] in view of Salama et al. [US PGPUB # 2020/0082403] as applied in the rejection of claim 12 above, further in view of Kidder [US PGPUB # 2012/0255036]
As per claim 15. Weber and Salama do teach what is taught in the rejection of claim 12 above.
Weber and Salama do not clearly teach the system according to claim 12, wherein the message comprises a network-based protocol request and a token locator is incorporated into a header of the network-based protocol request.
However, Kidder does teach the system according to claim 12, wherein the message comprises a network-based protocol request and a token locator is incorporated into a header of the network-based protocol request [paragraph 0025, lines 3 – 7, evaluating a token as a URL in a HTTP header].
It would have been obvious to one of ordinary skilled in the art at before the effective filing date of applicant's claimed invention to combine the teachings of Weber as modified and Kidder in order for the completion of the tokenized transaction by the downstream party or merchant of Weber as modified to include logging the activity surrounding the token in the requested transaction message of Kidder. This would allow for the merchant to view activity surrounding the token in the transaction message as whether the tokens activity where authorized or not. See paragraph 0027 of Kidder.
Claim[s] 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Weber et al. [US PGPUB # 2014/0032418] in view of Salama et al. [2020/0082403] and Kidder [US PGPUB # 2012/0255036] as applied to claim 15 above, further in view of Sivan et al. [US PAT # 8976791]
As per claim 16. Weber and Salama and Kidder do teach what is taught in the rejection of claim 15 above.
Weber and Salama and Kidder do not teach clearly the system according to claim 15, wherein the network gateway is configured to strip off at least a portion of the header prior to forwarding the message with the sensitive information to a receiving system.
However, Sivan does teach the system according to claim 15, wherein the network gateway is configured to strip off at least a portion of the header prior to forwarding the message with the sensitive information to a receiving system [col. 3, lines 17 – 28, the IEEE 802.1ah standard header is stripped by the PEB 118h [provider edge device] of the Ethernet packets as it travels to customer A network].
It would have been obvious to one of ordinary skilled in the art at before the effective filing date of applicant's claimed invention to combine the teachings of Weber as modified and Sivan in order for the completion of the tokenized transaction by the downstream party or merchant of Weber as modified to include policies that identify if the requested tokenized transaction matches a particular known flow class of Sivan. This would allow for the merchant to implement policies that allow the identification of the tokenized transactions or classify what type of tokenized transaction is presented. See Col. 10, lines 51 - 57 of Sivan.
Claim[s] 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Weber et al. [US PGPUB # 2014/0032418] in view Salama et al. [US PGPUB # 2020/0082403] as applied in the rejection of claim 12 above, further in view of Schenk et al. [US PGPUB # 2017/0093812]
As per claim 17. Weber and Salama do teach what is taught in the rejection of claim 12 above.
Weber and Salama do not teach clearly the system according to claim 12, wherein the message comprises a batch file that comprises a plurality of tokens that are each defined by a particular location in the message, and the network gateway is configured to replace one or more of the plurality of tokens with corresponding sensitive data.
However, Schenk does teach the system according to claim 12, wherein the message comprises a batch file that comprises a plurality of tokens that are each defined by a particular location in the message, and the network gateway is configured to replace one or more of the plurality of tokens with corresponding sensitive data [paragraph 0087, As should now be appreciated, interposition of processing unit 25 in the connection between device 14 and server 50 allows payload data in communications between computing device 14 to be secured. Sensitive data is stored at data vaulting and tokenization server 36, and replaced in request messages with tokens. Tokens in response data may be replaced with sensitive data retrieved from data vaulting and tokenization server 36, or a proxy therefor (e.g. additional data). In this way, the message exchange between device 14 and server 50 over the established connection need not any provide any sensitive data to server 50].
It would have been obvious to one of ordinary skilled in the art at before the effective filing date of applicant's claimed invention to combine the teachings of Weber as modified and Schenk in order for the completion of the tokenized transaction by the downstream party or merchant of Weber as modified to include encrypting the tokenized transaction that is in route to the merchant or downstream party of Schnek. This would allow for the tokenized transaction data besides the token, and the message to be secured while in transit to the merchant or downstream party. See paragraphs 0003, 0004 of Schenk.
Claim[s] 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Weber et al. [US PGPUB # 2014/0032418] in view of Keresman, III et al. [US PGPUB # 2017/0017959]
As per claim 19. Weber does teach a system [paragraph 0006, embodiments of the invention relate to providing a token broker to assist upstream trading partners, downstream trading partners, and merchant ordering systems communicate during an order or payment process using one or more order messages (e.g., a first, second, third, and fourth order message)], comprising:
a processor [figure # 3, and paragraph 0071, lines 1 – 4, the broker system 305 can contain a broker computer 310. The broker computer 310 can comprise a processor 312 and a computer readable medium 314 coupled to the processor 312]; and
a memory storing logic that is executable by the processor to [paragraph 0073, lines 1 – 3, the processor 312 may be configured to execute the code stored in the computer readable medium 314 to implement the various methods described herein]:
receive a message from the client that comprises a payload and a token, the token representing sensitive information [Figure # 2, and paragraph 0065, At step 21, the broker system 220 can accept the order message through a hosted IFRAME. The order message may comprise an order and confidential account identifier. The hosted, embeddable IFRAME may also translate data as is it transferred between entities. Then at paragraph 0066, at step 22, the broker system 220 can transmit the account identifier (e.g., primary account number) to a tokenization service system 230 so that the tokenization service system can convert the account identifier to an account token. The tokenization service system can transmit the token back to the broker system 220], the message comprising:
an endpoint that directs the message to a network gateway [Figure # 2, and paragraph 0064, lines 3 – 5, the system 200 may include an upstream trading partner system 210 or customer 211 that submits an order message to a broker system 220];
a…..token locator that identifies a location of the token within the payload [paragraph 0063, lines 13 – 14, the broker system can interact with the tokenization service system 130 to de-tokenize the token];
replace the token with the sensitive information [paragraph 0063, lines 13 – 14, the broker system can interact with the tokenization service system 130 to de-tokenize the token] within the payload while leaving other content of the payload unchanged [Figures 5, and 6, and paragraph: 0091, FIG. 6 shows an example of a second order message transmitted between a broker system and a merchant ordering system according to an embodiment of the invention. In an embodiment, FIG. 6 may also include an example of a third order message transmitted between a merchant ordering system and a broker system. The second order message 600 may include an order 610 and an account token 660. The order 510 may be substantially similar to the order in the first order message 500 and comprise substantially similar information. For example, the order 610 can consist of a customer's name 620, order date 630, items to be ordered 640 and the total cost for the order 650.], while leaving other content of the payload unchanged [Figure # 2, and paragraph 0067, lines 1 – 3, at step 23, the broker system 220 can transmit the order message to the merchant ordering system 240. The order message may comprise an order and account token]; and
forward the message with the sensitive information to a receiving system [paragraph 0063, lines 14 – 17, and the broker system 120 can provide the de-tokenized order to the downstream trading partner system 150 for order and payment processing].
Weber does not teach clearly authentication credentials;
..client – generated………………………………………..
authenticate the client with the authentication credentials.
However, Keresman does teach authentication credentials [paragraph 0110, upon receipt of the token and/or request, the TTSP 140 (at step 2) validates that the requestor is authorized to receive the PAN. Of course, various events and/or responses can be triggered if the received token is invalid or the requestor 170 is an unauthorized party];
…client – generated………………………………………..[paragraph: 0037, lines 1 – 4, Having received the PAN, the TTSP 140 produces a corresponding token. For example, the equipment 142 is optionally provisioned and/or programmed with (or otherwise has access to) a token generator 144 which generates a token for the received PAN.]
authenticate the client with the authentication credentials [paragraph 0110, upon receipt of the token and/or request, the TTSP 140 (at step 2) validates that the requestor is authorized to receive the PAN. Of course, various events and/or responses can be triggered if the received token is invalid or the requestor 170 is an unauthorized party].
It would have been obvious to one of ordinary skilled in the art to before the effective filing date to combine the teachings of Weber as modified and Keresman in order for the downstream party to receive the de-tokenized sensitive data in a message of Weber as modified to include authenticating the downstream party of the de-tokenized sensitive data before access to such sensitive data of Keresman. This would allow for an authorized downstream party to receive the sensitive data instead of an un-authorized party. See paragraph 0015, lines 25 – 29 of Keresman.
Claim[s] 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Weber et al. [US PGPUB # 2014/0032418] in view of Keresman III et al. [US PGPUB # 2017/0017959] as applied to claim 19 above, further in view of Styslinger et al. [US PGPUB # 2005/0138426]
As per claim 20. Weber and Keresman do teach what is taught in the rejection of claim 19 above.
Weber and Keresman do not clearly teach the system according to claim 19, wherein the message comprises a header and the endpoint, authentication credentials, and token locator reside in a header of the message, further wherein the system is configured to remove the header from the message prior to forwarding to the receiving system.
However, Styslinger does teach system according to claim 19, wherein the message comprises a header and the endpoint, authentication credentials, and token locator reside in a header of the message, further wherein the system is configured to remove the header from the message prior to forwarding to the receiving system [paragraph 0061, lines 1 – 8, Under another aspect, the invention includes functionality that parses data, stores parsed data, analyzes data, and builds databases, including parsing all requests and responses, and intelligently storing the requests, responses, and parsed data (e.g., for web applications, URLs, paths, script names, HTTP Request and Response Headers, POST and GET parameters and values, Identification and Authentication credentials, session token names and values)].
It would have been obvious to one of ordinary skilled in the art at before the effective filing date of applicant's claimed invention to combine the teachings of Weber as modified and Styslinger in order for the completion of the tokenized transaction by the downstream party or merchant of Weber as modified to include encrypting the tokenized transaction that is in route to the merchant or downstream party of Styslinger. See paragraph 0059, lines 9 – 16 of Styslinger.
***The examiner notes that the prior art of Sivan teaches applicant's "removing the header from the message...etc., at col. 3, lines 17 – 28, the IEEE 802.1ah standard header is stripped by the PEB 118h [provider edge device] of the Ethernet packets as it travels to customer A network.
Conclusion
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.
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
Prosecution Insights