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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/20/2026 has been entered.
Claims 1, 9, and 16 have been amended and no claims have been added and/or canceled.
Claims 1-20 are pending with claims 1, 9, and 16 as independent claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 remain rejected under 35 U.S.C. 103 as being unpatentable over Fraenkel et al. (US 2003/0065986, published 4/3/2003, hereinafter as Fraenkel) in view of Chandrasekhar et al. (US 2020/0382361, published 12/3/2020, hereinafter as Chandrasekhar).
Claim 1. A system, comprising:
processing circuitry; and a memory connected to the processing circuitry, Fraenkel teaches in [0056 and 0080] “a computer 35 that hosts the controller 34 will be referred to as a "controller computer.".. the controller 34 stores various test control data in local storage 38. The test control data typically includes testcase files (script files and related data files) for pre-recorded transactions, and session files that specify the various monitoring sessions that have been created.” ((emphasis added) examiner note: the controller as a processing circuitry may be connected to local storage 38), wherein the memory is configured to store executable instructions that, when executed by the processing circuitry, facilitate performance of operations, comprising:
receive a root cause analysis (RCA) policy identifier; Fraenkel teaches in [0057] “Through this UI, the user can, among other things, select the agent computers 40 to be included within a monitoring session, and assign transactions and execution schedules to such computers. The controller 34 also provides functions for specifying alert conditions, and for notifying personnel when such conditions exist. Example screens of the controller's UI are shown in FIGS. 2-12 and 16 and are described below.” And in [0086] “To create a new monitoring session, the user selects PROFILE/NEW, which causes the controller 34 to launch a Setup Wizard (FIGS. 3-9). As illustrated by FIG. 3, the user is initially prompted to specify a session name. The session name provides a mechanism for later retrieving or viewing the reports for a particular monitoring session.” And in [0079] “the alerts engine can be configured to page a system administrator whenever the average response time of the transactional server exceeds a certain threshold, or when the transactional server becomes inaccessible from any location or organization.” (emphasis added) examiner note: the session name may be the policy identifier as shown in fig. 3,
receive one or more network element groups, where event messages from each network element group is to be filtered for monitoring; Fraenkel teaches in [0086-0087] As illustrated in FIG. 4, the user is then presented a "Select Transactions" screen for specifying the previously-generated transactions to be included within the monitoring session. The user can also use the NEW button to launch the recorder 34A and record a new transaction. The transaction may include a single URL request or multiple URL requests, including URL requests with data submissions (e.g., HTTP POST requests)… the user can later assign specific transactions, or sets of transactions, to specific agent computers 40, and can monitor the performance of the transactional server on a transaction-by-transaction basis… the user can freely define what constitutes a "transaction" for monitoring purposes… the transactions are defined by the user with sufficient granularity to facilitate identification of performance bottlenecks.” And in [0126] “the agents 32 could be configured to "filter" the transaction execution data, so that only those transactions that meet certain predefined criteria are reported. These and other alternatives could optionally be provided as user-configurable options.” (emphasis added) examiner note: the user may define one or more transactions as element group for monitoring such that transactions meet certain criteria may be filtered for the purpose of sending notifications,
receive one or more defined faults for each network element group, the one or more defined faults including a threshold value; Fraenkel teaches in [0097-0098] “As illustrated by FIGS. 11 and 12, the Alerts Wizard also provides screens for specifying notification criteria for the parameters to be monitored. In the example shown in FIG. 11, the user can request to be notified whenever the average response time exceeds a specified threshold, or exceeds the threshold with a specified frequency (e.g., 10 times per minute). As shown in FIG. 12, the user can also request to be notified by pager or email of an alert condition.” (emphasis added) examiner note: the fault may be defined when the average response, for a defined transaction, exceeds 10 seconds, for example,
receive an RCA policy definition for each network element group, based upon a conjunction of the one or more defined faults; Fraenkel teaches in [0194-0195] “The RCA system 168 then applies one or more predefined dependency rules to identify all of the possible parameters affecting the performance of the transaction. The performance data associated with each of the parameters is then analyzed by the RCA system 168 to predict which parameter(s) is/are the most likely cause of the problem… the identified parameters are displayed in the RCA UI tree 226 as additional (child) nodes that may, in some cases, be further expanded to drill down to more specific root causes of the performance problems.” (emphasis added),
enrich the event messages based on inventory information to provide data for at least one missing field in at least one of the event messages; Fraenkel teaches in [0119] “Upon receiving an alert notification message, the recipient can log into the reports server 36 to obtain details of the alert event, such as the location or organization of the agent computer that reported associated performance data.” And in [0126-0134] “the task of checking for and notifying users of alert conditions could be performed by the agents 32 and/or by the reports server 30, rather than by the controller 34. Further, the agents 32 could be configured to "filter" the transaction execution data, so that only those transactions that meet certain predefined criteria are reported… if the failed transaction involved an unexpected or missing message on a web page, the user could view the entire web page as well as the web pages (including any form data submitted by the agent) that preceded the unexpected response. An important benefit of this feature is the ability for the user to view the sequence of events that led to the failed transaction.” And in [0183] “The RCA UI tree 226 is based on (although not necessarily identical to) the underlying tree data structure built by the RCA system 168 during analysis of the performance data for the filtered transactions. Nodes of the RCA UI tree 226 that may be expanded by the user to view additional details are displayed with a "+" symbol throughout the RCA UI tree 226. Color coding (represented using hatching in the figures) indicates quality or severity grades based on comparisons with historical data, as described below.” And in [0192] “For more detailed information, the user highlights a poor performing transaction node from the RCA UI tree 226, such as, for example, the "BuyAStock" transaction node, and selects the graphs tab 228 to view a graph 250 of the transaction's performance during the specified time frame (see FIG. 34A). By selecting the data tab 230 with the transaction node highlighted, the user is able to view a tabular summary 252 of the transaction's performance (see FIG. 34B).” (emphasis added) examiner note: the alert notification message, regarding unexpected missing message, may be enriched by providing the user to view sequence of events that led to the failed transaction,
Fraenkel does not explicitly disclose
receive an action to be initiated by an action resource in response to the RCA policy definition and the enriched event messages for a network element group being satisfied. However, Chandrasekhar, in an analogous art, discloses in [0075-0078, 0081, and 0088-0089] “eNB 102 transmits alarm data and key performance indicator data. via the backhaul or network interface 382, to a server in order to detect network anomalies, diagnose the anomalies and provide instructions to correct the detected anomalies… Troubleshooting is triggered in response to detecting one or more of the KQIs falling outside a threshold or a nominal value. The troubleshooting process involves a manual or automated reasoning step for inferring the root-cause explanation to the KQI degradation. The root causes are obtained by detecting and diagnosing KPI anomalies providing fine-grained causal information for the KQI anomaly… when a service quality KQI indicates an anomaly of degradation in IP throughput, the possible root causes could be either low traffic demand or high radio frequency interference. Once root cause analysis (RCA) of the anomaly is complete, a recovery step could range from simply resetting the BS, or changing the Operations and Maintenance (OAM) parameters (e.g. transmit power, electrical tilt) at the BS.” And in [0113] “after the RCA 420 determines the root causes for the detected anomalies, an explanation of the root cause as well as the remedial action 422 can be displayed, on a user interface. When the remedial action 422 is displayed it can include recommended action(s) to perform in order to restore the network to its normal functioning state. In other embodiments, the remedial action 422 performs the necessary actions to restore the network to its normal functioning state automatically. The remedial action 422 can apply a corrective action as a function of the determined root cause that is responsible for the degradation of the KQI of interest.” (emphasis added) examiner note: the remedial action 422 may display recommended one or more actions to be performed, and
control an incident manager system to execute the action on the network element group in response to a received fault satisfying the RCA policy definition for the network element group. However, Chandrasekhar, in an analogous art, discloses in [0078 and 0088-0089] “A subset of these data, referred to as Key Quality Indicators (KQIs). A KQI provides aggregated metrics reflecting the level of service accessibility, service retainability, service availability, service quality and service mobility… The batch processing layer 406 generates rules for RCA based on the detected anomaly, from historical data. The rules identify an anomaly from the data and suggest a cause for the anomaly. The rules can also suggest one or more remedial actions that will resolve the detected anomaly… As shown in Equation (2), an anomaly is identified when the KQI is less than a threshold. After an anomaly is detected, the RCA framework 400 then discovers underlying root causes of the detected anomalies and then executes corrective actions based on the derived rules. That is, an anomaly is a symptom and the RCA is performed to identify the cause of the symptom and thereby determine a remedy for the detected anomaly such that the operator network returns to normal.” And in [0113-0114] “after the RCA 420 determines the root causes for the detected anomalies, an explanation of the root cause as well as the remedial action 422 can be displayed, on a user interface. When the remedial action 422 is displayed it can include recommended action(s) to perform in order to restore the network to its normal functioning state. In other embodiments, the remedial action 422 performs the necessary actions to restore the network to its normal functioning state automatically. The remedial action 422 can apply a corrective action as a function of the determined root cause that is responsible for the degradation of the KQI of interest.” And in [0193] “It is noted that alarms are event triggered based on a malfunctioning at the eNB while PM data is a per cell basis and received at certain intervals. Alarms are vital to the troubleshooting and diagnosis of hardware and software problems that potentially result in degraded network KQIs. As such, by joint processing alarms and PM data provides an explanation and the ability to predict occurrence of PM anomalies based on alarm eNB occurrences.” (emphasis added) examiner note: remedial action 422 may perform the necessary actions to restore the network to its normal functioning state automatically in response to detecting anomalies or faults (or average response time exceeds a certain threshold as an RCA policy set by a user shown in fig. 10 as indicated by Fraenkel) within cellular network.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Fraenkel with the teaching of Chandrasekhar because “to increase user experience and decrease prolonged network outages, service providers must rapidly discover the anomalies, uncover the underlying root causes of the anomalies, and apply remedial action”. Chandrasekhar [Background].
Claims 2, 10, and 17. The rejection of the system of claim 1 is incorporated, wherein the executable instructions further facilitate performance of operations, comprises:
cause a graphical user interface (GUI) to be output by a user interface (UI), the GUI comprising: a display of the network element groups in response to each network element group being received; Fraenkel teaches in [0092] “The user can also specify, for each computer, the order in which that computer is to execute the assigned transactions. As transactions are assigned to agent computers 40, the transactions are added to the session tree 46 as children of their respective computers (as illustrated in FIGS. 7 and 8 for the computer "dolphin").” And in [0105] “The examples shown in FIGS. 13-15 illustrate a monitoring session involving five transactions: Order Entry, Item in Stock Search, Browse Order Status, Update Account, and Purchase from Stock. The transactions are being executed from agent computers 40 located in four geographic regions: New York, Japan, United Kingdom and San Francisco.” (emphasis added) examiner note: display of elements, such as order entry, item in stock search, browse order status, purchase from stock, may be a display of the network element groups as shown in figs. 8 and 13.
Claims 3, 11, and 18. The rejection of the system of claim 1 is incorporated, wherein the executable instructions further facilitate performance of operations, comprises:
cause a graphical user interface (GUI) to be output by a user interface (UI), the GUI comprising: a display of one or more RCA policy templates, the display
including a status of each RCA template; Fraenkel teaches in [0183-0184] “The RCA system 168 initially builds a tree data structure to indicate which of the monitored transactions performed poorly during the specified time frame… Using a "group by" button, the user may specify whether the transaction response times are to be grouped within the tree by transaction (FIG. 33A), by location (not shown), by severity grade (FIG. 41), or by other criteria. Regardless of the grouping method used, a user may navigate down the tree to effectively progress from general problem descriptions (e.g., "transaction response time of transaction T1 was ten seconds, which is longer than usual") to more specific problem descriptions that reveal the likely source of the performance degradation (e.g., "the number of processes running on database server DB increased from 8 to 12.")” (emphasis added) examiner note: as can be seen, in fig. 33A, status of each of four different monitored elements is displayed in may be root cause analysis templates.
Claims 4, 12, and 19. The rejection of the system of claim 1 is incorporated, wherein the receiving a root cause analysis (RCA) policy identifier comprises:
cause a graphical user interface (GUI) to be output by a user interface (UI), the GUI comprising: a display including one or more input fields configured to receive one or more user inputs identifying a policy name, a policy version identifier, a network vendor identifier, a policy type identifier, or a description of a RCA policy; Fraenkel teaches in [0086] “As illustrated by FIG. 3, the user is initially prompted to specify a session name. The session name provides a mechanism for later retrieving or viewing the reports for a particular monitoring session.” (emphasis added) examiner note: the user may be prompted to enter in a graphical user interface a name for monitoring session as shown in fig. 3.
Claims 5, 13, and 20. The rejection of the system of claim 1 is incorporated, wherein the receiving one or more network element groups, comprises:
cause a graphical user interface (GUI) to be output by a user interface (UI), the GUI comprising: a display including one or more input fields configured to receive one or more inputs identifying an element group name, an element criteria type, an element type, a network location, a domain, a network element filter, or a filter value that is used to filter event messages based upon the filter value and the network element filter; Fraenkel teaches in [0086 and 0090] “As illustrated in FIG. 4, the user is then presented a "Select Transactions" screen for specifying the previously-generated transactions to be included within the monitoring session. The user can also use the NEW button to launch the recorder 34A and record a new transaction. The transaction may include a single URL request or multiple URL requests, including URL requests with data submissions (e.g., HTTP POST requests). The transactions may optionally include verification points that specify expected server responses, such as particular values or text strings within web pages. Alternatively, the transactions may stress the transactional server without verifying the content of the server responses. As described below, the user can later assign specific transactions, or sets of transactions, to specific agent computers 40, and can monitor the performance of the transactional server on a transaction-by-transaction basis…. When the user selects the EDIT button (FIG. 5) with a computer selected in the session tree 46, the user is presented with a "Computer Properties" screen as shown in FIG. 6. From this screen, the user can assign various attributes (properties) to the computer or confirm previously-assigned attributes. In the illustrated example, the attribute types are the location (e.g., city), organization (e.g., accounting department), and ISP of the agent computer 40. Other pre-defined attributes types that may be provided include, for example, a group name, the computer's operating system, the router to which the computer is connected, the computer's modem or other connection speed, the computer's default web browser (particularly if the agent uses or emulates the browser), and the hardware configuration of the computer.” (emphasis added) examiner note: the group name may be “attribute types” associated with a monitoring computer as indicated in fig. 6, wherein element in the group may be “router connected to the monitoring computer” and/or “the computer’s default browser”, etc.
Claims 6, 14. The rejection of the system of claim 1 is incorporated, wherein the receiving the one or more defined faults for each network element group, comprises: cause a graphical user interface (GUI) to be output by a user interface (UI), the GUI comprising:
a display including one or more input fields configured to receive one or more inputs identifying an event source that sends event messages to a correlation and policy engine (CPE), a event type to filter the event messages from the CPE, a message type to further filter the event messages from the CPE, or an event name to further filter the event messages from the CPE; Fraenkel teaches in [0079 and 0099] “The controller 34 further includes an alerts engine 34D that monitors some or all of the performance data generated by the agents 32 in real-time to check for user-defined alert conditions. Using the scheduler 34B, the alerts engine 34D can be configured to notify an operator of alert conditions by an appropriate communications method such as pager, cellular telephone, or email. For example, the alerts engine can be configured to page a system administrator whenever the average response time of the transactional server exceeds a certain threshold, or when the transactional server becomes inaccessible from any location or organization. The alerts engine 34D can also generate notifications that are based on the content (e.g., expected text strings or values) returned by the transactional server.” (emphasis added) examiner note: the alert engine may be the event source that sends notification messages to ISP admin or system admin based on the failure type and a role of the admin, and
one or more conjunction input fields configured to receive one or more filtering instructions based upon filtered event messages; Fraenkel teaches in [0090] “When the user selects the EDIT button (FIG. 5) with a computer selected in the session tree 46, the user is presented with a "Computer Properties" screen as shown in FIG. 6. From this screen, the user can assign various attributes (properties) to the computer or confirm previously-assigned attributes. In the illustrated example, the attribute types are the location (e.g., city), organization (e.g., accounting department), and ISP of the agent computer 40. Other pre-defined attributes types that may be provided include, for example, a group name, the computer's operating system, the router to which the computer is connected, the computer's modem or other connection speed, the computer's default web browser (particularly if the agent uses or emulates the browser), and the hardware configuration of the computer… The "Filters" option 88 (FIGS. 13-15) allows the user to filter the displayed information by transaction and by each of the attributes. Using this feature, the user can, for example, filter out from the reports the performance data corresponding to a particular transaction, location, organization, ISP, or combination thereof. In one embodiment (not shown), the user specifies the filter to be applied by completing a web form that includes a respective check box for each transaction and each attribute used in the monitoring session.” (emphasis added) examiner note: input fields associated with the computer monitoring user defined transactions may receive filtering instructions such as the ISP provider, location and organization, to be notified for failure, for example, and
one or more operator input fields configured to determine a number of occurrences for the filtered event messages; Fraenkel teaches in [0097-0098] “As illustrated by FIG. 10, the Alerts Wizard allows the user to specify one or more performance parameters to monitor in real-time for purposes of generation alerts, including response time, availability, pass/fail status, and response data size. By selecting the check box 70, the user can specify certain parameter statistics to monitor, such as the average of the parameter over a specified time frame… In the example shown in FIG. 11, the user can request to be notified whenever the average response time exceeds a specified threshold, or exceeds the threshold with a specified frequency (e.g., 10 times per minute).” (emphasis added) examiner note: fig. 11 provides input fields that allow the user to define a number of average response time exceeds threshold with specified frequency such as 10 times per minute before sending a notification message.
Claims 7, 15. The rejection of the system of claim 1 is incorporated, wherein the receiving the RCA policy definition for each network element group, comprises: cause a graphical user interface (GUI) to be output by a user interface (UI), the GUI comprising:
a display including one or more input fields configured to receive one or more inputs identifying a time window in which to accept filtered event messages, a root event, or a group by identifier; Fraenkel teaches in [0097] “As illustrated by FIG. 10, the Alerts Wizard allows the user to specify one or more performance parameters to monitor in real-time for purposes of generation alerts, including response time, availability, pass/fail status, and response data size. By selecting the check box 70, the user can specify certain parameter statistics to monitor, such as the average of the parameter over a specified time frame.” (emphasis added) examiner note: the user may select one or more values in one or more fields, such as response time, to be monitored over a specified time frame selected by checking box 70 as shown in fig. 10, and
one or more conjunction input fields configured to receive one or more defined faults that are monitored before an RCA policy is satisfied; Fraenkel teaches in [0098] “As illustrated by FIGS. 11 and 12, the Alerts Wizard also provides screens for specifying notification criteria for the parameters to be monitored…. the user can request to be notified whenever the average response time exceeds a specified threshold, or exceeds the threshold with a specified frequency (e.g., 10 times per minute).” (emphasis added) examiner note: one or more fields associated with the response time, such as average response time (10 time per minute).
Claim 8. The rejection of the system of claim 1 is incorporated, wherein the receiving the action to be initiated by the action resource in response to the RCA policy definition for a network element group being satisfied, comprises: cause a graphical user interface (GUI) to be output by a user interface (UI), the GUI comprising:
a display including one or more input fields configured to receive one or more inputs identifying an action type, the action resource in which to implement the action, the action to be initiated, or a payload; Fraenkel teaches in [0099] “The Alerts Wizard may also provide an option (not illustrated) to be notified when certain types of transactions fail, and/or when failures are detected within particular attribute groups. Using this option, a user can request to be notified whenever a problem is detected which falls within the user's respective area of responsibility. For example, a system administrator responsible for a particular business process may be notified when a transaction that corresponds to that business process fails; to avoid being notified of general failures, this notification may be made contingent upon other types of transactions completing successfully.” (emphasis added) examiner note: the action type may be sending notification when certain transaction fail, wherein the notification may be made contingent upon other types of transactions completing successfully, and
an input filed configured to receive an input when the action is to be taken when a change request is initiated; Fraenkel teaches in [0099] “Other example uses of this feature include: notifying an ISP administrator when a threshold number of agent computers using that ISP are unable to access to the transactional server (optionally contingent upon the transactional server being accessible from other ISPs); and notifying a system administrator responsible for a particular office when a threshold number of agent computers 40 within that office are unable to access to the transactional server (optionally contingent upon the transactional server being accessible from other offices).” (emphasis added) examiner note: ISP admin may be notified when certain number of agent computers are unable to access the transactional server, whereas system admin may be notified when a number of agent computer within particular office are unable to access the transactional server, which indicating notification “change request”.
Claim 9. The claim is directed towards a method executed by a processor to implement the operation steps of claim 1, therefore, the claim is similarly rejected as claim 1.
Claim 16. The claim is directed towards a device comprising a non-transitory, tangible computer readable storage medium storing a computer program, wherein the computer program contains instructions that when executed, cause a processor to perform operations of claim 1, therefore, the claim is rejected similarly to claim 1.
Response to Arguments
Applicant's arguments filed 11/30/2025 have been fully considered but they are not persuasive.
Argument: Applicant argues “Claim 1 recites "control an incident manager system to execute the action on the network element group in response to a received fault satisfying the RCA policy definition for the network element group." The Office conceded that Fraenkel fails to teach or suggest the recited claim language. (Office Action at page 6). The Office asserted that Chandrasekhar includes this feature. (Office Action at pages 6-7). Applicant respectfully traverses the interpretation of Chandrasekhar. Chandrasekhar mentions performing corrective actions based on a root cause analysis, but Chandrasekhar fails to reasonably teach or suggest that the corrective action is "in response to a received fault satisfying the RCA policy definition for the network element group." To the extent that the Office attempts to maintain the asserted rejection, Applicant respectfully requests that the Office specifically identify the portion of Chandrasekhar that is considered as reasonably teach or suggesting the above claim language.”
Response: Fraenkel sets RCA policy using Alert Wizard such that the user can specify certain parameter to monitor a network, wherein the parameter may be a response time such that if the response time exceeds certain time (such as detecting failures within particular attribute group) a notification may be transmitted to certain user. See Fraenkel [0097-0099] and fig. 10. Fraenkel does not teach or suggest action to remedy the failure of the network. However, Chandrasekhar performing action to remedy failure in the network when anomaly is detected in the network. Thus, the teaching of Fraenkel may be modified by the teaching of Chandrasekhar such that detected failures that have been set using RCA policy using the Alert Wizard, taught by Fraenkel, can be corrected using remedial action 422 taught by Chandrasekhar.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AHAMED I NAZAR whose telephone number is (571)270-3174. The examiner can normally be reached 10 am to 7 pm Mon-Fri.
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, Stephen Hong can be reached at 571-272-4124. 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.
/AHAMED I NAZAR/Examiner, Art Unit 2178 2/5/2026
/STEPHEN S HONG/Supervisory Patent Examiner, Art Unit 2178