专利名称：状态信息管理系统和状态信息管理服务器的制作方法
技术领域：
本发明涉及一种信息公开的设定方式。
背景技术：
近年来，盛行开发利用称为“呈现(presence)”概念的用户间状态把握技术。所谓“呈现”如其名称所示，是用于通知其它用户的各用户的“存在”，具体而言，是表示各用户的当前位置或当前状态等各种自己的存在之信息。通过向其它用户实时通知该“呈现”，可把握彼此的当前状态。这些呈现的概念与通信技术从IM(Instant Messaging)技术得到发展。就IM、和呈现的概念而言，以IETF(Internet Engineering Task Force)的impp(InstantMessaging and Presence Protocol)工作组为中心，进行标准化(参照非专利文献1、2)。另外，就具体的呈现通信技术而言，根据impp规定的概念，由各种IETF工作组来进行议论、标准化。用图15来说明呈现通信技术的概要。这里，使用作为呈现的代表通信技术之一的、采用由IETF(InternetEnginneering Task Force)的SIMPLE(Sip for Intstant Messaging andPresence Leveraging Extensions)工作组进行标准化的SIP(SessionInitiation Protocol)之呈现通信技术来说明概要。
图15表示182所示的UserA终端、183所示的UserB终端、184所示的UserC终端发送接收彼此的呈现信息的状态。
例如，在182所示的UserA按185所示的形式想要知道UserB、UserC的呈现信息的情况下，UserA把握UserB、UserC的ID(在SIP中为SIP-URI)，UserA指定UserB、UserC的SIP-URI，将期望接收呈现的通知(下面将该动作称为预订(subscribe))的SIP消息SUBSCRIBE消息发送给带呈现发送功能的服务器181。接收到该消息的带呈现发送功能的服务器181使用SIP的NOTIFY消息，将对应的SIP-URI呈现信息、即UserB和UserC的呈现信息通知给UserA。之后，只要从UserA至UserB、UserC的预订有效，则每当UserB、UserC对带呈现发送功能的服务器181更新自己的呈现信息，则对UserA使用NOTIFY消息进行更新通知。就这些使用S IP的基本呈现信息通信的规定而言，在非专利文献3和非专利文献4中有其详细内容的记述。另外，另一通信方法中有指定组的统一呈现信息取得。例如，将185所示的朋友列表认为是一个组，向该组分配188所示的各种组ID，保持于带呈现发送功能的服务器181中。在182所示的UserA想知道UserB、UserC的呈现信息的情况下，不必指定UserB和UserC的SIP-URI，并单独发送希望呈现信息的通知之SUBSCRIBE消息，而是发送指定包含UserB与UserC作为组的组ID188之SUBSCRIBE消息，并统一取得作为该组成员的UserB与UserC的呈现信息。在IETF的SIMPLE工作组中，将如此指定组后统一取得其成员的呈现信息之方法称为‘事件列表预订’，在非专利文献5中规定该方法。
在本例中，用SIP对呈现信息的通信技术说明概要，但就基本概念而言，即便使用其它的通信技术也一样。基本模式如下，即想阅览他人呈现信息的用户指定构成呈现阅览对象的用户之用户ID、或对象用户所属的组ID，向具有181所示的呈现信息之发送接收功能的服务器发送期望呈现信息通知的消息，取得期望的对方之呈现信息。
非专利文献1RFC 2778非专利文献2RFC 2779非专利文献3RFC 3265非专利文献4RFC 3856非专利文献5IETF Internet Draftdraft-Ietf-simple-event-list-06.txt无论利用背景技术中所述的指定用户ID的预订方法、指定组ID用统一取得所属用户的呈现信息之预订方法哪个，进行预订的用户都必需明示地指定预订对象的ID(对方用户或组)，并发送期望呈现信息通知的预订消息。在该方法中，自己必需事先把握想预订的对方用户的ID或组ID。在想暂时参照呈现的情况下，当考虑短时间使预订对象变化这样的呈现信息通信模式时，由于把握对方的ID或组ID的负担，难以由本方式下的预订实现。例如，首先想暂时知道在出席的会议中最初与会的会议成员之呈现信息的情况，虽然不知道参加中的会议室名称(即组ID)，但想知道位于该场所的用户状态的情况，自己想知道当前暂时在座的周围人的呈现信息的情况。在这种状态下，每次听到对方的ID，调查当前自己暂时所属的组ID导致用户能力下降。
发明内容
不指定对方的ID或组ID来发送预订消息，而指定构成条件对象的呈现信息的某个项目与针对该项目的条件来进行。例如，某个用户将“当前位置”的呈现信息“相同”的情况作为条件来进行预订。此时，在进行预订的用户之“当前位置”呈现信息为“201会议室”的情况下，向相同的“当前位置”呈现为“201会议室”的其它用户自动进行预订，接受呈现信息的通知。之后，若进行预订的用户之“当前位置”呈现信息变化为“502实验室”，则当“当前位置”为“201会议室”时，自动解除对阅览呈现信息的成员之预订，自动开始对“当前位置”为“502实验室”的成员的预订。另外，被预订侧的用户对来自其它用户的预订设定是否公开呈现信息、或公开至哪里等，进行保护，以不让其它用户知道超出所需的呈现信息。
发明效果各用户在进行预订时，不必明示地指定对方用户或组的ID。由此，由于消除了输入预订对象ID的手续，所以用户能力提高。另外，由于构成预订对象的用户对应于自己的呈现信息变化而自动变化，所以当使预订对象变化时，削减消息数量。
图1是适用本发明的带条件预订方式的呈现服务器之功能框图。
图2是适用本发明的带条件预订方式的呈现服务器之装置图。
图3是本发明装置的动作概要图。
图4是表示使用本发明装置的连接形式的网络图。
图5是使用本发明装置的连接形式的动作序列图。
图6是用户对本发明装置发送的呈现信息请求时的SIP消息。
图7是本发明装置对用户发送的呈现信息通知时的SIP消息。
图8是本发明装置对用户发送的呈现信息通知时的SIP消息。
图9是本发明装置存储的带条件预订管理用表格图。
图10是本发明装置存储的预订对象管理用表格图。
图11是本发明装置存储的预订条件模板用表格图。
图12是本发明装置存储的允许设定用表格图。
图13是本发明装置存储的允许设定用表格图。
图14是本发明装置存储的允许设定用表格图。
图15是现有技术利用时的网络图。
图16是本发明装置的流程图。
图17是本发明装置的流程图。
图18是本发明装置的流程图。
图19是本发明装置的流程图。
图20是本发明装置的流程图。
图21是本发明的第2动作原理图。
图22是本发明的第3动作原理图。
图23是呈现信息内容间的关系图。
图24是本发明的第4服务示意图。
图25是本发明的第4动作原理图。
符号说明1 呈现服务器2 允许信息控制部3 允许管理部实施例1在本实施例中，首先说明发送接收呈现信息的服务器的逻辑构造、物理构造、动作概要及实现使用该服务器的服务之网络概要。之后，使用服务器内部保持的数据例、流程图例来说明本发明装置的处理。
图1中示出本实施例的发送接收呈现信息的服务器的功能框图。图1的功能框图是表示软件上实现的逻辑功能构成的图，但即便由硬件来构成各功能块也无妨。
图2中示出图1所示的功能块如何在硬件上实现。图1所示的各种功能块的动作被容纳于图2所示的存储器22的处理模块群26中，动作时，CPU23读出该动作步骤并执行。将各个处理模块动作时所需的信息存储在数据库31和存储器22上的暂时存储器表格24中，必要时进行读出，写入。此时，经由接口(IF)30与表格信息输入输出部37来进行存储在数据库31中的数据的读出、写入处理。另外，数据库31与服务器1也可由物理上不同的装置来构成，或在相同装置内部逻辑构成。
首先，用图3的动作原理图，来说明使用图1、图2所示的具有呈现信息发送接收功能之服务器1，各用户可以进行哪些内容。图3中表示如下状态，，45所示用户将将构成预订条件对象的呈现项目设定为41所示“location(场所)”，将其条件如42所示设定为“same(相同)”，并对服务器1执行预订。此时，如果45所示的用户目前还滞留在会议室43，将自己的呈现信息“location”如46-1所示登录为“会议室”的情况下，服务器1将自动识别为目前滞留于同一场所，将呈现信息“location”为相同“会议室”的51所示的A、52所示的B、53所示的F如47-1所示，为预订对象，45所示的用户可取得A、B、F的呈现信息。之后，设45所示的用户移动到居室44。之后，45所示的用户如46-2所示，将呈现信息“location”更新为“居室”。这样，服务器1以呈现信息的更新为契机，暂时废弃47-1的预订对象，还将目前滞留于同一场所、呈现信息“location”为相同“居室”的54所示的C、55所示的G、56所示的D、57所示的E如47-2所示，自动重新识别为预订对象，45所示的用户可取得C、G、D、E的呈现信息。即，若45所示的用户向服务器1暂时发送期望预订的消息，则服务器1对应于用户本人的状态变化，如从47-1至47-2所示，自动变更预订对象。通过该处理，进行预订的用户不必明示地变更预订对象，就可开始对应于不同情况的针对对方的预订。另外，相反，可对应于不同情况，不明示宣称地结束对不需要的对方的预订。
下面，用图1的模块图、图2的物理硬件图、图4的网络图、图5的序列图、图6-8的消息例、图9-图14的表格图、图16-20的流程图来说明上述概要的详细动作内容的实例。但是，这些说明中记述的具体发送接收消息内容、序列、表格构成、软件的模块构成、硬件构成、处理流程图仅是一例，只要通过实现目的的动作来达到发明效果，则即便使用其它方法和构成来实现也无妨。
图4是使用本发明的服务实例的网络图。在该网络上，61所示的UserA、62所示的UserB、63所示的UserC等3个用户处于如下状态，分别经由无线访问网1061、有线访问网1062、IP Network1063来访问通信商1064拥有的呈现发送接收服务器1，并阅览其它用户的呈现信息，即对其它用户进行预订。各终端也可能利用通信商1064拥有的认证服务器68或SIP服务器69。另外，设UserA在利用终端中，除64所示的信息终端外，还使用65所示的传感器件。所谓传感器件是RFID(Radio Frequency Identification)等小型标签或可自己发送当前位置的带GPS的便携电话等、能通过某种方法将自己的位置信息登录在服务器中的装置。通过使用传感器件，可使用1065所示的接收机，经由无线将用户的当前位置通知给系统。在本例中，UserA使用传感器件作为第2终端，但还考虑在本终端中使用其它器件或终端、应用程序，还考虑UserA不利用多个终端而仅使用64的信息终端的情况。
图5是图4的动作序列图。通过顺序说明该序列，说明详细的动作流程。另外，图4的序列开始时、各用户的呈现信息之初始值为70的表中所示的值，设UserB、UserC已结束对服务器1的注册处理，开始本发明的条件指定类型的预订。另外，UserB、UserC执行的条件指定类型预订的预订条件与作为UserA执行的条件指定类型预订的预订条件之呈现信息“location”为“same(相同)”的条件一样。
首先，61所示的UserA使用终端64在步骤71注册到呈现信息发送接收服务器1。在注册之后，在步骤72发送指定条件后的呈现信息请求。即，开始本发明的条件指定类型预订。
图6示出此时的消息实例。图6是由SIP来执行预订的情况的消息实例。UserA在表示预订对象的请求线101、To头标102中，不表示构成预订对象的对方用户或组的SIP-URI，而表示自己的SIP-URI。请求线、To头标在SIP消息的传输规定上，必需要记述，但如本实例中所示的自己的SIP-URI那样，只要SIP消息是被传输到服务器1的SIP-URI，则可以是任意值。另外，将预订的条件记述为Contact头标内部的URI参数103。预订条件的记述除如此在现有头标内部以URI参数的形式扩展后记述的方式外，也可采取如104所示独自记述在扩展头标中的方式、如105所示记述在SIP消息主体部中的形式。虽然与条件和记述场所无关，但服务器1为了根据预订条件来特定预订对象，最少必需记述一个。另外，通过记述多个条件，可检索匹配多个条件的对象。
图16、图17示出服务器1在接收64所示的UserA发送的预订请求后执行的处理流程图。用图16、17来说明服务器1的处理步骤。
若服务器1在图16的步骤191由图1的呈现信息取得请求模块13接收预订请求，则在步骤192解析预订消息，并抽取订户与条件。所谓订户是请求取得其它用户的呈现信息之用户，在本例中，是发送了呈现信息请求的用户。本处理由呈现信息取得请求解析模块12执行。另外，在步骤192中，将这些解析后的信息发送给呈现信息、预订信息管理功能2。
发送的信息在步骤193由预订状态管理模块7处理。预订状态管理模块7是用图2所示的预订管理表格25来管理预订的开始、结束等预订状态或各预订的条件之模块。图9中示出预订管理表格的详细内容。预订状态管理模块根据从呈现信息取得请求解析模块发送的信息，将预订条件登录在图9的表格121内的122所示的订户及124所示的条件1中。在存在多个预订条件的情况下，在125之后写入条件。
完成预订登录处理的服务器1接着在步骤194中，为了对进行了预订的UserA通知与当前预订条件匹配的用户、和这些用户的呈现信息，检索在当前时刻与UserA指定的预订条件匹配的其它用户。本处理由图1所示的预订对象管理模块6执行。预订对象管理模块6根据图2的带条件预订管理表格25中记述的条件，经由IF30、数据库31的表格信息输入输出部37，从呈现信息管理表格34中检索与预订条件匹配的用户。由于呈现信息管理表格34中具体记录各用户的当前呈现信息一览，所以只要检索登录了与预订条件匹配的呈现信息之用户即可。由此，即便预订时不指定用户名或组名，也可阅览与条件匹配的用户的呈现信息。
之后，在步骤195中没有与条件匹配的用户的情况下，由于不必执行步骤196-201的处理，所以前进到步骤202，通过图17的步骤212、213、214的处理，通知订户没有匹配的用户，在步骤215结束处理。
在步骤195确认有与条件匹配的用户的情况下，在步骤196由公开呈现控制模块8检索数据库31的允许信息管理表格32。这是因为如果在用户进行了不对订户公开自己的呈现信息之设定的情况下，执行如下控制，即便该用户的呈现信息与订户指定的条件匹配，也不将与条件匹配的情况告诉订户。通过执行该控制，可防止将进行非公开设定的用户之呈现信息与条件匹配告诉订户，即防止秘密公开呈现信息。允许信息管理表格如图14的表格171所示构成，173所示的访问对象用户对172所示的访问用户公开怎样的呈现信息，被记述在允许信息174中。该允许也可使用采用特愿2004-108642的匹配等级允许功能所设定的内容。在检索了允许信息管理表格32之后，仅在步骤197与条件匹配，呈现信息对订户公开的情况下，将该用户在步骤198登录在位于图2的存储器22上的预订对象管理表格27中。图10的131是预订对象管理表格27的表格构成例。预订对象管理模块6在该表格131的预订序号132中写入图9的表格121预订管理序号123中记述的订户之预订管理序号，在预订对象用户133的栏中写入匹配的用户名称，管理当前哪个序号的订户与哪个用户的条件匹配、是否正在阅览呈现信息。在步骤197中将呈现信息设定为非公开的情况下，跳过步骤198、199的处理，不将该用户识别为与条件一致的用户。所谓‘非公开’设定是指设定的用户不让订户知道自己的存在。这里，通过不对订户执行通知，可隐藏进行了‘非公开’设定的用户之存在。
在步骤198中登录了预订对象用户之后，制作向订户发送该用户的呈现信息之消息，此时，通过过滤在步骤199公开的呈现信息来确认可以通知的呈现信息。该处理由图1的公开呈现控制模块8执行，对数据库31的允许信息管理表格32、呈现信息公开策略管理表格33、模板管理表格35进行检索后，确定通知的呈现信息。
公开呈现控制模块8首先检索策略管理表格33。策略管理表格的细节为图12所示的表格151。在该表格中，首先确定UserA登录的呈现信息，检索153、155等呈现项目和154、156等呈现值与UserA的呈现值一致的记录。因为各记录中可指定多个呈现项目，所以根据情况可能有多个记录与条件匹配。例如，在记录157与158这样的实例中，在本例中，UserA的初始呈现值“location”为“会议室”，section为“设计部”，故与记录157、158匹配。此时，条件指定使详细的记录优先。在本例中，由于记录157一方设为条件的呈现项目数量多，成为条件详细，所以视为与记录157匹配。该匹配处理的优先顺序也可由本例的方法之外的方法来实现。
在本例中，视为与记录157匹配，所以确认记录157的分配模板152。在本例中，记述为“A”，但该值是由模板管理表格35管理的模板值。图13的表格161中示出模板管理表格35的详细表格构成。在该表格中，在模板名称162为“A”的记录中，将公开呈现163、164、165的值指定为“location”、“comment”、“material”。即，指这3个呈现均被公开。结果，在UserA执行具有“location＝会议室”、“section＝设计部”的呈现之预订的情况下，可能会参照匹配的其它用户的“location”、“comment”、“material”之呈现项目。在本例中，向图12的分配模板152分配一个模板，但也可分配多个。这样，服务器1利用UserA的呈现信息值来判断可阅览条件匹配用户的哪个呈现信息。另外，即便是利用本处理判断为公开的呈现，在允许信息管理表格32通过单独设定将呈现信息设定为非公开的情况下，使这些信息优先，将呈现信息设定为非公开。呈现信息公开策略管理表格33、模板管理表格35由系统的管理者设定。另一方面，允许信息管理表格32为了对各用户自己登录的呈现信息保护自己的隐私而进行设定。这样，即便是系统管理者设定为公开的呈现信息，在各人为了保守自己的隐私而进行的设定为非公开的情况下，尊重各人的意思，服务器1判断该呈现信息为非公开。这样，通过使各个可设定的过滤功能最优先，确定地订户的公开策略，各用户可沿袭个人持有的公开策略来进行隐私的保护。
在步骤199中进行呈现信息的过滤之后，在步骤200对可公开的呈现信息制作通知消息，保存在暂时存储器表格中，进行发送准备。
在这些处理结束之后，在步骤201全部条件匹配用户的处理未结束的情况下，再次从步骤196开始对下一用户进行处理，重复执行处理，直到对全部匹配的用户之处理结束。
在对全部匹配用户的处理结束的情况下，由图17的步骤212取得登录在暂时存储器表格中的全部匹配用户的消息，由步骤213合成全部消息，并制作对订户的通知消息。本处理由图1的呈现信息分析、构筑模块10进行。之后，由步骤214从呈现信息更新通知发送模块14在图5的步骤74发送。此时的发送消息实例如图7和图8所示。在本例中，在呈现信息的通知中利用SIP的NOTIFY消息，但只要能满足同样的功能，则也可使用其它协议。图7的111所示的部分是SIP消息头标部，113、114所示的部分是SIP消息主体部。在SIP消息头标部中有表示消息发送源的From头标112，但其中未记述发送源用户或组的SIP-URI，而是记述UserA自身的SIP-URI。该部分不必是UserA的SIP-URI，即便是任意值均无妨。另外，113、114是表示呈现信息内容的SIP主体部分，但该部分根据由draft-Ietf-simple-event-list-06.txt规定的格式来记述。113所示部分记述在该通知消息中记述的呈现信息的成员一览、即记述由在先的预订对象管理模块6匹配的用户一览。在图8的114中记述各用户的呈现信息的内容。在本例中，根据draft-Ietf-simple-event-list-06.txt的规定来记述呈现信息的记述，但由其它方法来记述呈现信息也无妨。
接着，服务器1向在序列图的步骤75中进行了预订的UserA发送对于其它用户的预订公开多少自己的呈现信息之询问。通过进行询问，服务器1可确认公开呈现信息的用户之信息公开策略。每当UserA的呈现信息被更新、匹配对象变化时，发送该询问。UserA有可能根据呈现信息的内容而想要变更公开策略。此时，通过在每次更新呈现信息时进行询问，服务器1可知道UserA的公开策略的详细变化。通过该询问，UserA例如在会议室中可看见带入资料或注释，但也可判断当座在自己的座位时，不想让看见(也包含判断为不必看见的情况)，可使公开呈现信息变化。此前在步骤74中，UserA接收与条件匹配的用户之呈现信息时，匹配的其它用户将自己的呈现信息“location”变更为“会议室”时，已接受步骤75的询问，直到在对此进行允许公开的响应之后，向UserA发送呈现信息。接受该询问后，UserA在步骤76执行允许呈现信息公开的响应的情况下，服务器1在步骤77向UserC发送UserA与条件匹配的通知。但是，在UserA在步骤76发送拒绝呈现信息公开的响应的情况下，不通知步骤77的消息。通过不通知，可防止泄漏拒绝公开的UserA的信息。另外，在步骤76中UserA进行允许呈现信息公开的响应的情况下，在本例中，在步骤78还向UserA自身通知UserA与条件匹配的情况，但本发明既可执行也可不执行，最好对每个系统确定可否发送的策略。并且，从步骤75-78的部分(由82的框包围的步骤群)中以系统单位来确定可否执行的策略，在不必的情况下也可不执行。在不执行该步骤群的情况下，根据UserA事先设定的允许信息、和系统管理者设定的图2的数据库31中之呈现信息公开策略管理表格33的设定，将UserA的呈现信息通知给UserC。通知处理的方法基于后述的UserA更新呈现信息时的处理流程图。
之后，UserA在步骤79将自己的呈现信息“location”从“会议室”变更为“居室”。此时，服务器1执行确认伴随呈现信息的更新之预订匹配用户的变更的处理，详细说明其内容。
图18、图19是上述处理的流程图。服务器1在图18的步骤231由图1的呈现信息发送接收模块11接收呈现信息更新消息，在由呈现信息分析、构筑模块10抽取登录的呈现信息之后，由呈现信息管理模块9经由各种信息输入模块4，从IF30更新数据库31的呈现信息管理表格34的呈现信息。之后，开始基于呈现更新的预订匹配用户之更新处理。
首先，服务器1在步骤232，由图1的预订对象管理模块6检索存储器22的带条件预订管理表格25，确认呈现更新用户是否正在预订中。之后，在步骤233，在不在预订中的情况下，跳过之后的步骤234-247的处理，在步骤248进入下一步骤。
在步骤233判断为是预订中的情况下，接着在步骤234，通过检索存储器22的带条件预订管理表格25，确认该预订的条件。在预订的条件中记述构成关于呈现信息的项目与其值的条件等，在下一步骤235中，条件确认的结果，在更新的呈现信息的项目‘未包含于’指定为预订条件的呈现信息项目的一部分中的情况下，跳过步骤236-247的处理，在步骤248进入下一步骤，在本例中，UserA在预订条件中指定呈现信息的项目“location”为与自己相同的值“(条件)”。因此，由于UserA将“location”从“会议室”变更为“居室”，所以服务器1判断为更新的呈现信息的项目包含于预订的条件的一部分中。如本例所示，当提示比较自己的呈现信息值与对方的呈现信息值的条件时，在更新呈现信息的项目中包含作为条件的呈现信息项目的一部分的情况下，UserA通过更新呈现信息，UserA的预订条件从“location”是“会议室”变更为“location”是“居室”，条件方式变化。
在步骤235，当判断为更新的呈现信息的项目‘包含于’预订的条件中的情况下，接着在步骤236，从存储器22上的预订对象管理表格27中，删除所有当前与该预订匹配的用户。这是因为通过订户更新呈现信息，与条件匹配的用户变更，故再次进行匹配处理。在本例中，由于UserA更新的呈现信息“location”包含于UserA的预订条件中，所以处理前进到步骤236。
下面从步骤237至步骤247的处理与上述图16的从步骤194至图17的步骤214的处理流程图一样。
步骤247中发送的消息在图5所示的序列之步骤74中被发送到UserA。
之后，服务器1在步骤1252由图1的预订对象管理模块6检索存储器表格22上的预订对象管理表格27，并确认对当前更新呈现信息的用户进行预订的其它用户。
在步骤1253中，当判断为不存在预订中的其它用户的情况下，跳过步骤1254-1258的处理，在步骤1259前进到下一步骤。
在步骤1253中，当判断为存在预订中的其它用户的情况下，接着在步骤1254，根据存储器22上的带条件预订管理表格25来确认进行该预订的上述其它用户之预订条件。
之后，在步骤1255中，确认更新后的UserA的呈现信息是否与上述其它用户之预订条件匹配，在匹配的情况下，不必执行预订对象的更新，所以跳过步骤1256、1257的处理，前进到步骤1258。
在步骤1255中，更新后的UserA的呈现信息不与上述其它用户之预订条件匹配的情况下，前进到步骤1256。在本例中，UserA更新呈现信息的结果，由于与UserC进行的预订条件不匹配，所以前进到步骤1256。在步骤1256中，呈现对象管理模块6从存储器22上的预订对象管理表格27中删除对象预订的项目。这是因为更新呈现信息后的用户之新的呈现信息不与条件匹配，超出预订对象之外。
之后，在步骤1257，向作为订户的上述其它用户通知变更了预订条件匹配用户的情况。在本例中，结果，在序列图的步骤83中，UserA通知UserC未包含于条件匹配用户中的呈现信息。
之后，在步骤1258中，当全部用户的处理未结束的情况，返回步骤1254，再次执行对其它用户的处理。当全部用户的处理结束的情况下，前进到步骤1259，进入下一步骤252的处理。
服务器1在图20的步骤252由图1的预订对象管理模块6检索存储器表格22上带条件的预订管理表格25，执行更新后的新呈现信息与当前预订的其它用户之预订条件的匹配。
在步骤253中，在不存在进行将更新后的新呈现信息设为对象的带条件预订之其它用户的情况下，跳过步骤254-261的处理，在步骤262结束处理。在存在的情况下，前进到步骤254。在本例中，由于UserB进行成为对象的带条件预订，所以处理前进到步骤254。在步骤254，比较条件内容与呈现信息更新用户的更新后的呈现信息。
之后，在步骤255，在预订条件与呈现信息更新用户的更新后的呈现信息不匹配的情况下，跳过步骤256-步骤261的处理，在步骤262结束处理。在匹配的情况下，处理前进到步骤256。在本例中，由于UserA的新的呈现信息与UserB的条件匹配，所以处理前进到步骤256。通过执行该条件匹配，UserA更新呈现信息的结果，可更新与作为其它用户的UserB之预订条件匹配的用户。
步骤256至步骤259的处理与图16的流程图中所述的图18的步骤239-步骤243一样，是允许关系的处理。在允许的处理结束之后，只要是判断为公开呈现信息的情况下，在步骤260向UserB重新通知匹配的用户。另外，这些允许处理还包含序列图的步骤84之来自服务器1的呈现信息公开请求消息与步骤85的返回消息、之后的步骤87的消息。这两个步骤的内容与序列图的框82一样。通过步骤260的处理，在序列图的78从服务器1向UserB发送消息。
之后，在步骤261中，对全部用户的处理未结束的情况下，为了执行对其余用户的处理，返回步骤254，再次执行处理。在对全部用户的处理结束的情况下，前进到步骤262，结束处理。
之后，在序列图中，在步骤79，UserA将呈现信息“location”从“会议室”变更为“居室”，将此情况通知给UserC，该处理与序列图的步骤79、83一样。
通过这种动作，各用户可对服务器1进行带条件的预订，伴随彼此的呈现信息的变化，边变化预订对象，边参照系统以及其它用户自身允许公开与条件匹配的其它用户呈现信息的信息。
这样，通过UserA不指定用户ID或组ID，而进行仅指定条件的预订，即便不知道对方用户ID、组ID，也可成为预订对象。并且，当预订对象伴随UserA的呈现信息的变化而变化时，UserA即便什么都不执行，均能自动开始对与新条件匹配的其它用户之预订，利用条件的变化来自动解除非预订对象的其它用户之预订。
实施例2图21是本发明的第2实施例。在本例中，273所示的A、272所示的B与271所示的C分别以不同的预订条件274、275、276为条件，执行预订。在本例中，对条件指定以○○m以内为范围，而非图3所示的“same(相同)”。通过如此对条件指定范围，可与条件相匹配地使构成预订对象的用户具有宽度。各个呈现信息“location”的值为277、278、279的值。此时，由于各个用户指定的预订条件不同(范围不同)，所以预订对象变得非对称。即，如280所示，没有与C的条件匹配的其它用户，C不阅览其它用户的呈现信息，相反，B如281所示，阅览C的呈现信息。另外，B与A如281、282所示，对称地执行预订，彼此阅览呈现信息。可利用条件的指定方式来产生这种非对称状态下的预订。各用户可在实施例1所示的系统上设定各自独立的条件。利用该方式，各用户通过向服务器提示各自的预订条件，可实现这些非对称的预订。
实施例3图22是本发明的第3实施例。在本例中，291所示的A、292所示的B、293所示的C、294所示的D的4人进行带条件的预订，各自的条件为295-302。在本例中，各用户不指定呈现信息的值作为预订条件，而指定登录到自己的同伴(buddy)列表为条件。该设定执行预订一侧限定与条件匹配的用户范围。这样，各用户可在自己预订时指定自己条件匹配的范围。并且，系统管理者也可设定这种范围。各用户在自己进行预订时，在指定如此限定匹配的用户范围的条件的情况下，其条件内容也记述在图9的表格121上的124等条件栏中。在管理者设定的情况下，各用户在预订时，仅在管理者设定的用户范围下进行匹配。另外，各用户对呈现信息“location”设定的条件也可如图3的实例所示，指定设定○○m以内的范围，而非“same(相同)”。用图23来说明该范围指定。
图23是呈现信息“location”的值间关联图。通过管理者在系统内设定这种设定，可定义值的范围。在本例中，例如将338“センタ街”与337“ハチ公前”间的距离设定为1。若如此考虑，则例如333“タイムズスクエア”与334“原宿”的距离为3。另外，可认为338“センタ街”与335“西部前”的距离为2或3。这是因为从センタ街到西部前的距离计算模式存在两种，在这种情况下，就选择短距离还是选择长距离而言，只要以系统单位来进行任何选择即可。在本例中，进行选择短距离的判断。在本例中，由于呈现信息中使用位置信息，所以所谓‘距离’是指物理距离，但所谓‘距离’不仅指物理距离，也可定义为指示逻辑距离的术语。例如，也可将距离定义为903所示的class(职务)。此时所谓的‘距离’是表示931所示的本部长、932所示的中心长官在最上位、933所示的部长、其下方934所示的课长、935所示的组长等、组织图上的上下关系远近的逻辑距离。也可利用如此构成定义对象的呈现项目来定义逻辑的距离。
回到图22，考虑各用户的条件内容与匹配用户。图22中，各用户的当前呈现信息为303-360，各用户的同伴列表登录用户为307-310。
291所示的A如311所示，阅览位于“location”条件范围内的B之呈现信息。C被登录于A的同伴列表中，但由于C的“location”不在A的条件范围内，所以C不匹配A的预订条件。292所示的B虽然A、C、D的3人进入“location”的范围内，但登录于同伴列表中的用户仅为A、D，所以如312所示，仅阅览这2人的呈现信息。C虽然仅A被登录于同伴列表中，但由于A未进入“location”的条件范围内，所以预订对象如313所示，为“无”。D由于B存在于“location”的条件范围内，所以如314所示，将B构成预订对象。这样，通过将距离定义为存在信息的值间，还将逻辑距离定义为实施例3的地名等值间的具体距离不清楚的概念值间，服务器可计算预订的范围。
实施例4图24是本发明第4实施例的服务示意图。该服务包含在公共汽车站等车的用户372如375所示确认自己应乘的公共汽车之运行状况的服务、公共汽车运行公司373确认本公司的公共汽车之运行状况的服务、运行中的公共汽车如374所示确认是否有在目的地的公共汽车站等车的用户的服务的3个。用图25来说明该服务的具体内容。图25是图24的服务之动作原理图。在本例中，342所示的A、343所示的B、344所示的C分别在公共汽车站等车。另外，341所示的公共汽车当前正在运行中。公共汽车的前进目的地如353的“destination”所示，为“国立”，途中经由的公共汽车站如“via”所示，为“○○-丁目”、“○○大学”、“国立”。A与C想去的公共汽车站如354、356的“goal”所示，为“国立”，B想去的公共汽车站如355的“goal”所示，为“立川”。A、B、C、公共汽车分别对服务器1设定345-352为条件，进行条件指定类型的预订。另外，在公共汽车站间，如图23的322-331所示的形式，设定值间的关系。
此时，A在○○-丁目”的公共汽车站等车，且下车的公共汽车站为“国立”。341的公共汽车为当前A之前的公共汽车站，且前进目的地为国立，所以与条件匹配。由此，A的预订对象中包含341所示的公共汽车，如304所示，将04路公共汽车向国立的前一公共汽车站出发通知给A。B等车的公共汽车站与A一样，但由于前进目的地为立川，是341的公共汽车不停的公共汽车站，所以不向B通知341所示的公共汽车的信息。另外，C的前进目的地为国立，但由于与公共汽车的距离为2，所以与“location”的条件不匹配，也不将341的公共汽车的信息通知给C。另外，A、B、C的用户间，虽然“location”的范围为1以内，但由于各用户就指定为第2个条件的“via”的值而言，彼此不匹配(A、B、C原本不具有呈现信息“via”，未进行设定)，所以不产生用户间的匹配。
另外，341所示的总线将“location”为±2以内且在自己的“via”中有与对方的“goal”相同的值设为条件，进行预订。从而，可得到以“国立”与公共汽车的“via”中存在的值来登录“goal”的值之A、C的信息，结果，如357所示，可在前进到公共汽车站之前，事先把握在下一公共汽车站有乘客一人(A)，在再下一公共汽车站有乘客一人(C)。“location”、“via”、“goal”等3个呈现各自的呈现所示含义不同，但通过利用各用户的目的，如此将各自的呈现信息的项目指定为匹配条件，可如本例所示，通过使各用户的“想去的场所”与运输到此地的公共汽车“经由的场所”匹配，实现各用户的目的。
在如此应用于公共汽车的运行系统的情况下，各用户通过道路状况，可边在公共汽车站等边了解到达时刻容易变动的公共汽车之实际运行状况。并且，公共汽车方面必需目视在公共汽车站等的用户，来确认到现在为止是否应在各公共汽车站停车，虽然确认未必确实正确，但通过事先知道在各公共汽车站等的用户，可确实知道在各公共汽车站停车的必要性。
权利要求
1.一种状态信息管理系统，具有管理多个终端的状态信息的服务器，其特征在于上述服务器具有接收部，从上述多个终端的第1终端接收状态信息公开请求；控制部，从上述状态信息公开请求中提取状态信息提取条件；和发送部，将上述多个终端中与上述状态信息提取条件一致的一个或多个其它终端的状态信息发送给上述第1终端，上述状态信息提取条件不是表示上述其它终端的信息、表示上述其它终端的用户的信息、或表示上述其它终端或上述其它终端的用户所属组的信息中的任一个。
2.一种状态信息管理系统，具有管理多个终端的状态信息的服务器，其特征在于上述服务器具有接收部，从上述多个终端的第1终端接收状态信息公开请求；控制部，从上述状态信息公开请求中提取状态信息提取条件；和发送部，将上述多个终端中与上述状态信息提取条件一致的一个或多个其它终端的状态信息发送给上述第1终端，上述发送部在符合上述状态信息提取条件的其它终端增加或减少的情况下，将反映了上述增加或减少的一个或多个其它终端的新的状态信息，重新发送给上述第1终端。
3.根据权利要求1或2所述的状态信息管理系统，其特征在于上述状态信息提取条件指定状态信息的值的至少一部分，上述发送部将具有与由上述状态信息提取条件指定的状态信息的值的至少一部分一致的状态信息的上述其它终端的状态信息，发送给上述第1终端。
4.根据权利要求3所述的状态信息管理系统，其特征在于上述状态信息提取条件指定状态信息的值的范围。
5.根据权利要求4所述的状态信息管理系统，其特征在于上述状态信息提取条件指定距上述第1终端的状态信息的值一定距离内的状态信息的值。
6.根据权利要求5所述的状态信息管理系统，其特征在于上述距离是根据物理或逻辑的距离所确定的距离。
7.根据权利要求6所述的状态信息管理系统，其特征在于上述状态信息的值是终端或该终端的用户的所在地，上述距离是根据物理的距离或路程所确定的距离。
8.根据权利要求6所述的状态信息管理系统，其特征在于上述状态信息的值是终端的用户职务名称，上述距离是表示上述职务名称间的组织阶层上的远近的逻辑距离。
9.根据权利要求3所述的状态信息管理系统，其特征在于上述状态信息提取条件指定与上述第1终端的状态信息的关系满足一定的条件的状态信息的值，上述发送部将具有满足上述一定的条件的值的其它终端的状态信息发送给上述第1终端。
10.根据权利要求9所述的状态信息管理系统，其特征在于上述一定的条件是指为与上述第1终端的状态信息的值相同值的条件。
11.根据权利要求9所述的状态信息管理系统，其特征在于上述一定的条件是指为距上述第1终端的状态信息的值一定距离内的值的条件。
12.根据权利要求11所述的状态信息管理系统，其特征在于上述距离是根据物理或逻辑的距离所确定的距离。
13.根据权利要求9所述的状态信息管理系统，其特征在于上述状态信息包含多个项目，上述一定的条件是针对与上述第1终端的状态信息的一个或多个项目相同项目的条件。
14.根据权利要求9所述的状态信息管理系统，其特征在于上述状态信息包含多个项目，上述一定的条件是针对与上述第1终端的状态信息的一个或多个项目不一致的项目的条件。
15.根据权利要求1或2所述的状态信息管理系统，其特征在于上述发送部仅将上述一个或多个其它终端中部分被限定的一个或多个其它终端的状态信息发送给上述第1终端，上述限定其它终端的条件是不根据该其它终端的状态信息的值来限定的条件。
16.根据权利要求15所述的状态信息管理系统，其特征在于上述限定其它终端的条件由上述第1终端指定。
17.根据权利要求16所述的状态信息管理系统，其特征在于上述限定其它终端的条件是指仅限定为包含于上述第1终端事先指定的其它终端的列表中的终端的条件。
18.根据权利要求15所述的状态信息管理系统，其特征在于上述限定其它终端的条件由该系统的管理者设定。
19.根据权利要求15所述的状态信息管理系统，其特征在于上述限定其它终端的条件是指去除上述一个或多个其它终端中拒绝状态信息的公开的其它终端的条件。
20.根据权利要求19所述的状态信息管理系统，其特征在于上述拒绝状态信息的公开的其它终端，事先将拒绝公开的状态信息的值、或拒绝公开的对方终端的至少之一登录于该服务器上。
21.根据权利要求19所述的状态信息管理系统，其特征在于上述服务器向上述一个或多个终端询问能否公开状态信息。
22.根据权利要求21所述的状态信息管理系统，其特征在于向与上述状态信息提取条件一致的上述其它终端进行上述询问。
23.根据权利要求2所述的状态信息管理系统，其特征在于在上述第1终端的状态信息被更新时，将上述新的状态信息发送给上述第1终端。
24.根据权利要求2所述的状态信息管理系统，其特征在于在上述第1终端以外的终端的任一个的状态信息被更新时，将上述新的状态信息发送给上述第1终端。
25.一种管理多个终端的状态信息的状态信息管理服务器，其特征在于具有接收部，从上述多个终端中的第1终端接收状态信息公开请求；控制部，从上述状态信息公开请求中提取状态信息提取条件；和发送部，将上述多个终端中与上述状态信息提取条件一致的一个或多个其它终端的状态信息发送给上述第1终端，上述状态信息提取条件不是表示上述其它终端的信息、表示上述其它终端的用户的信息、或表示上述其它终端或上述其它终端的用户所属组的信息中的任一个。
26.一种管理多个终端的状态信息的状态信息管理服务器，其特征在于具有接收部，从上述多个终端中的第1终端接收状态信息公开请求；控制部，从上述状态信息公开请求中提取状态信息提取条件；和发送部，将上述多个终端中与上述状态信息提取条件一致的一个或多个其它终端的状态信息发送给上述第1终端，上述发送部在与上述状态信息提取条件一致的其它终端增加或减少的情况下，将反映了上述增加或减少的一个或多个其它终端的新的状态信息，重新发送给上述第1终端。
27.根据权利要求25或26所述的状态信息管理服务器，其特征在于上述状态信息提取条件指定状态信息的值的至少一部分，上述发送部将具有与由上述状态信息提取条件指定的状态信息的值的至少一部分一致的状态信息的上述其它终端的状态信息，发送给上述第1终端。
28.根据权利要求27所述的状态信息管理服务器，其特征在于上述状态信息提取条件指定状态信息的值的范围。
29.根据权利要求28所述的状态信息管理服务器，其特征在于上述状态信息提取条件指定距上述第1终端的状态信息的值一定距离内的状态信息的值。
30.根据权利要求29所述的状态信息管理服务器，其特征在于上述距离是根据物理或逻辑的距离所确定的距离。
31.根据权利要求30所述的状态信息管理服务器，其特征在于上述状态信息的值是终端或该终端的用户所在地，上述距离是根据物理的距离或路程所确定的距离。
32.根据权利要求30所述的状态信息管理服务器，其特征在于上述状态信息的值是终端的用户职务名称，上述距离是表示上述职务名称间组织阶层上的远近的逻辑距离。
33.根据权利要求27所述的状态信息管理服务器，其特征在于上述状态信息提取条件指定与上述第1终端的状态信息的关系满足一定的条件的状态信息的值，上述发送部将具有满足上述一定的条件的值的其它终端的状态信息发送给上述第1终端。
34.根据权利要求33所述的状态信息管理服务器，其特征在于上述一定的条件是指为与上述第1终端的状态信息的值相同值的条件。
35.根据权利要求33所述的状态信息管理服务器，其特征在于上述一定的条件是指为距上述第1终端的状态信息的值一定距离内的值的条件。
36.根据权利要求35所述的状态信息管理服务器，其特征在于上述距离是根据物理或逻辑的距离所确定的距离。
37.根据权利要求33所述的状态信息管理服务器，其特征在于上述状态信息包含多个项目，上述一定的条件是针对与上述第1终端的状态信息的一个或多个项目相同项目的条件。
38.根据权利要求33所述的状态信息管理服务器，其特征在于上述状态信息包含多个项目，上述一定的条件是针对与上述第1终端的状态信息的一个或多个项目不一致的项目的条件。
39.根据权利要求25或26所述的状态信息管理服务器，其特征在于上述发送部仅将上述一个或多个其它终端中部分被限定的一个或多个其它终端的状态信息发送给上述第1终端，上述限定其它终端的条件是不根据该其它终端的状态信息的值来限定的条件。
40.根据权利要求39所述的状态信息管理服务器，其特征在于上述限定其它终端的条件由上述第1终端指定。
41.根据权利要求40所述的状态信息管理服务器，其特征在于上述限定其它终端的条件是指仅限定为包含于上述第1终端事先指定的其它终端列表中的终端的条件。
42.根据权利要求39所述的状态信息管理服务器，其特征在于上述限定其它终端的条件由该系统的管理者设定。
43.根据权利要求40所述的状态信息管理服务器，其特征在于上述限定其它终端的条件是指去除上述一个或多个其它终端中拒绝状态信息公开的其它终端的条件。
44.根据权利要求43所述的状态信息管理服务器，其特征在于上述拒绝状态信息公开的其它终端事先将拒绝公开的状态信息的值、或拒绝公开的对方终端的至少之一登录于该服务器上。
45.根据权利要求43所述的状态信息管理服务器，其特征在于上述服务器向上述一个或多个终端询问能否公开状态信息。
46.根据权利要求45所述的状态信息管理服务器，其特征在于向与上述状态信息提取条件一致的上述其它终端进行上述询问。
47.根据权利要求26所述的状态信息管理服务器，其特征在于在上述第1终端的状态信息被更新时，将上述新的状态信息发送给上述第1终端。
48.根据权利要求26所述的状态信息管理服务器，其特征在于在上述第1终端以外的终端的任一个的状态信息被更新时，将上述新的状态信息发送给上述第1终端。
全文摘要
本发明提供一种状态信息管理系统和状态信息管理服务器。当开始用于取得呈现信息的预订时，之前必需以任何方法取得预订对象的ID，必需开始指定其的预订。不指定预订对象，而指定预订对象的条件(呈现的值等)进行预订。例如，若以当前位置相同为条件，进行预订，则自动开始针对与条件匹配的用户的预订，取得呈现，但当对方或自己的呈现变化为不同值时，预订对象自动变化。不必在预订开始时事先取得预订对象的用户ID、组ID等。
文档编号H04L12/16GK1842006SQ20061000511
公开日2006年10月4日 申请日期2006年1月12日 优先权日2005年4月1日
发明者宫田辰彦, 春日谦治 申请人:株式会社日立制作所