JP4119879B2 - アクセス要求処理方法及び装置 - Google Patents

Description

本発明は、ユーザ間のコミュニケーションや情報の公開を行う場合に、サービスの柔軟性及びユーザの利便性を高める技術に関する。

従来、公開情報へのアクセス制御及びユーザ間のコミュニケーションにおけるアクセス制御の技術は、アクセス制御リスト（Access Control List、以下ＡＣＬと称す）を用いて行われている。ＡＣＬには、リソースや相手ユーザへのアクセスを許可するか否かが設定されている。ＡＣＬは、元来、分散オペレーティングシステムやネットワークリソースの管理に用いられる。ＡＣＬの目的は、アクセス要求者の本人認証に基づいて、ファイルやネットワークサービスなど固定的なリソースへのアクセスを制御するところにある。具体的には、ＡＣＬは、ファイルなどのリソースに対するアクセス、たとえばread/writeに対してユーザ毎、あるいはユーザが属するグループ毎に許可・不許可を指定するテーブルである。ＡＣＬの基本的な例を、図１４に示す。ＡＣＬは、設定が単純であるという利点を持ち、ファイルアクセスやＷＷＷ(World Wide Web) のページの取得、ディレクトリサーバからのデータ取得等のアクセス制御技術として広く用いられている。

しかし、ＡＣＬに基づくアクセス制御は、コミュニケーションやプライバシー情報へのアクセスなど、人間が背後にいることを前提としたアクセスに対する制御には不十分である。なぜなら、ＡＣＬが基本的に許可・不許可という２値の判断を前提としていることと、要求者側の属性のみに従った判断規則しか取り扱わないからである。
例えば、ユーザ間のコミュニケーションを要求する場合、被要求者の現在の状態に従って応対が変化する方が便利である。重要度の高い仕事に集中している時には普通のコミュニケーション要求に対しては拒絶をしたり、代理エージェントに任せたい要求がある。しかし、同じ状態にある場合でも、上司からのコミュニケーション要求に対しては答えなければならないかもしれない。また、被要求者の状態に、出張中の所在情報や連絡先などの情報を含め、必要に応じて適切な手段で適切な転送先に要求を転送したい場合も考えられる。

さらに、公開情報に対するアクセス制御についても、リソースに関連する利用者の状態に応じ、提供する情報を柔軟に変化させたい場合がある。例えば、オンライン顧客ヘルプデスクのような情報提供サービスにおいては、問合せを行う顧客情報および問合せを受ける担当者の現在状態に応じた対応を行いたい。得意先からの問い合わせに対しては忙しい場合でも担当者につなぐ。一方、初めての顧客からの問い合わせは、他の問い合わせ先に転送する、すぐ応対できる適切な担当者へ問合せをつなぐ、しばらくお待ち下さいなどのメッセージを提供するなどである。

本発明は、利用者間のコミュニケーションや情報の公開等のサービスの提供をネットワークを介して行う場合に、プライバシーや心理的・物理的状態など人が関わることで生じる特有の問題を解決する、アクセス要求処理方法及びアクセス要求処理システムを提供することを目的とする。

本発明は、ネットワークを介したユーザ間のコミュニケーションにおいて、アクセスする側のさまざまな属性やアクセスされる側の心理的状態及び物理的状態に応じた柔軟なアクセス権限の付与を可能にする。また、情報提供サービスにおいては、要求対象に関連するユーザの現在状態に応じて柔軟にサービスを提供することを可能にする。すなわち、本願第１発明は、要求に応じて他の情報端末に情報を提供する情報提供装置に用いられるアクセス要求処理方法であって、
Ａ；前記情報提供装置は、前記情報に関連する利用者の状態を前記情報毎に蓄積し、
Ｂ；前記情報提供装置は、前記情報を要求する利用者と、情報に関連する他の利用者の状態と、要求対象情報と、に応じた前記情報要求に対する処理動作が前記情報毎に設定された処理ポリシーを記憶し、
Ｃ；前記情報提供装置は、前記いずれかの情報に対する要求が生じた場合、前記要求対象情報の処理ポリシーに基づいて前記要求に対する処理動作を決定し、
Ｄ；前記情報提供装置は、前記決定した処理動作に基づいて、前記要求に対する処理を制御する、
アクセス要求処理方法を提供する。

予め、各情報リソース、情報を要求する利用者及び情報リソースに関連する他の利用者の状態に応じ、情報の要求に対する処理が設定された処理ポリシーを、各情報リソース毎に準備しておく。情報の要求が発生すると、要求対象の情報リソースに関するポリシーを参照し、要求に対する処理を決定する。処理とは、例えば"情報の要求を認める"、"断る"、"要求された情報の一部にメッセージを埋め込んで提供する"、"情報リソースに関連する利用者に問い合わせる"などである。処理を決定するために、必要に応じ、情報リソースに関連する他の利用者の状態を参照する。例えば、ホームページ"ＵＲＬ１"のポリシーに、「"ユーザＡ"からの要求に対しては、ホームページの作成者が"多忙"であればＵＲＬ１ａのホームページを提供する」と設定されているとする。利用者ＡからＵＲＬ１の要求があった場合、ホームページの作成者の状態が"多忙"であるか否かを判断する必要がある。そこで担当者の状態を参照し、要求に対する処理を決定する。このように、情報リソースへのアクセス要求に対し、要求者のみならず情報リソースに関連する利用者の状態をも考慮することにより、柔軟なサービスが提供可能になる。

本願第２発明は、要求に応じて他の情報端末に情報を提供する情報提供装置に用いられるアクセス要求処理システムであって、第１蓄積手段と、第２蓄積手段と、第３蓄積手段と、認証手段と、連携手段と、決定手段と、情報登録手段と、状態登録手段と、ポリシー登録手段とを備えたアクセス要求処理システムを提供する。
第１蓄積手段は、前記情報を要求する要求者に関する情報を蓄積する。第２蓄積手段は、前記要求対象の情報に関連する利用者の状態を蓄積する。第３蓄積手段は、前記情報の要求者と、前記情報に関連する利用者の状態と、要求対象情報とに応じた前記情報の要求に対する処理が、前記情報毎に設定された処理ポリシーを蓄積する。認証手段は、前記情報提供の要求が生じた場合、前記情報提供の要求者を確認する。連携手段は、前記情報提供装置から前記要求者及び要求対象情報を獲得する。決定手段は、前記連携手段が獲得した要求対象情報に基づいて前記処理ポリシーを取得し、前記要求者の確認結果及び前記取得した処理ポリシーに基づいて前記要求者に関する情報及び前記要求対象情報に関連する利用者の状態を参照し、前記要求に対する処理を決定し前記情報提供装置に通知する。

情報登録手段は、前記要求者に関する情報の入力を受け付け、前記第１蓄積手段に登録する。状態登録手段は、前記情報に関連する利用者の状態の入力を受け付け、前記第２蓄積手段に登録する。ポリシー登録手段は、前記処理ポリシーの設定を受け付け、前記第３蓄積手段に登録する。
予め、各情報リソース、情報を要求する利用者及び情報に関連する他の利用者の状態に応じ、情報の要求に対する処理が設定されたポリシーを準備しておく。情報の要求が発生すると、要求対象の情報リソースに関するポリシーを参照し、要求に対する処理を決定する。処理を決定するために、必要に応じ、第１及び第２蓄積手段の情報を参照する。例えば、ホームページ"ＵＲＬ１"のポリシーに、「社名が"Fujitsu"の要求者であれば、ホームページの担当者が"多忙"である場合ＵＲＬ１ａのホームページを提供する」と設定されているとする。この場合、利用者ＡからＵＲＬ１の要求があった場合、利用者Ａの社名が"Fujitsu"か否か、担当者の状態が"多忙"であるか否かを判断する必要がある。そこで、利用者Ａに関する情報及び担当者の状態を参照し、要求に対する処理を決定する。

本願第３発明は、要求に応じて他の情報端末に情報を提供する情報提供装置に用いられるアクセス要求処理装置であって、第１蓄積手段と、第２蓄積手段と、第３蓄積手段と、認証手段と、連携手段と、決定手段とを備えるアクセス要求処理装置を提供する。
第１蓄積手段は、前記情報を要求する要求者に関する情報を蓄積する。第２蓄積手段は、前記要求対象の情報に関連する利用者の状態を蓄積する。第３蓄積手段は、前記情報の要求者と、前記情報に関連する利用者の状態と、要求対象情報とに応じた前記情報の要求に対する処理が、前記情報毎に設定された処理ポリシーを蓄積する。認証手段は、前記情報提供の要求が生じた場合、前記情報提供の要求者を確認する。連携手段は、前記情報提供装置から前記要求者及び要求対象情報を獲得する。決定手段は、前記連携手段が獲得した要求対象情報に基づいて前記処理ポリシーを取得し、前記要求者の確認結果及び前記取得したポリシーに基づいて前記要求者に関する情報及び前記要求対象情報に関連する利用者の状態を参照し、前記要求に対する処理を決定し前記情報提供手段に通知する。

本願第４発明は、要求に応じて他の情報端末に情報を提供する情報提供装置とネットワークを介して接続された、前記情報端末に用いられるアクセス権限設定装置であって、情報登録手段と、状態登録手段と、ポリシー登録手段とを備えたアクセス権限設定装置を提供する。
情報登録手段は、前記情報の提供を要求する利用者に関する情報の入力を受け付け、前記情報提供装置に送信する。状態登録手段は、前記情報に関連する利用者の状態の入力を受け付け、前記情報提供装置に送信する。ポリシー登録手段と、前記情報の要求者と、前記情報に関連する利用者の状態と、要求対象情報とに応じた前記情報の要求に対する処理が、前記情報毎に設定されたポリシーの設定を受け付け、前記情報提供装置に送信する。

本願第５発明は、要求に応じて他の情報端末に情報を提供する情報提供装置に用いられる、アクセス要求処理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、下記Ａ〜Ｇ段階を実行させるためのアクセス要求処理プログラムを記録した、コンピュータ読み取り可能な記録媒体を提供する。
Ａ；前記情報を要求する要求者に関する情報を蓄積する段階、
Ｂ；前記要求対象情報に関連する利用者の状態を蓄積する段階、
Ｃ；前記情報の要求者と、前記情報に関連する利用者の状態と、要求対象情報とに応じた前記情報の要求に対する処理が、前記情報毎に設定された処理ポリシーを蓄積する段階、
Ｄ；前記情報提供の要求が生じた場合、前記情報提供の要求者を確認する段階、
Ｅ；前記情報提供装置から前記要求者及び要求対象情報を獲得する段階、
Ｆ；前記連携手段が獲得した要求対象情報に基づいて前記処理ポリシーを取得し、前記要求者の確認結果及び前記取得したポリシーに基づいて前記要求者に関する情報及び前記要求対象情報に関連する利用者の状態を参照し、前記要求に対する処理を決定する段階、
Ｇ；前記決定した処理を、前記情報提供装置に通知する段階。

本願第６発明は、要求に応じて他の情報端末に情報を提供する情報提供装置とネットワークを介して接続された前記情報端末に用いられる、アクセス権限設定プログラムを記録したコンピュータ読み取り可能な記録媒体であって、下記Ａ〜Ｃ段階を実行させるためのアクセス権限設定プログラムを記録した、コンピュータ読み取り可能な記録媒体を提供する。
Ａ；前記情報の提供を要求する利用者に関する情報の入力を受け付け、前記情報提供装置に送信する段階、
Ｂ；前記情報に関連する利用者の状態の入力を受け付け、前記情報提供装置に送信する段階、
Ｃ；前記情報の要求者と、前記情報に関連する利用者の状態と、前記要求対象情報とに応じた前記情報の要求に対する処理が、前記情報毎に設定された処理ポリシーの設定を受け付け、前記情報提供装置に送信する段階。

次に、本願発明について、実施形態例を挙げ、図面を参照しつつ具体的に説明する。
＜第１実施形態例＞
［全体構成］
図１に、本発明の第１実施形態例に係るアクセス要求処理システムの全体構成を示す。図１のアクセス要求処理システムは、サーバ及び複数のユーザ端末から構成されている。

（１）サーバ
サーバは、チャットアプリケーションなどユーザ間のコミュニケーションを提供する種々の通信アプリケーションが動作可能であり、アクセス要求処理部１を有している。また、通常の電話サービスも通信アプリケーションの一例と考えられ、その場合には交換機が通信アプリケーションの役割を果たす。アクセス要求処理部１は、認証情報ＤＢ２、認証部３、連携部４、決定部５、ポリシー格納部６、動的データ格納部７、静的データ格納部８、端末通信部９及び他サーバ通信部１０を有している。サーバは、他サーバ通信部１０を介して情報提供サーバと接続されている。

−ポリシー及びデータ−
まず、ポリシー格納部６，動的データ格納部７及び静的データ格納部８に格納されている情報について説明する。ポリシー格納部６には、処理ポリシーと属性付与ポリシーとが設定されている。処理ポリシーには、コミュニケーションの要求に対する処理が設定される。設定される処理は、他のユーザにコミュニケーションを要求するアクセス要求者と、被要求者の状態と、要求内容との組み合わせに依る。各ユーザは、被要求者の立場で、アクセス要求者に対し要求内容毎に処理ポリシーを設定する。ここで、アクセス要求者の設定は、特定のユーザの指定の他に、例えば"友人"や社名が同じユーザなど、ある共通の特性を持つユーザグループを指定することもできる。また、要求内容とは、チャットアプリケーションを例に取れば、"プライベートチャネルで会話する"や、特定のチャネルを指定して会話するなどが挙げられる。

図２に、ユーザにより設定される処理ポリシーの概念図を示す。図２の処理ポリシーにおいて、ユーザＡにプライベートチャネルでのコミュニケーションが要求される場合を例に取る。要求者がユーザＤである場合や趣味が同じである人の場合、ユーザＡの通常時には要求が許可されるように設定されている。一方、ユーザＡが多忙時には、ユーザＡに問い合わせるように設定されている。また、要求者が上司であれば、被要求者であるユーザＡの状態に関わらず、いつでも要求を許可するように設定されている。

属性付与ポリシーには、アクセス要求者の属性が、各ユーザにより自由に設定される。言い換えれば、各ユーザは、他のユーザに対して自由に属性を設定することができる。ここで、属性とは、"友人"や"同僚"など、後述するユーザの静的データからは導けないユーザ同士の関係である。図３に、ユーザにより設定される属性付与ポリシーの概念図を示す。図３の属性付与ポリシーにおいて、ユーザＡは、ユーザＢに"上司"、ユーザＣに"友人"などの属性を設定している。ポリシー格納部６への処理ポリシー及び属性付与ポリシーの設定は、後述するユーザ端末のポリシー設定部２１を用いて各ユーザによりなされる。属性付与ポリシーを設定することにより、コミュニケーションの被要求者の状態だけでなく、被要求者側ユーザからみたユーザ間の関係に応じて、コミュニケーションの要求を処理可能になる。

動的データ格納部７には、各ユーザの現在の状態や現在の状態に付随する情報など、比較的短時間で変化する動的なデータが格納されている。図４に、動的データ格納部７に格納されている動的なデータの一例を示す。図４に格納される動的なデータの例としては、"多忙"や"暇"などの忙しさの程度、現在の居場所、連絡先などが挙げられる。また、現在の居場所へ転送を許可するか否かの情報を登録しておくことも考えられる。なお、動的データとしては、動的データの内容そのものではなく、動的データが格納されている場所を示す識別子であっても良い。本実施形態例においては、これら動的な情報は、後述するユーザ端末のデータ設定部２２を用い、各ユーザ端末から動的データ格納部７に格納される。

静的データ格納部８には、各ユーザの静的なデータが格納されている。ユーザの静的なデータとは、短時間では余り変化しない性質のデータであり、氏名、社名、部署、電子メールアドレス、電話番号、年齢、性別、趣味など様々である。本実施形態例において、ユーザの静的データは必ずしも必要ではないが、コミュニケーション要求に対しより柔軟な処理を行うためには、静的データを用いることが好ましい。また、静的データの内容そのものではなく、社内ＤＢや他の情報提供サーバなど静的データの内容が格納されている場所を示す識別子であっても良いのは動的データと同様である。図５に、静的データ格納部８に蓄積されるユーザの静的データの一例を示す。本実施形態例においては、ユーザの静的データは、後述するユーザ端末のデータ設定部２２を用い、各ユーザ端末から静的データ格納部８に設定される。

−各ブロックの機能−
認証情報ＤＢ２は、ユーザの認証情報、例えばパスワードやＩＤ番号を各ユーザ毎に格納している。
認証部３は、他のユーザとのコミュニケーションを要求する要求者に対し、チャットアプリケーションを介して認証情報の入力を要求する。また、認証部３は、要求に応じて入力された認証情報と認証情報ＤＢに登録されている認証情報とを比較し、要求者が認証情報ＤＢに登録されているユーザか否か判断する。要求者が認証情報ＤＢに登録されていない新規なユーザの場合、認証部３は、新規ユーザを「無名ユーザ」として扱う。

連携部４は、認証部３からの指示に従い、コミュニケーションの要求内容、要求者及び被要求者をチャットアプリケーションから獲得し、決定部５に送出する。実際には、連携部４は、サーバ上で動作可能な種々な通信アプリケーションにそれぞれ対応させて作られる。例えばＩＲＣ(Internet Relay Chat)アプリケーションに対しては、IRCエージェントやBOTと呼ばれる機構などを連携部４として挙げることができる。さらに、連携部４は、要求部４１及び問合わせ部４２を有していることが好ましい。

要求部４１は、後述する決定部５の要求指示部５１からの指示に従い、要求者側の端末との間で、必要な情報の要求及び情報の取得をチャットアプリケーションを介して行う。また、取得した情報を要求指示部５１に送出する。要求部４１は、コミュニケーションの要求に対する処理を決定するために必要な、要求者に関する情報を要求者自身に問い合わせることを可能にするため、設けておくことが好ましい。

問合わせ部４２は、後述する決定部５の問合わせ指示部５１からの指示に従い、要求されたコミュニケーションを行うか否かの問い合わせを、通信アプリケーションを介して被要求者側の端末に送信する。通信アプリケーションとしては、後述する動的データ格納部７に格納されている被要求者の現在の連絡先に問い合わせを送信可能な通信アプリケーションや、被要求者が使用中の通信アプリケーションを選択することが好ましい。問合わせ部４２は、コミュニケーションの要求に対する被要求者の意志を、ユーザ端末に新たな機能を付加することなく確認可能であるため、設けておくことが好ましい。

決定部５は、連携部４から送出された要求内容、要求者及び被要求者に基づいて、ポリシー格納部６から処理ポリシー及び属性付与ポリシーを取得する。さらに、必要に応じ、静的データ格納部７や動的データ格納部８からユーザ情報を取得し、要求されたコミュニケーションに対する処理を決定する。また、決定部５は、端末通信部９を介してユーザ端末から送信されてくる各種ポリシーやユーザ情報などを、ポリシー格納部６やデータ格納部７，８に格納する。決定部５は、要求指示部５１及び問い合わせ指示部５２を有していることが好ましい。

要求指示部５１は、決定部５が静的データ格納部８に要求者に関する必要な情報がないと判断した場合に、必要な情報を要求する。要求方法としては、通信アプリケーションを用いて要求者に要求する方法と、他サーバ通信部１０を介して他の情報提供サーバなどに要求する方法とが考えられる。要求者に要求する場合には、要求指示部５１は、適当な通信アプリケーションを介して必要な情報を取得することを、要求部４１に指示する。通信アプリケーションとしては、要求者がコミュニケーションを要求してきた通信アプリケーションなどが考えられる。

情報提供サーバに対して情報を要求する場合には、所定の方法で情報提供サーバのアドレスが取得できていることが前提となる。所定の方法としては、あらかじめ情報提供サーバのアドレスを静的データ格納部８に格納しておく、コミュニケーション要求に付随して含まれているアドレスを取得する、要求者端末への問合せの結果としてアドレスを取得する、などが挙げられる。なお、情報提供サーバ以外にも汎用ＤＢや社内ＤＢなど様々な他の情報提供手段が用いられる。要求指示部５１は、コミュニケーション要求の処理に必要な情報の設定及び取得を容易にし、ひいては柔軟な処理を可能にするので設けておくことが好ましい。

問合せ指示部５２は、決定部５が「問い合わせる」という動作を選択した場合に、被要求者に対し、コミュニケーションを行うか否かの問合せを行う。具体的には、問い合わせ指示部５２は、前記問い合わせを被要求者側の端末に端末通信部９を介して送信する。また、この問い合わせに対する被要求者の回答を、端末通信部９を介して取得する。前記連携部４に問合わせ部４２を設ける場合、この問い合わせ及び回答の取得を、問い合わせ部４２及び通信アプリケーションを介して行うことも可能である。問い合わせを、端末通信部９または問合わせ部４２のどちらに指示するかは、被要求者の現在の状態に応じて決定すると好ましい。例えば、被要求者が通信アプリケーションを使用している場合は、問合わせ部４２に指示する。逆に、通信アプリケーションを使用していない場合は、端末通信部９に指示する。いずれかにより取得した回答に基づいて、決定部５はコミュニケーションの要求に対する処理を最終的に決定する。すなわち、問い合わせ指示部５２は、前記処理ポリシーにおいて"問い合わせる"の処理を設定することを可能にし、要求に対する柔軟な処理を可能にするので設けることが好ましい。

端末通信部９は、ユーザ端末から送信されるポリシーやユーザ情報を受信し、決定部５に送出する。また、端末通信部９は、問合わせ指示部５２からのコミュニケーション要求に対する問い合わせを、ユーザ端末に送信する。
他サーバ通信部１０は、情報提供サーバ及び要求指示部５１に対応して設けられ、要求指示部５１の指示に応じて必要な情報の要求及び取得を情報提供サーバとの間で行う。

（２）ユーザ端末
ユーザ端末では、ユーザ間でのコミュニケーションを可能にする通信アプリケーションが動作可能である。ユーザ端末は、少なくともポリシー設定部２１及びデータ設定部２２を有し、さらに好ましくは回答部２３を有している。なお、図１では被要求者端末について前記機能を示しているが、要求者側端末も同様の機能を有している。

ポリシー設定部２１は、要求されるコミュニケーションに対する処理の入力を受け付ける。入力される処理は、コミュニケーションの要求内容と、要求者と、被要求者の状態とに依る。要求されるコミュニケーションに対する処理の入力を受け付ける。図６に、ポリシー設定部２１により表示される設定ウインドウの一例を示す。図６の設定ウインドウにおいては、”コミュニケーション要求”、”要求者”、”あなたの状態”及び”処理”の４項目について、ユーザが選択可能なプルダウンメニューが準備されている。メニューにない項目については、新規項目をクリックすることで追加設定が可能である。下部の既設定表示画面には、現在入力している項目に関連した既設定情報が表示されており、現在の設定情報を確認しながらあらたなポリシーを設定することが出来るようになっている。さらに、ポリシー設定部２１は、ユーザにより設定されたポリシーをサーバに送信する。前述のように、サーバに送信されたポリシーは、端末通信部９を介して決定部５によりポリシー格納部６に格納される。

データ設定部２２は、ユーザの現在の状態など動的データ及びユーザの静的データの入力を受け付け、入力されたユーザ情報をサーバに送信する。前述のように、サーバに送信されたユーザ情報は、端末通信部９を介して決定部５によりデータ格納部７，８に格納される。なお、既存の在席管理システムなどを用い、ユーザの動的データをユーザ端末側またはサーバ側で自動的に検出してサーバへ登録してもよい。同様に、ユーザ端末側またはサーバ側で何らかの方法により収集したユーザの静的データを、サーバに自動的に登録することも可能である。例えば静的データ格納部８のデータを、静的データが蓄積されたデータベースを利用して予め自動登録しておくことなどが考えられる。

回答部２３は、サーバの問い合わせ指示部５２に対応して設けられる。回答部２３は、問い合わせ指示部５２からの問い合わせをユーザに通知する。また、回答部２３は、前記問い合わせに対する回答の入力を受け付ける。さらに、回答部２３は入力された回答をサーバに送信する。
［処理の流れ］
前述の構成を有するアクセス要求処理システムにおけるアクセス要求処理処理の流れを、図７を参照して説明する。図７は、アクセス要求処理装置１が行う処理の流れを示すフローチャートである。サーバが、他のユーザ端末に対するコミュニケーションの要求をいずれかのユーザ端末から受信することにより、以下の処理が開始される。以下の説明において、説明を容易にするために、コミュニケーションの被要求者がユーザＡであり、処理ポリシー及び属性付与ポリシーは図２及び３に示すように設定されているものとする。また、ユーザの静的データ及び動的データは、それぞれ図４及び図５に示すように登録されているものとする。

（１）メインルーチン
ステップＳ１では、認証部３は、コミュニケーションを要求してきた要求者の端末に対し、パスワードなどの認証情報の入力を要求する。要求に応じて入力された認証情報と、認証情報ＤＢ２に登録されている認証情報とが一致した場合、認証部３は要求を認証する。一致しない場合は、認証不可とする。

ステップＳ２では、連携部４が、要求内容、要求者及び被要求者を通信アプリケーションから取得し、決定部５に送出する。この際、前述のステップＳ１において、要求の認証が不可と判断されている場合、連携部４は要求者を「無名ユーザ」として扱う。
ステップＳ３では、決定部５が、連携部４より送出されてきた要求内容、要求者および被要求者に基づいて、ポリシー格納部６を検索する。具体的には、決定部５は、被要求者の処理ポリシー及び属性付与ポリシーをポリシー格納部６から読み出す。次いで、決定部５は、要求者が合致する可能性がある“アクセス要求者”を、要求者の属性に基づいて被要求者の処理ポリシーから抽出する。抽出した内容は、分類可能性リストとして、メモリ等に一時的に作成される。決定部５は、被要求者の処理ポリシー中、抽出した“アクセス要求者”に対応する項目を、分類可能性リストに併せて書き込む。本例では、“要求内容”、“被要求者の状態”及び“処理”が、“アクセス要求者”とともに分類可能性リストに記述される。

以上により、通信アプリケーションから取得した要求内容、要求者及び被要求者に基づいて、要求者が該当する可能性がある“アクセス要求者”の分類候補が抽出される。以下のステップでは、要求者が該当する“アクセス要求者”の分類が、抽出された分類候補のなかから決定される。また、決定した“アクセス要求者”の分類に従い、コミュニケーション要求が処理される。“アクセス要求者”の分類の決定は、静的データ格納部８に格納された要求者の属性情報や、動的データ格納部７に格納された被要求者の状態情報を参照して行われる。

分類可能性リストに複数の分類候補が抽出されている場合、決定部５は、要求者が該当するか否かを、各分類候補について順に判断する。そして、最初に該当する分類を、要求者が該当する“アクセス要求者”の分類として決定する。どの順で前記判断を行うかは予め定められているものとする。例えば、予め“アクセス要求者”の各分類に、予め優先順位がつけられていることが考えられる。また例えば、“アクセス要求者”として特定のユーザが指定されている場合、その分類を優先し、その他の場合は処理ポリシーに記述されている順番を優先順位とすることが挙げられる。

ステップＳ４では、決定部５は、分類可能性リストに抽出された全ての分類候補について、要求者が該当するか否かの判断を行ったか否かを判定する。“Ｙｅｓ”と判断すると、ステップＳ５に移行する。要求者が、抽出されたいずれの分類候補にも該当しなかった場合である。“Ｎｏ”と判断すると、要求者が該当する“アクセス要求者”の分類を決定するために、ステップＳ６に移行する。前記判断が行われていない分類候補が、分類可能性リストに残っている場合である。

ステップＳ５では、決定部５は、要求者について、“アクセス要求者”の分類を“その他”に決定する。
ステップＳ６では、決定部５は、前述した優先順位に従って分類可能性リストから１つの分類候補を選択する。決定部５は、選択した分類候補を、要求者が該当するか否かを判断する判断対象とする。また、決定部５は、選択した分類候補を分類可能性リストから削除する。この分類候補について、前記判断を行ったことを示すためである。

ステップＳ７では、決定部５は、要求者に関する静的データの取得が必要かどうかを、判断対象である分類候補の内容に基づいて判断する。“Ｙｅｓ”と判断すると、ステップＳ８に移行する。例えば、判断対象の分類候補が、アクセス要求者“趣味＝登山”の場合である。“Ｎｏ”と判断すると、後述するステップＳ１４に移行する。例えば、判断対象の分類候補が、アクセス要求者“友人”や“上司”の場合である。

ステップＳ８では、決定部５は、要求者をキーにして静的データ格納部８を検索し、要求者の静的データを読み込む。例えば、判断対象の分類候補が、アクセス要求者“趣味＝登山”の場合、決定部５は要求者の趣味を読み込む。
ステップＳ９では、決定部５は、分類を決定するのに必要なデータを、静的データ格納部８から取得できたかどうかを判断する。“Ｙｅｓ”と判断すると、後述するステップＳ１３に移行する。“Ｎｏ”と判断すると、ステップＳ１０に移行する。

例えば、判断対象の分類候補が“趣味＝登山”の場合、必要な静的データは要求者の趣味である。図５に示すように、例えば要求者がユーザＢであれば、趣味として“テニス” が登録されている。従って、要求者が分類候補に該当するか否かを判断可能である。しかし、例えば要求者がユーザＣの場合、趣味は登録されていない。また、ユーザＤの場合はアドレスのみが格納されている。このような場合、要求者が分類候補に該当するか否かの判断に必要な情報は、静的データ管理部８に登録されている情報だけでは不十分である。従って、分類を決定するために必要なデータをさらに取得する。

ステップＳ１０では、要求指示部５１が、通信アプリケーションまたは情報提供サーバに対し、ユーザ情報の取得要求を送出する。静的データ格納部８にデータのアドレスが登録されている場合、要求指示部５１は他サーバ通信部１０を介してその情報を取得する。しかし、静的データ格納部８に何も登録されていなければ、要求指示部５１は要求部４１に対して情報の取得要求を送出する。要求部４１は、受け取った取得要求を通信アプリケーションに適合させて要求者の端末に送信する。

ステップＳ１１およびステップＳ１２では、要求指示部５１は、取得要求を送信してからデータを取得するまでの時間経過を監視する。所定の時間（Ｔ）を経過してもデータが取得出来なかった場合（ステップＳ１２で“Ｙｅｓ”の場合）、ステップＳ４に戻る。すなわち、分類候補について、該当するか否かの判断が出来なかったので、次の分類候補について同様の判断を行う。データが取得出来た場合（ステップＳ１１で“Ｙｅｓ”の場合）、ステップＳ１３に移行し、要求者について“アクセス要求者”の分類を決定可能かどうかを判断する。

ステップＳ１３では、決定部５は、取得した情報に基づいて、対象の分類候補に要求者が該当するか否かの判断が可能かを判断する。“Ｙｅｓ”と判断すると、ステップＳ１４に移行する。“Ｎｏ”と判断すると、ステップＳ４に戻る。すなわち、要求者が分類候補に該当するか否かの判断が出来なかったので、次の分類候補について同様の判断を行う。
ステップＳ１４では、決定部５は、要求に対する処理の決定を行うために、被要求者の動的データの取得が必要かどうかを判断する。必要と判断する場合、ステップＳ１５へ移行する。必要でないと判断する場合、後述するステップＳ１７に移行し、処理を決定する。

必要と判断する場合とは、例えば図２の処理ポリシーにおいて、要求内容が" プライベートチャネルで話す" であり、アクセス要求者が" 友人" である場合である。この場合、被要求者の状態が" 通常" か" 多忙" であるかによって処理が異なるので、被要求者の状態を取得する必要がある。一方、必要と判断しない場合とは、例えば図２の処理ポリシーにおいて、被要求者の状態が" いつでも" に設定されている場合である。この場合、決定部５は、ユーザＡの状態に関わらず処理を決定することが可能である。

ステップＳ１５では、決定部５は、被要求者の状態を動的データ格納部７から読み込む。例えば、図４のユーザの動的データにおいて、ユーザＡの状態は" 多忙" である。
ステップＳ１６では、決定部５は、コミュニケーション要求に対する処理を決定可能か否か、またはアクセス要求者の分類が“その他”のいずれかに該当するかを判断する。処理を決定可能な場合及びアクセス要求者の分類が“その他”である場合、ステップＳ１７へ移行する。処理の決定が不可能と判断された場合、ステップＳ４に戻り、次の分類候補について前述の判断を行う。

ステップＳ１７では、後述する処理決定サブルーチンを実行し、コミュニケーション要求を処理するための動作を決定する。
（２）処理決定サブルーチン
図８は、決定部５が行う処理決定サブルーチンの処理の流れを示すフローチャートである。前記のメインルーチンにおいて、コミュニケーション要求に対する処理動作を決定するために必要なデータが取得できている場合、決定部５は以下の処理を行う。

まず、ステップＳ９１では、決定部５が処理ポリシーに従って処理を決定する。例えば、要求内容が”プライベートチャネルで話す”であり、要求者が“上司”の属性を持つ"user-B"である場合や、要求内容が”チャネル#fooに入る”であり、要求者が"user-C"であれば、ユーザＡの状態に関わらず"許可する"に決定する。また、アクセス要求者の分類が“その他”であり,処理ポリシーに“アクセス要求者”がその他の場合の処理が登録されていない場合、“断る”に決定する。

ステップＳ９２では、決定した処理が"許可する"であるか否か判断する。"許可する"であればステップＳ９３に移行し、その他の場合は後述するステップＳ９５に移行する。
ステップＳ９３では、決定部５が、動的データ格納部７から被要求者の現在の連絡先を取得する。
ステップＳ９４では、決定部５は、取得した連絡先を、連携部４を介して通信アプリケーションに通知する。連絡先を受け取った通信アプリケーションは、被要求者の現在の連絡先を用いて通信チャネルを確立し、コミュニケーションを開始させる。

ステップＳ９１で決定された動作が"断る"または"問い合わせる"である場合、ステップＳ９５に移行する。ステップＳ９５では、決定部５は、決定された動作が"断る"であるか否かを判断する。"断る"であれば、ステップＳ９６に移行する。"断る"でなければ、ステップＳ９７に移行する。
ステップＳ９６では、決定部５は、要求されたコミュニケーションが断られた旨の通知を通信アプリケーションに対して送出し、前記メインルーチンに戻る。

ステップＳ９７では、決定部５は、決定された動作が"問い合わせる"であるか否かを判断する。"問い合わせる"である場合はステップＳ９８に移行する。"問い合わせ"でない場合は前記メインルーチンに戻り処理を終了する。
ステップＳ９８では、問合わせ部５１が、被要求者の端末に対し、コミュニケーションの要求を許可するか否かの問い合わせを、端末通信部９または問合わせ部４２を介して送信する。例えば、被要求者端末で起動中の通信アプリケーションがあれば問合わせ部４２に送信し、その他の場合は端末通信部９を介して回答部２３に送信すると良い。

次いで、ステップＳ９９では、問い合わせ指示部５１が、被要求者の端末からの回答を待機する。問い合わせ指示部５１は、回答を受信するとステップＳ９２に戻って回答に応じた処理を行う。この回答は、"許可する"または"断る"のどちらかである。回答がない場合はステップＳ１００に移行する。
ステップＳ１００では、問い合わせ指示部５１は、待機時間が所定時間Ｔを経過したか否かを判断する。問い合わせ指示部５１は、経過していなければ再びステップＳ９９に戻って回答を受信したか否かを判断する。経過していればステップＳ１０１に移行する。

ステップＳ１０１では、決定部５は、被要求者端末からの回答がないため要求されたコミュニケーションを断ることとし、通信アプリケーションに対してその旨の通知を送出する。なお、要求者からコミュニケーション要求があった旨のメッセージを、アクセス要求処理装置側または被要求者端末に記憶させるようにすることも考えられる。
本実施形態例のアクセス要求処理システムにおいては、チャットや同期的メッセージなどのコミュニケーションを行う際に不要なアクセスに悩まされることを防止し、信頼できる相手から適切な状態でメッセージを受取ることを可能にする。

＜第２実施形態例＞
［全体構成］
図９に、本発明の第２実施形態例に係るアクセス要求処理システムの全体構成を示す。図９のアクセス要求処理システムは、サーバ及び複数のユーザ端末から構成されている。
（１）サーバ
図９のサーバは、通信アプリケーションに代えて情報提供アプリケーションが動作可能であることを除き、前記の第１実施形態例と同様の構成を有している。図９中、第１実施形態例と同様の構成要素については同じ符号を付して示している。情報提供アプリケーションは、情報が蓄積された情報格納部に接続され、ネットワーク上のユーザ端末に情報を提供している。情報提供アプリケーションとしては、例えばＣＧＩ(Common Gateway Interface)等によって他のプログラムと連携可能なＷＷＷが挙げられる。

−ポリシー及びデータ−
第２実施形態例においては、ポリシー格納部６、動的データ格納部７及び静的データ格納部８に格納されるデータの内容が異なることを除き、各機能は前記第１実施形態例とほぼ同様である。ポリシー格納部６には、情報提供ポリシー及び属性付与ポリシーが設定されている。情報提供ポリシーには、情報の提供要求に対する処理が設定されている。設定されている処理は、提供する情報リソースと、情報の要求者と、要求される情報リソースに関連するユーザ（以下、関連ユーザという）の状態とに依る。ここで、関連ユーザとは、情報リソースの管理者、情報が記述している属性を持つユーザ、情報提供ページの問合せに答える担当者など、さまざまな関連するユーザが考えられる。図１０に、情報提供ポリシーの概念図を示す。

図１０の情報提供ポリシーにおいては、ＵＲＬ１は顧客向けのサポートデスク用ページ、ＵＲＬ２は一般的な問合せ窓口であり、URL1-a，URL1-b，URL1-cは顧客向け、URL1-dは社内ユーザ向けのメッセージを持っているとする。各ＵＲＬで表示されるメッセージ及び画面の例を下記に示す。
・ URL1-a，URL2-a :「お待たせいたしました。○○（対応者名）です。」というメッセージと共にチャット画面を表示する。
・ URL1-b :「ただいま○○は手がふさがっております。代わりに△△が対応いたします。」とのメッセージと共に，チャット画面を選択させる画面を表示する。
・ URL1-c :「ただいま○○は手がふさがっております。」とのメッセージと共に、他の担当者と会話するか、こちらから連絡させるか、後でユーザに連絡してもらうか、を選択させる画面を表示する。
・ URL1-d :「○○がすぐ対応いたします。少々お待ち下さい。」のメッセージと共に、広告画面を表示する。
・ URL2-b : 「ただいま○○は離席中です。」とのメッセージと共に、他の担当者と会話するか、こちらから連絡させるか、後でユーザに連絡してもらうか、を選択させる画面を表示する。

図１０の情報提供ポリシーでは、例えばＵＲＬ１で示される情報が要求された場合、要求者が上顧客の"user-B"であれば、関連ユーザの状態に応じてURL1-aまたはURL1-bで示される情報を提供するように設定されている。一方、要求者が"user-B"以外の通常顧客である場合は、関連ユーザの状態に応じてURL1-a，URL1-cまたはURL1-dで示される情報を提供するように設定されている。

なお、提供する情報を示す方法としては、必ずしもＵＲＬでなくてもよい。例えば、関連ユーザ状態を入力とし、表示するメッセージを出力とするようなプログラムを必要に応じて動的に起動できるようにすることも考えられる。この場合、提供情報ポインタの部分に実行結果を出力するように記述しておくとよい。この情報提供ポリシーは、関連ユーザにより設定される。

属性付与ポリシーには、ユーザと情報リソースとの関係を示す属性が、各情報リソースの関連ユーザにより設定される。言い換えれば、情報リソースに関連するユーザは、自分が関連する情報リソースに関し、他のユーザに対して自由に属性を設定することができる。図１１に、ユーザにより設定される属性付与ポリシーの概念図を示す。図１１の属性付与ポリシーにおいて、"user-A"はＵＲＬ２に関連するユーザにより"得意先"に設定されている。ポリシー格納部６への情報提供ポリシー及び属性付与ポリシーの設定は、後述するユーザ端末のポリシー設定部２１を用いて各ユーザによりなされる。

動的データ格納部７には、第１実施形態例と同様、ユーザの現在の状態や現在の状態に付随する情報などの比較的動的に変化するデータが格納されている。但し、本実施形態例では、情報格納部に格納されている情報リソースに関連するユーザの動的データが、各情報リソースと関連づけて格納されている必要がある。図１２に、情報に関連するユーザの動的情報の概念図を示す。

データ格納部８には、第１実施形態例と同様に情報要求者となる各ユーザの静的データが格納されている。この情報の設定は、各ユーザ自身で行っても良いし、また情報リソースに関連するユーザにより行っても良い。本実施形態例においても、各ユーザの静的データは必ずしも必要ではないが、より柔軟なサービスの提供を可能にするためには静的データを用いることが好ましい。前述の第１実施形態例と同様、各ユーザの動的データ及び静的データは、データそのものではなく、データが格納されている場所を示す識別子でも構わない。

−各ブロックの機能−
認証部３は、前述と同様に認証情報ＤＢ２を参照し、情報の提供を要求する利用者が認証情報ＤＢ２に登録されているか否かを確認する。新規なユーザからの要求であれば、そのユーザを「無名ユーザ」として扱うのも第１実施形態例と同様である。
連携部４は、認証部３からの指示に従い、要求対象及び情報の要求者を種々の情報提供アプリケーションから取得し、決定部５に送出する。連携部４の具体例としては、ＣＧＩによってＷＷＷと連携する通信機構に作り込まれた、決定部５との通信機構が挙げられる。また、連携部４は要求部４１を有している。

要求部４１は、決定部５の要求指示部５１からの指示に従い、情報要求者の端末との間で必要な情報の要求及び要求に対する回答の取得を行う。この要求及び回答の取得は、情報提供アプリケーションを介して行う。
決定部５は、連携部４から送出された要求対象及び要求者に基づいてポリシー格納部６から情報提供ポリシー及び属性付与ポリシーを取得し、情報の要求に対する処理を決定する。前記決定を行うために、決定部５は、第１実施形態例と同様に、取得した情報提供ポリシーに応じて動的データ格納部７や静的データ格納部８からユーザに関するデータを読み出す。また、決定部５は、ユーザ端末から送信されるポリシーやデータを、ポリシー格納部６やデータ格納部７，８に格納する。決定部５は、問い合わせ指示部５１及び要求指示部５１を有していることが好ましい。

要求指示部５１は、他サーバ通信部１０または要求部４１に情報の取得要求を送出し、この要求に対する回答を受け取る。前記取得要求は、決定部５が要求者に関する必要なデータが静的データ格納部８にないと判断した場合に行われる。決定部５は、要求指示部５２により取得された情報に基づいて、情報の要求を決定する。
問合せ指示部５２は、決定部５が要求対象に関連するユーザに対し「問い合わせる」ことを決定した場合、所定の問い合わせを、端末通信部９を介して前記ユーザの端末に送信する。所定の問い合わせとは、要求されている情報を提供するか否か、または提供する情報の問い合わせである。また、問合わせ部５１は、この問い合わせに対するユーザ端末からの回答を、端末通信部９を介して取得する。決定部５は、問合わせ部５１により取得された回答に基づいて、要求された情報を提供するか否かを最終的に決定する。

端末通信部９は、決定部とユーザ端末との間でデータの送受信を行う。
他サーバ通信部１０は、前記第１実施形態例と同様に前記要求指示部５１及び他の情報提供サーバに対応して設けられ、情報提供サーバと決定部５との間データの送受信を行う。
（２）ユーザ端末
図９において、関連ユーザ端末は、サーバに対して情報を要求し、取得を行うブラウザが動作可能であり、少なくともポリシー設定部２１及びデータ設定部２２を有し、さらに好ましくは回答部２３を有している。図９中、第１実施形態例と同様の構成要素については同じ符号を付して示している。なお、図９に示すユーザ端末の構成は、各ユーザの静的情報を、関連ユーザ端末からサーバに登録する場合を示している。各ユーザの静的情報を各ユーザ端末からそれぞれサーバに登録可能にする場合は、図９に示される要求者端末にもデータ設定部２２を設けておく。

ポリシー設定部２１は、関連ユーザによる前記情報提供ポリシー及び属性付与ポリシーの設定を受け付け、設定されたポリシーをサーバに送信する。
データ設定部２２は、関連ユーザの動的データ及び各ユーザの静的データの入力を受け付け、入力されたデータをサーバに送信する。前述と同様、何らかの手段によりこれらのデータを収集し、自動的にサーバに登録するようにしても良い。

回答部２３は、サーバの問い合わせ指示部５２に対応して設けられる。回答部２３は、情報の要求に対する処理の問い合わせをユーザに通知する。また、回答部２３は、前記問い合わせに対するユーザからの回答をサーバに送信する。
［処理の流れ］
前述の構成を有するアクセス要求処理システムにおいて、アクセス要求処理装置１が行う処理の流れは前述の第１実施形態例とほぼ同様であるので、前述の図７を参照して説明する。サーバが、情報提供の要求をいずれかのユーザ端末から受信することにより、以下の処理が開始される。以下の説明において、説明を容易にするために、要求対象の情報がＵＲＬ１、関連ユーザがユーザＡであり、ポリシーは図１０及び図１１に示すように設定されているものとする。また、各ユーザの静的データは前記図５に、関連ユーザの動的データは図１２に示されているものとする。

ステップＳ１〜ステップＳ１７における処理は、前述の第１実施形態例と同様である。但し、ステップＳ１７で行う処理決定サブルーチンの処理内容は第１実施形態例と異なる。
すなわち、ステップＳ１では、認証部３は、要求者端末から入力される認証情報と登録されている認証情報とを比較する。認証部３は、両者が一致すれば要求者を認証する。一致しない場合、認証不可とする。

ステップＳ２では、連携部４が、要求対象及び要求者を情報提供アプリケーションから取得し、決定部５に送出する。この際、前記ステップＳ１において、要求の認証が不可と判断されている場合、連携部４は要求者を「無名ユーザ」として扱う。
ステップＳ３では、決定部５が、要求対象に関する情報提供ポリシー及び属性付与ポリシーをポリシー格納部６から取得し、分類可能性リストを作成する。

ステップＳ４では、決定部５は、分類可能性リストに抽出された全ての分類候補について、要求者が該当するか否かの判断を行ったか否かを判断する。“Ｙｅｓ”と判断すると、ステップＳ５に移行する。“Ｎｏ”と判断すると、ステップＳ６に移行する。
ステップＳ５では、決定部５は、要求者について、“情報要求者”の分類を“その他”に決定する。

ステップＳ６では、決定部５は、所定の優先順位に従って分類可能性リストから１つの分類候補を選択し、判断対象とする。優先順位については第１実施形態例と同様に予め定められている。選択した分類候補のエントリは、分類可能性リストから削除される。
ステップＳ７では、決定部５は、要求者に関する静的データの取得が必要であるか否かを、対象の分類候補に基づいて判断する。“Ｙｅｓ”と判断すると、ステップＳ８に移行する。“Ｎｏ”と判断すると、後述するステップＳ１４に移行する。“Ｙｅｓ”と判断するのは、例えば要求対象がＵＲＬ１であり、要求者が"user-B"またはその他のユーザの場合である。分類不可能とは、例えば要求対象がＵＲＬ２の場合である。この場合、要求者の社名が”Fujitsu”か否かにより情報要求者の分類が決定されるため、この段階ではいずれの分類に属するか分類不可能である。

ステップＳ８では、決定部５は、要求者に関し必要な静的データを静的データ格納部８から読み込む。要求者が情報提供ポリシーに設定されている情報要求者のいずれの分類に該当するかを判断するためである。例えば、要求対象が"ＵＲＬ２"であれば、要求者の社名が必要である。
ステップＳ９では、決定部５は、要求者に関する必要な静的データが、静的データ格納部８にあるか否かを判断する。データが静的データ格納部８にある場合、必要な静的データを読み込んで前述のステップＳ５に移行する。必要なデータが何も登録されていない、またはデータのアドレスのみが登録されている場合には、ステップＳ１０に移行する。

ステップＳ１０では、要求指示部５１が、他サーバ通信部１０または要求部４１を介し、ユーザ情報の取得要求を送出する。必要としているデータのアドレスが静的データ格納部８に登録されている場合、要求指示部５２は他サーバ通信部１０を介してその情報を取得する。必要なデータが何も登録されていなければ、要求指示部５１は、要求部４１に対して情報の取得要求を送出する。要求部４１は、受け取った取得要求を情報提供アプリケーションに適合させて要求者端末に送信する。

ステップＳ１１及びステップＳ１２では、要求指示部５１は、所定時間が経過するまでデータを待機する。所定の時間（Ｔ）を経過してもデータが取得出来なかった場合、ステップＳ４に戻る。データが取得出来た場合、ステップＳ１３に移行し、要求者が属する“情報要求者”の分類を決定可能かどうかを判断する。
ステップＳ１３では、決定部５は、取得した情報に基づいて、対象の分類候補に要求者が該当するか否かの判断が可能か否かを、判断する。“Ｙｅｓ”と判断すると、ステップＳ１４に移行する。“Ｎｏ”と判断すると、ステップＳ４に戻る。

ステップＳ１４では、決定部５は、決定部５は、提供する情報を決定可能か否かを判断する。この判断は、要求者が、情報提供ポリシーのいずれの情報要求者に該当するかに依る。決定可能な場合とは、提供する情報が関連ユーザの状態に依存しない場合である。この場合はステップＳ１７に移行する。決定不可能な場合とは、提供する情報が関連ユーザの状態に依存する場合である。情報提供ポリシーが図１０に示すように設定されている場合、関連ユーザの状態により提供する情報が異なるので、この段階では提供する情報を決定不可能と判断される。この場合はステップＳ１５に移行する。

ステップＳ１５では、決定部５は、関連ユーザの状態を動的データ格納部７から取得する。
ステップＳ１６では、決定部５が、要求対象、情報要求者の分類及び取得した関連ユーザの状態に基づいて、情報提供ポリシーに従い、提供する情報を決定する。
ステップＳ１７では、決定部５は、要求対象、情報要求者の分類及び取得した関連ユーザの状態に基づいて、情報提供ポリシーに従い、提供する情報を決定する。

本実施形態例のアクセス付与制御システムにおいては、顧客用ヘルプデスクなどにおいて相手に応じたきめの細かな対応・処理を行うことができるようになる。また、たとえば、あるユーザのホームページで当人に関するデータを公開しているとする。公開データの中に当人の連絡先情報が含まれている時に、当人の現在の居場所情報が格納されていると、それを利用して提供する情報の内容を変更することができる。

＜第３実施形態例＞
前記第２実施形態例において、静的データ格納部８に格納されている各ユーザの個人情報を提供することも可能である。この場合、例えば個人データ提供ポリシーを設定し、各ユーザは自分の静的データの各項目についての公開レベルを、他のユーザとの関係に応じて設定可能にする。個人データ提供ポリシーの例を図１３に示す。ただし、各公開レベルそれぞれに対し応じ、公開する静的データが予め設定されているものとする。

本発明を利用すれば、ネットワークコミュニケーションサービスや公開情報の提供サービス等、ネットワークを介してユーザが関係するサービスを提供する場合に、アクセス対象ユーザまたはアクセス対象に関連するユーザの状態に応じてサービスの要求に対する処理を行うことができる。直接または間接的にアクセスされるユーザの状態を考慮することにより、サービスの要求に対する処理の柔軟性を高めることが出来る。

本発明の第１実施形態例の機能構成を示すブロック図である。 処理ポリシーの概念を示す説明図である。 属性付与ポリシーの概念を示す説明図である。 ユーザの動的データの一例を示す説明図である。 ユーザの静的データの一例を示す説明図である。 ポリシーの設定ウインドウの一例を示す説明図である。 図１に示すアクセス要求処理装置が行う処理の流れを示すフローチャートである。 処理決定サブルーチンにより行われる処理の流れを示すフローチャートである。 本発明の第２実施形態例の機能構成を示すブロック図である。 情報提供ポリシーの概念を示す説明図である。 第２実施形態例における属性付与ポリシーの概念を示す説明図である。 第２実施形態例におけるユーザの動的データの一例を示す説明図である。 個人情報提供ポリシーの概念を示す説明図である。 ＡＣＬの概念を示す説明図である。

Claims (6)

1. 要求に応じて他の情報端末に情報を提供する情報提供装置に用いられるアクセス要求処理方法であって、
   前記情報提供装置は、前記情報に関連する利用者の状態を前記情報毎に蓄積し、
   前記情報提供装置は、前記情報を要求する利用者と、情報に関連する他の利用者の状態と、要求対象情報と、に応じた前記情報要求に対する処理動作が前記情報毎に設定された処理ポリシーを記憶し、
   前記情報提供装置は、前記いずれかの情報に対する要求が生じた場合、前記要求対象情報の処理ポリシーに基づいて前記要求に対する処理動作を決定し、
   前記情報提供装置は、前記決定した処理動作に基づいて、前記要求に対する処理を制御する、
   アクセス要求処理方法。
2. 要求に応じて他の情報端末に情報を提供する情報提供装置に用いられるアクセス要求処理システムであって、
   前記情報を要求する要求者に関する情報を蓄積する第１蓄積手段と、
   前記要求対象の情報に関連する利用者の状態を蓄積する第２蓄積手段と、
   前記情報の要求者と、前記情報に関連する利用者の状態と、要求対象情報とに応じた前記情報の要求に対する処理が、前記情報毎に設定された処理ポリシーを蓄積する第３蓄積手段と、
   前記情報提供の要求が生じた場合、前記情報提供の要求者を確認する認証手段と、
   前記情報提供装置から前記要求者及び要求対象情報を獲得する連携手段と、
   前記連携手段が獲得した要求対象情報に基づいて前記処理ポリシーを取得し、前記要求者の確認結果及び前記取得した処理ポリシーに基づいて前記要求者に関する情報及び前記要求対象情報に関連する利用者の状態を参照し、前記要求に対する処理を決定し前記情報提供装置に通知する決定手段と、
   前記要求者に関する情報の入力を受け付け、前記第１蓄積手段に登録する情報登録手段と、
   前記情報に関連する利用者の状態の入力を受け付け、前記第２蓄積手段に登録する状態登録手段と、
   前記処理ポリシーの設定を受け付け、前記第３蓄積手段に登録するポリシー登録手段と、
   を備えたアクセス要求処理システム。
3. 要求に応じて他の情報端末に情報を提供する情報提供装置に用いられるアクセス要求処理装置であって、
   前記情報を要求する要求者に関する情報を蓄積する第１蓄積手段と、
   前記要求対象の情報に関連する利用者の状態を蓄積する第２蓄積手段と、
   前記情報の要求者と、前記情報に関連する利用者の状態と、要求対象情報とに応じた前記情報の要求に対する処理が、前記情報毎に設定された処理ポリシーを蓄積する第３蓄積手段と、
   前記情報提供の要求が生じた場合、前記情報提供の要求者を確認する認証手段と、
   前記情報提供装置から前記要求者及び要求対象情報を獲得する連携手段と、
   前記連携手段が獲得した要求対象情報に基づいて前記処理ポリシーを取得し、前記要求者の確認結果及び前記取得したポリシーに基づいて前記要求者に関する情報及び前記要求対象情報に関連する利用者の状態を参照し、前記要求に対する処理を決定し前記情報提供手段に通知する決定手段と、
   を備えるアクセス要求処理装置。
4. 要求に応じて他の情報端末に情報を提供する情報提供装置とネットワークを介して接続された、前記情報端末に用いられるアクセス権限設定装置であって、
   前記情報の提供を要求する利用者に関する情報の入力を受け付け、前記情報提供装置に送信する情報登録手段と、
   前記情報に関連する利用者の状態の入力を受け付け、前記情報提供装置に送信する状態登録手段と、
   前記情報の要求者と、前記情報に関連する利用者の状態と、要求対象情報とに応じた前記情報の要求に対する処理が、前記情報毎に設定されたポリシーの設定を受け付け、前記情報提供装置に送信するポリシー登録手段と、
   を備えたアクセス権限設定装置。
5. 要求に応じて他の情報端末に情報を提供する情報提供装置に用いられる、アクセス要求処理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
   Ａ；前記情報を要求する要求者に関する情報を蓄積する段階と、
   Ｂ；前記要求対象情報に関連する利用者の状態を蓄積する段階と、
   Ｃ；前記情報の要求者と、前記情報に関連する利用者の状態と、要求対象情報とに応じた前記情報の要求に対する処理が、前記情報毎に設定された処理ポリシーを蓄積する段階と、
   Ｄ；前記情報提供の要求が生じた場合、前記情報提供の要求者を確認する段階と、
   Ｅ；前記情報提供装置から前記要求者及び要求対象情報を獲得する段階と、
   Ｆ；前記連携手段が獲得した要求対象情報に基づいて前記処理ポリシーを取得し、前記要求者の確認結果及び前記取得したポリシーに基づいて前記要求者に関する情報及び前記要求対象情報に関連する利用者の状態を参照し、前記要求に対する処理を決定する段階と、
   Ｇ；前記決定した処理を、前記情報提供装置に通知する段階と、
   を実行させるためのアクセス要求処理プログラムを記録した、コンピュータ読み取り可能な記録媒体。
6. 要求に応じて他の情報端末に情報を提供する情報提供装置とネットワークを介して接続された前記情報端末に用いられる、アクセス権限設定プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
   Ａ；前記情報の提供を要求する利用者に関する情報の入力を受け付け、前記情報提供装置に送信する段階と、
   Ｂ；前記情報に関連する利用者の状態の入力を受け付け、前記情報提供装置に送信する段階と、
   Ｃ；前記情報の要求者と、前記情報に関連する利用者の状態と、前記要求対象情報とに応じた前記情報の要求に対する処理が、前記情報毎に設定された処理ポリシーの設定を受け付け、前記情報提供装置に送信する段階と、
   を実行させるためのアクセス権限設定プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images