UNIFIED VIDEO PROVISIONING WITHIN A HETEROGENEOUS NETWORK ENVIRONMENT

A video provisioning system may receive a video asset from one or more content providers. The video provisioning system may process the video asset to allow the video asset to be provided to a set top box and another device that is a different type of device than the set top box. The video provisioning system may further provide the video asset to the set top box and the other device.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Patent Application No. 61/387,939, filed Sep. 29, 2010, the entire contents of the provisional application being incorporated herein by reference.

BACKGROUND

Users, of user devices, have a growing array of sources, networks, and/or content providers from which to obtain video content and/or services. The users may use video client devices (e.g., a set top box, etc.) to obtain free broadcast television video content (e.g., from Fox, ABC, CBS, etc.), on-demand video content (e.g., Video On-Demand (VOD), pay-per-view (PPV), etc.), and/or pay television video content (e.g., from HBO, Cinemax, etc.) from cable television operators (e.g., Comcast, Time Warner, etc.) and/or satellite television operators (e.g., DirectTV, Dish Network, etc.). The users may use computer devices, wireless mobile devices, etc. to obtain other video content from on-line content providers, such as television operators (e.g., ABC, Fox, CBS, etc.), over-the-top (OTT) content providers (e.g., Hulu, Veoh, Jaman, YouTube, etc.), and/or other commercial content providers (e.g., Apple Computer's iTunes, Netflix, Blockbuster, etc.).

Unfortunately, the users use different types of user devices to access and/or obtain video content from the array of sources, networks, and/or content providers. Pricing, availability, and/or accessibility for the video content is usually unique depending on a particular source, network, and/or content provider from which the video content is obtained. Additionally, the pricing, availability, and/or accessibility usually depends on the particular type of user device for which the services are obtained and/or via which type of network (e.g., cable television, satellite television, Internet, wireless service provider, etc.) the video content downloaded.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an example overview of a video provisioning system in which systems and/or methods, described herein, may be implemented;

FIG. 2 is a diagram of an example environment in which the systems and/or methods, described herein, may be implemented;

FIG. 3 is a diagram of example devices, associated with the video provisioning system, of FIG. 2;

FIG. 4 is a diagram of example components that correspond to one or more of the devices of FIGS. 2 and/or 3;

FIG. 5 is a diagram of an example data structure that stores metadata associated with video content;

FIG. 6 is a flow chart of an example process for ingesting and/or processing video content within a video provisioning system;

FIG. 7 is a flow chart of an example process for registering a user device with a video provisioning system;

FIG. 8 is a flow chart of an example process for provisioning common video services to various types of user devices; and

FIGS. 9A-9C are diagrams of example user devices that are displaying a video asset as a result of interacting with the video provisioning system to obtain the video asset according to an implementation described herein.

 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.

Systems and/or methods, described herein, may enable video content to be formatted for and/or provisioned to various types of user devices over various types of networks. The systems and/or methods may enable the video content to be provisioned with a uniform price, availability, and/or accessibility, regardless of a type of network via which the video content is being provisioned and/or a type of user device for which the video content is obtained. Thus, video content may be provisioned for computer devices (e.g., desktop computers, laptop computers, and tablet computers), wireless handheld devices (e.g., mobile phones, smart phones, personal digital assistants (PDAs), and tablet computers), and set top boxes.

The video content may be provisioned to the computer devices, wireless handheld devices, and/or set top boxes via a federated network environment that includes a number of different types of networks, such as, for example, a wired network, a wireless network, a broadband network, a cellular telephone network, a television network, etc., and/or some combination thereof. For example, video content may be provisioned to a set top box via a managed television network that transmits the video content (e.g., via a video stream) to the set top box. The managed television network may stream the video content using, for example, a conditional access encryption technique. The managed television network may provide the video content to the set top box in a manner that conforms to a particular quality of service (QoS) level, data rate, etc.

In another example, the video content may be provisioned to a computer device, associated with a user of the set top box, via a broadband network (e.g., via progressive download, adaptive bit rate streaming, etc.), such as, for example, the Internet. The video content, in this example, may be encrypted using another encryption technique (e.g., based on digital rights management and/or some other technique) and/or another QoS level (e.g., best efforts and/or some other QoS level) associated with the broadband network. In yet another example, the video content may be provisioned to a wireless handheld device, associated with the user, via a wireless network (e.g., via progressive download, adaptive bit rate streaming, etc.). The video content, in this example, may be encrypted using a further encryption technique (e.g., based on digital rights management and/or some other technique) and/or a further QoS level (e.g., best efforts or some other QoS level) associated with the wireless network and/or a type of wireless handheld device.

The term video content, as used herein, may include one or more video assets, metadata associated with the video assets, and/or information associated with digital rights management (DRM) that corresponds to the video assets. The video assets may include Video On-Demand (VOD) video content, pay-per-view (PPV) video content, rented video content, free television content (e.g., from free television broadcasters, etc.), paid for television content (e.g., from pay television content providers), on-line video content (e.g., on-line television programs, movies, videos, etc.), advertising, games, music videos, promotional information (e.g., such as previews, trailers, etc.), etc. The information associated with the DRM may include license information that identifies terms and/or conditions for handling, promoting, distributing, and/or using the video assets and/or enables video assets to be encrypted and/or decrypted (e.g., based on keys associated with the license information).

The metadata may enable the video assets to be identified, managed, merchandized, and/or distributed to a user device. The metadata may, for example, include an identifier associated with a video asset (e.g., a number, a name, a title, etc.); a genre of the video asset (e.g., horror, comedy, adult, etc.); a category of the video asset (e.g., VOD asset, a PPV asset, etc.); a text description of the video asset; and/or information associated with artists associated with the video asset (e.g., names of actors, directors, producers, etc.). The metadata may also, or alternatively, include information associated with a type of video asset (e.g., a movie, music video, a game, etc.); a rating associated with the video asset (e.g., general audience (G), parental guidance (PG), PG-13, restricted (R), mature audience (MA), etc.); user reviews associated with the video asset; a price associated with the video asset (e.g., a sale price, a rental price per day, a pay-per-view price, etc.); and/or an availability period associated with the video asset (e.g., release dates, restriction periods, blackout periods, etc.). The metadata may also, or alternatively, include information associated with a storage location (e.g., a uniform resource locator (URL)) corresponding to the video asset; a format associated with the video asset (e.g., a resolution level, compression/decompression (CODEC) information, a screen size, a frame size, a frame refresh rate, a bit rate, etc.); and/or types of user devices supported by each format, etc.

FIG. 1 is a diagram of an example overview of a video provisioning system (VPS) in which systems and/or methods, described herein, may be implemented. As shown in FIG. 1, a VPS may receive (sometimes referred to as “ingest”) video content from one or more content providers. The VPS may connect to a collection of user devices associated with a user, such as, for example, a set top box, a computer device, a wireless handset (e.g., a smart phone, a personal digital assistant (PDA), etc.), and/or other types of user devices. The VPS may connect to the set top box via a television network (e.g., a cable television network, a satellite television network, a fiber optic television network, or some combination thereof). The VPS may connect to the computer device via a broad band network (e.g., via the Internet). The VPS may connect to the wireless handset via a wireless service provider network.

The VPS may process video assets, obtained from the ingested video content, in a manner that is supported (e.g., can be received, processed, stored, played and/or rendered for display) by each of the different user devices. For example, the VPS may generate copies of the video assets based on one or more video profiles. The video profiles may identify a type of user device 210 for which the video asset is intended (e.g., a set top box, a computer device, a wireless handheld device, a gaming device, etc.), type of format (e.g., a bit rate, a resolution level, a frame refresh rate, a CODEC, etc.) supported by user device 210, an encryption technique, etc. The VPS may convert each of the copies of the video assets into different formats based on the video profiles. A copy of a video asset may be generated based on one video profile that is supported by the set top box. Another copy of the video asset may be generated based on another video profile that is supported by the computer device. A further copy of the video asset may be generated based on a further video profile that is supported by the wireless mobile handset and/or another type of user device. The VPS may store the copies of the video assets within a memory, storage device, and/or content distribution network associated with the VPS.

The VPS may process metadata obtained from the ingested video content and may publish the processed metadata to a catalog. The processed metadata may include cover art, descriptions of the video assets, prices (e.g., a purchase price, a rental price, a pay-per-view (PPV) price, a subscription price, etc.), etc. that are converted to formats that the user devices can process and/or display. The VPS may use the metadata to manage the availability of the video assets and may establish the one or more prices to ensure settlement costs (e.g., associated with content providers, etc.), operating costs, expenses, profit, etc. are covered by the prices. The catalog may establish bundled offerings (e.g., offerings that include one or more video assets, services, etc.) for a bundled price usually for a limited period of time.

The VPS may publish a portion of the processed metadata, that corresponds to available video assets, to a VPS store front. The VPS store front may be a portal (e.g., a webpage, user interface, an interactive media guide (IMG), etc.) that enables each of the different user devices to access a common list of titles, prices, etc. associated with the video assets that are available to be obtained by a user device.

A user device (e.g., the set top box) may access the store front and may select metadata associated with a video asset (e.g., a title, an identifier, etc.). The VPS may retrieve a copy of the video asset, associated with a format that is supported by the user device, and may transmit the copy of the video asset to the user device. The VPS store front may process payment information for the video asset (e.g., as a purchase, rental, pay-per-view, etc.) and/or may cause the selection of the video asset to be added to a bill associated with the user device. Another user device (e.g., the computer device), associated with a user of the user device, may access the store front and may select the video asset. The VPS may retrieve another copy of the video asset, associated with another format that is supported by the other user device, and may transmit the other copy of the video asset to the other user device at no additional cost. The VPS may also, or alternatively, maintain a bookmark for the video asset. The bookmark may identify a point at which the user device stopped playing the copy of the video asset before the copy of the video asset was finished playing on the user device. The VPS may use the bookmark to provide the other copy of the video asset, at another point that corresponds to the point at which the user device stopped the copy of the video asset, to the other user device. Thus, the other user device may resume playing of the video asset at the exact point where the playing of the video asset, by the user device, was stopped.

FIG. 2 is a diagram of an example environment 200 in which systems and/or methods, described herein, may be implemented. As shown in FIG. 2, environment 200 may include a group of user devices 210-1, . . . , 210-J (where J≧1) (hereinafter referred to collectively as “user devices 210” and individually as “user device 210”), a video provisioning system (VPS) 220, a group of content providers 230-1, . . . , 230-K (where K≧1) (hereinafter referred to collectively as “content providers 230” and individually as “content provider 230”), a service provider network 240, and a network 250. The number of devices, systems, and/or networks, illustrated in FIG. 2, is provided for explanatory purposes only. In practice, there may be additional devices, systems, and/or networks; fewer devices, systems, and/or networks; different devices, systems, and/or networks; or differently arranged devices, systems, and/or networks than illustrated in FIG. 2.

Also, in some implementations, one or more of the devices of environment 200 may perform one or more functions described as being performed by another one or more of the devices of environment 200. Devices, systems, and/or networks of environment 200 may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

User device 210 may include a computation or communication device that is capable of communicating with service provider network 240. For example, user device 210 may include a radiotelephone, a personal communications system (PCS) terminal (e.g., that may combine a cellular radiotelephone with data processing and data communications capabilities), a personal digital assistant (PDA) (e.g., that can include a radiotelephone, a pager, Internet/intranet access, etc.), a laptop computer, a tablet computer, a set top box, a digital video recorder (DVR), a personal gaming system, a smart phone, or another type of computation or communication device.

User device 210 may host a media manager application (hereinafter referred to as “media application”) that enables user device 210 to communicate with VPS 220 and/or to perform certain operations to obtain video content from VPS 220. For example, the media application may enable user device 210 to access a portal (e.g., a website, a user interface, an IMG, etc.) associated with VPS 220, to browse, search, select, and/or obtain a video asset in exchange for payment (e.g., as a purchase, rental, pay-per-view, subscription, etc.). The media application may manage information associated with DRM with respect to the video asset and may use license information, obtained from VPS 220, to decrypt the video asset for playing on user device 210. The media application may bookmark a location at which user device 210 stopped playing the video asset and may transmit the bookmarked location to VPS 220. Another user device 210, associated with the user, may obtain a copy of the video asset from VPS 220 and may resume playing the video asset based on the bookmarked location obtained from VPS 220.

The media application may permit a particular type of user device 210 (e.g., a wireless mobile handset device associated with user device 210-J) to obtain the video asset from another type of computer device 210 (e.g., a computer device associated with user device 210-3) via a side loading operation (e.g., via a wired and/or wireless connection) instead of, or in addition to, obtaining the video asset from VPS 220.

VPS 220 may include one or more devices that gather, process, search, store, and/or provide information in a manner similar to that described herein. VPS 220 may be capable of communicating with content providers 230 via network 250 and/or user devices 210 via service provider network 240. VPS 220 may perform operations associated with video content ingestion, processing, and distribution for one or more types of user devices 210, associated with a user, within environment 200.

Content provider 230 may include any type or form of content provider. For example, content provider 230 may include free television broadcast providers (e.g., local broadcast providers, such as NBC, CBS, ABC, and/or Fox), for-pay television broadcast providers (e.g., TNT, ESPN, HBO, Cinemax, CNN, etc.), and/or Internet-based content providers (e.g., Youtube, Vimeo, Netflix, Hulu, Veoh, etc.) that stream content from web sites and/or permit content to be downloaded (e.g., via progressive download, etc.). Content provider 230 may include on-demand content providers (e.g., VOD, PPV, etc.). A media stream, as used herein, may refer to a stream of content that includes video content (e.g., a video stream), audio content (e.g., an audio stream), and/or textual content (e.g., a textual stream).

Service provider network 240 may include one or more wired and/or wireless networks via which user devices 210 communicate with and/or receive video content from VPS 220. For example, service provider network 240 may include a cellular network, the Public Land Mobile Network (PLMN), a second generation (2G) network, a third generation (3G) network, a fourth generation (4G) network (e.g., a long term evolution (LTE) network), a fifth generation (5G) network, and/or another network. Additionally, or alternatively, service provider network 240 may include a code division multiple access (CDMA) network, a global system for mobile communications (GSM) network, a general packet radio services (GPRS) network, or a combination of CDMA, GSM, and/or GPRS networks. Additionally, or alternatively, service provider network 240 may include a wide area network (WAN), a metropolitan area network (MAN), an ad hoc network, an intranet, a fiber optic-based network (e.g., a fiber optic service (FiOS) network), a television network, and/or a combination of these or other types of networks.

Network 250 may include one or more wired and/or wireless networks. For example, network 250 may include a cellular network, the PLMN, a 2G network, a 3G network, a 4G network (e.g., an LTE network), a 5G network, and/or another network. Additionally, or alternatively, network 250 may include a WAN, a MAN, a telephone network (e.g., the Public Switched Telephone Network (PSTN)), an ad hoc network, an intranet, the Internet, a fiber optic-based network, and/or a combination of these or other types of networks.

FIG. 3 is a diagram of example devices associated with VPS 220. VPS 220 may include an application server 315, an interactive media guide (IMG) server 320, a video on-demand (VOD) server 325, a content delivery network (CDN) server 330, a catalog server 335, a video content management (VCM) server 340, a profile server 345, and a billing server 350. Although FIG. 3 shows example devices of VPS 220, in other implementations, VPS 220 may include fewer devices, additional devices, different devices, or differently arranged devices than depicted in FIG. 3. Additionally, or alternatively, one or more devices of VPS 220 may perform one or more tasks described as being performed by one or more other devices of VPS 220.

In the description below, VOD server 325 is described as provisioning video services for a type of user device 210 (i.e., a set top box) and CDN server 330 is described as provisioning video services for another other type of user device 210 (i.e., a computer device, a wireless mobile device, etc.) for explanatory purposes. In another implementation, the video services may be provisioned for the set top box and/or the other types of user devices in a number of ways. For example, VOD server 325 and/or CDN server 330 may be combined into a single device that provisions the video services for each type of user device 210. In another example, the video services may be provisioned, for each type of user device 210, by another device and/or network instead of, or in combination with, VOD server 325 and/or CDN server 330. Additionally, IMG server 320 is described as providing an a store front portal (i.e., via an IMG), that can be accessed by the set top box, and application server 315 is described as providing another store front portal (e.g., via a web page, a user interface, an interactive program guide, etc.), that can be accessed by the other types of user devices, for explanatory purposes. In another implementation, the store front portal may be provisioned for the set top box and/or the other types of user devices in a number of ways. For example, IMG server 320 and/or application server 315 may be combined into a single device that provisions the store front portal for each type of user device 210. In another example, the store front portal may be provisioned, for each type of user device 210, by another device and/or network instead of, or in combination with, IMG server 320 and/or application server 315. Thus, the examples below are provided for explanatory purposes only.

Application server 315 may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner similar to that described herein. Application server 315 may receive metadata that has been published by catalog server 335. The metadata may be associated with video assets that are to be made available and/or offered (e.g., for sale, rent, subscription, etc.) to user devices 210. Application server 315 may host a portal (e.g., a VPS store front), such as a private website (e.g., for subscribing user devices 210), a public website (e.g., for non-subscribing user devices 210), a user interface (UI) (e.g., that is accessible by wireless mobile handset-type user devices 210, etc.), an interactive program guide (e.g., an IMG for set top box-type user devices 210) and/or other types of user interfaces. The portal may enable single sign-on (SSO) portal access, to a user of one or more user devices 210, based on the same login credentials (e.g., username, password, personal identification number (PIN), etc.). Application server 315 may publish all or a portion of the metadata to the portal that permits any of user devices 210 to browse, perform searches, process payment, etc. for video assets based on the metadata that is published to the portal.

Application server 315 may perform a session management operation that authenticates user device 210 when user device 210 attempts to access the store front portal. Application server 315 may retrieve, from profile server 345, information relating to a profile associated with a user of one or more user devices 210. Application server 315 may obtain, from the information associated with the profile, information associated with a type of user device 210, a video format (e.g., screen size, bit rate, frame size, a frame reset rate, etc.) supported by user device 210, parental controls specified by the user, a transaction history associated with the user, a bookmark associated with a video asset, etc.

Application server 315 may permit user device 210 to browse and/or search video assets provided by VPS 220. Application server 315 may permit user device 210 to preview a trailer associated with a video asset and/or to select a video asset via the portal. Application server 315 may store information associated with the selected video asset in a logical shopping cart and/or electronic invoice. Application server 315 may recommend other video assets based on information associated with the transaction history and/or the parental controls. Application server 315 may perform an electronic transaction that permits user device 210 to purchase, rent, etc. a selected video asset (e.g., that was stored in the logical shopping cart), purchase a subscription for one or more video assets, bundles, etc. Application server 315 may, in one example, process payment information obtained from the information associated with the profile. Application server 315 may, in another example, send a notification, to billing server 350, that includes information associated with the transaction and which enables billing server 350 to include a cost of the transaction in an account associated with user device 210.

Application server 315 may send a notification to catalog server 335 that identifies the selected video content. The notification may include an indication of the type of user device 210 and/or information associated with the video format that user device 210 supports. Application server 315 may send an indication, to profile server 345, that the transaction associated with the selected video content was executed. The indication may enable other user devices 210, associated with the user, to obtain a copy of the selected video (e.g., in a video format supported by the other user devices 210) content at no additional cost to the user.

IMG server 320 may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner similar to that described herein. IMG server 320 may, for example, process metadata, that has been published by catalog server 335 and/or VOD server 325, in a manner similar to that described above (e.g., with respect to application server 315). The metadata may be associated with video content that may be obtained by a particular type of user device 210, such as a set top box user device 210.

IMG server 320 may publish all or a portion of the metadata to an IMG user interface (UI) that the set top box user device 210, associated with the user, may render for display on a video display device. IMG server 320 may permit the set top box user device 210 to access information associated with video assets, stored by VOD server 325, and access the actual video assets. IMG server 320 may, in another example implementation, communicate with application server 315, which may permit the set top box user device 210 to access the metadata associated video assets that are stored in CDN server 330.

IMG server 320 may receive a selection of a video asset (e.g., via the IMG) and may communicate with application server 315 in order to perform a session management operation, an electronic transaction, and/or a billing operation in a manner similar to that described above. IMG server 320 may communicate with VOD server 325 that causes the selected video asset to be transmitted (e.g., as a video stream) to the set top box user device 210. IMG server 320 may send an indication, to profile server 345, that the transaction associated with the selected video content was executed. The indication may enable other user devices 210, associated with the user, to obtain a copy of the selected video asset (e.g., in a video format supported by the other user devices 210) at, for example, no additional cost to the user.

VOD server 325 may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner similar to that described herein. VOD server 325 may, for example, perform operations to receive, store, process, and/or distribute video content in a format that is supported by set top box user devices 210.

VOD server 325 may receive published video assets and/or metadata from VCM server 340. VOD server 325 may store the published video assets in a memory associated with VOD server 325. VOD server 325 may manage a catalog that includes metadata associated with video assets received from VCM server 340. VOD server 325 may publish a portion of the metadata, associated with video assets (e.g., that are available for release and/or not subject to a blackout, etc.), to IMG server 320 that enables the catalog to be accessed, via the IMG, by set top box user devices 210.

VOD server 325 may respond to requests for selected video assets. VOD server 325 may receive, from IMG 320, an indication that a set top box user device 210 has selected a video asset via the IMG. VOD server 325 may, in response to the indication, forward information associated with the selected video asset, such as, for example, an identifier associated with the selected video asset (e.g., a title asset identifier (PAID)), information associated with content provider 230 (e.g., a provider identifier (PID)) from which the selected video asset was obtained, etc., to the set top box user device 210 via IMG server 320. VOD server 325 may receive, from the set top box user device 210, a request for the selected video asset and may transmit (e.g., via streaming video) the selected video asset to the set top box user device 210. The request may include the information associated with the selected video asset, the information associated with content provider 230, etc. The selected video asset may be encrypted (e.g., based on CAS-based encryption techniques) as the VOD server 325 is streaming the selected video asset to the set top box. The selected asset may be transmitted to the set top box in a manner that conforms to a particular QoS.

CDN server 330 may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner similar to that described herein. CDN server 330 may, for example, perform operations to receive, store, process, and/or distribute video content in a format that is supported by one or more types of user devices 210 (e.g., a computer device, a wireless mobile device, a gaming device, etc.) other than, or in addition to, a set top box user device 210. CDN server 330 may actually represent a content delivery network that includes multiple routing and/or storage devices.

CDN server 330 may receive published video assets in multiple video formats from VCM server 340. CDN server 330 may store the published video assets in a memory associated with CDN server 330. CDN server 330 may identify a respective storage location and/or URL for each format of each video asset that are stored within the memory and may send information associated with the storage locations and/or the URLs to catalog server 335.

CDN server 330 may respond to requests for selected video assets. CDN server 330 may receive, from user device 210, a request for a video asset based on a URL associated with the request. CDN server 330 may retrieve the video asset that is based on a particular video format that corresponds to the URL and may transmit the retrieved video asset to user device 210. CDN server 330 may transmit the video asset, that has been pre-encrypted by VCM server 340 (e.g., based on DRM-based encryption techniques), to user device 210. The selected asset may be transmitted (e.g., based on a progressive download protocol, adaptive bit rate streaming protocol, and/or some other protocol) to user device 210 in a manner that conforms to another QoS (e.g., best efforts).

Catalog server 335 may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner similar to that described herein. Catalog server 335 may, for example, receive, from VCM server 340, published metadata associated with video content that has been published to VOD server 325 and/or CDN server 330. Catalog server 335 may process and/or package the metadata in order to merchandize the video content to which the metadata corresponds.

Catalog server 335 may, for example, obtain metadata for a video asset that includes, for the video asset, an identifier (e.g., a title, etc.), a description, a genre, casting information (e.g., actors, directors, producer, etc.), ratings, reviews, etc. Catalog server 335 may merchandize the video asset by associating one or more prices to the metadata for the video asset. The prices may include a rental price (e.g., a price per single viewing, a price per day, per week, etc.), a sale price, a subscription price, etc. Catalog server 335 may associate the metadata, for the video asset, with other metadata, for other video assets, to create a service bundle (e.g., that includes the video asset and one or more other video assets and/or services) and may associate another price for the sale, rental, subscription, etc. of the service bundle. Catalog server 335 may identify a price to cover costs associated with the video asset (e.g., a settlement cost to be paid to content provider 230 who provided the video asset, costs associated with service provider network 240, expected profit, etc.).

Catalog server 335 may identify, from the metadata, information associated with the availability of the video asset based on a date on which the video asset is released, blacked out, etc. Catalog server 335 may publish the metadata, associated with the merchandized video assets, to the store front portal associated with VPS application 315. Catalog server 335 may not publish metadata associated with video assets that are identified as not yet being available. Catalog server 335 may publish other metadata associated with service bundles, promotions, recommendations, etc. to the store front portal.

Catalog server 335 may associate information associated with DRM with the metadata associated with the merchandized assets. For example, catalog server 335 may associate information associated with a license and/or a key (e.g., a private key, a public key, a CODEC, etc.) with the metadata for the merchandized video asset and may store the information associated with the license and/or the key in a memory associated with catalog server 335. The key may enable the video asset to be decrypted (e.g., by user device 210) when the information associated with the license indicates that the video asset can be decrypted and/or is otherwise available. Catalog server 335 may store the metadata for the video asset in the memory. Catalog server 335 may include, with the metadata, a URL associated with a location at which the video asset is stored within CDN server 330.

VCM server 340 may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner similar to that described herein. VCM server 340 may, for example, communicate with content providers 230 to ingest video content to be processed by VPS 220. VCM server 340 may ingest high quality video content (e.g., associated with a resolution level and/or bit rate that is greater than a threshold). The video content may include one or more video assets, metadata associated with the video assets, and/or information associated with DRM that corresponds to the video assets.

VCM server 340 may process the high quality video content using one or more video profiles, in order to generate one or more copies of the video content. The video profiles may identify a type of user device 210 for which the video asset is intended (e.g., a set top box, a computer device, a wireless handheld device, a gaming device, etc.), type of format supported by user device 210 (e.g., a bit rate, a resolution level, a frame refresh rate, a CODEC, etc.), an encryption technique, etc. The copies may correspond to one or more formats that are supported by one or more types of user devices 210. VCM server 340 may, for example, use a video profile to generate a video format associated with a frame rate, a resolution level, a screen size, a frame refresh rate, a bit rate, etc. that enables user device 210 (such as, for example, a smart phone) to receive, process, display, and/or store the video asset. In another example, VCM 340 may use another video profile to generate another video format associated with another frame rate, another resolution level, a different screen size, another frame refresh rate, another bit rate, etc. that enables another user device 210 (e.g., a computer device) to receive, process, display, and/or store the video asset.

VCM server 340 may perform a quality control operation (e.g., by reducing periods of black screen, within the video assets, that are greater than a threshold, etc.) on the formatted video assets to ensure that the formatted video asset can be transmitted to and/or played on user device 210 at a QoS that is greater than a threshold. VCM server 340 may encrypt the one or more formats and/or may publish the one or more formats, associated with the processed video assets, to VOD server 325 and/or CDN server 330.

VCM server 340 may process the metadata associated with the video assets to ensure that the metadata is supported by different types of user devices 210. For example, VCM server 340 may adapt image sizes (e.g., associated with cover art of a video asset, etc.) to one or more sizes that can be supported by the different types of user devices 210. VCM server 340 may publish the processed metadata and/or the information associated with the DRM to catalog server 335.

Profile server 345 may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner similar to that described herein. Profile server 345 may, for example, store information associated with a profile that includes information regarding the user and each user device 210 with which the user has registered with VPS 220. For example, information associated with the profile may further include information associated with the user (e.g., a username, password, PIN, etc.), information associated with each user device 210, such as a respective identifier (e.g., a mobile directory number (MDN), an Internet protocol (IP) address, a media access control (MAC) address, a CODEC identifier, etc.), and/or information associated with a type of user device 210, such as a computer device (e.g., a lap top computer, a tablet computer, etc.), a wireless mobile device (e.g., a Droid®, a Blackberry®, an iPhone®, etc.), a set top box, a gaming device, etc.

The information associated with the profile may also include a respective user history (e.g., prior purchases, prior URLs accessed, prior downloads, etc.) associated with each user device 210; information associated with services for which user device 210 has subscribed; information associated with a location (e.g., an address, a zip code, a city, etc.) of the user and/or user device 210; information associated user account limits, restrictions, etc.; information associated with a language spoken by the user; etc.

The information associated with the profile may include a bookmark that identifies a location at which user device 210 stopped a video asset. The bookmark may permit another user device 210, associated with the user, to resume playing the video asset (e.g., that has been downloaded on the other user device 210) at the location at which the video asset was stopped by user device 210.

Billing server 350 may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner similar to that described herein. Billing server 350 may, for example, perform billing operations associated with accounts that correspond to each user device 210 associated with a user. For example, billing server 350 may receive an indication that user device 210 (e.g., a computer device), associated with the user, downloaded a video asset (e.g., via a broadband service associated with service provider network 240) as a result of a transaction via the store front portal. Billing server 350 may generate billing information that identifies the video asset, the type of transaction (e.g., a purchase, rental, subscription, etc.), a price associated with the transaction, a time at which the transaction occurred, etc. Billing server 350 may associate the billing information with an account that corresponds to the user and/or user device 210. Billing server 350 may generate other billing information regarding another transaction with another user device 210 (e.g., a set top box) with which the user is associated. Billing server 350 may associate the other billing information with another account that corresponds to the user and/or the other user device 210. In yet another example, billing server 350 may process payment information (e.g., based on credit card information, debit card information, etc.) associated with a transaction with a further user device 210 to purchase, rent, subscribe to, etc. another video asset.

FIG. 4 is a diagram of example components of a device 400 that may correspond to user device 210, content provider 230, application server 315, IMG server 320, VOD server 325, CDN server 330, catalog server 335, VCM server 340, profile server 345, and/or billing server 350. Alternatively, each of user device 210, content provider 230, application server 315, IMG server 320, VOD server 325, CDN server 330, catalog server 335, VCM server 340, profile server 345, and/or billing server 350 may include one or more devices 400. Device 400 may include a bus 410, a processor 420, a memory 430, an input component 440, an output component 450, and a communication interface 460. Although FIG. 4 shows example components of device 400, in other implementations, device 400 may contain fewer components, additional components, different components, or differently arranged components than depicted in FIG. 4. For example, device 400 may include one or more switch fabrics instead of, or in addition to, bus 410. Additionally, or alternatively, one or more components of device 400 may perform one or more tasks described as being performed by one or more other components of device 400.

Bus 410 may include a path that permits communication among the components of device 400. Processor 420 may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Memory 430 may include any type of dynamic storage device that may store information and instructions, for execution by processor 420, and/or any type of non-volatile storage device that may store information for use by processor 420.

Input component 440 may include a mechanism that permits a user to input information to device 400, such as a keyboard, a keypad, a button, a switch, etc. Output component 450 may include a mechanism that outputs information to the user, such as a display, a speaker, one or more light emitting diodes (LEDs), etc. Communication interface 460 may include any transceiver-like mechanism that enables device 400 to communicate with other devices and/or systems via wireless communications (e.g., radio frequency, infrared, and/or visual optics, etc.), wired communications (e.g., conductive wire, twisted pair cable, coaxial cable, transmission line, fiber optic cable, and/or waveguide, etc.), or a combination of wireless and wired communications. For example, communication interface 460 may include mechanisms for communicating with another device or system via a network, such as service provider network 240 and/or network 250. In one alternative implementation, communication interface 460 may be a logical component that includes input and output ports, input and output systems, and/or other input and output components that facilitate the transmission of data to other devices.

As will be described in detail below, device 400 may perform certain operations relating to video content provisioning. Device 400 may perform these operations in response to processor 420 executing software instructions contained in a computer-readable medium, such as memory 430. A computer-readable medium may be defined as a non-transitory memory device. A memory device may include space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into memory 430 from another computer-readable medium or from another device. The software instructions contained in memory 430 may cause processor 420 to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

FIG. 5 is a diagram of an example data structure 500 that stores metadata associated with video content. Catalog server 335 may perform an operation to merchandize published metadata received from VCM server 340 and may store the merchandized metadata in data structure 500. Data structure 500 may include a collection of fields, such as a video asset identifier (ID) field 505, a title field 510, a genre field 515, a description field 520, a cast information (info) field 525, a rating field 530, a price field 535, an availability field 540, a data rights management (DRM) field 545, a category field 550, a reviews field 555, a cover art field 560, a storage location field 565, a format field 570, and a bundle field 575. Data structure 500 includes fields 505-575 for explanatory purposes. In practice, data structure 500 may include additional fields, fewer fields, different fields, or differently arranged fields than are described with respect to data structure 500.

Video asset ID field 505 may store a unique identifier (e.g., one or more sequences of characters, etc.) associated with a particular video asset and/or information associated with a particular content provider 230 from which the particular asset was received. Title field 510 may store a title associated with the particular video asset. Genre field 515 may store information associated with a genre that corresponds to the particular video asset. Description field 520 may store a description associated with the particular video asset, such as a summary of a move when the particular video asset corresponds to the movie). Cast info field 525 may store information associated with an actor, a director, a producer, and/or other individuals associated with the particular video asset.

Rating field 530 may store information associated with a rating (e.g., general audience (G), parental guidance (PG), PG-13, restricted (R), mature audience (MA), etc.) that corresponds to the particular video asset. Price field 535 may store information, associated with one or more prices, that corresponds to the particular video asset. For example, one price may correspond to a sale price for the particular video asset. Another price may correspond to a rental price (e.g., a cost per viewing, per day, per week, etc.). One or more further prices may correspond to a price associated with a bundle of video assets and/or services that include the particular video asset, etc. Availability field 540 may store information associated with an availability of the particular asset. For example, availability field 540 store information that identifies when the particular video asset may be released to users of user devices 210 and when the particular asset is no longer available to users of user devices 210. In another example, availability field 540 may store information associated with a blackout period from a time when the particular asset is not to be released to another time when the particular asset may be released.

DRM field 545 may store license information associated with the particular asset and/or one or more keys that are used to encrypt the particular video asset. Category field 550 may store information associated with a category that corresponds to the particular video asset. The information, associated with the category, may include, for example, an indication that the particular video asset is a movie, a television program, a video game, etc. Reviews field 555 may include information associated with reviews, by users associated with VPS 220 and possibly users not associated with VPS 220, of the particular video asset. Cover art field 560 may include one or more images associated with the particular asset.

Storage location field 565 may store information associated with a location, within a memory associated with VOD server 325 and/or CDN server 330, that the particular video asset is stored. Format field 570 may store information associated with a video format that corresponds to the particular video asset. For example, format field 570 may store information associated with a bit rate, a screen size, a resolution level, a frame rate, a frame refresh rate, etc. that corresponds to the particular video asset. Bundle field 575 may store information, associated with a bundle, that identifies other services and/or other video assets, obtained from the ingested video content, that are associated with the particular video content. The bundle may be associated with a price identified in price field 535.

FIG. 6 is a flow chart of an example process 600 for ingesting and processing video content within VPS 220. In one example implementation, process 600 may be performed by one or more devices associated with VPS 220. In another example implementation, some or all of process 600 may be performed by a system and/or device, or collection of systems and/or devices separate from, or in combination with the devices associated with VPS 220.

As shown in FIG. 6, process 600 may include obtaining video content from content provider 230 (block 605) and processing a video asset and/or metadata obtained from the video content (block 610). For example, VPS 220 (e.g., using VCM server 340) may communicate with one or more content providers 230 to receive high quality video content that VPS 220 is to use to provide common video services to one or more types of user devices 210 associated with a user. The high quality video content may include one or more video assets associated with a resolution level that is greater than a threshold. The high quality video content may also include respective metadata associated with each of the video assets and/or information associated with DRM (hereinafter referred to as “DRM information”) for each of the video assets.

VCM server 340 may use the high quality video content to generate copies of the video assets associated with one or more other resolution levels that are approximately equal to or less than the resolution level associated with the high quality video content. For example, VCM server 340 may generate a copy of a video asset and may perform an operation to transcode the video asset into a format that can be supported (e.g., received, processed, stored, played, etc.) by a type of user device 210 (e.g., a computer device) and/or some other format (e.g., a high definition format, etc.). The format of the transcoded video asset may be associated with a frame size, frame refresh rate, resolution level, a bit rate, etc. Additionally, or alternatively, the format may be associated with a level of compression that corresponds to the type of user device 210 (e.g., based on a CODEC that corresponds to user device 210). VCM server 340 may obtain, from the video content, DRM information associated with the video asset. VCM server 340 may use the DRM information to generate a key and/or license information associated with each format and/or copy of the video asset. VCM server 340 may use a respective key to encrypt each copy of the video asset. VCM server 340 may generate other encrypted copies of the video asset based on other formats that are supported by other types of user devices 210.

VCM server 340 may process metadata associated with the video asset. For example, VPS 220 obtain metadata, associated with the video asset, from the video content. VCM server 340 may format images (e.g., cover art), descriptions of the video asset, etc. associated with the video asset in a manner that is supported by user device 210. VCM server 340 may generate other encrypted copies of the metadata based on other formats that are supported by other types of user devices 210. VCM server 340 may process other metadata associated with other video assets obtained from the video content.

As also shown in FIG. 6, process 600 may include publishing the processed video asset, processed metadata, and/or DRM information associated with the video asset (block 615). For example, VPS 220 (e.g., using VCM server 340) may publish copies of the video asset in one or more memories associated with VPS 220. The copies may include a high definition copy, a standard definition copy, a movie trailer copy, an advertising copy, video game copies, etc. In one example, VCM server 340 may transmit a portion of the copies of the video asset, that are based on a format that is supported by a set top box user device 210, to VOD server 325. VOD server 325 may receive the portion of the copies of the video asset and may store the portion of the copies of the video asset in a memory associated with VOD server 325.

In another example, VCM server 340 may transmit another portion of the copies of the video asset to CDN server 330. The other portion of the copies of the video assets may be based on one or more formats that are supported by types of user devices (e.g., a computer device, a wireless mobile device, a portable gaming device, etc.) other than, or in addition to, the set top box user device 210. CDN server 330 may receive the other portion of the copies of the video asset and may store the other portion of the copies of the video asset in a memory associated with CDN server 330. CDN server 330 may transmit, to VCM server 340, information associated with a respective storage location (e.g., respective URLs, etc.), within the memory associated with CDN server 330, that each of the other portion of the copies of the video asset are stored.

VCM server 340 may transmit the processed metadata and/or copies of the key and/or license information, associated with the video asset, to VOD server 325 and/or catalog server 335. The processed metadata may include the information associated with one or more storage locations within CDN server 330. For example, VCM server 340 may send, to VOD server 325, a portion of the processed metadata that corresponds to the copies of the video assets that are formatted for the set top box user device 210. VCM server 340 may send the portion of the processed metadata and/or another portion of the processed metadata, which is formatted for the type of user device 210 other than the set top box user device 210, to catalog server 335.

As further shown in FIG. 6, process 600 may include merchandizing the published metadata and/or storing the merchandized metadata and/or DRM information in a catalog (block 620). For example, VPS 220 (e.g., using catalog server 335) may perform an operation to merchandize the published metadata received from VCM server 340. Catalog server 335 may, for example, generate a price structure associated with the video asset. The price structure may include one or more prices (e.g., a sale price, a rental price, a subscription price, etc.) associated with distributing the video asset to user device 210. Catalog server 335 may determine the one or more prices in order to cover operating expenses (e.g., associated with processing, etc.), profit (e.g., as a result of the transaction), a settlement cost (e.g., obtained from the published metadata) associated with content provider 230 from which the video asset was received, and/or other costs.

In another example, catalog server 335 may combine two or more video assets and/or services to generate bundles of services and/or video assets. Catalog server 335 may generate a price associated with the bundle. Catalog server 335 may associate, with the published metadata, information associated with advertising and/or promotional information (e.g., discounts on prices, subscriptions, etc. for a period of time, during a particular season, etc.).

Catalog server 335 may store the merchandized metadata, the DRM information, and/or the information associated with the storage locations (e.g., URLs associated with CDN server 330) associated with the video asset in a data structure (e.g., data structure 500 of FIG. 5). In a manner similar to that described above, VOD server 325 may merchandize the portion of the published metadata (e.g., received from VCM server 340) and may store the portion of the merchandized metadata in another data structure.

In another example implementation, catalog server 335 may merchandize published metadata associated with free video assets (e.g., associated with free broadcast video assets, free on-line video assets, etc). For example, catalog server 335 may combine two or more free video assets and/or services to generate bundles of free video assets and/or services. Catalog server 335 may associated, with the published metadata, the information associated with advertising and/or the promotional information. Catalog server 335 may not, in this example, generate a price structure associated with the free video assets nor assign one or more prices to the free video assets and/or bundles of free video assets.

As yet further shown in FIG. 6, process 600 may include publishing the merchandized metadata to an electronic store front (block 625). For example, VPS 220 (e.g., using catalog server 335) may publish the merchandized metadata to an electronic store front associated with VPS 220 (e.g., that is hosted by application server 315). Catalog server 335 may, for example, obtain information, associated with the availability of the video asset, from the metadata. Catalog server 335 may determine whether the video asset is available (e.g., can be released to the public) based on the information associated with the availability. Catalog server 335 may transmit all or a portion of the merchandized metadata to application server 315 when the information, associated with the availability, indicates that the video asset is available. Catalog server 335 may not transmit the merchandized metadata when the information, associated with the availability, indicates that the video asset is not available. In an example implementation, catalog server 335 may transmit information that identifies a future time when the video asset will be available.

Application server 315 may receive all or the portion of the merchandized metadata and may publish the received merchandized metadata to the electronic store front, such as, for example, a webpage that can be accessed by a type of user device 210 (e.g., a computer device, a wireless mobile device, etc.) via service provider network 240 (e.g., a broadband network, such as the Internet, etc.). In another example, the electronic store front may include a data structure from which information is transmitted, via a service provider network 240 (e.g., a wireless telephone network, etc.), to another type of user device 210 (e.g., a wireless mobile device) for display via a user interface.

In another example, VOD server 325 may, in a manner similar to that described above, transmit all or a portion of the merchandized metadata, associated with the video asset that is formatted for the set top box user device 210, to IMG server 320. IMG server 320 may receive the merchandized metadata and may publish the merchandized metadata to another electronic store front, associated with VPS 220. The other electronic store front may include, for example, an interactive program guide via which a set top box user device 210 can view and/or select the video asset.

FIG. 7 is a flow chart of an example process 700 for registering user device 210 with VPS 220. In one example implementation, process 700 may be performed by one or more devices associated with VPS 220. In another example implementation, some or all of process 700 may be performed by a system and/or device, or collection of systems and/or devices separate from, or in combination with the devices associated with VPS 220.

As shown in FIG. 7, process 700 may include receiving a registration request from a user device (block 705) and sending a client application to the user device (block 710). For example, application server 315 may receive, from user device 210, a request to register with VPS 220. The request may include information associated with user device 210, such as, for example, a device identifier (e.g., an MDN, a CODEC, etc.), a network address (e.g., a MAC address, an IP address, etc.), information associated with a user of user device 210 (e.g., a username, a password, a PIN, etc.), etc. The request may also include information relating to another user device 210, associated with the user.

Application server 315 may retrieve, from a memory associated with application server 315, a client application and may send the client application to user device 210. User device 210 may receive the client application and may install and/or execute the client application. User device 210 may use the client application to register user device 210 with application server 315. In another example implementation, the user may register user device 210 in a manner that does not include installing the client application. For example, user device 210 may access a web page (e.g., via the Internet), hosted by application server 315, and may send the information, associated with user device 210, to application server 315, via the web page.

As also shown in FIG. 7, process 700 may include receiving registration information from the user device (block 715). For example, the user of user device 210 may enter registration information into a user interface display, provided by the client application, on user device 210. User device 210 may receive the registration information and may transmit the registration information to application server 315. Application server 315 may receive the registration information. The registration information may include information associated with a type of user device 210 (e.g., a set top box, a computer device, a wireless mobile device, a tablet computer, etc.) associated with the user. The registration information may include information associated with respective parental controls, preferred video content genres, etc. associated with user device 210.

As further shown in FIG. 7, process 700 may include establishing a profile, associated with a user of the user device, based on the information associated with the user device and/or the registration information (block 720). For example, application server 315 may transmit the information associated with user device 210 and/or the registration information to profile server 345. Profile server 345 may receive the information associated with user device 210 and/or the registration information and may create a profile associated the user of user device 210. Profile server 345 may communicate with billing server 350 to obtain information associated with one or more accounts that correspond to user device 210 and/or another user device 210 with which the user is associated. Profile server 345 may associate the information, associated with user device 210, the registration, and/or the accounts, with the profile and may store information associated with the profile in a memory associated with profile server 345.

As yet further shown in FIG. 7, process 700 may include transmitting confirmation information to the user device as a result of establishing the profile (block 725). For example, application server 315 may receive, from profile server 345, an indication that the profile, associated with the user of user device 210, has been established. Application server 210 may transmit a request, to catalog server 340, for unique confirmation information (e.g., a private key, a public key, a digital certificate, a confirmation number, etc.) that corresponds to user device 210. Catalog server 340 may receive the request and may send the confirmation information to application server 315. Application server 315 may receive the confirmation information and may transmit the confirmation information to user device 210. Application server 210 may obtain other unique confirmation information, corresponding to other user devices 210 associated with the user, and may transmit the other unique confirmation information to the other user devices 210. In an example implementation, application server 315 may transmit the client application, to user device 210, after a successful registration of user device 210.

The user may register one or more other user devices 210 in a manner similar to that described above. The other user device(s) 210 may be the same type or a different type of user device 210 relative to user device 210. In this way, a user may provide information regarding a number of user devices 210 with which the user is associated.

FIG. 8 is a flow chart of an example process 800 for provisioning common video services to various types of user devices 210. In one example implementation, process 800 may be performed by one or more devices associated with VPS 220. In another example implementation, some or all of process 800 may be performed by a system and/or device, or collection of systems and/or devices separate from, or in combination with the devices associated with VPS 220.

As shown in FIG. 8, process 800 may include receiving an access request from a user device and authenticating the user device in response to the request (block 805). For example, application server 315 may receive an access request from user device 210. The access request may include information associated with the user (e.g., username, password, PIN, etc.) and/or user device 210 (e.g., a device identifier, a network address, etc.), and/or confirmation information associated with user device 210 (e.g., a private key, a public key, a digital certificate, a confirmation number, etc.). Application server 315 may retrieve information associated with the user and/or user device 210 from a profile, associated with the user, stored in a memory associated with profile server 345. Additionally, or alternatively, application server 315 may retrieve confirmation information, associated with user device 210, from catalog server 335 and/or from the profile associated with the user.

Application server 315 may compare the information associated with the user and/or user device 210, received with the access request, to the retrieved information associated with the user and/or user device 210. Application server 315 may, based on the comparison, determine whether the received information, associated with the user and/or user device 210, matches the retrieved information associated with the user and/or user device 210. Application server 315 may not authenticate user device 210 based on a determination that the received information does not match the retrieved information. Application server 315 may determine that the received information matches the retrieved information and may compare confirmation information, obtained from the access request, to the retrieved confirmation information to determine whether the confirmation information matches the retrieved confirmation information. Application server 315 may not authenticate user device 210 based on a determination that the confirmation information does not match the retrieved confirmation information. Application server 315 may authenticate user device 210 based on a determination that the confirmation information matches the retrieved confirmation information.

As also shown in FIG. 8, process 800 may include retrieving a profile and/or a transaction history associated with the user and/or retrieving metadata associated with a catalog (block 810). For example, application server 315 may, as a result of authenticating user device 210, retrieve information associated with a profile, that corresponds to user device 210, from profile server 345. Also, or alternatively, application server 315 may retrieve, from a memory associated with application server 315, information associated with a transaction history that corresponds to the user. The information associated with the transaction history may identify metadata associated with a video asset (e.g., a title of the video asset; a date of the prior purchase, rental, subscription, etc.; an indication that identifies to which user device 210 the video asset was downloaded; etc.) that was downloaded, by user device 210 and/or the other user device 210, at a prior point in time. Application server 315 may retrieve metadata associated with a catalog from a memory associated with application server 315 and/or from catalog server 335.

Additionally, or alternatively, application server 315 may obtain, from the profile, information associated with a video profile that identifies a type of user device 210, a format supported by user device 210, encryption techniques supported by user device 210, etc. Application server 315 may use the information, associated with the video profile, to identify particular copies of a selected asset to transmit to user device 210.

As further shown in FIG. 8, process 800 may include sending the metadata associated with the catalog and/or the information associated with the transaction history (block 815). For example, application server 315 may send, to user device 210, the metadata associated with the catalog and/or the information associated with the transaction history. User device 210 may receive the metadata and/or the information associated with the transaction history and a client application, hosted by user device 210, may present the metadata and/or the information associated with the transaction history for display via a user interface. The user interface may be associated with an electronic store front associated with VPS 220 and may permit the user to interact with the user interface to select a video asset to be downloaded to user device 210.

As yet further shown in FIG. 8, process 800 may include receiving selection of a video asset (block 820). For example, the user may select, via the user interface, metadata associated with a video asset. User device 210 may send the selection of the video asset to application server 315 and application server 315 may receive the selection of the video asset. Application server 315 may determine whether the selected video asset was downloaded at a prior time (e.g., by another user device 210 associated with the user) based on the information associated with the transaction history.

As still further shown in FIG. 8, if the selected video asset has been previously downloaded (block 825-YES) and if the license of the downloaded asset is valid (block 830-YES), then process 800 may include sending a URL and/or a bookmark associated with the selected asset (block 835). For example, application server 315 may determine that the information associated with the transaction history includes an indication that the select video asset was downloaded to another user device 210, associated with the user, at a prior time as a result of a purchase, rental, subscription, etc. Application server 315 may, based on the determination that the selected asset was previously downloaded, communicate with catalog server 335 and/or VOD server 325 to determine whether a license, associated with the previously downloaded video asset, is still valid. Catalog server 335 and/or VOD server 325 may retrieve information associated with the license and may determine that a term, during which the license is to remain valid, has not expired. In another example, application server 315 may determine that the previously downloaded video asset was transmitted to the other user device 210 as a result of a purchase, which may indicate that the license is still valid.

Based on the determination that the selected asset was previously downloaded to the other user device 210 and/or that the license, associated with the previously downloaded asset, is valid, application server 315 may, in one example, obtain a URL from metadata associated with the selected asset. Application server 315 may use information, associated with the video profile that corresponds to user device 210, to select a URL associated with the video content. The URL may be associated with a storage location from which the selected asset, that is formatted in a manner that can be supported by user device 210 (e.g., based on the video profile), can be retrieved by user device 210. In another example, application server 315 may retrieve, from VOD server 325 and based on the video profile, information associated with the selected video asset (e.g., a PAID) and/or content provider 230 (e.g., PID) from which the selected video asset was obtained. Also, or alternatively, application server 315 may retrieve a bookmark, associated with the selected asset, from profile server 345 that enables user device 210 to resume playing the selected asset at a location at which the other user device 210 stopped playing the downloaded asset at a previous point in time. Application server 315 may transmit the URL, the information associated with the video asset and/or content provider 230, and/or the bookmark to user device 210.

As also shown in FIG. 8, process 800 may include receiving a request for the selected content and sending the selected content in response to the request (block 840). For example, user device 210 may receive the URL, the information associated with the selected video asset and/or content provider 230, and/or the bookmark. In one example, the client application may use the URL to send a request for the selected video asset from CDN server 330. CDN server 330 may receive the request and may, in response to the request, retrieve a copy of the selected asset from a memory associated with CDN server 330 based on the URL. In another example, CDN server 330 may determine that the selected video asset is not stored in the memory and may retrieve a copy of the selected video asset from content provider 230. The selected asset, received from content provider 230 may, in a manner similar to that described above (e.g., with respect to FIG. 6), be processed, by VCM server 340, to create a format that is supported by user device 210. CDN server 330 may send the copy of the selected asset to user device 210 (e.g., via progressive download, adaptive bit rate streaming, etc.) in a manner that conforms to a level of QoS.

In a further example, the client application may use the information associated with the selected video asset (e.g., a PAID) and/or content provider 230 (e.g., a PID) to send a request for the selected video asset from VOD server 325. VOD server 325 may receive the request and may, for example, retrieve a copy of the selected asset from a memory associated with VOD server 3325 based on the information associated with the selected video asset and/or content provider 230. In another example, CDN server 330 may determine that the selected video asset is not stored in the memory associated with VOD server 325 and may retrieve a copy of the selected video asset from content provider 230. The selected asset, retrieved from content provider 230, may, in a manner similar to that described above (e.g., with respect to FIG. 6), be processed, by VCM server 340, to create a format that is supported by user device 210 (e.g., a set top box user device 210). VOD server 325 may send the copy of the selected asset to user device 210 (e.g., via streaming video, etc.) in a manner that conforms to another level of QoS.

As further shown in FIG. 8, process 800 may include receiving a request for a license associated with the selected asset and sending the license in response to the request (block 845). For example, user device 210 may receive the selected video asset and the client application may send a request, to catalog server 335, for a license associated with the selected asset. Catalog server 335 may receive the request and may retrieve the license from a memory associated with catalog server 335. Catalog server 335 may transmit the license to user device 210. User device 210 may receive the license and the client application may use the license to decrypt the selected asset. The client application may automatically, or in response to an instruction from the user, play the decrypted video asset on user device 210.

As yet further shown in FIG. 8, if the selected video asset has not been previously downloaded (block 825-NO), or if a license associated with the downloaded asset is not valid (block 830-NO), process 800 may include performing an electronic transaction associated with the selected video asset (block 850). For example, application server 315 may determine that the information associated with the transaction history does not include an indication that the select video asset was downloaded to another user device 210, associated with the user, at the prior time. In another example, application server 315 may determine that the information associated with the transaction history includes an indication that the select video asset was downloaded to the other user device 210 at the prior time (e.g., as a result of a rental, a subscription, etc.). Based on the determination that selected video asset was previously downloaded, application server 315 may interact with catalog server 335 and/or VOD server 325 to determine whether a license, associated with the downloaded video asset, is still valid. Catalog server 335 and/or VOD server 325 may retrieve information associated with the license and may determine that a term, during which the license is to remain valid, has expired.

Application server 315 may, based on the determination that the selected video asset was not previously downloaded and/or that a license, associated with the previously downloaded video asset, has expired, perform an electronic transaction associated with the selected asset. For example, application server 315 may send an indication, to billing server 350, indicating that information regarding an electronic transaction is to be associated with an account corresponding to user device 210. The indication may include a value associated with a price for the selected video asset, information associated with user device 210, information associated with the selected video asset (e.g., an identifier associated with the selected video asset), and/or and information associated with content provider 230 (e.g., an identifier associated content provider 230) from which the selected video asset was received. The price may correspond to a type of electronic transaction, such as a purchase, rental, subscription, bundle, etc.

Billing server 350 may receive the indication and may store the information regarding the electronic transaction in a data structure relating to the account. Billing server 350 may perform settlement operation by storing a portion of the price in another data structure relating to another account associated with content provider 230.

Application server 315 may send an electronic receipt, to user device 210, that includes the information associated with the electronic transaction. Application server 315 may update the transaction history, associated with user device 210, based on the information associated with the electronic transaction. Application server 210 may communicate with user device 210 to transmit the selected video asset and/or a license, associated with the selected video asset, in a manner similar to that described above (e.g., with respect to blocks 835-845).

FIGS. 9A-9C are diagrams of different user devices 900-920, that are displaying a video asset as a result of interacting with the VPS 220 to obtain the video asset according to an implementation described herein. For example, as shown in FIG. 9A, a set top box 900 may present a video asset for display on a display device 905 associated with set top box 900. A user, associated with set top box 900, may instruct set top box 900 (e.g., by pressing a button, or series of buttons, on set top box 900 and/or on a remote control associated with set top box 900) to stop playing the video asset. Set top box 900 may, in response to the instruction, stop playing the video asset. Set top box 900 may store a bookmark (e.g., a pointer) that corresponds to a first point at which set top box 900 stopped playing the video asset and may send the bookmark to application server 315 and/or profile server 345 to be stored in a user profile associated with the user.

As shown in FIG. 9B, a computer device 910, associated with the user, may receive the bookmark from application server 315 and/or profile server 345. The user may instruct computer device 910 (e.g., by pressing a key, a series of keys, a touch screen, etc. on the computer device) to resume playing the video asset using a copy of the video asset that is stored on computer device 910. Computer device 910 may receive the instruction and may use the bookmark to resume playing the video asset at the point where set top box 900 stopped playing the video asset. As some later point in time, the user may stop the playing of the video asset on computer device 910. In response, computer device 910 may send another bookmark, to application server 315 and/or profile server 345, that corresponds to a second point at which computer device 910 stopped playing the copy of the video asset.

As shown in FIG. 9C, a wireless mobile handset 920, associated with the user, may receive the bookmark and/or the other bookmark from application server 315 and/or profile server 345. The user may instruct wireless mobile handset 920 (e.g., by pressing a button, a series of buttons, a touch screen, etc. on wireless mobile handset 920) to resume playing the video asset on wireless mobile handset 920, using another copy of the video asset that is stored on wireless mobile handset 920. Wireless mobile handset 920 may receive the instruction and may use the bookmark, or the other bookmark, to resume playing the video asset (e.g., the other copy of the video asset) in a manner similar to that described above. Thus, in the examples above, a user may pause the playing of the video asset on set top box 900 and resume the playing of the video asset on computer device 910 or wireless mobile handset 920.

In addition, while the previous example described a situation where the video asset is first played on set top box 900, systems and/or methods, described herein, are not so limited. In fact, the user may interact with VPS 220 to initiate playing of the video asset on any of these user devices, stop the playing of the video asset, and resume the playing of the video asset on the same or any other one of these user devices.

Systems and/or methods, described herein, may enable video content to be processed in a manner that enables the video content to be provisioned to various types of user devices, associated with a user, over various types of networks. The systems and/or methods may enable the video content to be provisioned, to each type of user device, for a uniform price and/or with respect to the same availability and/or accessibility. The systems and/or methods may enable copies of the video content to be formatted in a manner that is supported by each type of user device. The systems and/or methods may enable a catalog to store metadata associated with video content that can be accessed by each type of user device. The systems and/or methods may enable a transaction history to store information regarding each transaction, associated with each type of user device, to obtain video content. The systems and/or methods may enable each type of user device to use uniform login credentials to access a store front portal via which video content is obtained from the catalog. The systems and/or methods may permit video content to be played on one of the user devices, paused, and resumed on another one of the user devices.

The foregoing description provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the embodiments.

While series of blocks have been described with regard to FIGS. 6-8, the order of the blocks may be modified in other implementations. Further, non-dependent blocks may be performed in parallel.

It will be apparent that systems and/or methods, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these systems and methods is not limiting of the embodiments. Thus, the operation and behavior of the systems and methods were described without reference to the specific software code—it being understood that software and control hardware can be designed to implement the systems and methods based on the description herein.

Further, certain portions, described above, may be implemented as a component that performs one or more functions. A component, as used herein, may include hardware, such as a processor, an ASIC, or a FPGA, or a combination of hardware and software (e.g., a processor executing software).

It should be emphasized that the terms “comprises”/“comprising” when used in this specification are taken to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the embodiments. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one other claim, the disclosure of the embodiments includes each dependent claim in combination with every other claim in the claim set.

No element, act, or instruction used in the present application should be construed as critical or essential to the embodiments unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

Claims

1. A method comprising:

receiving, by a video provisioning system, a video asset from one or more content providers;
processing, by the video provisioning system, the video asset to allow the video asset to be provided to a set top box and another device, the other device being a different type of device than the set top box; and
providing, by the video provisioning system, the video asset to the set top box and the other device.

2. The method of claim 1, where receiving the video asset from one or more content providers further includes:

receiving, from the one or more content providers, metadata associated with the video asset, where the metadata enables the video asset to be managed by the video provisioning system, where the metadata includes at least one of: an identifier associated with the video asset, an identifier associated with the one or more content providers, a description associated with the video asset, information associated with a genre that correspond to the video asset, information associated with a rating that correspond to the video asset, or information indicating that the video asset can be provided to the set top box and the other device.

3. The method of claim 2, further comprising:

processing the metadata associated with the video asset to allow the video asset to be offered to the set top box or the other device, where offering the video asset permits the set top box or the other device to purchase or rent the video asset.

4. The method of claim 1, where processing the video asset to allow the video asset to be provided to the set top box and the other device includes:

formatting the video asset in a manner that can be transmitted to, received by, or played on the set top box; and
formatting the video asset in a different manner that can be transmitted to, received by, or played by the other device.

5. The method of claim 1, where processing the video asset to allow the video asset to be provided to the set top box and the other device includes:

generating one or more copies of the video asset, where a first portion, of the one or more copies, correspond to a format that can be played by the set top box, and where a second portion, of the one or more copies, correspond to another a different format that can be played by the other device.

6. The method of claim 1, where the other user device includes at least one of:

a computer device,
a wireless handheld device, or
a gaming device.

7. The method of claim 1, further comprising:

receiving, from a user device, a request to obtain the video asset;
retrieving, from a memory associated with the video provisioning system, information associated with a profile that corresponds to a user of the user device;
identify the user device as the set top box based on the information associated with the profile;
retrieving, from the memory, a copy of the video asset, of one or more copies of the video asset, that is formatted to be played by the set top box; and
transmitting, to the set top box, the copy of the video asset that is formatted to be played by the set top box.

8. The method of claim 7, further comprising:

retrieving, from a memory associated with the video provisioning system and in response to the request, a license associated with the video asset; and
transmitting, to the set top box, the license associated with the video asset, where transmitting the license enables the set top box to decrypt the video asset and to play the decrypted video asset.

9. The method of claim 1, further comprising:

receiving, from the set top box, a bookmark associated with the video asset, where the bookmark identifies a point at which the set top box stopped playing the video asset; and
providing the bookmark to a user device, associated with a user of the set top box and that previously downloaded a copy of the video asset, where providing the bookmark allows the user device to play the copy of the video asset at the point at which the set top box stopped playing the video asset.

10. The method of claim 1, further comprising:

receiving, from the other device, a request for another video asset;
retrieving, in response to the request, a profile associated with a user of the other device, where the profile includes information relating to a transaction history associated with the user and information associated with the set top box;
determining that a copy of the other video asset was previously transmitted to the set top box based on the information relating to the transaction history; and
transmitting, to the other device, the other video asset at no additional cost to the user.

11. A system comprising:

one or more processors to: receive a video asset, process the video asset to allow the video asset to be transmitted to a set top box and another device, the other devices being a different type of device than the set top box, the set top box and the other device being associated with a user, receive a request for the video asset from one of the set top box or the other device, and transmit, in response to receiving the request, the video asset to the one of the set top box or the other device.

12. The system of claim 11, where, when processing the video asset, the one or more processors are to:

generate one or more copies of the video asset, where a first portion of the one or more copies can be played by the set top box, and a second portion of the one or more copies can be played by the other device.

13. The system of claim 11, where the one or more processors are further to:

receive metadata associated with the video asset,
determine, based on the received metadata, that the video asset is precluded from being transmitted to the set top box or the other device until a future point in time, and
transmit the video asset to the set top box or the other device after the future point in time.

14. The system of claim 11, further comprising:

receive metadata associated with the video asset, and
publish, the metadata via a portal that is accessible by the set top box and the other device,
where the request is received in response to selection of the metadata via the portal.

15. The system of claim 11, where the one or more processors are further to:

receive, from the set top box, a request to register the set top box,
transmit, to the set top box and in response to the request to register, a client application that enables the set top box to provide information, associated with a profile that corresponds to the user, where the information, associated with the profile, includes at least one of: information associated with the user, information associated with the set top box, information associated with the one or more other devices, information associated with a genre, associated with video assets, that is specified by the user, or information associated with parental controls that are specified by the user.

16. The system of claim 11, where, when processing the video asset, the one or more processors are to:

transcode the video asset to create a first copy of the video asset associated with a first format that can be played by the set top box, where the first format identifies at least one of: a first bit rate associated with the video asset, a first frame rate associated with the video asset, a first level of resolution associated with the video asset, or a first compression/decompression (CODEC) ratio associated with the video asset, and
transcode the video asset to create one or more copies of the video asset associated with a second format that can be played by the other device, where the second format identifies at least one of: a second bit rate associated with the video asset, a second frame rate associated with the video asset, or a second frame refresh rate associated with the video asset.

17. The system of claim 11, where the one or more processors are further to:

receive, from the other device, an indication that a copy of the video asset was transferred to a different device, associated with the user,
retrieve, as a result of receiving the indication, a license associated with the copy of the video asset, and
transmit the license to the different device, where the license enables the different device to decrypt the copy of the video asset and to play the decrypted copy of the video asset on the different device.

18. The system of claim 11, where the one or more processors are further to:

receive a bookmark from the other device, of the one or more other devices, where the bookmark identifies a point at which the other device stopped playing the video asset, and
retrieve information associated with a profile, that corresponds to the user, where the information associated with the profile indicates that a copy of the video asset was previously transmitted to a different device associated with the user, and
transmit the bookmark to the different device, where the bookmark allows the different device to resume playing the copy of the video asset at the point at which the other device stopped playing the video asset.

19. A video provisioning system comprising:

one or more devices to: receive a video asset from one or more content providers; process the video asset to allow the video asset to be provided to a set top box and another user device, the other user device being a different type of device than the set top box, the set top box and the other user device being associated with a user, provide the video asset to the set top box and the other user device, receive, from one of the set top box or the other device, a bookmark that identifies a point at which the one of the set top box or the other user device stopped playing the video asset, and
provide the bookmark to another one of the set top box or the other user device, where providing the bookmark enables the other one of the set top box or the other user device to resume playing the video asset at the point at which the one of the set top box or the other user device stopped playing the video asset.

20. The video provisioning system of claim 19, where the one or more devices are further to:

receive, from the other one of the set top box or the other user device, another bookmark that identifies another point at which the other one of the set top box or the other user device stopped playing the video asset, where the other bookmark enables the set top box, the other user device, or a further user device, associated with the user, to resume playing the video asset at the other point at which the other one of the set top box or the other user device stopped playing the video asset.

21. The video provisioning system of claim 19, where the one or more devices are further to:

retrieve information associated with a user profile that corresponds to the user,
identify that the other one of the set top box or the other user device associated with the user based on the information associated with the profile, and
determine that the bookmark is to be provided to the other one of the set top box or the other user device based on the identification that the other one of the set top box or the other user device is associated with the user.

22. The video provisioning system of claim 19, where the one or more devices are further to:

receive, from a user device, a request for another video asset, where the request indicates that the other video asset is to be purchased,
retrieve information associated with a profile that corresponds to the user device, where the information associated with the profile identifies an account associated with a user of the user device, and
associated a price, that corresponds to a rental price for the other video asset, to an account associated with the user, and
provide the other video asset to the user device.

23. The video provisioning system of claim 22, where the one or more devices are further to:

receive, from the one of the set top box or the other user device, a request for the other video asset,
retrieve information associated with another profile that corresponds to the one of the set top box or the other user device, where the information associated with the other profile indicates that the one of the set top box or the other user device is associated with the user of the user device, and
provide, to the one of the set top box or the other user device, the other video asset and another bookmark, associated with the other video asset, based on the indication that the one of the set top box or the other user device is associated with the user of the user device, where the other bookmark identifies a point at which the user device stopped playing the other video asset, and where the other video asset is sent to the one of the set top box or the other user device at no cost to the user.

24. The video provisioning system of claim 19, where the one or more processors are further to:

retrieve, from a storage device, a license associated with the video asset that was provided to the one of the set top box or the other user device,
retrieve, from the storage device, a different license associated with the video asset that was provided to the other one of the set top box or the other user device,
provide the license to the one of the set top box or the other user device that enables the one of the set top box or the other user device to decrypt the video asset to create a decrypted copy of the video asset that can be played by the one of the set top box or the other user device, and
provide the different license to the other one of the set top box or the other user device that enables the other one of the set top box or the other user device to decrypt the video asset to create a different decrypted copy of the video asset that can be played by the other one of the set top box or the other user device.
Patent History
Publication number: 20120079523
Type: Application
Filed: Aug 2, 2011
Publication Date: Mar 29, 2012
Applicant: VERIZON PATENT AND LICENSING, INC. (Basking Ridge, NJ)
Inventors: John K. TRIMPER (Groton, MA), Jyothikumar JAGANNATHAN (Wesley Chapel, FL), Sampath K. NAMBAKKAM (Irving, TX), Sanjay AHUJA (Irving, TX), Srirama R. KALIDINDI (Flower Mound, TX), Hans Raj NAHATA (New Providence, NJ), Jeffery L. HARRIS (Reston, VA)
Application Number: 13/196,714
Classifications
Current U.S. Class: Of Specific Program (e.g., Based On Program Rating) (725/28); Control Process (725/116)
International Classification: H04N 21/2347 (20110101); H04N 21/23 (20110101);