DETAILED ACTION
This is a final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 -3 in application 18/669,123.
Claims 1-3 are amended.
Claims 1-3 are pending and have been examined on the merits.
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 .
Response to Arguments
Claim Objection
Applicant’s arguments, filed 3/17/2026, with respect to Claim 3 have been fully considered and are persuasive. The claim objection of Claim 3 has been withdrawn.
Claim Interpretation
Applicant’s arguments, filed 3/17/2026, with respect to Claim 3 have been fully considered and are not persuasive. The amendments do not remove the underlying indefiniteness. The recited “first module,” “second module,” “third module,” etc, are still nonce terms that merely describe functions rather than definite structure. The amendments do not replace those modules with sufficiently definite structure, nor do they identify corresponding algorithmic structure in the claim itself. Please see the rejection below.
35 USC 112
Applicant’s arguments, filed 3/17/2026, with respect to Claims 1-3 have been fully considered and are not persuasive. Several amended limitations still recite relationships and results without objective boundaries. The amendments add more functional language, but they do not clarify how the binding occurs, what makes the intervals non-overlapping, or what relationship is required for the “responsive to” the project NFT token and the series of carbon credit NFT tokens do not clearly define wat structure or specific operations are required, or where the boundaries of the claim begin and end. Please see the rejection below.
USC 101
Applicant’s arguments, filed 3/17/2026, with respect to Claims 1-3 have been fully considered and are persuasive. The claim rejection of Claims 1-3 has been withdrawn.
35 USC 103
Applicant’s arguments, filed 3/17/2026, with respect to Claims 1-3 have been fully considered and are NOT persuasive. Slack teaches the claimed carbon-credit/NFT environment, including carbon reductions “validated as NFTs on a distributed ledger. Tobias teaches wallet/private key pairing for blockchain assets. Tian was cited for separate smart contract functionality in carbon recording and Madisetti teaches address based smart contract creation and contract-to-contract association.
Applicant’s “project NFT token” argument is not persuasive because the claims do not require any particular container data structure beyond a project linked token and associated smart contract relationships. Slack expressly ties NFTs to an “associated project” and provides project creation functionality, while the cited smart contract references supply the contract architecture and binding concepts. Thus the combination reasonably suggests using a project level NFT as the anchor for downstream carbon credit NFTs.
Applicant’s argument regarding the “second smart contact” and binding relationship is also unpersuasive. Slack expressly teaches that “a first smart contract is operable to invoke a second smart contract,” and Madisetti teaches creation and association of smart contracts at blockchain addresses. The rejection therefore does not rely on Slack alone, but on the combined teaches to show separate smart contract layers tied to the project carbon credit workflow.
Applicant’s argument concerning “periodically generating” carbon credit NFTs for “respective non-overlapping time intervals” is not persuasive. Slack teaches carbon NFT metadata including at least one start date, annual creation rules, expiration dates, and expressly identifiers double counting as a problem. In that context, assigning each periodically generated carbon credit NFT to a distinct, non-overlapping reporting interval would have been an obvious implementation choice to improve traceability and avoid duplicate accounting.
Applicant’s arguments as to retiring, transferring, or issuing credits likewise do not overcome the rejection. Slack expressly teaches validating transfers of carbon NFTs on a distributed ledger and facilitating transfer to a burn wallet, i.e., retirement, while Tobias and Madisetti reinforce the wallet key and smart contract transaction framework use to control such issuance and transfer operations.
Accordingly, the amended claims does not overcome the rejection. Please see the updated rejection.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. - An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term "means" or "step" or a term used as a substitute for "means" that is a generic placeholder (also called a nonce term or a nonstructural term having no specific structural meaning) for performing the claimed function;
(B) the term "means" or "step" or the generic placeholder is modified by functional language, typically, but not always linked by the transition word "for'' (e.g., "means for'') or another linking word or phrase, such as "configured to" or "so that"; and (C) the term "means" or "step" or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word "means" (or "step") in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word "means" (or "step") in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word "means" (or "step") are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word "means" (or "step") are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word "means," but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
Such claim limitation(s) are: "a first module to create an entity private key/wallet address pair associated with a specific enterprise; a second module to create a first smart contract using the entity private key/wallet address pair; a third module to, using the first smart contract, generate a new project NFT token representing a project; a fourth module to create a second smart contract that binds to the project NFT token; a fifth module to ingest project data that corresponds to the project's carbon activity and storing it in a database; a sixth module , using the first smart contract, periodically generate a carbon NFT token in a series of tokens, from the ingested project data, wherein the series of tokens do not overlap in time; a seventh module to bind the carbon NFT token to the second smart contract and the project NFT token; an eighth module to take an action, responsive to the project NFT token and the carbon NFT tokens of the series of tokens" in Claim 3.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If Applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recites sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL-The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the
manner and process of making and using it, in such full, clear, concise, and exact terms as to
enable any person skilled in the art to which it pertains, or with which it is most nearly
connected, to make and use the same, and shall set forth the best mode contemplated by the
inventor of carrying out his invention.
Claims 1 - 3 are 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. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1 - 3 recite, “project” NFT token…”; however, the specification does not include sufficient detail for term “project” token or its structural or functional characteristics; nor explain how the token is generated beyond invoking the smart contract. Claims 2 and 3 recite similar language.
Claims 1 - 3 recite, “using the first smart contract, periodically generating a carbon NFT token…; binding the carbon NFT token…and the project NFT token; and taking an action, responsive to the project NFT token and the carbon NFT tokens…”.
The specification does not detail how a separate “carbon NFT token” is generated and/or bound to the previous “project NFT”. The specification details, 0037 “It may be noted that each project itself can be represented as an NFT with its corresponding metadata. The project NFT can also be a project token. This allows for associating any future carbon credit production related to the project to be associated with the project by binding it to the project token”; however, based on this language there appears to be only an association of project data and emission data. The specification is silent to the generation of two types of NFT.
Claim 3 recites limitations, as noted in the Claim Interpretation under 112(f) above, fails to disclose the corresponding structure, material and/or acts for performing a blockchain-based carbon credit tracking system and/or clearly link the structure, material, or acts to the function.
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 1 - 3 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Indefinite
Regarding Claims 1 - 3 recites, “project” NFT token…”. The Applicant’s specification does not detail any recognized terminology for “project” NFT token. The term is unclear to one of ordinary skill in the art because the specification does not appear to have a generally accepted meaning in the art. Accordingly, the scope of the term cannot be determined with reasonable certainty. The term “project” as used to modify the “NFT” appears to be a trademark. As noted, the specification provides no other explanation for the meaning of the term “project” as a modifier for “NFT.” See https://backpack.exchange/ and https://www.coingecko.com/learn/what-is-backpack-crypto-exchange-wallet-potential-airdrop. Claims 2 and 3 recited similar language.
Further regarding claims 1–3. Claims 1 and 2 each recite “taking an action, responsive to the project NFT token and the carbon NFT tokens of the series of tokens” and claim 3 recites, “an eight[h] module to take an action, responsive to the project NFT token and the carbon NFT tokens of the series of tokens.” “Take[ing] an action” is so broad that it renders the claim indefinite. Although a general principle, per MPEP 2173.04, is that breadth does not equal indefiniteness, in this instance the genus of "actions" is so broad that it is not clear what categories or "species" of actions are covered by the claim.
The specification at 008 provides only one possible example of “an action” (i.e., buying a carbon credit). Paragraphs 083 and 0114 add only that an AI is going to take some action "based on underlying analysis for the data that they operate on.” Thus, the “take an action” could lead to more than one reasonable interpretation of what species are included or covered in the metes and bounds of the claim. Accordingly, claims 1–3 are indefinite.
Means Plus Function
Claim 3 recites "first module”; “second module”; “third module”; “fourth module”; “fifth module”; “sixth module”; “seventh module”; and “eighth module”, which invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification is devoid of any structure that performs the function in the claim. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01 (o) and 2181.
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 for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3 is/are rejected under 35 U.S.C. 103 as being unpatentable Slack (US20230139137A1), in view of Tobias (US20160260091A1), in further view of Tian et al. (US20210117981A1) hereinafter Tian, and in further view of Madisetti et al. (US20220200975A1) hereinafter Madisetti.
Regarding Claims 1-3. Slack teaches in (BOLD) the following:
A computer-implemented method in a system, on a data communication network, for providing immutable information about carbon credits and associated data tracked with a non-fungible cryptographic token (NFT) based carbon certificate, the method comprising:
Note – Slack directly teaches carbon credits/offsets tracked as NFTs on an immutable distributed ledger.
Slack - carbon reductions and/or carbon offset measures are validated as non-fungible tokens (NFTs) on a distributed ledger (¶ 0018). the present invention utilizes a distributed ledger-based platform to provide an immutable record of a specific carbon offset which has been measured and verified, including details which allow for independent verification of the carbon offset (¶ 0038).
a processor;
Slack - a processor (¶ 0081).
a network interface communicatively coupled to the processor and to a data communication network; and
Slack - The server 850 is constructed, configured, and coupled to enable communication over a network 810 (¶ 0078). a network interface unit (¶ 0081).
a memory, communicatively coupled to the processor and storing instructions executable by the processor:
Slack - a processor 860, a system memory 862 having a random access memory (RAM) 864 and a read-only memory (ROM) 866, and a system bus 868 that couples the memory 862 to the processor 860. In another embodiment, the computing device 830 is operable to additionally include components such as a storage device 890 for storing the operating system 892 (¶ 0081).
a third module to, using the first smart contract, generate a new project NFT token representing a project;
Slack - the platform produces at least one non-fungible token (NFT) representing carbon credits, wherein the at least one NFT includes a carbon credit issuance serial number, a name of the associated project, a location (e.g., geospatial coordinates) of the project, a project start date, a project end date, a project duration, a company associated with the project (Abstract). an NFT representing each carbon credit…includes associated metadata, such as the type of project…the location of the project, the certification protocol followed to create this offset, and the external certifier that was used…generates a non-fungible token (NFT) corresponding to each carbon credit via a smart contract. information regarding the project used to generate the carbon credit is encoded as metadata in the relevant carbon credit NFT (¶ 0043).
each carbon credit NFT token corresponding to a respective non-overlapping time interval;
Slack - distributed ledger-based platforms are able to incorporate rules decreasing the number of carbon NFTs created annually (¶ 0038). detect that 1 ton of CO2 less than a predetermined amount (i.e., a baseline amount) has been produced over a particular time period, then one carbon NFT is added to a wallet associated with the company profile (¶ 0046). dashboard page includes at least one graph showing the number of carbon credit NFTs held by the user profile over time. In one embodiment, the at least one graph shows the total number of carbon NFTs held over time. In another embodiment, the at least one graph shows the per time period (e.g., per day, per week, per month, per year) change in the number of carbon credit NFTs (or carbon credits represented by said NFTs) held by the user profile over time (¶ 0049). NFT list page includes a date associated with the carbon NFT (e.g., date purchased, date generated, an expiration date, etc.), an identification code for each carbon NFT, a certifying entity for each carbon NFT (¶ 0056).
an eighth module to retiring, transferring, or issuing a carbon credit, responsive to the project NFT token and the carbon NFT tokens of the series of tokens.
Slack - transfers of carbon NFTs are validated on a distributed ledger…facilitate the transfer of the carbon NFTs to a burn wallet (¶ 0017).
Slack does not teach, however, Tobias discloses (in BOLD):
a first module to create an entity private key/wallet address pair associated with a specific enterprise;
Tobias - generating a unique wallet address that is permanently associated with the instance of the wallet (Abstract). the wallet uses an AES encrypted database to secure the wallet address and private key pairs (¶ 0014). the wallet utilizes AES encrypted SQLite database that secures user wallet address and private key pairs using BIP38 (¶ 0029).
Therefore, it would have been obvious to one of ordinary skilled before the effective filing date of the claimed invention to modify the carbon-credit NFT platform of Slack with the wallet key of Tobias because doing so allows carbon credit NFTs to be securely created, controlled, and transferred through blockchain wallet credentials.
The combination of Slack and Tobias does not disclose, however Tian discloses (in BOLD):
a first module to create an entity private key/wallet address pair associated with a specific enterprise;
Tian - the second object may be an enterprise with an excessive carbon emission (¶ 0025).
a fourth module to create a second smart contract that binds to the project NFT token;
Tian - using the first smart contract, the carbon data to a block chain platform for storage; and performing, using a second smart contract, a carbon trading (¶ 0009). convert, using a first smart contract, data related to carbon behaviors of a plurality of objects to corresponding carbon data of the plurality of objects, respectively, and transmit, using the first smart contract, the carbon data to a block chain platform for storage (¶ 0010). A smart contract (such as the second smart contract 220 shown in FIG. 2) dedicated to performing the carbon trading may be developed and distributed to the block chain platform 212 (¶ 0038).
a seventh module to bind the carbon NFT token to the second smart contract and the project NFT token;
Tian - using a second smart contract, a carbon trading between two objects in the plurality of objects or between one object in the plurality of objects and a third party object not belonging to the plurality of objects based on the carbon data (¶ 0012). the second smart contract entity 220 in the present disclosure. In this case, the second smart contract entity 220 performs the carbon trading between the first object and the second object based on, for example, the carbon data of the first object (e.g., the carbon emission reduction amount) and the carbon data (e.g., the carbon emission amount) of the second object. The second smart contract 220 may be contracted by each object to perform the carbon trading and distributed to the entire block chain platform 212 or a portion of the block chain platform 212. The second smart contract 220 may be developed by a developer of the system 200 (¶ 0038).
a fifth module to ingest project data that corresponds to the project's carbon activity and storing it in a database;
Tian - The raw carbon data may be stored by the system 200 in a local memory or a distributed database (such as the database 216 shown in FIG. 2) (¶ 0035). obtaining data related to carbon behaviors of a plurality of objects; converting the data related to the carbon behaviors of the plurality of objects to corresponding carbon data of the plurality of objects, respectively; transmitting the carbon data to a block chain platform for storage; performing, based on the carbon data, a carbon trading between two objects in the plurality of objects or one object in the plurality of objects and a third party object not belonging to the plurality of objects; and distributing the carbon trading to the block chain platform as a block chain transaction (Abstract).
a sixth module to, using the first smart contract, periodically generate a carbon credit NFT token in a series of carbon credit NFT tokens, from the ingested project data,
Tian - the data related to the carbon behaviors of the plurality of objects is transmitted to the first smart contract entity 218 on the block chain platform 212, and the data related to the carbon behaviors of the objects is converted to the corresponding carbon data using the first smart contract entity 218. The first smart contract 218 may be contracted by each object whose carbon record is to be recorded and distributed to the entire block chain platform 212 or a portion of the block chain platform 212. The first smart contract 218 may be developed by a developer of the system 200 or other providers and may be regarded as part of the system 200 (¶ 0028).
Therefore, it would have been obvious to one of ordinary skilled before the effective filing date of the claimed invention to modify the carbon-credit NFT platform of Slack and the wallet key of Tobias with the smart contract architecture of Tian because doing so allows a more organized blockchain system in which the wallet credentials interact with separate contracts for project data and carbon-credit operations.
The combination of Slack, Tobias, and Tian does not disclose, however Madisetti discloses (in BOLD):
a second module to create a first smart contract using the entity private key/wallet address pair;
Madisetti– smart contract…which is referred to as the ‘Seal Contract’ . The transaction to create this new Seal Contract 262 on the blockchain network is signed by the user's private key [smart contract creation is effected by a signed blockchain transaction] (¶ 0071). The data is signed by the user's private key (¶ 0072). receiving a transaction to create an identity smart contract (Claim 1).
a fourth module to create a second smart contract that binds to the project NFT token;
Madisetti - the certificate smart contract comprises the identity smart contract (Claim 8).
a seventh module to bind the carbon NFT token to the second smart contract and the project NFT token;
Madisetti - the certificate smart contract comprises the identity smart contract (Claim 8).
Therefore, it would have been obvious to one of ordinary skilled before the effective filing date of the claimed invention to modify the carbon-credit NFT platform of Slack and the wallet key of Tobias and the smart contract architecture of Tian with the verifying of Madisetti because doing so improves the integrity and traceability of the project-level and carbon credit level smart contract relationships in the combined system.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. James et al. (US10373158B1) - The present invention generally relates to a method, system and program product for modifying a supply of stable value digital asset tokens tied to a blockchain.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C whose telephone number is (571)270-7280. The examiner can normally be reached on Monday-Friday from 8am to 5pm.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick , can be reached at telephone number 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights