DETAILED ACTION
This office action is responsive to amendment filed on May 26, 2026 in this application Sun et al., U.S. Patent Application No. 17/957,953, (Filed 9/30/2022) (“Sun”). Claims 1 – 25 were pending. Claims 1, 7, 9, 24, and 25 are amended. Claims 1 - 25 are pending.
Applicants' arguments have been carefully and respectfully considered and found not persuasive. Accordingly, this action has been made FINAL.
Information Disclosure Statement
The information disclosure statement (IDS) filed on 5/26/2026 are in compliance with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609. The references listed therein have been considered, and placed in the application file.
Response to Arguments
1. With respect to Applicant’s argument on pgs. 11 – 12 of the Applicant’s Remarks (“Remarks”) that the claims do not recite an abstract and even if they did are a practical application and amount to significantly more, examiner respectfully disagrees. See infra § Claim Rejections - 35 USC §101.
The abstract idea is limited to the conversion limitations. The claims fail to integrate the abstract idea into a practical application or amount to significantly more because they merely apply the abstract idea to generic computer components of “interface processor circuitry” “memory” “a processor” and the use of “hardware computation.” See MPEP 2106.05(d)(II) & (f). Because the components are well known generic computer components and the abstract idea is merely applied to them the claims remain rejected under 35 USC 101.
2. With respect to Applicant’s argument on pgs. 12 - 14 of the Remarks stating that Wang fails to teach data type conversion, examiner respectfully neither agrees nor disagrees. See infra § Claim Rejections - 35 USC §103 § Claim 1. Wang is not used to teach data type conversion but rather hardware conversion between instruction formats, therefore this argument is moot.
3. With respect to Applicant’s argument on pgs. 14 - 15 of the Remarks stating that neither Wang nor Wagner teach an “interface processor” communicating data between modules, examiner respectfully disagrees. See infra § Claim Rejections - 35 USC §103 § Claim 17. While the argument appears to characterize the interface processor and modules as not being software under the broadest reasonable interpretation such elements may be a software processor and software modules which perform the data transmission. To the extent Applicant wishes to specify particular hardware embodiments having features which distinguish over the prior art they are encouraged to do so to the extent supported by the specification. Therefore, the combination of Wang and Wagner teach the argued limitations.
4. With respect to Applicant’s argument on pgs. 15 - 16 of the Remarks stating that neither Wang nor Wagner teach the claimed third data, examiner respectfully disagrees. See infra § Claim Rejections - 35 USC §103 § Claim 21. The third data is taught by Wagner in that the data type conversion of Wager contemplate a variety of different types and is disclosed as a repetition of the lifting and lowering conversion process of Wagner, but into yet a third data type. Id. at pgs. 1 & 2 (different source languages exchange data). Therefore, the current prior art references teach the argued limitations.
Claim Objections
In light of Applicant’s amendments the Objections made to the claims are withdrawn.
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 applying the abstract idea to a general purpose computer as well as routine data receiving and sending, however other than the two conversion steps no data manipulation is claimed, merely sending and receiving. MPEP 2106.05(f) and (g). That is, other than reciting generic computer components 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). The data conversion steps, while claimed as performed via “hardware computation” lacks any details of the hardware computation and represents mere instructions to apply the abstract idea to a computer. MPEP 2106.05(f). 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 and routine data transmission. See MPEP 2106.05(d). 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)(II) & (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.
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: perform a first hardware computation to…perform a second hardware computation 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 to be communicated to a second module and 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 the 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 the first hardware computation is 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 the second hardware computation is 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
THIS ACTION IS MADE FINAL. 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 extension fee 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 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./ September 23, 2026
Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
