JP6494149B2 - 認可処理方法およびデバイス - Google Patents

Description

本発明は、マシン・ツー・マシン通信技術の分野に関し、特に、認可処理方法およびデバイスに関する。

マシン・ツー・マシン通信（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ， Ｍ２Ｍ）は、インテリジェントなマシンインタラクションを中核とする、ネットワークアプリケーションおよびサービスである。マシン・ツー・マシン通信において、ユーザがモニタリング、コマンド処理およびディスパッチ処理、ならびにデータの収集および測定等を行うための、情報に関する要件を満たすべく、無線または有線の通信モジュールおよびアプリケーション処理ロジックがマシンに組み込まれる。Ｍ２Ｍシステムおいて、例えば電気メータ検針およびスマート家電といった各種Ｍ２Ｍサービスを実現するべく、各種センサのような各種Ｍ２Ｍデバイスが、Ｍ２Ｍゲートウェイを用いてＭ２Ｍサービスプラットフォームに直接アクセスする。Ｍ２Ｍサービスプラットフォームによって提供されるサービス能力を用いることで、Ｍ２Ｍデバイスにより収集されるデータを取得する、またはＭ２Ｍデバイスに対して制御および管理を行うことができる。

既存のＭ２Ｍ仕様において、ＲＥＳＴｆｕｌ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）アーキテクチャを用いることにより、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォーム、およびそれらによって提供されるサービス能力は、リソースとして抽象化され、一意のリソース識別子、すなわち、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を有する。アクセス先リソースについてのシステムのアクセス制御機能を実現するべく、各アクセス先リソースについて対応するアクセス権限が設定されることがあり、ＡＣＰ（ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ）リソースのようなアクセス制御ポリシーリソースが用いられる。

アクセス先リソースが属するデバイスは、アクセスデバイスのリソース要求メッセージを受信した場合、そのアクセス先リソースのアクセス制御ポリシー識別子ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤに従って、対応するアクセス制御ポリシーリソースを取得する。アクセス制御ポリシーリソースの各アクセス制御ルールは、３タプルの＜ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ， ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔｓ， ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓ＞であると考えてよい。ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓは、オペレーション許可を有するアクセスデバイスの識別子（これはＣＳＥ−ＩＤ、ＡＥ−ＩＤ、もしくはｓｅｒｖｉｃｅＰｒｏｖｉｄｅｒ ｄｏｍａｉｎであってよく、またはＡｌｌであってもよい）を示し、ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓは、ルールにより許可されたオペレーション許可（これはＲｅｔｒｉｅｖｅ、Ｃｒｅａｔｅ、Ｕｐｄａｔｅ、Ｄｅｌｅｔｅ、Ｄｉｓｃｏｖｅｒｙ、またはＮｏｔｉｆｙのうちの１つまたは複数を含んでよい）を示し、ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔｓは、任意選択的であり、ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓにおいて規定されるオペレーション許可をａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓが有するための、例えば時間範囲内であることおよび地理的領域内にあることといった条件を定義する。任意選択的な方式において、ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔｓの値はヌルであってよく、すなわち、オペレーション許可のための条件は限定されず、これについては説明しない。アクセス先リソースが属するデバイスは、取得されたアクセス制御ポリシーリソース内のａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ属性がアクセスデバイスの識別子を含むか否かと、ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓ属性がアクセス先リソースに対してアクセスデバイスが要求するオペレーションを含むか否かとに従って、アクセスデバイスがアクセス先リソースにアクセスする権限を有するか否かを判定する。これら２つの条件の両方が満足される場合にのみ、アクセスデバイスがアクセス制御権限チェックに合格することを示す。

Ｍ２Ｍシステムにおいて、アクセスデバイス識別子は、アクセスデバイスのアイデンティティを識別するのに用いられる。具体的には、アクセスデバイスは、アプリケーションエンティティ（Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｔｉｔｙ， ＡＥ）または共通サービスエンティティ（Ｃｏｍｍｏｎ Ｓｅｒｖｉｃｅｓ Ｅｎｔｉｔｙ， ＣＳＥ）であってよい。アクセスデバイス識別子は、アクセスデバイスが登録する共通サービスエンティティ、すなわち、Ｒｅｇｉｓｔｒａｒ ＣＳＥ（統一してレジストラと呼称する）により割り当てられる。従来技術においては、アクセスデバイスが異なる複数のレジストラに登録することによって、または別の理由によって、同一のアクセスデバイスの割り当てられたアクセスデバイス識別子が変更された場合、アクセスデバイスは、Ｍ２Ｍシステムにおいてアクセスデバイスに対して構成されている元のアクセス制御ポリシーを用いることができなくなる。一例として、ＡＥを用いる。ＡＥがローカルＩＤのためにＣＳＥ１に登録した場合、ＡＥ−ＩＤ１がＡＥに割り当てられる。ＡＥがオフラインになった後に、ＡＥがＣＳＥ２に登録した場合、ＡＥ−ＩＤ２がＡＥに割り当てられる。この場合、Ｍ２ＭシステムにおけるＡＥの識別子が変更され、ＡＥ−ＩＤ１に関連付けられている元の認可関係（例えば、ＡＣＰ）が新たなＡＥ−ＩＤ２に適用できなくなり、管理者がＡＥ−ＩＤ２に関してＡＣＰを再設定または付加する必要があることは明らかである。これは、Ｍ２Ｍデバイスのサービス連続性およびユーザエクスペリエンスに著しい影響を及ぼす。例えば、Ｍ２Ｍシステムにおいて、リソースＸに対応するＡＣＰリソースを以下の表に示す。

この表から、アクセスデバイス識別子ＡＥ−ＩＤ１に対応するアクセスデバイスは、リソースＸに対するＲｅｔｒｉｅｖｅまたはＣｒｅａｔｅのアクセス権限を有することがわかる。しかしながら、何らかの理由により、例えば、アクセスデバイスが別のレジストラに登録することにより、Ｍ２Ｍシステムによって割り当てられたアクセスデバイス識別子がＡＥ−ＩＤ２に変更された場合、ＡＣＰリソースがアクセスデバイスに適用できなくなり、アクセスデバイスはリソースＸに対するＲｅｔｒｉｅｖｅまたはＣｒｅａｔｅのアクセス権限を取得できなくなる。

本発明は、アクセスデバイスの識別子が変更された場合にアクセスデバイスが元の認可関係を用いることができなくなるという技術的課題を解決するべく、認可処理方法およびデバイスを提供する。

第１の態様によれば、本発明は、マシン・ツー・マシン通信における認可処理方法であって、アクセスデバイスにより送信された第１認可更新要求を受信する段階であって、第１認可更新要求は、アクセスデバイスの第１識別子を含む、段階と、第１認可更新応答をアクセスデバイスに送信する段階であって、第１認可更新応答は、署名要求情報を含み、署名要求情報は、検証情報に署名するようアクセスデバイスに命令する、段階と、アクセスデバイスにより送信された署名検証要求を受信する段階であって、署名検証要求は、第１識別子と、検証情報と、検証情報の署名とを含み、検証情報の署名は、アクセスデバイスが鍵を用いて検証情報に署名することにより生成される、段階と、検証情報に従って、記憶された第１認可関係を取得する段階と、受信された署名検証要求における検証情報の署名と第１認可関係に記憶された検証情報の署名とに従って、署名検証要求における検証情報の署名が有効であると判定する段階と、第１識別子に従って第１認可関係を更新する段階とを備える方法を提供する。

第１の態様に関連して、第１の態様の第１の可能な実現形態において、当該方法は、アクセスデバイスにより送信された第１認可更新要求を受信する段階の前に、リソースサーバが、アクセスデバイスにより送信されたリソースアクセス要求を受信する段階であって、リソースアクセス要求は、第１識別子とアクセス先リソースの識別子とを含む、段階と、リソースサーバが、第１識別子とアクセス先リソースの識別子とに従って、アクセスデバイスがアクセス先リソースの識別子に対応するリソースにアクセスする権限を有さないと判定する段階と、リソースサーバが、アクセス先リソースの識別子に対応するリソースにアクセスするためのアクセスデバイスの要求を拒否し、リダイレクトアドレスを含むリソースアクセス応答をアクセスデバイスに送信する段階であって、リダイレクトアドレスは、認可サーバの認可更新ポートアドレスであり、それによりアクセスデバイスは、認可更新ポートアドレスに従って第１認可更新要求を認可サーバに送信する、段階とをさらに備える。

第１の態様または第１の態様の第１の可能な実現形態に関連して、第１の態様の第２の可能な実現形態において、第１識別子に従って第１認可関係を更新する段階は、具体的には、第１認可関係における第２識別子を第１識別子に変更する段階であって、第２識別子は、アクセスデバイスにより用いられていた識別子である、段階である。

第１の態様、第１の態様の第１の可能な実現形態、または第１の態様の第２の可能な実現形態に関連して、第１の態様の第３の可能な実現形態において、当該方法は、アクセスデバイスにより送信された第１認可更新要求を受信する段階の前に、アクセス先リソースの識別子に対応するリソースへのアクセスデバイスによるアクセスに対して初期認可を行う段階をさらに備える。

第１の態様の第３の可能な実現形態に関連して、第１の態様の第４の可能な実現形態において、検証情報は、アクセスデバイスにより記憶された第２識別子であり、署名検証要求は、第１識別子の署名をさらに含み、第１識別子の署名は、アクセスデバイスが鍵を用いて第１識別子に署名することにより生成され、当該方法は、署名検証要求における検証情報の署名が有効であると判定する段階の後に、第１認可関係に記憶された検証情報の署名を第１識別子の署名に変更する段階をさらに備える。

第１の態様の第４の可能な実現形態に関連して、第１の態様の第５の可能な実現形態において、アクセス先リソースの識別子に対応するリソースへのアクセスデバイスによるアクセスに対して初期認可を行う段階は、具体的には、リソース作成要求をリソースサーバに送信する段階であって、リソース作成要求は、予め設定されたアクセス制御ポリシーとアクセス先リソースの識別子とを含み、予め設定されたアクセス制御ポリシーは、第２識別子を含む、段階と、リソースサーバにより送信されたリソース作成応答を受信する段階であって、リソース作成応答は、リソースサーバがアクセス制御ポリシーリソースを作成することに成功し、アクセス制御ポリシーリソースをアクセス先リソースの識別子に対応するリソースにバインドすることに成功したことを示すものであり、アクセス制御ポリシーリソースは、予め設定されたアクセス制御ポリシーを記録するのに用いられる、段階と、署名要求をアクセスデバイスに送信する段階であって、署名要求は、第２識別子に署名するようアクセスデバイスに命令するものである、段階と、アクセスデバイスにより送信された署名応答を受信する段階であって、署名応答は、第２識別子の署名を含む、段階と、第１認可関係を記憶する段階であって、第１認可関係は、第２識別子と、第２識別子の署名と、アクセス先リソースの識別子との間の対応関係を含む、段階とである。

第１の態様の第２から第５の可能な実現形態のいずれか一つに関連して、第１の態様の第６の可能な実現形態において、当該方法は、第１識別子に従って第１認可関係を更新する段階の後に、第２認可更新要求をリソースサーバに送信する段階であって、第２認可更新要求は、第１識別子と、第２識別子と、アクセス先リソースの識別子とを含む、段階をさらに備える。

第１の態様の第３の可能な実現形態に関連して、第１の態様の第７の可能な実現形態において、検証情報は、認可クレデンシャルであり、第１認可更新要求は、認可クレデンシャルをさらに含み、当該方法は、第１認可更新応答をアクセスデバイスに送信する段階の前に、認可クレデンシャルに従って、認可クレデンシャルを含む第１認可関係が存在すること、および、第１認可関係においてバインドされているアクセスデバイス識別子が第１識別子ではないことを判定する段階をさらに備える。

第１の態様の第７の可能な実現形態に関連して、第１の態様の第８の可能な実現形態において、アクセス先リソースの識別子に対応するリソースへのアクセスデバイスによるアクセスに対して初期認可を行う段階は、具体的には、アクセスデバイスの認可要求を受信する段階であって、認可要求は、第２識別子と、アクセス先リソースの識別子と、ユーザがアクセスデバイスのリソースアクセスに同意するという認証情報とを含む、段階と、認証情報に従って、ユーザがアクセス先リソースの識別子に対応するリソースにアクセスする権限を有すると判定された場合、認可クレデンシャルを生成する段階と、アクセス先リソースの識別子に対応するリソースが位置するリソースサーバに認可バインド要求を送信する段階であって、認可バインド要求は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含む、段階と、リソースサーバにより送信された認可バインド応答を受信する段階であって、認可バインド応答は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とのバインドが成功したことを示す情報を含む、段階と、認可応答をアクセスデバイスに送信する段階であって、認可応答は、認可クレデンシャルと、アクセス先リソースの識別子と、認可クレデンシャルに署名するよう命令する情報とを含む、段階と、アクセスデバイスにより送信された署名バインド要求を受信する段階であって、署名バインド要求は、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成される、段階と、第１認可関係を記憶する段階であって、第１認可関係は、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子との間の対応関係を含む、段階とである。

第１の態様の第７または第８の可能な実現形態に関連して、第１の態様の第９の可能な実現形態において、当該方法は、第１識別子に従って第１認可関係を更新する段階の後に、第２認可更新要求をリソースサーバに送信する段階であって、第２認可更新要求は、第１識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含む、段階をさらに備える。

第２の態様によれば、マシン・ツー・マシン通信における認可処理方法であって、アクセスデバイスにより送信された第１リソースアクセス要求を受信する段階であって、第１リソースアクセス要求は、アクセスデバイスの第１識別子と、アクセス先リソースの識別子と、認可クレデンシャルとを含む、段階と、認可クレデンシャルに従って、認可クレデンシャルとアクセス先リソースの識別子とを含む第２認可関係が存在すること、および、第２認可関係においてバインドされているアクセスデバイス識別子が第１識別子ではないことを判定する段階と、第１リソースアクセス応答をアクセスデバイスに送信する段階であって、第１リソースアクセス応答は、署名要求情報を含み、署名要求情報は、認可クレデンシャルに署名するようアクセスデバイスに命令するものである、段階と、アクセスデバイスにより送信された第２リソースアクセス要求を受信する段階であって、第２リソースアクセス要求は、第１識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成される、段階と、署名データ要求を認可サーバに送信する段階であって、署名データ要求は、認可クレデンシャルを含む、段階と、認可サーバにより送信された署名データ応答を受信する段階であって、署名データ応答は、認可クレデンシャルの署名を含み、認可クレデンシャルの署名は、第１認可関係に記憶され、認可サーバにより認可クレデンシャルに従って取得される、段階と、第２リソースアクセス要求における認可クレデンシャルの署名と、認可サーバにより送信された認可クレデンシャルの署名とに従って、第２リソースアクセス要求における認可クレデンシャルの署名が有効であると判定する段階と、第１識別子に従って第２認可関係を更新する段階とを備える方法が提供される。

第２の態様に関連して、第２の態様の第１の可能な実現形態において、当該方法は、第１識別子に従って第２認可関係を更新する段階の後に、第２リソースアクセス応答をアクセスデバイスに送信する段階であって、第２リソースアクセス応答は、アクセス先リソースの識別子に対応するリソースを含む、段階をさらに備える。

第２の態様または第２の態様の第１の可能な実現形態に関連して、第２の態様の第２の可能な実現形態において、第１識別子に従って第２認可関係を更新する段階は、具体的には、第２認可関係における第２識別子を第１識別子に変更する段階であって、第２識別子は、アクセスデバイスにより用いられていた識別子である、段階である。

第２の態様の第２の可能な実現形態に関連して、第２の態様の第３の可能な実現形態において、当該方法は、アクセスデバイスにより送信された第１リソースアクセス要求を受信する段階の前に、認可サーバが、アクセスデバイスにより送信された認可要求を受信する段階であって、認可要求は、第２識別子と、アクセス先リソースの識別子と、ユーザがアクセスデバイスのリソースアクセスに同意するという認証情報とを含む、段階と、認可サーバが、認証情報に従って、ユーザがアクセス先リソースの識別子に対応するリソースにアクセスする権限を有すると判定し、認可クレデンシャルを生成し、アクセス先リソースの識別子に対応するリソースが位置するリソースサーバに認可バインド要求を送信する段階であって、認可バインド要求は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含む、段階と、リソースサーバが、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子との間の対応関係を第２認可関係として記憶し、認可バインド応答を認可サーバに送信する段階であって、認可バインド応答は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とのバインドが成功したことを示す情報を含む、段階と、認可サーバが、認可応答をアクセスデバイスに送信する段階であって、認可応答は、認可クレデンシャルと、アクセス先リソースの識別子と、認可クレデンシャルに署名するよう命令する情報とを含む、段階と、認可サーバが、アクセスデバイスにより送信された署名バインド要求を受信する段階であって、署名バインド要求は、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成される、段階と、認可サーバが、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子との間の対応関係を第１認可関係として記憶する段階とをさらに備える。

第２の態様、または第２の態様の第１から第３の可能な実現形態のいずれか一つに関連して、第２の態様の第４の可能な実現形態において、当該方法は、第２リソースアクセス要求における認可クレデンシャルの署名が有効であると判定する段階の後に、第３認可更新要求を認可サーバに送信する段階であって、第３認可更新要求は、認可クレデンシャルと第１識別子とを含む、段階と、認可サーバにより送信された第３認可更新応答を受信する段階であって、第３認可更新応答は、認可サーバが認可更新を行うことに成功したことを示す情報を含む、段階とをさらに備える。

第３の態様によれば、マシン・ツー・マシン通信における認可サーバであって、アクセスデバイスにより送信された第１認可更新要求を受信するよう構成された受信モジュールであって、第１認可更新要求は、アクセスデバイスの第１識別子を含む、受信モジュールと、第１認可更新応答をアクセスデバイスに送信するよう構成された送信モジュールであって、第１認可更新応答は、署名要求情報を含み、署名要求情報は、検証情報に署名するようアクセスデバイスに命令するものである、送信モジュールと、受信モジュールは、アクセスデバイスにより送信された署名検証要求を受信するようさらに構成され、署名検証要求は、第１識別子と、検証情報と、検証情報の署名とを含み、検証情報の署名は、アクセスデバイスが鍵を用いて検証情報に署名することにより生成され、受信モジュールにより受信された署名検証要求における検証情報に従って、記憶された第１認可関係を取得するよう構成された取得モジュールと、受信された署名検証要求における検証情報の署名と第１認可関係に記憶された検証情報の署名とに従って、署名検証要求における検証情報の署名が有効であると判定するよう構成された判定モジュールと、第１識別子に従って第１認可関係を更新するよう構成された更新モジュールとを備える認可サーバがさらに提供される。

第３の態様に関連して、第３の態様の第１の可能な実現形態において、更新モジュールは、具体的には、第１認可関係における第２識別子を第１識別子に変更するよう構成され、第２識別子は、アクセスデバイスにより用いられていた識別子である。

第３の態様または第３の態様の第１の可能な実現形態に関連して、第３の態様の第２の可能な実現形態において、認可サーバは、アクセス先リソースの識別子に対応するリソースへのアクセスデバイスによるアクセスに対して初期認可を行うよう構成された初期認可モジュールをさらに備える。

第３の態様の第２の可能な実現形態に関連して、第３の態様の第３の可能な実現形態において、検証情報は、アクセスデバイスにより記憶された第２識別子であり、署名検証要求は、第１識別子の署名をさらに含み、第１識別子の署名は、アクセスデバイスが鍵を用いて第１識別子に署名することにより生成され、更新モジュールは、第１認可関係に記憶された検証情報の署名を第１識別子の署名に変更するようさらに構成される。

第３の態様の第３の可能な実現形態に関連して、第３の態様の第４の可能な実現形態において、初期認可モジュールは、具体的には、リソース作成要求をリソースサーバに送信することであって、リソース作成要求は、予め設定されたアクセス制御ポリシーとアクセス先リソースの識別子とを含み、予め設定されたアクセス制御ポリシーは、第２識別子を含む、ことと、リソースサーバにより送信されたリソース作成応答を受信することであって、リソース作成応答は、リソースサーバがアクセス制御ポリシーリソースを作成することに成功し、アクセス制御ポリシーリソースをアクセス先リソースの識別子に対応するリソースにバインドすることに成功したことを示すものであり、アクセス制御ポリシーリソースは、予め設定されたアクセス制御ポリシーを記録するのに用いられる、ことと、署名要求をアクセスデバイスに送信することであって、署名要求は、第２識別子に署名するようアクセスデバイスに命令するものである、ことと、アクセスデバイスにより送信された署名応答を受信することであって、署名応答は、第２識別子の署名を含む、ことと、第１認可関係を記憶することであって、第１認可関係は、第２識別子と、第２識別子の署名と、アクセス先リソースの識別子との間の対応関係を含む、こととを行うよう構成される。

第３の態様の第１から第４の可能な実現形態のいずれか一つに関連して、第３の態様の第５の可能な実現形態において、送信モジュールは、第１認可関係が第１識別子に従って更新された後に、第２認可更新要求をリソースサーバに送信するようさらに構成され、第２認可更新要求は、第１識別子とアクセス先リソースの識別子とを含む。

第３の態様の第２の可能な実現形態に関連して、第３の態様の第６の可能な実現形態において、検証情報は、認可クレデンシャルであり、第１認可更新要求は、認可クレデンシャルをさらに含み、判定モジュールは、第１認可更新応答がアクセスデバイスに送信される前に、認可クレデンシャルに従って、認可クレデンシャルを含む第１認可関係が存在すること、および、第１認可関係においてバインドされているアクセスデバイス識別子が第１識別子ではないことを判定するようさらに構成される。

第３の態様の第６の可能な実現形態に関連して、第３の態様の第７の可能な実現形態において、初期認可モジュールは、具体的には、アクセスデバイスの認可要求を受信することであって、認可要求は、第２識別子と、アクセス先リソースの識別子と、ユーザがアクセスデバイスのリソースアクセスに同意するという認証情報とを含む、ことと、認証情報に従って、ユーザがアクセス先リソースの識別子に対応するリソースにアクセスする権限を有すると判定された場合、認可クレデンシャルを生成することと、アクセス先リソースの識別子に対応するリソースが位置するリソースサーバに認可バインド要求を送信することであって、認可バインド要求は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含む、ことと、リソースサーバにより送信された認可バインド応答を受信することであって、認可バインド応答は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とのバインドが成功したことを示す情報を含む、ことと、認可応答をアクセスデバイスに送信することであって、認可応答は、認可クレデンシャルと、アクセス先リソースの識別子と、認可クレデンシャルに署名するよう命令する情報とを含む、ことと、アクセスデバイスにより送信された署名バインド要求を受信することであって、署名バインド要求は、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成される、ことと、第１認可関係を記憶することであって、第１認可関係は、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子との間の対応関係を含む、こととを行うよう構成される。

第３の態様の第６または第７の可能な実現形態に関連して、第３の態様の第８の可能な実現形態において、送信モジュールは、第１認可関係が第１識別子に従って更新された後に、第２認可更新要求をリソースサーバに送信するようさらに構成され、第２認可更新要求は、第１識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含む。

第４の態様によれば、マシン・ツー・マシン通信におけるリソースサーバであって、アクセスデバイスにより送信された第１リソースアクセス要求を受信するよう構成された受信モジュールであって、第１リソースアクセス要求は、アクセスデバイスの第１識別子と、アクセス先リソースの識別子と、認可クレデンシャルとを含む、受信モジュールと、認可クレデンシャルに従って、認可クレデンシャルとアクセス先リソースの識別子とを含む第２認可関係が存在すること、および、第２認可関係においてバインドされているアクセスデバイス識別子が第１識別子ではないことを判定するよう構成された判定モジュールと、第１リソースアクセス応答をアクセスデバイスに送信するよう構成された送信モジュールであって、第１リソースアクセス応答は、署名要求情報を含み、署名要求情報は、認可クレデンシャルに署名するようアクセスデバイスに命令するものである、送信モジュールと、受信モジュールは、アクセスデバイスにより送信された第２リソースアクセス要求を受信するようさらに構成され、第２リソースアクセス要求は、第１識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成され、送信モジュールは、署名データ要求を認可サーバに送信するようさらに構成され、署名データ要求は、認可クレデンシャルを含み、受信モジュールは、認可サーバにより送信された署名データ応答を受信するようさらに構成され、署名データ応答は、認可クレデンシャルの署名を含み、認可クレデンシャルの署名は、第１認可関係に記憶され、認可サーバにより認可クレデンシャルに従って取得され、判定モジュールは、第２リソースアクセス要求における認可クレデンシャルの署名と、認可サーバにより送信された認可クレデンシャルの署名とに従って、第２リソースアクセス要求における認可クレデンシャルの署名が有効であると判定するようさらに構成され、第１識別子に従って第２認可関係を更新するよう構成された更新モジュールとを備えるリソースサーバがさらに提供される。

第４の態様に関連して、第４の態様の第１の可能な実現形態において、送信モジュールは、第２認可関係が第１識別子に従って更新された後に、第２リソースアクセス応答をアクセスデバイスに送信するようさらに構成され、第２リソースアクセス応答は、アクセス先リソースの識別子に対応するリソースを含む。

第４の態様または第４の態様の第１の可能な実現形態に関連して、第４の態様の第２の可能な実現形態において、更新モジュールは、具体的には、第２認可関係における第２識別子を第１識別子に変更するよう構成され、第２識別子は、アクセスデバイスにより用いられていた識別子である。

第４の態様の第２の可能な実現形態に関連して、第４の態様の第３の可能な実現形態において、受信モジュールは、アクセス先リソースの識別子に対応するリソースへのアクセスデバイスによるアクセスに対して初期認可を認可サーバが行った後に送信された認可バインド要求を受信するようさらに構成され、認可バインド要求は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含み、記憶モジュールは、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子との間の対応関係を第２認可関係として記憶するよう構成される。

本発明において提供される技術的解決手段によれば、Ｍ２Ｍシステムにおけるアクセスデバイスの識別子が、ある理由により変更された場合、Ｍ２Ｍシステムは、検証情報の署名が有効であるか否かを判定することにより、すなわち、アクセスデバイスにより送信された検証情報の署名が、認可サーバにより記憶された第１認可関係における検証情報の署名と同一であるか否かを比較することにより、アクセスデバイスのアイデンティティを識別し、既存の認可関係をさらに更新することができ、それによりアクセスデバイスは、既存の認可関係を継続して用いることができる。よって、シームレスなリソースアクセスが実現され、Ｍ２Ｍシステムのサービス連続性が保証される。

本発明の実施形態における技術的解決手段をより明確に説明するべく、以下、実施形態を説明するために必要な添付図面について簡潔に説明する。以下の説明における添付図面は、本発明のいくつかの実施形態を示しているに過ぎず、当業者であれば、創造的な努力なく、これらの添付図面から他の図面をさらに導き出し得ることは明らかである。

本発明の一実施形態に係る認可更新システムのブロック図である。

本発明の一実施形態に係る、マシン・ツー・マシン通信における認可処理方法のフローチャートである。

本発明の一実施形態に係る別の認可処理方法のフローチャートである。

本発明の一実施形態に係る、ＡＣＰ認可アーキテクチャに基づいて行われる初期認可のフローチャートである。

本発明の一実施形態に係る、ＡＣＰ認可アーキテクチャに基づいて行われる認可更新のフローチャートである。

本発明の一実施形態に係る、ＯＡｕｔｈ認可アーキテクチャに基づいて行われる初期認可のフローチャートである。 本発明の一実施形態に係る、ＯＡｕｔｈ認可アーキテクチャに基づいて行われる初期認可のフローチャートである。

本発明の一実施形態に係る、ＯＡｕｔｈ認可アーキテクチャに基づいて行われる認可更新のフローチャートである。

本発明の一実施形態に係る、ＯＡｕｔｈ認可アーキテクチャに基づいて行われる別の認可更新のフローチャートである。

本発明の一実施形態に係る認可サーバの概略構造図である。

本発明の一実施形態に係る別の認可サーバの概略構造図である。

本発明の一実施形態に係るリソースサーバの概略構造図である。

本発明の一実施形態に係る別のリソースサーバの概略構造図である。

本発明の目的、技術的解決手段、および利点をより明確にすべく、以下さらに、添付図面を参照して、本発明の実施形態を詳細に説明する。本発明を包括的に理解するべく、以下の詳細な説明は、多くの具体的な詳細に言及する。しかしながら、当業者には、これらの具体的な詳細がなくとも本発明が実現され得ることは理解されよう。他の実施形態において、実施形態を不明瞭にすることを避けるべく、周知の方法、プロセス、構成要素、および回路については詳細に説明しない。説明されている実施形態が本発明の実施形態の全てではなく一部であることは明らかである。当業者により、本発明の実施形態に基づいて創造的努力なく得られる全ての他の実施形態は、本発明の保護範囲に属するものとする。

本発明の実施形態において説明されている認可サーバおよびリソースサーバの関連し合う機能は、同一のデバイスにおける異なる複数の機能モジュールにより実現されてよく、または異なる複数のデバイスにより別々に実現されてもよいことに留意されたい。これは本発明において限定されるものではない。

加えて、下記で説明するいくつかの手順は、特定の順序に従って現れる複数のオペレーションを含む。しかしながら、これらのオペレーションは、本明細書に現れる順序に従って行われなくてよく、並行して行われてもよいことを明確に理解されたい。１０１および１０２のようなオペレーションの通し番号は、オペレーションを区別するのに用いられているに過ぎず、これらの通し番号は実行の順序を示すものではない。加えて、これらの手順は、より多くのまたはより少ないオペレーションを含んでよく、これらのオペレーションは、ある順序に従って行われてよく、または並行して行われてもよい。本明細書における「第１」および「第２」のような説明は、メッセージ、デバイス、またはモジュール等を区別するのに用いられており、順序を示すものではないことに留意されたい。加えて、「第１」および「第２」は、異なる種類を示すものではない。

図１は、本発明の一実施形態に係る認可更新システムのブロック図である。当該システムは、有線または無線の通信ネットワークを用いて互いに通信し合う複数の通信デバイスを含む。

アクセスデバイス１０２は、アプリケーションエンティティ（Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｔｉｔｙ， ＡＥ）であってよく、または共通サービスエンティティ（Ｃｏｍｍｏｎ Ｓｅｒｖｉｃｅｓ Ｅｎｔｉｔｙ， ＣＳＥ）であってもよく、レジストラ１０４を用いてＭ２Ｍシステムにアクセスし、Ｍ２Ｍシステム内の別のエンティティにより管理されるリソースにアクセスできる。

レジストラ１０４は、Ｍ２Ｍシステムにおいてアクセスデバイス１０２に登録サービスを提供する共通サービスエンティティ（Ｒｅｇｉｓｔｒａｒ ＣＳＥ， Ｒ−ＣＳＥ）であり、アクセスデバイス１０２に登録を提供すること、および、アクセスデバイス１０２にエンティティ識別子（Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｔｉｔｙ−Ｉｄｅｎｔｉｆｉｅｒ， ＡＥ−ＩＤ／Ｃｏｍｍｏｎ Ｓｅｒｖｉｃｅｓ Ｅｎｔｉｔｙ−Ｉｄｅｎｔｉｆｉｅｒ， ＣＳＥ−ＩＤ）を割り当てることを担う。エンティティ識別子は、アクセスデバイスのアイデンティティ識別子として用いられる。

認可サーバ１０６は、インフラストラクチャノード（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ， ＩＮ）に存在する共通サービスエンティティ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ−ＣＳＥ， ＩＮ−ＣＳＥ）であってよく、または、独立して動作し、ＩＮ−ＣＳＥに接続される認可サーバ（Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｓｅｒｖｅｒ， ＡＳ）であってもよく、Ｍ２Ｍシステムにおける認可関係を記憶すること、および、アクセスデバイスと、アクセスデバイスのアイデンティティ検証情報と、検証情報の署名と、アクセス先リソースの識別子との間の対応関係を維持することを担う。

リソースサーバ１０８は、通常、アクセス先リソースが位置するノードの共通サービスエンティティ（Ｈｏｓｔｉｎｇ ＣＳＥ， Ｈ−ＣＳＥ）であり、ローカルリソースの対応する認可関係を維持し、アクセスデバイス１０２により送信されるリソースアクセス要求に従ってアクセス制御判断を行い、判断結果に従ってリソースアクセス応答をアクセスデバイスに返す。

本発明は、２つの認可関係に関することに留意されたい。一方は、認可サーバにより維持されるもので、第１認可関係と呼称し、他方は、リソースサーバにより維持されるもので、第２認可関係と呼称する。加えて、本発明はさらに、２つのアクセスデバイス識別子、すなわち、第１識別子および第２識別子に関する。第２識別子は、アクセスデバイスにより用いられていた識別子であり、第２識別子に関連する認可関係は、認可サーバおよびリソースサーバ内で維持され、第２識別子は、以下の本発明の実施形態においてはＡＥ−ＩＤ１と表記する。第１識別子は、再登録の後にアクセスデバイスにより取得される識別子であり、第１識別子は、以下の本発明の実施形態においてはＡＥ−ＩＤ２と表記する。従来技術によれば、アクセスデバイスが第１識別子を用いてリソースにアクセスする場合、アクセスデバイスのアクセス要求は拒否され、そのアクセスは終了する。本発明は、アクセスデバイスが、元の認可関係を継続して用いてリソースアクセス権限を取得することができるよう、第１認可関係および第２認可関係における第２識別子を第１識別子に更新するための方法について説明する。当該方法によれば、ユーザは、対応する認可関係を再作成することなく、アクセスデバイスを用いて対応するリソースにシームレスにアクセスすることができる。これにより、アクセスデバイスのリソースアクセスが大幅に容易になる。例えば、ＯＡｕｔｈ２．０に関連するプロトコルによれば、ｔｏｋｅｎに基づく認可関係の確立には、リソースプロセッサがオンライン認可を行うことが必要であることがわかる。リソースプロセッサがオンラインでない場合、Ｍ２Ｍシステムは、アクセスデバイスに対して再認可を行うことができない。よって、ユーザは、リソースにアクセスすることができない。

本発明の本実施形態において、認可サーバ１０６は、アクセスデバイス識別子と、アクセス先リソースの識別子と、アクセスデバイスの検証情報と、検証情報の署名との間の対応関係の認可関係を記憶する。具体的には、認可サーバ１０６は、アクセスデバイス１０２に対して初期認可を行う場合、アクセスデバイス１０２から検証情報の署名を取得し、検証情報の署名を、対応するアクセスデバイス識別子、検証情報、およびアクセス先リソースの識別子と共に認可関係に記憶する。認可サーバ１０６は、アクセスデバイス１０２により送信された署名検証要求を受信した後に、アクセスデバイス１０２の元のアイデンティティを確認してよい。あるいは、認可サーバ１０６は、リソースサーバ１０８により送信された署名要求を受信した場合に、検証情報の署名をリソースサーバ１０８に送信してよく、そしてリソースサーバ１０８がアクセスデバイス１０２の元のアイデンティティを確認する。

リソースサーバ１０８は、リソースが位置するノードの共通サービスエンティティである。リソースサーバ１０８は、Ｍ２Ｍシステムにおいて、中間ノード（Ｍｉｄｄｌｅ Ｎｏｄｅ， ＭＮ）、インフラストラクチャノード（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ， ＩＮ）、またはアプリケーションサービスノード（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｎｏｄｅ， ＡＳＮ）に存在してよい。本発明においては、認可更新処理のための判定ロジックがリソースサーバ１０８内の元のアクセス制御判断モジュールに付加され、当該判定ロジックは、アクセスデバイス１０２により送信されたリソースアクセス要求に従って行われたアクセス制御判断の結果が認可されなかった場合、ローカル認可更新を始めるか、またはリソースアクセス要求を認可サーバ１０６へとリダイレクトして認可更新を行うよう構成される。加えて、本発明の一実施形態において、リソースサーバ１０８は、認可サーバ１０６から検証情報の署名を取得し、アクセスデバイス１０２から対応する検証情報の署名を取得して、アクセスデバイスの元のアイデンティティの確認を完了する。アクセスデバイス１０２の元のアイデンティティの確認が完了した後に、認可サーバ１０６がローカル認可関係を自主的に更新するか、またはリソースサーバ１０８が認可サーバ１０６による命令の下でローカル認可関係を更新する。

アクセスデバイス１０２は、アプリケーションエンティティ（ＡＥ）または共通サービスエンティティ（ＣＳＥ）であってよく、レジストラ１０４を用いてＭ２Ｍシステムにアクセスする。本発明においては、署名モジュールがアクセスデバイス１０２に付加され、当該署名モジュールは、認可サーバ１０６またはリソースサーバ１０８から署名要求を受信した場合、鍵を用いて対応する情報に署名し、認可サーバ１０６またはリソースサーバ１０８にその情報の署名を返すよう構成される。アクセスデバイスにより署名に用いられる鍵は、デバイスの配送時に設定されてよく、または別の方式で生成されてもよいことに留意されたい。鍵の具体的な形態は、本発明において限定されるものではない。

レジストラ１０４は、ＭＮ−ＣＳＥであってよく、ＩＮ−ＣＳＥまたはＡＳＮ−ＣＳＥであってもよく、アクセスデバイス１０２に識別子を割り当てることを担う。

加えて、Ｍ２Ｍシステムにおいて、リソースサーバ１０８および認可サーバ１０６は、あるデバイス内の２つの機能モジュールとして用いられてよく、またはＭ２Ｍシステムにおいて独立して動作する２つのデバイスとして用いられてもよいことに留意されたい。リソースサーバ１０８および認可サーバ１０６が、あるデバイス内の２つの機能モジュールとして用いられる場合、リソースサーバ１０８と認可サーバ１０６との間での情報交換は、当該デバイス内での情報交換であると考えられる。リソースサーバ１０８および認可サーバ１０６の具体的な表現形態は、本発明において限定されるものではない。例えば、以下の本発明の実施形態において、リソースサーバ１０８および認可サーバ１０６は、独立して動作する２つのデバイスとして説明される。

図１の認可アーキテクチャは、アクセスデバイス識別子が変更される（ＡＥがレジストラＲ−ＣＳＥ１およびＲ−ＣＳＥ２に逐次登録し、異なるＡＥ−ＩＤが割り当てられる）一例に過ぎない。異なるアクセスデバイス識別子割り当て方式によっては、アクセスデバイス識別子は、別の場合に変更され得る（例えば、アクセスデバイスが同一のレジストラに登録するが、アクセスデバイスの元の識別子が別のエンティティに割り当てられている）。加えて、リソースサーバ１０８およびレジストラ１０４は、ＩＮ−ＣＳＥに直接的に接続されてよく、他のＣＳＥの複数のホップを介してＩＮ−ＣＳＥに接続されてもよい。Ｍ２Ｍシステムの具体的な構造は、本発明において限定されるものではない。

以下、添付図面を参照して、本出願に関連する認可処理方法およびデバイスの実現形態について詳細に説明する。

図２は、本発明に係る、マシン・ツー・マシン通信における認可処理方法のフローチャートである。当該方法は、以下の段階を備える。

段階２０２：アクセスデバイスにより送信された第１認可更新要求を受信する。第１認可更新要求は、アクセスデバイスの第１識別子を含む。

任意選択的に、第１認可更新要求の宛先アドレスは、認可サーバの認可更新ポートであってよい。すなわち、認可サーバは、認可更新ポートを用いて、アクセスデバイスにより送信された第１認可更新要求を受信する。任意選択的に、第１認可更新要求は、アクセス先リソースの識別子をさらに含む。

段階２０４：第１認可更新応答をアクセスデバイスに送信する。第１認可更新応答は、署名要求情報を含み、署名要求情報は、検証情報に署名するようアクセスデバイスに命令する。

任意選択的に、署名要求情報は、署名フラグビットであってよい。署名フラグビットの値が「１」である場合、これはアクセスデバイスが検証情報に署名する必要があることを示す。あるいは、署名フラグビットの値が「２」である場合、これはアクセスデバイスが検証情報とアクセスデバイスの現在の識別子とに署名する必要があることを示す。

段階２０６：アクセスデバイスにより送信された署名検証要求を受信する。署名検証要求は、第１識別子と、検証情報と、検証情報の署名とを含み、検証情報の署名は、アクセスデバイスが鍵を用いて検証情報に署名することにより生成される。

段階２０８：検証情報に従って、記憶された第１認可関係を取得する。

段階２１０：受信された署名検証要求における検証情報の署名と第１認可関係に記憶された検証情報の署名とに従って、署名検証要求における検証情報の署名が有効であると判定する。

具体的には、認可サーバは、第１認可関係に記憶された検証情報の署名を取得し、第１認可関係に記憶された検証情報の署名を、受信された署名検証要求における検証情報の署名と比較し、第１認可関係に記憶された検証情報の署名が、受信された署名検証要求における検証情報の署名と同一である場合、署名検証要求における検証情報の署名が有効であると判定する。

段階２１２：第１識別子に従って、第１認可関係を更新する。

具体的には、認可サーバは、署名検証要求における検証情報の署名が有効であると判定した後に、アクセスデバイスの識別子が既に第１識別子に更新されていると判定する。よって、認可サーバは、ローカルで記憶された、アクセスデバイスに関連する認可関係を更新する必要がある。

任意選択的に、第１識別子に従って第１認可関係を更新する段階は、具体的には、第１認可関係における第２識別子を第１識別子に変更する段階であって、第２識別子は、アクセスデバイスにより用いられていた識別子である、段階であるか、または、第１認可関係を削除し、新たな認可関係を作成する段階であって、新たな認可関係は、第１識別子と、第１認可関係における検証情報と、第１認可関係における検証情報の署名とを含む、段階である。

具体的には、当該方法は、段階２０２の前に、リソースサーバが、アクセスデバイスにより送信されたリソースアクセス要求を受信する段階であって、リソースアクセス要求は、第１識別子とアクセス先リソースの識別子とを含む、段階と、リソースサーバが、第１識別子とアクセス先リソースの識別子とに従って、アクセスデバイスがアクセス先リソースの識別子に対応するリソースにアクセスする権限を有さないと判定する段階と、リソースサーバが、アクセス先リソースの識別子に対応するリソースにアクセスするためのアクセスデバイスの要求を拒否し、リダイレクトアドレスを含むリソースアクセス応答をアクセスデバイスに送信する段階であって、リダイレクトアドレスは、認可サーバの認可更新ポートアドレスであり、それによりアクセスデバイスは、認可更新ポートアドレスに従って第１認可更新要求を認可サーバに送信する、段階とをさらに備える。

具体的には、当該方法は、アクセスデバイスにより送信された第１認可更新要求を受信する段階の前に、認可サーバが、アクセス先リソースの識別子に対応するリソースへのアクセスデバイスによるアクセスに対して初期認可を行う段階をさらに備える。

Ｍ２ＭシステムにおいてＡＣＰ認可アーキテクチャが用いられる場合、検証情報は、第２識別子であってよい。検証情報が第２識別子である場合、認可サーバは、第２識別子と、第２識別子の署名と、アクセス先リソースの識別子とに対応する第１認可関係を記憶し、リソースサーバは、第２識別子とアクセス先リソースの識別子とに対応する第２認可関係を記憶する。具体的には、検証情報が第２識別子である場合、署名検証要求は、第１識別子の署名をさらに含み、第１識別子の署名は、アクセスデバイスが鍵を用いて第１識別子に署名することにより生成される。当該方法は、段階２１０、すなわち、署名検証要求における検証情報の署名が有効であると判定する段階の後に、第１認可関係に記憶された検証情報の署名を第１識別子の署名に変更する段階をさらに含む。認可サーバが、アクセス先リソースの識別子に対応するリソースへのアクセスデバイスによるアクセスに対して初期認可を行う段階は、具体的には、リソース作成要求をリソースサーバに送信する段階であって、リソース作成要求は、予め設定されたアクセス制御ポリシーとアクセス先リソースの識別子とを含み、予め設定されたアクセス制御ポリシーは、第２識別子を含み、それによりリソースサーバは、予め設定されたアクセス制御ポリシーに従ってアクセス制御ポリシーリソースを設定し、アクセス制御ポリシーリソースをアクセス先リソースの識別子に対応するリソースにバインドし、アクセス制御ポリシーリソースは、第２識別子を含む、段階と、リソースサーバにより送信されたリソース作成応答を受信する段階であって、リソース作成応答は、リソースサーバがアクセス制御ポリシーリソースを作成することに成功し、アクセス制御ポリシーリソースをアクセス先リソースの識別子に対応するリソースにバインドすることに成功したことを示すものであり、アクセス制御ポリシーリソースは、予め設定されたアクセス制御ポリシーを記録するのに用いられる、段階と、署名要求をアクセスデバイスに送信する段階であって、署名要求は、第２識別子に署名するようアクセスデバイスに命令するものである、段階と、アクセスデバイスにより送信された署名応答を受信する段階であって、署名応答は、第２識別子の署名を含む、段階と、第１認可関係を記憶する段階であって、第１認可関係は、第２識別子と、第２識別子の署名と、アクセス先リソースの識別子との間の対応関係を含む、段階とである。管理者が、予め設定されたアクセス制御ポリシーを認可サーバ上に作成することの可能な実現形態は、アクセスデバイス１０２が、レジストラ１０４に登録し、登録情報を生成するものであることに留意されたい。登録情報は、レジストラにより割り当てられる識別子、例えば、第２識別子と、アクセスデバイスの特徴を反映する情報、例えば、アクセスデバイスのＩＰアドレス、ＭＡＣアドレス、またはデバイスディスクリプション情報のようなコンテンツとを含み、管理者は、認可サーバにログインした後に登録情報を取得し、登録情報に従ってアクセス制御ポリシーを作成する、すなわち、アクセスデバイスがリソースにアクセスすることを可能とするルールを作成する。さらに、当該方法は、段階２１２の後に、リソースサーバにより記憶された第２認可関係を更新する段階をさらに備える。具体的には、当該方法は、第１識別子に従って第１認可関係を更新する段階の後に、第２認可更新要求をリソースサーバに送信する段階をさらに備える。第２認可更新要求は、第１識別子と、第２識別子と、アクセス先リソースの識別子とを含み、それによりリソースサーバは、第２識別子とアクセス先リソースの識別子とに従って、記憶された第２認可関係を取得し、記憶された第２認可関係における第２識別子を第１識別子に更新する。任意選択的に、認可サーバは、リソースサーバにより送信された第２認可更新応答を受信する。第２認可更新応答は、第２認可関係の更新が成功したことを示す。

ＡＣＰ認可アーキテクチャに基づいて、検証情報は、認可サーバがアクセスデバイスの第１認可更新要求を受信した後に、認可サーバにより第１認可更新応答を用いてアクセスデバイスに送信されてよく、または検証情報は、アクセスデバイスに記憶されてもよいことに留意されたい。例えば、本発明の一実施形態において、第２識別子は、検証情報として用いられ、アクセスデバイスに記憶される。しかしながら、これは本発明において限定されるものではない。

Ｍ２ＭシステムにおいてＯＡｕｔｈ認可アーキテクチャが用いられる場合、検証情報は、認可クレデンシャルであってよい。認可サーバは、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とに対応する第１認可関係を記憶し、リソースサーバは、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とに対応する第２認可関係を記憶する。具体的には、検証情報が認可クレデンシャルである場合、第１認可更新要求は、認可クレデンシャルをさらに含み、当該方法は、段階２０４、すなわち、第１認可更新応答をアクセスデバイスに送信する段階の前に、認可クレデンシャルに従って、認可クレデンシャルを含む第１認可関係が存在すること、および、第１認可関係においてバインドされているアクセスデバイス識別子が第１識別子ではないことを判定する段階をさらに備える。

アクセス先リソースの識別子に対応するリソースへのアクセスデバイスによるアクセスに対して初期認可を行う段階は、具体的には、アクセスデバイスの認可要求を受信する段階であって、認可要求は、第２識別子と、アクセス先リソースの識別子と、ユーザがアクセスデバイスのリソースアクセスに同意するという認証情報とを含む、段階と、認証情報に従って、ユーザがアクセス先リソースの識別子に対応するリソースにアクセスする権限を有すると判定された場合に、認可クレデンシャルを生成する段階と、アクセス先リソースの識別子に対応するリソースが位置するリソースサーバに認可バインド要求を送信する段階であって、認可バインド要求は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含む、段階と、リソースサーバにより送信された認可バインド応答を受信する段階であって、認可バインド応答は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とのバインドが成功したことを示す情報を含む、段階と、認可応答をアクセスデバイスに送信する段階であって、認可応答は、認可クレデンシャルと、アクセス先リソースの識別子と、認可クレデンシャルに署名するよう命令する情報とを含む、段階と、アクセスデバイスにより送信された署名バインド要求を受信する段階であって、署名バインド要求は、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成される、段階と、第１認可関係を記憶する段階であって、第１認可関係は、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子との間の対応関係を含む、段階とである。さらに、当該方法は、段階２１２の後に、リソースサーバにより記憶された第２認可関係を更新する段階をさらに備える。具体的には、当該方法は、第１識別子に従って第１認可関係を更新する段階の後に、第２認可更新要求をリソースサーバに送信する段階をさらに備える。第２認可更新要求は、第１識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含み、それによりリソースサーバは、認可クレデンシャルとアクセス先リソースの識別子とに従って、記憶された第２認可関係を取得し、第２認可関係における第２識別子を第１識別子に更新する。任意選択的に、認可サーバは、リソースサーバにより送信された第２認可更新応答を受信する。第２認可更新応答は、第２認可関係の更新が成功したことを示す。

リソースサーバが、記憶された第２認可関係における第２識別子を第１識別子に更新した後に、アクセスデバイスは、元の認可関係を用いることができるようになり、これによりリソースアクセスを実現する。

本発明の本実施形態は、マシン・ツー・マシン通信における認可処理方法を提供する。Ｍ２Ｍシステムにおけるアクセスデバイスの識別子が、ある理由により変更された場合、Ｍ２Ｍシステムは、検証情報の署名が有効であるか否かを判定することにより、すなわち、アクセスデバイスにより送信された検証情報の署名が、認可サーバにより記憶された第１認可関係における検証情報の署名と同一であるか否かを比較することにより、アクセスデバイスのアイデンティティを識別し、既存の認可関係をさらに更新することができ、それによりアクセスデバイスは、既存の認可関係を継続して用いることができる。よって、シームレスなリソースアクセスが実現され、Ｍ２Ｍシステムのサービス連続性が保証される。

図３は、本発明の一実施形態に係る別の認可処理方法のフローチャートである。当該方法は、以下の段階を備える。

段階３０２：アクセスデバイスにより送信された第１リソースアクセス要求を受信する。第１リソースアクセス要求は、アクセスデバイスの第１識別子と、アクセス先リソースの識別子と、認可クレデンシャルとを含む。

段階３０４：認可クレデンシャルに従って、認可クレデンシャルとアクセス先リソースの識別子とを含む第２認可関係が存在すること、および、第２認可関係においてバインドされているアクセスデバイス識別子が第１識別子ではないことを判定する。

段階３０６：第１リソースアクセス応答をアクセスデバイスに送信する。第１リソースアクセス応答は、署名要求情報を含み、署名要求情報は、認可クレデンシャルに署名するようアクセスデバイスに命令する。

段階３０８：アクセスデバイスにより送信された第２リソースアクセス要求を受信する。第２リソースアクセス要求は、第１識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成される。

段階３１０：署名データ要求を認可サーバに送信する。署名データ要求は、認可クレデンシャルを含む。

段階３１２：認可サーバにより送信された署名データ応答を受信する。署名データ応答は、認可クレデンシャルの署名を含み、認可クレデンシャルの署名は、第１認可関係に記憶され、認可サーバにより認可クレデンシャルに従って取得される。

段階３１４：第２リソースアクセス要求における認可クレデンシャルの署名と、認可サーバにより送信された認可クレデンシャルの署名とに従って、第２リソースアクセス要求における認可クレデンシャルの署名が有効であると判定する。

具体的には、リソースサーバは、認可サーバにより送信された認可クレデンシャルの署名を、第２リソースアクセス要求における認可クレデンシャルの署名と比較し、認可サーバにより送信された認可クレデンシャルの署名が、第２リソースアクセス要求における認可クレデンシャルの署名と同一である場合、第２リソースアクセス要求における認可クレデンシャルの署名が有効であると判定する。

段階３１６：第１識別子に従って、第２認可関係を更新する。

第１識別子に従って第２認可関係を更新する段階は、具体的には、第２認可関係における第２識別子を第１識別子に変更する段階であって、第２識別子は、アクセスデバイスにより用いられていた識別子である、段階か、または、第２認可関係を削除し、新たな第２認可関係を作成する段階であって、新たな第２認可関係は、第１識別子と、第２認可関係における認可クレデンシャルと、アクセス先リソースの識別子とを含む、段階である。

具体的には、段階３０２の前に、初期認可手順がさらに存在し、これは、認可サーバが、アクセスデバイスにより送信された認可要求を受信する段階であって、認可要求は、第２識別子と、アクセス先リソースの識別子と、ユーザがアクセスデバイスのリソースアクセスに同意するという認証情報とを含む、段階と、認可サーバが、認証情報に従って、ユーザがアクセス先リソースの識別子に対応するリソースにアクセスする権限を有すると判定し、認可クレデンシャルを生成し、アクセス先リソースの識別子に対応するリソースが位置するリソースサーバに認可バインド要求を送信する段階であって、認可バインド要求は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含む、段階と、リソースサーバが、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子との間の対応関係を第２認可関係として記憶し、認可バインド応答を認可サーバに送信する段階であって、認可バインド応答は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とのバインドが成功したことを示す情報を含む、段階と、認可サーバが、認可応答をアクセスデバイスに送信する段階であって、認可応答は、認可クレデンシャルと、アクセス先リソースの識別子と、認可クレデンシャルに署名するよう命令する情報とを含む、段階と、認可サーバが、アクセスデバイスにより送信された署名バインド要求を受信する段階であって、署名バインド要求は、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成される、段階と、認可サーバが、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子との間の対応関係を第１認可関係として記憶する段階とを含む。

段階３０２において、アクセスデバイスが第１リソースアクセス要求をリソースサーバに送信した後に、リソースサーバは、アクセスデバイスの第１リソースアクセス要求に対して判断を行う必要がある。第１リソースアクセス要求における情報が、リソースサーバにより記憶された第２認可関係と完全に合致する場合にのみ、リソースサーバは、当該要求を許可し、アクセスデバイスにより要求されるリソースを返すことができる。具体的には、リソースサーバが、第１リソースアクセス要求に従って、認可クレデンシャルとアクセス先リソースの識別子とを含む第２認可関係が存在すること、および、第２認可関係においてバインドされているアクセスデバイス識別子が第１識別子ではないことを判定した場合には、リソースサーバは、アクセスデバイス識別子が変更されたか、または認可クレデンシャルが開示されたと判定する。さらに、段階３０６から段階３１４を行うことにより、リソースサーバは、アクセスデバイスおよび認可サーバから取得された認可クレデンシャルの署名に従って、第１識別子と第２識別子との両方がアクセスデバイスの識別子であると判定し、さらに自主的に第１識別子を用いて、記憶された第２認可関係を更新する。

さらに、当該方法は、第１識別子に従って第２認可関係を更新する段階の後に、第２リソースアクセス応答をアクセスデバイスに送信する段階をさらに備える。第２リソースアクセス応答は、アクセス先リソースの識別子に対応するリソースを含む。このように、アクセスデバイスは、元の認可関係を用いてリソースアクセスを達成する。

任意選択的に、当該方法は、第２リソースアクセス要求における認可クレデンシャルの署名が有効であると判定する段階の後に、第３認可更新要求を認可サーバに送信する段階であって、第３認可更新要求は、認可クレデンシャルと第１識別子とを含む、段階と、認可サーバにより送信された第３認可更新応答を受信する段階であって、第３認可更新応答は、認可サーバが認可更新を行うことに成功したことを示す情報を含む、段階とをさらに備える。

本発明の本実施形態は、マシン・ツー・マシン通信における認可処理方法を提供する。Ｍ２Ｍシステムにおけるアクセスデバイスの識別子が、ある理由により変更された場合、Ｍ２Ｍシステムは、検証情報の署名が有効であるか否かを判定することにより、すなわち、アクセスデバイスにより送信された検証情報の署名が、認可サーバにより記憶された第１認可関係における検証情報の署名と同一であるか否かを比較することにより、アクセスデバイスのアイデンティティを識別し、既存の認可関係をさらに更新することができ、それによりアクセスデバイスは、既存の認可関係を継続して用いることができる。よって、シームレスなリソースアクセスが実現され、Ｍ２Ｍシステムのサービス連続性が保証される。

図２および図３における認可処理方法の具体的な実現プロセスは、下記、ＡＣＰ認可アーキテクチャおよびＯＡｕｔｈ認可アーキテクチャに基づいて別々に説明する。

アクセスデバイスのリソースアクセスを認可するのにＡＣＰ認可アーキテクチャがＭ２Ｍシステムにおいて用いられる場合、検証情報は、アクセスデバイスの第２識別子であってよい。具体的には、図４および図５に示す実施形態において、Ｍ２ＭシステムにおいてＡＣＰ認可アーキテクチャに基づいて行われる認可手順は、初期認可および認可更新の２つのサブ手順を含むものとして提供される。初期認可は、アクセスデバイスの識別子が変更される前に、認可サーバが、アクセスデバイスについての検証情報の署名を取得し、認可関係を生成する手順である。

図４を参照すると、図４は、本発明に係る、ＡＣＰ認可アーキテクチャに基づいて行われる初期認可のフローチャートである。本実施形態におけるアクセスデバイスは、アプリケーションエンティティＡＥである。しかしながら、アクセスデバイスの具体的な形態は、本発明の本実施形態において限定されるものではない。初期認可手順は、以下の段階を含む。

段階４０２および段階４０４：ＡＥが、登録要求をレジストラ１（Ｒ−ＣＳＥ１）に送信し、レジストラ１が、識別子ＡＥ−ＩＤ１をＡＥに割り当てる。

段階４０６：システム管理者（Ａｄｍｉｎ）が、ＡＥについてのＡＣＰを認可サーバ（ＡＳ）上に作成する。

具体的には、ＡＣＰ認可アーキテクチャに基づいて、Ａｄｍｉｎは通常、ＡＥについてのＡＣＰを手動で設定する。Ｍ２Ｍシステムにおいて、ＡＣＰは、リソースとして作成され、対応するリソースにバインドされる。バインドの方式は、ＡＣＰのリソース識別子（ＡＣＰ ＩＤ）を、対応するリソースのアクセス制御ポリシー識別子ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ属性値に付加するものである。背景技術で説明したように、Ｍ２ＭシステムにおけるＡＣＰリソースの各ルールは、３タプルの＜ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ， ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔｓ， ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓ＞である。本発明の本実施形態において、ＡｄｍｉｎがＡＥについてのＡＣＰを作成することは、具体的には、ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓパラメータを「／ＣＳＥ０００５／ＣＡＥ０００１」に設定することであってよく、／ＣＳＥ０００５／ＣＡＥ０００１は、ＡＥ−ＩＤ１である。別のパラメータは、本発明の解決手段に無関係であるので、本発明の本実施形態において限定されるものではない。

段階４０８：認可サーバが、ＡＣＰリソース作成要求をリソースサーバ（Ｈ−ＣＳＥ）に送信する。

ＡＣＰリソース作成要求は、ＡＥについてＡｄｍｉｎにより作成されたＡＣＰの全属性データと、対応するバインドされたリソース識別子とを含む。例えば、認可サーバによりリソースサーバに送信されるＡＣＰリソース作成要求は、以下の通りであってよい。
ＰＯＳＴ ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００３ ＨＴＴＰ／１．１
Ｆｒｏｍ：ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ＲｅｓｏｕｒｃｅＴｙｐｅ"："ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ"，
"ｐｒｉｖｉｌｅｇｅｓ．ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ"："／ＣＳＥ０００５／ＣＡＥ０００１"，
"ｒｅｓ＿ｕｒｉ"："／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１"｝

「ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００３」は、Ｈ−ＣＳＥのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）であり、ＡＳがＡＣＰリソースを作成することを見込む親ノードである。すなわち、ＡＣＰリソースはＨ−ＣＳＥの根ノード上に作成される。具体的な実現形態において、ＡＳは、ＰＯＳＴ要求のＵＲＬ中に、作成される必要があるＡＣＰリソースの親リソースＩＤを定義してよい。どのリソース上で具体的にＡＣＰリソースが作成されるかは、本発明の解決手段に影響を及ぼさないので、本発明において限定されるものではない。「Ｆｒｏｍ」は、リソース作成要求の発信者のＩＤ、すなわち、本実施形態においては認可サーバのＵＲＬアドレス「ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ」を記述する。ＨＴＴＰメッセージボディは、作成されたＡＣＰリソースの属性の全てを含む。「"ＲｅｓｏｕｒｃｅＴｙｐｅ"："ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ"」は、現在作成を要求されているリソースの種類がＡＣＰであることを示す。「"ｐｒｉｖｉｌｅｇｅｓ．ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ"："／ＣＳＥ０００５／ＣＡＥ０００１"」は、作成されたＡＣＰリソースを適用可能なアクセスデバイスが「／ＣＳＥ０００５／ＣＡＥ０００１」であることを示す。ＨＴＴＰメッセージボディは、作成されたＡＣＰリソースの別の属性をさらに含むはずである。しかしながら、これは本発明の解決手段に無関係であるので、本実施形態においては説明しない。加えて、「"ｒｅｓ＿ｕｒｉ"："／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１"」は、ＡＣＰリソースがバインドされる必要があるリソースＵＲＩが「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」であることを示す。具体的な実現形態において、バインドされる必要があるリソースＵＲＩは、別の方式で記述されてよい。（例えば、リソースＵＲＩは、ＰＯＳＴ要求のＵＲＬに含まれ、クエリストリングの形態として記述される）。しかしながら、リソースＵＲＩを記述する具体的な方式は、ＡＣＰリソースの作成およびバインドのプロセスに影響を及ぼさない。

段階４１０：リソースサーバが、ＡＣＰリソースを作成し、作成されたＡＣＰリソースを対応するリソースにバインドする。

具体的には、Ｈ−ＣＳＥは、ＡＳのＡＣＰリソース作成要求を受信した後に、まずリソース作成要求をパースして、ＡＣＰリソースの作成位置または親リソースＩＤを取得し、次いでＨＴＴＰメッセージボディをパースして、作成されたＡＣＰリソースの各属性値を取得する。例えば、本発明の本実施形態において、ＡＣＰリソースの作成位置は、「ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００３」である。すなわち、当該リソースは、Ｈ−ＣＳＥの根ノード上に作成される。加えて、ＨＴＴＰメッセージボディ中、「"ＲｅｓｏｕｒｃｅＴｙｐｅ"："ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ"」は、作成されたリソースの種類がＡＣＰであることを示し、「"ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ"："／ＣＳＥ０００５／ＣＡＥ０００１"」は、ＡＣＰにおけるアクセス制御ルールのａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓパラメータ値が「／ＣＳＥ０００５／ＣＡＥ０００１」であることを示す。具体的な実現形態において、ＡＣＰリソース作成要求におけるＨＴＴＰメッセージボディは、ＡＣＰリソースの別の属性値をさらに含んでよい。ＡＣＰリソースを作成した場合、Ｈ−ＣＳＥはまた、作成されたＡＣＰリソースの対応する属性値を取得し、値をアサインする必要がある。

具体的には、Ｈ−ＣＳＥがＡＣＰリソースの作成を完了した後に、Ｈ−ＣＳＥは、ＡＣＰ ＩＤをＡＣＰリソースに割り当て、そのＡＣＰ ＩＤを、ＡＣＰリソースのリソース識別子（すなわち、ｒｅｓｏｕｒｃｅＩＤ属性）、例えば、「ＡＣＰ０００１」として設定する。ＡＣＰ ＩＤは、ＡＣＰリソースをＨ−ＣＳＥ内で一意に識別する。次いで、Ｈ−ＣＳＥは、ＡＣＰリソース作成要求におけるバインドされたリソース識別子に従って、対応するリソース、すなわち、「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」を見つけ出し、作成されたＡＣＰリソースのＡＣＰ ＩＤ、すなわち、「ＡＣＰ０００１」を当該リソースのａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ属性値リストに付加する。

段階４１２：リソースサーバが、ＡＣＰリソース作成応答を認可サーバに返す。

具体的には、Ｈ−ＣＳＥが、ＡＣＰリソース作成応答をＡＳに返す。当該応答は、ＨＴＴＰ２００応答コードを含む。例えば、Ｈ−ＣＳＥによりＡＳに返されるＡＣＰリソース作成応答は、以下の通りである。
ＨＴＴＰ／１．１ ２００ ＯＫ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｒｅｓｏｕｒｃｅＩＤ"： "／ＣＳＥ０００３／ＡＣＰ０００１"｝

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、Ｈ−ＣＳＥが、対応するＡＣＰリソースの作成およびバインドを既に完了していることを示す。ＨＴＴＰメッセージボディ中、「"ｒｅｓｏｕｒｃｅＩＤ"： "／ＣＳＥ０００３／ＡＣＰ０００１"」は、作成されたＡＣＰにＨ−ＣＳＥにより割り当てられたＡＣＰ ＩＤが「／ＣＳＥ０００３／ＡＣＰ０００１」であることを示す。ＡＣＰリソースをＭ２Ｍシステムにおいて一意に識別するべく、Ｈ−ＣＳＥのＣＳＥ ＩＤがＡＣＰ ＩＤの前に付加される。

段階４１４：認可サーバが、記憶された認可関係マッピング表においてＡＥ−ＩＤ１に対応する検証情報の署名が存在するか否かを判定する。

具体的には、ＡＳが、アクセスデバイス識別子がＡＥ−ＩＤ１に等しい認可関係を、記憶された認可関係マッピング表に問い合わせる。対応する認可関係が見つかり、対応する検証情報の署名がその認可関係に記憶されている場合には、初期認可は完了する。あるいは、対応する認可関係が見つからない場合には、対応する検証情報に署名するようＡＥに要求するべく、段階４１６が行われる、すなわち、ＡＥへの署名要求を開始する。

具体的には、認可関係マッピング表中の各認可関係は、アクセスデバイス識別子と、アクセス先リソースの識別子と、アクセスデバイスの検証情報と、検証情報の署名とを記憶するのに用いられる。例えば、認可関係マッピング表の可能な構造は、表１に記録するものである。
表１ 認可関係マッピング表

表１に示すように、この表の各行は、アクセスデバイスに対応する認可関係を示し、これは、アクセスデバイス識別子（ｓｕｂｊｅｃｔＩＤ）と、署名（ｓｉｇｎａｔｕｒｅ）と、アクセス先リソースＵＲＩリスト（ｒｅｓ＿ｕｒｉｓ）とを含む。認可関係マッピング表において、アクセスデバイス識別子は、アクセスデバイスの検証情報としても用いられることに留意されたい。「署名」列の値は、アクセスデバイスが鍵を用いて対応するアクセスデバイス識別子に署名することにより生成される署名である。表１の第１行から、ｒｅｓ＿ｕｒｉｓ列は２つのアクセス先リソースＵＲＩを有することがわかる。実際には、１つのアクセスデバイスの認可ステータスが、認可関係マッピング表中の各認可関係に記録および記憶される。同一のアクセスデバイスが、複数のリソースへのアクセス権限を取得してよいことは明らかである。

具体的な実現形態においては、各アクセスデバイスについて別の形態の検証情報が用いられてよい。例えば、表２に示すように、ランダムに生成されるストリングが検証情報として用いられ、その検証情報への各アクセスデバイスの署名値が記憶される。
表２ 認可関係マッピング表（別の例）

表２は、各アクセスデバイスが、ランダムに生成される検証情報（ｃｈａｌｌｅｎｇｅ）と検証情報の署名とを記憶する認可関係マッピング表構造を示す。具体的な実現形態において、どの情報が検証情報として用いられるかは、本発明の具体的な解決手段に影響を及ぼさない。本実施形態においては、表１に示す認可関係マッピング表構造がＭ２Ｍシステムにおいて用いられる、すなわち、アクセスデバイス識別子が検証情報として用いられると仮定する。具体的な実現形態において、認可関係マッピング表は、ＡＳ内の共通データベースを用いて維持されてよく、またはＲＥＳＴｆｕｌリソースＡｕｔｈｚＲｅｌＭａｐＴａｂｌｅとして記述されてもよい。ＡＣＰ認可アーキテクチャに基づいて、ＡｕｔｈｚＲｅｌＭａｐＴａｂｌｅリソースは、以下の表３に示す形態で示されてよい。
表３ 認可関係マッピング表リソースおよび属性

ＡｕｔｈｚＲｅｌＭａｐＴａｂｌｅは、認可関係マッピング表リソースである。当該リソースは、いくつかの認可記録属性、すなわち、ａｕｔｈｚＲｅｃｏｒｄリソースを含む。各ａｕｔｈｚＲｅｃｏｒｄリソースは、１つのアクセスデバイスの認可関係を記録し、ａｕｔｈｚＲｅｃｏｒｄリソースは、以下の属性を含む。
ｓｕｂｊｅｃｔＩＤ：表１におけるアクセスデバイス識別子属性に対応する。
ｓｉｇｎａｔｕｒｅ：表１における署名属性に対応する。
ｒｅｓ＿ｕｒｉｓ：表１におけるアクセス先リソースＵＲＩリスト属性に対応する。

表１は、一例として用いられている。具体的には、ＡＳは、Ｈ−ＣＳＥのリソース作成応答を受信した後に、まず認可関係マッピング表からアクセスデバイス識別子がＡＥ−ＩＤ１に等しい認可関係を検索する、すなわち、「ｓｕｂｊｅｃｔＩＤ」列の値が「／ＣＳＥ０００５／ＣＡＥ０００１」に等しい認可関係を検索する。条件を満足する認可関係が認可関係マッピング表において見つかり、当該認可関係の署名属性値がヌルでない場合には、ＡＳは直接的に初期認可手順を終了する。あるいは、条件を満足する認可関係が認可関係マッピング表において見つからなかった場合には、ＡＳは、署名要求手順を開始し、段階４１６を行う。

段階４１６：認可サーバが、署名要求をＡＥに送信する。

具体的には、ＡＳにより開始されるＡＥへの署名要求は、以下の通りであってよい。
ＰＯＳＴ ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００５／ＣＡＥ０００１ ＨＴＴＰ／１．１
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ＳｉｇＲｅｑ"： "１"｝

ＰＯＳＴ要求におけるＵＲＬは、Ｒ−ＣＳＥ上でのＡＥのＵＲＩである。Ｒ−ＣＳＥは、当該要求を受信した後に、署名要求をＡＥに転送する。ＨＴＴＰメッセージボディ中、「"ＳｉｇＲｅｑ"： "１"」は、ＡＥが検証情報に署名する必要があることを示す署名要求フラグビットである。本実施形態における検証情報は、ＡＥ−ＩＤ１である。ＡＥの識別子をＡＥ自体が記憶するので、上述の署名要求におけるＨＴＴＰメッセージボディは、検証情報パラメータを含む必要はない。具体的な実現形態において、別の形態の検証情報が用いられる場合、上述の署名要求におけるＨＴＴＰメッセージボディは、対応する検証情報パラメータを含んでよい。

段階４１８：ＡＥが、デバイス出荷時の鍵を用いて検証情報に署名する。

具体的には、ＡＥは、ＡＳの署名要求を受信した後に、まずＨＴＴＰメッセージボディが署名要求フラグビット「ＳｉｇＲｅｑ」を含むか否かを検出する。リソースアクセス応答が「ＳｉｇＲｅｑ」パラメータを含み、「ＳｉｇＲｅｑ」パラメータの値が「１」である場合、ＡＥは、予め設定された署名アルゴリズムとデバイス出荷時の鍵とを用いて対応する検証情報に署名する。本実施形態において、ＡＥ−ＩＤ１を計算することにより取得される署名は、「ＪＹＵＩ７ＢＺＯ９２」である。

具体的には、ＡＥは、現在のＡＥ−ＩＤ１とＭ２Ｍ ＳＰ ＩＤ（Ｍ２Ｍ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｉｄｅｎｔｉｆｉｅｒ）とをバインドし、ローカルで記憶する。記憶方法は、アクセスデバイス識別子マッピング表を用いて実現されるものであってよく、または別の記憶方式が用いられる。具体的な実現形態において、どの記憶方法が用いられるかは、本発明の解決手段に影響を及ぼさない。本実施形態においては、表４に示すように、ＡＥ側が、アクセスデバイス識別子マッピング表を用いてＡＥ−ＩＤとＭ２Ｍ ＳＰ ＩＤとの間の対応関係を記憶すると仮定する。
表４ アクセスデバイス識別子マッピング表

Ｍ２Ｍシステムにおいて、ＡＥは、現在割り当てられている識別子を記憶する。ＡＥにより記憶される、現在割り当てられている識別子は、ここで記憶されるアクセスデバイス識別子マッピング表に関連するものではないことに留意されたい。例えば、アクセスデバイスが、ある理由により新たなレジストラに再登録し、識別子ＡＥ−ＩＤ１１を取得する場合には、アクセスデバイスは、ＡＥ−ＩＤ１１を現在のデバイス識別子として記憶する。しかしながら、アクセスデバイスが認可を再申請するのにＡＥ−ＩＤ１１を用いない場合には、アクセスデバイス識別子マッピング表におけるアクセスデバイス識別子は更新されない。

段階４２０：ＡＥが、署名応答をＡＳに返す。

具体的には、ＡＥが、署名応答をＡＳに返す。例えば、ＡＥによりＡＳに返される署名応答は、以下の通りである。
ＨＴＴＰ／１．１ ２００ ＯＫ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｓｉｇｎａｔｕｒｅ"： "ＪＹＵＩ７ＢＺＯ９２"｝

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、ＡＥが既に検証情報に署名していることを示す。ＨＴＴＰメッセージボディ中、「"ｓｉｇｎａｔｕｒｅ"： "ＪＹＵＩ７ＢＺＯ９２"」は、検証情報の署名が「ＪＹＵＩ７ＢＺＯ９２」であることを示す。

段階４２２：認可サーバが、ＡＥの署名応答を受信した後に、署名応答をパースして検証情報の署名を取得し、対応する認可関係を認可関係マッピング表に付加する。

具体的には、ＡＳがＡＥの署名応答を受信した場合、ＡＳはまず、署名応答におけるＨＴＴＰメッセージボディをパースして、検証情報の署名、すなわち、「ＪＹＵＩ７ＢＺＯ９２」を取得する。次いで、ＡＳは、認可関係マッピング表から、ＡＥに対応する認可関係を検索する、すなわち、ｓｕｂｊｅｃｔＩＤ属性値がＡＥ−ＩＤ１、すなわち、「／ＣＳＥ０００５／ＣＡＥ０００１」に等しい認可関係を検索する。当該認可関係が見つけ出された場合には、値「ＪＹＵＩ７ＢＺＯ９２」が当該認可関係の署名属性値にアサインされる。当該認可関係が見つけ出されなかった場合には、新たな認可関係が構築され、その認可関係が認可関係マッピング表に付加される。本発明の本実施形態において、表１に示すように、ＡＥに対応する認可関係は、ＡＳの認可関係マッピング表には存在しない。よって、ＡＳは、新たな認可関係を生成し、認可関係マッピング表中に新たな認可関係を更新する。更新された認可関係マッピング表を表５に示す。この表の第３行のデータが、新たに生成された認可関係である。
表５ 認可関係マッピング表

図５を参照すると、図５は、本発明に係る、ＡＣＰ認可アーキテクチャに基づいて行われる認可更新のフローチャートである。図４の実施形態におけるＡＥが、アクセス位置の変更のような理由により異なるレジストラ（例えば、Ｒ−ＣＳＥ２）に登録する場合、新たなレジストラＲ−ＣＳＥ２が新たな識別子ＡＥ−ＩＤ２をＡＥに割り当ててよい。その結果、Ｍ２Ｍシステムにおける既存の認可関係は無効になる。図５の方法は、アクセス識別子が変更された後に認可関係を更新するための方法である。当該方法は、以下の段階を備える。

段階５０２および段階５０４：ＡＥが、登録要求をレジストラ２（Ｒ−ＣＳＥ２）に送信し、レジストラ２が、識別子ＡＥ−ＩＤ２をＡＥに割り当てる。

段階５０６：ＡＥが、リソースサーバ（Ｈ−ＣＳＥ）へのリソースアクセス要求を開始する。リソースアクセス要求は、ＡＥ−ＩＤ２とアクセス先リソースのＵＲＩとを含む。

具体的には、ＡＥが、リソースアクセス要求をＨ−ＣＳＥに送信する。例えば、ＡＥにより開始されるＨ−ＣＳＥへの初期リソースアクセス要求は、以下の通りである。
ＧＥＴ ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１？ｆｒｏｍ＝／ＣＳＥ０００５／ＣＡＥ０００３ ＨＴＴＰ／１．１
「ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」は、アクセス先リソースのＵＲＩであり、「ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００３」は、ＡＥのアクセスデバイス識別子、すなわち、ＡＥ−ＩＤ２を示す。

段階５０８：リソースサーバ（Ｈ−ＣＳＥ）が、アクセス要求に保持される情報に従ってアクセス制御判断を行う。

具体的には、Ｈ−ＣＳＥがＡＥのリソースアクセス要求を受信した後に、Ｈ−ＣＳＥはまず、リソースアクセス要求におけるアクセス先リソースのＵＲＩ、すなわち、ＧＥＴ要求におけるＵＲＬアドレス（／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１）をパースにより抜き出し、対応するリソースｒｅｓｏｕｒｃｅ１をローカルで検索する。次いで、Ｈ−ＣＳＥは、リソースアクセス要求をパースしてＡＥ−ＩＤ２、すなわち、ＧＥＴ要求におけるＵＲＬクエリストリング「／ＣＳＥ０００６／ＣＡＥ０００３」を取得する。最後に、Ｈ−ＣＳＥは、対応するリソースｒｅｓｏｕｒｃｅ１のａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ属性値から、当該リソースにバインドされたＡＣＰ ＩＤリストを見つけ出し、背景技術で説明したアクセス制御判断プロセスに従って、ＡＥが当該リソースにアクセスする権限を有するか否かを判定する。初期認可と比較して、ＡＥのアクセスデバイス識別子のみがＡＥ−ＩＤ１からＡＥ−ＩＤ２に変更され、本実施形態におけるリソースアクセスに関連する他の属性（例えば、オペレーションおよびコンテクスト環境）は初期認可の間の制限と一致していると仮定する。初期認可の間にＡｄｍｉｎによりＡＥについて予め設定されたＡＣＰにおいて、ｐｒｉｖｉｌｅｇｅｓ．ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ属性値は、ＡＥ−ＩＤ１、すなわち、／ＣＳＥ０００５／ＣＡＥ０００１のみを含む。よって、アクセス判断プロセスにおいて、Ｈ−ＣＳＥは、ＡＥ−ＩＤ２、すなわち、／ＣＳＥ０００６／ＣＡＥ０００３を含むＡＣＰを見つけ出すことができない。この場合、アクセス制御判断の結果は、現在のリソースアクセスが許可されないというものである。従来技術においては、リソースサーバがアクセスデバイスのアクセス要求を直接的に拒否する。その結果、同一のアクセスデバイスのアクセスデバイス識別子が変更された場合、リソースアクセスは失敗する。

段階５１０：リソースサーバが、リソースアクセス応答をＡＥに返す。当該応答は、ＨＴＴＰ３０２応答コードとリダイレクトＵＲＬとを含み、リダイレクトＵＲＬは、認可サーバの認可更新ポートを指定する。

具体的には、Ｈ−ＣＳＥのアクセス制御判断が、現在のリソースアクセスが許可されないというものである場合、Ｈ−ＣＳＥによりＡＥに返されるリソースアクセス応答は、以下の通りである。
ＨＴＴＰ／１．１ ３０２ Ｍｏｖｅ ｔｅｍｐｏｒａｒｉｌｙ
Ｌｏｃａｔｉｏｎ：ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ａｕｔｈｚｕｐｄａｔｅ＃ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００３＆ｒｅｓ＿ｕｒｉ＝ ／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１

ＨＴＴＰ応答のステータスコードは「３０２」であり、これは、ＡＥのリソースアクセス要求が新たなＵＲＬにリダイレクトされる必要があることを示す。「Ｌｏｃａｔｉｏｎ：ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ａｕｔｈｚｕｐｄａｔｅ」は、リダイレクトＵＲＬを示す。リダイレクトＵＲＬは、Ｍ２Ｍシステムにおける認可サーバの認可更新ポートを指定する。例えば、ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ａｕｔｈｚｕｐｄａｔｅは、認可サーバの認可更新ポートアドレスである。「＃ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００３＆ｒｅｓ＿ｕｒｉ＝／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」は、リダイレクトされたリソースアクセス要求に添付される必要があるパラメータ情報であり、ＡＥ−ＩＤ２（すなわち、／ＣＳＥ０００６／ＣＡＥ０００３）とアクセス先リソースのＵＲＩ（すなわち、／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１）とを含み、クエリストリングの形態で示される。

段階５１２：ＡＥが、リソースサーバのリソースアクセス応答を受信した後に、認可更新要求を認可サーバに送信する。認可更新要求は、ＡＥ−ＩＤ２とアクセス先リソースのＵＲＩとを含む。

具体的には、ＡＥが、Ｈ−ＣＳＥのリソースアクセス応答を受信し、ＨＴＴＰステータスコードを検出する。ステータスコードが「３０２」である場合、ＡＥは、認可更新要求をＡＳに送信する。例えば、ＡＥによりＡＳに送信される認可更新要求は、以下の通りであってよい。
ＧＥＴ ／ａｕｔｈｚｕｐｄａｔｅ？ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００３＆ｒｅｓ＿ｕｒｉ＝ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ

ＧＥＴ要求におけるＵＲＬアドレス「／ａｕｔｈｚｕｐｄａｔｅ？ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００３＆ｒｅｓ＿ｕｒｉ＝ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１ ＨＴＴＰ／１．１」は、認可サーバの認可更新ポートアドレスと、添付パラメータ情報とを示す。添付パラメータ情報は、ＡＥ−ＩＤ２（すなわち、／ＣＳＥ０００６／ＣＡＥ０００３）と、アクセス先リソースの識別子（すなわち、／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１）とを含む。「Ｈｏｓｔ」は、認可サーバのアドレスを記述する。

段階５１４：認可サーバが、ＡＥの認可更新要求を受信した後に、認可更新応答をＡＥに返す。当該応答は、ＨＴＴＰ２０２応答コードと署名要求フラグビットとを含む。

具体的には、ＡＳがＡＥの認可更新要求を受信した後に、ＡＳによりＡＥに返される認可更新応答は、以下の通りである。
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ＳｉｇＲｅｑ"： "２"｝

ＨＴＴＰ応答のステータスコードは「２０２」であり、これは、ＡＳが既にＡＥの認可更新要求を受理していることを示す。しかしながら、後続の処理にはさらなる情報が必要である。ＨＴＴＰメッセージボディ中、「"ＳｉｇＲｅｑ"： "２"」は、ＡＥが検証情報と現在のアクセスデバイス識別子とに署名する必要があることを示す署名要求フラグビットである。本実施形態において、検証情報は、初期認可の間のＡＥのアクセスデバイス識別子ＡＥ−ＩＤ１、すなわち、／ＣＳＥ０００５／ＣＡＥ０００１であり、現在のアクセスデバイス識別子は、ＡＥ−ＩＤ２：／ＣＳＥ０００６／ＣＡＥ０００３である。

段階５１６：ＡＥが、デバイス出荷時の鍵を用いて、検証情報に署名し、現在のアクセスデバイス識別子ＡＥ−ＩＤ２に署名する。

具体的には、ＡＥがＨ−ＣＳＥの認可更新応答を受信した後に、ＨＴＴＰ応答のステータスコードが「２０２」であること、および、ＨＴＴＰメッセージボディが値「２」の「ＳｉｇＲｅｑ」パラメータを含むことを検出した場合、ＡＥは、ローカルで記憶されたＡＥ−ＩＤ１に署名する。本実施形態において、ＡＥ−ＩＤ１は、表４に示すように、アクセスデバイス識別子マッピング表の形態でローカルで記憶される。ＡＥは、ＡＥにより現在アクセスされているＭ２Ｍシステムの識別子（すなわち、本実施形態では「ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ」であるＭ２Ｍ ＳＰ ＩＤ）に従って、アクセスデバイス識別子マッピング表から対応するアクセスデバイス識別子ＡＥ−ＩＤ１： ／ＣＳＥ０００５／ＣＡＥ０００１を見つけ出す。本実施形態においては、ＡＥ−ＩＤ１ ／ＣＳＥ０００５／ＣＡＥ０００１が、対応する検証情報である。

具体的には、ＡＥが、ローカルで記憶されたＡＥ−ＩＤ１を見つけ出した後に、ＡＥは、ＡＥ−ＩＤ１およびＡＥ−ＩＤ２に署名する。本実施形態においては、ＡＥ−ＩＤ１に署名することにより「ＪＹＵＩ７ＢＺＯ９２」が取得され、ＡＥ−ＩＤ２に署名することにより「Ｍ６ＵＩ７Ｂ２ＯＫＱ」が取得される。次いで、ＡＥ−ＩＤ２は、ローカルで記憶されたアクセスデバイス識別子マッピング表中に更新されて、元のＡＥ−ＩＤ１と置き換わる。すなわち、表４において「／ＣＳＥ０００５／ＣＡＥ０００１」が「／ＣＳＥ０００６／ＣＡＥ０００３」で置き換えられて、表６に示す更新されたアクセスデバイス識別子マッピング表が取得される。
表６ アクセスデバイス識別子マッピング表

段階５１８：ＡＥが、署名検証要求を認可サーバに送信する。

ＡＥが署名を完了した後に、ＡＥは、ＡＳへの署名検証要求を開始する。当該要求は、ＡＥ−ＩＤ１と、ＡＥ−ＩＤ１の署名と、ＡＥ−ＩＤ２と、ＡＥ−ＩＤ２の署名とを含む。

具体的には、ＡＥにより開始されるＡＳへの署名検証要求は、以下の通りである。
ＰＵＴ ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ａｕｔｈｚｕｐｄａｔｅ ＨＴＴＰ／１．１
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ａｅｉｄ＿ｏｒｉ"： "／ＣＳＥ０００５／ＣＡＥ０００１"， "ｓｉｇ＿ｏｒｉ"： "ＪＹＵＩ７ＢＺＯ９２"
"ａｅｉｄ＿ｎｏｗ"： "／ＣＳＥ０００６／ＣＡＥ０００３"， "ｓｉｇ＿ｎｏｗ"： "Ｍ６ＵＩ７Ｂ２ＯＫＱ"｝

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、ＡＥが既に検証情報に署名していることを示す。ＨＴＴＰメッセージボディ中、「"ａｅｉｄ＿ｏｒｉ"： "／ＣＳＥ０００５／ＣＡＥ０００１"」は、初期認可の間のアクセスデバイス識別子ＡＥ−ＩＤ１が「／ＣＳＥ０００５／ＣＡＥ０００１」であることを示し、「"ｓｉｇ＿ｏｒｉ"： "ＪＹＵＩ７ＢＺＯ９２"」は、初期認可の間のアクセスデバイス識別子ＡＥ−ＩＤ１の署名が「ＪＹＵＩ７ＢＺＯ９２」であることを示し、「"ａｅｉｄ＿ｎｏｗ"： "／ＣＳＥ０００６／ＣＡＥ０００３"」は、ＡＥの現在のアクセスデバイス識別子ＡＥ−ＩＤ２が「／ＣＳＥ０００６／ＣＡＥ０００３」であることを示し、「"ｓｉｇ＿ｎｏｗ"： "Ｍ６ＵＩ７Ｂ２ＯＫＱ"」は、ＡＥの現在のアクセスデバイス識別子ＡＥ−ＩＤ２の署名が「Ｍ６ＵＩ７Ｂ２ＯＫＱ」であることを示す。

段階５２０：ＡＳが、署名検証要求における署名を検証して、認可関係マッピング表を更新するか否かを判定する。

ＡＳがＡＥの署名検証要求を受信した後に、ＡＳは、アクセスデバイス識別子がＡＥ−ＩＤ１である認可関係を認可関係マッピング表から検索し、署名検証要求におけるＡＥ−ＩＤ１の署名が当該認可関係における署名と一致するか否かを比較し、さらにＡＥに対する認可更新を行うか、または認可更新要求を拒否する。

具体的には、ＡＳがＡＥの署名検証要求を受信した後に、ＡＳはまず、署名検証要求をパースして、ＡＥ−ＩＤ１と、ＡＥ−ＩＤ１の署名と、ＡＥ−ＩＤ２と、ＡＥ−ＩＤ２の署名とを取得する。次いで、ＡＳは、ｓｕｂｊｅｃｔＩＤ属性値がＡＥ−ＩＤ１（すなわち、「／ＣＳＥ０００５／ＣＡＥ０００１」）である認可関係を認可関係マッピング表から検索し、当該認可関係における署名属性値がＡＥ−ＩＤ１の署名（すなわち、「ＪＹＵＩ７ＢＺＯ９２」）と同一であるか否かを検証する。対応する認可関係における署名属性値がＡＥ−ＩＤ１の署名とは異なる場合には、認可サーバは、ＡＥの署名検証要求を拒否し、署名検証応答、例えば、ＨＴＴＰ／１．１ ４０３ Ｆｏｒｂｉｄｄｅｎを返し、認可更新手順は終了する。対応する認可関係における署名属性値がＡＥ−ＩＤ１の署名と同一である場合には、ＡＥの現在の認可更新が許可され、認可関係におけるｓｕｂｊｅｃｔＩＤ属性値はＡＥ−ＩＤ２（すなわち、「／ＣＳＥ０００６／ＣＡＥ０００３」）に更新され、署名属性値はＡＥ−ＩＤ２の署名（すなわち、「Ｍ６ＵＩ７Ｂ２ＯＫＱ」）に更新される。本発明の本実施形態において、署名検証が成功することは明らかである。ＡＳは、表７に示すように、認可関係マッピング表を更新する。
表７ 認可関係マッピング表

段階５２２：認可サーバが、認可更新要求をリソースサーバに送信する。

ＡＳがＡＥの認可更新を許可した後に、ＡＳは、Ｈ−ＣＳＥへの認可更新要求を開始する。当該要求は、アクセス先リソースのＵＲＩと、ＡＥ−ＩＤ１と、ＡＥ−ＩＤ２とを含む。

具体的には、認可更新要求は、以下の通りであってよい。
ＰＵＴ ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１ ＨＴＴＰ／１．１
Ｆｒｏｍ：ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ａｅｉｄ＿ｏｒｉ"： "／ＣＳＥ０００５／ＣＡＥ０００１"，
"ａｅｉｄ＿ｎｏｗ"： "／ＣＳＥ０００６／ＣＡＥ０００３"｝

「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」は、アクセス先リソースのＵＲＩである。ＨＴＴＰメッセージボディ中、「"ａｅｉｄ＿ｏｒｉ"： "／ＣＳＥ０００５／ＣＡＥ０００１"」は、元のアクセスデバイス識別子ＡＥ−ＩＤ１が「／ＣＳＥ０００５／ＣＡＥ０００１」であることを示し、「"ａｅｉｄ＿ｎｏｗ"： "／ＣＳＥ０００６／ＣＡＥ０００３"」は、現在のアクセスデバイス識別子ＡＥ−ＩＤ２が「／ＣＳＥ０００６／ＣＡＥ０００３」であることを示す。

段階５２４：リソースサーバが、認可関係を更新する。

Ｈ−ＣＳＥがＡＳの認可更新要求を受信した後に、Ｈ−ＣＳＥは、アクセス先リソースのＵＲＩに従って、対応するリソースを見つけ出し、そのリソースに関連付けられた認可関係を更新する。

具体的には、Ｈ−ＣＳＥは、ＡＳの認可更新要求を受信した後に、まず認可更新要求をパースしてアクセス先リソースのＵＲＩ、すなわち、「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」を取得し、対応するリソースをローカルで見つけ出し、次いで認可更新要求におけるＨＴＴＰメッセージボディをパースしてＡＥ−ＩＤ１（すなわち、「／ＣＳＥ０００５／ＣＡＥ０００１」）およびＡＥ−ＩＤ２（すなわち、「／ＣＳＥ０００６／ＣＡＥ０００３」）を取得し、対応するリソースｒｅｓｏｕｒｃｅ１のａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ属性から、そのリソースに関連付けられた全てのＡＣＰ ＩＤのリストを見つけ出し、これらのＡＣＰからｐｒｉｖｉｌｅｇｅｓ．ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ属性値が「／ＣＳＥ０００５／ＣＡＥ０００１」を含むＡＣＰリソースを検索し、当該ＡＣＰリソースのｐｒｉｖｉｌｅｇｅｓ．ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ属性値を「／ＣＳＥ０００６／ＣＡＥ０００３」に更新する。

段階５２６：リソースサーバが、認可更新応答を認可サーバに送信する。

Ｈ−ＣＳＥが認可更新を完了した後に、Ｈ−ＣＳＥは、認可更新応答をＡＳに返す。具体的には、Ｈ−ＣＳＥが認可更新を完了した後に、Ｈ−ＣＳＥによりＡＳに返される認可更新応答は、以下の通りである。
ＨＴＴＰ／１．１ ２００ ＯＫ

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、Ｈ−ＣＳＥが、対応するＡＣＰリソースの更新を既に完了していることを示す。

段階５２８：認可サーバが、署名検証応答をＡＥに送信する。

ＡＳがＨ−ＣＳＥの認可更新応答を受信した後に、ＡＳは、署名検証応答をＡＥに返す。

具体的には、ＡＳがＨ−ＣＳＥの認可更新応答を受信した後に、ＡＳによりＡＥに返される署名検証応答は、以下の通りである。
ＨＴＴＰ／１．１ ２００ ＯＫ

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、ＡＳが、ＡＥにより要求された認可更新を既に完了していることを示す。

ＡＥが認可サーバにより送信された署名検証応答を受信した後に、これは、認可関係の更新がＭ２Ｍシステムにおいて既に完了していることを示す。この場合、ＡＥは、アクセスデバイス識別子ＡＥ−ＩＤ２を用いてアクセス先リソース／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１にアクセスしてよい。

本実施形態において、Ｍ２ＭシステムにおけるＡＥのようなＭ２Ｍデバイスが、識別子が変更された後にアクセス先リソースにアクセスした場合、リソースサーバが認可関係更新手順をトリガする。Ｍ２Ｍシステムは、アクセスデバイスの検証情報の署名を検証することによりアクセスデバイスのアイデンティティを判定し、既存の認可関係を更新する。よって、Ｍ２Ｍデバイスはシームレスなリソースアクセスを実現することができ、Ｍ２Ｍシステムのサービス連続性が保証される。

アクセスデバイスのリソースアクセスを認可するのにＯＡｕｔｈ認可アーキテクチャがＭ２Ｍシステムにおいて用いられる場合、検証情報は、認可サーバにより生成されるアクセストークンであってよい。具体的には、図６Ａ、図６Ｂ、および図７に示す実施形態において、ＯＡｕｔｈ認可アーキテクチャに基づいて行われる認可手順は、初期認可および認可更新の２つの手順を含むものとしてＭ２Ｍシステムにおいて提供される。初期認可は、アクセスデバイスの識別子が変更される前に、認可サーバが、アクセスデバイスについてのアイデンティティ検証情報を取得し、認可関係を生成する手順である。

図６Ａおよび図６Ｂを参照すると、図６Ａおよび図６Ｂは、本発明に係る、ＯＡｕｔｈ認可アーキテクチャに基づいて行われる初期認可のフローチャートである。本実施形態におけるアクセスデバイスは、アプリケーションエンティティＡＥである。しかしながら、アクセスデバイスの具体的な形態は、本発明の本実施形態において限定されるものではない。初期認可手順は、以下の段階を含む。

段階６０２および段階６０４：ＡＥが、登録要求をレジストラ１（Ｒ−ＣＳＥ１）に送信し、レジストラ１が、アイデンティティ識別子ＡＥ−ＩＤ１をＡＥに割り当てる。

段階６０６：ＡＥが、リソースサーバ（Ｈ−ＣＳＥ）への初期リソースアクセス要求を開始する。リソースアクセス要求は、ＡＥ−ＩＤ１とアクセス先リソースのＵＲＩとを含む。

具体的には、ＡＥが、初期リソースアクセス要求をＨ−ＣＳＥに送信する。例えば、ＡＥにより開始されるＨ−ＣＳＥへのリソースアクセス要求は、以下の通りである。
ＧＥＴ ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１？ｆｒｏｍ＝／ＣＳＥ０００５／ＣＡＥ０００１ ＨＴＴＰ／１．１

「ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」は、アクセス先リソースのＵＲＩであり、「ｆｒｏｍ＝／ＣＳＥ０００５／ＣＡＥ０００１」は、ＡＥのアクセスデバイス識別子、すなわち、ＡＥ−ＩＤ１を示す。ＡＥは、初めてアクセス先リソースにアクセスし、ＡＥは、当該リソースにバインドされるアクセストークンをローカルで記憶していない。よって、初期リソースアクセス要求は、アクセストークンパラメータを含まない。

段階６０８：リソースサーバ（Ｈ−ＣＳＥ）が、ＡＥにより送信されたリソースアクセス要求を受信し、アクセス制御判断を行う。

具体的には、Ｈ−ＣＳＥは、リソースアクセス要求を受信した場合、まず、リソースアクセス要求におけるアクセス先リソースのＵＲＩに従って対応するリソースをローカルで検索する。当該リソースがローカルで見つからない場合には、Ｈ−ＣＳＥは、ＡＥにリソースアクセス拒否応答、例えば、ＨＴＴＰ／１．１ ４０４ Ｎｏｔ Ｆｏｕｎｄを返す。アクセス先リソースがローカルで見つかった場合には、Ｈ−ＣＳＥは、リソースアクセス要求におけるアクセスデバイス識別子およびアクセストークンに従って、対応する認可関係をリソース属性から検索する。ＡＥにより送信されたリソースアクセス要求が初期リソースアクセス要求である場合、段階６０６において説明したように、当該要求はアクセストークンパラメータを含まず、Ｈ−ＣＳＥは、ＡＥが初めてリソースにアクセスしていると判定し、Ｈ−ＣＳＥは認可手順を開始する。

段階６１０：リソースサーバが、リソースアクセス応答をＡＥに返す。

当該応答は、リダイレクト応答コードとリダイレクトＵＲＬとを含む。リダイレクトＵＲＬは、Ｍ２Ｍシステムにおける認可サーバの動的認可アドレスを指定する。

具体的には、Ｈ−ＣＳＥは、リソースアクセスを要求するＡＥにリソースアクセス応答を返す。例えば、Ｈ−ＣＳＥによりＡＥに返されるリソースアクセス応答は、以下の通りであってよい。
ＨＴＴＰ／１．１ ３０２ Ｍｏｖｅ ｔｅｍｐｏｒａｒｉｌｙ
Ｌｏｃａｔｉｏｎ：ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ｄｙｎａｍｉｃａｕｔｈｚ＃ｆｒｏｍ＝／ＣＳＥ０００５／ＣＡＥ０００１＆ｒｅｓ＿ｕｒｉ＝ ／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１

ＨＴＴＰ応答のステータスコードは「３０２」であり、これは、ＡＥのリソースアクセス要求が新たなＵＲＬにリダイレクトされる必要があることを示す。「Ｌｏｃａｔｉｏｎ」は、リダイレクトＵＲＬを示す。リダイレクトＵＲＬは、Ｍ２Ｍシステムにおける認可サーバの動的認可アドレスを指定する。例えば、ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ｄｙｎａｍｉｃａｕｔｈｚは、認可サーバの動的認可アドレスである。「＃ｆｒｏｍ＝／ＣＳＥ０００５／ＣＡＥ０００１＆ｒｅｓ＿ｕｒｉ＝／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」は、リダイレクトされたリソースアクセス要求に添付される必要があるパラメータ情報であり、クエリストリングの形態で示される。本例において、添付パラメータ情報は、アクセスデバイス識別子が「／ＣＳＥ０００５／ＣＡＥ０００１」であること、および、アクセス先リソースのＵＲＩが「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」であることである。

段階６１２：ＡＥが、認可要求をリソースサーバに送信する。認可要求は、ＡＥ−ＩＤ１とアクセス先リソースのＵＲＩとを含む。

ＡＥは、Ｈ−ＣＳＥのリソースアクセス応答を受信した後に、認可要求をＡＳに送信する。段階６１０におけるリソースアクセス応答におけるＬｏｃａｔｉｏｎパラメータにおいて提供されるリダイレクトＵＲＬは、認可要求のアドレス中に用いられる。

具体的には、ＡＥが、Ｈ−ＣＳＥのリソースアクセス応答を受信し、ＨＴＴＰステータスコードを検出する。ステータスコードが「３０２」である場合、ＡＥは、認可要求をＡＳに送信する。例えば、ＡＥによりＡＳに送信される認可要求は、以下の通りである。
ＧＥＴ ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ ／ｄｙｎａｍｉｃａｕｔｈｚ？ｆｒｏｍ＝／ＣＳＥ０００５／ＣＡＥ０００１＆ｒｅｓ＿ｕｒｉ＝ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１ ＨＴＴＰ／１．１

「／ｄｙｎａｍｉｃａｕｔｈｚ？ｆｒｏｍ＝／ＣＳＥ０００５／ＣＡＥ０００１＆ｒｅｓ＿ｕｒｉ＝ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」は、認可サーバの動的認可アドレスと、添付パラメータ情報とを示す。添付パラメータ情報は、ＡＥ−ＩＤ１とアクセス先リソースのＵＲＩとを含む。「Ｈｏｓｔ」は、本実施形態では「ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｎｉｎｇｓ．ｃｏｍ」である、認可サーバのアドレスを記述する。ＡＥは、認可要求をＡＳに送信する場合、Ｈｏｓｔパラメータを用いるのではなく、ＧＥＴ要求を直接用いて、リソースアクセス応答におけるＬｏｃａｔｉｏｎパラメータにおいて提供されるリダイレクトＵＲＬにアクセスしてよい。例えば、認可要求は、以下の通りであってよい。
ＧＥＴ ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ｄｙｎａｍｉｃａｕｔｈｚ？ｆｒｏｍ＝／ＣＳＥ０００５／ＣＡＥ０００１
＆ｒｅｓ＿ｕｒｉ＝／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１ ＨＴＴＰ／１．１

第１行の末尾の改行は、説明を明確にすることを意図したものに過ぎない。具体的な実現形態においては、上述の２つのメッセージ行の間には改行が存在しない。

段階６１４：認可サーバが、認可応答をＡＥに返す。認可応答は、ユーザ認証を要求するためのフラグビットを含む。

具体的には、ＡＳは、ＡＥの認可要求を受信した後に、まず認可要求がユーザ認証に関連するパラメータを含むか否かを検出する。認可要求がユーザ認証情報を含まない場合、ＡＳによりＡＥに返される認可応答は、以下の通りである。
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ＮｅｅｄＵｓｅｒＡｕｔｈＮ"： "１"｝

ＨＴＴＰ応答のステータスコードは「２０２」であり、これは、認可要求が既に受信されていることを示す。しかしながら、後続の処理にはさらなる情報が必要である。ＨＴＴＰメッセージボディ中、「"ＮｅｅｄＵｓｅｒＡｕｔｈＮ"： "１"」パラメータは、ユーザ認証を要求するためのフラグビットを示す。当該パラメータは、ＡＥがユーザ認証情報を次回の認可要求に付加する必要があることを示す。

段階６１６：ＡＥが、認可サーバにより送信された認可応答を受信し、ＡＥが、当該応答がユーザ認証を要求するためのフラグビットを含むことを検出した場合、ＡＥにユーザ認証情報を入力するようユーザに命令する。

具体的には、ＡＥは、ＡＳにより送信された認可応答を受信し、ＨＴＴＰステータスコードを検出する。ステータスコードが「２０２」である場合、ＡＥは、ＨＴＴＰメッセージボディの検出を継続する。ＡＥは、メッセージボディが「ＮｅｅｄＵｓｅｒＡｕｔｈＮ」パラメータを含むこと、および、当該パラメータの値が「１」であることを検出した場合、ＡＥにユーザ認証情報を入力するようユーザに命令する。ここでユーザは、ＡＥが存在するデバイスのユーザインタラクション能力に従って、適切な入力方法を選択してよい。例えば、当該デバイスが（キーボードまたはタッチスクリーンのような）ユーザインタラクションインターフェースを有する場合、ユーザは、ユーザのアカウントおよびパスワードを当該インタラクションインターフェースを用いて入力してよい。当該デバイスがユーザインタラクションオペレーションをサポートしていない場合、ユーザは、別のインタラクションデバイスを用いてユーザ情報の入力を完了してよい。加えて、ユーザは、ユーザのアイデンティティを証明することができるアイデンティティカードのような物体を用いてアイデンティティ情報の入力を完了してよい。具体的には、ユーザ認証情報を入力するための方式は、本発明の議論の範囲外であり、本発明の解決手段に影響を及ぼさない。簡単のために、本発明の解決手段において、当該デバイスはユーザインタラクションインターフェースを有し、ユーザは当該インタラクションインターフェースを用いてユーザのアカウントｕｓｅｒ１およびパスワードｐａｓｓｗｏｒｄ１をＡＥに入力すると仮定する。

段階６１８：ユーザが、ユーザ認証情報を入力する。

段階６２０：ＡＥが、認可要求をリソースサーバに送信する。認可要求は、ＡＥ−ＩＤ１と、アクセス先リソースのＵＲＩと、ユーザ認証情報とを含む。

具体的には、ユーザがユーザのユーザ認証情報をＡＥ側に入力した後に、ＡＥによりＡＳに送信される認可要求は、以下の通りである。
ＧＥＴ ／ｄｙｎａｍｉｃａｕｔｈｚ？ｆｒｏｍ＝／ＣＳＥ０００５／ＣＡＥ０００１＆ｒｅｓ＿ｕｒｉ＝／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｕｓｅｒ"： "ｕｓｅｒ１"，
"ｐａｓｓｗｏｒｄ"： "ｐａｓｓｗｏｒｄ１"｝

段階６１２における認可要求と比較して、この認可要求にはユーザ認証情報に関連するパラメータが付加される。「"ｕｓｅｒ"： "ｕｓｅｒ１"」は、ユーザのアカウント名を示す。「"ｐａｓｓｗｏｒｄ"： "ｐａｓｓｗｏｒｄ１"」は、ユーザのアカウント名に対応するパスワードを示す。本実施形態において、ユーザ認証情報は、ＨＴＴＰメッセージボディに含まれ、ＪＳＯＮフォーマットを用いて符号化される。実際の実現形態において、ユーザ認証情報は、クエリストリングの形態でＧＥＴ要求のＵＲＬに含まれてよい。これは本発明において限定されるものではない。

段階６２２：認可サーバが、ユーザ認証情報に従ってユーザアイデンティティおよび権限を判定し、アクセストークン（ｔｏｋｅｎ）を生成する。

ＡＳがＡＥの認可要求を受信し、ユーザ認証情報を検出した後に、ＡＳは、認可要求からユーザ認証情報を取得し、ユーザ情報データベースにおけるユーザ認証情報を検証し、ユーザがリソースにアクセスする権限を有するか否かを判定する。ユーザアイデンティティおよび権限が確認された後に、ＡＳは、現在の認可についてのｔｏｋｅｎを生成する。

具体的には、ＡＳは、ＡＥの認可要求を受信した後に、まず認可要求がユーザ認証に関連するパラメータを含むか否かを検出する。認可要求のメッセージボディが「ｕｓｅｒ」および「ｐａｓｓｗｏｒｄ」のパラメータを含む場合、これは、ＡＥがユーザ認証を必要としていることを示す。次いで、ＡＳは、認可要求のメッセージボディから「ｕｓｅｒ」のパラメータ値「ｕｓｅｒ１」および「ｐａｓｓｗｏｒｄ」のパラメータ値「ｐａｓｓｗｏｒｄ１」を取得し、アカウント名が「ｕｓｅｒ１」であるユーザをユーザ情報データベースから検索し、当該ユーザのパスワードが「ｐａｓｓｗｏｒｄ１」に等しいか否かを検証する。ユーザ情報データベースは、Ｍ２Ｍシステムにおける全てのユーザ認証情報およびアクセス権限が記憶されたデータベースである。ユーザ情報データベースに記憶されたユーザ認証情報は、ＡＳにより用いられる認証方法に関連する。本実施形態において、ＡＳは、従来の方式でアカウント名およびパスワードを用いてユーザ認証を行う。よって、ユーザ情報データベースに記憶されたユーザ認証情報は、ユーザのアカウント名およびパスワードを少なくとも含む。加えて、ユーザ情報データベースに記憶されたユーザ認証情報は、ユーザがリソースにアクセスするための権限をさらに含んでよい。

アカウント名が「ｕｓｅｒ１」でありパスワードが「ｐａｓｓｗｏｒｄ１」に等しいユーザ記録をＡＳがユーザ情報データベースから見つけ出した場合、ＡＳは、アクセス先リソースのＵＲＩ、すなわち、「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」がユーザのアクセス権限に該当するものであるか否かをさらに判定する。権限の具体的な表現形態は、Ｍ２Ｍシステムにおける権限管理方式に関連する。本実施形態において、ユーザ権限情報は、ユーザ情報データベースにおいてアクセス可能リソースリストとして表されると仮定する。アクセス可能リソースリストは、ユーザがアクセスする権限を有する全てのリソースのＵＲＩを含む。ユーザによりユーザ情報データベースに記録されたアクセス可能リソースリストがアクセス先リソースのＵＲＩを含む場合、ＡＳは、現在の認可要求を認可し、現在の認可要求についての対応するアクセストークン（ｔｏｋｅｎ）を生成する。ｔｏｋｅｎの生成方式は、ＡＳにより自律的に決定される。どのｔｏｋｅｎ生成方法が用いられるかは、本発明の解決手段に影響を及ぼさない。本実施形態において、ｔｏｋｅｎは、ＡＳによりランダムに生成される長さ一定のストリング、例えば、「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」を用いて示されると仮定する。

段階６２４：認可サーバが、認可バインド要求をリソースサーバに送信する。認可バインド要求は、ＡＥ−ＩＤ１と、ｔｏｋｅｎと、アクセス先リソースのＵＲＩとを含む。

ＡＳがＡＥの認可要求についてのｔｏｋｅｎを生成した後に、ＡＳは、認可バインド要求をＨ−ＣＳＥに送信して、認可情報および対応するリソースをバインドおよび記憶するようＨ−ＣＳＥに命令する。認可バインド要求は、ＡＥ−ＩＤ１と、ｔｏｋｅｎと、アクセス先リソースのＵＲＩとを含む。

具体的には、ＡＳがＡＥの認可要求についてのｔｏｋｅｎを生成した後に、ＡＳによりＨ−ＣＳＥに送信される認可バインド要求は、以下の通りであってよい。
ＰＵＴ ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１ ＨＴＴＰ／１．１
Ｆｒｏｍ：／ＣＳＥ０００５／ＣＡＥ０００１
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"｝

ＰＵＴ要求におけるＵＲＬは、更新される必要があるアクセス先リソースのＵＲＩ、すなわち、「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」を示す。「Ｆｒｏｍ」は、アクセスデバイス識別子、すなわち、「／ＣＳＥ０００５／ＣＡＥ０００１」を示す。ＨＴＴＰメッセージボディ中、「"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"」は、アクセスデバイスとアクセス先リソースのＵＲＩとに対応するアクセストークンの具体的な値が「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」であることを示す。

段階６２６：リソースサーバが、認可サーバにより送信された認可バインド要求に従って、認可関係をバインドする。

Ｈ−ＣＳＥは、ＡＳの認可バインド要求におけるアクセス先リソースのＵＲＩに従って、Ｈ−ＣＳＥにより記憶されたアクセス先リソースを見つけ出す。次いで、ＡＳは、認可バインド要求からアクセスデバイス識別子およびアクセストークンを取得し、アクセス先リソースの対応するリソース属性にアクセスデバイス識別子およびアクセストークンを記憶する。

具体的には、Ｈ−ＣＳＥがＡＳの認可バインド要求を受信した後に、Ｈ−ＣＳＥは、認可バインド要求からアクセス先リソースのＵＲＩを取得、例えば、ＰＵＴ要求におけるＵＲＬからアクセス先リソースのＵＲＩ、すなわち、「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」を取得し、Ｈ−ＣＳＥによりローカルで記憶されたリソースからアクセス先リソースを見つけ出す。次に、Ｈ−ＣＳＥは、認可バインド要求からアクセスデバイスのＡＥ−ＩＤ１および対応するｔｏｋｅｎを取得、例えば、ＰＵＴ要求におけるＨＴＴＰヘッダフィールドの「Ｆｒｏｍ」パラメータからＡＥ−ＩＤ１、すなわち、「／ＣＳＥ０００５／ＣＡＥ０００１」を取得し、ＨＴＴＰメッセージボディにおける「ｔｏｋｅｎ」パラメータからアクセストークン、すなわち、「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」を取得する。次いで、Ｈ−ＣＳＥは、ＡＥ−ＩＤおよびｔｏｋｅｎをアクセス先リソースの対応するリソース属性に記憶する。

既存のｏｎｅＭ２Ｍ規格においては、アクセス制御ポリシー（ＡＣＰ）に対応する属性ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓのみがリソースオブジェクトについて定義され、対応するリソース属性は、ｔｏｋｅｎに基づく認可アーキテクチャについて定義されない。表８は、可能な認可関係バインド方法を提供する。リソースにバインドされる認可関係を示すのに用いられる認可関係属性ａｕｔｈｚＲｅｌが、リソースの一般属性に付加される。
表８ リソースの新たに付加された認可関係属性の例

表８に示すように、各リソース属性は、リソースにバインドされるいくつかの認可関係を示すためのいくつかのａｕｔｈｚＲｅｌ属性を含んでよく、各ａｕｔｈｚＲｅｌリソースは、ｓｕｂｊｅｃｔＩＤ（アクセスデバイス識別子）およびａｕｔｈｚＰｒｏｏｆ（アクセストークン）の２つの属性を含む２タプルのリソースとして示される。

Ｈ−ＣＳＥは、認可バインド要求からＡＥ−ＩＤ１およびｔｏｋｅｎパラメータを取得した後に、＜ａｕｔｈｚＲｅｌ＞リソースインスタンスａｕｔｈｚＲｅｌ１を構築する。ａｕｔｈｚＲｅｌ１のｓｕｂｊｅｃｔＩＤ属性値は「／ＣＳＥ０００５／ＣＡＥ０００１」に等しく、ａｕｔｈｚＰｒｏｏｆ属性値は「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」に等しい。Ｈ−ＣＳＥは、次いで、／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１に対応するリソースの属性にａｕｔｈｚＲｅｌ１リソースを付加し、それにより認可関係のバインドを完了する。

段階６２８：リソースサーバが、認可関係のバインドを完了した後に、認可バインド応答をＡＳに返す。

具体的には、Ｈ−ＣＳＥが認可関係のバインドを完了した後に、Ｈ−ＣＳＥによりＡＳに返される認可バインド応答は、以下の通りであってよい。
ＨＴＴＰ／１．１ ２００ ＯＫ

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、現在の認可関係がバインドされることに成功したことを示す。

段階６３０：認可サーバがリソースサーバにより送信された認可バインド応答を受信した後に、認可サーバが、認可応答をＡＥに返す。認可応答は、ｔｏｋｅｎと、アクセス先リソースのＵＲＩと、署名要求フラグビットとを含む。

具体的には、ＡＳがＨ−ＣＳＥの認可バインド応答を受信した後に、ＡＳによりＡＥに返される認可応答は、以下の通りであってよい。
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"，
"ｒｅｓ＿ｕｒｉ"： "／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１"，
"ＳｉｇＲｅｑ"： "１"｝

ＨＴＴＰ応答のステータスコードは「２０２」であり、これは、現在の認可要求が既に認可されていることを示す。しかしながら、後続の処理にはさらなる情報が必要である。ＨＴＴＰメッセージボディ中、「"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"」は、現在の認可で生成されるアクセストークンを示し、ＡＥは、対応するリソースへの次回のアクセスに当該ｔｏｋｅｎを用いてよい。「"ｒｅｓ＿ｕｒｉ"： "／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１"」は、現在の認可応答が「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」を対象とすることを示す。ｔｏｋｅｎは、リソースアクセスに用いられる。ｒｅｓ＿ｕｒｉパラメータは主に、ＡＥにより開始される複数の認可要求をＡＳが同時に処理する場合に用いられる。ｒｅｓ＿ｕｒｉパラメータは、ＡＥが認可応答メッセージを区別できることを確実にするべく用いられる。「"ＳｉｇＲｅｑ"： "１"」は、現在の認可に関連付けられた検証情報の署名をＡＳ側に記憶するには、ＡＥがｔｏｋｅｎ署名データをさらに提供する必要があることを示す、署名要求フラグビットである。

段階６３２：ＡＥが、アクセストークンを記憶し、デバイス出荷時の鍵を用いてアクセストークンに署名する。

ＡＥがＡＳの認可応答を受信した後に、ＡＥはまず、認可応答からｔｏｋｅｎとアクセス先リソースのＵＲＩとを取得し、ｔｏｋｅｎとアクセス先リソースのＵＲＩとをバインドしてローカルで記憶する。次いで、認可応答が署名要求フラグビットを含むことをＡＥが検出した場合には、ＡＥは、デバイス出荷時の鍵を用いて、受信されたｔｏｋｅｎに署名する。

具体的には、ＡＥがＡＳの認可応答を受信した後に、ＡＥはまず、認可応答からｔｏｋｅｎとアクセス先リソースのＵＲＩとを取得し、すなわち、ＨＴＴＰ応答メッセージボディにおける「ｔｏｋｅｎ」パラメータからアクセストークン「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」を取得し、「ｒｅｓ＿ｕｒｉ」パラメータからアクセス先リソースのＵＲＩ、すなわち、「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」を取得し、アクセストークンとアクセス先リソースのＵＲＩとをバインドしてローカルで記憶する。記憶方法は、アクセストークンマッピング表を用いて実現されるものであってよく、または別の記憶方式が用いられる。具体的な実現形態において、どの記憶方法が用いられるかは、本発明の解決手段に影響を及ぼさない。本実施形態において、ＡＥ側は、アクセストークンマッピング表を用いてアクセス先リソースのＵＲＩとｔｏｋｅｎとの間の対応関係を記憶すると仮定する。以下の表９に示すように、表９の各行は、ＡＥにより既に取得されている１つの認可を示す。
表９ アクセストークンマッピング表

次いで、ＡＥは、認可応答が署名要求フラグビット「ＳｉｇＲｅｑ」を含むか否かを検出する。認可応答が「ＳｉｇＲｅｑ」パラメータを含み、「ＳｉｇＲｅｑ」パラメータの値が「１」である場合、ＡＥは、予め設定された署名アルゴリズムとデバイス出荷時の鍵とを用いてｔｏｋｅｎに署名する。署名アルゴリズムは、ＭＡＣまたはＨＭＡＣのような一般的な署名アルゴリズムであってよい。具体的な実現形態において、どの署名アルゴリズムが用いられるかは、本発明の解決手段に影響を及ぼさない。本実施形態において、ＡＥはＭＡＣ署名アルゴリズムを用い、上述のｔｏｋｅｎを計算することにより取得される署名は「８４５６Ｂ１ＣＤ」であると仮定する。

段階６３４：ＡＥがｔｏｋｅｎの署名を完了した後に、ＡＥが、認可サーバへの署名バインド要求を開始する。当該要求は、ＡＥ−ＩＤ１と、ｔｏｋｅｎと、ｔｏｋｅｎ署名と、アクセス先リソースのＵＲＩとを含む。

具体的には、ＡＥがｔｏｋｅｎの署名を完了した後に、ＡＥにより開始されるＡＳへの署名バインド要求は、以下の通りであってよい。
ＰＵＴ ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ｄｙｎａｍｉｃａｕｔｈｚ ＨＴＴＰ／１．１
Ｆｒｏｍ：／ＣＳＥ０００５／ＣＡＥ０００１
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"，
"ｔｏｋｅｎ＿ｓｉｇ"： "８４５６Ｂ１ＣＤ"，
"ｒｅｓ＿ｕｒｉ"： "／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１"｝

ＰＵＴ要求におけるＵＲＬアドレス、すなわち、「ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ｄｙｎａｍｉｃａｕｔｈｚ」は、ＡＳの動的認可アドレスである。「Ｆｒｏｍ」は、署名バインド要求を開始するアクセスデバイスの識別子を示す。ＨＴＴＰメッセージボディ中、「ｔｏｋｅｎ」および「ｔｏｋｅｎ＿ｓｉｇ」のパラメータは、それぞれ、署名バインドを行う必要があるｔｏｋｅｎと、ｔｏｋｅｎ署名とを示す。

段階６３６：認可サーバが、ＡＥの署名バインド要求を受信した後に、対応する認可関係を生成し、当該認可関係を認可関係マッピング表に記憶する。

具体的には、ＡＳは、ＡＥの署名バインド要求を受信した後に、まず現在の認可についての認可関係を生成する。認可関係は、アクセスデバイス識別子と、ｔｏｋｅｎと、ｔｏｋｅｎ署名と、アクセス先リソースのＵＲＩとを少なくとも含む。次いで、ＡＳは、生成された認可関係を認可関係マッピング表に付加する。認可関係マッピング表の構造は、表１０に示すものであってよい。
表１０ 認可関係マッピング表

表１０に示すように、この表の各行は、認可関係を示す。ＡＳがＡＥの署名バインド要求を受信した後に、ＡＳは、ＡＥの署名バインド要求から対応するパラメータ値を取得し、その値を対応する認可関係に付加する。本実施形態において、ＡＳは、表１０における二番目の記録に記載されているように、対応する認可関係を生成し、その認可関係を認可関係マッピング表に付加する。

具体的な実現形態において、上述の認可関係マッピング表は、ＡＳ内の共通データベースを用いて維持されてよく、またはＲＥＳＴｆｕｌリソースＡｕｔｈｚＲｅｌＭａｐＴａｂｌｅとして記述されてもよい。ｔｏｋｅｎに基づく認可アーキテクチャにおいて、ＡｕｔｈｚＲｅｌＭａｐＴａｂｌｅリソースは、以下の図に示す形態で示されてよい。
表１１ 認可関係マッピング表リソースおよび属性の例

ＡｕｔｈｚＲｅｌＭａｐＴａｂｌｅは、認可関係マッピング表リソースである。当該リソースは、いくつかの認可関係属性、すなわち、ａｕｔｈｚＲｅｃｏｒｄリソースを含む。ａｕｔｈｚＲｅｃｏｒｄは、認可関係リソースである。当該リソースは、以下の属性を含む。
ｓｕｂｊｅｃｔＩＤ：表１０におけるアクセスデバイス識別子に対応する。
ｔｏｋｅｎ：表１０におけるｔｏｋｅｎ属性に対応する。
ｔｏｋｅｎ＿ｓｉｇ：表１０におけるｔｏｋｅｎ署名属性に対応する。
ｒｅｓ＿ｕｒｉ：表１０におけるアクセス先リソースのＵＲＩ属性に対応する。

認可関係マッピング表の具体的な表現形態は、本発明において限定されるものではないことに留意されたい。

段階６３８：認可サーバが、署名バインド応答をＡＥに返す。

具体的には、ＡＳが認可関係の記憶を完了した後に、ＡＳによりＡＥに返される署名バインド応答は、以下の通りであってよい。
ＨＴＴＰ／１．１ ２００ ＯＫ

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、現在の署名バインド要求が既に完了していることを示し、ＡＥは、ｔｏｋｅｎを用いて対応するリソースにアクセスしてよい。

本発明の本実施形態において、受信されたリソースアクセス要求がアクセストークンを含まないとリソースサーバが判定した場合、リソースサーバによりアクセスデバイスに返されるリソースアクセス応答は、認可サーバのＵＲＩを保持し、それによりアクセスデバイスは、認証認可を認可サーバに申請する。認可サーバは、ユーザ認証情報が有効であることを検証し、アクセストークンを生成する。認可サーバは、アクセスデバイス識別子と、アクセス先リソースのＵＲＩと、生成されたアクセストークンとをリソースサーバに送信し、それによりリソースサーバは、対応する認可関係を生成する。認可サーバは、生成されたアクセストークンとアクセス先リソースのＵＲＩとをＡＥに送信し、アクセストークンに署名するようＡＥに要求する。ＡＥは、アクセス先リソースのＵＲＩとアクセストークンとの間の対応関係を記憶する。認可サーバは、アクセスデバイス識別子と、アクセス先リソースのＵＲＩと、アクセストークンと、アクセストークンの署名との間の対応関係を認可関係マッピング表に記憶する。

その後アクセス先リソースがアクセスされる必要がある場合、対応するアクセストークンがリソースアクセス要求に保持される必要がある。その後ＡＥがアクセス先リソースにアクセスするときに、アクセスデバイス識別子が変更されている場合には、リソースサーバは、アクセス先リソースのＵＲＩおよびアクセストークンはリソースアクセス要求におけるものと一致するがアクセスデバイス識別子は一致しない、ローカルで存在する認可関係に従って、アクセスデバイス識別子が変更された可能性があると判定し、認可更新手順をトリガしてよい。

図７を参照すると、図７は、本発明に係る、ＯＡｕｔｈ認可アーキテクチャに基づいて行われる認可更新のフローチャートである。図６Ａおよび図６Ｂの実施形態におけるＡＥが、アクセス位置の変更のような理由により異なるレジストラ（例えば、Ｒ−ＣＳＥ２）に登録する場合、新たなレジストラＲ−ＣＳＥ２が新たな識別子ＡＥ−ＩＤ２をＡＥに割り当ててよい。その結果、Ｍ２Ｍシステムにおける既存の認可関係は無効になる。図７の方法は、アクセス識別子が変更された後に認可関係を更新するための方法である。当該方法は、以下の段階を備える。

段階７０２および段階７０４：ＡＥが、レジストラ２（Ｒ−ＣＳＥ２）への登録要求を開始し、レジストラ２が、識別子ＡＥ−ＩＤ２をＡＥに割り当てる。

段階７０６：ＡＥが、アクセス先リソースのＵＲＩに従って、当該リソースに対応するｔｏｋｅｎをローカルで見つけ出し、リソースアクセス要求をリソースサーバ（Ｈ−ＣＳＥ）に送信する。リソースアクセス要求は、ＡＥ−ＩＤ２と、アクセス先リソースのＵＲＩと、アクセス先リソースのＵＲＩに対応するｔｏｋｅｎとを含む。

具体的には、図６Ａおよび図６Ｂにおける方法の段階６３２で説明したように、初期認可が行われた後に、ＡＥは、アクセス先リソースのＵＲＩとアクセストークンとの間の対応関係を記憶する。ＡＥはまず、アクセス先リソースのＵＲＩに従って、ローカルで記憶された認可情報から対応するｔｏｋｅｎを見つけ出し、次いでＡＥは、リソースアクセス要求をＨ−ＣＳＥに送信する。

段階７０８：リソースサーバが、ＡＥにより送信されたリソースアクセス要求を受信し、アクセス制御判断を行う。

具体的には、段階６２６で説明したように、リソースサーバは、アクセス先リソースのＵＲＩと、ＡＥ−ＩＤ１と、対応するアクセストークンとの間の認可関係を記憶する。Ｈ−ＣＳＥは、リソースアクセス要求をパースして、アクセス先リソースのＵＲＩと、ＡＥ−ＩＤ２と、ｔｏｋｅｎとを取得する。アクセス先リソースがローカルで存在するとＨ−ＣＳＥが判定したときに、Ｈ−ＣＳＥが、ａｕｔｈｚＰｒｏｏｆ属性値がｔｏｋｅｎと同一であるもののｓｕｂｊｅｃｔＩＤ属性値がＡＥ−ＩＤ２とは異なる認可記録を、アクセス先リソースの認可関係属性（ａｕｔｈｚＲｅｌ）から見つけ出した場合には、リソースサーバは、認可更新手順を始める。

段階７１０：リソースサーバが、リソースアクセス応答をＡＥに返す。当該応答は、リダイレクト応答コードとリダイレクトＵＲＬとを含み、リダイレクトＵＲＬは、Ｍ２Ｍシステムにおける認可サーバの認可更新ポートを指定する。

具体的には、Ｈ−ＣＳＥは、ＡＥにリソースアクセス応答を返す。例えば、Ｈ−ＣＳＥによりＡＥに返されるリソースアクセス応答は、以下の通りであってよい。
ＨＴＴＰ／１．１ ３０２ Ｍｏｖｅ ｔｅｍｐｏｒａｒｉｌｙ
Ｌｏｃａｔｉｏｎ：ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ａｕｔｈｚｕｐｄａｔｅ＃ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００３＆ｒｅｓ＿ｕｒｉ＝ ／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１＆ｔｏｋｅｎ＝２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ

ＨＴＴＰ応答のステータスコードは「３０２」であり、これは、ＡＥのリソースアクセス要求が新たなＵＲＬにリダイレクトされる必要があることを示す。「Ｌｏｃａｔｉｏｎ」は、リダイレクトＵＲＬを示す。リダイレクトＵＲＬは、Ｍ２Ｍシステムにおける認可サーバの認可更新ポートを指定する。例えば、ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ａｕｔｈｚｕｐｄａｔｅは、認可サーバの動的認可アドレスである。「＃ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００３＆ｒｅｓ＿ｕｒｉ＝／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１＆ｔｏｋｅｎ＝２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」は、リダイレクトされたリソースアクセス要求に添付される必要があるパラメータ情報であり、クエリストリングの形態で示される。上述の添付パラメータ情報の具体的な内容については、段階５１０における説明を参照のこと。本発明の本実施形態では詳細を説明しない。

段階７１２：ＡＥが、リソースサーバのリソースアクセス応答を受信し、認可更新要求を認可サーバ（ＡＳ）に送信する。当該応答におけるＬｏｃａｔｉｏｎパラメータにおいて提供されるＵＲＬは、認可更新要求のアドレス中に用いられる。

具体的には、ＡＥが、Ｈ−ＣＳＥのリソースアクセス応答を受信し、ＨＴＴＰステータスコードを検出する。ステータスコードが「３０２」である場合、ＡＥは、認可更新要求をＡＳに送信する。例えば、ＡＥによりＡＳに送信される認可更新要求は、以下の通りである。
ＧＥＴ ／ａｕｔｈｚｕｐｄａｔｅ？ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００１＆ｒｅｓ＿ｕｒｉ＝ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１
＆ｔｏｋｅｎ＝２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ

リダイレクト応答におけるＬｏｃａｔｉｏｎパラメータは、以下の２つの部分に分けられる。つまり、ＧＥＴ要求におけるＵＲＬアドレス「／ａｕｔｈｚｕｐｄａｔｅ？ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００１＆ｒｅｓ＿ｕｒｉ＝ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１＆ｔｏｋｅｎ＝２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」は、認可サーバのローカル認可更新ポートアドレスと添付パラメータ情報とを示し、「Ｈｏｓｔ」は、本実施形態では「ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｎｉｎｇｓ．ｃｏｍ」である、認可サーバのアドレスを記述する。ＡＥは、認可更新要求をＡＳに送信する場合、Ｈｏｓｔパラメータを用いるのではなく、ＧＥＴ要求を直接用いて、リダイレクト応答におけるＬｏｃａｔｉｏｎパラメータにおいて提供されるリダイレクトＵＲＬにアクセスしてよい。例えば、認可更新要求は、以下の通りであってよい。
ＧＥＴ ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ａｕｔｈｚｕｐｄａｔｅ？ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００１
＆ｒｅｓ＿ｕｒｉ＝／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１＆ｔｏｋｅｎ＝２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ ＨＴＴＰ／１．１

段階７１４：認可サーバが、ＡＥの認可更新要求を受信した後に、認可更新要求におけるｔｏｋｅｎに対応する、ローカルで存在する認可関係を判定する。

具体的には、ＡＳがＡＥの認可更新要求を受信した後に、ＡＳはまず、認可更新要求のクエリストリングをパースして、ｔｏｋｅｎとアクセス先リソースのＵＲＩとを取得する。例えば、ｔｏｋｅｎは「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」であり、アクセス先リソースのＵＲＩは「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」である。次いで、ＡＳは、「Ｔｏｋｅｎ」列の値が「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」であり、「アクセス先リソースのＵＲＩ」列の値が「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」である認可関係を、ローカルで記憶された認可関係マッピング表から検索する。認可関係マッピング表が、段階６３６における表１１で説明したＲＥＳＴｆｕｌリソースＡｕｔｈｚＲｅｌＭａｐＴａｂｌｅを用いて実現される場合、ｔｏｋｅｎ値が「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」に等しくｒｅｓ＿ｕｒｉが「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」に等しいａｕｔｈｚＲｅｃｏｒｄ認可関係が、ＡｕｔｈｚＲｅｌＭａｐＴａｂｌｅ属性から検索される。上述の条件を満足する認可記録がない場合には、ＡＳは、ＡＥの認可更新要求を拒否し、認可更新失敗応答：ＨＴＴＰ／１．１ ４０４ Ｎｏｔ ＦｏｕｎｄをＡＥに返す。ＨＴＴＰ応答のステータスコードは「４０４」であり、これは、ＡＳが、対応する認可記録を見つけ出さなかったことを示す。条件を満足する認可関係があった場合には、ＡＳは、認可更新応答をＡＥに返して、ｔｏｋｅｎに署名するようＡＥに要求する。

段階７１６：認可サーバが、認可更新応答をＡＥに返す。当該応答は、ＨＴＴＰ２０２応答コードと、ｔｏｋｅｎと、署名要求フラグビットとを含む。

具体的には、ＡＳが認可更新手順を始めた後に、ＡＳによりＡＥに返される認可更新応答は、以下の通りである。
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"，
"ＳｉｇＲｅｑ"： "１"｝

ＨＴＴＰ応答のステータスコードは「２０２」であり、これは、ＡＳが既にＡＥの認可更新要求を受理していることを示す。しかしながら、後続の処理にはさらなる情報が必要である。ＨＴＴＰメッセージボディ中、「"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"」は、ｔｏｋｅｎに対応する認可関係に署名が要求されていることを示す。ＡＥは、当該認可関係に対応する検証情報に署名する必要がある。本実施形態において、検証情報はｔｏｋｅｎである。具体的な実現形態においては、他の情報（例えば、元のＡＥ−ＩＤ）が検証情報として用いられてよい。これは、ＡＳの認可更新ポートの具体的な実現形態に依存する。ＨＴＴＰメッセージボディ中、「"ＳｉｇＲｅｑ"： "１"」は署名要求フラグビットであり、これは、ＡＳがＡＥのアイデンティティを確認できるよう、ＡＥがｔｏｋｅｎ署名データをさらに提供する必要があることを示す。

具体的な実現形態において、検証情報ｔｏｋｅｎは、認可更新応答に必須のものではないことに留意されたい。

段階７１８：ＡＥが、受信されたリソースアクセス応答が署名要求フラグビットを含むことを検出した場合、デバイス出荷時の鍵を用いて、受信されたｔｏｋｅｎに署名する。

具体的には、ＡＥがＨ−ＣＳＥのリソースアクセス応答を受信した後に、ＨＴＴＰ応答のステータスコードが「２０２」であること、および、ＨＴＴＰメッセージボディが値「１」の「ＳｉｇＲｅｑ」パラメータを含むことをＡＥが検出した場合、ＡＥは、ｔｏｋｅｎに署名する。

段階７２０：ＡＥがｔｏｋｅｎの署名を完了した後に、ＡＥが、認可サーバへの署名検証要求を開始する。当該要求は、ＡＥ−ＩＤ２と、ｔｏｋｅｎと、ｔｏｋｅｎ署名とを含む。

具体的には、ＡＥがｔｏｋｅｎの署名を完了した後に、ＡＥにより開始されるＡＳへの署名検証要求は、以下の通りである。
ＰＵＴ ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ａｕｔｈｚｕｐｄａｔｅ ＨＴＴＰ／１．１
Ｆｒｏｍ：／ＣＳＥ０００６／ＣＡＥ０００１
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"，
"ｔｏｋｅｎ＿ｓｉｇ"： "８４５６Ｂ１ＣＤ"，
"ｒｅｓ＿ｕｒｉ"： "／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１"｝

各パラメータの解説については、段階６３４における説明を参照のこと。本発明の本実施形態では詳細を説明しない。

段階７２２：認可サーバが、ＡＥの署名検証要求からｔｏｋｅｎおよびｔｏｋｅｎ署名を取得し、次いで、ｔｏｋｅｎに対応する認可関係を認可関係マッピング表から検索し、署名検証要求におけるｔｏｋｅｎ署名が当該認可関係におけるｔｏｋｅｎ署名と一致するか否かを検証する。

具体的には、ＡＳがＡＥの署名検証要求を受信した場合、ＡＳはまず、ＡＥの署名検証要求をパースして、ｔｏｋｅｎ値「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」およびｔｏｋｅｎ署名値「８４５６Ｂ１ＣＤ」を取得する。次いで、ＡＳは、「Ｔｏｋｅｎ」列における値が「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」に等しい認可関係を、ローカルで記憶された認可関係マッピング表から検索し、当該認可関係の「Ｔｏｋｅｎ署名」列が「８４５６Ｂ１ＣＤ」に等しいか否かを比較する。対応する認可記録における「Ｔｏｋｅｎ署名」列が「８４５６Ｂ１ＣＤ」に等しくない場合には、ＡＳは、署名検証失敗応答をＡＥに返す。当該応答は、ＨＴＴＰ４０３応答コード、例えば、ＨＴＴＰ／１．１ ４０３ Ｆｏｒｂｉｄｄｅｎを含む。「Ｔｏｋｅｎ署名」列が「８４５６Ｂ１ＣＤ」に等しい場合には、ＡＳは、認可関係を更新する、すなわち、ｔｏｋｅｎに対応する認可関係におけるアクセスデバイス識別子ＡＥ−ＩＤ１を、現在のアクセスデバイス識別子ＡＥ−ＩＤ２に変更する。

段階７２４：認可サーバが、第２認可更新要求をリソースサーバに送信する。当該要求は、アクセス先リソースのＵＲＩと、ｔｏｋｅｎと、ＡＥ−ＩＤ２とを含む。

具体的には、ＡＳが認可記録を更新する場合、ＡＳにより開始されるＨ−ＣＳＥへの認可更新要求は、以下の通りであってよい。
ＰＵＴ ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１ ＨＴＴＰ／１．１
Ｆｒｏｍ：／ＣＳＥ０００６／ＣＡＥ０００３
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"｝

ＰＵＴ要求におけるＵＲＬは、更新される必要があるアクセス先リソースのＵＲＩ、すなわち、「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」を示す。「Ｆｒｏｍ」は、新たなアクセスデバイス識別子ＡＥ−ＩＤ２、すなわち、「／ＣＳＥ０００６／ＣＡＥ０００３」を示す。ＨＴＴＰメッセージボディ中、「"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"」は、アクセスデバイスとアクセス先リソースのＵＲＩとに対応するアクセストークンの具体的な値が「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」であることを示す。

段階７２６：リソースサーバが、認可サーバの第２認可更新要求を受信した後に、アクセス先リソースのＵＲＩに従って、ローカルで記憶されたアクセス先リソースｒｅｓｏｕｒｃｅ１を見つけ出し、アクセストークンがｔｏｋｅｎである認可記録をｒｅｓｏｕｒｃｅ１の認可関係属性から検索し、認可記録におけるアクセスデバイス識別子をＡＥ−ＩＤ２に更新する。

具体的には、Ｈ−ＣＳＥがＡＳの認可更新要求を受信した後に、Ｈ−ＣＳＥはまず、認可更新要求のＵＲＬから、アクセス先リソースのＵＲＩ、すなわち、「／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１」を取得し、リソースｒｅｓｏｕｒｃｅ１をローカルで見つけ出す。次いで、Ｈ−ＣＳＥは、認可更新要求における「Ｆｒｏｍ」ヘッダフィールドとＨＴＴＰメッセージボディとを別々にパースして、ｔｏｋｅｎおよびＡＥ−ＩＤ２の値、すなわち、ｔｏｋｅｎが「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」でありＡＥ−ＩＤ２が「／ＣＳＥ０００６／ＣＡＥ０００１」である値を取得し、アクセストークンがｔｏｋｅｎである認可記録をｒｅｓｏｕｒｃｅ１の認可関係属性から検索し、認可記録におけるアクセスデバイス識別子をＡＥ−ＩＤ２に更新する。具体的には、Ｈ−ＣＳＥは、ａｕｔｈｚＰｒｏｏｆ属性値が「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」に等しい認可記録を、ｒｅｓｏｕｒｃｅ１のａｕｔｈｚＲｅｌ属性から検索し、次いで、認可記録における対応するｓｕｂｊｅｃｔＩＤ属性値を「／ＣＳＥ０００６／ＣＡＥ０００３」に変更する。

段階７２８：リソースサーバが、ローカル認可更新を完了した後に、第２認可更新応答を認可サーバに返す。当該応答は、ＨＴＴＰ２００ステータスコードを含む。

具体的には、Ｈ−ＣＳＥがローカル認可更新を完了した後に、Ｈ−ＣＳＥによりＡＳに返される認可更新応答は、以下の通りである。
ＨＴＴＰ／１．１ ２００ ＯＫ

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、Ｈ−ＣＳＥが、当該リソースに対応する認可更新を既に完了していることを示す。

段階７３０：認可サーバが、署名検証応答をＡＥに返す。当該応答は、ＨＴＴＰ２００応答コードを含む。

具体的には、ＡＳがＨ−ＣＳＥの認可更新応答を受信した後に、ＡＳによりＡＥに返される署名検証応答は、以下の通りである。
ＨＴＴＰ／１．１ ２００ ＯＫ

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、ＡＳが署名検証を既に完了していること、および、Ｍ２Ｍシステムが認可更新を既に完了していることを示す。

段階７３２：Ｍ２Ｍシステムが認可更新を既に完了しているとＡＥが判定した後に、ＡＥが、既存のリソースアクセス手順に従って、Ｈ−ＣＳＥへのリソースアクセス要求を開始し、対応するリソースを取得してよい。

本発明の本実施形態においては、Ｍ２ＭシステムにおけるＡＥのようなＭ２Ｍデバイスが、識別子が変更された後にアクセス先リソースにアクセスした場合、リソースサーバが認可関係更新手順をトリガする。Ｍ２Ｍシステムは、アクセスデバイスの検証情報の署名（ｔｏｋｅｎ署名）を検証することによりアクセスデバイスのアイデンティティを判定し、既存の認可関係を更新する。よって、Ｍ２Ｍデバイスはシームレスなリソースアクセスを実現することができ、Ｍ２Ｍシステムのサービス連続性が保証される。

図６Ａおよび図６Ｂにおける認可処理方法から、アクセスデバイスのリソースアクセスを認可するのにＯＡｕｔｈ認可アーキテクチャがＭ２Ｍシステムにおいて用いられる場合、認可サーバは、アクセスデバイス識別子と、ｔｏｋｅｎと、ｔｏｋｅｎ署名と、アクセス先リソースのＵＲＩとに対応する認可関係を記憶し、リソースサーバは、アクセスデバイス識別子と、ｔｏｋｅｎと、アクセス先リソースのＵＲＩとに対応する認可関係を記憶することがわかる。アクセスデバイス識別子が変更された後に、アクセス先リソースへのアクセスがリソースサーバから要求される場合、リソースサーバは、当該アクセスを拒否し、認可更新のためにアクセスデバイスのリソースアクセス要求を認可サーバへとリダイレクトする。認可サーバは、検証情報の署名、すなわち、ｔｏｋｅｎ署名に従ってアクセスデバイスのアイデンティティを判定し、さらにＭ２Ｍシステムにおける認可関係を更新する。実際には、リソースサーバが、アクセスデバイスのアイデンティティを検証し、さらにＭ２Ｍシステムにおける認可関係を更新してよい。

図８を参照すると、図８は、本発明に係る、ＯＡｕｔｈ認可アーキテクチャに基づいて行われる別の認可更新のフローチャートである。

段階８０２から段階８０８は、図７の実施形態における段階７０２から段階７０８と同一である。関連する説明については、図７の実施形態における関連する段階を参照のこと。ここでは詳細を再度説明しない。

段階８１０：リソースサーバが、署名データ要求を認可サーバ（ＡＳ）に送信する。当該要求は、ｔｏｋｅｎを含む。

具体的には、Ｈ−ＣＳＥが認可更新手順を開始する場合、Ｈ−ＣＳＥにより認可サーバに送信される署名データ要求は、以下の通りである。
ＧＥＴ ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ｓｉｇｑｕｅｒｙ？ｔｏｋｅｎ＝２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ ＨＴＴＰ／１．１

「ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ｓｉｇｑｕｅｒｙ」は、認可サーバの署名データ要求ポートアドレスである。「？ｔｏｋｅｎ＝２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」は、署名が要求される対象の対応するアクセストークンであり、クエリストリングの形態で示される。

段階８１２：認可サーバが、署名データ要求におけるｔｏｋｅｎに対応する、認可関係における署名を、ローカル認可関係マッピング表から取得する。

具体的には、ＡＳは、Ｈ−ＣＳＥの署名データ要求を受信した後に、まず署名データ要求におけるクエリストリングをパースして、ｔｏｋｅｎ値、例えば、「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」を取得する。次いで、ＡＳは、ローカルで記憶された認可関係マッピング表から検索を行って、ｔｏｋｅｎが、署名データ要求におけるものと同一である認可関係を「Ｔｏｋｅｎ」列から検索し、対応する認可関係における「Ｔｏｋｅｎ署名」値を取得する。例えば、段階６３６で説明した認可関係マッピング表（表１０）において、値が「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」に等しい認可関係が「Ｔｏｋｅｎ」列から検索され、次いで、当該認可関係における「Ｔｏｋｅｎ署名」、すなわち、「８４５６Ｂ１ＣＤ」が抽出される。

段階８１４：認可サーバが、署名データ応答をリソースサーバに返す。署名データ応答は、ｔｏｋｅｎ署名を含む。

具体的には、ＡＳによりＨ−ＣＳＥに返される署名データ応答は、以下の通りである。
ＨＴＴＰ／１．１ ２００ ＯＫ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｔｏｋｅｎ＿ｓｉｇ"： "８４５６Ｂ１ＣＤ"｝

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、現在の署名データ要求が既に認可されていることを示す。ＨＴＴＰメッセージボディ中、「"ｔｏｋｅｎ＿ｓｉｇ"： "８４５６Ｂ１ＣＤ"」は、要求されるｔｏｋｅｎ署名値が「８４５６Ｂ１ＣＤ」であることを示す。

段階８１６：リソースサーバが、リソースアクセス応答をＡＥに返す。当該応答は、署名要求フラグビットを含む。

具体的には、Ｈ−ＣＳＥがＡＳの署名データ応答を受信した後に、Ｈ−ＣＳＥによりＡＥに返されるリソースアクセス応答は、以下の通りであってよい。
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"，
"ＳｉｇＲｅｑ"： "１"｝

ＨＴＴＰ応答のステータスコードは「２０２」であり、これは、現在のリソースアクセス要求が既に処理されていることを示す。しかしながら、後続の処理にはさらなる情報が必要である。ＨＴＴＰメッセージボディ中、「"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"」は、ＡＥにより提供される必要がある署名データが、ｔｏｋｅｎに対応することを示す。当該パラメータは、主に、ＡＥにより開始される複数のリソースアクセス要求をＨ−ＣＳＥが同時に処理する場合に用いられ、当該パラメータは、ＡＥが異なるリソースアクセス応答メッセージを区別することを確実にするべく用いられる。「"ＳｉｇＲｅｑ"： "１"」は、Ｈ−ＣＳＥがＡＥのアイデンティティを確認できるよう、ＡＥがｔｏｋｅｎ署名データをさらに提供する必要があることを示す、署名要求フラグビットである。

段階８１８：ＡＥが、受信されたリソースアクセス応答が署名要求フラグビットを含むことを検出した場合、デバイス出荷時の鍵を用いて、受信されたｔｏｋｅｎに署名する。

この段階は、段階７１８と同一である。段階７１８における関連する説明を参照のこと。ここでは詳細を再度説明しない。

段階８２０：ＡＥがｔｏｋｅｎの署名を完了した後に、ＡＥが、Ｈ−ＣＳＥへのリソースアクセス要求を再開する。当該要求は、ＡＥ−ＩＤ２と、初期認可の間に取得されたｔｏｋｅｎと、ｔｏｋｅｎ署名と、リソースＵＲＩとを含む。

具体的には、ＡＥがｔｏｋｅｎの署名を完了した後に、ＡＥにより開始されるＨ−ＣＳＥへのリソースアクセス要求は、以下の通りであってよい。
ＧＥＴ ｈｔｔｐ：／／ｍ２ｍ．ｔｈｉｎｇｓ．ｃｏｍ／ＣＳＥ０００３／ｒｅｓｏｕｒｃｅ１？ｆｒｏｍ＝／ＣＳＥ０００６／ＣＡＥ０００１
＆ｔｏｋｅｎ＝２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ＆ｔｏｋｅｎ＿ｓｉｇ＝８４５６Ｂ１ＣＤ ＨＴＴＰ／１．１

段階８０６で説明したリソースアクセス要求と比較して、この段階では、リソースアクセス要求に保持される情報に、アクセストークン署名パラメータ、すなわち、「ｔｏｋｅｎ＿ｓｉｇ＝８４５６Ｂ１ＣＤ」が付加される。「ｔｏｋｅｎ＿ｓｉｇ＝８４５６Ｂ１ＣＤ」は、現在のリソースアクセス要求が、アクセストークンのみを保持するのではなく、アクセストークンに対応する署名データも保持することを示す。

段階８２２：Ｈ−ＣＳＥが、ＡＥのリソースアクセス要求を受信した後に、リソースアクセス要求からｔｏｋｅｎ署名を取得し、ｔｏｋｅｎ署名が、段階８１４で認可サーバから取得されたｔｏｋｅｎ署名と同一であるか否かを判定する。

具体的には、Ｈ−ＣＳＥがＡＥのリソースアクセス要求を受信した後に、Ｈ−ＣＳＥはまず、リソースアクセス要求におけるＨＴＴＰメッセージボディをパースしてｔｏｋｅｎ署名を取得する、すなわち、「ｔｏｋｅｎ＿ｓｉｇ」パラメータに対応する値「８４５６Ｂ１ＣＤ」を取得する。次いで、Ｈ−ＣＳＥは、リソースアクセス要求におけるｔｏｋｅｎ署名を、段階８１４における署名データ応答におけるｔｏｋｅｎ署名と比較する。例えば、本実施形態では、上述のｔｏｋｅｎ署名の両方の値が「８４５６Ｂ１ＣＤ」である。これらｔｏｋｅｎ署名が同一である場合、Ｈ−ＣＳＥは、リソースアクセス要求のアクセスデバイス、すなわち、ＡＥと、初期認可におけるＡＥとが同一のアクセスデバイスであることを確認する。これらｔｏｋｅｎ署名が異なる場合には、リソースサーバは、アクセスデバイスのアクセスを拒否し、手順は終了する。

段階８２４：署名が有効であることをリソースサーバが確認した後に、Ｈ−ＣＳＥが、ＡＳへの認可更新要求を開始する。当該要求は、ｔｏｋｅｎとＡＥ−ＩＤ２とを含む。

具体的には、Ｈ−ＣＳＥがＡＥと初期認可におけるアクセスデバイスとの間の対応関係を確認した後に、Ｈ−ＣＳＥにより開始されるＡＳへの認可更新要求は、以下の通りであってよい。
ＰＵＴ ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ａｕｔｈｚｕｐｄａｔｅ ＨＴＴＰ／１．１
Ｆｒｏｍ：／ＣＳＥ０００６／ＣＡＥ０００１
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｔｏｋｅｎ"： "２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ"｝

ＰＵＴ要求におけるＵＲＬアドレス、すなわち、「ｈｔｔｐ：／／ａｕｔｈｚｓｅｒｖｅｒ．ｔｈｉｎｇｓ．ｃｏｍ／ａｕｔｈｚｕｐｄａｔｅ」は、ＡＳの認可更新ポートアドレスである。「Ｆｒｏｍ」は、認可更新を必要とするアクセスデバイスの新たな識別子ＡＥ−ＩＤ２、すなわち、「／ＣＳＥ０００６／ＣＡＥ０００３」を示す。ＨＴＴＰメッセージボディ中、「ｔｏｋｅｎ」は、更新される必要がある認可関係における、対応するｔｏｋｅｎの値を示す。すなわち、更新される必要がある認可関係におけるｔｏｋｅｎ値は、「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」である。このパラメータは、ＡＳが、更新される必要がある認可関係を見つけ出すことを確実にするべく用いられる。

段階８２６：認可サーバが、ローカルで記憶された認可関係マッピング表を更新する。

具体的には、ＡＳは、Ｈ−ＣＳＥの認可更新要求を受信した後に、まず認可更新要求をパースして、アクセスデバイスの新たな識別子「／ＣＳＥ０００６／ＣＡＥ０００３」と、現在のリソースアクセス要求に対応する認可関係におけるｔｏｋｅｎ値「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」とを取得する。次いで、ＡＳは、「Ｔｏｋｅｎ」列の値が「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」である認可関係を、ローカルで記憶された認可関係マッピング表から検索する。認可関係マッピング表は、段階６３６において表１０で説明したものである。ＡＳは、対応する認可関係を見つけ出した後に、当該認可関係における「アクセスデバイス識別子」列の元の値「／ＣＳＥ０００５／ＣＡＥ０００１」を、認可更新要求における新たな識別子「／ＣＳＥ０００６／ＣＡＥ０００３」で置き換える。認可関係マッピング表が、段階６３６で説明したＲＥＳＴｆｕｌリソースＡｕｔｈｚＲｅｌＭａｐＴａｂｌｅを用いて実現される場合、認可更新は、ｔｏｋｅｎ値が「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」に等しいａｕｔｈｚＲｅｃｏｒｄ認可関係がＡｕｔｈｚＲｅｌＭａｐＴａｂｌｅ属性から検索されること、および、認可関係におけるｓｕｂｊｅｃｔＩＤが「／ＣＳＥ０００６／ＣＡＥ０００３」に更新されることである。

段階８２８：認可サーバが、認可関係マッピング表の更新が完了した後に、認可更新応答をリソースサーバに返す。

具体的には、ＡＳが認可関係マッピング表の更新を完了した後に、ＡＳによりＨ−ＣＳＥに返される認可更新応答は、以下の通りである。
ＨＴＴＰ／１．１ ２００ ＯＫ

ＨＴＴＰ応答のステータスコードは「２００」であり、これは、ＡＳが認可関係マッピング表の更新に既に成功していることを示す。

段階８３０：リソースサーバが、認可サーバの認可更新応答を受信した後に、アクセス先リソースに関連付けられた認可関係を更新する。

具体的には、Ｈ−ＣＳＥは、ＡＳの認可更新応答を受信した後に、ａｕｔｈｚＰｒｏｏｆがｔｏｋｅｎ（「２ＹｏｔｎＦＺＦＥｊｒ１ｚＣｓｉｃＭＷｐＡＡ」）に等しい認可関係を、アクセス先リソースのａｕｔｈｚＲｅｌ属性から検索し、認可関係におけるｓｕｂｊｅｃｔＩＤ値を「／ＣＳＥ０００６／ＣＡＥ０００３」に更新する。

段階８３２：リソースサーバが、アクセス先リソースに関連付けられた認可関係の更新を完了した後に、共通のリソースアクセス手順に従って、リソースアクセス応答をＡＥに返す。

具体的には、Ｈ−ＣＳＥが、アクセス先リソースに関連付けられた認可関係の更新を完了した後に、Ｈ−ＣＳＥによりＡＥに返されるリソースアクセス応答は、以下の通りであってよい。
ＨＴＴＰ／１．１ ２００ ＯＫ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｎｅｍ２ｍ−ｒｅｓｏｕｒｃｅ＋ｊｓｏｎ
｛"ｃｏｎｔｅｎｔ"： "ｘｘｘｘｘｘｘｘｘｘｘｘｘ"｝

当該応答のステータスコードは「２００」であり、これは、Ｈ−ＣＳＥがＡＥの現在のリソースアクセス要求を既に認可していることを示す。ＨＴＴＰメッセージボディは、ＡＥにより要求されるリソースコンテンツを含む。本実施形態において、「"ｃｏｎｔｅｎｔ"： "ｘｘｘｘｘｘｘｘｘｘｘｘｘ"」は、リソースコンテンツがＨＴＴＰメッセージボディに含まれ、ＡＥに返されることを示しているに過ぎない。返すときの具体的なフォーマットおよび内容は、アクセス先リソースの種類に従って決まる。これは本発明において限定されるものではない。

本発明の本実施形態においては、Ｍ２ＭシステムにおけるＡＥのようなＭ２Ｍデバイスが、識別子が変更された後にアクセス先リソースにアクセスした場合、リソースサーバが認可関係更新手順をトリガする。Ｍ２Ｍシステムは、アクセスデバイスの検証情報の署名（ｔｏｋｅｎ署名）を検証することによりアクセスデバイスのアイデンティティを判定し、既存の認可関係を更新する。よって、Ｍ２Ｍデバイスはシームレスなリソースアクセスを実現することができ、Ｍ２Ｍシステムのサービス連続性が保証される。

本発明の実施形態において、図２に示す実施形態と同一の発明的構想に属する認可サーバについてさらに説明する。図９に示すように、図９は、本発明の一実施形態に係る認可サーバの概略構造図である。認可サーバは、受信モジュール９０１と、送信モジュール９０２と、取得モジュール９０３と、判定モジュール９０４と、更新モジュール９０５とを備えてよい。

受信モジュール９０１は、アクセスデバイスにより送信された第１認可更新要求を受信するよう構成される。第１認可更新要求は、アクセスデバイスの第１識別子を含む。

送信モジュール９０２は、第１認可更新応答をアクセスデバイスに送信するよう構成される。第１認可更新応答は、署名要求情報を含み、署名要求情報は、検証情報に署名するようアクセスデバイスに命令する。

受信モジュール９０１は、アクセスデバイスにより送信された署名検証要求を受信するようさらに構成される。署名検証要求は、第１識別子と、検証情報と、検証情報の署名とを含み、検証情報の署名は、アクセスデバイスが鍵を用いて検証情報に署名することにより生成される。

取得モジュール９０３は、受信モジュールにより受信された署名検証要求における検証情報に従って、記憶された第１認可関係を取得するよう構成される。

判定モジュール９０４は、受信された署名検証要求における検証情報の署名と第１認可関係に記憶された検証情報の署名とに従って、署名検証要求における検証情報の署名が有効であると判定するよう構成される。

更新モジュール９０５は、第１識別子に従って、第１認可関係を更新するよう構成される。

更新モジュールは、具体的には、第１認可関係における第２識別子を第１識別子に変更するよう構成される。第２識別子は、アクセスデバイスにより用いられていた識別子である。

具体的には、認可サーバは、アクセス先リソースの識別子に対応するリソースへのアクセスデバイスによるアクセスに対して初期認可を行うよう構成された初期認可モジュールをさらに含む。

任意選択的に、検証情報が、アクセスデバイスにより記憶された第２識別子である場合、署名検証要求は、第１識別子の署名をさらに含む。第１識別子の署名は、アクセスデバイスが鍵を用いて第１識別子に署名することにより生成される。更新モジュール９０５は、第１認可関係に記憶された検証情報の署名を第１識別子の署名に変更するようさらに構成される。 初期認可モジュールは、具体的には、リソース作成要求をリソースサーバに送信することであって、リソース作成要求は、予め設定されたアクセス制御ポリシーとアクセス先リソースの識別子とを含み、予め設定されたアクセス制御ポリシーは、第２識別子を含む、ことと、リソースサーバにより送信されたリソース作成応答を受信することであって、リソース作成応答は、リソースサーバがアクセス制御ポリシーリソースを作成することに成功し、アクセス制御ポリシーリソースをアクセス先リソースの識別子に対応するリソースにバインドすることに成功したことを示すものであり、アクセス制御ポリシーリソースは、予め設定されたアクセス制御ポリシーを記録するのに用いられる、ことと、署名要求をアクセスデバイスに送信することであって、署名要求は、第２識別子に署名するようアクセスデバイスに命令するものである、ことと、アクセスデバイスにより送信された署名応答を受信することであって、署名応答は、第２識別子の署名を含む、ことと、第１認可関係を記憶することであって、第１認可関係は、第２識別子と、第２識別子の署名と、アクセス先リソースの識別子との間の対応関係を含む、こととを行うよう構成される。任意選択的に、送信モジュール９０２は、第１認可関係が第１識別子に従って更新された後に、第２認可更新要求をリソースサーバに送信することであって、第２認可更新要求は、第１識別子と、第２識別子と、アクセス先リソースの識別子とを含み、それによりリソースサーバは、第２識別子とアクセス先リソースの識別子とに従って、ローカルで記憶された第２認可関係を取得する、ことと、第２認可関係における第２識別子を第１識別子に更新することとを行うようさらに構成される。

任意選択的に、検証情報が認可クレデンシャルである場合、第１認可更新要求は、認可クレデンシャルをさらに含み、判定モジュール９０４は、第１認可更新応答がアクセスデバイスに送信される前に、認可クレデンシャルに従って、認可クレデンシャルを含む第１認可関係が存在すること、および、第１認可関係においてバインドされているアクセスデバイス識別子が第１識別子ではないことを判定するようさらに構成される。初期認可モジュールは、具体的には、アクセスデバイスの認可要求を受信することであって、認可要求は、第２識別子と、アクセス先リソースの識別子と、ユーザがアクセスデバイスのリソースアクセスに同意するという認証情報とを含む、ことと、認証情報に従って、ユーザがアクセス先リソースの識別子に対応するリソースにアクセスする権限を有すると判定された場合、認可クレデンシャルを生成することと、アクセス先リソースの識別子に対応するリソースが位置するリソースサーバに認可バインド要求を送信することであって、認可バインド要求は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含む、ことと、リソースサーバにより送信された認可バインド応答を受信することであって、認可バインド応答は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とのバインドが成功したことを示す情報を含む、ことと、認可応答をアクセスデバイスに送信することであって、認可応答は、認可クレデンシャルと、アクセス先リソースの識別子と、認可クレデンシャルに署名するよう命令する情報とを含む、ことと、アクセスデバイスにより送信された署名バインド要求を受信することであって、署名バインド要求は、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成される、ことと、第１認可関係を記憶することであって、第１認可関係は、第２識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子との間の対応関係を含む、こととを行うよう構成される。任意選択的に、送信モジュール９０２は、第１認可関係が第１識別子に従って更新された後に、第２認可更新要求をリソースサーバに送信することであって、第２認可更新要求は、第１識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含み、それによりリソースサーバは、認可クレデンシャルとアクセス先リソースの識別子とに従って、第２認可関係を取得する、ことと、第２認可関係における第２識別子を第１識別子に更新することとを行うようさらに構成される。

図１０は、本発明の別の実施形態に係る認可サーバの構造を説明する。認可サーバは、図２、図４、図５、図６Ａおよび図６Ｂ、ならびに図７における上述の実施形態における認可サーバにより実現される認可処理方法を行うよう構成され、少なくとも１つのプロセッサ１００１（例えば、ＣＰＵ）と、少なくとも１つのネットワークインターフェース１００２または別の通信インターフェースと、メモリ１００３と、これらの装置の間の接続および通信を実現するよう構成された少なくとも１つの通信バス１００４とを備える。プロセッサ１００１は、メモリ１００３に記憶されたコンピュータプログラムのような、実行可能プログラムを実行するよう構成されている。メモリ１００３は、高速ランダムアクセスメモリ（ＲＡＭ： Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を含んでよく、または、不揮発性メモリ（ｎｏｎ−ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、例えば、少なくとも１つの磁気ディスクストレージをさらに含んでもよい。少なくとも１つのネットワークインターフェース１００２（これは有線または無線であってよい）は、インターネット、ワイドエリアネットワーク、ローカルエリアネットワーク、またはメトロポリタンエリアネットワーク等を用いて、認可サーバと少なくとも１つの他のネットワーク要素との間の通信接続を実現してよい。

いくつかの実現形態において、メモリ１００３は、プログラム１００３１を記憶する。プログラム１００３１は、プロセッサ１００１により実行されてよい。当該プログラムは、アクセスデバイスにより送信された第１認可更新要求を受信することであって、第１認可更新要求は、アクセスデバイスの第１識別子を含む、ことと、第１認可更新応答をアクセスデバイスに送信することであって、第１認可更新応答は、署名要求情報を含み、署名要求情報は、検証情報に署名するようアクセスデバイスに命令する、ことと、アクセスデバイスにより送信された署名検証要求を受信することであって、署名検証要求は、第１識別子と、検証情報と、検証情報の署名とを含み、検証情報の署名は、アクセスデバイスが鍵を用いて検証情報に署名することにより生成される、ことと、検証情報に従って、記憶された第１認可関係を取得することと、受信された署名検証要求における検証情報の署名と第１認可関係に記憶された検証情報の署名とに従って、署名検証要求における検証情報の署名が有効であると判定することと、第１識別子に従って第１認可関係を更新することとを備える。

本発明の実施形態において、図３に示す実施形態と同一の発明的構想に属するリソースサーバについてさらに説明する。図１１に示すように、図１１は、本発明の一実施形態に係るリソースサーバの概略構造図である。リソースサーバは、受信モジュール１１０１と、判定モジュール１１０２と、送信モジュール１１０３と、更新モジュール１１０４とを備えてよい。

受信モジュール１１０１は、アクセスデバイスにより送信された第１リソースアクセス要求を受信するよう構成される。第１リソースアクセス要求は、アクセスデバイスの第１識別子と、アクセス先リソースの識別子と、認可クレデンシャルとを含む。

判定モジュール１１０２は、認可クレデンシャルに従って、認可クレデンシャルとアクセス先リソースの識別子とを含む第２認可関係が存在すること、および、第２認可関係においてバインドされているアクセスデバイス識別子が第１識別子ではないことを判定するよう構成される。

送信モジュール１１０３は、第１リソースアクセス応答をアクセスデバイスに送信するよう構成される。第１リソースアクセス応答は、署名要求情報を含み、署名要求情報は、認可クレデンシャルに署名するようアクセスデバイスに命令する。

受信モジュール１１０１は、アクセスデバイスにより送信された第２リソースアクセス要求を受信するようさらに構成される。第２リソースアクセス要求は、第１識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成される。

送信モジュール１１０３は、署名データ要求を認可サーバに送信するようさらに構成される。署名データ要求は、認可クレデンシャルを含む。

受信モジュール１１０１は、認可サーバにより送信された署名データ応答を受信するようさらに構成される。署名データ応答は、認可クレデンシャルの署名を含み、認可クレデンシャルの署名は、第１認可関係に記憶され、認可サーバにより認可クレデンシャルに従って取得される。

判定モジュール１１０２は、第２リソースアクセス要求における認可クレデンシャルの署名と、認可サーバにより送信された認可クレデンシャルの署名とに従って、第２リソースアクセス要求における認可クレデンシャルの署名が有効であると判定するようさらに構成される。

更新モジュール１１０４は、第１識別子に従って第２認可関係を更新するよう構成される。

任意選択的に、更新モジュールが、第１識別子に従って第２認可関係を更新するよう構成されることは、具体的には、第２認可関係における第２識別子を第１識別子に変更することである。第２識別子は、アクセスデバイスにより用いられていた識別子である。

送信モジュール１１０３は、第２認可関係が第１識別子に従って更新された後に、第２リソースアクセス応答をアクセスデバイスに送信するようさらに構成される。第２リソースアクセス応答は、アクセス先リソースの識別子に対応するリソースを含む。

具体的には、受信モジュール１１０１は、アクセス先リソースの識別子に対応するリソースへのアクセスデバイスによるアクセスに対して初期認可を認可サーバが行った後に送信された認可バインド要求を受信するようさらに構成される。認可バインド要求は、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子とを含む。リソースサーバは、第２識別子と、認可クレデンシャルと、アクセス先リソースの識別子との間の対応関係を第２認可関係として記憶するよう構成された記憶モジュールをさらに備える。

図１２は、本発明の別の実施形態に係るリソースサーバの構造を説明する。リソースサーバは、図３、図６Ａおよび図６Ｂ、ならびに図８における上述の実施形態におけるリソースサーバにより実現される認可処理方法を行うよう構成され、少なくとも１つのプロセッサ１２０１（例えば、ＣＰＵ）と、少なくとも１つのネットワークインターフェース１２０２または別の通信インターフェースと、メモリ１２０３と、これらの装置の間の接続および通信を実現するよう構成された少なくとも１つの通信バス１２０４とを備える。プロセッサ１２０１は、メモリ１２０３に記憶されたコンピュータプログラムのような、実行可能プログラムを実行するよう構成されている。メモリ１２０３は、高速ランダムアクセスメモリ（ＲＡＭ： Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を含んでよく、または、不揮発性メモリ（ｎｏｎ−ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、例えば、少なくとも１つの磁気ディスクストレージをさらに含んでもよい。少なくとも１つのネットワークインターフェース１２０２（これは有線または無線であってよい）は、インターネット、ワイドエリアネットワーク、ローカルエリアネットワーク、またはメトロポリタンエリアネットワーク等を用いて、リソースサーバと少なくとも１つの他のネットワーク要素との間の通信接続を実現してよい。

いくつかの実現形態において、メモリ１２０３は、プログラム１２０３１を記憶する。プログラム１２０３１は、プロセッサ１２０１により実行されてよい。当該プログラムは、アクセスデバイスにより送信された第１リソースアクセス要求を受信することであって、第１リソースアクセス要求は、アクセスデバイスの第１識別子と、アクセス先リソースの識別子と、認可クレデンシャルとを含む、ことと、認可クレデンシャルに従って、認可クレデンシャルとアクセス先リソースの識別子とを含む第２認可関係が存在すること、および、第２認可関係においてバインドされているアクセスデバイス識別子が第１識別子ではないことを判定することと、第１リソースアクセス応答をアクセスデバイスに送信することであって、第１リソースアクセス応答は、署名要求情報を含み、署名要求情報は、認可クレデンシャルに署名するようアクセスデバイスに命令するものである、ことと、アクセスデバイスにより送信された第２リソースアクセス要求を受信することであって、第２リソースアクセス要求は、第１識別子と、認可クレデンシャルと、認可クレデンシャルの署名と、アクセス先リソースの識別子とを含み、認可クレデンシャルの署名は、アクセスデバイスが鍵を用いて認可クレデンシャルに署名することにより生成される、ことと、署名データ要求を認可サーバに送信することであって、署名データ要求は、認可クレデンシャルを含む、ことと、認可サーバにより送信された署名データ応答を受信することであって、署名データ応答は、認可クレデンシャルの署名を含み、認可クレデンシャルの署名は、第１認可関係に記憶され、認可サーバにより認可クレデンシャルに従って取得される、ことと、第２リソースアクセス要求における認可クレデンシャルの署名と、認可サーバにより送信された認可クレデンシャルの署名とに従って、第２リソースアクセス要求における認可クレデンシャルの署名が有効であると判定することと、第１識別子に従って第２認可関係を更新することとを備える。

上述の方法の実施形態は、説明を平易にするべく、一連の動作として説明されていることに留意されたい。しかしながら、本発明によれば、いくつかの段階は他の順序で行われても、または同時に行われてもよいので、当業者であれば、本発明が説明されている動作の順序に限定されるものではないことは理解されよう。加えて、当業者であれば、本明細書で説明されている全ての実施形態は例示的な実施形態であり、それに関連する動作およびモジュールは、本発明に必須のものでは必ずしもないことも理解されよう。

装置およびシステム内のモジュール間での情報交換および実行プロセスのような内容は、本発明の方法の実施形態と同一の考え方に基づくものである。よって、詳細な内容については、本発明の方法の実施形態における説明を参照されたく、ここでは詳細を再度説明しない。

実施形態における方法のプロセスの全てまたは一部が、関連するハードウェアに命令を行うコンピュータプログラムによって実現されてよいことは、当業者には理解されよう。当該プログラムは、コンピュータ可読記憶媒体に記憶されてよい。当該プログラムが動作する場合、実施形態における方法のプロセスが行われる。上述の記憶媒体は、磁気ディスク、光ディスク、リードオンリーメモリ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ， ＲＯＭ）、またはランダムアクセスメモリ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ， ＲＡＭ）を含んでよい。

本明細書では、具体的な例を用いて本発明の原理および実現方式を説明している。上述の実施形態についての説明は、本発明の方法および考え方を理解する一助とすることを意図したものに過ぎない。加えて、実現方式および適用範囲に対しては、本発明の考え方に従って当業者により変形が施されてよい。よって、本明細書は、本発明を限定するものとして解釈されないこととする。

Claims (15)

1. マシン・ツー・マシン通信における認可処理方法であって、
   認可サーバが、アクセスデバイスにより送信された第１認可更新要求を受信する段階であって、前記第１認可更新要求は、前記アクセスデバイスの第１識別子を含む、段階と、
   前記認可サーバが、第１認可更新応答を前記アクセスデバイスに送信する段階であって、前記第１認可更新応答は、署名要求情報を含み、前記署名要求情報は、検証情報に署名するよう前記アクセスデバイスに命令するのに用いられる、段階と、
   前記認可サーバが、前記アクセスデバイスにより送信された署名検証要求を受信する段階であって、前記署名検証要求は、前記第１識別子と、前記検証情報と、前記検証情報の署名とを含み、前記検証情報の前記署名は、前記アクセスデバイスが鍵を用いて前記検証情報に署名することにより生成される、段階と、
   前記認可サーバが、前記検証情報に従って、記憶された第１認可関係を取得する段階と、
   前記認可サーバが、受信された前記署名検証要求における前記検証情報の前記署名と前記第１認可関係に記憶された検証情報の署名とに従って、前記署名検証要求における前記検証情報の前記署名が有効であると判定する段階と、
   前記認可サーバが、前記第１識別子に従って前記第１認可関係を更新する段階と
   を備える、方法。
2. 前記方法は、アクセスデバイスにより送信された第１認可更新要求を受信する前記段階の前に、
   リソースサーバが、前記アクセスデバイスにより送信されたリソースアクセス要求を受信する段階であって、前記リソースアクセス要求は、前記第１識別子とアクセス先リソースの識別子とを含む、段階と、
   前記リソースサーバが、前記第１識別子と前記アクセス先リソースの前記識別子とに従って、前記アクセスデバイスが前記アクセス先リソースの前記識別子に対応するリソースにアクセスする権限を有さないと判定する段階と、
   前記リソースサーバが、前記アクセス先リソースの前記識別子に対応する前記リソースにアクセスするための前記アクセスデバイスの前記リソースアクセス要求を拒否し、リダイレクトアドレスを含むリソースアクセス応答を前記アクセスデバイスに送信する段階であって、前記リダイレクトアドレスは、前記認可サーバの認可更新ポートアドレスであり、それにより前記アクセスデバイスは、前記認可更新ポートアドレスに従って前記第１認可更新要求を前記認可サーバに送信する、段階と
   をさらに備える、請求項１に記載の方法。
3. 前記第１識別子に従って前記第１認可関係を更新する前記段階は、具体的には、
   前記認可サーバが、前記第１認可関係における第２識別子を前記第１識別子に変更する段階であって、前記第２識別子は、前記アクセスデバイスにより用いられていた識別子である、段階
   である、
   請求項２に記載の方法。
4. 前記方法は、アクセスデバイスにより送信された第１認可更新要求を受信する前記段階の前に、
   前記認可サーバが、前記アクセス先リソースの前記識別子に対応する前記リソースへの前記アクセスデバイスによるアクセスに対して初期認可を行う段階
   をさらに備える、
   請求項３に記載の方法。
5. 前記検証情報は、前記アクセスデバイスにより記憶された前記第２識別子であり、前記署名検証要求は、前記第１識別子の署名をさらに含み、前記第１識別子の前記署名は、前記アクセスデバイスが前記鍵を用いて前記第１識別子に署名することにより生成され、
   前記方法は、前記署名検証要求における前記検証情報の前記署名が有効であると判定する前記段階の後に、
   前記認可サーバが、前記第１認可関係に記憶された前記検証情報の前記署名を前記第１識別子の前記署名に変更する段階
   をさらに備える、
   請求項４に記載の方法。
6. 前記検証情報は、認可クレデンシャルであり、前記第１認可更新要求は、前記認可クレデンシャルをさらに含み、前記検証情報に従って、記憶された第１認可関係を取得する前記段階は、第１認可更新応答を前記アクセスデバイスに送信する前記段階の前に、前記認可サーバが、前記認可クレデンシャルに従って、前記認可クレデンシャルを含む前記第１認可関係が存在することを判定する段階を含む、請求項４に記載の方法。
7. 前記方法は、前記第１識別子に従って前記第１認可関係を更新する前記段階の後に、
   前記認可サーバが、第２認可更新要求を前記リソースサーバに送信する段階であって、前記第２認可更新要求は、前記第１識別子と、前記認可クレデンシャルと、前記アクセス先リソースの前記識別子とを含む、段階
   をさらに備える、
   請求項６に記載の方法。
8. マシン・ツー・マシン通信における認可処理方法であって、
   アクセスデバイスにより送信された第１リソースアクセス要求を受信する段階であって、前記第１リソースアクセス要求は、前記アクセスデバイスの第１識別子と、アクセス先リソースの識別子と、認可クレデンシャルとを含む、段階と、
   前記認可クレデンシャルに従って、前記認可クレデンシャルと前記アクセス先リソースの前記識別子とを含む第２認可関係が存在すること、および、前記第２認可関係においてバインドされているアクセスデバイス識別子が前記第１識別子ではないことを判定する段階と、
   第１リソースアクセス応答を前記アクセスデバイスに送信する段階であって、前記第１リソースアクセス応答は、署名要求情報を含み、前記署名要求情報は、前記認可クレデンシャルに署名するよう前記アクセスデバイスに命令するものである、段階と、
   前記アクセスデバイスにより送信された第２リソースアクセス要求を受信する段階であって、前記第２リソースアクセス要求は、前記第１識別子と、前記認可クレデンシャルと、前記認可クレデンシャルの署名と、前記アクセス先リソースの前記識別子とを含み、前記認可クレデンシャルの前記署名は、前記アクセスデバイスが鍵を用いて前記認可クレデンシャルに署名することにより生成される、段階と、
   署名データ要求を認可サーバに送信する段階であって、前記署名データ要求は、前記認可クレデンシャルを含む、段階と、
   前記認可サーバにより送信された署名データ応答を受信する段階であって、前記署名データ応答は、認可クレデンシャルの署名を含み、前記認可クレデンシャルの前記署名は、第１認可関係に記憶され、前記認可サーバにより前記認可クレデンシャルに従って取得される、段階と、
   前記第２リソースアクセス要求における前記認可クレデンシャルの前記署名と、前記認可サーバにより送信された前記認可クレデンシャルの前記署名とに従って、前記第２リソースアクセス要求における前記認可クレデンシャルの前記署名が有効であると判定する段階と、
   前記第１識別子に従って前記第２認可関係を更新する段階と
   を備える、方法。
9. 前記方法は、前記第１識別子に従って前記第２認可関係を更新する前記段階の後に、
   第２リソースアクセス応答を前記アクセスデバイスに送信する段階であって、前記第２リソースアクセス応答は、前記アクセス先リソースの前記識別子に対応するリソースを含む、段階
   をさらに備える、
   請求項８に記載の方法。
10. 前記第１識別子に従って前記第２認可関係を更新する前記段階は、具体的には、
    前記第２認可関係における第２識別子を前記第１識別子に変更する段階であって、前記第２識別子は、前記アクセスデバイスにより用いられていた識別子である、段階
    である、
    請求項８または９に記載の方法。
11. マシン・ツー・マシン通信における認可サーバであって、
    アクセスデバイスにより送信された第１認可更新要求を受信する受信モジュールであって、前記第１認可更新要求は、前記アクセスデバイスの第１識別子を含む、受信モジュールと、
    第１認可更新応答を前記アクセスデバイスに送信する送信モジュールであって、前記第１認可更新応答は、署名要求情報を含み、前記署名要求情報は、検証情報に署名するよう前記アクセスデバイスに命令するのに用いられる、送信モジュールと
    を備え、
    前記受信モジュールは、さらに、前記アクセスデバイスにより送信された署名検証要求を受信し、前記署名検証要求は、前記第１識別子と、前記検証情報と、前記検証情報の署名とを含み、前記検証情報の前記署名は、前記アクセスデバイスが鍵を用いて前記検証情報に署名することにより生成され、
    前記認可サーバは、
    前記受信モジュールにより受信された前記署名検証要求における前記検証情報に従って、記憶された第１認可関係を取得する取得モジュールと、
    受信された前記署名検証要求における前記検証情報の前記署名と前記第１認可関係に記憶された検証情報の署名とに従って、前記署名検証要求における前記検証情報の前記署名が有効であると判定する判定モジュールと、
    前記第１識別子に従って前記第１認可関係を更新する更新モジュールと
    をさらに備える、認可サーバ。
12. 前記更新モジュールは、具体的には、
    前記第１認可関係における第２識別子を前記第１識別子に変更し、前記第２識別子は、前記アクセスデバイスにより用いられていた識別子である、
    請求項１１に記載の認可サーバ。
13. 前記認可サーバは、
    アクセス先リソースの識別子に対応するリソースへの前記アクセスデバイスによるアクセスに対して初期認可を行う初期認可モジュール
    をさらに備える、
    請求項１１または１２に記載の認可サーバ。
14. マシン・ツー・マシン通信におけるリソースサーバであって、
    アクセスデバイスにより送信された第１リソースアクセス要求を受信する受信モジュールであって、前記第１リソースアクセス要求は、前記アクセスデバイスの第１識別子と、アクセス先リソースの識別子と、認可クレデンシャルとを含む、受信モジュールと、
    前記認可クレデンシャルに従って、前記認可クレデンシャルと前記アクセス先リソースの前記識別子とを含む第２認可関係が存在すること、および、前記第２認可関係においてバインドされているアクセスデバイス識別子が前記第１識別子ではないことを判定する判定モジュールと、
    第１リソースアクセス応答を前記アクセスデバイスに送信する送信モジュールであって、前記第１リソースアクセス応答は、署名要求情報を含み、前記署名要求情報は、前記認可クレデンシャルに署名するよう前記アクセスデバイスに命令するものである、送信モジュールと
    を備え、
    前記受信モジュールは、さらに、前記アクセスデバイスにより送信された第２リソースアクセス要求を受信し、前記第２リソースアクセス要求は、前記第１識別子と、前記認可クレデンシャルと、前記認可クレデンシャルの署名と、前記アクセス先リソースの前記識別子とを含み、前記認可クレデンシャルの前記署名は、前記アクセスデバイスが鍵を用いて前記認可クレデンシャルに署名することにより生成され、
    前記送信モジュールは、さらに、署名データ要求を認可サーバに送信し、前記署名データ要求は、前記認可クレデンシャルを含み、
    前記受信モジュールは、さらに、前記認可サーバにより送信された署名データ応答を受信し、前記署名データ応答は、認可クレデンシャルの署名を含み、前記認可クレデンシャルの前記署名は、第１認可関係に記憶され、前記認可サーバにより前記認可クレデンシャルに従って取得され、
    前記判定モジュールは、さらに、前記第２リソースアクセス要求における前記認可クレデンシャルの前記署名と、前記認可サーバにより送信された前記認可クレデンシャルの前記署名とに従って、前記第２リソースアクセス要求における前記認可クレデンシャルの前記署名が有効であると判定し、
    前記リソースサーバは、
    前記第１識別子に従って前記第２認可関係を更新する更新モジュール
    をさらに備える、リソースサーバ。
15. 前記送信モジュールは、さらに、前記第２認可関係が前記第１識別子に従って更新された後に、第２リソースアクセス応答を前記アクセスデバイスに送信し、前記第２リソースアクセス応答は、前記アクセス先リソースの前記識別子に対応するリソースを含む、
    請求項１４に記載のリソースサーバ。

Images