【誤訳訂正書】
【提出日】平成27年9月16日(2015.9.16)
【誤訳訂正１】
【訂正対象書類名】明細書
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【発明の詳細な説明】
【発明の名称】サードパーティーアプリケーションの集中型セキュアマネージメント方法、システム、および対応する通信システム
【技術分野】
【０００１】
本発明は、通信に関し、詳細には、ユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション／クライアント上での集中型セキュアマネージメントを実行するためのテクノロジーに関する。
【背景技術】
【０００２】
現在、インターネットサービスどうしの統合が、必要なトレンドになってきている。よりよいサービスをユーザに提供するために、多くのサービスプロバイダは、サードパーティーアプリケーション／クライアントが、「オープンネットワークＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）」を呼び出すことによってさらに多くのアプリケーションをユーザに提供することを可能にしている。オープンプラットフォームの本質的な問題は、ユーザ認証、承認、およびサードパーティーアプリケーション／クライアントがオープンネットワークＡＰＩを安全に使用しなければならないということである。ユーザにとっては一般に、ユーザとサードパーティーの両者が強い信頼関係にない限り、サードパーティーがユーザの保護されているネットワークリソースにアクセスする目的でユーザ自身のユーザ名およびパスワードを直接使用することができることをユーザは望まない。サービスどうしの統合中の「認証および承認」という本質的な問題を解決する目的で、ＯＡｕｔｈ（Ｏｐｅｎ  Ａｕｔｈｏｒｉｚａｔｉｏｎ）プロトコルが発表されている。
【０００３】
ＩＥＴＥ（すなわち、Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）によって開発されたＯＡｕｔｈプロトコルは、現在国際的に一般的な許可様式であり、リソースの所有者を代理することによって、保護されているリソースにアクセスする方法をサードパーティーアプリケーション／クライアントに提供する。保護されているリソースにアクセスする前に、サードパーティーアプリケーション／クライアントは、はじめにリソースの所有者からの許可、すなわちアクセス許可（アクセス許可は、リソースの所有者によって提供される許可に相当し、そのタイプは、サードパーティーアプリケーション／クライアントによって使用される入手様式、および許可サーバによってサポートされる様式に依存する）を入手し、次いで（アクセス許可のアクション範囲、持続時間、およびその他の属性を表す）アクセストークンをアクセス許可と交換しなければならない。サードパーティーアプリケーション／クライアントは、アクセストークンをリソースサーバに示すことによって、保護されているリソースにアクセスする。
【０００４】
ＯＡｕｔｈプロトコルの新たなバージョン、ＯＡｕｔｈ２．０は、実施を簡素化することを原則としており、より多くのアクセス形態をサポートし、たとえば、「ウェブアプリケーション、デスクトップアプリケーション、モバイル端末、ホームデバイス」などを同時にサポートする。ＯＡｕｔｈ２．０は、ユーザが、必ずしも自分の長期クレデンシャルを、または自分の識別子さえ明らかにすることなく、自分の保護されているリソースへのアクセスをサードパーティーアプリケーション／クライアントに許可することを可能にする。この方法においては、ユーザ機密情報のプライバシーが保護されることが可能である。
【０００５】
この目的のために、サービスプロバイダは、ユーザのリソースを管理しなければならず、下記を担当するＩＥＴＦ  ＯＡｕｔｈ２．０において定義されている許可サーバを構築しなければならない：
−  ユーザのマネージメント、
−  サードパーティーアプリケーション／クライアントのマネージメント、
−  サードパーティーアプリケーション／クライアントがアクセストークンを求める際に用いるアクセス許可（ＩＥＴＦ  ＯＡｕｔｈ２．０における定義を参照されたい）を発行すること、
−  許可サーバとユーザとの間における相互認証、
−  許可サーバとサードパーティーアプリケーション／クライアントとの間における相互認証、
−  アクセス許可の検証、および
−  サードパーティーアプリケーション／クライアントがユーザの保護されているリソースにアクセスすることができるアクセストークンを発行すること。
【０００６】
図１は、ＩＥＴＦ  ＯＡｕｔｈ２．０によるシステムおよびワークフローを概略的に示している。
【０００７】
図１において示されているワークフローは、下記のとおりである：
１．サードパーティーアプリケーション／クライアントが、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスすることを計画し、
２．リソースサーバは、サードパーティーアプリケーション／クライアントが、有効なアクセストークンを有していないことに気づき、次いでユーザの許可を得るために、サードパーティーアプリケーション／クライアントをユーザエージェントへリダイレクトし、
３．ユーザは、許可アクセスを用いてサードパーティーアプリケーション／クライアントを許可する前に、許可サーバによって許可されなければならず、また同時に許可サーバを認証することを必要とする場合があり、
４．許可サーバは、ユーザエージェントを介してサードパーティーアプリケーション／クライアントへ許可アクセスを送信し、
５．サードパーティーアプリケーション／クライアントは、アクセストークンを求めるために、識別子、許可アクセス、および自分自身の認証クレデンシャルを許可サーバに提示し、
６．許可サーバとサードパーティーアプリケーション／クライアントとの間における相互認証の後に、かつ許可アクセスを検証した後に、許可サーバは、アクセストークンをサードパーティーアプリケーション／クライアントに発行し、
７．サードパーティーアプリケーション／クライアントは、ユーザのリソースにアクセスするために、アクセストークンをリソースサーバに提示し、
８．アクセストークンが有効である場合には、リソースサーバは、データをサードパーティーアプリケーション／クライアントに返す。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、ＩＥＴＦ  ＯＡｕｔｈ２．０が非常に好ましいのは、いくつかの大規模サービスプロバイダにとってのみである。なぜなら、それらの大規模サービスプロバイダは、サードパーティーアプリケーション／クライアントのマネージメント（たとえば、識別子、認証、認証クレデンシャルマネージメントなど）を自分たち自身でまかなう余裕があるためである。しかしながら、小規模および中規模サービスプロバイダにとっては、これを行うのは容易ではない。なぜなら、サードパーティーアプリケーション／クライアントを管理することは、それらの小規模および中規模サービスプロバイダにとって非常に高くつくことになるためである。その上、大規模サービスプロバイダたちは、内部で別々のリソースサーバを配備している場合には、サードパーティーウェブサイトおよびアプリケーション／クライアントを管理するための重複したコンポーネントを開発および配備しなければならない。
【０００９】
さらに、非常に多くのサードパーティーアプリケーション／クライアントが存在し、それらのうちのいくつかは個人によって開発および提供される場合があるため、攻撃者たちが、ネットワークＡＰＩを悪用することによってユーザのリソースに不正にアクセスするために悪意のあるネットワークＡＰＩを開発する可能性がある。したがって、すべてのサードパーティーアプリケーション／クライアントがセキュアで信頼されているということを、ユーザの保護されているリソースへのアクセスをそれらのサードパーティーアプリケーション／クライアントに許可する前に保証することは、容易ではない。
【課題を解決するための手段】
【００１０】
従来技術における上述の欠点に対処するために、本発明の第１の態様によれば、本発明は、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション上での集中型セキュアマネージメントを実行するための方法を明らかにする。この方法によれば、集中型マネージメントのためのサードパーティーアプリケーションの集中型セキュアマネージメントシステムが、サードパーティーアプリケーションを発行する前に、サードパーティーアプリケーションのセキュリティーを検証すること、およびサードパーティーアプリケーションにデジタル署名することを担当し、その集中型セキュアマネージメントシステムがサードパーティーアプリケーションを認証することができる認証クレデンシャルを発行する。この方法は、サードパーティーアプリケーションによって、その識別子、認証クレデンシャル、およびアクセス許可を区別可能な様式で集中型セキュアマネージメントシステムへ送信するステップと、サードパーティーアプリケーションを成功裏に認証した後に、集中型セキュアマネージメントシステムによって、アクセス許可を許可サーバへ転送するステップと、許可サーバがアクセス許可を有効なものとして成功裏に認証した場合には、許可サーバによって、ユーザの保護されているリソースにアクセスするためのアクセストークンを、集中型セキュアマネージメントシステムを通じてサードパーティーアプリケーションに発行するステップとを含む。
【００１１】
本発明の別の態様によれば、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステムが提供され、このシステムは、区別可能な様式でサードパーティーアプリケーションによって送信されたサードパーティーアプリケーションの識別子、認証クレデンシャル、およびアクセス許可を受信するための第１の受信デバイスと、識別子、認証クレデンシャル、およびアクセス許可を受信した後に、識別子および認証クレデンシャルを使用してサードパーティーアプリケーションを認証するための第１の認証デバイスと、サードパーティーアプリケーションを成功裏に認証した後に、サードパーティーアプリケーションのアクセス許可を許可サーバへ転送するための第１の転送デバイスと、許可サーバによって発行されたアクセストークンをサードパーティーアプリケーションへ転送するための第２の転送デバイスと含む。
【００１２】
好ましくは、本発明によるシステムは、個人の開発者またはサービスプロバイダによって開発されて、デジタル署名のために個人の開発者またはサービスプロバイダのプライベートキーを使用するサードパーティーアプリケーションを受信するための第２の受信デバイスと、個人の開発者またはサービスプロバイダによって開発されたデジタル証明書を使用して、第２の受信デバイスによって受信されたサードパーティーアプリケーションのデジタル署名を認証するための第２の認証デバイスと、第２の認証デバイスの成功裏の認証の後に、サードパーティーアプリケーションが、悪意のあるコードまたはウイルスを含んでいるかどうかを検知するための安全チェックデバイスと、サードパーティーアプリケーションを成功裏に安全チェックした後に、システムのプライベートキーを使用してサードパーティーアプリケーションにデジタル署名するためのデジタル署名デバイスと、サードパーティーアプリケーションに関する識別子、認証クレデンシャル、および関連属性の統一配布のマネージメントのためのサードパーティーアプリケーションレジストリ／マネージメントデバイスと、すべての関連したデジタル証明書の統一マネージメント（生成、発行、および取り消しなど）のための証明書マネージメントデバイスとをさらに含む。
【００１３】
本発明のさらに別の態様によれば、少なくとも１つの許可サーバと、少なくとも１つのリソースサーバと、ユーザエージェントと、サードパーティーアプリケーションと、本発明による、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステムとを含む通信システムが提供される。
【００１４】
本発明のその他の特徴、目的、および利点は、添付の図面を参照しながら、非限定的な実施形態についての以降の詳細な説明を読むことによって、さらに明らかになるであろう。
【図面の簡単な説明】
【００１５】
【図１】従来技術におけるＩＥＴＦ  ＯＡｕｔｈ２．０によるシステムおよびワークフローを概略的に示す図である。
【図２】本発明による、サードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステムおよびワークフローを概略的に示す図である。
【図３】本発明の一実施形態による、サードパーティーアプリケーション上での集中型セキュアマネージメントの方法のフローチャートである。
【図４】本発明の一実施形態による、サードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステムのブロック図である。
【発明を実施するための形態】
【００１６】
本発明の基本的なアイディアは、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション／クライアント上での集中型セキュアマネージメントを実行することである。簡潔にするために、「サードパーティーアプリケーション／クライアント」は、以降の文章においては「サードパーティーアプリケーション」と示されることになる。図２は、サードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステムおよびワークフローを概略的に示している。図２において示されているように、図１における既存のソリューションと比較すると、集中型セキュアマネージメントシステムが付加されている。このシステムは、下記の機能を有する：
−  サードパーティーアプリケーションを正式にリリースする前に、
サードパーティーアプリケーションのトレーサビリティーを確保するための個人の開発者またはサービスプロバイダのキーを通じた署名に関してサードパーティーアプリケーションを認証するために個人の開発者またはサービスプロバイダのデジタル証明書を使用すること、
サードパーティーアプリケーションがセキュアであるか否かを検証すること（たとえば、アンチウイルス／アンチマルウェアをチェックすること）、
サービスプロバイダまたはエンドユーザが、サードパーティーアプリケーションのインストレーションの前にサードパーティーアプリケーションのセキュリティー、真正性、および信頼性を確認することができるように、サードパーティーアプリケーションにそのキーを用いて署名すること、
認証のために使用されるサードパーティーアプリケーションに対するクレデンシャル（たとえば、証明書またはキー）を発行すること、
−  サードパーティーアプリケーションを正式にリリースすること、
−  サードパーティーアプリケーションが、ユーザの保護されているリソースにアクセスする前に、このシステムは、下記の機能を有する：
集中型セキュアマネージメントシステムと、サードパーティーアプリケーションとの間における相互認証、
サードパーティーアプリケーションに関する識別子およびその認証クレデンシャルのマネージメント。
【００１７】
図１における既存のソリューションと比較すると、図２におけるサードパーティーアプリケーションは、本出願による集中型セキュアマネージメントサーバが、識別子、認証クレデンシャル、およびそのアクセス許可を個別に区別することができるように、それらの識別子、認証クレデンシャル、およびアクセス許可を個別にパックすること、または識別子、認証クレデンシャル、およびアクセス許可を個別にマークすることを必要とすることが可能である。
【００１８】
図２においては、許可サーバ＿１／リソースサーバ＿１、許可サーバ＿２／リソースサーバ＿２、および許可サーバ＿ｎ／リソースサーバ＿ｎは、下記のものに属する場合がある：
別々の小規模および中規模サービスプロバイダ、または
いくつかのリソースサーバを別々に配備した同じ大規模サービスプロバイダ。
【００１９】
図１における既存のソリューションと比較すると、許可サーバ＿ｎは、ステップ５のメッセージがサードパーティーアプリケーションから直接来ているのか、またはステップ５において示されているように集中型セキュアマネージメントシステムから来ているのかを区別するべきである。その区別は、たとえばフラグを通じて実施されることが可能である。ステップ５のメッセージがサードパーティーアプリケーションから直接来ている場合には、許可サーバ＿ｎは、サードパーティーアプリケーションを認証して、アクセス許可を検証すべきであり、ステップ５のメッセージが集中型セキュアマネージメントシステムから来ている場合には、許可サーバ＿ｎは、アクセス許可を検証することのみを行うべきである。
【００２０】
図１における既存のソリューションと比較すると、図５におけるワークフローの変更は、下記のとおり存在する：
−  ステップ５においては、サードパーティーアプリケーションの識別子、認証クレデンシャル、およびアクセス許可が、区別可能な様式で集中型セキュアマネージメントシステムへ送信されることが可能であり、区別可能な様式とは、集中型セキュアマネージメントシステムが、識別子、認証クレデンシャル、およびアクセス許可を区別することができるように、それらの識別子、認証クレデンシャル、およびアクセス許可が個別にパッケージされること、または個別にマークされることが可能であるということを意味している。
−  ステップ６においては、ステップ６は、下記のように２つのサブステップを含む：
６−１：  サードパーティーアプリケーションを成功裏に認証した後に、集中型セキュアマネージメントシステムは、アクセス許可を許可サーバ＿ｎへ転送する。アクセス許可が有効である場合には、許可サーバ＿ｎは、サードパーティーアプリケーションに対して発行されたアクセストークンを集中型セキュアマネージメントシステムへ送信する。本発明においては、アクセス許可およびアクセストークンは、たとえば、ＩＥＴＦによって定義されている認証プロトコルＯＡｕｔｈ２．０に準拠している。
６−２：  集中型セキュアマネージメントシステムは、アクセストークンをサードパーティーアプリケーションへ転送する。
【００２１】
さらに、本発明のソリューションによれば、サードパーティーアプリケーションが、有効なアクセストークンを有していない場合には、リソースサーバは、サードパーティーアプリケーションのアクセス要求をユーザエージェントへリダイレクトする。
【００２２】
指摘されなければならないこととして、本発明による集中型セキュアマネージメントシステムは、サーバグループを含み、そのサーバグループは、たとえば、証明書発行マネージメントサーバ、サードパーティーアプリケーションのセキュリティーチェッキングサーバ、サードパーティーアプリケーションのレジストリマネージメントサーバ、サードパーティーアプリケーションの認証サーバ、サードパーティーアプリケーションのストレージ／リリースサーバなどを含むことができる。
【００２３】
本発明においてさらに指摘されなければならないこととして、ユーザは、自分の保護されているリソースにサードパーティーアプリケーションがアクセスすることを許可すると想定される。自分の保護されているリソースにサードパーティーアプリケーションがアクセスすることを許可する前に、ユーザは、サードパーティーアプリケーションがアクセストークンを入手する目的でアクセス許可を入手するように、自分の識別子が真正であること、および自分の保護されているリソースにサードパーティーアプリケーションがアクセスすることを許可するための権限を有していることを確かにするために、許可サーバによって認証されなければならない。本発明のソリューションによれば、ユーザ認証は、ユーザエージェントと許可サーバとの間における通信によって直接、または集中型セキュアマネージメントシステムを通じたユーザエージェントによる許可サーバへのリダイレクトによって、実施されることが可能である。
【００２４】
同様に、アクセス許可は、許可サーバによってユーザエージェントを通じてサードパーティーアプリケーションへ送信されること、または許可サーバによって集中型セキュアマネージメントシステムおよびユーザエージェントを通じてサードパーティーアプリケーションへ送信されることが可能である。
【００２５】
さらに、本発明による集中型セキュアマネージメントシステムは、下記の機能を実施することができる：
−  個人の開発者またはサービスプロバイダのキーを使用した個人の開発者またはサービスプロバイダの署名およびサインによって開発されたサードパーティーアプリケーションが受信された場合には、サードパーティーアプリケーションのトレーサビリティーを確保するためのサードパーティーアプリケーションのデジタル署名を認証するために個人の開発者またはサービスプロバイダのデジタル証明書を使用すること、
−  認証が成功裏に実施された後に、サードパーティーアプリケーションが、悪意のあるコードまたはウイルスを含んでいるかどうかを検知すること、
−  安全検知がサードパーティーアプリケーション上で成功裏に実施された後に、サードパーティーアプリケーションがインストールされる際のそのセキュリティー、真正性、および信頼性を確かにする目的でサードパーティーアプリケーションにデジタル署名するために集中型セキュアマネージメントシステムのキーを使用すること、
−  サードパーティーアプリケーションに関する識別子、認証クレデンシャル、および関連属性の統一配布のマネージメントを実行すること、
−  生成、発行、および取り消しなど、すべての関連したデジタル証明書上での統一マネージメントを実行すること。
【００２６】
本発明による集中型セキュアマネージメントシステムを使用することによって、小規模および中規模サービスプロバイダにとっては、多額のコストを節約すること、および負担を低減することが可能であり（それは、ユーザおよび保護されているリソースのマネージメントを担当するだけですむということを意味し）、またさらに、大規模サービスプロバイダは、サードパーティーアプリケーション上での集中型マネージメントを伴って、それによって個別に配備される複数の内部リソースサーバを提供するようになることが可能である。さらに、本発明のソリューションを使用することによって、サードパーティーアプリケーションがさらにセキュアであり信頼できるということを確かにすることができる。なぜなら、そのサードパーティーアプリケーションは、信頼できるサードパーティーメカニズム（すなわち、本発明の集中型セキュアマネージメントシステム）によって安全管理されるためである。
【００２７】
以降では、本発明の一実施形態による、サードパーティーアプリケーション上での集中型セキュアマネージメントを実行するための方法が、図３を参照することによって説明される。この実施形態の方法は、上述の図２において示されているようなシステムに適合されることが可能であり、ここで上述のシステムの説明にさらに入り込むことはしない。
【００２８】
図３において示されているように、はじめに、ステップ３０１において、サードパーティーアプリケーションは、自分の識別子、認証クレデンシャル、およびアクセス許可を区別可能な様式で集中型セキュアマネージメントシステムへ送信する。認証クレデンシャルは、ここでは、たとえば、デジタル証明書、暗号、またはパスワードであることが可能であり、アクセス許可は、たとえば、ＩＥＴＦによって定義されている認証プロトコルＯＡｕｔｈ２．０に準拠することができる。区別可能な様式とは、集中型セキュアマネージメントシステムが、識別子、認証クレデンシャル、およびアクセス許可を区別することができるように、それらの識別子、認証クレデンシャル、およびアクセス許可が個別にパッケージされること、または個別にマークされることが可能であるということを意味している。上述したように、この実施形態においては、ユーザは、自分の保護されているリソースにサードパーティーアプリケーションがアクセスすることを許可すると想定される。サードパーティーアプリケーションが、リソースサーバ内のユーザの保護されているリソースにアクセスすることを要求したときに、サードパーティーアプリケーションが、有効なアクセストークンを有していない場合には、リソースサーバは、サードパーティーアプリケーションのアクセス要求をユーザエージェントへリダイレクトする。
【００２９】
指摘されなければならないこととして、アクセスに関してサードパーティーアプリケーションを許可する前に、ユーザは、サードパーティーアプリケーションがアクセス許可を使用することによってアクセストークンを入手する目的でアクセス許可を入手するように、許可サーバによって認証されなければならず、許可サーバによるユーザの認証は、許可サーバに対するユーザエージェントの認証によって直接、または認証のための集中型セキュアマネージメントシステムを通じたユーザエージェントによる許可サーバへのリダイレクトによって、実施されることが可能である。
【００３０】
さらに指摘されなければならないこととして、許可サーバがアクセス許可をサードパーティーアプリケーションへ送信した後に、サードパーティーアプリケーションは、そのサードパーティーアプリケーションの識別子、認証クレデンシャル、およびアクセス許可を集中型セキュアマネージメントシステムへ送信し、アクセス許可は、許可サーバによってユーザエージェントを通じてサードパーティーアプリケーションへ送信されること、または許可サーバによって集中型セキュアマネージメントシステムおよびユーザエージェントを通じてサードパーティーアプリケーションへ送信されることが可能である。
【００３１】
次いで、ステップ３０２において、集中型セキュアマネージメントシステムは、サードパーティーアプリケーションを成功裏に認証した後にアクセス許可を許可サーバへ転送する。ここで、アクセス許可は、たとえば、ＩＥＴＦによって定義されている認証プロトコルＯＡｕｔｈ２．０に準拠している。
【００３２】
次いで、ステップ３０３において、アクセス許可が有効である場合には、許可サーバは、ユーザの保護されているリソースにアクセスするためのアクセストークンを、集中型セキュアマネージメントシステムを通じてサードパーティーアプリケーションに発行する。ここで、アクセストークンは、たとえば、ＩＥＴＦによって定義されている認証プロトコルＯＡｕｔｈ２．０に準拠している。したがって、サードパーティーアプリケーションは、ユーザの保護されているリソースにアクセスするためにアクセストークンをリソースサーバに提示することができる。
【００３３】
この実施形態においては、集中型セキュアマネージメントシステム、ユーザエージェント、サードパーティーアプリケーション、許可サーバ、およびリソースサーバの間におけるインタラクティブなプロセスは、上述のＯＡｕｔｈ２．０などの（ただし、それには限定されない）任意の既存のおよび将来のソリューション、標準、および基準の様式に準拠することができる。
【００３４】
上述の説明においては、新たな集中型セキュアマネージメントシステムを既存のシステム内に付加することによって、この実施形態による、サードパーティーアプリケーション上での集中型セキュアマネージメントを実行する方法を使用すれば、小規模および中規模サービスプロバイダにとっては、多額のコストを節約すること、および負担を低減することが可能であり（それは、ユーザおよび保護されているリソースのマネージメントを担当するだけですむということを意味し）、またさらに、大規模サービスプロバイダは、サードパーティーアプリケーション上での集中型マネージメントを伴って、それによって個別に配備される複数の内部リソースサーバを提供するようになることが可能であるということがわかる。さらに、本発明のソリューションを使用することによって、サードパーティーアプリケーションがさらにセキュアであり信頼できるということを確かにすることができる。なぜなら、そのサードパーティーアプリケーションは、信頼できるサードパーティーメカニズム（すなわち、本発明の集中型セキュアマネージメントシステム）によって安全管理されるためである。
【００３５】
同じコンセプトのもとで、本発明の別の態様によれば、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステムが提供される。以降では、そのシステムが、図を参照することによって説明される。
【００３６】
図４は、本発明の一実施形態による集中型セキュアマネージメントシステム４００を示している。システム４００は、受信デバイス４０１、認証デバイス４０２、第１の転送デバイス４０３、および第２の転送デバイス４０４を含む。同様に、ユーザは、自分の保護されているリソースにサードパーティーアプリケーションがアクセスすることを許可すると想定される。具体的には、サードパーティーアプリケーションが、保護されているリソースにアクセスすることを要求した場合には、許可サーバがユーザを成功裏に認証して、アクセス許可をサードパーティーアプリケーションに発行した後に、受信デバイス４０１は、区別可能な様式でサードパーティーアプリケーションによって送信されたサードパーティーアプリケーションの識別子、認証クレデンシャル、およびアクセス許可を受信する。区別可能な様式とは、集中型セキュアマネージメントシステムが、識別子、認証クレデンシャル、およびアクセス許可を区別することができるように、それらの識別子、認証クレデンシャル、およびアクセス許可が個別にパッケージされること、または個別にマークされることが可能であるということを意味している。識別子、認証クレデンシャル、およびアクセス許可を受信した後に、認証デバイス４０２は、サードパーティーアプリケーションを認証するために、識別子、認証クレデンシャルを使用する。第１の転送デバイス４０３は、サードパーティーアプリケーションを成功裏に認証した後にサードパーティーアプリケーションのアクセス許可を許可サーバへ転送し、第２の転送デバイス４０４は、許可サーバによって発行されたアクセストークンをサードパーティーアプリケーションへ転送する。したがって、サードパーティーアプリケーションは、アクセストークンをリソースサーバに提示することによって、ユーザの保護されているリソースにアクセスすることができる。
【００３７】
上述したように、集中型セキュアマネージメントシステム４００はさらに、下記の機能を実施する：
−  個人の開発者またはサービスプロバイダのキーを使用した個人の開発者またはサービスプロバイダの署名およびサインによって開発されたサードパーティーアプリケーションが受信された場合には、サードパーティーアプリケーションのトレーサビリティーを確保するためのサードパーティーアプリケーションのデジタル署名を認証するために個人の開発者またはサービスプロバイダのデジタル証明書を使用すること、
−  認証が成功裏に実施された後に、サードパーティーアプリケーションが、悪意のあるコードまたはウイルスを含んでいるかどうかを検知すること、
−  安全検知がサードパーティーアプリケーション上で成功裏に実施された後に、サードパーティーアプリケーションがインストールされる際のそのセキュリティー、真正性、および信頼性を確かにする目的でサードパーティーアプリケーションにデジタル署名するために集中型セキュアマネージメントシステムのキーを使用すること、
−  サードパーティーアプリケーションに関する識別子、認証クレデンシャル、および関連属性の統一配布のマネージメントを実行すること、
−  生成、発行、および取り消しなど、すべての関連したデジタル証明書上での統一マネージメントを実行すること。
【００３８】
指摘されなければならないこととして、サードパーティーアプリケーション上での集中型セキュアマネージメントシステムのセキュリティーチェックは、任意の既存のおよび将来のソリューション、標準、および基準の様式に準拠することができる。
【００３９】
実装においては、集中型セキュアマネージメントシステム４００、および、その集中型セキュアマネージメントシステム４００が含む受信デバイス４０１、認証デバイス４０２、第１の転送デバイス４０３、および第２の転送デバイス４０４は、ソフトウェア、ハードウェア、およびソフトウェアとハードウェアの組合せの形態で実装されることが可能である。たとえば、当業者なら、その手段を適切に実施するためのさまざまな種類のデバイス、たとえば、マイクロプロセッサ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）、および／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などをよく知っている。この実施形態による集中型セキュアマネージメントシステムのそれぞれのコンポーネントは、物理的に個別に実現されて、互いに動作可能に接続されることが可能である。
【００４０】
オペレーションにおいては、上述の図４とともに説明されている実施形態の、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステムは、上述のサードパーティーアプリケーション上での集中型セキュアマネージメントを実行するための方法を実施することができる。このシステムを使用することによって、小規模および中規模サービスプロバイダにとっては、多額のコストを節約すること、および負担を低減することが可能であり（それは、ユーザおよび保護されているリソースのマネージメントを担当するだけですむということを意味し）、またさらに、大規模サービスプロバイダは、サードパーティーアプリケーション上での集中型マネージメントを伴って、それによって個別にデプロイされる複数の内部リソースサーバを提供するようになることが可能である。さらに、本発明のソリューションを使用することによって、サードパーティーアプリケーションがさらにセキュアであり信頼できるということを確かにすることができる。なぜなら、そのサードパーティーアプリケーションは、信頼できるサードパーティーメカニズム（すなわち、本発明の集中型セキュアマネージメントシステム）によって安全管理されるためである。
【００４１】
同じ本発明のコンセプトのもとで、本発明のさらに別の態様によれば、少なくとも１つの許可サーバと、少なくとも１つのリソースサーバと、ユーザエージェントと、サードパーティーアプリケーションと、本発明による、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステムとを含む通信システムが提供される。さらに、この通信システムは、その他のネットワーク要素、たとえばルータなどを含むことができる。
【００４２】
サードパーティーアプリケーション上での集中型セキュアマネージメントを実行するための方法、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステム、および、少なくとも１つの許可サーバと、少なくとも１つのリソースサーバと、ユーザエージェントと、サードパーティーアプリケーションと、本発明による、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステムとを含む通信システムが、いくつかの例示的な実施形態を用いて具体的に説明されているが、それらの実施形態は、限定的なものではなく、例示的なものとみなされるべきであり、当業者なら、本発明の趣旨および範囲内でさまざまな種類の変形および修正を実施することができる。したがって本発明は、それらの実施形態に限定されるものではなく、本発明の範囲は、添付の特許請求の範囲によってのみ画定される。
【誤訳訂正２】
【訂正対象書類名】特許請求の範囲
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【特許請求の範囲】
【請求項１】
ユーザが許可サーバによって承認された後でユーザにアクセス可能なリソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーションに関する集中型セキュアマネージメントを実行するための方法であって、集中型マネージメントのためのサードパーティーアプリケーションの集中型セキュアマネージメントシステムが、サードパーティーアプリケーションのセキュリティーを検証すること、およびサードパーティーアプリケーションにデジタル署名することを担当し、集中型セキュアマネージメントシステムがサードパーティーアプリケーションを認証することができる認証クレデンシャルを発行し、当該方法が、
サードパーティーアプリケーションから集中型セキュアマネージメントシステムへのサードパーティーアプリケーションの識別子、認証クレデンシャル、およびアクセス許可を区別可能な様式で集中型セキュアマネージメントシステムによって受信するステップと、
アクセス許可が、集中型セキュアマネージメントシステムからまたはサードパーティーアプリケーションから直接、受信されるかどうかを許可サーバが区別することができるように、サードパーティーアプリケーションを成功裏に認証した後に、集中型セキュアマネージメントシステムによって、アクセス許可を許可サーバへ転送するステップと、
アクセス許可が有効である場合には、許可サーバから集中型セキュアマネージメントシステムによって、サードパーティーアプリケーションに対するユーザの保護されているリソースにアクセスするためのアクセストークンを受信するステップとを含むことを特徴とする、方法。
【請求項２】
アクセス許可およびアクセストークンが、ＩＥＴＦによって定義されている認証プロトコルＯＡｕｔｈ２．０に準拠しており、および／または認証クレデンシャルが、デジタル証明書、キー、またはパスワードのうちの１つである、
請求項１に記載の方法。
【請求項３】
サードパーティーアプリケーションがアクセスに関して許可される前に、ユーザが、サードパーティーアプリケーションがアクセス許可を使用することによってアクセストークンを入手する目的でアクセス許可を入手するように、許可サーバによって認証されなければならず、ならびに／または
許可サーバがアクセス許可をサードパーティーアプリケーションへ送信した後に、サードパーティーアプリケーションが、そのサードパーティーアプリケーションの識別子、認証クレデンシャル、およびアクセス許可を集中型セキュアマネージメントシステムへ送信する、
請求項１または２に記載の方法。
【請求項４】
サードパーティーアプリケーションが、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスすることを要求したときに、サードパーティーアプリケーションが、有効なアクセストークンを有していない場合には、リソースサーバが、サードパーティーアプリケーションのアクセス要求をユーザエージェントへリダイレクトするステップ、および／または
許可サーバが、集中型セキュアマネージメントシステムを通じてサードパーティーアプリケーションにアクセストークンを発行した後に、サードパーティーアプリケーションが、ユーザの保護されているリソースにアクセスするためにアクセストークンをリソースサーバに提示するステップ
をさらに含む、請求項１から３のいずれか一項に記載の方法。
【請求項５】
許可サーバがユーザを認証することが、ユーザエージェントによって許可サーバに対して直接認証を行うことを介して行われ、
アクセス許可が、許可サーバによってユーザエージェントを通じてサードパーティーアプリケーションへ送信される、
請求項３に記載の方法。
【請求項６】
許可サーバがユーザを認証することが、ユーザエージェントによって認証のために集中型セキュアマネージメントシステムを通じて許可サーバへリダイレクトすることを介して行われ、
アクセス許可が許可サーバによって集中型セキュアマネージメントシステムおよびユーザエージェントを通じてサードパーティーアプリケーションへ送信されるステップ、またはアクセス許可が許可サーバによってユーザエージェントを通じてサードパーティーアプリケーションへ送信されるステップのうちの少なくとも１つが実行される、
請求項３に記載の方法。
【請求項７】
区別可能な様式が、サードパーティーアプリケーションが識別子、認証クレデンシャル、およびアクセス許可を個別にパッケージする様式、またはサードパーティーアプリケーションが識別子、認証クレデンシャル、およびアクセス許可を個別にマークする様式のうちの１つを含む、請求項１から３のいずれか一項に記載の方法。
【請求項８】
リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーションに関する集中型セキュアマネージメントを実行するように構成されたシステムであって、当該システムが、サードパーティーアプリケーションのセキュリティーを検証すること、およびサードパーティーアプリケーションにデジタル署名することを担当し、当該システムがサードパーティーアプリケーションを認証することができる認証クレデンシャルを発行するように構成され、当該システムが、
区別可能な様式でサードパーティーアプリケーションによって送信されたサードパーティーアプリケーションの識別子、認証クレデンシャル、およびアクセス許可を受信するように構成された第１の受信デバイスと、
識別子、認証クレデンシャル、およびアクセス許可を受信した後に、識別子および認証クレデンシャルを使用してサードパーティーアプリケーションを認証するように構成された第１の認証デバイスと、
アクセス許可が、システムからまたはサードパーティーアプリケーションから直接、受信されるかどうかを許可サーバが区別することができるように、サードパーティーアプリケーションを成功裏に認証した後に、サードパーティーアプリケーションのアクセス許可を許可サーバへ転送するように構成された第１の転送デバイスと、
許可サーバによって発行されたアクセストークンをサードパーティーアプリケーションへ転送するように構成された第２の転送デバイスと含むことを特徴とする、システム。
【請求項９】
個人の開発者またはサービスプロバイダによって開発されて、デジタル署名のために個人の開発者またはサービスプロバイダのプライベートキーを使用するサードパーティーアプリケーションを受信するように構成された第２の受信デバイスと、
個人の開発者またはサービスプロバイダによって開発されたデジタル証明書を使用して、第２の受信デバイスによって受信されたサードパーティーアプリケーションのデジタル署名を認証するように構成された第２の認証デバイスと、
第２の認証デバイスの成功裏の認証の後に、サードパーティーアプリケーションが、悪意のあるコードまたはウイルスを含んでいるかどうかを検知するように構成された安全チェックデバイスと、
サードパーティーアプリケーションを成功裏に安全チェックした後に、システムのプライベートキーを使用してサードパーティーアプリケーションにデジタル署名するように構成されたデジタル署名デバイスと、
サードパーティーアプリケーションに関する識別子、認証クレデンシャル、および関連属性の統一配布を管理するように構成されたサードパーティーアプリケーションレジストリ／マネージメントデバイスと、
すべての関連したデジタル証明書を管理するように構成された証明書マネージメントデバイスと
をさらに含む、請求項８に記載のシステム。
【請求項１０】
アクセス許可およびアクセストークンが、ＩＥＴＦによって定義されている認証プロトコルＯＡｕｔｈ２．０に準拠しており、ならびに／または
認証クレデンシャルが、デジタル証明書、キー、もしくはパスワードのうちの１つであり、ならびに／または
デジタル証明書上での証明書マネージメントデバイスのマネージメントが、生成、発行、および取り消しを含む、
請求項８または９に記載のシステム。
【請求項１１】
すべての関連したデジタル証明書上での統一マネージメントが、生成、発行、および取り消しを含み、ならびに／または
許可サーバがアクセス許可をサードパーティーアプリケーションへ送信した後に、サードパーティーアプリケーションが、そのサードパーティーアプリケーションの識別子、認証クレデンシャル、およびアクセス許可をシステムへ送信するように構成され、ならびに／または
サードパーティーアプリケーションがアクセスに関して許可される前に、ユーザが、サードパーティーアプリケーションがアクセス許可を用いてアクセストークンを入手する目的でアクセス許可を入手するように、許可サーバによってユーザエージェントを通じて認証されなければならず、ならびに／または
サードパーティーアプリケーションが、リソースサーバ内のユーザの保護されているリソースにアクセスすることを要求したときに、サードパーティーアプリケーションが、有効なアクセストークンを有していない場合には、リソースサーバが、サードパーティーアプリケーションのアクセス要求をユーザエージェントへリダイレクトし、ならびに／または
許可サーバが、システムを通じてサードパーティーアプリケーションにアクセストークンを発行した後に、サードパーティーアプリケーションが、ユーザの保護されているリソースにアクセスするためにアクセストークンをリソースサーバに提示する、
請求項８から１０のいずれか一項に記載のシステム。
【請求項１２】
許可サーバが、直接的にユーザエージェントと通信することによってユーザを認証するように構成される、
請求項１１に記載のシステム。
【請求項１３】
許可サーバが、ユーザエージェントからリダイレクトを介してシステムを通じてユーザの認証を受信するように構成され、
許可サーバが、１）アクセス許可をシステムおよびユーザエージェントを通じてサードパーティーアプリケーションへ送信するステップ、または２）アクセス許可をユーザエージェントを通じてサードパーティーアプリケーションへ送信するステップのうちの少なくとも１つを実行するように構成される、
請求項１１に記載のシステム。
【請求項１４】
区別可能な様式が、サードパーティーアプリケーションが識別子、認証クレデンシャル、およびアクセス許可を個別にパッケージする様式、またはサードパーティーアプリケーションが識別子、認証クレデンシャル、およびアクセス許可を個別にマークする様式のうちの１つを含む、請求項８から１０のいずれか一項に記載のシステム。
【請求項１５】
少なくとも１つの許可サーバと、
少なくとも１つのリソースサーバと、
ユーザエージェントと、
サードパーティーアプリケーションと、
請求項８から１４のいずれか一項に記載されている、リソースサーバ内に格納されているユーザの保護されているリソースにアクセスするためにサードパーティーアプリケーション上での集中型セキュアマネージメントを実行するためのシステムと
を含む、通信システム。