WO2015112997A1 - Method and apparatus for remote adjustable cross network streaming chain - Google Patents

Abstract

The invention enables the streaming of data from one Device to many receiving Devices across networks. It also works if the Devices cannot reach each other directly. Furthermore this streaming is remotely controllable from yet another Device which again does not need a direct connection to other Devices.

Description

Method and Apparatus for Remote Adjustable Cross Network Streaming Chain

RELATED APPLICATION

[0000] The present Application for Patent claims priority to U.S. Patent Application No. 14164231 titled "Method and Apparatus for Remote Adjustable Cross Network Streaming Chain" filed 01/26/2014, pending, and which is hereby incorporated herein by reference.

FIELD OF THE INVENTION

[0001] The present invention pertains to streaming to one or more devices. More particularly, the present invention relates to Method and Apparatus for Remote Adjustable Cross Network Streaming Chain.

BACKGROUND OF THE INVENTION

[0002] Communicating content from one device to another device is often desired. Data, for example, in the form of a music file, may be located on a first device however the user of a second device may want the data, in this example the music file, communicated to the second device for storage and/or playing. Additionally, the user may want to remotely control how the data, in this example the music file, is not only communicated but rendered, stopped, started, etc. as well. Doing this across different networks, each with different filtering, firewalls, etc. is very difficult and often impossible without extreme user intervention in altering firewall settings, configuration, router setup, etc. This configuring by a user presents its own set of technical issues and security risks. This presents a technical problem for which a technical solution using a technical means is needed.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which:

[0004] Figure 1 illustrates a network environment in which the method and apparatus of the invention may be implemented;

[0005] Figure 2 is a block diagram of a computer system which may implement some embodiments of the invention and where some embodiments of the invention may be used;

[0006] Figure 3 illustrates one embodiment of the invention showing a StreamingChain;

[0007] Figure 4 illustrates one embodiment of the invention showing a StreamingChain setup;

[0008] Figure 5 illustrates one embodiment of the invention showing user commands and Master Server push messages;

[0009] Figure 6 illustrates various embodiment of Device types;

[0010] Figure 7 and Figure 8 illustrate one embodiment of invention, showing a first Device playing local music locally;

[0011] Figure 9 and Figure 10 illustrate one embodiment of invention, showing streaming from a first Device to a second Device;

[0012] Figure 11 and Figure 12 illustrate one embodiment of invention, showing streaming from a first Device to a third Device;

[0013] Figure 13 and Figure 14 illustrate one embodiment of invention, showing listening to music in a web browser;

[0014] Figure 15 and Figure 16 illustrate one embodiment of invention, showing a passive Device being found and streaming to a Device B and Device T;

[0015] Figure 17 illustrates embodiment of the invention showing a block diagram of a streaming buffer; and

[0016] Figure 18 illustrates various embodiments of the invention.

DETAILED DESCRIPTION

[0017] In one embodiment the invention provides a system to stream binary media data from one device to one or multiple other devices across network boundaries. The system is designed to allow the seamless change of target devices without affecting existing target devices. It is also designed to minimize the network traffic.

[0018] To illustrate some of the features and embodiments of the invention we shall describe data in the form of music or media files. However, the invention is not so limited and any form of data may be used, for example, but not limited to binary data, video, file transfers, voice, movies, payments, credits, word files, social media communications, marketplace

communications, etc.

[0019] In one embodiment the invention is a distributed Media Player. In such an embodiment a Media Player mechanism (Device) (such as, but not limited to, a device having hardware or a combination of hardware and software, but not software alone) that when implemented on multiple devices acts like one system. For example, all the music from any device is available everywhere and all devices are available as media renderers. A user can select where the media plays (e.g. rendered) and then can play any media file. The system then transports each file from w^rhere it is stored to all devices where it needs to render on demand. This works across the Internet, so even if devices cannot directly connect to each other operation is possible. The only requirement is that devices are turned on and Internet connected for full functionality of remote control, etc.

[0020] In one embodiment of the invention each Media Player (Device) installation is separated into up to four components and/or roles as follows.

[0021] The first is a MediaProvider (MP): A MediaProvider component has access to the locally stored media files. It indexes those files and makes the index accessible to all Controllers. It can receive a command to provide any of these indexed files and transmit its contents to a StreamingHub.

[0022] The second is a StreamingHub (SH): A StreamingHub component connects multiple components of the media player. Those components can be on the same device or on different devices. A StreamingHub receives a media file stream and provides it to one or many Receivers also denoted a MediaRenderer. A Receiver can be one of three things:

1. a local MediaRenderer.

2. a remote MediaRenderer.

3. a remote StreamingHub.

Receivers can be added during playback at the current media playback position. [0023] The third is a Media enderer (MR): MediaRenderes also called Receivers (RE) receive a media file stream and render it on the local system. Rendering refers to decoding the media codec and having the local system play the file on the local system (i.e. playing a movie file on the connected screen or playing a sound file on the connected speakers).

[0024] The fourth is a Controller (CT): A Controller is, in one embodiment, the user interface that displays all the media files, playlists, target devices, playlists and settings. A controller is the component that triggers media file playbacks, changes, and applies settings to the current playback (for example, but not limited to, volume or selected devices to render the music). The Controller has access to all the indexes of all MediaProviders and the list of all available MediaRenderers.

[0025] In one embodiment the system additionally consists of a Master Server (hosted and controlled by a company). The Master Server manages a user's account and knows:

- all the MediaProviders' media indexes,

- all the Device installations and the components/roles each installation provides, and

- which installation can directly reach which other installation.

The Master Server can also send commands to each component of each installation, (called "server push notifications").

An installation generally combines multiple of the roles mentioned above.

[0026] Figure 3 illustrates, generally at 300, one embodiment of the invention showing a StreamingChain. At 302 is a MP, at 304 a SH, and at 306 a RE. At 303 is shown a 1 : 1 communication (i.e. a one to one communication), at 305 and 307 are shown a 1 :n, where n is an integer greater than 0 (i.e. a one to n communication). In order to play any media file on any set of target Devices, no matter where the source file is stored or how the Devices are are connected, the StreamingChain was invented. For example, when a new media file is played (for instance triggered by a user interaction or the completion of a previous playback) or when a new set of MediaRenderers is chosen by the user, then the Master Server chooses a new set of nodes (such as 302, 304, 306), sends messages to each node (such as 302, 304, 306) to have them connect and stream the media file (also called the music) While 303, 305, and 307 have arrows indicating a predominate communications direction, such as the majority of the direction of the

communications, the invention is not so limited and it is to be appreciated that there can be communications in the directions opposite the arrows.

[0027] Figure 4 illustrates, generally at 400, one embodiment of the invention showing a StreamingChain setup. In this illustrated embodiment 402 represents the Internet (also known as the cloud), 404 a SH, 406 a first network which has 408 a MP, 403 a communications link between 408 MP and 404 SH. At 410 is a second network (separate and distinct from the first network 406). The second network 410 has 412 a SH, 414 a MP, 416 a RE, and 418 a RE, 405 a communications like between 404 SH and 412 SH, a communications link between 412 SH and 416 RE, and a communications link between 412 SH and 418 RE. As can be seen in Figure 4 this embodiment has the ability to stream media files (or any data) from one provider (e.g. a Device that has direct access to the file) to multiple receivers (e.g. a Device that can render the file) across network boundaries (e.g. through NAT firewalls, etc.), while all this is remote controllable from the cloud. For example, a media file on MP 408 can be communicated via communication link 403 through a firewall associated with the first network 408 to SH 404 which then streams via communication link 405 the media file provided by MP 408 through any firewall associated with the second network 410 to 412 SH. SH 412 then communicates within the second network 410 via communication links 407 and 409 to RE 416 and 418 respectively. All this streaming (408 MP to 404 SH to 412 SH to 416 RE and 418 RE is controllable from cloud 402. This allows streaming data to any Device, no matter how it is connected to the Internet. It also allows control of the stream from any Device (having a CT), no matter how it is connected to the Internet.

[0028] Figure 5 illustrates, generally at 500, one embodiment of the invention showing user commands and Master Server push messages. At 502 is a Master Server which communicates via communication link 503 Master Server push messages to 504 a MP, 506 a SH, 508 a MR, and 510 a CT. From CT (controller) 510 are communicated via communication link 505 user commands to 502 Master Server. In this embodiment streaming data to any Device, no matter how it is connected to the Internet is possible while allowing control of the stream from any Device (in this embodiment 510 CT), no matter how it is connected to the Internet.

[0029] In one embodiment the invention enables the streaming of data from one Device to many receiving Devices across networks, so it also works if the Devices cannot reach each other directly. Furthermore this streaming is remote controllable from yet another Device which again does not need a direct connection.

[0030] In one embodiment of the invention, Devices and services provide for playing media files, largely as described above. For ease of discussion this will be referred to as OnAir Player. Various embodiments of the invention will be described using OnAir Player.

[0031] Figure 6 illustrates, generally at 600, various embodiment of Device types. At 602 is an OnAir Player Installation showing at 604 a MP, at 606 a CT, at 608 a SH, and at 610 a MR. At 620 is a OnAir Play er Relay Serve showing at 622 a SH. At 630 is an External passive Device showing at 632 a MR. At 640 is a OnAir Player Web Client showing at 642 a CT, and at 644 a MR.

[0032] Figure 7 and Figure 8 illustrate, generally at 700 and 800, one embodiment of the invention, showing a first Device playing local music locally. Figure 7 illustrates arrows in the direction of the byte stream flow, and Figure 8 illustrates arrows in the direction of connection establishment. In Figure 7 at Device A 702 is a MP 704, a CT 706, a SH 708, and a MR 710. As can been seen the direction of the byte stream flow goes from 704 MP to 708 SH to 710 MR. In Figure 8 at Device A 802 is a MP 804, a CT 806, a SH 808, and a MR 810. As can been seen the direction of the connection establishment goes from 804 MP to 808 SH and from 810 MR to 808 SH.

[0033] Figure 9 and Figure 10 illustrate, generally at 900 and 1000, one embodiment of invention, showing streaming from a first Device to a second Device. For example a Mac laptop logging in and streaming from a Device A to a Device B using a common (i.e. both Devices can access the same) WiFi network. Figure 9 has arrows indicating the direction of byte stream flow. Figure 10 has arrows in the direction of connection establishment. In Figure 9 at 902 is Device A having at 904 a MP, at 906 a CT, at 908 a SH, and at 910 a MR. In Figure 9 at 920 is Device B having at 924 a SH, at 926 a MR, at 928 a MP, and at 930 a CT. As can been seen in Figure 9 the direction of the byte stream flow is from 902 Device A's MP at 904 to 902 Device A's SH at 908 and from 902 Device A's SH at 908 to 920 Device B's SH at 924 to 920 Device B's MR at 926.

[0034] In Figure 10 at 1002 is Device B having at 1004 a MP, at 1006 a CT, at 1008 a SH, and at 1010 a MR. In Figure 10 at 1020 is Device B having at 1024 a SH, at 1026 a MR, at 1028 a MP, and at 1030 a CT. As can been seen in Figure 10 the direction of connection establishment has several variations one is from 1002 Device A's MP at 1004 to 1002 Device A's SH at 1008 and from 1002 Device A's SH at 1008 to 1020 Device B's SH at 1024 and from 1020 Device B's MR at 1026 to 1020 Device B's SH at 1024 (1008 to 1024 direction). The second variation is from 1020 Device B's MR at 1026 to 1020 Device B's SH at 1024 and from 1020 Device B's SH at 1024 to 1002 Device A's SH at 1008 and from 1002 Device A's MP at 1004 to 1002 Device A's SH at 1008 (1024 to 1008 direction). The determination of whether the connection should be established from Device A 1002 to Device B 1020 or from Device B 1020 to Device A 1002 can, in one embodiment, be chosen depending on the ability to directly connect to the other Device.

[0035] Figure 11 and Figure 12 illustrate, generally at 1 100 and 1200, one embodiment of invention, showing streaming from a first Device to a third Device. For example a third Device logging in and streaming from a Device A to a Device C. Figure 11 has arrows indicating the direction of byte stream flow. Figure 12 has arrows in the direction of connection establishment. In Figure 11 at 1102 is an OnAir Player Relay Server having at 1104 a SH. At 11 10 is Device A having at 1112 a MP, at 11 14 a CT, at 1116 a SH, and at 1 118 a MR. In Figure 11 at 1120 is Device C having at 1 122 a SH, at 1124 a MR, at 1 126 a MP, and at 1128 a CT. At 1130 is NAT Router and/or a Firewall. At 1140 is NAT Router and/or a Firewall. As can been seen in Figure 11 the direction of the byte stream flow is from 11 10 Device A's MP at 1112 to 1110 Device A's SH at 1116 and from 1110 Device A's SH at 1 116 through 1 130 NAT Router and/or Firewall to 1102 OnAir Player Relay Server's SH at 1104. and then from 1102 OnAir Player Relay Server's SH at 1104. through 1 140 NAT Router and/or Firewall to 1 120 Device C's SH at 1 122 to 1120 Device C's MR at 1 124.

[0036] In Figure 12 at 1202 is an OnAir Player Relay Server having at 1204 a SH. At 1210 is Device A having at 1212 a MP, at 1214 a CT, at 1216 a SH, and at 1218 a MR. In Figure 12 at 1220 is Device C having at 1222 a SH, at 1224 a MR, at 1226 a MP, and at 1228 a CT. At 1230 is NAT Router and/or a Firewall. At 1240 is NAT Router and/or a Firewall. As can been seen in Figure 12 the direction of the connection establishment is from 1210 Device A's MP at 1212 to 1210 Device A's SH at 1216 and from 1210 Device A's SH at 1216 through 1230 NAT Router and/or Firewall to 1202 OnAir Player Relay Server's SH at 1204.and from 1220 Device C's MR at 1224 to 1220 Device C's SH at' 1222 and then through 1240 NAT Router and/or Firewall to 1202 OnAir Player Relay Server's SH at 1204.

[0037] Figure 13 and Figure 14 illustrate, generally at 1300 and 1400, one embodiment of invention, showing listening to music in a web browser. Figure 13 has arrows indicating the direction of data flow. Figure 14 has arrows in the direction of connection establishment. In Figure 13 at 1302 is an OnAir Player Relay Server having at 1304 a SH. At 1310 is Device A having at 1312 a MP, at 1314 a CT, at 1316 a SH, and at 1318 a MR. In Figure 13 at 1320 is an OnAir Player Web Client having at 1322 a CT, and at 1324 a MR. At 1330 is NAT Router and/or a Firewall. At 1340 is NAT Router and/or a Firewall. As can been seen in Figure 13 the direction of the data flow is from 1310 Device A's MP at 1312 to 1310 Device A's SH at 1316 and from 1310 Device A's SH at 1316 through 1330 NAT Router and/or Firewall to 1302 OnAir Player Relay Server's SH at 1304.and then from 1302 OnAir Player Relay Server's SH at 1304. through 1340 NAT Router and/or Firewall to 1320 OnAir Player Web Client's MR at 1324.

[0038] In Figure 14 at 1402 is an OnAir Player Relay Server having at 1404 a SH. At 1410 is Device A having at 1412 a MP, at 1414 a CT, at 1416 a SH, and at 1418 a MR. In Figure 14 at 1420 is an OnAir Player Web Client having at 1422 a CT, and at 1424 a MR, At 1430 is NAT Router and/or a Firewall. At 1440 is NAT Router and/or a Firewall. As can been seen in Figure 14 the direction of the connection establishment is from 1410 Device A's MP at 1412 to 1410 Device A's SH at 1416 and from 1410 Device A's SH at 1416 through 1430 NAT Router and/or Firewall to 1402 OnAir Player Relay Server's SH at 1404.and from 1420 OnAir Player Web Client's MR at 1424 through 1440 NAT Router and/or Firewall to 1402 OnAir Player Relay Server's SH at 1404.

[0039] Figure 15 and Figure 16 illustrate, generally at 1500 and 1600, one embodiment of the invention, showing a passive Device being found and streaming to a Device B and Device T. Figure 15 has arrows indicating the direction of data flow. Figure 16 has arrows in the direction of connection establishment. In Figure 15 at 1502 is an OnAir Player Relay Server having at 1504 a SH. At 1510 is Device A having at 1512 a MP, at 1514 a CT, at 1516 a SH, and at 1518 a MR. In Figure 15 at 1520 is a Device B having at 1522 a MP, at 1524 a CT, at 1526 a SH, and at 1528 a MR. At 1530 is Device C having at 1532 a SH, at 1534 a MR, at 1536 a MP, and at 1538 a CT. At 1540 is Device T having at 1542 a MR. At 1550 is NAT Router and/or a Firewall. At 1560 is NAT Router and/or a Firewall. As can been seen in Figure 15 the direction of data flow is from 1530 Device C's MP at 1536 to 1530 Device C's SH at 1532 and from 1532 Device C's SH at 1532 through 1560 NAT Router and/or Firewall to 1502 OnAir Play er Relay Server's SH at 1504.and then from 1502 OnAir Player Relay Server's SH at 1504. through 1550 NAT Router and/or Firewall to 1510 Device A's SH at 1526, then from 1510 Device A's SH at 1526 to two destinations, the first being 1520 Device B's SH at 1526. (the data then going to 1520 Device B's MR at 1 28), and the second destination being 1540 Device T's MR at 1542.

[0040] In Figure 16 at 1602 is an OnAir Player Relay Server having at 1604 a SH. At 1610 is Device A having at 1612 a MP, at 1614 a CT, at 1616 a SH, and at 1618 a MR. In Figure 16 at 1460 is Device B having at 1622 a MP, at 1624 a CT, at 1626 a SH, and at 1628 a MR, At 1630 is Device C having at 1632 a SH, at 1634 a MR, at 1636 a MP, and at 1638 a CT. At 1640 is Device T having at 1642 a MR. At 1650 is NAT Router and/or a Firewall. At 1660 is NAT Router and/or a Firewall. As can been seen in Figure 16 the direction of one of the connection establishments is from 1630 Device C's MP at 1636 to 1630 Device C's SH at 1632 and from 1630 Device C's SH at 1632 through 1660 NAT Router and/or Firewall to 1602 OnAir Player Relay Server's SH at 1604. Another direction of connection establishment is from 1610 Device A's SH at 1616 through 1650 NAT Router and/or Firewall to 1602 OnAir Player Relay Server's SH at 1604. Another direction of connection establishment is from 1640 Device T's MR at 1642 to 1610 Device A's SH at 1616. Another direction of connection establishment is 1620 Device B's MR at 1628 going to 1620 Device B's AH at 1626. The remaining direction of connections establishment has two variations, the first variations is from 1620 Device B's SH at 1626 to 1610 Device A's SH at 1616 (1626 to 1616 direction). The second variation is from 1610 Device A's SH at 1616 to 1620 Device B's SH at 1626 (1616 to 1626 direction). The determination of whether the connection should be established using the first variation or the second variation, can, in one embodiment, be chosen depending on the ability to directly connect to the other Device. For example, if Device A can directly connect to Device B while Device B cannot connect directly to Device A, then the Device A to Device B connection establishment would be used.

[0041] Figure 17 illustrates, generally at 1700 one embodiment of the invention showing a block diagram of a streaming buffer. At 1701 is a stream entering a shared buffer 1702. At 1704-1 through 1704-r, where r is an integer, are r streams being sent to r Receivers (MRs). Thus showing the 1 to many feature. At 1703 is figuratively shown a current position pointer indicating the current playback position within the shared buffer 1702 and figuratively showing with dashed line 1705 the direction the current position pointer 1703 will move with the advance of time. In such an embodiment streaming targets (e.g. the Media Renderers (Receivers) 1 to r that actually play the media file) can be added or removed during playback at the current playback position without affecting existing MRs. This capability is achieved in the SH implementation which allows for 1 to many streaming, meaning it can distribute the incoming stream to multiple other Receivers. It does so by employing the shared buffer from which every Receiver r 1704-1 through 1704-r is served. The incoming stream 1701 will be written to the shared buffer 1702 and can be read many times for each Receiver. The shared buffer 1702 is special in the way that it has knowledge about the media file that is being buffered (i.e. from 1701): It knows, for example but is not limited to, the average bitrate of the media format used. This knowledge is transmitted in stream, meaning every stream begins with a header that contains this data. A SH extracts this header when receiving the stream and stores the information about the bitrate. If a new Receiver is added to the SH (e.g. because the user selected a new streaming target Device for example), then the SH will not serve the media file from the beginning but can compute how many bytes to skip (bytes per second * seconds elapsed). Hence a new Receiver can be added to the SH at the current playback position 1703 without affecting other Receivers.

[0042] As illustrated in the Figures and discussed above Method and Apparatus for Remote Adjustable Cross Network Streaming Chain has a variety of illustrated embodiments, however the invention is not so limited and other variations are possible. To illustrate some of these various embodiments we will describe an overview of operation of an OnAir Player in action using some of the techniques disclosed in five scenarios.

[0043] Scenario 1 - First Device logging in (for example, a Windows Laptop Computer) [0044] Associate Device with account on Master Server

[0045] When the user first starts the OnAir Player on the Windows laptop computer the user is asked to create a new account or log in with an existing one (the same happens on any Device when started for the first time). We will call the OnAir Player installation on this Windows laptop "Device A" for better reference.

[0046] When Device A logs in with the Master Server, it uploads some data about itself (for example, but not limited to, local network IP address, Device detection port, inter Device streaming port, name). The Windows installation of OnAir Player contains the following components of the software: MP, SH, MR & CT. This information is also transmitted to the Master Server at login. The Master Server returns that same data about all other Devices from the same account that are currently online. In this case there is no such Device yet, so that list will only contain the Device A.

[0047] Make local media files known to all Devices

[0048] After the user has selected some local file system folder to import the media files from, the MP will start indexing those files (for example, but not limited to, extracting data like title, artist, length, genre and more). There are already some folders preselected and will thus be indexed even without user interaction (e.g. the Windows laptop "My Music" folder). The MP will then upload that index to the Master Server which will store it in a database. The Master Server will now send a command to all CTs (currently only Device A) that new media is available. The CT component of Device A will then connect to the Master Server to get the update. Once received the CT will update the user interface and display the data to the user. The CT will also store that index data locally, so that it does not need to retrieve the whole index on every start of the software but can only ask for updates since the last start ( thus minimizing precious limited bandwidth and saving network resources and CPU cycles and speeding up operation).

[0049] The CT also received the list of all other Devices, so it can display that list to the user and let the user decide on what Device the media should be played. (That list contains only Device A at this time).

[0050] When the user selects Device A as a streaming target, then this information is transmitted to the Master Server. No action is taken yet since no playback has been started.

[0051] Playing / streaming a media file

[0052] When the user selects a media file to be played, then a HTTP call to the Master Server occurs. The Master Server knows that the media file is stored on Device A and that the media should be played on Device A as well. It then sends multiple commands to Device A: 1. a command to the MP to start streaming the contents of the media file to the SH of Device A.

2. a command to the SH of Device A to receive that stream and pass it on to the MR of Device A.

[0053] Since the MR of Device A is now receiving media data it will start rendering it (for instance, but not limited to, playing the movie on the screen or playing a song on the attached speakers of Device A).

[0054] In an alternative embodiment, this communication could also be optimized to avoid the Master Server and message the components (MP, SH, MR) directly.

[0055] Scenario 2 - Second Device logging in (for example, a Mac Laptop)

[0056] Associate Device with account on Master Server

[0057] When the user first starts the OnAir Player on OSX then the user is asked to create a new account or log in with an existing one. Since the user intends to stream between Devices and share the media, the user will log in with the same account that was created when starting Device A. We will call the OnAir Player installation for example, on this Macbook Pro laptop, "Device B" for reference.

[0058] When Device B logs in with the Master Server, it uploads some data about itself (for example, but not limited to, local network IP address, Device detection port, inter Device streaming port, name). The OSX installation of OnAir Player contains the following components: MP, SH, MR & CT. This information is also transmitted to the Master Server at login. The Master Server returns that same data about all other Devices from the same account that are currently online. In this case this list contains the data about Device A and Device B.

[0059] Since in this example Device B identified itself as have a CT, the initial login also returns the media file index (which so far only contains the media from Device A). Due to the fact that the Device B, in this example, identified itself as have a MR, the Master Server will send an update command to all existing CTs to announce that a new streaming Device is available. Those CTs (currently only Device A) will then offer the new Device as a streaming destination in the user interface.

[0060] Checking direct inter-Device connectivity

[0061] Device B will now check if it can connect to any of the other Devices directly. Since it retrieved, for example, their local IP address and Device discovery port from the Master Server at login, Device B will try to directly connect to that IP / port using, for example, a TCP socket. In this example the connection is successful because both Devices are on the same network (e.g. home WiFi). Device B will transmit the data about itself to Device A, so that Device A can add Device B to the list of all online Devices. This data also contains open ports information for direct streaming. Now both Device A and Device B have full knowledge of all online Devices for the user's account. After the initial communication handshakes Device A will keep the socket open and send keep-alive messages every few seconds. In this way Device A will know if Device B changes its connectivity and is not directly reachable any more. After Device A receives the data about Device B, Device A will also connect using a TCP socket and will also start sending keep-alive messages to detect a Device B drop off (loss of connectivity to Device B).

[0062] After both Devices (in this example, Device A and Device B) successfully discovered each other on the network, they each upload this data ("can reach Device A") to the Master Server which now can build a full connectivity graph of all Devices for this user's account.

[0063] Make local media files known to all Devices (for this user's account)

[0064] After the user selected some local file system folder to import the media files from, the MP will start indexing those files (extract data like, but not limited to, title, artist, length, genre and more). There are already some folders preselected and will thus be indexed even without user interaction (e.g. the OSX "-/Music" folder). The MP will then upload that index to the Master Server which will store it in a database. The Master Server will now send a command to all CTs (Device A and Device B in this example) that new media is available. Those CT components will then connect to the Master Server to get the update. Once received, the CT components of those Devices will update the user interface and display the data to the user. The CT will also store that index data locally, so that it does not need to retrieve the whole index on every start of the OnAir Player but can only ask for updates since the last start.

[0065] The CT of all Devices now offers Device A and Device B as streaming targets. In this example, the user now selects Device B as the target, then the user selects a media file to be played that is stored on Device A.

[0066] Playing / streaming a media file

[0067] When the user selected a media file to play (which was stored on Device A), a HTTP call to the Master Server was made. The Master Server now knows that a media file from Device A is to be streamed to Device B. It also knows that Device A can reach Device B via direct streaming. Thus it sends the following commands:

1. a command to the MP of Device A to stream the contents of the media file to the SH of Device A.

2. a command to the SH of Device A to receive the local stream, establish a direct connection to Device B and stream the data to the SH of Device B. 3. a command to the SH of Device B to accept a local connection from Device A and pass it on to the MR of Device B.

[0068] This will result in Device B playing music that was stored on Device A.

[0069] Scenario 3 - Third Device logging in (for example, an Android smartphone)

[0070] Associate Device with account on Master Server

[0071] When the user first starts the OnAir Player on Android the user is asked to create a new account or log in with an existing account. Since the user intends to stream in between Devices and share media, the user will log in with the same account that was created when starting Device A. We will call the OnAir Player installation on this Android phone "Device C" for reference.

[0072] When Device C logs in with the Master Server, it uploads some data about itself (for example, but not limited to, local network IP address, Device detection port, inter Device streaming port, name). The Android installation of OnAir Player contains the following components: MP, SH, MR & CT. This information is also transmitted to the Master Server at login. The Master Server returns that same data about all other Devices from the same account that are currently online. In this case this list contains the data about Device A, Device B, and Device C.

[0073] In this example, since Device C identified itself as having a CT, the initial login also returns the media file index (which so far contains the media from Device A and Device B). Due to the fact that Device C identified itself as having a MR, the Master Server will send an update command to all existing CTs (on any Devices for this user's account) to announce that a new streaming Device is available. Those CTs (currently Device A and Device B) will then offer the new Device (Device C in this example) as a streaming destination in the user interface.

[0074] Checking direct inter-Device connectivity

[0075] Device C will now check if it can connect to any of the other Devices directly. Since it retrieved their local IP address and Device discovery port from the Master Server at login, it will try to directly connect to that IP / port using a TCP socket. In this example the connection is not successful because the smartphone is on a cellular network (e.g. 3G/4G) and thus cannot reach the other Devices (Device A and Device B) that are, for example, behind a home NAT router.

[0076] After failing to connect to any other Device, Device C will upload the list of all reachable Devices (in this case an empty list) to the Master Server. The Master Server can now update its connectivity graph.

[0077] Make local media files known to all Devices [0078] On the Android smartphone the MP will start indexing all music files that can be found on the Device (extracting data like, but not limited to, title, artist, length, genre and more). The Android smartphone MP will then upload that index to the Master Server which will store it in a database. The Master Server will now send a command to all CTs (Device A, Device B, and Device C in this example) that new media is available. Those CT components (on Devices for this user's account) will then connect to the Master Server to get the update. Once received, the CT components of those Devices will update the user interface and display the data to the user. The CTs will also store that index data locally, so that it does not need to retrieve the whole index on every start of the OnAir Player but can only ask for updates since last starting.

[0079] The CT of all Devices (in this example Device A, Device B, and Device C) now offers Device A, Device B, and Device C as a streaming target. In this example, the user now selects Device C as the target, the user then selects a media file to be played that is stored on Device A.

[0080] Playing / streaming a media file

[0081] When the user, in this example, selects a media file to play, a HTTP call to the Master Server is made. The Master Server now knows that a media file from Device A is to be streamed to Device C. It also knows that Device A cannot reach Device C via direct streaming. Thus it sends the following commands:

1 . a command to the MP of Device A to stream the contents of the media file to the SH of Device A.

2. a command to the SH of Device A to receive the local stream, establish a connection to a Relay Server (the URL is specified in the command structure) and start uploading the media data.

3. a command to the SH of Device C to connect to the same Relay Server (URL is again specified in the command structure) and download the media stream. The command also contains the instruction to push the received data to the local MR for rendering.

[0082] This will lead to Device C playing music that was stored on Device A despite no direct available connection between the Device C and Device A devices.

[0083] A Relay Server is a server (hosted by a company "in the cloud") that can be accessed by any Internet connected Device. The uploading Device (SH) will use an outgoing HTTP POST connection to connect to the Relay Server. The receiving Device (SH) will use an outgoing HTTP GET connection to connect to the Relay Server. The Relay Server will then connect those two streams (from the two SHs). Since both those connections are outbound and are using standard HTTP, almost all Firewalls and routers allow the connection. Thus a connection between two Devices across networks works without requiring user or firewall and/or router configuration.

[0084] A Relay Server, just like every SH, allows for 1 to many streaming. This means that while Device C is uploading the data only once, many Devices (for instance Device A, a Device D, and a Device E) can connect to the same Relay Server using a HTTP GET and receive the same media file byte stream or data stream.

[0085] Scenario 4 - A passive Device (e.g. a TV on the local network) is found

[0086] Every Device installation not only searches for other OnAir Player installations and whether they can be reached directly, but also scans for passive devices that can be discovered. One example is support for some smart TVs (using for example, DLNA, or UPnP, or other discoverable mechanisms) every Device constantly scans the local network for available and compatible devices that can receive and render a media file byte stream or data stream.

[0087] Now in this example, Device A detects a smart TV on the local network (Device T). Device A then uploads a new list of all reachable Devices, now containing Device B and Device T. Device T is marked to be a MR only Device as it is an external device that only offers to receive and render media. The Master Server now updates the Device graph and sends an update command to all Devices having a CT since a new streaming target is now available. This will lead to all user interfaces of all CT Devices (Device A, Device B, and Device C in this example) will now offer the option of streaming to Device A, Device B, Device C, Device T, or any combination thereof (in no preferential order).

[0088] Playing / streaming a media file

[0089] Now the user selects Device T and Device B as streaming targets and plays a media file which is stored on Device C. (Device C is the Android phone that is on 3G/4G).

[0090] When the user selects the media file to play, a HTTP call to the Master Server is made. The Master Server now knows that a media file from Device C is to be streamed to Device B and Device T. It also knows that Device C cannot reach Device B nor can it reach Device T. It knows that Device A can reach both Device B and Device T via direct streaming. Thus it sends the following commands:

1. a command to the MP of Device C to stream the contents of the media file to the SH of Device C.

2. a command to the SH of Device C to receive the local stream, establish a connection to a Relay Server (the URL is specified in the command structure) and start uploading the media data. 3. a command to the SH of Device A to connect to the same Relay Server (URL is again specified in the command structure) and download the media stream. The command also contains the instruction to forward the stream to Device B and to Device T.

4. a command to the SH of Device B to receive a local media file stream and pass it on to the local Device B MR for rendering.

[0091] Device A now downloads the media stream once and passes it on to multiple devices: in this example, Device B and Device T. For Device B it connects directly using TCP sockets and sends the media stream / data. For Device T, the smart TV, it creates a local HTTP server and tells the smart TV to connect to that same server. Every HTTP request made to this server will serve the content of the media file. Thus the smart TV will receive the media file and play it.

[0092] Instead of having Device A download and distribute the stream in the local network, in an alternative embodiment, one could also tell Device B to download the stream from the Relay Server directly instead. However, it would be less efficient since the connection speed of a local network (used to stream the data from Device A to Device B) is much faster than the average Internet connection.

[0093] Scenario 5 - Changing the target Devices during playback

[0094] One of the advantages of the invented system is the ability to add and remove streaming targets (e.g. the Media Renderer that actually plays the media file) during playback at the current playback position without affecting existing MRs.

[0095] This capability is achieved in the SH implementation which allows for 1 to many streaming, meaning it can distribute the incoming byte stream to multiple other Receivers. It does so by employing a shared byte buffer from which every Receiver is served. The incoming byte stream will be written to that buffer and can be read many times for each Receiver. The byte buffer is special in the way that it has knowledge about the media file that is being buffered: It knows, for example but is not limited to, the average bitrate of the media format used. This knowledge is transmitted in stream, meaning every stream begins with a header that contains this data. A SH extracts this header when receiving the stream and stores the information about the bitrate. If a new Receiver is added to the SH (e.g. because the user selected a new streaming target Device for example), then the SH will not serve the media file from the beginning but can compute how many bytes to skip (bytes per second * seconds elapsed). Hence a new Receiver can be added to the SH at the current playback position without affecting other Receivers.

[0096] In one embodiment, the system allows streaming to any combination of all available streaming target Devices (MRs) and allows the user to change this combination at any time. When the user selects a new combination then a HTTP request is made to the Master Server which knows the current streaming chain setup, knows the current connectivity graph and can send commands to any Device at any time. New Devices can be added by sending a currently active SH a new command which contains more or fewer targets to stream to. The Master Server can also send a command to start uploading the current stream to a Relay Server which then can be used by yet another Device (for example, in an unreachable network) to download and render the music/data. If a Device is removed from the streaming chain then a command is sent to the SH that is serving the Device to either stop serving that Device (if it was serving multiple Devices) or to shut down (if it was serving only one Device).

[0097] Figure 18 illustrates various embodiments of the invention as indicated below.

[0098] Illustrated generally at 1. A method for controlling one or more Devices, the method comprising:

[0099] receiving from at least one of said one or more Devices a user input, said user input being transformed by a controller in said at least one Device into a user command message;

[00100] receiving said user command message on a Master Server, said Master Server having connectivity to a Internet;

[00101] transforming said received user command message into a series of one or more specialized messages for at least one of a MP, a SH, a MR, and a CT; and

[00102] pushing said series of one or more specialized messages to at least one of a MP, a SH, a MR, and a CT having connectivity to said Master Server.

[00103] Illustrated generally at 2. The method of claim 1 wherein said one or more Devices have at least one of a MP, a SH, a MR, and a CT.

[00104]

[00105] Illustrated generally at 3. The method of claim 1 wherein said one or more Devices have at least one SH.

[00106] Illustrated generally at 4. An apparatus comprising:

[00107] a first device, said first device having a MP and a SH, wherein said first device

MP is operatively coupled to said first device SH;

[00108] a second device, said second device having a SH and a MR; wherein said second device SH is operatively coupled to said second device MR; and

[00109] wherein said first device SH is operatively coupled to said second device SH.

[00110] Illustrated generally at 5. The apparatus of claim 4 wherein said first device further comprises one or more entities selected from the group consisting of a CT and a MR.

[00111] Illustrated generally at 6. The apparatus of claim 4 wherein said second device further comprises one or more entities selected from the group consisting of a MP and a CT. [00112] Illustrated generally at 7. The apparatus of claim 4 wherein said wherein said first device SH is operatively coupled to said second device SH further comprises said first device SH operatively coupled to a SH in a Relay Server and said Relay Server SH operatively coupled to said second device SH.

[00113] Illustrated generally at 8. The apparatus of claim 4 wherein said wherein said first device SH is operatively coupled to said second device SH further comprises said first device SH operatively coupled through a first NAT Router and/or Firewall to a SH in a Relay Server and said Relay Server SH operatively coupled through a second NAT Router and/or Firewall to said second device SH.

[00114] Illustrated generally at 9. An apparatus comprising:

[00115] a first device, said first device having a MP and a SH, wherein said first device

MP is operatively coupled to said first device SH;

[00116] a second device, said second device having a MR;

[00117] wherein said first device SH is operatively coupled to said second device MR.

[00118] Illustrated generally at 10. The apparatus of claim 9 wherein said wherein said first device SH is operatively coupled to said second device MR further comprises said first device SH operatively coupled to a SH in a Relay Server and said Relay Server SH operatively coupled to said second device MR.

[00119] Illustrated generally at 1 1 . An apparatus comprising:

[00120] a Relay Server having at least a SH;

[00121] a first Device having at least a SH, wherein said first Device SH is operatively coupled to said Relay Server SH;

[00122] a second Device having a least a MR; and

[00123] wherein said second Device MR is operatively coupled to said first Device SH.

[00124] Illustrated generally at 12. The apparatus of claim 1 1 further comprising:

[00125] a third Device having at least a SH and a MP, wherein said third Device MP is operatively coupled to said third Device SH; and

[00126] wherein said third Device SH is operatively coupled to said Relay Server SH.

[00127] Illustrated generally at 13. The apparatus of claim 1 1 further comprising:

[00128] a fourth Device having at least a SH and a MR, wherein said fourth Device MR is operatively coupled to said fourth Device SH; and

[00129] wherein said first Device SH is operatively coupled to said fourth Device SH.

[00130] Illustrated generally at 14. The apparatus of claim 13 wherein said wherein said first Device SH is operatively coupled to said Relay Server SH further comprises said Relay Server SH operatively coupled through a first NAT Router and/or Firewall to said first Device SH.

[00131] Illustrated generally at 15. The apparatus of claim 13 wherein said wherein said third Device SH is operatively coupled to said Relay Server SH. further comprises said third Device SH operatively coupled through a second NAT Router and/or Firewall to said Relay Server SH.

[00132] Illustrated generally at 16. The apparatus of claim 13 wherein said w^rherein said first Device SH is operatively coupled to said Relay Server SH further comprises said Relay Server SH operatively coupled through a first NAT Router and/or Firew^rall to said first Device SH; and wherein said wherein said third Device SH is operatively coupled to said Relay Server SH. further comprises said third Device SH operatively coupled through a second NAT Router and/or Firewall to said Relay Server SH.

[00133] Illustrated generally at 17. The apparatus of claim 16 wherein said first Device has one or more entities selected from the group consisting of a MP, a CT, and a MR.

[00134] Illustrated generally at 18. The apparatus of claim 17 wherein said fourth Device has one or more entities selected from the group consisting of a MP, and a CT.

[00135] Illustrated generally at 19. The apparatus of claim 18 wherein said third Device has one or more entities selected from the group consisting of a MR, and a CT.

[00136] Illustrated generally at 20. The apparatus of claim 1 1 wherein said second Device and said fourth Device said operatively coupled to said first Device SH are at different bitrates.

[00137] Thus a Method and Apparatus for Remote Adjustable Cross Network Streaming

Chain have been described.

[00138] Because of various considerations in embodiments of the present invention (for example, multiple streaming) specialized hardware is required.

[00139] Figure 1 illustrates a network environment 100 from which the techniques described may be accessed and/or controlled. The network environment 100 has a network 102 that connects S servers 104-1 through 104-S, and C clients 108-1 through 108-C. More details are described below.

[00140] Figure 2 is a block diagram of a computer system 200 which some embodiments of the invention may employ parts of in conjunction with required specialized hardware and which may be representative of use in any of the clients and/or servers shown in Figure 1, as well as, devices, clients, and servers in other Figures. More details are described below.

[00141] Referring back to Figure 1 , Figure 1 illustrates a network environment 100 in which the techniques described may be accessed and/or controlled. The network environment 100 has a network 102 that connects S servers 104-1 through 104-S, and C clients 108-1 through 108-C. As shown, several computer systems in the form of S servers 104-1 through 104-S and C clients 108-1 through 108-C are connected to each other via a network 102, which may be, for example, a corporate based network. Note that alternatively the network 102 might be or include one or more of: the Internet, a Local Area Network (LAN), Wide Area Network (WAN), satellite link, fiber network, cable network, or a combination of these and/or others. The servers may represent, for example, disk storage systems alone or storage and computing resources.

Likewise, the clients may have computing, storage, and viewing capabilities. The method and apparatus described herein may be accessed and/or controlled by essentially any type of communicating means or device whether local or remote, such as a LAN, a WAN, a system bus, etc. For example, a network connection which communicates via for example wireless may control an embodiment of the invention having a wireless communications device. Thus, the invention may find application at both the S servers 104-1 through 104-S, and C clients 108-1 through 108-C.

[00142] Referring back to Figure 2, Figure 2 illustrates a computer system 200 in block diagram form, which may be representative of any of the clients and/or servers shown in Figure 1. The block diagram is a high level conceptual representation and may be implemented in a variety of ways and by various architectures. Bus system 202 interconnects a Central Processing Unit (CPU) 204, Read Only Memory (ROM) 206, Random Access Memory (RAM) 208, storage 210, display 220, audio, 222, keyboard 224, pointer 226, miscellaneous input/output (I/O) devices 228 via link 229, and communications 230 via port 232. The bus system 202 may be for example, one or more of such buses as a system bus, Peripheral Component Interconnect (PCI), Advanced Graphics Port (AGP), Small Computer System Interface (SCSI), Institute of Electrical and Electronics Engineers (IEEE) standard number 1394 (Fire Wire), Universal Serial Bus (USB), etc. The CPU 204 may be a single, multiple, or even a distributed computing resource. Storage 210, may be Compact Disc (CD), Digital Versatile Disk (DVD), hard disks (HD), optical disks, tape, flash, memory sticks, video recorders, etc., all non-transitory medium. Display 220 might be, for example, used by an embodiment of the present invention. Note that depending upon the actual implementation of a computer system, the computer system may include some, all, more, or a rearrangement of components in the block diagram. For example, a thin client might consist of a wireless hand held device that lacks, for example, a traditional keyboard. Thus, many variations on the system of Figure 2 are possible.

[00143] For purposes of discussing and understanding the invention, it is to be understood that various terms are used by those knowledgeable in the art to describe techniques and approaches. Furthermore, in the description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one of ordinary skill in the art that the present invention may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention. These embodiments are described in sufficient detail to enable those of ordinary skill in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, mechanical, electrical, and other changes may be made without departing from the scope of the present invention.

[00144] Some portions of the description may be presented in terms of algorithms and symbolic representations of operations on, for example, data bits within a computer memory. These algorithmic descriptions and representations are used by those of ordinary skill in the data processing arts to most effectively convey the substance of their work to others of ordinary skill in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of acts leading to a desired result. The acts are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic non-transitory signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these non-transitory signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[00145] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate non-transitory physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, can refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, non-transitory transmission, or display devices.

[00146] An apparatus for performing the operations herein can implement the present invention. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer, selectively activated or reconfigured by a computer program stored in the computer, however it is not software alone. Such a computer program may be stored in a non-transitory computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, hard disks, optical disks, compact disk- read only memories (CD-ROMs), and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), electrically programmable read-only memories (EPROM)s, electrically erasable programmable read-only memories (EEPROMs), FLASH memories, magnetic or optical cards, etc., or any type of non-transitory media suitable for storing electronic instructions either local to the computer or remote to the computer.

[00147] The techniques presented herein are specifically related to a particular computer or other apparatus. A specialized apparatus to perform the required methods is required. For example, any of the methods according to the present invention can be implemented in hardwired circuitry specifically designed for the functionality disclosed, or by programming special hardware having, for example, in one embodiment, a particular machine such as a computer (or CPU) specifically designed with a 16 bit or greater barrel shift register and a carry look ahead arithmetic logic unit. As disclosed Applicant submits that any results are tied to a particular machine or apparatus and/or transform a particular article into a different non-transitory state or thing and that such particulars and/or things are non- trivial. For example, in Figure 2 at 220 is a display. The results of the specialized machine may return an electronic value and such a value can be stored in hardware on the specialized machine and transformed into a graphical representation that can be displayed to a user of the computer. For example, in one embodiment, the returned value may be stored as a group of physical electrons on a trapped gate of a flash memory device. These physical electrons may then be transformed into a graphical

representation, for example, by twisting the molecules of a liquid crystal display so that a carrier signal can be modulated and produces on reception a molecular change in a rod and cone receptor of a human user to produce physical electrons thus producing a tangible useful result and transformation tied to a particular machine such as a computer specifically designed with a 16 bit or greater barrel shift register and a carry look ahead arithmetic logic unit. For example the specialized hardware is required for logical operations and comparisons of values. For example, in one embodiment, the returned value may be stored as a series of holes on a paper tape that may be read by a person (e.g. a blind person) by tactile sensation (e.g. output from a KSR-33 Teletype). As disclosed Applicant submits that these results are tied to a particular machine or apparatus and/or transform a particular article into a different state or thing and that such particulars and/or things are non-trivial and as such satisfy Bilski.

[00148] The methods of the invention may be implemented using computer software on the specialized hardware as noted supra. The methods of the invention cannot be implemented in software per se. If written in a programming language conforming to a recognized standard, sequences of instructions designed to implement the methods on specialized hardware can be compiled for execution on the specialized hardware. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention on specialized hardware as described herein. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, application, driver,...), as taking an action or causing a result. Such expressions are merely a shorthand way of saying that execution of the software by specialized hardware causes, for example, a processor of a computer to perform an action and produce a tangible concrete non-transitor result.

[00149] It is to be understood that various terms and techniques are used by those

knowledgeable in the art to describe communications, protocols, applications, implementations, mechanisms, etc. One such technique is the description of an implementation of a technique in terms of an algorithm or mathematical expression. That is, while the technique may be, for example, implemented as executing code on a specialized computer, the expression of that technique may be more aptly and succinctly conveyed and communicated as a formula, algorithm, or mathematical expression. Thus, one of ordinary skill in the art would recognize a block denoting A+B=C as an additive function whose implementation in hardware (and possibly using software) would take two inputs (A and B) and produce a summation output (C). Thus, the use of formula, algorithm, or mathematical expression as descriptions is to be understood as having a physical embodiment in at least hardware (such as a specialized computer system in which the techniques of the present invention may be practiced as well as implemented as an embodiment).

[00150] A machine-readable medium is understood to include any non-transitory mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a non-transitory machine-readable medium includes read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; and devices having non-transitory storage.

[00151] As used in this description, "substantially" or "substantially equal" or similar phrases are used to indicate that the items are very close or similar. Since two physical entities can never be exactly equal, a phrase such as ""substantially equal" is used to indicate that they are for all practical purposes equal.

[00152] As used in this description, "one embodiment" or "an embodiment" or similar phrases means that the feature(s) being described are included in at least one embodiment of the invention. References to "one embodiment" in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually exclusive. Nor does "one embodiment" imply that there is but a single embodiment of the invention. For example, a feature, structure, act, etc. described in "one embodiment" may also be included in other embodiments. Thus, the invention may include a variety of combinations and/or integrations of the embodiments described herein.

[00153] It is to be understood that in any one or more embodiments of the invention where alternative approaches or techniques are discussed that any and all such combinations as may be possible are hereby disclosed. For example, if there are five techniques discussed that are all possible, then denoting each technique as follows: A, B, C, D, E, each technique may be either present or not present with every other technique, thus yielding 2^Λ5 or 32 combinations, in binary order ranging from not A and not B and not C and not D and not E to A and B and C and D and E. Applicant(s) hereby claims all such possible combinations. Applicant(s) hereby submit that the foregoing combinations comply with applicable EP (European Patent) standards. No preference is given any combination.

[00154] Applicant has availed himself of the legal right to be his own lexicographer and such terms as, but not limited to, Device, SH, MP. MR, CT, Relay Server, etc. have specific meanings as denoted and/or explained.

[00155] Thus while particular embodiments and applications of the present invention have been illustrated and described, it is to be understood that the invention is not limited to the precise construction and components disclosed herein. Various modifications, changes and variations which will be apparent to one of skill in the art may be made in the arrangement, operation and details of the method and apparatus of the present invention disclosed herein without departing from the spirit and scope of the invention as defined in the claims.

Claims

CLAIMS What is claimed is:

1. A method for controlling one or more Devices, the method comprising:

receiving from at least one of said one or more Devices a user input, said user input being transformed by a controller in said at least one Device into a user command message;

receiving said user command message on a Master Server, said Master Server having connectivity to a Internet;

transforming said received user command message into a series of one or more specialized messages for at least one of a MP, a SH, a MR, and a CT; and

pushing said series of one or more specialized messages to at least one of a MP, a SH, a MR, and a CT having connectivity to said Master Server.

2. The method of claim 1 wherein said one or more Devices have at least one of a MP, a SH, a MR, and a CT.

3. The method of claim 1 wherein said one or more Devices have at least one SH.

4. An apparatus comprising:

a first device, said first device having a MP and a SH, wherein said first device MP is operatively coupled to said first device SH;

a second device, said second device having a SH and a MR; wherein said second device SH is operatively coupled to said second device MR; and

wherein said first device SH is operatively coupled to said second device SH.

5. The apparatus of claim 4 wherein said first device further comprises one or more entities selected from the group consisting of a CT and a MR.

6. The apparatus of claim 4 wherein said second device further comprises one or more entities selected from the group consisting of a MP and a CT.

7. The apparatus of claim 4 wherein said wherein said first device SH is operatively coupled to said second device SH further comprises said first device SH operatively coupled to a SH in a Relay Server and said Relay Server SH operatively coupled to said second device SH.

8. The apparatus of claim 4 wherein said wherein said first device SH is operatively coupled to said second device SH further comprises said first device SH operatively coupled through a first NAT Router and/or Firewall to a SH in a Relay Server and said Relay Server SH operatively coupled through a second NAT Router and/or Firewall to said second device SH.

9. An apparatus comprising:

a first device, said first device having a MP and a SH, wherein said first device MP is operatively coupled to said first device SH;

a second device, said second device having a MR;

wherein said first device SH is operatively coupled to said second device MR.

10. The apparatus of claim 9 wherein said wherein said first device SH is operatively coupled to said second device MR further comprises said first device SH operatively coupled to a SH in a Relay Server and said Relay Server SH operatively coupled to said second device MR.

11. An apparatus comprising:

a Relay Server having at least a SH;

a first Device having at least a SH, wherein said first Device SH is operatively coupled to said Relay Server SH;

a second Device having a least a MR; and

wherein said second Device MR is operatively coupled to said first Device SH.

12. The apparatus of claim 1 1 further comprising:

a third Device having at least a SH and a MP, wherein said third Device MP is operatively coupled to said third Device SH; and

wherein said third Device SH is operatively coupled to said Relay Server SH.

13. The apparatus of claim 1 1 further comprising:

a fourth Device having at least a SH and a MR, wherein said fourth Device MR is operatively coupled to said fourth Device SH; and

wherein said first Device SH is operatively coupled to said fourth Device SH.

14. The apparatus of claim 13 wherein said wherein said first Device SH is operatively coupled to said Relay Server SH further comprises said Relay Server SH operatively coupled through a first NAT Router and/or Firewall to said first Device SH.

15. The apparatus of claim 13 wherein said wherein said third Device SH is operatively coupled to said Relay Server SH. further comprises said third Device SH operatively coupled through a second NAT Router and/or Firewall to said Relay Server SH.

16. The apparatus of claim 13 wherein said wherein said first Device SH is operatively coupled to said Relay Server SH further comprises said Relay Server SH operatively coupled through a first NAT Router and/or Firewall to said first Device SH; and wherein said wherein said third Device SH is operatively coupled to said Relay Server SH. further comprises said third Device SH operatively coupled through a second NAT Router and/or Firewall to said Relay Server SH.

17. The apparatus of claim 16 wherein said first Device has one or more entities selected from the group consisting of a MP, a CT, and a MR.

18. The apparatus of claim 17 wherein said fourth Device has one or more entities selected from the group consisting of a MP, and a CT.

19. The apparatus of claim 1 8 wherein said third Device has one or more entities selected from the group consisting of a MR, and a CT.

20. The apparatus of claim 1 1 wherein said second Device and said fourth Device said operatively coupled to said first Device SH are at different bitrates.