"リソースを保持する第1端末から得られる特定の情報とリソースに対するアクセスを要求する第2端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第1端末から特定の情報を取得するとともに、前記第2端末から特定の情報を取得し、前記第1、第2端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断する、処理をコンピュータに実行させることを特徴とするアクセス制御プログラム。前記判断する処理における判断結果に基づいて、前記第2端末のアクセス制御を行う処理を前記コンピュータに更に実行させることを特徴とする請求項1に記載のアクセス制御プログラム。前記判断する処理において前記第2端末からの前記リソースに対するアクセスが可能と判断した場合に、前記第2端末に対して証明書を発行する処理を、前記コンピュータに更に実行させ、前記判断する処理では、前記第2端末から前記証明書が提示された場合にも、前記第2端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする請求項1又は2に記載のアクセス制御プログラム。前記証明書を発行する処理では、証明書を分割して発行し、前記判断する処理では、前記分割された証明書の少なくとも一部が提示された場合に、前記第2端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする請求項3に記載のアクセス制御プログラム。前記アクセス制御条件は、複数種類の特定の情報に関する類似性で定義され、前記取得する処理では、前記第1、第2端末から前記複数種類の特定の情報を取得することを特徴とする請求項1~4のいずれか一項に記載のアクセス制御プログラム。前記取得する処理では、前記第1端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第2端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、前記判断する処理では、前記第1端末及び前記第2端末から取得した各符号化した情報の一致不一致に基づいて、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする請求項1~5のいずれか一項に記載のアクセス制御プログラム。前記取得する処理では、前記第1端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第2端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、前記判断する処理では、前記第1端末及び前記第2端末から取得した各文字の個数の一致不一致に基づいて、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする請求項1~5のいずれか一項に記載のアクセス制御プログラム。前記アクセス制御条件は、前記第1端末から得られる特定の情報の集合と前記第2端末から得られる特定の情報の集合との類似性で定義され、前記取得する処理では、前記第1、第2端末から特定の情報の集合を取得し、前記判断する処理では、前記第1、第2端末から取得した情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする請求項1~7のいずれか一項に記載のアクセス制御プログラム。リソースを保持する第1端末から得られる特定の情報とリソースに対するアクセスを要求する第2端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第1端末から特定の情報を取得するとともに、前記第2端末から特定の情報を取得する取得工程と、前記第1、第2端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断する判断工程と、をコンピュータが実行することを特徴とするアクセス制御方法。リソースを保持する第1端末から得られる特定の情報とリソースに対するアクセスを要求する第2端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件を管理する管理部と、前記アクセス制御条件に基づいて、前記第1端末から特定の情報を取得するとともに、前記第2端末から特定の情報を取得する取得部と、前記取得部が前記第1、第2端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断する判断部と、を備えるアクセス制御装置。しかしながら、上記特許文献1では、アクセスを許可又は拒否する人を一人一人システムに登録し、管理しておく必要があり、登録には手間と時間を要する。これに対し、各ユーザを登録、管理することなく、アクセスを許可するユーザを大まかに分類して指定することができるようになれば、今後、種々のシステムへの利用が期待できると考えられる。そこで本件は上記の課題に鑑みてなされたものであり、リソースに対するアクセスを要求する端末を個別に特定することなく、アクセスの可否を判断可能なアクセス制御プログラム、アクセス制御方法及びアクセス制御装置を提供することを目的とする。本明細書に記載のアクセス制御プログラムは、リソースを保持する第1端末から得られる特定の情報とリソースに対するアクセスを要求する第2端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第1端末から特定の情報を取得するとともに、前記第2端末から特定の情報を取得し、前記第1、第2端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断する、処理をコンピュータに実行させるアクセス制御プログラムである。本明細書に記載のアクセス制御方法は、リソースを保持する第1端末から得られる特定の情報とリソースに対するアクセスを要求する第2端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第1端末から特定の情報を取得するとともに、前記第2端末から特定の情報を取得する取得工程と、前記第1、第2端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断する判断工程と、をコンピュータが実行するアクセス制御方法である。本明細書に記載のアクセス制御装置は、リソースを保持する第1端末から得られる特定の情報とリソースに対するアクセスを要求する第2端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件を管理する管理部と、前記アクセス制御条件に基づいて、前記第1端末から特定の情報を取得するとともに、前記第2端末から特定の情報を取得する取得部と、前記取得部が前記第1、第2端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断する判断部と、を備えるアクセス制御装置である。本明細書に記載のアクセス制御プログラム、アクセス制御方法及びアクセス制御装置は、リソースに対するアクセスを要求する端末を個別に特定することなく、アクセスの可否を判断できるという効果を奏する。《第1の実施形態》以下、第1の実施形態について、図1~図8に基づいて詳細に説明する。図1には、第1の実施形態に係る情報処理システム100の構成が概略的に示されている。情報処理システム100は、リソースの権利者が利用する第1端末としての端末Taと、リソースの要求者が利用する第2端末としての端末Tbと、を有している。これら端末Ta,Tbは、インターネットなどのネットワーク80に接続されており、端末Ta,Tb間における通信が可能な状態となっている。ここで、リソースとは、アクセス制御対象の単位となるものを指す。例えば、Webサイトにおけるアクセス制御であれば、リソースは、各URLで参照されるファイルや、URLで示されたフォルダ内に存在するファイルの全てを意味する。また、勤務先のドアに付帯したアクセス制御である場合には、リソースは、ドアそのもの、もしくは、当該ドアの先にあるもの全てを意味する。なお、本第1の実施形態では、端末Ta,Tbで管理されているエンティティのデータを用いてアイデンティティ類似性IS:IdentitySimilarityを検証し、エンティティの認証及び当該認証結果を利用したアクセス制御を行う。ここで、エンティティとは、人や物端末等を意味している。また、エンティティのデータとは、端末Ta,Tbが保有するデータ全て、又は各端末を利用するユーザ別に利用可能なデータを意味する。具体的には、エンティティのデータには、利用者本人が作成したファイル群や、アプリケーションが作成した利用者用のデータ、あるいは利用者のシステムの利用履歴などが含まれる。なお、利用履歴等の本人やアプリケーションが保存したデータに対する背景情報例えば、ファイルに付加された当該ファイル更新日時等のみを指す場合には、メタデータという。また、アイデンティティ類似性とは、エンティティと、別のエンティティが類似しているかどうかを、各エンティティのデータの共通性等に基づいて数値で表したものを意味する。なお、以下においては、1台の端末が1人の利用者専用の端末であるより具体的には、端末Taの利用者がAであり、端末Tbの利用者がBであるものとする。このため、本第1の実施形態におけるエンティティは、端末Ta又は利用者Aと、端末Tb又は利用者Bとなる。端末Taは、例えば、PC、携帯電話などの端末であるものとする。端末Taは、図2aに示すようなハードウェア構成を有する。具体的には、端末Taは、CPU90、ROM92、RAM94、記憶部ここではHDDHardDiskDrive96、ネットワークインタフェース97、ユーザインタフェース部93、及び可搬型記憶媒体用ドライブ99等を備える。端末Taの構成各部は、バス98に接続されている。ユーザインタフェース部93は、ディスプレイなどの表示装置や、キーボードやマウスなどの入力装置を含む。端末Taでは、ROM92あるいはHDD96に格納されているプログラムアクセス制御プログラム、或いは可搬型記憶媒体用ドライブ99が可搬型記憶媒体91から読み取ったプログラムアクセス制御プログラムをCPU90が実行することにより、図3の各部の機能が実現される。なお、プログラムアクセス制御プログラムをネットワーク80を介してインストールできるような場合には、端末Taに可搬型記憶媒体用ドライブ99を設けないようにしてもよい。端末Tbは、図2bに示すようなハードウェア構成を有する。端末Tbは、端末Taと同様の構成となっている。具体的には、端末Tbは、CPU190、ROM192、RAM194、記憶部HDD196、ネットワークインタフェース197、ユーザインタフェース部193、及び可搬型記憶媒体用ドライブ199等を備える。端末Tbの構成各部は、バス198に接続されている。端末Tbでは、ROM192あるいはHDD196に格納されているプログラムアクセス制御プログラム、或いは可搬型記憶媒体用ドライブ199が可搬型記憶媒体191から読み取ったプログラムアクセス制御プログラムをCPU190が実行することにより、図3の各部の機能が実現される。なお、プログラムアクセス制御プログラムをネットワーク80を介してインストールできるような場合には、端末Tbに可搬型記憶媒体用ドライブ99を設けないようにしてもよい。図3には、端末Ta及び端末Tbの機能ブロック図が示されている。図3に示すように、端末Taは、CPU90がプログラムを実行することで、アクセス制御部20、管理部としてのアクセス制御ポリシー管理部22、比較照合部24、及び情報管理部26、としての機能を実現している。また、端末Tbは、CPU190がプログラムを実行することで、リソースリクエスト部40、及び情報管理部42、としての機能を実現している。なお、図3では、端末TaのHDD96等に格納される各種DB及びテーブル以下TBLと記述するも図示されている。これら各種DB及びTBLには、図3に示すように、リソース群DB31、アクセス制御ポリシーTBL32、記述定義TBL33、検証条件複合TBL34、検証条件TBL35、Store用プロパティTBL36、IS検証用データTBL37が含まれる。次に、上記各部について、詳細に説明する。アクセス制御部20は、端末Tbから端末Taのリソース群DB31に格納されているリソースに対するアクセス要求を受け付ける。そして、アクセス制御部20は、端末Taからアクセス制御に必要な特定の情報を取得するとともに、端末Tbからアクセス制御に必要な特定の情報を取得する。なお、特定の情報とは、後述するアクセス制御条件としてのアクセス制御ポリシーにおいて定義されている、アクセス制御に用いる情報を意味する。また、アクセス制御部20は、アクセス制御ポリシー管理部22及び比較照合部24と連携し、アクセス制御ポリシーと、取得したデータと、に基づいて、端末Tbのアクセス制御を実行する。ここで、リソース群DB31には、アクセス制御対象であるリソースが格納される。リソースには、様々なファイル、データ等が含まれる。なお、本第1の実施形態では、リソースに、利用者Aが端末Ta内で保有する会員証登録簿内で管理されている店舗の情報店名住所電話番号等が含まれているものとする。アクセス制御ポリシー管理部22は、アクセス制御ポリシーTBL32、記述定義TBL33、検証条件複合TBL34、検証条件TBL35、及びStore用プロパティTBL36に基づいてアクセス制御ポリシーを生成し、管理する。ここで、アクセス制御ポリシーTBL32は、一例として、図4aに示すように、リソースと、対象と、AllowDenyの各フィールドを有する。リソースのフィールドには、アクセス制御に係るリソースの名称が記述される。対象のフィールドには、リソースに対するアクセスを許可又は不許可とする対象が記述される。AllowDenyの各フィールドには、対象に対するアクセスを許可するAllowか、不許可とするDenyか、が記述される。記述定義TBL33は、一例として、図4bに示すように、検証文と、検証条件複合ID参照のフィールドを有する。検証条件複合TBL34は、一例として、図4cに示すように、検証条件複合IDと、複合条件演算と、検証条件ID1参照と、検証条件ID2参照の各フィールドを有する。検証条件TBL35は、一例として、図5aに示すように、検証条件IDと、検証条件演算と、検証方向と、クリア条件と、検証対象と、Store用プロパティID参照の各フィールドを有する。Store用プロパティTBL36は、一例として、図5bに示すように、Store用プロパティID、データタイプ、Sameas、from、toなどのフィールドを有する。これら各TBL33~36は、アクセス制御ポリシー管理部22により管理されている。これら各TBL33~36からは、アクセス制御ポリシーとして、検証文:会員登録している店舗ならば、リソースSystemrscPhonebookへのアクセス権限を付与する、という内容が定義されている。すなわち、アクセス制御ポリシーでは、会員登録しているかどうかという観点で見た時にアイデンティティ類似性ISが高い会員登録している可能性が高いかどうかを検証することが定められている。また、検証条件TBL35やStore用プロパティTBL36では、IS検証用データTBL37図5c参照に含まれている電話帳データSystemrscPhonebookのうち店舗電話番号のラベルがついたデータの少なくとも1つが、端末Tbから得られるデータの1つと同一であれば、アクセス権限を付与する、ということが定められている。図3に戻り、比較照合部24は、記述定義TBL33等から生成されるアクセス制御ポリシーに基づいて、アクセス制御部20が取得した情報を比較照合し、当該比較照合結果検証結果とも呼ぶをアクセス制御部20に回答する。情報管理部26は、IS検証用データTBL37において、アイデンティティ類似性ISを検証するためのデータを管理する。なお、利用者Aは、端末Taにおいて会員証情報を管理しているものとし、情報管理部26は、当該会員証情報から電話番号を抽出して、IS検証用データTBL37を生成する。ここで、IS検証用データTBL37は、一例として、図5cに示すように、検証用データIDと、検証用データタイプと、検証用データの各フィールドを有する。検証用データタイプのフィールドには、店舗電話番号などのデータの種類が記述され、検証用データのフィールドには、電話番号などの実データが記述される。なお、検証用データタイプのフィールドは、検証データのフィールドに記述される実データのラベルとしての機能を有する。図3に戻り、端末Tbのリソースリクエスト部40は、端末Tbの利用者Bが、ユーザインタフェース部193からリソースへのアクセスをリクエストした場合に、当該リクエストを端末Taのアクセス制御部20に対して送信する。情報管理部42は、アクセス制御部20から要求される、アクセス制御に必要なデータを送信する。なお、端末Taは、図3に示す機能のほか、端末Tbの機能を併せ持っていても良いし、端末Tbは、図3に示す機能のほか、端末Taの機能を併せ持っていても良い。次に、図6のフローチャートに沿って、端末Ta、端末Tbの処理について詳細に説明する。図6では、左側のフローチャートが端末Tbの処理を示しており、右側のフローチャートが端末Taの処理を示している。なお、以下の説明では、図6及び図7に示す、処理及びデータの流れを示す番号括弧付き番号を適宜用いるものとする。なお、本第1の実施形態では、端末Tbを利用する利用者Bリソースの要求者がリソースを保有する端末Taの利用者Aリソースの権利者のよく行く店舗であるものとする。そして、リソースには、利用者Aの会員証登録簿内で管理されている利用者Bの店舗情報店名住所電話番号等を含む会員証情報を含むものとする。また、以下では、利用者Bが、端末Tbを介して端末Taが保有する会員証情報にアクセスすることで当該会員証情報を変更しようとしており、端末Taでは、以下に説明する方法で、端末Tbのアクセス制御を行うものとする。また、以下の処理で用いるアクセス制御ポリシーは、図4、図5の各テーブル33~36から導き出されるアクセス制御ポリシーであるものとする。図6の処理では、まず、ステップS10において、端末Tbのリソースリクエスト部40が、リソースに対するアクセスのリクエストが入力されるまで待機する。この場合、リソースリクエスト部40では、ユーザインタフェース部193を介した利用者Bからのリクエストが入力された段階で、ステップS12に移行する。ステップS12では、リソースリクエスト部40が、リソースに対するアクセスのリクエストを、端末Taのアクセス制御部20に対して送信する図7の1参照。なお、上記ステップS10、S12では、リソースリクエスト部40が、利用者Bからのリクエストの入力があった段階でリクエストを端末Taに対して送信する場合について説明したが、これに限られるものではない。例えば、リソースリクエスト部40は、端末Tbと端末Taとの距離が赤外線等による通信が可能になる程度の距離に近づくまで待機し、近づいた段階で、自動的に端末Taに対してリクエストを送信するようにしてもよい。上記ステップS10、S12の処理の間、端末Taのアクセス制御部20は、ステップS110において、リソースに対するアクセスのリクエストを受信するまで待機している。そして、ステップS12において、端末Tb側からアクセス制御部20に対してリクエストが送られてくると、アクセス制御部20は、ステップS112に移行する。ステップS112では、アクセス制御部20は、端末Tb側から送信されてきたリクエストを受け付ける。次いで、ステップS114では、アクセス制御ポリシー管理部22が、アクセス制御ポリシーTBL32を参照して、アクセス制御ポリシーを確認する図7の2参照。次いで、ステップS116では、記述定義TBL33等を参照して、検証に必要なデータと確認内容を確定する図7の3参照。次いで、ステップS118では、アクセス制御部20が、端末Tbの情報管理部42に対して、ステップS116で確定した検証に必要なデータを要求する図7の4参照。ここでは、前述したように、アクセス制御ポリシーでは、店舗電話番号のラベルが付されているデータ電話番号が検証に必要なデータとなっている。上記端末Taの処理の間、端末Tbでは、ステップS14において、端末Taからの要求があるまで待機している。そして、ステップS118においてアクセス制御部20からの要求があると、ステップS16に移行する。ステップS16では、情報管理部42が、データ要求を受け付ける。次いで、ステップS18では、情報管理部42が、端末Tbが保有するデータの中から、アクセス制御部20により要求されたデータのうち、利用者Bが無制限に公開しているデータを選択して、送信する図7の5参照。ここで、情報管理部42からアクセス制御部20に対して送信されたデータは、図8aのような店舗電話番号Lb1,Lb2であったものとする。なお、端末Tb側では、これ以降、ステップS20において、次に端末Taからデータ等が送られてくるまで待機する。なお、端末Taのアクセス制御部20は、ステップS118の処理以降は、ステップS120において、データを受信するまで待機している。したがって、アクセス制御部20は、ステップS18において端末Tb側からデータが送信されてきた段階で、ステップS122に移行する。ステップS122では、アクセス制御部20は、端末Tb側から送信されてきたデータを受け付ける。次いで、ステップS124では、アクセス制御部20の指示の下、比較照合部24が、端末Ta,Tbのデータを用いた比較照合を実行する図7の6参照。この場合、比較照合部24は、端末Taが保有する店舗電話番号をアクセス制御部20を介して情報管理部26IS検証用データTBL37から取得する。なお、比較照合部24が取得した店舗電話番号は、図8bに示す電話番号であったものとする。そして、比較照合部24は、ステップS122で受け付けたデータ端末Tbが保有する店舗電話番号図8b参照と比較照合する。この場合、比較照合部24は、比較照合により、図8cの表のような照合結果を得ることができる。なお、図8cの表では、0が、電話番号の不一致を示し、1が、電話番号の一致を示す。次いで、ステップS126では、アクセス制御部20が、アクセスOKであるかアクセスを許可するか否かを判断する。この場合、アクセス制御部20は、アクセス制御ポリシー端末Ta,Tbにおいて同一の店舗電話番号を最低1つ保有を満たしているか否かを判断する。ここでは、図8cより、店舗電話番号La3とLb2が同一である。したがって、アクセス制御部20は、アクセスを許可すると判断する。なお、この場合のIS一致傾向x/100は、最大100/100であるといえる。この場合、アクセス制御部20は、ステップS128において、端末Tbのリソースリクエスト部40に対して、リソースを応答する図7の7参照。この端末Ta側からのリソースの応答により、端末Tbでは、ステップS20の判断が肯定されて、ステップS22に移行する。そして、リソースリクエスト部40は、ステップS22においてリソースの受付を行う。これにより、端末Tb側では、リソースに対するアクセスが可能となるため、利用者Bは、端末Tbのユーザインタフェース部193を介して、自店舗の情報の書き換えを行うことが可能となる。一方、端末Ta側において、ステップS126の判断が否定された場合、すなわち、アクセスがNGであると判断された場合には、ステップS130に移行する。アクセス制御部20は、ステップS130において、アクセスがNGアクセス不可である旨のメッセージを端末Tbのリソースリクエスト部40に対して回答する図7の8参照。この回答があった場合、端末Tbでは、ステップS20の判断が肯定されて、ステップS22に移行する。そして、ステップS22では、リソースリクエスト部40が、アクセスがNGであることのメッセージの受付を行う。これにより、端末Tb側では、端末Taへのアクセスができない旨のメッセージをユーザインタフェース部193に表示することが可能となる。なお、これまでの説明から明らかなように、アクセス制御部20は、制御部としての機能を有している。また、アクセス制御部20と情報管理部26とにより、取得部としての機能が実現されている。更に、アクセス制御部20と比較照合部24とにより、判断部としての機能が実現されている。以上、詳細に説明したように、本第1の実施形態によると、アクセス制御ポリシー管理部22が、リソースを保持する端末Taから得られる特定の情報例えば店舗電話番号とリソースに対するアクセスを要求する端末Tbから得られる特定の情報例えば店舗電話番号との類似性アイデンティティ類似性ISで定義される、リソースに対するアクセス制御ポリシーを管理している。また、アクセス制御部20が、アクセス制御ポリシーに基づいて、端末Ta及び端末Tbから特定の情報例えば店舗電話番号を取得し、当該取得された各情報の類似性が検証条件を満たすか否かを検証することで、端末Tbからのリソースに対するアクセスが可能か否かを判断する。これにより、本第1の実施形態では、リソースに対するアクセスを要求する端末を個別に特定することなく、リソースに対するアクセスの可否を判断することが可能となる。したがって、アクセス制御対象の端末やユーザごとの登録が不要となり、登録の手間や登録に要する時間を低減することができるとともに、アクセス可否の単位を、検証条件を満たす端末やユーザという大まかな範囲とすることができる。また、本第1の実施形態では、アクセス制御部20が、アクセス可否の判断結果に基づいてアクセス制御を行うので、端末Tb自体を登録しなくても、端末Tbからのアクセスを適切に制御することが可能となる。また、本第1の実施形態では、アクセス制御ポリシーを適宜変更することで、種々のアクセス制御が可能である。一例として、以下のようなアクセス制御が可能である。1同一エリアに居住している住人であれば、位置情報付きの風景写真に対するアクセスを可能とする。2同じエリアに住んでいない人土地勘の無い人であれば、自己のブログへのアクセスを可能とする。3仕事関係の共通の知人が多ければ、仕事用プロフィールの閲覧を可能とする。なお、上記第1の実施形態では、IS検証用データとして電話番号のような完全一致検証ができるデータを用いることとしたが、これに限られるものではない。例えば、IS検証用データとしては、類似度を検証できるデータ例えば、住所を用いることとしても良い。この場合においても、図8cのようなマトリクスを用いることで、比較照合が可能となる。ただし、マトリクスの各格子にどのような計算結果が入るかは、用いる類似度関数に依存し、用意された類似度関数中のどの関数を使用するかは、用いるIS検証用データのラベルや確認したい内容によって異なる。この場合、アクセス制御部20では、マトリクスに入力される数値を用いて、所定の演算によりIS一致傾向=x/100を算出し、当該IS一致傾向が所定の閾値よりも大きい場合すなわち、アクセス制御条件を満たす場合に、アクセスを許可するなどの制御をすることができる。《第2の実施形態》以下、第2の実施形態について、図9に基づいて説明する。本第2の実施形態では、アクセス制御部20が一度認証した場合アクセスを許可した場合に、当該認証結果を証明書として発行し、証明書を受け取った端末では、次回以降の認証において、当該証明書を用いて認証を行うこととする。図9には、第2の実施形態に係る端末Ta、Tbの機能ブロック図が示されている第2の実施形態で新たに追加された機能については、太線で表示している。図9に示すように、端末Taは、第1の実施形態で説明した各部に加え、証明書発行部28と、証明書DB39と、を備えている。また、端末Tbは、第1の実施形態で説明した各部に加え、証明書管理部44と、証明書DB46と、を備えている。証明書発行部28は、アクセス制御部20が一度アクセスを許可した場合に、当該アクセス許可情報認証情報をアクセス制御部20から受け取り、証明書を発行して、証明書DB39に格納する。なお、証明書には、リソースに対するアクセス許可がいつなされたのか、を示すための情報が基本情報として含まれているものとする。また、証明書発行部28は、発行した証明書をアクセス制御部20を介して、リソースリクエスト部40に送信する。証明書管理部44は、リソースリクエスト部40から証明書を受け取り、証明書DB46に格納する。また、証明書管理部44は、リソースリクエスト部40がアクセス制御部20に対してアクセスをリクエストする際には、証明書DB46から証明書を読み出して、リソースリクエスト部40に受け渡す。なお、リソースリクエスト部40は、アクセス制御部20に対してアクセスをリクエストする際に、証明書をアクセス制御部20に対して送信する。なお、端末Tb側の証明書DB46において管理される証明書は、端末Ta側の証明書DB39で管理する証明書の全てのデータを含んでいてもよいし、証明書DB39で管理する証明書と紐付ける情報のみであってもよい。また、証明書には、検証用データ上記第1の実施形態の例では、店舗電話番号がどの程度信頼できるデータであるかを示す情報を含めてもよい。この場合、例えば、検証用データとしてGPSラベルのついたデータを用いた場合であれば、単に比較に用いた緯度や経度の情報だけでなく、それらの情報がいつ取得された情報なのか、どの端末によって取得された情報なのか、というメタデータに相当する情報を証明書に含めておくこととしてもよい。これらの情報を用いることで、認証結果の信頼性を推量することが可能となる。また、証明書発行部28は、上記メタデータに相当する情報に基づいて、不確かなデータであることを判別できるような場合には、証明書を発行しないこととしてもよい。また、証明書には、一般的な証明書同様、有効期限を設けることができる。この場合、証明書発行部28は、検証用データの信頼性が高ければ証明書の有効期限を長くし、そうでなければ短くするなどしてもよい。また、証明書の不正な乱用を避けるため、アクセス制御部20は、証明書DB39において、証明書と紐付けて使用回数情報カウンタを管理することとしてもよい。この場合、アクセス制御部20は、証明書使用の度にカウントアップすることで、使用上限値に達した証明書の使用を停止するなどしてもよい。なお、アクセス制御部20は、あるリソースのアクセス制御において発行した証明書を、他のリソースに対するアクセス制御に流用することとしてもよい。この場合、アクセス制御部20は、共通する検証文を有するリソース間において、他のリソースの証明書の流用を許可するなどすればよい。なお、アクセス制御ポリシーが改変された場合、提示された証明書の情報では、改変後の検証文をクリアするのに必要なデータを満足しない場合がある。このような場合には、アクセス制御部20は、端末Tbの情報管理部42に対して不足しているデータの提供を求めるものとする。そして、情報管理部42は、無条件に公開されている情報を優先して、アクセス制御部20に対して提供するようにする。ただし、当該提供では認証が成功しない場合もある。このような場合には、情報管理部42は、端末Tbのユーザインタフェース部193を通じて端末Tbの利用者Bに直接データ開示の確認を行い、確認が取れた後に非公開の情報を提供するようにしてもよい。なお、情報管理部42は、端末Tb上で管理されていない情報であっても、外部のセンサやサービスが提供している情報群を新たに取得して、アクセス制御部20に対して提供することとしてもよい。以上説明したように、本第2の実施形態によると、証明書発行部28は、アクセス制御部20が端末Tbからのアクセスが可能と判断した場合に、端末Tbに対して証明書を発行し、これ以降、アクセス制御部20は、端末Tbから証明書が提示された場合にも、端末Tbのアクセスを許可する。これにより、1度アクセス可能と判断した端末の、以降の認証を簡素化することができる。これにより、アクセス制御の簡素化及び時間短縮を図ることができる。また、証明書に種々の情報を含めることで、上述したような様々なアクセス制御が可能となる。《第3の実施形態》以下、第3の実施形態について、図10~図12に基づいて説明する。本第3の実施形態では、上記第1、第2の実施形態と異なり、複数種類のデータに基づいたアクセス制御が行われるものとする。なお、本第3の実施形態では、図10のような情報処理システムにおけるアクセス制御を行うものとする。この場合、前述した端末Taのアクセス制御に関する機能アクセス制御部20、アクセス制御ポリシー管理部22、比較照合部24、情報管理部26は、図10のサーバ200に設けられているものとする。サーバ200は、端末Taの利用者Aのリソースを保持している。また、サーバ200は、端末Tbからのリソースに対するアクセス制御を、端末Taが保有する特定の情報実際にはサーバ200上に存在と、端末Tbが保有する特定の情報サーバ200上に存在とに基づいて、判断するものとする。なお、各端末Ta,Tbが保有する特定の情報は、各端末Ta,Tbの内部の記憶部等に格納されていてもよい。以下、端末Taの利用者Aが会社を退職した場合において、利用者Aのデータリソースへのアクセスをアイデンティティ類似性ISに基づいて制御する例について説明する。この場合の前提として、利用者Aは、退職前にサーバ200に残すデータを全ての部署員に開示するのではなく、同じプロジェクトに関連している人後述する検証文Sa1を満たす人にのみ開示しようとしている。また、プロジェクトで共用しているデータ等は、他の同僚も持っているので引き継がなくても問題ないが、利用者Aが担当していた範囲の個人的な備忘録などは、同じ仕事に携わる人がアクセスできるようにしようとしている。なお、利用者Aの退職後にプロジェクトに新たに参加する人等には、事前にデータを渡すことができず、また、当該新たに参加する人を個別に指定してサーバに登録するなどすることはできない。したがって、本第3の実施形態においても、上記第1、第2の実施形態と同様、アクセス制御ポリシーを用いるものとする。本第3の実施形態では、記述定義の検証文Sa1において、図11aに示すConda1とConda2の2つが同時に成立する場合にアクセス可能とする検証条件が定義されているものとする。ここで、Conda1で用いるデータは、プロジェクトMLラベルのメールアドレスである。Conda1では、端末Taリソース権利者側の保有するプロジェクトMLラベルのメールアドレスと、端末Tbリソース要求者側の保有するプロジェクトMLラベルのメールアドレスとが1つ以上一致することが条件とされている。一方、Conda2で用いるデータは、プロジェクトラベルの付与されたフォルダのファイルハッシュである。Conda2では、端末Taの保有するプロジェクトラベルの付与されたフォルダのファイルハッシュと、端末Tbの保有するプロジェクトラベルの付与されたフォルダのファイルハッシュとが1つ以上一致することが条件とされている。なお、利用者Aは、退職前に、自動で集計登録されたプロジェクトMLラベルのメールアドレスから不要なアドレスを削除しているものとする。また、利用者Aは、退職前に、プロジェクトラベルのフォルダとしてピックアップされたフォルダから不要なフォルダを削除しているものとする。以下、上記のような状況下において、端末Tbから、端末Taが保有するプロジェクトに関するリソースに対してアクセスがあった場合の、サーバ200主にアクセス制御部20によるアクセス制御について説明する。利用者Aの退職後、プロジェクトに参加した利用者Bは、利用者Aの仕事を引き継ぐこととなり、どういう蓄積データがあるのかを確認しようと、プロジェクトprojectAに関するフォルダ例えばhomeuserAproject2011projectAに、端末Tbを介してアクセスしたとする。この場合、サーバ200のアクセス制御部20は、アクセス制御ポリシー管理部22で管理されているアクセス制御ポリシーの検証条件図11a参照を参照する。そして、アクセス制御部20は、検証条件に基づいて、端末Tbが保有するプロジェクトMLラベルのメールアドレスと、プロジェクトラベルフォルダprojectA以下のファイルハッシュと、を取得する図11b参照。また、アクセス制御部20は、端末Taが保有するプロジェクトMLラベルのメールアドレスと、プロジェクトラベルフォルダprojectA以下のファイルハッシュと、を取得する図11c参照。そして、比較照合部24は、アクセス制御部20の指示の下、取得された各メールアドレス及び各ファイルハッシュを比較照合する。図12aには、プロジェクトMLラベルのメールアドレスの比較照合結果検証結果が示され、図12bには、プロジェクトラベルフォルダprojectA以下のファイルハッシュの比較照合結果検証結果が示されている。これら図12a、図12bでは、アドレスやファイルハッシュが一致している場合に値1が入力され、不一致の場合に値0が入力される。この場合、図12a及び図12bの検証結果には、値1が存在している1つ以上の一致がある。したがって、アクセス制御部20は、アクセス制御ポリシーに基づいて、projectAに関するフォルダhomeuserAproject2011projectAに対する、端末Tbのアクセスを許可する。このようにすることで、新たにプロジェクトに参加した利用者Bは、利用者Aが退職前に残したデータにアクセスできるようになる。以上説明したように、本第3の実施形態によると、アクセス制御ポリシーは、複数種類のデータプロジェクトMLラベルのメールアドレスとプロジェクトラベルフォルダ以下のファイルハッシュに関する類似性共通性で定義されており、アクセス制御部20は、端末Ta、Tbから複数種類のデータを取得し、アクセス制御を行う。このように、複数種類のデータを用いたアクセス制御を行うことで、精度の高いアクセス制御の実現が可能となる。なお、上記第3の実施形態においては、アクセス制御部20が、自動的にメールアドレスやファイルハッシュを取得する場合について説明したが、これに限られるものではない。アクセス制御部20は、端末Tbのユーザインタフェース部193を介して、利用者Bに対してメールアドレスやファイルハッシュの提示を求めるようにしてもよい。この場合、利用者Bは、具体的に何を提示すればよいのかを理解できない場合もあると考えられる。このような場合に備え、アクセス制御部20は、メールアドレスやファイルハッシュの提示を求める場合に、ユーザインタフェース部193例えばディスプレイ上に詳細メッセージを表示するためのボタン等を表示してもよい。そして、アクセス制御部20は、利用者Bによってボタンが押された場合にプロジェクトprojectAに関連するファイルを1つ以上提示することなどとユーザインタフェース部193を介して表示するようにしてもよい。なお、利用者Bは、求められたデータを端末Tb上から選択することとしてもよいが、求められたデータをユーザインタフェース部193を介して新たに入力することとしてもよい。なお、上述したようにアクセス制御部20が自動的にメールアドレスやファイルハッシュを取得する場合であっても、自動取得後に、利用者Bがメールアドレスやファイルハッシュの追加変更等を行えるようにしてもよい。この場合、意図と異なる検証用データがアクセス制御部20により取得された場合でも、当該検証用データの修正ができるので、利用者の利便性を向上することができる。また、これとは逆に、メールアドレスやファイルハッシュの自動取得後における追加変更を一切禁止するようにしてもよい。この場合、利用者本人の利用状況を正確に反映させた検証用データを作成することが可能となる。なお、上記第3の実施形態では、アクセス制御部20が、プロジェクトMLラベルのメールアドレスと、プロジェクトラベルフォルダ以下のファイルハッシュの2種類のデータに基づいてアクセス制御を行う場合について説明した。しかしながら、これに限られるものではなく、上記以外のデータや、3種類以上のデータに基づいて、アクセス制御を行うようにしてもよい。《第4の実施形態》次に、第4の実施形態について、図13に基づいて説明する。本第4の実施形態では、検証条件として検証文を用いずに、各端末が保有するデータそのものをアクセス制御ポリシーに記述する点に特徴を有する。なお、装置構成は、第1の実施形態と同様であるものとする。図13aには、本第4の実施形態で用いるアクセス制御ポリシーの一例が示されている。この図13aは、ある利用者Aが、自分の端末Ta内のアドレス帳の情報更新を山田太郎さんに許可する場合の例である。この場合、更新を許可する対象者が曖昧でなく、特定の人物であるので、特定の人物のみがアクセス可能となるように条件が記述することができる。すなわち、アクセス制御に用いるデータは、図13aのアクセス制御ポリシーに記述されている確認データ山田太郎などとなる。なお、図13aの例では、名前や電話番号などの、山田太郎さんの個人情報を全て知っている入力できる利用者のみが、アドレス帳の情報更新を行うことが可能となる。なお、セキュリティ上の安全を確保するため、図13bに示すように、確認データを符号化してもよい。図13bの例では、符号化後のデータはハッシュ値となっている。なお、確認データを符号化する場合には、使用する確認対象に合わせて符号化するようにしてもよい。例えば、データの一致を確認すればよい場合類似度の確認が不要の場合には、全体のハッシュをとるだけで問題ないが、住所データのように階層構造を持ったデータの場合には、図13cのように階層毎に符号化してもよい。この場合、例えば、神奈川県川崎市と神奈川県が県レベルで同じ情報であることを示すことができる。なお、上記第4の実施形態では、第3の実施形態と同様の装置構成サーバ200がアクセス制御を行う構成を採用してもよい。《第5の実施形態》次に、第5の実施形態について、図14、図15に基づいて説明する。なお、本第5の実施形態の装置構成は、上述した第1の実施形態と同様の装置構成であるものとする。本第5の実施形態は、端末Tbが保有するデータを、端末Taに対して秘匿化して送信する場合の例である。上述した第1の実施形態のように、会員登録している店舗の電話番号リストを店舗の端末に送信するのは利用者にとって然程問題にならない可能性が高い。しかしながら、送信するデータが、例えば、友人の電話番号のリストである場合には、利用者が実データを送信するのに躊躇するおそれがある。このような場合などにおいて、本第5の実施形態を用いることができる。ここでは、端末Taの利用者Aと端末Tbの利用者Bが初めて出会った場合に、利用者Aと利用者Bに共通の知人が多ければ、利用者Bに対して、利用者Aが作成したプロフィールへの参照権限を与える例について説明する。この場合、アクセス制御部20は、利用者A,Bが保有する電話番号ラベルのついたIS検証データ電話番号データを互いに開示することなく比較し、共通する電話番号の個数を知る必要がある。図14は、端末Tb及びTaにおける処理を示すフローチャートである。なお、図14の処理は、基本的には、第1の実施形態図6と同様となっている。図14の処理では、まず、初めて会った利用者A端末Taに対して、利用者B端末Tbがプロフィール情報をリクエストするステップS12。次いで、端末Taのアクセス制御部20が、利用者Aのアクセス制御ポリシーから、検証文:共通の知人が多い、を検証する。この場合、使用するデータは、電話番号ラベルの付いた電話番号データである。また、本第5の実施形態では、秘匿化関数を用いた検証を行うことがアクセス制御ポリシーにおいて定義されているものとする。このため、アクセス制御部20は、ステップS118における端末Tbに対するデータの要求の際には、図15中の手続きA1の実行により生成される秘匿化IS検証用データSaを付加して、検証に必要な電話番号ラベルの付いた電話番号データの要求を送付する。これに対し、利用者B側では、情報管理部42が、秘匿化関数を用いた場合に送付できる範囲で、電話番号ラベルのIS検証データ電話番号データを用いて、図15の手続きBを実行する。そして、情報管理部42は、秘匿化IS検証データSbを利用者Aに返却するステップS18。また、利用者A側では、アクセス制御部20が、端末Tb側から受領した秘匿化IS検証データSbを用いて図15中の手続きA2を実行し、0になった個数を取得するステップS124。ここで、手続きA2の結果、0になった個数は、双方のIS検証データ中で一致していたものの個数を意味する。この場合、アクセス制御部20は、共通の電話番号の個数が多ければ一致割合が所定の閾値よりも多ければ、共通の知人が多いと判断し、利用者Bに対して利用者Aが作成したプロフィールへの参照権限を付与する。以上説明したように、本第5の実施形態では、アクセス制御部20は、図14の処理を行うことで、実質的に、端末Taが保有する電話番号データを秘匿化したデータと、端末Tbが保有する電話番号データを秘匿化したデータとを取得し、その一致割合に基づいて、端末Tbによるアクセス制御を行っているといえる。これにより、本第5の実施形態では、各端末で保有しているデータを他の端末に対して一切明かすことなく、アクセス制御を行うことが可能となる。《第6の実施形態》次に、第6の実施形態について、図16に基づいて説明する。本第6の実施形態の装置構成は、第1の実施形態と同様の装置構成となっている。第6の実施形態は、データをプロフィールや名刺、会員証等テンプレート毎に管理し、かつテンプレート単位で符号化を行うものである。ここで、本第6の実施形態では、前述した第5の実施形態と同様、検証文共通の知人が多いを、プロフィール情報の一致割合に基づいて確認するものとする。ただし、本第6の実施形態では、利用者Aの端末Taと利用者Bの端末Tbが保有する電話番号同士を比較するのではなく、保持しているプロフィール全体の情報を用いた比較を行う。例えば、アクセス制御部20は、端末Taが保有するプロフィールとして、図16aに示すプロフィールを取得し、端末Tbが保有するプロフィールとして、図16bに示すプロフィールを取得したものとする。プロフィールのようにIS検証用データの1つ1つの項目中に更に住所や名前といった詳細データが含まれる場合であっても、各項目の類似度を算出する段階では、上述した各実施形態と同様、項目と項目、つまり、プロフィールとプロフィールの比較を行えばよい。この場合、アクセス制御部20は、図16cに示すような検証結果類似度マトリクスを得ることができる。この図16cの検証結果では、類似度マトリクスの各格子に各プロフィール相互の類似度が入力されている。なお、検証関数が、一致不一致だけを見る場合には、プロフィールを符号化し、符合化後のデータファイルハッシュ値を比較した結果値1又は0を類似度マトリクスの各格子に入力するようにすればよい。なお、アクセス制御部20は、図16cの検証結果から、所定の演算方法を用いてIS一致傾向=x/100を算出し、当該IS一致傾向に基づいて、端末Tbからのアクセスの許可不許可を判断する。なお、IS一致傾向の演算方法としては、例えば、図16cの各格子に入力されている類似度の平均を算出する方法などを採用することができる。以上、説明したように、本第6の実施形態によると、プロフィールなどのデータの集合の類似度に基づいてアクセス制御を行うので、上記各実施形態と同様、ユーザ登録等を行うことなく適切なアクセス制御を行うことが可能となる。《第7の実施形態》次に、第7の実施形態について、図17に基づいて説明する。本第7の実施形態の装置構成は、上記第1の実施形態の装置構成と同様となっている。また、本第7の実施形態は、IS検証データのデータ量を縮退することを目的としている。図17は、本第7の実施形態におけるデータの縮退イメージを示す図である。本実施形態では、情報管理部26、42では、電話番号のデータをアクセス制御部20に対して送信する前に、図17aに示すように符号化する。なお、図17aでは、電話番号のデータをハッシュ化した例Hash、Hash、...が示されている。そして、情報管理部26、42は、ハッシュ化したデータHash、Hash、...それぞれに含まれる文字0,1,2,...e,fの個数をカウントし、それらを並べたものを縮退データL1、L2...とする図17b参照。なお、IS検証データとしては、全ての縮退データから重複のないようにデータを集計する。情報管理部26,42は、図17bのような縮退データをアクセス制御部20に対して送信するものとする。そして、アクセス制御部20では、利用者A端末Ta側で生成されるCa図17c参照と、Caと同様にして利用者B端末Tb側で生成されるCbとの一致不一致を検証する。ここで、利用者A側と利用者B側内の元の電話番号が同じであった場合には、そのハッシュ値及び、Ca、Cb中の対応する縮退データも一致することを意味する。したがって、本第7の実施形態では、アクセス制御部20が、CaとCbとを比較することで、大まかな電話番号の一致個数を検証することができる。以上のように、本第7の実施形態によると、ハッシュ値に含まれる各文字の個数を用いて検証に用いるデータ量を縮退させるので、ハッシュ値そのものを端末間でやり取りする場合よりもデータ量を低減することができる。また、データ量の低減により検証に要する時間を短縮することができる。《第8の実施形態》次に、第8の実施形態について、図18に基づいて説明する。本第8の実施形態では、第2の実施形態と同様に、一度アクセスを許可した端末に対して、リソースを保持する端末から証明書を発行するものとする。すなわち、本第8の実施形態の装置構成は、第2の実施形態の装置構成図9と同様であるものとする。本第8の実施形態では、アクセス制御部20での認証が完了した後、証明書発行部28は証明書CTaとするを発行する。この場合、アクセス制御部20は、証明書CTaを端末Tbのリソースリクエスト部40にそのまま送信するのではなく、証明書CTaを例えば3つの分割証明書DCTa1、DCTa2、DCTa3に変換して送信することとする。この場合の各分割証明書の内容は、単純に証明書CTaのハッシュ値を等分に分けたものでも良い。また、しきい値秘密分散法を用いて、例えばn個の分割証明書のうち、k個を利用者が保持していた場合には、証明書CTaを復元できるようにしてもよい。なお、秘密分散法を用いる場合のデータの例は、図18に示されている。図18に示すように、k-1次の多項式を作ることで、分割符号情報をk個集めて、連立方程式を解くことで、元の証明書を復元することが可能となっている。ここで、秘密分散法を用いた分割符号証明書は、複数の利用者に証明書CTaをばら撒きたいが、人によって使用する分割符号証明書を変えたい場合や、1人の利用者が状況や場所に合わせて使用する分割符合証明書を変えたい場合に用いることができる。ただし、証明書のハッシュ値を等分に分割して分割証明書DCTa1、DCTa2、DCTa3を作成した場合、その一部を提示するのみでは、証明書CTaのハッシュ値から生成された分割証明書を保有していることを完全に証明することはできない。すなわち、単にリソースを要求する利用者Bが提示した分割証明書DCTa1が、証明書CTaのハッシュ値の一部と合致することが証明できるだけである。そのため、アクセス制御部20は、上記のように証明が完全でない場合には、アクセス制御で提示する情報のレベルを下げるような運用を採用してもよい。また、このような運用を採用すれば、分割証明書の提出状況に応じて、端末Tbのユーザインタフェース196上に表示可能なデータを制限できるので、利用者Bは、状況に合わせて分割証明書を使い分けることができる。例えば、利用者Bは、他人と一緒にいる場合には、一部の分割証明書のみを提出して、表示が制限された状態でデータ操作を行い、1人になったら、他の分割証明書を追加提出することで、表示制限を解除するようにしてもよい。以上のように、本第8の実施形態では、分割証明書の少なくとも1つに基づいてアクセス制御を行うので、リソース要求者側端末Tb側から提出される分割証明書の数等に基づいて、種々のアクセス制御を行うことが可能となる。なお、分割証明書は、公開用の分割証明書と、秘密裏に運用するための分割証明書にその役割を割り当てることもできる。例えば、利用者Bの作成した証明書をCTbとし、当該証明書CTbの分割証明書をDCTb1、DCTb2とする。そして、利用者Aのブログデータを閲覧するには、利用者Bであることを証明する必要があるとする。この場合、まず、利用者Bは自分のブログ等において、分割証明書DCTb1を公開鍵のような形で公開する。これに対し、利用者Aの端末Taのアクセス制御ポリシー管理部22は、アクセス制御ポリシーを作成するにあたって、利用者Bの公開している分割証明書DCTb1を取得管理する。そして、利用者B端末Tbが利用者Aのブログデータに対するアクセスを要求した場合には、アクセス制御部20は、分割符合の組を要求する。この場合、利用者Bは、秘密裏に管理されていた分割証明書DCTb2と、分割前の証明書CTb1をアクセス制御部20に対して提示する。アクセス制御部20は、保管していた分割証明書DCTb1と受領した分割証明書DCTb2とで、証明書CTb1が構成できるか否かを判定する。この場合において、証明書CTb1が構成できると判定された場合には、アクセス制御部20は、利用者Bによる、利用者Aのブログデータの閲覧を許可することができる。なお、上述したように、受領した分割証明書の組み合わせによってアクセス制限をかけるために、秘密分散法で、復号=復号=復号DCTa2,DCTa3=CTaである分割証明書を用いる場合、復号した情報,DCTa1,DCTa2、復号した情報,DCTa1,DCTa3、復号した情報,DCTa2,DCTa3の組み合わせ毎に、付与する権限を変えるなどすることができる。この場合、各分割証明書を渡す段階において、どの分割証明書の組で、どのアクセス権限が付与されるのかを注意して配布する必要がある。《第9の実施形態》次に、第9の実施形態について、図19,図20に基づいて説明する。なお、本第9の実施形態の装置構成は、第1の実施形態と同様であるものとする。本第9の実施形態は、検証に用いるデータ、もしくは、認証結果証明書、更にはそれらを分割符号化したものの配布に画像を用いる点に特徴を有している。図19は、本第9の実施形態で用いられる、画像化された証明書の一例を示している。アクセス制御部20は、第2の実施形態や第8の実施形態で説明した証明書、分割証明書のデータを、図19に示すような画像データに加工し、端末Tb側に送信する。ここで、図19の画像データは、証明書の2次元コードと、証明書を発行した人の写真とが関連付けられた状態となっている。このようにすることで、証明書を提示する場合であっても、2次元コード近傍の写真を見れば、どの利用者から得た証明書であったのかが一目瞭然であるので、適切な証明書の提出が可能となる。なお、証明書情報のみならず、単に利用者が保持しているプロフィール情報などの情報を画像化して保持させておいてもよい。この場合、前述した第4の実施形態のような場合において、画像化されたデータを用いて、アクセス制御ポリシーを記述することとしてもよい。また、前述した第6の実施形態のように、プロフィールや名刺毎のハッシュ値を比較検証に用いる場合に、検証に必要なデータとしてプロフィールや名刺のハッシュ値を提供する場合にも、画像化されたデータを用いることができる。図20には、認証時に携帯電話の電話帳情報を画像化してアクセス制御装置に提示するイメージの一例を示している。例えば、認証の際に、図20aのような画面が端末Tbのユーザインタフェース部193上に表示されるとする。そして、利用者Bによって電話帳読み込みボタンが押され、かつ図20bのように電話帳の一部が選択された後に再度電話帳読み込みボタンが押されたとする。この場合、情報管理部42は、選択された電話帳の一部のデータテキストデータに基づいて、図20cに示すような画像を生成する。そして、利用者Bによって認証のボタンが押されると、情報管理部42は、当該画像を端末Taのアクセス制御部20に送信する。この場合、アクセス制御部20では、送信されてきた画像を用いてアクセス制御を行うこととなる。なお、上記各実施形態は、適宜組み合わせることができる。一例として、第3の実施形態のように複数種類のデータを用いてアクセス制御を行うという概念は、その他の実施形態においても適用することができる。なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVDDigitalVersatileDisc、CD-ROMCompactDiscReadOnlyMemoryなどの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。上述した各実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。なお、以上の説明に関して更に以下の付記を開示する。付記1リソースを保持する第1端末から得られる特定の情報とリソースに対するアクセスを要求する第2端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第1端末から特定の情報を取得するとともに、前記第2端末から特定の情報を取得し、前記アクセス制御条件に基づいて、前記第1端末から特定の情報を取得するとともに、前記第2端末から特定の情報を取得し、前記第1、第2端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断する、処理をコンピュータに実行させることを特徴とするアクセス制御プログラム。付記2前記判断する処理における判断結果に基づいて、前記第2端末のアクセス制御を行う処理を前記コンピュータに更に実行させることを特徴とする付記1に記載のアクセス制御プログラム。付記3前記判断する処理において前記第2端末からの前記リソースに対するアクセスが可能と判断した場合に、前記第2端末に対して証明書を発行する処理を、前記コンピュータに更に実行させ、前記判断する処理では、前記第2端末から前記証明書が提示された場合にも、前記第2端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記1又は2に記載のアクセス制御プログラム。付記4前記証明書を発行する処理では、証明書を分割して発行し、前記判断する処理では、前記分割された証明書の少なくとも一部が提示された場合に、前記第2端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記3に記載のアクセス制御プログラム。付記5前記アクセス制御条件は、複数種類の特定の情報に関する類似性で定義され、前記取得する処理では、前記第1、第2端末から前記複数種類の特定の情報を取得することを特徴とする付記1~4のいずれかに記載のアクセス制御プログラム。付記6前記取得する処理では、前記第1端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第2端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、前記判断する処理では、前記第1端末及び前記第2端末から取得した各符号化した情報の一致不一致に基づいて、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記1~5のいずれかに記載のアクセス制御プログラム。付記7前記取得する処理では、前記第1端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第2端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、前記判断する処理では、前記第1端末及び前記第2端末から取得した各文字の個数の一致不一致に基づいて、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記1~5のいずれかに記載のアクセス制御プログラム。付記8前記アクセス制御条件は、前記第1端末から得られる特定の情報の集合と前記第2端末から得られる特定の情報の集合との類似性で定義され、前記取得する処理では、前記第1、第2端末から特定の情報の集合を取得し、前記判断する処理では、前記第1、第2端末から取得した各情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする付記1~7のいずれかに記載のアクセス制御プログラム。付記9リソースを保持する第1端末から得られる特定の情報とリソースに対するアクセスを要求する第2端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件に基づいて、前記第1端末から特定の情報を取得するとともに、前記第2端末から特定の情報を取得する取得工程と、前記第1、第2端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断する判断工程と、をコンピュータが実行することを特徴とするアクセス制御方法。付記10前記判断工程における判断結果に基づいて、前記第2端末のアクセス制御を行うアクセス制御工程を前記コンピュータが更に実行することを特徴とする付記9に記載のアクセス制御方法。付記11前記判断工程において前記第2端末からの前記リソースに対するアクセスが可能と判断された場合に、前記第2端末に対して証明書を発行する証明書発行工程を、前記コンピュータが更に実行し、前記判断工程では、前記第2端末から前記証明書が提示された場合にも、前記第2端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記9又は10に記載のアクセス制御方法。付記12前記証明書発行工程では、証明書を分割して発行し、前記判断工程では、前記分割された証明書の少なくとも一部が提示された場合に、前記第2端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記11に記載のアクセス制御方法。付記13前記アクセス制御条件は、複数種類の特定の情報に関する類似性で定義され、前記取得工程では、前記第1、第2端末から前記複数種類の特定の情報を取得することを特徴とする付記9~13のいずれかに記載のアクセス制御方法。付記14前記取得工程では、前記第1端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第2端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、前記判断工程では、前記第1端末及び前記第2端末から取得した各符号化した情報の一致不一致に基づいて、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記9~13のいずれかに記載のアクセス制御方法。付記15前記取得工程では、前記第1端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第2端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、前記判断工程では、前記第1端末及び前記第2端末から取得した各文字の個数の一致不一致に基づいて、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記9~13のいずれかに記載のアクセス制御方法。付記16前記アクセス制御条件は、前記第1端末から得られる特定の情報の集合と前記第2端末から得られる特定の情報の集合との類似性で定義され、前記取得工程では、前記第1、第2端末から特定の情報の集合を取得し、前記判断工程では、前記第1、第2端末から取得した各情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする付記9~15のいずれかに記載のアクセス制御方法。付記17リソースを保持する第1端末から得られる特定の情報とリソースに対するアクセスを要求する第2端末から得られる特定の情報との類似性で定義される、前記リソースに対するアクセス制御条件を管理する管理部と、前記アクセス制御条件に基づいて、前記第1端末から特定の情報を取得するとともに、前記第2端末から特定の情報を取得する取得部と、前記取得部が前記第1、第2端末から取得した各情報の類似性が前記アクセス制御条件を満たすか否かを検証することで、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断する判断部と、を備えるアクセス制御装置。付記18前記判断部による判断結果に基づいて、前記第2端末のアクセス制御を行う制御部を更に備える付記17に記載のアクセス制御装置。付記19前記判断部が前記第2端末からの前記リソースに対するアクセスが可能と判断した場合に、前記第2端末に対して証明書を発行する証明書発行部を更に備え、前記判断部は、前記第2端末から前記証明書が提示された場合にも、前記第2端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記17又は18に記載のアクセス制御装置。付記20前記証明書発行部は、証明書を分割して発行し、前記判断部は、前記分割された証明書の少なくとも一部が提示された場合に、前記第2端末からの前記リソースに対するアクセスが可能であると判断することを特徴とする付記19に記載のアクセス制御装置。付記21前記管理部は、複数種類の特定の情報に関する類似性で定義された前記アクセス制御条件を管理し、前記取得部は、前記第1、第2端末から前記複数種類の特定の情報を取得することを特徴とする付記17~20のいずれかに記載のアクセス制御装置。付記22前記取得部は、前記第1端末から得られる特定の情報を所定の符号化方法で符号化した情報を取得するとともに、前記第2端末から得られる特定の情報を前記所定の符号化方法で符号化した情報を取得し、前記判断部は、前記第1端末及び前記第2端末から取得した各符号化した情報の一致不一致に基づいて、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記17~21のいずれかに記載のアクセス制御装置。付記23前記取得部は、前記第1端末から得られる特定の情報を所定の符号化方法で符号化した情報に含まれる各文字の個数を取得するとともに、前記第2端末から得られる特定の情報を前記所定の符号化方法で符号化した情報に含まれる各文字の個数を取得し、前記判断部は、前記第1端末及び前記第2端末から取得した各文字の個数の一致不一致に基づいて、前記第2端末からの前記リソースに対するアクセスが可能か否かを判断することを特徴とする付記17~21のいずれかに記載のアクセス制御装置。付記24前記管理部は、前記第1端末から得られる特定の情報の集合と前記第2端末から得られる特定の情報の集合との類似性で定義された前記アクセス制御条件を管理し、前記取得部は、前記第1、第2端末から特定の情報の集合を取得し、前記判断部は、前記取得部が前記第1、第2端末から取得した各情報の集合の類似性が前記アクセス制御条件を満たすか否かを検証することを特徴とする付記17~23のいずれかに記載のアクセス制御装置。"