(57)【要約】【課題】  改善されたクラウドロボティックスシステムを提供する。【解決手段】  クラウドプラットフォームとロボットとを備えるクラウドロボティクスシステムであって、前記クラウドプラットフォーム及び前記ロボットは、それぞれ、タスクを実行するための共通のインタフェースを有するサービスモジュールを実行するものであり、前記共通のインタフェースは、少なくともタスクの実行を依頼するためのリクエストと、前記タスクの実行の状況を報告するためのフィードバックとを有し、前記サービスモジュールのそれぞれは、少なくとも、前記タスクを実行するためのワーキングルーチンと、前記タスクの実行が失敗したかどうかを検出するための失敗検出サブルーチンと、外部に救助を要請するための救助要請ルーチンとを有することを特徴とする。【選択図】  図１
2017047519.tif 000002
【特許請求の範囲】
【請求項１】
クラウドプラットフォームとロボットとを備えるクラウドロボティクスシステムであって、
前記クラウドプラットフォーム及び前記ロボットは、それぞれ、タスクを実行するための共通のインタフェースを有するサービスモジュールを実行するものであり、
前記共通のインタフェースは、少なくともタスクの実行を依頼するためのリクエストと、前記タスクの実行の状況を報告するためのフィードバックとを有し、
前記サービスモジュールのそれぞれは、少なくとも、前記タスクを実行するためのワーキングルーチンと、前記タスクの実行が失敗したかどうかを検出するための失敗検出サブルーチンとを有する
ことを特徴とするシステム。
【請求項２】
前記システムは、ユーザインタフェースを備えたユーザ端末をさらに備えるとともに、前記サービスモジュールは、外部に救助を要請するための救助要請ルーチンをさらに備え、
前記失敗検出サブルーチンが前記タスクの実行が失敗したことを検出した場合に、前記救助要請ルーチンにより前記ユーザ端末へ救助を要請する
ことを特徴とする請求項１に記載のシステム。
【請求項３】
前記クラウドプラットフォームは、前記ユーザ端末に対して前記ロボットに対する操作を許可することを特徴とする請求項２に記載のシステム。
【請求項４】
前記ロボットに対する操作を許可することは、前記ユーザ端末のディスプレイに示された視覚情報に対する直接操作による操作許可であることを特徴とする請求項３に記載のシステム。
【請求項５】
前記ユーザインタフェースは、３Ｄジェスチャーインタフェースであることを特徴とする請求項２〜４のいずれか１項に記載のシステム。
【請求項６】
前記ユーザインタフェースは、ヘッドマウントディスプレイを含むことを特徴とする請求項２〜５のいずれか１項に記載のシステム。
【請求項７】
前記救助を要請した前記ユーザ端末から得た情報を検索可能にデータベース化することを特徴とする請求項２〜６のいずれか１項に記載のシステム。
【請求項８】
前記データベース化された前記情報は、前記救助を要請することとなった前記ロボットの状況が含まれ、前記情報は、前記状況に陥った他のロボットの救助に利用されることを特徴とする請求項２〜７のいずれか１項に記載のシステム。
【請求項９】
前記救助要請を行うために前記ユーザ端末に表示させるための画像が送信され、前記画像の少なくとも一部にはプライバシ保護のための処理がなされることを特徴とする請求項２〜８のいずれか１項に記載のシステム。
【請求項１０】
クラウドプラットフォームとロボットとを備えるクラウドロボティクスシステムで実行されるコンピュータプログラムであって、前記システムで実行されたとき、
前記クラウドプラットフォーム及び前記ロボットに、それぞれ、タスクを実行するための共通のインタフェースを有するサービスモジュールを実行させる処理ステップと、
前記共通のインタフェースを介して、前記サービスモジュールに、少なくともタスクの実行を依頼するためにリクエストさせる処理ステップ、及び前記タスクの実行の状況を報告するためにフィードバックさせる処理ステップと、
を実行し、ここにおいて、
前記サービスモジュールは、ワーキングルーチンに前記タスクを実行させる処理ステップと、失敗検出サブルーチンに前記タスクの実行が失敗したかどうかを検出させる処理ステップとをさらに有するプログラム。
【請求項１１】
前記システムは、ユーザインタフェースを備えたユーザ端末をさらに備えるとともに、前記サービスモジュールは、外部に救助を要請するための救助要請ルーチンをさらに備え、
前記失敗検出サブルーチンが前記タスクの実行が失敗したことを検出した場合に、前記救助要請ルーチンに前記ユーザ端末へ救助を要請させる処理ステップ
をさらに有することを特徴とする請求項１０に記載のプログラム。
【請求項１２】
前記クラウドプラットフォームに、前記ユーザ端末に対して前記ロボットに対する操作を許可させる処理ステップをさらに有することを特徴とする請求項１１に記載のプログラム。
【請求項１３】
前記ロボットに対する操作を許可させる処理ステップは、前記ユーザ端末のディスプレイに示された視覚情報に対する直接操作による操作を許可させる処理ステップであることを特徴とする請求項１２に記載のプログラム。
【請求項１４】
前記ユーザインタフェースは、３Ｄジェスチャーインタフェースであることを特徴とする請求項１１〜１３のいずれか１項に記載のプログラム。
【請求項１５】
前記ユーザインタフェースは、ヘッドマウントディスプレイを含むことを特徴とする請求項１１〜１４のいずれか１項に記載のプログラム。
【請求項１６】
前記救助を要請した前記ユーザ端末から得た情報を検索可能にデータベース化させる処理ステップをさらに有することを特徴とする請求項１１〜１５のいずれか１項に記載のプログラム。
【請求項１７】
前記データベース化された前記情報は、前記救助を要請することとなった前記ロボットの状況が含まれ、前記情報は、前記状況に陥った他のロボットの救助に利用されることを特徴とする請求項１１〜１６のいずれか１項に記載のプログラム。
【請求項１８】
前記クラウドプラットフォームに、
前記救助要請を行うために前記ユーザ端末に表示させるための画像を送信させる処理ステップと、
前記画像の少なくとも一部にプライバシ保護のための処理を実施させる処理ステップと
をさらに有することを特徴とする請求項１１〜１７のいずれか１項に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、広く自律作動ないし自律移動するロボットを制御または支援するシステムに関し、より具体的には、自律作動ないし自律移動するロボットと、これらロボットを制御または支援するクラウドサーバ群（以下、「クラウドプラットフォーム」という。）と、かかるクラウドプラットフォームに接続可能な情報処理装置とを含むクラウドロボティクスシステムに関する。
【背景技術】
【０００２】
従来、一般家庭や様々な施設において、自律して作業したり移動したりするロボット（以下、「自律ロボット」、あるいは、単に「ロボット」という。）によるサービスを提供するための技術が提案されてきた。これらのロボットは、ユーザから直接要求を受けたり、ネットワークを介してロボットが接続している遠隔サーバからタスクを受けたりすることにより、その任務を果たすべく作業ないし移動を行う。
かかる遠隔サーバとロボットとの間の通信方法や、遠隔サーバによるロボットの制御方法については、様々な提案がなされている。
【０００３】
例えば、サーバからのタスク実行依頼に基づきロボットがタスクを実行する際、サーバとロボットとの間の通信を良好に行い、確実かつ円滑にタスクの実行処理を行わせる技術が提案されている（特許文献１）。
【０００４】
すわなち、特許文献１には、通信機能を有するロボットと、通信ネットワークを介して前記ロボットにタスク実行要求を行なうサーバとがデータ通信を行なう通信方法において、前記サーバから前記ロボットへ伝送された要求タスク情報に対して、前記ロボットが、前記要求タスク情報に対する実行可否情報を含む見積り情報を前記サーバに送信することを特徴とする通信方法が開示されている。
【０００５】
また、クラウド・コンピューティング・プラットフォームを利用して、計算、記憶、協同するロボット（クラウドロボット）システムも提案されている（特許文献２）。
【０００６】
すなわち、特許文献２には、クラウド・コンピューティング・プラットフォームおよび少なくとも一台のロボットを含むクラウドロボットシステムであって、前記クラウド・コンピューティング・プラットフォームは、前記システムにおける少なくとも一台の前記ロボットにより送信される、前記一台のロボットに関するデータ、ステータスおよびリクエストを含む作業情報を受信し、前記データおよび前記ステータスの作業情報を処理して前記ロボットに処理結果を返信し、前記リクエストに応じて対応するロボットに制御命令を送信し、前記ロボットは、自身の前記作業情報を前記クラウド・コンピューティング・プラットフォームに送信し、前記クラウド・コンピューティング・プラットフォームにより処理された前記作業情報の処理結果を受信し、前記クラウド・コンピューティング・プラットフォームにより送信される前記制御命令に応じて自身の動作を行う、ことを特徴とするクラウドロボットシステムが開示されている。
【０００７】
また、一方のロボットが得た知識を他方のロボットが有効に利用してタスクを効率よく実行するための共有されたロボット知識ベースを備えたクラウド・コンピューティング・システムも提案もなされている（特許文献３）。
【０００８】
すなわち、特許文献３には、共有されたロボット知識ベースを備えたクラウド・コンピューティング・システムであって、ロボットが遭遇した物体に関するデータを前記ロボットから収集して、その収集データを共有されたロボット知識ベースに蓄積し、あるいは、ロボットに対して物体との触れ合いを指示し、前記ロボットと物体との触れ合いに基づくフィードバックを前記ロボットから受信してそのフィードバックに基づき共有されたロボット知識ベースを更新し、あるいは、その共有された知識ベースに蓄積された情報に基づいてアプリケーションの実行をロボットに指示するシステムが開示されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００６−００７３４１号公報
【特許文献２】特表２０１３−５３６０９５号公報
【特許文献３】米国特許第８６３９６４４号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、従来のクラウド・コンピューティングを前提としたロボット制御ないし支援は、知識ベースとなるデータベースをどのように構築するのかについて、さほど具体的には開示されていない。特に、クラウドプラットフォームやクラウド・コンピューティング環境が、現時点で知識ベースを参照してもロボットからの要求に応えられない場合の対処については、更なる改善が期待される。
【課題を解決するための手段】
【００１１】
そこで、本発明の一実施形態にかかるクラウドロボティクスシステムは、クラウドプラットフォームとロボットとを備えるクラウドロボティクスシステムであって、前記クラウドプラットフォーム及び前記ロボットは、それぞれ、タスクを実行するための共通のインタフェースを有するサービスモジュールを実行するものであり、前記共通のインタフェースは、少なくともタスクの実行を依頼するためのリクエストと、前記タスクの実行の状況を報告するためのフィードバックとを有し、前記サービスモジュールのそれぞれは、少なくとも、前記タスクを実行するためのワーキングルーチンと、前記タスクの実行が失敗したかどうかを検出するための失敗検出サブルーチンとを有することを特徴とする。
【００１２】
また、前記システムは、ユーザ端末をさらに備えるとともに、前記サービスモジュールは、外部に救助を要請するための救助要請ルーチンをさらに備え、前記失敗検出サブルーチンが前記タスクの実行が失敗したことを検出した場合に、前記救助要請ルーチンにより前記ユーザ端末へ救助を要請する
ことを特徴とする。
【発明の効果】
【００１３】
本発明の一実施形態にかかるクラウドロボティクスシステム等によれば、クラウドプラットフォームやクラウド・コンピューティング環境が、現時点での知識ベースを参照してもロボットからの要求に応えられない場合であっても良好に解決へと導くことができるという効果を奏する。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施形態にかかるロボット、情報処理装置、クラウドプラットフォームを含むクラウドロボティクスシステムの全体構成例を説明する説明図である。
【図２】本発明の一実施形態にかかるクラウドロボティクスシステムにおけるロボットのバリエーション例を説明する説明図である。
【図３】本発明の一実施形態にかかるロボットを構成するハードウェアの機能ブロックを説明する説明図である。
【図４】本発明の一実施形態にかかるクラウドロボティクスシステムにおける情報処理装置の外観構成例を説明する説明図である。
【図５】本発明の一実施形態にかかる情報処理装置を構成するハードウェアの機能ブロックを説明する説明図である。
【図６】本発明の一実施形態にかかるクラウドプラットフォームの詳細な機能ブロック構成を説明する説明図である。
【図７】本発明の一実施形態にかかるクラウドロボティクスシステムにおける処理ルーチン（処理サービスの構成要素）の基本概念を説明する説明図である。
【図８】本発明の一実施形態にかかるクラウドロボティクスシステムにおける処理ルーチン（処理サービスの構成要素）を説明する説明図である。
【図９】本発明の一実施形態にかかるクラウドロボティックスシステムの動作概念を説明する説明図である。
【図１０】本発明の一実施形態にかかるクラウドロボティクスシステムのアプリケーション例を説明する説明図である。
【図１１】本発明の他の実施形態にかかるクラウドロボティクスシステムのアプリケーション例を説明する説明図である。
【図１２】本発明の他の実施形態にかかるクラウドロボティクスシステムのアプリケーション例を説明する説明図である。
【図１３】本発明のさらに他の実施形態にかかるクラウドロボティクスシステムのアプリケーション例を説明する説明図である。
【図１４】本発明のさらに他の実施形態にかかるクラウドロボティクスシステムのアプリケーション例を説明する説明図である。
【発明を実施するための形態】
【００１５】
（はじめに）
本発明は、クラウド・コンピューティングを前提としたロボット制御システムないし支援システムの中でも、特に、ロボットに対して高いスペックを必要としないシステムの実現を目的としている。例えば、ロボットに数々の高価なセンサを搭載すれば、当然に、高機能のロボットを実現できる（例えば、ロボットに３０００ドルのレーザセンサを搭載すれば、後述する太陽光による悪い影響を受けないで済む）。しかし、高機能だが高価なロボットは誰もが気軽に入手できるものではない。また、ロボットの高機能化を進めていったとしても、その性能を向上させるためのコストは、指数関数的に増大する（例えば、人間の能力を１００％として、ロボットの機能をゼロから９０％まで高めるためのコストよりも、９０％から９５％まで高めるためのコストのほうがずっと大きいということがあり得る）。
【００１６】
そこで、クラウドプラットフォームにおける処理に重点をおき、ロボットは低コストで実現する方向で、ロボットコンピューティング環境を実現することは得策と言えるが、残りの１０％をどう埋め合わせするかが次の問題となる。この問題に対しては、ロボットの動作や作業におけるトラブルに対し、クラウドプラットフォームの知識や他のユーザ（人間）の知識をうまく利用することがひとつの鍵となると、発明者は考えている。
特に、人間の知識は、現在のロボットとは異なり高度に集約されているので、人間ならば一目見ただけで（クラウドプラットフォームでは膨大な演算量を必要とする場合でも）、適切な対処方法を得られる場合も多い。
さらに、かかる人間の知識をロボットの将来の動作や作業に活かすことができれば、一層有益なクラウドロボティクスシステムを提供することができる。本発明は、かかる観点から発明者により創意工夫されたものである。
【００１７】
以下、本発明の一実施形態にかかるクラウドロボティクスシステム等について、図面を参照しながら詳細に説明する。
【００１８】
図１に、本発明の一実施形態にかかるクラウドロボティクスシステムの全体構成例を示す。
【００１９】
図１に示されるように、クラウドロボティクスシステム１０は、その一実施形態における構成として、クラウドプラットフォーム１１と、ユーザが使用する各種情報処理装置（図において、例示的に、携帯情報端末ないしタブレット端末１２、携帯電話１３、ＰＣ１４が示されている。以下、総称して「端末」とも言うこともある）と、ロボット２０１ａ〜２０１ｅとで構成されている。クラウドプラットフォーム１１、各種端末、及びロボット間は、図１に示されるように専用回線やインターネット等の公衆回線（有線の回線として、３７〜３９）で相互に通信可能に接続されている。また、回線は有線であっても無線であってもよく、無線の場合、携帯電話１３及び携帯情報端末ないしタブレット端末１２は、無線で図示しない基地局やアクセスポイント等を介してインターネット３９に乗り入れ、更に回線３８を介してクラウドプラットフォーム１１と相互に通信可能に接続される。
【００２０】
また、ロボット２０１ａ〜２０１ｅがドローンのような飛行型ロボットである場合には、図１に示されるような無線基地局ないしアクセスポイント４１、４２等を介してインターネット３９に接続される。つまり、ロボット２０１ａ〜２０１ｅもインターネット３９を介して、クラウドプラットフォーム１１や各種端末との相互通信が可能に構成されている。
ここで、アクセスポイントとは、ＰＣやスマートフォンなどの無線端末を相互に接続したり、他のネットワークに接続させたりするための無線機である。典型的には、ＯＳＩ参照モデルにおける第１層（物理層）及び第２層（データリンク層）の通信プロトコルで作動するデバイスである。
【００２１】
なお、本願の出願時点での携帯電話や携帯情報端末ないしタブレットは、パーソナルコンピュータ（ＰＣ）に比肩する処理能力（通信処理速度や画像処理能力等）を備えているものも多く、小型のコンピュータとも言うべきものである。
【００２２】
また、本発明の実施に必要なプログラムないしソフトウェアは、通常、ＰＣや携帯情報端末の記憶部におけるＨＤＤ、ＳＳＤ等にインストールないし記憶され、プログラムないしソフトウェアの実行時には、必要に応じて記憶部内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵにおいて演算実行される。
【００２３】
あるいは、ブラウザベースのコンピュータないし携帯情報端末を採用することもできる。この場合は、必要に応じて他のサーバやコンピュータから端末にプログラムが配信され、端末上のブラウザではこれを実行する、という構成になる。
【００２４】
また、クラウドプラットフォーム１１のハードウェア構成も、基本的にはＰＣを採用することができる。なお、本発明はこれに限定されるものではないが、クラウドプラットフォーム１１は、必要に応じてそのハードウェアスペックを上げるにあたり、複数のＰＣ（一例として、数十台〜数万台）を並列的に作動させることによって大規模データの処理に適した構成をとることもできる。
【００２５】
図２に、本発明の一実施形態にかかるクラウドロボティクスシステムにおけるロボットのバリエーション例を示す。本発明の一実施形態にかかるロボットは、図２（Ａ）に示された飛行型ロボット２０１（図１に示された飛行型ロボット２０１ａ〜２０１ｅに対応する）の他、自走式の掃除ロボット２０２や、自律歩行式の介助ロボット２０３など、多くのロボットを含むことができる。例えば、図２に示されたバリエーション以外にも、航空機、船舶、自動車、ロケット、人工衛星、探索機、救助ロボット等々、自律して作動ないし移動する様々な乗り物や電子機器、制御機械等が含まれる。
【００２６】
図３に、本発明の一実施形態にかかるロボット２０１〜２０３を構成するハードウェアの機能ブロック図を例示する。例示的に、ロボット２０１〜２０３の動作は、以下に説明するハードウェアの個々の動作、及びソフトウェアとこれらハードウェアとの連携動作によって実現されている。
【００２７】
図３において、ハードウェアブロック全体としてのロボット３００は、大別すると、移動手段となるプロペラ（飛行型ロボットの場合）や車輪（陸上走行ロボットの場合）を駆動するためのモータ部３０１と、アームや可動フック、ハンドなどを可動させるためのアクチュエータ部３０２と、ＲＧＢカメラのほか、ＲＧＢ−Ｄカメラ、赤外線カメラなどからなるカメラ部３０３と、音声収録のためのマイク部３０４と、熱センサ、温度センサ、ガスセンサなどのセンシング部３０５と、各種信号制御のための制御部３０６と、比較・演算処理を行うためのＣＰＵ３０７と、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の記憶部３０８と、ランプ、スピーカ等の出力部３０９と、通信部３１０（無線、有線を問わない）と、時刻等を計時するための計時部３１１と、電源部３１２と、ジャイロ３１３と、ＧＰＳ３１４とからなる。
但し、ロボットの種別によって、これらの一部のデバイスは他のデバイスに代替されたり省略されたりすることがある。
【００２８】
また、電源部３１２としては、リチウムポリマー（Ｌｉ−Ｐｏ）バッテリーや水素燃料バッテリー等のバッテリーユニットが採用される。また、ジャイロ３１３には、特に飛行型ロボットの場合に必要とされる、（回転運動）加速度及び（併進運動）加速度を検出可能な慣性センサ（６軸）ユニットが採用される。また、ＧＰＳ３１４には、アンテナ及び受信機が一体的に実装された汎用型ＧＰＳユニットなどが採用される。
【００２９】
これらのモジュールは必要に応じて適宜通信バスや給電線（図３においては、便宜上各線が適宜区分された結線３９９としてひとまとめに表す）によって接続されている。
【００３０】
また、本発明の実施に必要なロボット３００上で実行されるプログラムないしソフトウェアは、通常、記憶部３０７を構成するハードディスクディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、フラッシュメモリ等にインストールないし記憶され、プログラムないしソフトウェアの実行時には、必要に応じて記憶部３０７内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵ３１２において演算実行される。
【００３１】
なお、演算実行は必ずしもＣＰＵ等の中央処理部３１２で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。
【００３２】
図４に、本発明の一実施形態にかかるクラウドロボティクスシステムにおける情報処理装置としてのタブレット端末１２の外観構成を示す。図４において、情報処理装置（タブレット端末）１２は、筐体部１２１とディスプレイ１２２と筐体１２１の下部中央部に設けられたハードウェアボタン１２３とからなる。ディスプレイ１２２は典型的には液晶ディスプレイ（ＬＣＤ）等で構成され、文字や静止画像や動画など様々な情報を表示することができる。また、ディスプレイ１２２にメニューボタンやソフトウェアキーボードを表示させ、これを指ないしタッチペン（不図示）等で触れることによりタブレット端末１２への指示（コマンド）とすることができる。この点で上記ハードウェアボタン１２３は必須の構成要素ではないが、本発明の説明の便宜上、一定の機能を担うボタンとして実装されている。もちろん、これらハードウェアボタン１２３を、ディスプレイ１２２の一部に表示させたメニューボタンで代替させることも可能である。
【００３３】
また、ディスプレイ１２２には、マルチタッチ入力パネルが含まれており、タッチ入力パネル上でのタッチ入力位置座標が入力デバイスインタフェース（不図示）を介してタブレット端末１２の処理系（ＣＰＵ）へ送信され処理される。そして、このマルチタッチ入力パネルは、パネルに対する複数の接触点を同時に感知することができるよう構成されている。この検出（センサ）については様々な方法で実現することができ、必ずしも接触センサに限られず、例えば、光学式のセンサを利用してパネルに対する指示点を抽出することも可能である。さらに、センサには、接触式のセンサや光学式のセンサのほか、人の肌の接触を感知する静電容量方式のセンサを用いることも可能である。
【００３４】
また、図４には現れていないが、タブレット端末１２は、マイクやスピーカを備えることもできる。この場合にはマイクより拾ったユーザの声などを判別して入力コマンドとすることも可能である。さらに、図４には現れていないが、タブレット端末１２の背面等には、ＣＭＯＳ等のカメラデバイスが実装されている。
【００３５】
さらに、タブレット端末１２や他の情報処理装置で実装可能なアプリケーション例として、３Ｄジェスチャーインタフェースがある。これは、外付けか、あるいは内蔵された小型モーションコントローラと、専用ソフトウェアとからなる３次元モーションキャプチャシステムである。
【００３６】
主として、指先や手の動きをキャプチャして解析し、コンピュータの指示操作とすることができる。典型的には、コントローラないしディスプレイ手前の一定の３次元空間において、ユーザの両手や指先の動きを高速で追跡し、その動きに応じたコマンドを様々なアプリケーションに対して体感的及び直接的に指示することができる。
【００３７】
例えば、地図アプリケーション上で指や手を大きく動かして地図を拡大／縮小させたり、ビューアに表示させた３次元オブジェクトを回転させたりすることができるほか、指先の動きを追跡して署名などの細かい筆跡をキャプチャすることも可能である。一例として、１００分の１ミリ程度の精度で指先等の動きを検知することができる。
【００３８】
また、他のインタフェースデバイスとして、頭部に装着するディスプレイ装置（ヘッドマウントディスプレイ）などのウェアラブルコンピュータを採用することも有効である。この場合、例えば、ロボットの視界をヘッドマウントディスプレイ等の画面に連動させることにより、このヘッドマウントディスプレイを装着したユーザの頭の動き（向き）とロボットの視界（向き）とを連動させることができる。
【００３９】
図５に、本発明の一実施形態にかかるタブレット端末１２を構成するハードウェアの機能ブロック図を例示する。タブレット端末１２の動作は、以下に説明するハードウェアの個々の動作、及びソフトウェアとこれらハードウェアとの連携動作によって実現されている。
【００４０】
図５において、ハードウェアブロック全体としてのタブレット端末５００は、大別すると、図４におけるハードウェアボタン１２３、ディスプレイ１２２に設けられたマルチタッチ入力パネル、マイク等で構成される入力部５０１と、プログラムやデータ等を記憶するためのハードディスク、ＲＡＭ及び／又はＲＯＭ等で構成される記憶部５０２と、プログラムによって様々な数値計算や論理演算を行うＣＰＵによって構成される中央処理部５０３と、ディスプレイ１２２等で構成される表示部５０４と、チップや電気系統等の制御を行うための制御部５０５と、インターネットにアクセスするためのスロットや光通信を行うためのポート、及び通信インタフェースから構成される通信インタフェース部５０６と、スピーカやバイブレーション、赤外線プロジェクター等の出力部５０７と、時刻等を計時するための計時部５０８と、ＣＭＯＳ等のイメージセンサや赤外線センサ、慣性センサ等からなるセンサ部５０９と、装置内の各モジュールに電源を供給するための電源部５１０とからなり、これらのモジュールは必要に応じて適宜通信バスや給電線（図５においては、便宜上各線が適宜区分された結線５９９としてひとまとめに表す）によって接続されている。
なお、センサ部５０９には、タブレット端末５００（１２）の位置を特定するためのＧＰＳセンサモジュールを含めることとしても良い。また、センサ部５０９を構成するＣＭＯＳ等のイメージセンサや赤外線センサ等によって検知された信号は、入力部５０１において入力情報として処理することができる。
【００４１】
また、本発明の実施に必要なタブレット端末５００上で実行されるプログラムないしソフトウェアは、通常、記憶部５０２を構成するハードディスクディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、フラッシュメモリ等にインストールないし記憶され、プログラムないしソフトウェアの実行時には、必要に応じて記憶部５０２内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵ５０３において演算実行される。
【００４２】
なお、演算実行は必ずしもＣＰＵ等の中央処理部５０３で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。
【００４３】
図６に、本発明の一実施形態にかかるクラウドプラットフォームの詳細な機能ブロック構成を示す。図６には、例示的に２つのクラウドプラットフォーム６００及び６５０が示されている。本発明は、これに限定されるものではないが、複数のクラウドプラットフォームを想定することができる。
【００４４】
クラウドプラットフォーム６００には、サーバ群６１０とサーバ群６２０とが含まれており、いくつかのデータベース６３１〜６３３を有している。
【００４５】
サーバ群６１０、６２０は、必ず２つというものではなく、１群のサーバであってもよいし、それ以上の数のサーバ群が含まれてもよい。同図では、サーバ群６１０及び６２０は、有線／無線を問わない回線６４１によって接続され、相互に通信可能に構成されている。
【００４６】
また、データベース６３１〜６３３についても、その数に制限はなく、適応的に増減させることができる。そして、これらデータベース６３１〜６３３に対しては、回線６４２〜６４５を介して、サーバ群６１０、６２０の双方からアクセス可能に構成されている。
さらに、データベース６３１〜６３３には、適宜プライバシが保護された情報が共有されている。また、データ形式とプロセスの定義が可能である（例えば、データベース６３３に、ロボットのタイプやスペック等の情報を予め登録しておくことができる）。
【００４７】
クラウドプラットフォーム６５０は、クラウドプラットフォーム６００から見た場合の他のクラウド資源（例えば、サード・パーティＡＰＩなど）である。クラウドプラットフォーム６５０も、クラウドプラットフォーム６００と同様に、適応的に増減可能なハードウェア及びソフトウェア資源で構成され、有線／無線を問わない双方向に通信可能な回線６４６によって接続されている。
同図中、クラウドプラットフォーム６５０は、例示的に、サーバ（群）６５１とデータベース６５２とを含み、相互に通信可能な回線６５３で接続されている。
【００４８】
クラウドプラットフォーム６００、６５０は、安全かつ容量可変なプラットフォームとして構築ないし構成される。
【００４９】
そして、これらのクラウドプラットフォーム（クラウド資源）に対しては、双方向の標準コミュニケーションインタフェース６９５を介して、様々なデバイスとコミュニケーションをとることができる。
【００５０】
同図中、様々なデバイスの例示として、ロボット６８１〜６８３、及び情報処理装置（端末）６８４が示されている。ロボット６８１〜６８３は、通常、クラウドプラットフォームと連携して動作するが、必要に応じてネットワーク異常を検出させ、異常が検出された場合には、完全かつ安全なスタンドアローンシステムないしデバイスへと切り替えるよう制御させることもできる。
【００５１】
また、情報処理装置（端末）は、ユーザや管理者が使用するものであるが、かかる情報処理装置を介して、例えばブラウザ経由のシステム構成変更や状態監視が可能である。さらには、クラウドプラットフォームを介して、ブラウザ経由のロボット監視や制御も可能である。
【００５２】
次に、図７（Ａ）及び図７（Ｂ）を参照して、本発明の一実施形態にかかるクラウドロボティクスシステムにおける処理ルーチン（処理サービスの構成要素）の基本概念を示す。
なお、処理サービスは、構成要素であるいくつかの処理ルーチンによって構成されている。以下、詳細に説明する。
【００５３】
図７（Ａ）は、シングルサービスとしての処理ルーチンのソフトウェア構成が例示されており、サービス７０は、サービスインタフェース７１１〜７１３を介して外部モジュールと通信可能な内部ソフトウェアモジュール７２０、７３０、及び７４０を含む（後述するが、内部ソフトウェアモジュール７２０は、サービスインタフェース７１１〜７１３と同様のインタフェースを介して他の外部モジュールとも通信可能に構成される）。
【００５４】
内部ソフトウェアモジュール７２０、７３０、及び７４０は、さらに詳細な役割分担として、ワーキングルーチン、失敗検出サブルーチン、及び救助要請ルーチンに区分される。以後、内部ソフトウェアモジュール７２０、７３０、及び７４０を、それぞれワーキングルーチン７２０、失敗検出サブルーチン７３０、及び救助要請ルーチン７４０とも呼ぶこととする。
【００５５】
ワーキングルーチン７２０は、外部ソフトウェアモジュールから受けたリクエストに従って主たるタスクを実行するソフトウェアモジュールである。後述するが、サービスインタフェース７１１〜７１３と同様のインタフェースを介して他の外部モジュールに対してリクエストを出すこともできる。
【００５６】
失敗検出サブルーチン７３０は、リクエストを受けたタスクの実行中にそのタスクが失敗したことを自身で判断することができるほか、外部モジュールからのフィードバック状況から外部モジュールに対するリクエストが失敗したことも判断することができる。
【００５７】
救助要請ルーチン７４０は、失敗と判断されたリクエストないしタスクについて、クラウドプラットフォーム等に救助を要請する（call for help）ソフトウェアモジュールである。この場合、必要に応じて、サービスインタフェース７１１〜７１３とは別にクラウドプラットフォーム等へ救助を要請するためのソフトウェアインタフェースを設けることとしても良い（救助要請は、クラウドプラットフォームを介して、端末７９１〜７９３へ伝達される。詳細については後述する）。
【００５８】
サービスインタフェース７１１〜７１３は、外部モジュールからリクエストを受けた場合のコミュニケーションインタフェースである（同様に、外部モジュールに対してリクエストを出す場合には、ワーキングルーチン７２０からリクエストが出される。２者間のコネクションの様子は、図７（Ｂ）を参照して後述する）。
【００５９】
そして、サービスインタフェース７１１は、外部モジュールからのリクエストを受けるためのインタフェースであり、サービスインタフェース７１２は、リクエストを出した外部モジュールに対してフィードバックを返すためのインタフェースであり、サービスインタフェース７１２は、リクエストを出した外部モジュールに対して結果（典型的には、真／偽といったバイナリ応答）を返すためのインタフェースである。
【００６０】
本発明の一実施形態にかかるクラウドロボティクスシステムでは、図７（Ａ）に示したシングルサービスを基本として、他のシングルサービスからリクエストを受けたり、別のシングルサービスへリクエストを出したりするといった関係を有機的に（ダイナミックに）構築しながら全体の処理を進めていくことが、大きな特徴となっている。
【００６１】
ここで、２以上のサービスがコネクション関係を構築して処理を進める場合には、リクエストを出すサービスは、ハイレベル・サービスとなり、リクエストを受けたサービスは、ローレベル・サービスとなる。
【００６２】
図７（Ｂ）に、かかるコネクション関係を構築したハイレベル・サービス及びローレベル・サービスの関係を示す。
【００６３】
図７に示された基本的なサービスコネクション構造におけるハイレベル・サービス７５０とローレベル・サービス７６０との間の典型的なやりとりは、次のモデルに従う。
（Ａ）必要に応じて、ハイレベル・サービス７５０内での初期化（Initialization）。この初期化には、ゴールの設定も含まれる。
（Ｂ）ハイレベル・サービス７５０からローレベル・サービス７６０へのリクエストまたはタスク要求（図７（Ｂ）において、ワーキングルーチン７５２０からサービスインタフェース７６１１へリクエストが送信される）。
（Ｃ）ローレベル・サービス７６０における処理。図７（Ｂ）には示さないが、ここで処理が、さらに詳細なタスクやリクエストに分解されて、さらにローレベルとなる他のサービスないしルーチンへ送られる場合もある（その場合は、ワーキングルーチン７６２０から外部サービスへリクエストが出される）。
（Ｄ）ローレベル・サービス７６０からハイレベル・サービス７５０へのフィードバック。ローレベル・サービス７６０で検知された状況が返される。
（Ｅ）ハイレベル・サービス７５０での判断。例えば、ゴールに向けたタスク処理の進行が好ましいかどうか（失敗したかどうか）、あるいは、外部の助け（Help）が必要かどうかの判断を行う。この場合、失敗の判断は、図７における失敗検出サブルーチン７３０、７５３０、７６３０によって判断され、外部の助けが必要と判断された場合の救助要請は、図７における救助要請ルーチン７４０、７５４０、７６４０によって実施される。
（Ｆ）ローレベル・サービス７６０からハイレベル・サービス７５０へのバイナリ応答（例えば、真(1)か偽(0)かの２値応答）
【００６４】
図７（Ａ）や図７（Ｂ）に示したモデルは、最もシンプルなモデルであり、もっと複雑な階層構造を伴ったモデルもあり得る（Fundamental Build Up Model）。例えば、３層構造のモデルや５層構造、それ以上の構造のモデルなどである。
【００６５】
また、ハイレベル・サービスは常にクラウドプラットフォーム側にあり、ローレベル・サービスは常にロボット側にあるというものでもない。双方がクラウドプラットフォーム側にある場合も、また逆に双方がロボット側にあるということもあり得る。あるいは、あるハイレベル・サービス（またはローレベル・サービス）の一部がクラウドプラットフォームにあって、他の一部はローレベル・サービスにあるということも有り得る。
【００６６】
さらに、クラウドプラットフォームにて生成されたハイレベル・サービスが、ロボットにあるローレベル・サービスにタスク要求（サービスコール）し、ロボットにてサービスを実行していく過程で、今度は、ロボットからクラウドプラットフォームへのタスク要求（サービスコール）を行うということもあり得る。
こうした、ハイレベル・サービス及びローレベル・サービスは、同時並行して動的に生成され、様々な階層構造をとり得る。
【００６７】
また、失敗の検知方法（失敗と判断する基準）には、特定イベントないしステータスが返ってきたことを検知することの他に、一定時間が経過しても応答がないこと（いわゆるタイムアウトしたこと）が含まれる。
【００６８】
図８は、図７を参照して説明したモデルに基づいて、さらに階層的な処理構造（レイヤ構造）を有することとなった、本発明の一実施形態にかかるクラウドロボティクスシステムにおける処理サービスの概念を例示したものである。
【００６９】
図８に示したモデルでは、４階層のレイヤ１〜４が存在している。レイヤ１には、終局的なサービスである「ゴールＧ」が設定され、レイヤ１よりもローレベルとなるレイヤ２には、「ゴールＧ」を達成するための３つのサービス２Ａ〜２Ｃが存在する。
そして、レイヤ２のうちのサービス２Ａからは、レイヤ２よりもさらにローレベルとなるレイヤ３におけるサービス３Ａが存在し、サービス２Ｂからは、レイヤ３におけるサービス３Ｂが存在している。
【００７０】
さらに、レイヤ３には、「ゴールＧ」を達成するための別のサービス３Ｃが存在する（なお、このサービス３Ｃは、サービス２Ａ〜２Ｃの生成時には存在しなかったものである。処理の詳細については後述する）。そして、サービス３Ｃからは、レイヤ３よりもさらにローレベルとなるレイヤ４におけるサービス４Ａが存在している。
【００７１】
ここで、図８に示されたモデルが適用される具体的な事例として、クラウドプラットフォームが部屋にいるロボットに対し「テーブルの上にあるコップを持って来なさい」というタスク実行命令（リクエスト、または、サービスコールとも言う。以下、同じ）を実行させることを挙げることができる。
【００７２】
このとき、レイヤ１のゴールＧは、
Ｇ：「テーブルの上にあるコップを持って来なさい」
であり、クラウドプラットフォームからロボットへのサービスコールである。
【００７３】
そして、レイヤ１のＧからレイヤ２へ分岐する３つのサービス２Ａ〜２Ｃには、例えば、それぞれ以下のサービスを対応付けることができる。いずれも、クラウドプラットフォームからロボットへのサービルコールである。
２Ａ：「テーブルを見つけなさい」
２Ｂ：「見つけたテーブルの上のコップを確認して持ちなさい」
２Ｃ：「コップを持ったまま帰って来なさい」
【００７４】
サービス２Ａを実行するロボットからクラウドプラットフォームへは、次のようなフィードバック１〜３が返される。
フィードバック１：「いま、部屋の中の物体を探しています」
フィードバック２：「椅子を発見しました」
フィードバック３：「タンスを発見しました」
【００７５】
今度は、レイヤ２のサービス２Ａ（テーブルを見つけなさい）をハイレベル・サービスとして、レイヤ３におけるローレベルとなるサービス３Ａが存在する。
３Ａ：「（画像の送信とともに）これはテーブルですか？」
これは、ロボットからクラウドプラットフォームへのサービスコールである。クラウドプラットフォームからロボットへは、Ｙｅｓ（真）又はＮｏ（偽）のバイナリ応答が返される。ここでは、Ｙｅｓ（真）が返され、ロボットは、サービス２Ｂ（見つけたテーブルの上のコップを確認して持ちなさい）を実行するものとする。サービス２Ｂを実行するロボットからクラウドプラットフォームへは、次のようなフィードバック４〜５が返される。
フィードバック４：「いま、テーブルの上の物体を探しています」
フィードバック５：「本を発見しました」
【００７６】
さらに、レイヤ２のサービス２Ｂ（テーブルの上のコップを確認して持ちなさい）をハイレベル・サービスとして、レイヤ３におけるローレベルとなるサービス３Ｂが存在する。
３Ｂ：「（画像の送信とともに）これはコップですか？」
これは、ロボットからクラウドプラットフォームへのサービスコールである。クラウドプラットフォームからロボットへは、Ｙｅｓ（真）又はＮｏ（偽）のバイナリ応答が返される。ここでは、Ｙｅｓ（真）が返され、ロボットは、サービス２Ｂ（見つけたテーブルの上のコップを確認して持ちなさい）をさらに実行しようとして、次のフィードバック６が返されるとする。
フィードバック６：「このコップをどのくらいの力で持てばいいか分かりません」
【００７７】
上記フィードバック６を受けたクラウドプラットフォームは、そのコップに対する力加減をデータベース上で探し出そうとするが見つからないものとする。そうすると、ロボットからは、
フィードバック６：「このコップをどのくらいの力で持てばいいか分かりません」
という同じフィードバックが返ってくるか、あるいは、しばらくフィードバックが返って来ないまま一定の時間が経過することとなる（やがて、タイムアウトとなる）。
【００７８】
この場合、クラウドプラットフォームでは、サービス２Ｂは、行き詰ったと判断し、一例としてサービス２Ｂを消滅させたあとに、新たなサービス３Ｃを生成する。サービス３Ｃは、クラウドプラットフォームが他のプラットフォームに問い合わせたか、他のユーザ（人間）に問い合わせた結果に基づいて検証した結果、新たなサービスコールとして生成されたものであり、ロボットに送信される。
３Ｃ：「そのコップを０．５Ｎ以上０．９Ｎ未満の力で持ちなさい」
【００７９】
そして、レイヤ３のサービス３Ｃをハイレベル・サービスとして、レイヤ４におけるローレベルとなるサービス４Ａが存在する。
４Ａ：「（画像を送信するとともに）この位置を持っていいですか？」
これは、ロボットからクラウドプラットフォームへのサービスコールである。ここでは、クラウドプラットフォームからロボットへは、Ｎｏ（偽）のバイナリ応答が返されるとする（その位置は、特に壊れやすい部分であるなどの理由による）。
【００８０】
このようにして、ロボットは、正しい位置を正しい力に持ち始め、次のようなフィードバック７〜９を逐次クラウドプラットフォームに返す。
フィードバック７：「いま、０．５Ｋｇで握っています」
フィードバック８：「いま、０．８Ｋｇで握っています」
フィードバック９：「いま、コップが持ち上がりました」
（この時点で、バイナリ応答として「真」が返される。タスクの完了である）
【００８１】
次に、ロボットは、レイヤ２のサービス２Ｃ（コップを持ったまま帰って来なさい）を実行し、次のようなフィードバック１０〜１４を逐次クラウドプラットフォームに返す。
フィードバック１０：「いま、方向転換しました。」
フィードバック１１：「現在、（Ｘ１，Ｙ１）にいます。帰還地点まで、１５ｍです。」
フィードバック１２：「現在、（Ｘ２，Ｙ２）にいます。帰還地点まで、８ｍです。」
フィードバック１３：「現在、（Ｘ３，Ｙ３）にいます。帰還地点まで、３ｍです。」
フィードバック１４：「いま帰還しました。」
（この時点で、バイナリ応答として「真」が返される。タスクの完了である）
【００８２】
また、図示しないが、別の事例として、「外泊出張をしている主人の自宅の安全を確保するセキュリティシステム」を挙げることができる。その場合の各レイヤ及び各サービスの構成は、次のとおりである。
【００８３】
レイヤ００１（次の終局ゴールが存在する）
００１Ｇ：外泊出張をしている主人の自宅の安全を確保する
【００８４】
レイヤ００２（００１Ｇから派生した次の３つのサービスが存在する）
００２Ａ：泥棒に入られないこと（不審人物のチェック）
００２Ｂ：火事に遭わないこと（隣家のチェックも含む）
００２Ｃ：台風やハリケーンによる被害を防ぐこと（気象情報のチェックなど）
【００８５】
レイヤ００３（００２Ａから派生した次のサービスが存在する）
００３Ａ：家の中を巡回しなさい
【００８６】
レイヤ００４（００３Ａから派生した次の３つのサービスが存在する）
００４Ａ：ルートＡで家の中を巡回しなさい
００４Ｂ：ルートＢで家の中を巡回しなさい
００４Ｃ：ルートＣで家の中を巡回しなさい
【００８７】
図９に、本発明の一実施形態にかかるクラウドロボティックスシステムの動作例を示す。理解の容易のために、上記の（「外泊出張をしている主人の自宅の安全を確保する」ためにクラウドロボティックスが実行するモデル）に基づいて、さらに具体的に説明する。また、この実施例におけるロボットが実装しているカメラデバイスの前提について、簡単に説明する。
【００８８】
（１）まず、同図中のロボットは、ナビゲーション用にＲＧＢ−Ｄカメラ（センサ）を実装しているものとする。このＲＧＢ−Ｄカメラ（センサ）からは、（ａ）ＲＧＢイメージ、（ｂ）深度情報、の二つのデータがストリーミングされる。これらのストリーミングデータは、ロボットを移動させるための「ナビゲーションサービス」において使用される。
（２）次に、移動環境において太陽光の影響を強く受けた場合には、センサからは空の値が送信されてくる。失敗検出サブルーチンは、この状態を（失敗として）検知する。
（３）救助要請ルーチンは、必要に応じて他のユーザへの救助要請を行うことができる。例えば、特定のユーザに対してこのロボットの遠隔制御を許可するなどである。許可されたユーザは、ＲＧＢイメージストリームだけを頼りに（つまり、深度情報無しで）、人間としての経験を活かしてこのロボットを遠隔制御する。
【００８９】
また、動作の概要を説明すると、同図中、時刻ｔ１〜ｔ４までは、ロボットがルートＡを巡回中に窓越しに発見した、ロボット自身が見たことのない人物の訪問についての問い合わせを行う動作例を示す。具体的には、その人物画像とともにクラウドプラットフォームへサービスコールをする。
【００９０】
そして、同図中、時刻ｔ５〜ｔ１１までは、ロボットがルートＢを巡回中に、ちょうど太陽光の差し込みや反射によるカメラの不具合（サチレーション現象）を起こし、前へ進めなくなったか、あるいは、無理に動くと危険な状態となった場合の救済措置を示す。具体的には、かかるトラブルに陥ったロボットは、クラウドプラットフォームに対し、ＲＧＢ情報は取得できるがＤ情報（深度情報）が取得できないので動けない（移動不可）というフィードバックを返す。この場合、クラウドプラットフォームでは、例えば、ＲＧＢイメージのみでロボットを移動させる制御プログラムを有していればこのプログラムを起動してクラウド側からロボットを制御するが、さもなければ、広くユーザに問い合わせを行う。そして、この問い合わせに対し、複数のユーザからの提案があった場合、クラウドプラットフォームはそれらの提案を検証して、一例として、１人のユーザにロボットのテレオペレーションを許可する。ロボットは、ユーザのテレオペレーションにより、カメラの調整と共に、飛行ルートの変更（太陽光の影響を受けないような高度に変更など）を行い、トラブルを解消する。その操作内容や改善状況は学習され、次の日にも活用される。つまり、次の日に、ルートＢを巡回するロボットは、同じ時刻に同じ位置に差し掛かった時に、前日と同じようにカメラが太陽光の差し込みや反射で見えなくなるというトラブルに遭遇するが、前日の学習の結果、適切なカメラ調整及び／又は飛行高度の変更を行い、このトラブルを上手く回避する。
【００９１】
図９の時刻ｔ１において、クラウドプラットフォームからロボットへサービスコール１（「ルートＡで家の中を巡回しなさい」というリクエスト）が送信される（ステップＳ９０１）。
【００９２】
次に、時刻ｔ１〜ｔ２において、ロボットにてリクエストが実行され、逐次フィードバックがクラウドプラットフォームに送られる（ステップＳ９０２）。例えば、ロボットは主人の自宅の内部を警備し、一定時間ごとにプラットフォームへ自身の位置と周囲の状況とを報告する。
【００９３】
時刻ｔ２になると、ロボット自身では解析できない人物の訪問があったので、クラウドプラットフォームに対し、屋内から窓越しに撮影した画像の解析を依頼する（ステップＳ９０３のサービスコールＡ）。例えば、ロボットは、見慣れない制服を着た人物を「もしかしたら不審者ではないか」という疑問をもって、その人物の画像（動画像でも良い）をクラウドプラットフォーム送信するとともに画像認識等の解析を依頼する。
【００９４】
時刻ｔ２〜ｔ３まで、クラウドプラットフォームにて、ロボットから送られてきた画像（ないし動画像）に対する物体認識処理等を実施し、画像に写しこまれた人物が正規のポストマン（postman）であることを認識する。見慣れない制服を着た人物でも「正当な訪問者の来訪は認める（ので、特に警戒措置は採らない）」との判断をする（ステップＳ９０４）。
【００９５】
時刻ｔ３になると、クラウドプラットフォームでの解析処理が完了し、ロボットへバイナリ応答が返信される（ステップＳ９０６）。この場合、特に問題が無いので、真（True）が返される。
【００９６】
時刻ｔ３〜ｔ４まで、ロボットにてサービスコール１のサービス（ルートＡの巡回）が継続され、逐次フィードバックがクラウドプラットフォームに送られる（ステップＳ９０７）。
【００９７】
時刻ｔ４になると、ルートＡの巡回が終わったので、ロボットはクラウドプラットフォームに完了報告を行う（真（True）のバイナリ応答が返される）。
【００９８】
時刻ｔ４において、クラウドプラットフォームでは、今回のロボットとのやりとりから得た新たなデータが集積及び保存され（ステップＳ９０９）、データベースの再構築が実施される（ステップＳ９１０）。
【００９９】
次に、時刻ｔ５以降は、クラウドプラットフォームがヘルプを必要とする場合の動作例を示す。
【０１００】
まず、時刻ｔ５において、クラウドプラットフォームからロボットへサービスコール２（ルートＢで家の中を巡回しなさい）が送信される（ステップＳ９５１）。
【０１０１】
時刻ｔ５〜ｔ６まで、ロボットにてリクエストが実行され、逐次フィードバックがクラウドプラットフォームに送られる（ステップＳ９５２）。例えば、ロボットは、主人の自宅の内部を警備し、一定時間ごとにプラットフォームへ自身の位置と周囲の状況とを報告する。
【０１０２】
時刻ｔ６になると、ルートＢに沿って家の中を巡回しているロボットが、太陽光の差し込みや反射などにより視界が遮られ、何も見えなくなり前進することが困難となったので、ＲＧＢ情報は取得できるがＤ情報（深度情報）が取得できないので動けない（移動不可）というフィードバックをクラウドプラットフォームへ返す（ステップＳ９５３）。
【０１０３】
時刻ｔ６〜ｔ７まで、クラウドプラットフォームにて、ロボットからのフィードバックに応じてデータベースを参照するなどして（例えば、ＲＧＢイメージのみでロボットを移動させる制御プログラムがあればそれを起動して）解決を試みるが、適切な処置が見つからない（ステップＳ９５４）。
【０１０４】
そこで、時刻ｔ７において、クラウドプラットフォームは、他のクラウドプラットフォームか、あるいは、他のユーザ（人間）に対するヘルプ要請が必要と判断する。
【０１０５】
次に、時刻ｔ７〜ｔ８まで、クラウドプラットフォームは、どのような問い合わせをすれば良いか等の検討処理を行う（ステップＳ９５５）。例えば、他のクラウドプラットフォーム（例えば、図６の６５０）に問い合わせるか、あるいは、後述するように広くユーザ（人間）に問い合わせするかなどである。
【０１０６】
時刻ｔ８において、クラウドプラットフォームは、第三者（他の人間のユーザ）に広く問い合わせる方が良いと判断し、クラウドプラットフォームとネットワークを介して接続され得る多くのユーザ端末（情報処理装置）に問い合わせを行う（ステップＳ９５６）。
例えば、ロボットから送られた位置及び経路地図、現場の画像ないし映像等を配信し、「この状態でロボットはどのように進めば良いでしょうか？」といった問い合わせを行う。このとき、必要に応じて、プライバシを確保するための処理が施される（図１３〜図１４を参照して後述する）。
【０１０７】
ここで、ロボットが自身の移動のために使用するカメラは、深度情報を得られる単体のＲＧＢ−Ｄカメラないしセンサであり、上述の太陽光の反射等によるフレアが起こった場合には、この深度情報が得られなくなる。一方で、通常のＲＧＢカメラから得られるＲＧＢイメージについては、上述のフレアの影響がさほど大きくない場合があり、こうした場合に、通常のＲＧＢイメージによる現場の画像ないし映像等を他のユーザ（人間）が見て状況判断可能であることは、充分に期待できる。
【０１０８】
時刻ｔ８〜ｔ９まで、クラウドプラットフォームからの問い合せに対し、１以上のユーザから回答あるいはアドバイスが返される（ステップＳ９５７）。例えば、「カメラ（ＲＧＢ−Ｄセンサ）をこのように調整すれば良い」とか、「こういったルートで進めば良い」とか、「高度を下げると太陽光の影響は少なくなる」などといったアドバイスが送られてくる。
【０１０９】
次に、時刻ｔ９〜ｔ１０まで、クラウドプラットフォームでは、時刻ｔ８〜ｔ９までに寄せられた１以上のユーザからのアドバイスを検証し（ステップＳ９５８）、その内の１人のユーザＰに対してテレオペレーションを許可する（ステップＳ９５９）。
【０１１０】
時刻ｔ１０〜ｔ１１まで、テレオペレーションを許可されたユーザＰは、ロボットをテレオペレートしてトラブルを回避する（ステップＳ９６０）。例えば、ロボットのカメラの調整を行い、あるいは、飛行高度を適切に下げるなどして、ロボットの（ＲＧＢ−Ｄセンサによる）視界を良好にし、そのエリアの移動をユーザによる手動で切り抜ける。
【０１１１】
次に、時刻ｔ１１において、ロボットからクラウドプラットフォームへトラブルを無事に回避したことが報告される（ステップＳ９６１）。クラウドプラットフォームでは、これまでに集積した情報を新たな知識として整理及び記憶され（ステップＳ９６２）、必要に応じてデータベースが再構築される（ステップＳ９６３）。
【０１１２】
例えば、クラウドプラットフォームでは、今回ロボットがトラブルに陥った日時や場所、及びトラブルの状況（深度情報が空の値になったこと。つまり、太陽光による影響を強く受けたこと）、並びに、このトラブルに対して他のユーザが取った措置（カメラの設定を変えたとか、飛行高度を変えたなどの操作履歴）をデータベース化して、検索可能に保存する。
【０１１３】
クラウドプラットフォームにおける上述のステップＳ９６２〜ステップＳ９６３までの処理（学習処理）によって、ロボットは（他のロボットであっても）、翌日同じ時間帯に同じエリアを通過する場合であっても、既にデータベースには、同じ様な状況でのトラブル回避方法がデータベース化されているので、今回と同じようなトラブルに見舞われることなく、学習内容に基づいて事前にＲＧＢ−Ｄセンサの調整や飛行高度などを適切に変更するなどしてこのエリアを無事に通過することができる。
【０１１４】
図１０は、本発明の一実施形態にかかるクラウドロボティックスシステムのアプリケーション例を示す。
【０１１５】
図１０（Ａ）では、２台のカメラ付きロボット１００１、１００２が、相互に連携をとって、ルーム１００３の３次元空間データを収集し、クラウドプラットフォーム上に仮想空間を構築していく様子を示している。同図中、白い部分（白く欠けている部分）は、ロボット１００１ないし１００２によるキャプチャが未だ行われていない部分である。カメラ付きロボット１００１または１００２が一度キャプチャした部分については、基本的に他方のロボットによるキャプチャは不要である。
したがって、２台より３台、３台より４台のロボットによるキャプチャ作業を行ったほうが、全体の仮想空間を早く構築できる。
【０１１６】
次に、図１０（Ｂ）では、図示しない多数のカメラ付きロボットが、ある建物の構内を相互に連携しながら迷路のようになっている構内の３次元構造をクラウドプラットフォーム上に構築している様子を示す。同図では、構内のあるフロアの構造が部分的に解析されており、ほぼ平行に配置される通路１０１１、１０１２と、通路１０１１、１０１２と連結するルーム１０１３、並びに、他の通路１０１４〜１０１６の構造解析が進められている。
【０１１７】
図１０（Ｂ）では、通路１０１４及び１０１５は、仕切りを介して分断されていることが分かっている。一方で、通路１０１５及び１０１６は、仕切りなしに連通していることが分かっている。多数のカメラ付きロボットによる解析は継続され、通路１０１４と１０１５との間にある仕切りには開閉可能なドアが存在することが判明するかもしれないし、他の通路同士の接続関係も明らかになっていくであろう。
【０１１８】
各ロボットから収集されたデータは、クラウドプラットフォームに収集されて、構内の３次元構造データとして整理・保存されていく。
【０１１９】
図１１及び図１２は、本発明の他の実施形態にかかるクラウドロボティクスシステムのアプリケーション例を示す。具体的には、ある構内をロボットが探索し、入口（Start）から出口（Goal）までの道順（行き方）をクラウドプラットフォーム上にてデータベース化しようとして迷子になり、ユーザ（人間）による救助（ヘルプ）を受ける様子が示されている。
【０１２０】
なお、図１１及び図１２に示されたアプリケーション例は、あくまで本発明の理解のために、あえて２次元モデルに基づいて説明されている。つまり、現在のコンピュータのパフォーマンスならば、かかる２次元の迷路の探索を行ってロボットを確実に入口（Start）から出口（Goal）まで誘導することは容易いことである。現実的には、各フロアが複雑な迷路のような構造になった高層ビルの中を１階から高層階のある地点までロボットに探索させるような事例が適切と言えるかもしれない（計算量は、２次元の場合と比べて指数関数的に増大するため）。
しかしながら、この実施例では、あくまで本発明の理解のために、簡素化された２次元モデルに基づいて説明を進める。
【０１２１】
まず、図１１（Ａ）には、ある構内をロボットが探索し、入口（Start）から出口（Goal）までの道順（行き方）をクラウドプラットフォーム上にてデータベース化しようとして、地点Ｋで行き止ってしまった様子が示されている（×印がロボットの現在位置である）。
ロボットは、地点Ｋにおいて、クラウドプラットフォームに対し、「ここから先への道順が分かりません」とのフィードバックを返す。
【０１２２】
クラウドプラットフォームでは、ロボットのフィードバックに基づいて、ロボットが迷子になったものと判断する（一例として、同じフィードバックを返してくるか、一定時間内に次のフィードバックが返されないことなどにより判断）。
【０１２３】
クラウドプラットフォームでは、自身のデータベースにより、この構内についての他の情報を検索するが見当たらず、他のクラウドプラットフォームに問い合わせるが、それでも有益な情報は得られないものとする。
【０１２４】
そこで、クラウドプラットフォームは、他のユーザ（人間）に救済を要請することを決定する。
【０１２５】
次に、クラウドプラットフォームは、ロボットから提供されたデータに基づいて構築した地図と、これまでのロボットの探索によって作成した道順（図１１（Ａ）中のＳｔａｒｔから地点Ａ→Ｂ→Ｃ→Ｄ→Ｅ→Ｆ→Ｇ→Ｈ→Ｉ→Ｊ→Ｋへと続く点線の経路）とが示された視覚情報を１以上のユーザの端末（情報処理装置）へ送る。
【０１２６】
クラウドプラットフォームから問い合わせを受けた１以上のユーザは、自身の端末（情報処理装置）のディスプレイ上に示される、地図、ロボットの現在位置及びロボットのこれまでの経路（図１１（Ａ））に対し、アドバイスをする。
【０１２７】
このアドバイスは、ユーザにとって必ずしも強制的なものではないが、アドバイスによってある種のポイントを付与したり、ゲーミフィケーションの要素を実装したりすることにより、アドバイスの件数を増やすことができるであろう。
【０１２８】
図１１（Ｂ）には、ユーザが道順ないし経路を直接操作によってアドバイスする場合の例が示されている。同図において、ユーザは、自身の端末に表示された視覚情報（視覚データ）のうち、ロボットのこれまでの経路に対して、直接操作により、さらに適切な経路となるように修正してアドバイスすることができる。
【０１２９】
例えば、経路うちの辺の途中の点１１０１を指示して上下に移動させたり、他の点１１０２を左右に移動させたり、経路のうちの途中の他の点１１０３を指示して、斜め方向に上下左右に移動させたり、終点１１０４を指示して上下左右に移動させるなどである。
【０１３０】
この他にも、ユーザは、経路中の任意の点をつまんで移動させたり、延長／短縮したりすることにより、新たな経路を再構成してクラウドプラットフォーム（あるいはロボット）へのアドバイスとすることができる。
【０１３１】
なお、この事例では、２次元平面における経路データの編集ないし修正例にフォーカスして説明したが、もし、３次元空間における経路データを編集ないし修正する場合には、３Ｄジェスチャーインタフェースを介した体感的かつ直接的な指示方法を採用することもできる。
【０１３２】
図１２（Ａ）〜（Ｃ）には、図１１（Ａ）に示される視覚情報に対し、図１１（Ｂ）に例示された編集ないし修正方法によって他のユーザからアドバイスされてきた様々な経路が示されている。
クラウドプラットフォームでは、これらのアドバイスを検証して、どのアドバイスが最も適切かを判断し、最適なアドバイスをロボットに送信する。また、必要に応じて最適なアドバイスをしたユーザに対して、迷子になったロボットのテレオペレーションを許可することもできる。
【０１３３】
図１２（Ａ）では、図１１（Ａ）に示された経路がユーザＵ１によって修正され、Ｓｔａｒｔから地点Ａ→Ｂ→Ｃ→Ｄ→Ｅ→Ｆ→Ｇ→Ｈ→Ｎへと続く点線の経路が最適なルートとしてアドバイスされている。
【０１３４】
クラウドプラットフォームでは、ユーザＵ１によるこのアドバイスを検証し、例えば、これまでに構築された構内データを参照して、今回新たに示された経路の状況を検証し、例えば、地点Ｈ〜Ｎまでの通路には階段があり（同図中、一点破線で段差を表現したエリアである）、この区間は現在迷子になっているロボットのスペックでは走行ができないことを導き出す。
この場合、図１２（Ａ）に示された経路は、採用されない。
【０１３５】
次に、図１２（Ｂ）では、図１１（Ａ）に示された経路がユーザＵ２によって修正され、Ｓｔａｒｔから地点Ａ→Ｂ→Ｃ→Ｌ→Ｍ→Ｎへと続く点線の経路が最適なルートとしてアドバイスされている。
【０１３６】
クラウドプラットフォームでは、ユーザＵ２によるこのアドバイスを検証し、例えば、これまでに構築された構内データを参照して、今回新たに示された経路の状況を検証し、例えば、地点Ｃ〜Ｌまでの通路の幅は、ロボットの幅よりも狭いので、この区間は走行できないことを導き出す。
この場合、図１２（Ｂ）に示された経路は、採用されない。
【０１３７】
次に、図１２（Ｃ）では、図１１（Ａ）に示された経路がユーザＵ３によって修正され、Ｓｔａｒｔから地点Ａ→Ｂ→Ｃ→Ｄ→Ｅ→Ｆ→Ｍ→Ｎへと続く点線の経路が最適なルートとしてアドバイスされている。
【０１３８】
クラウドプラットフォームでは、ユーザＵ３によるこのアドバイスを検証し、例えば、これまでに構築されたデータを参照して、今回新たに示された経路の状況を検証し、特に問題点は見当たらないことが確認される。
【０１３９】
そうして、図１２（Ｃ）に示された経路が採用されてロボットへ送信される。ロボットは、クラウドプラットフォームから送られた経路（図１２（Ｃ）の経路）に従って、無事に出口（Goal）に到達することができる。
なお、クラウドプラットフォームは、必要に応じて、適宜ユーザＵ３に対してこのロボットのテレオペレーションを許可することができる。
【０１４０】
図１３及び図１４は、さらに他のアプリケーション例を示すが、特に、クラウドプラットフォームから他のユーザに示される画像の少なくとも一部を加工し、画像に含まれる物体や人物のプライバシを保護する例を示している。
【０１４１】
図１３（Ａ）は、ある建物の入口（ドア）１３１９が写し込まれた画像１３１である。ドア１３１９の左には、プレート１３１１が設置されている。クラウドプラットフォームは、ロボットがこのドアの開け方が分からずに問い合わせを受け、自身でも解決できずに、この画像を多くのユーザに送信して、ドアの開け方を問い合わせするために、画像１３１として切り出している（なお、図１３（Ｂ）の画像１３２、図１３（Ｃ）の画像１３３は、後述するように画像１３１の一部を加工したものである）。
【０１４２】
図１３（Ａ）に示された画像１３１は、一切加工されていない画像であるのに対し、図１３（Ｂ）に示された画像１３２は、プライバシ保護のため、プレート部分にモザイク処理１３２１が施されている。さらに、ドア１３２９は、実際のドア１３１１の色（青）とは異なる着色処理（例えば、緑）が施されている。
また、図１３（Ｃ）に示された画像１３３は、ドア１３３９以外の物体や部分等に対しては、問い合わせ事項には直接関係ないものとして、隠ぺい処理１３３１及び１３３２が施されている。この隠ぺい処理は、隠ぺいの対象となるエリアの透過度を変えることのほか、図１３（Ｂ）のようなモザイク処理をしたり、他の模様で完全に隠ぺいしたりするなど、様々な加工を行うことができる。
また、上述のように、ユーザに見せるドアの色を変えたり、他のオブジェクトの色を実際の色とは異なる色に着色したりすることもできる。
【０１４３】
図１４（Ａ）及び（Ｂ）は、ある人物が写し込まれた画像である。例示的に、人物１４０１は警官であり、人物１４１１はポストマンである。
【０１４４】
クラウドプラットフォームは、ロボットがこれらの人物の特定ができずに問い合わせを受け、自身でも解決できずに、この人物画像を多くのユーザに送信して、人物画像１４０２、１４１２として切り出している。
【０１４５】
ここで、図１４（Ａ）に示された画像１４０２では、人物の顔部分にモザイク処理１４０３が施され、同様に、図１４１２でも、人物の顔部分にモザイク処理１４１３が施されている。
このようなモザイク処理により、人物のプライバシが保たれる。もちろん、同図で示したモザイク処理のほか、漫画のキャラクタや動物の顔を覆いかぶせるによる処理をしたり、他の模様で完全に隠ぺいしたりするなど、様々な加工を行うことができる。
【０１４６】
以上、具体例に基づき、クラウドロボティクスシステム、情報処理装置等の実施形態を説明したが、本発明の実施形態としては、システム又は装置を実施するための方法又はプログラムの他、プログラムが記録された記憶媒体（一例として、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、ハードディスク、メモリカード）等としての実施態様をとることも可能である。
【０１４７】
また、プログラムの実装形態としては、コンパイラによってコンパイルされるオブジェクトコード、インタプリタにより実行されるプログラムコード等のアプリケーションプログラムに限定されることはなく、オペレーティングシステムに組み込まれるプログラムモジュール等の形態であっても良い。
【０１４８】
さらに、プログラムは、必ずしも制御基板上のＣＰＵにおいてのみ、全ての処理が実施される必要はなく、必要に応じて基板に付加された拡張ボードや拡張ユニットに実装された別の処理ユニット（ＤＳＰ等）によってその一部又は全部が実施される構成とすることもできる。
【０１４９】
本明細書（特許請求の範囲、要約、及び図面を含む）に記載された構成要件の全て及び／又は開示された全ての方法又は処理の全てのステップについては、これらの特徴が相互に排他的である組合せを除き、任意の組合せで組み合わせることができる。
【０１５０】
また、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された特徴の各々は、明示的に否定されない限り、同一の目的、同等の目的、または類似する目的のために働く代替の特徴に置換することができる。したがって、明示的に否定されない限り、開示された特徴の各々は、包括的な一連の同一又は均等となる特徴の一例にすぎない。
【０１５１】
さらに、本発明は、上述した実施形態のいずれの具体的構成にも制限されるものではない。本発明は、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された全ての新規な特徴又はそれらの組合せ、あるいは記載された全ての新規な方法又は処理のステップ、又はそれらの組合せに拡張することができる。
【符号の説明】
【０１５２】
１０  クラウドロボティクスシステム
１１  クラウドプラットフォーム
１２  タブレット端末（情報処理装置の一形態）
１３  携帯電話（情報処理装置の一形態）
１４  ＰＣ（情報処理装置の一形態）
２０１ａ〜２０１ｅ  飛行型ロボット（ロボットの一形態）
４１、４２  アクセスポイント（ルータ等）
３７、３８  通信回線
３９  公衆回線（専用線、インターネット等）
【図１】
2017047519.tif 000003
【図２】
2017047519.tif 000004
【図３】
2017047519.tif 000005
【図４】
2017047519.tif 000006
【図５】
2017047519.tif 000007
【図６】
2017047519.tif 000008
【図７】
2017047519.tif 000009
【図８】
2017047519.tif 000010
【図９】
2017047519.tif 000011
【図１０】
2017047519.tif 000012
【図１１】
2017047519.tif 000013
【図１２】
2017047519.tif 000014
【図１３】
2017047519.tif 000015
【図１４】
2017047519.tif 000016
【手続補正書】
【提出日】平成28年3月4日(2016.3.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
クラウドプラットフォームとロボットとを備えるクラウドロボティクスシステムであって、
前記クラウドプラットフォーム及び前記ロボットは、それぞれ、タスクを実行するための共通のサービスインタフェースを有するサービスモジュールを実行するものであり、
前記共通のサービスインタフェースは、少なくともタスクの実行を依頼するためのリクエストを授受するためのインタフェースと、前記タスクの実行の状況を報告するためのフィードバックを授受するためのインタフェースとを有し、
前記サービスモジュールのそれぞれは、少なくとも、前記タスクを実行するためのワーキングルーチンと、前記タスクの実行が失敗したかどうかを検出するための失敗検出サブルーチンとを有しており、
前記クラウドプラットフォーム及び前記ロボットは、前記共通のサービスインタフェースを有する前記サービスモジュールを備えることにより、前記タスクの実行が開始され完了するまでの間に、
（１）前記クラウドプラットフォームが出した前記リクエストを前記ロボットが受けること、及び、
（２）前記ロボットが出した前記リクエストを前記クラウドプラットフォームが受けることが双方向に実行されることを特徴とするシステム。
【請求項２】
前記システムは、ユーザインタフェースを備えたユーザ端末をさらに備えるとともに、前記サービスモジュールは、外部に救助を要請するための救助要請ルーチンをさらに備え、
前記失敗検出サブルーチンが前記タスクの実行が失敗したことを検出した場合に、前記救助要請ルーチンにより前記ユーザ端末へ救助を要請する
ことを特徴とする請求項１に記載のシステム。
【請求項３】
前記クラウドプラットフォームは、前記ユーザ端末に対して前記ロボットに対する操作を許可することを特徴とする請求項２に記載のシステム。
【請求項４】
前記ロボットに対する操作を許可することは、前記ユーザ端末のディスプレイに示された視覚情報に対する直接操作による操作許可であることを特徴とする請求項３に記載のシステム。
【請求項５】
前記ユーザインタフェースは、３Ｄジェスチャーインタフェースであることを特徴とする請求項２〜４のいずれか１項に記載のシステム。
【請求項６】
前記ユーザインタフェースは、ヘッドマウントディスプレイを含むことを特徴とする請求項２〜５のいずれか１項に記載のシステム。
【請求項７】
前記救助を要請した前記ユーザ端末から得た情報を検索可能にデータベース化することを特徴とする請求項２〜６のいずれか１項に記載のシステム。
【請求項８】
前記データベース化された前記情報は、前記救助を要請することとなった前記ロボットの状況が含まれ、前記情報は、前記状況に陥った他のロボットの救助に利用されることを特徴とする請求項２〜７のいずれか１項に記載のシステム。
【請求項９】
前記救助要請を行うために前記ユーザ端末に表示させるための画像が送信され、前記画像の少なくとも一部にはプライバシ保護のための処理がなされることを特徴とする請求項２〜８のいずれか１項に記載のシステム。
【請求項１０】
クラウドプラットフォームとロボットとを備えるクラウドロボティクスシステムで実行されるコンピュータプログラムであって、前記システムで実行されたとき、
前記クラウドプラットフォーム及び前記ロボットに、それぞれ、タスクを実行するための共通のサービスインタフェースを有するサービスモジュールを実行させる処理ステップと、
前記共通のサービスインタフェースを介して、前記サービスモジュールに、少なくともタスクの実行を依頼するためにリクエストを授受させる処理ステップ、及び前記タスクの実行の状況を報告するためのフィードバックを授受させる処理ステップと、
を実行し、ここにおいて、
前記サービスモジュールは、ワーキングルーチンに前記タスクを実行させる処理ステップと、失敗検出サブルーチンに前記タスクの実行が失敗したかどうかを検出させる処理ステップとをさらに有し、
前記クラウドプラットフォーム及び前記ロボットは、前記共通のサービスインタフェースを有する前記サービスモジュールを備えることにより、前記タスクの実行が開始され完了するまでの間に、
（１）前記クラウドプラットフォームが出した前記リクエストを前記ロボットが受けるステップ、及び、
（２）前記ロボットが出した前記リクエストを前記クラウドプラットフォームが受けるステップが双方向に実行される
ことを特徴とするプログラム。
【請求項１１】
前記システムは、ユーザインタフェースを備えたユーザ端末をさらに備えるとともに、前記サービスモジュールは、外部に救助を要請するための救助要請ルーチンをさらに備え、
前記失敗検出サブルーチンが前記タスクの実行が失敗したことを検出した場合に、前記救助要請ルーチンに前記ユーザ端末へ救助を要請させる処理ステップ
をさらに有することを特徴とする請求項１０に記載のプログラム。
【請求項１２】
前記クラウドプラットフォームに、前記ユーザ端末に対して前記ロボットに対する操作を許可させる処理ステップをさらに有することを特徴とする請求項１１に記載のプログラム。
【請求項１３】
前記ロボットに対する操作を許可させる処理ステップは、前記ユーザ端末のディスプレイに示された視覚情報に対する直接操作による操作を許可させる処理ステップであることを特徴とする請求項１２に記載のプログラム。
【請求項１４】
前記ユーザインタフェースは、３Ｄジェスチャーインタフェースであることを特徴とする請求項１１〜１３のいずれか１項に記載のプログラム。
【請求項１５】
前記ユーザインタフェースは、ヘッドマウントディスプレイを含むことを特徴とする請求項１１〜１４のいずれか１項に記載のプログラム。
【請求項１６】
前記救助を要請した前記ユーザ端末から得た情報を検索可能にデータベース化させる処理ステップをさらに有することを特徴とする請求項１１〜１５のいずれか１項に記載のプログラム。
【請求項１７】
前記データベース化された前記情報は、前記救助を要請することとなった前記ロボットの状況が含まれ、前記情報は、前記状況に陥った他のロボットの救助に利用されることを特徴とする請求項１１〜１６のいずれか１項に記載のプログラム。
【請求項１８】
前記クラウドプラットフォームに、
前記救助要請を行うために前記ユーザ端末に表示させるための画像を送信させる処理ステップと、
前記画像の少なくとも一部にプライバシ保護のための処理を実施させる処理ステップと
をさらに有することを特徴とする請求項１１〜１７のいずれか１項に記載のプログラム。