DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 27, 2026 has been entered.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 8-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Stoodley et al. (US PGPUB 2014/0325493; hereinafter “Stoodley”) in view of Schrammel et al. (US PGPUB 2022/0179776; hereinafter “Schrammel”).
Claim 1: (Currently Amended)
Stoodley teaches a computer-implemented method, comprising:
executing, by a processor as part of runtime execution of a dynamic language (Fig. 2: Processor Unit 204. [0032] “Processor unit 204 serves to execute instructions for software.” [0007] “the java runtime including the java virtual machine and the just in time compiler.” [0046] “Enhanced JVM 302 provides a capability for speculative class-based optimization that extends a runtime assumption mechanism to enable just in time (JIT) compiler 304 to introduce new features (for example, methods or classes) into a class hierarchy that are not previously present in a Java application being executed.”),
a first comparison test to determine whether an unknown object is an instance of a first sub-class of a class of objects, wherein runtime execution of the dynamic language is dependent on identification of the unknown object at runtime; and determining that the unknown object is not an instance of the first sub-class ([0007] “Responsive to a determination the type of the class is not a fixed type, the computer-implemented method determines, by the just in time compiler, whether the class is sub-classed.” [0077] “For example, given a Java statement of: a[i]=x; where the run time class type of a is A[ ] and the run time class type of x is X, the Java specification requires that an array store exception be raised when the object x is non null and class X is not the same as class A and class X is not a subclass of class A which is the basic logic of instructions generated by JIT compiler 304 for arraystore checks,” wherein the raising of an “array store exception” indicates that execution is dependent on the identification of “object x”, i.e. “the unknown object”.); and
responsive to the determining that the unknown object is not an instance of the first sub-class ([0007] “Responsive to a determination the class is not sub-classed”):
preventing, by the processor, a second comparison test to determine whether the unknown object is an instance of a second sub-class by performing a no operation (NOP) test to determine that there are no additional sub-classes for the class of objects in addition to the first sub-class and a second sub-class ([0084] “JIT compiler 304 places inline a base implementation along with a virtual guard. The virtual guard can be changed in future so as to cause a more conservative implementation to execute when the particular property becomes invalid. Further, the implemented virtual guard may also include a NOP instruction.” [0093] “when the JIT compiler knows that the resolved type C has not been sub-classed at this particular point in time (where A is of resolved type C[ ] and X is of resolved type C) then the compiler can create the virtual synthetic property method doArrayStoreCheckOnC( ) on the class C with the implementation creating an empty method (reflecting that no arraystore check is currently required). Since doArrayStoreCheckOnC( ) has only a single implementation in the class hierarchy rooted at C at this point, the JIT compiler can inline the doArrayStoreCheckOnC( ) method along with a virtual guard containing a NOP instruction. The JIT compiler automatically creates an assumption on the class C to correct the NOP later when any class extends C and overrides the doArrayStoreCheckOnC( ) virtual synthetic property method.” [0095] “ The JIT compiler is aware that there are currently no subclasses of C, (in this example) and therefore creates a virtual guard with NOP to eliminate the condition in the if statements portion of statements 408 which transforms the code into statements 410.”); and
responsive to determining that there are no additional sub-classes, executing, by the processor, a second code fragment which assumes the unknown object is an instance of the second sub-class ([0093] “Since doArrayStoreCheckOnC( ) has only a single implementation in the class hierarchy rooted at C at this point, the JIT compiler can inline the doArrayStoreCheckOnC( )”).
With further regard to Claim 1, Stoodley does not teach the following, however, Schrammel teaches:
wherein the second-subclass is a sub-class of the class of objects ([0105] “FIG. 5B illustrates the process of performing static analysis… FIG. 5B shows code statements 526, 528, 530 each associated with the instantiation of concrete representations 532, 534, 536 of an abstract class (i.e., the Account abstract class). Code statement 526 instantiates first concrete representation 532 corresponding to a CurrentAccount object which is a subclass of the Account abstract class. Code statement 528 instantiates second concrete representation 534 corresponding to an ISA object which is a subclass of the Account abstract class. Code statement 530 instantiates third concrete representation 536 corresponding to an OverdraftAccount object which is a subclass of the Account abstract class,” wherein Schrammel teaches a plurality of subclasses, i.e. “CurrentAccount”, “ISA” and “OverdraftAccount”, of a class of objects, i.e. the “Account” class of objects. Further, [0200] “A class cast exception heuristic is applied when a class cast exception is thrown. A class cast exception is thrown when an attempt has been made to cast an object to a subclass of which it is not an instance. Therefore, a rule applied by a class cast exception heuristic is to identify a new candidate input value corresponding to an implementation type that is compatible with the class cast exception from prioritized list of candidate input values 328. The chosen implementation type determines the availability of constructors to use for instantiating the object.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Stoodley with the sub-class type as taught by Schrammel for purposes of “improving computer-implemented testing methods and software programs in general” (Schrammel [0015]).
Claim 8:
Stoodley in view of Schrammel teaches all the limitations of claim 1 as described above. Stoodley further teaches wherein executing the second code fragment comprises:
executing a virtual call to an instance of a function using the unknown object ([0085] “To save code space, however, JIT compiler 304 may choose not to inline a conservative implementation into the compiled code. Rather JIT compiler 304 performs a special virtual call.”).
Claim 9: (Currently Amended)
Stoodley teaches a system comprising:
a processor (Fig. 2: Processor Unit 204.); and
a memory device communicatively coupled to the processor, the memory device comprising instructions executable by the processor, the instructions comprising (Fig. 2: Memory 206. [0032] “Processor unit 204 serves to execute instructions for software that may be loaded into memory 206.”):
instructions to execute, as part of runtime execution of a dynamic language ([0007] “the java runtime including the java virtual machine and the just in time compiler.” [0046] “Enhanced JVM 302 provides a capability for speculative class-based optimization that extends a runtime assumption mechanism to enable just in time (JIT) compiler 304 to introduce new features (for example, methods or classes) into a class hierarchy that are not previously present in a Java application being executed.”),
a first comparison test to determine whether an unknown object is an instance of a first sub-class of a class of objects, wherein runtime execution of the dynamic language is dependent on identification of the unknown object at runtime ([0007] “Responsive to a determination the type of the class is not a fixed type, the computer-implemented method determines, by the just in time compiler, whether the class is sub-classed.” [0077] “For example, given a Java statement of: a[i]=x; where the run time class type of a is A[ ] and the run time class type of x is X, the Java specification requires that an array store exception be raised when the object x is non null and class X is not the same as class A and class X is not a subclass of class A which is the basic logic of instructions generated by JIT compiler 304 for arraystore checks,” wherein the raising of an “array store exception” indicates that execution is dependent on the identification of “object x”, i.e. “the unknown object”.); and
instructions, responsive to determining that the unknown object is not an instance of the first sub-class ([0007] “Responsive to a determination the class is not sub-classed”),
to prevent a second comparison test to determine whether the unknown object is an instance of a second sub-class by performing a no operation (NOP) test to determine that there are no additional sub-classes for the class of objects in addition to the first sub-class and a second sub-class ([0084] “JIT compiler 304 places inline a base implementation along with a virtual guard. The virtual guard can be changed in future so as to cause a more conservative implementation to execute when the particular property becomes invalid. Further, the implemented virtual guard may also include a NOP instruction.” [0093] “when the JIT compiler knows that the resolved type C has not been sub-classed at this particular point in time (where A is of resolved type C[ ] and X is of resolved type C) then the compiler can create the virtual synthetic property method doArrayStoreCheckOnC( ) on the class C with the implementation creating an empty method (reflecting that no arraystore check is currently required). Since doArrayStoreCheckOnC( ) has only a single implementation in the class hierarchy rooted at C at this point, the JIT compiler can inline the doArrayStoreCheckOnC( ) method along with a virtual guard containing a NOP instruction. The JIT compiler automatically creates an assumption on the class C to correct the NOP later when any class extends C and overrides the doArrayStoreCheckOnC( ) virtual synthetic property method.” [0095] “ The JIT compiler is aware that there are currently no subclasses of C, (in this example) and therefore creates a virtual guard with NOP to eliminate the condition in the if statements portion of statements 408 which transforms the code into statements 410.”); and
instructions to, responsive to determining that there are no additional sub-classes, execute a second code fragment which assumes the unknown object is an instance of the second sub-class ([0093] “Since doArrayStoreCheckOnC( ) has only a single implementation in the class hierarchy rooted at C at this point, the JIT compiler can inline the doArrayStoreCheckOnC( )”).
With further regard to Claim 9, Stoodley does not teach the following, however, Schrammel teaches:
wherein the second-subclass is a sub-class of the class of objects ([0105] “FIG. 5B illustrates the process of performing static analysis… FIG. 5B shows code statements 526, 528, 530 each associated with the instantiation of concrete representations 532, 534, 536 of an abstract class (i.e., the Account abstract class). Code statement 526 instantiates first concrete representation 532 corresponding to a CurrentAccount object which is a subclass of the Account abstract class. Code statement 528 instantiates second concrete representation 534 corresponding to an ISA object which is a subclass of the Account abstract class. Code statement 530 instantiates third concrete representation 536 corresponding to an OverdraftAccount object which is a subclass of the Account abstract class,” wherein Schrammel teaches a plurality of subclasses, i.e. “CurrentAccount”, “ISA” and “OverdraftAccount”, of a class of objects, i.e. the “Account” class of objects. Further, [0200] “A class cast exception heuristic is applied when a class cast exception is thrown. A class cast exception is thrown when an attempt has been made to cast an object to a subclass of which it is not an instance. Therefore, a rule applied by a class cast exception heuristic is to identify a new candidate input value corresponding to an implementation type that is compatible with the class cast exception from prioritized list of candidate input values 328. The chosen implementation type determines the availability of constructors to use for instantiating the object.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Stoodley with the sub-class type as taught by Schrammel for purposes of “improving computer-implemented testing methods and software programs in general” (Schrammel [0015]).
Claim 10:
Stoodley in view of Schrammel teaches the system of claim 9, and Stoodley teaches further comprising instructions executable by the processor to cause the processor to, responsive to determining that the unknown object is an instance of the first sub-class, execute a first code fragment which assumes the unknown object is an instance of the first sub-class ([0109] “Process 600 begins (step 602) and performs a type propagation analysis of a class (step 604). The class being analyzed is contained within a code portion being compiled, for example a collection of Java statements being compiled by a Just In Time compiler.” [0110] “process 600 determines whether the class is sub-classed (step 608). In response to a determination that the class is sub-classed, process 600 generates code for a conventional function call (step 616) and terminates as before (step 618).”).
Claim 11:
Stoodley in view of Schrammel teaches the system of claim 9, and Stoodley teaches further comprising instructions executable by the processor to cause the processor to, responsive to determining that there are additional sub-classes, execute the second code fragment which refrains from assuming the unknown object is of any particular sub-class ([0109] “Process 600 begins (step 602) and performs a type propagation analysis of a class (step 604). The class being analyzed is contained within a code portion being compiled, for example a collection of Java statements being compiled by a Just In Time compiler.” [0110] “process 600 determines whether the class is sub-classed (step 608). In response to a determination that the class is sub-classed, process 600 generates code for a conventional function call (step 616) and terminates as before (step 618).”).
Claim 12:
Stoodley in view of Schrammel teaches the system of claim 9. Stoodley further teaches
wherein the processor forms part of a just-in-time (JIT) compiler ([0046] “Enhanced JVM 302 provides a capability for speculative class-based optimization that extends a runtime assumption mechanism to enable just in time (JIT) compiler 304 to introduce new features (for example, methods or classes) into a class hierarchy that are not previously present in a Java application being executed.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Ali in view of Schrammel with the JIT compiler as taught by Stoodley in order “to enable a category of speculative optimizations that may not otherwise be expressible as standard kinds of runtime assumptions” (Stoodley [0046]).
Claim 13:
Stoodley in view of Schrammel teaches all the limitations of claim 9 as described above. Stoodley further teaches
wherein executing the second code fragment comprises inlining the second code fragment as an instance of a function using the second sub-class assuming that the unknown object is an instance of the second sub-class ([0083] “An embodiment of selective speculative class-based optimization system 300 relies on efficiently inlining (virtual) synthetic methods.” [0084] “JIT compiler 304 places inline a base implementation along with a virtual guard. The virtual guard can be changed in future so as to cause a more conservative implementation to execute when the particular property becomes invalid.” [0093] “the JIT compiler can inline the doArrayStoreCheckOnC( ) method along with a virtual guard containing a NOP instruction. The JIT compiler automatically creates an assumption on the class C to correct the NOP later when any class extends C and overrides the doArrayStoreCheckOnC( ) virtual synthetic property method.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Ali in view of Schrammel with the code inlining as taught by Stoodley in order “to drive optimization of generated code using the run time assumptions framework of the JVM” (Stoodley [0081]).
Claim 14:
Stoodley in view of Schrammel teaches all the limitations of claim 9 as described above. Stoodley further teaches
wherein executing the second code fragment comprises executing a virtual call to an instance of a function using the unknown object ([0085] “To save code space, however, JIT compiler 304 may choose not to inline a conservative implementation into the compiled code. Rather JIT compiler 304 performs a special virtual call.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Ali in view of Schrammel with the virtual call as taught by Stoodley in order “to drive optimization of generated code using the run time assumptions framework of the JVM” (Stoodley [0081]).
Claims 15-17 and 20:
With regard to Claims 15-17 and 20, these claims are equivalent in scope to Claims 9-12 rejected above, merely having a different independent claim type, and as such Claims 15-17 and 20 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 9-12.
Claims 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over Stoodley in view of Schrammel as applied to Claim 1 above, and further in view of Ogasawara (US PGPUB 2012/0233597; hereinafter “Ogasawara”).
Claim 3:
Stoodley in view of Schrammel teaches all the limitations of claim 1 as described above. Stoodley in view of Schrammel does not teach the following, however, Ogasawara teaches:
wherein determining, by the processor, whether the unknown object is an instance of the first sub-class comprises executing an instanceof test ([0005] “As such subclass test functions, the ‘instanceof’ operator in Java.RTM. programming language and the ‘isinstance’ function in Python, for example, are known.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Stoodley in view of Schrammel with the “instanceof” test as taught by Ogasawara since “In object-oriented languages, subclass test functions for testing whether an object is an instance of a class or an instance of a subclass of a class are often used” (Ogasawara [0005]).
Claim 4:
Stoodley in view of Schrammel teaches all the limitations of claim 1 as described above. Stoodley in view of Schrammel does not teach the following, however, Ogasawara teaches:
wherein determining, by the processor, whether the unknown object is an instance of the first sub-class comprises executing a type test added by a just-in-time (JIT) compiler ([0038] “The optimization method includes a step of determining reusability of code of the subclass test function.” [0062] “The monitoring unit 145 monitors the type information associated with the execution result included in the profile information stored in the profile DB 125. In response to a change made to the type information, the monitoring unit 145 prohibits reuse of the execution result associated with the type information.” [0064] “The monitoring unit 145 is realized by execution of the above instruction sequence in response to execution of the manipulation code. Here, the manipulation code for changing type information may be implementation code of an interpreter or may be JIT code compiled by a JIT compiler.” [0073] “the monitoring process illustrated in FIG. 10 is executed by the interpreter when type information is changed by the interpreter or is executed by JIT code when type information is changed by the JIT code.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Stoodley in view of Schrammel with the JIT compilation as taught by Ogasawara as this “provides an optimization method for optimizing a program” (Ogasawara [0038]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Stoodley in view of Schrammel as applied to Claim 1 above, and further in view of Shaylor (US PGPUB 2002/0104076; hereinafter “Shaylor”).
Claim 5:
Stoodley in view of Schrammel teaches all the limitations of claim 1 as described above. Stoodley in view of Schrammel does not teach the following, however, Shaylor teaches wherein executing the second code fragment comprises:
inlining the second code fragment as an instance of a function using the second sub-class assuming that the unknown object is an instance of the second sub-class ([0027] “The present invention specifically addresses optimization of native code through heavy use of inlining techniques when the code involves target method calls.” [0041] “methods can be inlined, but with a test just before the first instruction of the inlined code that checks whether the class type is correct.” Claim 3 of Shaylor: “when all possible subclasses for the target method's class are known, the method further comprises: generating a code fragment for each possible subclass wherein each code fragment inlines code from the target method as defined by the associated subclass.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Stoodley in view of Schrammel with the code inlining as taught by Shaylor since “inlining makes these target method calls more efficient by copying the code of the target method into the calling method” (Shaylor [0013]).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Stoodley in view of Schrammel as applied to Claim 15 above, and further in view of Teodorescu et al. (US PGPUB 2016/0335062; hereinafter “Teodorescu”).
Claim 19:
Stoodley in view of Schrammel teaches all the limitations of claim 15 as described above. Stoodley in view of Schrammel does not teach the following, however, Teodorescu teaches:
wherein the code fragments, unknown objects, and classes are defined in a .class file ([0091] “the code can be provided as compiled class files. The class files can be anything suitable to execute on a virtual machine (e.g., JVM). The code can range from a single class up to the code for an entire computer data system. The class files can include a) Java code that has been compiled to JVM bytecode files; b) non-Java code (e.g. scala, groovy, etc.) that has been compiled to JVM bytecode files; and/or c) JVM classes and objects that have been dynamically generated.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the computer program product as disclosed by Stoodley in view of Schrammel with the class file as taught by Teodorescu so that “The dynamically loaded code 612 may ‘override’ a portion 614 or all of the initial code deployment 616” (Teodorescu [0083]), in order to “provide an advantage of being a mechanism that can reliably and safely replace (or augment) core data system engine/server component classes as well as a mechanism for deploying new functionality to all or a subset of users” (Teodorescu [0083]).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Stoodley in view of Schrammel as applied to Claim 1 above, and further in view of Ogasawara and Teodorescu.
Claim 21:
Stoodley in view of Schrammel teaches the method of claim 1. Stoodley does not teach the following, however, Schrammel teaches:
wherein the first sub-class and the second sub-class are non-abstract sub-classes ([0105] “FIG. 5B illustrates the process of performing static analysis… FIG. 5B shows code statements 526, 528, 530 each associated with the instantiation of concrete representations 532, 534, 536 of an abstract class (i.e., the Account abstract class). Code statement 526 instantiates first concrete representation 532 corresponding to a CurrentAccount object which is a subclass of the Account abstract class. Code statement 528 instantiates second concrete representation 534 corresponding to an ISA object which is a subclass of the Account abstract class. Code statement 530 instantiates third concrete representation 536 corresponding to an OverdraftAccount object which is a subclass of the Account abstract class,” wherein the plurality of subclasses, i.e. “CurrentAccount”, “ISA” and “OverdraftAccount”, are “concrete representation[s]”, i.e. “non-abstract sub-classes”.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Stoodley with the sub-class type as taught by Schrammel for purposes of “improving computer-implemented testing methods and software programs in general” (Schrammel [0015]).
With further regard to Claim 21, Stoodley further teaches
wherein the processor forms part of a just-in-time (JIT) compiler ([0046] “Enhanced JVM 302 provides a capability for speculative class-based optimization that extends a runtime assumption mechanism to enable just in time (JIT) compiler 304 to introduce new features (for example, methods or classes) into a class hierarchy that are not previously present in a Java application being executed.”).
With further regard to Claim 21, Stoodley in view of Schrammel does not teach the following, however, Ogasawara teaches:
wherein determining whether the unknown object is an instance of the first sub-class comprises executing an instanceof test ([0005] “As such subclass test functions, the ‘instanceof’ operator in Java.RTM. programming language and the ‘isinstance’ function in Python, for example, are known.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Stoodley in view of Schrammel with the “instanceof” test as taught by Ogasawara since “In object-oriented languages, subclass test functions for testing whether an object is an instance of a class or an instance of a subclass of a class are often used” (Ogasawara [0005]).
With further regard to Claim 21, Stoodley in view of Schrammel and Ogasawara does not teach the following, however, Teodorescu teaches:
wherein code fragments, unknown objects, and classes are defined in a .class file ([0091] “the code can be provided as compiled class files. The class files can be anything suitable to execute on a virtual machine (e.g., JVM). The code can range from a single class up to the code for an entire computer data system. The class files can include a) Java code that has been compiled to JVM bytecode files; b) non-Java code (e.g. scala, groovy, etc.) that has been compiled to JVM bytecode files; and/or c) JVM classes and objects that have been dynamically generated.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Stoodley in view of Schrammel and Ogasawara with the class file as taught by Teodorescu so that “The dynamically loaded code 612 may ‘override’ a portion 614 or all of the initial code deployment 616” (Teodorescu [0083]), in order to “provide an advantage of being a mechanism that can reliably and safely replace (or augment) core data system engine/server component classes as well as a mechanism for deploying new functionality to all or a subset of users” (Teodorescu [0083]).
Response to Arguments
With respect to the Applicant’s argument, Pages 6-8 of the Remarks filed March 27, 2026, that the previously cited prior art does not teach the newly amended claim language, the Office respectfully disagrees. Upon further review of the prior art, the Office contends that the previously cited Stoodley et al. (US PGPUB 2014/0325493) reference does teach the newly amended language recited in independent claims 1, 9 and 15. The Office respectfully directs the Applicant’s attention to the newly modified rejections of claims 1, 9 and 15 above for further explanation regarding how the Stoodley reference has been interpreted as teaching the newly amended language of independent claims 1, 9 and 15.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Wu et al. (US PGPUB 2004/0103391) discloses a method and apparatus for identifying a type of a software object, wherein the identifying includes a process of comparing the object type to both a target type and a root type and then setting the object type to a super object type if the object type is not either of the target or root type.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/JOANNE G MACASIANO/Examiner, Art Unit 2197
Prosecution Insights