DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the amendment filed September 30, 2025.
Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on January 22, 2026 was filed after the mailing date of the application on October 24, 2023. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant’s arguments, see Remarks, filed September 30, 2025 with respect to the rejection(s) of claim(s) 1-20 under §103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of the prior art as applied below.
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.
Claim(s) 1, 8-10, 12, 14, 15 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Hron” (US Patent 11,909,858) in view of “Shillingford” (US PG Pub 2022/0292268) and further in view of “Coleman” (US PG Pub 2020/0401573).
Regarding Claim 1, Hron teaches:
1. A method for generating and validating a smart contract, the method comprising:
receiving text input describing a desired operation of a smart contract; (See Hron e.g. 306-310, Fig. 3, Col. 2, Ln 26-42, See further Col. 5, Ln 1- 29, teaching taking text of contract as input to be parsed for smart contract generation)
processing the text input with a language model to output a smart contract logic description and a textual description of a scenario for validating the smart contract, wherein the smart contract is configured to operate in the scenario described in the textual description of the scenario;; (Hron See 310-316 Fig. 3 Col. 2, Ln 26-42, See further Col. 5, Ln 30-Col 6 40, teaches parsing and converting contract terms into variables and rules of the contract terms to be implemented in a smart contract. And further including generation of dummy values as part of the smart contract generation and validation Col 6, 41-50). [Applicant’s specification fails to define or describe “textual description of a scenario” A broad but reasonable interpretation of this term includes a description of the smart contract terms parsed from the received text, such as those seen in 312, 316 Fig. 3 of Hron]
processing the textual description of a scenario output by the language model to generate synthetic data for validating the smart contract; (Col. 5, Ln 1 to Col. 6, Ln 50, 308-318, Fig. 3, teaches using the cross-compiler 308, which employees trained language model(s), fig. 3 to generate dummy variable for validating the smart contract in a sandboxed environment)
validating the smart contract code using the synthetic data to simulate transactions with the smart contract; (Hron Col. 6, 41-50 teaches validating the smart contract using dummy values before transporting it downstream)
and deploying the smart contract code on a blockchain upon successful validation of the smart contract code. (Hron Col. 6, 41-50 teaches validating the smart contract using dummy values before transporting it downstream; Col. 6, Ln 51-62 teaches deploying the smart contract to a blockchain network to be performed)
Hron does not teach, but Shillingford teaches:
processing the smart contract logic description with a generative artificial intelligence model to generate smart contract code, (Fig. 2C, ¶¶13, 29, 34 teaches us of a generative model e.g. BERT or GPT3 to generate smart contract code for use in the smart contract) [Here, Shillingord teaches a generative AI model trained to generate smart contract code used to generate smart contract code, Further Hron teaches or suggests the use of multiple language models as described above]
In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Shillingford as each is directed to smart contract code generation and Shillingford recognized the need for a system “that is fine-tuned with finance and legal training data sets.” (¶13).
Hron further does not teach, but Coleman teaches: wherein the synthetic data comprises an application programming interface (API) call performed by a user describedin the scenario; (See Coleman ¶¶22, 93, Fig. 8, 830-840 teaches using test API calls to test a smart contract blockchain transaction) [Here Coleman teaches use of test API calls to test smart contract execution API calls, which would be obvious to one of ordinary skill to generate using the generative AI system of Shillingford described above as Shillingford teaches testing the chain code as part of its AI generation system as in ¶27]
In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Shillingford with those of Coleman as each is directed to smart contract code generation and Coleman recognized the need for automated smart contract testing systems as “Blockchain solutions are often costly and take a significant amount of time to deploy.” (¶5).
Regarding Claim 10, Hron teaches:
10. A system comprising:
a processor; (604, Fig. 6 Hron)
and memory (608, Fig. 6 Hron)
storing instructions which, when executed by the processor, cause the system to: receive text input describing a desired operation of a smart contract; (See Hron e.g. 306-310, Fig. 3, Col. 2, Ln 26-42, See further Col. 5, Ln 1- 29, teaching taking text of contract as input to be parsed for smart contract generation)
process the text input with a language model to output a smart contract logic description and a textual description of a scenario for validating the smart contract; (Hron See 310-316 Fig. 3 Col. 2, Ln 26-42, See further Col. 5, Ln 30-Col 6 40, teaches parsing and converting contract terms into variables and rules of the contract terms to be implemented in a smart contract. And further including generation of dummy values as part of the smart contract generation and validation Col 6, 41-50). [Applicant’s specification fails to define or describe “textual description of a scenario.” A broad but reasonable interpretation of this term includes a description of the smart contract terms parsed from the received text, such as those seen in 312, 316 Fig. 3 of Hron]
processing the textual description of a scenario output by the language model to generate synthetic data for validating the smart contract; (Col. 5, Ln 1 to Col. 6, Ln 50, 308-318, Fig. 3, teaches using the cross-compiler 308, which employees trained language model(s), fig. 3 to generate dummy variable for validating the smart contract in a sandboxed environment)
validate the smart contract code using the synthetic data to simulate transactions with the smart contract; (Hron Col. 6, 41-50 teaches validating the smart contract using dummy values before transporting it downstream)
and deploy the smart contract code on a blockchain upon successful validation of the smart contract code. (Hron Col. 6, 41-50 teaches validating the smart contract using dummy values before transporting it downstream; Col. 6, Ln 51-62 teaches deploying the smart contract to a blockchain network to be performed)
Hron does not teach, but Shillingford teaches: process the smart contract logic description with a generative artificial intelligence model to generate smart contract code, (Fig. 2C, ¶¶13, 29, 34 teaches us of a generative model e.g. BERT or GPT3 to generate smart contract code for use in the smart contract) [Here, Shillingord teaches a generative AI model trained to generate smart contract code used to generate smart contract code, different from the compiler in Hron. Further Hron teaches or suggests the use of multiple language models as described above]
In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Shillingford as each is directed to smart contract code generation and Shillingford recognized the need for a system “that is fine-tuned with finance and legal training data sets.” (¶13).
Hron further does not teach, but Coleman teaches: wherein the synthetic data comprises an application programming interface (API) call performed by a user describedin the scenario; (See Coleman ¶¶22, 93, Fig. 8, 830-840 teaches using test API calls to test a smart contract blockchain transaction) [Here Coleman teaches use of test API calls to test smart contract execution API calls, which would be obvious to one of ordinary skill to generate using the generative AI system of Shillingford described above as Shillingford teaches testing the chain code as part of its AI generation system as in ¶27]
In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Shillingford with those of Coleman as each is directed to smart contract code generation and Coleman recognized the need for automated smart contract testing systems as “Blockchain solutions are often costly and take a significant amount of time to deploy.” (¶5).
Regarding Claim 15, Hron teaches:
15. A smart contract generation and validation system comprising:
a processor; (604, Fig. 6 Hron)
and memory storing instructions that, when executed by the processor, cause the smart contract generation and validation system to: (608, Fig. 6 Hron)
apply a language model configured to process text input describing a desired operation of a smart contract to generate a smart contract logic description and a scenario for validating the smart contract, wherein the smart contract is configured to operate in the scenario; (See Hron e.g. 306-310, Fig. 3, Col. 2, Ln 26-42, See further Col. 5, Ln 1- 29, teaching taking text of contract as input to be parsed for smart contract generation) (Hron See 310-316 Fig. 3 Col. 2, Ln 26-42, See further Col. 5, Ln 30-Col 6 40, teaches parsing and converting contract terms into variables and rules of the contract terms to be implemented in a smart contract. And further including generation of dummy values as part of the smart contract generation and validation Col 6, 41-50). [Applicant’s specification fails to define or describe “scenario” generated from the text input. A broad but reasonable interpretation of this term includes a description of the smart contract terms parsed from the received text, such as those seen in 312, 316 Fig. 3 of Hron]
apply a second language model to generate synthetic data for validating the smart contract based on the scenario output by the language model (Col. 5, Ln 1 to Col. 6, Ln 50, 308-318, Fig. 3, teaches using the cross-compiler 308, which employees trained language model(s), fig. 3 to generate dummy variable for validating the smart contract in a sandboxed environment)
and apply a validation module to validate the smart contract code using the synthetic data to simulate transactions with the smart contract. (Hron Col. 6, 41-50 teaches validating the smart contract using dummy values before transporting it downstream; Col. 6, Ln 51-62 teaches deploying the smart contract to a blockchain network to be performed)
Hron does not teach, but Shillingford teaches:
apply a generative artificial intelligence model configured to process the smart contract logic description to generate smart contract code; (Fig. 2C, ¶¶13, 29, 34 teaches us of a generative model e.g. BERT or GPT3 to generate smart contract code for use in the smart contract) [Here, Shillingord teaches a generative AI model trained to generate smart contract code used to generate smart contract code, different from the compiler in Hron. Further Hron teaches or suggests the use of multiple language models as described above]
Hron further does not teach, but Coleman teaches: wherein the synthetic data comprises an application programming interface (API) call performed by a user describedin the scenario; (See Coleman ¶¶22, 93, Fig. 8, 830-840 teaches using test API calls to test a smart contract blockchain transaction) [Here Coleman teaches use of test API calls to test smart contract execution API calls, which would be obvious to one of ordinary skill to generate using the generative AI system of Shillingford described above as Shillingford teaches testing the chain code as part of its AI generation system as in ¶27]
In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Shillingford with those of Coleman as each is directed to smart contract code generation and Coleman recognized the need for automated smart contract testing systems as “Blockchain solutions are often costly and take a significant amount of time to deploy.” (¶5).
In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Shillingford as each is directed to smart contract code generation and Shillingford recognized the need for a system “that is fine-tuned with finance and legal training data sets.” (¶13).
Regarding Claim 8, Hron further teaches:
8. The method of claim 1, wherein the smart contract logic description includes a flow chart illustrating the desired operation of the smart contract when executed on the blockchain. (Hron Col. 6, Ln 17-62 teaches the smart contract logic being organized into a sequence in the converter and further teaches a dependency tree and then sorted via a topological sorting method)
Regarding Claim 9, Hron further teaches:
9. The method of claim 1, wherein one or more of the receiving text input, the processing the text input, the processing the smart contract logic description, the validating the smart contract code, and the deploying the smart contract code are executed in a cloud based environment. (Hron Col. 4, Ln23-34 and Col. 8, Ln48-67 describe executing Hron’s system in a cloud environment)
Regarding Claim 12, Hron further teaches:
12. The system of claim 10, wherein the text input includes documentation defining business logic. (Hron Col. 4, Ln 35-67 teaches text input including a digital text version of a contract or an OCRed version of a contract)
Regarding Claim 14, Hron teaches:
14. The system of claim 10, wherein a user can observe output of the smart contract when executed on the blockchain through both the system and directly from the blockchain. (See Hron 408, Fig. 4 teaching smart contract output directly observable in the blockchain, and 614 Fig 6 teaching an output device for user observing output in the system)
Regarding Claim 20, Hron does not teach, but Shillingford teaches:
20. The smart contract generation and validation system comprising of claim 19, wherein the model includes a transformer neural network.(See e.g. Shillingford ¶13 teaches use of a generative pretrained transformer (GPT-3) in the natural language processing and smart contract generation system). In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Shillingford as each is directed to smart contract code generation and Shillingford recognized the need for a system “that is fine-tuned with finance and legal training data sets.” (¶13).
Claim(s) 2,3 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Hron” (US Patent 11,909,858) in view of “Shillingford” (US PG Pub 2022/0292268) and further in view of “Coleman” (US PG Pub 2020/0401573) as applied above and further in view of “Williams” (US PG Pub 2022/0327529)
Regarding Claim 2, Hron does not teach but Williams teaches:
2. The method of claim 1, wherein the blockchain is a layer 2 network configured to interface with a layer 1 blockchain network. (Willams ¶¶221 teaches deployment of smart contracts on a layer 2 block linked to a layer 1 blockchain network which provides services to the layer 2)
In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Williams as each is directed to smart contract code generation and Williams recognized “[a]lthough program execution appears as a simple chronological sequence, to maximize throughput of the network smart contracts are constructed in hierarchical layers (subroutine calls) to avoid unnecessary consensus validations.”(¶219).
Regarding Claim 3, Hron does not teach but Williams teaches: 3. The method of claim 2, wherein the smart contract defines a bridge linking the blockchain to the layer 1 blockchain network. (Willams ¶¶221 teaches deployment of smart contracts on a layer 2 block linked to a layer 1 blockchain network which provides services to the layer 2)
In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Williams as each is directed to smart contract code generation and Williams recognized “[a]lthough program execution appears as a simple chronological sequence, to maximize throughput of the network smart contracts are constructed in hierarchical layers (subroutine calls) to avoid unnecessary consensus validations.”(¶219).
Claim(s) 4, 5, 7 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Hron” (US Patent 11,909,858) in view of “Shillingford” (US PG Pub 2022/0292268) and further in view of “Coleman” (US PG Pub 2020/0401573). as applied above and further in view of “Bakshi” (US PG Pub 2023/0403288)
Regarding Claim 4, Hron et al teaches the limitations of claim 1 above but does not further teach, while Bakshi teaches:
4. The method of claim 1, wherein generating the synthetic data further comprises processing one or more datasets output from the language model with a second model to generate a plurality of simulated interactions with the smart contract for each of the one or more datasets, wherein the one or more datasets define smart contract execution scenarios. (¶¶45-49 teaches the use of a simulation engine to generate synthetic data for use in verifying the code of a smart contract, including simulating the actual data objects to verify the correct execution of smart contracts)
In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Bakshi as each is directed to smart contract code generation and Bakshi recognized the need for a system with the “practical application of simulating suspicious data interactions, verifying the suspicious data interaction while the simulated data interaction is being performed and processing the suspicious data interaction only after the verification is successful.” (¶6).
Regarding Claim 5, Hron et al teaches the limitations of claim 1 above but does not further teach, while Bakshi teaches:
5. The method of claim 4, wherein the one or more datasets defining smart contract execution scenarios include at least one of:(a) an outside world interaction with smart contracts dataset; (b) an owner/user interactions with smart contracts dataset; (c) a smart contract-to-smart contract communications dataset; (d) a hacking scenarios dataset; or (e) any combination of (a), (b), (c), and (d). (¶¶45-49 teaches the use of a simulation engine to generate synthetic data for use in verifying the code of a smart contract, including simulating the actual data objects to verify the correct execution of smart contracts. The synthetic data in Bakshi may represent hacking scenarios as in ¶28)
In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Bakshi as each is directed to smart contract code generation and Bakshi recognized the need for a system with the “practical application of simulating suspicious data interactions, verifying the suspicious data interaction while the simulated data interaction is being performed and processing the suspicious data interaction only after the verification is successful.” (¶6).
Regarding Claim 7, Hron et al teaches the limitations of claim 1 above but does not further teach, while Bakshi teaches:7. The method of claim 1, further comprising, upon an unsuccessful validation of the smart contract code: providing feedback to the language model to generate an updated smart contract logic description based on the feedback. (¶¶45-49 teaches the use of a simulation engine to generate synthetic data for use in verifying the code of a smart contract, including simulating the actual data objects to verify the correct execution of smart contracts. 216, Fig. 2, ¶¶70-71 teaches performing actions in response to validation failure including sending a report administrative node or simulation engine of the suspicious results of validation ) In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Bakshi as each is directed to smart contract code generation and Bakshi recognized the need for a system with the “practical application of simulating suspicious data interactions, verifying the suspicious data interaction while the simulated data interaction is being performed and processing the suspicious data interaction only after the verification is successful.” (¶6).
Regarding Claim 19, Hron et al teaches the limitations of claim 15 above but does not further teach, while Bakshi teaches: 19. The smart contract generation and validation system comprising of claim 15, wherein the language model outputs seed data and a synthetic data engine is configured to generate the synthetic data by processing the seed data with a model. (¶¶44-45 teaches generating a report with smart contract information including data objects, suspicious data interactions and behaviors etc as a seed for synthetic data generation to the simulation engine) In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Bakshi as each is directed to smart contract code generation and Bakshi recognized the need for a system with the “practical application of simulating suspicious data interactions, verifying the suspicious data interaction while the simulated data interaction is being performed and processing the suspicious data interaction only after the verification is successful.” (¶6).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Hron” (US Patent 11,909,858) in view of “Shillingford” (US PG Pub 2022/0292268) and further in view of “Coleman” (US PG Pub 2020/0401573). as applied above and further in view of “Singh” (US PG Pub 2023/0224306).
Regarding Claim 6, Hron et al teaches the limitation of claim 1 does not further teach, but Singh teaches:6. The method of claim 1, wherein the generative artificial intelligence model is trained on a corpus of optimized and validated example smart contract code. (Singh ¶36 teaches training a deel learning model trained on output smart contracts and able to identify criteria to be satisfied for transactions to be executed on the blockchain). In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Singh as each is directed to smart contract code generation and Singh recognized the need for a system wherein “computing platform may feed the one or more event features into a deep learning engine, which may cause the deep learning engine to produce a smart contract corresponding to the event processing request.” (¶2).
Claim(s) 11 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Hron” (US Patent 11,909,858) in view of “Shillingford” (US PG Pub 2022/0292268) and further in view of “Coleman” (US PG Pub 2020/0401573) as applied above and further in view of “Revankar” (US PG Pub 2020/0119905)
Regarding Claim 11, Hron et al teaches the limitation of claim 10 does not further teach, but Revankar teaches: 11. The system of claim 10, wherein the text input includes a text prompt describing describes the desired operation of the smart contract and identifyingidentifies the blockchain on which the smart contract is to be deployed. (¶¶54, 84, 88 710-Fig. 7 teaches a system providing a GUI and allowing for the upload of smart contract information including authenticated users over e.g. an enterprise-wide network) In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Revankar as each is directed to smart contract code generation and Revankar recognized the need for “a simplified interface that allows users to select and arrange a series of transaction elements for a customized smart contract workflow.” (¶2).
Regarding Claim 13, Hron et al teaches the limitation of claim 10 does not further teach, but Revankar teaches:13. The system of claim 10, wherein the system is accessible to authenticated users of an enterprise associated with the system. (¶¶54, 84, 88 710-Fig. 7 teaches a system providing a GUI and allowing for the upload of smart contract information including authenticated users over e.g. an enterprise-wide network) In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Revankar as each is directed to smart contract code generation and Revankar recognized the need for “a simplified interface that allows users to select and arrange a series of transaction elements for a customized smart contract workflow.” (¶2).
Claim(s) 16-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Hron” (US Patent 11,909,858) in view of “Shillingford” (US PG Pub 2022/0292268) and further in view of “Coleman” (US PG Pub 2020/0401573) as applied above and further in view of “Schwarz” (Wipo Publication 2023/144770)
Regarding Claim 16, Hron et al teaches the limitations of claim 15 above but does not further teach, while Schwarz teaches:16. The smart contract generation and validation system comprising of claim 15, further comprising an internal sidechain, wherein the smart contract code is deployed on the internal sidechain upon successful validation of the smart contract code. (Schwarz Pages 4-5 teaches use of a sidechain for hosting smart contracts where the sidechain is linked to the layer one blockchain via a bridge) In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Schwarz as each is directed to smart contract code generation and Schwarz recognized “Brand owners clearly wish to maintain control over their valuable brands, including with regard to their trademarks and copyrights. However no good solution currently exists to permit such control in the virtual economy.” (Page 1).
Regarding Claim 17, Hron et al teaches the limitations of claim 15 above but does not further teach, while Schwarz teaches:17. The smart contract generation and validation system comprising of claim 16, wherein the internal sidechain is linked to a layer 1 blockchain via an internal bridge. (Schwarz Pages 4-5 teaches use of a sidechain for hosting smart contracts where the sidechain is linked to the layer one blockchain via a bridge) In addition, it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Hron and Schwarz as each is directed to smart contract code generation and Schwarz recognized “Brand owners clearly wish to maintain control over their valuable brands, including with regard to their trademarks and copyrights. However no good solution currently exists to permit such control in the virtual economy.” (Page 1).
Regarding Claim 18, Hron further teaches: 18. The smart contract generation and validation system comprising of claim 16, wherein the internal sidechain is configured to interface with an internal oracle to access data associated with the smart contract. (Hron Col. 7, Ln18-22 teaches interfacing with an oracle to access associated data)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The prior art cited in the attached PTO-892 form includes additional prior art relevant to applicant’s disclosures related to smart contract generation systems.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4:30pm.
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, Wei Zhen can be reached at 571-272-3708. 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.
March 20, 2026
/M.J.B/ Primary Examiner, Art Unit 2191
/MATTHEW J BROPHY/ Primary Examiner, Art Unit 2191