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 .
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 non-structural 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 limitations are: “contract execution unit” and “contract verification unit in” independent claim 10 and dependent claims 11-12.
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. (See paragraphs 47, 58-59, and 87 and Figures 3-4)
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 recite sufficient structure to perform the claimed function so as to avoid 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 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 10-11 and 13-14 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.
Referring to claim 10, the claim recites “and the second execution result to consensus verification nodes; performing, by the consensus verification node”.
It is unclear whether it is only one of the consensus nodes doing the performing step or if it is each of the consensus verification nodes doing the performing. The Examiner is interpreting that the performing is done by each consensus verification node for examination purposes.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4, 10-11, 13-16, 18-21 and 24 are rejected under 35 U.S.C 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-4 and 18 recite a method (process), claims 10-11 and 13-14 recite another method (process), claims 15, 19-21, and 24 recite an electronic device (machine), and claim 16 recites a non-transitory computer-readable medium (manufacture) and therefore fall into a statutory category.
Step 2A – Prong 1 (Is a Judicial Exception Recited?):
Referring to claims 1-4, 10-11, 13-16, 18-21 and 24, the claims recite a manner of verifying information associated with an agreement, which under its broadest reasonable interpretation covers concepts covered under the Certain Methods of Organizing Human Activity grouping of abstract ideas.
The abstract idea portion of the claims is as follows:
(Claim 1)
A method for data verification, comprising: performing a first verification on data-to-be-verified, wherein the data-to-be-verified comprises a first contract parameter, an identifier of a smart contract, and a first execution result;
processing, after the first verification is passed, the first contract parameter to obtain a second contract parameter, and executing the [smart] contract according to the second contract parameter to obtain a second execution result;
sending the second contract parameter, the identifier of the smart contract, and the second execution result [to consensus verification nodes] for a consensus verification;
wherein processing the first contract parameter to obtain the second contract parameter comprises: desensitizing the first contract parameter to obtain the second contract parameter;
desensitizing the first contract parameter to obtain the second contract parameter comprises: performing a hash operation on the first contract parameter to obtain the second contract parameter; the first execution result is a result of executing an intelligent contract corresponding to the identifier of a smart contract;
[and an operating agency system executing the first verification is different from operating agency systems corresponding to the consensus verification nodes].
(Claim 10)
A method for data verification, comprising: sending, [by a contract execution unit of an operating agency system], a first contract parameter, an identifier of the smart contract, and a first execution result [to a contract verification unit of the operating agency system] for a first verification;
performing the first verification [by the contract verification unit of the operating agency system], processing, after the first verification is passed, the first contract parameter to obtain a second contract parameter, and executing a [smart] contract according to the second contract parameter to obtain a second execution result;
sending the second contract parameter, the identifier of the smart contract, and the second execution result [to consensus verification nodes];
performing,[ by the consensus verification node], a consensus verification according to the second contract parameter, the identifier of the smart contract, and the second execution result;
wherein the processing, [by the contract verification unit of the operating agency system], the first contract parameter to obtain the second contract parameter comprises: desensitizing the first contract parameter to obtain the second contract parameter [by the contract verification unit of operating agency system];
desensitizing the first contract parameter to obtain the second contract parameter comprises: performing a hash operation on the first contract parameter to obtain the second contract parameter;
the first execution result is a result of executing an intelligent contract corresponding to the identifier of a smart contract;
[and an operating agency system executing the first verification is different from operating agency systems corresponding to the consensus verification nodes].
(Claim 15)
[ An electronic device for data verification, comprising: at least one processor; and a storage apparatus, configured to store at least one program, wherein when the at least one program is executed by the at least one processor, the at least one processor is enabled to implement following actions:]
perform a first verification on data-to-be-verified, wherein the data-to-be-verified comprises a first contract parameter, an identifier of a smart contract, and a first execution result;
process, after the first verification is passed, the first contract parameter to obtain a second contract parameter, and execute the [smart] contract according to the second contract parameter to obtain a second execution result;
send the second contract parameter, the identifier of the smart contract, and the second execution result [to consensus verification nodes] for a consensus verification;
wherein the at least one processor is enabled to implement the following actions: desensitize the first contract parameter to obtain the second contract parameter, perform a hash operation on the first contract parameter to obtain the second contract parameter;
the first execution result is a result of executing an intelligent contract corresponding to the identifier of a smart contract;
[and an operating agency system executing the first verification is different from operating agency systems corresponding to the consensus verification nodes].
(Claim 16)
[ A non-transitory computer-readable medium, storing a computer program, wherein the program, when executed by a processor, the processor is enabled to implement following actions:]
perform a first verification on data-to-be-verified, wherein the data-to-be-verified comprises a first contract parameter, an identifier of a smart contract, and a first execution result;
process, after the first verification is passed, the first contract parameter to obtain a second contract parameter, and execute the [smart] contract according to the second contract parameter to obtain a second execution result;
send the second contract parameter, the identifier of the smart contract, and the second execution result [to consensus verification nodes] for a consensus verification;
[wherein the processor is enabled to implement following actions]: desensitize the first contract parameter to obtain the second contract parameter;
performing a hash operation on the first contract parameter to obtain the second contract parameter;
the first execution result is a result of executing an intelligent contract corresponding to the identifier of a smart contract;
[and an operating agency system executing the first verification is different from operating agency systems corresponding to the consensus verification nodes].
Here the claims recite concepts capable of being performed in Certain Methods of Organizing Human Activity, in particular commercial or legal interactions (including agreements in the form of contracts) but for the recitation of generic computer components. In the present application concepts reciting a manner of verifying information associated with an agreement. (See paragraph 47).
If a claim limitation, under its broadest reasonable interpretation, covers concepts capable of being performed in commercial or legal interactions (including agreements in the form of contracts), it falls under the Certain Methods of Organizing Human Activity grouping of abstract ideas. See MPEP 2106.04.
Step 2A-Prong 2 (Is the Exception Integrated into a Practical Application?):
The Examiner views the following as the additional elements:
A smart contract. (See paragraph 3)
A consensus verification node. (See paragraph 58)
A contract execution unit. (See paragraphs 58-59, and 87 and Figures 3-4)
An operating agency system. (See paragraph 47)
Contract verification unit. (See paragraphs 47, 58, 87 and Figures 3-4)
An electronic device. (See paragraph 90)
At least one processor/ a processor. (See paragraph 91)
A storage apparatus. (See paragraphs 91-92)
At least one program. (See paragraphs 91 and 93)
A non-transitory computer-readable medium. (See paragraph 93-94)
A computer program/program. (See paragraph 93)
These additional elements are recited at a high-level of generality such that they act to
merely “apply” the abstract idea using generic computing components and do not integrate the
abstract idea into a practical application. (See MPEP 2106.05 (f)) The combination of these additional elements and/or results oriented steps are no more than mere instructions to apply the exception using generic computing components. (See Id.)
Regarding, “an operating agency system executing the first verification is different from operating agency systems corresponding to the consensus verification nodes” the examiner views these additional elements merely indicate the particular technological environment or field of use in which to apply the abstract idea, in this instance defining what device is executing the first verification as part of the arrangement. See MPEP 2106.05 (h)
Accordingly, even in combination 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.
Step 2B (Does the claim recite additional elements that amount to Significantly More than the Judicial Exception?):
As noted above, the claims as a whole merely describes a method and non-transitory computer readable medium that generally “apply” the concepts discussed in prong 1 above. (See MPEP 2106.05 f (II)) In particular applicant has recited the computing components at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. As the court stated in TLI Communications LLC v. AV Automotive LLC, 823 F.3d 607, 613 (Fed. Cir. 2016) merely invoking generic computing components or machinery that perform their functions in their ordinary capacity to facilitate the abstract idea are mere instructions to implement the abstract idea within a computing environment and does not add significantly more to the abstract idea. Regarding the limitations of “an operating agency system executing the first verification is different from operating agency systems corresponding to the consensus verification nodes” is generally well understood, routine and conventional information as taught by the Specification. See paragraph 59 of the Specification. Accordingly, these additional computer components do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea and as a result the claim is not patent eligible.
Dependent claim 2 further defines the abstract idea as identified. Additionally, the claim recites the generic smart contract (See paragraph 3) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 2 is considered to be patent ineligible.
Dependent claim 3 further defines the abstract idea as identified. Additionally, the claim recites the generic smart contract (See paragraph 3) and consensus verification node (See paragraph 58) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 3 is considered to be patent ineligible.
Dependent claims 4, 14, 17-18, and 24 further define the abstract idea as identified. Therefore claims 4, 14, 17-18, and 24 are considered to be patent ineligible.
Dependent claim 11 further defines the abstract idea as identified. Additionally, the claim recites the generic contract verification unit (See paragraph 58), operation agency system (See paragraph 47), and smart contract (See paragraph 3) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 11 is considered to be patent ineligible.
Dependent claim 13 further defines the abstract idea as identified. Additionally, the claim recites the generic consensus verification node (See paragraph 58) and smart contract (See paragraph 3) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 13 is considered to be patent ineligible.
Dependent claims 19-20 further define the abstract idea as identified. Additionally, the claim recites the generic at least one processor (See paragraph 91) and smart contract (See paragraph 3) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 19-20 are considered to be patent ineligible.
Dependent claim 21 further defines the abstract idea as identified. Additionally, the claim recites the generic at least one processor (See paragraph 91) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 21 is considered to be patent ineligible.
In conclusion the claims do not provide an inventive concept, because the claims do not recite additional elements or a combination of elements that amount to significantly more than the judicial exception of the claims. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and the collective functions merely provide conventional computer implementation. Therefore, whether taken individually or as an order combination, the claims are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Response to Arguments
Applicant's arguments filed December 18, 2025 have been fully considered but they are not persuasive.
Applicant’s amendments and arguments, on page 9 of the Remarks, regarding the 112 (b) rejection the Examiner finds Applicant’s amendments persuasive. Therefore, the Examiner has withdrawn the 112 (b) rejection. The Examiner however notes the new 112 (b) rejection in response to Applicant’s amendments.
Applicant’s amendments and arguments, on pages 9-13 of the Remarks, regarding the 101 rejection the Examiner finds unpersuasive.
Applicant argues the claims are directed to a distributed verification architecture across independently operated entities that addresses a technical problem inherently arising from the characteristics of computer system. According to Applicant, this technical problem is when the contract execution unit and the verification unit belong to the same operating agency the unit constitute a single point of failure or single trust domain leading to a lack of variability in addition to other problems. Applicant contends the claims solve this through:
1) preliminary verification: the verification unit of operation agency system performs a local check on the result generated by its own execution unit, reflected in “performing a verification on data-to-be verified”,
2) secure parameter transformation by the operating agency system that enables cross institutional verification without exposing sensitive data, thereby technically unifying privacy preservation with verifiability, reflected in “desensitizing the first contract parameter to obtain the second contract parameter by performing a hash operation on the first contract parameter, executing the smart contract according to the second contract parameter to obtain a second execution result”,
and 3) cross institutional consensus verification: The second contract parameter, the identifier of the smart contract, and the second execution result are sent to consensus verification nodes operated by different agencies. Applicant contends the consensus verification nodes independently execute the same smart contract using the second contract parameter and determine whether consensus is reached, corresponding to "sending the second contract parameter, the identifier of the smart contract, and the second execution result to a consensus verification node for a consensus verification" recited in the amended Claim 1. According to Applicant this fundamentally resolves the "self-verification" paradox and enhances the robustness, security, and reliability of distributed computer systems against single-point failures or malicious insider attacks.
The Examiner respectfully disagrees, viewing the distributed environment is the general field of use where to apply the abstract idea. The purported improvements to accuracy, verifiability, and ensuring of privacy as claimed are improvements to the underlying commercial endeavor where to apply the abstract idea rather than an improvement to the distributed environment or any other consideration enumerated under MPEP 2106.04(d) to constitute integration into a practical application. Further the portions of the claims Applicant references as constituting the additional elements that provide for these purported benefits the Examiner considers to be a part of the abstract idea defining a portion of the coordination for the verification i.e. performing a verification of data to be verified, desensitizing the first contract to obtain the second contract parameter used in executing the contract, and sending the second contract parameter, the identifier of the smart contract, and second execution result. In other words, the Examiner views the purported improvement of self-verification is obtained through the performance of the abstract idea rather than the additional elements. The Examiner viewed the additional elements of smart contract and consensus verification nodes as mere instructions to apply the abstract idea using generic computing components that do not integrate the abstract idea into a practical application or adds significantly more to the abstract idea as claimed.
According to Applicant the claims do not implement an abstract commercial verification process but instead integrates abstract concepts into a practical application of secure privacy preserving cross institutional collaborative distributed computing platform, where this platform is not a mere vessel for an abstract idea but a technical system with a clear technical objective, specific component interactions and an innovative data flow. According to Applicant the claims provide for the following:
1) the claims provide a concrete technical means, cryptographic hashing to desensitize the first contract parameter to obtain the second contract parameter thereby achieving privacy preserving verification in a distributed environment. Hash functions as fundamental tools in computer science and cryptography are creatively applied here to smart contract execution: original sensitive parameters (e.g., user identity, asset amounts) are transformed into semantically equivalent yet information-obscured hash values. This allows consensus nodes to independently re-execute the smart contract and verify result consistency without accessing raw data. This mechanism resolves a long-standing core tension in blockchain and multi-party computation: how to enable trustworthy verification without compromising data confidentiality. This is clearly not a routine or generic computer function, but a substantive technical improvement to the security model of distributed systems.
2) the claims explicitly specify that "the operating agency system performing the first verification is different from the operating agencies corresponding to the consensus verification nodes." This defines a decentralized, multi-party check-and-balance system architecture, fundamentally distinct from traditional single-party trust models (e.g., a single cloud provider or internal audit system). In this architecture, the executor cannot unilaterally manipulate the verification outcome, and verifiers cannot access sensitive business data, thus establishing technical trust among mutually distrustful parties based on cryptography and consensus protocols. This structural design is not a rearrangement of business organization, but a re-engineering of the trust mechanism in distributed systems, constituting an innovation in computer system architecture.
The Examiner respectfully disagrees viewing the technical arrangement as presently claimed only indicates the field of use to apply the abstract idea and does not provide for integration into a practical application or adds significantly more. Further the limitations regarding the desensitizing and hashing steps from precluding their performance in the recited abstract idea as claimed. Indeed, there is no technical specificity in terms of how the desensitizing or hashing the information is performed or how the distributed architecture is configured such that it can provide such a technical improvement. Rather the claims only recite concepts covering what device performs a particular step of the abstract idea in a particular of use in which to apply the abstract idea.
Applicant argues the claims provide an ordered combination of elements embodies an "inventive concept" that is "significantly more" than any underlying abstract idea. According to Applicant even if "verification" were deemed an abstract concept, the additional elements in the claim go far beyond merely "implementing the concept on a generic computer":
(1) Cryptographic Data Transformation: The use of hash operations to process contract parameters is a specific, non-abstract data transformation step. It ensures data privacy and security, which is a prerequisite for cross- institutional technical collaboration.
(2) Non-Conventional, Multi-Centric System Architecture: The separation of execution units, verification units, and consensus nodes, each controlled by different operating agency systems, forms a specific collaborative pattern deliberately designed to enhance system credibility. This is not a conventional way of using computers.
(3) Ordered Combination Yields Technical Effects: The integration of these elements produces a synergistic technical effect: reliable verification of distributed computation results without compromising data privacy. This improves the capabilities of a technical field (distributed computing systems), making them more secure and trustworthy.
The Examiner respectfully disagrees first reiterating that they view the hashing and desensitizing concepts are recited at a high level of the generality and constitute a portion of the recited abstract idea rather than being additional elements that can integrate the abstract idea into a practical application or add significantly more to the abstract idea. The Examiner views the claims as recited are improving a commercial transaction by improving the privacy however this is an improvement to the abstract idea or other commercial endeavor rather than an improvement to technology or other consideration enumerated under MPEP 2106.04 (d). The Examiner further disagrees viewing the technical arrangement as presently claimed only indicates the field of use to apply the abstract idea and does not provide for integration into a practical application or adds significantly more. The additional elements alone or when considered in combination only inform a reader to apply the abstract idea using generic computing components or define the field of use where to apply the abstract idea rather than provides for integration into a practical application or adds significantly more.
.
Applicant contends, the overall inventive concept of the present disclosure constitutes a complete and self-consistent technical solution. According to Applicant, its essence is to address, at a technical level, the core problem of low credibility in smart contract verification caused by the execution and verification functions residing within the same operating agency system and does not "graft" existing business rules onto a computer system; but rather introduces cryptographic data transformation and constructs a decentralized, multi-party balanced architecture to establish technical trust among distrustful participants based on cryptography and consensus protocols.
The Examiner respectfully disagrees maintaining that the claims as drafted recite concepts for providing a manner of verifying information associated with an agreement. The recited abstract idea is merely applied using generic computing components and do not provide for an improvement to technology but rather improve the concept of verifying information in an agreement. The aspects pertaining to the verification of the smart contract, including the hashing of information as claimed, are steps of the recited abstract idea that is merely applied in a generic field of use using generic computing components for facilitating the performance of the verification of information with an information and does not provide for any technical benefits as proffered by Applicant.
Therefore, the Examiner has maintained the 101 rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wei et al. (US 20200342092) – directed to securely executing smart contract operations in a trusted execution environment.
Madl et al. (US 20200252202) – directed to cross-chain validation.
Novotny (US 20210314155) - directed to trusted ledger stamping.
Deng et al. (US 20220067715) – directed to starting smart contracts.
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 MICHAEL J MONAGHAN whose telephone number is (571)270-5523. The examiner can normally be reached on Monday- Friday 8:30 am - 5:30 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, Sarah Monfeldt can be reached on (571) 270-1833. 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.
/M.J.M./Examiner, Art Unit 3629 /SARAH M MONFELDT/Supervisory Patent Examiner, Art Unit 3629