Title of Invention

TECHNIQUE FOR DISTRIBUTING CONTENT DATA.

Abstract A technique for distributing content data in a first domain to a plurality of network components communicating in a second domain is provided, wherein the network components have addresses in both the first domain and the second domain. Content data for distribution in the first domain is received together with addresses of the network components in the first domain that have been derived from the addresses of the network components in the second domain. Thereafter, the content data is distributed to the network components via the first domain using the first domain addresses.
Full Text DESCRIPTION
Field of the Invention
The current invention relates to communications More specifically, the current invention relates to a technique lor distributing content data in a first domain to one or more network components engaged in communication in a second domain
Background of the Invention
Advances in mobile communications devices allow users to exchange increasing amounts of content data, such as audio,, video, and multimedia files However, the ability for a mobile communications device (or other network component) to exchange such content data while participating in a conference (or any other communication arrangement such as a combinational service communication) having more than two participants is limited Unless the conference is between two communications devices, content data cannot (or not satisfactorily) be sent to the various participants simultaneously during the conference For example, while two communications device users speaking to each other over a circuit switching (CS) domain may simultaneously exchange video data over a packet switching (PS) domain, a user would not be able to send that same video data to multiple users As a result communications devices must sequentially send the content data to each participant of a conferencing session, an arrangement that generates unnecessary data traffic and is time consuming
Accordingly, it will be appreciated that there remains a need for an improved technique for distributing content data to one or more network components in communication with each other
Summary of the Invention
The invention may be embodied in a method for distributing content data in a first domain to a plurality of network components that are in communication or otherwise communicating in a second domain, wherein the network components have addresses in both the first domain and the second domain The method may
2

include the steps of receiving content data from a network component for distribution in the first domain, receiving the addresses of the network components in the first domain derived from the addresses of the network components in the second domain, and distributing the content data to the network components via the first domain using the first domain addresses In one variation, the addresses of the second domain are resolved into (or otherwise associated with) equivalent or compatible addresses in the first domain
Depending on the desired configuration, the method may also include the step of centrally storing the addresses of the network components in the first domain that have been derived from the second domain addresses The addresses may either be the addresses of individual components, or they may be addresses for groups of network components (so that the transfer of content data to the group address results in the content data being distributed to each network component
associated therewith) If the addresses are stored on a server or other storage device, the method may also include the step of updating the list of centrally stored network components addresses based on the network components currently communicating in the second domain (e g , participating in a conferencing session or other session in which data is transmitted and/or received among the various network components) With this arrangement, the content data is only distributed to those currently participating in the communications (which might include new participants)
The addresses may be centrally stored when the communications in the second domain commence In addition to, or optionally, the addresses may be stored after a request (such as a Session Initiation Protocol message) by a network component in the second domain (for example, when a network component makes a request to initiate the process for content distribution) Furthermore, if the addresses are stored on a server, the method may include the step of contacting, by the server, a Home Location Register to determine the addresses of the network components in the second domain To facilitate the acquisition of the addresses and to minimize data traffic in some instances, the method may also comprise the step of generating a pointer to the centrally stored addresses
3

The centrally stored first domain addresses may be generated by providing the addresses in the second domain to an address resolver The address resolver transposes, converts, or otherwise associates the second domain addresses with corresponding addresses in the first domain After the addresses in the first domain addresses have been derived (eg for a group of communicating network components), they may be centrally stored Additionally, a pointer to the centrally stored group of first domain addresses (i e to their storage location) may be generated
In addition, or in the alternative, the method may also include the step of receiving the pointer (so that, for example, the receiving network component may subsequently transmit a distribution request with the pointer and the content data to be distributed for more rapid distribution of the content data) The use of a pointer also may ensure, as will be explained further below, that the most current list of addresses in the first domain are used for the distribution of content data
The method may also include the step of determining which types of content data are compatible with each end user device (or participant) For example, the addresses of the communicating network components may be obtained using a pointer and a capabilities request may be sent to the addresses thus obtained to poll the various network components regarding the transmission and/or reception capabilities Therefore, prior to distributing content data, it may be determined whether the content data needs to be modified for any particular participants Distribution of the content data may be performed by an Internet Protocol Multimedia Unit, or any other component, module, etc that can efficiently transmit data to a plurality of identified recipients The content data may be distributed by multicast, unicast, SMS, MMS, etc
The invention may further be embodied in a method for distributing content data in a first domain to a plurality of network components communicating in a second domain, wherein the network components have addresses in both the first domain and the second domain Such a method comprises the step of sending content
4

data and an identifier associated with at least one of the addresses of the network components in the second domain to a transmission unit for determining the corresponding addresses of the network components in the first domain and for distributing the content data to the network components via the first domain using the first domain addresses The identifier may, for example, be a list with one or more addresses or a pointer to such a list
The invention may be used in connection with the provision of combinational services that combine circuit switching (CS) domain services (e g , voice) with packet switching (PS) domain / Internet protocol multimedia (IPMM) services (e g content sharing), such as push-to-watch Voice and image sharing, push to view video, voice, and video-clip sharing, as well as voice and whiteboard sharing The
invention may also be used in connection with PS with PS/IPMM domain
f
combinational services such as gaming and push to talk, and gaming and instant messaging In other words, the various participating network components may be exchanging data while communicating via a conforming protocol relating, for example, to at least one of video conferencing, audio conferencing, and multimedia conferencing In some variations, the network components include at least one mobile communications device, and more specifically, mobile telephone In other variations, the network component is a device such as a communications terminal, a network node, an intermediary node such as a router, or the like
It will also be appreciated that the invention may be embodied in a computer program product comprising program code portions for performing the steps of the preceding inventions when the computer program product is run on a computer system Depending on the desired implementation, the computer program product may be stored on a computer readable recording medium
Similarly, the invention may be embodied in a system comprising a computer
processor and a memory coupled to the processor, where the memory is encoded
with one or more programs that may perform the steps of any the preceding
inventions
5

In an interrelated embodiment, the invention is provided in an apparatus for distributing content data in a first domain to a plurality of network components
communicating in a second domain, wherein the network components have
addresses in both the first domain and the second domain The apparatus may comprise a content data unit for receiving content data from a network component
for distribution in the first domain, an addressing unit for receiving the addresses
of the network components in the first domain derived from the addresses of the
network components in the second domain, and a distribution unit for distributing the content data to the network components via the first domain using the first domain addresses
The invention may also comprise another interrelated embodiment, namely an apparatus for distributing content data in a first domain to a plurality of network components communicating in a second domain, wherein the network components have addresses in both the first domain and the second domain The
apparatus may include a request unit for sending a distribution request containing
content data and an identifier associated with at least one of the addresses of the
network components in the second domain to a transmission unit for determining the corresponding addresses of the network components in the first domain and for distributing the content data to the network components via the first domain using the first network addresses
In addition to the apparatus embodiments, the invention may be an interrelated system for distributing content data in a first domain to a plurality of network components communicating in a second domain, wherein the network components have addresses in both the .first domain and the second domain Such a system may comprise an address resolver for determining the addresses of the network components in the first domain from the addresses of the network components in the second domain, and a transmission unit for receiving content data from a network component for distribution in the first domain and distributing the content data to the network components via the first domain using the first domain addresses from the address resolver
6

In an example useful for understanding the invention, a sequence of events may occur (in whole or in part) that facilitate a mobile communications device (or other type of network component) to send content data to a group of participating network components in a conferencing session The mobile communications device may order in a first domain, such as the CS domain, the storage of addresses of participating network components on a server or database (which may be part of the CS domain, an IPMMlunt, or integrated into the mobile communications device) Alternatively, the mobile communications device may send a message, such as a session initiation protocol (SIP) message, via a protocol such as IPMM to the server whereafter the server may contact the CS domain for the addresses If a SIP message is utilized, it may contain the mobile switching centre (MSC) address, or in the alternative, the server may contact a home location register (HLR) for routing information (such as the MSC address) in order to retrieve the conference information (which may be the individual addresses of each participant in the CS domain or it may be one or more addresses that pertain to groups of participants)
In another variation in the initialization step, the CS domain may automatically store the pertinent conference information when the conferencing session is established and it may periodically update this information whenever participants join or leave the conferencing session (in order to reduce signalling delays whenever a mobile communications device desires to send content to the other participating devices)
The next occurrence may be that the CS domain stores the addresses of the participants in the server The server may then, for example, resolve these
addresses in an address resolver so that PS or other domain addresses are
derived from the CS domain addresses The resolved addresses may be
subsequently stored in the server and a pointer to the addresses, generated by the server, may be sent to the requesting mobile communications device via the CS domain or the PS domain (e g , using an SMS)
7

The requesting network component may then send the content data and the pointer to a distribution unit, such as an IPMM unit, which may use the pointer to retrieve the addresses of the participating network components Once the addresses are obtained, the IPWvi unit may distribute the content to the participants via unicast (where IPMM sequentially distributes the content data to each of the participants using a protocol such as instant messaging. MMS or the like) or MBMS in the PS domain Optionally, the IPMM unit may also distribute the pointer to each of the participants either with or separate from the content data
Brief Description of the Drawings
In the following the invention will be described with reference to exemplary embodiments illustrated m the figures, m which
Fig 1 is a first process flow diagram useful for understanding and
implementing the irvention.
Fig 2 is a second process flow diagram useful for understanding and
implementing the invent-on.
Fig 3 is a signalling sequence chart useful for understanding and
implementing the invention
Fig 4 is a process flow diagram of a method embodiment of the invention,
and
Ftg 5 is a schematic diagram of an apparatus embodiment of the
invention
Detailed Description of tho Preferred Embodiments
In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular sequences of steps and various configurations, etc in order to provide a thorough understanding of the present invention It will be apparent to cne skilled m the art that the present invention may
8

be practiced in other embodiments that depart from these specific details Moreover, those skilled in the art will appreciate that the functions explained herein below may be implemented using software functioning in conjunction with a programmed microprocessor or general purpose computer, and/or using an application specific integrated circuit (ASIC) It will also be appreciated that while the current invention is primarily described as a method, it may also be embodied in a computer program product as well as a system comprising a computer processor and a memory coupled to the processor, wherein the memory is encoded with one or more programs that may perform the methods disclosed herein
Fig 1 illustrates a process flow diagram 100 useful for understanding and implementing the invention A plurality of network components 103, here pictured as mobile telephones, communicate with each other on a conferencing session in a circuit switching (CS) domain 110 via a server 120 that stores addresses for each of the network components and is coupled to an address resolver 130 that resolves the addresses from one domain to another (or otherwise derives addresses from one domain into addresses of another domain), and an IP Multimedia (IPMM) unit 145 that distributes data via a packet switching (PS) domain 165 or via MBMS/PS domain
A network component 104 that wishes to'send content data to the other participating network components 103, at step 105, orders the CS domain 110 to store the addresses of the participating components, at step 115, in the server or database 120 Alternatively, the network component 104 may send a session initiation protocol message (SIP) via IP Multimedia (IPMM) to the server 120 upon which the server 120 contacts the CS domain for the addresses With this variation, either the SIP message contains the mobile switching centre (MSC)
address or the server 120 contacts the home location register (HLR) for routing information, such as the MSC Address, in order for the server 120 to retrieve the conference information (i e , the addresses of the participating components)
9

After the CS domain addresses are stored at the server 120, the server resolves the addresses, at step 125, using the address resolver 130 and subsequently stores the resolved addresses The address resolver 130 may convert the CS addresses, as in the case of E164 addresses (as specified by the ITU (International Telecommunications Union)), into packet switching (domain) addresses such as URLs or IP addresses using ENUM (an IETF (Internet Engineering Task Force) proposal in which DNS (Domain Name System) systems will be used to translate E164 telephone numbers into URL (Uniform Resource Locator) and IP addresses - see RFC 2916) or using similar translation mechanism Moreover, the addresses may be a single address for the entire
group, or they may be the individual addresses of each participant At step 135, a
pointer to the resolved addresses stored'on the server 120 (and generated by the
server 120) is sent to the requesting network component 104 (either via the CS domain or in the PS domain (e g , as an SMS))
Optionally, modifications may be made to the list of addresses in case there are new network components participating or previously participating network
components have ceased communicating This modification / updating may be
performed on a periodic basis (whether or not initiated by a network component 104)
At step 140, the requesting network component 104 sends the content data including the received pointer to the IPMM unit 145 Next, at steps 150 and 155, the IPMM unit 145 uses the pointer to retrieve the addresses of the participating components and at step 160, the content data is distributed to the network components 103 via unicast in the PS domain 165 or Multimedia Broadcast Multimedia Service (MBMS) in the PS domain 170
Before distribution, the content data is temporarily stored in the IPMM unit 145 (which may be accomplished via a multimedia resource function (MRF)) The
network component 104 that sends the content data may include the content data
i in a SIP message (e g , SIP INFO message) and the content may be temporarily
10

stored in the multimedia resource function centre (MRFC - or a dedicated database coupled to the MRFC)
Alternatively, the requesting network component 104 may inform the MRFC (indirectly via a Serving-Call Session Control Function (S-CSCF) with a corresponding SIP message, upon which the multimedia resource function processor (MRFP) is ordered by the MRFC to retrieve the content from the requesting network component 104 With this arrangement, the content data may be retrieved immediately prior to its distribution, thereby avoiding the requirement for intermediate storage In addition, the MFRP may be used to adapt and modify the content data so that it is compatible with the capabilities of each of the participating components 103 (a technique for determining the capabilities of the participating components is described below)
If the content data is distributed by the IPMM unit 145 via MBMS/PS 170, then the MRFC contacts a broadcast multicast service centre (BMSC) for further content data distribution The MRFP then sends a single copy of the content data to the BMSC from which the content is distributed to the participating components 103 Optionally, if the technical capabilities of the participating components are known (such as by the IPMM unit 145, or retrieved from the participating components 103, or from a database), the MRFP may modify the data to ensure compatibility
In yet another variation, the IPMM unit 145 may cause the content data to be distributed via the PS domain 165 such that the MRFC acts as the content data provider and requests an multimedia messaging centre (MMSC) to distribute the content data via MMS
The skilled artisan will also appreciate that with the example shown in Fig 1, the CS domain 110 may automatically trigger the storage of the conference information in the server 120 whenever a conference is established (resulting in reduced number of signalling delays when a network component sends content data to the participating components). Also, with regard to this example, the
T
master control of the functionality described above resides within the server 120
11

The server 120 provides updated conference information and is the coordination node between the CS conference and the PS data sessions However, the skilled artisan will appreciate that the server 120 may be a logical unit that is integrated within another unit or module For example, the server 120 may be integrated in the CS domain, IPMM or within the network component (or mobile communications device) that commands steps 105 and 140 It will also be appreciated that, at step 135, the server 120 may send the pointer to all of the network components 103, rather than just the requesting network component 104
Fig 2 illustrates a variation 200 of the example of Fig 1 in which the technical capabilities of the various participating components may be determined so that certain types of content data or services can be provided These capabilities may be the types of content data that may be displayed or otherwise processed for each network component 103, and/or it may include information pertaining to the content distribution (e g , codecs, etc ) Common features and steps have the same numbering as in Fig 1
Simultaneous or subsequent to sending the content data at step 105, the requesting network component 104, at step 205, requests information pertaining to the capabilities of the participating components The IPMM unit 145, at step 210, which has retrieved the addresses of the network components 103 in the first
domain using a pointer to the addresses of the participating network components
103 which has been received by the requesting network component 104, then sends a capability request to the participating components 103 and receives the results from the participating components 103
Optionally, at step 215, the IPMM unit 145 sends the capabilities information to the server 120 for storage (for laier use) With this variation, the next capability request from the IPMM unit 145 need only be sent to participating components 103 that joined the conferencing session subsequent to the last capability request Finally, at step 220, the capability information of the other participating components 103 is sent either to the requesting network component 104 or to all
12

of the participating components 103 (which in the latter case would also include the capabilities of the requesting network component 104)
With reference to Fig 3, a signalling sequence chart 300 useful for understanding
and implementing the invention is provided The signalling sequence chart 300
illustrates various messages that may be exchanged among a requesting network component 305, a CS domain unit 310, an IPMM/PS unit 315, a server 320, an address resolver 325, and other network components 330 currently participating in
a CS conferencing session with the requesting network component 305

During the CS conferencing session, the requesting network component 305 sends signal 335 to the CS domain unit 310 to request it to store the addresses of the participating network components 330 The CS domain unit 310 then sends the participant information (e g , a list of CS domain addresses of the participating components and optionally a group identification) to the server 320 via signal 340 The server 320 then sends signal 345 to the address resolver 325 to request that the CS domain addresses (e g , a sequence of numbers according to the ITU-T E164 standard) be resolved for use in the IPMM/PS domain The address resolver 325 via signal 350 returns the resolved addresses (or single address when the individual participating component addresses are grouped together in some fashion) to the server 320
Next, the server 320 generates a pointer to the resolved addresses stored thereon and sends a confirmation signal and the pointer 355 to the CS domain unit 310 (or optionally, the server may simply send the resolved addresses rather than a pointer) The CS domain unit 310 forwards the confirmation via signal 360 (and the pointer to the address or addressed on the server 320) to the network component 305 Signal 365 acts to notify the CS domain unit 310 if there are any additions or deletions of participating network components 330 If a modification of the list of participating components is necessary, then, via signal 370, the server 320 is notified about the change (which may require that the server 320 repeat signals similar to signals 345 and 350 to resolve the addresses of new participating components)
13

The requesting network component 305 then sends the content data and the pointer to the IPMM/PS unit 315 in signal 375 (wherein the content data is temporarily stored in the IPMM/PS unit 315 (e g , in the multimedia resource function (MRF)) Via signal 380, the IPMM/PS unit 315 requests the addresses of the group members (or an address for the entire group) by sending the pointer to the server 320 The server 320, via signal 385 provides the IPMM/PS unit 315 with the addresses, whereafter, via signal 390, the IPMM/PS unit 315 distributes the content data to the participating components 330 Optionally, in addition, each of the participating components 315 sends a signal back to the IPMM/PS unit 315 confirming receipt of the content data
With the above examples, the CS conference may be a voice, video or multimedia conference The conference control and data handling can be performed by a conferencing call device (CCD) in the MSC, a dedicated multipoint control unit (MCU) (e g , for mobile multimedia based on protocols such as 3G 324M), or similar arrangements The conference may also be applied to PS and IPMM/PS conferences (e g , voice or videoconferencing in the PS domain or in combination with push-to-talk, gaming, or similar functionalities) The conferencing session may be established by a network component (e g , multi-party call in the CS domain) or all conference participants can register at a central server where the conference is established
'I As described above, each participant may optionally send a confirmation after it
has received the content data, either from each network component or by the BMSC when MBMS is applied In the latter case, the BMSC returns a list of content receivers (i e , the participating components that it monitors and controls) This confirmation may be used to verify the integrity and performance of the applicable data communications network and can also be used to charge accounts associated with the network components (in exchange for obtaining the content data) If the participating components have registered to receive the content data, then their accounts are simply charged, but if they have not registered (such as when the content data is distributed via multiple unicasts),
14

then the participant will have the oppoiunity to reiect the content data (and as a result the participant will not have to pay for such content data)
if the content data is being distributed to a large number of participating components it may be advantageous to use MBMS for the content data replication If this is the case then MBMS can notify the participating components about the contents of the content data (e g by spoken message in conference or an SMS with the multicast address) so that the participating components may register to indicate that they want to receive the content data Alternatively the content data may be pushed to the participating components via MBMS (and signalling messages may also be distributed via MBMS such as step 160 m Fig 1 and steps 210 and 220 m Fig 2)
In some variations the content data may comprise a pointer to further content data that may be transmitted so that each participant may retrieve the content data (e g from the Internet) With this arrangement each receiving network component may retrieve the further content data whenever required and its own preferred data transfer technique Furthermore portions of the content data may be subsequently stored at a server and network components that are not part of a conferencing session may access the stored content data by providing a conference identifier
With regard to Fig 4 a process flow diagram 400 is illustrated relating to a method for distributing content data in a first domain to a plurality of network components communicating in a second domain Similar to the illustrations and embodiments above the network components have addresses in both the first domain and the second domain The method commences at step 410. with the rccipt of content data from a network component for distribution m the first domam Thereafter at step 420 addresses of the network components in the first domam derived from the addresses of the network components in the second domam are received The method concludes at step 430 with the distribution of the content data to the network components via the first domain using the first demam addresses
15

Fig 5 illustrates an apparatus 500 for distributing content data in a first domain to a plurality of network components; communicating in a second domain, wherein the network components have addresses in both the first domain and the second domain The apparatus includes a content data unit 510 for receiving content data from a network component for distribution in the first domain, an addressing unit 520 for receiving the addresses of the network components in the first domain derived from the addresses of the network components in the second domain, and a distribution unit 530 for distributing the content data to the network components via the first domain using the first domain addresses
It will be appreciated from the above, that the invention provides many benefits such as the ability to enable instant exchange of content data while communicating in a voice, video, or multimedia conference among three or more participants A user may conveniently send the content data to all or selected participants via a user-friendly interface In those variations that utilize MBMS or similar protocols, the content data is efficiently delivered using common transport channels (with a single copy of the content date) in the network and broadcasting on the radio interface
While the present invention has been described with respect to particular
embodiments (including certain system arrangements and certain orders of steps
within various methods), those skilled in the art will recognize that the present invention is not limited to the specific embodiments described and illustrated herein Therefore, while the present invention has been described in relation to its preferred embodiments, it is to be understood that this disclosure is only illustrative Accordingly, it is intended that the invention be limited only by the scope of the claims appended hereto
16

WE CLAIM:
1. A method for distributing content data In a first domain (160) to a plurality of network components (103) in communication in a second domain (110), wherein the network components (103) have addresses in both the first domain (160) and the second domain (110), and wherein the first domain (160) is either one of a circuit-switched domain and a packet-switched domain and the second domain (110) is the other one of the circuit-switched domain and the packet-switched domains, the method comprising the steps of:
receiving content data from a network component (104) for distribution in the first domain (160);
receiving the addresses of the network components (103) in the first domain (160) derived from the addresses of the network components (103) in the second domain (110); and,
during the communication in the second domain (110), distributing the content data to the network components (103) via the first domain (160) using the
first domain addresses.
2. The method of claim 1, further comprising the step of resolving the
addresses in the first domain (160).
3. The method of any of the preceding claims, further comprising the step
of centrally storing the addresses of the network components (103) in the first
domain (160).
4. The method of claim 3, further comprising the step of updating the
centrally stored network component addresses based on the network components
(103) currently communicating in the second domain (110).
5. The method of any of claims 3 to 4, wherein the addresses are centrally
stored when communications in the second domain (110) commence.
17

6. The method of any claims 3 to 4, wherein the addresses are stored
after a request by a network component (104) in the second domain (110).
7. The method of any of claims 3 to 6, further comprising the steps of
generating a pointer to the centrally stored addresses in the first domain.
8. The method claim 7, further comprising the step of providing the
pointer to the network component (104) sending the content data.
9. The method of claim 8, further comprising the step of receiving the
pointer from the network component (104) sending the content data, and
distributing the content data to the network components (103).
10. The method of any of claims 3 to 9, wherein the centrally stored
addresses are stored on a server (120).
11. The method of claim 10, further comprising the step of contacting, by
the server (120), a Home Location Register to determine the addresses of the
network components (103) in the secondjdomain (110).
12. The method of any of the preceding claims, wherein at least one of the
network components (103) is a mobile communications device.
13. The method of any of the preceding claims, further comprising the step
of determining which types of content data are compatible with each network
component (103).
14. The method of any of the preceding claims, wherein distribution of the
content data is performed by an Internet Protocol Multimedia Unit (145).
18

15. The method of any of the preceding claims, wherein each of the
network components (103) is communicating via at least one
conferencing protocol.
16. A method for distributing content data in a first domain (160) to a
plurality of network components (103) in communication in a second domain (110),
wherein the network components (103) have addresses in both the first domain
(160) and the second domain (110), and wherein the first domain (160) is either one
of a circuit-switched domain and a packet-switched domain and the second domain
(110) is the other one of the circuit-switched domain and the packet-switched
domains, the method comprising the step of:
sending content data and an identifier associated with at least one of the addresses of the network components (103) in the second domain (110) to a transmission unit for determining the corresponding addresses of the network components (103) in the first domain (160) and for distributing, during the communication in the second domain (110), the'content data to the network components (103) via the first domain (160) using the first domain addresses.
17. A computer program product comprising program code portions for
performing the steps of any of the preceding claims when the computer program
product is run on a computer system.
18. The computer program product of claim 17, wherein the computer
program product is stored on a computer readable recording medium.
19. A system comprising a computer processor and a memory coupled to
the processor, where the memory is encoded with one or more programs that may
perform the steps of any of claims 1 to 16.
19

20. An apparatus (500) for distributing content data in a first domain (160) to a plurality of network components (103) in communication in a second domain (110), wherein the network components (103) have addresses in both the first domain (160) and the second domain (110), and wherein the first domain (160) is either one of a circuit-switched domain and a packet-switched domain and the second domain (110) is the other one of the circuit-switched domain and the packet-switched domains, the apparatus comprising:
a content data unit (510) for receivmg content data from a network component (103) for distribution in the first domain (160);
an addressing unit (520) for receiving the addresses of the network components (103) in the first domain (160) derived from the addresses of the network components (103) in the second domain (110); and
a distribution unit (530) for distributing, during the communication in the second domain (110), the content data to the network components (103) via the first domaln (160) using the first domain addresses.
21. An apparatus for distributing content data in a first domain (160) to a plurality of network components (103) in communication in a second domain (110), wherein the network components (103) have addresses in both the first domain (160) and the second domain (110), and wherein the first domain (160) is either one of a circuit-switched domain and a packet-switched domain and the second domain (110) is the other one of the circuit-switched domain and the packet-switched domains, the apparatus comprising a request unit for sending a request containing content data and an identifier associated with at least one of the addresses of the network components (103) in the second domain (110) to a transmission unit for determining the corresponding addresses of the network components (103) in the first domain (160) and for distributing, during the communication in the second domain (110), the content data to the network components (103) via the first domain (160) using the first network addresses.
20

22. A system for distributing content data in a first domain (160) to a plurality of network components (103) in communication in a second domain (110), wherein the network components (103) have addresses in both the first domain (160) and the second domain (110), and wherein the first domain (160) is either one of a circuit-switched domain and a packet-switched domain and the second domain (110) is the other one of the circuit-switched domain and the packet-switched domains, the system comprising:
an address resoiver (130) for determining the addresses, of the network components (103) in the first domain (160) from the addresses of the network components (103) in the second domain (110); and
a transmission unit for receiving content data from a network component for distribution in the first domain (160) and distributing, during the communication in the second domain (110), the content data to the network components (103) via the first domain (160) using the first domain (160) addresses determined by the address resoiver (130).
Dated this 13th day of November 2006
A technique for distributing content data in a first domain to a plurality of network components communicating in a second domain is provided, wherein the network components have addresses in both the first domain and the second domain Content data for distribution in the first domain is received together with addresses of the network components in the first domain that have been derived from the addresses of the network components in the second domain Thereafter, the content data is distributed to the network components via the first domain using the first domain addresses.

Documents:

03316-kolnp-2006 abstract.pdf

03316-kolnp-2006 assignment.pdf

03316-kolnp-2006 claims.pdf

03316-kolnp-2006 correspondence others.pdf

03316-kolnp-2006 description (complete).pdf

03316-kolnp-2006 drawings.pdf

03316-kolnp-2006 form-1.pdf

03316-kolnp-2006 form-2.pdf

03316-kolnp-2006 form-3.pdf

03316-kolnp-2006 form-5.pdf

03316-kolnp-2006 international publiucation.pdf

03316-kolnp-2006 international search authority report.pdf

03316-kolnp-2006 priority document.pdf

03316-kolnp-2006-correspondence-1.1.pdf

03316-kolnp-2006-others.pdf

3316-KOLNP-2006-(09-07-2012)-ABSTRACT.pdf

3316-KOLNP-2006-(09-07-2012)-AMANDED CLAIMS.pdf

3316-KOLNP-2006-(09-07-2012)-CORRESPONDENCE.pdf

3316-KOLNP-2006-(09-07-2012)-DESCRIPTION (COMPLETE).pdf

3316-KOLNP-2006-(09-07-2012)-DRAWINGS.pdf

3316-KOLNP-2006-(09-07-2012)-FORM-1.pdf

3316-KOLNP-2006-(09-07-2012)-FORM-2.pdf

3316-KOLNP-2006-(09-07-2012)-PA-CERTIFIED COPIES.pdf

3316-KOLNP-2006-(16-11-2011)-ENGLISH TRANSLATION.pdf

3316-KOLNP-2006-(16-11-2011)-EXAMINATION REPORT REPLY RECIEVED.pdf

3316-KOLNP-2006-(16-11-2011)-FORM-3.pdf

3316-KOLNP-2006-(18-12-2014)-CORRESPONDENCE.pdf

3316-KOLNP-2006-(26-03-2013)-CORRESPONDENCE.pdf

3316-KOLNP-2006-(28-05-2013)-CORRESPONDENCE.pdf

3316-KOLNP-2006-(28-05-2013)-FORM 3.pdf

3316-KOLNP-2006-(30-07-2012)-ANNEXURE TO FORM 3.pdf

3316-KOLNP-2006-(30-07-2012)-CORRESPONDENCE.pdf

3316-KOLNP-2006-CORRESPONDENCE 1.1.pdf

3316-KOLNP-2006-CORRESPONDENCE-1.2.pdf

3316-kolnp-2006-form 18.pdf

3316-KOLNP-2006-GPA.pdf

3316-KOLNP-2006-GRANTED-FORM 1.pdf

3316-KOLNP-2006-GRANTED-SPECIFICATION-COMPLETE.pdf

abstract-03316-kolnp-2006.jpg


Patent Number 265512
Indian Patent Application Number 3316/KOLNP/2006
PG Journal Number 10/2015
Publication Date 06-Mar-2015
Grant Date 26-Feb-2015
Date of Filing 13-Nov-2006
Name of Patentee TELEFONAKTIEBOLAGET LM ERICSSON (publ)
Applicant Address S-16483 Stockholm,Sweden
Inventors:
# Inventor's Name Inventor's Address
1 KELLER,Ralf Talblick 22,D-52146 Wurselen
2 HUNDSCHEIDT,Frank In de Boomgaard 26,NL-6464 GC Kerkrad,Netherlands
3 LOHMAR,Thorsten Hirschgraben 9-11,52062 Aachen, Germany
PCT International Classification Number H04L12/18; H04L12/28
PCT International Application Number PCT/EP2004/004181
PCT International Filing date 2004-04-20
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 PCT/EP2004/004181 2004-04-20 Sweden