DETAILED ACTION
This final office action is in response to claims 1-10 filed on 02/12/2026 for examination. Claims 1-10 are being examined and are pending.
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Amendment/Argument
The amendment filed February 12, 2026 has been entered. Claims 1-10 remain pending in the application. Applicant’s narrowing amendments to the claims have overcome each and every drawings object and 35 U.S.C. 102 rejection previously set forth in the Non-Final Office Action mailed October 21, 2025. Claims 1-10 have been amended and necessitated a new ground(s) of rejection in this Office Action. Further, Applicant’s arguments filed on 02/12/2025 have been fully considered but are moot in view of the new ground(s) of rejection because the arguments do not apply to any of the updated rejections identified for the newly amended claims.
Claim Objections
Claim(s) 1-10 is/are objected to because of the following informalities:
Claim 1 recites “the linkage or pledge” in (b)(iii)(B). Examiner suggests amending to, e.g., “the linkage or the pledge” or similar, if intended. Referenced elements should be explicitly referenced. Similarly, claim 1 recites “the burning, staking, freezing, locking or accounting operation” in (c)(ii). Examiner suggests amending to, e.g., “the burning operation, the staking operation, the freezing operation, the locking operation, or the accounting operation” or similar, if intended. Like deficiencies are repeated in numerous instances throughout the claims 1-10 when listing elements, requiring appropriate correction.
Claim 1 recites “to revert their tokenized stated” (emphasis added) in (e)(ii). Referenced elements must be explicitly referenced.
Claim 1 recites “corresponding to that pledged asset” (emphasis added) in (e)(iii). Referenced elements must be explicitly referenced.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 1-10 is/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. Particularly:
Regarding claim 1, the phrase “including systems configured to maintain […]” in section (a) renders the claim indefinite because it is unclear whether the limitation(s) following the phrase are part of the claimed invention. See MPEP § 2173.05(d). Intended limitations must be positively recited (e.g., “comprising at least one of […]” or similar, if intended). This “including […]” deficiency is further repeated multiple times throughout claim 1. Further, this deficiency is repeated throughout claims 2-10, which are rejected under similar rationale.
Claim 1 introduces “a tokenizable value” in (b)(ii), as well as “a tokenizable value” in (e)(ii). Subsequently, claims 1 and 4-7 throughout recite “the tokenizable value” and/or “the remaining tokenizable value”. There is unclear antecedent basis as to which introduced tokenizable value is being referred to by the repeated recitations of “the tokenizable value” and/or “the remaining tokenizable value”. Claims 2-3 and 8-10 incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1, (b)(iii)(A) is generally grammatically unclear and inconsistent. E.g., reciting “indicating (A): whether tokenizable value is assigned […] value transition constraints, whether or not labelled […] by the system, to a category”. Examiner suggests amending to, e.g., “indicating (A): whether tokenizable value is assigned […] value transition constraints, whether the value transition constraints are labelled […] by the system, to a category” or similar, if intended. Claims 2-10 incorporate this deficiency of their parent claim, and are rejected under like rationale.
Claim 1 introduces “a lifecycle control state” in (b)(iii)(B), as well as “whose lifecycle control state” in (c)(i). Subsequently, claims 1 and 5 throughout recite “the lifecycle control state”. There is unclear antecedent basis as to which introduced lifecycle control state is being referred to by the recitations of “the lifecycle control state”. Claims 2-4 and 6-10 incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 introduces “underlying assets or underlying reserves” in (d)(i)(B), as well as introduces “underlying assets or underlying reserves” in (d)(ii). Subsequently, claim 1 recites “the corresponding underlying assets or underlying reserves” in (e)(ii). There is unclear antecedent basis as to which introduced underlying assets or underlying reserves is being referred to by the recitations of “the underlying assets or underlying reserves”. Claims 2-10 incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 introduces “asset tokens” in (b)(iv), as well as introduces “asset tokens” in (c)(i) (and in other locations). Subsequently, claim 1 recites “the asset tokens” throughout. There is unclear antecedent basis as to which introduced asset tokens is being referred to by recitations of “the asset tokens” throughout. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 introduces “lifecycle control state” throughout, and claim 5 similarly introduces “lifecycle control state”. Subsequently, claim 5 recites “the lifecycle control state”. There is unclear antecedent basis as to which introduced lifecycle control state is being referred to by recitations of “the lifecycle control state”.
Claim 1 recites “the originating lifecycle instance” in (c)(i). There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites “the same lifecycle state” in (c)(i). There is insufficient antecedent basis for this limitation in the claim.
Claim 1 introduces “a minting ratio”, and claim 6 similarly introduces “a minting ratio”. Subsequently, claim 6 recites “the […] minting ratio”. There is unclear antecedent basis as to which introduced minting ratio is being referred to by recitations of “the minting ratio”.
Claim 1 introduces “any subsequent minting operation”, as well as introduces “each minting operation”. Subsequently, claim 1 recites “the minting operation”. There is unclear antecedent basis as to which introduced minting operation is being referred to by recitations of “the minting operation”. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 introduces “digital currency units” in multiple instances throughout claim 1. Subsequently, claim 1 recites “the digital currency units”. There is unclear antecedent basis as to which introduced digital currency units is being referred to by recitations of “the digital currency units”. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 recites “the detokenization request” in (e)(i). There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites “the lifecycle architecture” in (e)(ii). There is insufficient antecedent basis for this limitation in the claim.
Claim 1 introduces “operation” in multiple separate instances throughout claim 1. Subsequently, claim 1 recites “the operation”. There is unclear antecedent basis as to which introduced operation is being referred to by recitations of “the operation”. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 recites “the reverted token or value” in (e)(ii). There is insufficient antecedent basis for this limitation in the claim. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 recites “the corresponding asset” in (e)(ii). There is insufficient antecedent basis for this limitation in the claim. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 recites “the lifecycle instance” in (e)(ii). There is insufficient antecedent basis for this limitation in the claim. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 recites “the same lifecycle record” in (e)(ii). There is insufficient antecedent basis for this limitation in the claim. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 recites “the detokenization operation” in (e)(ii). There is insufficient antecedent basis for this limitation in the claim. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 recites “the corresponding lifecycle instance” in (e)(ii). There is insufficient antecedent basis for this limitation in the claim. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 recites “the state reversion event” in (e)(iii). There is insufficient antecedent basis for this limitation in the claim. Claims 2-10 include/incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 1 introduces “an asset” and “a validated underlying asset” throughout. Subsequently, claim 3 recites “the asset”. There is unclear antecedent basis as to which introduced asset is being referred to by recitations of “the asset”.
Claim 5 recites “the lifecycle” in (f). There is unclear antecedent basis for this limitation in the claim (i.e., to which of the prior introduced lifecycles of claim 1 is it referencing).
Claim 6 recites “the number” throughout (e.g., in “(a)”). There is insufficient antecedent basis for this limitation in the claim.
Claim 1 introduces “a programmable redemption ratio” (e.g., (d)(ii)). Claim 6 similarly introduces “a tokenization ratio” in (a). Subsequently, claim 6 recites “the ratio”. There is unclear antecedent basis as to which ratio is being referred to by “the ratio”.
Claim 6 recites “the corresponding proportion” in (c). There is insufficient antecedent basis for this limitation in the claim.
Claim 6 recites “the relationship” throughout (e.g., in “(a)”). There is insufficient antecedent basis for this limitation in the claim.
Objected Subject Matter
Claim(s) 1-10 would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action. Further, care should be taken to not introduce further 35 U.S.C. 112 (or other) issues during amendment.
The following is an examiner’s statement of reasons for allowance (in accordance with MPEP 1302.14): The primary reason for allowance of the foregoing claims in the inclusion of a limitation in the independent claim which is not found in prior art references. Specifically, amended claim 1 recites, inter alia, “(a) a network of computing nodes configured to execute lifecycle processes of asset tokenization, conversion, redemption, and detokenization, the lifecycle processes being implementable by any combination of smart contracts, off-chain applications, backend systems, or hybrid architectures, including systems configured to maintain, update or interact with a ledger; (b) a tokenization module, operable by at least one processor and stored on a non- transitory computer-readable medium, configured to: (i) receive and validate asset data relating to an asset from one or more data sources, the asset data comprising valuation data, pricing data, contractual or asset reference data, ownership data, identity verification data, or pledged or linked state data relating to the asset, and validate the asset data using system-enforced programmable integrity logic configured to evaluate data integrity including consistency, accuracy, and completeness; (ii) determine a tokenizable value for the asset based on the validated asset data, using valuation, pricing, external data feed ingestion, or system-configured computation logic, and record the tokenizable value in the ledger for use in subsequent lifecycle operations;(iii) generate lifecycle control data associated with the tokenizable value determined under sub-element (ii), the lifecycle control data being based on at least the validated asset data received under sub-element (i) and the tokenizable value, the lifecycle control data indicating:(A) whether the tokenizable value is assigned, explicitly or implicitly including classification inferred from system-enforced lifecycle behaviour, transformation permissions, or value transition constraints, whether or not labelled as a discrete category by the system, to a category representing a transformation classification determined by lifecycle behaviour enforced by the computing system, comprising category (A), a bidirectional transformation 2 class, or category (B), a non-bidirectional transformation class within the computing system; and (B) whether the tokenizable value is linked to, or pledged in relation to, a validated underlying asset represented by the validated asset data such that minting, conversion, redemption, or detokenization authority derives from the linkage or pledge; and record the lifecycle control data in a governing persistent lifecycle record stored in the ledger or in a persistent system record synchronized with the ledger, thereby establishing a lifecycle control state comprising any encoded system enforced condition, representation, or constraint recorded in or enforced by the computing system that governs whether a lifecycle transition is permitted, the lifecycle control state comprising machine-enforced validation conditions evaluated by the computing system prior to execution of each lifecycle operation and configured to automatically prevent execution of any lifecycle transition inconsistent with recorded lifecycle constraints; (iv) responsive to the lifecycle control data indicating category (A), mint asset tokens linked to the underlying asset validated under sub-element (i) based on the tokenizable value using a system-configured tokenization ratio, record the minted asset tokens in the ledger, and permit bidirectional conversion between the asset tokens and digital currency units by the conversion module; (v) responsive to the lifecycle control data indicating category (B), provide the tokenizable value and the lifecycle control data to the conversion module and restrict the conversion module from performing bidirectional conversion, by preventing execution of any reverse lifecycle transition inconsistent with the lifecycle control state; and (vi) store and manage asset token states in the ledger using cryptographic or system- level integrity mechanisms that enforce completeness and accuracy of recorded states and that detect and prevent unauthorized state modification;3 (c) a conversion module, operable by at least one processor and stored on a non-transitory computer-readable medium, configured to: (i) for asset types whose lifecycle control state indicates category (A), execute a burning, staking, freezing, locking or accounting operation on corresponding asset tokens to render the asset tokens unavailable for reuse in any subsequent minting operation; and for asset types whose lifecycle control state indicates category (B), utilize the tokenizable value recorded under element (b)(ii) as the basis for minting asset tokens or digital currency units, ensuring that each unit of tokenizable value is consumed once within a lifecycle and rendered permanently unavailable for reuse within the originating lifecycle instance and prevented from re-entering the same lifecycle state without creation of a new validated lifecycle record; (ii) compute an amount of asset tokens or digital currency units to mint by applying a programmable minting ratio, wherein for asset types designated under category (B) the programmable minting ratio is applied to the tokenizable value determined under element (b)(ii), and for asset types designated under category (A) the programmable minting ratio is applied to the quantity of asset tokens subjected to the burning, staking, freezing, locking, or accounting operation under element (c)(i); (iii) record, in the ledger, each minting operation together with: (A)a corresponding value adjusting event performed under element (c)(i),comprising the burning, staking, freezing, locking, or accounting operation applied to the asset tokens or to tokenizable value units maintained by the system; and (B) a resulting token state after completion of the minting operation; and (iv) synchronize conversion events with processes executed by the computing system to enforce lifecycle conditions through cross-module state verification and enforcement preventing over minting, double spending, or duplication of value across the ledger; (d) a redemption module, operable by at least one processor and stored on a non-transitory computer-readable medium, configured to: (i) execute a burning, locking, freezing, revoking, staking, or reversing accounting 4 entries operation on asset tokens or digital currency units to:(A) reinstate asset tokens for asset types designated under category (A); or (B) effect release, transfer, or settlement of underlying assets or underlying reserves for asset types designated under category (B); and, where the digital currency units or the asset tokens correspond to native on-chain assets rather than underlying assets, apply the operation in a manner that transitions such native on-chain assets into a recorded lifecycle state suitable for subsequent detokenization, without releasing or affecting any underlying assets or underlying reserves; (ii) apply a programmable redemption ratio to determine a quantity of asset tokens to reinstate or a quantity of underlying assets or underlying reserves to release; (iii) record, in the ledger, each redemption operation, including the value adjusting event performed under sub-element (d)(i) and the resulting token state, thereby maintaining lifecycle consistency across tokenization, conversion, redemption, and detokenization; and (iv) synchronize redemption events with processes executed by the computing system to prevent unauthorized, inconsistent, or duplicative redemption actions; (e) a detokenization module, operable by at least one processor and stored on a non- transitory computer-readable medium, configured to:asset tokens or digital currency units to revert their tokenized state, and, where the asset tokens 5 correspond to pledged or linked assets, enable release of the corresponding underlying assets or underlying reserves; and where the ledger maintains a tokenizable value associated with the corresponding asset under element (b)(ii), apply a value state reversion operation that eliminates or irrevocably marks as exhausted the remaining tokenizable value associated with the lifecycle instance, thereby preventing further lifecycle operations under the same lifecycle record; wherein, for asset types designated under category (B), execution of a redemption operation that fully satisfies lifecycle exit conditions is treated by the system as satisfying the detokenization operation for the corresponding lifecycle instance, such that redemption and detokenization may occur as a merged lifecycle event while remaining governed by the lifecycle control state, thereby enforcing terminal lifecycle closure and prohibiting reactivation of the lifecycle record; (iii) record, in the ledger, each detokenization operation, including the state reversion event performed under sub-element (e)(ii) and the resulting token state […] (f) a secure interface, operable by at least one processor and stored on a non-transitory computer-readable medium, configured to: (i) authenticate users or authorized agents and provide access to system-maintained information, including balances, statuses, or other lifecycle related data associated with the asset tokens or the digital currency units; (ii) retrieve ledger recorded or system recorded transaction histories relating to the asset tokens or the digital currency units; and (iii) enable secure initiation of tokenization, conversion, transfer of asset tokens or digital currency units, redemption, or detokenization operations, and cause execution 6 of the corresponding operations by a set of modules comprising the tokenization module, the conversion module, the redemption module, and the detokenization module ("the lifecycle modules"), in accordance with permissions enforced by the system; and (g) wherein the system is configured to autonomously coordinate execution and interdependence of the lifecycle modules through enforced inter-module state validation and synchronized execution constraints comprising machine-executed validation conditions that prevent inconsistent lifecycle states, including conditional and interdependent state transitions that enforce a unified closed-circuit lifecycle, with cryptographic recording of resulting state transitions in the ledger to enforce asset integrity.
Art found of record, e.g., the combination of Sliwka et al. (US20210082044; hereinafter “Sliwka”) teaches a computing system for autonomous asset tokenization and digital currency management, the system comprising: (a) a network of computing nodes configured to execute one or more of the processes of asset tokenization, digital currency issuance, redemption, or detokenization, utilizing smart contracts, off-chain applications, or a hybrid thereof; (b) a tokenization module, operable by at least one processor and stored on a non-transitory computer-readable medium, configured to perform at least one of the following: (i) receive and validate asset data from one or more data sources, including trusted sources where applicable; (ii) determine a tokenizable value for an asset based on asset data, valuation or statistical models, or other parameters, including verifying the value or availability of reserves or asset pools that hold assets for tokenization; (iii) trigger and flag underlying assets as pledged in the system when applicable; (iv) mint asset tokens or digital currency using the tokenizable value and/or a predetermined tokenization ratio, subject to conditions governing asset status; or (v) store and manage the asset tokens in a ledger that employs a cryptographic commitment scheme or standard enterprise data integrity protocols to ensure data integrity; wherein the system is configured such that any implementation of asset tokenization either requires that at least one of redemption (d) or detokenization (e) be performed, or operatively enables the minting of digital currency (c); (c) a conversion module, operable by at least one processor and stored on a non- transitory computer-readable medium, configured to perform one or more of the following functions: (i) execute a token burning, staking, freezing or locking operation on asset tokens to enable digital currency minting; (ii) calculate the amount of digital currency to mint by applying a programmable minting ratio enforced by a smart contract to prevent excess issuance; (iii) generate a cryptographically secured proof-of-minting, verifiably linked to a prior proof-of-burning, staking, locking, or freezing event recorded in a digital ledger; or (iv) synchronize conversion events with system processes to enforce conditions preventing over-minting; wherein the conversion module is required in embodiments involving digital currency issuance but is not necessary for systems performing tokenization, redemption and/or detokenization without digital currency minting; (d) a redemption module, optionally included where required to perform redemption, operable by at least one processor and stored on a non-transitory computer-readable medium, configured to perform one or more of the following functions: (i) execute a token burning, locking, freezing, revoking, staking, or reversing accounting entries operation on digital currency or asset tokens to: (A) trigger asset token reinstatement; (B) cause the digital currency to cease functioning as an independent unit of value; or (C) facilitate the release or transfer of pledged or underlying assets upon fulfilment of predefined conditions; (ii) apply a programmable redemption ratio to restore asset tokens or to release or transfer underlying assets; (iii) generate cryptographically secured proof-of-redemption recorded in a digital ledger; and (iv) synchronize redemption events with system processes to prevent unauthorized transactions; wherein the redemption module (d) and the detokenization module (e) are configured to operate independently, in conjunction with one another, or in sequence; (e) a detokenization module, optionally included where required to perform detokenization, operable by at least one processor and stored on a non-transitory computer-readable medium, configured to perform one or more of the following functions: (i) execute a token burning, locking, freezing, revoking, rendering inoperable, or reversing accounting entries operation on asset tokens to revert their tokenized state or release pledged or underlying assets, temporarily or permanently; (ii) verify that a sufficient quantity and valid classification of asset tokens is available for detokenization; (iii) reassign, reclassify, or modify asset tokens in a manner that alters their contractual obligations, asset backing, metadata, or intended purpose, whether executed via a smart contract update, an off-chain application, or other system processes; (iv) generate cryptographically secured proof-of-detokenization recorded in a digital ledger; (v) transition a pledged asset to an unpledged state when all asset tokens have been detokenized; (vi) releasing pledged or underlying assets, in whole or in part, upon satisfaction of at least one predefined condition, comprising: (A) expiration of a contractual, staking, or pledge period verified by timestamps or contract data; (B) a user-initiated detokenization request executed via a secure interface or digital wallet; or (C) compliance with regulatory, legal, or contractual requirements, or predefined governance controls mandating detokenization and/or asset release, including system logic and/or governance conditions encoded in a smart contract or programmable rule set, such as automatic release upon expiration or penalties for failure to redeem; wherein the redemption module (d) and the detokenization module (e) are configured to operate independently, in conjunction with one another, or in sequence; (f) a secure computing interface for authenticated user interactions with digital asset tokens and/or digital currency accounts, configured to perform at least one of the following: (i) provide authenticated access to balance inquiries; (ii) retrieve and display transaction history; or (iii) enable secure initiation of any system-supported function, including but not limited to tokenization, conversion, transfer, redemption, or detokenization; and (g) wherein the system is configured to autonomously manage aspects of the lifecycle of asset tokenization, redemption, and/or detokenization, and optionally, digital currency issuance wherein implementations optionally support bidirectional convertibility, real-time proof-of-reserves, and automated compliance (see as particularly presented in Non-Final Office Action dated 10/21/2025), however fails to teach the newly amended language in combination.
Other prior art, e.g., Dubrofsky (US20200327609) teaches utilizing collateralization ratios for controlling smart contract execution and tokenizing smart contracts/financial instruments, as well as minting of DAI digital currency (see, e.g., Dubrofsky at abstract, [0103], and [0160-161]), yet similarly fails to remedy the aforementioned deficiency. Madisetti et al. (US20190081789) teaches a system for receiving collateral inputs and using the collateral inputs to mint digital currencies (see, e.g., abstract, [0025], [0084-086], and [0102-106]), yet similarly fails to remedy the aforementioned deficiency. Kozhan et al. (NPL: “Decentralized Stablecoins and Collateral Risk”; September 1, 2021) teaches a system for receiving collateral, determining a value of the collateral, and minting DAI tokens based on predefined rations pertaining to the value of the collateral (see, e.g., abstract and sections 3-4), yet similarly fails to remedy the aforementioned deficiency.
None of the prior art of record, either taken by itself or in any combination, would have anticipated or made obvious all features of the invention of the present application claim 1 at or before the time it was filed. Dependent claims 2-10 (of claim 1) incorporate the limitations of their parent claim, and are objected for at least the same rationale.
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA RAYMOND WHITE whose telephone number is (571)272-4365. The examiner can normally be reached Monday-Thursday, & Alternate Fridays.
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, Taghi Arani can be reached at 5712723787. 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.
/J.R.W./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438