JP7693117B2 - Managing access to protected content using device security profiles - Google Patents

Description

CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63/289,067, filed December 13, 2021, and U.S. Patent Application No. 17/670,301, filed February 11, 2022, each of which is incorporated by reference in its entirety.

Content, such as digital images and videos, may be stored on servers or content storage and delivery systems connected to a network, such as the Internet. Client devices may download the content and display it to users of the client devices. Content owners may want to prevent unauthorized distribution of their content or reduce the quality of copies made by client devices without authorization. In some cases, Digital Rights Management (DRM) technology may be used to prevent client devices from copying content or to reduce the quality of copies of content made by client devices.

Disclosed herein are aspects of a system, method, computer program product, and apparatus for managing access to protected content using a device security profile.

One aspect of the teachings described herein is a method of managing access to protected content using a device security profile. The method may include receiving data associated with a device security profile (DSP) from a content owner device at a digital rights management (DRM) server, where the DSP specifies requirements for a client device to access a content item associated with the content owner, the requirements varying with a resolution level of the content item being accessed. The method may include storing an indication of the DSP and the content owner at the DRM server. The method may include receiving a pull request for a DSP update from a content server that stores the content items associated with the content owner. The method may include transmitting the DSP to the content server in response to the pull request, where the DSP causes the content server to restrict client devices from accessing the content item according to the DSP (e.g., the DSP is configured to cause the content server to restrict client device access to the content item according to the DSP).

The resolution levels may be based on at least one of total pixels, pixels per frame, or pixel dimension measurements. The resolution levels may include at least one of standard definition (SD), high definition (HD), or 4K. The requirements may vary depending on the tag of the content item being accessed. The requirements may comprise hardware and/or security requirements of the client device (e.g., each client device) accessing the content item. The DSP may be configured with a first data structure representing the resolution levels and requirements for each resolution level, a second data structure representing the tags of the content item and requirements for each tag, and a third data structure representing device configurations having exceptions to the requirements of the first data structure or the requirements of the second data structure.

The method may further include pushing the DSP to a second content server if a pull request for the DSP update is not received within a predetermined time from a second content server that stores the content item associated with the content owner. The method may further include receiving an update to the DSP from the content owner device, receiving a second pull request from the content server, and sending the update to the DSP or an updated version of the DSP to the content server in response to the second pull request.

The method may further comprise transmitting code to the content owner device that generates a graphical user interface (GUI) for inputting data associated with the DSP, and generating at the DRM server a DSP based on data associated with the DSP obtained at the content owner device via the GUI. The method may comprise receiving at the content server the DSP of the content owner, receiving at the content server a content request from a client device for a content item, the content item being one of the content items associated with the content owner, determining a resolution level of the content item to provide to the client device based on the content request and the DSP, and transmitting the content item from the content server to the client device at the determined resolution level.

Another aspect of the teachings described herein is a computer system that uses a device security profile to manage access to protected content. The system includes a memory that stores instructions. The system includes a processor that can execute instructions to perform the method of any of the aspects described above. In particular, the processor can execute instructions to receive data associated with a DSP from a content owner device at a DRM server, where the DSP specifies requirements for a client device to access a content item associated with the content owner, the requirements varying with the resolution level of the content item being accessed. The processor can execute instructions to store an indication of the DSP and the content owner at the DRM server. The processor can execute instructions to receive a pull request for a DSP update from a content server that stores the content items associated with the content owner. The processor can execute instructions to send the DSP to the content server in response to the pull request, where the DSP causes the content server to restrict client devices from accessing the content item according to the DSP.

In another aspect, a computer-readable medium (e.g., a computer program product) for managing access to protected content using a device security profile. The computer-readable medium stores instructions that can cause a processor to perform operations such as those in the method of the aspect described above. The instructions may include code for receiving data associated with a device security profile (DSP) from a content owner device at a digital rights management (DRM) server, the DSP specifying requirements for a client device to access a content item associated with the content owner, the requirements varying with a resolution level of the content item being accessed. The instructions may include code for storing the DSP and an indication of the content owner at the DRM server. The instructions may include code for receiving a pull request for a DSP update from a content server that stores the content items associated with the content owner. The instructions may include code for sending the DSP to the content server in response to the pull request, the DSP causing the content server to restrict client devices from accessing the content item according to the DSP.

Variations of these and other aspects are described in more detail below.

The present specification is described with reference to the accompanying drawings, in which like reference numerals refer to like parts throughout the various views unless otherwise noted or apparent from the context.

FIG. 1 is a diagram of a computing device. FIG. 1 is a diagram of a computing and communication system. FIG. 1 is a block diagram of an example of a system in which access control to protected content can be implemented using device security profiles. FIG. 2 is a block diagram illustrating an example of a data structure of a device security profile. 1 is a flow chart illustrating an example of a method for providing a device security profile to a content server. 1 is a flow chart illustrating an example of a method for processing a content request using a device security profile. FIG. 13 is a diagram of a graphical user interface for entering information associated with a device security profile. FIG. 13 is a diagram of a graphical user interface for displaying exceptions to a device security profile. FIG. 13 is a diagram of a graphical user interface for searching a device security profile.

A content owner may develop content (e.g., digital video, audio files, images) and provide the content for storage on a content server. The content server distributes the content to client devices where it can be displayed or played. The content owner may want to prevent unauthorized distribution of the content or to degrade the quality of copies made on client devices without authorization. It can be difficult to provide content for playback while restricting the provided content from being further distributed or copied.

In some cases, Digital Rights Management (DRM) technologies may be used to prevent client devices from copying content or to degrade the quality of copies of content made by client devices. DRM servers may provide DRM policy information to content servers. DRM servers may provide encryption schemes and hardware security support to restrict client devices from accessing delivered content according to rules defined by the content owner.

Content owners may wish to dynamically update rules regarding the hardware and security policies of devices that access their content. This may be desirable, for example, when new hardware comes onto the market, when security policies change, or when new security vulnerabilities are discovered that may be exploited to illegally copy content.

At least some implementations of the teachings herein relate to the technical problem of how to protect access to content items in a distribution system in response to dynamic changes in the security of the devices accessing the content items. A technical solution may comprise establishing a Device Security Profile (DSP) that can be dynamically updated by a content owner. For example, a content owner may update the DSP in response to changes in security credentials of a client device. A technical solution may comprise providing a distribution architecture for making the DSP available to a content server in a secure and timely manner.

In some implementations, the DRM server receives data associated with a DSP from a content owner device. The DSP specifies requirements for a client device to access a content item associated with the content owner. The requirements vary depending on the resolution level of the content item being accessed. The resolution level may be based on total pixels, pixels per frame, pixel dimension measurements, or a combination thereof. For example, the resolution level may be at least one of standard definition (SD) (e.g., 720x480 pixels), high definition (HD) (e.g., 1280x720 pixels or 1920x1080 pixels), or 4K (e.g., 4096x2160 pixels). The DRM server stores the DSP along with an indication of the content owner, for example, in a data structure associated with the content owner. The DRM server receives a pull request for a DSP update from a content server that stores the content item associated with the content owner. The DRM server transmits the DSP to the content server in response to the pull request. The DSP allows the content server to restrict the client devices that can access the content item according to the DSP.

In some implementations, the content server receives a DSP of a content owner, e.g., in response to a pull request for a DSP update from the content server. The DSP specifies requirements for a client device to access a content item associated with the content owner. The requirements vary depending on the resolution level of the content item to be accessed. The content server receives a content request for the content item from the client device. The content server determines a resolution level of the content item to provide to the client device based on the content request and the DSP. The content server transmits the content item to the client device at the determined resolution level.

Details of these and other embodiments are described in further detail below, first with reference to the environments in which they may be implemented.

1 is a block diagram illustrating an example of a computing device 100. The illustrated computing device 100 includes a memory 110, a processor 120, a user interface (UI) 130, an electronic communication unit 140, a sensor 150, a power source 160, and a bus 170. As used herein, the term "computing device" includes any unit or combination of units capable of performing any method or any portion thereof disclosed herein.

The computing device 100 may be a fixed computing device such as a personal computer (PC), a server, a workstation, a minicomputer, a mainframe, or a mobile computing device such as a mobile phone, a personal digital assistant (PDA), a laptop, a tablet PC, or the like. Although shown as a single unit, any one or more elements of the computing device 100 may be integrated into any number of separate physical units. For example, the user interface 130 and the processor 120 may be integrated into a first physical unit and the memory 110 may be integrated into a second physical unit. The processor 120 may be a hardware unit and may be comprised of processing hardware or processing circuitry. The processor 120 may comprise a single processor or multiple processors.

Memory 110 may include any non-transitory computer usable or computer readable medium, such as any tangible device capable of containing, storing, communicating, or transferring data 112, instructions 114, operating system 116, or any information related thereto for use by or in connection with other components of computing device 100. Non-transitory computer usable or computer readable media may include solid state drives, memory cards, removable media, read only memory (ROM), random access memory (RAM), hard disks, floppy disks, optical disks, any type of disk such as magnetic or optical cards, application specific integrated circuits (ASICs), or any type of non-transitory medium suitable for storing electronic information, or combinations thereof.

Although shown as a single unit, memory 110 may comprise multiple physical units, such as one or more primary memory units, such as random access memory units, one or more secondary data storage units, such as disks, or a combination thereof. For example, data 112 or portions thereof, instructions 114 or portions thereof, or both, may be stored in a secondary storage unit and loaded or transferred to a primary storage unit in conjunction with processing of the respective data 112, execution of the respective instructions 114, or both. In some implementations, memory 110 or portions thereof may be removable memory.

Data 112 may be or comprise input data, encoded data, decoded data, etc. Instructions 114 may include instructions, such as code, for performing any method disclosed herein, or any portion or portions thereof. Instructions 114 may be embodied in hardware, software, or any combination thereof. For example, instructions 114 may be implemented as information stored in memory 110, such as a computer program or application, and may be executed by processor 120 to perform any of the respective methods, algorithms, aspects, or combinations thereof described herein.

Although shown as having memory 110, in some implementations, instructions 114, or portions thereof, may be implemented as a special purpose processor or circuitry, which may include dedicated hardware for performing any of the methods, algorithms, aspects, or combinations thereof described herein. Portions of instructions 114 may be distributed across multiple processors on the same or different machines, or across a network, such as a local area network, a wide area network, the Internet, or a combination thereof.

Processor 120 may include any device or system capable of manipulating or processing digital signals or other electronic information, such as an optical processor, a quantum processor, a molecular processor, or a combination thereof, now existing or later developed. For example, processor 120 may include a special purpose processor, a central processing unit (CPU), a digital signal processor, multiple microprocessors, one or more microprocessors associated with a digital signal processor core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic array, a programmable logic controller, microcode, firmware, any type of integrated circuit (IC), a state machine, or any combination thereof. As used herein, the term "processor" includes a single processor or multiple processors.

The user interface 130 may include any unit capable of interfacing with a user, such as a virtual or physical keypad, a touchpad, a display, a touch display, a speaker, a microphone, a video camera, a sensor, or any combination thereof. For example, the user interface 130 may be an audiovisual display device, and the computing device 100 may use the user interface 130 audiovisual display device to present audio, such as decoded audio, in combination with a display of video, such as decoded video. Although shown as a single unit, the user interface 130 may comprise one or more physical units. For example, the user interface 130 may comprise an audio interface for audio communication with the user and a touch display for visual-based and touch-based communication with the user.

The electronic communication unit 140 may transmit, receive, or transmit and receive signals via a wired or wireless electronic communication medium 180, such as a radio frequency (RF) communication medium, an ultraviolet (UV) communication medium, a visible light communication medium, an optical fiber communication medium, a wired communication medium, or a combination thereof. For example, as shown, the electronic communication unit 140 is operatively connected to an electronic communication interface 142, such as an antenna configured to communicate via wireless signals.

Although electronic communication interface 142 is shown in FIG. 1 as a wireless antenna, electronic communication interface 142 can be a wireless antenna as shown, a wired communication port such as an Ethernet port, an infrared port, a serial port, or any other wired or wireless unit capable of interfacing with a wired or wireless electronic communication medium 180. Although a single electronic communication unit 140 and a single electronic communication interface 142 are shown in FIG. 1, any number of electronic communication units and any number of electronic communication interfaces can be used.

The sensor 150 may comprise, for example, an audio detector, a visible light detector, a motion detector, or a combination thereof. For example, the sensor 150 may comprise a sound detector, such as a microphone, or any other sound detector now existing or later developed, capable of detecting sounds in the vicinity of the computing device 100, such as a voice or other speech by a user operating the computing device 100. In another example, the sensor 150 may comprise a camera, or any other image detector now existing or later developed, capable of detecting images, such as an image of a user operating the computing device. Although a single sensor 150 is shown, the computing device 100 may comprise multiple sensors 150. For example, the computing device 100 may comprise a first camera with a field of view directed toward a user of the computing device 100 and a second camera with a field of view directed away from the user of the computing device 100.

The power source 160 can be any device suitable for providing power to the computing device 100. For example, the power source 160 can include a wired external power interface, one or more dry batteries such as nickel-cadmium (NiCd) batteries, nickel-zinc (NiZn) batteries, nickel-metal hydride (NiMH) batteries, lithium-ion (Li-ion) batteries, solar cells, fuel cells, or any other device capable of providing power to the computing device 100. Although a single power source 160 is shown in FIG. 1, the computing device 100 may include multiple power sources 160, such as batteries and wired external power interfaces.

Although shown as separate units, the electronic communication unit 140, the electronic communication interface 142, the user interface 130, the power source 160, or portions thereof, may be configured as a combined unit. For example, the electronic communication unit 140, the electronic communication interface 142, the user interface 130, and the power source 160 may be implemented as a communication port that can interface with an external display device and provide communication, power, or both.

One or more of the memory 110, the processor 120, the user interface 130, the electronic communication unit 140, the sensor 150, or the power source 160 may be operatively connected via a bus 170. Although a single bus 170 is shown in FIG. 1, the computing device 100 may include multiple buses. For example, the memory 110, the processor 120, the user interface 130, the electronic communication unit 140, the sensor 150, and the bus 170 may receive power from the power source 160 via the bus 170. In another example, the memory 110, the processor 120, the user interface 130, the electronic communication unit 140, the sensor 150, the power source 160, or a combination thereof, may communicate data, such as by sending or receiving electronic signals, via the bus 170.

Although not shown separately in FIG. 1, one or more of the processor 120, the user interface 130, the electronic communication unit 140, the sensor 150, or the power source 160 may include internal memory, such as an internal buffer or register. For example, the processor 120 may include internal memory (not shown) and may read and process data 112 from memory 110 into the internal memory (not shown).

Although shown as separate elements, the memory 110, the processor 120, the user interface 130, the electronic communication unit 140, the sensor 150, the power source 160, and the bus 170, or any combination thereof, may be integrated into one or more electronic units, circuits, or chips.

2 is a diagram of a computing and communication system 200. The illustrated computing and communication system 200 includes computing and communication devices 100A, 100B, 100C, access points 210A, 210B, and a network 220. For example, the computing and communication system 200 can be a multiple access system that provides communications, such as voice, audio, data, video, messaging, broadcast, or combinations thereof, to one or more wired or wireless communication devices, such as computing and communication devices 100A, 100B, 100C. For simplicity, FIG. 2 shows three computing and communication devices 100A, 100B, 100C, two access points 210A, 210B, and one network 220, but any number of computing and communication devices, access points, and networks can be used.

The computing and communication devices 100A, 100B, 100C can be, for example, computing devices such as the computing device 100 described in FIG. 1. For example, the computing and communication devices 100A, 100B can be user devices such as a mobile computing device, a laptop, a thin client, or a smartphone, and the computing and communication device 100C can be a server such as a mainframe or a cluster. Although the computing and communication devices 100A and 100B are described as user devices and the computing and communication devices 100C are described as servers, any computing and communication device may perform some or all of the server functions, some or all of the user device functions, or some or all of the server functions and the user device functions. For example, the server computing and communication device 100C can receive, process, such as encode, process, store, transmit, or a combination thereof, data such as audio data or video data, and one or both of the computing and communication devices 100A and 100B can receive, process, such as decode, process, store, present, or a combination thereof.

Each computing and communication device 100A, 100B, 100C may comprise a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a mobile phone, a personal computer, a tablet computer, a server, a consumer electronics device, or any similar device, and may be configured to communicate wired or wirelessly, such as via a network 220. For example, the computing and communication devices 100A, 100B, 100C may be configured to transmit or receive wired or wireless communication signals. Although each computing and communication device 100A, 100B, 100C is shown as a single unit, the computing and communication device may include any number of interconnected elements.

Each access point 210A, 210B can be any type of device configured to communicate with the computing and communication devices 100A, 100B, 100C, the network 220, or both, via a wired or wireless communication link 180A, 180B, 180C. For example, the access points 210A, 210B can include a base station, a base transceiver station (BTS), a NodeB, an enhanced NodeB (eNode-B), a home NodeB (HNode-B), a wireless router, a wired router, a hub, a repeater, a switch, or any similar wired or wireless device. Although each access point 210A, 210B is shown as a single unit, an access point can include any number of interconnected elements.

Network 220 can be any type of network configured to provide services such as voice, data, applications, Voice over Internet Protocol (VoIP), or any other communication protocol or combination of communication protocols over wired or wireless communication links. For example, network 220 can be a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), a mobile or cellular network, the Internet, or any other electronic communication means. The network can use communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Protocol (IP), Real-Time Transport Protocol (RTP), Hypertext Transfer Protocol (HTTP), or combinations thereof.

The computing and communication devices 100A, 100B, 100C can communicate with each other over the network 220 using one or more wired or wireless communication links, or a combination of wired and wireless communication links. For example, as shown, the computing and communication devices 100A, 100B can communicate via wireless communication links 180A, 180B, and the computing and communication device 100C can communicate via wired communication link 180C. Any of the computing and communication devices 100A, 100B, 100C may communicate using any wired or wireless communication link. For example, the first computing and communication device 100A can communicate via a first access point 210A using a first type of communication link, the second computing and communication device 100B can communicate via a second access point 210B using a second type of communication link, and the third computing and communication device 100C can communicate via a third access point (not shown) using a third type of communication link. Similarly, the access points 210A, 210B can communicate with the network 220 via one or more types of wired or wireless communication links 230A, 230B. Although FIG. 2 illustrates the computing and communication devices 100A, 100B, 100C communicating with each other via the network 220, the computing and communication devices 100A, 100B, 100C can communicate with each other via any number of communication links, such as direct wired or wireless communication links.

In some implementations, communication between one or more of the computing and communication devices 100A, 100B, 100C may omit communication over the network 220 and may include data transfer over another medium (not shown), such as a data storage device. For example, the server computing and communication device 100C may store data, such as encoded data, in a data storage device, such as a portable data storage unit, and one or both of the computing and communication device 100A or the computing and communication device 100B may access, read, or retrieve the stored audio data from the data storage unit, for example, by physically disconnecting the data storage device from the server computing and communication device 100C and physically connecting the data storage device to the computing and communication device 100A or the computing and communication device 100B.

Other implementations of the computing and communication system 200 are possible. For example, in one implementation, the network 220 can be an ad-hoc network and one or more of the access points 210A, 210B can be omitted. The computing and communication system 200 may include devices, units, or elements not shown in FIG. 2. For example, the computing and communication system 200 may include more communication devices, networks, and access points.

As previously discussed, protecting access to content items in a distribution system in response to dynamic changes in the security of devices accessing the content items can be accomplished by establishing a Device Security Profile (DSP) that can be dynamically updated by the content owner. The DSP may be used to manage access to such protected content.

3 is a block diagram of an example of a system 300 that can implement access management to protected content using a DSP. As shown, the system 300 includes content owner devices 302A, 302B, 302C, a DRM server 304, content servers 306A, 306B, and client devices 308A, 308B. The content owner devices 302A, 302B, 302C, the DRM server 304, the content servers 306A, 306B, and the client devices 308A, 308B can each correspond to a computing device 100. Also, although three content owner devices 302A, 302B, 302C, one DRM server 304, two content servers 306A, 306B, and two client devices 308A, 308B are shown, other numbers of these devices may be used in some implementations. The content owner devices 302A, 302B, 302C, the DRM server 304, the content servers 306A, 306B, and the client devices 308A, 308B communicate with each other via a network (e.g., the network 220). Each content server 306A, 306B may be or include a license server.

In some embodiments, the content owner devices 302A, 302B, 302C and the client devices 308A, 308B are user devices such as mobile phones, tablet computers, desktop computers, laptop computers, smart watches, personal digital assistants, digital music players, etc. The DRM server 304 and the content servers 306A, 306B may be server computers.

As shown, DRM server 304 stores data associated with content owners 310A, 310B, and 310C. Content owner 310A is associated with content owner device 302A. Content owner 310B is associated with content owner device 302B. Content owner 310C is associated with content owner device 302C. Data associated with content owner 310A includes DSP 312A. Data associated with content owner 310B includes DSP 312B. Data associated with content owner 310C includes DSP 312C.

In some implementations, the DRM server 304 sends code to the content owner device 302A that generates a graphical user interface (GUI) for entering data associated with the DSP 312A. An example of a GUI for entering information associated with the device security profile is shown in FIG. 7. The data associated with the DSP 312A may include requirements for the content owner's content associated with the content owner device 302A to be displayed at one or more resolution levels (e.g., SD, HD, 4K, etc.) or to have one or more tags (e.g., new release, drama, comedy, romance, etc., that provide descriptive data regarding characteristics of the content item). For example, the data associated with the DSP 312A may include the data shown in FIG. 4 and described below.

A user of the content owner device 302A inputs data associated with the DSP 312A into the GUI. The content owner device 302A transmits the data associated with the DSP 312A input into the GUI to the DRM server 304. The DRM server 304 generates a DSP 312A based on the data and stores the DSP 312A within the data associated with the content owner 310A. The DSP 312A specifies requirements for a client device, such as client devices 308A, 308B, to access a content item associated with the content owner 310A. The requirements may differ depending on the resolution level of the content item being accessed. For example, requirements may be different for accessing SD content than for accessing an HD version of the same content. In an embodiment, the requirements for accessing an HD version of ABC-MOVIE are different from the requirements for accessing a 4K version of ABC-MOVIE. The DSPs 312B, 312C are obtained from the content owner devices 302B, 302C and stored in data associated with the content owners 310B, 310C using techniques such as those described herein for the DSP 312A.

The DRM server 304 distributes the DSPs 312A, 312B, 312C to the content servers 306A, 306B that store the content of the associated content owners 310A, 310B, 310C. As shown, the content server 306A stores the content of the content owners 310A, 310B, but not the content of the content owner 310C, so that the content server 306A receives the DSPs 312A, 312B, but not the DSP 312C. Similarly, the content server 306B stores the content of the content owners 310B, 310C, but not the content owner 310A, so that the content server 306B receives the DSPs 312B, 312C, but not the DSP 312A. In other implementations, the content may be stored on more, fewer, or different content servers.

According to another embodiment, the DRM server 304 receives a pull request for DSP updates from a content server 306A that stores content items associated with the content owners 310A, 310B. In response to the pull request, the DRM server 304 transmits to the content server 306A DSPs 312A, 312B that have been updated or added since the last pull request. The transmitted DSPs 312A, 312B cause the content server to set restrictions or conditions for client devices accessing the content items of the content owners 310A, 310B according to the DSPs 312A, 312B. The content server 306B similarly transmits a pull request to receive the DSPs 312B, 312C of the content owners 310B, 310C whose content is stored in the content server 306B.

After receiving the DSP 312A of the content owner 310A, or simultaneously with receiving the DSP 312A of the content owner 310A, the content server 306A receives a content request 314A for the content item 316A of the content owner 310A from the client device 308A. The content request 314A may be or may comprise a license request and may include a hardware status and a security status of the client device 308A. For example, the hardware status may comprise the make and model of the client device 308A (e.g., Apple iPhone XR, Google Pixel 4, etc.) and any indication of changes to the hardware. The security status may include the operating system version and an indication of any security patches installed on the client device 308A.

Based on the content request 314A and the DSP 312A, the content server 306A determines the resolution level (e.g., SD, HD, 4K, etc.) of the content item 316A to provide to the client device 308A. For example, the resolution level can be determined by comparing the hardware and security status of the content request 314A with the requirements of the various resolution levels (and any tags of the content item 316A) specified by the DSP 312A.

In some implementations, the content server 306A can determine, based on the content request 314A and the DSP 312A, that the version of the requested content item may not be provided to the client device 308A and can send a message to the client device 308A informing the client device 308A that the content item 316A is unavailable. The content server 306A can determine, based on the DSP 312A, whether the client device 308A can access the requested content item 316A after a software update and can send a message to the user of the client device 308A advising them to update their software.

In some implementations, the content server 306A may determine, based on the content request 314A and the DSP 312A, that multiple different resolution levels (e.g., SD or HD, but not 4K) of the requested content item may be provided to the client device 308A. In some cases, the highest resolution level may be sent to the client device 308A. In some cases, the resolution level may be selected based on at least one of the network download speed of the client device 308A, the display capabilities of the client device 308A, the audio playback capabilities of the client device 308A, or a user account setting of a user account associated with the client device 308A. The content server 306A may send the content item 316A to the client device 308A at the determined resolution level. Similarly, the content server 306B may receive a content request 314B (which may be or may comprise a license request) from the client device 308B and send the content item 316B in response thereto.

Figure 4 is a block diagram illustrating an example of a data structure for a DSP 312 (e.g., one of DSPs 312A, 312B, 312C). As shown, DSP 312 includes a resolution requirements data structure 402, a tag requirements data structure 404, and an exceptions data structure 406.

As shown, the resolution requirements data structure 402 indicates various resolutions (SD, HD, or 4K in this example) and the requirements that a client device must meet in order for a content owner to provide content at the associated resolution level. The requirements may include hardware requirements and security requirements. For example, the hardware requirements may include the manufacturer, model, and/or other hardware identifiers of the client device. The security requirements may include at least one indicator of an operating system version, security policy, security patches, or software updates installed on the client device.

Similarly, tag requirements data structure 404 indicates tag (e.g., "new release") requirements that must be met by a client device in order for the content owner to provide content containing the indicated tag. Exceptions data structure 406 indicates various devices for which exceptions to the requirements of data structures 402, 404 may be provided. For example, a company that is both a client device manufacturer and a content owner may want to provide the highest resolution version of its content to client devices that it manufactures, even if those devices lack certain required hardware or security features.

FIG. 4 illustrates an example of a data structure for DSP 312. Other data structures for DSP 312 may be used in addition to or instead of the data structures illustrated in FIG. 4. Resolution requirements data structure 402 and tag requirements data structure 404 are illustrated as tables or two-dimensional arrays. However, other types of data structures (e.g., linked lists, stacks, queues, etc.) may be used for resolution requirements data structure 402, tag requirements data structure 404, or both.

In one example use case, a user of content owner device 302A creates DSP 312A through a graphical user interface displayed on content owner device 302A. DSP 312A specifies that to access SD content of content owner 310A, hardware A and security policy A must be present on the accessing client device. To access HD content of content owner 310A, hardware B and security policy B must be present on the accessing client device. To access 4K content of content owner 310A, hardware C and security policy C must be present on the accessing client device. To access new releases of content owner 310A, hardware D and security policy D must be present on the accessing client device. DSP 312A may also indicate exceptions for client devices of certain manufacturers. For example, client devices manufactured by manufacturer ABC will be able to access all new releases or 4K content of content owner 310A, regardless of the client device's hardware or security policy. The DSP 312A is transmitted from the content owner device 302A to the DRM server 304 and stored on the DRM server 304 in a data structure associated with the content owner 310A.

The content server 306A stores content (e.g., video and/or audio files) associated with the content owner 310A. The content server 306A sends a pull request for a DSP update to the DRM server 304. In response to the pull request for the DSP update, the DRM server 304 sends the DSP 312A to the content server 306A. The content server 306A stores the DSP 312A.

Continuing with the above example, client device 308A sends content request 314A to content server 306A to access a video DEF stored on content server 306A and associated with content owner 310A. Content request 314A indicates that client device 308A includes hardware A, security policy A, security policy B, and security policy C, and is manufactured by manufacturer ABC. Content server 306A attempts to determine if client device 308A is authorized to receive an SD, HD, or 4K version of the video DEF. Based on client device 308A's hardware (has hardware A, no hardware B, no hardware C) and client device security policy (has security policy A), content server 306A determines that client device 308A has access to the SD version of the video DEF, but not the HD and 4K versions of the video DEF. The content server 306A determines whether the video DEF has a new release tag, and if the content server 306A determines that the video DEF does not have a new release tag, the content server 306A determines that the client device 308A can still access the SD version of the video DEF, but cannot access the HD and 4K versions. The content server 306A checks the exception in the DSP 312A and determines whether the client device 308A is eligible to get the SD, HD, or 4K version of the video DEF based on the fact that the client device 308A is manufactured by manufacturer ABC.

The content server 306A determines the network speed and display capabilities of the client device 308A and determines whether to send the SD, HD, or 4K version of the video DEF to the client device. For example, upon determining that the client device 308A has a display capable of displaying SD and HD but not 4K files, and that the client device 308A is connected to a cellular network with a download speed that exceeds the minimum speed for HD transmission (e.g., 5 megabits/second), the content server 306A can provide the HD version of the video DEF to the client device 308A. If the client device 308A was manufactured by a manufacturer other than manufacturer ABC, the client device 308A would not be able to receive the HD or 4K version of the video DEF under the DSP 312A (because it does not have hardware B and hardware C), and the client device 308A would receive the SD version of the video DEF.

FIG. 5 is a flow chart illustrating an example method 500 for providing a device security profile to a content server. The method 500 may be implemented by a DRM server, such as the DRM server 304 shown in FIG. 3, one or more of the computing and communication devices 100A, 100B, 100C shown in FIG. 2, or the computing device 100 shown in FIG. 1.

In block 502, the DRM server receives data associated with a DSP (e.g., DSP 312, 312A, 312B, 312C) from a content owner device (e.g., content owner device 302A, 302B, 302C). The DSP specifies requirements for a client device (e.g., client device 308A, 308B) to access a content item associated with the content owner. The requirements vary based on the resolution level of the content item being accessed. The requirements may also vary based on the tag of the content item being accessed (e.g., "new release"). The requirements may include hardware requirements and security requirements.

In block 504, the DRM server stores an indication of the DSP and the content owner (e.g., content owners 310A, 310B, 310C). The indication of the DSP and the content owner may be stored in the memory of the DRM server (e.g., memory 110) or in a data repository (e.g., a database) in communication with the DRM server. The DSP may include a first data structure (e.g., resolution requirements data structure 402) representing resolution levels and requirements for each resolution level. The DSP may include a second data structure (e.g., tag requirements data structure 404) representing tags for the content item and requirements for each tag. The DSP may include a third data structure (e.g., exceptions data structure 406) representing device configurations for which there are exceptions to the requirements of the first data structure or the requirements of the second data structure.

In block 506, the DRM server receives a pull request for a DSP update from a content server (e.g., content server 306A) that stores content items associated with the content owner. The content server may send a pull request for a DSP update when the content server's network speed exceeds a threshold network speed, when the content server's processor load falls below a threshold load, or both. The pull request may be sent once per threshold period (e.g., once per day).

At block 508, the DRM server sends the DSP to the content server in response to the pull request. The DSP causes the content server to restrict client devices that access the content item according to the DSP. In some implementations, the DRM server receives an update to the DSP from the content owner device. The DRM server receives a second pull request from the content server. The DRM server sends an update to the DSP (or an updated version of the DSP) to the content server in response to the second pull request.

In some implementations, the DRM server pushes the DSP to the second content server. The push can occur, for example, upon failure to receive a pull request for a DSP update from the second content server that stores the content item associated with the content owner within a predefined time or defined period (e.g., one day or seven days).

Figure 6 is a flow chart illustrating an example of a method 600 for processing a content request using a device security profile. The method 600 may be implemented by a content server, such as one or more of the content servers 306A, 306B shown in Figure 3, one or more of the computing and communications devices 100A, 100B, 100C shown in Figure 2, or the computing device 100 shown in Figure 1.

In block 602, the content server receives a content owner's DSP (e.g., DSP 312, 312A, 312B, 312C). The DSP specifies requirements for client devices to access content items associated with the content owner. In some cases, the content server sends a pull request to a DRM server (DRM server 304) for a DSP update and receives the content owner's DSP in response to the pull request. Alternatively, the DSP may be pushed from the DRM server to the content server.

At block 604, the content server receives a content request (e.g., content request 314A, 314B) for a content item from a client device (e.g., client device 308A, 308B). For example, a user of the client device may direct the client device to an application or web page associated with the content server and request the content via the application or web page.

In block 606, the content server determines the resolution level of the content item (e.g., content items 316A, 316B) to provide to the client device based on the content request and the DSP. For example, the content server may compare the hardware and security status of the client device as indicated in the content request with the hardware and security requirements for providing content at various resolution levels of the DSP.

At block 608, the content server transmits the content item at the determined resolution level to the client device. The client device can play or display the content item via a user interface (e.g., user interface 130) of the client device.

In some implementations, the content server sends a second pull request to the DRM server for the DSP update. In response to the second pull request, the content server receives an updated DSP or an update to the previously stored DSP to replace the DSP. The content server replaces the DSP with the updated DSP in the content server's memory (e.g., memory 110) or the content server incorporates the update into the DSP.

FIG. 7 illustrates a GUI 700 for inputting information related to a DSP. The GUI 700 may be displayed on a content owner device 302A, 302B, 302C. As shown, the GUI 700 includes blocks for inputting a name of the DSP 702, a minimum device security level 704, a minimum version of decryption software 706, a minimum copy protection version 708, whether the make/model is verified 710, and whether copy generation management system (CGMS) output protection is required 712. The name of the DSP 702 may be any name selected by the user. The minimum device security level 704 may correspond to a minimum security level, such as an indication of security software installed on the client device. The minimum version of decryption software 706 may correspond to a version of software associated with a media player or other application for displaying content on the client device. The minimum copy protection version 708 may include a version of copy protection (e.g., High Bandwidth Digital Content Protection (HDCP)) installed on the client device. The make/model to be verified 710 can correspond to whether the content request 314A, 314B from the client device indicates the make/model of the client device. The CGMS output protection required 712 can indicate whether CGMS output protection is required on the client device.

FIG. 8 illustrates a GUI 800 for displaying device exceptions on a DSP. The GUI 800 may be displayed on a content owner device 302A, 302B, 302C. As shown, the GUI 800 includes a table of exceptions including columns for series name 802, manufacturer 804, system identifier (ID) 806, allow list status 808, and exception status 810. The GUI 800 also includes an "Add additional exception" button 812 that, when selected, allows a user to add a row to the table of exceptions. The series name 802 column displays the series name of the device to which the exception applies. The manufacturer 804 column displays the manufacturer of the device to which the exception applies. The system ID 806 column displays the system ID of the device to which the exception applies. The allow list status 808 column displays the allow list status (e.g., allowed or blocked) of the device to which the exception applies. The exception status 810 column displays whether an exception has been set for the device to which the exception applies. A user can use the drop-down menu in the Exception Status 810 column to select "Yes" or "No" (or "True" or "False" or similar options) to indicate whether the exception listed in a particular row applies.

GUIs 700, 800 show examples of information contained in a DSP's hardware profile and security profile. Not all DSPs require the information shown therein. DSPs may include different, more, or less information.

9 illustrates a GUI 900 for searching for a DSP. The GUI 900 may be displayed on a content owner device 302A, 302B, 302C. As shown, the GUI 900 includes input boxes for searching for a DSP by content provider name 902 and DSP name 904. The GUI 900 includes drop down menus for searching for a DSP by production status 906, device security level 908, decryption software version 910, and copy protection version 912. The GUI 900 includes radio buttons for selecting whether the client device make/model is verified 914, whether CGMS output protection is enabled on the client device 916, and whether known security vulnerabilities are allowed 918. The GUI 900 includes a search button 920. When the search button 920 is selected, the device displaying the GUI 900 (e.g., content owner device 302A, 302B, 302C) searches (e.g., searches in local memory or causes a search to be performed on the DRM server 304) for a DSP associated with the content owner corresponding to the device (or the account logged into the device) based on what has been entered into any of the input boxes 902, 904, the drop-down menus 906, 908, 910, 912, and the radio buttons 914, 916, 918. The search generates search results. All or a portion of the generated search results can be displayed on the device (e.g., in a list format).

Several embodiments are described below as numbered examples (Examples 1, 2, 3, etc.). These examples are provided by way of example only and are not intended to limit the disclosed technology.

Example 1 is a method that includes receiving, at a Digital Rights Management (DRM) server, data associated with a Device Security Profile (DSP) from a content owner device, where the DSP specifies requirements for client devices to access a content item associated with the content owner, the requirements varying with a resolution level of the accessed content item; storing, at the DRM server, an indication of the DSP and the content owner; receiving, from a content server that stores the content items associated with the content owner, a pull request for a DSP update; and transmitting, in response to the pull request, the DSP to the content server, where the DSP causes the content server to restrict client devices from accessing the content item according to the DSP.

In Example 2, the subject matter of Example 1 includes a subject matter in which the resolution level is based on at least one of total pixels, pixels per frame, or pixel dimension measurements.

In Example 3, the subject matter of Example 1, Example 2, or both includes subject matter having at least one of the following resolution levels: standard definition (SD), high definition (HD), or 4K.

In Example 4, the subject matter of any of Examples 1-3 includes a subject matter in which requirements vary depending on the tag of the accessed content item.

In Example 5, the subject matter of any of Examples 1 to 4 includes subject matter in which the requirements include hardware requirements and security requirements for a client device that accesses the content item.

In Example 6, the subject matter of any of Examples 1 to 5 includes a subject matter in which the DSP has a first data structure representing resolution levels and requirements for each resolution level, a second data structure representing tags for the content items and requirements for each tag, and a third data structure representing device configurations having exceptions to the requirements of the first data structure or the requirements of the second data structure.

In Example 7, the subject matter of any of Examples 1-6 includes pushing the DSP to a second content server if a pull request for a DSP update is not received within a defined period of time from a second content server that stores a content item associated with the content owner.

In Example 8, the subject matter of any of Examples 1-7 includes receiving an update to the DSP from the content owner device, receiving a second pull request from the content server, and sending the update to the DSP or an updated version of the DSP to the content server in response to the second pull request.

In Example 9, the subject matter of any of Examples 1-8 includes transmitting code to the content owner device that generates a graphical user interface (GUI) for inputting data associated with the DSP, and generating at the DRM server a DSP based on the data associated with the DSP obtained at the content owner device via the GUI.

In Example 10, the subject matter of any of Examples 1-9 includes receiving at a content server a DSP of a content owner, receiving at the content server a content request from a client device for a content item, the content item being one of the content items associated with the content owner, determining a resolution level of the content item to provide to the client device based on the content request and the DSP, and transmitting the content item from the content server to the client device at the determined resolution level.

Example 11 is a digital rights management (DRM) server including a memory for storing instructions, and a processor for executing instructions to receive data associated with a device security profile (DSP) from a content owner device, the DSP specifying requirements for a client device to access a content item associated with the content owner, the requirements varying with a resolution level of the accessed content item, the requirements including hardware and security requirements of the client device accessing the content item, instructions to store an indication of the DSP and the content owner, instructions to receive a pull request for a DSP update from a content server storing the content items associated with the content owner, and instructions to transmit the DSP to the content server in response to the pull request, the DSP causing the content server to restrict client devices from accessing the content item according to the DSP.

In Example 12, the subject matter of Example 11 includes a subject matter in which the resolution level is based on at least one of total pixels, pixels per frame, or pixel dimension measurements.

In Example 13, the subject matter of Example 11, Example 12, or both includes subject matter having at least one of the following resolution levels: standard definition (SD), high definition (HD), or 4K.

In Example 14, the subject matter of any of Examples 11-13 includes a subject matter in which requirements vary depending on the tag of the accessed content item.

In Example 15, the subject matter of any of Examples 11 to 14 includes a subject matter in which the DSP has a first data structure representing resolution levels and requirements for each resolution level, a second data structure representing tags for the content items and requirements for each tag, and a third data structure representing device configurations having exceptions to the requirements of the first data structure or the requirements of the second data structure.

In Example 16, the subject matter of any of Examples 11 to 15 includes subject matter in which the processor executes instructions to push the DSP to a second content server if the processor fails to receive a pull request for a DSP update from a second content server that stores a content item associated with the content owner within a predetermined time.

In Example 17, the subject matter of any of Examples 11 to 16 includes subject matter in which a processor executes instructions to receive an update to the DSP from the content owner device, instructions to receive a second pull request from the content server, and instructions to send the update to the DSP or an updated version of the DSP to the content server in response to the second pull request.

In Example 18, the subject matter of any of Examples 11 to 17 includes subject matter that executes instructions to send code to the content owner device that generates a graphical user interface (GUI) for inputting data associated with the DSP, and instructions to generate in the DRM server a DSP based on data associated with the DSP obtained in the content owner device via the GUI.

Example 19 is a non-transitory computer-readable medium storing instructions operable by a processor to perform operations including: receiving, at a digital rights management (DRM) server, data associated with a device security profile (DSP) from a content owner device, the DSP specifying requirements for client devices to access a content item associated with the content owner, the requirements varying depending on a resolution level of the accessed content item, the resolution level being based on at least one of a total number of pixels, a number of pixels per frame, or pixel dimension measurements; storing, at the DRM server, an indication of the DSP and the content owner; receiving, from a content server storing the content items associated with the content owner, a pull request for a DSP update; and transmitting, in response to the pull request, the DSP to the content server, the DSP causing the content server to restrict client devices from accessing the content item according to the DSP.

In Example 20, the subject matter of Example 19 includes a subject matter having at least one of the following resolution levels: standard definition (SD), high definition (HD), or 4K.

In example 21, the subject matter of example 19, example 20, or both includes subject matter having different requirements depending on the tag of the accessed content item.

In Example 22, the subject matter of any of Examples 19-21 includes a subject matter in which the requirements include hardware requirements and security requirements for a client device that accesses the content item.

Example 23 is a method that includes receiving, at a content server, a device security profile (DSP) of a content owner, the DSP specifying requirements for a client device to access a content item associated with the content owner, the requirements varying depending on the resolution of the accessed content item; receiving, at the content server, a content request for the content item from the client device; determining a resolution level of the content item to provide to the client device based on the content request and the DSP; and transmitting the content item at the determined resolution level to the client device.

In example 24, the subject matter of example 10 or example 23 includes sending a pull request for a DSP update and receiving the content owner's DSP in response to the pull request.

In Example 25, the subject matter of Example 24 includes sending a second pull request for the DSP update, receiving an updated DSP in response to the second pull request that replaces the DSP or the update to the DSP, and replacing the DSP with the updated DSP or incorporating the update into the DSP in a memory of the content server.

In Example 26, the subject matter of any of Examples 10 or 23-25 includes a subject matter having at least one of the following resolution levels: standard definition (SD), high definition (HD), or 4K.

In Example 27, the subject matter of any of Examples 10 or 23-26 includes subject matter in which requirements vary depending on the tag of the accessed content item.

In Example 28, the subject matter of any of Examples 10 or 23 to 27 includes a subject matter in which the requirements include hardware requirements and security requirements.

In Example 29, the subject matter of any of Examples 10 or 23-28 includes a subject matter in which the DSP has a first data structure representing resolution levels and requirements for each resolution level, a second data structure representing tags for the content items and requirements for each tag, and a third data structure representing device configurations having exceptions to the requirements of the first data structure or the requirements of the second data structure.

Example 30 is a content server including a memory for storing instructions, and a processor that executes instructions to receive a device security profile (DSP) of a content owner, the DSP specifying requirements for a client device to access a content item associated with the content owner, the requirements varying depending on the resolution of the accessed content item, instructions to receive a content request from the client device for the content item, instructions to determine a resolution level of the content item to provide to the client device based on the content request and the DSP, and instructions to transmit the content item to the client device at the determined resolution level.

In example 31, the subject matter of example 30 includes subject matter in which a processor executes instructions to send a pull request for a DSP update, and in response to the pull request, a DSP of the content owner is received.

In Example 32, the subject matter of Example 31 includes the subject matter of the processor executing instructions for sending a second pull request for the DSP update, receiving an updated DSP in response to the second pull request that replaces the DSP or the update to the DSP, and, in a memory of the content server, instructions for replacing the DSP with the updated DSP or incorporating the update into the DSP.

In Example 33, the subject matter of any of Examples 30 to 32 includes a subject matter having at least one of the following resolution levels: standard definition (SD), high definition (HD), or 4K.

In Example 34, the subject matter of any of Examples 30-33 includes a subject matter in which requirements vary depending on the tag of the accessed content item.

In Example 35, the subject matter of any of Examples 30 to 34 includes a subject matter in which the requirements include hardware requirements and security requirements.

In Example 36, the subject matter of any of Examples 30 to 35 includes a subject matter in which the DSP has a first data structure representing resolution levels and requirements for each resolution level, a second data structure representing tags for the content items and requirements for each tag, and a third data structure representing device configurations having exceptions to the requirements of the first data structure or the requirements of the second data structure.

Example 37 is a non-transitory computer-readable medium storing instructions that operate a processor to perform operations including receiving at a content server a device security profile (DSP) of a content owner, the DSP specifying requirements for a client device to access a content item associated with the content owner, the requirements varying depending on the resolution of the accessed content item; receiving at the content server a content request for the content item from the client device; determining a resolution level of the content item to provide to the client device based on the content request and the DSP; and transmitting the content item at the determined resolution level to the client device.

In Example 38, the subject matter of Example 37 includes the subject matter of operations including sending a pull request for a DSP update, where a content owner's DSP is received in response to the pull request.

In Example 39, the subject matter of Example 38 includes a subject matter of operations that includes sending a second pull request for the DSP update, receiving an updated DSP in response to the second pull request that replaces the DSP or the update to the DSP, and replacing the DSP with the updated DSP or incorporating the update into the DSP in the memory of the content server.

In Example 40, the subject matter of any of Examples 37 to 39 includes a subject matter having at least one of the following resolution levels: standard definition (SD), high definition (HD), or 4K.

In Example 41, the subject matter of any of Examples 37-40 includes a subject matter in which requirements vary depending on the tag of the accessed content item.

In Example 42, the subject matter of any of Examples 37 to 41 includes a subject matter in which the requirements include hardware requirements and security requirements.

Example 43 is a system including a processing circuit configured to perform the method described in any of Examples 1 to 10 or 23 to 29.

The words "example," "embodiment," and "aspect" are used herein to mean serving as an example, illustration, or illustration. Any aspect or design described herein as an "example," "embodiment," or "aspect" should not necessarily be construed as preferred or advantageous over other aspects or designs. Rather, the use of these words is intended to present concepts in a concrete manner. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or." That is, unless otherwise specified or clear from the context, "X includes A or B" is intended to mean a natural inclusive permutation. That is, if X includes A, if X includes B, or if X includes both A and B, then "X includes A or B" is satisfied in each of the foregoing cases. Furthermore, the articles "a" and "an" used in this application and the appended claims should generally be construed to mean "one or more" unless otherwise specified or clear from the context to refer to the singular form. Additionally, all uses of the terms "embodiment" or "implementation" are not intended to refer to the same embodiment or implementation unless described as such. As used herein, the terms "determine" and "identify," or any variations thereof, include selecting, ascertaining, calculating, searching, receiving, determining, establishing, obtaining, or otherwise identifying or determining using one or more devices shown in FIG. 1.

In addition, although for simplicity of illustration, the figures and descriptions herein may include a sequence of steps or acts, elements of the methods disclosed herein may occur in various orders and/or simultaneously. Moreover, elements of the methods disclosed herein may occur with other elements not explicitly shown and described herein. Moreover, one or more elements of the methods described herein may be omitted from embodiments of methods in accordance with the disclosed subject matter.

Implementations of the transmitting computing and communication device 100A and/or the receiving computing and communication device 100B (and algorithms, methods, instructions, etc. stored therein and/or executed by it) can be realized in hardware, software, or any combination thereof. Hardware can include, for example, computers, intellectual property (IP) cores, application specific integrated circuits (ASICs), programmable logic arrays, optical processors, programmable logic controllers, microcode, microcontrollers, servers, microprocessors, digital signal processors, or any other suitable circuitry. In the claims, the term "processor" should be understood to include any of the aforementioned hardware, alone or in combination. The terms "signal" and "data" are used interchangeably. Furthermore, each part of the transmitting computing and communication device 100A and the receiving computing and communication device 100B does not necessarily have to be implemented in the same way.

Furthermore, in some implementations, for example, the transmitting computing and communication device 100A or the receiving computing and communication device 100B may be implemented using a computer program that, when executed, performs any of the respective methods, algorithms, and/or instructions described herein. Additionally or alternatively, a special purpose computer/processor may be utilized that may include, for example, specialized hardware for performing any of the methods, algorithms, or instructions described herein.

Furthermore, all or a portion of the embodiments may take the form of a computer program product accessible, for example, from a tangible computer usable medium or computer readable medium. A computer usable medium or computer readable medium is, for example, any device that can tangibly store, store, communicate, or transfer a program for use by or in connection with any processor. Media may include, for example, electronic, magnetic, optical, electromagnetic, or semiconductor devices. Other suitable media may also be utilized.

It will be appreciated that aspects may be implemented in any convenient form. For example, aspects may be implemented by a suitable computer program, which may be carried on a suitable carrier medium, which may be a tangible carrier medium (e.g., a disk) or an intangible carrier medium (e.g., a communication signal). Aspects may also be implemented using a suitable apparatus, which may take the form of a programmable computer executing a computer program configured to implement the methods and/or techniques disclosed herein. Aspects may be combined such that functionality described in the context of one aspect may be implemented in another aspect.

The above embodiments are set forth to facilitate understanding of the present application and are not intended to be limiting. Rather, the present application encompasses various modifications and equivalent arrangements that fall within the scope of the appended claims, which scope should be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures permitted by law.

Claims (12)

receiving, at a Digital Rights Management (DRM) server, data associated with a Device Security Profile (DSP) from a content owner device, the DSP specifying requirements for a client device to access a content item associated with the content owner, the requirements varying depending on a resolution level of the content item being accessed;
storing, at the DRM server, the DSP and an indication of the content owner;
receiving a pull request for a DSP update from a content server that stores the content item associated with the content owner;
and sending the DSP to the content server in response to the pull request, the DSP configured to cause the content server to restrict access to the content item by client devices in accordance with the DSP. The method of claim 1, wherein the resolution level is based on at least one of a total number of pixels, a number of pixels per frame, or a pixel dimension measurement. The method of claim 1 , wherein the resolution levels include at least one of standard definition (SD), high definition (HD), or 4K. The method of claim 1 , wherein the requirements vary depending on a tag of the accessed content item. 2. The method of claim 1, wherein the requirements for the client devices include at least one requirement selected from the group consisting of hardware requirements, security requirements, or a combination thereof for each client device that accesses a content item of the content items. The DSP includes:
a first data structure representing resolution levels and the requirements for each resolution level;
a second data structure representing tags of content items and the requirements for each tag;
and a third data structure representing device configurations having exceptions to the requirements of the first data structure or the requirements of the second data structure. 2. The method of claim 1, further comprising: pushing the DSP to a second content server if a pull request for the DSP update is not received within a predetermined time from a second content server that stores the content item associated with the content owner. receiving updates to the DSP from the content owner device;
receiving a second pull request from the content server;
sending the update to the DSP or an updated version of the DSP to the content server in response to the second pull request;
The method of claim 1 , comprising: sending to the content owner device code for generating a graphical user interface (GUI) for inputting the data associated with the DSP;
and generating , at the DRM server, the DSP based on the data associated with the DSP obtained at the content owner device via the GUI. receiving, at the content server, the DSP associated with the content owner;
receiving, at the content server, a content request from a client device for a content item, the content item being one of the content items associated with the content owner;
determining a resolution level of the content item for provision to the client device based on the content request and the DSP;
and transmitting the content item from the content server to the client device at the determined resolution level. at least one memory for storing instructions;
and at least one processor configured to execute said instructions to perform the method of any one of claims 1 to 10. A computer readable storage medium storing instructions operable to cause one or more processors to perform the method of any one of claims 1 to 10.