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 .
Claims 1-9 are presented for examination.
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-3, 6-8 are rejected under 35 U.S.C. 103 as being unpatentable over Oliveira et al. U.S. Patent Application Publication Number 2023/0034229 A1 (hereinafter Oliveira), and further in view of Nagatani et al. U.S. Patent Application Publication Number 2025/0193099 A1 (hereinafter Nagatani).
As per claim 1, Oliveira discloses an alarm system for monitoring network devices on a virtualization platform (see observability intelligence platform for monitoring network environments on page 3 section [0038]), the alarm system comprising:
at least one monitoring server (see agents 310 installed on network devices and servers on page 3 section [0038] and Figure 3), arranged on at least one client platform (see agents 310 installed on monitored client network devices and servers on page 3 section [0038] and Figure 3) and configured to monitor network devices on the at least one client platform (see agents used to monitor devices of a client on page 3 section [0038]), comprising:
a log managing module configured to receive logs (see agent passively monitor activities on page 3 section [0037]) sent by the network devices and determine whether the logs contain an alarm event (to be taught by Nagatani);
a status testing module configured to regularly send a test signal to each of the network devices and determine whether the network devices are in operation based on a test response returned by the network devices (see agent run tests and probe packets to determining response from monitored network devices on page 4 section [0039]);
a status monitoring module configured to receive status information of the network devices (see analyzing and troubleshooting the monitored environment on page 4 section [0040]) and determine whether the network devices are in an abnormal status (to be taught by Nagatani);
a signal transmission module connected to the log managing module, the status testing module, and the status monitoring module and configured to send out information received by the log managing module, the status testing module, and the status monitoring module from the network devices and information generated by the log managing module, the status testing module, and the status monitoring module (see agent, or monitoring server as claimed, all send monitored performance data and reports to controller 320, or collection device as claimed, on page 4 section [0040]); and
a connection device (see controller 320, or collection device as claimed, receiving performance data and reports on page 4 section [0040]) connected to the log managing module, the status testing module, the status monitoring module, and the network devices and configured to send the test signal to the network devices and receive the test response (see controller 320, or collection device as claimed, receiving performance data and reports on page 4 section [0040]), the logs, and the status information transmitted by the network devices, wherein the connection device comprises:
an actively receiving module configured to obtain the status information from the network devices (see actively running test and probe packets and receive response from the network devices on page 4 section [0039]) based on a simple network management protocol (SNMP) and provide the status information for the status monitoring module (see to be taught by Nagatani); and
a passively receiving module configured to receive the logs sent by the network devices (see passively monitoring activities of the network device on page 3 section [0037]) based on a system logging protocol (Syslog) and provide the logs for the log managing module (see to be taught by Nagatani); and
a cloud server connected to the at least one monitoring server through the signal transmission module and configured to receive and store information sent by the signal transmission module (see network monitored platform is deployed on a cloud server on page 7 section [0067] and see received monitored data is stored on a database 106 working in conjunction with the servers 104 as part of the cloud-based service on page 2 section [0020] and Figure 1).
Oliveira do not disclose expressly: a log managing module configured to receive logs (see agent passively monitor activities on page 3 section [0037]) sent by the network devices and determine whether the logs contain an alarm event.
Oliveira do not disclose expressly: a status monitoring module configured to receive status information of the network devices and determine whether the network devices are in an abnormal status.
Oliveira do not disclose expressly: an actively receiving module configured to obtain the status information from the network devices (see actively running test and probe packets and receive response from the network devices on page 4 section [0039]) based on a simple network management protocol (SNMP) and provide the status information for the status monitoring module.
Oliveira do not disclose expressly: a passively receiving module configured to receive the logs sent by the network devices (see passively monitoring activities of the network device on page 3 section [0037]) based on a system logging protocol (Syslog) and provide the logs for the log managing module.
Nagatani teaches: a log managing module configured to receive logs sent by the network devices and determine whether the logs contain an alarm event (see checking log information to determine if network device is in inoperative state, or alarm event as claimed, on page 2 section [0028] and see determine an abnormality cause to network device on page 4 section [0044]).
Nagatani teaches: a status monitoring module configured to receive status information of the network devices and determine whether the network devices are in an abnormal status (see checking log information to determine if network device is in inoperative state, or alarm event as claimed, on page 2 section [0028] and see determine an abnormality cause to network device on page 4 section [0044]).
Nagatani teaches: an actively receiving module configured to obtain the status information from the network devices based on a simple network management protocol (SNMP) and provide the status information for the status monitoring module (see use of Simple Network Management Protocol (SNMP) to determining status of the network device on page 2 section [0029]).
Nagatani teaches: a passively receiving module configured to receive the logs sent by the network devices based on a system logging protocol (Syslog) and provide the logs for the log managing module (see use of syslog, or system logging protocol (Syslog) as claimed, to determining status of the network device on page 2 section [0029]).
Oliveira and Nagatani are analogous art because they are from a same field of endeavor, network monitoring systems. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art use log data from System Logging Protocol and Simple Network Management Protocol (SNMP) to determine the status of the network device. The motivation for doing so would have been to use well known network management tool (see page 2 section [0029] in Nagatani). Therefore, it would have been obvious to combine Oliveira and Nagatani for the benefit of using syslog and Simple Network Management Protocol to manage network devices to obtain the invention as specified in claim 1.
As per claim 2, Oliveira and Nagatani disclose the alarm system for monitoring network devices on a virtualization platform according to claim 1, wherein the log managing module is configured to set keywords and determine whether the logs include at least one of the keywords to determine whether there is the alarm event (see determine an abnormality cause to network device by analyzing specific character string in the log, or keywords as claimed, on page 4 section [0044] in Nagatani). The motivation to combine is same as above.
As per claim 3, Oliveira and Nagatani disclose the alarm system for monitoring network devices on a virtualization platform according to claim 1, wherein the signal transmission module in the at least one monitoring server is connected to the cloud server through a web server interface (WebAPI) (see cloud-based and web-based services such as monitoring services using web server interface on page section [0032] on page 3 section [0032] in Oliveira). The motivation to combine is same as above.
As per claim 6, Oliveira and Nagatani disclose the alarm system for monitoring network devices on a virtualization platform according to claim 1, wherein the at least one client server is implemented with identical or different virtualization platforms (see deploying different types of agents for different virtualization platforms for serving different agent operations on page 3 section [0036] and see different agent used on different locations and different networks on page 3 section [0034] in Oliveira). The motivation to combine is same as above.
As per claim 7, Oliveira and Nagatani disclose the alarm system for monitoring network devices on a virtualization platform according to claim 1, wherein the status monitoring module is further configured to determine whether number of the network devices has been expanded based on the status information of the network devices, and when the number of the network devices is expanded, computing resources of the monitoring server are correspondingly expanded (see network monitoring can be implemented on different devices and utilizing additional devices on page 5 section [0049] in Oliveira). The motivation to combine is same as above.
As per claim 8, Oliveira and Nagatani disclose the alarm system for monitoring network devices on a virtualization platform according to claim 7, wherein the computing resources of the monitoring server include number of cores of at least one central processor and capacities of at least one memory and at least one hard disk space (see collecting information on processor core usage, memory usage, and hardware information such as hard disk space on page 3 section [0036] in Oliveira). The motivation to combine is same as above.
Claims 4-5, 9 are rejected under 35 U.S.C. 103 as being unpatentable over Oliveira et al. U.S. Patent Application Publication Number 2023/0034229 A1 (hereinafter Oliveira),further in view of Nagatani et al. U.S. Patent Application Publication Number 2025/0193099 A1 (hereinafter Nagatani). and further in view of Nagatani et al., and further in view of Liu et el. U.S. Patent Number 10,419,310 B1 (hereinafter Liu).
As per claims 4 and 5, Oliveira and Nagatani do not disclose expressly: alarm system for monitoring network devices on a virtualization platform according to claims 1, wherein the signal transmission module is configured to send information received by the log managing module, the status testing module, and the status monitoring module from the network devices and information generated by the log managing module, the status testing module, and the status monitoring module to the cloud server by e-mail.
Liu teaches: wherein the signal transmission module is configured to send information received by the log managing module, the status testing module, and the status monitoring module from the network devices and information generated by the log managing module, the status testing module, and the status monitoring module to the cloud server by e-mail (see determining potential problem generated from monitoring and add a desired action based on profile such as an email notification on column 11 line 1-9).
Oliveira and Liu are analogous art because they are from a same field of endeavor, network monitoring systems. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art use email notification on identified network issues. The motivation for doing so would have been to use remove network issues (see column 11 line 1-9 in Liu). Therefore, it would have been obvious to combine Oliveira and Nagatani and Liu for the benefit of using email as status notification to obtain the invention as specified in claims 4 and 5.
As per claim 9, Oliveira and Nagatani disclose the alarm system for monitoring network devices on a virtualization platform according to claim 1, wherein when the cloud server receives the alarm event or information related to abnormal statuses of the network devices, the cloud server automatically sends a dispatch notification to equipment maintenance personnel (see determining potential problem generated from monitoring and add a desired action based on profile such as an email notification to an equipment maintenance personnel on column 11 line 1-9 in Liu). The motivation to combine is same as above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Shaw et al. U.S. Patent Application Publication Number 2019/0238591 A1. SNMP request for network device management (see section [0105]).
Schlachet U.S. Patent Application Publication Number 2019/0080306 A1. Monitoring device configuration with monitoring server (see Abstract).
Markowitz et al. U.S. Patent Application Publication Number 2017/0180192 A1. Monitoring and management of network device (see Abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN S CHOU whose telephone number is (571)272-5779. The examiner can normally be reached Monday-Friday 9:00-5:00 EST.
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, Chris L 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.
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.
/ALAN S CHOU/Primary Examiner, Art Unit 2451
Prosecution Insights