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 ACTION
This Office Action is in response to the Remarks filed on 08/11/2025.
In the instant Amendment, claims 1 and 20-21 are amended; claim 11-19 and 22 has been cancelled, claims 1-10, 20-21 and 23-30 been examined and are pending in this application. This Action is made FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 08/11/2025, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant’s arguments with respect to claim(s) 1 and the rest of the independent claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The Examiner respectfully suggests that the claim be further amended; details in the specification could be incorporated, to distinguish the claimed invention over prior art of record. Should the Applicant desire an interview to further clarify the claim interpretation/rejections, please contact the Examiner at (571) 272-1531 to schedule an interview.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 7-10, 20-21, 23 and 28-30 and is/are rejected under 35 U.S.C. 103 as being unpatentable over Li (US 11,336,506 B1 ), in view of SOHUM (US 2019/0333099 A1).
Regarding Claim 1
Li discloses:
A method of processing data, applied to an authentication server, comprising:
obtaining pulling information reported by a live data server, wherein the pulling information carries at least one request address and a traffic metric representing an amount of data traffic generated through pulling by the at least one request address within a reporting period (Li Column 4, Line 50 - Column 6, Line 40: teaches obtaining heartbeat data from a live streaming session, where the data includes the public IP address (request address) and traffic metrics such as buffering time, bitrate, and play duration, reported every minute for each session. These per-minute heartbeat entries reflect pulling behavior and are generated while the session is actively streaming, aligning with the notion of pulling information reported by a live data server during a defined reporting period.), wherein the pulling information is periodically reported by the live data server at an interval of the reporting period (Li Column 4, Lines 50-63: teaches that heartbeat data is periodically reported by the live data server (content distribution monitor) every 20 seconds while a video session is active. These periodic reports are summarized and stored per minute in HDFS, aligning with the notion of pulling information reported at regular intervals within a reporting period.), and wherein the live data server stops reporting the pulling information in response to determining that the at least one request address stops obtaining a live vide stream from the live data server (Li Column 5, Line 63 - Column 6, Line 9: teaches that heartbeat messages are generated and sent only while a video session is active, with each heartbeat tied to a specific session ID. Once the viewer stops obtaining the live video stream, the session ends and no further heartbeat (pulling information) is reported.);
computing total data traffic associated with a target request address within a statistical period (Li Column 8, Lines 19-64: teaches computing metrics such as total buffering time and average bitrate played since session start, and aggregating these metrics across sessions grouped by request address within a statistical time window, thereby enabling computation of total data traffic associated with a target request address during that period. These aggregated traffic metrics are then fed into an anomaly detection engine, which uses techniques such as baseline thresholds and Hidden Markov Models (HMMs) to detect deviations in total traffic patterns over time, signaling potential issues in the video delivery pipeline.); and
In an analogous art, SOHUM discloses an anomaly blacklist system/method that includes:
determining, based on the total data traffic, whether the target request address is a blacklist address, wherein the target request address is any request address carried in the pulling information (SOHUM ¶34, 44-45 and 51: teaches determining whether an IP address (i.e., request address) is a blacklist address by analyzing abnormal traffic behavior, computing a score based on the total traffic for that IP, and then comparing it against a threshold to classify the address as either blacklisted or whitelisted. This determination is made using IP traffic data over time, aligning with the claim’s requirement of using total data traffic to make the blacklist esses to a blacklist if their traffic behavior exceeds a defined threshold (Sohum ¶44–45, 51). determination.).
Given the teachings of Sohum, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Li by determining whether a target request address is a blacklist address based on total data traffic. Sohum discloses collecting and analyzing IP address traffic data, computing traffic-based scores, and allocating IP addrThis teaches determining whether an address should be blacklisted based on aggregated pulling traffic. Thus, it would have been obvious to incorporate Sohum teachings of traffic-based blacklist determination in order to provide automated, real-time threat detection for request addresses exhibiting suspicious or excessive traffic behavior improving a system responsiveness and fraud mitigation.
Regarding Claim 2
SOHUM further discloses an anomaly blacklist system/method that includes:
The method according to claim 1, wherein the determining, based on the total data traffic, whether the target request address is a blacklist address further comprises: determining whether the total data traffic is greater than an initial traffic threshold; and determining, based on a geographical location of the target request address, whether the target request address is a blacklist address when the total data traffic is greater than the initial traffic threshold (Sohum ¶44-46: teaches determining whether a target request address (IP) should be blacklisted based on total traffic metrics. Specifically, Sohum discloses computing a score for each IP address based on the analysis of abnormal traffic, and allocating the IP address to a blacklist if the traffic-based score exceeds a defined threshold. Additionally, Sohum determines fraud using geo-IP correlation, analyzing the geographic location of the IP address when assessing blacklist status.).
Given the teachings of Sohum, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Li by determining whether a request address is a blacklist address based on traffic thresholds and geographic location. Sohum discloses calculating scores for IP addresses based on total data traffic to detect abnormal behavior and allocating those with high scores to a blacklist (Sohum ¶44–45). Furthermore, Sohum teaches correlating IP address data with geographic location using a geo-IP database to assess fraud (Sohum ¶46). Thus, it would have been obvious to determine blacklist status by first evaluating whether total data traffic exceeds a threshold and then using the geographic location of the target address as part of the blacklist determination logic.
Regarding Claim 7
Li discloses:
The method according to claim 1, wherein the pulling information further carries reporting times; and the computing total data traffic associated with a target request address within a statistical period further comprises: determining one or more reporting times carried in the pulling information corresponding to the target request address (Li Column 4, Line 50 - Column 6, Line 40: teaches that the system collects streaming session measurements sent periodically from client devices in the form of "heartbeats" (e.g., every 20 seconds), where each heartbeat includes session identifiers and timing metadata such as session start/end times and timestamped quality metrics. These timestamps serve as the reporting times carried in the pulling information, which are then used to aggregate traffic per session within defined statistical windows (e.g., per minute, per hour) for QoE and anomaly analysis.); and computing data traffic carried in corresponding pulling information with the one or more reporting times that are within the statistical period to obtain the total data traffic of the target request address within the statistical period (Li Column 6, Line 34 - Column 7, Line 10: teaches receiving session summaries at fixed time intervals (e.g., per minute) from client devices and computing aggregated QoE metrics such as rebuffering ratio and startup time based on reporting times within that interval, thereby computing total data traffic associated with a target request address (e.g., CDN or geo-location) during a defined statistical period. This supports determining reporting times from pulling information and aggregating corresponding traffic data within the same time window.).
Regarding Claim 8
SOHUM further discloses an anomaly blacklist system/method that includes:
The method according to claim 1, wherein after the determining, based on the total data traffic, whether the target request address is a blacklist address, the method further comprises: generating a blacklist based on a determined blacklist address; and returning the blacklist to the live data server in response to receiving an obtaining request from the live data server (Sohum ¶45-49: teaches generating a blacklist based on IP addresses whose traffic scores exceed a threshold, and further discloses returning this blacklist to external systems such as publishers or ad platforms in response to queries or communication triggers. This maps directly to generating and returning a blacklist to a live data server based on total data traffic associated with request addresses.).
Given the teachings of Sohum, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Li by generating and returning a blacklist to a live data server based on total data traffic. Sohum discloses identifying suspicious request addresses by computing traffic scores and blacklisting IP addresses whose scores exceed defined thresholds (Sohum ¶45). It further teaches returning or transmitting the blacklist to external systems such as publishers or ad networks for fraud prevention and mitigation (Sohum ¶49). It would have been obvious to implement Sohum’s blacklist return to a live data in order to automate and improve responsiveness in fraud detection and address blocking.
Regarding Claim 9
SOHUM further discloses an anomaly blacklist system/method that includes:
The method according to claim 8, wherein the generating a blacklist based on a determined blacklist address further comprises: determining whether a target blacklist address exists within a current statistical period, wherein the target blacklist address does not exist within a previous statistical period; and generating a blacklist corresponding to the current statistical period by adding the target blacklist address to a blacklist generated within the previous statistical period (Sohum ¶30-31, 41, 47-48: teaches generating a blacklist based on IP addresses whose fraud scores exceed a defined threshold, and further discloses updating and storing this blacklist in real time within a database, including comparing to historical data sources. It further teaches that the blacklist is distributed or made available to external systems, such as advertisers and publishers, to block users or take fraud-prevention actions.).
Given the teachings of Sohum, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Li by blacklist generation to incrementally update the blacklist across successive statistical periods. Sohum teaches generating a blacklist based on IP addresses whose traffic scores exceed a threshold, and updating the blacklist in real time based on current traffic data (Sohum ¶44–47). It further stores historical and real-time data in databases, including a blocked IP DB and historical DB (Sohum ¶30–31), enabling differentiation between newly detected addresses and previously blacklisted ones. It would have been obvious to modify Sohum to determine whether a blacklist address appears in the current period but not in a previous one, and to generate a current blacklist by appending newly flagged addresses to a previously stored list. This modification would enhance fraud detection accuracy over time and reduce redundant entries, thereby improving a system efficiency and responsiveness in tracking newly emerging threats.
Regarding Claim 10
SOHUM further discloses an anomaly blacklist system/method that includes:
The method according to claim 8, wherein the returning the blacklist to the live data server in response to receiving an obtaining request from the live data server further comprises: obtaining a target blacklist corresponding to a current statistical period in response to receiving the obtaining request from the live data server; and returning the target blacklist to the live data server (Sohum ¶47–49: teaches generating and storing a blacklist in real time, and communicating blacklist information to external entities such as publishers and advertisers upon detection of fraud. This maps to receiving an obtaining request from a live data server and returning a target blacklist corresponding to the current statistical period, supporting dynamic, request-triggered delivery of blacklist data.).
Given the teachings of Sohum, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Li by returning an updated blacklist corresponding to a current statistical period in response to a request from an external system such as a live data server. Sohum teaches generating and storing blacklists in real time (Sohum ¶47-48) and sending alerts or communications to external parties such as publishers and advertisers based on blacklist status (Sohum ¶49). It would have been obvious to incorporate a request to allow the live data server or a similar external system to dynamically retrieve a current-period blacklist, thereby improving the flexibility and responsiveness of the fraud mitigation workflow.
Regarding Claim 20
Claim 20 is directed to a system corresponding to the computer-implemented method in claim 1. Claim 20 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 21
Claim 21 is directed to a computer-executable instruction corresponding to the computer-implemented method in claim 1. Claim 21 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 23
Claim 23 is directed to a system corresponding to the computer-implemented method in claim 2. Claim 23 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 28
Claim 28 is directed to a system corresponding to the computer-implemented method in claim 7. Claim 28 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 29
Claim 29 is directed to a system corresponding to the computer-implemented method in claim 8. Claim 29 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Regarding Claim 30
Claim 30 is directed to a system corresponding to the computer-implemented method in claim 10. Claim 30 is similar in scope to claim 10 and is therefore rejected under similar rationale.
Claims 3-4, 6, 24-25 and 27 and is/are rejected under 35 U.S.C. 103 as being unpatentable over Li (US 11,336,506 B1 ), in view of SOHUM (US 2019/0333099 A1) and in further view of Yu (US 2013/0347113 A1).
Regarding Claim 3
In an analogous art Yu discloses an IP address geographical system/method that includes:
The method according to claim 2, wherein the determining, based on a geographical location of the target request address, whether the target request address is a blacklist address further comprises:
determining a target area to which the geographical location of the target request address belongs (Yu ¶31: determining a target area by evaluating service-request behavior according to a “particular geographic area”, meaning the system identifies the geographic region associated with an IP address and applies region-specific traffic analysis.);
determining a request address reuse value corresponding to the target area, and determining whether the request address reuse value of the target area is greater than a preset threshold (Yu ¶24-26: teaches computing a reuse value of an address within a geographic area by analyzing how often an IP address is used across accounts and time, and comparing that value to a threshold to determine whether the address should be labeled as good or bad. );
determining a corresponding updated traffic threshold based on the target area when the request address reuse value of the target area is greater than the preset threshold (Yu ¶25–26, 31: teaches updating the evaluation threshold for an IP address once its reuse exceeds a preset limit by adjusting how many service requests are acceptable for that address based on patterns tied to the particular geographic area (e.g., night vs. peak-hour norms). When an address crosses the reuse threshold, the system applies these area-dependent time-series and population-based metrics as the new, higher-level threshold for assessing whether the traffic volume is abnormal.);
determining whether the total data traffic is greater than the updated traffic threshold (Yu ¶25, 27, 31: determines whether the total traffic for an IP exceeds the updated threshold by comparing the IP’s overall volume of service requests against the area-based time-series limits); and
determining, based on a quantity of live rooms accessed by the target request address within the statistical period, whether the target request address is a blacklist address when the total data traffic is greater than the updated traffic threshold (Yu ¶26, 27, 31: determining whether an IP address should be treated as malicious (blacklist) based on the number of accounts or services it accesses, because it classifies an IP as bad when it is associated with more than a threshold number of accounts or exhibits high-volume or suspicious request patterns over a statistical period.).
Given the teachings of Yu, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Li and SOHUM by determining a request address reuse value for an IP address based on both a geographic area attribute and statistical-time behavior. Yu teaches computing IP risk and classification features using geographically dependent attributes, such as identifying whether requests occur during peak or non-peak periods for a particular geographic area (Yu ¶31), and further teaches using time-series statistical features, including the number of time units exceeding request thresholds and anomaly-derived predictability (Yu ¶31). It would have been obvious to a POSITA to combine these geographic and temporal factors when computing a reuse value for an address in a given area, as Yu already uses these exact types of statistical and area-dependent characteristics to identify suspicious or high-volume IP activity.
Regarding Claim 4
Yu further discloses an IP address geographical system/method that includes:
The method according to claim 3, wherein the determining a request address reuse value corresponding to the target area further comprises at least one of: determining the request address reuse value corresponding to the target area based on an area attribute of the target area; determining the request address reuse value corresponding to the target area based on the area attribute of the target area and a statistical time (Yu ¶31: teaches determining a reuse or activity value for an IP address based on both area attributes and statistical time patterns.); or determining the request address reuse value corresponding to the target area based on a population density of the target area
Given the teachings of Yu, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Li and SOHUM by determining a request address reuse value for an IP address based on both a geographic area attribute and statistical-time behavior. Yu teaches computing IP risk and classification features using geographically dependent attributes, such as identifying whether requests occur during peak or non-peak periods for a particular geographic area (Yu ¶31), and further teaches using time-series statistical features, including the number of time units exceeding request thresholds and anomaly-derived predictability (Yu ¶31). It would have been obvious to a POSITA to combine these geographic and temporal factors when computing a reuse value for an address in a given area, as Yu already uses these exact types of statistical and area-dependent characteristics to identify suspicious or high-volume IP activity.
Regarding Claim 6
Yu further discloses an IP address geographical system/method that includes:
The method according to claim 3, wherein the determining a corresponding updated traffic threshold based on the target area further comprises: determining the updated traffic threshold corresponding to an area attribute of the target area based on prestored correspondences between area attributes and traffic thresholds (Yu ¶26, 29: teaches determining a reuse or traffic-volume value for an IP “area” based on stored area attributes such as the number of associated accounts, request distributions, and other population features and comparing that value against pre-defined thresholds, which corresponds to determining an updated traffic threshold for a target area based on pre-stored correspondences between area attributes and threshold values.).
Given the teachings of Yu, a POSITA would have recognized the desirability of modifying the teachings of Li and SOHUM by determining an updated traffic threshold for an IP-area based on stored area attributes and corresponding threshold values. Yu teaches using population attributes of an IP block (Yu ¶29) and comparing them to predefined thresholds (Yu ¶26) to decide whether an address shows abnormal reuse. It would have been obvious to use these stored attribute threshold correspondences to update a traffic threshold for a target area to improve accuracy in identifying suspicious high-traffic addresses.
Regarding Claim 24
Claim 24 is directed to a system corresponding to the computer-implemented method in claim 3. Claim 24 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 25
Claim 25 is directed to a system corresponding to the computer-implemented method in claim 4. Claim 25 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding Claim 27
Claim 27 is directed to a system corresponding to the computer-implemented method in claim 6. Claim 27 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Claims 5 and 26 and is/are rejected under 35 U.S.C. 103 as being unpatentable over Li (US 11,336,506 B1), in view of SOHUM (US 2019/0333099 A1), in view of Yu (US 2013/0347113 A1) and in further view of Ward (US 20180183829 A1).
Regarding Claim 5
In an analogous art Ward discloses an IP address geographical system/method that includes:
The method according to claim 3, wherein the pulling information further carries live room identifiers; and the determining, based on a quantity of live rooms accessed by the target request address within the statistical period, whether the target request address is a blacklist address further comprises: calculating, based on one or more live room identifiers carried in the pulling information corresponding to the target request address, the quantity of live rooms accessed by the target request address within the statistical period (Ward ¶27, 43, 45: teaches determining, for a given request address, a count value based on stored identifiers of the specific domains accessed (live room identifiers) and computing how many distinct domains the user/IP accessed within a defined statistical time period. Ward further teaches comparing this calculated count against predetermined thresholds to classify the requester as abusive or malicious, which corresponds to determining the quantity of live rooms accessed within the statistical period based on identifiers carried in the pulling information.); determining whether the quantity of live rooms accessed by the target request address within the statistical period is less than a preset quantity threshold (Ward ¶43 and 45: teaches comparing the counted number of domains accessed by a given requestor within a defined time window against preset threshold values to decide whether the behavior is abnormal or malicious, which corresponds to determining whether the quantity of live rooms accessed within the statistical period is less than a preset quantity threshold.); and determining that the target request address is a blacklist address when the quantity of live rooms accessed by the target request address within the statistical period is less than the preset quantity threshold (Ward ¶43-44: teaches marking or treating a requestor as malicious when their access count falls on the wrong side of a defined threshold, which corresponds to determining that a target request address is a blacklist address when its number of accessed live rooms is below the preset quantity threshold.).
Given the teachings of Ward, a person of ordinary skill in the art would have found it obvious to modify the teaching of Li, SOHUM and Yu by determining a threshold-based blacklist determination to classify a target request address as malicious when its access activity falls below a preset threshold. Ward discloses detecting abnormal or undesirable requestors by evaluating the number of requests made within a period and triggering mitigation when the requester’s activity fails threshold-based tests (¶43–¶45). It would have been obvious to apply Ward’s threshold-driven classification logic to the claimed scenario of evaluating live-room access counts, because both involve determining maliciousness based on whether measured activity is above or below predefined limits, thereby improving early detection of abnormal clients and enabling timely mitigation actions.
Regarding Claim 26
Claim 26 is directed to a system corresponding to the computer-implemented method in claim 5. Claim 26 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Saad Abdullah whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday through Friday, 8:30 AM - 5:00 PM (EST).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. 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 http://pair-direct.uspto.gov. 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.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights