WO2022004412A1

WO2022004412A1 - 情報処理装置、情報処理方法、並びにプログラム

Info

Publication number: WO2022004412A1
Application number: PCT/JP2021/023052
Authority: WO
Inventors: 博隆石川; 諭渡辺
Original assignee: ソニーセミコンダクタソリューションズ株式会社
Priority date: 2020-07-01
Filing date: 2021-06-17
Publication date: 2022-01-06
Also published as: JPWO2022004412A1; CN116018814A; US20230319397A1

Abstract

本技術は、バッテリの残量に応じて、処理を適切に分担できるようにする情報処理装置、情報処理方法、並びにプログラムに関する。バッテリの残量または熱の少なくとも一方に応じて、モードを切り替えるモード切替部を備え、モード切替部は、第１の装置で所定の処理を実行する第１のモードと、第２の装置で所定の処理を実行する第２のモードとを切り替える。所定の処理は、ＡＩ機能による処理である。本技術は、例えば、監視カメラと監視カメラからのデータを配信するサーバから構成されるシステムに適用できる。

Description

情報処理装置、情報処理方法、並びにプログラム

　本技術は、情報処理装置、情報処理方法、並びにプログラムに関し、例えば、状況に応じた処理の分担を適切に行えるようにした情報処理装置、情報処理方法、並びにプログラムに関する。

　近年、街頭のいたるところに監視カメラ等が設置され、さらに、走行する車両にも、当該車両の周囲環境を撮像することができる車載カメラが搭載されており、様々な場所における撮像画像を容易に取得することができるようになってきている。また、監視カメラなどでは撮影された画像を解析することで、人を検出したり、特定の人を認識したりすることも行われている。

　これらのカメラのうち、バッテリから電力が供給されるカメラの場合、バッテリの残量が少なくなると、処理を行えなくなる可能性がある。特許文献１では、バッテリ残量に基づき、ビデオストリームの複雑さを調整することが提案されている。

特開2017-212744号公報

　バッテリの容量が低下した場合や、発熱などにより機能が低下してしまう状況が発生することを防ぐことが望まれている。

　本技術は、このような状況に鑑みてなされたものであり、機能が低下してしまうような状況が発生したときに、機能が低下しないように処理を適切に分担して行うことができるようにするものである。

　本技術の一側面の情報処理装置は、バッテリの残量または熱の少なくとも一方に応じて、モードを切り替えるモード切替部を備え、前記モード切替部は、第１の装置で所定の処理を実行する第１のモードと、第２の装置で前記所定の処理を実行する第２のモードとを切り替える。

　本技術の一側面の情報処理方法は、情報処理装置が、バッテリの残量または熱の少なくとも一方に応じて、第１の装置で所定の処理を実行する第１のモードと、第２の装置で前記所定の処理を実行する第２のモードとを切り替える。

　本技術の一側面のプログラムは、コンピュータに、バッテリの残量または熱の少なくとも一方に応じて、第１の装置で所定の処理を実行する第１のモードと、第２の装置で前記所定の処理を実行する第２のモードとを切り替える処理を実行させる。

　本技術の一側面の情報処理装置、情報処理方法、並びにプログラムにおいては、バッテリの残量に応じて、第１の装置で所定の処理を実行する第１のモードと、第２の装置で前記所定の処理を実行する第２のモードとが切り替えられる。

　なお、情報処理装置は、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。

　また、プログラムは、伝送媒体を介して伝送することにより、または、記録媒体に記録して、提供することができる。

本技術を適用したデータ配信システムの一実施の形態の構成を示す図である。センサデバイスの構成例を示す図である。サービスサーバの構成例を示す図である。認識モデルの生成について説明するための図である。配信データの一例を示す図である。前処理部が行う処理について説明するため図である。情報処理方法の一例について説明するための図である。センサデバイスの他の構成例を示す図である。サービスサーバの他の構成例を示す図である。モード切替の処理について説明するためのフローチャートである。モード切替の一例を示す図である。モード切替の一例を示す図である。モード切替の一例を示す図である。モード切替の一例を示す図である。モード切替の一例を示す図である。情報処理方法の一例について説明するためのフローチャートである。モード切替の開始に係わる処理について説明するための図である。モード切替の開始に係わる処理について説明するための図である。モード切替の開始に係わる処理について説明するための図である。パーソナルコンピュータの構成例を示す図である。車両制御システムの概略的な構成の一例を示すブロック図である。車外情報検出部及び撮像部の設置位置の一例を示す説明図である。

　以下に、本技術を実施するための形態（以下、実施の形態という）について説明する。

　＜データ配信システムの概略構成＞
　図１を参照して、本開示の実施の形態に係るデータ配信システム１の構成例を説明する。図１は、本開示の実施の形態に係るデータ配信システム１の概略的な機能構成を示したシステム図である。詳細には、図１に示すように、本実施の形態に係るデータ配信システム１は、複数のセンサデバイス１０ａ，１０ｂ，１０ｃ、サービスサーバ２０、複数のユーザデバイス３０ａ，３０ｂ，３０ｃ、および認証サーバ４０を主に含むことができる。

　これらの各装置は、例えば、図示しない基地局等（例えば、携帯電話機の基地局、無線ＬＡＮ（Local Area Network）のアクセスポイント等）を介してネットワーク（図示省略）に接続されることにより、データ配信システム１が構築されることとなる。なお、上記ネットワークで用いられる通信方式は、有線又は無線（例えば、第５世代通信システム、ＷｉＦｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等）を問わず任意の方式を適用することができるが、大容量のデータを安定して高速送信することができる通信方式を用いることができる。

　また、データ配信システム１に含まれるセンサデバイス１０やユーザデバイス（要求元）３０は、図１に図示されるようにそれぞれ３つであることに限定されるものではなく、本実施の形態に係るデータ配信システム１には、それぞれ３つ以上含まれていてもよい。すなわち、本実施の形態に係るデータ配信システム１は、複数のセンサデバイス１０を管理し、複数のユーザデバイス３０からの要求を受け付け、それらにデータを送信することができる。以下に、本実施の形態に係るデータ配信システム１に含まれる各装置の概略について説明する。

　＜センサデバイス＞
　センサデバイス１０は、設置された周囲環境のセンシングデータ（例えば、画像、音声等）を取得し、取得したセンシングデータから取得される配信データ（所定のデータ）を、後述するユーザデバイス３０等の外部装置に送信することができる。また、センサデバイス１０は、ＡＩ（Artificial Intelligence）機能が搭載されていることが望ましく、後述するサービスサーバ２０から送信された認識モデルに基づき、取得したセンシングデータが、ユーザからの要求（配信リクエスト）に該当するかどうかを認識することができる。センサデバイス１０は、センシングデータを扱う情報処理装置として機能する。

　例えば、センサデバイス１０は、自動車等の移動体に搭載された撮像装置（カメラ）や、ユーザの携帯するスマートフォンに搭載された撮像装置、自宅や店舗等に設置された監視カメラ等の撮像装置であることができ、この場合、センシングデータは画像となる。この場合、これら撮像装置は、設置された周囲に位置する被写体からの光を集光して撮像面に光像を形成し、撮像面に形成された光像を電気的な画像信号に変換することによって画像を取得することができる。

　なお、以下の説明においては、特段のことわりがない限りは、移動体とは、自動車、電気自動車、ハイブリッド電気自動車、自動二輪車、自転車、パーソナルモビリティ、飛行機、ドローン、船舶、ロボット（移動ロボット）、建設機械、農業機械（トラクタ）等であることができる。

　また、センサデバイス１０は、上述した撮像装置であることに限定されるものではない。例えば、センサデバイス１０は、被写体までの距離（深さ）を計測する深度センサ、周囲環境の音を集音するマイクロフォン等の集音装置、周囲環境の温度及び湿度を計測する温度センサ及び湿度センサ、河川等の水位を測定する水位センサ等であってもよい。

　なお、センサデバイス１０は、データ配信システム１に共通するインタフェース（データ転送形式、データ転送方法等）を持つものであれば、その内部構成については、基本的に限定されるものではない。従って、本実施の形態に係るデータ配信システム１は、仕様の異なる様々なセンサデバイス１０を取り込むことができる。なお、センサデバイス１０の詳細構成については後述する。

　＜サービスサーバ＞
　サービスサーバ２０は、後述するユーザデバイス３０から、上記センシングデータから生成され得る配信データの配信を要求する配信リクエストを受け付けるコンピュータである。またサービスサーバ２０は、センサデバイス１０やユーザデバイス３０とデータの授受を行い、処理する情報処理装置として機能する。

　またサービスサーバ２０は、複数の配信リクエスト（要求）を統合し、配信リクエストに応じた認識モデルを生成し、生成した認識モデルを上述したセンサデバイス１０へ送信することができる。当該認識モデルは、センサデバイス１０での認識に供されることとなるが、この詳細については後述する。

　また、サービスサーバ２０は、必要に応じて、センサデバイス１０から配信データを受信し、受信した配信データを、上記配信リクエストに該当するユーザデバイス３０へ送信することもできる。例えば、サービスサーバ２０は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random ACCESS Memory）等のハードウェアにより実現されることができる。なお、サービスサーバ２０の詳細構成につては後述する。

　＜ユーザデバイス＞
　ユーザデバイス３０は、ユーザによって携帯され、もしくは、ユーザの近傍に設置され、ユーザから入力された情報を受け付け、受け付けた当該情報を配信リクエストとしてサービスサーバ２０へ送信したり、配信リクエストに係る配信データを受信したりすることができる端末である。例えば、ユーザデバイス３０は、タブレット型ＰＣ（Personal Computer）、スマートフォン、携帯電話、ラップトップ型ＰＣ、ノート型ＰＣ等のモバイル端末、ＨＭＤ（Head Mounted Display）等のウェアラブルデバイスなど情報処理装置とすることができる。

　さらに詳細には、ユーザデバイス３０は、ユーザに向けて表示を行う表示部（図示省略）や、ユーザからの操作を受け付ける操作部（図示省略）や、ユーザに向けて音声出力を行うスピーカ（図示省略）等を有していてもよい。

　なお、ユーザデバイス３０には、例えば、データ配信システム１に共通するアプリケーション（アプリ）、もしくは、上述したサービスサーバ２０と共通する仕様を持つアプリケーションがインストールされることができる。ユーザデバイス３０は、上述のようなアプリケーションがインストールされることにより、データ配信システム１に共通する形式等を持つ、配信リクエストを生成し、送信したり、配信データを受け取ったりすることが可能となる。

　ユーザは、ユーザデバイス３０を介して、サービスサーバ２０へ配信リクエストを送信する。当該配信リクエストは、ユーザが配信を要求するデータの内容（データタイプ）等を指定する情報を含む。例えば、当該配信リクエストは、配信を要求する対象となるオブジェクト（例えば、顔、人物、動物、移動体、テキスト、道路（歩道、横断歩道、道幅、標識等）、ロゴ、バーコード等）と、オブジェクトに関するどのような情報（例えば、数量、速度、位置、状態、年齢、性別、特定した名前、推定結果等）を要求するのかを指定する情報（データタイプ）とからなるオブジェクト情報を含むことができる。

　また、当該配信リクエストは、配信データのデータフォーマット（例えば、画像、テキスト等）を指定するデータフォーマット情報を含むことができる。さらに、当該配信リクエストは、ユーザもしくはユーザデバイス３０の識別情報（ＩＤ（identification））を含むことができる。なお、上記配信リクエストには、サービスサーバ２０で認識モデルを生成する際に利用される各種データが含まれていてもよい（詳細は後述する）。

　上記配信リクエストは、データ配信システム１に共通するデータ形式を持つ。例えば、配信リクエストは、オブジェクト情報やデータフォーマット情報に対応する文字列や数字列を含むことができる。この場合、ユーザから高い頻度で要求されるオブジェクト情報やデータフォーマット情報については、対応する文字列や数字列を予め決定し、サービスサーバ２０が保有する記憶部（図示省略）にデータベース（図示省略）として格納する。

　そして、サービスサーバ２０は、上記データベースを参照することにより、配信リクエストに含まれる文字列等に対応するオブジェクト情報及びデータフォーマット情報を認識することができる。また、ユーザが所望するオブジェクト情報及びデータフォーマット情報に対応する文字列等が上記データベースに存在しない場合には、これらオブジェクト情報及びデータフォーマット情報は、上記配信リクエスト内で直接的に記述されてもよい。もしくは、この場合、ユーザが所望するオブジェクト情報及びデータフォーマット情報に対応する文字列を新たに決定して、決定した文字列等を、上記配信リクエスト及び上記データベースに記述してもよい。

　＜認証サーバ＞
　認証サーバ４０は、センサデバイス１０やサービスサーバ２０からそれぞれの認証情報（ＩＤ）を受信し、これらの各装置が、本実施の形態に係るデータ配信システム１によるサービスを提供する、もしくは提供される権限を有するか否かを判定するコンピュータである。さらに、認証サーバ４０は、権限を有する装置に対して、サービスへのアクセスを可能にするキーや、サービスを提供するもしくはサービスを提供されるためのコマンド等を送信する。

　そして、上記認証情報は、データ配信システム１に共通するデータ形式を持つものとする。すなわち、認証サーバ４０は、認証ＡＰＩ（Application Programming Interface）として用いられ、センサデバイス１０とサービスサーバ２０とを認証し、互いに紐づけることができる。本実施の形態に係るデータ配信システム１は、このような認証サーバ４０を組み込むことにより、当該データ配信システム１のセキュリティを確保し、各センサデバイス１０を、サービスサーバ２０を介して各ユーザデバイス３０と紐づけることができる。また、認証サーバ４０は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ等のハードウェアにより実現されることができる。なお、認証サーバ４０は、ユーザデバイス３０に対する認証を行ってもよい。

　なお、本実施の形態に係るデータ配信システム１においては、センサデバイス１０やサービスサーバ２０は、それぞれ単一の装置によって実現されていなくてもよく、有線又は無線の各種のネットワーク（図示省略）を介して接続され、互いに協働する複数の装置によって実現されてもよい。

　＜センサデバイスの詳細構成例＞
　次に、図２を参照して、本実施の形態に係るセンサデバイス１０の詳細構成を説明する。図２は、本実施の形態に係るセンサデバイス１０の機能構成例を示すブロック図である。詳細には、図２に示すように、センサデバイス１０は、センサ部１００と、測位部１１０と、処理部１３０と、記憶部１６０と、通信部１７０とを主に有する。以下に、センサデバイス１０の各機能ブロックについて順次説明する。

　センサ部１００は、センシングデータを取得し、取得したセンシングデータを後述する処理部１３０へ出力する。詳細には、センサデバイス１０が撮像装置であった場合には、センサ部１００は、被写体から発せられる光を集光する撮影レンズ及びズームレンズ等の撮像光学系、及び、ＣＣＤ（Charge Coupled Device）又はＣＭＯＳ（Complementary Metal Oxide Semiconductor）等の撮像素子を有することとなる。

　なお、センサ部１００は、センサデバイス１０内に固定されるように設けられていてもよく、センサデバイス１０に脱着可能に設けられていてもよい。

　また、センサ部１００は、撮像装置の他にも、深度センサとしてＴＯＦ（Time of Flight）センサ（図示省略）を含んでいてもよい。ＴＯＦセンサは、被写体からの反射光の戻り時間を直接的又は間接的に計測することにより、ＴＯＦセンサと被写体との間の距離及び凹凸等の形状情報（深度情報／画像）を取得することができる。さらに、センサ部１００は、集音装置（マイク）、温度センサ、気圧センサ、湿度センサ、風向風速センサ、日照センサ、降水量センサ、水位センサ等を含んでいてもよく、周囲環境からセンシングデータを取得することができれば特に限定されるものではない。

　測位部１１０は、配信リクエストに該当するセンシングデータが取得された際のセンサデバイス１０の測位データを取得し、取得した測位データを、処理部１３０（詳細には、データ生成部１４４）に出力する。例えば、当該測位データは、配信データとともに、後述する処理部１３０の配信部１４６により、ユーザデバイス３０へ送信されることとなる。

　測位部１１０は、具体的には、ＧＮＳＳ（Global Navigation Satellite System）受信機等であることができる。この場合、測位部１１０は、ＧＮＳＳ衛星からの信号に基づいて、センサデバイス１０の現在地の緯度・経度を示す測位データを生成することができる。また、例えば、ＲＦＩＤ（Radio Frequency Identification）、Ｗｉ－Ｆｉのアクセスポイント、無線基地局の情報等からユーザの相対的な位置関係を検出することが可能なため、このような通信装置を上記測位部１１０として利用することも可能である。なお、測位部１１０は、センサデバイス１０に設けられていなくてもよい。

　処理部１３０は、センサ部１００が取得したセンシングデータを処理し、配信データを生成する機能を有する。処理部１３０は、例えば、ＣＰＵやＧＰＵ（Graphics Processing Unit）等の処理回路や、ＲＯＭ、ＲＡＭ等により実現される。詳細には、図２に示すように、処理部１３０は、ＩＤ送信部１３２と、ｋｅｙ受信部１３４と、センサデータ取得部１３６と、前処理部１３８と、モデル取得部１４０と、認識部１４２と、データ生成部１４４と、配信部１４６とを主に有する。以下に、処理部１３０の有する各機能部の詳細について説明する。

　ＩＤ送信部１３２は、後述する通信部１７０を介して、センサデバイス１０の認証情報（ＩＤ）を認証サーバ４０に送信する。当該認証情報は、認証サーバ４０にて、センサデバイス１０が、本実施の形態に係るデータ配信システム１によるサービスを提供する権限を有するか否かを判定する際に用いられる。本実施の形態に係るデータ配信システム１は、このような認証により、当該データ配信システム１のセキュリティを確保している。

　ｋｅｙ受信部１３４は、後述する通信部１７０を介して、認証サーバ４０から送信されたサービスへのアクセスを可能にするキーや、サービスを提供するためのコマンド等を受信し、受信したキー等を後述するモデル取得部１４０へ出力する。当該モデル取得部１４０は、ｋｅｙ受信部１３４で受信したキー等を用いて、サービスサーバ２０から認識モデルを取得することができる。

　センサデータ取得部１３６は、センサ部１００を制御して、センサ部１００から出力されたセンシングデータを取得し、取得したセンシングデータを後述する前処理部１３８又は認識部１４２へ出力する。

　前処理部１３８は、後述するモデル取得部１４０が取得した認識モデルに含まれる情報（例えば、認識モデルを生成する際に用いた教師データに関する情報等）に応じて、センサデータ取得部１３６から出力されたセンシングデータを前処理して、前処理したセンシングデータを後述する認識部１４２へ出力する。

　詳細には、認識部１４２は、機械学習で得られた、配信リクエストに対応する認識モデルを用いて、センシングデータが当該配信リクエストに該当することになるかどうかを認識する。そこで、センシングデータが認識モデルに近い形態を持つように前処理を行うことにより、上記認識に好適なセンシングデータを認識部１４２に提供することができる。その結果、本実施の形態によれば、認識部１４２の認識の精度を向上させることができる。なお、前処理部１３８での前処理の詳細については、後述する。

　モデル取得部１４０は、後述する通信部１７０を介して、サービスサーバ２０から、配信リクエストに対応する認識モデルを取得し、取得した認識モデルを前処理部１３８及び認識部１４２に出力する。なお、当該認識モデルの詳細については後述する。

　認識部１４２は、ＡＩ機能等を利用して、モデル取得部１４０から出力された認識モデルに基づき、センサデータ取得部１３６から出力されたセンシングデータ、もしくは、前処理部１３８で前処理されたセンシングデータが、配信リクエストに該当するかどうかを認識することができる。

　より具体的には、認識部１４２は、例えば、センシングデータとしての画像に、配信リクエストで指定されたオブジェクトの画像が含まれるかどうかを認識することができる（言い換えると、オブジェクトの認識）。そして、認識部１４２は、認識結果を後述するデータ生成部１４４に出力する。なお、当該認識モデルは、サービスサーバ２０における機械学習で得られ、例えば、配信リクエストで指定されたオブジェクトの画像や音声等のデータから得られた当該オブジェクトを特徴づける特徴情報であることができる。上述のような認識をセンサデバイス１０で行うことから、センシングデータの取得後すぐに認識を行うことができる。なお、認識部１４２における認識の詳細については後述する。

　データ生成部１４４は、上述した認識部１４２でセンシングデータが配信リクエストに該当すると認識された場合、当該センシングデータに対して当該配信リクエストに応じた処理を行い、配信データを生成することができる。例えば、データ生成部１４４は、センシングデータから配信リクエストで指定されたオブジェクトに関するデータのみを抽出したり、抽象化したり、テキストデータ化したりすることにより、配信データを生成することができる。

　より具体的には、当該配信データは、配信リクエストで指定された、オブジェクトの属性情報、数量情報、位置情報、状態情報、動作情報、周囲環境情報、及び、予測情報のうちの少なくとも１つの情報を含むことができる。さらに、配信データのデータフォーマットは、画像データ、音声データ、テキストデータ等であることができ、特に限定されるものではない。このように、センサデバイス１０にて、配信リクエストに該当したセンシングデータを処理して、配信データを生成することから、リアルタイムで配信を実現することができる。

　また、データ生成部１４４は、センシングデータが配信リクエストに該当しない場合には、配信データを生成、配信することはない。従って、本実施の形態によれば、センシングデータが配信リクエストに該当するか否かに関係なくセンシングデータを送信する場合に比べて、データ送信の負荷を減らすことができる。

　さらに、データ生成部１４４は、例えば、配信データから、センシングデータに含まれるプライバシに関する情報（例えば、人物が特定できる程度の人物の撮像）を排除することができる。また、データ生成部１４４は、例えば、配信データ上で、プライバシに関する情報にマスクがかけることができる。このようにすることで、プライバシの保護を確保している。なお、このような処理の例については後述する。

　配信部１４６は、上述したデータ生成部１４４で生成した配信データを、ユーザデバイス３０又はサービスサーバ２０へ配信する。なお、配信部１４６は、複数の異なる配信データをユーザデバイス３０又はサービスサーバ２０へ配信することもできる。例えば、配信部１４６は、上記情報として、配信データに対応するセンシングデータが取得された際の日時の情報、配信データを配信した日時の情報、データタイプ、データフォーマット、配信量、配信先（例えばユーザデバイス３０の認識情報）等を出力する。

　記憶部１６０は、処理部１３０が各種処理を実行するためのプログラム、情報等や、処理によって得た情報を格納する。記憶部１６０は、例えば、ＨＤＤ（Hard Disk Drive）等の記憶装置により実現される。

　通信部１７０は、サービスサーバ２０等の外部装置との間で情報の送受信を行うことができる。通信部１７０は、データの送受信を行う機能を有する通信インタフェースと言える。なお、通信部１７０は、通信アンテナ、送受信回路やポート等の通信デバイス（図示省略）により実現される。

　＜サービスサーバの詳細構成＞
　次に、図３を参照して、本実施の形態に係るサービスサーバ２０の詳細構成を説明する。図３は、本実施の形態に係るサービスサーバ２０の機能構成例を示すブロック図である。詳細には、図３に示すように、サービスサーバ２０は、処理部２３０と、記憶部２６０と、通信部２７０とを主に有する。以下に、サービスサーバ２０の各機能ブロックについて順次説明する。

　処理部２３０は、後述する通信部２７０を介して、ユーザデバイス３０から配信リクエストを取得し、取得した配信リクエストに応じた認識モデルを生成し、生成した認識モデルを、センサデバイス１０へ送信したりする機能を有する。処理部２３０は、例えば、ＣＰＵやＧＰＵ等の処理回路や、ＲＯＭ、ＲＡＭ等により実現される。詳細には、図３に示すように、処理部２３０は、ＩＤ送信部２３２と、リクエスト受付部２３４と、能力情報取得部２３６と、モデル生成部２３８と、モデル送信部２４０と、データ取得部２４２と、配信部２４６とを主に有する。以下に、処理部２３０の有する各機能部の詳細について説明する。

　ＩＤ送信部２３２は、後述する通信部２７０を介して、サービスサーバ２０の認証情報（ＩＤ）を認証サーバ４０に送信する。当該認証情報は、認証サーバ４０にて、サービスサーバ２０が、本実施の形態に係るデータ配信システム１によるサービスを提供される権限を有するか否かを判定する際に用いられる。本実施の形態に係るデータ配信システム１は、このような認証により、当該データ配信システム１のセキュリティを確保している。

　リクエスト受付部２３４は、後述する通信部２７０を介して、１つ又は複数のユーザデバイス３０から配信リクエストを受け付け、受け付けた配信リクエストを後述するモデル生成部２３８へ出力する。なお、リクエスト受付部２３４は、共通する配信リクエストについては、これらを統合して出力してもよい。

　能力情報取得部２３６は、後述する通信部２７０を介して、各センサデバイス１０のセンシング能力（センシングの種別、精度、位置、範囲、粒度等）や演算能力を示す能力情報を予め取得し、取得した能力情報を後述するモデル生成部２３８に出力する。なお、能力情報取得部２３６は、センサデバイス１０の機能等がアップデートされた際に、能力情報を再取得することが好ましい。

　そして、後述するモデル生成部２３８において、各センサデバイス１０の能力情報に基づいて、各センサデバイス１０の能力に応じた認識モデルが生成されることとなる。従って、本実施の形態によれば、センサデバイス１０の機能等がアップデートされた際に能力情報を再取得するようにすることで、現時点の各センサデバイス１０の能力に応じるものになるように認識モデルを更新することができる。

　モデル生成部２３８は、リクエスト受付部２３４からの配信リクエスト及び能力情報取得部２３６からの能力情報に基づき、各センサデバイス１０の能力に応じて、配信リクエストに対応する認識モデルを機械学習により生成することができる。さらに、モデル生成部２３８は、生成した認識モデルを、後述するモデル送信部２４０に出力することができる。

　なお、モデル生成部２３８は、機械学習に必要なデータを、ユーザデバイス３０又は図示しない他のサーバから取得してもよい。モデル生成部２３８は、各センサデバイス１０に好適な認識モデルを生成することができることから、センサデバイス１０における認識を実現することができる。また、センサデバイス１０の機能等がアップデートされた際に能力情報を再取得し、認識モデルを再生成することも可能であることから、認識モデルを動的に変えて、センサデバイス１０での認識を向上させることができる。

　また、モデル生成部２３８は、モデル生成部２３８の機械学習で用いたデータに関する情報（例えば、認識モデルを生成する際に用いた教師データに関する情報等）を、認識モデルに含ませてもよい。当該情報は、センサデバイス１０の前処理部１３８において、センシングデータが認識モデルに近い形態を持つように前処理を行う際に用いられる。さらに、モデル生成部２３８は、センサデバイス１０の能力情報に基づく、配信リクエストで指定された配信データを生成するために求められるセンシングデータを取得するための、センサデバイス１０のセンサ部１００の設定に関する設定情報を、認識モデルに含ませてもよい。なお、モデル生成部２３８はサービスサーバ２０と別個の装置として設けられていてもよく、特に限定されるものではない。

　モデル送信部２４０は、上述したモデル生成部２３８から取得した認識モデルを、各認識モデルに対応するセンサデバイス１０へ、通信部２７０を介して送信する。

　データ取得部２４２は、後述する通信部２７０を介して、センサデバイス１０から配信リクエストに対応する配信データを取得し、取得した配信データを後述する配信部２４６に出力する。なお、センサデバイス１０からユーザデバイス３０へ直接配信データを送信する場合には、当該データ取得部２４２は設けられていなくてもよい。

　配信部２４６は、上述したデータ取得部２４２で取得した配信データを、後述する通信部２７０を介して、配信リクエストに該当するユーザデバイス３０へ配信する。なお、センサデバイス１０からユーザデバイス３０へ直接配信データを送信する場合には、当該配信部２４６は設けられていなくてもよい。

　記憶部２６０は、処理部２３０が各種処理を実行するためのプログラム、情報等や、処理によって得た情報を格納する。なお、記憶部２６０は、例えば、ＨＤＤ等の記憶装置により実現される。

　通信部２７０は、センサデバイス１０、ユーザデバイス３０等の外部装置との間で情報の送受信を行うことができる。言い換えると、通信部２７０は、データの送受信を行う機能を有する通信インタフェースと言える。なお、通信部２７０は、通信アンテナ、送受信回路やポート等の通信デバイス（図示省略）により実現される。

　＜本実施の形態に係る認識について＞
　次に、図４から図６を参照して、本実施の形態に係る認識の一例について説明する。図４は、本実施の形態に係る認識モデル３１０の生成例を説明するための説明図であり、図５は、本実施の形態に係る配信データの例を説明するための説明図であり、図６は、本実施の形態に係る前処理の例を説明するための説明図である。

　本実施の形態に係る認識で用いられるモデルの生成について説明する。認識モデルは、上述したように、サービスサーバ２０のモデル生成部２３８で生成される。上記モデル生成部２３８は、図４に示すように、例えば、サポートベクターレグレッションやディープニューラルネットワーク等の教師付き学習器２３８ａを有するものとする。

　学習器２３８ａには、例えば、配信リクエストで指定される配信を要求する対象となるオブジェクトに関する情報である複数の教師データ３０２－１～３０２－ｎが入力される。そして、当該学習器２３８ａは、入力された複数の教師データ３０２－１～３０２－ｎを機械学習することにより、センサデバイス１０の認識部１４２での認識で用いられる認識モデル３１０を生成することができる。

　複数のセンサデバイス１０は、そのセンシング能力や演算能力が互いに異なり、すなわち、認識できる能力が互いに異なるため、学習器２３８ａは、上述した各センサデバイス１０の能力情報に応じて各認識モデル３１０を生成することが好ましい。従って、様々な仕様を持つ複数のセンサデバイス１０が含まれていても、各センサデバイス１０の能力に応じた認識モデル３１０を生成することができることから、各センサデバイス１０で認識を行うことができる。

　より詳細には、上記学習器２３８ａは、例えば、配信リクエストで指定される配信を要求する対象となるオブジェクト３００-１～３００－ｎでそれぞれラベル付けされた、当該オブジェクトに関する教師データ３０２－１～３０２－ｎが入力される。そして、学習器２３８ａは、コンボリューショナルニューラルネットワーク等による機械学習により、複数の教師データ３０２－１～３０２－ｎから、当該オブジェクトの特徴点、特徴量を抽出する。このように抽出された特徴点等の情報が、各センサデバイス１０で取得されたセンシングデータに当該オブジェクトの情報が含まれているかどうかを認識するための認識モデル３１０となる。

　ここで、具体例を示して、本実施の形態に係る認識モデル３１０の生成について説明する。例えば、ユーザからの配信リクエストにより、センサデバイス１０で取得した画像（センシングデータ）を用いて、所定の人物（オブジェクト）を探索することを要求された場合（配信データは、所定の人物の位置情報となる場合）を説明する。

　サービスサーバ２０は、上記配信リクエストを送信したユーザデバイス３０又は図示しないサーバから、認識モデル３１０を生成する際に利用する複数の教師データ３０２として、所定の人物の複数の画像を取得する。そして、サービスサーバ２０は、図４に示すように、取得した複数の画像（教師データ）３０２－１～３０２－ｎを、所定の人物（オブジェクト）３００－１～３００－ｎというラベルをそれぞれに付して、学習器２３８ａに入力する。さらに、学習器２３８ａは、複数の画像（教師データ）３０２－１～３０２－ｎを用いた機械学習により、複数の画像（教師データ）３０２－１～３０２－ｎから、所定の人物（オブジェクト）３００の画像の特徴点、特徴量を抽出し、画像（センシングデータ）から所定の人物（オブジェクト）３００の画像を認識するための認識モデル３１０を生成する。

　なお、上述の例と同様に、ユーザからの配信リクエストにより、センサデバイス１０で取得したセンシングデータ（ここでは、特にセンシングデータの種別を限定していない）を用いて、所定の人物（オブジェクト）を探索することを要求された場合には、学習器２３８ａは、各センサデバイス１０で取得可能なセンシングデータの種別に応じて認識モデル３１０を生成してもよい。

　より具体的には、学習器２３８ａは、画像を取得することが可能なセンサデバイス１０のために画像から所定の人物の画像を認識するための認識モデル３１０を生成し、環境音を取得することが可能なセンサデバイス１０のために環境音から所定の人物の音声を認識するための認識モデル３１０を生成する。従って、様々な仕様を持つ複数のセンサデバイス１０が含まれていても、各センサデバイス１０の能力に応じた認識モデル３１０を生成することができることから、各センサデバイス１０で認識を行うことができる。

　また、上述したように、認識モデル３１０は、機械学習で用いた教師データ３０２に関する情報を含んでいてもよい。ここで、教師データ３０２に関する情報とは、教師データ３０２の種別（例えば、画像、音声等）や、教師データの品質（ひずみ補償レベル、画素欠陥、ホワイトバランス、画像サイズ、彩度、輝度、ガンマ、コントラスト、エッジ強調レベル、フォーカス、露出レベル、解像度、ダイナミックレンジ、ノイズリダクションレベル等）であることができる。

　このような教師データ３０２に関する情報は、先に説明したセンサデバイス１０の前処理部１３８において、取得されたセンシングデータが認識モデル（詳細には教師データ３０２）に近い形態を持つように前処理を行う際に用いられることができる。このようにすることで、センサデバイス１０の認識部１４２の認識の精度を向上させることができる。

　また、上述したように、認識モデル３１０は、配信リクエストで指定された配信データを生成するために求められるセンシングデータを取得するための、センサデバイス１０のセンサ部１００の設定に関する設定情報を含んでいてもよい。ここで、設定情報とは、センシングデータの種別（例えば、画像、音声等）や、所望するセンシングデータの品質に応じたセンサ部１００の設定値（ひずみ補償レベル、ホワイトバランス、画像サイズ、彩度、輝度、ガンマ、コントラスト、エッジ強調レベル、フォーカス、露出レベル、解像度、ダイナミックレンジ、ノイズリダクションレベル等）であることができる。このような設定情報は、センサ部１００の設定の際に用いられ、認識モデル３１０に応じたセンシングデータを取得することを可能にし、ひいては認識部１４２の認識の精度を向上させることができる。

　なお、学習器２３８ａはサービスサーバ２０と別個のサーバに設けられていてもよく、特に限定されるものではない。さらに、学習器２３８ａにおける学習方法は、上述した方法に限定されるものではなく別の方法を用いてもよい。

　＜認識モデルを用いた認識＞
　次に、上述した認識モデル３１０を用いた認識について説明する。上述したように、認識モデル３１０は、センサデバイス１０の認識部１４２で、センシングデータ、もしくは、前処理されたセンシングデータが、配信リクエストに該当するかどうかを認識する際に用いられる。ここで、具体例を示して、本実施の形態に係る認識ついて説明する。

　例えば、ユーザからの配信リクエストにより、センサデバイス１０で取得した画像（センシングデータ）を用いて、所定の人物（オブジェクト）を探索することを要求された場合（配信データは、所定の人物の位置情報となる）を説明する。センサデバイス１０は、センサ部１００から画像を取得する。そして、認識部１４２は、サービスサーバ２０から取得した認識モデル３１０、詳細には、所定の人物（オブジェクト）３００の画像の特徴点、特徴量を参照して、センサ部１００から取得した画像に、所定の人物の画像が含まれているかどうかを認識する。すなわち、上述のような認識をセンサデバイス１０で行うことから、画像の取得後すぐに認識を行うことができる。

　上述したように、複数のセンサデバイス１０は、そのセンシング能力や演算能力が互いに異なり、すなわち、認識できる能力が互いに異なるため、各センサデバイス１０の能力情報に応じて、各認識モデル３１０を生成され、各認識が行われる。例えば、本実施の形態においては、ユーザからの配信リクエストにより、センサデバイス１０で取得したセンシングデータ（ここでは、特にセンシングデータの種別を限定していない）を用いて、所定の人物（オブジェクト）を探索することを要求された場合には、画像を取得することが可能なセンサデバイス１０の認識部１４２は、認識モデル３１０に基づいて、画像から所定の人物の画像を認識し、環境音を取得することが可能なセンサデバイス１０の認識部１４２は、認識モデル３１０に基づいて、環境音から所定の人物の音声を認識する。

　なお、認識部１４２は、センサデバイス１０と別個の装置に設けられていてもよく、特に限定されるものではない。さらに、認識部１４２における認識方法は、上述した方法に限定されるものではなく別の方法を用いてもよい。

　次に、図５を参照して、本実施の形態に係る配信データの例について説明する。上述したように、センサデバイス１０のデータ生成部１４４は、センシングデータに対して当該配信リクエストに応じた処理を行い、配信データを生成する。当該配信データは、配信リクエストで指定された、オブジェクトの属性情報、数量情報、位置情報、状態情報、動作情報、周囲環境情報、及び、予測情報のうちの少なくとも１つの情報を含むことができる。

　また、当該配信データは、画像やテキスト等のデータフォーマットを持つことができ、特に限定されるものではない。さらに、配信データには、配信リクエストを送信したユーザもしくはユーザデバイス３０の識別情報が含まれていることが好ましい。すなわち、例えば、データ生成部１４４は、配信リクエストに応じて、センシングデータから配信リクエストで指定されたオブジェクトのデータのみを配信データとして抽出したり、抽象化したり、テキストデータ化したりすることができる。

　このように、データ生成部１４４が、配信リクエストに該当したセンシングデータを処理して配信データを生成する、リアルタイムでの配信を実現することができる。また、データ生成部１４４は、センシングデータが配信リクエストに該当しない場合には、配信データを生成、送信することはない。従って、本実施の形態によれば、センシングデータが配信リクエストに該当するか否かに関係なくセンシングデータを送信する場合に比べて、データ送信の負荷を減らすことができる。

　また、データ生成部１４４は、配信データから、センシングデータに含まれるプライバシに関する情報（例えば、人物が特定できる程度の人物の撮像）を排除することができる。このようにすることで、プライバシの保護を確保にしている。より具体的には、図５の最上段に示される例では、データ生成部１４４は、配信リクエストに該当するセンシングデータとして道路の画像Ａが取得された場合、配信リクエストで指定された看板標識や横断歩道のみを抽出して、配信データＡを生成する。

　また、図５の上から２段目に示される例では、データ生成部１４４は、配信リクエストに該当するセンシングデータとして道路の画像Ｂが取得された場合、配信リクエストで指定された道路上の標識や車両のみを抽出して、配信データＢを生成する。

　また、図５の上から３段目に示される例では、データ生成部１４４は、配信リクエストに該当するセンシングデータとして道路の画像Ｃが取得された場合、配信リクエストで指定された看板標識や水たまりのみを抽出して、配信データＣを生成する。

　さらに、図５の最下段に示される例では、データ生成部１４４は、配信リクエストに該当するセンシングデータとして道路の画像Ｄが取得された場合、配信リクエストで指定された横断歩道や当該横断歩道を渡る人物のみを抽出して、配信データＤを生成する。

　次に、図６を参照して、本実施の形態に係る前処理の例について説明する。上述したように、認識部１４２は、機械学習で得られた認識モデル３１０を用いて、センシングデータが配信リクエストに該当するかどうかを認識することができる。そして、認識部１４２での認識の精度を向上させるために、センサデバイス１０の前処理部１３８は、上述した教師データに関する情報に基づいて、センシングデータが認識モデル３１０に近い形態を持つように前処理を行う。詳細には、前処理部１３８は、フォーマット、ひずみ補償レベル、画素欠陥、ホワイトバランス、画像サイズ、彩度、輝度、ガンマ、コントラスト、エッジ強調レベル、フォーカス、露出レベル、解像度、ダイナミックレンジ、ノイズリダクションレベル等が教師データ３０２と同等になるように、センシングデータに対して前処理を行う。

　より具体的には、例えば、センサデバイス１０のセンサ部１００で、図６の上段に示すような各画像をセンシングデータとして取得した場合には、前処理部１３８は、画質サイズ及びフォーカスが教師データ３０２と同等になるように、図６の上段の各画像に対して前処理を行う。そして、前処理部１３８は、図６の下段に示すような各画像を取得する。本実施の形態によれば、このように、前処理部１３８で、認識モデル３１０を生成する際に用いた教師データ３０２と同等のデータレベルを持つセンシングデータになるように前処理することにより、認識部１４２での認識の精度をより向上させることができる。

　次に、図７を参照して、本開示の実施の形態に係る情報処理方法について説明する。図７は、本実施の形態に係る情報処理方法の一例を示すシーケンス図である。

　ステップＳ１において、ユーザデバイス３０は、ユーザから入力された情報を受け付け、受け付けた当該情報を配信リクエストとしてサービスサーバ２０へ送信する。ステップＳ２において、サービスサーバ２０は、ユーザデバイス３０から配信リクエストを受信する。

　ステップＳ３において、サービスサーバ２０は、上述したステップＳ２で受信した配信リクエストに基づいて、認識モデルを生成し、生成した認識モデルを各センサデバイス１０へ送信する。

　ステップＳ４において、センサデバイス１０は、サービスサーバ２０から認識モデルを受信する。また、ステップＳ５において、センサデバイス１０は、センシングを行い、センシングデータを取得する。さらに、ステップＳ６において、センサデバイス１０は、上述したステップＳ４で受信した認識モデルに基づいて、上述したステップＳ５で取得したセンシングデータが配信リクエストに該当するかどうかを認識する。

　センサデバイス１０は、上述したステップＳ６でセンシングデータが配信リクエストに該当すると認識したことに基づいて、当該センシングデータに対して配信リクエストに応じた処理を行い、配信データを生成する。さらに、ステップＳ７において、センサデバイス１０は、生成した配信データを、配信リクエストに係るユーザデバイス３０へ直接送信する。

　なお、他の実施の形態として、センサデバイス１０からユーザデバイス３０に、配信データが、直接送信されるのではなく、サービスサーバ２０を介して送信されるようにしても良い。

　ステップＳ８において、ユーザデバイス３０は、センサデバイス１０から送信された配信データを受信する。

　以上説明したように、上述した本実施の形態によれば、様々なセンサデバイス１０が取得したセンシングデータから得られる情報を様々なユーザが容易に利用することが可能なフレームワークを構築することができる。

　＜モードの切り替え機能の追加＞
　センサデバイス１０は、上述したように、自動車等の移動体に搭載された撮像装置（カメラ）や、ユーザの携帯するスマートフォンに搭載された撮像装置、自宅や店舗等に設置された監視カメラ等の撮像装置などである。センサデバイス１０が、バッテリで駆動しているような場合、バッテリの容量が減り、機能しなくなる可能性がある。また、ＡＩ処理するＣＰＵやＧＰＵが熱を持つ可能性もあり、発熱がひどくなると、センサデバイス１０が正常に機能しなくなる可能性もある。

　センサデバイス１０のバッテリの容量が、閾値以下になったような場合や、ＣＰＵやＧＰＵといった処理部１３０の発熱量が閾値以上になったような場合、センサデバイス１０で行われている処理の一部を、サービスサーバ２０で行うように切り替える。ここでは、センサデバイス１０のＡＩ機能の一部、または全てが、サービスサーバ２０で行われる場合を例に挙げて説明を続ける。

　センサデバイス１０の処理の一部をサービスサーバ２０で行うようにすることで、センサデバイス１０のバッテリの消費を抑えたり、処理部１３０の発熱を抑えたりする処理について説明を加える。

　図８に、このような処理を行うでセンサデバイス１０の構成例を示す。図８に示したセンサデバイス１０は、以下の説明に必要とされる部分を、図２に示したセンサデバイス１０の構成に追加した構成である。図８に示したセンサデバイス１０は、センサデバイス１０の各部に電力を供給するバッテリ１８０と、そのバッテリ１８０の残量を検知する残量検出部１５２と、センサデバイス１０内の発熱量を検知する熱検出部１５４が追加された構成とされている。また、後述するモードを切り替えるときの処理を行うモード切替制御部１５６も追加された構成とされている。

　センサデバイス１０側の処理の一部を、サービスサーバ２０側でも行えるようにした場合のサービスサーバ２０の構成例を図９に示す。図９に示したサービスサーバ２０は、図３に示したサービスサーバ２０の構成に、認識部２４８と前処理部２５０を追加した構成とされている。認識部２４８と前処理部２５０は、センサデバイス１０の認識部１４２と前処理部１３８と同等の処理を行う機能である。また、後述するモードを切り替えるときの処理を行うモード切替制御部２５２も追加された構成とされている。

　ここでは、例えば、センサデバイス１０のバッテリ１８０の容量が閾値以下になった場合やセンサデバイス１０の発熱量が閾値以上になった場合、センサデバイス１０の認識部１４２で行う処理を、サービスサーバ２０で行うようにする。またさらにバッテリ１８０の容量が下がった場合、センサデバイス１０の前処理部１３８で行う処理も、サービスサーバ２０で行うようにする。このような場合を例に挙げて説明するため、サービスサーバ２０は、図９に示したように、認識部２４８と前処理部２５０を備える構成とされている。

　センサデバイス１０として、どのような機能を有しているか、またセンサデバイス１０の機能のうち、どの機能をサービスサーバ２０側で行わせるかにより、図８，図９に示したセンサデバイス１０とサービスサーバ２０の構成は変わるため、図８，図９に示した構成例は一例であり、限定を示すものではない。

　センサデバイス１０のバッテリ１８０の残量や処理部１３０の発熱量に応じて、センサデバイス１０の処理の一部を、サービスサーバ２０側で行う場合の一例を、図１０、図１１を参照して説明する。

　以下の説明においては、センサデバイス１０側で、センサデバイス１０側で行うとして設定されている処理の全てを行うモードをセンサデバイス重点モードと記述する。このセンサデバイス重点モードは、例えば、センサデバイス１０のＡＩ機能で、認識モデルを用いた処理を行うモードである。

　サービスサーバ２０側で、センサデバイス１０側で行うとして設定されている処理の一部を行うモードをサービスサーバ重点モードと記述する。サービスサーバ重点モードはセンサデバイス１０とサービスサーバ２０で、センサデバイス１０のＡＩ機能を分担して、認識モデルを用いた処理を行うモードである。

　なおここでは、この２つのモードがある場合を例示して説明を続けるが、モードとしては複数設けても良い。２以上のモードを設けた場合については、図１２を参照して後述する。

　図１０は、センサデバイス１０とサービスサーバ２０から構成されシステムにおいて、モードの切替（モード遷移）に係わる処理について説明するためのフローチャートである。図１１は、センサデバイス重点モードとサービスサーバ重点モードのときのセンサデバイス１０とサービスサーバ２０の機能の分担状態を表す図である。

　ステップＳ１１において、センサデバイス１０側のバッテリ１８０の残量が、閾値以下であるか、または熱が閾値以上であるかが判定される。センサデバイス１０の残量検出部１５２により、バッテリ１８０の残量が検出され、閾値以下であるか否かがモード切替制御部１５６により判定される、また、センサデバイス１０の熱検出部１５４により、センサデバイス１０内の温度が計測され、その温度が閾値以上であるか否かが、モード切替制御部１５６により判定される。

　バッテリ１８０の残量が閾値以下であるかの判定や、熱が閾値以上であるかの判定は、後述するように、サービスサーバ２０のモード切替制御部２５２で行うようにすることもできる。

　また、ここではバッテリ１８０の残量と処理部１３０の熱が監視され、残量と熱がそれぞれ閾値と比較される場合を例に挙げて説明を続けるが、残量と熱のうちのどちらか一方のみが監視され、閾値比較される場合にも、本技術を適用することはできる。すなわち、本技術は、モード切替のトリガとなる要因が、１つ（残量または熱）であっても良いし、２つ（残量と熱）であっても良い。さらに、本技術は、モード切替のトリガとなる要因が２以上であってももちろん適用できる。

　なお、熱検出部１５４は、ＣＰＵやＧＰＵといった認識部１４２や前処理部１３８を構成する部位（ＡＩ機能に係わる部位）の温度（発熱量）を直接計測する、換言すれば、ＣＰＵやＧＰＵの熱だけを計測するように構成しても良いし、センサデバイス１０の温度を計測する（この場合、外気温の影響も少なからず受ける）ようにしても良い。

　ステップＳ１１において、センサデバイス１０側のバッテリ１８０の残量は、閾値以下にはなっていない、かつ熱も閾値以上にはなっていないと判定された場合、ステップＳ１２に処理は進められ、センサデバイス重点モードに設定される。図１１の上段は、センサデバイス重点モードのときを表している。

　センサデバイス１０は、人を検出する処理を実行する人検出機能を有している。この人検出機能は、前処理部１３８や認識部１４２がモデル取得部１４０で取得された認識モデルに基づき、センサ部１００で撮像された画像から人を検出するＡＩ機能である。センサデバイス１０は、センサデバイス重点モードのときには、センサ部１００で得られた画像を解析することで、人を検出し、人が検出された座標を、配信データとして、通信部１７０を介して、サービスサーバ２０に送信する。

　サービスサーバ２０は、通信部２７０を介してデータ取得部２４２でセンサデバイス１０側から送信されてきた人の座標に関するデータを取得する。サービスサーバ２０は、所定のアプリケーションで人の座標に関するデータを処理する。例えば、進入禁止のエリアに人が侵入していないか否かを判定したり、侵入していると判定したときには、所定のユーザデバイス３０に通知したりする処理が行われる。

　一方で、ステップＳ１１において、センサデバイス１０側のバッテリ１８０の残量は、閾値以下になった、または／および、熱が閾値以上にはなったと判定された場合、ステップＳ１３に処理は進められ、サービスサーバ重点モードに設定される。図１１の下段は、サービスサーバ重点モードのときを表す。

　センサデバイス重点モードから、サービスサーバ重点モードに切り替えられると、センサデバイス１０側は、センサ部１００で撮像された画像の画像データを、サービスサーバ２０に送信する。サービスサーバ重点モードのときには、センサデバイス１０は、前処理部１３８や認識部１４２における処理を行わない。前処理部１３８や認識部１４２の処理が実行されないことにより、バッテリ１８０の消費電力を抑制したり、発熱量を抑制したりすることができる。

　サービスサーバ２０は、センサデバイス１０からの画像データを、通信部２７０を介してデータ取得部２４２により取得する。サービスサーバ２０が、人検出機能を、認識部２４３と前処理部２５０で実現する場合、データ取得部２４２で取得された画像データは、前処理部２５０に供給される。そして、前処理部２５０で処理された画像データは、認識部２４８に供給される。前処理部２５０１と認識部２４８は、センサデバイス１０側の前処理部１３８と認識部１４２と同様の処理を実行することで、人検出機能を実現する。サービスサーバ２０は、人検出機能により人を検出し、その人の座標を検出すると、その人の座標に関するデータを、アプリケーションで供給する。

　図１１に示した例では、センサデバイス１０のバッテリ１８０の残量が閾値以下になった場合や発熱量が閾値以上になった場合、センサデバイス１０の人検出機能（ＡＩ機能）による処理が、サービスサーバ２０側で行われるようにモードが切り替えられる。

　なお、サービスサーバ重点モードのとき、センサデバイス１０のバッテリ１８０が充電されたり、交換されたりすることで、残量が閾値以上に戻ったと判定された場合や、発熱が収まったと判定された場合、センサデバイス重点モードに戻される。

　＜複数のモード間での遷移＞
　図１２を参照して、３つのモードがある場合について説明を加える。図１２に示したモードは、センサデバイス重点モード、バランスモード、サービスサーバ重点モードの３モードである。バランスモードは、センサデバイス重点モードとサービスサーバ重点モードの間のモードとの位置づけである。

　センサデバイス重点モードのとき、センサデバイス１０では、センサ部１００で撮像された画像から、人の顔を検出する顔検出機能と、顔検出機能により検出された顔を認識する顔認識機能からなるＡＩ機能を有する場合を示している。

　例えば、顔検出機能は、前処理部１３８（図８）において実現されるようにし、センサ部１００で撮像された画像から、顔が撮像されている領域を抽出するＡＩ機能として設けることができる。また例えば、顔認識機能は、認識部１４２（図８）において実現されるようにし、顔検出機能（前処理部１３８）により検出された顔が、例えばユーザＡであるか否か、特定の人物を特定する機能であり、顔認証を行うＡＩ機能として設けることができる。

　センサデバイス重点モードのとき、センサデバイス１０の顔検出機能により、画像から顔が検出され、顔検出結果が出力される。また、センサデバイス１０の顔認識機能により、顔検出結果を用いて、顔認識が行われ、顔認識結果が出力される。このような一連の処理が、センサデバイス重点モードのときには、センサデバイス１０側で行われ、最終的に出された顔認識結果が、サービスサーバ２０側に送信される。

　サービスサーバ２０は、通信部２７０を介してデータ取得部２４２でセンサデバイス１０側から送信されてきた顔認識結果に関するデータを取得する。サービスサーバ２０は、所定のアプリケーションで顔認識結果に関するデータを処理する。例えば、顔認識の結果が、ユーザＡであるとの認識結果である場合、部屋の鍵を開ける、照明を付けるといった処理がなされるようにすることができる。

　センサデバイス１０のセンサデバイス１０側のバッテリ１８０の残量は、閾値以下になった、または熱が閾値以上にはなったと判定されると、バランスモードに切り替えられる。バランスモードの状態を、図１２の中段に示す。図１２の中段に示したように、バランスモードのときには、センサデバイス１０の顔認識機能に関する処理、換言すれば、認識部１４２で行われる処理は、サービスサーバ２０側で実行されるようになる。

　センサデバイス１０側では、センサ部１００で撮像された画像から、顔検出機能により、顔を検出するまでの処理が実行される。そして、顔検出結果が、サービスサーバ２０に送信される。サービスサーバ２０は、データ取得部２４２により顔検出結果を取得する。サービスサーバ２０は、顔認識機能、この場合、認識部２４８（図９）により、顔認識を行う。サービスサーバ２０の顔認識機能により認識された顔認識結果は、アプリケーションに供給される。

　バランスモードの場合、センサデバイス１０側の顔認識機能（認識部１４２（図８）で行う処理）が、サービスサーバ２０側で行われる。換言すれば、センサデバイス１０は、顔認識の処理を行わない。よって、センサデバイス１０は、顔認識を行わない分だけ少なくとも、バッテリ１８０の消費電力を低減したり、処理部１３０の発熱量を低減したりすることができる。

　このように、バランスモードは、センサデバイス１０のＡＩ機能で処理していたことを、センサデバイス１０とサービスサーバ２０で分担して行うようにするモードである。

　なお、バランスモードのとき、センサデバイス１０のバッテリ１８０が充電されたり、交換されたりすることで、残量が閾値以上に戻った判定された場合や、発熱が収まったと判定された場合、センサデバイス重点モードに戻される。

　バランスモードのときからさらに、センサデバイス１０側のバッテリ１８０の残量が下がった場合や、熱がより上がった場合などには、バランスモードからサービスサーバ重点モードに遷移する。

　サービスサーバ重点モードのときには、センサデバイス１０の顔検出機能に関する処理、換言すれば、前処理部１３８で行われる処理も、サービスサーバ２０側で実行されるようになる。さらに換言すると、サービスサーバ重点モードは、センサデバイス１０側のＡＩ機能による処理のうちのほぼ全ての処理が、サービスサーバ２０側で行われるモードである。

　サービスサーバ重点モードの場合、センサデバイス１０は、センサ部１００で撮像された画像の画像データを、サービスサーバ２０に送信する。サービスサーバ重点モードのときには、センサデバイス１０は、前処理部１３８や認識部１４２における処理を行わない。前処理部１３８や認識部１４２の処理が実行されないことにより、バッテリ１８０の消費電力を抑制したり、発熱量を抑制したりすることができる。

　サービスサーバ２０は、センサデバイス１０からの画像データを、通信部２７０を介してデータ取得部２４２により取得する。サービスサーバ２０は、顔検出機能、この場合、前処理部２５０（図９）により、顔検出を行う。さらに、サービスサーバ２０は、顔認識機能、この場合、認識部２４８（図９）により、顔認識を行う。サービスサーバ２０の顔認識機能により認識された顔認識結果は、アプリケーションに供給される。

　サービスサーバ重点モードの場合、センサデバイス１０側の顔検出機能（前処理部１３８（図８）で行う処理）と顔認識機能（認識部１４２（図８）で行う処理）が、サービスサーバ２０側で行われる。換言すれば、センサデバイス１０は、顔検出と顔認識の処理を行わない。よって、センサデバイス１０は、顔検出や顔認識を行わない分だけ少なくとも、バッテリ１８０の消費電力を低減したり、処理部１３０の発熱量を低減したりすることができる。

　なお、サービスサーバ重点モードのとき、センサデバイス１０のバッテリ１８０が充電されたり、交換されたりすることで、残量が閾値以上に戻った判定された場合や、発熱が収まったと判定された場合、バランスモードまたはセンサデバイス重点モードに戻される。

　また、ここでは、センサデバイス重点モード、バランスモード、サービスサーバ重点モードの順で、モードが遷移する場合を例に挙げて説明したが、残量の減りが大きかったり、熱が急激に上がったりしたなどの場合、センサデバイス重点モードからサービスサーバ重点モードに遷移しても良い。

　＜複数のモードの第２の遷移＞
　アプリケーションは、センサデバイス１０側にあっても良い。センサデバイス１０は、上述したように、ＡＩ機能（認識部１４２など実現される）が搭載され、サービスサーバ２から送信された認識モデルに基づき、取得したセンシングデータが、ユーザからの要求（配信リクエスト）に該当するかどうかを認識することができる構成とされている。そこで、センサデバイス１０自体にアプリケーションを搭載し、センサデバイス１０で取得されたセンシングデータから、センサデバイス１０で、ユーザからの要求に該当するかどうかを認識し、その結果を提示するまでの処理を行えるようにすることもできる。

　図１３は、図１２と同様に、センサデバイス重点モード、バランスモード、およびサービスサーバ重点モードを遷移する場合の図である。図１３の上段に示したように、センサデバイス１０は、所定のアプリケーションを有し、センサデバイス重点モードのときには、図１２の場合と同じく、センサデバイス１０が有する顔検出機能と顔認識機能のＡＩ機能により、顔認識が行われる。さらに、アプリケーションにより顔認識結果が処理されるまでの処理が、センサデバイス１０側で行われる。

　バランスモードのときには、図１３の中段に示したように、図１２の中段に示した場合と同じく、センサデバイス１０が有する顔検出機能により顔検出が行われ、その顔検出結果が、サービスサーバ２０に送信される。サービスサーバ２０は、顔認識機能を起動させ、顔認識機能により、顔認識を行う。サービスサーバ２０の顔認識機能により認識された顔認識結果は、センサデバイス１０に送信される。センサデバイス１０は、受信された顔認識結果を、アプリケーションで処理する。

　サービスサーバ重点モードのときには、図１３の下段に示したように、図１２の下段に示した場合と同じく、センサデバイス１０は、センサ部１００で得られた画像データを、サービスサーバ２０に送信する。サービスサーバ２０は、顔検出機能と顔認識機能を起動させ、顔検出と顔認識を行う。サービスサーバ２０の顔認識機能により認識された顔認識結果は、センサデバイス１０に送信される。センサデバイス１０は、受信された顔認識結果を、アプリケーションで処理する。

　このように、センサデバイス１０がアプリケーションも有するように構成し、センサデバイス重点モードのときには、サービスサーバ２０とのやりとりなしで、処理が行われるようにすることもできる。また、バランスモードやサービスサーバ重点モードのときには、サービスサーバ２０での処理結果が、センサデバイス１０側に戻されるようにすることもできる。

　図１３の中段では、顔検出結果が、サービスサーバ２０に送信され、顔認識結果が、センサデバイス１０に送信される例を示した。センサデバイス１０からは、センサ部１００で取得された画像データが、サービスサーバ２０に送信され、サービスサーバ２０は、顔検出機能を有し、顔検出を行うようにしても良い。また、サービスサーバ２０は、顔検出結果を、センサデバイス１０に送信し、センサデバイス１０側で、顔認識機能により顔認識が行われるようにしても良い。

　＜モードにより異なる処理を行う例＞
　図１４は、異なるモードのときには、異なる処理が実行されるときの一例を説明するための図である。図１４に示した例も、図１３に示した例と同じく、センサデバイス１０がアプリケーションを備えている例を示す。

　図１４の上段に示したように、センサデバイス重点モードのときには、センサデバイス１０は、ＲＧＢ人検出機能を起動させ、人検出を行う。ＲＧＢ人検出機能は、ＲＧＢ（Red、Green、Blue）のカラー画像を処理して、人検出を行うＡＩ機能である。センサデバイス重点モード、すなわち、バッテリ１８０の残量があり、発熱量が少ないときには、センサデバイス１０は、センサ部１００で取得されたカラー画像を処理して、人を検出し、人の座標を取得する。またセンサデバイス１０は、所定のアプリケーションで、人の座標を処理し、所定の処理を実行する。

　センサデバイス重点モードから、サービスサーバ重点モードに遷移した場合、図１４の下段に示したように、センサデバイス１０は、ＲＧＢ人検出機能から、輝度人検出機能へとＡＩ機能を切り替える。輝度人検出機能は、センサ部１００で取得された画像の輝度成分を用いて、人検出を行い、輝度による人の座標をアプリケーションに出力するＡＩ機能である。

　またセンサデバイス重点モードのときには、センサ部１００で取得されたカラー画像の画像データは、サービスサーバ２０に送信される。サービスサーバ２０は、ＲＧＢ人検出機能を起動し、受信された画像データに基づく画像を処理することで、人を検出する。検出されたＲＧＢによる人の座標は、サービスサーバ２０からセンサデバイス１０に対して送信される。センサデバイス１０のアプリケーションは、サービスサーバ２０からのＲＧＢによる人の座標も用いて処理を行う。この場合、センサデバイス１０は、グレースケールで人検出を行い、簡易的に人を検出し、詳細はサービスサーバ２０からのＲＧＢによる人の座標を用いて補完する。

　センサデバイス１０が、ＲＧＢ人検出機能を用いて人検出を行うときよりも、輝度人検出機能を用いて人検出を行うときの方が、処理負担が軽減され、バッテリ１８０の消費電力を抑えられる。図１４を参照して説明したようにモード遷移することで、センサデバイス重点モードのときよりも、サービスサーバ重点モードのときの方が、バッテリ１８０の消費電力を抑えることができる。また、発熱も、処理が軽減されれば、下がると考えられるため、センサデバイス重点モードのときよりも、サービスサーバ重点モードのときの方が、発熱量を抑えることができる。

　このように、サービスサーバ重点モードのときには、センサデバイス１０の処理は、センサデバイス重点モードのときよりも処理負荷が低い処理とされ、サービスサーバ２０側で、軽減された処理を補うような処理が実行されるように構成することもできる。

　なお、サービスサーバ重点モードのときは、センサ部１００で撮像されたカラー画像のデータが、サービスサーバ２０に送信されるが、この送信とき、暗号化の処理や圧縮の処理が行われるようにしても良い。このようにした場合、暗号化の処理や圧縮の処理による処理負荷が大きくなる可能性がある。このようなことから、サービスサーバ重点モードのときには、カラー画像のデータの送信を行わないという実施の形態もある。

　＜モードにより異なる処理を行う他の例＞
　図１５は、異なるモードのときには、異なる処理が実行されるときの一例を説明するための図である。図１５に示した例も、図１４に示した例と同じく、センサデバイス１０がアプリケーションを備えている例を示す。

　図１５の上段に示したように、センサデバイス重点モードのときには、センサデバイス１０は、人検出機能を起動させ、人検出を行う。人検出機能により検出された人の座標に関するデータは、アプリケーションに供給される。センサデバイス１０は、所定のアプリケーションで、人の座標を処理し、所定の処理を実行する。

　センサデバイス重点モードから、サービスサーバ重点モードに遷移した場合、図１５の下段に示したように、センサデバイス１０は、差分算出機能を起動し、その差分算出機能による算出結果により、処理を分ける。差分算出機能は、時刻t１においてセンサ部１００で取得された画像１と、時刻ｔ１より前の時刻ｔ０で取得された画像ｔ０との差分を算出する。

　差分算出機能は、所定のフレームと１フレーム前のフレームを比較することで、差分を算出する。この差分は、時刻ｔ０で撮像された状況と時刻ｔ１で撮像された状況とで、どの程度の変化があったかを表す指標として用いることができる。

　この差分が大きい場合、時刻ｔ０で撮像された状況から時刻ｔ１で撮像された状況は大きく変化したと推定することができる。このように状況が変化したと判定されるときには、センサデバイス１０での検出結果をできるだけ早く出すようにするのが良いと考えられる。よって、差分算出機能により算出された差分が大きい場合には、センサデバイス１０側の人検出機能により人検出が行われ、検出された人の座標が、アプリケーションに供給されるようにする。

　一方で、差分が小さい場合、時刻ｔ０で撮像された状況から時刻ｔ１で撮像された状況はあまり変化していないと推定することができる。このように状況があまり変化していないと判定されるときには、センサデバイス１０での検出結果をできるだけ早く出す必要性は低いと考えられる。よって、差分算出機能により算出された差分が小さい場合には、画像データをサービスサーバ２０に送信し、サービスサーバ２０側の人検出機能により人検出が行われ、検出された人の座標が、センサデバイス１０のアプリケーションに供給されるようにする。

　サービスサーバ重点モードのときには、センサデバイス１０は、差分が大きいときだけ人検出を行うため、常時人検出を行う場合、すなわちセンサデバイス重点モードのときよりも、バッテリ１８０の消費電力を抑えることができる。また、発熱も、処理が軽減されれば、下がると考えられるため、センサデバイス重点モードのときよりも、サービスサーバ重点モードのときの方が、発熱量を抑えることができる。

　このように、サービスサーバ重点モードのときには、センサデバイス１０は、サービスサーバ重点モードのときに実行していた処理と、その処理よりも軽減された処理との、どちらかを選択して実行するように構成することもできる。

　＜モード遷移に係わる処理＞
　図１６のフローチャートを参照し、センサデバイス１０とサービスサーバ２０との間で行われる処理についてさらに説明を加える。図１６のフローチャートを参照した説明は、図１１を参照して説明したようにモードが遷移する場合を例に挙げた説明とする。

　また、図１６には、NICE（Network of Intelligent Camera Ecosystem）Allianceで規定されている仕様を適用したときに用いられるＡＰＩ（Application Programming Interface）を図中右側に記載してある。このことは、本技術は、NICE規格に基づいて処理を実行することが可能であることを示す記載であるが、NICE規格にのみに本技術の適用範囲が限定されることを示す記載ではない。すなわち、本技術は、NICE規格に適用することができるし、NICE規格以外の規格に対しても適用できる。

　ステップＳ１０１において、サービスサーバ２０からセンサデバイス１０に対して情報要求が出される。この要求に応じて、センサデバイス１０は、ステップＳ１０２において、センサデバイス１０の情報通知を、サービスサーバ２０に対して行う。このステップＳ１０１とステップＳ１０２において実行されるセンサデバイス１０に関する情報の授受を、NICE規格に基づいて行う場合、GetCapabilitiesというＡＰＩが用いられる。

　GetCapabilitiesというＡＰＩは、デバイスの能力を問い合わせるためのＡＰＩであり、例えば、動画や静止画を撮影する能力があるか、フォーマットとしてJPEGやH.264などＷ扱えるか、どのSceneModeに対応しているかなどの情報を授受するためのＡＰＩである。

　本技術を適用した場合、GetCapabilitiesというＡＰＩを用いて授受されるセンサデバイス１０の情報には、バッテリ１８０の残量や熱（温度）の情報も含まれる。センサデバイス１０は、サービスサーバ２０からGetCapabilitiesというＡＰＩを受け取ったとき、残量検出部１５２でバッテリ１８０の残量を検出し、その検出された残量に関する情報を他の情報とともにサービスサーバ２０に送付する。また、センサデバイス１０は、サービスサーバ２０からGetCapabilitiesというＡＰＩを受け取ったとき、熱検出部１５４でセンサデバイス１０の熱（温度）を測定し、その測定された熱に関する情報も、他の情報とともにサービスサーバ２０に送付する。

　ステップＳ１０３において、サービスサーバ２０は、モード設定を行う。サービスサーバ２０は、センサデバイス１０からのセンサデバイス１０の能力や状態に関する情報を受信しており、この情報を元に、適切なモードを設定する。設定されるモードは、センサデバイス重点モード、またはサービスサーバ重点モードである。

　また、モードが設定されるとは、認識部１４２（図８）が用いる認識モデルが設定されることも含まれる。換言すれば、設定されるモードに対応するＡＩ機能が設定される。

　ステップＳ１０３おいて実行されるモード設定に関する処理を、NICE規格に基づいて行う場合、SetSceneModeというＡＰＩが用いられる。SetSceneModeというＡＰＩは、SceneModeを設定するＡＰＩであり、SceneModeは、人検出、動体検出などである。

　ステップＳ１０４において、センサデバイス１０は、設定された認識モデルを用いた検出処理を行う。例えば図１１を参照して説明したように、センサ部１００で取得された画像から、人を検出する処理が実行される。

　ステップＳ１０５において、センサデバイス１０は、検出処理で検出された情報を、サービスサーバ２０に送信する。送信される情報は、例えば、検出された人の座標に関する情報である。

　ステップＳ１０５において実行される検出結果の通知を、NICE規格に基づいて行う場合、SetSceneMarkというＡＰＩが用いられる。このSetSceneMarkというＡＰＩは、SetSceneModeで設定したトリガにかかったときに、そのトリガにかかった情報を送信するＡＰＩである。例えば、SetSceneModeで人検出が設定されていた場合、人が検出されたときのサムネイル、タイムスタンプなどのメタ情報が送信される。

　ステップＳ１０４における検出処理と、ステップＳ１０５の検出結果の通知の処理は、繰り返し行われる。検出処理と通知処理が繰り返し行われている一方で、図１０を参照して説明したモード切替処理も行われている。図１０を参照して説明したフローチャートのステップＳ１１において、センサデバイス１０のモード切替制御部１５６により、バッテリ１８０の残量が閾値以下になった、または熱が閾値以上になったと判定された場合、センサデバイス重点モードからサービスサーバ重点モードに移行すると決定され、モード遷移が開始される。

　このようなモード遷移の処理が開始されると、図１５に示したフローチャートのステップＳ１１１において、センサデバイス１０の情報が通知される。なお、モード遷移の処理の開始は、センサデバイス１０側からの指示により行うか、サービスサーバ２０側からの指示により行うかなど、複数の実施の形態があるため、詳細は後述する。

　ステップＳ１１１において、モード遷移の開始のために、センサデバイス１０から、バッテリ１８０の残量やセンサデバイス１０の熱に関する情報が、サービスサーバ２０に対して送信される。このようなモード遷移の開始のために、センサデバイス１０から、サービスサーバ２０にセンサデバイス１０の情報を送信するＡＰＩについては、NICE規格では未定義の通信である。このような通信を行うＡＰＩを、NICE規格に新たに定義することで、モード遷移の開始に係わる通信をNICE規格でも行えるようにすることができる。

　ステップＳ１１２において、サービスサーバ２０は、センサデバイス１０に対して、モード設定を行う。このステップＳ１１２におけるモード設定の処理は、ステップＳ１０３におけるモード設定の処理と基本的に同様に行われる。サービスサーバ２０は、センサデバイス１０からのセンサデバイス１０のバッテリ残量や熱に関する情報を受信すると、そのバッテリ残量や熱のときに適したモードを設定する。図１６に示した例では、ステップＳ１１２においては、サービスサーバ重点モードに設定される。ステップＳ１１２におけるモード設定に係わる処理を、NICE規格に基づいて行う場合、SetSceneModeというＡＰＩを用いることができる。

　ステップＳ１１２において、サービスサーバ重点モードに切り替えられることにより、図１１を参照して説明したように、センサデバイス１０は、センサ部１００で取得された画像データを、サービスサーバ２０に送信し、人検出処理は行わないモードになる。また、サービスサーバ２０側は、センサデバイス１０からの画像データを受信し、その画像データを用いて人検出処理を実行するモードになる。

　ステップＳ１１３において、センサデバイス１０は、サービスサーバ２０に画像データ（画像情報）を通知する。この通知を、NICE規格に基づいて行う場合、SetSceneMarkというＡＰＩを用いても良いし、SetSceneDataというＡＰＩを用いても良い。SetSceneDataは、基本的には、SetSceneMarkと同様であるが、SetSceneMarkはメタ情報を送信するのに対して、SetSceneDataは、データそのものを送信するという点が異なる。

　ステップＳ１１４において、サービスサーバ２０は、センサデバイス１０から送信されてきた画像情報を用いた検出処理を行う。ステップＳ１１３における画像情報の通知の処理と、ステップＳ１１４における検出処理は、繰り返し行われる。繰り返し行われることで、例えば人検出の処理が継続的に行われる。

　ステップＳ１２１において、センサデバイス１０は、サービスサーバ２０に対してセンサデバイス１０の情報を通知する。この通知は、継続不可能であることを示す通知である。センサデバイス１０が、サービスサーバ重点モードで稼働しているとき、例えばバッテリ１８０が充電されるなどの処理が行われなければ、バッテリ１８０の残量は減り続け、最終的には稼働できない残量まで減ってしまう可能性がある。

　このように、センサデバイス１０は、稼働不可能な状態となる前に、稼働不可能な状態になりそうだということを、サービスサーバ２０に対して通知する。このような通知を受け、サービスサーバ２０は、例えば、センサデバイス１０を管理する管理者に、センサデバイス１０の状態を通知する処理を実行する。

　なお、バッテリの残量が０になりそうなとき以外にも、熱が下がらない、さらに上がり続けているといったような場合にも通知が出されるようにすることができる。また、これら以外に、故障したとき、例えば、センサ部１００により画像が撮影できなくなったときなどにも、通知が出せる状態であれば、通知を出すようにしても良い。

　このように、正常に稼働できない状態になった、正常に稼働できない状態になりそうだといったときに、センサデバイス１０からサービスサーバ２０に通知を出すＡＰＩについては、NICE規格では未定義の通信である。このような通知を行うＡＰＩを、NICE規格に新たに定義することで、稼働状態を継続することが不可能な状態であることを示す通知をNICE規格でも行えるようにすることができる。

　＜モード遷移に係わる第１の処理について＞
　モード遷移の開始に係わる第１の処理について説明する。図１７は、モード遷移の開始を、センサデバイス１０側から指示（要求）を出す場合の処理について説明するためのフローチャートである。

　ステップＳ２０１において、センサデバイス１０の残量検出部１５２は、バッテリ１８０の残量を検知する。ステップＳ２０２において、熱検出部１５４は、センサデバイス１０の熱（ＣＰＵやＧＰＵの熱）を検知する。

　ステップＳ２０３において、モード切替制御部１５６は、検知された残量は、閾値以下であるか否か、または熱が閾値以上であるか否かを判定する。なお、残量に対する閾値と、熱に対する閾値は、異なる値である。ステップＳ２０３において、検知された残量は閾値以上であり、熱は閾値以下であると判定された場合、処理は、ステップＳ２０１に戻され、それ以降の処理が繰り返される。

　ステップＳ２０１乃至Ｓ２０３の処理は、所定の周期で繰り返し行われる。ここでは、センサデバイス重点モードのときに、ステップＳ２０３の処理が実行される場合を例に挙げて説明している。よって、ステップＳ２０３において、検知された残量は、閾値以下であるか否か、または熱が閾値以上であるか否かが判定されるとして説明している。サービスサーバ重点モードのときに、ステップＳ２０３の処理が実行される場合、検知された残量は、閾値以上であるか否か、また熱は閾値以下であるか否かが判定される処理となる。

　また、図１２や図１３を参照して説明したように、複数のモードがある場合、ステップＳ２０３の処理が行われる時点で設定されているモードに合った閾値との比較が行われ、判定が行われる。すなわち、閾値は、モード毎に設定されている。

　一方、ステップＳ２０３において、検知された残量は、閾値以下であると判定された場合、または／および、熱が閾値以上であると判定された場合、ステップＳ２０４に処理は進められる。

　ステップＳ２０４において、センサデバイス１０は、サービスサーバ２０に対して、モード変更の要求を出す。サービスサーバ２０は、ステップＳ２０５において、センサデバイス１０からのモード変更の要求を受け取ると、ステップＳ２０６において、変更後のモードを設定する。ステップＳ２０６においては、サービスサーバ２０側は、例えば、センサデバイス１０が実行していた認識モデルに基づく認識を開始できる状態にするとともに、センサデバイス１０に対して、設定されたモードに対応する認識モデルを送信する処理が実行される。

　センサデバイス１０は、ステップＳ２０７において、サービスサーバ２０からの認識モデルを受信することで、例えばサービスサーバ重点モードへと遷移する。ステップＳ２０４乃至Ｓ２０７の処理は、図１６のステップＳ１１１とステップＳ１２２において実行される処理に該当する。

　このように、センサデバイス１０側で、モード変更の要求を出すように構成することができる。

　＜モード遷移に係わる第２の処理について＞
　モード遷移の開始に係わる第２の処理について説明する。図１８は、モード遷移の開始を、サービスサーバ２０側で判定する場合の処理について説明するためのフローチャートである。

　ステップＳ２２１において、センサデバイス１０の残量検出部１５２は、バッテリ１８０の残量を検知する。ステップＳ２２２において、熱検出部１５４は、センサデバイス１０の熱（ＣＰＵやＧＰＵの熱）を検知する。

　ステップＳ２２３において、モード切替制御部１５６は、検知された残量が、閾値以上変化したか否か、または熱が閾値以上変化したか否かを判定する。ステップＳ２２１乃至Ｓ２２３の処理は、所定の周期で行われる。その検知間隔の間に、変化した変化量が、閾値以上変化したか否かが判定される。

　ステップＳ２２３においては、バッテリ１８０の残量の変化量が、閾値以上ではないと判定された場合、および熱の変化量も閾値以上ではないと判定された場合、ステップＳ２２１に処理が戻され、それ以降の処理が繰り返される。一方で、ステップＳ２２３において、バッテリ１８０の残量の変化量が、閾値以上であると判定された場合、または／および、熱の変化量が閾値以上であると判定された場合、ステップＳ２２４に処理が進められる。

　ステップＳ２２４において、センサデバイス１０は、サービスサーバ２０に対して、残量と熱に関する情報を送信する。このとき送信されるのは、バッテリ１８０の残量と、熱の情報である。ここでは、残量と熱に関する情報をサービスサーバ２０に送信するトリガとして、残量や熱の変化量が所定の閾値以上になった場合としている。このようなトリガを設けることで、頻繁にデータの授受が行われることを防ぐことができる。

　センサデバイス１０からの情報を、ステップＳ２２５において受信したサービスサーバ２０のモード切替制御部２５２は、ステップＳ２２６において、センサデバイス１０のバッテリ１８０の残量が閾値以下であるか、または熱が閾値以上であるかを判定する。ステップＳ２２６において、サービスサーバ２０は、センサデバイス１０のバッテリ１８０の残量は閾値以下ではなく、または熱も閾値以上ではないと判定した場合、モード遷移に関する処理としては何もせずに、そのままの状態を維持する。

　一方で、ステップＳ２２６において、センサデバイス１０のバッテリ１８０の残量が閾値以下である、または／および、熱が閾値以上であると判定された場合、ステップＳ２２７に処理は進められる。ステップＳ２２７において、変更後のモードへの設定が行われる。ステップＳ２２７以降の処理は、ステップＳ２０６（図１７）以降の処理と同様である。

　このように、センサデバイス１０は、所定のトリガにより、サービスサーバ２０に対して、バッテリの残量に関する情報と熱に関する情報を送信し、サービスサーバ２０側で、モードを変更するか否かの判定や、その判定に基づきモード変更の指示を出すように構成することができる。

　このように、センサデバイス１０側で、バッテリ１８０の残量の変化量を検知するようにした場合、バッテリ１８０の容量の減りの速さを観測することもできる。このような観測を利用し、バッテリ１８０の劣化を検出し、メンテナンス用の情報として用いるようにしても良い。例えば、バッテリ１８０の変化量が大きくなってきた場合、バッテリ１８０が劣化し始めていると判定し、センサデバイス１０を管理する管理者に通知が出されるような仕組みを設けることも可能である。

　＜モード遷移に係わる第３の処理について＞
　モード遷移の開始に係わる第３の処理について説明する。図１９は、モード遷移の開始を、サービスサーバ２０側で判定する場合の処理について説明するためのフローチャートである。

　ステップＳ２４１において、センサデバイス１０の残量検出部１５２は、バッテリ１８０の残量を検知する。ステップＳ２４２において、熱検出部１５４は、センサデバイス１０の熱（ＣＰＵやＧＰＵの熱）を検知する。

　ステップＳ２４３において、検知された残量と熱に関する情報が、サービスサーバ２０に送信される。ステップＳ２４１乃至Ｓ２４３の処理は、所定の周期で繰り返し行われる。すなわち、センサデバイス１０は、所定の周期毎に残量と熱に関する情報を、サービスサーバ２０に送信し、サービスサーバ２０は、所定の周期毎に、センサデバイス１０のバッテリの残量とデバイスの熱に関する情報を受信する。

　ステップＳ２４４において、センサデバイス１０からの情報を受信したサービスサーバ２０は、ステップＳ２４５において、センサデバイス１０のバッテリ１８０の残量が閾値以下であるか、または熱が閾値以上であるかを判定する。ステップＳ２４４以降の処理は、ステップＳ２２５（図１８）以降の処理と同様であるため、説明は省略する。

　このように、センサデバイス１０は、所定の周期で、サービスサーバ２０に対して、バッテリの残量に関する情報と熱に関する情報を送信し、サービスサーバ２０側で、モードを変更するか否かの判定や、その判定に基づきモード変更の指示を出すように構成することができる。

　このように、本技術によれば、センサデバイス１０のバッテリ１８０の残量やＣＰＵなどの発熱量に応じて、センサデバイス１０側で主に処理を行うモードと、サービスサーバ２０側で主に処理を行うモードとを切り替えることができる。換言すれば、本技術によれば、センサデバイス１０のバッテリ１８０の残量やＣＰＵなどの発熱に応じて、処理を分担し、その処理分担を最適化した状態で行うことができる。また、分担する処理は、ＡＩ機能による処理とすることができる。

　本技術によれば、センサデバイス１０が突然バッテリ切れや発熱により、機能が停止してしまうようなことを防ぐことができる。また、仮に機能が停止してしまうような状態になるとしても、そのような状態になるまでの時間を長くすることができる。

　上述した実施の形態では、バッテリの残量とデバイスの熱に応じてモードの遷移が起こる場合を例に挙げて説明したが、残量や熱に加えて、または残量は熱以外のトリガによりモード遷移が起こるようにしても良い。例えば、センサデバイス１０とサービスサーバ２０間の通信ネットワークのトラフィックに応じて、モードの切り替えが行われるようにしても良い。例えば、通信ネットワークのトラフィックが混んでいる場合には、センサデバイス１０とサービスサーバ２０間で授受されるデータ量が減少するようなモードに設定されるようにすることもできる。

　また、サービスサーバ２０の処理負荷が、モード切り替えのトリガとしても良い。サービスサーバ２０は、複数のセンサデバイス１０とデータの授受を行い、処理を行うため、サービスサーバ２０の処理負荷が大きくなる可能性がある。サービスサーバ２０の処理負荷が大きくなった場合には、サービスサーバ２０側で行う処理の一部を、センサデバイス１０側で行うモードに遷移するといった実施の形態にも適用できる。

　また、サービスサーバ２０側のメモリのリソース残量やストレージの残量などを、モード切り替えのトリガとしても良い。サービスサーバ２０のメモリのリソース残量やストレージの残量が、所定の閾値以下になった場合などサービスサーバ２０側での処理負担を軽減するモードに切り替えられるようにしたり、センサデバイス１０やサービスサーバ２０以外の装置のメモリやストレージを用いることができるモードに切り替えられたりする構成とすることもできる。

　上述した実施の形態において、センサデバイス１０とサービスサーバ２０との通信は、プラバシー保護のために暗号化されて行われるようにすることもできる。例えば、サービスサーバ重点モードのときには、センサデバイス１０から画像データがサービスサーバ２０に送信されるときもあるが、この送信される画像データは、暗号化がかけられたり、圧縮処理がかけられたりするようにすることもできる。

　＜記録媒体について＞
　上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

　図２０は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。コンピュータにおいて、ＣＰＵ（Central Processing Unit）５０１、ＲＯＭ（Read Only Memory）５０２、ＲＡＭ（Random Access Memory）５０３は、バス５０４により相互に接続されている。バス５０４には、さらに、入出力インタフェース５０５が接続されている。入出力インタフェース５０５には、入力部５０６、出力部５０７、記憶部５０８、通信部５０９、及びドライブ５１０が接続されている。

　入力部５０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部５０７は、ディスプレイ、スピーカなどよりなる。記憶部５０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部５０９は、ネットワークインタフェースなどよりなる。ドライブ５１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体５１１を駆動する。

　以上のように構成されるコンピュータでは、ＣＰＵ５０１が、例えば、記憶部５０８に記憶されているプログラムを、入出力インタフェース５０５及びバス５０４を介して、ＲＡＭ５０３にロードして実行することにより、上述した一連の処理が行われる。

　コンピュータ（ＣＰＵ５０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体５１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

　コンピュータでは、プログラムは、リムーバブル記録媒体５１１をドライブ５１０に装着することにより、入出力インタフェース５０５を介して、記憶部５０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部５０９で受信し、記憶部５０８にインストールすることができる。その他、プログラムは、ＲＯＭ５０２や記憶部５０８に、あらかじめインストールしておくことができる。

　なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

　＜移動体への応用例＞
　本開示に係る技術（本技術）は、様々な製品へ応用することができる。例えば、本開示に係る技術は、自動車、電気自動車、ハイブリッド電気自動車、自動二輪車、自転車、パーソナルモビリティ、飛行機、ドローン、船舶、ロボット等のいずれかの種類の移動体に搭載される装置として実現されてもよい。

　図２１は、本開示に係る技術が適用され得る移動体制御システムの一例である車両制御システムの概略的な構成例を示すブロック図である。

　車両制御システム１２０００は、通信ネットワーク１２００１を介して接続された複数の電子制御ユニットを備える。図２１に示した例では、車両制御システム１２０００は、駆動系制御ユニット１２０１０、ボディ系制御ユニット１２０２０、車外情報検出ユニット１２０３０、車内情報検出ユニット１２０４０、及び統合制御ユニット１２０５０を備える。また、統合制御ユニット１２０５０の機能構成として、マイクロコンピュータ１２０５１、音声画像出力部１２０５２、及び車載ネットワークＩ／Ｆ（Interface）１２０５３が図示されている。

　駆動系制御ユニット１２０１０は、各種プログラムにしたがって車両の駆動系に関連する装置の動作を制御する。例えば、駆動系制御ユニット１２０１０は、内燃機関又は駆動用モータ等の車両の駆動力を発生させるための駆動力発生装置、駆動力を車輪に伝達するための駆動力伝達機構、車両の舵角を調節するステアリング機構、及び、車両の制動力を発生させる制動装置等の制御装置として機能する。

　ボディ系制御ユニット１２０２０は、各種プログラムにしたがって車体に装備された各種装置の動作を制御する。例えば、ボディ系制御ユニット１２０２０は、キーレスエントリシステム、スマートキーシステム、パワーウィンドウ装置、あるいは、ヘッドランプ、バックランプ、ブレーキランプ、ウィンカー又はフォグランプ等の各種ランプの制御装置として機能する。この場合、ボディ系制御ユニット１２０２０には、鍵を代替する携帯機から発信される電波又は各種スイッチの信号が入力され得る。ボディ系制御ユニット１２０２０は、これらの電波又は信号の入力を受け付け、車両のドアロック装置、パワーウィンドウ装置、ランプ等を制御する。

　車外情報検出ユニット１２０３０は、車両制御システム１２０００を搭載した車両の外部の情報を検出する。例えば、車外情報検出ユニット１２０３０には、撮像部１２０３１が接続される。車外情報検出ユニット１２０３０は、撮像部１２０３１に車外の画像を撮像させるとともに、撮像された画像を受信する。車外情報検出ユニット１２０３０は、受信した画像に基づいて、人、車、障害物、標識又は路面上の文字等の物体検出処理又は距離検出処理を行ってもよい。

　撮像部１２０３１は、光を受光し、その光の受光量に応じた電気信号を出力する光センサである。撮像部１２０３１は、電気信号を画像として出力することもできるし、測距の情報として出力することもできる。また、撮像部１２０３１が受光する光は、可視光であっても良いし、赤外線等の非可視光であっても良い。

　車内情報検出ユニット１２０４０は、車内の情報を検出する。車内情報検出ユニット１２０４０には、例えば、運転者の状態を検出する運転者状態検出部１２０４１が接続される。運転者状態検出部１２０４１は、例えば運転者を撮像するカメラを含み、車内情報検出ユニット１２０４０は、運転者状態検出部１２０４１から入力される検出情報に基づいて、運転者の疲労度合い又は集中度合いを算出してもよいし、運転者が居眠りをしていないかを判別してもよい。

　マイクロコンピュータ１２０５１は、車外情報検出ユニット１２０３０又は車内情報検出ユニット１２０４０で取得される車内外の情報に基づいて、駆動力発生装置、ステアリング機構又は制動装置の制御目標値を演算し、駆動系制御ユニット１２０１０に対して制御指令を出力することができる。例えば、マイクロコンピュータ１２０５１は、車両の衝突回避あるいは衝撃緩和、車間距離に基づく追従走行、車速維持走行、車両の衝突警告、又は車両のレーン逸脱警告等を含むＡＤＡＳ（Advanced Driver Assistance System）の機能実現を目的とした協調制御を行うことができる。

　また、マイクロコンピュータ１２０５１は、車外情報検出ユニット１２０３０又は車内情報検出ユニット１２０４０で取得される車両の周囲の情報に基づいて駆動力発生装置、ステアリング機構又は制動装置等を制御することにより、運転者の操作に拠らずに自律的に走行する自動運転等を目的とした協調制御を行うことができる。

　また、マイクロコンピュータ１２０５１は、車外情報検出ユニット１２０３０で取得される車外の情報に基づいて、ボディ系制御ユニット１２０３０に対して制御指令を出力することができる。例えば、マイクロコンピュータ１２０５１は、車外情報検出ユニット１２０３０で検知した先行車又は対向車の位置に応じてヘッドランプを制御し、ハイビームをロービームに切り替える等の防眩を図ることを目的とした協調制御を行うことができる。

　音声画像出力部１２０５２は、車両の搭乗者又は車外に対して、視覚的又は聴覚的に情報を通知することが可能な出力装置へ音声及び画像のうちの少なくとも一方の出力信号を送信する。図２１の例では、出力装置として、オーディオスピーカ１２０６１、表示部１２０６２及びインストルメントパネル１２０６３が例示されている。表示部１２０６２は、例えば、オンボードディスプレイ及びヘッドアップディスプレイの少なくとも一つを含んでいてもよい。

　図２２は、撮像部１２０３１の設置位置の例を示す図である。

　図２２では、撮像部１２０３１として、撮像部１２１０１、１２１０２、１２１０３、１２１０４、１２１０５を有する。

　撮像部１２１０１、１２１０２、１２１０３、１２１０４、１２１０５は、例えば、車両１２１００のフロントノーズ、サイドミラー、リアバンパ、バックドア及び車室内のフロントガラスの上部等の位置に設けられる。フロントノーズに備えられる撮像部１２１０１及び車室内のフロントガラスの上部に備えられる撮像部１２１０５は、主として車両１２１００の前方の画像を取得する。サイドミラーに備えられる撮像部１２１０２、１２１０３は、主として車両１２１００の側方の画像を取得する。リアバンパ又はバックドアに備えられる撮像部１２１０４は、主として車両１２１００の後方の画像を取得する。車室内のフロントガラスの上部に備えられる撮像部１２１０５は、主として先行車両又は、歩行者、障害物、信号機、交通標識又は車線等の検出に用いられる。

　なお、図２２には、撮像部１２１０１ないし１２１０４の撮影範囲の一例が示されている。撮像範囲１２１１１は、フロントノーズに設けられた撮像部１２１０１の撮像範囲を示し、撮像範囲１２１１２，１２１１３は、それぞれサイドミラーに設けられた撮像部１２１０２，１２１０３の撮像範囲を示し、撮像範囲１２１１４は、リアバンパ又はバックドアに設けられた撮像部１２１０４の撮像範囲を示す。例えば、撮像部１２１０１ないし１２１０４で撮像された画像データが重ね合わせられることにより、車両１２１００を上方から見た俯瞰画像が得られる。

　撮像部１２１０１ないし１２１０４の少なくとも１つは、距離情報を取得する機能を有していてもよい。例えば、撮像部１２１０１ないし１２１０４の少なくとも１つは、複数の撮像素子からなるステレオカメラであってもよいし、位相差検出用の画素を有する撮像素子であってもよい。

　例えば、マイクロコンピュータ１２０５１は、撮像部１２１０１ないし１２１０４から得られた距離情報を基に、撮像範囲１２１１１ないし１２１１４内における各立体物までの距離と、この距離の時間的変化（車両１２１００に対する相対速度）を求めることにより、特に車両１２１００の進行路上にある最も近い立体物で、車両１２１００と略同じ方向に所定の速度（例えば、０km/h以上）で走行する立体物を先行車として抽出することができる。さらに、マイクロコンピュータ１２０５１は、先行車の手前に予め確保すべき車間距離を設定し、自動ブレーキ制御（追従停止制御も含む）や自動加速制御（追従発進制御も含む）等を行うことができる。このように運転者の操作に拠らずに自律的に走行する自動運転等を目的とした協調制御を行うことができる。

　例えば、マイクロコンピュータ１２０５１は、撮像部１２１０１ないし１２１０４から得られた距離情報を元に、立体物に関する立体物データを、２輪車、普通車両、大型車両、歩行者、電柱等その他の立体物に分類して抽出し、障害物の自動回避に用いることができる。例えば、マイクロコンピュータ１２０５１は、車両１２１００の周辺の障害物を、車両１２１００のドライバが視認可能な障害物と視認困難な障害物とに識別する。そして、マイクロコンピュータ１２０５１は、各障害物との衝突の危険度を示す衝突リスクを判断し、衝突リスクが設定値以上で衝突可能性がある状況であるときには、オーディオスピーカ１２０６１や表示部１２０６２を介してドライバに警報を出力することや、駆動系制御ユニット１２０１０を介して強制減速や回避操舵を行うことで、衝突回避のための運転支援を行うことができる。

　撮像部１２１０１ないし１２１０４の少なくとも１つは、赤外線を検出する赤外線カメラであってもよい。例えば、マイクロコンピュータ１２０５１は、撮像部１２１０１ないし１２１０４の撮像画像中に歩行者が存在するか否かを判定することで歩行者を認識することができる。かかる歩行者の認識は、例えば赤外線カメラとしての撮像部１２１０１ないし１２１０４の撮像画像における特徴点を抽出する手順と、物体の輪郭を示す一連の特徴点にパターンマッチング処理を行って歩行者か否かを判別する手順によって行われる。マイクロコンピュータ１２０５１が、撮像部１２１０１ないし１２１０４の撮像画像中に歩行者が存在すると判定し、歩行者を認識すると、音声画像出力部１２０５２は、当該認識された歩行者に強調のための方形輪郭線を重畳表示するように、表示部１２０６２を制御する。また、音声画像出力部１２０５２は、歩行者を示すアイコン等を所望の位置に表示するように表示部１２０６２を制御してもよい。

　本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

　なお、本明細書に記載された効果はあくまで例示であって限定されるものでは無く、また他の効果があってもよい。

　なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

　なお、本技術は以下のような構成も取ることができる。
（１）
　バッテリの残量または熱の少なくとも一方に応じて、モードを切り替えるモード切替部を備え、
　前記モード切替部は、第１の装置で所定の処理を実行する第１のモードと、第２の装置で前記所定の処理を実行する第２のモードとを切り替える
　情報処理装置。
（２）
　前記所定の処理は、ＡＩ（Artificial Intelligence）機能による処理である
　前記（１）に記載の情報処理装置。
（３）
　前記モード切替部は、前記第１の装置のバッテリの残量が所定の閾値以上であり、かつ前記第１の装置の熱が所定の閾値以下である場合、前記第１のモードを設定し、前記第１の装置のバッテリの残量が所定の閾値以下である場合、または／および前記第１の装置の熱が所定の閾値以上である場合、前記第２のモードを設定する
　前記（１）または（２）に記載の情報処理装置。
（４）
　前記第１のモードは、前記第１の装置で、前記ＡＩ機能による処理を実行するモードであり、前記第２のモードは、前記第２の装置で、前記ＡＩ機能による処理を実行するモードである
　前記（２）に記載の情報処理装置。
（５）
　前記第２のモードは、前記第１の装置と前記第２の装置で前記ＡＩ機能による処理を実行するモードである
　前記（２）に記載の情報処理装置。
（６）
　前記第１の装置は、前記バッテリの残量を検知し、前記残量が所定の閾値以下である場合、または前記熱を検知し、前記熱が所定の閾値以上である場合、前記第２の装置に、モード切替の指示を出す
　前記（１）乃至（５）のいずれかに記載の情報処理装置。
（７）
　前記第１の装置は、所定の周期毎に、前記バッテリの残量と前記熱を検知し、前記残量と前記熱に関する情報を、前記第２の装置に送信し、
　前記第２の装置は、前記残量と前記熱に関する情報に基づいて、前記モードを切り替えるか否かを判定する
　前記（１）乃至（５）のいずれかに記載の情報処理装置。
（８）
　前記第２のモードのとき、前記第１の装置は、前記第１のモードのときに前記第１の装置が行う第１の処理よりも処理負担が軽減された第２の処理を行い、前記第２の装置は、前記第１の装置が行う前記第１の処理を行う
　前記（１）乃至（７）のいずれかに記載の情報処理装置。
（９）
　前記第２のモードのとき、前記第１の装置は、前記第１のモードのときに前記第１の装置が行う第１の処理、または前記第１の処理よりも処理負担が軽減された第２の処理のどちらかの処理を選択的に切り替えて実行する
　前記（１）乃至（８）のいずれかに記載の情報処理装置。
（１０）
　前記バッテリの残量が継続不能な状態になるレベルまで減少した場合、前記第１の装置から前記第２の装置に通知が出される
　前記（１）乃至（９）のいずれかに記載の情報処理装置。
（１１）
　前記第１の装置は、センシングを行うセンサデバイスであり、前記第２の装置は、前記センサデバイスによりセンシングされた情報を取得するサーバである
　前記（１）乃至（１０）のいずれかに記載の情報処理装置。
（１２）
　情報処理装置が、
　バッテリの残量または熱の少なくとも一方に応じて、第１の装置で所定の処理を実行する第１のモードと、第２の装置で前記所定の処理を実行する第２のモードとを切り替える
　情報処理方法。
（１３）
　コンピュータに、
　バッテリの残量または熱の少なくとも一方に応じて、第１の装置で所定の処理を実行する第１のモードと、第２の装置で前記所定の処理を実行する第２のモードとを切り替える
　処理を実行させるためのプログラム。

　１　データ配信システム，　２　サービスサーバ，　１０　センサデバイス，　２０　サービスサーバ，　３０　ユーザデバイス，　４０　認証サーバ，　１００　センサ部，　１１０　測位部，　１３０　処理部，　１３２　ＩＤ送信部，　１３４　ｋｅｙ受信部，　１３６　センサデータ取得部，　１３８　前処理部，　１４０　モデル取得部，　１４２　認識部，　１４４　データ生成部，　１４６　配信部，　１５２　残量検出部，　１５４　熱検出部，　１５６　モード切替制御部，　１６０　記憶部，　１７０　通信部，　１８０　バッテリ，　２３０　処理部，　２３２　ＩＤ送信部，　２３４　リクエスト受付部，　２３６　能力情報取得部，　２３８　モデル生成部，　２４０　モデル送信部，　２４２　データ取得部，　２４３　認識部，　２４６　配信部，　２４８　認識部，　２５０　前処理部，　２５２　モード切替制御部，　２６０　記憶部，　２７０　通信部，　３０２　教師データ，　３１０　認識モデル

Claims

　バッテリの残量または熱の少なくとも一方に応じて、モードを切り替えるモード切替部を備え、
　前記モード切替部は、第１の装置で所定の処理を実行する第１のモードと、第２の装置で前記所定の処理を実行する第２のモードとを切り替える
　情報処理装置。
　前記所定の処理は、ＡＩ（Artificial Intelligence）機能による処理である
　請求項１に記載の情報処理装置。
　前記モード切替部は、前記第１の装置のバッテリの残量が所定の閾値以上であり、かつ前記第１の装置の熱が所定の閾値以下である場合、前記第１のモードを設定し、前記第１の装置のバッテリの残量が所定の閾値以下である場合、または／および前記第１の装置の熱が所定の閾値以上である場合、前記第２のモードを設定する
　請求項１に記載の情報処理装置。
　前記第１のモードは、前記第１の装置で、前記ＡＩ機能による処理を実行するモードであり、前記第２のモードは、前記第２の装置で、前記ＡＩ機能による処理を実行するモードである
　請求項２に記載の情報処理装置。
　前記第２のモードは、前記第１の装置と前記第２の装置で前記ＡＩ機能による処理を実行するモードである
　請求項２に記載の情報処理装置。
　前記第１の装置は、前記バッテリの残量を検知し、前記残量が所定の閾値以下である場合、または前記熱を検知し、前記熱が所定の閾値以上である場合、前記第２の装置に、モード切替の指示を出す
　請求項１に記載の情報処理装置。
　前記第１の装置は、所定の周期毎に、前記バッテリの残量と前記熱を検知し、前記残量と前記熱に関する情報を、前記第２の装置に送信し、
　前記第２の装置は、前記残量と前記熱に関する情報に基づいて、前記モードを切り替えるか否かを判定する
　請求項１に記載の情報処理装置。
　前記第２のモードのとき、前記第１の装置は、前記第１のモードのときに前記第１の装置が行う第１の処理よりも処理負担が軽減された第２の処理を行い、前記第２の装置は、前記第１の装置が行う前記第１の処理を行う
　請求項１に記載の情報処理装置。
　前記第２のモードのとき、前記第１の装置は、前記第１のモードのときに前記第１の装置が行う第１の処理、または前記第１の処理よりも処理負担が軽減された第２の処理のどちらかの処理を選択的に切り替えて実行する
　請求項１に記載の情報処理装置。
　前記バッテリの残量が継続不能な状態になるレベルまで減少した場合、前記第１の装置から前記第２の装置に通知が出される
　請求項１に記載の情報処理装置。
　前記第１の装置は、センシングを行うセンサデバイスであり、前記第２の装置は、前記センサデバイスによりセンシングされた情報を取得するサーバである
　請求項１に記載の情報処理装置。
　情報処理装置が、
　バッテリの残量または熱の少なくとも一方に応じて、第１の装置で所定の処理を実行する第１のモードと、第２の装置で前記所定の処理を実行する第２のモードとを切り替える
　情報処理方法。
　コンピュータに、
　バッテリの残量または熱の少なくとも一方に応じて、第１の装置で所定の処理を実行する第１のモードと、第２の装置で前記所定の処理を実行する第２のモードとを切り替える
　処理を実行させるためのプログラム。