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 .
This office action is responsive to a response filed on April 27th, 2026. In this office action:
Claims 1-20 are pending.
Claims 1-20 are rejected.
Summary of Previous Office Action
In the Non-Final Office Action mailed on January 27th, 2026,
Claims 1, 6-7, 9, 14-15, 17 and 20 were rejected under 35 U.S.C. 103 as being unpatentable over Johnson et al. (Patent No. US 9,857,825), hereinafter Johnson; in view of Li et al. (Pub. No. US 20140067940), hereinafter Li; and further in view of Ardel et al. (Pub. No. US 2023/0325292), hereinafter Ardel.
Claims 2, 10, and 18 were rejected under 35 U.S.C. 103 as being unpatentable over Johnson et al. (Patent No. US 9,857,825), hereinafter Johnson; in view of Li et al. (Pub. No. US 20140067940), hereinafter Li; further in view of Ardel et al. (Pub. No. US 2023/0325292), hereinafter Ardel; and further in view of Gupta et al. (Pub. No. US 2012/0271916), hereinafter Gupta.
Claims 3-5, 11-13, and 19 were rejected under 35 U.S.C. 103 as being unpatentable over Johnson et al. (Patent No. US 9,857,825), hereinafter Johnson; in view of Li et al. (Pub. No. US 20140067940), hereinafter Li; further in view of Ardel et al. (Pub. No. US 2023/0325292), hereinafter Ardel; and further in view of Cawley et al. (Pub. No. US 2023/0291657), hereinafter Cawley.
Claims 8 and 16 were rejected under 35 U.S.C. 103 as being unpatentable over Johnson et al. (Patent No. US 9,857,825), hereinafter Johnson; in view of Li et al. (Pub. No. US 20140067940), hereinafter Li; further in view of Ardel et al. (Pub. No. US 2023/0325292), hereinafter Ardel; and further in view of Iyer et al. (Pub. No. US 2022/0043595), hereinafter Iyer.
Response to Amendment
The amendments filed on April 27th, 2026 have been entered.
Claims 1, 9, and 17 have been amended.
Response to Arguments
Applicant’s arguments filed on April 27th, 2026 have been fully considered, and are moot in view of the new grounds of rejection, as presented in this Office Action.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1, 6-7, 9, 14-15, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson et al. (Patent No. US 9,857,825), hereinafter Johnson; in view of Bates et al. (Pub. No. US 2017/0083929), hereinafter Bates; and further in view of Ibryam (Patent No. US 10,990,402).
Claim 1. Johnson discloses [a] system comprising:
a processor; and a memory that stores computer-executable instructions that, when executed by the processor (See Fig. 12; “Processor 1200” and “Memory 1212”), cause the processor to perform operations comprising
receiving, from a notification system (See Fig. 3; the system management component 302 and nodes 306), notification traffic data associated with at least one of notification requests or notifications to be processed by the notification system (See Col. 8 lines 19-38; anomaly detection component 303 may receive notifications (notification traffic data) of potential anomalies from various nodes within the network... See Col. 4 lines 36-67; the system management component 302 communicates with nodes 306 within the network 304 to provide forwarding instructions for data published by the various publishers. The nodes 306 forward the data published by the publishers (notifications to be processed by the notification system) through the network 304 to appropriate subscribers according to the latency and rate specified by the system management component 302 … the anomaly detection component 303 may also communicate with the nodes 306 in the network and receive notifications from the nodes 306 if data is not be received and/or forwarded at the specified rate and/or latency. See also Col. 3 lines 1-17 and Col. 8 lines 4-18. Examiner’s interpretation: It is known in the art that Pub/sub messages are notification(s), where the publisher sends message(s) to subscriber(s) on a specific topic, allowing for efficient distribution of notifications to interested parties. As taught by Johnson, the notification(s) received by the anomaly detection component 303 is associated with data published by publisher(s) to indicates potential anomalies dues to the data not being received and/or forwarded at the specified rate and/or latency. Therefore, the notification(s) received by the anomaly detection component 303 is a notification traffic data associated with notifications to be processed by the notification system),
determining whether the notification traffic data indicates an anomaly associated with any of the at least one of the notification requests or the notifications to be processed by the notification system (See Col. 8 lines 19-33; The anomaly detection component 303 may receive notifications of potential anomalies from various nodes within the network and assess whether an anomaly indeed exists, or may potentially exist if action is not taken, and also determine the likely source of the anomaly. For example, if a notice is received that the rate of data from publisher 1 308 that is being forwarded by a node does not satisfy the rate specified in the forwarding rules, the anomaly detection component 303 may determine whether other notices have been received from data along the path for publisher 1 308. Based on a collection of information from multiple nodes and/or stand-alone components monitoring the nodes, the anomaly detection component 303 can assess whether an anomaly exists and the likely source of the anomaly (determining whether the notification traffic data indicates an anomaly associated with the notifications)), and
in response to determining that the notification traffic data indicates an anomaly associated with the notifications to be processed by the notification system, generating a first anomaly notification identifying the anomaly, and providing the first anomaly notification to the notification system while the notifications are being processed by the notification system (See Col. 8 lines 33-38; Once an anomaly has been detected and the likely source determined, the anomaly detection component 303 may communicate with the system management component 302 (generating and providing the anomaly notification to the system management component 302) and the publication of data may be modified to ensure that the QoS for each potentially effected subscriber is not violated. See also Col. 6 lines 46-59; The anomaly detection component communicate with the system management component 303 to assess whether action needs to be taken to ensure the QoS for each subscriber is maintained. See Abstract; The failure detection component may identify an anomaly within the network and a source of the anomaly. Based on the identified anomaly, data rates and or data paths may be adjusted in real-time. See also Col. 8 lines 39-52. Examiner’s interpretation: upon anomaly detection, the anomaly detection component communicates with the system management component (i.e., processing the publication of data) to modify (adjust) the publication of data (notifications) in order to maintain/ensure QoS of the publication of data (providing the anomaly notification to the notification system while the notifications being processed by the notification system));
wherein the anomaly identified by the first anomaly notification comprises a bias in a distribution of the notifications to a subscriber associated with the notification system (See Col. 8 lines 4-38; Each node within the network, or stand-alone components that monitor the nodes, may utilize the forwarding rules to monitor network traffic and notify the anomaly detection component 303 of potential anomalies. In some implementations, traffic coming into a node on an incoming connection may be monitored to determine if it is being received in a manner consistent with the forwarding rules … The anomaly detection component 303 may receive notifications of potential anomalies from various nodes within the network and assess whether an anomaly indeed exists, or may potentially exist if action is not taken, and also determine the likely source of the anomaly. For example, if a notice is received that the rate of data from publisher 1 308 that is being forwarded by a node does not satisfy the rate specified in the forwarding rules, the anomaly detection component 303 may determine whether other notices have been received from data along the path for publisher 1 308 (or other published data along the path). Based on a collection of information from multiple nodes and/or stand-alone components monitoring the nodes, the anomaly detection component 303 can assess whether an anomaly exists and the likely source of the anomaly. Once an anomaly has been detected and the likely source determined, the anomaly detection component 303 may communicate with the system management component 302 and the publication of data may be modified to ensure that the QoS for each potentially effected subscriber is not violated. Examiner’s interpretation: A “bias in distribution” is reasonably interpreted as inconsistency with the forwarding rules when publishing to subscribers).
Johnson doesn’t explicitly disclose determining whether the notification traffic data indicates an anomaly using at least one machine learning model; wherein the bias in the distribution of the notifications comprises the subscriber associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system, and wherein the notification system determines, in response to the first anomaly notification, that content associated with at least one of the notifications is similar to content associated with at least one other notification of the notifications and merges the at least one of the notifications with the at least one other notification in response to determining that the content associated with the at least one of the notifications is similar to the content associated with the at least one other notification.
However, Bates discloses determining whether the notification traffic data indicates an anomaly using at least one machine learning model (See Parag. [0016]; “intelligent alerting” refers to an automated process that employs machine learning to create individually tailored alerts and associated thresholds for users based on a variety of factors, including, for example, user behavior, consumption patterns, and anomaly detection. The alerts are communicated to the user and context is automatically provided for the alert); and wherein the notification system determines, in response to the first anomaly notification, that content associated with at least one of the notifications is similar to content associated with at least one other notification of the notifications and merges the at least one of the notifications with the at least one other notification in response to determining that the content associated with the at least one of the notifications is similar to the content associated with the at least one other notification (See Parag. [0068]; Related alerts of the selected alerts are combined or deduplicated, at step 314. Related alerts represent the same macro event. For example, alerts may be triggered for decreased revenue, decreased sales, decreased conversions, and the like. However, each of these items may be tied to the same event ... Rather than providing a user multiple alerts for the same event many times over the course of a reporting period, these alerts can be combined or deduplicated. In this way, alert fatigue can be greatly reduced by reducing the number of alerts for a single macro event. See also Parag. [0076]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the anomaly detection system, taught by Johnson, to include determining whether the notification traffic data indicates an anomaly using at least one machine learning model, and wherein the notification system determines, in response to the first anomaly notification, that content associated with at least one of the notifications is similar to content associated with at least one other notification of the notifications and merges the at least one of the notifications with the at least one other notification in response to determining that the content associated with the at least one of the notifications is similar to the content associated with the at least one other notification, as taught by Bates. This would be convenient such that alert fatigue can be greatly reduced by reducing the number of alerts (Bates, Parag. [0068]).
Johnson in view of Bates doesn’t explicitly disclose wherein the bias in the distribution of the notifications comprises the subscriber associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system.
However, Ibryam discloses wherein the bias in the distribution of the notifications comprises the subscriber (“consumer 152”) associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system (See Col. 6 lines 47-67; received maximum cache limits individualized to each respective consumer enable a message broker to deliver a quantity of messages or data to a consumer that the consumer will be able to process. Additionally, the individualized maximum cache limits may also help avoid a message broker underutilizing a particular consumer. For example, a message broker 110 configured to transmit a set maximum limit of 25 messages transmits 25 messages to the consumer 150, transmits 25 messages to the consumer 152, and transmits 25 messages to the consumer 154. At this point in time, the consumer 150 has a maximum cache limit of 30 messages and is able to process the received 25 messages, but the consumer 152 has a maximum cache limit of 20 messages and thus the received 25 messages uses 100% of its memory causing the consumer 152 to fail to process the messages).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the bias in the distribution of the notifications, taught by Johnson in view of Bates, to comprise the subscriber associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system, as taught by Ibryam. This would be convenient to maximize the system's overall message processing efficiency; and balancing the throughput and latency of each respective consumer to determine the best message distribution among the consumers to minimize the occurrence of messages idling in a consumer's cache to reduce overall latency and may maximize the concurrent processing of messages to increase overall throughput (Ibryam, Col. 14 lines 6-17).
Claim 6. Johnson in view of Bates and Ibryam discloses [t]he system of claim 1,
Johnson further discloses wherein the anomaly notification comprises information identifying the notifications associated with the anomaly (See Col. 8 lines 33-38; Once an anomaly has been detected and the likely source determined, the anomaly detection component 303 may communicate with the system management component 302 (providing the anomaly notification to the system management component 302) and the publication of data (notifications) may be modified to ensure that the QoS for each potentially effected subscriber is not violated. See also Col. 6 lines 46-59 and Col. 8 lines 39-52. Examiner’s interpretation: The anomaly detection component notifies the system management component in order to modify publication of data (notifications). Therefore, the notification comprises information identifying the notifications associated with the anomaly to be modified).
Claim 7. Johnson in view of Bates and Ibryam discloses [t]he system of claim 1,
Johnson further discloses wherein the operations further comprise in response to determining that the notification traffic data indicates an anomaly associated with at least one of the notification requests to be processed by the notification system: generating a second anomaly notification; and providing the second anomaly notification to the notification system while the at least one of the notification requests is being processed by the notification system (See Col. 4 lines 36-67; the system management component 302 communicates with nodes 306 within the network 304 to provide forwarding instructions for data published by the various publishers (notification requests). The nodes 306 forward the data published by the publishers (notifications to be processed by the notification system) through the network 304 to appropriate subscribers according to the latency and rate specified by the system management component 302 … See Col. 8 lines 33-38; Once an anomaly has been detected and the likely source determined, the anomaly detection component 303 may communicate with the system management component 302 (generating and providing the anomaly notification to the system management component 302) and the publication of data may be modified to ensure that the QoS for each potentially effected subscriber is not violated. See also Col. 6 lines 46-59; The anomaly detection component communicate with the system management component 303 to assess whether action needs to be taken to ensure the QoS for each subscriber is maintained. See Abstract; The failure detection component may identify an anomaly within the network and a source of the anomaly. Based on the identified anomaly, data rates and or data paths may be adjusted in real-time. See also Col. 8 lines 39-52. Examiner’s interpretation: upon anomaly detection, the anomaly detection component communicates with the system management component (i.e., processing the publication of data) to modify (adjust) the publication of data (notifications) in order to maintain/ensure QoS of the publication of data (providing the anomaly notification to the notification system while the notifications being processed by the notification system)).
Claim 9. Johnson discloses [a] method comprising:
receiving, by a notification traffic anomaly detector, from a notification system (See Fig. 3; the system management component 302 and nodes 306), notification traffic data associated with at least one of notification requests or notifications to be processed by the notification system (See Col. 8 lines 19-38; anomaly detection component 303 (notification traffic anomaly detector) may receive notifications (notification traffic data) of potential anomalies from various nodes within the network... See Col. 4 lines 36-67; the system management component 302 communicates with nodes 306 within the network 304 to provide forwarding instructions for data published by the various publishers. The nodes 306 forward the data published by the publishers (notifications processed by the notification system) through the network 304 to appropriate subscribers according to the latency and rate specified by the system management component 302 … the anomaly detection component 303 may also communicate with the nodes 306 in the network and receive notifications from the nodes 306 if data is not be received and/or forwarded at the specified rate and/or latency. See also Col. 3 lines 1-17 and Col. 8 lines 4-18. Examiner’s interpretation: It is known in the art that Pub/sub messages are notification(s), where the publisher sends message(s) to subscriber(s) on a specific topic, allowing for efficient distribution of notifications to interested parties. As taught by Johnson, the notification(s) received by the anomaly detection component 303 is associated with data published by publisher(s) to indicates potential anomalies dues to the data not being received and/or forwarded at the specified rate and/or latency. Therefore, the notification(s) received by the anomaly detection component 303 is a notification traffic data associated with notifications processed by the notification system),
determining, by the notification traffic anomaly detector, whether the notification traffic data indicates an anomaly associated with any of the at least one of the notification requests or the notifications to be processed by the notification system (See Col. 8 lines 19-33; The anomaly detection component 303 may receive notifications of potential anomalies from various nodes within the network and assess whether an anomaly indeed exists, or may potentially exist if action is not taken, and also determine the likely source of the anomaly. For example, if a notice is received that the rate of data from publisher 1 308 that is being forwarded by a node does not satisfy the rate specified in the forwarding rules, the anomaly detection component 303 may determine whether other notices have been received from data along the path for publisher 1 308. Based on a collection of information from multiple nodes and/or stand-alone components monitoring the nodes, the anomaly detection component 303 can assess whether an anomaly exists and the likely source of the anomaly (determining whether the notification traffic data indicates an anomaly associated with the notifications)), and
in response to determining that the notification traffic data indicates an anomaly associated with the notifications to be processed by the notification system, generating, by the notification traffic anomaly detector, a first anomaly notification identifying the anomaly, and providing, by the notification traffic anomaly detector, the first anomaly notification to the notification system while the notifications are being processed by the notification system (See Col. 8 lines 33-38; Once an anomaly has been detected and the likely source determined, the anomaly detection component 303 may communicate with the system management component 302 (generating and providing the anomaly notification to the system management component 302) and the publication of data may be modified to ensure that the QoS for each potentially effected subscriber is not violated. See also Col. 6 lines 46-59; The anomaly detection component communicate with the system management component 303 to assess whether action needs to be taken to ensure the QoS for each subscriber is maintained. See Abstract; The failure detection component may identify an anomaly within the network and a source of the anomaly. Based on the identified anomaly, data rates and or data paths may be adjusted in real-time. See also Col. 8 lines 39-52. Examiner’s interpretation: upon anomaly detection, the anomaly detection component communicates with the system management component (i.e., processing the publication of data) to modify (adjust) the publication of data (notifications) in order to maintain/ensure QoS of the publication of data (providing the anomaly notification to the notification system while the notifications being processed by the notification system));
wherein the anomaly comprises a bias in a distribution of the notifications to a subscriber associated with the notification system (See Col. 8 lines 4-38; Each node within the network, or stand-alone components that monitor the nodes, may utilize the forwarding rules to monitor network traffic and notify the anomaly detection component 303 of potential anomalies. In some implementations, traffic coming into a node on an incoming connection may be monitored to determine if it is being received in a manner consistent with the forwarding rules … The anomaly detection component 303 may receive notifications of potential anomalies from various nodes within the network and assess whether an anomaly indeed exists, or may potentially exist if action is not taken, and also determine the likely source of the anomaly. For example, if a notice is received that the rate of data from publisher 1 308 that is being forwarded by a node does not satisfy the rate specified in the forwarding rules, the anomaly detection component 303 may determine whether other notices have been received from data along the path for publisher 1 308 (or other published data along the path). Based on a collection of information from multiple nodes and/or stand-alone components monitoring the nodes, the anomaly detection component 303 can assess whether an anomaly exists and the likely source of the anomaly. Once an anomaly has been detected and the likely source determined, the anomaly detection component 303 may communicate with the system management component 302 and the publication of data may be modified to ensure that the QoS for each potentially effected subscriber is not violated. Examiner’s interpretation: A “bias in distribution” is reasonably interpreted as inconsistency with the forwarding rules when publishing to subscribers).
Johnson doesn’t explicitly disclose that the notification traffic anomaly detector comprising a processor; determining, by the notification traffic anomaly detector, whether the notification traffic data indicates an anomaly using at least one machine learning model; wherein the bias in the distribution of the notifications comprises the subscriber associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system, and wherein the notification system determines, in response to the first anomaly notification, that content associated with at least one of the notifications is similar to content associated with at least one other notification of the notifications and merges the at least one of the notifications with the at least one other notification in response to determining that the content associated with the at least one of the notifications is similar to the content associated with the at least one other notification.
However, Bates discloses the notification traffic anomaly detector comprising a processor (See Parag. [0041]; “processor”); determining, by the notification traffic anomaly detector, whether the notification traffic data indicates an anomaly using at least one machine learning model (See Parag. [0016]; “intelligent alerting” refers to an automated process that employs machine learning to create individually tailored alerts and associated thresholds for users based on a variety of factors, including, for example, user behavior, consumption patterns, and anomaly detection. The alerts are communicated to the user and context is automatically provided for the alert); and wherein the notification system determines, in response to the first anomaly notification, that content associated with at least one of the notifications is similar to content associated with at least one other notification of the notifications and merges the at least one of the notifications with the at least one other notification in response to determining that the content associated with the at least one of the notifications is similar to the content associated with the at least one other notification (See Parag. [0068]; Related alerts of the selected alerts are combined or deduplicated, at step 314. Related alerts represent the same macro event. For example, alerts may be triggered for decreased revenue, decreased sales, decreased conversions, and the like. However, each of these items may be tied to the same event ... Rather than providing a user multiple alerts for the same event many times over the course of a reporting period, these alerts can be combined or deduplicated. In this way, alert fatigue can be greatly reduced by reducing the number of alerts for a single macro event. See also Parag. [0076]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the anomaly detection system, taught by Johnson, to include determining, by the notification traffic anomaly detector, whether the notification traffic data indicates an anomaly using at least one machine learning model, and wherein the notification system determines, in response to the first anomaly notification, that content associated with at least one of the notifications is similar to content associated with at least one other notification of the notifications and merges the at least one of the notifications with the at least one other notification in response to determining that the content associated with the at least one of the notifications is similar to the content associated with the at least one other notification, as taught by Bates. This would be convenient such that alert fatigue can be greatly reduced by reducing the number of alerts (Bates, Parag. [0068]).
Johnson in view of Bates doesn’t explicitly disclose wherein the bias in the distribution of the notifications comprises the subscriber associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system.
However, Ibryam discloses wherein the bias in the distribution of the notifications comprises the subscriber (“consumer 152”) associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system (See Col. 6 lines 47-67; received maximum cache limits individualized to each respective consumer enable a message broker to deliver a quantity of messages or data to a consumer that the consumer will be able to process. Additionally, the individualized maximum cache limits may also help avoid a message broker underutilizing a particular consumer. For example, a message broker 110 configured to transmit a set maximum limit of 25 messages transmits 25 messages to the consumer 150, transmits 25 messages to the consumer 152, and transmits 25 messages to the consumer 154. At this point in time, the consumer 150 has a maximum cache limit of 30 messages and is able to process the received 25 messages, but the consumer 152 has a maximum cache limit of 20 messages and thus the received 25 messages uses 100% of its memory causing the consumer 152 to fail to process the messages).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the bias in the distribution of the notifications, taught by Johnson in view of Bates, to comprise the subscriber associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system, as taught by Ibryam. This would be convenient to maximize the system's overall message processing efficiency; and balancing the throughput and latency of each respective consumer to determine the best message distribution among the consumers to minimize the occurrence of messages idling in a consumer's cache to reduce overall latency and may maximize the concurrent processing of messages to increase overall throughput (Ibryam, Col. 14 lines 6-17).
Claim 14 is taught by Johnson in view of Bates and Ibryam as described for claim 6.
Claim 15 is taught by Johnson in view of Bates and Ibryam as described for claim 7.
Claim 17. Johnson discloses [a] computer storage medium having computer-executable instructions stored thereon that, when executed by a processor of a notification traffic anomaly detector, cause the processor to perform operations (See Fig. 12; “Processor 1200” and “Memory 1212”) comprising:
receiving, from a notification system (See Fig. 3; the system management component 302 and nodes 306), notification traffic data associated with at least one of notification requests or notifications to be processed by the notification system (See Col. 8 lines 19-38; anomaly detection component 303 may receive notifications (notification traffic data) of potential anomalies from various nodes within the network... See Col. 4 lines 36-67; the system management component 302 communicates with nodes 306 within the network 304 to provide forwarding instructions for data published by the various publishers. The nodes 306 forward the data published by the publishers (notifications processed by the notification system) through the network 304 to appropriate subscribers according to the latency and rate specified by the system management component 302 … the anomaly detection component 303 may also communicate with the nodes 306 in the network and receive notifications from the nodes 306 if data is not be received and/or forwarded at the specified rate and/or latency. See also Col. 3 lines 1-17 and Col. 8 lines 4-18. Examiner’s interpretation: It is known in the art that Pub/sub messages are notification(s), where the publisher sends message(s) to subscriber(s) on a specific topic, allowing for efficient distribution of notifications to interested parties. As taught by Johnson, the notification(s) received by the anomaly detection component 303 is associated with data published by publisher(s) to indicates potential anomalies dues to the data not being received and/or forwarded at the specified rate and/or latency. Therefore, the notification(s) received by the anomaly detection component 303 is a notification traffic data associated with notifications processed by the notification system),
determining whether the notification traffic data indicates an anomaly associated with any of the at least one of the notification requests or the notifications to be processed by the notification system (See Col. 8 lines 19-33; The anomaly detection component 303 may receive notifications of potential anomalies from various nodes within the network and assess whether an anomaly indeed exists, or may potentially exist if action is not taken, and also determine the likely source of the anomaly. For example, if a notice is received that the rate of data from publisher 1 308 that is being forwarded by a node does not satisfy the rate specified in the forwarding rules, the anomaly detection component 303 may determine whether other notices have been received from data along the path for publisher 1 308. Based on a collection of information from multiple nodes and/or stand-alone components monitoring the nodes, the anomaly detection component 303 can assess whether an anomaly exists and the likely source of the anomaly (determining whether the notification traffic data indicates an anomaly associated with the notifications)), and
in response to determining that the notification traffic data indicates an anomaly associated with the notifications to be processed by the notification system, generating a first anomaly notification identifying the anomaly, and providing the first anomaly notification to the notification system while the notifications are being processed by the notification system (See Col. 8 lines 33-38; Once an anomaly has been detected and the likely source determined, the anomaly detection component 303 may communicate with the system management component 302 (generating and providing the anomaly notification to the system management component 302) and the publication of data may be modified to ensure that the QoS for each potentially effected subscriber is not violated. See also Col. 6 lines 46-59; The anomaly detection component communicate with the system management component 303 to assess whether action needs to be taken to ensure the QoS for each subscriber is maintained. See Abstract; The failure detection component may identify an anomaly within the network and a source of the anomaly. Based on the identified anomaly, data rates and or data paths may be adjusted in real-time. See also Col. 8 lines 39-52. Examiner’s interpretation: upon anomaly detection, the anomaly detection component communicates with the system management component (i.e., processing the publication of data) to modify (adjust) the publication of data (notifications) in order to maintain/ensure QoS of the publication of data (providing the anomaly notification to the notification system while the notifications being processed by the notification system));
wherein the anomaly comprises a bias in a distribution of the notifications to a subscriber associated with the notification system (See Col. 8 lines 4-38; Each node within the network, or stand-alone components that monitor the nodes, may utilize the forwarding rules to monitor network traffic and notify the anomaly detection component 303 of potential anomalies. In some implementations, traffic coming into a node on an incoming connection may be monitored to determine if it is being received in a manner consistent with the forwarding rules … The anomaly detection component 303 may receive notifications of potential anomalies from various nodes within the network and assess whether an anomaly indeed exists, or may potentially exist if action is not taken, and also determine the likely source of the anomaly. For example, if a notice is received that the rate of data from publisher 1 308 that is being forwarded by a node does not satisfy the rate specified in the forwarding rules, the anomaly detection component 303 may determine whether other notices have been received from data along the path for publisher 1 308 (or other published data along the path). Based on a collection of information from multiple nodes and/or stand-alone components monitoring the nodes, the anomaly detection component 303 can assess whether an anomaly exists and the likely source of the anomaly. Once an anomaly has been detected and the likely source determined, the anomaly detection component 303 may communicate with the system management component 302 and the publication of data may be modified to ensure that the QoS for each potentially effected subscriber is not violated. Examiner’s interpretation: A “bias in distribution” is reasonably interpreted as inconsistency with the forwarding rules).
Johnson doesn’t explicitly disclose determining whether the notification traffic data indicates an anomaly using at least one machine learning model; wherein the bias in the distribution of the notifications comprises the subscriber associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system, and wherein the notification system determines, in response to the first anomaly notification, that content associated with at least one of the notifications is similar to content associated with at least one other notification of the notifications and merges the at least one of the notifications with the at least one other notification in response to determining that the content associated with the at least one of the notifications is similar to the content associated with the at least one other notification.
However, Bates discloses determining whether the notification traffic data indicates an anomaly using at least one machine learning model (See Parag. [0016]; “intelligent alerting” refers to an automated process that employs machine learning to create individually tailored alerts and associated thresholds for users based on a variety of factors, including, for example, user behavior, consumption patterns, and anomaly detection. The alerts are communicated to the user and context is automatically provided for the alert); and wherein the notification system determines, in response to the first anomaly notification, that content associated with at least one of the notifications is similar to content associated with at least one other notification of the notifications and merges the at least one of the notifications with the at least one other notification in response to determining that the content associated with the at least one of the notifications is similar to the content associated with the at least one other notification (See Parag. [0068]; Related alerts of the selected alerts are combined or deduplicated, at step 314. Related alerts represent the same macro event. For example, alerts may be triggered for decreased revenue, decreased sales, decreased conversions, and the like. However, each of these items may be tied to the same event ... Rather than providing a user multiple alerts for the same event many times over the course of a reporting period, these alerts can be combined or deduplicated. In this way, alert fatigue can be greatly reduced by reducing the number of alerts for a single macro event. See also Parag. [0076]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the anomaly detection system, taught by Johnson, to include determining whether the notification traffic data indicates an anomaly using at least one machine learning model, and wherein the notification system determines, in response to the first anomaly notification, that content associated with at least one of the notifications is similar to content associated with at least one other notification of the notifications and merges the at least one of the notifications with the at least one other notification in response to determining that the content associated with the at least one of the notifications is similar to the content associated with the at least one other notification, as taught by Bates. This would be convenient such that alert fatigue can be greatly reduced by reducing the number of alerts (Bates, Parag. [0068]).
Johnson in view of Bates doesn’t explicitly disclose wherein the bias in the distribution of the notifications comprises the subscriber associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system.
However, Ibryam discloses wherein the bias in the distribution of the notifications comprises the subscriber (“consumer 152”) associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system (See Col. 6 lines 47-67; received maximum cache limits individualized to each respective consumer enable a message broker to deliver a quantity of messages or data to a consumer that the consumer will be able to process. Additionally, the individualized maximum cache limits may also help avoid a message broker underutilizing a particular consumer. For example, a message broker 110 configured to transmit a set maximum limit of 25 messages transmits 25 messages to the consumer 150, transmits 25 messages to the consumer 152, and transmits 25 messages to the consumer 154. At this point in time, the consumer 150 has a maximum cache limit of 30 messages and is able to process the received 25 messages, but the consumer 152 has a maximum cache limit of 20 messages and thus the received 25 messages uses 100% of its memory causing the consumer 152 to fail to process the messages).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the bias in the distribution of the notifications, taught by Johnson in view of Bates, to comprise the subscriber associated with the notification system receiving a higher volume of the notifications than other subscribers associated with the notification system, as taught by Ibryam. This would be convenient to maximize the system's overall message processing efficiency; and balancing the throughput and latency of each respective consumer to determine the best message distribution among the consumers to minimize the occurrence of messages idling in a consumer's cache to reduce overall latency and may maximize the concurrent processing of messages to increase overall throughput (Ibryam, Col. 14 lines 6-17).
Claim 20 is taught by Johnson in view of Bates and Ibryam as described for claim 7.
Claims 2, 10, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson et al. (Patent No. US 9,857,825), hereinafter Johnson; in view of Bates et al. (Pub. No. US 2017/0083929), hereinafter Bates; further in view of Ibryam (Patent No. US 10,990,402); and further in view of Gupta et al. (Pub. No. US 2012/0271916), hereinafter Gupta.
Claim 2. Johnson in view of Bates and Ibryam discloses [t]he system of claim 1,
The combination doesn’t explicitly disclose wherein the notification traffic data comprises information identifying subscribers destined to receive the notifications, information identifying publishers that provided the notification requests to the notification system, and timestamp information associated with receipt of each of the notification requests by the notification system.
However, Gupta discloses wherein the notification traffic data comprises information identifying subscribers destined to receive the notifications, information identifying publishers that provided the notification requests to the notification system, and timestamp information associated with receipt of each of the notification requests by the notification system (See Parag. [0003]; receiving, at the message broker (notification system), a plurality of publications on a common topic from at least one publisher; identifying, at the message broker, for each of the publications on the topic, whether a more recently received of the publications should overwrite another of the publications, responsive to an instruction received from the publisher of the each publication (publishers that provided the notification requests to the notification system); storing, by the message broker for any received publication that is not overwritten, data indicating a time when the publication was published to the broker (timestamp information associated with receipt of each of the notification requests by the notification system), data indicating a time when the publication was last requested by any of the subscribers (identifying subscribers destined to receive the notifications), and a count of times the publication was requested by the subscribers … Examiner’s interpretation: It is known in the art that Pub/sub messages are notification(s), where the publisher sends message(s) to subscriber(s) on a specific topic, allowing for efficient distribution of notifications to interested parties; also, in a Pub/sub system, a "broker" acts as a central hub that receives messages from publishers, stores them based on designated topics, and then delivers those messages to subscribers who are interested in that specific topic. As taught by Gupta, the information identifies the subscribers that will receive notifications from publishers, publishers that provided the notification requests to the broker (notification system), and data indicating a time when the publication was published to the broker).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the notification traffic data, taught by the combination, to comprise information identifying subscribers destined to receive the notifications, information identifying publishers that provided the notification requests to the notification system, and timestamp information associated with receipt of each of the notification requests by the notification system, as taught by Gupta. This would be convenient for controlling retention of publications in a publish/subscribe system (Gupta, Parag. [0003]).
Claim 10 is taught by Johnson in view of Bates, Ibryam, and Gupta as described for claim 2.
Claim 18 is taught by Johnson in view of Bates, Ibryam, and Gupta as described for claim 2.
Claims 3-5, 11-13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson et al. (Patent No. US 9,857,825), hereinafter Johnson; in view of Bates et al. (Pub. No. US 2017/0083929), hereinafter Bates; further in view of Ibryam (Patent No. US 10,990,402); and further in view of Cawley et al. (Pub. No. US 2023/0291657), hereinafter Cawley.
Claim 3. Johnson in view of Bates and Ibryam discloses [t]he system of claim 1,
Johnson discloses determining whether the notification traffic data indicates an anomaly (See Col. 8 lines 19-33; The anomaly detection component 303 may receive notifications of potential anomalies from various nodes within the network and assess whether an anomaly indeed exists …); but, the combination doesn’t explicitly disclose wherein determining whether the notification traffic data indicates an anomaly comprises determining whether deviation of an observed notification request volume indicated by the notification traffic data from a forecasted notification request volume provided by the at least one machine learning model exceeds an anomaly alert level.
However, Cawley discloses determining whether deviation of an observed notification request volume indicated by the notification traffic data from a forecasted notification request volume provided by the at least one machine learning model exceeds an anomaly alert level (See Parag. [0056]; FIG. 4A illustrates a SCR (statistical control rule) 410, which is triggered when the distance measure between an observed value of an activity metric (the number of service requests received per period, See Parag. [0020]) (observed notification request volume) and the predicted value exceeds a specified distance threshold … As shown in this example, the last observed value of the activity metric (observed notification request volume) deviates significantly from the predicted value (forecasted notification request volume), exceeding the configured distance threshold specified for SCR 410 (exceeds an anomaly alert level). As a result, an anomaly alert will be generated under SCR 410. See Parag. [0014]; the forecasting step may be implemented as a machine learning model. The forecasting model only generates the forecast data, which is used as a baseline to analyze the time series data for anomalies... See Parag. [0022]; Forecast component generates forecast values for the time series data (e.g. predicted values of the activity metric 132 and prediction confidence intervals …). See also Parag. [0020-0026] [0041-0042] [0057] and Claim 21).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify determining whether the notification traffic data indicates an anomaly, taught by the combination, to comprise determining whether deviation of an observed notification request volume indicated by the notification traffic data from a forecasted notification request volume provided by the at least one machine learning model exceeds an anomaly alert level, as taught by Cawley. This would be convenient to combine the robustness, flexibility, and low cost of a rule-based detection system with the sophistication of complex machine learning systems (e.g. by generating forecast data that reflects seasonality of the data) (Cawley, Parag. [0015]).
Claim 4. Johnson in view of Bates and Ibryam discloses [t]he system of claim 1,
Johnson discloses determining whether the notification traffic data indicates an anomaly (See Col. 8 lines 19-33; The anomaly detection component 303 may receive notifications of potential anomalies from various nodes within the network and assess whether an anomaly indeed exists …); but, the combination doesn’t explicitly disclose wherein determining whether the notification traffic data indicates an anomaly comprises determining whether deviation of an observed bias metric value indicated by the notification traffic data from a forecasted bias metric value provided by the at least one machine learning model exceeds an anomaly alert level.
However, Cawley discloses determining whether deviation of an observed bias metric value indicated by the notification traffic data from a forecasted bias metric value provided by the at least one machine learning model exceeds an anomaly alert level (See Parag. [0056]; FIG. 4A illustrates a SCR (statistical control rule) 410, which is triggered when the distance measure between an observed value of an activity metric 402 (the number of service requests received per period, See Parag. [0020]) and the predicted value exceeds a specified distance threshold … As shown in this example, the last observed value (observed bias metric value) of the activity metric deviates significantly from the predicted value (forecasted bias metric value), exceeding the configured distance threshold specified for SCR 410 (exceeds an anomaly alert level). As a result, an anomaly alert will be generated under SCR 410. See Parag. [0014]; the forecasting step may be implemented as a machine learning model. The forecasting model only generates the forecast data, which is used as a baseline to analyze the time series data for anomalies... See Parag. [0022]; Forecast component generates forecast values for the time series data (e.g. predicted values of the activity metric 132 and prediction confidence intervals ... See Parag. [0023]; the forecaster 150 may periodically self-adjust over time to better align its predictions with the observed values of the time series data (generating forecasted bias metric value). See also Parag. [0020-0026] [0041-0042] [0053] [0057] and Claim 21. Examiner’s interpretation: The “last observed value" is interpreted as a biased metric value; and the “forecaster 150 may periodically self-adjust over time to better align its predictions” is interpreted as generating forecasted bias metric value).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify determining whether the notification traffic data indicates an anomaly, taught by the combination, to comprise determining whether deviation of an observed bias metric value indicated by the notification traffic data from a forecasted bias metric value provided by the at least one machine learning model exceeds an anomaly alert level, as taught by Cawley. This would be convenient to combine the robustness, flexibility, and low cost of a rule-based detection system with the sophistication of complex machine learning systems (e.g. by generating forecast data that reflects seasonality of the data) (Cawley, Parag. [0015]).
Claim 5. Johnson in view of Bates and Ibryam discloses [t]he system of claim 1,
Johnson discloses determining whether the notification traffic data indicates an anomaly (See Col. 8 lines 19-33; The anomaly detection component 303 may receive notifications of potential anomalies from various nodes within the network and assess whether an anomaly indeed exists …); but, the combination doesn’t explicitly disclose wherein determining whether the notification traffic data indicates an anomaly comprises determining whether deviation of an observed non-preference metric value indicated by the notification traffic data from a forecasted non-preference metric value provided by the at least one machine learning model exceeds an anomaly alert level.
However, Cawley discloses determining whether deviation of an observed non-preference metric value indicated by the notification traffic data from a forecasted non-preference metric value provided by the at least one machine learning model exceeds an anomaly alert level (See Parag. [0058]; FIG. 4C illustrates SCR (statistical control rule) 430, which is triggered when a sequence of observations trends in the opposite direction from their predicted values. As shown in this example, when three consecutive observation values create a trend (observed non-preference metric value) in the opposite direction as their predicted values (forecasted non-preference metric value), an anomaly condition is detected. This type of anomaly condition may be identified by data monitor 170 by tracking respective trends of the time series data (See Parag. [0020]) and the forecast data, which may be stored as trend indicators in the log repository. See Parag. [0037]; when one or more of the SCRs 172 are satisfied (exceeds an anomaly alert level), the data monitor 170 issues an anomaly alert 190 via an alert interface 180 of the system. See Parag. [0014]; the forecasting step may be implemented as a machine learning model. The forecasting model only generates the forecast data, which is used as a baseline to analyze the time series data for anomalies... See Parag. [0022]; Forecast component generates forecast values for the time series data (e.g. predicted values of the activity metric 132 and prediction confidence intervals … See also Parag. [0020-0026] [0041-0042] [0053] [0057] and Claim 21. Examiner’s interpretation: The Applicant discloses in the specification, Parag. [0039], that “[t]he non-preference metric value is defined by a uniformity score.” It is known in the art that: (1) A uniformity score is a metric used to evaluate how consistently data is distributed. (2) A trend is a characteristic observed within a distribution, which describes the overall direction or pattern of change within distribution of the data points. Thus, from (1) and (2), the trend evaluates how consistently data is distributed. Therefore, as taught by Cawley, the respective trends of the time series data and the forecast data, which may be stored as trend indicators, are interpreted as observed non-preference metric value and forecasted non-preference metric value, respectively).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify determining whether the notification traffic data indicates an anomaly, taught by the combination, to comprise determining whether deviation of an observed non-preference metric value indicated by the notification traffic data from a forecasted non-preference metric value provided by the at least one machine learning model exceeds an anomaly alert level, as taught by Cawley. This would be convenient to combine the robustness, flexibility, and low cost of a rule-based detection system with the sophistication of complex machine learning systems (e.g. by generating forecast data that reflects seasonality of the data) (Cawley, Parag. [0015]).
Claims 11-13 are taught by Johnson in view of Bates, Ibryam, and Cawley as described for claim 3-5. respectively.
Claim 19. Johnson in view of Bates and Ibryam discloses [t]he computer storage medium of claim 17,
Johnson discloses determining whether the notification traffic data indicates an anomaly (See Col. 8 lines 19-33; The anomaly detection component 303 may receive notifications of potential anomalies from various nodes within the network and assess whether an anomaly indeed exists …); but, the combination doesn’t explicitly disclose wherein determining whether the notification traffic data indicates an anomaly comprises at least one of: determining whether deviation of an observed notification request volume indicated by the notification traffic data from a forecasted notification request volume provided by the at least one machine learning model exceeds an anomaly alert level associated with notification request volumes; determining whether deviation of an observed bias metric value indicated by the notification traffic data from a forecasted bias metric value provided by the at least one machine learning model exceeds an anomaly alert level associated with bias metric values; or determining whether deviation of an observed non-preference metric value indicated by the notification traffic data from a forecasted non-preference metric value provided by the at least one machine learning model exceeds an anomaly alert level associated with non-preference metric values.
However, Cawley discloses determining whether deviation of an observed bias metric value indicated by the notification traffic data from a forecasted bias metric value provided by the at least one machine learning model exceeds an anomaly alert level associated with bias metric values (See Parag. [0056]; FIG. 4A illustrates a SCR (statistical control rule) 410, which is triggered when the distance measure between an observed value of an activity metric 402 (the number of service requests received per period, See Parag. [0020]) and the predicted value exceeds a specified distance threshold … As shown in this example, the last observed value (observed bias metric value) of the activity metric deviates significantly from the predicted value (forecasted bias metric value), exceeding the configured distance threshold specified for SCR 410 (exceeds an anomaly alert level). As a result, an anomaly alert will be generated under SCR 410. See Parag. [0014]; the forecasting step may be implemented as a machine learning model. The forecasting model only generates the forecast data, which is used as a baseline to analyze the time series data for anomalies... See Parag. [0022]; Forecast component generates forecast values for the time series data (e.g. predicted values of the activity metric 132 and prediction confidence intervals ... See Parag. [0023]; the forecaster 150 may periodically self-adjust over time to better align its predictions with the observed values of the time series data (generating forecasted bias metric value). See also Parag. [0020-0026] [0041-0042] [0053] [0057] and Claim 21. Examiner’s interpretation: The “last observed value" is interpreted as a biased metric value; and the “forecaster 150 may periodically self-adjust over time to better align its predictions” is interpreted as generating forecasted bias metric value. Examiner’s note: The claim recites determining whether the notification traffic data indicates an anomaly comprises at least one of: (A), (B), or (C). The Examiner has chosen the second limitation (B))).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify determining whether the notification traffic data indicates an anomaly, taught by the combination, to comprise determining whether deviation of an observed bias metric value indicated by the notification traffic data from a forecasted bias metric value provided by the at least one machine learning model exceeds an anomaly alert level, as taught by Cawley. This would be convenient to combine the robustness, flexibility, and low cost of a rule-based detection system with the sophistication of complex machine learning systems (e.g. by generating forecast data that reflects seasonality of the data) (Cawley, Parag. [0015]).
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson et al. (Patent No. US 9,857,825), hereinafter Johnson; in view of Bates et al. (Pub. No. US 2017/0083929), hereinafter Bates; further in view of Ibryam (Patent No. US 10,990,402); and further in view of Iyer et al. (Pub. No. US 2022/0043595), hereinafter Iyer.
Claim 8. Johnson in view of Bates and Ibryam discloses [t]he system of claim 7,
The combination doesn’t explicitly disclose wherein the notification system modifies the at least one of the notification requests in response to receiving the second anomaly notification by throttling a rate at which the at least one of the notification requests is processed by the notification system.
However, Iyer discloses herein the notification system modifies the at least one of the notification requests in response to receiving the second anomaly notification by throttling a rate that the at least one of the notification requests is processed by the notification system (See Parag. [0036]; the topic manager 113 (within Public-Subscribe server 110, See Fig. 1) is configured to dynamically adjust the rate of publishing based on a current publishing rate of the messages … When the topic manager 113 detects that the publishing rate has equaled or exceeded a pre-selected threshold for the publishing rate, the topic manager 113 throttles the publishing rate so that messages 118 are published to the topic 114 (throttling a rate that at least one of the notification requests is processed by the notification system) at a rate slower than a current rate of publishing in an attempt to bring the publishing rate below the pre-selected threshold publishing rate. See Parag. [0029]; One or more of the publishing entities 120 may publish messages 118 to the topic 114. One or more of the subscribing entities 130 may subscribe to the topic 114 and receive messages 118 published to the topic 114).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the system management component, taught by the combination, to modify notification requests by throttling a rate that at least one of the notification requests is processed by the notification system, as taught by Iyer. This would be convenient to manage resource utilization by the topic 114 so that a topic is kept from overloading or a recovery from a topic overload situation is effected in real-time without loss of topic data or topic downtime (Iyer, Parag. [0033]).
Claim 16 is taught by Johnson in view of Bates, Ibryam, and Iyer as described for claim 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Bogdan et al. (US 2018/0018316) – Related art in the area of analyzing a plurality of text documents, (Abstract; Aspects of the subject disclosure may include, for example, a computer that performs a statistical natural language processing analysis on a plurality of text documents to determine a plurality of topics, creates a proper subset of topics from the plurality of topics, based on user input, maps one or more topics in the proper subset of topics to each document in the plurality of text documents, thereby creating a plurality of topic-document pairs, identifies n-dimensions of bias for each topic-document pair from the text, creates clusters of topics from the proper subset of topics, and generates presentable content depicting each cluster of the clusters of topics according to a corresponding image configuration. The topics and n-dimensions of bias data can be further analyzed with co-collected structured data for statistical relationships. The topics and n-dimensions of bias data can be used for a publisher-subscriber network that uses content-driven routing when delivering raw data and summarized data via the network. Other embodiments are disclosed).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
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, Oscar Louie can be reached on 571-270-1684. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Primary Examiner, Art Unit 2445
Prosecution Insights