Real-time geo-locked content delivery network token

Abstract

To solve the problem that when a link to a content distribution network (CDN) is shared, there is a possibility that unauthorized access to content may occur.SOLUTION: A method of providing a streaming content includes steps of: receiving a first request for a link to a streaming content from a first user; determining a geographic location of the first user based on the first request; generating a geographic-specific token describing the geographic location of the first user; transmitting the link including the geographic-specific token to the streaming content to the first user; receiving a second request for streaming content based on a link, a second request including the geographic-specific token; and rejecting the second request for streaming content based on comparing the geographic-specific token to additional geographic information determined based on the second request.SELECTED DRAWING: Figure 5

Description

Background

[0001] Streaming content is typically provided by content providers to authorized users via links to a content delivery network (CDN). However, if these links are shared from authorized users to unauthorized users, unauthorized access to the content may occur. For example, an authorized subscriber of a streaming platform may share a CDN playback uniform resource identifier (e.g., a uniform resource locator (URL)) with a non-subscriber. The non-subscriber may be able to access that playback URL outside the content provider's platform and play the content from the CDN. This has significant drawbacks such as overloading of the CDN and content provider networks, and degradation of the playback experience for authorized users. [Brief Description of the Drawings]

[0002] To achieve and clearly understand the above aspects, a more specific description of the embodiments described in the present specification, which is briefly summarized above, can be obtained by referring to the accompanying drawings.

[0003] However, it should be understood that the accompanying drawings illustrate typical embodiments and are not intended to be limiting, and other equally effective embodiments are also conceivable. [Figure 1] 1 is a block diagram illustrating a computing environment for geolocked (geographically locked) content delivery tokens, in accordance with at least one embodiment. [Figure 2] 1 is a block diagram illustrating a controller for geolocked content delivery tokens, in accordance with at least one embodiment. [Figure 3] Illustrates geolocked content delivery to authorized users, in accordance with at least one embodiment. [Figure 4]This flowchart shows the delivery of geo-locked content to an authorized user by at least one embodiment. [Figure 5] This flowchart shows how to generate geographically specific links for geo-locked content delivery to authorized users, according to at least one embodiment. [Figure 6] This flowchart shows an attempt to deliver geo-locked content to an unauthorized user in at least one embodiment. Detailed explanation

[0004] As mentioned above, sharing CDN links from authorized users to unauthorized users can cause significant problems for content providers (e.g., streaming platforms). One solution is to control access to content using Digital Rights Management (DRM) technology. DRM typically requires a DRM client on the subscriber's player to enforce rights to the content. While DRM allows sharing of playback URLs with non-subscribers, the content is encrypted using DRM, so non-subscribers typically do not have access to the DRM license needed to decrypt the content.

[0005] While DRM makes content link sharing difficult, it also has drawbacks. For example, DRM can be bypassed in some situations, especially on some less secure display devices. Furthermore, implementing DRM can require significant changes across the content provider's entire media platform and considerable computer overhead. DRM requires additional work for encryption, key management, license servers, and DRM clients, which increases both development and computational costs.

[0006] Another solution is token revocation. Token revocation depends on the tokenized URL. The token includes a subscriber identifier (e.g., direct or indirect identification), an expiration date, and other appropriate information. Such tokens are called individual tokens. When a subscriber shares a tokenized URL with a non-subscriber, the CDN cannot detect the link sharing because the token is likely still valid at that time (based on its expiration date, URL path, etc.).

[0007] However, content providers can analyze the use of individual tokens (e.g., using information provided by their backend systems and CDN) to identify suspicious access patterns. The content provider can then work with the CDN to revoke access for that token. However, one drawback of token revocation is that it takes a reactive approach to detection and prevention. Furthermore, it relies on logging activity on the CDN (e.g., potentially generating large amounts of logs and requiring significant computing bandwidth) and the ingestion of signals from the CDN to identify suspicious usage (e.g., based on heuristics or rules). This can be inaccurate, leading to false positive and false negative detections and placing a heavy computing load on the system (e.g., signaling is required between the CDN and the content provider, requiring analysis on one or both systems).

[0008] One or more embodiments described herein are based on the use of CDN access tokens by including a geographical aspect within the token. In one embodiment, a content provider generates a geolock token based on the requester's geographical location, which is provided to the requester as part of a content link (e.g., as part of a URL) so that the geolock token is used when requesting content from a CDN. For the content to play, the geographical location of the user accessing the link to request content from the CDN must match the geographical location of the user who requested the content from the content provider, as recorded in the geolock token.

[0009] In one embodiment, the geolock token provides an active security approach based on the assumption that a subscriber's geographical location typically does not change significantly in the very short timeframe between accessing a content provider and requesting content from the CDN. This enables a real-time approach to prevent unauthorized users from accessing content. Furthermore, since the requesting user's geographical location can be easily accessed using the user's Internet Protocol (IP) address or other geographic information, it is relatively low-cost in terms of computing and implementation, and does not require building new workflows across CDNs and content providers. In one embodiment, the use of the geolock token can provide active security without the need for DRM (as opposed to reactive security provided, for example, by token revocation).

[0010] Furthermore, using geolock tokens offers numerous technical advantages over traditional solutions. For example, as mentioned above, it requires minimal development changes across the entire computing environment (in contrast to DRM solutions) and avoids the significant computer overhead associated with DRM. Another example is that using geolock tokens is stateless and asynchronous, eliminating the need to capture and maintain logs on a CDN (in contrast to, for example, token revocation solutions). This significantly reduces the computing and storage load on the system, and also reduces development time and resources.

[0011] Figure 1 is a block diagram showing a computing environment 100 for a geolocked content delivery token according to at least one embodiment. In one embodiment, the computing environment 100 includes a subscriber 102 of a content service (e.g., a streaming service). The subscriber 102 accesses the content through a content provider, which operates a content provider service stack 120 as part of the content provider computing environment. The content provider service stack 120 controls access to the content and, if the subscriber is authorized to access the content, provides a link to a CDN 130 that hosts the content and delivers it to the subscriber 102.

[0012] For example, subscriber 102 sends a content request 122 to content provider service stack 120. In one embodiment, subscriber 102 uses a suitable computing device (e.g., laptop computer, desktop computer, smartphone, tablet, Internet of Things (IoT) device, smart TV device, wearable device, digital media player device, game device, or other suitable computing device) and accesses content provider service stack 120 using a suitable communication network. This will be further explained below.

[0013] In one embodiment, the content provider service stack 120 validates the request (for example, by checking whether the subscriber has permission to access the requested content) and responds with a playback link 124. In one embodiment, the playback link 124 includes a link to an appropriate CDN (e.g., CDN 130) that hosts the content. For example, the playback link 124 may include a URL that identifies the location of the content on CDN 130.

[0014] As shown in the diagram, subscriber 102 uses playback link 124 to access content from CDN 130. For example, subscriber 102 can use the URL contained in playback link 124 to send a content request 132A to CDN 130. CDN 130 can then respond with one or more content items 134A (e.g., a streaming video content item, a streaming audio content item, a streaming video game content item, or other appropriate content item).

[0015] In one embodiment, subscriber 102 has the authority to access the requested content from the content provider service stack 120, but non-subscriber 104 does not have the authority to access this content (for example, non-subscriber 104 does not maintain a proper subscription to access the content). Subscriber 102 may be able to provide non-subscriber 104 with unauthorized access to the content by sharing the playback link 124.

[0016] For example, subscriber 102 can share a playback link 124 with non-subscriber 104. Non-subscriber 104 can use the playback link 124 (for example, the URL contained in the playback link 124) to send a content request 132B to CDN 130. CDN 130 may respond to the content request 132B with one or more content items 134B and provide the content to non-subscriber 104 even though non-subscriber 104 does not have permission to access the content.

[0017] As will be further explained below in relation to Figure 3-6, in one embodiment, the content provider service stack mitigates this problem by providing a geolock token to the playback link 124. In one embodiment, the content provider service stack 120 uses the geographical location of subscriber 102 to generate a token that restricts access to the content to the required geographical location. Subscriber 102 includes the token received from the content provider service stack 120 in a content request 132A to the CDN 130 (for example, as part of the URL provided by the playback link 124). The CDN 130 compares the geographical location of the requesting subscriber 102 with the geographical location recorded in the content request 132A and provides access to the content. In contrast, if subscriber 102 attempts to share the playback link 124 with a non-subscriber 104 located in a different geographical location, the CDN 130 may refuse to provide access to the content based on the difference between the expected geographical location in the content request 132B and the actual geographical location of the non-subscriber 104. As mentioned above, this will be explained further below in relation to Figure 3-6.

[0018] In one embodiment, various components of the computing environment 100 communicate using one or more suitable communication networks, including the Internet, a wide area network, a local area network, or a cellular network, and using any suitable wired or wireless communication technology (e.g., Wi-Fi or cellular communication). Furthermore, in one embodiment, the content provider service stack 120 and CDN 130 can be implemented using any suitable combination of physical computing systems, cloud computing nodes, and storage locations, or other suitable implementations.

[0019] For example, the Content Provider Service Stack 120 and CDN 130 can each be implemented using their respective servers or server clusters. Alternatively, the Content Provider Service Stack 120 and CDN 130 can be implemented using a combination of compute nodes and storage locations within a suitable cloud environment. For example, one or more components of the Content Provider Service Stack 120 and CDN 130 can be implemented using a public cloud, private cloud, hybrid cloud, or other appropriate implementation. Furthermore, subscribers 102, non-subscribers 104, or both can be implemented using any number or combination of compute devices.

[0020] Figure 2 is a block diagram showing a controller for a geo-locked content delivery token according to at least one embodiment. In one embodiment, the content provider controller 200 corresponds to one aspect of the content provider service stack 120 shown in Figure 1. The content provider controller 200 includes a processor 202, memory 210, and network components 220. The processor 202 typically retrieves and executes programming instructions stored in memory 210. The processor 202 includes a single central processing unit (CPU), multiple CPUs, a single CPU with multiple processing cores, a graphics processing unit (GPU) with multiple execution paths, and the like.

[0021] The network component 220 includes the components necessary for the content provider controller 200 to interface with components on the network (see, for example, Figure 1). For example, the content provider controller 200 is part of a content provider service stack, and it can use the network component 220 to interface with remote storage and computing nodes that use network components (e.g., subscriber 102, non-subscriber 104, CDN 130, or other appropriate components). Alternatively or additionally, the content provider controller 200 may support another part of the computing environment 100 (e.g., CDN 130 or another appropriate location).

[0022] The content provider controller 200 can interface with other elements in the system via a local area network (LAN), such as an enterprise network, a wide area network (WAN), the Internet, or other suitable networks. The network component 220 includes wired, WiFi, or cellular network interface components and associated software, and can facilitate communication between the content provider controller 200 and the communication network.

[0023] Although the memory 210 is shown as a single entity, the memory 210 may include one or more memory devices having memory blocks associated with physical addresses, such as random access memory (RAM), read-only memory (ROM), flash memory, or other types of volatile and / or non-volatile memory. The memory 210 typically contains program code for performing various functions related to the use of the content provider controller 200. The program code is generally described as various functional "applications" or "services" within the memory 210, but alternative implementations may have different functions and / or combinations of functions. Within the memory 210, the content link service 212 facilitates the generation of geolocked content distribution tokens. This will be described in further detail in the following figures.

[0024] In one embodiment, the CDN controller 250 corresponds to one aspect of the CDN 130 shown in FIG. 1. The CDN controller 250 includes a processor 252, a memory 260, and a network component 270. The processor 252 typically retrieves and executes programming instructions stored in the memory 260. The processor 252 includes a single central processing unit (CPU), multiple CPUs, a single CPU having multiple processing cores, a graphics processing unit (GPU) having multiple execution paths, and the like.

[0025] The network component 270 includes the components necessary for the CDN controller 250 to interface with components on the network (for example, shown in Figure 1). For example, the CDN controller 250 is part of the CDN 130, and the CDN controller 250 can use the network component 270 to interface with remote storage nodes and compute nodes that use network components (e.g., subscriber 102, non-subscriber 104, content provider service stack 120, or other appropriate components). Alternatively or additionally, the CDN controller 250 may support other parts of the compute environment 100 (e.g., content provider service stack 120 or another appropriate location).

[0026] The CDN controller 250 can interface with other elements in the system via a local area network (LAN), such as an enterprise network, a wide area network (WAN), the internet, or other suitable network. The network component 270 includes wired, WiFi, or cellular network interface components and associated software, which can facilitate communication between the CDN controller 250 and the communication network.

[0027] Although the memory 260 is shown as a single entity, the memory 260 may include one or more memory devices having memory blocks associated with physical addresses, such as random access memory (RAM), read-only memory (ROM), flash memory, or other types of volatile and / or non-volatile memory. The memory 260 typically contains program code for performing various functions related to the use of the CDN controller 250. The program code is typically described as various functional "applications" or "services" within the memory 260, although alternative implementations may have different functions and / or combinations of functions. Within the memory 260, the CDN validation service 262 facilitates validation of geolocked content delivery tokens, which is explained in further detail in the following figures.

[0028] In Figure 2, the content link service 212 is disposed in the memory 210 and the CDN validation service 262 is disposed in the memory 260, but this representation is provided merely for clarity of explanation. More generally, the content provider controller 200 and the CDN controller 250 may each include one or more computing platforms such as computer servers, which may be co-located, or may form an interactively linked but distributed system, such as a cloud-based system (e.g., a public cloud, a private cloud, a hybrid cloud, or other suitable cloud-based system). As a result, the processors 202, 252 and the memories 210, 260 may correspond to distributed processor and memory resources within a computing environment.

[0029] Figure 3 illustrates geo-locked content delivery to authorized users according to at least one embodiment. In one embodiment, the computing environment 300 includes a subscriber 302 to a content service (such as a streaming service). As described in Figure 1, the subscriber 302 can access content from a CDN 330 through requests to a content provider service stack 320, which is part of the content provider computing environment (similar to how the subscriber 102 shown in Figure 1 can access content from a CDN 130). However, in one embodiment, in the computing environment 300 shown in Figure 3, the content provider service stack 320 provides a geo-specific playback link 324 that can be used to protect against unauthorized access by a non-subscriber 304 located in a different geographical location from the subscriber 302.

[0030] For example, subscriber 302 can send a content request 322 to content provider service stack 320 (using appropriate computing devices and communication networks, for example, as described in relation to Figure 1). In one embodiment, content provider service stack 320 verifies the request (for example, verifies that the subscriber has permission to access the requested content) and generates a geo-specific playback link.

[0031] For example, the content provider service stack 320 can use the information contained in the content request 322 to determine the geographical location of the subscriber 302 (e.g., the subscriber's IP address, or other appropriate information). The content provider service stack can use the geographical location to generate a geo-specific playback link 324. For example, the content provider can generate a URL (e.g., a URL that identifies the location where the content is stored on the CDN 330) that includes a geo-specific token (e.g., a token that identifies the geographical location of the subscriber 302). This will be further explained below with reference to Figure 4-6.

[0032] As illustrated, subscriber 302 accesses content from CDN 330 using geo-specific playback link 324. For example, subscriber 302 can send a content request 332A to CDN 330 using the URL contained in geo-specific playback link 324. CDN 330 can validate the request. For example, CDN 330 can use the geo-specific token contained in content request 332A and information indicating subscriber 302's current geographical location (e.g., subscriber 302's IP address) to determine whether the content request 332A to the CDN originated from the same geographical location as the content request 322 to the content provider service stack. After validating the content request 332A, CDN 330 can respond with one or more content items 334A (e.g., streaming video content items, streaming audio content items, streaming video game content items, or other appropriate content items).

[0033] As shown in Figure 1, in one embodiment, subscriber 302 has the authority to access the requested content from the content provider service stack 320, but non-subscriber 304 does not have the authority to access this content (for example, non-subscriber 304 does not have the appropriate subscription to access the content). Subscriber 302 may share a geo-specific playback link 324 with non-subscriber 304 who is in a different geographical location from subscriber 302 (for example, intentionally or unintentionally). However, unlike in Figure 1, non-subscriber 304 cannot access the requested content because of the geo-specific playback link 324.

[0034] For example, a non-subscriber 304 can send a content request 332B to a CDN 330 using a geo-specific replay link 324 (e.g., a URL contained in the geo-specific replay link 324 that includes a geo-specific token). The CDN 330 can validate the request. For example, the CDN 330 can compare the geographic information contained in the geo-specific replay link 324 (e.g., a geo-specific token) with the geographic information contained in the content request 332B that identifies the geographic location of the non-subscriber 304 (e.g., the IP address of the non-subscriber 304). Since the non-subscriber 304 is in a different geographic location than subscriber 302, the geographic information contained in the geo-specific replay link 324 will not match the geographic information contained in the content request 332B that identifies the geographic location of the non-subscriber 304 (e.g., the geo-specific token contained in the geo-specific replay link 324 will not match the geographic location indicated by the IP address of the non-subscriber 304). Therefore, CDN330 returns a rejection 336 (for example, instead of a content item). As will be further explained below with respect to Figure 6, this rejection may include an error, a re-request initiated by subscriber 302, or other appropriate rejection action.

[0035] Similar to Figure 1, in one embodiment, various components of the computing environment 300 communicate using one or more suitable communication networks, including the Internet, a wide area network, a local area network, or a cellular network, and using any suitable wired or wireless communication technology (e.g., WiFi or cellular communication). Furthermore, in one embodiment, the content provider service stack 320 and CDN 330 can be implemented using any suitable combination of physical computing systems, cloud computing nodes, and storage locations, or other suitable implementations.

[0036] For example, each of the Content Provider Service Stack 320 and CDN 330 can be implemented using its own server or server cluster. Alternatively, the Content Provider Service Stack 320 and CDN 330 can be implemented using a combination of compute nodes and storage locations within a suitable cloud environment. For example, one or more components of the Content Provider Service Stack 320 and CDN 330 can be implemented using a public cloud, private cloud, hybrid cloud, or other appropriate implementation. Furthermore, subscribers 302, non-subscribers 304, or both can be implemented using any number or combination of compute devices.

[0037] Figure 4 is a flowchart 400 illustrating the delivery of geo-locked content to an authorized user according to at least one embodiment. In block 402, a subscriber (e.g., subscriber 302 shown in Figure 3) requests a playback link. For example, the subscriber may send a network message to a content provider controller (e.g., content provider controller 200 shown in Figure 2) using an appropriate communication network (e.g., the Internet, LAN, WAN, cellular communication network, or other appropriate communication network).

[0038] In block 404, the content provider generates a geo-specific link. In one embodiment, a content link service (e.g., content link service 212 shown in Figure 2) can use information from the replay link request to determine the subscriber's geographic location. This will be described in detail below with reference to Figure 5. For example, the content link service can use the subscriber's IP address or other appropriate information to determine the subscriber's geographic location. Furthermore, as described below with reference to Figure 5, the content link service can determine the geographic location at an appropriate level of granularity (e.g., city, county, state, residential area, or other appropriate level of granularity). The content link service can generate a token that identifies this geographic location and include this token in the link (e.g., URL) provided to the subscriber.

[0039] In block 406, the subscriber requests content using a geo-specific link. In one embodiment, the link identifies a content item on the appropriate CDN, and the subscriber follows the link to retrieve the content. For example, the geo-specific link may be a URL containing a geo-specific token. The subscriber can access the URL to retrieve the content from the CDN.

[0040] In block 408, the CDN evaluates geo-specific links. In one embodiment, a content request from a subscriber includes both the subscriber's current geographic location (e.g., an IP address or other geographic identifier) ​​and a geo-specific link generated by the content provider's content linking service (e.g., a URL containing a geo-specific token). A CDN validation service (e.g., CDN validation service 262 shown in Figure 2) compares the subscriber's current geographic location with the expected geographic location recorded in the geo-specific link. If the geographic locations match, the CDN validation service satisfies the request. If they do not match, the CDN validation service does not satisfy the request.

[0041] In one embodiment, the CDN can evaluate geo-specific links for every content request it receives. Alternatively or additionally, the CDN can evaluate geo-specific links at defined times. For example, the CDN can evaluate geo-specific links only at the start of content playback (e.g., for mobile devices that may move during playback) or at regular intervals. In one embodiment, limiting the number of evaluations can avoid errors when a valid subscriber is moving geographically (e.g., viewing content as a passenger in a moving vehicle). Furthermore, in one embodiment, the CDN validation service can use a radius around a geographical location (e.g., current geographical location, expected geographical location, or both) to account for the subscriber's physical movement. For example, the CDN validation service can define a required radius (e.g., the distance around a specific point expressed in latitude and longitude) as a buffer around the geographical location. This required radius can be hardcoded or configured (e.g., pre-operation or at runtime). If the current and expected geographical locations coincide within this radius, the request can be evaluated as valid.

[0042] In block 410, the CDN provides content to the subscriber. In one embodiment, the CDN verification service determines that the geographic location of the requesting subscriber matches the geographic location described in the geo-specific link (e.g., URL token). The CDN then provides content to the subscriber.

[0043] Figure 5 is a flowchart illustrating the generation of geo-specific links for geo-locked content delivery to authorized users, according to at least one embodiment. In one embodiment, Figure 5 corresponds to block 404 shown in Figure 4. In block 502, a content link service (e.g., content link service 212 shown in Figure 5) identifies the subscriber's geography. For example, a request to the content link service (e.g., a request from a subscriber) may include the IP address of the requester (e.g., the subscriber). The content link service can use the IP address to identify the requester's geographical location (e.g., using a lookup table or another suitable technique).

[0044] The use of IP addresses is merely an example; Content Link services can use any appropriate technology (e.g., cellular network identifiers, application-specific identifiers, or other appropriate technologies) to identify the requester's geographical location. For example, a request to a Content Link service may include latitude and longitude information, cellular network geographic identification (e.g., base station or subscriber identification information), network service provider headers, or other appropriate information. Content Link services can resolve this information to identify the requester's geographical location.

[0045] In one embodiment, a requester may attempt to mask their actual geographical location by using a virtual private network (VPN) or other technology. For example, a requester may use a VPN to provide the Content Link service with an IP address that matches a desired geographical location (e.g., to enable unauthorized content sharing) rather than their actual geographical location. In one embodiment, the Content Link service (or other appropriate software service) can take appropriate measures against this scenario. For example, the Content Link service may use VPN detection to prevent requesters using a VPN from obtaining content. This is just an example, and the Content Link service may take any appropriate measures (e.g., relying on geographical identification information separately from or in addition to IP addresses).

[0046] In one embodiment, the ContentLink service can identify the requester's geographical location at a desired level of granularity. For example, the ContentLink service can identify the geographical location at the national, state, county, city, intracity (neighborhood or other area, etc.) level, or other appropriate level of granularity. The level of granularity can be set by the content provider, determined before operation, or determined using other appropriate techniques. In one embodiment, ISO 3166-2 coding can be used. In this coding, each country is divided into subdivisions with assigned codes. For example, in ISO 3166-2, the United States is designated with the code US and is subdivided into 50 states, one district, and six surrounding regions.

[0047] In one embodiment, a content link service can use geohash technology to pinpoint a geographic location at a preferred level of granularity (e.g., in addition to or as an alternative to ISO 3166-2 coding). In one embodiment, geohash encodes the geographic location into a hierarchical code value (e.g., a combination of numbers and letters) that indicates the location. For example, geohash involves dividing the geographic space into a grid-shaped bucket (e.g., using a space-filling curve). Generally, the longer the code, the more precise the geographic specification (e.g., adding symbols to the code increases granularity, and removing symbols from the code decreases granularity). In one embodiment, geohash can be implemented to cover a wide range of granularities, from tens of kilometers to hundreds of kilometers, and even thousands of kilometers.

[0048] In one embodiment, the granularity of geographic location can be determined based on several factors. For example, the geographic location of a requester (e.g., a subscriber) can be determined based on a lookup of the requester's IP address. However, these lookups can vary greatly in accuracy, potentially leading to inconsistent results or false positives. Furthermore, a mix of IPv4 and IPv6 addresses (e.g., for a particular requester) can lead to different geographic lookups (e.g., an IPv4 address might return one location, while the same user's IPv6 address might return a different location). This, too, can lead to errors. In one embodiment, a level of granularity can be selected so that the requester's geographic location is specific enough to protect against unauthorized access by others, while being general enough to avoid a negative user experience due to inaccurate or inconsistent IP lookups.

[0049] Another potential consideration is the requester's movement. In one embodiment, the requester may be on the move (e.g., in a car, train, airplane, or other vehicle). Fragmented geographic location can be a source of errors because the user may move geographically between the request to the content provider service stack and the request to the CDN. For example, a viewer in a car may be in one location when requesting content from the content provider service stack, receiving a geo-specific playback link tied to that first location, and then be in a second location when requesting content from the CDN. If geographic location is too fragmented, the user may be incorrectly denied access based on this movement. In one embodiment, the user's geographic location is defined broadly enough to avoid or reduce these errors.

[0050] Alternatively or additionally, as described above in relation to block 408 in Figure 4, the potential movement of the requester can be addressed by evaluating geo-specific links only at defined times (e.g., only at the start of content playback, or at regular intervals), defining a desirable radius around the geographic location for evaluation, or by a combination of appropriate technologies. As an example, a CDN validation service (or other appropriate software service) can evaluate geo-specific links only at the start of playback. This limits the time between the generation of the geo-specific token and the evaluation of the geo-specific link to a very short period (e.g., less than one minute), reducing the likelihood of errors occurring even if the requester has moved geographically sufficiently.

[0051] Furthermore, the CDN validation service can modify the evaluation frequency, geographical radius or granularity, or other appropriate characteristics based on whether the requester is using a mobile device. For example, the requester's movement may only be an issue for mobile devices. The CDN validation service can use information within the request or other appropriate information to identify that the requester is using a mobile device and modify the evaluation flow (frequency or timing, radius, granularity, etc.) based on this identification. This allows for the application of different evaluation methods for mobile devices (reducing evaluation frequency, decreasing geographical identification granularity, increasing the radius around geographical location, or other appropriate differences) to avoid mistakenly denying access to authorized users while performing evaluations more frequently for other devices.

[0052] In block 504, the ContentLink service generates a geo-specific token. In one embodiment, the token includes the requested user's detected geographic location at the required level of granularity. For example, the token may correspond to an ISO 3166-2 code, a geohash, a combination of the two, or other appropriate values.

[0053] In block 506, the content link service provides subscribers with links that include geo-specific tokens. For example, the content link service may provide subscribers with URLs that include geo-specific tokens as properties of the URL. The token is, for example, a field or property embedded in the URL (e.g., a key-value pair in the URL) that reflects the requester's geographic location (e.g., a string in the URL that reflects the geographic location). This is just an example, and the geo-specific token can be any appropriate value using any appropriate technique. In one embodiment, the token may be obfuscated for security purposes so that the requester cannot identify or modify its value. For example, the token may be modified using encryption (e.g., using public-key cryptography), encoding, hashing, or other appropriate obfuscation.

[0054] Figure 6 is a flowchart 600 illustrating an attempt at geo-locked content delivery to an unauthorized user in at least one embodiment. In one embodiment, flowchart 600 is similar to flowchart 400 shown in Figure 4, except that the content is not delivered to the user because the user requesting content from the CDN is not in the same geographical location as the user accessing the content provider service stack (for example, the user is assumed not to be a valid subscriber).

[0055] In block 602, a subscriber (for example, subscriber 302 shown in Figure 3) requests a playback link. For example, the subscriber can send a network message to a content provider controller (for example, content provider controller 200 shown in Figure 2) using an appropriate communication network (for example, the Internet, LAN, WAN, cellular communication network, or other appropriate communication network).

[0056] In block 604, the content provider generates a geo-specific link. In one embodiment, a content link service (e.g., content link service 212 shown in Figure 2) can use information from the replay link request to determine the subscriber's geographic location. This is illustrated in detail in Figure 5. For example, the content link service can use the subscriber's IP address or other appropriate information to determine the subscriber's geographic location. Furthermore, as illustrated in Figure 5, the content link service can determine the geographic location at an appropriate level of granularity (e.g., city, county, state, residential area, or other appropriate level of granularity). The content link service can generate a token that identifies this geographic location and include this token in the link (e.g., URL) provided to the subscriber.

[0057] In block 606, subscribers provide geo-specific links to non-subscribers. For example, a subscriber can share a link received in block 604 with another entity that is not a subscriber. This may be done intentionally or unintentionally (for example, a malicious third party may intercept or eavesdrop on the transmission of the link).

[0058] In block 608, a non-subscriber requests content using a geo-specific link. In one embodiment, the link identifies a content item on the appropriate CDN, and the non-subscriber attempts to retrieve the content by following the link. For example, a geo-specific link is a URL containing a geo-specific token. The non-subscriber attempts to retrieve the content from the CDN by accessing the URL.

[0059] In block 610, the CDN rejects the request. In one embodiment, the CDN evaluates the request and determines that the request should not be fulfilled because the requester to the CDN is in a different geographical location than the requester to the content provider service stack. In one embodiment, the content request from a non-subscriber includes both the non-subscriber's current geographical location (e.g., an IP address or other geographic identifier) ​​and a geographically unique link (e.g., a URL containing a geographically unique token) generated by the content provider's content linking service. The CDN validation service (e.g., CDN validation service 262 shown in Figure 2) compares the non-subscriber's current geographical location with the expected geographical location recorded in the geographically unique link. Since the geographical locations do not match, the CDN rejects the request.

[0060] In one embodiment, the CDN may take any appropriate action as part of rejecting a request. For example, the CDN may refuse to provide content and provide an appropriate error message. Alternatively or additionally, the CDN may request additional information from the requester, ask the requester to re-request a playback link from the content provider service stack, interface with the content provider service stack to verify the requester (e.g., exchange one or more messages between the CDN and the content provider service stack), or take other appropriate actions. Furthermore, the CDN (or other aspects of the system) may require the user to re-verify access to the content (e.g., log in again using a username, password, or other identifying information).

[0061] For example, as part of rejecting a request, the CDN can contact the content provider service stack, the requester, both, or other appropriate network components to initiate subscriber re-validation. The subscriber can then initiate another content request (e.g., automatically or based on user input), and the content provider service stack and the CDN can validate the geographical match of this request. This can be used to prevent valid subscribers from being inadvertently blocked from content (e.g., if geographical validation fails).

[0062] This disclosure refers to various embodiments. However, it should be understood that this disclosure is not limited to any particular embodiment described. Instead, any combination of the following features and elements, whether related to a different embodiment or not, should be considered for carrying out and practicing the teachings provided herein. Furthermore, where an element of an embodiment is described in the form of “at least one of A and B,” it should be understood that embodiments comprising only element A, embodiments comprising only element B, and embodiments comprising elements A and B should be considered, respectively. Furthermore, while some embodiments may achieve other possible solutions or advantages over the prior art, whether a particular advantage is achieved by a particular embodiment does not limit this disclosure. Accordingly, the aspects, features, embodiments, and advantages disclosed herein are merely illustrative and should not be considered elements or limitations of any appended claims unless expressly stated in the claims. Similarly, references to “the present invention” should not be interpreted as a generalization of the subject matter of the invention disclosed herein and should not be considered elements or limitations of any appended claims unless expressly stated in the claims.

[0063] As those skilled in the art will understand, the embodiments described herein can be embodied as systems, methods, or computer program products. Accordingly, embodiments can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects (collectively referred to herein as “circuits,” “modules,” or “systems”). Furthermore, embodiments described herein can take the form of computer program products embodied in one or more computer-readable media in which computer-readable program code is embodied.

[0064] Program code embodied in a computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, or a suitable combination thereof.

[0065] Computer program code for performing operations of embodiments of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the C programming language or similar languages. The program code can run entirely on the user's computer, partially on the user's computer, run as a standalone software package, run partially on the user's computer and partially on a remote computer, or run entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or to an external computer (for example, via the Internet using an Internet service provider).

[0066] Aspects of the present disclosure are described herein with reference to flowcharts or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. Each block in a flowchart or block diagram, and any combination of blocks within a flowchart or block diagram, is understood to be implementable by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a dedicated computer, or any other programmable data processing device to generate a machine, and instructions executed through the processor of the computer or other programmable data processing device create means for implementing the functions / operations specified in the blocks of the flowchart or block diagram.

[0067] Furthermore, these computer program instructions can be stored in a computer-readable medium that can instruct a computer, other programmable data processing device, or other device to function in a specific way, thereby generating a product that includes instructions that perform actions / operations specified in a flowchart or block diagram by the instructions stored in the computer-readable medium.

[0068] Furthermore, computer program instructions are loaded into a computer, another programmable data processing device, or another device, and a series of operational steps are executed on the computer, another programmable device, or another device, generating a computer execution process, which in turn provides a process for instructions executed on the computer, another programmable data processing device, or another device to perform the actions / operations specified in the blocks of a flowchart or block diagram.

[0069] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of the systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for performing a specified logical action. It should also be noted that in some alternative implementations, the actions shown in the blocks may occur in a different order than shown in the diagram. For example, two consecutively shown blocks may actually be executed almost simultaneously, or blocks may be executed in reverse order or in a different order depending on the function they relate to. It should also be noted that each block in a block diagram or flowchart, and any combination of blocks in a block diagram or flowchart, may be executed by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to perform a specified action or operation.

[0070] The foregoing relates to embodiments of the present disclosure, but other embodiments and further embodiments of the present disclosure may be created without departing from its basic scope, the scope of which is defined by the following claims.

Claims

1. The process of receiving a first request from a first user for a link to streaming content, A step of determining the geographical location of the first user based on the first requirement, A step of generating a geo-specific token that describes the geographic location of a first user, the step of generating a geohash that describes the geographic location of the first user, A step of sending a link to streaming content to a first user, wherein the link includes a geo-specific token, A step of receiving a second request for streaming content based on a link, wherein the second request includes a geo-specific token, A method comprising the step of rejecting a second request for streaming content based on comparing a geo-specific token with additional geographic information determined based on the second request.

2. The method according to claim 1, wherein the first request is received in the content provider's computing environment, and the second request is received in a content delivery network (CDN) different from the content provider's computing environment.

3. The method according to claim 2, wherein the link to the streaming content includes a geo-specific token and includes a uniform resource locator (URL) that identifies the location of the content in the CDN.

4. The method according to claim 3, wherein the geographic location of the first user is obfuscated within a geo-specific token.

5. The step of determining the geographical location of the first user based on the first requirement is: A step of identifying a first property of a first request, wherein the first property includes at least one of (i) an IP address associated with a first user, (ii) latitude or longitude associated with a first user, (iii) a cellular subscriber identifier associated with a first user, or (iv) a network service provider header associated with a first request. The method according to claim 1, further comprising the step of determining the geographical location of a first user based on a first property.

6. The method according to claim 1, wherein a geo-specific token describes the geographic location of a first user at a defined granularity level, the granularity level being determined to reduce errors for users requesting streaming content compared to different granularity levels.

7. The method according to claim 1, wherein the step of rejecting a second request for streaming content includes initiating an additional request for streaming content by the first user.

8. Rejecting a second request for streaming content based on comparing geo-specific tokens with additional geographic information determined based on the second request is: A process of determining a first geographic location based on geographically specific tokens, A process of determining a second geographical location based on a second requirement, The method according to claim 1, comprising the step of determining that the first geographical location does not coincide with the second geographical location.

9. The process of receiving a third request for second streaming content from a second user, A step of determining the second geographical location of the second user based on the third requirement, The process involves generating a second geographically specific token that describes the second geographic location of a second user, A step of sending a second link to a second streaming content to a second user, wherein the second link includes a second geo-specific token. A step of receiving a fourth request for second streaming content based on a second link, wherein the fourth request includes a second geo-specific token. The method according to claim 1, further comprising the step of authorizing a fourth request for second streaming content based on the determination that the second geographic location of a second user described in a second geo-specific token matches additional geographic information determined based on a fourth request.

10. It is a system, One or more processors, One or more memory locations where a program stores an operation when executed by a combination of one or more processors; the operation is: The process of receiving a first request from a first user for a link to streaming content, A step of determining the geographical location of the first user based on the first requirement, The process involves generating a geo-specific token that describes the geographic location of the first user, A step of sending a link to streaming content to a first user, wherein the link includes a geo-specific token, A step of receiving a second request for streaming content based on a link, wherein the second request includes a geo-specific token, The process includes a step of rejecting a second request for streaming content based on comparing a geo-specific token with additional geographic information determined based on the second request, A geo-specific token describes the geographic location of a first user at a defined granularity level, and the granularity level is determined to reduce user errors when requesting streaming content compared to different granularity levels in a memory-based system.

11. The system according to claim 10, wherein the first request is received in the content provider's computing environment, and the second request is received in a content delivery network (CDN) different from the content provider's computing environment.

12. The system according to claim 11, wherein the link to the streaming content includes a geo-specific token and includes a uniform resource locator (URL) that identifies the location of the content in the CDN.

13. The step of determining the geographical location of the first user based on the first requirement is: A step of identifying a first property of a first request, wherein the first property includes at least one of (i) an IP address associated with a first user, (ii) latitude or longitude associated with a first user, (iii) a cellular subscriber identifier associated with a first user, or (iv) a network service provider header associated with a first request. The system according to claim 10, comprising the step of determining the geographical location of a first user based on a first property.

14. The process of rejecting a second request for streaming content based on comparing a geo-specific token with additional geographic information determined based on the second request is as follows: A process of determining a first geographic location based on geographically specific tokens, A process of determining a second geographical location based on a second requirement, The system according to claim 10, further comprising the step of determining that the first geographical location does not coincide with the second geographical location.

15. When executed by an operation of one or more computer processors, a non-temporary computer-readable medium containing computer program code that performs the operation, the operation is, The process of receiving a first request from a first user for a link to streaming content, A step of determining the geographical location of the first user based on the first requirement, The process involves generating a geo-specific token that describes the geographic location of the first user, A step of sending a link to streaming content to a first user, wherein the link includes a geo-specific token, A step of receiving a second request for streaming content based on a link, wherein the second request includes a geo-specific token, A non-temporary computer-readable medium comprising the steps of rejecting a second request for streaming content based on comparing a geo-specific token with additional geographic information determined based on the second request, and initiating an additional request for streaming content by the first user.

16. The non-temporary computer-readable medium according to claim 15, wherein the first request is received in the content provider's computing environment, and the second request is received in a content delivery network (CDN) different from the content provider's computing environment.

17. The non-temporary computer-readable medium according to claim 16, wherein the link to the streaming content includes a geo-specific token and a uniform resource locator (URL) that identifies the location of the content in the CDN.

18. The step of determining the geographical location of the first user based on the first requirement is: A step of identifying a first property of a first request, wherein the first property includes at least one of (i) an IP address associated with a first user, (ii) latitude or longitude associated with a first user, (iii) a cellular subscriber identifier associated with a first user, or (iv) a network service provider header associated with a first request. The non-temporary computer-readable medium according to claim 15, comprising the step of determining the geographical location of a first user based on a first property.

19. The process of rejecting a second request for streaming content based on comparing a geo-specific token with additional geographic information determined based on the second request is as follows: A process of determining a first geographic location based on geographically specific tokens, A process of determining a second geographical location based on a second requirement, The non-temporary computer-readable medium according to claim 15, comprising the step of determining that the first geographical location does not coincide with the second geographical location.

Images