JP7113270B1 - ロボット制御方法及び情報提供方法 - Google Patents

Abstract

Ｂ社サーバは、Ａ社サーバからロボットの動作を求めるリクエストを示すリクエスト情報を取得し、Ａ社サーバがリクエスト情報を要求するアクセス権を持つことが確認された場合、リクエスト情報を含む第１情報に基づいて、リクエストを実行、保留、又は却下することを決定し、リクエストを実行することが決定された後に、ユーザが運動することを働きかける動作を行わせるための指示情報をロボットに対して送信する。

Description

本開示は、ロボットの能力を外部に提供する技術に関するものである。

特許文献１は、ユーザの体調を配慮する自律型ロボットとして、ユーザの体温を測定し、測定した体温の周期に基づいてユーザの体調を判定する方法、および基礎体温周期が所定のタイミングとなった際にロボットの動作量を変更する方法が開示されている。

特許第６４９５４８６号公報

しかしながら、特許文献１の技術ではさらなる改善が必要である。

本開示の一態様におけるロボット制御方法は、ロボットと通信する第１サーバにおけるロボット制御方法であって、第２サーバから前記ロボットの動作を求めるリクエストを示すリクエスト情報を取得し、前記第２サーバにおいて、ユーザの情報端末から取得した前記ユーザの生体活動を示す生体活動情報に基づき前記ユーザに対して運動することを働きかける必要があるか否かが判定され、前記リクエスト情報は、前記第２サーバにおいて前記ユーザに対して運動することを働きかける必要があると判定された後に送信されるものであり、前記第１サーバにおいて、前記第２サーバが前記リクエスト情報を要求するアクセス権を持つことが確認された場合、前記リクエスト情報を含む第１情報に基づいて、前記リクエストを実行、保留、又は却下することを決定し、前記リクエストを実行することが決定された後に、前記ユーザが運動することを働きかける動作を行わせるための指示情報を前記ロボットに対して送信する。

本開示によればさらなる改善が可能となる。

本開示の実施の形態に係る情報システムの全体構成の一例を示すブロック図である。 本開示の実施の形態に係る情報システムの構成の一例を示すブロック図である。 本開示の一形態の形態に係る情報システムの全体構成の一例を示すブロック図である。 非ロボット会社（Ａ社）がロボットと連携する際の処理の一例を示すフローチャートである。 ロボットについてのアクセス権の設定情報の一例を示す表である。 リクエストされたタスクの実行可否を判断するための緊急度のレベルの一例を示す表である。 非ロボット会社がロボットに対してタスクをリクエストする処理の一例を示すフローチャートである。 非ロボット会社がロボットに対してタスクをリクエストする処理の一例を示すフローチャートである。 Ｂ社サーバの処理の一例を示すフローチャートである。 必要緊急度の設定例を示す表である。

（本開示に至る経緯）
我々の日常生活はますますデジタル化されてきている。例えば、多くの人が個人専用の情報通信端末であるスマートフォンを持つ。ユーザは、スマートフォンにユーザの健康管理を行うアプリケーション（以下、アプリケーションをアプリと呼ぶ）、家計の管理を支援するアプリ、知人とのリアルタイムなコミュニケーションを支援するソーシャルコミュニケーションアプリ、および世の中のニュースを個人の興味に合わせてキュレーションしてくれるニュースアプリなど様々なアプリをインストールして利用するようになった。

一方で、徐々にだが、自律的に種々の動作や作業を行うことができる可動装置（以下、ロボットと呼ぶ）も実用化されてきた。工場において部品の組み立てまたは調整を行うロボット、物流拠点において正確かつ迅速な仕分けを行うロボット、特定のタスクを周囲の状況を鑑みながら遂行するロボットなどである。これらのロボットには、人との共同作業、または人の代替として特定の作業を行ってくれるロボットもある。

本開示は、多様な情報処理を行うことができる情報処理装置であるスマートフォンと、多様な動作または物体を扱う作業を行うことができる可動装置であるロボットとが連携動作することによって、健康な、幸福な、快適な、安心な、安全な、愉しい、かつ／または清潔な生活をできるようにユーザを支援するための技術を提案する。

ユーザの生体活動情報を収集し、収集した生体活動情報からユーザの運動不足が確認された場合、ユーザのスマートフォンを通じてユーザを運動に誘導するメッセージを提示すれば、ユーザに運動を促すことが可能である。このように、ユーザに対して行動変容を促すメッセージはナッジと呼ばれる。

しかしながら、運動習慣のないユーザに対して運動への行動変容を起こさせることは容易ではなく、単にナッジをユーザに提示するだけでは不十分であり、ナッジよりも強い動機付けが必要である。

上述の特許文献１は、ロボットが、オーナーの体温からオーナーの月経周期を考慮に入れてオーナーに配慮すべき配慮タイミングを推定し、推定した配慮タイミングにおいてオーナーを見つめるといったオーナーを配慮する動作を行うことにより、普段は自由奔放にふるまっているロボットにオーナーを配慮させる行動をとらせ、それによってオーナーのロボットに対する共感を高める技術を開示する。

このように、特許文献１は、オーナーとロボットとの共感を高める技術であるので、ユーザに対して運動への強い動機づけを与えることはできない。

本開示は、このような課題を解決するためになされたものであり、ユーザに対して運動への強い動機付けを与えることができる技術を提供することを目的とする。

本開示の一態様におけるロボット制御方法は、ロボットと通信する第１サーバにおけるロボット制御方法であって、第２サーバから前記ロボットの動作を求めるリクエストを示すリクエスト情報を取得し、前記第２サーバにおいて、ユーザの情報端末から取得した前記ユーザの生体活動を示す生体活動情報に基づき前記ユーザに対して運動することを働きかける必要があるか否かが判定され、前記リクエスト情報は、前記第２サーバにおいて前記ユーザに対して運動することを働きかける必要があると判定された後に送信されるものであり、前記第１サーバにおいて、前記第２サーバが前記リクエスト情報を要求するアクセス権を持つことが確認された場合、前記リクエスト情報を含む第１情報に基づいて、前記リクエストを実行、保留、又は却下することを決定し、前記リクエストを実行することが決定された後に、前記ユーザが運動することを働きかける動作を行わせるための指示情報を前記ロボットに対して送信する。

上記態様により、アクセス権を通じて、第１サーバが管理するロボットの能力を、ロボットを管理していない第２サーバに対して一時的に利用させることができる。これにより、第２サーバは、ユーザに対して運動することを働きかける必要があると判断したときに、第１サーバが管理するロボットを通じて、ユーザに運動することを働きかけることができる。その結果、第２サーバは、自身がロボットを管理していないにも関わらず、ロボットに対してユーザが運動することを働きかける動作を行わせることができる。そのため、例えば、ユーザの情報端末のディスプレイに運動することを促すメッセージが表示されるに過ぎない場合に比して、運動することについてのより強い動機付けをユーザに対して与えることができる。

上記ロボット制御方法において、前記リクエスト情報は、さらに前記ユーザが運動する緊急性の程度を示す緊急度情報を含み、前記第１情報は、さらに、必要緊急度情報を含み、前記必要緊急度情報は、前記ロボットが前記リクエストを実行するために必要となる緊急性の程度を示すものであって、前記第１サーバにより管理されていてもよい。

上記態様により、リクエスト情報は、ユーザが運動する緊急性の程度を示す緊急度情報を含み、第１情報は、ロボットがリクエストを実行するために必要となる緊急性の程度を示す必要緊急度情報を含んでいるので、ユーザの運動に対する緊急性を考慮に入れて、ユーザに運動を促す行動をロボットにとらせることができる。

上記ロボット制御方法において、前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度以上である場合に、前記リクエストを実行することを決定してもよい。

上記態様により、緊急度情報が示す緊急性の程度が、必要緊急度情報が示す緊急性の程度以上である場合にリクエストが実行されるので、例えば、ユーザが仕事に集中しているなどの時間帯を外して、ロボットはユーザに運動を促す行動を実行することができる。これにより、ユーザが運動できないタイミングにおいて、ユーザに運動を促す行動をロボットにとらせることを防止できる。

上記ロボット制御方法において、前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度未満である場合に、前記リクエストを保留又は却下することを決定してもよい。

上記態様により、緊急度情報が示す緊急性の程度が、必要緊急度情報が示す緊急性の程度未満である場合に、リクエストが留保又は却下される。これにより、例えば、ユーザが仕事に集中するなど、ロボットに構っていられない状況下にある間に、ユーザに運動を促す行動をロボットにとらせることを防止できる。

上記ロボット制御方法において、前記リクエスト情報は、さらに、前記リクエスト情報に基づく決定を保留できる保留期間を示す保留期間情報を含み、前記保留期間において、前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度以上とならなかった場合に、前記リクエストを却下することを決定してもよい。

上記態様によれば、保留期間内に緊急度情報が示す緊急性の程度が必要緊急度情報が示す緊急性の程度以上とならなかった場合に、リクエストが却下されるので、ユーザの状態が運動を促すのに適切でない状態において、ユーザに運動を促す行動をロボットにとらせることを防止できる。例えば、夜遅くなってからユーザに運動を促す行動をロボットにとらせることを防止できる。

上記ロボット制御方法において、前記リクエスト情報は、さらに、前記リクエスト情報に基づく決定を保留できる保留期間を示す保留期間情報を含み、前記保留期間において、前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度以上となった場合に、前記リクエストを実行することを決定してもよい。

上記態様によれば、保留期間内に緊急度情報が示す緊急性の程度が必要緊急度情報が示す緊急性の程度以上となった場合、リクエストが実行されるので、ユーザの状態が運動を促すのに適切な状態になったときに、ユーザに運動を促す行動をロボットにとらせることができる。また、このような判定が保留期間内に行われているので、ロボットは無制限に運動を促すのではなく、保留期間に限って運動を促すことができる。

上記ロボット制御方法において、前記必要緊急度情報が示す緊急性の程度は、前記ロボットに設けられたセンサーのセンシング結果に基づき得られる前記ユーザから前記ロボットに向けられた発言を示す情報に基づき、決定されるものであり、前記発言に、前記ロボットとのコミュニケーションを取らない意図の発言が含まれる場合には、前記必要緊急度情報が示す緊急性の程度を所定のレベルまで引き上げてもよい。

上記態様によれば、ロボットとのコミュニケーションを取らない意図の発言をユーザが行うと、必要緊急度情報が示す緊急性の程度が引き上げられるので、リクエストが実行され難くなる。そのため、ユーザは忙しくてロボットに構っていられないような状態にあるときに、コミュニケーションを取らない意図の発言を行うだけで、ロボットによるリクエストの実行を回避することができる。

上記ロボット制御方法において、前記必要緊急度情報が示す緊急性の程度は、前記ロボットが取得した質問に対する前記ユーザからの回答を示す情報に基づき、決定され、前記質問は、前記ロボットのスピーカーから出力されたものであり、前記必要緊急度情報が示す緊急性の程度を前記ユーザに確認するためものであってもよい。

上記態様によれば、必要緊急度情報が示す緊急性の程度をユーザに確認する質問に対する回答に応じて必要緊急度情報が示す緊急性の程度が決定されるので、例えばユーザがロボットと関わりたくない状況下において、ロボットによりリクエストが実行されることを回避することができる。

上記ロボット制御方法において、前記必要緊急度情報が示す緊急性の程度は、前記ロボットに設けられたセンサーから取得された前記ユーザの画像を解析することにより得られる前記ユーザの行動に基づき、決定されるものであり、前記ユーザの行動が、電話中又はパソコン操作中である場合には、前記必要緊急度情報が示す緊急性の程度を所定のレベルまで引き上げてもよい。

上記態様によれば、ユーザが電話中又はパソコンの操作中であり、ロボットに構っていられない状態にある場合、ロボットによりリクエストが実行されることを回避することができる。

上記ロボット制御方法において、前記指示情報は、さらに、前記指示情報の有効期限を示す有効期限情報を含んでもよい。

上記態様によれば、ユーザに運動を促す行動を有効期限内に限ってロボットにとらせることができる。

上記ロボット制御方法において、前記決定されたタイミングからの経過時間が前記有効期限を超えた場合は、前記ロボットにおいて前記ユーザを運動に誘導することなく前記指示情報はキャンセルされてもよい。

上記態様によれば、リクエストの実行が決定されたタイミングからの経過時間が有効期限を超えた場合、指示情報はキャンセルされるので、ユーザに運動を促す行動をロボットが無制限にとることを防止できる。

上記ロボット制御方法において、前記ロボットから、前記指示情報に示される前記ユーザが運動することを働きかける動作が行われたことを示す情報を取得した後に、前記ユーザが運動した運動量である実施運動量情報を前記第２サーバに対して送信してもよい。

上記態様によれば、第２サーバは、ロボットの働きかけにより運動したユーザの運動量を示す実施運動量情報を管理することができる。

上記ロボット制御方法において、前記第１サーバは前記ロボットを管理する第１事業者により管理され、前記第２サーバは前記ユーザの情報端末から取得した前記生体活動情報を管理する第２事業者により管理され、前記第２事業者は前記第１事業者とは異なってもよい。

上記態様によれば、第１事業者が管理するロボットの能力を、ユーザの生体活動情報を管理する第２事業者に利用させることができる。

本開示の別の一態様における情報提供方法は、ロボットに対応する第１サーバと通信するとともに、ユーザの情報端末と通信する第２サーバにおける情報提供方法であって、前記ユーザの情報端末から前記ユーザの生体活動を示す生体活動情報を取得し、前記生体活動情報に基づき、前記ユーザに対して運動することを働きかける必要があるか否かを判定し、前記ユーザに対して運動することを働きかける必要があると判定された後に、前記ロボットの動作を求めるリクエストを示すリクエスト情報を前記第１サーバに送信し、前記第１サーバにおいて、前記第２サーバが前記リクエスト情報を要求するアクセス権を持つことが確認された場合、前記リクエスト情報を含む第１情報に基づいて、前記リクエストを実行、保留、又は却下することが決定され、前記リクエストを実行することが決定された後に、前記ユーザが運動することを働きかける動作を行わせるための指示情報を前記ロボットに対して送信される。

上記態様により、ユーザの生体活動に基づきロボットの外部からロボットに対して、ユーザへの働きかけを依頼してユーザに運動を促し、一方で、ロボットを介してユーザの状態を動的に監視しながら、ユーザへの働きかけを、ユーザの状態に応じた適切なタイミングでロボットに実行させることができる。その結果、ロボットが備える機能を超えてユーザの運動促進のためにロボットを活用できると共に、ユーザに不快感を与えない配慮をしつつユーザに運動の働きかけを実現できる。

上記情報提供方法において、前記リクエスト情報は、前記生体活動情報に基づき算出された前記ユーザが必要とする運動量を示す運動量情報を含み、前記リクエスト情報に基づいて前記ロボットが前記ユーザを運動に誘導したことにより前記ユーザが運動を行った後に、前記ユーザが運動した運動量である実施運動量情報を取得し、前記運動量情報及び前記実施運動量情報に基づき、前記ユーザの運動を評価する評価メッセージを作成し、前記評価メッセージを前記ユーザの情報端末に送信してもよい。

上記態様により、ロボットに運動を促された後にユーザが運動した場合、その運動に関する情報をユーザが共有できる。

上記情報提供方法において、前記運動量情報及び前記実施運動量情報に基づき、前記ユーザが運動した運動量が、前記ユーザが目標とする運動量以上であると判断された場合に、前記評価メッセージとして、前記ユーザが目標とする運動量を達成した旨のメッセージが作成されてもよい。

上記態様により、ユーザが目標とする運動量を達成した旨のメッセージをユーザが共有できる。

本開示の別の一態様におけるロボット制御方法は、ロボットと通信する第１サーバにおけるロボット制御方法であって、第２サーバから前記ロボットの動作を求めるリクエストを示すリクエスト情報を取得し、前記第２サーバにおいてユーザの情報端末から取得した前記ユーザの生体活動を示す生体活動情報に基づき前記ユーザに対して運動することを働きかける必要があるか否かが判定され、前記リクエスト情報は前記第２サーバにおいて前記ユーザに対して運動することを働きかける必要があると判定された後に送信されるものであり、前記ロボットから、前記ロボットにおいて検知した前記ユーザの状態に関わり動的に変化する状態データを取得し、前記リクエスト情報及び前記状態データに基づき、前記リクエスト情報に応じて前記ユーザが運動することを働きかける動作を行わせるための指示情報を前記ロボットに対して送信する。

上記態様により、前記ユーザの生体活動に基づき前記ロボットの外部から前記ロボットに対して、前記ユーザへの働きかけを依頼して前記ユーザに運動を促し、一方で、前記ロボットを介して前記ユーザの状態を動的に監視しながら、前記ユーザへの働きかけを、前記ユーザの状態との関係で適切なタイミングで前記ロボットに実行させることができる。その結果、前記ユーザの運動促進のために前記ロボットを活用できると共に、前記ユーザに不快感を与えない配慮をしつつ前記ユーザに運動の働きかけを実現できる。

上記ロボット制御方法において、前記状態データに基づき、前記ユーザが運動することを働きかけてよい状態に前記ユーザの状態がなった場合に、前記指示情報の送信を決定してもよい。

上記態様によれば、ユーザの状態が運動を働きかけてよい状態になったときに、ユーザに運動を促す行動をロボットにとらせることができる。

上記ロボット制御方法において、前記リクエスト情報は、さらに、前記リクエスト情報に応じた前記指示情報の決定を保留できる保留期間を示す保留期間情報を含み、前記保留期間において、前記ユーザが運動することを働きかけてよい状態に前記ユーザの状態がなった場合に、前記指示情報の送信を決定してもよい。

上記態様によれば、保留期間内において、ユーザの状態が運動を促すのに適切な状態になったときに、ユーザに運動を促す行動をロボットにとらせることができる。また、このような判定が保留期間内に行われているので、ロボットを用いて無制限に運動を促すのではなく、保留期間に限って運動を促すことができる。

上記ロボット制御方法において、前記保留期間において、前記ユーザが運動することを働きかけてよい状態に前記ユーザの状態がならなかった場合に、前記指示情報を送信しないことを決定してもよい。

ユーザの状態が運動を促すのに適切でない状態において、ユーザに運動を促す行動をロボットにとらせることを防止できる。例えば、夜遅くになってからユーザに運動を促す行動をロボットにとらせることを防止できる。

上記ロボット制御方法において、前記リクエスト情報は、前記ユーザが運動する緊急性の程度を示す緊急度情報を含み、前記状態データは、前記ロボットから取得した前記状態データの動的な変化に応じて変化する必要緊急度情報を含み、前記必要緊急度情報は前記ロボットが前記リクエストを実行するために必要となる緊急性の程度を示すものであってもよい。

上記態様により、前記リクエスト情報は、前記ユーザが運動する緊急性の程度を示す緊急度情報を含み、また、前記状態データは、前記ロボットから取得した前記状態データの動的な変化に応じて変化する必要緊急度情報を含んでいるので、ユーザの運動に対する緊急性を考慮に入れて、ユーザに運動を促す行動をロボットにとらせることができる。

上記ロボット制御方法において、前記緊急度情報及び前記必要緊急度情報に基づき、前記ユーザが運動することを働きかけてよい状態に前記ユーザの状態がなったか否かを判断してもよい。

上記態様により、第２サーバから取得される前記ユーザの生体活動に基づく固定値としてリクエスト情報に含まれる緊急度情報と、前記ロボットから取得した状態データの動的な変化に応じて変化する必要緊急度情報とに基づき、前記ユーザが運動することを働きかけてよい状態に前記ユーザの状態がなったか否かを判断することができる。

上記ロボット制御方法において、前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度以上である場合に、前記指示情報の送信を決定してもよい。

上記態様により、第２サーバから取得される前記ユーザの生体活動に基づく固定値としてリクエスト情報に含まれる緊急度情報と、前記ロボットから取得から取得した状態データの動的な変化に応じて変化する必要緊急度情報とに基づき、前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度以上である場合に、前記指示情報の送信を決定することができる。例えば、前記ユーザが仕事に集中しているなどの時間帯を外して、前記指示情報を前記ロボットに送信するので、前記ユーザが運動できないタイミングで前記ユーザへ運動を促すことを防止できる。

上記ロボット制御方法において、前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度未満である場合に、前記指示情報の送信の保留を決定してもよい。

上記態様により、前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度未満である場合に、前記指示情報の送信の留保を決定することができる。例えば、前記ユーザが仕事に集中している間は、前記指示情報を前記ロボットに送信しないので、前記ユーザへ運動を促すことはない。

上記ロボット制御方法において、前記第２サーバが前記リクエスト情報を要求するアクセス権を持つことが確認された場合、前記指示情報を前記ロボットに対して送信してもよい。

上記態様により、前記ロボットへのアクセス権のない外部からの遠隔指示を防止できる。

上記ロボット制御方法において、前記第１サーバにおいて前記第２サーバが前記アクセス権を有するか否かを登録しておき、前記登録に基づき、前記第２サーバが前記アクセス権を持つことを確認してもよい。

上記態様により、前記ロボットへのアクセス権のない外部からの遠隔指示を防止できる。

本開示のさらに別の一態様における情報提供方法は、ロボットに対応する第１サーバと通信するとともに、ユーザの情報端末と通信する第２サーバにおける情報提供方法であって、前記ユーザの情報端末から前記ユーザの生体活動を示す生体活動情報を取得し、前記生体活動情報に基づき、前記ユーザに対して運動することを働きかける必要があるか否かを判定し、前記ユーザに対して運動することを働きかける必要があると判定された後に、前記ロボットの動作を求めるリクエストを示すリクエスト情報を前記第１サーバに送信し、前記第１サーバにおいて、前記ロボットから前記ロボットにおいて検知した前記ユーザの状態に関わり動的に変化する状態データが取得され、前記リクエスト情報及び前記状態データに基づき前記リクエスト情報に応じて前記ユーザが運動することを働きかける動作を行わせるための指示情報が前記ロボットに対して送信される。

上記態様により、前記ユーザの生体活動に基づき前記ロボットの外部から前記ロボットに対して、前記ユーザへの働きかけを依頼して前記ユーザに運動を促し、一方で、前記ロボットを介して前記ユーザの状態を動的に監視しながら、前記ユーザへの働きかけを、前記ユーザの状態に応じた適切なタイミングで前記ロボットに実行させることができる。その結果、前記ロボットが備える機能を超えて前記ユーザの運動促進のために前記ロボットを活用できると共に、前記ユーザに不快感を与えない配慮をしつつ前記ユーザに運動の働きかけを実現できる。

上記情報提供方法において、前記リクエスト情報は、前記生体活動情報に基づき算出された前記ユーザが必要とする運動量を示す運動量情報を含み、前記リクエスト情報に基づいて前記ロボットが前記ユーザを運動に誘導したことにより前記ユーザが運動を行った後に、前記ユーザが運動した運動量である実施運動量情報を取得し、前記運動量情報及び前記実施運動量情報に基づき、前記ユーザの運動を評価する評価メッセージを作成し、前記評価メッセージを前記ユーザの情報端末に送信してもよい。

上記態様により、前記ロボットに運動を促された後に前記ユーザが運動した場合、その運動に関する情報を前記ユーザが共有できる。

上記情報提供方法において、前記運動量情報及び前記実施運動量情報に基づき、前記ユーザが運動した運動量が、前記ユーザが目標とする運動量以上であると判断された場合に、前記評価メッセージとして、前記ユーザが目標とする運動量を達成した旨のメッセージが作成されてもよい。

上記態様により、前記ユーザが目標とする運動量を達成した旨のメッセージを前記ユーザは共有することができる。

なお、本開示は、ここで用いられるロボット制御方法及び情報提供方法に含まれる特徴的な各構成をコンピュータに実行させるプログラム、或いはこのプログラムによって動作するシステムとして実現することもできる。また、このようなコンピュータプログラムを、ＣＤ－ＲＯＭ等のコンピュータ読取可能な非一時的な記録媒体あるいはインターネット等の通信ネットワークを介して流通させることができるのは、言うまでもない。

なお、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。以下の実施の形態で示される数値、形状、構成要素、ステップ、ステップの順序などは、一例であり、本開示を限定するものではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。また全ての実施の形態において、各々の内容を組み合わせることもできる。

（実施の形態）
我々の社会は、今後もさらにインターネットが普及し、各種センサーが身近になることが予想される。これにより、我々の社会は、個人の内部状態及び活動等に関する情報から建造物及び交通網等を含む街全体の情報までもが、デジタル化されてコンピューターシステムで利用できる状態になっていくと予想される。デジタル化された個人に関するデータ（個人情報）は、通信ネットワークを介してビッグデータとして情報銀行などのクラウドサーバに安全に管理され、個人や社会のために様々な用途に利用されていく。

このような高度情報化社会は、日本ではＳｏｃｉｅｔｙ５．０と呼ばれる。高度情報化社会は、個人を取り囲む物質世界である現実空間（フィジカル空間）とコンピュータ同士が連携してフィジカル空間に関する各種処理がなされる仮想空間（サイバー空間）とを高度に融合させた情報基盤（サイバーフィジカルシステム）により、経済発展と社会的課題の解決とが期待される社会である。

そうした高度情報化社会では、個人が行う日常の様々なシーンでのコミュニケーション（情報の取得、提供、およびその表現方法を含む）や行動を分析し、蓄積した個人情報を含むビッグデータを分析することで、そのシーンに応じた、その個人にとって最適と思われるコミュニケーションの方法にて、その個人に必要な情報またはサービスを提供することが可能になる。

以降では、そのようなサイバーフィジカルシステムが稼働する高度情報化社会を前提として、個人であるユーザに寄り添った日常生活の支援をテーマとして、ユーザの健康および幸福を高める具体的な様態について説明していく。

図１は、本開示の実施の形態に係る情報システムの全体構成の一例を示すブロック図である。図１は、上半分はサイバー空間、下半分はフィジカル空間を示している。左側は非ロボット提供会社であるＡ社関連のリソースが並んでおり、サイバー空間にはＡ社サーバ１０１、フィジカル空間にはスマートフォン１００の上で動作するＡ社アプリがある。Ａ社サーバ１０１はＡ社アプリとペアとなって動作する。右側はロボット提供会社であるＢ社関連のリソースが並んでおり、サイバー空間にはＢ社サーバ１１１、フィジカル空間には可動装置であるロボット１１０と、スマートフォン１００の上で動作するＢ社アプリとがある。Ｂ社サーバ１１１はロボット１１０かつ／またはＢ社アプリとペアになって動作する。フィジカル空間の真ん中にはスマートフォン１００にインストールされたＡ社アプリ、Ｂ社アプリ、さらにロボット１１０を扱うユーザがいる。スマートフォン１００、ロボット１１０、Ａ社サーバ１０１、およびＢ社サーバ１１１はインターネットのような広域通信網により相互通信が可能なように接続されている。

この図に示すようにＡ社およびＢ社はそれぞれのアプリおよびロボットを通じて、ユーザとの接点を持っている。Ａ社が持つのはスマートフォン１００上のアプリを介した接点だけであり、これは今日、多く見られる顧客接点の一形態である。一方で、この図のＢ社が持つのはスマートフォン１００上のアプリを介した接点だけでなく、ロボット１１０を介した接点もある。自律的な可動装置であるロボット１１０を介してユーザ（一般消費者）と接点を持つ会社は、一部の玩具メーカーを除くとまだ例がなく、これから出現してくるものと期待される。

なお、ここではロボット１１０の一例として犬型ロボットのイラストを用いているが、ロボット１１０はこれ以外の人間を含む生物に基づく形態でも、無機質で非生物的な形態であってもよい。フィジカル空間において自律的な運動能力（姿勢変更能力、および移動能力など）、かつ／または、作用能力（ボタンを押すおよび物を持ち上げるなど他の物体を動かす能力）がある限りは、その形態は限られない。

本開示の実施の形態である情報システムは、夫々の顧客接点であるアプリ、ロボット１１０、さらにはロボット１１０に操作される家電および住宅設備などがこれまで以上に高度に連携して、他が保有する情報および能力を活用しながら、自らのサービスの品質の上げ幅を広げ、ユーザへより高い価値提供を行う情報システムであるとも言える。ロボットが持つ認知能力および運動能力は日々進化を続けており、このような万能なロボットが実現すれば、そのロボットが保有する固有の能力に他社がアクセスできる仕組みを構築しておくべきである。そうすることが、ユーザにとっても、サービスを提供する非ロボット会社にとっても、ロボットを提供するロボット会社にとっても、多種多様な価値の連携を生む土台になると思われる。

図２は、本開示の実施の形態に係る情報システムの構成の一例を示すブロック図である。スマートフォン１００は、通信部１００ａ、演算部１００ｂ、センサー１００ｃ、メモリ１００ｄ、操作部１００ｅ、および映像音声出力部１００ｆを含む。センサー１１０ｃは、映像情報、音声情報、かつ／または周辺環境情報を取得するデバイスである。センサー１１０ｃは、例えば、イメージセンサーおよびマイクを含む。

映像音声出力部１００ｆは、映像および音声を出力するデバイスである。映像音声出力部１００ｆは、例えば、ディスプレイおよびスピーカーを含む。操作部１００ｅは、ユーザからのボタン押下やタッチ操作などを受け付けるデバイスである。操作部１００ｅは、例えばタッチパネルおよびボタンを含む。演算部１００ｂは、スマートフォン１００の中で行われる音声認識、音声合成、情報検索、および情報描画などの情報処理を行うデバイスである。演算部１００ｂは、例えば中央演算処理装置である。メモリ１００ｄは、演算部１００ｂが処理するデータを保持する。メモリ１００ｄは、例えば、フラッシュメモリなどの半導体メモリである。通信部１００ａは、ネットワーク上の他のコンピュータと情報通信を行う通信回路である。Ａ社アプリも、Ｂ社アプリもインストールされると、スマートフォン１００のメモリ１００ｄにプログラムと必要なデータとが記録され、演算部１００ｂによってそのプログラムが実行される。

Ａ社サーバ１０１は、スマートフォン１００にインストールされたＡ社アプリと協調動作する。Ａ社サーバ１０１は、通信部１０１ａ、演算部１０１ｂ、およびメモリ１０１ｃを含む。通信部１０１ａは、ネットワーク上の他のコンピュータと情報通信を行うための通信回路である。メモリ１０１ｃは、Ａ社アプリおよびユーザに関する情報を記録する。メモリ１０１ｃは、例えばハードディスクドライブおよびソリッドステートドライブなどの大容量記憶装置である。演算部１０１ｂは、外部とやり取りするデータの処理を行う。演算部１０１ｂは、例えば中央演算処理装置などのプロセッサである。

Ｂ社サーバ１１１は、スマートフォン１００にインストールされたＢ社アプリと協調動作する。Ｂ社サーバ１１１は、通信部１１１ａ、演算部１１１ｂ、およびメモリ１１１ｃを含む。通信部１１１ａは、ネットワーク上の他のコンピュータと情報通信を行うための通信回路である。メモリ１１１ｃは、Ｂ社アプリ、ロボット１１０、およびユーザに関する情報を記録する。メモリ１１１ｃは、例えばハードディスクドライブおよびソリッドステートドライブなどの大容量記憶装置である。演算部１１１ｂは、外部とやり取りするデータの処理を行う。演算部１１１ｂは、例えば中央演算処理装置などのプロセッサである。

ロボット１１０は、通信部１１０ａ、演算部１１０ｂ、センサー１１０ｃ、メモリ１１０ｄ、可動部１１０ｅ、および音声出力部１１０ｆを含む。センサー１１０ｃは、映像情報、音声情報、かつ／または周辺環境情報を取得するデバイスである。センサー１１０ｃは、例えばイメージセンサーおよびマイクを含む。音声出力部１１０ｆは、例えばスピーカーであり、音声を出力する。ロボット１１０は、ユーザからのボタン押下やタッチ操作などを受け付ける操作部（図示せず）を含んでもよい。可動部１１０ｅは、演算部１１０ｂの制御の下、ロボット１１０の姿勢を制御し、ロボット自体の移動および他物体への力学的作用を行うデバイスである。可動部１１０ｅは、例えばモータなどのアクチュエータである。演算部１１０ｂは、ロボット１１０の中で行われる各種演算処理を行う。演算部１１０ｂは、例えば、中央演算処理装置などのプロセッサである。メモリ１１０ｄは、演算部１１０ｂが処理するデータを保持する。メモリ１１０ｄは、例えばフラッシュメモリなどの半導体メモリである。通信部１１０ａは、ネットワーク上の他のコンピュータと情報通信を行うための通信回路である。

なお、Ａ社サーバ１０１、スマートフォン１００、ロボット１１０、およびＢ社サーバ１１１は広域通信網で相互通信できるよう接続されているとしたが、低遅延通信、強固なセキュリティ、またはローカルでのペアリングが要求される場合などには、専用通信網または近距離無線通信などにより接続されても良い。

（健康管理におけるロボットの能力提供）
ここからは、ユーザの健康管理を身近にあるロボット１１０を用いて、より効果的に実施する一実施の形態について説明していく。

図３は、本開示の一形態の形態に係る情報システムの全体構成の一例を示すブロック図である。この形態においては、非ロボット会社のＡ社はユーザが契約している健康保険の会社とする。保険会社であるＡ社は、ユーザの健康増進を図るためにスマートフォン１００にＡ社が提供するヘルスケアアプリをインストールさせ、ユーザに日々利用させる。Ａ社ヘルスケアアプリは、ユーザの生体活動情報（心拍、脈拍、血圧、体温、体水分量、呼吸、発汗量、活動量（消費カロリー）、摂取量（摂取カロリー）、歩数、姿勢、および運動種別など）をウェアラブルセンサーなどによって日々継続して収集し、その生体活動情報をスマートフォン１００のメモリ１００ｄに記録すると同時に、Ａ社サーバ１０１へ定期的にアップロードする（図中「（ａ）生体活動情報」）。

このようにして収集されたユーザの生体活動情報は、ユーザの個人情報としてＡ社サーバ１０１にて厳密に管理される。Ａ社サーバ１０１は定期的にユーザの生体活動情報に基づきユーザの健康リスクを分析する（図中「（ｂ）健康リスク分析」）。さらに、Ａ社サーバ１０１はユーザの運動量が不足していると判断された場合には、運動を推奨するためにナッジ（ｎｕｄｇｅ）をユーザに送る。例えば、Ａ社アプリを介して「運動しましょう」と望ましい行動をとるよう行動変容を起こすメッセージを表示させる（図中「（ｃ）運動の推奨」）。しかしながら、往々にしてこの手のアプローチによる行動変容は十分な動機を与えることに失敗し易く、ユーザの運動不足を解消できないことが多い（図中「（ｄ）運動せず」）。

これまでの情報化社会（Ｓｏｃｉｅｔｙ４．０社会とも呼ばれる）で提供される従来のサービスは、ここに説明した（ａ）から（ｄ）までのループについては実現できている。従来のサービスは、サイバー空間とフィジカル空間とが連携してユーザに持続的な接点を持って、健康増進を進めることは可能である。しかしながら、従来のサービスは、Ａ社のサービスの中だけでその生体活動情報およびサービスが閉じており、Ａ社以外との連携は無い。従来のサービスは、いわばサイロ状態となっている。Ａ社がスマートフォン１００に表示するメッセージの表現を多少変えても、なかなか行動変容を起こせないユーザも多いと思われる。したがって、従来のサービスは、広くユーザの健康を改善するサービスに成り得るには不十分である。本実施の形態においては、自律的運動能力を備えるユーザに身近なロボットを用いて、Ａ社アプリが保有しないがロボットならば保有する自律的運動能力を用いて、ユーザの健康をより良く改善するサービスを構想し、そのサービスの実現の形態について説明していく。それでは図３の続きの説明を行う。

Ａ社サーバ１０１（第２サーバの一例）が運動を推奨するようにナッジを送った後も、定期的にアップロードされる生体活動情報により、ユーザが十分な運動を行っていないとＡ社サーバ１０１が判断する場合、Ａ社サーバ１０１は事前に連携設定をしているＢ社サーバ１１１（第１サーバの一例）に対して、ユーザに運動（例えば散歩）を働きかけるタスクをロボット１１０にリクエストするリクエスト情報を送信する（図中「（ｅ）運動（散歩）を要望」）。すなわち、リクエスト情報は、Ｂ社サーバ１１１においてユーザに対して運動することを働きかける必要があると判定された後に送信される。サーバ間の事前の連携設定については後述する。

リクエスト情報を受信したＢ社サーバ１１１は、Ａ社サーバ１０１がリクエストしたタスクに対するアクセス権を持つことを確認すると、リクエストを実行、保留、又は却下することを決定する。そして、Ｂ社サーバ１１１は、リクエストを実行すると決定した場合、そのユーザが保有するロボット１１０に対して、ユーザを運動（散歩）に誘導する指示情報を出力する（図中「（ｆ）運動（散歩）を誘導指示」）。この指示情報は、具体的にどのように振る舞い何をユーザに要求するのかを、ユーザに理解できる形式でロボット１１０が提示するための指示を含む。例えば、ロボット１１０が受信する運動を誘導する指示情報には、犬型ロボットであれば「散歩に行こう」とユーザに直接的に呼び掛ける、または散歩時に用いるリードをロボット１１０が持ってきてユーザに散歩に行くことをせがむ（自らが散歩に行きたいという意志を示す）、などの指示が含まれる。これらの具体的な指示の内容は、Ｂ社サーバ１１１からロボット１１０に送られた運動を誘導するための指示情報に含まれ、ロボット１１０により実行される（図中「（ｇ）運動（散歩）を誘導」）。

このように犬型ロボットに一緒に運動（散歩）することを誘われたユーザは、スマートフォン１００を介して受け取った運動に関するナッジよりも強い動機付けを得る。その結果、ユーザはやっと運動（散歩）する（図中「（ｈ）運動（散歩）する」）。ここでのロボット１１０の運動への誘導方法には様々なバリエーションが考えられ、上記はその一例に過ぎない。例えば、ユーザが保有するロボット１１０が一緒に散歩をするには小さすぎる、または散歩をすると考えにくい生物（例えば、カエル）を模写してあった場合には、そのカエル型ロボットに「近くの川が見たい」などと言わせて、そこまでの道順をユーザの手の上に乗ったまま誘導する誘導方法が採用できる。

ロボット１１０は、指示情報により要求されたタスクが終わると、ユーザが運動（散歩）をしたことを示す情報、およびその走行距離または歩行速度の情報を含む実施運動量情報をＢ社サーバ１１１へ通知する。実施運動量情報を受信したＢ社サーバ１１１はＡ社サーバ１０１に、「（ｅ）運動（散歩）の要望」に対する最終結果として、実施運動量情報（例えば、歩行距離）を通知する（図中「（ｉ）運動量（歩行距離）を通知」）。

Ａ社サーバ１０１は実施運動量情報を記録し（図中「（ｊ）運動量（歩行距離）を記録」）、実施運動量情報に基づき、ユーザの運動を称賛し、ユーザの運動に対するモチベーションを高めるために「５０００歩、達成」などの、ユーザの運動を評価する評価メッセージをＡ社アプリを通じてユーザに提示する（図中「（ｋ）運動の評価」）。

なお、Ａ社アプリまたはＡ社サーバ１０１は、図中「（ｋ）運動の評価」のような評価メッセージを、Ｂ社サーバ１１１から得た実施運動量情報に基づかずに、ユーザにフィードバックしてもよい。例えば、Ａ社サーバ１０１は、ユーザが装着する歩数センサーから生体活動情報「図中（ａ）生体活動情報」を得ることにより、スマートフォン１００の画面に評価メッセージを表示すればよい。

ユーザの運動量を増やすような行動変容を起こすことは、Ａ社が持つ顧客接点であるスマートフォン１００上の映像情報および音声情報などのメッセージだけでは難しい面があった。Ａ社がＢ社の提供する犬型ロボットを介して、散歩をせがむこと、さらにはその犬型ロボットが一緒に散歩することで、運動（散歩）に対するユーザの心理的障壁を低くし、ユーザの運動量を増加させることができる。またこれにより、ユーザはより良く健康維持ができると期待できる。

このようにロボット１１０がユーザに行動変容を求める場合には、ロボット１１０があたかも１つの生命体であるかのように自らの意志または要望（散歩に行きたい）をユーザに伝えることで、ユーザはその生命体（ロボット）が要望している事をやらせてあげようと思うことがある。これはユーザが持つ健康を維持したいという利己的欲求だけに基づいてユーザに行動変容を求めるのではなく、１つの意志を持つ生命体であるロボットの要望を叶えるという利他的欲求にも基づいてユーザに行動変容を求めているからである。ここで開示したユーザの健康維持のサービスは、これまでＡ社が単独で実施できる利己的欲求によるアプローチだけでなく、Ｂ社のロボット１１０と連携することにより初めて実現可能となる利他的欲求を合わせたアプローチである。

この情報システムは、夫々の顧客接点であるアプリまたはロボット１１０がより高度に連携して、他が保有する情報および能力を活用しながら、自らのサービスの品質を上げ、ユーザへより高い価値提供を行う情報システムであるとも言える。ロボットが持つ認知能力および運動能力は日々進化を続けており、このような万能なロボットが実現すれば、そのロボットが保有する固有の能力に他社がアクセスできる仕組みを構築しておくべきである。そうすることが、ユーザにとっても、サービスを提供する非ロボット会社（Ａ社）にとっても、ロボット１１０を提供するロボット会社（Ｂ社）にとっても、多種多様な価値の連携を生む土台になる。

図４は、非ロボット会社（Ａ社）がロボット１１０と連携する際の処理の一例を示すフローチャートである。図３で説明したようなＡ社アプリまたはＡ社サーバ１０１が、Ｂ社が運用するロボット１１０が持つ情報および能力にアクセスするには、事前にそのアクセス権を適切に設定しておく必要がある。図４はそのアクセス権を予め設定しておくための処理の一例を示している。

ユーザはスマートフォン１００にインストールされたＢ社アプリを使って、Ｂ社アプリがＡ社アプリとの連携するように設定する。具体的には、Ｂ社アプリは、ユーザの入力に基づいて、ユーザの利用するＡ社アプリの固有ＩＤを取得する（ステップＳ１）。Ｂ社アプリは、取得したＡ社アプリの固有ＩＤをＢ社アプリの固有ＩＤと共に、Ｂ社サーバ１１１に登録するための登録依頼を送信する（ステップＳ２）。登録依頼を受信したＢ社サーバ１１１は、Ａ社アプリとＢ社アプリとのペア情報を登録する。この登録処理では、同時にロボット１１０のどの固有能力に対してどこまでの利用権利をＡ社に許諾するかを示すアクセス権の登録も行われる（ステップＳ３）。アクセス権の詳細については図５を用いて後述する。ロボット１１０のロボットＩＤとＢ社アプリの固有ＩＤとを含むペア情報は予めＢ社サーバ１１１に登録されている。この登録は、例えばユーザがＢ社アプリの初期設定画面において、ロボット１１０の固有ＩＤを入力することによって行われる。

Ａ社アプリの登録を受け取ったＢ社サーバ１１１は、Ａ社サーバ１０１に対してＡ社アプリが許可されるアクセス権の設定情報を通知する（ステップＳ４）。具体的には、Ｂ社サーバ１１１は、Ａ社アプリの固有ＩＤとＢ社アプリの固有ＩＤとのペア情報に加えて、そのアクセス権の設定情報をＡ社サーバ１０１に通知する。

Ａ社サーバ１０１は、Ａ社アプリの固有ＩＤとＢ社アプリの固有ＩＤとのペア情報、およびそのアクセス権の設定情報をメモリ１０１ｃに登録する（ステップＳ５）。これらの情報は、Ａ社アプリまたはＡ社サーバ１０１がＢ社の提供するロボット１１０に対してその固有能力を利用する際に、対象のロボット１１０を特定すると共に、その固有能力の利用が可能か否かを判定するために用いられる。

ここでは、Ａ社アプリまたはＡ社サーバ１０１に対して、Ｂ社が提供するロボット１１０へのアクセス権を正しく設定できれば良く、上記はその一例に過ぎない。上記とは異なる登録方法が用いられてもよい。

図５は、ロボット１１０についてのアクセス権の設定情報の一例を示す表である。Ａ社はＢ社のロボット１１０に対して様々なタスクをリクエストできる。さらに、ロボット１１０は、様々なセンサー１１０ｃおよび運動能力（可動部１１０ｅ）を具備しており、それらに対するＡ社からのアクセス権は、Ｂ社サーバ１１１だけでなく、利用する側であるＡ社サーバ１０１にも登録される。以下、アクセス権の種類とその許可レベルとについて、説明する。このアクセス権の設定は、図４のステップＳ３においてユーザにより行われる。

アクセス権の種類は「タスク」、「センサー」、および「運動能力」に分類される。「タスク」はさらに「運動の勧誘」および「会話」に分類される。「センサー」はさらに「カメラ映像」、「測距センサー」、「赤外線センサー」、「マイク音声」、「触覚センサー」、「気温・湿度・気圧センサー」、および「位置センサー」に分類される。「運動能力」はさらに「表情変更能力」、「発声能力」、「姿勢変更能力」、および「移動能力」に分類される。

「タスク」に属する「運動の勧誘」は、ロボット１１０に対して、ユーザに運動を働きかけるタスクについて、非ロボット会社（Ａ社）がとの範囲までリクエストできるかを表すアクセス権である。ここで言う運動は、例えば、散歩、ジョギング、スクワット、腕立て伏せ、スイミング、およびヨガなどであり、特に種類は問わない。ここでは、説明の都合上、リクエストできる場合にはアクセス権があるとし、リクエストできない場合にはアクセス権がないと表現する。「運動の勧誘」へのアクセス権は以下の通り、アクセス権のない「０」から、制約なくアクセス権がある「２」まで段階的に設定される。例えば、このアクセス権の許可レベルが「１」である非ロボット会社（Ａ社）からの「運動の勧誘」タスクのリクエストに対して、ロボット運用会社（Ｂ社）は、所定運動負荷以下の軽い運動に対するリクエストのみ許可し、許可した範囲内でロボット１１０かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：軽い運動のみ許可
２：すべて許可
同じく「タスク」に属する「会話」は、ロボット１１０を介してユーザと会話をすることを非ロボット会社（Ａ社）がどの範囲までリクエストすることができるかを表すアクセス権である。「会話」へのアクセス権は以下の通り、アクセス権のない「０」か、アクセス権がある「１」の２択で設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からの「会話」タスクのリクエストに対しては、ロボット運用会社（Ｂ社）はアクセス権があるとして許可する。ロボット運用会社（Ｂ社）は、ロボットに具備されたマイク（センサー１１０ｃの「マイク音声」）とスピーカー（運動能力の「発声能力」）とを非ロボット会社（Ａ社）に対して利用可能に設定する。これにより、非ロボット会社（Ａ社）は、ユーザとロボット１１０とが会話ができるよう、ロボット１１０かつ／またはＢ社サーバ１１１を制御する。したがって、「会話」タスクへのアクセス権がある場合には、センサー１１０ｃの「マイク音声」および運動能力の「発声能力」に対してもアクセス権があるように連動して、設定される。

０：不許可
１：許可
タスクは上記の説明のように、非ロボット会社からロボット会社が何らかのタスクをロボット１１０で実行するリクエストを受けた際に、そのリクエストを実行するかを判定するために用いられる。そのため、図５のアクセス権の設定情報は非ロボット会社ごとに設定される。

尚、本開示においては、ロボット１１０が、非ロボット会社からのリクエストに基づき、ユーザかつ／またはリアル空間の対象物体（例えば、テレビのリモコン、照明のスイッチ、または扉のノブ）に対して何らかの働きかけまたは作用を行う一連の自律的な動作をタスクと呼ぶこととする。

「カメラ映像」は、ロボット（１１０）が具備するイメージセンサー（例えば、ＲＧＢイメージセンサー）へのアクセス権である。これは、ロボットの目と外見上認知される個所に具備されているイメージセンサーであってもよい。「カメラ映像」へのアクセス権は、以下の通り、アクセス権のない「０」から制約なくアクセス権が付与される「３」まで段階的に設定することができる。例えば、この許可レベルが「２」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）は低品質動画映像を返すようにロボット（１１０）かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：静止画のみ許可
２：低品質動画まで許可
３：すべて許可
「測距センサー」は、ロボット１１０が具備する対象物までの距離が測定できるセンサー１１０ｃ（例えば、ＴＯＦセンサー、ＬｉＤＡＲなど）へのアクセス権である。「測距センサー」へのアクセス権は、以下の通り、アクセス権のない「０」か、アクセス権がある「１」の２択で設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）は測距センサーが取得したデータ（例えば、デプスイメージ）を返すようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：許可
「赤外線センサー」は、ロボット１１０が具備する赤外線が測定できるセンサーへのアクセス権である。赤外線センサーは、近赤外線領域においては暗闇での被写体認識、遠赤外線領域においては被写体温度分布の測定などに使われる。「赤外線センサー」へのアクセス権は、以下の通り、アクセス権のない「０」か、アクセス権がある「１」の２択で設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）は、赤外線センサーが取得したデータ（例えば、サーモグラフィー映像）を返すようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：許可
「マイク音声」は、ロボット１１０が具備するマイクへのアクセス権である。「マイク音声」へのアクセス権は、以下の通り、アクセス権のない「０」か、アクセス権がある「１」の２択で設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）はマイクが取得した音声データを返すようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：許可
「触覚センサー」は、ロボット１１０が具備するロボット表面での触覚感覚が測定できるセンサー（例えば、ＭＥＭＳシリコン毛デバイスセンサー）へのアクセス権である。「触覚センサー」へのアクセス権は以下の通り、アクセス権のない「０」か、制約なくアクセス権が付与される「２」まで段階的に設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）は触覚センサーが取得したデータ（例えば、圧力分布映像）の内、ロボットの一部分（例えば、頭部）のデータのみを返すようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：一部分のみ許可
２：すべて許可
「気温・湿度・気圧センサー」は、ロボット１１０が具備する気温センサー、湿度センサー、および気圧センサーへのアクセス権である。「気温・湿度・気圧センサー」へのアクセス権は、以下の通り、アクセス権のない「０」か、アクセス権がある「１」の２択で設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）は気温・湿度・気圧センサーが取得した夫々のデータを返すようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：許可
「位置センサー」は、ロボット１１０が具備するロボットの現在位置を測定するセンサーへのアクセス権である。「位置センサー」へのアクセス権は以下の通り、アクセス権のない「０」か、アクセス権がある「１」の２択で設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）は位置センサーが取得したロボットの現在位置情報を示すデータを返すようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：許可
ここまでがロボット１１０に具備されたセンサー１１０ｃへのアクセス権に対する説明である。続いて、ロボットが具備する運動能力へのアクセス権について説明する。

「表情変更能力」は、ロボット１１０が具備する顔の外見的特徴を変更する能力へのアクセス権である。これは、ロボット１１０に、外見上、顔と認識できる部分がある場合に、その顔を構成するパーツを動かす能力、またはパーツの色を変更する能力であってもよい。「表情変更能力」へのアクセス権は、以下の通り、アクセス権のない「０」か、アクセス権がある「１」の２択で設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）は顔表情の変更要求に応じて顔表情を変更するようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：許可
「発声能力」は、ロボット１１０が具備する音声出力能力へのアクセス権である。これは、ロボット１１０に、外見上、口と認識できる部分がある場合に、その口を構成するパーツを動かす能力、またはその口の周辺部から音声を出力する能力であってもよい。「発声能力」へのアクセス権は、以下の通り、アクセス権のない「０」か、アクセス権がある「１」の２択で設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）は発声するべき音声情報に応じて口の周辺部から音声を出力するようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：許可
「姿勢変更能力」は、ロボット１１０が具備する姿勢を変更する能力へのアクセス権である。これは、ロボット１１０の可動部１１０ｅにある複数の関節機構部の角度を変更する能力であってもよい。ただし、ロボット１１０自体の位置を変える能力ではない。「姿勢変更能力」へのアクセス権は、以下の通り、アクセス権のない「０」から制約なくアクセス権が付与される「２」まで段階的に設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）は頭部のみを要求に応じて動かすようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。

０：不許可
１：頭部のみ許可
２：すべて許可
「移動能力」は、ロボット１１０が具備する移動する能力へのアクセス権である。これは、ロボット１１０の可動部１１０ｅにある複数の関節機構部の角度を変更する能力であってもよい。ただし、「移動能力」は、ロボット１１０自体の位置を変える能力である。「移動能力」へのアクセス権は、以下の通り、アクセス権のない「０」から制約なくアクセス権が付与される「４」まで段階的に設定することができる。例えば、この許可レベルが「１」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）は、ユーザ宅の中でユーザが許可したエリアのみを低速で移動することを許可するようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。例えば、この許可レベルが「３」である非ロボット会社（Ａ社）からのアクセス要求に対しては、ロボット運用会社（Ｂ社）はユーザが許可した宅内、宅外のエリアのみを高速で移動することを許可するようにロボット１１０かつ／またはＢ社サーバ１１１を制御する。ここでユーザが許可したエリアは、ユーザがあらかじめ設定しておく条件の１つである。例えば、ユーザのプライバシーを侵害してしまう恐れのあるエリア（例えばお風呂場）にはロボットが近寄れないよう予め設定しておくことができる。

０：不許可
１：許可済み宅内のみ、低速での移動を許可
２：許可済み宅内/宅外まで、低速での移動を許可
３：許可済み宅内/宅外まで、高速での移動を許可
４：すべて許可
図６は、リクエストされたタスクの実行可否を判断するための緊急度のレベルの一例を示す表である。図３の説明でＡ社サーバ１０１がＢ社サーバ１１１に対して運動を要請するリクエスト情報を送信し（「（ｅ）運動（散歩）を要望」）、これに伴いＢ社サーバ１１１がロボット１１０に対して運動を要請する指示情報を送信する（「（ｆ）運動（散歩）を誘導指示」）シーンがある。このシーンにおいて送信されるリクエスト情報は緊急度情報を含む。緊急度情報は、ユーザが運動する緊急性の程度（緊急度）を示す情報である。リクエスト情報を受信するＢ社サーバ１１１は、必要緊急度情報を管理している。必要緊急度情報は、リクエストされたタスクをロボット１１０が実行するために必要となる緊急性の程度（必要緊急度）を示す情報である。

必要緊急度は、ユーザが何か特定の作業に集中している時など、他社（例えばＡ社）からロボット１１０を介して要求されたユーザへの緊急度の低いリクエストを無効化、またはその働きかけが適当なタイミングになるまでリクエストの実行を保留させるために用いられる。必要緊急度情報は、Ｂ社サーバ１１１またはロボット１１０により保有され、Ｂ社サーバ１１１またはロボット１１０により使用される情報である。他社（例えばＡ社）がロボット１１０に対して要求するリクエスト情報に含まれる緊急度情報が示す緊急度も、必要緊急度情報と同じ基準で必要緊急度が設定されている。必要緊急度は、図６に示すように高、中、低というように段階的に設定されてもよい。

「高」：必要緊急度が「高」の場合、生命、健康、危険、または財産の損失リスクに関するような緊急性の高い情報をユーザに通知するリクエストが処理される。そうでなければ、リクエストは保留または却下される。

「中」：必要緊急度が「中」の場合、必要緊急度が「高」に分類されるリクエストに加えて、日常生活における重要な情報をユーザに通知するリクエストが実行される。そうでなければ、リクエストは保留または却下される。日常生活における重要な情報は、例えば次のスケジュールをユーザに通知するための情報および重大な損失リスクがある状態（例えばガスコンロつけっ放し）をユーザに通知するための情報を含む。

「低」：必要緊急度が「低」の場合、すべてのリクエストが実行される。

このように、必要緊急度が高く設定されると、他社サーバ（Ａ社サーバ１０１）からＢ社サーバ１１１が受け取ったリクエストの内、ユーザにとって重要で緊急性のあるリクエストだけが即座に処理される。それ以外のリクエストは保留または却下される。ユーザにとって重要で緊急性のあるリクエスト情報に含まれる緊急度情報は、発信元の他社（Ａ社）によって上記必要緊急度の定義に従い、付与される。

より具体的には、他社サーバ（例えばＡ社サーバ１０１）が送信したリクエスト情報に含まれる緊急度情報（高、中、または低）が、Ｂ社（例えばＢ社サーバ１１１）に設定されている必要緊急度情報（高、中、または低）以上であれば、そのリクエスト情報が示すリクエストは即座に処理される。そうでなければ、そのリクエストは即座に実行されず、適切なタイミングまで保留または却下される。

以上、図３に示した健康管理におけるロボット１１０の能力提供のシナリオを実現するために、Ａ社およびＢ社間の連携設定と、Ａ社のロボット能力へのアクセス権と、リクエストの緊急度について説明した。ここからは、これらを用いてこのシナリオを実現する処理全体の流れを説明していく。

図７は、非ロボット会社がロボット１１０に対してタスクをリクエストする処理の一例を示すフローチャートである。特に、図７は、リクエストが即座に実施されるケースを示している。

図３でも説明したようにスマートフォン１００にインストールされた保険会社Ａ社のアプリケーション（Ａ社アプリ）は、ユーザの生体活動情報を継続的に検出し、検出した生体活動情報をスマートフォン１００内のメモリに蓄積する（ステップＳ１１）。さらに、Ａ社アプリは、蓄積した生体活動情報を定期的にＡ社サーバ１０１へアップロードする（ステップＳ１２）。生体活動情報を受信したＡ社サーバ１０１は、ユーザとＡ社との保健契約に基づき、ユーザに運動を推奨するメッセージ（ナッジ）の送信の必要性を判定する（ステップＳ１３）。ナッジの送信の必要性があると判定した場合、Ａ社サーバ１０１は、ナッジを送信する（ステップＳ１４）。逆に、運動を推奨するメッセージの送信の必要性がないと判断した場合、Ａ社サーバ１０１は、Ａ社アプリからアップロードされるユーザの生体活動情報を蓄積する処理を継続する。

ステップＳ１５において、スマートフォン１００は、運動を推奨するメッセージを表示する。これにより、運動を推奨するメッセージがユーザに提示される。

ステップＳ１６において、Ａ社アプリかつ／またはＡ社サーバ１０１は、運動を推奨するメッセージを表示した後においても、ユーザの生体活動情報を継続的に検出し、検出した生体活動情報に基づいてユーザの運動量を算出し、算出したユーザの運動量を評価する。

Ａ社サーバ１０１は、ユーザとＡ社との保健契約に基づき、ユーザに対して運動を推奨するさらに強い働きかけの必要性を判定する。ここで、Ａ社アプリかつ／またはＡ社サーバ１０１は、ステップＳ１６で算出したユーザの運動量が目標運動量未満である状態が所定回数以上観測された場合、ナッジによりユーザの運動量が改善されなかったので、さらに強い働きかけ必要性があると判定する。ここでは、強い働きかけの必要性があると判定されたものとする。逆に、さらに強い働きかけの必要性がないと判定された場合、Ａ社サーバ１０１は、Ａ社アプリからアップロードされたユーザの生体活動情報を蓄積する処理を継続する。ここで、Ａ社アプリかつ／またはＡ社サーバ１０１は、例えばステップＳ１６で算出したユーザの運動量が目標運動量未満である状態が所定回数以上観測されなかった場合、さらに強い働きかけの必要性はないと判定する。

ステップＳ１７において、さらに強い働きかけの必要があると判定したＡ社サーバ１０１は、Ｂ社サーバ１１１に、ユーザに運動を働きかけるタスクをロボット１１０にリクエストするリクエスト情報を送信する。

リクエスト情報は、ユーザのＡ社アプリの固有ＩＤ、リクエストの緊急度を示す緊急度情報、リクエストを実行するまでの保留期間を示す保留期間情報、およびリクエストの内容を含む。リクエストの内容は例えばロボット１１０にリクエストするタスクを示す。リクエスト情報を受信したＢ社サーバ１１１は、リクエスト情報に含まれるユーザのＡ社アプリの固有ＩＤから、Ａ社アプリの固有ＩＤに対応するＢ社アプリの固有ＩＤを特定することができる。Ｂ社サーバ１１１は、Ｂ社アプリの固有ＩＤに対応するロボット１１０のロボットＩＤを管理しているので、Ａ社からリクエストされたタスクを実行するべきロボット１１０を一意に特定することができる。

さらに、リクエスト情報は、ユーザに必要とされる目標運動量を含む。目標運動量は、例えば１日あたり５０００歩または１日あたりの消費カロリー１５０Ｋｃａｌなどである。この例では、目標運動量は１日あたり５０００歩であり、現時点でのユーザの１日あたりの運動量は２０００歩である。Ａ社サーバ１０１は、１日あたり５０００歩の散歩をユーザに促すために、Ｂ社サーバ１１１に対してリクエスト情報を送信する。また、このリクエスト情報に含まれる緊急度情報が示す緊急度は「低」である。

ステップＳ１８において、リクエスト情報を受信したＢ社サーバ１１１は、リクエストに対する応答可否を判定する。Ｂ社サーバ１１１は、このリクエスト情報を受信する前に必要緊急度情報が示す必要緊急度を「低」に設定している（ステップＳ１０）。そこで、Ｂ社サーバ１１１は、受信したリクエスト情報に含まれる緊急度情報が示す緊急度と、事前設定している必要緊急度情報が示す必要緊急度とを比較して、リクエスト情報への応答可否を判定する。ここでは、リクエスト情報に含まれる緊急度情報が示す緊急度が「低」であり、必要緊急度情報が示す必要緊急度が「低」であり、緊急度情報が示す緊急度が必要緊急度情報が示す必要緊急度以上であるため、Ｂ社サーバ１１１は、このリクエスト情報が示すリクエストを即座に実行すると判定する。そのため、Ｂ社サーバ１１１は、リクエストの応答することを示す応答可情報をＡ社サーバ１０１に送信する（ステップＳ１９）。リクエスト情報および必要緊急度情報は第１情報の一例である。

応答可情報を送信したＢ社サーバ１１１は、ユーザに目標運動量以上の運動をユーザに促す誘導動作を指示する指示情報をロボット１１０に送信する（ステップＳ２０）。この誘導動作は、上述したようにロボット１１０がユーザに「散歩に行こう」と呼び掛ける、かつ／またはリードを持ってきて散歩に行きたいとせがむ、というような動作である。この誘導動作は、ロボット１１０の容姿および運動能力に応じて様々な形態が採用される。

指示情報は有効期限を示す有効期限情報を含んでいてもよい。有効期限は例えば１０分間である。ロボット１１０が指示情報に基づき有効期限の間、ユーザを散歩に誘い続けてもユーザがそれに応じない場合、ロボット１１０は誘導動作を自動的に中止しても良い。さらに、このようにユーザの行動変容に失敗した場合、さらに一定時間が経過した後またはユーザがリラックスしている時に、ロボット１１０は、再び誘導動作をしても良い。また、この場合における誘導動作の有効期限は、失敗した前回の有効期限よりも短くても良い。有効期限を短く設定するようにしているのは、失敗した誘導動作を同様に繰り返すと、ユーザとロボットとの関係が悪化するリスクがあるためである。

Ｂ社サーバ１１１から指示情報を受信したロボット１１０は、指示情報に従ってユーザを運動（１日あたり５０００歩の散歩）に連れ出す誘導動作を行う（ステップＳ２１）。この例では、ロボット１１０は、犬型ロボットであるので、「ワン、ワン」と鳴きながら尻尾を振る誘導動作を行う。この誘導動作によりユーザに散歩を連想させることができる。その他、ロボット１１０は、ユーザが理解可能な言語で「散歩に行こう」または「散歩に行きたい」などと話しかける誘導動作、かつ／または、散歩に使うリードを持ってきて散歩に行きたいという意志を示す誘導動作を有効期限の間繰り返してもよい。

Ａ社サーバ１０１がロボット１１０のセンサー１１０ｃまたは運動能力に対するアクセス権を持ち、運動能力への直接的なアクセスを求めている場合、Ａ社サーバ１０１は、ロボット１１０の周辺状況を分析し、分析結果に基づいてロボット１１０の表情、発声、姿勢、および移動を制御するコマンドをＢ社サーバ１１１を介して、または直接、ロボット１１０に送信してもよい。これにより、Ａ社サーバ１０１は、ロボット１１０を直接的に制御することができる。

ユーザは、これらロボット１１０からの誘導動作を受けて散歩をする決心をして、ロボットと一緒に運動（散歩）をする（ステップＳ２２）。ロボット１１０は、５０００歩の散歩を指示するＢ社サーバ１１１からの指示情報に従い、散歩の歩数が５０００歩となるように、散歩するコースをユーザに提案する、かつ／または、自ら散歩を先導しても良い。

小さいまたは歩行する機能がないというようにロボット１１０がユーザと一緒に歩く能力を有していない場合には、ロボット１１０は散歩の歩数が５０００歩となるように、散歩するコースをユーザに提示しても良い。この場合、目標運動量を達成するようにロボット１１０は、ユーザに働きかける誘導動作を行っても良い。例えば、ロボット１１０は、「近くに出来たスーパーマーケットに寄ってみよう」、または「今夜は丘の上に登ると流れ星が見られるかも知れない」などの発話をしてもよい。これにより、散歩の歩数（運動量）が調整される。

このようにして、無事に運動（散歩）を行ったユーザが帰宅したことをカメラ画像や位置センサーなどによって検知すると、ロボット１１０はユーザとの運動（散歩）が終わったことを示す終了通知と、その運動の実施運動量を示す実施運動量情報とをＢ社サーバ１１１に送信する（ステップＳ２３）。実施運動量情報は、例えば、歩数、散歩コース、および散歩のペースなどを示す情報を含む。

Ｂ社サーバ１１１は、Ａ社サーバ１０１に対して、リクエストの終了通知と、実施運動量情報とを送信する（ステップＳ２４）。終了通知と実施運動量情報とを受信したＡ社サーバ１０１は、リクエストした運動が実施されたことを示す情報と、実施運動量情報とを実施履歴としてメモリ１０１ｃに記録する（ステップＳ２５）。

Ａ社サーバ１０１は、実施運動量情報の示す実施運動量が目標運動量情報が示す目標運動量以上であると判定した場合、ユーザが目標運動量を達成したことを示す評価メッセージを、スマートフォン１００に送信する（ステップＳ２６）。評価メッセージを受信したスマートフォン１００は、Ａ社アプリを通じて目標運動量が達成されたことを示す評価メッセージを表示する（ステップＳ２７）。これにより、ユーザは一定の達成感を得ることができ、運動（散歩）への抵抗感が減る。なお、Ａ社サーバ１０１は実施運動量が目標運動量未満の場合、そのことを示す評価メッセージをスマートフォン１００に送信してもよい。

ここでは、運動に誘導するリクエストが即座に実施される場合を説明したが、ユーザが仕事の会議中などで直ちにロボット１１０からの働きかけに応じることができないケースもある。

図８は、非ロボット会社がロボット１１０に対してタスクをリクエストする処理の一例を示すフローチャートである。特に、図８は、リクエストが即座に実施されないケースを示す。図７との違いは、Ｂ社サーバ１１１がリクエスト情報を受信した時の必要緊急度情報にある。図７では必要緊急度情報が示す必要緊急度が「低」であり、どのようなリクエストもロボット１１０により即座に実施される状況であった。一方、図８では必要緊急度情報が示す必要緊急度が「中」であり、リクエスト情報に含まれる緊急度情報が示す緊急度が「中」または「高」でない限り、リクエストは即座に実施されない。この場合、リクエストは、適切なタイミングまで保留される、または却下される。図８は、適切なタイミングまでリクエストが保留されるケースを例示する。

Ａ社がＡ社アプリおよびＡ社サーバ１０１を用いてユーザの生体活動情報を継続的に検出して、運動（散歩で５０００歩相当）を行うよう緊急度が「低」のリクエスト情報をＢ社サーバ１１１に送信するまでの処理は、図７と同じであるため説明を省略する。異なる点は、このリクエスト情報が送信される処理（ステップＳ１７）の前にある。

ステップＳ８０１において、ロボット１１０は、ロボット１１０とのコミュニケーションをとらない意図を含むユーザからの発言またはユーザの状況を判断する。ステップＳ８０２において、ロボット１１０は、前記発現又は前記状況の判断結果、に基づいて、必要緊急度を「中」（所定のレベルの一例）に更新する。

例えば、ユーザがロボット１１０に対して「静かにしておいて」または「話しかけないで」といったロボット１１０とのコミュニケーションを取らない意図の発言をした場合、ロボット１１０は必要緊急度を「低」から「中」に変更すればよい。或いは、ロボット１１０は、センサー１１０ｃのセンシングデータからユーザが会話中または車の運転中であることを認識した場合、必要緊急度を「低」から「中」に変更すればよい。必要緊急度を「中」に変更したロボット１１０は、必要緊急度を「中」に更新する更新依頼をＢ社サーバ１１１に送信する。この更新依頼を受信したＢ社サーバ１１１は、必要緊急度を「低」から「中」に更新する（ステップＳ８０２）。

Ａ社サーバ１０１からリクエスト情報を受信したＢ社サーバ１１１は、リクエスト情報に含まれる緊急度と必要緊急度とに基づき、応答可否を判定する（ステップＳ１８）。ここでは、緊急度「低」が必要緊急度「中」よりも低いため、Ｂ社サーバ１１１は、リクエストを即座に実行できないと判定する。即座に実行できないと判定したＢ社サーバ１１１は、Ａ社サーバ１０１に対して、リクエストが保留されたことを示す保留情報を送信する（ステップＳ８０３）。

以後、ロボット１１０は、必要緊急度を変更の要否を判定する処理を、ユーザの発言およびセンサー１１０ｃからのセンシングデータに基づいて継続的に行う（ステップＳ８０４）。ユーザが明示的に必要緊急度を下げる発言をした場合、ユーザが緊急性のない話題を含む発言をした場合、またはユーザが緊急性の低い行動をとっていると判定した場合、ロボット１１０は必要緊急度を「低」に設定すればよい。緊急性の低い行動は、例えば、テレビを見る、スマートフォンを操作するなどの行動である。

必要緊急度を「中」から「低」へ更新した場合、ロボット１１０は、Ｂ社サーバ１１１に対して、必要緊急度を「低」へ更新するようための更新依頼を送信する（ステップＳ８０５）。

更新依頼を受信したＢ社サーバ１１１は、必要緊急度を「中」から「低」へ更新する。次に、Ｂ社サーバ１１１は、保留中のリクエストの応答可否を再判定する（ステップＳ８０６）。ここで、ステップＳ８０３でＡ社サーバ１０１から送信されたリクエスト情報に含まれる緊急度情報が示す緊急度が「低」であり、現在の必要緊急度情報が示す必要緊急度が「低」であり、緊急度が必要緊急度以上であるため、Ｂ社サーバ１１１はＡ社サーバ１０１に対して、応答可情報を送信する（ステップＳ８０７）。

ここから先の処理は、図７と同じであるため説明を省略する。

図７、図８にて説明したように、Ｂ社サーバ１１１の仕組みを纏めると下記のようになる。Ｂ社サーバ１１１は、Ａ社（Ａ社アプリ）が保有しないセンサー１１０ｃまたはロボット１１０の運動能力が必要なリクエストを、ユーザの身近にあるＢ社のロボット１１０に実行させる。Ｂ社サーバ１１１は、ユーザ毎にＡ社とＢ社との連携設定を行う。Ｂ社サーバ１１１は、ユーザの事前入力に基づいて、Ｂ社のロボット１１０が有する各能力をどのレベルまでＡ社に利用させるかを規定するアクセス権の設定情報を事前登録する。Ｂ社サーバ１１１は、ユーザがロボット１１０に構うことができない状況にある場合、緊急度の低いリクエストを保留または却下する。Ｂ社サーバ１１１は、保留したリクエストを、ユーザからの要請またはユーザの状況変化に応じて適切なタイミングに再度実行する。

図９は、Ｂ社サーバ１１１の処理の一例を示すフローチャートである。図９の処理において、Ｂ社サーバ１１１は、非ロボット会社（Ａ社）がリクエストしたタスクを実施するために必要なアクセス権を有しているか、ユーザに対してリクエストされたタスクを即座に実行するべき緊急性があるか、および実行が保留されたリクエストが保留期間を超過していないかを判定し、判定結果に基づいて非ロボット会社（Ａ社）のリクエストに応答する。具体的には以下の通りである。

ステップＳ１０１において、Ｂ社サーバ１１１は、Ａ社サーバ１０１からユーザに運動を働きかけるタスクをロボット１１０にリクエストするリクエスト情報を受信する。

ステップＳ１０２において、Ｂ社サーバ１１１は、リクエストされたタスクに対するＡ社のアクセス権を確認する。まず、Ｂ社サーバ１１１は、リクエスト情報に含まれるＡ社アプリの固有ＩＤが、Ｂ社アプリの固有ＩＤと対応付けられたペア情報がメモリ１１１ｃに事前登録されているか否かを判定する。そして、Ｂ社サーバ１１１は、事前登録されていると判定した場合、Ｂ社サーバ１１１は、リクエスト情報がリクエストするタスクのアクセス権をＡ社が保有しているか否かを図５に示すアクセス権の設定情報に基づいて確認する。ここでは、図５の示す「運動の勧誘」タスクについてのＡ社のアクセス権の許可レベルが「１」または「２」に設定されているため、リクエストされたタスクについてＡ社はアクセス権を有すると判定される。なお、「運動の勧誘」タスクについてのＡ社のアクセス権の許可レベルが「０」の場合、リクエストされたタスクについてＡ社はアクセス権を有していないと判定される。

Ａ社がアクセス権を有していないと判定された場合（ステップＳ１０３でＮＯ）、Ｂ社サーバ１１１は、リクエストされたタスクを実行するためのアクセス権がないことを示すメッセージをＡ社サーバ１０１に送信し（ステップＳ１０４）、処理を終了する。

一方、Ａ社がアクセス権を有していると判定された場合（ステップＳ１０３でＹＥＳ）、Ｂ社サーバ１１１は、ステップＳ１０１で受信したリクエスト情報に含まれる緊急度情報が示す緊急度と、現在設定されている該当するユーザの必要緊急度とを比較して、当該リクエスト情報が示すリクエストを即座に実行するか否かを判定する（ステップＳ１０５）。

緊急度が必要緊急度未満の場合（ステップＳ１０５でＮＯ）、Ｂ社サーバ１１１は、リクエスト情報を受信してからの経過時間が保留期間内であるか否かを判定する（ステップＳ１０９）。

保留期間は、タスクの実行が保留されたリクエストをいつまで保留するかを示す時間情報である。Ｂ社サーバ１１１は、リクエスト情報を受信してからの経過時間が保留期間を超えると（ステップＳ１０９でＮＯ）、そのリクエスト情報が示すリクエストを却下する（ステップＳ１１１）。リクエストを却下したＢ社サーバ１１１は、リクエストを行ったＡ社サーバ１０１に対して保留期間を超えたためリクエストが却下された旨のメッセージを送信し、処理を終了する。

これにより、必要緊急度が「低」に更新された瞬間に、大量に蓄積された緊急度が「低」のリクエストが一斉に実行されることが防止される。さらに、受信されてからから長時間経過したような、現時点では実施する意味のないリクエストの実行が防止される。このようなリクエストの却下は、ロボット１１０によるユーザへの働きかけの効果を維持するためにも必要である。

一方、リクエスト情報を受信してからの経過時間が保留期間内の場合（ステップＳ１０９でＹＥＳ）、Ｂ社サーバ１１１は、ロボット１１０を介してユーザの状態データを取得し、取得した状態データに基づいて現在の必要緊急度をロボット１１０を介して再評価する（ステップＳ１１０）。もしくは、ロボット１１０がユーザの状態データを取得し、取得した状態データに基づいて現在の必要緊急度を自ら設定し、Ｂ社サーバ１１１に通知するようにしてもよい。ステップＳ１１０の処理が終了すると、処理はステップＳ１０５に戻る。これにより、ステップＳ１０５、Ｓ１０９、Ｓ１１０に示すループ処理が実行される。このループ処理により、ユーザに働きかけを行うのに必要となる必要緊急度以上の緊急度を持つリクエストのみが随時、実行され、そうでないリクエストは保留期間の間、実行が保留され続ける。状態データは、ロボット１１０において検知したユーザの状態に関わり動的に変化するデータである。具体的には、後述の図９に示すようにロボット１１０のセンサー１１０ｃによるセンシングデータに基づいて設定される必要緊急度情報を含む。

Ａ社サーバ１０１からのリクエストに含まれる緊急度情報が示す緊急度がＢ社サーバ１１１またはロボット１１０にて管理されている必要緊急度以上である場合（ステップＳ１０５でＹＥＳ）、処理はステップＳ１０６に進む。

ステップＳ１０６において、Ｂ社サーバ１１１は、ユーザが運動を働きかけてよい状態になったので、ロボット１１０に対して、Ａ社サーバ１０１からリクエストされたタスクの実行を指示する指示情報を送信する。指示情報を受信したロボット１１０は指示情報にしたがってタスクを実行する。これにより、ロボット１１０は、ユーザを散歩に連れ出す誘導動作を行う。この誘導動作によって散歩を決心したユーザはロボット１１０と一緒に散歩する。散歩からの帰宅したロボット１１０は、タスクの実行結果を散歩の終了を告げる終了通知と、散歩における実施運動量情報とをＢ社サーバ１１１に送信する。これにより、Ｂ社サーバ１１１は、終了通知と実施運動量情報とを受信する（ステップＳ１０７）。

ステップＳ１０８において、Ｂ社サーバ１１１は、受信した終了通知と実施運動量情報とをＡ社サーバ１０１に送信する。

なお、Ａ社サーバ１０１が、ロボット１１０に対する、センサー１１０ｃ、運動能力である表情変更能力、発声能力、姿勢変更能力、かつ／または移動能力のアクセス権を有している場合、Ａ社サーバが、Ｂ社サーバ１１１を介して、ロボット１１０の周辺状況に応じて、直接的にロボット１１０の顔表情、音声発話、姿勢、かつ／または移動を制御してもよい。この場合も、Ｂ社サーバ１１１からタスクの実行が指示されたロボット１１０は、タスクの実行結果をＢ社サーバ１１１に送信すればよい。つまり、Ａ社サーバ１０１はロボット１１０を遠隔制御しているとはいえ、ロボット１１０を直接的に制御しているのは、Ｂ社サーバ１１１であり、ロボット１１０とＢ社サーバ１１１との関係は、上述した態様と同じである。

Ａ社サーバ１０１によるロボット１１０の遠隔制御は、「５Ｇ」や「Ｂｅｙｏｎｄ ５Ｇ」などと呼ばれる高速かつ低遅延の無線通信インフラが整うことで、今後の実現が期待される。タスクの実行結果を受け取ったＢ社サーバ１１１は、その実行結果を、タスクのリクエスト元であるＡ社サーバ１０１に送信して処理を終える。

図１０は、必要緊急度の設定例を示す表である。この図は、朝８時から夜８時までのユーザの状態の遷移を示している。以下の説明では、必要緊急度は、ロボット１１０が設定するものとして説明するが、これは一例であり、Ｂ社サーバ１１１が設定してもよい。この場合、Ｂ社サーバ１１１は、ロボット１１０を介して取得したセンシングデータに基づいて必要緊急度を設定すればよい。

ロボット１１０は、ユーザの状態を継続的にしてセンシングして、センシング結果からユーザの状態を随時検出し、検出結果に基づき必要緊急度を適宜更新する。

８：００－１０：００の時間帯において、ユーザは他人と対面で会話している。ロボット１１０はカメラおよびマイクなどのセンサー１１０ｃを用いて、ユーザが他人と会話していると判定する。人の行動および状態を静止画、動画、または音声から判定または説明するニューラルネットワークが開発されている。そのため、ロボット１１０は、このようなニューラルネットワークによる画像認識技術または音声認識技術を用いてユーザの状態を検出すればよい。ロボット１１０は、ユーザの状態が会話中であると判定した後、必要緊急度を「中」に設定する。これにより、「中」以上の緊急度を持つリクエストでなければ、リクエストは実行されなくなる。そして、ロボット１１０は設定された必要緊急度をＢ社サーバ１１１と共有する。

さらに、この判定においては、ロボット１１０はカメラから取得したユーザの表情およびジェスチャー、かつ／またはマイクから取得した音声情報に含まれる会話内容および音声トーンなどからユーザの感情分析を行っても良い。ここで、感情分析の結果は、例えば「ポジティブ」、「ニュートラル」、および「ネガティブ」のように分類される。感情分析の結果が「ポジティブ」または「ニュートラル」である会話の場合、タスクを実行するためのロボット１１０の会話への割り込みは、ユーザにより許容される可能性が高い。この場合、ロボット１１０は上記で設定した必要緊急度を下げてもよい。また、感情分析の結果が「ネガティブ」である会話の場合、会話への割り込みがユーザにより許容されない可能性が高いので、ロボット１１０は上記で設定した必要緊急度を維持または上げても良い。必要緊急度が変更した場合には、ロボット１１０は変更した必要緊急度をＢ社サーバ１１１と共有する。

このようにユーザの状態判定に、ユーザの感情分析を加味することで、ユーザにとってより適切なタイミングで、ロボット１１０はタスクを処理することができる。

ここでは、感情分析の結果は３つに分類されていたが、本開示はこれに限定されない。感情分析の結果は、「喜怒哀楽」のようにより多く分類されてもよいし、「ポジティブ」および「ネガティブ」の２種類のようにより少なく分類されてもよい。また、ロボット１１０は、ユーザのストレス度合いを推定し、推定したストレス度合いの数値範囲に応じて必要緊急度を調整してもよい。

１０：００－１２：００の時間帯において、ユーザはコンピュータに向かって作業（仕事）をしている。ロボット１１０はカメラ、マイクなどセンサー１１０ｃを用いて、ユーザがコンピュータを操作していることを検出する。ロボット１１０はユーザがコンピュータで作業中であると判定した後、必要緊急度を「中」に維持する。この場合、「中」以上の緊急度を持つリクエストでなければ、リクエストは実行されない。そして、ロボット１１０は設定された必要緊急度をＢ社サーバ１１１と共有する。

１２：００－１３：００の時間帯において、ユーザは椅子に座って食事をしている。ロボット１１０はカメラ、マイクなどのセンサー１１０ｃを用いて、ユーザが食事中であることを検出する。ロボット１１０はユーザが食事中であると判定した後、必要緊急度を一番低い「低」に設定する。そして、ロボット１１０は設定された必要緊急度をＢ社サーバ１１１と共有する。

１３：００－１５：００の時間帯において、ユーザは電話もしくは会議をしている。ロボット１１０はカメラ、マイクなどのセンサー１１０ｃを用いて、ユーザが携帯電話を介して会話している（電話中）、またはコンピュータを介して会話している（会議中）ことを検出する。ロボット１１０はユーザが電話中または会議中であると判定した後、必要緊急度を「中」に設定する。この場合、「中」以上の緊急度を持つリクエストでなければ、リクエストは実行されない。そして、ロボット１１０は設定された必要緊急度をＢ社サーバ１１１と共有する。

１５：００－１６：００の時間帯において、ユーザは運動をしている。ロボット１１０はカメラ、マイクなどのセンサー１１０ｃを用いて、ユーザが運動していることを検出する。ロボット１１０はユーザが運動中であると判定した後、必要緊急度を「中」に維持する。

さらに、この判定においては、ロボットはカメラから取得した画像に基づいてユーザの皮膚の色彩の周期的変化を計測してもよいし、スマートウォッチなどを用いてユーザの心拍数を計測してもよい。ここで計測された心拍数が所定値よりも低い場合、タスクを実行するためのロボット１１０による運動への割り込みがユーザに許容される可能性が高い。この場合、ロボット１１０は必要緊急度を下げてもよい。一方、心拍数が所定値より高い場合、タスクを実行するためのロボット１１０による運動への割り込みがユーザに許容されない可能性が高い。そのため、ロボット１１０は必要緊急度を維持してもよいし、必要緊急度を上げてもよい。必要緊急度が変更された場合、ロボット１１０は変更された必要緊急度をＢ社サーバ１１１と共有する。

このようにユーザの状態が運動中であると判定された場合に、ユーザの心拍数を加味することで、ユーザにとってより適切なタイミングで、ロボット１１０はタスクを処理することができる。

１６：００－２０：００の時間帯において、ユーザは寝転がってリラックスしている。ロボット１１０はカメラ、マイクなどのセンサー１１０ｃを用いて、ユーザがリラックス状態であることを検出する。ロボット１１０はユーザがリラックス状態であると判定した後、必要緊急度を一番低い「低」に設定する。そして、ロボット１１０は設定された必要緊急度をＢ社サーバ１１１と共有する。

このように、ユーザの状態は時々刻々と変化する。ロボット１１０はセンサー１１０ｃを活用してユーザの状態をセンシングし、ユーザの状態を随時判定する。さらにその判定結果をもとに必要緊急度を更新する。ロボット１１０は、必要緊急度を更新した場合、更新した必要緊急度をＢ社サーバ１１１に通知し、最新の必要緊急度をＢ社サーバ１１１と共有する。このように、必要緊急度は、ユーザの状態に応じて随時変化するのである。

このように本実施の形態によれば、Ａ社サーバ１０１は、ユーザに対して運動することを働きかける必要があると判断したときに、Ｂ社サーバ１１１が管理するロボット１１０を通じて、ユーザに運動することを働きかけることができる。その結果、Ａ社サーバ１０１は、自身がロボット１１０を管理していないにも関わらず、ロボット１１０に対してユーザが運動することを働きかける動作を行わせることができる。そのため、ユーザのスマートフォン１００の映像音声出力部１００ｆに運動することを促すメッセージが表示されるに過ぎない場合に比して、運動することについてのより強い動機付けをユーザに対して与えることができる。

なお、本実施の形態は以下の変形例が採用できる。

（１）図８のステップＳ８０１において、ロボット１１０は、ユーザに対して「今、話かけてもいい？」または「ちょっといい？」などとユーザの現在の必要緊急度を確かめる質問を話しかけ、ユーザに答えさせるようにしても良い。ロボット１１０は、所定のタイミングまたは未だ実施されていないリクエストの件数および／またはそれらの緊急度が所定の条件を満たした場合などに、ユーザに対して直接的に上記のような質問をする。この質問により、ロボット１１０は、ユーザの回答内容から必要緊急度を設定するための情報を取得するようにしても良い。この方法の場合、ロボット１１０は、ユーザに直接、必要緊急度を確認することができるため、ユーザの認識通りの必要緊急度情報をロボット１１０が設定および更新することができる。

ここで、ユーザが上記質問に対して「いいよ」などの肯定的な返事をした場合は、ロボット１１０は、必要緊急度を「低」など低いレベルに設定するようにしても良い。また、「後にして欲しい」または返事が得られない場合には、今はユーザへの働きかけを行うのに良いタイミングではないとして、ロボット１１０は、必要緊急度を「中」または「高」などの高いレベルに設定しても良い。

（２）スマートフォン１００は情報端末の一例であり、本開示において、情報端末はスマートフォン１００に限定されない。情報端末は、タブレット型コンピュータであってもよく、携帯可能な情報端末が採用できる。

本開示によれば、他社機器が保有するセンサーや運動能力を要求または直接的に制御することが安全に実現できる。これにより、これまでのサイバー空間だけの情報流通から、サイバー空間とフィジカル空間とを融合して、誰しもがソフトウェアを通じて、サイバー空間からフィジカル空間において何らかの実空間への作用を行うことが可能となり、多種多様な産業的利用の基盤技術として期待ができる。

１００ ：スマートフォン（情報通信端末）
１０１ ：Ａ社サーバ（非ロボット会社）
１１０ ：ロボット（可動装置）
１１１ ：Ｂ社サーバ（ロボット会社）

Claims (27)

1. ロボットと通信する第１サーバにおけるロボット制御方法であって、
   第２サーバから前記ロボットの動作を求めるリクエストを示すリクエスト情報を取得し、前記第２サーバにおいて、ユーザの情報端末から取得した前記ユーザの生体活動を示す生体活動情報に基づき前記ユーザに対して運動することを働きかける必要があるか否かが判定され、前記リクエスト情報は、前記第２サーバにおいて前記ユーザに対して運動することを働きかける必要があると判定された後に送信されるものであり、前記リクエスト情報は前記ユーザが運動する緊急性の程度を示す緊急度情報を含み、
   前記第１サーバにおいて、前記第２サーバが前記リクエスト情報を要求するアクセス権を持つことが確認された場合、前記緊急度情報と前記第１サーバで管理されている必要緊急度情報とに基づいて、前記リクエストを実行、保留、又は却下することを決定し、前記必要緊急度情報は、前記ロボットが前記リクエストを実行するために必要となる緊急性の程度を示すものであり、
   前記リクエストを実行することが決定された後に、前記ユーザが運動することを働きかける動作を行わせるための指示情報を前記ロボットに対して送信する、
   ロボット制御方法。
2. 前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度以上である場合に、前記リクエストを実行することを決定する、
   請求項１に記載のロボット制御方法。
3. 前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度未満である場合に、前記リクエストを保留又は却下することを決定する、
   請求項１に記載のロボット制御方法。
4. 前記リクエスト情報は、さらに、前記リクエスト情報に基づく決定を保留できる保留期間を示す保留期間情報を含み、
   前記保留期間において、前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度以上とならなかった場合に、前記リクエストを却下することを決定する、
   請求項１に記載のロボット制御方法。
5. 前記リクエスト情報は、さらに、前記リクエスト情報に基づく決定を保留できる保留期間を示す保留期間情報を含み、
   前記保留期間において、前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度以上となった場合に、前記リクエストを実行することを決定する、
   請求項１に記載のロボット制御方法。
6. 前記必要緊急度情報が示す緊急性の程度は、前記ロボットに設けられたセンサーのセンシング結果に基づき得られる前記ユーザから前記ロボットに向けられた発言を示す情報に基づき、決定されるものであり、
   前記発言に、前記ロボットとのコミュニケーションを取らない意図の発言が含まれる場合には、前記必要緊急度情報が示す緊急性の程度を所定のレベルまで引き上げる、
   請求項１に記載のロボット制御方法。
7. 前記必要緊急度情報が示す緊急性の程度は、前記ロボットが取得した質問に対する前記ユーザからの回答を示す情報に基づき、決定され、
   前記質問は、前記ロボットのスピーカーから出力されたものであり、前記必要緊急度情報が示す緊急性の程度を前記ユーザに確認するためものである、
   請求項１に記載のロボット制御方法。
8. 前記必要緊急度情報が示す緊急性の程度は、前記ロボットに設けられたセンサーから取得された前記ユーザの画像を解析することにより得られる前記ユーザの行動に基づき、決定されるものであり、
   前記ユーザの行動が、電話中又はパソコン操作中である場合には、前記必要緊急度情報が示す緊急性の程度を所定のレベルまで引き上げる、
   請求項１に記載のロボット制御方法。
9. 前記指示情報は、さらに、前記指示情報の有効期限を示す有効期限情報を含む、
   請求項１記載のロボット制御方法。
10. 前記決定されたタイミングからの経過時間が前記有効期限を超えた場合は、前記ロボットにおいて前記ユーザを運動に誘導することなく前記指示情報はキャンセルされる、
    請求項９に記載のロボット制御方法。
11. 前記ロボットから、前記指示情報に示される前記ユーザが運動することを働きかける動作が行われたことを示す情報を取得した後に、前記ユーザが運動した運動量である実施運動量情報を前記第２サーバに対して送信する、
    請求項１に記載のロボット制御方法。
12. 前記第１サーバは前記ロボットを管理する第１事業者により管理され、
    前記第２サーバは前記ユーザの情報端末から取得した前記生体活動情報を管理する第２事業者により管理され、
    前記第２事業者は前記第１事業者とは異なる、
    請求項１に記載のロボット制御方法。
13. ロボットに対応する第１サーバと通信するとともに、ユーザの情報端末と通信する第２サーバにおける情報提供方法であって、
    前記ユーザの情報端末から前記ユーザの生体活動を示す生体活動情報を取得し、
    前記生体活動情報に基づき、前記ユーザに対して運動することを働きかける必要があるか否かを判定し、
    前記ユーザに対して運動することを働きかける必要があると判定された後に、前記ロボットの動作を求めるリクエストを示すリクエスト情報を前記第１サーバに送信し、前記リクエスト情報は前記ユーザが運動する緊急性の程度を示す緊急度情報を含み、前記第１サーバにおいて、前記第２サーバが前記リクエスト情報を要求するアクセス権を持つことが確認された場合、前記緊急度情報と前記第１サーバで管理されている必要緊急度情報とに基づいて、前記リクエストを実行、保留、又は却下することが決定され、前記リクエストを実行することが決定された後に、前記ユーザが運動することを働きかける動作を行わせるための指示情報を前記ロボットに対して送信され、前記必要緊急度情報は、前記ロボットが前記リクエストを実行するために必要となる緊急性の程度を示すものである、
    情報提供方法。
14. 前記リクエスト情報は、前記生体活動情報に基づき算出された前記ユーザが必要とする運動量を示す運動量情報を含み、
    前記リクエスト情報に基づいて前記ロボットが前記ユーザを運動に誘導したことにより前記ユーザが運動を行った後に、前記ユーザが運動した運動量である実施運動量情報を取得し、
    前記運動量情報及び前記実施運動量情報に基づき、前記ユーザの運動を評価する評価メッセージを作成し、
    前記評価メッセージを前記ユーザの情報端末に送信する、
    請求項１３記載の情報提供方法。
15. 前記運動量情報及び前記実施運動量情報に基づき、前記ユーザが運動した運動量が、前記ユーザが目標とする運動量以上であると判断された場合に、前記評価メッセージとして、前記ユーザが目標とする運動量を達成した旨のメッセージが作成される、
    請求項１４に記載の情報提供方法。
16. ロボットと通信する第１サーバにおけるロボット制御方法であって、
    第２サーバから前記ロボットの動作を求めるリクエストを示すリクエスト情報を取得し、前記第２サーバにおいてユーザの情報端末から取得した前記ユーザの生体活動を示す生体活動情報に基づき前記ユーザに対して運動することを働きかける必要があるか否かが判定され、前記リクエスト情報は前記第２サーバにおいて前記ユーザに対して運動することを働きかける必要があると判定された後に送信されるものであり、
    前記ロボットから、前記ロボットにおいて検知した前記ユーザの状態に関わり動的に変化する状態データを取得し、
    前記リクエスト情報及び前記状態データの動的な変化に基づき、前記ユーザに対して運動することを働きかけてよい状態に前記ユーザの状態がなったと判断した後に、前記リクエスト情報に応じて前記ユーザに対して運動することを働きかける動作を行わせるための指示情報を前記ロボットに対して送信する、
    ロボット制御方法。
17. 前記リクエスト情報は、さらに、前記リクエスト情報に応じた前記指示情報の決定を保留できる保留期間を示す保留期間情報を含み、
    前記保留期間において、前記ユーザが運動することを働きかけてよい状態に前記ユーザの状態がなった場合に、前記指示情報の送信を決定する、
    請求項１６に記載のロボット制御方法。
18. 前記保留期間において、前記ユーザが運動することを働きかけてよい状態に前記ユーザの状態がならなかった場合に、前記指示情報を送信しないことを決定する、
    請求項１７に記載のロボット制御方法。
19. 前記リクエスト情報は、前記ユーザが運動する緊急性の程度を示す緊急度情報を含み、
    前記状態データは、前記ロボットから取得した前記状態データの動的な変化に応じて変化する必要緊急度情報を含み、前記必要緊急度情報は前記ロボットが前記リクエストを実行するために必要となる緊急性の程度を示すものである、
    請求項１６記載のロボット制御方法。
20. 前記緊急度情報及び前記必要緊急度情報に基づき、前記ユーザが運動することを働きかけてよい状態に前記ユーザの状態がなったか否かを判断する、
    請求項１９に記載のロボット制御方法。
21. 前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度以上である場合に、前記指示情報の送信を決定する、
    請求項１９に記載のロボット制御方法。
22. 前記緊急度情報が示す緊急性の程度が、前記必要緊急度情報が示す緊急性の程度未満である場合に、前記指示情報の送信の保留を決定する、
    請求項２１に記載のロボット制御方法。
23. 前記第２サーバが前記リクエスト情報を要求するアクセス権を持つことが確認された場合、前記指示情報を前記ロボットに対して送信する、
    請求項１６記載のロボット制御方法。
24. 前記第１サーバにおいて前記第２サーバが前記アクセス権を有するか否かを登録しておき、
    前記登録に基づき、前記第２サーバが前記アクセス権を持つことを確認する、
    請求項２３記載のロボット制御方法。
25. ロボットに対応する第１サーバと通信するとともに、ユーザの情報端末と通信する第２サーバにおける情報提供方法であって、
    前記ユーザの情報端末から前記ユーザの生体活動を示す生体活動情報を取得し、
    前記生体活動情報に基づき、前記ユーザに対して運動することを働きかける必要があるか否かを判定し、
    前記ユーザに対して運動することを働きかける必要があると判定された後に、前記ロボットの動作を求めるリクエストを示すリクエスト情報を前記第１サーバに送信し、前記第１サーバにおいて、前記ロボットから前記ロボットにおいて検知した前記ユーザの状態に関わり動的に変化する状態データが取得され、前記リクエスト情報及び前記状態データの動的な変化に基づき、前記ユーザに対して運動することを働きかけてよい状態に前記ユーザの状態がなったと判断された後に、前記リクエスト情報に応じて前記ユーザに対して運動することを働きかける動作を行わせるための指示情報が前記ロボットに対して送信される、
    情報提供方法。
26. 前記リクエスト情報は、前記生体活動情報に基づき算出された前記ユーザが必要とする運動量を示す運動量情報を含み、
    前記リクエスト情報に基づいて前記ロボットが前記ユーザを運動に誘導したことにより前記ユーザが運動を行った後に、前記ユーザが運動した運動量である実施運動量情報を取得し、
    前記運動量情報及び前記実施運動量情報に基づき、前記ユーザの運動を評価する評価メッセージを作成し、
    前記評価メッセージを前記ユーザの情報端末に送信する、
    請求項２５記載の情報提供方法。
27. 前記運動量情報及び前記実施運動量情報に基づき、前記ユーザが運動した運動量が、前記ユーザが目標とする運動量以上であると判断された場合に、前記評価メッセージとして、前記ユーザが目標とする運動量を達成した旨のメッセージが作成される、
    請求項２６に記載の情報提供方法。

Images