CN1316325C

CN1316325C - 服务器

Info

Publication number: CN1316325C
Application number: CNB200410007299XA
Authority: CN
Inventors: 宫田辰彦; 川井惠理
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2003-06-23
Filing date: 2004-02-27
Publication date: 2007-05-16
Anticipated expiration: 2024-02-27
Also published as: CN1573639A; US20040260948A1; EP1492298A3; US20080077997A1; EP1492298A2

Abstract

本发明可对个人信息对第三者的揭示程度进行适当管理。其方法为对个人属性信息的可否揭示的设定值根据揭示级进行分层管理。另外，在用户要求变更设定值的场合，根据变更后的设定值所属的可否揭示级适当变更上位下位的设定值的整合性。通过对设定矛盾的整合，人为错误会得到吸收，可防止由于用户的个人信息外流所引起的安全性的降低。另外，通过对容许信息进行集中管理，实际上与进行服务的服务器分离，可减轻各个服务器的负担。

Description

服务器

技术领域

本发明涉及信息公开的设定方式。

背景技术

随着通信技术和网络技术的发展，随时随地进行通信交流的无所不在的网络社会正在到来。可以说，在无所不在的社会中的通信交流中，各用户可将自己和他人的个人信息登录到数据库并接受种种的服务。

现在，在数据库上管理隐私保护的方式之一，是采用Unix系统正在使用的容许系统。这是一种针对具有目录结构的文件系统上的目录或文件，利用分割为所有者、组、其他人三种访问单位，对每个访问单位在Read(读出)、Write(写入)、Execute(执行)三种操作方面是否容许访问进行设定的方式。容许的设定，通常是从整个系统的安全性的观念出发，由管理者进行。

在图27中，在Unix系统使用的文件系统的结构图中，一并示出在容许设定中使用的参数。下面利用此图对Unix中进行的容许管理方式予以说明。

首先，对图27的前提条件予以说明。图27的文件系统的结构是在root(根)目录下形成多个第一层次目录、第二层次目录，在第二层次目录的下层存放fileA、fileB、fileC共3个文件。在本文件系统中，存在UserA、UserB、UserC三个用户。另外，由UserA和UserC形成GroupA，由UserA和UserB形成GroupB。在文件系统的外侧的各四个角部，示出对各目录、各文件的访问权限的所在和种别(以下称为容许)的设定值。比如，fileA右侧的四角示出多fileA的容许的设定值。根据对fileA容许的设定，fileA的所有者为UserA，赋予组容许的组是GroupA。另外，赋予所有者的访问权限的种别是r、w、x，即Read、Write、Execute中的任何一种都可以执行。赋予组的权限为是r、w，即属于GroupA的用户的可能操作为Read、Write操作。赋予其他人的权限为“-”，即其他人完全不能操作fileA。

虽未被图示出，但在此文件系统中，假设是附带一个对容许进行管理的管理服务器。容许的各设定值，保管在保管服务器内的存储装置中，每当对各目录及文件进行访问时，管理服务器参照该存储装置对容许进行判断。

下面对UserA、UserB、UserC对fileA、fileB、fileC进行访问之际的容许判定方法予以说明。

在UserA访问fileA的场合，开始顺序访问root目录、第一层次目录、第二层次目录、文件。实际上，顺序访问Home，UserA，fileA。文件系统的访问管理服务器，首先，确认UserA意欲访问的Home、UserA的各目录以及fileA的所有者是谁。所有者全部是UserA，对于所有者全部层次都许可r、w、x各操作。因此，在UserA访问fileA的场合，文件系统许可UserA按照第一层次目录、第二层次目录的顺序访问，许可最终访问到fileA。其次，对fileA，许可执行Read、Write、Execute全部的处理。

另一方面，对fileB、fileC，UserA不是所有人。于是，在判定UserA对fileB、fileC的访问之际，文件系统确认组容许。比如，UserA属于GroupB。如根据fileB右侧四角内示出的容许设定值，属于GroupB的用户，对于fileB许可进行Read、Write操作。对于fileC的容许也一样。

下面对UserB的文件访问予以说明。如UserB访问home，文件系统将判定UserB对home的访问权限。UserB不是home的所有人，也不属于GroupA。因此，文件系统按照其他人确认容许，而对其他人设定的容许内容全部是不许可。所以，UserB没有对home进行访问的权限，对home以下的全部目录、文件都不能访问。fileB的所有人是UserB，但因为在上层访问就截止了，所以即使是自己是所有人的fileB也不能访问。

下面对UserC的文件访问予以说明。因为UserC属于GroupA，UserC保有对home、UserA的各层次的目录进行访问的权限。因此，文件系统许可UserC可以通过第二层次为止。对于fileA，因为UserC不是所有人，要确认组容许。因为UserC属于GroupA，所以文件系统对UserC许可对fileA的Read、Write。关于fileB，UserC既不是所有人，也不属于GroupB，文件系统按照其他人确认容许，UserC不能对fileC进行访问。对fileC，因为UserC是所有人，文件系统许可其进行Read、Write、Execute全部操作。

这样，在Unix的访问管理中，因为是在确认上位的目录的同时，对下位的目录、文件的访问进行管理，在对上位的目录没有容许的场合，就不能访问下位。就是说，即使是下位的容许有一些改变，只要上位没有同样的改变，就不能访问。此外还有，在设定新的访问用户范围时，必须生成新的组，对组进行容许设定。

另外，存在以另外的方式在关系数据库中使用的那样的访问控制。这是一种对各访问者、或一些访问者集合而成的组每一个都设定对数据库的记录的访问权的方式。简言之，如果是不采用树结构的文件系统，就要对关系数据库的各数据表的容许对每个访问者进行设定。容许设定，由数据库系统的管理者进行。

在根据加入者的个人信息开展种种服务的商业中，从隐私保护的观点出发，揭示个人信息的范围的设定及管理是重要的。因此，用于对个人信息的揭示范围的设定及管理的容许管理是重要的。

在现有的技术中，容许的管理系统是文件及数据库服务器附带的，是对每一个特定的数据进行容许管理。就是说，过去不存在将容许信息与其他信息进行区别而只对容许信息进行管理的服务器。比如，在Unix的文件系统中，是对作为文件进行管理的文档、图像等种种的数据的每一个进行容许管理的。可是，在根据个人信息提供服务的商业的场合，服务提供者保有的服务提供装置(服务器等)，会由于用户要接受提供的服务的种类的不同而在物理上有差别。比如，在百货商店中的商品购入历史大概会保存于商店保持的服务器中，终端的位置信息保存于终端的管理执行体的服务器中。在各用户想要对自己的信息改变容许时，因为要对这些服务器个别进行访问，设定很烦杂，用户的负担很重。另外，即使是对于服务提供者保有的服务器，有时也需要个别保持管理容许设定的数据库。

在这种容许设定中，如果采用单纯的容许设定方式，随着信息量的增大，用户的负担也按比例增大。其结果，即使是系统的容许功能逻辑上是可以完成的，但由于人自身的操作失误而引起的信息外流的危险性会增加。登录个人信息的服务器是个人信息保护的最重大的因素，其功能，比如，即使是人为的操作失误的原因，如果作为结果外流的可能性很高时，就会变成服务器本身的信用问题。

另外，在根据用户的个人信息进行种种服务的商业中，由于用户的现在状况及时间和心情的不同，个人信息的可否揭示的设定的变更会频繁地发生。现有的容许管理方式，是在管理者一次对访问控制进行设定之后，设定变更频率不大这样的前提上开发的，对于频率高的更新没有减轻频率的规划。

另外还有，在附带容许的个人信息中，在每一种个人信息中都存在上位、下位的关系。另一方面，对某个个人信息设定的容许，像公开、Read、Write等这样设定多个。容许的设定值，在对一个个人信息赋予的多个容许之间逻辑上设定也必须没有矛盾，所以对于设定了容许的个人信息，对于位于上位和下位的个人信息赋予的容许的设定值，设定也必须在逻辑上没有矛盾。

另外，在服务提供者利用用户的个人信息向第三者提供服务的场合，在隐私保护的关系上，有时不只是仅仅要管理Read、Write的可否，还必须要对信息存在的本身进行隐蔽。在现有技术中，由于过去是根据成为访问对象的数据的参照要求来判断容许的可否的管理方式，所以过去一直不能对存在本身进行隐蔽。就是说，过去是对容许进行可否判断＝访问对象存在。

发明内容

本发明的目的在于提供一种可以对容许进行合适管理的服务器或利用该服务器的服务模型。

本发明的服务器具有用于存储用户的终端信息以及该终端的可否通信信息的存储单元，其特征在于，上述存储单元还存储该终端信息与该终端的可否通信信息之间的从属关系、和该终端信息以及该终端的可否通信信息各自的可否公开的设定值，在上述从属关系中，上述终端的可否通信信息为上位，上述终端信息为下位，上述终端的可否通信信息的上述设定值从不可公开变更为可公开的情况下，将上述终端信息的上述设定值变更为可公开，上述终端信息的上述设定值从可公开变更为不可公开的情况下，将上述终端的可否通信信息的上述设定值变更为不可公开。

在本发明中，通过设置专门对容许的设定值进行管理的管理服务器，可以解决每个服务提供者必须进行容许设定的这一设定的烦杂的课题。

在上述容许设定值的管理服务器中，对种种的容许设定值依据容许的上下关系分类成为多个进行管理。由此，可以对容许设定值进行适当地管理。除了依据上下关系进行以外，还可以对对容许赋予可以识别的识别代码，对应于该识别信息进行管理。由此，不仅容许的设定值，对具有上下关系的信息群可以进行适当的管理。

本发明的管理服务器，也可具对有容许进行自动设定变更功能。就是说，在针对其他的容许对相对下位的容许的设定值进行变更之际，对该容许的相对上位的容许的设定值可以自动变更。由此，因为可以在容许设定值变更之际，保持容许的上下关系的整合性，所以就是在提供容许的设定变更频率大的服务之际，也可以减少用户的负担的增加。这些容许设定值的自动变更，可以在赋予一个个人信息的多个容许之间和在为该一个个人信息的上位和下位的个人信息设定的容许之间，在不会产生逻辑矛盾的情况下进行设定变更。

由于只对容许独立地进行管理，历来，每次加入新服务时可以对执行了的容许的设定进行简化，使用性可提高。另外，不仅容许信息，对具有上下关系的信息群，与历来技术相比，可以进行适合的管理。

附图说明

图1为应用本申请发明的容许设定方式的装置的功能框图。

图2为应用本申请发明的容许设定方式的装置图。

图3为示出利用本申请发明的装置处理的用户信息的层次结构的示图。

图4为示出利用本申请发明的装置进行的容许设定的用户单位中的层次结构的示图。

图5为示出利用本申请发明的装置进行的容许设定的处理单位中的层次结构的示图。

图6为本申请发明的装置存储的容许设定的表格图。

图7为本申请发明的装置存储的容许设定的表格图。

图8为本申请发明的装置存储的容许设定的表格图。

图9为本申请发明的装置在外部记录的容许设定的表格图。

图10为本申请发明的装置设定容许时的处理流程图。

图11为本申请发明的装置读出容许时的处理流程图。

图12为利用本申请发明的装置的服务的网络图。

图13为在使用利用本申请发明的装置的服务的SIP服务器时的网络图。

图14为利用本申请发明的装置的服务的动作次序图。

图15为在使用利用本申请发明的装置的服务的SIP服务器时的动作次序图。

图16为示出在利用本申请发明的装置的服务中传输的用户信息的示图。

图17为利用本申请发明的装置的网络图。

图18为在使用利用本申请发明的装置的SIP服务器时的网络图。

图19为利用本申请发明的装置的服务的动作次序图。

图20为在使用利用本申请发明的装置的服务的SIP服务器时的动作次序图。

图21为示出在利用本申请发明的装置的服务中传输的用户信息的示图。

图22为在利用本申请发明的装置处理多个数据库服务器的场合的网络图。

图23为在利用本申请发明的装置处理多个数据库服务器的SIP服务器的场合的网络图。

图24为在利用本申请发明的装置处理多个数据库服务器的场合的动作次序图。

图25为示出在利用本申请发明的装置处理多个数据库服务器的场合的传输的信息示图。

图26为本申请发明的信息管理装置的实施形态2。

图27为说明Unix文件系统的容许的管理方式的说明图。

图28为示出在实施例1中，UserA登录到存在服务器对象信息的层次结构的示图。

图29为示出在实施例1中，UserA对UserB设定的容许的示图。

图30为示出在实施例1中，UserA进行设定变更后的容许的示图。

图31为实施应用本发明的服务的网络构成图。

图32为实施应用本发明的服务的网络构成图。

图33为在图28的网络中收发的消息的次序图。

图34为示出UserA和UserB具有的存在信息和容许的关系的示图。

图35为示出UserA和UserB具有的存在信息和容许的关系的另一示图。

图36为示出容许的设定例的示图。

图37为示出容许的设定例的示图。

图38为示出在图28示出的服务中使用的对象信息的上下关系的示图。

图39为要求容许设定的SIP包的格式。

图40为示出在图36示出的SIP包的正文部分中存放的Message的一例的示图。

图41为示出SIP消息正文部分的XML模式图。

具体实施方式

在以下的实施例中，将包含个人信息、存在信息等用户的属性信息称为对象信息，对第三者各个对象信息可否揭示称为容许。

[实施例1]

下面，对本实施例中的存在服务器的结构、动作以及用于实现利用存在服务器的服务的网络予以说明。

在图1中示意示出本实施例的存在服务器的功能框图。图1的功能框图，为示出在软件上实现的逻辑的功能结构的示图，也可利用硬件来构成各功能框图。

在图2中示出在图1中示出的功能块是任何在硬件上实现的。图1所示的各种功能块的动作，存放于图2所示的存储器22的程序存储单元26中，在动作时CPU21将该动作步骤读出执行。在各个功能块动作之际，必要的容许的设定值存放于存储器22中，CPU21，通过读出存储于存储器22中的登录表，读出、写入必要的信息。

下面对存在服务器1，接收来自用户的容许设定要求，将其内容写入到图2的容许设定表24为止的全体动作予以说明。

如果用户将对自己的信息容许设定要求从终端发出，存在服务器1的各接口11-1～11-n就接收该发送消息。于是，首先将该消息传输到容许信息输入输出单元2，容许信息收发单元4接收该消息。之后，将消息发送到容许输入信息构筑转送单元5。在容许输入信息构筑转送单元5，从消息之中将容许设定要求的一部分抽出，在服务器内部以可以解释的形式构筑数据，并将构筑的用户设定要求转送到容许设定计算处理单元3的容许设定内容外部输入输出单元7。

容许设定内容外部输入输出单元7，将该要求转送到容许设定内容整合单元9，容许设定内容整合单元9对设定内容进行整合。此时，整合必要的信息是经容许信息内部输入输出单元8从图2所示的存储器22的信息上下关系设定表23中读出。另外，为了确认现在设定的容许及用户要求的容许设定的矛盾而取得整合性，从图2所示的容许设定表24读出现在的容许设定。如对容许进行整合，就从图2所示的容许设定对应描述表25中读出存放图8所示的容许信息之时的对应表，将容许信息变换为与图2的容许设定表24的描述形式相对应的形式。进行了整合、描述形式变换的容许设定转送到容许设定内容外部输入输出单元7。容许设定内容外部输入输出单元7，经图2的数据总线27将设定内容存储于存储器22上的容许设定表24中。存储结束时，将存储结束这一点经容许设定内容外部输入输出单元7发送到容许设定内容整合单元9，如接收到这个通知，就将表示容许设定成功这一点的消息经容许设定内容外部输入输出单元7发送到容许信息收发单元4，而容许信息收发单元4经接口11将容许设定成功发送给用户。

下面，对本实施例的存在服务器1，根据用户的要求，读出存储于存在服务器1中的容许信息向用户发送时的整体动作予以说明。首先，接收到来自用户的容许取得要求消息的接口11～11-n使该消息由容许信息收发单元4接收。容许信息收发单元4则将该信息转送到容许设定计算处理单元的容许设定外部输入输出单元7。而容许设定外部输入输出单元7将该内容发送到容许输出内容计算单元10。而容许输出内容计算单元10，为了从存储器22取得用户指定的容许信息，向容许设定内部输入输出单元8发出取得命令，而容许设定内部输入输出单元8则经图2的数据总线27调用存放于存储器22的容许设定表24中的指定的容许设定内容。此外，容许输出内容计算单元10经容许设定内部输入输出单元8从图2所示的容许设定对应描述表25取出信息，将存储器中记载的信息变换为供自己处理的容许信息。其后，容许输出内容计算单元进行计算以使该设定内容不会发生矛盾。此时用于计算的信息是从图2所示的存储器22的信息上下关系设定表23中读出。计算后，该内容经容许设定外部输入输出单元7转送到容许输出信息接收构筑单元6。容许输出信息接收构筑单元6由接收到的容许设定内容构筑用户客户可以解释的消息，经容许信息收发单元4将记载容许设定内容的消息从接口11发送。另外，管理台，是存在服务器的管理者用来设定容许设定对应描述表25及信息上下关系设定表23的装置。

在图3中，示出用来分类对象信息的层次结构模型。在本实施例中假设的层次模型中，用户ID31，位于层次模型的最上位的信息中。用户ID，只要是能够单值识别各用户的ID，是什么都可以，也可以将姓名和住所等组合使用来代替数值及代码。位于用户ID的下一层的下位中的是用户附带信息32。所谓用户附带信息，是表示，比如，各用户是否有手机，是否参加特定的服务等的信息。也可以说是表示用户是否具有要参加推定服务的意愿的信息。用户有时具有多个终端，也有完全没有的时候。就服务而言也同样。

位于用户附带信息的下一层的下位的是终端ID33-1～33-n及服务ID34-1～34-n。在本模型中，如果判别终端ID和服务ID，可考虑自动判别终端种别和服务种别，终端种别信息及服务种别信息，最好是与各ID信息分开置于更下一层的下位的位置。作为终端ID，比如，可使用电话号码及SIP(会话初始化协议)、URL等。另外，所谓服务ID，比如，是服务提供者对服务参加者分配的ID。不消说，所谓终端种别信息，是表示终端是，比如，PD33-n或手机33-1，或是PC等固定终端等的信息。所谓服务种别信息，比如，是表示用户参加的服务是IM服务34-1还是视频聊天服务34-n的信息。

位于在终端ID33-1～33-n及服务ID34-1～34-n的下一层的下位的是各终端及服务附带的各种信息35-1～35-n～38-1～38-n。所谓终端附带信息，比如，是每个终端的在线状态、占线状态、位置信息等，各种终端附带的各种信息。另外，所谓服务附带信息，是各服务提供者为开展服务所必需的信息，比如，如果是占星服务提供者，就相当于服务参加者的出生年月日及星座等信息。存在服务器1，将种种的对象信息依照图3的层次模型存储。

在图3中，示出的是四层的层次模型，也可以将结构进一步细分，作成更多层的结构存储对象信息。另外，将结构再简化，也可以将其作成三层或两层结构存储对象信息。实际上，很多场合也可以不考虑第二层的用户附带信息。这是因为很多时候没有终端的用户以及没参加服务的用户，不持有用户ID之故。但是，根据用户及服务提供者的方便，有时设置附带信息32的层次较好。比如，在用户临时停止享受服务，过了不久希望重新开始享受服务的场合，以及从服务提供者一方考虑，希望临时中断对用户提供服务的场合等(比如，用户不支付费用时)，可以原样照用以前的用户ID更方便。

图4为示出针对各对象信息设定的容许中存在上下关系时的示图。存在服务器1具有的容许信息的层次结构与对象信息的层次结构相同。存在服务器1，在图2所示的存储器22的信息上下关系设定表23中保持表示此层次结构模型的信息，在计算上述容许信息时随时调用图所示的容许设定内容整合单元9及容许输出内容计算单元10使用。如对比图3和图4，图4的第一个层次结构与图3的用户ID层相当。存在服务器1，将针对用户ID的容许41作为最上位的容许进行识别和存储。将对于在其下一层的下位的用户附带的各种信息的容许42、对于各服务ID的容许43、对于各终端ID的容许44、对于再下一层的下位的服务附带的各信息的容许45、对于终端附带的各信息的容许46进行存储。存在服务器1，只存储具有这一结构的容许设定信息、进行对象信息设定的用户和意欲阅览该信息的第三者(不仅服务提供者，也包含所谓的第三者)的组合的数目。

图5为示出利用本申请发明的存在服务器1处理的对象信息的容许设定的设定种别单位中的存储结构的示图。容许的设定值，根据某一对象信息打算在何种程度对第三者揭示的程度，取多个值。在本实施例中，可针对各对象信息41～46设定的容许的种别，为公开设定52、Read设定53及Write设定54三种。对于52～54的各种别设定许可56或拒绝57的值。

所谓公开设定52，是决定可不可以让阅览用户看到该信息的设定，如设定为像55-1那样的许可，就可以让阅览用户看到该信息，如设定为像56-1那样的拒绝，就不可让阅览用户看到该信息。进行拒绝设定的阅览用户不能知道该信息为公开用户所有。比如，如果对于用户ID41将公开设定52设定为拒绝，阅览用户不能知道公开用户的用户ID。就是说，该公开用户的存在对于第三者可以隐蔽。反过来说，在将对象信息的隐蔽功能附加到存在服务器的场合，对容许设定的设定种别必须设定称为公开设定的参数不可。

所谓Read设定53，是决定许可阅览用户读出该信息或拒绝的设定，如设定为像55-2那样的许可，就可以让阅览用户看到该信息，如设定为像56-2那样的拒绝，则当阅览用户要求阅读该信息时，就通知其拒绝公开。

所谓Write设定54，是决定许可阅览用户该信息的写入或拒绝写入的设定，如设定为像55-3那样的许可，阅览用户就可以进行该信息的登录或更新。就是说，公开用户所有的信息可由第三者代为更新。在各对象信息中，对一个信息可能有三个容许设定。另外，此三个设定采取层次结构。存在服务器，对于对象信息41～46，首先将最上位的设定变成公开设定52，将其下位变成为Read设定53，再将其下位设定为Write设定54这样来处理容许信息。另外，关于这三个设定的内容是有法则的。比如，在最下位的Write设定54为许可的场合，上位的Read设定53也为许可，并且最上位的公开设定52也为许可。另外，假如最上位的公开设定52为拒绝，下位的Read设定53、Write设定54同样成为拒绝。就是说，在上位设定为拒绝的场合，下位设定也据之设定为拒绝，并且如果下位的设定为许可，上位的设定也同样为许可。这是因为如信息可以阅览，当然也是公开的，如可以更新，当然是可以阅览的，也应该是公开的。因此，这三个设定就成为每个层次没有矛盾的设定。

另外，除了上述公开设定52、Read设定53、Write设定54之外，容许的设定种别，经图2的管理台，存在服务器的用户可自由地设定。比如，如果增加公开设定种别的数目，就可以设定更细分的揭示级，反之，在不需要隐蔽功能的场合，可删除公开设定这一参数。不管怎样，在本实施例中，通过将对象信息分类为多个，并且赋予上下关系进行管理，可以对对象信息进行适当的管理。这一信息也保持于如图2所示的存储器22的信息上下关系设定表23中，在上述容许信息的计算时，可随时从图1所示的容许设定内容整合单元9及容许输出内容计算单元10中调出利用。

图6、图7、图8是用来设定本申请的发明的存在服务器1实际存储的容许登录表的示例。存在服务器1，在各用户设定的容许信息存储于图2的24所示的那样的存储器区域的场合，存储于表61、71、81三个表中。下面说明，在存在服务器1，接收各用户发出的容许设定要求，存储其内容时的动作。另外，图6所示的表61、图7所示的表71存放于图2所示的存储器22的容许设定表24中。另外，图8所示的表81存放于图2所示的存储器22的容许设定对应描述表25中。

首先，从图6的61所示的表内部的公开用户名字段62中检索公开信息的用户的用户ID，读出与其相对应的索引63。此处，所谓公开用户62指的是公开对象信息的用户。简单说，也可以认为是基于对象信息的从服务提供者接受服务的用户。

图7为记录揭示对象信息的第三者和针对该对象信息的容许的设定值的登录表。图7的登录表，在图6所示的每个索引中都存在。比如，公开用户名为UserA的用户，具有以索引1识别的容许设定用的登录表。UserB具有索引2的登录表。UserC以下也一样。

存在服务器1，在71所示的索引表内，从与读出的索引号相对应的表检索阅览用户名字段，并将容许设定写入与其相对应的容许设定内容73。此处所谓的阅览用户名72指的是公开用户参照公开的对象信息，或是由公开用户的代理更新的用户或应用服务器。如检索阅览用户名字段的结果是未发现阅览用户名时，就作为新的容许的设定，在索引表71的各字段增加新的阅览用户名和容许设定内容。另外，在用户发出的设定要求是删除容许的场合，就从索引表71将指定的阅览用户名从阅览用户字段72删除，并且也将与其相对应的容许设定内容字段73删除。

另外，当存在服务器1从用户接收到容许设定的取得要求并读出其内容时也执行同样的动作，从容许设定内容73读出容许设定。并且，索引表71准备公开信息的用户部分。就是说，成为对每个用户具有索引表的形式。在此索引表71中，记载阅览用户72及与该阅览用户相对应的容许设定内容73。73的容许设定，比如，以64位二进制数串表示。在此二进制数的记述中，从前面算起每两位对各信息进行容许设定。此二位的值表示什么对象信息的容许见图8的表81。表81的编号82表示位串的编号，在与其相对应的设定对象用户信息83中记述对象的对象信息。比如，在表81中记述的信息中容许设定内容73的开始2位可读作与编号1相对应的用户ID的容许，其次2位可读作与编号2相对应的IM服务ID的容许。

在添加新公开用户的场合，在登录表61上添加公开用户名。此时，在索引字段63中记述的索引编号，由服务器把握空号自动进行设定。另外，此时准备新添加的公开用户用的索引表71。反之，在删除现在登录的公开用户的场合，首先消去要删除的用户的索引表71，其后，检索从登录表61的公开用户名字段62中削除的用户名，将其信息削除。

在图8中示出服务器在解释图7所示的容许的设定内容之际的参照用表。图8的参照用表81，有编号字段82和设定对象信息字段83构成。编号字段82是表示从容许设定内容73的前头算起的第几个2位的编号，设定对象信息字段83表示该2位记述的什么信息的容许。表81这样将容许设定内容73和表81组合就可以读出，或是写入，在哪一个信息中设定什么样的容许。在2位的二进制数中，可以设定以下的4种模式的容许：

1)公开设定52和Read设定53和Write设定54全部设定为拒绝、

2)公开设定52设定为许可、Read设定53和Write设定54设定为拒绝、

3)公开设定52和Read设定53设定为许可、Write设定54设定为拒绝、

4)全部的容许级设定为许可

比如，通过使上述1)的状态对应00、上述2)的状态对应01、上述3)的状态对应1、上述4)的状态对应11，就可能表现种种的容许级的设定值。另外，在本实施例中，作为容许级，假设了公开设定可否、Read可否、Write可否三种状态，但即使是将容许级更细分，设定级在4以上的场合，利用二进制数的位也可以表现各级的状态。比如，如果采用3位二进制数，就可以进行2³＝8种的容许设定。

在添加新对象信息的场合，在参照用表81中新添加著录项。通过添加著录项，可将对此前未利用的索引表71的容许设定内容字段73中示出的位串分配对象信息的容许设定。反之，在削除对象信息的场合，从参照用表81中削除著录项。著录项削除的位串，在容许设定，容许取得时不再参照，成为未使用的位串。

以上，在本实施例中，对容许的设定值，通过赋予可以表现上下关系的数值代码，可以进行考虑到容许级的上下关系的管理。

容许设定表，为了备份的目的，可以保存于外部的数据库等之中。在图9中，示出用于存放于外部存储手中的容许设定表的形式。表91由公开用户名字段92、阅览用户名字段93、及容许设定内容字段94构成，表61，记述与71同样的内容。关于表81的设定对象信息，比如，有将其在服务器的设定文件中备份保存的方法。

图10为在存在服务器1接收到用户发出的容许设定要求时，利用图1示出的容许设定内容整合单元9进行的处理的内容的流程图。容许设定内容整合单元9，是根据用户发出的容许设定要求的内容计算图4、图5所示的上下关系中没有矛盾的容许设定内容对设定内容进行整合的处理块。下面对此处理块予以说明。

容许设定内容整合单元9，如果在步骤101中接收到用户的容许设定要求，就在步骤102中从图2的程序存储单元26中取得成像信息，开始处理。处理开始后，首先在步骤103中，检验用户发出的容许设定要求与图4、图5所示的上下关系是否没有矛盾。假如发现矛盾时，就在步骤104中执行出错输出，在步骤119中结束处理，并在步骤120中将发给用户的表示容许设定失败的消息返送到图1所示的容许设定外部输入输出单元7。在无矛盾的场合，在步骤105中，首先进行容许设定。但是，在一次对多个对象信息要求容许设定的场合，首先对最先记述的设定进行处理。之后，在步骤106中，为了对按照设定要求进行设定的容许取得图5所示的在处理单位中的上下关系的整合性，从图2所示的信息上下关系设定表23中读出处理单位的信息上下关系表，检验在处理单位中的上位容许。比如，如果设定要求是对Write设定进行容许设定，就对Read设定进行检验。不过，因为设定要求是最上位的公开设定的可能性也存在，在步骤107中检验设定要求是否是处理单位的最上位。假如是最上位，就转入步骤111，如果不是最上位，就进入步骤108，比较检验中处理单位和上位的处理单位的设定内容。在步骤108中，假如上位的容许设定为拒绝，并且检验的容许设定为许可时，因为在图5的上下关系中有矛盾，就将上位的容许在步骤109中设定为许可。如无矛盾，就不进行这一处理。

之后，在步骤110中，将容许的检验对象向上位移动一个层次。比如，现在检验的是Write设定，在本步骤就将检验对象移动到Read设定。其后，再一次执行步骤106～，进行循环处理一直到最上位的公开设定为止。如果到达最上位检验结束，就在步骤107结束循环，处理进入步骤111。顺便指出，此步骤106～至步骤110为止的处理循环，虽然理解图5所示的处理单位的上下关系，但不能不执行，关于上下关系预先已经在存在服务器1的寄存器中设定。

在步骤111中，从图2所示的信息上下关系设定表23读出信息单位的信息上下关系表，再从图2所示的容许设定表24读出现在在设定的容许信息，将现在进行容许设定的对象信息的设定内容与其对上位的对象信息现在设定的容许的内容的矛盾进行整合。因为现在在进行容许设定的对象信息有可能是图4所示的信息单位层次的最上位的用户ID，首先在步骤111检验是否是信息单位的最上位。假如不是，在步骤113中对现在进行容许信息设定的对象信息和图4所示的上下关系图中的上位的对象信息的容许设定的Read设定进行比较。假如上位对象信息的Read设定是拒绝，而现在设定的对象信息的Read设定是许可的场合，则因为上位的对象信息拒绝阅览与下位的对象信息的许可阅览是处于矛盾状态，在步骤114中许可上位的对象信息的公开设定、Read设定。由此可对上下关系的矛盾进行整合。假如在步骤113中，不符合条件，则不进行步骤114的处理。

在此处理结束时，在步骤115中，将容许检验对象向现在的对象信息的的上位的对象信息移动一个层次，再次进行从步骤111起的处理，这一处理循环进行一直到容许检验对象移动到作为最上位的用户ID为止。如果容许检验对象移动到最上位，从步骤112进入步骤116的处理。顺便指出，此步骤111～至步骤115为止的处理循环，虽然理解图4所示的对象信息单位的上下关系，但不能不处理，该信息存储于图2的对象信息上下关系设定表23中。此设定，在存在服务器1的运用中，用户对关系可自由地设定。

如处理前进，在步骤116中检验全部设定是否结束。只有在用户发出的容许设定要求是针对多个对象信息的场合，处理进入步骤117，读入下一个要求，对该要求进行从步骤105起的处理。在全部设定要求结束时，处理从步骤116进入步骤118，对整合的容许的设定值进行写入到图2所示的存储器22的容许设定表24的处理，在步骤119中结束处理。其后，如接收到写入结束的通知，就在步骤120中将用来发给用户的表示容许设定成功的消息返送到图1所示的容许设定外部输入输出单元7。

图11为示出在存在服务器1接收到用户发出的容许取得要求时，利用图1所示的容许输出内容计算单元10进行处理的内容的流程图。容许输出内容计算单元10，是在从图1所示的容许设定外部输入输出单元7接收到用户发出的取得要求并从图2的容许设定表24读出容许设定之后，确认该设定在图4、图5所示的关系上有无矛盾，假如有矛盾，就计算容许设定内容，将计算后的容许设定内容返回用户的处理块。下面对此处理块予以说明。如果容许输出内容计算单元10，在步骤131中，从图1所示的容许设定外部输入输出单元7接收到用户发出的取得要求，就从图2所示的程序存储单元26读出处理内容，在步骤132中开始处理。处理开始后，首先在步骤133中，检验要求容许取得的用户是否可以取得要求目标的容许设定。假如没有取得权力，处理进入步骤134执行出错输出，在步骤149中结束处理，并在步骤150中将发给用户的通知没有取得权力的消息返送到图1所示的容许设定外部输入输出单元7。在步骤133中有权力的场合，处理就进入步骤135。在步骤135中，从容许设定表24读出容许设定。并且，为了计算上下关系的矛盾，从图2所示的信息上下关系设定表23读出图4所示的上下关系。之后进入步骤136，检验针对各对象信息在处理单位中的容许设定和图5所示的上下关系有无矛盾。此时，在必须对于针对多个对象信息的容许设定进行检验时，进行检验的次序是从图8的表81的编号82的次序，即图7的容许设定内容73的最初的2位起读出容许设定。在处理单位容许检验中，首先在步骤136中使进行检验的处理设定移动到最上位，即公开设定。之后，检验进入步骤1001的检验中的公开设定是否是最下位，因为第一次的循环是检验最上位的公开设定，不是最下位，按照原样使处理进到步骤137，检验公开设定是否是拒绝。假如是拒绝时，因为其下位，即Read设定、Write设定当然也是拒绝，就那样设定。假如是许可时，就使处理进到步骤138，使容许检验对象向下位移动一个层次。比如，现在检验中的处理设定是公开设定的话，就将容许检验对象向下位移动一个层次到Read设定。

其后使处理进入步骤1001再开始，是处理循环一直到移动到最下位的处理设定为止。假如处理成为了最下位，就使处理从步骤1001进入到步骤140。在步骤140中，检查是否对全部对象信息都已经结束检验，假如未结束，就使处理进入步骤141。在结束的场合，使处理进入到下一个步骤142。在步骤142中，检验在对象信息单位中在如图4所示的上下关系中是否存在矛盾。在此处理中，首先使在步骤143中进行检验的对象信息移动到用户ID。之后，在步骤1002中检验处于检验中的对象信息是否是最下位，因为现在的检验中对象信息是最上位的用户ID，就按着原样进入步骤144，检查检验中的容许设定的Read设定是否是拒绝。假如是拒绝，因为可以了解到对于下位的对象信息没有让看的意思，在步骤146中对全部的下位对象信息将全部处理设定的内容设定为拒绝。假如在步骤144中Read设定是许可时，就使处理进入到步骤145。在步骤145中，使容许检验对象在处理单位中向下位移动。但是，有时位于用户ID的下位的对象信息存在多个。此时，任意选择下位的对象信息并将容许检验对象移向该对象信息。此时对检验过的下位的对象信息进行存储。之后，再打开步骤144，使处理循环一直到检验到最下位的对象信息为止。

在最下位的对象信息的检验移动时，处理从步骤1002进到步骤147。在步骤147中，从存储的已经经过检验的下位对象信息中，调查是否图4的树结构的全部分枝都已经经过检验，假如不是全部分枝都已经经过检验时，处理进入到步骤148。在步骤148中，使容许检验对象向还未检验过的分枝的对象信息移动。其后，处理进入到步骤1002，使处理循环一直到对全部分枝的容许检验结束为止。在步骤147，如果对全部分枝检验容许检验都已经结束，处理进入到步骤149而结束。之后，在步骤150，将用来发给用户的表示经过检验的容许信息返送到图1所示的容许设定外部输入输出单元7。另外，容许输出内容计算单元10进行的图11的处理并非必需的处理。依靠容许设定内容整合单元9的处理，并且如果还有通过其他路径不将容许设定写入到容许设定表24的保障的话，也可以不执行图11所示的处理流程，而将从容许设定表24取得的容许设定按照原样发送给用户。但是，通过执行图11所示的处理流程，不想信息公开的用户的信息外流的可能性可以更降低。

下面利用图28至图30，对于针对用户要求的容许设定，图1所示的容许设定内容整合单元9是如何取得整合性，结果将何种容许设定保存于图2所示的容许设定表24中进行说明。

图28示出UserA现在登录到存在服务器1的对象信息。位于最上位的是UserA的用户ID3101，用户具有以3200表示的手机和PDA。于是，位于其下位的是作为手机的ID的电话号码3102，并且位于同列中的有作为PDA的ID的SIP-URI3105。此外，手机的下位有现在位置3103和与其同列的占线信息3104。另外，PDA的下位有接收通信状态3106和与其同列的忙3107。在存在服务器1中，就可以将UserA登录的对象信息以这种方式维持上下关系而得到保持。

另外，图29示出现在UserA对UserB进行了何种容许设定。从此图可知，现在UserA对UserB将用户ID3101设定成为3111那样公开许可、Read许可。以下从手机号码3102起到PDA通信状态3107止同样也设定为从3112起到3117止那样的容许。

此时，假如存在服务器1接到想要将UserA对UserB的手机的位置信息3102设定为Read许可。于是，首先，容许设定内容整合单元9从图2所示的信息上下关系设定表23中读出图5所示的上下关系。于是，从容许设定要求的处理是Read处理出发，可把握其上位处理中有公开设定。并且，因为用户要求的设定为Read许可，可判断出其上位的公开设定也是许可。

此外，为了从对象间的上下关系整合容许设定，从图2所示的信息上下关系设定表23中读出图28所示的上下关系信息。于是，对容许设定要求的手机的位置信息3103，作为上位对象可以把握手机的电话号码3102以及用户ID3101的存在。另外，从图2所示的容许设定表24读出图29所示的现在设定的容许信息。因为用户发出的容许设定要求中是要将手机的位置信息变为Read许可，而其上位的手机的电话号码3102的公开设定、Read设定为图29的3112中所示的公开拒绝、Read拒绝，要变更为公开许可、Read许可。并且，对上位的用户ID3101进行确认，如3111所示，因为原来的设定为公开许可、Read许可，所以原样保留。手机的占线信息3104、PDA的SIP-URI3105、PDA的忙3106、PDA的通信状态3107，从图28所示的上下关系图可知，是处于与用户要求的容许设定的手机的位置信息无关的位置的信息，设定前的内容不改写。

结果，在用户发出设定要求后，在图2所示的存储器22的容许设定表24中登录的容许信息成为图30所示的内容。

从图30可知，UserA只要求将手机的位置信息容许改变为Read许可，但经过图1所示的容许设定内容整合单元9的处理，如3213所示，手机的位置信息登录为公开许可的容许，并且如3212所示，手机的电话号码登录为公开许可、Read许可的容许。

图12为利用本实施例的存在服务器服务模型的一例。在图12中，以254表示的UserA是将信息登录到存在服务器1，从家族信息通知服务器152接受服务的用户。此服务，是由家族信息通知服务器把握UserA及其家族的现在信息，比如，如果UserA及其家族持有的图16的位置信息216互相靠近的话，从家族信息通知服务器发出的通知警报的服务。在此图12中，是以存在服务器为通信公司所有，家族信息通知服务器152及信息配送服务器153为服务提供者所有为前提说明的，也有通信公司保有家族信息通知服务器152及信息配送服务器153，进行本服务作为事业的情况。

下面对服务模型整体的动作予以说明。首先154示出的UserA将自己的信息及自己的信息公开设定登录到存在服务器1，向家族信息通知服务器152提出服务要求，经信息配送服务器153接受服务。作为本服务模型的其他应用例，可以有登录家族成员现今想要的物品，将其通知在出售该物品的商店附近的其他家族等的应用。

在图14中示出其具体动作的次序。下面对其动作予以说明。154所示的UserA首先在步骤171中向家族信息通知服务器152发送服务登录要求。于是，家族信息通知服务器152，在步骤172中，向154所示的UserA查询可以公开的信息。在154中示出的UserA对此在步骤173中自己将可以公开的信息登录到家族信息通知服务器152。另外，从步骤171起到173止的处理不经过存在服务器进行的时候很多。另外，与此同时，在步骤174中，也将容许设定登录到存在服务器1。存在服务器1，将以4表示的UserA登录的信息公开设定在步骤175中保存到服务器内部。另外，家族信息通知服务器152，由于接收到以4表示的UserA的信息更新及更新的信息的内容的通知，在步骤176中对存在服务器1进行UserA的信息更新通知预约。之后，以4表示的UserA在步骤177中将自己的信息更新登录到存在服务器1。因为存在服务器1，在步骤176中从家族信息通知服务器152接收到UserA的信息更新通知预约并享有，就对家族信息通知服务器152进行更新通知。此时，存在服务器1首先在步骤178中对以4表示的UserA对家族信息通知服务器152设定的容许设定予以确认。之后，只将确认在容许设定中Read设定是许可的信息在步骤179中通知家族信息通知服务器152。此时，通知方法有只将更新的信息通知的方法和将以4表示的UserA持有的包含未更新的信息的全部通知的方法两种，但使用哪一种方法都可以。

图16示出以4表示的UserA持有的信息和通知家族信息通知服务器152的信息的一例。在图16中，以154表示的UserA保有用户ID212、UserA保持的终端1的ID213、UserA保持的第二台终端2的ID214、还有终端2附带的信息On/Off215以及位置216。不过，对家族信息通知服务器152，只能看到以4表示的UserA的用户信息212、214、215、216。这是因为UserA，在容许设定表24上对家族信息通知服务器152登录的终端1的ID213的公开设定是拒绝，存在服务器1的管理单元3未通知终端1的ID213之故。另外，在信息更新通知方法是只通知更新的信息的方法时，该更新的信息对以154表示的UserA的家族信息通知服务器152的容许设定的公开设定或Read设定为拒绝时，不进行步骤179的信息更新通知。通过以154表示的UserA在存在服务器上登录自己的信息，存在服务器1利用容许设定计算处理单元3对信息进行过滤，就可以对图16所示的家族信息通知服务器152进行信息配送。

家族信息通知服务器152，在步骤179中，取得以4表示的UserA的更新的信息，在步骤180中对更新的信息，并且包含其他未更新的信息，进行确认，进行服务提供判断，进行其内容的判断。之后，家族信息通知服务器152，在决定服务配送后，在步骤181中向信息配送服务器153发送服务的配送要求。之后，信息配送服务器153，在步骤182中，针对对方的终端设定符合动画及静止画面、文字等的配送媒体以及UserA的通信带宽的位速率，在步骤183中对UserA进行配送服务。不过，如果家族信息通知服务器152，确认在步骤180中更新取得的UserA的信息并决定不进行配送服务时，不进行步骤181～183的处理，等待下一个UserA的信息更新通知。另外，在此次序中，也有家族信息通知服务器152具有信息配送服务器153的功能的情况。此时，也有不进行步骤181的处理，而步骤182、183中的处理由家族信息通知服务器152执行的场合。

图14是利用SIP(会话初始化协议)/SIMPLE(SIP for InstantMessaging and Presence LeveragingExtensions)实现图12的实施例的示例。所谓SIP/SIMPLE是提供实时通信的会话确立和存在信息的更新通知预约及对其进行更新通知、IM等、多媒体通信所必需的功能的协议。图14的SIP服务器161具有给基于SIP/SIMPLE的消息进行路由选择传输到目的对象的功能。

图15是利用SIP/SIMPLE实现图14的次序的应用例。在图15中，除了SIP/SIMPLE，还利用HTTP实现服务。在本次序中，藉助利用HTTP的191、192、193实现服务登录要求171、公开信息查询172、公报公开设定登录173。迄今为止的处理是经存在服务器1进行的。另外，容许设定174是藉助使用SIMPLE的MESSAGE顺序(method)发送194经SIP服务器161中继实现的。所谓顺序是SIP/SIMPLE消息的最前头的部分中记述的字符串，通过多该字符串的确认，可以判断该SIP/SIMPLE消息是发送到哪一目的的。顺便指出，MESSAGE顺序本来是发送正文库IM的发言内容的顺序，在本申请发明的装置中扩展到容许设定要求、取得要求。另外，UserA的UserA的信息变更通知预约176是利用SIMPLE的SUBSCRIBE消息发送196经SIP服务器中继实现的。下一个信息更新177是利用REGISTER消息发送197经SIP服务器161中继实现的。REGISTER顺序本来是用户进行在线登录的方法，在本申请发明的装置中对其进行扩展而成为可以利用此顺序进行用户信息登录。

之后的UserA的信息变更通知179是利用NOTIFY消息发送199由SIP服务器161中继实现的。NOTIFY消息，是用来对这样利用SUBSCRIBE享有的用户信息更新通知预约通知信息更新的顺序。对于其后的服务配送183，在实时性高的动画及语音的配送时，利用SIP，在发送INVITE消息之后，在UserA154和信息配送服务器153之间，在会话打开以后利用RTP协议，传输服务。像静止画面及正文库这样的实时性低的配送的场合，是利用SIMPLE的MESSAGE顺序，以直接发送文字信息的方法实现的。无论采取哪一种方法，都是以SIP服务器161作为中继传输SIP消息。

另外，广角本实施例的存在服务器，不仅容许信息，包含逻辑上的上下关系的一切信息组，都可以进行适当的管理。

[实施例2]

图17示出采用存在服务器的商业模型的第二实施例。在图17中以224表示的UserA，在日常购物时利用○×商店的时候很多。在○×商店购入历史累积服务器221中累积有UserA的商品购入历史。另外，UserA，在存在服务器1上登录有图21所示的用户ID272、作为用户附带信息的兴趣273、年收入274、终端的ID276、作为终端的附带信息的On/Off277、位置278，是从店铺信息配送服务器222接受服务的用户。对全体动作不予说明，UserA224将自己的用户信息和对店铺信息配送服务器222的容许设定登录于存在服务器1上。另外，向店铺信息配送服务器222提出服务提供要求，经信息配送服务器223接受服务。

图10是其动作次序。下面利用此次序对对具体的动作予以说明。以224表示的UserA首先在步骤231中在○×商店购入历史累积服务器221上登录自己的信息。此所谓的信息登录，表示的不是以网络上的消息登录的信息，而是以224表示的UserA在○×商店进行购物的结果，在以221表示的○×商店的购入历史累积服务器上累积UserA的购入历史。所以，从在图17、图18中以224表示的UserA起到以221表示的○×商店止的箭头也不是表示网络上的消息，而是表示由于以这种方式进行物理上的购物的信息累积。○×商店购入历史累积服务器221，在步骤234中将其历史登录到存在服务器。UserA利用步骤233向店铺信息配送服务器222发送服务登录要求。于是，店铺信息配送服务器222，通过步骤234向UserA咨询可能公开的信息。对此UserA在步骤235中自己将可以公开的信息登录到店铺信息配送服务器222。从步骤233起到235止的处理，不经过存在服务器的很多。另外，与此同时，在步骤236中，对店铺信息配送服务器222的容许设定也登录到存在服务器1上。

存在服务器1，将UserA登录的容许设定在步骤237中保存到内部。另外，店铺信息配送服务器222，由于接收到UserA的信息更新的内容的通知，在步骤238中对存在服务器1进行UserA的信息更新通知预约。之后，UserA在步骤239中将自己的信息更新登录到应用服务器1。因为存在服务器1，在步骤238中从店铺信息配送服务器222接收到UserA的信息更新通知预约并享有，UserA就在步骤240中在对店铺信息配送服务器222设定的容许确认后，只将确认在容许设定中Read设定是许可的信息在步骤241中通知店铺信息配送服务器222。此时，通知方法有只将更新的信息通知的方法和将以4表示的UserA持有的包含未更新的信息的全部通知的方法两种，但使用哪一种方法都可以。

图21示出UserA在存在服务器1及○×商店购入历史累积服务器221上登录、更新信息和店铺信息配送服务器222接收的关于UserA的信息的一例。在图21中，UserA保有用户ID 272、作为UserA的附带信息兴趣273、年收入274、○×商店购入历史275、UserA保持的终端1的ID276、作为终端的附带信息的On/Off277、位置278。不过，店铺信息配送服务器222接收到关于UserA的年收入信息是拒绝公开281。这是因为UserA将对店铺信息配送服务器222登录的年收入的Read设定的拒绝的容许信息登录到存在服务器1之故。另外，在信息更新通知方法是只通知更新的信息的方法时，该更新的信息对店铺信息配送服务器222的容许设定为公开设定或Read设定为拒绝时，不进行步骤241的信息更新通知。

店铺信息配送服务器222，在步骤241中，取得UserA的更新的信息，在步骤242中对更新的信息，并且包含其他未更新的信息，进行确认，进行服务提供判断，进行其内容的判断。之后，店铺信息配送服务器，在决定服务配送后，在步骤243中向信息配送服务器223发送服务的配送要求。之后，信息配送服务器223，在步骤244中，针对对方的终端设定符合动画及静止画面、文字等的配送媒体以及UserA的通信带宽的位速率，在步骤245中对UserA，比如，靠近UserA的现在位置的商店信息及该商店的服务优惠券等的配送服务。此时，如果店铺信息配送服务器222，确认在步骤241中更新取得的UserA的信息并决定不进行配送服务时，不进行步骤243～245的处理，等待下一个UserA的信息更新通知。另外，在此次序中，也有店铺信息配送服务器222具有信息配送服务器223的功能的情况。此时，也有不进行步骤243的处理，而步骤244、245中的处理由店铺信息配送服务器222执行的场合。

图18是利用SIP(会话初始化协议)/SIMPLE(SIP for InstantMessaging and Presence LeveragingExtensions)实现图17的实施例的示例。另外，图20是利用SIP/SIMPLE和HTTP实现图19的次序的示例。下面利用图20对图18的具体动作予以说明。在图19中，利用Register(UserA的购入历史登录)252经SIP服务器161中继实现UserA的购入历史登录232。之后，针对服务登录要求233、公开信息查询234、公开信息登录235，在253、254、255的步骤中，利用HTTP实现。另外，容许设定登录236，在Message消息发送256中经SIP服务器161中继实现。下一个UserA的UserA的信息变更通知预约238是在258SUBSCRIBE消息发送258中经SIP服务器161中继实现。用户信息更新239与232一样是利用REGISTER消息发送259经SIP服务器中继实现的。信息更新通知241是利用NOTIFY消息发送261由SIP服务器161中继实现的。另外，作为最后的步骤的服务配送245，在步骤265中，在动画等实时性高的媒体的配送时，在发送INVITE消息之后，在会话打开以后利用RTP协议，传输服务。像静止画面及正文库这样的实时性低的配送的场合，是利用MESSAGE顺序发送实现的。无论采取哪一种方法，都是以SIP服务器161作为中继转送SIP消息。

[实施例3]

图22示出利用存在服务器的商业模型的实施例3。UserA301，在存在服务器1上登录有图25所示的用户ID312、作为用户附带信息的兴趣313、年收入314、UserA所有的终端1的ID315、作为终端1的附带信息的On/Off316、位置317。另外，UserB302是进行UserA的信息更新通知的预约、把握UserA的现在状态的用户。图24是此实施例的动作次序图。下面利用图24对此实施例的具体的动作予以说明。首先，UserA在步骤321中，将兴趣313登录到存在服务器1。因为设定的是假设存在服务器1将兴趣313保存在数据库服务器A303-1中，在步骤322中将其登录到数据库服务器A303-1中。

之后UserA在步骤323中将终端1附带的位置316登录到存在服务器1。因为设定的是存在服务器1将位置316保存于数据库服务器B303-2中，所以在步骤324中，将UserA的位置316登录到数据库服务器B303-2中。之后，UserA在步骤325中，将对UserB的设定登录到存在服务器1。于是，存在服务器1，在步骤326中，存储UserA对UserB的容许设定。之后，UserB，为了解UserA的信息更新，对存在服务器1，在步骤327中，发送UserA的信息更新预约通知。于是，存在服务器1，在步骤328中，首先确认UserA对UserB设定的容许，只将Read设定为许可的用户信息通知UserB。因此，存在服务器1只将Read为许可的信息在步骤329和330中从数据库服务器A303-1和数据库服务器B303-2中读出(UserA的用户信息)并在步骤331中通知UserB。此时，假如用户的公开设定或Read设定为拒绝时，因为没有可以通知的用户信息，在步骤331中返回无权的消息并且此动作次序结束。之后，如果UserA，在步骤332中，比如，更新位置信息和兴趣，存在服务器1在步骤333、334中将各自的用户信息保存于数据库服务器A303-1和数据库服务器B303-2中，并且，在步骤335中UserA将对UserB设定的容许信息进行确认并将Read设定是许可的用户信息在步骤336中通知UserB。

观察图25的302可知，通知UserB的UserA的信息内，用户附带的年收入351、终端1附带的位置352拒绝公开。这是由于UserA对UserB的年收入和位置的Read设定为将拒绝的容许设定登录到容许设定表24，存在服务器1的容许控制单元3判断公开拒绝通知之故。

另外，图23是以SIP/SIMPLE实现图22的实施例的示例。在两个图面中，从存在服务器1到数据库服务器A303-1、数据库服务器B303-2之间的接口是同样的，在图23中，从UserA301到存在服务器1、从UserB302到存在服务器1的接口是利用SIP/SIMPLE的REGISTER、SUBSCRIBE、NOTIFY、MESSAGE顺序的消息由SIP服务器161进行中继的形式。

[实施例5]

在实施例4中对存在服务器的另一种构成例予以说明。图26示出的是与图2结构不同的存在服务器的模式图。本实施例的存在服务器，使用的是将公开用户名、阅览用户名和容许设定值汇总的容许登录表。就是说，使用与图9所示的登录表相同的登录表。本方式的登录表，由于将公开用户名字段、阅览用户名字段以及容许设定值字段汇总为一个容许登录表，与图6、图7那样的将登录表分开的情况相比较，具有从容许的设定内容检索用户名的逆引易于进行的优点。

但是，由于登录表的数据长度变大，如图2所示的实施例，将全部数据存放于存储器中是不可能的，通常存放于外部存储装置2002中，只将必需的部分在存储器空间上展开，进行容许设定处理。2001是盘接口，与外部存储装置2002及存在服务器主体相连接。另外，用来解释容许设定内容的参照用表(与图8相同的表)，在本实施例中，也是必需的，因此，本实施例的存在服务器具有用来存放参照用存储器的高速缓存2003。

[实施例5]

在实施例5中，对实际的利用情况下的容许变更步骤及其所取得的效果予以说明。在图31中假设UserA和UserB是同事。另外，UserA具有以4001表示的PDA的终端1和以4002表示的终端2，经SIP服务器161将存在信息以及容许信息登录到存在服务器1。在图31中的是经SIP服务器161访问存在服务器1的模型，如图32所示，也可以考虑不经过SIP服务器161而直接与服务器1进行通信的形态。此时，存在服务器1，具有SIP的会话控制功能，或是UserA和UserB之间的通信是不用SIP的形态的任何一种。比如，HTTP及Instant Messaging等。

下面利用图33所示的次序图对在图31中示出的网络图中收发何种消息予以说明。下面对在此网络上，利用以IETF标准化的Request ForComment(RFC)表示的SIP消息进行通信的情况进行说明。如上所述，除了SIP以外，也可以藉助利用HTTP及Instant Messaging的协议等实现本次序。

首先，UserB，为确认UserA的状态，使用自有终端4003，在步骤4011中，向存在服务器1发送SUBSCRIBE消息。另外，所谓SUBSCRIBE，是表示由SIP规定的消息种别的称为顺序的方法，SUBSCRIBE是在IETF Request For Comment(RFC)3265中对利用方法进行规定的。之后，接收SUBSCRIBE消息的存在服务器1，将表示该SUBSCRIBE成功的200 OK响应在步骤4012中发送给UserB，接着，为了通知UserA的存在信息即对象信息，在步骤4013中，将NOTIFY消息发送给UserB。NOTIFY消息，也与SUBSCRIBE一样，是由RFC3265规定的顺序，是用来在消息内部记述对象信息的顺序。在此顺序中，发送UserA所有的终端1(4001)、终端2(4002)两者的对象信息。

在图34中，将根据容许设定，从UserA向UserB揭示的对象信息与UserA持有的全部对象信息相对比示出。在4030～4036中示出的各项目，是UserA持有的对象信息。实际上，UserA持有的对象信息，登录到存在服务器1内。容许的设定信息，保持于存在服务器内的容许管理单元中。另一方面，在图2所示的结构的存在服务器的场合，容许的设定信息，存放于存储器内的容许设定表中。

另外，在图36中，在步骤4013的NOTIFY消息表示在到达UserB的时刻UserA对UserB设定的容许。根据图36，针对UserB，对UserA保持的所有的对象信息容许设定为公开许可。因此，图34所示的4030～4036全部的对象信息按照原样通知UserB。

下面对图33的次序图的后半部分予以说明。如果UserA要在4014中变更终端1(4001)的对象信息，存在服务器1就在步骤4015中将UserA的对象信息的改变利用NOTIFY消息通知UserB。这是因为在步骤4011中发送的SUBSCRIBE消息具有一定时间的有效期限，在有效期限内每次UserA的对象信息变更时存在服务器1都将其变更内容通知UserB之故。步骤4016、4017是终端2(4002)变更对象信息时的次序，其步骤与步骤4014、4015一样。

之后，假设UserA结束办公时间汇入归家人群。UserA和UserB是公司的同事，但不能说是密友。UserA考虑在工作时间以外的私人时间内，认为也可以让UserB看到的信息仅仅是邮件地址，希望业务联系通过电子邮件进行。当然，可访问状态信息、位置信息及占线信息不想让人看到。此外，也不想利用手机呼出。于是在回家时，UserA对UserB的容许设定改变。具体言之，从UserA所有的终端向存在服务器1发送容许设定变更要求的消息(步骤4018)而变更存放于存在服务器1中的容许设定。其内容为要求将手机的容许变为拒绝公开以及要求将PDA终端的可访问状态变为Read拒绝。接收到容许设定要求的存在服务器1，在步骤4019中取得容许设定的整合性并进行登录。在图37中，示出步骤4019的容许设定登录的结果登录的容许设定。因为在UserA发出的设定变更要求中包含将手机的容许变为非公开的要求，所以手机电话号码公开设定变为拒绝，并且其下位的Read设定也由存在服务器1整合而自动设定为拒绝。

在图35中，示出根据变更后的设定向UserB揭示的UserA的对象信息。在终端1的信息中，对UserB公开的信息只有终端1的ID4031和邮件地址4033，可访问状态4032变为非公开。另外，关于终端2的对象信息全部未揭示。

图38为示出图31所示的服务中使用的对象信息的上下关系的示图。由图38的上下关系图手机的位置信息、占线信息也由存在服务器1整合，自动地设定为拒绝公开和Read拒绝。另外，因为PDA的可访问状态可由图38了解到是最下位的对象，与其以外的容许设定的整合性可得到确认，而不能自动变更容许设定。

UserA在容许设定变更之后，存在服务器1立即在步骤4020中向UserB的终端4003以NOTIFY消息发送由容许设定许可的对象信息，即只有邮件地址信息。其后，存在服务器1，也更新UserA的存在，这一点在容许为不使UserB了解时，不向UserB发送状态变更通知。比如，即使是UserA在步骤4021中变更手机的存在，也不向UserB发送该变更通知。但是，在像步骤4022那样将公开的对象信息更新的场合，就像步骤4023那样以NOTIFY消息发送对象信息。

[实施例6]

图39～图41是用来说明在图33的步骤4018中实际上是如何发送容许设定要求的示图。实际上，要求容许设定的消息是由利用如图39的4220所示的那样的SIP协议和IP的包(分组)构成的。4221是示出IP包的IP地址的部分，IP协议，是由IPv4或IPv6记述IPv4地址或IPv6地址。4222记述传输层，传输层，不管使用TCP/UDP哪一个，都记述发送源的端口号、发送目的的端口号。实际记述SIP协议的数据的部分是由4223表示的有效载荷部分。关于这一部分更详细的记述部分是4224～4226。SIP消息是由记述消息种别的SIP的要求行4224、记述消息的设定的SIP头4225、记述实际数据的SIP消息正文4226构成的。在本实施例中中，如图40所示，采用由IETF Request For Comment(RFC)3428规定的Instant Messaging用的顺序的MESSAGE顺序发送设定要求。另外，在取得容许设定时，也同样使用MESSAGE顺序。在使用MESSAGE顺序的SIP消息中，采用如图41所示的eXchange Markup Language(XML)记述对存在服务器1的要求。容许设定、取得要求，在SIP消息正文中也可以利用XML以外的记述形式或是XML但是不同的模式(文法)记述。此时，在图40的4232所示的Content-type头中记述SIP消息正文。另外，在4233中示出的Content-Length头中记述以字节为单位的SIP消息正文的容量。关于上述头，在IETF Request For Comment(RFC)3261中有关于利用方法的记述。

下面对图41所示的SIP消息正文部分的XML模式予以说明。图41的XML主要由4301表示的acl元素、4302表示的object-def元素、4303表示的flag元素、4304表示的subject元素构成的。在acl元素中记述进行容许设定的用户的SIP-URI、在object-def元素中记述要设定的容许的种别、在flag元素中记述要设定的容许的操作内容、在subject元素中记述成为设定对象的对方SIP URI和设定内容。实际记述的设定内容为如4305所示的形式。此记述是并列的位串。此位串从左起记述由object-def元素定义的对象顺序排列的设定内容，对于1个对象，由flag元素记述的操作部分的位给出的各个操作的设定为0表示拒绝，1表示许可。比如，可以看到图41中的设定为000 100。可知其中作为第一个对象的手机的设定的记述000表示公开＝拒绝、read＝拒绝、write＝拒绝。另外，可知作为第二个对象的PDA的设定的记述的可访问状态为100，即公开＝许可、read＝拒绝、write＝拒绝。另外，在本实施例中，是以flag元素定义write操作，但flag元素可以只对要设定的操作的记述进行，比如，只对read操作进行容许设定的场合，flag元素可以只对read操作部分进行。

以这种消息的接收为触发工具，存在服务器1可以进行容许设定的整合性调查、设定内容补全和登录。

Claims

1.一种服务器，具有用于存储用户的终端信息以及该终端的可否通信信息的存储单元，其特征在于，

上述存储单元还存储该终端信息与该终端的可否通信信息之间的从属关系、和该终端信息以及该终端的可否通信信息各自的可否公开的设定值，

在上述从属关系中，上述终端的可否通信信息为上位，上述终端信息为下位，

上述终端的可否通信信息的上述设定值从不可公开变更为可公开的情况下，将上述终端信息的上述设定值变更为可公开，

上述终端信息的上述设定值从可公开变更为不可公开的情况下，将上述终端的可否通信信息的上述设定值变更为不可公开。

2.如权利要求1所述的服务器，其特征在于，将上述可否公开的设定值分成针对上述用户终端的通信对方的上述终端信息的公开可否、针对上述用户终端的通信对方的上述终端信息的读出可否、针对上述用户终端的通信对方的上述终端信息的写入可否这三种类型来进行管理。

3.如权利要求2所述的服务器，其特征在于，

使上述三种设定值具有从属关系地进行管理，

上述公开可否是比上述读出可否上位的设定值，

上述读出可否是比上述写入可否上位的设定值，

当上述设定值中的下位的设定值从否变更为可的情况下，将比该下位的设定值上位的设定值变更为可，

当上述设定值中的上位的设定值从可变更为否的情况下，将比该上位的设定值下位的设定值变更为否。