DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Status
No claims are amended.
Claim 20 is canceled.
Claim 21 is newly added.
Claims 1-19 and 21 are presented for examination.
Response to Arguments
Applicant’s arguments filed on 3/17/2026 with respect to the rejection of claim 1, 14 and 16 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Zilbershtein et al. (US 20220345474) as rejected in rejection section below.
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-4, 6, 8, 9, 10, 13, 14-19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Vinukonda et al. (US 20180205742), in view of Zilbershtein et al. (US 20220345474), in further view of Cline et al. (US 20130055375).
Regarding claim 1, Vinukonda discloses, a method comprising by a content delivery network:
receiving a digital content segment request containing a token (Par. 0015, receive a subsequent request, e.g., a content download request) including the secure token transmitted to the user device in response to the content access request. The content download request is a request to transmit content (e.g., a variant media playlist, a number of media segments, etc.) to the user device. The request can be received by a CDN server corresponding to a URL contained in a content master playlist transmitted to the user device in response to the content access request);
in response to the digital content segment request, checking the token, and, upon a successful check of the token, transmitting the requested digital content segment to a requestor, wherein the token contains an entitlement tag for restricted use (Par. 0015, Before transmitting the requested content to the user device, the secure token received with the content download request is validated, Par. 0019, methods can automatically validate a content access request using one or more tokens and a counter identifying a number of IP addressing changes to ensure that the number of IP addressing changes does not exceed a threshold number);
for each of a plurality of received digital content segment requests, extracting the entitlement tag from the token of the digital content segment request and storing a record including at least the extracted entitlement tag (Par. 0053, the user device transmits the secure token along with a current IP address of the user device (i.e. entitlement tag = IP address of user device) with any subsequent request made to a CDN server to download a playlist, media segment, etc. The secure token is used to match the initial IP address (i.e., the IP address used with the initial content access request) with the IP address being used with the current request (i.e. storing IP address or ID of the of user device received in first request)).
Vinukonda does not disclose, analyzing the stored records to detect if a number of instances of a same entitlement tag within a predetermined time period exceeds a threshold,
in case of a positive detection, storing said entitlement tag in a list of nontrusted tags.
Zilbershtein discloses, analyzing the stored records to detect if a number of instances of a same entitlement tag within a predetermined time period exceeds a threshold (0058-0059, when a pirate clones identity and/or shares tokens, the pirate often automates the process by sending out an abnormally high number of access requests per time unit for a given watch session, a high Presentation_Exceeded count represents an abnormally high number of presentation changes in a watch session of the same client_ID, the number of records in the watch table with the same client ID signals an abnormally high number of concurrent watch sessions of the same client_ID, The detection analytics module identifies the cluster(s) with one or more abnormally high counts as exhibiting abnormal automated behaviors and generates reports for the suspected piracy export module to pass to the anti-piracy controller. Par. 0065, a malicious user shares the same IP address, uses a shared token, clones an identity, attempts to frame an innocent user, using an identity tied to a fictitious user, and/or exploits the safety margin, the piracy detection system can establish clustering to differentiate the automated behaviors from normal usages, thus improving the accuracy and efficacy of piracy detection, i.e. detecting number of instances of using same client ID or same ID address for making request becomes abnormally high (i.e. higher than certain allowed limit) within time unit. Par. 0027, the anti-piracy controller 106 instructs the control plane 103 and/or the CDNs 104 to perform further anti-piracy actions, e.g., disrupting services and/or streaming to client device N 102-N via CDN M 104-M).
It would have been obvious to a skilled artisan before the effective filing date of the claimed invention to modify the system of Vinukonda by teaching of analyzing the stored records to detect if a number of instances of a same entitlement tag within a predetermined time period exceeds a threshold, as taught by Zilbershtein, to identify piracy behaviors that are statistically different from normal usage using same client device or client terminal having same identifier, as disclosed in Zilbershtein, par. 0015, 0058-0059, 0065.
Vinukonda in view of Zilbershtein does not disclose, in case of a positive detection, storing said entitlement tag in a list of nontrusted tags.
Cline discloses, in case of a positive detection, storing said entitlement tag in a list of nontrusted tags (Par. 0034, if exceeding request threshold, the client's IP address is blacklisted and stored to a table in the data storage medium 110).
It would have been obvious to a skilled artisan before the effective filing date of the claimed invention to modify the system of Vinukonda in view of Zilbershtein by teaching of in case of a positive detection, storing said entitlement tag in a list of nontrusted tags, as taught by Cline, to generate list of the client addresses that are potentially of attacker for future protection, as disclosed in Cline, par. 0005.
Regarding claim 2, The method according to claim 1,
Vinukonda further discloses, wherein the entitlement tag includes at least one of a client identifier, a random number, and a counter value (Par. 0053, the user device transmits the secure token along with a current IP address of the user device (i.e. entitlement tag = IP address of user device) with any subsequent request made to a CDN server to download a playlist, media segment).
Regarding claim 3, The method according to claim 1,
Vinukonda in view of Zilbershtein in further view of Cline further discloses, further comprising, upon an unsuccessful check of the token, rejecting the digital content segment request or transmitting a content segment related to a predefined content different from the requested content (Zilbershtein Par. 0027, the anti-piracy controller 106 instructs the control plane 103 and/or the CDNs 104 to perform further anti-piracy actions, e.g., disrupting services and/or streaming to client device N 102-N via CDN M 104-M).
Regarding claim 4, The method according to claim 1,
Vinukonda further discloses, wherein the checking the token includes verifying a digital signature of said token and/or successfully decrypting said token (Par. 0105, fig. 7, a tokenized URL comprising a secure token. URL 702 includes a reference to the resource (e.g., a content master playlist, variant media playlist, content segment, etc.) and a number of embedded parameters, i.e., ih, x and s, the x parameter comprises an expiration of the secure token, and the s parameter comprises a URL signature (e.g., a hash, such as and without limitation an MD5 hash, of the URL 702 including the ih and s parameters). The URL signature can be used to ensure that the URL has not been tampered with. In addition, the URL signature can be decrypted (e.g., using a decryption key that is shared between the CMS server 504 and the CDN server 506) to retrieve the ih and s parameters).
Regarding claim 6, The method according to claim 1,
Vinukonda further discloses, wherein the checking the token includes verifying that a validity time period of the token has not expired (Par. 0015 the received secure token can have an associated short-lived expiration time which can be retrieved from the received secure token, and the expiration time can be checked against a time associated with the content download request to ensure that the secure token is not expired (is still live)).
Regarding claim 8, The method according to claim 1,
Vinukonda further discloses, further comprising by a content platform:
receiving a selection of a digital content from an authenticated requestor (Par. 0069, a video application and/or video platform, can be provided via the application server 108, whereby a user is able to utilize such service upon the user being authenticated, verified or identified by the service. Par. 0098, a request is received by secure token generator 302 from a media playback component (e.g., a media player) of a user device (e.g., client device 101, mobile devices 102-104, mobile device 200 or the like). The request identifies the IP address of the user device. The request may be a user's request to experience (e.g., view and/or listen to) an item of content identified in the request. The request might be initiated in response to the user's content selection (e.g., a hyperlink selection) in a web page displayed in a graphical user interface (GUI) of a browser application executing on the user device, a GUI of the media player); and
in response to said selection, generating the token including the entitlement tag and transmitting the generated token to the authenticated requestor (Par. 0102, The IP address associated with the content access request can be the IP address received with the content access request 508, in the example of FIG. 5. This IP address can be used alone or in combination with other information (e.g., an expiration time) in generating the secure token. The secure token can be generated after a determination is made that there are no access restrictions and/or the user is determined to be a user authorized to access the requested content, Par. 0103, the secure token is transmitted to the user device 502 from which the content access request 508 is received, in response to the received content access request 508).
Regarding claim 9, The method according to claim 8,
Vinukonda further discloses, further comprising signing and/or encrypting the generated token, by the content platform (Par. 0103, The secure token can be generated by encrypting the information using an encryption algorithm such as MD5).
Regarding claim 10, The method according to claim 8,
Vinukonda further discloses, further comprising by the content platform:
in response to the selection of the digital content from the authenticated requestor, producing a network address to access the selected digital content, including the generated token in said network address, and transmitting said network address to the requestor (Par. 0098, fig. 4, at step 402, a request is received to experience (e.g., view and/or listen to) an item of content. The request identifies the IP address of the user device. Par. 0102, step 404, token is generated and associated with the IP address, Par. 0104-0105, fig. 4, 5, secure token is transmitted as part of the URL, URL (i.e. network address) includes reference to the content and hash of client IP address (e.g., the IP address of the user device 502 accompanying the content access request), i.e. URL includes generated token and also includes the client IP address, therefore it is generated in response to receiving request for content from client device which identifies the client IP address).
Regarding claim 13, the method according to claim 1,
Vinukonda in view of Zilbershtein in further view of Cline further discloses, wherein the storing records and analyzing the stored records are performed by a management system from records stored by a plurality of distributed edge servers of the content delivery network (Zilbershtein Par. 0021, the OTT content delivery system 100 includes a control plane 103 and a plurality of CDNs 104, e.g., CDN 1 104-1, CDN 2 104-2, . . . , CDN 104-M, etc. The CDNs 104 (e.g., geographically dispersed servers) facilitate streaming media content and/or delivering services, Par. 0025, a piracy detector 105 obtains the CDN logs from the authorization sub-system (i.e., the CDNs 104) ), and the management system transmits a list of non-trusted tags to the distributed edge servers (Zilbershtein Par. 0072 exporting a report identifying the one or more pirated client devices in real-time, e.g., exporting a piracy report by the suspected piracy export module 210 in FIG. 2, and causing disruption of access from the one or more pirated client devices based on the report, e.g., the anti-piracy controller 106 takes anti-piracy actions against the pirate 101-N based on the detection results from the piracy detector 105 as shown in FIG. 1. In some embodiments, when anti-piracy controller 106 applies the anti-piracy actions to all CDN nodes, e.g., CDNs 104 in FIG. 1. As such, despite the network connection of the client device, e.g., the pirate changing to another node at some point, and regardless of the number of client devices the pirate uses for concurrent attacks, the piracy actions can be detected and stopped).
Regarding claims 14, see rejection of claim 1.
Regarding claims 15, see rejection of claim 8.
Regarding claims 16, see rejection of claim 1
Regarding claims 17, 18, and 19, see rejection of claims 2, 3, and 4, respectively.
Regarding claim 21, the method according to claim 1,
Vinukonda in view of Zilbershtein in further view of Cline further discloses, wherein the entitlement tag includes data different from an IP address of the requestor (Zilbershtein Par. 0068, the respective distribution key can be an identifier associated with a respective client device such as a client ID).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Vinukonda et al. (US 20180205742), in view of Zilbershtein et al. (US 20220345474), in further view of Cline et al. (US 20130055375), in further view of Tsarfati et al (US 20210314339).
Regarding claim 5, the method according to claim 1,
Vinukonda in view of Zilbershtein in further view of Cline does not discloses, wherein the checking the token includes verifying that the entitlement tag included in the token is not included in the stored list of non-trusted tags.
Tsarfati discloses, wherein the checking the token includes verifying that the entitlement tag included in the token is not included in the stored list of non-trusted tags (Par. 0055, scanning applications that are configured for network communications (e.g., browsers, social media applications, entertainment applications, financial services applications, database applications, etc.) and inspecting them for embedded (e.g., programmed or stored) network addresses. The identified network addresses may then be compared against a list (e.g., whitelist or blacklist) to determine whether the addresses are valid or potentially malicious, i.e. network address listed in non-trusted address or blacklist).
It would have been obvious to a skilled artisan before the effective filing date of the claimed invention to modify the system of Vinukonda in view of Zilbershtein in further view of Cline by teaching of wherein the checking the token includes verifying that the entitlement tag included in the token is not included in the stored list of non-trusted tags, as taught by Tsarfati, to implement appropriate security controls to protect against illegitimate or malicious access, as disclosed in Tsarfati, par. 0005.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Vinukonda et al. (US 20180205742), in view of Zilbershtein et al. (US 20220345474), in further view of Cline et al. (US 20130055375), in further view of Tsarfati et al (US 20230319025).
Regarding claim 7, the method according to claim 1,
Vinukonda in view of Zilbershtein in further view of Cline does not discloses, wherein the storing the record includes storing, in association with the entitlement tag, additional data including at least one of a content identifier, a network address of a requestor, and timestamp data of a reception time of the content segment request.
Srivastava discloses, wherein the storing the record includes storing, in association with the entitlement tag, additional data including at least one of a content identifier, a network address of a requestor, and timestamp data of a reception time of the content segment request (Par. 0015, The server device further generates a log record corresponding to the request, the log record including the USN (authorized unique session number or tag)), and stores the log record stored in a file or database. Par. 0016, In addition to the USN, the log records may also include a time stamp associated with the request, the identity of the user record, an IP address associated with the request).
It would have been obvious to a skilled artisan before the effective filing date of the claimed invention to modify the system of Vinukonda in view of Zilbershtein in further view of Cline by teaching of wherein the storing the record includes storing, in association with the entitlement tag, additional data including at least one of a content identifier, a network address of a requestor, and timestamp data of a reception time of the content segment request, as taught by Srivastava, to determine suspicious activities based on information associated time stamps and network addresses, as disclosed in Srivastava, par. 0016.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Vinukonda et al. (US 20180205742), in view of Zilbershtein et al. (US 20220345474), in further view of Cline et al. (US 20130055375), in further view of Freedman et al (US 20190251281).
Regarding claim 11, the method according to claim 1,
Vinukonda in view of Zilbershtein in further view of Cline does not disclose, wherein the analyzing the stored records is performed using a machine learning model.
Freedman discloses, the method according to claim 1, wherein the analyzing the stored records is performed using a machine learning model.
wherein the analyzing the stored records is performed using a machine learning model (Par. 0037, the data exchange may evaluate user-request patterns across multiple secondary assignment systems to identify trends within the behavior patterns, the data provided to and received from the data exchange may include anomaly analytics, bot patterns, Par. 0224, Data exchange 1050 can receive the data representing reassignments, and evaluate the data using one or more machine-learning techniques (e.g., clustering) to identify patterns or trends within the data. In some cases, secondary assignment system 216b may subscribe to data exchange 1050 to view the patterns or trends identified by data exchange, i.e. using machine Learning to identify user request pattern to identifying invalid access rights).
It would have been obvious to a skilled artisan before the effective filing date of the claimed invention to modify the system of Vinukonda in view of Zilbershtein in further view of Cline by teaching of wherein the analyzing the stored records is performed using a machine learning model, as taught by Freedman, to identify patterns and trends by clustering of data using machine learning analysis, as disclosed in Freedman, par. 0037 and 0224.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Vinukonda et al. (US 20180205742), in view of Zilbershtein et al. (US 20220345474), in further view of Cline et al. (US 20130055375), in further view of Mittal et al (US 20120102329).
Regarding claim 12, the method according to claim 1,
Vinukonda in view of Zilbershtein in further view of Cline does not disclose, further comprising watermarking at least part of the digital content segments transmitted to the requestor with the respective entitlement tag.
Mittal does not disclose, further comprising watermarking at least part of the digital content segments transmitted to the requestor with the respective entitlement tag (Par. 0192, the method 900 may include watermarking the content with a unique identifier associated with the client device prior to encryption. For instance, the unique identifier may include a license number assigned to the client device by the secure publishing system).
It would have been obvious to a skilled artisan before the effective filing date of the claimed invention to modify the system of Vinukonda in view of Zilbershtein in further view of Cline by teaching of watermarking at least part of the digital content segments transmitted to the requestor with the respective entitlement tag, as taught by Mittal, to fraud detection and content piracy reduction, as disclosed in Mittal, par. 0105.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AKSHAY DOSHI whose telephone number is (571)272-2736. The examiner can normally be reached M-F 9:30 AM to 6:00 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, JOHN W MILLER can be reached at (571)272-7353. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.D./Examiner, Art Unit 2422
/JOHN W MILLER/Supervisory Patent Examiner, Art Unit 2422
Prosecution Insights