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 the Claims
The office action is being examined in response to the amendments submitted by the applicant on February 20, 2025.
Claims 1-2, 4-7, 9-12, 14-17, 19-20 have been amended and are hereby entered.
Claims 8 and 18 are cancelled.
Claims 21 and 22 are newly added and are hereby entered.
Claims 1 -7, 9–17, and 19 – 22 are pending and have been examined.
This action is made FINAL.
The examiner would like to note that this application is now being handled by examiner Michael Anderson.
Response to Arguments
Applicant's arguments filed February 20, 2025 have been fully considered but they are not persuasive.
Argument 1: Business Methods Are Not Categorically Excluded
Applicant argues that “software and business methods are not excluded categories of subject matter” (citing MPEP § 2106.04(a)) and that business methods are “at least in some circumstances, eligible for patenting under § 101.”
Examiner’s Response: The Examiner does not dispute that business methods are not categorically excluded from patent eligibility. The rejection does not assert that the claims are ineligible because they are business methods. Rather, the rejection identifies specific claim limitations that recite an abstract idea — namely, the commercial or legal interaction of authenticating a transaction, classifying it as safe or unsafe, approving or denying the transaction, and managing a pool of trusted verification intermediaries. The question is not whether business methods can be eligible, but whether these particular claims integrate their recited abstract idea into a practical application or recite significantly more. As set forth below, they do not.
Argument 2: CosmoKey — “Technical Solution to a Security Problem”
Applicant argues that, like CosmoKey, the claims recite “a technical solution to a security problem in networks and computers” and “a specific improvement to authentication that increases security, prevents unauthorized access … and can advantageously be carried out with mobile devices of low complexity.”
Examiner’s Response: The Examiner has considered Applicant’s reliance on CosmoKey and finds it distinguishable. In CosmoKey, the claims recited a specific technical mechanism — namely, monitoring user interaction with a device to detect a status change from a “locked” to an “unlocked” state as a local authentication factor, which was then communicated to a remote server. This was a particular implementation tied to a specific device functionality (device lock/unlock state monitoring) that the court found constituted a technical improvement to the authentication process itself.
By contrast, the present claims do not recite any specific technical mechanism for authentication. The claims recite: receiving a request, selecting a verifier, transmitting data, receiving a determination, classifying the request, and updating verifiers — all at a high level of generality without specifying how authentication is technically performed, what specific algorithm the verifier applies, what particular architecture the secure execution environment implements, or how the system’s technical functioning is improved. The claims recite what is done (authenticate, classify, update) but not how it is done in a technically specific manner. The “secure execution environment” is recited as a generic environment in which the verifier operates — the claim does not specify any particular TEE architecture, hardware configuration, attestation protocol, or technical mechanism that distinguishes it from merely using a TEE as a tool to perform the otherwise abstract verification. The claims lack the technical specificity that rendered CosmoKey eligible.
Furthermore, the specification does not describe the claimed combination as providing a specific technical improvement to computer functionality with supporting technical evidence (e.g., reduced latency, improved throughput, enhanced cryptographic security through a novel protocol). Rather, the specification describes a general-purpose transaction authentication framework. The statement at ¶[0203] that the system acts “as safeguards to protect blockchain wallets, NFT marketplaces, and various token-storage entities from abuse” describes the purpose or desired outcome of the invention (preventing fraud), not a technical improvement to how a computer functions. Fraud prevention is the motivation for the invention — it does not alone establish that the claims recite a technological improvement. See MPEP § 2106.05(a) (the improvement must be to the functioning of the computer itself or another technology, not merely using a computer to improve a business process).
Argument 3: USPTO Example 35 — Non-Conventional Verification Process
Applicant argues that, like Example 35, claim 1 involves “utilizing technical means to unconventionally validate transactions with a multi-factor authentication system.”
Examiner’s Response: The Examiner has considered Applicant’s reliance on Example 35 and finds it distinguishable. In Example 35, the claim was found eligible because it recited a specific ordered combination of steps that operated in a “non-conventional and non-generic arrangement” — specifically, the combination of using a particular type of customer data from a bank card, applying a specific type of wireless protocol-based analysis, and performing a particular matching algorithm between the analyzed data and stored customer profile data. The example noted that this particular combination was not well-understood, routine, or conventional.
The present claims, by contrast, recite a general framework: receive request → select verifier → transmit data → receive determination → classify → update verifiers. This is the concept of delegated multi-factor verification, not a specific non-conventional implementation thereof. The claims do not recite:
A specific type of data analysis performed by the verifier
A specific algorithm or protocol for authentication
A specific technical mechanism for how the “secure execution environment” contributes to the verification beyond being a generic secure processing location
A specific non-conventional arrangement of steps that distinguishes the process from conventional delegated authentication
Applicant characterizes the claims as a “multi-factor authentication system,” but the claims recite what factors are checked (authentication value + security policy compliance) without specifying how this is done in a technically non-conventional manner. Conventional authentication systems routinely verify both credentials and policy compliance ; the claims do not articulate what makes this particular combination non-conventional at the technical level.
Argument 4: USPTO Example 41 — Secure Data Transfer Between Devices
Applicant argues that, like Example 41, claim 1 “securely authenticates data transfers between devices.”.
Examiner’s Response: The Examiner has considered Applicant’s reliance on Example 41 and finds it distinguishable. Example 41 involved a specific technical process for cryptographically securing communications; namely, a particular method of generating and applying cryptographic values to message content in a defined sequence that provided both source authentication and content integrity verification through a specific cryptographic protocol. The example was found eligible because the specific technical operations (generating integers, applying them in a particular cryptographic scheme) constituted a technical improvement to secure communications.
The present claims do not recite any specific cryptographic protocol, specific data transformation, or specific technical mechanism for securing communications. The claims recite “cryptographic transfer” at a high level without specifying the cryptographic operations involved. The claims recite “authentication value” generically. The verification process is described functionally (determine authentication, determine compliance) without specifying the technical implementation. Simply reciting that a process relates to “security” or involves “cryptographic” elements does not make it analogous to Example 41’s specific cryptographic protocol implementation.
Argument 5: Claims Are Directed to Improving Transaction Security
Applicant argues that “the claims, as amended, are an improvement to the technical field of transaction security, directed to the practical application of multi-factor authentication.”
Examiner’s Response: Applicant’s characterization of the claims as “an improvement to the technical field of transaction security” is conclusory and unsupported by the claim language or specification. The relevant inquiry under MPEP § 2106.05(a) is whether the claims recite an improvement to the functioning of a computer or to another technology or technical field. An improvement to a business process (making transactions more secure from a business perspective) is not the same as an improvement to technology (making a computer system function better, faster, or more efficiently).
The specification does not provide:
Technical comparisons demonstrating that the claimed method provides improved computational performance, reduced processing overhead, lower latency, or other technical metrics compared to prior systems
A specific technical problem with prior computer systems that is solved by a specific technical mechanism recited in the claims
Evidence that the specific combination of elements claimed improves the functioning of any computer component
Rather, the specification describes a business objective (preventing fraudulent transactions) achieved by applying known computing components (digital wallets, processors, TEEs, ML models, blockchains) in their conventional capacities. The fact that a system performs authentication better from a security/fraud-prevention standpoint does not establish a technological improvement to computer functionality. See MPEP § 2106.05(a) (“It is important to note that … an improvement in the judicial exception itself is not an improvement in technology”).
Applicant’s argument that the system “can advantageously be carried out with mobile devices of low complexity” actually undercuts the argument for technical improvement; it suggests that no specialized hardware or novel computer architecture is required, which is consistent with the Examiner’s position that the claims merely apply the abstract idea using generic computing components.
Argument 6: Any Judicial Exception Is “Secondary” to Verification/Security
Applicant argues that “any judicial exception (i.e., processing the transactions themselves) comes secondary to the primary objective of evaluating whether the data associated with the transactions is valid/safe.”
Examiner’s Response: The Examiner respectfully disagrees with Applicant’s characterization. The abstract idea identified in the rejection is not merely “processing transactions.” The abstract idea encompasses the entire process of authenticating a transaction request — receiving the request, selecting a trusted verifier, obtaining verification determinations, classifying the request as safe/unsafe, approving or denying, and managing the verifier pool. The “evaluating whether data is valid/safe” is itself the abstract idea of commercial interaction (transaction authentication and risk mitigation), not something separate from it. Applicant’s argument essentially recharacterizes the abstract idea as the practical application, which is circular reasoning.
The fact that the claims are primarily directed to verification/authentication does not make them eligible — authentication of transactions for commercial purposes has long been recognized as a fundamental economic practice and commercial interaction. The question remains whether the claims recite a specific technical implementation of that authentication that integrates the abstract idea into a practical application, and as discussed above, they do not.
Conclusion on § 101
For the foregoing reasons, the rejection under 35 U.S.C. § 101 is maintained. The claims recite the abstract idea of authenticating a transaction (a commercial or legal interaction), and the additional elements; digital wallet, device, tokens, cryptographic transfer, secure execution environment, processor, non-transitory computer-readable medium ; are recited at a high level of generality as generic computing components performing their conventional functions (receiving, transmitting, processing, storing data). The claims do not integrate the abstract idea into a practical application, nor do they recite significantly more than the abstract idea.
Response to Arguments Regarding the § 103 Rejection
Applicant argues that neither Todasco nor Gaur discloses: (1) “the request verifier executes in a secure execution environment” or (2) “updating the plurality of approved verifiers in response to classification of the request.”
Examiner’s Response: Applicant’s arguments with respect to the § 103 rejection have been considered and are persuasive. The previously applied combination of Todasco and Gaur does not teach or suggest the specific configuration of selecting a request verifier from a plurality of approved verifiers executing in a secure execution environment, nor the dynamic updating of the approved verifier pool in response to classification outcomes, as now recited in amended Claims 1 and 11.
Accordingly, the rejection under 35 U.S.C. § 103 based on Todasco in view of Gaur is withdrawn.
However, the claims remain rejected under 35 U.S.C. § 101 as set forth above, and new rejections under 35 U.S.C. § 112 are applied as set forth in this Office action.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 22 is rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor,. It is unclear if the applicant is trying to claim the system of claim 21 and further delineate a wherein clause or if the applicant is trying to claim the method of claim 22 with an additional wherein clause. For the purposes of examination, the Examiner interpreted the system of claim 21 with the wherein clause to be the method of claim 21 further explaining a wherein clause.
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-7, 9-17, and 19-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. A Section 101 analysis is below.
Step 1
Step 1 – are the claims directed to a process, machine, manufacture or composition of matter. The method of Claims 1 and 21/22 and the CRM of Claim 11 are within the statutory categories of invention. See MPEP § 2106.03.
Step 2A, Prong One
Step 2A, Prong One – do the claims recite a judicial exception, which is an abstract idea enumerated in the MPEP § 2106.04(a), a law of nature, or a natural phenomenon. Using the text of Claim 1 as an example, independent Claims 1 and 11 recite:
A method for authenticating a token-based action, the method comprising:
receiving, from a digital wallet, a request to perform a cryptographic transfer of at least one token from a device;
selecting, from a plurality of approved verifiers, a request verifier, wherein the request verifier executes in a secure execution environment;
transmitting a collection of data to the request verifier, wherein the collection of data: corresponds to the cryptographic transfer; and comprises a recipient identifier and an authentication value for a requesting user;
receiving, from the request verifier, a validity confirmation for the cryptographic transfer, wherein the validity confirmation comprises: a first determination, concerning whether the request is properly authenticated via the authentication value; and a second determination, concerning whether the request complies with at least one security policy associated with at least one of the at least one token or an entity associated with the digital wallet;
classifying the request, wherein classifying the request: is based, at least in part, on at least one of the first determination or the second determination, and comprises: when the request is concluded to be unsafe, rejecting the request; and when the request is concluded to be safe, processing the request; and
updating the plurality of approved verifiers in response to classification of the request.
Referring to the limitations above, independent Claims 1 and 11 each recite an abstract idea enumerated in MPEP § 2106.04(a). Specifically, Claims 1 and 11 are each directed to the abstract idea of certain methods of organizing human activity — commercial or legal interactions. More specifically, as drafted, each of Claims 1 and 11 recites the commercial or legal interaction of authenticating a transaction and mitigating settlement risk — i.e., receiving a transfer request, selecting a verifier to assess the request, determining whether the request is properly authenticated and complies with security policies, classifying the request as safe or unsafe, approving or denying the request accordingly, and updating the pool of approved verifiers. This is analogous to a financial intermediary (e.g., a bank officer, compliance agent, clearinghouse, or escrow service) receiving a transfer request, consulting a trusted third party to verify the request’s legitimacy and compliance with established rules, approving or denying the transaction based on the third party’s assessment, and updating which third parties remain trusted based on their track record. See MPEP § 2106.04(a)(2)(II)(B) noting that a transaction performance guarantee and mitigating settlement risk are examples of commercial or legal interactions. See also MPEP § 2106.04(a)(2)(II)(A) noting fundamental economic practices including mitigating risk.
Accordingly, each of Claims 1 and 11 are directed to the judicial exception of an abstract idea.
Regarding new independent Claim 21, this claim recites substantially the same abstract idea as Claim 1, with additional specificity that the verifier is a machine learning model, processing the request includes decrypting the request, and updating includes removing the verifier when “contradicted by a later response” and further training verifiers. These additions describe how the abstract verification/classification is performed (using ML, via decryption) and how the verifier pool is managed (removal/retraining based on outcomes) — but the underlying concept remains authenticating a transaction, classifying it as safe/unsafe, and managing the approved verifiers accordingly. This is still a commercial or legal interaction — transaction authentication and settlement risk mitigation. Accordingly, Claim 21 is also directed to the judicial exception of an abstract idea.
Step 2A, Prong Two
Step 2A, Prong Two – do the claims recite additional elements that integrate the judicial exception into a practical application. Integration of the judicial exception into a practical application requires an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. See MPEP § 2106.04(d).
Regarding Claims 1 and 11, these claims recite the additional elements of a device, a digital wallet, tokens (including cryptographic transfer thereof), a secure execution environment, and (in Claim 11) a non-transitory computer-readable medium comprising instructions configured to cause a processor to perform the process. The claims use these additional elements to perform authenticating a token-based action by: receiving a request to perform a cryptographic transfer; selecting a request verifier from approved verifiers, wherein the verifier executes in a secure execution environment; transmitting data to the verifier; receiving a validity confirmation comprising determinations regarding authentication and policy compliance; classifying the request as safe or unsafe; and updating the plurality of approved verifiers.
These additional elements are recited at a high level of generality (e.g., to receive, store, transmit, or process data) such that they amount to no more than mere instructions to apply the exception using generic computer components. See MPEP § 2106.05(f). The digital wallet is recited generically as a source of a request. The device is a generic computing device. The secure execution environment is recited as a generic computing environment in which the verifier executes — the claim does not specify any particular architecture, hardware configuration, or technical implementation of the TEE that would distinguish it from its conventional use as a general-purpose secure processing environment. The claim merely uses the TEE as a tool to perform the otherwise abstract verification. The cryptographic transfer and token terminology merely link the abstract idea to the particular technological field of blockchain/cryptocurrency. See MPEP § 2106.05(h) (field-of-use limitations). The “updating the plurality of approved verifiers” limitation describes managing which verifiers remain in the approved pool — this is part of the abstract process of managing the verification system (i.e., managing which trusted intermediaries remain approved) and does not transform the nature of the claim into a technological improvement.
The claims do not recite an improvement to the functioning of a computer or to any other technology or technical field (MPEP § 2106.05(a)); do not apply the judicial exception with or by use of a particular machine (MPEP § 2106.05(b)); do not effect a transformation or reduction of a particular article to a different state or thing (MPEP § 2106.05©); and do not apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment (MPEP § 2106.05(e)).
It is further noted that the claimed invention as recited in Claims 1 and 11 does not pertain to an improvement in the functioning of the computer components themselves or a technological solution to a technological problem. The specification does not describe the claimed combination as providing a specific technical improvement to computer functionality. Rather, the specification describes a general-purpose transaction authentication framework. See MPEP § 2106.05(f)(1) discussing when the claim recites only the idea of a solution or outcome — i.e., the claim fails to recite details of how a solution to a problem is accomplished — this does not show integration into a practical application. See MPEP § 2106.05(f)(2) discussing when the claim invokes computers or other machinery merely as a tool to perform an existing process including use of a computer or other machinery for economic tasks, this does not show integration into a practical application.
Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Regarding Claim 21, this claim recites additional elements of a machine learning model (as the request verifier) executing in a secure execution environment, and decrypting the request. These elements do not change the analysis. The machine learning model is recited generically — the claim does not describe a specific model architecture, specific training methodology, specific inputs/outputs, or any improvement to ML technology itself. It merely uses an ML model as a tool to perform the abstract classification/verification task. See MPEP § 2106.05(f). The decryption step is recited at a high level without any specific cryptographic algorithm, key management protocol, or technical improvement to decryption technology. It is merely a data processing step (converting encrypted data to usable form) incidental to performing the abstract transaction authentication. The feedback loop of removing contradicted verifiers and further training the remaining verifiers describes the abstract management of a verification pool (i.e., which trusted intermediaries to retain) and does not recite any specific technical mechanism that would amount to an improvement to computer technology. Accordingly, Claim 21 does not integrate the abstract idea into a practical application.
Step 2B
Step 2B – do the claims recite additional elements that amount to significantly more than the judicial exception. See MPEP § 2106.05.
Regarding Claims 1, 11, and 21, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a device, digital wallet, tokens/cryptographic transfer, secure execution environment, non-transitory computer-readable medium, processor, machine learning model, and decrypting amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. See MPEP § 2106.05(f).
The computer components implementing the abstract idea are generic in view of at least Applicant’s specification: ¶[0084] (user devices may be implemented using any class of consumer electronics device); ¶[0119]–[0120] (TEEs such as ARM TrustZone™ or Intel SGX™ are known environments used for integrity assurance); ¶[0220] (trustees may be implemented using machine learning models, AI, expert systems); ¶[0066] (digital wallets securely store NFTs); ¶[0228] (requests may be encrypted). These disclosures demonstrate that the additional elements are well-understood, routine, and conventional in the art.
Furthermore, the receiving and transmitting steps constitute insignificant extra-solution activity — mere data gathering and output. See MPEP § 2106.05(g). These activities are also well-understood, routine, and conventional per the Symantec, TLI, OIP Techs., and buySAFE court decisions cited in MPEP § 2106.05(d)(II) (receiving or transmitting data over a network; performing repetitive calculations; electronic recordkeeping; storing and retrieving information in memory).
Accordingly, Claims 1, 11, and 21 do not recite additional elements that amount to significantly more than the judicial exception.
Dependent Claims
In view of the above analysis, independent Claims 1, 11, and 21 are not patent eligible. Dependent Claims 2-7, 9-10, 12-17, 19-20, and 22 do not cure the deficiencies in their respective base claims as set forth below.
Claims 2 and 12 further refine the abstract idea by specifying actions taken upon rejection (removing authentication information, requiring second-factor authentication, transmitting a rejection, performing direct verification) or upon processing (transmitting to a blockchain node, transmitting acceptance to the device). These limitations describe alternative ways of performing the abstract approval/denial of the commercial transaction. The blockchain node is a generic computing element recited at a high level of generality that merely links the abstract idea to the blockchain technological field. See MPEP § 2106.05(h).
Claims 3 and 13 specify that the token is a non-fungible token (NFT). This merely narrows the field of use to a particular type of digital asset and does not add an additional element that integrates the exception or provides significantly more. See MPEP § 2106.05(h).
Claims 4 and 14 further refine the abstract idea by specifying that the authentication value comprises a digital signature, message authentication code, one-time code, password, or personal identification number, and that the first determination verifies whether the authentication value corresponds to an owner. These limitations describe conventional authentication mechanisms used as tools to perform the abstract verification of a commercial transaction. See MPEP § 2106.05(f).
Claims 5 and 15 further refine the abstract idea by specifying that the classification involves deriving a risk score based on user identity or potential maliciousness and comparing to a threshold. Deriving a risk score and comparing it to a threshold to approve or deny a transaction is part of the fundamental economic practice of risk mitigation in commercial transactions. It does not integrate the abstract idea into a practical application or provide significantly more.
Claims 6 and 16 further refine the abstract idea by specifying that each verifier has a trust score and verifiers below a threshold are removed. Managing the trustworthiness of intermediaries and removing underperforming ones is part of the abstract commercial process of maintaining a reliable verification system. This does not add a technological improvement or significantly more.
Claims 7 and 17 specify that the request verifier is further trained on authentications performed by other verifiers. Training a model on prior evaluations is a conventional machine learning operation recited at a high level of generality, used merely as a tool to perform the abstract verification task. See MPEP § 2106.05(f).
Claims 9 and 19 specify additional data elements in the collection (valuation, time limit, nonce, metadata file, request header). These merely describe the type of data gathered and transmitted — insignificant extra-solution activity. See MPEP § 2106.05(g).
Claims 10 and 20 further refine the abstract idea by specifying the content of the security policies (banlists, allowlists, IP address checks, valuation maximums, time-of-day restrictions). These are descriptions of rules/criteria applied during the abstract transaction authentication process — they describe what policies a human compliance officer would apply when approving or denying a commercial transaction and do not add technological improvements.
Claim 22 specifies that the request is encrypted such that it is incompatible with a particular blockchain and that processing comprises decrypting the request. Decryption is a well-understood, routine, and conventional computing operation. See Applicant’s specification ¶[0228]. The limitation merely describes a data formatting/conversion step as part of the abstract transaction processing. The reference to blockchain incompatibility is a field-of-use limitation. See MPEP § 2106.05(h).
Accordingly, Claims 2-7, 9-10, 12-17, 19-20, and 22 do not recite additional elements that integrate the abstract idea into a practical application or amount to significantly more than the judicial exception.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure includes: US 20250055700; US 20240428306; US 20240346087; US 12041067; US 20240104653; US 20230419302; US 20230419309; US 20230376926; US 11824864; US 20230298001; US 11538028; WO 2022241083; WO 2022232180; US 20220343015; WO 2022212801; US 20220172198; US 11301765; US 20220075845; US 20220058651; US 20220036323; US 20220014543; US 20210279695; US 20210248258; US 20210248214; US 20210243198; US 20210233078; US 20210217001; US 20210182850; US 20210173897; US 11019076; US 20210082044; US 20210058395; US 20200051084; US 20190034936; and US 20180005235.
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 MICHAEL W ANDERSON whose telephone number is (571)270-0508. The examiner can normally be reached Monday - Thursday 9am-4pm.
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, Tariq Hafiz can be reached at (571) 272-5350. 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.
Mike Anderson
Supervisor Patent Examiner
Art Unit 3693
/Mike Anderson/Supervisory Patent Examiner, Art Unit 3693
Prosecution Insights