JP2006085720A - Service provision system and method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To appropriately manage the degree of disclosure of personal information to a third party. <P>SOLUTION: A set value for disclosure propriety of personal attribute information is hierarchically managed according to a disclosure level. When a user requests to change the set value, the consistency of the set values of high order and low order is appropriately changed according to the disclosure propriety level to which the set value to be changed belongs. Thereby, a human error is absorbed by adjusting a setting conflict, and degradation of the security resulting from a user's personal information outflow can be prevented. Since central control of the permission information is carried out to separate from the server actually providing a service, the load of each server is reduced. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to an information disclosure setting method.

Along with the development of communication technology and network technology, a ubiquitous network society that can communicate anytime and anywhere is coming. In communication in the ubiquitous society, it is said that each user can register personal information of the other person in a database and receive various services.

Currently, there is a permission system used in a Unix (Unix is a registered trademark) system as one method for managing privacy protection on a database. This is for a directory or file on a file system with a directory structure.
Using the access unit divided into 3 parts with others, Read (read), Write for each access unit
This is a method to set permission for access for three operations (write) and Execute. The permission is usually set by the administrator of the entire system from the viewpoint of the security of the entire system.

In FIG. 27, parameters used for permission setting are shown together with a structure diagram of a file system used in the Unix system. The permission management method used in Unix will be described using this figure.
First, the precondition of FIG. 27 will be described. In the file system of FIG. 27, a plurality of first hierarchy directories and second hierarchy directories are formed under the root directory, and three files of file A, file B, and file C are stored below the second hierarchy directory. It has a tree structure. It is assumed that there are three users, User A, User B, and User C, on this file system. Also, User A and User C will be Group A, and User A and User B will be Group B.
Is formed.

Each square outside the file system indicates the location of access authority and the setting value (hereinafter referred to as permission) for each directory and file. For example, the square on the right side of file A shows the permission settings for file A. According to the permission settings for file A, the owner of file A is User A, and the group to which group permission is granted is Group A. The type of access authority granted to the owner is r
, W, x, that is, any of Read, Write, and Execute operations can be executed.

Further, the authority given to the group is r and w, that is, the operations that can be performed by the users belonging to Group A are the Read and Write operations. The authority given to others is-and others are file
A cannot be operated at all.
Although not shown, it is assumed that the file system is accompanied by a management server that performs permission management. Each setting value of the permission is stored in a storage unit in the management server, and each time an access to each directory or file occurs, the management server refers to the storage unit to determine the permission.

Next, a method for determining permission when User A, User B, and User C access file A, file B, and file C will be described.
When User A accesses file A, access is started in the order of the root directory, the first hierarchy directory, the second hierarchy directory, and the file. Actually home, User A, fi
Accesses in the order of le A. The file system access management server starts with User A
Check who the owner of home, User A and file A tries to access. The owner is all User A, and r, w, and x operations are permitted for the owner at all levels. Therefore, when User A accesses file A, the file system permits User A to access the first hierarchy directory and then the second hierarchy directory, and finally grant access to file A. To do. Next, write r for file A
ead, execution All executions are also permitted.

On the other hand, for file B and file C, User A is not the owner. Therefore, the file system checks the group permission when determining whether User A accesses file B and file C. For example, User A belongs to Group B. According to the permission settings shown in the box on the right side of file B, users belonging to Group B can perform read and write operations on file B. Therefore, the file system allows User A only to perform read and write operations on file B. The same is true for file C.

Next, User B's file access will be described. When User B accesses home,
The file system determines User B's access authority to home. User B is h
It is not the owner of ome and does not belong to Group A. Therefore, the file system confirms the permissions for others, but the contents of the permissions for others are set to disallow. Therefore, User B has no access authority to home and cannot access all directories and files under home. The owner of file B is User B, but access is blocked in the upper layer, so even if file B is the owner, it cannot be accessed.

Next, User C file access will be described. Since User C belongs to Group A, User C has access rights to the directories at the levels of home and User A. Therefore, the file system permits until User C passes through the second hierarchy directory. For file A, User C is not the owner, so check the group permissions. Since User C belongs to Group A, the file system is
Permits reading and writing to A. For file B, User C is not the owner or belongs to Group B, so the file system checks the permissions for others and
Does not allow access to file B. For file C, since User C is the owner, the file system allows all write, read, and execution operations.

In this way, in Unix access control management, access management is performed on lower directories and files while checking upper directories, so if there is no permission in the upper directories, lower access cannot be made. In other words, no matter how much the lower-level permissions are changed, access cannot be made unless the upper-level permissions are similarly changed. Furthermore, when setting a new access user range, it is necessary to create a new group and set permissions for the group.

Another type of access control is used in relational databases. This is a method of setting an access right for a record in the database for each accessor or a group of several accessors. Simply put, it is a file system that does not use a tree structure, and sets permissions for each data table of the relational database for each accessor. Permissions are set by the database system administrator.

In a business that develops various services based on the subscriber's personal information, setting and managing the range in which the personal information is disclosed is important from the viewpoint of privacy protection. For this reason, it is important to manage permissions for setting and managing the disclosure range of personal information.

In the prior art, a permission management system is attached to a file or database server, and performs permission management for each specific data. That is, there is no server that manages only permission information by distinguishing permission information from other information. For example, in a Unix file system, permission management is performed for various data such as documents and images managed as files. However, in the case of a business that provides a service based on personal information, the service providing means (such as a server) possessed by the service provider physically differs depending on the type of service that the user wants to receive.

For example, the product purchase history at the department store will be stored in the server of the department store, and the terminal location information is stored in the management carrier server of the terminal. When each user wants to change the permissions for his / her information, setting these servers individually is cumbersome and burdensome to the user. Furthermore, the server owned by the service provider also needs to have a separate database for managing permission settings.

In such permission setting, if a simple permission setting method is adopted, the burden on the user increases proportionally as the amount of information increases. As a result, even if the permission function of the system is logically completed, there is a higher risk of information leaking due to a human error. Protection of personal information is the most important factor for a server that registers personal information. Even if the function is caused by a human operation error, if the possibility of leaking becomes high as a result, it is considered that the server itself has a credit problem. Become.

Also, in a business that provides various services based on a user's personal information, the setting of whether or not to disclose personal information frequently occurs depending on the current status, time zone, and mood of the user.
The conventional permission management method is developed on the assumption that the frequency of setting change is not high after the administrator once sets the access control, and it reduces the frequency for frequent updates. There is no mechanism.

Furthermore, there is an upper / lower relationship for each type of personal information in the personal information accompanied by permission. On the other hand, the permissions set for certain personal information are public, read
Multiple settings such as, write, etc. Permission setting values must be set logically consistently among multiple permissions assigned to one piece of personal information, but they are positioned higher and lower than personal information for which permissions are set. The setting value of the permission given to the personal information to be set must be set logically without contradiction.

In addition, when a service provider uses a user's personal information to provide a service to a third party, the user's personal information for the third party is managed by managing only the read / write permission for privacy protection. In addition to determining whether or not access is possible, there are cases where it is necessary to hide the existence of information itself. In the prior art, since the management method determines whether permission is permitted according to a reference request for data to be accessed, the existence itself cannot be concealed. In other words, permission permission is determined = access target exists,
Met.
An object of this invention is to provide the server which can manage a permission appropriately, or the service model using the said server.

In the present invention, by providing a management server that specially manages permission setting values, it is possible to solve the problem of complexity of setting that it is necessary to set permission for each service provider.
The permission setting value management server categorizes and manages various permission setting values according to the hierarchical relationship of permissions. Thereby, appropriate management of permission setting values becomes possible. In addition to the classification according to the hierarchical relationship, an identification code that can identify the hierarchical relationship may be given to the permission and managed according to the identification information.
This makes it possible to appropriately manage not only permission setting values but also information groups having a vertical relationship.

The management server according to the present invention may have a permission automatic setting change function. In other words, when changing the setting value for the lower permission relative to the other permission, the setting value for the upper permission relative to the permission is automatically changed. As a result, it is possible to maintain the consistency of the hierarchical relationship of permissions when changing the permission setting value, so reducing the increase in the burden on the user even when providing services with frequent permission setting changes. Can do. The automatic change of these permission setting values is logical between a plurality of permissions assigned to one piece of personal information, and between permissions set for upper and lower personal information of the one piece of personal information. Change the settings so that no inconsistencies arise.

Since only the permission is managed independently, it is possible to simplify the setting of the permission which has been conventionally performed every time a new service is subscribed, and the usability is improved. Further, not only permission information but also a group of information having a hierarchical relationship can be appropriately managed as compared with the prior art.

In the following embodiments, user attribute information including personal information and presence information is referred to as object information, and whether or not individual object information can be disclosed to a third party is referred to as permission.

In the present embodiment, the structure and operation of a presence server and a network for realizing a service using the presence server will be described.
FIG. 1 schematically shows a functional block diagram of the presence server of the present embodiment. The functional block diagram of FIG. 1 is a diagram showing a logical functional configuration realized in software, but each functional block may be configured by hardware.

FIG. 2 shows how the functional blocks shown in FIG. 1 are realized in hardware. The operations of the various functional blocks shown in FIG. 1 are stored in the program storage unit 26 of the memory 22 shown in FIG. 2, and the CPU 21 reads and executes the operation procedure during operation. The permission setting values required when individual functional blocks operate are stored in the memory 22, and the CPU 21 reads out and writes necessary information by reading the entry table stored in the memory 22.

Next, the overall operation from when the presence server 1 receives a permission setting request from the user and writes the contents into the permission setting table 24 of FIG. 2 will be described.
When the user transmits a permission setting request for his / her information from the terminal, each interface 11-1 to 11-n of the presence server 1 receives the transmission message. Therefore, the message is first transferred to the permission information input / output unit 2, and the permission information transmitting / receiving unit 4 receives the message. Next, construct message permission input information
Transmit to the transfer unit 5. The permission information construction / transfer unit 5 extracts the permission setting request part from the message, constructs the data in a format that can be interpreted inside the server, and converts the constructed user setting request to the permission setting calculation processing unit 3 permission. Setting contents Transfer to external input / output unit 7.

The permission setting content external input / output unit 7 transfers the request to the permission setting content matching unit 9, and the permission setting content matching unit 9 matches the setting content. At this time, information necessary for matching is read out from the information hierarchy relation setting table 23 in the memory 22 shown in FIG. In addition, in order to confirm the contradiction between the currently set permission and the permission setting requested by the user, the current permission setting is read from the permission setting table 24 shown in FIG.

When the permissions are matched, the permission setting correspondence description table 25 shown in FIG.
8 is read, and the permission information is converted into a form corresponding to the description format of the permission setting table 24 of FIG. The permission settings that have undergone matching and description format conversion are transferred to the permission setting internal input / output unit 7. The permission setting internal input / output unit 7 stores the setting contents in a permission setting table 24 on the memory 22 via the data bus 27 of FIG. When the storage is completed, the end of the storage is transmitted to the permission setting content matching unit 9 via the permission setting internal input / output unit 7, and when it is received, a message indicating that the permission setting is successful is sent to the permission setting external input / output unit 7 The permission information transmitting / receiving unit 4 transmits to the user via the interface 11 that the permission setting is successful.

Next, an overall operation when the presence server 1 of the present embodiment reads permission information stored in the presence server 1 and transmits it to the user in response to a user request will be described. First, the interfaces 11 to 11-n that have received the permission acquisition request message from the user receive the message at the permission information transmission / reception unit 4. The permission information transmitting / receiving unit 4 transfers the information to the permission setting external input / output unit 7 of the permission setting calculation processing unit 3. The permission setting external input / output unit 7 transmits the contents to the permission output content calculation unit 10. The permission output content calculation unit 10 issues an acquisition command to the permission setting internal input / output unit 8 in order to acquire permission information designated by the user from the memory 22, and the permission setting internal input / output unit 8 uses the data bus shown in FIG. The designated permission setting content stored in the permission setting table 24 of the memory 22 is called through 27.

Further, the permission output content calculation unit 10 extracts information from the permission setting correspondence description table 25 shown in FIG. 2 via the permission setting internal input / output unit 8, and converts the information described in the memory into permission information for processing by itself. To do. Thereafter, the permission output content calculation unit performs calculation so that no contradiction occurs in the setting content. At this time, information for calculation is read from the information vertical relation setting table 23 in the memory 22 shown in FIG.
After the calculation, the contents are transferred to the permission output information receiving / constructing unit 6 via the permission setting external input / output unit 7.

The permission output information receiving / constructing unit 6 constructs a message that can be interpreted by the user client from the received permission setting contents, and transmits a message describing the permission setting contents from the interface 11 via the permission information transmitting / receiving unit 4. The management console is a device for setting and setting the permission setting correspondence description table 25 and the information hierarchy relation setting table 23 shown in FIG. 2 by the administrator of the presence server.

FIG. 3 shows a hierarchical structure model for classifying object information. In the hierarchical model assumed in this embodiment, the user ID 31 is located in the highest level information of the hierarchical model. The user ID may be anything as long as it can uniquely identify each user, and a name and address may be used in combination instead of numerical values and codes. Information 32 associated with the user is located one level below the user ID. The information accompanying the user is, for example, information indicating whether each user owns a mobile phone or whether a specific service is subscribed. It may be paraphrased as information indicating whether the user is willing to receive a specific service. A user may own multiple terminals or may not own them at all. The same applies to services.

Terminal IDs 33-1 to 33-n and service IDs 34-1 to 34-n are located one level below the user's accompanying information. In this model, if the terminal ID and service ID are known, it is considered that the terminal type and service type are automatically determined. However, the terminal type information and service type information are separated from each ID information, and 1 It may be positioned lower in the hierarchy. As the terminal ID, for example, a telephone number, SIP (Session Initiation Protocol), URI, or the like can be used. Service I
D is, for example, an ID assigned to a service subscriber by a service provider. Needless to say, the terminal type information is information indicating whether the terminal is, for example, a PDA 33-n, a mobile phone 33-1, or a fixed terminal such as a PC. The service type information is, for example, information indicating whether the service subscribed to by the user is the IM service 34-1 or the video chat service 34-n.

Further below the terminal IDs 33-1 to 33-n and the service IDs 34-1 to 34-n, various information 35-1 to 35-n to 38-1 to 38- associated with each terminal and service are provided. n is located. The terminal-accompanying information is various information associated with various terminals such as an online status, a busy status, and position information for each terminal. Service-related information is information necessary for each service provider to develop a service. For example, in the case of a horoscope service provider, the service subscriber's date of birth, constellation, etc. This information is applicable. Presence server
1 stores various object information according to the hierarchical model of FIG.

Although FIG. 3 shows a four-layer hierarchical model, the object information may be stored as a more multilayered structure by further subdividing the structure. Further, the structure may be further simplified, and the object information may be stored as a three-layer or two-layer hierarchy. Actually, the user-attached information on the second layer does not need to be considered in many cases. This is because a user who does not have a terminal or a user who does not subscribe to a service often does not have a user ID in the first place. However, depending on the circumstances of the user or service provider, it may be better to provide a hierarchy of the attached information 32. For example, when the user temporarily stops receiving the service and wants to resume the service after a while, or when the service provider wants to temporarily stop providing the service to the user (for example, For example, when the user can no longer pay the fee), the previous user ID can be used as it is.

FIG. 4 is a diagram showing that the permissions set for each object information have a vertical relationship. The hierarchical structure of permission information possessed by the presence server 1 is the same as the hierarchical structure of object information. The presence server 1 stores information representing this hierarchical structure model in the information hierarchical relation setting table 23 of the memory 22 shown in FIG. 2, and when calculating the above permission information, the permission setting content matching unit 9 and permission output contents shown in FIG. The calculation unit 10 calls and uses it at any time. Comparing FIG. 3 and FIG. 4, the first hierarchical structure of FIG.
This corresponds to the user ID layer in FIG. The presence server 1 recognizes and stores the permission 41 for the user ID as the highest permission.

In the lower hierarchy, there are permissions 42 for each information attached to the user and each service I.
A permission 43 for D, a permission 44 for each terminal ID, and a permission 45 for each piece of information associated with the service and a permission 46 for each piece of information attached to the terminal are stored one level below. The presence server 1 has permission setting information having this structure between the user who set the object information and a third party (not only a service provider but also a so-called third party) who wants to browse the information. Remember the number of combinations.

FIG. 5 is a diagram showing a storage structure in units of setting types of permission settings for object information handled by the presence server 1 of the present invention. The permission setting value can take a plurality of values depending on how much certain object information is to be disclosed to a third party. In the present embodiment, the types of permission that can be set for the object information 41 to 46 are three types: a public setting 52, a read setting 53, and a write setting 54. A value of allow 56 or reject 57 can be set for each type of 52-54.

The public setting 52 is a setting for deciding whether or not to show the information to the viewing user. When permission is set as shown in 55-1, information is shown to the viewing user and rejection is shown as 56-1. If set, the information is not shown to the browsing user. The browsing user who is set to be refusal cannot know that the information is owned by the public user. For example, if the public setting 52 is set to reject for the user ID 41, the browsing user cannot know the user ID of the public user. That is, the presence of the public user can be concealed from a third party. Conversely, when the object information concealment function is added to the presence server, a parameter called “public setting” must be provided in the permission setting type.

The Read setting 53 is a setting for deciding whether to allow or deny reading of the information to the viewing user. When the permission is set as in 55-2, the viewing user can view the information. If you set the refusal so that the browsing user requests to view the information,
You will be notified that the publication has been refused. Write setting 54 is a setting that determines whether to allow or reject the writing of information to the viewing user. If permission is set as in 55-3, the viewing user can register or update the information. . That is, it becomes possible for a third party to update information owned by a public user on behalf of the user. It is possible to set these three permissions for each piece of object information. These three settings have a hierarchical structure. The presence server handles the permission information by setting the highest setting for each object information 41 to 46 as the public setting 52, the lower setting as the Read setting 53, and the lower setting as the Write setting 54. In addition, the contents of these three settings are lawful. For example, when the lowest write setting 54 is permitted, the upper read setting 53 is also permitted, and the highest public setting 52 is also permitted.

If the highest level public setting 52 is rejected, the lower read setting 53 and write setting 54 are similarly rejected. In other words, if the higher setting is rejected, the lower setting is also rejected accordingly, and if the lower setting is permitted, the higher setting is also permitted. This is because, if information can be browsed, it is of course made public, and if it can be updated, it can of course be browsed and should be made public. Therefore, these three settings are a method for making settings that are consistent with each other.

In addition to the public settings 52, read settings 53, and write settings, the permission setting types are:
The presence server can be freely set via the management console of FIG. For example. If the number of public setting types is increased, a more detailed disclosure level can be set. Conversely, if the concealment function is not required, a parameter called public setting can be deleted. In any case, in this embodiment, the object information can be appropriately managed by classifying the object information into a plurality of items and giving them a hierarchical relationship. This information is also stored in the information hierarchical relation setting table 23 of the memory 22 shown in FIG. 2, and is used by the permission setting content matching unit 9 and the permission output content calculating unit 10 shown in FIG. .

6, 7, and 8 are examples of entry tables for setting permissions that are actually stored by the presence server 1 of the present invention. When the presence server 1 stores the permission information set by each user in a memory area as shown by 24 in FIG.
, 81 are stored in three tables. Hereinafter, an operation when the presence server 1 receives a permission setting request from each user and stores the contents will be described. The table 61 shown in FIG. 6 and the table 71 shown in FIG. 7 are the permission setting table 2 of the memory 22 shown in FIG.
Stored in 4. Further, the table 81 shown in FIG. 8 is stored in the permission setting correspondence description table 25 of the memory 22 shown in FIG.

First, the user ID of the user whose information is to be disclosed is searched from the public user name field 62 in the table shown in 61 of FIG. Here, the public user 62 refers to a user who publicizes object information. Simply, it may be considered that the user is receiving some service based on the object information from the service provider.

FIG. 7 is an entry table in which a third party who discloses object information and a set value of permission for the object information are recorded. The entry table of FIG.
Exists for each index indicated in. For example, a user whose public user name is User A has a permission setting entry table identified by index 1. User B
Has an entry table with index 2. The same applies to User C and below.

The presence server 1 searches the browsing user name field from the table corresponding to the read index number in the index table shown in 71, and writes the permission setting in the permission setting content 73 corresponding thereto. Here, the browsing user 72 refers to a user who refers to object information published by a public user or updates on behalf of the public user, or an application server. If the browsing user name cannot be found as a result of searching the browsing user name field, it is regarded as a new permission setting, and a new browsing user name and permission setting contents are added to each field of the index table 71. When the setting request from the user is deletion of permission, the browsing user name designated from the index table 71 is deleted from the browsing user field 72, and the corresponding permission setting content field 73 is also deleted.

Further, when the presence server 1 receives a permission setting acquisition request from the user and reads out the contents, the same operation is performed to read out the permission settings from the permission setting contents 73. In addition, the index table 71 is prepared for users who disclose information. In other words, each public user has an index table. In this table 71, a browsing user 72 and permission setting contents 73 for the browsing user are described. 73 permission settings are described in, for example, a 64-bit binary string. In this binary description, the permission for each information is set by 2 bits from the beginning.

The table 81 in FIG. 8 shows which object information the 2-bit value is the permission for. The number 82 in the table 81 indicates the order of the bit strings, and the target object information is described in the setting target user information 83 corresponding thereto. For example, in the information described in table 81, the first two bits of permission setting 73 are read as the user ID permission corresponding to number 1, and the next two bits are read as the IM service ID permission corresponding to number 1 and number 2. I can do it.

When adding a new public user, the public user name is added to the entry table 61. At this time, the index number described in the index field 63 is automatically set by the server ascertaining the free number. Also, an index table 71 for the public user newly added at that time is prepared. Conversely, when deleting a currently registered public user, first delete the index table 71 of the user to be deleted, then search the user name to be deleted from the public user name field 62 of the entry table 61, and delete the information. To do.

FIG. 8 shows a reference table used when the server interprets the permission setting contents shown in FIG. The reference table 81 in FIG. 8 includes a number field 82 and a setting target information field 83.
It consists of Number field 82 is the number 2 from the top of permission setting 73
The setting target information field 83 describes the information to which the two bits are permitted. In this way, table 81 shows permission setting contents 73
It is possible to read or write what permission is set for which information by combining the table 81 and the table 81.

The following 4 patterns of permissions can be set for 2-bit binary numbers.
1) Open setting 52, Read setting 53 and Write setting 54 are all set to reject,
2) Open setting 52 is permitted, Read setting 53 and Write setting 54 are set to reject,
3) Open setting 52 and Read setting 53 are allowed, and Write setting 54 is set to reject,
4) All permission levels are set to allow,
For example, the setting value 00 is set for the state 1), 01 is set for the 2), 10 is set for the 3), and 4 is set for the 4
It is possible to express setting values of various permission levels by making 11 correspond to).

In this embodiment, the permission level can be set to public setting, read permission, write permission
Although three possible states are assumed, even when the permission level is further subdivided and the setting level is set to four or more, the state of each level can be expressed by binary bits. . For example, if a 3-bit binary number is used, 2 ³ = 8 types of permission levels can be set.

When new object information is added, a new entry is added to the reference table 81. By adding an entry, the permission setting for the object information can be assigned to the bit string shown in the permission setting content field 73 of the index table 71 that has not been used until now. Conversely, when deleting the object information, the entry is deleted from the reference table 81. The bit string from which the entry has been deleted is not referenced when setting or acquiring permission, and becomes an unused bit string.

As described above, in the present embodiment, by giving a numerical code that can express the vertical relationship to the setting value of the permission, management considering the vertical relationship of the permission level is possible.
The permission setting table can be stored in an external database or the like for the purpose of backup or the like. FIG. 9 shows the format of the permission setting table for storing in the external storage means. The table 91 includes a public user name field 92, a browsing user name field 93, and a permission setting content field 94, and describes the same contents as the tables 61 and 71. The setting target information in the table 81 may be stored in a server setting file for backup or the like, for example.

FIG. 10 is a flowchart showing the contents of processing performed by the permission setting content matching unit 9 of FIG. 1 when the presence server 1 receives a permission setting request from the user. The permission setting content matching unit 9 is a processing block that calculates the permission setting content that does not contradict the hierarchical relationship shown in FIGS. 4 and 5 from the content of the permission setting request from the user, and matches the setting content. The operation of this block will be described.

When the permission setting content matching unit 9 receives a user permission setting request in step 101, it acquires program information from the program storage unit 26 of FIG. 2 in step 102, and starts processing. When the processing is started, first, at step 103, it is checked whether the permission setting request from the user is consistent with the hierarchical relationship shown in FIGS. If a contradiction is found, an error is output in step 104, the process is terminated in step 119, and step 120 is performed.
Then, a message indicating that the permission setting has failed is sent back to the permission setting external input / output unit 7 shown in FIG. If there is no contradiction, the permission is first set at step 105. However, when there is a permission setting request for a plurality of pieces of object information at a time, first, the setting described first is processed.

Next, in order to ensure the consistency of the hierarchical relationship in the processing unit shown in FIG. 5 for the permissions set in accordance with the setting request in step 106, the information hierarchical relationship table in the processing unit is changed from the information hierarchical relationship setting table 23 shown in FIG. To check the upper permission in the processing unit. For example, if the setting request is a permission setting for the Write setting, the Read setting is checked. However, since the setting request may be the highest public setting,
In step 107, it is checked whether the setting request is the highest level of the processing unit.

If it is the highest level, the process proceeds to step 111, but if it is not the highest level, the process proceeds to step 108 to compare the setting contents of the processing unit being checked and the upper processing unit. In step 108, if the upper permission setting is rejected and the permission setting being checked is permitted, the upper permission is set to permitted in step 109 because it contradicts the hierarchical relationship in FIG. If there is no contradiction, this process is not performed.

Next, in step 110, the permission check target is moved up one level. For example, if the write setting is currently checked, the check target is moved to the read setting in this step. After that, the steps 106 to are executed once again, and the process is looped up to the highest public setting. When the check is finished up to the highest level, the loop ends at step 107 and step 111
The process proceeds. Incidentally, the processing loop from step 106 to step 110 must be performed while understanding the hierarchical relationship of the processing units shown in FIG.

In step 111, the information hierarchy information table is read from the information hierarchy setting table 23 shown in FIG. 2, and the currently set permission information is read from the permission setting table 24 shown in FIG. The contradiction between the set contents of the object information being set and the contents of the permissions currently set in the upper object information is matched. Since the object information for which permission is currently set may be the user ID at the top of the information unit hierarchy shown in FIG.
To check if it is the top of the information unit. If the currently set object information is the highest, the process proceeds to step 116.

If not, the object information for which permission information is currently set in step 113 is compared with the read setting of the permission setting set in the higher-level object information in the hierarchical relationship diagram shown in FIG. If the upper object information read setting is rejected and the object information read setting that has just been set is allowed, the upper object information is denied to be viewed but the lower object information is allowed to be viewed. Since the contradiction occurs, in step 114, the public object read setting and the read setting are permitted. This can match up and down contradictions. If the condition is not met at step 113, the process at step 114 is not performed.

When this process ends, in step 115, the permission check target is moved to the object information one level higher than the current object information, and the process from step 111 is performed again.
The process is looped until the permission check target moves to the highest user ID. When the permission check target moves to the top, the process proceeds from step 112 to step 116. Incidentally, the processing loop from step 111 to step 115 must be processed while understanding the hierarchical relationship of the object information units shown in FIG. 4, but the information is stored in the object information hierarchical relationship setting table 23 of FIG. Has been. This setting can be freely set by the user in the operation of the presence server 1.

As the process proceeds, it is checked in step 116 whether all settings have been completed. If the permission setting request from the user is only for a plurality of object information, the process proceeds to step 117, the setting request is read next, and the process from step 105 is performed on the setting request. When all the setting requests have been processed, the process proceeds from step 116 to step 118, the process of writing the matched permission setting values to the permission setting table 24 of the memory 22 shown in FIG. 2 is performed, and the process ends at step 119. To do. Thereafter, when a notice of completion of writing is received, in step 120, a message indicating that the permission setting is successful is returned to the user, so that a message is transmitted to the permission setting external output unit 7 shown in FIG.

FIG. 11 is a flowchart showing the contents of processing performed by the permission output content calculation unit 10 of FIG. 1 when the presence server 1 receives a permission acquisition request from the user. The permission output content calculation unit 10 receives a permission acquisition request from the user from the permission setting external milk flow force unit 7 shown in FIG.
After reading the permission setting from, check if the setting does not contradict the hierarchical relationship shown in FIGS. 4 and 5, if there is a contradiction, calculate the permission setting contents, and the calculated permission setting contents It is a processing block to reply to.

A processing method of this block will be described. When the permission output content calculation unit 10 receives a permission information acquisition request from the user from the permission setting external milk flow force unit 7 shown in FIG. 1 in step 131, it reads the processing content from the program storage unit 26 shown in FIG. Processing starts at 132. When the processing is started, first, in step 133, it is checked whether or not the user who has requested the permission acquisition can acquire the requested permission setting. If there is no acquisition right, the process proceeds to step 134, an error is output, the process is terminated at step 149, and the user who sent the permission setting acquisition request at step 150 is notified that there is no acquisition right. A message is transmitted to the permission setting external input / output unit 7 shown in FIG. If there is a right in step 133, the process proceeds to step 135. In step 135, the permission setting is read from the permission setting table 24.

Further, in order to calculate the contradiction in the hierarchical relationship, the information hierarchical relationship setting table 23 shown in FIG.
Read the vertical relationship as shown in. Next, the process proceeds to step 136, and it is checked whether there is a contradiction in the hierarchical relationship shown in FIG. At this time, it is necessary to check permission settings for a plurality of pieces of object information.
The permission setting is read from the first two bits of the permission setting contents 73 of. In the processing unit permission check, first, the processing setting to be checked in step 136 is the highest level,
In other words, move to public settings.

Next, go to step 1001 to check whether the processing setting being checked is at the lowest level, but since the first loop is checking the highest level public setting, it is not at the lowest level and processing is directly performed at step 137. Go ahead and check if the publishing setting is rejected. If it is a rejection, the lower level, that is, the Read setting and the Write setting are naturally also rejected, so that setting is made. If it is permitted, the process proceeds to step 138, and the permission check target is moved down one layer. For example, if the processing setting currently being checked is a public setting, the permission check target is moved to the Read setting one level below.

Thereafter, the process proceeds to step 1001 and resumes, and the process is looped until the lowest process setting is reached. If the process is at the lowest level, the process proceeds from step 1001 to step 140. step 1
In step 40, it is checked whether all object information has been checked. If not, the process proceeds to step 141, the setting for the next object information is read, and the process from step 136 is performed. If completed, the process proceeds to the next step 142. In step 142, it is checked whether there is a contradiction in the vertical relationship shown in FIG. In this process, first, in step 143, the object information to be checked is moved to the user ID.

Thereafter, in step 1002, it is checked whether the object information being checked is the lowest. However, since the currently checked object information is the highest user ID, the process proceeds to step 144 as it is, and the permission setting Read being checked is read. See if the setting is rejected. If it is a rejection, it can be grasped that there is no intention to show the lower-level object information, so in step 146, the contents of all processing settings are set to rejection for all the lower-level object information.

If the read setting is permitted in step 144, the process proceeds to step 145. Step
In 145, the permission check target is moved to the lower level in units of processing. However, user ID
There may be a plurality of pieces of object information located in the lower order. In that case, the lower-level object information is arbitrarily selected, and the permission check target is moved to the object information. The lower-level object information checked at this time is stored. Step 144 is then resumed and the process loops until the lowest object information is checked.

When moving to the lowest object information check, step 1002 to step 147
The process proceeds. In step 147, from the stored subordinate object information that has been checked,
It is investigated whether all branches in the tree structure of FIG. 4 have been checked. If all branches have not been checked, the process proceeds to step 148. In step 148, the permission check target is moved to the object information of the branch that has not been checked yet. Thereafter, the process proceeds to step 1002, and the process is looped until the permission check is completed for all branches. If the permission check has been completed for all branches in step 147, the process proceeds to step 149 and ends.

Thereafter, a message is transmitted to the permission setting external input / output unit 7 shown in FIG. 1 in order to return the permission information checked in step 150 to the user. The process of FIG. 11 performed by the permission output content calculation unit 10 is not an essential process. If the processing of the permission setting content matching unit 9 is trusted and there is a guarantee that the permission setting is not written to the permission setting table 24 by another path, the processing flow shown in FIG. The permission settings that have been made may be sent to the user as they are. However, by executing the processing flow shown in FIG. 11, it is possible to further reduce the possibility that information unintended by the information disclosure user will be leaked.

28 to 30, how the permission setting content matching unit 9 shown in FIG. 1 takes consistency with the permission setting requested by the user, and as a result, what permission setting is shown in the permission setting table shown in FIG. Explain what is stored in 24.
FIG. 28 shows object information currently registered by User A in the presence server 1. UserA's user ID 3101 is located at the top, and UserA owns a mobile phone and PDA as indicated by 3200. Therefore, the phone number 3102, which is the ID of the mobile phone, is located below it, and the PDA I
SIP-URI3105 which is D is located. Further, the cellular phone has a current position 3103 and a telephone in-call information 3104 in the same row as the current position. The PDA has a reception communication form 3106 and a busyness 3107 in the same order as the reception communication form 3106. The presence server 1 holds the object information registered by UserA in such a vertical relationship.

FIG. 29 shows what permission settings are currently set by UserA for UserB. From this figure, it can be seen that UserA now has set User ID 3101 to UserB as public permission and read permission as 3111. Similarly, permissions from 3112 to 3117 are set for the mobile phone number 3102 to the PDA communication mode 3107.

At this time, if the presence server 1 sends the mobile phone location information 3102 from UserA to UserB
Suppose you receive a request that you want ead permission. First, the permission setting matching unit 9 reads the hierarchical relationship shown in FIG. 5 from the information hierarchical relationship setting table 23 shown in FIG. Therefore, since the process that requested the permission setting is a read process, it is understood that the upper process has a public setting. Further, since the setting requested by the user is read permission, it is determined that the upper public setting is also permitted.

Further, in order to match the permission setting based on the vertical relationship between objects, the vertical relationship information shown in FIG. 28 is read from the information vertical relationship setting table 23 shown in FIG. Therefore, the mobile phone location information 3103 for which the permission setting request is made grasps that the mobile phone number 3102 and the user ID 3101 exist as higher-level objects. Also, the currently set permission information shown in FIG. 29 is converted into the permission setting table 24 shown in FIG.
Read from. In the permission setting request from the user, the mobile phone location information is set to read permission, so the public setting of the phone number 3102 of the higher-level mobile phone and the read setting are open to the public as indicated by 3112 in FIG. Although it was read refusal, it changes to public permission and read permission.

Further, the user ID 3101, which is a higher level, is also confirmed. However, as shown in 3111, since the setting was originally the permission for disclosure and the permission for read, it is left as it is. Mobile phone information 3104, PDA S
The IP-URI 3105, the busyness of the PDA 3106, and the communication form 3107 of the PDA can be understood from the hierarchical relationship diagram shown in FIG. Do not rewrite previous content.

As a result, after the setting request from the user, the permission setting table 24 of the memory 22 shown in FIG.
The permission information registered in is the content shown in FIG.
Referring to FIG. 30, UserA only made a request to set the location information permission of the mobile phone to read permission. However, the permission setting content matching unit 9 shown in FIG. In the location information, permission for disclosure is registered, and as shown by reference numeral 3212, permission for disclosure and permission for reading are registered in the telephone number of the mobile phone.

FIG. 12 shows an example of a service model using the presence server of this embodiment. FIG.
User A indicated by 154 registers information in the presence server 1, and the family information notification server 15
User who receives service from 2. In this service, the family information notification server grasps the current information of User A and the family, and for example, when the location information 216 shown in FIG. Service. In this 12, the presence server is owned by a communication carrier, and the family information notification server 152 and the information distribution server 153 are described on the premise that they are owned by a service provider. The server 152 and the information distribution server 153 are owned, and this service may be performed as a business.

The operation of the entire service model will be explained. First, User A indicated by 154 registers his information and his information disclosure setting in the presence server 1, makes a service provision request to the family information notification server 152, and sets up the information distribution server 153. Receive service via. As another application example of the service model, it is possible to register what the whole family wants now and notify the other family members approaching the store that sells it.

FIG. 14 shows a specific operation sequence. The operation will be described below. User A indicated by 154 first transmits a service registration request to the family information notification server 152 in step 171. Then, the family information notification server 152 makes an inquiry about information that can be disclosed to User A indicated by 154 in step 172. On the other hand, in step 173, User A indicated by 154 registers information that can be disclosed to the family information notification server 152. Steps 171 to 17
Processing up to 3 is often performed without a presence server.

At the same time, permission setting is registered in the presence server 1 in step 174. Presence server 1 sets the information disclosure setting registered by User A indicated by 4 in step 17.
Save in the server in step 5. In addition, the family information notification server 152 makes an information update notification reservation for User A to the presence server 1 in step 176 in order to receive notification about the information update of User A and the content of the updated information indicated by 4. Thereafter, User A indicated by 4 registers his / her information update in the presence server 1 in Step 177. Presence server 1 is a family information notification server 152
From Step 176, since the user A has received the information update notification reservation and enjoyed it, he / she tries to send an update notification to the family information notification server 152.

At this time, the presence server 1 first confirms in step 178 the permission setting that User A indicated by 4 has set for the family information notification server 152. After that, only the information that confirms that the Read setting is permitted in the permission setting is sent to the family information notification server 1 in Step 179.
Notify 52. At this time, there are two notification methods: a method for notifying only updated information and a method for notifying all the information of User A shown in 4 including information that has not been updated. The method may be used.

FIG. 16 shows an example of information held by User A indicated by 4 and information notified to the family information notification server 152. In FIG. 16, User A indicated by 154 is a user ID 212 and terminal 1 owned by User A.
, ID 214 of the second terminal 2 possessed by User A, On / Off 215 as information associated with the terminal 2, and a position 216. However, only the user information 212, 214, 215, and 216 of User A indicated by 4 is visible to the family information notification server 152. User A has registered in the permission setting table 22 that the family ID notification server 152 is set to reject the public setting of the ID 213 of the terminal 1, and the permission management unit 3 of the presence server 1 did not notify the ID 213 of the terminal 1 is there.

In addition, when the information update notification method is a method of notifying only updated information, the updated setting is set as refusal of permission setting public setting or read setting for the family information notification server 152 of User A indicated by 154 If there is, the information update notification in step 179 is not performed. UserA indicated by 154 registers his / her information in the presence server, and the presence server 1 performs filtering of information by the permission setting calculation processing unit 3, whereby information distribution to the family information notification server 152 as shown in FIG. It becomes possible.

The family information notification server 152 obtains the updated information of User A shown in 4 in step 179 and confirms the updated information in step 180 and other information that has not been updated. , Determine the contents. Thereafter, when the family information notification server 152 determines service distribution, in step 181, the family information notification server 152 transmits a service distribution request to the information distribution server 153. Thereafter, the information distribution server 153 performs distribution media such as moving images, still images, and characters in accordance with the partner terminal in step 182 and sets the bit rate according to the communication band of User A.
The service is distributed to User A.

However, if the family information notification server 152 confirms the information of User A updated and acquired in step 180 and decides not to distribute the service, the process from step 181 to 183 is not performed and the next Us
Wait until er A's information update is notified. In this sequence, the family information notification server 152 may have the function of the distribution server 153. In this case, the process of step 181 is not performed, and the family information notification server 152 may perform the processes of steps 182 and 183.

FIG. 14 shows the embodiment of FIG. 12 with SIP (Session Initiation Protocol) / SIMPLE (S
This is an example realized using IP for Instant Messaging and Presence Leveraging Extensions). SIP / SIMPLE is a protocol that provides functions necessary for multimedia communication, such as session establishment of real-time communication, update notification reservation of presence information, update notification corresponding thereto, IM, and the like. The SIP server 161 in FIG.
It has a function of routing a message conforming to IP / SIMPLE and transferring it to a target partner.

FIG. 15 shows an application example in which the sequence of FIG. 14 is realized using SIP / SIMPLE.
In FIG. 15, in addition to SIP / SIMPLE, HTTP (Hyper Text Transport Protocol)
To realize the service. In this sequence, the service registration request 171, the public information inquiry 172, and the public information public setting registration 173 are realized by 191, 192, and 193 using HTTP. The processes so far are performed without going through the presence server 1. The permission setting 174 is realized by applying SIMPLE and relaying the SIP server 161 by the MESSAGE method transmission 194. A method is a character string described in the very first part of a SIP / SIMPLE message. By checking the character string, it is possible to determine what purpose the SIP / SIMPLE message is transmitted. . Incidentally, the MESSAGE method is originally a method for transmitting the text-based IM utterance contents, but the apparatus of the present invention has been extended so that permission setting requests and acquisition requests can be made.

Further, the user A information update notification reservation 176 is realized by relaying the SIP server 161 by the SIMPLE SUBSCRIBE message transmission 196. Next information update 177 is REGISTE
This is realized by relaying the SIP server 161 by R message transmission 197. The REGISTER method is originally a method for online registration of a user, but this is also extended in the apparatus of the present invention so that user information can be registered using this method.

Subsequent user A information update notification 179 is NOTIFY message transmission 199 and SIP server 16
Realize by relaying 1. The NOTIFY method is a method for notifying information update with respect to the user information update notification reservation enjoyed by SUBSCRIBE. Subsequent service transmission 183 uses SIP to send an INVITE message for high-real-time video and audio delivery, and then establishes a session between User A154 and information delivery server 153 and then uses the RTP protocol. To transfer the service. For a low-real-time distribution such as a still image or a text base, it is realized by a method of directly transmitting character information using the SIMPLE MESSAGE method. Either way, the SIP server
161 relays and forwards the SIP message.

Note that according to the presence server of this embodiment, not only permission information but also any information group including a logical hierarchical relationship can be appropriately managed.

FIG. 17 shows a second embodiment of the business model using the presence server. 2 in FIG.
User A indicated by 24 often uses the XX department store for everyday shopping, and the XX department store purchase history storage server 221 stores the product purchase history of User A. User A has a user ID 272 shown in FIG. 21, hobby 273, annual income 274, terminal I
D276, a user who receives On / Off 277 and position 278 as information associated with the terminal in the presence server 1 and receives services from the store information distribution server 222. To explain the overall operation, first, User A 224 registers his / her user information and permission settings for the store information distribution server 222 in the presence server 1. Further, a service provision request is made to the store information distribution server 222, and the service is received via the information distribution server 223.

FIG. 10 shows the operation sequence. A specific operation will be described using this sequence. First, in step 231, User A indicated by 224 registers his / her information in the XX department store purchase history storage server 221. This information registration is not the information registered in the message on the network, but as a result of UserA indicated by 224 shopping at XX department store, the purchase history of UserA is accumulated in the purchase history storage server of XX department store indicated by 221 Indicates that Therefore, Fig. 17,
Also, the arrow from UserA shown in 224 shown in FIG. 18 to the XX department store shown as 221 does not indicate a message on the network, but indicates that information is accumulated by performing physical shopping or the like in this way. ing. ○ × Department purchase history storage server 221 stores the history in step 2
32. Register with the presence server.

User A transmits a service registration request to the store information distribution server 222 in step 233. Then, the store information distribution server 222 inquires about information that can be disclosed to User A in step 234. In response to this, in step 235, User A registers information that can be disclosed to the store information distribution server 222. The processing from step 233 to 235 is often performed without going through the presence server. At the same time, in step 236, the presence server 1
In addition, permission settings for the store information distribution server 222 are registered.

In step 237, the presence server 1 stores the permission settings registered by User A in the server. Further, the store information distribution server 222 makes an information update notification reservation for User A to the presence server 1 in step 238 in order to receive notification about the contents of User A information update. Thereafter, User A registers his / her information update in the application server 1 in step 239. Since the presence server 1 receives the user A information update notification reservation from the store information distribution server 222 in step 238 and enjoys it, the permission set by the user A for the store information distribution server 222 in step 240 is given. After confirmation, only the user information for which the Read setting is permitted is notified to the store information distribution server 222 in Step 241 of the user A information update. At this time, there are two notification methods: a method for notifying only updated information and a method for notifying all information held by User A including information that has not been updated. It doesn't matter.

FIG. 21 shows an example of information registered and updated by the user A in the presence server 1 and the XX department store purchase history storage server 221 and information on the user A received by the store information notification server 222. In FIG. 21, User A has a user ID 272, hobby 273, annual income 27 as information accompanying the user.
4. XX stores department store purchase history 274, terminal 1 ID 276 possessed by User A, On / Off 277 and position 278 as information associated with terminal 1. However, the store information distribution server 222
Receiving refusal 281 regarding ser A's annual income information. This is because User A has registered in the presence server 1 permission information that denies the store information distribution server 222 the annual income read setting. Further, when the information update notification method is a method of notifying only updated information, if the permission of the updated information with respect to the store information distribution server 222 is public setting or read setting denial, the information in step 241 No update notification is made.

The store information distribution server 222 obtains the updated information of User A in step 241 and executes step 24.
In step 2, the service information is determined by checking the updated information and other information that has not been updated, and the contents are determined. Thereafter, when the store information distribution server determines the service distribution, in step 243, the store information distribution server transmits a service distribution request to the information distribution server 223. After that, in step 244, the information distribution server 223 performs distribution media such as moving images, still images, characters, etc. according to the partner terminal, bit rate setting according to the communication band of User A, etc. Distributes services such as store information near the current location of User A and service coupons for that store.

At this time, if the store information distribution server 222 confirms the information of User A updated and acquired in step 241 and decides not to distribute the service, the processing from step 243 to 245 is not performed, and the next Us
Wait until er A's information update is notified. In this sequence, the store information distribution server 222 may have the function of the distribution server 223. In this case, the process of step 243 is not performed, and the store information distribution server 222 may perform the processes of steps 244 and 245.

FIG. 18 shows the embodiment of FIG. 17 with SIP (Session Initiation Protocol) / SIMPLE.
This is an example realized using (SIP for Instant Messaging and Presence Leveraging Extensions). FIG. 20 shows an example in which the sequence of FIG. 19 is realized using SIP / SIMPLE and HTTP. A specific operation of FIG. 18 will be described with reference to FIG. In FIG. 19, the purchase history registration 232 of User A is set to SI using a SIP REGISTER message transmission 252.
This is realized by relaying the P server 161. Next, service registration request 233, public information inquiry
234 and public information registration 235 are realized using HTTP in steps 253, 254, and 255. In addition, permission setting registration 236 is performed by SIP in MESSAGE message transmission 256.
This is realized by relaying the server 161.

The next information change notification reservation 238 for User A is realized by relaying the SIP server by SUBSCRIBE message transmission 258. User information update 239 is implemented by SIP server relay using REGISTER message transmission 259 as in 232. For information update notification 241, NOTI
This is realized by relaying the SIP server in the FY message transmission 261. In the case of media distribution with high real-time properties such as a moving image in step 265, the service distribution 245 as the last step transmits the service by RTP after the session is established after the INVITE message is transmitted. In the case of delivery with a low real-time property such as a still image or text, it is realized by transmitting a MESSAGE method. In either method, the SIP message is transferred via the SIP server 161.

FIG. 22 shows a third embodiment of a business model using a presence server. User A301
Is stored in the presence server 1 as a user ID 312 in FIG.
Annual income 314, ID 315 of terminal 1 owned by User A, On / Off 31 as information accompanying terminal 1
6, registered position 317. In addition, User B302 reserves the information update notification for User A and uses
r A user who knows the current state of A. FIG. 24 is an operation sequence diagram of this embodiment. The specific operation of this embodiment will be described with reference to FIG. First, User A has a hobby 3 in Step 321
13 is registered in the presence server 1. Since the presence server 1 is set to store the hobby 313 in the database server A 303-1, this is stored in the database server A 303 in step 322.
Register to -1.

Next, User A registers the location 316 associated with the terminal 1 in the presence server 1 in Step 323.
Since the presence server 1 is set to store the location 316 in the database server B 303-2, in step 324, the location 316 of User A is registered in the database server B 303-2. Then Us
In step 325, er A registers the permission setting for User B in the presence server 1. Then, the presence server 1 stores the permission setting for User B of User A in Step 326.

After that, User B asks the presence server 1 to know the information update of User A.
At 27, the user A information update notification reservation is transmitted. Therefore, presence server 1 uses Us in step 328.
er A first checks the permission set for User B, and notifies User B only about the user information whose Read setting is permitted. Therefore, the presence server 1 uses only the information permitted to be read in steps 329 and 330 in the database server A 303-1 and the database server B 303.
The user information of User A is read from −2, and the user B is notified in step 331.

At this time, if the public setting of the user ID or the read setting is rejected, there is no user information that can be notified, so that in step 331 it is returned that there is no right, and this operation sequence ends. After that, when User A updates position information and hobbies in step 332, for example, the presence server 1 saves the respective user information in the database server A 303-1 and database server B 303-2 in steps 333 and 334, In step 335, User A is User B
In step 336, user B is notified of user information whose read setting is permitted.

Looking at 302 in FIG. 25, the annual income 351 associated with the user in the information of User A notified to User B,
The position 352 associated with the terminal 1 is open to the public. This is because User A has registered permission settings for denying the annual income and position read settings for User B in the permission setting table 24, and the permission control unit 3 of the presence server 1 has determined the disclosure denial notification.
FIG. 23 shows an example in which the embodiment of FIG. 22 is realized by SIP / SIMPLE. In the two drawings, presence server 1 to database server A 303-1 and database server B 303-2 are shown.
The interface between the two is the same, but in FIG.
REG of SIP / SIMPLE is the interface from User B302 to Presence Server 1
The SIP server 161 relays messages using the ISTER, SUBSCRIBE, NOTIFY, and MESSAGE methods.

In the fourth embodiment, another configuration example of the presence server will be described. FIG. 26 is a schematic diagram showing a presence server having a structure different from that shown in FIG. The presence server of this embodiment uses an entry table in which the public user name, the browsing user name, and the permission setting value are combined. That is, the same entry table as the entry table shown in FIG. 9 is used. In the entry table of this method, the public user name field, the browsing user name field, and the permission setting value field are combined into one entry table, so that the entry table is divided as shown in FIGS. This has the advantage that it is easy to perform reverse lookup to search for the user name from the setting contents of the permission.

However, since the data size of the entry table becomes large, it is impossible to store all data in the memory as in the embodiment shown in FIG.
Only necessary parts are expanded in the memory space, and permission setting processing is performed. 20
A disk interface 01 connects the external storage device 2002 and the presence server main body. Further, a reference table (the same table as FIG. 8) for interpreting the permission setting contents is also necessary in the present embodiment.
A cache memory 2003 is provided for storing a reference memory.

In the fifth embodiment, a procedure for changing permissions in an actual usage scene and effects thereof will be described. In FIG. 31, it is assumed that UserA is UserB and a colleague of the company. Further, it is assumed that UserA has a PDA terminal 1 indicated by 4001 and a terminal 2 indicated by 4002, and has registered presence information and permission information in the presence server 1 via the SIP server 161. FIG. 31 shows a model in which the presence server is accessed via the SIP server. However, as shown in FIG. In this case, the presence server 1 has a SIP session control function or UserA
Communication between UserB and UserB is either of a form that does not use SIP. For example, HTTP or Instant
t Messaging etc.

FIG. 33 shows what messages are transmitted and received in the network diagram shown in FIG.
It demonstrates using the sequence diagram shown in FIG. Requ standardized by IETF on this network
The description will be made assuming that communication is performed using the SIP message indicated by est For Comment (RFC) 3261. As described above, this sequence can be realized by a protocol for HTTP or Instant Messaging in addition to SIP.

First, UserB uses its own terminal 4003 to check the state of UserA, and then step 40
11 sends a SUBSCRIBE message to presence server 1. Note that SUBSCRIBE is a method that represents a message type specified by SIP, and SUBSCRIBE is an IETF Reques.
t For Comment (RFC) 3265 specifies how to use it. Next, the presence server 1 that has received the SUBSCRIBE message sends a 200 OK response indicating that the SUBSCRIBE was successful to UserB in step 4012, and then sends a NOTIFY message in step 4013 to notify the presence information of UserA, that is, the object information. Send to UserB. Like the SUBSCRIBE, the NOTIFY message is a method defined in RFC3265, and is a method for describing object information inside the message. In this NOTIFY method, object information of both terminal 1 (4001) and terminal 2 (4002) owned by UserA is transmitted.

FIG. 34 shows the object information disclosed from UserA to UserB based on the permission setting in comparison with all object information held by UserA. Each item shown by 4030-4036 is the object information which UserA has. Actually, the object information held by UserA is registered in the presence server. The permission setting information is held in a permission management unit in the presence server. On the other hand, in the presence server having the configuration shown in FIG. 2, permission setting information is stored in a permission setting table in the memory.

In FIG. 36, when the NOTIFY message in step 4013 arrives at UserB, UserA is Us
Indicates the permissions set for erB. According to FIG. 36, for UserB, Us
The permission is set to open for all object information of erA. Therefore, all the object information 4030 to 4036 shown in FIG. 34 is notified to UserB as it is.

Next, the latter half of the sequence diagram of FIG. 33 will be described. When UserA changes the object information of terminal 1 (4001) in 4014, presence server 1 notifies UserB that the object information of UserA has changed using a NOTIFY message in step 4015. This is because the SUBSCRIBE message sent in step 4011 has an expiration date of a certain time, and if it is within the expiration date, UserA
This is because the presence server 1 notifies UserB of the change contents every time the object information is changed. Steps 4016 and 4017 are sequences when the terminal 2 (4002) changes the object information, and the procedure is the same as steps 4014 and 4015.

Suppose that UserA then ends work hours and arrives at home. Suppose UserA and UserB are company colleagues, but not private friends. UserA is the only information that UserB may want to show to UserB during their private hours outside work hours.
I would like business communication to be made via email. Of course, I don't want to show availability information, location information, and telephone information. In addition, they do not want to call on a mobile phone. Therefore, when returning home, UserA changes the permission settings for UserB. Specifically, a permission setting change request message is transmitted from the terminal possessed by UserA to the presence server 1 (step 4018), and the permission setting stored in the presence server 1 is changed.

The contents are a request to make the mobile phone permission open to the public and a request to make the PDA terminal availability read reject. Receiving the permission setting request, the presence server 1 performs consistency registration of the permission setting in step 4019 and performs registration. FIG. 37 shows the permission settings registered as a result of the permission setting registration in step 4019.
Since the setting change request from UserA contains a request to make the mobile phone permission private, the public setting of the mobile phone number is changed to refusal, and the lower read setting is also adjusted by the presence server 1, Automatically set to reject.

FIG. 35 shows the object information of UserA disclosed to UserB based on the changed permission setting. The information that is disclosed to UserB as the information of terminal 1 is only the ID 4031 and the mail address 4033 of terminal 1, and the availability 4032 is not disclosed. Also, no object information related to the terminal 2 is disclosed.

FIG. 38 is a diagram showing the vertical relationship of object information used in the service shown in FIG. Presence server also shows the location information of the mobile phone and the information on the phone from the top-bottom relationship diagram of FIG.
Matched by 1 and automatically set to refusal to public or refusal to read. Further, it can be seen from FIG. 38 that the availability of the PDA is the lowest object, so that consistency with other permission settings is confirmed, but automatic permission setting change is not performed.

Immediately after UserA changes the permission settings, Presence Server 1 uses User in step 4020
Only the object information permitted by the permission setting, that is, the mail address information is transmitted to the B terminal 4003 by a NOTIFY message. After that, presence server 1 uses
Even if rA updates presence, if it does not give permission to UserB, it will not send a status change notification to UserB. For example, even if User A changes the presence of the mobile phone in Step 4021, the change notification is not transmitted to User B. However,
When the published object information is updated as in step 4022, the object information is transmitted with a NOTIFY message as in step 4023.

39 to 41 are diagrams for explaining how the permission setting request is actually transmitted in step 4018 of FIG. The message for actually requesting permission setting is composed of a packet using the SIP protocol and IP as indicated by 4220 in FIG. Four
221 indicates the IP address of the IP packet, and it depends on whether the IP protocol is IPv4 or IPv6.
4 address or IPv6 address is described. 4222 is a description of the transport layer, and the source port number and the destination port number are described regardless of which TCP / UDP is used for the transport layer.

A portion where actual SIP protocol data is described is a payload portion indicated by 4223. The portion in which this portion is described in more detail is 4224 to 4226. The SIP message includes a SIP request line 4224 describing a message type, a SIP header 4225 describing message settings, and a SIP message body 4226 describing actual data. In this embodiment, as shown in FIG. 40, Instant Messagi defined in IETF Request For Comment (RFC) 3428.
Send setting request using MESSAGE method which is a method for ng.

The MESSAGE method is also used when acquiring permission settings. In the SIP message using the MESSAGE method, a request to the presence server 1 is described using eXchange Markup Langage (XML) as shown in FIG. The permission setting and acquisition request may be made in a description format other than XML in the SIP message body part, or in a description of a schema (grammar) that is different in XML. At this time, the description format of the SIP message body is described in the Content-Type header indicated by 4232 in FIG. The Content-Length header shown in 4233 describes the capacity of the SIP message body in bytes. IETF Request For Comment (RFC) 3261 for the above header
Has a description of how to use it.

Next, the XML schema of the SIP message body part shown in FIG. 41 will be described. XM in Fig. 41
L mainly includes an acl element indicated by 4301, an object-def element indicated by 4302, a flag element indicated by 4303, and a subject element indicated by 4304. The SIP-URI of the user whose permission is set in the acl element
Describe the type of permission to be set in the object-def element, the operation contents of the permission to be set in the flag element, and the SIP-URI of the target to be set and the setting contents in the subject element. The setting contents actually described are in a format as shown in 4305. This description is a sequence of bit strings.

This bit string describes the setting contents from the left in the order of the objects defined by the object-def element, and one object is given the bit for the operation described in the flag element. 0 (reject) or 1 (permit) is set. For example, FIG.
Looking at the setting, the bit string is 000 100. This shows that for the first object, the mobile phone, 000, that is, the setting of public = reject, read = reject, write = reject is described.

In addition, the availability of the second object, the PDA, is 100, that is, the setting of disclosure = permission, read = rejection, and write = rejection is described. In this embodiment, f
The write operation is defined in the lag element, but the flag element only needs to describe the operation you want to set. For example, if you only want to set permissions for the read operation, the flag element
Only the read operation can be used.
With the reception of such a message as a trigger, the presence server 1 checks the consistency of permission settings, complements the settings, and registers them.

It is a functional block diagram of an apparatus to which a permission setting method in the present invention is applied. It is an apparatus figure to which the permission setting system in the present invention is applied. It is the figure which showed the hierarchical structure of the user information handled with this invention apparatus. It is the figure which showed the hierarchical structure in the user information unit of the permission setting performed with this invention apparatus. It is the figure which showed the hierarchical structure in the processing unit of the permission setting performed with this invention apparatus. It is a table figure of the permission setting which this invention apparatus memorize | stores. It is a table figure of the permission setting which this invention apparatus memorize | stores. It is a table figure of the permission setting which this invention apparatus memorize | stores. It is a table figure of the permission setting which this invention apparatus records outside. It is a processing flowchart figure when this invention apparatus sets permission. It is a process flowchart figure when this invention apparatus reads permission. It is a network diagram of the service using this invention apparatus. It is a network diagram when the SIP server of the service using this invention apparatus is used. It is an operation | movement sequence diagram of the service using this invention apparatus. It is an operation | movement sequence diagram when the SIP server of the service using this invention apparatus is used. It is the figure which showed the user information transmitted by the service using this invention apparatus. It is a network diagram of the service using this invention apparatus. It is a network diagram when the SIP server of the service using this invention apparatus is used. It is an operation | movement sequence diagram of the service using this invention apparatus. It is an operation | movement sequence diagram when the SIP server of the service using this invention apparatus is used. It is the figure which showed the user information transmitted by the service using this invention apparatus. It is a network figure at the time of handling a some database server using this invention apparatus. It is a network figure at the time of handling a some database server using this invention apparatus and utilizing a SIP server. It is an operation | movement sequence diagram at the time of handling a some database server using this invention apparatus. It is the figure which showed the information transmitted at the time of handling a some database server using this invention apparatus. It is 2nd Embodiment of the information management apparatus of this invention. It is a figure explaining the management system of the permission in a Unix file system. FIG. 6 is a diagram illustrating a hierarchical structure of object information registered by User A in the presence server in the first embodiment. FIG. 10 is a diagram illustrating permissions that UserA has set for UserB in the first embodiment. In Example 1, it shows the permission after UserA has changed the setting. It is a network block diagram in which the service to which the invention is applied is implemented. It is a network block diagram in which the service to which the invention is applied is implemented. FIG. 29 is a sequence diagram of messages transmitted and received in the network of FIG. 28. It is a figure which shows the relationship between the presence information which UserA and UserB have, and permission. It is another figure which shows the relationship between the presence information which UserA and UserB have, and permission. It is a figure which shows the example of a setting of permission. It is a figure which shows the example of a setting of permission. It is a figure which shows the up-and-down relationship of the object information used with the service shown by FIG. This is a format of a SIP packet for requesting permission setting. It is an example of Message stored in the body part of the SIP packet shown in FIG. It is a figure which shows the XML schema of a SIP message body part.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Presence server, 2 ... Permission information control part, 3 ... Permission management part.

Claims (21)

A server that classifies and manages hierarchically the set values of permission / inhibition (permission) of various attribute information (object information) of registered users with respect to others. 2. The server according to claim 1, wherein the set value of the permission is classified into three levels: whether or not the object information can be disclosed, whether or not the object information can be read, and whether or not the object information can be written. A server characterized by management. The server according to claim 2,
The availability of the disclosure is set as an upper permission level for the availability of reading,
The readability is set as an upper permission level for the writeability,
A server characterized by detecting a contradiction in a set value of a predetermined permission on the basis of a relationship between upper and lower levels of the permission level. In the server according to claim 3, when there is a request for changing a setting value from a user to a permission level other than the disclosure permission among certain permission levels for certain object information,
A server that checks the consistency of the permission setting values of all levels belonging to a higher level with the change request with respect to the setting value with the change request. The server according to claim 4,
When there is a contradiction in the consistency, the server modifies a permission setting value of a level that belongs to a higher level of the permission of the level for which the setting value change request is made. The server according to claim 4,
A server characterized in that a high-order / low-order relationship is assigned to the object information according to the type of the object information, and systematically classified and managed. In the server according to claim 6, when there is a request for changing a setting value for a permission setting value at an arbitrary level with respect to certain object information,
A server that checks the consistency of the permission setting value included in the object information higher than the object information to which the setting value that has received the change request belongs with respect to the setting value that has received the change request. 8. The server according to claim 7, wherein when there is a contradiction in the consistency, the permission setting value belonging to the object information belonging to the higher order of the object information to which the setting value having received the change request belongs is corrected. server. 2. The server according to claim 1, wherein a high-order / low-order relationship is assigned to the attribute information in accordance with the type of the attribute information, and systematically classified and managed. An interface for receiving the transmitted information, a storage means, and a means for reading the information stored in the storage means;
The storage means is an entry table in which various attribute information (object information) of a registered user and a disclosure permission (permission) setting value for the attribute information classified according to a disclosure level are recorded. A server comprising: 11. The server according to claim 10, wherein the permission setting values are classified into a plurality of levels that are associated with each other in a higher level and a lower level,
A server characterized in that a setting value assigned to any of the plurality of levels is recorded in the entry table. The server according to claim 11,
The setting value of the permission includes whether the object information can be disclosed, whether the object information can be read, whether the object information is written (writ
e) is classified into three levels of availability,
A server characterized in that a setting value assigned to any one of the three levels is recorded in the entry table. The server according to claim 11,
Means for extracting a permission setting value change request from the received information;
A server comprising: a determination unit that refers to the entry table and determines whether or not a setting value of the permission requested to change is consistent with a setting value of a higher permission of the setting value. The server according to claim 12, wherein
A server, comprising: means for correcting an upper permission setting value when there is a contradiction between a setting value requested to be changed and an upper permission setting value of the setting value. 12. The server according to claim 11, further comprising an external storage device storing copy data of the entry table. The registered user's various attribute information (object information) is managed hierarchically by assigning a higher / lower relationship to the setting value of disclosure permission / permission (permission) with respect to others. Server control method. The server control method according to claim 16,
Receiving a permission setting value change request for predetermined object information from the registered user;
Determine which level of the permission setting value the change request is for, and
Determine whether the setting value of the permission belonging to the higher level is consistent with the permission setting value requested to be changed,
When there is a contradiction, the server control method is characterized in that a setting value of a permission belonging to the higher level is corrected. The server control method according to claim 16,
A server control method characterized by assigning a higher-order / lower-order relationship according to a type of the object information to the object information, and classifying and managing the object information. The method for controlling a server according to claim 18,
Receiving a permission setting value change request for predetermined object information from the registered user;
Determine which level the object information belongs to,
Determine whether the permission setting value of the object information belonging to the higher level of the object information to which the permission setting value that received the change request belongs does not contradict the permission setting value requested to change,
A server control method characterized by notifying a user of setting change refusal when there is a contradiction. A presence server that categorizes the set values of disclosure permission (permission) of various attribute information (object information) of a registered user with respect to others according to the level of the permission and manages them hierarchically. A service providing server for providing a service to the user, and a terminal for the user to receive the service,
The service providing server makes an access request to the presence server for predetermined object information of a user who intends to provide a service to the presence server,
The presence server sends object information that can be given within a range of permission setting values to the object information requested to be accessed, to the service providing server,
The service providing system provides a service to a user based on the received object information. A presence server that categorizes the set values of disclosure permission (permission) of various attribute information (object information) of a registered user with respect to others according to the level of the permission and manages them hierarchically. A service providing method using a system including at least a service providing server for providing a service and a terminal for the user to receive the service,
The service providing server makes an access request to the presence server for predetermined object information of a user who intends to provide a service to the presence server,
The presence server sends object information that can be given within a range of permission setting values to the object information requested to be accessed, to the service providing server,
The service providing server provides a service to a user based on the received object information.

Images