WO2007020685A1 - 通信制御方法、コンピュータ・システム、会議管理サーバ、通信方法及び携帯端末 - Google Patents

通信制御方法、コンピュータ・システム、会議管理サーバ、通信方法及び携帯端末 Download PDF

Info

Publication number
WO2007020685A1
WO2007020685A1 PCT/JP2005/014925 JP2005014925W WO2007020685A1 WO 2007020685 A1 WO2007020685 A1 WO 2007020685A1 JP 2005014925 W JP2005014925 W JP 2005014925W WO 2007020685 A1 WO2007020685 A1 WO 2007020685A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
server
conference
image
user
Prior art date
Application number
PCT/JP2005/014925
Other languages
English (en)
French (fr)
Inventor
Hisayuki Morishima
Toru Noda
Akinobu Toda
Original Assignee
Fujitsu Limited
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 Fujitsu Limited filed Critical Fujitsu Limited
Priority to EP05780235A priority Critical patent/EP1916607A4/en
Priority to PCT/JP2005/014925 priority patent/WO2007020685A1/ja
Priority to CN200580050959.5A priority patent/CN101218572B/zh
Priority to JP2007530869A priority patent/JP4707714B2/ja
Publication of WO2007020685A1 publication Critical patent/WO2007020685A1/ja
Priority to US12/068,516 priority patent/US8144185B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
    • 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/40—Support for services or applications
    • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • 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/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • the present invention relates to a communication control technique in an electronic conference.
  • Japanese Patent Application Laid-Open No. 2003-298751 discloses a group call of three or more people in an existing telephone system without requiring significant technical changes in the exchanges and repeaters constituting the telephone system. Techniques for realizing the above are disclosed. That is, caller information including the caller's user ID, phone number, and password and the phone numbers of a plurality of call recipients that the caller wishes to call are registered in advance in a telephone directory database connected to the communication network.
  • the caller database accessing the phonebook database and selecting the call recipient of the caller registered in the phonebook database; and Transmitting the caller's telephone number and the telephone number of the recipient receiver selected by the caller to a call center having a connection means; and the call center sends the call via the simultaneous line connection means. Calling the sender's telephone number and the telephone number of the recipient receiver selected by the sender, Allowing simultaneous calls with multiple call destination recipient said selected.
  • the idea of adding or changing the communication format of the conference on the way is disclosed.
  • Japanese Patent Application Laid-Open No. 2004-13303 discloses a technology that applies instant messaging (IM) technology to an electronic conference.
  • the IM server manages the presence information, available media, and user information of each IM client so that each IM client can acquire such information.
  • the IM server manages the connection between each participating IM client and the IM server, merges the text from each participating IM client, and distributes the result to each participating IM client.
  • the AP server connects to each participating IM client and MD server.
  • the MD server mixes the audio from each participating IM client except the IM client of interest and distributes the results to the IM client of interest. This process is performed for each participating IM client.
  • this gazette only shows general usage of presence technology (offline, during IM !, and how to use the client !, and how to use presence data). Nah ...
  • Patent Document 1 Japanese Patent Laid-Open No. 2003-298751
  • Patent Document 2 JP 2004-13303 A
  • an object of the present invention is to provide a technique for facilitating exchange of image data and the like during a conference in an electronic conference using a mobile terminal.
  • the communication control method is executed by the conference management server, and is performed by the first participant of the voice-based electronic conference with respect to other participants in the voice-based electronic conference.
  • data relating to image distribution is managed as presence data, so that it is possible to distribute images to participants of voice-based electronic conferences using the presence technology.
  • receiving image data from the terminal of the first participant and storing it in a data storage area for image distribution; and in response to receiving the image data, presence of the first participant may further include the step of allowing the presence server to perform data update settings.
  • the presence server By changing the presence data of the first participant, for example, during image distribution! /, Etc., it is automatically distributed as presence data to other participants. It is possible to know the transmission / reception status of image data by participants.
  • the data related to image distribution described above may include user identification information related to image distribution and data related to image distribution resources.
  • the image distribution status of the user may be included in addition to the user identification information.
  • image distribution resources may include IP addresses and port numbers.
  • the setting step described above requests the presence server to register the data related to image distribution as presence data, and the presence to disclose the data related to image distribution as presence data.
  • It may include a step of requesting the server. By doing this, it is possible to easily and flexibly set the delivery destination of data related to image delivery.
  • the first participant power image data is received and stored in the data storage area for image distribution, and in response to the reception of the image data, presence data including data related to image distribution is received. It may further include a step of causing the presence server to perform update setting. For example, by including data indicating completion of image upload by the distribution requester in the data related to image distribution, other participants can know the transmission / reception status of the image data by the first participant.
  • the other participants may be a subset of the participants in the audio-based electronic conference specified by the first participant in the audio-based electronic conference.
  • a computer system includes a presence server having presence management means for performing processing related to presence data, and a conference management server for performing conference control processing. Then, when the conference management server receives the terminal power of the first participant of the voice-based electronic conference, and receives a request for image delivery to the other participants of the voice-based electronic conference, the conference management server As well as A presence setting request is transmitted to the presence server so that the first participant and other participants can subscribe to data related to the image distribution resource.
  • the presence server's presence management means in response to the presence setting request, the first participant and other participants distribute the data related to image distribution resources to the subscribers at the time of update. It is set so that it can be subscribed as presence data.
  • the mobile terminal according to the third aspect of the present invention is distributed from the server when the image data is stored in the terminal power server of the first participant of the voice-based electronic conference, and Image data managed as presence data distributed to subscribers at the time of update
  • the presence data processing unit that receives data related to the resource for distribution, and the data related to the resource for image data distribution after the reception, the image
  • An image processing unit that acquires image data from resources for data distribution.
  • Mobile terminals can also exchange image data during electronic conferences.
  • the portable terminal is distributed from the server when the server receives an image distribution request from the terminal of the first participant of the audio-based electronic conference. Receives information about the image data distribution resource managed as the first presence data distributed to the subscribers at the time of update, and the image data corresponding to the image distribution request is sent from the terminal of the first participant to the server.
  • the presence data processing unit that receives the second presence data relating to the state of the first participant, which is distributed as the above-mentioned storage triggered by being stored, and the first presence data after receiving the second presence data
  • a program for causing a computer to execute the communication control method described above a program for causing a conference management server or presence server to execute the above-described processing, and a portable terminal
  • a program for operating can be created, and the program is stored in a storage medium or storage device such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, and a hard disk. Also, it may be distributed as a digital signal via a network. Intermediate processing results are temporarily stored in a storage device such as a memory.
  • FIG. 1 is a system configuration diagram according to an embodiment of the present invention.
  • FIG. 2 is a functional block diagram of the user terminal.
  • FIG. 3 is a functional block diagram of the user A presence management unit.
  • FIG. 4 is a functional block diagram of the conference A presence manager.
  • FIG. 5 is a schematic diagram of data stored in a presence data storage unit in a user A presence management unit.
  • FIG. 6 is a schematic diagram of data stored in the presence data storage unit in the conference A presence management unit.
  • FIG. 7 is a diagram showing an example of presence data whose presence ID is “FloorUser”
  • FIG. 8 is a diagram showing an example of presence data whose presence ID is “JoinUser”.
  • FIG. 9 is a diagram showing an example of presence data whose presence ID is “Member”.
  • FIG. 10 is a diagram showing an example of presence data whose presence ID is “ChatUser”.
  • FIG. 11 is a diagram showing an example of presence data whose presence ID is “Chat”.
  • FIG. 12 is a diagram showing an example of presence data whose presence ID is “Photo”.
  • FIG. 13 is a diagram showing an example of presence data whose presence ID is “PhotoUser”.
  • FIG. 14 is a diagram showing a first part of the processing flow of one embodiment of the present invention.
  • FIG. 15 is a diagram showing a second part of the processing flow of one embodiment of the present invention.
  • FIG. 16 is a diagram showing a third part of the processing flow of one embodiment of the present invention.
  • FIG. 17 is a diagram showing a fourth part of the processing flow of one embodiment of the present invention.
  • FIG. 18 is a diagram showing a fifth part of the processing flow of one embodiment of the present invention.
  • FIG. 19 is a diagram showing a sixth part of the process flow of one embodiment of the present invention.
  • FIG. 20 is a diagram showing a seventh part of the processing flow of one example of the present invention.
  • FIG. 21 is a diagram showing an eighth part of the processing flow of one embodiment of the present invention.
  • FIG. 22 is a diagram showing a ninth part of the processing flow of one embodiment of the present invention.
  • FIG. 23 is a diagram showing a first part of a processing flow of chat start processing in one embodiment of the present invention.
  • FIG. 24 is a diagram showing a second part of the processing flow of chat start processing in one embodiment of the present invention.
  • FIG. 25 is a diagram showing a third part of the processing flow of chat start processing in one embodiment of the present invention.
  • FIG. 26 is a diagram showing a first part of first to third processing flows of image distribution processing in the embodiment of the present invention.
  • FIG. 27 is a diagram showing a second part of the first processing flow of the image distribution processing in the embodiment of the present invention.
  • FIG. 28 is a diagram showing a second part of the second processing flow of the image distribution processing in the embodiment of the present invention.
  • FIG. 29 is a diagram showing a second part of the third processing flow of the image distribution processing in the embodiment of the present invention.
  • FIG. 30 is a functional block diagram of a computer.
  • FIG. 1 shows a system outline diagram according to one embodiment of the present invention.
  • a plurality of mobile phones here, user terminal A operated by user A and user terminal B operated by user B
  • network 1 which is a mobile phone network via a radio base station (not shown).
  • the mobile phone may be a PHS (Personal Handyphone System) terminal, and it executes various application programs such as a mail client, a web (Web) browser, and a client application in this example, in addition to having a voice call function. can do.
  • the user terminals A and B may be portable terminals such as a PDA (Personal Digital Assistant) with a voice call function.
  • User terminals A and B in the present embodiment will be described later using a functional block diagram.
  • a SIPZSIMPLE server 3, a PoC (Push-to-talk over Cellular) management server 5, and a PoC-MCU (Multipoint Communication Unit) server 7 are connected to the network 1.
  • SIP / SIMPLE server 3 and PoC management server 5 have these functions 1 May be a single server computer.
  • the SIP / SIMPLE server 3 includes a presence management unit 3 la for user A, a presence management unit 31b for user B, a presence management unit 33a for conference A, a presence management unit 33b for conference B, routing And a processing unit 35.
  • a presence management unit 3 la for user A
  • a presence management unit 31b for user B for user B
  • a presence management unit 33a for conference A
  • a presence management unit 33b for conference B routing And a processing unit 35.
  • Figure 1 shows only the presence managers for meetings A and B.
  • the SIPZSIMPLE server 3 also includes processing units that are not directly related to the present embodiment, such as a processing unit that performs user authentication processing.
  • the user presence management unit and the conference presence management unit will be described later using functional block diagrams.
  • the PoC management server 5 is also called a PoC control server, and is a server that controls and manages the electronic conference, and a conference management unit 53 that performs processing for each conference (here, processing for conference A)
  • the conference A management unit 53a and the conference B management unit 53b) that perform processing for the conference B and the message transferred from the routing processing unit 35 of the SIPZSIMPLE server 3 are transferred to the conference management unit 53 in charge.
  • a message distribution processing unit 51 for performing the distribution processing.
  • the conference management unit 53 includes an MCU information storage unit 531 (here, the MCU information storage unit 53 la of the conference A), a user data storage unit 533 (here, the user data storage unit 53 3a of the conference A), an image Data storage unit 535 (here, image data storage unit 535a of conference A).
  • the image data storage unit 535a stores image data to be distributed to the conference A participants.
  • the PoC management server 5 also manages the image data to be distributed to the conference A participants.
  • the PoC-MCU server 7 includes a conference voice communication management unit 71 that manages and controls voice communication for each conference (here, a conference A voice communication management unit 7 la that performs processing for the conference A). And the conference B voice communication management unit 71b) that performs processing for the conference B.
  • the conference voice communication management unit 71 stores the speaker and participant data storage unit 711 (here, the speaker and participant data of the conference A are stored). Part 71 la).
  • a user terminal is connected to a SIP / SIMPLE server 3 and a SIM MPLE (SIP (session Initiation Protocol) for Instant Messaging and Presence Levera via a network 1.
  • SIM MPLE Session Initiation Protocol
  • ZTCP Session Initiation Protocol
  • PUCCH Presence Levera
  • RTP ReaH: ime Transport Protocol
  • FIG. 2 shows a functional block diagram of the user terminal.
  • the user terminal includes a client application 91 for performing processing in the present embodiment, and a microphone driver 93 of a microphone provided in the user terminal.
  • the client application 91 includes an audio conference processing unit 911, a chat processing unit 913, a presence data processing unit 915, and an image processing unit 916.
  • the image processing unit 916 receives an image distribution request from a user, requests a necessary process to a PoC management server, etc., transmits image data itself, and receives image data from the PoC management server 5 Display on the display device. It should be noted that functions that are not directly related to the present embodiment are shown in the figure.
  • FIG. 3 shows a functional block diagram of the presence management unit 31a of the user A.
  • the presence management unit 3 la of the user A has a presence data management unit 311a, a presence data storage unit 313a, and a distribution processing unit 315a.
  • the presence management unit 3 la of the user A updates the data stored in the presence data storage unit 3 13a in cooperation with the client application 91 of the user terminal A, and the data stored in the presence data storage unit 313a. Delivery processing is performed.
  • FIG. 4 shows a functional block diagram of the presence management unit 33a of the conference A.
  • the presence management unit 33a of the conference A has a presence data management unit 33la, a presence data storage unit 333a, and a distribution processing unit 335a.
  • the presence management unit 33a of the conference A updates the data stored in the presence data storage unit 333a in cooperation with the conference A management unit 53a of the PoC management server 5 and the client application 91 of the user terminal, or the presence data. Distribution processing of the data stored in the storage unit 333a is performed.
  • FIG. 5 shows an example of data stored in the presence data storage unit 313a included in the user A presence management unit 3la.
  • the presence data storage unit 313a includes a presence information storage area 3131, a presence group information storage area 3133, and a subscriber list storage area 3135.
  • the presence information storage area 3131 is an area for storing presence data (in this case, user or user terminal state information) for each presence data item, and the presence ID of the presence data item is “State”.
  • Includes an area 316 for storing certain presence data mainly any of ONLINE, OFFLINE, or BUSY, but may be in other states (eg “image delivery” or “Photo Sending”)) .
  • the presence group information storage area 3133 is an area for storing data for associating presence data items (ie, presence IDs) with delivery destination user IDs (ie, subscriber IDs).
  • an area 317 including an area 3171 for storing a presence ID belonging to the group I “default” which is a presence group and an area 3172 for storing a user ID (that is, a subscriber ID) is included.
  • a default group is a group in which subscribers are initially registered. Any number of groups can be defined that is not limited in number of groups.
  • user IDs of users who are permitted to distribute information such as UserB and UserC (that is, subscriber IDs) are registered here. Any number of subscribers can be registered without limitation.
  • FIG. 6 shows an example of data stored in the presence data storage unit 333a included in the conference A presence management unit 33a.
  • a presence information storage area 3331 stores presence data whose presence data item ID is “FloorUser” (here, the subscriber ID of the user who has the right to speak (also referred to as the right to speak)).
  • the presence ID is “JoinUser” and the presence data (in this case, the subscriber ID of the user who participated in the audio conference) is stored in the area 3363 and the presence data item ID is “Chat” Is an area 3364 for storing presence data (here, the content of chat (character-based electronic conference) utterance) and the ID of the presence data item
  • the specified user An area 3366 for storing the upload destination resource of the image data to be distributed to the user, the distribution source resource (for example, the IP address XXX.XXX.XXX and the port number XXXX) or both, and
  • a plurality of address information such as .gif may be included.
  • information specifying the distribution source user may be registered separately from the power address that includes the name of the transmission source user in the file name. If necessary, presence data representing the state may be registered.
  • a plurality of image files may not be distributed simultaneously.
  • the presence group information storage area 3333 includes an area 3371 for storing presence IDs belonging to the group I “default” which is a presence group, and an area 3373 for storing user IDs (that is, subscriber IDs).
  • An area 337 containing the presence ID an area 3381 containing the presence ID belonging to the presence group Group II “Voice Conferencing”, an area 338 containing the user ID (ie subscriber ID), and an area 338 containing the presence ID, III Area 3391 for storing presence ID belonging to “Chat”, Area 339 including area 3392 for storing user ID (ie subscriber ID), and Area for storing presence ID belonging to group IV “Image” which is a presence group 3401 and user ID
  • the subscriber ID of the user participating in the audio conference is stored in area 3382, and the data disclosed to the user participating in the audio conference is the presence ID “FloorUser”, “Member”, and “JoinUser” Presence data. That is, the speaker ID of the speaker's right holder, the subscriber ID list of the called user, and the subscriber ID list of the participating user are presented.
  • the subscriber ID of the user participating in the chat is stored in area 3392, and the data disclosed to the user participating in the chat is the presence data whose presence ID is “Chat” or “ChatUser”.
  • Participant's subscriber ID list and chat utterance contents are presented, and the participant ID of the user participating in the image distribution is stored in area 3402, and the data disclosed to the user participating in the image distribution is Presence data with presence ID “Photo” and presence data with “PhotoUser.”
  • the user ID of the user ie subscriber ID
  • the user ID of the user ie subscriber ID
  • the user to whom the image data is distributed may be a part of the user who participates in the audio conference or all of the users.
  • the presence data whose presence ID is “JoinUser” is used without providing the area 3367 for storing presence data whose presence ID is “PhotoUser”. You can do it. That is, “Photo” and “JoinUser” may be registered in the area 3401 for storing presence IDs belonging to group IV “images”!
  • Presence data with presence ID “Chat” in presence information area 3331 and presence data with presence ID “ChatUser” correspond to group III “chat” 339 in presence group information area 3333
  • the data area of the group related to chat such as Group III “Chat” and Group VI “Chat”, in an identifiable form, respectively. It is possible to provide multiple sets of areas for storing the subscriber IDs of the corresponding chat participants and areas for storing the chat contents. This is the image layout The same is true for the communication, and in the presence data storage unit 333a for one conference, the group data related to the chat such as group IV “image” and group VII “image” can be identified. It is also possible to provide a plurality of sets of areas, areas for storing the subscriber IDs of the corresponding subscribers of image distribution, and areas for storing image distribution resources.
  • FIGS. 5 and 6 schematically show data stored in the presence data storage unit.
  • an area 3361 for presence data whose presence ID is “FloorUser” is shown in FIG.
  • poc.fj.com which is identified by the Uniform Resource Locator (PIP) URL, where the presence data is owned by the conference A management unit 53a of the PoC management server 5, and this presence The data is updated by the conference A manager 53a, and the SIP URL of the conference A manager 53a is Conference01 @ poc.fj. Com, and the speaker between the ⁇ note> and ⁇ Znote> tags.
  • SIP—URL “UserA @ poc. Fj. Com” is registered as the user ID of the rights holder.In Fig. 5 and Fig. 6, "UserA® poc. Show.
  • data having a tag data structure as shown in FIG. 9, for example is stored in the area 3362 for presence data whose presence ID is “Member”.
  • the owner of this presence data is the SIP conference01 @poc. SIP of the user that is specified in the URL and called for the audio conference between the ⁇ note> and ⁇ Znote> tags, UserA@poc.fj.com, UserB@poc.fj.com, U serC@poc.fj.com "is registered as the user ID.
  • data having a tag data structure as shown in FIG. 10 is stored in the area 3365 for presence data whose presence ID is “ChatUser”.
  • the owner of this presence data is specified by the SIP URL Conference01 @ poc.fj.com, and chatting is performed between the ⁇ note> and Znote> tags.
  • the registered user's SIP URL, UserA@poc.fj.com, UserB@poc.fj.com is registered as the user ID.
  • data of a tag data structure as shown in FIG. 11, for example, is stored in an area 3364 for presence data whose presence ID is “Chat”.
  • the owner of this presence data is identified by the SIP URL Conference01 @ poc.fj.com, and chat between ⁇ note> and ⁇ Znote> tags. remarks the contents of the "Hello. ⁇ ⁇ ⁇ " is registered.
  • the owner of this presence data is the conference A manager 53a, which is the same as the other presence data described above, but is stored in the area 3365 for presence data whose presence ID is “ChatUser”. It is assumed that the setting is made so that the update authority is also given to the user with the current user ID.
  • data having a tag data structure as shown in FIG. 13, for example is stored in the area 3366 for presence data whose presence ID is “Photo”.
  • the owner of this presence data is specified by the SIP URL Conference01 @ poc.fj.com, and there is an image between the ⁇ note> and ⁇ Znote> tags.
  • Upload destination resource IP address and port number
  • source resource or both Is registered.
  • Presence data is updated by the owner in principle, and when updated, it is distributed by the distribution processing unit to the user of the user ID associated with the presence ID of the presence data.
  • the conference A management unit 53a and the conference B management unit 53b of the PoC management server 5 have supervisor authority over the presence data in the SIPZSIMPLE server 3 so that necessary presence data can be changed as needed. OK.
  • FIG. All users are logged in to the SIPZSIMPLE server 3 and authenticated. Furthermore, it is assumed that the association between the IP address of the user terminal and the user ID (SIP-URL) is completed in the SIPZSIMPLE server 3.
  • user A operates user terminal A to specify a member to be called for the conference in order to start a voice-based electronic conference, and inputs a call instruction.
  • the audio conference processing unit 911 of the client application 91 in the user terminal A accepts a user operation input regarding a call request of a member to be called for a voice-based electronic conference (step S1), and a list of conference members (for example, a list of SIP URLs).
  • a call request including () is transmitted to the SIP / SIMPLE server 3 (step S3).
  • the routing processing unit 35 of the SIPZSIMPLE server 3 receives the call request including the list of conference members as well as the user terminal A, and when determining that it is the call request, transfers it to the PoC management server 5 (step S5).
  • the message distribution processing unit 51 of the PoC management server 5 receives the call request including the list of conference members of the routing processing unit 35 of the SIPZSIMPLE server 3 (step S7). In response to this reception, the message distribution processing unit 51 of the PoC management server 5 returns an OK response (step S9).
  • the routing processor 35 of the SIP / SIMPLE server 3 receives the OK response from the PoC management server 5, it transfers it to the user terminal A (step Sl l).
  • User terminal A receives an OK response from SIP / SIMPLE server 3 (step S13). Thereby, the user terminal A can recognize that the call request has been received by the PoC management server 5.
  • the message distribution processing unit 51 of the PoC management server 5 receives a call request including a list of conference members, it starts a new conference, so the conference management unit 53 is newly activated (for example, the conference A management unit 53a is newly activated), and a SIP URL is assigned to the conference A management unit 53a (step S14).
  • the conference A management unit 53a stores the conference member list in the user data storage unit 533a and transmits a new conference creation request including the conference member list to the Po C—MCU server 7 (step S15).
  • the list of conference members includes the user ID of the call requesting user and the IP address of the user terminal, and is specified as a speaker right holder.
  • the new conference audio communication management unit 71 (for example, conference A audio) is allocated to secure resources for the new conference.
  • the conference A voice communication management unit 71a stores the list of conference members in the speaker / participant data storage unit 71la (step S17).
  • the conference A voice communication manager 71a retains the SIP URL of the conference A manager 53a so that it can respond to instructions from the conference A manager 53a.
  • the conference A voice communication management unit 71a secures resources used in the conference related to the call request, that is, the IP address and the port number, and further sets the speaker right for the call requesting user (step).
  • the processing after terminals A to D will be described with reference to FIG. PoC—Conference A of the MCU server 7
  • the voice communication management unit 71a transmits the IP address and port number, which are resources secured in step S19, to the PoC management server 5 as voice destination information (step S21).
  • O PoC management server 5 The conference A management unit 53a receives the voice transmission destination information from the PoC—MCU server 7 and stores it in the MCU information storage unit 531a (step S23).
  • the conference A management unit 53a uses the data stored in the MCU information storage unit 531a to transmit the voice transmission destination information (PoC—IP address and port number of the MCU server 7) and the SIP of the conference A management unit 53a— Send URL as conference information to SIPZSIMPLE server 3 (step S25) .
  • the routing processing unit 35 of the SIP / SIMPLE server 3 transfers the conference information to the user terminal A that is the call request source (step S27).
  • the conference presence management unit in this case, the conference A presence management unit 33a
  • the conference A presence management unit 33a may be activated!
  • the audio conference processing unit 911 of the client application 91 in the user terminal A receives the conference information from the S IPZSIMPLE server 3, and stores it in the storage device (step S29).
  • the audio conference processing unit 911 returns an OK response to the SIPZSIMPLE server 3 (step S31).
  • the routing processing unit 35 of the SIPZSIMPLE server 3 transfers it to the PoC management server 5 (step S33).
  • the conference A management unit 53a of the PoC management server 5 receives the OK response from the SIP / SIMPLE server 3 (step S35).
  • the message distribution processing unit 51 receives a message (in this case, an OK response) from the SIPZSIMPLE server 3, and transfers it to the conference A management unit 53a in charge.
  • description of reception by the message distribution processing unit 51 is omitted.
  • the audio conference processing unit 911 of the client application 91 in the user terminal A activates the microphone driver 93 in response to reception of the conference information (step S37). That is, the microphone of user terminal A detects the voice of user A and converts it into an electrical signal, and microphone microphone 93 generates voice packet data to transmit the voice received by the microphone.
  • the user terminal A can transmit voice packets to the PoC-MCU server 7 in accordance with the IP address and port number included in the received conference information.
  • the PoC—MCU server 7 copies and forwards the voice packet because other participants are identified! There is nothing.
  • the processing shifts to the processing in FIG. 16 through terminals E and F.
  • the conference A management unit 53a of the PoC management server 5 uses the data stored in the user data storage unit 533a to transmit the presence data acquisition request of each conference member excluding the call request source to the SIPZSIMPLE server 3 (step S39). .
  • the presence data acquisition request is transmitted for each conference member.
  • the presence manager 31 of each conference member in the SIPZSIMPLE server 3 The presence data acquisition request of each conference member is received from the management server 5 (step S41).
  • PoC management server 5 Normally, the user's presence data can be updated only by the user, and only those authorized by the user can subscribe. Therefore, PoC management server 5
  • the presence data management unit 311 can refer to the presence data without permission to subscribe. Set in advance.
  • supervisor authority may be given to the PoC management server 5 for the presence data in the SIP / SIMPLE server 3. Accordingly, the presence data management unit 311 of the presence management unit 31 that has received the presence data acquisition request reads the presence data representing the state of the user or user terminal of the conference member from the presence data storage unit 313, and performs PoC management. Send to server 5 (step S43).
  • the conference A management unit 53a of the PoC management server 5 receives the presence data of each conference member from the SIPZSIMPLE server 3 (step S45), and selects a conference member that can be called from the presence data of each conference member. Extract (step S47). In other words, conference members whose presence data indicates that a call is available (for example, ONLINE) are extracted. If the status is OFFLINE or BUSY, voice conference calls are not possible, so do not perform the call processing described below. This can speed up the call processing. However, the processing from step S39 to step S47 is optional. The processing shifts to the processing in FIG. 17 through terminals G and H. For the sake of simplicity, it is assumed that only the user B who operates the user terminal B is called as a conference member.
  • the conference A management unit 53a of the PoC management server 5 uses the data stored in the user data storage unit 533a and the MCU information storage unit 53 la to generate conference information (the SIP-URL and PoC-MCU of the conference A management unit 53a).
  • a call for the callable conference member including the IP address and port number of Sirano 7 is transmitted to the S IPZSIMPLE server 3 (step S49).
  • the call request source user data is included in this call.
  • the routing processing unit 35 of the SIPZSIMPLE server 3 receives the call for the callable conference member including the conference information from the PoC management server 5, and transfers the call to the user terminal of each conference member (step S51).
  • the audio conference processing unit 911 of the terminal B receives the call including the conference information from the SIPZSIMPLE server 3, and performs processing corresponding to the call (step S53). For example, the user B is notified that the call has been received by sounding a ring tone or causing the display device to perform a predetermined display.
  • the received conference information is stored in a storage device and used for a subsequent participation response.
  • the audio conference processing unit 911 of the user terminal B transmits an OK response to the call to the SIPZSI MPLE server 3 (step S55).
  • the routing processing unit 35 of the SIP / SIMPLE server 3 transfers it to the PoC management server 5 (step S57).
  • the conference A management unit 53a of the PoC management server 5 also receives the OK response from the SIPZSIMPLE server 3 (step S59).
  • User B determines whether or not to participate in the audio conference in response to the call in step S53.
  • the user terminal B is operated to input a conference participation instruction.
  • the audio conference processing unit 911 of the user terminal B receives the conference participation instruction input from the user B (step S61), and transmits a participation response to the SIPZSIMPLE server 3 (step S63).
  • the routing processing unit 35 of the S IPZSIMPLE server 3 transfers the response to the PoC management server 5 (step S65).
  • the conference A management unit 53a of the PoC management server 5 receives the participation response from the user B from the SIPZSIMPLE server 3 (step S67).
  • the conference A management unit 53a registers the user ID (ie, SIP URL) of the user who made the participation response and the IP address of the user terminal as a participant in the user data storage unit 533a. Also, a participation member addition notification including the user ID (ie, SIP URL) of the user who made the participation response and the IP address of the user terminal is transmitted to the PoC—MCU server 7 (step S69). PoC—Conference of MCU server 7 A Voice communication management unit 71a receives the participation notification including the user ID and IP address of the participant from the PoC management server 5!], And the speaker and participant data storage unit The user ID and IP address of the participant are registered in 71 la (step S71).
  • the conference A manager 53a transmits an OK response to the SIP / SIMPLE server 3 (step S73).
  • the routing processor 35 of the SIPZSIMPLE server 3 receives the OK response from the PoC management server 5 and forwards it to the user terminal B (Step S75).
  • User terminal B receives an OK response from SIPZSIMPLE server 3 (step S77).
  • the conference A management unit 53a of the PoC management server 5 uses the data stored in the user data storage unit 533a to generate a presence registration request for the speaker information including the user ID of the user who has the right to speak.
  • Send to ZSIMPLE server 3 (step S79). More specifically, the conference A management unit 53a requests registration of the user ID of the user who has the right to speak as presence data whose owner is the presence ID “FloorUser”.
  • the SIPZSIMPLE server 3 receives the speaker information presence registration request from the PoC management server 5.
  • the conference A presence manager 33a for the conference A manager 53a is not activated, it is activated at this timing, and the presence data manager 331a of the conference A presence manager 33a
  • the user ID of the user who has the right to speak corresponding to the presence ID (“FloorUser") is stored as presence data in the presence data storage unit 333a (step S81).
  • the user ID “UserA” of the user who has the right to speak is registered in area 3361.
  • the conference A presence manager 33a transmits an OK response to the PoC management server 5 (step S83).
  • the conference A management unit 53a of the PoC management server 5 receives the OK response from the SIP / SIMPLE server 3 (step S85).
  • the conference A management unit 53a of the PoC management server 5 uses the data stored in the user data storage unit 533a to include the presence of the member information including the information of the conference member including the user who made the call request.
  • a registration request is generated and sent to the SIPZSIMPLE server 3 (step S87). More specifically, the user ID of the conference member including the user who made the call request is registered as the presence data that is owned by the conference A management unit 53a and has the presence ID power S “Member”. Request.
  • the conference A presence management unit 33a of the SIPZSIMPLE server 3 receives a member information presence registration request from the PoC management server 5, and the presence data management unit 33la of the conference A presence management unit 33a Presence data (“UserA, UserB, UserC” in the example of FIG. 6) corresponding to the presence ID (“Member”) related to the request for registration of registration is stored in the presence data storage unit 333a (step S89). Further, the conference A presence manager 33a transmits an OK response to the PoC management server 5 (step S91). The conference A management unit 53a of the PoC management server 5 receives the OK response from the SIP ZSIMPLE server 3 (step S93).
  • the conference A management unit 53a of the PoC management server 5 uses the data stored in the user data storage unit 533a to generate a proxy subscription request by the conference member including the user who made the call request, Send to SIPZSIMPLE server 3 (step S95). More specifically, the subscriber list storage area 3335 in the presence data storage unit 333a and the group II “voice conference” area 333 in the presence group information storage area 3333 include the conference member in the area 3382 for the subscriber ID in the area 338. Request to register. Note that the SIPZSIMPLE server 3 may be requested to register the user who made the call request and the user who made the participation response instead of the conference member.
  • the PoC management server 5 acts as a proxy from the viewpoint that the data communication volume in the wireless section is increased and the communication bandwidth is used unnecessarily, which slows the progress of the conference. And register for subscription.
  • the owner of the presence data storage unit 333a of the conference A presence management unit 33a is the conference A management unit 53a, and there is no significant problem in terms of authority for the owner to subscribe and register on behalf.
  • the conference A presence management unit 33a of the SIPZSIMPLE server 3 receives the proxy subscription request to the conference member including the user who has made a call request from the PoC management server 5, and the presence data management unit 33 la , A conference member (or participant) is registered in the subscriber list storage area 3 335 of the presence data storage unit 333a, and the subscriber ID in the group 338 “voice conference” area 338 in the presence group information storage area 3 333 A conference member (or participant) is registered in the area 3382 for registration (step S97).
  • the conference A presence management unit 33a transmits an OK response to the PoC management server 5 (step S99).
  • the conference A management unit 53a of the PoC management server 5 receives the OK response from the SIPZSIMPLE server 3 (step S101). The processing shifts to the processing in FIGS. 19 and 20 through terminals K and L.
  • the conference member registers in the subscriber list storage area 3335 and the presence group information storage area 3333 in the group II "voice conference" area 338 for the subscriber ID area 3382. Then, presence data power of presence ID registered in area 3381 for presence ID in area 338 of group II “voice conference” is distributed to conference members (or participants) by the processing unit 335a. become.
  • the distribution processing unit 335a of the presence management unit 33a determines the presence data of the conference according to the state of the presence data storage unit 333a (user ID of the speaker right holder, user ID of the conference member and participation) (User ID of the user) is executed (step S 10 3).
  • presence data of the conference is transmitted to user terminal A and user terminal B.
  • the presence data processing unit 915 of the user terminal B receives the conference presence data from the SIPZSIMPLE server 3 and displays it on the display device (step S105).
  • the presence data processing unit 915 of the user terminal A receives the conference presence data from the SIPZSIMPLE server 3 and displays it on the display device (step S107).
  • the presence data processing unit 915 of the user terminal B returns an OK response to the SIPZSIMPLE server 3 (step S109), and the presence data processing unit 915 of the user terminal A also receives the SIPZ An OK response is returned to SIMPLE server 3 (step S111).
  • the conference A presence manager 33a of the SIPZSIMPLE server 3 also receives the OK response from the user terminal A and the user terminal B (step S113). The processing shifts to the processing in FIG.
  • the conference A management unit 53a of the PoC management server 5 uses the data stored in the user data storage unit 533a to confirm the participants who have been confirmed by this stage (not only the user who made the participation response but also the call request).
  • a presence registration request (including the user who made the request) is generated and transmitted to the SIP / SIMPLE server 3 (step S115). More specifically, the conference A management unit 53a is the owner, and requests that the user ID of the participant be registered as presence data whose presence ID is “JoinUser”.
  • the conference A presence manager 33a of the SIPZSIMPLE server 3 receives the participant's presence registration request from the PoC management server 5, and the presence data manager 331a of the conference A presence manager 33a
  • the presence ID (“joinUser”) and presence data (“UserA, UserB” in the example of FIG. 6) are stored in the presence data storage unit 333a (step SI17).
  • the conference A presence management unit 33a transmits an OK response to the PoC management server 5 (step S119).
  • the conference A management unit 53a of the PoC management server 5 receives the OK response from the SIP / SIMPLE server 3 (step S121).
  • the distribution processing unit 335a of the conference A presence management unit 33a in the SIPZSIMPLE server 3 determines the presence data of the conference (user ID of the speaker right holder, user of the conference member according to the state of the presence data storage unit 333a) ID and participant user ID) notification processing is performed (step S123).
  • the presence data of the conference is transmitted to user terminal A and user terminal B.
  • the presence data processing unit 915 of the user terminal B receives the conference presence data from the SIP ZSIMPLE server 3 and displays it on the display device (step S125).
  • the presence data processing unit 915 of the user terminal A receives the conference presence data from the SIP ZSIMPLE server 3, and displays it on the display device (step S127).
  • step S117 the participant enters the presence data storage unit 333a. Since it is registered, a display that can grasp the conference member, the participant, the speaker right holder, and the user who does not participate in the call is displayed. Then, presence data processing unit 915 of user terminal B returns an OK response to SIPZSIMPLE server 3 (step S 1 29), and presence data processing unit 915 of user terminal A also returns an OK response to SIPZSIMPLE server 3. (Step S131).
  • the conference A presence management unit 33a of the SIPZSIMPLE server 3 also receives the OK response from the user terminal A and the user terminal B (step S133). The process proceeds to the process in FIG. Further, the processing shifts to the processing in FIG.
  • steps S115 to S133 are executed each time a new participant appears. If the participant has been subscribed and registered in step S97, each time a participant newly appears, steps S115 to S133 are executed, and the user who has already subscribed and registered as a participant is registered. Presence data is distributed, and steps S95 to S113 are further executed to distribute presence data to new participants.
  • each participant of the electronic conference can recognize other participants and can start the conference. Since the user who made the call request holds the speaker right, only this user can speak.
  • processing as shown in FIG. 21 is performed.
  • User A speaks to user terminal A because user A is a right holder.
  • the user terminal A receives the voice input from the user A with a microphone, and the voice conference processing unit 911 generates a voice data force voice packet generated by the microphone driver 93 and transmits it to the PoC—MCU server 7 ( Step S 135).
  • the IP address and port number of the PoC-MCU server 7 received as the conference information are used. That is, the voice packet is transmitted directly to the PoC—MCU server 7.
  • PoC—Conference A voice communication manager 71a of MCU server 7 receives the voice packet from user terminal A, and stores the participant IP address stored in the speaker and participant data storage 71 la. A copy of the voice packet is transferred to the destination (step S137).
  • the audio conference processing unit 911 of the client application 91 in the user terminal B receives the audio packet from the PoC—MCU server 7 and does not show the voice packet via the speaker driver and the speaker. (Step SI 39). In this way, an audio-based electronic conference is performed. Note that the transfer of the right to speak is not the main part of the present embodiment and will not be described here.
  • the conference A management unit 53a of the PoC management server 5 uses the data stored in the user data storage unit 533a to store the presence data of the participant for each participant (including the user who made the call request).
  • the presence data update registration request is generated so as to be changed to “(or during a voice conference, etc.) and transmitted to the SIP / SIM PLE server 3 (step S141). More specifically, if the participants are user A and user B, an area 316 (presence ID is “State”) in the presence information storage area 3131 in the presence data storage section 3 13a of the user A presence management section 3 la.
  • Presence data update registration request to change the data stored in) to “BUSY”, etc., and presence information storage area 3131 in user B presence management section 3 lb presence data storage section 313b stored in area 316
  • a presence data update registration request for changing the data to “BUSY” or the like is generated and sent to the SIPZSIMPLE server 3.
  • the data in the presence data storage unit 313a in the user A presence management unit 31a can be changed only to the user A.
  • the data in the presence data storage unit 313b in the user B presence management unit 31b can be changed only to the user B.
  • the PoC management server 5 is specifically allowed to change in order to smoothly advance the audio conference and reduce the communication volume in the wireless section. As mentioned above, PoC management server 5 should be given supervisor rights to the presence data in SIP / SIMPLE server 3!
  • the user A presence management unit 3 la (and the user B presence management unit 31b of the SIP / SIMPLE server 3 is omitted because it overlaps below), from the PoC management server 5 to the presence data of the participant.
  • the presence data management unit 311a of the user A presence management unit 31a stores presence data such as “BUSY” in the presence data storage unit 313a corresponding to the presence ID “State” (step S143).
  • S User A presence manager 31a of IPZSIMPLE server 3 sends OK response to PoC
  • the data is transmitted to the management server 5 (step S 145).
  • the conference A management unit 53a of the PoC management server 5 receives the OK response from the SIPZSIMPLE server 3 (step S147).
  • the presence data of user A and user B is notified to the user registered as a subscriber of presence ID "State". . That is, the delivery processing unit 315a of the user A presence management unit 31a in the SIPZSIMPLE server 3 performs the notification process of the presence data of the user A according to the state of the presence data storage unit 313a (step S149). In the example of Fig. 5, it is sent to user B and user C. The same processing is performed for the user B presence management unit 3 lb. However, user B's presence data shall be sent to user A and user C.
  • presence data processing section 915 of user terminal B receives the presence data of user A from SIPZSIMPLE sensor 3 and displays it on the display device (step S151).
  • the presence data processing unit 915 of the user terminal A receives the presence data of the user B from the SIP / SIMPLE server 3 and displays it on the display device (step S153).
  • the display is changed in the same manner in other user terminals. This allows other users who have subscribed to the status of the participants in the audio-based electronic conference to recognize that the participant has not been able to get in touch with BUSY.
  • presence data processing unit 915 of user terminal B returns an OK response to SIPZSIMPLE server 3 (step S155), and presence data processing unit 915 of user terminal A also returns an OK response to SIPZSIMPLE server 3. (Step S157).
  • the user A presence manager 31a and the user B presence manager 3 lb of the SIP / SIMPLE server 3 receive the OK response from the user terminal A and the user terminal B (step S159).
  • FIGS. 23 to 25 processing when a character-based electronic conference (chat) is started in the middle of an audio-based electronic conference is described with reference to FIGS. 23 to 25.
  • user A is an audio-based electronic conference in which user A, user B, user C, etc. participate.
  • Fig. 5 we explain the process when we have a secret meeting with User B in character-based chat instead of voice. In this case, the voice-based electronic conference is maintained.
  • user A operates user terminal A to maintain a voice-based electronic conference and designate user B who is a participant to call for chat.
  • the chat processing unit 913 of the user terminal A receives a user operation input for such a voice maintenance chat call request (step S201), and performs a voice maintenance chat call including a list of chat members (here, user B).
  • the request is transmitted to the SIPZSIMPLE server 3 (step S203). For example, if user A cannot input the callee designation, all participants in the voice-based electronic conference may be set as callees.
  • the routing processor 35 of the SIPZSIMPLE server 3 receives the voice maintenance chat call request including the list of chat members of the user terminal A, and forwards it to the PoC management server 5 (step S205).
  • the conference A management unit 53a of the PoC management server 5 receives the voice maintenance call request including the chat member list from the SIP / SIMPLE server 3, and stores the chat member list in the user data storage unit 533a, for example. Store (step S207). Then, the conference A management unit 53a of the PoC management server 5 returns an OK response to the SIPZSIMPLE server 3 (step S209).
  • the routing processing unit 35 of the SIP / SIMPLE server 3 receives the OK response from the PoC management server 5 and forwards it to the user terminal A (step S211).
  • the chat processing unit 913 of the user terminal A receives an OK response from the SIPZSIMPLE server 3 (step S213).
  • the conference A management unit 53a of the PoC management server 5 makes a chat call for voice maintenance to the chat member (user B in this case) for each chat member according to the received list of chat members. (Step S215).
  • the data for the calling user is included in the chat call.
  • the routing processing unit 35 of the SIP / SIMPLE server 3 receives the chat call for maintaining the voice for the chat member from the PoC management server 5 and transfers it to the user terminal B (step S 217).
  • the chat processing unit 913 of the user terminal B receives the chat call for maintaining the voice from the SIPZSIMPLE server 3 and performs the chat call process such as displaying for a chat call or outputting a predetermined voice (step). S219).
  • chat processing unit 913 of the user terminal B Send the request to the SIPZSIMPLE server 3 (step S221).
  • the routing processing unit 35 of the SIPZSIMPLE server 3 receives the OK response from the user terminal B and forwards it to the PoC management server 5 (step S223).
  • the conference A management unit 53a of the PoC management server 5 receives the OK response from the SIP ZSIMPLE server 3 (step S225).
  • the processing shifts to the processing in FIG. 24 via terminal Q, terminal R, and terminal S.
  • the conference A management unit 53a of the PoC management server 5 transmits an OK response to the SIPZSI MPLE server 3 (step S235).
  • the routing processing unit 35 of the SIPZSIMPLE server 3 receives the OK response from the PoC management server 5 and forwards it to the user terminal B (step S237).
  • Chat processing unit 913 of user terminal B receives the OK response from SIPZSIMPLE server 3 (step S239).
  • the conference A management unit 53a of the PoC management server 5 uses the data stored in the user data storage unit 533a to include the chat participants (including the chat call requesting users.
  • a presence registration request for user B. is generated and transmitted to SIPZSIMPLE server 3 (step S241). More specifically, the user ID of the participant (“UserA, UserB” in the example of FIG. 6) is registered as presence data whose owner is the conference A management unit 53a and whose presence ID is “ChatUser”. Request.
  • Conference in SIPZSIMPLE Sano 3 A presence manager 33a presence data manager 33 la receives a chat participant presence registration request from the PoC management server 5, and receives the received presentation.
  • the chat participant's user ID (“UserA, UserB” in the example of FIG. 6) is stored as presence data in the presence data storage unit 333a (step S243). ).
  • the user IDs of the participants (“UserA, UserB” in the example of FIG. 6) are registered in area 3365 of presence information storage area 3331.
  • the conference A presence manager 33a transmits an OK response to the PoC management server 5 (step S245).
  • the conference A management unit 53a of the PoC management server 5 receives the OK response from the SIP / SIMPL E server 3 (step S247).
  • the conference A management unit 53a of the PoC management server 5 generates a public setting request for the chat participant using the data stored in the user data storage unit 533a, and sends it to the SIP / SI MPLE server 3. Transmit (step S249). More specifically, in the presence group information storage area 3333, the user ID of the chat participant (in the example of FIG. 6 "UserA, UserB" ) Is required to be registered.
  • Presence data management unit 331a of presence management unit 33a receives a public setting request (proxy subscription request) corresponding to a chat participant from PoC management server 5, and participates in chat related to the received public setting request
  • the user ID of the subscriber is stored in the subscriber ID area 3392 in the area 339 for group III “chat” in the presence group information storage area 3333 (step S251).
  • the conference A presence management unit 33a transmits an OK response to the PoC management server 5 (step S253).
  • the conference A management unit 53a of the PoC management server 5 receives the OK response from the SIPZSIMPLE server 3 (step S255). The processing shifts to the processing in FIG.
  • the presence ID included in the group III “chat” area 339 in the presence group information storage area 3333 is stored.
  • the presence data specified in area 3391 is notified to the chat participant.
  • the flop Rezensudeta whose presence ID is "Chat”, "the contents of the chat” ( “Hello '" in the example of FIG. 6)
  • the presence data "chat participant” whose presence ID is "ChatUser” (Fig. In the example of 6, "UserA, Use rB") is automatically notified at the time of update.
  • chat participants since the owner of the presence data is the Conference A Manager 53a, chat participants usually update the presence data. I can't do it. If the chat participant cannot change the chat content, the chat cannot proceed.
  • a process such as starting the presence management unit owned by the chat participant is performed separately from the conference A presence management unit 33a. Has problems such as using extra resources of SIPZSIMPLE server 3 and PoC management server 5. Therefore, in this embodiment, a chat participant registered as presence data whose presence ID is “ChatUser” can update the presence data whose presence ID is “Chat” regardless of the owner.
  • the chat participant is authorized to update the chat content in response to the presence registration request of the chat participant in step S241 or a public setting request (proxy subscription request) to the chat participant in step S249. become. In this way, the chat can be started smoothly without wasting resources.
  • the distribution processing unit 335a of the conference A presence management unit 33a in the SIPZSIMPLE server 3 sends chat presence data (presence data of chat contents and presence data of chat participants) to the user according to the settings of the presence data storage unit 333a. Notification is made to terminal A and user terminal B (step S257). Initially, no chat content is registered, so nothing is notified.
  • the presence data processing unit 915 of the client application 91 in the user terminal B receives the chat presence data from the SIPZSIMPLE server 3 and displays it on the display device (step S259).
  • the presence data processing unit 915 of the client application 91 in the user terminal A receives chat presence data from the SIPZSIMPLE server 3 and displays it on the display device (step S261).
  • the presence data processing unit 915 of the user terminal B returns an OK response to the SIPZSIMPLE server 3 (step S263).
  • the presence data processing unit 915 of the user terminal A returns an OK response to the SIP / SIMPLE server 3 (step S265).
  • the conference A presence manager 33a of the SIP / SIMPLE server 3 receives the OK response from the user terminal A and the user terminal B (step S267).
  • user A operates user terminal A to change the chat contents (conversation characters).
  • presence data processing unit 915 of user terminal A accepts input of a conversation character by user A and transmits it to SIPZSIMPLE server 3 as presence data of presence ID “Chat” (step S269).
  • the presence data management unit 331a in the conference A presence management unit 33a of the SIPZSIMPLE server 3 receives the conversation character data as the presence data of the presence ID “Chat” from the user terminal A and stores it in the presence data storage unit 333a (step S271).
  • the conference A presence manager 33a transmits an OK response to the user terminal A (step S273).
  • the user terminal A receives an OK response from the SIPZSIMPL E server 3 (step S275).
  • the distribution processing unit 335a of the conference A presence management unit 33a in the SIPZSIMPLE server 3 performs chat presence data (presence data of chat content) according to the setting of the presence data storage unit 333a. If there is a change, the presence data of the chat participant is notified to user terminal A and user terminal B (step S277). In some cases, only the difference is notified.
  • the presence data processing unit 915 of the client application 91 at the user terminal B receives the chat presence data from the SIP ZSIMPLE server 3 and displays it on the display device (step S279).
  • the presence data processing unit 915 of the client application 91 in the user terminal A receives chat presence data from the SIPZSIMPLE server 3 and displays it on the display device (step S281).
  • the presence data processing unit 915 of the user terminal B returns an OK response to the SIPZSIMPLE server 3 (step S288).
  • the presence data processing unit 915 of the user terminal A returns an OK response to the SI PZSIMPLE server 3 (step S285).
  • the conference A presence manager 33a of the SIPZSIMPLE server 3 receives the OK response from the user terminal A and the user terminal B (step S287).
  • chat conversation can be advanced by repeating the processes of steps S269 to S287.
  • conversation characters can also be transmitted from the user terminal B. Since the processing contents are the same, the description thereof is omitted here.
  • character-based chatting is performed separately for a subset of participants in the audio-based electronic conference while maintaining the audio-based electronic conference. Will be able to. Since chat is realized using presence technology, resources prepared for voice-based electronic conferences can be used effectively.
  • multiple chat groups can be managed. For example, users A, B, C, and D As a subset of an audio conference with four participants, users A and B, users C and D chat separately, and users A and B and users A and C chat separately. You can chat with multiple subsets, such as
  • presence data of a specific user is managed.
  • the presence ID is “position”, and “teacher” or “student”! / If such presence data is stored, a user whose presence data is “student” may allow only a user whose presence data is “teacher” as a chat destination, or the presence data may be “ A call from a user who is a “teacher” can be controlled so that the call is allowed to any user.
  • presence data managed for each user can be used to control transmission of presence data.
  • presence data storage area 3331 in FIG. 6 manages the presence data of voice-based electronic conferences.
  • the presence ID is “teacher” and a participant who has teacher status is subscribed. If a participant ID is registered, and the presence ID is “student”, and the participant ID of a participant with student status is registered, the same process as above can be performed. That is, a user registered as presence data whose presence ID is “teacher” can call chat to all conference participants, and presence data whose presence ID is “student”. For users registered as V, chat can only be called to users registered as presence data whose presence ID is "teacher”! Become. Therefore, it is possible to control the presence data transmission using the presence data managed for each conference.
  • FIGS. For example, the processing for starting distribution of necessary image data during an electronic conference will be described.
  • three types of processing when user A delivers an image to user B in an audio-based electronic conference in which user A, user B, user C, etc. participate will be described.
  • the description of transmission / reception of the OK response is omitted.
  • user A who is a participant in the electronic conference selects user B or the like to distribute image data required for the electronic conference to user B or the like. Perform V and all operations on the image distribution request.
  • the image processing unit 916 in the client application 91 of the user terminal A accepts a user operation input for an image distribution request including a selection of a distribution destination user such as the user B from the user A (step S301), and the user ID of the distribution destination user
  • An image distribution request including “S” is transmitted to the SIPZSIMPLE server 3 (step S303).
  • the routing processing unit 35 of the SIP / SIMPLE server 3 receives the image distribution request from the user terminal A and transfers it to the PoC management server 5 (step S305).
  • the conference A management unit 53a of the PoC management server 5 receives the image distribution request from the user terminal A, and stores the user ID of the image distribution requesting source user and the user ID of the distribution destination user, for example, a user data storage unit 533a. (Step S307). Then, a resource for image distribution (image storage area in image data storage unit 535a, IP address and port number of upload destination resource, etc.) is secured (step S309). Then, the conference A management unit 53a generates a presence registration request for image distribution and transmits it to the PoC management server 5 (step S311).
  • the conference A management unit 53a is the owner and the user ID of the image distribution participant is registered as presence data whose presence ID is “PhotoUser”, and the conference A management unit 53a is the owner. It requests that resource data for distribution and distribution be registered as presence data whose presence ID is “Photo”.
  • Presence data management unit 33 la of presence management unit 33a receives presence registration request for image distribution from PoC management server 5, and presence related to the received presence registration request Corresponding to the ID (“PhotoUser"), the presence data storage unit 333 uses the user ID of the image distribution participant as presence data.
  • the image distribution resource 'data is stored as presence data in the presence data storage unit 333a (step S313).
  • the user IDs of the image distribution participants (“UserA, UserB” in the example of FIG. 6) are registered in the area 3367 of the presence information storage area 3331.
  • an image distribution resource is stored in the area 3366 of the presence information storage area 3331.
  • the conference management unit 53a of the PoC management server 5 generates a public setting request (proxy subscription request) for the image distribution participant using the data stored in the user data storage unit 533a, and SIPZSIMPLE Send to server 3 (step S315). More specifically, the user ID of the image distribution participant is requested to be registered in the subscriber ID area 3402 in the area 340 for the group IV “image” in the presence group information storage area 3333. Conference on SIP / SIMPLE server 3 Presence data management unit 33 la of presence management unit 33a receives a public setting request (proxy subscription request) from the PoC management server 5 to the image distribution participant and responds to the received public setting request. The user ID of the image delivery participant (“UserA, UserB” in the example of FIG. 6) is stored in the group ID “image” area 340 in the presence group information storage area 3333 in the reader ID area 3402. (Step S317).
  • the distribution processing unit 335a of the conference A presence management unit 33a in the SIPZSIMPLE server 3 follows the setting of the presence data storage unit 333a to provide the presence data (image upload resource 'data (especially upload)
  • the destination resource (IP address and port number) and the presence data of the image delivery participant) are notified to the user terminal A and the user terminal B (step S319)
  • the presence data processing unit of the client application 91 in the user terminal B 915 Receives the presence data about the image distribution from the SIPZSIMPLE server 3 and displays it on the display device (step S323)
  • the presence data processing unit 915 of the client application 91 in the user terminal A performs the image distribution from the SIPZSIMPLE server 3.
  • Receive presence data and display This enables each user terminal to obtain the transmission destination data (upload destination resource) of the image data to be distributed. Shifts to the processing in FIG. 27 via terminal U, terminal V, and terminal W.
  • the user A of the user terminal A that has transmitted the image distribution request operates the user terminal A to specify image data (image file) to be distributed.
  • the image processing unit 916 in the client application 91 of the user terminal A accepts a designation input of image data from the user A (step S325), reads the image data from the storage device power of the user terminal A, and designates the designated image data. Is sent to the upload destination resource (IP address and port number) (step S3 27).
  • the conference A management unit 53a of the PoC management server 5 receives the image data from the user terminal A and stores it in the image data storage unit 535a (step S329).
  • the conference A management unit 53a of the PoC management server 5 generates an update registration request for presence data of the image distribution source user (here, user A) and transmits it to the SIPZSIMPLE server 3 (step S331). Specifically, for changing the data stored in the area 316 in the presence information storage area 3131 in the presence data storage section 313a of the user A presence management section 3 la to “Photo Sending” or “Image delivery in progress”. Generate a presence data update registration request.
  • the PoC management server 5 has supervisor authority over the SIPZSIMPLE server 3, and the user A presence management unit 31a and the presence data storage unit 313 in the user B presence management unit 3 lb Assume that you have update authority.
  • Presence data manager 311a of la receives the presence update registration request of the distribution source user from PoC management server 5, and relates to the received presence update registration request Corresponding to the presence ID (“State”), “Photo Sending” or “Image delivery” or the like is stored as presence data in the presence data storage unit 313a (step S333).
  • the data stored in the area 316 in the presence information storage area 3131 in the presence data storage section 313a of the user A presence management section 3 la is changed to “Photo Sending” or “Image delivery in progress”.
  • the electronic conference participant registers other electronic conference participants in advance as subscribers of presence data whose presence ID is “State”.
  • the processing unit 315a notifies the user terminal A and the user terminal B of the presence data whose presence ID is “State” according to the setting of the presence data storage unit 313a (step S335).
  • the presence data processing unit 915 of the client application 91 in the user terminal B receives the presence data of the user A from the SIPZSIMPLE server 3 and displays it on the display device (step S339).
  • the presence data processing unit 915 of the client application 91 in the user terminal A receives the presence data of the user A from the SIPZSIMPLE server 3 and displays it on the display device (step S337).
  • each user terminal can grasp that user A uploaded the image data.
  • the user B operates the user terminal B to request the image data uploaded by the user A by clicking the image distribution resource 'data'.
  • the image processing unit 916 of the client application 91 of the user terminal B transmits an image request to the image distribution resource (step S341).
  • Step S341 may be executed without user B intervention.
  • the conference A management unit 53a of the PoC management server 5 receives the image request from the user terminal B (step S343), reads the image data related to the request from the image data storage unit 535a, and distributes it to the user terminal B that is the request source. (Step S345).
  • the image processing unit 916 of the client application 91 of the user terminal B receives the image data from the PoC management server 5 and displays it on the display device (step S347). In this way, the image data uploaded by user A can be downloaded.
  • the distribution destination user terminal accesses the image distribution resource and images. Data can be downloaded. Also, for example, if another user's power participating in the same electronic conference is overwritten and registered in the same resource in the image data storage unit 535a, the presence data of the other user is updated, and accordingly. Since other user terminals that have detected presence updates access the image distribution resources, it is possible to easily distribute image data while using audio-based teleconferencing resources using presence technology. It becomes like this. Further, the same resource in the image data storage unit 535a can be diverted. [0105] Further, after step S345, presence data representing the state of user A may be returned to "Busy".
  • step S331 to step S339 can be replaced with the following processing. That is, the conference A management unit 53 3a of the PoC management server 5 generates an update registration request for presence data whose presence ID is “Photo” or presence data whose photo ID is “PhotoUser”, and transmits the request to the SIPZSIMPLE server 3 (step S3). S331). Specifically, the distribution source resource (for example, ft p: //yyy.yyy.yyy.yyyyy/imagefromUserA.j P g) is allocated to the upload destination resource, and the presence of the conference A presence management unit 33a is secured.
  • the distribution source resource for example, ft p: //yyy.yyy.yyy.yyyy/imagefromUserA.j P g
  • Data storage section 333a Presence information storage area 3331 area 336 6 in the thread 7 1 ⁇ xxx.xxx.xxx.xxx:xxxx ftp: //yyy.yyy.yy.yy/imagefromUserA .jpg "etc., and the presence data update registration request is generated.
  • the presence data storage section 333a of the conference A presence management section 33a also stores the data stored in the area 3367 in the storage area 3331" You may generate a presence data update registration request to change to UserA (Photo Sending), UserB "or” UserA (during image delivery), UserB ", etc. A recording request may be generated.
  • the presence data management unit 33 la of the conference A presence management unit 33a in the SIP / SIMPLE server 3 sends an update registration request for presence data whose presence ID is Photo "or PhotoUser" from the PoC management server 5.
  • XXX ftp: //yyy.yyy.yyy.yyy corresponding to the presence ID ("Photo” or "PhotoUser") related to the received presence update registration request /imagefromUserA.jpg or u serA (Photo Sensing), UserB "or” UserA (during image delivery), UserB ", etc. are stored as presence data in the presence data storage unit 333a (step S333).
  • the distribution process of the conference A presence manager 33a in the SIPZSIMPLE server 3 According to the setting of the presence data storage unit 333a, the management unit 335a notifies the user terminal A and the user terminal B of the presence data whose presence ID is “Photo” or the presence data “PhotoUser” (step S335). .
  • the presence data processing unit 915 of the client application 91 in the user terminal B also receives the presence data regarding the image distribution as described above and displays it on the display device (step S339). Further, the presence data processing unit 915 of the client application 91 in the user terminal A receives the presence data regarding the image distribution as described above from the SIPZSIMPLE server 3 and displays it on the display device (step S337).
  • step S319 notification of presence data for image distribution in step S319 is not transmitted to user terminal B, which is not the user terminal of the image distribution source user.
  • the user ID of user B is not registered in the public setting request (substitute subscription request) in step S315, and the user after receiving the image data to be distributed as described below.
  • It may be realized by sending a public setting request (substitute subscription request) including the user ID of B from the conference A management unit 53a of the PoC management server 5 to the conference A presence management unit 33a of the SIP / SIMPLE server 3. good.
  • step S315. it is realized by including a setting that masks the user ID of user B until the next presence data update registration request is received in the public setting request (substitute subscription request) in step S315. Also good. In this way, the user terminal A that is the transmission source of the image distribution request is notified of the image distribution resource data.
  • the user A of the user terminal A that has transmitted the image distribution request operates the user terminal A to specify image data to be distributed.
  • the image processing unit 916 in the client application 91 of the user terminal A accepts the designation input of the image data as well as the user A force (Step S351), reads the image data from the storage device capability of the user terminal A, and uploads the designated image data to the upload destination. Send to resource (IP address and port number) (step S353).
  • the conference A management unit 53a of the PoC management server 5 receives the image data from the user terminal A and stores it in the image data storage unit 535a (step S355).
  • the conference A management unit 53a of the PoC management server 5 generates a presence data update registration request whose presence ID is "Photo” and transmits it to the SIPZSIMPLE server 3 (step S357). Specifically, the data stored in the area 3366 in the presence information storage area 3331 in the presence data storage section 333a of the conference A presence management section 33a is changed to “xxx.xxx.xxx.xxx:xxxx” (IP address and port number). ) To generate a presence data update registration request.
  • a distribution source resource for example, ftp: ⁇ yyy.yyy.yyy.yyyy / imagefromUserA.jpg
  • presence information storage section 333a of conference A presence management section 33a stores presence information.
  • Presence data update registration request to change the data stored in area 3366 in area 3331 to "xxx.xxx.xxx.xxx:xxxx ftp: ⁇ yyy.y yy.yyy.yyyyyyyyyyy / imagefromUserA.jpg"Let's generate it.
  • Presence data management unit 33a of presence management unit 33a receives and receives an update registration request for presence data whose presence ID is "Photo" from PoC management server 5
  • Xxx.xxx.xxx.xx.xxx:xxxx or xxx.xxx.xxx.xxx:xxxx ftp: // y yy.yyy-yyy.yyy / imagefromUserA .jpg 'etc. are stored in the presence data storage unit 333a as a presence status (step S359).
  • the distribution processing unit 335a of the conference A presence management unit 33a in the SIPZSIMPLE server 3 sends the presence data whose presence ID is "Photo" to the user terminal A and the user according to the setting of the presence data storage unit 333a.
  • Terminal B is notified (step S361).
  • the presence data processing unit 915 of the client application 91 in the user terminal B receives the presence data from the SIPZSIMPLE server 3 and displays it on the display device (step S365). Further, the presence data processing unit 915 of the client application 91 in the user terminal A receives presence data for the SIPZSIMPLE server 3 image distribution and displays it on the display device (step S363).
  • the user B operates the user terminal B to request the image data uploaded by the user A by clicking the image distribution resource data.
  • the image processing unit 916 of the client application 91 of the user terminal B transmits an image request to the image distribution resource (step S367). Note that step S367 may be executed without the intervention of user B.
  • the conference A management unit 53a of the PoC management server 5 receives the image request from the user terminal B (step S369), reads the image data related to the request from the image data storage unit 535a, and sends it to the requesting user terminal B. Distribute (step S371).
  • the image processing unit 916 of the client application 91 of the user terminal B also receives the image data from the PoC management server 5 and displays it on the display device (step S373). In this way, the image data uploaded by user A can be downloaded.
  • presence data including image distribution resources and the like are notified to the distribution destination user terminal in accordance with image registration in the PoC management server 5. Therefore, each distribution destination user terminal can access the image distribution resource according to the notification. Also, for example, if another user registers image data in the image data storage unit (which may be overwritten on the same resource), the presence resource with the presence ID “Photo” is the resource for distributing the image data. The data is updated, and other user terminals can download images in response to notification of presence data whose presence ID is “Photo”. Therefore, it is possible to distribute images while using the resources of the audio-based electronic conference.
  • step S357 the data stored in the area 3367 in the presence information storage area 3331 in the presence data storage section 333a of the conference A presence management section 33a is stored as "UserA (Photo Sending), UserB” or " A presence data update registration request for changing to UserA (during image delivery), UserB ", etc. may be generated. Furthermore, a presence data update registration request for updating presence data whose presence ID is “Photo” and presence data whose “PhotoUser” is present may be generated.
  • User A of user terminal A which has transmitted the image distribution request, operates user terminal A to specify image data to be distributed.
  • the image processing unit 916 in the client application 91 of the user terminal A receives a specified input of image data from the user A (step S381), reads the image data from the storage device of the user terminal A, and uploads the specified image data to the upload destination resource. (IP address and port number) (step S383).
  • the conference A management unit 53a of the PoC management server 5 receives the image data from the user terminal A and stores it in the image data storage unit 535a (step S385).
  • the conference A management unit 53a of the PoC management server 5 reads the distribution destination user ID included in the image distribution request stored in the user data storage unit 533a, and further, the distribution destination user ID power user
  • the IP address of terminal B is specified, and the image data stored in image data storage unit 535a and received from user terminal A is transmitted to user terminal B (step S387).
  • the IP address corresponding to the user ID is acquired from the SIPZSIMPLE server 3.
  • the image processing unit 916 of the client application 91 of the user terminal B receives the image data from the PoC management server 5 and displays it on the display device (step S3 89). In this way, the user terminal B can receive the image data uploaded by the user A.
  • the image data is separately transmitted to a subset of the participants of the audio-based electronic conference. You will be able to interact. Since the distribution of image data is realized using presence technology, the resources prepared for voice-based electronic conferences can be used effectively.
  • FIGS. 1 to 4 are examples, and may not necessarily match the actual program module configuration. Furthermore, as for the data holding methods shown in FIGS. 5 to 13, other methods can be adopted as long as similar data can be managed.
  • the SIP / SIMPLE server 3, the PoC management server 5, and the PoC-MCU server 7 are computer devices, as shown in FIG. 30, and are a memory 2501, a CPU 2503, and a node device.
  • the operating system (OS) and the application program for executing the processing in the present embodiment are included in the HDD2505, and when executed from the CPU2503, the memory 2501 is stored in the HDD2505. Is read out.
  • the CPU 2503 controls the display control unit 2507, the communication control unit 2517, and the drive device 2513 to perform necessary operations.
  • the data being processed is stored in the memory 2501 and stored in the HDD 2505 if necessary.
  • the application “program for executing the processing described above” is stored in the removable disk 2511 and distributed, and installed in the HDD 2505 from the drive device 2513. It may be installed in HDD2505 via network such as the Internet and communication control unit 2517.
  • Such a computer device realizes various functions as described above through the organic cooperation between the hardware such as CPU2503 and memory 2501 described above, the OS, and the necessary application programs. To do.
  • the user terminal can also be represented by a substantially similar configuration by providing a storage device such as a flash memory instead of the HDD 2505 and the drive device 2513.
  • a storage device such as a flash memory instead of the HDD 2505 and the drive device 2513.
  • step S115 in FIG. 20 a configuration has been described in which a participant presence registration request is transmitted from the PoC management server 5 to the SIP / SIMPLE server 3 for each participant.
  • the meeting A management unit 53a of the PoC management server 5 does not immediately send the presence registration request of the participant immediately after accepting the participation response for a predetermined time. Participant presence registration requests may be sent.
  • the first predetermined period there is a high possibility that multiple participants will reply with a participation response. Therefore, when a large number of participants' presence registration requests are transmitted, presence data is frequently updated, and if presence data updates are frequently notified to the user terminal, the communication bandwidth of the wireless section is reduced. Will be consumed.
  • step S115 and subsequent steps may be performed every time a participation response is received.
  • PoC management server 5 has the ability to execute a proxy subscription request on behalf of the user.
  • SIPZSIMPLE server 3 may automatically change the subscription relationship.
  • a chat call process may be applied.
  • the processing of steps S201 to S267 should be performed as a call processing for image distribution.
  • the image data related to image distribution may be a still image or a moving image. Other files can be distributed as well.

Abstract

　本発明のコンピュータシステムは、プレゼンスデータに関連する処理を実施するプレゼンス管理手段を有するプレゼンス・サーバと、会議の制御処理を実施する会議管理サーバとを有する。会議管理サーバは、音声ベースの電子会議の第１の参加者の端末から当該音声ベースの電子会議の他の参加者に対する画像配信の依頼を受信した場合、画像配信のためのリソースを確保すると共に、当該画像配信のためのリソースに関するデータを、第１の参加者と他の参加者とが講読できるように、プレゼンス設定要求をプレゼンス・サーバに送信する。プレゼンス・サーバのプレゼンス管理手段は、プレゼンス設定要求に応じて、第１の参加者と他の参加者とが、画像配信のためのリソースに関するデータを、更新時に講読者に配信されるプレゼンスデータとして講読できるように設定するものである。

Description

明 細 書
通信制御方法、コンピュータ 'システム、会議管理サーバ、通信方法及び 携帯端末
技術分野
[0001] 本発明は、電子会議における通信制御技術に関する。
背景技術
[0002] 例えば特開 2003— 298751号公報には、電話システムを構成する交換機や中継 機の大幅な技術的変更を必要とせずに、既存の電話システムにお 、て 3名以上のグ ループ通話を実現するための技術が開示されている。すなわち、発信者のユーザ ID 、電話番号及びパスワードを含む発信者情報と当該発信者が通話を希望する複数 の通話先受信者の電話番号を、通信ネットワークに接続された電話帳データベース に予め登録するステップと、前記発信者が、前記電話帳データベースにアクセスして 、前記電話帳データベースに登録されている当該発信者の前記通話先受信者を選 択するステップと、前記電話帳データベースが、同時回線接続手段を有するコール センターに対して前記発信者の電話番号と当該発信者が選択した通話先受信者の 電話番号を送信するステップと、前記コールセンタが、前記同時回線接続手段を介 して前記発信者の電話番号と当該発信者が選択した前記通話先受信者の電話番号 に対して一斉発呼するステップとを含み、前記発信者が前記選択された複数の通話 先受信者との同時通話を可能にする。但し、会議の通信形態を途中で追加'変更す るような発想は開示されて 、な 、。
[0003] また、特開 2004— 13303号公報には、インスタントメッセージング (IM)技術を電 子会議に応用する技術が開示されている。具体的には、 IMサーバに、各 IMクライア ントのプレゼンス情報、利用可能メディア及びユーザ情報を管理させ、各 IMクライア ントがこれらの情報を取得できるようにする。テキストチャットを行なう場合、 IMサーバ が各参加 IMクライアントと IMサーバとの間のコネクションを管理し、各参加 IMクライ アントからのテキストをマージして結果を各参加 IMクライアントに配信する。音声チヤ ットを行なう場合、 APサーバが各参カロ IMクライアントと MDサーバとの間のコネクショ ンを管理し、 MDサーバが注目 IMクライアントを除く各参加 IMクライアントからの音 声をミックスして結果を注目 IMクライアントに配信する。この処理を各参加 IMクライア ントに対して行なう。但し、本公報は、プレゼンス技術の一般的な使い方 (オフライン、 IM中と!、つたクライアントの状態を示すと!、う使い方）を示すのみであり、プレゼンス データの使用の仕方に特別なものはな 、。
特許文献 1：特開 2003— 298751号公報
特許文献 2：特開 2004 - 13303号公報
発明の開示
発明が解決しょうとする課題
[0004] 近年、携帯電話機等の携帯端末を用いて電子会議を行なう技術 (PoCシステム)が 提案されるようになってきている。このような電子会議の最中においては、画像データ を参加者同士で参照しながら電子会議を行なうことが望ましい場合がある。また、画 像データの参照を、会議参加者の一部のメンバに限定することが好ましい場合もある
[0005] 従って、本発明の目的は、携帯端末を用いた電子会議において、会議継続中に画 像データ等のやりとりを容易にするための技術を提供することである。
課題を解決するための手段
[0006] 本発明の第 1の態様に係る通信制御方法は、会議管理サーバにより実行され、音 声ベースの電子会議の第 1の参加者による当該音声ベースの電子会議の他の参カロ 者に対する画像配信依頼を、第 1の参加者の端末から受信するステップと、第 1の参 加者と他の参加者とが、更新時に講読者に配信されるプレゼンスデータとして管理さ れる、画像配信に関するデータを講読できるように、プレゼンス管理設定をプレゼン ス 'サーバに行わせる設定ステップとを含む。
[0007] このようにプレゼンスデータとして画像配信に関するデータが管理されるので、プレ ゼンス技術を用いて音声ベースの電子会議の参加者に画像を配信することができる ようになる。
[0008] また、第 1の参加者の端末から画像データを受信し、画像配信用のデータ記憶領 域に格納するステップと、画像データの受信に応答して、第 1の参加者のプレゼンス データの更新設定をプレゼンス ·サーバに行わせるステップとをさらに含むようにして もよ 、。第 1の参加者のプレゼンスデータを例えば画像配信中と!/、つたように変更す ることによって、自動的にプレゼンスデータとして他の参加者に配信されるので、他の 参加者は第 1の参加者による画像データの送受信状況を知ることができる。
[0009] さらに、上で述べた画像配信に関するデータが、画像配信に係るユーザの識別情 報と画像配信用リソースに関するデータとを含むようにしてもよい。ユーザの識別情 報だけではなぐ当該ユーザの画像配信状況などを含むようにしても良い。また、画 像配信用リソースには IPアドレス及びポート番号等の場合もある。
[0010] さらに、上で述べた設定ステップが、画像配信に関するデータをプレゼンスデータと して登録するようにプレゼンス ·サーバに要求するステップと、画像配信に関するデー タをプレゼンスデータとして公開するようにプレゼンス ·サーバに要求するステップとを 含むようにしてもよい。このよう〖こすること〖こよって、画像配信に関するデータの配信 先を容易に且つ柔軟に設定することができる。
[0011] さらに、第 1の参加者力 画像データを受信し、画像配信用のデータ記憶領域に格 納するステップと、画像データの受信に応答して、画像配信に関するデータを含むプ レゼンスデータの更新設定をプレゼンス 'サーバに行わせるステップとをさらに含むよ うにしてもよい。例えば、画像配信に関するデータに、配信依頼者による画像アップ ロードの完了を表すデータを含めることによって、他の参加者は第 1の参加者による 画像データの送受信状況を知ることができる。
[0012] また、他の参加者が、音声ベースの電子会議の第 1の参加者により指定された音声 ベースの電子会議の参加者のサブセットである場合もある。さらに、画像配信に関す るデータを含むプレゼンスデータは、音声ベースの電子会議の一つに対し、複数管 理されるようにしてちょい。
[0013] 本発明の第 2の態様に係るコンピュータ 'システムは、プレゼンスデータに関連する 処理を実施するプレゼンス管理手段を有するプレゼンス ·サーバと、会議の制御処理 を実施する会議管理サーバとを有する。そして、会議管理サーバは、音声ベースの 電子会議の第 1の参加者の端末力 当該音声ベースの電子会議の他の参加者に対 する画像配信の依頼を受信した場合、画像配信のためのリソースを確保すると共に、 当該画像配信のためのリソースに関するデータを、第 1の参加者と他の参加者とが講 読できるように、プレゼンス設定要求をプレゼンス 'サーバに送信する。そして、プレ ゼンス 'サーバのプレゼンス管理手段は、プレゼンス設定要求に応じて、第 1の参カロ 者と他の参加者とが、画像配信のためのリソースに関するデータを、更新時に講読者 に配信されるプレゼンスデータとして講読できるように設定するものである。
[0014] 本発明の第 3の態様に係る携帯端末は、音声ベースの電子会議の第 1の参加者の 端末力 サーバへ画像データが格納されたことを契機にして上記サーバより配信さ れ且つ更新時に講読者に配信されるプレゼンスデータとして管理される画像データ 配信用のリソースに関するデータを受信するプレゼンスデータ処理部と、上記受信の 後に、画像データ配信用のリソースに関するデータを用いて、当該画像データ配信 用のリソースから画像データを取得する画像処理部とを有する。携帯端末でも、電子 会議中に画像データ等のやりとりができるようになる。
[0015] 本発明の第 4の態様に係る携帯端末は、音声ベースの電子会議の第 1の参加者の 端末からの画像配信依頼をサーバが受信したことを契機にして上記サーバより配信 され且つ更新時に講読者に配信される第 1のプレゼンスデータとして管理される画像 データ配信用のリソースに関する情報を受信し、第 1の参加者の端末から上記サー バへ画像配信依頼に対応する画像データが格納されたことを契機にして前記サー ノなり配信される、第 1の参加者の状態に関する第 2のプレゼンスデータを受信する プレゼンスデータ処理部と、第 2のプレゼンスデータの受信の後に、第 1のプレゼンス データに含まれる画像データ配信用のリソースに関するデータを用いて、当該画像 データ配信用のリソースから画像データを取得する画像処理部とを有する。
[0016] 上で述べた通信制御方法をコンピュータに実行させるためのプログラム、会議管理 サーバ又はプレゼンス ·サーバに上で述べた処理を実行させるためのプログラム、及 び携帯端末を上で述べたように動作させるためのプログラムを作成することができ、こ のプログラムは、例えばフレキシブルディスク、 CD-ROM,光磁気ディスク、半導体 メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークな どを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメモリ 等の記憶装置に一時保管される。 図面の簡単な説明
[図 1]図 1は本発明の一実施例に係るシステム構成図である。
[図 2]図 2はユーザ端末の機能ブロック図である。
[図 3]図 3はユーザ Aプレゼンス管理部の機能ブロック図である。
[図 4]図 4は会議 Aプレゼンス管理部の機能ブロック図である。
[図 5]図 5はユーザ Aプレゼンス管理部におけるプレゼンスデータ格納部に格納され るデータの模式図である。
[図 6]図 6は会議 Aプレゼンス管理部におけるプレゼンスデータ格納部に格納される データの模式図である。
[図 7]図 7はプレゼンス IDが" FloorUser"のプレゼンスデータの一例を示す図である
[図 8]図 8はプレゼンス IDが" JoinUser"のプレゼンスデータの一例を示す図である。
[図 9]図 9はプレゼンス IDが" Member"のプレゼンスデータの一例を示す図である。
[図 10]図 10はプレゼンス IDが" ChatUser"のプレゼンスデータの一例を示す図であ る。
[図 11]図 11はプレゼンス IDが" Chat"のプレゼンスデータの一例を示す図である。
[図 12]図 12はプレゼンス IDが" Photo"のプレゼンスデータの一例を示す図である。
[図 13]図 13はプレゼンス IDが" PhotoUser"のプレゼンスデータの一例を示す図で ある。
[図 14]図 14は本発明の一実施例の処理フローの第 1の部分を示す図である。
[図 15]図 15は本発明の一実施例の処理フローの第 2の部分を示す図である。
[図 16]図 16は本発明の一実施例の処理フローの第 3の部分を示す図である。
[図 17]図 17は本発明の一実施例の処理フローの第 4の部分を示す図である。
[図 18]図 18は本発明の一実施例の処理フローの第 5の部分を示す図である。
[図 19]図 19は本発明の一実施例の処理フローの第 6の部分を示す図である。
[図 20]図 20は本発明の一実施例の処理フローの第 7の部分を示す図である。
[図 21]図 21は本発明の一実施例の処理フローの第 8の部分を示す図である。
[図 22]図 22は本発明の一実施例の処理フローの第 9の部分を示す図である。 [図 23]図 23は本発明の一実施例におけるチャット開始処理の処理フローの第 1の部 分を示す図である。
[図 24]図 24は本発明の一実施例におけるチャット開始処理の処理フローの第 2の部 分を示す図である。
[図 25]図 25は本発明の一実施例におけるチャット開始処理の処理フローの第 3の部 分を示す図である。
[図 26]図 26は本発明の実施例における画像配信処理の第 1乃至第 3の処理フロー の第 1の部分を示す図である。
[図 27]図 27は本発明の実施例における画像配信処理の第 1の処理フローの第 2の 部分を示す図である。
[図 28]図 28は本発明の実施例における画像配信処理の第 2の処理フローの第 2の 部分を示す図である。
[図 29]図 29は本発明の実施例における画像配信処理の第 3の処理フローの第 2の 部分を示す図である。
[図 30]図 30はコンピュータの機能ブロック図を示す図である。
発明を実施するための最良の形態
[0018] 図 1に本発明の一実施例に係るシステム概要図を示す。例えば携帯電話網である ネットワーク 1には、図示しない無線基地局を介して複数の携帯電話機 (ここではュ 一ザ Aが操作するユーザ端末 A及びユーザ Bが操作するユーザ端末 B)が接続され ている。携帯電話機は、 PHS (Personal Handyphone System)端末の場合もあり、音 声通話機能を有するだけではなぐメール'クライアント、ウェブ (Web)ブラウザ、本実 施例におけるクライアントアプリケーションなどの各種アプリケーションプログラムを実 行することができる。また、ユーザ端末 A及び Bは、音声通話機能付きの PDA (Perso nal Digital Assistant)等の携帯端末であってもよい。本実施例におけるユーザ端末 A 及び Bについては、後に機能ブロック図を用いて説明する。
[0019] ネットワーク 1には、 SIPZSIMPLEサーバ 3と、 PoC (Push-to-talk over Cellular) 管理サーバ 5と、 PoC - MCU (Multipoint Communication Unit)サーバ 7とが接続さ れている。 SIP/SIMPLEサーバ 3と PoC管理サーバ 5は、それらの機能を備えた 1 台のサーバコンピュータであってもよい。
[0020] SIP/SIMPLEサーバ 3は、ユーザ Aのプレゼンス管理部 3 laと、ユーザ Bのプレ ゼンス管理部 31bと、会議 Aのプレゼンス管理部 33aと、会議 Bのプレゼンス管理部 3 3bと、ルーティング処理部 35とを有する。ここでは説明を簡単にするためユーザ A及 び Bのプレゼンス管理部のみを示して!/、るが、ユーザの数だけプレゼンス管理部は 設けられる。また、図 1では会議 A及び Bのプレゼンス管理部のみを示している力 会 議の数だけプレゼンス管理部は設けられる。また、 SIPZSIMPLEサーバ 3には、ュ 一ザの認証処理を行う処理部など本実施例と直接関係しない処理部も含まれるが、 ここでは図示して!/、な!/、。ユーザのプレゼンス管理部及び会議のプレゼンス管理部 につ 、ては、後に機能ブロック図を用いて説明する。
[0021] PoC管理サーバ 5は、 PoC制御サーバとも呼ばれ、電子会議の制御及び管理を行 うサーバであり、各会議のための処理を行う会議管理部 53 (ここでは会議 Aのための 処理を行う会議 A管理部 53a及び会議 Bのための処理を行う会議 B管理部 53b)と、 SIPZSIMPLEサーバ 3のルーティング処理部 35から転送されてくるメッセージを担 当の会議管理部 53に転送する振分処理を実施するメッセージ振分処理部 51とを含 む。また、会議管理部 53は、 MCU情報格納部 531 (ここでは会議 Aの MCU情報格 納部 53 la)と、ユーザデータ格納部 533 (ここでは会議 Aのユーザデータ格納部 53 3a)と、画像データ格納部 535 (ここでは会議 Aの画像データ格納部 535a)とを含む 。画像データ格納部 535aは、会議 Aの参加者に配信すべき画像データを格納する 。このように、 PoC管理サーバ 5は、会議 Aの参加者に配信すべき画像データの管理 をも行う。
[0022] また、 PoC— MCUサーバ 7は、各会議のための音声通信を管理及び制御する会 議音声通信管理部 71 (ここでは会議 Aのための処理を行う会議 A音声通信管理部 7 la及び会議 Bのための処理を行う会議 B音声通信管理部 71b)を含み、会議音声通 信管理部 71は話者及び参加者データ格納部 711 (ここでは会議 Aの話者及び参加 者データ格納部 71 la)を含む。
[0023] 図 1において、ユーザ端末は、ネットワーク 1を介して SIP/SIMPLEサーバ 3と SI MPLE (SIP (session Initiation Protocol) for Instant Messaging and Presence Levera ging Extensions) ZTCPで通信を行い、ネットワーク 1を介して PoC— MCUサーバ 7 とは RTP (ReaH:ime Transport Protocol) ZUDPで通信を行うようになっている。
[0024] 次に図 2にユーザ端末の機能ブロック図を示す。ユーザ端末は、本実施例における 処理を行うためのクライアントアプリケーション 91と、ユーザ端末に設けられているマ イクのマイクドライバ 93とを含む。クライアントアプリケーション 91は、音声会議処理部 911と、チャット処理部 913と、プレゼンスデータ処理部 915と、画像処理部 916とを 含む。画像処理部 916は、ユーザからの画像配信依頼を受け付け、 PoC管理サー ノ ¾等に必要な処理を依頼したり、画像データ自体を送信したり、さらに PoC管理サ ーバ 5から画像データを受信して表示装置に表示したりする。なお、本実施例におい て直接関係のな ヽ機能にっ ヽては図示されて!ヽな ヽ。
[0025] また図 3にユーザ Aのプレゼンス管理部 31aの機能ブロック図を示す。ユーザ Aの プレゼンス管理部 3 laは、プレゼンスデータ管理部 311aと、プレゼンスデータ格納 部 313aと、配信処理部 315aとを有している。ユーザ Aのプレゼンス管理部 3 laは、 ユーザ端末 Aのクライアントアプリケーション 91と協働してプレゼンスデータ格納部 3 13aに格納されたデータの更新を行ったり、プレゼンスデータ格納部 313aに格納さ れたデータの配信処理を行う。
[0026] さらに図 4に会議 Aのプレゼンス管理部 33aの機能ブロック図を示す。会議 Aのプレ ゼンス管理部 33aは、プレゼンスデータ管理部 33 laと、プレゼンスデータ格納部 33 3aと、配信処理部 335aとを有している。会議 Aのプレゼンス管理部 33aは、 PoC管 理サーバ 5の会議 A管理部 53a及びユーザ端末のクライアントアプリケーション 91と 協働してプレゼンスデータ格納部 333aに格納されたデータの更新を行ったり、プレ ゼンスデータ格納部 333aに格納されたデータの配信処理を行う。
[0027] 図 5にユーザ Aプレゼンス管理部 3 laに含まれるプレゼンスデータ格納部 313aに 格納されるデータの一例を示す。図 5の例では、プレゼンスデータ格納部 313aは、 プレゼンス情報格納領域 3131と、プレゼンスグループ情報格納領域 3133と、講読 者リスト格納領域 3135とを含む。プレゼンス情報格納領域 3131は、プレゼンスデー タ項目ごとにプレゼンスデータ (ここではユーザ又はユーザ端末の状態情報)を格納 するための領域であり、プレゼンスデータ項目の IDであるプレゼンス IDが" State"で あるプレゼンスデータ（主に ONLINE、 OFFLINE又は BUSYのいずれ力。但し、 他の状態（例えば「画像配信中」又は「Photo Sending」など）であってもよい。）を 格納するための領域 316を含む。プレゼンスデータ項目の数に制限はないが、本実 施例ではユーザ端末の状態を示すプレゼンスデータ項目のみが示されている。プレ ゼンスグループ情報格納領域 3133は、プレゼンスデータ項目（すなわちプレゼンス I D)と配信先ユーザ ID (すなわち講読者 ID)を対応付けるためのデータを格納する領 域である。ここでは、プレゼンスグループであるグループ I「デフォルト」に属するプレ ゼンス IDを格納する領域 3171及びユーザ ID (すなわち講読者 ID)を格納する領域 3172を含む領域 317が含まれる。デフォルトグループは、講読者が初期的に登録さ れるグループである。グループ数に限定はなぐ任意の数のグループを定義し得る。 講読者リスト格納領域 3135は、ここでは UserB及び UserCといった情報配信が許可 されたユーザのユーザ ID (すなわち講読者 ID)が登録される。講読者数に限定はな ぐ任意の数の講読者が登録される。
また図 6に会議 Aプレゼンス管理部 33aに含まれるプレゼンスデータ格納部 333a に格納されるデータの一例を示す。図 6の例では、プレゼンス情報格納領域 3331と 、プレゼンスグループ情報格納領域 3333と、講読者リスト格納領域 3335とが含まれ る。プレゼンス情報格納領域 3331は、プレゼンスデータ項目の IDであるプレゼンス I Dが" FloorUser"であるプレゼンスデータ（ここでは話者権（発言権とも呼ぶ）を有す るユーザの講読者 ID)を格納するための領域 3361と、プレゼンスデータ項目の IDで あるプレゼンス IDが" Member"であるプレゼンスデータ（ここでは音声会議に呼び出 されたユーザの講読者 ID)を格納するための領域 3362と、プレゼンスデータ項目の IDであるプレゼンス IDが" JoinUser"であるプレゼンスデータ（ここでは音声会議に 参カロしたユーザの講読者 ID)を格納するための領域 3363と、プレゼンスデータ項目 の IDであるプレゼンス IDが" Chat"であるプレゼンスデータ（ここではチャット（文字べ ースの電子会議）の発言内容）を格納するための領域 3364と、プレゼンスデータ項 目の IDであるプレゼンス IDが" ChatUser"であるプレゼンスデータ（ここではチャット の参加ユーザの講読者 ID)を格納するための領域 3365と、プレゼンスデータ項目の IDであるプレゼンス IDが" Photo"であるプレゼンスデータ（ここでは指定されたユー ザへ配信されるべき画像データのアップロード先リソース又は配信元リソース (例えば IPアドレス XXX.XXX.XXX.XXX及びポート番号 XXXX)若しくはその両方）を格納するための 領域 3366と、プレゼンスデータ項目の IDであるプレゼンス IDが" PhotoUser"であ るプレゼンスデータ (ここでは画像配信先のユーザの講読者 ID)を格納するための領 域 3367とを含む。
[0029] 本実施例では、プレゼンス IDが" Member"、 "JoinUser"、 "ChatUser"及び" Ph otoUser"であるプレゼンスデータについては、講読者 IDのみが通知され、その講読 者 IDのユーザがいかなる状態にあるかについては通知していない。しかし、講読者 I Dに追加して状態データ (例えば「書き込み中」「画像配信」など）を付加的に登録し、 ユーザ端末にぉ 、て当該ユーザにっ 、ての表示を変更するようにしても良 、。例え ば「書き込み中」マークを付したり、「画像配信中」のマークに変更したりする。さらに、 プレゼンス IDが" Photo"であるプレゼンスデータにつ!、ては、複数のユーザが画像 を配信する場合に対応するため、アップロード先リソースと配信元リソースと登録する ようにしても良 ヽ。例えば xxx.xxx.xxx.xxx:xxxxをアップロード先リソースとして登録す ると共に、 ftp://yyy.yyy.yyy.yyy/imagefromUserA.jpg及び ftp://yyy.yyy.yyy.yyy/ima gefromUserB.gifといったように、複数のアドレス情報を含めるようにしても良い。さらに 、上の例ではファイル名に送信元ユーザの名前を含めるようにしている力 アドレスと は別に配信元ユーザを特定する情報を登録するようにしても良い。さらに必要であれ ば、状態を表すプレゼンスデータを登録するようにしても良い。なお、複数の画像ファ ィルを同時に配信可能としなくともよい。
[0030] また、プレゼンスグループ情報格納領域 3333は、プレゼンスグループであるグル ープ I「デフォルト」に属するプレゼンス IDを格納する領域 3371及びユーザ ID (すな わち講読者 ID)を格納する領域 3373を含む領域 337と、プレゼンスグループである グループ II「音声会議」に属するプレゼンス IDを格納する領域 3381及びユーザ ID ( すなわち講読者 ID)を格納する領域 3382を含む領域 338と、プレゼンスグループで あるグループ III「チャット」に属するプレゼンス IDを格納する領域 3391及びユーザ ID (すなわち講読者 ID)を格納する領域 3392を含む領域 339と、プレゼンスグループ であるグループ IV「画像」に属するプレゼンス IDを格納する領域 3401及びユーザ ID (すなわち講読者 ID)を格納する領域 3402を含む領域 340とを含む。
[0031] 音声会議に参加するユーザの講読者 IDは領域 3382に格納され、音声会議に参 加するユーザに開示されるデータはプレゼンス IDが" FloorUser"と" Member"と" J oinUser"であるプレゼンスデータである。すなわち、話者権保持者の講読者 IDと、 呼び出されたユーザの講読者 IDリストと、参加したユーザの講読者 IDリストが提示さ れる。また、チャットに参加するユーザの講読者 IDは領域 3392に格納され、チャット に参加するユーザに開示されるデータはプレゼンス IDが" Chat"ど' ChatUser"であ るプレゼンスデータである。すなわち、チャット参加者の講読者 IDリストとチャットの発 言内容とが提示される。また、画像配信に参加するユーザの講読者 IDは領域 3402 に格納され、画像配信に参加するユーザに開示されるデータはプレゼンス IDが" Ph oto"であるプレゼンスデータと" PhotoUser"であるプレゼンスデータである。すなわ ち、画像配信への参加者の講読者 IDリストと配信される画像のアップロード先リソー ス (IPアドレス及びポート番号)又は配信元リソース若しくはその両方である。講読者リ スト格納領域 3335には、ここでは UserA、 UserB、 UserCといった情報配信が許可 されたユーザのユーザ ID (すなわち講読者 ID)が登録される。
[0032] なお、画像データの配信先であるユーザは、音声会議に参加して 、るユーザの一 部であってもよいし、全員であってもよい。配信先が音声会議に参加しているユーザ 全員の場合には、プレゼンス IDが" PhotoUser"のプレゼンスデータを格納する領 域 3367を設けずに、プレゼンス IDが" JoinUser"であるプレゼンスデータを用いるよ うにしても良い。すなわち、グループ IV「画像」に属するプレゼンス IDを格納する領域 3401に" Photo"と" JoinUser"を登録するようにしてもよ!ヽ。
[0033] プレゼンス情報領域 3331のプレゼンス IDが" Chat"であるプレゼンスデータと、プ レゼンス IDが" ChatUser"であるプレゼンスデータとは、プレゼンスグループ情報領 域 3333のグループ III「チャット」 339に対応するものであり、 1つの会議に対するプレ ゼンスデータ格納部 333aの中に、それぞれ識別可能な形で、例えばグループ III「チ ャット」、グループ VI「チャット」というようにチャットに関連するグループのデータ領域、 それに対応するチャットの参加ユーザの講読者 IDを格納するための領域及びチヤッ トの内容を格納するための領域を複数セット設けることも可能である。これは画像配 信についても同様であって、 1つの会議に対するプレゼンスデータ格納部 333aの中 に、それぞれ識別可能な形で、例えばグループ IV「画像」、グループ VII「画像」という ようにチャットに関連するグループのデータ領域、それに対応する画像配信の参加ュ 一ザの講読者 IDを格納するための領域及び画像配信用のリソースを格納するため の領域を複数セット設けることも可能である。
[0034] 図 5及び図 6は、プレゼンスデータ格納部に格納されるデータを模式的に示したも のであり、例えばプレゼンス IDが" FloorUser"であるプレゼンスデータのための領域 3361に、例えば図 7に示すようなタグデータ構造のデータを格納する。図 7の例は、 基本的には OMA (Open Mobile Alliance)に準拠した形で XML (extensible Markup Language)を用いて記述されている。ここで注目すべきは、上力 4行目に entity = " pres： Conf erenceO 1 @ poc . fj . com"というフレーズにて、プレゼンス ID力 ， Floor User"であるプレゼンスデータの所有者力 Conference01 @poc. fj . comという SI P- URL (Uniform Resource Locator)で特定されている点である。ここで、このプレゼ ンスデータの所有者は PoC管理サーバ 5の会議 A管理部 53aであり、このプレゼンス データは会議 A管理部 53aにより更新される。また、会議 A管理部 53aの SIP— URL は Conference01 @poc. fj. comである。さらに、く note >及びく Znote>タグと の間に話者権保持者のユーザ IDとして SIP— URL"UserA@poc. fj. com"が登 録される。図 5及び図 6では、 "UserA® poc. fj. com"を簡略表示して" UserA"と 示している。
[0035] 同様に、プレゼンス IDが" JoinUser"であるプレゼンスデータのための領域 3363に 、例えば図 8に示すようなタグデータ構造のデータを格納する。図 8の例では、図 7と 同様に、このプレゼンスデータの所有者が、 Conference01 @poc. fj . comという SI P URLで特定されており、 < note >及びく Znote >タグとの間に音声会議の参 加者の SIP— URL，，UserA@poc. fj . com, UserB@poc. fj . com"がユーザ IDと して登録される。
[0036] さらに、プレゼンス IDが" Member"であるプレゼンスデータのための領域 3362に、 例えば図 9に示すようなタグデータ構造のデータを格納する。図 9の例では、図 7と同 様に、このプレゼンスデータの所有者が、 Conference01 @poc. fi . comという SIP URLで特定されており、 < note >及び < Znote >タグとの間に音声会議に呼び 出されたユーザの SIP— URL，，UserA@poc. fj . com, UserB@poc. fj. com, U serC@poc. fj . com"がユーザ IDとして登録される。
[0037] また、プレゼンス IDが" ChatUser"であるプレゼンスデータのための領域 3365に、 例えば図 10に示すようなタグデータ構造のデータを格納する。図 10の例では、図 7 と同様に、このプレゼンスデータの所有者が、 Conference01 @poc. fj . comという SIP URLで特定されており、 < note >及びく Znote >タグとの間にチャットに参 加したユーザの SIP— URL，，UserA@poc. fj . com, UserB@poc. fj. com"がュ 一ザ IDとして登録される。
[0038] さらに、プレゼンス IDが" Chat"であるプレゼンスデータのための領域 3364に、例 えば図 11に示すようなタグデータ構造のデータを格納する。図 11の例では、図 7と 同様に、このプレゼンスデータの所有者が、 Conference01 @poc. fj . comという SI P URLで特定されており、 < note >及び < Znote >タグとの間にチャットの発言 内容"こんにちは。 · · · "が登録される。なお、本プレゼンスデータの所有者は、会議 A管理部 53aであり、上で述べた他のプレゼンスデータと同じであるが、プレゼンス I Dが" ChatUser"であるプレゼンスデータのための領域 3365に格納されているユー ザ IDのユーザにも更新権限を与えるように設定が行われているものとする。
[0039] また、プレゼンス IDが" PhotoUser"であるプレゼンスデータのための領域 3367に 、例えば図 12に示すようなタグデータ構造のデータを格納する。図 12の例では、図 7 と同様に、このプレゼンスデータの所有者が、 Conference01 @poc. fj . comという SIP— URLで特定されており、く note >及びく Znote >タグとの間に画像配信に 参加するユーザの SIP— URL，，UserA@poc. fj. com, UserB@poc. fj . com"が ユーザ IDとして登録される。
[0040] さらに、プレゼンス IDが" Photo"であるプレゼンスデータのための領域 3366に、例 えば図 13に示すようなタグデータ構造のデータを格納する。図 13の例では、図 7と 同様に、このプレゼンスデータの所有者が、 Conference01 @poc. fj . comという SI P URLで特定されており、 < note >及び < Znote >タグとの間に画像のアップ口 ード先リソース (IPアドレス及びポート番号)又は配信元リソース若しくはその両方など が登録される。また、上でも述べたが、さらに多くのデータを登録するようにして、画像 配信への参加者により多くのデータを通知するようにしても良 、。
[0041] プレゼンスデータは原則として所有者により更新され、更新されると当該プレゼンス データのプレゼンス IDが関連付けられているユーザ IDのユーザに配信処理部により 配信される。また、 PoC管理サーバ 5の会議 A管理部 53a及び会議 B管理部 53bなど は、 SIPZSIMPLEサーバ 3中のプレゼンスデータに対してスーパーバイザ権限を 有するようにして、必要なプレゼンスデータの変更を随時行うようにしても良 、。
[0042] 次に、図 14乃至図 29を用いて図 1乃至図 4に示したシステムの処理フローを説明 する。なお、ユーザはすべて SIPZSIMPLEサーバ 3にログインして、認証が済んで いるものとする。さらに、ユーザ端末の IPアドレスとユーザ ID (SIP— URL)との対応 付けは、 SIPZSIMPLEサーバ 3内で完了しているものとする。まず、ユーザ Aは、ュ 一ザ端末 Aを操作して、音声ベースの電子会議を開始するため当該会議に呼び出 すメンバを指定して呼出指示を入力する。ユーザ端末 Aにおけるクライアントアプリケ ーシヨン 91の音声会議処理部 911は、音声ベースの電子会議に呼び出すメンバの 呼出依頼についてのユーザ操作入力を受け付け (ステップ S1)、会議メンバのリスト（ 例えば SIP— URLのリスト）を含む呼出依頼を SIP/SIMPLEサーバ 3に送信する（ ステップ S3)。 SIPZSIMPLEサーバ 3のルーティング処理部 35は、ユーザ端末 A 力も会議メンバのリストを含む呼出依頼を受信し、呼出依頼であると判断すると PoC 管理サーバ 5に転送する（ステップ S5)。 PoC管理サーバ 5のメッセージ振分処理部 51は、 SIPZSIMPLEサーバ 3のルーティング処理部 35力 会議メンバのリストを含 む呼出依頼を受信する (ステップ S7)。この受信に応答して、 PoC管理サーバ 5のメッ セージ振分処理部 51は、 OKレスポンスを返信する（ステップ S 9)。 SIP/SIMPLE サーバ 3のルーティング処理部 35は、 PoC管理サーバ 5から OKレスポンスを受信す ると、ユーザ端末 Aに転送する（ステップ Sl l)。ユーザ端末 Aは、 SIP/SIMPLEサ ーバ 3から OKレスポンスを受信する（ステップ S 13)。これにより、ユーザ端末 Aは、呼 出要求が PoC管理サーバ 5により受信されたことを認識することができる。
[0043] PoC管理サーバ 5のメッセージ振分処理部 51は、会議メンバのリストを含む呼出依 頼を受信すると、新規に会議を行うこととなるため、会議管理部 53を新たに起動し（ 例えば会議 A管理部 53aを新たに起動し）、当該会議 A管理部 53aに SIP— URLを 割り当てる (ステップ S14)。会議 A管理部 53aは、会議メンバのリストをユーザデータ 格納部 533aに格納すると共に、会議メンバのリストを含む新規会議作成依頼を、 Po C— MCUサーバ 7に送信する (ステップ S15)。また、会議メンバのリストには、呼出 依頼元ユーザのユーザ ID及びそのユーザ端末の IPアドレスも含まれ、話者権保持 者として特定されている。
[0044] PoC— MCUサーバ 7は、会議メンバのリストを含む新規会議作成依頼を受信する と、新たな会議のためのリソースを確保すべく新たな会議音声通信管理部 71 (例え ば会議 A音声通信管理部 71a)を起動する。そして、会議 A音声通信管理部 71aは、 会議メンバのリストを話者及び参加者データ格納部 71 laに格納する (ステップ S17) 。なお、会議 A音声通信管理部 71aは、会議 A管理部 53aの SIP— URLを保持して おき、会議 A管理部 53aからの指示に応答できるようにする。そして、会議 A音声通 信管理部 71aは、呼出依頼に係る会議において使用されるリソース、すなわち IPアド レス及びポート番号などを確保し、さらに呼出依頼元ユーザに話者権を設定する (ス テツプ S19)。話者権を有するユーザについては、話者及び参加者データ格納部 71 laにおいて識別可能なようにデータが保持されている。本実施例では、話者権を有 する者のみが PoC— MCUサーバ 7に音声データを他の参加者へ転送させることが できる。この後、処理は端子 A乃至 Dを介して図 15の処理に遷移する。なお、呼出依 頼元ユーザのユーザ端末の IPアドレスについては、この段階で、話者及び参加者デ ータ格納部 71 laに登録しておく。
[0045] 図 15を用いて端子 A乃至 D以降の処理について説明する。 PoC— MCUサーバ 7 の会議 A音声通信管理部 71aは、ステップ S19で確保したリソースである IPアドレス 及びポート番号を音声送信先情報として PoC管理サーバ 5に送信する (ステップ S21 ) o PoC管理サーバ 5の会議 A管理部 53aは、 PoC— MCUサーバ 7から音声送信先 情報を受信し、 MCU情報格納部 531aに格納する (ステップ S23)。そして、会議 A 管理部 53aは、 MCU情報格納部 531aに格納されたデータを用いて、音声送信先 情報（PoC— MCUサーバ 7の IPアドレス及びポート番号）と当該会議 A管理部 53a の SIP— URLを会議情報として SIPZSIMPLEサーバ 3に送信する（ステップ S25) 。 SIP/SIMPLEサーバ 3のルーティング処理部 35は、 PoC管理サーバ 5から会議 情報を受信すると、呼出依頼元のユーザ端末 Aに、当該会議情報を転送する (ステツ プ S27)。なお、このタイミングにて、受信した会議情報に基づき当該会議のプレゼン ス管理部（ここでは会議 Aプレゼンス管理部 33a)を起動するようにしてもよ!、。
[0046] ユーザ端末 Aにおけるクライアントアプリケーション 91の音声会議処理部 911は、 S IPZSIMPLEサーバ 3から会議情報を受信し、記憶装置に格納する (ステップ S29) 。音声会議処理部 911は、 OKレスポンスを SIPZSIMPLEサーバ 3に返信する（ス テツプ S31)。 SIPZSIMPLEサーバ 3のルーティング処理部 35は、ユーザ端末 Aか ら OKレスポンスを受信すると、 PoC管理サーバ 5に転送する（ステップ S33)。 PoC 管理サーバ 5の会議 A管理部 53aは、 SIP/SIMPLEサーバ 3から OKレスポンスを 受信する（ステップ S35)。なお、メッセージ振分処理部 51が、 SIPZSIMPLEサー ノ 3からメッセージ (ここでは OKレスポンス）を受信して、担当の会議 A管理部 53a〖こ 転送する。但し、以下の説明では、メッセージ振分処理部 51の受信については、説 明を省略する。
[0047] またユーザ端末 Aにおけるクライアントアプリケーション 91の音声会議処理部 911 は、会議情報受信に応じて、マイクドライバ 93を起動する (ステップ S37)。すなわち、 ユーザ端末 Aのマイクはユーザ Aの音声を検出して電気信号に変換し、マイクドライ ノ 93は、マイクによって受け付けた音声を送信するため、音声パケットのデータを生 成する。これによりユーザ端末 Aは、受信した会議情報に含まれる IPアドレス及びポ ート番号に従って、 PoC— MCUサーバ 7に音声パケットを送信することができるよう になる。但し、現段階で PoC— MCUサーバ 7に音声パケットを送信しても、 PoC— MCUサーバ 7は他の参加者が特定されて!、な!/、ので、音声パケットのコピー及び転 送を行うことはない。処理は端子 E及び Fを介して図 16の処理に移行する。
[0048] 次に図 16を用いて端子 E及び F以降の処理を説明する。 PoC管理サーバ 5の会議 A管理部 53aは、ユーザデータ格納部 533aに格納されたデータを用いて、呼出依 頼元を除く各会議メンバのプレゼンスデータ取得要求を SIPZSIMPLEサーバ 3に 送信する (ステップ S39)。プレゼンスデータ取得要求は、会議メンバ毎に送信される 。 SIPZSIMPLEサーバ 3における各会議メンバのプレゼンス管理部 31は、 PoC管 理サーバ 5から各会議メンバのプレゼンスデータ取得要求を受信する（ステップ S41)
。通常、ユーザのプレゼンスデータは当該ユーザのみが更新でき、さらに当該ユーザ により許可された者のみが講読できるようになつている。従って、 PoC管理サーバ 5は
、通常であれば会議メンバのプレゼンスデータを取得することはできないが、 PoC管 理サーバ 5からの要求であれば、講読許可がなくともプレゼンスデータの参照を可能 とするようにプレゼンスデータ管理部 311に予め設定しておく。または、上で述べたよ うに SIP/SIMPLEサーバ 3におけるプレゼンスデータに対して PoC管理サーバ 5に スーパーバイザ権限を与えておくようにしても良い。従って、プレゼンスデータ取得要 求を受信したプレゼンス管理部 31のプレゼンスデータ管理部 311は、プレゼンスデ ータ格納部 313から会議メンバのユーザ又はユーザ端末の状態を表すプレゼンスデ ータを読み出し、 PoC管理サーバ 5に送信する (ステップ S43)。
[0049] PoC管理サーバ 5の会議 A管理部 53aは、 SIPZSIMPLEサーバ 3から各会議メ ンバのプレゼンスデータを受信し (ステップ S45)、当該各会議メンバのプレゼンスデ ータから呼出可能な会議メンバを抽出する (ステップ S47)。すなわち、プレゼンスデ ータが通話可能という状態 (例えば ONLINE)を示している会議メンバを抽出する。 OFFLINEや BUSYという状態であれば、音声会議の通話は不可能であるから、以 下で説明する呼出処理を実施しないようにする。これにより呼出処理を高速化するこ とができる。但し、ステップ S39からステップ S47の処理は、オプションである。処理は 、端子 G及び Hを介して図 17の処理に移行する。なお、説明を簡単にするため呼び 出す会議メンバはユーザ端末 Bを操作するユーザ Bのみであるものとする。
[0050] 図 17を用いて端子 G及び H以降の処理を説明する。 PoC管理サーバ 5の会議 A管 理部 53aは、ユーザデータ格納部 533a及び MCU情報格納部 53 laに格納された データを用いて、会議情報（会議 A管理部 53aの SIP— URL及び PoC— MCUサー ノ 7の IPアドレス及びポート番号)を含む、呼出可能な会議メンバに対する呼出を、 S IPZSIMPLEサーバ 3に送信する（ステップ S49)。なお、本呼出には呼出依頼元ュ 一ザのデータを含める。 SIPZSIMPLEサーバ 3のルーティング処理部 35は、 PoC 管理サーバ 5から、会議情報を含む、呼出可能な会議メンバに対する呼出を受信し、 各会議メンバのユーザ端末に当該呼出を転送する (ステップ S51)。ここではユーザ 端末 Bの音声会議処理部 911が、 SIPZSIMPLEサーバ 3から会議情報を含む呼 出を受信し、当該呼出に応じた処理を実施する (ステップ S53)。例えば、着信音を 鳴らせたり、表示装置に所定の表示を行わせたりして、呼出を受信したことをユーザ Bに知らせる。なお、受信した会議情報については記憶装置に格納して、後に参カロ 応答を行う際に用いる。
[0051] ユーザ端末 Bの音声会議処理部 911は、呼出に対する OKレスポンスを SIPZSI MPLEサーバ 3に送信する（ステップ S55)。 SIP/SIMPLEサーバ 3のルーティン グ処理部 35は、ユーザ端末 B力 OKを受信すると、 PoC管理サーバ 5に転送する（ ステップ S57)。 PoC管理サーバ 5の会議 A管理部 53aは、 SIPZSIMPLEサーバ 3 力も OKレスポンスを受信する（ステップ S59)。
[0052] ユーザ Bは、ステップ S53における呼出に応じて、音声会議に参加するか否かを判 断する。参加する場合には、ユーザ端末 Bを操作して会議参加指示を入力する。ュ 一ザ端末 Bの音声会議処理部 911は、ユーザ Bによる会議参加指示入力を受け付け (ステップ S61)、参加応答を SIPZSIMPLEサーバ 3に送信する（ステップ S63)。 S IPZSIMPLEサーバ 3のルーティング処理部 35は、ユーザ端末 B力 参加応答を 受信すると、 PoC管理サーバ 5に転送する（ステップ S65)。 PoC管理サーバ 5の会 議 A管理部 53aは、ユーザ Bからの参加応答を SIPZSIMPLEサーバ 3から受信す る (ステップ S67)。会議 A管理部 53aは、参加応答を行ったユーザのユーザ ID (すな わち SIP— URL)及びそのユーザ端末の IPアドレスをユーザデータ格納部 533aに 参加者として登録する。また、参加応答を行ったユーザのユーザ ID (すなわち SIP— URL)及びそのユーザ端末の IPアドレスを含む参加メンバ追加通知を PoC— MCU サーバ 7に送信する (ステップ S69)。 PoC— MCUサーバ 7の会議 A音声通信管理 部 71aは、 PoC管理サーバ 5から参加者のユーザ ID及び IPアドレスを含む参力!]メン バ追加通知を受信し、話者及び参加者データ格納部 71 laに参加者のユーザ ID及 び IPアドレスを登録する（ステップ S71)。
[0053] ステップ S69の後に、会議 A管理部 53aは、 OKレスポンスを SIP/SIMPLEサー バ 3に送信する（ステップ S73)。 SIPZSIMPLEサーバ 3のルーティング処理部 35 は、 PoC管理サーバ 5から OKレスポンスを受信し、ユーザ端末 Bへ転送する（ステツ プ S75)。ユーザ端末 Bは、 SIPZSIMPLEサーバ 3から OKレスポンスを受信する（ ステップ S77)。
[0054] なお、図 17の処理は、呼出可能な会議メンバ毎に実施される。また、処理は端子 I 及び Jを介して図 18の処理に移行する。
[0055] 図 18を用いて端子 I及び J以降の処理について説明する。 PoC管理サーバ 5の会 議 A管理部 53aは、ユーザデータ格納部 533aに格納されたデータを用いて、話者 権を有するユーザのユーザ IDを含む話者情報のプレゼンス登録要求を生成し、 SIP ZSIMPLEサーバ 3に送信する (ステップ S79)。より具体的には、会議 A管理部 53 aが所有者であって、プレゼンス IDが" FloorUser"であるプレゼンスデータとして話 者権を有するユーザのユーザ IDを登録することを要求する。 SIPZSIMPLEサーバ 3は、 PoC管理サーバ 5から、話者情報のプレゼンス登録要求を受信する。会議 A管 理部 53aのための会議 Aプレゼンス管理部 33aが起動されていない場合にはこのタ イミングにて起動し、会議 Aプレゼンス管理部 33aのプレゼンスデータ管理部 331aは 、受信したプレゼンス登録要求に係るプレゼンス ID ("FloorUser")に対応して話者 権を有するユーザのユーザ IDをプレゼンスデータとしてプレゼンスデータ格納部 33 3aに格納する (ステップ S81)。図 6に示すように、領域 3361に話者権を有するユー ザのユーザ ID"UserA"が登録される。また、会議 Aプレゼンス管理部 33aは、 OKレ スポンスを PoC管理サーバ 5に送信する（ステップ S83)。 PoC管理サーバ 5の会議 A 管理部 53aは、 SIP/SIMPLEサーバ 3から OKレスポンスを受信する（ステップ S85
) o
[0056] さらに、 PoC管理サーバ 5の会議 A管理部 53aは、ユーザデータ格納部 533aに格 納されたデータを用いて、呼出依頼を行ったユーザを含む会議メンバの情報を含む メンバ情報のプレゼンス登録要求を生成し、 SIPZSIMPLEサーバ 3に送信する（ス テツプ S87)。より具体的には、会議 A管理部 53aが所有者であって、プレゼンス ID 力 S"Member"であるプレゼンスデータとして、呼出依頼を行ったユーザを含む会議メ ンバのユーザ IDを登録することを要求する。 SIPZSIMPLEサーバ 3の会議 Aプレ ゼンス管理部 33aは、 PoC管理サーバ 5からメンバ情報のプレゼンス登録要求を受 信し、会議 Aプレゼンス管理部 33aのプレゼンスデータ管理部 33 laは、受信したプ レゼンス登録要求に係るプレゼンス ID ("Member")に対応してプレゼンスデータ（ 図 6の例では" UserA, UserB, UserC")をプレゼンスデータ格納部 333aに格納す る（ステップ S89)。また、会議 Aプレゼンス管理部 33aは、 OKレスポンスを PoC管理 サーバ 5に送信する（ステップ S91)。 PoC管理サーバ 5の会議 A管理部 53aは、 SIP ZSIMPLEサーバ 3から OKレスポンスを受信する（ステップ S93)。
また、 PoC管理サーバ 5の会議 A管理部 53aは、ユーザデータ格納部 533aに格納 されたデータを用いて、呼出依頼を行ったユーザを含む会議メンバにっ 、て代理講 読要求を生成し、 SIPZSIMPLEサーバ 3に送信する (ステップ S95)。より具体的に は、プレゼンスデータ格納部 333aにおける講読者リスト格納領域 3335及びプレゼ ンスグループ情報格納領域 3333におけるグループ II「音声会議」の領域 338内の講 読者 IDのための領域 3382に、会議メンバを登録することを要求する。なお、会議メ ンバではなく呼出依頼を行ったユーザ及び参加応答を行ったユーザを登録するよう に SIPZSIMPLEサーバ 3に要求してもよい。但し、参加応答が行われる毎に、当該 参加応答に係るユーザにっ ヽて代理講読を行う必要がある。会議への参加状況及 び話者権保持者等のプレゼンスデータを、参加応答を行ったユーザのみに配信する の力、又は呼出がなされたユーザに配信するのかは、会議の公開ポリシーにかかわ ることなので、いずれの方式を採用することも可能である。但し、本来、プレゼンスデ ータの講読については、講読を必要とする各ユーザが要求を行い、プレゼンスデー タの所有者の許可を得て講読者として登録するものである。従って、本来ならば、会 議に参加する又は呼び出されたユーザの各々が SIPZSIMPLEサーバ 3にアクセス して、講読登録を要求する必要がある。しかしながら、本実施例では、会議という性格 上、会議への参加状況及び話者権保持者等のプレゼンスデータの講読は、参加者（ 又は呼び出されたユーザ）にとつて必要な情報であるという観点と、各ユーザに講読 登録を行わせる場合には無線区間におけるデータ通信量が増力 tlして通信帯域が無 駄に使用され、会議の進行が遅くなるという観点とから、 PoC管理サーバ 5が代理で 講読登録を行うこととしている。なお、会議 Aプレゼンス管理部 33aのプレゼンスデー タ格納部 333aの所有者は会議 A管理部 53aであり、所有者が代理で講読登録する ことは権限上大きな問題はない。 [0058] SIPZSIMPLEサーバ 3の会議 Aプレゼンス管理部 33aは、 PoC管理サーバ 5から 呼出依頼を行ったユーザを含む会議メンバにつ!、て代理講読要求を受信し、プレゼ ンスデータ管理部 33 laは、プレゼンスデータ格納部 333aの講読者リスト格納領域 3 335に会議メンバ（又は参加者)を登録し、さらにプレゼンスグループ情報格納領域 3 333におけるグループ II「音声会議」の領域 338内の講読者 IDのための領域 3382 に会議メンバ（又は参加者)を登録する (ステップ S97)。また、会議 Aプレゼンス管理 部 33aは、 OKレスポンスを PoC管理サーバ 5に送信する（ステップ S99)。 PoC管理 サーバ 5の会議 A管理部 53aは、 SIPZSIMPLEサーバ 3から OKレスポンスを受信 する（ステップ S101)。処理は端子 K及び Lを介して図 19及び図 20の処理に移行す る。
[0059] このように会議メンバ（又は参加者）が講読者リスト格納領域 3335及びプレゼンスグ ループ情報格納領域 3333におけるグループ II「音声会議」の領域 338内の講読者 I Dのための領域 3382に登録されると、グループ II「音声会議」の領域 338内のプレゼ ンス IDのための領域 3381に登録されたプレゼンス IDのプレゼンスデータ力 配信 処理部 335aにより会議メンバ（又は参加者）に配信されるようになる。
[0060] 次に図 19を用いて端子 K以降の処理について説明する。 SIPZSIMPLEサーバ 3における会議 Aプレゼンス管理部 33aの配信処理部 335aは、プレゼンスデータ格 納部 333aの状態に応じて会議のプレゼンスデータ (話者権保持者のユーザ ID、会 議メンバのユーザ ID及び参加者のユーザ ID)の通知処理を実施する (ステップ S 10 3)。ここではユーザ端末 A及びユーザ端末 Bに会議のプレゼンスデータを送信する。 ユーザ端末 Bのプレゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3から会議 のプレゼンスデータを受信して、表示装置に表示する（ステップ S105)。同じように、 ユーザ端末 Aのプレゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3から会議 のプレゼンスデータを受信して、表示装置に表示する（ステップ S107)。
[0061] この段階では、まだ参加者はプレゼンスデータ格納部 333aに登録されていないの で、会議メンバ及び話者権保持者のみが把握可能な表示が行われる。そして、ユー ザ端末 Bのプレゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3に OKレスポン スを返信し (ステップ S109)、ユーザ端末 Aのプレゼンスデータ処理部 915も、 SIPZ SIMPLEサーバ 3に OKレスポンスを返信する（ステップ S 111)。 SIPZSIMPLEサ ーバ 3の会議 Aプレゼンス管理部 33aは、 OKレスポンスをユーザ端末 A及びユーザ 端末 B力も受信する (ステップ S 113)。処理は、端子 Mを介して図 20の処理に移行 する。
[0062] 次に図 20を用いて端子 L及び M以降の処理について説明する。 PoC管理サーバ 5の会議 A管理部 53aは、ユーザデータ格納部 533aに格納されたデータを用いて、 この段階までに確定している参加者 (参加応答を行ったユーザだけではなく呼出依 頼を行ったユーザを含む）のプレゼンス登録要求を生成し、 SIP/SIMPLEサーバ 3 に送信する (ステップ S115)。より具体的には、会議 A管理部 53aが所有者であって 、プレゼンス IDが" JoinUser"であるプレゼンスデータとして、参加者のユーザ IDを 登録することを要求する。 SIPZSIMPLEサーバ 3の会議 Aプレゼンス管理部 33aは 、 PoC管理サーバ 5から参加者のプレゼンス登録要求を受信し、会議 Aプレゼンス管 理部 33aのプレゼンスデータ管理部 331aは、受信したプレゼンス登録要求に係るプ レゼンス ID ("joinUser")及びプレゼンスデータ（図 6の例では" UserA, UserB") をプレゼンスデータ格納部 333aに格納する（ステップ SI 17)。また、会議 Aプレゼン ス管理部 33aは、 OKレスポンスを PoC管理サーバ 5に送信する（ステップ S 119)。 P oC管理サーバ 5の会議 A管理部 53aは、 SIP/SIMPLEサーバ 3から OKレスポン スを受信する (ステップ S 121)。
[0063] そして、 SIPZSIMPLEサーバ 3における会議 Aプレゼンス管理部 33aの配信処理 部 335aは、プレゼンスデータ格納部 333aの状態に応じて会議のプレゼンスデータ（ 話者権保持者のユーザ ID、会議メンバのユーザ ID及び参加者のユーザ ID)の通知 処理を実施する (ステップ S123)。ここではユーザ端末 A及びユーザ端末 Bに会議の プレゼンスデータを送信する。ユーザ端末 Bのプレゼンスデータ処理部 915は、 SIP ZSIMPLEサーバ 3から会議のプレゼンスデータを受信して、表示装置に表示する（ ステップ S125)。同じように、ユーザ端末 Aのプレゼンスデータ処理部 915は、 SIP ZSIMPLEサーバ 3から会議のプレゼンスデータを受信して、表示装置に表示する（ ステップ S 127)。
[0064] この段階では、ステップ S117において参加者がプレゼンスデータ格納部 333aに 登録されているので、会議メンバ、参加者、話者権保持者、及び呼出を受けて参加し ていないユーザを把握可能な表示がなされる。そして、ユーザ端末 Bのプレゼンスデ ータ処理部 915は、 SIPZSIMPLEサーバ 3に OKレスポンスを返信し (ステップ S 1 29)、ユーザ端末 Aのプレゼンスデータ処理部 915も、 SIPZSIMPLEサーバ 3に O Kレスポンスを返信する（ステップ S 131)。 SIPZSIMPLEサーバ 3の会議 Aプレゼ ンス管理部 33aは、 OKレスポンスをユーザ端末 A及びユーザ端末 B力も受信する（ ステップ S133)。処理は端子 Nを介して図 21の処理に移行する。また、端子 Pを介し て図 22の処理に移行する。
[0065] ステップ S97において会議メンバが講読登録されている場合においては、参加者 が新たに現れる毎に、ステップ S115乃至 S133が実行される。ステップ S97におい て参加者が講読登録されている場合においては、参加者が新たに現れる毎に、ステ ップ S 115乃至 S 133が実行されて、既に参加者として講読登録されて 、るユーザに プレゼンスデータが配信され、さらにステップ S95乃至 S113が実行されて新たな参 加者にプレゼンスデータが配信される。
[0066] 図 20に示した処理が完了した時点において、電子会議の各参加者は、他の参カロ 者を認識でき、会議を開始することができるようになる。なお、話者権については呼出 依頼を行ったユーザが保持して 、るので、このユーザのみが発言することができる。
[0067] すなわち図 21に示すような処理が実施される。ユーザ Aが話者権保持者であるか ら、ユーザ Aはユーザ端末 Aに対して発話する。ユーザ端末 Aは、ユーザ Aからの音 声入力をマイクで受け付け、音声会議処理部 911は、マイクドライバ 93が生成した音 声データ力 音声パケットを生成して、 PoC— MCUサーバ 7に送信する（ステップ S 135)。この際、会議情報として受信した、 PoC— MCUサーバ 7の IPアドレス及びポ ート番号を用いる。すなわち直接 PoC— MCUサーバ 7に音声パケットを送信する。
[0068] PoC— MCUサーバ 7の会議 A音声通信管理部 71aは、ユーザ端末 Aから音声パ ケットを受信し、話者及び参加者データ格納部 71 laに格納されて ヽる参加者 IPアド レス宛に、音声パケットのコピーを転送する（ステップ S137)。ユーザ端末 Bにおける クライアントアプリケーション 91の音声会議処理部 911は、 PoC— MCUサーバ 7から 音声パケットを受信し、図示しな!、スピーカドライバ及びスピーカを介して音声バケツ トに係る音声を出力する (ステップ SI 39)。このようにして、音声ベースの電子会議が 行われる。なお、話者権の移動については本実施例の主要部ではないので、ここで は説明しない。
[0069] 次に図 22を用いて端子 P以降の処理を説明する。 PoC管理サーバ 5の会議 A管理 部 53aは、ユーザデータ格納部 533aに格納されたデータを用いて、参加者（呼出依 頼を行ったユーザを含む）毎に、参加者のプレゼンスデータを" BUSY" (又は音声 会議中等）に変更するようにプレゼンスデータの更新登録要求を生成し、 SIP/SIM PLEサーバ 3に送信する（ステップ S141)。より具体的には、参加者がユーザ A及び ユーザ Bであるとすると、ユーザ Aプレゼンス管理部 3 laのプレゼンスデータ格納部 3 13aにおけるプレゼンス情報格納領域 3131内の領域 316 (プレゼンス IDは" State" )に格納されたデータを" BUSY"などに変更するためのプレゼンスデータ更新登録 要求、及びユーザ Bプレゼンス管理部 3 lbのプレゼンスデータ格納部 313bにおける プレゼンス情報格納領域 3131内の領域 316に格納されたデータを" BUSY"などに 変更するためのプレゼンスデータ更新登録要求を生成し、 SIPZSIMPLEサーバ 3 に送信する。
[0070] 本来であれば、ユーザ Aプレゼンス管理部 31aにおけるプレゼンスデータ格納部 3 13a内のデータは、ユーザ Aにしか変更できない。同じようにユーザ Bプレゼンス管理 部 31bにおけるプレゼンスデータ格納部 313b内のデータは、ユーザ Bにしか変更で きない。しかし、本実施例においては、音声会議をスムーズに進め、無線区間におけ る通信量を減らすために、特別に PoC管理サーバ 5に変更を認めるものである。上で も述べたように、 PoC管理サーバ 5に SIP/SIMPLEサーバ 3におけるプレゼンスデ ータにつ 、てスーパーバイザ権限を与えておけばよ!、。
[0071] SIP/SIMPLEサーバ 3のユーザ Aプレゼンス管理部 3 la (及びユーザ Bプレゼン ス管理部 31b。但し以下重複するので説明を省略する。）は、 PoC管理サーバ 5から 参加者のプレゼンスデータの更新登録要求を受信し、ユーザ Aプレゼンス管理部 31 aのプレゼンスデータ管理部 311aは、プレゼンス ID"State"に対応して" BUSY"等 のプレゼンスデータをプレゼンスデータ格納部 313aに格納する（ステップ S143)。 S IPZSIMPLEサーバ3のューザAプレゼンス管理部31aは、 OKレスポンスを PoC管 理サーバ 5に送信する（ステップ S 145)。 PoC管理サーバ 5の会議 A管理部 53aは、 SIPZSIMPLEサーバ 3から OKレスポンスを受信する（ステップ S 147)。
[0072] このようなユーザ A及びユーザ Bのプレゼンスデータの更新が行われれば、プレゼ ンス ID"State"の講読者として登録されたユーザには、ユーザ A又はユーザ Bのプレ ゼンスデータが通知される。すなわち、 SIPZSIMPLEサーバ 3におけるユーザ Aプ レゼンス管理部 31aの配信処理部 315aは、プレゼンスデータ格納部 313aの状態に 応じてユーザ Aのプレゼンスデータの通知処理を実施する（ステップ S 149)。図 5の 例では、ユーザ B及びユーザ Cに送信される。なお、ユーザ Bプレゼンス管理部 3 lb についても同様の処理が実施される。但し、ユーザ Bのプレゼンスデータについては ユーザ A及びユーザ Cに送信されるものとする。
[0073] そうすると、ユーザ端末 Bのプレゼンスデータ処理部 915は、 SIPZSIMPLEサー ノ 3からユーザ Aのプレゼンスデータを受信して、表示装置に表示する（ステップ S15 1)。同じように、ユーザ端末 Aのプレゼンスデータ処理部 915は、 SIP/SIMPLEサ ーバ 3からユーザ Bのプレゼンスデータを受信して、表示装置に表示する（ステップ S 153)。他のユーザ端末でも、同じように表示が変更される。これによつて、音声べ一 スの電子会議の参加者の状態を講読して 、る他のユーザは、参加者が BUSYで連 絡が取れな 、ことを認識することができる。
[0074] そして、ユーザ端末 Bのプレゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3 に OKレスポンスを返信し (ステップ S 155)、ユーザ端末 Aのプレゼンスデータ処理部 915も、 SIPZSIMPLEサーバ 3に OKレスポンスを返信する（ステップ S157)。 SIP /SIMPLEサーバ 3のユーザ Aプレゼンス管理部 31a及びユーザ Bプレゼンス管理 部 3 lbは、 OKレスポンスをユーザ端末 A及びユーザ端末 Bカゝら受信する（ステップ S 159)。
[0075] このような処理を実施することにより、ユーザは音声ベースの電子会議をスムーズに 進行させることができ、無線の通信帯域を無駄に消費することもな 、。
[0076] 次に、図 23乃至図 25を用いて音声ベースの電子会議が行われている途中で文字 ベースの電子会議 (チャット）を開始する場合の処理について説明する。まず、例え ばユーザ Aが、ユーザ A、ユーザ B、ユーザ C等が参加する音声ベースの電子会議 において、ユーザ Bと音声ではなく文字ベースのチャットで内々に打ち合わせを行う 場合の処理を説明する。この場合、音声ベースの電子会議は維持される。
[0077] まずユーザ Aは、ユーザ端末 Aを操作して、音声ベースの電子会議を維持すること 及びチャットに呼び出す参加者のユーザ Bを指定する。ユーザ端末 Aのチャット処理 部 913は、このような音声維持のチャット呼出依頼についてのユーザ操作入力を受け 付け (ステップ S201)、チャットメンバ（ここではユーザ B)のリストを含む音声維持のチ ャット呼出依頼を SIPZSIMPLEサーバ 3に送信する（ステップ S203)。なお、例え ばユーザ Aから呼び出し先の指定の入力が無力つた場合は、音声ベースの電子会 議の参加者全員を呼び出し先として設定するようにしてもょ 、。 SIPZSIMPLEサー ノ 3のルーティング処理部 35は、ユーザ端末 A力もチャットメンバのリストを含む音声 維持のチャット呼出依頼を受信し、 PoC管理サーバ 5に転送する (ステップ S205)。
[0078] PoC管理サーバ 5の会議 A管理部 53aは、 SIP/SIMPLEサーバ 3からチャットメ ンバのリストを含む音声維持の呼出依頼を受信し、チャットメンバのリストを例えばュ 一ザデータ格納部 533aに格納する（ステップ S207)。そして、 PoC管理サーバ 5の 会議 A管理部 53aは、 OKレスポンスを SIPZSIMPLEサーバ 3に返信する（ステツ プ S209)。 SIP/SIMPLEサーバ 3のルーティング処理部 35は、 PoC管理サーバ 5 力ら OKレスポンスを受信し、ユーザ端末 Aに転送する（ステップ S211)。ユーザ端末 Aのチャット処理部 913は、 SIPZSIMPLEサーバ 3から OKレスポンスを受信する（ ステップ S 213)。
[0079] また、 PoC管理サーバ 5の会議 A管理部 53aは、受信したチャットメンバのリストに 従って、チャットメンバ毎に、チャットメンバ（ここではユーザ B)に対する音声維持のチ ャット呼出を SIPZSIMPLEサーバ 3に送信する（ステップ S215)。なお、呼出元の ユーザにつ 、てのデータをチャット呼出に含める。 SIP/SIMPLEサーバ 3のルーテ イング処理部 35は、 PoC管理サーバ 5からチャットメンバに対する音声維持のチャット 呼出を受信し、ユーザ端末 Bに転送する (ステップ S 217)。ユーザ端末 Bのチャット処 理部 913は、 SIPZSIMPLEサーバ 3から音声維持のチャット呼出を受信し、例えば チャット呼出用の表示を行ったり、所定の音声を出力するなどチャット呼出処理を実 施する（ステップ S219)。なお、ユーザ端末 Bのチャット処理部 913は、 OKレスポン スを SIPZSIMPLEサーバ 3に送信する（ステップ S221)。 SIPZSIMPLEサーバ 3 のルーティング処理部 35は、ユーザ端末 Bから OKレスポンスを受信し、 PoC管理サ ーバ 5に転送する (ステップ S223)。 PoC管理サーバ 5の会議 A管理部 53aは、 SIP ZSIMPLEサーバ 3から OKレスポンスを受信する（ステップ S225)。処理は、端子 Q、端子 R及び端子 Sを介して図 24の処理に移行する。
[0080] 図 24を用いて端子 Q、端子 R及び端子 S以降の処理について説明する。ユーザ B は、チャット呼出を認識すると、チャットに参加するカゝ判断する。参加すると判断する 場合には、ユーザ端末 Bにチャット参加応答を入力する。ユーザ端末 Bは、ユーザ B によるチャット参加応答入力を受け付け (ステップ S227)、ユーザ Bによる参加応答を SIPZSIMPLEサーバ 3に送信する（ステップ S229)。 SIPZSIMPLEサーバ 3の ルーティング処理部 35は、ユーザ端末 B力もユーザ Bによる参加応答を受信し、 PoC 管理サーバ 5に転送する（ステップ S231)。 PoC管理サーバ 5の会議 A管理部 53a は、ユーザ Bによる参加応答を、 SIPZSIMPLEサーバ 3から受信し、ユーザデータ 格納部 533aにユーザ Bに対応してチャット参カ卩を表すデータを格納する (ステップ S 233) o
[0081] これに対して、 PoC管理サーバ 5の会議 A管理部 53aは、 OKレスポンスを SIPZSI MPLEサーバ 3に送信する（ステップ S235)。 SIPZSIMPLEサーバ 3のルーティン グ処理部 35は、 PoC管理サーバ 5から OKレスポンスを受信し、ユーザ端末 Bに転送 する（ステップ S237)。ユーザ端末 Bのチャット処理部 913は、 SIPZSIMPLEサー ノ 3から OKレスポンスを受信する（ステップ S239)。
[0082] そして、 PoC管理サーバ 5の会議 A管理部 53aは、ユーザデータ格納部 533aに格 納されたデータを用いて、チャット参加者 (チャット呼出依頼元のユーザを含む。ここ ではユーザ A及びユーザ B。）のプレゼンス登録要求を生成し、 SIPZSIMPLEサー ノ 3に送信する (ステップ S241)。より具体的には、会議 A管理部 53aが所有者であ つて、プレゼンス IDが" ChatUser"であるプレゼンスデータとして参加者のユーザ ID (図 6の例では" UserA, UserB")を登録することを要求する。 SIPZSIMPLEサー ノ 3における会議 Aプレゼンス管理部 33aのプレゼンスデータ管理部 33 laは、 PoC 管理サーバ 5からチャット参加者のプレゼンス登録要求を受信し、受信したプレゼン ス登録要求に係るプレゼンス ID ("ChatUser")に対応してチャット参加者のユーザ I D (図 6の例では" UserA, UserB")をプレゼンスデータとしてプレゼンスデータ格納 部 333aに格納する（ステップ S 243)。図 6に示すように、プレゼンス情報格納領域 3 331の領域 3365に参加者のユーザ ID (図 6の例では" UserA、 UserB")が登録さ れる。また、会議 Aプレゼンス管理部 33aは、 OKレスポンスを PoC管理サーバ 5に送 信する（ステップ S 245)。 PoC管理サーバ 5の会議 A管理部 53aは、 SIP/SIMPL Eサーバ 3から OKレスポンスを受信する（ステップ S247)。
[0083] さらに、 PoC管理サーバ 5の会議 A管理部 53aは、ユーザデータ格納部 533aに格 納されたデータを用いて、チャット参加者に対する公開設定要求を生成し、 SIP/SI MPLEサーバ 3に送信する（ステップ S249)。より具体的には、プレゼンスグループ 情報格納領域 3333のグループ III「チャット」のための領域 339内の講読者 IDの領域 3392に、チャット参加者のユーザ ID (図 6の例では" UserA、 UserB")を登録するこ とを要求する。 SIPZSIMPLEサーバ 3における会議 Aプレゼンス管理部 33aのプレ ゼンスデータ管理部 331aは、 PoC管理サーバ 5からチャット参加者に対応する公開 設定要求 (代理講読要求)を受信し、受信した公開設定要求に係るチャット参加者の ユーザ IDをプレゼンスグループ情報格納領域 3333のグループ III「チャット」のため の領域 339内の講読者 IDの領域 3392に格納する（ステップ S251)。また、会議 Aプ レゼンス管理部 33aは、 OKレスポンスを PoC管理サーバ 5に送信する（ステップ S25 3)。 PoC管理サーバ 5の会議 A管理部 53aは、 SIPZSIMPLEサーバ 3から OKレス ポンスを受信する (ステップ S255)。処理は端子 Tを介して図 25の処理に移行する。
[0084] なお、図 24における SIP/SIMPLEサーバ 3の会議 Aプレゼンス管理部 33aの処 理が完了すれば、プレゼンスグループ情報格納領域 3333内のグループ III「チャット 」の領域 339に含まれるプレゼンス IDの領域 3391で特定されるプレゼンスデータが 、チャット参加者に通知されるようになる。すなわち、プレゼンス IDが" Chat"であるプ レゼンスデータ「チャットの内容」（図 6の例では"こんにちは' · · "）と、プレゼンス IDが "ChatUser"であるプレゼンスデータ「チャット参加者」（図 6の例では" UserA, Use rB")とが、更新時に自動的に通知される。しかしながら、プレゼンスデータの所有者 は会議 A管理部 53aであるから、通常ではチャット参加者はプレゼンスデータを更新 することはできない。チャット参加者がチャット内容を変更できないのでは、チャットを 進めることができない。一方で、音声ベースの電子会議を実施中にチャットを開始す る場合に、会議 Aプレゼンス管理部 33aとは別にチャット参加者が所有するプレゼン ス管理部を起動するなどの処理を実施する場合には、 SIPZSIMPLEサーバ 3や P oC管理サーバ 5のリソースを余分に使用するなどの問題がある。従って、本実施例で は、プレゼンス IDが" ChatUser"であるプレゼンスデータとして登録されたチャット参 加者は、プレゼンス IDが" Chat"のプレゼンスデータを所有者にかかわらず更新可 能とする。すなわち、ステップ S241のチャット参加者のプレゼンス登録要求又はステ ップ S249のチャット参加者に対する公開設定要求 (代理講読要求）に応じて、チヤッ ト参加者にチャットの内容を更新する権限が与えられることになる。このようにして、リ ソースを無駄に消費することなぐスムーズにチャットを開始することができるようにな る。
[0085] 次に、図 25を用いて端子 T以降の処理を説明する。ここでは SIPZSIMPLEサー ノ 3における会議 Aプレゼンス管理部 33aの配信処理部 335aは、プレゼンスデータ 格納部 333aの設定に従い、チャットのプレゼンスデータ（チャット内容のプレゼンス データ及びチャット参加者のプレゼンスデータ）を、ユーザ端末 A及びユーザ端末 B に通知する（ステップ S257)。初期的にはチャット内容は何も登録されていないので 、何も通知されない。ユーザ端末 Bにおけるクライアントアプリケーション 91のプレゼ ンスデータ処理部 915は、 SIPZSIMPLEサーバ 3からチャットのプレゼンスデータ を受信し、表示装置に表示する (ステップ S259)。また、ユーザ端末 Aにおけるクライ アントアプリケーション 91のプレゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3からチャットのプレゼンスデータを受信し、表示装置に表示する（ステップ S261)。 ユーザ端末 Bのプレゼンスデータ処理部 915は、 OKレスポンスを SIPZSIMPLEサ ーバ 3に返信する（ステップ S263)。同じようにユーザ端末 Aのプレゼンスデータ処理 部 915は、 OKレスポンスを SIP/SIMPLEサーバ 3に返信する（ステップ S265)。 S IP/SIMPLEサーバ 3の会議 Aプレゼンス管理部 33aは、ユーザ端末 A及びユーザ 端末 Bからの OKレスポンスを受信する（ステップ S267)。
[0086] さらに例えばユーザ Aが、ユーザ端末 Aを操作して、チャットの内容 (会話文字)を 入力すると、ユーザ端末 Aのプレゼンスデータ処理部 915は、ユーザ Aによる会話文 字の入力を受け付け、プレゼンス ID"Chat"のプレゼンスデータとして SIPZSIMPL Eサーバ 3に送信する（ステップ S269)。 SIPZSIMPLEサーバ 3の会議 Aプレゼン ス管理部 33aにおけるプレゼンスデータ管理部 331aは、ユーザ端末 Aから会話文字 データをプレゼンス ID"Chat"のプレゼンスデータとして受信し、プレゼンスデータ格 納部 333aに格納する (ステップ S271)。会議 Aプレゼンス管理部 33aは、ユーザ端 末 Aに OKレスポンスを送信する（ステップ S273)。ユーザ端末 Aは、 SIPZSIMPL Eサーバ 3から OKレスポンスを受信する（ステップ S275)。
[0087] このようにプレゼンスデータが更新されたので、 SIPZSIMPLEサーバ 3における 会議 Aプレゼンス管理部 33aの配信処理部 335aは、プレゼンスデータ格納部 333a の設定に従い、チャットのプレゼンスデータ（チャット内容のプレゼンスデータ及び変 更があればチャット参加者のプレゼンスデータ）を、ユーザ端末 A及びユーザ端末 B に通知する (ステップ S277)。差分のみを通知するようにする場合もある。ユーザ端 末 Bにおけるクライアントアプリケーション 91のプレゼンスデータ処理部 915は、 SIP ZSIMPLEサーバ 3からチャットのプレゼンスデータを受信し、表示装置に表示する (ステップ S279)。また、ユーザ端末 Aにおけるクライアントアプリケーション 91のプレ ゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3からチャットのプレゼンスデー タを受信し、表示装置に表示する (ステップ S281)。ユーザ端末 Bのプレゼンスデー タ処理部 915は、 OKレスポンスを SIPZSIMPLEサーバ 3に返信する（ステップ S2 83)。同じようにユーザ端末 Aのプレゼンスデータ処理部 915は、 OKレスポンスを SI PZSIMPLEサーバ 3に返信する（ステップ S285)。 SIPZSIMPLEサーバ 3の会 議 Aプレゼンス管理部 33aは、ユーザ端末 A及びユーザ端末 Bからの OKレスポンス を受信する (ステップ S287)。
[0088] 以下、ステップ S269乃至 S287の処理を繰り返すこと〖こより、チャットでの会話を進 めることができる。なお、ユーザ端末 Bからも会話文字を送信することが可能である。 処理内容は同様であるからここでは説明を省略する。
[0089] このような処理を実施することにより、音声ベースの電子会議を維持しつつ、別途音 声ベースの電子会議の参加者のサブセットにおいて文字ベースのチャットを行うこと ができるようになる。なお、プレゼンス技術を用いてチャットを実現しているため、音声 ベースの電子会議のために用意されたリソースを有効に活用することができる。
[0090] また、 1つの音声会議に対し、プレゼンスグループ情報及びそれに対応するプレゼ ンスデータのセットを複数用意することにより、複数のチャットグループを管理できる ので、例えばユーザ A、 B、 C及び Dの 4人が参カ卩している音声会議のサブセットとし て、ユーザ Aと B、ユーザ Cと Dがそれぞれ別個のチャットを行ったり、ユーザ Aと B、 ユーザ Aと Cとが別個にチャットを行ったりするなど、複数のサブセットのチャットを行う ことちでさる。
[0091] また、図 5のプレゼンス情報格納領域 3131では特定のユーザのプレゼンスデータ が管理されているが、ここに例えばプレゼンス IDを" position"とし、 "teacher"又は" student "の!/、ずれかのプレゼンスデータを格納しておけば、プレゼンスデータが" st udent"であるユーザからは、チャットの呼出先としてプレゼンスデータが" teacher" であるユーザのみを許可するようにしたり、プレゼンスデータが" teacher"であるユー ザからの呼び出しは、いずれのユーザへの呼び出しであっても許可したりするような 制御が可能となる。すなわち、ユーザ毎に管理されているプレゼンスデータを利用し てプレゼンスデータの送信を制御することができるようになる。
[0092] 一方、図 6のプレゼンス情報格納領域 3331では音声ベースの電子会議のプレゼ ンスデータが管理されて 、るが、ここに例えばプレゼンス IDを" teacher"とし先生の 地位を有する参加者の講読者 IDを登録し、さらにプレゼンス IDを" student"とし学 生の地位を有する参加者の講読者 IDを登録すると上と同様の処理を行うことができ るようになる。すなわち、プレゼンス IDが" teacher"であるプレゼンスデータとして登 録されたユーザにっ 、ては、全ての会議参加者にチャットの呼び出しを行うことがで き、プレゼンス IDが" student"であるプレゼンスデータとして登録されたユーザにつ V、ては、プレゼンス IDが" teacher"であるプレゼンスデータとして登録されたユーザ にしかチャットの呼び出しを行うことができな 、と!/、うような制御が可能となる。従って、 会議毎に管理されているプレゼンスデータを利用してプレゼンスデータの送信を制 御することがでさるよう〖こなる。
[0093] 次に、図 26乃至図 29を用いて音声ベースの電子会議が行われている途中で、例 えば電子会議中に必要な画像データの配信を開始する場合の処理にっ 、て説明す る。まず、例えばユーザ Aが、ユーザ A、ユーザ B、ユーザ C等が参加する音声べ一 スの電子会議において、ユーザ Bに画像を配信する場合の処理を 3種類説明する。 なお、以下の説明では、説明を簡略ィ匕するため OKレスポンスの送受信については 説明を省略する。
[0094] 第 1の例に係る処理フローを図 26及び図 27に示す。最初に、音声ベースの電子会 議開催中に、当該電子会議の参加者であるユーザ Aは、当該電子会議で必要な画 像データをユーザ Bなどに配信すべく、ユーザ Bなどを選択して画像配信依頼につ V、ての操作を行う。ユーザ端末 Aのクライアントアプリケーション 91における画像処理 部 916は、ユーザ Aから、ユーザ Bなどの配信先ユーザの選択を含む画像配信依頼 についてのユーザ操作入力を受け付け (ステップ S301)、配信先ユーザのユーザ ID を含む画像配信依頼を SIPZSIMPLEサーバ 3に送信する（ステップ S303)。 SIP /SIMPLEサーバ 3のルーティング処理部 35は、ユーザ端末 Aから画像配信依頼 を受信し、 PoC管理サーバ 5に転送する (ステップ S305)。
[0095] PoC管理サーバ 5の会議 A管理部 53aは、ユーザ端末 Aからの画像配信依頼を受 信し、画像配信依頼元ユーザのユーザ ID及び配信先ユーザのユーザ IDを例えば ユーザデータ格納部 533aに格納する (ステップ S307)。そして、画像配信用のリソ ース (画像データ格納部 535a内の画像記憶領域、アップロード先リソース等の IPアド レス及びポート番号)を確保する (ステップ S309)。そして、会議 A管理部 53aは、画 像配信のためのプレゼンス登録要求を生成し、 PoC管理サーバ 5に送信する (ステツ プ S311)。より具体的には、会議 A管理部 53aが所有者であって、プレゼンス IDが" PhotoUser"であるプレゼンスデータとして画像配信参加者のユーザ IDを登録する ことと、会議 A管理部 53aが所有者であって、プレゼンス IDが" Photo"であるプレゼ ンスデータとして配信配信用のリソース ·データを登録することを要求する。
[0096] SIP/SIMPLEサーバ 3における会議 Aプレゼンス管理部 33aのプレゼンスデータ 管理部 33 laは、 PoC管理サーバ 5から画像配信のためのプレゼンス登録要求を受 信し、受信したプレゼンス登録要求に係るプレゼンス ID ("PhotoUser")に対応して 画像配信参加者のユーザ IDをプレゼンスデータとしてプレゼンスデータ格納部 333 aに格納し、受信したプレゼンス登録要求に係るプレゼンス ID ("Photo")に対応して 画像配信用のリソース 'データをプレゼンスデータとしてプレゼンスデータ格納部 333 aに格納する（ステップ S313)。図 6に示すように、プレゼンス情報格納領域 3331の 領域 3367に画像配信参加者のユーザ ID (図 6の例では" UserA、 UserB")が登録 される。さらに、プレゼンス情報格納領域 3331の領域 3366に画像配信用のリソース
•データ（図 6の例では" χχχ.χχχ.χχχ.χχ^χχχχ")が登録される。
[0097] さらに、 PoC管理サーバ 5の会議 Α管理部 53aは、ユーザデータ格納部 533aに格 納されたデータを用いて、画像配信参加者に対する公開設定要求 (代理講読要求） を生成し、 SIPZSIMPLEサーバ 3に送信する (ステップ S315)。より具体的には、 プレゼンスグループ情報格納領域 3333のグループ IV「画像」のための領域 340内 の講読者 IDの領域 3402に、画像配信参加者のユーザ IDを登録することを要求する 。 SIP/SIMPLEサーバ 3における会議 Aプレゼンス管理部 33aのプレゼンスデータ 管理部 33 laは、 PoC管理サーバ 5から画像配信参加者に対する公開設定要求 (代 理講読要求)を受信し、受信した公開設定要求に係る画像配信参加者のユーザ ID ( 図 6の例では" UserA, UserB")をプレゼンスグループ情報格納領域 3333のグル ープ IV「画像」のための領域 340内の講読者 IDの領域 3402に格納する（ステップ S 317)。
[0098] その後、 SIPZSIMPLEサーバ 3における会議 Aプレゼンス管理部 33aの配信処 理部 335aは、プレゼンスデータ格納部 333aの設定に従い、画像配信についてのプ レゼンスデータ（画像配信用のリソース 'データ（特にアップロード先リソース（IPァドレ ス及びポート番号)及び画像配信参加者のプレゼンスデータ）を、ユーザ端末 A及び ユーザ端末 Bに通知する (ステップ S319)。ユーザ端末 Bにおけるクライアントアプリ ケーシヨン 91のプレゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3から画像 配信についてのプレゼンスデータを受信し、表示装置に表示する（ステップ S323)。 また、ユーザ端末 Aにおけるクライアントアプリケーション 91のプレゼンスデータ処理 部 915は、 SIPZSIMPLEサーバ 3から画像配信についてのプレゼンスデータを受 信し、表示装置に表示する (ステップ S321)。これによつて、各ユーザ端末では、配 信すべき画像データの送信先のデータ（アップロード先リソース）を取得できる。処理 は、端子 U、端子 V及び端子 Wを介して図 27の処理に移行する。
[0099] 次に、図 27を用いて端子 U、端子 V及び端子 W以降の処理を説明する。画像配信 依頼を送信したユーザ端末 Aのユーザ Aは、ユーザ端末 Aを操作して配信すべき画 像データ（画像ファイル)の指定を行う。ユーザ端末 Aのクライアントアプリケーション 9 1における画像処理部 916は、ユーザ Aから画像データの指定入力を受け付け (ステ ップ S325)、当該画像データをユーザ端末 Aの記憶装置力 読み出し、指定画像デ ータをアップロード先リソース (IPアドレス及びポート番号)宛に送信する（ステップ S3 27)。 PoC管理サーバ 5の会議 A管理部 53aは、ユーザ端末 Aから画像データを受 信し、画像データ格納部 535aに格納する（ステップ S329)。
[0100] そうすると、 PoC管理サーバ 5の会議 A管理部 53aは、画像配信元ユーザ (ここでは ユーザ A)のプレゼンスデータの更新登録要求を生成し、 SIPZSIMPLEサーバ 3に 送信する（ステップ S331)。具体的には、ユーザ Aプレゼンス管理部 3 laのプレゼン スデータ格納部 313aにおけるプレゼンス情報格納領域 3131内の領域 316に格納 されたデータを" Photo Sending"又は"画像配信中"などに変更するためのプレゼ ンスデータ更新登録要求を生成する。なお、本実施の形態では、 PoC管理サーバ 5 は、 SIPZSIMPLEサーバ 3に対してスーパーバイザ権限を有しており、ユーザ Aプ レゼンス管理部 31a、ユーザ Bプレゼンス管理部 3 lbにおけるプレゼンスデータ格納 部 313に対する更新権限を有しているものとする。
[0101] SIP/SIMPLEサーバ 3におけるユーザ Aプレゼンス管理部 3 laのプレゼンスデー タ管理部 311aは、 PoC管理サーバ 5から配信元ユーザのプレゼンス更新登録要求 を受信し、受信したプレゼンス更新登録要求に係るプレゼンス ID ("State")に対応 して" Photo Sending"又は"画像配信中"などをプレゼンスデータとしてプレゼンス データ格納部 313aに格納する（ステップ S333)。ユーザ Aプレゼンス管理部 3 laの プレゼンスデータ格納部 313aにおけるプレゼンス情報格納領域 3131内の領域 316 に格納されたデータを" Photo Sending"又は"画像配信中"などに変更する。なお 、本例では、電子会議参加者は、他の電子会議参加者を、プレゼンス IDが" State" であるプレゼンスデータの講読者として予め登録しておくものとする。
[0102] その後、 SIPZSIMPLEサーバ 3におけるユーザ Aプレゼンス管理部 3 laの配信 処理部 315aは、プレゼンスデータ格納部 313aの設定に従い、プレゼンス IDが" Sta te"であるプレゼンスデータを、ユーザ端末 A及びユーザ端末 Bに通知する（ステップ S335)。ユーザ端末 Bにおけるクライアントアプリケーション 91のプレゼンスデータ処 理部 915は、 SIPZSIMPLEサーバ 3からユーザ Aのプレゼンスデータを受信し、表 示装置に表示する (ステップ S339)。また、ユーザ端末 Aにおけるクライアントアプリ ケーシヨン 91のプレゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3からユー ザ Aのプレゼンスデータを受信し、表示装置に表示する（ステップ S337)。これによつ て、各ユーザ端末では、ユーザ Aが画像データをアップロードしたことを把握すること ができるようになる。
[0103] ここでユーザ Bは、ユーザ端末 Bを操作して、画像配信用のリソース 'データをクリツ クするなどして、ユーザ Aがアップロードした画像データを要求する。ユーザ端末 Bの クライアントアプリケーション 91の画像処理部 916は、画像配信用のリソースに対して 画像要求を送信する (ステップ S341)。ユーザ Bの介在なしにステップ S341を実行 するようにしても良い。 PoC管理サーバ 5の会議 A管理部 53aは、ユーザ端末 Bから 画像要求を受信し (ステップ S343)、画像データ格納部 535aから要求に係る画像デ ータを読み出し、要求元のユーザ端末 Bに配信する (ステップ S345)。ユーザ端末 B のクライアントアプリケーション 91の画像処理部 916は、 PoC管理サーバ 5から画像 データを受信し、表示装置に表示する（ステップ S347)。このようにすれば、ユーザ A がアップロードした画像データをダウンロードすることができる。
[0104] このようにすれば、配信元ユーザのプレゼンスデータ（プレゼンス IDの" State"のプ レゼンスデータ）の更新に応じて、配信先のユーザ端末は画像配信用のリソースにァ クセスして画像データのダウンロードを行うことができる。また、例えば同じ電子会議 に参カ卩している他のユーザ力 画像データ格納部 535a内の同じリソースに画像デー タを上書き登録すれば、当該他のユーザのプレゼンスデータが更新され、それに応 じてプレゼンス更新を検知した他のユーザ端末が画像配信用のリソースにアクセスす るので、プレゼンス技術を利用して音声ベースの電子会議のリソースを利用しながら 画像データの配信を容易に行なうことができるようになる。また、画像データ格納部 5 35a内の同じリソースを流用することが可能になる。 [0105] また、ステップ S345の後に、ユーザ Aの状態を表すプレゼンスデータを" Busy"に 戻すようにしても良い。
[0106] なお、本例の処理、特にステップ S331乃至ステップ S339については、以下のよう な処理に置換することも可能である。すなわち、 PoC管理サーバ 5の会議 A管理部 5 3aは、プレゼンス IDが" Photo"であるプレゼンスデータ又は" PhotoUser"であるプ レゼンスデータの更新登録要求を生成し、 SIPZSIMPLEサーバ 3に送信する（ステ ップ S331)。具体的には、アップロード先リソースにカ卩え、配信元リソース（例えば、 ft p://yyy.yyy.yyy.yyy/imagefromUserA.jPg)を確保し、会議 Aプレゼンス管理部 33aの プレゼンスデータ格納部 333aにおけるプレゼンス情報格納領域 3331内の領域 336 6に格糸内 れ 7こァ1 ~~タ xxx.xxx.xxx.xxx:xxxx ftp://yyy.yyy.yyy.yyy/imagefromUs erA.jpg"などに変更するためのプレゼンスデータ更新登録要求を生成する。また、会 議 Aプレゼンス管理部 33aのプレゼンスデータ格納部 333aにおけるプレゼンス情報 格納領域 3331内の領域 3367に格納されたデータを" UserA (Photo Sending) , UserB"又は" UserA (画像配信中）， UserB"などに変更するためのプレゼンスデー タ更新登録要求を生成してもよ 、。これの両方を行うようなプレゼンスデータ更新登 録要求を生成してもよい。
[0107] SIP/SIMPLEサーバ 3における会議 Aプレゼンス管理部 33aのプレゼンスデータ 管理部 33 laは、 PoC管理サーバ 5からプレゼンス IDが，， Photo"又は，， PhotoUser" であるプレゼンスデータの更新登録要求を受信し、受信したプレゼンス更新登録要 求に係るプレゼンス ID ("Photo"又は" PhotoUser")に対応して，，xxx.xxx.xxx.xxx:x XXX ftp://yyy.yyy.yyy.yyy/imagefromUserA.jpg しくは， u serA (Photo Senam g) , UserB"又は" UserA (画像配信中）， UserB"などをプレゼンスデータとしてプレ ゼンスデータ格納部 333aに格納する（ステップ S333)。会議 Aプレゼンス管理部 33 aのプレゼンスデータ格納部 333aにおけるプレゼンス情報格納領域 3331内の領域 3 JO 6に格糸内 れ 7こァ1 ~~タ xxx.xxx.xxx.xxx:xxxx ftp://yyy.yyy.yyy.yyy/imagerro mUserA.jpg"などに変更する力 又は領域 3367に格納されたデータを" UserA (Ph oto Sending) , UserB"又は" UserA (画像配信中）， UserB"などに変更する。
[0108] その後、 SIPZSIMPLEサーバ 3における会議 Aプレゼンス管理部 33aの配信処 理部 335aは、プレゼンスデータ格納部 333aの設定に従い、プレゼンス IDが" Phot o"であるプレゼンスデータ又は" PhotoUser"であるプレゼンスデータを、ユーザ端 末 A及びユーザ端末 Bに通知する（ステップ S335)。ユーザ端末 Bにおけるクライア ントアプリケーション 91のプレゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3 力も上記のような画像配信についてのプレゼンスデータを受信し、表示装置に表示 する（ステップ S339)。また、ユーザ端末 Aにおけるクライアントアプリケーション 91の プレゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3から上記のような画像配 信についてのプレゼンスデータを受信し、表示装置に表示する（ステップ S337)。
[0109] 次に、第 2の例に係る処理フローを図 28を用いて説明する。なお、図 26におけるス テツプ S301乃至ステップ S321までの処理はほぼ同じである。但し、ステップ S319 にお ヽて画像配信用のプレゼンスデータの通知は、画像配信元ユーザのユーザ端 末ではないユーザ端末 Bには送信しない。これは、例えばステップ S315における公 開設定要求 (代理講読要求）にお 、てユーザ Bのユーザ IDを登録しな 、ようにして、 以下で説明するように配信すべき画像データを受信した後にユーザ Bのユーザ IDを 含む公開設定要求 (代理講読要求)を PoC管理サーバ 5の会議 A管理部 53aから SI P/SIMPLEサーバ 3の会議 Aプレゼンス管理部 33aに送信することにより実現する ようにしても良い。また、ステップ S315における公開設定要求 (代理講読要求）にお いて次のプレゼンスデータの更新登録要求を受信するまでユーザ Bのユーザ IDをマ スクするような設定を含むようにすることによって実現してもよい。このようにして、画像 配信依頼の送信元のユーザ端末 Aには、画像配信用のリソースのデータが通知され る。
[0110] 次に、画像配信依頼を送信したユーザ端末 Aのユーザ Aは、ユーザ端末 Aを操作 して配信すべき画像データの指定を行う。ユーザ端末 Aのクライアントアプリケーショ ン 91における画像処理部 916は、ユーザ A力も画像データの指定入力を受け付け（ ステップ S351)、当該画像データをユーザ端末 Aの記憶装置力も読み出し、指定画 像データをアップロード先リソース (IPアドレス及びポート番号）に送信する (ステップ S353)。 PoC管理サーバ 5の会議 A管理部 53aは、ユーザ端末 Aから画像データを 受信し、画像データ格納部 535aに格納する（ステップ S355)。 [0111] そして、 PoC管理サーバ 5の会議 A管理部 53aは、プレゼンス IDが" Photo"である プレゼンスデータの更新登録要求を生成し、 SIPZSIMPLEサーバ 3に送信する（ス テツプ S357)。具体的には、会議 Aプレゼンス管理部 33aのプレゼンスデータ格納 部 333aにおけるプレゼンス情報格納領域 3331内の領域 3366に格納されたデータ を" xxx.xxx.xxx.xxx:xxxx" (IPアドレス及びポート番号）などに変更するためのプレゼ ンスデータ更新登録要求を生成する。または、アップロード先リソースに加え、配信元 リソース（例えば、 ftp：〃 yyy.yyy.yyy.yyy/imagefromUserA.jpg)を別途確保し、会議 A プレゼンス管理部 33aのプレゼンスデータ格納部 333aにおけるプレゼンス情報格納 領域 3331内の領域 3366に格納されたデータを" xxx.xxx.xxx.xxx:xxxx ftp：〃 yyy.y yy.yyy.yyy/imagefromUserA.jpg"などに変更するためのプレゼンスデータ更新登録 要求を生成するようにしてもょ 、。
[0112] SIP/SIMPLEサーバ 3における会議 Aプレゼンス管理部 33aのプレゼンスデータ 管理部 33 laは、 PoC管理サーバ 5からプレゼンス IDが" Photo"であるプレゼンスデ ータの更新登録要求を受信し、受信したプレゼンス更新登録要求に係るプレゼンス I D ( Photo )にスォ J心して xxx.xxx.xxx.xxx:xxxx 又【 xxx.xxx.xxx.xxx:xxxx ftp://y yy.yyy-yyy.yyy/imagefromUserA.jpg 'などをプレセンステータとしてプレゼンスデータ 格納部 333aに格納する（ステップ S359)。会議 Aプレゼンス管理部 33aのプレゼン スデータ格納部 333aにおけるプレゼンス情報格納領域 3331内の領域 3366又は領 ¾)^3do7iこ格内され 7こア1 ~~タ XXX.XXX.XXX.XXXIXXXX 又 xxx.xxx.xxx.xxx:xxxx ft p://yyy.yyy.yyy.yyyハ magefromUserA.jpg，などに変更する。
[0113] その後、 SIPZSIMPLEサーバ 3における会議 Aプレゼンス管理部 33aの配信処 理部 335aは、プレゼンスデータ格納部 333aの設定に従い、プレゼンス IDが" Phot o"であるプレゼンスデータを、ユーザ端末 A及びユーザ端末 Bに通知する（ステップ S361)。ユーザ端末 Bにおけるクライアントアプリケーション 91のプレゼンスデータ処 理部 915は、 SIPZSIMPLEサーバ 3からプレゼンスデータを受信し、表示装置に 表示する (ステップ S365)。また、ユーザ端末 Aにおけるクライアントアプリケーション 91のプレゼンスデータ処理部 915は、 SIPZSIMPLEサーバ 3力 画像配信につ!/ヽ てのプレゼンスデータを受信し、表示装置に表示する（ステップ S363)。 [0114] ここでユーザ Bは、ユーザ端末 Bを操作して、画像配信用のリソース 'データをクリツ クするなどして、ユーザ Aがアップロードした画像データを要求する。ユーザ端末 Bの クライアントアプリケーション 91の画像処理部 916は、画像配信用のリソースに対して 画像要求を送信する（ステップ S367)。なお、ユーザ Bの介在なしにステップ S367を 実行するようにしても良い。 PoC管理サーバ 5の会議 A管理部 53aは、ユーザ端末 B カゝら画像要求を受信し (ステップ S369)、画像データ格納部 535aから要求に係る画 像データを読み出し、要求元のユーザ端末 Bに配信する (ステップ S371)。ユーザ端 末 Bのクライアントアプリケーション 91の画像処理部 916は、 PoC管理サーバ 5力も画 像データを受信し、表示装置に表示する (ステップ S373)。このようにすれば、ユー ザ Aがアップロードした画像データをダウンロードすることができる。
[0115] このような処理を行うことにより、 PoC管理サーバ 5への画像の登録に応じて、配信 先ユーザ端末へ画像配信用のリソースなどを含むプレゼンスデータが通知される。 従って、当該通知に応じて各配信先ユーザ端末は、画像配信用のリソースにァクセ スすることができる。また、例えば画像データ格納部（同じリソースへの上書きでも良 い）へ他のユーザが画像データを登録すれば、当該画像データの配信用のリソース' データで、プレゼンス IDが" Photo"であるプレゼンスデータが更新され、プレゼンス I Dが" Photo"であるプレゼンスデータの通知に応じて他のユーザ端末が画像をダウ ンロードできるようになる。従って、音声ベースの電子会議のリソースを利用しながら 画像の配信を行なうことが可能になる。
[0116] なお、ステップ S357において会議 Aプレゼンス管理部 33aのプレゼンスデータ格 納部 333aにおけるプレゼンス情報格納領域 3331内の領域 3367に格納されたデ ータを" UserA (Photo Sending) , UserB"又は" UserA (画像配信中）， UserB" などに変更するためのプレゼンスデータ更新登録要求を生成するようにしてもよい。 さらに、プレゼンス IDが" Photo"であるプレゼンスデータ及び" PhotoUser"である プレゼンスデータの更新を行うようなプレゼンスデータ更新登録要求を生成してもよ い。
[0117] 次に、第 3の例に係る処理フローを図 29を用いて説明する。なお、図 26におけるス テツプ S301乃至ステップ S323までの処理は同じである。 [0118] 画像配信依頼を送信したユーザ端末 Aのユーザ Aは、ユーザ端末 Aを操作して配 信すべき画像データの指定を行う。ユーザ端末 Aのクライアントアプリケーション 91に おける画像処理部 916は、ユーザ Aから画像データの指定入力を受け付け (ステップ S381)、当該画像データをユーザ端末 Aの記憶装置から読み出し、指定画像データ をアップロード先リソース（IPアドレス及びポート番号）に送信する（ステップ S383)。 P oC管理サーバ 5の会議 A管理部 53aは、ユーザ端末 Aから画像データを受信し、画 像データ格納部 535aに格納する（ステップ S385)。
[0119] そして、 PoC管理サーバ 5の会議 A管理部 53aは、ユーザデータ格納部 533aに格 納されて ヽる画像配信依頼に含まれる配信先ユーザ IDを読み出し、さらに当該配信 先ユーザ ID力 ユーザ端末 Bの IPアドレスを特定し、当該ユーザ端末 Bに画像デー タ格納部 535aに格納されており且つユーザ端末 Aから受信した画像データを送信 する（ステップ S387)。例えば SIPZSIMPLEサーバ 3からユーザ IDに対応する IP アドレスを取得する。ユーザ端末 Bのクライアントアプリケーション 91の画像処理部 91 6は、 PoC管理サーバ 5から画像データを受信し、表示装置に表示する (ステップ S3 89)。このようにすれば、ユーザ端末 Bは、ユーザ Aがアップロードした画像データを 受信することができる。
[0120] 以上、図 26乃至図 29に示したような処理を実施することにより、音声ベースの電子 会議を維持しつつ、別途音声ベースの電子会議の参加者のサブセットにお 、て画像 データのやりとりを行うことができるようになる。なお、プレゼンス技術を用いて画像デ ータの配信を実現しているため、音声ベースの電子会議のために用意されたリソース を有効に活用することができる。
[0121] 以上本発明の一実施例を説明したが、本発明はこれに限定されるものではない。
図 1乃至図 4に示した機能ブロック図は、一例であって、必ずしも実際のプログラムモ ジュールの構成に合致しない場合もある。さらに、図 5乃至図 13に示したデータの保 持の仕方についても、同様のデータを管理可能な限りにおいて他の方式を採用する ことも可能である。
[0122] なお、 SIP/SIMPLEサーバ 3、 PoC管理サーノ 5及び PoC— MCUサーバ 7は、 図 30に示すように、コンピュータ装置であって、メモリ 2501と CPU2503とノヽードディ スク 'ドライブ (HDD) 2505と表示装置 2509に接続される表示制御部 2507とリムー バブル ·ディスク 2511用のドライブ装置 2513と入力装置 2515とネットワークに接続 するための通信制御部 2517とがバス 2519で接続されて!、る。オペレーティング ·シ ステム（OS： Operating System)及び本実施例における処理を実施するためのアプリ ケーシヨン 'プログラムは、 HDD2505〖こ格糸内されており、 CPU2503〖こより実行され る際には HDD2505からメモリ 2501に読み出される。必要に応じて CPU2503は、 表示制御部 2507、通信制御部 2517、ドライブ装置 2513を制御して、必要な動作を 行わせる。また、処理途中のデータについては、メモリ 2501に格納され、必要があれ ば HDD2505に格納される。本発明の実施例では、上で述べた処理を実施するた めのアプリケーション 'プログラムはリムーバブル'ディスク 2511に格納されて頒布さ れ、ドライブ装置 2513から HDD2505にインストールされる。インターネットなどのネ ットワーク及び通信制御部 2517を経由して、 HDD2505にインストールされる場合も ある。このようなコンピュータ装置は、上で述べた CPU2503、メモリ 2501などのハー ドウエアと OS及び必要なアプリケーション 'プログラムとが有機的に協働することによ り、上で述べたような各種機能を実現する。
[0123] また、ユーザ端末についても、 HDD2505及びドライブ装置 2513の代わりにフラッ シュメモリなどの記憶装置を設けることによりほぼ同様な構成で表すことができる。
[0124] また、図 20のステップ S115については、参加者毎に参加者のプレゼンス登録要求 を PoC管理サーバ 5から SIP/SIMPLEサーバ 3に送信するような構成を説明した。 しかし、例えば最初は所定時間、参加応答を受け付けても直ぐに PoC管理サーバ 5 の会議 A管理部 53aが上記参加者のプレゼンス登録要求を送信せず、所定時間内 に受信した参加応答をまとめて上記参加者のプレゼンス登録要求を送信するように してもよい。最初の所定期間内においては、複数の参加者が参加応答を返信する可 能性が高い。従って、上記参加者のプレゼンス登録要求を多数送信することになつ て、プレゼンスデータの更新が頻繁になり、プレゼンスデータの更新がユーザ端末に 頻繁に通知されるようになると、無線区間の通信帯域が消費されることになる。そこで 、上で述べたように参加応答を所定期間まとめることにより、 SIPZSIMPLEサーバ 3 とユーザ端末間の通信データ量を減少させ、レスポンスを早めることができる。なお、 所定期間経過後については、参加応答を受信する毎にステップ S115以降を実施す ればよい。
[0125] また、図 24のステップ S 241についても同様である。
[0126] さらに、図 18のステップ S95では、 PoC管理サーバ 5がユーザに代わって代理講 読要求を実施するような処理を示した力 自明な場合には他の場面においても PoC 管理サーバ 5や SIPZSIMPLEサーバ 3が、 自動的に講読関係を変更するようにし てもよい。
[0127] また、図 26乃至図 29の処理では、チャットの呼び込み処理を応用するようにしても 良い。その場合には、ステップ S201乃至 S267の処理を画像配信についての呼び 込み処理として実施すればょ ヽ。
[0128] また、画像配信に係る画像データは、静止画であっても良 、し、動画でも良 ヽ。ま た、他のファイルも同様に配信可能である。

Claims

請求の範囲
[1] 音声ベースの電子会議の第 1の参加者による当該音声ベースの電子会議の他の 参加者に対する画像配信依頼を、前記第 1の参加者の端末から受信するステップと 前記第 1の参加者と前記他の参加者とが、更新時に講読者に配信されるプレゼン スデータとして管理される、画像配信に関するデータを講読できるように、プレゼンス 管理設定をプレゼンス ·サーバに行わせる設定ステップと、
を含み、会議管理コンピュータに実行される通信制御方法。
[2] 前記第 1の参加者の端末から画像データを受信し、画像配信用のデータ記憶領域 に格納するステップと、
前記画像データの受信に応答して、前記第 1の参加者のプレゼンスデータの更新 設定を前記プレゼンス ·サーバに行わせるステップと
をさらに含む請求項 1記載の通信制御方法。
[3] 前記画像配信に関するデータが、画像配信に係るユーザの識別情報と画像配信 用リソースに関するデータとを含む請求項 1記載の通信制御方法。
[4] 前記設定ステップが、
前記画像配信に関するデータをプレゼンスデータとして登録するように前記プレゼ ンス ·サーバに要求するステップと、
前記画像配信に関するデータをプレゼンスデータとして公開するように前記プレゼ ンス ·サーバに要求するステップと、
を含む請求項 1記載の通信制御方法。
[5] 前記第 1の参加者力 画像データを受信し、画像配信用のデータ記憶領域に格納 するステップと、
前記画像データの受信に応答して、前記画像配信に関するデータを含むプレゼン スデータの更新設定を前記プレゼンス ·サーバに行わせるステップと、
をさらに含む請求項 1記載の通信制御方法。
[6] 前記他の参加者が、前記音声ベースの電子会議の第 1の参加者により指定された 前記音声ベースの電子会議の参加者のサブセットであることを特徴とする請求項 1記 載の通信制御方法。
[7] 前記画像配信に関するデータを含むプレゼンスデータは、前記音声ベースの電子 会議の一つに対し、複数管理されることを特徴とする請求項 1記載の通信制御方法。
[8] プレゼンスデータに関連する処理を実施するプレゼンス管理手段を有するプレゼン ス.サーノくと、 会議の制御処理を実施する会議管理サーバと
を有し、
前記会議管理サーバは、
音声ベースの電子会議の第 1の参加者の端末力 当該音声ベースの電子会議の 他の参加者に対する画像配信の依頼を受信した場合、画像配信のためのリソースを 確保すると共に、当該画像配信のためのリソースに関するデータを、前記第 1の参加 者と前記他の参加者とが講読できるように、プレゼンス設定要求を前記プレゼンス · サーバに送信し、
前記プレゼンス ·サーバの前記プレゼンス管理手段は、
前記プレゼンス設定要求に応じて、前記第 1の参加者と前記他の参加者とが、前記 画像配信のためのリソースに関するデータを、更新時に講読者に配信されるプレゼ ンスデータとして講読できるように設定する
ことを特徴とするコンピュータ ·システム。
[9] 音声ベースの電子会議の第 1の参加者による当該音声ベースの電子会議の他の 参加者に対する画像配信依頼を、前記第 1の参加者の端末から受信する手段と、 前記第 1の参加者と前記他の参加者とが、更新時に講読者に配信されるプレゼン スデータとして管理される、画像配信に関するデータを講読できるように、プレゼンス 管理設定をプレゼンス ·サーバに行わせる手段と、
を有する会議管理コンピュータ。
[10] 音声ベースの電子会議の第 1の参加者の端末力 サーバへ画像データが格納さ れたことを契機として前記サーバより配信され且つ更新時に講読者に配信されるプレ ゼンスデータとして管理される画像データ配信用のリソースに関するデータを受信す るステップと、 前記受信の後に、前記画像データ配信用のリソースに関するデータを用いて、当 該画像データ配信用のリソース力も前記画像データを取得するステップと、
を含む、電子会議の参加者端末により実行される通信方法。
[11] 音声ベースの電子会議の第 1の参加者の端末力 サーバへ画像データが格納さ れたことを契機にして前記サーバより配信され且つ更新時に講読者に配信されるプ レゼンスデータとして管理される画像データ配信用のリソースに関するデータを受信 するプレゼンスデータ処理部と、
前記受信の後に、前記画像データ配信用のリソースに関するデータを用いて、当 該画像データ配信用のリソースから前記画像データを取得する画像処理部と、 を有する携帯端末。
[12] 音声ベースの電子会議の第 1の参加者の端末力 の画像配信依頼をサーバが受 信したことを契機にして前記サーバより配信され且つ更新時に講読者に配信される 第 1のプレゼンスデータとして管理される画像データ配信用のリソースに関する情報 を受信する第 1の受信ステップと、
前記第 1の参加者の端末から前記サーバへ前記画像配信依頼に対応する画像デ ータが格納されたことを契機にして前記サーバより配信される、前記第 1の参加者の 状態に関する第 2のプレゼンスデータを受信する第 2の受信ステップと、
前記第 2の受信ステップの後に、前記第 1の受信ステップで受信した前記第 1のプ レゼンスデータに含まれる前記画像データ配信用のリソースに関するデータを用 、て 、当該画像データ配信用のリソース力 前記画像データを取得するステップと、 を含む、電子会議の参加者端末により実行される通信方法。
[13] 音声ベースの電子会議の第 1の参加者の端末力 の画像配信依頼をサーバが受 信したことを契機にして前記サーバより配信され且つ更新時に講読者に配信される 第 1のプレゼンスデータとして管理される画像データ配信用のリソースに関する情報 を受信し、前記第 1の参加者の端末から前記サーバへ前記画像配信依頼に対応す る画像データが格納されたことを契機にして前記サーバより配信される、前記第 1の 参加者の状態に関する第 2のプレゼンスデータを受信するプレゼンスデータ処理部 と、 前記第 2のプレゼンスデータの受信の後に、前記第 1のプレゼンスデータに含まれ る前記画像データ配信用のリソースに関するデータを用いて、当該画像データ配信 用のリソース力 前記画像データを取得する画像処理部と、
を有する携帯端末。
PCT/JP2005/014925 2005-08-15 2005-08-15 通信制御方法、コンピュータ・システム、会議管理サーバ、通信方法及び携帯端末 WO2007020685A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP05780235A EP1916607A4 (en) 2005-08-15 2005-08-15 COMMUNICATION CONTROL METHOD, COMPUTER SYSTEM, CONFERENCE MANAGEMENT SERVER, COMMUNICATION METHOD, AND MOBILE TERMINAL
PCT/JP2005/014925 WO2007020685A1 (ja) 2005-08-15 2005-08-15 通信制御方法、コンピュータ・システム、会議管理サーバ、通信方法及び携帯端末
CN200580050959.5A CN101218572B (zh) 2005-08-15 2005-08-15 通信方法以及计算机系统
JP2007530869A JP4707714B2 (ja) 2005-08-15 2005-08-15 通信制御方法、コンピュータ・システム、会議管理サーバ、通信方法及び携帯端末
US12/068,516 US8144185B2 (en) 2005-08-15 2008-02-07 Communication control method, computer system, conference management server, communication method and portable terminal

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2005/014925 WO2007020685A1 (ja) 2005-08-15 2005-08-15 通信制御方法、コンピュータ・システム、会議管理サーバ、通信方法及び携帯端末

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/068,516 Continuation US8144185B2 (en) 2005-08-15 2008-02-07 Communication control method, computer system, conference management server, communication method and portable terminal

Publications (1)

Publication Number Publication Date
WO2007020685A1 true WO2007020685A1 (ja) 2007-02-22

Family

ID=37757357

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/014925 WO2007020685A1 (ja) 2005-08-15 2005-08-15 通信制御方法、コンピュータ・システム、会議管理サーバ、通信方法及び携帯端末

Country Status (5)

Country Link
US (1) US8144185B2 (ja)
EP (1) EP1916607A4 (ja)
JP (1) JP4707714B2 (ja)
CN (1) CN101218572B (ja)
WO (1) WO2007020685A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008139566A1 (ja) * 2007-05-08 2008-11-20 Fujitsu Limited 情報通信システム、情報通信方法、情報通信装置及びコンピュータプログラム
US8144185B2 (en) 2005-08-15 2012-03-27 Fujitsu Limited Communication control method, computer system, conference management server, communication method and portable terminal
JP2013243723A (ja) * 2007-06-20 2013-12-05 Qualcomm Inc ワイヤレス通信デバイス間のグループ通信においてメディアを共有するためのシステムおよび方法
US8892145B2 (en) 2010-02-18 2014-11-18 Qualcomm Incorporated System and method for selective media object removal in group communications among wireless communication devices
US9674675B2 (en) 2007-06-20 2017-06-06 Qualcomm Incorporated Synchronizing floor control and media sharing in a half-duplex PTT system

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006197041A (ja) * 2005-01-12 2006-07-27 Nec Corp ＰｏＣシステム、ＰｏＣ携帯端末及びそれらに用いるポインタ表示方法並びにそのプログラム
US20070271337A1 (en) * 2006-05-22 2007-11-22 Microsoft Corporation Quorum for a Real-Time, Collaborative Electronic Meeting
US20070276913A1 (en) * 2006-05-23 2007-11-29 Microsoft Corporation Providing Access to Missed Text Messages in a Real-Time Text-Messaging Conference
US20100190478A1 (en) * 2009-01-23 2010-07-29 Qualcomm Incorporated System and method for push-to-share file distribution with previews
EP2020795B1 (en) * 2007-08-03 2017-11-22 Nokia Solutions and Networks Oy Method and network equipment for maintaining a media stream through another network equipment while suspending an associated media stream connection in a communication network
US10079900B2 (en) * 2008-05-27 2018-09-18 Microsoft Technology Licensing, Llc Techniques to manage presence information
US20100031152A1 (en) * 2008-07-31 2010-02-04 Microsoft Corporation Creation and Navigation of Infinite Canvas Presentation
US8108777B2 (en) 2008-08-11 2012-01-31 Microsoft Corporation Sections of a presentation having user-definable properties
US8649813B2 (en) 2009-04-13 2014-02-11 Qualcomm Incorporated Latency improvement methods in native PTT gateway for a group call with dispatch console clients
US10127524B2 (en) 2009-05-26 2018-11-13 Microsoft Technology Licensing, Llc Shared collaboration canvas
US10108500B2 (en) * 2010-11-30 2018-10-23 Red Hat, Inc. Replicating a group of data objects within a storage network
US9118612B2 (en) 2010-12-15 2015-08-25 Microsoft Technology Licensing, Llc Meeting-specific state indicators
US9383888B2 (en) 2010-12-15 2016-07-05 Microsoft Technology Licensing, Llc Optimized joint document review
US9864612B2 (en) 2010-12-23 2018-01-09 Microsoft Technology Licensing, Llc Techniques to customize a user interface for different displays
GB2502492B (en) * 2011-03-03 2019-04-17 Securekey Tech Inc Methods and systems for selecting a secondary logical communications device
US9544158B2 (en) 2011-10-05 2017-01-10 Microsoft Technology Licensing, Llc Workspace collaboration via a wall-type computing device
US8682973B2 (en) 2011-10-05 2014-03-25 Microsoft Corporation Multi-user and multi-device collaboration
US9996241B2 (en) 2011-10-11 2018-06-12 Microsoft Technology Licensing, Llc Interactive visualization of multiple software functionality content items
US10198485B2 (en) 2011-10-13 2019-02-05 Microsoft Technology Licensing, Llc Authoring of data visualizations and maps
DE102014004069A1 (de) * 2014-03-20 2015-09-24 Unify Gmbh & Co. Kg Verfahren, Softwareprodukt und Vorrichtung zur Steuerung einer Konferenz
JP6582562B2 (ja) * 2015-05-29 2019-10-02 株式会社リコー 通信端末、通信システム、通信方法、及びプログラム
US10587427B2 (en) * 2016-04-14 2020-03-10 Talking Stick, Inc. Equitable electronic group communication session management using an ordered list to provide predetermined equal amount of exclusive time to each of the participants

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002093959A1 (en) 2001-05-11 2002-11-21 Nokia Corporation Mobile instant messaging and presence service
WO2003084258A1 (en) 2002-03-28 2003-10-09 Motorola Inc., A Corporation Of The State Of Delaware Graphics and variable presence architectures in wireless communication networks, mobile handsets and methods therefor
JP2005038393A (ja) * 2003-06-23 2005-02-10 Hitachi Ltd 情報公開設定制御方法、情報管理装置および該情報管理装置を用いたサービス

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3944528B2 (ja) 2002-04-01 2007-07-11 ＳＢＩ Ｒｏｂｏ株式会社 電話によるグループ通話方法及びグループ通話システム
JP4254996B2 (ja) * 2002-06-04 2009-04-15 株式会社日立製作所 コミュニケーションシステムおよびコミュニケーション方法
WO2004004139A2 (en) 2002-06-26 2004-01-08 Yahoo Inc. System and method for communicating images between intercommunicating users
FR2849974B1 (fr) * 2003-01-15 2005-08-26 France Telecom Procede de communication interpersonnelle via un reseau de telecommunication.
US7216147B2 (en) * 2003-03-27 2007-05-08 Microsoft Corporation Controlling publication of presence information
US20040260948A1 (en) * 2003-06-23 2004-12-23 Tatsuhiko Miyata Server and control method for managing permission setting of personal information disclosure
JP3938379B2 (ja) * 2004-08-10 2007-06-27 富士通株式会社 電子音声会議における話者権についての情報処理方法及びプログラム、並びに無線通信携帯端末
JP4707714B2 (ja) 2005-08-15 2011-06-22 富士通株式会社 通信制御方法、コンピュータ・システム、会議管理サーバ、通信方法及び携帯端末

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002093959A1 (en) 2001-05-11 2002-11-21 Nokia Corporation Mobile instant messaging and presence service
WO2003084258A1 (en) 2002-03-28 2003-10-09 Motorola Inc., A Corporation Of The State Of Delaware Graphics and variable presence architectures in wireless communication networks, mobile handsets and methods therefor
JP2005038393A (ja) * 2003-06-23 2005-02-10 Hitachi Ltd 情報公開設定制御方法、情報管理装置および該情報管理装置を用いたサービス

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
INOUE T. ET AL.: "Presence Service o Jitsugen suru Push-Gata Joho Haishin Software: FLAIRINC", FUJITSU, vol. 54, no. 2, 20 March 2003 (2003-03-20), pages 161 - 166, XP002904723 *
See also references of EP1916607A4
SHIMOMURA M. ET AL.: "Communication Kasseika Service -Presence Club- no Teian", THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS 2003 NEN SOGO TAIKAI KOEN RONBUNSHU, TSUSHIN 2, THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS, 3 March 2003 (2003-03-03), pages 184, XP002904722 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8144185B2 (en) 2005-08-15 2012-03-27 Fujitsu Limited Communication control method, computer system, conference management server, communication method and portable terminal
WO2008139566A1 (ja) * 2007-05-08 2008-11-20 Fujitsu Limited 情報通信システム、情報通信方法、情報通信装置及びコンピュータプログラム
JPWO2008139566A1 (ja) * 2007-05-08 2010-07-29 富士通株式会社 情報通信システム、情報通信方法、情報通信装置及びコンピュータプログラム
JP5467866B2 (ja) * 2007-05-08 2014-04-09 富士通株式会社 情報通信システム、情報通信方法、情報通信装置及びコンピュータプログラム
JP2013243723A (ja) * 2007-06-20 2013-12-05 Qualcomm Inc ワイヤレス通信デバイス間のグループ通信においてメディアを共有するためのシステムおよび方法
US8892147B2 (en) 2007-06-20 2014-11-18 Qualcomm Incorporated System and method for sharing media in a group communication among wireless communication devices
US8892148B2 (en) 2007-06-20 2014-11-18 Qualcomm Incorporated System and method for sharing media in a group communication among wireless communication devices
US9210202B2 (en) 2007-06-20 2015-12-08 Qualcomm Incorporated System and method for sharing media in a group communication among wireless communication devices
US9674675B2 (en) 2007-06-20 2017-06-06 Qualcomm Incorporated Synchronizing floor control and media sharing in a half-duplex PTT system
US8892145B2 (en) 2010-02-18 2014-11-18 Qualcomm Incorporated System and method for selective media object removal in group communications among wireless communication devices

Also Published As

Publication number Publication date
EP1916607A4 (en) 2009-03-04
JP4707714B2 (ja) 2011-06-22
CN101218572B (zh) 2011-07-27
US20080136897A1 (en) 2008-06-12
EP1916607A1 (en) 2008-04-30
US8144185B2 (en) 2012-03-27
CN101218572A (zh) 2008-07-09
JPWO2007020685A1 (ja) 2009-02-19

Similar Documents

Publication Publication Date Title
JP4707714B2 (ja) 通信制御方法、コンピュータ・システム、会議管理サーバ、通信方法及び携帯端末
JP4514755B2 (ja) 通信制御方法及びコンピュータ・システム
EP1980949A1 (en) Content distribution method and device in teleconference
JP4668952B2 (ja) プレゼンス・システムとその移動デバイス及びサーバ
JP4357699B2 (ja) 通信手段の通知方法及び通知システム
JP4779450B2 (ja) コンテキスト情報に応じたアプリケーション制御を行うネットワークシステム
KR101518992B1 (ko) 모바일 커뮤니티 서비스를 위한 시스템, 방법 및 장치
JP2005521338A (ja) 通信システムにおいてユーザグループをグローバルかつ固有に識別する方法
KR20110065513A (ko) 네트워크 시스템, 통신 장치, 통신 방법 및 컴퓨터 판독가능 기록매체
JPWO2002054750A1 (ja) 通信システム
JP5063889B2 (ja) 通信端末装置、通信システム及び通信方法
JP2004015692A (ja) 通信アプリケーション間の状態情報共有・処理方法およびそのシステム
JP3910581B2 (ja) 通信制御装置、端末装置、通信システム及び通信方法
JP4340570B2 (ja) アドレス情報配信・収集方法、アドレス情報配信・収集プログラム及び送受信端末
JP3910580B2 (ja) 通信制御装置、端末装置、通信システム及び通信方法
JP5439938B2 (ja) 通信制御装置
JP2010140083A (ja) 通信端末
JP5170558B2 (ja) 通信装置および通信方法
KR20050002981A (ko) 인스턴트 메시지 서비스에 있어서 친구목록 등록방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2007530869

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 200580050959.5

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2005780235

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2005780235

Country of ref document: EP