DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 12/01/2025.
Claims 1, 2 and 21 are amended.
Claims 4, 20 and 22- 25 are cancelled.
Claims 1-3, 5-19 and 21 are pending.
Claims 1-3, 5-19 and 21 have been examined.
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
Applicant's arguments filed 12/01/2025 have been fully considered but they are not persuasive.
101
Applicant argues “To avoid this and save on computing and network resources, then a third party may instead wish to rely on a second-hand report of the blockchain transactions from the first and/or second party. However, this then creates another technical issue to be addressed, as it leaves open a security vulnerability in that one of the parties may maliciously make a false representation of the state of the blockchain… The presently claimed method provides an improved mechanism that achieves the best of both worlds, i.e. it combines the technical advantages of. a) avoiding the computational burden that the third party has to access each individual blockchain transaction in the set from the blockchain(s), but b) still exploiting the immutable nature of the blockchain to mitigate potential malicious activity by one of the first and second parties. This is achieved by requiring each of the first and second parties to record an attestation, i.e. a cryptographic digest, of the transactions they were involved with on a blockchain, and also in parallel to report the transactions to the third party. ”
First, Applicant’s description confirms that the third party is the technology performing the claims steps and more importantly, that the third party is not the blockchain, but rather it is interacting with parties that themselves interact with the blockchain. The recitation of a blockchain does not automatically make claims subject matter eligible, especially here, when the existing business process is using the blockchain as a storage means of a real world business process. As currently recited, the blockchain does not appear to be integral to the claims.
Secondly, it is clear the improvements are not technology based, for example, Applicant points out “avoiding the computational burden that the third party has to access each individual blockchain transaction in the set from the blockchain(s)”, the third party does not interact with the blockchain rather it receives information, “to report the transactions to the third party”. The receipt of information is not an improvement to the third party, it is an insignificant extra solution activity.
Additionally, to “save on computing and network resources, then a third party may instead wish to rely on a second-hand report of the blockchain transactions from the first and/or second party”, the third party “saving” resources by using the efforts of another entity is not an improvement but rather highlights their business practice and “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. For example, in Trading Technologies Int’l v. IBG, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019), the court determined that the claimed user interface simply provided a trader with more information to facilitate market trades, which improved the business process of market trading but did not improve computers or technology.” MPEP 2106.05(a) (II)” The rejection is maintained.
103
Applicant states “Jayachandran does not disclose receiving a report of some of the same transactions from two different clients or parties, as in claim 1 (claim 1 recites receiving a report of "said" set of transactions from both the first and second parities - the examiner does not seem to dispute that this clearly limits to the third party receiving a report for some of the same transactions from the first and second parties)… However, this does not mean that ordering service node 284 of Jayachandran (nor any other network element of Jayachandran) receives two separate reports of the same set of transactions from both clients 260 involved in the transactions of the set,… “If the objection is to be maintained, Applicants request that the Examiner confirm precisely: what network element in Jayachandran is being mapped to the first party of claim 1? what network element in Jayachandran is being mapped to the second party of claim 1? what network element in Jayachandran is being mapped to the second party of claim 1? what signal or message in Jayachandran is being mapped to the first report of claim 1?
what signal or message in Jayachandran is being mapped to the second report of claim 1? which transactions in Jayachandran are being read against the set of transactions of claim 1? ” Examiner disagrees.
Jayachandran is clear that there are in fact different clients and the reports are received from the different parties. It is unclear from Applicants proposed limitations in the Claims, what the “network element” is that Applicant is referring to in the recited claims. All Prior art, Jayachandran included, are not required to recite “Alice”, “Bob”, “etc.”, in the duplicated numerations Applicant has written for the “first party” that exactly mirrors the same steps of the “second party, to recite the functions performed as claimed. Jayachandran recites receiving blockchain data, ex. transactions, from multiple different parties.
Jayachandran - the method may include receiving reduced-step hashes and full-step hashes of a plurality of storage requests from a plurality of client applications, respectively. In 557, the method may include arranging the reduced-step hashes within a data block based on timing information such as a timestamp, etc. included in the storage requests. Here, the storage requests may include different transactions from different parties on the blockchain… receiving a request from a client application to verify the data file.. the method may include storing a full-step hash of a data file and a reduced-step hash of the data file within a data block of a hash-linked chain of blocks of a blockchain. For example, the data file may include one or more of an audio file, a video file, a document, an image, and a multi-media file. …As another example, the determining may be based on an identifier within the request from the client (or other node), or the like. In some embodiments, the full-step hash of the data file and the reduced-step hash of the data file are both received from a different client application than the client application that submitted the request. (¶ 128-132, 145)
Additionally, the data blocks are in a set, for example, based on timestamps etc., so the transactions that are received are not just random sets of transactions. The rejection is maintained.
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-3, 5-19 and 21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claim 1 is directed to a method, and claim 21 is directed to a machine.
Step 2a.1– Identifying an Abstract Idea
The claims recite the steps of “receiving …report … observing … attestation recorded … checking that … report is consistent … and determining whether the indications in the first report indicate the same membership….” The recited limitations fall within mental process grouping of abstract ideas, specifically, observation and evaluation of transaction records. Accordingly, the claims recites an abstract idea.
See MPEP 2106.
Step 2a.2 – Identifying a Practical Application
The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application. The use of a distributed ledger or blockchain does not preclude the claim from reciting an abstract idea as the blockchain recites functions of a generic computer component, such as storing records.
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.
Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea.
Step 2b
The claim limitations recite “receiving …report … observing … attestation recorded … checking that … report is consistent … and determining whether the indications in the first report indicate the same membership….”” are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible.
Viewed as a whole, instructions/method claims recite the concept of mental process as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment.
Dependent claim 13 discuss functions in more descriptive detail of the steps geared toward the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
Claims 2-3, 5-12, 14-19 provide descriptive language surrounding the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
The claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 2-3, and 5-19 are also rejected.
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 1-3, 5-19 and 21 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.
Claims 1 and 21 recite “wherein the accessing of the first and second attestations is performed without the third party individually accessing the transactions of said set from a blockchain”. The claim is unclear and indefinite. The language is unclear whether Applicant intended that the limitation mean the third party does not access each transaction of the set individually, but can access them collectively, or whether the limitation means the third party does not itself, individually, access the transactions of the set. The claim limitations are unclear and indefinite. Dependent claims 2-3, and 5-19 are also rejected.
Claims 1, 2 and 21 recite “cryptographic transform” or “cryptographic transforms”. Where applicant acts as his or her own lexicographer to specifically define a term of a claim contrary to its ordinary meaning, the written description must clearly redefine the claim term and set forth the uncommon definition so as to put one reasonably skilled in the art on notice that the applicant intended to so redefine that claim term. Process Control Corp. v. HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. Cir. 1999). It is unclear what the disclosure and claims are attempting to use the words to mean. According to the disclosure(13, 17, 93, 106), “the first attestation comprising a first attestation value derived from the first party having applied a first transform to the indications reported in the first report … At the same time since the attestation recorded on the public is a transform of the set (preferably an irreversible transform) rather than the explicit indications (e.g. raw TxIDs), Also in principle, in alternative transaction formats, Bob′ address could simply comprise a copy of his public key, not necessarily a transform thereof such as a hash.” The term is indefinite because the specification does not clearly redefine the term. The term “cryptographic transform” is not recited in the disclosure, but the term “transform”, originally a verb, is used as an item at times, and others as a function to be applied. The claim language is unclear and indefinite. Dependent claims 2-3, and 5-19 are also rejected.
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.
Claims 1-3, 5-19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Jayachandran (US 20200379856)(“Jayachandran”), and further in view of Carver et al. (US 20200167779)(“ Carver”).
Regarding claims 1 and 21, Jayachandran discloses by a third party:from the first party, receiving a first report comprising an indication of each of a plurality of blockchain transactions involving the first party including at least the blockchain transactions in said set, the first report comprising one or more reporting messages sent at one or more times; from the second party, receiving a second report comprising an indication of each of a plurality of blockchain transactions involving the second party including at least some or all of the blockchain transactions in said set, the second report comprising one or more reporting messages sent at one or more times (¶ 93, 101-106, 128-132, 145-167)
Jayachandran - the method may include receiving reduced-step hashes and full-step hashes of a plurality of storage requests from a plurality of client applications, respectively. In 557, the method may include arranging the reduced-step hashes within a data block based on timing information such as a timestamp, etc. included in the storage requests. Here, the storage requests may include different transactions from different parties on the blockchain… receiving a request from a client application to verify the data file.. the method may include storing a full-step hash of a data file and a reduced-step hash of the data file within a data block of a hash-linked chain of blocks of a blockchain. For example, the data file may include one or more of an audio file, a video file, a document, an image, and a multi-media file. …As another example, the determining may be based on an identifier within the request from the client (or other node), or the like. In some embodiments, the full-step hash of the data file and the reduced-step hash of the data file are both received from a different client application than the client application that submitted the request. (¶ 128-132, 145)
accessing from a blockchain, via a storage node of a corresponding blockchain network, a first attestation recorded by the first party in at least one first blockchain transaction, the first attestation comprising a first attestation value being a cryptographic digest derived from the first party having applied a first cryptographic transform to the indications reported in the first report; accessing from a blockchain, via a storage node of a corresponding blockchain network, a second attestation recorded by the second party in a second blockchain transaction, the second attestation comprising a second attestation value being a cryptographic digest derived from the second party having applied a second cryptographic transform to the indications as reported in the second report, and the first and second blockchain transactions being separate from said set (¶ 86-94, 105, 106, 132, 133, 154-158)
Jayachandran - , the full-step hash of the data file may be generated by repeated performance of a hash function on the data file a first predetermined number of times, and the reduced-step hash of the data file may be generated by repeated performance of the hash function on the data file a second predetermined number of times that is less than the first predetermined number of times…performing an approximate hash verification on a media file stored on blockchain according to example embodiments. The method may be performed by a client node, a peer node, or the like. In 536, the method may include receiving a hashed data file from a blockchain peer node, where data of the hashed data file is previously stored within a hash-linked chain of blocks on a blockchain. In this example, the hashed data file may include a hash of one or more of an audio file, a video file, a document, an image, and a multi-media file…determining whether the hashed data file has been tampered with through an approximate hash verification of the hashed data file. In some embodiments, the full-step hash may include repeated performance of a hash function on the data file a first predetermined number of times, and the reduced-step hash comprises repeated performance of the hash function on the data file a second predetermined number of times that is less than the first predetermined number of times. (¶ 132, 133)
applying the first cryptographic transform to the indications reported in the first report to generate a first cryptographic output value: determining that the first cryptographic transform is equal to the cryptographic digest of the first attestation; applying the second cryptographic transform to the indications reported in the second report to generate a second cryptographic output value; determining that the second cryptographic output value is equal to the second attestation from the blockchain; and and(¶ 84-106, 134, 141-145, 164-191, 209)
Jayachandran - a length of a data value created by the reduced-step hash applied to the data file is equal to a length of a data value created by the full-step hash applied to the data file. In some embodiments, the determining may include generating a reduced-step hash of a local copy of the data file and verifying the retrieved hashed data file based on the reduced-step hash of the local copy of the data file. In some embodiments, the data file may include a media file that is stored off-chain while a hash result of the hashed data file is stored within a data block among the hash-linked chain of blocks. (¶ 134)
wherein the accessing of the first and second attestations is performed without the third party individually accessing the transactions of said set from a blockchain (¶ 86-94, 105, 106, 132, 133, 154-158)
Jayachandran - , the full-step hash of the data file may be generated by repeated performance of a hash function on the data file a first predetermined number of times, and the reduced-step hash of the data file may be generated by repeated performance of the hash function on the data file a second predetermined number of times that is less than the first predetermined number of times…performing an approximate hash verification on a media file stored on blockchain according to example embodiments. The method may be performed by a client node, a peer node, or the like. In 536, the method may include receiving a hashed data file from a blockchain peer node, where data of the hashed data file is previously stored within a hash-linked chain of blocks on a blockchain. In this example, the hashed data file may include a hash of one or more of an audio file, a video file, a document, an image, and a multi-media file…determining whether the hashed data file has been tampered with through an approximate hash verification of the hashed data file. In some embodiments, the full-step hash may include repeated performance of a hash function on the data file a first predetermined number of times, and the reduced-step hash comprises repeated performance of the hash function on the data file a second predetermined number of times that is less than the first predetermined number of times. (¶ 132, 133)
Jayachandran does not disclose determining whether the indications in the first report indicate the same membership of the set as the indications in the second report.
Carver teaches determining whether the indications in the first report indicate the same membership of the set as the indications in the second report (¶ 51, 68-71, 76-79, 102, 103)
Claim Interpretation – According to the disclosure(¶ 95, 111), “A Merkel tree (hash tree) has the useful property that to prove that a given leaf is a member of the set, one only needs the value of the leaf, the Merkel root, and the Merkle path between the leaf and root (i.e. the values of all the hashes along the path from leaf to root)…. As mentioned, a Merkle tree allows to prove that a candidate leaf is a member of the set given only the root and Merkle path. Hence only this need be stored and/or presented in the evidence, and not the indication (e.g. TxIDs) of Charlie's transactions with Alice.”
Carver- In performing validation, and upon receiving messages 503 for a segment, the receiving node element handling the segment validates the received transactions, computes the segment's Merkle tree, and upon completion sends message 506 to the element in the node handling the header. That element reconstructs the block header from the messages 506 for all segments and compares it to the header received from the mining node in message 505. If the headers match, the block is accepted and added to the set of pre-finalized blocks in that node. (¶ 51)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Jayachandran and Carver in order to mitigate transaction risk (Carver; ¶ 107-110).
Regarding claim 2, Jayachandran discloses wherein each of the first and second attestation values comprises a hash value, each of the first and second cryptographic transforms comprising at least one hash function (¶ 94-100, 156-165).
Regarding claim 3, Jayachandran discloses wherein one or both of: the first attestation value comprises a root of a first hash tree, each of the indications reported in the first report being a leaf of the first hash tree, and/or the second attestation value comprises a root of a second hash tree, each of the indications reported in the second report being a leaf of the second hash tree(¶ 99-102, 114, 126, 143).
Regarding claim 5, Carver teaches wherein the indications in the first and second reports comprise transaction IDs of the transactions reported in the first and second reports respectively(¶ 42-45, 88).
Regarding claim 6, Jayachandran discloses wherein each of the first and second transactions is addressed to a public key of the third party(¶ 106, 197).
Regarding claim 7, Carver teaches wherein each of the first and second transactions comprises an output comprising a locking script, the locking script being addressed to the third party by including an address based on a public key of the third party and requiring a corresponding signature of the third party to unlock(¶ 59, 61, 66, 88-90).
Regarding claim 8, Carver teaches wherein the transactions between the first and second parties comprises at least some transactions transacting from the first party to the second party, each comprising an address based on a respective child public key of the second party, wherein each child key is related to a master public key of the second party by a derivation function, the derivation function being parameterized by respective derivation information(¶ 88-90, 110, 168, 385, 386, 396).
Regarding claim 9, Jayachandran discloses wherein the respective derivation information for each child key comprises a respective invoice, sales order or receipt for the respective transaction(¶ 100-103).
Regarding claim 10, Carver teaches wherein the derivation information comprises a chain code common to the public child keys(¶ 88-90, 110, 168, 385, 386, 396).
Regarding claim 11, Jayachandran discloses wherein the derivation information for each child key comprises a respective index value(¶ 53-56, 106, 155-157, 197).
Regarding claim 12, Jayachandran discloses wherein the master public key of the second party is linked to a public identity of the second party by a digital certificate authority(¶ 82-84).
Regarding claim 13, Carver teaches from the first party, receiving the respective derivation information for at least one of the blockchain transactions in said set; and in response to determining that the first and second reports indicate different membership of the set, using the derivation function, the master public key of the second party and the received derivation information in order to determine the child public key of the second party and thereby verify that the respective address is linked to the master public key of the second party(¶ 88-90, 110, 168, 385, 386, 396).
Regarding claim 14, Carver teaches wherein the receiving of the respective derivation information is also performed in response to determining that the first and second reports indicate different membership of a set(¶ 51, 68-71, 76-79, 102, 103).
Regarding claim 15, Jayachandran discloses wherein the public key of the second party is linked to a public identity of the second party by a digital certificate authority, and said determining step further comprises using the master public key and a digital certificate issued by the certificate authority to verify the public identity of the second party(¶ 82-84).
Regarding claim 16, Jayachandran discloses wherein one or both of: the first report comprises multiple first report messages received at different times, each first report message reporting a different respective one of the blockchain transactions involving the first party, and wherein the first attestation value is an instance of a periodic attestation combining blockchain transactions involving the first party within a time window; and/or the second report comprises multiple second report messages received at different times, each second report message reporting a different respective one of the blockchain transactions involving the second party, and wherein the second attestation value is an instance of a periodic attestation to blockchain transactions involving the second party within a time window(¶ 141-145, 164-191, 209).
Regarding claim 17, Jayachandran discloses wherein the indications in the first report and/or second report further include an indication of each of one or more further blockchain transactions transacting with one or more further parties other than the first, second and third parties, said set being an intersection of transactions involving the first or second parties(¶ 93, 94, 101, 105, 106, 145-147).
Regarding claim 18, Jayachandran discloses wherein first attestation value comprises a root of a hash tree, each of the indications reported in the first report being a leaf of the hash tree; and wherein the method comprises: in response to determining that the first and second reports indicate different membership of the set, identifying at least one blockchain transaction present indicated in the first report but not the second report as a missing transaction; using the hash tree root, and a hash tree path between the root and the indication representing the missing transaction, in order to produce evidence that the second party made a false attestation; based on the use of the hash tree root and path, presenting the evidence to a fourth party without disclosing to the fourth party the indications of the transactions of said further parties(¶ 96, 97, 122, 123, 204, 206).
Regarding claim 19, Jayachandran discloses wherein: a public key of the second party is linked to a public identity of the second party by a digital certificate authority, and said determining step further comprises using a master public key and a digital certificate issued by the certificate authority to verify the public identity of the second party; and the evidence further includes the verification of the link to the public identity of the second party(¶ 55, 82-84, 103, 134, 144).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Craig et al., (GB2581970) teaches same Assignee, fill in H.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
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, NEHA H PATEL can be reached on (571) 270-1492. 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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699
Prosecution Insights