DETAILED ACTION
Claims 1 – 10 and 12 – 20 have been amended.
Claims 1 – 20 have been examined and are pending.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3, 8 – 12, 14 and 19 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication No. 2010/0164736 to Byers et al. (hereinafter Byers) in view of US Patent No. 6,456,306 to Chin et al. (hereinafter Chin).
Regarding Claim 1, Byers discloses (¶11) a method for managing a power consumption state of a status indicator light in a network device, which further includes:
computing system (Byers discloses (¶67 and Fig. 5) discloses a system 500 to control a power mode of a status indicator light) one or more non-transitory computer-readable media comprising instructions executable by the one or more programmable processors to cause the computing system to: (Byers discloses (¶23, ¶68) management system 502 includes memory in communication with processors) obtain network information of a network device wherein the network device includes at least one visual indicator (Byers discloses (¶35) an activity LED may blink to indicate network traffic activity. Further, Byers discloses (¶46) a network link failure, or software component failure, abnormally intermittent or low network data throughput, link parity error, or other abnormal operation. A system error status or condition may be used to trigger normal LED operation to assist an operator in troubleshooting and diagnosing the source of the error status or condition)
determine a network event based on the network information (Byers discloses (¶43) event may be an environmental event, a user-generated event, a system-generated event, or other types of events, such as an error)
instruct, based on the network event, the network device to configure the at least one visual indicator as active or inactive (Byers discloses (¶39) when an error condition or network event is detected (e.g., ¶35: network traffic activity, or ¶46: network link failure, abnormally intermittent or low network data throughput, link parity error) then the system error status or condition may be used to trigger normal LED operation, and one or more status indicator lights may be enabled. The disabling and re-enabling may be configurable. The indicator light may be disabled after a period of inactivity or use. Re-enabling the status indicator light may occur after one or more conditions or triggering events are detected.)
Byers does not explicitly disclose wherein to determine the network event comprises a determination of whether at least one network link of the network device is not included in an active route configured in the network device. However, in an analogous art, Chin teaches:
wherein to determine the network event comprises a determination of whether at least one network link of the network device is not included in an active route configured in the network device (Chin teaches (¶Col. 10, Lines 25-55 and Fig. 8: 860) a visual GUI display with overall health status of each network device. In addition, however, window 800 allows the network manager to view at a glance the state of the six fault categories for a given network device by selecting the device icon representing the device, e.g., device icon 821, a router. Upon selecting device icon 821, state information for the router appears in state detail pane 860. Thus, the network manager is able to quickly glance at a depiction of the selected device's state severity levels, including the connectivity events, errors, components, load, security and issues with (the network link / network route) configurations).
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine computing system one or more non-transitory computer-readable media comprising instructions executable by the one or more programmable processors to cause the computing system to: obtain network information of a network device wherein the network device includes at least one visual indicator, determine a network event based on the network information, instruct, based on the network event, the network device to configure the at least one visual indicator as active or inactive, as disclosed by Byers, and wherein to determine the network event comprises a determination of whether at least one network link of the network device is not included in an active route configured in the network device, as taught by Chin, for the purpose of implementing (¶Col. 1, Lines 22-25) network management systems for displaying information regarding network devices and objects of an enterprise-wide computer network.
Claim 3, Byers in view of Chin disclose all the elements of claim 1. Further they disclose:
wherein the network information includes configuration information of one or more links of the network device, and wherein to determine the network event based on the network information, instructions cause the computing system to: determine, based on the configuration information, that at least one network link of the network device is at least one of incompletely configured, incorrectly configured, or a combination thereof (Chin teaches (¶Col. 10, Lines 25-55 and Fig. 8: 860) a visual GUI display where upon selecting the device icon 821, state information for the router appears in state detail pane 860, and it shows the selected device's state severity levels, including the connectivity events, errors, components, load, security and issues with (the network link / network route) configurations).
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 8, Byers and Chin disclose all the elements of claim 1. Further they disclose:
wherein the network event comprises a first network event, and wherein the instructions cause the computing system to determine a second network event based on the network information, wherein the second network event comprises a hot plug network event (Byers teaches (¶46) system error event may be related to a hardware component failure, a network link failure, or software component failure, and events such as abnormally intermittent or low network data throughput, link parity error. Upon detection, the system error status or condition may be used to trigger normal LED operation, and one or more status indicator lights may be enabled.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 9, Byers and Chin disclose all the elements of claim 1. Further they disclose:
wherein the instructions cause the computing system to: determine, based on the hot plug network event (Byers teaches (¶46) system error event may be related to a hardware component failure, a network link failure, or software component failure), that an administrator is not within a proximity of the network device (Byers teaches (¶45) the user is not present or in proximity of the network device, thus the status indicator lights are not needed), and wherein to instruct the network device to configure the at least one visual indicator, the instructions cause the computing system to configure, based on the determination that the administrator is not within the proximity of the network device, the at least one visual indicator as inactive (Byers teaches (¶45) when a user accesses the computer terminal remotely (i.e., the user is not in proximate to the network device) the computer terminal or the network device is configured to detect this type of remote access and differentiate it from a local access, in which case the status indicator lights are not transitioned 108 to a normal power consumption state 104.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 10, Byers and Chin disclose all the elements of claim 1. Further they disclose:
wherein the instructions further cause the computing system to: apply a time domain filter (Byers teaches (¶24) processor being operable to: determine a timeout period) to the network event (Byers teaches (¶43) event may be an environmental event, a user-generated event, a system-generated event, or other types of events, such as an error), wherein the time domain filter filters a plurality of network events based on a corresponding duration of each network event of the plurality of network events (Byers teaches (¶39) the disabling and re-enabling may be configurable, for example, using administrative control software. As an example, the indicator light may be disabled after a period of inactivity or use, such as a timeout period. The timeout period may be configurable. Re-enabling the status indicator light may occur after one or more conditions or triggering events are detected. The configuration may also be used to determine (¶48) a timeout period, an expiration period, an active period, or other time-based event to trigger the transition from a first power consumption to a second power consumption state.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 11, Byers and Chin disclose all the elements of claim 1. Further they disclose:
wherein the network device comprises the one or more programmable processors (Byers teaches (¶78-¶79) a network device implemented via computer system 600 with programmable processors, memory and status indicator lights.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 12, do not teach or further define over the limitations in claim 1. Therefore, claim 12 is rejected for the same rationale of rejection as set forth in claim 1.
Claim 14, do not teach or further define over the limitations in claim 3. Therefore, claim 14 is rejected for the same rationale of rejection as set forth in claim 3.
Claim 19, do not teach or further define over the limitations in claim 9. Therefore, claim 19 is rejected for the same rationale of rejection as set forth in claim 9.
Claim 20, do not teach or further define over the limitations in claim 1. Therefore, claim 20 is rejected for the same rationale of rejection as set forth in claim 1.
Claims 2, 4, 13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication No. 2010/0164736 to Byers in view of US Patent No. 6,456,306 to Chin, and further in view of US Patent Application Publication No. 2022/0229738 to Murti et al. (hereinafter Murti).
Claim 2, Byers in view of Chin disclose all the elements of claim 1. Further they disclose:
wherein the network information includes forwarding information of the network device wherein to determine the network event based on the network information (Byers teaches (¶46) system-generated network event notifications may include events such as error events, alert events. A system error event may be related to a hardware component failure, a network link failure, or software component failure, in various examples. A system alert event may include events or conditions such as low available memory, abnormally intermittent or low network data throughput, link parity error, or other abnormal operation), the instructions cause the computing system to: (Byers teaches (¶79) teaches a computer system 600 includes a processor and memory)
Byers in view of Chin does not explicitly disclose determine, based on the forwarding information that at least one network link of the network device is not included in the active route configured in the network device and wherein to instruct the network device to configure the at least one visual indicator as active or inactive, the instructions cause the computing system to instruct, based on a determination that the at least one network link is not included in the active route configured in the network device, the network device to configure the at least one visual indicator as inactive, wherein the at least one visual indicator is associated with the at least one network link. However, in an analogous art, Murti teaches:
determine, based on the forwarding information that at least one network link of the network device is not included in the active route configured in the network device and wherein to instruct the network device to configure the at least one visual indicator as active or inactive, the instructions cause the computing system to instruct, based on a determination that the at least one network link is not included in the active route configured in the network device, the network device to configure the at least one visual indicator as inactive, wherein the at least one visual indicator is associated with the at least one network link (Murti teaches (¶82 – ¶85 and Fig. 9) connectors from one device to other devices is displayed to reflect the device connectivity characteristic through a visual GUI representation of the connector. This connectivity characteristic can comprise any relevant parameter, such as link speed, maximum transmission unit (MTU) (i.e., the largest packet size that can be sent over the connection), device latency, and device bandwidth. Thus, links between devices can be shown with lines of different weights and colors such as thinner or thicker lines to indicate relative transmission speeds or signal quality. Each device display area includes visual elements to show certain information pertaining to the device, configuration, performance, protection status, and provides at-a-glance information such as success/warnings/failures of jobs (e.g., backup, restore, replication, etc.) related to devices connected to that network device. The graph is coded so that it quickly provides visual indicators of relevant device and network parameters, for example, indicate relative congestion of the device with the other connected devices and actual numerical statistics for the jobs, and a health score for the device. The health score is generated using simple rules that factor the relevant configuration and job statistics. Scores can be compiled on factors such as software version, device age, sensor health, and so on, and can utilize additive or subtractive operations to derive an overall score. Nested GUI layers may be used to provide different points of view, such that clicking on a particular device icon dynamically reloads the table to show the same view, but for the next level of devices. In Fig. 9: 900, for example, clicking on “router 3” would update the view to show only the devices in the Denver datacenter, including the switches connected to Router 3. This display would then leverage the information from the DP software's catalog, i.e., the other asset sources (e.g., VM hypervisors, DB servers, etc.) connected to those network devices. Other similar known GUI mechanisms may also be used, depending on system configuration and use.)
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine the network information includes forwarding information of the network device wherein to determine the network event based on the network information, the instructions cause the computing system to, as disclosed by Byers in view of Chin, and determine, based on the forwarding information that at least one network link of the network device is not included in the active route configured in the network device and wherein to instruct the network device to configure the at least one visual indicator as active or inactive, the instructions cause the computing system to instruct, based on a determination that the at least one network link is not included in the active route configured in the network device, the network device to configure the at least one visual indicator as inactive, wherein the at least one visual indicator is associated with the at least one network link, as taught by Murti, for the purpose of implementing (¶2) visually mapping network topographies and protection status.
Claim 4, Byers, Chin and Murti disclose all the elements of claim 2. Further they disclose:
wherein to determine that the at least one network link is not included in the active route configured in the network device instructions cause the computing system to: determine, based on the forwarding information, that the at least one network link is included in the active route configured in the network device, wherein the active route has relatively low activity.
(Byers teaches (¶46) system alert event may include events or conditions such as a network link failure, abnormally intermittent or low network data throughput, link parity error, or other abnormal operation and further, Byers teaches (¶2) link status indicator lights may provide information regarding the link condition, such as "in service," "active," "busy," "error," or link speed.)
The motivation to combine the references is similar to the reasons in Claim 2.
Claim 13, do not teach or further define over the limitations in claim 2. Therefore, claim 13 is rejected for the same rationale of rejection as set forth in claim 2.
Claim 15, do not teach or further define over the limitations in claim 4. Therefore, claim 15 is rejected for the same rationale of rejection as set forth in claim 4.
Claims 5 – 6 and 16 – 17 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication No. 2010/0164736 to Byers, in view of US Patent No. 6,456,306 to Chin, and further in view of US Patent No. 11,438,211 to Lyubomirsky et al. (hereinafter Lyubomirsky).
Claim 5, Byers and Chin disclose all the elements of claim 1. Further they disclose:
wherein to determine the network event based on the network information (Byers teaches (¶43) event may be an environmental event, a user-generated event, a system-generated event, or other types of events, such as an error), the instructions cause the computing system to:
wherein to instruct the network device to configure the at least one visual indicator as inactive or active, the instructions cause the computing system to instruct the network device to configure the at least one visual indicator as inactive, wherein the at least one visual indicator is associated with the inactive network link (Byers discloses (¶39) when an error condition or network event is detected (e.g., ¶35: network traffic activity, or ¶46: network link failure, abnormally intermittent or low network data throughput, link parity error) then the system error status or condition may be used to trigger normal LED operation, and one or more status indicator lights may be enabled. The disabling and re-enabling may be configurable. The indicator light may be disabled after a period of inactivity or use. Re-enabling the status indicator light may occur after one or more conditions or triggering events are detected)
Byers in view of Chin does not explicitly disclose determine, based on providing the network information to a machine learning (ML) model, a stability score of at least one network link of the network device, determine, based on a determination that the stability score of the at least one network link satisfies a predetermined threshold, that the at least one network link is an inactive network link. However, in an analogous art, Lyubomirsky teaches:
determine, based on providing the network information (Lyubomirsky (¶Col. 5, Lines 22 -25) teaches that network management apparatus uses network performance and operating parameters information to monitor and improve performance) to a machine learning (ML) model (Lyubomirsky (¶Col. 5, Lines 62 -65) inference module 212 generates failure event probability determinations and likelihood of various link failure mechanisms, degradation or failure of certain components, etc. by using machine learning techniques using the telemetry collected by and received from communication interface 211), a stability score of at least one network link of the network device (Lyubomirsky teaches (¶Col. 6, Lines 51 -55) telemetry values (i.e. stability score, based on collected telemetry measurements) associated with link quality and reliability of data communications)
determine, based on a determination that the stability score (Lyubomirsky ¶Col. 6, Lines 51 -55: telemetry values) of the at least one network link satisfies a predetermined threshold, that the at least one network link is an inactive network link (Lyubomirsky teaches (Fig. 4 and ¶Col. 9, Lines 3 -27) during the machine learning and training process using the initial threshold values to report on network performance and reliability and to determine the likelihood of physical link failure or quality issues based on a large number of network link data inputs i.e., telemetry measurements)
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine to determine the network event based on the network information, the instructions cause the computing system to: wherein to instruct the network device to configure the at least one visual indicator as inactive or active, the instructions cause the computing system to instruct the network device to configure the at least one visual indicator as inactive, wherein the at least one visual indicator is associated with the inactive network link, as disclosed by Byers in view of Chin, and determine, based on providing the network information to a machine learning (ML) model, a stability score of at least one network link of the network device, determine, based on a determination that the stability score of the at least one network link satisfies a predetermined threshold, that the at least one network link is an inactive network link, as taught by Lyubomirsky, for the purpose of implementing (¶Col. 1, Lines 50-55) network device that collects telemetry measurements related to the quality of data communication and uses a machine learning algorithm to generates probability determinations using the telemetry measurements and an inference model. The probability determinations are used to generate alarms signals or activate repair algorithms.
Claim 6, Byers, Chin and Lyubomirsky disclose all the elements of claim 5. Further they disclose:
wherein the network information includes at least one of: alert statistics of the at least one network link, alarm statistics of the at least one network link, view statistics of a user monitoring the status of the at least one network link, or query statistics of the link, or a combination thereof (Lyubomirsky teaches (¶Col. 5, Lines 22-35) the collected telemetry received data includes link failure and slowdown warnings and other information from multiple network entities. Telemetry refers to measurements related to performance of data computation, and these measurements may include direct measurements (e.g., signal strength, amount of noise, etc.) and metrics calculated from direct measurements (e.g., jitter, FEC statistics, SNR variation over time, PAM4 histogram (if PAM4 protocol is used), equalization taps, and others.)
The motivation to combine the references is similar to the reasons in Claim 5.
Claim 16, do not teach or further define over the limitations in claim 5. Therefore, claim 16 is rejected for the same rationale of rejection as set forth in claim 5.
Claim 17, do not teach or further define over the limitations in claim 6. Therefore, claim 17 is rejected for the same rationale of rejection as set forth in claim 6.
Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication No. 2010/0164736 to Byers, in view of US Patent No. 6,456,306 to Chin, and further in view of US Patent Application Publication No. 2019/0158312 to Junkin et al. (hereinafter Junkin).
Claim 7, Byers in view of Chin disclose all the elements of claim 1. Further they disclose:
wherein to determine the network event based on the network information, the instructions cause the computing system to: (Byers teaches (¶43) event may be an environmental event, a user-generated event, a system-generated event, or other types of events, such as an error. Further, Byers teaches (¶79) teaches computer processor)
Byers in view of Chin does not explicitly disclose determine a virtual local area network (VLAN) associated with the network event, wherein the VLAN includes a plurality of network links including the at least one network link, and wherein to instruct the network device to configure the at least one visual indicator, the instructions cause the computing system to: configure each visual indicator associated the plurality of network links of the VLAN in an active state and each visual indicator not associated with a link of the VLAN in an inactive state. However, in an analogous art, Junkin teaches:
determine a virtual local area network (VLAN) associated with the network event (Junkin teaches (¶8) a suspect event related to the users of VLAN), wherein the VLAN includes a plurality of network links including the at least one network link (Junkin teaches (¶29 and ¶36) VLAN refers to virtual local area network, a network segmentation of digital data separating Ethernet traffic exchanged over multiple interfaces), and wherein to instruct the network device to configure the at least one visual indicator (Junkin teaches (¶32) when not in use, a green light indicates a lack of data exchange between the devices, and when the device detects traffic, the indicator light 110 emits a red color), the instructions cause the computing system to: configure each visual indicator associated the plurality of network links of the VLAN in an active state and each visual indicator not associated with the VLAN in an inactive state (Junkin teaches (¶36) detecting the traffic on the VLAN, and detecting audio and video data transmissions and registering such activity on an externally visible green/red indicator light 110, thereby allowing a proximate network user, such as a company employee, to recognize a potential security breach.)
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine to determine the network event based on the network information, the instructions cause the computing system to, as disclosed by Byers in view of Chin, and determine a virtual local area network (VLAN) associated with the network event, wherein the VLAN includes a plurality of network links including the at least one network link, and wherein to instruct the network device to configure the at least one visual indicator, the instructions cause the computing system to: configure each visual indicator associated the plurality of network links of the VLAN in an active state and each visual indicator not associated with a link of the VLAN in an inactive state, as taught by Junkin, for the purpose of implementing (¶2) a countersurveillance system.
Claim 18, do not teach or further define over the limitations in claim 7. Therefore, claim 18 is rejected for the same rationale of rejection as set forth in claim 7.
Response to Arguments
Claim Rejections - 35 USC § 103
Applicant’s arguments and amendments, filed on 04/21/2026 with respect to the Claims 1 – 20 have been fully considered and they are persuasive. Hence, the 35 USC § 103 rejection is withdrawn. However, based on the claim amendments and the newly introduced limitations, the search is updated and a new reference, US Patent No. 6,456,306 to Chin et al. has been introduced for the 35 USC § 103 rejection.
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 HASSAN ABDUR-RAHMAN KHAN whose telephone number is (313)446-6574. The examiner can normally be reached TEAPP - (M-Sa) 9/30/17-9/30/18, 6am-10pm IFP.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry can be reached at (571) 272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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.
/H. A. K./
Examiner, Art Unit 2451
/GLENFORD J MADAMBA/Primary Examiner, Art Unit 2451
Prosecution Insights