WO2011091296A1

WO2011091296A1 - Session transfer and bookmarking support for streaming services

Info

Publication number: WO2011091296A1
Application number: PCT/US2011/022116
Authority: WO
Inventors: Michelle Perras; Debashish Purkayastha; Kamel M. Shaheen; Robert G. Gazda
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2010-01-21
Filing date: 2011-01-21
Publication date: 2011-07-28

Abstract

Methods and apparatus for bookmarking streaming media sessions are disclosed. Bookmarks may be used for hypertext transfer protocol (HTTP) streaming media sessions and may support pause and resume functionalities. The bookmarks may be stored at a server or may be stored at a client. The bookmarks may use current HTTP functionalities or may modify existing HTTP functionalities. Methods and apparatus for inter-device session transfer of a streaming media session with bookmarking support are also disclosed. A device currently streaming a media session may initiate the session transfer or a target device may initiate the session transfer. A bookmark may be explicitly requested and stored at the server by a device, may be part of an inter-wireless transmit/receive unit (WTRU) transfer command sent to a server, or may be sent directly from one device to another device.

Description

SESSION TRANSFER AND BOOKMARKING SUPPORT FOR STREAMING

SERVICES

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application Serial No. 61/297,130 filed on January 21, 2010. This application also claims the benefit of U.S. Provisional Application Serial No. 61/297,463 filed on January 22, 2010. All of the above referenced applications are hereby incorporated by reference herein.

BACKGROUND

[0002] Streaming services may be delivered to users via real time streaming protocol (RTSP) or hyper text transfer protocol (HTTP). RTSP is a network control protocol for use in entertainment and communications systems to control streaming media servers. RTSP controls the delivery of real-time data (audio and video) carried over multiple sessions. Clients of media servers issue VCR-like commands, such as play and pause, to facilitate real-time control of playback of media files from the server. The data delivery mechanisms used by RTSP are based on real-time transport protocol (RTP). While RTSP is widely used, the use of RTSP may present several drawbacks. For example, RTSP ports are often blocked by operators, thereby preventing a user from streaming a media session.

[0003] HTTP is an alternative to RTSP. HTTP is a simple client-server protocol that is connectionless, stateless and media-independent. HTTP is used to carry data (unbound streams of multimedia). Improvements in HTTP allow for multiple transactions over a single persistent TCP connection, cache support, chunked encoding, and multiple domains by a single IP address. However, while play, pause, and resume functionalities are currently supported by RTSP, pause and resume are not currently supported by HTTP. Despite the current lack of functionality, using HTTP rather than RTSP for streaming media sessions may be desirable. For example, HTTP ports may not be blocked by operators in the same way that RTSP ports are blocked. Also, HTTP allows for network address translation (NAT) traversal. NAT traversal is a general term for techniques that establish and maintain transmission control protocol/internet protocol (TCP/IP) network and/or user datagram protocol (UDP) connections traversing NAT gateways.

[0004] While HTTP is stateless, the RTSP protocol does include states.

A session identifier may be used in RTSP to keep track of sessions when needed. Thus, no permanent TCP connection may be required. RTSP messages are sent from client to server, although in certain situations, the server may send messages to the client.

[0005] To make HTTP a viable alternative to RTSP, HTTP must support all functionalities already supported by RTSP. HTTP Live Streaming is the equivalent to RTSP streaming. While pause and resume functionalities are supported by RTSP, HTTP Live Streaming does not currently support these functionalities. The inclusion of these functionalities for HTTP may also allow for efficient session transfer of streaming media sessions among or between a plurality of clients.

SUMMARY

[0006] Methods and apparatus for bookmarking streaming media sessions are disclosed. Bookmarks may be used for HTTP streaming media sessions and may support pause and resume functionalities. The bookmarks may be stored at a server or may be stored at a client. The bookmarks may use current HTTP functionalities or may modify existing HTTP functionalities. Methods and apparatus for inter- device session transfer of a streaming media session with bookmarking support are also disclosed. A device currently streaming a media session may initiate the session transfer or a target device may initiate the session transfer. A bookmark may be explicitly requested and stored at the server by a device, may be part of an inter-wireless transmit/receive unit (WTRU) transfer command sent to a server, or may be sent directly from one device to another device. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0008] FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0009] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;

[0010] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;

[0011] FIG. 2 is an example of a server-based bookmarking solution, whereby an HTTP live stream is paused by a user and the bookmark is stored at the server;

[0012] FIG. 3 is an example of a server-based bookmarking solution, whereby an HTTP live stream is resumed by a user using a bookmark stored at the server;

[0013] FIG. 4 is an example of a client-based bookmarking solution, whereby an HTTP live stream is paused by a user and the bookmark is stored at the client;

[0014] FIG. 5 is an example of a client-based bookmarking solution whereby an HTTP live stream is resumed by a user using a bookmark stored by the user;

[0015] FIG. 6 is an example of active device-initiated session transfer of a streaming media session using explicit bookmarking;

[0016] FIG. 7 is an example of active device-initiated session transfer of a streaming media session whereby a bookmark may be created as part of an inter- WTRU transfer command;

[0017] FIG. 8 is an example of active device-initiated session transfer of a streaming media session whereby a bookmark may be created and two or more WTRUs may communicate directly; [0018] FIG. 9 is an example of target device-initiated session transfer of a streaming media session using explicit bookmarking by the original device; and

[0019] FIG. 10 is an example of target device-initiated session transfer of a streaming media session whereby two or more WTRUs may communicate directly and bookmarking may be performed by the original device.

DETAILED DESCRIPTION

[0020] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0021] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like. [0022] The communications systems 100 may also include a base station

114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0023] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple -input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0024] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0025] More specifically, as noted above, the communications system

100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High- Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0026] In another embodiment, the base station 114a and the WTRUs

102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE-A).

[0027] In other embodiments, the base station 114a and the WTRUs

102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0028] The base station 114b in FIG. 1A may be a wireless router, Home

Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106. [0029] The RAN 104 may be in communication with the core network

106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high- level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0030] The core network 106 may also serve as a gateway for the

WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0031] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular -based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0032] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 106, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub- combination of the foregoing elements while remaining consistent with an embodiment.

[0033] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0034] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0035] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0036] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0037] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light- emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 106 and/or the removable memory 132. The nonremovable memory 106 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown). [0038] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel- cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0039] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location- determination method while remaining consistent with an embodiment.

[0040] The processor 118 may further be coupled to other peripherals

138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0041] FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106. [0042] The RAN 104 may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0043] Each of the eNode-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0044] The core network 106 shown in FIG. 1C may include a mobility management gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0045] The MME 142 may be connected to each of the eNode-Bs 142a,

142b, 142c in the RAN 104 via an Si interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0046] The serving gateway 144 may be connected to each of the eNode

Bs 140a, 140b, 140c in the RAN 104 via the Si interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0047] The serving gateway 144 may also be connected to the PDN gateway 146, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0048] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0049] A streaming media session may include one or more clients, a web server, and/or a streaming media server. The web server and the streaming media server may reside within the same hardware component. A streaming media session, such as a multimedia presentation, may be specified by a uniform resource identifier (URI) and/or a Playlist file, which is an ordered list of additional URIs that may be desired. A URI is a string of characters used to identify a name or a resource on the Internet. Each URI in a Playlist file refers to a media file, which is a segment of a single contiguous stream. To play the stream, a client may first obtain the Playlist file and may then obtain and play each media file in the Playlist. The Playlist file may be reloaded to discover additional segments.

[0050] HTTP is a simple client-server protocol that is connectionless, stateless, and media independent. Improvements to HTTP include bidirectional HTTP, which may have improved functionality as compared to HTTP. One inclusion in bi-directional HTTP is "long polling," which includes using a "Comet" model that describes a web application model in which a long- held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting the information. Using long polling, a server may delay an HTTP polling response until data is available. Once data is available, a complete HTTP response may be sent to the client and the client may initiate another long-poll. Another feature of bi-directional HTTP is HTTP streaming whereby a push technique may used such that the server incrementally writes to a long-lived response. Another feature of bidirectional HTTP is client pulling (also known as an "Ajax model") whereby an HTTP client "pulls" from a server regardless of whether there is data for the client or not.

[0051] Other examples of emerging solutions using HTTP include the use of an HTTP to switch Protocol; a Handshake; and/or a Data exchange. For example, one solution includes using web sockets, which means using an HTTP Upgrade to establish a socket on top of TCP. Another example is Bidirectional Web Transfer Protocol (BWTP), which uses an HTML5 web sockets application programming interface (API) designed as an alternative for Web Socket Protocol. Another example is Reverse HTTP in which the HTTP client and server reverse their role. Another example is Bidirectional- Streams Over Synchronous HTTP (BOSH) whereby as soon as the client receives a response from the connection manager, the client sends another request, thereby ensuring that the connection manager is potentially always holding a request that it may use to "push" data to the client. Another example is Bayeux protocol, which is a protocol to transport asynchronous messages (primarily over HTTP). A final example is Block Extensible Exchange Protocol (BEEP).

[0052] HTTP Live Streaming is an HTTP-based media streaming communications protocol. HTTP Live Streaming may operate by breaking the overall stream into a sequence of small HTTP-based file downloads, with each download loading one short chunk of an overall potentially unbounded transport stream. As the stream is played, the client may select from a number of alternative streams containing the same material encoded at a variety of data rates, allowing the streaming session to adapt to the available data rate. Since the requests may use only standard HTTP transactions, HTTP Live Streaming may be capable of traversing any firewall or proxy server that may allow standard HTTP traffic. The same may not be true of RTSP communications, because a firewall or proxy server may block RTSP communications.

[0053] HTTP Live Streaming may be used for transmitting unbounded streams of multimedia data. It may specify the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. This protocol may support the encryption of media data and the provision of alternate versions (for example, bitrates) of a stream. In HTTP Live Streaming, media data may be transmitted soon after it is created, allowing it to be received in near real-time whereby data is usually carried over HTTP. While pause and resume functionalities are supported by RTSP, they are not currently specifically supported by HTTP Live Streaming. Therefore, a bookmark is introduced that may support pause and resume functionalities for HTTP Live Streaming.

[0054] Bookmark information may be saved, for example, if a live media stream is paused and the bookmark information may be retrieved if the download is resumed. The bookmark information may include, for example, a specific bookmark and/or any other information related to the current download. The bookmark information may be stored on the client side or on the server side if a user pauses a streaming media session. If a client wishes to resume a streaming media session, the bookmark information may be retrieved. As previously explained, the bookmark information to be retrieved may either be stored at the client or at the server. The bookmark examples explained herein may use existing HTTP methods and protocols and may not require a modification of the HTTP protocol.

[0055] In order to have the ability to resume a streaming media session from the point at which the session was paused, the bookmark may contain information related to the point at which the session was paused. For example, the bookmark may include the number of bytes already played by the media player. Thus, the bookmark may enable identification of the point at which the media session should resume. Alternatively or additionally, the bookmark may be extended to other units of measurement. For example, the bookmark may be based on time or may be based on chunks of media. A variety of bookmark types and flows are described herein.

[0056] A client may restart the download in many different ways. The manner in which the download is restarted may depend on the format of the bookmark. In one example, the bookmark may be the first byte to be downloaded next (byte number). This may be the first byte following the bytes that have already been played by the media player. For example, if a chunk comprises 500 bytes and a pause occurs at byte 300, chunks 301 - 800 may be downloaded. This example assumes that the client receives that information from an application, for example, a media player.

[0057] Alternatively or additionally, the bookmark may be the current chunk, indicated by, for example, range. A portion of the streaming data may be re-played/re- sent to the media player if the bookmark is based on the current chunk. For example, if a chunk comprises 500 bytes and a pause occurs at byte 300, a re-download of chunk 1-500 may occur.

[0058] Alternatively or additionally, the bookmark may be the time at which the pause occurred (pause time). The download may resume at the same time that the pause occurred. For example, for a uniform resource identifier (URI) of 10 seconds and a pause time at 3 seconds, the same URI may be re-downloaded starting at 3 seconds. Alternatively or additionally, the bookmark may be the time related to the whole stream, meaning the addition of the duration of all URIs. This bookmark type may assume that the HTTP client receives information from an application, for example, a media player. This example may also assume that the application triggering the HTTP client includes an algorithm that may be used to deduce the byte number. This may be necessary if using the HTTP GET + Range function, which is discussed in more detail below. [0059] Other information may be needed for bookmarking in addition to the bookmark itself. For example, other information that may be used for bookmarking may include: the current URI (pause time and current byte number may be related to the current URI); playlist (which may include a list of URIs to play); the pause time (the actual time at which the pause occurred may be needed to determine if the playlist should be reloaded after resume); and/or the bookmark format (which may be byte number, time-based, etc). The information described herein serves only as an example and many other types of information may also be included.

[0060] To perform bookmarking, including creating and receiving a bookmark, HTTP methods may be used. These methods may include, for example, HTTP "PUT," "GET," and "GET(Range)" (also referred to as "GET + RANGE") methods. The HTTP method "PUT" may be used to upload the bookmark information to the server. A resource may be created and updated on the HTTP server. The RequestURI may be used to identify the entity or the resource. The entity may contain the bookmark information.

[0061] The HTTP method "GET" may be used to retrieve the user- specific bookmark information. The RequestURI may need to be known by the WTRU that is attempting to retrieve a bookmark and/or information. If the device doing the information retrieval is the same as the one that previously saved the information, then the RequestURI may already be known. If the device that is doing the information retrieval is a different device than the one that previously saved the information (for example, if inter- WTRU transfer was used), then the RequestURI may need to be sent to the new device in some manner. For example, the RequestURI may be sent via inter-device communication, may be a locally configured RequestURI, may be part of a user profile retrieved from the server or from elsewhere, may be hardcoded on a particular device, or may be available in some other way.

[0062] The HTTP method "GET + Range" may be used to download specific chunks of data, for example, to resume a download. Chunks may be based on byte number, time, or other information, as explained above with respect to the types of bookmarks. [0063] Alternatively or additionally, modifications to HTTP may be used. The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 is designed to allow implementations of applications that do not depend on knowledge of ranges. Accordingly, the current definition of range-unit is: range-unit = bytes-unit | other-range-unit, wherein bytes-unit = "bytes" and other-range-unit = token. Therefore, it may be desirable to add a new range unit in HTTP. A new range unit may be defined as: range-unit = bytes-unit | elapsed-time | total-elapsed-time | other-range-unit, wherein, bytes-unit = "bytes"; elapsed-time = "milliseconds"; total-elapsed-time = "milliseconds"; and other-range-unit = token. The "range-unit" element may represent a way to interpret values that follow the range-unit. For example, if a value of "2" is stored as bookmark information, range-unit may indicate whether the value of "2" corresponds to "2 bytes," "2 seconds," or any other unit. The "elapsed-time" element may relate to the elapsed time of part of a file. For example, a playlist may include a list of URIs with a particular duration. Thus, the elapsed-time element may relate to the elapsed time of a particular URI, for example, the current URI. Total-elapsed-time may relate to the elapsed time of an entire download. For example, total-elapsed-time may relate to the time elapsed over two or more URIs in a playlist and, in some circumstances, may not relate to the time elapsed for one particular URI.

[0064] As explained above, a server-based solution may be used whereby bookmark information is saved on the server side. At any time later, the bookmark information may be retrieved from the server. A client may use the bookmark information to resume the streaming media session or download that was paused. The bookmarking described herein may be used with inter- WTRU transfer. Another client or device may retrieve the bookmark information from the server or via inter- WTRU transfer and may resume the streaming media session or download.

[0065] The call flow for several examples of server-based bookmarking will now be described with reference to the overview and architecture described above. In the examples, one or more WTRUs may attempt to pause a streaming media session and may attempt to create a bookmark. Additionally, one or more WTRUs may attempt to resume the streaming media session at the point at which the session was paused. A wireless application protocol (WAP)/WEB server and a Streaming Media Server may also facilitate communication of streaming media services.

[0066] Figure 2 is an example of a server-based bookmarking solution, whereby an HTTP live stream is paused by a user and the bookmark is stored at the server. A first WTRU (WTRUl) 202 may currently be streaming media via a WAP/WEB Server 204 from a Streaming Media Server 206. WTRUl 202 may pause the live steam and attempt to store a bookmark at the Streaming Media Server 206.

[0067] As described above, WTRUl 202 may currently have a streaming media session with the Streaming Media Server 206. To establish the streaming media session, WTRUl 202 may get the requested WAP/web page using an HTTP URI 208 via communication with the WAP/WEB Server 204. WTRUl 202 may establish a connection 210 with the Streaming Media Server 206. WTRUl 202 may request media streaming to begin 212. WTRUl 202 may send an HTTP GET [media URI] request 214 to the Streaming Media Server 206. The Streaming Media Server 206 may return a complete playlist 216 to WTRUl 202 because the request was a first invocation. The Streaming Media Server 206 may send an HTTP RESPONSE [Playlist] message 218 to WTRUl 202. WTRUl 202 may send an HTTP GET [mediaURI, Range] request 220 to the Streaming Media Server 206. Media chunks may then be sent 222 from the Streaming Media Server 206 to WTRUl 202. It may be assumed that both WTRUl 202 and the Streaming Media Server 206 support byte-range operations that allow media chunks to be sent.

[0068] WTRUl 202 may decide to pause the media stream 224. This may be accomplished, for example, by pressing a PAUSE button. The media player that is located at WTRUl 202 and is playing the media stream may stop at the current position. WTRUl 202 may stop fetching the next media indicated by the playlist. The media player may know the last byte that was played, so the next byte may be used as the bookmark 230. Alternatively or additionally, the played-time that is specific to the current URI or the total time played may be used as a bookmark. The bookmark information may be passed to the HTTP client. WTRU1 202 may send an HTTP PUT request 240 to the Streaming Media Server 206. The HTTP PUT request 240 may include, for example, WTRUl's bookmark URI, a bookmark, a currentMediaURI, a playlist, and/or any other information that may be needed to store a bookmark at the Streaming Media Server 206. The Streaming Media Server 206 may create and/or update the specified URI containing specified information 242. The Streaming Media Server 206 may send an OK message 244 to WTRU1 202. A bookmark may now be stored at the Streaming Media Server 206.

[0069] Figure 3 is an example of a server-based bookmarking solution, whereby an HTTP live stream is resumed by a user using a bookmark stored at the server. A second WTRU (WTRU2) 308 may attempt to resume a streaming media session that was previously bookmarked. WTRU2 308 may communicate via a WAP/WEB Server 304 to resume a streaming media session that is bookmarked a Streaming Media Server 306.

[0070] As described above, WTRU2 308 may attempt to resume a streaming media session based on a bookmark that is stored at the Streaming Media Server 306. WTRU2 308 may be in communication with the WAP/WEB Server 304 to get a WAP/web page with an HTTP URI 310. WTRU2 308 may establish a connection with the Streaming Media Server 306. Upon establishing a connection, WTRU2 308 may obtain bookmark information 314 that was stored at the Streaming Media Server 306. The bookmark information 314 may be, for example, WTRUlJ ookmarkURI that was previously saved by another WTRU. The bookmark information 314 may be hardcoded into WTRU2 308, may be retrieved via inter-device communication (for example, inter- WTRU transfer), or may be retrieved from the network. WTRU2 308 may send an HTTP GET [WTRUl_bookmarkURI] request 318 to the Streaming Media Server 306. The Streaming Media Server 306 may retrieve the requested bookmark information 320 and may send the information back to WTRU2 308. The Streaming Media Server 306 may send an HTTP RESPONSE message 322 to WTRU2 308. The HTTP RESPONSE message 322 may include, for example, the bookmark, the currentMediaURI, the playlist, and/or any other information that is saved at the Streaming Media Server 306. WTRU2 308 may select the media URI that represents the point at which the streaming media session should be resumed and may use the bookmark information to specify the starting point for resuming the steaming media session 324. The local media player that is located at WTRU2 308 may determine the point at which the media player should start playing 328 based on the "CurrentLocation" and "Playlist information," which may be the bookmark plus currentMediaURI. WTRU2 308 may send an HTTP GET [mediaURI, range] request 332 to the Streaming Media Server 306. Media chunks may then be sent 334 from the Streaming Media Server 306 to WTRU2 308. The Streaming Media Server 306 may delete the bookmark or may store the bookmark 336. For example, if the bookmark is permanent, the Streaming Media Server 306 may store it for use by a user or anyone that the user shares the bookmark with. The user may also delete the bookmark from the Streaming Media Server 306.

[0071] As explained above, a client-based solution may also be used whereby bookmark information is saved on the client side. Thus, at any time later, the same device that paused and bookmarked a streaming media session may resume the session. Alternatively or additionally, inter-device communication (for example, inter- WTRU transfer) may be supported. The bookmark information may be transferred to another client or device, for example, using inter- WTRU transfer. The other client or device may resume the streaming media session or download.

[0072] The call flow for several examples of client-based bookmarking will now be described with reference to the overview and architecture described above. In the examples, one or more WTRUs may attempt to pause a streaming media session and may attempt to create a bookmark. The bookmark may be stored at the WTRU and/or may be sent to another WTRU. Additionally, one or more WTRUs may attempt to resume the streaming media session at the point at which the session was paused. A WAP/WEB server and a Streaming Media Server may also facilitate communication of streaming media services. [0073] Figure 4 is an example of a client-based bookmarking solution, whereby an HTTP live stream is paused by a user and the bookmark is stored at the client. A first WTRU (WTRUl) 402 may currently be streaming media via a WAP/WEB Server 404 from a Streaming Media Server 406. WTRUl 402 may pause the live steam and attempt to store a bookmark at WTRUl 402.

[0074] As described above, WTRUl 402 may currently have a streaming media session with the Streaming Media Server 406. To establish the streaming media session, WTRUl 402 may get the requested WAP/web page using an HTTP URI 410 via communication with the WAP/WEB Server 404. WTRUl 402 may establish a connection 412 with the Streaming Media Server 406. WTRUl 402 may request media streaming to begin 414. WTRUl 402 may send an HTTP GET [media URI] request 416 to the Streaming Media Server 406. The Streaming Media Server 406 may return a complete playlist 418 to WTRUl 402 because the request was a first invocation. The Streaming Media Server 406 may send an HTTP RESPONSE [Playlist] message 420 to WTRUl 402. WTRUl 402 may send an HTTP GET [mediaURI, Range] request 422 to the Streaming Media Server 406. Media chunks may then be sent 424 from the Streaming Media Server 406 to WTRUl 402. It may be assumed that both WTRUl 402 and the Streaming Media Server 406 support byte-range operations that allow media chunks to be sent.

[0075] WTRUl 402 may decide to pause the media stream 426. This may be accomplished, for example, by pressing a PAUSE button. The media player that is located at WTRUl 402 and is playing the media stream may stop at the current position. WTRUl 402 may stop fetching the next media indicated by the playlist. The media player may know the last byte that was played, so the next byte may be used as the bookmark 432. Alternatively or additionally, the played-time that is specific to the current URI or the total time played may be used as a bookmark. WTRUl 402 may locally store the bookmark, currentMediaURI, and/or any other information 434, so that the information is available for later retrieval.

[0076] Figure 5 is an example of a client-based bookmarking solution whereby an HTTP live stream is resumed by a user using a bookmark stored by the user. A first WTRU (WTRUl) 502 may attempt to resume a streaming media session that was previously bookmarked. WTRUl 502 may communicate via a WAP/WEB Server 504 to resume the streaming media session that is bookmarked at WTRUl 502.

[0077] As described above, WTRUl 502 may attempt to resume a streaming media session based on a bookmark that is stored at WTRUl 502. WTRUl may be in communication with the WAP/WEB Server 504 to get a WAP/web page with an HTTP URI 510. WTRUl may establish a connection 512 with the Streaming Media Server 506. Upon establishing a connection, WTRUl 502 may locally retrieve the bookmark, mediaURImformation, and/or any other stored information 514. Alternatively or additionally, WTRUl 502 may retrieve the bookmark, mediaURImformation, and/or any other stored information from another device using, for example, inter-device communication. WTRUl 502 may select the media URI that corresponds to the location at which to resume the download and may use the bookmark to specify a range 516. Byte-number may be used as the bookmark in this example. WTRUl 502 may send an HTTP GET [mediaURI, range] request 520 to the Streaming Media Server 506. Media chunks may then be sent 522 from the Streaming Media Server 506 to WTRUl 502. A local media player located at WTRUl 502 may then determine the point at which the media player should start playing 524 based on the "CurrentLocation" and "Playlist information," which may be the bookmark plus currentMediaURI. The user may, optionally, delete the bookmark from WTRUl 502.

[0078] The bookmark solutions described herein may be used in a variety of ways. As previously explained, bookmarking may be used any time a user decides to pause a streaming media session. For example, an HTTP streaming media session may be paused and resumed according to the bookmark solutions provided herein. Additionally, the bookmark solutions may be used any time that a session transfer is performed. By way of example, a user watching a streamed video on a portable device (first device) may desire to transfer the streamed video to another device (second device), such as a television. The bookmark solutions described herein may be used to start the video on the second device at the position at which the streamed video was paused. A user may initiate the session transfer from the first device. Alternatively or additionally, the user may initiate the session transfer from the second device. In either example, a bookmark may be used to allow the session to be resumed at the point at which the session was paused.

[0079] The call flow for several examples of session transfer will now be described with reference to the overview and architecture described above. In the following examples, a device playing streamed media may discover the availability of another device or another device may discover the availability of the device playing streamed media. The devices may be under control of the same user and/or may be under the same subscription. An active device- initiated (also referred to as "source device-initiated") session transfer occurs if a device that is currently streaming (or was previously streaming) a media session initiates the session transfer to another device. A target-initiated session transfer occurs if a device that desires to receive a currently streaming media session or to resume a previously paused and/or bookmarked media session initiates the session transfer to itself.

[0080] As previously explained, the current streaming media session may be paused and a bookmark may be created. The pausing and bookmarking may be initiated by a user of the active device or may be requested by a user of the target device. The bookmark may be stored at the server or at the client, as explained in detail above with respect to the server- based and client-based bookmarking solutions. The server may send the bookmark to a target device and may request that streaming is initiated. Two or more devices or clients may exchange bookmark information directly over a direct communication link such as, for example, peer-to-peer (P2P) communication, the internet, and/or a WLAN DIRECT connection. A streaming media session may then be initiated by the device receiving the bookmark information.

[0081] Figure 6 is an example of active device-initiated session transfer of a streaming media session using explicit bookmarking. A first WTRU (WTRUl) 602 may be streaming a media session via a WAP/WEB Server 604 from a Streaming Media Server 606. WTRUl 602 may attempt to transfer the session to a second WTRU (WTRU2) 608 and WTRUl 602 may pause and bookmark the current session before the transfer.

[0082] As described above, WTRUl 602 may currently have a streaming media session with the Streaming Media Server 606. To establish the streaming media session, WTRUl 602 may get a requested WAP/web page using an HTTP URI 610 via communication with the WAP/WEB Server 604. WTRUl 602 may establish a connection 612 with the Streaming Media Server 606. WTRUl 602 may send a Get Media request 614 to the Streaming Media Server 606. Media chunks may then be sent 616 from the Streaming Media Server 606 to WTRUl 602.

[0083] WTRUl 602 may detect WTRU2 608 and WTRUl 602 may decide to transfer the streaming media session 618 to WTRU2 608. WTRUl 602 may create bookmark information. WTRUl 602 may send a Pause Media request to the Streaming Media Server 606 to pause the media session 622. The Pause Media request may include bookmark information. The Streaming Media Server 606 may store the bookmark information 624. The bookmarking may be performed in any manner, including any of the ways described above. WTRUl 602 may send a Transfer_Session request 626 to the Streaming Media Server 606. The Transfer_Session request may include, for example, an identification of the recipient of the session transfer (WTRU2 608 in this example), such as URI, IP Address, or the like, as well as media information. Alternatively or additionally, requests such as Duplicate and Modify may also be used. Optionally, the TCP connection may be closed 628. Otherwise, the Streaming Media Server 606 and WTRUl 602 may choose to keep the TCP connection open for future use. It may be assumed that WTRUs engaged in inter- WTRU transfer are running a server, for example, Reverse HTTP. For example, Reverse HTTP may allow a WTRU (which may typically be the HTTP client) to behave as an HTTP Server and/or may allow the HTTP Server to behave as a client (for example, by sending requests). This may allow the Streaming Media Server 606 to initiate a streaming media session with a target WTRU.

[0084] The Streaming Media Server 606 may send a request to start streaming 630 to WTRU2 608. Thus, the Streaming Media Server 606 may decide to and trigger WTRU2 608 to initiate streaming 632. A Start_streaming request 634 may include the MediaURI and the bookmark, whereby the bookmark may include URI, time, and/or any other information. WTRU2 608 may establish a connection 636 with the Media Server 606. WTRU2 608 may send a Get Media request 638 to the Streaming Media Server 606. The Get Media request 638 may include the MediaURI related to the point at which a previous streaming media session was paused and/or bookmarked. The Streaming Media Server 606 may start streaming from the previously "paused" location 640. A media session may then be streamed 642 between WTRU2 608 and the Streaming Media Server 606.

[0085] Figure 7 is an example of active device-initiated session transfer of a streaming media session whereby a bookmark may be created as part of an inter-WTRU transfer command. A first WTRU (WTRUl) 702 may be streaming a media session via a WAP/WEB Server 704 from a Streaming Media Server 706. WTRUl 702 may attempt to transfer the session to a second WTRU (WTRU2) 708 and WTRUl 702 may pause the current session and create a bookmark via an inter-WTRU transfer command.

[0086] As described above, WTRUl 702 may currently have a streaming media session with the Streaming Media Server 706. To establish the streaming media session, WTRUl 702 may get a requested WAP/web page using an HTTP URI 710 via communication with the WAP/WEB Server 704. WTRUl 702 may establish a connection 712 with the Streaming Media Server 706. WTRUl 702 may send a Get Media request 714 to the Streaming Media Server 706. Media chunks may then be sent 716 from the Streaming Media Server 706 to WTRUl 702.

[0087] WTRUl 702 may detect WTRU2 708 and WTRUl 702 may decide to transfer the streaming media session 718 to WTRU2 708. WTRUl 702 may create bookmark information. WTRUl 702 may send a Transfer_Session request 722 to the Streaming Media Server 706. The Transfer_Session request may include, for example, the MediaURI, bookmark information, and/or an identification of the recipient of the session transfer (WTRU2 708 in this example), such as URI, IP Address, or the like. Thus, an explicit Pause command may not be required and bookmark information may be sent along with the Transfer_Session request. Alternatively or additionally, requests such as Duplicate and Modify may also be used. Alternatively or additionally, the bookmarking may be performed in any manner, including any of the ways described above. The Streaming Media Server 706 may store the bookmark information 724. Optionally, the TCP connection may be closed 726. Otherwise, the Streaming Media Server 706 and WTRUl 702 may choose to keep the TCP connection open for future use. It may be assumed that WTRUs engaged in inter- WTRU transfer are running a server, for example, Reverse HTTP.

[0088] The Streaming Media Server 706 may send a request to start streaming 728 to WTRU2 708. Thus, the Streaming Media Server 706 may decide to and trigger WTRU2 708 to initiate streaming 730. A Start_streaming request 732 may include bookmark information, which may include URI, time, and/or any other information. WTRU2 708 may establish a connection 734 with the Media Server 706. WTRU2 708 may send a Get Media request 736 to the Streaming Media Server 706. The Get Media request 736 may include the MediaURI related to the point at which a previous streaming media session was paused and/or bookmarked. The Streaming Media Server 706 may start streaming from the previously "paused" location 738. A media session may then be streamed 740 between WTRU2 708 and the Streaming Media Server 706.

[0089] Figure 8 is an example of active device-initiated session transfer of a streaming media session whereby a bookmark may be created and two or more WTRUs may communicate directly via peer-to-peer communication. A first WTRU (WTRUl) 802 may be streaming a media session via a WAP/WEB Server 804 from a Streaming Media Server 806. WTRUl 802 may attempt to transfer the session to a second WTRU (WTRU2) 808 and WTRUl 802 may pause the current session, create a bookmark, and/or communicate directly with WTRU2 808.

[0090] As described above, WTRUl 802 may currently have a streaming media session with the Streaming Media Server 806. To establish the streaming media session, WTRUl 802 may get a requested WAP/web page using an HTTP URI 810 via communication with the WAP/WEB Server 804. WTRUl 802 may establish a connection 812 with the Streaming Media Server 806. WTRUl 802 may send a Get Media request 814 to the Streaming Media Server 806. Media chunks may then be sent 816 from the Streaming Media Server 806 to WTRUl 802.

[0091] WTRUl 802 may detect WTRU2 808 and WTRUl 802 may decide to transfer the streaming media session 818 to WTRU2 808. WTRUl 802 may create bookmark information. Optionally, the TCP connection may be closed 822. Otherwise, the Streaming Media Server 806 and WTRUl 802 may choose to keep the TCP connection open for future use. Optionally, WTRUl 802 may send a Pause Media request to the Streaming Media Server 806 to pause the media session 824. The Pause Media request may include the MediaURI and/or bookmark information. Optionally, the Streaming Media Server 806 may store the bookmark information 826. WTRUl 802 may send a Transfer_Session request 828 to WTRU2 808. The Transfer_Session request may be sent, for example, via a P2P connection, the internet, a WLAN Direct connection, or the like. Thus, WTRUl 802 may send the command directly 830 to WTRU2 808. The Transfer_Session request may include, for example, the MediaURI and/or bookmark information. Alternatively or additionally, requests such as Duplicate and Modify may also be used. The bookmarking may be performed in any manner, including any of the ways described above. WTRU2 808 may establish a connection 832 with the Streaming Media Server 806. WTRU2 808, the target device, may decide to initiate streaming 834. WTRU2 808 may send a Get Media Request 836 to the Streaming Media Server 806. The Get Media Request may include, for example, the MediaURI and/or the bookmark information related to the point at which a previous streaming media session was paused. The Streaming Media Server 806 may begin streaming from the previously "paused" location 838. A media session may then be streamed 840 between WTRU2 808 and the Streaming Media Server 806.

[0092] Figure 9 is an example of target device-initiated session transfer of a streaming media session using explicit bookmarking by the original device. A first WTRU (WTRUl) 902 may be streaming a media session via a WAP/WEB Server 904 from a Streaming Media Server 906. A second WTRU (WTRU2) 908 may attempt to transfer the session from WTRUl 902 to WTRU2 908.

[0093] As described above, WTRUl 902 may currently have a streaming media session with the Streaming Media Server 906. To establish the streaming media session, WTRUl 902 may get a requested WAP/web page using an HTTP URI 910 via communication with the WAP/WEB Server 904. WTRUl 902 may establish a connection 912 with the Streaming Media Server 906. WTRUl 902 may send a Get Media request 914 to the Streaming Media Server 906. Media chunks may then be sent 916 from the Streaming Media Server 906 to WTRUl 902.

[0094] WTRU2 908 may detect WTRUl 902 and WTRU2 908 may decide to transfer the streaming media session 918 to WTRU2 908. WTRU 908 may get a requested web page HTTP URI 922 via communication with the WAP/WEB Server 904. WTRU2 908 may then identify the media stream that is to be transferred 924. WTRU2 908 may establish a connection 926 with the Streaming Media Server 906. WTRU2 908, the target device, may then initiate the session transfer 928. WTRU2 908 may send a SessionTransfer_Request 930 to the Streaming Media Server 906. The SessionTransfer_Request may include, for example, the fromURI and/or the mediaURI. WTRUl 902 and WTRU2 908 may belong to the same user and may be under the same subscription 932. Thus, each WTRU may inform the other WTRU regarding authentication or authorization procedures.

[0095] The Streaming Media Server 906 may send a

PauseMedia(mediaURI) request 936 to WTRUl 902. WTRUl 902 may send an acknowledgement (ACK) 940 to the Streaming Media Server 906. The ACK may include bookmark information. The bookmarking may be performed in any manner, including any of the ways described above. The Streaming Media Server 906 may send a SessionTransfer_ACK message 942 to WTRU2 908. The SessionTransfer_ACK message may include the bookmark information. Upon receiving the ACK from the Streaming Media Server 906, WTRU2 908 may initiate streaming 944. WTRU2 908 may send a Get Media request 946 to the Streaming Media Server 906. The Get Media request may include, for example, the mediaURI or the bookmark information. The Streaming Media Server 906 may start streaming from the previously "paused" location 948. A media session may then be streamed 950 between WTRU2 908 and the Streaming Media Server 906. The TCP connection between WTRUl 902 and the Streaming Media Server 906 may be closed 952.

[0096] Figure 10 is an example of target device-initiated session transfer of a streaming media session whereby two or more WTRUs may communicate directly via peer-to-peer communication and bookmarking may be performed by the original device. A first WTRU (WTRUl) 1002 may be streaming a media session via a WAP/WEB Server 1004 from a Streaming Media Server 1006. A second WTRU (WTRU2) 1008 may attempt to transfer the session from WTRUl 1002 to WTRU2 1008.

[0097] As described above, WTRUl 1002 may currently have a streaming media session with the Streaming Media Server 1006. To establish the streaming media session, WTRUl 1002 may get a requested WAP/web page using an HTTP URI 1010 via communication with the WAP/WEB Server 1004. WTRUl 1002 may establish a connection 1012 with the Streaming Media Server 1006. WTRUl 1002 may send a Get Media request 1014 to the Streaming Media Server 1006. Media chunks may then be sent 1016 from the Streaming Media Server 1006 to WTRUl 1002.

[0098] WTRU2 1008 may detect WTRUl 1002 and WTRU2 1008 may decide to transfer the streaming media session 1018 to WTRU2 1008. WTRU 1008 may get a requested web page HTTP URI 1022 via communication with the WAP/WEB Server 1004. WTRU2 1008 may then identify the media stream that is to be transferred 1024. WTRUl 1002 and WTRU2 1008 may belong to the same user and may be under the same subscription 1030. WTRU2 1008, the target device, may then initiate the session transfer. WTRU2 1008 may send a SessionTransfer_Request 1032 to WTRUl 1002. The SessionTransfer_Request may include, for example, the fromURI and/or the mediaURI. Alternatively or additionally, requests such as Duplicate and Modify may also be used. The TransferSession_Request may be sent, for example, via P2P, the internet, WLAN Direct, etc. Thus, WTRU2 1008 may send the command directly 1034 to WTRUl 1002.

[0099] WTRUl 1002 may pause the streaming media and may create a bookmark 1036. The bookmarking may be performed in any manner, including any of the ways described above. WTRUl 1002 may send a SessionTransfer_ACK 1038 to WTRU2 1008. The SessionTransfer_ACK may include the bookmark information. WTRU2 1008 may establish a connection 1040 with the Streaming Media Server 1006. WTRU2 1008 may send a Get Media request 1042 to the Streaming Media Server 1006. The Get Media request may include, for example, the mediaURI or the bookmark information. The Streaming Media Server 1006 may start streaming from the previously "paused" location 1044. A media session may then be streamed 1046 between WTRU2 1008 and the Streaming Media Server 1006. Optionally, the TCP connection between WTRUl 1002 and the Streaming Media Server 1006 may be closed 1048.

[0100] Embodiments:

1. A method for hyper text transfer protocol (HTTP) bookmarking by a wireless transmit/receive unit (WTRU), the method comprising:

requesting media;

obtaining a playlist file;

querying for current position;

posting the current position; and

receiving an acknowledgment (ACK).

2. The method of embodiment 1, wherein the communication is initiated by a WTRU. 3. The method as in any of the preceding embodiments, further comprising creating a uniform resource identifier (URI) for each media file that appears in a playlist.

4. The method as in any of the preceding embodiments, further comprising pausing a playlist.

5. The method as in any of the preceding embodiments, further comprising creating a bookmark on condition that a playlist is paused.

6. The method as in any of the preceding embodiments, further comprising sending bookmark information to a server.

7. The method as in any of the preceding embodiments, further comprising storing bookmark information in a database.

8. The method as in any of the preceding embodiments, further comprising calculating a location to resume playing media after the media is paused by using duration and elapsed time to start.

9. The method as in any of the preceding embodiments, further comprising using an HTTP POST method to upload bookmark information.

10. The method as in any of the preceding embodiments, further comprising using a HTTP method GET to retrieve bookmark information.

11. The method as in any of the preceding embodiments, further comprising using a HTTP GET + Range method to download specific data and to resume a download.

12. The method as in any of the preceding embodiments, wherein the bookmark information is saved when media is paused.

13. The method as in any of the preceding embodiments, wherein the bookmark information is retrieved when the download is resumed.

14. The method as in any of the preceding embodiments, wherein the bookmark information is kept on the client side when the user presses a pause button.

15. The method as in any of the preceding embodiments, wherein the bookmark information is kept on server side when the user presses the pause button. 16. The method as in any of the preceding embodiments, wherein the bookmark information is retrieved when the download is resumed.

17. The method as in any of the preceding embodiments, wherein the download continues from where it was before the user pressed the pause button.

18. The method as in any of the preceding embodiments, wherein the download format depends on the bookmark format.

19. The method as in any of the preceding embodiments, wherein the bookmark format is the first byte to be downloaded.

20. The method as in any of the preceding embodiments, wherein the byte is the first byte following the byte already been played by a media player.

21. The method as in any of the preceding embodiments, wherein the bookmark format is the current chunk or range.

22. The method as in any of the preceding embodiments, wherein the bookmark format is the bookmark is the pause time.

23. The method as in any of the preceding embodiments, wherein the HTTP client receives the bookmark format information from a media player.

24. The method as in any of the preceding embodiments, wherein the client uses the bookmark information saved on the client side to resume the download.

25. The method as in any of the preceding embodiments, wherein the information saved on the client side is used to perform an inter- WTRU transfer.

26. The method as in any of the preceding embodiments, wherein a PUT method is used to upload the bookmark information on the server.

27. The method as in any of the preceding embodiments, wherein a GET method is used to retrieve user specific bookmark information.

28. The method as in any of the preceding embodiments, wherein a GET + Range method is used to download specific chunks of data and to resume the download. 29. The method as in any of the preceding embodiments, wherein the client uses the bookmark information saved on the server side to resume the download.

30. The method as in any of the preceding embodiments, wherein the bookmark information is saved on the client side.

31. The method as in any of the preceding embodiments, wherein the bookmark is saved on the client side is retrieved to resume the download.

32. The method as in any of the preceding embodiments, wherein the same device is continuing the download.

33. The method as in any of the preceding embodiments, wherein the GET + Range method is used to download a specific range of data for client- based and server-based bookmarking.

34. The method as in any of the preceding embodiments, wherein the range of the bookmark is calculated according to:

range unit = bytes-unit | elapsed-time | total-elapsed-time | other-range-unit, wherein bytes-unit = "bytes", elapsed-time = "milliseconds", total-elapsed-time = "milliseconds" and other-range-unit = token.

35. The method as in any of the preceding embodiments, the method comprising:

determining that a media session will be transferred;

identifying a media stream for transfer;

creating a bookmark related to the media stream; and

initiating a session transfer.

36. The method as in any of the preceding embodiments, wherein the communication is initiated by a WTRU.

37. The method as in any of the preceding embodiments, further comprising obtaining a playlist file containing a plurality of media files.

38. The method as in any of the preceding embodiments, further comprising discovering a media ability of a target client device.

39. The method as in any of the preceding embodiments, further comprising pausing a media stream and creating a bookmark. 40. The method as in any of the preceding embodiments, further comprising using a uniform resource identifier (URI) to identify a media file.

41. The method as in any of the preceding embodiments, further comprising creating a bookmark by a first device.

42. The method as in any of the preceding embodiments, further comprising creating a bookmark by a target device.

43. The method as in any of the preceding embodiments, further comprising storing a bookmark at either a client or a server.

44. The method as in any of the preceding embodiments, further comprising dividing a media stream into media files where the duration of each media file is the same.

45. The method as in any of the preceding embodiments, further comprising a server passing a bookmark to a target device.

46. The method as in any of the preceding embodiments, further comprising creating a uniform resource identifier (URI) for each media file that appears in a playlist.

47. The method as in any of the preceding embodiments, further comprising making an entire media file available on the condition that the uniform resource identifier (URI) is included in a playlist file.

48. The method as in any of the preceding embodiments, further comprising a server sending a request to start streaming to a target device.

49. The method as in any of the preceding embodiments, further comprising exchanging bookmarks directly between a first device and a target device.

50. The method as in any of the preceding embodiments, further comprising a first device initiating transfer of streaming and bookmark.

51. The method as in any of the preceding embodiments, further comprising a target device initiating transfer of streaming and bookmark.

52. The method as in any of the preceding embodiments, further comprising sending a bookmark from a first device to a streaming media server. 53. The method as in any of the preceding embodiments, further comprising a streaming media server sending a streaming request to a target device.

54. The method as in any of the preceding embodiments, further comprising creating a bookmark on condition that a playlist is paused.

55. The method as in any of the preceding embodiments, further comprising sending bookmark information to a server.

56. The method as in any of the preceding embodiments, further comprising storing bookmark information in a database.

57. The method as in any of the preceding embodiments, further comprising starting of streaming from a paused location.

58. The method as in any of the preceding embodiments, further comprising calculating a location to resume playing media after the media is paused by using duration and elapsed time to start.

59. The method as in any of the preceding embodiments, further comprising deleting bookmark information.

60. The method as in any of the preceding embodiments, further comprising using a POST method to upload bookmark information.

61. The method as in any of the preceding embodiments, further comprising using a method GET to retrieve bookmark information.

62. The method as in any of the preceding embodiments, further comprising sending a Transfer_Session request to a streaming media server

63. The method as in any of the preceding embodiments, further comprising sending a close transmission control protocol (TCP).

64. The method as in any of the preceding embodiments, further comprising querying a media player for a current location and media uniform resource locator (URL).

65. The method as in any of the preceding embodiments, further comprising sending a transfer session request using peer to peer (P2P) communication.

66. The method as in any of the preceding embodiments, further comprising receiving an acknowledgment from a streaming media server. 67. The method as in any of the preceding embodiments, further comprising sending a transfer session request using the Internet.

68. A method as in any of the preceding embodiments, the method comprising:

transmitting a first hypertext transfer protocol (HTTP) GET request to initiate a streaming media session;

receiving user input pausing the streaming media session;

creating bookmark information related to the paused streaming media session; and

transmitting a second HTTP GET request to resume the streaming media session, wherein the second HTTP GET request includes the bookmark information.

69. The method as in any of the preceding embodiments, further comprising:

transmitting an HTTP PUT request to a server to store the bookmark information, the HTTP PUT request including the bookmark information; transmitting a third HTTP GET request to the server to retrieve the bookmark information; and

receiving an HTTP RESPONSE from the server, the HTTP RESPONSE including the bookmark information.

70. The method as in any of the preceding embodiments, further comprising:

storing the bookmark information.

71. The method as in any of the preceding embodiments, further comprising:

transmitting a Pause Media request to a server, the Pause Media request including the bookmark information.

72. The method as in any of the preceding embodiments, further comprising:

initiating a session transfer of a streaming media session from the WTRU to another WTRU, wherein the initiating occurs after the bookmark information is created. 73. The method as in any of the preceding embodiments, wherein the initiating the session transfer is performed by the WTRU.

74. The method as in any of the preceding embodiments, wherein the initiating the session transfer is performed by the other WTRU.

75. The method as in any of the preceding embodiments, further comprising:

transmitting an inter- WTRU transfer command to a server, the inter- WTRU transfer command including the bookmark information.

76. The method as in any of the preceding embodiments, wherein the bookmark information includes a number of bytes of the streaming media session that were played prior to pausing the streaming media session.

77. The method as in any of the preceding embodiments, wherein the bookmark information includes an amount of time of the streaming media session that elapsed prior to pausing the streaming media session.

78. The method as in any of the preceding embodiments, wherein the bookmark information includes information related to the most recent media chunk that was played prior to pausing the streaming media session.

79. A wireless transmit and receive unit (WTRU) configured to perform the method of any one of embodiments 1-78.

80. An integrated circuit (IC) configured to perform the method of any one of embodiments 1-78.

81. An evolved NodeB (eNB) configured to perform the method of any one of embodiments 1-78.

82. A network configured in accordance with any one of embodiments

1-78.

83. A network element configured to perform the method of any one of embodiments 1-78.

84. A streaming media server configured to perform the method of any one of embodiments 1-78.

[0101] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto -optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

" " "

Claims

CLAIMS What is claimed is:

1. A method for use in a wireless transmit/receive unit (WTRU) of bookmarking a streaming media session, the method comprising:

receiving user input pausing the streaming media session;

2. The method of claim 1, further comprising:

3. The method of claim 1, further comprising:

storing the bookmark information after the bookmark information is created.

4. The method of claim 1, further comprising:

transmitting a Pause Media request to a server in response to the receiving user input, the Pause Media request including the bookmark information.

5. The method of claim 1, further comprising:

initiating a session transfer of a streaming media session from the WTRU to another WTRU, wherein the initiating occurs after the bookmark information is created.

6. The method of claim 5, wherein the initiating the session transfer comprises transmitting an initiation message to the another WTRU.

7. The method of claim 5, wherein the initiating the session transfer comprises receiving an initiation message from the another WTRU.

8. The method of claim 1, further comprising:

9. The method of claim 1, wherein the bookmark information includes a number of bytes of the streaming media session played prior to pausing the streaming media session.

10. The method of claim 1, wherein the bookmark information includes an amount of time of the streaming media session that elapsed prior to pausing the streaming media session.

11. A wireless transmit/receive unit (WTRU) configured to bookmark a streaming media session, comprising:

a transmitter configured to transmit a first hypertext transfer protocol (HTTP) GET request to initiate a streaming media session;

a processor configured to:

receive user input pausing the streaming media session; and create bookmark information related to the paused streaming media session; and

the transmitter further configured to transmit a second HTTP GET request to resume the streaming media session, wherein the second HTTP GET request includes the bookmark information.

12. The WTRU of claim 11, further comprising:

the transmitter further configured to:

transmit an HTTP PUT request to a server to store the bookmark information, the HTTP PUT request including the bookmark information; and

transmit a third HTTP GET request to the server to retrieve the bookmark information; and

a receiver configured to receive an HTTP RESPONSE from the server, the HTTP RESPONSE including the bookmark information.

13. The WTRU of claim 11, further comprising:

a storage device configured to store the bookmark information after the bookmark information is created.

14. The WTRU of claim 11, wherein the transmitter is further configured to transmit a Pause Media request to a server in response to receiving user input pausing the streaming media session, the Pause Media request including the bookmark information.

15. The WTRU of claim 11, wherein the processor is further configured to initiate a session transfer of a streaming media session from the WTRU to another WTRU, wherein the initiating occurs after the bookmark information is created.

16. The WTRU of claim 15, wherein the transmitter is further configured to transmit an initiation message to the another WTRU.

17. The WTRU of claim 15, further including:

a receiver configured to receive an initiation message from the another WTRU, wherein the initiation message requests initiation of the session transfer.

18. The WTRU of claim 11, wherein the transmitter is further configured to transmit an inter- WTRU transfer command to a server, the inter- WTRU transfer command including the bookmark information.

19. The WTRU of claim 11, wherein the bookmark information includes a number of bytes of the streaming media session played prior to pausing the streaming media session.

20. The WTRU of claim 11, wherein the bookmark information includes an amount of time of the streaming media session that elapsed prior to pausing the streaming media session.