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 .
Status of Claims
This action is in reply to the Applicant Response filed on 6/12/2026.
Claims 18-37 have been added.
Claims 1-17 have been canceled.
Claims 18-37 are currently pending and have been examined.
This action is made Non-FINAL.
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 18-37 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more.
Under the broadest reasonable interpretation, the following claim terms are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. MPEP § 2111.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03) Claim 1 and 18 recites a process, which is a statutory category of invention (Step 1: YES). Claim 11 recites an apparatus (product), which is a statutory category of invention (Step 1: YES).
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a)). Yes.
The claims are analyzed to determine whether it is directed to a judicial exception. The following claims identify the limitations that recite additional elements in bold and the abstract idea without bold. Underlined claim limitations denote newly added claim limitations:
Claims, 18, 25 and 32 recite a method comprising: receiving, by a processing network computer from a resource provider computer for a transaction, a first transaction authorization request message that includes a digital identity certificate including identity information and transaction information associated with the transaction; determining, by the processing network computer, a token associated with the identity information from a plurality of tokens associated with the identity information based at least in part on the transaction information and the digital identity certificate; retrieving, by the processing network computer, the token; generating, by the processing network computer, a second transaction authorization request that includes the token; transmitting, by the processing network computer and to an authorizing entity computer, the second transaction authorization request; receiving, by the processing network computer and from the authorizing entity computer, a first transaction authorization response message generated based at least in part on the token; and transmitting, by the processing network computer and to the resource provider computer, a second transaction authorization response message indicating whether the transaction was authorized. These limitations, as drafted, under its broadest reasonable interpretation, covers performance via certain methods of organizing human activity, but for the recitation of generic computer components. Under human activity, the limitations are commercial interactions, such as business relations, as well as managing interactions involving people, such as following instructions. The claims also recite a fundamental economic practice, such as mitigating risk (Applicant specification, Para. 44). Lastly, the claims recite a mental process, capable of being performed in the human mind or by pen and paper. Accordingly, the claim recites an abstract idea. The mere recitation of generic computer components in the claims do not necessarily preclude that claim from reciting an abstract idea. (Step 2A-Prong 1: Yes. The claims recite an abstract idea).
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d)). No.
The above judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements of a processing network computer, resource provider computer, storage media storing instructions, non-transitory computer readable storage media, authorizing entity computer, processors, instructions, plurality of tokens and token. The additional elements of processing network computer, resource provider computer, storage media storing instructions, non-transitory computer readable storage media, authorizing entity computer, processors, instructions, plurality of tokens and token, are just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)). The computer components are recited at such a high-level of generality (i.e. as a generic computer components) such that it amounts to no more than mere instructions to apply the exception using generic computer components, and the claims fail to recite technological detail as to how the step of the judicial exception is accomplished. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. (Step 2A-Prong 2: NO. The judicial exception is not integrated into a practical application).
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05). No.
The claims are next analyzed to determine if there are additional claim limitations that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements of (processing network computer, resource provider computer, storage media storing instructions, non-transitory computer readable storage media, authorizing entity computer, processors, instructions, plurality of tokens and token) in the claims amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer component and generally linking the use of blockchain to judicial exception cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO; The claims do not provide significantly more, and are not patent eligible).
Claim 19 recites wherein the token is associated with at least one of: an account for government benefits, a disaster relief account, a charitable assistance account, a health account, an account for disability disbursement, an account for education disbursement, an account for insurance disbursement, a pension account, or a personal bank account. These limitations are also part of the abstract idea identified in claim 18, and the additional elements of the data structure are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 18 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 18, supra.
Claim 20 recites wherein determining the token comprises: searching for an identifier of the token included in a data structure storing a set of token identifiers using at least the identity information and the transaction information. These limitations are also part of the abstract idea identified in claim 18, and the additional elements of the data structure, token and set of token identifiers are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 18 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 18, supra.
Claim 21 recites wherein the second transaction authorization request includes information included in the first transaction authorization request message. These limitations are also part of the abstract idea identified in claim 18, and is similarly rejected under the same rationale as claim 18, supra.
Claim 22 recites wherein the digital identity certificate is stored by a user device. These limitations are also part of the abstract idea identified in claim 18, and the additional elements of a user device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 18 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 18, supra.
Claim 23 recites wherein the second transaction authorization response message comprises a digital certificate corresponding to the token. These limitations are also part of the abstract idea identified in claim 18, and the additional elements of the data structure are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 18 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 18, supra.
Claim 24 recites wherein transmitting the second transaction authorization request to the authorizing entity computer is based at least in part on the token. These limitations are also part of the abstract idea identified in claim 18, and the additional elements of the authorizing entity computer and the token are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 18 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 18, supra.
Claim 26 recites wherein the token is associated with at least one of: an account for government benefits, a disaster relief account, a charitable assistance account, a health account, an account for disability disbursement, an account for education disbursement, an account for insurance disbursement, a pension account, or a personal bank account. These limitations are also part of the abstract idea identified in claim 25, and the additional elements of the authorizing entity computer and the token are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 25 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 25, supra.
Claim 27 recites wherein determining the token comprises: searching for an identifier of the token included in a data structure storing a set of token identifiers using at least the identity information and the transaction information. These limitations are also part of the abstract idea identified in claim 25, and the additional elements of the data structure, token and set of token identifiers are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 25 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 25, supra.
Claim 28 recites wherein the second transaction authorization request includes information included in the first transaction authorization request message. These limitations are also part of the abstract idea identified in claim 25, and is similarly rejected under the same rationale as claim 25, supra.
Claim 29 recites wherein the digital identity certificate is stored by a user device. These limitations are also part of the abstract idea identified in claim 25, and the additional elements of the user device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 25 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 25, supra.
Claim 30 recites wherein the second transaction authorization response message comprises a digital certificate corresponding to the token. These limitations are also part of the abstract idea identified in claim 25, and the additional elements of the token are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 25 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 25, supra.
Claim 31 recites wherein transmitting the second transaction authorization request to the authorizing entity computer is based at least in part on the token. These limitations are also part of the abstract idea identified in claim 25, and the additional elements of the authorizing entity computer and the token are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 25 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 25, supra.
Claim 33 recites wherein the token is associated with at least one of: an account for government benefits, a disaster relief account, a charitable assistance account, a health account, an account for disability disbursement, an account for education disbursement, an account for insurance disbursement, a pension account, or a personal bank account. These limitations are also part of the abstract idea identified in claim 32, and the additional elements of the token are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 32 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 32, supra.
Claim 34 recites wherein determining the token comprises: searching for an identifier of the token included in a data structure storing a set of token identifiers using at least the identity information and the transaction information. These limitations are also part of the abstract idea identified in claim 32, and the additional elements of the data structure, token and set of token identifiers are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 32 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 32, supra.
Claim 35 recites wherein the second transaction authorization request includes information included in the first transaction authorization request message. These limitations are also part of the abstract idea identified in claim 32, and is similarly rejected under the same rationale as claim 32, supra.
Claim 36 recites wherein the digital identity certificate is stored by a user device. These limitations are also part of the abstract idea identified in claim 32, and the additional elements of the user device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 32 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 32, supra.
Claim 37 recites wherein the second transaction authorization response message comprises a digital certificate corresponding to the token. These limitations are also part of the abstract idea identified in claim 32, and the additional elements of the token are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 32 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 32, supra.
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 nonobviousness.
Claim(s) 18, 19, 21, 22, 23, 24, 25, 26, 28, 29, 30, 31, 32, 33, 35, 36 and 37 are rejected under 35 U.S.C. 103 as being unpatentable over McCoy et al. (US 2021/0383378 A1, hereinafter “McCoy”) in view of Camacho Diaz (US 9,947,008 B1, hereinafter “Camacho”).
Regarding claims 18, 25 and 32, McCoy discloses method comprising:
receiving, by a processing network computer from a resource provider computer for a transaction, a first transaction authorization request message that includes a [a credential] including identity information and transaction information associated with the transaction (McCoy discloses a processing computer receiving, from a resource provider system, an authentication/authorization request message containing a portable device identifier (identity information) and transaction information; McCoy ¶¶ 0008, 0039, 0041, “receiving, by a processing computer from a resource provider system, an authentication request message comprising a cryptogram and a portable device identifier”; “An authorization request message may also comprise ‘transaction information,’ such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location”)).
;
McCoy also discloses determining, by the processing network computer, a token associated with the identity information from a plurality of tokens associated with the identity information based at least in part on the transaction information (McCoy discloses the processing computer determining an access identifier (token) associated with a portable device identifier, where the resource provider database stores mappings between identifiers, and the access identifier is retrieved based on the portable device identifier and transaction context; McCoy ¶¶ 0020, 0077, 0126, “the resource provider computer 106 may retrieve an access identifier from the resource provider database 112”; “the resource provider database 112 may store a mapping between a portable device identifier…an access identifier, an intermediate access identifier”));
retrieving, by the processing network computer, the token (McCoy discloses retrieving the access identifier (token); McCoy ¶ 0126, “the resource provider computer 106 may search the resource provider database 112 and retrieve an access identifier”));
generating, by the processing network computer, a second transaction authorization request that includes the token (McCoy discloses generating a second authorization request message containing the access identifier; McCoy ¶¶ 0008, 0128, “transmitting, by the processing computer, a second authorization request message comprising the access identifier to an authorization computer”);
transmitting, by the processing network computer and to an authorizing entity computer, the second transaction authorization request (McCoy discloses transmitting the second authorization request message to an authorization computer. (McCoy ¶ 0128));
receiving, by the processing network computer and from the authorizing entity computer, a first transaction authorization response message generated based at least in part on the token (McCoy discloses receiving a first authorization response message from the authorization computer; McCoy ¶¶ 0008, 0130, “receiving, by the processing computer from the authorization computer, a first authorization response message containing an authorization response indicator”);
and transmitting, by the processing network computer and to the resource provider computer, a second transaction authorization response message indicating whether the transaction was authorized (McCoy discloses transmitting a second authorization response message to the resource provider system indicating the authorization result. (McCoy ¶¶ 0008, 0131, “transmitting, by the processing computer to the resource provider system, a second authorization response message comprising the authorization response indicator”)).
McCoy fails to disclose That the credential in the first transaction authorization request message is a “digital identity certificate” including identity information, and determining the token based on the digital identity certificate.
However, Camacho teaches a certificate authority computer system that manages digital identity certificates, wherein a digital certificate (TCERT/PCERT) includes identity information (actual user data such as name, license number, address) and is used to validate and authorize transactions. (Camacho Abstract, “the creation and management of a user’s Digital Identity certificate”; ¶¶ 0007, 0156-0158, “the CA matches said A…Z data with said A′…Z′ data for said user…proceeds optionally to validate said data A…Z at the time of issuance of the TCERT”). Camacho further teaches that such digital identity certificates can utilize tokenized values and can be used in financial transactions. (Camacho ¶¶ 0008, 0141, “tokenized values”; “a unique secure payment gateway with multiple business transaction engine”).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified McCoy with the digital identity certificate. Doing so provides enhanced security, real-time validation, and multi-factor authentication of a user’s identity during a transaction. (Camacho ¶¶ 0003-0005, describing the need for enhanced certificate validation; ¶ 0126, “The fortified enhanced certification authority protocol corrects several issues/shortcomings”). One of ordinary skill would have been motivated to combine these teachings because both references are directed to secure transaction authorization using a processing/certificate authority computer that validates credentials and routes authorization messages to an authorizing entity, and the combination would predictably yield an improved transaction system with stronger identity assurance.
Regarding claims 19, 26 and 33, modified McCoy teaches determining the token, but fails to discloses where the token is associated with at least one of: an account for government benefits, a disaster relief account, a charitable assistance account, a health account, an account for disability disbursement, an account for education disbursement, an account for insurance disbursement, a pension account, or a personal bank account (The recited account types (government benefits, disaster relief, health, pension, personal bank account, etc.) constitute non-functional descriptive material / intended use of the token’s associated account, and are further taught by Camacho, which describes the framework applied to government, health (HIPAA/EHR), education, insurance, and personal accounts; Camacho ¶¶ 0043, 0059, 0136, “Legal 644, Education 646, Payment 648…Health 614…insurance 628”; “removing any mental diagnosis from the approved HIPAA data fields”). It would have been obvious to associate the token with any of these account types as a matter of obvious design choice / intended use.
Regarding claims 21, 28 and 35, modified McCoy discloses wherein the second transaction authorization request includes information included in the first transaction authorization request message (McCoy discloses that the authorization request messages may share data fields, wherein the second authorization request message includes information (e.g., transaction information) included in the first message; McCoy ¶¶ 0041, 0097, “an authentication request message may utilize similar or identical data fields as a subsequent authorization request message”).
Regarding claims 22, 29 and 36, modified McCoy discloses wherein the digital identity certificate is stored by a user device (Camacho teaches that certificates (PCERT/TCERT) are stored on the user’s device/machine; Camacho ¶ 0168, “The user then stores the PCERT in their machine for use anytime a Certificate is required”)).
Regarding claims 23, 30 and 37, modified McCoy teaches McCoy teaches exchanging the access identifier for the intermediate access identifier in the response so the token is not exposed. (McCoy ¶ 0131). Camacho teaches that the corresponding digital certificate is returned to the user. In combination, it would have been obvious that the second authorization response message comprises a digital certificate corresponding to the token, to avoid exposing sensitive token data to the resource provider, as taught by McCoy (¶ 0107 of the present spec analog; McCoy ¶ 0131) and Camacho).
Regarding claims 25-31, McCoy discloses a processing computer comprising a processor and a computer readable medium (memory) storing code executable to perform the recited operations. (McCoy ¶¶ 0043-0045, 0109-0110, FIG. 6). The apparatus claims are rejected under the same rationale as the corresponding method claims 18-24.
Regarding claims 32-37, McCoy discloses non-transitory computer readable media storing instructions executable by processors. (McCoy ¶¶ 0045, 0133, “a non-transitory computer readable medium that stores instructions that can be executed by a processor”). The media claims are rejected under the same rationale as the corresponding method claims 18-24.
Claims 20, 27, and 34 are rejected under 35 U.S.C. 103 as being unpatentable over McCoy in view of Camacho, and further in view of Gaddam et al. (US 2018/0359100 A1, hereinafter “Gaddam”).
Regarding claims 20, 27 and 34, modified McCoy fails to disclose wherein determining the token comprises: searching for an identifier of the token included in a data structure storing a set of token identifiers using at least the identity information and the transaction information. However, Gaddam further teaches that determining a token comprises searching a data structure (token vault/credential database) storing a set of token identifiers using identifying information, wherein token-to-credential mappings are maintained. (Gaddam ¶¶ 0032, 0088, 0114, “a token vault where the generated tokens are stored”; “link a generated payment token with a received PAN…and to store the information in the credential database”).
It would have been obvious to combine Gaddam’s token vault lookup with McCoy/Camacho to efficiently manage and retrieve tokens in a multi-token environment. (Gaddam ¶ 0059, describing multiple levels of tokenization).
Claims 24 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over McCoy in view of Camacho, and further in view of Patterson US 20160232527.
Regarding claims 24 and 31, modified McCoy fails to disclose wherein transmitting the second transaction authorization request to the authorizing entity computer is based at least in part on the token. However, Patterson discloses a second authorization request that is sent onward via transport computer network 140 that is comprised by a token (Claim 8 and Claim 13; See also arrows back and forth between 170 to token issuer 160).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified McCoy with the second transaction authorization request that based in part on the token. Doing so creates efficiency in the transaction system and increases security of the authorization message as it pertains to a token.
Response to Arguments
Applicant's arguments filed 6/12/2026 have been fully considered but they are not persuasive.
Applicant argues that the currently recited claims are a practical application. Examiner disagrees. The currently recited processing network computer, resource provider computer, authorizing entity computer, acts of retrieving, generating, transmitting specific messages, retrieving the token, and the digital identity certificate are recited at a high level of generality. The currently recited claims do not meaningfully limit the abstract idea, and simply implement selection of an identity-linked token and routing authorization messages on a computer.
The focus of the claims is not on such an improvement in computers as tools, but on certain independently abstract ideas that use computers as tools. The claims here are not directed to a specific improvement to computer functionality. Rather, they are directed to the use of conventional or generic technology in a well-known environment, without any claim that the invention reflects an inventive solution to any computer specific problem. More specifically, the claims are limited to a business solution to a technical problem, not a technical solution to a technical problem.
In Enfish, the court evaluated the patent eligibility of claims related to a self-referential database. Id. The court concluded the claims were not directed to an abstract idea, but rather an improvement to computer functionality. In contrast, the current claims are not directed to an improvement to computer functionality and instead merely recite the computer elements at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
Similarly, in DDR Holdings LLC v. Hotels.com, LP, the claims were found eligible as they reflected improvements to the functioning of a computer, i.e. a modification of conventional Internet hyperlink protocol to dynamically produce a dual-source hybrid webpage. In contrast, the current claims do not contain limitations reflective of an improvement to computer functionality and instead merely recite the computer elements at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
The currently recited claims are dissimilar from Example 35, Claim 2. Claim 2 of Example 35 was found eligible because it recited a specific combination of technical steps in a non-conventional way in a banking context; generating a random code, reading an encrypted image generated on a device in response to the code, decrypting the code, and analyzing the potential match. The currently recited claims do not involve encryption, and do not improve the underlying computer network or security architecture or token-selection.
The currently recited claims are dissimilar from Example 41, Claim 2. Example 41 was found eligible as it integrated math concepts of encoding messages into ciphertext into a practical application to transmit a ciphertext word signal to a computer terminal, securing network communications. Specifically, as noted in the Example, “the combination of elements use the mathematical formulas and calculations in a specific manner that sufficiently limits the use of the mathematical concepts to the practical application of transmitting the ciphertext word signal to a computer terminal over a communication channel.” The currently recited claim 18 does not integrate the abstract idea into a practical application and does not recite any math formula in a specific, limiting technical way that secures communications, as the token-selection and messaging is an abstract business activity using a conventional computer network.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Laxinarayanan US 20150046338 discloses that an authorization requests to the payment processing network sends to the issuer computer “may also include the token or an indication that the transaction involved a token,” and that a token assurance level code may be included to inform the issuers decision, which is similar to Claim 24 and 31 of the recited claims.
Dill US 20150032626 discloses a server computer receiving an authorization request with a payment token, determining the real account identifier, generating a modified authorization request, and transmitting the modified authorization request to the issuer for approval. This is similar to Claim 24 and 31 and Steps 346-348, where an intermediary service receives a token-bearing request and transmits downstream authorization request to the issuer (authorizing entity).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON M DUCK whose telephone number is (469)295-9049. The examiner can normally be reached 8am - 5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Michael Anderson can be reached at 571-270-0508. 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.
/BRANDON M DUCK/Examiner, Art Unit 3693
Prosecution Insights