DESC:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003

COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
METHOD AND SYSTEM FOR AUTHENTICATING A CONTENT VIEWER WHILE STREAMING CONTENT

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

Novi Digital Entertainment Private Limited

Indian

Star House, Urmi Estate, 95 Ganpatrao Kadam Marg, Lower Parel (W) Mumbai 400 013, Maharashtra, India

3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

4. DESCRIPTION
(See next page)

METHOD AND SYSTEM FOR AUTHENTICATING A CONTENT VIEWER WHILE STREAMING CONTENT

I. Technical Field:

[0001] The invention generally relates to the delivery of content such as streaming content, i.e., media content to end-users by Over-The-Top (OTT) streaming content providers and, more particularly, to a method and system for authenticating a content viewer while streaming content from content delivery networks (CDNs).

II. Background:

[0002] In recent times, digital content streaming has become hugely popular among viewers of online content. Subscribers (i.e., content viewers) are increasingly using a variety of electronic devices to access streaming content using Over-The-Top (OTT) media services (i.e., over the Internet) from any location. Conventionally, when a subscriber selects media content for playback on the subscriber’s electronic device, a request for content access is transmitted to a platform associated with a content provider. The platform authenticates the subscriber and performs an entitlement check to determine whether the subscription of the subscriber allows access to the requested media content. If the authentication and the entitlement checks are successful, the platform provides an initial token, known as a first token to the electronic device. It noted that the first token is referred interchangeably hereinafter to as a ‘short token’, for simplicity. The short token includes a playback URL, which identifies a content delivery network (CDN) where the media content is cached. The electronic device forwards the short token to the CDN, which performs basic token validation and provides the electronic device with a second token. The second token is a tokenized URL manifest which includes the URLs corresponding to different renditions of the same content (with different resolutions and bitrates) within a CDN. In a non-limiting example, the URLs may correspond to a CDN point of presence (PoP), i.e., a CDN content store from where the content can be streamed. It noted that the second token is referred interchangeably hereinafter to as a ‘long token’, for simplicity. The electronic device uses the URL of the CDN PoP to receive the stream of the requested media content.

[0003] In some scenarios, the subscriber may share the long token provided by the CDN with other illegitimate/non-entitled users, who may then use the tokenized URL manifest to access the media content from the CDN without subscribing to the streaming content services offered by the content provider. Such unauthorized or illegitimate sharing of long tokens is referred to herein as ‘illicit long token sharing’. The CDN or sub-CDN (such as CDN POP), which receives only the URL from multiple illegitimate users may not be equipped to check whether the request is from a legitimate/genuine subscriber or not, without verifying each content request with the content provider’s platform by performing various verification checks. However, it is noted that as the number of verification checks at any stage in the streaming process increase, the overall latency between receiving a content request and the content being served also increases. Therefore, causing delays in content delivery and bad user experience. Further, performing a large number of verification checks will be computationally intensive thereby, leading to a waste of processing resources. For example, if the content being streamed is a live-streaming event, where users can join instantly to watch the event. Then, during such events, users can drop and join the stream at any time which causes tremendous fluctuations in the requirement for processing resources. Further, since live events (such as sports) are seasonal in nature, therefore maintaining permanent processing resources would be cost inefficient. To that end, performing verification checks will be cost-inefficient and computationally expensive.

[0004] In some scenarios, an illegitimate user may manipulate a content provider’s application installed on a personal electronic device to bypass a concurrent streaming restriction mandated by the user’s subscription and make multiple short token requests for streaming different content. Such bypassing of a restriction implemented by the content provider is referred to herein as ‘concurrency restriction bypass’ or simply as ‘concurrency bypass’. Using the short tokens supplied by the content provider’s platform, the illegitimate user’s electronic device may proceed to receive the long tokens from the CDN and thereafter access multiple media contents from the sub-CDN.

[0005] Given the foregoing, there is a need to authenticate a content viewer while streaming content from the CDNs to prevent illegitimate access to the content from illegitimate content viewers. It would also be advantageous to allow only legitimate/genuine users to access streaming content and prevent illegitimate activities like long token sharing and concurrency bypass, which lead to increased computational requirements for the content provider while also breaching the rights of the content provider and for the content creation ecosystem, and, degrades the viewing experience of legitimate users on account of network load caused by illegitimate access of content.

III. SUMMARY

[0006] Various embodiments of the present disclosure provide methods and systems for authenticating a content viewer while streaming content.

[0007] In an embodiment of the invention, a computer-implemented method for authenticating a content viewer while streaming content is disclosed. The computer-implemented method performed by a system includes receiving an enhanced first token from an electronic device of a content viewer. The enhanced first token includes at least a content address, a content repository server identifier (ID), and a first content viewer metadata. Further, the method includes generating an enhanced second token based, at least in part, on the enhanced first token. The enhanced second token includes at least the content address, the content repository server ID, the first content viewer metadata, and a time-to-live (TTL) value indicating a lifetime of the enhanced second token. Further, the method includes transmitting the enhanced second token to the electronic device.

[0008] In another embodiment of the invention, a system for authenticating a content viewer while streaming content is disclosed. The system includes memory and a processor. The memory stores instructions which are executed by the processor and cause the system to receive an enhanced first token from an electronic device of a content viewer. The enhanced first token includes at least a content address, a content repository server identifier (ID), and a first content viewer metadata. Further, the system is caused to generate an enhanced second token based, at least in part, on the enhanced first token. The enhanced second token includes at least the content address, the content repository server ID, the first content viewer metadata, and a time-to-live (TTL) value indicating a lifetime of the enhanced second token. Further, the system is caused to transmit the enhanced second token to the electronic device.

[0009] In yet another embodiment of the invention, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a system, cause the system to perform a method. The method includes receiving an enhanced first token from an electronic device of a content viewer. The enhanced first token includes at least a content address, a content repository server identifier (ID), and a first content viewer metadata. Further, the method includes generating an enhanced second token based, at least in part, on the enhanced first token. The enhanced second token includes at least the content address, the content repository server ID, the first content viewer metadata, and a time-to-live (TTL) value indicating a lifetime of the enhanced second token. Further, the method includes transmitting the enhanced second token to the electronic device.

IV. Description of the Drawings:

[0010] The advantages and features of the invention will become better understood with reference to the detailed description taken in conjunction with the accompanying drawings, wherein like elements are identified with like symbols, and in which:

[0011] FIG. 1 illustrates a representation for provisioning of content offered by a streaming content provider to a subscriber, in accordance with an embodiment of the invention;

[0012] FIG. 2 is a block diagram of a system configured to authenticate a content viewer while streaming content from content delivery networks (CDNs), in accordance with an embodiment of the invention;

[0013] FIG. 3 is a block diagram of a token analysis module, in accordance with an embodiment of the invention;

[0014] FIG. 4 shows a simplified representation of components of an enhanced long token, in accordance with an embodiment of the invention;

[0015] FIG. 5 depicts a sequence flow diagram showing a process flow for authenticating a content viewer while streaming content from a CDN, in accordance with an embodiment of the invention;

[0016] FIG. 6 shows a flow diagram of a method for authenticating a content viewer while streaming content from CDNs, in accordance with an embodiment of the invention;

[0017] FIG. 7 shows a flow diagram of a method for authenticating a content viewer while streaming content from any content repository server, in accordance with an embodiment of the invention; and

[0018] FIG. 8 is a simplified block diagram of a Content Delivery Network (CDN), in accordance with various embodiments of the invention.

[0019] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

V. Description of the Technology:

[0020] The best and other modes for carrying out the present invention are presented in terms of the embodiments, herein depicted in FIGS. 1 to 8. The embodiments are described herein for illustrative purposes and are subject to many variations. It is understood that various omissions and substitutions of equivalents are contemplated as circumstances may suggest or render expedient but are intended to cover the application or implementation without departing from the scope of the invention. Further, it is to be understood that the phraseology and terminology employed herein are for the purpose of the description and should not be regarded as limiting. Any heading utilized within this description is for convenience only and has no legal or limiting effect.

[0021] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification is not necessarily all refer to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.

[0022] The terms “a” and “an” as used herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced items.

OVERVIEW

[0023] Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for authenticating a content viewer while streaming content from any content repository server. It is noted that the content repository server is a Content Delivery Network (CDN).

[0024] Conventional authentication approaches have various drawbacks and limitations as described earlier. A few such drawbacks include increased latency leading to increased buffering at the content viewer’s end, increased computational requirements, at content provider’s end, bad user experience, and the like. To overcome such problems or limitations, the present disclosure describes a system that is configured to perform the below operations.

[0025] In an embodiment, the system is configured to receive an enhanced first token from an electronic device of a content viewer. The enhanced first token includes at least a content address, a content repository server identifier (ID), a first token ID, a token lifespan, and a first content viewer metadata. The first content viewer metadata further includes a content viewer ID, a device ID, an IP address associated with the electronic device of the content viewer, type of network access, type of electronic device, content viewer account credentials, and location information. In an embodiment, after receiving the enhanced first token, the same is authenticated. The enhanced first token is authenticated based, at least in part, on performing a hash-message authentication code (HMAC) verification on the enhanced first token. The authentication further includes comparing the first token ID with a plurality of prior token IDs accessed from a token ID database associated with the system to determine if the first token ID is unique. Upon determining that the first token ID is unique, authenticate the enhanced first token. The authentication further includes comparing the first token ID with a plurality of blacklisted token IDs accessed from the token ID database to determine if the first token ID is blacklisted. Upon determining that the first token ID is not blacklisted, authenticating the enhanced first token. The authentication further includes determining if the enhanced first token is active based, at least in part, on the token lifespan. Upon determining that the enhanced first token is active, authenticating the enhanced first token.

[0026] In another embodiment, the system is further configured to generate an enhanced second token based, at least in part, on the enhanced first token. The enhanced second token includes at least the content address, the content repository server ID, the first content viewer metadata, and the time-to-live (TTL) value indicating a lifetime of the enhanced second token. In an example, the TTL value is determined based, at least in part, on a content type requested by the content viewer and user concurrency. Herein, the content type is determined based, at least in part, on the content address. In another embodiment, the system is further configured to receive a token refresh request from the electronic device. The token request is generated based, at least in part, on the TTL value. The token refresh request includes a second content viewer metadata. In another embodiment, the system is configured to transmit the enhanced second token to the electronic device. It is noted that the content address is a content playback Uniform Resource Locator (URL).

[0027] In another embodiment, the system is further configured to determine a dissimilarity value for the token refresh request based, at least in part, on the first content viewer metadata and the second content viewer metadata. Then, generate a new enhanced second token upon determining that the dissimilarity value less than a first predetermined threshold. Further, the new enhanced second token is transmitted to the electronic device. In another embodiment, the system is configured to generate a second token sharing flag upon determining that the dissimilarity value greater than a first predetermined threshold, the second token sharing flag indicating an authentication failure due to second token sharing. The content viewer ID is blacklisted in a database associated with the system and the second token sharing flag is transmitted to the electronic device. Herein, the first predetermined threshold is determined based, at least in part, on an account type of the content viewer, wherein the account type is determined based, at least in part, on the content viewer ID. Further, the system is configured to determine a number of consecutive token refresh requests associated with the same content viewer ID within a preset time interval. Then, determine a number of electronic devices generating the consecutive token refresh requests associated with the same content viewer ID. Further, generate a new enhanced second token upon determining that the number of consecutive token refresh requests and the number of electronic devices is less than a second predetermined threshold. Thereafter, transmit the new enhanced second token to the electronic device.

[0028] In an embodiment, the server system is further configured to determine a number of consecutive token refresh requests associated with the same content viewer ID within a preset time interval. Then, determine a number of electronic devices generating the consecutive token refresh requests associated with the same content viewer ID. Further, generate a concurrency check flag upon determining that the number of consecutive token refresh requests and the number of electronic devices greater than a second predetermined threshold, the concurrency check flag indicating authentication failure due to concurrency bypass. Furthermore, the content viewer ID is blacklisted in a database associated with the system and the concurrency check flag is transmitted to the electronic device. Herein, the second predetermined threshold is determined based, at least in part, on content type, content viewer profile, account type, and content viewer behavior.

[0029] Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure provides an enhanced second token with a TTL value which ensures that the enhanced second token is refreshed periodically, thereby ensuring that an illegitimate content viewer is unable to stream any content (i.e., more than the duration of a compromised second token). Further, by employing the approaches of the present disclosure, the overall latency can be improved while ensuring proper performance and no processing resources are wasted. To that end, the approaches provided by the present disclosure are computationally efficient. Further, a good user experience can be provided to the user by reducing the latency thereby, reducing any buffering or stuttering in the content while streaming.

[0030] FIG. 1 illustrates a representation 100 for provisioning of content offered by a streaming content provider to a subscriber 102, in accordance with an embodiment of the invention.

[0031] The term ‘subscriber’ as used herein implies a content viewer or a user, who has subscribed, i.e., registered to a subscription plan (whether a free subscription plan or a paid subscription plan) from among a plurality of subscription plans for accessing content offered by a content provider. In at least some embodiments, the term ‘subscriber’ may also include one or more users in addition to the individual subscriber, such as for example family members of the subscriber. To that effect, the term ‘subscriber’ as used herein may include one or more users. Further, it is noted that the term ‘content viewer’ is used hereinafter interchangeably to refer to the ‘subscriber’.

[0032] The term ‘streaming content provider’ as used herein refers to an entity that holds digital rights associated with digital content present within digital video content libraries, offers the content on a subscription basis by using a digital platform and over-the-top (OTT) media services, i.e., content is streamed over the Internet to the electronic devices of the subscribers. A streaming content provider is hereinafter referred to as a ‘content provider’ for ease of description. The content offered by the content provider may be embodied as streaming video content such as live streaming content or on-demand video streaming content. It is noted that though the content offered by the content provider is explained with reference to video content, the term ‘content’ as used hereinafter may not be limited to only video content. Indeed, the term ‘content’ may refer to any media content including but not limited to ‘video content’, ‘audio content’, ‘gaming content’, ‘textual content’, and any combination of such content offered in an interactive or non-interactive form. Accordingly, the term ‘content’ is also interchangeably referred to hereinafter as ‘media content’ for the purposes of description. Individuals wishing to view/access the media content may subscribe to at least one type of subscription offered by the content provider.

[0033] The provisioning of media content to a subscriber (such as subscriber 102) in response to the subscriber’s request for accessing such content is explained next with reference to an illustrative example in FIG. 1. The representation 100 depicts the subscriber 102 controlling an electronic device 104 for viewing/accessing media content offered by the content provider. The electronic device 104 is depicted to be a smartphone for illustration purposes only. It is noted that the subscriber 102 may use one or more electronic devices, such as a television (TV), a laptop, a desktop, or a personal computer to view the media content provided by the content provider.

[0034] In one illustrative example, the subscriber 102 may access a user interface (UI) of a mobile application or a Web application associated with a content provider by using the electronic device 104. It is understood that the electronic device 104 may be in operative communication with a communication network, such as the Internet, enabled by a network provider, also known as the Internet Service Provider (ISP). One example ISP network is depicted as an ISP network 170 in the representation 100. The electronic device 104 may connect to the ISP network 170 using a wired network, a wireless network, or a combination of wired and wireless networks. Some non-limiting examples of wired networks may include the Ethernet, the Local Area Network (LAN), a fiber-optic network, and the like. Some non-limiting examples of wireless networks may include Wireless LAN (WLAN), cellular networks, Bluetooth or ZigBee networks, and the like.

[0035] In an illustrative example, the subscriber 102 may create an account and, as part of the account creation process, select a subscription type from among two or more subscription types offered by the content provider. For example, the subscriber 102 may choose to subscribe to standard/regular content, or, the subscriber 102 may choose to subscribe to premium content offered by the content provider. Some subscription types may provide an option to concurrently view the same media content on different devices or different media content on different devices. For example, subscribing to a premium type of subscription may enable the subscriber 102 to view media content such as audio content and a live soccer match concurrently on two different electronic devices associated with the subscriber 102 using the same account credentials. More specifically, the subscribers of the premium content may concurrently have two active sessions on different electronic devices (for example, smartphones and Television). Once the subscriber 102 has selected the type of subscription and the account is created, the subscriber 102 may enter account credentials to login into the account and access the user interface (UI) associated with the content provider over the ISP network 170. In an illustrative example, the UI may include a plurality of content titles corresponding to the media content offered by the content provider to its subscribers. The subscriber 102 may select a content title related to media content from among a content catalog including various content titles displayed on the display screen of the electronic device 104. The selection of a content title may trigger a request for a playback Uniform Resource Locator (URL). The request for the playback URL is sent from the electronic device 104 via the ISP network 170 to the digital platform server 120 associated with the content provider. The transmission of the request for the playback URL from the electronic device 104 to the digital platform server 120 is exemplarily depicted using a communication link 106.

[0036] In at least some embodiments, the digital platform server 120 is configured to authenticate the subscriber 102 and determine if the subscriber 102 is entitled to view the requested content. To this effect, the digital platform server 120 may be in operative communication with one or more remote servers, such as an authentication server and an entitlement server, which may be associated with at least one of a Content Management System (CMS) and a User Management System (UMS). The authentication server and the entitlement server are not shown in FIG. 1. The authentication server (not shown) may facilitate the authentication of subscriber account credentials using standard authentication mechanisms, which are not explained herein. The entitlement server (not shown) may facilitate the determination of the subscriber’s subscription type (i.e., whether the subscriber 102 has subscribed to regular or premium content) and status (i.e., whether the subscription is still active or is expired), which in turn may determine whether the subscriber 102 is entitled to view/access the requested content or not.

[0037] If the authentication and the entitlement check are successful, the digital platform server 120 is configured to provide a token, also referred to herein as a ‘first token’, to the electronic device 104. It is noted that the term ‘short token’ is used interchangeably hereinafter with ‘first token’. The transmission of the short token from the digital platform server 120 to the electronic device 104 is exemplarily depicted using a communication link 108. The short token includes the playback URL, which identifies a content delivery network (CDN) from among a plurality of CDNs 180a – 180c, where the media content is cached. In a non-limiting example, the plurality of CDNs 180a-180c includes at least a public CDN, a private CDN, a telecommunication CDN (i.e., a telco-CDN), internet service provider (ISP) CDN, and the like. The electronic device 104 forwards the short token to a CDN, say CDN 180a, which performs an HMAC based token validation and provides the electronic device 104 with a second token. The second token is a tokenized URL manifest which includes the URLs corresponding to different renditions of the same content (with different resolutions and bitrates) within a CDN. In a non-limiting example, the URLs may correspond to a CDN point of presence (PoP), i.e., a CDN content store from where the content can be streamed. It noted that the second token is referred interchangeably hereinafter to as a ‘long token’. A CDN point of presence (PoP), such as a CDN PoP 190a associated with the CDN 180a, may be chosen based on one or more criteria, such as the proximity of the PoP to the subscriber 102 within the subscriber’s home network/peering network, the health of the CDN PoP 190a, the availability of requested content at the PoP, and the like. The transmission of the short token from the electronic device 104 to the CDN 180a is exemplarily depicted using a communication link 110, and, the transmission of the long token from the CDN 180a to the electronic device 104 is exemplarily depicted using a communication link 112. The electronic device 104 uses the URL of the CDN PoP 190a in the long token to request the stream of the requested media content from the CDN PoP 190a. The transmission of the media content request from the electronic device 104 to the CDN PoP 190a and the subsequent streaming of the media content from the CDN PoP 190a to the electronic device 104 may be performed via the ISP network 170 and is not shown in FIG. 1.

[0038] In some scenarios, an illegitimate/non-entitled user may share the long token provided by the CDN 180a with other illegitimate users, who may then stream the media content from the CDN PoP 190a without subscribing to the streaming content services offered by the content provider. The CDN PoP 190a, which receives the URL from multiple illegitimate users may not be equipped to check whether the request is from a legitimate subscriber or not, without verifying each content request with the digital platform server 120. The digital platform server 120 may also not be able to handle the volume of a large number of verification checks received from multiple CDN PoPs due to the various reasons explained earlier.

[0039] To prevent long token sharing, some CDNs may generate a short-lived long token, which may cause the streaming of content to be blocked once the long token expires. The content provider’s application in a legitimate subscriber’s electronic device may request the CDN 180a to refresh the long token, automatically, to continue accessing the media content in a seamless manner. However, the long tokens may expire on unauthorized user’s devices as the applications used for illegally sharing the long tokens would not make any request for refreshing the long tokens to the CDN 180a as they are unaware of the long token expiry. To circumvent the long token expiry issue, some illegitimate users have attempted to learn the lifespan of the long token by making several trial-and-error attempts. Once learned, the applications on the illegitimate users’ devices are programmed to request for refreshing the long tokens to the CDN 180a. As the CDN 180a, conventionally, performed only a basic token validation, the requests for long token refresh were treated as legitimate requests from legitimate subscribers, and accordingly, the illegitimate users were able to refresh the long tokens and continue accessing the media content illegally. Alternatively, an illegitimate user may use a legitimate content provider’s application to periodically refresh long tokens and share the refreshed long tokens at regular intervals with illegal applications, which may then access the CDN 190a for illegally obtaining the streaming content.

[0040] Like illegitimate long token sharing, in some scenarios, illegitimate users may manipulate the type of subscription to make multiple short token requests for streaming content. In one illustrative example, a subscriber 102 on account of having subscribed to a premium subscription, which entitles the subscriber 102 to watch two or more different media contents on two or more different devices concurrently, may request multiple short tokens from the digital platform server 120. On receiving the short tokens, the subscriber’s electronic devices may proceed to receive long tokens from the CDNs and thereafter access the requested media content from the CDN PoPs, such as the CDN PoP 190a. Typically a heartbeat signal, indicative of the subscriber 102 watching media content on the electronic device 104, is received from the subscriber’s electronic device 104 at the digital platform server 120. The heartbeat signal is a steady stream of data packets shared from the electronic device 104 to the digital platform server 120. In an example, the payload of the data packets includes information pertaining to all the interactions performed by the user on their electronic device 104 while operating the content provider’s application, transactions performed on the application, and temporary application cache. Upon receiving the heartbeat signal, the digital platform server 120 determines if the subscriber 102 is watching two different media contents on two different electronic devices as allowed by the subscriber’s subscription. If the same is allowed or permitted by the subscriber’s subscription, then content request from the subscriber 102 is authorized and access to content for a respective electronic device 104 is maintained. In various scenarios, the heartbeat signal may not reach the digital platform server 120 due to reasons such as the connection being broken, the content provider’s application being illegitimately modified or the use of any other special application, dropped packets, delay in processing the heartbeat signal, ingestion loss or incorrect ingestion at the server’s end, and the like. Such scenarios may lead the digital platform server 120 to determine that no content is being accessed on the corresponding electronic device 104. A fresh request for a short token for another media content may then be generated by the illegitimate user, in effect, increasing the number of media content being concurrently accessed. Using a fresh token, the illegitimate user’s electronic device may proceed to receive the long token from the CDN and thereafter access the requested media content from the CDN PoPs.

[0041] The representation 100 depicts a system 150 in operative communication with at least one CDN, such as the CDN 180a. The system 150 is configured to serve as a security layer for authenticating a content viewer while streaming content from the associated CDN. More specifically, the system 150 is configured to perform a long token sharing check and a concurrency bypass check to prevent illegitimate access of the streaming content from the CDNs. The system 150 is explained in further detail with reference to FIG. 2.

[0042] FIG. 2 is a block diagram of the system 150 of FIG. 1 configured to authenticate a content viewer while streaming content from CDNs, in accordance with an embodiment of the invention. The system 150 is configured to perform a security check of every long token request (via a short token) and/or of every long token refresh request received at the CDN for a possible presence of illegitimate activity. The illegal requests are blocked and illegitimate access to the media content is restricted for such illegal requests. The deployment of a security layer, in the form of the system 150, near a content repository server such as a CDN (see, CDN 180a), provides several advantages. For example, the security layer can stop illegitimate content access from a point in a network, from which the content is being accessed. Further, the security layer enables the CDN 180a to perform its routine security checks without having to add custom layers for each content provider’s delivery architecture, and yet provide a high level of security in terms of content access. It is noted that the security layer provided by the system 150 is compatible with all types of CDNs (such as public CDN, private CDN, telco-CDN, and the like) individually or a combination thereof. Furthermore, the security layer avoids the need for the CDN 180a to check or confirm the authenticity of each subscriber’s content access request with the content provider’s platform, thereby enabling scaling of the security checks without burdening the CDN 180a or the content provider’s platform.

[0043] As explained with reference to FIG. 1, the system 150 is configured to be in operative communication with a CDN, such as the CDN 180a. In some embodiments, the system 150 may also be included within the CDN, whereas in some embodiments the system 150 may be implemented externally with respect to the CDN. The system 150 is depicted to include a processing module 202, a memory module 204, an input/output (I/O) module 206, a communication module 208, and a storage module 210. It is noted that although the system 150 is depicted to include the processing module 202, the memory module 204, the I/O module 206, the communication module 208, and the storage module 210, in some embodiments, the system 150 may include more or fewer components than those depicted herein. The various components of the system 150 may be implemented using hardware, software, firmware, or any combination thereof. It is also noted that one or more components of the system 150 may be implemented in a single server or a plurality of servers, which are remotely placed from each other.

[0044] In one embodiment, the processing module 202 may be embodied as a multi-core processor, a single-core processor, or a combination of one or more multi-core processors and one or more single-core processors. For example, the processing module 202 may be embodied as one or more of various processing devices, such as a coprocessor, a microprocessor, a controller, a digital signal processor (DSP), a processing circuitry with or without an accompanying DSP, or various other processing devices including integrated circuits such as, for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microcontroller unit (MCU), a hardware accelerator, a special-purpose computer chip, or the like. In one embodiment, the memory module 204 is capable of storing machine-executable instructions, referred to herein as platform instructions 216. Further, the processing module 202 is capable of executing the platform instructions 216. In an embodiment, the processing module 202 may be configured to execute hard-coded functionality. In an embodiment, the processing module 202 is embodied as an executor of software instructions, wherein the instructions may specifically configure the processing module 202 to perform the algorithms and/or operations described herein when the instructions are executed.

[0045] The processing module 202 is depicted to include a token analysis module 212 and an action module 214. In some embodiments, the token analysis module 212 and the action module 214 may be associated with respective sets of processors and memories for executing their functionalities. The processing module 202 and the memory module 204, in at least some embodiments, are configured to be collective embodiments of the processors and memories included in the respective components.

[0046] The memory module 204 may be embodied as one or more non-volatile memory devices, one or more volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. For example, the memory module 204 may be embodied as semiconductor memories, such as flash memory, mask ROM, PROM (programmable ROM), EPROM (erasable PROM), RAM (random access memory), etc., and the like. In at least some embodiments, the memory module 204 may include logic, such as a logic for parsing contents of a received short/long token, logic for updating a token history database with the parsed content, logic for performing comparative checks between parameters associated with a long token refresh request and the original long token, and the like. The logic and/or code stored in the memory module 204 may be executed by the token analysis module 212 and the action module 214 to perform their respective functionalities.

[0047] In an embodiment, the I/O module 206 may include mechanisms configured to receive inputs from and provide outputs to an operator of the system 150. The term ‘operator of the system 150’ as used herein may refer to one or more individuals or administrators, whether directly or indirectly, associated with managing CDN on behalf of the content provider. To enable the reception of inputs and provide outputs to the system 150, the I/O module 206 may include at least one input interface and/or at least one output interface. Examples of the input interface may include, but are not limited to, a keyboard, a mouse, a joystick, a keypad, a touch screen, soft keys, a microphone, and the like. Examples of the output interface may include, but are not limited to, a display such as a light-emitting diode display, a thin-film transistor (TFT) display, a liquid crystal display, an active-matrix organic light-emitting diode (AMOLED) display, a microphone, a speaker, a ringer, and the like.

[0048] In an example embodiment, the processing module 202 of the system 150 may include I/O circuitry (not shown in FIG. 1) configured to control at least some functions of one or more elements of the I/O module 206, such as, for example, a speaker, a microphone, a display, and/or the like. The processing module 202 of the system 150 and/or the I/O circuitry may be configured to control one or more functions of the one or more elements of the I/O module 206 through computer program instructions, for example, software and/or firmware, stored on a memory, for example, the memory module 204, and/or the like, accessible to the processing module 202 of the system 150.

[0049] The communication module 208 is configured to facilitate communication between the system 150 and one or more remote entities over a communication network. For example, the communication module 208 is capable of facilitating communication with electronic devices of the subscribers, with one or more CDNs such as the plurality of CDNs 180a- 180c, with the digital platform server 120, with edge servers associated with CDNs, with content ingestion servers, and the like.

[0050] The storage module 210 is any computer-operated hardware suitable for storing and/or retrieving data. In one embodiment, the storage module 210 is configured to store information extracted from the short and long tokens in a token history database as will be explained in further detail later. In addition to the information extracted from the tokens, the storage module 210 may include a database of subscriber profiles including subscriber access details (e.g., type of subscriber devices, IP addresses, subscriber location, subscriber viewing preferences, etc.), blacklisted tokens, blacklisted subscriber accounts, a CDN-content map, hostnames for playback URLs, and the like.

[0051] The storage module 210 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. In some embodiments, the storage module 210 may include a storage area network (SAN) and/or a network attached storage (NAS) system. In one embodiment, the storage module 210 may correspond to a distributed storage system, wherein individual databases are configured to store custom information, such as subscriber access details, blacklisted subscriber information, etc. In some embodiments, the storage module 210 is integrated within the system 150. For example, the system 150 may include one or more hard disk drives as the storage module 210. In other embodiments, the storage module 210 is external to the system 150 and may be accessed by the system 150 using a storage interface (not shown in FIG. 2). The storage interface is any component capable of providing the processing module 202 with access to the storage module 210. The storage interface may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processing module 202 with access to the storage module 210.

[0052] As explained with reference to FIG. 1, the subscriber 102 selects a content title related to streaming media content (e.g., a web series) from among the plurality of content titles displayed on the display screen of the electronic device 104. The selection of the content title may trigger a request for a content address for the selected content. In a non-limiting example, the content address is a content playback Uniform Resource Locator (URL). The digital platform server 120 (shown in FIG. 1) is configured to perform subscriber authentication and entitlement checks in response to the receipt of the request for content playback URL. After the successful completion of the subscriber authentication and the entitlement checks, the digital platform server 120 identifies an optimal CDN from among the plurality of CDNs for serving the selected content. Further, the digital platform server 120 generates a short token including the playback URL identifying the CDN caching the requested media content.

[0053] In at least one embodiment, the digital platform server 120 is configured to embed additional information in the short token, which traditionally only included the playback URL, a token identifier, and other token related information (such as a short token ID, i.e., a first token ID, a token lifespan, and the like.), which enabled the CDN to perform token validation. In one illustrative example, the digital platform server 120 may embed additional information in the short token such as (1) information related to the subscriber, such as the subscriber’s account credentials, the number of active electronic devices associated with the subscriber, the type of electronic devices and the device identifiers, the subscriber’s IP address, the subscriber’s location, and the like, and (2) information related to the type of request, the content title, the genre of the content title, etc. Such additional information embedded in the short token is hereinafter referred to as ‘first content viewer metadata’.

[0054] Accordingly, the first token is enhanced by the addition of the first content viewer metadata over the conventional contents of the first token. The enhanced first token is provided by the digital platform server 120 to the subscriber’s electronic device 104, which forwards the enhanced first token to a CDN identified in the playback URL. It noted that the ‘enhanced first token’ is referred interchangeably hereinafter to as an ‘enhanced short token’. In at least some embodiments, the enhanced short token may be embodied as a JSON Web Token (JWT) and may use a hash-message authentication code (HMAC) to protect the contents of the enhanced short token. Further, in some embodiments, the contents of the enhanced short token may be encrypted and/or compressed prior to embedding the playback URL and the first content viewer metadata information in the JWT with HMAC protection.

[0055] In a non-limiting example, a portion of an enhanced short token is provided below:
master8ec2145b1b.mpd?ttl=300&type=paid&CVID=encrypted(CVID)&DID=encrypted(DID)&acl=/videos/ABC/1260049853*&cc=IN&asn=55836&ABC=st=1612943340~exp=1612943940~hmac=f6763365bc99c8da144ccab9cab2d05613ec200afbe3fa84af8827f936513ece

[0056] Returning to the present example, the portion of the enhanced short token includes content viewer ID (CVID), device ID (DID), content viewer type, country code, autonomous system number (ASN) code, expired (indicating condition for hard expiry of the token) and the like. In a non-limiting example, the enhanced short token may also include a TTL value which is determined similar to the TTL value associated with the enhanced long token. In a non-limiting example, content viewer type (depicted as ‘paid’ in the above example) may instead correspond to various tiers of subscriptions offered by the content provider.

[0057] The system 150 on account of being in operative communication with the CDN (such as CDN 180a) is configured to receive the enhanced short token. More specifically, the communication module 208 of the system 150 is configured to receive the enhanced short token and forward the enhanced short token to the token analysis module 212. The processing of token information performed by the token analysis module 212 is explained next with reference to FIG. 3.

[0058] Referring now to FIG. 3, a block diagram 300 of a token analysis module 212 is shown, in accordance with an embodiment of the invention. The token analysis module 212 is depicted to include a token verification module 302, a parsing module 304, and a comparator module 306.

[0059] As explained with reference to FIG. 2, an enhanced short token, i.e., a short token including the content address, the content repository server identifier (ID), and the first content viewer metadata, may be received by the token analysis module 212 from the communication module 208. The token verification module 302 in the token analysis module 212 may be configured to perform verification checks on tokens received at the CDN, such as the CDN 180a. For example, the token verification module 302 may perform a check of the enhanced short token, which is provided by the subscriber’s electronic device 104 to request a long token from the CDN 180a. Similarly, the token verification module 302 may also perform a check of long token refresh requests (which may also be received in form of a token) received from the subscriber’s electronic device 104.

[0060] In one illustrative example, the token verification module 302 may check if the enhanced short token is authentic based on the HMAC verification. The authenticity of the enhanced short token may confirm that the JWT is not manipulated by an illegitimate user. Further, the token verification module 302 may check if a token identifier of the enhanced short token is unique or not by comparing the token identifier with token IDs stored in a token ID database 320 in the storage module 210 of the system 150. Furthermore, the token verification module 302 may check whether the enhanced short token is active, i.e., the token has not expired, based on a token lifespan associated with the enhanced short token. The token verification module 302 may also check whether the enhanced short token corresponds to a blacklisted token. To this effect, the token verification module 302 may perform a check of blacklisted entries stored in the token ID database 320 of the storage module 210. After the successful clearance of all checks, the token verification module 302 may be configured to decrypt and/or decompress the playback URL and metadata information included in the enhanced short token and provide the information to the parsing module 304.

[0061] In particular, token verification module 302 performs multiple authentications or verification processes on the enhanced short token before proceeding further. At first, the HMAC verification is performed on the enhanced short token. Then, the short token ID (i.e., the first token ID) is compared with a plurality of prior token IDs accessed from the token ID database 320 associated with the system 150 to determine if the short token ID is unique. Upon determining that the short token ID is unique, the enhanced short token is authenticated otherwise, the authentication fails. Further, the short token ID is compared with a plurality of blacklisted token IDs accessed from the token ID database to determine if the short token ID is blacklisted. Upon determining that the short token ID is not blacklisted, the enhanced short token is authenticated otherwise, the authentication fails. Furthermore, the token verification module 302 determines if the enhanced short token is active based, at least in part, on the token lifespan. Upon determining that the enhanced short token is active, the enhanced short token is authenticated otherwise, the authentication fails.

[0062] In at least one embodiment, the parsing module 304 is configured to parse the contents of tokens/requests received from the subscriber’s electronic device 104. For example, the parsing module 304 is configured to parse the contents of the enhanced short tokens and long token refresh requests as will be explained hereinafter.

[0063] In one illustrative example, the parsing module 304 is configured to extract the first content viewer metadata from among the contents of the enhanced short token. The parsing module 304 is further configured to update the records in the storage module 210. In at least one embodiment, the storage module 210 may maintain a database, shown as a token history database 330, which is configured to store all information received in the metadata. For example, details related to the subscribers’ account, device/IP/location details, the type of requested content, content title, and the like, may be recorded as parameters in separate entries as part of a single record associated with a receipt of an enhanced short token. The storage module 210 may also be configured to trigger an application programming interface (API) call the comparator module 306 on completion of the update to the token history database 330. The comparator module 306 is configured to perform a check to determine the presence of any anomaly in the information contained in the tokens/requests received from the electronic devices of the subscribers. The detection of the anomaly by the comparator module 306 and the subsequent action performed in response to the detection of the anomaly is explained in further detail later.

[0064] If no anomaly is detected by the comparator module 306, then the comparator module 306 may provide a signal, indicative of the clear status to the parsing module 304. The parsing module 304 on receiving the signal may forward the extracted information, i.e., the metadata and the URL, to the CDN 180a for the generation of the long token. If an anomaly is detected by the comparator module 306, then a flag signal is issued to the parsing module 304, which may provide such information to the action module 214 (shown in FIG. 2). The action module 214, in conjunction with the CDN 180a, may be configured to request additional authentication from the subscriber, block access to the requested content or temporarily suspend the subscriber’s account. In case, when no anomaly is detected in the enhanced short token, the CDN 180a is configured to receive extracted playback URL and the metadata including the subscriber and content related information from the parsing module 304.

[0065] In at least some embodiments, the parsing module 304 may also provide a time-to-live (TTL) value to be associated with the enhanced second token that is to be generated by the CDN 180a based on the enhanced short token received from the subscriber 102. The TTL value is indicative of a time for which the enhanced second token is going to be active. In other words, the TTL value indicates the lifetime of the enhanced second token. It noted that the enhanced second token is referred interchangeably hereinafter to as an ‘enhanced long token’. Before the time period indicated by the TTL value expires, the subscriber’s electronic device 104 may have to request a refresh of the long token from the CDN 180a. In one illustrative example, the enhanced long token is configured to only provide access to a video segment among a plurality of video segments related to the requested media content and as such, the enhanced long token has to be refreshed after a predefined time (as defined in the TTL value) to retrieve one or more subsequent segments related to the requested media content. For example, an enhanced long token is configured to last only 5 minutes, i.e., 300 seconds of playtime of the media content, i.e., a TTL value associated with the enhanced long token is 5 minutes, whereas the entire media content is of 30 minutes duration. As such, the enhanced long token has to be refreshed after a predefined time (e.g., 4 minutes after receiving the enhanced long token) before the expiry of the enhanced long token. The predefined time may correspond to a time instant (for example, 1 minute) prior to the expiry time enhanced long token. The refreshing of the enhanced long token is explained in further detail later.

[0066] In a non-limiting example, an enhanced long token is provided below:
hdntl=exp=1613029841~acl=/videos/ABC/1260049853*~data=CVID=encrypted(CVID)&DID=
encrypted(DID)&acl=/videos/ABC/1260049853*&cc=IN&asn=55836&hdntl~hmac=f904fa28
9d76088b37ab8d1 fca2c65b3e10090a293457

[0067] Returning to the present example, the portion of the enhanced short token includes at least a content viewer ID (CVID), device ID (DID), country code, ASN code, and the like.

[0068] Thus, the CDN 180a is configured to receive extracted playback URL, the first content viewer metadata, and the TTL value from the parsing module 304. The CDN 180a is configured to add the CDN PoP information, from which the requested content is to be streamed, to the received information from the parsing module 304 to configure an enhanced long token. A simplified representation of the components of the enhanced long token is shown in FIG. 4.

[0069] Referring now to FIG. 4, a simplified representation of components of an enhanced long token 400 is shown, in accordance with an example embodiment of the invention. The enhanced long token 400 is exemplarily depicted to include a long token identifier 402 (i.e., second token identifier), CDN PoP portion 404, a subscriber information portion 406 (i.e., the first content viewer metadata), a content information portion 408, and a TTL value 410.

[0070] The long token identifier 402 includes a token identification number, which uniquely identifies the enhanced long token 400. The CDN PoP portion 404 includes URL information related to the CDN PoP (such as the CDN PoP 190a shown in FIG. 1) from which the requested content is to be streamed. The subscriber information portion 406 includes information related to the subscriber such as the subscriber’s account credentials, the type of electronic device 104 (for example, mobile phone, TV, or tablet device) used by the subscriber 102 for requesting access to the media content, device identifier (ID), a type of access method (web interface or mobile application), type of network access (cellular or Wi-Fi), an IP address, location information (for example, State, City, region), and the like. The content information portion 408 includes information related to the requested content such as a type of content (i.e., video, audio, review content, etc.), the content title, the genre of the content, the segment identifier, the segment length, the total number of segments, and the like. It is noted that the information included in the subscriber information portion 406 and the content information portion 408 is obtained from the metadata extracted from the enhanced short token by the parsing module 304 (shown in FIG. 3). Further, as explained with reference to FIG. 3, the TTL value (shown as TTL value 410 in FIG. 4) defines a time period for which the enhanced long token 400 will stay active, and before the time period elapses, a subscriber’s device has to send a request to refresh the enhanced long token. If the time period elapses prior to the long token refresh request, the subscriber’s device 104 may have to make a fresh request for a new enhanced long token and this may adversely affect the subscriber’s 102 viewing experience. In at least some embodiments, the TTL value 410 may be configured to be a fixed value for all types of content.
[0071] In an alternative embodiment, the TTL value 410 may be dynamically changed based on various factors, such as content type, user concurrency, content viewer profile (i.e., subscriber profile), etc. In other words, the TTL value is fine-tuned, i.e., either increased or decreased based on real-time conditions based on different factors. In one example, if the content type is live content, then the TTL value can be high since a low TTL value might lead to increased latency and poor user experience. On the other hand, if the content is video-on-demand content, then the TLL value can be lower without impacting the user experience. In another example, if the user concurrency is high based on the content viewer’s subscription plan, then the TTL value can be high when compared with low user concurrency. In a non-limiting example, behavioral aspects of the content viewer may also be determined based on the content viewer profile using various machine learning models to fine-tune the TTL value.

[0072] It is noted that contents of the enhanced long token 400 may not be limited to the example portions mentioned above, and, indeed the enhanced long token 400 may be configured to include a variety of information related to the subscription of the subscriber 102 and the media content access request provided by the subscriber 102. The long token identifier 402, the CDN PoP portion 404, the subscriber information portion 406, the content information portion 408, and the TTL value 410 to be integrated into the enhanced long token 400, may be subjected to processing in the form of encryption, encoding and/or compression prior to the integration of such information in the enhanced long token 400.

[0073] Referring back to FIG. 3, the enhanced long token, such as the enhanced long token 400 shown in FIG. 4, may be generated by a CDN, such as the CDN 180a. The CDN 180a may then provide the enhanced long token to the subscriber’s device (such as the electronic device 104 shown in FIG. 1) as a response to the receipt of the enhanced short token from the subscriber’s electronic device 104. The subscriber’s electronic device 104 shown in FIG. 1, may use the CDN PoP 190a related information in the CDN PoP portion of the enhanced long token to obtain the URL and request the CDN PoP 190a to stream the requested content to the subscriber’s electronic device 104.

[0074] As explained with reference to FIG. 1, in some scenarios, a subscriber 102 or a user may share the enhanced long token with a plurality of illegitimate users, thereby allowing the illegitimate users to watch the content without subscribing to the content provider’s subscription service. In the conventional scenario, once the long token is shared with an illegitimate user, the illegitimate user accesses the CDN PoP 190a, which is not configured to perform any verification check, and streams the requested content to the illegitimate user’s electronic device 104.

[0075] As per the present invention, the enhanced long token is associated with a TTL value, which is deliberately configured to last for a short time period. Before the TTL expires, each illegitimate user (i.e., unauthorized user) would have to refresh the long token. A request for refreshing the long token sent from the device of the illegitimate user may include information related to the device ID, device type, IP address, location, etc. of the illegitimate user. Such a request for a long token refresh may be received by the system 150 on behalf of the CDN 180a. More specifically, the communication module 208 (shown in FIG. 2) may receive the request for refreshing the long token and forward the request to the token analysis module 212. In one example, the token verification module 302 of the token analysis module 212 may perform appropriate verification checks on long token refresh requests, such as for example, checking the authenticity of the precedents of the long token, i.e., the enhanced long token originally issued to the user, in relation to which the refresh request is made. In another example, the token verification module 302 may perform appropriate verification checks on any new user that requests to join a content stream using the long token (for both shared and non-shared tokens). To that end, if a user requests access using a long token, the token verification module 302 checks if any other user is watching some content using the same long token. If so, the content request is directly rejected. Once the verification check is complete, the decrypted/decoded/decompressed content of the long token refresh request is provided to the parsing module 304.

[0076] The parsing module 304 may extract the first content viewer metadata related to the subscriber’s information and the content information from the long token refresh request and provide the extracted information to the comparator module 306. The comparator module 306 may compare the extracted content viewer metadata with corresponding content viewer metadata from the enhanced long token initially issued to the user and in relation to which the refresh request is made. In at least some embodiments, individual parameters, such as the device ID, the location, device type, etc., can be compared based on the extracted content and the relevant record in the token history database 330 to generate a dissimilarity value. If the dissimilarity value exceeds a first predetermined threshold, then the long token refresh request is considered to have failed a long token sharing check and, accordingly the long token refresh request for refreshing the originally issued enhanced long token is denied, thereby restricting any further access to the media content. In one example embodiment, the first predetermined threshold may be a preset value based on a type of subscription account (for example, a standard account or a premium account).

[0077] In particular, it is noted that the token refresh request from the electronic device 104 of the subscriber 102 includes a second content viewer metadata. The second content viewer metadata includes similar information as the first content viewer metadata, i.e., it will include a content viewer ID, a device ID, an IP address associated with the electronic device 104 of the content viewer, type of network access, type of electronic device, content viewer account credentials, and location information of the device transmitting the token refresh request. The comparator module 306 determines the dissimilarity value for the token refresh request based, at least in part, on comparing the first content viewer metadata with the second content viewer metadata. It is understood that if the same user generates the token refresh request upon expiration of the enhanced long token due to the TTL value, then there will be no dissimilarity between the first content viewer metadata with the second content viewer metadata, thus dissimilarity value will be low and vice-versa. To that end, if the dissimilarity value is less than the first predetermined threshold, a new enhanced long token is generated and transmitted to the electronic device 104. Otherwise, a long token sharing flag is generated and transmitted to the electronic device 104. The long token sharing flag indicates that authentication failure due to long token sharing has occurred. Further, the content viewer ID may also be blacklisted in a database associated with the system 150.

[0078] In one illustrative example, a subscriber ‘A’ may have requested playback of an action movie using a smartphone associated with a device identifier ‘AWZ1025U’ and an IP address (192.158. 1.38). As such, the subscription of the subscriber ‘A’ may have been authenticated and as such he would have received an enhanced long token T1 to initiate playback of the action movie. In addition, the system 150 may have cached a copy of the information included in the token T1 in the token history database 330. For example, a record may be created corresponding to the current content access request by the subscriber ‘A’ in the token history database 330 in the storage module 210. The record may include entries related to various parameters, such as type of access, device type, device identifier, IP address, location, type of network access, browser information, type of content, content title, etc. The token T1 may be associated with a TTL value of 5 minutes and as, such, the token T1 has to be refreshed before the expiry at a predefined time (e.g., 2 minutes prior to expiry). In one example scenario, the subscriber ‘A’ may have shared the token T1 including the CDN PoP URL with a friend, for example, user X. The user X may initiate playback of the media content on a smart TV associated with a device identifier ‘LYK1041Q’ and an IP address (178.23.2. 225) using the enhanced long token T1. It is noted that the CDN PoP URL in the token T1 is associated only with a segment of the media content (i.e., the action movie), and to receive the continued stream of subsequent segments from the CDN, refresh requests for the token T1 need to be sent to the CDN. In one example scenario, a token T1X sent for a long token refresh from the smart TV associated with the user X includes device parameters related to the user X, such as a type of electronic device (e.g., TV) for requesting the playback of the media content, device identifier, a type of access method (web interface or mobile application), type of network access (cellular or Wi-Fi), IP address, location information, and the like. This information integrated into the long token refresh request, i.e., in token T1X may be collected from cookies in the web interface or mobile application that the user X may utilize to access the media content offered by the content provider.

[0079] When the system 150 receives the token T1X from the user X on behalf of the CDN and performs a long token sharing check as outlined above, i.e., parse the contents of the token T1X and matches the extracted parameters with the parameters of token T1 stored in the token history database 330. As the type of devices, the device identifiers, the access type, and the IP addresses of the subscriber A and user X as embedded in the access tokens T1 and T1X are different, a dissimilarity value S1 of 4 may be computed by the comparator module 306. If the first predetermined threshold (P1) is preset to 2, then the dissimilarity value S1 is greater than the first predetermined threshold (i.e., S1 > P1), indicating that the token T1X has failed the long token sharing check.

[0080] If the token T1X, i.e., the long token refresh request, fails the long token sharing check, it is determined that the long token refresh request has been received from an unauthorized user who is associated with a different electronic device, IP address, or geographical location when compared with the subscriber, who had requested the enhanced long token. The comparator module 306 is configured to raise a flag signal to the parsing module 304. The flag signal, which is indicative of a potential illegitimate event, may be forwarded to the action module 214, which in conjunction with the CDN 180, may restrict content access and even block the subscriber’s device from future access. In some cases, the device/IP address credentials may also be added to the token ID database 320 as blacklisted entries.

[0081] In some embodiments, a subscriber such as subscriber 102 who had acquired the initial enhanced long token may make long token refresh requests on behalf of the illegitimate users. The comparator module 306, in conjunction with the parsing module 304, is configured to compare the contents of each long token refresh request with previously issued enhanced long tokens. If the number of long token refresh requests is greater than a second predetermined threshold, then a presence of an anomaly may be deduced. If an anomaly is detected by the comparator module 306, then a flag signal is issued to the parsing module 304, which may provide such information to the action module 212. The action module 212, in conjunction with the CDN 180a, may be configured to request additional authentication from the subscriber 102, block access to the requested content, or temporarily suspend the subscriber’s account.

[0082] In a non-limiting example, a pseudo-code for performing the long token sharing check is provided below:

-Receive content viewer metadata (including IP addresses);
-Count IPs per enhanced long token;
-Validate count of IPs per enhanced long token;
--If Count of IPs per Long token < First predetermined threshold;
---Send enhanced long token;
--If Count of IPs per Long token > First predetermined threshold;
--- Long token sharing error Detected, give error;
---The token ID is set as blacklist;
-For new calls, check if new token ID = = black list token ID;
-IF yes, decline;

[0083] As explained with reference to FIG. 1, in some scenarios, a subscriber 102 or a user may bypass the concurrency usage restriction by restricting the device heartbeat signal and making multiple short token requests for streaming content.

[0084] As per the present invention, the comparator module 306 is configured to perform a concurrency bypass check. In an illustrative example, a subscriber 102 may provide different playback URL requests within a preset amount of time, for example, in 15 minutes, using one or more devices. Further, the enhanced short tokens and long tokens may also be provided by the CDN 180a to the subscriber 102 for accessing different content requested by the subscriber 102. In scenarios, where the subscriber 102 is trying to select a content to watch, the subscriber 102 may attempt to watch initial few segments of multiple content, and accordingly, multiple exchanges of short and long tokens may be possible. However, the periodic long token refresh requests for different content on different devices, which exceed a threshold number of devices defined by the subscriber’s subscription, may be a clear indication of concurrency bypass. Accordingly, the comparator module 306 may be configured to track metadata in each long token refresh request from among the multiple long token refresh requests provided by the subscriber 102 using different devices within a preset amount of time. More specifically, the comparator module 306 is configured to perform the concurrency bypass check, wherein the number of long token refresh requests associated with a subscriber account is tracked and compared across multiple requests within a preset time interval. If the number of received long token refresh requests associated with similar/different content titles is greater than a preset threshold (for example, 5 requests), then the presence of an anomaly may be deduced. Similarly, if the subscriber’s location identified from the metadata seems to be different in two successive enhanced long token refresh requests received within the preset time interval, then the presence of an anomaly may be deduced.

[0085] In particular, the comparator module 306 is configured to determine a number of consecutive token refresh requests associated with the same content viewer ID within a preset time interval. Then, the comparator module 306 is configured to determine a number of electronic devices generating the consecutive token refresh requests associated with the same content viewer ID. Further, a new enhanced long token is generated and transmitted upon determining that the number of consecutive token refresh requests and the number of electronic devices is less than a second predetermined threshold. Otherwise, a concurrency check flag is generated and transmitted. The concurrency check flag indicates authentication failure due to a possible concurrency bypass. Herein, the second predetermined threshold is determined based, at least in part, on an account type of the content viewer and a soft buffer. Further, the content viewer ID may also be blacklisted in a database associated with the system 150. In one illustrative example, user A with a premium subscription may view a thriller web series on a laptop while accessing a live cricket match on a smartphone.
[0086] In an illustrative example, user A may have manipulated his application to restrict the transmission of the heartbeat signal and thereby attempt to hide access to the live cricket match on the smartphone. The subscriber 102 may share his access credentials (i.e., login information) with a friend (for example, user B) who intends to follow the live streaming of the cricket match on a laptop. The user B may make a fresh request for a short token related to the live streaming of a cricket match, assuming that his device may be recorded as a second device streaming different content as allowed by the user A’s premium subscription. Based on the received short token, the user B may place a long token request. Thereafter, the user A and user B may place a request to refresh long token requests at periodic intervals. However, due to the tracking of the access requests and the device/IP address credentials/locations in the long token requests themselves, a subsequent access from a different device and different IP address/location may be detected and flagged as an anomalous occurrence. If the number of devices accessing media contents for a given subscriber’s account exceeds a threshold allowed by the subscriber’s subscription, then the subscriber is deemed to have failed the concurrency bypass check. Further, it is noted that by relying on the enhanced long token, the concurrency can be checked even if the heartbeat signal is lost, thereby preventing concurrency bypass.

[0087] If the concurrency bypass check fails for a subscriber, the system 150 may facilitate the display of a concurrency error popup on the electronic device of the subscriber 102. In some embodiments, a list of electronic devices currently accessing the media content may be displayed to the subscriber 102. In addition, the subscriber 102 may be provided with an option to log out of one or more sessions that are currently active on different devices. In one illustrative example, a standard subscriber may have logged into his account via a smartphone to view a live soccer game and may have also turned on his laptop to view the live soccer game on a bigger screen. If the concurrency limit is exceeded based on the subscriber’s account limit, then a prompt may be displayed to the subscriber 102 including provisions to logout of the session active on the smartphone and/or the laptop. If the subscriber 102 chooses to logout of one or more sessions and if the active devices and active sessions of the subscriber pass the concurrency bypass check as explained above, the media content will be seamlessly provided to the subscriber 102. For example, if a subscriber chooses to logout off a session active on their smartphone, media content will be seamlessly played on a laptop.

[0088] In a non-limiting example, a pseudo-code for performing the long token sharing check is provided below:

-Receive content viewer metadata (including device IDs and IP addresses);
-Count device IDs per enhanced long token;
-Count IPs per enhanced long token;
-Validate count of device IDs and IPs per enhanced long token;
Case (a)--If Count of device IDs < second predetermined threshold and count of IPs per Long token < second threshold;
---Concurrency check passed;
Case (b)-- If Count of device IDs > second determined threshold and count of IPs per Long token > second threshold;
--- Concurrency check fail;
---The token ID is set as blacklist;
-For new calls, check if new token ID = = black list token ID;
-IF yes, decline;

[0089] In a non-limiting example, the second predetermined threshold is determined based at least in part on various dynamic factors such as content type, content viewer profile, account type (subscription type), content viewer behavior, and the like.

[0090] FIG. 5 depicts a sequence flow diagram showing a process flow 500 for authenticating a content viewer while streaming content a CDN, in accordance with an embodiment of the invention.

[0091] FIG. 5 depicts a subscriber 502 associated with an electronic device 504 exemplarily depicted to be a smartphone. The subscriber 502 may have installed a mobile application (not shown in FIG. 5) related to an OTT streaming content provider on the electronic device 504. It is noted that the electronic device 504 may be any other device capable of connecting to a communication network, such as the Internet, and displaying content retrieved over the communication network. For example, the electronic device 504 may be a smart TV, and a Web application corresponding to the content provider may be installed on the smart TV. Alternatively, the subscriber 502 may access a website related to the content provider on the electronic device 504 for accessing the streaming content. In at least some embodiments, the subscriber 502 may complete a registration process, which may involve selecting a subscription plan prior to accessing content offered by the content provider. In one illustrative example, subsequent to the completion of the registration process, the subscriber 502 may access a UI associated with a content provider on the electronic device 504 and provide a selection of a content title from among a plurality of content titles displayed on the UI. The process flow 500 starts at 512 after the subscriber 502 has provided a selection of the content title to watch on the UI associated with the content provider on the electronic device 504. It is noted that subscriber 502, electronic device 504, digital platform server 506, CDN 508, and CDN POP 510 are similar or identical to subscriber 102, electronic 104, digital platform server 120, CDN 108a, and CDN POP 190 respectively of FIG. 1.

[0092] At 512, a request for playback URL is sent from the electronic device 504 to a digital platform server 506 associated with the content provider in response to the selection of content title on the UI by the subscriber 502.

[0093] At 514, the digital platform server 506 generates an enhanced short token. The generation of the enhanced short token may be performed as explained with reference to FIGS. 2 and 3.

[0094] At 516, the enhanced short token is provided to the electronic device 504 by the digital platform server 506. The enhanced short token includes the playback URL of the requested content and metadata including a subscriber and content related information.

[0095] At 518, the enhanced short token is forwarded by the electronic device 504 to a content delivery network (CDN) 508. The enhanced short token is also received by the system 150 on account of being in operative communication with the CDN 508.

[0096] At 520, the system 150 is configured to perform a concurrency bypass check in addition to other verification checks. The concurrency bypass check may be performed as explained with reference to FIG. 3 and is not explained again herein.

[0097] Subsequent to successful verification checks, at 522, the system 150 is also configured to provide the metadata extracted from the enhanced short token along with a TTL value to the CDN 508.

[0098] At 524, the CDN 508 is configured to generate the enhanced long token and share the enhanced long token with the electronic device 504.

[0099] At 526, the electronic device 504 is configured to receive streaming content from a CDN PoP 510 using a CDN PoP URL with the enhanced long token. At first, a content request is made by the user for accessing the desired content using the enhanced long token. Upon receiving the content request, the enhanced long token is checked by the system 150 to determine whether the same token is already being used by another user to access the content. If so, the content request is rejected and the enhanced long token is blacklisted otherwise, the content stream is authorized and the electronic device initiates the streaming of content.

[0100] At 528, the electronic device 504 may provide a long token refresh request to the CDN 508. The long token refresh request is also received by the system 150 on account of being in operative communication with the CDN 508.

[0101] At 530, the system 150 is configured to perform at least one of a long token sharing check and a concurrency bypass check based on information included within the long token refresh request.

[0102] At 532, the system 150 is configured to indicate a status of the check to the CDN 508. For example, if the long token refresh request fails the long token sharing check, then a fail signal is provided to the CDN 508 by the system 150. If the long token refresh request succeeds the long token sharing check, then a success signal is provided to the CDN 508 by the system 150.

[0103] At 534, the CDN 508 responds to the electronic device 504 based on the status of the long token sharing check and the concurrency bypass check. More specifically, if the long token sharing check is successful, then the CDN 508 refreshes the long token and shares the refreshed long token to the electronic device 504. If the long token sharing check is a failure, then the CDN 508 blocks the access to the requested content and informs the electronic device 504 of the presence of a possible illegitimate activity. The process flow 500 stops at 534.

[0104] FIG. 6 shows a flow diagram of a method 600 for authenticating a content viewer while streaming content from content delivery networks, in accordance with an embodiment of the invention. The various steps and/or operations of the flow diagram, and combinations of steps/operations in the flow diagram, may be implemented by, for example, hardware, firmware, a processor, circuitry, and/or by a system such as the system 150 explained with reference to FIG. 1 to 4 and/or by a different device associated with the execution of software that includes one or more computer program instructions. The method 600 starts at operation 602.

[0105] At operation 602 of the method 600, an enhanced short token is received by a system, such as the system 150, from a subscriber’s electronic device 104. The enhanced short token is provided to the subscriber’s device 104 by a digital platform server 506 associated with a content provider in response to a request for a content playback URL. The enhanced short token includes information related to at least one of the subscriber 102 and content associated with the requested content playback URL.

[0106] At 604, the enhanced short token is parsed by the system 150 and one or more parameters values are extracted from the enhanced short token and recorded in a database such as token history database 330.

[0107] At 606, the generation of an enhanced long token is facilitated by the system 150. The enhanced long token is generated by the CDN such as CDN 508 using the extracted one or more parameter values. The enhanced long token including a time-to-live (TTL) value is provided to the subscriber’s electronic device 504 in response to the receipt of the enhanced short token.

[0108] At 608, a request for refreshing the enhanced long token is received by the system 150 from the subscriber’s electronic device 504 prior to an expiry of a time period indicated in the TTL value.

[0109] At 610, at least one of a long token sharing check and a concurrency bypass check is performed by the system 150 in response to the receipt of the request for refreshing the long token. The long token sharing check and the concurrency bypass check may be performed using the one or more parameter values recorded in the database.

[0110] At 612, at least one action is performed by the system 150 based on the status of the long token sharing check and the concurrency bypass check. For example, if the long token sharing check is a failure, then a fail signal is provided by the CDN 508 by the system. If the long token sharing check is a success, then a success signal is provided by the CDN 508 to the system 150 and the CDN 508 refreshes the enhanced long token for the subscriber 102.

[0111] FIG. 7 shows a flow diagram of a method 700 for authenticating a content viewer while streaming content from any content repository server, i.e., a CDN, in accordance with an embodiment of the invention. The various steps and/or operations of the flow diagram, and combinations of steps/operations in the flow diagram, may be implemented by, for example, hardware, firmware, a processor, circuitry, and/or by a system such as the system 150 explained with reference to FIG. 1 to 6 and/or by a different device associated with the execution of software that includes one or more computer program instructions. The method 700 starts at operation 702.

[0112] At operation 702, the method 700 includes receiving, by a system 150, an enhanced short token from an electronic device 104 of a content viewer (i.e., the subscriber 102), the enhanced short token including at least a content address (i.e., the content playback URL), a content repository server identifier (ID), and a first content viewer metadata. In various embodiments, the enhanced short token further includes a short token ID (i.e., first token ID), and a token lifespan. Further, the first content viewer metadata includes a content viewer identifier (ID), a device ID, an IP address associated with the electronic device 104 of the content viewer, and the like.

[0113] At 704, the method 700 includes generating, by the system 150, an enhanced long token based, at least in part, on the enhanced short token. The enhanced long token includes at least the content address, the content repository server ID, and a time-to-live (TTL) value indicating a lifetime of the enhanced long token.

[0114] At 706, the method 700 includes transmitting, by the system 150, the enhanced long token to the electronic device 504.

[0115] FIG. 8 is a simplified block diagram of a Content Delivery Network (CDN) 800, in accordance with various embodiments of the invention. The CDN 800 is an example of the CDN 180 of FIG. 1 or CDN 508 of FIG. 5. The CDN 800 refers to a distributed group of servers that are connected via a network (such as Network 804, which is explained later). The CDN 800 provides quick delivery of media content to various content viewers subscribed to the digital platform server 120. The CDN 800 includes a plurality of interconnected servers that may interchangeably be referred to as a plurality of content repository servers. The CDN includes an origin CDN server 802, a public CDN server 806, a private CDN server 808, a Telecommunication CDN server (referred to hereinafter as ‘Telco CDN server’) 810, an Internet Service Provider CDN server (referred to hereinafter as ‘ISP CDN server’) 812, and a CDN point of presence server (referred to hereinafter as ‘CDN POP server’) 814 each coupled to, and in communication with (and/or with access to) the network 804. The CDN POP server 814 is an example of the CDN POP 190 of FIG. 1. It is noted that CDN POP may also be interchangeably referred to as ‘sub-CDNs’, ‘subnet CDN’, ‘surrogate CDN’, and ‘CDN sub-box’. Further, two or more components of the CDN 800 may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the CDN 800 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.

[0116] The network 804 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber-optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated in FIG. 8, or any combination thereof. Various servers within the CDN 800 may connect to the network 804 using various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, future communication protocols or any combination thereof. For example, the network 804 may include multiple different networks, such as a private network made accessible by the origin CDN server 802 and a public network (e.g., the Internet, etc.) through which the various servers may communicate.

[0117] The origin CDN server 802 stores the media content accessed/downloaded from the streaming content provider and/or content producers. The origin CDN server 802 serves the media content to one or more cache servers which are either located in the vicinity of the content viewer/subscriber or connected to another cache server located in the content viewer’s vicinity. In various examples, cache servers include the public CDN server 806, the private CDN server 808, the Telco CDN server 810, the ISP CDN server 812, the CDN POP server 814, and the like.

[0118] The origin CDN server 802 includes a processing system 816, memory 818, database 820, and communication interface 822. The processing system 816 is configured to extract programming instructions from the memory 818 to perform various functions of the CDN 800. In one example, the processing instructions include instructions for ingesting media content via the communication interface 822 from a remote database 824 which may further include one or more data repositories/databases (not shown) to an internal database such as database 820. The remote database 824 is associated with a streaming content provider and/or content producer. In another example, the media content stored within the database 820 can be served to one or more cache servers via the communication interface 822 over the network 804.

[0119] In some examples, the public CDN server 806 is associated with a public CDN provider which hosts media content among other types of data for different content providers within the same server. The private CDN server 808 is associated with a private CDN provider (such as a streaming content provider) which hosts media content for serving the needs of its subscribers. The Telco CDN server 810 is associated with telecommunication service providers which provide content hosting services to various entities such as the streaming content platform. The ISP CDN server 812 is associated with internet service providers which provide content hosting services to various entities such as the streaming content platform. The CDN POP server 190 caches content and allows the electronic devices of the content viewers to stream the content. It is noted that the various cache servers download and cache media content from the origin CDN server 802 and further allow a valid user or content viewer to stream the media content.

[0120] It is noted that various embodiments of the present disclosure, the various functions of the system 150, or the method disclosed in FIG.6 and/or FIG.7 can be implemented using any one or more components of the CDN 800 such as the origin CDN server 802 and/or one or more cache servers individually and/or in combination with each together. Alternatively, the system 150 can be communicably coupled with the CDN 800 to perform the various embodiments or methods described by the present disclosure.

[0121] Various embodiments disclosed herein provide numerous advantages. More specifically, the embodiments disclosed herein suggest techniques for authenticating a content viewer while streaming content from the CDNs. Only legitimate users are allowed to access streaming content and illegitimate activity such as long token sharing or concurrency bypass, which leads to a loss of revenue for the content provider and for the content creation ecosystem is mitigated. The deployment of a security layer, in the form of the system 150, near a CDN also provides several advantages. For example, the security layer can stop illegitimate content access from a point in a network, from which the content is being accessed. Further, the security layer enables a CDN to perform its routine security checks without having to add custom layers for each content provider’s delivery architecture, and yet provide a high level of security in terms of content access. Furthermore, the security layer avoids the need for the CDN to check or confirm the authenticity of each subscriber’s content access request with the content provider’s platform, thereby enabling scaling of the security checks without burdening the CDN or the content provider’s platform.

[0122] The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the present invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The exemplary embodiment was chosen and described in order to best explain the principles of the present invention and its practical application, to thereby enable others skilled in the art to best utilize the present invention and various embodiments with various modifications as are suited to the particular use contemplated.
,CLAIMS:CLAIMS
We Claim:

1. A computer-implemented method for authenticating a content viewer while streaming content, the method comprising:
receiving, by a system, an enhanced first token from an electronic device of a content viewer, the enhanced first token comprising at least a content address, a content repository server identifier (ID), and a first content viewer metadata;
generating, by the system, an enhanced second token based, at least in part, on the enhanced first token, the enhanced second token comprising at least the content address, the content repository server ID, the first content viewer metadata, and a time-to-live (TTL) value indicating a lifetime of the enhanced second token; and
transmitting, by the system, the enhanced second token to the electronic device.

2. The computer-implemented method as claimed in claim 1, wherein the enhanced first token further comprises a first token ID, a token lifespan, and the first content viewer metadata further comprises a content viewer ID, a device ID, an IP address associated with the electronic device of the content viewer, type of network access, type of electronic device, content viewer account credentials, and location information.

3. The computer-implemented method as claimed in claim 1, further comprising:
authenticating, by the system, the enhanced first token based, at least in part, on performing a hash-message authentication code (HMAC) verification on the enhanced first token, wherein the authenticating comprises:
comparing, by the system, the first token ID with a plurality of prior token IDs accessed from a token ID database associated with the system to determine if the first token ID is unique; and
upon determining that the first token ID is unique, authenticating, by the system, the enhanced first token.

4. The computer-implemented method as claimed in claim 3, wherein the authenticating further comprises:
comparing, by the system, the first token ID with a plurality of blacklisted token IDs accessed from the token ID database to determine if the first token ID is blacklisted; and
upon determining that the first token ID is not blacklisted, authenticating, by the system, the enhanced first token.

5. The computer-implemented method as claimed in claim 3, wherein the authenticating further comprises:
determining, by the system, if the enhanced first token is active based, at least in part, on the token lifespan; and
upon determining that the enhanced first token is active, authenticating, by the system, the enhanced first token.

6. The computer-implemented method as claimed in claim 1, wherein the TTL value is determined based, at least in part, on a content type requested by the content viewer and user concurrency, wherein the content type is determined based, at least in part, on the content address.

7. The computer-implemented method as claimed in claim 1, further comprising:
receiving, by the system, a token refresh request from the electronic device, the token request being generated based, at least in part, on the TTL value, the token refresh request comprising a second content viewer metadata.

8. The computer-implemented method as claimed in claim 7, further comprising:
determining, by the system, a dissimilarity value for the token refresh request based, at least in part, on the first content viewer metadata and the second content viewer metadata;
generating, by the system, a new enhanced second token upon determining that the dissimilarity value is less than a first predetermined threshold; and
transmitting, by the system, the new enhanced second token to the electronic device.

9. The computer-implemented method as claimed in claim 7, further comprising:
generating, by the system, a second token sharing flag upon determining that the dissimilarity value is greater than a first predetermined threshold, the second token sharing flag indicating authentication failure due to second token sharing;
blacklisting, by the system, the content viewer ID in a database associated with the system; and
transmitting, by the system, the second token sharing flag to the electronic device.

10. The computer-implemented method as claimed in any of claim 8 or 9, wherein the first predetermined threshold is determined based, at least in part, on an account type of the content viewer, wherein the account type is determined based, at least in part, on the content viewer ID.

11. The computer-implemented method as claimed in claim 7, further comprising:
determining, by the system, a number of consecutive token refresh requests associated with the same content viewer ID within a preset time interval;
determining, by the system, a number of electronic devices generating the consecutive token refresh requests associated with the same content viewer ID;
generating, by the system, a new enhanced second token upon determining that the number of consecutive token refresh requests and the number of electronic devices is less than a second predetermined threshold; and
transmitting, by the system, the new enhanced second token to the electronic device.

12. The computer-implemented method as claimed in claim 7, further comprising:
determining, by the system, a number of consecutive token refresh requests associated with the same content viewer ID within a preset time interval;
determining, by the system, a number of electronic devices generating the consecutive token refresh requests associated with the same content viewer ID;
generating, by the system, a concurrency check flag upon determining that the number of consecutive token refresh requests and the number of electronic devices is greater than a second predetermined threshold, the concurrency check flag indicating authentication failure due to concurrency bypass;
blacklisting, by the system, the content viewer ID in a database associated with the system; and
transmitting, by the system, the concurrency check flag to the electronic device.

13. The computer-implemented method as claimed in claim 1, wherein the second predetermined threshold is determined based, at least in part, on content type, content viewer profile, account type, and content viewer behavior.

14. The computer-implemented method as claimed in claim 1, wherein the content repository server is a Content Delivery Network (CDN) and the content address is a content playback Uniform Resource Locator (URL).

15. A system for authenticating a content viewer while streaming content, the system comprising:
a memory for storing instructions; and
a processor configured to execute the instructions and thereby cause the system, at least in part, to:
receive an enhanced first token from an electronic device of a content viewer, the enhanced first token comprising at least a content address, a content repository server identifier (ID), and a first content viewer metadata;
generate an enhanced second token based, at least in part, on the enhanced first token, the enhanced second token comprising at least the content address, the content repository server ID, the first content viewer metadata, and a time-to-live (TTL) value indicating a lifetime of the enhanced second token; and
transmit the enhanced second token to the electronic device.

16. The system as claimed in claim 15, wherein the enhanced first token further comprises a first token ID, a token lifespan, and the first content viewer metadata further comprises a content viewer ID, a device ID, an IP address associated with the electronic device of the content viewer, type of network access, type of electronic device, content viewer account credentials, and location information.

17. The system as claimed in claim 15, wherein, the system is further caused, at least in part to:

receive a token refresh request from the electronic device, the token request being generated based, at least in part, on the TTL value, the token refresh request comprising a second content viewer metadata;
determine a dissimilarity value for the token refresh request based, at least in part, on the first content viewer metadata and the second content viewer metadata;
generate a new enhanced second token upon determining that the dissimilarity value is less than a first predetermined threshold; and
transmitting, by the system, the new enhanced second token to the electronic device.

18. The system as claimed in claim 15, wherein, the system is further caused, at least in part to:
receive a token refresh request from the electronic device, the token request being generated based, at least in part, on the TTL value, the token refresh request comprising a second content viewer metadata;
determine a dissimilarity value for the token refresh request based, at least in part, on the first content viewer metadata and the second content viewer metadata;
generate a second token sharing flag upon determining that the dissimilarity value is greater than a first predetermined threshold, the second token sharing flag indicating authentication failure due to second token sharing;
blacklist the content viewer ID in a database associated with the system; and
transmit the second token sharing flag to the electronic device.

19. The system as claimed in claim 18, wherein the first predetermined threshold is determined based, at least in part, on an account type of the content viewer, wherein the account type is determined based, at least in part, on the content viewer ID.

20. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by at least a processor of a system, cause the system to perform a method comprising:
receiving an enhanced first token from an electronic device of a content viewer, the enhanced first token comprising at least a content address, a content repository server identifier (ID), and a first content viewer metadata;
generating an enhanced second token based, at least in part, on the enhanced first token, the enhanced second token comprising at least the content address, the content repository server ID, the first content viewer metadata, and a time-to-live (TTL) value indicating a lifetime of the enhanced second token; and
transmitting the enhanced second token to the electronic device.