Patent Application
20060123131
The present invention relates generally to seamless mobility, and in particular, to a method, apparatus, and system for performing seamless mobility.
The vision of seamless mobility includes the ability to migrate multi-media sessions between differing devices. For example, imagine you are listening to your favorite music from the comfort of your home, but you have to go out. You transfer the music to your phone while you walk to your automobile, and then transfer the music from the phone to your auto as you drive away. While moving from the home to the car, the music continues playing uninterrupted, as if emanating from a single device.
A major obstacle encountered in seamless mobility is to have the digital content pick up at a new device in the same state that it left off the old device. In case of a music session, the current state may include the current elapsed time etc. Therefore, a need exists for a method, apparatus, and system for performing seamless mobility that allows a user's session to seamlessly migrate to a new device starting on the new device exactly where it left off at the old device
To address the above-mentioned need an independent server is established to track the state of content being rendered on a client device. In one embodiment, the client device automatically (or alternatively upon a user's action) updates the server with the state of the content being rendered. Alternatively, the content server (alternatively referred to as an application server) itself maintains a backchannel with that independent server and updates session state, witch has the advantage of not requiring any changes in the client. When migrating content from a first client device to a second client device, the second client device will access the server prior to rendering the content. Upon accessing the server, the second client device will be provided with the state of the current session (e.g., amount of media rendered, volume, play lists, . . . , etc.). By providing the second client device with the current session state of the session, a user will be able to seamlessly migrate to the second client device and have the content continue where it left off at the old device.
The present invention encompasses a method comprising the steps of receiving a request to stream digital content to a client device, receiving a current session state of the digital content, and streaming the digital content to the client device based on the current session state. The current session state is updated by updating an external server with the current session state.
The present invention additionally encompasses a method comprising the steps of receiving session state updates from an application server, receiving a request for digital content from a client device, and providing the client device with an address for the application server holding the digital content. The client device is provided with a session state for the digital content.
The present invention additionally encompasses a method for operating a content server. The method comprises the steps of providing digital content to an external client, determining a current session state for the digital content, and providing the current session state of the digital content to an external server.
The present invention additionally encompasses an apparatus comprising a receiver receiving a request to stream digital content to a client device and receiving a current session state of the digital content. The apparatus additionally comprises a transmitter streaming the digital content to the client device based on the current session state and transmitting the current session state to an external server.
The present invention additionally comprises an apparatus comprising a receiver receiving session state updates from an application server and receiving a request for digital content from a client device. The apparatus additionally comprises a transmitter providing the client device with an address for the application server holding the digital content, and providing the client device with a session state for the digital content.
Turning now to the drawings, wherein like numerals designate like components,
Content servers 101-102 provide digital content to devices 106-108 via network 104, however, in alternate embodiments the digital content may be provided via a direct link to devices 106-108, either wired or over-the-air. Network 104 may take various forms such as but not limited to a cellular network, a local-area network, a wide-area network, . . . , etc. For example, client device 108 may comprise a standard cellular telephone, with network 104 comprising a cellular network such as a Code-Division, Multiple-Access communication system, with access point 105 comprising a standard cellular base station. Additionally, client device 108 may comprise an MP3 player capable of communication over a local-area network, with network 104 using an IEEE 802.11, 802.16, or 802.21 system protocol, and access point 105 being a wireless gateway. Regardless of the form that devices 106-108, servers 101-102, and network 104 take, digital content is stored on servers 101 and 102 and provided to client devices 106-108 when requested.
As discussed, a major obstacle to seamless mobility is to have the digital content migrate to a new device in a similar state as it left the old device, instead of having the session simply restart when migrating to the new device. In order to address this issue, state database server 103 is provided to monitor the state of the current session (e.g., amount of media rendered, volume, list of media to be rendered, etc.). Any device 106-108 wishing to render the current session will be able to determine the current session state by accessing state database server 103, allowing a user's session to seamlessly pick up at a new device where it left off at the old device. To migrate a session (i.e., the current rendering of a digital file) from a source client device to a destination client device, the source client device simply needs to terminate the current session after providing the session parameters to state database server 103. Alternatively, state database server 103 could instruct the content server 101 to force migration of the current session after capturing the necessary session state from the content server. In the first embodiment, the end client may need to send state information that could potentially infringe upon the user's privacy. A server based solution is more secure in this respect. Subsequently, a new session is launched on the destination client device using session parameters obtained from state database server 103 matching the earlier session state (e.g., amount of media rendered, volume, play lists, . . . , etc.).
Application 209 is preferably computer code that is designed to render digital content 217. For example, application 209 may comprise computer software designed to “play” an MPEG Audio Layer 3 (MP3) file or software designed to “play” a video file such as an MPEG Video Layer 4 file utilizing a standard MPEG video codec. Regardless of the form application 209 takes, application 209 is designed to periodically provide logic circuitry 215 with the current session state of the content being rendered. This can be accomplished by application 209 storing this information in state database 211, or simply passing the information directly to logic circuitry 215. Logic circuitry 215 periodically provides state information to state database server 103 for storage in state database 203.
During streaming, content (application) servers 101, 102 provide updated session information to state database server 103. This is accomplished by logic circuitry 219 periodically providing state database server 103 with updated state information for particular sessions being streamed by the content server.
Finally, state database server 103 preferably comprises content catalog 201 comprising a list of available digital content. Any user can access (e.g., via network 104) catalog 201 and request digital content from catalog 201. In return, logic circuitry 205 returns a message that contains an address (e.g., a URL) where the content is located. More particularly, the address comprises the address of a content server hosting the requested file. Along with the content server hosting the requested file, logic circuitry 205 accesses state database 203 and provides the requester with the current session state of the content being requested.
In order to provide accurate session state information on digital content being requested, logic circuitry 205 must associate the request with a current session. This is accomplished by use of a session identification (discussed in detail below).
During operation application 209 renders digital content 217. As discussed, the session state of the digital content is provided periodically to state database 203. This is either accomplished via application 209 periodically updating state database 203, or alternatively, a content server updating state database 203. When migration is desired, a user signals the intent to migrate a session. For example, a user may “pause” a session before “tearing” it down. (Alternatively, the owner of the database 103 or the owner of the content server 101-102 could force such a migration.) This may indicate to logic circuitry 215 that a migration may occur causing the current session state to be provided to state database 203. When a second device 106-108 wishes to render the digital content, the second device accesses state database server 103 to determine an address of the content server hosting the requested file, and is provided with the address along with the current session state. The current session state is stored in state database 211. When the second device renders the digital content, it is rendered having the same session state (e.g., amount of media rendered, volume, . . . , etc.). So for example, if an MP3 song was 35% rendered on a first device, operating at a first volume level, the second device would begin playing the content 35% into the song, at the first volume level.
In a more-detailed example, assume a first MP3 player is 35% into playing a song at a first volume level. The MP3 player contains a play list of songs to be played. The user wishes to seamlessly migrate to a second MP3 player within their automobile. The above procedures will require the automobile's MP3 player to access state database server 103 to acquire the current session state of the first MP3 player and an address of the content server containing the digital content to be rendered. The automobile's MP3 player will access the appropriate content server and appropriately render the digital content. When moving to the car, the music continues to be played uninterrupted, at the same volume level, as if emanating from a single device. In addition, the play list is also transferred to the automobile's MP3 player.
It should be noted that application 209 may receive media from content servers 101, 102 in various forms. For example, a media file may simply be transferred to the client device, or alternatively may be streamed from the content server. The technique used to provide application 209 with the file will dictate what device utilizes the state information to allow the destination device to provide the content in the appropriate state. It will also dictate what device (i.e., the client device or the content server) updates state database server 103. Thus, in a first embodiment, where content is streamed from a content server, the content server is provided the current session state (either by the destination device, or alternatively by the state database itself) so that streaming may begin at the appropriate time. During streaming, the content server will update state database server 103.
Alternatively, in a second embodiment, where media files are provided to application 209, the client device only needs to request the appropriate files from a content server 101-102. Application 209 will analyze state database 211 to determine the session state and appropriately render the content in the correct session state. The client device will update state database server 103.
The current session state of the digital content preferably is received from the client device; however, in an alternate embodiment of the present invention, the current session state may come directly from state database server 103. In a further alternate embodiment of the present invention, a content server may determine a session state from an existing session being provided to a user. More particularly, if a received request's session identification matches an existing session being provided by the content server, the current state can be obtained by analyzing the current session being provided to the user. At step 605 logic circuitry 219 analyzes the current session state and begins streaming the digital content to the client device (step 607). The streaming maintains the current session state. In other words, the streaming is based on the current session state and will begin from the point where it left off of the source client device, having an amount of media rendered based on the current session state. In addition, all other session states (e.g., volume, . . . , etc.) will remain the same. Finally, at step 609, state database server 103 is periodically updated with the current session state via transmitter 221.
In an alternate embodiment, a client server will update state database server 103. The updating of state database server 103 in this manner will preferably take place when a client server is streaming digital content, and thus has immediate access as to the state. With this in mind,
Continuing, if at step 803 logic circuitry 205 determines that state parameters need to be updated, then the logic flow continues to step 805 where they are obtained (either internally, or from client device 106). If, however, at step 803 it is determined that state parameters are not needed from client device 106, the logic flow simply continues to step 807 where state information is provided, via transceiver 207, to state database server 103.
While the invention has been particularly shown and described with reference to a particular embodiment, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention. For example, the above discussion does not require the web server and media server to be distinct products. In other words, both can be bundled as part of a single product. In this case, the messages described above, can be implemented as software interfaces that can be invoked using inter-process communication (IPC) mechanisms. It is intended that such changes come within the scope of the following claims.
