Language selection

Search

Patent 2434698 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent: (11) CA 2434698
(54) English Title: MULTICASTING METHOD AND APPARATUS
(54) French Title: PROCEDE ET APPAREIL DE MULTI-DIFFUSION
Status: Expired
Bibliographic Data
(51) International Patent Classification (IPC):
  • H04L 12/16 (2006.01)
  • H04L 12/26 (2006.01)
  • H04L 12/70 (2013.01)
(72) Inventors :
  • MONTEIRO, ANTONIO M. (United States of America)
  • BUTTERWORTH, JAMES F. (United States of America)
(73) Owners :
  • TWO-WAY MEDIA LTD. (United States of America)
(71) Applicants :
  • TWO-WAY MEDIA LLC (United States of America)
(74) Agent: OSLER, HOSKIN & HARCOURT LLP
(74) Associate agent:
(45) Issued: 2006-11-07
(22) Filed Date: 1997-05-08
(41) Open to Public Inspection: 1997-11-13
Examination requested: 2003-07-21
Availability of licence: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data:
Application No. Country/Territory Date
08/644,072 United States of America 1996-05-09

Abstracts

English Abstract

A scalable architecture is disclosed for delivery of real-time information over a communications network. Embedded into the architecture is a control mechanism (10) that provides for the management and administration (60) of users (40) who are to receive the real-time information. A user (40) chooses to tune in or tune out a particular channel, but does not choose the time at which the channel distributes its information. Advantageously, interactive (two-way) information can be incorporated into the system, multiple streams of information can be integrated for delivery to a user (40), and certain portions of the information being delivered can be tailored to the individual user (40).


French Abstract

L'invention se rapporte à une architecture à géométrie variable destinée à acheminer des informations en temps réel sur un réseau de communications. Un mécanisme de commande (10), intégré à l'architecture, assure la gestion et l'administration (60) des utilisateurs (40) devant recevoir les informations en temps réel. Un utilisateur (40) choisit d'activer ou de désactiver un canal donné, mais ne choisit pas le moment où le canal distribue ses informations. De manière avantageuse, des informations (bidirectionnelles) interactives peuvent être intégrées au système, plusieurs suites d'informations peuvent être intégrées pour être envoyées à un utilisateur (40), et certaines parties de ces informations en cours d'acheminement peuvent être adaptées à chaque utilisateur (40).

Claims

Note: Claims are shown in the official language in which they were submitted.



What is claimed is:

1. A method for monitoring the forwarding of
real-time information to at least one user having access to
a communications network comprising:
generating delivery-commencement indications of
real-time information forwarded to the user by means of the
communications network, wherein the real-time information
comprises a plurality of packets forwarded over the
communications network to the user,
verifying the operational status of the user's
access to the communications network during delivery of the
real-time information, and
generating delivery-termination indications of the
real-time information forwarded to the user.

2. The method of claim 1 wherein the verifying
step indicates abnormal termination of the user's access to
the communications network, and wherein the generated
delivery-termination indications then also comprise
indications of the abnormal termination.

3. The method of claim 1 further comprising
updating a database with information provided by the
delivery-commencement and the delivery-termination
indications.

4. The method of claim 1 wherein the delivery-
commencement indications and delivery-termination
indications further comprise time information.

5. The method of claim 1 wherein the operational
status comprises an active/working status.

-33-


6. The method of claim 1 wherein the step of
verifying further comprises forwarding over the
communications network messages concerning the operational
status of the user's access to the communications network.

7. The method of claim 6 wherein the messages
concerning the operational status of the user's access to
the communications network are initiated by the user.

8. The method of claim 6 wherein the messages
concerning the operational status of the user's access to
the communications network are received by the user and
responded to by the user.

9. The method of claim 6 wherein the
communications network further comprises at least one server
computer, and wherein the messages concerning the
operational status of the user access to the communications
network are initiated by the server computer.

10. The method of claim 1 wherein the indications
of delivery-commencement and of delivery-termination are
stored on the server computer.

11. The method of claim 1 wherein the delivery-
commencement indications and the delivery-termination
indications are stored at the user.

12. The method of claim 11 wherein the delivery-
commencement indications and the delivery-termination
indications that are stored at the user are later forwarded
over the communications network to the server computer.

-34-



13. The method of claim 1 further comprising a
step of determining the total delivery time of the real-time
information to the user from the delivery-commencement and
the delivery-termination indications.

14. The method of claim 13 further comprising a
step of determining the content of the real-time information
delivered during the total delivery time.

15. The method of claim 13 wherein the total
delivery time is determined as the total elapsed time
between delivery-commencement and delivery-termination
indications during which the user's access to the
communications network was also verified to be in an
active/working operational status.

16. The method of claim 1 wherein the real-time
information comprises audio information, or video
information, or advertising information.

17. The method of claim 1 further comprising
generating indications of the content of the real-time
information.

18. The method of claim 1 wherein an identifier
is provided for the user.

19. The method of claim 18 wherein commencement
and termination indications are associated with the
identifier.

-35-



20. The method of claim 1 wherein the
communications network includes the Internet.

21. The method of claim 1 wherein the
communications network includes a satellite network.

22. The method of claim 1 wherein the
communications network includes a cable TV network.

23. The method of claim 1 wherein the
communications network includes a private data network.

24. A method for monitoring the forwarding of
real-time information to at least one user having access to
a communications network comprising:
generating delivery-commencement indications of
real-time information to the user, wherein the real-time
information comprises a plurality of packets comprising
audio information, or video information and is forwarded
over the communications network to the user, and wherein the
delivery-commencement indications further comprise time
information,
verifying the operational status of the user's
access to the communications network during delivery of the
real-time information, wherein the operational status
includes abnormal termination,
generating delivery-termination indications of the
real-time information to the user, wherein the delivery-
termination indications further comprise time information
and indications of any abnormal termination, and
updating a database with information provided by
the delivery-commencement and the delivery-termination
indications.

-36-



25. The method of claim 24 wherein the step of
verifying further comprises forwarding over the
communications network messages concerning the operational
status of the user's access to the communications network.

26. The method of claim 24 further comprising a
step of determining the total delivery time of the real-time
information to the user from the delivery-commencement and
the delivery-termination indications.

27. The method of claim 26 wherein the total
delivery time is determined as the total elapsed time
between delivery-commencement and delivery-termination
indications during which the user's access to the
communications network was also verified to be in an
active/working operational status.

28. The method of claim 24 further comprising
generating indications of the content of the real-time
information, and wherein the database is updated with
information provided by the content indications.

29. A method for forwarding real-time information
to one or more users having access to a communications
network comprising:
processing one or more streams of audio or visual
information into one or more streams of packets for
forwarding over the communications network, wherein at least
one stream of packets comprises audio or video information,
forwarding the digital packets to the users in
response to information selection signals received from the
users,

-37-



verifying the operational status of the users
access to the communications network during delivery of the
real-time information, and
updating a database with indications of:
(i) which streams of packets were
received by which users,
(ii) the time when delivery of each
stream to each user commenced, and
(iii) the time when delivery of each
stream to each user terminated.

30. The method of claim 29 wherein the
operational status includes abnormal termination, and
wherein the termination time of each data stream further
comprises indications of any abnormal termination.

31. The method of claim 29 wherein the step of
verifying further comprises forwarding over the
communications network to the users messages querying the
operational status of the users access to the
communications network.

32. The method of claim 29 wherein the messages
concerning the operational status of the users' access to
the communications network are initiated by the users.

33. The method of claim 32 wherein the messages
concerning the operational status of the users' access to
the communications network are received by the user and
responded to by the user.

-38-



34. A method for a user having access to a
communications network to obtain real-time information
comprising:
forwarding selection signals over the
communications network from the user indicating the real-
time information desired,
receiving one or more streams of packets forwarded
to the user over the communications network in response to
the selection signals, wherein at least one stream of
packets comprises audio or video information, and
verifying the operational status of the
communications network access during delivery of the real-
time information.

35. The method of claim 34 wherein an identifier
is provided by the user.

36. The method of claim 34 wherein the step of
verifying further comprises responding to messages forwarded
to the user concerning the operational status of the user's
access to the communications network.

37. The method of claim 34 further comprising the
step of forwarding termination signals from the user
indicating that termination of the streams of packets is
requested.

38. The method of claim 37 wherein the
termination signals from the user are voluntary.

39. The method of claim 37 wherein the
termination signals from the user are involuntary.

-39-



40. A system for a user to obtain real-time
information over a communications network comprising a
programmable device,
wherein the programmable device has access to the
communications network, and
wherein the programmable device includes user
software for causing the programmable device to
forward selection signals from the
programmable device indicating the real-time
information desired,
receive one or more streams of packets
forwarded to the programmable device in response to the
selection signals, wherein at least one stream of
packets comprises audio or video information, and
verify the operational status of the
programmable device during delivery of the real-time
information.

41. The system of claim 40 wherein the
programmable device comprises a personal computer, or a
personal digital assistant, or a telephone, or a mobile
phone, or a terminal device, or a television set-top box, or
a game console.

42. The system of claim 40 wherein the user
software further causes the programmable device to initiate
and forward over the communications network messages
concerning the programmable device's operational status.

43. The system of claim 40 wherein the user
software further causes the programmable device to respond
to messages forwarded to the programmable device concerning
the programmable device's operational status.

-40-



44. The system of claim 40 wherein the user
software forwards over the communication network a unique
identifier.

45. The system of claim 44 wherein the identifier
is provided by the programmable device.

46. The system of claim 44 wherein the identifier
is provided by the user software.

47. The system of claim 40 wherein the user
software comprises an Internet browser.

48. The system of claim 40 wherein the user
software further causes the programmable device to display a
channel guide, a program guide, or a multimedia frame.

49. The system of claim 40 wherein the
programmable device's operational status comprises its
access to the communication network.

50. A software product comprising user software
on a computer readable medium for causing a programmable
device having access to a communications network to forward
selection signals from a user indicating real-time
information desired,
receive one or more streams of packets forwarded
to the user in response to the selection signals, wherein at
least one stream of packets comprises audio or video
information, and
verify the operational status of the programmable
device during delivery of the real-time information.

-41-





51. The product of claim 50 wherein the user
software further causes the programmable device to respond
to messages forwarded to the programmable device concerning
the programmable device's operational status.

52. The product of claim 50 wherein the user
software further causes the programmable device to initiate
and forward over the communications network messages
concerning the programmable device's operational status.

53. The product of claim 50 wherein the user
software forwards over the communication network a unique
identifier.

54. The product of claim 50 wherein the user
software comprises an Internet browser.

55. The product of claim 50 wherein the user
further causes the programmable device to display a channel
guide, a program guide, or a multimedia frame.

56. The product of claim 50 wherein the user
software is provided in a form that is downloadable over the
communications network.


-42-

Description

Note: Descriptions are shown in the official language in which they were submitted.



CA 02434698 2003-07-21
MULTICASTTNG METHOD AND APPARA~S
i~ Field of the =avention
...This relates to a method and apparatus for.provid'ing'
audio and/or visual c~mmunication servi~;es, ..in real--time to a
multiplicity of identifiable ~ users'~on a communications '
network, such as the Internet. In a preferred embodiment,
the.inventi.on monitors which users.are receiving signals on
which one of . a plurality of channels- arr~ modifies the :content
.of a~~ least . some .signals ~in response th~:reto~. ~3 particular .
application ,is to provide services akinvto multi~channel
radio or television with commercial, programming content
adjusted in accordance~with the identity of the individual
user.
I5
3. Background of the Invention
Systems such as the ~Int.ernet typically are point-
to-point (or unicast, .systems in which -a message, is~ converted
into a series ~f addressed packets that are routed .from a
. 3p. source .node through a plurality, of roisters ~ to a~ destination
node. In most communication protocols the packet~.includes a'
header that containa'the addresses of the source and the
destination nodes as well as a sequence number that
specifies the packetls order in the message:. ..
25 In.general, these systems do not have td~e
capability of broadcasting a message from a'source node,.to
all the other nodes in the ~ettaork because such a capability
is rarely of much~use and could easily overload the network.
However, there are situations where it is desirable for, one
30 node to communicate with some subset of all~the nodes. For
example, mufti-party conferencing capability, analogous to
that found iw the public telephone system and broadcasting to
a.limited number of nodes, is of considerable interest to
users of packet-switched networks. To satisfy such demands,
35 packets destined for several recipients have been .
encapswlated in a unicast packet and forwarded from a source.
to a point in a network where the~packets have been


CA 02434698 2003-07-21
replicated and~~forwarded on to all desired recipients. This
technique is known as IP Multicasting a~xl the network over
which such packets are routed. is referred to as the Multicast
Backbone or MBONE.-. More recently, routers~.have become
5:avai.lable that can route the.mu3ticast addresses (clas~ D
addresses),provided for.in communication protocols such a~
TCP/IP and UDP/~P. A multicast address is essentially an
address for a group of host computers who have indicated',
~~ their desire to participate in that~group. Thus, a multicast
i0 packet can be r~ut~d from a source, node through a plurality
of multicast roisters for mrouters) °to one or more devices
receiving thc~ multicast packets. From there the packet is
distributed to.all the~host computers that are members of the
multicast group~.
i5 ~ These techn~.ques ha'~re been used to provide on the
Internet~audio and video conferencing as well as radio-like
broadcasting to groups of interested parties. See, for
example, K. Savets,et al~ MF30NE Multicastina Tomorro~,!s
Interns (IDG Books Worldwide xno:, 199fs). .
20 Further details concerning technical aspects of
multicasting may be found in the. Internet. documents Request
for Comments (RFaC) 1112 and 1458, which are reproduced at
Appendices A and ~ ~f the Savetz bo~k and in D.P~ Brutaman et
s,x., "MBONE provides Audio axrd Video Across the Internet,"
25 IEEE Comuuter, Vol. 27, No. 4, pp. 3°-36 (April 1~~4),
Citation of the foregoing documents is.not to~be
construed as an admission that any of such documents is a
prior art publication relati~re to the present invention.
sa
~ ~ s , a~ the x~~reat~omm
The present invention is-a scalable architecture
for delivery of real-time , information. over a communications
network. ~nbedded into the architecture is a control
35 mechanism that provides for the management and administration
of users who are to receive the real=time information.
o ~ P


CA 02434698 2003-07-21
~, In the preferred embodiment, the infor$iation being
delivered~is high-quality audio. However, it could.also be
video, graphics, text or any other_type of infor~atiori that
can be transmitted over.a digital netwoyk. ,'his information
is delivered in real-time to any number of widely:distributed
users. ~It is real-time.in.that for a given channel of
information, approximately the same information is being sent
at appraximately the same tide to everyone who is:enabled to
receive. the information.
to : . Preferably, there are multiple charui~3s' of .
informatio~a available simultaneously to be delivered. to
users, each channel consisting of an independent.stream o~f
information. A user ~ chooses to tune in or ~ tune out a
particular channel, but does not choose the time~at which the
~5 channel distributes its infoz~ination..Advaritageously,
interactive (two--way) information can, be incorporated into
the system, multiple streams of information can be integrated
for delivery to a user, and certain portions'..of~t~e'
infozmation being delivered can. be tailored to the 3.ndividual
2o user.
Brief Descripti~a of the DrarrfaQ .
These and other objects, features and.advantages of
our invention will be more readily apparent frosi the
x5 following Detailed Description of a F~c°efex°red Embodiment
of
our invention in which: .
Fig. 1 is a schematic diagram depicting ~ari overview
of the system of the present invention;
Fig. 2 is a schematic diagram~depicting the network
30 control center for the system of_.Fig. 1~:
Fig. 3 is a sohematic~diagtam depicting a unicast
distribution structure;
Fig. 4 is a schematic diagram depicting a multicast
distribution structure;
35 Fig. 5~is a schematic diagram depicting the
connection. between the media server and the user in the
system of Fig. 1;
- 3 -


CA 02434698 2003-07-21
Figs. 6-1?.are timing diagrams that depict various
aspects of the operation of the system of Fig. 1; and
Figs. 18 and 19 depict the user interface,for
control of the system of. Fig. i: .
Where the sa~ie reference numerals appear ~ in
multiple drawings, the numerals refer t~ the same or
corresponding structure in such drawings.
5. Detailed Description of- the preferred Embod3.ment
Referring to Fig. 1, the syste~a of the present
invention comprises a Network Control Center 10, a plurality
of Primary Servers 20, Media Servers 30, Users 40 and Control
Servers 50 and an administration Server 60. The servers are
interconnected by a~coadmunications network, which in..the
15 preferred embodiment is the global connected internetwork
- known as.the Internet. The NetworkwControl Center 10 is the
source of the information being distributed. It receives
audio feeds from satellite, over the air broadcast or in
other ways and processes this information for delivery over
~o the network on multiple channels of info~.~nation.. This
processing consists of optionally recording the information
for future broadcast and dynamically inserting paid
commercial advertisements.
Far each channel of information, there is a~Primary
35 Server 20 hat receives the .streax4 of inforaaation from the
Network Control Center to and compresses the information
Stx'eam t~ allow for more efficient tranSmlsslon. 'fhe Prlm8ry
Servers 20 are directly connected. to the network.
The Primary Servers forward information via the
30 network to a number of Media Servers 30. There may be a
large number of Media Servers~vand in fact there may be many
levels of Media Servers. For examgle, a Media Server that
receives a stream of information from a primary Server may
forward that stream via the network to another Media Server
35 that then forwards it to a User 4n: This multilevel
hierarchical structure is described~:~in more detail below.
- 4 -


CA 02434698 2003-07-21
The topology of the Internet dictates the ideal
placement of Media Servers, the fan-out of each. Media Server
and. the number of ~ levels of Media. Servers between the Pricaary
-vServer and Users. For example, the Media Servers that~feed
from a Primary Server might be placed at major'goints of
presence (POPS) of each of the large Internet service.
providers.. These Media Servers might also be placed, near
clouds that serve as high bandwidth~exchange points between
the major.carriers. Similarly, Media Servers that~~feed to
1~ Users might be placed~on or close to networks.that have a
large'number of subscribers to minimize the distance and
number of data streams being transmitted.
Control. Servers 50 are responsible for ~Ceeping.
. track of which users are listening. ,to Which charnels and for
~5 directing the Med~awServers to start and stop st.reaias of
information to those Users. The Controh~Sezvers are also
responsible for handling other interactions among the various
components of the system.as will be described in more~detail
belo~r. Each Control Server is responsible for. managing a
2A clustes'of Media Servers; and each.Media Server is~managed by
a single Control Server, at any given time: As a result, the
Control Servers are distributed throughout the Internet,
preferably located close to the Media Servers.
The Administration server 60 is responsible for
25 registering neW users:, authenticating users who want to log.
onto the system, and maintaining audit logs for how many
Users'are li,stening~to which channels and at which ;times.
Maintaining audit logs and,, gathering statistics-are features
critical to monitoring the delivery of paid commercial
30 messages as well as for other purposes. 'For example, .for
purposes of assessing copyright r~yalties, the audit logs.cari
record the number of listeners for each musical o~c video
selection.that is distributed by the system. Another
application is to determine the percentage of listeners who
35 are interested in listening to a particular musical selection.
by determining how many listen~to the entire selection at~d
hOW many turn it Off~
s 5. w


CA 02434698 2003-07-21 .
The system of the present invention can Jbe. .
considered a distribution architecture integrated with a
control architecture. The distribution architecture handles
scalable real-time delivery of information.to any number of
Users on a.packet switched networks such as the Internet.
The control architecture represent~,a~second scalable system
integrated with the distribution architecture for.ananaiging
and administering the delivexy of that information.
.The remainder.of this description is divided into
Ip three~sect~ions. In the pert sectiors~the distribution
architecture will be described in ~aore'detail. ~ ~~llowing
that, the control architecture will be.described. In the
third section the user interface will be illustrated.
t5 I. Distribution i~rchit~cture
The distribution, architecture provides~for'the
delivery of real-time infor~datiori to any number of Users
distributed throughout a network. ~,s will be described in
20 detail below, the distribution architecture~is scalable t~
allow for efficient delivery of multiple simultaneous
information~channels in real-time to a urge number of Users.
In the preferred embodiment, the information that
is being distributed consists of high-quality audio in~
i5 addition to other information'. It should be appreciated that
' the basic architedture and other general principles set forth
herein would~also apply to the delivery of video, graphics,
text or any other'type of informatiorA that can be delivered
over a digital network. In addition; it should be
3~ appreciated that an information, stream carp consist of audio
with supplemental information such as text and graphic images
and commands to control software running on the User~s
c~mputer a ~ _ , .
The source of inforanation in the preferred
35 embodiment is the Network Control. Center 10, depicted in'the
schematic diagram of Fig. 2. Control c:entsss of this type of
design,are available from Braadcast Electronics, Inc, and are
- 6 -


CA 02434698 2003-07-21
similar to what would be found in a conventional radio
station serving multiple frequencies.
Referring to Fig. 2, the incoming signal can be
received in a variety of ways such as from a satellite, over-
the-air broadcast, cable or hard disk. It is then processed
by Receiver/Decoder 210, which decodes the signal and
provides an incoming audio stream. Routing Switcher 120 is
respansible for routing the incoming audio feed from the
Receiver to either Delay Recording Workstation 340 or to one
of the Playback/Control Workstations 130. Real-time
insertion of paid commercial advertising takes place at the
Playback/Control Workstations and the resulting integrated
audio stream is delivered to the Primary Servers. The Delay
Recording Workstation is responsible fox recording an
i5 incoming broadcast so that it can be played back at a later
time.
Supervisory Workstation 154 is responsible for
managing and controlling the Playback/Control Workstations,
Delay Recording Workstations and other computers as may be
connected to the local area network within the Network
Control Center. Production Workstation 160 and AudioVAULT-
NFS Server 170 are used to manipulate audio samples, such as
commercial messages for use by the Playback/Contral
Workstations. The audio being delivered can consist of
syndicated TV or radio programsf such as would be received
over satellite or cable and delivered as described above.
These can be delivered live and/or played bank at a later
time. Tt is also possible for the delivery of information,
such as music, to take place from information that is all
stored locally such as on a hard disko A new play list and
its associated music data can then be downloaded periodically
to update the channel. Additionally, it is possible to
deliver commercial-free programming, for example public
service announcements or label-specific music"
In the preferred embodiment the Primary Servers are
responsible for compressing the audio stream using an
advanced perceptual technique developed and licensed by AT&T
7 _


CA 02434698 2003-07-21
Corp. and Lucent Technologies, Inc. This highly
sophisticated algorithm is used to maximise the benefit of
the bandwidth available. Advantageously, two bitrates are
available, a first rate of approximately 2oKbps and a second
rate of approximately 56Kbps. Using the perceptual
technique, the quality of the first rate is similar to FM
monaural (with a sampling rate of approximately 22,00~ 16-bit
samples per second) and the second rate is close to CD
quality stereo (with a sampling rate of approximately 32,000
16-bit samples in stereo each second). The signals at the
two different bitrates comprise two differen°t audio channels
and thus require two different compression p~roaesses.
The computational requirements of compressing an
audio stream in real time using techniques such as the
advanced perceptual technique are approximately 100% of a
Pentium-Pro 20oMhz computer and the computat~.onal
requirements of decompressing an audio strewn' in real time
are approximately 30% of a Pentium 75Mhz computer. Future
improvements and/or changes to the algox°ithm could
24 significantly change these requirements. For the present, a
dedicated computer is required within the Primary server to
compress the audio stream. The decompression process takes
place on end Users' computers and preferably would use only a
portion of the computers' computational requirements,
~5 allowing the computers to be used for other tasks while they
are processing the audio stream.
It is important to appreciate that 'the compression
and decompression techniques employed by the present
invention are not critical to the overall operation of the
30 system and the advantages obtained therefrom could be
obtained with other compression methodologies.
Advantageously, the identity of the compression technique
used can be encoded into the audio stream in the packet
header. This makes it possible to identify to the receiver
s5 the nature of the decompression algorithm to use~ and thereby
make it possible for the computer within the F~rimary Server
_ g ._


CA 02434698 2003-07-21
to select an optimum compression algorithm defending on the
nature of the audio stream to be compressed.
The remainder of the distribution architecture
comprises the multilevel hierarchy of data transmission
originating at the Primary Server 20 and terminat3.ng at the
Users 40 as shown',in Figure.3. In the preferred embodiment,
the network is the global connected Internet. 7Ct can also
include private networks that are~connected to the Internet
and it could be implemented on any packet switched.network,
1,0 cable=modem-based or satellite-based cable system~~ It is
possible that certain links within the overall system, for
example, the link between the Primary Server and the first
level of Med3.a Servers, are private data links that carry
~only.data associated with this.system. This could also be
true of other data transmission_paths in the distribution
architecture. . The User receiving ;the information preferably
can be anyone who has access to the Internet with~sufficient
bandwidth to receive the resulting audio data.
It should be appreciated that the distribution
2~ architecture of ahe present invei~tio~ provides for
scalability. Using such a structure~ any ~ number of tlse~~
and as widely distributed as necessary, can be accommodated.
In the preferred embodiment, the fan-out at each level.o~~.
Media Server cgiven~the state of technology today) is on the
order of ten,~but.the same structure could be applie8v.with
other fan-outs. The location and fan~out of the Media.
Servers is chosen to minimize overall iietwork~bandwidth
consumed.
The -flow of information fro~i Primary Server ~0
through network to User ~0 is based can the delivery of av
continuous sequence~of individual pieces of information, or
packets. Thus the distribution architecture implements a
form of multicast packet delivery to a group. The group in
this case is the set of all Users who are listening to a
given channel at a given time. Group membership is dynamic;
users can start and stop listening to a channel at any time.
~ g


CA 02434698 2003-07-21
Multicasting can be implemented in a variety of
ways, any or, all of which can be used~in the present
invention. Tn the preferred embodiment, .the Media Servers
receive unicast packet stieams and they then duplicate thess
streams into mope unicast streams to ~ther Media Servers
that are in the membership group for that stream. The
lowest level Media Servers use hardware broadcast, multicast
and/or unicast to reach all Users served by that~Media
Server.
gp If the Media Server is directly connected.t~ the
same physical network as the. User, hardware broadcast or
multicast can be used to transmit the packet.strea~a,to ali
Users listening at that time on that network. In this case
the Media Servers can translate the inco~aing packets into
t5 broadcast or multicast packets for transmission on the local
network:, Only a single packet is transmitted at-a=time.on
the local network..and any computer directly connected t~ the
local network can receive that packet. Hardware multicast'is
built into most networks and it is lower iw overall overhead
Z0 than hardware broadcast since.computers riot interested in a
transmission do not have to process the~packets. In the case
that a Media Server is serving a tTser who is not on the same
physical network,va unicast transmission is used to reach
that User, which requires a.separate packet transmission for
25 each User so connected. In. the preferred embpdiment, the.
assignment of Users to Media Servers is done using cbntrol
transactions among the User ~f; Control Servers 5~, and
Administration Server 60. This system will be described~more
fully in the following section.
3o Multicasting can also be implemented within t3ie~
Internet at the IP level,usxng~Il? class D addresses and the
7~GMP group control protocol. Fig. 4 illustrates how the
multilevel hierarchical distribution architecture would
operate using IP multicast delivery. Under this~system, a
35 packet is transmitted Wi_th~a multicast address for a
destination and each router,maintains group membership lists
for each interface that it is connected 'to and will forward
- 10 -


CA 02434698 2003-07-21
packets across the Internet to other routers such that all
Users within the global group eventually receive a copy of
the,packet. Unless and until all rnuters within the Internet
understand multicasting in this way, it is necessary to
supplement it with ~P,tunneling in which multicast packets
are encapsulated in unicast.packets and xouted by unicast
routers to multicast routers. The present invention can
and will be able to take advantage of IP multicasting as it
becomes widely available. Each chanaiiel of information would
io be given its own class D address and the Media Server would
then simply transmit packet-s.using the appropriate IP
destination address. In this case no Media Servers would-be
used as this function would be accoanplished by the routers in.'
use to stare and forward other IP packets.
Thus it can be appreciated that the implementation
. of the multicast delivery structure can be implemented using.
a~combination of IP unicast, IP multicast and hardware
multicast or any other system that provides for distributed
delivery of infor.°matio=a .to a specif;:c group of~ destinations.
It is expected that special relationships with Internet
. providers will be established so~that delivery of. the audio
steams can take place with~a~guaranteed.bandwidth and iw the
most efficient way possible.
In the preferred embodiment, packets c~f information
for distribution use the UDP protocol under IP rather. than
the TCP protocol. TCP provides for reliable stream delivery
but at the cost~of retransmission and delays. For real-time
information, it is usually more appropriate to use.ilDP since
the information is time critical and. low latency is more
important that reliability. Since TCP is a point-to-point
protocol, it is incompatible with IP multxcasting. However
TCP could be used on the IP unicast links between Media
Servers that are.expected to have very ~.ow packet loss.. In
order to handle out. of order;"lost, duplicate and corrupted
packets, the ilDP packets are serialized~'
w In the preferred embodiment the size of the~audio
packets.being transmitted is variable and can change on a
- 11 -


CA 02434698 2003-07-21
packet by packet'basis. It is expected 'that when using
compression schemes that have a fixed bit rate, .such as
ADPCM, all packets for that stream-would be the same size.
Alternatively when:using a variable.bit rate compressiow
algorithm, it ~.s expected that packet,si~e would wary so°as~
to establish approximately the same amount of time for each
sample.v. For example, ~.f each packet corresponds.to a 20
millisecond segment of speech, this could. correspond to.100
bites duriaig one time period and 200 .bytes during another.
to Additionally, the Media Server'may choose to dynamically vary
the packet size to accommodate~changes i~a network conditions.
Since the resulting playback of audio information
is sensitive to packet loss and network congestion, software
.running on the various computers that, make up this system
i5 monitors the ongoing situation and adapt to it in the best
possible way.: This may, involve using different Media Servers
and/or lowering the data rate to the User. For example,
similar to analog dynamic s3gnal'quality negotiation present
in many analog radio receivers,~the User.software may request
2o a lower bitrate until the~situation is improved...Also, note
that .the audio information being delivered to the User its
preferably . ,inter~.eaved , so that, a contiguous segment ~of the
audio stream is distributed for trarismiseion ov~.r.several ~.
packets. As.a result, the loss of one packet'is spread out
25 over multiple audio~swmples and causes minimal degradation in
audio.. Advantageously, a small degree of redundancy may be
incoz~porated~ within ~ the audio strew to i'urther guard against"
packet loss. .
Preferably, there are two citrate options available
3o to the User fog audio delivery:,.. These are approximately
2oKbps for standard audio and approximately 56Rbps~for high
quality audio. Thus, a 28.8Rbps modem connection over"an
analog phone line is sufficient to listen to standard audio .
broadcasts. To listen t~o high quality audio, an ISDN .
35 connection to the Internet is required, or some .other
connection with greater than 56Rbps bandwidth. It should be
appreciated that higher bandwidths are currently~becoming
w 12


CA 02434698 2005-06-17
available to end Users. In particular the use of cable
modems and residential fiber networks are enhancing the
bandwidths available to Users and thus making broadcasts of
higher bitrates more practical.
In addition to the content of the audio channel
being delivered, it is also possible to deliver out of band
of side-bar information such as graphics, images and text.
This side-bar information is synchronized with the audio
channel. This may only involve small increases in bandwidth
requirements, such as 1-2Kbps. For example a music program
could deliver images of an album cover, the text of song
lyrics, or URLs for use by a Web browser. The User can
preferably choose to have the side-bar information show up
automatically or be hidden. It is also possible to
incorporate two-way interactioninto the system, such that
for example Users can participate in a global chat session
during the audio broadcast. These and other details are
explained in more detail below under the description of the
User interface.
The delivery of paid commercial advertising
information is an important aspect of the present invention.
Advertising may be incorporated into the audio stream within
the Network Control Center as described above. It may also
be incorporated into the audio stream at the User level, or
at some intermediate point in the distribution architecture.
In addition, the side-bar information discussed
above can also include advertising content. Fig. 5
illustrates the provision to the User of two separate
streams 32, 34 of packets, one of which may be used for
advertising. In this case the insertion of the stream of
commercial advertising into the non-commercial stream occurs
on the User's computer. Fig. 5 also illustrates packet
stream 36, which identifies the User to the system. This
enables the system to monitor which Users are listening to
which channels and also allows the system to vary, for
example, the advertising content delivered to a User.
- 13 -


CA 02434698 2003-07-21
One advantage of this alternative is to allow
. targeted commercial delivery based on the individual User.
That is, an individual User would receive the main audio feed
plus a particular advertising stream unique too his
demographic group. Note that the advertising stream
typically is lower in overall bitrate and generally does not
require real-time delivery, thus lowering the overall load on
the network. For example, the advertising stream could be
delivered to the User in advance of the regular programming,
stored in a buffer in the User s computer and inserted into
the stream of regular programming upon receipt of a cueing
signal embedded in the stream of regular programming~ Thus,
a substantial number of targeted groups, perhaps 10 or 100 or
even more could be accommodated without an impractical
increase in network load.
II. Control Architecture
The control architecture described in this section
is responsible for managing and administering the Users who
are receiving the information being delivered by the
distribution architecture described in t:he previous section.
The control architecture handles new User registration, User
login, the starting and stopping of audio streams and the
monitoring of ongoing transmissions. The control
architecture is scalable just as is the distribution
architecture so that any number of Users can be managed.
This section describes the control. protocol, which
consists of the format and sequence of control messages that
are exchanged among Users, Control Servers, Media Servers,
3~ Primary Servers and the Administration server. These
messages are in the form of ~bjects, which have specifis data
formats. Objects are exchanged preferably using the TGP
protocol although other options are possible. Below we
describe the sequence of objects passed among the various
computers and detail the internal structure of each object.


CA 02434698 2003-07-21
The major objects used in the present embodiment ~f
. the invention are set forth in Table 1. For each object,
Table 1. provides a brief description of its tEunction,
identification of the names of the fields in the object,
their types and a brief description of irheir function.
Channel Activation Object
T1~,13 .~
Contains information used for charmed activatio~~zldeactivatian. It is sent
s o to li~edia and Primary Servers to tell them to carry or stop carrying a
specific channel. Media Servers get the channel from another server in
the system hierarchy and Primary Servers get and encode the feed from
the actual input source.
Field Name Field ~'ype itemar&s
ZS Token Security Token Object
Moniker Moniker Object unique channel identifier
activate lnt action flag (activateldeactivate)
CompressType Int type of compression to use
Host Host Object host carrying the channel
Channel Guide Object
Contains analytical and descriptive information for an item requested
that is uniquely identr; fled by a moniker. It is usually the reply to a
Channel Guide Request object.
Field Name lE~eld 'Type Remarks
Token Security Token Object
Type Int type of content
Result the content daea itself
Channel Guide Request Object
Conveys a request for analytical and descriptive information about an
s o item uniquely idenh~ed by the contained moniker. The reply is in the
form of a Channel Guide object.
Field Name held Type Remarks
Token Security Token Object inherited from base class
Type Int type of content
Monaker Moniker Object unique identifier
~ 1~ _


CA 02434698 2003-07-21
Table 1 (continued) -
Host Object
Encapsulates the attributes of a networked computer related to the
operation or services it offers or requests.
Field Name Meld Type Remar%s
Token Security Token ~bject
HostName String computer name and domain
PortNumber Int port number for service
DisplayNume String descriptive computer name
s o gin Information Object
E~«apsulates the name and password by which a fleet is known to the
sysyem.
Field Naare Field Type Rettaarks
Token Security Token ~bject
I ogin String User's system login name
Password String Use:r's system password (possibly
encrypted)
Medda Control Interface (MCI) Request Object
~ Encapsulates a multimedia control command, such as play and stop, and
any extra information that may be necessary to perform the requested
service.
Field Name Field Type Rennarks
Token Security 'Token ~bject
2 5 C~mmand Int multimedia command
String String cotr~mand-specific extra info
Moniker Object
A moniker encapsulates the name of an object or process with the
intelligence necessary to work with that rrtame. In other words, it
3 o pr~yides naming and' binding services. 1'he Moniker Object is used in
the system f~r unique identification of various components, parts or
-- features, such as a channel, a directory, or ~a computer list.
Field Name Field Type Remarks
Token Security Token ~bject
3 r ID String unique string identifier
DisplayName String User-readable name
_ 1~ _


CA 02434698 2003-07-21
T'a6le 1 (continued)
Ping Object
Ping is the name given to the "Are-You-Alive?" operation useful in
determining if a specific computer is up and running. This object is
5 used in the system when a server has to be queried for its operational
status. dt can also provide timing informatdon jbr statistical purposes
and quality of service evaluations,
Field Name Field Type Remarks
Token Security Token Object
Date Date system date
1 ~ fiime Time system time
Protocol List Object
encapsulates a general purpose collecdion object.
Field Name Field Type Remarks
Token Security Token Object
Type Int type of object list
Idesult Message Object
2 o Acts as the acknowledgment for a requested service successfully carried
that out or reports errors that occur in the system during a clientlserver
transaction.
Field Name Field Type Remarks
Token Security Token Object
2 5 bode lnt result code
Message String message corresponding to code
Security Token Object
Contains the authorization key for a transaction. The key must be
validated before any service is performed"
Field Name Field Type Ren'arks
ID String authorisation keyltransaction ID.
- 17 -


CA 02434698 2003-07-21
Table d (continued)
Server Activation Object
Contains information used in the server activationldeactivation process.
Used for announcement as well as command purposes (e.g., a server can
n~tt; fy the administration database that is now activated or a server can
be instructed to manage someone else).
Field Name Field Type Remarks
Token Security Token Object
Active Int action flag (activate/da:.activate)
Manage Int control flag (managelassociate)
Type Int server type
Host Host Object host to be controlled
,Server List ~tequest Object
Encapsulates a request for a list of available server resources for an
identt~ed service (e.g., a request for a list of Control Servers for a
specified channel).
Field Name Field Type Remarks
Token Security Token Object
Type Int type of service
Moniker Moniker Object contentlchannel unique identifier
Host Host Object local host information
Statistics Object
Contains system-related information that a:an be used by load
balancing algorithms and for statistical purposes.
2 5 Field Name Field Type Remarks
Token Security Token
Object


Load Int load on the system


Threads Int number of threads
running


Users Int number of iJsers
being


Uptime Int serviced


3 0 NumberManaged Int amount of time
running


NumberAssociated Int number of managed
servers


number of associated
servers


gfl _


CA 02434698 2003-07-21
Statistics Request Object
Encapsulates a request for system-related information that can be used
by load balancing algorithms and statistical purposes.
Field Name Field Type Remarks
Token Security Token
Object


Load Int request flag
(onlof~


Threads Int request flag
(onloff)


Users Int request flag
(on/off~


Uptime Int request flag
(on/of~


NumberManaged Int request flag
(on/off)


g ~ NumberAssociaeed Int request flag
(on/off~


User Object
Users and Servers use this object to register themsedves with the
administration database. They provide the information for subsequent
logins (name, password] and other system-related info. The end Users
~5 provide personal, demographic, and system-related information.
Field Name Field ~'ype Remarks
Token Security 'Token
Object


Login Login Information login information(name,
Object password)


FirstName String User's first name


LastName String User's last name


TFtle String User's job title


Company String User's employer


Addressl String User's home street
address


Address2 String User's address extra


City String city, village


State String state, province or
foreign country


ZipCode String zip or postal code


Age String User's age


2 5 Gender String User's gender


PhoneNumber String telephone number


FarNumber String fax number


En:.a; l String email address


Deanographlcs Dictionary market-targeting
extra User info


Sysremdnfo Dictionary system-related information


3~


CA 02434698 2003-07-21
Table ~ (continued)
Version Object
All components of the system use this object to report their versioning
information to the party they transact with in order to use a protocol
s they both understand. They are also given the chance to update
themselves if a newer version exists.
Field Name Fyetd Type Remarks
T~ken Security Token Object
Major Int major protocol version number
Minor Int minor protocol version number
1~ Type Int sender type
Client Version client version information
Unlike traditional protocols based on state
computers, the control protocol of the present invention is a
light-weight, stateless protocol comprising simple sequences
15 of objects. It is light-weight in that in most sequences
only two objects are involved ire the transaction and after a
sequence is completed the connectian can be reused. Tt is
also stateless in that the server maintains no information
about the client. Every transaction is I;xandled independently
20 of the previous ones. States exist in the lower levels, for
example within the TCP layer, to express logical states of a
network connection but they are not actually part of the
control protocol.
in the preferred embodiment, the software running
25 on the Control Servers, Media Servers and Primary Servers is
programmed for Windows NT and UNIX environment using the OLE
environment. In addition, COM interfaces are used between
components. The Rogue Wave system is used to transfer
objects between the applications running on the various
30 Computers. The software running on the User computer is
preferably programmed for a Windows 32-bit environment, so it
will run on a Windows 95 or Windows NT CC)mplitE:r.
Alternatively, Macintosh and UNIX environments can be
accommodated by other User software,
35 The basic process of a control transaction consists
of a version sequence followed by one or more protoco.~
~ 20 -


CA 02434698 2003-07-21
sequences. The version sequence starts after,the .computer ~~-
initiating the transaction, the client, has established a
connection with the computer completing the transaction, the
server. The client sends a Version Object (defined in Table
1) and in response the server then sends back its own Version
Object. This version sequence is used so that both client
and server are aware of the version numbers of the software
they are using. If a version number is older than expected,
either client or server can choose to conform to the previous
version or abort the transaction, depending on its needs and
capabilities. If a version number as newer than expected, in
most cases the current transaction can be completed since the
software systems are designed to be fully backward compatible
with previous versions. Additionally, in the case that the
server of the transaction is tree Administration Server, the
client receives information about what the latest version
number is and thus the client can be informed that a software
update is needed. The process of handling automatic updating
of User software is described more fully below.
After the version sequence, one or more protocol
sequences occur in which other objects are exchanged between
client and server. When a particular protocol sequence is
completed, another independent protocol sequence can be
serviced. The protocol sequences that are part of the
Z5 control architecture of the present invention are summarized
in Table 2 and described below in conjunction with Figures 6-
2~.
- 21 -


CA 02434698 2003-07-21
~°Al~~a~'
St~nary o~ Protocol 8e~a~enc~s
tro . eq~~ . : llettt Serveir atn O ~eCt~ : xC ang



User RegistrationUser Administration Version Object


and Login User Object


(see Fig. Channel Guide Object
6)


User Login User Administration Version Object


(sue Fig. L.agin Information Object
7)


Channel Guide Object


Channel PlayUser Administration Version Object


(see Figs Server List Object
8a, 8B,


8C)


Control Version Object


Server List Object


Media 'Version Object


MCI Objects -


OPB1VIPLAY/STOPICLOSB


Ping Objets


(TCP connection stays
open)



Token ValidationControl or Administration'Version Object
or
~


(see Figs. Media or Control Security 'Token Object
9A,


9B) Primary


Server Media or Administration Version Object


2 RegistrationControl I,7ser Object
5 and


~gm Server Acrivation Object


(see Fig.
10)


Server LoginMedia or Administration Version Object


(see Fig. Control L,ogin Object
11)


Server Activation Object



Conerol ServerAdministration Control 'Tension Object


Activation Server Activation Object


(see Fig.
If lz)
II


_ 2~ _


CA 02434698 2003-07-21
::.., . . .:..::..::::::::.,.,;:..:,..;; , ......, - ._.
tr . en~_...-::~:: ... . ...,...-::::.:::::... "...................
::.. . . :.....:,.
:.-..... .::: . , . .:.:::::.".
-.. : . w , , teFFt..............".,..:.: ::: :..
,:y ~...;..;,"... :... _..:.,.....::::.; . - ":
, ::::.:: :::::.. .:::::..:::.;;,.;':'~;::::::..... . aim : ...::::.:::"
,:::. on ..: ,:,.::.>::.:.::.~::.;.:';::;.....-....:..:.
O .: .. .:.:CI,- .-::::.:.::.:.::.,....._.......... , ~~~
. :... ,.::,,:::::. e.... ..,. . .. .
....: :,,:: ..5..:.:_:._...... .. ~~..... ~, . . .
":;; _.: ..." . . . , ... . ..... ...,.
.....:.n~ ,,\ ........., ..... . ,.... . .....
,..~;,~,: ~:: ::v:::,:: ..: ..:._::.. .........:,r; : .~..:.,::...
.":::: :: ........, ,,. " ".............. ,~:...... ..,..,.n
.. ..... ....,. ,..,........... ., ........ ..
- ~ ... >" ,
:...; " .. .. .....,: , .,.. .....:.
...... ........."..:.::...v; ;\..,.,::.:::.::.:.......,.,...........
..,: . .._. .....,:..n,",


Media ServerControl Media 'Version Object


Activation Server Activation Object


(see Fig. Ping Objects
13)


(TCP connection stays
open)



Control ChannelAdministration Control Version Objet


Activation Channel Activation Object


(see Fig.
14)


M~ia ChannelControl Media (open TCP connection)


Activation Channel Activation Objects


(see Fig.
15)


DistributionMedia Media or Version Object


Activation Primary MCI Objects


(~ Fig. 16) OPEN/PLAY/STOP/CLOSE


Ping Objects


(TCP connection stays
open}


Statistics Administration Control Version Object
Request or


(sea Fig. Media Statistics Object
17}



The User registration and login sequences are the
processes by which a new User registers with the system, logs
in and retrieves programming information~ The channel play
sequence takes place when a User asks to listen to a
particular channel. The token validation sequence is used to
verify that a computer requesting a service is authorized to
do so. The Server registration, login and activation
sequences are used by Control and Media Servers when they
become active. The Control Server and IH(edia Server
activation sequences are used to manage the Control and Media
Servers. The control channel, media channel and distribution
activation sequences are used to cause a channel to be
distributed to a Media Server. Finally, the statistics
request is used for administrative purposes.
- 23 -


CA 02434698 2003-07-21
Fig. ~ illustrates the User registration and logii,
sequence in more detail. This seguence,takes place after the
User has installed the User software on his/her computer.. It
is expected.that the User will,download the software from the
Internet and then invoke it, which in the preferred embodiment
will use the Windows Wizard interface: This will guide the.
User through the installation process including filling out
the registration form, which we wil3 describe more fully in
the next section. After the User has selected a name and
~.0 password and selected the option.to register, the User ~. .
computer opens a TC1? c~nnection to the A~tministration Server.
Advantageously, the full domain name of-°the Administration
Server is. embedded into the User software, although it could
be discovered in other ways.' The User ahd Administration .
l5 Server then exchange version objectss with the Administration .
Server as described above. If tree version numbers vieet
expectations, the User sends a Ueer Object to the
Administration Server., The format of.the User Object is
shown 'in Table 3. Once the'Administration Server receives
~0 the User object, it verifies that..the information is filled
in properly and that the selectedUser. naive , is unique:: ~ If
the User Object is invalid for any reason, the Administration
Server returas:a Result Message object with a.code indicating
the reason. The format of the Result Message Object is shown
25 in Table 1. If the User information is valid, the .
Administration,Server updates the global database of User
names and passwords and then generates a security token f~r
that User. This security token is then returned to the ~Tser.
ixr a Result Message Object.
30 .Upon receiving the Result Message Object, the User
saves the security token for future use. .This.token is a~a
identifier that allows the User.to request services from the
Administration Server and. other computers within tire overall'
system. The security-token is hot saved permanently or
35 registered on the-User computer. Na~mally, the User software
then immediately sends a claannel.Guide Request Object to the
Administration Server and a Channel Guide Object is returned:.
~ 24 -


CA 02434698 2003-07-21
The format of these objects is also shown in Table. 1. Note-
that in principle, this.is a separate transaction and could
take place in a separate TCP connection to the Administration
Server. In particular, once the User has registered and
logged in, he/she can request the Channel Guide ~b~ect again
since it may have been updated since the previous.re~uest.~
~At this point. the TCh~ connection to the ~rdministration'~;server
is closed.
The process of User registration only net to take
io place,once.for each User. However~anyone can re-register at
any time, even after the software, has ~beein installed. Iti
particular, it is expected that if multiple persons use a
computer, each-person will register end obtain his/her own
User name and password.. If the registration process is not
:5 completed successfully, the User software saves ttie
registration.i~aformation and asks the User if he/she .would
like to try again the next time~the software is inv~oked.~
since the security~token is not permanently.sav~d
by the~User software, it is lost when thd Uses software .is
2o closed, and the security token must''again be r~trieved fry
the Administration Server the next time the User wants to use
the system.. . T~iis~ process is the purpose of the .login
sequence illustrated in Fig. .7. This sec~uen~'e is used if a .
User has already registered and needs only to retrieve~a
25 valid secu~~.ty,token. In this case.~the sequence consists of
the Oser~s sending a T.ogin Information object to the
Administration Server. The~Administration Server than
queries the User database to validate the login rr ~ acrd
password, if the loqin name and password are:corrwct, than a
3o security token~~is returned to the User. ~lormally the receipt
of the security token will ianmediately be follot~ by a
channel info~nation request sequence, dust ,as in the
registration sequence described previously.
The control sequence that ioakes place when a.User
33 initiates a channel play operation i~s illustrated in Figs.
8A, 8B and 8C. (First the User software" requests a Control
server List from the Administration Server. Dote that the
25 -


CA 02434698 2003-07-21
Server List Request Object, illustrated in Table l.contains~~a
. channel identifier. The Administration. Server generates a
sorted list ~~f Control Servers based on overall system load
and the location of the User on the network and returns this
list to the User using a Protocol List Object. Once the
Control Server List is returned to the User, the
Administration Server is no longer needed and the TCP
connection is closed.
The User software then searches the list of Control
30 Servers and opens a TCP connection to the first host listed.
If that host computer does not respond, then the next Control
Server on the list is tested and so forth in succession.
Upon obtaining a response from a Control Server, the User
software uses a Server List Request Object to requests a
Media Server List from the Control Server. :Cf the Control
server is too busy to service the User, it returns a Result
Message Object so indicating and the User software tries the
next Control Server on the list. However, in the likely
scenario that the Control Server is able to handle the User's
request, a sorted list of Media Servers is generated and
returned to the User computer using a Protocol List Object.
The TCP connection to the Control Server is then closed by
the User software.
At this point the User software initiates a TCP
connection to the first Media Server on the list provided by
the Control Server. As in the previous case, it attempts to
connect to the first host on the list and if unsuccessful
tries the next hosts in succession. Once the Version Objects
are exchanged, the User software sends an MCI Request Object
to the Media Server. An MCI Request Object can be used for
four basic commands: OPEN, PLAY, STOP and CLOSE. The User
software must first send an OPEN command for the desired
channel. If the returned Result Message Object indicates
success, the User software then sends a PLAY command.
When the Media Server receives a valid PLAY
command, it initiates the delivery of audio information to
the User as described in the previous section, Dote that
- 26 -


CA 02434698 2003-07-21
this could be in the form of broadcast, mul~icast or unicast
packets to a specific UBP port. The TCp connection through
which the MCI Request Objects were sent stays open during the
audio play operation. In addition, Ping Objects are sent to
the User on a periodic basis to verify that the computer is
still working and active. When the User software receives a
Ping object, it simply returns it. The Media Server uses the
Ping Objects to measure round trip time and also to determine
when a User's computer has terminated abnormally. In that
case the audio stream is terminated.
In the case of normal termination of the audio
stream, the User makes an explicit selection to stop and this
causes a STOP command to be sent to the Media Server in an
MCI Request Object. The Media Server then terminates the
audio stream to that User. When the User closes the
application software or selects another channel to play, the
User software will send a CLOSE command to the Media Server
in an MCI Request Object and the TCP connection is closed.
The initiation of the audio stream by the Meda_a
Server causes a log entry to be generated and sent to the
Administration Server. This information is important so that
the Administration Server can update its database to indicate
which Users are listening to which channels. The security
token is used to identify the User initiating the audio
stream. Additionally, when the audio stream is terminated to
any User, another iog message is generated and sent to the
Administration Server.
Fig. 9A illustrates the process by which security
tokens are validated.. The Administration Server is the only
server that can validate a security token. Thus, when a User
requests services from a Control Server or from a Media
Server, that server must go back to the Administration Server
with a token validation sequence. However, Control Servers
and Media Servers are allowed to cache validations of
security tokens so that they do not have to validate tokens
repeatedly once they have validated it the first tame. In
the case where a Media Server receives a request, the token


CA 02434698 2003-07-21
will be va7.idated with the Control Server that is managing.
that Media Server. F'ig. 9S identifies the various token
validation scenarios.
Fig. 1~ illustrates the process by which a new
server is registered. This process .is similar to.new User
registration. zt.is expected, howwer, that the server
installation will be through a Web interface rather~than a-
Wizasd. The Administration Server, upon receiving a ~Tser .
Obj ect ~roin a Media Server or .Control server, validates the
lo.User~name and password and generates a security token just as
in the case of User~regist~ation. Normally the Server then
immediately sends back a server Activation object indicating
that it is ready to be used as a system resource. ~nce this
process has_bee~n.completed, the TCP connection to the
a5 Administration server is closed.
If a Media Servsr or Cont~°ol Server that has sent a
Server Activation Object to the Administration Server becomes
inactive, it will send another Server Activation object
indicating this condition. In the ease of a Media Server,
2o dais object is sent to the managing Control Serve. ~In~the~
case of a Control Server, this object sent to: the
Administration Server. As in the case of User;registration,
Media Server and Control Server regi.~tration needs only~take
place once per ~ computer. However, if the computer i~. ~ ~ .
25 restarted, the server must login and again retrieve a
security token. This is the server 1~gin and activation
sequence shown in Figure ih.
once a Control Server has indicated to the
Administration Server that it is ready, the Administration
30 server can activate that Control Server'by sending the .»~~,
Control Server a Server Activation Object ae illustrated in
Fig. 12. This is a separate transaction and is used t~ tell
the control Server which Media Servers it is supposed to
manage. Recall that a Control Server and a numberlof Media
35 servers form a cluster-of Media Servers. The single control
Server that manages that cluster must be given a list of host
computers corresponding to the Media servers in that cluster.
-° 28 -


CA 02434698 2003-07-21
The process by which a Control Server activates the
Media Servers.that it manages is~illustrated in Fig, l3-. The
Control Serves sends a Server Activation Object to'the Media
. server indicating that it is responsible fer channel
management. This TCP connection between the Contr~1 Server
and, the Media Server stays open during the time that both
servers are active. The Control Server periodically sends
Ping objects to the Media Server.across this open TCP
connection to verify~that the Media server is~still_running.
i0 ~ Fig.' 9.~ illustrates the process by ~ which a ~ given
channel is activated by the Administration Server. The
Administratio~a Server opens a connection to a Control Server
that its wishes to have carry a given channel and provide a
Channel Activation Object. This object indicates to the
i5 Control. Server Which Media or Primary Server the Control
Server should direct its Mecia Servers to get the feed from.
At this point the Control Server is said to ba carrying that
channel and it will..be a valid host on a list of Control
Servers requested by a Chaiziiel Play sequence.
a0 Fig. 15 illustrates what. happens when a C~ntrol
Server needs to provide a channel. First it sends a~Channel
Activation~bject to one of the Media. Servers that it manages
acrciss the,operl TCCP connection~described previously. This .
object indicates to the Media Server that it should start
25 receiving the channel identified and from where it should
receive it.
~. In Figs. 16A and 1SH depict how the Media serer
requests distribution of an audio channel from another_Media
server or from a Primary server. Tb.is sequence is much the
30 same as that in which a ilser requests the distribution of
audio information..~rom a Media ~Se~rver. ' Note that a Media
Server receives a siaigle incoming stream for each channel
that it is carrying and then redistributes this stream
to all Users~or other Media Servers that request it.
35 Finally, Fig. IT illustrates the statistics request
sequence. This secsuence is used by the Ad~ainistration Server
to gather information. from the Media Servers and Control
- 29 -


CA 02434698 2003-07-21
Servers in order to manage the overall system. It can use
this information to detect failures and to balance load as
the dynamic.conditions change. l~s indicated above, it can
also~use this information to monitor which:Users are
listening ~to ~ahicli channel' or whether Users stop listening 't~
a channel,at any time, such.as during the p3~ay of a
particular song. 'It can also use this information to control
the. advertising. content that is downloaded to'a particular
User in advance of receipt of regular audio programming
io and/or monitor, the delivery_of advertising to the Users.
The cantrol architecture described in this section
is scalable to handle any number of Users. Note.that the
User registration process only happens. once for each
subscriber and the 3.ogin process~only happens once per
i5 sessions These interactions, which require the
Administration Server,~are eXpecte~d.to constitute a.very small
' ' percentage:of the overall system,bandwidth. If the
Administration Server. were to become a bottleneck, however,
~it would ~be possible to duplicate it~and to have the database
20 it maintains distrib~xted and automatically updated to .
guarantee cansisten~r.. ~ . .
. The Control Servers are dvstributed throughout the
' network and can handle the lower level ~i~rteractions -with the
.Users and the Media Servers. A single Control :Server,can
25 handle preferably on the order of ten Media Servers up t~
several hundred t3sers. The bitrate among the Users, the
Control Servers and the Media-Servers is expected to be'smahl.
in comparison to the audio transmission bitrate. The Ping
objects~normally only involve the User and the ne~x°est Media
3o Server. They are also low in overhead since their are small
and only get transmitted infrequently.
III. User Interface
The User interface is provided by. the client application
35 runni.rig ~on an individual computer .and its associated
graphical interface. In the preferred embodiment the Usex
interface is available for 32-hit Windows (95.and NT),
- 3Q


CA 02434698 2003-07-21
Macintosh anal UNIX platforms. Preferably anyone on the
Internet can freely download a copy of the client software
and install it in their computer.
Figure 18 illustrates the main User screen in the
preferred embodiment. The screen is composed of three
sections: channel guide (upper left frame), program guide
(upper right frame), and multimedia frame (lower half of
screen). The channel guide lists, as a tree hierarchy, the
channels that are available from the system. The User
l0 selects a channel from the list of those displayed on the
channel guide. The program guide provides information
pertaining to the channel selected. This information can be
a detailed schedule of the programming that has played or
will be glaying on the channel selected. Additionally, other
~5 relevant informatiora will be displayed in this frame, for
example, a notice regarding an upcoming special event on
another channel. True multimedia frame provides an integrated
web browser that displays information via a series of tabbed
sections.
2A The information. contained in the channel guide, program
guide, and the tabs of the multimedia frame is dynamically
transmitted to the client. for example, if a new channel
begins operation, the client application can immediately
display it as being available. Furthermore, the tabs
25 displayed can be specifically relevant depending on what song
is playing. For example, tabs displaying the album cover,
information on the artist, song lyrics, tour dates can be
displayed. Additionally, as shown in the example in figure
18, a tab caz be available allowing the User to place an
30 order for the CD or allowing the User to participate in a
chat session related to the channel.
Figure ~.9 illustrates the key pull-down menus available
in the main User screen in the preferred embodiment. Table 3
provides a description of each of the functions available
35 through the pull down menus, as shown in figure 19.
_ 31


CA 02434698 2003-07-21
As~will be apparent to those skilled in the art, w
numerous modifications may be made.within the spirit arid
scope ef the invention.
. ~ ~a~~~ ~ .
pulL~-Down Menu Functic~n~
Menu MeaWBub.-Cho ce besc=~.ptaon


Choice
,


ga a Log~rt A
ows the User o og to .
__ _ _..


the- system.


i0 y Logout A ows the User o ogou


from the system. .'


Register Hsings up a a og so a


the User c:an register with .


the syste~a for the (first


time:


close Minimizes t a screen..


Ed t copy A ows a User to cogy a


selection on ~to ~t~is


clipboard.


Proper ies A ows a user o se


various properties.


hudie P ay Begins playing a se ec a


channel. ."'


~ s op stops p
ay ng. a se ecte .
"'


2 ,
channel.


Mute "'~ stops a p ayang o au o
"


view Too Bar W sp ay or a. a a too


(providing'access to pull-


down menu functions). .
-
-


status Bar
-
'D~.sp~.ay or ha a a s atus


bar. normally situatedl~at


25 ~ botton of the screen. '


Web sar Dasp ay or hi a a too


section that provides access


t~ the web browser functions.


Help ~ielp Topics -Bsings up a s o avai a a


online help topics.


Abou .... Displavys summary inforcnatioa


30 ~ regarding this application,


such as version number, copy-


right information, arid so on.


..


- sa -

Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Administrative Status , Maintenance Fee  and Payment History  should be consulted.

Administrative Status

Title Date
Forecasted Issue Date 2006-11-07
(22) Filed 1997-05-08
(41) Open to Public Inspection 1997-11-13
Examination Requested 2003-07-21
(45) Issued 2006-11-07
Expired 2017-05-10

Abandonment History

Abandonment Date Reason Reinstatement Date
2003-05-08 FAILURE TO PAY APPLICATION MAINTENANCE FEE 2004-02-10

Payment History

Fee Type Anniversary Year Due Date Amount Paid Paid Date
Request for Examination $400.00 2003-07-21
Registration of a document - section 124 $50.00 2003-07-21
Registration of a document - section 124 $50.00 2003-07-21
Registration of a document - section 124 $50.00 2003-07-21
Application Fee $300.00 2003-07-21
Maintenance Fee - Application - New Act 2 1999-05-10 $100.00 2003-07-21
Maintenance Fee - Application - New Act 3 2000-05-08 $100.00 2003-07-21
Maintenance Fee - Application - New Act 4 2001-05-08 $100.00 2003-07-21
Maintenance Fee - Application - New Act 5 2002-05-08 $150.00 2003-07-21
Reinstatement: Failure to Pay Application Maintenance Fees $200.00 2004-02-10
Maintenance Fee - Application - New Act 6 2003-05-08 $150.00 2004-02-10
Maintenance Fee - Application - New Act 7 2004-05-10 $200.00 2004-05-07
Maintenance Fee - Application - New Act 8 2005-05-09 $200.00 2005-04-13
Advance an application for a patent out of its routine order $500.00 2005-06-17
Maintenance Fee - Application - New Act 9 2006-05-08 $200.00 2006-04-05
Final Fee $300.00 2006-08-04
Maintenance Fee - Patent - New Act 10 2007-05-08 $250.00 2007-05-08
Maintenance Fee - Patent - New Act 11 2008-05-08 $250.00 2008-04-29
Maintenance Fee - Patent - New Act 12 2009-05-08 $250.00 2009-05-06
Maintenance Fee - Patent - New Act 13 2010-05-10 $250.00 2010-05-06
Maintenance Fee - Patent - New Act 14 2011-05-09 $450.00 2011-05-17
Maintenance Fee - Patent - New Act 15 2012-05-08 $450.00 2011-05-17
Maintenance Fee - Patent - New Act 16 2013-05-08 $650.00 2013-07-20
Maintenance Fee - Patent - New Act 17 2014-05-08 $450.00 2013-07-20
Registration of a document - section 124 $100.00 2014-04-03
Registration of a document - section 124 $100.00 2014-04-03
Maintenance Fee - Patent - New Act 18 2015-05-08 $450.00 2015-05-06
Maintenance Fee - Patent - New Act 19 2016-05-09 $650.00 2016-07-21
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
TWO-WAY MEDIA LTD.
Past Owners on Record
BUTTERWORTH, JAMES F.
MONTEIRO, ANTONIO M.
NETCAST COMMUNICATIONS CORP.
NETCAST INNOVATIONS LTD.
TWO-WAY MEDIA LLC
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Abstract 2003-07-21 1 23
Description 2003-07-21 32 2,201
Claims 2003-07-21 9 389
Drawings 2003-07-21 23 533
Representative Drawing 2003-09-19 1 8
Cover Page 2003-10-01 2 42
Description 2005-06-17 32 2,179
Claims 2006-01-24 10 339
Cover Page 2006-10-12 2 43
Correspondence 2003-08-21 1 39
Assignment 2003-07-21 3 124
Correspondence 2003-09-09 1 15
Fees 2004-02-10 2 76
Fees 2004-05-07 1 34
Prosecution-Amendment 2005-06-17 2 83
Prosecution-Amendment 2005-06-17 1 34
Prosecution-Amendment 2005-06-27 1 11
Prosecution-Amendment 2005-02-25 1 41
Prosecution-Amendment 2005-07-25 2 35
Prosecution-Amendment 2006-01-24 12 405
Fees 2006-04-05 1 41
Correspondence 2006-08-04 1 41
Fees 2007-05-08 1 43
Fees 2010-05-06 1 29
Correspondence 2014-04-24 1 17
Correspondence 2014-04-24 1 17
Assignment 2014-04-03 3 80