DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9-13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In Claim 9, “at least one of a link status change, a first hub status change, a second hub status change, a first node status change, and a second node status change” appear to have antecedent basis in the claim.
Remaining claims are rejected as depending from a rejected claim.
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.
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.
Claim(s) 1 and 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849) in view of McLain et al. (US 2002/0145562).
For Claim 1, Kavuri teaches a system comprising:
a plurality of Mobile Communications Network (“MCN”) components including: a first network link; a first hub; a second hub; wherein the second hub is coupled with the first hub via the first network link; a first node; wherein the first node is coupled to the first hub; a second node; wherein the second node is coupled to the second hub; (see paragraphs 66, 69: core network components on bath comprising links, access nodes coupled to core)
a first User Mobile Device (“UMD1”); wherein the UMD1 is wirelessly coupled to the first node; a second User Mobile Device (“UMD2”); wherein the UMD2 is wirelessly coupled to the second node; wherein the UMD2 is communicatively coupled to the UMD1 via a first communications path that further includes the second node, the second hub, the first network link, the first hub, and the first node (see paragraphs 66, 62-63: user equipment in communication via core network and access nodes).
Though Kavuri does teach a load balancer collecting data on and monitoring the network (see paragraph 72), Kavuri as applied above is not explicit as to, but McLain teaches a Network Operations Center (“NOC”) comprising: a NOC processor; a non-transient NOC data store, coupled to the NOC processor, storing: first computer instructions, which when executed by the NOC processor (see paragraph 17: hardware is inherent to the recited system; paragraphs 33-37), instantiate an Outage Notification Monitor (“ONM”) which performs ONM operations including:
notifying at least one of the UMD1 and the UMD2 when a change of status in one of the MCN components is detected (see paragraphs 33-37: monitoring status and notifying UE).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to provide the network monitoring and remediation function as in McLain when implementing a network as in Kavuri. The motivation would be to ensure effective usage of network resources.
For Claim 3, Kavuri as applied above Is not explicit as to, but McLain teaches the system, wherein the non-transient NOC data store further stores: second computer instructions, which when execute by the NOC processor, instantiate a Network Link Status Monitor (“NLSM”) which performs NLSM operations including: monitoring link data for a link status change (see paragraph 32, 34: monitoring).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to provide the network monitoring and remediation function as in McLain when implementing a network as in Kavuri. The motivation would be to ensure effective usage of network resources.
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849) and McLain et al. (US 2002/0145562) as applied to claim 1 above, and further in view of Wu et al. (US 2015/0215918).
For Claim 2, the references as applied are not explicit as to, but Wu teaches the system, wherein the change of status in one of the MCN components results in a degradation in a Quality of Service (“QoS”) provided by the MCN to at least one of the UMD1 and the UMD2 (see paragraphs 52, 75-78L NOC, UE, QoS change with overloading resulting in reallocation).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor the QoS situation and act accordingly as in Wu when implementing the system of Kavuri and McClain. The motivation would be to address communication problems of user devices.
Claim(s) 4 and 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849) and McLain et al. (US 2002/0145562) as applied to claims 1 and 3 above, and further in view of Yadav et al. (US 2022/0014424) and Dutta et al. (US 2023/0115255).
For Claim 4, Kavuri as applied above is not explicit as to, but McClain teaches the system, wherein, the ONM operations further include:
upon receiving a notification of the link status change: retrieving a current dependency set for the first network link (see paragraphs 7, 33-37);
populating, based on the current dependency set, an impacted UMD data set (see paragraphs 7, 33-37);
determining, when UMD1 is on the impacted UMD data set, a first impact of the link status change on UMD1 (see paragraphs 7, 33-37: for multiple UMDs);
determining, when UMD2 is on the impacted UMD data set, a second impact of the link status change on UMD2 (see paragraphs 7, 33-37: for multiple UMDs); and
notifying, as appropriate, the UMD1 of the first impact and the UMD2 of the second impact (see paragraphs 7, 33-37).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to determine the cause of issues on the network as in McClain when managing a network as in Kavuri. The motivation would be to efficiently determine and resolve communication issues.
The references as applied above are not explicit as to, but Yadav teaches a data store wherein the link data is stored in the data store (see paragraphs 28-30: collection of data for analysis and monitoring);
wherein the NLSM operations further include: monitoring the data lake for the link status change (see paragraph 31: detect degradation); and notifying, when detected, the ONM of the link status change (see paragraph 34: alert to NOC).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor data and provide an alert as in Yadav when monitoring a network as in Kavuri and McLain. The motivation would be to provide for timely mitigation of detected issues.
The references as applied above are not explicit as to the data store being a data lake. However, Dutta teaches that it is known to aggregate data in a data lake for monitoring network services (see paragraph 35).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ a data lake as in Dutta when collecting data for monitoring the network of Kavuri, McClain, and Yadav. One of ordinary skill would have been able to do so with the reasonably predictable result of using a known data management mechanism for handling data during network status monitoring.
For Claim 5, the references as applied above are not explicit as to, but McLain further teaches the system, wherein, the ONM operations further include: determining a respective impact of the change in component status on at least one UMD identified on an impacted UMD data set (see paragraphs 7, 33-37); and
notifying the at least one UMD identified on the impacted UMD data set of the respective impact of the change in component status (see paragraphs 7, 33-37).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor effects on UMDs as in McLain when implementing the network of Kavuri. The motivation would be to ensure effective usage of network resources.
The references as applied above are not explicit as to, but Yadav teaches the system, wherein the first network link includes a first network link component (see paragraph 28);
wherein the link data includes first network component link status data for the first network link component (see paragraph 28);
wherein the first network component link status data is stored in a data store (see paragraph 29);
wherein the NLSM operations further include: monitoring the first network link component status data for a change in component status (see paragraphs 29, 30); and
notifying, when detected, the ONM of the change in the component status (see paragraph 34).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to aggregate data relating to links as in Yadav when implementing the network of Kavuri and McLain. The motivation would be to consider historical patterns of network conditions.
The references as applied above are not explicit as to the data store being a data lake. However, Dutta teaches that it is known to aggregate data in a data lake for monitoring network services (see paragraph 35).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ a data lake as in Dutta when collecting data for monitoring the network of Kavuri, McClain, and Yadav. One of ordinary skill would have been able to do so with the reasonably predictable result of using a known data management mechanism for handling data during network status monitoring.
Claim(s) 6-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849) and McLain et al. (US 2002/0145562) as applied to claim 1 above, and further in view of Rahman (US 2011/0075553).
For Claim 6, while Kavuri does teach the presence of core devices (see paragraph 66), Kavuri as applied above is not explicit as to, but McLain teaches the system of claim 1, wherein the non-transient NOC data store further stores:
second computer instructions, which when executed by the NOC processor, instantiate a Network Link Status Monitor (“NLSM”) which monitors link data for a link status change (see paragraphs 33-37: interference changes affect link status).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor links as in McLain when implementing the system of Kavuri. The motivation would be to collect information necessary for ensuring effective usage of network resources.
The references as applied above are not explicit as to, but Rahman teaches third computer instructions, which when executed by the NOC processor, instantiate a Hub Status Monitor (“HSM”) which monitors first hub data for a first hub status change and monitors second hub data for a second hub status change (see abstract, paragraphs 73, 75, 78).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor hub devices as in Rahman when implementing network monitoring as in Kavuri and McLain. The motivation would be to maintain user services even in the event of core network outages.
For Claim 7, Kavuri further teaches the system, wherein the non-transient NOC data store further stores: fourth computer instructions, which when executed by the NOC processor, instantiate a Node Status Monitor (“NSM”) which monitors first node data for a first node status change and monitors second node data for a second node status change (see paragraph 190: node channel condition monitoring, between node and UE).
For Claim 8, Kavuri further teaches the system, wherein the non-transient NOC data store further stores: fifth computer instructions, which when executed by the NOC processor, instantiate a User Mobile Device Status Monitor (“UMDSM”) which monitors UMD1 data for a UMD1 status change and monitors UMD2 data for a UMD2 status change (see paragraph 190: node channel condition monitoring, between node and UE).
Claim(s) 9 and 12-13, as understood in light of the rejection under 35 USC 112, is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849), McLain et al. (US 2002/0145562), and Rahman (US 2011/0075553) as applied to claims 1 and 6-8 above, and further in view of Yadav et al. (US 2022/0014424) and Dutta et al. (US 2023/0115255).
For Claim 9, Kavuri as applied above is not explicit as to, but McLain teaches the system wherein, the ONM operations further include:
upon receiving a notification of the given status change: retrieving a current dependency set for at least one of the first network link, the first hub, the second hub, the first node, and the second node (see paragraphs 7, 33-37);
populating, based on the current dependency set, an impacted UMD data set (see paragraphs 7, 33-37);
determining, when UMD1 is on the impacted UMD data set, a first impact of the given status change on UMD1 (see paragraphs 7, 33-37);
determining, when UMD2 is on the impacted UMD data set, a second impact of the given status change on UMD2 (see paragraphs 7, 33-37); and
notifying, as appropriate, the UMD1 of the first impact and the UMD2 of the second impact (see paragraphs 7, 33-37).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to determine the cause of issues on the network as in McClain when managing a network as in Kavuri. The motivation would be to efficiently determine and resolve communication issues.
The references as applied above are not explicit as to, but Yadav teaches a data store; wherein the link data is stored in the data store; wherein the first hub data is stored in the data store; wherein the second hub data is stored in the data store; wherein the first node data is stored in the data store; wherein the second node data is stored in the data store (see paragraphs 28-30: collection of data for monitoring);
wherein the NLSM, HSM, and NSM perform operations including: respectively monitoring the data lake for a given status change (see paragraph 31);
wherein the given status change is at least one of a link status change, a first hub status change, a second hub status change, a first node status change, and a second node status change (see paragraphs 31, 34); and
notifying the ONM when the given status change is detected (see paragraph 34).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor data and provide an alert as in Yadav when monitoring a network as in Kavuri and McLain. The motivation would be to provide for timely mitigation of detected issues.
The references as applied above are not explicit as to the data store being a data lake. However, Dutta teaches that it is known to aggregate data in a data lake for monitoring network services (see paragraph 35).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ a data lake as in Dutta when collecting data for monitoring the network of Kavuri, McClain, and Yadav. One of ordinary skill would have been able to do so with the reasonably predictable result of using a known data management mechanism for handling data during network status monitoring.
For Claim 12, Kavuri as applied above is not explicit as to, but McLain teaches the system, wherein, the ONM operations further include:
determining if a work-around is available to address, at least in part, at least one of the first impact and the second impact (see paragraphs 7, 33-37: adjustments to mitigate interference);
instructing, when the work-around is available, a reconfiguration of at least one component of the plurality of MCN components (see paragraphs 7, 33-37); and
wherein the reconfiguration alleviates, at least in part, at least one of the first impact and the second impact (see paragraphs 7, 33-37).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to mitigate issues on the network as in McClain when managing a network as in Kavuri. The motivation would be to efficiently determine and resolve communication issues to improve user services.
For Claim 13, Kavuri as applied above is not explicit as to, but McLain teaches the system, wherein, the ONM operations further include:
determining whether the first impact has been alleviated (see paragraphs 33-37); and
notifying the UMD1 when the first impact has been alleviated (see paragraphs 33-37).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to mitigate issues on the network as in McClain when managing a network as in Kavuri. The motivation would be to efficiently determine and resolve communication issues to improve user services.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over McLain et al. (US 2002/0145562).
For Claim 14, McLain teaches a computer server comprising: a Network Operations Center (“NOC”) processor; and a non-transient NOC data store, coupled to the NOC processor (see paragraph 17: hardware is inherent to the recited system), storing:
first computer instructions, which when executed by the NOC processor, instantiate an Outage Notification Monitor (“ONM”) which performs ONM operations including: notifying a User Mobile Device (“UMD”) when a change of status in a Mobile Communications Network (“MCN”) component is detected which impacts current usage of the MCN by the UMD (see paragraphs 7, 33-37).
McLain is not explicit as to the hardware teachings and the location of the NOC relative to the operations. However, one of ordinary skill in the art at the time the application was filed would have been able to assemble the known types of hardware within a NOC in order to facilitate network monitoring.
Claim(s) 15 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over McLain et al. (US 2002/0145562) as applied to claim 14 above, and further in view of Yadav et al. (US 2022/0014424).
For Claim 15, McLain as applied above is not explicit as to, but Yadav teaches the computer server, wherein the non-transient NOC data store further stores: second computer instructions, which when executed by the NOC processor, instruct the ONM to perform outage prediction operations including: predicting a future status change in one of the MCN components (see abstract, paragraph 33);
determining an impact of the future status change on the UMD (see paragraphs 33-37); and
notifying the UMD of the impact of the future status change (see paragraphs 34-35: recommendation).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to predict and notify outages as in Yadav when implementing the system of McLain. The motivation would be to provide timely recommendations to handle problems.
For Claim 18, McLain as applied above is not explicit as to, but Yadav teaches the computer server, wherein the outage prediction operations are further performed based on a current data set that includes at least one of: current signal strength data for at least one of the MCN components and the UMD (see paragraph 33: RSSI); current QoS data for at least one of the MCN components and the UMD; current outage data for the MCN (see paragraph 33: failure cause code); and current GIS data for the UMD.
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to predict and notify outages using parameters as in Yadav when implementing the system of McLain. The motivation would be to provide timely recommendations to handle problems.
Claim(s) 16 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over McLain et al. (US 2002/0145562) and Yadav et al. (US 2022/0014424) as applied to claims 14 and 15 above, and further in view of Ko et al. (US 2015/0280973).
For Claim 16, the references as applied above are not explicit as to, but Ko teaches the computer server, wherein the second computer instructions further include:
generating a network outage model that identifies, based on historical data, multiple interdependencies between two or more data sets (see paragraphs 22, 24, 27);
wherein the two or more data sets include data for one or more MCN components (see paragraph 27); and
generating a UMD outage model based on an application of past path data for the UMD to the network outage model (see paragraphs 20, 30).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to model outages as in Ko when implementing the system of McLain and Yadav. One of ordinary skill would have been able to do so with the reasonably predictable results of interpreting network behaviors in accord with past behaviors.
For Claim 17, the references as applied above are not explicit as to, but Ko teaches the computer server, wherein the two or more data sets include at least one of: historic signal strength data for at least one of the MCN components and the UMD; historic Quality of Service (“QoS”) data for at least one of the MCN components and the UMD; historic network data for the MCN (see paragraphs 22, 30); historic outage data for the MCN; and historic Geographic Information System (“GIS”) data for the UMD.
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to model outages as in Ko when implementing the system of McLain and Yadav. One of ordinary skill would have been able to do so with the reasonably predictable results of interpreting network behaviors in accord with past behaviors.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over McLain et al. (US 2002/0145562) and Yadav et al. (US 2022/0014424) as applied to claims 14-15 and 18 above, and further in view of Kavuri et al. (US 2019/0349849), Rahman (US 2011/0075553), and Dutta et al. (US 2023/0115255).
For Claim 19, McLain further teaches the computer server, wherein the non-transient NOC data store further stores: second computer instructions, which when execute by the NOC processor, instantiate a Network Link Status Monitor (“NLSM”) which monitors the data lake for data indicative of a first link status change (see paragraph 32).
McLain as applied above is not explicit as to, but Kavuri teaches the server, wherein the MCN components include: a first link; a first hub; a second hub; wherein the first link couples the first hub with the second hub; a first node coupled to the first hub; a second node coupled to the second hub; and a store lake storing data for the MCN components (see paragraphs 66, 69: core network components on bath comprising links, access nodes coupled to core; paragraphs 72, 104: operations necessarily require data store);
fourth computer instructions, which when executed by the NOC processor, instantiate a Node Status Monitor (“NSM”) which monitors the data store for data indicative of at least one of a first node status change and a second node status change (see paragraph 109); and
fifth computer instructions, which when executed by the NOC processor, instantiate a MUDSM which monitors the UMD for a UMD status change (see paragraph 109).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor data to monitor data for the various elements as in Kavuri when implementing the system of McLain. The motivation would be to ensure consideration of multiple factors that contribute to network issues.
The references as applied above are not explicit as to, but Rahman teaches third computer instructions, which when executed by the NOC processor, instantiate a Hub Status Monitor (“HSM”) which monitors the data lake for data indicative of at least one of a first hub status change and second hub status change (see abstract, paragraphs 73, 75, 78).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor hub devices as in Rahman when implementing network monitoring as in Kavuri and McLain. The motivation would be to maintain user services even in the event of core network outages.
The references as applied above are not explicit as to the data store being a data lake. However, Dutta teaches that it is known to aggregate data in a data lake for monitoring network services (see paragraph 35).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ a data lake as in Dutta when collecting data for monitoring the network of Kavuri, McClain, and Yadav. One of ordinary skill would have been able to do so with the reasonably predictable result of using a known data management mechanism for handling data during network status monitoring.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849), McLain et al. (US 2002/0145562), and Rahman (US 2011/0075553).
For Claim 20, Kavuri teaches a non-transitory computer readable medium, having stored thereon computer instructions (see paragraphs 23, 155-157) which, when executed by a processor for a Mobile Communications Network (“MCN”) having two or more MCN components including at least one of an MCN link, an MCN hub, and an MCN node (see paragraphs 66, 69: core network components on bath comprising links, access nodes coupled to core), cause the NOC to perform operations comprising:
instantiate a Node Status Monitor which detects data indicative of a status change in the MCN node (see paragraph 190: node channel condition monitoring, between node and UE).
Kavuri as applied above is not explicit as to, but McLain teaches a Network Operations Center (“NOC”) (see paragraphs 7, 17) and operations to instantiate a Network Link Status Monitor which detects data indicative of a status change in the MCN link (see paragraphs 33-37: interference changes affect link status); and
instantiate an Outage Notification Monitor (“ONM”) which notifies a User Mobile Device (“UMD”) when a change of status in at least one of the two or more MCN components is detected which impacts current usage of the MCN by the UMD (see paragraphs 33-37: monitoring status and notifying UE).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to provide the network monitoring and remediation function as in McLain when implementing a network as in Kavuri. The motivation would be to ensure effective usage of network resources.
The references as applied above are not explicit as to, but Rahman teaches instantiating a Hub Status Monitor which detects data indicative of a status change in the MCN hub (see abstract, paragraphs 73, 75, 78).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to monitor hub devices as in Rahman when implementing network monitoring as in Kavuri and McLain. The motivation would be to maintain user services even in the event of core network outages.
Allowable Subject Matter
Claims 10 and 11 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Carrillo et al. (US 2006/0072505) teaches a system for link status monitoring and prediction. Howarter et al. (US 2009/0274052) teaches a system in a NOC for monitoring network failures and providing alerts. Kanevsky et al. (US 2023/0208728) teaches a system which provides alerts at times of high outage risk. Yi et al. (US 2020/0396629) teaches network monitoring based on link state parameters. Kubba et al. (US 2021/0073659) teaches a system for collecting network statistics and identifying status changes.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CASSANDRA L DECKER whose telephone number is (571)270-3946. The examiner can normally be reached 7:30 am - 4:00 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, Faruk Hamza can be reached at 571-272-7969. 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.
/CASSANDRA L DECKER/Examiner, Art Unit 2466 1/16/2026
/FARUK HAMZA/Supervisory Patent Examiner, Art Unit 2466