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 .
DETAILED OFFICE ACTION
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 2024-03-22 in compliance with the provisions of 37 CFR 1.97 has been considered by the examiner and made of record in the application file.
Claim Status
Claims 1-6 are pending in this Office Action. No claims have been allowed.
Claim Rejections – 35 U.S.C. § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for the 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.
As reiterated by the Supreme Court in KSR, and as set forth in MPEP 2141 (R-01.2024), II, the factual inquiries of Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), applied for establishing a background for determining obviousness under 35 U.S.C. §103, are summarized as follows:
Determining the scope and content of the prior art;
Ascertaining the differences between the prior art and the claims at issue;
Resolving the level of ordinary skill in the pertinent art; and
Considering objective evidence indicative of obviousness or non-obviousness, if present.
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 C.F.R. § 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,4,5 and 6 are rejected under 35 U.S.C. §103 as being unpatentable over Derakhshan et al. (WO2014000987A1) in view of Ginter et al. (US 7,246,156 B2).
Claim 1
Derakhshan teaches a network entity providing event subscription/notifications (control functionality), “According to a first aspect embodiments provide a network entity of a communication network, wherein the communication network comprises a plurality of network entities or elements, such as computing or processing entities, processing resource management entities, routing control entities, or the like. Said network entity, which may regarded as an originating network entity, comprises an interface which is operable to provide (e.g. transmit), to an event publishing network entity/element of the communication network, an event subscription message comprising information identifying said originating network entity and comprising one or more configuration rules for configuring a configurable event of interest at the event publishing network entity, wherein the configurable event of interest shall be reported from the event publishing network entity to the originating network entity. Further, the (originating) network entity may comprise an interface, such as e.g. a receiver interface, which is operable to provide (e.g. receive) the configurable event of interest from the event publishing network entity to said originating network entity. In other words, the originating (or subscribing) network entity, which may be a resource management entity, a network routing controller, or a signal processing entity of the network or a domain thereof, may define, re-define or update an event of interest ( or parameters thereof) or its reporting modalities by setting up or updating one or more event configuration rules of the event subscription message.” [Derakhshan, Summary].
Derakhshan further teaches obtaining event notification messages at a configured notification frequency, “an acquisitor unit configured to acquire information from a distributed station that notifies the information related to one or more events occurred within a predetermined time period at a predetermined notification frequency”, “ For example, a notification frequency may be set to "l" in order to obtain an event notification message 160 once (per second) from the respective event publishing network entity 150. This may be referred to as pull- or period-based EPSIE. A specific value for the "notification frequency" may e.g. automatically trigger related values for other event subscription parameters. For example, notification frequency = "l" may lead to sending the subscribe message 110 with default values for one or more other parameters, e.g. event threshold = NULL, event hysteresis = NULL, event granularity = NULL, trigger for event notification = NULL, time to trigger = NULL, etc. The latter parameters are optional and do not need to be explicitly defined in the event subscription message 110. If a non-mandatory parameter is not specified it may be set to NULL. The "notification contenf-parameter of the message 110 may be set to the event or status information of interest, e.g., "available processing resources". In this case the event notification message 160 may return the instantaneous situation or status with respect to the status information of interest ( e.g. available processing resources) at the event publishing network entity 150. That is to say, the event publishing network entity 150 may return its current status with respect to the event of interest, e.g. "available processing resources= 52 %". Likewise, the notification frequency may be set to "10" in order to obtain ten event notification messages 160 (per second) from the respective event publishing network entity 150 with respect to the specified information of interest.” [Derakhshan, Description of Embodiments].
In an analogous art, Derakhshan teaches processing/analysis of event information for network control decisions, “an information analyser configured to execute analysis processing on the information”, “The event notification 160 may automatically be transmitted to the event subscribers 100 as soon as the previously-configured profile conditions are satisfied, for example, event attributes, notification frequency, etc. The enhanced publish-subscribe information exchange according to embodiments may allow to adjust the notification frequency and the size of the notification message 160 to an optimum, for example, in dependence of a current link or processor load situation. The clients 100 may calibrate their communication with the servers 150 according to their needs by updating the corresponding entries in their message subscription profiles 110. By decoupling the information exchange from the time-critical decision phase the proposed concept may enable a client 100 to apply more advanced and more complex resource allocation algorithms resulting in a higher resource optimization quality. The enhanced publish-subscribe information exchange may abstract conventional request/response mechanisms, for example, if the notification frequency is set to "1" in the subscription profile (see description above). In this case a general status information of interest may be retrieved from the specified network node. In other words, the conventional request/response information exchange may be regarded as a special case of the proposed enhanced publish/subscribe information exchange.” [Derakhshan, Description of Embodiments].
Derakhshan teaches notification frequency expressed as messages per second (occurrence frequency), “a frequency derivator configured to derive an occurrence frequency of the information”, “For example, a notification frequency may be set to "l" in order to obtain an event notification message 160 once (per second) from the respective event publishing network entity 150. This may be referred to as pull- or period-based EPSIE. A specific value for the "notification frequency" may e.g. automatically trigger related values for other event subscription parameters. For example, notification frequency = "l" may lead to sending the subscribe message 110 with default values for one or more other parameters, e.g. event threshold = NULL, event hysteresis = NULL, event granularity = NULL, trigger for event notification = NULL, time to trigger = NULL, etc. The latter parameters are optional and do not need to be explicitly defined in the event subscription message 110. If a non-mandatory parameter is not specified it may be set to NULL. The "notification contenf-parameter of the message 110 may be set to the event or status information of interest, e.g., "available processing resources". In this case the event notification message 160 may return the instantaneous situation or status with respect to the status information of interest ( e.g. available processing resources) at the event publishing network entity 150. That is to say, the event publishing network entity 150 may return its current status with respect to the event of interest, e.g. "available processing resources= 52 %". Likewise, the notification frequency may be set to "10" in order to obtain ten event 10 notification messages 160 (per second) from the respective event publishing network entity 150 with respect to the specified information of interest.” [Derakhshan, Description of Embodiments].
Derakhshan further teaches configurable events related to load situations and distributing processing load based on reported events, “a load derivator configured to derive a load of analysis processing of the information”, “ For example, a first processing unit or the resource management entity may subscribe to an individually defined processing-capabilityrelated event, which may be published from a second processing unit of the network, to which a corresponding event subscription message has directly or indirectly been sent from the interested event subscribing network first processing unit. Hence, the configurable event of interest may e.g. be related to a load situation at the event publishing network entity. In this case the originating or subscribing network entity may further comprise a load controller which is operable to distribute processing load among the plurality of network entities based on the reported event of interest” [Derakhshan, Summary].
In an analogous art Derakhshan teaches adjusting the notification frequency to an optimum dependent on processor load, “a frequency controller configured to control the predetermined notification frequency”, “The event notification 160 may automatically be transmitted to the event subscribers 100 as soon as the previously-configured profile conditions are satisfied, for example, event attributes, notification frequency, etc. The enhanced publish-subscribe information exchange according to embodiments may allow to adjust the notification frequency and the size of the notification message 160 to an optimum, for example, in dependence of a current link or processor load situation. The clients 100 may calibrate their 1 0 communication with the servers 150 according to their needs by updating the corresponding entries in their message subscription profiles 110……………. The enhanced publish-subscribe information exchange may abstract conventional request/response mechanisms, for example, if the notification frequency is set to "1" in the subscription profile (see description above). In this case a general status information of interest may be retrieved from the specified network node. In other words, the conventional request/response information exchange may be regarded as a special case of the proposed enhanced publish/subscribe information exchange” [Derakhshan, Description of Embodiments].
Derakhshan does not expressly teach sending notifications at successive intervals that increase approximately exponentially However, in an analogous art, Ginter teaches sending notifications at successive intervals that increase approximately exponentially, thereby reducing effective notification frequency below the event/occurrence rate under persistent conditions. “a frequency lower than the occurrence frequency as an upper limit on the basis of at least one of an analysis result of the information, an occurrence frequency of the information, and a load of analysis processing of the information.”, “In accordance with another aspect of the invention is a computer program product for event notification comprising code that: receives a first report of a condition; sends a first notification message about said first report of said condition; sends a second notification message about said condition at a first notification interval; receives subsequent reports at fixed time intervals; and sends a subsequent notification message at a second notification interval if said condition is still ongoing during said second notification interval, wherein said second notification interval has a length which is a multiple of said first notification interval. The first report may be sent from a reporting agent on a first computer system reporting about one of: said first computer system and a network including said first computer system, and said notification messages are sent from a notification server on a second computer system. Notification messages may be sent to a notification point at successive notification intervals wherein each of said successive notification intervals increases approximately exponentially with respect to an immediately prior notification interval. The condition may be associated with an alarm condition and an alarm condition is set when a current level of a metric is not in accordance with a predetermined threshold value. Each of the notification messages may include a first level of information about said condition and a second level of information used to perform at least one of the following: determine a cause of said condition, and take a corrective action for said condition. An option may be included in a reporting agent to enable and disable reporting of said second level of information to a notification server from said agent sending said first report. An option may be used to enable and disable condition notification messages including said second level of information. An alarm condition may be associated with a first level alarm and an alarm state of said first level is maintained when a current level of a metric is in accordance with said predetermined threshold value until an acknowledgement of said alarm state at said first level is received by said notification server. The alarm condition may transition to a second level alarm when said current level is not in accordance with said predetermined threshold and another threshold associated with a second level, and said second level alarm may be maintained when a current level of a metric is in accordance with one of: said predetermined threshold and said other threshold until acknowledgement of said second level alarm is received by said notification server. Reports may be sent from a reporting agent executing on a computer system in an industrial network to an appliance included in said industrial network and each of said reports includes events occurring within said industrial network. An alarm condition may be determined in accordance with a plurality of weighted metrics, said plurality of weighted metrics including at least one metric about: a network intrusion detection, a network intrusion prevention, a number of failed login attempts, a number of users with a level of privileges greater than a level associated with a user-level account.” [Ginter, SUMMARY OF THE INVENTION, Colum 7-8]
Ginter further teaches determining frequency within a reporting period “Threat thermostat change-An embodiment may indicate an alarm condition when a change occurs to the threat thermostat setting. The change may be the result of a manual change, an automated change in accordance with the functionality included in an embodiment. Additional detail for enhanced reporting may include what user made the change, what was the status changed to/from, the frequency that such changes have been made within a reporting period, identify the uses that most frequently changed the setting and what percentage of the time each user changed the setting. NIDS and Ips reports-An address or other identifying source of the most frequent alerted NIDS/Ips conditions, an associated percentage of these conditions attributed to a particular source, information about the type of attack, and the target of the attack (what machine by host name, IP address and the like). Anti-virus events-The metric may identify a total number of antivirus events. Additional information may include a break down by type of event within a reporting period to identify what viruses (virus signatures) have been removed from a communication streams with an associated frequency or percentage, what source and/or destinations (such as source and destination networks) appeared most frequently for each type, and a frequency or percentage associated with each of the source and destinations. Other activity-This metric identifies other activity that does not belong in any other category. Additional information may include the text of the first one or more messages of this type detected. [Ginter, DETAILED DESCRIPTION OF EMBODIMENT(S), Colum 61-62].
One of ordinary skill in the art would have been motivated to combine Derakhshan’s load-dependent control of event notification frequency with Ginter’s throttling via exponentially increasing successive notification intervals to manage signaling/computation load while maintaining event awareness and timely reporting.
Therefore, claim 1 is unpatentable over Derakhshan in view of Ginter.
Claim 3
With respect to claim 3, all claim limitations are taught by Derakhshan and Ginter except wherein the notified information is discarded from storage when the occurrence frequency is less than a predetermined threshold value. However, within analogous art, Derakhshan teaches configurable event parameters including event thresholds, and a POSITA would have found it obvious to apply threshold-based filtering/discarding to reduce storage and analysis burden for low-occurrence information while prioritizing higher-value events.
Derakhshan teaches configurable event parameters that include event thresholds, supporting threshold-based decisions for event handling and filtering, “a storage processor configured to discard the notified information from the storage it when it is judged that the occurrence frequency of the information is less than a predetermined threshold value.” “The configurable event parameters eventpar may, for example, be event thresholds, an event hysteresis, an event granularity, triggers for event notification, a time to trigger, a notification frequency, a notification content, etc. According to the exemplary embodiment of Fig. 2 event notification content has been set to "0", such that the published event notification 160 only comprises the ID of the event publishing network entity 150-2. For example, a configurable event of interest could also be a Signal-to-Interference-plusNoise Ratio (SINR) above or below a given threshold for less or more than a given time threshold. Thereby, such threshold values may be configurable event parameters of the event subscription message 110. If the event subscribing network entity 100 is no longer interested in outdated event threshold values, it may, for example, issue a new or updated event subscription message 110 comprising its new event parameters of interest. Another example of an event of interest (see Fig. 2) could be a PWT (Processing Waiting Time) below or above a configurable waiting time threshold for more or less than a configurable time threshold. Also, those values or parameters could be changed or updated in order to fit the subscribed configurable event to the current interests of the event subscribing network entity 100. Some of the parameters of the event subscription message may be optional while others are mandatory. In some embodiments the ID of the event subscribing network entity 100 may be a mandatory parameter of the event subscription message 110.”,[Derakhshan, Description of Embodiments].
One of ordinary skill in the art would have been motivated to implement threshold-based discarding of low-frequency notified information in the Derakhshan/Ginter framework to reduce storage/processing overhead and to concentrate analysis resources on more significant or frequent events, consistent with the references’ express focus on load-aware optimization.
Therefore, claim 3 is unpatentable over Derakhshan in view of Ginter.
Claim 4
Derakhshan teaches a subscribing network entity (client) and publishing network entities exchanging event notifications “A communication system comprising a distributed station and a control device”, “For example, a notification frequency may be set to "l" in order to obtain an event notification message 160 once (per second) from the respective event publishing network entity 150. This may be referred to as pull- or period-based EPSIE. A specific value for the "notification frequency" may e.g. automatically trigger related values for other event subscription parameters. For example, notification frequency = "l" may lead to sending the subscribe message 110 with default values for one or more other parameters, e.g. event threshold = NULL, event hysteresis = NULL, event granularity = NULL, trigger for event notification = NULL, time to trigger = NULL, etc. The latter parameters are optional and do not need to be explicitly defined in the event subscription message 110. If a non-mandatory parameter is not specified it may be set to NULL. The "notification contenf-parameter of the message 110 may be set to the event or status information of interest, e.g., "available processing resources". In this case the event notification message 160 may return the instantaneous situation or status with respect to the status information of interest ( e.g. available processing resources) at the event publishing network entity 150.” [Derakhshan, Description of Embodiments]
Derakhshan further teaches event publishing entities sending notifications at configured notification frequency (messages per second), “the distributed station comprises a notification processor that notifies information related to one or more events occurred within a predetermined time period at a predetermined notification frequency”, “…………...In this case the event notification message 160 may return the instantaneous situation or status with respect to the status information of interest ( e.g. available processing resources) at the event publishing network entity 150. That is to say, the event publishing network entity 150 may return its current status with respect to the event of interest, e.g. "available processing resources= 52 %". Likewise, the notification frequency may be set to "10" in order to obtain ten event notification messages 160 (per second) from the respective event publishing network entity 150 with respect to the specified information of interest. Also, specifying the notification frequency to be "O" without any further parameter settings may delete a previous subscription (i.e. not to obtain any related published event notification 160) …………” [Derakhshan, Description of Embodiments].
Further, Derakhshan teaches the subscribing entity obtaining/receiving event notification messages “the control device comprises an acquisitor that acquires the information” “……… Whenever an event of interest, as defined by the event subscribing network entity or client 100 in the subscription profile 110, occurs, the event publishing network entity or server 150 may send a notification message 160 only to those subscribing entities who have expressed their interest in this event by previously sending their subscription profile 110. The notification message 160 may contain the type and the amount of information as configured or defined by the event subscribing network entity 100 in the event subscription message 110. The event notification or report 160 may either comprise a simple message indicating a change of the publishing entity's state or the entire state parameters. The content of the event notification 160 may have been configured beforehand by corresponding parameters in the event subscription message 110. For example, an event subscribing network entity 100 may be informed that a packet loss value or a buffer fill level of a certain event publishing network entity 150 has just fallen below a critical threshold value. Another example would be to inform an interested event subscribing network entity 100 that signal processing resources available at the respective event publishing network entity 150 are above a previously configured threshold value. That is to say, a published event notification 160 may include the event publishing network entity's ID, measured values, as for example a processing queue waiting time. Some parameters may be optional, while others may be mandatory. In some embodiments the ID of the reporting event publishing network entity 150 may be a mandatory parameter comprised by the notification 160. Additionally or alternatively, a notification frequency may be mandatory. In this way, the event subscribing network entity 100 may obtain knowledge on what is happening at the individual event publishing network entities 150……….” [Derakhshan, Description of Embodiments].
In an analogous art, Derakhshan teaches analysis/optimization based on link/processor load and event information “an information analyser that executes analysis processing on the information”, “…………. The event notification 160 may automatically be transmitted to the event subscribers 100 as soon as the previously-configured profile conditions are satisfied, for example, event attributes, notification frequency, etc. The enhanced publish-subscribe information exchange according to embodiments may allow to adjust the notification frequency and the size of the notification message 160 to an optimum, for example, in dependence of a current link or processor load situation. The clients 100 may calibrate their communication with the servers 150 according to their needs by updating the corresponding entries in their message subscription profiles 110. By decoupling the information exchange from the time-critical decision phase the proposed concept may enable a client 100 to apply more advanced and more complex resource allocation algorithms resulting in a higher resource optimization quality………”. [Derakhshan, Description of Embodiments].
Derakhshan further teaches notifications per second, “……a notification frequency may be set to "l" in order to obtain an event notification message 160 once (per second) from the respective event publishing network entity 150. This may be referred to as pull- or period-based EPSIE. A specific value for the "notification frequency" may e.g. automatically trigger related values for other event subscription parameters…...” [Derakhshan, Description of Embodiments].
In an analogous art, Derakhshan teaches events related to load situations and distributing processing load based on reported events “a load derivator that derives a load of analysis processing of the Information”, “Processing load information may be exchanged by making use of embodiments of the enhanced publish-subscribe concept. For example, a first processing unit or the resource management entity may subscribe to an individually defined processing-capability related event, which may be published from a second processing unit of the network, to which a corresponding event subscription message has directly or indirectly been sent from the interested event subscribing network first processing unit. Hence, the configurable event of interest may e.g. be related to a load situation at the event publishing network entity. In this case the originating or subscribing network entity may further comprise a load controller which is operable to distribute processing load among the plurality of network entities based on the reported event of interest.”, [Derakhshan, Summary]
Further, Derakhshan teaches adjusting notification frequency dependent on link/processor load “a frequency controller that controls the predetermined notification frequency with a frequency lower than the occurrence frequency as an upper limit on the basis of at least one of an analysis result of the information, an occurrence frequency of the information”, “……..event attributes, notification frequency, etc. The enhanced publish-subscribe information exchange according to embodiments may allow to adjust the notification frequency and the size of the notification message 160 to an optimum, for example, in dependence of a current link or processor load situation. The clients 100 may calibrate their communication with the servers……….” [Derakhshan, Description of Embodiments].
Derakhshan does not expressly teach frequency within a reporting period However, in an analogous art, Ginter teaches frequency within a reporting period “a frequency derivator that derives an occurrence frequency of the Information”, “Threat thermostat change-An embodiment may indicate an alarm condition when a change occurs to the threat thermostat setting. The change may be the result of a manual change, an automated change in accordance with the functionality included in an embodiment. Additional detail for enhanced reporting may include what user made the change, what was the status changed to/from, the frequency that such changes have been made within a reporting period, identify the uses that most frequently changed the setting and what percentage of the time each user changed the setting. NIDS and Ips reports-An address or other identifying source of the most frequent alerted NIDS/Ips conditions, an associated percentage of these conditions attributed to a particular source, information about the type of attack, and the target of the attack (what machine by host name, IP address and the like). Anti-virus events-The metric may identify a total number of antivirus events. Additional information may include a break down by type of event within a reporting period to identify what viruses (virus signatures) have been removed from a communication streams with an associated frequency or percentage, what source and/or destinations (such as source and destination networks) appeared most frequently for each type, and a frequency or percentage associated with each of the source and destinations. Other activity-This metric identifies other activity that does not belong in any other category. Additional information may include the text of the first one or more messages of this type detected. [Ginter, DETAILED DESCRIPTION OF EMBODIMENT(S), Colum 61-62].
Ginter further teaches exponentially increasing notification intervals to throttle frequency “a load of analysis processing of the information”, “………...Notification messages may be sent to a notification point at successive notification intervals wherein each of said successive notification intervals increases approximately exponentially with respect to an immediately prior notification interval. The condition may be associated with an alarm condition and an alarm condition is set when a current level of a metric is not in accordance with a predetermined threshold value. Each of the notification messages may include a first level of information about said condition and a second level of information used to perform at least one of the following: determine a cause of said condition, and take a corrective action for said condition. An option may be included in a reporting agent to enable and disable reporting of said second level of information to a notification server from said agent sending………………….” [Ginter, SUMMARY OF THE INVENTION, Colum 8]
One of ordinary skill in the art would have been motivated to combine Derakhshan’s load-dependent control of event notification frequency with Ginter’s throttling via exponentially increasing successive notification intervals to manage signaling/computation load while maintaining event awareness and timely reporting in a distributed event-notification system.
Therefore, claim 4 is unpatentable over Derakhshan in view of Ginter.
Claim 5
Derakhshan teaches receiving event notification messages at a configured notification frequency, “acquiring information from a distributed station that notifies the information related to one or more events occurred within a predetermined time period at a predetermined notification frequency”, “………...For example, a notification frequency may be set to "l" in order to obtain an event notification message 160 once (per second) from the respective event publishing network entity 150. This may be referred to as pull- or period-based EPSIE. A specific value for the "notification frequency" may e.g. automatically trigger related values for other event subscription parameters. For example, notification frequency = "l" may lead to sending the subscribe message 110 with default values for one or more other parameters, e.g. event threshold = NULL, event hysteresis = NULL, event granularity = NULL, trigger for event notification = NULL, time to trigger = NULL, etc. The latter parameters are optional and do not need to be explicitly defined in the event subscription message 110. If a non-mandatory parameter is not specified it may be set to NULL. The "notification contenf-parameter of the message 110 may be set to the event or status information of interest, e.g., "available processing resources". In this case the event notification message 160 may return the instantaneous situation or status with respect to the status information of interest ( e.g. available processing resources) at the event publishing network entity 150. That is to say, the event publishing network entity 150 may return its current status with respect to the event of interest, e.g. "available processing resources= 52 %". Likewise, the notification frequency may be set to "10" in order to obtain ten event notification messages 160 (per second) from the respective event publishing network entity 150 with respect to the specified information of interest. Also, specifying the notification frequency to be "O" without any further parameter settings may delete a previous subscription (i.e. not to obtain any related published event notification 160) …………”, [Derakhshan, Description of Embodiments].
Derakhshan further teaches analysis/optimization based on link/processor load situation, “executing analysis processing on the information”, “The enhanced publish-subscribe information exchange according to embodiments may allow to adjust the notification frequency and the size of the notification message 160 to an optimum, for example, in dependence of a current link or processor load situation. The clients 100 may calibrate their communication with the servers 150 according to their needs by updating the corresponding entries in their message subscription profiles 110.” [Derakhshan, Description of Embodiments].
In an analogous art Derakhshan teaches messages per second, “deriving an occurrence frequency of the information”, “………a notification frequency may be set to "l" in order to obtain an event notification message 160 once (per second) from the respective event publishing network entity 150. This may be referred to as pull- or period-based EPSIE. A specific value for the "notification frequency" may e.g. automatically trigger related values for other event subscription parameters………...” [Derakhshan, Description of Embodiments].
Further, Derakhshan teaches events related to load situation and distributing processing load based on reported event information, “deriving a load of analysis processing of the information”, “For example, a first processing unit or the resource management entity may subscribe to an individually defined processing-capability related event, which may be published from a second processing unit of the network, to which a corresponding event subscription message has directly or indirectly been sent from the interested event subscribing network first processing unit. Hence, the configurable event of interest may e.g. be related to a load situation at the event publishing network entity. In this case the originating or subscribing network entity may further comprise a load controller which is operable to distribute processing load among the plurality of network entities based on the reported event of interest.” [Derakhshan, Summary].
Derakhshan teaches adjusting notification frequency to an optimum dependent on load, “controlling the predetermined notification frequency with a frequency lower than the occurrence frequency as an upper limit on the basis of at least one of an analysis result of the information, an occurrence frequency of the information, and a load of analysis processing of the information”, “ ……….allow to adjust the notification frequency and the size of the notification message 160 to an optimum, for example, in dependence of a current link or processor load situation………..” [Derakhshan, Description of Embodiments].
Derakhshan does not expressly teach exponentially increasing successive notification intervals to throttle frequency. However, in an analogous art, Ginter teaches exponentially increasing successive notification intervals to throttle frequency, “……... Notification messages may be sent to a notification point at successive notification intervals wherein each of said successive notification intervals increases approximately exponentially with respect to an immediately prior notification interval. The condition may be associated with an alarm condition and an alarm condition is set when a current level of a metric is not in accordance with a predetermined threshold value. Each of the notification messages may include a first level of information about said condition and a second level of information used to perform at least one of the following: determine a cause of said condition, and take a corrective action for said condition. An option may be included in a reporting agent to enable and disable reporting of said second level of information to a notification server from said agent sending…...”, [Ginter, Column 8]
Ginter further teaches associated frequency within a reporting period, “Anti virus events-The metric may identify a total number of antivirus events. Additional information may include a break down by type of event within a reporting period to identify what viruses (virus signatures) have been removed from a communication streams with an associated frequency or percentage, what source and/or destinations (such as source and destination networks) appeared most frequently for each type, and a frequency or percentage associated with each of the source and destinations.” [Ginter, Column 62].
One of ordinary skill in the art would have been motivated to combine Derakhshan’s configured event-notification acquisition and load-aware optimization with Ginter’s throttling via exponentially increasing successive notification intervals to control notification frequency under persistent conditions, thereby reducing overhead while preserving event reporting.
Therefore, claim 5 is unpatentable over Derakhshan in view of Ginter.
Claim 6
With respect to claim 6, all claim limitations are taught by Derakhshan and Ginter except wherein Claim 6 recites a non-transitory computer-readable medium storing instructions that cause a computer to execute the functions of claim 1. In an analogous art, Ginter expressly teaches a “computer program product for event notification comprising code that” performs receiving reports, sending notification messages at notification intervals, and sending subsequent notifications when a condition persists. “A non-transitory computer readable medium which stores a program for causing a computer to function as the control device”, “In accordance with another aspect of the invention is a computer program product for event notification comprising code that: receives a first report of a condition; sends a first notification message about said first report of said condition; sends a second notification message about said condition at a first notification interval; receives subsequent reports at fixed time intervals; and sends a subsequent notification message at a second notification interval if said condition is still ongoing during said second notification interval, wherein said second notification interval has a length which is a multiple of said first notification interval. The first report may be sent from a reporting agent on a first computer system reporting about one of: said first computer system and a network including said first computer system, and said notification messages are sent from a notification server on a second computer system. Notification messages may be sent to a notification point at successive notification intervals wherein each of said successive notification intervals increases approximately exponentially with respect to an immediately prior notification interval. The condition may be associated with an alarm condition and an alarm condition is set when a current level of a metric is not in accordance with a predetermined threshold value. Each of the notification messages may include a first level of information about said condition and a second level of information used to perform at least one of the following: determine a cause of said condition, and take a corrective action for said condition. An option may be included in a reporting agent to enable and disable reporting of said second level of information to a notification server from said agent sending said first report. An option may be used to enable and disable condition notification messages including said second level of information. An alarm condition may be associated with a first level alarm and an alarm state of said first level is maintained when a current level of a metric is in accordance with said predetermined threshold value until an acknowledgement of said alarm state at said first level is received by said notification server. The alarm condition may transition to a second level alarm when said current level is not in accordance with said predetermined threshold and another threshold associated with a second level, and said second level alarm may be maintained when a current level of a metric is in accordance with one of: said predetermined threshold and said other threshold until acknowledgement of said second level alarm is received by said notification server. Reports may be sent from a reporting agent executing on a computer system in an industrial network to an appliance included in said industrial network and each of said reports includes events occurring within said industrial network. An alarm condition may be determined in accordance with a plurality of weighted metrics, said plurality of weighted metrics including at least one metric about: a network intrusion detection, a network intrusion prevention, a number of failed login attempts, a number of users with a level of privileges greater than a level associated with a user-level account.” [Ginter, Column 7-8]. Such a computer program product inherently resides on a non-transitory computer-readable medium when stored (e.g., memory, disk), and when executed causes a computer system to perform the claimed control-device functions.
One of ordinary skill in the art would have been motivated to implement the Derakhshan/Ginter event-notification and throttling techniques as stored executable instructions on a non-transitory computer-readable medium (computer program product) to deploy the control functionality in network equipment and servers, which is a predictable and conventional implementation of network-control logic in software.
Therefore, claim 6 is unpatentable over Derakhshan in view of Ginter.
Claim 2 is rejected under 35 U.S.C. §103 as being unpatentable over Derakhshan et al. in view of Ginter et al. and further in view of Gerstel (US20150023663A1).
Claim 2
With respect to claim 2, all claim limitations are taught by Derakhshan and Ginter except wherein wavelength switching necessity is judged on the basis of the analysis result. However, within analogous art, Gerstel teaches receiving a signal to move communication off a first optical path before performance fails, which corresponds to judging and initiating optical-path switching based on analyzed conditions, as follows:
Gerstel teaches a router configured to receive a signal to move the communication off of a first optical path before performance has failed, and to establish a second optical path i.e., an optical-path switching decision responsive to monitored/analyzed conditions, “ a wavelength switching judge configured to judge whether or not wavelength switching of an optical signal transmitted through an optical path is necessary on the basis of the analysis result”, “ router over an IP path that includes an IP link that uses a first optical path. The router configured to proactively maintain the performance of the communication of data. The router configured to receive a signal to move the communication off of the first optical path, before performance of the first optical path has failed. The router configured to establish a second optical path to the destination router an associate the IP link with the second optical path and move the communication of data with the destination router to the second optical path. The router may optionally be configured to tear down the first optical path. The trigger received by the router may be an indication of a performance degradation of the first optical path or an indication of a router interface used by the IP link being switched into maintenance mode.” [Gerstel, Abstract].
One of ordinary skill in the art would have been motivated to use the analysis result of Derakhshan’s event/processing framework to trigger or judge optical-path switching as taught by Gerstel in order to proactively maintain performance and availability, particularly under load or degraded conditions, which is a predictable use of known network-management techniques.
Therefore, claim 2 is unpatentable over Derakhshan in view of Ginter, further in view of Gerstel.
It is noted that any citations to specific, pages, columns, lines, or figures in the prior art references and any interpretation of the reference should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See MPEP 2123.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohammed Abdelraheem, whose telephone number is (571) 272-0656. The examiner can normally be reached Monday–Thursday.
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, David Payne, can be reached at (571) 272-3024. 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.
/MOHAMMED ABDELRAHEEM/Examiner, Art Unit 2635
/DAVID C PAYNE/Supervisory Patent Examiner, Art Unit 2635