Patent Publication Number: US-9407968-B2

Title: Multicast and unicast adaptive bitrate services

Description:
BACKGROUND 
     A content delivery network (CDN) (also known as a content distribution network) is used for delivering programs to users via user devices. The content delivery network stores and delivers the programs to users either on-demand, according to a program schedule, or both. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a diagram illustrating an exemplary environment in which an exemplary embodiment of multicast and unicast adaptive bitrate services may be implemented; 
         FIGS. 2A-2G  are diagrams that illustrate an exemplary scenario pertaining to an exemplary embodiment of the multicast and unicast adaptive bitrate service; 
         FIG. 2H  is a diagram illustrating another exemplary scenario pertaining to an exemplary embodiment of the multicast and unicast adaptive bitrate service; 
         FIG. 3  is a diagram illustrating exemplary components of a device that may correspond to one or more of the devices in an exemplary environment; 
         FIG. 4  is a flow diagram that illustrates an exemplary process pertaining to the multicast and unicast adaptive bitrate services; 
         FIGS. 5A and 5B  are flow diagrams that illustrate another exemplary process pertaining to the multicast and unicast adaptive bitrate services; and 
         FIGS. 6A and 6B  are flow diagrams that illustrate yet another exemplary process pertaining to the multicast and unicast adaptive bitrate services. 
     
    
    
     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. Also, the following detailed description does not limit the invention. 
     As used herein, the term “program” refers to audio content and/or visual content. For example, a program may include a linear television program (e.g., a movie, a program of a television series, a reality show, a documentary, etc.), an on-demand program, a pay-per-view program, music, a pre-recorded program, a live program, or user-generated content. A program may be free or may require some form of purchase (e.g., buy, rent, etc.). 
     A program service provider (e.g., a multiple system operator (MSO)) may offer a program service for programs. The program service may be a subscription-based program service that delivers programs to users. The program service delivers programs to users via a content delivery network. Users may be able to receive programs via streaming and/or downloading. Depending on the program service provider, the content delivery network may have a national geographic presence, a regional geographic presence, or a local geographic presence. By way of further example, in a national-based context, the content delivery network may include a centralized center or distributed centers that receive programs and metadata from program providers, process the programs and metadata (e.g., transcode, format, encrypt, etc.), manage digital rights (e.g., licensing, etc.), and distribute the programs and metadata to regional centers. The regional centers make the programs and metadata available to users via local nodes, as well as perform other functions (e.g., user entitlement management, billing, program recommendations, etc.). 
     Under an existing approach, when a user of a mobile device wishes to receive a program (e.g., a movie) via adaptive streaming (e.g., Hypertext Transfer Protocol (HTTP)-based adaptive streaming), a program player will obtain a file (e.g., a manifest file) from a network device of a content delivery network. The file includes a list of available bitrates for the program that a network device of the content delivery network supports for different bandwidths and different playback qualities. The program player of the mobile device measures the maximum bandwidth of a connection with a mobile network to which the mobile device is attached. The program player selects and obtains the appropriate index file from the network device based on the measured maximum bandwidth. The index file (e.g., an M3U8 playlist) includes a list of video files or segments (e.g., transport stream (ts) files) of the program for a particular bitrate. The index file may also include a network address (e.g., a Uniform Resource Locator (URL)) to obtain a license key. The program player may obtain the license key and obtains the transport stream (ts) files, one by one in sequence via a unicast delivery (e.g., a Hypertext Transfer Protocol (HTTP) unicast) from a network device of the content delivery network. The program player saves the transport stream files into a buffer of the mobile device. The program player uses video library functions on the mobile device to perform playback of the program from the buffer while using the license key for decryption. 
     While the existing approach for delivery and playback of the program to a mobile device may provide a reasonable quality-of-service, when bandwidth is in high demand, such as wireless bandwidth within a mobile network, using unicast delivery to provide the transport stream files to the mobile device may not be efficient. As a comparative, one streaming server may serve, via multicasting, 300 channels and 10 million users using 1.5 Gigabits per second (Gbps) of network capacity, whereas 10,000 streaming servers may be needed to serve, via unicasting, 300 channels using 50 Terabits per second (Tbps) of network capacity. 
     According to an exemplary embodiment, a network device obtains a file that indicates a list of possible bitrates available for a program and names of metadata files pertaining to transport stream files of the program. According to an exemplary implementation, the file is a manifest file. For example, the manifest file indicates a list of bitrates and corresponding names of M3U8 files. According to an exemplary embodiment, the network device obtains, for each bitrate, a corresponding metadata file. For example, according to an exemplary implementation, the network device obtains the M3U8 file for each bitrate. 
     According to an exemplary embodiment, the network device adds metadata to the metadata file (e.g., the M3U8 file). According to an exemplary embodiment, the added metadata indicates a multicast channel, and a date and time of a multicast delivery, from which a user device (e.g., a mobile device) may obtain the corresponding transport stream files of a particular bitrate of the program. For example, according to an exemplary implementation, the network device adds text to the M3U8 file that indicates a multicast channel of the mobile network, such as a Long Term Evolution (LTE) multicast channel (e.g., a Multimedia Broadcast Multicast Service (MBMS) channel) and a date and time the multicast of the transport stream files will occur. 
     According to an exemplary embodiment, the network device obtains the transport stream files and, if needed, segments each transport stream file to a size of the maximum transmission unit (MTU) supported by the multicast channel. According to an exemplary embodiment, the network device is a part of the content delivery network and multicasts the transport stream files. For example, the network device may be implemented as a program server device that services user requests for programs. According to another exemplary embodiment, another network device may multicast the segmented transport stream files. 
     According to an exemplary embodiment, a user device includes a program server. According to an exemplary embodiment, the user device is a mobile device and the program server includes an HTTP program server. As described further below, according to an exemplary embodiment, the program server streams transport stream files of a program to a program player. For example, the program server uses the HTTP unicast protocol to stream the transport stream files to the program player of the user device. According to another exemplary embodiment, the program player may perform a local fetch from a memory or a storage device where the transport streams are stored, without the program server streaming the transport stream files of the program to the program player. Depending on where the program sever stores the transport stream files, the local fetch may include that the program player loads the transport stream files into a buffer used by the program player or the transport stream files may already be stored in the buffer. According to an exemplary embodiment, the program player resides on the user device. According to another exemplary embodiment, the program player resides on another user device. According to yet another exemplary embodiment, there may be multiple program players. For example, one program player may reside on the user device and one or multiple program players may reside on one or multiple other user devices. In this way, the program server of the user device may provide a program sharing service that allows the program server to stream a program to other program players of other user devices. 
     According to an exemplary embodiment, the program server obtains a file that indicates a list of possible bitrates available for a program and names of metadata files pertaining to transport stream files of the program. According to an exemplary implementation, the file is the manifest file. According to an exemplary embodiment, the program server obtains the appropriate index file from the network device of the content delivery network. The index file (e.g., an M3U8 playlist) includes a list of video files or segments (e.g., transport stream files) of the program for a particular bitrate and the multicast information (e.g., information indicating the multicast channel and a date and time the multicast of the transport stream files will occur). The index file may also include a network address (e.g., a Uniform Resource Locator (URL)) to obtain a license key. 
     According to an exemplary embodiment, the program server obtains the index file for each bitrate. According to another exemplary embodiment, the program server obtains the index file for fewer than all of the available bitrates. For example, the program server measures a maximum bandwidth of a connection between the user device and the network device of the content delivery network and/or a maximum bandwidth of a connection between the user device and another user device. 
     According to an exemplary embodiment, the program server tunes, via a receiver, to the multicast channel of a wireless network, based on the multicast information, and obtains the segmented transport stream files pertaining to the appropriate bitrate. According to an exemplary embodiment, the program server reassembles the MTUs of each segmented transport stream file to form the transport stream files belonging to the bitrate. The program server stores the assembled transport stream files on the user device. According to an exemplary embodiment, the program server streams the assembled transport stream files, using a unicast protocol (e.g., the HTTP unicast protocol), to a program player. 
     According to an exemplary embodiment, a user device includes a program player. According to an exemplary embodiment, the program player measures the maximum bandwidth of a connection with a wireless network to which the user device is attached. The program player selects and obtains the appropriate index file from the network device of the content delivery network based on the measured bandwidth. The index file (e.g., an M3U8 playlist) includes a list of video files or segments (e.g., transport stream files) of the program for a particular bitrate and the multicast information. The index file may also include a network address (e.g., a URL) to obtain a license key. The program player may obtain the license key from the content delivery network. 
     According to an exemplary embodiment, the program player determines whether the program server has the transport stream files of the program for the particular bitrate. When a transport stream file is available from the program server, the program player obtains the transport stream file from the program server. For example, as previously described, the program server streams (e.g., using the HTTP unicast protocol) the transport stream files of the program to the program player. Alternatively, the program player determines whether the transport stream files are stored (e.g., in the buffer or other storage area, as stored by the program server). When a transport stream file is not available from the program server, the program player obtains the transport stream file from the network device of the content delivery network. Also, when a transport stream file is available, but the transport stream file has uncorrectable errors, the program player obtains the transport stream file from the network device of the content delivery network. The program player saves the transport stream files into a buffer of the user device. The program player uses video library functions on the user device to perform playback of the program from the buffer while using the license key for decryption. 
       FIG. 1  is a diagram illustrating an exemplary environment in which an exemplary embodiment of multicast and unicast adaptive bitrate services may be implemented. As illustrated, environment  100  includes a content delivery network  105 , which includes content devices  110 - 1  through  110 -X (also referred to collectively as content devices  110  and individually or generally as content device  110 ). As further illustrated, environment  100  includes a user device  150  and a user device  155 . 
     Environment  100  may be implemented to include wired, optical, and/or wireless connections among the devices and the network illustrated. A connection may be direct or indirect and may involve an intermediary device and/or an intermediary network not illustrated in  FIG. 1 . Additionally, the number, type (e.g., wired and wireless), and the arrangement of connections between the devices and the networks are exemplary. 
     A device may be implemented according to a centralized computing architecture, a distributed computing architecture, or a cloud computing architecture (e.g., an elastic cloud, a private cloud, a public cloud, etc.). Additionally, a device may be implemented according to one or multiple network architectures (e.g., a client device, a server device, a peer device, a proxy device, and/or a cloud device). 
     The number of devices, the number of networks, and the configuration in environment  100  are exemplary. According to other embodiments, environment  100  may include additional devices, fewer devices, and/or differently arranged devices, than those illustrated in  FIG. 1 . For example, a single device in  FIG. 1  may be implemented as multiple devices. By way of further example, user device  150  may include multiple devices, such as a display and a computer. 
     Additionally, or alternatively, environment  100  may include additional networks and/or differently arranged networks, than those illustrated in  FIG. 1 . For example, environment  100  may include an intermediary network. The types of devices and the types of networks in environment  100  are also exemplary. Also, according to other embodiments, one or more functions and/or processes described as being performed by a particular device may be performed by a different device, or some combination of devices. 
     Content delivery network  105  includes a network that provides access to and use of a program service. Generally, content delivery network  105  may be implemented as a satellite-based network, a terrestrial-based network, or a combination thereof. Content delivery network  105  may be implemented to distribute programs using various technologies, such as an optical architecture, a coaxial cable architecture, an Internet Protocol (IP) TV architecture, a digital subscriber line (DSL) architecture, a wireless architecture, and/or an Internet-based architecture. Depending on the architecture implemented, content delivery network  105  may include various types of network devices that contribute to the provisioning and distribution of the program service. 
     Content devices  110  include network devices that provide the program service. According to an exemplary embodiment, content devices  110  include network devices that provide various program services, such as a program processing device (e.g., transcoding, encryption, etc.), a digital rights management device, a licensing device, a login device (e.g., authentication, authorization, etc.), a program storage device, a metadata storage device, and a program server device. Content devices  110  may include other types of network devices, such as a billing device, a program recommendation device, a user account management device, etc. For purposes of description, content device  110 - 1  includes a program server device, as described herein. For example, content device  110 - 1  obtains the manifest file, obtains the M3U8 file for each bitrate, modifies the M3U8 file by adding multicast information, obtains the transport stream files, segments the transport stream files based on the MTU of the multicast channel, and multicasts the segmented transport stream files. 
     User device  150  includes a device that provides the multicast and unicast adaptive bitrate services. According to an exemplary embodiment, user device  150  is a mobile device. For example, user device  150  may be implemented as a smartphone, a tablet device, a computer (e.g., a laptop computer, a netbook, a palmtop computer, etc.), or some other type of end user device (e.g., an Internet access device, a user-worn device, etc.). According to another exemplary embodiment, user device  150  is a non-mobile device or a stationary device. For example, user device  150  may be implemented as a television and a set top box, a desktop computer, etc. 
     According to an exemplary embodiment, user device  150  includes the program server, as described herein. For example, the program server obtains the manifest file, obtains the M3U8 file for each bitrate or some other number of bitrates, obtains the transport stream files based on the multicast information, reassembles the segmented chunks of a transport stream file into a transport stream file for each transport file of a bitrate, and unicasts the transport stream files of the program of a particular bitrate to a program player. 
     According to an exemplary embodiment, user device  150  includes the program player, as described herein. For example, the program player obtains the manifest file, obtains the M3U8 file for a particular bitrate based on a maximum bandwidth measurement, determines whether the program server of user device  150  has any of the transport stream files, obtains a transport stream file from the program server of user device  150  when the program server has the transport stream file, obtains a transport stream file from the program server of content device  110  when the program server of user device  150  does not have the transport stream file or the transport stream file has an error that is uncorrectable. The program player also plays the transport stream files. 
     User device  155  includes a device that can play a program. For example, user device  155  may be implemented as a mobile device. User device  155  includes the program player. According to other exemplary environments, user device  155  may not exist or there may be multiple user devices  155 . 
       FIGS. 2A-2G  are diagrams illustrating an exemplary scenario pertaining to an exemplary embodiment of the multicast and unicast adaptive bitrate service. As illustrated in  FIG. 2A , content delivery network  105  includes a program metadata device  205 , a program server device  210 , and a license server device  215 . Program metadata device  205 , program server device  210 , and license server device  215  are network elements of content devices  110 , as previously illustrated and described in relation to  FIG. 1 . 
     Program metadata device  205  provides a storefront for users to select programs for viewing and/or listening. For example, program metadata device  205  stores metadata pertaining to the programs, such as title, genre, length of time of a program, format (e.g., high definition,  3 D, etc.), program summary, cast and crew information, name of band, posters, etc. Program server device  210  provides multicast and unicast adaptive streaming services, as described herein. License server device  215  stores license keys for decrypting a program for user viewing and/or listening. Program repository device  217  stores programs and various files (e.g., manifest files, M3U8 files, etc.). 
     Mobile network  220  is a wireless network that provides access to content delivery network  105 . For example, mobile network  220  may be implemented as an LTE network, a Code Division Multiple Access (CDMA) network, a Universal Mobile Telecommunications System (UMTS) network, a Global System for Mobile Communications (GSM) network, a Wideband Code Division Multiple Access (WCDMA) network, a High-Speed Packet Access (HSPA) network, an Evolution Data Optimized (EV-DO) network, and/or another type of wireless network (e.g., an LTE Advanced network, or future generation wireless network architecture). According to other implementations, other types of wireless networks may be used, such as a WiFi network, etc., as well as other types of networks, such as the Web, the Internet, etc., to access content delivery network  105 . According to other embodiments, however, an exemplary environment may not include a mobile network (e.g., mobile network  220 ), a wireless network, and/or a user device (e.g., user device  150 ) that is a mobile device. 
     Referring to  FIG. 2A , assume program server device  210  obtains programs (e.g., program data) from program repository device  217 . For example, an edge server controller or a program management system (not illustrated) may manage the caching of programs on program server device  210  based on well-known methods, proprietary methods, algorithms (e.g., a Least Recently Used (LRU) algorithm, a Least Frequently Used (LFU) algorithm, etc.), statistical information, etc. Alternatively, program server device  210  may manage its own caching of programs based on various methods (e.g., collaborative caching, etc.). Additionally, program server device  210  obtains files pertaining to the programs. For example, program server device  210  obtains a manifest file and M3U8 files associated with each bitrate for the program from program repository device  217 . Program server device  210  stores the programs and the files. 
     Referring to  FIG. 2B , program server device  210  adds multicast information to each M3U8 file. Provided below is a portion of an exemplary, modified M3U8 file:
         #EXTM3U   #EXT-X-VERSION:2   #EXT-X-TARGET DURATION: 10   #EXT-X-KEY: METHOD=AES-128, URI=http://localhost:999/histkey?psw=AS0tbGM (location of license key)   #EXTINF:9,   KOVU1376-00-0.TS (list of transport stream files)   #EXTINF:8,   KOVU1376-00-1.TS   #EXTINF:10,   KOVU1376-00-2.TS   .   .   .   #EXTINF:8,   KOVU1376-00-100.TS   #EXTINF: MULTICAST (multicast information)   CHANNEL: 12   DATE/TIME: Oct. 30, 2014, 2:15 P.M.       

     As illustrated above, the M3U8 file includes a location of a license key and a list of transport stream files of a particular bitrate for a program. Program server device  210  adds the multicast information, such as a multicast channel (e.g., an Internet Protocol address, a port number, a channel number, etc.) and a date and time of a multicast of the program. According to an exemplary embodiment, program server device  210  may not add multicast information to an M3U8 file until at least one user request or a minimum number of user requests for the program of the particular bitrate are received. In this way, program server device  210  may schedule the date and the time of the multicast in accordance with user demand of the program. According to another exemplary embodiment, program server device  210  may add multicast information to an M3U8 file without necessarily receiving a user request for the program. For example, program server device  210  may multicast the program based on a schedule provided by the program service provider. By way of further example, program server device  210  may use information similar to an electronic programming guide (EPG) to schedule the date, the time, and the multicast channel for multicasting a program. 
     Referring to  FIG. 2B , program server device  210  segments each transport stream file into smaller chunks based on the MTU size of the multicast channel. For example, program server device  210  may segment each transport stream file based on the multicast channel of mobile network  220 . Depending on the type of wireless network, the MTU size may be different. Thus, program server device  210  may segment each transport stream file based on multiple sizes of MTUs, which may correspond to different mobile networks (e.g., CDMA, LTE, etc.). For example, program server device  210  stores MTU information that indicates the MTU sizes of multicast channels for multiple types of wireless networks. Program server device  210  uses the stored MTU information when segmenting each transport stream file. In this way, program server device  210  may store an array of segmented transport stream files for a variety of MTUs. Program server device  210  stores the segmented transport stream files and the modified M3U8 files. 
     Referring to  FIG. 2C , assume a user  225  of user device  150  connects to program metadata device  205  so as to select a program for an adaptive streaming session. Program metadata device  205  provides a user interface that allows user  225  to select a program of his or her choice. Assume, user  225  selects a program and user device  150  is redirected to program server device  210 . The program server of user device  150  obtains a manifest file belonging to the selected program from program server device  210 . Provided below is a portion of an exemplary manifest file:
         #EXTM3U   #EXT-X-STREAM-INF:BANDWIDTH=256000 (Bitrate of M3U8 file)   KOVU1377622.001.m3u8 (M3U8 file)   #EXT-X-STREAM-INF:BANDWIDTH=160000 (Bitrate of M3U8 file)   KOVU1377622.006.m3u8 (M3U8 file)   .   .   .   #EXT-X-STREAM-INF:BANDWIDTH=864000 (Bitrate of M3U8 file)   KOVU1377622.0016.m3u8 (M3U8 file)       

     According to an exemplary embodiment, the program server of user device  150  can select one or multiple bitrates corresponding to one or multiple M3U8 files. For example, according to an exemplary embodiment, the program player may communicate with the program server to inform the program server of the M3U8 file to select. For example, as described further below in relation to  FIG. 2E , the program player may select the M3U8 file based on a measured maximum bandwidth pertaining to a connection with mobile network  220 . 
     Alternatively, according to another exemplary embodiment, the program server of user device  150  may select one or multiple M3U8 files. The program server of user device  150  may select the particular M3U8 file based on the communication with the program player, historical bitrate information based on past usage of mobile network  220  or a combination of all wireless networks used, location of user device  150 , and/or other criteria or policies (e.g., obtain a high bitrate and a low bitrate, etc.). 
     Referring to  FIG. 2C , the program server of user device  150  reads the multicast information from one or multiple M3U8 files, which have been selected, to determine when a multicast is to take place. Program server device  210  may multicast segmented transport stream files belonging to a particular bitrate of the program on a single multicast channel. Alternatively, program server device  210  may multicast segmented transport stream files belonging to different bitrates of the program on a single multicast channel. By way of further example, the multicast channel may carry, in a time-slotted, interleaving manner, the segmented transport stream files belonging to different bitrates. According to other implementations, different bitrates may be multicast through other conventional methods (e.g., frequency hopping, etc.). According to another example, the program server of user device  150  may obtain multiple M3U8 files by tuning to multiple multicast channels (e.g., either simultaneously or intermittently depending on the communication interface capabilities of user device  150 ). 
     Depending on the type of program, the multicast information may allow the program server of user device  150  to obtain the M3U8 file(s) with little delay. For example, assume that user  225  selected a program that is a live program or a program that is scheduled according to an EPG. If user  225  selects the program near its scheduled time, the program server may obtain the M3U8 file(s) with little delay since a multicast of the segmented transport stream files is likely to occur near its scheduled time (as would be indicated by the multicast information included in the M3U8 file). According to other examples, such as a video-on-demand program, a pay-per-view program, etc., the multicast information may indicate that the program server of user device  150  will have to wait some period of time before a next multicast is to take place. According to an exemplary embodiment, the program server of user device  150  determines whether the wait time period is beyond a threshold time period. For example, the program server calculates a wait time period (e.g., using the current time and the time of the multicast) and compares the wait time period to a threshold wait time period. When the wait time period is shorter than the threshold wait time period, the program server will join the future multicast. Otherwise, the program server may obtain the program from a unicast delivery from program server device  210 . The program server may also prompt the user as to the wait time period, via a user interface, and obtain instructions (e.g., a user input via the user interface) from the user as to how to proceed. 
     Additionally, according to an exemplary embodiment, the program server of user device  150  may initially receive the transport stream files of the program from program server device  210  via a unicast delivery, and subsequently switch to (e.g., join) a multicast of the program. By way of example, this may occur when the user pauses or stops the program for a period of time, or rewinds or replays a portion of the program. For example, the program player of user device  150  may monitor trickplay input or user input during the playing of the program to determine whether a triggering event satisfies certain criteria (e.g., a pause or a series of pauses that last a threshold period of time, a stop or a series of stops that last a threshold period of time, a rewind to a particular portion of the program that is equivalent to a particular length of the program, time period, etc.). When the program player determines that the triggering event occurs, the program player informs the program server. The program server of user device  150  uses this information and the multicast information to calculate whether segmented transport stream files from the multicast could be used in continuance of the playing of the program or streaming session. For example, the program server of user device  150  may determine the current time window of playback of the program relative to the multicast and the current position of playback of the program in relation to the user. When the program server determines that the segmented transport stream files from the multicast could be used, the program server joins the multicast. 
     According to an exemplary embodiment, the program server of user device  150  pre-fetches a program based on program recommendation logic, an advertisement from program metadata device  205  indicating a new program available, input from user  225  that indicates to have a particular program stored on user device  150  by a particular date and/or time, etc. In this way, the program server of user device  150  may minimize the delay that user  225  may have to wait before the segmented transport stream files are obtained from a multicast, reassembled, and ready for playback. According to yet another exemplary embodiment, the program server or the program player of user device  150  may obtain transport stream files from program server device  210  based on a unicast delivery (e.g., an HTTP unicast) when the wait time for obtaining the segmented transport stream files from a multicast is beyond a particular time period threshold. 
     Referring to  FIG. 2D , assume that the program server of user device  150  uses the multicast information to obtain segmented transport stream files belonging to one or multiple bitrates from a multicast provided by program server device  210 . For example, user device  150  joins the multicast of the segmented transport stream files of the program based on conventional methods (e.g., tuning to a particular channel, connect to an IP address, port number, etc.). The program server of user device  150  receives the segmented transport stream files via mobile network  220 , and reassembles the segmented transport stream files into transport stream files, as previously described. Additionally, the program server of user device  150  stores the transport stream files in a buffer (e.g., for immediate playback) or other memory/storage (e.g., in a pre-fetch case). 
     Referring to  FIG. 2E , the program player of user device  150  may assist in the selection of the M3U8 file. For example, the program player of user device  150  may obtain the manifest file (e.g., from program sever device  210  or the program server of user device  150 ), measure the maximum bandwidth of a connection with mobile network  220 , and select a bitrate from the manifest file and corresponding M3U8 file. The program player of user device  150  may indicate the selected bitrate and/or M3U8 file to the program server of user device  150 . This process loops so that the program player of user device  150  obtains the appropriate transport stream files that best match the measured maximum bandwidth and corresponding bitrate during the course of the playing of the program. For example, the program player of user device  150  may periodically measure the maximum bandwidth and provide this information to the program player of user device  150  to provide for an adaptive bitrate streaming session of the program. The program server of user device  150  obtains, in turn, based on the updated maximum bandwidth, the segmented transport stream files corresponding to the appropriate bitrate from a particular multicast (e.g., based on the multicast information). 
     Referring to  FIG. 2F , when the program player of user device  150  is invoked to playback the program, the program player determines whether the transport stream files of the program are available from the program server of user device  150 . For example, the program player may communicate with the program server of user device  150  and requests the program. When the program server has stored at least a portion of the program (e.g., the program server of user device  150  is receiving the multicast) or has already stored all of the program, the program server of user device  150  transmits each transport stream file, one by one in sequence (e.g., an HTTP unicast), to the program player and saves each transport stream file in the buffer that the program player uses for playback. Alternatively, the program player may fetch each transport stream file from, for example, a local memory that stores the transport stream files. When the program server of user device  150  indicates that it does not have the program or any particular transport stream file (e.g., due to a problem or an error that occurred during the multicast, etc.), then the program player establishes a session (e.g., an HTTP unicast session) with program server device  210  to obtain the program or the particular transport stream file. 
     According to an exemplary embodiment, the program player provides an error correction service that uses conventional forward error correction to correct an error in a transport stream file. In the event that the transport stream file has an error that cannot be corrected, the program player establishes a session (e.g., an HTTP unicast session) with program server device  210  to obtain an error-free, transport stream file. Alternatively, the program server of user device  150  provides the error correction service. 
     As further illustrated in  FIG. 2F , the program player of user device  150  obtains the license key from license server device  215  based on the URI indicated in the M3U8 file. For example, the program server may provide the URI to the program player or the program player may obtain the M3U8 file and read the URI from the file. Referring to  FIG. 2G , the program player of user device  150  uses video library functions to perform playback of the program from the buffer while using the license key for decryption. During this time, the program server of user device  150  may be receiving segmented transport stream files of a program (e.g., when the program is a live program) from program server device  210  during playback of the program. Additionally, the program player of user device  150  may receive a unicast transport stream from program server device  210  during playback, as previously described. 
     Although  FIGS. 2A-2G  illustrate an exemplary scenario pertaining to the multicast and unicast adaptive bitrate service, according to other scenarios, other types of processes may be performed. 
     As previously described, the program server of user device  150  may provide a program sharing service that allows the program server to stream a program to other program players of other user devices  155 . Referring to  FIG. 2H , assume user  225 - 1  of user device  150  and a user  225 - 2  of user device  155  are traveling in a car. User  225 - 1  and user  225 - 2  both agree to watch a same movie. However, user device  155  is unable to connect to mobile device  220 . For example, user device  155  may be a legacy device. User device  150  is able to connect mobile network  220  and has hotspot capabilities, which user device  155  is able to use. User device  155  establishes a wireless connection with user device  150  so that a streaming session with the program server of user device  150  can occur. In a manner similarly to that previously described, the program server of user device  150  obtains transport stream files belonging to one or multiple bitrates. Additionally, for example, the program player of user device  155  may measure the bandwidth of the connection between user device  155  and user device  150 . The program player of user device  155  communicates this information to the program server of user device  150 . The program server of user device  150  uses this information to select a particular bitrate and corresponding segmented transport stream files to receive, reassemble, etc. The program player of user device  155  receives the transport stream files from user device  150  and user  225 - 2  views the program. In the event that a transport stream file is not available or contains an error that is not correctable, the program server of user device  150  obtains the transport stream file from program server device  210 . 
     Although  FIG. 2H  illustrates an exemplary scenario pertaining to the multicast and unicast adaptive bitrate service, according to other scenarios, other types of processes may be performed. For example, the program server of user device  150  may pre-fetch a program and have the program available for other user devices and users. Thus, according to another scenario, user device  155  may detect user device  150  as having the program server and program sharing service capabilities. User  225 - 2  may view the available programs stored on user device  150  via a user interface. User  225 - 2  may select one of the programs already stored on user device  150  for viewing on user device  155  via the program player of user device  155 . 
       FIG. 3  is a diagram illustrating exemplary components of a device  300  that may correspond to one or more of the devices in the environments described herein. For example, device  300  may correspond to content device  110 , user device  150 , user device  155 , as well as other devices illustrated and described. As illustrated in  FIG. 3 , according to an exemplary embodiment, device  300  includes a processor  305 , memory/storage  310  that stores software  315 , a communication interface  320 , an input  325 , and an output  330 . According to other embodiments, device  300  may include fewer components, additional components, different components, and/or a different arrangement of components than those illustrated in  FIG. 3  and described herein. 
     Processor  305  includes one or multiple processors, microprocessors, data processors, co-processors, application specific integrated circuits (ASICs), controllers, programmable logic devices, chipsets, field-programmable gate arrays (FPGAs), application specific instruction-set processors (ASIPs), system-on-chips (SoCs), central processing units (CPUs) (e.g., one or multiple cores), microcontrollers, and/or some other type of component that interprets and/or executes instructions and/or data. Processor  305  may be implemented as hardware (e.g., a microprocessor, etc.), a combination of hardware and software (e.g., a SoC, an ASIC, etc.), may include one or multiple memories (e.g., cache, etc.), etc. 
     Processor  305  may control the overall operation or a portion of operation(s) performed by device  300 . Processor  305  may perform one or multiple operations based on an operating system and/or various applications or computer programs (e.g., software  315 ). Processor  305  may access instructions from memory/storage  310 , from other components of device  300 , and/or from a source external to device  300  (e.g., a network, another device, etc.). 
     Memory/storage  310  includes one or multiple memories and/or one or multiple other types of storage mediums. For example, memory/storage  310  may include one or multiple types of memories, such as, random access memory (RAM), dynamic random access memory (DRAM), cache, read only memory (ROM), a programmable read only memory (PROM), a static random access memory (SRAM), a single in-line memory module (SIMM), a dual in-line memory module (DIMM), a flash memory, and/or some other type of memory. Memory/storage  310  may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.) and a corresponding drive. Memory/storage  310  may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.), a Micro-Electromechanical System (MEMS)-based storage medium, and/or a nanotechnology-based storage medium. Memory/storage  310  may include drives for reading from and writing to the storage medium. 
     Memory/storage  310  may be external to and/or removable from device  300 , such as, for example, a Universal Serial Bus (USB) memory stick, a dongle, a hard disk, mass storage, off-line storage, or some other type of storing medium (e.g., a compact disk (CD), a digital versatile disk (DVD), a Blu-Ray® disk (BD), etc.). Memory/storage  310  may store data, software, and/or instructions related to the operation of device  300 . 
     Software  315  includes an application or a program that provides a function and/or a process. In this context, the term “program” is used in the sense of a sequence of instructions designed for execution on a computer system. A “program” or a “computer program” may include a subroutine, a function, a procedure, an object method, an object implementation, an applet, a servlet, a source code, an object code, a shared library/dynamic load library and/or other sequence of instructions designed for execution on a computer system. The term “program,” when used to mean, for example, audio and/or video data versus used to mean a set of instructions will be apparent from the context of use in the present document. As an example, with reference to content device  110 , software  315  may include an application that, when executed by processor  305 , provides the functions of the multicast and unicast adaptive bitrate services, as described herein. Additionally, for example, with reference to user device  150 , software  315  may include an application that, when executed by processor  305 , provides the functions of the multicast and unicast adaptive bitrate services, as described herein. Software  315  may include firmware. 
     Communication interface  320  permits device  300  to communicate with other devices, networks, systems, and/or the like. Communication interface  320  includes one or multiple wireless interfaces and/or wired interfaces. For example, communication interface  320  may include one or multiple transmitters and receivers or transceivers. Communication interface  320  may operate according to a protocol stack and a communication standard. 
     Input  325  permits an input into device  300 . For example, input  325  may include a keyboard, a mouse, a display, a touchscreen, a touchless screen, a button, a switch, an input port, speech recognition logic, and/or some other type of visual, auditory, tactile, etc., input component. Output  330  permits an output from device  300 . For example, output  330  may include a speaker, a display, a touchscreen, a touchless screen, a light, an output port, and/or some other type of visual, auditory, tactile, etc., output component. 
     Device  300  may perform a process and/or a function, as described herein, in response to processor  305  executing software  315  stored by memory/storage  310 . By way of example, instructions may be read into memory/storage  310  from another memory/storage  310  (not shown) or read from another device (not shown) via communication interface  320 . The instructions stored by memory/storage  310  causes processor  305  to perform a process described herein. Alternatively, for example, according to other implementations, device  300  performs a process described herein based on the execution of hardware (processor  305 , etc.). 
       FIG. 4  is a flow diagram illustrating an exemplary process  400  pertaining to the multicast and unicast adaptive bitrate services. Process  400  is directed to a process previously described above with respect to  FIGS. 2A-2G  and elsewhere in this description, in which content device  110  of content delivery network  105  uses multicast delivery for HTTP-based adaptive bitrate streaming sessions. As previously described, various types of programs, such as linear television programs, live programs, video-on-demand programs, pay-per-view programs, etc., may be multicasted to users based on an HTTP-based adaptive bitrate streaming delivery. This is in contract to conventional approaches in which programs (e.g., transport stream files) are unicasted to users using an adaptive bitrate delivery system. According to an exemplary embodiment, content device  110  performs one or more of the steps described in process  400 . For example, processor  305  of program server device  210  executes software  315  to perform the steps described. 
     Referring to  FIG. 4 , block  405 , process  400  begins in which a program, and a manifest file and M3U8 files pertaining to the program for each bitrate are received. For example, program server device  210  obtains the program (e.g., program data) and the files from program repository device  217 . Program server device  210  may also receive other information, such as a program schedule. The program schedule provides date, day, and time information pertaining to when the program is to be provided or made available (e.g., multicasted, etc.) to users. For example, the program schedule may be an entry or a part of an EPG for a live program or a pre-recorded program. Alternatively, the program may be an on-demand program or a pay-per-view program. The program schedule may be geographic-specific (e.g., a certain locale of the United States, etc.). Additionally, the program schedule may be dynamic based on user demand. For example, a minimum number of requests (e.g., overall or within a particular geographic region) for an on-demand program or a pay-per-view program may be needed before a multicast is scheduled and provided. Additionally, for example, other factors, such as the popularity of the program may influence the program schedule and the frequency and number of multicasts. 
     In block  410 , multicast information is added to each M3U8 file of each bitrate. For example, program server device  210  adds multicast information (e.g., inserts text) into the M3U8 file. The multicast information may include a multicast channel and a date and time of the multicast of the program. The multicast information may be based on the program schedule and/or user demand. 
     In block  415 , each transport stream file of a bitrate is segmented based on an MTU of a network. Program server device  210  segments each transport stream file based on the multicast channel of mobile network  220 . For example, program server device  210  may segment each transport stream file based on multiple sizes of MTUs, which may correspond to different mobile networks (e.g., CDMA, LTE, etc.). 
     In block  420 , the segmented transport stream files and the modified M3U8 files are stored. For example, program server device  210  stores the segmented transport stream files and the modified M3U8 files, along with the manifest file, which pertain to the program. 
     In block  425 , the manifest file is provided to a user device. Program server device  210  provides the manifest file and the M3U8 files for any bitrate to user device  150 . For example, the program server of user device  150  and/or the program player of user device  150  may obtain the manifest file and the M3U8 file for a particular bitrate, upon request. 
     In block  430 , the segmented transport stream files are multicast based on the multicast information. For example, program server device  220  multicasts the program to program servers of user devices  150  based on the multicast information. 
     Although  FIG. 4  illustrates an exemplary process  400 , according to other embodiments, process  400  may include additional operations, fewer operations, and/or different operations than those illustrated in  FIG. 4  and described. For example, program server device  220  may unicast a program or one or multiple transport stream files to user devices  150 , as previously described. 
       FIGS. 5A and 5B  are flow diagrams illustrating another exemplary process  500  pertaining to the multicast and unicast adaptive bitrate services. Process  500  is directed to a process previously described above with respect to  FIGS. 2A-2G  and elsewhere in this description, in which user device  150  receives transport stream files from a multicast via an HTTP-based adaptive bitrate streaming session and provides an HTTP-based unicast delivery to a program player. As previously described, various types of programs, such as linear television programs, live programs, video-on-demand programs, pay-per-view programs, etc., may be multicasted to users based on an HTTP-based adaptive bitrate streaming delivery. According to an exemplary embodiment, a program server of user device  150  performs one or more of the steps described in process  500 . For example, processor  305  of a mobile device executes software  315  to perform the steps described. 
     Referring to  FIG. 5A , in block  505 , a user device obtains a manifest file pertaining to a program. For example, the program server of user device  150  obtains the manifest file pertaining to a program selected by or recommended for a user of user device  150 . As previously described, an exemplary manifest file lists identifiers (e.g., names) of M3U8 files and their corresponding bandwidths and/or bitrates. 
     In block  510 , one or multiple M3U8 files are selected from the manifest file. For example, the program server of user device  150  selects an M3U8 file and corresponding bandwidth and/or bitrate, from the manifest file, based on a measured maximum bandwidth pertaining to a connection with the mobile network  220 . For example, a program player of user device  150  may communicate the maximum bandwidth to the program server of user device  150 . Alternatively, the program server of user device  150  may select one or multiple M3U8 files based on other information (e.g., historical bitrate information, location of user device  150 , and/or other policies). 
     In block  515 , the multicast information is read from the one or multiple M3U8 files. For example, the program server of user device  150  reads the multicast information from the M3U8 file. In this way, the program server of user device  150  is able to receive the segmented transport stream files of a particular bit rate from a multicast provided by program server device  210 . 
     In block  520 , segmented transport stream files are received from a multicast. For example, the program server of user device  150  joins a multicast pertaining to a particular bitrate of the program based on the multicast information. The program server of user device  150  receives the segmented transport stream files from program server device  210 . 
     In block  525 , the segmented transport stream files are assembled into transport stream files. For example, the program server of user device  150  assembles the segmented transport stream files of the particular bitrate into transport stream files. The program server of user device  150  stores the assembled transport stream files. 
     In block  530 , a request for a transport stream file is received from a program player. For example, the program server of user device  150  receives a request from the program player of user device  150  for a transport stream file of a particular bit rate. 
     Referring to  FIG. 5B , it is determined whether the transport stream file is available (block  535 ). For example, the program server of user device  150  searches the stored transport stream files to determine whether the requested transport stream file is available. 
     When it is determined that the requested transport stream file is not available (block  535 —NO), a negative response is transmitted (block  540 ). For example, the program server of user device  150  indicates to the program player of user device  150  that the requested transport stream file is not available. When it is determined that the requested transport stream file is available (block  535 —YES), the requested transport stream file is unicasted (block  545 ). For example, the program player of user device  150  unicasts the requested transport stream to the program player of user device  150  using HTTP. 
     In block  550 , it is determined whether the program has ended. For example, the program server of user device  150  determines whether there are additional transport stream files to obtain for the program. For example, the program server of user device  150  may use information included in the M3U8 file to identify a last transport stream file (e.g., by name, etc.). When it is determined that the program has not ended (block  550 —NO), it is determined whether another transport stream file is available (block  555 ). For example, the program server of user device  150  may determine whether one or a certain number of other transport stream files are stored that correspond to a next sequence of one or multiple transport stream files for the program. 
     When it is determined that there is not another transport stream file available (block  555 —NO), then process  500  returns to block  520 . For example, the program player of user device  150  tunes to the multicast pertaining to a particular bitrate of the program based on the multicast information. The program server of user device  150  receives the segmented transport stream files from program server device  210 . The program server of user device  150  may receive maximum bandwidth information from the program player of user device  150 . The program server of user device  150  may use the maximum bandwidth information to select the appropriate bitrate, etc. 
     When it is determined that there is another transport stream file available (block  555 —YES), then process  500  returns to block  530 . For example, the program server of user device  150  receives another request from the program player of user device  150  for another transport stream file. 
     Referring back to block  550 , when it is determined that the program has ended (block  550 —YES), the process  500  ends. For example, the program server of user device  150  ends the multicast session with program server device  210 . The program server of user device  150  also ends communication with the program player of user device  150 . 
     Although  FIGS. 5A and 5B  illustrate an exemplary multicast and unicast adaptive bitrate services process  500 , according to other embodiments, process  500  may include additional operations, fewer operations, and/or different operations than those illustrated in  FIGS. 5A and 5B  and described herein. For example, the program server of user device  150  may not unicast the transport stream file to the program player. Rather, for example, the program server of user device  150  may store the transport stream files in a local memory or other storage area. The local memory or storage area may be a buffer used by the program player of user device  150 . 
       FIGS. 6A and 6B  are flow diagrams illustrating yet another exemplary process  600  pertaining to the multicast and unicast adaptive bitrate services. Process  600  is directed to a process previously described above with respect to  FIGS. 2A-2G  and elsewhere in this description, in which user device  150  receives transport stream files of a multicast via an HTTP-based adaptive bitrate streaming session and provides an HTTP-based unicast delivery to a program player. As previously described, various types of programs, such as linear television programs, live programs, video-on-demand programs, pay-per-view programs, etc., may be multicasted to users based on an HTTP-based adaptive bitrate streaming delivery. According to an exemplary embodiment, a program player of user device  150  performs one or more of the steps described in process  600 . For example, processor  305  of a mobile device executes software  315  to perform the steps described. 
     Referring to  FIG. 6A , in block  605 , a user device obtains a manifest file pertaining to a program. For example, the program player of user device  150  obtains the manifest file pertaining to a program selected by or recommended for a user of user device  150 . 
     In block  610 , a maximum bandwidth of a connection is measured. For example, the program player of user device  150  may measure various metrics to calculate the maximum bandwidth based on conventional methodologies, tools, etc. 
     In block  615 , the measured maximum bandwidth is provided to a program server. For example, the program player of user device  150  communicates one or multiple values indicating the measured maximum bandwidth to the program server of user device  150 . 
     In block  620 , an M3U8 file is selected based on the measured maximum bandwidth. For example, the program player of user device  150  selects an M3U8 file and corresponding bandwidth and/or bitrate, from the manifest file, based on the measured maximum bandwidth pertaining to a connection with the mobile network  220 . 
     In block  625 , a license key is obtained based on a network address included in the M3U8 file. For example, an exemplary M3U8 file includes a network address or Uniform Resource Identifier (URI) for license server device  215 . By way of further example, the URI may include a location of a license key for the program and corresponding transport stream files. 
     It is determined whether a transport stream file is available from the program server (block  630 ). For example, the program player of user device  150  communicates to the program server of user device  150  to obtain the transport stream file pertaining to the program. For example, as transport stream files are buffered for playback, the program player may seek to obtain the transport stream files from the program server of user device  150  before content delivery network  105 . The communication between the program player and the program server may include a request and a response exchange or other suitable communication exchange. 
     When it is determined that the transport stream file is not available from the program server (block  630 —NO), a unicast of the transport stream file is received from a content delivery network (block  635 ). For example, when the program player determines that the program server of user device  150  does not have the transport stream file (e.g., based on a communication from the program server), the program player of user device  150  receives the transport stream file from program server device  210  via an HTTP unicast session. By way of further example, the program player of user device  150  may transmit a request (e.g., directly or via the program server of user device  150 ) to program server device  210 . The request includes data that includes an identifier of the transport stream file and an identifier of the program. 
     When it is determined that the transport stream file is available from the program server (block  630 —YES), a unicast of the transport stream file is received from the program server (block  640 ). For example, when the program player determines that the program server of user device  150  has the transport stream file (e.g., based on a communication from the program server), the program player of user device  150  receives the transport stream file from the program server of user device via an HTTP unicast. 
     Referring to  FIG. 6B , in block  645 , the transport stream file is played. For example, the program player of user device  150  plays the transport stream file. For example, the program player may play this portion of a movie or a song. 
     In block  650 , it is determined whether the program has ended. For example, the program player of user device  150  determines whether there are additional transport stream files to obtain for the program. By way of example, the program player of user device  150  may identify a last transport stream file. 
     When it is determined that the program has not ended (block  650 —NO), it is determined whether to measure a maximum bandwidth (block  655 ). For example, the program player of user device  150  may provide a maximum bandwidth to the program server of user device  150  based on a triggering event. For example, the triggering event may be time-based (e.g., periodically, such as every minute, etc.), a number of times the program server did not have a transport stream file, a number of times a transport stream file had an error that was not correctable, an analysis of the maximum bandwidth signature (e.g., steady state, erratic, etc.), etc. 
     When it is determined not to measure the maximum bandwidth (block  655 —NO), the process  600  continues to block  630 . For example, as previously described, the program player of user device  150  communicates to the program server of user device  150  to obtain the transport stream file pertaining to the program. Based on the communication, the program player determines whether the transport stream file is available from the program server of user device  150 . 
     When it is determined to measure the measure maximum bandwidth (block  655 —YES), the maximum bandwidth is measured and provided to the program server (block  660 ). For example, the operations previously described in relation to blocks  610  and  615  are performed. Thereafter, process  600  continues to block  630 . 
     Referring back to block  650 , when it is determined that the program has ended (block  650 —YES), process  600  ends. For example, the program player of user device  150  ends communication with the program server of user device  150  after playback of a last transport stream file. The playback of the last transport stream file may be based on user input (e.g., a stop command, a closing of the program player, etc.). 
     Although  FIGS. 6A and 6B  illustrate an exemplary multicast and unicast adaptive bitrate services process  600 , according to other embodiments, process  600  may include additional operations, fewer operations, and/or different operations than those illustrated in  FIGS. 6A and 6B  and described herein. For example, the program player of user device  150  may not receive a unicast of the transport stream file from the program server of user device  150 . Rather, the program player of user device  150  may perform a fetch (e.g., from a local memory) of the transport stream files. The program player of user device  150  may load the transport stream files into a buffer. Alternatively, the program server of user device  150  may store the transport stream files into the buffer. 
     The foregoing description of embodiments provides illustration, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Accordingly, modifications to the embodiments described herein may be possible. 
     The terms “a,” “an,” and “the” are intended to be interpreted to include one or more items. Further, the phrase “based on” is intended to be interpreted as “based, at least in part, on,” unless explicitly stated otherwise. The term “and/or” is intended to be interpreted to include any and all combinations of one or more of the associated items. 
     In addition, while series of blocks have been described with regard to the processes illustrated in  FIGS. 4, 5A, 5B, 6A, and 6B , the order of the blocks may be modified according to other embodiments. Further, non-dependent blocks may be performed in parallel. Additionally, other processes described in this description may be modified and/or non-dependent operations may be performed in parallel. 
     The embodiments described herein may be implemented in many different forms of software and/or firmware executed by hardware. For example, a process or a function may be implemented as “logic” or as a “component.” The logic or the component may include, for example, hardware (e.g., processor  305 , etc.), or a combination of hardware and software (e.g., software  315 ). The embodiments have been described without reference to the specific software code since the software code can be designed to implement the embodiments based on the description herein and commercially available software design environments/languages. 
     In the preceding specification, various embodiments have been described with reference to the accompanying drawings. However, various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded as illustrative rather than restrictive. 
     In the specification and illustrated by the drawings, reference is made to “an exemplary embodiment,” “an embodiment,” “embodiments,” etc., which may include a particular feature, structure or characteristic in connection with an embodiment(s). However, the use of the phrase or term “an embodiment,” “embodiments,” etc., in various places in the specification does not necessarily refer to all embodiments described, nor does it necessarily refer to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiment(s). The same applies to the term “implementation,” “implementations,” etc. 
     Additionally, embodiments described herein may be implemented as a non-transitory storage medium that stores data and/or information, such as instructions, program code, data structures, program modules, an application, etc. The program code, instructions, application, etc., is readable and executable by a processor (e.g., processor  305 ) of a computational device. A non-transitory storage medium includes one or more of the storage mediums described in relation to memory/storage  310 . 
     No element, act, or instruction described in the present application should be construed as critical or essential to the embodiments described herein unless explicitly described as such. 
     Use of ordinal terms such as “first,” “second,” “third,” etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another, the temporal order in which acts of a method are performed, the temporal order in which instructions executed by a device are performed, etc., but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.