DETAILED ACTION
This Office action is in response to the amendment filed 7 April 2026. Claims 1-20 are pending in this application.
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 § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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 Schemagin et al. (US 2016/0135232) and 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 path comprising links, access nodes coupled to core)
a first User Mobile Device (“UMD1”); wherein the UMD1 is wirelessly coupled to the MCN via the first node; a second User Mobile Device (“UMD2”); wherein the UMD2 is wirelessly coupled to the MCN via the second node; and wherein the UMD2 is communicatively coupled to the UMD1 via a first communications path provided by the MCN and using a plurality of MCN components that further include the second node, the second hub, the first network link, the first hub, and the first node (see Figure 1, 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 Schemagin teaches a Network Operations monitor, configured to monitor a current operating status of each of the MCN components (see paragraphs 4, 46: all the components of a network, monitoring), comprising:
a processor (see paragraphs 20, 103); a non-transient data store, coupled to the processor (see paragraphs 20, 103), storing:
first computer instructions, which when executed by the processor, instantiate an Outage Notification Monitor (“ONM”) which performs ONM operations including: notifying at least one of the UMD1 and the UMD2 when a change in the current operating status in one of the MCN components is detected (see paragraphs 18, 46, 87, 91, 99-102: affected UEs identified and handed over or notified).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ a network monitoring system as in Schemagin when implementing a network as in Kavuri. The motivation would be to maintain communications for the connected endpoint devices.
The references as applied above are not explicit as to the monitoring equipment being called a Network Operations Center comprising a NOC processor and a non-transient NOC data store. However, as can be seen in McLain, NOCs and their hardware (see paragraphs 6-7, 17, 33-37) are well known in the art.
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use a NOC when implementing the network of Kavuri and Schemagin. One of ordinary skill would have been able to do so with the reasonably predictable result of providing a known type of means for monitoring multiple interconnected networks.
For Claim 3, Kavuri as applied above Is not explicit as to, but Schemagin as modified by McLain above 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 paragraphs 99-102); and
wherein the NOC notifies at least one of the UMD1 and the UMD2 of the link status change (see paragraphs 99-102).
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 Schemagin 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), Schemagin et al. (US 2016/0135232), 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, Kavuri as applied above is not explicit as to, but Schemagin as modified by McLain teaches the NOC notifying at least one of the UMD1 and the UMD2 of the degradation in the service provided by the MCN (see paragraphs 99-102).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to notify UEs by the NOC as in Schemagin and McLain when implementing a network as in Kavuri. The motivation would be to maintain communications for the connected endpoint devices.
The references as applied above are not explicit as to, but Wu teaches the system, wherein the change of current operating 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, Schemagin, 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), Schemagin et al. (US 2016/0135232), 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 and Schemagin 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), Schemagin et al. (US 2016/0135232), 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 and Schemagin as applied above are 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, Schemagin, 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 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kavuri et al. (US 2019/0349849), Schemagin et al. (US 2016/0135232), 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 and Schemagin as applied above are 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, Schemagin, 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, Schemagin, 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 and Schemagin as applied above are 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 and Schemagin. The motivation would be to efficiently determine and resolve communication issues to improve user services.
For Claim 13, Kavuri and Schemagin as applied above are 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 and Schemagin. 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-11 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
The amendment filed 7 April 2026 has been entered.
Previous rejections under 35 USC 112 are withdrawn in light of the amendments.
Applicant’s arguments with respect to rejections over prior art have been fully considered, but are either not persuasive or moot in view of the new grounds of rejection introduced herein. The claims remain rejected under 35 USC 103.
With regards to teachings of McLain, please note that the UMDs in McLain are notified of the status change by undergoing the process applied to identify the problem. As for notifications in Claim 4, the claim only recites that the UMDs are notified of the impact, but not about any other details relating to the impact. Thus McLain teaches the matter for which it is relied upon.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Sohn et al. (US 2015/0381640) teaches a NOC that notifies endpoints of events. Graffagnino et al. (US 2014/0323137) teaches a network management system.
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 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 4/24/2026
/FARUK HAMZA/Supervisory Patent Examiner, Art Unit 2466
Prosecution Insights