DETAILED ACTION
This action is in response to claims filed 26 January 2023 for application 18159889 filed 26 January 2023. Currently claims 1-20 are pending.
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 Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-11, 13-14, 16-17, and 20 are rejected under 35 U.S.C. 102(A)(1) as being anticipated by Saboori et al. (US 20210350233).
Regarding claim 1, Saboori discloses: A system for deploying neural networks in low bit environments, the system comprising:
a runtime platform (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010], target hardware platform [0025]);
a first set of configuration parameters identifying limitations of the runtime platform (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010]);
a quantization platform for quantizing neural networks (“The engine 10 also provides content aware optimization, by providing a two-level intermediate layer composed of: a) the design space exploration module 26, which is an intermediate layer for finding a smaller architecture with similar performance as the given model to reduce memory footprint and computation (described in greater detail below); and b) the quantizer 28, which is a low-level layer for quantizing the network to gain further computation speedup.” [0027]), the quantization platform:
receiving a neural network associated with a framework and quantizing the neural network into a smaller neural network (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010]); and
generating a dataset comprising a second set of configuration parameters for compiling the smaller neural network into instructions for the runtime platform, the second set of configuration parameters being responsive to the limitations of the first set of configuration parameters (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010]); and
wherein the runtime platform implements the smaller neural network in accordance with the second set of configuration parameters (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010]).
Regarding claim 2, Saboori discloses: The system of claim 1, wherein:
the runtime platform includes two or more operators (“It is also recognized that a major challenge lies in enabling support for multiple hardware back-ends while keeping compute, memory and energy footprints at their lowest. Content aware optimization alone is not considered to be enough to solve the challenge of supporting different hardware back ends. The reason being that primitive operations like convolution or matrix multiplication may be mapped and optimized in very different ways for each hardware back-end. These hardware-specific optimizations can vary drastically in terms of memory layout, parallelization threading patterns, caching access patterns and choice of hardware primitives.” [0030]); and
the second set of configuration parameters specify at least one of (1) an order of the two or more operators, or (2) a composition of the two or more operators for use by the runtime platform (“It is also recognized that a major challenge lies in enabling support for multiple hardware back-ends while keeping compute, memory and energy footprints at their lowest. Content aware optimization alone is not considered to be enough to solve the challenge of supporting different hardware back ends. The reason being that primitive operations like convolution or matrix multiplication may be mapped and optimized in very different ways for each hardware back-end. These hardware-specific optimizations can vary drastically in terms of memory layout, parallelization threading patterns, caching access patterns and choice of hardware primitives.” [0030], note: the different primitive operations such as convolution or multiplication are interpreted as the composition of two or more operators).
Regarding claim 3, Saboori discloses: The system of claim 1, wherein the first set of configuration parameters relate to at least one of a target precision, a resulting layout of the smaller neural network, a target accuracy, and a target architecture (“FIG. 2 illustrates an example of an architecture for the DNN optimization engine 10. The engine 10 in this example configuration includes a model converter 22 which can interface with a number of frameworks 20, an intermediate representation model 24, a design space exploration module 26, a quantizer 28, and mapping algorithms 30 that can include algorithms for both heterogeneous hardware 32 and homogeneous hardware 34. The engine 10 is also interfaces with a target hardware (HW) platform 16. The design space exploration module 26, quantizer 28, and mapping algorithms 30 adopt, apply, consider, or otherwise take into account the constraints 19. In this example, the constraints include accuracy, power, cost, supported precision, speed, among others that are possible as shown in dashed lines. FIG. 2 illustrates a framework with maximum re-use in mind, so that new AI frameworks 20, new DNN architectures and new hardware architectures can be easily added to a platform utilizing the engine 10. The engine 10 addresses inference optimization of DNNs by leveraging state-of-the-art algorithms and methodologies to make DNNs applicable for any device 16. This provides an end-to-end framework to optimize DNNs from different deep learning framework front-ends down to low-level machine code for multiple hardware back-ends.” [0025]).
Regarding claim 4, Saboori discloses: The system of claim 3, wherein the target architecture indicates the two or more operators (“For the model converter 22, the engine 10 is configured to support multiple frameworks 20 (e.g. TensorFlow, Pytorch, etc.) and DNN architectures (e.g. CNN, RNN, etc.), to facilitate applying the engine's capabilities on different projects with different AI frameworks 20. To do so, two layers are included, namely: a) the model convertor 22 which contains each AI frameworks' specifications and DNNs' parser to produce the intermediate representation model (IRM) 24 from the original model; and b) the IRM 24 which represents all DNN models in a standard format.” [0026]).
Regarding claim 5, Saboori discloses: The system of claim 1, wherein at least some of the second set of configuration parameters are for a subset of a plurality of nodes (“Regarding the design space exploration module 26, DNNs are heavily dependent on the design of hyper-parameters like the number of hidden layers, nodes per layer and activation functions, which have traditionally been optimized manually. Moreover, hardware constraints 19 such as memory and power should be considered to optimize the model effectively. Given spaces can easily exceed thousands of solutions, it can be intractable to find a near-optimal solution manually.” [0028]).
Regarding claim 6, Saboori discloses: The system of claim 1, wherein the first set of configuration parameters or the second set of configuration parameters comprises different configuration parameters for different nodes of a plurality of nodes (“Regarding the design space exploration module 26, DNNs are heavily dependent on the design of hyper-parameters like the number of hidden layers, nodes per layer and activation functions, which have traditionally been optimized manually. Moreover, hardware constraints 19 such as memory and power should be considered to optimize the model effectively. Given spaces can easily exceed thousands of solutions, it can be intractable to find a near-optimal solution manually.” [0028]).
Regarding claim 7, Saboori discloses: The system of claim 1, wherein quantizing the neural network comprises training the neural network to satisfy at least one of the first set of configuration parameters (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010]).
Regarding claim 8, Saboori discloses: The system of claim 7, wherein the training is performed with a first device, and the smaller neural network is output to a second device (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010], note: the learning is performed on a different device than the target device).
Regarding claim 9, Saboori discloses: The system of claim 1, wherein the quantization platform reuses the first set of configuration parameters for quantizing another neural network (“FIG. 2 illustrates a framework with maximum re-use in mind, so that new AI frameworks 20, new DNN architectures and new hardware architectures can be easily added to a platform utilizing the engine 10. The engine 10 addresses inference optimization of DNNs by leveraging state-of-the-art algorithms and methodologies to make DNNs applicable for any device 16. This provides an end-to-end framework to optimize DNNs from different deep learning framework front-ends down to low-level machine code for multiple hardware back-ends.” [0025]).
Regarding claims 10 and 20, Saboori discloses: A method for deploying neural networks in low bit environments, the method comprising:
providing a quantized neural network having a plurality of operations (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010]);
providing a set of configuration parameters for implementing the quantized neural network with a runtime platform having two or more operators (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010], “It is also recognized that a major challenge lies in enabling support for multiple hardware back-ends while keeping compute, memory and energy footprints at their lowest. Content aware optimization alone is not considered to be enough to solve the challenge of supporting different hardware back ends. The reason being that primitive operations like convolution or matrix multiplication may be mapped and optimized in very different ways for each hardware back-end. These hardware-specific optimizations can vary drastically in terms of memory layout, parallelization threading patterns, caching access patterns and choice of hardware primitives.” [0030];
compiling the quantized neural network to generate compiled code, the compiled code specifying implementing at least some of the plurality of operations of the generated compiled code with one of the two or more operators, based on the set of configuration parameters (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010]); and
implementing the generated compiled code with the runtime platform (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010], note: the neural network inherently comprises code executed on the target device).
Regarding claim 11, Saboori discloses: The method of claim 10, wherein the set of configuration parameters specifies implementing different operators of the two or more operators for different parts of the compiled code (“It is also recognized that a major challenge lies in enabling support for multiple hardware back-ends while keeping compute, memory and energy footprints at their lowest. Content aware optimization alone is not considered to be enough to solve the challenge of supporting different hardware back ends. The reason being that primitive operations like convolution or matrix multiplication may be mapped and optimized in very different ways for each hardware back-end. These hardware-specific optimizations can vary drastically in terms of memory layout, parallelization threading patterns, caching access patterns and choice of hardware primitives.” [0030]).
Regarding claim 13, Saboori discloses: The method of claim 10, wherein the set of configuration parameters specifies different operators of the two or more operators for different layers of the quantized neural network (“It is also recognized that a major challenge lies in enabling support for multiple hardware back-ends while keeping compute, memory and energy footprints at their lowest. Content aware optimization alone is not considered to be enough to solve the challenge of supporting different hardware back ends. The reason being that primitive operations like convolution or matrix multiplication may be mapped and optimized in very different ways for each hardware back-end. These hardware-specific optimizations can vary drastically in terms of memory layout, parallelization threading patterns, caching access patterns and choice of hardware primitives.” [0030], “The engine 10 described herein exploits low precision weights using reinforcement learning to learn an optimal precision configuration across the neural network where each layer may have different precision to get the best out of the target platform 16. Besides mixed-precision, the engine 10 also supports uniform precision, fixed-point, dynamic fixed-point and binary/ternary networks.” [0029], Note: different operators can be used on different layers).
Regarding claim 14, Saboori discloses: The method of claim 10, further comprising:
providing a neural network from a framework associated with a second runtime platform having one or more operators (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010]);
quantizing the neural network into the quantized neural network ([0010], [0027]),
wherein the set of configuration parameters for implementing the quantized neural network specifies implementing at least some of the plurality of operations of the generated compiled code with the one or more operators of the first runtime platform and further specifies implementing at least some of the plurality of operations of the generated compiled code with the two or more operators (“In one aspect, there is provided a method of automated precision configuration for deep neural networks, the method comprising: obtaining an input model and one or more constraints associated with an application and/or target device or process used in the application configured to utilize a deep neural network; learning an optimal low-precision configuration of the optimal architecture using the input model, constraints, the training data set, and the validation data set; and deploying the optimal configuration on the target device or process for use in the application.” [0010], see also [0030]).
Regarding claim 16, Saboori discloses: The method of claim 10, wherein compiling the quantized neural network comprises casting elements of the quantized neural network from a first data type into a second data type (“The engine 10 described herein exploits low precision weights using reinforcement learning to learn an optimal precision configuration across the neural network where each layer may have different precision to get the best out of the target platform 16. Besides mixed-precision, the engine 10 also supports uniform precision, fixed-point, dynamic fixed-point and binary/ternary networks.” [0029]).
Regarding claim 17, Saboori discloses: The method of claim 10, wherein the runtime platform can process compiled code from different code compilers, or operate on more than one device type (FIG. 2 illustrates a framework with maximum re-use in mind, so that new AI frameworks 20, new DNN architectures and new hardware architectures can be easily added to a platform utilizing the engine 10. The engine 10 addresses inference optimization of DNNs by leveraging state-of-the-art algorithms and methodologies to make DNNs applicable for any device 16. This provides an end-to-end framework to optimize DNNs from different deep learning framework front-ends down to low-level machine code for multiple hardware back-ends.” [0025], see also [0031]).
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 12 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Saboori in view of Interlandi et al. (US 20220051104).
Regarding claim 12, Saboori does not explicitly disclose: The method of claim 10, wherein the two or more operators include at least one custom operator.
Interlandi teaches: wherein the two or more operators include at least one custom operator (“In step 204, the set of ML operators is mapped to a set of neural network operators. For instance, with reference to FIG. 3, ML pipeline parser 302 is configured to map ML operator set 304 to neural network operator set 306. In examples, neural network operator set 306 may comprise a set of tensor-based implementations that may implement one or more ML-based operators. Once each of the tensor-based implementations is registered, ML pipeline parser 302 may implement a conversion for mapping each of the ML operators to one or more of the neural network operators. For instance, a particular ML operator in ML operator set 304 may be mapped to a particular tensor-based implementation in neural network operator set 306. In this manner, each of the operators in ML operator set 304 may be mapped (e.g., converted to) a tensor-based operator of neural network operator set 306. It is noted and understood that for each operator, ML pipeline parser 302 may select a particular tensor-based implementation (e.g., the best or most suitable one for a given implementation) from among a plurality of implementations. For instance, ML pipeline parser 302 may be configured to map a particular ML operator to one of a plurality of tensor implementations, based on the information contained in the ML operator. In examples, neural network operator set 306 may be registered via one or more APIs of a neural network framework (e.g., DNN framework).” [0044]).
Saboori and Interlandi are in the same field of endeavor of neural network implementations and are analogous. Saboori discloses a quantizer for selection and optimization of a model to target hardware. Interlandi discloses known neural network operators and the use of custom and updated operators. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the known model quantization and optimization disclosed by Saboori with the known operator modifications as taught by Interlandi to yield predictable results.
Regarding claim 15, Saboori does not explicitly disclose: The method of claim 10, further comprising updating the two or more operators.
Interlandi teaches: further comprising updating the two or more operators (“In step 204, the set of ML operators is mapped to a set of neural network operators. For instance, with reference to FIG. 3, ML pipeline parser 302 is configured to map ML operator set 304 to neural network operator set 306. In examples, neural network operator set 306 may comprise a set of tensor-based implementations that may implement one or more ML-based operators. Once each of the tensor-based implementations is registered, ML pipeline parser 302 may implement a conversion for mapping each of the ML operators to one or more of the neural network operators. For instance, a particular ML operator in ML operator set 304 may be mapped to a particular tensor-based implementation in neural network operator set 306. In this manner, each of the operators in ML operator set 304 may be mapped (e.g., converted to) a tensor-based operator of neural network operator set 306. It is noted and understood that for each operator, ML pipeline parser 302 may select a particular tensor-based implementation (e.g., the best or most suitable one for a given implementation) from among a plurality of implementations. For instance, ML pipeline parser 302 may be configured to map a particular ML operator to one of a plurality of tensor implementations, based on the information contained in the ML operator. In examples, neural network operator set 306 may be registered via one or more APIs of a neural network framework (e.g., DNN framework).” [0044] note: changing operators from one form to another is interpreted as updating).
Claim(s) 18 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Saboori in view of Luo et al. (US 20200210816).
Regarding claim 18, Saboori does not explicitly disclose: The method of claim 10, wherein the set of configuration parameters specify a target encoding scheme for at least some weights and activations of the quantized neural network.
Luo teaches: wherein the set of configuration parameters specify a target encoding scheme for at least some weights and activations of the quantized neural network (“During operation, the mode configuration control 202 may be used to select weights and/or other parameters in weight memory 228 associated with a particular encoding technique (e.g., Reed-Solomon coding, BCH coding, LDPC coding, and/or Polar coding). The hardware implementation of neural network 200 may then utilize the selected weights and/or other parameters to function as a decoder for data encoded with that encoding technique.” [0053]).
Saboori and Luo are in the same field of endeavor of neural network implementations and are analogous. Saboori discloses a quantizer for selection and optimization of a model to target hardware. Luo teaches known neural network weight/parameter encoding schemes. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the known model quantization and optimization disclosed by Saboori with the known encoding schemes as taught by Luo to yield predictable results.
Regarding claim 19, Saboori does not explicitly disclose: The method of claim 18, wherein the target encoding scheme is unipolar or bipolar.
Luo teaches: wherein the target encoding scheme is unipolar or bipolar (“During operation, the mode configuration control 202 may be used to select weights and/or other parameters in weight memory 228 associated with a particular encoding technique (e.g., Reed-Solomon coding, BCH coding, LDPC coding, and/or Polar coding). The hardware implementation of neural network 200 may then utilize the selected weights and/or other parameters to function as a decoder for data encoded with that encoding technique.” [0053]).
Response to Arguments
Applicant's arguments filed 13 January 2026 have been fully considered but they are not persuasive. Applicant argues that Saboori does not disclose compiling in claims 1, 11 and 20. Examiner respectfully disagrees. By broadest reasonable interpretation, compiling is creating hardware specific instructions from another form. Claims 5 and 6 of the instant application show that the configuration parameters that are compiled are parameters such as nodes. Looking at figure 2 of Saboori, the multistep process of converting the model, finding a smaller model, quantizing the model, and then mapping the model to the hardware is shown. The steps between the framework and the target hardware are interpreted as a compilation process. The arguments mention a software runtime environment however, the runtime platform of the claims is interpreted as the software and hardware as a whole. Further details about what is required during runtime in the claims could be beneficial in advancing prosecution past the current interpretation.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Burger et al. (US 20190340499) discloses details of compiling a DNN and quantizing for accelerated performance [0047] in a runtime emulator.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC NILSSON whose telephone number is (571)272-5246. The examiner can normally be reached M-F: 7-3.
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, James Trujillo can be reached at (571)-272-3677. 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.
/ERIC NILSSON/ Primary Examiner, Art Unit 2151