JP7269364B2 - デバイスの通信方法、デバイス及び記憶媒体 - Google Patents

Description

本発明は、無線通信技術分野に関し、特にデバイスの通信方法、デバイス及び記憶媒体に関する。

関連技術において、同一のローカルネットワークになく、且つ同一のクラウドプラットフォームに接続された第１のデバイスと第２のデバイスは、クラウドプラットフォームを介して通信することができる。しかし、同一のクラウドプラットフォームに接続されていない二つのデバイスの間の通信をどのように実現させるかについては、現在には有効な解決手段がない。

上記の課題を解決するために、本発明の実施例は、デバイスの通信方法、デバイス及び記憶媒体を提供する。

第１の態様によれば、本発明の実施例は、デバイスの通信方法を提供し、この方法は、第１のクラウドプラットフォームが、第２のクラウドプラットフォームから、前記第１のクラウドプラットフォームが前記第２のクラウドプラットフォームにおける第２のデバイスの第２のリソースリンクにアクセスするための第１のアクセストークンを取得するステップと、前記第１のクラウドプラットフォームが、前記第１のアクセストークンに基づいて、前記第２のリソースリンクを取得するステップと、前記第１のクラウドプラットフォームが、前記第２のリソースリンクに基づいて、前記第１のクラウドプラットフォームにおける前記第２のデバイスの第１のリソースリンクを決定するステップを含み、前記第２のデバイスは、前記第２のクラウドプラットフォームに接続され、前記第１のリソースリンクは、前記第１のクラウドプラットフォームに接続された第１のデバイスと前記第２デバイスとの通信に使用される。

第２の態様によれば、本発明の実施例は、デバイスの通信方法を提供し、この方法は、第２のクラウドプラットフォームが、第１のクラウドプラットフォームに、前記第１のクラウドプラットフォームが前記第２のクラウドプラットフォームにおける第２のデバイスの第２のリソースリンクにアクセスするための第１のアクセストークンを送信するステップを含み、前記第２のリソースリンクは第１のデバイスと第２のデバイスとの通信に使用され、前記第１のデバイスは前記第１のクラウドプラットフォームに接続され、前記第２のデバイスは前記第２のクラウドプラットフォームに接続される。

第３の態様によれば、本発明の実施例は、第１のクラウドプラットフォームを提供し、前記第１のクラウドプラットフォームは、第２のクラウドプラットフォームから、前記第１のクラウドプラットフォームが前記第２のクラウドプラットフォームにおける第２のデバイスの第２のリソースリンクにアクセスするための第１のアクセストークンを取得するように構成される第１の送受信ユニットと、
前記第１のアクセストークンに基づいて、前記第２のリソースリンクを取得するように構成される第２の送受信ユニットと、
前記第２のリソースリンクに基づいて、前記第１のクラウドプラットフォームにおける前記第２のデバイスの第１のリソースリンクを決定するように構成される第１の処理ユニットと、を備え、
前記第２のデバイスは、前記第２のクラウドプラットフォームに接続され、
前記第１のリソースリンクは、前記第１のクラウドプラットフォームに接続された第１のデバイスと前記第２のデバイスとの通信に使用される。

第４の態様によれば、本発明の実施例は、第２のクラウドプラットフォームを提供し、前記第２のクラウドプラットフォームは、第１のクラウドプラットフォームに、前記第１のクラウドプラットフォームが前記第２のクラウドプラットフォームにおける第２のデバイスの第２のリソースリンクにアクセスするための第１のアクセストークンを送信するように構成される第４の送受信ユニットを備え、前記第２のリソースリンクは、第１のデバイスと第２のデバイスとの通信に使用され、
前記第１のデバイスは前記第１のクラウドプラットフォームに接続され、前記第２のデバイスは前記第２のクラウドプラットフォームに接続される。

第５の態様によれば、本発明の実施例は、プロセッサと、プロセッサで実行可能なコンピュータプログラムを記憶するためのメモリと、を備える第１のクラウドプラットフォームを提供し、前記プロセッサが前記コンピュータプログラムを実行する場合、上記の端末デバイスにより実行されたデバイスの通信方法のステップが実行される。

第６の態様によれば、本発明の実施例は、プロセッサと、プロセッサで実行可能なコンピュータプログラムを記憶するためのメモリと、を備える第２のクラウドプラットフォームを提供し、前記プロセッサが前記コンピュータプログラムを実行する場合、上記のネットワークデバイスにより実行されたデバイスの通信方法のステップが実行される。

第７の態様によれば、本発明の実施例は、実行可能なプログラムが記憶されている記憶媒体を提供し、前記実行可能なプログラムがプロセッサにより実行されるときに、上記の端末デバイスにより実行されたデバイスの通信方法が実現される。

第８の態様によれば、本発明の実施例は、実行可能なプログラムが記憶されている記憶媒体を提供し、前記実行可能なプログラムがプロセッサにより実行されるときに、上記のネットワークデバイスにより実行されたデバイスの通信方法が実現される。

本発明の実施例により提供されるデバイスの通信方法は、第１のクラウドプラットフォームが、第２のクラウドプラットフォームから第１のアクセストークンを取得し、前記第１のアクセストークンに基づいて、前記第２のリソースリンクを取得するステップと、前記第１のクラウドプラットフォームに接続された第１のデバイスが第１のリソースリンクに基づいて第２のデバイスと通信するように、前記第２のリソースリンクに基づいて、前記第２のクラウドプラットフォームに接続された前記第２のデバイスが前記第１のクラウドプラットフォームにおける前記第１のリソースリンクを決定するステップと、を含み、それにより、異なるクラウドプラットフォームに接続された二つのデバイスとの間の通信が実現された。

本発明のモノのインターネット( ＩｏＴ：Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ)におけるクライアントとサービス側とのインタラクション方式の模式図である。 本発明のＯＣＦクラウドプラットフォームの配置アーキテクチャの模式図である。 本発明の制御側とＯＣＦデバイスがクラウドプラットフォームを介して通信される模式図である。 本発明の実施例に係る通信システムの構成構造の模式図である。 本発明の実施例に係るデバイスの通信方法の一つの選択可能な処理フローの模式図である。 本発明の実施例に係る第１のデバイスと第２のデバイスとの通信の処理フローの第１の模式図である。 本発明の実施例に係る第１のデバイスと第２のデバイスとの通信の処理フローの第２の模式図である。 本発明の実施例に係る第１のクラウドプラットフォームの構成構造の模式図である。 本発明の実施例に係る第２のクラウドプラットフォームの構成構造の模式図である。 本発明の実施例に係るクラウドプラットフォームのハードウェアの構成構造の模式図である。

本発明の実施例の特徴及び技術的内容をより詳細に理解するために、以下には、図面を参照して本発明の実施例の実現を詳細に説明し、添付図面は単に説明するためのものであり、本発明の実施例を限定するものではない。

本発明の実施例により提供されるデバイスの通信方法を詳細に説明する前に、まずは、モノのインターネットの関連情報を簡単に説明する。

オープンコネクティビティーファンデーション（Ｏｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ、ＯＣＦ）は、モノのインターネットのアプリケーション層の技術の標準化団体であり、ＯＣＦは、モノのインターネットデバイスの間で相互接続と相互通信が実現されるように、Ｒｅｓｔｆｕｌサービスフレームワークを策定する。ＯＣＦ Ｒｅｓｔｆｕｌサービスフレームワークにおいて、モノのインターネットデバイス、デバイスの機能サービス及びデバイスの状態等の情報がリソースによって表現される。リソースを提供するエンティティは、ＯＣＦサービス側（以下、単に「サービス側」と呼ぶ）であり、リソースにアクセスするエンティティは、ＯＣＦクライアント（以下、単に「クライアント」と呼ぶ）である。例えば、室内環境状態のデータを取得する制御端末はクライアントであり、室内環境状態のデータを監視するセンサデバイスはサービス側であり、クライアントとサービス側との業務インタラクションは、リソースに対する作成、読み取り、更新、削除又は通知等のリソース操作により実現される。モノのインターネットにおけるクライアントとサービス側とのインタラクション方式の模式図は、図１に示すように、クライアントは、サービス側に要求メッセージを送信し、サービス側にリソースを操作するように要求し、サービス側は、リソース操作を実行し、クライアントにリソースの説明を含む要求応答を返信する。具体的に実施するときに、クライアントがサービス側に要求する操作のオブジェクトはリソースのユニフォームリソース識別子（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ、ＵＲＩ）であり、要求にリソース操作方法が運ばれる。図１に示すように、サービス側は、環境温度リソースのＵＲＩが「/ｅｎｖｉｒｏｎｍｅｎｔＴｅｍｐｅｒａｔｕｒｅ」である環境温度リソースを有り、リソース操作方法は、リソース更新方法ＰＯＳＴである。リソースの説明は、リソースＵＲＩ、リソースタイプ、リソースインターフェース及びリソースの機能属性のうちの少なくとも一つを含む。ここで、
１、リソースＵＲＩ：ＯＣＦリソースの説明では「ｈｒｅｆ」により示され、リソースＵＲＩがＯＣＦサービス側のリソースのアドレスを提供し、「ｈｒｅｆ」の値が具体的なリソースＵＲＩであり、ＯＣＦクライアントがリソースＵＲＩによりＯＣＦサービス側のリソースにアクセスし、図１における環境温度リソースのリソースＵＲＩは「/ｅｎｖｉｒｏｎｍｅｎｔＴｅｍｐｅｒａｔｕｒｅ」である。

２、リソースタイプ：ＯＣＦリソースの説明では「ｒｔ」により示され、リソースタイプがリソースのタイプを示し、図１におけるリソースタイプ「ｒｔ」は温度リソースタイプを示す「ｏｉｃ.ｒ.ｔｅｍｐｅｒａｔｕｒｅ」である。

３、リソースインターフェース：ＯＣＦリソースの説明では「ｉｆ」 により示され、リソースインターフェースがリソースの閲覧及びリソースサポートに対する応答を提供し、図１におけるリソースインターフェース「ｉｆ」はコントローラインターフェースを示す「ｏｉｃ.ｉｆ.a」である。

４、リソース属性：ＯＣＦリソースの説明でリソースの属性情報が記述され、図１における「ｔａｒｇｅｔＴｅｍｐｅｒａｔｕｒｅ」が温度リソースのターゲット温度属性を示し、「ｃｕｒｒｅｎｔＴｅｍｐｅｒａｔｕｒｅ」が温度リソースの現在温度属性を示し、「ｔｅｍｐｅｒａｔｕｒｅＲａｎｇｅ」が温度リソースの温度範囲属性を示す。

ＯＣＦは、すべてのＯＣＦデバイスがサポートしなければならないリソース発見リソースを定義し、リソース発見リソースは「/ｏｉｃ/ｒｅｓ」により示され、リソース発見リソースは、ＯＣＦデバイス及びリソースの発見のためにデバイスリソース発見の機能を提供し、リソース発見リソースのＵＲＩが「/ｏｉｃ/ｒｅｓ」に固定される。

リソースの間の関連関係を示すために、ＯＣＦは、リソースリンク（Ｌｉｎｋｓ）を定義し、ＯＣＦサービス側は、ＯＣＦクライアントが自身のリソースを発見しやすいように、リソースリンクの形式で自身が所有するリソースを提供してもよい。Ｌｉｎｋｓの内容は、以下のように、
{
"anchor": "ocf://dc70373c-1e8d-4fb3-962e-017eaa863989",
"href": "/myLightSwitch",
"rt": ["oic.r.switch.binary"],
"if": ["oic.if.a", "oic.if.baseline"],
"eps": [{"ep": "coaps://[2001:db8:b::c2e5]:22222"}]
}

リソースリンクの内容は、下記の少なくとも一つを含む。
ａｎｃｈｏｒ: コンテキストＵＲＩであり、Ｌｉｎｋｓを含む所有者リソースのＵＲＩを示す。
ｈｒｅｆ: ターゲットＵＲＩ、即ち、Ｌｉｎｋｓが引用するターゲットリソースのＵＲＩである。
ｒｔ: ターゲットリソースのリソースタイプ識別子である。
ｉｆ: ターゲットリソースによりサポートされるインターフェースである。
ｅｐｓ: ターゲットリソースにアクセスできるエンドポイント（ターゲットアドレスおよびポート番号）である。

ＯＣＦ標準プロトコルがトランスポート層においてＣｏＡＰプロトコルを採用してＯＣＦメッセージを運ぶので、各ＯＣＦサービス側はエンドポイントを有する必要であり、各ＯＣＦサービス側はメッセージを送受信するために少なくとも一つのエンドポイントに関連付けられなければならない。ＯＣＦクライアントはエンドポイントを介してＯＣＦサービス側のターゲットリソースにアクセスできる。Ｌｉｎｋｓのパラメータにおいて、ターゲットリソースのエンドポイントが「ｅｐｓ」配列で表示され、具体的なエンドポイントが「ｅｐ」 で示し、即ち、「ｅｐｓ」パラメータのうちの「ｅｐ」の値によりターゲットリソースにアクセスできる。例えば、上記のソースリンクＬｉｎｋｓの例において、クライアントは、メッセージエンドポイント「ｃｏａｐｓ://[２００１:ｄｂ８:ｂ:: ｃ２ｅ５]:２２２２２」によりターゲットリソース「/ｍｙＬｉｇｈｔＳｗｉｔｃｈ」にアクセスできる。

ＯＣＦサービス側とＯＣＦクライアントが同一のローカルネットワーク中になかった場合、ＯＣＦサービス側とＯＣＦクライアントがクラウドプラットフォームを介して通信される。ＯＣＦクラウドプラットフォームの配置アーキテクチャは、図２に示すように、クラウドプラットフォームは、クラウドインターフェース、認可サーバ、リソースディレクトリという三つのエンティティを含み、ここで、クラウドインターフェースは、サービス側とクライアントとのアクセス管理、及びサービス側とクライアントとのリモート通信のメッセージルーティングに使用される。認可サーバは、サービス側とクライアントの登録、サービス側とクライアントのアクセストークンの検証に使用される。リソースディレクトリは、サービス側のＬｉｎｋｓを公開するために使用され、クライアントは、リソースディレクトリを検索することにより、ターゲットデバイスのリソースを取得できる。

クラウドプラットフォームの実装においてリソースディレクトリ機能が定義され、サービス側がクラウドプラットフォームに登録された後、サービス側は、予め定義されたリソース配信プロセスに従って、自身により運ばれるリソースをクラウドプラットフォームのリソースディレクトリに配信するべきである。サービス側とクラウドプラットフォームとの間にはＴＬＳ持続的接続を維持し、クラウドプラットフォームは、当該ＴＬＳ持続的接続を介してサービス側とクライアントとの間でメッセージのルーティングを行い、本発明の実施例において、クライアントが制御側と呼ばれてもよく、サービス側がＯＣＦデバイスと呼ばれてもよい。

制御側とＯＣＦデバイスがクラウドプラットフォームを介して通信される模式図は、図３に示すように、以下のステップを含む。

ステップ１、制御側が、ＯＣＦデバイスをアクティブにし、ＯＣＦデバイスのデバイス識別子を生成する。

ステップ２、制御側がクラウドプラットフォームに登録し、クラウドプラットフォームが制御側のためにユーザ識別子とアクセストークンを生成する。

ステップ３、制御側は、クラウドプラットフォームにアクセスするようにＯＣＦデバイスを構成する。

ステップ４、ＯＣＦデバイスは、クラウドプラットフォームにアクセスし、クラウドプラットフォームとの持続的接続を維持する。

ステップ５、ＯＣＦデバイスは、それ自体によって運ばれるリソースリンク（Ｌｉｎｋｓ）をクラウドプラットフォームのリソースディレクトリに配信し、リソースディレクトリは、ＯＣＦデバイスのリソース配信を受信し、デバイスにより配信されたＬｉｎｋｓを/ｏｉｃ/ｒｅｓリソースに追加する。

ステップ６、制御側はクラウドプラットフォームの/ｏｉｃ/ｒｅｓにリソース発見要求を送信し、クラウドプラットフォームはリソース発見応答を行い、応答メッセージにおいてリソースディレクトリに配信されたデバイスＬｉｎｋｓが返信され、ＬｉｎｋｓにはＯＣＦデバイスのリソース情報が含まれる。

ステップ７、制御側はＯＣＦデバイスのターゲットリソースにリソース操作要求を送信する。

ステップ８、クラウドプラットフォームは、ＯＣＦデバイスにリソース操作要求を転送することにより、制御側とＯＣＦデバイスとの通信を実現する。

関連技術において、同一のローカルネットワークに属さない制御側とＯＣＦデバイスは、クラウドプラットフォームを介して通信することができる。しかし、制御側とＯＣＦデバイスは、同一のクラウドプラットフォームに接続しなければリモート通信を実現することができず、即ち、異なるクラウドプラットフォームに接続されたデバイスとの間には通信を行うことができない。本発明の実施例の通信システムの構成構造の模式図は、図４に示すように、デバイスは、第１の制御側と、第１のＯＣＦデバイスと、第２の制御側と、第２のＯＣＦデバイスとを備え、第１の制御側は、第１のクラウドプラットフォームを介して第１のＯＣＦデバイスと通信することができ、第２の制御側は、第２のクラウドプラットフォームを介して第２のＯＣＦデバイスと通信することができる。しかし、第１の制御側は、第２のＯＣＦデバイスと通信することができず、第２の制御側も第１のＯＣＦデバイスと通信することができないので、デバイスの間には相互運用性がなくなり、ユーザー体験に影響を与える。

上記の問題に基づき、本発明はデバイスの通信方法を提供し、本出願の実施例のデバイスの通信方法は、例えば、モノのインターネットシステム、グローバルモバイル通信（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｏｆ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ，ＧＳＭ）システム、符号分割多元接続（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ，ＣＤＭＡ）システム、広帯域符号分割多元接続（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ，ＷＣＤＭＡ）システム、汎用パケット無線サービス（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ，ＧＰＲＳ）、ロングタームエボリューション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ，ＬＴＥ）システム、ＬＴＥ周波数分割複信（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ，ＦＤＤ）システム、ＬＴＥ時分割複信（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ，ＴＤＤ）、ユニバーサル移動体通信システム（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ，ＵＭＴＳ）、グローバル相互接続マイクロ波アクセス（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ，ＷｉＭＡＸ）通信システム又は５Ｇシステム等のような様々な通信システムに適用されてもよい。

図５に示すように、本発明の実施例により提供されるデバイスの通信方法の一つの選択可能な処理フローは、以下のステップを含む。

ステップＳ２０１、第１のクラウドプラットフォームは、第２のクラウドプラットフォームから第１のアクセストークンを取得する。

本発明の実施例において、第１のクラウドプラットフォームが第１のデバイスに接続され、即ち、第１のクラウドプラットフォームが第１のデバイスと通信することができ、第２のクラウドプラットフォームが第２のデバイスに接続され、即ち、第２のクラウドプラットフォームが第２のデバイスと通信することができる。ステップＳ２０１が実行された前に、第２の制御側は、第２のデバイスをアクティブにし、第２のデバイスのデバイス識別子（Ｄｅｖｉｃｅ ＩＤ）を生成し、第２の制御側は第２のクラウドプラットフォームに制御側の登録を行い、第２のクラウドプラットフォームは第２の制御側にユーザ識別子及び第２の制御側のアクセストークンを返信し、第２の制御側は、第２のデバイスが第２のクラウドプラットフォームにアクセスするための構成プロセスを開始する。第２のクラウドプラットフォームは第２の制御側のアクセストークンと、第２の制御側のユーザ識別子および第２のデバイスのＤｅｖｉｃｅ ＩＤとの間の関連関係を維持する。第２のデバイスはＬｉｎｋｓを第２のクラウドプラットフォームのリソースディレクトリに配信する。幾つかのシナリオにおいて、ユーザは、第１のデバイス（第１の制御側）がユーザアカウントの関連付けを行うようにトリガーし、第１のデバイス（第１の制御側）は、第１のクラウドプラットフォームに、第２のクラウドプラットフォームからのユーザ認可を要求するように指示する。

幾つかの実施例において、第１のクラウドプラットフォームは以下のステップを通じて、第２のクラウドプラットフォームから第１のアクセストークンを取得することができる。

ステップａ１、第１のクラウドプラットフォームが第２のクラウドプラットフォームにユーザ認可リソースに対する第１の更新要求メッセージを送信する。

ここで、前記第１の更新要求メッセージは、第１のクラウドプラットフォームが第２のクラウドプラットフォームにユーザ認可を要求するために使用され、前記第１の更新要求メッセージは、第１のクラウドプラットフォームのクライアント識別子及びターゲットユーザ認可リソースのＵＲＩを含む。第１の更新要求メッセージのターゲットＵＲＩは第２のクラウドプラットフォームのユーザ認可リソースのＵＲＩである。第１のクラウドプラットフォームが第２のクラウドプラットフォームのユーザ認可リソースＵＲＩに第１の更新要求メッセージを送信すると理解されてもよい。前記第１の更新要求メッセージによって更新が要求されるリソース情報には、第１のクラウドプラットフォームのクライアント識別子が含まれる。選択的に、第１のクラウドプラットフォームのクライアント識別子およびターゲットユーザ認可リソースのＵＲＩに加えて、前記第１の更新要求メッセージには、認可された権限範囲がさらに含まれる可能があり、例えば、認可された権限範囲には、第２のクラウドプラットフォームにアクセスされたデバイスリソースに対する読み取り及び書き込み操作、又は、第２のクラウドプラットフォームにアクセスされたデバイスリソースに対する読み取り専用操作などが含まれる。

第２のクラウドプラットフォームは、第１の更新要求メッセージを受信した後、ユーザを認可インタラクティブページにリダイレクトし、許可するか否かをユーザに問い合わせる。ユーザが第２のクラウドプラットフォームのアカウントにログインしていなかった場合、許可ユーザは第２のクラウドプラットフォームのアカウントにログインする必要がある。ユーザが許可すれば、第２のクラウドプラットフォームは第１のクラウドプラットフォームのクライアント識別子を検証し、検証に成功した後、第２のクラウドプラットフォームは第１のクラウドプラットフォームに第１の更新要求応答メッセージを送信し、第１のクラウドプラットフォームはステップｂ１を実行する。

ステップｂ１、第１のクラウドプラットフォームは、第２のクラウドプラットフォームにより送信された第１の更新要求応答メッセージを受信する。

ここで、前記第１の更新要求応答メッセージには認可コードが運ばれ、前記認可コードは、第１のクラウドプラットフォームが、アクセストークンを取得する要求を第２のクラウドプラットフォームに送信するときに、第２のクラウドプラットフォームが、前記認可コードを利用してアクセストークンを取得する要求のソースの信頼性を検証するために使用される。

ステップc１、第１のクラウドプラットフォームが、第２のクラウドプラットフォームにアクセストークンリソースに対する第２の更新要求メッセージを送信する。

ここで、前記第２の更新要求メッセージは、前記第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードを含む。前記第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードは、前記第２の更新要求メッセージによって更新が要求されるリソース情報であり、前記第２の更新要求メッセージのターゲットＵＲＩは、第２のクラウドプラットフォームのアクセストークンリソースのＵＲＩである。

第２のクラウドプラットフォームは、第２の更新要求メッセージを受信した後、第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードを検証し、検証に成功した後、第２のクラウドプラットフォームが第１のクラウドプラットフォームに第２の更新要求応答メッセージを送信し、第１のクラウドプラットフォームはステップｄ１を実行する。

ステップｄ１、第１のクラウドプラットフォームは、第２の更新要求応答メッセージを受信する。

ここで、前記第２の更新要求応答メッセージには第１のアクセストークンが運ばれ、前記第１のアクセストークンは、第１のクラウドプラットフォームが第２のクラウドプラットフォームのリソースディレクトリのＬｉｎｋｓをアクセスするためのアクセストークンである。前記第１のアクセストークンは第２のクラウドプラットフォームにより生成され、前記第２のクラウドプラットフォームは前記第１のアクセストークンと第２の制御側のユーザ識別子との関連関係を確立する。ここで、前記第２の制御側が第２のクラウドプラットフォームに接続されることにより、第２の制御側は第２のクラウドプラットフォームと通信することができる。第１のアクセストークンは、ステップＳ２０１が実行される前に、第２の制御側が第２のクラウドプラットフォームに制御側の登録を行うときに、第２のクラウドプラットフォームから第２の制御側に返信した第２の制御側のアクセストークンであり、又は、前記第１のアクセストークンは新たなアクセストークンであってもよい。第１のアクセストークンが新たなアクセストークンである場合、第２のクラウドプラットフォームは、第１のアクセストークンと、第２の制御側のユーザ識別子及び第２のデバイスのデバイス識別子との間の関連関係を確立する必要がある。具体的に実施するときに、第２のクラウドプラットフォームは、第２の制御側のユーザ識別子に応じて第１のアクセストークンを生成してもよく、他の要因に応じて第１のアクセストークンを生成してもよい。本発明の実施例は、第２のクラウドプラットフォームにより第１のアクセストークンを生成する方法限定しない。

他の幾つかの実施例において、第１のクラウドプラットフォームは、以下のステップを通じて、第２のクラウドプラットフォームから第１のアクセストークンを取得することができる。

ステップａ２、第１のクラウドプラットフォームは、第２のクラウドプラットフォームのユーザ認可アドレスに基づき、第１のアクセス要求メッセージを送信する。

第１のクラウドプラットフォームは、第２のクラウドプラットフォームのユーザ認可アドレスにアクセスすることにより、第１のアクセス要求メッセージを送信すると理解され得る。前記第１のアクセス要求メッセージは、第１のクラウドプラットフォームが第２のクラウドプラットフォームにユーザ認可を要求するために使用され、前記第１のアクセス要求メッセージには、第１のクラウドプラットフォームのクライアント識別子及びコールバックアドレスが含まれる。選択的に、第１のクラウドプラットフォームのクライアント識別子およびコールバックアドレスに加え、前記第１のアクセス要求メッセージには、認可された権限範囲も含まれる可能性があり、例えば、認可された権限範囲には、第２のクラウドプラットフォームにアクセスされたデバイスリソースに対する読み取り及び書き込み操作、又は、第２のクラウドプラットフォームにアクセスされたデバイスリソースに対する読み取り専用操作などが含まれる。

第２のクラウドプラットフォームは、第１のアクセス要求メッセージを受信した後、ユーザを認可インタラクティブページにリダイレクトし、許可するか否かをユーザに問い合わせる。ユーザが第２のクラウドプラットフォームのアカウントにログインしていなかった場合、許可ユーザは第２のクラウドプラットフォームのアカウントにログインする必要がある。ユーザが許可すれば、第２のクラウドプラットフォームは第１のクラウドプラットフォームのクライアント識別子を検証し、検証に成功した後、第２のクラウドプラットフォームはコールバックアドレスに認可コードを送信し、第１のクラウドプラットフォームはステップｂ２を実行する。ここでは、前記認可コードは、第１のクラウドプラットフォームが、アクセストークンを取得する要求を第２のクラウドプラットフォームに送信するときに、第２のクラウドプラットフォームが認可コードを利用してアクセストークンを取得する要求のソースの信頼性を検証するために使用される。

ステップｂ２、第１のクラウドプラットフォームは、第２のクラウドプラットフォームにより送信された認可コードを受信する。

ステップc２、第１のクラウドプラットフォームは、第２のクラウドプラットフォームのアクセストークン取得アドレスに基づき、第２のアクセス要求メッセージを送信する。

第１のクラウドプラットフォームは、第２のクラウドプラットフォームのトークン取得アドレスにアクセスすることにより、第２のアクセス要求メッセージを送信すると理解され得る。ここで、前記第２のアクセス要求メッセージには、前記第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードが含まれる。

第２のクラウドプラットフォームは、第２のアクセス要求メッセージを受信した後、第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードを検証し、検証に成功した後、第２のクラウドプラットフォームはコールバックアドレスに第１のアクセストークンを送信し、第１のクラウドプラットフォームはステップｄ２を実行する。

ステップｄ２、第１のクラウドプラットフォームは、第２のクラウドプラットフォームにより送信された第１のアクセストークンを受信する。

前記第１のアクセストークンは、第１のクラウドプラットフォームが第２のクラウドプラットフォームのリソースディレクトリのＬｉｎｋｓをアクセスするためのアクセストークンである。前記第１のアクセストークンは第２のクラウドプラットフォームにより生成され、前記第２のクラウドプラットフォームは前記第１のアクセストークンと第２の制御側のユーザ識別子との関連関係を確立する。ここで、前記第２の制御側が第２のクラウドプラットフォームに接続されているので、第２の制御側は第２のクラウドプラットフォームと通信することができる。第１のアクセストークンは、ステップＳ２０１が実行される前に、第２の制御側が第２のクラウドプラットフォームに制御側の登録を行うときに、第２のクラウドプラットフォームが第２の制御側に返信した第２の制御側のアクセストークンであり、又は、前記第１のアクセストークンは、新たなアクセストークンであってもよい。第１のアクセストークンが新たなアクセストークンである場合、第２のクラウドプラットフォームは、第１のアクセストークンと、第２の制御側のユーザ識別子および第２のデバイスのデバイス識別子との間の関連関係を確立する必要がある。具体的に実施するときに、第２のクラウドプラットフォームは、第２の制御側のユーザ識別子に応じて第１のアクセストークンを生成してもよく、他の要因に応じて第１のアクセストークンを生成してもよい。本発明の実施例は、第２のクラウドプラットフォームにより第１のアクセストークンを生成する方法を限定しない。

ステップＳ２０２、第１のクラウドプラットフォームは、前記第１のアクセストークンに基づいて、第２のリソースリンクを取得する。

本発明の実施例において、第１のクラウドプラットフォームは、第１のアクセストークンを取得した後、ステップＳ２０２を実行する前に、第１のクラウドプラットフォームは、ユーザに第２のクラウドプラットフォームにより認可された第１のアクセストークンを関連付けることで、ユーザアカウントの関連を完了する。第１の制御側（即ち、第１のデバイス）は、第１のクラウドプラットフォームに配信されたリソースディレクトリのデバイスリソースリンクを照会する場合、前記第１のアクセストークンに基づいて第２のリソースリンクを取得するように第１のクラウドプラットフォームをトリガする。

幾つかの実施例において、第１のクラウドプラットフォームは、第２のクラウドプラットフォームに、前記第１のアクセストークンを運ぶリソースリンク要求メッセージを送信する。具体的な実装では、第１のクラウドプラットフォームは、第２のクラウドプラットフォームのリソースディレクトリから、許可ユーザと関連付けられているデバイスにより配信された第２のリソースリンクを照会する。第２のクラウドプラットフォームは、第１のアクセストークンに関連付けられた第２のデバイスのデバイス識別子に基づき、第２のデバイスにより配信された第２のリソースリンクを取得し、取得された第２のリソースリンクを第１のクラウドプラットフォームに送信する。この際には、第２のリソースリンクのエンドポイント情報は第２のクラウドプラットフォームのエンドポイント情報である。

ステップＳ２０３、第１のクラウドプラットフォームは、前記第２のリソースリンクに基づいて、第１のクラウドプラットフォームにおける第２のデバイスの第１のリソースリンクを決定し、第１のリソースリンクが、第１のクラウドプラットフォームに接続された第１のデバイスと第２のデバイスとの通信に用いられる。

幾つかの実施例において、前記第１のクラウドプラットフォームは、前記第２のリソースリンクを/ｏｉｃ/ｒｅｓリソースに追加し、前記第２のリソースリンクにおける前記第２のクラウドプラットフォームのエンドポイント情報を前記第１のクラウドプラットフォームのエンドポイント情報に置き換えることにより、第１のリソースリンクを取得する。選択的に、第１のクラウドプラットフォームは、第１のリソースリンクにおける前記第１のクラウドプラットフォームのエンドポイント情報と、前記第２のリソースリンクにおける前記第２のクラウドプラットフォームのエンドポイント情報とのマッピング関係をさらに確立してもよい。

ステップＳ２０３が実行された後、前記方法は、以下のステップをさらに含む。

ステップＳ２０４、第１のクラウドプラットフォームは、第１のデバイスに第１のリソースリンクを送信する。

幾つかの実施例において、第１のデバイスは、第１のクラウドプラットフォームに接続されている第１の制御側である。

ステップＳ２０５、第１のクラウドプラットフォームは、第１のデバイスにより送信されたリソース操作要求メッセージを受信する。

幾つかの実施例において、前記リソース操作要求メッセージは、第１のデバイスにより第１のクラウドプラットフォームのエンドポイントに送信される。

ステップＳ２０６、第１のクラウドプラットフォームは、前記第２のクラウドプラットフォームに前記リソース操作要求メッセージを送信する。

幾つかの実施例において、第１のクラウドプラットフォームは、確立された前記第１のリソースリンクにおける前記第１のクラウドプラットフォームのエンドポイント情報と、前記第２のリソースリンクにおける前記第２のクラウドプラットフォームのエンドポイント情報とのマッピング関係に基づいて、前記第２のクラウドプラットフォームのエンドポイントに前記リソース操作要求メッセージを送信する。第２のクラウドプラットフォームは、前記リソース操作要求メッセージを第２のデバイスのデバイスリソースに転送する。

本発明の実施例において、第１のデバイスは、第１のクラウドプラットフォームに第２のデバイスに対するリソース操作要求メッセージを送信し、第１のクラウドプラットフォームは、第１のクラウドプラットフォームにより維持される第１のリソースリンクにおける第１のクラウドプラットフォームのエンドポイント情報と、第２のクラウドプラットフォームにより維持される第２のリソースリンクにおける第２のクラウドプラットフォームのエンドポイント情報とのマッピング関係に基づいて、前記第２のクラウドプラットフォームのエンドポイントに前記リソース操作要求メッセージを送信することにより、第２のクラウドプラットフォームが前記リソース操作要求メッセージを第２のデバイスに転送し、それにより、異なるネットワークに接続された第１のデバイスと第２のデバイスとの間の通信が実現される。

上記の実施例のステップＳ２０１におけるステップａ１～ステップｄ１に記載の第１のクラウドプラットフォームが第２のクラウドプラットフォームから第１のアクセストークンを取得する実現方式について、第１の制御側（第１のデバイス）と第２のデバイスとの通信の第１の処理フロー模式図は、図６に示すように、以下のステップを含む。

Ｓ１、第２の制御側が第２のデバイスをアクティブにし、第２のデバイスのデバイス識別子を生成する。

Ｓ２、第２の制御側は第２のクラウドプラットフォームに制御側登録を行う。

Ｓ３、第２のクラウドプラットフォームは第２の制御側に第２の制御側のユーザ識別子Ｕｓｅｒ ＩＤ １、第２の制御側のアクセストークンＡｃｃｅｓｓ Ｔｏｋｅｎ １を返信する。

Ｓ４、第２の制御側は、第２のデバイスが第２のクラウドプラットフォームにアクセスするための構成フローを開始する。

Ｓ５、第２のクラウドプラットフォームは、Ａｃｃｅｓｓ Ｔｏｋｅｎ １と、Ｕｓｅｒ ＩＤ １及び第２のデバイスのデバイス識別子との関連関係を維持する。

Ｓ６、第２のデバイスは、デバイスリソースリンクを第２のクラウドプラットフォームのリソースディレクトリに配信する。

Ｓ７、ユーザは、第１の制御側をトリガーしてユーザアカウントを関連付け、第１の制御側は、第１のクラウドプラットフォームが第２のクラウドプラットフォームにユーザ認可を要求するように指示する。

Ｓ８、第１のクラウドプラットフォームは第２のクラウドプラットフォームにユーザ認可リソースを要求する。

具体的な実装では、第１のクラウドプラットフォームは、ユーザ認可リソースに基づいて、第２のクラウドプラットフォームに更新要求を送信し、更新要求のターゲットＵＲＩは、第２のクラウドプラットフォームのユーザ認可リソースＵＲＩであり、更新が要求されるリソース情報には、第１のクラウドプラットフォームのクライアント識別子が含まれ、又は、更新が要求されるリソース情報には、第１のクラウドプラットフォームのクライアント識別子、及び認可された権限範囲が含まれる。例えば、認可された権限範囲１は、ユーザがアクセスする第２のクラウドプラットフォームのデバイスリソースに対する読み取り及び書き込み操作を示し、又は認可された権限範囲２は、ユーザがアクセスする第２のクラウドプラットフォームのデバイスリソースに対する読み取り専用操作を示す。

Ｓ９、第２のクラウドプラットフォームは、ユーザを認可インタラクティブページにリダイレクトし、許可するか否かをユーザに問い合わせ、ユーザが第２のクラウドプラットフォームのアカウントにログインしていなかった場合、許可ユーザはアカウントにログインする必要がある。

Ｓ１０、ユーザが許可すれば、第２のクラウドプラットフォームは第１のクラウドプラットフォームのクライアント識別子を検証し、検証に成功した後、第１のクラウドプラットフォームにリソース更新応答メッセージを返信し、メッセージ中には認可コード（ｃｏｄｅ）が含まれる。

Ｓ１１、第１のクラウドプラットフォームは第２のクラウドプラットフォームにアクセストークンを要求する。

具体的な実装では、第１のクラウドプラットフォームは、アクセストークンリソースに基づいて第２のクラウドプラットフォームに更新要求を送信し、更新要求のターゲットＵＲＩは第２のクラウドプラットフォームのアクセストークンリソースＵＲＩであり、更新されたリソース情報には、第１のクラウドプラットフォームのクライアント識別子、クライアント鍵、及びｃｏｄｅが含まれる。

Ｓ１２、第２のクラウドプラットフォームは、第１のクラウドプラットフォームのクライアント識別子、クライアント鍵、及び認可コードを検証する。

第２のクラウドプラットフォームのリソースディレクトリのＬｉｎｋｓのアクセストークンＡｃｃｅｓｓ Ｔｏｋｅｎ ２は第２のクラウドプラットフォームにより生成されてもよく、前記第２のクラウドプラットフォームは、Ａｃｃｅｓｓ Ｔｏｋｅｎ ２とＵｓｅｒ ＩＤ １との関連関係を確立し、ここで、前記第２の制御側が第２のクラウドプラットフォームに接続されているので、第２の制御側が第２のクラウドプラットフォームと通信でき、第２の制御側のユーザ識別子Ｕｓｅｒ ＩＤ １が生成され、Ａｃｃｅｓｓ Ｔｏｋｅｎ ２は、Ｕｓｅｒ ＩＤ １に関連付けられたアクセストークンＡｃｃｅｓｓ Ｔｏｋｅｎ １であってもよく、新たなアクセストークンであってもよい。Ａｃｃｅｓｓ Ｔｏｋｅｎ ２が新たなアクセストークンである場合、第２のクラウドプラットフォームがＡｃｃｅｓｓ Ｔｏｋｅｎ ２と、第２のデバイスのデバイス識別子及び第２の制御側のユーザ識別子との三者の関連関係を関連付ける必要がある。

Ｓ１３、第１のクラウドプラットフォームは、ユーザを第２のクラウドプラットフォームにより認可されたアクセストークンに関連付けて、ユーザアカウントの関連付けを完了する。

Ｓ１４、第１の制御側は第１のクラウドプラットフォームのリソースディレクトリに配信されたＬｉｎｋｓを照会する。

Ｓ１５、第１のクラウドプラットフォームは、第２のクラウドプラットフォームのリソースディレクトリに、認可ユーザに関連付けられたデバイスによって配信されたＬｉｎｋｓを照会し、照会要求にはＡｃｃｅｓｓ Ｔｏｋｅｎ ２が運ばれている。

Ｓ１６、第２のクラウドプラットフォームは、Ａｃｃｅｓｓ Ｔｏｋｅｎ ２に関連付けられた第２のデバイスのデバイス識別子に基づいて、第２のデバイスにより配信されたＬｉｎｋｓを返信し、ここで返信されたリソースリンクＬｉｎｋｓのエンドポイント情報は第２のクラウドプラットフォームのエンドポイント情報である。

Ｓ１７、第１のクラウドプラットフォームは、第２のデバイスのＬｉｎｋｓを/ｏｉｃ/ｒｅｓリソースに追加し、第２のクラウドプラットフォームにより返信されたエンドポイント情報と、第１のクラウドプラットフォームのリソースディレクトリにより公開されたＬｉｎｋｓにおけるエンドポイント情報との間のマッピングを維持する。

ここで、第１のクラウドプラットフォームにより公開されたＬｉｎｋｓにおけるリソースのエンドポイント情報は、第１のクラウドプラットフォーム自体のエンドポイント情報であり、第２のクラウドプラットフォームのエンドポイント情報ではない。

Ｓ１８、第１のクラウドプラットフォームが、第１の制御側に第２のデバイスのＬｉｎｋｓを送信し、第２のデバイスのＬｉｎｋｓにおけるエンドポイント情報が第１のクラウドプラットフォームのエンドポイント情報である。

Ｓ１９、第１の制御側は、第１のクラウドプラットフォームに第２のデバイスのリソース操作要求を送信し、前記リソース操作要求が第１の制御側により第１のクラウドプラットフォームのエンドポイントに送信される。

Ｓ２０、第１のクラウドプラットフォームは、第１のクラウドプラットフォームによって維持されるエンドポイント情報のマッピングに基づいて、第２のクラウドプラットフォームにリソース操作要求を送信する。

Ｓ２１、第２のクラウドプラットフォームは、リソース操作要求を第２のデバイスのデバイスリソースに転送する。

上記の実施例のステップＳ２０１におけるステップa２～ステップｄ２に記載の第１のクラウドプラットフォームが第２のクラウドプラットフォームから第１のアクセストークンを取得する実現方式について、第１の制御側（第１のデバイス）と第２のデバイスとの通信の第２の処理フロー模式図は、図７に示すように、以下のステップを含む。

ｈ１、第２の制御側は、第２のデバイスをアクティブにし、第２のデバイスのデバイス識別子を生成する。

ｈ２、第２の制御側は、第２のクラウドプラットフォームに制御側の登録を行う。

ｈ３、第２のクラウドプラットフォームは、第２の制御側に第２の制御側のユーザ識別子Ｕｓｅｒ ＩＤ １、第２の制御側のアクセストークンＡｃｃｅｓｓ Ｔｏｋｅｎ １を返信する。

ｈ４、第２の制御側は、第２のデバイスが第２のクラウドプラットフォームにアクセスするための構成フローを開始する。

ｈ５、第２のクラウドプラットフォームは、Ａｃｃｅｓｓ Ｔｏｋｅｎ １と、Ｕｓｅｒ ＩＤ １及び第２のデバイスのデバイス識別子との関連関係を維持する。

ｈ６、第２のデバイスは、デバイスリソースリンクを第２のクラウドプラットフォームのリソースディレクトリに配信する。

ｈ７、ユーザは、第１の制御側をトリガーしてユーザアカウントを関連付け、第１の制御側は、第１のクラウドプラットフォームが第２のクラウドプラットフォームにユーザ認可を要求するように指示する。

ｈ８、第１のクラウドプラットフォームは、第２のクラウドプラットフォームにユーザ認可を要求し、具体的な実装において、第１のクラウドプラットフォームは、第２のクラウドプラットフォームのユーザ認可アドレスに基づき、第１のアクセス要求メッセージを送信し、前記第１のアクセス要求メッセージには、第１のクラウドプラットフォームのクライアント識別子及びコールバックアドレスが含まれる。選択的に、第１のクラウドプラットフォームのクライアント識別子及びコールバックアドレスに加え、前記第１のアクセス要求メッセージには、認可された権限範囲が含まれる可能性がある。例えば、認可された権限範囲１は、ユーザがアクセスする第２のクラウドプラットフォームのデバイスリソースに対する読み取り及び書き込み操作を示し、又は、認可された権限範囲２は、ユーザがアクセスする第２のクラウドプラットフォームのデバイスリソースに対する読み取り専用操作を示す。

ｈ９、第２のクラウドプラットフォームは、ユーザを認可インタラクティブページにリダイレクトし、許可するか否かをユーザに問い合わせ、ユーザが第２のクラウドプラットフォームのアカウントにログインしていない場合、許可ユーザはアカウントにログインする必要がある。

ｈ１０、ユーザが許可すれば、第２のクラウドプラットフォームは第１のクラウドプラットフォームのクライアント識別子を検証し、検証に成功した後、第１のクラウドプラットフォームにリソース更新応答メッセージを返信し、メッセージには認可コード（ｃｏｄｅ）が含まれる。

ｈ１１、第１のクラウドプラットフォームは、第２のクラウドプラットフォームにアクセストークンを要求し、具体的な実装では、第１のクラウドプラットフォームは、第２のクラウドプラットフォームのアクセストークン取得アドレスに基づき、第２のアクセス要求メッセージを送信し、第２のアクセス要求メッセージには、第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及びｃｏｄｅが含まれる。

ｈ１２、第２のクラウドプラットフォームは、第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードを検証する。

第２のクラウドプラットフォームのリソースディレクトリのＬｉｎｋｓのアクセストークンＡｃｃｅｓｓ Ｔｏｋｅｎ ２は、第２のクラウドプラットフォームにより生成され、前記第２のクラウドプラットフォームは、Ａｃｃｅｓｓ Ｔｏｋｅｎ ２とＵｓｅｒ ＩＤ １との関連関係を確立し、ここで、前記第２の制御側が第２のクラウドプラットフォームが接続されているので、第２の制御側が第２のクラウドプラットフォームと通信できる。Ａｃｃｅｓｓ Ｔｏｋｅｎ ２は、Ｕｓｅｒ ＩＤ １に関連付けられたアクセストークンＡｃｃｅｓｓ Ｔｏｋｅｎ １であってもよく、新たなアクセストークンであってもよい。Ａｃｃｅｓｓ Ｔｏｋｅｎ ２が新たなアクセストークンである場合、第２のクラウドプラットフォームは、Ａｃｃｅｓｓ Ｔｏｋｅｎ ２と、第２のデバイスのデバイス識別子及び第２の制御側のユーザ識別子との三者の関連関係を関連付ける必要がある。

ｈ１３、第１のクラウドプラットフォームは、ユーザを、第２のクラウドプラットフォームにより認可されたアクセストークンに関連付けて、ユーザアカウントの関連付けを完了する。

ｈ１４、第１の制御側は、第１のクラウドプラットフォームのリソースディレクトリに配信されたＬｉｎｋｓを照会する。

ｈ１５、第１のクラウドプラットフォームは、第２のクラウドプラットフォームのリソースディレクトリに、認可ユーザに関連付けられたデバイスにより配信されたＬｉｎｋｓを照会し、照会要求中にはＡｃｃｅｓｓ Ｔｏｋｅｎ ２が運ばれる。

ｈ１６、第２のクラウドプラットフォームは、Ａｃｃｅｓｓ Ｔｏｋｅｎ ２に関連づけられた第２のデバイスのデバイス識別子に基づき、第２のデバイスにより配信されたＬｉｎｋｓを返信し、ここで返信されたリソースリンクＬｉｎｋｓのエンドポイント情報は、第２のクラウドプラットフォームのエンドポイント情報である。

ｈ１７、第１のクラウドプラットフォームは、第２のデバイスのＬｉｎｋｓを/ｏｉｃ/ｒｅｓリソースに追加し、第２のクラウドプラットフォームにより返信されたエンドポイント情報と、第１のクラウドプラットフォームのリソースディレクトリにより公開されたＬｉｎｋｓにおけるエンドポイント情報との間のマッピングを維持する。

ここで、第１のクラウドプラットフォームにより公開されたＬｉｎｋｓにおけるリソースのエンドポイント情報は、第１のクラウドプラットフォーム自体のエンドポイント情報であり、第２のクラウドプラットフォームのエンドポイント情報ではない。

ｈ１８、第１のクラウドプラットフォームは、第１の制御側に第２のデバイスのＬｉｎｋｓを送信し、第２のデバイスのＬｉｎｋｓにおけるエンドポイント情報は、第１のクラウドプラットフォームのエンドポイント情報である。

ｈ１９、第１の制御側は、第１のクラウドプラットフォームに第２のデバイスのリソース操作要求を送信し、前記リソース操作要求は、第１の制御側により第１のクラウドプラットフォームのエンドポイントに送信される。

ｈ２０、第１のクラウドプラットフォームは、第１のクラウドプラットフォームにより維持されるエンドポイント情報のマッピングに基づき、第２のクラウドプラットフォームにリソース操作要求を送信する。

ｈ２１、第２のクラウドプラットフォームは、リソース操作要求を第２のデバイスのデバイスリソースに転送する。

上記のデバイスの通信方法を実現するために、本発明の実施例は、第１のクラウドプラットフォームを提供し、前記第１のクラウドプラットフォーム３００の構成構造は、図８に示すように、第１の送受信ユニット３０１、第２の送受信ユニット３０２及び第１の処理ユニット３０３を備える。

第１の送受信ユニット３０１は、第２のクラウドプラットフォームから、前記第１のクラウドプラットフォームが前記第２のクラウドプラットフォームにおける第２のデバイスの第２のリソースリンクにアクセスするための第１のアクセストークンを取得するように構成され、前記第２のデバイスは前記第２のクラウドプラットフォームに接続されている。

第２の送受信ユニット３０２は、前記第１のアクセストークンに基づき、前記第２のリソースリンクを取得するように構成される。

第１の処理ユニット３０３は、前記第２のリソースリンクに基づき、前記第１のクラウドプラットフォームにおける前記第２のデバイスの第１のリソースリンクを決定するように構成され、前記第１のリソースリンクは、前記第１のクラウドプラットフォームに接続される第１のデバイスと前記第２のデバイスとの通信に用いられる。

幾つかの実施例において、前記第１の送受信ユニット３０１は、前記第２のクラウドプラットフォームにユーザ認可リソースに対する第１の更新要求メッセージを送信し、
前記第２のクラウドプラットフォームにより送信された第１の更新要求応答メッセージを受信し、
前記第１の更新要求応答メッセージに基づき、前記第２のクラウドプラットフォームにアクセストークンリソースに対する第２の更新要求メッセージを送信し、
前記第２のクラウドプラットフォームにより送信された第２の更新要求応答メッセージを受信し、前記第２の更新要求応答メッセージには前記第１のアクセストークンが運ばれる。

ここで、前記第１の更新要求メッセージは、第１のクラウドプラットフォームのクライアント識別子及びターゲットユーザ認可リソースのＵＲＩを含み、又は、前記第１の更新要求メッセージは、第１のクラウドプラットフォームのクライアント識別子、ターゲットユーザ認可リソースのＵＲＩ及び認可された権限範囲を含む。前記第１の更新要求応答メッセージは、認可コードを含む。前記第２の更新要求メッセージは、前記第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードを含む。

他の幾つかの実施例において、前記第１の送受信ユニット３０１は、前記第２のクラウドプラットフォームのユーザ認可アドレスに基づき、第１のアクセス要求メッセージを送信し、
前記第２のクラウドプラットフォームにより送信された認可コードを受信し、
前記第２のクラウドプラットフォームのアクセストークン取得アドレスに基づき、第２のアクセス要求メッセージを送信し、
前記第２のクラウドプラットフォームにより送信された前記第１のアクセストークンを受信するように構成される。

ここで、前記第１のアクセス要求メッセージは、前記第１のクラウドプラットフォームのクライアント識別子及びコールバックアドレスを含み、又は、前記第１のアクセス要求メッセージは、前記第１のクラウドプラットフォームのクライアント識別子、コールバックアドレス及び認可された権限範囲を含む。前記第２のアクセス要求メッセージは、前記第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードを含む。

本発明の実施例において、前記第２の送受信ユニット３０２は、前記第２のクラウドプラットフォームに、前記第１のアクセストークンを運ぶリソースリンク要求メッセージを送信し、
前記第２のクラウドプラットフォームにより送信された第２のリソースリンクを受信するように構成され、前記第２のリソースリンクは前記第１のアクセストークンに関連付けられる前記第２のクラウドプラットフォームの前記第２のデバイスにより配信されたリソースリンクである。

本発明の実施例において、前記第１の処理ユニット３０３は、前記第２のリソースリンクにおける前記第２のクラウドプラットフォームのエンドポイント情報を前記第１のクラウドプラットフォームのエンドポイント情報に置き換えることにより、第１のリソースリンクを取得するように構成される。

本発明の実施例において、前記第１の処理ユニット３０３は、前記第１のリソースリンクにおける前記第１のクラウドプラットフォームのエンドポイント情報と、前記第２のリソースリンクにおける前記第２のクラウドプラットフォームのエンドポイント情報とのマッピング関係を確立するようにさらに構成される。

本発明の実施例において、前記第１のクラウドプラットフォームは、前記第１のデバイスに前記第１のリソースリンクを送信するように構成される第３の送受信ユニット３０４と、をさらに備える。

本発明の実施例において、前記第３の送受信ユニット３０４は、前記第１のデバイスにより送信されたリソース操作要求メッセージを受信し、前記第２のクラウドプラットフォームに前記リソース操作要求メッセージを送信するようにさらに構成される。

本発明の実施例において、前記第３の送受信ユニット３０４は、確立された前記第１のリソースリンクにおける前記第１のクラウドプラットフォームのエンドポイント情報と、前記第２のリソースリンクにおける前記第２のクラウドプラットフォームのエンドポイント情報とのマッピング関係に基づき、前記第２のクラウドプラットフォームのエンドポイントに前記リソース操作要求メッセージを送信するように構成される。

上記のデバイスの通信方法を実現するために、本発明の実施例は、第２のクラウドプラットフォームをさらに提供し、図９に示すように、前記第２のクラウドプラットフォーム４００の構成構造は、第４の送受信ユニット４０１を備える。

第４の送受信ユニット４０１は、第１のクラウドプラットフォームに、前記第１のクラウドプラットフォームが前記第２のクラウドプラットフォームにおける第２のデバイスの第２のリソースリンクにアクセスするための第１のアクセストークンを送信するように構成され、前記第２のリソースリンクが、前記第１のクラウドプラットフォームによりエンドポイント情報の交換が行われることにより、第１のリソースリンクが得られ、前記第１のリソースリンクは、第１のデバイスと第２のデバイスとの通信に用いられる。

前記第１のデバイスが前記第１のクラウドプラットフォームに接続され、前記第２のデバイスが前記第２のクラウドプラットフォームに接続される。

本発明の実施例において、前記第２のクラウドプラットフォームは、第１のアクセストークンと、ユーザ識別子及び第２のデバイス識別子との関連関係を確立するように構成される第２の処理ユニット４０２をさらに備える。

幾つかの実施例において、前記第４の送受信ユニット４０１は、前記第１のクラウドプラットフォームにより送信されたユーザ認可リソースに対する第１の更新要求メッセージを受信し、
前記第１のクラウドプラットフォームに第１の更新要求応答メッセージを送信し、
前記第１のクラウドプラットフォームにより送信されたアクセストークンリソースに対する第２の更新要求メッセージを受信し、
前記第１のクラウドプラットフォームに、前記第１のアクセストークンを運ぶ第２の更新要求応答メッセージを送信するように構成される。

ここで、前記第１の更新要求メッセージは、第１のクラウドプラットフォームのクライアント識別子及びターゲットユーザ認可リソースのＵＲＩを含み、又は、前記第１の更新要求メッセージは、第１のクラウドプラットフォームのクライアント識別子、ターゲットユーザ認可リソースのＵＲＩ及び認可された権限範囲を含む。前記第１の更新要求応答メッセージは、認可コードを含む。前記第２の更新要求メッセージは、前記第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードを含む。

他の幾つかの実施例において、前記第４の送受信ユニット４０１は、前記第２のクラウドプラットフォームのユーザ認可アドレスに基づき、第１のアクセス要求メッセージを受信し、
前記第１のクラウドプラットフォームに認可コードを送信し、
前記第２のクラウドプラットフォームのアクセストークン取得アドレスに基づき、第２のアクセス要求メッセージを受信し、
前記第１のクラウドプラットフォームに前記第１のアクセストークンを送信するように構成される。

ここで、前記第１のアクセス要求メッセージは、前記第１のクラウドプラットフォームのクライアント識別子及びコールバックアドレスを含み、又は、前記第１のアクセス要求メッセージは、前記第１のクラウドプラットフォームのクライアント識別子、コールバックアドレス及び認可された権限範囲を含む。前記第２のアクセス要求メッセージは、前記第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードを含む。

本発明の実施例において、前記第４の送受信ユニット４０１は、前記第１のクラウドプラットフォームにより送信された、前記第１のアクセストークンを運ぶリソースリンク要求メッセージを受信し、
前記第１のクラウドプラットフォームに、第２のリソースリンクを送信するようにさらに構成され、前記第２のリソースリンクは、前記第１のアクセストークンに関係付けられる前記第２のクラウドプラットフォームの前記第２のデバイスにより配信されたリソースリンクである。

本発明の実施例において、前記第４の送受信ユニット４０１は、前記第１のクラウドプラットフォームにより送信されたリソース操作要求メッセージを受信するようにさらに構成される。

本発明の実施例は、クラウドプラットフォームをさらに提供し、当該クラウドプラットフォームは、プロセッサと、プロセッサで実行可能なコンピュータプログラムを記憶するためのメモリと、を備え、前記プロセッサは、前記コンピュータプログラムを実行するときに、上記の端末デバイスにより実行されたデバイスの通信方法のステップを実行するために使用される。

図１０は、本発明の実施例に係るクラウドプラットフォームのハードウェアの構成構造の模式図であり、クラウドプラットフォーム７００は、少なくとも一つのプロセッサ７０１、メモリ７０２、少なくとも一つのネットワークインターフェース７０４を含む。端末デバイス７００における各ユニットは、バスシステム７０５を介して結合される。バスシステム７０５はこれらのユニットとの間の接続通信を実現するために使用されると理解されてもよい。バスシステム７０５は、データバスに加え、電源バス、制御バス及び状態信号バスを含む。しかし、明確に説明するために、図１０には様々なバスをいずれもバスシステム７０５と表記する。

メモリ７０２は、揮発性メモリ又は不揮発性メモリであってもよく、揮発性メモリ及び不揮発性メモリの両方を含んでもよいと理解されてもよい。ここで、不揮発性メモリは、ＲＯＭ、プログラマブル読み取り専用メモリ（ＰＲＯＭ、Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ-Ｏｎｌｙ Ｍｅｍｏｒｙ）、消去可能なプログラマブル読み取り専用メモリ（ＥＰＲＯＭ、Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ-Ｏｎｌｙ Ｍｅｍｏｒｙ）、電気的消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ、Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ-Ｏｎｌｙ Ｍｅｍｏｒｙ）、磁性ランダムアクセスメモリ（ＦＲＡＭ、ｆｅｒｒｏｍａｇｎｅｔｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、フラッシュメモリ（Ｆｌａｓｈ Ｍｅｍｏｒｙ）、磁気表面メモリ、光ディスク、又はコンパクトディスク読み取り専用メモリ（ＣＤ-ＲＯＭ、Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ-Ｏｎｌｙ Ｍｅｍｏｒｙ）であってもよく、磁気表面メモリは、磁気ディスクメモリ又は磁気テープメモリであってもよい。揮発性メモリは、外部キャッシュとして機能するランダムアクセスメモリ（ＲＡＭ、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）であってもよい。例示であるが限定ではない説明として、例えば、スタティックランダムアクセスメモリ（ＳＲＡＭ、Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、同期スタティックランダムアクセスメモリ（ＳＳＲＡＭ、Ｓｙｎｃｈｒｏｎｏｕｓ Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ、Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ、Ｓｙｎｃｈｒｏｎｏｕｓ Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ダブルデータレート同期ダイナミックランダムアクセスメモリ（ＤＤＲＳＤＲＡＭ、Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ Ｓｙｎｃｈｒｏｎｏｕｓ Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、エンハンスト同期ダイナミックランダムアクセスメモリ（ＥＳＤＲＡＭ、Ｅｎｈａｎｃｅｄ Ｓｙｎｃｈｒｏｎｏｕｓ Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、同期リンクダイナミックランダムアクセスメモリ（ＳＬＤＲＡＭ、ＳｙｎｃＬｉｎｋ Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ダイレクトラムバスランダムアクセスメモリ（ＤＲＲＡＭ、Ｄｉｒｅｃｔ Ｒａｍｂｕｓ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のような多くの形態のＲＡＭが利用可能である。本発明の実施例に記載のメモリ７０２は、これらと任意の他の適切なタイプのメモリを含むが、これらに限定されないことを意図する。

本発明の実施例におけるメモリ７０２は、クラウドプラットフォーム７００の動作をサポートするように様々なタイプのデータを記憶するために使用される。これらのデータの例は、例えば、アプリケーションプログラム７０２２のような端末デバイス７００上で操作するために使用される任意のコンピュータプログラムを含む。本発明の実施例の方法を実現するプログラムはアプリケーションプログラム７０２２に含まれてもよい。

上記本発明の実施例に開示された方法は、プロセッサ７０１に適用されてもよく、又はプロセッサ７０１により実現されてもよい。プロセッサ７０１は、信号の処理能力を有する集積回路チップであってもよい。実装プロセスにおいて、上記の方法の各ステップは、プロセッサ７０１におけるハードウェアの集積論理回路又はソフトウェアの形の命令により完了することができる。上記のプロセッサ７０１は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ、Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、又は他のプログラマブル論理デバイス、ディスクリートゲート又はトランジスタ論理デバイス、ディスクリートハードウェアコンポーネント等であってもよい。プロセッサ７０１は、本発明の実施例に開示された各方法、ステップ及び論理ブロック図を実現又は実行してもよい。汎用プロセッサは、マイクロプロセッサ又はいずれかの通常のプロセッサ等であってもよい。本発明の実施例に開示された方法のステップに関連して、ハードウェア復号化プロセッサにより実行されて完了されるように、又は復号化プロセッサにおけるハードウェア及びソフトウェアモジュールの組み合わせで実行して完了されるように直接に具現化されることができる。ソフトウェアモジュールは、メモリ７０２における記憶媒体に配置されてもよく、プロセッサ７０１は、メモリ７０２内の情報を読み取り、そのハードウェアと組み合わせて上記の方法のステップを完了する。

例示的な実施例において、前述の方法を実行するために、クラウドプラットフォーム７００は一つ又は複数の特定用途向け集積回路（ＡＳＩＣ、Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＤＳＰ、プログラマブルロジックデバイス（ＰＬＤ、Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）、複雑なプログラマブルロジックデバイス（ＣＰＬＤ、ｃｏｍｐｌｅｘ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）、ＦＰＧＡ、汎用プロセッサ、コントローラ、ＭＣＵ、ＭＰＵ、又は他の電子部品により実現されてもよい。

本出願の実施例は、コンピュータプログラムを記憶するための記憶媒体をさらに提供する。

選択的に、該記憶媒体は本出願の実施例におけるクラウドプラットフォームに適用されてもよく、且つ該コンピュータプログラムはコンピュータに本出願の実施例の各方法における対応するフローを実行させ、簡潔にするために、ここで説明を省略する。

本発明は、本発明の実施例に係る方法、デバイス（システム）、及びコンピュータプログラム製品のフローチャート及び/又はブロック図を参照して説明される。フローチャート及び/又はブロック図における各フロー及び/又はブロック、及びフローチャート及び/又はブロック図におけるフロー及び/又はブロックの組み合わせはコンピュータプログラム命令によって実現できることを理解されたい。一つのマシンを生成するようにこれらのコンピュータプログラム命令は汎用コンピュータ、専用コンピュータ、組み込みプロセッサ又は他のプログラマブルデータ処理デバイスのプロセッサに提供されて、マシンを生成することができ、その結果、コンピュータ又は他のプログラマブルデータ処理デバイスのプロセッサにより実行された命令は、フローチャートの一つのフロー又は複数のフロー及び/又はブロック図の一つのブロック又は複数のブロックで指定された機能を実現するための装置を生成する。

これらのコンピュータプログラム命令は、コンピュータまたは他のプログラマブルデータ処理デバイスを特定の方式で動作させるように導くことができるコンピュータ可読メモリに記憶されることもでき、その結果、当該コンピュータ可読メモリに記憶された命令は、フローチャートの一つのフロー又は複数のフロー及び/又はブロック図の一つのブロック又は複数のブロックで指定された機能を実現する命令装置を含む製造品を生成する。

これらのコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理デバイスにロードされてもよく、その結果、コンピュータにより実現された処理を生成するようにコンピュータ又は他のプログラマブルデバイスで一連の操作ステップが実行され、それにより、コンピュータ又は他のプログラマブルデバイスで実行された命令は、フローチャートの一つのフロー又は複数のフロー及び/又はブロック図の一つのブロック又は複数のブロックで指定された機能を実現するためのステップを提供する。

上記のように、本発明の好ましい実施例に過ぎず、本発明の保護範囲を限定するものではなく、本発明の精神及び原則内で行われたいかなる修正、同等置換及び改善などは、いずれも本発明の保護範囲内に含まれるべきである。

Claims (15)

1. 第１のクラウドプラットフォームが、第２のクラウドプラットフォームから、前記第１のクラウドプラットフォームが前記第２のクラウドプラットフォームにおける第２のデバイスの第２のリソースリンクにアクセスするための第１のアクセストークンを取得するステップと、
   前記第１のクラウドプラットフォームが、前記第１のアクセストークンに基づいて、前記第２のリソースリンクを取得するステップと、
   前記第１のクラウドプラットフォームが、前記第２のリソースリンクに基づいて、前記第１のクラウドプラットフォームにおける前記第２のデバイスの第１のリソースリンクを決定するステップを含み、
   前記第２のデバイスは、前記第２のクラウドプラットフォームに接続され、
   前記第１のリソースリンクは、前記第１のクラウドプラットフォームに接続された第１のデバイスと前記第２のデバイスとの通信に使用される
   ことを特徴とするデバイスの通信方法。
2. 前記第１のクラウドプラットフォームが第２のクラウドプラットフォームから第１のアクセストークンを取得するステップは、
   前記第１のクラウドプラットフォームが、前記第２のクラウドプラットフォームのユーザ認可アドレスに基づいて、第１のアクセス要求メッセージを送信するステップと、
   前記第１のクラウドプラットフォームが、前記第２のクラウドプラットフォームにより送信された認可コードを受信するステップと、
   前記第１のクラウドプラットフォームが、前記第２のクラウドプラットフォームのアクセストークン取得アドレスに基づいて、第２のアクセス要求メッセージを送信するステップと、
   前記第１のクラウドプラットフォームが、前記第２のクラウドプラットフォームにより送信された前記第１のアクセストークンを受信するステップを含む
   ことを特徴とする請求項１に記載の方法。
3. 前記第１のアクセス要求メッセージは、
   前記第１のクラウドプラットフォームのクライアント識別子、及びコールバックアドレスを含む
   ことを特徴とする請求項２に記載の方法。
4. 前記第２のアクセス要求メッセージは、
   前記第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードを含む
   ことを特徴とする請求項２又は３に記載の方法。
5. 前記第１のアクセス要求メッセージは、認可された権限範囲をさらに含む
   ことを特徴とする請求項２～４のいずれか１項に記載の方法。
6. 前記第１のクラウドプラットフォームが前記第１のアクセストークンに基づいて、前記第２のリソースリンクを取得するステップは、
   前記第１のクラウドプラットフォームが、前記第２のクラウドプラットフォームに、前記第１のアクセストークンを運ぶリソースリンク要求メッセージを送信するステップと、
   前記第１のクラウドプラットフォームが、前記第２のクラウドプラットフォームにより送信された第２のリソースリンクを受信するステップを含み、
   前記第２のリソースリンクは、前記第２のクラウドプラットフォームにより前記第１のアクセストークンに関連付けられる前記第２のデバイスによって配信されたリソースリンクである
   ことを特徴とする請求項１～５のいずれか１項に記載の方法。
7. 前記第１のクラウドプラットフォームが、前記第２のリソースリンクに基づいて、前記第１のクラウドプラットフォームにおける前記第２のデバイスの第１のリソースリンクを決定するステップは、
   前記第１のクラウドプラットフォームが、前記第２のリソースリンクにおける前記第２のクラウドプラットフォームのエンドポイント情報を前記第１のクラウドプラットフォームのエンドポイント情報に置き換えることにより、第１のリソースリンクを取得するステップを含む
   ことを特徴とする請求項１～６のいずれか１項に記載の方法。
8. 前記第１のクラウドプラットフォームが、前記第１のリソースリンクにおける前記第１のクラウドプラットフォームのエンドポイント情報と、前記第２のリソースリンクにおける前記第２のクラウドプラットフォームのエンドポイント情報とのマッピング関係を確立するステップをさらに含む
   ことを特徴とする請求項７に記載の方法。
9. 第２のクラウドプラットフォームが、第１のクラウドプラットフォームに、前記第１のクラウドプラットフォームが前記第２のクラウドプラットフォームにおける第２のデバイスの第２のリソースリンクにアクセスするための第１のアクセストークンを送信するステップを含み、
   前記第１のクラウドプラットフォームによって前記第２のリソースリンクのエンドポイント情報を置き換えることにより、第１のリソースリンクを取得し、前記第１のリソースリンクは第１のデバイスと第２のデバイスの通信に用いられ、
   前記第１のデバイスは前記第１のクラウドプラットフォームに接続され、前記第２のデバイスは前記第２のクラウドプラットフォームに接続される
   ことを特徴とするデバイスの通信方法。
10. 前記第２のクラウドプラットフォームが第１のクラウドプラットフォームに第１のアクセストークンを送信するステップは、
    前記第２のクラウドプラットフォームが、前記第２のクラウドプラットフォームのユーザ認可アドレスに基づいて、第１のアクセス要求メッセージを受信するステップと、
    前記第２のクラウドプラットフォームが、前記第１のクラウドプラットフォームに認可コードを送信するステップと、
    前記第２のクラウドプラットフォームが、前記第２のクラウドプラットフォームのアクセストークン取得アドレスに基づいて、第２のアクセス要求メッセージを受信するステップと、
    前記第２のクラウドプラットフォームが、前記第１のクラウドプラットフォームに前記第１のアクセストークンを送信するステップを含む
    ことを特徴とする請求項９に記載の方法。
11. 前記第１のアクセス要求メッセージは、
    前記第１のクラウドプラットフォームのクライアント識別子、及びコールバックアドレスを含む
    ことを特徴とする請求項１０に記載の方法。
12. 前記第２のアクセス要求メッセージは、
    前記第１のクラウドプラットフォームのクライアント識別子、クライアント鍵及び認可コードを含む
    ことを特徴とする請求項１０又は１１に記載の方法。
13. 前記第１のアクセス要求メッセージは、認可された権限範囲をさらに含む
    ことを特徴とする請求項１０～１２のいずれか１項に記載の方法。
14. 請求項１から８のいずれか一項に記載の方法を実行するように構成されることを特徴とする第１のクラウドプラットフォーム。
15. 請求項９から１３のいずれか一項に記載の方法を実行するように構成されることを特徴とする第２のクラウドプラットフォーム。

Images