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
This action is in reply to the request for continued examination filed on 12/19/2025.
Claims 1, 2, 4, 8, 9, 11, 15, 16 and 18 have been amended.
Claims 3, 5, 6, 10, 12, 13, 17, 19 and 20 have been canceled.
Claim 23 has been added.
Claims 7 and 14 have been canceled.
Claims 1-2, 4, 8-9, 11, 15-16, 18, 21-23 are pending and have been examined.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/19/2025 has been entered.
Response to Arguments
With regard to the 101 rejection (Abstract Idea), the arguments have been considered but they are not persuasive. In Prong 2 – Step 2A, the applicant asserted that “[even] assuming arguendo that the instant claims do not recite a judicial exception, which Applicant does not concede, the claims are patent eligible because they integrate any alleged judicial exception into a practical application . . . The present claims demonstrate an improved in distributed ledger based financial transaction systems . . .”. The assertion is not persuasive because the claim recites an idea of transferring between a payer and a payee via the use of an NFT. Such generally linking to a technological improvement does not render the claim more than an abstract idea. The limitations are not indicative of integration into a practical application: Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
In step 2B prong Two, the Applicant asserted that “the present claims recite an inventive concept for at least the same reasons as discussed above with respect to a practical application . . . the requirement that the NFT check passcode can be a one-time-use passcode unique to the request to execute the resource transfer transaction . . .” However, the limitations are not indicative of an inventive concept (aka “significantly more”). They are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Therefore, the claim is not patent eligible.
With regard to the 103 rejection, the arguments have been considered but they are not persuasive. The independent claims have been amended to recite additional limitations. However, per reviewing the claim amendments, the primary reference, Karnik, still discloses the amended limitations. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Karnik by creating an NFT and using NFT as a payment tool as taught by Doumar, because modifying Karnik using elements taught by Doumar helps to improve the performing payment transaction (Abstract). Therefore, the claimed invention is obvious in view of the cited references. Hence, the 103 rejection is maintained. Please refer to the rejection below for further details.
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.
Claim 1-2, 4, 8-9, 11, 15-16, 18, 21-23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional computer elements, which are recited at a high level of generality, provide conventional computer functions that do not add meaningful limits to practicing the abstract idea.
Claims 1-2, 4, 8-9, 11, 15-16, 18, 21-23 recite, in part, A system for orchestrating resource instruments in an electronic network utilizing unique hash tokens, the system comprising: a processing device; a non-transitory storage device containing instructions when executed by the processing device, causes the processing device to perform the steps of: receive resource action data from an end-point device of a first user as a request to execute a resource transfer transaction; determine, via a metadata engine, metadata from the resource action data required for generating a non-fungible token (NFT) check, wherein the metadata comprises (i) a resource account identifier corresponding to a resource account of the first user, and (ii) an NFT check passcode, wherein the NFT check passcode is required to access the NFT check via an NFT management platform, and wherein the NFT check passcode comprises a one-time use passcode unique to the request to execute a resource transfer transaction; initiate, via the metadata engine and a calling engine, a call to the end-point device of the first user to receive data, the data comprising a voice sample of the first user's voice; perform, via the metadata engine, a biometric voice verification of the first user via the voice sample of the first user's voice to authenticate the first user's identity for authorization of the resource transfer transaction; after authenticating the first user’s identity, utilize a distributed ledger architecture to generate, via the NFT management platform, the NFT check based on the metadata provided by the metadata engine; transmit unique hash code data representing the NFT check to an entity resource account management and settlement repository; generate a link to the NFT check; transmit the link to the NFT check to the end-point device of the first user, wherein transmitting the link to the NFT check to the end-point device of the first user further comprises in the absence of an active internet connection, sending a Short Message Service (SMS) to a registered mobile number of the first user; receive the NFT check from a second user; verify the second user as an authorized payee based on the extracted metadata; transfer the NFT check to an entity associated with a resource account of the second user; update ownership of the NFT check to the entity associated with the resource account of the second user; and automatically withdraw resources from the resource account of the first user and transmit the resources to the resource account of the second user to settle the resource transfer transaction. The limitations are directed to “business relations” (commercial interactions - see MPEP 2106.04(a)(2)). Hence, they fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements such as a system, a non-fungible token (NFT) check, a metadata engine, an NFT management platform, a processing device, a non-transitory storage device, end-point device, non-fungible token (NFT) to perform receiving, extracting and generating. The generic computer components are recited at a high-level of generality (receiving, determining, and transmitting) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these 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.
Next the claim as a whole is analyzed to determine whether any element, or combination of elements, is sufficient to ensure the claim amounts to significantly more than an abstract idea. Claims 1, 8 and 15 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements of at least a computing device to perform receiving and identifying data are merely additional elements Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). There is no improvement to computer technology or computer functionality MPEP 2106.05(a) nor a particular machine MPEP 2106.05(b) nor a particular transformation MPEP 2106.05(c). Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) see MPEP 2106.05(d). Given the above reasons, a generic processing device used to transmit a payment is not an Inventive Concept. Thus, the claim is not patent eligible.
The dependent claims have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The Dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea.
Claims 2, 9, 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) additional elements of resource identifier, a resource amount, identifier(s), or check memos. This judicial exception is not integrated into a practical application because the additional elements (such as a system) are Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). Therefore, the claims are rejected under 35 U.S.C. 101.
Claims 4, 11, 18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) abstract idea of receiving voice from the user and applying MFCC algorithm to analyze voice similarities. This judicial exception is not integrated into a practical application because the additional elements (such as a system) are Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). Therefore, the claims are rejected under 35 U.S.C. 101.
Claims 21, 22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) an abstract idea of endorsing a payment option. This judicial exception is not integrated into a practical application because the additional elements (such as a system) are Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Claim 23 is rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) an abstract idea of endorsing an NFT check. This judicial exception is not integrated into a practical application because the additional elements (such as a system, an NFT platform) are Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Therefore, the claims are rejected under 35 U.S.C. 101.
Claim Rejections - 35 USC § 103
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-2, 8-9, 15-16, 23 are rejected under 35 U.S.C. 103 as being unpatentable over Karnik et al. (US 2020/0097972) in view of Doumar et al. (US 2023/0289425 A1).
Claims 1, 8 and 15 are grouped together. Claim 1, for instance, is disclosed as follows: Karnik discloses: A system for orchestrating resource instruments in an electronic network utilizing unique hash tokens, the system comprising:
a processing device (Karnik, Par. [0022]); a non-transitory storage device containing instructions when executed by the processing device, causes the processing device to perform the steps of:
receive resource action data from an end-point device of a first user as a request to execute a resource transfer transaction (Karnik, see at least par. [0023] “In a step 204, the transaction request module 110a of the payment application 110 initiates a user request to perform the payment transaction. The user request may include user login credentials to verify the user's identity to use the payment application 110.”) a user corresponds to a first user;
determine, via a metadata engine, metadata from the resource action data required for generating a non-fungible token (NFT) check (Karnik, see at least par. [0022] “. . . In a step 210, the transaction request module 110a selects, by the user and via the user operative interface, a payment instrument 108 of the user 104 for payment of the payment amount to the payee 105 . . .” & par. [0034]) Interpretation: a “check” could correspond to any type of payment instrument listed in par. [0034] of the cited reference to use to make payment, wherein the metadata comprises (i) a resource account identifier corresponding to a resource account of the first user (see at least par. [0033] “ The user 104 is an individual who is an account holder of an account associated with a number of payment instruments 108 of the user 104. In some embodiments, the account is a bank account maintained by a financial institution, such as an issuer institution or bank . . .”), and (ii) an NFT check passcode, wherein the NFT check passcode is required to access the NFT check via an NFT management platform, and wherein the NFT check passcode comprises a one-time use passcode unique to the request to execute a resource transfer transaction (Karnik, see at least par. [0041] “ . . . n some embodiments, the user request may include user login credentials to verify the user's identity to use the payment application 110. FIG. 3B depicts a GUI 320 representing a user credentials screen 322. The user credentials screen 322 includes one or more verification schemes for verifying the identity of the user 104 accessing the payment application 110. Specifically, the user 104 inputs user login credentials to verify whether the user 104 is a rightful or authorized user of the payment application 110. The verification schemes may include a biometric verification scheme 324 and/or a code verification scheme 326, and verified access to the payment application 110 may be based on one or both verification schemes 324 and 326. The biometric verification scheme 324 may be based on fingerprint scanning. In this regard, the display screen of the electronic device 102 is configured for scanning fingerprints. The biometric verification scheme 324 may be based on other biometric parameters, such as facial, retinal image, and/or speech recognition. The code verification scheme 326 may be based on a numerical PIN code or more complex alphanumeric passcodes. . . .”) The cited portion discloses a passcode used for transaction. The NFT portion is disclosed in the secondary reference;;
initiate, via the metadata engine and a calling engine, a call to the end-point device of the first user to receive data, the data comprising a voice sample of the first user's voice (Karnik, see at least par. [0023] “In a step 204, the transaction request module 110a of the payment application 110 initiates a user request to perform the payment transaction. The user request may include user login credentials to verify the user's identity to use the payment application 110. In a step 206, the transaction request module 110a presents, in response to initiation of the user request, a user operative interface for the user 104 to provide details of the payment transaction . . .”) Interpretation: a request corresponds to a “call” to the device of the user to receive payment request data;
perform, via the metadata engine, a biometric voice verification of the first user via voice sample of the first user's voice to authenticate the user's identity for authorization of the resource transfer transaction (Karnik, see at least par. [0041] “ . . . The biometric verification scheme 324 may be based on fingerprint scanning. In this regard, the display screen of the electronic device 102 is configured for scanning fingerprints. The biometric verification scheme 324 may be based on other biometric parameters, such as facial, retinal image, and/or speech recognition . . .”)
receive the NFT check from a second user (Karnik, see at least par. [0023] “. . . The user 104 provides the payment transaction details by inputting them into the payment application 110. Additionally, the payment application 110, specifically on the user operative interface, provides a plurality of options for the user 104 to provide the payee identification data . . . ) the user receives one of the payment options (such as “an NFT check) from the payee;
verify the second user as an authorized payee based on the extracted metadata (Karnik, par. [0049] “the second user” corresponds to a payee which could be a merchant. The merchant is verified by one of the identification data;
transfer the NFT check to an entity associated with a resource account of the second user (Karnik, see at least par. [0023] “. . . Additionally, the payment application 110, specifically on the user operative interface, provides a plurality of options for the user 104 to provide the payee identification data. The plurality of options may relate to one or more of optical codified data (e.g. Quick Response (QR) codes), contacts stored on the electronic device 102, transaction history, and proximity to the user 104 . . .”) the QR code corresponds to the second’s user “[NFT] check”;
update ownership of the NFT check to the entity associated with the resource account of the second user (Karnik, see at least par. [0023] “. . . For example, the payee identification data may be obtained by scanning a QR code with the electronic device 102 or manually entered by the user 104. In a step 210, the transaction request module 110a selects, by the user and via the user operative interface, a payment instrument 108 of the user 104 for payment of the payment amount to the payee 105 . . .” & see at least par. [0076] “. . . . Various options are provided by the user operative interface to help the user 104 provide the payee identification data. Such options include the use of QR codes, existing contacts of the user 104, and searching for nearby payees 105. The user 104 would not need to always manually input the payee identification data . . .”) The cited portion discloses the concept of detecting the payment option from the user’s device and prepares for the payment;
and automatically withdraw resources from the resource account of the first user and transmit resources to a resource account of the second user (Karnik, see at least par. [0032] “. . . More specifically, upon processing of the payment transaction, funds are debited from the payment instrument 108 of the user 104, and funds are credited to an account of the payee 105 held at the acquirer institution . . .”) the payee corresponds to second user.
Karnik does not disclose the following; however, Doumar teaches:
after authenticating the first user's identity, utilize a distributed ledger architecture to generate, via the NFT management platform, the NFT based on the metadata provided by the metadata engine (Doumar, see at least par. [0100] “In order to generate a PNFT, according to an embodiment, an end user-using either a web page or an application connected to a token-granting server-requests that a personal non-fungible token be generated and optionally uploads an image or other data element to be stored permanently in association with the generated token . . . Once confirmed, the new record is permanently written to a distributed ledger, and the requesting end user receives the unique identifier of the newly-generated PNFT.”) Interpretation: an NFT is generated based on “metadata”, personal related data, and utilized a distributed ledger;
transmit unique hash code data representing the NFT check to an entity resource account management and settlement repository (Doumar, par. [0077]) Interpretation: token manager, under BRI corresponds to resource account management and media server corresponds to settlement repository ;
generate a link to the NFT check (Doumar, see at least par. [0099] “. . . In some aspects a link or pointer to the image may be stored in the PNFT . . .”) A link is generated in the context of a PNFT is created; transmit the link to the NFT to the end-point device of the first user, wherein transmitting the link to the NFT check to the end-point device of the first user further comprises, in the absence of an active internet connection, sending a Short Message Service (SMS) to a registered mobile number of the first user (see at least par. [0074] “. . . In this way, authorization for capture of the user's phone number and establishment of communications with a third party can be established simply by having the user click on two automatically-generated SMS messages without having to otherwise enter any data on the smartphone. This method works universally on all smartphones with SMS technology without having to install additional applications. Note that while SMS technology is the primary example used herein, the invention is not so limited and other forms of mobile device interactions may be used, provided that an identifier for the mobile device can be obtained from the interaction . . .”) & see at least par. [0100] “. . . Once confirmed, the new record is permanently written to a distributed ledger, and the requesting end user receives the unique identifier of the newly-generated PNFT. At this point, the end user is able to post the PNFT on any suitable electronic medium, for example her webpage or a social network home page, or even embedded in her standard email template. It will be appreciated by one having ordinary skill in the art that “posting” an PNFT means placing an image (such as the personal photo image that was optionally uploaded when generating the PNFT) along with a (hidden) link “behind” the image or accessible via scanning the image . . .).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Karnik by creating an NFT and using NFT as a payment tool as taught by Doumar, because modifying Karnik using elements taught by Doumar helps to improve the performing payment transaction (Abstract). Therefore, the claimed invention is obvious in view of the cited references.
Claims 2, 9 and 16 are grouped together. Claim 2, for instance, is taught: Karnik in view of Doumar teaches: The system of claim 1. Karnik further teaches: wherein the metadata further comprises a resource account identifier, a resource amount, a payee identifier, a payer identifier, or a check memo (Karnik, see at least par. [0042] “. . . At the payment transaction screen 332, the user 104 provides payment transaction details including payee identification data and payment amount, as well as details of the payment instrument 108 for paying the payee 105. The payee identification data may include, but is not limited to, one or more of the name, address, contact number, and/or account number of the payee 105 . . .”).
Claim 23. Karnik in view of Doumar teaches: The method of claim 15. However, Doumar teaches: further comprising: prior to receiving the NFT check from the second user, receiving a request to endorse the NFT check to the second user from an intermediate user (Doumar, see at least par. [0077] “Once authorization has been established via text messaging, the media server 200 requests verification of the PNFT token from and receipt of rules for the token 1110 from the token manager 800. The token manager 800 verifies the PNFT token and sends rules associated with it 1112 to the media server 200. Depending on the rules, the media server may take one of several actions, two of which are shown here. The media server 200 may automatically forward information 1114a to the customer 120 according to the PNFT rules, or may request session initiation 1114b from the session manager 400. If a session request is sent 1114b, the session manager initiates an SIP session 1116, which establishes an SIP connection through the media server 200 between the client 1118a and the customer 1118b.”) the verification corresponds to endorsement.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Karnik by using SMS to transfer link with NFT as taught by Doumar, because modifying Karnik using elements taught by Doumar helps to improve the performing payment transaction. Therefore, the claimed invention is obvious in view of the cited references.
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Karnik et al. (US 2020/0097972) in view of Doumar et al. (US 2023/0289425 A1) in further view of Zigel, Yaniv, (WO 2008/047339 A2).
Claims 4, 11 and 18 are grouped together. Claim 4, for instance, is disclosed: The system of claim 1. Zigel, however, teaches: wherein biometric voice verification further comprises the steps of: receive a voice sample of the user's voice via the end-point device of the user; preprocess the voice sample to reduce noise, normalize volume, and remove silence from the voice sample (Then, frames that include silence and frames that include significant levels of noise are discarded leaving only speech frames.); perform a feature extraction on the voice sample to generate a compact representation of the voice sample by applying a Mel Frequency Cepstral Coefficients (MFCC) algorithm; compare and analyze resulting feature vectors to determine a similarity score via one or more aligned feature vectors of the voice sample in comparison to a previously stored voice sample of the user (Zigel, see at least “. . . For example, a background model can characterize all speakers, male speakers, female speakers, different acoustic environments, different channels, or other subgroups of voices of callers calling a call center, and captured. The model comprises characteristics of the call center and of the recording equipment. Optionally, after a voice is compared to a model of a specific speaker from the target set during the identification process, the match result is normalized using a match between the speaker and a background model, in order to enhance the score. The model generation process comprises the following steps: a target utterance 302 is fed into preprocessing step 304, in which the target utterance available as a voice signal is first segmented into speech frames of about 20-ms window progressing at an about 10-ms frame rate. Then, frames that include silence and frames that include significant levels of noise are discarded leaving only speech frames. The exclusion is optionally performed by a self-normalizing, energy-based detector. Then at step 308 voice features are extracted from the audio, thus generating a multiplicity of feature vectors, one vector for each frame. The voice features are preferably MFCC (Mel Frequency Cepstral Coefficients) feature vectors are extracted from the speech frames . . .”); and normalize the similarity score to a scale ranging from 0-100, wherein 0 represents no similarity, and 100 represents a perfect match (Zigel, Yaniv, WO 2008/047339 A2) “ Since the matching involves exercising a loop over the frames of the input signal, when the number of frames is significantly reduced, so does the time required for matching. After matching the partial utterance against all the target set models, only the models whose matching provided the highest scores are selected. For example, a predetermined percentage of the models, such as those having the top 10% of the scores, or a predetermined number of models having the highest scores are selected…”) the model indicates higher percentage means greater similarity and vice versa.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Karnik in view of Doumar by applying voice extraction technique to determine and compare voice similarity as taught by Zigel, because modifying Karnik in view of Doumar using elements taught by Zigel helps to improve the verification process when performing a payment transaction. Therefore, the claimed invention is obvious in view of the cited references.
Claims 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Karnik et al. (US 2020/0097972) in view of Doumar et al. (US 2023/0289425 A1) in further view of Jakobsson et al. (US 2022/0398538 A1).
Claims 21 and 22 are grouped together. Claim 21, for instance, is disclosed: Karnik in view of Doumar teaches: system of claim 1. However Jackobsson teaches: wherein the non-transitory storage device comprises instructions that, when executed by the processing device, causes the processing device to, prior to receiving the NFT check from the second user, receive a request to endorse the NFT check to the second user from an intermediate user (see at least par. [0298] “. . . Content creators may assign bonuses, give partial payments, create endorsements for contributors, etc. Content creators may request that contributors endorsed by one or more selected content creators can be selected for a given task, and/or used as the pool of preferred contributors for feedback on content generated and/or curated by the content creator. . .”) Content creators correspond to third party user that endorse the “NFT”.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Karnik in view of Doumar by endorsing a content for payment option as taught by Jakobsson, because modifying Karnik in view of Doumar using elements taught by Jakobsson helps to improve the verification process when performing a payment transaction. Therefore, the claimed invention is obvious in view of the cited references.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOAN DUC BUI whose telephone number is (571)272-0833. The examiner can normally be reached M-F 8-5:00 PM.
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 W. Anderson can be reached on (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.
/TOAN DUC BUI/Examiner, Art Unit 3693
/ELIZABETH H ROSEN/Primary Examiner, Art Unit 3693