(57)【要約】【課題】リソースの所有者のリソースに対するアクセスを制御する方法を提供する。【解決手段】所有者は、リソース・コンピュータ・システムのユーザでよい。アクセス制御は、ソーシャル・ネットワーキング・システムのソーシャル・ネットワーク・データに基づくものでよい。アクセス制御はまた、所有者に関する所有者トークン、リソースに対するアクセスを要求する要求側に関する要求側トークン、およびアクセス制御ポリシーに基づくものでよい。所有者トークンおよび要求側トークンをソーシャル・ネットワーキング・システムによって受信し、所有者トークンおよび要求側トークンの内容に基づいて、リソースに対するアクセスを許可すべきかどうかをソーシャル・ネットワーキング・システムによって判定することができる。所有者のソーシャル・ネットワーク識別および要求側のソーシャル・ネットワーク識別は、ソーシャル・ネットワーク・システムのみによって判定可能でよい。【選択図】図２
2017504855.tif 000002
【特許請求の範囲】
【請求項１】
リソース（３０８）の所有者の前記リソース（３０８）に対するアクセスを制御する方法（１００）であって、前記所有者がリソース・コンピュータ・システム（３１２）のユーザであり、前記アクセス制御が、ソーシャル・ネットワーキング・システム（２０２）のデータに基づき、
前記アクセス制御が、前記所有者に関する所有者トークン（３１４）、前記リソースに対するアクセスを要求する要求側に関する要求側トークン、およびアクセス制御ポリシーに基づき、
リソース所有者識別（３１０ｓ）および前記アクセス制御ポリシーが前記所有者トークン（３１４）内に符号化され、前記リソース要求側識別が前記要求側トークン内に符号化され、前記所有者トークン（３１４）および前記要求側トークンが、前記ソーシャル・ネットワーキング・システム（２０２）によって受信され、前記所有者トークン（３１４）および前記要求側トークンの内容に基づいて、リソース・コンピュータ・システム上の前記リソース（３０８）に対するアクセスを許可すべきかどうかが前記ソーシャル・ネットワーキング・システムによって判定される、方法（１００）。
【請求項２】
前記アクセス制御ポリシーが前記ソーシャル・ネットワーキング・システム（２０２）のみによって判定可能である、請求項１に記載の方法（１００）。
【請求項３】
前記所有者トークン（３１４）が、前記リソース・コンピュータ・システム（２０４）上の前記リソース（３０８）に関係付けられる、請求項１または２に記載の方法（１００）。
【請求項４】
前記所有者トークン（３１４）および前記要求側トークンから前記ソーシャル・ネットワーキング・システム（２０２）内の所有者識別（３１０ｓ）および要求側識別（３１２ｓ）を求めるステップと、
前記所有者トークン（３１４）が関連するアクセス制御ポリシーを求めるステップと、
前記ソーシャル・ネットワーキング・システム（２０２）内の前記所有者識別（３１４）または前記要求側識別（３１２ｓ）あるいはその両方に基づいて前記アクセス制御ポリシーを評価するステップと、
前記ソーシャル・ネットワーキング・システム（２０２）から前記リソース・コンピュータ・システム（２０４）に前記評価の結果を送るステップ（４１２）と
をさらに含む、請求項１ないし３のいずれかに記載の方法（１００）。
【請求項５】
前記所有者トークン（３１４）および前記要求側トークンがグループ署名を含み、関連する署名グループが前記ソーシャル・ネットワーキング・システム（２０２）によって管理される、請求項１ないし４のいずれかに記載の方法（１００）。
【請求項６】
所有者システム（３１０）または要求側システム（３１２）あるいはその両方によって、前記ソーシャル・ネットワーキング・システム（２０２）に関係するユーザ特有の秘密グループ署名鍵（３１６、３１８）を取得するステップ
をさらに含む、請求項５に記載の方法（１００）。
【請求項７】
前記所有者トークン（３１４）または前記要求側トークンあるいはその両方の中に含まれる前記グループ署名が、前記所有者または前記要求側あるいはその両方の前記秘密グループ署名鍵の下で、メッセージに署名した結果である、請求項６に記載の方法（１００）。
【請求項８】
所有者トークン（３１４）で署名された前記メッセージが、プレーン・テキストまたは暗号化形式の前記アクセス制御ポリシーを含む、請求項７に記載の方法（１００）。
【請求項９】
前記所有者トークン（３１４）または前記要求側トークンあるいはその両方が、ＯＡｕｔｈ許可フレームワークに基づくＯＡｕｔｈアクセス・トークンを含む、請求項１ないし４のいずれかに記載の方法（１００）。
【請求項１０】
前記ソーシャル・ネットワーキング・システム（２０２）が、前記所有者トークン（３１４）または前記要求側トークンあるいはその両方についての許可サーバとして働き、前記ソーシャル・ネットワーキング・システム（２０２）が、前記所有者トークン（３１４）を前記所有者識別（３１０ｓ）および前記アクセス制御ポリシーと共に格納し、または前記要求側トークンを前記要求側識別（３１２ｓ）と共に格納し、あるいはその両方を行う、請求項９に記載の方法（１００）。
【請求項１１】
リソース（３０８）の所有者の前記リソースに対するアクセスを制御するアクセス制御システムであって、リソース・コンピュータ・システム（３０８）を備え、前記所有者が、リソース・コンピュータ・システム（２０２）およびソーシャル・ネットワーキング・システム（２０２）のユーザであり、前記ソーシャル・ネットワーキング・システム（２０２）が、ソーシャル・ネットワーク・データを格納するストレージを備え、前記リソース（３０８）に対するアクセスが、前記ソーシャル・ネットワーキング・システム（２０２）の前記ストレージ内に格納されたデータに基づき、
前記アクセス制御システムの前記アクセス制御が、前記リソース・コンピュータ・システムのメモリ内に格納された所有者トークン（３１４）に基づき、所有者システム（３１０）に関する前記所有者トークン（３１４）、前記リソース（３０８）に対するアクセスを要求する要求側システム（３１２）に関する要求側トークン、およびアクセス制御ポリシーが、前記リソース・コンピュータ・システム（２０４）のメモリ内に前記所有者トークン（３１４）の部分として格納され、
前記アクセス制御ポリシーに加えて、リソース所有者識別（３１０ｓ）が前記所有者トークン（３１４）内に符号化され、前記リソース要求側識別が前記要求側トークン内に符号化され、前記所有者トークン（３１４）および前記要求側トークンが、前記リソース・コンピュータ・システム（２０４）から前記ソーシャル・ネットワーキング・システム（２０２）に送られ、前記所有者トークン（３１４）および前記要求側トークンの内容に基づいて、前記リソース（３０８）に対するアクセスを許可すべきかどうかが判定される、アクセス制御システム。
【請求項１２】
プログラム命令を格納するコンピュータ可読記憶媒体を含むコンピュータ・プログラム製品であって、前記プログラム命令が、前記ソーシャル・ネットワーキング・システム（２０２）のプロセッサおよび前記リソース・コンピュータ・システム（２０４）のプロセッサによって部分的に実行されるとき、請求項１ないし１０のいずれかに記載の方法を実施する、コンピュータ・プログラム製品。
【請求項１３】
請求項１ないし１０のいずれかに記載の方法を実施するソフトウェア・コード部分を含む、データ処理システムで実行するためのデータ処理プログラムであって、前記プログラムが、前記ソーシャル・ネットワーキング・システム（２０２）および前記リソース・コンピュータ・システム（２０４）のプロセッサ上で部分的に実行される、データ処理プログラム。
【請求項１４】
ソーシャル・ネットワーク・データを格納するストレージを備えるソーシャル・ネットワーキング・システム（２０２）であって、
リソース・コンピュータ・システムのリソースの所有者についての秘密グループ署名鍵を生成し、
前記リソース（３０８）に対する要求側についての秘密グループ署名鍵を生成し、
前記リソース・コンピュータ・システムから所有者トークン（３１４）および要求側トークンを受信し、前記所有者トークン（３１４）および前記要求側トークンの内容に基づいて、前記リソース（３０８）に対するアクセスを許可すべきかどうかを判定するように構成され、アクセス制御ポリシーが前記所有者トークン（３１４）内に符号化され、前記アクセス制御ポリシーに加えて、リソース所有者識別（３１０ｓ）が前記所有者トークン（３１４）内に符号化され、リソース要求側識別が前記要求側トークン内に符号化される、ソーシャル・ネットワーキング・システム（２０２）。
【請求項１５】
前記リソース（３０８）に対するアクセスを許可すべきかどうかの前記判定に基づいて、前記リソース・コンピュータ・システムにアクセス許可信号を送る
ように構成される、請求項１４に記載のソーシャル・ネットワーキング・システム（２０２）。
【請求項１６】
リソース（３０８）の所有者の前記リソース（３０８）に対するアクセスを制御する方法であって、前記所有者がリソース・コンピュータ・システム（３１２）のユーザであり、前記アクセス制御が、ソーシャル・ネットワーキング・システム（２０２）のデータに基づき、前記方法が、
リソース・コンピュータ・システムのリソースの所有者についての秘密グループ署名鍵を生成するステップと、
前記リソース（３０８）に対する要求側についての秘密グループ署名鍵を生成するステップと、
前記リソース・コンピュータ・システムから所有者トークン（３１４）および要求側トークンを受信し、前記所有者トークン（３１４）および前記要求側トークンの内容に基づいて、前記リソース（３０８）に対するアクセスを許可すべきかどうかを判定するステップとを含み、アクセス制御ポリシーが前記所有者トークン（３１４）内に符号化され、
前記アクセス制御ポリシーに加えて、リソース所有者識別（３１０ｓ）が所有者トークン（３１４）内に符号化され、リソース要求側識別が前記要求側トークン内に符号化される、方法。
【請求項１７】
前記リソース（３０８）に対するアクセスを許可すべきかどうかの前記判定に基づいて、前記リソース・コンピュータ・システムにアクセス許可信号を送るステップ
をさらに含む、請求項１６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にはリソースへのアクセスを制御する方法に関する。本発明はさらに、リソースの所有者のリソースへのアクセスを制御するためのアクセス制御システム、データ処理プログラム、およびコンピュータ・プログラム製品に関する。
【背景技術】
【０００２】
今日の社会での多くの個人は、フェイスブック、リンクトイン、フォースクエア、フリッカー、ツイッターなどの１つまたは複数のソーシャル・ネットワーキング・システム（ＳＮＳ）内にプロファイルを維持している。そのようなＳＮＳは、ＳＮＳのユーザが同一のＳＮＳの他のユーザと個人的な友達関係または職業上の関係を確立および維持することを可能にする。多くのＳＮＳはまた、一定のプロファイル・データへのアクセスを特定のグループまたはサブグループのメンバに制限するように、ユーザがユーザの友達を友達グループ、たとえば最良の友達、職場の同僚、家族などに分割することを可能にする。友達関係およびグループを含む、ＳＮＳプロファイルの確立および保守は、継続的で非常に時間のかかるプロセスであり、ユーザが維持する友達が多くなるほど強くなるロックイン効果も伴う。同時に、多数の競合するＳＮＳが存在し、通常は、単一のＳＮＳ内ですべての関係を管理することができるわけではないことがある。したがって、ＳＮＳのユーザは、異なるＳＮＳ内の関係を維持することを強いられることがある。
【０００３】
しかし、あるＳＮＳ内の関係の、別のＳＮＳでのプライバシーを保持する再利用は可能ではない。さらに、この文脈での主な問題は、ＳＮＳ内で定義される友達関係およびグループを、マルチユーザ・コンピューティング・システムのような別のコンピュータ・システム内、別のＳＮＳ内などの、このＳＮＳの外部のアクセス制御のためにユーザが利用できないことである。
【０００４】
たとえば、多数の注意深く選択された友達ならびにいくつかのよく維持される友達グループを有する、たとえばフェイスブックまたはフリッカーのプロファイルを有するアリスというユーザを考える。アリスが、たとえばフォースクエア（フォースクエアでは、ユーザが、チェックインを介して、たとえばバー、レストラン、店などの場所でのユーザの物理的存在を示すことができる）などの別のＳＮＳに加入するとき、アリスは、自分のフェイスブックの友達、または自分のフェイスブックの友達グループのうちの１つのメンバだけが、自分の（プライバシーに敏感な）フォースクエア・チェックインにアクセスすることを望むことがある。しかし、現在のＳＮＳは、そのような種類のアクセス制御を可能にせず、ＳＮＳ内部プロファイル・データ、すなわちそのプロファイル・データ・アクセスが制御される各ＳＮＳ内にあるＳＮＳプロファイル・データに基づくアクセス制御規則を可能にするだけである。上記の例では、このアクセス制御問題に対する従来の技術的に実現可能な解決策は、たとえば、フォースクエアがアリスのフェイスブックの友達に照会することを可能にすることとなる。フェイスブックおよびフォースクエア上にプロファイルを有するボブというユーザを考えると、フォースクエアに対するボブのログイン時に、フォースクエアがアリスの現在のフェイスブックの友達リストを取り出し、ボブがアリスのフェイスブックの友達であるかどうかを判定する。しかし、そのような従来の解決策の一欠点は、フォースクエアがアリスのすべてのフェイスブックの友達を学習することであり、それによってアリスのプライバシーが損なわれる。
【０００５】
さらに、そもそもそのような解決策を可能にするためには、フォースクエアおよびそのプロバイダが（ａ）誰のフェイスブック・ユーザの友達に照会するかを知り、（ｂ）アリスの友達リスト内のボブを認識することができるように、アリスとボブが共に、自分のフェイスブック識別（たとえば、自分のフェイスブック・ユーザ名）をフォースクエアに知らせることが必要となる。この識別開示は、従来の解決策の別の欠点である。
【０００６】
関連技術が、たとえばＷＯ２０１１／１４０２６３Ａ１号に開示されている。本文書では、ソーシャル・ネットワーク、職業的ネットワーク、ならびにコンテンツ共有およびパブリック・サイト（public sight）を含むソーシャル・グラフに関連し、またはソーシャル・グラフから導出される情報へのアクセスおよび接続を実現する方法およびシステムが開示される。
【０００７】
ＷＯ２０１２／０８９００７Ａ１号では、マルチ・プラットフォーム環境内のユーザのグループに対する共有コンテンツを実現するシステムが開示されている。このシステムは、デジタル・コンテンツ項目を各プラットフォームにわたって利用可能にすることを可能にする。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】ＷＯ２０１１／１４０２６３Ａ１号
【特許文献２】ＷＯ２０１２／０８９００７Ａ１号
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、たとえばコンピュータ・システム上で専用アクセス制御システムを使用する必要なしに、コンピュータ・システム上のよりインテリジェントなアクセス・リソースが求められている。
【課題を解決するための手段】
【００１０】
この必要は、独立請求項による、リソースに対するアクセスを制御する方法、リソースの所有者のリソースに対するアクセスを制御するアクセス制御システム、データ処理プログラム、およびコンピュータ・プログラム製品によって対処することができる。
【００１１】
本発明の一態様の一実施形態によれば、リソースに対するアクセスを制御する方法を提供することができる。リソースは、リソースの所有者のリソースでよい。所有者は、リソース・コンピュータ・システムのユーザでよく、アクセスは、ソーシャル・ネットワーキング・システムのデータに基づくものでよい。アクセス制御はまた、所有者に関する所有者トークン、リソースに対するアクセスを要求する要求側に関する要求側トークン、およびアクセス制御ポリシーに基づくものでよい。
【００１２】
さらに、リソース所有者識別およびアクセス制御ポリシーを所有者トークン内に符号化することができ、リソース要求側識別を要求側トークン内に符号化することができる。所有者トークンおよび要求側トークンをソーシャル・ネットワーキング・システムによって受信して、所有者トークンおよび要求側トークンの内容に基づいて、（具体的には要求側による）リソース・コンピュータ上のリソースに対するアクセスを許可することがきるかどうかをソーシャル・ネットワーキング・システムによって判定することができる。
【００１３】
本発明の別の態様の一実施形態によれば、リソースの所有者のリソースに対するアクセスを制御するアクセス制御システムを提供することができる。所有者は、リソース・コンピュータ・システムのユーザでよい。アクセスは、ソーシャル・ネットワーキング・システムのデータに基づくものでよく、アクセス制御はまた、所有者に関する所有者トークン、リソースに対するアクセスを要求する要求側に関する要求側トークン、およびアクセス制御ポリシーに基づくものでよい。
【００１４】
アクセス制御ポリシーに加えて、リソース所有者識別を所有者トークン内に符号化することができる。リソース要求側識別を要求側トークン内に符号化することができる。所有者トークンおよび要求側トークンをリソース・コンピュータ・システムからソーシャル・ネットワーキング・システムに送り、所有者トークンおよび要求側トークンの内容に基づいて、リソースに対するアクセスを許可すべきかどうかを判定することができる。
【００１５】
このようにして、ソーシャル・ネットワーキング・システム上の所有者および要求側のプライバシー、具体的には所有者および要求側のソーシャル・ネットワーク識別を保持することができる。これらの識別は、ソーシャル・ネットワーキング・システムのみによって判定可能であるからである。
【００１６】
本発明の別の態様の一実施形態によれば、ソーシャル・ネットワーク・データを格納するストレージを備えるソーシャル・ネットワーキング・システムが提供され、ソーシャル・ネットワーキング・システムは、
リソース・コンピュータ・システムのリソースの所有者についての秘密グループ署名鍵を生成し、
リソースに対する要求側についての秘密グループ署名鍵を生成し、
リソース・コンピュータ・システムから所有者トークンおよび要求側トークンを受信し、所有者トークンおよび要求側トークンの内容に基づいて、リソースに対するアクセスを許可すべきかどうかを判定するように構成され、アクセス制御ポリシーが所有者トークン内に符号化され、アクセス制御ポリシーに加えて、リソース所有者識別が所有者トークン内に符号化され、リソース要求側識別が要求側トークン内に符号化される。
【００１７】
本発明の別の態様の一実施形態によれば、リソースの所有者のリソースに対するアクセスを制御する方法が提供され、所有者がリソース・コンピュータ・システムのユーザであり、アクセス制御が、ソーシャル・ネットワーキング・システムのデータに基づき、方法は、ソーシャル・ネットワーキング・システムで、
リソース・コンピュータ・システムのリソースの所有者についての秘密グループ署名鍵を生成するステップと、
リソース（３０８）に対する要求側についての秘密グループ署名鍵を生成するステップと、
リソース・コンピュータ・システムから所有者トークン（３１４）および要求側トークンを受信し、所有者トークン（３１４）および要求側トークンの内容に基づいて、リソース（３０８）に対するアクセスを許可すべきかどうかを判定するステップとを含み、アクセス制御ポリシーが所有者トークン（３１４）内に符号化され、
アクセス制御ポリシーに加えて、リソース所有者識別（３１０ｓ）が所有者トークン（３１４）内に符号化され、リソース要求側識別が要求側トークン内に符号化される。
【００１８】
この説明の文脈では、以下の規約、用語、または表現、あるいはそれらの組合せが使用されることがある。
【００１９】
「アクセス制御」という用語は、リソース、たとえばコンピュータ・システム内のファイル、インターネット上のページを指定するのに使用されるＵＲＬ（Universal Resource Locator）などに対するアクセスの選択的制限を表すことがある。アクセスする動作は、特定のリソースを消費すること、特定のリソースに入ること、または特定のリソースを使用すること、具体的には、読み取ること、例外として、更新すること、書き込むこと、および削除することをも意味することがある。いくつかのケースでは、部屋、建物、車、ストレージ・システムなどのような、物理的デバイスを保護するためのロックに対する物理的アクセスをも意味することがある。通常、リソースに対するアクセスの許可のためにｕｓｅｒ＿ＩＤまたはパスポートあるいはその両方が必要となることがある。
【００２０】
「ソーシャル・ネットワーキング・システム」（ＳＮＳ）という用語は、現実生活の関心、活動、背景の共有などを行う登録ユーザ間のソーシャル関係、たとえば仕事関連のつながりのソーシャル・ネットワークを可能にし、定義し、維持するインターネット・プラットフォームに基づいてソーシャル・ネットワーキング・サービスを配信するシステムを表すことがある。ソーシャル・ネットワーキング・サービスは、ユーザの電子、ウェブ、およびブラウザ・ベースの表現（ユーザ・プロファイルまたは識別）、他のユーザに対するユーザのソーシャル・リンク、および様々な追加のサービスからなることがある。ソーシャル・ネットワーキング・サービス、または略してＳＮＳは、１つまたは複数のコンピュータ・システム上で実行することができる。今日の周知のソーシャル・ネットワーキング・システムの例として、ほんの数例であるが、フェイスブック、リンクトイン、エクシング、グーグル＋、ツイッター、フリッカー、フォースクエアを挙げることができる。
【００２１】
「リソース」という用語は通常、それに対するアクセスを選択的に許可する、たとえばパスワードによって保護することができるだけである、コンピュータ・システム内のリソース、たとえばファイル（たとえば、イメージ・ファイル、テキスト・ファイル、サウンド・ファイル、ビデオ・ファイルなど）、ディレクトリ、ＵＲＬ、または任意の他の情報構成要素を表すことがある。
【００２２】
「リソース・コンピュータ・システム」という用語は、リソース所有者、または単に所有者によって所有されるリソースを格納したコンピュータ・システムを表すことがある。リソース所有者は、リソース・コンピュータ・システムにリソースをアップロードしていることがあり、またはリソースを別の方式で制御することがある。本開示の文脈での「リソース」は、建物のドアへのアクセス、または任意の種類の物理的ロックへのアクセスのような物理的リソースでもよい。
【００２３】
「所有者」という用語は、個人、ユーザ、あるいは「その人の」リソースに対するアクセスを許可または制限するために使用可能にされる、個人、ユーザ、またはその電子的識別を表すことがある。この文脈では、「要求側」は、要求側によって「所有」されないリソースに対するアクセスを要求する個人またはその電子的識別を表すことがある。
【００２４】
「所有者トークン」という用語は、リソースの所有者に関係付けることのできる（任意選択で暗号化された）情報項目の組（tuple）を表すことがある。リソースは、ＳＮＳとは異なるシステム上に配置されることがある。この異なるシステムは、たとえば、第２のＳＮＳまたはリソース・コンピュータ・システムのような、別のマルチユーザ・システムでよい。
【００２５】
「要求側トークン」という用語は、要求側に関係付けることのできる（任意選択で暗号化された）情報項目の組を表すことがある。
【００２６】
「関係」という用語は、ＳＮＳの２人のユーザ間の定義済みの論理リンクを表すことがある。しかし、関係は、グループに対する定義済みのメンバシップのように、より抽象的に解釈されることもある。別のオプションは、たとえば、同一の都市に住むＳＮＳのすべてのユーザ、同一の定義済みのイベントを訪れたことのあるＳＮＳのすべてのユーザ、同一の年または同一の国で生まれたＳＮＳのすべてのユーザ、または同じ会社で働くＳＮＳのすべてのユーザなどのような、明示的に定義されないことのあるコミュニティに対するメンバシップでよい。
【００２７】
「アクセス・ポリシー」という用語は、誰、またはどのシステムがリソースにアクセスした可能性があるかを定義する制御を表すことがある。関係の定義に戻ると、定義済みの関係と共にＳＮＳ内の識別を定義したＳＮＳのユーザは、アクセス制御の１つの方式を定義することができる。２つの識別をたとえば「友達」としてリンクすることができる場合、関係を明示的に定義することができ、識別名による定義済みの友達は、所有者のリソースにアクセスすることができる。「すべての友達」による所有者のリソースに対するアクセスを可能にすることも可能であることがあり、リソースのユーザまたは所有者にリンクまたはネットワーク化される、リソースに対するアクセスを要求するすべてのエンティティに、リソースに対するアクセスを許可することができることを意味する。ユーザまたは所有者に対するリンクのない人には、アクセスが許可されないことがある。他方では、ＳＮＳ内の所有者識別と要求側識別が、たとえば、同一の故郷を有する、同一の会社で働いている、同一のパーティにいた、同一の年に生まれた、同一の趣味、またはＳＮＳ内に格納され、個人を特徴付ける任意の他の特徴を共有する、などの共通の特徴を共有するとき、要求側を表すシステムにアクセスを許可することもできる。
【００２８】
「プライバシー」という用語は、ＳＮＳのユーザに関するいくつかの特徴、またはユーザのプロファイル、またはユーザに関する他のデータ、たとえば実際の位置データを表すことがある。具体的には、プライバシーを保持することにより、ＳＮＳに登録されたどのユーザ識別が所有者または要求側トークンを作成したか、さらには所有者または要求側トークンが同一のユーザによって生成されたか、それとも異なるユーザによって生成されたかを、どのような要求側コンピュータ・システムも伝えることができないことを保証することができる。プライバシーを保持するために、所有者トークンが関係についての情報をリークする可能性がないことが必要となることがある。よりネイティブな観点からは、ＳＮＳからのプロファイリングまたは関係データを別のコンピュータ・システム、たとえば別のＳＮＳにエクスポートすることができない（別のＳＮＳが別のコンピュータ・システム上のリソースに対するアクセス制御のために第１のＳＮＳの関係情報を使用することができる場合であっても）。最後に、やはり経時的に、第１のＳＮＳに対する一連のアクセス制御関連の関係アクセスが行われた可能性がある場合であっても、別のコンピュータ・システムまたは別のＳＮＳは、その関係を学習することができない。
【００２９】
「グループ署名」という用語は、グループのメンバがグループの代わりにデジタル署名を使用してメッセージに匿名で署名する能力を表すことがある。デジタル署名は、デジタル・メッセージまたは文書の真正性を実証するための数学的スキームでよい。この概念は、Ｄａｖｉｄ  ＣｈａｕｍおよびＥｕｇｅｎｅ  ｖａｎ  Ｈｅｙｓｔによる概念に戻り、当業者によって一般に知られている。グループ署名概念は、グループ・メンバを編集することを担当し、元の署名者を明らかにすることのできるグループ・マネージャを常に必要とする。詳細を以下で論じる。
【００３０】
「ＯＡｕｔｈ許可フレームワーク」（具体的にはバージョン２．０以上）という用語は、サードパーティアプリケーションまたはユーザがＨＴＴＰサービスに対する限定されたアクセスを得るための許可フレームワークおよび課金を表すことがある。ＯＡｕｔｈは、オープン標準化フレームワークを有する。ＯＡｕｔｈは、クライアントが、異なるクライアントであることがあるリソース所有者の代わりに、リソースの一部にアクセスする方法を提供することができる。グループ署名のケースと同様に、ここでも、ユーザ名およびパスワードなどのユーザ証明を共有することはできない。詳細を以下で論じる。
【００３１】
「アクセス制御ポリシー」という用語は、定義済みの他のユーザまたはシステムによる所有者のリソースに対するアクセスを所有者が許可することのできる規則を定義することができる。
【００３２】
「所有者システム」を、リソースの所有者によって制御されるコンピュータ・システムと定義することができ、「要求側システム」を、リソースに対するアクセスを要求する要求側によって操作されるコンピュータ・システムと定義することができる。
【００３３】
リソースに対するアクセスを制御するための、提案される方法は、１対の利点をもたらすことができる。
【００３４】
アクセスを制御する方法を使用すると、関係データ、具体的には抽象的関係データの１つの（メイン）ＳＮＳへの集中化、およびリソース・コンピュータ・システム上に格納されたリソースに対するアクセス制御のために、これらの関係および他のＳＮＳを再利用することを可能にすることができる。したがって、プロファイル・データを複数のシステム内にではなく、単一のＳＮＳ内にのみ維持することができるので、関係の保守をずっと容易にすることができる。このことにより、新しいＳＮＳ内で再び関係を維持する必要がないので、ユーザが新しいＳＮＳに入ることの障壁を下げることができる。
【００３５】
アクセス制御ポリシーについての評価段階をメインＳＮＳ内のプロファイル・データによって表現することができるので、メインＳＮＳ内にプロファイル・データを維持することは、同時に、異なるＳＮＳ上のこれらのプロファイル・データに依存することがある制御アクセス許可、または単に別のコンピュータ・システム上のリソースに対するアクセスを維持することができる。すなわち、メインＳＮＳ上のより定義された関係、具体的には友達関係または友達グループまたは上記で論じたような他の関係は、すべての従属するＳＮＳまたはすべての他の従属するコンピュータ・システム、たとえばリソース・コンピュータ・システムのアクセス許可に関する即時または瞬間的効果を有することができる。
【００３６】
このことにより、既存の関係を再利用することができるため、新しく加入したＳＮＳでの関係の再定義を不要にすることができるので、ＳＮＳ進入障壁を下げることができる。このことは、ＳＮＳおよびリソース・コンピュータ・システム内にアカウントを有するユーザに少なくとも適用することができる。
【００３７】
メインＳＮＳに対するこれらのアクセスを利用して、要求側ＳＮＳまたは他のリソース・コンピュータ・システムは、メインＳＮＳ内のプロファイル所有者の識別を知ることはできない。プライバシーは完全に保持される。別のコンピュータ・システム上のリソースを共有するために、良好なコミュニティ加入ＳＮＳに対して（他のユーザに対する関係を含む）プロファイル情報全体に対するアクセスを可能にすることにより、必要とされる関係の再確立、および新しく加入したＳＮＳ内のグループの潜在的な再定義を回避するためにプライバシーを断念することはもはや必要とされない。別のＳＮＳ内で確立された関係に基づいてプロファイル情報に対するアクセスを容易に制御することができるので、関係およびグループを再確立することの障害はもはやなく、したがってパーソナルプロファイル情報を公にする必要はもはやない。
【００３８】
様々な態様の下でプライバシーを保証することができる。リソース・コンピュータ・システムをサービス・プロバイダによって運用することができ、ＳＮＳがサービス・プロバイダＳＮによって運用される場合、以下のプライバシー要件を履行することができる。
【００３９】
匿名性：ＳＮに登録されたどのユーザ識別が所有者または要求側トークンを作成したか、さらには２つの所有者または要求側トークンが同一のユーザによって生成されたか、それとも異なるユーザによって生成されたかをＳＰが伝えることはできないことを保証することができる。所有者トークンがポリシーについての情報をＳＰに漏曳しないことを保証することができる。
【００４０】
リソース秘密：所有者トークン、要求側トークン、およびリンキング・トークンが、それについてのトークンが生成されたリソースｒｅｓについての情報をＳＮに漏曳しないことを保証することができる。
【００４１】
トークン非偽造可能性：不正なユーザがポリシーを満たさない場合、不正なユーザがアクセスを得ることができないことを保証することができる。同時に、不正なサービス・プロバイダＳＰがアクセス判断を行うために厳密に必要とされるものよりも多くのポリシー評価を実施することを防止することを本発明者らは望む。このことは、どんなリソースに対するアクセスも決して要求しなかったユーザに関するポリシーを評価するためにも、このポリシーが関連付けられるリソースに対するアクセスを決して要求しなかったユーザに関するポリシーを評価するためにも、ＳＰがリソース所有者によって作成されたポリシーを修正することができるべきではないことを意味する。技術的には、これらの制限はすべて、抽出アルゴリズムを通じて抽出されるときの正直なユーザを指し示す所有者および要求側トークンの非偽造可能性となる。
【００４２】
プロバイダ・セキュリティ：所有者トークン検証アルゴリズムを通過し、ＳＰが有効なリンキング・トークンを作成するために使用することのできるトークンを敵対者が生成することができず、それについては抽出が失敗することを保証することができる。
【００４３】
以下では、追加の拡張実施形態を説明する。
【００４４】
方法の一実施形態によれば、アクセス制御ポリシーはＳＮＳによって決定可能であるだけであることがある。リソース・コンピュータ・システムは、アクセス制御ポリシーを求めることができないことがある。これにより、所有者および要求側のプライバシーを保護することができる。リソース・コンピュータは、リソースの所有者と要求側との間の関係については何も「知る」ことはできない。
【００４５】
方法の拡張実施形態によれば、所有者トークンをリソース・コンピュータ・システム上のリソースに関係付けることができる。このことは、リソースおよび所有者トークンを共に格納することができること、またはリソース・コンピュータ・システムまたはそのストレージ上でリソースと所有者トークンとの間の少なくとも関係を確立することができることを示唆することができる。
【００４６】
方法の一実施形態はまた、具体的にはＳＮＳで、所有者トークンおよび要求側トークンからＳＮＳ内の所有者識別および要求側識別を求めること、（具体的には、グループ署名のケースでは、所有者トークンの部分としての、またはＯＡｕｔｈのケースでは、ＳＮＳ内に格納された）所有者トークンが関連するアクセス制御ポリシーを求めること、およびＳＮＳ内の所有者識別または要求側識別あるいはその両方に基づいてアクセス制御ポリシーを評価することをも含むことができる。この同一の実施形態はまた、評価の結果をＳＮＳからリソース・コンピュータ・システムに送ることをも含むことができる。このことは、リソースに対するアクセスを許可するか否かの標識または許可信号の形態で実施することができる。
【００４７】
方法の追加の実施形態によれば、所有者トークンおよび要求側トークンはグループ署名を含み、関連する署名グループがＳＮＳによって管理される。あるいは、ＳＮＳに対する関連する独立したシステムによってグループ署名を管理することができる。このようにして、所有者と要求側が、リソースの所有者と要求側との間のつながりを反映するグループとして互いにリンクされる。しかし、ＳＮＳの外部では、具体的にはリソース・コンピュータ・システム外では、グループは検出可能ではないことがある。
【００４８】
さらに、一実施形態では、方法は、所有者システムおよび要求側システムあるいはその両方によって、ＳＮＳに関係するユーザ特有の秘密グループ署名鍵を取得することを含むことができる。ＳＮＳのユーザは、所有者および要求側でよい。特有の秘密グループ署名鍵は、各ユーザについて個々のものでよい。ＳＮＳ内のユーザ・アカウントのセットアップ中に、特有の秘密グループ署名鍵を生成することができる。しかし、特有の秘密グループ署名鍵は、異なる後または前の時点に作成可能とすることもできる。ＳＮＳと個々のユーザまたはユーザ・システムとの間のプロトコルの実行によって特有の秘密グループ署名鍵を生成することができ、実行の終了時に、ユーザはその秘密グループ署名鍵を受信することができる。したがって、秘密グループ署名鍵を、それぞれ所有者または要求側のコンピュータ・システム（それぞれ所有者システムまたは要求側システムあるいはその両方）上に格納することができる。
【００４９】
方法の拡張実施形態によれば、所有者トークンまたは要求側トークンあるいはその両方の中に含まれるグループ署名は、所有者または要求側あるいはその両方の秘密グループ署名鍵の下で、メッセージ、具体的には任意のメッセージに署名した結果でよい。メッセージの内容はどんな役割も果たさないことがある。しかし、所有者の所有者識別をトークンから抽出することができる。
【００５０】
方法の別の拡張実施形態によれば、所有者トークンで署名された前述のメッセージは、プレーン・テキストまたは暗号化形式のアクセス制御ポリシーを含むことができる。ＳＮＳの公開鍵の下で前述のメッセージを暗号化することができる。リソースに対するアクセスを要求する前に、または要求する間に「オンザフライ」で、要求側トークンを生成することができる。
【００５１】
方法の代替実施形態によれば、所有者トークンまたは要求側トークンあるいはその両方は、ＯＡｕｔｈ許可フレームワーク、具体的にはＯＡｕｔｈ２．０フレームワークに基づくＯＡｕｔｈアクセス・トークンを含むことができる。
【００５２】
方法のＯＡｕｔｈベースの実施形態の別の実施形態によれば、ソーシャル・ネットワーキング・システムは、具体的にはどちらもＯＡｕｔｈアクセス・トークンでよい所有者トークンまたは要求側トークンあるいはその両方についての許可サーバとして働くことができ、ＳＮＳは、所有者トークンを所有者識別およびアクセス制御ポリシーと共に格納し、または要求側トークンを要求側識別と共に格納し、あるいはその両方を行うことができる。この格納は、ＳＮＳ、あるいは関連する追加のシステムまたはストレージで実施することができる。
【００５３】
さらに、実施形態は、コンピュータまたは任意の命令実行システムによって、またはそれと共に使用するためのプログラム・コードを提供するコンピュータ使用可能またはコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム製品の形態を取ることができる。この説明では、コンピュータ使用可能またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスによって、またはそれと共に使用するためのプログラムを格納、通信、伝播、または移送する手段を含むことのできる任意の装置でよい。
【００５４】
媒体は、伝播媒体用の電子、磁気、光、電磁、赤外線、または半導体システムでよい。コンピュータ可読媒体の例は、半導体または固体メモリ、磁気テープ、取外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、固定磁気ディスク、および光ディスクを含むことができる。光ディスクの現在の例は、コンパクト・ディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク読取り／書込み（ＣＤ−Ｒ／Ｗ）、ＤＶＤ、およびＢｌｕｅ−ｒａｙディスクを含む。
【００５５】
異なる主題を参照して本発明の実施形態を説明したことにも留意されたい。具体的には、方法型クレームを参照していくつかの実施形態を説明したのに対して、装置型クレームを参照して他の実施形態を説明した。しかし、上記および以下の説明から、別段の通知がない限り、あるタイプの主題に属する特徴の任意の組合せに加えて、異なる主題に関する特徴の間、具体的には方法型クレームの特徴と、装置型クレームの特徴との間の任意の組合せも本文書内で開示されるとみなされることを当業者は知るであろう。
【００５６】
本発明の上記で定義された態様および別の態様は、以下で説明する実施形態の例から明らかであり、実施形態の例を参照しながら説明されるが、本発明は実施形態に限定されない。
【００５７】
次に、単に例として、以下の図面を参照しながら、本発明の好ましい実施形態を説明する。
【図面の簡単な説明】
【００５８】
【図１】リソースに対するアクセスを制御する方法のステップのブロック図である。
【図２】ソーシャル・ネットワーキング・システム、リソースを格納したコンピュータ・システム、所有者システム、および要求側システムという、関係する各エンティティのブロック図である。
【図３】関係する構成要素およびメッセージ・フローのより詳細なブロック図である。
【図４】関係する構成要素およびメッセージ・フローの別の詳細なブロック図である。
【図５】方法の文脈で使用されるコンピュータ・システムのブロック図である。
【発明を実施するための形態】
【００５９】
以下では、図の詳細な説明を与える。図のすべての命令は概略的なものである。まず、所有者のリソースを制御する本発明の方法の一実施形態のブロック図。その後、リソースに対するアクセスを制御する方法ならびに関連するアクセス制御システムの別の実施形態を説明する。
【００６０】
図１に、リソースに対するアクセスを制御する方法のステップのブロック図を示す。まず、ＳＮＳで、ユーザ、すなわちリソースの所有者およびリソースの要求側を定義しなければならず（１０２）、別のコンピュータ・システム、すなわちリソース・コンピュータ・システム上にリソースを格納することができる。登録時に、所有者および要求側についての秘密グループ署名鍵をそれぞれ生成することができる（１０４）。これらの秘密グループ署名鍵をＳＮＳからそれぞれの所有者システムおよびそれぞれの要求側システムに送ることができる。所有者の秘密グループ署名鍵およびアクセス制御ポリシーを含むトークンをリソースと共にリソース・コンピュータ・システム上に格納することができる（１０６）。このプロセスを、所有者システムを介してリソースの所有者によって制御することができる。
【００６１】
リソース・コンピュータ・システム上で要求側によってリソースにアクセスする試行時に、所有者トークンおよび要求側トークンをリソース・コンピュータ・システムからＳＮＳに送ることができる（１０８）。ここで、ＳＮＳにおいて、所有者および要求側の秘密グループ署名鍵に基づいて所有者および要求側の識別を求めることができ（１１０）、受信したトークンに基づいてアクセス制御ポリシーを求めることができる。再び、所有者識別、抑制された識別、アクセス制御ポリシー、およびＳＮＳ内の所有者と要求側との間の定義済みの、または抽象的な関係に基づいて、許可信号を生成することができ（１１２）、リソース・コンピュータ・システムに許可信号を送り戻すことができる（１１４）。ここで、許可信号を使用して、リソースに対するアクセスを許可することができる。
【００６２】
図２に、リソース・コンピュータ・システム２０４上のリソースにアクセスする典型的なシナリオおよび一般的プロセス・フローを示す。ソーシャル・ネットワーキング・サービス２０２（ここではＳＮとも表される）のすべての登録ユーザのうちのいくつかのユーザ２０６が存在することがある。利用可能なソーシャル・ネットワーキング・サービス２０２の多くのうちの１つは、たとえばフェイスブックでよい。ここでは、ユーザ２０６がアカウントを有していることがある。ＳＮ２０２上では、ユーザは、その友達関係およびグループを管理することができる。ＳＮはまた、このシナリオに関係することのある、そのユーザについての他の情報も知っていることがある。ユーザＵｉは、一定のリソース（たとえば、イメージのコレクション）を所有および提供することがあり、たとえばフリッカーなどのサービス・プロバイダのリソース・コンピュータ・システムＳＰ上にリソースを預け、または提供する（２１０）ことによってリソースを友達と共有したいことがある。フェイスブックならびにフリッカーを単に例として使用することに留意されたい。任意の他のＳＮＳ２０２またはリソース・コンピュータ・システムＳＰ２０４を使用して、本開示の方法を実施することができる。ユーザＵｉ２０６は、友達のすべてとリソースを共有することを望まず、一定の基準を満たす友達のみと共有することを望むので、ユーザＵｉ２０６は、リソースに対するアクセスを誰に許可することができるかを記述するアクセス・ポリシーｐｌｃを作成することができる（２１２）。次いで、ユーザＵｉ２０６は、ＳＰでアクセス制御ポリシー（既にその適切な暗号化）をリソースと関連付けることができる（ステップ２）。ユーザＵｉ２０６はＳＮ２０２上で友達を管理することができるので、ポリシーは、ＳＮ２０２によって評価されるが、ＳＰ２０４によって実施される。ポリシー自体のフォーマットについて仮定は行われない。
【００６３】
ユーザＵｊがリソースに対するアクセスを要求することができる場合（２１４）（ステップ３）、ＳＰ、ＳＮ、およびＵｊは相互運用し、Ｕｊにアクセスを許可すべきかどうかを判定する（ステップ４、２１６、２１８）。最後に、ユーザＵｊ２０８は、リソースにアクセスすることができる（２０８）（ステップ５）。このプロセスでは、ＳＰは、ＵｊがＳＮによって評価されるポリシーｐｌｃを満たすことができるか否かを知ることができるだけである。この基本的シナリオでは、単純のために、ユーザ２０６、２０８がＳＮとの間のそのアカウントまたは識別の下で知られていると仮定することができ、ユーザ２０６、２０８がＳＰとの間のアカウントをも有している可能性があるかどうかは関係がない。ユーザＵｉ２０６は、任意の通信方法によって（ｅメールを送ることによって、ブログ上、ＳＮ上のユーザＵｉ２０６のウォール上でリンクを送ることによって）ユーザＵｊ２０８に通知することができ、またはＵｊ２０８は、Ｕｉ２０６のページを単に定期的に訪問することができる。
【００６４】
残りの図に関係するさらなる詳細に入る前に、提案されるソーシャル・ネットワーク・システム・ベースのアクセス制御についてのいくつかの一般的概念を論じることができる。
【００６５】
ＳＮＳベースのアクセス制御システム内の参加者またはユーザ２０６、２０８はソーシャル・ネットワークＳＮ２０４であり、ソーシャル・ネットワークＳＮ２０４では、ユーザ２０６、２０８は、そのプロファイルおよび友達リストを管理することができる。ＳＮに登録されているいくつかのユーザＵ１、．．．、Ｕｎ、およびリソースをホストし、リソースを他のユーザと共有するためにユーザ２０６、２０８が使用するサービス・プロバイダＳＰ２０４。ユーザ２０６、２０８は、ＳＰ２０４との間でアカウントを有することがあり、または有しないことがある。ＳＮ２０４との間のユーザ２０６、２０８の識別に基づいてすべてのアクセス制御決定を行うことができるので、これは、ここで提案されるシステムには無関係である。単純のために、ＳＮとの間のユーザＵｉのユーザ名をｉとみなすことができる。以下では、システムの高レベル概念をまず説明することができ、次いでそのアルゴリズムの正式な定義を与えることができる。
【００６６】
システムをセットアップするために、ＳＮ２０４は、鍵生成プロトコルを実行し、スキームのシステム・パラメータおよびＳＮの公開鍵を発行することができる。リソースを共有し、またはアクセスすることができるようにするために、ユーザＵｉ２０４は、ユーザが何らかの登録情報ｓｋｉ（ユーザの秘密鍵）をそこから得ることのできる、ソーシャル・ネットワークＳＮとの間の登録プロトコルをまず実行する必要があることがある。
【００６７】
次に、ユーザＵｉ（リソースの所有者）は、何らかのリソースを説明ｒｅｓと共に預けたい可能性があるとき（これは、たとえばリソースＵＲＬであることがある）、ｓｋｉおよびｒｅｓを使用して、何らかのアクセス制御ポリシーｐｌｃについて所有者トークンｏｔと呼ばれることがあるものを生成することができる。次いでＵｉは、所有者トークンおよびリソースをＳＰに預けることができ、ＳＰは、トークンの有効性をチェックすることができ、次いで、Ｕｉは、何らかの適切な手段によってｒｅｓを友達に送ることができる。
【００６８】
次に、ユーザＵｊ２０８（リソースの要求側）が説明ｒｅｓを伴うリソースにアクセスしたいことがあるとき、ユーザＵｊ２０８は、ユーザＵｊ２０８のｓｋｊを使用して、リソースｒｅｓについての要求側トークンｒｔを生成することができ、リソースを求める要求の部分としてｒｔをＳＰ２０４に送ることができる。ＳＰ２０４は、ｏｔおよびｒｔを使用して、ｏｔおよびｒｔが同一のリソースに関係することを証明するリンキング・トークンｌｔと呼ばれることがあるものを生成することができ、次いで３つの組（ｏｔ，ｒｔ，ｌｔ）をＳＮに送ることができる。リンキング・トークンは、ＳＮがリソースについての情報を知ることがないような方式で、ｏｔがそれについてポリシーを定義するリソースに対するアクセスを要求側トークンｒｔが実際に要求していることをＳＮ２０２に保証する。リンキング・トークンの生成はまた、要求側トークンの検証をも含むことができる。これらの３つのトークンを仮定すると、ＳＮは、ポリシーｐｌｃおよびユーザの識別ＵｉおよびＵｊを抽出することができる。したがって、ある意味では、要求側および所有者トークンを生成することにより、ＵｉおよびＵｊは、ＳＮ２０２との間のそのアカウントに関するポリシーｐｌｃの評価についてＳＮ２０２に照会することをＳＰ２０４に許可する。
【００６９】
次に、ＳＮ２０２は、ＵｊがＵｉに関するポリシーｐｌｃを満たすか否かを評価することができ、結果（「はい」または「いいえ」）をＳＰ２０４に送り戻すことができ、ＳＰ２０４は、結果に基づいてリソースに対するアクセスを許可または拒否する。
【００７０】
ユーザ２０６、２０８のプライバシーを保護するために、ＳＰ２０４およびＳＮ２０２が厳密に必要であるよりも多くの情報を知ることがないように保証することができ、すなわち、ＳＮ２０２はリソースについてのどんな情報も知るべきではなく、一方、ＳＰ２０４は、ＳＮとの間のユーザ２０６、２０８の識別も、アクセス・ポリシーについてのどのような情報も知ることがない。セキュリティのために、ポリシーを満たさないユーザ２０６、２０８がユーザ２０６、２０８にアクセスを与える要求側トークンを偽造することができないこと、およびサービス・プロバイダＳＰ２０４がＵｉによって作成されなかったＵｉに関連するポリシーを評価するために所有者トークンを偽造することができないことを保証することができる。
【００７１】
既に述べたように、所有者トークンおよび要求側トークンが何らかの形でリソースに「リンク」され、したがって所有者トークンおよび要求側トークンを異なるリソースに対するアクセスを保護または取得するために再利用することができないことをも保証することができる。ＳＮ２０２は、所有者トークンおよび要求側トークンが同一のリソースについて作成されたことをチェックすることができるべきであるが、同時に、ＳＮ２０２は、ｒｅｓ自体についてどのようなことも知ることができるべきである。これらの一見して矛盾する要件は、ユーザ２０６、２０８に、各所有者または要求側トークンと共にＳＰ２０４に送らせ、さらに情報ｏｌｉまたはｒｌｉをそれぞれリンクすることによって対処することができる。ＳＰ２０４は、ｏｌｉおよびｒｌｉをＳＮ２０２に転送することはできないが、その代わりに、本質的にｒｅｓ自体についてのすべての情報を取り去るｏｌｉおよびｒｌｉからリンキング・トークンｌｔを生成することができ、それでもなお、ｏｔおよびｒｔが実際に同一のリソースについて作成されたことをＳＮが検証することを可能にする。
【００７２】
ＳＮＳベースのアクセス制御システムは、Ｓｅｔｕｐ、Ｒｅｇｉｓｔｅｒ、ＯＴＧｅｎ、ＯＴＶｆ、ＲＴＧｅｎ、ＬＴＧｅｎ、およびＥｘｔｒａｃｔという５つの手順からなることができる。これらの手順を以下のように定義することができる（分かり易くするために、以下のセクションでは参照番号を伏せる）。
【００７３】
Ｓｅｔｕｐ：ＳＮについての鍵を生成するための確率的アルゴリズム。セキュリティ・パラメータｌの入力時に、アルゴリズムは、秘密ｓｋＳＮおよび公開鍵ｐｋＳＮを出力することができる。
【００７４】
Ｒｅｇｉｓｔｅｒ：ユーザＵｉとＳＮとの間の確率的プロトコル。ユーザの入力は（ｉ，ｐｋＳＮ）でよく、ＳＮの入力は（ｉ，ｓｋＳＮ）でよい。ユーザの出力はｓｋｉでよい。プロトコルが索引ｉについて既に実行された場合、プロトコルはこの索引について失敗することがあると仮定することができる。
【００７５】
ＯＴＧｅｎ：ユーザＵｉが、ＳＮによって検証すべきアクセス制御ポリシーplc∈{0,1}と共にＳＰによって格納されたリソースres∈{0,1}についてのリンキング情報ｏｌｉと共に所有者トークンｏｔを生成することを可能にする確率的アルゴリズム。ＯＴＧｅｎは、(ot,oli)←R OTGen(pkSN,ski,plc,res)として計算される。
【００７６】
ＯＴＶｆ：ＳＰがｒｅｓおよびＳＮに関して所有者トークンｏｔおよびそのリンキング情報ｏｌｉを検証することを可能にする決定性アルゴリズム、すなわち、0/1←(pkSN,ot,oli,res)。
【００７７】
ＲＴＧｅｎ：ユーザＵｉが、(rt,rli)←R RTGen(pkSN,ski,res)を計算することにより、ＳＰによってホストされるリソースｒｅｓについてのリンキング情報ｒｌｉと共に要求側トークンｒｔを生成することを可能にする確率的アルゴリズム。
【００７８】
ＬＴＧｅｎ：ポリシー・リンキング情報ｏｌｉおよびアクセス・リンキング情報ｒｌｉをリンキング・トークンｌｔとして組み合わせることのできる、恐らくは確率的なアルゴリズム、すなわち、lt←R LTGen(pkSN,ot,oli,rt,rli,res)。ＬＴＧｅｎは、失敗を示すためにlt=Null/無効を返すことができる。
【００７９】
Ｅｘｔｒａｃｔ：ＳＮがポリシー、アクセス、およびリンキング・トークンの３つの組に関連するユーザ識別およびポリシーを抽出することを可能にする決定性アルゴリズム、すなわち(i,j,plc)←Extract(skSN,ot,rt,lt)。トークンが不正に形成される場合、Ｅｘｔｒａｃｔは⊥を返す。その後で、ＳＮは、ユーザｉおよびｊがポリシーｐｌｃを満たすかどうかをチェックすることができる。このアルゴリズムは入力としてｒｅｓを必要としないことに留意されたい。実際には、ｏｔ、ｒｔ、ｌｔはｒｅｓについての情報を漏曳しないことが必要となることがある。
【００８０】
グループ署名実施形態
次のセクションは、使用されるグループ署名概念を説明する。
【００８１】
ソーシャル・ネットワーク・システム・ベースのアクセス制御スキームの一実施形態は、グループ署名に基づくことができ、グループ署名は、グループ・マネージャだけが正確な署名者を理解することができるように、署名者のグループがグループの名前でメッセージに匿名で署名することを可能にする。グループ・マネージャの役割はＳＮによって果たすことができ、ＳＮは、ＳＮに登録する各ユーザに署名鍵を配布することができる。リソースＵｉの所有者は、ＳＮの公開鍵の下でポリシーを暗号化し、リソースｒｅｓの識別子に対するコミットメントを作成し、暗号文およびコミットメントに対するグループ署名を計算することにより、アクセス・ポリシーをリソースに添付することができる。所有者トークンから暗号文を分離することができず、別のグループ署名と組み合わせて使用することができないことを確実にするために、暗号文をトークンにバインドするために、ワンタイム署名に関係する周知の技法を使用することができる。所有者トークンは、グループ署名、暗号文、コミットメント、これらのすべての３つに関するワンタイム署名、およびワンタイム署名スキームに対する公開鍵を含むことができ、リンキング情報は、コミットメントに対するオープニング情報からなる。ユーザＵｊがリソースに対するアクセスを要求することがあるとき、ユーザＵｊはまた、リソースにコミットし、ユーザＵｊのグループ署名鍵を使用してコミットメントに署名する。サービス・プロバイダＳＰは、トークン内のすべての署名を検証することができ、両方のコミットメントがリソース識別子ｒｅｓに対して開かれることをチェックする。次いで、サービス・プロバイダＳＰは、所有者トークンおよび要求側トークン内のコミットメントが同一のリソースに対して開かれることの非対話式ゼロ知識証明を計算することによってリンキング・トークンを作成することができる。ＳＮは、すべての署名およびゼロ知識証明をまず検証することができ、グループ署名を開くことによってユーザ識別ｉ、ｊを抽出し、アクセス・ポリシーを復号することができる。次いでＳＮは、ＵｊがＵｉに関するポリシーを満たすかどうかを評価し、アクセス判断をＳＰに送り戻すことができる。
【００８２】
グループ署名は、署名者がユーザのグループ全体の名前でメッセージに匿名で署名することを可能にし、ユーザは、グループ・マネージャからユーザの秘密署名鍵を得る。グループ・マネージャは、グループの初期化、およびグループ・メンバの許可の役割を果たす。グループの公開鍵を使用して、メッセージが有効なグループ・メンバによって署名されたことを誰もが検証することができるが、グループ・マネージャ（または専用のオープナ）だけが署名者の正確な識別を回復することができる。署名鍵がすべてのユーザについて初期化段階中にあらかじめ計算されるか、それとも新しいユーザがグループに加入したときにはいつでも動的に生成されるかに応じて、グループ署名スキームは静的または動的と呼ばれる。ここでは、単純のため、静的グループ署名によって方法を説明するが、方法は動的なケースに容易に拡張される。
【００８３】
グループ署名スキームは、以下のアルゴリズムからなることができる。
【００８４】
ＧＫｇ：グループ公開鍵ｇｐｋ、署名鍵ｇｓｋ１、．．．、ｇｓｋｎ、およびオープニング鍵ｏｋを生成するためにグループ・マネージャがセキュリティ・パラメータｌおよびユーザ数ｎの入力時に使用することのできる確率的アルゴリズム。ＧＫｇはｇｐｋを発行し、署名鍵ｇｓｋｉをユーザＵｉに渡し、ｏｋを秘密に保つ。
【００８５】
ＧＳｉｇｎ：グループ署名σを作成するためにユーザＵｉが署名鍵ｇｓｋｉおよびメッセージｍｓｇの入力時に実行する署名アルゴリズム。
【００８６】
ＧＶｅｒｉｆｙ：検証者がグループ公開鍵ｇｐｋ、メッセージｍｓｇ、および署名σの入力時に実行し、署名が有効である場合に１を返し、そうでない場合はゼロを返す決定性検証アルゴリズム。
【００８７】
ＧＯｐｅｎ：オープニング鍵ｏｋ、メッセージｍｓｇ、および署名σの入力時に、署名を作成したユーザの索引i∈{0,...,1}、または失敗を示すためにヌル／無効を返すオープニング・アルゴリズム。
【００８８】
ＧＶｅｒｉｆｙ：検証者がグループ公開鍵ｇｐｋ、メッセージｍｓｇ、および署名σの入力時に実行することができ、署名が有効である可能性がある場合に１を返すことができ、そうでない場合にゼロを返す決定性検証アルゴリズム。
【００８９】
ＧＯｐｅｎ：オープニング鍵ｏｋ、メッセージｍｓｇ、および署名σの入力時に、署名を作成したユーザの索引i∈{0,...,1}、または失敗を示すためにヌル／無効を返すオープニング・アルゴリズム。
【００９０】
すべてのl,n,i∈Nについて、およびすべてのmsg∈{0,...,1}*について、(gpk,gsk1,...,gskn,ok)←GKg(l,n)であるとき、確率１でGVerify(gpk,msg,GSign(gski,msg))=1およびGOpen(ok,msg,GSign(gski,msg))=iを有することを正確さが必要とする。
【００９１】
グループ署名スキームのセキュリティは、２つのプロパティ、すなわち匿名性および追跡可能性からなることができる。匿名性は本質的に、グループ・マネージャ以外の誰も、どの署名者が特定の署名を作成したかを伝えることはできないことを保証する。
【００９２】
追跡可能性は、有効なグループ署名を、グループ署名の作成でその署名鍵が使用されたユーザまで常にトレースバックすることができることを保証することができる。このことは、どのような署名鍵に対するアクセスも行わない有効な署名の作成能力が追跡可能性に違反することになるので、非偽造可能性を示唆する。どちらの要件も履行される。
【００９３】
ラベルを用いる公開鍵暗号化
ラベルを用いる公開鍵暗号化は、標準公開鍵暗号化と同様であるが、悪用不可能な方式でラベルを暗号文にバインドすることができる。ラベルをメッセージに添付することによってラベルを任意の標準公開鍵暗号化スキームに追加することができるが、多くのスキームは、より効率的なインスタンス化を提供する。スキームは、セキュリティ・パラメータｌの入力時に公開暗号鍵ｅｐｋおよび対応する秘密暗号化解除鍵ｅｓｋを生成する鍵生成アルゴリズムＥＫｇと、ｅｐｋ、メッセージｍｓｇ、およびラベルλの入力時に暗号文ｃを出力する暗号化アルゴリズムＥｎｃと、ｅｓｋ、＿、およびｃの入力時に失敗を示すためにｍｓｇまたは⊥を出力する暗号化解除アルゴリズムＤｅｃとからなる。任意の鍵ペア(epk,esk)←EKg(l)、任意のl∈N、および任意のmsg,λ∈{0,1}*について、確率１でDec(esk,λ,Enc(epk,msg,λ))=msgであることを正確さが必要とする。
【００９４】
適応的選択暗号文攻撃（ＩＮＤ−ＣＣＡ２）の下での区別不可能性の標準セキュリティ概念がここでは使用される。敵対者Ａに暗号鍵ｅｐｋおよび暗号化解除オラクルＤｅｃ（ｅｓｋ，・，・）に対する適応的アクセスが与えられる。Ａがラベルλ＊および２つの等しい長さのメッセージｍｓｇ０＊、ｍｓｇ１＊１を出力するとき、ランダムビットb∈{0,1}についてc*←Enc(pk,msgb*,λ)が与えられる。
【００９５】
敵対者が暗号化解除オラクルに(λ*,c*)を照会することなくｂ’＝ｂを出力する場合、敵対者はゲームに勝利する。
【００９６】
ワンタイム署名スキーム
ワンタイム署名スキームは、３つのアルゴリズム（ＯＴｋｇ、ＯＴＳｉｇｎ、ＯＴＶｅｒｉｆｙ）からなり、ＯＴｋｇは、セキュリティ・パラメータｌの入力時に、公開検証鍵ｏｔｐｋおよび対応する秘密署名鍵ｏｔｓｋを生成し、ＯＴＳｉｇｎは、入力としてｏｔｓｋおよびメッセージｍｓｇを取って署名ｏｔｓを生成し、ＯＴＶｅｒｉｆｙは、与えられた署名ｏｔｓが公開鍵ｏｔｐｋおよびメッセージｍｓｇに関して有効であるかどうかを示すビットを出力する。すべてのl∈Nおよびmsg∈{0,1}について(otpk,otsk)←R OTkg(l)であるときはいつでも、確率１でOTVerify(otpk,msg,OTSign(otsk,msg))=1であることを正確さが必要とする。ｌ内の時間多項式内で実行中の敵対者が、ｏｔｐｋの入力時、かつｏｔｓを返す署名オラクルOTSign(otsk,・)に対する単一の照会ｍｓｇの後、OTVerify(otpk,msg',ots')=1および(msg',σ')≠(msg,ots)となるように偽造（ｍｓｇ’，ｏｔｓ’）を生成することができない場合、スキームは、強力ワンタイム偽造不可能(strongly one-time unforgeable)であると言われる。選択メッセージ攻撃下で強固に偽造不可能である任意の（複数回）署名スキームは、ワンタイム強力偽造不可能スキームでもあるが、より効率的な構成が存在する。
【００９７】
結論
以下のセクションは、証明システムＮＩＺＫを用いる、グループ署名スキーム（ＧＫｇ、ＧＳｉｇｎ、ＧＶｅｒｉｆｙ、ＧＯｐｅｎ）、公開鍵暗号化スキーム（ＥＫｇ、Ｅｎｃ、Ｄｅｃ）、およびコミットメント・スキーム（ＣＰＧｅｎ、Ｃｏｍｍｉｔ、ＣＯｐｅｎ）からのＳＮＳベースのアクセス制御システムの構成を以下のように説明する。
【００９８】
Ｓｅｔｕｐ：ｌの入力時に、ＳＮＳは、(gpk,gsk1,...,gskn,ok)←R GKg(l,n)を実行する。ただし、ｎはＳＮ内のユーザ数についての上界である。Ｓｅｔｕｐはまた、暗号鍵ペア(epk,esk)←R EKg(l)およびコミットメント・パラメ-タcpars←R CPGen(l)を生成する。skSN=(gsk1,...,gskn,ok,esk)およびpkSN=(gpk,epk,cpars)を返す。
【００９９】
Ｒｅｇｉｓｔｅｒ：ユーザＵｉがＳＮに登録するとき、ＳＮは単にski=gskiをＵｉに送る。
【０１００】
ＯＴＧｅｎ：ユーザＵｉは、ワンタイム署名鍵ペア(otpk,otsk)←R OTkg(l)を生成し、ラベルｏｔｐｋを有するＳＮの公開鍵の下でポリシーをc←Enc(epk,plc,otpk)として暗号化し、リソース(cmt,op)←R Commit(cpars,res)にコミットし、グループ署名σ←GSign(gski,(policy,c,cmt,otpk,SP))を作成し,ots←R OTSign(otsk,(c,cmt,σ))に署名することによって、アクセス制御ポリシーｐｌｃでＳＰ上でホストされるリソースｒｅｓの所有者トークンｏｔを生成する。ユーザＵｉは、所有者トークンot=(c,cmt,σ,otpk,ots)およびリンキング情報oli=opをＳＰに送る。
【０１０１】
ＯＴＶｆ：サービス・プロバイダＳＰは、Open(cpars,cmt,res,op)=1,GVerify(gpk,(policy,c,cmt,otpk,SP),σ)=1,およびOTVerify(otpk,(c,cmt,σ),ots)=1をチェックすることにより、リソースｒｅｓについてoli=opでot=(c,cmt,σ,otpk,ots)を検証する。
【０１０２】
ＲＴＧｅｎ：ユーザＵｊがＳＰでホストされるリソースｒｅｓにアクセスしたいとき、ＲＴＧｅｎは、コミットメント(cmt,op)←R Commit(cpars,res)を作成し、グループ署名σ←GSign(gskj,(access,cmt,SP))を計算し、要求側トークンrt=(cmt,σ)およびリンキング情報rli=opをＳＰに送る。
【０１０３】
ＬＴＧｅｎ：サービス・プロバイダＳＰは、リンキング・トークンｌｔを、ポリシー内のコミットメントおよび要求側トークンが同一のリソースについてのものであるＮＩＺＫ  ＰｏＫとして計算する。より厳密には、ＬＴＧｅｎはまず、COpen(cpars,res,cmt2,op2)=1をチェックし、署名GVerify(gpk,(access,cmt2,SP))=1を検証することにより、rli=op2で要求側トークンrt=(cmt2,σ2)を検証する。これらのテストのいずれかが失敗した場合、ＲＴＧｅｎはヌル／無効を返し、そうでない場合,所有者ト-クンot=(c,cmt1,σ1,otpk,ots)およびoli=op1を使用して,lt R NIZK{(res,op1,op2):COpen(cpars,cmt1,res,op1)=1∧COpen(cpars,cmt2,res,op2)=1}を生成する.
【０１０４】
Ｅｘｔｒａｃｔ：ＳＮが所有者トークンot=(c,cmt1,σ1,otpk,ots),要求側トークンrt=(cmt2,σ2),およびリンキング・トークンｌｔをリソース・ホストＳＰから受信するとき、Ｅｘｔｒａｃｔは以下のように進む。署名のいずれかが無効である場合、すなわち、GVerify(gpk,(policy,c,cmt1,otpk,SP),_1)=0、OTVerify(otpk,(c,cmt1,σ1),ots)=0、またはGVerify(gpk,(access,cmt2,SP)、σ2)=0である場合、あるいはＮＩＺＫ  ＰｏＫ  ｌｔの検証がｃｍｔ１、ｃｍｔ２に関して失敗した場合、Ｅｘｔｒａｃｔはヌル／無効を返す。そうでない場合,σ1およびσ2をi←GOpen(ok,(policy,c,cmt1,SP),σ1)およびj←GOpen(ok,(access,cmt2,SP),σ2)として開く。Ｅｘｔｒａｃｔはまた、ポリシーplc←Dec(esk,c,otpk)を暗号化解除する。ｉ＝⊥またはｊ＝⊥である場合、Ｅｘｔｒａｃｔは⊥を返し、そうでない場合、(I,j,plc)を返し、ｉおよびｊがポリシーｐｌｃを満たすかどうかをＳＮがチェックすることを可能にする。そうである場合、リソースｒｅｓに対するアクセスが、ＳＰによってｊに許可される。⊥は「無効」、「空き」、または「偽」を表すことがあることに留意されたい。
【０１０５】
ＯＡｕｔｈ実施形態
以下では、ウェブ技術によって既存のＳＮＳをＳＮＳベースのアクセス制御システムとなるようにどのように拡張することができるかを説明する。示されるように、ＯＡｕｔｈ２．０許可フレームワークを利用することによってセキュリティ要件を達成することが可能である。
【０１０６】
以下では、まずＯＡｕｔｈを紹介し、次いで実装詳細を与える。
【０１０７】
ＯＡｕｔｈ２．０は、ユーザの実際のアクセス証明（ユーザのユーザ名およびパスワードなど）を共有する代わりに、いわゆるＯＡｕｔｈアクセス・トークンをサードパーティに提供することにより、ユーザがユーザのオンライン・リソースに対するサードパーティ・アクセスを許可することを可能にする。たとえば、ユーザは、何らかの写真印刷サービスにアクセス・トークンを提供することにより、印刷サービスに、たとえば、グーグル＋イメージ・ギャラリーに対する限定されたアクセスを許可することができる。そのようなトークンは、ベアリング・サードパーティに発行されたアクセス許可を表す不透明文字列である。ユーザの代わりに保護されたリソースに対する要求を行うサードパーティは、ＯＡｕｔｈではクライアントとも呼ばれる。ＯＡｕｔｈトークンが、リソース所有者（たとえば、何らかのユーザＵｉ）の承認と共に許可サーバ（たとえばＳＮ）によってクライアント（たとえば、ＳＰ）に発行される。セキュリティの理由で、クライアントは、クライアント識別子およびパスワードからなる認証証明を得るために許可サーバに登録しなければならないことがある。
【０１０８】
本発明者の実装のセキュリティ・プロパティを後で論じるために、以下では、最も一般的なＯＡｕｔｈメッセージ・フローの５つのステップを略述する。
【０１０９】
１．クライアントが、リソース所有者のユーザ・エージェント（たとえば、リソース所有者のウェブ・ブラウザ）を許可サーバに向ける（リダイレクトする）ことによってプロトコル・フローを開始する。クライアントは、そのクライアント識別子と、要求されるアクセス範囲と、アクセスが許可（拒否）された後に許可サーバがユーザをリダイレクトして戻すＵＲＬとを含む。
【０１１０】
２．許可サーバは、ユーザ・エージェントを介してリソース所有者を認証し、リソース所有者が、与えられた範囲についてのクライアントのアクセス要求を許可するか、それとも拒否するかを確立する。
【０１１１】
３．リソース所有者がアクセスを許可するケースでは、許可サーバは、前に提供されたリダイレクションＵＲＩを使用して、ユーザ・エージェントをクライアントにリダイレクトして戻す。リダイレクションＵＲＩは許可コードを含む。
【０１１２】
４．クライアントは、前のステップで受信した許可コードをサーバに提供することにより、許可サーバにアクセス・トークンを要求する。要求を行うとき、クライアントは、（たとえば、ＨＴＴＰ  Ｂａｓｉｃ認証で）登録中に得た認証証明を含む。要求は、トランスポート層セキュリティ（ＴＬＳ）と共にサーバ許可チャネルを使用して行われる。
【０１１３】
５．許可サーバは、クライアントを認証し、許可コードを検証する。有効である場合、許可サーバは、アクセス・トークンで応答する。
【０１１４】
実装
本セクションでは、所有者トークンｏｔおよび要求側トークンｒｔの入力時に、ｏｔに関連するユーザ識別の下で評価されるｏｔに関連するポリシーがｒｔに関連するユーザ識別に関して満たされるかどうかに関するブール回答、すなわち0/1←policyEval(ot,rt)を返すＳＰによって使用されるウェブ・サービス・エンドポイント（たとえば、ＲＥＳＴｆｕｌ  ＡＰＩ）をＳＮＳがどのように実装することができるかを説明する。本発明者らはｒｔおよびｏｔをＯＡｕｔｈアクセス・トークンとして理解し、ＯＡｕｔｈプロトコルを前述のように使用して、ＳＰにこれらのトークンを提供する。
【０１１５】
リソース預託
何らかのリソースを説明ｒｅｓ（たとえば、リソースＵＲＬ）と共にＳＰに預けることが許可されるユーザＵｉについて、ユーザＵｉは、ＳＰに所有者トークンｏｔを提供しなければならない。このトークンと共に、Ｕｉは、説明したサービス・エンドポイントによってＵｉに代わって何らかのポリシーｐｌｃを評価することをＳＰに許可する。このトークンを得るために、ＳＰは、Ｕｉをクライアントとして、ＳＮを許可サーバとしてＯＡｕｔｈ許可プロトコルを実行する。ＳＰは、範囲ｐｏｌｉｃｙＥｖａｌ＿ｏｗｎｅｒを使用して、ＳＮのサービス・エンドポイントと共にポリシー評価のためにＳＰが使用することを望む所有者トークンの生成をＳＰが要求することをＳＮおよびユーザに明確に示す。ステップ２でのユーザ認証の間に、Ｕｉは、Ｕｉの証明（たとえば、ユーザ名およびパスワード）だけではなく、（たとえば、何らかのウェブフォームに記入することによって）所有者トークンに関連付けられるべきポリシーｐｌｃもＳＮに提供する。ＯＡｕｔｈ  ｏｗのステップ５でＳＮがｏｔを返す前に、ＳＮはまず、このトークンを十分なエントロピーでランダム文字列として生成し、それを何らかのローカル・データベース内で、認証されたユーザＵｉ、ポリシーｐｌｃ、および要求された範囲と関連付ける。所有者トークンｏｔを受信すると、ＳＰは、リソースを預けることを許可し、何らかのローカル・データベースでリソースをｒｅｓおよびｏｔと関連付ける。リソースを預けると、Ｕｉは、Ｕｉの友達がリソースにアクセスすることができるように、（たとえば、Ｅメールによって）ｒｅｓをＵｉの友達に送る。
【０１１６】
リソース・アクセス
何らかのユーザＵｊが、ＳＰによってホストされる説明ｒｅｓを有するリソースにアクセスしたいとき、ユーザはまず、ＳＰがポリシー評価照会を行うことができるように、ワンタイム要求側トークンｒｔをＳＰに提供しなければならない。このトークンを用いて、Ｕｊは、ＳＰがＳＮのサービス・エンドポイントと共に行われるポリシー・チェックでＵｊの識別を使用することを許可する。トークンを得るために、ＳＰは、ＵｊおよびＳＮと共にクライアントとしてＯＡｕｔｈプロトコルを実行する。ＳＰは、範囲ｐｏｌｉｃｙＥｖａｌ＿ｒｅｑｕｅｓｔｅｒを使用して、ＳＮのサービス・エンドポイントと共にポリシー評価のために使用することを望む要求側トークンの生成をＳＰが要求することをＳＮおよびユーザに示す。ＳＮがＯＡｕｔｈ  ｏｗのステップ５でｒｔを返す前に、ＳＮはまず、このワンタイム・トークンを十分なエントロピーでランダム文字列として生成し、それを何らかのローカル・データベース内で、認証されたユーザＵｊと要求された範囲の両方に関連付ける。ＳＰが要求側トークンを得た後、ＳＰは、ｒｅｓに関連する所有者トークンを取り出し、取り出した所有者トークンおよび得られた要求側トークンを照会パラメータとして使用することによって（たとえば、ＨＴＴＰ  ＧＥＴ要求によって）ＳＮのポリシー評価エンドポイントに照会する。
【０１１７】
ポリシー評価
ＳＮのウェブ・サービス・エンドポイントに関するＳＰからのポリシー評価照会の受信時に、ＳＮは、そのローカル・データベースから、ユーザ識別ＵｉおよびＵｊ、ならびに提供された所有者および要求側トークンにそれぞれ関連する範囲ｓｏおよびｓｒを取り出す。ＳＮはまた、このデータベースから所有者トークンに関連するポリシーｐｌｃも取り出す。その後で、ＳＮは、ｓｏおよびｓｒがそれぞれｐｏｌｉｃｙＥｖａｌ＿ｏｗｎｅｒおよびｐｏｌｉｃｙＥｖａｌ＿ｒｅｑｕｅｓｔｅｒに等しいかどうかをチェックする。トークンが有効であり、範囲が一致し、要求側トークンが以前に使用されていない場合、ＳＮは、Ｕｉの識別の下でｐｌｃを評価し（すなわち、ログイン中にＵｉが照会を自分自身で実行するかのように）、その照会の結果、ユーザ識別のセットが得られる。最後に、ＳＮは、Ｕｊがこのセットのメンバであるかどうかをブール式にＳＰに応答し、ｒｔを使用済みとしてマークする。トークンのうちの１つが有効ではなく、または範囲が一致しない場合、ＳＮはトランザクションを打ち切る。サービス要求が認証された場合、任意選択で、ＳＮは、サービス・エンドポイントに対する、認証されたパーティの将来のアクセスを拒否することができる。
【０１１８】
図３に、関係するエンティティである、ＳＮＳ２０２、リソース３０８を格納したリソース・コンピュータ・システム２０４、所有者システム３１０、および要求側システム３１２のブロック図３００を示す。ユーザがＳＮＳ２０２に対して登録することができる場合、プロファイル３１０を生成することができる。このことは、要求側と命名された場合、別のユーザを含むＳＮＳ２０２の任意のユーザに適用することができる。要求側のプロファイルまたは識別を３１２ｓと命名することができる。ユーザと要求側はどちらも、それ自体のコンピュータ・システム、すなわち所有者システム３１０および要求側システム３１２を使用することができる。これらのシステムを使用して、所有者および要求側は、ＳＮＳ２０２にアクセスすることができる。ＳＮＳ２０２では、所有者は、要求側プロファイル３１２ｓによって識別可能な、要求側に対する関係３２０を定義することができる。関係３２０は、ユーザのプロファイルまたは所有者プロファイル３１０ｓの部分となることができる。
【０１１９】
さらに、ＳＮＳ２０２はアクセス・コントローラ３０４を備えることができる。アクセス・コントローラ３０４の制御下で、各ユーザ（所有者および要求側を含む）は、それぞれのシステム３１０および３１２で、任意のユーザ特有の秘密グループ署名鍵３１６、３１８を受信することができる（３２６、３２８）。これらのユーザ特有の秘密グループ署名鍵３１６、３１８に対する他者によるアクセスを許可しない所有者システム３１０および要求側システム３１２上に、これらの鍵を格納しなければならないことがある。これらの鍵を秘密として保たなければならない。一例として、ＳＮＳ２０２は、たとえばフェイスブック、リンクトイン、エクシング、または任意の他のＳＮＳでよい。ＳＮＳをクラウド・コンピューティング・システムとして配置することができ、複数の異なるコンピュータ・システムにわたって分散させることができる。
【０１２０】
リソース３０８、たとえばテキスト・ファイルまたはピクチャまたはビデオまたは任意の他の格納可能なリソースの所有者を、所有者システム３１０を介して、所有者システム３１０から、または別のストレージ位置からリソース・コンピュータ・システム２０４にアップロードすることができる（３２２）。リソース３０８自体に加えて、リソース・コンピュータ・システム２０４上に所有者トークン３１４を格納し、リソース３０８にリンクすることができる。要求側システム３１２によってリソース３０８に直接的にアクセスすることはできない。しかし、要求側システム３１２の要求３２４時に、ＳＮＳ２０２のアクセス・コントローラ３０４との間の一定のプロトコルを含むアクセス制御手順を実行することができる。したがって、リソース・コンピュータ・システム２０６の側の直接的なアクセス制御機構を使用する必要はない。その代わりに、ＳＮＳ２０２内に格納され、アクセス・コントローラ３０４によって制御されるアクセス制御ポリシーを、リソース・コンピュータ・システム２０４上のリソース３０８に対するアクセスを制御するために使用することもできる。
【０１２１】
追加の詳細なメッセージ・フロー４００が、図４を使用して示されている。所有者システム３１２から、リソース３０８に対するアクセス・ポリシーを含むリソース・コンピュータ・システム２０４上に所有者トークンを格納することができる（４０４と比較）。要求側システム３１２は、リソース・コンピュータ・システム２０４に要求側トークンを送り（４０６）、リソース３０８に対するアクセスを要求する。しかし、要求側システム３０８に対する直接的アクセスを許可することができない。その代わりに、要求側システムは、要求側トークン（４０８と比較）と共にアクセス制御ポリシーを含む所有者トークンをＳＮＳ２０２に送る（４１０）。ここでは、所有者トークンおよび要求側トークンに基づいて、所有者および要求側の識別が求められる。さらに、所有者トークン、およびＳＮＳ２０２との間の所有者識別と要求側識別との間の定義済みの関係３２０に基づいて、アクセス・ポリシーを求めることができる。アクセス・コントローラ３０４によってアクセス制御ポリシーを確認することができる場合、かつ要求側システム３１２によるリソースに対するアクセスについての肯定的な判定のケースでは、アクセス・コントローラ３０４を介してＳＮＳ２０２からリソース・コンピュータにアクセス許可確認信号４１２を送ることができる。次いで、リソース・コンピュータは、要求側コンピュータ・システム３１２によるリソース３０８に対するアクセスを許可することができる。
【０１２２】
本発明の実施形態を、プログラム・コードを格納または実行あるいはその両方を行うのに適したプラットフォームの如何に拘わらず、ほぼ任意のタイプのモバイル・デバイスまたはモバイル・コンピュータと共に実装することができる。所有者システム３１０および要求側システム３１２として適しているのは、具体的には、スマートフォンのようなモバイル・デバイスまたはモバイル・コンピューティング・デバイスである。これから論じるコンピュータは、図２、３、４の文脈で論じた要素をも含むことができる。たとえば、図５に示されるように、コンピューティング・システム５００、たとえばモバイル・デバイスは、プロセッサ当たり１つまたは複数のコアを有する１つまたは複数のプロセッサ５０２、関連するメモリ要素５０４、内部記憶デバイス５０６（たとえば、ハード・ディスク、コンパクト・ディスク・ドライブやデジタル・ビデオ・ディスク（ＤＶＤ）ドライブなどの光ドライブ、フラッシュ・メモリ・スティックなど）、ならびに今日のコンピュータに典型的な多数の他の要素および機能（図示せず）を含むことができる。メモリ要素５０４は、プログラム・コードの実際の実行中に利用されるメイン・メモリ、たとえばランダム・アクセス・メモリ（ＲＡＭ）、およびキャッシュ・メモリを含むことができ、キャッシュ・メモリは、実行のために長期記憶媒体または外部バルク・ストレージ５１６から取り出さなければならない回数、コード、またはデータ、あるいはそれらの組合せを削減するために、少なくとも一部のプログラム・コードまたはデータあるいはその両方の一時記憶を提供することができる。スマートフォンでは、長期バルク・ストレージをスマートカード、ＳＤカード（ＳＤ＝Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ）、またはｍｉｃｒｏＳＤカードとして実装することができる。バス・システム５１８および対応するアダプタによって、コンピュータ５００内部の要素を互いにリンクすることができる。
【０１２３】
コンピューティング・システム５００はまた、キーボード５０８、マウス５１０などのポインティング・デバイス、ならびにマイクロフォンおよびスピーカ、あるいはそれらの組合せ（図示せず）などの入力手段をも含むことができる。あるいは、コンピューティング・システムは、メイン入力および出力デバイスとしてタッチ検知画面５１２を備えることができる。さらに、コンピュータ５００は、モニタや画面５１２（たとえば、液晶ディスプレイ（ＬＣＤ）、プラズマ・ディスプレイ、発光ダイオード・ディスプレイ（ＬＥＤ）、または陰極線管（ＣＲＴ）モニタ）などの出力手段を含むことができる。コンピュータ・システム５００をネットワーク（たとえば、ネットワーク・インターフェース接続５１４を介するワイヤレス・ネットワークを含む、ローカル・エリア・ネットワーク（ＬＡＮ）、インターネットや任意の他の同様のタイプのネットワークなどの広域ネットワーク（ＷＡＮ））に接続することができる。これにより、他のコンピュータ・システムまたはストレージ・ネットワークまたはテープ・ドライブまたは携帯電話ネットワークに対する結合を可能にすることができる。多くの異なるタイプのコンピュータ・システムが存在し、前述の入力および出力手段は他の形態を取ることがあることを当業者は理解されよう。一般的に言えば、コンピュータ・システム５００は、本発明の実施形態を実施するために必要な、少なくとも最小限の処理手段、入力手段、または出力手段、あるいはそれらの組合せを含むことができる。
【０１２４】
限られた数の実施形態に関連して本発明を説明したが、本開示の利点を得る当業者は、本明細書で開示される本発明の範囲から逸脱しない他の実施形態を考案できることを理解されよう。したがって、本発明の範囲は添付の特許請求の範囲のみによって限定されるべきである。さらに、様々な実施形態に関連して説明した要素を組み合わせることができる。特許請求の範囲内の参照符号を限定的な要素と解釈すべきではないことにも留意されたい。
【０１２５】
当業者は理解するであろうが、本開示の態様をシステム、方法、またはコンピュータ・プログラム製品として具現化することができる。したがって、本開示の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはソフトウェア態様とハードウェア態様を組み合わせる実施形態の形態を取ることができ、それらはすべて、本明細書では全般的に「回路」、「モジュール」、または「システム」と呼ぶことがある。さらに、本開示の態様は、その中で具現化されるコンピュータ可読プログラム・コードを有する１つまたは複数のコンピュータ可読媒体で具現化されるコンピュータ・プログラム製品の形態を取ることができる。
【０１２６】
１つまたは複数のコンピュータ可読媒体の任意の組合せを利用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体でよい。コンピュータ可読記憶媒体は、たとえば、限定はしないが、電子、磁気、光、電磁、赤外線、または半導体システム、装置、またはデバイス、あるいは上記の任意の適切な組合せでよい。コンピュータ可読記憶媒体のより具体的な例（網羅的でないリスト）は、１つまたは複数のワイヤを有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、または上記の任意の適切な組合せを含む。本文書の文脈では、コンピュータ可読記憶媒体は、命令実行システム、装置、またはデバイスによって、あるいはそれと共に使用するためのプログラムを収容または格納することのできる任意の有形媒体でよい。
【０１２７】
コンピュータ可読信号媒体は、たとえば、ベースバンドで、または搬送波の部分としてコンピュータ可読プログラム・コードがその中で具現化される伝播データ信号を含むことができる。そのような伝播信号は、限定はしないが、電磁的、光学的、またはそれらの任意の適切な組合せを含む様々な形態のいずれかを取ることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではない、命令実行システム、装置、またはデバイスによって、またはそれと共に使用するためにプログラムを通信、伝播、または移送することのできる任意のコンピュータ可読媒体でよい。
【０１２８】
コンピュータ可読媒体上で具現化されるプログラム・コードは、限定はしないが、ワイヤレス、ワイヤライン、光ファイバ・ケーブル、ＲＦなど、または上記の任意の適切な組合せを含む任意の適切な媒体を使用して送信することができる。
【０１２９】
本発明の諸態様の動作を実施するコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語や類似のプログラミング言語などの従来の手続型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組合せで書くことができる。プログラム・コードは、完全にユーザのコンピュータ上で、スタンド・アロン・ソフトウェア・パッケージとして部分的にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、かつ部分的にリモート・コンピュータ上で、あるいは完全にリモート・コンピュータまたはサーバ上で実行することができる。後者のシナリオでは、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを通じて、リモート・コンピュータをユーザのコンピュータに接続することができ、または外部コンピュータに対する接続を行うことができる（たとえば、インターネット・サービス・プロバイダを使用して、インターネットを通じて）。
【０１３０】
本開示の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品の流れ図またはブロック図あるいはその両方を参照しながら本開示の諸態様を説明した。流れ図またはブロック図あるいはその両方の各ブロック、ならびに流れ図またはブロック図あるいはその両方のブロックの組合せをコンピュータ・プログラム命令によって実装できることを理解されよう。これらのコンピュータ・プログラム命令は、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行される命令が、流れ図またはブロック図あるいはその両方の１つまたは複数のブロックで指定される機能／動作を実装する手段を作成するように、汎用コンピュータ、専用コンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供されて、マシンを生成するものであってよい。
【０１３１】
これらのコンピュータ・プログラム命令はまた、コンピュータ可読媒体内に格納された命令が、流れ図またはブロック図あるいはその両方の１つまたは複数のブロックで指定される機能／動作を実装する命令を含む製造品を生成するように、コンピュータ可読媒体内に格納され、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスに特定の方式で機能するように指示するものであってもよい。
【０１３２】
コンピュータ・プログラム命令はまた、コンピュータまたは他のプログラム可能装置上で実行される命令が、流れ図またはブロック図あるいはその両方の１つまたは複数のブロックで指定される機能／動作を実装するプロセスを提供するように、コンピュータ実装プロセスを生成させるべく、コンピュータ、他のプログラム可能データ処理装置、または他のデバイス上にロードされ、コンピュータ、他のプログラム可能装置、または他のデバイス上で一連の動作ステップを実施させるものであってもよい。
【０１３３】
図のブロック図は、本開示の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。この点で、ブロック図の各ブロックは、指定の論理機能を実装する１つまたは複数の実行可能命令を含むモジュール、セグメント、またはコードの部分を表すことがある。いくつかの代替実装では、上記で論じた機能は、開示した順序とは異なる順序で行われることがある。たとえば、関係する機能に応じて、連続して教示した２つの機能は、実際にはほぼ同時に実行されることがあり、または機能が時には逆の順序で実行されることがある。ブロック図の各ブロック、およびブロック図のブロックの組合せが、指定の機能または動作を実施する専用ハードウェア・ベースのシステム、あるいは専用ハードウェアとコンピュータ命令の組合せによって実装されることがあることにも留意されたい。
【０１３４】
本明細書で使用する用語は、特定の実施形態を説明するためのものに過ぎず、本発明を限定するものではない。本明細書では、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈がそうでないことを明確に示すのでない限り、複数形も含むものとする。「備える」または「備えている」、あるいはそれらの両方である用語は、本明細書で使用されるとき、記載の特徴、完全体、ステップ、動作、要素、または構成要素、あるいはそれらの組合せの存在を指定するが、１つまたは複数の他の特徴、完全体、ステップ、動作、要素、構成要素、またはそれらのグループ、あるいはそれらの組合せの存在または追加を除外するものではないこともさらに理解されよう。
【０１３５】
以下の特許請求の範囲のすべてのミーンズまたはステップ・プラス・ファンクション要素の対応する構造、材料、動作、および均等物は、具体的に特許請求されるように、他の特許請求される要素と共に機能を実施する任意の構造、材料、または動作を含むものとする。例示および説明のために本発明の説明を提示したが、本発明の説明は、網羅的ではなく、または開示される形態の発明に限定されないものとする。本発明の範囲および趣旨から逸脱することなく、多くの変更形態および変形形態が当業者には明らかとなるであろう。本発明の原理、実際の応用例を最良に説明するため、および企図される特定の用途に適するように様々な変更を伴う様々な実施形態についての本発明を他の当業者が理解することを可能にするために実施形態を選び、説明した。
【図１】
2017504855.tif 000003
【図２】
2017504855.tif 000004
【図３】
2017504855.tif 000005
【図４】
2017504855.tif 000006
【図５】
2017504855.tif 000007
【手続補正書】
【提出日】平成28年7月29日(2016.7.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
リソースの所有者の前記リソースに対するアクセスを制御する方法であって、前記所有者がリソース・コンピュータ・システムのユーザであり、前記アクセス制御が、ソーシャル・ネットワーキング・システムのデータに基づき、
前記アクセス制御が、前記所有者に関する所有者トークン、前記リソースに対するアクセスを要求する要求側に関する要求側トークン、およびアクセス制御ポリシーに基づき、
リソース所有者識別および前記アクセス制御ポリシーが前記所有者トークン内に符号化され、前記リソース要求側識別が前記要求側トークン内に符号化され、前記所有者トークンおよび前記要求側トークンが、前記ソーシャル・ネットワーキング・システムによって受信され、前記所有者トークンおよび前記要求側トークンの内容に基づいて、リソース・コンピュータ・システム上の前記リソースに対するアクセスを許可すべきかどうかが前記ソーシャル・ネットワーキング・システムによって判定される、方法。
【請求項２】
前記アクセス制御ポリシーが前記ソーシャル・ネットワーキング・システムのみによって判定可能である、請求項１に記載の方法。
【請求項３】
前記所有者トークンが、前記リソース・コンピュータ・システム上の前記リソースに関係付けられる、請求項１または２に記載の方法。
【請求項４】
前記所有者トークンおよび前記要求側トークンから前記ソーシャル・ネットワーキング・システム内の所有者識別および要求側識別を求めるステップと、
前記所有者トークンが関連するアクセス制御ポリシーを求めるステップと、
前記ソーシャル・ネットワーキング・システム内の前記所有者識別または前記要求側識別あるいはその両方に基づいて前記アクセス制御ポリシーを評価するステップと、
前記ソーシャル・ネットワーキング・システムから前記リソース・コンピュータ・システムに前記評価の結果を送るステップと
をさらに含む、請求項１ないし３のいずれかに記載の方法。
【請求項５】
前記所有者トークンおよび前記要求側トークンがグループ署名を含み、関連する署名グループが前記ソーシャル・ネットワーキング・システムによって管理される、請求項１ないし４のいずれかに記載の方法。
【請求項６】
所有者システムまたは要求側システムあるいはその両方によって、前記ソーシャル・ネットワーキング・システムに関係するユーザ特有の秘密グループ署名鍵を取得するステップ
をさらに含む、請求項５に記載の方法。
【請求項７】
前記所有者トークンまたは前記要求側トークンあるいはその両方の中に含まれる前記グループ署名が、前記所有者または前記要求側あるいはその両方の前記秘密グループ署名鍵の下で、メッセージに署名した結果である、請求項６に記載の方法。
【請求項８】
所有者トークンで署名された前記メッセージが、プレーン・テキストまたは暗号化形式の前記アクセス制御ポリシーを含む、請求項７に記載の方法。
【請求項９】
前記所有者トークンまたは前記要求側トークンあるいはその両方が、ＯＡｕｔｈ許可フレームワークに基づくＯＡｕｔｈアクセス・トークンを含む、請求項１ないし４のいずれかに記載の方法。
【請求項１０】
前記ソーシャル・ネットワーキング・システムが、前記所有者トークンまたは前記要求側トークンあるいはその両方についての許可サーバとして働き、前記ソーシャル・ネットワーキング・システムが、前記所有者トークンを前記所有者識別および前記アクセス制御ポリシーと共に格納し、または前記要求側トークンを前記要求側識別と共に格納し、あるいはその両方を行う、請求項９に記載の方法。
【請求項１１】
リソースの所有者の前記リソースに対するアクセスを制御するアクセス制御システムであって、リソース・コンピュータ・システムを備え、前記所有者が、リソース・コンピュータ・システムおよびソーシャル・ネットワーキング・システムのユーザであり、前記ソーシャル・ネットワーキング・システムが、ソーシャル・ネットワーク・データを格納するストレージを備え、前記リソースに対するアクセスが、前記ソーシャル・ネットワーキング・システムの前記ストレージ内に格納されたデータに基づき、
前記アクセス制御システムの前記アクセス制御が、前記リソース・コンピュータ・システムのメモリ内に格納された所有者トークンに基づき、所有者システムに関する前記所有者トークン、前記リソースに対するアクセスを要求する要求側システムに関する要求側トークン、およびアクセス制御ポリシーが、前記リソース・コンピュータ・システムのメモリ内に前記所有者トークンの部分として格納され、
前記アクセス制御ポリシーに加えて、リソース所有者識別が前記所有者トークン内に符号化され、前記リソース要求側識別が前記要求側トークン内に符号化され、前記所有者トークンおよび前記要求側トークンが、前記リソース・コンピュータ・システムから前記ソーシャル・ネットワーキング・システムに送られ、前記所有者トークンおよび前記要求側トークンの内容に基づいて、前記リソースに対するアクセスを許可すべきかどうかが判定される、アクセス制御システム。
【請求項１２】
コンピュータ・プログラムであって、前記コンピュータ・プログラムが、前記ソーシャル・ネットワーキング・システムのプロセッサおよび前記リソース・コンピュータ・システムのプロセッサによって部分的に実行されるとき、請求項１ないし１０のいずれかに記載の方法を実施する、コンピュータ・プログラム。
【請求項１３】
請求項１ないし１０のいずれかに記載の方法を実施するソフトウェア・コード部分を含む、データ処理システムで実行するためのデータ処理プログラムであって、前記プログラムが、前記ソーシャル・ネットワーキング・システムおよび前記リソース・コンピュータ・システムのプロセッサ上で部分的に実行される、データ処理プログラム。
【請求項１４】
ソーシャル・ネットワーク・データを格納するストレージを備えるソーシャル・ネットワーキング・システムであって、
リソース・コンピュータ・システムのリソースの所有者についての秘密グループ署名鍵を生成し、
前記リソースに対する要求側についての秘密グループ署名鍵を生成し、
前記リソース・コンピュータ・システムから所有者トークンおよび要求側トークンを受信し、前記所有者トークンおよび前記要求側トークンの内容に基づいて、前記リソースに対するアクセスを許可すべきかどうかを判定するように構成され、アクセス制御ポリシーが前記所有者トークン内に符号化され、前記アクセス制御ポリシーに加えて、リソース所有者識別が前記所有者トークン内に符号化され、リソース要求側識別が前記要求側トークン内に符号化される、ソーシャル・ネットワーキング・システム。
【請求項１５】
前記リソースに対するアクセスを許可すべきかどうかの前記判定に基づいて、前記リソース・コンピュータ・システムにアクセス許可信号を送る
ように構成される、請求項１４に記載のソーシャル・ネットワーキング・システム。
【請求項１６】
リソースの所有者の前記リソースに対するアクセスを制御する方法であって、前記所有者がリソース・コンピュータ・システムのユーザであり、前記アクセス制御が、ソーシャル・ネットワーキング・システムのデータに基づき、前記方法が、
リソース・コンピュータ・システムのリソースの所有者についての秘密グループ署名鍵を生成するステップと、
前記リソースに対する要求側についての秘密グループ署名鍵を生成するステップと、
前記リソース・コンピュータ・システムから所有者トークンおよび要求側トークンを受信し、前記所有者トークンおよび前記要求側トークンの内容に基づいて、前記リソースに対するアクセスを許可すべきかどうかを判定するステップとを含み、アクセス制御ポリシーが前記所有者トークン内に符号化され、
前記アクセス制御ポリシーに加えて、リソース所有者識別が所有者トークン内に符号化され、リソース要求側識別が前記要求側トークン内に符号化される、方法。
【請求項１７】
前記リソースに対するアクセスを許可すべきかどうかの前記判定に基づいて、前記リソース・コンピュータ・システムにアクセス許可信号を送るステップ
をさらに含む、請求項１６に記載の方法。
【国際調査報告】
2017504855.tif 000008
2017504855.tif 000009