(57)【要約】      （修正有）【課題】オンラインで管理される情報を種々の状況に応じて活用する判定装置、判定方法及び判定プログラムを提供する。【解決手段】判定装置は、第１取得部と、第２取得部と、判定部とを備える。第１取得部は、第１端末を利用するユーザである第１ユーザが提供を受けようとするサービスに関する権限情報、及び、第１端末に関する利用状況を取得する。第２取得部は、権限情報の委譲を許可するための条件であって、第１ユーザと権限情報が委譲される委譲先との関係性を示した条件を取得する。判定部は、第１取得部によって取得された利用状況に基づいて、第１ユーザと、第１ユーザが権限情報を委譲しようとするユーザである第２ユーザとの関係性が条件を満たすか否かを判定する。【選択図】図４
2019057011.tif 000002
【特許請求の範囲】
【請求項１】
第１端末を利用するユーザである第１ユーザが提供を受けようとするサービスに関する権限情報、及び、当該第１端末に関する利用状況を取得する第１取得部と、
前記権限情報の委譲を許可するための条件であって、前記第１ユーザと前記権限情報が委譲される委譲先との関係性を示した条件を取得する第２取得部と、
前記第１取得部によって取得された利用状況に基づいて、前記第１ユーザと、当該第１ユーザが権限情報を委譲しようとするユーザである第２ユーザとの関係性が前記条件を満たすか否かを判定する判定部と、
を備えることを特徴とする判定装置。
【請求項２】
前記第１取得部によって取得された利用状況に基づいて、前記第２ユーザの候補となりうるユーザである候補ユーザが抽出されたリストであって、当該候補ユーザとして抽出される根拠を示す情報が含まれるリストを生成する生成部、
をさらに備え、
前記判定部は、
前記第２取得部によって取得された条件と、前記生成部によって生成されたリストが含む情報とを照合することにより、前記候補ユーザのうち前記第２ユーザとしての条件を満たす候補ユーザを判定する、
ことを特徴とする請求項１に記載の判定装置。
【請求項３】
前記第２取得部は、
前記第１端末と、前記第２ユーザが利用する第２端末とが所定時間以上近接した履歴があることを前記条件として取得し、
前記判定部は、
前記リストにおいて、前記第１端末と、前記候補ユーザが利用する端末とが所定時間以上近接した履歴を含むことを根拠として前記第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが前記条件を満たすと判定する、
ことを特徴とする請求項２に記載の判定装置。
【請求項４】
前記生成部は、
前記利用状況として、前記第１端末と前記候補ユーザが利用する端末とが近距離無線通信もしくは有線通信を行った履歴、又は、当該第１端末と当該候補ユーザが利用する端末とが同じアクセスポイントを利用した履歴に基づいて前記リストを生成し、
前記判定部は、
前記リストにおいて、前記第１端末と前記候補ユーザが利用する端末とが近距離無線通信もしくは有線通信を行った履歴、又は、当該第１端末と当該候補ユーザが利用する端末とが同じアクセスポイントを利用した履歴を含むことを根拠として前記第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが前記条件を満たすと判定する、
ことを特徴とする請求項３に記載の判定装置。
【請求項５】
前記第２取得部は、
前記第１ユーザと前記第２ユーザとが所定回数以上、同一又は類似する行動を行ったことを示す行動履歴があることを前記条件として取得し、
前記判定部は、
前記リストにおいて、前記第１ユーザと前記候補ユーザとが所定回数以上、同一又は類似する行動を行ったことを示す行動履歴を含むことを根拠として当該第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが前記条件を満たすと判定する、
ことを特徴とする請求項２〜４のいずれか一つに記載の判定装置。
【請求項６】
前記生成部は、
前記利用状況として、前記第１ユーザが所定サービスを利用した履歴と、当該第１ユーザが当該所定サービスを利用した所定時間内に前記候補ユーザが当該所定サービスを利用した履歴とに基づいて前記リストを生成し、
前記判定部は、
前記リストにおいて、前記第１ユーザが所定サービスを利用した履歴と、当該第１ユーザが当該所定サービスを利用した所定時間内に前記候補ユーザが当該所定サービスを利用した履歴とを含むことを根拠として当該第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが前記条件を満たすと判定する、
ことを特徴とする請求項５に記載の判定装置。
【請求項７】
前記第２取得部は、
前記第１ユーザが利用するＳＮＳ（Social  Networking  Service）において前記第２ユーザとのつながりを有することを示す履歴が含まれることを前記条件として取得し、
前記判定部は、
前記リストにおいて、前記第１ユーザが利用するＳＮＳにおいて前記候補ユーザとつながりを有することを示す履歴が含まれることを根拠として当該第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが前記条件を満たすと判定する、
ことを特徴とする請求項２〜６のいずれか一つに記載の判定装置。
【請求項８】
前記第２取得部は、
前記第１ユーザが利用する画像共有サービスにおいて前記第２ユーザが撮像された画像を共有していることを示す履歴が含まれることを前記条件として取得し、
前記判定部は、
前記リストにおいて、前記第１ユーザが利用する画像共有サービスにおいて前記候補ユーザが撮像された画像を共有していることを示す履歴が含まれることを根拠として当該第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが前記条件を満たすと判定する、
ことを特徴とする請求項２〜７のいずれか一つに記載の判定装置。
【請求項９】
前記第２取得部は、
前記第１ユーザが利用するネットワーク上のカレンダーサービスにおいて前記第２ユーザと同じ予定を共有することを示す履歴が含まれることを前記条件として取得し、
前記判定部は、
前記リストにおいて、前記第１ユーザが利用するネットワーク上のカレンダーサービスにおいて前記候補ユーザと同じ予定を共有することを示す履歴が含まれることを根拠として当該第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが前記条件を満たすと判定する、
ことを特徴とする請求項２〜８のいずれか一つに記載の判定装置。
【請求項１０】
前記第２取得部は、
前記第１ユーザと前記第２ユーザとが所定時間以上、同行した履歴があることを前記条件として取得し、
前記判定部は、
前記リストにおいて、前記第１ユーザと前記候補ユーザとが所定時間以上、歩行動作において共起した履歴が含まれることを根拠として当該第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが前記条件を満たすと判定する、
ことを特徴とする請求項２〜９のいずれか一つに記載の判定装置。
【請求項１１】
前記第２取得部は、
サービス提供側によって前記第１ユーザが前記権限情報を有する本人であることが確認された旨を示す情報を取得し、
前記判定部は、
前記第２取得部によって前記第１ユーザが前記権限情報を有する本人であることが確認された旨を示す情報が取得されたことを契機として、当該第１ユーザと前記第２ユーザとの関係性が前記条件を満たすか否かを判定する、
ことを特徴とする請求項１〜１０のいずれか一つに記載の判定装置。
【請求項１２】
前記判定部は、
前記第１ユーザと前記第２ユーザとの関係性が前記条件を満たすか否かを判定する場合に、サービス提供側によって当該第１ユーザが前記権限情報を有する本人であることが確認されているか否かを判定し、確認されていない場合には、当該第１ユーザが当該権限情報を有する本人であることが当該サービス提供側によって確認された旨を示す情報の提示を当該サービス提供側に要求する、
ことを特徴とする請求項１〜１０のいずれか一つに記載の判定装置。
【請求項１３】
コンピュータが実行する判定方法であって、
第１端末を利用するユーザである第１ユーザが提供を受けようとするサービスに関する権限情報、及び、当該第１端末に関する利用状況を取得する第１取得工程と、
前記権限情報の委譲を許可するための条件であって、前記第１ユーザと前記権限情報が委譲される委譲先との関係性を示した条件を取得する第２取得工程と、
前記第１取得工程によって取得された利用状況に基づいて、前記第１ユーザと、当該第１ユーザが権限情報を委譲しようとするユーザである第２ユーザとの関係性が前記条件を満たすか否かを判定する判定工程と、
を含んだことを特徴とする判定方法。
【請求項１４】
第１端末を利用するユーザである第１ユーザが提供を受けようとするサービスに関する権限情報、及び、当該第１端末に関する利用状況を取得する第１取得手順と、
前記権限情報の委譲を許可するための条件であって、前記第１ユーザと前記権限情報が委譲される委譲先との関係性を示した条件を取得する第２取得手順と、
前記第１取得手順によって取得された利用状況に基づいて、前記第１ユーザと、当該第１ユーザが権限情報を委譲しようとするユーザである第２ユーザとの関係性が前記条件を満たすか否かを判定する判定手順と、
をコンピュータに実行させることを特徴とする判定プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、判定装置、判定方法及び判定プログラムに関する。
【背景技術】
【０００２】
近年、通信ネットワークの普及が進み、通信ネットワークを介したサービスが盛んに提供されている。さらに、オンラインで管理される情報をオフライン（実世界）のサービスにつなげるようなサービスも展開されている。例えば、予めオンライン上でサービスを受けるためのチケットを発行しておき、その後、ユーザの端末装置上に表示されるオンラインチケットを確認することで実世界のコンサート会場への入場を管理する、といったようなサービスが展開されている。
【０００３】
このようなサービスに関連する技術として、サービス側における権限情報とユーザの生体情報等の認証情報とを照らし合わせることで本人確認情報を生成し、生成した本人確認情報を活用してサービスを提供するための技術が提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第６１３４３７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、オンラインで管理される情報をオフラインで活用する技術については、改善の余地がある。例えば、上記の従来技術では、サービスを利用する本人の権限情報を予めサービス側で管理することが前提となる。このため、例えば、チケットを購入したユーザ本人以外の同行者など、サービス側で権限情報が適切に管理されていないユーザ（例えば、ユーザ本人がチケットを購入してないために、購入者が本人であるか否かを確認するための本人確認情報等がサービス側で管理されていないユーザ）に対しては、上記の従来技術を適用することが難しい場合がある。
【０００６】
本願は、上記に鑑みてなされたものであって、オンラインで管理される情報を種々の状況に応じて活用することができる判定装置、判定方法及び判定プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願に係る判定装置は、第１端末を利用するユーザである第１ユーザが提供を受けようとするサービスに関する権限情報、及び、当該第１端末に関する利用状況を取得する第１取得部と、前記権限情報の委譲を許可するための条件であって、前記第１ユーザと前記権限情報が委譲される委譲先との関係性を示した条件を取得する第２取得部と、前記第１取得部によって取得された利用状況に基づいて、前記第１ユーザと、当該第１ユーザが権限情報を委譲しようとするユーザである第２ユーザとの関係性が前記条件を満たすか否かを判定する判定部と、を備えることを特徴とする。
【発明の効果】
【０００８】
実施形態の一態様によれば、オンラインで管理される情報を種々の状況に応じて活用することができるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施形態に係る判定処理の一例を示す図（１）である。
【図２】図２は、実施形態に係る判定処理の一例を示す図（２）である。
【図３】図３は、実施形態に係る判定システムの構成例を示す図である。
【図４】図４は、実施形態に係る判定装置の構成例を示す図である。
【図５】図５は、実施形態に係る利用状況記憶部の一例を示す図である。
【図６】図６は、実施形態に係る通信先記憶部の一例を示す図である。
【図７】図７は、実施形態に係るトラストリスト記憶部の一例を示す図である。
【図８】図８は、実施形態に係るユーザ端末の構成例を示す図である。
【図９】図９は、実施形態に係るサービスサーバの構成例を示す図である。
【図１０】図１０は、実施形態に係るサービス情報記憶部の一例を示す図である。
【図１１】図１１は、実施形態に係るトラストポリシー記憶部の一例を示す図である。
【図１２】図１２は、実施形態に係る処理手順を示すフローチャート（１）である。
【図１３】図１３は、実施形態に係る処理手順を示すフローチャート（２）である。
【図１４】図１４は、判定装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。
【発明を実施するための形態】
【００１０】
以下に、本願に係る判定装置、判定方法及び判定プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る判定装置、判定方法及び判定プログラムが限定されるものではない。また、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。
【００１１】
〔１．判定処理の一例〕
まず、図１及び図２を用いて、実施形態に係る判定処理の一例について説明する。図１は、実施形態に係る判定処理の一例を示す図（１）である。図１では、本願に係る判定装置１００によって、所定のサービスの提供を受けるための権限を有するユーザ（以下、「第１ユーザ」と表記する場合がある）と、権限を委譲されるユーザ（以下、「第２ユーザ」と表記する場合がある）との関係性が所定の条件を満たすか否かを判定する処理が行われる一例を示す。
【００１２】
図１に示す判定装置１００は、実施形態に係る判定処理を実行するサーバ装置である。また、図１に示すサービスサーバ５０は、サービス提供者によって管理されるサーバ装置であり、サービスの提供に関する処理を行う。
【００１３】
実施形態では、サービス提供者が提供するサービスとして、劇場やコンサート施設等（以下、「会場」と総称する）で開催されるコンサートを例に挙げる。また、実施形態では、第１ユーザが有する権限として、コンサートに参加する権利（かかる権利は、例えば会場に入場する権利を示すオンラインチケット等によって具現化される）を例に挙げて説明する。すなわち、図１の例では、チケットを購入したユーザ（購入者）であるユーザＵ０１がサービスに関する権限を有しており、第１ユーザに該当する。また、ユーザＵ０１に同行して会場を訪れるユーザ（同行者）であるユーザＵ０２は、ユーザＵ０１が購入したチケットを譲り受けて会場に入場することになるため、第２ユーザに該当する。
【００１４】
図１に示す購入者端末２０は、第１ユーザの一例であるユーザＵ０１によって利用される情報処理端末である。また、図１に示す同行者端末３０は、第２ユーザの一例であるユーザＵ０２によって利用される情報処理端末である。購入者端末２０及び同行者端末３０は、例えば、スマートフォン等である。なお、本明細書では、購入者端末２０や同行者端末３０等のユーザによって利用される情報処理端末であって、購入者端末２０や同行者端末３０等を区別する必要のない場合には、これらの装置を「ユーザ端末１０」と総称する。また、ユーザＵ０１やユーザＵ０２等を区別する必要のない場合には、「ユーザ」と総称する。また、以下では、ユーザをユーザ端末１０等と読み替える場合がある。例えば、「ユーザＵ０１が情報を送信する」という記載は、実際には、「ユーザＵ０１が利用する購入者端末２０（ユーザ端末１０の一例）が情報を送信する」という状況を示す場合がある。また、以下の説明では、第１ユーザ（購入者）が利用するユーザ端末１０（図１の例では購入者端末２０）を「第１端末」と表記し、第２ユーザ（同行者）が利用するユーザ端末１０（図１の例では同行者端末３０）を「第２端末」と表記する場合がある。
【００１５】
また、図１に示すサービスサーバ５０は、サービスに関する権限情報を発行したり、発行した権限情報を有するユーザの本人性を確認する処理を行ったりする。具体的には、サービスサーバ５０は、オンラインチケットの販売及び発行に関する処理を行うとともに、オンラインチケットを配布したユーザから、ユーザの本人性を確認するための認証情報を取得する。認証情報は、例えば、ユーザが設定するパスワードや、ユーザの顔を撮像した顔画像データや、ユーザの指紋データ等である。サービス提供者は、実際にサービスが提供される会場において、ユーザから認証情報の提示を受け、予めサービスサーバ５０に保持されていた認証情報との照合を行う。すなわち、サービス提供者は、会場を訪れたユーザが真にチケットを購入したユーザであるか否かを判定する。これにより、サービス提供者は、偽造チケットによる入場や、不当な転売によってチケットを入手したユーザの入場を防止することができる。
【００１６】
上記のように、サービス提供者は、チケットの購入者本人については事前に認証情報を取得することが可能であるため、ユーザの本人性を確認することができる。しかしながら、一般に、購入者は、コンサート等のチケットを複数枚購入し、同行者とともに会場を訪れることが多い。この場合、サービス提供者は、購入者の本人確認を行うことはできるものの、同行者について、その同行者が信頼に値するユーザであるか否かを判定することが難しい。例えば、同行者は、購入者がチケットを不当に高額で転売した相手である可能性がある。この場合、サービス提供者は、購入者の本人確認を行ったとしても、サービスにおける不当な転売を防止することができない。しかし、チケットの販売は、実際にサービスが提供される数か月前から行われることが多く、その時点で購入者に全ての同行者の情報を提示させることは、購入者にとって負担が大きくなる。また、同行者の情報を後から変更可能とすると、やはり、同行者の信頼性に欠けることとなる。
【００１７】
そこで、実施形態に係る判定装置１００は、以下に説明する手法を用いることで、同行者に関する事前の登録処理を必要とせずに、同行者の信頼性（トラスト）を判定する。具体的には、判定装置１００は、事前に第１端末に関する利用状況を取得するとともに、サービス提供者が規定する、権限情報を委譲するための条件を取得する。そして、判定装置１００は、第１端末の利用状況に基づいて、第１ユーザと第２ユーザとの関係性が条件を満たすか否かを判定する。例えば、判定装置１００は、第１端末の利用状況に基づいて、第１ユーザと第２ユーザが実際に会場を訪れる前から知り合いであるか否かを判定する。そして、判定装置１００は、第１ユーザと第２ユーザが会場を訪れる所定期間前（例えば、１ヶ月前）から知り合いであれば、当該第２ユーザは、転売されたチケットを得て会場に入場しようとするユーザである可能性が極めて低いと判定する。そして、判定装置１００は、サービスサーバ５０が発行したオンラインチケットの委譲を許可する判定を行い、第１ユーザが有する権限情報を第２ユーザに委譲させる。これにより、同行者である第２ユーザは、第１ユーザから委譲されたチケットを会場で提示して、サービスの提供を受けることができる。以下、図１を用いて、実施形態に係る判定処理の流れについて説明する。
【００１８】
図１の例において、ユーザＵ０１（購入者）やユーザＵ０２（同行者）は、それぞれ購入者端末２０や同行者端末３０を所持しており、また、日常生活において様々な場所に同行するなどの行動をとっているものとする。このような日常の行動において、購入者端末２０は、同行者端末３０と定期的に通信を行う（ステップＳ０１）。例えば、購入者端末２０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の近距離無線通信によって同行者端末３０を検知したり、ときにはペアリング等の処理を行ったりする。具体的には、購入者端末２０は、近距離無線通信で検知された周囲の機器（この例では同行者端末３０）の識別情報を認識し、認識した識別情報を記憶する。より具体的には、購入者端末２０は、どのような場所で、どのような機器を、どのくらいの回数だけ検知したりペアリングしたりしたか、といった利用状況を取得し、記憶する。なお、識別情報は、例えば、機器固有の製造番号や、ＭＡＣアドレス（Media  Access  Control  address）等でよい。
【００１９】
上記のような購入者端末２０の利用状況の取得処理は、例えば、購入者端末２０にインストールされるプログラムの一例である専用アプリケーション（以下、単に「アプリ」と表記する）によって実現されてもよい。なお、かかるアプリは、例えば判定装置１００やサービスサーバ５０から提供されてもよい。
【００２０】
上記のように、購入者端末２０は、ユーザＵ０１の日常生活において、定期的に端末の利用状況（すなわち、購入者端末２０におけるコンテキスト）を記憶する（ステップＳ０２）。例えば、購入者端末２０は、機器を検知したタイミングや、所定時間（例えば５分）ごとのタイミングで、端末の利用状況を取得し、取得した利用状況を記憶する。また、購入者端末２０は、自装置に利用状況を記憶するとともに、利用状況を判定装置１００に送信する（ステップＳ０３）。例えば、購入者端末２０は、上述のアプリの機能に従い、定期的に判定装置１００に利用状況を送信する。なお、判定装置１００は、利用状況の取得リクエストを購入者端末２０に送信し、リクエストに応答した購入者端末２０から利用状況を取得するようにしてもよい。
【００２１】
判定装置１００は、取得した利用状況に基づいて、ユーザＵ０１に関するトラストリストＬ０１を生成する（ステップＳ０４）。実施形態において、トラストリストとは、ユーザＵ０１にとって信頼に値するユーザが記載されるリストである。具体的には、トラストリストＬ０１には、購入者端末２０の利用状況に基づいて抽出された、ユーザＵ０１と関係性を有する複数のユーザが含まれる。なお、本明細書では、トラストリストＬ０１にはユーザＵ０１にとって信頼に値するユーザが含まれるとして説明するが、実際には、トラストリストＬ０１に含まれる情報は、ユーザＵ０１にとって信頼に値するユーザが所持する機器（デバイス）を識別する識別情報である。ただし、判定装置１００は、各機器の識別情報とユーザとを対応付ける情報を保持していれば、トラストリストＬ０１にユーザそのものを特定する情報を含ませることが可能である。
【００２２】
判定装置１００は、種々の判定基準（抽出基準）に応じて、トラストリストＬ０１に含まれるユーザを判定してもよい。例えば、判定装置１００は、所定期間（例えば、直近３０日）において、ユーザＵ０１（すなわち購入者端末２０）と所定時間以上、近接していたユーザをトラストリストＬ０１に含めてもよい。具体的には、判定装置１００は、所定期間において、所定回数を超えて、購入者端末２０からＢｌｕｅｔｏｏｔｈの機能によって検知された機器を所有するユーザをトラストリストＬ０１に含める。
【００２３】
また、判定装置１００は、ユーザＵ０１と同じ行動をとったと推定される行動をとったユーザをトラストリストＬ０１に含めてもよい。例えば、購入者端末２０は、ユーザＵ０１が、所定の店舗において購入者端末２０をかざして決済（例えば、ＮＦＣ（Near  Field  Communication）規格を利用した電子マネー決済など）を行ったという利用状況を取得する。また、購入者端末２０は、同じ店舗で所定の時間内（例えば１０分以内）に、ユーザＵ０２が同行者端末３０をかざして決済を行った情報をあわせて取得する。この場合、購入者端末２０は、同行者端末３０とのペアリングを行うことにより、同行者端末３０からかかる決済情報を取得してもよい。そして、判定装置１００は、例えば、ユーザＵ０１及びユーザＵ０２の二者が同じ店舗において所定の時間内に決済を行ったという利用状況が所定回数を超えて観測される場合に、ユーザＵ０２をトラストリストＬ０１に含める処理を行う。
【００２４】
このようにして、判定装置１００は、ユーザＵ０１にとって信頼のあるユーザを含むトラストリストＬ０１を生成する。なお、トラストリストＬ０１には、信頼のあるユーザとともに、当該ユーザを信頼のあるユーザと判定した根拠となる情報も含まれる。根拠となる情報とは、例えば、ユーザＵ０１との近接した回数や、同じ店舗で同じ行動をとったこと等、信頼性を判定するために用いられた利用状況の種別である。
【００２５】
上記のトラストリストの生成処理は、例えば、ユーザＵ０１がアプリを使用し続けることにより、継続的に行われるものとする。その後、ユーザＵ０１は、任意のタイミングで、サービス提供者が提供するサービスの権利を購入する処理を行うものとする。例えば、サービスがコンサート等である場合、ユーザＵ０１は、上述したアプリを介して、チケットの購入を行う。また、ユーザＵ０１は、チケットの購入に際して、本人の認証情報の提示が義務付けられている場合、認証情報を送信する。すなわち、ユーザＵ０１は、チケットの購入要求及び認証情報をサービスサーバ５０に送信する（ステップＳ０５）。
【００２６】
サービスサーバ５０は、ユーザＵ０１からの要求に応答して、要求されたチケットを発行するとともに、購入者であるユーザＵ０１の認証情報を記憶する（ステップＳ０６）。例えば、サービスサーバ５０は、ユーザＵ０１が設定したパスワードや、ユーザＵ０１の顔画像データ等を認証情報として取得し、ユーザＵ０１の購入情報と対応付けて記憶する。また、サービスサーバ５０は、ユーザＵ０１が購入したチケット分の権限情報を生成する。例えば、ユーザＵ０１が「２枚」のチケットを要求した場合、サービスサーバ５０は、ユーザＵ０１が「２枚」のチケット分の権限を有することを示す権限情報を生成する。
【００２７】
そして、サービスサーバ５０は、ネットワークを介して、購入枚数分のチケットを購入者端末２０に送信する（ステップＳ０７）。これにより、ユーザＵ０１は、サービスサーバ５０が提供するサービスに係る権利（権限）として、２枚分のオンラインチケットを取得することができる。なお、ユーザＵ０１が購入したオンラインチケットのような権限情報の管理は、購入者端末２０にインストールされたアプリによって行われてもよい。
【００２８】
続いて、図２を用いて、実際にサービスが提供される段階において、判定装置１００が行う判定処理について説明する。図２は、実施形態に係る判定処理の一例を示す図（２）である。図２は、ユーザＵ０１がチケットを購入してから所定期間が経過し、実際にサービスが提供されるタイミングになった状況を示す。なお、判定装置１００は、ユーザＵ０１がチケットを購入してから、実際にチケットを使用するまでの間も、ユーザＵ０１（購入者端末２０）の利用状況を取得し続けるものとする。
【００２９】
図２に示すように、同行者であるユーザＵ０２とともに会場を訪れたユーザＵ０１は、自身が購入していたオンラインチケットをサービス提供者に提示する（ステップＳ１１）。サービス提供者は、ユーザＵ０１に対して、真にユーザＵ０１が購入者であるかを認証するための認証情報の提示を要求する（ステップＳ１２）。ユーザＵ０１は、要求に応答して、認証情報を提示する（ステップＳ１３）。例えば、ユーザＵ０１は、自身が設定したパスワードを提示したり、サービス提供者が用意する顔認識システムを用いて自身の顔画像データを提示したりする。
【００３０】
サービス提供者は、ユーザＵ０１から提示された認証情報と、事前にサービスサーバ５０に記憶されていたユーザＵ０１の認証情報とを照合する。照合された場合、サービス提供者は、ユーザＵ０１（購入者）の本人性を確認する（ステップＳ１４）。すなわち、サービス提供者は、ユーザＵ０１が有する権限情報が正当なものであると判定する。
【００３１】
続いて、サービス提供者は、同行者であるユーザＵ０２の信頼性を確認する処理を行う。具体的には、サービス提供者は、ユーザＵ０１に対して、同行者の信頼性判定を要求する（ステップＳ１５）。すなわち、サービス提供者は、ユーザＵ０１が同行させたユーザＵ０２が、会場においてユーザＵ０１から転売チケットを購入したユーザなど、ユーザＵ０１と実際には何らつながりのないユーザではなく、信頼に値するユーザであることを証明させるための処理を要求する。
【００３２】
ここで、ユーザＵ０１は、例えば購入者端末２０のアプリを起動させ、同行者の信頼性判定を要求する（ステップＳ１６）。例えば、ユーザＵ０１は、購入者端末２０と同行者端末３０との通信を確立させ、同行者端末３０の識別情報を取得する。そして、購入者端末２０は、取得した同行者端末３０の識別情報を判定装置１００に送信し、かかる識別情報で識別される機器を所有するユーザＵ０２が信頼に値するユーザであるか否かを判定させる。具体的には、購入者端末２０は、事前に生成されたトラストリストＬ０１において、同行者端末３０の識別情報が含まれるか否かを問い合わせる。
【００３３】
このとき、判定装置１００は、購入者端末２０から判定の要求を受け付けるとともに、サービスサーバ５０から、サービス側のトラストポリシー（条件）を取得する（ステップＳ１７）。例えば、判定装置１００は、購入者端末２０から判定の要求を受け付けた場合に、判定に関するサービスを特定し、特定したサービスを提供するサービスサーバ５０に対して、トラストポリシーの送信を要求する。サービスサーバ５０は、要求に応答して、サービスに関するトラストポリシーを判定装置１００に送信する。
【００３４】
これは、判定装置１００が生成したトラストリストＬ０１にユーザＵ０２が含まれていたとしても、最終的に、サービス側がそのトラストリストＬ０１を信頼するか否かは、サービス側が設定するトラストポリシーによって判定されることによる。例えば、サービス側は、ユーザＵ０１とユーザＵ０２とが近接したことを示す利用状況が過去に一度あったことのみを信頼の根拠とすることを認めず、例えば、過去３０日より前にユーザＵ０１とユーザＵ０２とが近接したことを示す利用状況が少なくとも３回あること等を条件として有していてもよい。すなわち、サービス側が有する条件とは、購入者と、購入者が同行させる（言い換えれば、購入者が有する権限情報を譲り受けてサービスを受けようとする）同行者との関係性を規定するものである。このようなサービス側が提示する条件は、サービス側によって任意に設定可能である。
【００３５】
判定装置１００は、サービスサーバ５０から取得した条件と、トラストリストＬ０１に含まれる情報とを照合する（ステップＳ１８）。具体的には、判定装置１００は、サービス側が提示する条件である「過去３０日より前にユーザＵ０１とユーザＵ０２とが近接したことを示す利用状況が少なくとも３回あること」を、トラストリストＬ０１に含まれる情報が満たすか否かを判定する。図２の例では、トラストリストＬ０１には、上記の条件を満たすような、ユーザＵ０２との利用状況が保持されているものとする。この場合、判定装置１００は、同行者であるユーザＵ０２が、サービス側の条件を満たすと判定する（ステップＳ１９）。
【００３６】
判定装置１００は、ユーザＵ０１の同行者が信頼に値するユーザであると判定した場合、ユーザＵ０１が有する権限情報を同行者に委譲することを許可する。具体的には、判定装置１００は、ユーザＵ０１がユーザＵ０２にチケットを委譲することを許可する旨を購入者端末２０に通知する（ステップＳ２０）。
【００３７】
かかる通知を受信したユーザＵ０１は、購入者端末２０のアプリを介して、ユーザＵ０２へのチケットの委譲を行う（ステップＳ２１）。例えば、購入者端末２０のアプリは、アプリ内に格納されている権限情報を委譲することができないようなロック機能を有しており、許可通知を受信した場合に限り、許可通知に含まれるユーザに対してロック機能が解除されるものとする。そして、購入者端末２０と同行者端末３０は、ロック機能が解除された場合に、当該アプリにおけるペアリングが許可され、権限情報の委譲が可能になる。
【００３８】
ユーザＵ０１からチケットの委譲を受けたユーザＵ０２は、当該チケットをサービス提供者に提示する（ステップＳ２２）。サービス提供者は、ユーザＵ０２がチケットを譲りうけていること、すなわち、権限情報の委譲が判定装置１００によって許可されたことを根拠として、同行者の信頼性を確認する（ステップＳ２３）。この場合、サービス提供者は、ユーザＵ０１とともに、同行者であるユーザＵ０２にサービスを提供する（ステップＳ２４）。具体的には、サービス提供者は、ユーザＵ０１とユーザＵ０２の会場への入場を許可する。
【００３９】
このように、実施形態に係る判定装置１００は、ユーザＵ０１が提供を受けようとするサービスに関する権限情報、及び、購入者端末２０に関する利用状況を取得する。また、判定装置１００は、権限情報の委譲を許可するための条件であって、ユーザＵ０１と権限情報が委譲される委譲先であるユーザＵ０２との関係性を示した条件を取得する。そして、判定装置１００は、取得した利用状況に基づいて、ユーザＵ０１とユーザＵ０２との関係性が条件を満たすか否かを判定する。
【００４０】
すなわち、判定装置１００は、ユーザＵ０１の日常的な利用状況を取得し、取得した利用状況に基づいて、ユーザＵ０１にとって信頼に足るユーザを予め抽出しておく。このようにして抽出されたユーザは、ユーザＵ０１にとって同行者の候補となりうるユーザ（以下、「候補ユーザ」と表記する場合がある）である。そして、判定装置１００は、実際にユーザＵ０１がサービスを利用しようとするタイミングにおいて、ユーザＵ０１が有する権限情報を委譲することを所望した場合に、その委譲先となるユーザが、候補ユーザに含まれるか否かを判定する。さらに、判定装置１００は、候補ユーザがサービス側の条件を満たすか否かを判定する。このような処理により、判定装置１００は、サービス側が事前に認証情報を有しない同行者に対しても、一定の信頼性があるか否かを判定することができる。これにより、判定装置１００は、サービスにおいて転売等の不正な行為が行われることを抑止できる。具体的には、購入者からの転売でチケットを購入したユーザは、たとえ購入者とともに会場に来場したとしても、購入者との信頼関係がないため、チケットの委譲を受けることが許可されない。また、実施形態に係る判定装置１００によれば、サービス側は、事前に同行者の認証情報等を取得する手間や、認証情報を照合する手間を省くことができる。このように、判定装置１００は、事前に認証情報が記憶されていないユーザの信頼性の判定等、オンラインで管理される情報を種々の状況に応じて活用することができる。以下、上記の処理を行う判定装置１００、及び、判定装置１００を含む判定システム１の構成等について詳細に説明する。
【００４１】
〔２．判定システムの構成〕
次に、図３を用いて、実施形態に係る判定装置１００が含まれる判定システム１の構成について説明する。図３は、実施形態に係る判定システム１の構成例を示す図である。図３に例示するように、実施形態に係る判定システム１には、ユーザ端末１０と、サービスサーバ５０と、判定装置１００とが含まれる。また、ユーザ端末１０には、購入者端末２０や同行者端末３０等が含まれる。判定システム１に含まれる各種装置の数は、図示したものに限られない。これらの各種装置は、ネットワークＮを介して、有線又は無線により通信可能に接続される。なお、ネットワークＮの態様としては、インターネット（Internet）、ＬＡＮ（Local  Area  Network）やＶＰＮ（Virtual  Private  Network）、移動体通信網などの任意の通信網が挙げられる。
【００４２】
ユーザ端末１０は、例えば、デスクトップ型ＰＣ（Personal  Computer）や、ノート型ＰＣや、タブレット型端末や、スマートフォンを含む携帯電話機、ＰＤＡ（Personal  Digital  Assistant）等の情報処理端末（デバイス）である。また、ユーザ端末１０には、時計型端末や、眼鏡型端末などのウェアラブルデバイス（wearable  device）も含まれる。さらに、ユーザ端末１０には、情報処理機能を有する種々のスマート機器が含まれてもよい。例えば、ユーザ端末１０には、ＴＶ（Television）などのスマート家電や、自動車などのスマートビークル（Smart  vehicle）や、ドローン（drone）、家庭用ロボットなどが含まれてもよい。
【００４３】
サービスサーバ５０は、サービス提供者によって管理されるサーバ装置である。なお、サービスサーバ５０は、デスクトップ型ＰＣ、タブレット型ＰＣ、ノート型ＰＣなどの情報処理装置や、サービスにおける会計処理を行うＰＯＳ（Point  Of  Sales）端末等で実現されてもよい。
【００４４】
例えば、サービスサーバ５０は、サービス提供者が提供するサービスに関する情報や、サービスに関する権限情報や、権限情報を取得したユーザの認証情報等を管理する。具体的には、サービスサーバ５０は、ユーザからの要求に応答してオンラインチケットを発行し、発行したオンラインチケットをユーザに送信する。言い換えれば、サービスサーバ５０は、サービスに関する権限情報を購入者であるユーザに付与する処理を行う。かかる処理は、例えば、ユーザ端末１０にインストールされたアプリを介して行われてもよい。また、サービスサーバ５０は、サービスを購入したユーザの氏名や、住所、生年月日、年齢等のユーザ属性情報等を取得し、管理してもよい。例えば、サービスサーバ５０は、チケットの購入時にユーザから登録される情報に基づいて、ユーザに関する各種情報を取得する。なお、実施形態では、サービスサーバ５０と判定装置１００とを別の装置として記載しているが、これらは一つの装置であってもよい。例えば、サービスサーバ５０と判定装置１００とは、同じ管理者の下で管理される装置であってもよい。
【００４５】
判定装置１００は、上述のように、第１端末に関する利用状況とサービス側の条件とを取得し、取得した利用状況に基づいて、第１ユーザと第２ユーザとの関係性が条件を満たすか否かを判定するサーバ装置である。判定装置１００は、例えば、サービスサーバ５０と連携し、サービスにおける不正利用（例えば、チケットの高額転売等）を抑止する目的で利用される。
【００４６】
〔３．判定装置の構成〕
次に、図４を用いて、実施形態に係る判定装置１００の構成について説明する。図４は、実施形態に係る判定装置１００の構成例を示す図である。図４に示すように、判定装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、判定装置１００は、判定装置１００の管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。
【００４７】
（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ（Network  Interface  Card）等によって実現される。通信部１１０は、ネットワークＮと有線又は無線で接続され、ネットワークＮを介して、ユーザ端末１０やサービスサーバ５０との間で情報の送受信を行う。
【００４８】
（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random  Access  Memory)、フラッシュメモリ（Flash  Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。実施形態に係る記憶部１２０は、利用状況記憶部１２１と、通信先記憶部１２２と、トラストリスト記憶部１２３とを有する。以下、各記憶部について順に説明する。
【００４９】
（利用状況記憶部１２１について）
利用状況記憶部１２１は、第１端末の利用状況を記憶する。ここで、図５に、実施形態に係る利用状況記憶部１２１の一例を示す。図５は、実施形態に係る利用状況記憶部１２１の一例を示す図である。図５に示した例では、利用状況記憶部１２１は、「ユーザＩＤ」、「利用状況」といった項目を有する。また、「利用状況」の項目は、「ログＩＤ」、「行動日時」、「通信先ＩＤ」、「センサ情報」といった小項目を有する。
【００５０】
「ユーザＩＤ」は、第１ユーザ又は第１端末を識別する識別情報を示す。なお、実施形態の説明では、図５に示すような識別情報と、説明に用いる参照符号とは共通するものとする。例えば、ユーザＩＤが「Ｕ０１」であるユーザは、ユーザＵ０１（もしくは、ユーザＵ０１が所有する購入者端末２０）を示す。なお、ユーザと購入者端末２０（第１端末）との対応付けについては、例えば、判定装置１００やサービスサーバ５０が提供する所定のサービスをユーザが利用した場合に、ユーザから登録される情報に基づいて行われてもよい。具体的には、判定装置１００やサービスサーバ５０は、アクセスしてきた購入者端末２０の識別情報（ＭＡＣアドレスでもよいし、ブラウザのＣｏｏｋｉｅ等でもよい）と、ユーザが登録した識別情報（ユーザアカウントを登録する際のアカウントＩＤ等）とを取得することにより、ユーザと購入者端末２０とを対応付けることができる。
【００５１】
「利用状況」は、第１端末の利用状況（コンテキスト）を示す。「ログＩＤ」は、利用状況として取得されるログの識別情報を示す。「行動日時」は、利用状況が取得された（すなわち、行動が行われた）日時を示す。「通信先ＩＤ」は、第１端末とネットワークＮを介して接続された接続先の装置や、第１端末から検知された装置等の識別情報を示す。
【００５２】
「センサ情報」は、利用状況として取得される各種センサ情報を示す。図５では、「センサ情報」の項目に「Ｇ０１」等の概念的な情報が記憶される例を示しているが、実際には、「センサ情報」の項目には、第１端末が備えるセンサによって検知された具体的な情報が記憶される。一例として、センサ情報には、第１端末が検知した通信の種類（ＢｌｕｅｔｏｏｔｈであるかＬＡＮ接続であるか等）や、第１端末が備えるＧＰＳ（Global  Positioning  System）機能等によって検知された位置情報や、ジャイロセンサによって検知された傾度や加速度情報、周囲の照度や気圧、周囲の音の大きさを示す数値等が含まれる。
【００５３】
すなわち、図５では、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１が所有する第１端末の利用状況の一例が、ログＩＤ「ＬＧ０１」で識別されるログＬＧ０１であり、ログＬＧ０１が示す利用状況の行動日時は「２０１７年８月１日１２時００分」であり、通信先ＩＤが「Ｅ０２」で識別される装置であり、センサ情報が「Ｇ０１」であることを示している。
【００５４】
（通信先記憶部１２２について）
通信先記憶部１２２は、第１端末の通信相手となる通信先に関する情報を記憶する。具体的には、通信先記憶部１２２は、第１端末との間で通信が確立した装置を示す情報や、第１端末が検知した装置を示す情報等の履歴を記憶する。ここで、図６に、実施形態に係る通信先記憶部１２２の一例を示す。図６は、実施形態に係る通信先記憶部１２２の一例を示す図である。図６に示した例では、通信先記憶部１２２は、「通信先ＩＤ」、「デバイス種別」、「通信方式」といった項目を有する。
【００５５】
「通信先ＩＤ」は、第１端末の通信先であり、図５に示した同一の項目に対応する。「デバイス種別」は、通信先となるデバイスの種別を示す。「通信方式」は、第１端末と通信先のデバイスとの間で通信が行われた際の通信方式を示す。なお、通信方式は、１種類に限らず、複数の通信方式が記憶されてもよい。
【００５６】
すなわち、図６では、通信先ＩＤ「Ｅ０２」で識別される装置のデバイス種別が「スマートフォン」であり、第１端末との通信方式は「Ｂｌｕｅｔｏｏｔｈ」によって行われたことを示している。
【００５７】
なお、図６では図示を省略したが、通信先記憶部１２２には、通信先ＩＤに対応する装置を所有するユーザを識別する識別情報が記憶されてもよい。通信先ＩＤに対応する装置とユーザとの対応付けは、図５で説明した場合と同様、サービスに対する登録情報等から行われてもよい。この場合、通信先記憶部１２２には、例えば、通信先ＩＤ「Ｅ０２」で識別される装置の所有ユーザが「Ｕ０２」で識別されるユーザであるといった情報が記憶される。
【００５８】
（トラストリスト記憶部１２３について）
トラストリスト記憶部１２３は、第１ユーザ（言い換えれば、第１端末）ごとに生成されるトラストリストに関する情報を記憶する。ここで、図７に、実施形態に係るトラストリスト記憶部１２３の一例を示す。図７は、実施形態に係るトラストリスト記憶部１２３の一例を示す図である。図７に示した例では、トラストリスト記憶部１２３は、「トラストＩＤ」、「通信先ＩＤ」、「トラストデータ種別」、「ログＩＤ」といった項目を有する。
【００５９】
「トラストＩＤ」は、トラストリストに含まれるデータを識別する識別情報を示す。「通信先ＩＤ」は、図６に示した同一の項目に対応する。「トラストデータ種別」は、通信先を信頼のあるユーザ（候補ユーザ）であると判定した根拠となったデータの種別を示す。「ログＩＤ」は、図５に示した同一の項目に対応し、トラストデータ種別の判定に用いられたログデータを示す。
【００６０】
例えば、ログＩＤ「ＬＧ０１」や「ＬＧ０２」等が、通信先Ｅ０２との間でＢｌｕｅｔｏｏｔｈ接続が行われたことを示す利用状況であるとする。この場合、第１端末と通信先Ｅ０２とは、近接した関係（数メートルから１０メートル程）であったと判定できる。このように、第１端末と通信先Ｅ０２とが近接したという利用状況が頻繁に観測される場合、第１端末のユーザＵ０１と、通信先Ｅ０２のユーザ（例えば、図１に示したユーザＵ０２）とは、友人や知人の関係であると推測される。判定装置１００は、このような利用状況のログに基づいて、第１端末と通信先Ｅ０２とが「近接」していたという状況を判定し、判定した情報を根拠として、第１端末と通信先Ｅ０２とが関係性を有する、すなわち、第１端末にとって通信先Ｅ０２が信頼に足る装置であると判定し、トラストリストに追加する。
【００６１】
図７に示すように、トラストリストは、通信先を識別する情報と、その通信先が信頼に足ると判定されたデータとの組合せを含む。このため、トラストリストには、通信先ＩＤが同一の場合であっても、異なるトラストデータ種別によって候補ユーザとして抽出されたユーザ（通信先）が含まれる場合がある。例えば図７では、トラストリストには、「近接」や、「行動履歴」や、「ＳＮＳ（Social  Networking  Service）」といった各々異なるトラストデータ種別を根拠として、同一の通信先Ｅ０２が抽出される例を示している。なお、詳細は後述するが、「ＳＮＳ」とは、例えば、ユーザＵ０１が利用するＳＮＳにおいて、つながりを有する（相互にフォローする関係や、友人関係の設定が行われている等）ユーザとして、通信先Ｅ０２が観測されたことを意味する。
【００６２】
すなわち、図７では、トラストＩＤ「Ｔ０１」によって識別される候補ユーザは、通信先ＩＤ「Ｅ０２」によって識別される装置であり、トラストデータ種別が「近接」を根拠として抽出された装置であることを示している。また、トラストデータ種別が「近接」であると判定された根拠となる利用状況は、ログＩＤ「ＬＧ０１」や「ＬＧ０２」等で識別されるログであったことを示している。
【００６３】
（制御部１３０について）
制御部１３０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）等によって、判定装置１００内部の記憶装置に記憶されている各種プログラム（判定プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、コントローラであり、例えば、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路により実現される。
【００６４】
図４に示すように、制御部１３０は、第１取得部１３１と、生成部１３２と、第２取得部１３３と、判定部１３４と、送信部１３５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図４に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図４に示した接続関係に限られず、他の接続関係であってもよい。
【００６５】
（第１取得部１３１について）
第１取得部１３１は、ユーザ端末１０から各種情報を取得する。例えば、第１取得部１３１は、権限情報の所有者となる第１ユーザが利用する第１端末から、当該第１端末に関する利用状況を取得する。図１及び図２に示した例では、第１取得部１３１は、第１端末の一例である第１端末から、第１端末の利用状況を取得する。
【００６６】
第１取得部１３１は、利用状況として、第１端末によって検知された種々の情報を取得する。例えば、第１取得部１３１は、第１端末と第２ユーザが利用する第２端末とが近接したことを示す利用状況を取得する。
【００６７】
例えば、第１取得部１３１は、第１端末と第２端末とが近接したことを示す利用状況として、第１端末と第２端末とが近距離無線通信もしくは有線通信を行った履歴、又は、第１端末と第２端末とが同じアクセスポイントを利用した履歴等を取得する。また、第１取得部１３１は、利用状況として、例えば、近距離通信によってペアリングが継続している時間や、有線接続が行われた時間を取得することにより、第１端末と第２端末と近接した時間を導出することができる。
【００６８】
また、第１取得部１３１は、利用状況として、第１ユーザと第２ユーザとが同一又は類似する行動を行ったことを示す行動履歴を取得してもよい。
【００６９】
例えば、第１取得部１３１は、第１ユーザと第２ユーザとが同一又は類似する行動を行ったことを示す利用状況として、第１ユーザが所定サービスを利用した履歴と、第１ユーザが所定サービスを利用した所定時間内に第２ユーザが当該所定サービスを利用した履歴とを取得する。例えば、第１取得部１３１は、同じ店舗において、第１ユーザが決済した情報と、第２ユーザが決済した情報とが、所定の時間内（例えば１０分以内）に行われたことを示す利用状況を取得する。より具体的には、第１取得部１３１は、同じ社員食堂において、第１ユーザと第２ユーザとが所定の時間内に決済を行ったことを示す利用状況を取得する。この場合、第１取得部１３１は、第１端末に限らず、第１端末が利用した食堂等に設置される社員用の通信機器（無線ＬＡＮルータ等）から、第１端末や第２端末の利用状況を取得してもよい。また、第１取得部１３１は、通信状況のみならず、例えば、第１端末と第２端末とが同じ位置に所在していることを示す位置情報等を取得してもよい。
【００７０】
さらに、第１取得部１３１は、利用状況として、第１端末や第２端末同士の通信のみならず、第１ユーザや第２ユーザの交流を示す情報等を取得してもよい。例えば、第１取得部１３１は、第１端末の利用状況として、第１ユーザが利用するＳＮＳに関する情報を取得する。具体的には、第１取得部１３１は、利用状況として、第１ユーザが利用するＳＮＳにおいて、第１ユーザとつながりを有するユーザを識別する識別情報を取得する。より具体的には、第１取得部１３１は、所定のＳＮＳにおいてフォローしあう関係にあるユーザを識別する識別情報や、同じ画像を共有しているユーザを識別する識別情報等を取得する。このように、第１取得部１３１は、第１端末の利用状況として、通信状況や決済情報のみならず、第１ユーザのあらゆる行動に関する情報を取得してもよい。
【００７１】
また、第１取得部１３１は、第１端末からサービスに関する権限情報を取得する。後述する第２取得部１３３は、取得した権限情報に基づいてサービスを特定し、当該サービスが有する条件を取得する。また、判定部１３４は、取得した権限情報に基づいて、第１ユーザと第２ユーザとの関係性が条件を満たすか否かを判定する。
【００７２】
また、第１取得部１３１は、取得した各種情報を記憶部１２０内に格納する。例えば、第１取得部１３１は、取得した利用状況を示すログデータを利用状況記憶部１２１内に格納する。
【００７３】
（生成部１３２について）
生成部１３２は、第１取得部１３１によって取得された利用状況に基づいて、第２ユーザの候補となりうるユーザである候補ユーザが抽出されたリストであって、候補ユーザとして抽出される根拠を示す情報が含まれるトラストリストを生成する。
【００７４】
例えば、生成部１３２は、利用状況として、第１端末と候補ユーザが利用するユーザ端末１０とが近距離無線通信もしくは有線通信を行った履歴、又は、第１端末と候補ユーザが利用するユーザ端末１０とが同じアクセスポイントを利用した履歴に基づいて、トラストリストを生成する。この場合、生成部１３２は、トラストデータ種別を「近接」としたトラストリストを生成する。なお、生成部１３２がトラストデータ種別を判定するための定義データ等は、例えば、判定装置１００の管理者等によって、適宜、入力されたり更新されたりしてもよい。
【００７５】
例えば、生成部１３２は、所定期間（例えば１週間や１ヶ月間）の間に、所定回数を超えて第１端末と近距離無線通信した履歴を有するユーザ端末１０を、候補ユーザとして抽出する。そして、生成部１３２は、抽出した候補ユーザの識別情報と、トラストデータ種別（この例では「近接」）とを対応付けて、トラストリスト記憶部１２３に記憶する。
【００７６】
また、生成部１３２は、利用状況として、第１ユーザが所定サービスを利用した履歴と、第１ユーザが所定サービスを利用した所定時間内に候補ユーザが所定サービスを利用した履歴とに基づいてトラストリストを生成してもよい。すなわち、生成部１３２は、第１ユーザと同じ時間帯に同じ行動を行ったユーザは、第１ユーザとの何らかの関係性を有するユーザである可能性が高いと判定し、候補ユーザとして抽出する。そして、生成部１３２は、抽出した候補ユーザの識別情報と、トラストデータ種別（この例では「行動履歴」）とを対応付けて、トラストリスト記憶部１２３に記憶する。
【００７７】
また、生成部１３２は、第１ユーザが利用するサービスの利用状況等に基づいて、トラストリストを生成してもよい。具体的には、生成部１３２は、第１ユーザが利用するＳＮＳにおいてつながりを有するユーザを候補ユーザとして抽出する。そして、生成部１３２は、抽出した候補ユーザの識別情報と、トラストデータ種別（この例では「ＳＮＳ」）とを対応付けて、トラストリスト記憶部１２３に記憶する。なお、生成部１３２は、候補ユーザを抽出する基準については、任意の設定情報に基づいて行ってもよい。例えば、生成部１３２は、「少なくとも２つのＳＮＳにおいてつながりを有するユーザを候補ユーザとして抽出する」といった設定情報が存在する場合、かかる設定に基づいて、条件を満たすユーザを候補ユーザとして抽出する。このような設定情報は、例えば、判定装置１００の管理者等によって、予め記憶部１２０内に格納される。
【００７８】
（第２取得部１３３について）
第２取得部１３３は、サービスサーバ５０から各種情報を取得する。例えば、第２取得部１３３は、権限情報の委譲を許可するための条件であって、第１ユーザと権限情報が委譲される委譲先との関係性を示した条件を取得する。
【００７９】
例えば、第２取得部１３３は、第１端末と第２ユーザが利用する第２端末とが所定時間以上近接した履歴があることを条件として取得する。また、第２取得部１３３は、例えば第１端末と第２端末とが所定回数以上近接した履歴があることや、さらに期間に関する条件（例えば、直近１ヶ月以内に近接したことや、１ヶ月以上過去において近接したこと等）を追加した条件等を取得してもよい。
【００８０】
また、第２取得部１３３は、第１ユーザと第２ユーザとが所定回数以上、同一又は類似する行動を行ったことを示す行動履歴があることを条件として取得してもよい。同一又は類似する行動履歴は、例えば、第１ユーザが所定サービスを利用したことを示す行動履歴と、第１ユーザが所定サービスを利用した所定時間内に第２ユーザが所定サービスを利用したことを示す行動履歴等によって特定される。
【００８１】
また、第２取得部１３３は、第１ユーザが利用するＳＮＳにおいて第２ユーザとのつながりを有することを示す履歴が含まれることを条件として取得してもよい。例えば、サービス側は、所定期間よりも前に第１ユーザと第２ユーザとがＳＮＳ上でつながりがあることを条件として提示することにより、転売のために急きょつながりを作成したような第２ユーザについては信頼性が確保できないとして、サービスの利用を制限させることができる。
【００８２】
なお、第２取得部１３３は、第１ユーザから判定の要求を受けたタイミングでサービスサーバ５０から条件を取得するのみならず、事前に種々のサービスサーバ５０から条件を取得しておいてもよい。この場合、第２取得部１３３は、取得した条件を記憶部１２０内に格納する。そして、第２取得部１３３は、第１ユーザからの要求を受信したタイミングで、サービスに係る条件を特定し、特定した条件を記憶部１２０から取得する。
【００８３】
（判定部１３４について）
判定部１３４は、ユーザが権限情報を委譲しようとするユーザである第２ユーザとの関係性が条件を満たすか否かを判定する。
【００８４】
例えば、判定部１３４は、第２取得部１３３によって取得された条件と、生成部１３２によって生成されたリストが含む情報とを照合することにより、候補ユーザのうち第２ユーザとしての条件を満たす候補ユーザを判定する。なお、判定部１３４は、判定要求とともに、第１ユーザから、権限情報を委譲しようとする第２ユーザが特定する情報が送信された場合には、特定される第２ユーザがトラストリスト内の候補ユーザに含まれるか否か、また、特定される第２ユーザが条件を満たすか否か、をともに判定する。
【００８５】
例えば、判定部１３４は、近接に関する条件が取得された場合には、トラストリストにおいて、第１端末と候補ユーザが利用するユーザ端末１０とが所定時間以上近接した履歴を含むことを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが条件を満たすと判定する。具体的には、判定部１３４は、図７に示した例におけるトラストデータ種別の項目が「近接」である候補ユーザ（通信先ＩＤによって識別されるユーザ）が条件を満たすと判定する。なお、判定部１３４は、単に「近接」といったことを条件とするのみならず、サービス側のより詳細な条件（例えば、直近３０日の間に３時間以上の近接を条件とすること等）を満たすか否かを判定してもよい。
【００８６】
なお、判定部１３４は、近接の判定基準として、例えば、トラストリストにおいて、第１端末と候補ユーザが利用するユーザ端末１０とが近距離無線通信もしくは有線通信を行った履歴、又は、第１端末と候補ユーザが利用するユーザ端末１０とが同じアクセスポイントを利用した履歴を含むことを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが条件を満たすと判定するようにしてもよい。すなわち、判定部１３４は、上記のような通信の種別や、同じアクセスポイントを利用した端末同士を近接した関係にあったものと推定し、上記のような判定を行う。
【００８７】
また、判定部１３４は、トラストリストにおいて、第１ユーザと候補ユーザとが所定回数以上、同一又は類似する行動を行ったことを示す行動履歴を含むことを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが条件を満たすと判定してもよい。
【００８８】
具体的には、判定部１３４は、トラストリストにおいて、第１ユーザが所定サービスを利用した履歴と、第１ユーザが当該所定サービスを利用した所定時間内に候補ユーザが当該所定サービスを利用した履歴とを含むことを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが条件を満たすと判定する。このように、同じ時間帯に同じサービスを利用するユーザ同士は、近接した関係であるとともに、友人や知人である可能性が高いため、判定部１３４は、かかる情報を根拠として、両者が関係性を有すると判定する。
【００８９】
また、判定部１３４は、トラストリストにおいて、第１ユーザが利用するＳＮＳにおいて候補ユーザとつながりを有することを示す履歴が含まれることを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが条件を満たすと判定してもよい。
【００９０】
そして、判定部１３４は、第１ユーザと第２ユーザとが条件を満たす関係性にあると判定した場合、第１ユーザが有する権限情報を第２ユーザに委譲することを許可する。具体的には、判定部１３４は、第１端末にインストールされたアプリにおいて、第１ユーザから第２ユーザへ権限情報を委譲することを可能とする設定を行う。
【００９１】
（送信部１３５について）
送信部１３５は、各種情報を送信する。例えば、送信部１３５は、判定部１３４によって判定された結果に基づいて、権限情報の委譲を許可した旨の通知を第１端末に送信する。また、送信部１３５は、第１端末に通知を送信するとともに、第１ユーザから第２ユーザへの権限情報の委譲を許可した旨の通知をサービスサーバ５０に送信してもよい。これにより、サービス側は、権限情報の委譲が判定装置１００によって許可されたことを事前に把握することができる。
【００９２】
〔４．ユーザ端末の構成〕
次に、図８を用いて、実施形態に係るユーザ端末１０の構成について説明する。図８は、実施形態に係るユーザ端末１０の構成例を示す図である。図８に示すように、ユーザ端末１０は、通信部１１と、入力部１２と、表示部１３と、検知部１４と、記憶部１５と、制御部１６とを有する。なお、ユーザ端末１０が有する各処理部の接続関係は、図８に示した接続関係に限られず、他の接続関係であってもよい。
【００９３】
（通信部１１について）
通信部１１は、ネットワークと有線又は無線で接続され、判定装置１００やサービスサーバ５０等との間で情報の送受信を行う。例えば、通信部１１は、ＮＩＣ等によって実現される。
【００９４】
（入力部１２について）
入力部１２は、ユーザから各種操作を受け付ける入力装置である。例えば、入力部１２は、ユーザ端末１０に備えられた操作キー等によって実現される。また、入力部１２には、画像を撮影するための撮像装置（カメラ等）や、音声を集音する集音機器（マイク等）が含まれてもよい。
【００９５】
（表示部１３について）
表示部１３は、各種情報を表示するための表示装置である。例えば、表示部１３は、液晶ディスプレイ等によって実現される。なお、ユーザ端末１０にタッチパネルが採用される場合には、入力部１２の一部と表示部１３とは一体化される。
【００９６】
（検知部１４について）
検知部１４は、ユーザ端末１０に関する各種情報を検知する。具体的には、検知部１４は、ユーザ端末１０に対するユーザの操作や、ユーザ端末１０の所在する位置情報や、ユーザ端末１０と接続されている機器に関する情報や、ユーザ端末１０における環境等を検知する。
【００９７】
例えば、検知部１４は、入力部１２に入力された情報に基づいて、ユーザの操作を検知する。すなわち、検知部１４は、入力部１２に画面をタッチする操作の入力があったことや、音声の入力があったこと等を検知する。また、検知部１４は、ユーザによって上述したアプリが起動されたことを検知してもよい。また、検知部１４は、ユーザ端末１０内に備えられた加速度センサやジャイロセンサ等で検知されたデータに基づき、ユーザ端末１０自体が動かされているといった操作を検知してもよい。
【００９８】
また、検知部１４は、ユーザ端末１０の現在位置を検知する。具体的には、検知部１４は、ＧＰＳ衛星から送出される電波を受信し、受信した電波に基づいてユーザ端末１０の現在位置を示す位置情報（例えば、緯度及び経度）を取得する。
【００９９】
また、検知部１４は、種々の手法により位置情報を取得してもよい。例えば、ユーザ端末１０が駅改札や商店等で使用される非接触型ＩＣカードと同等の機能を備えている場合（もしくは、ユーザ端末１０が非接触型ＩＣカードの履歴を読み取る機能を備えている場合）、ユーザ端末１０によって駅での乗車料金の決済等が行われた情報とともに、使用された位置が記録される。検知部１４は、かかる情報を検知し、位置情報として取得する。また、検知部１４は、ユーザ端末１０が特定のアクセスポイントと通信を行う際には、アクセスポイントから取得可能な位置情報を検知してもよい。また、位置情報は、ユーザ端末１０が備える光学式センサや、赤外線センサや、磁気センサ等によって取得されてもよい。また、ＩＰアドレス等によってユーザ端末１０の位置を推定可能な場合には、検知部１４は、位置情報の一例として、ＩＰアドレス等を取得してもよい。
【０１００】
また、検知部１４は、ユーザ端末１０に接続される外部装置を検知する。なお、外部装置とは、対象となるユーザ端末１０以外の装置であり、対象とは異なる他のユーザ端末１０が含まれてもよい。例えば、購入者端末２０からみた場合、同行者端末３０は、外部装置として認識される。
【０１０１】
検知部１４は、例えば、外部装置との相互の通信パケットのやり取りや、外部装置が発する信号等に基づいて、外部装置を検知する。具体的には、検知部１４は、外部装置が利用しているＷｉｆｉ（登録商標）やＢｌｕｅｔｏｏｔｈ等の電波を検知する。また、検知部１４は、外部装置と通信が確立する場合に、外部装置との接続の種類を検知してもよい。例えば、検知部１４は、外部装置と有線で接続されているか、無線通信で接続されているかを検知する。また、検知部１４は、無線通信で用いられている通信方式等を検知してもよい。また、検知部１４は、外部装置が発する電波を検知する電波センサや、電磁波を検知する電磁波センサ等によって取得される情報に基づいて、外部装置を検知してもよい。
【０１０２】
また、検知部１４は、ユーザ端末１０における環境を検知する。検知部１４は、ユーザ端末１０に備えられた各種センサや機能を利用し、環境に関する情報を検知する。例えば、検知部１４は、ユーザ端末１０の周囲の音を収集するマイクロフォンや、ユーザ端末１０の周囲の照度を検知する照度センサや、ユーザ端末１０の物理的な動きを検知する加速度センサ（又は、ジャイロセンサなど）や、ユーザ端末１０の周囲の湿度を検知する湿度センサや、ユーザ端末１０の所在位置における磁場を検知する地磁気センサ等を利用する。そして、検知部１４は、各種センサを用いて、種々の情報を検知する。例えば、検知部１４は、ユーザ端末１０の周囲における騒音レベルや、ユーザ端末１０の周囲がユーザの虹彩を撮像に適する照度であるか等を検知する。さらに、検知部１４は、カメラで撮影された写真や映像に基づいて周囲の環境情報を検知してもよい。
【０１０３】
また、ユーザ端末１０は、検知部１４によって検知された情報に基づいて、ユーザ端末１０のコンテキストを示す各種情報を取得するようにしてもよい。上述のように、ユーザ端末１０は、内蔵された各種センサ（検知部１４）により、位置、加速度、温度、重力、回転（角速度）、照度、地磁気、圧力、近接、湿度、回転ベクトルといった、種々の物理量を、コンテキストを示す情報として取得する。また、ユーザ端末１０は、内蔵する通信機能を利用して、各種装置との接続状況（例えば、通信の確立に関する情報や、利用している通信規格）などを、コンテキストを示す情報として取得してもよい。
【０１０４】
（記憶部１５について）
記憶部１５は、各種情報を記憶する。記憶部１５は、例えば、ＲＡＭ、フラッシュメモリ（Flash  Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。例えば、記憶部１５は、ユーザによるユーザ端末１０の利用状況を記憶する。
【０１０５】
（制御部１６について）
制御部１６は、コントローラであり、例えば、ＣＰＵ等によって、ユーザ端末１０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１６は、コントローラであり、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。例えば、制御部１６は、ＲＡＭを作業領域として、インストールされたアプリ等のプログラムを実行することにより、各種情報処理を実現する。図８に示すように、制御部１６は、取得部１６１と、受信部１６２と、送信部１６３とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１６の内部構成は、図８に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。
【０１０６】
（取得部１６１について）
取得部１６１は、各種情報を取得する。例えば、取得部１６１は、検知部１４によって検知された各種情報を、ユーザ端末１０の利用状況として取得する。また、取得部１６１は、取得した利用状況を記憶部１５内に格納する。
【０１０７】
（受信部１６２について）
受信部１６２は、各種情報を受信する。例えば、受信部１６２は、ユーザが実際に会場でサービスを受けようとする際に、会場に設置される所定の機器から発信される情報を受信する。具体的には、受信部１６２は、会場に設置されるサービスサーバ５０や、会場に設置されるアクセスポイントや、ビーコン等から、購入した際にサービス側に提示した認証情報と照合するための認証情報を送信することを要求する旨の信号を受信する。
【０１０８】
（送信部１６３について）
送信部１６３は、各種情報を送信する。例えば、送信部１６３は、会場において、ユーザが事前に購入した権限情報（オンラインチケット等）の情報をサービスサーバ５０に送信する。また、送信部１６３は、ユーザの操作に従って、購入した際にサービス側に提示した認証情報と照合するための認証情報をサービスサーバ５０に送信する。具体的には、送信部１６３は、ユーザから入力されたパスワードや、会場で撮像したユーザの顔画像等を送信する。なお、送信部１６３は、認証情報として、ユーザの指紋情報を送信したり、音声情報を送信したりしてもよい。
【０１０９】
また、送信部１６３は、ユーザが同行者に権限情報を委譲することを所望する操作を行った場合には、判定装置１００に対して、権限情報の委譲の判定を行うことを要求する旨の信号を送信する。
【０１１０】
〔５．サービスサーバの構成〕
次にサービスサーバ５０の構成について説明する。図９は、実施形態に係るサービスサーバ５０の構成例を示す図である。図９に示すように、サービスサーバ５０は、通信部５１と、操作入力部５２と、表示部５３と、リーダ部５４と、記憶部５５と、制御部５６とを有する。
【０１１１】
（通信部５１について）
通信部５１は、ＮＩＣ等のインターフェイスである。通信部５１は、ネットワークを介した他の装置との間で各種のデータを送受信する。例えば、通信部５１は、サービスサーバ５０で提供するサービスに関する情報を判定装置１００に送信する。また、通信部５１は、購入者及び同行者に対する認証処理の要求をユーザ端末１０に送信する。
【０１１２】
（操作入力部５２について）
操作入力部５２は、各種の情報を入力する入力デバイスである。例えば、操作入力部５２としては、マウスやキーボード、タッチパネルなどの入力デバイスが挙げられる。操作入力部５２は、例えば、サービスサーバ５０の管理者（例えば、会場に所在するサービス提供者）から各種の情報の入力を受け付け、受け付けた操作内容を示す操作情報を制御部５６に入力する。
【０１１３】
（表示部５３について）
表示部５３は、各種情報を表示する表示デバイスである。表示部５３としては、ＬＣＤやＣＲＴなどの表示デバイスが挙げられる。表示部５３は、各種情報を表示する。例えば、表示部５３は、ユーザがサービス提供の条件を満たすか否か（例えば、オンラインチケットが有効なものであるか否か等）を表示する。
【０１１４】
（リーダ部５４について）
リーダ部５４は、所定の情報を読み取る。例えば、リーダ部５４は、ユーザ端末１０がかざされることにより、ユーザ端末１０が有する近距離無線通信機能を起動させる。そして、リーダ部５４は、ユーザ端末１０がオンラインチケットを有するか否か、あるいは、オンラインチケットが正規で有効なものであるか否かといった、権限情報を読み取る。なお、リーダ部５４が情報を読み取る手段は、既知である様々な読取手段により実現されてよい。例えば、リーダ部５４は、権限情報がコード化された２次元コードを画像として読み取り、読み取った画像をデコードして、コード化された権限情報を制御部５６へ出力してもよい。
【０１１５】
（記憶部５５について）
記憶部５５は、各種情報を記憶するデバイスである。例えば、記憶部５５としては、ＲＡＭ、フラッシュメモリなどの半導体メモリ素子や、ハードディスク、光ディスクなどの記憶装置が挙げられる。
【０１１６】
記憶部５５は、制御部５６で実行されるＯＳやユーザ情報の管理に用いる各種プログラムを記憶する。さらに、記憶部５５は、各種データを記憶する。例えば、記憶部５５は、サービス情報記憶部５５１及びトラストポリシー記憶部５５２を有する。
【０１１７】
（サービス情報記憶部５５１について）
サービス情報記憶部５５１は、サービスに関する情報が記憶される。ここで、図１０に、実施形態に係るサービス情報記憶部５５１の一例を示す。図１０は、実施形態に係るサービス情報記憶部５５１の一例を示す図である。図１０に示した例では、サービス情報記憶部５５１は、「サービスＩＤ」、「サービス内容」、「権限取得者」、「チケット発行枚数」、「認証情報」といった項目を有する。
【０１１８】
「サービスＩＤ」は、サービスを識別する識別情報を示す。「サービス内容」は、サービスの具体的な内容を示す。「権限取得者」は、サービスに関する権限を取得した取得者を示す。なお、権限取得者として表示する情報は、ユーザＩＤと共通するものとする。「チケット発行枚数」は、権限取得者（すなわち、購入者）に対して発行したチケットの枚数を示す。言い換えれば、権限取得者は、サービスに対して、チケット発行枚数分の権限情報を有する。「認証情報」は、権限取得者の本人性を確認するために用いられる認証情報の種別を示す。
【０１１９】
すなわち、図１０では、サービス情報記憶部５５１に記憶される情報の一例として、サービスＩＤ「Ｐ０１」で識別されるサービスは、サービス内容が「コンサートチケット販売」に関するものであり、そのサービスにおける権限取得者は、例えば「Ｕ０１」であり、チケット発行枚数は「２」枚であり、認証情報として「パスワード」が登録されていることを示している。
【０１２０】
（トラストポリシー記憶部５５２について）
トラストポリシー記憶部５５２は、サービス側が有するトラストに関するポリシー（規約）に関する情報を記憶する。具体的には、トラストポリシー記憶部５５２は、サービス側が同行者に対して要求する条件を記憶する。ここで、図１１に、実施形態に係るトラストポリシー記憶部５５２の一例を示す。図１１は、実施形態に係るトラストポリシー記憶部５５２の一例を示す図である。図１１に示した例では、トラストポリシー記憶部５５２は、「サービスＩＤ」、「条件ＩＤ」、「条件」といった項目を有する。
【０１２１】
「サービスＩＤ」は、図１０に示した同一の項目に対応する。「条件ＩＤ」は、条件を識別するための識別情報を示す。「条件」は、サービス側が同行者に求める具体的な条件の内容を示す。
【０１２２】
すなわち、図１１では、トラストポリシー記憶部５５２に記憶される情報の一例として、サービスＩＤ「Ｐ０１」で識別されるサービスには、条件ＩＤ「Ｒ０１」や、「Ｒ０２」や、「Ｒ０３」等で識別される条件が設定されており、例えば条件Ｒ０１は、第１端末と第２端末との関係性が「直近１ヶ月以内の近接時間が３時間以上」を満たす関係性であること、を条件とすることを示している。
【０１２３】
（制御部５６について）
制御部５６は、コントローラであり、例えば、ＣＰＵやＭＰＵ等によって、サービスサーバ５０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部５６は、コントローラであり、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。制御部５６は、各種のプログラムが動作することにより各種の処理部として機能する。例えば、制御部５６は、取得部５６１と、読取制御部５６２と、認証情報要求部５６３と、検証部５６４とを有する。
【０１２４】
（取得部５６１について）
取得部５６１は、各種情報を取得する。例えば、取得部５６１は、サービス提供者によって入力される、サービスに関する情報を取得する。また、取得部５６１は、オンライン上で行われるチケットの購入要求に関する情報や、購入者から送信される認証情報等を取得する。
【０１２５】
（読取制御部５６２について）
読取制御部５６２は、リーダ部５４における読み取り処理を制御する。例えば、読取制御部５６２は、操作入力部５２に対してユーザ端末１０の読み取り開始を指示する所定の操作が行われた場合、リーダ部５４を制御してユーザ端末１０の読み取りを行う。具体的には、読取制御部５６２は、会場において購入者から提示されるユーザ端末１０から、サービスに関する権限情報を読み取る。
【０１２６】
（認証情報要求部５６３について）
認証情報要求部５６３は、読取制御部５６２が権限情報を読み取ったのち、当該権限情報に関する認証情報を購入者に要求する。例えば、認証情報要求部５６３は、認証情報として、パスワードの入力を要求する。また、認証情報要求部５６３は、認証情報として、顔画像データの入力を要求する。なお、顔画像データの入力は、例えば、会場に設置される顔認証システム等の外部装置と連携して行われてもよい。
【０１２７】
（検証部５６４について）
検証部５６４は、認証情報要求部５６３による要求に応答したユーザ端末１０から送信された認証情報を検証する。具体的には、検証部５６４は、予めサービス情報記憶部５５１に記憶されていた認証情報と、会場において購入者から提示された認証情報とを照合する。そして、検証部５６４は、照合結果が一致した場合に、購入者の本人性が確認されたと判定する。
【０１２８】
〔６．処理手順〕
次に、図１２及び図１３を用いて、判定装置１００による処理の手順について説明する。まず、図１２を用いて、判定装置１００によるトラストリストの生成処理の手順について説明する。図１２は、実施形態に係る処理手順を示すフローチャート（１）である。
【０１２９】
判定装置１００は、第１端末から、第１端末の利用状況を取得したか否かを判定する（ステップＳ１０１）。利用状況を取得していない場合（ステップＳ１０１；Ｎｏ）、判定装置１００は、取得するまで待機する。
【０１３０】
一方、利用状況を取得した場合（ステップＳ１０１；Ｙｅｓ）、判定装置１００は、取得した利用状況に基づいて、第１端末を所有する第１ユーザに関するトラストリストを生成する（ステップＳ１０２）。
【０１３１】
その後、判定装置１００は、第１端末からさらに利用状況を取得したか否かを判定する（ステップＳ１０３）。利用状況を取得していない場合（ステップＳ１０３；Ｎｏ）、判定装置１００は、取得するまで待機する。
【０１３２】
一方、利用状況を取得した場合（ステップＳ１０３；Ｙｅｓ）、判定装置１００は、第１ユーザに関するトラストリストを更新する（ステップＳ１０４）。判定装置１００は、トラストリストの更新処理を継続的に行うことにより、第１ユーザと関係性を有する候補ユーザを抽出したり、削除したりする処理を繰り返す。
【０１３３】
次に、図１３を用いて、判定装置１００による判定処理の手順について説明する。図１３は、実施形態に係る処理手順を示すフローチャート（２）である。
【０１３４】
判定装置１００は、第１端末から、権限情報及び同行者の信頼性の判定要求を受信したか否かを判定する（ステップＳ２０１）。権限情報及び判定要求を受信していない場合（ステップＳ２０１；Ｎｏ）、判定装置１００は、受信するまで待機する。
【０１３５】
一方、権限情報及び判定要求を受信した場合（ステップＳ２０１；Ｙｅｓ）、判定装置１００は、当該権限情報及び判定要求に関係するサービスを特定し、サービス側から、当該サービスの条件を取得する（ステップＳ２０２）。
【０１３６】
そして、判定装置１００は、条件とトラストリストとを照合する（ステップＳ２０３）。照合の結果を受けて、判定装置１００は、同行者が条件を満たすか否かを判定する（ステップＳ２０４）。
【０１３７】
同行者が条件を満たす場合（ステップＳ２０４；Ｙｅｓ）、判定装置１００は、第１端末に対して、チケット（権限情報）の委譲を許可する旨を送信する（ステップＳ２０５）。
【０１３８】
一方、同行者が条件を満たさない場合（ステップＳ２０４；Ｎｏ）、判定装置１００は、第１端末に対して、チケット（権限情報）の委譲を許可しない旨を送信する（ステップＳ２０６）。
【０１３９】
〔７．変形例〕
上述した判定システム１による判定処理は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、判定システム１の他の実施形態について説明する。
【０１４０】
〔７−１．条件及びトラストデータの種別〕
上記実施形態では、判定装置１００は、例えば第１端末と第２端末とが日常的に近接する関係にあるか、同じような行動履歴を有するか、あるいは、ＳＮＳにおけるつながりがあるか、といった利用状況に基づいて、第２端末（第２ユーザ）をトラストリストに追加したり、条件の判定を行ったりする例を示した。しかし、判定装置１００が第２端末の信頼性を判定するための情報は、上記に限られない。
【０１４１】
例えば、判定装置１００は、第１ユーザが利用する画像共有サービスにおいて第２ユーザが撮像された画像を共有していることを示す履歴が含まれることを条件として取得してもよい。また、判定装置１００は、トラストリストにおいて、第１ユーザが利用する画像共有サービスにおいて候補ユーザが撮像された画像を共有していることを示す履歴が含まれることを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが条件を満たすと判定してもよい。
【０１４２】
この場合、判定装置１００は、画像共有サイトに関する情報として、第１ユーザが他のユーザと画像を共有していること、及び、当該他のユーザを識別する情報を取得する。そして、判定装置１００は、画像を共有しているという関係性を根拠として、当該他のユーザをトラストリストに追加する。このように、判定装置１００は、画像共有サイト等における共有関係を根拠として、トラストリストを生成してもよい。なお、判定装置１００は、画像共有サイトに限らず、データ共有サイトなど、例えばクラウド上で提供される種々のサービスを共有する関係にあるユーザ同士を関係性のあるユーザであると推定し、トラストリストに追加するようにしてもよい。
【０１４３】
また、判定装置１００は、例えば上記のような画像データを利用して、異なる手法によって同行者の信頼性を判定する処理を行ってもよい。例えば、判定装置１００は、画像共有サイトや、第１端末がローカルに記憶する画像データを既知の技術を用いて解析し、画像データに含まれる人物の顔画像を抽出する。その後、サービスサーバ５０は、会場において、同行者の顔画像データを取得し（例えば、顔認証システムを用いて同行者を撮像し）、取得した顔画像データを判定装置１００に送信する。判定装置１００は、第１端末に記憶されていた画像データから抽出された顔画像に、会場を訪れた同行者と同一人物と判定される顔画像が含まれる場合、同行者が購入者の友人や知人である可能性が高いと推定し、当該同行者が信頼に足るユーザであると判定する。判定装置１００は、同行者を信頼できるユーザと判定した場合には、第１ユーザの権限情報を第２ユーザ（同行者）に委譲する処理を可能とする設定を行ってもよい。
【０１４４】
また、判定装置１００は、上記の判定処理について、顔以外の画像データを用いて行ってもよい。例えば、判定装置１００は、画像共有サイトや、第１端末がローカルに記憶する画像データを既知の技術を用いて解析し、画像データに含まれる対象であって、同行者を特定することが可能な対象を抽出する。一例として、判定装置１００は、画像データに含まれるネイルアートを対象として抽出するものとする。この場合、サービスサーバ５０は、会場において、同行者が施しているネイルアートの画像データを取得し（例えば、カメラを用いてネイルアートを撮像し）、取得したネイルアートの画像データを判定装置１００に送信する。なお、サービス側は、第１ユーザ又は同行者から、ネイルアートの画像データによる認証の申請を受け付けた場合に、同行者のネイルアートの画像データを取得してもよい。
【０１４５】
そして、判定装置１００は、サービスサーバ５０から送信されたネイルアートの画像データを受け付けるとともに、画像共有サイトや、第１端末がローカルに記憶する画像データにおいて、サービスサーバ５０から送信されたネイルアートの画像データと部分的に一致する画像データが存在するか否かを判定する。そして、判定装置１００は、サービスサーバ５０から送信されたネイルアートを過去に撮像したと推定される画像データが、画像共有サイトや、第１端末がローカルに記憶する画像データに存在していた場合に、第１ユーザと同行者とが友人又は知人である可能性が高いと推定し、当該同行者が信頼に足るユーザであると判定してもよい。
【０１４６】
このように、判定装置１００は、第１端末から取得される利用状況に基づいて、第２ユーザとの関係性を示すと推定される種々の情報を抽出し、第１ユーザと第２ユーザとの関係性を判定する処理を柔軟に行ってもよい。
【０１４７】
また、他の例として、判定装置１００は、第１ユーザが利用するネットワーク上のカレンダーサービスにおいて第２ユーザと同じ予定を共有することを示す履歴が含まれることを条件として取得してもよい。この場合、判定装置１００は、トラストリストにおいて、第１ユーザが利用するネットワーク上のカレンダーサービスにおいて候補ユーザと同じ予定を共有することを示す履歴が含まれることを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが条件を満たすと判定する。
【０１４８】
この場合、判定装置１００は、第１ユーザが利用するネットワーク上のカレンダーサービスにおいて他のユーザと同じ予定を共有することを示す履歴が含まれることを根拠として、当該他のユーザをトラストリストに追加する。このように、判定装置１００は、例えば、クラウド上のカレンダーサービス等のスケジュールサービス等における共有関係を根拠として、トラストリストを生成してもよい。
【０１４９】
また、他の例として、判定装置１００は、第１ユーザと第２ユーザとが所定時間以上、同行した履歴があることを条件として取得してもよい。この場合、判定装置１００は、トラストリストにおいて、第１ユーザと候補ユーザとが所定時間以上、歩行動作において共起した履歴が含まれることを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、当該候補ユーザが条件を満たすと判定する。
【０１５０】
すなわち、判定装置１００は、第１端末におけるジャイロセンサによる検知情報や、第１端末とペアリングする第２端末から取得されるジャイロセンサによる検知情報に基づいて、両者が同行していることを判定する。このような歩行の共起は、既知の技術や、また、位置情報の一致等により判定可能である。判定装置１００は、第１ユーザと同行する時間の長いユーザは、第１ユーザと何らかの関係性を有するユーザであるとして、当該ユーザをトラストリストに追加する。このように、判定装置１００は、第１端末によって取得される、日常的な動作や行動などのあらゆる利用状況（コンテキスト）に基づいて、トラストリストを生成するようにしてもよい。
【０１５１】
〔７−２．権限情報の委譲〕
上記実施形態では、同行者の信頼性が判定された場合に、第１ユーザから第２ユーザに対して権限情報の委譲が行われる例を示した。ここで、権限情報の委譲とは、必ずしも端末間をオンラインチケットの情報が移行することを示すのではなく、単に、第２ユーザに第１ユーザの権限を使用させることを許可するといった状況を含むものであってもよい。例えば、サービス提供者は、第１ユーザの同行者として第２ユーザが検証されたことを示す情報を第１端末の画面上等で確認し、確認を行った場合に、その権限の行使を許可するようにしてもよい。
【０１５２】
また、この場合、同行者は、必ずしも図８に示したユーザ端末１０のような各種機能を備えた装置を有しなくてもよい。例えば、同行者は、ＮＦＣに対応した社員証など、第１端末と通信を行うことが可能であり、識別情報を有するものだけ所有していれば、サービスを享受することが可能となる。具体的には、判定装置１００は、第１端末と近接する位置に、同行者の社員証が所在していたという履歴（例えば、ＮＦＣによって第１端末に社員証が認識されていた履歴）に基づいて、当該社員証をトラストリストに含める。そして、判定装置１００は、トラストリストの情報がサービス側の条件を満たせば、当該社員証が信頼に足るデバイスであると判定可能である。この場合、同行者は、例えば、判定装置１００によって権限情報の委譲が許可された社員証をサービスサーバ５０のリーダ部５４にかざすことで、自身が信頼されたデバイスであることをサービス側に伝えることができる。
【０１５３】
〔７−３．判定処理の契機〕
判定装置１００は、サービスサーバ５０から、サービス提供側によって第１ユーザ（購入者）が権限情報を有する本人であることが確認された旨を示す情報を取得し、かかる情報が取得されたことを契機として、第１ユーザと第２ユーザ（同行者）との関係性が条件を満たすか否かを判定するようにしてもよい。
【０１５４】
判定装置１００は、購入者が信頼できるユーザであることを前提として同行者の信頼性を判定するため、購入者が信頼に足るユーザでない場合、判定処理を行うことを要しない。このため、判定装置１００は、サービスサーバ５０による購入者の認証情報の検証などが問題なく完了したことを示す情報を取得したのちに、同行者の判定処理を行うようにしてもよい。これにより、判定装置１００は、無駄な判定処理を回避することができるので、情報処理の負荷を軽減させることができる。
【０１５５】
なお、上記のような、サービス側が購入者の本人性を確認したことを示す情報は、購入者と同行者との関係性を判定する処理が行われようとする際や、購入者と同行者との関係性を判定する処理が行われた後に取得されてもよい。すなわち、購入者が本人であると確認されたことを示す情報の取得は、判定処理の前に行われてもよいし、後で行われてもよい。
【０１５６】
すなわち、判定装置１００は、１ユーザと第２ユーザとの関係性が条件を満たすか否かを判定する場合に、サービス提供側によって第１ユーザが権限情報を有する本人であることが確認されているか否かを判定し、確認されていない場合には、第１ユーザが権限情報を有する本人であることがサービス提供側によって確認された旨を示す情報の提示をサービス提供側に要求するようにしてもよい。
【０１５７】
具体的には、判定装置１００は、第１ユーザと第２ユーザとの関係性が条件を満たすと判定し、第１ユーザが購入したオンラインチケットを第２ユーザに委譲しようとする段階になって、第１ユーザがサービス側によって本人確認がなされていない場合には、第１ユーザがサービス側によって間違いなく本人であることが確認されたことを示す情報を取得するよう、サービス側に要求を行う。これにより、判定装置１００は、第１ユーザと第２ユーザとの関係性が条件を満たすか否かを判定した処理を行い、実際に第２ユーザが権利を行使しようとしたときに、まだ第１ユーザの本人確認が完了していなかったというような事態が発生することを防止できる。
【０１５８】
〔７−４．判定装置〕
上記実施形態では、判定装置１００が、第１端末とは異なるサーバ装置として実現される例を示した。しかし、実施形態で説明した判定装置１００が実行する全ての処理は、第１端末によって行われてもよい。すなわち、第１端末は、利用状況をサーバにアップロードするのではなく、自らが判定装置１００の機能を有し、実施形態に係る判定処理を行うものであってもよい。この場合、第１端末は、図８に示した構成に加えて、図４に示した判定装置１００が有する構成を全て備えていてもよい。
【０１５９】
〔７−５．ユーザ端末の態様〕
上記実施形態では、図８を用いてユーザ端末１０の構成例を示したが、ユーザ端末１０は、図８で示した構成を必ずしも全て有していなくてもよい。ユーザ端末１０には、上述のように、スマートフォンやウェアラブルデバイスのようなスマートデバイスのみならず、通信機能を有する眼鏡型端末や、あるいは、ユーザの心拍を記憶する心拍測定器など、種々のウェアラブルデバイスが含まれる。また、ユーザ端末１０には、上述のように、ＮＦＣ機能を有するカード型端末等も含まれる。この場合、ユーザ端末１０は、必ずしもユーザから入力を受け付けるのではなく、自動的にユーザの情報を取得し、かかる情報を通信ネットワークに送信するなどの機能を持ちうる。すなわち、ユーザ端末１０は、いわゆるＩｏＴ（Internet  of  Things）を実現するような、所定の通信機能を有するデバイスであれば、必ずしも図８で示した構成を有していなくてもよい。また、ユーザ端末１０は、図８で示した構成を実現するための機能を有する、２台以上の機器により実現されてもよい。
【０１６０】
〔７−６．認証情報〕
上記実施形態では、購入者の本人確認のため、購入者端末２０が認証情報をサービスサーバ５０に送信する例を示した。しかし、購入者端末２０は、認証情報そのものを送信するのではなく、購入者端末２０が有する認証機能によって認証が完了したことを示す情報を送信してもよい。例えば、購入者端末２０が指紋認証機能を有する場合、購入者は、会場において指紋を購入者端末２０にかざす。そして、購入者端末２０は、権限情報が記憶された端末のユーザが購入者本人であることを認証したことを示す情報を、認証情報としてサービスサーバ５０に送信する。これにより、購入者端末２０は、パスワード等の認証情報そのものを送信しないで本人認証を行わせることができるため、安全性を高めることができる。かかる処理は、ＦＩＤＯ（Fast  Identity  Online  Alliance）のような技術を利用することで実現可能である。
【０１６１】
また、購入者端末２０が上記のような「端末側で本人を認証したという結果情報」を同行者端末３０に送信し、同行者が、購入者端末２０から受信した結果情報をサービス側に提示してもよい。この場合、購入者端末２０は、トラストリストを参照し、「端末側で本人を認証したという結果情報」を送信することが許可可能なユーザを判定する。そして、購入者端末２０は、トラストな関係にあるユーザ（ここでは、同行者端末３０を所有するユーザ）に、かかる結果情報を送信することを許可する。
【０１６２】
この場合、同行者は、同行者端末３０内に「購入者本人を認証したという結果情報」を有していることで、購入者とトラストな関係にあり、かつ、サービスの権限情報を行使する権利を有していることをサービス側に提示することができる。このように、同行者は、購入者端末２０における「端末側で本人を認証したという結果情報」を用いて、自身の信頼性を証明してもよい。言い換えれば、同行者は、チケットのような権限情報に代えて、購入者端末２０が端末側で本人認証を行った結果情報を提示することで、サービスに対して権限を行使することができる。
【０１６３】
〔７−７．同行者の確認〕
判定装置１００は、購入者から同行者にオンラインチケット等の権限情報が委譲された場合に、委譲された権限の行使に際して、同行者端末３０において同行者の本人確認を要求するようにしてもよい。例えば、判定装置１００は、委譲された権限情報権限情報を行使するための条件として、同行者端末３０における指紋認証等を同行者に要求する。これにより、判定装置１００は、権限情報が委譲された同行者端末３０が、真に同行者によって所有されている端末であることを検証したうえで、委譲した権限情報の行使を許可することができるので、さらに権限情報の委譲に関する安全性、信頼性を向上させることができる。
【０１６４】
〔７−８．サービスの種別〕
上記実施形態では、サービスサーバ５０が提供するサービスとして、コンサートのチケット販売に係るサービスを例に挙げた。しかし、上記実施形態で説明した処理は、コンサートのチケット販売等以外のサービスにも適用可能である。例えば、判定装置１００は、既存の顧客からの紹介でしか店舗の利用を認めない、いわゆる一見さんお断りの店舗利用等に、上記実施形態で説明した判定処理を適用可能である。店舗側は、通常では、既存の顧客が紹介してきた新規の客が真に信頼できる客であるかを検証することは難しい。しかし、判定装置１００によれば、既存の顧客と新規の客との関係性を判定することが可能となるため、店舗側は、新規の客が信頼に足る客であるか否かを判定したうえで店舗の利用を許可することができる。
【０１６５】
〔７−９．トラストリスト〕
上記実施形態では、判定装置１００が、購入者からの要求に従って同行者の信頼性を判定するため、トラストリストを利用する例を説明した。ここで、判定装置１００は、購入者からの要求に従って同行者の信頼性を判定したトラストリストに含まれる情報をサービス側に提供してもよい。
【０１６６】
例えば、判定装置１００は、購入者からの要求に従ってトラストリストを参照し、購入者にとって信頼性を有する同行者（例えば、同行者が利用する端末装置の識別情報）を抽出する。そして、判定装置１００は、抽出した同行者の識別情報をサービス側に提供する。
【０１６７】
サービス側は、判定装置１００から提供された情報に基づいて、同行者の信頼性を判定する。例えば、サービス側は、同行者から提示された同行者端末３０が、判定装置１００から提供された情報に含まれるか否かに基づいて、同行者の信頼性を判定する。サービス側は、予め判定装置１００からトラストリストの情報の提供を受けておくことで、例えば同行者が購入者から遅れて到着した場合に、購入者が手続に関与せずとも、同行者の信頼性を判定することができる。かかる構成によれば、サービス側は、事前に、購入者に対して信頼のある同行者の情報を全て取得しておくことができるため、会場での処理を簡素にしたり、遅れて到着する同行者に対しても問題なく信頼性の確認処理を行えたりするため、サービスにおけるユーザビリティを向上させることができる。
【０１６８】
また、上記実施形態では、トラストリストに、同行者端末３０のように具体的な第２端末の識別情報が含まれる例を示した。しかし、トラストリストは、第２端末の識別情報を含むのではなく、第１端末とどのような関係性のある第２端末を信頼するか、といった、例えばトラストなコンテキストとして判定されるための条件等が含まれるものであってもよい。すなわち、トラストリストは、必ずしも第２端末の識別情報を含むのではなく、どのような条件を満たす第２端末がトラストな関係にあるかといった情報を包括的に含むものであってもよい。
【０１６９】
〔７−１０．トラストポリシー〕
上記実施形態では、トラストポリシーをサービス側が有する例を示した。ここで、サービス側が有するトラストポリシーは、必ずしも全てのユーザに共通するものではなく、例えばユーザごとに異なる情報が含まれるものであってもよい。例えば、トラストポリシーは、過去に同行者としてサービスを提供したユーザを信頼する、といった基準を有していてもよい。この場合、同じサービス提供者が過去に提供したサービスを利用したユーザと、はじめてサービスの提供を受けるユーザとでは、適用されるトラストポリシーが異なることになる。このように、トラストポリシーは、全てのユーザに共通した基準を適用するのではなく、例えばユーザの過去のサービス利用の有無など、画一的に判定されない事柄を判定基準として含んでもよい。
【０１７０】
〔８．ハードウェア構成〕
上述してきた実施形態に係るユーザ端末１０や、サービスサーバ５０や、判定装置１００は、例えば図１４に示すような構成のコンピュータ１０００によって実現される。以下、判定装置１００を例に挙げて説明する。図１４は、判定装置１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。
【０１７１】
ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に記憶されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を記憶する。
【０１７２】
ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（実施形態に係るネットワークに対応）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを、通信網５００を介して他の機器へ送信する。
【０１７３】
ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。
【０１７４】
メディアインターフェイス１７００は、記録媒体１８００に記憶されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital  Versatile  Disc）、ＰＤ（Phase  change  rewritable  Disk）等の光学記録媒体、ＭＯ（Magneto-Optical  disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
【０１７５】
例えば、コンピュータ１０００が実施形態に係る判定装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内のデータが記憶される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から通信網５００を介してこれらのプログラムを取得してもよい。
【０１７６】
〔９．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【０１７７】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図４に示した第１取得部１３１と、第２取得部１３３とは統合されてもよい。また、例えば、記憶部１２０に記憶される情報は、ネットワークを介して、外部に備えられた記憶装置に記憶されてもよい。
【０１７８】
また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【０１７９】
〔１０．効果〕
上述してきたように、実施形態に係る判定装置１００は、第１取得部１３１と、第２取得部１３３と、判定部１３４とを有する。第１取得部１３１は、第１端末を利用するユーザである第１ユーザが提供を受けようとするサービスに関する権限情報、及び、第１端末に関する利用状況を取得する。第２取得部１３３は、権限情報の委譲を許可するための条件であって、第１ユーザと権限情報が委譲される委譲先との関係性を示した条件を取得する。判定部１３４は、第１取得部１３１によって取得された利用状況に基づいて、第１ユーザと、第１ユーザが権限情報を委譲しようとするユーザである第２ユーザとの関係性が条件を満たすか否かを判定する。
【０１８０】
このように、実施形態に係る判定装置１００は、第１ユーザの日常的な利用状況を取得し、取得した利用状況に基づいて、第１ユーザと第２ユーザとの関係性がサービス側の条件を満たすか否かを判定する。これにより、第１ユーザに同行する第２ユーザは、事前に特別な対応を行わずとも、日常の第１ユーザとの関係に基づいて、自身の信頼性をサービス側に提示することができる。このように、判定装置１００は、事前に認証情報が記憶されていないユーザの信頼性の判定等、オンラインで管理される情報を種々の状況に応じて活用することができる。
【０１８１】
また、実施形態に係る判定装置１００は、第１取得部１３１によって取得された利用状況に基づいて、第２ユーザの候補となりうるユーザである候補ユーザが抽出されたリストであって、候補ユーザとして抽出される根拠を示す情報が含まれるリスト（トラストリスト）を生成する生成部１３２をさらに備える。判定部１３４は、第２取得部１３３によって取得された条件と、生成部１３２によって生成されたリストが含む情報とを照合することにより、候補ユーザのうち第２ユーザとしての条件を満たす候補ユーザを判定する。
【０１８２】
このように、実施形態に係る判定装置１００は、第１ユーザの日常的な利用状況に基づいて、第１ユーザにとって信頼に足るユーザを候補ユーザとして抽出したリストを生成する。そして、判定装置１００は、判定処理の際に、サービス側から提示された条件と、リストに含まれる情報とを照合することにより、条件を満たす第２ユーザを精度よく抽出することができる。
【０１８３】
また、第２取得部１３３は、第１端末と第２ユーザが利用する第２端末とが所定時間以上近接した履歴があることを条件として取得する。判定部１３４は、リストにおいて、第１端末と、候補ユーザが利用する端末とが所定時間以上近接した履歴を含むことを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、候補ユーザが条件を満たすと判定する。
【０１８４】
このように、実施形態に係る判定装置１００は、第１端末と第２端末との近接を根拠として、第２ユーザの信頼性を判定する。一般に、所定時間以上、近接した関係性を有するユーザ同士は友人や知人であると推定されるので、判定装置１００は、かかる利用状況に基づいて、信頼に足る第２ユーザを的確に判定することができる。
【０１８５】
また、生成部１３２は、利用状況として、第１端末と候補ユーザが利用する端末とが近距離無線通信もしくは有線通信を行った履歴、又は、第１端末と候補ユーザが利用する端末とが同じアクセスポイントを利用した履歴に基づいてリストを生成する。判定部１３４は、リストにおいて、第１端末と候補ユーザが利用する端末とが近距離無線通信もしくは有線通信を行った履歴、又は、第１端末と候補ユーザが利用する端末とが同じアクセスポイントを利用した履歴を含むことを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、候補ユーザが条件を満たすと判定する。
【０１８６】
このように、実施形態に係る判定装置１００は、通信の種別等に応じて、第１端末と第２端末とが近接したか否かを判定する。すなわち、判定装置１００は、第１端末と頻繁に通信を行っている端末の所有者を第２ユーザとして判定するため、精度よく第２ユーザを判定することができる。
【０１８７】
また、第２取得部１３３は、第１ユーザと第２ユーザとが所定回数以上、同一又は類似する行動を行ったことを示す行動履歴があることを条件として取得する。判定部１３４は、リストにおいて、第１ユーザと候補ユーザとが所定回数以上、同一又は類似する行動を行ったことを示す行動履歴を含むことを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、候補ユーザが条件を満たすと判定する。
【０１８８】
このように、実施形態に係る判定装置１００は、同じような行動履歴を有することを根拠として、第２ユーザの信頼性を判定する。一般に、同じような行動履歴を有するユーザ同士は友人や知人であると推定されるので、判定装置１００は、かかる利用状況に基づいて、信頼に足る第２ユーザを的確に判定することができる。
【０１８９】
また、生成部１３２は、利用状況として、第１ユーザが所定サービスを利用した履歴と、第１ユーザが所定サービスを利用した所定時間内に候補ユーザが所定サービスを利用した履歴とに基づいてリストを生成する。判定部１３４は、リストにおいて、第１ユーザが所定サービスを利用した履歴と、第１ユーザが所定サービスを利用した所定時間内に候補ユーザが所定サービスを利用した履歴とを含むことを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、候補ユーザが条件を満たすと判定する。
【０１９０】
このように、実施形態に係る判定装置１００は、所定サービスを同じ時間帯に利用したか否かに応じて、第１ユーザと第２ユーザとが同じ行動履歴を有するか否かを判定する。すなわち、判定装置１００は、第１ユーザと第２ユーザとが共に過ごしているなどの日常の行動に基づいて第１ユーザと第２ユーザの関係性を判定するので、精度よく両者の関係性を判定することができる。なお、この場合の所定サービスとは、例えば、小売店や、飲食店などであって、ＮＦＣ規格の決済に対応した店舗等が該当する。
【０１９１】
また、第２取得部１３３は、第１ユーザが利用するＳＮＳにおいて第２ユーザとのつながりを有することを示す履歴が含まれることを条件として取得する。判定部１３４は、リストにおいて、第１ユーザが利用するＳＮＳにおいて候補ユーザとつながりを有することを示す履歴が含まれることを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、候補ユーザが条件を満たすと判定する。
【０１９２】
このように、実施形態に係る判定装置１００は、ＳＮＳの利用状況に基づいて第１ユーザと第２ユーザとの関係性を判定するなど、種々の情報を利用した、柔軟な判定処理を実行することができる。
【０１９３】
また、第２取得部１３３は、第１ユーザが利用する画像共有サービスにおいて第２ユーザが撮像された画像を共有していることを示す履歴が含まれることを条件として取得する。判定部１３４は、リストにおいて、第１ユーザが利用する画像共有サービスにおいて候補ユーザが撮像された画像を共有していることを示す履歴が含まれることを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、候補ユーザが条件を満たすと判定する。
【０１９４】
このように、実施形態に係る判定装置１００は、画像共有サービスなどの利用状況に基づいて第１ユーザと第２ユーザとの関係性を判定するなど、種々の情報を利用した、柔軟な判定処理を実行することができる。
【０１９５】
また、第２取得部１３３は、第１ユーザが利用するネットワーク上のカレンダーサービスにおいて第２ユーザと同じ予定を共有することを示す履歴が含まれることを条件として取得する。判定部１３４は、リストにおいて、第１ユーザが利用するネットワーク上のカレンダーサービスにおいて候補ユーザと同じ予定を共有することを示す履歴が含まれることを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、候補ユーザが条件を満たすと判定する。
【０１９６】
このように、実施形態に係る判定装置１００は、例えばクラウド上のスケジュール共有サービスなどの利用状況に基づいて第１ユーザと第２ユーザとの関係性を判定するなど、種々の情報を利用した、柔軟な判定処理を実行することができる。
【０１９７】
また、第２取得部１３３は、第１ユーザと第２ユーザとが所定時間以上、同行した履歴があることを条件として取得する。判定部１３４は、リストにおいて、第１ユーザと候補ユーザとが所定時間以上、歩行動作において共起した履歴が含まれることを根拠として第１ユーザと関係性を有する候補ユーザが特定される場合に、候補ユーザが条件を満たすと判定する。
【０１９８】
このように、実施形態に係る判定装置１００は、歩行の共起情報など、第１ユーザと第２ユーザとが共に行動をしていることを示す履歴に基づくことで、第１ユーザと第２ユーザとの関係性を多様な観点から判定することができる。
【０１９９】
また、第２取得部１３３は、サービス提供側によって第１ユーザが権限情報を有する本人であることが確認された旨を示す情報を取得する。判定部１３４は、第２取得部１３３によって第１ユーザが権限情報を有する本人であることが確認された旨を示す情報が取得されたことを契機として、第１ユーザと第２ユーザとの関係性が条件を満たすか否かを判定する。
【０２００】
このように、実施形態に係る判定装置１００は、第１ユーザの本人確認が行われたあとで、第１ユーザと第２ユーザの関係性が条件を満たすか否かの判定処理を行うことで、無駄な判定処理が発生することを防止し、情報処理の負荷の軽減を図ることができる。
【０２０１】
また、判定部１３４は、第１ユーザと第２ユーザとの関係性が条件を満たすか否かを判定する場合に、サービス提供側によって第１ユーザが権限情報を有する本人であることが確認されているか否かを判定し、確認されていない場合には、第１ユーザが権限情報を有する本人であることがサービス提供側によって確認された旨を示す情報の提示をサービス提供側に要求する。
【０２０２】
このように、実施形態に係る判定装置１００は、第１ユーザと第２ユーザの関係性が条件を満たすか否かの判定処理を行う場合に、第１ユーザの本人確認が確実に行われたか否かをさらに判定し、第１ユーザの本人確認が確実に行われたと判定されない場合に、第１ユーザが本人であると確認したという情報の送信をサービス側に要求してもよい。これにより、判定装置１００は、無駄な判定処理が発生することを防止し、情報処理の負荷の軽減を図ることができる。
【０２０３】
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【０２０４】
また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、生成部は、生成手段や生成回路に読み替えることができる。
【符号の説明】
【０２０５】
１  判定システム
１０  ユーザ端末
２０  購入者端末
３０  同行者端末
５０  サービスサーバ
１００  判定装置
１１０  通信部
１２０  記憶部
１２１  利用状況記憶部
１２２  通信先記憶部
１２３  トラストリスト記憶部
１３０  制御部
１３１  第１取得部
１３２  生成部
１３３  第２取得部
１３４  判定部
１３５  送信部
【図１】
2019057011.tif 000003
【図２】
2019057011.tif 000004
【図３】
2019057011.tif 000005
【図４】
2019057011.tif 000006
【図５】
2019057011.tif 000007
【図６】
2019057011.tif 000008
【図７】
2019057011.tif 000009
【図８】
2019057011.tif 000010
【図９】
2019057011.tif 000011
【図１０】
2019057011.tif 000012
【図１１】
2019057011.tif 000013
【図１２】
2019057011.tif 000014
【図１３】
2019057011.tif 000015
【図１４】
2019057011.tif 000016