アクセス制御プログラム、アクセス制御方法及びアクセス制御装置
【課題】リソースに対するアクセスを要求する端末を個別に特定することなく、アクセス制御を行う。
【解決手段】アクセス制御ポリシー管理部２２が、リソースを保持する端末Ｔａから得られる特定の情報とリソースに対するアクセスを要求する端末Ｔｂから得られる特定の情報との類似性（アイデンティティ類似性）で定義される、リソースに対するアクセス制御ポリシーを管理し、アクセス制御部２０が、アクセス制御ポリシーに基づいて、端末Ｔａ及び端末Ｔｂから特定の情報を取得し、当該取得された各情報の類似性が検証条件を満たすか否かを検証することで、端末Ｔｂのアクセス制御を行う。
【解決手段】アクセス制御ポリシー管理部２２が、リソースを保持する端末Ｔａから得られる特定の情報とリソースに対するアクセスを要求する端末Ｔｂから得られる特定の情報との類似性（アイデンティティ類似性）で定義される、リソースに対するアクセス制御ポリシーを管理し、アクセス制御部２０が、アクセス制御ポリシーに基づいて、端末Ｔａ及び端末Ｔｂから特定の情報を取得し、当該取得された各情報の類似性が検証条件を満たすか否かを検証することで、端末Ｔｂのアクセス制御を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本件は、アクセス制御プログラム、アクセス制御方法及びアクセス制御装置に関する。
【背景技術】
【０００２】
従来より、ある利用者に関するサービスに対して、他の利用者のアクセスを制限するシステムがある。当該システムとしては、例えば、ある利用者に関する個人情報を、参照者である他の利用者に開示する情報開示サービスシステムなどがある。
【０００３】
特許文献１には、友人や、同僚、上司といった既存の関係を有する人に対して当該関係に合わせたアクセスコードを配布することで、アクセス制御を行う方法が開示されている。この特許文献１では、リソースにアクセスするユーザをユーザ名や電子メールアドレスを使って一意に識別し、当該アクセスユーザとリソースの持ち主との既存関係をアクセスコードに反映し、配布することで、アクセス制御を行う。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−３４６２５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記特許文献１では、アクセスを許可又は拒否する人を一人一人システムに登録し、管理しておく必要があり、登録には手間と時間を要する。これに対し、各ユーザを登録、管理することなく、アクセスを許可するユーザを大まかに分類して指定することができるようになれば、今後、種々のシステムへの利用が期待できると考えられる。
【０００６】
そこで本件は上記の課題に鑑みてなされたものであり、リソースに対するアクセスを要求する端末を個別に特定することなく、アクセスの可否を判断可能なアクセス制御プログラム、アクセス制御方法及びアクセス制御装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本明細書に記載のアクセス制御プログラムは、リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得し、前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する、処理をコンピュータに実行させるアクセス制御プログラムである。
【０００８】
本明細書に記載のアクセス制御方法は、リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得工程と、前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断工程と、をコンピュータが実行するアクセス制御方法である。
【０００９】
本明細書に記載のアクセス制御装置は、リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件を管理する管理部と、前記アクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得部と、前記取得部が前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断部と、を備えるアクセス制御装置である。
【発明の効果】
【００１０】
本明細書に記載のアクセス制御プログラム、アクセス制御方法及びアクセス制御装置は、リソースに対するアクセスを要求する端末を個別に特定することなく、アクセスの可否を判断できるという効果を奏する。
【図面の簡単な説明】
【００１１】
【図１】一実施形態に係る情報処理システムの構成を概略的に示す図である。
【図２】図２（ａ）は、端末Ｔａのハードウェア構成図であり、図２（ｂ）は、端末Ｔｂのハードウェア構成図である。
【図３】端末Ｔａ，Ｔｂの機能ブロック図である。
【図４】図４（ａ）は、アクセス制御ポリシーＴＢＬを示す図であり、図４（ｂ）は、記述定義ＴＢＬを示す図であり、図４（ｃ）は、検証条件複合ＴＢＬを示す図である。
【図５】図５（ａ）は、検証条件ＴＢＬを示す図であり、図５（ｂ）は、Ｓｔｏｒｅ用プロパティＴＢＬを示す図であり、図５（ｃ）は、ＩＳ検証用データＴＢＬを示す図である。
【図６】端末Ｔａ，Ｔｂの処理を示すフローチャートである。
【図７】図６の処理及びデータの流れを示す図である。
【図８】図８（ａ）は、端末Ｔｂが保有する店舗電話番号ラベルの電話番号を示す図であり、図８（ｂ）は、端末Ｔａが保有する店舗電話番号ラベルの電話番号を示す図であり、図８（ｃ）は、検証結果を示す図である。
【図９】第２の実施形態に係る端末Ｔａ，Ｔｂの機能ブロック図である。
【図１０】第３の実施形態に係る情報処理システムの構成を示す図である。
【図１１】図１１（ａ）は、第３の実施形態に係る記述定義を示す図であり、図１１（ｂ）は、第３の実施形態において、端末Ｔｂから取得したデータを示す図であり、図１１（ｃ）は、第３の実施形態において、端末Ｔａから取得したデータを示す図である。
【図１２】図１２（ａ）は、プロジェクトＭＬラベルのメールアドレスの検証結果を示す図であり、図１２（ｂ）は、プロジェクトラベルフォルダ以下のハッシュファイルの検証結果を示す図である。
【図１３】図１３（ａ）は、第４の実施形態に係るアクセス制御ポリシーを示す図であり、図１３（ｂ）は、変形例に係るアクセス制御ポリシーを示す図であり、図１３（ｃ）は、符号化の一例を示す図である。
【図１４】第５の実施形態に係る端末Ｔａ，Ｔｂの処理を示すフローチャートである。
【図１５】図１４の処理における手続きを説明するための図である。
【図１６】図１６（ａ）は、第６の実施形態において端末Ｔａから取得したプロフィールであり、図１６（ｂ）は、第６の実施形態において端末Ｔｂから取得したプロフィールであり、図１６（ｃ）は、図１６（ａ）と図１６（ｂ）のデータを比較した検証結果を示す図である。
【図１７】図１７（ａ）〜図１７（ｃ）は、第７の実施形態を説明するための図である。
【図１８】第８の実施形態を説明するための図である。
【図１９】第９の実施形態において画像化された証明書を示す図である。
【図２０】図２０（ａ）〜図２０（ｃ）は、第９の実施形態の変形例を示す図である。
【発明を実施するための形態】
【００１２】
《第１の実施形態》
以下、第１の実施形態について、図１〜図８に基づいて詳細に説明する。
【００１３】
図１には、第１の実施形態に係る情報処理システム１００の構成が概略的に示されている。情報処理システム１００は、リソースの権利者が利用する第１端末としての端末Ｔａと、リソースの要求者が利用する第２端末としての端末Ｔｂと、を有している。これら端末Ｔａ，Ｔｂは、インターネットなどのネットワーク８０に接続されており、端末Ｔａ，Ｔｂ間における通信が可能な状態となっている。
【００１４】
ここで、「リソース」とは、アクセス制御対象の単位となるものを指す。例えば、Ｗｅｂサイトにおけるアクセス制御であれば、リソースは、各ＵＲＬで参照されるファイルや、ＵＲＬで示されたフォルダ内に存在するファイルの全てを意味する。また、勤務先のドアに付帯したアクセス制御である場合には、リソースは、ドアそのもの、もしくは、当該ドアの先にあるもの全てを意味する。
【００１５】
なお、本第１の実施形態では、端末Ｔａ，Ｔｂで管理されているエンティティのデータを用いてアイデンティティ類似性（ＩＳ：Identity Similarity）を検証し、エンティティの認証及び当該認証結果を利用したアクセス制御を行う。ここで、「エンティティ」とは、人や物（端末等）を意味している。また、「エンティティのデータ」とは、端末Ｔａ，Ｔｂが保有するデータ全て、又は各端末を利用するユーザ別に利用可能なデータを意味する。具体的には、「エンティティのデータ」には、利用者本人が作成したファイル群や、アプリケーションが作成した利用者用のデータ、あるいは利用者のシステムの利用履歴などが含まれる。なお、利用履歴等の本人やアプリケーションが保存したデータに対する背景情報（例えば、ファイルに付加された当該ファイル更新日時等）のみを指す場合には、「メタデータ」という。
また、「アイデンティティ類似性」とは、エンティティと、別のエンティティが類似しているかどうかを、各エンティティのデータの共通性等に基づいて数値で表したものを意味する。
【００１６】
なお、以下においては、１台の端末が１人の利用者専用の端末である（より具体的には、端末Ｔａの利用者がＡであり、端末Ｔｂの利用者がＢである）ものとする。このため、本第１の実施形態における「エンティティ」は、端末Ｔａ（又は利用者Ａ）と、端末Ｔｂ（又は利用者Ｂ）となる。
【００１７】
端末Ｔａは、例えば、ＰＣ、携帯電話などの端末であるものとする。端末Ｔａは、図２（ａ）に示すようなハードウェア構成を有する。具体的には、端末Ｔａは、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、ユーザインタフェース部９３、及び可搬型記憶媒体用ドライブ９９等を備える。端末Ｔａの構成各部は、バス９８に接続されている。ユーザインタフェース部９３は、ディスプレイなどの表示装置や、キーボードやマウスなどの入力装置を含む。端末Ｔａでは、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（アクセス制御プログラム）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（アクセス制御プログラム）をＣＰＵ９０が実行することにより、図３の各部の機能が実現される。なお、プログラム（アクセス制御プログラム）をネットワーク８０を介してインストールできるような場合には、端末Ｔａに可搬型記憶媒体用ドライブ９９を設けないようにしてもよい。
【００１８】
端末Ｔｂは、図２（ｂ）に示すようなハードウェア構成を有する。端末Ｔｂは、端末Ｔａと同様の構成となっている。具体的には、端末Ｔｂは、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ＨＤＤ）１９６、ネットワークインタフェース１９７、ユーザインタフェース部１９３、及び可搬型記憶媒体用ドライブ１９９等を備える。端末Ｔｂの構成各部は、バス１９８に接続されている。端末Ｔｂでは、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラム（アクセス制御プログラム）、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体１９１から読み取ったプログラム（アクセス制御プログラム）をＣＰＵ１９０が実行することにより、図３の各部の機能が実現される。なお、プログラム（アクセス制御プログラム）をネットワーク８０を介してインストールできるような場合には、端末Ｔｂに可搬型記憶媒体用ドライブ９９を設けないようにしてもよい。
【００１９】
図３には、端末Ｔａ及び端末Ｔｂの機能ブロック図が示されている。図３に示すように、端末Ｔａは、ＣＰＵ９０がプログラムを実行することで、アクセス制御部２０、管理部としてのアクセス制御ポリシー管理部２２、比較照合部２４、及び情報管理部２６、としての機能を実現している。また、端末Ｔｂは、ＣＰＵ１９０がプログラムを実行することで、リソースリクエスト部４０、及び情報管理部４２、としての機能を実現している。
【００２０】
なお、図３では、端末ＴａのＨＤＤ９６等に格納される各種ＤＢ及びテーブル（以下「ＴＢＬ」と記述する）も図示されている。これら各種ＤＢ及びＴＢＬには、図３に示すように、リソース群ＤＢ３１、アクセス制御ポリシーＴＢＬ３２、記述定義ＴＢＬ３３、検証条件複合ＴＢＬ３４、検証条件ＴＢＬ３５、Ｓｔｏｒｅ用プロパティＴＢＬ３６、ＩＳ検証用データＴＢＬ３７が含まれる。
【００２１】
次に、上記各部について、詳細に説明する。
【００２２】
アクセス制御部２０は、端末Ｔｂから端末Ｔａのリソース群ＤＢ３１に格納されているリソースに対するアクセス要求を受け付ける。そして、アクセス制御部２０は、端末Ｔａからアクセス制御に必要な特定の情報を取得するとともに、端末Ｔｂからアクセス制御に必要な特定の情報を取得する。なお、特定の情報とは、後述するアクセス制御条件としてのアクセス制御ポリシーにおいて定義されている、アクセス制御に用いる情報を意味する。また、アクセス制御部２０は、アクセス制御ポリシー管理部２２及び比較照合部２４と連携し、アクセス制御ポリシーと、取得したデータと、に基づいて、端末Ｔｂのアクセス制御を実行する。
【００２３】
ここで、リソース群ＤＢ３１には、アクセス制御対象であるリソースが格納される。リソースには、様々なファイル、データ等が含まれる。なお、本第１の実施形態では、リソースに、利用者Ａが端末Ｔａ内で保有する会員証登録簿内で管理されている店舗の情報（店名・住所・電話番号等）が含まれているものとする。
【００２４】
アクセス制御ポリシー管理部２２は、アクセス制御ポリシーＴＢＬ３２、記述定義ＴＢＬ３３、検証条件複合ＴＢＬ３４、検証条件ＴＢＬ３５、及びＳｔｏｒｅ用プロパティＴＢＬ３６に基づいてアクセス制御ポリシーを生成し、管理する。
【００２５】
ここで、アクセス制御ポリシーＴＢＬ３２は、一例として、図４（ａ）に示すように、「リソース」と、「対象」と、「Allow/Deny」の各フィールドを有する。「リソース」のフィールドには、アクセス制御に係るリソースの名称が記述される。「対象」のフィールドには、リソースに対するアクセスを許可又は不許可とする対象が記述される。「Allow/Deny」の各フィールドには、「対象」に対するアクセスを許可する（Allow）か、不許可とする（Deny）か、が記述される。
【００２６】
記述定義ＴＢＬ３３は、一例として、図４（ｂ）に示すように、「検証文」と、「検証条件複合ＩＤ（参照）」のフィールドを有する。検証条件複合ＴＢＬ３４は、一例として、図４（ｃ）に示すように、「検証条件複合ＩＤ」と、「複合条件演算」と、「検証条件ＩＤ１（参照）」と、「検証条件ＩＤ２（参照）」の各フィールドを有する。検証条件ＴＢＬ３５は、一例として、図５（ａ）に示すように、「検証条件ＩＤ」と、「検証条件演算」と、「検証方向」と、「クリア条件」と、「検証対象」と、「Ｓｔｏｒｅ用プロパティＩＤ（参照）」の各フィールドを有する。Ｓｔｏｒｅ用プロパティＴＢＬ３６は、一例として、図５（ｂ）に示すように、「Ｓｔｏｒｅ用プロパティＩＤ」、「データタイプ」、「Ｓａｍｅａｓ」、「ｆｒｏｍ」、「ｔｏ」などのフィールドを有する。これら各ＴＢＬ３３〜３６は、アクセス制御ポリシー管理部２２により管理されている。
【００２７】
これら各ＴＢＬ３３〜３６からは、アクセス制御ポリシーとして、“検証文：会員登録している店舗”ならば、リソース（System.rsc.Phonebook.*）へのアクセス権限を付与する、という内容が定義されている。すなわち、アクセス制御ポリシーでは、会員登録しているかどうかという観点で見た時にアイデンティティ類似性（ＩＳ）が高い（会員登録している可能性が高い）かどうかを検証することが定められている。また、検証条件ＴＢＬ３５やＳｔｏｒｅ用プロパティＴＢＬ３６では、ＩＳ検証用データＴＢＬ３７（図５（ｃ）参照）に含まれている電話帳データ（System.rsc.Phonebook.*）のうち店舗電話番号のラベルがついたデータの少なくとも１つが、端末Ｔｂから得られるデータの１つと同一であれば、アクセス権限を付与する、ということが定められている。
【００２８】
図３に戻り、比較照合部２４は、記述定義ＴＢＬ３３等から生成されるアクセス制御ポリシーに基づいて、アクセス制御部２０が取得した情報を比較照合し、当該比較照合結果（検証結果とも呼ぶ）をアクセス制御部２０に回答する。
【００２９】
情報管理部２６は、ＩＳ検証用データＴＢＬ３７において、アイデンティティ類似性（ＩＳ）を検証するためのデータを管理する。なお、利用者Ａは、端末Ｔａにおいて会員証情報を管理しているものとし、情報管理部２６は、当該会員証情報から電話番号を抽出して、ＩＳ検証用データＴＢＬ３７を生成する。ここで、ＩＳ検証用データＴＢＬ３７は、一例として、図５（ｃ）に示すように、「検証用データＩＤ」と、「検証用データタイプ」と、「検証用データ」の各フィールドを有する。「検証用データタイプ」のフィールドには、「店舗電話番号」などのデータの種類が記述され、「検証用データ」のフィールドには、電話番号などの実データが記述される。なお、「検証用データタイプ」のフィールドは、「検証データ」のフィールドに記述される実データのラベルとしての機能を有する。
【００３０】
図３に戻り、端末Ｔｂのリソースリクエスト部４０は、端末Ｔｂの利用者Ｂが、ユーザインタフェース部１９３からリソースへのアクセスをリクエストした場合に、当該リクエストを端末Ｔａのアクセス制御部２０に対して送信する。情報管理部４２は、アクセス制御部２０から要求される、アクセス制御に必要なデータを送信する。なお、端末Ｔａは、図３に示す機能のほか、端末Ｔｂの機能を併せ持っていても良いし、端末Ｔｂは、図３に示す機能のほか、端末Ｔａの機能を併せ持っていても良い。
【００３１】
次に、図６のフローチャートに沿って、端末Ｔａ、端末Ｔｂの処理について詳細に説明する。図６では、左側のフローチャートが端末Ｔｂの処理を示しており、右側のフローチャートが端末Ｔａの処理を示している。なお、以下の説明では、図６及び図７に示す、処理及びデータの流れを示す番号（括弧付き番号）を適宜用いるものとする。
【００３２】
なお、本第１の実施形態では、端末Ｔｂを利用する利用者Ｂ（リソースの要求者）がリソースを保有する端末Ｔａの利用者Ａ（リソースの権利者）のよく行く店舗であるものとする。そして、リソースには、利用者Ａの会員証登録簿内で管理されている利用者Ｂの店舗情報（店名・住所・電話番号等）を含む会員証情報を含むものとする。また、以下では、利用者Ｂが、端末Ｔｂを介して端末Ｔａが保有する会員証情報にアクセスすることで当該会員証情報を変更しようとしており、端末Ｔａでは、以下に説明する方法で、端末Ｔｂのアクセス制御を行うものとする。また、以下の処理で用いるアクセス制御ポリシーは、図４、図５の各テーブル３３〜３６から導き出されるアクセス制御ポリシーであるものとする。
【００３３】
図６の処理では、まず、ステップＳ１０において、端末Ｔｂのリソースリクエスト部４０が、リソースに対するアクセスのリクエストが入力されるまで待機する。この場合、リソースリクエスト部４０では、ユーザインタフェース部１９３を介した利用者Ｂからのリクエストが入力された段階で、ステップＳ１２に移行する。
【００３４】
ステップＳ１２では、リソースリクエスト部４０が、リソースに対するアクセスのリクエストを、端末Ｔａのアクセス制御部２０に対して送信する（図７の（１）参照）。なお、上記ステップＳ１０、Ｓ１２では、リソースリクエスト部４０が、利用者Ｂからのリクエストの入力があった段階でリクエストを端末Ｔａに対して送信する場合について説明したが、これに限られるものではない。例えば、リソースリクエスト部４０は、端末Ｔｂと端末Ｔａとの距離が赤外線等による通信が可能になる程度の距離に近づくまで待機し、近づいた段階で、自動的に端末Ｔａに対してリクエストを送信するようにしてもよい。
【００３５】
上記ステップＳ１０、Ｓ１２の処理の間、端末Ｔａのアクセス制御部２０は、ステップＳ１１０において、リソースに対するアクセスのリクエストを受信するまで待機している。そして、ステップＳ１２において、端末Ｔｂ側からアクセス制御部２０に対してリクエストが送られてくると、アクセス制御部２０は、ステップＳ１１２に移行する。
【００３６】
ステップＳ１１２では、アクセス制御部２０は、端末Ｔｂ側から送信されてきたリクエストを受け付ける。次いで、ステップＳ１１４では、アクセス制御ポリシー管理部２２が、アクセス制御ポリシーＴＢＬ３２を参照して、アクセス制御ポリシーを確認する（図７の（２）参照）。次いで、ステップＳ１１６では、記述定義ＴＢＬ３３等を参照して、検証に必要なデータと確認内容を確定する（図７の（３）参照）。
【００３７】
次いで、ステップＳ１１８では、アクセス制御部２０が、端末Ｔｂの情報管理部４２に対して、ステップＳ１１６で確定した検証に必要なデータを要求する（図７の（４）参照）。ここでは、前述したように、アクセス制御ポリシーでは、店舗電話番号のラベルが付されているデータ（電話番号）が検証に必要なデータとなっている。
【００３８】
上記端末Ｔａの処理の間、端末Ｔｂでは、ステップＳ１４において、端末Ｔａからの要求があるまで待機している。そして、ステップＳ１１８においてアクセス制御部２０からの要求があると、ステップＳ１６に移行する。
【００３９】
ステップＳ１６では、情報管理部４２が、データ要求を受け付ける。次いで、ステップＳ１８では、情報管理部４２が、端末Ｔｂが保有するデータの中から、アクセス制御部２０により要求されたデータのうち、利用者Ｂが無制限に公開しているデータを選択して、送信する（図７の（５）参照）。ここで、情報管理部４２からアクセス制御部２０に対して送信されたデータは、図８（ａ）のような店舗電話番号（Ｌｂ１，Ｌｂ２）であったものとする。なお、端末Ｔｂ側では、これ以降、ステップＳ２０において、次に端末Ｔａからデータ等が送られてくるまで待機する。
【００４０】
なお、端末Ｔａのアクセス制御部２０は、ステップＳ１１８の処理以降は、ステップＳ１２０において、データを受信するまで待機している。したがって、アクセス制御部２０は、ステップＳ１８において端末Ｔｂ側からデータが送信されてきた段階で、ステップＳ１２２に移行する。
【００４１】
ステップＳ１２２では、アクセス制御部２０は、端末Ｔｂ側から送信されてきたデータを受け付ける。次いで、ステップＳ１２４では、アクセス制御部２０の指示の下、比較照合部２４が、端末Ｔａ，Ｔｂのデータを用いた比較照合を実行する（図７の（６）参照）。この場合、比較照合部２４は、端末Ｔａが保有する店舗電話番号をアクセス制御部２０を介して情報管理部２６（ＩＳ検証用データＴＢＬ３７）から取得する。なお、比較照合部２４が取得した店舗電話番号は、図８（ｂ）に示す電話番号であったものとする。そして、比較照合部２４は、ステップＳ１２２で受け付けたデータ（端末Ｔｂが保有する店舗電話番号（図８（ｂ）参照））と比較照合する。この場合、比較照合部２４は、比較照合により、図８（ｃ）の表のような照合結果を得ることができる。なお、図８（ｃ）の表では、「０」が、電話番号の不一致を示し、「１」が、電話番号の一致を示す。
【００４２】
次いで、ステップＳ１２６では、アクセス制御部２０が、アクセスＯＫであるか（アクセスを許可するか）否かを判断する。この場合、アクセス制御部２０は、アクセス制御ポリシー（端末Ｔａ，Ｔｂにおいて同一の店舗電話番号を最低１つ保有）を満たしているか否かを判断する。ここでは、図８（ｃ）より、店舗電話番号Ｌａ３とＬｂ２が同一である。したがって、アクセス制御部２０は、アクセスを許可すると判断する。なお、この場合のＩＳ一致傾向（ｘ／１００）は、最大（１００／１００）であるといえる。この場合、アクセス制御部２０は、ステップＳ１２８において、端末Ｔｂのリソースリクエスト部４０に対して、リソースを応答する（図７の（７）参照）。
【００４３】
この端末Ｔａ側からのリソースの応答により、端末Ｔｂでは、ステップＳ２０の判断が肯定されて、ステップＳ２２に移行する。そして、リソースリクエスト部４０は、ステップＳ２２においてリソースの受付を行う。これにより、端末Ｔｂ側では、リソースに対するアクセスが可能となるため、利用者Ｂは、端末Ｔｂのユーザインタフェース部１９３を介して、自店舗の情報の書き換えを行うことが可能となる。
【００４４】
一方、端末Ｔａ側において、ステップＳ１２６の判断が否定された場合、すなわち、アクセスがＮＧであると判断された場合には、ステップＳ１３０に移行する。アクセス制御部２０は、ステップＳ１３０において、アクセスがＮＧ（アクセス不可）である旨のメッセージを端末Ｔｂのリソースリクエスト部４０に対して回答する（図７の（８）参照）。この回答があった場合、端末Ｔｂでは、ステップＳ２０の判断が肯定されて、ステップＳ２２に移行する。そして、ステップＳ２２では、リソースリクエスト部４０が、アクセスがＮＧであることのメッセージの受付を行う。これにより、端末Ｔｂ側では、端末Ｔａへのアクセスができない旨のメッセージをユーザインタフェース部１９３に表示することが可能となる。
【００４５】
なお、これまでの説明から明らかなように、アクセス制御部２０は、制御部としての機能を有している。また、アクセス制御部２０と情報管理部２６とにより、取得部としての機能が実現されている。更に、アクセス制御部２０と比較照合部２４とにより、判断部としての機能が実現されている。
【００４６】
以上、詳細に説明したように、本第１の実施形態によると、アクセス制御ポリシー管理部２２が、リソースを保持する端末Ｔａから得られる特定の情報（例えば店舗電話番号）とリソースに対するアクセスを要求する端末Ｔｂから得られる特定の情報（例えば店舗電話番号）との類似性（アイデンティティ類似性（ＩＳ））で定義される、リソースに対するアクセス制御ポリシーを管理している。また、アクセス制御部２０が、アクセス制御ポリシーに基づいて、端末Ｔａ及び端末Ｔｂから特定の情報（例えば店舗電話番号）を取得し、当該取得された各情報の類似性が検証条件を満たすか否かを検証することで、端末Ｔｂからのリソースに対するアクセスが可能か否かを判断する。これにより、本第１の実施形態では、リソースに対するアクセスを要求する端末を個別に特定することなく、リソースに対するアクセスの可否を判断することが可能となる。したがって、アクセス制御対象の端末やユーザごとの登録が不要となり、登録の手間や登録に要する時間を低減することができるとともに、アクセス可否の単位を、検証条件を満たす端末やユーザという大まかな範囲とすることができる。
【００４７】
また、本第１の実施形態では、アクセス制御部２０が、アクセス可否の判断結果に基づいてアクセス制御を行うので、端末Ｔｂ自体を登録しなくても、端末Ｔｂからのアクセスを適切に制御することが可能となる。
【００４８】
また、本第１の実施形態では、アクセス制御ポリシーを適宜変更することで、種々のアクセス制御が可能である。一例として、以下のようなアクセス制御が可能である。
（１） 同一エリアに居住している住人であれば、位置情報付きの風景写真に対するアクセスを可能とする。
（２） 同じエリアに住んでいない人（土地勘の無い人）であれば、自己のブログへのアクセスを可能とする。
（３） 仕事関係の共通の知人が多ければ、仕事用プロフィールの閲覧を可能とする。
【００４９】
なお、上記第１の実施形態では、ＩＳ検証用データとして電話番号のような完全一致検証ができるデータを用いることとしたが、これに限られるものではない。例えば、ＩＳ検証用データとしては、類似度を検証できるデータ（例えば、住所）を用いることとしても良い。この場合においても、図８（ｃ）のようなマトリクスを用いることで、比較照合が可能となる。ただし、マトリクスの各格子にどのような計算結果が入るかは、用いる類似度関数に依存し、用意された類似度関数中のどの関数を使用するかは、用いるＩＳ検証用データのラベルや確認したい内容によって異なる。この場合、アクセス制御部２０では、マトリクスに入力される数値を用いて、所定の演算によりＩＳ一致傾向（＝ｘ／１００）を算出し、当該ＩＳ一致傾向が所定の閾値よりも大きい場合（すなわち、アクセス制御条件を満たす場合）に、アクセスを許可するなどの制御をすることができる。
【００５０】
《第２の実施形態》
以下、第２の実施形態について、図９に基づいて説明する。本第２の実施形態では、アクセス制御部２０が一度認証した場合（アクセスを許可した場合）に、当該認証結果を証明書として発行し、証明書を受け取った端末では、次回以降の認証において、当該証明書を用いて認証を行うこととする。
【００５１】
図９には、第２の実施形態に係る端末Ｔａ、Ｔｂの機能ブロック図が示されている（第２の実施形態で新たに追加された機能については、太線で表示している）。図９に示すように、端末Ｔａは、第１の実施形態で説明した各部に加え、証明書発行部２８と、証明書ＤＢ３９と、を備えている。また、端末Ｔｂは、第１の実施形態で説明した各部に加え、証明書管理部４４と、証明書ＤＢ４６と、を備えている。
【００５２】
証明書発行部２８は、アクセス制御部２０が一度アクセスを許可した場合に、当該アクセス許可情報（認証情報）をアクセス制御部２０から受け取り、証明書を発行して、証明書ＤＢ３９に格納する。なお、証明書には、リソースに対するアクセス許可がいつなされたのか、を示すための情報が基本情報として含まれているものとする。また、証明書発行部２８は、発行した証明書をアクセス制御部２０を介して、リソースリクエスト部４０に送信する。
【００５３】
証明書管理部４４は、リソースリクエスト部４０から証明書を受け取り、証明書ＤＢ４６に格納する。また、証明書管理部４４は、リソースリクエスト部４０がアクセス制御部２０に対してアクセスをリクエストする際には、証明書ＤＢ４６から証明書を読み出して、リソースリクエスト部４０に受け渡す。なお、リソースリクエスト部４０は、アクセス制御部２０に対してアクセスをリクエストする際に、証明書をアクセス制御部２０に対して送信する。
【００５４】
なお、端末Ｔｂ側の証明書ＤＢ４６において管理される証明書は、端末Ｔａ側の証明書ＤＢ３９で管理する証明書の全てのデータを含んでいてもよいし、証明書ＤＢ３９で管理する証明書と紐付ける情報のみであってもよい。また、証明書には、検証用データ（上記第１の実施形態の例では、店舗電話番号）がどの程度信頼できるデータであるかを示す情報を含めてもよい。この場合、例えば、検証用データとしてＧＰＳラベルのついたデータを用いた場合であれば、単に比較に用いた緯度や経度の情報だけでなく、それらの情報がいつ取得された情報なのか、どの端末によって取得された情報なのか、というメタデータに相当する情報を証明書に含めておくこととしてもよい。これらの情報を用いることで、認証結果の信頼性を推量することが可能となる。また、証明書発行部２８は、上記メタデータに相当する情報に基づいて、不確かなデータであることを判別できるような場合には、証明書を発行しないこととしてもよい。
【００５５】
また、証明書には、一般的な証明書同様、有効期限を設けることができる。この場合、証明書発行部２８は、検証用データの信頼性が高ければ証明書の有効期限を長くし、そうでなければ短くするなどしてもよい。
【００５６】
また、証明書の不正な乱用を避けるため、アクセス制御部２０は、証明書ＤＢ３９において、証明書と紐付けて使用回数情報（カウンタ）を管理することとしてもよい。この場合、アクセス制御部２０は、証明書使用の度にカウントアップすることで、使用上限値に達した証明書の使用を停止するなどしてもよい。
【００５７】
なお、アクセス制御部２０は、あるリソースのアクセス制御において発行した証明書を、他のリソースに対するアクセス制御に流用することとしてもよい。この場合、アクセス制御部２０は、共通する検証文を有するリソース間において、他のリソースの証明書の流用を許可するなどすればよい。
【００５８】
なお、アクセス制御ポリシーが改変された場合、提示された証明書の情報では、改変後の検証文をクリアするのに必要なデータを満足しない場合がある。このような場合には、アクセス制御部２０は、端末Ｔｂの情報管理部４２に対して不足しているデータの提供を求めるものとする。そして、情報管理部４２は、無条件に公開されている情報を優先して、アクセス制御部２０に対して提供するようにする。ただし、当該提供では認証が成功しない場合もある。このような場合には、情報管理部４２は、端末Ｔｂのユーザインタフェース部１９３を通じて端末Ｔｂの利用者Ｂに直接データ開示の確認を行い、確認が取れた後に非公開の情報を提供するようにしてもよい。なお、情報管理部４２は、端末Ｔｂ上で管理されていない情報であっても、外部のセンサやサービスが提供している情報群を新たに取得して、アクセス制御部２０に対して提供することとしてもよい。
【００５９】
以上説明したように、本第２の実施形態によると、証明書発行部２８は、アクセス制御部２０が端末Ｔｂからのアクセスが可能と判断した場合に、端末Ｔｂに対して証明書を発行し、これ以降、アクセス制御部２０は、端末Ｔｂから証明書が提示された場合にも、端末Ｔｂのアクセスを許可する。これにより、１度アクセス可能と判断した端末の、以降の認証を簡素化することができる。これにより、アクセス制御の簡素化及び時間短縮を図ることができる。また、証明書に種々の情報を含めることで、上述したような様々なアクセス制御が可能となる。
【００６０】
《第３の実施形態》
以下、第３の実施形態について、図１０〜図１２に基づいて説明する。本第３の実施形態では、上記第１、第２の実施形態と異なり、複数種類のデータに基づいたアクセス制御が行われるものとする。なお、本第３の実施形態では、図１０のような情報処理システムにおけるアクセス制御を行うものとする。この場合、前述した端末Ｔａのアクセス制御に関する機能（アクセス制御部２０、アクセス制御ポリシー管理部２２、比較照合部２４、情報管理部２６）は、図１０のサーバ２００に設けられているものとする。
【００６１】
サーバ２００は、端末Ｔａの利用者Ａのリソースを保持している。また、サーバ２００は、端末Ｔｂからのリソースに対するアクセス制御を、端末Ｔａが保有する特定の情報（実際にはサーバ２００上に存在）と、端末Ｔｂが保有する特定の情報（サーバ２００上に存在）とに基づいて、判断するものとする。なお、各端末Ｔａ，Ｔｂが保有する特定の情報は、各端末Ｔａ，Ｔｂの内部の記憶部等に格納されていてもよい。
【００６２】
以下、端末Ｔａの利用者Ａが会社を退職した場合において、利用者Ａのデータ（リソース）へのアクセスをアイデンティティ類似性（ＩＳ）に基づいて制御する例について説明する。この場合の前提として、利用者Ａは、退職前にサーバ２００に残すデータを全ての部署員に開示するのではなく、同じプロジェクトに関連している人（後述する検証文Ｓａ１を満たす人）にのみ開示しようとしている。また、プロジェクトで共用しているデータ等は、他の同僚も持っているので引き継がなくても問題ないが、利用者Ａが担当していた範囲の個人的な備忘録などは、同じ仕事に携わる人がアクセスできるようにしようとしている。なお、利用者Ａの退職後にプロジェクトに新たに参加する人等には、事前にデータを渡すことができず、また、当該新たに参加する人を個別に指定してサーバに登録するなどすることはできない。したがって、本第３の実施形態においても、上記第１、第２の実施形態と同様、アクセス制御ポリシーを用いるものとする。
【００６３】
本第３の実施形態では、記述定義の検証文Ｓａ１において、図１１（ａ）に示すCond-a1とCond-a2の２つが同時に成立する場合にアクセス可能とする検証条件が定義されているものとする。
【００６４】
ここで、Cond-a1で用いるデータは、プロジェクトＭＬラベルのメールアドレスである。Cond-a1では、端末Ｔａ（リソース権利者側）の保有するプロジェクトＭＬラベルのメールアドレスと、端末Ｔｂ（リソース要求者側）の保有するプロジェクトＭＬラベルのメールアドレスとが１つ以上一致することが条件とされている。一方、Cond-a2で用いるデータは、プロジェクトラベルの付与されたフォルダのファイルハッシュである。Cond-a2では、端末Ｔａの保有するプロジェクトラベルの付与されたフォルダのファイルハッシュと、端末Ｔｂの保有するプロジェクトラベルの付与されたフォルダのファイルハッシュとが１つ以上一致することが条件とされている。
【００６５】
なお、利用者Ａは、退職前に、自動で集計登録されたプロジェクトＭＬラベルのメールアドレスから不要なアドレスを削除しているものとする。また、利用者Ａは、退職前に、プロジェクトラベルのフォルダとしてピックアップされたフォルダから不要なフォルダを削除しているものとする。
【００６６】
以下、上記のような状況下において、端末Ｔｂから、端末Ｔａが保有するプロジェクトに関するリソースに対してアクセスがあった場合の、サーバ２００（主にアクセス制御部２０）によるアクセス制御について説明する。
【００６７】
利用者Ａの退職後、プロジェクトに参加した利用者Ｂは、利用者Ａの仕事を引き継ぐこととなり、どういう蓄積データがあるのかを確認しようと、プロジェクト（projectA）に関するフォルダ（例えば/home/userA/project/2011/projectA）に、端末Ｔｂを介してアクセスしたとする。この場合、サーバ２００のアクセス制御部２０は、アクセス制御ポリシー管理部２２で管理されているアクセス制御ポリシーの検証条件（図１１（ａ）参照）を参照する。そして、アクセス制御部２０は、検証条件に基づいて、端末Ｔｂが保有するプロジェクトＭＬラベルのメールアドレスと、プロジェクトラベルフォルダprojectA以下のファイルハッシュと、を取得する（図１１（ｂ）参照）。また、アクセス制御部２０は、端末Ｔａが保有するプロジェクトＭＬラベルのメールアドレスと、プロジェクトラベルフォルダprojectA以下のファイルハッシュと、を取得する（図１１（ｃ）参照）。
【００６８】
そして、比較照合部２４は、アクセス制御部２０の指示の下、取得された各メールアドレス及び各ファイルハッシュを比較照合する。図１２（ａ）には、プロジェクトＭＬラベルのメールアドレスの比較照合結果（検証結果）が示され、図１２（ｂ）には、プロジェクトラベルフォルダprojectA以下のファイルハッシュの比較照合結果（検証結果）が示されている。これら図１２（ａ）、図１２（ｂ）では、アドレスやファイルハッシュが一致している場合に値「１」が入力され、不一致の場合に値「０」が入力される。この場合、図１２（ａ）及び図１２（ｂ）の検証結果には、値「１」が存在している（１つ以上の一致がある）。したがって、アクセス制御部２０は、アクセス制御ポリシーに基づいて、projectAに関するフォルダ（/home/userA/project/2011/projectA）に対する、端末Ｔｂのアクセスを許可する。このようにすることで、新たにプロジェクトに参加した利用者Ｂは、利用者Ａが退職前に残したデータにアクセスできるようになる。
【００６９】
以上説明したように、本第３の実施形態によると、アクセス制御ポリシーは、複数種類のデータ（プロジェクトＭＬラベルのメールアドレスとプロジェクトラベルフォルダ以下のファイルハッシュ）に関する類似性（共通性）で定義されており、アクセス制御部２０は、端末Ｔａ、Ｔｂから複数種類のデータを取得し、アクセス制御を行う。このように、複数種類のデータを用いたアクセス制御を行うことで、精度の高いアクセス制御の実現が可能となる。
【００７０】
なお、上記第３の実施形態においては、アクセス制御部２０が、自動的にメールアドレスやファイルハッシュを取得する場合について説明したが、これに限られるものではない。アクセス制御部２０は、端末Ｔｂのユーザインタフェース部１９３を介して、利用者Ｂに対してメールアドレスやファイルハッシュの提示を求めるようにしてもよい。この場合、利用者Ｂは、具体的に何を提示すればよいのかを理解できない場合もあると考えられる。このような場合に備え、アクセス制御部２０は、メールアドレスやファイルハッシュの提示を求める場合に、ユーザインタフェース部１９３（例えばディスプレイ）上に詳細メッセージを表示するためのボタン等を表示してもよい。そして、アクセス制御部２０は、利用者Ｂによってボタンが押された場合に「プロジェクト（projectA）に関連するファイルを１つ以上提示すること」などとユーザインタフェース部１９３を介して表示するようにしてもよい。なお、利用者Ｂは、求められたデータを端末Ｔｂ上から選択することとしてもよいが、求められたデータをユーザインタフェース部１９３を介して新たに入力することとしてもよい。
【００７１】
なお、上述したようにアクセス制御部２０が自動的にメールアドレスやファイルハッシュを取得する場合であっても、自動取得後に、利用者Ｂがメールアドレスやファイルハッシュの追加・変更等を行えるようにしてもよい。この場合、意図と異なる検証用データがアクセス制御部２０により取得された場合でも、当該検証用データの修正ができるので、利用者の利便性を向上することができる。また、これとは逆に、メールアドレスやファイルハッシュの自動取得後における追加・変更を一切禁止するようにしてもよい。この場合、利用者本人の利用状況を正確に反映させた検証用データを作成することが可能となる。
【００７２】
なお、上記第３の実施形態では、アクセス制御部２０が、プロジェクトＭＬラベルのメールアドレスと、プロジェクトラベルフォルダ以下のファイルハッシュの２種類のデータに基づいてアクセス制御を行う場合について説明した。しかしながら、これに限られるものではなく、上記以外のデータや、３種類以上のデータに基づいて、アクセス制御を行うようにしてもよい。
【００７３】
《第４の実施形態》
次に、第４の実施形態について、図１３に基づいて説明する。本第４の実施形態では、検証条件として検証文を用いずに、各端末が保有するデータそのものをアクセス制御ポリシーに記述する点に特徴を有する。なお、装置構成は、第１の実施形態と同様であるものとする。
【００７４】
図１３（ａ）には、本第４の実施形態で用いるアクセス制御ポリシーの一例が示されている。この図１３（ａ）は、ある利用者Ａが、自分の端末Ｔａ内のアドレス帳の情報更新を「山田太郎」さんに許可する場合の例である。この場合、更新を許可する対象者が曖昧でなく、特定の人物であるので、特定の人物のみがアクセス可能となるように条件が記述することができる。すなわち、アクセス制御に用いるデータは、図１３（ａ）のアクセス制御ポリシーに記述されている確認データ（「山田太郎」など）となる。なお、図１３（ａ）の例では、名前や電話番号などの、山田太郎さんの個人情報を全て知っている（入力できる）利用者のみが、アドレス帳の情報更新を行うことが可能となる。
【００７５】
なお、セキュリティ上の安全を確保するため、図１３（ｂ）に示すように、確認データを符号化してもよい。図１３（ｂ）の例では、符号化後のデータはハッシュ値となっている。なお、確認データを符号化する場合には、使用する確認対象に合わせて符号化するようにしてもよい。例えば、データの一致を確認すればよい場合（類似度の確認が不要の場合）には、全体のハッシュをとるだけで問題ないが、住所データのように階層構造を持ったデータの場合には、図１３（ｃ）のように階層毎に符号化してもよい。この場合、例えば、“神奈川県川崎市”と“神奈川県”が県レベルで同じ情報であることを示すことができる。
【００７６】
なお、上記第４の実施形態では、第３の実施形態と同様の装置構成（サーバ２００がアクセス制御を行う構成）を採用してもよい。
【００７７】
《第５の実施形態》
次に、第５の実施形態について、図１４、図１５に基づいて説明する。なお、本第５の実施形態の装置構成は、上述した第１の実施形態と同様の装置構成であるものとする。本第５の実施形態は、端末Ｔｂが保有するデータを、端末Ｔａに対して秘匿化して送信する場合の例である。
【００７８】
上述した第１の実施形態のように、会員登録している店舗の電話番号リストを店舗の端末に送信するのは利用者にとって然程問題にならない可能性が高い。しかしながら、送信するデータが、例えば、友人の電話番号のリストである場合には、利用者が実データを送信するのに躊躇するおそれがある。このような場合などにおいて、本第５の実施形態を用いることができる。
【００７９】
ここでは、端末Ｔａの利用者Ａと端末Ｔｂの利用者Ｂが初めて出会った場合に、利用者Ａと利用者Ｂに共通の知人が多ければ、利用者Ｂに対して、利用者Ａが作成したプロフィールへの参照権限を与える例について説明する。
【００８０】
この場合、アクセス制御部２０は、利用者Ａ，Ｂが保有する電話番号ラベルのついたＩＳ検証データ（電話番号データ）を互いに開示することなく比較し、共通する電話番号の個数を知る必要がある。
【００８１】
図１４は、端末Ｔｂ及びＴａにおける処理を示すフローチャートである。なお、図１４の処理は、基本的には、第１の実施形態（図６）と同様となっている。図１４の処理では、まず、初めて会った利用者Ａ（端末Ｔａ）に対して、利用者Ｂ（端末Ｔｂ）がプロフィール情報をリクエストする（ステップＳ１２）。次いで、端末Ｔａのアクセス制御部２０が、利用者Ａのアクセス制御ポリシーから、検証文：共通の知人が多い、を検証する。この場合、使用するデータは、電話番号ラベルの付いた電話番号データである。また、本第５の実施形態では、秘匿化関数を用いた検証を行うことがアクセス制御ポリシーにおいて定義されているものとする。このため、アクセス制御部２０は、ステップＳ１１８における端末Ｔｂに対するデータの要求の際には、図１５中の手続きＡ１の実行により生成される秘匿化ＩＳ検証用データＳａを付加して、検証に必要な電話番号ラベルの付いた電話番号データの要求を送付する。
【００８２】
これに対し、利用者Ｂ側では、情報管理部４２が、秘匿化関数を用いた場合に送付できる範囲で、電話番号ラベルのＩＳ検証データ（電話番号データ）を用いて、図１５の手続きＢを実行する。そして、情報管理部４２は、秘匿化ＩＳ検証データＳｂを利用者Ａに返却する（ステップＳ１８）。
【００８３】
また、利用者Ａ側では、アクセス制御部２０が、端末Ｔｂ側から受領した秘匿化ＩＳ検証データＳｂを用いて図１５中の手続きＡ２を実行し、０になった個数を取得する（ステップＳ１２４）。ここで、手続きＡ２の結果、０になった個数は、双方のＩＳ検証データ中で一致していたものの個数を意味する。この場合、アクセス制御部２０は、共通の電話番号の個数が多ければ（一致割合が所定の閾値よりも多ければ）、共通の知人が多いと判断し、利用者Ｂに対して利用者Ａが作成したプロフィールへの参照権限を付与する。
【００８４】
以上説明したように、本第５の実施形態では、アクセス制御部２０は、図１４の処理を行うことで、実質的に、端末Ｔａが保有する電話番号データを秘匿化したデータと、端末Ｔｂが保有する電話番号データを秘匿化したデータとを取得し、その一致割合に基づいて、端末Ｔｂによるアクセス制御を行っているといえる。これにより、本第５の実施形態では、各端末で保有しているデータを他の端末に対して一切明かすことなく、アクセス制御を行うことが可能となる。
【００８５】
《第６の実施形態》
次に、第６の実施形態について、図１６に基づいて説明する。本第６の実施形態の装置構成は、第１の実施形態と同様の装置構成となっている。第６の実施形態は、データをプロフィールや名刺、会員証等テンプレート毎に管理し、かつテンプレート単位で符号化を行うものである。
【００８６】
ここで、本第６の実施形態では、前述した第５の実施形態と同様、検証文「共通の知人が多い」を、プロフィール情報の一致割合に基づいて確認するものとする。ただし、本第６の実施形態では、利用者Ａの端末Ｔａと利用者Ｂの端末Ｔｂが保有する電話番号同士を比較するのではなく、保持しているプロフィール全体の情報を用いた比較を行う。例えば、アクセス制御部２０は、端末Ｔａが保有するプロフィールとして、図１６（ａ）に示すプロフィールを取得し、端末Ｔｂが保有するプロフィールとして、図１６（ｂ）に示すプロフィールを取得したものとする。
【００８７】
プロフィールのようにＩＳ検証用データの１つ１つの項目中に更に住所や名前といった詳細データが含まれる場合であっても、各項目の類似度を算出する段階では、上述した各実施形態と同様、項目と項目、つまり、プロフィールとプロフィールの比較を行えばよい。この場合、アクセス制御部２０は、図１６（ｃ）に示すような検証結果（類似度マトリクス）を得ることができる。この図１６（ｃ）の検証結果では、類似度マトリクスの各格子に各プロフィール相互の類似度が入力されている。なお、検証関数が、一致・不一致だけを見る場合には、プロフィールを符号化し、符合化後のデータ（ファイルハッシュ値）を比較した結果（値「１」又は「０」）を類似度マトリクスの各格子に入力するようにすればよい。
【００８８】
なお、アクセス制御部２０は、図１６（ｃ）の検証結果から、所定の演算方法を用いてＩＳ一致傾向（＝ｘ／１００）を算出し、当該ＩＳ一致傾向に基づいて、端末Ｔｂからのアクセスの許可・不許可を判断する。なお、ＩＳ一致傾向の演算方法としては、例えば、図１６（ｃ）の各格子に入力されている類似度の平均を算出する方法などを採用することができる。
【００８９】
以上、説明したように、本第６の実施形態によると、プロフィールなどのデータの集合の類似度に基づいてアクセス制御を行うので、上記各実施形態と同様、ユーザ登録等を行うことなく適切なアクセス制御を行うことが可能となる。
【００９０】
《第７の実施形態》
次に、第７の実施形態について、図１７に基づいて説明する。本第７の実施形態の装置構成は、上記第１の実施形態の装置構成と同様となっている。また、本第７の実施形態は、ＩＳ検証データのデータ量を縮退することを目的としている。
【００９１】
図１７は、本第７の実施形態におけるデータの縮退イメージを示す図である。本実施形態では、情報管理部２６、４２では、電話番号のデータをアクセス制御部２０に対して送信する前に、図１７（ａ）に示すように符号化する。なお、図１７（ａ）では、電話番号のデータをハッシュ化した例（Hash(data1)、Hash(data2)、…）が示されている。そして、情報管理部２６、４２は、ハッシュ化したデータ（Hash(data1)、Hash(data2)、…）それぞれに含まれる文字（０，１，２，…ｅ，ｆ）の個数をカウントし、それらを並べたものを縮退データＬ１、Ｌ２…とする（図１７（ｂ）参照）。なお、ＩＳ検証データとしては、全ての縮退データから重複のないようにデータを集計する。情報管理部２６，４２は、図１７（ｂ）のような縮退データをアクセス制御部２０に対して送信するものとする。
【００９２】
そして、アクセス制御部２０では、利用者Ａ（端末Ｔａ）側で生成されるＣａ（図１７（ｃ）参照）と、Ｃａと同様にして利用者Ｂ（端末Ｔｂ）側で生成されるＣｂとの一致・不一致を検証する。ここで、利用者Ａ側と利用者Ｂ側内の元の電話番号が同じであった場合には、そのハッシュ値及び、Ｃａ、Ｃｂ中の対応する縮退データも一致することを意味する。したがって、本第７の実施形態では、アクセス制御部２０が、ＣａとＣｂとを比較することで、大まかな電話番号の一致個数を検証することができる。
【００９３】
以上のように、本第７の実施形態によると、ハッシュ値に含まれる各文字の個数を用いて検証に用いるデータ量を縮退させるので、ハッシュ値そのものを端末間でやり取りする場合よりもデータ量を低減することができる。また、データ量の低減により検証に要する時間を短縮することができる。
【００９４】
《第８の実施形態》
次に、第８の実施形態について、図１８に基づいて説明する。本第８の実施形態では、第２の実施形態と同様に、一度アクセスを許可した端末に対して、リソースを保持する端末から証明書を発行するものとする。すなわち、本第８の実施形態の装置構成は、第２の実施形態の装置構成（図９）と同様であるものとする。
【００９５】
本第８の実施形態では、アクセス制御部２０での認証が完了した後、証明書発行部２８は証明書（「ＣＴａ」とする）を発行する。この場合、アクセス制御部２０は、証明書ＣＴａを端末Ｔｂのリソースリクエスト部４０にそのまま送信するのではなく、証明書ＣＴａを例えば３つの分割証明書（ＤＣＴａ１、ＤＣＴａ２、ＤＣＴａ３）に変換して送信することとする。
【００９６】
この場合の各分割証明書の内容は、単純に証明書ＣＴａのハッシュ値を等分に分けたものでも良い。また、(ｋ,ｎ)しきい値秘密分散法を用いて、例えばｎ個の分割証明書のうち、ｋ個を利用者が保持していた場合には、証明書ＣＴａを復元できるようにしてもよい。なお、秘密分散法を用いる場合のデータの例は、図１８に示されている。図１８に示すように、（ｋ−１）次の多項式を作ることで、分割符号情報をｋ個集めて、連立方程式を解くことで、元の証明書を復元することが可能となっている。ここで、秘密分散法を用いた分割符号証明書は、複数の利用者に証明書ＣＴａをばら撒きたいが、人によって使用する分割符号証明書を変えたい場合や、１人の利用者が状況や場所に合わせて使用する分割符合証明書を変えたい場合に用いることができる。
【００９７】
ただし、証明書のハッシュ値を等分に分割して分割証明書（ＤＣＴａ１、ＤＣＴａ２、ＤＣＴａ３）を作成した場合、その一部を提示するのみでは、証明書ＣＴａのハッシュ値から生成された分割証明書を保有していることを完全に証明することはできない。すなわち、単にリソースを要求する利用者Ｂが提示した分割証明書（ＤＣＴａ１）が、証明書ＣＴａのハッシュ値の一部と合致することが証明できるだけである。そのため、アクセス制御部２０は、上記のように証明が完全でない場合には、アクセス制御で提示する情報のレベルを下げるような運用を採用してもよい。また、このような運用を採用すれば、分割証明書の提出状況に応じて、端末Ｔｂのユーザインタフェース１９６上に表示可能なデータを制限できるので、利用者Ｂは、状況に合わせて分割証明書を使い分けることができる。例えば、利用者Ｂは、他人と一緒にいる場合には、一部の分割証明書のみを提出して、表示が制限された状態でデータ操作を行い、１人になったら、他の分割証明書を追加提出することで、表示制限を解除するようにしてもよい。
【００９８】
以上のように、本第８の実施形態では、分割証明書の少なくとも１つに基づいてアクセス制御を行うので、リソース要求者側（端末Ｔｂ側）から提出される分割証明書の数等に基づいて、種々のアクセス制御を行うことが可能となる。
【００９９】
なお、分割証明書は、公開用の分割証明書と、秘密裏に運用するための分割証明書にその役割を割り当てることもできる。例えば、利用者Ｂの作成した証明書をＣＴｂとし、当該証明書ＣＴｂの分割証明書をＤＣＴｂ１、ＤＣＴｂ２とする。そして、利用者Ａのブログデータを閲覧するには、利用者Ｂであることを証明する必要があるとする。この場合、まず、利用者Ｂは自分のブログ等において、分割証明書ＤＣＴｂ１を公開鍵のような形で公開する。これに対し、利用者Ａの端末Ｔａのアクセス制御ポリシー管理部２２は、アクセス制御ポリシーを作成するにあたって、利用者Ｂの公開している分割証明書ＤＣＴｂ１を取得・管理する。そして、利用者Ｂ（端末Ｔｂ）が利用者Ａのブログデータに対するアクセスを要求した場合には、アクセス制御部２０は、分割符合の組を要求する。
【０１００】
この場合、利用者Ｂは、秘密裏に管理されていた分割証明書ＤＣＴｂ２と、分割前の証明書ＣＴｂ１をアクセス制御部２０に対して提示する。アクセス制御部２０は、保管していた分割証明書ＤＣＴｂ１と受領した分割証明書ＤＣＴｂ２とで、証明書ＣＴｂ１が構成できるか否かを判定する。この場合において、証明書ＣＴｂ１が構成できると判定された場合には、アクセス制御部２０は、利用者Ｂによる、利用者Ａのブログデータの閲覧を許可することができる。
【０１０１】
なお、上述したように、受領した分割証明書の組み合わせによってアクセス制限をかけるために、秘密分散法で、復号(ＤＣＴａ１，ＤＣＴａ２)＝復号(ＤＣＴａ１，ＤＣＴａ３)＝復号（ＤＣＴａ２，ＤＣＴａ３）＝ＣＴａである分割証明書を用いる場合、（復号した情報，ＤＣＴａ１，ＤＣＴａ２)、（復号した情報，ＤＣＴａ１，ＤＣＴａ３）、（復号した情報，ＤＣＴａ２，ＤＣＴａ３）の組み合わせ毎に、付与する権限を変えるなどすることができる。この場合、各分割証明書を渡す段階において、どの分割証明書の組で、どのアクセス権限が付与されるのかを注意して配布する必要がある。
【０１０２】
《第９の実施形態》
次に、第９の実施形態について、図１９，図２０に基づいて説明する。なお、本第９の実施形態の装置構成は、第１の実施形態と同様であるものとする。本第９の実施形態は、検証に用いるデータ、もしくは、認証結果証明書、更にはそれらを分割符号化したものの配布に画像を用いる点に特徴を有している。
【０１０３】
図１９は、本第９の実施形態で用いられる、画像化された証明書の一例を示している。アクセス制御部２０は、第２の実施形態や第８の実施形態で説明した証明書、分割証明書のデータを、図１９に示すような画像データに加工し、端末Ｔｂ側に送信する。
【０１０４】
ここで、図１９の画像データは、証明書の２次元コードと、証明書を発行した人の写真とが関連付けられた状態となっている。このようにすることで、証明書を提示する場合であっても、２次元コード近傍の写真を見れば、どの利用者から得た証明書であったのかが一目瞭然であるので、適切な証明書の提出が可能となる。
【０１０５】
なお、証明書情報のみならず、単に利用者が保持しているプロフィール情報などの情報を画像化して保持させておいてもよい。この場合、前述した第４の実施形態のような場合において、画像化されたデータを用いて、アクセス制御ポリシーを記述することとしてもよい。
【０１０６】
また、前述した第６の実施形態のように、プロフィールや名刺毎のハッシュ値を比較検証に用いる場合に、検証に必要なデータとしてプロフィールや名刺のハッシュ値を提供する場合にも、画像化されたデータを用いることができる。図２０には、認証時に携帯電話の電話帳情報を画像化してアクセス制御装置に提示するイメージの一例を示している。例えば、認証の際に、図２０（ａ）のような画面が端末Ｔｂのユーザインタフェース部１９３上に表示されるとする。そして、利用者Ｂによって電話帳読み込みボタンが押され、かつ図２０（ｂ）のように電話帳の一部が選択された後に再度電話帳読み込みボタンが押されたとする。この場合、情報管理部４２は、選択された電話帳の一部のデータ（テキストデータ）に基づいて、図２０（ｃ）に示すような画像を生成する。そして、利用者Ｂによって認証のボタンが押されると、情報管理部４２は、当該画像を端末Ｔａのアクセス制御部２０に送信する。この場合、アクセス制御部２０では、送信されてきた画像を用いてアクセス制御を行うこととなる。
【０１０７】
なお、上記各実施形態は、適宜組み合わせることができる。一例として、第３の実施形態のように複数種類のデータを用いてアクセス制御を行うという概念は、その他の実施形態においても適用することができる。
【０１０８】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
【０１０９】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１１０】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１１１】
上述した各実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【０１１２】
なお、以上の説明に関して更に以下の付記を開示する。
（付記１） リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得し、
前記アクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得し、
前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する、処理をコンピュータに実行させることを特徴とするアクセス制御プログラム。
（付記２） 前記判断する処理における判断結果に基づいて、前記第２端末のアクセス制御を行う処理を前記コンピュータに更に実行させることを特徴とする付記１に記載のアクセス制御プログラム。
（付記３） 前記判断する処理において前記第２端末からの前記リソースに対するアクセスが可能と判断した場合に、前記第２端末に対して証明書を発行する処理を、前記コンピュータに更に実行させ、
前記判断する処理では、前記第２端末から前記証明書が提示された場合にも、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記１又は２に記載のアクセス制御プログラム。
（付記４） 前記証明書を発行する処理では、証明書を分割して発行し、
前記判断する処理では、前記分割された証明書の少なくとも一部が提示された場合に、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記３に記載のアクセス制御プログラム。
（付記５） 前記アクセス制御条件は、複数種類の特定の情報に関する類似性で定義され、
前記取得する処理では、前記第１、第２端末から前記複数種類の特定の情報を取得することを特徴とする付記１〜４のいずれかに記載のアクセス制御プログラム。
（付記６） 前記取得する処理では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、
前記判断する処理では、前記第１端末及び前記第２端末から取得した各符号化した情報の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記１〜５のいずれかに記載のアクセス制御プログラム。
（付記７） 前記取得する処理では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、
前記判断する処理では、前記第１端末及び前記第２端末から取得した各文字の個数の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記１〜５のいずれかに記載のアクセス制御プログラム。
（付記８） 前記アクセス制御条件は、前記第１端末から得られる特定の情報の集合と前記第２端末から得られる特定の情報の集合との類似性で定義され、
前記取得する処理では、前記第１、第２端末から特定の情報の集合を取得し、
前記判断する処理では、前記第１、第２端末から取得した各情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする付記１〜７のいずれかに記載のアクセス制御プログラム。
（付記９） リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得工程と、
前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断工程と、をコンピュータが実行することを特徴とするアクセス制御方法。
（付記１０） 前記判断工程における判断結果に基づいて、前記第２端末のアクセス制御を行うアクセス制御工程を前記コンピュータが更に実行することを特徴とする付記９に記載のアクセス制御方法。
（付記１１） 前記判断工程において前記第２端末からの前記リソースに対するアクセスが可能と判断された場合に、前記第２端末に対して証明書を発行する証明書発行工程を、前記コンピュータが更に実行し、
前記判断工程では、前記第２端末から前記証明書が提示された場合にも、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記９又は１０に記載のアクセス制御方法。
（付記１２） 前記証明書発行工程では、証明書を分割して発行し、
前記判断工程では、前記分割された証明書の少なくとも一部が提示された場合に、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記１１に記載のアクセス制御方法。
（付記１３） 前記アクセス制御条件は、複数種類の特定の情報に関する類似性で定義され、
前記取得工程では、前記第１、第２端末から前記複数種類の特定の情報を取得することを特徴とする付記９〜１３のいずれかに記載のアクセス制御方法。
（付記１４） 前記取得工程では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、
前記判断工程では、前記第１端末及び前記第２端末から取得した各符号化した情報の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記９〜１３のいずれかに記載のアクセス制御方法。
（付記１５） 前記取得工程では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、
前記判断工程では、前記第１端末及び前記第２端末から取得した各文字の個数の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記９〜１３のいずれかに記載のアクセス制御方法。
（付記１６） 前記アクセス制御条件は、前記第１端末から得られる特定の情報の集合と前記第２端末から得られる特定の情報の集合との類似性で定義され、
前記取得工程では、前記第１、第２端末から特定の情報の集合を取得し、
前記判断工程では、前記第１、第２端末から取得した各情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする付記９〜１５のいずれかに記載のアクセス制御方法。
（付記１７） リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件を管理する管理部と、
前記アクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得部と、
前記取得部が前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断部と、を備えるアクセス制御装置。
（付記１８） 前記判断部による判断結果に基づいて、前記第２端末のアクセス制御を行う制御部を更に備える付記１７に記載のアクセス制御装置。
（付記１９） 前記判断部が前記第２端末からの前記リソースに対するアクセスが可能と判断した場合に、前記第２端末に対して証明書を発行する証明書発行部を更に備え、
前記判断部は、前記第２端末から前記証明書が提示された場合にも、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記１７又は１８に記載のアクセス制御装置。
（付記２０） 前記証明書発行部は、証明書を分割して発行し、
前記判断部は、前記分割された証明書の少なくとも一部が提示された場合に、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記１９に記載のアクセス制御装置。
（付記２１） 前記管理部は、複数種類の特定の情報に関する類似性で定義された前記アクセス制御条件を管理し、
前記取得部は、前記第１、第２端末から前記複数種類の特定の情報を取得することを特徴とする付記１７〜２０のいずれかに記載のアクセス制御装置。
（付記２２） 前記取得部は、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、
前記判断部は、前記第１端末及び前記第２端末から取得した各符号化した情報の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記１７〜２１のいずれかに記載のアクセス制御装置。
（付記２３） 前記取得部は、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、
前記判断部は、前記第１端末及び前記第２端末から取得した各文字の個数の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記１７〜２１のいずれかに記載のアクセス制御装置。
（付記２４） 前記管理部は、前記第１端末から得られる特定の情報の集合と前記第２端末から得られる特定の情報の集合との類似性で定義された前記アクセス制御条件を管理し、
前記取得部は、前記第１、第２端末から特定の情報の集合を取得し、
前記判断部は、前記取得部が前記第１、第２端末から取得した各情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする付記１７〜２３のいずれかに記載のアクセス制御装置。
【符号の説明】
【０１１３】
２０ アクセス制御部（取得部の一部、判断部の一部、制御部）
２２ アクセス制御ポリシー管理部（管理部）
２４ 比較照合部（取得部の一部）
２６ アクセス制御部（取得部の一部）
２８ 証明書発行部
Ｔａ 端末（第１端末）
Ｔｂ 端末（第２端末）
【技術分野】
【０００１】
本件は、アクセス制御プログラム、アクセス制御方法及びアクセス制御装置に関する。
【背景技術】
【０００２】
従来より、ある利用者に関するサービスに対して、他の利用者のアクセスを制限するシステムがある。当該システムとしては、例えば、ある利用者に関する個人情報を、参照者である他の利用者に開示する情報開示サービスシステムなどがある。
【０００３】
特許文献１には、友人や、同僚、上司といった既存の関係を有する人に対して当該関係に合わせたアクセスコードを配布することで、アクセス制御を行う方法が開示されている。この特許文献１では、リソースにアクセスするユーザをユーザ名や電子メールアドレスを使って一意に識別し、当該アクセスユーザとリソースの持ち主との既存関係をアクセスコードに反映し、配布することで、アクセス制御を行う。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−３４６２５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記特許文献１では、アクセスを許可又は拒否する人を一人一人システムに登録し、管理しておく必要があり、登録には手間と時間を要する。これに対し、各ユーザを登録、管理することなく、アクセスを許可するユーザを大まかに分類して指定することができるようになれば、今後、種々のシステムへの利用が期待できると考えられる。
【０００６】
そこで本件は上記の課題に鑑みてなされたものであり、リソースに対するアクセスを要求する端末を個別に特定することなく、アクセスの可否を判断可能なアクセス制御プログラム、アクセス制御方法及びアクセス制御装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本明細書に記載のアクセス制御プログラムは、リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得し、前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する、処理をコンピュータに実行させるアクセス制御プログラムである。
【０００８】
本明細書に記載のアクセス制御方法は、リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得工程と、前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断工程と、をコンピュータが実行するアクセス制御方法である。
【０００９】
本明細書に記載のアクセス制御装置は、リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件を管理する管理部と、前記アクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得部と、前記取得部が前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断部と、を備えるアクセス制御装置である。
【発明の効果】
【００１０】
本明細書に記載のアクセス制御プログラム、アクセス制御方法及びアクセス制御装置は、リソースに対するアクセスを要求する端末を個別に特定することなく、アクセスの可否を判断できるという効果を奏する。
【図面の簡単な説明】
【００１１】
【図１】一実施形態に係る情報処理システムの構成を概略的に示す図である。
【図２】図２（ａ）は、端末Ｔａのハードウェア構成図であり、図２（ｂ）は、端末Ｔｂのハードウェア構成図である。
【図３】端末Ｔａ，Ｔｂの機能ブロック図である。
【図４】図４（ａ）は、アクセス制御ポリシーＴＢＬを示す図であり、図４（ｂ）は、記述定義ＴＢＬを示す図であり、図４（ｃ）は、検証条件複合ＴＢＬを示す図である。
【図５】図５（ａ）は、検証条件ＴＢＬを示す図であり、図５（ｂ）は、Ｓｔｏｒｅ用プロパティＴＢＬを示す図であり、図５（ｃ）は、ＩＳ検証用データＴＢＬを示す図である。
【図６】端末Ｔａ，Ｔｂの処理を示すフローチャートである。
【図７】図６の処理及びデータの流れを示す図である。
【図８】図８（ａ）は、端末Ｔｂが保有する店舗電話番号ラベルの電話番号を示す図であり、図８（ｂ）は、端末Ｔａが保有する店舗電話番号ラベルの電話番号を示す図であり、図８（ｃ）は、検証結果を示す図である。
【図９】第２の実施形態に係る端末Ｔａ，Ｔｂの機能ブロック図である。
【図１０】第３の実施形態に係る情報処理システムの構成を示す図である。
【図１１】図１１（ａ）は、第３の実施形態に係る記述定義を示す図であり、図１１（ｂ）は、第３の実施形態において、端末Ｔｂから取得したデータを示す図であり、図１１（ｃ）は、第３の実施形態において、端末Ｔａから取得したデータを示す図である。
【図１２】図１２（ａ）は、プロジェクトＭＬラベルのメールアドレスの検証結果を示す図であり、図１２（ｂ）は、プロジェクトラベルフォルダ以下のハッシュファイルの検証結果を示す図である。
【図１３】図１３（ａ）は、第４の実施形態に係るアクセス制御ポリシーを示す図であり、図１３（ｂ）は、変形例に係るアクセス制御ポリシーを示す図であり、図１３（ｃ）は、符号化の一例を示す図である。
【図１４】第５の実施形態に係る端末Ｔａ，Ｔｂの処理を示すフローチャートである。
【図１５】図１４の処理における手続きを説明するための図である。
【図１６】図１６（ａ）は、第６の実施形態において端末Ｔａから取得したプロフィールであり、図１６（ｂ）は、第６の実施形態において端末Ｔｂから取得したプロフィールであり、図１６（ｃ）は、図１６（ａ）と図１６（ｂ）のデータを比較した検証結果を示す図である。
【図１７】図１７（ａ）〜図１７（ｃ）は、第７の実施形態を説明するための図である。
【図１８】第８の実施形態を説明するための図である。
【図１９】第９の実施形態において画像化された証明書を示す図である。
【図２０】図２０（ａ）〜図２０（ｃ）は、第９の実施形態の変形例を示す図である。
【発明を実施するための形態】
【００１２】
《第１の実施形態》
以下、第１の実施形態について、図１〜図８に基づいて詳細に説明する。
【００１３】
図１には、第１の実施形態に係る情報処理システム１００の構成が概略的に示されている。情報処理システム１００は、リソースの権利者が利用する第１端末としての端末Ｔａと、リソースの要求者が利用する第２端末としての端末Ｔｂと、を有している。これら端末Ｔａ，Ｔｂは、インターネットなどのネットワーク８０に接続されており、端末Ｔａ，Ｔｂ間における通信が可能な状態となっている。
【００１４】
ここで、「リソース」とは、アクセス制御対象の単位となるものを指す。例えば、Ｗｅｂサイトにおけるアクセス制御であれば、リソースは、各ＵＲＬで参照されるファイルや、ＵＲＬで示されたフォルダ内に存在するファイルの全てを意味する。また、勤務先のドアに付帯したアクセス制御である場合には、リソースは、ドアそのもの、もしくは、当該ドアの先にあるもの全てを意味する。
【００１５】
なお、本第１の実施形態では、端末Ｔａ，Ｔｂで管理されているエンティティのデータを用いてアイデンティティ類似性（ＩＳ：Identity Similarity）を検証し、エンティティの認証及び当該認証結果を利用したアクセス制御を行う。ここで、「エンティティ」とは、人や物（端末等）を意味している。また、「エンティティのデータ」とは、端末Ｔａ，Ｔｂが保有するデータ全て、又は各端末を利用するユーザ別に利用可能なデータを意味する。具体的には、「エンティティのデータ」には、利用者本人が作成したファイル群や、アプリケーションが作成した利用者用のデータ、あるいは利用者のシステムの利用履歴などが含まれる。なお、利用履歴等の本人やアプリケーションが保存したデータに対する背景情報（例えば、ファイルに付加された当該ファイル更新日時等）のみを指す場合には、「メタデータ」という。
また、「アイデンティティ類似性」とは、エンティティと、別のエンティティが類似しているかどうかを、各エンティティのデータの共通性等に基づいて数値で表したものを意味する。
【００１６】
なお、以下においては、１台の端末が１人の利用者専用の端末である（より具体的には、端末Ｔａの利用者がＡであり、端末Ｔｂの利用者がＢである）ものとする。このため、本第１の実施形態における「エンティティ」は、端末Ｔａ（又は利用者Ａ）と、端末Ｔｂ（又は利用者Ｂ）となる。
【００１７】
端末Ｔａは、例えば、ＰＣ、携帯電話などの端末であるものとする。端末Ｔａは、図２（ａ）に示すようなハードウェア構成を有する。具体的には、端末Ｔａは、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、ユーザインタフェース部９３、及び可搬型記憶媒体用ドライブ９９等を備える。端末Ｔａの構成各部は、バス９８に接続されている。ユーザインタフェース部９３は、ディスプレイなどの表示装置や、キーボードやマウスなどの入力装置を含む。端末Ｔａでは、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（アクセス制御プログラム）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（アクセス制御プログラム）をＣＰＵ９０が実行することにより、図３の各部の機能が実現される。なお、プログラム（アクセス制御プログラム）をネットワーク８０を介してインストールできるような場合には、端末Ｔａに可搬型記憶媒体用ドライブ９９を設けないようにしてもよい。
【００１８】
端末Ｔｂは、図２（ｂ）に示すようなハードウェア構成を有する。端末Ｔｂは、端末Ｔａと同様の構成となっている。具体的には、端末Ｔｂは、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ＨＤＤ）１９６、ネットワークインタフェース１９７、ユーザインタフェース部１９３、及び可搬型記憶媒体用ドライブ１９９等を備える。端末Ｔｂの構成各部は、バス１９８に接続されている。端末Ｔｂでは、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラム（アクセス制御プログラム）、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体１９１から読み取ったプログラム（アクセス制御プログラム）をＣＰＵ１９０が実行することにより、図３の各部の機能が実現される。なお、プログラム（アクセス制御プログラム）をネットワーク８０を介してインストールできるような場合には、端末Ｔｂに可搬型記憶媒体用ドライブ９９を設けないようにしてもよい。
【００１９】
図３には、端末Ｔａ及び端末Ｔｂの機能ブロック図が示されている。図３に示すように、端末Ｔａは、ＣＰＵ９０がプログラムを実行することで、アクセス制御部２０、管理部としてのアクセス制御ポリシー管理部２２、比較照合部２４、及び情報管理部２６、としての機能を実現している。また、端末Ｔｂは、ＣＰＵ１９０がプログラムを実行することで、リソースリクエスト部４０、及び情報管理部４２、としての機能を実現している。
【００２０】
なお、図３では、端末ＴａのＨＤＤ９６等に格納される各種ＤＢ及びテーブル（以下「ＴＢＬ」と記述する）も図示されている。これら各種ＤＢ及びＴＢＬには、図３に示すように、リソース群ＤＢ３１、アクセス制御ポリシーＴＢＬ３２、記述定義ＴＢＬ３３、検証条件複合ＴＢＬ３４、検証条件ＴＢＬ３５、Ｓｔｏｒｅ用プロパティＴＢＬ３６、ＩＳ検証用データＴＢＬ３７が含まれる。
【００２１】
次に、上記各部について、詳細に説明する。
【００２２】
アクセス制御部２０は、端末Ｔｂから端末Ｔａのリソース群ＤＢ３１に格納されているリソースに対するアクセス要求を受け付ける。そして、アクセス制御部２０は、端末Ｔａからアクセス制御に必要な特定の情報を取得するとともに、端末Ｔｂからアクセス制御に必要な特定の情報を取得する。なお、特定の情報とは、後述するアクセス制御条件としてのアクセス制御ポリシーにおいて定義されている、アクセス制御に用いる情報を意味する。また、アクセス制御部２０は、アクセス制御ポリシー管理部２２及び比較照合部２４と連携し、アクセス制御ポリシーと、取得したデータと、に基づいて、端末Ｔｂのアクセス制御を実行する。
【００２３】
ここで、リソース群ＤＢ３１には、アクセス制御対象であるリソースが格納される。リソースには、様々なファイル、データ等が含まれる。なお、本第１の実施形態では、リソースに、利用者Ａが端末Ｔａ内で保有する会員証登録簿内で管理されている店舗の情報（店名・住所・電話番号等）が含まれているものとする。
【００２４】
アクセス制御ポリシー管理部２２は、アクセス制御ポリシーＴＢＬ３２、記述定義ＴＢＬ３３、検証条件複合ＴＢＬ３４、検証条件ＴＢＬ３５、及びＳｔｏｒｅ用プロパティＴＢＬ３６に基づいてアクセス制御ポリシーを生成し、管理する。
【００２５】
ここで、アクセス制御ポリシーＴＢＬ３２は、一例として、図４（ａ）に示すように、「リソース」と、「対象」と、「Allow/Deny」の各フィールドを有する。「リソース」のフィールドには、アクセス制御に係るリソースの名称が記述される。「対象」のフィールドには、リソースに対するアクセスを許可又は不許可とする対象が記述される。「Allow/Deny」の各フィールドには、「対象」に対するアクセスを許可する（Allow）か、不許可とする（Deny）か、が記述される。
【００２６】
記述定義ＴＢＬ３３は、一例として、図４（ｂ）に示すように、「検証文」と、「検証条件複合ＩＤ（参照）」のフィールドを有する。検証条件複合ＴＢＬ３４は、一例として、図４（ｃ）に示すように、「検証条件複合ＩＤ」と、「複合条件演算」と、「検証条件ＩＤ１（参照）」と、「検証条件ＩＤ２（参照）」の各フィールドを有する。検証条件ＴＢＬ３５は、一例として、図５（ａ）に示すように、「検証条件ＩＤ」と、「検証条件演算」と、「検証方向」と、「クリア条件」と、「検証対象」と、「Ｓｔｏｒｅ用プロパティＩＤ（参照）」の各フィールドを有する。Ｓｔｏｒｅ用プロパティＴＢＬ３６は、一例として、図５（ｂ）に示すように、「Ｓｔｏｒｅ用プロパティＩＤ」、「データタイプ」、「Ｓａｍｅａｓ」、「ｆｒｏｍ」、「ｔｏ」などのフィールドを有する。これら各ＴＢＬ３３〜３６は、アクセス制御ポリシー管理部２２により管理されている。
【００２７】
これら各ＴＢＬ３３〜３６からは、アクセス制御ポリシーとして、“検証文：会員登録している店舗”ならば、リソース（System.rsc.Phonebook.*）へのアクセス権限を付与する、という内容が定義されている。すなわち、アクセス制御ポリシーでは、会員登録しているかどうかという観点で見た時にアイデンティティ類似性（ＩＳ）が高い（会員登録している可能性が高い）かどうかを検証することが定められている。また、検証条件ＴＢＬ３５やＳｔｏｒｅ用プロパティＴＢＬ３６では、ＩＳ検証用データＴＢＬ３７（図５（ｃ）参照）に含まれている電話帳データ（System.rsc.Phonebook.*）のうち店舗電話番号のラベルがついたデータの少なくとも１つが、端末Ｔｂから得られるデータの１つと同一であれば、アクセス権限を付与する、ということが定められている。
【００２８】
図３に戻り、比較照合部２４は、記述定義ＴＢＬ３３等から生成されるアクセス制御ポリシーに基づいて、アクセス制御部２０が取得した情報を比較照合し、当該比較照合結果（検証結果とも呼ぶ）をアクセス制御部２０に回答する。
【００２９】
情報管理部２６は、ＩＳ検証用データＴＢＬ３７において、アイデンティティ類似性（ＩＳ）を検証するためのデータを管理する。なお、利用者Ａは、端末Ｔａにおいて会員証情報を管理しているものとし、情報管理部２６は、当該会員証情報から電話番号を抽出して、ＩＳ検証用データＴＢＬ３７を生成する。ここで、ＩＳ検証用データＴＢＬ３７は、一例として、図５（ｃ）に示すように、「検証用データＩＤ」と、「検証用データタイプ」と、「検証用データ」の各フィールドを有する。「検証用データタイプ」のフィールドには、「店舗電話番号」などのデータの種類が記述され、「検証用データ」のフィールドには、電話番号などの実データが記述される。なお、「検証用データタイプ」のフィールドは、「検証データ」のフィールドに記述される実データのラベルとしての機能を有する。
【００３０】
図３に戻り、端末Ｔｂのリソースリクエスト部４０は、端末Ｔｂの利用者Ｂが、ユーザインタフェース部１９３からリソースへのアクセスをリクエストした場合に、当該リクエストを端末Ｔａのアクセス制御部２０に対して送信する。情報管理部４２は、アクセス制御部２０から要求される、アクセス制御に必要なデータを送信する。なお、端末Ｔａは、図３に示す機能のほか、端末Ｔｂの機能を併せ持っていても良いし、端末Ｔｂは、図３に示す機能のほか、端末Ｔａの機能を併せ持っていても良い。
【００３１】
次に、図６のフローチャートに沿って、端末Ｔａ、端末Ｔｂの処理について詳細に説明する。図６では、左側のフローチャートが端末Ｔｂの処理を示しており、右側のフローチャートが端末Ｔａの処理を示している。なお、以下の説明では、図６及び図７に示す、処理及びデータの流れを示す番号（括弧付き番号）を適宜用いるものとする。
【００３２】
なお、本第１の実施形態では、端末Ｔｂを利用する利用者Ｂ（リソースの要求者）がリソースを保有する端末Ｔａの利用者Ａ（リソースの権利者）のよく行く店舗であるものとする。そして、リソースには、利用者Ａの会員証登録簿内で管理されている利用者Ｂの店舗情報（店名・住所・電話番号等）を含む会員証情報を含むものとする。また、以下では、利用者Ｂが、端末Ｔｂを介して端末Ｔａが保有する会員証情報にアクセスすることで当該会員証情報を変更しようとしており、端末Ｔａでは、以下に説明する方法で、端末Ｔｂのアクセス制御を行うものとする。また、以下の処理で用いるアクセス制御ポリシーは、図４、図５の各テーブル３３〜３６から導き出されるアクセス制御ポリシーであるものとする。
【００３３】
図６の処理では、まず、ステップＳ１０において、端末Ｔｂのリソースリクエスト部４０が、リソースに対するアクセスのリクエストが入力されるまで待機する。この場合、リソースリクエスト部４０では、ユーザインタフェース部１９３を介した利用者Ｂからのリクエストが入力された段階で、ステップＳ１２に移行する。
【００３４】
ステップＳ１２では、リソースリクエスト部４０が、リソースに対するアクセスのリクエストを、端末Ｔａのアクセス制御部２０に対して送信する（図７の（１）参照）。なお、上記ステップＳ１０、Ｓ１２では、リソースリクエスト部４０が、利用者Ｂからのリクエストの入力があった段階でリクエストを端末Ｔａに対して送信する場合について説明したが、これに限られるものではない。例えば、リソースリクエスト部４０は、端末Ｔｂと端末Ｔａとの距離が赤外線等による通信が可能になる程度の距離に近づくまで待機し、近づいた段階で、自動的に端末Ｔａに対してリクエストを送信するようにしてもよい。
【００３５】
上記ステップＳ１０、Ｓ１２の処理の間、端末Ｔａのアクセス制御部２０は、ステップＳ１１０において、リソースに対するアクセスのリクエストを受信するまで待機している。そして、ステップＳ１２において、端末Ｔｂ側からアクセス制御部２０に対してリクエストが送られてくると、アクセス制御部２０は、ステップＳ１１２に移行する。
【００３６】
ステップＳ１１２では、アクセス制御部２０は、端末Ｔｂ側から送信されてきたリクエストを受け付ける。次いで、ステップＳ１１４では、アクセス制御ポリシー管理部２２が、アクセス制御ポリシーＴＢＬ３２を参照して、アクセス制御ポリシーを確認する（図７の（２）参照）。次いで、ステップＳ１１６では、記述定義ＴＢＬ３３等を参照して、検証に必要なデータと確認内容を確定する（図７の（３）参照）。
【００３７】
次いで、ステップＳ１１８では、アクセス制御部２０が、端末Ｔｂの情報管理部４２に対して、ステップＳ１１６で確定した検証に必要なデータを要求する（図７の（４）参照）。ここでは、前述したように、アクセス制御ポリシーでは、店舗電話番号のラベルが付されているデータ（電話番号）が検証に必要なデータとなっている。
【００３８】
上記端末Ｔａの処理の間、端末Ｔｂでは、ステップＳ１４において、端末Ｔａからの要求があるまで待機している。そして、ステップＳ１１８においてアクセス制御部２０からの要求があると、ステップＳ１６に移行する。
【００３９】
ステップＳ１６では、情報管理部４２が、データ要求を受け付ける。次いで、ステップＳ１８では、情報管理部４２が、端末Ｔｂが保有するデータの中から、アクセス制御部２０により要求されたデータのうち、利用者Ｂが無制限に公開しているデータを選択して、送信する（図７の（５）参照）。ここで、情報管理部４２からアクセス制御部２０に対して送信されたデータは、図８（ａ）のような店舗電話番号（Ｌｂ１，Ｌｂ２）であったものとする。なお、端末Ｔｂ側では、これ以降、ステップＳ２０において、次に端末Ｔａからデータ等が送られてくるまで待機する。
【００４０】
なお、端末Ｔａのアクセス制御部２０は、ステップＳ１１８の処理以降は、ステップＳ１２０において、データを受信するまで待機している。したがって、アクセス制御部２０は、ステップＳ１８において端末Ｔｂ側からデータが送信されてきた段階で、ステップＳ１２２に移行する。
【００４１】
ステップＳ１２２では、アクセス制御部２０は、端末Ｔｂ側から送信されてきたデータを受け付ける。次いで、ステップＳ１２４では、アクセス制御部２０の指示の下、比較照合部２４が、端末Ｔａ，Ｔｂのデータを用いた比較照合を実行する（図７の（６）参照）。この場合、比較照合部２４は、端末Ｔａが保有する店舗電話番号をアクセス制御部２０を介して情報管理部２６（ＩＳ検証用データＴＢＬ３７）から取得する。なお、比較照合部２４が取得した店舗電話番号は、図８（ｂ）に示す電話番号であったものとする。そして、比較照合部２４は、ステップＳ１２２で受け付けたデータ（端末Ｔｂが保有する店舗電話番号（図８（ｂ）参照））と比較照合する。この場合、比較照合部２４は、比較照合により、図８（ｃ）の表のような照合結果を得ることができる。なお、図８（ｃ）の表では、「０」が、電話番号の不一致を示し、「１」が、電話番号の一致を示す。
【００４２】
次いで、ステップＳ１２６では、アクセス制御部２０が、アクセスＯＫであるか（アクセスを許可するか）否かを判断する。この場合、アクセス制御部２０は、アクセス制御ポリシー（端末Ｔａ，Ｔｂにおいて同一の店舗電話番号を最低１つ保有）を満たしているか否かを判断する。ここでは、図８（ｃ）より、店舗電話番号Ｌａ３とＬｂ２が同一である。したがって、アクセス制御部２０は、アクセスを許可すると判断する。なお、この場合のＩＳ一致傾向（ｘ／１００）は、最大（１００／１００）であるといえる。この場合、アクセス制御部２０は、ステップＳ１２８において、端末Ｔｂのリソースリクエスト部４０に対して、リソースを応答する（図７の（７）参照）。
【００４３】
この端末Ｔａ側からのリソースの応答により、端末Ｔｂでは、ステップＳ２０の判断が肯定されて、ステップＳ２２に移行する。そして、リソースリクエスト部４０は、ステップＳ２２においてリソースの受付を行う。これにより、端末Ｔｂ側では、リソースに対するアクセスが可能となるため、利用者Ｂは、端末Ｔｂのユーザインタフェース部１９３を介して、自店舗の情報の書き換えを行うことが可能となる。
【００４４】
一方、端末Ｔａ側において、ステップＳ１２６の判断が否定された場合、すなわち、アクセスがＮＧであると判断された場合には、ステップＳ１３０に移行する。アクセス制御部２０は、ステップＳ１３０において、アクセスがＮＧ（アクセス不可）である旨のメッセージを端末Ｔｂのリソースリクエスト部４０に対して回答する（図７の（８）参照）。この回答があった場合、端末Ｔｂでは、ステップＳ２０の判断が肯定されて、ステップＳ２２に移行する。そして、ステップＳ２２では、リソースリクエスト部４０が、アクセスがＮＧであることのメッセージの受付を行う。これにより、端末Ｔｂ側では、端末Ｔａへのアクセスができない旨のメッセージをユーザインタフェース部１９３に表示することが可能となる。
【００４５】
なお、これまでの説明から明らかなように、アクセス制御部２０は、制御部としての機能を有している。また、アクセス制御部２０と情報管理部２６とにより、取得部としての機能が実現されている。更に、アクセス制御部２０と比較照合部２４とにより、判断部としての機能が実現されている。
【００４６】
以上、詳細に説明したように、本第１の実施形態によると、アクセス制御ポリシー管理部２２が、リソースを保持する端末Ｔａから得られる特定の情報（例えば店舗電話番号）とリソースに対するアクセスを要求する端末Ｔｂから得られる特定の情報（例えば店舗電話番号）との類似性（アイデンティティ類似性（ＩＳ））で定義される、リソースに対するアクセス制御ポリシーを管理している。また、アクセス制御部２０が、アクセス制御ポリシーに基づいて、端末Ｔａ及び端末Ｔｂから特定の情報（例えば店舗電話番号）を取得し、当該取得された各情報の類似性が検証条件を満たすか否かを検証することで、端末Ｔｂからのリソースに対するアクセスが可能か否かを判断する。これにより、本第１の実施形態では、リソースに対するアクセスを要求する端末を個別に特定することなく、リソースに対するアクセスの可否を判断することが可能となる。したがって、アクセス制御対象の端末やユーザごとの登録が不要となり、登録の手間や登録に要する時間を低減することができるとともに、アクセス可否の単位を、検証条件を満たす端末やユーザという大まかな範囲とすることができる。
【００４７】
また、本第１の実施形態では、アクセス制御部２０が、アクセス可否の判断結果に基づいてアクセス制御を行うので、端末Ｔｂ自体を登録しなくても、端末Ｔｂからのアクセスを適切に制御することが可能となる。
【００４８】
また、本第１の実施形態では、アクセス制御ポリシーを適宜変更することで、種々のアクセス制御が可能である。一例として、以下のようなアクセス制御が可能である。
（１） 同一エリアに居住している住人であれば、位置情報付きの風景写真に対するアクセスを可能とする。
（２） 同じエリアに住んでいない人（土地勘の無い人）であれば、自己のブログへのアクセスを可能とする。
（３） 仕事関係の共通の知人が多ければ、仕事用プロフィールの閲覧を可能とする。
【００４９】
なお、上記第１の実施形態では、ＩＳ検証用データとして電話番号のような完全一致検証ができるデータを用いることとしたが、これに限られるものではない。例えば、ＩＳ検証用データとしては、類似度を検証できるデータ（例えば、住所）を用いることとしても良い。この場合においても、図８（ｃ）のようなマトリクスを用いることで、比較照合が可能となる。ただし、マトリクスの各格子にどのような計算結果が入るかは、用いる類似度関数に依存し、用意された類似度関数中のどの関数を使用するかは、用いるＩＳ検証用データのラベルや確認したい内容によって異なる。この場合、アクセス制御部２０では、マトリクスに入力される数値を用いて、所定の演算によりＩＳ一致傾向（＝ｘ／１００）を算出し、当該ＩＳ一致傾向が所定の閾値よりも大きい場合（すなわち、アクセス制御条件を満たす場合）に、アクセスを許可するなどの制御をすることができる。
【００５０】
《第２の実施形態》
以下、第２の実施形態について、図９に基づいて説明する。本第２の実施形態では、アクセス制御部２０が一度認証した場合（アクセスを許可した場合）に、当該認証結果を証明書として発行し、証明書を受け取った端末では、次回以降の認証において、当該証明書を用いて認証を行うこととする。
【００５１】
図９には、第２の実施形態に係る端末Ｔａ、Ｔｂの機能ブロック図が示されている（第２の実施形態で新たに追加された機能については、太線で表示している）。図９に示すように、端末Ｔａは、第１の実施形態で説明した各部に加え、証明書発行部２８と、証明書ＤＢ３９と、を備えている。また、端末Ｔｂは、第１の実施形態で説明した各部に加え、証明書管理部４４と、証明書ＤＢ４６と、を備えている。
【００５２】
証明書発行部２８は、アクセス制御部２０が一度アクセスを許可した場合に、当該アクセス許可情報（認証情報）をアクセス制御部２０から受け取り、証明書を発行して、証明書ＤＢ３９に格納する。なお、証明書には、リソースに対するアクセス許可がいつなされたのか、を示すための情報が基本情報として含まれているものとする。また、証明書発行部２８は、発行した証明書をアクセス制御部２０を介して、リソースリクエスト部４０に送信する。
【００５３】
証明書管理部４４は、リソースリクエスト部４０から証明書を受け取り、証明書ＤＢ４６に格納する。また、証明書管理部４４は、リソースリクエスト部４０がアクセス制御部２０に対してアクセスをリクエストする際には、証明書ＤＢ４６から証明書を読み出して、リソースリクエスト部４０に受け渡す。なお、リソースリクエスト部４０は、アクセス制御部２０に対してアクセスをリクエストする際に、証明書をアクセス制御部２０に対して送信する。
【００５４】
なお、端末Ｔｂ側の証明書ＤＢ４６において管理される証明書は、端末Ｔａ側の証明書ＤＢ３９で管理する証明書の全てのデータを含んでいてもよいし、証明書ＤＢ３９で管理する証明書と紐付ける情報のみであってもよい。また、証明書には、検証用データ（上記第１の実施形態の例では、店舗電話番号）がどの程度信頼できるデータであるかを示す情報を含めてもよい。この場合、例えば、検証用データとしてＧＰＳラベルのついたデータを用いた場合であれば、単に比較に用いた緯度や経度の情報だけでなく、それらの情報がいつ取得された情報なのか、どの端末によって取得された情報なのか、というメタデータに相当する情報を証明書に含めておくこととしてもよい。これらの情報を用いることで、認証結果の信頼性を推量することが可能となる。また、証明書発行部２８は、上記メタデータに相当する情報に基づいて、不確かなデータであることを判別できるような場合には、証明書を発行しないこととしてもよい。
【００５５】
また、証明書には、一般的な証明書同様、有効期限を設けることができる。この場合、証明書発行部２８は、検証用データの信頼性が高ければ証明書の有効期限を長くし、そうでなければ短くするなどしてもよい。
【００５６】
また、証明書の不正な乱用を避けるため、アクセス制御部２０は、証明書ＤＢ３９において、証明書と紐付けて使用回数情報（カウンタ）を管理することとしてもよい。この場合、アクセス制御部２０は、証明書使用の度にカウントアップすることで、使用上限値に達した証明書の使用を停止するなどしてもよい。
【００５７】
なお、アクセス制御部２０は、あるリソースのアクセス制御において発行した証明書を、他のリソースに対するアクセス制御に流用することとしてもよい。この場合、アクセス制御部２０は、共通する検証文を有するリソース間において、他のリソースの証明書の流用を許可するなどすればよい。
【００５８】
なお、アクセス制御ポリシーが改変された場合、提示された証明書の情報では、改変後の検証文をクリアするのに必要なデータを満足しない場合がある。このような場合には、アクセス制御部２０は、端末Ｔｂの情報管理部４２に対して不足しているデータの提供を求めるものとする。そして、情報管理部４２は、無条件に公開されている情報を優先して、アクセス制御部２０に対して提供するようにする。ただし、当該提供では認証が成功しない場合もある。このような場合には、情報管理部４２は、端末Ｔｂのユーザインタフェース部１９３を通じて端末Ｔｂの利用者Ｂに直接データ開示の確認を行い、確認が取れた後に非公開の情報を提供するようにしてもよい。なお、情報管理部４２は、端末Ｔｂ上で管理されていない情報であっても、外部のセンサやサービスが提供している情報群を新たに取得して、アクセス制御部２０に対して提供することとしてもよい。
【００５９】
以上説明したように、本第２の実施形態によると、証明書発行部２８は、アクセス制御部２０が端末Ｔｂからのアクセスが可能と判断した場合に、端末Ｔｂに対して証明書を発行し、これ以降、アクセス制御部２０は、端末Ｔｂから証明書が提示された場合にも、端末Ｔｂのアクセスを許可する。これにより、１度アクセス可能と判断した端末の、以降の認証を簡素化することができる。これにより、アクセス制御の簡素化及び時間短縮を図ることができる。また、証明書に種々の情報を含めることで、上述したような様々なアクセス制御が可能となる。
【００６０】
《第３の実施形態》
以下、第３の実施形態について、図１０〜図１２に基づいて説明する。本第３の実施形態では、上記第１、第２の実施形態と異なり、複数種類のデータに基づいたアクセス制御が行われるものとする。なお、本第３の実施形態では、図１０のような情報処理システムにおけるアクセス制御を行うものとする。この場合、前述した端末Ｔａのアクセス制御に関する機能（アクセス制御部２０、アクセス制御ポリシー管理部２２、比較照合部２４、情報管理部２６）は、図１０のサーバ２００に設けられているものとする。
【００６１】
サーバ２００は、端末Ｔａの利用者Ａのリソースを保持している。また、サーバ２００は、端末Ｔｂからのリソースに対するアクセス制御を、端末Ｔａが保有する特定の情報（実際にはサーバ２００上に存在）と、端末Ｔｂが保有する特定の情報（サーバ２００上に存在）とに基づいて、判断するものとする。なお、各端末Ｔａ，Ｔｂが保有する特定の情報は、各端末Ｔａ，Ｔｂの内部の記憶部等に格納されていてもよい。
【００６２】
以下、端末Ｔａの利用者Ａが会社を退職した場合において、利用者Ａのデータ（リソース）へのアクセスをアイデンティティ類似性（ＩＳ）に基づいて制御する例について説明する。この場合の前提として、利用者Ａは、退職前にサーバ２００に残すデータを全ての部署員に開示するのではなく、同じプロジェクトに関連している人（後述する検証文Ｓａ１を満たす人）にのみ開示しようとしている。また、プロジェクトで共用しているデータ等は、他の同僚も持っているので引き継がなくても問題ないが、利用者Ａが担当していた範囲の個人的な備忘録などは、同じ仕事に携わる人がアクセスできるようにしようとしている。なお、利用者Ａの退職後にプロジェクトに新たに参加する人等には、事前にデータを渡すことができず、また、当該新たに参加する人を個別に指定してサーバに登録するなどすることはできない。したがって、本第３の実施形態においても、上記第１、第２の実施形態と同様、アクセス制御ポリシーを用いるものとする。
【００６３】
本第３の実施形態では、記述定義の検証文Ｓａ１において、図１１（ａ）に示すCond-a1とCond-a2の２つが同時に成立する場合にアクセス可能とする検証条件が定義されているものとする。
【００６４】
ここで、Cond-a1で用いるデータは、プロジェクトＭＬラベルのメールアドレスである。Cond-a1では、端末Ｔａ（リソース権利者側）の保有するプロジェクトＭＬラベルのメールアドレスと、端末Ｔｂ（リソース要求者側）の保有するプロジェクトＭＬラベルのメールアドレスとが１つ以上一致することが条件とされている。一方、Cond-a2で用いるデータは、プロジェクトラベルの付与されたフォルダのファイルハッシュである。Cond-a2では、端末Ｔａの保有するプロジェクトラベルの付与されたフォルダのファイルハッシュと、端末Ｔｂの保有するプロジェクトラベルの付与されたフォルダのファイルハッシュとが１つ以上一致することが条件とされている。
【００６５】
なお、利用者Ａは、退職前に、自動で集計登録されたプロジェクトＭＬラベルのメールアドレスから不要なアドレスを削除しているものとする。また、利用者Ａは、退職前に、プロジェクトラベルのフォルダとしてピックアップされたフォルダから不要なフォルダを削除しているものとする。
【００６６】
以下、上記のような状況下において、端末Ｔｂから、端末Ｔａが保有するプロジェクトに関するリソースに対してアクセスがあった場合の、サーバ２００（主にアクセス制御部２０）によるアクセス制御について説明する。
【００６７】
利用者Ａの退職後、プロジェクトに参加した利用者Ｂは、利用者Ａの仕事を引き継ぐこととなり、どういう蓄積データがあるのかを確認しようと、プロジェクト（projectA）に関するフォルダ（例えば/home/userA/project/2011/projectA）に、端末Ｔｂを介してアクセスしたとする。この場合、サーバ２００のアクセス制御部２０は、アクセス制御ポリシー管理部２２で管理されているアクセス制御ポリシーの検証条件（図１１（ａ）参照）を参照する。そして、アクセス制御部２０は、検証条件に基づいて、端末Ｔｂが保有するプロジェクトＭＬラベルのメールアドレスと、プロジェクトラベルフォルダprojectA以下のファイルハッシュと、を取得する（図１１（ｂ）参照）。また、アクセス制御部２０は、端末Ｔａが保有するプロジェクトＭＬラベルのメールアドレスと、プロジェクトラベルフォルダprojectA以下のファイルハッシュと、を取得する（図１１（ｃ）参照）。
【００６８】
そして、比較照合部２４は、アクセス制御部２０の指示の下、取得された各メールアドレス及び各ファイルハッシュを比較照合する。図１２（ａ）には、プロジェクトＭＬラベルのメールアドレスの比較照合結果（検証結果）が示され、図１２（ｂ）には、プロジェクトラベルフォルダprojectA以下のファイルハッシュの比較照合結果（検証結果）が示されている。これら図１２（ａ）、図１２（ｂ）では、アドレスやファイルハッシュが一致している場合に値「１」が入力され、不一致の場合に値「０」が入力される。この場合、図１２（ａ）及び図１２（ｂ）の検証結果には、値「１」が存在している（１つ以上の一致がある）。したがって、アクセス制御部２０は、アクセス制御ポリシーに基づいて、projectAに関するフォルダ（/home/userA/project/2011/projectA）に対する、端末Ｔｂのアクセスを許可する。このようにすることで、新たにプロジェクトに参加した利用者Ｂは、利用者Ａが退職前に残したデータにアクセスできるようになる。
【００６９】
以上説明したように、本第３の実施形態によると、アクセス制御ポリシーは、複数種類のデータ（プロジェクトＭＬラベルのメールアドレスとプロジェクトラベルフォルダ以下のファイルハッシュ）に関する類似性（共通性）で定義されており、アクセス制御部２０は、端末Ｔａ、Ｔｂから複数種類のデータを取得し、アクセス制御を行う。このように、複数種類のデータを用いたアクセス制御を行うことで、精度の高いアクセス制御の実現が可能となる。
【００７０】
なお、上記第３の実施形態においては、アクセス制御部２０が、自動的にメールアドレスやファイルハッシュを取得する場合について説明したが、これに限られるものではない。アクセス制御部２０は、端末Ｔｂのユーザインタフェース部１９３を介して、利用者Ｂに対してメールアドレスやファイルハッシュの提示を求めるようにしてもよい。この場合、利用者Ｂは、具体的に何を提示すればよいのかを理解できない場合もあると考えられる。このような場合に備え、アクセス制御部２０は、メールアドレスやファイルハッシュの提示を求める場合に、ユーザインタフェース部１９３（例えばディスプレイ）上に詳細メッセージを表示するためのボタン等を表示してもよい。そして、アクセス制御部２０は、利用者Ｂによってボタンが押された場合に「プロジェクト（projectA）に関連するファイルを１つ以上提示すること」などとユーザインタフェース部１９３を介して表示するようにしてもよい。なお、利用者Ｂは、求められたデータを端末Ｔｂ上から選択することとしてもよいが、求められたデータをユーザインタフェース部１９３を介して新たに入力することとしてもよい。
【００７１】
なお、上述したようにアクセス制御部２０が自動的にメールアドレスやファイルハッシュを取得する場合であっても、自動取得後に、利用者Ｂがメールアドレスやファイルハッシュの追加・変更等を行えるようにしてもよい。この場合、意図と異なる検証用データがアクセス制御部２０により取得された場合でも、当該検証用データの修正ができるので、利用者の利便性を向上することができる。また、これとは逆に、メールアドレスやファイルハッシュの自動取得後における追加・変更を一切禁止するようにしてもよい。この場合、利用者本人の利用状況を正確に反映させた検証用データを作成することが可能となる。
【００７２】
なお、上記第３の実施形態では、アクセス制御部２０が、プロジェクトＭＬラベルのメールアドレスと、プロジェクトラベルフォルダ以下のファイルハッシュの２種類のデータに基づいてアクセス制御を行う場合について説明した。しかしながら、これに限られるものではなく、上記以外のデータや、３種類以上のデータに基づいて、アクセス制御を行うようにしてもよい。
【００７３】
《第４の実施形態》
次に、第４の実施形態について、図１３に基づいて説明する。本第４の実施形態では、検証条件として検証文を用いずに、各端末が保有するデータそのものをアクセス制御ポリシーに記述する点に特徴を有する。なお、装置構成は、第１の実施形態と同様であるものとする。
【００７４】
図１３（ａ）には、本第４の実施形態で用いるアクセス制御ポリシーの一例が示されている。この図１３（ａ）は、ある利用者Ａが、自分の端末Ｔａ内のアドレス帳の情報更新を「山田太郎」さんに許可する場合の例である。この場合、更新を許可する対象者が曖昧でなく、特定の人物であるので、特定の人物のみがアクセス可能となるように条件が記述することができる。すなわち、アクセス制御に用いるデータは、図１３（ａ）のアクセス制御ポリシーに記述されている確認データ（「山田太郎」など）となる。なお、図１３（ａ）の例では、名前や電話番号などの、山田太郎さんの個人情報を全て知っている（入力できる）利用者のみが、アドレス帳の情報更新を行うことが可能となる。
【００７５】
なお、セキュリティ上の安全を確保するため、図１３（ｂ）に示すように、確認データを符号化してもよい。図１３（ｂ）の例では、符号化後のデータはハッシュ値となっている。なお、確認データを符号化する場合には、使用する確認対象に合わせて符号化するようにしてもよい。例えば、データの一致を確認すればよい場合（類似度の確認が不要の場合）には、全体のハッシュをとるだけで問題ないが、住所データのように階層構造を持ったデータの場合には、図１３（ｃ）のように階層毎に符号化してもよい。この場合、例えば、“神奈川県川崎市”と“神奈川県”が県レベルで同じ情報であることを示すことができる。
【００７６】
なお、上記第４の実施形態では、第３の実施形態と同様の装置構成（サーバ２００がアクセス制御を行う構成）を採用してもよい。
【００７７】
《第５の実施形態》
次に、第５の実施形態について、図１４、図１５に基づいて説明する。なお、本第５の実施形態の装置構成は、上述した第１の実施形態と同様の装置構成であるものとする。本第５の実施形態は、端末Ｔｂが保有するデータを、端末Ｔａに対して秘匿化して送信する場合の例である。
【００７８】
上述した第１の実施形態のように、会員登録している店舗の電話番号リストを店舗の端末に送信するのは利用者にとって然程問題にならない可能性が高い。しかしながら、送信するデータが、例えば、友人の電話番号のリストである場合には、利用者が実データを送信するのに躊躇するおそれがある。このような場合などにおいて、本第５の実施形態を用いることができる。
【００７９】
ここでは、端末Ｔａの利用者Ａと端末Ｔｂの利用者Ｂが初めて出会った場合に、利用者Ａと利用者Ｂに共通の知人が多ければ、利用者Ｂに対して、利用者Ａが作成したプロフィールへの参照権限を与える例について説明する。
【００８０】
この場合、アクセス制御部２０は、利用者Ａ，Ｂが保有する電話番号ラベルのついたＩＳ検証データ（電話番号データ）を互いに開示することなく比較し、共通する電話番号の個数を知る必要がある。
【００８１】
図１４は、端末Ｔｂ及びＴａにおける処理を示すフローチャートである。なお、図１４の処理は、基本的には、第１の実施形態（図６）と同様となっている。図１４の処理では、まず、初めて会った利用者Ａ（端末Ｔａ）に対して、利用者Ｂ（端末Ｔｂ）がプロフィール情報をリクエストする（ステップＳ１２）。次いで、端末Ｔａのアクセス制御部２０が、利用者Ａのアクセス制御ポリシーから、検証文：共通の知人が多い、を検証する。この場合、使用するデータは、電話番号ラベルの付いた電話番号データである。また、本第５の実施形態では、秘匿化関数を用いた検証を行うことがアクセス制御ポリシーにおいて定義されているものとする。このため、アクセス制御部２０は、ステップＳ１１８における端末Ｔｂに対するデータの要求の際には、図１５中の手続きＡ１の実行により生成される秘匿化ＩＳ検証用データＳａを付加して、検証に必要な電話番号ラベルの付いた電話番号データの要求を送付する。
【００８２】
これに対し、利用者Ｂ側では、情報管理部４２が、秘匿化関数を用いた場合に送付できる範囲で、電話番号ラベルのＩＳ検証データ（電話番号データ）を用いて、図１５の手続きＢを実行する。そして、情報管理部４２は、秘匿化ＩＳ検証データＳｂを利用者Ａに返却する（ステップＳ１８）。
【００８３】
また、利用者Ａ側では、アクセス制御部２０が、端末Ｔｂ側から受領した秘匿化ＩＳ検証データＳｂを用いて図１５中の手続きＡ２を実行し、０になった個数を取得する（ステップＳ１２４）。ここで、手続きＡ２の結果、０になった個数は、双方のＩＳ検証データ中で一致していたものの個数を意味する。この場合、アクセス制御部２０は、共通の電話番号の個数が多ければ（一致割合が所定の閾値よりも多ければ）、共通の知人が多いと判断し、利用者Ｂに対して利用者Ａが作成したプロフィールへの参照権限を付与する。
【００８４】
以上説明したように、本第５の実施形態では、アクセス制御部２０は、図１４の処理を行うことで、実質的に、端末Ｔａが保有する電話番号データを秘匿化したデータと、端末Ｔｂが保有する電話番号データを秘匿化したデータとを取得し、その一致割合に基づいて、端末Ｔｂによるアクセス制御を行っているといえる。これにより、本第５の実施形態では、各端末で保有しているデータを他の端末に対して一切明かすことなく、アクセス制御を行うことが可能となる。
【００８５】
《第６の実施形態》
次に、第６の実施形態について、図１６に基づいて説明する。本第６の実施形態の装置構成は、第１の実施形態と同様の装置構成となっている。第６の実施形態は、データをプロフィールや名刺、会員証等テンプレート毎に管理し、かつテンプレート単位で符号化を行うものである。
【００８６】
ここで、本第６の実施形態では、前述した第５の実施形態と同様、検証文「共通の知人が多い」を、プロフィール情報の一致割合に基づいて確認するものとする。ただし、本第６の実施形態では、利用者Ａの端末Ｔａと利用者Ｂの端末Ｔｂが保有する電話番号同士を比較するのではなく、保持しているプロフィール全体の情報を用いた比較を行う。例えば、アクセス制御部２０は、端末Ｔａが保有するプロフィールとして、図１６（ａ）に示すプロフィールを取得し、端末Ｔｂが保有するプロフィールとして、図１６（ｂ）に示すプロフィールを取得したものとする。
【００８７】
プロフィールのようにＩＳ検証用データの１つ１つの項目中に更に住所や名前といった詳細データが含まれる場合であっても、各項目の類似度を算出する段階では、上述した各実施形態と同様、項目と項目、つまり、プロフィールとプロフィールの比較を行えばよい。この場合、アクセス制御部２０は、図１６（ｃ）に示すような検証結果（類似度マトリクス）を得ることができる。この図１６（ｃ）の検証結果では、類似度マトリクスの各格子に各プロフィール相互の類似度が入力されている。なお、検証関数が、一致・不一致だけを見る場合には、プロフィールを符号化し、符合化後のデータ（ファイルハッシュ値）を比較した結果（値「１」又は「０」）を類似度マトリクスの各格子に入力するようにすればよい。
【００８８】
なお、アクセス制御部２０は、図１６（ｃ）の検証結果から、所定の演算方法を用いてＩＳ一致傾向（＝ｘ／１００）を算出し、当該ＩＳ一致傾向に基づいて、端末Ｔｂからのアクセスの許可・不許可を判断する。なお、ＩＳ一致傾向の演算方法としては、例えば、図１６（ｃ）の各格子に入力されている類似度の平均を算出する方法などを採用することができる。
【００８９】
以上、説明したように、本第６の実施形態によると、プロフィールなどのデータの集合の類似度に基づいてアクセス制御を行うので、上記各実施形態と同様、ユーザ登録等を行うことなく適切なアクセス制御を行うことが可能となる。
【００９０】
《第７の実施形態》
次に、第７の実施形態について、図１７に基づいて説明する。本第７の実施形態の装置構成は、上記第１の実施形態の装置構成と同様となっている。また、本第７の実施形態は、ＩＳ検証データのデータ量を縮退することを目的としている。
【００９１】
図１７は、本第７の実施形態におけるデータの縮退イメージを示す図である。本実施形態では、情報管理部２６、４２では、電話番号のデータをアクセス制御部２０に対して送信する前に、図１７（ａ）に示すように符号化する。なお、図１７（ａ）では、電話番号のデータをハッシュ化した例（Hash(data1)、Hash(data2)、…）が示されている。そして、情報管理部２６、４２は、ハッシュ化したデータ（Hash(data1)、Hash(data2)、…）それぞれに含まれる文字（０，１，２，…ｅ，ｆ）の個数をカウントし、それらを並べたものを縮退データＬ１、Ｌ２…とする（図１７（ｂ）参照）。なお、ＩＳ検証データとしては、全ての縮退データから重複のないようにデータを集計する。情報管理部２６，４２は、図１７（ｂ）のような縮退データをアクセス制御部２０に対して送信するものとする。
【００９２】
そして、アクセス制御部２０では、利用者Ａ（端末Ｔａ）側で生成されるＣａ（図１７（ｃ）参照）と、Ｃａと同様にして利用者Ｂ（端末Ｔｂ）側で生成されるＣｂとの一致・不一致を検証する。ここで、利用者Ａ側と利用者Ｂ側内の元の電話番号が同じであった場合には、そのハッシュ値及び、Ｃａ、Ｃｂ中の対応する縮退データも一致することを意味する。したがって、本第７の実施形態では、アクセス制御部２０が、ＣａとＣｂとを比較することで、大まかな電話番号の一致個数を検証することができる。
【００９３】
以上のように、本第７の実施形態によると、ハッシュ値に含まれる各文字の個数を用いて検証に用いるデータ量を縮退させるので、ハッシュ値そのものを端末間でやり取りする場合よりもデータ量を低減することができる。また、データ量の低減により検証に要する時間を短縮することができる。
【００９４】
《第８の実施形態》
次に、第８の実施形態について、図１８に基づいて説明する。本第８の実施形態では、第２の実施形態と同様に、一度アクセスを許可した端末に対して、リソースを保持する端末から証明書を発行するものとする。すなわち、本第８の実施形態の装置構成は、第２の実施形態の装置構成（図９）と同様であるものとする。
【００９５】
本第８の実施形態では、アクセス制御部２０での認証が完了した後、証明書発行部２８は証明書（「ＣＴａ」とする）を発行する。この場合、アクセス制御部２０は、証明書ＣＴａを端末Ｔｂのリソースリクエスト部４０にそのまま送信するのではなく、証明書ＣＴａを例えば３つの分割証明書（ＤＣＴａ１、ＤＣＴａ２、ＤＣＴａ３）に変換して送信することとする。
【００９６】
この場合の各分割証明書の内容は、単純に証明書ＣＴａのハッシュ値を等分に分けたものでも良い。また、(ｋ,ｎ)しきい値秘密分散法を用いて、例えばｎ個の分割証明書のうち、ｋ個を利用者が保持していた場合には、証明書ＣＴａを復元できるようにしてもよい。なお、秘密分散法を用いる場合のデータの例は、図１８に示されている。図１８に示すように、（ｋ−１）次の多項式を作ることで、分割符号情報をｋ個集めて、連立方程式を解くことで、元の証明書を復元することが可能となっている。ここで、秘密分散法を用いた分割符号証明書は、複数の利用者に証明書ＣＴａをばら撒きたいが、人によって使用する分割符号証明書を変えたい場合や、１人の利用者が状況や場所に合わせて使用する分割符合証明書を変えたい場合に用いることができる。
【００９７】
ただし、証明書のハッシュ値を等分に分割して分割証明書（ＤＣＴａ１、ＤＣＴａ２、ＤＣＴａ３）を作成した場合、その一部を提示するのみでは、証明書ＣＴａのハッシュ値から生成された分割証明書を保有していることを完全に証明することはできない。すなわち、単にリソースを要求する利用者Ｂが提示した分割証明書（ＤＣＴａ１）が、証明書ＣＴａのハッシュ値の一部と合致することが証明できるだけである。そのため、アクセス制御部２０は、上記のように証明が完全でない場合には、アクセス制御で提示する情報のレベルを下げるような運用を採用してもよい。また、このような運用を採用すれば、分割証明書の提出状況に応じて、端末Ｔｂのユーザインタフェース１９６上に表示可能なデータを制限できるので、利用者Ｂは、状況に合わせて分割証明書を使い分けることができる。例えば、利用者Ｂは、他人と一緒にいる場合には、一部の分割証明書のみを提出して、表示が制限された状態でデータ操作を行い、１人になったら、他の分割証明書を追加提出することで、表示制限を解除するようにしてもよい。
【００９８】
以上のように、本第８の実施形態では、分割証明書の少なくとも１つに基づいてアクセス制御を行うので、リソース要求者側（端末Ｔｂ側）から提出される分割証明書の数等に基づいて、種々のアクセス制御を行うことが可能となる。
【００９９】
なお、分割証明書は、公開用の分割証明書と、秘密裏に運用するための分割証明書にその役割を割り当てることもできる。例えば、利用者Ｂの作成した証明書をＣＴｂとし、当該証明書ＣＴｂの分割証明書をＤＣＴｂ１、ＤＣＴｂ２とする。そして、利用者Ａのブログデータを閲覧するには、利用者Ｂであることを証明する必要があるとする。この場合、まず、利用者Ｂは自分のブログ等において、分割証明書ＤＣＴｂ１を公開鍵のような形で公開する。これに対し、利用者Ａの端末Ｔａのアクセス制御ポリシー管理部２２は、アクセス制御ポリシーを作成するにあたって、利用者Ｂの公開している分割証明書ＤＣＴｂ１を取得・管理する。そして、利用者Ｂ（端末Ｔｂ）が利用者Ａのブログデータに対するアクセスを要求した場合には、アクセス制御部２０は、分割符合の組を要求する。
【０１００】
この場合、利用者Ｂは、秘密裏に管理されていた分割証明書ＤＣＴｂ２と、分割前の証明書ＣＴｂ１をアクセス制御部２０に対して提示する。アクセス制御部２０は、保管していた分割証明書ＤＣＴｂ１と受領した分割証明書ＤＣＴｂ２とで、証明書ＣＴｂ１が構成できるか否かを判定する。この場合において、証明書ＣＴｂ１が構成できると判定された場合には、アクセス制御部２０は、利用者Ｂによる、利用者Ａのブログデータの閲覧を許可することができる。
【０１０１】
なお、上述したように、受領した分割証明書の組み合わせによってアクセス制限をかけるために、秘密分散法で、復号(ＤＣＴａ１，ＤＣＴａ２)＝復号(ＤＣＴａ１，ＤＣＴａ３)＝復号（ＤＣＴａ２，ＤＣＴａ３）＝ＣＴａである分割証明書を用いる場合、（復号した情報，ＤＣＴａ１，ＤＣＴａ２)、（復号した情報，ＤＣＴａ１，ＤＣＴａ３）、（復号した情報，ＤＣＴａ２，ＤＣＴａ３）の組み合わせ毎に、付与する権限を変えるなどすることができる。この場合、各分割証明書を渡す段階において、どの分割証明書の組で、どのアクセス権限が付与されるのかを注意して配布する必要がある。
【０１０２】
《第９の実施形態》
次に、第９の実施形態について、図１９，図２０に基づいて説明する。なお、本第９の実施形態の装置構成は、第１の実施形態と同様であるものとする。本第９の実施形態は、検証に用いるデータ、もしくは、認証結果証明書、更にはそれらを分割符号化したものの配布に画像を用いる点に特徴を有している。
【０１０３】
図１９は、本第９の実施形態で用いられる、画像化された証明書の一例を示している。アクセス制御部２０は、第２の実施形態や第８の実施形態で説明した証明書、分割証明書のデータを、図１９に示すような画像データに加工し、端末Ｔｂ側に送信する。
【０１０４】
ここで、図１９の画像データは、証明書の２次元コードと、証明書を発行した人の写真とが関連付けられた状態となっている。このようにすることで、証明書を提示する場合であっても、２次元コード近傍の写真を見れば、どの利用者から得た証明書であったのかが一目瞭然であるので、適切な証明書の提出が可能となる。
【０１０５】
なお、証明書情報のみならず、単に利用者が保持しているプロフィール情報などの情報を画像化して保持させておいてもよい。この場合、前述した第４の実施形態のような場合において、画像化されたデータを用いて、アクセス制御ポリシーを記述することとしてもよい。
【０１０６】
また、前述した第６の実施形態のように、プロフィールや名刺毎のハッシュ値を比較検証に用いる場合に、検証に必要なデータとしてプロフィールや名刺のハッシュ値を提供する場合にも、画像化されたデータを用いることができる。図２０には、認証時に携帯電話の電話帳情報を画像化してアクセス制御装置に提示するイメージの一例を示している。例えば、認証の際に、図２０（ａ）のような画面が端末Ｔｂのユーザインタフェース部１９３上に表示されるとする。そして、利用者Ｂによって電話帳読み込みボタンが押され、かつ図２０（ｂ）のように電話帳の一部が選択された後に再度電話帳読み込みボタンが押されたとする。この場合、情報管理部４２は、選択された電話帳の一部のデータ（テキストデータ）に基づいて、図２０（ｃ）に示すような画像を生成する。そして、利用者Ｂによって認証のボタンが押されると、情報管理部４２は、当該画像を端末Ｔａのアクセス制御部２０に送信する。この場合、アクセス制御部２０では、送信されてきた画像を用いてアクセス制御を行うこととなる。
【０１０７】
なお、上記各実施形態は、適宜組み合わせることができる。一例として、第３の実施形態のように複数種類のデータを用いてアクセス制御を行うという概念は、その他の実施形態においても適用することができる。
【０１０８】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
【０１０９】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１１０】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１１１】
上述した各実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【０１１２】
なお、以上の説明に関して更に以下の付記を開示する。
（付記１） リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得し、
前記アクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得し、
前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する、処理をコンピュータに実行させることを特徴とするアクセス制御プログラム。
（付記２） 前記判断する処理における判断結果に基づいて、前記第２端末のアクセス制御を行う処理を前記コンピュータに更に実行させることを特徴とする付記１に記載のアクセス制御プログラム。
（付記３） 前記判断する処理において前記第２端末からの前記リソースに対するアクセスが可能と判断した場合に、前記第２端末に対して証明書を発行する処理を、前記コンピュータに更に実行させ、
前記判断する処理では、前記第２端末から前記証明書が提示された場合にも、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記１又は２に記載のアクセス制御プログラム。
（付記４） 前記証明書を発行する処理では、証明書を分割して発行し、
前記判断する処理では、前記分割された証明書の少なくとも一部が提示された場合に、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記３に記載のアクセス制御プログラム。
（付記５） 前記アクセス制御条件は、複数種類の特定の情報に関する類似性で定義され、
前記取得する処理では、前記第１、第２端末から前記複数種類の特定の情報を取得することを特徴とする付記１〜４のいずれかに記載のアクセス制御プログラム。
（付記６） 前記取得する処理では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、
前記判断する処理では、前記第１端末及び前記第２端末から取得した各符号化した情報の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記１〜５のいずれかに記載のアクセス制御プログラム。
（付記７） 前記取得する処理では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、
前記判断する処理では、前記第１端末及び前記第２端末から取得した各文字の個数の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記１〜５のいずれかに記載のアクセス制御プログラム。
（付記８） 前記アクセス制御条件は、前記第１端末から得られる特定の情報の集合と前記第２端末から得られる特定の情報の集合との類似性で定義され、
前記取得する処理では、前記第１、第２端末から特定の情報の集合を取得し、
前記判断する処理では、前記第１、第２端末から取得した各情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする付記１〜７のいずれかに記載のアクセス制御プログラム。
（付記９） リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得工程と、
前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断工程と、をコンピュータが実行することを特徴とするアクセス制御方法。
（付記１０） 前記判断工程における判断結果に基づいて、前記第２端末のアクセス制御を行うアクセス制御工程を前記コンピュータが更に実行することを特徴とする付記９に記載のアクセス制御方法。
（付記１１） 前記判断工程において前記第２端末からの前記リソースに対するアクセスが可能と判断された場合に、前記第２端末に対して証明書を発行する証明書発行工程を、前記コンピュータが更に実行し、
前記判断工程では、前記第２端末から前記証明書が提示された場合にも、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記９又は１０に記載のアクセス制御方法。
（付記１２） 前記証明書発行工程では、証明書を分割して発行し、
前記判断工程では、前記分割された証明書の少なくとも一部が提示された場合に、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記１１に記載のアクセス制御方法。
（付記１３） 前記アクセス制御条件は、複数種類の特定の情報に関する類似性で定義され、
前記取得工程では、前記第１、第２端末から前記複数種類の特定の情報を取得することを特徴とする付記９〜１３のいずれかに記載のアクセス制御方法。
（付記１４） 前記取得工程では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、
前記判断工程では、前記第１端末及び前記第２端末から取得した各符号化した情報の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記９〜１３のいずれかに記載のアクセス制御方法。
（付記１５） 前記取得工程では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、
前記判断工程では、前記第１端末及び前記第２端末から取得した各文字の個数の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記９〜１３のいずれかに記載のアクセス制御方法。
（付記１６） 前記アクセス制御条件は、前記第１端末から得られる特定の情報の集合と前記第２端末から得られる特定の情報の集合との類似性で定義され、
前記取得工程では、前記第１、第２端末から特定の情報の集合を取得し、
前記判断工程では、前記第１、第２端末から取得した各情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする付記９〜１５のいずれかに記載のアクセス制御方法。
（付記１７） リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件を管理する管理部と、
前記アクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得部と、
前記取得部が前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断部と、を備えるアクセス制御装置。
（付記１８） 前記判断部による判断結果に基づいて、前記第２端末のアクセス制御を行う制御部を更に備える付記１７に記載のアクセス制御装置。
（付記１９） 前記判断部が前記第２端末からの前記リソースに対するアクセスが可能と判断した場合に、前記第２端末に対して証明書を発行する証明書発行部を更に備え、
前記判断部は、前記第２端末から前記証明書が提示された場合にも、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記１７又は１８に記載のアクセス制御装置。
（付記２０） 前記証明書発行部は、証明書を分割して発行し、
前記判断部は、前記分割された証明書の少なくとも一部が提示された場合に、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記１９に記載のアクセス制御装置。
（付記２１） 前記管理部は、複数種類の特定の情報に関する類似性で定義された前記アクセス制御条件を管理し、
前記取得部は、前記第１、第２端末から前記複数種類の特定の情報を取得することを特徴とする付記１７〜２０のいずれかに記載のアクセス制御装置。
（付記２２） 前記取得部は、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、
前記判断部は、前記第１端末及び前記第２端末から取得した各符号化した情報の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記１７〜２１のいずれかに記載のアクセス制御装置。
（付記２３） 前記取得部は、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、
前記判断部は、前記第１端末及び前記第２端末から取得した各文字の個数の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記１７〜２１のいずれかに記載のアクセス制御装置。
（付記２４） 前記管理部は、前記第１端末から得られる特定の情報の集合と前記第２端末から得られる特定の情報の集合との類似性で定義された前記アクセス制御条件を管理し、
前記取得部は、前記第１、第２端末から特定の情報の集合を取得し、
前記判断部は、前記取得部が前記第１、第２端末から取得した各情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする付記１７〜２３のいずれかに記載のアクセス制御装置。
【符号の説明】
【０１１３】
２０ アクセス制御部（取得部の一部、判断部の一部、制御部）
２２ アクセス制御ポリシー管理部（管理部）
２４ 比較照合部（取得部の一部）
２６ アクセス制御部（取得部の一部）
２８ 証明書発行部
Ｔａ 端末（第１端末）
Ｔｂ 端末（第２端末）
【特許請求の範囲】
【請求項１】
リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得し、
前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する、処理をコンピュータに実行させることを特徴とするアクセス制御プログラム。
【請求項２】
前記判断する処理における判断結果に基づいて、前記第２端末のアクセス制御を行う処理を前記コンピュータに更に実行させることを特徴とする請求項１に記載のアクセス制御プログラム。
【請求項３】
前記判断する処理において前記第２端末からの前記リソースに対するアクセスが可能と判断した場合に、前記第２端末に対して証明書を発行する処理を、前記コンピュータに更に実行させ、
前記判断する処理では、前記第２端末から前記証明書が提示された場合にも、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする請求項１又は２に記載のアクセス制御プログラム。
【請求項４】
前記証明書を発行する処理では、証明書を分割して発行し、
前記判断する処理では、前記分割された証明書の少なくとも一部が提示された場合に、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする請求項３に記載のアクセス制御プログラム。
【請求項５】
前記アクセス制御条件は、複数種類の特定の情報に関する類似性で定義され、
前記取得する処理では、前記第１、第２端末から前記複数種類の特定の情報を取得することを特徴とする請求項１〜４のいずれか一項に記載のアクセス制御プログラム。
【請求項６】
前記取得する処理では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、
前記判断する処理では、前記第１端末及び前記第２端末から取得した各符号化した情報の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする請求項１〜５のいずれか一項に記載のアクセス制御プログラム。
【請求項７】
前記取得する処理では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、
前記判断する処理では、前記第１端末及び前記第２端末から取得した各文字の個数の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする請求項１〜５のいずれか一項に記載のアクセス制御プログラム。
【請求項８】
前記アクセス制御条件は、前記第１端末から得られる特定の情報の集合と前記第２端末から得られる特定の情報の集合との類似性で定義され、
前記取得する処理では、前記第１、第２端末から特定の情報の集合を取得し、
前記判断する処理では、前記第１、第２端末から取得した情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする請求項１〜７のいずれか一項に記載のアクセス制御プログラム。
【請求項９】
リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得工程と、
前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断工程と、をコンピュータが実行することを特徴とするアクセス制御方法。
【請求項１０】
リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件を管理する管理部と、
前記アクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得部と、
前記取得部が前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断部と、を備えるアクセス制御装置。
【請求項１】
リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得し、
前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する、処理をコンピュータに実行させることを特徴とするアクセス制御プログラム。
【請求項２】
前記判断する処理における判断結果に基づいて、前記第２端末のアクセス制御を行う処理を前記コンピュータに更に実行させることを特徴とする請求項１に記載のアクセス制御プログラム。
【請求項３】
前記判断する処理において前記第２端末からの前記リソースに対するアクセスが可能と判断した場合に、前記第２端末に対して証明書を発行する処理を、前記コンピュータに更に実行させ、
前記判断する処理では、前記第２端末から前記証明書が提示された場合にも、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする請求項１又は２に記載のアクセス制御プログラム。
【請求項４】
前記証明書を発行する処理では、証明書を分割して発行し、
前記判断する処理では、前記分割された証明書の少なくとも一部が提示された場合に、前記第２端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする請求項３に記載のアクセス制御プログラム。
【請求項５】
前記アクセス制御条件は、複数種類の特定の情報に関する類似性で定義され、
前記取得する処理では、前記第１、第２端末から前記複数種類の特定の情報を取得することを特徴とする請求項１〜４のいずれか一項に記載のアクセス制御プログラム。
【請求項６】
前記取得する処理では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、
前記判断する処理では、前記第１端末及び前記第２端末から取得した各符号化した情報の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする請求項１〜５のいずれか一項に記載のアクセス制御プログラム。
【請求項７】
前記取得する処理では、前記第１端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第２端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、
前記判断する処理では、前記第１端末及び前記第２端末から取得した各文字の個数の一致・不一致に基づいて、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする請求項１〜５のいずれか一項に記載のアクセス制御プログラム。
【請求項８】
前記アクセス制御条件は、前記第１端末から得られる特定の情報の集合と前記第２端末から得られる特定の情報の集合との類似性で定義され、
前記取得する処理では、前記第１、第２端末から特定の情報の集合を取得し、
前記判断する処理では、前記第１、第２端末から取得した情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする請求項１〜７のいずれか一項に記載のアクセス制御プログラム。
【請求項９】
リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得工程と、
前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断工程と、をコンピュータが実行することを特徴とするアクセス制御方法。
【請求項１０】
リソースを保持する第１端末から得られる特定の情報とリソースに対するアクセスを要求する第２端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件を管理する管理部と、
前記アクセス制御条件に基づいて、前記第１端末から特定の情報を取得するとともに、前記第２端末から特定の情報を取得する取得部と、
前記取得部が前記第１、第２端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第２端末からの前記リソースに対するアクセスが可能か否かを判断する判断部と、を備えるアクセス制御装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２０１３−６９１４２（Ｐ２０１３−６９１４２Ａ）
【公開日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願番号】特願２０１１−２０７５７８（Ｐ２０１１−２０７５７８）
【出願日】平成２３年９月２２日（２０１１．９．２２）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願日】平成２３年９月２２日（２０１１．９．２２）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]