DETAILED ACTION
This office action is responsive to claims 1 - 25 filed in this application Sun et al., U.S. Patent Application No. 17/957,953, (Filed 9/30/2022) (“Sun”).
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement(s) (IDS) filed on 12/7/2022 is in compliance with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 except for NPL references 2 and 3 which are not legible copies as the page breaks obscure lines of the text and figures. The remaining references listed therein have been considered, and placed in the application file.
Claim Objections
Claim 9 is objected to for the following informality: “asecond” should read “a second”.
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 – 25 are rejected under 35 U.S.C. 101 because the claimed inventions are directed to non-statutory subject matter. The claimed inventions do not fall within a statutory category of invention because the claimed invention is directed to a “Mental Processes” abstract idea without significantly more.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a “Mental Processes” abstract idea without significantly more. The claim recites two data conversion steps which covers performance of the limitations that can be performed in the mind or by pen and paper, but for the recitation of generic computer components.
The claims recite additional limitations of data obtaining, e.g. receiving, and providing, e.g. sending, however other than the two conversion steps no data manipulation is claimed, merely sending and receiving. That is, other than reciting generic computer components – an apparatus, comprising interface processing circuitry configured to be communicatively coupled to a memory and a processor - and insignificant extra-solution data transmission, nothing in the claim elements precludes the conversion steps from being performed in the mind of a user where the computer is merely being used as a tool to potentially record the converted data. See MPEP § 2106.04(a)(2)(III)(C)(3). As drafted, the claimed process, under its broadest reasonable interpretation, covers the performance of the limitation in the mind but for the recitation of generic computer components and insignificant extra-solution data transmission, which falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claims only recite generic computing components. See MPEP 2106.05(f). Accordingly, 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.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the courts have identified mere data gathering, displaying/outputting, transmitting, and storing, are well-understood, routine and conventional activity. See MPEP 2106.05(d) and 2106.05(f).
Claims 2 - 25 contain the same abstract idea as claim 1 and do not contain any additional limitations that would integrate the judicial exception into a practical application or additional elements that are sufficient to amount to significantly more than the judicial exception.
2. Claim 24 is rejected under 35 U.S.C. 101 because the claimed inventions are directed to non-statutory subject matter. The claimed inventions do not fall within a statutory category of invention because they are neither a process, machine, manufacture, nor composition of matter.
Claim 24 recites a “machine readable media” which the claims or specification fail to limit to non-transitory embodiments. Under the broadest reasonable interpretation, computer-readable medium or storage medium (or media), may be interpreted to include transitory media, which includes a signal per se, particularly when the storage medium is explicitly defined in the specification as a signal. See MPEP 2106 (II) & 2106.03. Claims covering signals per se must be rejected as non-statutory subject matter. See Interim Examination Instructions for Evaluating Subject Matter Eligibility Under 35 U.S.C. § 101, U.S. Patent and Trademark Off. (Aug. 24, 2009), available at http://www.uspto.gov/web/offices/pac/dapp/opla/2009-08-25_interim_101_instructions.pdf; see also In re Nuijten, 500 F.3d 1346, 1356-57 (Fed. Cir. 2007) (transitory embodiments are not directed to statutory subject matter). Examiner suggests amending the claims to read “non-transitory machine readable media.”
Claim 25 is rejected as depending on claim 24.
Claim Rejections 35 U.S.C. §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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 – 25 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al., United States Patent Application Publication No. 2022/0206807 (Published June 30, 2022, filed September 10, 2021) (“Wang”) in view of Wagner et al., “Interface Types Proposal” github.com (November 30, 2020) retrieved from https://web.archive.org/web/20210927115534/https://github.com/WebAssembly/interface-types/blob/main/proposals/interface-types/Explainer.md on February 7, 2026 (“Wagner”), and Haas et al., NPL Ref #1 IDS 12/7/2022 (Published 2017) (“Haas”).
Claims 1, 17, 21, and 24
With respect to claims 1, 17, 21, and 24 Wang teaches the invention as claimed including an apparatus, comprising:
interface processing circuitry configured to be communicatively coupled to a memory and a processor, the interface processing circuitry to: {A conversion control unit 702 may be used to convert machine instructions from a first native instruction format to a second native instruction format for execution on a processor 110 where the control unit and processor may be CISC, RISC-V, ARM, or X86. Wang at Abstract; id. at ¶¶ 0031, 0032, 0040, 0070, 0071; id. at ¶ 0036 (memory); id. at ¶¶ 0041 - 0043, 0062 (conversion control unit and examples of control unit hardware implementations).}
However, Wang doesn’t explicitly teach the limitation:
obtain, from a first module compiled from a [first software language], first data having a first native type of the [first software language]; convert the first data into second data having a first interface type; convert the second data having the first interface type into third data having a second native type of a [second software language]; and provide the third data to a second module associated with the [second software language]. {Wagner does teach this limitation. Wagner teaches that using a hardware control unit to convert between program data in a first type to program data in a second type, as taught in Wang, may include where first and second WebAssembly modules may be generated by a compiler from different source languages and where first data is WebAssembly data native to a first WebAssembly module that is converted using an adapter function to convert and “lift” the first data to a WebAssembly interface second data type which may then be consumed by a second WebAssembly module using the interface second data type and then converted again and “lowered”, using another adapter function, into a third data type native to the second WebAssembly module. Wagner at pgs. 1 & 2 (different source languages exchange data); id. at pg. 3 (interface data types); id. at pgs. 5 & 7-9 (adapters and “lift” and “lower” to convert data types and exchange using interface data types); id. at pgs. 17 & 18 (Second module may invoke a Web API).
Wang and Wagner are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of code conversion, and both are trying to solve the problem of how to process required code conversions.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine a hardware conversion device, as taught in Wang with converting between data types in WebAssembly, as taught in Wagner. Wagner teaches that WebAssembly modules needs a mechanism to exchange data when they represent different high-level types. Id. at pg. 1. Therefore, one having ordinary skill in the art would have been motivated to combine a hardware conversion device, as taught in Wang with converting between data types in WebAssembly, as taught in Wagner, for the purpose of exchanging different types of high-level data between WebAssembly modules.}
However, Wang and Wagner don’t explicitly teach the limitation:
first and second software language/ storing the third data in a shared memory region of memory to be accessed by the second module {Haas does teach this limitation. Haas teaches that a hardware WebAssembly data type conversion control unit, as taught in Wang and Wagner, may include where each WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).
Wang, Wagner, and Haas are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of code conversion, and both are trying to solve the problem of how to process required code conversions.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine a hardware WebAssembly data type conversion control unit, as taught in Wang and Wagner with WebAssembly data type exchanges between modules from different high-level languages, as taught in Haas. Wagner teaches that WebAssembly modules needs a mechanism to exchange data when they represent different high-level types. Id. at pg. 1. Therefore, one having ordinary skill in the art would have been motivated to combine a hardware WebAssembly data type conversion control unit, as taught in Wang and Wagner with WebAssembly data type exchanges between modules from different high-level languages, as taught in Haas, for the purpose of using known high-level data type conversion and exchange technique for different languages with WebAssembly modules that requires exchanging data between modules from particular different languages.}
Claims 2, 18, and 22
With respect to claim 2 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the first software language is compiled to WebAssembly binary code. {WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).}
Claim 3
With respect to claim 3 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the second module is compiled from the second software language to WebAssembly binary code. {WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).}
Claim 4
With respect to claim 4 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the second software language is different than the first software language. {WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).}
Claim 5
With respect to claim 5 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the second module is compiled to object code based on the second software language and is to run in a native runtime of the second software language. {WebAssembly bytecode may run in a runtime. Wagner at pg. 5; Haas at pg. 185 (Abstract).}
Claim 6
With respect to claim 6 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the second module is a WebAssembly system interface to an operating system or to one or more application programming interfaces (APIs) of a browser to run on the processor. {WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).}
Claim 7
With respect to claim 7 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein converting the first data into second data having a first interface type includes a first hardware computation to be performed by the [interface processing circuitry] in response to the first module initiating the [interface processing circuitry]. {First and second WebAssembly modules may be generated by a compiler from different source languages and where first data is WebAssembly data native to a first WebAssembly module that is converted using an adapter function to convert and “lift” the first data to a WebAssembly interface second data type which may then be consumed by a second WebAssembly module using the interface second data type and then converted again and “lowered”, using another adapter function, into a third data type native to the second WebAssembly module. Wagner at pgs. 1 & 2 (different source languages exchange data); id. at pg. 3 (interface data types); id. at pgs. 5 & 7-9 (adapters and “lift” and “lower” to convert data types and exchange using interface data types); id. at pgs. 17 & 18 (Second module may invoke a Web API).}
interface processing circuitry {A conversion control unit 702 may be used to convert machine instructions from a first native instruction format to a second native instruction format for execution on a processor 110 where the control unit and processor may be CISC, RISC-V, ARM, or X86. Wang at Abstract; id. at ¶¶ 0031, 0032, 0040, 0070, 0071; id. at ¶ 0036 (memory); id. at ¶¶ 0041 - 0043, 0062 (conversion control unit and examples of control unit hardware implementations).}
Claim 8
With respect to claim 8 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the interface processing circuitry is further to: load a first instruction sequence on the interface processing circuitry to perform the first hardware computation. {A conversion control unit 702 may be used to convert machine instructions from a first native instruction format to a second native instruction format for execution on a processor 110 where the control unit and processor may be CISC, RISC-V, ARM, or X86. Wang at Abstract; id. at ¶¶ 0031, 0032, 0040, 0070, 0071; id. at ¶ 0036 (memory); id. at ¶¶ 0041 - 0043, 0062 (conversion control unit and examples of control unit hardware implementations).}
Claim 9
With respect to claim 9, Wang, Wagner, and Haas, teach the invention as claimed including:
wherein converting the second data having the first interface type into third data having a second native type includes a second hardware computation to be performed by the [interface processing circuitry] in response to the second module initiating the [interface processing circuitry]. {First and second WebAssembly modules may be generated by a compiler from different source languages and where first data is WebAssembly data native to a first WebAssembly module that is converted using an adapter function to convert and “lift” the first data to a WebAssembly interface second data type which may then be consumed by a second WebAssembly module using the interface second data type and then converted again and “lowered”, using another adapter function, into a third data type native to the second WebAssembly module. Wagner at pgs. 1 & 2 (different source languages exchange data); id. at pg. 3 (interface data types); id. at pgs. 5 & 7-9 (adapters and “lift” and “lower” to convert data types and exchange using interface data types); id. at pgs. 17 & 18 (Second module may invoke a Web API).}
interface processing circuitry {A conversion control unit 702 may be used to convert machine instructions from a first native instruction format to a second native instruction format for execution on a processor 110 where the control unit and processor may be CISC, RISC-V, ARM, or X86. Wang at Abstract; id. at ¶¶ 0031, 0032, 0040, 0070, 0071; id. at ¶ 0036 (memory); id. at ¶¶ 0041 - 0043, 0062 (conversion control unit and examples of control unit hardware implementations).}
Claim 10
With respect to claim 10, Wang, Wagner, and Haas, teach the invention as claimed including:
load a second instruction sequence on the interface processing circuitry to perform the second hardware computation. {A conversion control unit 702 may be used to convert machine instructions from a first native instruction format to a second native instruction format for execution on a processor 110 where the control unit and processor may be CISC, RISC-V, ARM, or X86. Wang at Abstract; id. at ¶¶ 0031, 0032, 0040, 0070, 0071; id. at ¶ 0036 (memory); id. at ¶¶ 0041 - 0043, 0062 (conversion control unit and examples of control unit hardware implementations).}
Claim 11
With respect to claim 11 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the memory is to include a first linear memory space allocated to the first module and a second linear memory space allocated to the second module, wherein a shared memory region is to be designated in a portion of the first linear memory space. {WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).}
Claim 12
With respect to claim 12 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the second module is to be permitted to at least read from the shared memory region, wherein the first module is to be permitted to read from the shared memory region and write to the shared memory region. {WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).}
Claim 13
With respect to claim 13, Wang, Wagner, and Haas, teach the invention as claimed including:
in response to being initiated by the first module, fetch the first data from a shared memory region; subsequent to converting the first data into the second data having the first interface type, store the second data in the shared memory region; and in response to being initiated by the second module, fetch the second data from the shared memory region. {WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).}
Claim 14
With respect to claim 14, Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the interface processing circuitry is implemented on a reduced instruction set computer (RISC-V) or a complex instruction set computer (CISC). {A conversion control unit 702 may be used to convert machine instructions from a first native instruction format to a second native instruction format for execution on a processor 110 where the control unit and processor may be CISC, RISC-V, ARM, or X86. Wang at Abstract; id. at ¶¶ 0031, 0032, 0040, 0070, 0071; id. at ¶ 0036 (memory); id. at ¶¶ 0041 - 0043, 0062 (conversion control unit and examples of control unit hardware implementations).}
Claim 15
With respect to claim 15, Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the first data is one of: return data generated by the first module in response to being called by the second module; or a parameter generated by the first module to be communicated as part of calling the second module. {First and second WebAssembly modules may be generated by a compiler from different source languages and where first data is WebAssembly data native to a first WebAssembly module that is converted using an adapter function to convert and “lift” the first data to a WebAssembly interface second data type which may then be consumed by a second WebAssembly module using the interface second data type and then converted again and “lowered”, using another adapter function, into a third data type native to the second WebAssembly module. Wagner at pgs. 1 & 2 (different source languages exchange data); id. at pg. 3 (interface data types); id. at pgs. 5 & 7-9 (adapters and “lift” and “lower” to convert data types and exchange using interface data types); id. at pgs. 17 & 18 (Second module may invoke a Web API).}
Claims 16 and 20
With respect to claims 16 and 20, Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the second data further has one or more other interface types. {First and second WebAssembly modules may be generated by a compiler from different source languages and where first data is WebAssembly data native to a first WebAssembly module that is converted using an adapter function to convert and “lift” the first data to a WebAssembly interface second data type which may then be consumed by a second WebAssembly module using the interface second data type and then converted again and “lowered”, using another adapter function, into a third data type native to the second WebAssembly module. Wagner at pgs. 1 & 2 (different source languages exchange data); id. at pg. 3 (interface data types); id. at pgs. 5 & 7-9 (adapters and “lift” and “lower” to convert data types and exchange using interface data types); id. at pgs. 17 & 18 (Second module may invoke a Web API).}
Claim 19
With respect to claim 19 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the second module is compiled from the second software language to WebAssembly binary code, and wherein the second software language is different than the first software language. {WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).}
Claim 23
With respect to claim 23 Wang, Wagner, and Haas, teach the invention as claimed including:
wherein the second module is one of: compiled from the second software language to WebAssembly binary code, compiled to object code based on the second software language, or a WebAssembly system interface to an operating system or application programming interface of a browser. {WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).}
Claim 25
With respect to claim 25 Wang, Wagner, and Haas, teach the invention as claimed including:
in response to being initiated by the first module, fetch the first data from a [shared memory region of a memory]; subsequent to converting the first data into the second data having the first interface type, store the second data in the [shared memory region]; and in response to being initiated by the second module, fetch the second data from the [shared memory region]. {first and second WebAssembly modules may be generated by a compiler from different source languages and where first data is WebAssembly data native to a first WebAssembly module that is converted using an adapter function to convert and “lift” the first data to a WebAssembly interface second data type which may then be consumed by a second WebAssembly module using the interface second data type and then converted again and “lowered”, using another adapter function, into a third data type native to the second WebAssembly module. Wagner at pgs. 1 & 2 (different source languages exchange data); id. at pg. 3 (interface data types); id. at pgs. 5 & 7-9 (adapters and “lift” and “lower” to convert data types and exchange using interface data types); id. at pgs. 17 & 18 (Second module may invoke a Web API).
shared memory region of a memory {WebAssembly binary module may be compiled from a different high-level language such as APIs in Javascript, or C/C++, where each module has its own linear memory where portions of that memory can be shared with other modules using “import/export” instructions, and where modules may interact with a browser based Javascript API. Haas at pg. 187 (WebAssembly binary); id. at pg. 188 § 2.2 Linear Memory § Creation and Growing; id. at pg. 195 § 6 Embedding and Interoperability § Linking (Exports & Imports; Javascript API.); id. at pg. 198 (WebAssembly binaries can be compiled from C/C++).}
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THEODORE E HEBERT whose telephone number is (571)270-1409. The examiner can normally be reached on Monday to Friday 9:00 a.m. to 6:00 p.m..
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, Lewis Bullock can be reached on 571-272-3759. 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.
//T.H./ February 14, 2026
Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199