Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Double Patenting
The terminal disclaimer filed 7/9/26 overcomes the Double Patenting rejections which are consequently withdrawn.
Rejections Under 35 U.S.C. 112(b)
The applicant’s amendments are sufficient to overcome the previous rejections which are consequently withdrawn.
Rejections of Claims 1-20 under 35 U.S.C. 101
The applicant’s amendments are sufficient to overcome the previous rejections which are consequently withdrawn.
Rejections under 35 U.S.C. 103
B. Claims 1 and 14:
(1) Gallagher outputs "into a WASM binary format ... for execution," not "into said first byte code program" for static analysis, as the Examiner's reliance on Kaston concedes. The claim requires the translator to output byte code "into a first byte code program" ( claim 1) and the virtual machine to perform "static analysis ... via said processing of said first byte code program."
The examiner respectfully disagrees. Gallagher’s WASM binary format constitutes a byte code program output by the compiler. Gallagher is not cited as teaching static analysis, Xie is. And performing the analysis would have been obvious to perform the analysis “without actually executing all of the underlying software code” (Xie par. [0032])
Gallagher instead compiles an instruction file "into a WASM binary format" ([0037]) that is "a file comprising an application compiled into a WASM binary format for execution in a WASM runtime environment" ([0027]). Gallagher's output is a binary for execution; it is not "said first byte code program" subjected to "static analysis ... via said processing of said first byte code program." Confirming this, the Examiner conceded for claim 12 that Gallagher in view of Xie does not teach outputting byte code "into said first byte code program" and added Kaston to supply it. The identical limitation in claim 1 cannot at the same time be treated as met by Gallagher alone. MPEP 2143.03; In re Wilson, 424 F.2d at 1385.
Gallagher discloses translating WASM compatible code into WASM binary format and replacing non-compatible code with an a “WASM equivalent”. In at least some embodiments WASM equivalent comes in the form of a “replacement library … having an … API” (see e.g. par. [0054]). Posita would have understood such a “library” to be code external to, but called by, the WASM binary.
Claim 12 recites “second byte code language … translated and output as said first byte code”, whereas Claim 1 recites a “source code to byte code translator”. Source code and byte code are not equivalent, accordingly, the limitations are not identical. As indicated in the rejection Gallagher discloses the first but not the second.
(2) In the citation provided and during the interview Examiner suggested an API can be an external function that are called. However, an API is not the claimed external function, and Gallagher's functions are compiled into its binary, which cannot satisfy a claim requiring that the byte code program not contain byte code defining those functions.
Gallagher compiles an application "into a WASM binary format for execution in a WASM runtime environment" (Gallagher, [0027]); it operates only on "a set of programming languages that can be compiled into a W ASM binary format" and, where a language "cannot be compiled into a W ASM binary format," reports that the file "could not be converted" ([0040]). To reach that runnable binary, where a dependency is not compatible Gallagher "automatically replace[s]" it with a WASM-compatible equivalent ([0057]) and the cited "bindings ... wrapper functions, wrapper libraries, APis" are used "to map a plurality of respective non-WASM functions to a plurality of respective WASM functions" ([0054]) that are compiled into the binary ([0053]-[0057]).
The rejection maps these citations to two separate elements of the claim, (i) a first application programming interface (API) through which the virtual machine transfers control to the LSPM, and (ii) external functions that the LSPM causes to execute and that "remain defined outside of' the first byte code program, which does not "contain byte code that defines said external functions." By Gallagher's own description, its "APis" are the mapping layer (the interface) between "non-WASM functions" and "WASM functions" ([0054]); an interface is not a function, so it can correspond at most to element (i), never to the external functions of element (ii). And the only functions [0054] identifies, the "WASM functions," are compiled into the binary ([0053][0057]); they are defined inside, not "defined outside of," and their defining byte code is exactly what the amended claims exclude from the byte code program. The Examiner has thus cited an interface to satisfy the function element and compiled-in functions to satisfy the defined-outside element; neither reads.
Applicant's architecture is the opposite and is fully supported. As used in the claims, a "call" and an "execution" are distinct acts: a call is a byte code instruction within the first byte code program that names (references) an external function, and it neither defines nor performs that function (Spec. ,-i,i 40, 65); an execution is the running of the external function's own code, which resides outside the program and which the LSPM causes to occur (Spec. ,-i,i 53, 54, 72).
Gallagher discloses, among other things, a replacement library having an API interface. This appears to correspond with what is disclosed by the applicant (see e.g. par. [0052] “Transfers control of execution to a Language Specific Plugin Module (LSPM) 262, by calling an entry point function (entry point) within the application programming interface (AP) of the LSPM 262”). Accordingly, Gallaghers replacement library having an API interface is understood to fall within a reasonably broad understanding of the claim language.
(3) Xie does not cure the acknowledged gap. The Examiner concedes Gallagher lacks a virtual machine that performs static analysis and relies on Xie. Xie, however, "statically analyze[s] virtual devices" by symbolic execution to validate device drivers ([0032]); it does not input and process a byte code program produced by a translator. Xie analyzes a device, not the claimed first byte code program, and cannot supply "static analysis ... via said processing of said first byte code program." The sole stated motivation, "to analyze the device without actually executing all of the underlying software code," is Xie' s own device-validation rationale and gives no reason to modify Gallagher's execution/porting pipeline; the combination appears drawn from Applicant's disclosure. KSR, 550 U.S. at 418. Xie is also arguably non-analogous art. In re Clay, 966 F.2d 656, 658-59 (Fed. Cir. 1992); MPEP 2141.0l(a).
Xie teaches static analysis of a program instructions (par. [0031] “permit symbolic execution of program instructions”). Xie’s “device” is a “virtual device”, i.e. a program (see e.g. par [0029] “a virtual device stub component”). Accordingly, contrary to applicant’s assertion Xie teaches static analysis of a program. Gallagher discloses inputting and processing a byte code program (as discussed above).
(4) Addtionally[sic], "Portion" is not taught. Gallagher's binary is "a file comprising an application" ([0027]), a whole file; Gallagher discloses no representation of a "portion" of a larger computer program that is output into one shared byte code program, consistent with the specification's use of "portion" as a part of a program (Spec. ,i 23; see also ,i,i 34-3 7).
Gallagher discloses a program comprising “portions” created by multiple compilers based on multiple inputs (see e.g. Fig. 1, WASM compilers for languages 1-N labeled 46-1, 46-N). Thus each input source code language produces a portion or part of the complete program.
C. Claim 6:
Claim 6 recites a second translator that outputs a second set of byte code "into said first byte code program." Gallagher compiles each instruction file into "a WASM binary format" ([0037]) for execution; it does not output a second language's byte code into the same byte code program that the virtual machine analyzes. The specification confirms the point (Spec. ,¶¶ 34-37). Claim 6 is separately patentable.
Xie teaches compilation of a second set of byte code into a first byte code program. Gallagher teaches compilation of code in various languages into a first byte code program. As indicated in the rejection it would have been obvious, and within the ordinary level of skill to include a second byte code language compiler in Gallaghers compilers 46-1 – 46-N (fig. 1).
Claims 4-5, 1- and 17-18
Separately, the Official Notice that external functions defined within third party provided software would yield "only the expected results" is conclusory and does not cure the base combination; Applicant traverses the taking of Official Notice and requests documentary evidence if the position is maintained. MPEP 2144.03.
First, the applicant does not state why third party provided software is not considered to be common knowledge or well-known in the art and thus is inadequate to traverse the official notice (see MPEP 2144.03 C).
Further, those of ordinary skill in the art would have understood that the “provider” of the function only describes who wrote the code an does not change the functioning of the code. Accordingly, those of ordinary skill in the art would have had sufficient creativity to recognize that, e.g., a library could be purchased or licensed (rather than written in-house). According, use of code sourced from outside of the organization would not have represented a non-obvious distinction.
Kaston' s only relevant teaching is compiling MSIL bytecode into Java bytecode within the Visual Studio .NET IDE ([0013]). Kaston discloses no output "into said first byte code program" that a virtual machine statically analyzes; it is arguably non-analogous, and the stated motivation ("known ... method ... [with] expected results") is conclusory. KSR; Kahn. As noted in Part IV.B(2), the reliance on Kaston for the "into said first byte code program" element is itself an admission that Gallagher does not teach it. Claims 12 and 19 are patentable for these reasons and by dependence.
Kaston is only cited for its admitted teaching of compiling MSIL (a second) bytecode into Java (a first) byte code. Any compilation into a bytecode (e.g. MSIL bytecode into Java bytecode) produces a “program” containing the output bytecode. Thus Kaston teaches compiling the bytecode “into” a program. Kaston is not cited as teaching static analysis. Finally, the applicant has not in fact argued that Kaston is non-analogous. Accordingly, the examiner is not persuaded that it is.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 6-9, and 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0265059 to Gallagher et al. (Gallagher) in view of US 2013/0085720 to Xie et al. (Xie).
Claim 1: Gallagher discloses a system for performing static analysis of a computer program that is expressed as source code that is written in accordance with one of a set of a plurality of one or more different computer programming languages, the system including:
a processor and memory (e.g. Fig. 1, Processor Device 14, Memory 16);
a source code to byte code first translator program, executed by said processor, said first translator program being designed to input source code expressed in accordance with a first computer programming language, said source code defines at least a first portion of a first computer program, and wherein said first translator program is further designed to output a first set of byte code into a first byte code program, said first byte code program being a representation of said first portion of said first computer program (par. [0037] “a set of programming languages that can be compiled into a WASM binary format … a WASM compiler … 46-N to compile an instruction file … 8-2 into a WASM binary format”); and
a virtual machine (VM), executed by said processor, being designed for inputting of said at least a portion of said first computer program, via said processing of said first byte code program (par. [0027] “a WASM binary format for execution in a WASM runtime environment”), and
wherein said virtual machine being further designed to transfer control of execution to at least a first language specific plugin module (LSPM) (par. [0054] “a replacement dependency (e.g. replacement library, etc.)”) through a first application programming interface (API) provided by said first LSPM (par. [0054] “having an interface (e.g., API, etc.)”);
wherein said first LSPM being designed to cause execution of one or more external functions (par. [0054] “wrapper functions, wrapper libraries … for a dependency that would otherwise be WASM-incompatible”), and
wherein said external functions are each called from within said first byte code program (see e.g. par. [0046] “equivalent 60 … can otherwise be callable”, par. [0054] “wrapper functions” par. [0049] “libraries comprising system calls”), and
wherein said external functions remain defined outside of said first byte code program, said first byte code program not containing byte code that defines said external functions (par. [0054] “a plurality of bindings … to map a plurality of respective non-WASM functions to a plurality of respective WASM functions… wrapper functions, wrapper libraries, APIs and the like”; see also par. [0049] “libraries comprising system calls”, par. [0068]).
Gallagher does not disclose
a virtual machine (VM) being designed for performing static analysis of said at least a portion of said first computer program.
Xie teaches
a virtual machine (VM) being designed for inputting and for performing static analysis of said at least a portion of said first computer program, via said processing of said first byte code program (par. [0032] “symbolic execution can be used to statically analyze virtual devices”).
It would have been obvious before the effective filing date of the claimed invention to provide a VM to perform static analysis and symbolic execution. Those of ordinary skill in the art would have been motivated to do so to “analyze the device without actually executing all of the underlying software code” (Xie par. [0032]).
Claim 2: Gallagher and Xie teach the system of claim 1, wherein said first language specific plugin module (LSPM) enables said virtual machine (VM) to cause performance of said one or more external functions that are called from within said first byte code program, and wherein said external functions are defined within a first language specific runtime environment (LSRE) that is associated with said first computer programming language (Gallagher par. [0053] “the identified compile-time dependency is WASM-compatible”).
Claim 3: Gallagher and Xie teach the system of claim 1, wherein said first language specific plugin module (LSPM) enables said virtual machine (VM) to cause performance of said one or more external functions that are each called from within said first byte code program, and wherein said external functions are each defined within software provided by a first operating system (e.g. Gallagher par. [0057] “substituting one or more … compatible compile -time dependency equivalents …. For example a library for performing system calls”).
Claim 6: Gallagher and Xie teach the system of claim 1 including a source code to byte code second translator program, said second translator program being designed to input source code expressed in accordance with a second computer programming language, said source code defines at least a second portion of said first computer program, and wherein said second translator program is further designed to output a second set of byte code into said first byte code program (Gallagher par. [0037] “a set of programming languages that can be compiled into a WASM binary format … a WASM compiler 46-1 … to compile an instruction file 8-1 … into a WASM binary format”).
Claim 7: Gallagher and Xie teach the system of claim 6 including a second language specific plugin module (LSPM), said second LSPM providing a second application programming interface (API) and designed to cause performance of one or more external functions, and wherein said external functions are called from within said first byte code program, and wherein said external functions are called while each of said external functions are defined outside of said first byte code program (Gallagher par. [0054] “a plurality of bindings … to map a plurality of respective non-WASM functions to a plurality of respective WASM functions… wrapper functions, wrapper libraries, APIs and the like”).
Claim 8: Gallagher and Xie teach the system of claim 7, wherein said second language specific plugin module (LSPM) enables said virtual machine (VM) to cause performance of said one or more external functions that are called from within said first byte code program, and wherein each of said external functions are defined within a second language specific runtime environment (LSRE) that is associated with said second computer programming language (Gallagher par. [0054] “a plurality of bindings … to map a plurality of respective non-WASM functions to a plurality of respective WASM functions… wrapper functions, wrapper libraries, APIs and the like”).
Claim 9: Gallagher and Xie teach the system of claim 7, wherein said second language specific plugin module (LSPM) enables said virtual machine (VM) to cause performance of said one or more external functions that are each called from within said first byte code program, and wherein said external functions are operating system call functions that are each defined within software provided by a first operating system (Gallagher par. [0046] “determine whether an identified runtime dependency 40-1, 40-2 is WASM-compatible”).
Claim 14: Gallagher discloses a system for performing static analysis of a computer program, the system including:
a processor and memory (Fig. 1 Processor Device 14, Memory 16) and
a virtual machine (VM), executed by said processor and that is configured for inputting and for performing at least a portion of a first computer program that is translated into a first byte code program, said static analysis being performed via said processing of said first byte code program (par. [0027] “a WASM binary format for execution in a WASM runtime environment”), and
wherein said virtual machine being further designed to transfer control of execution to at least a first language specific plugin module (LSPM) (par. [0054] “a replacement dependency (e.g. replacement library, etc.)”) through a first application programming interface (API) provided by said first LSPM (par. [0054] “having an interface (e.g., API, etc.)”);
said first LSPM being designed to cause execution of one or more external functions (par. [0054] “wrapper functions, wrapper libraries … for a dependency that would otherwise be WASM-incompatible”),
wherein each of said external functions are called from within said first byte code program (see e.g. par. [0046] “equivalent 60 … can otherwise be callable”, par. [0054] “wrapper functions” par. [0049] “libraries comprising system calls”), and
wherein each of said external functions remain defined outside of said first byte code program, said first byte code program not containing byte code that defines said external functions (par. [0054] “a plurality of bindings … to map a plurality of respective non-WASM functions to a plurality of respective WASM functions… wrapper functions, wrapper libraries, APIs and the like”; see also par. [0049] “libraries comprising system calls”, par. [0068]).
Gallagher does not disclose:
a virtual machine (VM) that is configured for performing static analysis of at least a portion of a first computer program.
Xie teaches:
Xie teaches
a virtual machine (VM) being designed for inputting and for performing static analysis of said at least a portion of said first computer program, via said processing of said first byte code program (par. [0032] “symbolic execution can be used to statically analyze virtual devices”).
It would have been obvious before the effective filing date of the claimed invention to provide a VM to perform static analysis and symbolic execution. Those of ordinary skill in the art would have been motivated to do so to “analyz[e] the device without actually executing all of the underlying software code” (Xie par. [0032]).
Claim 15: Gallagher and Xie teach the system of claim 14, wherein said first language specific plugin module (LSPM) enables said virtual machine (VM) to cause performance of said one or more external functions that are each called from within said first byte code program, and wherein said external functions are defined within a first language specific runtime environment (LSRE) that is associated with said first computer programming language (Gallagher par. [0046] “determine whether an identified runtime dependency 40-1, 40-2 is WASM-compatible”).
Claim 16: Gallagher and Xie teach the system of claim 14, wherein said first language specific plugin module (LSPM) enables said virtual machine (VM) to cause performance of said one or more external functions that are each called from within said first byte code program, and wherein each of said external functions are operating system call functions that are each defined within software provided by a first operating system.
Claim(s) 4-5, 10-11, 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0265059 to Gallagher et al. (Gallagher) in view of US 2013/0085720 to Xie et al. (Xie) in view of Official Notice.
Claim 4: Gallagher and Xie teach the system of claim 1, wherein said first language specific plugin module (LSPM) enables said virtual machine (VM) to cause performance of said one or more external functions that are called from within said first byte code program, and wherein said external functions are defined within provided software (Gallagher par. [0054] “a plurality of bindings … to map a plurality of respective non-WASM functions to a plurality of respective WASM functions… wrapper functions, wrapper libraries, APIs and the like”).
Gallagher does not explicitly disclose the external functions are defined within third party provided software.
It is officially noted that third party software was well known in the art at the time of filing.
It would have been obvious at the time of filing to cause performance of functions provided within third party software. Those of ordinary skill in the art would have been motivated to do so as a known source of software which would have produced only the expected results.
Claim 5: Gallagher and Xie teach the system of claim 4, wherein said third party provided software includes source code that is expressed in accordance with said first computer programming language, and that is translated by said first translator program and output as a first set of byte code into said first byte code program, and that is directly function called from said first byte code program (Gallagher par. [0046] “determine whether an identified runtime dependency 40-1, 40-2 is WASM-compatible”).
Claim 11: Gallagher and Xie teach the system of claim 7, wherein said second translator program is further designed provided software that is expressed in accordance with said second computer programming language, and that is translated and output as a set of byte code into said first byte code program, and that is thereby directly function called from said first byte code program (Gallagher par. [0046] “determine whether an identified runtime dependency 40-1, 40-2 is WASM-compatible”).
Gallagher does not explicitly disclose the provided software is provided by a third party.
It is officially noted that third party software was well known in the art at the time of filing.
It would have been obvious at the time of filing to cause performance of functions provided within third party software. Those of ordinary skill in the art would have been motivated to do so as a known source of software which would have produced only the expected results.
Claim 10: Gallagher and Xie teach the system of claim 7, wherein said second language specific plugin module (LSPM) enables said virtual machine (VM) to cause performance of said one or more external functions that are each called from within said first byte code program, and wherein said external functions are defined within provided software (par. [0054] “a plurality of bindings … to map a plurality of respective non-WASM functions to a plurality of respective WASM functions… wrapper functions, wrapper libraries, APIs and the like”).
Gallagher does not explicitly disclose the external functions are defined within third party provided software.
It is officially noted that third party software was well known in the art at the time of filing.
It would have been obvious at the time of filing to cause performance of functions provided within third party software. Those of ordinary skill in the art would have been motivated to do so as a known source of software which would have produced only the expected results.
Claim 17: Gallagher and Xie teach the system of claim 14, wherein said first language specific plugin module (LSPM) enables said virtual machine (VM) to cause performance of said one or more external functions that are each called from within said first byte code program, and wherein each of said external functions are defined within provided software.
Gallagher does not explicitly disclose the external functions are defined within third party provided software.
It is officially noted that third party software was well known in the art at the time of filing.
It would have been obvious at the time of filing to cause performance of functions provided within third party software. Those of ordinary skill in the art would have been motivated to do so as a known source of software which would have produced only the expected results.
Claim 18: Gallagher and Xie teach the system of claim 17, wherein said third party provided software source code includes source code that is that is expressed in accordance with said first computer programming language, and that is translated by the first translator program and output as a first set of byte code into said first byte code program, and that is directly function called from said first byte code program (Gallagher par. [0046] “determine whether an identified runtime dependency 40-1, 40-2 is WASM-compatible”).
Claim(s) 12 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0265059 to Gallagher et al. (Gallagher) in view of US 2013/0085720 to Xie et al. (Xie) in view of US 2004/0268301 to Kaston (Kaston).
Claim 12: Gallagher and Xie teach the system of claim 1 including a byte code to byte code third translator program, said third translator program being designed to input a second byte code expressed in accordance with a second language, said code defining at least a portion of said first computer program, and wherein said third translator program is further designed to output said first byte code as a translation from said second code, into said first byte code program (Gallagher par. [0037] “a set of programming languages that can be compiled into a WASM binary format … a WASM compiler 46-1 … to compile an instruction file 8-1 … into a WASM binary format”).
Gallagher and Xie do not explicitly teach:
the third translator program designed to input second bytecode expressed in a second byte code language and output said first byte code.
Kaston teaches:
a translator program designed to input second bytecode expressed in a second byte code language and output a first byte code (par. [0013] “compiling Microsoft intermediate language (MSIL) bytecodes into Java bytecodes”).
It would have been obvious at the time of filing to translate second bytecode into the first bytecode. Those of ordinary skill in the art would have been motivated to do so in order to as a known compilation/translation method which would have produced only the expected results and would provide for greater flexibility in the development and use of an application.
Claim 19: Gallagher and Xie teach the system of claim 14 including a third translator program, said third translator program being designed to input a second set of code expressed in accordance with a second code language, said second set of code defines at least a portion of the first computer program, and wherein said third translator program is further designed to output a third set of code into said first byte code program, said first byte code program including a representation of said portion of said first computer program.
Gallagher and Xie do not explicitly teach:
the third translator program designed to input second bytecode expressed in a second byte code language and output said first byte code.
Kaston teaches:
a translator program designed to input second bytecode expressed in a second byte code language and output a first byte code (par. [0013] “compiling Microsoft intermediate language (MSIL) bytecodes into Java bytecodes”).
It would have been obvious at the time of filing to translate second bytecode into the first bytecode. Those of ordinary skill in the art would have been motivated to do so in order to as a known compilation/translation method which would have produced only the expected results and would provide for greater flexibility in the development and use of an application.
Claim(s) 13 and 20 and is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0265059 to Gallagher et al. (Gallagher) in view of US 2013/0085720 to Xie et al. (Xie) in view of US 2004/0268301 to Kaston (Kaston) in view of Official Notice.
Claim 13: Gallagher, Xie and Kaston teach the system of claim 12, wherein said third translator program is further designed to input provided software that is expressed in accordance with said second byte code language, and that is translated and output as said first byte code into said first byte code program, and that is thereby directly function called from said first byte code program.
Gallagher, Xie and Kaston do not explicitly teach the provided software is provided by a third party.
It is officially noted that third party software was well known in the art at the time of filing.
It would have been obvious at the time of filing to cause performance of functions provided within third party software. Those of ordinary skill in the art would have been motivated to do so as a known source of software which would have produced only the expected results.
Claim 20: Gallagher, Xie and Kaston teach the system of claim 19, wherein said third translator program is further designed to input a provided software that is expressed in accordance with said second byte code language, and that is translated and output as a third set of byte code into said first byte code program, and wherein the third set of byte code is thereby directly function called from said first byte code program.
Gallagher, Xie and Kaston do not explicitly teach the provided software is provided by a third party.
It is officially noted that third party software was well known in the art at the time of filing.
It would have been obvious at the time of filing to cause performance of functions provided within third party software. Those of ordinary skill in the art would have been motivated to do so as a known source of software which would have produced only the expected results.
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2021/0081837 to Polleri et al. and US 2023/0401042 to Liu et al. teach third party software.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON D MITCHELL whose telephone number is (571)272-3728. The examiner can normally be reached Monday through Thursday 7:00am - 4:30pm and alternate Fridays 7:00am 3: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, Lewis Bullock can be reached at (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.
/JASON D MITCHELL/Primary Examiner, Art Unit 2199
Prosecution Insights