Real-time geo-lock content distribution 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 content delivery networks (CDNs). However, unauthorized access to content can occur when authorized users share these links with unauthorized users. For example, authorized subscribers of a streaming platform can share a CDN playback uniform resource identifier (e.g., a uniform resource locator (URL)) with non-subscribers. The non-subscribers may be able to access the playback URL outside of the content provider's platform and play the content against the CDN. This has serious drawbacks, including overloading the CDN and content provider network and degrading the playback experience for authorized users. [Brief explanation of the drawings]

[0002] So that the above-mentioned aspects may be achieved and understood in detail, a more particular description of the embodiments described hereinabove briefly summarized may be had by reference to the accompanying drawings, in which:

[0003] It is to be understood, however, that the accompanying drawings illustrate exemplary embodiments and are not limiting, as other embodiments may be equally effective. [Figure 1] FIG. 1 is a block diagram illustrating a geo-locked content distribution token computing environment according to at least one embodiment. [Figure 2] FIG. 1 is a block diagram illustrating a controller for a geo-locked content distribution token according to at least one embodiment. [Figure 3] 1 illustrates geo-locked content delivery to authorized users in accordance with at least one embodiment. [Figure 4]1 is a flowchart illustrating the delivery of geo-locked content to authorized users according to at least one embodiment. [Figure 5] 1 is a flowchart illustrating generating geographically specific links for delivery of geo-locked content to authorized users, according to at least one embodiment. [Figure 6] 1 is a flowchart illustrating an attempted delivery of geo-locked content to an unauthorized user, according to at least one embodiment. Detailed Description

[0004] As mentioned above, the sharing of 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 content rights. While DRM allows the sharing of a playback URL with non-subscribers, because the content is encrypted using DRM, non-subscribers typically do not have access to the DRM license required to decrypt the content.

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

[0006] Another solution is token revocation. Token revocation relies on tokenized URLs. The token contains 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 valid at the time (based on expiration date, URL path, etc.).

[0007] However, content providers can analyze the use of their individual tokens (e.g., using information provided by their backend systems and the CDN) to identify suspicious access patterns. They can then work with the CDN to revoke access for those tokens. However, one drawback of token revocation is that it takes a reactive approach to detection and prevention. Furthermore, it relies on logging activity at the CDN (e.g., potentially generating large volumes of logs and requiring significant computational bandwidth) and on signaling (e.g., heuristic or rule-based) from the CDN to identify suspicious usage. This can be inaccurate, leading to false positives and false negatives, and is computationally intensive on the system (e.g., due to the signaling required between the CDN and the content provider and the analysis required in one or both systems).

[0008] One or more embodiments described herein are based on the use of CDN access tokens by including a geographic aspect within the token. In one embodiment, a content provider generates a geo-lock token based on the geographic location of the requester, and this geo-lock token is provided to the requester as part of the content link (e.g., as part of the URL), so that the geo-lock token is used when requesting the content from the CDN. To play the content, the geo-location of the user accessing the link requesting the content from the CDN must match the geo-location of the user requesting the content from the content provider, as recorded in the geo-lock token.

[0009] In one embodiment, geo-locked tokens provide an active approach to security based on the premise that a subscriber's geographic location typically does not change significantly during the very short time frame between accessing a content provider and requesting content from a CDN. This enables a real-time approach to preventing unauthorized users from accessing content. Furthermore, because the requesting user's geographic location can be easily accessed using the user's Internet Protocol (IP) address or other geographic information, this is relatively inexpensive in terms of computation and implementation and does not require building new workflows across CDNs and content providers. In one embodiment, the use of geo-locked tokens can provide active security (as opposed to reactive security provided by, for example, token revocation) without requiring DRM.

[0010] Furthermore, the use of geo-locked tokens offers many technical advantages over traditional solutions. For example, as noted above, it requires minimal development changes across the computing environment (as opposed to DRM solutions) and avoids the significant computational overhead associated with DRM. As another example, the use of geo-locked tokens is stateless and asynchronous, eliminating the need to capture and maintain logs at the CDN (as opposed to token revocation solutions, for example). This significantly reduces the computing and storage load on the system, reducing development time and resources.

[0011] 1 is a block diagram illustrating a geo-locked content distribution token computing environment 100 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 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 and serves the content 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., a laptop computer, a desktop computer, a smartphone, a tablet, an Internet of Things (IoT) device, a smart television device, a wearable device, a digital media player device, a gaming device, or other suitable computing device) to access content provider service stack 120 using a suitable communications network, as described further below.

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

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

[0015] In one embodiment, the subscriber 102 is authorized to access the requested content from the content provider service stack 120, but the non-subscriber 104 is not authorized to access this content (e.g., the non-subscriber 104 does not maintain the appropriate subscription to access the content). By sharing the playback link 124, the subscriber 102 may be able to provide the non-subscriber 104 with unauthorized access to the content.

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

[0017] As described further below in connection with Figures 3-6, in one embodiment, the content provider service stack 120 mitigates this problem by providing a geo-locked token in the playback link 124. In one embodiment, the content provider service stack 120 uses the geographic location of the subscriber 102 to generate a token that restricts access to the content to the required geographic location. The subscriber 102 includes the token received from the content provider service stack 120 in a content request 132A to the CDN 130 (e.g., as part of the URL provided in the playback link 124). The CDN 130 compares the geographic location of the requesting subscriber 102 with the geographic location recorded in the content request 132A to provide access to the content. In contrast, if the subscriber 102 attempts to share the playback link 124 with a non-subscriber 104 in a different geographic location, the CDN 130 can refuse to provide access to the content based on a discrepancy between the expected geographic location in the content request 132B and the actual geographic location of the non-subscriber 104. As mentioned above, this is further explained below in connection with Figures 3-6.

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

[0019] For example, content provider service stack 120 and CDN 130 may each be implemented using a respective server or server cluster. As another example, content provider service stack 120 and CDN 130 may be implemented using a combination of computing nodes and storage locations in a suitable cloud environment. For example, one or more components of content provider service stack 120 and CDN 130 may be implemented using a public cloud, a private cloud, a hybrid cloud, or other suitable implementation. Furthermore, subscriber 102, non-subscriber 104, or both, may be implemented using any number or combination of computing devices.

[0020] 2 is a block diagram illustrating a geo-locked content distribution token controller, according to at least one embodiment. In one embodiment, content provider controller 200 corresponds to an aspect of content provider service stack 120 shown in FIG. 1. Content provider controller 200 includes processor 202, memory 210, and network component 220. Processor 202 typically retrieves and executes programming instructions stored in memory 210. Processor 202 may include a single central processing unit (CPU), multiple CPUs, a single CPU with multiple processing cores, a graphics processing unit (GPU) with multiple execution paths, etc.

[0021] Network component 220 includes components necessary for content provider controller 200 to interface with components on a network (see, e.g., FIG. 1). For example, content provider controller 200 is part of a content provider service stack, and content provider controller 200 can use network component 220 to interface with remote storage and computing nodes using the network components (e.g., subscribers 102, non-subscribers 104, CDN 130, or other suitable components). Alternatively or additionally, content provider controller 200 can correspond to another portion of computing environment 100 (e.g., CDN 130 or another suitable location).

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

[0023] Although memory 210 is shown as a single entity, 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. Memory 210 generally includes program code for performing various functions associated with the use of content provider controller 200. The program code is generally described as various functional "applications" or "services" within memory 210, although alternative implementations may have different functions and / or combinations of functions. Within memory 210, content linking service 212 facilitates the generation of geo-locked content distribution tokens, as described in further detail in the following figures.

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

[0025] Network component 270 includes components necessary for CDN controller 250 to interface with components on a network (e.g., as shown in FIG. 1). For example, CDN controller 250 is part of CDN 130, and CDN controller 250 can use network component 270 to interface with remote storage nodes and computing nodes that use the network component (e.g., subscribers 102, non-subscribers 104, content provider service stack 120, or other suitable components). Alternatively or additionally, CDN controller 250 can correspond to another portion of computing environment 100 (e.g., content provider service stack 120 or another suitable location).

[0026] CDN controller 250 may 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. Network component 270 may include wired, WiFi, or cellular network interface components and associated software to facilitate communication between CDN controller 250 and the communications network.

[0027] Although memory 260 is shown as a single entity, 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. Memory 260 generally includes program code for performing various functions associated with the use of CDN controller 250. The program code is generally described as various functional "applications" or "services" within memory 260, although alternative implementations may have different functions and / or combinations of functions. Within memory 260, CDN verification service 262 facilitates verification of geo-locked content delivery tokens, as described in further detail in the following figures.

[0028] 2, content linking service 212 is located in memory 210 and CDN verification service 262 is located in memory 260, but this representation is provided merely for clarity of explanation. More generally, content provider controller 200 and CDN controller 250 can each include one or more computing platforms, such as computer servers, which can be co-located or 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, processors 202, 252 and memories 210, 260 can correspond to distributed processor and memory resources within a computing environment.

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

[0030] For example, subscriber 302 may send a content request 322 to content provider service stack 320 (e.g., using an appropriate computing device and communications network as described in connection with FIG. 1 ). In one embodiment, content provider service stack 320 validates the request (e.g., verifies that the subscriber has authorization to access the requested content) and generates a geo-specific playback link.

[0031] For example, the content provider service stack 320 can use information included in the content request 322 to determine the geographic location of the subscriber 302 (e.g., the subscriber's IP address, or other suitable information, etc.). The content provider service stack can use the geographic location to generate a geographically specific playback link 324. For example, the content provider can generate a URL (e.g., a URL identifying the storage location of the content on the CDN 330) that includes a geographically specific token (e.g., a token that identifies the geographic location of the subscriber 302, etc.), as further described below with reference to Figures 4-6.

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

[0033] 1 , in one embodiment, subscriber 302 is authorized to access the requested content from content provider service stack 320, but non-subscriber 304 is not authorized to access this content (e.g., non-subscriber 304 does not hold the appropriate subscription to access the content). Subscriber 302 may (e.g., intentionally or unintentionally) share a geographically-specific playback link 324 with non-subscriber 304 who is in a different geographic location than subscriber 302. However, unlike in FIG. 1 , non-subscriber 304 is unable to access the requested content due to the geographically-specific playback link 324.

[0034] For example, the non-subscriber 304 can send a content request 332B to the CDN 330 using the geography-specific playback link 324 (e.g., a URL included in the geography-specific playback link 324, including a geography-specific token). The CDN 330 can validate the request. For example, the CDN 330 can compare the geographic information included in the geography-specific playback link 324 (e.g., the geography-specific token) with the geographic information included 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). Because the non-subscriber 304 is in a different geographic location than the subscriber 302, the geographic information included in the geography-specific playback link 324 does not match the geographic information included in the content request 332B that identifies the geographic location of the non-subscriber 304 (e.g., the geography-specific token included in the geography-specific playback link 324 does not match the geographic location indicated by the IP address of the non-subscriber 304). Therefore, the CDN 330 returns a rejection 336 (e.g., instead of the content item). As further described below with respect to Figure 6, this rejection may include an error, initiation of a re-request by the subscriber 302, or other appropriate rejection action.

[0035] 1, in one embodiment, the various components of computing environment 300 communicate using one or more suitable communications networks, including the Internet, a wide area network, a local area network, or a cellular network, and use any suitable wired or wireless communications technology (e.g., WiFi or cellular communications). Further, in one embodiment, content provider service stack 320 and CDN 330 may 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 the CDN 330 may be implemented using a respective server or server cluster. As another example, the content provider service stack 320 and the CDN 330 may be implemented using a combination of computing nodes and storage locations in a suitable cloud environment. For example, one or more components of the content provider service stack 320 and the CDN 330 may be implemented using a public cloud, a private cloud, a hybrid cloud, or other suitable implementation. Furthermore, the subscribers 302, the non-subscribers 304, or both, may be implemented using any number or combination of computing devices.

[0037] 4 is a flowchart 400 illustrating delivery of geo-locked content to authorized users, according to at least one embodiment. At block 402, a subscriber (e.g., subscriber 302 shown in FIG. 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 FIG. 2) using an appropriate communications network (e.g., the Internet, a LAN, a WAN, a cellular communications network, or other suitable communications network).

[0038] At block 404, the content provider generates a geographically specific link. In one embodiment, a content linking service (e.g., the content linking service 212 shown in FIG. 2) can use information in the playback link request to identify the subscriber's geographic location, as described in more detail below with reference to FIG. 5. For example, the content linking service can use the subscriber's IP address or other suitable information to identify the subscriber's geographic location. Further, as described below with reference to FIG. 5, the content linking service can identify the geographic location at an appropriate level of granularity (e.g., city, county, state, residential area, or other appropriate level of granularity). The content linking 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] At block 406, the subscriber requests the content using the geographically specific link. In one embodiment, the link identifies a content item from the appropriate CDN, and the subscriber follows the link to obtain the content. For example, the geographically specific link may be a URL that includes a geographically specific token. The subscriber can access the URL to obtain the content from the CDN.

[0040] In block 408, the CDN evaluates the geo-specific link. 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 the geo-specific link (e.g., a URL containing a geo-specific token) generated by the content provider's content linking service. A CDN verification service (e.g., CDN verification service 262 shown in FIG. 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 verification service fulfills the request. If they do not match, the CDN verification service does not fulfill the request.

[0041] In one embodiment, the CDN can evaluate the geographically specific links for every received content request. Alternatively or additionally, the CDN can evaluate the geographically specific links at defined times. For example, the CDN can evaluate the geographically specific links only at the beginning 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 between geographic locations (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 geographic location (e.g., current geographic location, expected geographic location, or both) to account for the subscriber's physical movement. For example, the CDN validation service can define a required radius (e.g., a distance around a specific point expressed in latitude and longitude) as a cushion around the geographic location. This required radius can be hard-coded or configurable (e.g., pre-operation or runtime). If the current geographic location and the expected geographic location match within this radius, the request can be evaluated as valid.

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

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

[0044] The use of an IP address is merely an example, and the content linking service may use any suitable technique (e.g., a cellular network identifier, an application-specific identifier, or other suitable technique) to identify the geographic location of the requester. For example, a request to the content linking service may include latitude and longitude information, a cellular network geographic identification (e.g., base station or subscriber identification information), a network service provider header, or other suitable information. The content linking service may resolve this information to identify the geographic location of the requester.

[0045] In one embodiment, a requester may use a virtual private network (VPN) or other technology to attempt to mask the requester's actual geographic location. For example, a requester may use a VPN to provide the content linking service with an IP address that matches the requester's desired geographic location (e.g., to enable unauthorized content sharing) rather than the requester's actual geographic location. In one embodiment, the content linking service (or other suitable software service) may take appropriate measures for this scenario. For example, the content linking service may use VPN detection to prohibit a requester using a VPN from obtaining content. This is merely an example, and the content linking service may take any appropriate measures (e.g., relying on geographic identification information separately from or in addition to IP address).

[0046] In one embodiment, the content linking service can identify the geographic location of the requester at a desired level of granularity. For example, the content linking service can identify the geographic location at a country level, a state level, a county level, a city level, a city level (such as a neighborhood or other area), or any other suitable level of granularity. The level of granularity can be set by the content provider, determined in advance, or determined using any other suitable technique. 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 subregions.

[0047] In one embodiment, the content linking service can use geohash technology to identify geographic locations 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 geographic locations into hierarchical code values ​​(e.g., combinations of numbers and letters) that indicate the location. For example, geohash involves dividing geographic space into grid-shaped buckets (e.g., using space-filling curves). Typically, the longer the code, the more precise the geographic designation (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 granularity, from tens of kilometers to hundreds of kilometers or even thousands of kilometers.

[0048] In one embodiment, the granularity of the 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 widely 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., the IPv4 address may return one location, but the IPv6 address for the same user may return a different location), which can also lead to errors. In one embodiment, the granularity level can be selected so that the geographic location of the requester is specific enough to protect against unauthorized access by others, yet general enough to avoid a negative user experience due to inaccurate or inconsistent IP lookups.

[0049] Another potential consideration is the mobility of the requester. In one embodiment, the requester may be in motion (e.g., in a car, train, plane, or other vehicle). Granular geographic locations can be a source of errors because the user may move geographically between the time of the request to the content provider service stack and the time of 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 and receive a geographically specific playback link tied to that first location, and may be in a second location when the user requests content from the CDN. If the geographic location is too granular, the user may be erroneously denied access based on this mobility. 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 connection with block 408 of FIG. 4, potential movement of a requester can be addressed by evaluating the geography-specific link only at defined times (e.g., only at the start of playback of the content or at regular intervals), by defining a desired radius around the geographic location for evaluation, or by a combination of suitable techniques. As an example, a CDN validation service (or other suitable software service) can evaluate the geography-specific link only at the start of playback. This limits the time between generation of the geography-specific token and evaluation of the geography-specific link to a very short period (e.g., less than one minute), reducing the likelihood of an error occurring if the requester moves geographically sufficiently.

[0051] Additionally, the CDN validation service may modify the frequency, geographic radius or granularity of evaluation, or other appropriate characteristics, based on whether the requester is a mobile device. For example, the movement of the requester may be an issue only for mobile devices. The CDN validation service may use information in the request or other appropriate information to identify that the requester is a mobile device and modify the evaluation flow (e.g., frequency or timing, radius, granularity) based on this identification. This may allow the CDN validation service to apply a different evaluation technique (e.g., less frequent evaluation, less granularity of geographic identification, a larger radius around a geographic location, or other appropriate distinction) to mobile devices to avoid falsely denying access to authorized users, while performing more frequent evaluations for other devices.

[0052] In block 504, the content linking service generates a geo-specific token. In one embodiment, the token includes the detected geographic location of the requester at a desired level of granularity. For example, the token can correspond to an ISO 3166-2 code, a geohash, a combination of the two, or any other suitable value.

[0053] In block 506, the content linking service provides the subscriber with a link that includes the geography-specific token. For example, the content linking service can provide the subscriber with a URL that includes the geography-specific token as a property of the URL. The token, by way of example, is a field or property embedded in the URL (e.g., a key-value pair within the URL) that reflects the geography location of the requester (e.g., a string included in the URL that reflects the geography location). This is merely an example, and the geography-specific token can be any suitable value using any suitable technique. In one embodiment, the token can be obfuscated for security purposes to prevent the requester from identifying or modifying the value. For example, the token can be modified using encryption (e.g., using public key encryption), encoding, hashing, or other suitable obfuscation.

[0054] 6 is a flowchart 600 illustrating an attempt to deliver geo-locked content to an unauthorized user, according to at least one embodiment. In one embodiment, flowchart 600 is similar to flowchart 400 shown in FIG. 4, except that the user requesting the content from the CDN is not in the same geographic location as the user accessing the content provider service stack, and therefore the content is not provided to the user (e.g., it is assumed that the user is not a valid subscriber).

[0055] In block 602, a subscriber (e.g., subscriber 302 shown in FIG. 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 FIG. 2) using an appropriate communication network (e.g., the Internet, a LAN, a WAN, a cellular communication network, or other appropriate communication network).

[0056] At block 604, the content provider generates a geographically specific link. In one embodiment, a content linking service (e.g., content linking service 212 shown in FIG. 2) can use information in the playback link request to determine the subscriber's geographic location. This was described in more detail in FIG. 5. For example, the content linking service can use the subscriber's IP address or other suitable information to determine the subscriber's geographic location. Further, as described in FIG. 5, the content linking 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 linking 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, the subscriber provides the geographically specific link to the non-subscriber. For example, the subscriber may share the link received in block 604 with another entity that is not the subscriber. This may be done intentionally or unintentionally (e.g., a malicious third party may intercept or eavesdrop on the transmission of the link).

[0058] In block 608, the non-subscriber requests the content using a geographically specific link. In one embodiment, the link identifies a content item on the appropriate CDN, and the non-subscriber follows the link to attempt to obtain the content. For example, the geographically specific link is a URL that includes a geographically specific token. The non-subscriber accesses the URL to attempt to obtain the content from the CDN.

[0059] At 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 geographic location than the requester to the content provider service stack. In one embodiment, the content request from the non-subscriber includes both the non-subscriber's current geographic location (e.g., an IP address or other geographic identifier) ​​and a geographically specific link (e.g., a URL including a geographically specific token) generated by the content provider's content linking service. A CDN verification service (e.g., CDN verification service 262 shown in FIG. 2) compares the non-subscriber's current geographic location with the expected geographic location recorded in the geographically specific link. Because the geographic locations do not match, the CDN rejects the request.

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

[0061] For example, as part of rejecting the request, the CDN may contact the content provider service stack, the requester, both, or other appropriate network components to initiate a revalidation of the subscriber. The subscriber can initiate another content request (e.g., automatically or based on user input), and the content provider service stack and CDN can validate the geographic match of this request. This can be used to ensure that valid subscribers are not inadvertently blocked from content (e.g., if an error occurs in geographic validation).

[0062] This disclosure refers to various embodiments. However, it should be understood that the disclosure is not limited to the specific embodiments described. Instead, any combination of the following features and elements, whether related to different embodiments, is contemplated for implementing and practicing the teachings provided herein. Furthermore, when an element of an embodiment is described in the form of "at least one of A and B," it is understood that an embodiment including only element A, an embodiment including only element B, and an embodiment including elements A and B are each contemplated. Furthermore, while some embodiments may realize advantages over other possible solutions or the prior art, whether or not a particular advantage is achieved by a particular embodiment does not limit the disclosure. Accordingly, the aspects, features, embodiments, and advantages disclosed herein are merely exemplary and are not considered elements or limitations of the appended claims unless expressly recited in the claims. Similarly, references to "the present invention" should not be construed as generalizations of the inventive subject matter disclosed herein, and are not considered elements or limitations of the appended claims unless expressly recited in the claims.

[0063] As will be appreciated by one skilled in the art, the embodiments described herein may be embodied as a system, method, or computer program product. Accordingly, the embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects (collectively referred to herein as a "circuit," "module," or "system"). Furthermore, the embodiments described herein may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0064] The program code embodied in the computer readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, etc., or any suitable combination thereof.

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

[0066] Aspects of the present disclosure are described herein with reference to flowchart illustrations or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flowchart illustrations or block diagrams, and combinations of blocks in the flowchart illustrations or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce machine-readable instructions that, when executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / operations specified in the blocks of the flowchart illustrations or block diagrams.

[0067] These computer program instructions may also be stored on a computer-readable medium that can instruct a computer, other programmable data processing apparatus, or other device to function in a particular manner, thereby producing an article of manufacture including instructions that perform the actions / operations specified in the flowchart or block diagram blocks according to the instructions stored on the computer-readable medium.

[0068] Furthermore, the computer program instructions can be loaded into a computer, other programmable data processing apparatus, or other device, and a series of operational steps executed on the computer, other programmable data processing apparatus, or other device to generate a computer-implemented process, whereby the instructions executing on the computer, other programmable data processing apparatus, or other device provide a process for performing the actions / operations specified in the blocks of the flowchart diagrams or block diagrams.

[0069] The flowchart diagrams and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart diagrams or block diagrams may represent a module, segment, or portion of code, including one or more executable instructions for performing specified logical functions. It should also be noted that in some alternative implementations, the functions shown in the blocks may occur in a different order than that shown in the figures. For example, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may be executed in the reverse order or in a different order, depending on the functionality involved. It should also be noted that each block in the block diagrams or flowchart diagrams, and combinations of blocks in the block diagrams or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or a combination of dedicated hardware and computer instructions.

[0070] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the present disclosure may be made without departing from the basic scope thereof, which scope is defined by the following claims.

Claims

1. receiving a first request for a link to streaming content from a first user; determining a geographic location of the first user based on the first request; generating a geographically specific token describing a geographic location of the first user; sending a link to the streaming content to the first user, the link including a geographically specific token; receiving a second request for the streaming content based on the link, the second request including the geo-specific token; A method comprising denying a second request for streaming content based on comparing the geography-specific token to additional geographic information determined based on the second request.

2. 10. The method of claim 1, wherein the first request is received at a computing environment of the content provider and the second request is received at a content delivery network (CDN) that is different from the computing environment of the content provider.

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

4. The method of claim 3 , wherein the geographic location of the first user is obfuscated within the geographically specific token.

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

6. generating a geographically specific token describing the geographic location of the first user, The method of claim 1 , comprising generating a geohash describing the geographic location of the first user.

7. 2. The method of claim 1, wherein the geographically specific token describes the geographic location of the first user at a defined level of granularity, the level of granularity being determined to reduce errors of the user requesting the streaming content compared to different levels of granularity.

8. The method of claim 1 , wherein denying the second request for the streaming content comprises initiating an additional request for the streaming content by the first user.

9. Denying the second request for the streaming content based on comparing the geography-specific token to the additional geographic information determined based on the second request includes: determining a first geographic location based on the geography-specific token; determining a second geographic location based on the second request; The method of claim 1 , further comprising determining that the first geographic location does not match the second geographic location.

10. receiving a third request for the second streaming content from a second user; determining a second geographic location of the second user based on the third request; generating a second geographically specific token describing a second geographic location of the second user; sending a second link to the second streaming content to the second user, the second link including a second geo-specific token; receiving a fourth request for the second streaming content based on the second link, the fourth request including the second geo-specific token; 2. The method of claim 1, further comprising: granting a fourth request for the second streaming content based on a determination that a second geographic location of the second user described in the second geography-specific token matches additional geographic information determined based on the fourth request.

11. 1. A system comprising: one or more processors; One or more memories storing a program that, when executed in combination with one or more processors, performs operations, the operations including: receiving a first request for a link to streaming content from a first user; determining a geographic location of the first user based on the first request; generating a geographically specific token describing a geographic location of the first user; sending a link to the streaming content to the first user, the link including a geographically specific token; receiving a second request for the streaming content based on the link, the second request including the geo-specific token; A system comprising a memory, the system including the step of denying a second request for streaming content based on comparing the geography-specific token to additional geographic information determined based on the second request.

12. 12. The system of claim 11, wherein the first request is received at a computing environment of the content provider and the second request is received at a content delivery network (CDN) different from the computing environment of the content provider.

13. 13. The system of claim 12, wherein the link to the streaming content includes a geographically specific token and includes a uniform resource locator (URL) that identifies the location of the content on the CDN.

14. The step of determining the geographic location of the first user based on the first request includes: identifying a first property of the first request, the first property including at least one of (i) an IP address associated with the first user, (ii) a latitude or longitude associated with the first user, (iii) a cellular subscriber identifier associated with the first user, or (iv) a network service provider header associated with the first request; The system of claim 11 , further comprising determining a geographic location of the first user based on the first property.

15. The step of denying the second request for the streaming content based on comparing the geography-specific token to the additional geographic information determined based on the second request includes: determining a first geographic location based on the geography-specific token; determining a second geographic location based on the second request; The system of claim 11 , further comprising determining that the first geographic location does not match the second geographic location.

16. A non-transitory computer readable medium containing computer program code that, when executed by operation of one or more computer processors, performs operations, the operations including: receiving a first request for a link to streaming content from a first user; determining a geographic location of the first user based on the first request; generating a geographically specific token describing a geographic location of the first user; sending a link to the streaming content to the first user, the link including a geographically specific token; receiving a second request for the streaming content based on the link, the second request including the geo-specific token; 12. A non-transitory computer-readable medium comprising: denying a second request for streaming content based on comparing the geography-specific token to additional geographic information determined based on the second request.

17. 17. The non-transitory computer-readable medium of claim 16, wherein the first request is received at a computing environment of the content provider and the second request is received at a content delivery network (CDN) different from the computing environment of the content provider.

18. 20. The non-transitory computer-readable medium of claim 17, wherein the link to the streaming content includes a uniform resource locator (URL) that includes a geographically specific token and identifies the location of the content on a CDN.

19. The step of determining the geographic location of the first user based on the first request includes: identifying a first property of the first request, the first property including at least one of (i) an IP address associated with the first user, (ii) a latitude or longitude associated with the first user, (iii) a cellular subscriber identifier associated with the first user, or (iv) a network service provider header associated with the first request; The non-transitory computer-readable medium of claim 16 , further comprising determining a geographic location of the first user based on the first property.

20. The step of denying the second request for the streaming content based on comparing the geography-specific token to the additional geographic information determined based on the second request includes: determining a first geographic location based on the geography-specific token; determining a second geographic location based on the second request; 17. The non-transitory computer-readable medium of claim 16, comprising determining that the first geographic location does not match the second geographic location.

Images