DETAILED ACTION
This office action is in response to claims filed 31 May 2023.
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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to and abstract idea (mental process) without significantly more.
Regarding claim 1, in step 1 of the 101 analysis set forth in MPEP 2106, the claim recites a method that provisions resources for service calls based on a service call prediction path and business flow dependency graph. A method is one of the four statutory categories of invention.
In step 2A, prong 1 of the 101 analysis set forth in the MPEP 2106, the examiner has determined that the following limitations recite a process that, under the broadest reasonable interpretation, covers a mental process but for recitation of generic computer components:
i. “calculating a business value associated with each of said plurality of service calls using said runtime and remote data” (a person can mentally calculate a business value by simply evaluating runtime and remote data, and making a judgement of a particular business value to associate (MPEP 2106.04(a))).
ii. “generating a business flow dependency graph based on said calculated business value” (a person can mentally generate a business flow dependency graph by simply evaluating the business value, and making a judgement of a particular flow (MPEP 2106.04(a))).
iii. “generating a service call prediction path for each of said plurality of service calls based on said business flow dependency graph” (a person can mentally generate a service call prediction path by simply evaluating business flow dependency graph, and making a judgement of a service call prediction path (MPEP 2106.04(a))).
iv. “using said service call prediction path and said calculated business value, provisioning and routing a plurality of resources for each of said plurality of service calls” (a person can mentally route and provision resources by simply a service call prediction path and business value, and making a judgement of a routing and provisioning that should be performed (MPEP 2106.04(a))).
If claim limitations, under their broadest reasonable interpretation, covers performance of the limitations as a mental process but for the recitation of generic computer components, then it falls within the mental process grouping of abstract ideas. Accordingly, the claim “recites” an abstract idea.
In step 2A, prong 2 of the 101 analysis set forth in MPEP 2106, the examiner has determined that the following additional elements do not integrate this judicial exception into a practical application:
v. “A method for optimizing just in time routing of resources in a distributed cloud-based environment” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
vi. “obtaining runtime data and remote data associated with resource needs of said plurality of service calls to be performed” (insignificant extra-solution activity of mere data storage (MPEP 2106.05(g))).
vii. “wherein said business value has a calculated tangible and an intangible element” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
Since the claim does not contain any other additional elements that are indicative of integration into a practical application, the claim is “directed” to an abstract idea.
In step 2B of the 101 analysis set forth in the 2019 PEG, the examiner has determined through reanalysis of the following limitations considered in step 2A prong 2, that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
v. “A method for optimizing just in time routing of resources in a distributed cloud-based environment” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
vi. “obtaining runtime data and remote data associated with resource needs of said plurality of service calls to be performed” (well-understood, routine, and conventional activity of receiving data over a network, (MPEP 2106.05(d)(II))).
vii. “wherein said business value has a calculated tangible and an intangible element” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))).
Considering the additional elements individually and in combination, and the claim as a whole, the additional elements do not provide significantly more than the abstract idea. Therefore, the claim is not patent eligible.
Regarding claim 2, the additional element “a plurality of microservices is used for routing and provisioning of said plurality of resources for each of said plurality of service calls” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 3, the additional element “attaching said business value to said business flow dependency graph” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally attach values to a graph by simply making a judgement that values should be associated with different portions of a graph (MPEP 2106)).
Regarding claim 4, the additional element “said business dependency path is a distributed trace span” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 5, the additional element “an application resource manager is used to route and provision said plurality of resources” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 6, the additional element “said service call has a plurality of associated resources and applications used to calculate the business value” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 7, the additional element “predicting routing of a plurality of sub calls associated with said resources, wherein said prediction is made based on a distributed tracing dependency diagram, code associated with said microservices and inflight runtime data” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally make routing predictions by simply evaluating a dependency diagram, code, and runtime data, and making a judgement of a predicted routing (MPEP 2106)).
Regarding claim 8, the additional element “said distributed tracing dependency diagram is generated from historical trace data obtained” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 8, the additional element “said distributed tracing dependency diagram is generated from historical trace data obtained” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 9, the additional element “historical distributed trace dependency data is obtained to generate said service call prediction path” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data gathering (MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of receiving data over a network, (MPEP 2106.05(d)(II)).
Regarding claim 10, the additional element “obtaining runtime data and remote data includes retrieving runtime service level agreement (SLA) values and service level indicator (SLI) data” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data gathering (MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of receiving data over a network, (MPEP 2106.05(d)(II)).
Regarding claim 11, the additional element “said SLA and SLI data is used to determine a tangible business value component for said service call received” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 12, the additional element “runtime data, said tangible business value and said intangible business value and a generated service component business value are combined into a single business value” does not render the claim patent eligible because under step 2A prong 2, it does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally generate a single business value by simply the different values, and making a judgement of a combined value (MPEP 2106)).
Regarding claim 13, the additional element “at least one customer profile file is used to determine said intangible business value for each service call” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 14, the additional element “the business value of a plurality of service components are also determined for each service call request” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claims 15-20, they comprise limitations similar to claims 1, 2, 4, 10, 13, and 1 respectively. They are therefore rejected for similar rationale.
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-6, and 9-20 are rejected under 35 U.S.C. 103 as being unpatentable over POLINATI et al. Pub. No.: US 2013/0064110 A1 (hereafter POLINATI), in view of GUPTA et al. Pub. No.: US 2020/0192994 A1 (hereafter GUPTA).
Regarding claim 1, POLINATI teaches the invention substantially as claimed, including:
A method for optimizing just in time routing of resources in a distributed cloud-based environment, the method comprising:
obtaining runtime data and remote data associated with resource needs of said plurality of service calls to be performed ([0041] Measure 612 a service quality metric 118 of the activity 402 provided along the segment 406 (i.e., metrics related to service quality represent “runtime data”));
calculating a business value associated with each of said plurality of service calls using said runtime and remote data, wherein said business value has a calculated tangible and an intangible element ([0041] The instructions are al configured to identify 614 the service quality (i.e., service quality at least partially represents a “business value” as described below in the valuation algorithm of [0062]) of the activity 402 of the service 104 according to the service quality metrics 108 of the segments 406 of the service path 404 of the activity 402. [0024] It may be desirable for an administrator of the service to monitor the quality of the service (QoS), and particularly to devise metrics of the service quality of the service. This monitoring of particular metrics may provide a quantitative model of the quality of the service (i.e., quantitative models represent numerical, or “tangible” measures of quality, including download transmission rate as discussed in [0025]), and an objective metric of a determinant of the service quality may be adjusted in order to adjust the quality of the service. Additionally, inferences of customer response to adjustments in the metrics may be utilized in business cases (i.e., customer inferences represent “intangible elements” because they are not necessarily tied to numerical measures of quality, and are rather representative of overall user perception, as described in [0026]));
generating a business flow…based on said calculated business value ([0041] Identify 608 a service path 404 of the activity 402 from the source to the user 106, and identify 610 at least two segments 406 in the service path 404. [0061] The effects of service quality exhibited by respective segment may enable the identification of dependencies within the segments 406 of the service 104 (i.e., a service path of dependent segments represents a “dependency flow” that is identified based at least partially on the service quality, or “business value”));
generating a service call prediction path for each of said plurality of service calls based on said business flow ([0062] The embodiment may utilize a valuation algorithm to predict the magnitude of the improvement in the service quality metrics 118 of the segment 406 that is achievable by allocating greater resources and the cost of the deployed resources, and hence the marginal or comparative value proposition in allocating a first allocation of resources to this segment 406 as compared with a second allocation of resource to this segment 406 or another segment 406 (i.e., predicted value propositions generated for different segments represent “prediction paths” that are at least partially based on the identified service paths))…and
using said service call prediction path and said calculated business value, provisioning and routing a plurality of resources for each of said plurality of service calls ([0062] The embodiment may utilize a valuation algorithm to predict the magnitude of the improvement in the service quality metrics 118 of the segment 406 that is achievable by allocating greater resources and the cost of the deployed resources…and may choose the allocation of resources (i.e., “provisioning and routing resources”) across the segments 406 predicted to achieve the highest overall improvement in the service quality of the service 104).
While POLINATI discusses generating and executing a flow of instructions, POLINATI does not explicitly teach:
generating a business flow dependency graph
However, in analogous art that similarly executes a flow of instructions, GPUTA teaches:
generating a business flow dependency graph ([0027] Dependency graph generator 102 is configured to generate a dependency graph 114 based on execution trace 106, microarchitecture definition 108, microarchitectural event costs 110, and/or structural hazard policies 112 (i.e., costs associated with the instruction flow modeled by the dependency graph are “business” values and therefore the dependency graph is of a “business flow”)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined GUPTA’s teaching of generating a dependency graph of an instruction flow, with POLINATI’s teaching of generating a business flow, to realize, with a reasonable expectation of success, a system that generates a business flow, as in POLINATI, which is illustrated as a dependency graph, as in GUPTA. A person having ordinary skill would have been motivated to make this combination to more effectively model a system enabling users to more easily identify system bottlenecks and limitations (GUPTA [0001]).
Regarding claim 2, POLINATI further teaches:
a plurality of microservices is used for routing and provisioning of said plurality of resources for each of said plurality of service calls ([0041] The exemplary method 600 may be implemented, e.g., as a set of instructions (i.e., software components, or “microservices”) stored in a memory component of a device (e.g., a memory circuit, a platter of a hard disk drive, a solid-state memory component, or a magnetic or optical disc) that, when executed by a processor of a device, cause the device to perform the techniques presented herein. The exemplary method 600 begins at 602 and involves executing 604 the instructions on the processor).
Regarding claim 3, GUPTA further teaches:
attaching said business value to said business flow dependency graph ([0048] To associate a cost (i.e., “business value”) with an edge, dependency graph generator 102 may generate an identifier next to the edge that identifies the cost. In another example, dependency graph generator 102 may place the identifier such that it overlaps with the edge. In yet another example, dependency graph generator 102 may not display the identifier until a user selects a particular edge via the GUI (i.e., the cost remains hidden until a user selects the edge). Upon selecting a edge, the associated cost may be displayed in accordance with any of the examples described above. It is noted that while the embodiments described herein describe that a cost is associated with an edge, costs may also be associated with vertices in addition or in lieu of edges).
Regarding claim 4, GUPTA further teaches:
said business dependency path is a distributed trace span ([0008] FIG. 2B depicts an example dependency graph that is generated based on the sequence of instructions shown in FIG. 2A. [0022] The dependency graph may be generated based on an execution trace of a program and a microarchitecture definition that specifies various features and/or characteristics of the microarchitecture on which the execution trace is based (i.e., the tree structure illustrated in FIG. 2B that is generated based on execution traces represents a “distributed trace span”)).
Regarding claim 5, POLINATI further teaches:
an application resource manager is used to route and provision said plurality of resources ([0068] FIG. 11 presents an illustration of an exemplary computing environment within a computing device 1102 wherein the techniques presented herein may be implemented (i.e., computing device 1102 performs the allocation of resources discussed above and is therefore considered to at least partially represent an “application resource manager”)).
Regarding claim 6, POLINATI further teaches:
said service call has a plurality of associated resources and applications used to calculate the business value ([0062] The embodiment may utilize a valuation algorithm to predict the magnitude of the improvement in the service quality metrics 118 of the segment 406 that is achievable by allocating greater resources and the cost of the deployed resources (i.e., service quality, representing “business value”, is calculated based on amount and pricing of associated “resources”). [0025] An administrator of the service 104 may choose this metric due to a predictable impact on service quality for the service 104; e.g., the user satisfaction of a streaming media service is often determined by sustainable quality of the streamed media, which is determined by the download rate. For example, the server 102 may measure the outbound transmission rate achieved to respective users 106, and/or may configure a software client provided to each user 106 to detect the inbound transmission rate and report it to the server 102 (i.e., software clients, representing “applications” are used to calculate service quality based in one embodiment on detected transmission rate)).
Regarding claim 9, POLINATI further teaches:
historical distributed trace dependency data is obtained to generate said service call prediction path ([0062] Upon measuring a first service quality metric 118 of a segment 406, an embodiment may be configured to store the first service quality metric 118 as a historical segment quality metric of the segment 406; and upon measuring a second service quality metric 118 of the segment 406 at a subsequent time, the embodiment may compare the second service quality metric 118 of the segment 406 with historical service quality metrics 118 of the segment 118 to identify a segment quality change in the segment quality metrics 118 of the segment 406. This identification may be used, e.g., as an indicator of trends that may lead to changes in the service quality of the service 104 (i.e., historical service quality metrics, representing “trace dependency data” is used at least in part to determine a trend in service quality)).
Regarding claim 10, POLINATI further teaches:
obtaining runtime data and remote data includes retrieving runtime service level agreement (SLA) values and service level indicator (SLI) data ([0064] For respective segments 406, a service quality metric (i.e., “service level indicator”) may be detected 118, and may be compared with a service quality metric threshold 902 assigned to the segment 406 (e.g., a minimally acceptable service quality metric 118 for the segment 406) (i.e., minimum service quality metric represents a service level agreement)).
Regarding claim 11, POLINATI further teaches:
said SLA and SLI data is used to determine a tangible business value component for said service call received ([0024] It may be desirable for an administrator of the service to monitor the quality of the service (QoS), and particularly to devise metrics of the service quality of the service. This monitoring of particular metrics (i.e., monitored metrics, representing SLIs, are compared with minimum service quality metrics, representing SLAs) may provide a quantitative model of the quality of the service (i.e., quantitative models represent numerical, or “tangible” measures of quality, including download transmission rate as discussed in [0025]), and an objective metric of a determinant of the service quality may be adjusted in order to adjust the quality of the service).
Regarding claim 12, POLINATI further teaches:
runtime data, said tangible business value and said intangible business value and a generated service component business value are combined into a single business value ([0064] For respective segments 406, a service quality metric may be detected 118, and may be compared with a service quality metric threshold 902 assigned to the segment 406 (e.g., a minimally acceptable service quality metric 118 for the segment 406) (i.e., a single value (happy face, sad face, or mediocre face) is used to illustrate the business value representing both the quantitative model and customer inferences)).
Regarding claim 13, POLINATI further teaches:
at least one customer profile file is used to determine said intangible business value for each service call ([0032] Presented herein are techniques for detecting the service quality of a service 104 according to a different set of service quality metrics 118. In accordance with these techniques, a service 104 may be identified as a set of activities that are performable by a user 106 of the service 104. As a first example, a voice-over-IP service may comprise a collection of such activities as registering a VoIP account (i.e., a VOIP account associated with the user inferences representing “intangible business value” represents a “customer profile”)).
Regarding claim 14, POLINATI further teaches:
the business value of a plurality of service components are also determined for each service call request ([0022] Many scenarios involve an evaluation of the quality of a service provided to a set of users. Such service may include, e.g., realtime communication services, such as text, audio, and video, involving one or more participants (possibly including non-participating recipients), using protocol such as Internet Relay Chat (IRC), instant messaging, Simple Messaging Service (SMS), or Voice-over-IP (VoIP) services; email delivery services; streaming media services, such as music and video streaming services; file transfer services; and websites provided by webserver (i.e., each of the plural services comprises plural segments, representing “service components” which are evaluated for quality of service)).
Regarding claims 15-20, they comprise limitations similar to 1, 2, 4, 10, 13, and 1 respectively. They are therefore rejected for similar rationale.
Claims 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over POLINATI in view of GUPTA as applied to claim 2 above, and in further view of XU et al. Pub. No.: US 2023/0370337 A1 (hereafter XU).
Regarding claim 7, while POLINATI and GPUTA discuss generating flow dependency graphs illustrating business functions, they do not explicitly teach:
predicting routing of a plurality of sub calls associated with said resources, wherein said prediction is made based on a distributed tracing dependency diagram, code associated with said microservices and inflight runtime data.
However, in analogous art that similarly generates flow dependency graphs illustrating business functions, XU teaches,
predicting routing of a plurality of sub calls associated with said resources, wherein said prediction is made based on a distributed tracing dependency diagram, code associated with said microservices and inflight runtime data ([0001] Nested API calls (i.e., “sub calls”) are tree-like, semi-structured data that is not easily stored in a relational database…it is difficult to leverage the performance trace logs to predict future API traffic (which would help with cloud resources planning and balancing). If a cloud provider could predict trends in cloud usage, it can add or remove resources such as servers, virtual machines, database storage, etc. to better match actual future usage. [0032] At S210, a computer processor of a traffic prediction server may retrieve performance stack trace logs from a traffic performance stack trace log repository that stores traffic information of the cloud computing environment. At S220, the system may parse the performance stack trace logs as an objects list (including parent/child (i.e., “dependency”) object relationships) which are then stored in a graph database at S230 (i.e., stack trace logs stored in a graph, or “diagram”, represent “distributed tracing dependency diagram”). At S240, information in the graph database is transformed into training data (including spatial and temporal information). At S250, the transformed training data used to train a transformer model. Previous traffic input data associated with the cloud computing environment can then be provided to the transformer model, and the transformer model can generate predicted traffic output data (e.g., future traffic) based on the previous traffic input data. [0033] The training data 340…includes graph spatial information (e.g., an adjacency matrix) and the temporal information (which includes each edge's invoke times sum during a specific time period) (i.e., the number of times a call is invoked during execution represents “inflight runtime data” which is associated with the code of the invoked API call, representing “code associated with said microservice”)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined XU’s teaching of predicting future API call traffic to allocate resources, with the combination of POLINATI and GUPTA’s teaching of allocating resources based on business value metrics, to realize, with a reasonable expectation of success, a system that allocates resources based on business value metrics, as in POLINATI and GUPTA, which involves predicting future API call traffic, as in XU. A person of ordinary skill would have been motivated to make this combination to better match actual future usage to better allocate resources (XU [0001]).
Regarding claim 8, POLINATI further teaches:
said distributed tracing dependency diagram is generated from historical trace data obtained ([0062] Upon measuring a first service quality metric 118 of a segment 406, an embodiment may be configured to store the first service quality metric 118 as a historical segment quality metric of the segment 406; and upon measuring a second service quality metric 118 of the segment 406 at a subsequent time, the embodiment may compare the second service quality metric 118 of the segment 406 with historical service quality metrics 118 of the segment 118 to identify a segment quality change in the segment quality metrics 118 of the segment 406. This identification may be used, e.g., as an indicator of trends that may lead to changes in the service quality of the service 104).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195