System and method for evaluating client device trust in a distributed computing system

Abstract

A method includes receiving, by a processing device of a content sharing platform, a request for desired content from a client device, the content being stored in a content delivery network (CDN). The method also includes generating a partial trust metric associated with the client device based on data available to the content sharing platform, wherein the partial trust metric is to be used by a CDN server to make a decision regarding the client device accessing the desired content. The method also includes generating a response to the content request, wherein the response includes one or more resource locators for accessing the desired content in the CDN and the partial trust metric. The method also includes sending the response to the client device to enable the client device to request the desired content from the CDN server using the resource locators and the partial trust metric.

Description

Technical Field

[0001] Various aspects and embodiments of this disclosure relate to content sharing platforms, and more specifically to assessing client device trust in distributed computing systems. Background Technology

[0002] Content delivery platforms connected via the internet allow users to connect with each other and share information. Many content delivery platforms include content sharing features that allow users to upload, view, and share content such as video projects, image projects, and audio projects. Other users of the content delivery platform can comment on shared content, discover new content, locate updates, share content, and otherwise interact with the offered content. Shared content can include: content from professional content creators, such as film clips, television clips, and music video projects; and content from amateur content creators, such as vlogs and short original video projects. Summary of the Invention

[0003] One aspect of this disclosure provides a method comprising: receiving, by a processing device of a content sharing platform, a request for desired content from a client device, the content being stored in a content delivery network (CDN); generating a partial trust metric associated with the client device based on data available to the content sharing platform, wherein the partial trust metric will be used by a CDN server to make a decision regarding the client device's access to the desired content; generating a response to the content request, wherein the response includes one or more resource locators for accessing the desired content in the CDN and the partial trust metric; and sending the response to the client device to enable the client device to request the desired content from the CDN server using the one or more resource locators and the partial trust metric.

[0004] Another aspect of this disclosure provides a system comprising: a memory; and a processing device coupled to the memory to: receive, by the processing device of a content sharing platform, a request for desired content stored in a content delivery network (CDN) from a client device; generate a trust packet associated with the client device based on data available to the content sharing platform, wherein the trust packet will be used by the CDN server to make a decision regarding the client device's access to the desired content; generate a response to the content request, wherein the response includes one or more resource locators and the trust packet for accessing the desired content in the CDN; and send a response to the client device to enable the client device to request the desired content from the CDN server using the one or more resource locators and the trust packet.

[0005] Another aspect of this disclosure provides a computer program product (such as a tangible computer-readable medium or a software product that can be downloaded without necessarily being stored in a non-transitory manner) including instructions that, in response to execution by a processing device, cause the processing device to perform operations including methods according to any aspect or embodiment described herein. Attached Figure Description

[0006] The various aspects and embodiments of this disclosure will be more fully understood from the following detailed description and the accompanying drawings, which illustrate various aspects and embodiments of this disclosure. However, this disclosure should not be construed as limiting the disclosure to any particular aspect or embodiment, but is intended for explanation and understanding.

[0007] Figure 1 An example system architecture according to an embodiment of the present disclosure is illustrated.

[0008] Figure 2 This is a diagram illustrating operations for assessing client device trust according to embodiments of the present disclosure.

[0009] Figure 3 This is another diagram of operations for assessing client device trust according to embodiments of this disclosure.

[0010] Figure 4 A flowchart is depicted for a method for generating a partial trust metric according to embodiments of the present disclosure.

[0011] Figure 5 A flowchart is depicted for a method for determining the trust status of a client device according to embodiments of the present disclosure.

[0012] Figure 6 This is a block diagram illustrating an exemplary computer system according to an embodiment of the present disclosure. Detailed Implementation

[0013] Content-sharing platforms (also referred to herein as “content delivery platforms”) can serve content, such as video projects, audio projects, or game projects, to users via client devices. Users can log in to a user account associated with the content-sharing platform to access the platform and upload and / or consume content. Content-sharing platforms can use a content delivery network (CDN) (also referred to herein as a “content delivery network”) to store content and serve it to client devices. A CDN can include a geographically distributed network of servers that work together to provide high availability and high performance in content delivery. For example, server A of the CDN, located in the same geographical proximity as client device A, can be chosen to deliver content to client device A. Content delivered by server A can be delivered to client device A faster than by another server of the CDN that is not located in the same geographical proximity as client device A, i.e., server B of the CDN.

[0014] In some systems, users can request content from a content-sharing platform via a media player on a client device (e.g., a mobile application, a web browser, etc.). The content-sharing platform uses an authorization service to authorize a user account associated with the user to determine if the user is authorized to access the requested content. If the user account is authorized to access the content, the content-sharing platform can generate one or more resource locators (e.g., Uniform Resource Locators (URLs)) that the client device can use to retrieve the requested content from the CDN. For example, the content-sharing platform can generate a URL, send it to the client device, and the client device can use the URL to request the desired content from the CDN.

[0015] However, in some instances, users can access content from the CDN using unauthorized media players (e.g., overlay apps, third-party media players, modified media players, etc.) and perform unauthorized functions on the received content. For example, an unauthorized media player could download the received content to local storage media, a feature that content-sharing platforms may prohibit. In other instances, users can deceive content-sharing platforms and CDNs by requesting a URL from the content-sharing platform using an authorized media player, and then requesting content from the CDN using the same URL using an unauthorized media player. This deception is possible because, for security reasons, content-sharing platforms may expect not to share data related to user account information, authentication protocols, etc., with the CDN (which may be more vulnerable to security vulnerabilities than the content-sharing platform's highly privileged core services). Therefore, the CDN may not be able to accurately assess the trustworthiness of the client device sending the request for content.

[0016] Therefore, in the current system, it is difficult to identify content requests from unauthorized media players. This may lead content sharing platforms and / or CDNs to incorrectly grant unauthorized media players permission to access requested content, causing them to perform unauthorized functions on the received content.

[0017] The aspects and implementations of this disclosure address these and other drawbacks of the prior art by enabling content-sharing platforms to generate partial trust metrics for use by CDNs to determine the trustworthiness (e.g., authenticity) of client devices. In an example embodiment, in response to receiving a request for content from a client device, the content-sharing platform can generate a partial trust metric for the client device. The partial trust metric can be any score, indicator, or other type of quantifiable measure used to indicate to the CDN the authenticity of the client device, the media player used by the client device, or the user account associated with the user. Specifically, the partial trust metric can be created based on data available to the content-sharing platform and can be used to indicate to the CDN the likelihood that the user, media player, and / or client device are authorized to access the requested content, in contrast to unauthorized entities such as third-party media players, bots, server farms, etc. The data used to create the partial trust metric can include factors associated with the client device, user account, media player, or any combination thereof. In some embodiments, these factors can include: the user's viewing history, whether the user has previously viewed content, whether the client device has previously successfully decrypted content, whether the user is logged in, whether the user has participated in or is suspected of participating in unauthorized activities, the client device's IP address, encrypted logs associated with the client device, etc. In some embodiments, content-sharing platforms may generate partial trust metrics by using heuristics, machine learning, or other methods.

[0018] The content-sharing platform can then generate one or more resource locators (e.g., Uniform Resource Locators (URLs)) to enable client devices to request desired content from the CDN. The content-sharing platform can append a partial trust metric to the resource locator and digitally sign the resulting response. The digital signature can be based on signature parameters (e.g., expiration parameters indicating when the use of the resource locator and / or partial trust metric should expire, bitrate parameters used to deliver the requested content, identifiers for creating and associating playback events for the content request, etc.) used to instruct the CDN how the data should be served. Client devices can use the resource locator and partial trust metric received from the content-sharing platform to request content from the CDN server.

[0019] In response to receiving a request with a resource locator and a partial trust metric from a client device, the CDN server can determine the client device's trust status based on the partial trust metric. The client device's trust status can be any type of indicator that the CDN uses to determine whether to provide the requested content to the user. In some embodiments, the CDN can use the partial trust metric and one or more additional factors identified by the CDN (based on information available to the CDN) to obtain a final trust metric, and compare the final trust metric with one or more thresholds to determine the client device's trust status (e.g., high reliability, medium reliability, low reliability). Based on this comparison, the CDN can reduce or limit the resolution of the requested content (e.g., from high definition to standard definition), reduce or limit the frame rate, and so on.

[0020] In some embodiments, if the content sharing platform provides multiple resource locators for the desired content, the client device sends separate requests for each resource locator to the CDN server, including a partial trust metric received from the content sharing platform in each of these requests. Based on the partial trust metric included in each request, the CDN server can ensure that all multiple requests for the desired content (e.g., multiple requests for a portion of a specific video) originate from a trusted media player, thereby preventing malicious users from using an authorized media player to obtain the first portion of the desired content and then switching to an unauthorized player to obtain the remaining content.

[0021] In some embodiments, instead of providing a partial trust metric to the client device, the content sharing platform can provide a trust packet that includes multiple characteristics, such as whether the user is logged in, the type of browser the user used to request the content, the geographical location of the client device, the IP address of the client device, etc. When requesting content from a CDN server, the client device can provide the trust packet to the CDN server, which can then use the characteristics from the trust packet (and in some embodiments, information available locally to the CDN server) to determine whether to provide the requested content to the user.

[0022] The aspects of this disclosure offer technical advantages in improving the performance of media players on client devices, enhancing the security of content stored on CDNs, improving the security of user data, and improving the overall performance and security of content-sharing platforms. Specifically, the aspects of this disclosure enable content-sharing platforms and CDNs to verify the authenticity of media players requesting content without subjecting users to delays associated with extended verification techniques. Therefore, the techniques disclosed herein provide users with a stable and uninterrupted viewing experience. Furthermore, the aspects of this disclosure enable CDNs to verify user accounts and / or client devices based on opaque partial trust measurements that do not expose the CDN (which may be vulnerable to external attacks) to known information about the highly secure core services of the content-sharing platform used to generate the partial trust measurements. Additionally, the techniques disclosed herein can include reducing the computational, memory, and bandwidth resource consumption of content-sharing platforms by allowing the CDN to authorize the delivery of requested content.

[0023] For the sake of brevity, embodiments of this disclosure frequently refer to video. However, the teachings of this disclosure are generally applicable to media projects and can be applied to various types of content, including, for example, video, audio, text, images, program instructions, etc.

[0024] Figure 1 An example system architecture 100 according to one embodiment of the present disclosure is illustrated. System architecture 100 (also referred to herein as the “system”) includes a content sharing platform 120 (also referred to herein as a “content delivery platform”), a data warehouse 106, client devices 110A-110Z (generally referred to herein as “client devices 110”) connected to a network 104, and a content delivery network (CDN) 130 (also referred to herein as a “content delivery network”). CDN 130 may include multiple server machines 132A-132Z (also referred to herein as “servers 132A-132Z”).

[0025] Network 104 may include public networks (such as the Internet), private networks (such as local area networks (LANs) or wide area networks (WANs)), wired networks (such as Ethernet), wireless networks (such as 802.11 networks or Wi-Fi networks), cellular networks (such as LTE networks), routers, hubs, switches, server computers, and / or combinations thereof.

[0026] Data repository 106 may be persistent storage capable of storing content items (such as media items) and data structures for tagging, organizing, and indexing content items. Data repository 106 may be hosted by one or more storage devices, such as main memory, magnetic or optical storage-based disks, tape or hard disk drives, NAS, SAN, etc. In some embodiments, data repository 106 may be a network-attached file server, while in other embodiments, data repository 106 may be some other type of persistent storage, such as an object-oriented database, relational database, etc., which may be hosted by content sharing platform 120 or one or more different machines coupled to content sharing platform 120. In some embodiments, data repository 106 may be coupled to content sharing platform 120 via network 104.

[0027] Client devices 110A-110Z may each include a computing device, such as a personal computer (PC), laptop, mobile phone, smartphone, tablet, netbook, network-connected TV, etc. In some embodiments, client devices 110A-110Z may also be referred to as "user devices". In some embodiments, each client device 110A-110Z may include a media player 112 (or media viewer) and a token module 114. In some embodiments, media player 112 may be an application that allows users to play back, view, or upload content such as images, video items, web pages, documents, audio items, etc. For example, media player 112 may be a web browser capable of accessing, retrieving, rendering, or navigating content served by a web server (e.g., web pages such as Hypertext Markup Language (HTML) pages, digital media items, etc.). Media player 112 may render, display, or present content (e.g., web pages, media viewer) to the user. Media player 112 may also include an embedded media player (e.g., embedded in a web page, such as a web page that provides information about products sold by an online merchant) embedded in a web page (e.g., a web page that provides information about products sold by an online merchant). (Media player or HTML5 player). In another example, media player 112 may be a standalone application (e.g., a mobile application or a native application) that allows users to play back digital media items (e.g., digital video items, digital images, e-books, etc.). According to various aspects of this disclosure, media player 112 may be a content-sharing platform application for users to record, edit, and / or upload content for sharing on a content-sharing platform. Thus, media player 112 may be provided by content-sharing platform 120 to client devices 110A-110Z. For example, media player 112 may be an embedded media player embedded in a webpage provided by content-sharing platform 120. In another example, media player 112 may be an application downloaded from content-sharing platform 120.

[0028] In some embodiments, the content sharing platform 120 and / or server machines 132A-132Z may be one or more computing devices (such as rack-mounted servers, router computers, server computers, personal computers, mainframe computers, laptop computers, tablet computers, desktop computers, etc.), data warehousing (e.g., hard disks, storage devices, databases), networks, software components, or hardware components that can be used to provide users with access to or to provide media items to users. For example, the content sharing platform 120 may allow users to consume, upload, search, approve (“likes”), disapprove (“dislikes”), or comment on media items. The content sharing platform 120 may also include websites (e.g., web pages) or application backend software that can be used to provide users with access to media items.

[0029] In some embodiments of this disclosure, "user" may refer to a single individual. However, other embodiments of this disclosure encompass "user" as an entity controlled by a set of users and / or an automated source. For example, a set of individual users united as a community in a social network can be considered a "user." In another example, an automated consumer may be an automated ingestion pipeline of a content-sharing platform 120, such as a topic channel.

[0030] Content sharing platform 120 may include multiple channels (e.g., channels A to Z, where only channel A is present). Figure 1 (As shown in the image). A channel can be data content available from a public source, or data content with a public topic, theme, or essence. Data content can be digital content selected by users, digital content available to users, digital content uploaded by users, digital content selected by content providers, digital content selected by broadcasters, etc. For example, channel X can include videos Y and Z. A channel can be associated with an owner, who is a user who can perform actions on the channel. Different activities can be associated with a channel based on the owner's actions—such as the owner making digital content available on the channel, the owner selecting (e.g., liking) digital content associated with another channel, the owner commenting on digital content associated with another channel, etc. The activities associated with the channel can be collected into the channel's activity feed. In addition to the channel owner, users can subscribe to one or more channels they are interested in. The concept of "subscription" can also be referred to as "like," "follow," "friend," etc.

[0031] Once a user subscribes to a channel, information from that channel's activity feeds can be provided to the user. If a user subscribes to multiple channels, the activity feeds from each channel can be combined into a joint activity feed. Information from the joint activity feed can then be presented to the user. Channels may have their own feeds. For example, when navigating to a channel's homepage on a content-sharing platform, feed items generated by that channel can be displayed on the channel's homepage. Users can have joint feeds, which are feeds that include at least a subset of content items from all the channels the user subscribes to. Joint feeds can also include content items from channels the user does not subscribe to. For example, content-sharing platforms like 120 or other social networks can insert recommended content items into a user's joint feed, or they can insert content items associated with the user's relevant links into the joint feed.

[0032] Each channel may include one or more media items 122. Examples of media items 122 may include, but are not limited to, digital video, digital film, digital photograph, digital music, audio content, melodies, website content, social media updates, ebooks, e-magazines, digital newspapers, digital audiobooks, e-journals, web blogs, Real Simple Union (RSS) feeds, e-comic books, software applications, etc. In some embodiments, media items 122 are also referred to as content or content items.

[0033] For the sake of brevity and not limitation, throughout this document, video projects, audio projects, or game projects are used as examples of media project 122. As used herein, “media,” “media project,” “online media project,” “digital media,” “digital media project,” “content,” and “content project” can include electronic files that can be executed or loaded using software, firmware, or hardware configured to present digital media projects to entities. In one embodiment, content sharing platform 120 may use data repository 106 to store media project 122. In another embodiment, content sharing platform 120 may use data repository 106 to store video projects or fingerprints as electronic files in one or more formats.

[0034] In some embodiments, media item 122 is a video item. A video item is a set of consecutive video frames (e.g., image frames) representing a scene in motion. For example, a series of consecutive video frames can be captured sequentially or reconstructed later to produce an animation. Video items can be presented in various formats, including but not limited to analog, digital, two-dimensional, and three-dimensional video. Furthermore, a video item can include a movie, video clip, or any set of animated images to be displayed in sequence. Additionally, a video item can be stored as a video file comprising video and audio components. Video components can refer to video data in a video encoding format or an image encoding format (e.g., H.264 (MPEG-4 AVC), H.264 MPEG-4 Part 2, Graphics Interchange Format (GIF), WebP, etc.). Audio components can refer to audio data in an audio encoding format (e.g., Advanced Audio Coding (AAC), MP3, etc.). Note that a GIF can be saved as an image file (e.g., a .gif file) or as a series of images in an animated GIF (e.g., GIF89a format). It can be noted that H.264 can be a video encoding format, such as a block-oriented motion-compensated video compression standard used for recording, compressing, or distributing video content.

[0035] In some embodiments, a media item may be streamed, such as being transmitted in a live stream to one or more client devices among client devices 110A-110Z. It should be noted that “streamed” or “broadcast” refers to the transmission or broadcast of content such as a media item, wherein the receiving device may (within technical limitations) immediately replay the received portion of the media item while it is being received or while other portions of the media content are being delivered and the entire media item has not yet been received by the receiving device. “Stream” can refer to content that is streamed or broadcast, such as a media item. A live streaming media item can refer to the live broadcast or transmission of a live event, wherein the media item is at least partially transmitted to the receiving device simultaneously with the event, and wherein the media item as a whole is unavailable.

[0036] In some embodiments, content sharing platform 120 may allow users to create, share, view, or use playlists containing media items (e.g., playlist AZ, containing media items 122). A playlist is a collection of media items configured to be played one after another in a specific order without any user interaction. In some embodiments, content sharing platform 120 may maintain playlists on behalf of users. In some embodiments, playlist features of content sharing platform 120 allow users to group their favorite media items together for playback in a single location. In embodiments, content sharing platform 120 may send media items from a playlist to client device 110 for playback or display. For example, media viewer 112 may be used to play media items from a playlist in the order they are listed on the playlist. In another example, a user may switch between media items on a playlist. In yet another example, a user may wait for the next media item on the playlist to play, or may select a specific media item from the playlist to play.

[0037] In some embodiments, a user can access content on the sharing platform 120 through a user account. A user can access (e.g., log in) a user account by providing user account information (e.g., username and password) via an application (e.g., media viewer 112) on a client device 110. In some embodiments, a user account may be associated with a single user. In other embodiments, a user account may be a shared account (e.g., a family account shared by multiple users) (also referred to herein as a "shared user account"). A shared account may have multiple user profiles, each associated with a different user. Multiple users can log in to the shared account using the same account information or different account information. In some embodiments, multiple users of a shared account can be distinguished based on different user profiles of the shared account.

[0038] In some embodiments, the Authorization Data Service 124 (also referred to herein as the “Core Data Service” or “Authorization Data Source”) is a highly secure service that has access to data relating to user accounts on the Content Sharing Platform 120 and can use that data to determine whether to authorize a user account to access requested content. In some embodiments, the Authorization Data Service 124 may authorize a user account (e.g., a client device associated with that user account) to access requested content, authorize the delivery of the requested content to the client device, or both. Authorizing a user account to access requested content may involve authorizing what content to access and who is authorized to access that content. Authorizing the delivery of content may involve authorizing how the content is delivered.

[0039] In some embodiments, the authorization data service 124 may use user account information to authorize a user account. In some embodiments, an authentication token associated with the client device 110 or media player 112 may be used to determine whether to authorize a user account and / or playback of the requested content.

[0040] In some embodiments, the authorization data service 124 is part of the content sharing platform 120. In other embodiments, the authorization data service 124 may be an external service, such as a highly secure authorization service provided by a third party.

[0041] As described above, the Content Delivery Network (CDN) 130 may include one or more nodes, referred to as server machines 132A-132Z (generally referred to herein as "server machine 132" or "server 132"). In embodiments, the content delivery network 130 includes a geographically distributed network of servers that work together to provide rapid delivery of content. The server network is geographically distributed to provide high availability and performance by distributing content or services based on proximity to client device 110 in some instances. The closer the CDN server is to client device 110, the faster the content can be delivered to client device 110.

[0042] For example, different server machines 132A-132Z may be geographically distributed within a specific country or across different countries. User A, using client device 110A located in the UK, may request content hosted by content sharing platform 120. This request can be received through the authorization data service 124 of content sharing platform 120, and the user account associated with user A can be authorized to retrieve the requested content. Following authorization, content sharing platform 120 may send a resource locator, such as a Uniform Resource Locator (URL), to client device 110A. A resource locator may indicate the location or address of a resource (e.g., content) on a computer network and a reference to a mechanism used to retrieve the resource. The resource locator may instruct client device 110A to retrieve the content from server machine 132 of content delivery network 130, which is geographically located near client device 110A. For example, the resource locator may instruct client device 110A to retrieve the requested content from a specific server machine 132 of content delivery network 130, also located in the UK. In another example, another user B, using client device 110B located on the West Coast of the United States, requests the same content as user A. This request can be received by the authorization data service 124 of the content sharing platform 120, and the user account associated with user B can be authorized to access the requested content. Following authorization, the content sharing platform 120 can send a resource locator to client device 110B. The resource locator can instruct client device 110B to retrieve the content from server machine 132 of the content delivery network 130, which is geographically located near client device 110B. For example, the resource locator could instruct client device 110B to retrieve the requested content from server machine 132 of the content delivery network 130 located on the West Coast of the United States.

[0043] In some embodiments, content delivery network 130 is part of content sharing platform 120. In other embodiments, content delivery network 130 is a third-party platform providing CDN services to content sharing platform 120. In other embodiments, some parts of content delivery network 130 may be operated by content sharing platform 120, while other parts of content delivery network 130 may be operated by a third party. In embodiments, content delivery network 130 includes a data repository, such as data repository 134. Data repository 134 may be similar to data repository 106. The data repository may include data files 136 for content such as media content. Data repository 106 may also include one or more encryption keys 137, such as one or more public keys or one or more private keys.

[0044] Authorization module 138 may be included in server 132 of CDN 130. Authorization module 138 may perform various aspects of this disclosure as described herein. For example, authorization module 138 may determine the client device trust state. The client device trust state may be any type of indicator used by CDN 130 to determine whether to release the requested content to the user. As explained in more detail herein, the client device trust state may be determined based on partial trust metrics or trust packets.

[0045] Typically, in other embodiments, functions described in one embodiment as being performed by content sharing platform 120 and / or content delivery network 130 may also be performed on client devices 110A to 110Z, if appropriate. Furthermore, functionality belonging to a particular component may be performed by different or multiple components operating together. Content sharing platform 120 or content delivery network 130 may also be accessible as a service provided to other systems or devices through appropriate application programming interfaces, and is therefore not limited to use on a website.

[0046] Although embodiments of this disclosure are discussed in the context of a content-sharing platform and a social network facilitating the sharing of content items on a content-sharing platform 120, the embodiments are generally applicable to any type of social network or content delivery platform that provides connectivity between users. Implementations of this disclosure are not limited to content-sharing platforms that offer channel subscriptions to users.

[0047] In addition to the above description, users may be provided with controls that allow them to choose whether and when the system, program, or feature described herein enables the collection of user information (e.g., information about the user's social networks, social actions or activities, occupation, user preferences, or the user's current location), and whether content or communications are sent to the user from the server. Furthermore, some data may be processed in one or more ways before storage or use, thereby removing personally identifiable information. For example, a user's identity may be processed so that the user's personally identifiable information cannot be determined, or the user's geographic location may be generalized (e.g., down to the city, zip code, or state level) where location information is obtained, making it impossible to determine the user's specific location. Therefore, users may have control over what information about themselves is collected, how that information is used, and what information is provided to them.

[0048] Figure 2 This is a diagram illustrating operations for evaluating client device trust according to embodiments of this disclosure. System 200 may include... Figure 1 The system architecture has 100 similar components. It can be noted that... Figure 1 The components can be used to help describe Figure 2For illustrative and non-limiting purposes, the operation of system 200 is described as being performed via the licensed data service 124 of content sharing platform 120, the server machine 132 of content delivery network 130, or the client device 110, and may be performed by any of its components, unless otherwise described. For illustrative and non-limiting purposes, regarding Figure 2 The described operations are shown as being performed in a sequential order. It can be noted that the operations can be performed in any order, and any operation can be performed concurrently with one or more other operations. In some implementations, the same, different, fewer, or more operations can be performed in any order.

[0049] In operation 202, in response to user input regarding content, client device 110 sends a request to the authorized data service 124 of content sharing platform 120 to retrieve the content. For example, a user of client device 110 may request to play a video project hosted by content sharing platform 120. In some embodiments, the user may use an application such as a browser or a native application to request content from content sharing platform 120. The content may be stored on one or more nodes or servers (one or more CDN servers 132) of a content delivery network.

[0050] In some embodiments, a request from client device 110 to authorized data service 124 may include the format of the data to be received. For example, the request may include the format of a video item compatible with media viewer 112 at client device 110. In some embodiments, the request may include additional information (e.g., type, version, etc.) related to media viewer 112, at which content such as the video item will be played back.

[0051] In some embodiments, a content request may include an identifier of a client device or a user account attempting to access the content. For example, a user request may identify the username and password associated with the user account requesting access to the content. In another example, the request may include a cookie identifying an application on client device 110 or the user device, which may be used to identify a specific user account. For example, a user may log in to content sharing platform 120 using user account information, and in response to authorization of the user account by content sharing platform 120, content sharing platform 120 may send a cookie to user device 120. In yet another example, a content request may include other data associated with a user or user account, such as, for example, an Internet Protocol (IP) address associated with a client device.

[0052] In operation 204, the authorization data service 124 of the content sharing platform 120 can generate a partial trust metric associated with the content request. The partial trust metric can be any score, indicator, or other type of quantifiable measure used to indicate to the server 132 the authenticity of the client device, the media player used by the client device, or the user account. Specifically, the partial trust metric can be used to indicate to the CDN server 132 the likelihood that the user, media player, and / or client device is trustworthy and should be authorized to access the requested content, in contrast to unauthorized entities (e.g., unauthorized media players, bots, server farms, etc.).

[0053] The authorization data service 124 can generate partial trust metrics based on factors (e.g., data, signals, etc.) associated with the client device 110 (or user account, media player 112, or any combination thereof). One or more factors may be accessible through the authorization data service 124 but unavailable to the server 132. In some embodiments, these factors may include: the user's viewing history, whether the user has previously viewed content, whether the client device has previously successfully decrypted content, whether the user is logged in, whether the user has participated in or is suspected of participating in authorization activities, the user's IP address, encrypted logs associated with the user, etc.

[0054] In some embodiments, the authorization data service 124 may generate a partial trust metric using heuristics. According to the heuristics, the authorization data service 124 uses heuristic rules that involve assigning weights and values ​​between 0 and 1 to each factor used in generating the partial trust metric, and combining the weighted factors to generate the partial trust metric. In one example, for the factor of whether the client device has previously successfully decrypted content, a value of 0 may be assigned if the user has not previously successfully decrypted the content, or a value of 1 may be assigned if the user has previously successfully decrypted the content. In another example, for the factor of whether the client device has previously successfully decrypted content, a value of 0 may be assigned if the user has not previously successfully decrypted the content, a value of 0.5 may be assigned if the user has previously successfully decrypted the content less than five times, and a value of 1 may be assigned if the user has previously successfully decrypted the content at least five times. Different scales and any numerical scores may be used with each factor to determine the partial trust metric. Therefore, in some embodiments, the partial trust metric may be the sum of each weighted factor, which may be normalized between 0 and 1.

[0055] In some embodiments, the authorized data service 124 may generate a partial trust metric using machine learning techniques. In the machine learning approach, the authorized data service 124 may use a trained partial trust prediction model, which may be a machine learning model corresponding to a model artifact created by a training engine using training data including training inputs and corresponding target outputs (i.e., answers indicating the corresponding training inputs). The training inputs may be based on historical data and include factors associated with various client devices that have previously requested content from the authorized data service 124 and / or the CDN server 132. The target output may include an indication of whether the client device is authorized to access the requested content. In another implementation, a partial trust prediction model may be trained for a specific user based on training data associated with that user and / or that user's media player and / or client device.

[0056] In operation 206, the authorization data service 124 of the content sharing platform 120 can authorize the content request. To authorize the request, the authorization data service 124 can determine that at least one of the client device 110 or the user (or user account) is permitted to access the content. In some embodiments, the authorization data service 124 can determine whether a partial trust metric meets (e.g., is greater than) an authorization threshold. The authorization threshold can be any value used to determine whether the client device 110 should be authorized to receive a content identifier from the content sharing platform 120. In response to the partial trust metric meeting the authorization threshold, the authorization data service 124 can authorize the content request. For example, in response to a partial trust metric greater than 0.2, the client device 110 can be considered authorized.

[0057] In some embodiments, determining whether to authorize a content request can be independent of an authorization threshold. In one example, the content request may identify account information of the user account requesting the content. For example, the account information may be encrypted in a cookie. In another example, the account information may be entered by the user and provided in the request. In some embodiments, the authorization data service 124 may authenticate account information such as a username and password by comparing the account information (e.g., the received username and password) with a stored record of the account information. If the requested account information matches the recorded account information, the authorization data service 124 may determine that the specific user account is authenticated, and the authorization data service 124 may authorize the content request and assign a predefined partial trust metric to the content request.

[0058] In some embodiments, in response to the authorization data service 124 failing to authorize the content request and / or authenticate the client device 110, the authorization data service 124 may refuse the content request. In some embodiments, if the authorization data service 124 does not authorize the request to obtain content, the authorization data service 124 may send a message to the client device 110 indicating that authorization to obtain the requested content is not permitted.

[0059] In some embodiments, in response to a request from the authorization data service 124 to authorize the retrieval of content, the authorization data service 124 generates one or more resource locators (e.g., URLs) to authorize the client device 110 to retrieve the requested content from the CDN 130. In some embodiments, the resource locator may identify the CDN server 130 to which the requested content is to be delivered to the client device 110. For example, the resource locator may include a hostname that identifies a specific server (e.g., server 112A, server 112B, etc.) that can be accessed to retrieve the requested content. In some embodiments, the authorization data service 124 may append a partial trust metric to the resource locator and may digitally sign the resulting response. The digital signature may be based on signature parameters (e.g., expiration parameters, bitrate parameters, playback event identifiers, etc.) that can be used to indicate to the CDN 130 which data will be served and how the data will be served. In some embodiments, the digital signature may be encrypted.

[0060] In operation 208, in response to the user account being authorized, the authorization data service 124 may send a response to the client device 110 for the request for content (e.g., operation 202). In some embodiments, the response may include one or more resource locators identifying the CDN server 132 to which content is to be delivered to the client device 110, and a partial trust metric. In some embodiments, the response may also include a digital signature. In some embodiments, the response may include one or more of a content identifier, a user account identifier, and / or a playback event identifier associated with the content request. In some embodiments, the response may be a Hypertext Transfer Protocol (HTTP) response.

[0061] In operation 210, client device 110 can request content using a resource locator appended with a digital signature and a partial trust metric. In some embodiments, the request can be sent to CDN server 132. In some embodiments, CDN server 132 can decrypt the digital signature using, for example, one or more encryption keys, public keys, private keys, etc.

[0062] In operation 212, CDN server 132 may determine the trust status of a client device based on a partial trust metric. The client device trust status can be any type of indicator that CDN server 132 uses to determine whether to release the requested content to the user. In some embodiments, CDN server 132 may compare the partial trust metric to one or more thresholds to determine the client device trust status. Based on this comparison, server 132 may reduce or limit the resolution of the requested content (e.g., 2160p, 1440p, 1080p, 720p, 480p, 540p, 360p, 240p, etc.), reduce or limit the frame rate (e.g., 24 frames per second (fps), 25 fps, 30 fps, 60 fps, 120 fps, etc.), suppress data transmitted to client device 110, and so on. In one example, in response to server 132 determining that the partial trust metric is greater than a first threshold (e.g., 0.5), server 132 may determine that the client device is trustworthy and serve the content in the requested format (e.g., standard definition, high definition, etc.). In response to server 132 determining that a portion of the trust metric is less than a first threshold (e.g., 0.5) but greater than a second threshold (e.g., 0.2), server 132 may determine that the client device is problematic and release content only in standard definition instead of high definition. In response to server 132 determining that a portion of the trust metric is less than the second threshold (e.g., 0.2), server 132 may determine that the client device is not trusted and reject the content request.

[0063] In some embodiments, based on the determined trust state of the client device, CDN server 132 may request client device 110 to perform one or more additional functions before CDN server 132 releases the requested content. Additional functions may include requesting ReCaptcha verification, requesting user registration by client device 110, etc. For example, in response to CDN server 132 determining that a portion of the trust metric is less than a first threshold (e.g., 0.5) but greater than a second threshold (e.g., 0.2), CDN server 132 may determine that the client device has a problem and request the user to register in their user account.

[0064] In some embodiments, CDN server 132 may combine a portion of the trust metric with one or more additional CDN-related factors to determine the trust status of a client device. These additional factors may be identified by CDN server 132 based on information available to CDN server 132. Specifically, additional factors may include any data related to the client device 110, the user (user account), and / or other information determined by CDN server 132 based on content requests to CDN server 132 or other information locally available to CDN server 132 regarding content requests to CDN server 132 (in operation 210). For example, additional factors (factors determined by CDN) may include the IP address used to request content, one or more cookies provided to CDN 130 along with the content request, client proxies reported by the client device (e.g., browsers, bots, download managers, applications accessing the internet, etc.), the type of content requested (e.g., popular, private, advertising, paid video, etc.), the bitrate of the requested content, the amount of content requested in the request, etc. In some embodiments, CDN server 132 can determine the device trust status by increasing or decreasing a partial trust metric based on one or more factors determined by the CDN, and then comparing the new trust metric with one or more thresholds. In an illustrative example, a suspicious IP address may cause the partial trust metric to decrease by 0.1. Therefore, in response to client device 110 being assigned a partial trust metric of 0.25, and CDN server 132 determining that the content request at operation 210 was received from a suspicious IP address, CDN server 132 may decrease the partial trust metric by 0.1 and compare the new trust metric of 0.15 with one or more thresholds to determine the client device trust status of client device 110. In some embodiments, CDN server 132 may use heuristics to combine the partial trust metric with one or more CDN-determined factors, wherein each CDN-determined factor and / or partial trust metric may be assigned a weight, and the weighted factor is combined with a weighted or unweighted partial trust metric to determine the client device trust status. In other embodiments, CDN server 132 may use machine learning methods to combine the partial trust metric with one or more CDN-determined factors.

[0065] In operation 214, based on the client device's trust state, CDN server 132 may respond to a content request with content associated with the resource locator. For example, when the client device's trust state indicates that the client device is trusted, or when the format of the requested video item is lower than the format requested when the client device has a problem, the response may include the requested video item.

[0066] Figure 3This is a diagram illustrating operations for evaluating client device trust according to embodiments of this disclosure. System 300 may include... Figure 1 The system architecture has 100 similar components. It can be noted that... Figure 1 The components can be used to help describe Figure 3 For illustrative and non-limiting purposes, operations of system 300 are described as being performed via the licensed data service 124 of content sharing platform 120, the server machine 132 of content delivery network 130, or the client device 110, and may be performed by any of its components, unless otherwise described. ... Figure 3 The described operations are shown as being performed in a sequential order. It can be noted that the operations can be performed in any order, and any operation can be performed concurrently with one or more other operations. In some implementations, the same, different, fewer, or more operations can be performed in any order.

[0067] In operation 302, in response to user input regarding content, client device 110 sends a request to the authorized data service 124 of content sharing platform 120 to retrieve the content. For example, a user of client device 110 may request to play a video project hosted by content sharing platform 120. In some embodiments, the user may use an application such as a browser or a native application to request content from content sharing platform 120. The content may be stored on one or more nodes or servers (one or more CDN servers 132) of a content delivery network.

[0068] In some embodiments, a request from client device 110 to authorized data service 124 may include the format of the data to be received. For example, the request may include the format of a video item compatible with media viewer 112 at client device 110. In some embodiments, the request may include additional information (e.g., type, version, etc.) related to media viewer 112, at which content such as the video item will be played back.

[0069] In some embodiments, a content request may include an identifier of a client device or a user account attempting to access the content. For example, a user request may identify the username and password associated with the user account requesting access to the content. In another example, the request may include a cookie identifying an application on client device 110 or the user device, which may be used to identify a specific user account. For example, a user may log in to content sharing platform 120 using user account information, and in response to authorization of the user account by content sharing platform 120, content sharing platform 120 may send a cookie to user device 120. In yet another example, a content request may include other data associated with a user or user account, such as, for example, an Internet Protocol (IP) address associated with a client device.

[0070] In operation 304, the authorization data service 124 of the content sharing platform 120 can generate a trust packet associated with the content request. In some embodiments, the trust packet may include data such as whether the user is logged in, the type of browser the user used to request the content, the user's geographic location, and the user's IP address. In some embodiments, the trust packet may include instructions to the CDN server 132. The instructions may instruct the CDN server 132 to perform one or more functions in response to the fulfillment of a condition (or criterion). These functions may include rejecting the content request, reducing or limiting the resolution of the requested content, requesting ReCaptcha verification, requesting user registration on the client device 110, etc. The condition may be based on (at operation 310 below) one or more of the following: content requests to the CDN server 132 originating from or not originating from a specified region, content requests to the CDN server 132 using or not using an IP address or an IP address of a specified subnet, content requests to the CDN server 132 using or not using a specified browser, etc. For example, if the content request to the CDN server 132 does not originate from a specific type of browser, the instructions may instruct the CDN server 132 to reduce the resolution of the requested content.

[0071] In operation 306, the authorization data service 124 of the content sharing platform 120 can authorize the content request. To authorize the request, the authorization data service 124 can determine that at least one of the client device 110 or the user (or user account) is authorized to access the content. In one example, the content request can identify account information of the user account requesting the content. For example, the account information can be encrypted in a cookie. In another example, the account information can be entered by the user and provided in the request. In some embodiments, the authorization data service 124 can authenticate the account information, such as a username and password, by comparing it (e.g., a received username and password) with a stored record of the account information. If the requested account information matches the recorded account information, the authorization data service 124 can determine that the specific user account is authenticated, and the authorization data service 124 can authorize the content request.

[0072] In some embodiments, in response to the authorization data service 124 failing to authorize the content request and / or authenticate the client device 110, the content request can be rejected by the authorization data service 124. In some embodiments, if the authorization data service 124 does not authorize the request to obtain content, the authorization data service 124 may send a message to the client device 110 indicating that authorization to obtain the requested content is not permitted.

[0073] In some embodiments, in response to a request from the authorization data service 124 to authorize the retrieval of content, the authorization data service generates one or more resource locators (e.g., URLs) to authorize the client device 110 to retrieve the requested content from the CDN network 130. In some embodiments, the resource locator may identify the CDN server to which the requested content is to be delivered to the client device 110. For example, the resource locator may include a hostname that identifies a specific server (e.g., server 112A, server 112B, etc.) that can be accessed to retrieve the requested content. In some embodiments, the authorization data service 124 may append a trust packet to the resource locator and digitally sign the resulting response. The digital signature may be based on signature parameters (e.g., expiration parameters, bitrate parameters, playback event identifier parameters, etc.) that can be used to indicate to the CDN server 132 which data will be served and how the data will be served. In some embodiments, the digital signature may be encrypted.

[0074] In operation 308, in response to the user account being authorized, the authorization data service 124 may send a response to the client device 110 for the request for content (e.g., operation 302). In some embodiments, the response may include one or more resource locators identifying the server 132 of the CDN 130 to deliver content to the client device 110. In some embodiments, the response may also include a trust packet and a digital signature. In some embodiments, the response may include one or more of a content identifier, a user account identifier, and / or a playback event identifier associated with the content request. In some embodiments, the response may be a Hypertext Transfer Protocol (HTTP) response.

[0075] In some embodiments, the authorization data service 124 may send the trust packet to the identified CDN server 132 instead of including the trust packet in the response to the client device 110. In some embodiments, the trust packet is digitally signed using one or more signature parameters that provide, for example, the expiration time of the trust packet and / or a playback event identifier created for the content request.

[0076] In operation 310, client device 110 can request content using a resource locator appended with a digital signature and a trust packet. In some embodiments, the request can be sent to CDN server 132. In some embodiments, CDN server 132 can decrypt the digital signature using, for example, one or more encryption keys, public keys, private keys, etc.

[0077] In operation 312, CDN server 132 may determine the client device trust status based on a trust packet. The client device trust status can be any type of indicator used by CDN server 132 to determine whether to release the requested content to the user. In some embodiments, CDN server 132 may compare data received at operation 310 (and / or directly from authorized data service 124) from the trust packet with data obtained from the content request at operation 310 (e.g., factors determined by the CDN). Based on this comparison (e.g., whether server 132 detects a difference in the comparison), server 132 may determine the client device trust status. In some embodiments, in response to determining that there is no difference between the data obtained from the trust packet and the data obtained from the content request at operation 310, CDN server 132 may assign a trust status to the client device and release the requested content. In some embodiments, in response to determining a difference between the data obtained from the trust packet and the data obtained from the content request at operation 310, CDN server 132 may assign an untrusted status or a problematic status to client device 110 and reject the playback quality of the content request or downgrade the request, respectively. For example, in response to CDN server 132 determining that a client device is requesting content from authorized data service 124 using a first type of browser and requesting content from server 132 using a second type of browser, CDN server 132 can reduce the resolution of the requested content from 1080p to 480p.

[0078] In some embodiments, in response to determining a difference between the data obtained from the trust packet and the data obtained from the content request in operation 310, CDN server 132 may request client device 110 to perform one or more additional functions before server 132 releases the requested content. Additional functions may include requesting ReCaptcha verification, requesting user registration for client device 110, etc. For example, in response to CDN server 132 determining that client device requested content from authorized data service 124 using a first IP address and requested content from CDN server 132 using a different IP address, CDN server 132 may determine that there is a problem with the client device and request user registration to their user account.

[0079] In operation 314, based on the client device's trust state, CDN server 132 may respond to a content request with content associated with the resource locator. For example, when the client device's trust state indicates that the client device is trusted, or when the format of the requested video item is lower than the format requested when the client device has a problem, the response may include the requested video item.

[0080] In some embodiments, CDN server 132 may use any combination of partial trust metrics, trust packets, and / or factors determined by the CDN to determine the trust status of a client device. For example, authorization data service 124 may generate one or more resource locators to authorize client device 110 to obtain the requested content from CDN 130. Authorization data service 124 may further append partial trust metrics and trust packets to the resource locators and send the resulting response to client device 110. Additionally, authorization data service 124 may send a trust packet to CDN server 132. CDN server 132 can then use the partial trust metrics and trust packets to determine the trust status of the client device.

[0081] Figure 4 A flowchart illustrating a method 400 for performing a partial trust metric generation according to embodiments of the present disclosure is depicted. The method is executed by processing logic, which may include hardware (circuit, dedicated logic, etc.), software (e.g., instructions running on a processing device), or a combination thereof. In some embodiments, some or all of the operations of method 400 may be performed by… Figure 1 The operation of method 400 may be performed by one or more components of system 100. In other embodiments, one or more operations of method 400 may be performed by the licensing module of content delivery network 130 or licensing data service 124, as per [reference to...]. Figure 1-2 As described. It can be noted that regarding Figure 1-3 The described components can be used for illustration. Figure 4 All aspects.

[0082] In block 402, the processing logic of method 400 receives a request for content from the client device.

[0083] At block 404, the processing logic generates a partial trust metric associated with the client device based on data available to the content sharing platform. In some embodiments, the partial trust metric is used by the CDN server to make a decision about the client device's access to desired content and may include a score indicating to the CDN server the likelihood that the client device is trustworthy and should be authorized to access the requested content. In some embodiments, the partial trust metric is generated based on one or more characteristics, such as: the user's viewing history associated with the client device, whether the user has previously viewed the requested content, whether the client device has previously successfully decrypted other content, whether the user is logged in, whether the user has participated in or is suspected of participating in unauthorized activities, the client device's Internet Protocol (IP) address, or encrypted logs associated with the user. The characteristics used to generate the partial trust metric may not be available to the CDN server. In some embodiments, the partial trust metric is generated using heuristic rules. In some embodiments, the partial trust metric is generated using a trained machine learning model. In some embodiments, the partial trust metric is encrypted for decryption by the CDN server.

[0084] In block 406, the processing logic generates a response to the content request. This response may include one or more resource locators provided by the content sharing platform to authorize the client device to access the requested content. The response may also include a partial trust metric and may be digitally signed. In some embodiments, the processing logic may reject the content request based on the partial trust metric.

[0085] In block 408, the processing logic sends a response to the client device. A partial trust metric, but not any characteristic used to generate the metric, can be provided by the client device to the CDN server when requesting desired content, and can be used by the CDN server to determine whether to provide the requested content to the client device or degrade the quality of the requested content. In some embodiments, method 400 can be used to generate a trust packet, such as... Figure 3 As discussed in the article.

[0086] Figure 5 A flowchart illustrating a method 500 for determining the trust state of a client device according to embodiments of the present disclosure is provided. The method is executed by processing logic, which may include hardware (circuit, dedicated logic, etc.), software (e.g., instructions running on a processing device), or a combination thereof. In some embodiments, some or all of the operations of method 500 may be performed by… Figure 1 The method 500 is performed by one or more components of system 100. In other embodiments, one or more operations of method 500 may be performed by the authorization module of CDN server 132 and / or authorization data server 124, as per [reference to...]. Figure 1-3 As described. It can be noted that regarding Figure 1-3 The described components can be used for illustration. Figure 5 all aspects

[0087] In block 502, the processing logic implementing method 500 receives a request for content from the client device. This request includes a resource locator provided by an authorized data service to authorize the client device to obtain the requested content. The resource locator may be appended with a partial trust metric.

[0088] In block 504, the processing logic determines the client device's trust status based on a partial trust metric. The client device's trust status can be any type of indicator used by the processing logic to determine whether to release the requested content to the user. In some embodiments, the processing logic may compare the partial trust metric to one or more thresholds to determine the client device's trust status. Based on this comparison, the processing logic may reduce or limit the resolution of the requested content, reduce or limit the frame rate, suppress data transmitted to the client device, and so on.

[0089] In block 506, in response to a client device trust state indicating that the client device is authorized to receive the requested content, the processing logic provides playback of the content to the client device. For example, the processing logic may provide video data associated with a resource locator. In some embodiments, method 500 may be used to determine the client device trust state based on a trust packet, such as... Figure 3 As discussed in the article.

[0090] Figure 6 This is a block diagram illustrating an exemplary computer system 600 according to an embodiment of the present disclosure. The computer system 600 executes one or more sets of instructions that cause the machine to perform any or more of the methodologies discussed herein. Instruction sets, instructions, etc., can refer to instructions that, when executed, cause the computer system 600 to perform one or more operations of an initial playback module 142 (not shown), an authorization module 138, and / or an authorization data service 124 (not shown). The machine can operate as a server or client device in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), tablet computer, set-top box (STB), personal digital assistant (PDA), mobile phone, web device, server, network router, switch, or bridge, or any machine capable of executing a set of instructions specifying the actions to be taken by the machine (in sequence or otherwise). Furthermore, although only a single machine is illustrated, the term "machine" should also be used to include any collection of machines that, individually or jointly, execute a set of instructions to perform any or more of the methodologies discussed herein.

[0091] Computer system 600 includes processing device 602, main memory 604 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), static memory 606 (e.g., flash memory, static random access memory (SRAM), etc.) and data storage device 616, which communicate with each other via bus 608.

[0092] Processing device 602 represents one or more general-purpose processing devices, such as microprocessors, central processing units, etc. More specifically, processing device 602 may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processing device that implements other instruction sets or combinations of instruction sets. Processing device 602 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 602 is configured to execute instructions of system architecture 100 and authorization module 151 for performing the operations discussed herein.

[0093] Computer system 600 may further include a network interface device 622 that provides communication with other machines via a network 618, such as a local area network (LAN), intranet, extranet, or the Internet. Computer system 600 may also include a display device 610 (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)), an alphanumeric input device 612 (e.g., a keyboard), a cursor control device 614 (e.g., a mouse), and a signal generation device 620 (e.g., a speaker).

[0094] Data storage device 616 may include a non-transitory computer-readable storage medium 624 storing an instruction set of system architecture 100, data authorization service 124, or authorization module 138 (not shown) that implements any one or more of the methods or functions described herein. The instruction set of system architecture 100, data authorization service 124, or authorization module 138 may also reside wholly or at least partially in main memory 604 and / or processing device 602 during execution by computer system 600, which also constitute computer-readable storage media. The instruction set may also be transmitted or received on network 618 via network interface device 622.

[0095] While examples of computer-readable storage medium 624 are shown as a single medium, the term "computer-readable storage medium" can include a single medium or multiple media storing a set of instructions (e.g., a centralized or distributed database and / or associated caches and servers). The term "computer-readable storage medium" can include any medium capable of storing, encoding, or carrying a set of instructions for execution by a machine and causing the machine to perform any one or more of the methodologies of this disclosure. The term "computer-readable storage medium" can include, but is not limited to, solid-state memory, optical media, and magnetic media.

[0096] Numerous details have been set forth in the foregoing description. However, it will be apparent to those skilled in the art who benefit from this disclosure that it can be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring the disclosure.

[0097] Some parts of the detailed description are presented based on the algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are the means by which those skilled in the art of data processing most effectively communicate the nature of their work to others skilled in the art. Algorithms here are, and are generally considered, self-consistent sequences of operations that lead to desired results. These operations are those that require physical manipulation of physical quantities. Typically, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and otherwise manipulated. Sometimes, primarily for common reasons, it has proven convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0098] However, it should be remembered that all these and similar terms will be associated with appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise specified, it should be understood that throughout the specification, discussions using terms such as “generate,” “provide,” “adjust,” “receive,” and “cancel” refer to the actions and processes of a computer system or similar electronic computing device that manipulates and converts data represented as physical (e.g., electronic) quantities within the computer system’s memory or registers into other data similarly represented as physical quantities within the computer system’s memory or registers or other such information storage, transmission, or display devices.

[0099] This disclosure also relates to an apparatus for performing the operations described herein. The apparatus may be specifically constructed for the desired purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored therein. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, compact disc read-only memory (CD-ROM), magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, or any type of medium suitable for storing electronic instructions.

[0100] The terms “example” or “exemplary” are used herein to mean used as an example, instance, or illustration. Any aspect or design described herein as an “example” or “exemplary” is not necessarily to be construed as superior to or advantageous to other aspects or designs. Rather, the use of the terms “example” or “exemplary” is intended to present concepts in a specific manner. As used in this application, the term “or” is intended to mean inclusive “or” rather than exclusive “or.” That is, unless otherwise stated or clear from the context, “X comprises A or B” is intended to mean any natural substitution of inclusion. That is, if X comprises A; X comprises B; or X comprises both A and B, then “X comprises A or B” is satisfied in any of the foregoing instances. Furthermore, the articles “a” and “an” used in this application and the appended claims can generally be interpreted as “one or more” unless otherwise specified or clearly pointed to from the context in the singular form. In addition, the use of the terms “embodiment” or “an embodiment” or “implementation” or “one implementation” throughout is not intended to represent the same embodiment or implementation unless so described. Furthermore, the terms “first,” “second,” “third,” “fourth,” etc., as used herein are intended as labels to distinguish different elements and may not necessarily have ordinal meanings based on their numerical designations.

[0101] For the sake of simplicity, the methods herein are depicted and described as a series of actions or operations. However, the actions according to this disclosure can occur in various orders and / or concurrently, and together with other actions not presented and described herein. Furthermore, not all illustrated actions can be required to implement the methods according to the disclosed subject matter. Moreover, those skilled in the art will understand that the methods can alternatively be represented as a series of interrelated states via state diagrams or events. Furthermore, it should be understood that the methods disclosed in this specification can be stored on an article of writing to facilitate the transport and transfer of such methods to a computing device. The term "article of writing" as used herein is intended to encompass any computer program accessible from any computer-readable device or storage medium.

[0102] In additional embodiments, one or more processing devices for performing the operations of the above embodiments are disclosed. Furthermore, in embodiments of this disclosure, a non-transitory computer-readable storage medium stores instructions for performing the operations of the described embodiments. Similarly, in other embodiments, a system for performing the operations of the described embodiments is also disclosed.

[0103] It should be understood that the above description is intended to be illustrative and not limiting. Other embodiments will be apparent to those skilled in the art upon reading and understanding the above description. Therefore, the scope of this disclosure can be determined by referring to the appended claims and the full scope of their equivalents.

Claims

1. A method for assessing trust in a client device, comprising: The processing device of the content sharing platform receives a request for desired content from a client device, the content being stored in a content delivery network (CDN), wherein the content sharing platform supplies the content to the client device and the CDN provides the content to the client device; An authorized device of the content sharing platform or associated with the content sharing platform generates a partial trust metric associated with the client device based on data available to the content sharing platform. This partial trust metric will be used by the CDN server to make a decision regarding access to the desired content by the client device. Generate a response from the content sharing platform to the content request, wherein the response includes one or more resource locators for accessing the desired content in the CDN and the partial trust metric; and The response is sent to the client device to enable the client device to request the desired content from the CDN server using the one or more resource locators and the partial trust metric.

2. The method according to claim 1, wherein, The data available to the content sharing platform includes one or more of a plurality of characteristics, including: the viewing history of a user associated with the client device, whether the user has previously viewed the desired content, whether the client device has previously successfully decrypted other content, whether the user is logged in, whether the user has participated in or is suspected of participating in unauthorized activities, the Internet Protocol IP address of the client device, or encrypted logs associated with the client device.

3. The method according to claim 1, wherein, The trust metric mentioned above is generated using heuristic rules.

4. The method according to claim 1, wherein, The trust metric mentioned above was generated using a machine learning model.

5. The method according to claim 1, wherein, The response, including the one or more resource locators and the partial trust metric, is digitally signed using one or more signature parameters, which provide at least one of the following: the expiration time of the one or more resource locators and / or the partial trust metric, the bit rate for delivering the desired content, or an identifier for a playback event created for the request for the desired content.

6. The method of claim 1, further comprising: The content request is rejected based on the aforementioned partial trust metric.

7. The method according to claim 1, wherein, The trust metric will be used by the CDN server to determine whether to release the desired content to the client device or degrade the quality of the desired content.

8. The method according to claim 2, wherein, The data available to the content sharing platform for generating the partial trust metric is not available to the CDN server, and wherein, when the client device requests the desired content, the partial trust metric is provided to the CDN server instead of any of the plurality of features.

9. The method according to claim 1, wherein, The trust metric will be determined by the CDN server in combination with one or more additional factors to determine the trust status of the client device used by the CDN, in order to determine whether to release the desired content to the client device or degrade the quality of the desired content, wherein the one or more additional factors are identified by the CDN server based on data available to the CDN server.

10. The method according to claim 9, wherein, The additional factors include at least one of the following: the IP address used by the client device to request the content from the CDN server, one or more cookies provided to the CDN server along with the content request, the client proxy reported by the client device to the CDN server, the type of the requested content, the bitrate of the requested content, or the amount of content requested in the content request.

11. A system for assessing the trust of a client device, comprising: Memory; as well as A processing device, coupled to the memory, for: The processing device of the content sharing platform receives a request for desired content from a client device, the content being stored in a content delivery network (CDN), wherein the content sharing platform supplies the content to the client device and the CDN provides the content to the client device; Based on the data available to the content sharing platform, a trust packet is generated and associated with the client device, wherein the trust packet will be used by the CDN server to make a decision regarding access to the desired content by the client device; Generate a response from the content sharing platform to the content request, wherein the response includes one or more resource locators for accessing the desired content in the CDN and the trust packet; and The response is sent to the client device to enable the client device to request the desired content from the CDN server using the one or more resource locators and the trust packet.

12. The system according to claim 11, wherein, The data available to the content sharing platform includes one or more of a plurality of characteristics, including: the viewing history of a user associated with the client device, whether the user has previously viewed the desired content, whether the client device has previously successfully decrypted other content, whether the user is logged in, whether the user has participated in or is suspected of participating in unauthorized activities, the Internet Protocol IP address of the client device, or encrypted logs associated with the client device.

13. The system according to claim 11, wherein, The trust packet includes multiple characteristics that indicate whether the user of the client device is logged in, the type of browser used by the user to request the content, the geographical location of the client device, or the IP address of the client device.

14. The system according to claim 11, wherein, The trust packet includes instructions that instruct the CDN server to perform one or more functions in response to a condition being met.

15. The system according to claim 11, wherein, The response, including the one or more resource locators and the trust packet, is digitally signed using one or more signature parameters, which provide at least one of the following: the expiration time of the one or more resource locators and / or the trust packet, the bit rate for delivering the desired content, or an identifier for a playback event created for the request for the desired content.

16. The system according to claim 11, wherein, The processing device is further operable to: The content request is rejected based on the trust packet.

17. The system according to claim 11, wherein, The trust packet will be used by the CDN server to determine whether to release the desired content to the client device or degrade the quality of the desired content.

18. The system according to claim 11, wherein, The CDN server compares multiple characteristics of the trust packet with data obtained from the client device's content request to the CDN.

19. The system according to claim 11, wherein, The processing equipment is further used for: Based on the data available to the content sharing platform, a partial trust metric is generated associated with the client device, wherein the partial trust metric will be used by the CDN server in conjunction with the trust package to make a decision regarding access to the desired content by the client device.

20. A non-transitory computer-readable medium including instructions that, in response to execution by a processing device of a content-sharing platform, cause the processing device to perform operations, the operations including: A request for desired content is received from a client device, the content being stored in a content delivery network (CDN), wherein the content sharing platform supplies the content to the client device and the CDN provides the content to the client device; Based on data available to the content sharing platform, a partial trust metric is generated associated with the client device, wherein the partial trust metric will be used by the CDN server to make a decision regarding access to the desired content by the client device; Generate a response from the content sharing platform to the content request, wherein the response includes one or more resource locators for accessing the desired content in the CDN and the partial trust metric; and The response is sent to the client device to enable the client device to request the desired content from the CDN server using the one or more resource locators and the partial trust metric.

Images