DETAILED ACTION
Claim Status
This is first office action on the merits in response to the application filed on 12/18/2024.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 12/18/2024 is(are) in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory 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 nonstatutory 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 nonstatutory 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 nonstatutory 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 eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-14 of U.S. Patent No. 12,217,243. Although the claims at issue are not identical, they are not patentably distinct from each other because it recites the additional features of providing, by a token exchange service system, a portal to a merchant system through which the merchant system provides output token service provider configuration identifiers and activates token service providers corresponding to the output token service provider configuration identifiers; receiving, by the token exchange service system, the output token service provider configuration identifiers and an activation of the token service providers corresponding to the output token service provider configuration identifiers from the merchant system via the portal; generating, by the token exchange service system, a globally unique identifier (GUID) based on the received primary tokenization request, the GUID stored in a database of the token exchange system. Since U.S. Patent No. 12,217,243 and the claims at issue of the present application perform similar functions, it would have been obvious to a person of ordinary skill in the art to modify claims 1-14 of U.S. Patent No. 12,217,243 by removing the additional features. It is well settled that omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karison, 136 USPQ 184 (CCPA 1963) Also note Ex parte Rainu, 168 USPQ 375 (Bd. App. 1969). Thus, omission of a reference element whose function is not needed would be obvious to one of ordinary skill in the art.
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 to respective one or more output token vaults; receiving, by the token exchange service system, one or more ancillary tokenization responses 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 § 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 (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 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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, 5-12, and 14-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Dill (US 20200410483 A1; already of record in IDS).
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).
Regarding Claim 2, Dill 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, Dill 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, Dill 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, Dill 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, Dill 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, Dill 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, Dill 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, Dill 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 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) 4 and 13 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 Patterson (US 20160232527 A1; already of record in IDS).
Regarding Claims 4 and 13, Dill teaches all the limitations of claims 3 and 12 above; however Dill 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 Dill 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 Dill 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).
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.
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