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 .
DETAILED ACTION
1. This office action is in response to an amendment received on 5/8/26 for patent application 18/968,665.
2. Claims 1-9 are amended.
3. Claims 17-20 are cancelled.
4. Claims 1-16 are pending.
RESPONSE TO ARGUMENTS
Applicant argues#1
The pending claims provide a technical solution to a technical problem in the field of tokenization, where data access is limited by conventional systems. The pending claims, in particular, define a data access sequence, through which friction in the technical operations is reduced through opening service links. See, [0018 of the instant application. In this way, the data accessibility is improved, through interoperability and flexibility, thereby addressing "a significant operational need within the financial technology and payment processing industry." See, Id.
In this way, the specific system recited in the pending claims interacts to provide enhanced data access, through open services, and specifically, open service API communication. The claims are directed specifically to a technical solution to a technical problem related to specific data access and interoperability.
Examiner Response
Examiner respectfully disagrees.
Applicant argued the claims present a technical improvement. Examiner does not find this argument persuasive. Applicant’s claims do not improve technology; the underlying technology remains unaffected by the claims. Applicant is addressing a business problem (steps for retrieving a primary account number using an open banking system) with a business solution. Applicant is merely using existing technology (for its intended purpose) to implement the business solution. Any improvements lie in the abstract idea itself, not in underlying technology
The additional element of the API (application programming interface) is recited at a high level of generality and operating in its ordinary capacity and is being used as a tool to implement the steps of the identified abstract idea.
The rejection is maintained.
Applicant argues#2
Here, the pending claims are directed to a sequence of technical operations, which provide for data accessibility across multiple systems. In connection with claim one, specifically, for example, the open banking system provides for accessibility between the issuer of the financial account and the token requester server system and the token service system. Based on that accessibility, specific direct operations are performed to capture consent of the cardholder, and to proliferate financial account information and that consent between the systems in order to generate and provision a dPAN.
The subsequent use of the dPAN is not what the claims are directed to, whereby the pending claims are in fact not directed to a commercial interaction.
Examiner Response
Examiner respectfully disagrees.
The claims are reciting a commercial interaction (the identified abstract idea), see the section 101 rejection below.
The rejection is maintained.
Applicant argues#3
Further, even if the claims are directed to the alleged idea, the pending claims integrate the alleged idea into a practical application and/or recite significantly more than the alleged idea.
In particular, the pending claims apply the alleged exception in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. That is, in the pending claims, an efficient sequence of ordered operations is defined which captures, through open service API calls, access to specific consented data based on a request directed to that data. That data is then leveraged between two separate systems to generate a specific PAN linked to the financial account. This was previously not enabled due to the lack of a defined data access connection. The pending claims not only eliminate this technical omission but also provide for broad interoperability between the recited systems. This is a meaningful limitation on the alleged idea, which is sufficient to confer eligibility on the pending claims. To be clear, as amended herein, the pending claims recite still further additional limitations, including, for example, operations performed through the open service API. The integration of this feature along with the other additional limitations, cited by the Office, in the pending claims, defines a unique architecture - between the open banking system, the connection request signal, the cardholder computing device, the open banking connection interface, a login screen, the token requester server system, and the token service system - which is integral to the recited operations resulting in the dPAN being transmitted to the one or more merchant/fintech applications, for use thereby. This practical application is application of the alleged idea.
Examiner Response
Examiner respectfully disagrees.
The limitations that applicant appears to be referring to, “whereby the cardholder logs-in to provide consent to share the financial account information… receive from the open banking, the authorization token and financial account information specific to the financial account, based on the consent from the cardholder to the issuer of the financial account….. generate a device primary account number (dPAN)” is part of the identified abstract idea.
The additional elements (API, the connection request signal from a financial application, the cardholder computing device, the open banking connection interface, login screen, token requestor server system, and token service system) are recited at a high level of generatilty, operating in their ordinary capacity, and are being used as a tool to implement the steps of the identified abstract idea, see MPEP 2106.05(f).
Therefore there are no additional elements that are indicative of integration into a practical application and no additional element that amount to significantly more than the identified abstract idea.
The rejection is maintained.
Applicant argues#4
The Office argues that the claims merely apply the idea to a computer, as a tool to perform the idea, and that the limitations provide insignificant extra activities. See, Office action dated Feb. 20, 2026, at p. 6-7.
Initially, it is clear in the claims, especially as amended, that the claimed subject matter is formed as an integration between the alleged idea and the specific architecture recited in claims. That is, the pending claims do not recite the alleged idea and seek to merely add the words "apply it" to a computing device. It is the specific defined interactions between the specific devices, which importantly, gain specific access to pertinent data by operation of the claim limitations. Stated another way, the claimed subject matter is ineffective and efficient without the specific underlying architecture recited in the claims. For example, the connection request signal, the authorization code, the authorization token, the token account receipt request, and the token account receipt are not divisible from the additional elements recited in the claim -- as each would be rendered undefined outside the context of the claim, the additional elements in the specific linking recited.
In this way, it is not possible for the additional elements to be mere tools for implementation of the alleged idea. The pending claims are indeed patent eligible.
Further, as it relates to inventive concept, the Office asserts there are no additional elements. See, Office action dated Feb. 20, 2026, at p. 7. It is clear that the claims recites additional elements outside of the alleged idea (i.e., as listed above), as even admitted by the Office.
Examiner Response
Examiner respectfully disagrees.
This argument has been addressed above with respect to Applicant argues#3 above.
The rejection is maintained.
Applicant argues#5
What's more, where the alleged idea is a commercial interaction, the pending claim recite still further additional elements. For example, the login screen specific to the issuer of the financial account being presented, through an open banking connection interface at the specific cardholder computing device, is an additional element. This enables the specific cardholder to provide consent for data access through login. What's more, the authorization code provides an additional element. This is evident in PEG Example, 35.
That is, Example 35 includes Claim 3, which is designated as eligible. In doing so, the reasoning provides that the combination of the steps (e.g., the ATM's provision of the random code, the mobile communication device's generation of the customer confirmation code in response to the random code, the ATM's analysis of the customer confirmation code, and the ATM's subsequent sending of a control signal to provide or prevent access to the keypad of the ATM and thus allow or prevent a transaction based on the analysis of the code) operates in a non-conventional and non-generic way to ensure that the customer's IDENTITY is verified in a secure manner that is more than the CONVENTIONAL verification process employed by an ATM alone.
In combination, these steps do not represent merely gathering data for comparison or security purposes, but instead set up a sequence of events that address unique problems associated with bank cards and ATMs.
Consistent with the above, the pending claims provide a specific, discrete sequence of operations, which leverage the connection request signal, the authorization code, the authorization token, etc., in a unique, non-conventional, and non-generic way to provide for enhanced data accessibility, through open services. In this way, the interoperability of the specific architecture recited in the claims provides a sequence of events that address the unique problems associated with data access for purposes of proceeding from access to financial account information through generation and transmission of a dPAN for use by the one or more merchant/fintech applications. Example 35 demonstrates that what is claimed is indeed patent eligible.
Examiner Response
Examiner respectfully disagrees.
In example 35, random code data was transmitted, encrypted, and displayed on the customer' s mobile device such that the ATM read the corresponding image, decrypted the image, and analyzed the decrypted data to verify the customer identity. In this case, the combination of steps set up a sequence of events that address unique problems associated with bank cards and ATMs (e.g., the use of stolen or “skimmed” bank cards and/or customer information to perform unauthorized transactions). Thus, like in BASCOM, the claimed combination of additional elements presents a specific, discrete implementation of the abstract idea. Further, the combination of obtaining information from the mobile communication device (instead of the ATM keypad) and using the image (instead of a PIN) to verify the customer' s identity by matching identification information does not merely select information by content or source, in contrast to Electric Power, but instead describes a process that differs from the routine and conventional sequence of events normally conducted by ATM verification, such as entering a PIN, similar to the unconventional sequence of events in DDR. The additional elements in claim 2 thus represent significantly more (i.e., provide an inventive concept) because they are a practical implementation of the abstract idea of fraud prevention that performs identity verification in a non‐conventional and non‐generic way, even though the steps use well‐known components (a processor and mobile communication device). Claim 2 is eligible (Step 2B: Yes). In the instant case, the claims are attempting to solve a business problem (i.e. steps for retrieving a primary account number using an open banking system) using conventional computer functions. There is no unique problem associated with any technological environment or field of use that is being solved as was the case for Example 35. The instant claims are not analogous to Example 35.
The rejection is maintained.
Applicant argues#6
Moreover, the Federal Circuit has affirmed the non-abstract, practical and eligible nature of claims, such as the pending claims presented herein.
For example, in TecSec., Inc. V. Adobe Inc., the Court determined that "the focus of the claimed advance is on improving such a data network used for broadcasting a file to a large audience, with the improvement assertedly being an efficient way for the sender to permit different parts of the audience to see different parts of the file" and that the patent claims improve basic network functioning by "enabling secure and efficient transmission to intended recipients." See, TecSec, Inc. V. Adobe Inc., 978 F. 3d 1278 (Fed. Cir. Oct. 23, 2020). In doing so, the Court affirmed the lower court's rejection of defendants' eligibility challenge. See, Id. Similarly, here, the claims are directed to a specific data access ,where the data access is specifically conditioned. In this way, by the specific limitations of the claims, the proliferation of data (with the aim of enabling one or more merchant/fintech application with the dPAN) within the specific architecture of the claims, is limited, hidden, represented, etc., in a manner to disclose what is necessary for certain operations to be performed, while restricting other data. This is a clear improvement in technology, similar to TecSec, where an efficient manner for specific operations are enabled- while securing the actual data itself from being revealed. The pending claims recite an integration of the alleged idea into a practical application and/or, directed to the alleged idea, the pending claims integrate the alleged idea into a practical application and/or significantly more than the alleged idea.
For all of the foregoing reasons, pending Claims 1-16 involve patent eligible subject matter. Reconsideration and withdrawal of the § 101 rejection of these claims are therefore respectfully requested.
Examiner Response
Examiner respectfully disagrees.
Page 27 of the decision in TecSec v Adobe Inc, states, “The specification elaborates in a way that simultaneously shows that the claims at issue are directed at solving a problem specific to computer data networks. The patent focuses on allowing for the simultaneous transmission of secure information to a large group of recipients connected to a decentralized network—an important feature of data networks—but without uniform access to all data by all recipients. See ’702 patent at col. 11, lines 40–48. The proposed improvement involves, among other things, labeling together with encryption. “Using a secure labelling regimen, a network manager or user can be assured that only those messages meant for a certain person, group of per sons, and/or location(s) are in fact received, decrypted, and read by the intended receiver.” Id., col. 2, lines 39–43. “[M]any people within a company may have the key necessary to read a data file” that is encrypted and sent to many terminals, but the sender may not want all such people to read the file. Id., col. 2, lines 45–51. “By employing a secure labelling technique in addition to encryption, the sender can be assured that people having the correct key to decrypt the message but
working at different terminals will not receive or be allowed to access the communication.” Id., col. 2, lines 51–55 (emphasis added).
The claims of the instant invention are not aimed at solving a problem specific to computer data networks. There is no improvement in the claim or supported in the instant specification as was the case in TecSec v Adobe.
The claims of the instant invention are aiming to solve a business problem (retrieving a primary account number using an open banking system) with the use of technology.
See the Response to Applicant argues#1,3 above.
Therefore the claims of the instant invention are unlike the claims in TecSec v Adobe.
The rejection is maintained.
Applicant argues#7
Claim Rejection under 35 U.S.C. § 112
Claims 17-20 stand rejected under 35 U.S.C. § 112(a) or 35 U.S.C. § 112(pre-AIA ), first paragraph, as failing to comply with the written description requirement. Claims 17-20 are cancelled herein, thereby rendering the instant rejection of these claims moot.
Examiner Response
The 35 U.S.C 112 rejection for claims 17-20 has been withdrawn.
Applicant argues#8
Claim Rejections under 35 U.S.C. § 103
As amended herein, however, Claim 1 recites that the connection request is received, via an open banking API, that the connection request signal is specific to one or more merchant/fintech applications, and that the account is a checking account or a savings account. Notably, as cited, Thampi discloses that the PAN information is included in the original request. In general, this is not what is recited in Claim 1. That is, as it relates to this specific "receive" limitation, the specific connection request signal indicates one or more claims, which detail the financial account information being requested. In other words, the financial information is not known, which is why the open service API, and the open banking system is receiving that specific request, which, again, is through a specific API, for a checking account or savings account. Also, there is no connection request for one or more merchant/fintech applications. As such, Thampi fails to disclose receipt of the specific connection request signal now recited in Claim 1.
Second, in rejecting Claim 1, the Office relies on Thampi at ||0015 to disclose presenting a login screen associated with an issuer of the financial account. See, Office action dated Feb. 20, 2026, at p. 14.
As cited, Thampi discloses enrolling by a mobile device a PAN information using a banking application. There is, however, no indication of any specific screen being displayed at the mobile device, much less a login screen. Further, there is no indication of any open banking system presenting any screen at the mobile device in Thampi, as cited. As such, Thampi is deficient of the above limitation.
Third, in rejecting Claim 1, the Office relies on Thampi to disclose receiving the authorization code, which includes a verification that the cardholder is authenticated by the issuer, citing II0026. See, Office action dated Feb. 20, 2026, at p. 14.
As cited, Thampi merely discloses that a token gateway server computer receives the PAN, mobile device number and card validity, etc., from the token provider server computer. Initially, none of the cited information is received from a financial application at a cardholder computing device (as is now recited in Claim 1). Also, there is no indication that any of the cited data in Thampi indicates that the cardholder has in fact been authentication, and specifically, authenticated by the issuer of the financial account (i.e., checking account or savings account). Finally, there is no indication that the cited data is received, by the token gateway server computer, via any open service API, as is recited in Claim 1. As such, Thampi is deficient of the above limitation.
Fourth, the Office relies on Thampi to disclose transmitting a payment token request to the issuer of the financial account, where the request includes a TRID, an authorization token, and financial account information. See, Office action dated Feb. 20, 2026, at p. 17-18, citing [[0103.
As cited, Thampi discloses a definition of a Token issuer identifier range (issuer BIN range), in which the specific construction of payment and non-payment tokens is described. For example, as it relates to the specific BIN, a payment token issuer identifier may be mapped to a real issuer identifier for an issuer. There is, however, no request, which is transmitted to an issuer, much less any request that includes specific financial account information and also the recited authorization token from the open banking system. As such, Thampi is deficient of the above limitation.
Further, the Office does no rely on either Mehroff or Ho for the above limitations, whereby the suggested combination based on the above is also deficient.
Moreover, in combining Thampi and Mehrhoff, the Office argues the combination would be obvious to ensure that by tokenizing the contactless transaction, the transaction remain private and secure. See, Office action dated Feb. 20, 2026, at p. 21-22. Tokenization is already accomplished in Thampi, alone. To the extent tokenizing the transaction causes the transaction to be private and secure, it is also so in Thampi. Consequently, there is no motivation for one skilled in the art to combine the specific token service system 28 disclosed in Mehrhoff into Thampi. The combination is therefore improper.
For the reasons above, Claim 1 is patentable over Thampi, Mehrhoff, and Ho. Claims 2-4 depend from Claim 1 and are patentable over the art for the same reasons. Reconsideration and withdrawal of this rejection of Claims 1-4 are therefore respectfully requested.
Independent Claim 9
Independent Claim 9 recites similar limitations to Claim 1, and is rejected on the same basis as Claim 1. See, Office Action dated February 10, 2026 at p. 25-30. As such, Claim 9 is patentable for the same reasons explained above with respect to Claim 1. Also, Claims 10-12 depend from Claim 9. As such, Claims 10-12 are also patentable over the art for the same reasons.
Reconsideration and withdrawal of this rejection of Claims 9-12 are therefore respectfully requested.
B. Thampi, Mehrhoff, Ho, and Leonardi
Claims 5-6 and 13-14 stand rejected under 35 U.S.C. § 103 as allegedly unpatentable over Thampi in view of Mehrhoff and Ho, and in further view of Leonardi et al (U.S. Pub. No. 2023/0063947, hereinafter Leonardi). This rejection is respectfully traversed for at least the following reasons.
Claims 5-6 and Claims 13-14 depend from independent Claims 1 and 9, respectively, which are patentable over Thampi, Mehrhoff, and Ho for the reasons explained above. In addressing the features of Claims 5-6 and 13-14, the Office additionally cites to Leonardi as supplementing Thampi, Mehrhoff, and Ho. However, Leonardi at least fails to remedy the shortcomings of Thampi, Mehrhoff, and Ho with respect to Claims 1 and 9, as explained in detail above. As such, even assuming, arguendo, that the suggested combination of Thampi, Mehrhoff, Ho, and Leonardi is proper and that Leonardi discloses the subject matter asserted by the Office, Claims 5-6 and 13-14 are still patentable over the suggested combination of Thampi, Mehrhoff, Ho, and Leonardi, at least, based on their dependence from Claims 1 and 9.
Examiner Response
Based on the amendments to the claim, the 35 U.S.C 103 rejection is hereby withdrawn.
Claim Rejections- 35 U.S.C § 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.
1. Claims 1-16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1, 9 are directed to a system, method which are statutory categories of invention. (Step 1: YES).
Representative claim 1 recites the limitations of:
A computing system comprising: an open banking system comprising:
one or more first processors; and a first memory comprising first executable instructions, that when executed by the one or more first processors, cause the one or more first processors to:
receive, via an open service application programming (API), a connection request signal for one or more merchant/fintech applications from a financial application running on a cardholder computing device associated with a cardholder, the connection request signal including one or more claims detailing financial account information being requested for a financial account issued to the cardholder, the financial account being a checking account or a savings account;
in response to the connection request signal, launch an open banking connection interface on the cardholder computing device, via the financial application;
present, via the open banking connection interface, a login screen associated with an issuer of the financial account at the cardholder computing device, whereby the cardholder logs-in to provide consent to share the financial account information;
receive, from the financial application at the cardholder computing device, via the open service API, an authorization code, the authorization code including a verification that the cardholder is authenticated by the issuer; and
generate an authorization token based on the authorization code; and
a token requester server system comprising:
one or more second processors; and
a second memory comprising second executable instructions, that when
executed by the one or more second processors, cause the one or more second processors to:
receive, from the open banking system, the authorization token and the financial account information specific to the financial account based on the consent from the cardholder to the issuer of the financial account and;
utilize the authorization token, transmit a payment token request to the issuer, the payment token request including a token requester identifier (TRID) associated with the token requester server system, the authorization token, and the financial account information; and
a token service system comprising:
one or more third processors; and
a third memory comprising third executable instructions, that when executed by
the one or more third processors, cause the one or more third processors to:
receive a token account receipt request from the issuer, the token account receipt request including the TRID and the financial account information;
generate a token account receipt;
transmit the token account receipt to the issuer; and
generate a device primary account number (dPAN),
wherein the second executable instructions further cause the one or more second processors to:
receive, from the issuer, the token account receipt;
transmit a payment token request to the token service system, the payment token request including the token account receipt;
in response, receive the dPAN from the token service system; and transmit the dPAN to the one or more merchant/fintech applications.
These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity.
The claim recites elements that are in bold above, which covers performance of the limitation as a commercial interaction, steps for retrieving a primary account number using an open banking system (e.g., receive, the request signal including one or more claims detailing financial account information being requested for a financial account issued to the cardholder, the financial account being a checking account or a savings account; present, a login associated with an issuer of the financial account, whereby the cardholder logs-in to provide consent to share the financial account information; receive, an authorization code, the authorization code including a verification that the cardholder is authenticated by the issuer; and generate an authorization token based on the authorization code; and a token requester; receive, from the open banking, the authorization token and the financial account information specific to the financial account based on the consent from the cardholder to the issuer of the financial account and; utilize the authorization token, transmit a payment token request to the issuer, the payment token request including a token requester identifier (TRID) associated with the token requester, the authorization token, and the financial account information; and a token service; receive a token account receipt request from the issuer, the token account receipt request including the TRID and the financial account information; generate a token account receipt; transmit the token account receipt to the issuer; and generate a device primary account number (dPAN), receive, from the issuer, the token account receipt; transmit a payment token request to the token service , the payment token request including the token account receipt; in response, receive the dPAN from the token service; and transmit the dPAN to the one or more merchant/fintech)
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a Commercial Interaction, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
Claim 9 is abstract for similar reasons.
(Step 2A-Prong 1: YES. The claims are abstract).
This judicial exception is not integrated into a practical application. Limitations that are not indicative of integration into a practical application include: (1) Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05.f), (2) Adding insignificant extra solution activity to the judicial exception (MPEP 2106.05.g), (3) Generally linking the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05.h).
Claims 1, 9 includes the following additional elements:
-A computing system
-An open banking system
-One or more first processors
-An open service API
-One or more merchant/fintech applications
-A connection request signal from a financial application
-A cardholder computing device
-Open banking connection interface
-A login screen
-A token requester server system
-One or more second processors
-A second memory
-A token service system
-One or more third processors
-A third memory
The computing system, open banking system, one or more first processors, open service API, one or more merchant/fintech applications, a connection request signal from a financial application, a cardholder computing device, open banking connection interface, a login screen, a token requester server system, one or more second processors, a second memory, a token service system, one or more third processors, a third memory are recited at a high level of generality and are being used in their ordinary capacity and are being used as a tool for implementing the steps of the identified abstract idea, see MPEP 2106.05(f), where applying a computer or using a computer as a tool to perform the abstract idea is not indicative of a practical application.
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
Therefore claims 1, 9 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, there are no additional elements recited in the claim beyond the judicial exception.
Mere instructions to implement an abstract idea, on or with the use of generic computer components, or even without any computer components, cannot provide an inventive concept - rendering the claim patent ineligible. Thus claims 1,9 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-8, 10-16 further define the abstract idea that is present in their respective independent claims 1, 9 and thus correspond to Certain Methods of Organizing Human Activity and hence are abstract for the reasons presented above.
Claim 4, 12 further defines the identified abstract idea as recited in claims 1,9. The data mapping in a database is recited a high level of generality, operating in their ordinary capacity, and are being used as a tool to implement the steps of the identified abstract idea, see MPEP 2106.05(f)
Therefore, the dependent claims do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Therefore, the dependent claims (2-8, 10-16) are directed to an abstract idea. Thus, the claims 1-16 are not patent-eligible.
Conclusion
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 MOHAMMAD Z SHAIKH whose telephone number is (571)270-3444. The examiner can normally be reached M-T, 9-600; Fri, 8-11, 3-5.
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, BENNETT SIGMOND can be reached at 303-297-4411. 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.
/MOHAMMAD Z SHAIKH/Primary Examiner, Art Unit 3694 7/10/2026
Prosecution Insights