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 .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action.
This application includes one or more claim limitations in Claims 1-20 that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
“an interface module for receiving” in Claims 1-10 and “a simulation generator module for generating” in Claims 1-20.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1-20 contain computer-implemented 35 U.S.C. 112(f) limitations which were found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, as such these limitations also lack written description under 35 U.S.C. 112(a), see MPEP 2181(II)(B).
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim limitations “an interface module for receiving” in Claims 1-10, and “a simulation generator module for generating” in Claims 1-20, invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The Applicant’s specification only mentions these terms in the context of examples/embodiments which include them, but does not recite the corresponding structure, material or acts to perform the function. Therefore, the claims are indefinite and are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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-2, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos et al. (US PGPUB 2015/0339217; hereinafter “Avgerinos”) in view of Saha et al. (US PGPUB 2023/0106929; hereinafter “Saha”).
Claim 1:
Avgerinos teaches a unified simulation interface system comprising:
an interface module for receiving a simulation build graph ([0056] “Once the CFG is obtained, various example embodiments of the methods and systems discussed herein proceed to the next operation.” [0110] “The software testing machine 1110 is shown as including… a CFG module 1240 (e.g., a control flow graph generator, as discussed above with respect to FIG. 3)”),
wherein the simulation build graph comprises a static portion and a dynamic portion ([0047] “DSE [dynamic symbolic exploration] and SSE [static symbolic exploration] may be combined (e.g., alternated dynamically and opportunistically).” [0049] “the example embodiments analyze a dynamically recovered CFG and identify a core of statements that are easy for SSE to analyze, as well as a frontier of statements that are difficult for SSE to analyze. The SSE algorithm summarizes the effects of all paths through the easy statements (e.g., nodes) up to the hard frontier. Accordingly, some example embodiments of the methods and systems described herein then switch back to DSE to handle the statically difficult cases appropriately and may thereafter alternate between DSE and SSE in response to similar criteria.”), and
the interface module generates [inputs] for execution nodes comprising the static portion of the simulation build graph ([0006] “Symbolic execution can be attractive, because it systematically explores the software code (e.g., program) and produces real inputs… by automatically translating a software code fragment… into a formula… The logical formula is then solved to determine inputs.” [0116] “In operation 1340, the SSE module 1220 performs a static phase (e.g., an SSE phase) of the automatic test of the software code. Specifically, the SSE module 1220 performs SSE on the portion (e.g., the second portion) of the execution paths determined in operation 1330 to be devoid of non-statically interpretable executable statements.”);
a simulation generator module for generating [inputs] for execution nodes comprising the dynamic portion of the simulation build graph ([0006] “Symbolic execution can be attractive, because it systematically explores the software code (e.g., program) and produces real inputs… by automatically translating a software code fragment… into a formula… The logical formula is then solved to determine inputs.” [0114] “In operation 1320, the DSE module 1210 performs a dynamic phase (e.g., DSE phase) of an automatic test of the software code. Specifically, the DSE module 1210 performs DSE on a portion (e.g., a first portion) of the execution paths of the software code”); and
a remote build execution service for receiving the [inputs] generated by the interface module and the simulation generator module, and scheduling execution of tasks in connection with the received [inputs] for the execution nodes of the simulation build graph on a compute cluster ([0127] “As shown in FIG. 15, operation 1560 may be performed after operation 1350, in which the solver module 1230 generates the set of test cases based on formulas generated during the dynamic and static phases (e.g., multiple dynamic phase and multiple static phases) of the automatic test. In operation 1560, the solver module 1230 determines a set of one or more software bugs in the software code. The determination may be performed by concretely executing one or more test cases from the generated set of test cases from operation 1350.” [0085] “In performing the evaluations, all experiments on the example system were distributed among a private cluster consisting of 100 virtual nodes (e.g., virtual software testing machines).” [0148] “The performance of certain operations may be distributed among the one or more processors, whether residing only within a single machine or deployed across a number of machines.”).
With further regard to Claim 1, Avgerinos does not teach the following, however, Saha teaches:
wherein generating [inputs] comprises generating application programming interface (API) payloads for execution nodes ([0021] “paths of the PDG may be explored by generating inputs that are similar to inputs that resulted in failures,” wherein the “PDG” is similar to the “CFG” discussed in Avgerinos. [0024] “the initial test input generation module 108 generates random input… the random test inputs may include a sequence of API calls with random data,” wherein the “random data” is the “payload” in this instance. [0044] “generating realistic production payload data in privacy-preserving way to recommend untested system behavior for black-box API access.”); and
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 Avgerinos with the use of API payloads as taught by Saha in order to “enable developers to design a technology-agnostic API interface” (Saha [0019]).
Claim 2:
Avgerinos in view of Saha teaches the unified simulation interface system of Claim 1 and Avgerinos further teaches wherein the simulation generator is invoked by the interface module to process the execution nodes comprising the dynamic portion of the simulation build graph ([0116] “In FIG. 13, a loopback arrow is provided to indicate that the software testing machine 1110 may repeatedly execute operations 1320, 1330, and 1340, or similar operations, to dynamically and opportunistically alternate (e.g., switch) back and forth between DSE and SSE, as appropriate for various portions of the execution paths in the software code to be tested.”).
Claim 11:
With regard to Claim 11, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 11 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
Claim 17:
With regard to Claim 17, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 17 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
With further regard to Claim 17, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Avgerinos reference also anticipates these additional elements of Claim 17, for example, Avgerinos teaches:
One or more non-transitory computer-readable storage media comprising instructions for execution that, when executed by a processor, are operable to cause to be performed operations ([0135] “FIG. 17 is a block diagram illustrating components of a machine 1700, according to some example embodiments, able to read instructions 1724 from a machine-readable medium 1722 (e.g., a non-transitory machine-readable medium, a machine-readable storage medium, a computer-readable storage medium, or any suitable combination thereof) and perform any one or more of the methodologies discussed herein.” [0137] “The machine 1700 includes a processor 1702”).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha as applied to Claim 1 above, and further in view of Plate et al. (US PGPUB 2025/0348596; hereinafter “Plate”).
Claim 3:
Avgerinos in view of Saha teaches all the limitations of claim 1 as described above. Avgerinos in view of Saha does not teach the following, however, Plate teaches:
wherein the interface module comprises a Bazel client ([0054] “In some cases, the orchestrator 145 may use Bazel, an open-source build tool used for the automation of building and testing software.”).
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 Avgerinos in view of Saha with the Bazel client as taught by Plate in order to reduce software development costs, as Bazel is a free open-source software tool.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha and Plate as applied to Claim 3 above, and further in view of Urhegyi (“Introducing the Remote Execution API Testing Project,” 2019; hereinafter “Urhegyi”).
Claim 4:
Avgerinos in view of Saha and Plate teaches all the limitations of claim 3 as described above. Avgerinos in view of Saha and Plate does not teach the following, however, Urhegyi teaches:
wherein the API payloads comprise Bazel remote execution API (REAPI) payloads (Paragraphs 1-2: “Introducing Remote Execution to builds will help achieve this, and for this, there is Bazel's Remote Execution API, which gives us the ability to parallelise the construction and validation phases of the software development cycle, and thus massively reduce elapsed time. The API specifies protocols for both client and server.”).
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 Avgerinos in view of Saha and Plate with the use of the remote execution API as taught by Urhegyi in order “to get critical updates and features out to users as quickly as possible and … to increase the productivity of teams who rely on an efficient edit and compile cycle” (Urhegyi Paragraph 1).
Claims 5, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha as applied to Claims 1, 11 and 17 above, and further in view of Mazumdar et al. (US PGPUB 2023/0195596; hereinafter “Mazumdar”).
Claim 5:
Avgerinos in view of Saha teaches all the limitations of claim 1 as described above. Avgerinos in view of Saha does not teach the following, however, Mazumdar teaches:
wherein the compute cluster comprises a compute scheduler and a plurality of compute workers ([0049] “The cloud platform 1406 may include a runtime service 1417 that may provide an intermediate persistence layer for test execution requests which will be consumed by a poller service 1422 deployed in a cluster 1418.” [0059] “The cluster 1418 may be comprised of one master node (not shown) and a number of worker nodes on which the services (e.g., poller service, scheduler service, execution jobs, etc.) run.”).
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 Avgerinos in view of Saha with the compute cluster components as taught by Mazumdar in order “to facilitate dynamic load testing with multiple load testing tools in a shared platform” (Mazumdar [0028]).
Claims 13 and 19:
With regard to Claims 13 and 19, these claims are equivalent in scope to Claim 5 rejected above, merely having a different independent claim type, and as such Claims 13 and 19 are rejected under the same grounds and for the same reasons as discussed above with regard to Claim 5.
Claims 6-7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha as applied to Claims 1, 11 and 17 above, and further in view of Reddy et al. (US PGPUB 2022/0164181; hereinafter “Reddy”).
Claim 6:
Avgerinos in view of Saha teaches all the limitations of claim 1 as described above. Avgerinos in view of Saha does not teach the following, however, Reddy teaches:
wherein the nodes comprising the dynamic portion of the simulation build graph comprise dynamic dependencies among the nodes of the dynamic portion of the simulation build graph ([0006] “An internal-domain dynamic dependency graph is generated, in an aspect, by tracing a first plurality of method calls based on execution of the code base in an internal domain. The internal-domain dynamic dependency graph includes a second plurality of dependencies identified for the one or more client workflows based on the first plurality of method calls, in some aspects.” [0060] “the internal-domain dynamic dependency graph can indicate which method calls “called” other particular methods, which specific methods were called by other methods, and the sequencing of calls/calling between methods”).
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 Avgerinos in view of Saha with the graph comprising dynamic dependencies as taught by Reddy as this “provides a comprehensive view of all or nearly all of the dependencies present in the workflows” (Reddy [0044]).
Claim 7:
Avgerinos in view of Saha teaches all the limitations of claim 1 as described above. Avgerinos in view of Saha does not teach the following, however, Reddy teaches:
wherein the nodes comprising the static portion of the simulation build graph comprise only static dependencies ([0005] “ a static dependency graph is generated that maps a first plurality of dependencies for one or more client workflows encoded in a code base.” [0040] “the static dependency graph module 102 generates a static dependency graph that maps a first plurality of dependencies for one or more client workflows, as the workflows are encoded in a code base. The static dependency graph module 102 scans the code in a static manner, without execution of the code, in aspects.”).
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 Avgerinos in view of Saha with the graph comprising static dependencies as taught by Reddy as this “provides a comprehensive view of all or nearly all of the dependencies present in the workflows” (Reddy [0044]).
Claims 14 and 20:
With regard to Claims 14 and 20, these claims are equivalent in scope to Claims 6-7 rejected above, merely having a different independent claim type, and as such Claims 14 and 20 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 6-7.
Claims 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha as applied to Claims 1 and 11 above, and further in view of Bramley-Moore (“remote_asset.proto,” 2023; hereinafter “Bramley-Moore”).
Claim 8:
Avgerinos in view of Saha teaches all the limitations of claim 1 as described above. Avgerinos in view of Saha does not teach the following, however, Bramley-Moore teaches:
further comprising a native object fetching service, wherein the native object fetching service is configured to move a data asset described using a Bazel remote execution API (REAPI) extension directly to a compute worker from a data store remote from the compute worker (Lines 32-33: “The Remote Asset API provides a mapping from a URI and Qualifiers to Digests.” Lines 86-88: “service Fetch { Resolve or fetch referenced assets, making them available to the caller and other consumers.” Line 102: “Servers *MAY* cache fetched content and reuse it for subsequent requests.”).
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 Avgerinos in view of Saha with the use of the fetching service as taught by Bramley-Moore in order to standardize and simplify the manner in which data assets can be made available for use by the various software modules.
Claim 15:
With regard to Claim 15, this claim is equivalent in scope to Claim 8 rejected above, merely having a different independent claim type, and as such Claim 15 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 8.
Claims 9-10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha and Bramley-Moore as applied to Claims 8 and 15 above, and further in view of Schouten (“remote_execution.proto,” 2023; hereinafter “Schouten”).
Claim 9:
Avgerinos in view of Saha and Bramley-Moore teaches all the limitations of claim 8 as described above. Avgerinos in view of Saha and Bramley-Moore does not teach the following, however, Schouten teaches:
wherein the native object fetching service further comprises a native Bazel target in which metadata for scheduling a replay on the compute worker is packaged (Lines 407-418: “Fetch the entire directory tree rooted at a node. This request must be targeted at a [Directory][build.bazel.remote.execution.v2.Directory] stored in the [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage] (CAS). The server will enumerate the `Directory` tree recursively and return every node descended from the root. The GetTreeRequest.page_token parameter can be used to skip ahead in the stream (e.g. when retrying a partially completed and aborted request), by setting it to a value taken from GetTreeResponse.next_page_token of the last successfully processed GetTreeResponse),” wherein the “GetTreeRequest.page_token parameter” is the “metadata for scheduling a replay”.).
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 Avgerinos in view of Saha and Bramley-Moore with the use of a Bazel target for the fetching service as taught by Schouten in order to standardize and simplify the manner in which data assets can be made available for use by the various software modules.
Claim 10:
Avgerinos in view of Saha, Bramley-Moore and Schouten teaches all the limitations of claim 9 as described above. Avgerinos in view of Saha and Bramley-Moore does not teach the following, however, Schouten teaches:
wherein the native Bazel target employs at least one user-defined configuration flag to expand capabilities of the native Bazel target (Lines 1767-1773: “message GetTreeRequest {The instance of the execution system to operate against. A server may support multiple instances of the execution system (with their own workers, storage, caches, etc.). The server MAY require use of this field to select between them in an implementation-defined fashion, otherwise it can be omitted. string instance_name = 1,” wherein the “string instance_name = 1” is the “user-defined configuration flag”).
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 Avgerinos in view of Saha and Bramley-Moore with the use of a user-defined configuration flag as taught by Schouten in order to advantageously enable the ‘fetching-service’ to be customized based on a user’s desired functionality.
Claim 16:
With regard to Claim 16, this claim is equivalent in scope to Claim 9 rejected above, merely having a different independent claim type, and as such Claim 16 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 9.
Claims 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Avgerinos in view of Saha as applied to Claims 11 and 17 above, and further in view of Urhegyi.
Claim 12:
Avgerinos in view of Saha teaches all the limitations of claim 11 as described above. Avgerinos in view of Saha does not teach the following, however, Urhegyi teaches:
wherein the API payloads comprise Bazel remote execution API (REAPI) payloads (Paragraphs 1-2: “Introducing Remote Execution to builds will help achieve this, and for this, there is Bazel's Remote Execution API, which gives us the ability to parallelise the construction and validation phases of the software development cycle, and thus massively reduce elapsed time. The API specifies protocols for both client and server.”).
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 Avgerinos in view of Saha with the use of the remote execution API as taught by Urhegyi in order “to get critical updates and features out to users as quickly as possible and … to increase the productivity of teams who rely on an efficient edit and compile cycle” (Urhegyi Paragraph 1).
Claim 18:
With regard to Claim 18, this claim is equivalent in scope to Claim 12 rejected above, merely having a different independent claim type, and as such Claim 18 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 12.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Rausch et al. (US PGPUB 2020/0406927) disclose a method for testing a vehicle system, wherein a behavior of the vehicle or of a vehicle system of the vehicle is ascertained in a simulation for at least one of a plurality of possible sequences.
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