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 .
1. This communication is in response to amendments filed on 04/13/2026.
Claims 1, 2, 11, 16, 17, and 22 have been amended, and claims 18-20 were previously cancelled. Claims 16, 17 and 21 are withdrawn from consideration, and claims 1-15, 21 and 22 remain rejected.
Election/Restrictions
2. In response to the previously raised restriction requirement, Applicant has affirmed election, without traverse and without prejudice, of Group I (claims 1-15, 22, and 23). Claim 16 of Group II and claims 17 and 21 of Group III are hereby withdrawn from consideration.
Claim Rejections - 35 USC § 112
3. Applicant’s amendment to claim 11 in response the previously raised rejection under 35 U.S.C. 112(b) has been considered and obviates previously objection, as such the rejection is hereby withdrawn.
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.
4. Claims 1-6, 8-15, 22, and 23 remain rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. It was previously noted that the claimed features of obtaining information in response to a request, selecting criteria based on the obtained information, obtaining additional information and generating and performing an adaptive management strategy make up a judicial exception not integrated into a practical application because the claims lack description linking the obtaining, selecting, generating, and performing operations to a computer or improvement in computer functionality, and therefore these steps could be performed mentally by a human with access to the information and an ability to mentally design a strategy based on the information.
In response to this rejection Applicant has amended the generating limitation of claim 1 to recite, “generating, by a computation manager using Reinforcement Learning (RL), an adaptive management strategy…” and submits that RL is inherently computer-implemented and cannot to performed mentally by a human. However, it is noted that the language of the claim merely provides a computation manager which is capable of using RL, but does not specifically link the use of this RL to the claimed functionality or parameters, and therefore is not sufficient for the claims to amount to significantly more than the judicial exception.
Applicant is suggested to clarify, in the claim, that the claimed parameters used to generate the adaptive management strategy are provided as input for Reinforcement Learning performed by the computation manager, and that the RL outputs resulting generated adaptive management strategies in order to specify that use of these particular parameters for a RL model is what is intended as an improvement to the system.
The rejection is therefore maintained.
Response to Arguments
5. Applicant's arguments alleging that the applied references fail to render any of the present claims obvious have been fully considered but they are not persuasive. Applicant arguments are specifically directed to the limitations of claim 1.
Applicant first notes that claim 1, as amended, now recites “generating, by a computation manager using Reinforcement Learning (RL), an adaptive management strategy based on the one or more request criteria, the one or more user specification, the one or more application specifications, the static status of the one or more edge cloud resources, the dynamic status of the one or more edge cloud resources, and the one or more management strategies”. Applicant acknowledges that Parvataneni teaches reinforcement learning via an “RL agent”, but submits that it has not been established that the combination of references teaches a computation manager that uses RL to generate an adaptive management strategy based on all of the recited inputs now recited in amended claim 1.
In response, it is first submitted that the claim language lacks any specific details or characteristics describing the claimed computation manager in such a way that distinguishes this term from an RL agent controller in Parvataneni, which provides machine learning-based resource management to generate adaptive new rules for system management, within the scope of an adaptive management strategy. As noted by Applicant, Parvataneni, similarly to the claimed invention, performs this reinforcement learning for adaptive system management using various types of collected information, including a requested application service, end device information, application service policies, network resource information, and historical information. The previous Office Action recognizes that Parvataneni does not explicitly disclose both a static status of one or more edge cloud resources and a dynamic status of one or more edge cloud resources included in this collected information, however the Sun reference which also uses collected data to determine an optimized policy expressly states utilizing both static resource data and real-time dynamic resource data. It is submitted that the specific information which is collected and analyzed for adaptive management is an obvious variation to the system, and that the combination of these references sufficiently teaches this limitation, particularly given that both references utilize this collected information for determining optimized system management.
Further, Applicant asserts that the mapping of the “selecting” step is improper because the cited portion of Parvataneni describes the RL device selecting a host, and that selecting a hardware resource is fundamentally different from selecting a criterion to prioritize (e.g., latency vs cost vs total resource utilization) based on user and application specifications. It is noted that the rejection is in view of the entirety of the Parvataneni reference and additional portions provide contextual evidence for the correlation between the teachings of Parvataneni and the selecting of one of the one or more request criteria recited in the claims. Specifically, the RL device selecting a controller in Parvataneni refers to a RL device of an orchestrator providing a selected auto-scale rule to a RL agent of the selected controller in response to receiving a trigger event, such as a request from an end device. Paragraph [0051] describes that this selected auto-scale rule is obtained from the policy engine for a specific application service or category of application service, and paragraph [0011] discloses that these auto-scaling rules for managing network resources associated with the application services may include threshold and/or parametric values that change over time based on collected information. Paragraph [0034] teaches that RL models providing the scaling rules are selected to yield the most efficient use of resources given a current state pertaining to the network and end device, and paragraph [0042] specifies that a desired state may include an optimized state that has financial and/or performance benefits. The claim language of claim 1 is silent regarding specific characteristics or details of the claimed criteria, and it is therefore submitted that these auto-scaling rules selected by the RL device and provided to the selected RL agent to use for reinforcement learning computations are within the scope of the broadest reasonable interpretation of the claimed selecting criteria limitation.
Applicant’s remarks assert that the specification of the claimed invention describes considering the user and application specifications to analyze a best criterion to prioritize, such as latency vs cost, and that this identified best criterion is provided to the computation manager to utilize as input for the RL when generating a computation management strategy, however this description in Applicant’s remarks is narrower than the current claim language. Applicant is urged to include language supported by the specification which specifies these features in the claim language in order to distinguish from the applied prior art.
Lastly, Applicant argues that the applied references do not teach a multi-stage process where a dynamically selected criterion is communicated to the computation manager, and that it is then the selected criterion which directly shapes the RL-based generated computation management strategy. It is again noted that what is argued is not reflected in the claim language. Specifically, the claim limitation directed to generating recites that the adaptive management strategy is based on “the one or more request criteria”, not the selected one of the one or more request criteria, as alleged by Applicant. Applicant noted portions of the specification of the claimed invention which recite that the identified/selected criteria may be adjusted or weighted differently by the computation manager depending on the static and/or dynamic factors or the application/user specifications, and that a list of strategies is generated which satisfy the identified/selected criteria. If this is what is intended in the claims, Applicant is urged to include claim language describing how a selected criteria is weighted for prioritization and how it is factored into the generating of an adaptive management strategy.
Based on the above rationale, it is submitted that the prior art is within the scope of the broadest reasonable interpretation of the current claim language, and the rejection is therefore maintained.
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.
6. Claims 1-12, 14, 15, 22, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Parvataneni et al. (US 2021/0211352) in view of Sun et al. (US 2022/0006857) and in further view of Shaw et al. (US 2018/0316799).
Regarding claim 1, Parvataneni teaches a method performed by a computation management system for performing edge cloud computation management (Auto-scaling techniques may be used to manage resource allocation of the application-layer service network, such as a MEC network, [0010]), the method comprising:
receiving a computation management request from a UE (user equipment) (the triggering event may be a request from end device 180 for an application service, [0051]);
obtaining one or more request criteria associated with the computation management request (The request may include data indicating an application service or a category of an application service, [0051]);
obtaining one or more user specifications (end device information may include information relating to resource utilization for physical, virtual, and/or logical resources at end device 180. Additionally, end device information may also include information relating to end device performance, such as latency, packet drop rate, etc., and/or other types of KPIs, QoS, SLA parameters, and so forth);
obtaining one or more application specifications from previously stored application specifications (Policy engine 210 may store default auto-scaling rules for application services. For example, default auto-scaling rules may relate to a category of application services (e.g., mission critical, real-time, non-real-time, video streaming, IoT, etc.) and/or on a per-application service basis, [0033]; RL device 215 may obtain a default auto-scale rule for the application service 310 from the policy engine (PE) 210, [0051]);
selecting one of the one or more request criteria based on the one or more request criteria, the one or more user specifications, and the one or more application specifications (In response to receiving the default auto-scaling rule, RL device 215 may select a controller 220 and/or a host(s) 250 to provide the requested application service. RL device 215 may provide the default auto-scale rule 315 to RL agent 225 of the selected controller 220, [0052]; parametric values included in the auto-scaling rules may change over time based on the analysis of collected information, [0011]; RL models 275 may provide auto-scaling rules for application services or categories of application services that yield the most efficient use of resources given a current state pertaining to MEC network 125 and end device 180, [0034]);
obtaining status for one or more edge cloud resources (Network information may include information relating to resource utilization for physical, virtual, and/or logical resources at controller 220, host 250, and communication links, [0038]; RL agent 225 may obtain the network information from a monitoring and tracking system (e.g., a monitoring system 305 in FIG. 3) in MEC network 125 and/or other configured source, [0038]);
obtaining one or more management strategies (the machine learning-based resource management service may use various types of information (e.g., historical and current information pertaining to collected information, auto-scaling rules, etc.) that provides a more extensive evaluation and analysis of auto-scaling rules, [0012]);
generating, by a computation manager using Reinforcement Learning (RL) (RL agent 225 includes logic that provides the machine learning-based resource management service. According to an exemplary embodiment, RL agent 225 includes logic that uses various types of collected information as a basis to determine whether an auto-scaling rule should be modified, [0038]), an adaptive management strategy based on the one or more request criteria, the one or more user specifications, the one or more application specifications, the static of the one or more edge cloud resources, and the one or more management strategies (Based on the analysis of the collected information and an auto-scaling rule (in use), such as a default auto-scaling rule or a modified auto-scaling rule, RL agent 225 may determine whether to maintain the current auto-scaling rule or modify the current auto-scaling rule. For example, RL agent 225 may use a machine learning algorithm (e.g., a quality learning (q-learning) algorithm) that seeks to find the best action to take given the current state indicated by the collected information, [0040]); and
performing the generated adaptive management strategy to complete the computation management request (RL agent 225 may communicate with resource manager 230 to apply the modified auto-scaling rule, [0044]; based on a modified auto-scale rule (relative to a default auto-scale rule), resource manager 230 may allocate resources to an application service and associated host(s) 250 based on the modified auto-scale rule, [0047]; controller 220 may use the modified auto-scaling rule so to provision the application service. For example, resource manager 230 may adjust the allocation of resources to host 250, such as vertical or horizontal auto-scaling, in accordance with the modified auto-scaling rule, [0075]).
However, Parvataneni does not explicitly disclose both a static status and a dynamic status for the one or more edge cloud resources, or that the one or more management strategies and related success rates are obtained from a database.
Sun teaches obtaining static status and dynamic status for one or more edge cloud resources (Each of the factors described above may be determined based on stored information related to the candidate subset of MEC servers 306 (e.g., information indicative of the MEC server locations, processing capabilities, etc.) and/or based on real-time testing that is performed in accordance with communications and operations, [0053]; system 100 may combine static data that has been accessed from a data store (e.g., data indicative of locations of MEC servers 306, theoretical capabilities of MEC servers 306, etc.) with real-time, dynamic test result data reported by client devices 302 (e.g., data indicative of how each MEC server 306 may be expected to perform with respect to the actual client devices 302 at their current locations and under current conditions), [0058]);
obtaining one or more management strategies and related success rates from a database (analyzing at least one of the one or more factors described above using machine learning technology trained based on previous such identifications that have been made in the past and an indication of how optimal or successful such identifications turned out to be, [0053]; data representative of one or more executable applications 1012 configured to direct processor 1004 to perform any of the operations described herein may be stored within storage device 1006. In some examples, data may be arranged in one or more databases residing within storage device 1006, [0080]); and
generating an adaptive management strategy based on the static status of the one or more edge cloud resources, and the dynamic status of the one or more edge cloud resources (Based on all this data and any other suitable data that system 100 may access or receive in a particular implementation, system 100 may perform operation 504-3, in which a particular MEC server 306 is selected from the candidate subset of MEC servers 306 to be the one that will execute the multi-client application. Along with ensuring that all of the relevant operation parameters requested for the multi-client application can be satisfied by the selected MEC server 306, operation 504-3 may be configured to select a MEC server in accordance with a particular optimization policy, [0059]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to consider both static and dynamic resource conditions and utilize information about past successes in the system/method of Parvataneni as suggested by Sun when analyzing information to determine an optimal policy. One would be motivated to combine these teachings to combine a variety of static resource characteristics, such as location, with real-time conditions and to compare results with past successes in order to identify most appropriate resources to fulfill a particular request.
However, Parvataneni-Sun do not explicitly disclose that the one or more user specifications are previously stored.
Shaw teaches obtaining one or more user specification from previously stored user specifications (the Manager SDN Controller 130 can access User Profiles 132 of subscriber devices 116 to determine which users have histories of using which service applications, [0037]; the User Profile 132 can be stored at a cloud-based location, [0037]; Core SDN Controller 140 can fetch and look up a profile of one or more users of the communication device 116. The profile can include information on how the user and/or a subscriber to system services desires to manage data resources, [0082]); and
selecting one of one or more request criteria based on the one or more user specifications (access user profile/preference information for these devices to reveal performance needs so that QoS parameters can be defined at the device level. The SDN Controller can analyze QoS parameters over all the domains of the network to determine an aggregated set of QoS parameters needed to provide services within quality limits of the network for its totality of customers, [0110]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to store a user profile in the system/method of Parvataneni-Sun as suggested by Shaw to provide access to user preferences and performance needs. One would be motivated to combine these teachings to ensure that requirements of individual subscribers are met in order to provide each subscriber with a desired quality of service.
Regarding claim 2, Parvataneni teaches the method of claim 1 wherein the UE comprises one of: mobile device, smart car, smart watch, Virtual Reality (VR) glass (End device 180 may be implemented as a mobile device, a portable device, a stationary device, a device operated by a user, or a device not operated by a user. For example, end device 180 may be implemented as a Mobile Broadband device, a smartphone, a computer, a tablet, a netbook, a phablet, a wearable device, a vehicle support system, a game system, a drone, or some other type of wireless device, [0029]).
Regarding claim 3, Parvataneni teaches the method of claim 1, wherein the computation management request comprises at least one of: application, service, user, time, location, battery level, program code, application specification, user requirement (The request may include data indicating an application service or a category of an application service, [0051]).
Regarding claim 4, Parvataneni does not explicitly disclose the method of claim 1, wherein the one or more request criteria comprises at least one of: latency, cost, total resource utilization.
Sun teaches wherein one or more request criteria comprises at least one of: latency, cost, total resource utilization (one or more operation parameters obtained at operation 202 may define key performance indicators (e.g., computing resource requirements, target values, thresholds, etc.) for various aspects of the performance of the multi-client application, [0027]; Certain operational parameters obtained by system 100 at operation 202 may also relate to tolerable latencies of the multi-client application (e.g., a round-trip latency parameter or one-way latency parameter for the multi-client application that define maximum acceptable latencies that each client device may experience, [0028]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to obtain operational parameters associated with a requested service/application in the system/method of Parvataneni as suggested by Sun in order to consider specific needs and functionalities of different services/applications. One would be motivated to combine these teachings because factoring in characteristics of how each service/application operates when determining an optimal resource configuration would allow for prioritizing certain requirements to provide the best performance for a user requesting the service/application.
Regarding claim 5, Parvataneni teaches the method of claim 1, wherein the static status or dynamic status of the one or more edge cloud resources comprises at least one of: availability, utilization rate, maximum allowed capacity, node location, running load, failure rate, energy consumption level (the MEC network may have insufficient resources (e.g., physical, logical, virtual) due to the number of end devices/users being served, the number of applications running simultaneously, [0009]; Network information may include information relating to resource utilization for physical, virtual, and/or logical resources at controller 220, host 250, and communication links. Network information may also include information relating to network performance, such as response rates for user requests, latency, packet drop rate, throughput, jitter, and/or other types of key performance indicators (KPIs), quality of service (QoS), service level agreement (SLA) parameters, and so forth. The network information may further include other types of information relating to health, security, usage of application service (e.g., the degree at which some features of an application service are used relative to other features, etc.), fault detection, and/or resource utilization, [0038]).
Regarding claim 6, Parvataneni teaches the method of claim 1, wherein the one or more edge cloud resources comprise local resources, remote resources, or both local and remote resources (Network information may include information relating to resource utilization for physical, virtual, and/or logical resources at controller 220, host 250, and communication links, [0038]; resource utilization and performance information relating to other networks (e.g., access network 105, access devices 110, external network 160, external devices 165, etc.) and communication links external to MEC network 125 that pertain to the provisioning of an application service, [0038]).
Regarding claim 7, Parvataneni teaches the method of claim 1, further comprising assessing a result of the generated adaptive management strategy (RL agent 225 may analyze the collected information relative to the modified auto-scaling rule to determine whether further adjustment is needed or the modified auto-scaling rule has been successful 355, [0055]) and storing the result in the database (Based on this determination, RL agent 225 may provide the modified auto-scale rule 360 to RL device 215. RL device 215 may store and share the modified auto-scaling rule with other controllers 220, [0055]).
Regarding claim 8, Parvataneni does not explicitly disclose the method of claim 1, further comprising sending a result of the generated adaptive management strategy to the UE.
Sun teaches sending a result of a generated adaptive management strategy to a UE (at communication 502-5, system 100 may direct the performance testing by indicating which MEC servers 306 have been identified for the candidate subset of MEC servers, providing address information associated with each respective daemon process executing on each of the identified MEC servers, providing protocol information indicating a supported transport protocol that is to be utilized by client devices 302 to communicate with the respective daemon processes to enable testing of the performance capabilities, and so forth, [0056]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to indicate a selected server or resource to a requesting client in the system/method of Parvataneni as suggested by Sun in order for the client to acknowledge and approve the selection. One would be motivated to combine these teachings to enable client feedback for a determined resource configuration.
Regarding claim 9, Parvataneni teaches the method of claim 1, wherein the one or more user specifications or the one or more application specifications comprises at least one of: application, service, user, time, location, battery level, program code, application specification, user requirement (Policy engine 210 may store default auto-scaling rules for application services. For example, default auto-scaling rules may relate to a category of application services (e.g., mission critical, real-time, non-real-time, video streaming, IoT, etc.) and/or on a per-application service basis, [0033]).
Regarding claim 10, Parvataneni teaches the method of claim 1, further comprising updating the static and/or dynamic status for the one or more edge cloud resources (Auto-scaling mechanisms may dynamically adjust network resources to support an application service based on auto-scaling rules, [0010]; MEC device 130 may transmit the adjusted auto-scaling rules to a resource manager that governs allocated resources to virtual network devices, such as hosts, containers, VMs, or other types of network devices that provide an application service to end devices 180, [0024]; Resource manager 230 may modify the amount of resources allocated based on communication with RL agent 225, as described herein, [0047]).
Regarding claim 11, although Parvataneni teaches using historical information [0012], Parvataneni does not explicitly disclose the method of claim 1, wherein success rate for the one or more management strategies is calculated based on at least one of: historical success rate, current defined importance of criteria, and the one or more user specification and the one or more application specifications.
Sun teaches wherein success rate for the one or more management strategies is calculated based on at least one of: historical success rate, current defined importance of criteria, and the one or more user specifications, and the one or more application specifications (the identifying of the candidate subset of MEC servers 306 at operation 504-1 may include analyzing at least one of the one or more factors described above using machine learning technology trained based on previous such identifications that have been made in the past and an indication of how optimal or successful such identifications turned out to be, [0053]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to consider and utilize information about past successes in the system/method of Parvataneni as suggested by Sun when analyzing information to determine an optimal policy. One would be motivated to combine these teachings to compare results with past successes and develop improved techniques for identifying most appropriate resources to fulfill a particular request.
Regarding claim 12, Parvataneni teaches the method of claim 1, wherein the generating an adaptive management strategy comprises using Reinforcement Learning (RL) (RL models 275 may provide auto-scaling rules for application services or categories of application services that yield the most efficient use of resources given a current state pertaining to MEC network 125 and end device 180, [0034]; RL agent 225 includes logic that provides the machine learning-based resource management service, [0035]).
Regarding claim 14, Parvataneni teaches the method of claim 12 wherein the Reinforcement Learning comprises at least one of: Q-learning (RL agent 225 may use a machine learning algorithm (e.g., a quality learning (q-learning) algorithm) that seeks to find the best action to take given the current state indicated by the collected information, [0040]) and SARSA (State Action Reward State Action) (RL agent 225 may use other machine learning algorithms (e.g., State-Action-Reward-State-Action (SARSA), [0041]).
Regarding claim 15, Parvataneni teaches the method of claim 12, wherein the Reinforcement Learning comprises a RL model engine configured to train a learning algorithm to obtain a Q-Database (RL agent 225 may store and manage a q-table, [0041]).
Claim 22 is directed to a first network node, comprising, a processor, and a memory having stored thereon a computer program which, when executed on the processor, causes the processor to carry out the method according to claim 1, and therefore is rejected in view of the same rationale as claim 1.
Claim 23 is directed to a non-transitory computer-readable storage medium, having stored thereon a computer program which, when executed on at least one processor, causes the at least one processor to carry out the method according to claim 1, and therefore is rejected in view of the same rationale as claim 1.
7. Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Parvataneni-Sun-Shaw in view of Yeh et al. (US 2022/0014963).
Regarding claim 13, Parvataneni-Sun-Shaw do not explicitly disclose the method of claim 12 wherein the generating an adaptive management strategy comprises using a Markov Decision Process (MDP).
Yeh teaches wherein generating an adaptive management strategy comprises using a Markov Decision Process (MDP) (the learning approach of the actor network 303 and/or the critic network 305 is a policy gradient learning approach such as, for example, a cross-entropy loss function, Monte Carlo policy gradient, finite horizon MDP, [0057]; RL for traffic management is accomplished by modeling the wireless multi-RAT network interaction as Markov decision process, [0124]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize a Markov Decision Process in the system/method of Parvataneni-Sun-Shaw as suggested by Yeh to implement reinforcement learning. One would be motivated to combine these teachings because MDP is known for adaptive modeling of a sequence of decisions in a highly dynamic edge environment.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Roden et al. US 10,534,928 – inputting user data point information into a machine-learning mode to generate resource-affinity parameters.
Carnahan et al. US 2020/0195652 – ingesting resource and user information by a machine-learning model to predict component values and reassignment value conditions for a request.
Carames et al. US 2023/0071047 – inputting a request condition, user information, and resource information, including historical data, to a machine learning model for allocating resources to a group of users.
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 MADHU WOOLCOCK whose telephone number is (571)270-3629. The examiner can normally be reached Tuesday, Thursday 9-6 ET.
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, Chris Parry can be reached at 571-272-8328. 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.
MADHU WOOLCOCK
Examiner
Art Unit 2451
/MADHU WOOLCOCK/Primary Examiner, Art Unit 2451
Prosecution Insights