Patent Application
20080096599
The invention and its characteristics will become clearer after reading the description of embodiments given below.
In the example in
The communication client N can communicate with one or several other communication clients B, C through this communication network N.
In a manner known in itself, a communication terminal can be connected to the communication network through an up channel to transmit data (voice, video, etc.) from the communication client user, to the communication network N; a down channel for reception of data from the network (and generally indirectly from another communication client) ; and a signal channel used for two-directional transmission of signal messages between the communication client and the network N.
Communication clients are typically communication terminals provided with sound production and acquisition circuits for setting up a “voice” type communication session. They may also be provided with more advanced means such as screens, cameras, etc., for setting up a multimedia communication session (video, etc.).
The sound production circuit is typically a loud speaker or a headset for producing a sound signal representative of data received on the down communication channel.
The sound acquisition circuit is typically a microphone designed to produce data that are then transmitted to the communication network through the up communication channel.
Communication clients A, B, C also have signal interfaces to send and receive signal messages on the signal channel, connecting them to the communication network N.
These signal interfaces may comply with the SIP protocol as defined in RFC 3261 of the IETF (Internet Engineering Task Force) and possibly with extensions to this SIP protocol defined later by the IETF or other standardisation organisations.
The communication client A sends an invitation signal message MI to the communication network N, so as to set up a “PoC” type communication session (“Push to talk over Cellular”).
The communication client A has a man-machine interface that comprises means of ordering the signal interface and triggering transmission of this invitation signal message MI. This man-machine interface is typically composed of a set of keys, possibly in addition to a touch screen, thumbwheels, etc., that the user can use to order and control the communication client. Therefore, the user can use this man-machine interface to trigger initiation of a “PoC” type communication session.
This particular man-machine interface also has means (keys, thumbwheels, etc.) of changing over between a reception mode and a transmission mode, once a “Push to Talk” communication session has been set up. The sound acquisition circuit is inactive in reception mode. The sound production circuit is usually inactive in transmission mode.
The invitation signal message MI may be transmitted to a communication server SC within the communication network. This communication server can understand the content of the invitation signal message MI and, depending on this content, it can transmit it to the called communication clients B and C.
This invitation signal message MI is then an “INVITE” message defined by the IETF RFC 3261.
It comprises a first part ESIP formed by set of SIP headers. These headers contain at least the logical address of the user of the communication client A. They also contain information for routing the invitation message as far as the communication server SC.
The “INVITE” signal message also contains a part P1 containing information describing the set up communication session and used by the different parties to negotiate these parameters. These parameters may for example relate to encoding of media flows to be used, etc.
In a manner known in itself, this part complies with the SDP (“Session Description Protocol”) protocol.
The signal message MI also contains a part P2 also conforming to this SDP protocol, as specified in the standard documents mentioned above issued by the OMA. This part P2 contains the logical addresses of the invited communication clients.
The code given below is an illustrative example of an invitation signal message conforming to the SIP protocol and the OMA specifications. The first extract represents ESIP headers of this invitation message. The bold words represent keywords in the SIP protocol grammar and have only been shown in bold to facilitate legibility.
Note the “Content-Type: multipart/mixed” header that means that the invitation message MI is a “multi-party” message, comprising several parts conforming with the SDP protocol (P1 and P2, and P3 that will be described later).
SIP INVITE request
Request-URI sip:PoCConferenceFactoryURI.networkA.net
P-Preferred-Identity: “PoC User A” <sip:PoC-UserA@networkA.net>
Accept-Contact: *;+g.poc.talkburst; require;explicit
User-Agent: PoC-client/OMA1.0 Acme-Talk5000/v1.01
Privacy: id
Contact: <sip: PoC-ClientA.networkA.net>;+g.poc.talkburst
Supported: timer
Session-Expires: 1800;refresher=uac
Allow: INVITE,ACK,CANCEL,BYE,REFER,MESSAGE,SUBSCRIBE,
Content-Type: multipart/mixed
P-Alerting-Mode: MAO
Part P1 conforming to the SDP protocol may be shown in the following form:
Content-Type: application/sdp
c= IN IP6 5555::aaa:bbb:ccc:ddd
a= rtpmap:97 AMR
a= rtcp:5560
m= application 2000 udp TBCP
a= fmtp:TBCP queuing=1; tb_priority=2; timestamp=1
Part P2 also conforming to the SDP protocol may be shown in the following form:
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
As described above, this part P2 contains addresses of called communication clients B, C (“sip:PoC-UserB@networkB.com” and “sip:PoC-UserC@networkC.com”).
The communication server SC is designed to transmit this invitation signal message MI to communication clients B and C as a function of the addresses (“sip:PoC-UserB@networkB.com” and “sip:PoC-UserC@networkC.com”) contained in this message. Therefore in the example shown in
Furthermore, according to the invention, a part P3 is also inserted in the invitation signal message MI sent by the calling communication client A.
This part P3 contains a user's visiting card. It may be stored before in a memory specifically provided for this purpose within the communication client. The communication client can then be designed to automatically insert this visiting card stored in the sent invitation signal messages. A user confirmation may be requested, or a configuration option of this communication client may be used for this automatic insertion.
If a particular communication client could be used by several different users, the memory may store several visiting cards. In this case, the visiting card to be transmitted can be determined automatically when the user makes the connection to the communication client (“login”).
Possibly, several different visiting cards may be provided and stored for a particular user corresponding to different profiles, for example a business card, an individual visiting card, etc.
In all cases, the communication client is provided with means of determining one visiting card among the set of stored visiting cards, before the transmission in a signal message MI.
This visiting card may comply with the vCard format. This vCard format has the merit that it is widely used in emails and thus facilitates interoperability between invitation messages and emails and between applications and services using them.
This vCard (“Versitcard”) format is normalised in version 3.0 by the IETF's RFC 2425 and 2426, called “A MIME Content-Type for Directory Information” and “vCard MIME Directory Profile” respectively.
Obviously, other visiting card specifications are possible, while remaining within the scope of the invention.
The visiting card may contain different items of information about the user of the communication client: his pseudonym or family name, his email, his physical address, telephone numbers, his title and/or professional function, etc.
This part P3 that contains the visiting card may be as follows, in accordance with the SDP protocol:
Content-Type: application/x-vcard
begin:vcard
fn:Smith
n::Smith;Bob
org:Alcatel;
adr:;;Route de Nozay;Marcoussis;;F-91461 Cedex;France
email;internet:Bob.Smith@alcatel.fr
tel;work:+33 (0)1 69 63 xx xx
tel;fax:+33 (0)1 69 63 xx xx
version:2.1
end:vcard
This part P3 contained in the signal message MI is maintained in the signal messages MIB and MIC transmitted by the communication server SC to communication clients B and C respectively.
The communication servers B and C are provided with display means, and particularly a screen. The information contained in the visiting card can then be displayed partially or entirely on the screen. They thus provide the user of the called communication clients with additional information to decide whether or not to accept the invitation.
Some information may be displayed automatically (caller names, etc.), while other information will only be displayed following a specific action by the user (address, etc.). This separation may be dependent on the size of the display screen.
Even if the user of communication client B or C does not know the user of communication client A, he can thus be informed about his name, company, address, etc, and this information may be sufficient for him to make a decision. He can thus filter some incoming calls and possibly set aside unwanted “spamming” type invitations.
He can also mentally and physically prepare himself for an incoming call (by taking out a file, documentation, etc.).
This visiting card received by a communication client may optionally be stored in a memory provided for this purpose and managed by an “address book” type application. This storing and this application enable a user to manage contacts and keep a trace of these contacts.
According to one embodiment of the invention, the visiting cards may also be transmitted by signal messages other than invitation signal messages.
For example, signal messages may be transmitted by a called communication client B to the calling communication client A and/or to the other called communication client C. These signal messages containing the visiting card of the user of communication client B enable communication clients A and C to know this personal information and possibly to store this visiting card among their contacts.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0654332 | Oct 2006 | FR | national |
