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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-10, 18-21, 26 and 30 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claim(s) 1-6, 8-9, and 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over in view Bhorkar et al., US 20220136846 A1 (hereafter referred to as Bhorkar) in view of Stammers et al., USPN 11166147 B2 (hereafter referred to as Stammers).
Claim 26, Bhorkar teaches a network node operating in a communications network, the network node comprising:
an intent handler (p. 142, “The QoS handler platform 142 can obtain, from the QoS-based map applications 144/146, the QoS requirements 148, the origin location 150, and the destination location 152. In some embodiments, the QoS handler platform 142 can prompt the QoS-based map applications 144/146 to provide the QoS requirements 148, the origin location 150, and the destination location 152.”);
processing circuitry (p. 87, “a processing unit”); and memory coupled to the processing circuitry (p. 87, “The bus 812 enables bi-directional communication between the processing unit 802, the memory 804, the user interface devices 806, the I/O devices 808, and the network devices 810.”) and having instructions stored therein that are executable by the processing circuitry (p. 89, “The memory 804 includes an operating system 814 and one or more program modules 816. “ And p. 90, “The program modules 816 can include various software, program modules, and/or data described herein. For example, the program modules 816 can include the vehicle V2I application 122, the vehicle V2C application 124, the vehicle QoS-based map application 144 …”) to cause the communication device to:
determine a service level prediction, the service level prediction is associated with a predicted route of a communication device (p. 44, “The V2C platform 116 can provide, to the V2X-enabled device 102, one or more V2C services 130 via one or more V2C cloud networks 132.” And p. 86, “the V2X-enabled device 102, the user device 106, the vehicle system(s) 108, the V2C platform 116, the V2I platform 118, the V2I device(s) 136, the network edge resource(s) 138, the QoS handler platform 142, the route optimization system 154, the KPI collector 160, the network information database(s) 164, one or more components thereof” );
generate an intent based on the service level prediction, generate the intent comprises generating the intent to indicate that the communication device be prioritized as long as the communication device moves along the predicted route (p. 49, “The illustrated QoS handler platform 142 includes a route optimization system 154 that utilizes one or more route optimization models 156 to generate one or more optimized routes 158 based upon the QoS requirements 148, the origin location 150, and the destination location 152.” “For example, the optimized route 158 between the origin location 150 and the destination location 152 can be a route that is the shortest distance while … exceeding the QoS requirements 148.” And p. 68, “It is contemplated that the route optimization models 156 may be weighted in favor of or against certain QoS requirements 148 in accordance with a priority, which may be specified, for example, by the user or application that submitted the QoS requirements 148.” See also p. 8, “The route optimization system can predict, based upon a route optimization model, a QoS at each of the locations. The route optimization system can determine a least cost route of all the possible routes that satisfies the QoS requirement.” See also, p. 26, “the route optimization system can create routes to be used by vehicles and users for navigation over a wide coverage area provided by mobile wireless communication networks. Additionally, the routes can provide a guaranteed QoS such that if the vehicle strays or user from the route, the QoS can no longer be guaranteed and measures can be taken to ensure the safety of the vehicle and its occupants.” The priority is part of a QOS requirement and only guaranteed on the correspond route between starting location and ending location.); and
assign the intent to a set of intents used by the communications network (p. 50, “The route optimization system 154 can store the optimized route(s) 158 in association with the information used to create the optimized route(s) 158. This information can include QoS measurements, the KPIs 159, and/or other measurements/information. In some embodiments, the route optimization system 154 can construct a historical database (not shown) to store this information.”); and
use the set of intents to configure network resources (p. 72, “It should be understood that the least cost criterion may be least cost from … and/or from a mobile network operator (e.g., network resources usage or monetary cost associated with providing service along the route).”). Bhorkar does not specifically teach intents. However, in the same field of endeavor, Stammers teaches intents are translated in (column 4, lines 41-47; “A smart object is a digital representation of a physical or even virtual object. Often the smart object is a representation of an IoT device ... The smart object is associated with intent-based usage policies and micro-segmentation policies, which can be defined by the first domain or by third parties.” And column 4, lines 65-67 and column 5, lines 1-6; “The polices can be translated from the roaming provider into a context or language that applies to the second domain. Once translated and received by the second domain, the intents of the usage policies and micro-segmentation policies associated with the smart object are matched with what the second domain is capable of fulfilling. Finally, a workflow is created which, when executed, will allow the second domain to fulfill the policy intents.” See also column 9, lines 43-50; “This process involves taking policy intents received from home network 330; extracting the policy intents which apply to the present situation based on information about roaming device 320 and roaming network 300 (access network type, device class, device ID, location, device access type, or other factors); and translating these policy intents into policies that roaming network 300 can implement.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhorkar by incorporating policy intents from Stammer to assure compliance and enforcement of the policies without having to express the requirement in service level agreement details. The motivation would have been to simplify expressing the policies and also enable maintain the policies while roaming across networks.
Claim 1 is a method that recites steps similar to the operations of claim 26 above. Claim 1 is rejected on a similar rationale.
Claim 2, Bhorkar-Stammer teaches the method of Claim 1, wherein the service level prediction comprises a service level prediction associated with at least one of:
a communication device; a geographical area; a coverage area associated with a base station; and a route (Bhorkar, p. 73, “At operation 508, the route optimization system 154 samples multiple locations along each of the possible routes. From operation 508, the method 500 proceeds to operation 510. At operation 510, the route optimization system 154 predicts the QoS at each sample location. This predication can be based upon historical QoS at each sample location.”).
Claim 3, Bhorkar-Stammer teaches the method of Claim 1, wherein the intent comprises a conditional intent that is only valid until a condition is met (Bhorkar, p. 26, “the route optimization system can create routes to be used by vehicles and users for navigation over a wide coverage area provided by mobile wireless communication networks. Additionally, the routes can provide a guaranteed QoS such that if the vehicle strays or user from the route, the QoS can no longer be guaranteed and measures can be taken to ensure the safety of the vehicle and its occupants.”), the method further comprising:
responsive to determining that the condition is met, removing the intent from the set of intents (Bhorkar, p. 26, “For example, in the case of an autonomous vehicle, if the vehicle does not follow the route and the QoS therefore has been violated (or a QoS violation occurs for some other reason), the autonomous vehicle may not have access to certain features (e.g., a 360 degree view), and thus it might be safer to inform the occupants that manual mode should be engaged (i.e., an occupant must manually drive the vehicle).”).
Claim 4, Bhorkar-Stammer teaches the method of Claim 3, wherein the condition comprises at least one of: a
spatial condition; a temporal condition (Bhorkar, p. 27, “The QoS-based map application can receive routes created by the route optimization system and present the routes for selection by a user. The routes can be configurable. The routes can include least cost routes with respect to distance, time, or any other metric.”); and a condition that a predetermined application ends.
Claim 5, Bhorkar-Stammer teaches the method of Claim 1, wherein the service level prediction is associated with a predicted route of a communication device (Bhorkar, p. 49, “The illustrated QoS handler platform 142 includes a route optimization system 154 that utilizes one or more route optimization models 156 to generate one or more optimized routes 158 based upon the QoS requirements 148, the origin location 150, and the destination location 152.”), and
wherein generating the intent comprises generating the intent to indicate that the communication device be prioritized as long as the communication device moves along the predicted route (Bhorkar, p. 49, “For example, the optimized route 158 between the origin location 150 and the destination location 152 can be a route that is the shortest distance while … exceeding the QoS requirements 148.” And p. 68, “It is contemplated that the route optimization models 156 may be weighted in favor of or against certain QoS requirements 148 in accordance with a priority, which may be specified, for example, by the user or application that submitted the QoS requirements 148.” p. 26, “the route optimization system can create routes to be used by vehicles and users for navigation over a wide coverage area provided by mobile wireless communication networks. Additionally, the routes can provide a guaranteed QoS such that if the vehicle strays or user from the route, the QoS can no longer be guaranteed and measures can be taken to ensure the safety of the vehicle and its occupants.” The priority is part of a QOS requirement and only guaranteed on the correspond route between starting location and ending location.).
Claim 6, Bhorkar-Stammer teaches the method of Claim 1, further comprising:
identifying one or more network nodes with coverage areas associated with the predicted route of the communication device (Bhorkar, p. 42, The V2X-enabled device 102, embodied as the vehicle 104, the user device 106, or a combination of both, can communicate with the V2C platform 116 and the V2I platform 118 via one or more networks 120. The network(s) 120 can be or can include one or more wireless wide area networks (“WWANs”) operated by one or more mobile network operators. “), wherein the set of intents are associated with the one or more network nodes (p. 47, “Although the QoS requirements 148 have been described specifically for data services, the QoS requirements 148 can include requirements specific to voice services, including IP-based voice services. The QoS requirements 148 can include requirements specific to mobile compute intensive applications. A function of different QoS requirements and KPIs (or other performance-related data) can also be computed as the ultimate QoS requirement.”).
Claim 8, Bhorkar-Stammer teaches the method of Claim 1, further comprising: determining that the service level prediction will not be met (Bhorkar, p. 57, “The route optimization system 154 may, in some instances, encounter a situation in which at least a portion of at least one of the routes 206A-206C does not satisfy the QoS requirements 148. In these instances, the route optimization system 154 can inform the user, via the QoS-based map application 144/146, where along the routes 206A-206C the QoS requirements 148 are not satisfied.”); and
responsive to determining that the service level prediction will not be met, transmitting a message to a device associated with the service level prediction indicating that the service level prediction will not be met (p. 57, “From time to time, after a route has been selected, the selected route may be compromised due to weather, network failure, or some other circumstance, and as a result, the QoS requirements 148 cannot be satisfied. In these instances, the QoS-based map application 144/146 can inform the user of the portion(s) of the selected route where the QoS requirements 148 are not satisfied.”).
Claim 9, Bhorkar-Stammer teaches the method of Claim 1, wherein the service level prediction comprises at least one of: an assured bandwidth (Bhorkar, p. 26, “Additionally, the routes can provide a guaranteed QoS”. And p. 47, “The QoS-based map applications 144/146 can obtain one or more QoS requirements 148 (e.g., minimum download and/or upload speed, maximum latency”); an assured latency (p. 47, “The QoS-based map applications 144/146 can obtain one or more QoS requirements 148 (e.g., minimum download and/or upload speed, maximum latency”); an assured packet loss rate; and an assured basic service availability.
Claim(s) 7 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhorkar and Stammer as applied to claim 1 above, and further in view of Nimbavikar et al., US 20200068446 A1 (hereafter referred to as Nimbavikar).
Claim 7, Bhorkar-Stammer teaches the method of Claim 1, as cited above. Bhorkar-Stammer teaches wherein the service level prediction is associated with a first communication device of a plurality of communication devices that are each assigned a service category; wherein the first communication device is assigned to a first service category; and wherein the intent comprises a soft intent that indicates that the communication device have a higher priority than other communication devices in the first service category and a lower priority than communication devices in a second service category. However, Nimbavikar teaches wherein the first communication device is assigned to a first service category (p. 9, "selecting a QoS can be based at least in part on the user profile information (e.g., indicating a priority level associated with a user and/or device), a communication type (e.g., voice, text, video, data, etc.), a state of the network (e.g., congestion, delay, etc.), and the like." Interpreting communication type as service category.); and
wherein the intent comprises a soft intent that indicates that the communication device have a higher priority than other communication devices in the first service category and a lower priority than communication devices in a second service category (p. 41, "if the UE 202 is a highest priority level subscriber device performing video streaming and the UE 204 is a medium priority level making a voice call, the UEs 202 and 204 may receive the same QoS (e.g., when no congestion is present). In a case where congestion is detected (or any other appropriate consideration for QoS), the UE 202 may maintain the same QoS or may be downgraded before a QoS associated with the UE 204 is downgraded."). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhorkar-Stammer to incorporate from service categories and priorities from Nimbavikar to improve effectiveness for adjusting network intents and thereby providing
Claim 10, Bhorkar-Stammer teaches the method of Claim 1, wherein the service level prediction comprises the assured bandwidth, the method further comprising: determining an assured bandwidth value based on the service level prediction. Bhorkar-Stammer does not specifically teach notifying a Policy Control Function, PCF, in the communications network of the assured bandwidth value. However, in the same field of endeavor, Nimbavikar teaches notifying a Policy Control Function, PCF, in the communications network of the assured bandwidth value (p. 23, "the PCF 110 can be implemented as a network function including functionality to support unified policy framework to govern network behavior, provide policy rules to control plane functions and/or enforce such rules..." And p. 28, "the UE 102 can send a resource request to the base station 104 associated with RAN 106. In some instances, the resource request can include identity information 122 stored on the UE 102. The RAN 106 can send a request, based at least in part on the identity information 122, to the PCF 110." See also p. 49, "QoS enforcement component 310" will enforce the guarantees.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhorkar-Stammer by incorporating PCF enforcement for the intention levels by Nimbavikar to improve effectiveness. The motivation would have been to provide seamless guaranteed resources for services along the predicted route.
Claim(s) 18 and 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Filippou et al., WO 2021/067140 A1 (hereafter referred to as Filippou) in view of Bhorkar.
Claim 30, Filippou teaches a communication device operating in a communications network (p. 2, “Embodiments described herein generally relate to edge computing, network communication, and communication system implementations, and in particular, to techniques for implementing Vehicle-to-Everything (V2X) communications in Multi-access Edge Computing (MEC) systems and networks.”), the communication device comprising: processing circuitry; and memory coupled to the processing circuitry and having instructions stored therein that are executable by the processing circuitry (p. 270, “The compute node 2800 includes or is embodied as a processor 2804 and a memory 2806. The processor 2804 may be embodied as any type of processor capable of performing the functions described herein (e.g., executing an application). “) to cause the communication device to:
request a service level prediction from a network node in the communications network, the service level prediction is associated with a predicted route of the communication device (p. 57-58, “In procedure 400, where the service consumer requests the planned route information of a particular V-ITS-S. Procedure 400 is a scenario where, the service consumer (e.g., a V2X application, MEC app, etc.) sends a request to the VIS to receive predicted QoS corresponding to potential routes of a V-ITS-S, and receives a response containing the required/requested information (e.g., the predicted QoS information).”);
receive the service level prediction from the network node (p. 59. “At operation 402, the service producer (e.g., the VIS) responds with a response/reply message including a message body containing the predicted QoS information data structure ( PredictedQoS ). In this embodiment, the response message is an HTTP response message including the status code "200 OK" in the header of the HTTP message, which indicates that the service consumer’s request succeeded.”); and
perform an action based on the service level prediction (p. 62, “… the time attribute may be included to indicate an actual time of visiting a particular location indicated by the Locationlnfo, or a predicted time that the V-ITS-S is expected to visit the particular location.”), perform an action based on the service level prediction comprising at least one of: moving along the route (alternate limitation; p. 62, “Intermediate routelnfo structures corresponding to waypoint locations can include actual times that the V-ITS-S visits those waypoint locations, predicted/expect times for arriving at the waypoint locations, or some combination thereof.” Expected time is given for the direction being driven but not restricted to the route.); and
adjusting the route based on the likelihood of the service level prediction being met (p. 148, “Following the Google Traffic analogy, by gaining access to current and predicted network performance, drivers (or their satnav route planner) can adjust their route to optimize their experience. Likewise, many services could adjust their mode of operation if they have advance warning regarding any significant changes in expected network performance. Nevertheless, so far only network performance is considered for the predictions.”). Filippou does not specifically teach adjusting the route based on the likelihood of the service level prediction being met. However, in the same filed or endeavor, Bhorkar teaches adjusting the route based on the likelihood of the service level prediction being met (p. 57, “the route optimization system 154 may suggest a detour that satisfies the QoS requirements 148 or at least better approaches the QoS requirements 148. In some embodiments, the user may decide to abandon the selected route and choose another one of the routes 206A-206C.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Filippou by incorporating changing the route based on prediction from Bhorkar to improve user experience by initiating a detour that meets QOS requirement and thereby enable access to the service at the expected service level.
Claim 18 recites steps similar to the operations of claim 30 above. Claim 18 is rejected on a similar rationale.
Claim 20, Filippou-Bhorkar teaches the method of Claim 18, further comprising:
determining a likelihood of the service level prediction will not be met (Bhorkar, p. 57, “… the route optimization system 154 can inform the user, via the QoS-based map application 144/146, where along the routes 206A-206C the QoS requirements 148 are not satisfied. The user can use this information to make a more informed decision with regard to route selection.”).
Claim 21, Filippaou-Bhorkar teaches the method of claim 20, wherein determining the likelihood of the service level prediction being met comprises receiving an indication from the network node that the service level prediction will not be met (Bhorkar, p. 57, “From time to time, after a route has been selected, the selected route may be compromised due to weather, network failure, or some other circumstance, and as a result, the QoS requirements 148 cannot be satisfied. In these instances, the QoS-based map application 144/146 can inform the user of the portion(s) of the selected route where the QoS requirements 148 are not satisfied.”).
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Filippou and Bhorkar as applied to claim 18 above, and further in view of Pawar et al., US 11252214 B1 (hereafter referred to as Pawar).
Claim 19, Filippou-Bhorkar teaches the method of Claim 18, as cited above. Filippou-Bhorkar does not specifically teach further comprising:
transmitting a message to the network node requesting a likelihood of the service level prediction being met be increased. However, in the same field of endeavor, Pawar teaches transmitting a message to the network node requesting a likelihood of the service level prediction being met be increased (column 12, lines 19-25; "Further, as the UE is served with EN-DC by the 4G eNB 16 and the 5G gNB 20, the act of determining that the UE is headed toward reduced-throughput coverage or otherwise predicting that the UE will experience a coverage-throughput reduction could be carried out by any entity or entities that could track the UE's location in correlation with likely levels of coverage throughput. "And column 13, lines 19-31; "Further, as the UE is served with EN-DC by the 4G eNB 16 and the 5G gNB 20, the act of determining that the UE is headed toward reduced-throughput coverage or otherwise predicting that the UE will experience a coverage-throughput reduction could be carried out by any entity or entities that could track the UE's location in correlation with likely levels of coverage throughput."). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Filippou-Bhorkar by incorporating increasing likelihood of service level from Pawar to improve the network performance. The motivation would have been to be proactive and increase user experience by providing service as expected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lucas et al., US 20160211988 A1, teaches the techniques described herein, therefore, provide for the rendering of a customer's intent into a network intent such that a layer of abstraction may be implemented to assist customers that do not know precisely how to configure or request specific SLA or other network parameters. Specifically, the techniques herein allow for feedback-based adjusting of rendered policies, ensuring that the customer's intent is properly managed within a computer network.
Sabella et al., US 20210112441 A1, teaches A Prediction Function (PF) 302 collects necessary information, such as statistics including network, vehicle, and third-party data, to generate predictions, e.g., using machine-learning models. FIG. 3 shows an example of a vehicle running two applications using predictive QoS. The role of the PF 302 is to generate predictions of Quality-of-Service (QoS) to be experienced by, for example, Teleoperated Driving applications, V2X applications, and the like.
Filippou et al., WO 2020227435 A1, teaches the disclosed embodiments provide a V2X Information Service (VIS) framework for cooperative acquisition, partitioning, and distribution of information for efficient, journey-specific quality-of-service (QoS) predictions. The VIS framework identifies space/time correlations between radio condition/quality data collected in V2X system(s) and a vehicle's planned journey for better prediction of the radio conditions/quality of the communication network along the designated route.
Hamidian et al., WO 2023143695 A1, teaches the invention relates to a network node (100) informing a service consumer (300) about a QoS prediction for an end-to-end user plane link (550) between a first application instance (A1) and a second application instance (A2), where the end-to-end user plane link (550) comprises a set of network domains (D1, D2,..., Dn). Thereby, the service consumer (300) may benefit from an augmented QoS prediction service in a multi-domain environment that provide an aggregated QoS prediction covering the end-to-end user plane link by composing individual information collected across the different network domains in the set of network domains.
Miretsky et al., USPN 11317244 B1, in operation 106, one or more travel route recommendations are made to the consumer, based on the predicted QOS of the network at each target destination of the at least one target destination. The one or more recommendations may be provided to the consumer via one or more push notifications. To this end, travel route recommendations may be made for a consumer based on a network QOS prediction related to target destination(s) of the consumer. This may allow the consumer to change an existing route and/or change service providers, in order to improve a level of QOS provided to the consumer, before the QOS is negatively impacted (e.g. by certain events, lack of coverage, etc.).
Li et al., USPN 12317193 B2, teaches using an Intent Translation Module to obtain intent knowledge information and network knowledge information from the intent knowledge repository. Generate translation results, including an intent execution command and a corresponding network condition, a criterion for achieving an intent, a name and an identifier of an intent applied entity, and a format of a command that can be executed by the device. A request may be made to modify the intent priority. Specifically, the intent priority is increased, so that network resources occupied by the intent may be increased by the first network element/the third network element.
Rutger Claes et al., Traffic Coordination Using Aggregation-Based Traffic Predictions, teaches The InfrastructureAgents, however, aren’t interested in the intentions of all drivers participating in the system. They’re only interested in intentions that are relevant to their link—such as the intentions of drivers that plan to traverse their link. If a driver changes its route and the VehicleAgent has already propagated its previous route, this would lead to false information being used by the InfrastructureAgent. When a large number of drivers change their route be cause of changing traffic conditions, this false information could lead to inaccurate travel time predictions and bad route selection.
Varga, On Intention-Propagation-Based Prediction in Autonomously Self-adapting Navigation, teaches if the predicted future travel times show that a new travel
route is preferable, then the vehicle agent is free to change its route plan. If the vehicle agent changes its route plan, then it notifies the delegate MAS of its change of intention. The old intention is then invalidated and the new intention is registered
in the delegate MAS. If many vehicles make decisions at the same time, then they may make the same decision to take the same alternative route to avoid the already predicted congestion and cause congestion on the alternative route.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 PATRICE L WINDER whose telephone number is (571)272-3935. The examiner can normally be reached M-F 10am-6pm.
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, KAMAL B DIVECHA can be reached at (571)272-5863. 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.
/Patrice L Winder/Primary Examiner, Art Unit 2453
Prosecution Insights