JP4340576B2 - サーバ - Google Patents

Description

本発明は、情報公開の設定方式に関する。

通信技術とネットワーク技術の発展に伴い、いつでもどこでもコミュニケーションを取れるユビキタスネットワーク社会が到来しつつある。ユビキタス社会でのコミュニケーションでは、各ユーザが自他者の個人情報をデータベースに登録し、種々のサービスを受けることが可能になるといわれている。

現在、データベース上でプライバシ保護を管理する方式の一つに、Unix（Unixは登録商標）システムで用いられているパーミッションシステムがある。これはディレクトリ構造を持ったファイルシステム上のディレクトリないしファイルに対し、保有者、グループ、他人と3分割されたアクセス単位を用いて、アクセス単位ごとにRead（読み出し）、Write(書き込み)、Execute（実行）の3操作について、アクセス可否のパーミッションを設定する方式である。パーミッションの設定は、通常、システム全体のセキュリティの観念から，システム全体の管理者により行われている。

図２７には、Unixシステムで用いられているファイルシステムの構造図に、パーミッション設定で用いられるパラメータを併せて示した。本図を用いて、Unixで行われているパーミッション管理方式について説明する。
まず、図２７の前提条件について説明する。図２７のファイルシステムは、rootディレクトリの下に、第１階層ディレクトリ、第２階層ディレクトリが複数個形成され、第２階層ディレクトリの下層にfile A，file B，file Cの３つのファイルが格納されたツリー構造を有している。本ファイルシステム上には、User A，User B，User Cの３ユーザが存在しているとする。また、User A，User CによりGroup Aが、User A，User B によりGroup Bが形成されているものとする。

ファイルシステムの外側の各四角は、各ディレクトリ、各ファイルに対する、アクセス権限の所在と種別（以下、パーミッション）の設定値を示している。例えば、file Aの右側の四角はfile Aに対するパーミッションの設定値を示している。file Aに対するパーミッションの設定によれば、file AのオーナはUser Aであり、グループパーミッションが与えられたグループはGroup Aである。また、オーナに与えられたアクセス権限の種別は、r、w、xであり、すなわちRead、Write、Executeのいずれの操作も実行可能である。

また、グループに与えられた権限はr、wであり、すなわち、Group Aに属するユーザが可能な操作はRead、Write操作である。他人に与えられた権限は−であり、他人は、file Aを全く操作できない。
図示されていないが、本ファイルシステムには、パーミッション管理を行なう管理サーバが付随しているものとする。パーミッションの各設定値は、管理サーバ内の記憶手段に保管されており、各ディレクトリやファイルへのアクセスが発生するたびに、管理サーバが当該記憶手段を参照してパーミッションを判定する。

次に、User A，User B，User Cが、file A，file B，file Cへアクセスする際のパーミッションの判定方法について説明する。
User Aがfile Aにアクセスを行う場合，rootディレクトリ，第１階層ディレクトリ，第２階層ディレクトリ，ファイルの順番にアクセスを開始する。実際にはhome，User A，file Aの順番でアクセスを行う。ファイルシステムのアクセス管理サーバは、まず、User Aがアクセスしようとするhome、User Aの各ディレクトリおよびfile Aのオーナが誰であるか確認する。オーナは全てUser Aであり、オーナに対しては、全ての階層で、r、w、xの各操作が許可されている。従って、User Aがfile Aに対してアクセスする場合、ファイルシステムは、User Aに対し、第１階層ディレクトリ、第２階層ディレクトリの順でアクセスを許可し、最終的にfile Aへのアクセスを許可する。次に、file Aに対して、write，read，実行すべての処理の実行をも許可する。

一方、file B、file Cに対しては、User Aはオーナではない。そこでfile B、file CへのUser Aのアクセス判定に際しては、ファイルシステムは、グループパーミッションを確認する。例えば、User AはGroup Bに属している。file Bの右側の四角内に示されたパーミッション設定値によれば、Group Bに属するユーザはfile Bに対してread，writeの操作を行える。従ってファイルシステムは、User Aに対しては、file Bへのread，write操作のみを許可する。file Cに対するパーミッションも同様である。

次にUser Bのファイルアクセスについて説明する。User Bがhomeにアクセスを行うと、ファイルシステムは、User Bのhomeへのアクセス権限について判定を行う。User B は、homeのオーナでもなく、Group Aに属してもいない。よって、ファイルシステムは他人に対するパーミッションを確認するが、他人に対するパーミッションの内容はすべて不許可に設定されている。従って、User Bはhomeに対してアクセス権限がなく、home以下のすべてのディレクトリ，ファイルにアクセスすることが出来ない。file BのオーナはUser Bであるが、上層でアクセスが塞がれているので、自分がオーナであるfile Bであってもアクセスが出来ない。

次にUser Cのファイルアクセスについて説明する。User CはGroup Aに属しているので， User Cは、home，User Aの各階層のディレクトリに対してアクセス権限を持っている。よって、ファイルシステムは、User Cが第２階層ディレクトリを通過するまでは許可する。file Aについては、User C はオーナではないので、グループパーミッションを確認する。User C はGroup Aに所属しているので、ファイルシステムは、User Cに対し、file A へのread，writeを許可する。file Bについては、User CはオーナでもGroup Bに所属してもいないので、ファイルシステムは他人に対するパーミッションを確認し，User Cのfile Bへのアクセスは許可しない。file Cについては、User Cがオーナであるから、ファイルシステムはwrite，read，実行の全操作を許可する。

このようにUnixのアクセス制御管理では上位のディレクトリを確認しながら下位のディレクトリ，ファイルにアクセス管理を行うので、上位のディレクトリにパーミッションが無い場合，下位にアクセスすることが出来なくなる。つまり，下位のパーミッションをいくら変更しても上位のパーミッションも同様に変更しない限りアクセスすることが出来ない。更にまた，新しいアクセスユーザ範囲を設定するときは新たにグループを作成してグループに対するパーミッション設定を行う必要がある。

また、他の方式にリレーショナルデータベースで用いられているようなアクセスコントロールがある。これは各アクセス者、あるいは何人かのアクセス者が集まったグループに毎に、データベースのレコードに対するアクセス権を設定する方式である。簡単にいえば、ツリー構造を用いないようなファイルシステムであって、リレーショナルデータベースの各データテーブルへのパーミッションをアクセス者毎に設定する。パーミッション設定は、データベースシステムの管理者が行う。

加入者の個人情報に基づき種々のサービスを展開するビジネスにおいては、プライバシ保護の観点から、個人情報を開示する範囲の設定・管理が重要となる。このため、個人情報の開示範囲を設定・管理するためのパーミッションの管理が重要である。

従来技術では、パーミッションの管理システムはファイルやデータベースサーバに付随し、特定のデータ毎にパーミッション管理を行っていた。すなわち、パーミッション情報を他の情報と区別して、パーミッション情報だけを管理するサーバは存在しなかった。例えば、Unixのファイルシステムでは、ファイルとして管理される文書、画像等、種々のデータ毎にパーミッション管理を行っている。しかし、個人情報に基づきサービスを提供するビジネスの場合、サービス提供者の保有するサービス提供手段（サーバ等）は、ユーザが提供を受けようとするサービスの種類により物理的に異なる。

例えば、デパートでの商品購入履歴はデパートが持つサーバに保存されるだろうし、端末の位置情報は端末の管理キャリアのサーバに保存される。各ユーザが自分の情報に対するパーミッションを変更したい時、これらサーバに個別にアクセスするのでは設定が煩雑であり、ユーザの負担が大きい。更に、サービス提供者の保有するサーバについても、パーミッション設定を管理するデータベースを個別に持つ必要が出てくる。

このようなパーミッション設定においては、単純なパーミッション設定方式を採用すると，情報量の増大に伴いユーザの負担が比例的に増大する。その結果，システムのパーミッション機能が論理的に完成されたものであっても，人間自身の操作ミスにより情報が流出してしまう危険性が上がる。個人情報を登録するサーバは個人情報の保護が最も重大なファクターであり，その機能がたとえ人間の操作ミスが原因だとしても，結果として流出する可能性が高くなるとなればサーバ自体の信用問題となる。

また、ユーザの個人情報に基づき種々のサービスを行うようなビジネスでは、ユーザの現在状況や時間帯、気分などにより、個人情報の開示可否の設定変更が頻繁に発生する。従来のパーミッション管理方式は、管理者が一度アクセスコントロールの設定を行った後は、設定変更頻度が多くないという前提の上に開発されており、頻度の高い更新に対して頻度を軽減するようなしくみがない。

更にまた，パーミッションが付随する個人情報には、個人情報の種類毎に上位・下位の関係が存在する。一方、ある個人情報に対して設定されるパーミッションは、公開、read、writeなどのように、複数設定される。パーミッションの設定値は、一つの個人情報に対して付与される複数のパーミッション間で論理的に矛盾無く設定されている必要もあるが、パーミッションが設定された個人情報に対して上位・下位に位置する個人情報に対して付与されているパーミッションの設定値に対しても、論理的に矛盾無く設定されている必要がある。

また、サービス提供者がユーザの個人情報を利用して第三者にサービスを提供するような場合、プライバシ保護の関係上、Read、Writeの可否だけを管理して第三者に対するユーザの個人情報へのアクセス可否を判断するだけでなく、情報の存在そのものを隠蔽する必要がある場合もある。従来技術では、アクセス対象となるデータの参照要求に合わせてパーミッションの可否を判断する管理方式であったため、存在そのものを隠蔽することができなかった。すなわち、パーミッション可否が判断された＝アクセス対象が存在する、であった。
本発明は、パーミッションを適切に管理することが可能なサーバ、あるいは当該サーバを用いたサービスモデルを提供することを目的とする。

本発明においては、パーミッションの設定値を専門に管理する管理サーバを設けることにより、サービス提供者毎にパーミッション設定を行う必要があるという、設定の煩雑さという課題を解決する。
上記パーミッション設定値の管理サーバにおいては、種々のパーミッション設定値を、パーミッションの上下関係に応じて複数に分類して管理する。これにより、パーミッション設定値の適切な管理が可能となる。上下関係に応じて分類する以外にも、上下関係を識別可能な識別コードをパーミッションに与え、当該識別情報に対応させて管理しても良い。これにより、パーミッションの設定値のみならず、上下関係を持った情報群を適切に管理することが可能となる。

本発明に関わる管理サーバは、パーミッションの自動設定変更機能を備えていても良い。つまり、他のパーミッションに対して相対的に下位のパーミッションに対する設定値の変更を実行する際に、当該パーミッションに対して相対的に上位のパーミッションの設定値を自動変更する。これにより、パーミッション設定値変更の際にパーミッションの上下関係の整合性を保つことが可能となるため、パーミッションの設定変更頻度が多いようなサービスを提供する際にも、ユーザの負担増加を減らすことができる。これらパーミッション設定値の自動変更は、ひとつの個人情報に付与されている複数のパーミッション間と、当該ひとつの個人情報の上位・下位の個人情報に対して設定されているパーミッション間とで、論理的な矛盾が生じないように設定変更を行なう。

パーミッションのみを独立に管理するため、従来、新たなサービスに加入するたびに行っていたパーミッションの設定を簡略化でき、ユーザビリティが向上する。また、パーミッション情報のみならず、上下関係を持った情報群を従来技術に比べて適切に管理することが可能となる。

以下の実施例では、個人情報、プレゼンス情報等を含むユーザの属性情報をオブジェクト情報と称し、第三者に対する個々のオブジェクト情報の開示可否をパーミッションと称する。

本実施例では、プレゼンスサーバの構造、動作、及びプレゼンスサーバを用いたサービスを実現するためのネットワークについて説明する。
図１には、本実施例のプレゼンスサーバの機能ブロック図を模式的に示した。図１の機能ブロック図は、ソフトウェア上実現される論理的な機能構成を示した図であるが、各機能ブロックをハードウェアで構成しても構わない。

図２には、図１に示した機能ブロックが、ハードウェア上、どう実現されているかを示した。図１に示した種々の機能ブロックの動作は、図２に示すメモリ22のプログラム格納部26に収納されており，動作時にはＣＰＵ21がその動作手順を読み出して実行する。個々の機能ブロックが動作する際に必要なパーミッションの設定値は、メモリ22に格納されており、ＣＰＵ21は、メモリ22に格納されたエントリテーブルを読み出すことにより、必要な情報を取り出し，書き込む。

次に、プレゼンスサーバ1が、ユーザからのパーミッション設定要求を受信して、その内容を図２のパーミッション設定テーブル24に書き込むまでの全体的な動作について説明する。
ユーザが自分の情報に対するパーミッション設定要求を端末から送信すると、プレゼンスサーバ1の各インターフェース11−1〜11−ｎがその送信メッセージを受信する。そこでそのメッセージはまず、パーミッション情報入出力部2に転送され、パーミッション情報送受信部4がそのメッセージを受信する。次にメッセージをパーミッション入力情報構築・転送部5に送信する。パーミッション情報構築・転送部5では、メッセージの中からパーミッション設定要求の部分を抽出して、サーバ内部で解釈できる形式にデータを構築し、構築されたユーザ設定要求をパーミッション設定計算処理部3のパーミッション設定内容外部入出力部7に転送する。

パーミッション設定内容外部入出力部7はその要求をパーミッション設定内容整合部9に転送し、パーミッション設定内容整合部9は設定内容の整合を行う。その際，整合に必要な情報をパーミッション情報内部入出力部8を介して図２に示すメモリ22の情報上下関係設定テーブル23から読み出す。また，現在設定されているパーミッションとユーザが要求してきたパーミッション設定との矛盾を確認して整合性を取るために，図２に示すパーミッション設定テーブル24から現在のパーミッション設定を読み出す。

パーミッションを整合すると，次に図２に示すパーミッション設定対応記述テーブル25から図８に示すパーミッション情報を格納する際の対応テーブルを読み込み，図２のパーミッション設定テーブル24の記述形式に対応した形にパーミッション情報を変換する。整合，記述形式変換を行ったパーミッション設定はパーミッション設定内部入出力部7に転送される。パーミッション設定内部入出力部7は図２のデータバス27を介してメモリ22上にあるパーミッション設定テーブル24に設定内容を記憶する。記憶が終わると終わったことがパーミッション設定内部入出力部7を介してパーミッション設定内容整合部9に送信され，それを受信すると、パーミッション設定が成功したことを示すメッセージがパーミッション設定外部入出力部7を介して，パーミッション情報送受信部4に送信され，パーミッション情報送受信部4がインターフェース11を介してパーミッション設定が成功したことをユーザに送信する。

次に、本実施例のプレゼンスサーバ1が、ユーザの要求により、プレゼンスサーバ1に記憶されたパーミッション情報を読み出してユーザに送信する時の全体的な動作について説明する。まずユーザからのパーミッション取得要求メッセージを受信したインターフェース11〜11-nはそのメッセージをパーミッション情報送受信部4で受信する。パーミッション情報送受信部4はその情報をパーミッション設定計算処理部3のパーミッション設定外部入出力部7に転送する。パーミッション設定外部入出力部7はその内容をパーミッション出力内容計算部10に送信する。パーミッション出力内容計算部10はユーザから指定されたパーミッション情報をメモリ22から取得する為に，パーミッション設定内部入出力部8へ取得命令を発行し，パーミッション設定内部入出力部8は図２のデータバス27を介してメモリ22のパーミッション設定テーブル24に格納された指定のパーミッション設定内容を呼び出す。

さらにパーミッション出力内容計算部10はパーミッション設定内部入出力部8を介して図２に示すパーミッション設定対応記述テーブル25から情報を取り出し，メモリに記述された情報を自分が処理するためのパーミッション情報に変換する。その後、パーミッション出力内容計算部はその設定内容について矛盾が発生しないように計算を行う。その際計算を行うための情報を図２に示すメモリ22の情報上下関係設定テーブル23から読み出す。計算後，その内容はパーミッション設定外部入出力部7を介して，パーミッション出力情報受信・構築部6に転送される。

パーミッション出力情報受信・構築部6は受信したパーミッション設定内容からユーザクライアントが解釈できるメッセージを構築し、パーミッション情報送受信部4を介してパーミッション設定内容を記述したメッセージをインターフェース11から送信する。なお，管理コンソールは、プレゼンスサーバの管理者が図２に示すパーミッション設定対応記述テーブル25や情報上下関係設定テーブル23を設定設定するための装置である。

図３には、オブジェクト情報を分類するための階層構造モデルを示す。本実施例において想定している階層モデルでは、ユーザＩＤ31は、階層モデルの最上位の情報に位置する。ユーザＩＤは、各ユーザを一意に識別可能なＩＤであれば何でも良く、数値やコードの替りに、氏名と住所などを組み合わせて使用することもできる。ユーザＩＤの１階層下位には、ユーザに付随する情報32が位置する。ユーザに付随する情報とは、例えば、各ユーザが携帯電話を所有しているか否か、特定のサービスに加入しているか否かなどを示す情報である。ユーザに特定のサービスを受ける意志があるかどうかを示す情報と言い換えても良い。ユーザは、複数の端末を所有している場合もあり得るし、全く所有していない場合もあり得る。サービスについても同様である。

ユーザの付随情報の１階層下位には、端末ＩＤ33-1〜33-nやサービスＩＤ34-1〜34-nが位置する。本モデルでは、端末ＩＤやサービスＩＤが判れば、端末種別やサービスの種別は自動的に判明するものと考えているが、端末種別情報やサービス種別情報を、各ＩＤ情報と別にし、更に１階層下位に位置づけても良い。端末ＩＤとしては、例えば、電話番号やＳＩＰ（Session Initiation Protocol）、ＵＲＩ等が使用できる。また、サービスＩＤとは、例えば、サービス提供業者がサービス加入者に対して割り振るＩＤである。いうまでもないが、端末種別情報とは、端末が例えば、PDA33-nであるか携帯電話33-1であるか、あるいはPCなどの固定端末であるか等を示す情報である。サービス種別情報とは、例えば、ユーザが加入しているサービスが、ＩＭサービス34-1〜であるかビデオチャットサービス34-nであるかを示す情報である。

端末ＩＤ33-1〜33-nおよびサービスＩＤ34-1〜34-nのさらに1階層下位には、また各端末やサービスに付随する各種の情報35-1〜35-n 〜38-1〜38-n が位置する。端末付随情報とは、例えば、端末毎に持つオンラインステータスや話中ステータス、位置情報等、各種端末に付随する各種の情報である。また、サービス付随情報とは、各サービス提供業者がサービスを展開するのに必要とする情報のことであり、例えば、星占いのサービス提供業者であれば、サービス加入者の生年月日や星座などの情報が該当する。プレゼンスサーバ1は、種々のオブジェクト情報を、図３の階層モデルに従って記憶する。

図３では、4層の階層モデルを示したが、構造をもっと細分化して、より多層の構造としてオブジェクト情報を記憶しても良い。また、構造をもっと簡略化して、３層や２層の階層としてオブジェクト情報を記憶しても良い。実際には、２層目のユーザ付属情報は考慮しなくても良い場合が多い。端末を持っていないユーザや、サービスに加入していないユーザは、そもそもユーザＩＤを持たない場合が多いからである。ただし、ユーザやサービス提供者の都合によっては、付属情報32の階層を設けた方がよい場合があり得る。例えば、ユーザが、一時的にサービスの享受を停止して、しばらく経った後にサービス享受を再開したい場合や、サービス提供者の方から、ユーザへのサービス提供を一時的に中断したい場合など（例えば、ユーザが料金を支払えなくなった場合等）、以前のユーザＩＤがそのまま使用できて便利である。

図４は、各オブジェクト情報に対して設定されるパーミッションに上下関係があることを示した図である。プレゼンスサーバ1が持つパーミッション情報の階層構造はオブジェクト情報の階層構造と同様となる。プレゼンスサーバ1はこの階層構造モデルを表す情報を図2に示すメモリ22の情報上下関係設定テーブル23に保持し，上記のパーミッション情報の計算時に図１に示すパーミッション設定内容整合部9やパーミッション出力内容計算部10が随時呼び出して利用する。図３と図４とを対比すると、図４の第１の階層構造が、図３のユーザＩＤ層に相当する。プレゼンスサーバ1は、ユーザＩＤに対するパーミッション41を最上位のパーミッションとして認識し、記憶する。

その1階層下位にはユーザに付随する各情報に対するパーミッション42、各サービスＩＤに対するパーミッション43、各端末ＩＤに対するパーミッション44を、さらにその1階層下位にはサービスに付随する各情報へのパーミッション45、端末に付随する各情報に対するパーミッション46を記憶する。プレゼンスサーバ1はこの構造を持ったパーミッション設定情報を、オブジェクト情報の設定を行なったユーザとその情報を閲覧しようとする第三者（サービス提供業者のみならず、いわゆる第三者も含む）との組み合わせの数だけ記憶する。

図５は本願発明のプレゼンスサーバ1が取り扱うオブジェクト情報に対するパーミッション設定の設定種別単位での記憶構造を示した図である。パーミッションの設定値は、あるオブジェクト情報をどの程度第三者に対して開示したいかの度合いによって、複数の値を取りうる。本実施例では、各オブジェクト情報41〜46に対して設定できるパーミッションの種別は、公開設定52、Read設定53、Write設定54の３種とした。52〜54の各種別に対しては許可56、もしくは拒否57の値を設定できる。

公開設定52とは閲覧ユーザに対してその情報を見せるか、見せないかを決める設定であり、55−1のように許可と設定すると閲覧ユーザに情報を見せ、56−1のように拒否と設定すると閲覧ユーザに情報を見せないようにする。拒否設定をされた閲覧ユーザはその情報を公開ユーザが所有していることを知ることができなくなる。例えばユーザＩＤ41に対して公開設定52を拒否と設定すると閲覧ユーザは公開ユーザのユーザＩＤを知ることができない。つまりその公開ユーザの存在を第三者に対して隠蔽することができる。逆にいえば、オブジェクト情報の隠蔽機能をプレゼンスサーバに付加する場合は、パーミッションの設定種別に、公開設定というパラメータを設けなければならない。

Read設定53とは、閲覧ユーザに対するその情報の読み出しの許可、もしくは拒否を決める設定であり、55−2のように許可と設定すると閲覧ユーザはその情報を見ることが可能となり、56−2のように拒否と設定すると閲覧ユーザがその情報の閲覧を要求した時に、公開拒否されたことが通知される。 Write設定54とは閲覧ユーザに対するその情報の書き込みの許可、もしくは拒否を決める設定であり、55−3のように許可と設定すると閲覧ユーザがその情報の登録、もしくは更新を行うことが可能となる。つまり公開ユーザが所有する情報を第3者が代理で更新することが可能となる。各オブジェクト情報には1情報につきこの3つのパーミッション設定を行うことが可能である。また、この3つの設定は階層構造を取る。プレゼンスサーバは各オブジェクト情報41〜46に対してまず最上位の設定を公開設定52とし、その下位をRead設定53、さらにその下位をWrite設定54としてパーミッション情報を取り扱う。また、これら3つの設定の内容については法則性がある。例えば、最下位のWrite設定54が許可の場合は上位のRead設定53も許可となり、さらに最上位の公開設定52も許可となる。

また、最上位の公開設定52が拒否であれば下位のRead設定53、Write設定54も同様に拒否となる。つまり、上位設定が拒否であった場合、下位の設定もそれに従い拒否設定を行い、また、下位の設定が許可であるなら上位の設定も同様に許可となる。これは、情報を閲覧できるなら当然公開もされているし、更新が可能であるなら当然閲覧も可能だし、公開もされているはずであるからである。よってこの3設定は階層毎に矛盾がないような設定を行う方式となる。

なお、上記公開設定52、Read設定53、Write設定の他、パーミッションの設定種別は、図２の管理コンソールを介して、プレゼンスサーバのユーザが自由に設定することが可能である。例えば。公開設定種別の数を増やせば、よりきめ細かな開示レベルを設定することが可能であるし、逆に隠蔽機能が不要な場合は、公開設定というパラメータを削除することもできる。いずれにせよ、本実施例では、オブジェクト情報を複数に分類し、かつ上下関係を与えて管理することで、オブジェクト情報の適切な管理を可能としている。この情報も図2に示すメモリ22の情報上下関係設定テーブル23に保持し，上記のパーミッション情報の計算時に図１に示すパーミッション設定内容整合部9やパーミッション出力内容計算部10が随時呼び出して利用する。

図６、図７、図８、は本願発明のプレゼンスサーバ1が実際に記憶するパーミッションを設定するためのエントリテーブルの例である。プレゼンスサーバ1は各ユーザが設定したパーミッション情報を図２の24に示す様なメモリ領域に記憶する場合、テーブル61、71、81の3つのテーブルで記憶を行う。以下では、プレゼンスサーバ1が各ユーザからパーミッション設定要求を受信し、その内容を記憶する時の動作を説明する。なお，図6に示すテーブル61，図7に示すテーブル71は図２に示すメモリ22のパーミッション設定テーブル24に格納される。また，図8に示すテーブル81は図２に示すメモリ22のパーミッション設定対応記述テーブル25に格納される。

まず図６の61に示すテーブル内部の公開ユーザ名フィールド62の中から情報を公開するユーザのユーザＩＤを検索し、それに対応したインデックス63を読み出す。ここで公開ユーザ62とはオブジェクト情報を公開するユーザのことを指す。簡単には、オブジェクト情報に基づく何らかのサービスをサービス提供者から受けているユーザと考えてもよい。

図７はオブジェクト情報を開示する第三者と当該オブジェクト情報に対するパーミッションの設定値とが記録されたエントリテーブルである。図７のエントリテーブルは、図６に示されたインデックス毎に存在する。例えば、公開ユーザ名がUser Aのユーザは、インデックス1で識別されるパーミッション設定用のエントリテーブルを持っている。User Bはインデックス2のエントリテーブルを持っている。User C以下も同様である。

プレゼンスサーバ1は、71に示すインデックステーブルの内、読み出したインデックス番号に対応したテーブルから閲覧ユーザ名フィールドを検索し、それに対応したパーミッション設定内容73にパーミッション設定を書き込む。ここで閲覧ユーザ72とは公開ユーザが公開するオブジェクト情報を参照，もしくは公開ユーザの代理で更新するユーザ，またはアプリケーションサーバのことを指す。閲覧ユーザ名フィールドを検索した結果，閲覧ユーザ名を見つけることが出来なかった場合，新規のパーミッション設定とみなし，新たな閲覧ユーザ名とパーミッション設定内容をインデックステーブル７１の各フィールドに追加する。また，ユーザからの設定要求がパーミッションの削除であった場合，インデックステーブル７１から指定された閲覧ユーザ名を閲覧ユーザフィールド７２から削除，さらにそれに対応したパーミッション設定内容フィールド７３も削除する。

また、プレゼンスサーバ1がユーザからパーミッション設定の取得要求を受信し、その内容を読み出す時も同様の動作を行い、パーミッション設定内容73からパーミッション設定を読み出す。また、インデックステーブル71は情報を公開するユーザ分用意する。つまり公開ユーザ毎にインデックステーブルを持つ形式となる。このテーブル71には閲覧ユーザ72とその閲覧ユーザに対するパーミッション設定内容73が記述されている。73のパーミッション設定は例えば64ビットの2進数の列で記述されている。この2進数の記述には先頭から2ビットずつ各情報に対するパーミッションを設定する。

この2ビットの値がどのオブジェクト情報についてのパーミッションであるかを示しているのが図８のテーブル81である。テーブル81の番号82はビット列の順番を示し，それに対応する設定対象ユーザ情報83に対象のオブジェクト情報が記述されている。例えばテーブル81で記述されている情報ではパーミッション設定内容73の始めの2ビットが番号1に対応するユーザIDのパーミッション，次の2ビットが番号1の2番に対応するIMサービスIDのパーミッションと読み取ることが出来る。

新たな公開ユーザを追加する場合，エントリテーブル61に公開ユーザ名を追加する。この時インデックスフィールド６３に記述するインデックス番号はサーバが空き番号を把握し，自動的に設定する。また，その時に新規追加した公開ユーザ用のインデックステーブル７１を用意する。逆に，現在登録されている公開ユーザを削除する場合はまず削除するユーザのインデックステーブル７１を消去し，その後，エントリテーブル６１の公開ユーザ名フィールド６２から削除するユーザ名を検索，その情報を削除する。

図８には、図７に示したパーミッションの設定内容をサーバが解釈する際の参照用テーブルを示す。図８の参照用テーブル81は、番号フィールド82と設定対象情報フィールド83で構成されている。番号フィールド82はパーミッション設定内容73の先頭から何番目の2ビットかを示す番号であり、設定対象情報フィールド83はその2ビットがどの情報に対するパーミッションかを記述している。テーブル81はこのようにパーミッション設定内容73とテーブル81を組み合わせてどの情報にどのようなパーミッションが設定されているかを読み出す、もしくは書き込むことが可能となっている。

2ビットの2進数には、以下の4パターンのパーミッションを設定することが可能である。
１）公開設定52とRead設定53とWrite設定54すべてが拒否の設定、
２）公開設定52が許可でRead設定53とWrite設定54が拒否の設定、
３）公開設定52とRead設定53が許可でWrite設定54が拒否の設定、
４）すべてのパーミッションレベルが許可の設定、
例えば、上記１）の状態には設定値00を、上記２）には01を、上記３）には10を、上記４）には11を対応させることで、種々のパーミッションレベルの設定値を表現することが可能である。

また、本実施例では、パーミッションレベルとして、公開設定可否、Read可否、Write可否の３つの状態を想定しているが、パーミッションレベルをより細分化し、設定レベルを４つ以上にする場合であっても、2進数のビットで各レベルの状態を表現することが可能である。例えば、3ビットの2進数を用いれば、2³=8種類のパーミッションレベルの設定を行なうことができる。

新たなオブジェクト情報を追加する場合，参照用テーブル８１に新しくエントリを追加する。エントリを追加することで今まで利用していなかったインデックステーブル７１のパーミッション設定内容フィールド７３に示すビット列にオブジェクト情報に対するパーミッション設定を割当てることが出来る。逆にオブジェクト情報を削除する場合は参照用テーブル８１からエントリを削除する。エントリが削除されたビット列はパーミッション設定，パーミッション取得時に参照されることが無くなり，未使用ビット列となる。

以上、本実施例では、パーミッションの設定値に対し、上下関係の表現が可能な数値コードを与えることにより、パーミッションレベルの上下関係を考慮した管理を可能としている。
パーミッション設定テーブルは、バックアップ等の目的で、外部のデータベース等に保存しておくことができる。図９には、外部記憶手段に格納するためのパーミッション設定テーブルの形式を示した。テーブル91は公開ユーザ名フィールド92、閲覧ユーザ名フィールド93、パーミッション設定内容フィールド94から構成されており、テーブル61、71と同様の内容を記述する。テーブル81の設定対象情報については、例えば、サーバの設定ファイルにバックアップ等のために保存しておく方法がある。

図１０はプレゼンスサーバ1がユーザからのパーミッション設定要求を受信した時、図１のパーミッション設定内容整合部9で行う処理の内容を示したフローチャート図である。パーミッション設定内容整合部9はユーザからのパーミッション設定要求の内容から図４、図５に示した上下関係に矛盾しないパーミッション設定内容を計算し、設定内容の整合を行う処理ブロックである。このブロックの動作について説明する。

パーミッション設定内容整合部9は、ステップ101でユーザのパーミッション設定要求を受信するとステップ102で図２のプログラム格納部26からプログラム情報を取得し，処理を開始する。処理を開始するとまず、ステップ103でユーザからのパーミッション設定要求が図４、図５に示した上下関係と矛盾していないかをチェックする。もし矛盾を発見した場合、ステップ104でエラー出力を行い、ステップ119で処理を終了させ、ステップ120でユーザにパーミッション設定が失敗したことを示すメッセージを図１で示すパーミッション設定外部入出力部7に返信する。矛盾が無かった場合はステップ105でまずパーミッションを設定する。但し、一度に複数のオブジェクト情報に対するパーミッション設定要求があった場合、まずは一番始めに記述された設定について処理を行う。

次にステップ106で設定要求に従い設定を行ったパーミッションについて図５に示した処理単位での上下関係の整合性を取るため、図2に示す情報上下関係設定テーブル23から処理単位の情報上下関係テーブルを読み出して，処理単位での上位パーミッションをチェックする。例えば設定要求がWrite設定に対するパーミッション設定であればRead設定についてチェックを行う。しかし、設定要求が最上位の公開設定である可能性もあるので、ステップ107で設定要求が処理単位の最上位であるかをチェックする。

もし最上位であれば、ステップ111に進むが、最上位でなければステップ108に進み、チェック中処理単位と上位の処理単位の設定内容を比較する。ステップ108では、もし上位のパーミッション設定が拒否で、かつチェックしているパーミッション設定が許可であった場合、図５の上下関係に矛盾するので上位のパーミッションをステップ109で許可に設定する。矛盾が無ければこの処理は行わない。

次に、ステップ110でパーミッションのチェック対象を1階層上位に移動させる。例えば、現在Write設定をチェックしていたら、本ステップでチェック対象をRead設定に移動させる。その後はステップ106〜をもう一度実行して、最上位の公開設定まで処理をループさせる。最上位までチェックを終えると、ステップ107にてループが終了してステップ111に処理が進む。ちなみにこのステップ106〜ステップ110までの処理ループは図５に示す処理単位の上下関係を理解しながら行わなくてはならないが、上下関係についてはプレゼンスサーバ1のレジスタに予め設定されている。

ステップ111では図2に示す情報上下関係設定テーブル23から情報単位の情報上下関係テーブルを読み出して，さらに図2に示すパーミッション設定テーブル24から現在設定されているパーミッション情報を読み出して，今パーミッション設定をしているオブジェクト情報の設定内容とその上位のオブジェクト情報に現在設定されているパーミッションの内容との矛盾を整合する。現在パーミッション設定を行っているオブジェクト情報が図４に示す情報単位階層の最上位であるユーザＩＤである可能性があるので、まずステップ111で情報単位の最上位であるかをチェックする。もし現在設定しているオブジェクト情報が最上位であれば処理はステップ116に進む。

もしそうでなければ、ステップ113で現在パーミッション情報を設定しているオブジェクト情報と図４で示された上下関係図での上位のオブジェクト情報に設定されているパーミッション設定のRead設定を比較する。もし上位オブジェクト情報のRead設定が拒否で今設定したオブジェクト情報のRead設定が許可であった場合、上位のオブジェクト情報は閲覧を拒否しているのに下位のオブジェクト情報の閲覧を許可しているという矛盾した状態になるので、ステップ114で上位のオブジェクト情報の公開設定、Read設定を許可にする。これで上下関係の矛盾を整合できる。もしステップ113で条件に当てはまらなかったらステップ114の処理は行われない。

この処理が終了するとステップ115でパーミッションチェック対象を現在のオブジェクト情報の1階層上位のオブジェクト情報に移動させ、ステップ111からの処理を再度行い、最上位であるユーザＩＤにパーミッションチェック対象が移動するまで処理をループさせる。最上位までパーミッションチェック対象が移動するとステップ112からステップ116に処理が進む。ちなみにこのステップ111〜ステップ115までの処理ループは図４で示したオブジェクト情報単位の上下関係を理解しながら処理しなくてはならないが、その情報は図２のオブジェクト情報上下関係設定テーブル23に記憶されている。この設定はプレゼンスサーバ1の運用でユーザが関係を自由に設定することが可能である。

処理が進むとステップ116で全設定が終了したかをチェックする。ユーザからのパーミッション設定要求が複数のオブジェクト情報についてのみだった場合は、ステップ117に処理が進み、次に設定要求を読込み、その設定要求に対してステップ105からの処理を行う。すべての設定要求について処理を終えると、ステップ116からステップ118に処理が進み、整合したパーミッションの設定値を図2に示すメモリ22のパーミッション設定テーブル24に書き込む処理を行い、ステップ119で処理が終了する。その後、書き込み終了の通知を受信するとステップ120でユーザに対してパーミッション設定が成功したことを示すメッセージを返信するため，図1で示すパーミッション設定外部出力部7にメッセージを送信する。

図１１はプレゼンスサーバ1がユーザからのパーミッション取得要求を受信した時、図１のパーミッション出力内容計算部10で行う処理の内容を示したフローチャート図である。パーミッション出力内容計算部10はユーザからのパーミッション取得要求を図1に示すパーミッション設定外部入出力部7から受けて、図２のパーミッション設定テーブル24からパーミッション設定を読み出した後、その設定が図４、図５に示した上下関係に矛盾しないかを確認して、もし矛盾があればパーミッション設定内容を計算し、計算後のパーミッション設定内容をユーザに返信する処理ブロックである。

このブロックの処理方法について説明する。パーミッション出力内容計算部10はステップ131でユーザからパーミッション情報取得要求を図1に示すパーミッション設定外部乳流津力部7から受信すると、図2に示すプログラム格納部26から処理内容を読み出して，ステップ132で処理を開始する。処理を開始するとまず、ステップ133でパーミッション取得を要求してきたユーザが要求先のパーミッション設定を取得できるかをチェックする。もし取得権利がない場合、ステップ134に処理が進みエラー出力を行い、ステップ149で処理を終了し、ステップ150でパーミッション設定取得要求を送信したユーザに対して取得権利がないことを通知するために図1に示すパーミッション設定外部入出力部7にメッセージを送信する。ステップ133で権利があった場合はステップ135に処理が進む。ステップ135ではパーミッション設定テーブル24からパーミッション設定を読み出す。

また，上下関係の矛盾を計算するために図2に示す情報上下関係設定テーブル23から図4に示すような上下関係を読み出す。次にステップ136に進み、各オブジェクト情報に対する処理単位でのパーミッション設定に図５で示した上下関係に矛盾がないかチェックを行う。この時、複数のオブジェクト情報に対するパーミッション設定についてチェックを行う必要があるが、チェックを行う順番は図８のテーブル81の番号82の順番、つまり、図７のパーミッション設定内容73の最初の2ビットからパーミッション設定を読み出す。処理単位パーミッションチェックではまずステップ136でチェックを行う処理設定を最上位、つまり公開設定に移動させる。

次にステップ1001に進みチェック中の処理設定が最下位であるかどうかをチェックするが、1度目のループは最上位の公開設定をチェックしているので最下位ではなく、そのままステップ137に処理を進め、公開設定が拒否であるかどうかをチェックする。もし拒否であった場合はそれより下位、つまりRead設定、Write設定も当然拒否であるのでそのように設定する。もし許可であった場合は、ステップ138に処理が進み、パーミッションチェック対象を1階層下位に移動させる。例えば、現在チェック中の処理設定が公開設定なら1階層下位のRead設定にパーミッションチェック対象を移動させる。

その後処理をステップ1001に進め再開し、最下位の処理設定に移るまで処理をループする。もし処理が最下位となったらステップ1001からステップ140に処理が進む。ステップ140では全てのオブジェクト情報についてチェックが終了したかを見て、もし終了していなければステップ141に処理を進め、次のオブジェクト情報についての設定を読込み、ステップ136からの処理を行う。終了している場合、次のステップ142に処理を進める。ステップ142ではオブジェクト情報単位で図４に示した上下関係に矛盾がないかチェックを行う。この処理ではまずステップ143でチェックを行うオブジェクト情報をユーザＩＤに移動させる。

その後、ステップ1002でチェック中のオブジェクト情報が最下位であるかをチェックするが、現在のチェック中オブジェクト情報は最上位のユーザＩＤであるので、そのままステップ144に進み、チェック中のパーミッション設定のRead設定が拒否であるかどうかを見る。もし拒否であったら下位のオブジェクト情報についても見せる意思が無いと捕らえることが出来るので、ステップ146ですべての下位のオブジェクト情報に対して全処理設定の内容を拒否に設定する。

もしステップ144でRead設定が許可であった場合、処理はステップ145に進む。ステップ145ではパーミッションチェック対象を処理単位で下位に移動させる。但し、ユーザＩＤの下位に位置するオブジェクト情報は複数存在することがある。その場合は下位のオブジェクト情報を任意に選びそのオブジェクト情報にパーミッションチェック対象を移す。この時チェックした下位のオブジェクト情報は記憶しておく。その後ステップ144を再開し、最下位のオブジェクト情報をチェックするまで処理をループさせる。

最下位のオブジェクト情報のチェックに移動したとき、ステップ1002からステップ147に処理が進む。ステップ147では記憶されたチェック済みの下位オブジェクト情報から、図４のツリー構造の全ての枝についてチェックを行ったかを調査し、もし全ての枝についてチェックを行っていなかった場合、ステップ148に処理を進める。ステップ148ではまだチェックを行っていない枝のオブジェクト情報にパーミッションチェック対象を移動させる。その後処理はステップ1002に進みすべての枝についてパーミッションチェックが終了するまで処理をループさせる。ステップ147で全ての枝についてのパーミッションチェックが終了していたら、処理はステップ149に進み終了する。

その後、ステップ150でチェックを行ったパーミッション情報をユーザに返信するために図1で示すパーミッション設定外部入出力部7にメッセージを送信する。なお、パーミッション出力内容計算部10が行う図１１の処理は必須の処理ではない。パーミッション設定内容整合部9の処理を信頼し、さらにその他のパスでパーミッション設定がパーミッション設定テーブル24に書き込まれない保障があるなら図１１で示した処理フローを実行せず、パーミッション設定テーブル24から取得してきたパーミッション設定をそのままユーザに送信しても良い。ただ、図１１に示す処理フローを実行することで情報公開ユーザが意図しなかった情報が流出してしまう可能性をより低くすることが出来る。

図２８から図３０を用いてユーザが要求するパーミッション設定に対して図１で示すパーミッション設定内容整合部９がどのように整合性を取り，結果どのようなパーミッション設定が図２に示すパーミッション設定テーブル24に保存されるかを説明する。
図２８はUserAがプレゼンスサーバ1に現在登録しているオブジェクト情報である。最上位にはUserAのユーザID3101が位置し，UserAは3200で示すように携帯電話とPDAを所有している。よって，その下位に携帯電話のIDである電話番号3102が位置し，また同列でPDAのIDであるSIP-URI3105が位置する。さらに携帯電話はその下位に現在位置3103とそれと同列で電話中情報3104を持っている。また，PDAはその下位に受付通信形態3106とそれと同列で忙しさ3107を持っている。プレゼンスサーバ１ではUserAが登録するオブジェクト情報をこのように上下関係を持たせて保持している。

また，図２９は現在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から図２８に示す上下関係情報を読み出す。そこで，パーミッション設定要求のあった携帯電話の位置情報3103には上位オブジェクトとして，携帯電話の電話番号3102，及びユーザID3101が存在することを把握する。また，図２９に示す，現在設定されているパーミッション情報を図2に示すパーミッション設定テーブル24から読み出す。ユーザからのパーミッション設定要求では携帯電話の位置情報をread許可にするものであったので，その上位の携帯電話の電話番号3102の公開設定，read設定は図２８の3112に示すように公開拒否，read拒否であったが，公開許可，read許可に変更する。

また，さらに上位のであるユーザID3101も確認するが，3111に示すように元々設定が公開許可，read許可であったのでそのままにしておく。携帯電話の電話中情報3104，PDAのSIP-URI3105，PDAの忙しさ3106，PDAの通信形態3107は図２８で示す上下関係図からユーザがパーミッション設定を要求した携帯電話の位置情報とは関係の無い位置にある情報と分かるので，設定前の内容を書き換えない。

結果，ユーザからの設定要求後に図2に示すメモリ22のパーミッション設定テーブル24に登録されるパーミッション情報は図３０に示す内容となる。
図３０を見ると，UserAは携帯電話の位置情報パーミッションをread許可にする要求のみを行っていたが，図1に示すパーミッション設定内容整合部9が処理を行い，3213で示すように携帯電話の位置情報は公開許可のパーミッションが登録され，さらに3212で示すように携帯電話の電話番号には公開許可，read許可のパーミッションが登録されている。

図１２は、本実施例のプレゼンスサーバを用いたサービスモデルの１例である。図１２において154で示すUser Aはプレゼンスサーバ1に情報を登録して、家族情報通知サーバ152からサービスを受けるユーザである。このサービスは家族情報通知サーバがUser Aとその家族の現在情報を把握し、例えばUser Aとその家族が持つ図１６の位置情報216がお互いに近くなったら家族情報通知サーバからアラームを通知するようなサービスである。本１２では、プレゼンスサーバは通信キャリアが所有しており、家族情報通知サーバ152および情報配信サーバ153はサービス提供業者が所有しているとの前提で記載されているが、通信キャリアが家族情報通知サーバ152および情報配信サーバ153を保有しており、事業として本サービスを行なう場合もあり得る。

サービスモデル全体の動作を説明すると、まず154で示すUser Aは自分の情報と自分の情報公開設定をプレゼンスサーバ1に登録し、家族情報通知サーバ152にサービス提供要求を行い、情報配信サーバ153を経由してサービスを受信する。本サービスモデルのその他の応用例としては、家族全員が今欲しい物を登録しておき、それを売っている店に近づいた他の家族にそれを通知する等の応用が可能である。

図１４には、その具体的な動作シーケンスを示す。以下では、その動作について説明する。154で示すUser Aはまず、ステップ171で家族情報通知サーバ152にサービス登録要求を送信する。すると、家族情報通知サーバ152はステップ172で154に示すUser Aに公開可能な情報について問い合わせを行う。154で示すUser Aはそれに対してステップ173において自分が公開できる情報を家族情報通知サーバ152に登録する。なお，ステップ171から173までの処理はプレゼンスサーバを介さないで行われることが多い。

また、それと同時にステップ174においてプレゼンスサーバ1にもパーミッション設定を登録する。プレゼンスサーバ1は4で示すUser Aが登録してきた情報公開設定をステップ175でサーバ内部に保存する。また、家族情報通知サーバ152は4で示すUser Aの情報更新と更新された情報の内容について通知を受けるためにステップ176でUser Aの情報更新通知予約をプレゼンスサーバ1に対して行う。その後、4で示すUser Aは自分の情報の更新をステップ177でプレゼンスサーバ1に登録する。プレゼンスサーバ1は家族情報通知サーバ152からステップ176でUser Aの情報更新通知予約を受信してそれを享受しているので、家族情報通知サーバ152に対して更新通知を行おうとする。

この時、プレゼンスサーバ1はまず、4で示すUser Aが家族情報通知サーバ152に対して設定しているパーミッション設定をステップ178で確認する。その後、パーミッション設定でRead設定が許可であることを確認した情報のみをステップ179で家族情報通知サーバ152に通知する。この際、通知方法には更新された情報についてのみを通知する方法と更新されていない情報を含め4で示すUser Aが持つ情報をすべて通知する方法の2通りが存在するがそれについてはどちらの方法を用いてもかまわない。

図１６に、4で示すUser Aが持つ情報と家族情報通知サーバ152に通知される情報についての一例を示す。図１６では154で示すUser AはユーザＩＤ212、User Aが所持する端末1のＩＤ213、User Aが所持する2台目の端末2のＩＤ214、また端末2に付随する情報であるＯｎ／Ｏｆｆ215、位置216を保有しているとする。しかし家族情報通知サーバ152に対しては4で示すUser Aのユーザ情報212、214、215、216しか見えていない。User Aはパーミッション設定テーブル22に家族情報通知サーバ152に対して端末1のＩＤ213の公開設定を拒否と登録しており、プレゼンスサーバ1のパーミッション管理部3が端末1のＩＤ213を通知しなかったためである。

また、情報更新通知の方法が更新された情報のみを通知する方法の場合、その更新された情報が154で示すUser Aの家族情報通知サーバ152に対するパーミッション設定の公開設定、もしくはRead設定を拒否としていた場合にはステップ179の情報更新通知は行わない。154で示すUserAはプレゼンスサーバに自分の情報を登録し，プレゼンスサーバ1がパーミッション設定計算処理部3で情報のフィルタリングを行うことにより，図16で示すような家族情報通知サーバ152への情報配信が可能となる。

家族情報通知サーバ152はステップ179で4に示すUser Aの更新された情報を入手してステップ180でその更新された情報、また、他の更新されてない情報を含めて確認してサービス提供判断、その内容の判断を行う。その後、家族情報通知サーバ152はサービス配信を決定するとステップ181で情報配信サーバ153にサービスの配信要求を送信する。その後は情報配信サーバ153がステップ182において相手端末に合わせて動画や静止画、文字などの配信メディア、User Aの通信帯域に合わせたビットレート設定等を行い、ステップ183でUser Aに対してサービスを配信する。

しかし、家族情報通知サーバ152はステップ180で更新取得したUser Aの情報を確認してサービス配信をしないことを決定するとステップ181〜183までの処理は行なわず、次のUser Aの情報更新が通知されるまで待つ。また、このシーケンスにおいて家族情報通知サーバ152が配信サーバ153の機能を有することもある。この場合、ステップ181の処理は行われず、ステップ182、183の処理を家族情報通知サーバ152が行うこともある。

図１４は図１２の実施例をＳＩＰ（Session Initiation Protocol）／ＳＩＭＰＬＥ（SIP for Instant Messaging and Presence Leveraging Extensions）を用いて実現した例である。ＳＩＰ／ＳＩＭＰＬＥとはリアルタイム通信のセッション確立とプレゼンス情報の更新通知予約やそれに対する更新通知、ＩＭ等、マルチメディアコミュニケーションを行うために必要な機能を提供するプロトコルである。図１４のＳＩＰサーバ161はこのＳＩＰ／ＳＩＭＰＬＥに準拠したメッセージをルーティングし、目的の相手まで転送する機能を持つ。

図１５は図１4のシーケンスをＳＩＰ／ＳＩＭＰＬＥを用いて実現した適用例である。図１５ではＳＩＰ／ＳＩＭＰＬＥに加えてＨＴＴＰ（Hyper Text Transport Protocol）も用いてサービスを実現している。本シーケンスではサービス登録要求171、公開情報問い合わせ172、広報公開設定登録173をＨＴＴＰを用いた191、192、193で実現する。ここまでの処理はプレゼンスサーバ１を介さないで行われる。またパーミッション設定174はＳＩＭＰＬＥを適用してＭＥＳＳＡＧＥメソッド送信194でＳＩＰサーバ161を中継して実現している。メソッドとはＳＩＰ／ＳＩＭＰＬＥメッセージの一番始めの部分に記述する文字列であり、その文字列の確認によりそのＳＩＰ／ＳＩＭＰＬＥメッセージがどのような目的で送信されているかを判断することが可能となる。ちなみにＭＥＳＳＡＧＥメソッドは本来テキストベースＩＭの発言内容を送信するメソッドであるが、本願発明の装置ではパーミッション設定要求、取得要求ができるように拡張を行っている。

また、User Aの情報更新通知予約176はＳＩＭＰＬＥのＳＵＢＳＣＲＩＢＥメッセージ送信196でＳＩＰサーバ161を中継して実現している。次の情報更新177はＲＥＧＩＳＴＥＲメッセージ送信197でＳＩＰサーバ161を中継して実現している。ＲＥＧＩＳＴＥＲメソッドは本来ユーザのオンライン登録を行うメソッドであるが、これについても本願発明の装置ではこのメソッドを利用してユーザ情報の登録が出来るように拡張している。

その後のUser Aの情報更新通知179はＮＯＴＩＦＹメッセージ送信199でＳＩＰサーバ161を中継して実現する。ＮＯＴＩＦＹメソッドはこのようにＳＵＢＳＣＲＩＢＥで享受したユーザ情報更新通知予約に対して情報更新を通知するためのメソッドである。その後のサービス送信183についてはリアルタイム性の高い動画や音声での配信の場合はＳＩＰを利用してＩＮＶＩＴＥメッセージ送信後、User A154と情報配信サーバ153の間にセッションを張った後にＲＴＰプロトコルを利用してサービスを転送する。静止画やテキストベースの様にリアルタイム性が低い配信の場合はＳＩＭＰＬＥのＭＥＳＳＡＧＥメソッドを用いて文字情報を直接送信する方法で実現する。どちらの方法を取るにせよ、ＳＩＰサーバ161が中継してＳＩＰメッセージを転送する。

なお、本実施例のプレゼンスサーバによれば、パーミッション情報のみならず、論理的な上下関係を含むあらゆる情報群を適切に管理することが可能である。

図１７に、プレゼンスサーバを用いたビジネスモデルの第2の実施例を示す。図１７に224で示されるUser Aは、普段の買い物で○×デパートを利用することが多く、○×デパート購入履歴蓄積サーバ221にはUser Aの商品購入履歴が蓄積されている。また、User Aは図２１に示すユーザＩＤ272、ユーザに付随する情報として趣味273、年収274、端末のＩＤ276、端末に付随する情報としてＯｎ／Ｏｆｆ277、位置278をプレゼンスサーバ1に登録しており、店舗情報配信サーバ222からサービスを受けるユーザである。全体の動作を説明するとまずUser A224は自分のユーザ情報と店舗情報配信サーバ222に対するパーミッション設定をプレゼンスサーバ1に登録している。また、店舗情報配信サーバ222にサービス提供要求を行い、情報配信サーバ223を経由してサービスを受信する。

図１９はその動作シーケンスである。このシーケンスを用いて具体的な動作について説明する。224で示すUser Aはまず、ステップ231で○×デパート購入履歴蓄積サーバ221に自分の情報を登録する。この情報登録とはネットワーク上のメッセージで登録する情報ではなく224で示すUserAが○×デパートで買い物を行った結果，221で示す○×デパートの購入履歴蓄積サーバにUserAの購入履歴が蓄積されていったことを示す。よって，図17，及び図18で示す224に示すUserAから221で示す○×デパートまでの矢印もネットワーク上のメッセージを示すのではなく，このように物理的に買い物等を行うことにより情報が蓄積されることを示している。○×デパート購入履歴蓄積サーバ221はその履歴をステップ232でプレゼンスサーバに登録する。

User Aはステップ233により店舗情報配信サーバ222にサービス登録要求を送信する。すると、店舗情報配信サーバ222はステップ234によりUser Aに公開可能な情報について問い合わせを行う。User Aはそれに対してステップ235において自分が公開できる情報を店舗情報配信サーバ222に登録する。ステップ233から235までの処理はプレゼンスサーバを介さずに行われることが多い。また、それと同時にステップ236においてプレゼンスサーバ1にも店舗情報配信サーバ222に対するパーミッション設定を登録する。

プレゼンスサーバ1はUser Aが登録してきたパーミッション設定をステップ237でサーバ内部に保存する。また、店舗情報配信サーバ222はUser Aの情報更新の内容について通知を受けるためにステップ238でUser Aの情報更新通知予約をプレゼンスサーバ1に対して行う。その後、User Aは自分の情報の更新をステップ239によりアプリケーションサーバ1に登録する。プレゼンスサーバ1は店舗情報配信サーバ222からステップ238でUser Aの情報更新通知予約を受信してそれを享受しているので、ステップ240でUser Aが店舗情報配信サーバ222に対して設定したパーミッションを確認後、Read設定が許可であるユーザ情報についてのみステップ241で店舗情報配信サーバ222にUser Aの情報更新を通知する。この際、通知方法には更新された情報についてのみを通知する方法と更新されていない情報を含めUser Aが持つ情報をすべて通知する方法の2通りが存在するがそれについてはどちらの方法を用いてもかまわない。

図２１に、User Aがプレゼンスサーバ1、および○×デパート購入履歴蓄積サーバ221に登録、更新する情報と店舗情報通知サーバ222が受信するUser Aについての情報の一例を示す。図２１ではUser AはユーザＩＤ272、ユーザに付随する情報として趣味273、年収274、○×デパートの購入履歴274、User Aが所持する端末1のＩＤ276、端末1に付随する情報としてＯｎ／Ｏｆｆ277、位置278を保有している。しかし、店舗情報配信サーバ222はUser Aの年収情報に関して公開拒否281を受信している。これは、User Aが店舗情報配信サーバ222に対して年収のRead設定を拒否にしたパーミッション情報をプレゼンスサーバ1に登録していたからである。また、情報更新通知の方法が更新された情報のみを通知する方法の場合、その更新された情報の店舗情報配信サーバ222に対するパーミッションが公開設定、もしくはRead設定拒否であった場合、ステップ241の情報更新通知は行われない。

店舗情報配信サーバ222はステップ241でUser Aの更新された情報を入手してステップ242でその更新された情報、また、他の更新されてない情報を含めて確認してサービス提供判断、その内容の判断を行う。その後、店舗情報配信サーバはサービス配信を決定するとステップ243で情報配信サーバ223にサービスの配信要求を送信する。その後は情報配信サーバ223がステップ244において相手端末に合わせて動画や静止画、文字などの配信メディア、User Aの通信帯域に合わせたビットレート設定等を行い、ステップ245でUser Aに対して例えばUser Aの現在位置のすぐ近くにある店舗情報やその店舗のサービスクーポンなどのサービスを配信する。

この時、店舗情報配信サーバ222はステップ241で更新取得したUser Aの情報を確認してサービス配信をしないことを決定するとステップ243〜245までの処理は行なわず、次のUser Aの情報更新が通知されるまで待つ。また、このシーケンスにおいて店舗情報配信サーバ222が配信サーバ223の機能を有することもある。この場合、ステップ243の処理は行われず、ステップ244、245の処理を店舗情報配信サーバ222が行うこともある。

図１８は、図１７の実施例をＳＩＰ（Session Initiation Protocol）／ＳＩＭＰＬＥ（SIP for Instant Messaging and Presence Leveraging Extensions）を用いて実現した例である。また、図２０は図１９のシーケンスをＳＩＰ／ＳＩＭＰＬＥとＨＴＴＰを用いて実現した例である。図２０を用いて図１８の具体的な動作について説明する。図１９ではUser Aの購入履歴登録232をＳＩＰのＲＥＧＩＳＴＥＲメッセージ送信252を用いてＳＩＰサーバ161を中継して実現している。次に、サービス登録要求233、公開情報問い合わせ234、公開情報登録235については253、254、255のステップでＨＴＴＰを利用して実現している。また、パーミッション設定登録236はＭＥＳＳＡＧＥメッセージ送信256でＳＩＰサーバ161を中継して実現する。

次のUser Aの情報変更通知予約238はＳＵＢＳＣＲＩＢＥメッセージ送信258でＳＩＰサーバを中継して実現する。ユーザ情報更新239は232と同様ＲＥＧＩＳＴＥＲメッセージ送信259を利用してＳＩＰサーバ中継により実現する。情報更新通知241についてはＮＯＴＩＦＹメッセージ送信261でＳＩＰサーバを中継して実現する。また最後のステップであるサービス配信245はステップ265で動画などのリアルタイム性の高いメディア配信の場合はＩＮＶＩＴＥメッセージ送信後、セッションが張れた後にＲＴＰでサービス送信する。静止画、テキスト等リアルタイム性の低い配信の場合はＭＥＳＳＡＧＥメソッド送信により実現する。どちらの方法を取ってもＳＩＰメッセージはＳＩＰサーバ161を中継して転送される。

図２２は、プレゼンスサーバを用いたビジネスモデルの第3の実施例を示す。User A301はプレゼンスサーバ1に図２５のユーザＩＤ312、ユーザに付随する情報として趣味313、年収314、User Aが所有する端末1のＩＤ315、端末1に付随する情報としてＯｎ／Ｏｆｆ316、位置317を登録している。また、User B302はUser Aの情報更新通知の予約を行い、User Aの現在状態を把握しているユーザである。図２４この実施例の動作シーケンス図である。この実施例の具体的な動作を図２４で説明する。まず、User Aはステップ321で趣味313をプレゼンスサーバ1に登録する。プレゼンスサーバ1は趣味313をデータベースサーバＡ303−1に保存する設定としているので、ステップ322でこれをデータベースサーバＡ303−1に登録する。

次にUser Aはステップ323で端末1に付随する位置316をプレゼンスサーバ1に登録する。プレゼンスサーバ1は位置316をデータベースサーバＢ303−2に保存する設定としているので、ステップ324でUser Aの位置316をデータベースサーバＢ303−2に登録する。その後User Aはステップ325でUser Bに対するパーミッション設定をプレゼンスサーバ1に登録する。するとプレゼンスサーバ1はステップ326でUser AのUser Bに対するパーミッション設定を記憶する。

その後、User BがUser Aの情報更新を知るためにプレゼンスサーバ1に対してステップ327でUser Aの情報更新通知予約を送信する。そこでプレゼンスサーバ1はステップ328でUser AがUser Bに対して設定したパーミッションをまず確認してRead設定が許可のユーザ情報についてのみUser Bに通知を行う。そのためにプレゼンスサーバ1はReadが許可された情報のみをステップ329と330でデータベースサーバＡ303−1とデータベースサーバＢ303−2からUser Aのユーザ情報を読み出し、ステップ331でUser Bに通知を行う。

この時、もしユーザＩＤの公開設定、もしくはRead設定が拒否である場合は通知できるユーザ情報が無いのでステップ331では権利が無いことを返信してこの動作シーケンスは終了する。その後、User Aがステップ332で例えば位置情報と趣味を更新するとプレゼンスサーバ1はステップ333、334でそれぞれのユーザ情報を保存しているデータベースサーバＡ303−1、データベースサーバＢ303−2に保存、また、ステップ335でUser AがUser Bに対して設定しているパーミッション情報を確認してRead設定が許可のユーザ情報をステップ336でUser Bに通知する。

図２５の302を見るとUser Bに通知されるUser Aの情報の内ユーザに付随する年収351、端末1に付随する位置352は公開拒否となっている。これはUser AがUser Bに対して年収と位置のRead設定が拒否のパーミッション設定をパーミッション設定テーブル24に登録しており、プレゼンスサーバ1のパーミッション制御部3が公開拒否通知を判断したためである。
また、図２３は図２２の実施例をＳＩＰ／ＳＩＭＰＬＥで実現した例である。2つの図面ではプレゼンスサーバ1からデータベースサーバＡ303−1、データベースサーバＢ303−2の間のインターフェースは同様であるが、図２３ではUser A301からプレゼンスサーバ1、User B302からプレゼンスサーバ1へのインターフェースがＳＩＰ／ＳＩＭＰＬＥのＲＥＧＩＳＴＥＲ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＭＥＳＳＡＧＥメソッドを利用したメッセージをＳＩＰサーバ161が中継する形となっている。

実施例４では、プレゼンスサーバの別な構成例について説明する。図２６は、図２とは別構造のプレゼンスサーバを示した模式図である。本実施例のプレゼンスサーバは、公開ユーザ名と閲覧ユーザ名とパーミッションの設定値とをひとつにまとめたエントリテーブルを使用している。つまり、図９に示したエントリテーブルと同じエントリテーブルを使用している。本方式のエントリテーブルは、公開ユーザ名フィールド、閲覧ユーザ名フィールドおよびパーミッションの設定値フィールドとが一つのエントリテーブルにまとめられているため、図６，７のようにエントリテーブルを分けた場合に比べ、パーミッションの設定内容からユーザ名を検索する逆引きがやりやすいという利点を持つ。

但し、エントリテーブルのデータサイズが大きくなるため、図２に示した実施例のようにメモリに全データを格納するのは不可能で、通常は外部記憶装置2002に格納しておき、必要な部分のみをメモリ空間上に展開して、パーミッションの設定処理を行っている。2001はディスクインタフェースであり、外部記憶装置2002とプレゼンスサーバ本体とを接続する。また、パーミッション設定内容を解釈するための参照用テーブル（図８と同じテーブル）は、本実施例においても必要であり、このため、本実施例のプレゼンスサーバは、参照用メモリを格納するためのキャッシュメモリ2003を備えている。

実施例５では，実際の利用シーンにおけるパーミッション変更手順と，それによる効果を説明する。図３１でUserAはUserBと会社の同僚であるとする。また，UserAは4001に示すPDAの端末1と4002に示す端末２を所有しており，SIPサーバ161を経由してプレゼンスサーバ1にプレゼンス情報，及びパーミッション情報を登録しているとする。図３１ではプレゼンスサーバへのアクセスをSIPサーバ経由で行うモデルであるが，図３２に示すように，SIPサーバ161を介さずに直接プレゼンスサーバ1と通信を行う形態も考えられる。この場合、プレゼンスサーバ１がSIPのセッション制御機能を有しているか、あるいはUserAとUserB間の通信がSIPを用いない形態であるかのいずれかである。例えば、HTTPやInstant Messaging等である。

図３１で示すネットワーク図でどのようなメッセージが送受信されるかについて図３３に示すシーケンス図を用いて説明する。このネットワーク上ではIETFで標準化されたRequest For Comment(RFC)3261で示される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のプレゼンス情報すなわちオブジェクト情報を通知する為にNOTIFYメッセージをステップ4013でUserBに送信する。NOTIFYメッセージもSUBSCRIBEと同様，RFC3265で規定されたメソッドであり，メッセージ内部にオブジェクト情報を記述する為のメソッドである。このNOTIFYメソッドではUserAが所有する端末1(4001)，端末2(4002)両方のオブジェクト情報が送信される。

図３４には、パーミッション設定に基づきUserA からUserBへ開示されるオブジェクト情報を、UserAが持っている全オブジェクト情報と対比して示す。4030〜4036で示される各項目が、UserAが持っているオブジェクト情報である。実際には、UserAの持つオブジェクト情報は、プレゼンスサーバ内に登録されている。パーミッションの設定情報は、プレゼンスサーバ内のパーミッション管理部に保持される。一方、図２に示した構成のプレゼンスサーバの場合には、パーミッションの設定情報は、メモリ内のパーミッション設定テーブルに格納されている。

また、図３６には、ステップ4013のNOTIFYメッセージがUserBに届いた時点でUserAがUserBに対して設定しているパーミッションを示す。図３６によれば、UserBに対しては、UserAの持つすべてのオブジェクト情報に対しパーミッションが公開許可に設定されている。よって図３４に示す4030〜4036すべてのオブジェクト情報がそのままUserBに通知される。

次に，図３３のシーケンス図の後半部分を説明する。UserAが端末1(4001)のオブジェクト情報を4014で変更すると，プレゼンスサーバ1はUserAのオブジェクト情報が変化したことをUserBにステップ4015でNOTIFYメッセージを用いて通知する。これはステップ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でパーミッション設定の整合性を取り，登録を行う。図３７には、ステップ4019のパーミッション設定登録の結果登録されたパーミッション設定を示す。UserAからの設定変更要求の中に携帯電話のパーミッションを非公開にする要求が入っているので、携帯電話番号の公開設定が拒否に変わり，さらにその下位のread設定もプレゼンスサーバ1により整合され，自動的に拒否に設定される。

図３５には、変更後のパーミッション設定に基づきUserBへ開示されるUserAのオブジェクト情報を示す。端末1の情報でUserBに対して公開される情報は、端末1のID4031とメールアドレス4033のみで、アベイラビリティ4032は非公開になっている。また、端末2に関するオブジェクト情報は一切開示されない。

図３８は、図３１に示されるサービスで使用されるオブジェクト情報の上下関係を示す図である。図３８の上下関係図より携帯電話の位置情報，電話中情報もプレゼンスサーバ1により整合され，自動的に公開拒否，read拒否に設定される。また，PDAのアベイラビリティは図３８により最下位のオブジェクトであることが分かるので，そのほかのパーミッション設定との整合性を確認するが，自動的なパーミッション設定変更は行われない。

UserAがパーミッション設定を変更した直後，プレゼンスサーバ1はステップ4020でUserBの端末4003に対して，パーミッション設定で許されているオブジェクト情報，つまりメールアドレス情報のみをNOTIFYメッセージで送信する。その後，プレゼンスサーバ1はUserAがプレゼンスを更新しても，それがUserBに対してパーミッションを与えていないものであった場合，UserBに状態変更通知は送らなくなる。たとえばUserAがステップ4021で携帯電話のプレゼンスを変更したとしてもUserBにはその変更通知が送信されない。但し，ステップ4022の様に公開しているオブジェクト情報を更新した場合にはステップ4023の様にNOTIFYメッセージでオブジェクト情報が送信される。

図３９〜図４１は、図３３のステップ4018において、実際どのようにパーミッション設定要求が送信されているかを説明する図である。実際にパーミッション設定を要求するメッセージは図３９の4220に示す様なSIPプロトコルとIPを利用したパケットで構成する。4221はIPパケットのIPアドレスを示す部分であり，IPプロトコルがIPv4かIPv6かによりIPv4アドレス，もしくはIPv6アドレスが記述される。4222はトランスポート層の記述であり，トランスポート層にTCP/UDPどちらを利用しても，送信元ポート番号，送信先ポート番号が記述される。

実際のＳＩＰプロトコルのデータが記述されている部分は4223で示されるペイロード部分である。この部分をさらに詳しく記述した分が4224〜4226である。SIPメッセージはメッセージ種別を記述したSIPリクエストライン4224，メッセージの設定を記述したSIPヘッダ4225，実際のデータを記述したSIPメッセージボディ4226により構成される。本実施例では図４０に示す様にIETF Request For Comment(RFC)3428で規定されたInstant Messaging用のメソッドであるMESSAGEメソッドを用いて設定要求を送信する。

また，パーミッション設定の取得時も同様にMESSAGEメソッドを用いる。MESSAGEメソッドを用いたSIPメッセージには図４１に示すようなeXchange Markup Langage(XML)を用いてプレゼンスサーバ1に対する要求を記述する。パーミッション設定，取得要求はSIPメッセージボディ部にXML以外の記述形式，またはXMLでも異なるスキーマ(文法)の記述で行ってもよい。この時，図４０の4232に示すContent-TypeヘッダにSIPメッセージボディの記述形式を記述する。また，4233に示すContent-LengthヘッダにはSIPメッセージボディの容量をbyte単位で記述する。上記ヘッダについてはIETF Request For Comment(RFC)3261に利用方法についての記述がある。

次に図４１に示すSIPメッセージボディ部のXMLスキーマについて説明する。図４１の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(許可)の設定となっている。たとえば図４１の設定を見るとビット列は000 100となっている。これは1つ目のオブジェクトである携帯電話については000，つまり公開=拒否，read=拒否，write=拒否の設定が記述されていることが分かる。

また2つ目のオブジェクトであるPDAのアベイラビリティについては100，つまり公開=許可，read=拒否，write=拒否の設定が記述されていることが分かる。また，本実施例ではflag要素でwrite操作を定義しているが，flag要素は設定したい操作についての記述のみ行えばよく，たとえばread操作に対するパーミッション設定のみ行いたい場合，flag要素はread操作分のみとすることが可能である。
このようなメッセージの受信をトリガーにしてプレゼンスサーバ１はパーミッション設定の整合性調査，設定内容の補完，登録を行う。

本願発明におけるパーミッション設定方式を適用した装置の機能ブロック図である。 本願発明におけるパーミッション設定方式を適用した装置図である。 本願発明装置で取り扱うユーザ情報の階層構造を示した図である。 本願発明装置で行うパーミッション設定のユーザ情報単位での階層構造を示した図である。 本願発明装置で行うパーミッション設定の処理単位での階層構造を示した図である。 本願発明装置が記憶するパーミッション設定のテーブル図である。 本願発明装置が記憶するパーミッション設定のテーブル図である。 本願発明装置が記憶するパーミッション設定のテーブル図である。 本願発明装置が外部に記録するパーミッション設定のテーブル図である。 本願発明装置がパーミッションを設定するときの処理フローチャート図である。 本願発明装置がパーミッションを読出しするときの処理フローチャート図である。 本願発明装置を用いたサービスのネットワーク図である。 本願発明装置を用いたサービスのＳＩＰサーバを用いた時のネットワーク図である。 本願発明装置を用いたサービスの動作シーケンス図である。 本願発明装置を用いたサービスのＳＩＰサーバを用いた時の動作シーケンス図である。 本願発明装置を用いたサービスで伝達されるユーザ情報を示した図である。 本願発明装置を用いたサービスのネットワーク図である。 本願発明装置を用いたサービスのＳＩＰサーバを用いた時のネットワーク図である。 本願発明装置を用いたサービスの動作シーケンス図である。 本願発明装置を用いたサービスのＳＩＰサーバを用いた時の動作シーケンス図である。 本願発明装置を用いたサービスで伝達されるユーザ情報を示した図である。 本願発明装置を用いて複数のデータベースサーバを取り扱った場合のネットワーク図である。 本願発明装置を用いて複数のデータベースサーバを取り扱いＳＩＰサーバを利用した場合のネトワーク図である。 本願発明装置を用いて複数のデータベースサーバを取り扱った場合の動作シーケンス図である。 本願発明装置を用いて複数のデータベースサーバを取り扱った場合の伝達される情報を示した図である。 本願発明の情報管理装置の第２の実施形態である。 Ｕｎｉｘファイルシステムにおけるパーミッションの管理方式を説明する図である。 実施例１において、UserAがプレゼンスサーバに登録しているオブジェクト情報の階層構造を示す図。 実施例１において、UserAがUserBに対して設定しているパーミッションを示す図。 実施例１において、UserAが設定変更を行なった後のパーミッションを示す図。 発明が適用されるサービスが実施されるネットワーク構成図である。 発明が適用されるサービスが実施されるネットワーク構成図である。 図２８のネットワークで送受信されるメッセージのシーケンス図である。 UserAとUserBが持つプレゼンス情報とパーミッションの関係を示す図である。 UserAとUserBが持つプレゼンス情報とパーミッションの関係を示す別の図である。 パーミッションの設定例を示す図である。 パーミッションの設定例を示す図である。 図２８に示されるサービスで使用されるオブジェクト情報の上下関係を示す図である。 パーミッション設定を要求するＳＩＰパケットのフォーマットである。 図３６に示すＳＩＰパケットのボディ部分に格納されるMessageの一例である。 ＳＩＰメッセージボディ部のXMLスキーマを示す図である。

符号の説明

１・・・プレゼンスサーバ、２・・・パーミッション情報制御部、３・・・パーミッション管理部。

Claims (3)

1. ユーザの端末と他の端末とにネットワークを介して接続されるサーバであって、 ユーザの端末の識別情報及び該端末の話中情報及び該端末の位置情報のうち少なくともいずれか一方を記憶する記憶手段と制御部と、を有し、
   上記記憶手段はさらに、該端末の識別情報の他の端末への開示可否を示す開示可否情報と該端末の前記話中情報または位置情報の他の端末への開示可否を示す開示可否情報との間の上下関係と、該端末の識別情報と前記話中情報または位置情報とのそれぞれの開示可否の設定値を記憶しており、
   上記上下関係は、上記端末の識別情報の開示可否情報が上位、上記端末の前記話中情報または位置情報の開示可否情報が下位であり、
   前記制御部は、
   上記端末の前記話中情報または位置情報の上記設定値が開示否から開示可に変更された場合は、上記端末の識別情報の上記設定値を開示可に変更し、
   また、上記端末の識別情報の上記設定値が開示可から開示否に変更された場合は、上記端末の前記話中情報または位置情報の上記設定値を開示否に変更することを特徴とするサーバ。
2. 請求項１記載のサーバであって、
   前記開示可否の設定値を、当該情報に対する公開の可否、当該情報に対する読出し可否、当該情報に対する書き込み可否の３種に分類して管理することを特徴とするサーバ。
3. 請求項２に記載のサーバであって、
   前記３種の設定値に階層構造をもたせて管理しており、
   前記公開の可否は、前記読出し可否よりも上位の設定値であり、
   前記読み出し可否は、前記書き込み可否よりも上位の設定値であり、
   前記設定値のうち下位の設定値が否から可に変更された場合は、該下位の設定値よりも上位の設定値を可に変更し、
   また、上記設定値のうち上位の設定値が可から否に変更された場合は、該上位の設定値
   よりも下位の設定値を否に変更することを特徴とするサーバ。

Images