DETAILED ACTION
Acknowledgements
The amendment filed 10/8/2025 is acknowledged.
Claims 1-17 are pending.
Claims 1-17 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 Amendment/Arguments
Regarding the rejection of the claims under 35 USC 103, applicant states that Klaedtke does not disclose “in response to successfully checking the proposed transaction against the one or more transaction rules of the cryptographic configuration, participating in jointly signing the proposed transaction with a validation key associated with the cryptographic configuration” because it does not disclose that the validation key is associated with a cryptographic configuration.
Examiner notes, however, that the key of Klaedtke is associated with the policy because the key is used to sign the verdict which indicates the result of the policy check. Thus, there is an association between the key and the policy or cryptographic configuration.
Regarding claim 7, applicant states that Klaedtke does not disclose “generating . . . a joint signature over the proposed transaction” because the cited portions describe two separate signatures, which one being generated over a transaction by a user’s blockchain agent, and the other being generated over a verdict by the compliance checker. Examiner notes that signed verdict includes the signed transaction (See, e.g. Klaedtke ¶ 91). Therefore, the signature of the verdict is itself a signature over the transaction by virtue of inclusion of the transaction signature. Further, because the signature of the verdict is based on the transaction signature, it is a joint signature.
Regarding the rejection of the claims under 35 USC 101, applicant states that the claims are directed to a technical solution that is necessarily rooted in computer technology in order to overcome a technical problem specifically arising in the realm of computer-implemented layer 2 processing for a distributed ledger, and are not directed to an abstract idea.
Examiner notes, however, that although the claims recite that the transaction is “a proposed transaction for layer 2 processing,” the steps performed in the claims involve receiving a request to validate the proposed transaction, identifying a configuration or set of rules for the transaction, checking the transaction against the rules, and when the transaction is successfully checked against the rules, jointly signing the proposed transaction. These steps describe a method of validating a transaction by checking whether it complies with rules, and signing the validated transaction, which is a commercial or legal interaction, and therefore an abstract idea which falls within the “certain methods of organizing human activity” grouping of abstract ideas. Beyond reciting that the transaction is for layer 2 processing, the steps do not provide any technical details nor do they provide a technical solution. The additional elements of the claims, such as the use of layer 2 processing, a distributed ledger, and a cryptographic configuration to perform the method, merely use a computer as a tool to perform an abstract idea, and thus do not provide a practical application or significantly more than the abstract idea.
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-12 and 14-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract ides without significantly more.
In the instant case, claims 1-12 and 14-15 are directed to a method, claim 16 is directed to a system comprising at least one processor and at least one computer-readable storage medium, and claim 17 is directed to a non-transitory computer-readable storage medium. Therefore, these claims fall within the four statutory categories of invention.
The claims recite validating a transaction by checking whether it complies with rules, and signing the validated transaction, which is an abstract idea. Specifically, the claims recite “receiving a request to validate a proposed transaction for . . . processing for a . . . ledger,” “identifying a . . . configuration involved in the proposed transaction,” “checking the proposed transaction against one or more transaction rules of the . . . configuration,” and “in response to successfully checking the proposed transaction against the one or more transaction rules of the . . . configuration, participating in jointly signing the proposed transaction with a validation key associated with the . . . configuration,” which is grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (MPEP 2106.04 & 2106.04(a)) because it describes a method of validating a transaction and signing it involving receiving a request to validate the proposed transaction, identifying a configuration or set of rules for the transaction, checking the transaction against the rules, and when the transaction is successfully checked against the rules, jointly signing the proposed transaction, which is a commercial or legal interaction. Accordingly, the claims recite an abstract idea (See MPEP 2106.04(a)).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106.04(d)), the additional elements of the claims such as the use of layer 2 processing, a distributed ledger, and a cryptographic configuration to perform the method, merely use a computer as a tool to perform an abstract idea. Specifically, these additional elements perform the steps or functions of “receiving a request to validate a proposed transaction for . . . processing for a . . . ledger,” “identifying a . . . configuration involved in the proposed transaction,” “checking the proposed transaction against one or more transaction rules of the . . . configuration,” and “in response to successfully checking the proposed transaction against the one or more transaction rules of the . . . configuration, participating in jointly signing the proposed transaction with a validation key associated with the . . . configuration.” Viewed as a whole, the use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106.05), the additional elements of using layer 2 processing, a distributed ledger, and a cryptographic configuration to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of validating a transaction by checking whether it complies with rules, and signing the validated transaction. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions of “receiving a request to validate a proposed transaction for . . . processing for a . . . ledger,” “identifying a . . . configuration involved in the proposed transaction,” “checking the proposed transaction against one or more transaction rules of the . . . configuration,” and “in response to successfully checking the proposed transaction against the one or more transaction rules of the . . . configuration, participating in jointly signing the proposed transaction with a validation key associated with the . . . configuration.” These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of validating a transaction by checking whether it complies with rules, and signing the validated transaction. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. 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 (f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-12, and 14-15 further describe the abstract idea of validating a transaction by checking whether it complies with rules, and signing the validated transaction. Specifically, claim 2 describes characteristics of the cryptographic configuration and a contract, but does not require any steps or functions to be performed. The use of a smart contract does not provide a practical application or significantly more than the abstract idea because it only involves using a computer to automate and/or implement the abstract idea. Claim 3 further describe identifying the smart contract. This further describes the act of identifying the configuration or rules, which is part of the abstract idea. Claim 4 describes the types of information used to identify the smart contract, but does not require any further steps or functions to be performed. Claims 5-6 further describe the act of the checking the proposed transaction, and the rules involve in checking the proposed transaction. Because this act is part of the abstract idea, the limitations in these claims further describe the abstract idea. Claim 7 describes the two entities which jointly sign the transaction. This provides further detail regarding the abstract idea because it further describes the step of jointly signing the proposed transaction. Claims 8-9 describe updating the set of rules in the contract and claims 10 and 14 describe storing and updating the contract containing the set of rules. This is also directed to the abstract idea because it describes the rules used in validating the transaction. The use of a smart contract does not provide a practical application or significantly more than the abstract idea because it only involves using a computer to automate and/or implement the abstract idea. Claim 11 describes sending a request to validate the transaction and participating in jointly signing the proposed transaction, which is part of the abstract idea. Claim 12 describes transmitting the signed transaction for processing. This is also directed to the abstract idea because it describes the transmission of the transaction after it has been validated. Claim 15 describes transferring assets, which is part of the transaction. Therefore, this claim also further describes the abstract idea. The use of a smart contract does not provide a practical application or significantly more than the abstract idea because it only involves using a computer to automate and/or implement the abstract idea. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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-2, 7-8, 10-13, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Klaedtke (US 2019/0303932) in view of Dziembowski, S., et al. “General State Channel Networks.” In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS '18). Association for Computing Machinery, New York, NY, USA, 949–966 (2018) available at: https://doi.org/10.1145/3243734.3243856 (“Dziembowski”).
Regarding claims 1, 16, and 17, Klaedtke discloses a system comprising at least one processor and at least one computer-readable storage medium having stored thereon instructions which, when executed, program the at least one processor to perform a method, at least one computer-readable storage medium having stored thereon instructions which, when executed, program at least one processor to perform the method, and the computer-implemented method for validating distributed ledger transactions, the method comprising acts of:
receiving a request to validate a proposed transaction for processing for a distributed ledger (Klaedtke ¶¶ 68, 74, 77);
identifying a cryptographic configuration involved in the proposed transaction (Klaedtke ¶¶ 74-77);
checking the proposed transaction against one or more transaction rules of the cryptographic configuration (Klaedtke ¶¶ 22, 77-79);
in response to successfully checking the proposed transaction against the one or more transaction rules of the cryptographic configuration, participating in jointly signing the proposed transaction with a validation key associated with the cryptographic configuration (Klaedtke ¶¶ 59-61, 91).
Klaedtke does not specifically disclose layer 2 processing for a distributed ledger.
Dziembowski discloses layer 2 processing for a distributed ledger (Dziembowski p. 5, section 2, ¶¶ 1-2, starting with “Ledger state channels – an overview”).
Therefore, it would have been obvious to one of ordinary skill at the effective filing date of the application to modify the method of Klaedtke to include layer 2 processing for a distributed ledger, as disclosed in Dziembowski, in order to allow users to run smart contracts off-chain and to build channels over any number of intermediaries (Dziembowski p. 3, section 1.1, ¶ 1).
Regarding claim 2, Klaedtke discloses that the cryptographic configuration comprises information relating to a smart contract (Klaedtke ¶¶ 75, 84).
Klaedtke does not specifically disclose that the smart contract is not deployed on the distributed ledger.
Dziembowski discloses that the smart contract is not deployed on the distributed ledger (Dziembowski p. 5, section 2, ¶¶ 1-2, starting with “Ledger state channels – an overview”).
Therefore, it would have been obvious to one of ordinary skill at the effective filing date of the application to modify the method of Klaedtke to include the use of a smart contract not deployed on the distributed ledger, as disclosed in Dziembowski, in order to allow users to run smart contracts off-chain and to build channels over any number of intermediaries (Dziembowski p. 3, section 1.1, ¶ 1).
Regarding claim 7, Klaedtke discloses that the method is performed by a transaction validation service (Klaedtke ¶¶ 43); the act of signing the proposed transaction comprises generating, jointly with a wallet application a joint signature over the proposed transaction, wherein: the transaction validation service signs with the validation key associated with the cryptographic configuration (Klaedtke ¶¶ 59-63); and the wallet application signs with a user key associated with the cryptographic configuration (Klaedtke ¶¶ 26, 39-40, 60-61).
Regarding claim 8, Klaedtke does not specifically disclose receiving a proposed configuration transaction for the smart contract; identifying the smart contract to be updated; checking the proposed configuration transaction against one or more configuration rules of the smart contract; in response to successfully checking the proposed configuration transaction against the one or more configuration rules of the smart contract, updating a state of the smart contract, wherein the state of the smart contract is not maintained on the distributed ledger.
Dziembowski discloses receiving a proposed configuration transaction for the smart contract (Dziembowski p. 17, section 4.2 ¶ 2 starting with “Contract instance update”);
identifying the smart contract to be updated (Dziembowski p. 17, section 4.2 ¶ 2 starting with “Contract instance update”);
checking the proposed configuration transaction against one or more configuration rules of the smart contract (Dziembowski p. 17, section 4.2 ¶ 2 starting with “Contract instance update”);
in response to successfully checking the proposed configuration transaction against the one or more configuration rules of the smart contract, updating a state of the smart contract (Dziembowski p. 17, section 4.2 ¶ 2 starting with “Contract instance update”), wherein the state of the smart contract is not maintained on the distributed ledger (Dziembowski p. 5, section 2. ¶¶ 1-3).
Therefore, it would have been obvious to one of ordinary skill at the effective filing date of the application to modify the method of Klaedtke to include receiving a proposed configuration transaction for the smart contract; identifying the smart contract to be updated; checking the proposed configuration transaction against one or more configuration rules of the smart contract; in response to successfully checking the proposed configuration transaction against the one or more configuration rules of the smart contract, and updating a state of the smart contract, wherein the state of the smart contract is not maintained on the distributed ledger, as disclosed in Dziembowski, in order to allow users to run smart contracts off-chain and to build channels over any number of intermediaries (Dziembowski p. 3, section 1.1, ¶ 1).
Regarding claim 10, Klaedtke does not specifically disclose initiating a deployment transaction to deploy the smart contract on the distributed ledger, the deployment transaction being previously saved; and initiating a configuration transaction for the smart contract, the configuration transaction being saved before the smart contract is deployed.
Dziembowski discloses initiating a deployment transaction to deploy the smart contract on the distributed ledger, the deployment transaction being previously saved (Dziembowski pp. 10-11, section 3.1; p. 15 section 4.2, ¶¶ 1-4); and initiating a configuration transaction for the smart contract, the configuration transaction being saved before the smart contract is deployed (Dziembowski p. 5, section 2, ¶ 1 starting with “Ledger state channels – an overview”; p. 10, section 3.1 ¶¶ 2-6; p. 15, section 4.2, ¶¶ 1-4).
Therefore, it would have been obvious to one of ordinary skill at the effective filing date of the application to modify the method of Klaedtke to include disclose initiating a deployment transaction to deploy the smart contract on the distributed ledger, the deployment transaction being previously saved, and initiating a configuration transaction for the smart contract, the configuration transaction being saved before the smart contract is deployed., as disclosed in Dziembowski, in order to allow users to run smart contracts off-chain and to build channels over any number of intermediaries (Dziembowski p. 3, section 1.1, ¶ 1).
Regarding claim 11, Klaedtke discloses prior to initiating the deployment transaction to deploy the smart contract on the distributed ledger: sending the request to validate the proposed transaction for processing, wherein the proposed transaction involves the smart contract (Klaedtke ¶¶ 77-80); and
participating in jointly signing the proposed transaction with a user key associated with the smart contract, thereby obtaining a joint signature over the proposed transaction (Klaedtke ¶¶ 61, 83).
Klaedtke does not specifically disclose layer 2 processing for a distributed ledger.
Dziembowski discloses layer 2 processing for a distributed ledger (Dziembowski p. 5, section 2, ¶¶ 1-2, starting with “Ledger state channels – an overview”).
Therefore, it would have been obvious to one of ordinary skill at the effective filing date of the application to modify the method of Klaedtke to include layer 2 processing for a distributed ledger, as disclosed in Dziembowski, in order to allow users to run smart contracts off-chain and to build channels over any number of intermediaries (Dziembowski p. 3, section 1.1, ¶ 1).
Regarding claim 12, Klaedtke discloses prior to initiating the deployment transaction to deploy the smart contract on the distributed ledger: sending the proposed transaction, along with the joint signature, to a service for processing (Klaedtke ¶¶ 77-83).
Klaedtke does not specifically disclose a layer 2 service.
Dziembowski discloses the use of a layer 2 service (Dziembowski p. 5, section 2, ¶¶ 1-2, starting with “Ledger state channels – an overview”).
Therefore, it would have been obvious to one of ordinary skill at the effective filing date of the application to modify the method of Klaedtke to include the use of a layer 2 service, as disclosed in Dziembowski, in order to allow users to run smart contracts off-chain and to build channels over any number of intermediaries (Dziembowski p. 3, section 1.1, ¶ 1).
Regarding claim 13, Klaedtke discloses that the request to validate the proposed transaction is sent by a wallet application to a transaction validation service (Klaedtke ¶¶ 26, 29, 43-44); the joint signature is generated jointly by the wallet application and the transaction validation service, wherein: the transaction validation service signs with a validation key associated with the smart contract (Klaedtke ¶¶ 43-44, 59-63); and the wallet application signs with the user key associated with the smart contract (Klaedtke ¶¶ 26, 39-40, 60-61).
Regarding claim 15, Klaedtke does not specifically disclose after the smart contract has been deployed on the distributed ledger, initiating a withdrawal transaction to transfer one or more digital assets from a layer service to the smart contract.
Dziembowski discloses after the smart contract has been deployed on the distributed ledger, initiating a withdrawal transaction to transfer one or more digital assets from a layer service to the smart contract (Dziembowski p. 10, section 3.1, ¶¶ 1-7).
Therefore, it would have been obvious to one of ordinary skill at the effective filing date of the application to modify the method of Klaedtke to after the smart contract has been deployed on the distributed ledger, initiating a withdrawal transaction to transfer one or more digital assets from a layer service to the smart contract, as disclosed in Dziembowski, in order to allow users to run smart contracts off-chain and to build channels over any number of intermediaries (Dziembowski p. 3, section 1.1, ¶ 1).
Claims 3, 4, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Klaedtke in view of Dziembowski as applied to claim 2 and 10 above, and further in view of Cao, et al. (US 2019/0278767) (“Cao”).
Regarding claim 3, Klaedtke in view of Dziembowski does not specifically disclose that the proposed transaction indicates a layer address of the smart contract; and the act of identifying the cryptographic configuration comprises using the layer address to identify the information relating to the smart contract ().
Cao discloses that the proposed transaction indicates a layer address of the smart contract; and the act of identifying the cryptographic configuration comprises using the layer address to identify the information relating to the smart contract (Cao ¶¶ 52-54).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Klaedtke in view of Dziembowski to include a proposed transaction that indicates a layer address of the smart contract, and the act of identifying the cryptographic configuration comprising using the layer address to identify the information relating to the smart contract, as disclosed in Cao, in order to guarantee the safety of the update by only allowing the creator of the original smart contract to initiate the contract update through an authorization node (Cao ¶ 47).
Regarding claim 4, Klaedtke in view of Dziembowski does not specifically disclose that the layer address of the smart contract is determined based on a creator address, creation code, and/or a configuration of the smart contract.
Cao discloses that the layer address of the smart contract is determined based on a creator address, creation code, and/or a configuration of the smart contract (Cao ¶¶ 52-54).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Klaedtke in view of Dziembowski to include a layer address of the smart contract determined based on a creator address, creation code, and/or a configuration of the smart contract, as disclosed in Cao, in order to guarantee the safety of the update by only allowing the creator of the original smart contract to initiate the contract update through an authorization node (Cao ¶ 47).
Regarding claim 14, Dziembowski discloses that the act of initiating a configuration transaction comprises, after the smart contract has been deployed on the distributed ledger, sending the configuration transaction to the smart contract to be processed (Dziembowski p. 10, section 3.1, ¶¶ 2-6; p. 17, section 4.2, ¶ 3).
Klaedtke in view of Dziembowski does not specifically disclose that the act of initiating a deployment transaction comprises sending the deployment transaction to a factory contract configured to process the deployment transaction.
Cao disclose that the act of initiating a deployment transaction comprises sending the deployment transaction to a factory contract configured to process the deployment transaction (Cao ¶¶ 52-54).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Klaedtke in view of Dziembowski to include initiating a deployment transaction by sending the deployment transaction to a factory contract configured to process the deployment transaction, as disclosed in Cao, in order to guarantee the safety of the update by only allowing the creator of the original smart contract to initiate the contract update through an authorization node (Cao ¶ 47).
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Klaedtke in view of Dziembowski as applied to claim 1 above, and further in view of Kreder, III, et al. (US 2020/0394651) (“Kreder”).
Regarding claim 5, Klaedtke does not specifically disclose that the act of checking the proposed transaction against one or more transaction rules of the cryptographic configuration is performed before the transaction is submitted for layer 2 processing.
Kreder discloses that the act of checking the proposed transaction against one or more transaction rules of the cryptographic configuration is performed before the transaction is submitted for layer 2 processing (Kreder ¶¶ 216-218).
Therefore, it would have been obvious to one of ordinary skill the art at the effective filing date of the present application to modify the method of Klaedtke in view of Dziembowski to include the act of checking the proposed transaction against one or more transaction rules of the cryptographic configuration being performed before the transaction is submitted for layer 2 processing, as disclosed in Kreder, in order to allow for verifying the validity of transaction offline and to reduce transaction costs (Kreder ¶¶ 36, 210).
Regarding claim 6, Klaedtke disclose that the one or more transaction rules comprises at least one rule selected from a group consisting of: an N-out-of-M multi-signature rule, a transaction initiation rule, a transaction approval rule, a transaction amount rule, an aggregate amount rule, a blacklist rule, and a whitelist rule (Klaedtke ¶ 22).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Klaedtke in view of Dziembowski as applied to claim 8 above, and further in view of Padmanabhan (US 2021/0182423).
Regarding claim 9, Klaedtke in view of Dziembowski does not specifically disclose that the one or more configuration rules comprises a key recovery rule.
Padmanabhan discloses that the one or more configuration rules comprises a key recovery rule (Padmanbhan ¶¶ 663-664).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Klaedtke in view of Dziembowski to include one or more configuration rules comprising a key recovery rule, as disclosed in Padmanbhan, in order to store personal identifiable information via a metadata driven blockchain using distributed and decentralized storage for sensitive user information (Padmanbhan ¶ 12).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Unger, et al. (US 2020/0028697) (“Unger”) discloses performing off-chain validation of transaction for a blockchain in order to offload computationally intensive parts of a compliance process (Unger Figure 12; ¶¶ 11, 21, 35, 98, 108).
Noonan (US 2020/0366480) discloses a wallet application performing the method of validating a transaction (Noonan ¶¶ 91-92).
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 Mohammad A. Nilforoush whose telephone number is (571)270-5298. The examiner can normally be reached Monday-Friday 12pm-7pm.
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, John W. Hayes can be reached at 571-272-6708. 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.
/Mohammad A. Nilforoush/Primary Examiner, Art Unit 3697