DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This action is responsive to applicant's amendment and remarks received on 02/27/2026.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-4, 7, 11-13, 15-16, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sahai (US 2021/0027613 A1) in view of Ciasulli (US 2016/0153806 A1 – newly cited).
Regarding claim 1, Sahai discloses a computer-implemented method for providing status information for a fire detection system (figs. 1, 3; abstract), comprising:
managing an inventory of multiple devices coupled with the fire detection system, including detecting addition of one or more devices to, or removal of one or more devices from, the fire detection system (fig. 2A; [0015]-[0019], [0020], [0025], [0028]-[0032], [0035]-[0040]); and
displaying, via an interface, a dashboard (figs. 2A-3; [0032]-[0034], [0036]-[0041], [0046]-[0052]), wherein the dashboard includes:
a first indication of an overall system health indicator of the fire detection system (fig. 2A; [0037], [0040]); and
a second indication of a status related to an issue with a device of the multiple devices ([0038]-[0039], [0042], [0044]-[0045]).
However, Sahai does not expressly disclose "wherein the overall system health indicator indicates an overall system health score generated as a function of multiple parameters of each of the multiple devices." Sahai discloses that the dashboard displays multiple device-level parameter categories — connected/not connected, experiencing an event, about to expire, and determined to be unhealthy/faulty ([0040]) — across the population of monitored devices. Sahai further teaches that the analytics monitors "the health and maintenance status of fire control system 100 in real time" ([0032]) and is intended to enable users "to remotely view the real time status of components associated with the fire control panels" so that the user "can easily determine the severity of a detected event and/or determine when a device requires maintenance" ([0009]).
In analogous art, Ciasulli teaches a remote monitoring system for assets having multiple subsystems and multiple sensors per subsystem, where the remote computing system is configured to determine a "health metric (also referred to herein as a 'health score') of a given asset, which may be a single, aggregated parameter" reflecting the overall health of the asset ([0011]). Ciasulli teaches generating this aggregated health score as a function of multiple parameters drawn from each subsystem of the monitored asset: each subsystem has its own subsystem-level health metric computed from multiple sensor parameters of that subsystem ([0020]-[0021], [0077], [0175]-[0183]); the subsystem-level health metrics are then combined into an overall asset-level health metric, optionally with weighting based on the relative importance of each subsystem to the overall operation ([0022], [0184]-[0185]); and the overall health score is displayed on a graphical user interface as a numerical percentage and dial-like visualization ([0165], FIG. 7, element 702). Ciasulli contemplates use across a wide range of distributed-device monitoring contexts, including transportation machines, industrial machines, medical machines, and utility machines, among other examples ([0059]), and notes that the analytics system may receive data from and provide composite health information for "a fleet of locomotives or aircrafts, a group of wind turbines, or a set of MRI machines, among other examples" ([0060]). Ciasulli's score is dynamically updated based on current operating conditions ([0015]-[0016]) and is used to trigger alerts, work orders, and other actions ([0017]-[0019]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Sahai to display an overall system health score generated as a function of multiple parameters of each of the multiple devices, as taught by Ciasulli. Sahai expressly seeks to enable remote users to assess the severity of system events and determine when devices require maintenance (Sahai, [0008]-[0009]), and Sahai already collects the per-device parameters (connection state, expiration state, unhealthy/faulty state, event state, inspection status; [0035]-[0041]) that Ciasulli's composite scoring approach operates upon. A person of ordinary skill in the art would have been motivated to apply Ciasulli's known weighted-aggregation scoring technique to Sahai's existing device-parameter data, yielding the predictable result of a single dashboard health score.
Regarding claim 3, Sahai in view of Ciasulli discloses the computer-implemented method of claim 1, further comprising generating the overall system health indicator based at least in part on a number or severity of trouble conditions on the fire detection system (Sahai figs. 2A-2B; [0008], [0032]-[0035], [0037]-[0041]), or whether an application that manages the fire detection system is updated to a latest revision.
Regarding claim 4, Sahai in view of Ciasulli discloses the computer-implemented method of claim 1, further comprising detecting an out-of-date status indication for the device, wherein the dashboard displays the status related to the issue with the device indicating the out-of-date status indication (Sahai fig. 2A, element 224, 226, 228, 232; [0032]-[0033], [0037]-[0041]).
Regarding claim 7, Sahai in view of Ciasulli discloses the computer-implemented method of claim 4, wherein the out-of-date status indication relates to detecting that the device is recalled (Sahai Fig. 2A, health data 224; significant events 226; [0032]–[0041]), the device is expired (Sahai Fig. 2A, inventory 232; [0037]–[0041]), or a firmware of the device is out of date (Sahai Figs. 2A–2D; [0028]–[0035]).
Regarding claim 11, Sahai in view of Ciasulli discloses the computer-implemented method of claim 1, wherein the dashboard includes the second indication as a banner identifying the status related to the issue with the device (Sahai Figs. 2A–2E; [0032]-[0035]).
Regarding claim 12, Sahai in view of Ciasulli discloses the computer-implemented method of claim 1, wherein the dashboard includes a banner displaying a security issue with the fire detection system, a bulletin related to the fire detection system or one or more of the multiple devices, a history associated with one or more of the multiple devices, or an upcoming event for the one or more of the multiple devices (Sahai Figs. 2A–2E; [0033]-[0045]).
Claim 13 is rejected under 35 U.S.C. §103 over Sahai in view of Ciasulli for the same reasons set forth with respect to claim 1. Claim 13 recites an apparatus including a display device, a memory, and a processor (see, e.g., Sahai Fig. 3; [0046]–[0047]) configured to perform the same operations recited in method claim 1. The limitations of claim 13 correspond directly to the steps of claim 1 in apparatus/functional form, and the scope and content of the recited features are substantially the same as those addressed in the rejection of claim 1.
Claim 15 is rejected under 35 U.S.C. §103 over Sahai in view of Ciasulli for the same reasons set forth with respect to claim 3. Claim 15 recites an apparatus including a display device, a memory, and a processor (see, e.g., Sahai Fig. 3; [0046]–[0047]) configured to perform the same operations recited in method claim 3. The limitations of claim 15 correspond directly to the steps of claim 3 in apparatus/functional form, and the scope and content of the recited features are substantially the same as those addressed in the rejection of claim 3.
Claim 16 is rejected under 35 U.S.C. §103 over Sahai in view of Ciasulli for the same reasons set forth with respect to claim 4. Claim 16 recites an apparatus including a display device, a memory, and a processor (see, e.g., Sahai Fig. 3; [0046]–[0047]) configured to perform the same operations recited in method claim 4. The limitations of claim 16 correspond directly to the steps of claim 4 in apparatus/functional form, and the scope and content of the recited features are substantially the same as those addressed in the rejection of claim 4.
Claim 19 is rejected under 35 U.S.C. §103 over Sahai in view of Ciasulli for the same reasons set forth with respect to claim 1. Claim 19 recites a computer-readable medium storing code executable by a processor (see, e.g., Sahai Fig. 3; [0046]–[0049]) that, when executed, performs the same operations recited in method claim 1. The limitations of claim 19 correspond to the steps of claim 1 in executable-code form, and the scope and content of these features are substantially the same as those addressed in the rejection of claim 1.
Claims 2, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sahai (US 20210027613 A1) in view of Ciasulli (US 2016/0153806 A1), and further in view of Vidal (US 20220172591 A1) and Coop (US 20070114280 A1).
Regarding claim 2, Sahai in view of Ciasulli discloses the computer-implemented method of claim 1, wherein the parameters of each of the multiple devices include, for a given device of the multiple devices, a cleanliness of the device, a firmware status of the device, an expiration date of the device (Sahai, [0040]), whether the device is bypassed (Sahai, [0035], [0037], [0040]), whether the device is disabled (Sahai, [0035], [0037], [0040]), a date of a last inspection performed for the device (Sahai, [0039]), a date of a last notification self-test performed for the device (Sahai, [0044]), or a date of a last environmental test performed for the device (Sahai, [0044]).
However, Sahai in view of Ciasulli does not expressly disclose a cleanliness of the device and a firmware status of the device.
In an analogous art, Vidal teaches a fire detector incorporating a smoke sensor and volatile organic compound (VOC) / multi-gas sensor that evaluates environmental contamination (“dirty environments”) and adjusts sensitivity based on contamination levels: [0003]–[0004]: describes dirty environments and contaminant interference, [0009]: VOCs correlate with unwanted particulate/smoke contamination, [0053]–[0056]: VOC concentration used as an indicator of contamination and system reduces sensitivity accordingly, [0061]–[0062]: PM2.5, CO₂, and H₂ concentrations used to assess air quality and trigger maintenance alerts, and Fig. 1: fire detector includes VOC sensor 14 and multi-gas sensor used for contamination measurement. A person of ordinary skill in the art would immediately recognize this as a device cleanliness/contamination parameter, reflecting whether the detector is operating in a “clean” or “dirty” environment.
Therefore, a person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to incorporate Vidal’s contamination-sensing capability into Sahai’s (as modified by Ciasulli) remote monitoring platform because both references address fire-detection devices and their operational health. Sahai seeks to improve remote assessment of device conditions and maintenance needs, while Vidal teaches a known device-health parameter—environmental contamination—that directly affects detector performance and false-alarm rates. Adding Vidal’s contamination data to the set of parameters monitored in Sahai would predictably enhance accuracy and maintenance decision-making, fully aligning with Sahai’s stated goals. The combination requires no change to Sahai’s architecture, as Vidal’s contamination level is simply an additional device parameter processed like those Sahai already collects. Integrating such familiar, complementary features represents a straightforward improvement yielding predictable results.
However, Sahai in view of Ciasulli and Vidal does not expressly disclose a firmware status of the device.
In analogous art, Coop further teaches storing and tracking detailed component-level parameters such as revision level (firmware/configuration), serviceability status, installation date, life-limit/expiration information, date of last inspection, and various maintenance/test timestamps ([0035], [0040]–[0043], [0050]–[0051], [0067], [0071]–[0076]; Table 1 and Table 2). Coop explains that such parameters improve traceability, reduce maintenance errors, and support lifecycle management of safety-critical components.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Coop’s well-known maintenance, serviceability, revision, and lifecycle parameters into Sahai’s (as modified by Ciasulli and Vidal) existing device parameter model, since both systems track distributed safety-critical devices and report their health, status, inspections, and maintenance history. Coop’s parameters are simply additional fields associated with each device, readily stored in the same database Sahai already uses for health/inspection data and displayed through the same dashboards. Incorporating Coop’s timestamps and serviceability fields into Sahai’s device-level parameters—including firmware status, expiration/life-limit information, bypass/disabled/serviceability indicators, dates of last inspections, and dates of self-tests/environmental tests—would have been a straightforward and predictable enhancement that aligns with Sahai’s goals of improved maintenance visibility and reduced service errors.
Claim 14 is rejected under 35 U.S.C. §103 over Sahai (US 2021/0027613 A1) in view of Ciasulli (US 2016/0153806 A1), Vidal (US 2022/0172591 A1), and Coop (US 2007/0114280 A1) for the same reasons set forth with respect to claim 2. Claim 14 recites an apparatus including a display device, a memory, and a processor (see, e.g., Sahai Fig. 3; [0046]–[0047]) configured to perform the same operations recited in method claim 2. The limitations of claim 14 correspond directly to the steps of claim 2 in apparatus/functional form, and the scope and content of the recited features are substantially the same as those addressed in the rejection of claim 2.
Claim 20 is rejected under 35 U.S.C. §103 over Sahai (US 2021/0027613 A1) in view of Ciasulli (US 2016/0153806 A1), Vidal (US 2022/0172591 A1), and Coop (US 2007/0114280 A1) for the same reasons set forth with respect to claim 2. Claim 20 recites a computer-readable medium storing code executable by a processor (see, e.g., Sahai Fig. 3; [0046]–[0049]) that, when executed, performs the same operations recited in method claim 2. The limitations of claim 20 correspond to the steps of claim 2 in executable-code form, and the scope and content of these features are substantially the same as those addressed in the rejection of claim 2.
Claims 5, 6, 10, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sahai (US 2021/0027613 A1) in view of Ciasulli (US 2016/0153806 A1).
Regarding claim 5, Sahai in view of Ciasulli discloses the computer-implemented method of claim 4, but does not explicitly disclose further comprising causing, based on detecting the out-of-date status indication for the device, the fire detection system to place the device in a trouble condition. Sahai teaches detecting device-level conditions including expired, about-to-expire, unhealthy, disabled, low-battery, and communication-failure states (Sahai Fig. 2A, inventory 232; health data 224; [0035], [0037]–[0041]). Sahai further teaches that such conditions are treated as events or faults affecting the operational integrity of the system and are displayed to the user to guide maintenance and service decisions (Sahai Figs. 2A–2B; [0008], [0032]–[0035]). Sahai therefore teaches detecting out-of-date device status conditions (expired/about-to-expire) and treating device issues as trouble-type events.
Sahai does not explicitly describe placing a device into a trouble condition in response to detecting an out-of-date status. However, it would have been obvious to a person of ordinary skill in the art to configure Sahai’s (as modified by Ciasulli) fire control panels so that out-of-date device status (e.g., expired, about-to-expire, overdue inspection, or other maintenance-required conditions identified in inventory 232 and inspection statuses 228) is annunciated as a trouble condition. Sahai emphasizes the importance of enabling technicians to remotely determine the severity and nature of system issues and to coordinate and prioritize maintenance activities ([0008]–[0009]). Treating an out-of-date or expired device as a trouble condition ensures that such conditions are surfaced, logged, and prioritized using the same mechanisms Sahai already employs for other panel-reported device problems (faults, disablements, failures). This modification aligns directly with Sahai’s stated goals, employs the same event-handling framework Sahai already uses, and would have predictably improved remote maintenance visibility in the manner Sahai describes.
Regarding claim 6, Sahai in view of Ciasulli discloses the computer-implemented method of claim 5, but does not explicitly disclose wherein the fire detection system maintains operation of the device in the trouble condition in a limited or full operational state until the device is upgraded or replaced with another device. As explained in the rejection of claim 5, Sahai teaches detecting out-of-date or expired device conditions and treating such device issues as trouble-type events surfaced to the user (Sahai Figs. 2A–2B; health data 224; inventory 232; [0008], [0032]–[0041]). Sahai further teaches that devices experiencing faults, disablements, or maintenance conditions remain part of the monitored system and continue reporting health, inspection, and test progression data over time (Sahai Figs. 2A, 2D; inspection statuses 228; active test details 242).
Although Sahai does not expressly state maintaining operation of a device in a trouble condition “in a limited or full operational state,” it would have been obvious to a person of ordinary skill in the art to configure Sahai’s (as modified by Ciasulli) system so that a device flagged as out-of-date (per claim 5) continues operating until upgraded or replaced. Sahai expressly emphasizes remote assessment of issue severity, avoidance of unnecessary urgent visits, and coordinated scheduling of maintenance ([0008]–[0009]). Maintaining the device in service—rather than disabling it immediately—directly supports those objectives and uses the same monitoring and event-handling logic Sahai already applies to other device faults and maintenance states. The result is predictable and consistent with Sahai’s maintenance-planning framework.
Regarding claim 10, Sahai in view of Ciasulli discloses the computer-implemented method of claim 1, but does not explicitly disclose wherein the dashboard includes the first indication as a color code representing the overall system health indicator. Specifically, Sahai teaches displaying, via a dashboard interface, an overall health indicator of system status (Sahai Figs. 2A–2B; [0032]–[0035], [0037]–[0041]). However, Sahai does not explicitly disclose that the first indication is displayed as a color code representing the overall system health indicator.
Color-coded health/status indicators were well-known in the art and are a predictable, widely adopted technique for conveying severity or status information in graphical dashboards for safety-critical systems. A person of ordinary skill in the art would have been motivated to implement Sahai’s (as modified by Ciasulli) health indicator using a color-coded representation to improve clarity and allow technicians to more rapidly assess system state, consistent with Sahai’s stated objectives of enabling efficient remote evaluation of event severity and system health ([0008]–[0009]). Incorporating a color-coded visual cue would require only routine modification of the displayed indicator in Sahai’s existing dashboard UI and would predictably enhance usability without altering Sahai’s underlying architecture.
Claim 17 is rejected under 35 U.S.C. §103 over Sahai in view of Ciasulli for the same reasons set forth with respect to claim 5. Claim 17 recites an apparatus including a display device, a memory, and a processor (see, e.g., Sahai Fig. 3; [0046]–[0047]) configured to perform the same operations recited in method claim 5. The limitations of claim 17 correspond directly to the steps of claim 5 in apparatus/functional form, and the scope and content of the recited features are substantially the same as those addressed in the rejection of claim 5.
Claims 8, 9, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sahai (US 2021/0027613 A1) in view of Ciasulli (US 2016/0153806 A1) and Coop (US 2007/0114280 A1).
Regarding claim 8, Sahai in view of Ciasulli discloses the computer-implemented method of claim 1, but does not expressly disclose further comprising displaying, via the interface and based on detecting addition of one or more devices to, or removal of one or more devices from, the fire detection system, a prompt to create an inventory change log identifying one or more parameters related to addition of one or more devices to, or removal of one or more devices from, the fire detection system. Sahai discloses tracking device connection state changes and accepting technician maintenance entries (Sahai Fig. 2A, inventory 232; [0037]–[0041]; Figs. 2A–2E; [0032]–[0035], [0043]–[0046]).
In analogous art, Coop teaches a maintenance tracking system for distributed safety-critical components in which technicians must enter specific change-related information at the time of device addition or removal. When a component is removed, Coop teaches that the mechanic is "required to identify the component as unserviceable...noting when and why it was removed" (Coop, [0075]), with captured parameters including date and time removed, operating conditions, reason for removal, and an unserviceable signal (Coop, Table 3, [0075]). At the time of installation, the mechanic enters installation data including date, time, and conditions (Coop, [0079]). These entries are stored as part of an ongoing component maintenance history via an interactive reader/programmer display (Coop, [0034], [0066]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the Sahai/Ciasulli combination to display, based on detecting addition or removal of devices, a prompt to create an inventory change log identifying parameters related to the addition or removal, as taught by Coop. Sahai already detects device connection state changes and accepts technician maintenance entries ([0040], [0043]-[0045]); Coop supplies the structured workflow of capturing change-specific parameters (reason, date/time, conditions) at the time of addition or removal as part of a persistent maintenance history. A person of ordinary skill in the art would have been motivated to apply this workflow to Sahai's fire detection system because, as Coop expressly teaches, such structured data entry "greatly reduces the need for repetitive information entries typical of the paper environment, which also reduces human error in data entry" (Coop, [0067]), yielding the predictable result of automated change-log creation upon detected device addition or removal.
Claim 18 is rejected under 35 U.S.C. §103 over Sahai in view of Ciasulli and Coop for the same reasons set forth with respect to claim 8. Claim 18 recites an apparatus including a display device, a memory, and a processor (see, e.g., Sahai Fig. 3; [0046]–[0047]) configured to perform the same operations recited in method claim 8. The limitations of claim 18 correspond directly to the steps of claim 8 in apparatus/functional form, and the scope and content of the recited features are substantially the same as those addressed in the rejection of claim 8.
Regarding claim 9, Sahai in view of Ciasulli discloses the computer-implemented method of claim 1, but does not expressly disclose further comprising displaying, via the interface and based on detecting modification of one or more of the multiple devices, a prompt to create an inventory change log identifying one or more parameters related to modification of the one or more of the multiple devices. Sahai discloses detecting modification of devices and providing technician interfaces for entering maintenance, inspection, and test data (Sahai Figs. 2A–2E; [0032]–[0035], [0043]–[0045]), including notifications when a technician starts or ends maintenance on a device ([0043]), active test details with pass/fail status per device ([0044]), and maintenance details entered by the technician during the modification ([0045]).
In analogous art, Coop teaches that technicians performing maintenance, repair, or modification on safety-critical components are required to enter structured information about the change as part of an ongoing maintenance history. Coop expressly teaches that "Each maintenance activity performed on RFID tagged parts may be added as data stored on the RFID tag to create an audit trail" and that "Maintenance procedures would include updating the tag each time that a maintenance and/or inspection operation is conducted on a tagged part" (Coop, [0040]). Coop further teaches that captured modification related parameters include date and time of maintenance, technician identification, the nature of the modification performed, and operating conditions at the time of the change (Coop, [0066]–[0067], [0070]–[0075], Tables 1-3), all accessible through an interactive reader/programmer display (Coop, [0066]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the Sahai/Ciasulli combination to display, based on detecting modification of one or more devices, a prompt to create an inventory change log identifying parameters related to the modification, as taught by Coop. Sahai already detects device modification events and accepts technician maintenance entries ([0043]–[0045]); Coop supplies the structured workflow of capturing modification-specific parameters as part of a persistent audit trail. A person of ordinary skill in the art would have been motivated to apply this workflow to Sahai's fire detection system because, as Coop expressly teaches, such structured data entry "greatly reduces the need for repetitive information entries typical of the paper environment, which also reduces human error in data entry" (Coop, [0067]), yielding the predictable result of automated change-log creation upon detected device modification.
Response to Arguments
Applicant’s arguments have been considered but are moot because the arguments do not apply to new combination of references including new prior art being used in the current rejection. The new grounds of rejection are necessitated by amendment.
Conclusion
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 RAJSHEED O BLACK-CHILDRESS whose telephone number is (571)270-7838. The examiner can normally be reached M to F, 10am to 5pm.
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, Quan-Zhen Wang can be reached at (571) 272-3114. 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.
/RAJSHEED O BLACK-CHILDRESS/Examiner, Art Unit 2685
/QUAN ZHEN WANG/Supervisory Patent Examiner, Art Unit 2685
Prosecution Insights