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 .
Terminal Disclaimer
The terminal disclaimer filed on 13/30/2026 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of US Patent No. 12,217,243 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Response to Amendment
The amendment filed March 30, 2026 has been entered. Claims 1-20 remain pending in the application. Applicant's amendments to the Claims have overcome each and every 102 rejections previously set forth in the Non-Final Office Action mailed December 30, 2025.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under the Step 1 of the Section 101 analysis, Claims 1-10 are drawn to a method which is within the four statutory categories (i.e., a process), Claims 11-19 are drawn to a system which is within the four statutory categories (i.e. a machine), and Claim 20 is drawn to a non-transitory computer-readable medium which is within the four statutory categories (i.e., a manufacture).
Since the claims are directed toward statutory categories, it must be determined if the claims are directed towards a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea). Based on consideration of all of the relevant factors with respect to the claim as a whole, claims 1-20 are determined to be directed to an abstract idea. The rationale for this determination is explained below:
Regarding Claims 1, 11, and 20:
Claims 1, 11, and 20 are drawn to an abstract idea without significantly more. The claims recite “receiving, by a token exchange service system, a primary tokenization request from an upstream entity; generating, by the token exchange service system, one or more ancillary tokenization requests based on the primary tokenization request; transmitting, by the token exchange service system, the one or more ancillary tokenization requests in parallel to respective one or more output token vaults, wherein parallel transmission of the one or more ancillary tokenization requests reduces overall response time; receiving, by the token exchange service system, one or more ancillary tokenization responses asynchronously from the respective one or more output token vaults; generating, by the token exchange service system, a primary tokenization response based on the one or more ancillary tokenization responses; and transmitting, by the token exchange service system, the primary tokenization response to the upstream entity.”
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). For example, but for the “token exchange service system” and “token vaults” language, the underlined limitations in the context of this claim encompass the human activity or mental processes. A person could receive and generate requests, and the person could then generate and send responses according to the requests.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “A computer-implemented method for cross-platform token compatibility, comprising:”, “A system for cross-platform token compatibility, the system comprising: one or more processors; and at least one data storage comprising instructions which, when executed by the one or more processors, cause the one or more processors to perform a method comprising:”, “A non-transitory computer-readable medium for cross-platform token compatibility, the non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform a method comprising:”, “token exchange service system”, and “token vaults”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Accordingly, these additional elements, individually or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Regarding Claims 2-10 and 12-19:
Dependent claims 3, 5-6, 8, 12, 14-15, and 17 only further elaborate the abstract idea and do not recite additional elements.
Dependent claims 2, 4, 7, 9-10, 13, 16, and 18-19 include additional limitations, for example, “application programming interface (API)” (Claim 2); “token vaults” (Claims 4 and 13); “payment vehicle” and “card security code” (Claims 7 and 16); “token vaults” (Claims 9 and 18); “intermediary system” and “merchant system” (Claims 10 and 19), but none of these limitations are deemed significantly more than the abstract idea because, as stated above, they require no more than generic computer structures or signals to be executed, and do not recite any Improvements to the functioning of a computer, or Improvements to any other technology or technical field.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation or implementing the judicial exception on a generic computer.
Therefore, whether taken individually or as an ordered combination, claims 2-10 and 12-19 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
Claim(s) 1-3, 5-12, and 14-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dill (US 20200410483 A1; already of record in IDS) in view of Campos (US 20140143089 A1), and in further view of Course (US 20060271499 A1).
Regarding Claims 1, 11, and 20, Dill teaches A computer-implemented method for cross-platform token compatibility, comprising (Dill: Abstract; Fig. 2): A system for cross-platform token compatibility, the system comprising: one or more processors; and at least one data storage comprising instructions which, when executed by the one or more processors, cause the one or more processors to perform a method comprising (Dill: Abstract; Fig. 2; Paragraph(s) 0013; cl. 52): A non-transitory computer-readable medium for cross-platform token compatibility, the non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform a method comprising (Dill: cl. 52):
receiving, by a token exchange service system, a primary tokenization request from an upstream entity (Dill: Paragraph(s) 0011, 0053, 0057, 0075-0077, 0128, 0100, 0223; Fig. 2, items 140, 202B, and 208; Fig. 3, item 316 teach(es) a token registry vault can provide interfaces for various entities (e.g., mobile devices, issuers, merchants, mobile wallet providers, acquirers, etc.) (i.e., an upstream entity) to request payment tokens, request information about payment tokens or otherwise process payment tokens; tokens may be device-specific such that each device associated with an account (i.e., sensitive data) may be provisioned with a particular token; if a token requestor may request tokens for multiple domains, the token requestor may have multiple token requestor identifiers, one for each domain, and the token requestor identifier may include a code for a token service provider (e.g., first 3 digits) (i.e., output token service provider configuration identifiers); the token requestor identifier may include a code for a token service provider; Therefore, the token request may include the output token service provider configuration identifiers; The token requestor may specify configuration preferences (i.e., output token service provider configuration identifiers) or token attributes associated with tokens requested by the token requestor including, for example, token type (e.g., static or dynamic), supported token presentment modes (e.g., scan, contactless, e-commerce, etc.) and any other relevant token configuration information (i.e., output token service provider configuration identifiers) during the onboarding process (i.e., portal)); generating, by the token exchange service system, one or more ancillary tokenization requests based on the primary tokenization request (Dill: Paragraph(s) 0075-0077, 0104 teach(es) if a token requestor may request tokens for multiple domains, the token requestor may have multiple token requestor identifiers, one for each domain; the token requestor identifier may include a code for a token service provider; Therefore, the multiple ancillary tokenization requests are generated using the multiple token requestor identifiers; The network token system may include a token registry database and a token processing server computer. The token registry database may also be referred to as a “token vault”, storing and maintaining issued or generated tokens as well as any other relevant information to the tokens, including a token requestor identifier and an account identifier (e.g., PAN) (i.e., sensitive data of the user, which was routed for tokenization obviously) for each token. The token registry database and the token processing computer may be configured to provide services associated with the token registry including payment account registration, token generation (i.e., teaching ancillary tokenization requests), token issuance, token authentication and activation, token exchange, token routing, token assurance level generation, token life-cycle management, and token processing to the entities that are registered with the network token system); transmitting, by the token exchange service system, the one or more ancillary tokenization requests … to respective one or more output token vaults, … (Dill: Paragraph(s) 0040, 0034, 0104; Fig. 2 item 202A teach(es) The registered entity can provide their respective token requestor identifier (i.e., ancillary tokenization requests) with a token request to the network token system to use its services, requesting the issuance of a token via an API (Application Programming Interface) messaging or a batch request; the token registry vault (i.e., token vaults) can provide registration capability to any entity that wants to interface with the network token system, which provides services such as token generation, token issuance, token authentication and activation, token exchange and token life-cycle management; The network token system may include a token registry database and a token processing server computer. The token registry database may also be referred to as a “token vault”, storing and maintaining issued or generated tokens as well as any other relevant information to the tokens, including a token requestor identifier and an account identifier (e.g., PAN) (i.e., sensitive data of the user) for each token. The token registry database and the token processing computer may be configured to provide services associated with the token registry including payment account registration, token generation (i.e., teaching ancillary tokenization requests), token issuance, token authentication and activation, token exchange, token routing, token assurance level generation, token life-cycle management, and token processing to the entities that are registered with the network token system); receiving, by the token exchange service system, one or more ancillary tokenization responses … from the respective one or more output token vaults (Dill: Paragraph(s) 0128, 0104 teach(es) the acquirer token interface (which may be in the form of an API) may allow the acquirer computer to communicate with the network token system for tokenization and de-tokenization services, including token exchange, token processing and routing (i.e., receiving ancillary tokenization responses and then delivering); using the acquirer token interface, the acquirers may request that the network token system provision a token on their behalf, and a merchant, acquirer or a wallet provider may receive the token in response to a provisioning request message originating from an acquirer (e.g., delivered); The network token system (i.e., including different output token vaults) may include a token registry database and a token processing server computer, and the token registry database may also be referred to as a “token vault”); generating, by the token exchange service system, a primary tokenization response based on the one or more ancillary tokenization responses (Dill: Paragraph(s) 0127-0128, teach(es) the merchant token interface may allow the merchant computer to communicate with the network token system for tokenization and de-tokenization services such as token exchange, token processing and routing, etc.; using the acquirer token interface, the acquirers may request that the network token system provision a token (i.e., an ancillary tokenization response) on their behalf. A merchant, acquirer or a wallet provider may receive the token (i.e., a primary tokenization response) in response to a provisioning request message originating from an acquirer); and transmitting, by the token exchange service system, the primary tokenization response to the upstream entity (Dill: Paragraph(s) 0223, 0207, 0128 teach(es) the token processing server computer may generate a token and return the token through an opposite flow back to the merchant computer (i.e., upstream entity) using an ISO token response message; as stated above, a token requestor may request a plurality of tokens for multiple domains; A merchant, acquirer or a wallet provider may receive the token in response to a provisioning request message originating from an acquirer; the provisioning request message may include a PAN (i.e., sensitive data of the user), a transaction amount, a transaction date and time, an expiration date, a merchant type, an acquirer's country code, a POS entry mode code (e.g., manual key entry, contactless device read, etc.), an acquirer's identifier code, an AVS result code, a CVV2 result code, a CAW result code, CAV data, and any other relevant data).
However, Dill does not explicitly teach …in parallel, and …wherein parallel transmission of the one or more ancillary tokenization requests reduces overall response time.
Campos from same or similar field of endeavor teaches transmitting, by the token exchange service system, the one or more ancillary tokenization requests in parallel to respective one or more output token vaults, wherein parallel transmission of the one or more ancillary tokenization requests reduces overall response time (Campos: Paragraph(s) 0141, 0189, 0269 teach(es) The actions depicted can be performed in the order shown or in a different order, and two or more of the actions can be performed in parallel).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Dill to incorporate the teachings of Campos for in parallel and wherein parallel transmission of the one or more ancillary tokenization requests reduces overall response time.
There is motivation to combine Campos into Dill because Campos’s teachings of parallel processing would facilitate reducing overall response time (Campos: Paragraph(s) 0141, 0189, 0269).
However, the combination of Dill and Campos does not explicitly teach asynchronously.
Course from same or similar field of endeavor teaches receiving.. one or more ancillary tokenization responses asynchronously.. (Course: Paragraph(s) 0180, 0037 teach(es) process model includes an asynchronous service request and then a synchronous service request; Asynchronous service requests and asynchronous client requests include a correlation key and any response to the asynchronous service request or asynchronous client request, as appropriate, includes the correlation key).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Dill and Campos to incorporate the teachings of Course for ‘asynchronously’.
There is motivation to combine Course into the combination of Dill and Campos because Course’s teachings of synchronous and asynchronous service would facilitate providing service (Course: Paragraph(s) 0180, 0037).
Regarding Claim 2, the combination of Dill, Campos, and Course teaches all the limitations of claim 1 above; and Dill further teaches wherein the primary tokenization request is an application programming interface (API) request (Dill: Paragraph(s) 0040, 0070, 0108 teach(es) the token requestor can request the issuance of a token via an API (Application Programming Interface) messaging or a batch request).
Regarding Claims 3 and 12, the combination of Dill, Campos, and Course teaches all the limitations of claims 1 and 11 above; and Dill further teaches wherein the primary tokenization request comprises: sensitive data (Dill: Paragraph(s) 0053, 0103 teach(es) because each token may be associated with a single device, one PAN or account (i.e., sensitive data associated with the user) may have multiple tokens associated with it, where each PAN may have a different token for the different devices that may be used to initiate a transaction associated with the PAN using a specific token; a token requestor may provide an account identifier (e.g., a PAN) and an expiration date with a request for a new token).
Regarding Claims 5 and 14, the combination of Dill, Campos, and Course teaches all the limitations of claims 3 and 12 above; and Dill further teaches wherein each of the one or more ancillary tokenization requests comprises the sensitive data (Dill: Paragraph(s) 0053, 0103 teach(es) because each token may be associated with a single device, one PAN or account (i.e., sensitive data associated with the user) may have multiple tokens associated with it, where each PAN may have a different token for the different devices that may be used to initiate a transaction associated with the PAN using a specific token; a token requestor may provide an account identifier (e.g., a PAN) and an expiration date with a request for a new token).
Regarding Claims 6 and 15, the combination of Dill, Campos, and Course teaches all the limitations of claims 3 and 12 above; and Dill further teaches wherein the primary tokenization request further comprises supplemental information (Dill: Paragraph(s) 0053, 0057 teach(es) device information (i.e., supplemental information) may be stored in the token vault and used to ensure that the device used in a transaction is associated with the token that is being used in the transaction).
Regarding Claims 7 and 16, the combination of Dill, Campos, and Course teaches all the limitations of claims 6 and 15 above; and Dill further teaches wherein the supplemental information comprises at least one of: a payment vehicle expiration date, an address, and a card security code (Dill: Paragraph(s) 0061, 0144, 0103 teach(es) a token expiration date may match the underlying account identifier's (e.g., PAN's) expiration date; a token requestor may provide an account identifier (e.g., a PAN) and an expiration date with a request for a new token).
Regarding Claims 8 and 17, the combination of Dill, Campos, and Course teaches all the limitations of claims 6 and 15 above; and Dill further teaches wherein each of the one or more ancillary tokenization requests comprises the sensitive data, and at least one of the one or more ancillary tokenization requests further comprises supplemental information (Dill: Paragraph(s) 0083, 0092, 0128, 0152, 0201 teach(es) the provisioning request message may include a PAN (i.e., sensitive data), a transaction amount, a transaction date and time, an expiration date (i.e., supplemental information), a merchant type, an acquirer's country code, a POS entry mode code (e.g., manual key entry, contactless device read, etc.), an acquirer's identifier code, an AVS result code, a CVV2 result code, a CAW result code, CAV data, and any other relevant data).
Regarding Claims 9 and 18, the combination of Dill, Campos, and Course teaches all the limitations of claims 8 and 17 above; and Dill further teaches wherein each of the one or more output token vaults generates an output token that corresponds to the sensitive data, and at least one of the one or more output token vaults generates an output token that corresponds to the sensitive data and the supplemental information (Dill: Paragraph(s) 0053, 0055 teach(es) because each token may be associated with a single device, one PAN or account may have multiple tokens associated with it, where each PAN may have a different token for the different devices that may be used to initiate a transaction associated with the PAN using a specific token. This provides additional security for transactions because network token systems have additional information to validate in order to control the use of sensitive information in a transaction processing system; the token attributes may include a type of token, frequency of use, token expiration date and/or expiration time, a number of associated tokens, a transaction life-cycle expiration date, and any additional information that may be relevant to any entity within a transaction processing system).
Regarding Claims 10 and 19, the combination of Dill, Campos, and Course teaches all the limitations of claims 1 and 11 above; and Dill further teaches wherein the upstream entity is an intermediary system that is not a merchant system (Dill: Paragraph(s) 0225 teach(es) an enhanced account verification request may be used to allow acquirers to request that a network token system provision a token on their behalf or on behalf of a merchant or other upstream entity in the transaction processing system).
Claim(s) 4 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dill in view of Campos and Course, as applied to claims 3 and 12 above, and in further view of Patterson (US 20160232527 A1; already of record in IDS).
Regarding Claims 4 and 13, the combination of Dill, Campos, and Course teaches all the limitations of claims 3 and 12 above; however the combination does not explicitly teach further comprising: determining the one or more output token vaults using one or more output token service provider configuration identifiers.
Patterson from same or similar field of endeavor teaches further comprising: determining the one or more output token vaults using one or more output token service provider configuration identifiers (Patterson: Paragraph(s) 0025-0026, 0022 teach(es) a token request message may include payment credentials, mobile device identification information (e.g. a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider (i.e., output token service provider configuration identifiers), a merchant identifier, a cryptogram, and/or any other suitable information; A token response message may also include a payment token, mobile device identification information (e.g. a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider (i.e., output token service provider configuration identifiers), a merchant identifier, a cryptogram, and/or any other suitable information; a token service system (e.g., token issuer or token provider) can facilitate requesting, determining (e.g., generating) and/or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g. token vault)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Dill, Campos, and Course to incorporate the teachings of Patterson for further comprising: determining the one or more output token vaults using one or more output token service provider configuration identifiers.
There is motivation to combine Patterson into the combination of Dill, Campos, and Course because the token requestor can send a request to the token issuer to authenticate the token, or provide a number of management functions regarding the lifecycle of the token, and the token issuer may communicate with an issuer or payment processing network to perform some or all of these functions. The information identifying the token issuer or tokenization service provider would help to perform such processes (Patterson: Paragraph(s) 0053).
Response to Arguments
Applicant's arguments filed March 30, 2026 have been fully considered but they are not persuasive.
Regarding applicant’s argument under Claim Rejections - 35 USC § 101 that “the claims, as amended, provide a technical improvement by enabling the token exchange service system to process multiple tokenization requests concurrently and handle responses asynchronously, thereby significantly reducing overall processing time and improving throughput compared to conventional sequential token processing systems,” examiner respectfully argues that, as discussed in the interview, the concurrent processing of multiple ancillary tokenization requests and the asynchronous processing of ancillary tokenization responses need to be provided with more technical details and contexts of them to overcome the rejections.
Regarding applicant’s argument under Claim Rejections - 35 USC § 102 that Dill does not teach “transmitting, by the token exchange service system, the one or more ancillary tokenization requests in parallel to respective one or more output token vaults, wherein parallel transmission of the one or more ancillary tokenization requests reduces overall response time” and “receiving, by the token exchange service system, one or more ancillary tokenization responses asynchronously from the respective one or more output token vaults”, examiner respectfully argues that the combination of Dill, Campos, and Course teaches the features as stated above with respect to the 103 rejections (See at least Campos: Paragraph(s) 0141, 0189, 0269; and Course: Paragraph(s) 0180, 0037).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Miller (WO 2018170504 A1) teaches Unified Control Of Privacy-Impacting Devices, including a GUID or other designator that represents a unique tag possessed only by the particular privacy rule access token.
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 CLAY LEE whose telephone number is (571)272-3309. The examiner can normally be reached Monday-Friday 8-5pm EST.
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, Neha Patel can be reached at (571)270-1492. 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.
/CLAY C LEE/Primary Examiner, Art Unit 3699
Prosecution Insights