WO2009087271A1 - Fourniture de services internet dans un système de communication - Google Patents

Fourniture de services internet dans un système de communication Download PDF

Info

Publication number
WO2009087271A1
WO2009087271A1 PCT/FI2009/050004 FI2009050004W WO2009087271A1 WO 2009087271 A1 WO2009087271 A1 WO 2009087271A1 FI 2009050004 W FI2009050004 W FI 2009050004W WO 2009087271 A1 WO2009087271 A1 WO 2009087271A1
Authority
WO
WIPO (PCT)
Prior art keywords
user terminal
service
buddy
registered
user
Prior art date
Application number
PCT/FI2009/050004
Other languages
English (en)
Inventor
Juho Seppänen
Original Assignee
Teliasonera Ab
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Teliasonera Ab filed Critical Teliasonera Ab
Publication of WO2009087271A1 publication Critical patent/WO2009087271A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4547—Network directories; Name-to-address mapping for personal communications, i.e. using a personal identifier

Definitions

  • the present invention relates to providing an IP service to a user terminal.
  • IP Voice over Internet protocol
  • Voice information is sent in discrete packets in a digital form.
  • Voice over IP may support telephone-to-telephone links via suitable adapters and/or voice communications from a telephone to an IP terminal (such as a PC with a sound card) or from IP terminal to IP terminal.
  • Instant messaging refers to a service that enables users who subscribe to the service and who are online at the same time, to exchange messages via the Internet.
  • Skype is an Internet service that enables a user to make calls from a computer. Typically, calling to other people on Skype is free, and calling to phones and mobiles around the world is fairly cheap. This goes both for voice and video calls.
  • MSN Messenger service enables the user to communicate in the network by utilizing instant messaging, voice or video. It also enables transmitting files and pictures, playing games, introducing music to friends, and selecting and personalizing icons and wallpapers.
  • Fring is a free mobile voice over Internet protocol (VoIP) application that enables the user to make voice calls, chat and check out who is online before dialing (real-time presence).
  • Fring utilizes wireless fidelity (WiFi) or a mobile Internet data plan to enable a user to make mobile Internet calls and live chat to other Fring users and other netwoks including Skype and MSN Messenger.
  • WiFi wireless fidelity
  • Skype and MSN Messenger a mobile Internet data plan to enable a user to make mobile Internet calls and live chat to other Fring users and other netwoks including Skype and MSN Messenger.
  • An object of the present invention is thus to provide a method, system, server, user terminal and a computer program product for implementing the method so as to solve above problems.
  • the objects of the invention are achieved by a method and an arrangement which are characterized by what is stated in the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims.
  • the invention is based on the idea of providing an IP service to a user terminal, where a first buddy list is obtained, including information on user terminals registered as a buddy of a first user terminal for a first IP service. Also a second buddy list is obtained, including information on user terminals registered as a buddy of the second user terminal for the first IP service.
  • the system is configured to recognise if the first and second user terminals are registered in a second IP service. As a response to the recognising, the system is configured to check the first and the second buddy list. If the first buddy list includes information on the second user terminal and if the second buddy list includes information on the first user terminal, the system is configured to provide information (e.g. a username or email address) on the second user terminal registered in the second IP service, to the first user terminal, and informa- tion on the first user terminal registered in the second IP service, to the second user terminal.
  • information e.g. a username or email address
  • An advantage of the method and arrangement of the invention is that it provides an IP service operator with a way to facilitate users to start using the IP service operator's network for mutual communication instead of an Internet operator's network.
  • Figure 2 illustrates signalling according to an embodiment of the present solution
  • Figure 3 illustrates operation of an access server according to an embodiment of the present solution
  • Figure 4 illustrates operation of a user terminal according to an embodiment of the present solution
  • Figure 5 illustrates a communications system according to a second embodiment of the present solution.
  • the present solution is applicable to any user terminal, network node, corresponding components), and/or to any communication system or any combination of different communication systems capable of providing or supporting IP services, such as voice over IP (VoIP) and/or instant messaging (IM) services.
  • the communication system may be a fixed communication system or a wireless communication system or a communication system utilizing both fixed networks and wireless networks.
  • the protocols used, the specifications of communication systems and network nodes, especially in mobile and wireless communication develop rapidly. Such development may require extra changes to an embodiment. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment.
  • the relevant inventive aspect is the functionality concerned, not the network element or equipment where it is executed.
  • the present solution allows a mobile service operator to exploit Internet operator networks such as Skype, MSN Messenger and/or Fring, in order to introduce its own IP services.
  • the present solution enables a fast way to increase the popularity of the service operator's VoIP and/or instant messaging network. This quick mushrooming is useful when a service operator's service is being introduced.
  • the present solution can bind users effectively to the service operator's services instead of services provided by Internet opera- tors (such as Skype etc.). By means of the present solution, the user can be motivated to use the mobile service operator's network for local communication with services similar to those of the Internet operator, but with a better reliability and quality.
  • the present solution reduces a risk of the service operator being merely a bit pipe, especially if many of its subscribers are fundamentally users of the service provided by an Internet operator.
  • the solution may also give a better base of usage of other services provided by the cellular operator, used with the same VolP/IM identity.
  • the services provided by the Internet operators are emerging to mobile phones, they are mainly used in personal computers (PC).
  • PC personal computers
  • the present solution enables an effective and wide- spread use both mobile terminals and in PC's (with a PC client for PC users).
  • the present solution is applicable to a service operator-run Vo IP/I M service with connections to other networks such as Skype and MSN Messenger.
  • a client is primarily providing the service operator VoIP service, but access to Internet operator networks such as Skype and MSN Messenger is also provided. That does not need to be done with interworking, but by giving the access to the Internet operator network via the same client.
  • a partnership agreement may or may not be required between the service operator and the Internet operator).
  • a server (such as an access server) operated by the service operator may be used as a proxy to the Internet operator network in order to make identification (ID) detection possible (the client may assist in the identification detection, if necessary).
  • This may implemented by running a back-end at the server (where the service operator IP service runs) and a front-end at the client (software on the user terminal, controlling a profile running on the server), thus enabling a more lightweight client.
  • the access to the VolP/IM service may or may not be limited to the service operator subscribers.
  • the present solution is applicable e.g. to a situation where at least two user terminals are users of an Internet operator network, and where they are each other's "buddies", i.e. "friends", in the Internet operator network.
  • the user terminals do not know if they both also are users of a service operator IP service.
  • the present solution provides a client for accessing to the Internet operator network via the client. If the at least two user terminals have the same client, i.e. they use the same IP service provided by the service operator (but are not aware of that), the access server is able to recog- nise this. After the recognition, the server is able to inform the user terminals in that they both are also subscribers of the service operator network.
  • the term client may refer to software running in the user terminal (such as a mobile phone and/or a PC).
  • a first user terminal is provided with information on a buddy list, in- eluding information (e.g. username, user identification, nickname, and/or email address) on at least one second user terminal (or user) that the first user ter- minal is able to communicate with by using the Internet operator service (i.e. the first and second user terminals are each other's "buddies").
  • the user terminal is provided with information on a modified buddy list, including information on user terminals (or users) that are also buddies of the user terminal in the service operator network (in addition to being buddies in the Internet operator network).
  • the server Before adding the user terminal onto a modified buddy list, the server may be arranged to request the user terminal's permission whether the user wishes to be a buddy of the other user also for the service operator net- work.
  • the user can be provided with information on those of his/her buddies of that are also able to use of the service operator IP service (in addition to using the Internet operator service).
  • the server may be arranged to add a username and password for the buddy into the service operator service profile.
  • the buddy list may be used to provide information on the buddy's presence (online, busy etc.).
  • FIG. 1 illustrates a communications system S according to a first embodiment of the present solution.
  • the system S comprises at least one user terminal UE1, UE2 that may be e.g. a mobile, wireless or fixed terminal, such as a mobile phone (mobile station), a personal digital assistant (PDA), a laptop or the like, capable of using VoIP and/or instant messaging services.
  • the user terminal UE1, UE2 is connected to an IP core network, via an access network AN, such as a third generation radio access network (3G RAN) or wireless lo- cal area network (WLAN) operated by a mobile and/or wireless network operator.
  • 3G RAN third generation radio access network
  • WLAN wireless lo- cal area network
  • the system S further includes an access server AS such as a VoIP access server operated by a service operator, for providing the user terminal UE, UE2 with access to a corresponding service operator service domain TS.
  • an access server AS such as a VoIP access server operated by a service operator, for providing the user terminal UE, UE2 with access to a corresponding service operator service domain TS.
  • the user terminal is connected "directly" to the service operator service via e.g. the Internet.
  • Connections with Internet operator networks X, Y may be implemented either via IMS (IP multimedia subsystem) and/or IPX (Internet packet exchange) or without them, over the network operator IP core network to the Internet.
  • IMS IP multimedia subsystem
  • IPX Internet packet exchange
  • FIG. 1 shows a simplified version of a cellular or wireless network structure, which only illustrate the components necessary for illustrating the present solution, even though those skilled in the art naturally know that a general communica- tions system also comprises other functions and structures, which do not have to be described in more detail herein.
  • each network node or function UE1, UE2, AN, TS, AS, X, Y has been depicted as one entity, different modules and memory may be implemented in one or more physical or logical entities.
  • a possible use case may be as follows. Both user terminals UE1, UE2 have recently registered in a service operator VoIP network TS (for example, chatting). The user terminals are initially buddies "only" in an internet operator network X, Y. They do not know that they both are also members of the service operator VoIP network TS. However, in the present solution the server is able to detect the case and to introduce the user terminals UE1, UE2 to each other within the TS network. The present solution facilitates the users to start using the service operator network for mutual communication instead of the Internet operator network. This possibly gives option to check also GSM contacts, whether or not they are using also the same service. User identity for TS may be linked e.g.
  • the solution may also enable inviting contacts that are not yet using the IP service.
  • the solution may or may not be limited to subscribers of the same service operator only.
  • buddy lists can be gathered in one common list in the client.
  • the buddy lists are stored and/or cached (they may be hashed if required e.g. for privacy purposes) in AS.
  • FIG. 1 illustrates signalling between network entities according to an embodiment of the present solution.
  • buddy lists maintained in the access server AS may look like as follows:
  • the first user terminal UE1 i.e. "John” logins to TS by transmitting a message 2-1 to AS.
  • the first user terminal UE1 further logins to X, Y by transmitting a message 2-1 , 2-2 via AS to X, Y.
  • buddy lists for UE1 for the first IP service X 1 Y is provided 2- 3, 2-4 via AS to UE1.
  • AS may modify the messages 2-1 , 2-2, 2-3, 2-4, if nee- essary, as different protocols may be used between UE and AS, and between AS and X, Y (it should be noted that if there are more than one Internet operators X, Y the services of which UE1 logins, a separate message 2-2 is needed for each Internet operator service, one that is transmitted from AS to X, and another that is transmitted from AS to Y (the same applies for message 2-3)).
  • buddy lists maintained in the access server AS may look like as follows (John is online in TS, X and Y):
  • the second user terminal UE2 (i.e. "Mike") logins to TS by transmitting a message 2-5 to AS to TS.
  • the second user terminal UE2 further logins to X by transmitting a message 2-5, 2-6 via AS to X.
  • buddy lists for UE2 for the first IP service is provided 2-7, 2- 8 via AS to UE2.
  • buddy lists maintained in the access server AS may look like as follows (Mike is online in TS and X):
  • TS VoIP AS is arranged to check the buddy lists, wherein it is detected that John and Mike are friends in X but not yet in TS VoIP. Therefore, buddy requests 2-10, 1-11 are transmitted from AS to UE1 and UE2, in order to inform John and Mike that they both are also users of TS VoIP.
  • the respective user terminal UE1 may be arranged to display an introduction text such as: "Your friend Mike@X is also using TS VoIP. Would you like to add him to your contacts in order to communicate via TS VoIP network?" (UE1 may be arranged to display: "Your friend John@X is also using TS VoIP. Would you like to add him to your contacts in order to communicate via TS VoIP network?").
  • the user terminal UE1, UE2 responds by transmitting 2-12, 2-13 a buddy response, wherein the user terminal UEI 1 UE2 agrees or disagrees with the buddy request. If the user terminals UE1, UE2 agree with the buddy request (i.e. a positive buddy response 2-12, 2-13 is received in AS from both (or at least two) of the terminals UE1, UE2), AS is arranged to create 2-14 modified buddy lists for UE1 and UE2 for the second IP service TS.
  • the modified buddy lists may be as follows (right column):
  • the modified buddy list may be provided 2-15, 2-16 to the respective user terminal UE1, UE2.
  • UE1 and UE2 may start to use TS for mutual communication (instead of X (or Y)). If both (or all) of the user terminals UE1, UE2 disagree with the buddy request, the buddy lists are not modified in step 2-14, and UE1, UE2 can continue communicating as before.
  • the system may form an asymmetric buddy list connection (depending on the system implementation) so that the one that disagreed is able to see the one that agreed, in his buddy list, but not vice versa.
  • FIG. 3 is a flow chart illustrating the operation of a server node AS according to an embodiment of the present solution.
  • a login message from the first user terminal UE1 i.e. "John" to X, Y, TS, is received 3-1 in AS. After that, the login message regarding X and Y is forwarded 3-2 to X, Y.
  • a buddy list for UE1 for the first IP service X, Y is received from X, Y, and it is forwarded 3-4 to UE1.
  • a login message from the second user terminal UE2 i.e. "Mike” to X, TS, is received 3-5 in AS. After that, the login message re- garding X and Y is forwarded 3-6 to X.
  • a buddy list for UE2 for the first IP service X is received from X, and it is forwarded 3-8 to UE2.
  • TS VoIP AS is arranged to check the buddy lists, wherein it is detected that John and Mike are friends in the first IP service X but not yet in the TS service. Therefore, buddy requests are transmitted 3-10 from AS to UE1 and UE2, in order to inform John and Mike that they both are also users of the TS service, but not yet friends via it. If the user terminals UE1, UE2 agree with the buddy requests, positive buddy responses 3-11 are received from UE1 , UE2, and AS is arranged to create 3-12 modified buddy lists for UE1, UE2 for the second IP service TS. After that, information on the modified buddy lists may be provided 3-13 to the user terminals UE1, UE2. If both of the user terminals UE1, UE2 disagree with the buddy request, the buddy lists are not modified in step 3-12.
  • FIG. 4 is a flow chart illustrating the operation of a first user terminal UE1 according to an embodiment of the present solution.
  • the first user terminal UE1 i.e. "John” logins to X, Y, TS by transmitting a login message towards AS.
  • a buddy list for UE1 for the first IP service X, Y is received 4-2 from AS.
  • a buddy request is received from AS, informing John that "Mike” (i.e. UE2) is also a user of TS VoIP.
  • UE1 is arranged to display 4-3 an introduction text such as: "Your friend Mike@X is also using TS VoIP.
  • UE1 may respond by transmitting 4-4 a buddy response, informing that the user of the user terminal UE1 agrees (or disagrees) with the buddy request. After that, information on a modified buddy list for TS may be received 4-5 from AS (indicating that Mike has agreed to be John's buddy for TS and that John has agreed to be Mike's buddy for TS). If Mike does not want to be John's buddy, a respective notification may (or may not) be received 4-5 in UE1.
  • the present solution enables the service operator IP service subscribers to find each other.
  • An advantage of that is that if they start to use the service operator IP service, the traffic does not necessarily have to travel as long distances as when using the Internet operator service. This is because the access server of the service operator is usually located in the home country of the user terminal and the Internet operator server is often located abroad.
  • the user terminal may use the service operator IP service as the basic service, wherein the Internet operator IP service is used as a supplement to the basic service.
  • the identity of the buddy for TS, X and/or Y may appear (i.e. displayed to the user) on the buddy list e.g. as a username, as a user ID, as a nickname, as an email address (which may be changed to a "user-friendly" form by the user), and/or as a combination these.
  • the buddy's phone number may be identified, and the user may add the name of the buddy (as in a phone book of a mobile phone).
  • the present solution comprises maintaining Internet operator specific buddy lists for registered user terminals.
  • the present solution comprises main- taining service operator specific buddy lists for registered user terminals.
  • the present solution comprises updating the buddy lists for X, Y, TS, maintained in AS, wherein information on the updated buddy lists may be provided to the respective user terminal UE1, UE2.
  • the access server may be arranged to transmit a unified buddy list to UE1, LJE2, where the user terminals registered as a buddy of UE1, UE2 for the first and second IP service TS, X, Y are included.
  • Another option is that only updated buddy list information is transmitted to UE1, UE2, for example, only the user terminals registered as a buddy of UE1, UE2 for TS may be included.
  • the buddy list or the modified buddy list may include information on e.g. all of the user terminal's buddies or only the latest registrations as a buddy.
  • FIG. 5 illustrates a communications system S according to a second embodiment of the present solution, illustrating a further environment of use of ID detection.
  • the second embodiment resembles the first embodiment.
  • a rich communication environment enables users with mobile devices (and possibly also PCs) UE1 to combine existing mobile services (e.g. IM, voice, and video) such that e.g. in a mobile phone, contact information on the phone's address book shows a contact's presence and available services (that the contact is able to support).
  • the environment involves a rich communication platform for gathering services together, enabling users to see which services other users are able to use in order to communicate with them.
  • the platform enables different services to use the same address book and show users' abilities for different kinds of services.
  • the environment facilitates a TS client (the client of the service operator's service TS) to detect whether the user has logged in e.g. in Skype X, and to detect who are the user's buddies in that network X.
  • the TS client may be arranged to send information on the user's Skype etc. friends to the TS server AS.
  • the TS server AS is able to detect their availability (and that they are not yet friends in the TS service) in the TS service.
  • the TS client may be equal to Skype and other clients running on the phone UE1, UE2 (and not at the server), but could see the user information of the services (including Skype) from the address book of the user device UE1
  • the second IP service TS and each of the first IP services involve their own clients on the user terminal UE1.
  • the TS client is able to read the buddy lists for X, Y, and to provide them to the server AS.
  • the buddy lists for X, Y are included on a common contact list of the platform, and they can be utilized by various applications.
  • the items and steps shown in the figures are simplified and only aim at describing the idea of the present solution.
  • the steps/points, signaling messages and related functions described above in Figures 1 to 5 are in no absolute chronological order, and some of the steps/points may be performed simultaneously or in an order different from the given one. Other functions may also be executed between the steps/points or within the steps/points and other signaling messages sent between the illustrated messages. Some of the steps/points or part of the steps/points can also be left out or integrated together or replaced by a corresponding step/point or part of the step/point.
  • the apparatus operations illustrate a procedure that may be implemented in one or more physical or logical entities.
  • the signaling messages are only exemplary and may even comprise several separate messages for transmitting the same information.
  • the messages serve only as examples and they may contain only some of the information mentioned above. In addition, the messages may also contain other information, and the titles may deviate from those given above.
  • the above- described operations may be performed in any other element of a communica- tions system.
  • a system or system network nodes that implement the functionality of the present solution comprise means for managing buddy lists in a manner described above.
  • Existing network nodes and user terminals comprise processors and memory that may be utilized in the operations of the present solution.
  • ASIC application-specific integrated circuits
  • EPLDs electrically programmable logic device
  • FPGAs field programmable gate array

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne la fourniture d'un service IP à un terminal d'utilisateur (UE1, UE2). Une première liste de contacts est obtenue, comprenant des informations sur des terminaux d'utilisateur enregistrés comme un contact d'un premier terminal d'utilisateur (UE1) pour un premier service IP (X, Y). Également une seconde liste de contacts est obtenue, comprenant des informations sur des terminaux d'utilisateur enregistrés comme un contact du second terminal d'utilisateur (UE2) pour le premier service IP (X, Y). Si les premier et second terminaux d'utilisateur (UE1, UE2) sont enregistrés dans un second service IP (TS)1 et si la première liste de contacts comprend des informations sur le second terminal d'utilisateur (UE2) et vice versa, des informations sur le second terminal d'utilisateur (UE2) enregistré sont fournies au premier terminal d'utilisateur (UE1), et des informations sur le premier terminal d'utilisateur (UE1) sont fournies au second terminal d'utilisateur (UE2).
PCT/FI2009/050004 2008-01-08 2009-01-07 Fourniture de services internet dans un système de communication WO2009087271A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20085011A FI20085011L (fi) 2008-01-08 2008-01-08 Internet-palvelujen tarjoaminen viestintäjärjestelmässä
FI20085011 2008-01-08

Publications (1)

Publication Number Publication Date
WO2009087271A1 true WO2009087271A1 (fr) 2009-07-16

Family

ID=39004311

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2009/050004 WO2009087271A1 (fr) 2008-01-08 2009-01-07 Fourniture de services internet dans un système de communication

Country Status (2)

Country Link
FI (1) FI20085011L (fr)
WO (1) WO2009087271A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230117615A1 (en) * 2021-10-19 2023-04-20 At&T Intellectual Property I, L.P. Api driven subscriber ims registration status changes and ims routing steering
US12127149B2 (en) * 2021-10-19 2024-10-22 At&T Intellectual Property I, L.P. API driven subscriber IMS registration status changes and IMS routing steering

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6549937B1 (en) * 1999-07-21 2003-04-15 Microsoft Corporation System and method for multi-protocol communication in a computer network
US20050076241A1 (en) * 2003-04-02 2005-04-07 Barry Appelman Degrees of separation for handling communications
US20060109854A1 (en) * 2004-11-22 2006-05-25 Cancel Ramon C Systems and methods to share information between digital video recorders
US20060190543A1 (en) * 2004-10-13 2006-08-24 Pulver Jeffrey L Systems and methods for advanced communications and control

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6549937B1 (en) * 1999-07-21 2003-04-15 Microsoft Corporation System and method for multi-protocol communication in a computer network
US20050076241A1 (en) * 2003-04-02 2005-04-07 Barry Appelman Degrees of separation for handling communications
US20060190543A1 (en) * 2004-10-13 2006-08-24 Pulver Jeffrey L Systems and methods for advanced communications and control
US20060109854A1 (en) * 2004-11-22 2006-05-25 Cancel Ramon C Systems and methods to share information between digital video recorders

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230117615A1 (en) * 2021-10-19 2023-04-20 At&T Intellectual Property I, L.P. Api driven subscriber ims registration status changes and ims routing steering
US12127149B2 (en) * 2021-10-19 2024-10-22 At&T Intellectual Property I, L.P. API driven subscriber IMS registration status changes and IMS routing steering

Also Published As

Publication number Publication date
FI20085011A0 (fi) 2008-01-08
FI20085011L (fi) 2009-07-09

Similar Documents

Publication Publication Date Title
US10491641B2 (en) Inter-IMS service support in telecommunication systems
US8064934B2 (en) Method, system and apparatus for automatic notification to a plurality of communication nodes
WO2004064432A2 (fr) Systeme est procede d'echange d'informations d'identification pour stations mobiles
CN102035813B (zh) 端到端呼叫的实现方法、端到端呼叫终端及系统
EP2334035B1 (fr) Gestion des informations de présence dans un système de communication
CN103634195A (zh) 通讯方法及装置
WO2010121528A1 (fr) Terminal mobile et procédé de transmission de données fondé sur un mode poste à poste
WO2010097126A1 (fr) Procédés et agencements servant à créer un rapport virtuel entre des dispositifs de communication pour publier des données personnelles
CA2606919C (fr) Methode, systeme et appareil permettant la notification automatique a plusieurs noeuds de communication
WO2009074846A1 (fr) Procédé de marquage d'emplacement pour signalisation en mode paquet
CN105471820A (zh) 融合通信终端发现以及能力探测的处理方法及装置
EP3469779B1 (fr) Ramification d'initialisation de services rcs
US9900353B2 (en) Method and apparatus for enabling communications between users
US20130188559A1 (en) Method for Establishing a Communication Connection over the Internet Between Mobile Terminals, Computer Program, and Storage Medium
WO2018187059A1 (fr) Services ims de tiers
CN102882759A (zh) 跨社交网络的通信方法、网元及系统
WO2009130389A1 (fr) Création de numéros de mobile virtuels dans des réseaux de communauté
CN108140229A (zh) 将设备信息传送给服务与通信相关联的计算设备的应用服务器
WO2009087271A1 (fr) Fourniture de services internet dans un système de communication
US10237212B2 (en) RCS origination forking
US12127149B2 (en) API driven subscriber IMS registration status changes and IMS routing steering
US20230117615A1 (en) Api driven subscriber ims registration status changes and ims routing steering
KR20100124157A (ko) 인스턴트 메신저 서비스 시스템 및 그 서비스 방법
EP3396903A1 (fr) Techniques pour fournir un statut d'accessibilité dans un réseau de communication
CN116669132A (zh) 数据传输的方法、网络设备和用户设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09700257

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09700257

Country of ref document: EP

Kind code of ref document: A1