WO2010139898A1 - Systeme de notification de sessions dans un reseau de telecommunications - Google Patents

Systeme de notification de sessions dans un reseau de telecommunications Download PDF

Info

Publication number
WO2010139898A1
WO2010139898A1 PCT/FR2010/051074 FR2010051074W WO2010139898A1 WO 2010139898 A1 WO2010139898 A1 WO 2010139898A1 FR 2010051074 W FR2010051074 W FR 2010051074W WO 2010139898 A1 WO2010139898 A1 WO 2010139898A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
session
notification
service
server
Prior art date
Application number
PCT/FR2010/051074
Other languages
English (en)
Inventor
Dominique Pichon
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Publication of WO2010139898A1 publication Critical patent/WO2010139898A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • 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/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1093—In-session procedures by adding participants; by removing participants
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/147—Signalling methods or messages providing extensions to protocols defined by standardisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles

Definitions

  • the present invention is in the field of session management in a telecommunication network.
  • SIP Session Initiation Protocol
  • IMS IP Multimedia Subsystem
  • a method "SIP REFER" of the current state of the art, described in the RFC3515 of the Internet Engineering Task Force (IETF) allows a first terminal to send a REFER message to a second terminal, so that it it initiates a session with a third terminal. This method thus makes it possible to transfer a session from the first terminal to the second terminal.
  • Document TR 23.838 describes a service of continuity of sessions in an IMS network, such a service making it possible to transfer an established session with a first terminal of a user, to a second terminal of the same user.
  • this mechanism it is necessary for this user to subscribe to the continuity service, and for the two terminals to be connected to the same SCC AS server (Service Centra lization and Continuity Application Server) in charge of this service. .
  • SCC AS server Service Centra lization and Continuity Application Server
  • the invention relates to a session notification system comprising:
  • a notification server comprising means for obtaining a profile of a first user, this profile comprising at least one identifier of a module for retrieving the characteristics of a session for accessing a service by said first user; and an identifier of a second user.
  • the recovery module comprises means for sending to the notification server a message comprising the characteristics of the aforementioned session; and the notification server comprises means for sending these characteristics to a terminal of the second user.
  • the invention thus allows the establishment of a new service, hereinafter called “session notification service”.
  • session notification service Each user wishing to benefit from this service can thus define, in his profile, his preferences in terms of session sharing, namely, on the one hand the sessions of which he wishes to notify the characteristics, and on the other hand the users, hereinafter after called “friends” or “friend users” to whom he wishes to notify these characteristics.
  • a profile may include one or more session feature recovery module identifiers, and one or more friends identifiers.
  • the invention can be applied in any telecommunications network implementing a signaling protocol for identifying the beginning and the end of a session. It applies especially in the case of a SIP network, in which the SIP messages
  • INVITE and BYE are respectively a session initialization message and a session termination message.
  • the session is called "finished”.
  • the invention also proposes using the notion of "programmed" session, to designate a session that can be initialized within a given time range. For example, in a video-on-demand service, if a user buys access rights to a video for a specific time period, it can be considered that the access session to this service is programmed between buying the video and access to the video itself. If the user does not activate the session in this range, the session becomes "expired”.
  • the session notification system makes it possible to notify a user to notify one or more of his friends of a "programmed", “active”, “completed” or “expired” session. .
  • the characteristics of a service access session are obtained by the notification server from an entity called "session characteristics recovery module".
  • this entity may for example be constituted by the application server managing this service or by a module internal to the terminal. More generally, it can be any entity on the network having knowledge of the state of a session.
  • this recovery module is a server capable of rendering a continuity service between at least two terminals of the first user connected to this server. It may for example be an SCC AS server in the case of an IMS network.
  • This embodiment is particularly advantageous because such a server is aware of all the sessions of this user. It can therefore also send, in the aforementioned message, the characteristics of another session of the first user.
  • the invention also provides a notification server that can be used in the session notification system mentioned above.
  • This server includes: means for obtaining a profile of a first user, this profile comprising at least:
  • the invention relates to the process of notification of sessions that can be implemented by this server in a telecommunication network.
  • This process comprises:
  • this profile comprising at least:
  • the session notification method according to the invention further comprises a step of recording the characteristics of the sessions of a user in said profile of this user.
  • the session notification method further comprises a step of subscription of the notification server to the session characteristics recovery module, this module providing the characteristics of the session to the notification server. in a notification message.
  • the session characteristics recovery module may for example be included in an application server or in the user's terminal. In the context of an IMS network, this mechanism can be implemented using the SIP requests SUBSCRIBE and SIP NCTIFY known to those skilled in the art.
  • the session notification method according to the invention further comprises a step of recording the characteristics of the sessions of a user in said profile of this user.
  • the notification server can obtain the characteristics of a user's sessions by simply reading his profile, without subscribing to the recovery modules of the characteristics of the sessions of this user.
  • the session notification method comprises a step of subscribing the notification server to a presence server, in order to be notified of the presence of the first user and / or the second user in the network.
  • This feature advantageously allows the notification server to subscribe to the session characteristics recovery modules to obtain the characteristics of the sessions of a user, as soon as it enters the network.
  • This feature also allows the notification server to terminate its subscription for a particular user to such a module as soon as that user is no longer present.
  • the invention allowed a user to define, in his profile, the sessions he wants the features to be notified to his friends.
  • a user can for example choose to notify the characteristics of a session identified by a particular identifier, the characteristics of sessions of a specific type, or the characteristics of all its sessions.
  • the invention also enables a user to define in his profile the types of sessions of his friends whose characteristics he wishes to be notified.
  • the profile of the first user comprises at least one identifier of a service access session by the second user (user-friend).
  • the session notification method according to this second variant of the invention then comprises: a step of obtaining the characteristics of this session in a profile of the second user; and
  • the information sent to this terminal can for example be filtered according to criteria specified in the profile.
  • This second variant can be combined or not with the first variant.
  • the invention can also be used in an embodiment in which a user can both specify his sessions he wishes to notify friends, and friends sessions he wishes to be notified.
  • the profile of a user includes session filtering criteria of his friends, only the sessions fulfilling these filtering criteria being notified to the user.
  • the invention also provides an application server that can be used in the session notification system mentioned above.
  • This server differs from the application servers of the state of the art in that it communicates to a notification server the characteristics of a session so that it can notify a third party user.
  • this server comprises: means for receiving a subscription message from a notification server; and
  • the invention relates to a method for implementing a service in a telecommunication network, this method comprising:
  • the characteristics of the implementation method of a service can be applied to the application server according to the invention and consequently to the notification system according to the invention.
  • the invention enables a user who has received, on his terminal, the characteristics of a session of access to a service by another terminal, to establish a session of access to this service using these services. characteristics.
  • the invention relates to a terminal comprising:
  • means for notifying the presence of this terminal in a telecommunications network means for receiving a notification message comprising the characteristics of an access session, by another terminal, to a service from an application server in the network;
  • the invention also relates to a method of establishing a first access session to a service to an application server in a telecommunications network. This process is put into and comprises:
  • the terminal can notify its presence in the network in several ways. For example, he can publish his presence to a network presence server. It can also send a message to a recovery module of the characteristics of a session of access to a service offered on the network.
  • the various steps of the session notification method are determined by computer program instructions.
  • the invention also relates to a first computer program, on an information carrier, this first program comprising instructions adapted to the implementation of the steps of the session notification method, these steps being implemented. by a notification server or more generally by a computer.
  • this first program comprising instructions adapted to the implementation of the steps of the session notification method, these steps being implemented. by a notification server or more generally by a computer.
  • the various steps of the method of implementing a service are determined by computer program instructions.
  • the invention also relates to a second computer program, on an information medium, this second program comprising instructions adapted to the implementation of the steps of the method of implementing a service, these steps being able to be implemented by an application server or more generally by a computer.
  • the various steps of the method of establishing a service access session are determined by computer program instructions.
  • the invention also aims at a third computer program, on an information carrier, this third program comprising instructions adapted to the implementation of the steps of the method of establishing an access session to a service, these steps can be implemented by a terminal or more generally by a computer.
  • Each of these three programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • the invention also relates to a computer readable information medium, and comprising instructions from at least one of the three computer programs as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1C represents a table in which subscribers are registered to a session notification service according to a particular embodiment of the invention
  • FIG. 2 schematically represents the hardware architecture of a terminal according to a particular embodiment of the invention
  • FIG. 3 schematically represents a session notification system according to a particular embodiment of the invention
  • FIG. 4 schematically shows the hardware architecture of an application server according to a particular embodiment of the invention
  • FIG. 5 schematically shows the hardware architecture of a notification server according to a particular embodiment of the invention
  • FIGS. 6A and 6B schematically represent, in flowchart form, the main steps of a notification method, a method for implementing a service and a session establishment method in accordance with FIG. a particular embodiment of the invention.
  • a service access session may take a state of "active session”, “completed session”, “scheduled session”, “expired session”, the state of a session between a session terminal T and an application server AS being defined as follows:
  • each user registered with the session notification service can define "friend" users, the friend of a user A being a user B to whom A wishes to notify the characteristics of at least one session for a user.
  • A.'s terminal the friend of a user A being a user B to whom A wishes to notify the characteristics of at least one session for a user.
  • the session notification service according to the invention is mainly based on:
  • an SN notification server in charge of obtaining the characteristics of the sessions and notifying the "friend" users concerned.
  • each user UA (respectively UB) defines his friends in a profile P A (respectively P B ) recorded in a database BD accessible by the notification server SN.
  • the notification server SN subscribes, according to the SIP mechanism SUBSCRIBE / NO ⁇ FY, to the session characteristics recovery modules, the latter notifying the server of the session. notification of the characteristics of a session at each change of state. It is possible to record in the PA profile of an UA user, the list of modules to be interrogated by the SN notification server for this user UA (AS application servers, UA user terminals). It has previously been specified that an AU user could specify in his profile P A the list of his user-friends which must be notified of the characteristics of the sessions of UA.
  • an UA user can record in his PA profile, the list of UB users (also called “friends") whose UA wishes to know the characteristics of the sessions.
  • the notification server SN handles the conflict if it turns out that a user UA requests to be notified of the sessions of a friend UB, while UB does not allow UA to be notified of those sessions.
  • FIG. 1A represents an exemplary profile P A according to the invention.
  • the profile P A has six sections
  • the first Sectl section comprises, in a USERJD field, the identifier UA of the user to whom the profile P A belongs.
  • the second section Sect2 includes information on the sessions of the user UA. It defines, for each of these sessions:
  • the characteristics of a session include the state of the session, the type of service of the session, and possibly other information.
  • the user UA has:
  • a first session Sl programmed from 18H to 2OH, of video-on-demand (VoD) type, the application server managing this session being the server AS1, the video file that can be accessed by UA from an SV video server, the session that can be announced to UA's friends until a moment "t_notify_end"; and
  • VoD video-on-demand
  • the third section Sect3 contains the list of user-friendly users of the user UA.
  • the fourth section Sect4 includes the parameters instructing the notification server SN how to obtain the characteristics of the sessions, for each type of session.
  • the SERVICEJD field identifies the type of service
  • the MODULE field indicates the session characteristics recovery module (AS application server, or terminal) capable of notifying the creation / modification / termination events of the sessions of the type.
  • the NO ⁇ F_END_DEFAULT field specifies default values for the ad time limit for these sessions. For example, a VoD session will be announced until 24 hours after the creation date of the session (T-created_rcvd). A VoIP session, however, is no longer announced as soon as the communication is finished (T_bye_rcvd).
  • the fifth section Sect5 indicates the notification preferences of the user UA for his own sessions.
  • SESS_CRTTERIA In the field SESS_CRTTERIA, it indicates filtering criteria concerning its sessions. In the field FRIENDJD, it indicates the identifiers of his friends allowed to be notified. In the example, he allows all his friends to be notified of his VoD sessions.
  • the sixth section, Secr.6, describes the UA user's notification preferences for their friends' sessions. These preferences may for example contain the type of these sessions. In the field SESS_CRITERIA, it indicates the filtering criteria concerning their sessions. In the field FRIENDJD, it indicates the identifiers of his friends. Finally, in the TERM field, it indicates on which terminal it wishes to be notified of these sessions. In the example, the user A authorizes the notification server SN to notify him, on his terminal TAl, the VoD sessions of all his friends (keyword ALL). In the embodiment described here, the terminals to be notified are recorded in a format USER.TERMINAL
  • FIG. 1B shows the profile P B of the user B.
  • an SCC AS application server Service Centra I eration and Continuity Application Server
  • TS 23.237 V9.0.0 of 3GPP this server being defined in document TS 23.237 V9.0.0 of 3GPP.
  • the notification server SN obtains the characteristics of the sessions of this user from the server SCC AS managing continuity of sessions for this user.
  • FIG. 1C represents a table TU comprising, in a SUBSCRIBERJJSERJD field, the identifier of a user subscribed to the notification service and in a PRES_SERV field the identifier of a presence server of this user.
  • the notification server SN can query this table to know the session notification service subscribers actually present in the network.
  • FIG. 2 represents the hardware architecture of the terminal TA1, that of the terminal TB1, TB2 being similar.
  • the terminal TA1 has the hardware architecture of a computer. It comprises in particular a processor 10, a read-only ROM 11, a random-access memory RAM 12, communication means 13 and a screen 14.
  • the ROM 11 constitutes a recording medium in accordance with the invention. It comprises a computer program PG1 comprising instructions for executing the Exxx steps of a method for establishing a service access session in accordance with the invention, these steps being described later with reference to Figures 6A and 6B.
  • the RAM 12 allows the execution of the program PG1 by the processor 10.
  • the computer program PG1 is able to implement the following software functions: implementation of the functions necessary for the management of the SIP signaling protocol (in particular sending and receiving SIP messages INVITE and BYE as defined in RFC 3261 and updated in RFC 3265, 3853 and 4320);
  • FIG. 3 represents a network 1 according to the invention. In the embodiment described here, this network 1 is in accordance with the architecture
  • the network 1 comprises the two application servers AS1 and AS2 mentioned above, in which:
  • the application server AS1 is capable of rendering a video-on-demand service Sl "VoD", this service enabling a client terminal to access, either live or delayed, within a given time range, video files hosted by an SV video server; and. the application server AS2 is capable of rendering an S2 service voice over IP.
  • Sl video-on-demand service
  • each of the terminals TA1, TB1, TB2 comprises means for registering in the network 1 with an S-CSCF equipment (Serving CaII Session Control Function).
  • a terminal TA1, TB1, TB2 sends a SIP INVITE request, which is processed by the equipment S-CSCF, then validated according to a profile of the user of this terminal registered in a Home Subscriber Server (HSS) entity.
  • HSS Home Subscriber Server
  • the SIP INVITE request is validated by the S-CSCF, it is redirected to the application server AS1, AS2 in charge of the service concerned.
  • the table TU and the database BD in which the profiles P A , PB are stored are co-located with the entity HSS. As a variant, they could notably be co-located with the notification server SN.
  • the profile specific to the invention and the profile managed by the HSS entity can be grouped together in the same data structure.
  • each of the terminals TA1, TB1, TB2 comprises means for publishing its presence to a presence server SP, this server being able to be interrogated by the notification server according to the invention.
  • the table TU includes a field PRES_SERV in which the presence server SP used by this user is registered.
  • FIG. 3 there is shown a presence table TP in which the presence server SP stores the terminals present in the network.
  • FIG. 4 represents the hardware architecture of an application server according to the invention, for example that of the server AS1.
  • this server has the hardware architecture of a computer. It comprises in particular a processor 12, a read-only memory ROM 21, a RAM RAM 22 and communication means 23.
  • the ROM 21 is a recording medium according to the invention. It comprises a computer program PG2 comprising instructions for executing the steps Gxxx of a method, according to the invention, for implementing an access service. specific to this server, these steps being described later with reference to Figures 6A and 6B.
  • the RAM 22 allows the execution of the program PG2 by the processor 20.
  • the computer program In the embodiment described here, the computer program
  • PG2 is able to implement the following software functions:
  • FIG. 5 shows the hardware architecture of the SN notification server.
  • this server has the hardware architecture of a computer. It comprises in particular a processor 30, a ROM ROM 31, a RAM RAM 32 and communication means 33.
  • the ROM 31 is a recording medium according to the invention. It comprises a computer program PG3 comprising instructions for executing the steps Fxxx of a method of access to a service, in accordance with the invention, these steps being described later with reference to FIGS. 6A and 6B.
  • the RAM 32 allows the execution of the program PG3 by the processor 30.
  • the computer program PG3 is able to implement the following software functions:
  • the notification server SN obtains the identity of the presence server in the PRES_SERV field of the table TU;
  • the UA and UB users use one of their terminals TA1, TB1 to define and save their profile P A , PB in the database DB.
  • An entry is added for each user in the TU table of users who subscribe to the notification service. This entry identifies the subscribed user and his presence server.
  • the notification server SN queries the database BD and identifies, in the field SUBSCRIBER_USER_ID of the table TU, the two users UA and UB. It also identifies, in the PRES_SERV field, that these two users publish their presence on the network 1 to the presence server SP.
  • the notification server SN subscribes to the presence server SP to be notified of the input of the terminals of the users UA, UB in the network, or their output.
  • the terminal TA1 of the user UA registers in the IMS network during a step E20, and that it publishes its presence with the presence server SP during a step E30.
  • the notification server receives, during a step F30, a notification message from the presence server SP informing it of the arrival of the terminal TA1 of the user UA on the network.
  • the SN notification server then queries, during a step
  • the notification server then obtains, in the MODULE field of the PA profile, the list of recovery modules of the characteristics of the VoD and VoIP services to which the user UA has subscribed.
  • these are AS1, AS2 application servers managing services.
  • step F60 it subscribes to these application servers AS1, AS2 to be notified of any event (creation, modification, termination) on a session managed by these servers in which the UA user participates.
  • These subscription messages are received by each server AS1, AS2 during a step G62.
  • the notification server SN obtains the list of the friends of the user UA, ie UB, by reading the section Sect3 of the profile P A. By analyzing the section Sect ⁇ of the profile P A , the notification server SN determines the sessions for which the user UA wishes to be notified. He deduces from this that the user UA wishes to be notified of the VoD or VoIP type sessions of the user UB.
  • step F80 it queries the database to know the VoD or VoIP type sessions of the user UB.
  • the notification server SN checks whether sessions of the user UB are to be notified. User UB has no session. The SN sends a message to the UA1 terminal of the user UA which indicates that the user friend UB is not announcing any session.
  • the application server AS1 announces this session to the notification server SN during a step GI10 by sending a notification message.
  • This notification message includes the characteristics of the session. It is received by the SN notification server during a step
  • the AS application server in charge of the session • The deadline for announcing the session. Note that this deadline may be indicated by the application server AS having notified the notification server SN or, if it is not indicated, be determined by reading the field NOTIF_END_DEFAULT section Sect4 of the profile P A for the VoD type service identified in this same section by the SERVICEJD field.
  • the notification server SN checks, during a step F130, whether there is a conflict as to the notification, to the user UB, of the characteristics of the session S1. In this case it is not the case because:
  • the user UA wishes his friend UB to be notified of the characteristics of the session S1 (jointly section Sect3 and section Sect5 of the profile P A ), the announcement deadline having not been reached; and
  • the user UB wishes to be notified on his terminal TB1 of the characteristics of the VoD sessions of the user UA
  • the notification server SN checks, if the user UB is present on the network.
  • the notification server receives, during a step F30, a notification message from the presence server SP informing it of the arrival of the terminal TB1 on the network.
  • the notification server SN then queries, during a step F40, the database DB to obtain the profile PB of the user UB.
  • the notification server SN then obtains, in the MODULE field of the section Sect4 of the profile PB, an identifier of the characteristics recovery module of the sessions of the services to which subscribes the user UB.
  • the user UB subscribed to the video-on-demand service, this service being managed by the server SCC AS, the user UB having subscribed to a continuity service.
  • the notification server SN subscribes to the server SCC AS to be notified of any event (creation, modification, termination) on a session managed by this server.
  • This subscription message is received by the SCC server AS during a step G62.
  • the notification server FN obtains the list of the UB user's friends, namely UA, by reading the section Sect3 of the profile P 6 .
  • the SN determines the characteristics of the sessions for which the user UB wishes to be notified. He deduces from this that the user UB wishes to be notified of the VoD or VoIP type sessions of the user UA.
  • a step F80 it queries the database to know the VoD or VoIP type sessions of the user UA. It obtains in the section Sect2 of the profile PA, the list of the sessions of the user UA, namely a session S1 of VoD and a session S2 of VoIP.
  • the notification server SN checks whether the user UA allows UB to be notified of these sessions. For this, he reads the section Sect5 of the profile P A which indicates the allowed audience according to criteria on the sessions.
  • the notification server SN verifies that the user UB belongs to the friends of the user UA, by reading the section Sect3 of the profile PA where UB appears.
  • the notification server SN can send a notification message to the user UB to provide the characteristics of the session S1 of the user UA.
  • the notification server SN analyzes the section Sect ⁇ of the profile PB to know the preferences of the user UB on the receipt of the notification messages.
  • the user UB indicates that he requests to be notified of the VoD sessions on his terminal TBl.
  • the user UB being connected via his terminal TB1, the SN sends the notification message.
  • This notification message is received by the terminal TB1 during a step E84, the characteristics of the session being displayed on the screen 14 of this terminal during this same step.
  • the SCC AS application server receives this SIP INVITE request during a step GlOO.
  • the SCC AS application server announces this session to the notification server SN during a step GI10 by sending a notification message.
  • This notification message includes the characteristics of the session. It is received by the notification server SN during the step F120.
  • the notification server SN adds in the section Sect2 of the profile PB an entry concerning this new session. It identifies it by S3 in the field SESSJD and saves its characteristics in the field SESS_CHAR. Its characteristics are:
  • the AS in charge of the session • The deadline for announcing the session. Note that this deadline may be indicated by the AS having notified the SN or, if it is not indicated, be determined by reading the NOTIF_END_DEFAULT field of section Sect4 of profile P 8 for the VoD type service identified in this same section by the field SERVICEJD.
  • the notification server SN determines that the deadline for the new session is not reached. He then determines the hearing of the notification of this session.
  • the notification server SN then analyzes the section Sect ⁇ of the PA profile of the user UA and determines that the user UA authorizes all his friends to notify him of their VoD sessions on his terminal TAl.
  • the user being part of the friends of the user UA, according to the section Sect3 of the profile P A , the notification server SN can therefore notify the session S3 of the user UB to the terminal TA1 of the user UA.
  • the notification server SN checks, if the user UA is present on the network with his terminal TAl.
  • the notification server SN sends, during a step F160, the characteristics of the session S3 of the user UB to the terminal TA1 of the user UA.
  • This notification message is received by the terminal TA1 during a step E160, the characteristics of the session being displayed on the screen 14 of this terminal during this same step. It has previously been explained in detail how the characteristics of a session of a first user could be notified to a second user.
  • the second user can (step E180) for example decide to join the session, if this session is active.
  • the characteristics of a session may include the multicast address of a broadcast group, the second terminal then having the opportunity to join this group.
  • the first user has subscribed to a continuity service
  • the second user can thus establish a communication with this SCC AS, this server being then used to transfer flows between the terminals of two different users.
  • the invention makes it possible in other words to extend the controller / controlled mechanism described in document TR 23.828 and limited to the transfer of session between the terminals of the same user, to the transfer of session between the terminals of different users.
  • the second user can also (step E180) decide to establish his own session. For example, in the case of a session scheduled to access a video, the second user can download this video in streaming, completely independently of a possible access to this video by the first user.
  • the invention has previously been described in the context of a SIP network. It can be applied in any other type of network proposing a signaling protocol making it possible to clearly define the beginning and the end of a session between two entities.
  • the sessions of a user are presented on the terminals of this user.
  • each terminal can maintain the list of its sessions on the basis of the streams it receives.
  • a terminal may also query the AS application server that manages its sessions, as defined in the DOCl document already mentioned.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Ce système de notification de sessions comporte un serveur de notification (SN) comportant des moyens d'obtention d'un profil (PA) d'un premier utilisateur, ce profil comportant au moins un identifiant d'un module (AS1, AS2, SCC AS) de récupération des caractéristiques d'une session (S1) d'accès à un service par le premier utilisateur et un identifiant d'un deuxième utilisateur; Ce module (AS1) comporte des moyens (23) pour envoyer au serveur de notification (SN) un message comportant les caractéristiques de la session (S1). Le serveur de notification (SN) comporte des moyens pour envoyer lesdites caractéristiques de la session (S1) à un terminal (TB1) du deuxième utilisateur.

Description

Système de notification de sessions dans un réseau de télécommunications
Arrière-plan de l'invention
La présente invention se situe dans le domaine de la gestion des sessions dans un réseau de télécommunication.
Elle s'applique de façon privilégiée mais non limitative dans un réseau utilisant le protocole SIP (Session Initiation Protocol), et en particulier dans un réseau IMS (IP Multimedia Subsystem).
Une méthode « SIP REFER » de l'état actuel de la technique, décrite dans le document RFC3515 de l'IETF (Internet Engineering Task Force) permet à un premier terminal d'envoyer un message REFER à un deuxième terminal, afin que celui-ci initie une session avec un troisième terminal. Cette méthode permet ainsi de transférer une session du premier terminal vers le deuxième terminal.
Malheureusement, la méthode « SIP REFER » ne permet pas d'effectuer le transfert de la session à l'initiative du second terminal.
Le document TR 23.838 décrit un service de continuité de sessions dans un réseau IMS, un tel service permettant de transférer une session établie avec un premier terminal d'un utilisateur, vers un deuxième terminal du même utilisateur. Mais pour que ce mécanisme fonctionne, il est nécessaire que cet utilisateur ait souscrit au service de continuité de session, et que les deux terminaux soient connectés à un même serveur SCC AS (Service Centra I ization and Continuity Application Server) en charge de ce service.
Le document « Allowing any UE to request the controller UE to initiate média flow transfer and/or Collaborative Session Control transfer » de la société ERICSSON, rendu public lors d'une réunion du groupe de travail IMS_SCC-SPI / Release 9, du 3GPP TSG SA WG2 tenue entre le 30 mars et le 3 avril 2009 à Hangzhou en Chine (ci-après DOCl), décrit par ailleurs que ce serveur SCC AS peut être interrogé par le terminal d'un utilisateur pour obtenir la liste des sessions actives de cet utilisateur.
Malheureusement, ce mécanisme ne permet pas d'effectuer un transfert de session entre deux terminaux appartenant à des utilisateurs différents. L'invention vise un système de gestion de sessions qui ne présente pas les inconvénients de l'art antérieur. Obiet et résumé de l'invention
Plus précisément, et selon un premier aspect, l'invention concerne un système de notification de sessions comportant :
- un serveur de notification comportant des moyens d'obtention d'un profil d'un premier utilisateur, ce profil comportant au moins un identifiant d'un module de récupération des caractéristiques d'une session d'accès à un service par ledit premier utilisateur et un identifiant d'un deuxième utilisateur. Dans ce système :
- le module de récupération comporte des moyens pour envoyer au serveur de notification un message comportant les caractéristiques de la session précitée ; et - le serveur de notification comporte des moyens pour envoyer ces caractéristiques à un terminal du deuxième utilisateur.
L'invention permet ainsi la mise en place d'un nouveau service, par la suite appelé « service de notification de sessions ». Chaque utilisateur désirant bénéficier de ce service peut ainsi définir, dans son profil, ses préférences en matière de partage de session, à savoir, d'une part les sessions dont il souhaite notifier les caractéristiques, et d'autre part les utilisateurs, ci-après appelés « amis » ou « utilisateurs amis » à qui il souhaite notifier ces caractéristiques.
Il est bien entendu, que conformément à l'invention, un profil peut comporter un ou plusieurs identifiants de modules de récupération de caractéristiques de sessions, et un ou plusieurs identifiants d'amis.
L'invention peut s'appliquer dans tout réseau de télécommunications mettant en œuvre un protocole de signalisation permettant d'identifier le début et la fin d'une session. Elle s'applique en particulier dans le cas d'un réseau SIP, dans lequel les messages SIP
INVITE et BYE sont respectivement un message d'initialisation de session et un message de terminaison de session.
Typiquement, dans le cas d'une session entre deux entités A ou B, on observe les messages suivants : - envoi d'un message d'initialisation de session par A ou B ;
- acquittement de ce message par l'autre entité ; - déroulement de la session, la session est dite « active » ;
- envoi d'un message de terminaison de session par A ou B ;
- acquittement de ce message par l'autre entité ;
- fin de la session, la session est dite « terminée ». Pour certaines applications, l'invention propose aussi d'utiliser la notion de session « programmée », pour désigner une session susceptible d'être initialisée dans une plage de temps déterminée. Par exemple, dans un service de vidéo à la demande, si un utilisateur achète des droits d'accès à une vidéo pour une plage de temps déterminée, il pourra être considéré que la session d'accès à ce service est programmée, entre l'achat de la vidéo et l'accès à la vidéo à proprement parler. Si l'utilisateur n'active pas la session dans cette plage, la session devient «expirée».
Grâce à cette caractéristique avantageuse, le système de notification de sessions selon, l'invention permet de notifier à un utilisateur de notifier un ou plusieurs de ses amis d'une session « programmée », « active », « terminée » ou «expirée».
Conformément à l'invention, les caractéristiques d'une session d'accès à un service sont obtenues, par le serveur de notification, d'une entité appelée « module de récupération des caractéristiques de session ». Lorsqu'un terminal accède à un service, cette entité peut par exemple être constituée par le serveur d'application gérant ce service ou par un module interne au terminal. Plus généralement, il peut s'agir de toute entité sur le réseau ayant connaissance de l'état d'une session.
Dans un mode particulier de réalisation, ce module de récupération est un serveur apte à rendre un service de continuité de session entre au moins deux terminaux du premier utilisateur connectés à ce serveur. Il peut par exemple s'agir d'un serveur SCC AS dans le cas d'un réseau IMS.
Ce mode de réalisation est particulièrement avantageux, car un tel serveur a connaissance de toutes les sessions de cet utilisateur. Il peut par conséquence envoyer aussi, dans le message précité, les caractéristiques d'une autre session du premier utilisateur.
Selon un deuxième aspect, l'invention vise aussi un serveur de notification pouvant être utilisé dans le système de notification de sessions mentionné ci-dessus. Ce serveur comporte : - des moyens d'obtention d'un profil d'un premier utilisateur, ce profil comportant au moins :
- un identifiant d'un module de récupération des caractéristiques d'une session d'accès à un service par le premier utilisateur ; et - un identifiant d'un deuxième utilisateur ;
- des moyens d'obtention, en provenance de ce module, des caractéristiques d'une session d'accès à ce service par un terminal du premier utilisateur ; et
- des moyens d'envoi, à un terminal du deuxième utilisateur, d'un message de notification comportant ces caractéristiques.
Corrélativement l'invention concerne le procédé de notification de sessions pouvant être mis en œuvre par ce serveur dans un réseau de télécommunication. Ce procédé comporte :
- une étape d'obtention d'un profil d'un premier utilisateur, ce profil comportant au moins :
- un identifiant d'un module de récupération des caractéristiques d'une session d'accès à un service par ledit premier utilisateur ; et
- un identifiant d'un deuxième utilisateur ;
- une étape d'obtention, en provenance de ce module, des caractéristiques d'une session d'accès au service par un terminal du premier utilisateur ;
- une étape d'envoi, à un terminal dudit deuxième utilisateur, d'un message de notification comportant ces caractéristiques.
Dans un mode particulier de réalisation, le procédé de notification de sessions selon l'invention comporte en outre une étape d'enregistrement des caractéristiques des sessions d'un utilisateur dans ledit profil de cet utilisateur.
Dans un mode particulier de réalisation, le procédé de notification de sessions selon l'invention comporte en outre une étape de souscription du serveur de notification auprès du module de récupération des caractéristiques de sessions, ce module fournissant les caractéristiques de la session au serveur de notification dans un message de notification. On rappelle que le module de récupération des caractéristiques de sessions peut par exemple être compris dans un serveur d'application ou dans le terminal de l'utilisateur. Dans le cadre d'un réseau IMS, ce mécanisme peut être mis en œuvre en utilisant les requêtes SIP SUBSCRIBE et SIP NCTIFY connues de l'homme du métier.
Dans un mode particulier de réalisation, le procédé de notification de sessions selon l'invention comporte en outre une étape d'enregistrement des caractéristiques des sessions d'un utilisateur dans ledit profil de cet utilisateur.
Grâce à cette caractéristique, le serveur de notification peut obtenir les caractéristiques des sessions d'un utilisateur par simple lecture de son profil, sans souscrire aux modules de récupération des caractéristiques des sessions de cet utilisateur.
Dans un mode particulier de réalisation, le procédé de notification de sessions selon l'invention comporte une étape de souscription du serveur de notification auprès d'un serveur de présence, afin d'être notifié de la présence du premier utilisateur et/ou du deuxième utilisateur dans le réseau.
Cette caractéristique permet avantageusement au serveur de notification de souscrire auprès des modules de récupération de caractéristiques de sessions pour obtenir les caractéristiques des sessions d'un utilisateur, dès que celui-ci entre dans le réseau.
Cette caractéristique permet aussi au serveur de notification de résilier sa souscription pour un utilisateur particulier auprès d'un tel module dès que cet utilisateur n'est plus présent.
Il a déjà été expliqué comment l'invention permettait à un utilisateur de définir, dans son profil, les sessions dont il souhaite que les caractéristiques soient notifiées à ses amis. Un utilisateur peut ainsi par exemple choisir de notifier les caractéristiques d'une session repérée par un identifiant particulier, les caractéristiques des sessions d'un type déterminé, ou les caractéristiques de toutes ses sessions. Dans une autre variante de réalisation, l'invention permet aussi à un utilisateur de définir dans son profil les types des sessions de ses amis dont il souhaite être notifié des caractéristiques. Dans cette variante, le profil du premier utilisateur comporte au moins un identifiant d'une session d'accès à un service par le deuxième utilisateur (utilisateur-ami). Le procédé de notification de sessions selon cette deuxième variante de l'invention comporte alors : - une étape d'obtention des caractéristiques de cette session dans un profil du deuxième utilisateur ; et
- une étape d'envoi, à un terminal du premier utilisateur, d'un message de notification comportant ces caractéristiques. Les informations envoyées à ce terminal peuvent par exemple être filtrées en fonction de critères spécifiés dans le profil.
Cette deuxième variante peut être combinée ou non avec la première variante. Autrement dit, l'invention peut aussi être utilisée dans un mode de réalisation dans lequel un utilisateur peut à la fois préciser ses sessions qu'il souhaite notifier à des amis, et des sessions d'amis dont il souhaite être notifié.
Dans un mode particulier de cette deuxième variante de réalisation, le profil d'un utilisateur comporte des critères de filtrage de sessions de ses amis, seules les sessions remplissant ces critères de filtrage étant notifiées à l'utilisateur.
Ces critères peuvent être génériques et exprimés sous la forme de meta caractères. Ils peuvent par exemple permettre de définir des règles spécifiant que toutes les sessions des amis d'un utilisateur sont à notifier sur tous les terminaux de cet utilisateur. On notera que les caractéristiques du procédé de notification de sessions peuvent être appliquées au serveur de notification selon l'invention et par conséquent au système de notification selon l'invention.
Selon un troisième aspect, l'invention vise aussi un serveur d'application pouvant être utilisé dans le système de notification de sessions mentionné ci-dessus. Ce serveur se distingue des serveurs d'application de l'état de la technique en ce qu'il communique à un serveur de notification les caractéristiques d'une session pour que celui-ci puisse les notifier à un utilisateur tiers.
Plus précisément, ce serveur comporte : - des moyens de réception d'un message de souscription en provenance d'un serveur de notification ; et
- des moyens d'envoi, à ce serveur de notification, d'un message de notification comportant les caractéristiques d'une session d'accès à un service par un utilisateur. Corrélativement, l'invention concerne un procédé de mise en œuvre d'un service dans un réseau de télécommunication, ce procédé comportant :
- une étape de réception d'un message de souscription en provenance d'un serveur de notification ; et
- une étape d'envoi, à ce serveur de notification, d'un message de notification comportant les caractéristiques d'une session d'accès à un service par un utilisateur.
Les caractéristiques du procédé de mise en œuvre d'un service peuvent être appliquées au serveur d'application selon l'invention et par conséquent au système de notification selon l'invention.
Il a été expliqué comment l'invention permet à un utilisateur ayant reçu, sur son terminal, les caractéristiques d'une session d'accès à un service par un autre terminal, d'établir une session d'accès à ce service en utilisant ces caractéristiques.
Aussi, et selon un quatrième aspect, l'invention concerne un terminal comportant :
- des moyens de notification de la présence de ce terminal dans un réseau de télécommunications ; - des moyens de réception d'un message de notification comportant les caractéristiques d'une session d'accès, par un autre terminal, à un service auprès d'un serveur d'application dans le réseau ; et
- des moyens pour établir une session d'accès à ce service à partir de ces caractéristiques. Corrélativement, l'invention vise aussi un procédé d'établissement d'une première session d'accès à un service auprès d'un serveur d'application dans un réseau de télécommunication. Ce procédé est mis en et comporte :
- une étape de notification de la présence du premier terminal dans le réseau ;
- une étape de réception d'un message de notification comportant les caractéristiques d'une deuxième session d'accès au même service par un deuxième terminal ; et
- une étape d'établissement de la première session à partir de ces caractéristiques. Le terminal selon l'invention peut notifier sa présence dans le réseau de plusieurs façons. Il peut par exemple publier sa présence auprès d'un serveur de présence du réseau. Il peut aussi envoyer un message à un module de récupération des caractéristiques d'une session d'accès à un service offert sur le réseau.
Dans un mode particulier de réalisation, les différentes étapes du procédé de notification de sessions sont déterminées par des instructions de programme d'ordinateur.
En conséquence, l'invention vise aussi un premier programme d'ordinateur, sur un support d'informations, ce premier programme comportant des instructions adaptées à la mise en œuvre des étapes du procédé de notification de sessions, ces étapes pouvant être mises en œuvre par un serveur de notification ou plus généralement par un ordinateur. Dans un mode particulier de réalisation, les différentes étapes du procédé de mise en œuvre d'un service sont déterminées par des instructions de programme d'ordinateur.
En conséquence, l'invention vise aussi un deuxième programme d'ordinateur, sur un support d'informations, ce deuxième programme comportant des instructions adaptées à la mise en œuvre des étapes du procédé de mise en œuvre d'un service, ces étapes pouvant être mises en œuvre par un serveur d'application ou plus généralement par un ordinateur.
Dans un mode particulier de réalisation, les différentes étapes du procédé d'établissement d'une session d'accès à un service sont déterminées par des instructions de programme d'ordinateur.
En conséquence, l'invention vise aussi un troisième programme d'ordinateur, sur un support d'informations, ce troisième programme comportant des instructions adaptées à la mise en œuvre des étapes du procédé d'établissement d'une session d'accès à un service, ces étapes pouvant être mises en œuvre par un terminal ou plus généralement par un ordinateur.
Chacun de ces trois programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'au moins un des trois programmes d'ordinateurs tel que mentionnés ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disk) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
- les figures IA, IB sont des exemples de profil pouvant être utilisés dans l'invention ; - la figure IC représente une table dans laquelle sont enregistrés les abonnés à un service de notification de sessions conforme à un mode particulier de réalisation de l'invention ;
- la figure 2 représente de façon schématique l'architecture matérielle d'un terminal conforme à un mode particulier de réalisation de l'invention ; - la figure 3 représente de façon schématique un système de notification de sessions conforme à un mode particulier de réalisation de l'invention ;
- la figure 4 représente de façon schématique l'architecture matérielle d'un serveur d'application conforme à un mode particulier de réalisation de l'invention ;
- la figure 5 représente de façon schématique l'architecture matérielle d'un serveur de notification conforme à un mode particulier de réalisation de l'invention ; et - les figures 6A et 6B représentent schématiquement, sous forme d'organigramme, les principales étapes d'un procédé de notification, d'un procédé de mise en œuvre d'un service et d'un procédé d'établissement de session conformes à un mode particulier de réalisation de l'invention.
Description détaillée d'un mode de réalisation
Nous allons maintenant décrire un mode de réalisation de l'invention dans le contexte particulier d'un réseau de télécommunications conforme à l'architecture IMS. Dans l'exemple de réalisation décrit ici, nous considérons deux utilisateurs UA, UB.
Nous supposerons que l'utilisateur UA possède un terminal TAl et que l'utilisateur UB possède deux terminaux TBl, TB2.
Nous supposerons que les utilisateurs UA et UB ont souscrit à un service de vidéo à la demande, l'utilisateur UA ayant en outre souscrit à un service de voix sur IP.
Dans le mode de réalisation décrit ici, une session d'accès à un service peut prendre un état parmi « session active », « session terminée », « session programmée », « session expirée », l'état d'une session entre un terminal T et un serveur d'application AS étant défini de la façon suivante :
- « session active» dans tout l'intervalle de temps compris entre l'acquittement, par le serveur AS, d'une requête SIP INVITE émise par T pour accéder à ce service, et l'acquittement positif, par l'une de ces entités T ou AS, d'une requête SIP BYE émise par l'autre de ces entités T pour terminer ce service ; - « session terminée » après acquittement du message de terminaison de session ;
- « session programmée » dès lors qu'elle n'est pas active mais qu'il est défini des droits autorisant l'activation de la session dans une plage de temps ultérieure et déterminée ; et
- « session expirée » lorsqu'une session programmée n'a pas été activée dans la plage de temps autorisée.
Conformément à l'invention, chaque utilisateur inscrit au service de notification de sessions peut définir des utilisateurs « amis », l'ami d'un utilisateur A étant un utilisateur B à qui A souhaite notifier les caractéristiques d'au moins une session pour un terminal de A.
D'une façon générale, le service de notification de sessions selon l'invention repose principalement :
- d'une part sur les modules de récupération des caractéristiques des sessions, ces modules ayant pour fonction principale de récupérer les caractéristiques, dont l'état, des sessions, ces modules pouvant notamment être mis en œuvre par les serveurs d'application AS ou par les terminaux ; et
- d'autre part d'un serveur de notification SN, en charge d'obtenir les caractéristiques des sessions et de notifier les utilisateurs « amis » concernés.
Dans le mode de réalisation décrit ici, chaque utilisateur UA (respectivement UB) définit ses amis dans un profil PA (respectivement PB) enregistré dans une base de données BD accessible par le serveur de notification SN.
Afin que le serveur de notification SN connaisse les caractéristiques des sessions, dans un mode de réalisation, le serveur de notification SN souscrit, selon le mécanisme SIP SUBSCRIBE/NOΗFY auprès des modules de récupération des caractéristiques des sessions, ceux-ci notifiant le serveur de notification des caractéristiques d'une session à chaque changement d'état. Il est possible d'enregistrer dans le profil PA d'un utilisateur UA, la liste des modules devant être interrogés par le serveur de notification SN pour cet utilisateur UA (serveurs d'application AS, terminaux de l'utilisateur UA). II a été précisé précédemment qu'un utilisateur UA pouvait préciser dans son profil PA, la liste de ses utilisateurs-amis qui doivent être notifiés des caractéristiques des sessions de UA.
Dans un autre mode de réalisation, un utilisateur UA peut enregistrer dans son profil PA, la liste des utilisateurs UB (également appelés « amis ») dont UA souhaite connaître les caractéristiques des sessions.
Dans l'exemple décrit ici, ces deux modes de réalisation sont mis en œuvre. Dans ce cas, il peut être prévu que le serveur de notification SN gère le conflit s'il s'avère qu'un utilisateur UA demande à être notifié des sessions d'un ami UB, alors que UB n'autorise pas UA à être notifié desdites sessions.
La figure IA représente un exemple de profil PA conforme à l'invention. Dans ce mode de réalisation, le profil PA comporte six sections
Sectl, Sect2, Sect3, Sect4, Sect5 et Sectβ.
La première section Sectl comporte, dans un champ USERJD, l'identifiant UA de l'utilisateur à qui appartient le profil PA.
La deuxième section Sect2 comporte des informations sur les sessions de l'utilisateur UA. Elle définit, pour chacune de ces sessions :
- l'identifiant de cette session dans un champ SESSJD ; et
- les caractéristiques de cette session dans un champ SESS_CHAR.
Dans le mode de réalisation décrit ici, les caractéristiques d'une session comportent l'état de la session, le type de service de la session et éventuellement d'autres informations. Ainsi, dans l'exemple de la figure IA, l'utilisateur UA a :
- une première session Sl programmée de 18H à 2OH, de type vidéo à la demande (VoD), le serveur d'application gérant cette session étant le serveur ASl, le fichier vidéo pouvant être accédé par UA auprès d'un serveur vidéo SV, la session pouvant être annoncée aux amis de UA jusqu'à un instant « t_notify_end »; et
- une deuxième session S2, active, de type voix sur IP (VoIP), le serveur d'application gérant ce service étant le serveur AS2, l'utilisateur UA étant en communication de voix sur IP avec un interlocuteur user@s.com, cette session pouvant être annoncée jusqu'à l'instant t_notify_end. La troisième section Sect3 comporte la liste des utilisateurs amis de l'utilisateur UA.
La quatrième section Sect4 comporte les paramètres indiquant au serveur de notification SN comment obtenir les caractéristiques des sessions, pour chaque type de session. Le champ SERVICEJD identifie le type de service, le champ MODULE indique le module de récupération de caractéristiques de sessions (serveur d'application AS, ou terminal) susceptible de le notifier des événements de création/modification/terminaison des sessions dudit type. Enfin, le champ NOΗF_END_DEFAULT indique des valeurs par défaut concernant la limite temporelle d'annonce de ces sessions. Par exemple, une session de type VoD sera annoncée jusque 24h après la date de création de la session (T- created_rcvd). Une session de type VoIP en revanche n'est plus annoncée dès que la communication est terminée (T_bye_rcvd). La cinquième section Sect5 indique les préférences de notification de l'utilisateur UA pour ses propres sessions. Dans le champ SESS_CRTTERIA, il indique des critères de filtrage concernant ses sessions. Dans le champ FRIENDJD, il indique les identifiants de ses amis autorisés à être notifiés. Dans l'exemple, il autorise tous ses amis à être notifié de ses sessions de type VoD.
La sixième section Secr.6 indique les préférences de notification de l'utilisateur UA concernant les sessions de ses amis. Ces préférences peuvent par exemple contenir le type de ces sessions. Dans le champ SESS_CRITERIA, il indique les critères de filtrage concernant leurs sessions. Dans le champ FRIENDJD, il indique les identifiants de ses amis. Enfin, dans le champ TERM, il indique sur quel terminal il souhaite être notifié de ces sessions. Dans l'exemple, l'utilisateur A autorise le serveur de notification SN à lui notifier, sur son terminal TAl, les sessions de type VoD de tous ses amis (mot-clef ALL). Dans le mode de réalisation décrit ici, les terminaux à notifier sont enregistrés sous un format UTILISATEUR.TERMINAL
De façon similaire, la figure IB représente le profil PB de l'utilisateur B.
Dans le cas particulier décrit ici, nous supposerons que l'utilisateur UB a souscrit à un service de continuité de service, tel que défini dans le document TS 23.838 du 3GPP, ce service permettant de transférer les sessions entre les terminaux TBl, TB2 de cet utilisateur.
De façon connue, un serveur d'application SCC AS (Service Centra I ization and Continuity Application Server) est plus particulièrement en charge de la continuité des sessions, ce serveur étant défini dans le document TS 23.237 V9.0.0 du 3GPP.
Dans le mode de réalisation de l'invention décrit ici, on propose, lorsqu'un utilisateur souscrit à un service de continuité de service dans riMS, que le serveur de notification SN obtienne les caractéristiques des sessions de cet utilisateur auprès du serveur SCC AS gérant la continuité des sessions pour cet utilisateur.
L'interrogation d'un serveur SCC AS pour obtenir la liste des sessions en cours est décrite dans le document DOCl déjà mentionné.
On notera, dans la sixième section Sectβ du profil PB, que l'utilisateur UB souhaite être notifié sur son terminal TBl, des caractéristiques des sessions de type VoD ou VoIP de tous ses amis (mot- clef « ALL »), à savoir ici de l'utilisateur UA.
La figure IC représente une table TU comportant, dans un champ SUBSCRIBERJJSERJD, l'identifiant d'un utilisateur abonné au service de notification et dans un champ PRES_SERV l'identifiant d'un serveur de présence de cet utilisateur. Le serveur de notification SN peut interroger cette table pour connaître les abonnés au service de notification de session effectivement présents dans le réseau.
La figure 2 représente l'architecture matérielle du terminal TAl, celle du terminal TBl, TB2 étant similaire.
Dans l'exemple de réalisation décrit ici, le terminal TAl a l'architecture matérielle d'un ordinateur. Il comporte notamment un processeur 10, une mémoire morte de type ROM 11, une mémoire vive de type RAM 12, des moyens de communication 13 et un écran 14. La mémoire ROM 11 constitue un support d'enregistrement conforme à l'invention. Elle comporte un programme d'ordinateur PGl comprenant des instructions pour l'exécution des étapes Exxx d'un procédé d'établissement d'une session d'accès à un service conforme à l'invention, ces étapes étant sera décrites ultérieurement en référence à aux figures 6A et 6B. La mémoire RAM 12 permet l'exécution du programme PGl par le processeur 10.
Dans le mode de réalisation décrit ici, le programme d'ordinateur PGl est apte à mettre en œuvre les fonctions logicielles suivantes : - mise en œuvre des fonctions nécessaires à la gestion du protocole de signalisation SIP (notamment envoi et réception des messages SIP INVITE et BYE tels que définis dans le document RFC 3261 et mis à jour dans les documents RFC 3265, 3853 et 4320) ;
- définition du profil PA et enregistrement de ce profil dans la base de données BD ;
- réception d'un message de notification du serveur de notification SN comportant les caractéristiques des sessions définies dans la deuxième section Sect2 du profil de ses amis, en l'espèce P6 ;
- affichage sur l'écran 14 de ces caractéristiques ; et - établissement d'une session d'accès à un service à partir de ces caractéristiques.
On notera que dans l'exemple de la figure 2, le programme d'ordinateur PGl permet aussi d'afficher, sur l'écran 14 du terminal TAl, les caractéristiques des sessions de l'utilisateur UA. La figure 3 représente un réseau 1 conforme à l'invention. Dans le mode de réalisation décrit ici, ce réseau 1 est conforme à l'architecture
IMS.
Dans l'exemple de réalisation décrit ici, le réseau 1 comporte les deux serveurs d'application ASl et AS2 mentionnés ci-dessus, dans lesquels :
- le serveur d'application ASl est apte à rendre un service Sl de vidéo à la demande « VoD », ce service permettant à un terminal client d'accéder, soit en direct, soit en différé, dans une plage de temps déterminée, à des fichiers vidéo hébergés par un serveur vidéo SV ; et. - le serveur d'application AS2 est apte à rendre un service S2 de voix sur IP.
Dans l'exemple de réalisation décrit ici, les deux terminaux TBl, TB2 de l'utilisateur UB sont connectés au même serveur SCC AS, cet utilisateur ayant souscrit à un service de continuité de sessions. De façon connue, chacun des terminaux TAl, TBl, TB2 comporte des moyens pour s'enregistrer dans le réseau 1 auprès d'un équipement S-CSCF (Serving CaII Session Control Function).
Pour accéder à un service particulier, un terminal TAl, TBl, TB2 envoie une requête SIP INVITE, celle-ci étant traitée par l'équipement S- CSCF, puis validée en fonction d'un profil de l'utilisateur de ce terminal enregistré dans une entité HSS (Home Subscriber Server).
Si la requête SIP INVITE est validée par le S-CSCF, elle est redirigée vers le serveur d'application ASl, AS2 en charge du service concerné. Dans le mode de réalisation décrit ici, la table TU et la base de données BD dans laquelle sont enregistrés les profils PA, PB sont co- localisées avec l'entité HSS. En variante, elles pourraient notamment être co-localisées avec le serveur de notification SN.
En particulier le profil propre à l'invention et le profil géré par l'entité HSS peuvent être regroupés dans une même structure de données.
Dans cet exemple, chacun des terminaux TAl, TBl, TB2 comporte des moyens pour publier sa présence auprès d'un serveur de présence SP, ce serveur pouvant être interrogé par le serveur de notification selon l'invention. Dans le mode de réalisation décrit ici, la table TU comporte un champ PRES_SERV dans lequel le serveur de présence SP utilisé par cet utilisateur est enregistré.
A la figure 3, on a représenté une table de présence TP dans laquelle le serveur de présence SP enregistre les terminaux présents dans le réseau.
La figure 4 représente l'architecture matérielle d'un serveur d'application selon l'invention, par exemple celle du serveur ASl. Dans l'exemple de réalisation décrit ici, ce serveur a l'architecture matérielle d'un ordinateur. Il comporte notamment un processeur 12, une mémoire morte de type ROM 21, une mémoire vive de type RAM 22 et des moyens de communication 23.
La mémoire ROM 21 constitue un support d'enregistrement conforme à l'invention. Elle comporte un programme d'ordinateur PG2 comprenant des instructions pour l'exécution des étapes Gxxx d'un procédé, conforme à l'invention, pour mettre en œuvre un service d'accès propre à ce serveur, ces étapes étant décrites ultérieurement en référence aux figures 6A et 6B.
La mémoire RAM 22 permet l'exécution du programme PG2 par le processeur 20. Dans le mode de réalisation décrit ici, le programme d'ordinateur
PG2 est apte à mettre en œuvre les fonctions logicielles suivantes :
- mise en œuvre des fonctions nécessaires à la gestion du protocole de signalisation SIP ;
- mise en œuvre du service de vidéo à la demande ; et - notification, au serveur de notification SN des caractéristiques des sessions d'accès au service de type VoD par l'utilisateur UA, UB.
La figure 5 représente l'architecture matérielle du serveur de notification SN. Dans l'exemple de réalisation décrit ici, ce serveur a l'architecture matérielle d'un ordinateur. Il comporte notamment un processeur 30, une mémoire morte de type ROM 31, une mémoire vive de type RAM 32 et des moyens de communication 33.
La mémoire ROM 31 constitue un support d'enregistrement conforme à l'invention. Elle comporte un programme d'ordinateur PG3 comprenant des instructions pour l'exécution des étapes Fxxx d'un procédé d'accès à un service, conforme à l'invention, ces étapes étant décrites ultérieurement en référence aux figures 6A et 6B.
La mémoire RAM 32 permet l'exécution du programme PG3 par le processeur 30.
Dans le mode de réalisation décrit ici, le programme d'ordinateur PG3 est apte à mettre en œuvre les fonctions logicielles suivantes :
- mise en œuvre des fonctions nécessaires à la lecture des messages de notification de création/modification/terminaison de sessions issus des modules (AS, terminaux) de récupération de caractéristiques de sessions ; - interrogation de la base de données BD pour connaître les utilisateurs UA, UB inscrits au service de notification de sessions. Dans l'exemple de réalisation décrit ici, cette information peut être obtenue dans le champ SUBSCRIBER_USER_ID de la table TU ;
- abonnement auprès du serveur de présence SP auprès duquel un utilisateur publie sa présence afin de recevoir un message de notification de ce serveur SP dès que cet utilisateur UA rejoint ou quitte le réseau 1. Dans l'exemple de réalisation décrit ici, le serveur de notification SN obtient l'identité du serveur de présence dans le champ PRES_SERV de la table TU ;
- identification des services auxquels un utilisateur a souscrit (champ SERVICEJD) et du module de récupération des caractéristiques de session désigné pour les sessions d'accès à ces services (champ MODULE) à partir du profil utilisateur PA;
- obtention des caractéristiques de ces sessions, soit par interrogation des profils PA, PB, soit par mécanisme de souscription/notification auprès des modules précités ;
- obtention de la liste des terminaux auxquels les caractéristiques des sessions doivent être notifiées (champs TERM de la sectionSectβ).
En référence à la figure 6A, nous allons maintenant décrire un exemple de mise en œuvre du système de notification de sessions de la figure 3.
Au cours d'une étape ElO, les utilisateurs UA et UB utilisent un de leurs terminaux TAl, TBl pour définir et enregistrer leur profil PA, PB dans la base de données DB. Une entrée est ajoutée, pour chaque utilisateur, dans la table TU des utilisateurs abonnés au service de notification. Cette entrée identifie l'utilisateur abonné et son serveur de présence.
Au cours d'une étape FlO, le serveur de notification SN interroge la base de données BD et identifie, dans le champ SUBSCRIBER_USER_ID de la table TU , les deux utilisateurs UA et UB. Il identifie également, dans le champ PRES_SERV, que ces deux utilisateurs publient leur présence sur le réseau 1 auprès du serveur de présence SP.
Au cours d'une étape F20, le serveur de notification SN souscrit auprès du serveur de présence SP pour être notifié de l'entrée des terminaux des utilisateurs UA, UB dans le réseau, ou de leur sortie.
On suppose, que le terminal TAl de l'utilisateur UA s'enregistre dans le réseau IMS au cours d'une étape E20, et qu'il publie sa présence auprès du serveur de présence SP au cours d'une étape E30.
Le serveur de notification reçoit, au cours d'une étape F30 un message de notification du serveur de présence SP l'informant de l'arrivée du terminal TAl de l'utilisateur UA sur le réseau. Le serveur de notification SN interroge alors, au cours d'une étape
F40, la base de données DB pour obtenir le profil PA de l'utilisateur UA. Au cours d'une étape F50, le serveur de notification obtient alors, dans le champ MODULE du profil PA, la liste des modules de récupération des caractéristiques des services VoD et VoIP auxquels l'utilisateur UA a souscrit. Dans l'exemple de réalisation décrit ici, il s'agit des serveurs d'applications ASl, AS2 gérant des services.
Au cours d'une étape F60, il souscrit auprès de ces serveurs d'application ASl, AS2 pour être notifié de tout événement (création, modification, terminaison) sur une session gérée par ces serveurs à laquelle participe l'utilisateur UA. Ces messages de souscription sont reçus par chacun des serveurs ASl, AS2 au cours d'une étape G62.
Au cours d'une étape F70, le serveur de notification SN obtient la liste des amis de l'utilisateur UA, soit UB, en lisant la section Sect3 du profil PA. En analysant la section Sectβ du profil PA, le serveur de notification SN détermine les sessions pour lesquelles l'utilisateur UA souhaite être notifié. Il en déduit que l'utilisateur UA souhaite être notifié des sessions de type VoD ou VoIP de l'utilisateur UB.
Au cours d'une étape F80, il interroge la base de données pour connaître les sessions de type VoD ou VoIP de l'utilisateur UB.
Au cours d'une étape F82, le serveur de notification SN vérifie si des sessions de l'utilisateur UB sont à notifier. L'utilisateur UB n'a aucune session. Le SN envoie un message au terminal UAl de l'utilisateur UA qui indique que l'utilisateur ami UB n'annonce aucune session.
Nous supposerons que l'utilisateur UA démarre, au cours d'une étape E90, une session pour accéder au service de vidéo à la demande. Dans le mode de réalisation décrit ici, ceci se traduit par l'envoi d'une requête de signalisation SIP de type INVITE, cette requête étant analysée puis redirigée par le S-CSCF à destination du serveur d'application ASl gérant ce service.
Nous supposerons que le serveur d'application ASl reçoit cette requête SIP INVITE au cours d'une étape GlOO.
Dans le mode de réalisation décrit ici, le serveur d'application ASl annonce cette session au serveur de notification SN au cours d'une étape GIlO par l'envoi d'un message de notification.
Ce message de notification comporte les caractéristiques de la session. Il est reçu par le serveur de notification SN au cours d'une étape
F120. Il ajoute dans la section Sect2 du profil PA une entrée concernant cette nouvelle session. Il l'identifie par Sl dans le champ SESS_ID et enregistre ses caractéristiques dans le champ SESS_CHAR. Ses caractéristiques sont:
• Type : VoD • Status: Programmée
• Date de début de la session prévue et date de fin de la session prévue
• La source du flux SV
• Le serveur d'application AS en charge de la session • La date limite d'annonce de la session. A noter que cette date limite peut être indiquée par le serveur d'application 'AS ayant notifié le serveur de notification SN ou, si elle n'est pas indiquée, être déterminée en lisant le champ NOTIF_END_DEFAULT de la section Sect4 du profil PA pour le service de type VoD identifié dans cette même section par le champ SERVICEJD.
Dans l'exemple décrit ici, le serveur de notification SN vérifie, au cours d'une étape F130, s'il existe un conflit quant à la notification, à l'utilisateur UB, des caractéristiques de la session Sl. En l'espèce ce n'est pas le cas, car :
- l'utilisateur UA souhaite que son ami UB soit notifié des caractéristiques de la session Sl (conjointement section Sect3 et section Sect5 du profil PA), la date limite d'annonce n'étant pas atteinte; et
- l'utilisateur UB souhaite être notifié, sur son terminal TBl, des caractéristiques des sessions de type VoD de l'utilisateur UA
(conjointement section Sect3 et section Sectβ du profil PB).
Au cours d'une étape F140, le serveur de notification SN vérifie, si l'utilisateur UB est présent sur le réseau.
Comme ce n'est pas le cas dans cet exemple, le procédé de notification de sessions s'arrête.
Nous continuons la description de cet exemple en référence à la figure 6B.
On suppose, que le terminal TBl de l'utilisateur UB s'enregistre (étape E20) dans le réseau IMS et qu'il publie sa présence (étape E30) auprès du serveur de présence SP. Ces étapes sont identiques aux étapes E20 et E30 décrites précédemment en référence à la figure 6A. Le serveur de notification reçoit, au cours d'une étape F30 un message de notification du serveur de présence SP l'informant de l'arrivée du terminal TBl sur le réseau.
Le serveur de notification SN interroge alors, au cours d'une étape F40, la base de données DB pour obtenir le profil PB de l'utilisateur UB.
Au cours d'une étape F50, le serveur de notification SN obtient alors, dans le champ MODULE de la section Sect4 du profil PB, un identifiant du module de récupération de caractéristiques des sessions des services auxquels a souscrit l'utilisateur UB. En l'espèce, l'utilisateur UB a souscrit au service de vidéo à la demande, ce service étant géré par le serveur SCC AS, l'utilisateur UB ayant souscrit à un service de continuité de session.
Au cours d'une étape F60, le serveur de notification SN souscrit auprès du serveur SCC AS pour être notifié de tout événement (création, modification, terminaison) sur une session gérée par ce serveur. Ce message de souscription est reçu par le serveur SCC AS au cours d'une étape G62.
Au cours d'une étape F70, le serveur de notification FN obtient la liste des amis de l'utilisateur UB, soit UA, en lisant la section Sect3 du profil P6. En analysant la section Sectβ du profil PBf le SN détermine les caractéristiques des sessions pour lesquelles l'utilisateur UB souhaite être notifié. Il en déduit que l'utilisateur UB souhaite être notifié des sessions de type VoD ou VoIP de l'utilisateur UA.
Au cours d'une étape F80, il interroge la base de données pour connaître les sessions de type VoD ou VoIP de l'utilisateur UA. Il obtient dans la section Sect2 du profil PA, la liste des sessions de l'utilisateur UA, à savoir une session Sl de VoD et une session S2 de VoIP.
Le serveur de notification SN vérifie si l'utilisateur UA autorise UB à être notifié de ces sessions. Pour cela, il lit la section Sect5 du profil PA qui indique l'audience permise en fonction de critères sur les sessions.
Cette section indique que seules les sessions de type VoD peuvent être communiquées, en l'occurrence à tous les amis de l'utilisateur UA. Le serveur de notification SN vérifie que l'utilisateur UB appartient aux amis de l'utilisateur UA, en lisant la section Sect3 du profil PA OÙ apparaît bien UB. Dans l'exemple de réalisation décrit ici, le serveur de notification SN peut envoyer un message de notification à l'utilisateur UB pour lui fournir les caractéristiques de la session Sl de l'utilisateur UA. Le serveur de notification SN analyse alors la section Sectβ du profil PB pour connaître les préférences de l'utilisateur UB sur la réception des messages de notification. Dans cette section, l'utilisateur UB indique qu'il demande à être notifié des sessions de type VoD sur son terminal TBl.
L'utilisateur UB étant connecté via son terminal TBl, le SN envoie le message de notification. Ce message de notification est reçu par le terminal TBl au cours d'une étape E84, les caractéristiques de la session étant affichées sur l'écran 14 de ce terminal au cours de cette même étape.
Nous supposerons que l'utilisateur UB démarre, au cours d'une étape E90, une session pour accéder au service de vidéo à la demande. Dans le mode de réalisation décrit ici, ceci se traduit par l'envoi d'une requête de signalisation SIP de type INVITE, cette requête étant analysée puis redirigée par le S-CSCF à destination du serveur SCC-AS, l'utilisateur UB ayant souscrit à un service de continuité de session.
Le serveur d'application SCC AS reçoit cette requête SIP INVITE au cours d'une étape GlOO.
Le serveur d'application SCC AS annonce cette session au serveur de notification SN au cours d'une étape GIlO par l'envoi d'un message de notification.
Ce message de notification comporte les caractéristiques de la session. Il est reçu par le serveur de notification SN au cours de l'étape F120.
Le serveur de notification SN ajoute dans la section Sect2 du profil PB une entrée concernant cette nouvelle session. Il l'identifie par S3 dans le champ SESSJD et enregistre ses caractéristiques dans le champ SESS_CHAR. Ses caractéristiques sont:
• Type : VoD
• Status: Active
• Date de début de la session prévue et date de fin de la session prévue « La (ou les) source du flux
• L'AS en charge de la session • La date limite d'annonce de la session. A noter que cette date limite peut être indiquée par l'AS ayant notifié le SN ou, si elle n'est pas indiquée, être déterminée en lisant le champ NOTIF_END_DEFAULT de la section Sect4 du profil P8 pour le service de type VoD identifiée dans cette même section par le champ SERVICEJD.
Dans l'exemple décrit ici, le serveur de notification SN détermine que la date limite de la nouvelle session n'est pas atteinte. Il détermine alors l'audience de la notification de cette session.
Pour cela, il analyse conjointement les sections Sect3 et Sect5 du profil PB et détermine que l'utilisateur UA doit être notifié.
Le serveur de notification SN analyse alors la section Sectβ du profil PA de l'utilisateur UA et détermine que l'utilisateur UA autorise tous ses amis à le notifier de leurs sessions de VoD sur son terminal TAl. L'utilisateur faisant partie des amis de l'utilisateur UA, d'après la section Sect3 du profil PA, le serveur de notification SN peut donc notifier la session S3 de l'utilisateur UB auprès du terminal TAl de l'utilisateur UA.
Au cours d'une étape F140, le serveur de notification SN vérifie, si l'utilisateur UA est présent sur le réseau avec son terminal TAl.
Puisque c'est le cas, le serveur de notification SN envoie, au cours d'une étape F160, les caractéristiques de la session S3 de l'utilisateur UB au terminal TAl de l'utilisateur UA.
Ce message de notification est reçu par le terminal TAl au cours d'une étape E160, les caractéristiques de la session étant affichées sur l'écran 14 de ce terminal au cours de cette même étape. II a précédemment été expliqué en détails comment les caractéristiques d'une session d'un premier utilisateur pouvaient être notifiées à un deuxième utilisateur.
Suite à cette notification, le deuxième utilisateur peut (étape E180) par exemple décider de se joindre à la session, si cette session est active. A titre d'exemple, les caractéristiques d'une session peuvent comprendre l'adresse multicast d'un groupe de diffusion, le deuxième terminal ayant alors la possibilité de se joindre à ce groupe.
Dans le mode particulier de réalisation dans lequel le premier utilisateur a souscrit à un service de continuité de session, il peut être intéressant de placer l'identifiant du serveur SCC AS dans les caractéristiques de la session notifiées à un deuxième utilisateur. Le deuxième utilisateur peut ainsi établir une communication avec ce SCC AS, ce serveur étant alors utilisé pour transférer des flux entre les terminaux de deux utilisateurs différents. L'invention permet autrement dit d'étendre le mécanisme contrôleur/contrôlé décrit dans le document TR 23.828 et limité au transfert de session entre les terminaux d'un même utilisateur, au transfert de session entre les terminaux d'utilisateurs différents.
Le deuxième utilisateur peut aussi (étape E180) décider d'établir sa propre session. Par exemple, dans le cas d'une session programmée pour accéder à une vidéo, le deuxième utilisateur peut télécharger cette vidéo en streaming, de façon totalement indépendante d'un éventuel accès à cette vidéo par le premier utilisateur.
L'invention a précédemment été décrite dans le contexte d'un réseau SIP. Elle peut s'appliquer dans tout autre type de réseau proposant un protocole de signalisation permettant de clairement définir le début et la fin d'une session entre deux entités.
Dans le mode de réalisation décrit ici, les sessions d'un utilisateur sont présentées sur les terminaux de cet utilisateur.
Pour cela, chaque terminal peut maintenir la liste à jour de ses sessions sur la base des flux qu'il reçoit. En variante, un terminal peut aussi interroger le serveur d'application AS qui gère ses sessions, comme défini dans le document DOCl déjà mentionné.
Dans un autre mode de réalisation, il suffit d'enregistrer un terminal d'un utilisateur dans la section Sectβ du profil de cet utilisateur, pour que ce terminal soit notifié des sessions de cet utilisateur.

Claims

REVENDICATIONS
1. Système de notification de sessions caractérisé en ce qu'il comporte :
- un serveur de notification (SN) comportant des moyens d'obtention d'un profil (PA) d'un premier utilisateur (UA), ce profil comportant au moins un identifiant d'un module (ASl, AS2, SCC AS) de récupération des caractéristiques d'une session (Sl) d'accès à un service par ledit premier utilisateur (UA) et un identifiant d'un deuxième utilisateur (UB) ;
- ledit module (ASl) comportant des moyens (23) pour envoyer audit serveur de notification (SN) un message comportant les caractéristiques de ladite session (Sl) ;
- ledit serveur de notification (SN) comportant des moyens (33) pour envoyer lesdites caractéristiques de cette session (Sl) à un terminal (TBl) dudit deuxième utilisateur (UB).
2. Système de notification de sessions selon la revendication 1, dans lequel ledit module est un serveur d'application (ASl, AS2, SCC AS) apte à rendre ledit service.
3. Système de notification de sessions selon la revendication 2, dans lequel ledit serveur d'application est un serveur (SCC AS) apte à rendre un service de continuité de session entre au moins deux terminaux (TBl, TB2) dudit premier utilisateur connectés à ce serveur, caractérisé en ce que ledit serveur d'application (SCC AS) envoie en outre, dans ledit message, les caractéristiques d'une autre session dudit premier utilisateur (UB).
4. Procédé de notification de sessions pouvant être mis en œuvre par un serveur de notification (SN) dans un réseau de télécommunications comportant :
- une étape (FlO) d'obtention d'un profil (PA) d'un premier utilisateur (UA), ce profil comportant au moins (Sect4) : - un identifiant d'un module (ASl, AS2, SCC AS) de récupération des caractéristiques d'une session (Sl) d'accès à un service par ledit premier utilisateur (UA) ; et
- un identifiant d'un deuxième utilisateur (UB) ; - une étape (F82) d'obtention, en provenance dudit module, des caractéristiques d'une session (Sl) d'accès audit service par un terminal (TAl) dudit premier utilisateur (UA) ;
- une étape (F82) d'envoi, à un terminal (TBl) dudit deuxième utilisateur (UB) d'un message de notification comportant lesdites caractéristiques.
5. Procédé de notification de sessions selon la revendication 4, caractérisé en ce qu'il comporte une étape d'enregistrement desdites caractéristiques dans ledit profil (PA).
6. Procédé de notification de sessions selon la revendication 4, caractérisé en ce qu'il comporte une étape (F60) de souscription dudit serveur de notification (SN) auprès dudit module (ASl), pour obtenir (F120) lesdites caractéristiques dans un message de notification dudit module (ASl).
7. Procédé de notification de sessions selon la revendication 4, dans lequel ledit profil (PA) du premier utilisateur (UA) comporte en outre (Sect2) un identifiant d'une session (Sl) d'accès à un service par ledit deuxième utilisateur (UB), ledit procédé étant caractérisé en ce qu'il comporte :
- une étape (F120) d'obtention des caractéristiques de ladite session dans un profil (PB) dudit deuxième utilisateur ; et
- une étape (E170) d'envoi, à un terminal (TAl) du premier utilisateur (Ul), d'un message de notification comportant lesdites caractéristiques.
8. Procédé de notification de sessions selon la revendication 4, caractérisé en ce qu'il comporte une étape (F20) de souscription dudit serveur de notification (SN) auprès d'un serveur de présence (SP), afin d'être notifié de la présence du premier utilisateur (UA) et/ou du deuxième utilisateur (UB) dans le réseau.
9. Serveur de notification (SN) dans un réseau de télécommunications comportant :
- des moyens (33) d'obtention d'un profil (PA) d'un premier utilisateur (UA), ce profil comportant au moins (Sect4) : - un identifiant d'un module (ASl, AS2, SCC AS) de récupération des caractéristiques d'une session (Sl) d'accès à un service par ledit premier utilisateur (UA) ; et - un identifiant d'un deuxième utilisateur (UB) ;
- des moyens (10) d'obtention, en provenance dudit module, des caractéristiques d'une session (Sl) d'accès audit service par un terminal
(TAl) dudit premier utilisateur (UA) ; et
- des moyens (33) d'envoi, à un terminal (TBl) dudit deuxième utilisateur (UB), d'un message de notification comportant lesdites caractéristiques.
10. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de notification selon l'une quelconque des revendications 4 à 8 lorsque ledit programme est exécuté par un ordinateur.
11. Procédé de mise en œuvre d'un service dans un réseau de télécommunications comportant :
- une étape (G62) de réception d'un message de souscription en provenance d'un serveur de notification (SN) ; et
- une étape (GIlO) d'envoi, audit serveur de notification (SN), d'un message de notification comportant les caractéristiques d'une session (Sl) d'accès audit service par un utilisateur (UA).
12. Serveur d'application (ASl) apte à rendre un service à un utilisateur dans un réseau de télécommunications, caractérisé en ce qu'il comporte ;
- des moyens (23) de réception d'un message de souscription en provenance d'un serveur de notification (SN) dudit réseau ; et
- des moyens (23) d'envoi, audit serveur de notification (SN), d'un message de notification comportant les caractéristiques d'une session (Sl) d'accès audit service par ledit utilisateur (UA).
13. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de mise en œuvre d'un service dans un réseau de télécommunications selon la revendication 11 lorsque ledit programme est exécuté par un ordinateur.
14. Procédé d'établissement d'une première session (Sl) d'accès à un service auprès d'un serveur d'application (ASl) dans un réseau de télécommunication, ce procédé étant mis en œuvre dans un premier terminal (TAl) et caractérisé en ce qu'il comporte : - une étape (E30) de notification de la présence dudit premier terminal (TAl) dans le réseau ; et
- une étape (E170) de réception d'un message de notification comportant les caractéristiques d'une deuxième session d'accès audit service par un deuxième terminal (TBl) ; et - une étape (E180) d'établissement de ladite première session à partir desdites caractéristiques.
15. Terminal (TAl) comportant :
- des moyens (13) de notification de la présence dudit terminal (TAl) dans un réseau de télécommunications ; et
- des moyens (13) de réception d'un message de notification comportant les caractéristiques d'une session d'accès, par un autre terminal (TBl), à un service auprès d'un serveur d'application (ASl) dans ledit réseau ;
- des moyens (13) pour établir une session d'accès audit service à partir desdites caractéristiques.
16. Terminal selon la revendication 15, caractérisé en ce qu'il comporte :
- des moyens (13) de réception d'un message de souscription en provenance d'un serveur de notification (SN) ; et
- des moyens (13) d'envoi, à ce serveur de notification, d'un message de notification comportant les caractéristiques d'une session (Sl) d'accès à ce service par un utilisateur de ce terminal.
17. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé d'accès à un service dans un réseau de télécommunications selon la revendication 14 lorsque ledit programme est exécuté par un ordinateur.
PCT/FR2010/051074 2009-06-03 2010-06-02 Systeme de notification de sessions dans un reseau de telecommunications WO2010139898A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0953652 2009-06-03
FR0953652 2009-06-03

Publications (1)

Publication Number Publication Date
WO2010139898A1 true WO2010139898A1 (fr) 2010-12-09

Family

ID=41531591

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2010/051074 WO2010139898A1 (fr) 2009-06-03 2010-06-02 Systeme de notification de sessions dans un reseau de telecommunications

Country Status (1)

Country Link
WO (1) WO2010139898A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2506535A1 (fr) * 2011-03-31 2012-10-03 France Telecom Procédé de gestion de session applicative

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TR23838A (tr) 1988-06-18 1990-09-25 Henkel Kgaa Alüminyum ve alüminyum alasimlarinin üzerinde anodize edilmis oksit tabakalarinin yogunlastirilmasina mahsus usul
US20020075305A1 (en) * 2000-12-18 2002-06-20 Beaton Brian F. Graphical user interface for a virtual team environment
EP1330098A1 (fr) * 2002-01-21 2003-07-23 BRITISH TELECOMMUNICATIONS public limited company Procédé et système de communication pour le transfert des sessions Web
US20070282990A1 (en) * 2006-05-31 2007-12-06 Vijay Pochampalli Kumar Context-aware migration of communication session

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TR23838A (tr) 1988-06-18 1990-09-25 Henkel Kgaa Alüminyum ve alüminyum alasimlarinin üzerinde anodize edilmis oksit tabakalarinin yogunlastirilmasina mahsus usul
US20020075305A1 (en) * 2000-12-18 2002-06-20 Beaton Brian F. Graphical user interface for a virtual team environment
EP1330098A1 (fr) * 2002-01-21 2003-07-23 BRITISH TELECOMMUNICATIONS public limited company Procédé et système de communication pour le transfert des sessions Web
US20070282990A1 (en) * 2006-05-31 2007-12-06 Vijay Pochampalli Kumar Context-aware migration of communication session

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2506535A1 (fr) * 2011-03-31 2012-10-03 France Telecom Procédé de gestion de session applicative
FR2973620A1 (fr) * 2011-03-31 2012-10-05 France Telecom Procede de gestion de session applicative

Similar Documents

Publication Publication Date Title
EP2412141B1 (fr) Procédé et dispositif de traitement d'une information indicatrice d'un souhait d'implication dans au moins une session applicative d'un utilisateur
EP2381683A1 (fr) Procédé et système de gestion d'une session de diffusion en continu d'un flux vidéo affiché en direct
EP2708002B1 (fr) Procédé de traitement d'une requête de basculement d'une communication entre deux réseaux d'accès
EP2882161B1 (fr) Procédé et dispositf d' établissement d'une communication
FR3034608A1 (fr) Procede de priorisation de flux medias dans un reseau de communications
EP2353278B1 (fr) Procede de gestion d'un utilisateur dans un reseau de telecommunications, et dispositif associe
WO2010139898A1 (fr) Systeme de notification de sessions dans un reseau de telecommunications
EP3158709A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP2073493B1 (fr) Procédé de communication multimédia, serveur et produit programme d'ordinateur correspondants
EP3646578B1 (fr) Procédé de synchronisation d'état média
EP2859704B1 (fr) Serveur d'application et procede de traitement d'un message destine a une identite publique partagee par une pluralite de dispositifs
EP3472993A1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
EP3632078B1 (fr) Procédé de contrôle d'une communication comprenant des transactions multiples
WO2015181505A1 (fr) Procédé pour informer une entité d'un réseau ip du type de réseau d'accès utilisé par un terminal
EP2238727B1 (fr) Procédé de communication pour gérer des sessions de communication au niveau d'une passerelle domestique
FR2927491A1 (fr) Procede et dispositif de transfert d'un signal de flux multimedia au cours d'une session de communication
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
EP2262196A1 (fr) Procédé et dispositif de gestion de communications électroniques sécurisées en milieu hétérogène
FR2855703A1 (fr) Systeme de messagerie vocale pour les internautes
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
FR2974964A1 (fr) Continuite de service inter-terminal dans un reseau de telecommunications
WO2004100517A2 (fr) Couplage automatique d'applications entre utilisateurs et telephonie
FR2988951A1 (fr) Procede d'enregistrement d'un serveur aupres d'une pluralite de coeurs de reseau, et serveur.

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: 10734211

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10734211

Country of ref document: EP

Kind code of ref document: A1