EP1811737A1 - Mediationssystem und Verfahren zum Aufbau einer Kommunikationsverbindung, bei der private Informationen geschützt sind - Google Patents

Mediationssystem und Verfahren zum Aufbau einer Kommunikationsverbindung, bei der private Informationen geschützt sind Download PDF

Info

Publication number
EP1811737A1
EP1811737A1 EP20060017064 EP06017064A EP1811737A1 EP 1811737 A1 EP1811737 A1 EP 1811737A1 EP 20060017064 EP20060017064 EP 20060017064 EP 06017064 A EP06017064 A EP 06017064A EP 1811737 A1 EP1811737 A1 EP 1811737A1
Authority
EP
European Patent Office
Prior art keywords
sep
session
client
attribute information
function
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
EP20060017064
Other languages
English (en)
French (fr)
Other versions
EP1811737B1 (de
Inventor
Tadashi Kaji
Osamu Takata
Takahiro Fujishiro
Kazuyoshi Hoshino
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
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 Hitachi Ltd filed Critical Hitachi Ltd
Publication of EP1811737A1 publication Critical patent/EP1811737A1/de
Application granted granted Critical
Publication of EP1811737B1 publication Critical patent/EP1811737B1/de
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • 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/1069—Session establishment or de-establishment
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5683—Storage of data provided by user terminals, i.e. reverse caching

Definitions

  • the present invention relates to an access control in a system which establishes a communication session via multiple session managing servers, by using a control communication protocol among multiple entities.
  • control communication protocol When data communication is performed, for example, between two entities (for example, two devices or two processes which are implemented by executing software on the devices), a control communication protocol may be used. This control communication protocol is independent from the data communication, so as to control the data communication such as enabling the data communication, shutting down the data communication, and the like.
  • SIP Session Initiation Protocol
  • control communication protocols are developed, assuming a mechanism in which one or multiple session managing servers mediate a process for establishing a communication session between entities (hereinafter, also referred to as “clients”) .
  • clients entities
  • a session managing server also referred to as an "SIP server”
  • ISP Internet connection service provider
  • the session managing server is utilized so that a first client establishes a communication session (hereinafter, also referred to as merely "session") with a second client, thereby enabling the data communication therebetween.
  • a communication session hereinafter, also referred to as merely "session”
  • the first client registers an IP address of its own in the session managing server, prior to the process for establishing the communication session.
  • this client transmits to the session managing server, a registration request message (also referred to as "REGISTER message") including an identifier (also referred to as SIP-URI) to uniquely identify the client or a user of the client in the session managing server and the IP address of the client .
  • the session managing server records the identifier and the IP address described in the registration request message, in such a manner as being associated with each other.
  • association between the identifier and the IP address of the client which is recorded in the session managing server, is designed to be deleted after a lapse of effective period given at the time of recording the association.
  • this association may be deleted by sending from the client, a registration delete request message, i.e., REGISTER message that specifies to set zero to the effective period of the association.
  • the client logs in the session managing server a situation in which the identifier and IP address of a client (entity) are recorded, in such a manner as associated with each other in the session managing server.
  • the client logs out of the session managing server a situation in which there is not such recording.
  • Logging-in enables the session managing server to transmit an INVITE message (described below) that is received from a source client, to a destination client. On the other hand, this logging-in also allows the session managing server to accept an INVITE message or the like from the destination client as well.
  • a second client also logs in the session managing server prior to the session establishing processing.
  • the first client performs a processing to establish a session with the second client.
  • the first client transmits to the session managing server, a connection request message (hereinafter, also referred to as "INVITE message") which requests to establish a session with the second client.
  • INVITE message a connection request message
  • the session managing server which has received the INVITE message transmits the INVITE message to the second client. If the second client that has received the INVITE message accepts the connection request, it transmits to the session managing server a response message indicating the acceptance (also referred to as "200 OK message"). The session managing server returns the response message to the first client. Receiving the response message by the first client indicates that the communication session between the first client and the second client has been established.
  • the first session managing server which has received the INVITE message transfers the INVITE message to the second session managing server.
  • the second session managing server transfers the INVITE message to the second client.
  • the second client transmits the response message to the second session managing server.
  • the second session managing server which has received the response message transfers the response message to the first session managing server.
  • the first session managing server transfers the response message to the first client.
  • each ISP when an ISP provides its own customer with an IP phone service, each ISP operates the SIP server. Then, the SIP servers cooperate with one another to establish sessions for IP phones, between the IP phone client software programs which are running on terminals owned by the customers.
  • the second session managing server upon receipt of an INVITE message from the first client via the first session managing server, obtains attribute information of the user who is using the first client, and provides a service appropriate for the attribute information.
  • the user who logs in the first session managing server has to provide the attribute information to the second session managing server, even though the user is not logging in the second session managing server. If the user wants to use another service that logs in a third session managing server, it is also required to provide the attribute information to the third session managing server.
  • the second session managing server makes a wrong judgment regarding service-providing conditions, such as providing a service with a lower age limit to a user under that limit age.
  • the first session managing server only performs a process to simply transfer an INVITE message or a response message, without knowing what kind of judgment is a basis for providing the service.
  • the present invention mainly features that a session managing server manages attribute information of a user using a client that is logging in this session managing server, or attribute information of a service operating on the client; conditions for establishing a communication session (hereinafter, referred to as "Session Establishment Policy (SEP)”) are exchanged among multiple session managing servers; and the session managing server that manages the attribute information compares the attribute information with the SEP to make an access judgment whether or not the communication session is to be established, thereby preventing a copy of the attribute information from being distributed.
  • SEP Session Establishment Policy
  • the present invention includes an SEP providing means which provides an SEP, when the SEP is registered, updated, or deleted in the above individual managing servers, or when there is a request for the SEP from another session managing server.
  • the above session managing server includes a session managing server retrieving means and an SEP obtaining means.
  • the session managing server retrieving means retrieves a session managing server which a sending source client or a destination client of the INVITE message logs in, and the server obtaining means obtains an SEP from the session managing server that has been retrieved by the session managing server retrieving means.
  • the present invention mainly features that evidence indicating which session managing server has made access judgment based on what kind of SEP, is transmitted together with the above INVITE message or the above response message. Further, a session managing server which has not made the above access judgment checks the evidence so as to be aware in advance a basis for judgment on which other session managing servers try to provide a service, the session managing servers being related to the establishment of communication session.
  • the session managing server is provided with an evidence adding means which adds the evidence to the INVITE message or the response message when the above access judgment has been made, and an evidence verifying means which verifies the evidence when the INVITE message or the response message has the evidence being added.
  • the present invention produces an effect as the following; in a system involving multiple session managing servers to establish a communication session, it is possible to prevent a part or all of attribute information from being distributed.
  • the present invention produces an effect that it is possible to check what kind of judgment is a basis for providing a service by the session managing server which is related to establishing the communication session.
  • the present invention is also applicable to a system which sends and receives an INVITE message and a response message via a session managing server, when a communication session is established.
  • FIG. 1 is a diagram showing a system configuration of the SIP communication system to which the present invention is applied.
  • the SIP communication system is provided with n units of user terminal device (referred to as “user terminal") 10, m units of service server device (hereinafter, referred to as “server device”) 20, and two units of session managing device 30 are connected with one another via the network 0, and further, each of the session managing devices 30 is provided with an attribute information managing device 40 which is connected via a local network.
  • user terminal referred to as "user terminal”
  • server device service server device
  • attribute information managing device 40 which is connected via a local network.
  • the user terminal 10 is a device employed for user 1 to utilize the SIP communication system and a user application program is executed which allows the user terminal 10 to be operable as an entity on the user side.
  • a process (entity) implemented by executing this application program will be referred to as "application 100" in the following.
  • the server device 20 is a server device to provide a service to the user 1 or the user terminal 10, and a service program to implement the entity (referred to as "service 2") on the side to provide the service is executed on the server device.
  • service 2 a service program to implement the entity
  • the session managing device 30 is a managing device to control a communication session between the user terminal 10 and the server device 20, and a program to implement a session managing server 300 is operated thereon.
  • the session managing server 300 implements a login managing function 301 which performs processing to allow the application 100 (or the service 2) to log in or log out, a session control function 302 which controls the communication session between the application 100 and the service 2, a judgment request function 303 which requests the attribute information managing device 40 to judge whether or not establishment of communication session is allowed at the time when the session control function 302 performs processing for establishing the communication session, an SEP managing function 304 to manage the SEP 6, an SEP obtaining function 305 to obtain an SEP from another session managing device 30, an SEP sending function 306 to send the SEP 6 to another session managing device 30, an evidence creating function 307 which creates an evidence indicating on what kind of SEP the access judgment has been made, according to a result of the judgment requested to the attribute information managing device 40, and an evidence verifying function 308 to verify the evidence that was created by another session managing device 30. Furthermore, the session managing server 300 manages a registrar DB 309 in which the login managing the application 100 (or the service 2) to log in or log out
  • SIP-URI issued for the user 1 is used as SIP-URI to be registered in the session managing server 300 when the application 100 logs in. Therefore, login of the application 100 will also be referred to as login of the user 1.
  • the present invention is not limited to the example above.
  • three or more session managing devices 30 are arranged and different applications 100 and services 2 may log in the respective session managing devices.
  • FIG. 5 is a diagram showing a structure of the registrar DB 309.
  • the registrar DB 309 as shown in FIG. 5 comprises SIP-URI field 3091 which records SIP-URI of the user 1, which is used as SIP-URI of the application 100, and SIP-URI of the service 2, IP address field 3092 which records an IP address that is allocated to a user terminal 10 used by the user 1 and the server device 20 on which the service 2 is operating, and an effective period field 3093 which records the effective period for the association between the SIP-URI and the IP address.
  • the SIP-URI is represented as a character string concatenating a name of the user 1 or the service 2 with a name of the session managing server 300 (hereinafter, also referred to as "domain name") which the user 1 or the service 2 logs in, by using "@” therebetween, adding "sip:” on the top, which indicates that this character string is SIP-URI.
  • domain name a name of the session managing server 300
  • the user 1 1 has a name "user 11”
  • the session managing device 30 1 which the application 100 1 used by the user 1 logs in, has a name "sipl.hitachi.jp".
  • the SIP-URI of the user 1 and the application 100 1 is formed as "sip:user11@sipl.hitachi.jp".
  • the user 1 and the application 100 2 form SIP-URI being "sip:user12@sip1.hitachi.jp”
  • the user 1 and the application 100 n form SIP-URI being "sip:user12@sip1.hitachi.jp”.
  • the service 2 1 has a name of "service 21”
  • the session managing device 30 2 which the service 21 logs in has a name of "sip2.hitachi.jp”. Therefore, the name of SIP-URI of the service 2 1 is formed as "sip:service21@sip2.hitachi.jp".
  • SIP-URI of the service 2 2 is formed as "sip:service22@sip2.hitachi.jp"
  • SIP-URI of service 2 m is formed as "sip:service2m@sip2.hitachi.jp”.
  • FIG. 3 is an illustration showing a structure of the SEP DB 310.
  • the SEP DB 310 as shown in FIG. 3 comprises SIP-URI field 3101 to record SIP-URI of the user 1 or the service 2 in which SEP 6 is being set, and SEP field 3102 to record the SEP 6.
  • a setting is made so that the service 2 1 is allowed to accept a connection request from the user 1 having an attribute that a man whose address belongs to any one of Tokyo, Kanagawa, Saitama, and Chiba, and the age is 20 years old or more, and less than 30 years old.
  • the SEP 6 targeted for the user 11 is represented as SEP 6 11
  • the SEP 6 targeted for the user 12 is represented as SEP 6 12
  • the SEP 6 targeted for the service 21 is represented as SEP 6 21
  • the SEP 6 targeted for the service 22 is represented as SEP 6 22 .
  • permission for accepting a connection or a connection request means that enjoying a service and rendering a service are permitted.
  • the attribute information managing device 40 is a device which manages attribute information relating to the user 1 and service 2, and it is provided with programs to implement attribute information managing service 401 which performs registering, deleting, and updating the attribute information, and conformity judging service 402 which makes a judge requested from the session managing device 30, and attribute information DB 410 in which the attribute information managing service 401 records the attribute information of the user 1 and service 2.
  • FIG. 4A and FIG. 4B are illustrations each showing a structure of the attribute information DB 410.
  • the attribute information DB 410 includes a user attribute information table 411 which records attribute information of the user 1, and service attribute information table 412 which records attribute information of the service 2.
  • the user attribute information table 411 includes SIP-URI field 4110 which records SIP-URI of the user 1, name field 4111 which records a name of the user 1, address field 4112 which records an address of the user 1, age field 4113 which records age of the user 1, sex field 4114 which records sex of the user 1, and occupation field 4115 which records an occupation of the user 1, and the user attribute information table 411 manages all of above items as a set of information.
  • the service attribute information table 412 includes SIP-URI field 4120 which records SIP-URI of the service 2, name field 4121 which records a name of the service 2, recommended age field 4122 which records a recommended age of the user 1 who is allowed to use the service 2, violence field 4123 which records attribute information indicating whether or not a violent expression is included in the service 2, and sexual expression field 4124 which records attribute information indicating whether or not a sexual expression is included in the service 2, and the service attribute information table 412 manages all of above items as a set of information.
  • the service attribute information table 412 of the attribute information DB 410 2 does not record the attribute information of the user 1 who is using the user terminal 10 logging in the session managing device 30 1
  • the user attribute information table 411 of the attribute information DB 410 1 does not record the attribute information of the service 2 of the server device 20 which logs in the session managing device 30 2 .
  • An electric computer which is provided with, for example as shown in FIG. 2, CPU 91, memory 92, external storage 93 such as hard disk, reader 94 which reads information from a recording medium 99 with portability such as CD-ROM, communication device 95 which establishes connection with another device via a network or LAN, input device 96 such as a keyboard and mouse, output device 97 such as monitor and printer, interface 98 which conducts data sending and receiving among those elements above, and local network which connects various peripheral equipment.
  • the CPU 91 executes an operating system (referred to as "OS") loaded on the memory 92, and further executes a predetermined program under the control of the OS, whereby, each function and each service of the user terminal 10, server device 20, session managing device 30, and attribute information managing device 40 as shown in FIG. 1 can be implemented.
  • OS operating system
  • the service 2, application 100, session managing server 300, attribute information managing service 401, and conformity judging service 402 can be implemented as a process by the CPU 91 which executes a predetermined program.
  • the registrar DB 309, SEP DB 301, and attribute information DB 403 can be implemented by the CPU 91 utilizing the memory 92 and external storage 93.
  • This predetermined program to implement above elements on the electric computer as described above may be installed via the reader 94 from a storage medium 99 which is available for the electric computer. Alternatively, it may be installed via the communication device 95 from another server by way of a communication medium available for the electric computer, such as network 0, or a carrier wave or a digital signal carried through the network 0.
  • a communication medium available for the electric computer such as network 0, or a carrier wave or a digital signal carried through the network 0.
  • the program In installing the program, it is possible to store the program once in the external storage 93, and then, it is loaded on the memory 92 therefrom, so as to be executed by the CPU 91. Alternatively, the program may be directly loaded on the memory 92 without stored in the external storage 93, and then executed by the CPU 91.
  • the configuration of the present embodiment is not limited to the above example.
  • the attribute information managing device 40 may be provided with a function of access restriction, which identifies a device accessing the attribute information managing device 40, and permits a connection only from a particular session managing device 30, or only a specific area of the user attribute information table 411 and the service attribute information table 412 is allowed to be accessed.
  • the communication via the network 0 is vulnerable to tapping by a third person, it is desirable that the communication between the session managing device 30 and the attribute information managing device 40 is encrypted.
  • session managing device 30 and the attribute information managing device 40 may be the same device.
  • the user attribute information table 411 when information to be described in the user attribute information table 411 is registered, updated, or deleted, the user 1 requests as such in writing or face-to-face communication, and an administrator of the attribute information managing device 40 modifies the user attribute information table 411.
  • an administrator of the attribute information managing device 40 modifies the user attribute information table 411.
  • a provider of the service 2 requests as such in writing or face-to-face communication and the service attribute information table 412 is modified.
  • this modification is performed interactively through a procedure that the attribute information managing service 401 having received a command of the administrator from the input device 96 modifies the table, and displays a result on the output device 97.
  • the present invention is not limited to the above procedure.
  • the administrator of the attribute information managing device 40 is given an advantage that he or she is allowed to update the attribute information remotely via the network 0. This configuration produces another advantage that it is not necessary to prepare the input device 96 and the output device 97.
  • an operation when the user 1 or the application 100 logs in the session managing server 300 (as explained above, referred to as "the application 100 logs in” in the following) and an operation when the service 2 logs in the session managing server 300 are the same as the operation of the system utilizing a normal SIP. Therefore, those operations will not be tediously explained. While the user 1 logs in the session managing server 300, registration, updating, and deletion of SEP are enabled, also allowing data communication with the service 2 having logged in the session managing server 300.
  • FIG. 6 is a diagram which shows an operation sequence, when user 1 1 deletes SEP 6 11 managed on the session managing server 300 1 and then registers a new SEP 6 11 .
  • the user 1 1 starts the application 100 1 and logs in, then gives a directive to startup of SEP processing according to a predetermined operation (S601).
  • the application 100 1 that is given the directive to start the SEP process, makes an inquiry as to the SEP 6 11 currently registered in the session managing server 300 1 (S602).
  • SEP managing function 304 1 of the session managing server 300 1 searches the registrar DB 309 1 using the sending source IP address of the SEP 6 11 as a search key, and obtains SIP-URI of the user 1 1 (S603).
  • the SEP managing function 304 1 searches the SEP DB 310 1 using this SIP-URI as a search key (S604), and sends the SEP 6 11 to the application 100 1 (S605).
  • the application 100 1 which has received the SEP 6 11 from the session managing server 300 1 displays an SEP processing screen for the user, via the user terminal OS (S606).
  • FIG. 7 is an example of the SEP processing screen.
  • the SEP processing screen as shown in FIG. 7 includes SEP display field 701 which displays the SEP 6 currently registered in the session managing device 30, SEP input field 702 to input a new SEP 6, SEP register button 703 which registers in the session managing device 30 the SEP 6 inputted in the SEP input field, SEP delete button 704 which deletes the SEP 6 which is registered in the session managing device 30, and close button 705 which closes the SEP processing screen.
  • the application 100 1 transmits an SEP deletes request to the session managing server 300 1 (S608).
  • the SEP managing function 304 1 searches the registrar DB 309 1 using the sending source IP address of this SEP delete request as a search key, and obtains SIP-URI of the user 1 1 (S609) .
  • the SEP managing function 304 searches the SEP DB 310 1 using the SIP-URI as a search key (S610), deletes a value in the SEP field 3102 being associated with this SIP-URI (S611), and then returns a delete completion message to the application 100 1 (S612).
  • the application 100 1 which has received the delete completion message displays for the user 1 1 , the SEP processing screen with the SEP display field 701 being blank (S613).
  • the user 1 1 inputs data into the SEP input field 702 to register a new SEP 6 11 (S614), and clicks the SEP register button 703 (S615).
  • the application 100 1 which has detected that SEP register button 703 has been clicked, transmits the data inputted into the SEP input field to the session managing server 300 1 , assuming the data as SEP 6 11 (S616).
  • the SEP managing function 304 1 searches the registrar DB 309 1 using the sending source IP address of the SEP 6 11 as a search key, and obtains the SIP-URI of the user 1, that is, the application 100 1 (S617).
  • the SEP managing function 304 1 searches the SEP DB 310 1 using this SIP-URI as a search key (S618), overwrites with the SEP 6 11 the SEP field 3102 being associated with the SIP-URI (5619), and then, returns the registration completion message to the application 100 1 (S620).
  • the application 100 1 which has received the registration completion message displays for the user 1 1 the SEP processing screen, on which the SEP display field 701 has been updated with the above SEP 6 11 (S621).
  • the user 1 by himself or herself performs registration or deletion of SEP 6 of the user 1 via the network 0, but the present invention is not limited to this example.
  • the registration or deletion may be performed by a third person who is authorized by the user 1 to perform the registration or deletion of the SEP 6 (referred to as "authorized person").
  • authorized person a third person who is authorized by the user 1 to perform the registration or deletion of the SEP 6
  • the user 1 or the above authorized person makes a request by writing or by phone to the administrator of the session managing device 30, so as to allow the administrator to register or delete the SEP 6 of the user 1.
  • This configuration may produce an effect that even when the user or the authorized person is not aware of an accurate description method of the SEP 6, the SEP 6 can be set just by informing the administrator of details of the SEP 6 in a natural language.
  • the application 100 waits for a directive of session establishment or data from the network 0 in step 1001.
  • the application 100 creates an INVITE message 50 to the service 2 1 in step 1011, then transmits the INVITE message 50 to the session managing server 300 which the application 100 logs in (step 1012) and waits for a response message 51 from the session managing server 300 (step 1013).
  • the application 100 When the application 100 receives the response message 51 from the session managing server 300, it analyzes the details of the response message, and checks whether or not the communication is permitted (step 1014).
  • step 1015 If the communication is not permitted, the process returns to step 1001. If the communication is permitted, the application 100 transmits to the session managing server 300 a confirmation message 52 (step 1015), establishes the communication session with the service 2 1 , and then returns to step 1001.
  • the application 100 Upon receipt of the INVITE message 50 from the network 0 in step 1001, the application 100 performs the INVITE processing such as setting the communication device so as to establish communication with the sending source of the INVITE message (step 1021), then creates a response message 51 (step 1022), and then transmits the response message 51 to the session managing server 300 (step 1023).
  • the INVITE processing such as setting the communication device so as to establish communication with the sending source of the INVITE message (step 1021), then creates a response message 51 (step 1022), and then transmits the response message 51 to the session managing server 300 (step 1023).
  • the application 100 waits for data from the network 0 in step 1024.
  • step 1016 Upon receipt of the confirmation message 52 from the session managing server 300, the processing just returns to step 1024. Upon receipt of communication from the sending source of the INVITE message 50, processing from step 1016 is carried out.
  • the session control function 302 waits for a message from another session managing server 300, application 100, or service 2 (step 3001).
  • the session control function 302 checks whether or not the domain name of the sending destination SIP-URI of the INVITE message 50 (indicating the SIP-URI described in the sending destination field, also referred to as "To header field") corresponds to the domain name of the session managing server 300 itself (step 3010).
  • the session control function 302 requests the login managing function 302 to check whether or not the application 100 (or service 2) having the sending destination SIP-URI logs in (step 3030).
  • the session control function 302 requests the SEP managing function 304 to search the SEP DB 310 for an SEP 6 of the sending destination SIP-URI (step 3031).
  • step 3048 processing from step 3048 is executed.
  • step 3032 If there exists an SEP 6 of the sending destination SIP-URI ("Yes" in step 3032), processing proceeds to step 3033.
  • the session control function 302 requests the judgment request function 303 to make an inquiry to the conformity judging service 402, whether or not establishing of communication session is permitted.
  • the judgment request function 303 transmits an evaluation request message 70 including the above SEP 6 and the above sending source SIP-URI, to the conformity judging service 402, obtains an judgment result 71 from the conformity judging service 402 (step 3034), and proceeds to step 3035.
  • FIG. 16 shows formats of the evaluation request message 70 and judgment result 71 according to the present embodiment.
  • the evaluation request message 70 has a format including 4-byte SIP-URI length field 7011, variable length SIP-URI field 7012, 4-byte SEP length field 7013, and variable length SEP field 7014, and these fields are concatenated as a byte sequence.
  • the SIP-URI length field 7011 stores a length of the SIP-URI field 7012
  • the SIP-URI field 7012 stores SIP-URI that requests evaluation.
  • the SEP length field 7013 stores a length of the SEP field 7014
  • the SEP field 7014 stores SEP 6 which requests evaluation.
  • the judgment result 71 has a format including one-byte result code 7101, 4-byte evaluation request message length field 7111, and variable length evaluation request message field 7112, and these fields are concatenated as a byte sequence.
  • the evaluation request message length field 7111 stores a length of the evaluation request message field 7112
  • the evaluation request message field 7112 stores an evaluation request message 70 associated with this judgment result 71.
  • the result code 7101 stores a result of evaluation of the evaluation request message 70, that is, "0" for the case where the attribute information of the SIP-URI included in the above evaluation request message 70 satisfies the SEP 6 included in the above evaluation request message 70; "1" for the case where it is not satisfied; and "-1” for the case where an error occurs during the judgment.
  • the result code is "0"
  • the conformity judging service 402 has determined to permit establishing a session
  • the conformity judging service 402 has determined that establishing the session is not permitted.
  • the session control function 302 executes processing from step 3048.
  • step 3035 the session control function 302 creates a response message rejecting the connection request (step 3036), and executes the processing from step 3057.
  • the session control function 302 determines that the access judgment has not been made properly against the INVITE message, and executes the processing from step 3036.
  • step 3030 if the application 100 (or service 2) having the sending destination SIP-URI has not logged in, the processing from step 3036 is executed.
  • step 3010 if the domain name of the sending destination SIP-URI does not agree with the domain name of the session managing server 300, the session control function 302 checks whether or not the domain name of the sending source SIP-URI of the INVITE message 50 agrees with the domain name of the session managing server 300 (step 3011). When there is no agreement between the domain names, the session control function 302 executes the processing from step 3048. When there is an agreement between the domain names, the session control function 302 checks whether or not the application 100 (or service 2) having the above sending source SIP-URI has already logged in.
  • the session control function 302 requests the SEP obtaining function 305 to create an SEP sending request message 60 which requests for an SEP of the sending destination SIP-URI.
  • the session control function 302 transmits the message thus created to the session managing server 300 having the domain name of the above sending destination SIP-URI (step 3013).
  • the SEP obtaining function 305 is requested to obtain the SEP 6 from the message.
  • the SEP obtaining function 305 obtains the SEP 6 from the SEP sending response message 61 (step 3014).
  • the format of the SEP sending request message 60 and the SEP sending response message 61 conforms to the format of SIP message.
  • FIG. 15A and FIG. 15B are illustrations respectively showing configurations of the SEP sending request message 60 and the SEP sending response message 61.
  • the SEP sending request message 60 indicates that the session managing server 300 1 has requested the session managing server 300 2 to obtain an SEP 6 21 of the service 2 1 , and the SEP sending response message 61 is a response to this SEP sending request message 60.
  • SEP sending request message 60 As shown in FIG. 15A, there is described a character string "GETSEP" on the first line, indicating that the message is an SEP sending request message 60.
  • the sending source field starting from the character string "From:” there is described information indicating a sending source of the message, for example, a domain name of the session managing server 300 1 .
  • the sending destination field starting from the character string "To:” there is described identification information of a counterpart to whom sending request of SEP 6 is made, for example, SIP-URI of the service 2 1 .
  • SIP-URI of the service 2
  • SEP sending response message 61 As shown in FIG. 15B, there is described a character string "200 OK" on the first line, indicating that this message is a response message to something, and there are described the same information items as the above SEP sending request message on the two lines respectively starting from “Call-ID” and "CSeq". Therefore, it is indicated that this message is a response to the above SEP sending request message 60.
  • the sending source field starting from “From:” includes information indicating whose SEP 6 is described by this message, that is, SIP-URI of the service 2 1 .
  • the sending destination field starting from "To:” includes a domain name of the session managing server 300 1 as a partner for sending.
  • SEP 6 21 is described in an area interposed between two character strings " ⁇ SEP>" and " ⁇ /SEP>".
  • the session control function 302 requests the judgment request function 303 to make an inquiry against the conformity judging service 402 to determine whether or not establishment of the communication session is permitted.
  • the judgment request function 303 transmits to the conformity judging service 402 an evaluation request message 70 including the SEP 6 and the sending source SIP-URI, and obtains a judgment result 71 from the conformity judging service 402 (step 3015). If the result received from the conformity judging service 402 indicates that the session establishment is not permitted, processing from step 3036 is executed. If the result received from the conformity judging service 402 in step 3016 indicates that the session establishment is permitted, the judgment request function 303 creates evidence data 80 indicating what kind of judgment has been made (step 3017).
  • the evidence data 80 is to be created by the judgment request function 303, but the present invention is not limited thereto.
  • the evidence data 80 may be created by the session control function 302, or may be created by the conformity judging service 402 and returned to the judgment request function 303.
  • the session control function 302 requests the SEP managing function 304 to retrieve an SEP 6 of the above sending source SIP-URI.
  • the SEP managing function 304 searches the SEP DB 310 for the SEP 6, and gives a response to the session control function 302 (step 3018).
  • the session control function 302 adds to the above INVITE message 50, the SEP 6 of the sending source SIP-URI obtained from the SEP managing function 304 and the evidence data 80, and creates an evidence-added INVITE message 53.
  • FIG. 13 is an illustration showing a configuration of the evidence-added INVITE message 53.
  • the SEP 6 11 of the application 100 1 , and the evidence data 80 having judged whether or not the application 100 1 satisfies the SEP 6 21 of the service 2 1 are added to the body part of the INVITE message 50 from the application 100 1 to the service 2 1 .
  • the SEP 6 11 of the application 100 1 is described in the area interposed between two character strings of " ⁇ SEP>" and " ⁇ /SEP>”.
  • the evidence data 80 is described in the area interposed between two character strings of " ⁇ PROOF>" and " ⁇ /PROOF>".
  • step 3020 the session control function 302 transmits the evidence-added INVITE message 53 to the session managing server 300 having the domain name of the sending destination SIP-URI, and then the session control function 302 executes processing from step 3050.
  • step 3001 when the session control function 302 receives an evidence-added INVITE message 53 from another session managing server 300 or application 100, the session control function 302 shifts the processing to step 3041 and checks whether or not the domain name of the sending destination SIP-URI of the message agrees with the domain name of its own session managing server 300.
  • the session control function 302 executes the processing from step 3048, and if there is an agreement between the domain names, it checks in step 3042 whether or not the application 100 (or server 2) having the sending destination SIP-URI of the evidence-added INVITE message 53 has already logged in.
  • the session control function 302 executes the processing from step 3036, whereas if it has already logged in, it requests the judgment request function 303 to make an inquiry to the conformity judging service 402 as to whether or not the session establishment is permitted.
  • the judgment request function 303 transmits an evaluation request message 70 including the SEP 6 attached to the evidence-added INVITE message 53 and the above sending destination SIP-URI, to the conformity judging service 402, obtains a judgment result 71 from the conformity judging service 402 (step 3043), and proceeds to step 3044.
  • the session control function 302 executes the processing from step 3036. On the other hand, if the result indicates that the session establishment is permitted, the session control function 302 verifies the evidence data 80 which is attached to the evidence-added message 54 in step 3045. In other words, it is checked by verifying the electronic signature, whether or not the author of the evidence data 80 is reliable, and the evidence data 80 has not been tampered.
  • step 3036 If the session control function 302 fails in verifying the electronic signature, the processing from step 3036 is executed. If the verification of the electronic signature is successfully completed, the added SEP 6 and the evidence data 80 are removed from the above evidence-added INVITE message 53, and an INVITE message 50 is created (step 3047).
  • the session control function 302 searches the registrar DB 309 for an IP address which is associated with the above sending destination SIP-URI (step 3048), and transmits the INVITE message 50 to the device having this IP address (step 3049), and then waits for a response message (step 3050).
  • the session control function 302 Upon receipt of the response message in step 3051, the session control function 302 checks whether or not this response message is an evidence-added response message 54 in step 3052.
  • the evidence-added response message 54 is a message to which the evidence data 80 is added in the area interposed between two character strings " ⁇ PROOF>" and " ⁇ /PROOF>” in the body part of the response message 51, and it is possible to determine whether or not the message is an evidence-added response message 54 by checking the body part of the response message.
  • FIG. 14 is an illustration showing a configuration of the evidence-added response message 54 according to the present embodiment.
  • step 3052 if the message is a response message 51 in step 3052, processing from step 3057 is executed, and if it is an evidence-added response message 54, the evidence data 80 added to the message is validated, to verify whether a proper access judgment has been made. In other words, it is checked by verifying the electronic signature, whether or not the author of the evidence data 80 is reliable and the evidence data 80 has not been tampered (step 3053).
  • step 3054 if the above verification fails in step 3054, the processing from step 3056 is executed. If the above verification is successfully performed, it is checked whether or not there exists evidence data 80 to be added to the response message 51 in step 3055.
  • step 3055 if there is evidence data 80 to be added, an evidence-added response message 54 is created by adding the evidence data 80 to the above response message (step 3056).
  • step 3057 it is checked whether or not the domain name of the sending destination SIP-URI of the response message agrees with the domain name of its own session managing server 300. If there is an agreement therebetween, processing is shifted to step 3058, and if the above response message is an evidence-added response message 54, the evidence data 80 is deleted from the evidence-added response message 54, and a response message 51 is created.
  • the registrar DB 309 is searched for an IP address being associated to the above sending destination SIP-URI (step 3059), the response message 51 is transmitted to the device having this IP address (step 3060), and then, processing returns to step 3001.
  • step 3057 If there is no agreement between the domain names in step 3057, the response message is transmitted to the session managing server 300 having the domain name of the sending destination SIP-URI in step 3060, and processing returns to step 3001.
  • step 3001 if a confirmation message 52 is received from another session managing server 300 or application 100, this confirmation message 52 is regarded as a response message 51. Then, proceeding to step 3057 next, the session control function 302 executes the subsequent processing.
  • step 3001 upon receipt of an SEP sending request message 60 from another session managing server 300 or application 100, the next step is step 3021, and the SEP sending function 306 searches the SEP DB 310 for an SEP 6 of the sending destination SIP-URI described in the SEP sending request message 60.
  • step 3022 after the SEP sending function 306 creates an SEP sending response message 61 including the above SEP 6, a response is returned to the sending source of the above SEP sending request message 60, and processing returns to step 3001.
  • step 3021 If there does not exist the SEP 6 of the sending destination SIP-URI in the SEP DB 310 in step 3021, the SEP 6 is treated as a blank character string in the present embodiment.
  • step 3022 instead of interposing the SEP 6 between the two character strings " ⁇ SEP>” and “ ⁇ /SEP>” of the SEP sending response message 61, description of " ⁇ SEP />" is used.
  • the conformity judging service 402 waits for an operation from the session managing server 300 or from an administrator (step 4010).
  • the attribute information DB 410 is inactivated in step 4021 and the processing is terminated.
  • the conformity judging service 402 retrieves SIP-URI and SEP 6 included in the evaluation request message 70, and searches the attribute information DB 410 for the attribute information of the SIP-URI.
  • the conformity judging service 402 gives a response as a judgment result 71 to the session managing server 300, indicating that an error has occurred, and then processing returns to step 4010.
  • the conformity judging service 402 determines whether or not the attribute information satisfies the above SEP 6 (step 4013). If the SEP 6 is a blank character string, it is determined that the attribute information satisfies the SEP 6 at any time.
  • the conformity judging service 402 returns a result of the step 4013 to the session managing server 300, as a judgment result 71 (step 4014), and gets back to step 4010.
  • the application 100, the service 2, the session managing server 300, and the conformity judging service 402 conduct the above operations to send and receive various messages, thereby establishing the communication session.
  • the application 100 1 transmits an INVITE message 50 to the session managing server 300 1 in step 1012 (S801).
  • the session managing server 300 1 which has received the INVITE message 50 sends an SEP sending request message 60 requesting an SEP 6 21 from the session managing server 300 2 which the service 2 1 logs in step 3014 (S802).
  • the session managing server 300 2 returns the SEP sending response message 61 including the SEP 6 21 to the session managing server 300 1 (S3022 in FIG. 9 and 5803) .
  • the session managing server 300 1 which has received the SEP sending response message 61 including the SEP 6 21 from the session managing server 300 2 , sends to the conformity judging service 400 1 , an evaluation request message 70 including the SIP-URI of the application 100 1 and the SEP 6 21 in step 3015 (S3015 in FIG. 9 and S804).
  • the conformity judging service 400 1 having received the evaluation request message 70 evaluates whether or not the attribute information of the application 100 1 satisfies the SEP 6 21 (that is, having attribute of "a male ages from 20 under 30, living in address of any one of the following; Tokyo, Kanagawa, Saitama, and Chiba". Then, in step 4014, the conformity judging service 400 1 returns to the session managing server 300 1 , a judgment result 71, that is, "the attribute information of the application 100 1 satisfies the SEP 6 21 " (step 3016 and S805).
  • the session managing server 300 1 creates an evidence-added INVITE message 53 including the evidence data 80 generated from the judgment result 71, and the SEP 6 11 of the application 100 1 , and transmits thus created message to the session managing server 300 2 in step 3020 (S806).
  • the session managing server 300 2 which has received the evidence-added INVITE message 53 sends to the conformity judging service 400 2 an evaluation request message 70 including the SIP-URI of the service 2 1 and the SEP 6 11 in step 3043 (5807) .
  • the conformity judging service 400 2 which has received the evaluation request message 70, makes evaluations whether or not the attribute information of the service 2 1 satisfies the SEP 6 11 , and returns a judgment result 71 to the session managing server 300 1 in step 4014 (S808).
  • the session managing server 300 2 verifies the evidence data 80 attached to the above evidence-added INVITE message 53 in step 3045 and 3046.
  • step 3047 the session managing server 300 2 creates an INVITE message 50 from the evidence-added INVITE message 53, and transmits the created message to the service 2 1 in step 3049 (S809) .
  • the service 2 1 having received the INVITE message 50 transmits the response message 51 to the session managing server 300 2 in step 1023 (S810)
  • the session managing server 300 2 creates an evidence-added response message 54 in step 3051 to step 3056, and transmits the created message to the session managing server 300 1 (S811).
  • the session managing server 300 1 verifies the evidence data 80 attached to the evidence-added response message 54 in step 3050 to step 3054, the session managing server 300 1 deletes the evidence data 80 from the above evidence added response message 54 in step 3058, and transmits the response message 51 to the application 100 1 in step 3060 (S812).
  • the application 100 1 Upon receipt of the response message 51 in step 1013, the application 100 1 transmits a confirmation message 52 to the session managing server 300 1 in step 1015 (S813).
  • the session managing server 300 1 that has received the confirmation message 52 transmits the confirmation message 52 to the session managing server 300 2 in step 3061, and then the session managing server 300 2 also transmits this confirmation message 52 to the service 2 1 in step 3060 (S815).
  • a communication session is established between the application 100 1 and the service 2 1 .
  • TCP connection is established between the application 100 1 and the service 2 1 , and application data is sent and received between the application 100 1 and the service 2 1 (S 816).
  • the session managing server 300 receives an INVITE message 50 having the sending source SIP-URI domain name agreeing with the domain name of the session managing server 300 itself, and the sending destination SIP-URI domain name does not agree with the domain name of the session managing server 300, an SEP 6 of the application 100 (or service 2) associated with the above sending destination SIP-URI is obtained from the session managing server 300 having the domain name of the sending destination SIP-URI.
  • an evidence-added INVITE message 53 is transmitted, which is obtained by adding the SEP 6 of the application 100 (or service 2) associated with the above sending source SIP-URI to the INVITE message 50, to the session managing server 300 having the domain name of the above sending destination SIP-URI.
  • the attribute information managing device 40 manages the attribute information, and access judgment is made by this attribute information managing device 40. Therefore, according to the system of the present embodiment, there is produced an effect that the access judgment can be carried out without distributing the attribute information.
  • the session managing server 300 transmits the evidence data 80 showing an evidence of the access judgment together with the INVITE message 50 or the response message 51, in a form of evidence-added INVITE message 53 or evidence-added response message 54. Therefore, there is an effect that it is possible to verify what kind of access judgment has been made in the session managing server 300 which has not actually made the access judgment, and there is also an effect that the number of messages sent and received can be reduced, compared to the case where the evidence data 80 is transmitted separately.
  • the evidence-added INVITE message 53 and the evidence-added response message 54 store the SEP 6 and the evidence data 80 in the body part of the INVITE message 50 or in the response message 51. Therefore, it produces an effect that even when an SIP server to which the present embodiment is not applied relays the message, occurrence of error may be avoided.
  • the session managing server 300 may use a new message which is obtained by concatenating the SEP 6 or the evidence data 80 with the INVITE message 50 or the response message 51 in a form of byte sequence.
  • the SEP 6 or the evidence data 80 may be provided with an area to store the INVITE message 50 or the response message 51, and the SEP 6 or the evidence data 80 storing the INVITE message 50 or the response message 51 in the area may be transmitted.
  • the session managing server 300 obtains an SEP 6, which is not managed by its own server, at the time of access judgment. Therefore, the session managing server 300 is only required to manage an SEP 6 of the application 100 or the server 2 which logs in the session managing server 300. Therefore, the size of the SEP DB 310 can be made small.
  • the attribute information managing device 40 is designed to display and update the attribute information of the application 100 or the service 2, and it is possible to obtain a result of the conformity judgment whether or not a certain condition is satisfied, by accessing the attribute information managing device 40 via a local network. Therefore, there is an effect that a drain via the network of the attribute information of the application 100 or the service 2 can be prevented.
  • the session managing server 300 manages the SEP 6, and in order to determine from which session managing server 300 the SEP 6 should be obtained, the same judging method (algorithm) is used as the method in which the session managing server 300 decides a sending destination of the SIP message. Therefore, there is an effect that a function to search out an administrator who is managing the SEP 6 is not necessary.
  • a message sent and received via the network 0 is transmitted in a form of plain text, but it is not limited to this.
  • the message may be sent and received in such a manner as being ciphered, given an electronic signature, or using an encryption communication protocol. With this configuration, there is produced an effect that confidentiality and completeness of the message are made more reliable.
  • the registrar DB 309, SEP DB 310, and the attribute information DB 410 store the information in a form of plain text as it is, but it is not limited to this.
  • the information may be subjected to a process such as encryption or applying electronic signature, prior to being stored. With this configuration, there is produced an effect that confidentiality and completeness of the information stored in the DB are made more reliable.
  • the message sent and received via the network 0 does not include information regarding the communication session between the application 100 and the service 2.
  • the above message may include a name of the protocol used in the above communication session, a name of an encryption algorithm or a digest algorithm, a key used in encrypting process or hash process, or a random number for calculating the key.
  • the present invention when the user 1 establishes a communication session with the service 2, two types of judgment are made, that is, whether or not the attribute information of the user 1 satisfies the SEP 6 of the service 2, and whether or not the attribute information of the service 2 satisfies the SEP 6 of the user 1 (S805 and S808), but the present invention is not limited to this.
  • the session managing server 300 which the service 2 is logging in is only required to verify the evidence, there is produced an effect that high speed processing can be achieved.
  • the session managing server 300 is provided with the SEP managing function 304, the SEP sending function 306, and the SEP DB 310.
  • the present invention is not limited to this.
  • an SEP managing process which is different from the session managing server 300 may be provided with the SEP managing function 304, the SEP sending function 306, and SEP DB 310, and the session managing server 300 may obtain an SEP 6 from the SEP managing process by the SEP obtaining function 305. Furthermore, the session managing server 300 and the SEP managing process may be operated on different devices respectively. With this configuration, there is produced an effect that it is not necessary for the session managing server 300 to change the procedure for obtaining the SEP 6 depending on whether or not the domain name of the SIP-URI which wants to obtain the SEP 6 agrees with the domain name of its own session managing server 300, and it is only required to change a counterpart to which the obtaining request is transmitted.
  • the SEP sending request message 60 and the SEP sending response message 61 use a format conforming to SIP message, but the present invention is not limited to this.
  • a message in an original format may be employed.
  • an SIP message such as an INFO message or a MESSAGE message may be used, and a command for requesting/responding to send, register, or delete the SEP may be described in the body part of the SIP message.
  • Example 2 In the system according to Example 2, the application 100 holds an SEP 6 of the application 100, and the service 2 holds an SEP 6 of the service 2. This point is different from Example 1.
  • FIG. 17 is a diagram showing an operational sequence when the application 100 1 logs in and logs out.
  • the user 1 1 requests the application 100 1 to start up login processing to execute logging in (51601) .
  • the application 100 1 creates an SEP-added REGISTER message 55 which is obtained by adding to a REGISTER message an SEP 6 being held, and transmits the created message to the session managing server 300 1 (S1602).
  • the login managing function 301 1 registers a combination of the sending source SIP-URI of the message and the IP address in the registrar DB 309 1 , as well as registering the SEP 6 11 added to the message in the SEP DB 310 1 (S1603) .
  • the SEP sending function 306 1 transmits an SEP registration request message 62 including the SEP 6 11 to the session managing server 300 2 (S1604).
  • the session managing server 300 2 which has received the SEP registration request message 62 takes out the SEP 6 11 from the message, and registers the SEP in the SEP DB 310 2 (S1605) .
  • the session managing server 300 1 transmits the SEP registration request message 62 to the session managing server 300 2
  • the session managing server 300 1 transmits a response message 51 to the application 100 1 so as to notify that the login processing has been completed (S1606).
  • the application 100 1 which has received the response message 51 notifies the user 1 1 that the login process is completed through a method such as displaying (S1607).
  • the application 100 1 creates a REGISTER message 56 in which an effective period is set to zero, and transmits the created message to the session managing server 300 1 (S1612). Since the session managing server 300 1 has received the REGISTER message 56 in which the effective period is zero, the login managing function 301 1 deletes a combination of the sending source SIP-URI of the message and the IP address from the registrar DB 309 1 , as well as deleting the SEP 6 associated with the sending source SIP-URI from the SEP DB 310 1 (S1613).
  • the SEP sending function 306 1 transmits to the session managing server 300 2 , an SEP deletion request message 63 including the above sending source SIP-URI (S1614).
  • the session managing server 300 2 which has received the SEP deletion request message 63 takes out the above sending source SIP-URI from the message, and deletes the SEP 6 being associated with the SIP-URI from the SEP DB 310 2 (S1615).
  • the session managing server 300 1 transmits the SEP deletion request message 63 to the session managing server 300 2 , the session managing server 300 1 transmits a response message 51 to the application 100 1 so as to inform that the logout processing is competed (S1616).
  • the application 100 1 which has received the response message 51 notifies the user 1 1 that the logout processing is completed through a method such as displaying (S1617). It is to be noted here that a format conforming to the SIP message may be employed for the SEP registration request message 62 and the SEP deletion request message 63 in Example 2.
  • FIG. 15C and FIG. 15D are illustrations respectively showing the SEP registration request message 62 and the SEP deletion request message 63.
  • FIG. 15C shows the SEP registration request message 62 with which the session managing server 300 1 requests the session managing server 300 2 to register the SEP 6 11 of the application 100 1 .
  • FIG. 15D shows the SEP deletion request message 63 with which the session managing server 300 1 requests the session managing server 300 2 to delete the SEP 6 11 of the application 100 1 .
  • SEP registration request message 62 As shown in FIG. 15C, there is described a character string "ADDSEP" in the first line, indicating that the message is an SEP registration request message 62.
  • the sending destination field starting from the character string "To:” there is described information of the sending destination of the message, that is, the domain name of the session managing server 300 2 .
  • the sending source field starting from the character string "From:” there is described identification information indicating an object of the SEP 6 to be registered, that is, SIP-URI of the application 100 1 .
  • SIP-URI an object of the SEP 6 to be registered
  • SEP deletion request message 63 As shown in FIG. 15D, there is described a character string "DELSEP" in the first line, indicating that the message is an SEP deletion request message 63.
  • the sending destination field starting from the character string "To:” there is described information of the sending destination of the message, that is, the domain name of the session managing server 300 2 .
  • the sending source field starting from the character string "From:” there is described identification information indicating an object of the SEP 6 to be deleted, that is, SIP-URI of the application 100 1 .
  • SIP-URI an object of the SEP 6 to be deleted
  • Example 2 when the user 1 modifies the SEP 6, it is assumed that the SEP 6 held by the application 100 is modified in advance, and then the login processing is restarted. This operation is the same when the SEP 6 of the service 2 is modified.
  • Example 2 The operations of the session managing server 300 in Example 2 are similar to those of the session managing server 300 of Example 1. It is to be noted, however, the session managing server 300 of Example 2 obtains an SEP 6 from the SEP DB 310 when access judgment is requested, instead of obtaining the SEP 6 from the session managing server 300 or using the SEP 6 added to the evidence-added INVITE message 53.
  • FIG. 18 is a diagram showing operations of the session managing server 300 of Example 2, a part of operations being different from Example 1.
  • step 3021 and step 3022 do not exist.
  • the processing shifts to step 3012, as in the case of the session managing server 300 of Example 1.
  • step 3012 if the application 100 (or server 2) of the sending source SIP-URI has not logged in yet, the processing from step 3036 is executed as in the case of the session managing server 300 of Example 1.
  • step 3013 the processing shifts to step 3100, and the session managing server 300 searches the SEP DB 310 for an SEP 6 being associated with the sending destination SIP-URI.
  • step 3036 is executed.
  • step 3015 processing from step 3015 is executed.
  • step 3042 if the application 100 (or service 2) of the sending destination SIP-URI has not logged in yet, the processing from step 3036 is executed as in the case of the session managing server 300 of Example 1.
  • step 3043 processing shifts to step 3200, and the session managing server 300 searches the SEP DB 310 for an SEP 6 being associated with the sending source SIP-URI.
  • step 3036 processing from step 3036 is executed.
  • step 3043 processing from step 3043 is executed.
  • Example 2 when the application 100 or the service 2 logs in, the SEP 6 is sent and received between the session managing servers 300, but the present invention is not limited to this. It is also possible that the SEP 6 held by the session managing server 300 is transmitted to another session managing servers 300 repeatedly (for example, with predetermined time intervals). With this configuration, for example, even though the session managing server 300 2 temporarily suspends a service, it is possible to receive all the SEP 6 from the session managing server 300 1 when the service is resumed.
  • Example 2 the SEP registration request message 62 and the SEP deletion request messages 63 use a message in a format conforming to SIP message.
  • the present invention is not limited to this.
  • a message of an original format may be employed.
  • an SIP message such as an INFO message or a MESSAGE message may be used, and a command for requesting/responding to send, register, or delete the SEP may be described in the body part of the SIP message.
  • Example 1 and Example 2 may be combined appropriately for implementation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)
  • Storage Device Security (AREA)
EP20060017064 2006-01-18 2006-08-16 Mediationssystem und Verfahren zum Aufbau einer Kommunikationsverbindung, bei der private Informationen geschützt sind Not-in-force EP1811737B1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006009389A JP4830503B2 (ja) 2006-01-18 2006-01-18 個人情報を保護した通信セッション確立仲介システムおよび方法

Publications (2)

Publication Number Publication Date
EP1811737A1 true EP1811737A1 (de) 2007-07-25
EP1811737B1 EP1811737B1 (de) 2008-10-22

Family

ID=37897342

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20060017064 Not-in-force EP1811737B1 (de) 2006-01-18 2006-08-16 Mediationssystem und Verfahren zum Aufbau einer Kommunikationsverbindung, bei der private Informationen geschützt sind

Country Status (5)

Country Link
US (1) US8095676B2 (de)
EP (1) EP1811737B1 (de)
JP (1) JP4830503B2 (de)
CN (1) CN101005447B (de)
DE (1) DE602006003305D1 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008205988A (ja) * 2007-02-22 2008-09-04 Hitachi Ltd データ通信システムおよびセッション管理サーバ
US8082577B1 (en) * 2008-04-09 2011-12-20 United Services Automobile Association (Usaa) Systems and methods for deployment of secure shell devices
JP5439858B2 (ja) * 2009-02-26 2014-03-12 日本電気株式会社 認証システム、認証装置、認証方法及び認証プログラム
CN101997759B (zh) * 2009-08-10 2013-06-05 中兴通讯股份有限公司 一种业务实现方法及业务系统
US8321566B2 (en) * 2011-02-24 2012-11-27 Jibe Mobile System and method to control application to application communication over a network
WO2014060008A1 (en) * 2012-10-19 2014-04-24 Unify Gmbh & Co. Kg Method and system for creating a virtual sip user agent by use of a webrtc enabled web browser
WO2016168304A1 (en) 2015-04-13 2016-10-20 Research Now Group, Inc. Questionnaire apparatus
CN108830054B (zh) * 2018-06-14 2021-06-29 平安科技（深圳）有限公司 自动授权方法、装置、计算机设备及计算机存储介质
CN111756592B (zh) * 2019-03-28 2022-03-08 中国移动通信有限公司研究院 一种策略处理方法及实体
CN116208575B (zh) * 2023-02-02 2024-06-25 北京工业大学 一种在时空群聊天场景中建立私聊的方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1257129A1 (de) * 2001-05-07 2002-11-13 Telefonaktiebolaget L M Ericsson (Publ) Architektur zum auslösen der Dienste
EP1422909A2 (de) * 2002-11-19 2004-05-26 Fujitsu Limited Netzwerksystem zur Dienststeuerung

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1040197A (ja) * 1996-07-19 1998-02-13 Fujitsu Ltd 通信管理装置
WO2000019326A1 (fr) * 1998-09-29 2000-04-06 Fujitsu Limited Procede et dispositif de traitement de demandes d'acces
JP4320861B2 (ja) * 1999-09-08 2009-08-26 ソニー株式会社 通信システム、通信方法、受信端末装置、認証局装置
JP3855909B2 (ja) * 2002-10-23 2006-12-13 株式会社日立製作所 ポリシ設定可能なピアツーピア通信システム
JP4345368B2 (ja) * 2003-06-17 2009-10-14 株式会社日立製作所 プレゼンス管理装置および情報配信システム
KR100690871B1 (ko) * 2004-10-22 2007-03-09 엘지전자 주식회사 제어기능을 갖는 서버 결정방법
WO2007066170A2 (en) * 2005-01-14 2007-06-14 Lg Electronics Inc. Session invitation method and system
US7991895B2 (en) * 2005-12-09 2011-08-02 Nokia Corporation Limiting access to network functions based on personal characteristics of the user

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1257129A1 (de) * 2001-05-07 2002-11-13 Telefonaktiebolaget L M Ericsson (Publ) Architektur zum auslösen der Dienste
EP1422909A2 (de) * 2002-11-19 2004-05-26 Fujitsu Limited Netzwerksystem zur Dienststeuerung

Also Published As

Publication number Publication date
US20070168521A1 (en) 2007-07-19
DE602006003305D1 (de) 2008-12-04
JP2007193462A (ja) 2007-08-02
JP4830503B2 (ja) 2011-12-07
EP1811737B1 (de) 2008-10-22
CN101005447B (zh) 2011-08-10
US8095676B2 (en) 2012-01-10
CN101005447A (zh) 2007-07-25

Similar Documents

Publication Publication Date Title
EP1811737B1 (de) Mediationssystem und Verfahren zum Aufbau einer Kommunikationsverbindung, bei der private Informationen geschützt sind
EP1645971B1 (de) Datenbankzugriffssteuerverfahren, datenbankzugriffssteuerung, agent-verarbeitungsserver, datenbank-zugriffssteuerprogramm und das programm aufzeichnendes medium
JP4143601B2 (ja) 個人制御および匿名性を提供する効率的なブラウザベースのアイデンティティ管理
US7395424B2 (en) Method and system for stepping up to certificate-based authentication without breaking an existing SSL session
JP4299316B2 (ja) 情報処理システム
RU2332711C2 (ru) ЗАЩИЩЕННАЯ ОБРАБОТКА МАНДАТА КЛИЕНТСКОЙ СИСТЕМЫ ДЛЯ ДОСТУПА К РЕСУРСАМ НА ОСНОВЕ Web
US10397008B2 (en) Management of secret data items used for server authentication
US20030070069A1 (en) Authentication module for an enterprise access management system
EP1724964A1 (de) Verschlüsselungsverfahren und Verschlüsselungssystem für SIP Nachrichten
JPH11212912A (ja) セッション管理システム及び管理方法
JPH1125048A (ja) ネットワークシステムのセキュリティ管理方法
US20020095578A1 (en) System, method, and program for ensuring originality
KR20030016073A (ko) 웹 상에서 쿠키를 통한 사용자 인증 방법 및 인증 시스템
JP2012181662A (ja) アカウント情報連携システム
JP5336262B2 (ja) ユーザ認証システムおよびユーザ認証方法
JP2009043043A (ja) Ｓｉｐを用いた認証システムおよび認証方法
KR101642665B1 (ko) 다이렉트 전자 메일
KR100987768B1 (ko) 대용량 쿠키 처리 방법 및 장치
Bider Extension negotiation in the secure shell (ssh) protocol
JP2003108428A (ja) キャッシュ協調データ取得方法及びプロキシサーバ及びキャッシュ協調データ取得プログラム及びキャッシュ協調データ取得プログラムを格納した記憶媒体
Newman IMAP UNAUTHENTICATE Extension for Connection Reuse
WO2023250216A1 (en) A connectionless-virtual private network for secure cloud to user communication over the internet using a plurality of servers
Newman RFC 8437: IMAP UNAUTHENTICATE Extension for Connection Reuse
JPH1141284A (ja) 情報通信仲介装置
Meyer et al. XMPP Transport Layer Security

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

17P Request for examination filed

Effective date: 20080122

AKX Designation fees paid

Designated state(s): DE FR GB

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): DE FR GB

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REF Corresponds to:

Ref document number: 602006003305

Country of ref document: DE

Date of ref document: 20081204

Kind code of ref document: P

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20090723

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20130814

Year of fee payment: 8

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20130814

Year of fee payment: 8

Ref country code: FR

Payment date: 20130808

Year of fee payment: 8

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602006003305

Country of ref document: DE

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20140816

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602006003305

Country of ref document: DE

Effective date: 20150303

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20150430

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20140816

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20150303

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20140901