WO2023210035A1

WO2023210035A1 - 情報処理システム、情報処理装置及び情報処理方法

Info

Publication number: WO2023210035A1
Application number: PCT/JP2022/030137
Authority: WO
Inventors: 隆史石川; 侑規中村
Original assignee: パラマウントベッド株式会社
Priority date: 2022-04-25
Filing date: 2022-08-05
Publication date: 2023-11-02
Also published as: JP2023161203A

Abstract

情報処理システムは、熟練者の暗黙知に対応する処理を実行するアプリケーションを含むデバイスと、デバイスとの通信のデータリンク層において、ＭＡＣ（Media Access Control）ヘッダ、フレームボディ、及びトレイラを含むデータフレームを送信するサーバシステムと、を含み、サーバシステムは、能力情報を格納する第１領域、シーン情報を格納する第２領域、及び、デバイス種類情報を格納する第３領域を含む固定長の領域が、フレームボディに含まれる記データフレームを送信し、デバイスは、能力情報、シーン情報及びデバイス種類情報の少なくとも１つに基づいて、アプリケーションのアクティブまたは非アクティブを決定する。

Description

情報処理システム、情報処理装置及び情報処理方法

　本発明は、情報処理システム、情報処理装置及び情報処理方法等に関する。本願は、２０２２年４月２５日に日本で出願された特願２０２２－０７１４１０号に基づき優先権を主張し、その内容をここに援用する。

　従来、介助者が被介助者の介助を行う場面において利用されるシステムが知られている。特許文献１には、居住空間にセンサを配置し、当該センサにより取得された検知情報の時間変化に基づいて、居住空間に居住する居住者の状態に関する提供情報を生成する手法が開示されている。

特開２０２１－１８７６０号公報

　介助者による被介助者の介助を適切にサポートする情報処理システム、情報処理装置及び情報処理方法等を提供する。

　本開示の一態様は、熟練者の暗黙知に対応する処理を実行するアプリケーションを含むデバイスと、前記デバイスとの通信のデータリンク層において、ＭＡＣ（Media Access Control）ヘッダ、フレームボディ、及びトレイラを含むデータフレームを送信するサーバシステムと、を含み、前記サーバシステムは、被介助者の活動能力を表す能力情報を格納する第１領域、前記被介助者に対する介助のシーンを特定するシーン情報を格納する第２領域、及び、前記デバイスとともに用いられる併用デバイスの種類を特定するデバイス種類情報を格納する第３領域を含む固定長の領域が、前記フレームボディに含まれる前記データフレームを送信し、前記デバイスは、前記能力情報、前記シーン情報及び前記デバイス種類情報の少なくとも１つに基づいて、前記アプリケーションのアクティブまたは非アクティブを決定する情報処理システムに関係する。

　本開示の他の態様は、熟練者の暗黙知に対応する処理を実行するアプリケーションを含むデバイスとの通信のデータリンク層において、ＭＡＣ（Media Access Control）ヘッダ、フレームボディ、及びトレイラを含むデータフレームを送信する通信部と、前記通信部を制御する通信処理部と、を含み、前記通信部は、被介助者の活動能力を表す能力情報を格納する第１領域、前記被介助者に対する介助のシーンを特定するシーン情報を格納する第２領域、及び、前記デバイスとともに用いられる併用デバイスの種類を特定するデバイス種類情報を格納する第３領域を含む固定長の領域が、前記フレームボディに含まれる前記データフレームを、前記アプリケーションのアクティブまたは非アクティブを決定する情報として、前記デバイスに送信する情報処理装置に関係する。

　本開示のさらに他の態様は、熟練者の暗黙知に対応する処理を実行するアプリケーションを含むデバイスと、前記デバイスとの通信のデータリンク層において、ＭＡＣ（Media Access Control）ヘッダ、フレームボディ、及びトレイラを含むデータフレームを送信するサーバシステムとを含む情報処理システムにおける情報処理方法であって、被介助者の活動能力を表す能力情報を格納する第１領域、前記被介助者に対する介助のシーンを特定するシーン情報を格納する第２領域、及び、前記デバイスとともに用いられる併用デバイスの種類を特定するデバイス種類情報を格納する第３領域を含む固定長の領域が、前記フレームボディに含まれる前記データフレームを、前記サーバシステムから前記デバイスに送信し、前記能力情報、前記シーン情報及び前記デバイス種類情報の少なくとも１つに基づいて、前記アプリケーションのアクティブまたは非アクティブを決定する情報処理方法に関係する。

情報処理システムの構成例を示す図である。デバイスと暗黙知の関係例を示す図である。サーバシステムの構成例を示す図である。デバイスの構成例を示す図である。被介助者の能力と、想定されるリスクの関係例を示す図である。情報処理システムの処理を説明するシーケンス図である。情報処理システムの処理を説明するシーケンス図である。転倒リスクに関するデバイスの具体例を示す図である。転倒リスクに関するデバイスの具体例を示す図である。転落リスクに関するデバイスの具体例を示す図である。転落リスクに関するデバイスの具体例を示す図である。誤嚥リスクに関するデバイスの具体例を示す図である。褥瘡リスクに関するデバイスの具体例を示す図である。褥瘡リスクに関するデバイスの具体例を示す図である。ベッドポジション調整に用いられる画面例である。ベッドポジション調整に用いられる画面例である。看取りケアに用いられる画面例である。能力に応じたデバイスの動作モード例を示す図である。情報処理システムの処理を説明するシーケンス図である。デバイスにおける動作モードの決定処理を説明するフローチャートである。デバイスにおける動作モードの決定処理を説明するフローチャートである。嚥下ムセ検出装置と他のデバイスの連携例を説明する図である。デバイスにおける動作モードの決定処理を説明するフローチャートである。制御対象デバイスの具体例を示す図である。制御対象デバイスの具体例を示す図である。サーバレス通信を行う場合の情報処理システムの構成例を示す図である。通信処理部及び通信部の構成例を示す図である。ＭＡＣフレームの構成例を示す図である。フレームボディの構成例を示す図である。 data type IDとcontentsの関係例を示す図である。フレームボディの構成例を示す図である。 data type IDとcontentsの関係例を示す図である。アクセスカテゴリに応じたパラメータの例を示す図である。アクセスカテゴリの割り付け例を説明する図である。在宅介護における情報処理システムの構成例を示す図である。介助者の端末装置に表示される画面例である。介助者の端末装置に表示される画面例である。介助者の端末装置に表示される画面例である。ケアマネージャの端末装置に表示される画面例である。ケアマネージャの端末装置に表示される画面例である。ケアマネージャの端末装置に表示される画面例である。

　以下、本実施形態について図面を参照しつつ説明する。図面については、同一又は同等の要素には同一の符号を付し、重複する説明は省略する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本開示の必須構成要件であるとは限らない。

１．システム構成例
　図１は、本実施形態に係る情報処理システム１０の構成例である。本実施形態に係る情報処理システム１０は、例えば医療施設や介護施設において、介助者の“勘”や“暗黙知”によって行われる作業について、当該“勘”や“暗黙知”をデジタル化することによって、熟練度によらず適切な介助を行えるように、介助者に指示を与えるものである。

　なお、ここでの介助者は、介護施設の介護職員であってもよいし、病院等の医療施設における看護師や准看護師であってもよい。即ち、本実施形態における介助とは、被介助者をサポートする種々の行動を含むものであり、介護を含んでもよいし、注射等の医療に関する行為を含んでもよい。またここでの被介助者は、介助者による介助を受ける者であり、介護施設の入居者であってもよいし、病院に入院や通院を行う患者であってもよい。

　また本実施形態における介助は、家庭において行われてもよい。例えば、本実施形態における被介助者は、在宅介護を受ける要介護者であってもよいし、在宅医療を受ける患者であってもよい。また介助者は、要介護者や患者等の家族であってもよいし、訪問ヘルパー等であってもよい。

　図１に示す情報処理システム１０は、サーバシステム１００、デバイス２００、ゲートウェイ３００を含む。ただし、情報処理システム１０の構成は図１に限定されず、一部を省略する、他の構成を追加する等の種々の変形実施が可能である。例えば図１では、デバイス２００としてスマートフォン等のタブレット型の端末装置、車椅子６３０に配置される座面センサ４４０（図１０を用いて後述）、ベッド６１０に載置される検出装置４３０（図９を用いて後述）を例示しているが、デバイス２００の数や種類はこれに限定されない。例えば情報処理システム１０は、図８～図１４を用いて後述する種々のデバイス２００を含んでもよい。また情報処理システム１０は、図８～図１４に示すデバイス２００以外のデバイスを含むことも妨げられない。なお以下では、複数のデバイス２００を互いに区別する必要が無い場合、単にデバイス２００と表記する。また、構成の省略や追加等の変形実施が可能である点は、後述する図３や図４等においても同様である。

　本実施形態の情報処理装置は、例えばサーバシステム１００に対応する。ただし、本実施形態の手法はこれに限定されず、サーバシステム１００と他の装置を用いた分散処理によって、情報処理装置の処理が実行されてもよい。例えば、本実施形態の情報処理装置は、サーバシステム１００と、デバイス２００を含んでもよい。以下、情報処理装置がサーバシステム１００である例について説明する。

　サーバシステム１００は、例えばネットワークを介してデバイス２００と接続される。例えば、サーバシステム１００はインターネット等の公衆通信網を介してゲートウェイ３００と接続され、ゲートウェイ３００はＬＡＮ（Local Area Network）等を用いてデバイス２００と接続される。例えばゲートウェイ３００は、ＩＥＥＥ８０２．１１の規格に従った通信を行うアクセスポイント（ＡＰ）であり、デバイス２００はＩＥＥＥ８０２．１１の規格に従った通信を行うステーション（ＳＴＡ）であってもよい。ただし、各機器の間の通信手法については種々の変形実施が可能である。

　サーバシステム１００は、１つのサーバであってもよいし、複数のサーバを含んでもよい。例えばサーバシステム１００は、データベースサーバとアプリケーションサーバを含んでもよい。データベースサーバは、図３を用いて後述する種々のデータを記憶する。アプリケーションサーバは、図６～図７等を用いて後述する処理を行う。なおここでの複数のサーバは、物理サーバであってもよいし仮想サーバであってもよい。また仮想サーバが用いられる場合、当該仮想サーバは１つの物理サーバに設けられてもよいし、複数の物理サーバに分散して配置されてもよい。以上のように、本実施形態におけるサーバシステム１００の具体的な構成は種々の変形実施が可能である。

　デバイス２００は、例えば種々のセンサを有し、当該センサによってセンシングされたデータ（以下、センシングデータと記載）に基づいて処理を行う。上述した熟練者の暗黙知のデジタル化は、例えばデバイス２００のベンダによって実行されてもよい。例えば熟練者が車椅子での被介助者の姿勢に基づいて、前ずれ横ずれ判定を行う暗黙知を備えていたとする。この場合、座面センサ４４０によって検出される被介助者の姿勢に対応するセンシングデータを収集し、当該センシングデータに基づいて前ずれ横ずれ判定を行うアプリケーションを作成することによって、上記暗黙知をデジタル化することが可能である。例えばベンダは、座面センサ４４０及び上記アプリケーションを提供する。その結果として熟練者でない者（例えば新人職員）は熟練者と同等の前ずれ横ずれ判定等を活用できる。

　また１つのデバイス２００においてデジタル化される暗黙知は１つに限定されない。例えば、座面センサ４４０を用いてデジタル化される暗黙知は、前ずれ横ずれ判定に限定されず、転落可能性の判定行うものや、前ずれ横ずれ判定と転落可能性の両方を組み合わせるものを含んでもよい。前ずれ横ずれ判定とは、被介助者の姿勢の良し悪しの判定に対応し、転落可能性の判定とは、座面からのずり落ちの判定に対応する。また前ずれ横ずれ判定においても、どの程度のずれを前ずれや横ずれと判定するかの判定基準、判定処理内容等が異なる複数の暗黙知が存在しうる。よって各デバイス２００は、１又は複数の暗黙知に対応する処理を実行可能であって、各暗黙知に対応する処理を実行するか否かを切り替えてもよい。例えばベンダは暗黙知をアプリケーションソフトウェア（以下、単にアプリケーションとも表記する）として実装し、サーバシステム１００に登録してもよい。各デバイス２００は、登録されたアプリケーションのうち、実行可能性のあるアプリケーションをダウンロード、インストールすることによって、暗黙知に対応する処理を実行する。

　図２は、デバイス２００と暗黙知（アプリケーション）の関係例を示す図である。図２ではサーバシステム１００に接続されるデバイス２００として、デバイス２００ａ～２００ｅの５つを例示している。図２の例では、デバイス２００ａに暗黙知１及び暗黙知２の２つの暗黙知が対応付けられる。例えばデバイス２００ａに暗黙知１及び暗黙知２のアプリケーションがインストール済みの状態である。デバイス２００ａは例えば後述する転倒リスクに関するデバイスであってもよい。具体的には、デバイス２００ａは座面センサ４４０であって、暗黙知１は前ずれ横ずれ判定に関する暗黙知であり、暗黙知２は転落可能性判定に関する暗黙知であってもよい。暗黙知１及び暗黙知２に対応する処理結果は、例えばサーバシステム１００に送信される。

　デバイス２００ｂ及びデバイス２００ｃは、例えば後述する誤嚥リスクに関するデバイスであり、それぞれが誤嚥リスク等に対処するための複数の暗黙知と対応付けられる。デバイス２００ｄ及びデバイス２００ｅは、例えば後述する褥瘡リスクに関するデバイスであり、それぞれが褥瘡リスク等に対処するための複数の暗黙知と対応付けられる。このようにすれば、種々のデバイスを用いて多様な暗黙知をデジタル化することが可能である。なおここでは１つのデバイス２００につき２つの暗黙知を例示しているが、１つのデバイス２００と対応付けられる暗黙知の数はこれに限定されない。

　本実施形態の手法では、状況に応じて使用する暗黙知を切り替えることが可能である。例えば、図２に示した暗黙知１～暗黙知１０はその全てを使用する必要はなく、必要に応じて使用／不使用が切り替えられる。暗黙知の切り替えは、使用するデバイス２００を切り替えることによって実現されてもよい。例えば転倒リスクが高いが、誤嚥リスク及び褥瘡リスクが低い被介助者を対象とする場合、デバイス２００ａが使用され、デバイス２００ｂ－２００ｅは使用されない。このようにすれば、暗黙知１及び暗黙知２の少なくとも一方が使用され、他の暗黙知が使用されないため、被介助者にとって必要性の高い暗黙知を適切に使用することが可能になる。また被介助者の誤嚥リスクが高まった場合にはデバイス２００ｂやデバイス２００ｃを使用することによって、使用する暗黙知の切り替えが可能である。また誤嚥リスクに対処する場合にも、デバイス２００ｂのみを使用するケース、デバイス２００ｃのみを使用するケース、デバイス２００ｂと２００ｃの両方を使用するケース等が切り替えられてもよい。このようにすれば、例えば誤嚥リスクが高い場合に、図２の暗黙知３～暗黙知６のうち、必要な暗黙知を使用できる。褥瘡リスクが高まった場合も同様であり、デバイス２００ｄやデバイス２００ｅを使用することによって、使用する暗黙知の切り替えが可能である。また転倒リスクが低下した場合にデバイス２００ａの使用を停止する等の切り替えも可能である。

　また暗黙知の切り替えは、使用するデバイス２００を維持しつつ、当該デバイス２００内で使用する暗黙知を切り替えることによって実現されてもよい。例えばデバイス２００ａにおいて、暗黙知１のみを使用するケース、暗黙知２のみを使用するケース、暗黙知１と暗黙知２の両方を使用するケース等を切り替えてもよい。この処理は、例えば各暗黙知に対応するアプリケーションのアクティブ／非アクティブを制御することによって実現できる。

　そして暗黙知の切り替えは、被介助者の能力情報を用いて実行されてもよい。ここでの能力情報は、被介助者の活動能力を表す情報であって、例えばデバイス２００が何らかの暗黙知を用いた処理を行った結果として求められる情報である。能力情報は、例えば転倒リスク、誤嚥リスク、褥瘡リスクの高低に関連する情報であってもよい。能力情報の詳細については後述する。

　例えば、あるデバイス２００において暗黙知の処理結果が求められた場合に、同じデバイス２００の中で使用する暗黙知を切り替える処理が行われてもよい。例えば図２のデバイス２００ａでの暗黙知１の処理結果に基づいて、暗黙知１に対応するアプリケーションと暗黙知２に対応するアプリケーションのアクティブ／非アクティブが切り替えられてもよい。

　また、あるデバイス２００において暗黙知の処理結果が求められた場合に、当該処理結果が他のデバイス２００に影響を与えてもよい。例えばデバイス２００ａでの暗黙知１の処理結果に基づいて、デバイス２００ｂで使用する暗黙知が切り替えられる。例えば、デバイス２００ｂが使用されていない状態から、デバイス２００ｂが使用される状態への切り替えが行われてもよい。あるいは、デバイス２００ｂに対応付けられた暗黙知３及び暗黙知４について、個別にアクティブ／非アクティブが切り替えられてもよい。

　また暗黙知の切り替えは、能力情報に基づくものに限定されず、被介助者の介助シーンや、複数のデバイス２００の併用状況等に基づいて実行されてもよい。暗黙知の切り替えに用いられる情報、及び、暗黙知を切り替える処理の詳細については後述する。

　なお、デバイス２００と暗黙知の対応関係は柔軟に変更することが可能である。例えば、複数のデバイス２００を用いて取得されたセンシングデータに基づいて、１つの暗黙知に対応する処理が実行されてもよい。例えばデバイス２００ａで取得されたセンシングデータ、及び、デバイス２００ｂで取得されたセンシングデータに基づいて、暗黙知１に対応する処理が実行されてもよい。このようにすれば、処理に用いるセンシングデータの種類を増やせるため、処理精度の向上等が可能である。上記の例において、暗黙知１に対応する処理は、デバイス２００ａで行われてもよいし、デバイス２００ｂで行われてもよいし、デバイス２００ａとデバイス２００ｂの分散処理により実現されてもよい。さらに言えば、暗黙知に対応する処理は、センシングデータを取得するデバイス２００で実行されるものに限定されない。例えばデバイス２００ａで取得されたセンシングデータ、及び、デバイス２００ｂで取得されたセンシングデータに基づいて、デバイス２００ａとデバイス２００ｂの何れとも異なるデバイス２００において、暗黙知１に対応する処理が実行されてもよい。例えば図１において、座面センサ４４０で取得されたセンシングデータや検出装置４３０で取得されたセンシングデータに基づいて、スマートフォンであるデバイス２００が暗黙知に対応する処理を実行してもよい。

　なお、以上ではデバイス２００のベンダによって暗黙知がデジタル化される例を説明したがこれには限定されない。例えば、デバイス２００を利用する介助者が、自身の暗黙知をデジタル化することも妨げられない。例えば当該介助者は、暗黙知に対応するアプリケーションを作成し、当該アプリケーションをサーバシステム１００に登録してもよい。このようにすれば、暗黙知のデジタル化、及び利用を促進することが可能になる。

　図３は、サーバシステム１００の詳細な構成例を示すブロック図である。サーバシステム１００は、例えば処理部１１０と、記憶部１２０と、通信部１３０を含む。

　本実施形態の処理部１１０は、下記のハードウェアによって構成される。ハードウェアは、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むことができる。例えば、ハードウェアは、回路基板に実装された１又は複数の回路装置や、１又は複数の回路素子によって構成できる。１又は複数の回路装置は例えばＩＣ（Integrated Circuit）、ＦＰＧＡ（field-programmable gate array）等である。１又は複数の回路素子は例えば抵抗、キャパシター等である。

　また処理部１１０は、下記のプロセッサによって実現されてもよい。本実施形態のサーバシステム１００は、情報を記憶するメモリと、メモリに記憶された情報に基づいて動作するプロセッサと、を含む。情報は、例えばプログラムと各種のデータ等である。メモリは、記憶部１２０であってもよいし、他のメモリであってもよい。プロセッサは、ハードウェアを含む。プロセッサは、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）等、各種のプロセッサを用いることが可能である。メモリは、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリなどの半導体メモリであってもよいし、レジスタであってもよいし、ハードディスク装置（ＨＤＤ：Hard Disk Drive）等の磁気記憶装置であってもよいし、光学ディスク装置等の光学式記憶装置であってもよい。例えば、メモリはコンピュータによって読み取り可能な命令を格納しており、当該命令をプロセッサが実行することによって、処理部１１０の機能が処理として実現される。ここでの命令は、プログラムを構成する命令セットの命令でもよいし、プロセッサのハードウェア回路に対して動作を指示する命令であってもよい。

　処理部１１０は、例えば能力情報取得部１１１、シーン情報取得部１１２、デバイス種類情報取得部１１３、通信処理部１１４を含む。

　能力情報取得部１１１は、被介助者の活動能力を表す能力情報を取得する処理を行う。例えば、能力情報取得部１１１は、デバイス２００からセンシングデータを取得する。ここでのセンシングデータは、例えば所定期間におけるログデータであってもよい。能力情報取得部１１１は、ログデータに基づいて、被介助者の状態の時系列的な変化を求め、当該変化に基づいて能力情報を推定する。ここでの能力情報は、日常的な動作（ＡＤＬ：Activities of Daily Living）に関する指標情報であってもよい。例えばバーセル指数等、ＡＤＬを評価する手法は種々知られており、本実施形態ではそれらを広く適用可能である。また能力情報は、“Frailty and the potential kidney transplant recipient: time for a more holistic assessment?”, Henry H.L. Wu等に、Clinical Frailty Scaleとして開示されている９段階の指標が用いられてもよい。例えば本実施形態の能力情報取得部１１１は、センシングデータに基づいて被介助者が当該９段階のうちの何れの段階に属するかを判定する。

　なお、能力情報はデバイス２００等において求められてもよい。能力情報取得部１１１は、通信部１３０を介して、当該デバイス２００等から能力情報を取得する処理を実行してもよい。

　シーン情報取得部１１２は、被介助者の介助が行われるシーンを判定する。ここでのシーン情報とは、食事介助、排泄介助、移動・移乗介助等、実行される介助の種類を特定する情報であってもよい。またシーン情報は、被介助者の介助を実行する介助者の数や熟練度等、介助者に関する情報であってもよい。またシーン情報は、被介助者の属性等、被介助者に関する情報であってもよい。例えばシーン情報取得部１１２は、ユーザ入力や介助者のスケジュール等に基づいてシーン情報を求める処理を行う。

　デバイス種類情報取得部１１３は、対象となるデバイス２００とともに動作するデバイス２００の種類を特定する情報である。ここでのデバイス種類とは、車椅子、ベッド等の大まかな分類を表すものであって、ベンダを区別しない情報であってもよい。例えば第１ベンダの車椅子と、第１ベンダと異なる第２ベンダの車椅子のデバイス種類が同一であってもよい。例えばデバイス種類情報取得部１１３は、対象となるデバイス２００を使用する被介助者（あるいは当該被介助者を介助する介助者）が使用する他のデバイス２００を特定し、当該他のデバイス２００の種類を表す情報をデバイス種類情報として取得する処理を行ってもよい。

　通信処理部１１４は、通信部１３０を用いた通信を制御する。例えば通信処理部１１４は、データリンク層におけるＭＡＣフレーム等、送信対象となるデータを作成する処理を実行する。また通信処理部１１４は、通信部１３０が受信したデータに対して、フレーム構造の解釈等を行い、必要なデータを抽出し、アプリケーション等の上位層に出力する処理を行ってもよい。

　記憶部１２０は、処理部１１０のワーク領域であって、種々の情報を記憶する。記憶部１２０は、種々のメモリによって実現が可能であり、メモリは、ＳＲＡＭ、ＤＲＡＭ、ＲＯＭ、フラッシュメモリなどの半導体メモリであってもよいし、レジスタであってもよいし、磁気記憶装置であってもよいし、光学式記憶装置であってもよい。

　記憶部１２０は、ユーザ情報１２１、デバイス情報１２２、アプリケーション情報１２３を記憶してもよい。

　本実施形態の手法では、例えば暗黙知はアプリケーションとしてサーバシステム１００に登録されている。そして暗黙知を利用する各ユーザは、デバイス２００をシステムに登録した上で、必要なアプリケーションを当該デバイス２００にダウンロードして利用してもよい。

　ユーザ情報１２１は、情報処理システム１０のユーザを一意に特定するユーザＩＤやユーザ名等の情報、当該ユーザによって利用されているデバイス２００を一意に特定する情報であるデバイスＩＤ等を含む。

　デバイス情報１２２は、デバイス２００に関する情報であって、デバイスＩＤ、デバイス２００の種類を表すデバイス種類ＩＤ、ベンダ、インストール済のアプリケーションのアプリケーションＩＤ等を含む。アプリケーションＩＤは、アプリケーションを一意に特定する情報である。

　アプリケーション情報１２３は、アプリケーションに関する情報であり、アプリケーションＩＤ、アプリケーション名、作成者等を含む。またアプリケーション情報は、アプリケーションの具体的な処理内容を特定する情報を含んでもよい。処理内容を特定する情報は、プログラムのソースコードであってもよいし、実行ファイルであってもよい。またアプリケーションが学習済モデルに対応する場合、当該学習済モデルの構造の情報を含んでもよい。例えば学習済モデルがニューラルネットワーク（以下ＮＮと記載）である場合、学習済モデルの構造とは、ＮＮの層の数、各層に含まれるノード数、ノード間の接続関係、重み、活性化関数等を含む。

　ユーザ情報１２１を用いることによって、情報処理システム１０を利用するユーザを適切に管理することが可能になる。またデバイス情報１２２を参照することによって、各ユーザが使用するデバイス２００の詳細を確認することが可能になる。さらに、アプリケーション情報１２３を参照することによって、サーバシステム１００に登録された各アプリケーションの詳細を確認することが可能になる。

　通信部１３０は、ネットワークを介した通信を行うためのインターフェイスであり、サーバシステム１００が無線通信を行う場合、例えばアンテナ、ＲＦ（radio frequency）回路、及びベースバンド回路を含む。ただしサーバシステム１００は有線通信を行ってもよく、その場合の通信部１３０は、イーサネットコネクタ等の通信インターフェイス及び、当該通信インターフェイスの制御回路等を含んでもよい。通信部１３０は、通信処理部１１４による制御に従って動作する。ただし通信部１３０が、通信処理部１１４とは異なる通信制御用のプロセッサを含むことも妨げられない。通信部１３０は、例えばＩＥＥＥ８０２．１１やＩＥＥＥ８０２．３に規定された方式に従った通信を行ってもよい。ただし具体的な通信方式は種々の変形実施が可能である。

　図４は、デバイス２００の詳細な構成例を示すブロック図である。デバイス２００は、例えば処理部２１０と、記憶部２２０と、通信部２３０と、表示部２４０と、操作部２５０を含む。なお図８～図１４を用いて後述するように、本実施形態の手法では種々の態様のデバイス２００を用いることが可能である。各デバイス２００の構成は図４に限定されず、一部の構成を省略する、他の構成を追加する等の変形実施が可能である。例えばデバイス２００は、加速度センサやジャイロセンサ等のモーションセンサ、撮像センサ、圧力センサ、ＧＰＳ（Global Positioning System）センサ等、デバイス２００に応じた種々のセンサを有してもよい。

　処理部２１０は、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むハードウェアによって構成される。また処理部２１０は、プロセッサによって実現されてもよい。プロセッサは、ＣＰＵ、ＧＰＵ、ＤＳＰ等、各種のプロセッサを用いることが可能である。デバイス２００のメモリに格納された命令をプロセッサが実行することによって、処理部２１０の機能が処理として実現される。

　記憶部２２０は、処理部２１０のワーク領域であって、ＳＲＡＭ、ＤＲＡＭ、ＲＯＭ等の種々のメモリによって実現される。

　通信部２３０は、ネットワークを介した通信を行うためのインターフェイスであり、例えばアンテナ、ＲＦ回路、及びベースバンド回路を含む。通信部２３０は、例えばネットワークを介して、サーバシステム１００との通信を行う。通信部２３０は、例えばＩＥＥＥ８０２．１１の規格に準拠した無線通信をゲートウェイ３００との間で実行し、当該ゲートウェイ３００を介してサーバシステム１００との通信を行ってもよい。

　表示部２４０は、種々の情報を表示するインターフェイスであり、液晶ディスプレイであってもよいし、有機ＥＬディスプレイであってもよいし、他の方式のディスプレイであってもよい。操作部２５０は、ユーザ操作を受け付けるインターフェイスである。操作部２５０は、デバイス２００に設けられるボタン等であってもよい。また表示部２４０と操作部２５０は、一体として構成されるタッチパネルであってもよい。

　またデバイス２００は、発光部、振動部、音入力部、音出力部等、図４には不図示の構成を含んでもよい。発光部は例えばＬＥＤ（light emitting diode）であり、発光による報知を行う。振動部は例えばモータであり、振動による報知を行う。音入力部は例えばマイクである。音出力部は例えばスピーカであり、音による報知を行う。

２．能力情報に基づくデバイス制御
　本実施形態の情報処理システム１０は、図１に示したようにサーバシステム１００とデバイス２００を含む。そしてデバイス２００は、複数の動作モードの何れかで動作してもよい。本実施形態における動作モードとは、使用する暗黙知（アプリケーション）の組み合わせによって決定されるものであってもよい。例えば上述したように、デバイス２００は、異なる暗黙知に対応する複数のアプリケーションをインストール可能であり、当該複数のアプリケーションのそれぞれについて、アクティブ／非アクティブを切り替える。このようにすれば、状況に応じて利用する暗黙知を適切に切り替えることが可能になる。

　特にサーバシステム１００（能力情報取得部１１１）は、デバイスから送信されたセンシングデータに基づいて、被介助者の活動能力を表す能力情報を求めてもよい。そしてサーバシステム１００は、求めた能力情報をデバイス２００に送信する。デバイス２００は、受信した能力情報に基づいて、複数の動作モードのうちのいずれで動作するかを決定する。被介助者の能力情報の変化に合わせて実施すべき介助が変化するため、デバイス２００の望ましい動作が変化する可能性があるところ、本実施形態の手法によれば、能力情報に合わせて動作モードを適切に切り替えることが可能になる。例えば、デバイス２００は能力情報に応じてアプリケーションのアクティブ／非アクティブ（暗黙知の使用／不使用）を適切に切り替えることが可能である。以下、能力情報に基づく処理について説明する。

２．１　概要
　図５は、被介助者の能力情報と、想定されるリスクの関係例を示す図である。例えば被介助者の能力が十分高い場合、日常的な動作を他者の介助なしに実行することが可能であるため、日常におけるリスクは高くない。しかし能力の低下が始まると、例えば被介助者はまず起居動作を行うことが難しくなる。起居動作とは、立ち上がる動作や座る動作を表す。この場合、起居動作を含めた動き出し動作の際にバランスをとることが難しくなるため、被介助者の転倒リスクが増大する。動き出し動作とは、動きが小さい状態（狭義には静止した状態）から動き始める動作を表す。一方で、この段階では動き出し以外の日常的な動作には支障が少ないことが想定される。例えば被介助者は、座位状態を長時間保持すること、立ち上がった後に歩行器等を用いて歩行すること、食事をある程度自由にとること、等が可能である。

　さらに能力が低下すると、例えば被介助者は歩行を行うことが困難になり、車椅子等を用いた移動介助が必要となる。この場合、動き出しにおける転倒リスクが高い状態は上述の例と同様であるが、さらに座位状態を保持する能力も低下するため、転落リスクを考慮する必要も生じる。例えばこの段階の被介助者は、ベッドや車椅子に座っている状態でもバランスを崩してベッドのマットレスや車椅子の座面から転落する可能性がある。

　さらに能力が低下すると、例えば被介助者は食事をうまく取ることができなくなる。例えば、嚥下能力が低下するため、誤嚥リスクが高くなる。誤嚥リスクとは、例えば誤嚥性肺炎が発生する可能性が高くなることを表す。この段階では、被介助者は体を動かすことが可能であると考えられるため、上述の転倒リスク及び転落リスクが高い状態は維持され、さらに誤嚥性肺炎リスクを考慮する必要が生じる。

　さらに能力が低下すると、例えば被介助者は日常的な動作の大部分において介助が必要となる寝たきりの状態に移行する。この場合も、ベッドでのオムツ交換や、車椅子等での移動の可能性があるため、転落リスクは高い。また胃瘻等の特別の事情がなければ経口での食事が継続されるため、誤嚥性肺炎リスクも高い。さらに、ベッドにいる時間が非常に長く、自発的な寝返りも容易でなくなるため、褥瘡リスクも高くなる。一方で、寝たきりの場合には被介助者が自ら動き出すことは想定されないため、動き出し時の転倒リスクは低くなる。

　図５に示したように、被介助者の能力に応じて、想定されるリスクが異なるため、介助者が行うべき介助も変化する。そのため、デバイス２００を用いてデジタル化された暗黙知を利用する場合、用いるべき暗黙知も能力に応じて変化する。その点、本実施形態では能力情報に応じてデバイス２００の動作モードを設定できるため、能力変化に応じた処理を実行可能である。例えば、介護施設等において１０人程度の被介助者をユニットとして介助を行う場合、当該ユニット内に能力の異なる被介助者が混在することも考えられるが、本実施形態の手法によれば介助者が被介助者毎に必要な介助を手動で設定する必要が無い。即ち、複数の被介助者を担当する場合であっても、介助者の負担を増大させることなく、適切な動作モードを設定することが可能である。

　なお図５では上から下に向かって能力が低下する場合を例に説明を行ったが、能力変化の方向はこれに限定されない。例えば疾病の治癒や寛解、リハビリの実施等により能力が回復することもある。本実施形態の手法は能力に応じて動作モードを設定するものであるため、能力が回復する場合にも柔軟に対応可能である。また図５では、「起居できない」、「歩行できない」、「食事がうまくできない」、「寝たきり」の４段階を例示したが、能力情報によって表される能力の段階はこれに限定されず、一部の段階が省略されてもよいし、他の段階が追加されてもよい。また歩行はできるため転倒リスクは低いものの、嚥下能力が低下したため誤嚥リスクが高くなっているといった状態が考慮されてもよい。即ち上記４つの段階は、上述の順に変化していくものに限定されず、より複雑な組み合わせが考慮されてもよい。

　図６は、サーバシステム１００及びデバイス２００の動作を説明するシーケンス図であって、デバイス２００が暗黙知に対応する処理を実行する前に実行される前処理を説明する図である。

　まずステップＳ１０１において、サーバシステム１００は、予めアプリケーションの登録を受け付ける処理を行う。例えば、上述したようにアプリケーションはそれぞれが暗黙知に対応し、デバイス２００のベンダ等によって作成される。アプリケーションの作成者は、例えば任意の端末装置（ＰＣやスマートフォン等）を用いて本実施形態の情報処理システム１０にログインを行った後、当該端末装置の表示部に表示される不図示のベンダ画面を用いて、アプリケーションをサーバシステム１００に登録する処理を行う。サーバシステム１００の処理部１１０は、登録されたアプリケーションに関する情報を、アプリケーション情報１２３として記憶部１２０に記憶する。ここでは、ベンダによって作成されたアプリケーションであるベンダアプリ１～ベンダアプリ３が登録されている例を示している。

　ステップＳ１０２において、デバイス２００を使用するユーザの操作に基づいて、デバイス２００の登録リクエストをサーバシステム１００に送信する。ここでのユーザは、暗黙知を利用する介助者であってもよいし、介護施設の管理者等であってもよい。例えばユーザは、新たなデバイス２００を自身の環境に導入する際にステップＳ１０２の処理を実行する。例えばユーザは、デバイス２００の操作部、または、デバイス２００と接続される端末装置の操作部を用いて情報処理システム１０にログインを行った後、不図示のユーザ画面を用いてデバイス２００をサーバシステム１００に登録する処理を行う。登録リクエストは、例えばユーザを特定するユーザＩＤと、デバイス２００のベンダや型番等の情報を含む。

　ステップＳ１０３において、サーバシステム１００の処理部１１０は、登録リクエストに基づく処理を実行する。例えば処理部１１０は、対象のデバイス２００に対して、デバイス２００を一意に特定するデバイスＩＤを付与し、当該デバイスＩＤをデバイス２００に送信する。また処理部１１０は、ログインユーザと、登録リクエストのあったデバイス２００を対応付ける処理を実行してもよい。例えばログインユーザのユーザ情報１２１に、登録リクエストのあったデバイス２００のデバイスＩＤを追加する処理を行ってもよい。また処理部１１０は、デバイス情報１２２に、登録リクエストのあったデバイス２００のデバイスＩＤと、当該デバイス２００のデバイス種類ＩＤ等を対応付けて記憶してもよい。デバイス種類ＩＤは、例えば登録リクエストに含まれるベンダや型番等の情報に基づいて特定可能である。以上の処理によって、新たに導入されるデバイス２００が情報処理システム１０に登録される。

　次にステップＳ１０４において、デバイス２００を使用するユーザの操作に基づいて、デバイス２００が使用するアプリケーションを選択する。例えば、登録済みのデバイス２００がサーバシステム１００にアクセスした場合、サーバシステム１００は、当該デバイス２００において使用可能なアプリケーション一覧画面を返信してもよい。ユーザは、一覧表示されたアプリケーションの中から、使用するアプリケーションを選択するユーザ操作を行う。ここでは、ステップＳ１０１に示す処理で登録されていたベンダアプリ１～ベンダアプリ３を含むアプリケーションが一覧表示されており、ユーザはベンダアプリ１～ベンダアプリ３の選択操作を行った例を考える。

　ステップＳ１０５において、サーバシステム１００は、選択されたアプリケーションのダウンロードを許可し、デバイス２００は選択されたアプリケーションのダウンロードを実行する。またサーバシステム１００は、デバイス２００と、当該デバイス２００にダウンロードされたアプリケーションを対応付ける処理を行ってもよい。例えば処理部１１０は、デバイス２００に関するデバイス情報１２２に、ベンダアプリ１～ベンダアプリ３に対応するアプリケーションＩＤを追加する処理を実行する。

　ステップＳ１０６において、デバイス２００は、ダウンロードしたベンダアプリ１～ベンダアプリ３をインストールする処理を実行する。これにより、デバイス２００は、複数の動作モードの何れかで動作することが可能になる。例えば、デバイス２００は、ベンダアプリ１～ベンダアプリ３のそれぞれについて、アクティブ／非アクティブを切り替えてもよい。この場合、デバイス２００は、２^３＝８通りの動作モードを選択可能である。なお本実施形態では、ベンダアプリ１～ベンダアプリ３の全てが非アクティブである状態も１つの動作モードと考える。また、アプリケーションと動作モードの関係はこれに限定されない。例えば複数のアプリケーションは排他的に動作するものであってもよい。上記の例であれば、デバイス２００は、全てのベンダアプリが非アクティブであるモード、ベンダアプリ１のみがアクティブであるモード、ベンダアプリ２のみがアクティブであるモード、及び、ベンダアプリ３のみがアクティブであるモードの４つの動作モードを設定可能であってもよい。

　図７は、サーバシステム１００及びデバイス２００の動作を説明するシーケンス図であって、被介助者の能力情報に基づいて、デバイス２００の動作モードが変化する例を説明する図である。

　まずステップＳ２０１において、サーバシステム１００は、デバイス２００に対して能力情報を含むデータを送信する処理を行う。図７では、ＡＤＬの指標値が２であるデータが送信された例を示している。

　ステップＳ２０２において、デバイス２００は、取得した能力情報に基づいて、インストール済のベンダアプリのアクティブ／非アクティブを制御する。例えばデバイス２００の記憶部２２０は、能力情報と、動作モードを対応付けた情報を記憶してもよい。デバイス２００の処理部２１０は、当該情報と、サーバシステム１００から取得した能力情報とに基づいて、動作モードを求める処理を行う。例えば記憶部２２０は、ＡＤＬの指標値と、各アプリケーションのアクティブ／非アクティブとを対応付けたテーブルデータを記憶してもよい。処理部２１０は、当該テーブルデータのうち、受信したＡＤＬの指標値に合致するレコードを抽出することによって、各アプリケーションのアクティブ／非アクティブを決定する。ここでは、ベンダアプリ１～ベンダアプリ３のうち、ベンダアプリ１及び２がアクティブとなり、ベンダアプリ３が非アクティブとなる動作モードが設定される。ただし、能力情報に基づいて動作モードを決定する処理は上記の例に限定されず、種々の変形実施が可能である。

　ステップＳ２０２の処理後、デバイス２００は、ベンダアプリ１に従った処理、及びベンダアプリ２に従った処理を実行する。具体的にはデバイス２００の処理部２１０は、センサを用いてセンシングデータを取得し、当該センシングデータを入力として、アプリケーションに規定された処理を実行することによって処理結果を求める。ステップＳ２０３において、デバイス２００は、処理結果をサーバシステム１００に送信する。ここでの処理結果とは、熟練者の暗黙知を用いて実行された判断の結果に相当する。またここでサーバシステム１００に送信される情報は、処理結果に限定されず、センシングデータのログ等の情報を含んでもよい。

　ステップＳ２０４において、サーバシステム１００は、デバイス２００から受信した処理結果に基づく制御を実行する。例えば、処理部１１０は、制御対象デバイスを特定し、当該制御対象デバイスを動作させる制御信号を送信する処理を行ってもよい。ここでの制御対象デバイスは、図２３を用いて後述するリクライニング車椅子５１０や図２４を用いて後述する介護ベッド５２０であってもよい。この場合の制御信号とは、リクライニング車椅子５１０の背面部の角度や介護ベッド５２０のボトム角度の変更を指示する信号であってもよい。また制御信号とは、制御対象デバイスに対して報知の実行を指示する信号であってもよい。例えば、制御対象デバイスは表示部や発光部等の報知部を含むデバイスであって、制御信号は、画像の表示や発光等を用いた報知の実行を制御対象デバイスに指示する信号である。

　また、デバイス２００での処理結果に基づいて制御対象デバイスや制御内容を決定する処理は、サーバシステム１００の処理部１１０が行ってもよいし、デバイス２００の処理部２１０が行ってもよい。後者の場合、ステップＳ２０３において、処理結果に加えて、制御対象デバイスや制御内容を特定する情報が送信されてもよい。またデバイス２００やサーバシステム１００は制御対象デバイスの特定のみを行い、具体的な制御内容の決定は制御対象デバイスにおいて実行されてもよい。この場合、ステップＳ２０３及びＳ２０４では、それぞれ処理結果を送信する処理が実行される。その他、制御対象デバイス及び制御信号等については種々の変形実施が可能である。例えば制御対象デバイスがデバイス２００であってもよい。またステップＳ２０４において、サーバシステム１００は、デバイス２００から送信されたセンシングデータのログを記憶部１２０に記憶する処理を行ってもよい。

　またステップＳ２０５において、サーバシステム１００は、被介助者の能力情報を更新する処理を実行する。例えば能力情報取得部１１１は、上記センシングデータのログに基づいて、能力情報を求めてもよい。例えばサーバシステム１００の記憶部１２０は、センシングデータと能力情報を対応付ける情報を記憶してもよい。処理部１１０は、当該情報と、デバイス２００から送信されたセンシングデータとに基づいて、能力情報を求める処理を実行する。ここで、センシングデータと能力情報を対応付ける情報とは、学習済モデルであってもよい。ここでの学習済モデルを生成するための訓練データは、例えば、被介助者に関連するセンシングデータに対して、専門的な知識を有するもの（例えば医師や熟練の介助者等）が判断した当該被介助者の能力情報が正解データとして付与されたデータである。正解データは、上述したように、能力を表す指標値であってもよいし、個別の能力（後述する座位保持能力、嚥下能力等）の有無や高低を表す情報の集合であってもよい。処理部１１０は、学習済モデルにセンシングデータを入力することによって能力情報を求める。あるいは記憶部１２０が記憶する情報は、能力情報との対応関係が既知のセンシングデータである基準データであってもよい。処理部１１０は、取得されたセンシングデータと当該基準データの類似度を判定し、当該類似度に基づいて能力情報を求めてもよい。ここでの基準データは、例えば能力の高い被介助者を対象として取得されたセンシングデータであってもよい。この場合、基準データとの類似度が高い場合、能力値が高いと判定され、類似度が低い場合能力値が低いと判定される。また基準データは、能力の低い被介助者を対象として取得されたセンシングデータ等、他の情報であってもよい。また処理部１１０は、現在の能力情報を処理に用いてもよい。例えば処理部１１０は、センシングデータに基づいて能力情報の変化量を求め、当該変化量と現在の能力情報とに基づいて、更新後の能力情報を求めてもよい。能力情報を求める処理の具体例については後述する。またステップＳ２０５の処理において、介助者が入力するレポートや、医師等による診察結果等、センシングデータ以外の情報が用いられてもよい。

　ステップＳ２０６において、サーバシステム１００は、デバイス２００に対して、更新後の能力情報を含むデータを送信する処理を行う。図７では、ＡＤＬの指標値が３であるデータが送信された例を示している。

　ステップＳ２０７において、デバイス２００は、取得した能力情報に基づいて、インストール済のベンダアプリのアクティブ／非アクティブを制御する。例えばデバイス２００は上述したように、テーブルデータに基づいて各ベンダアプリのアクティブ／非アクティブを決定する。図７の例では、ベンダアプリ１及び２はアクティブな状態が維持され、且つ、ベンダアプリ３が非アクティブからアクティブに変更される。これにより、ステップＳ２０７以降では、デバイス２００は、ベンダアプリ１～ベンダアプリ３の全てがアクティブとなる動作モードによって動作する状態に移行する。ステップＳ２０７以降の動作は、例えばステップＳ２０３－Ｓ２０６と同様である。

　なお本実施形態の手法は、サーバシステム１００とデバイス２００を含む情報処理システム１０に適用されるものに限定されず、情報処理装置に適用されてもよい。ここでの情報処理装置とは、狭義にはサーバシステム１００である。情報処理装置は、複数の動作モードの何れかで動作し、被介助者の介助に用いられるデバイス２００と通信を行う通信部（図３の通信部１３０に対応）と、デバイス２００から送信されたセンシングデータに基づいて、被介助者の活動能力を表す能力情報を求める処理を行う処理部（図３の処理部１１０、狭義には能力情報取得部１１１に対応）と、を含む。そして情報処理装置の処理部は、デバイス２００が複数の動作モードのうちのいずれで動作するかを決定する情報として、能力情報を、通信部を介してデバイス２００に送信する処理を行う。このようにすれば、デバイス２００から収集した情報に基づいて被介助者の能力情報の推移を推定するとともに、当該能力情報に応じてデバイス２００を動作させることが可能になる。

　また、本実施形態の情報処理システムが行う処理の一部又は全部は、プログラムによって実現されてもよい。情報処理システムが行う処理とは、例えばサーバシステム１００の処理部１１０が行う処理及びデバイス２００の処理部２１０が行う処理の少なくとも一方を含むである。同様に、本実施形態の情報処理装置が行う処理の一部又は全部は、プログラムによって実現されてもよい。

　本実施形態に係るプログラムは、例えばコンピュータによって読み取り可能な媒体である非一時的な情報記憶装置（情報記憶媒体）に格納できる。情報記憶装置は、例えば光ディスク、メモリーカード、ＨＤＤ、或いは半導体メモリなどによって実現できる。半導体メモリは例えばＲＯＭである。処理部１１０等は、情報記憶装置に格納されるプログラムに基づいて本実施形態の種々の処理を行う。即ち情報記憶装置は、処理部１１０等としてコンピュータを機能させるためのプログラムを記憶する。コンピュータは、入力装置、処理部、記憶部、出力部を備える装置である。具体的には本実施形態に係るプログラムは、図６、図７等を用いて上述した各ステップを、コンピュータに実行させるためのプログラムである。

　また本実施形態の手法は、複数の動作モードの何れかで動作し、被介助者の介助に用いられるデバイス２００と、デバイス２００とネットワークを介して接続されるサーバシステム１００と、を含む情報処理システム１０における情報処理方法に適用できる。情報処理方法は、デバイス２００によって取得されたセンシングデータに基づいて、被介助者の活動能力を表す能力情報を求めるステップと、求めた能力情報に基づいて、デバイス２００が複数の動作モードのうちのいずれで動作するかを決定するステップと、を含む。

　以下では、図５に示した各段階を例に、具体的なデバイス２００や、当該デバイス２００において実行される処理について説明する。

２．２　起居できない
＜デバイス及び動作の例：転倒リスク判定＞
　まず起居動作が難しくなった状態において、動き出し時の転倒リスクに対応するためのデバイス２００について説明する。図８～図９は、動き出し時の転倒リスク判定に用いられるデバイス２００の例である。

　図８は、被介助者を撮像する撮像装置４１０の例、及び撮像装置４１０の出力画像ＩＭ１の例を示す図である。撮像装置４１０は、図４に示した各構成に加えて、センシングデータとして撮像画像を出力するイメージセンサを有する。撮像装置４１０は、介護施設のリビングやホール等、多人数がまとまって活動する場所に配置されてもよい。図８の例では、撮像装置４１０はテレビジョン装置の上部に配置される。

　撮像装置４１０の処理部２１０は、撮像画像に基づいて人物の動き出しを検知する処理を行ってもよい。処理部２１０は、例えば撮像装置４１０にインストールされるアプリケーションに従って動作することによって、撮像画像を入力データとして取得し、当該撮像画像から人物を検出する処理、及び、検出された人物の動き出しの有無を判定する処理を実行する。

　例えば撮像装置４１０は、撮像画像に基づいて人物の顔を認識する顔認識処理を行う。例えば撮像装置４１０の記憶部２２０は、検出対象となる人物の顔画像を記憶しており、処理部２１０は、当該顔画像をテンプレートとするマッチング処理に基づいて顔認識処理を行ってもよい。また顔認識処理は種々の手法が知られており、本実施形態ではそれらを広く適用可能である。例えば撮像装置４１０は、検出された顔領域の動きが所与の閾値以下の状態が一定時間継続した場合に、当該状態での顔領域の位置を基準位置に設定する。そして撮像装置４１０は、当該基準位置から所定距離離れた位置に検出領域を設定し、顔領域が当該検出領域に到達した場合に、動き出しがあったと判定してもよい。例えば、立ち上がり動作が行われた場合、顔の位置は相対的に上方に移動することが想定されるため、上記検出領域は基準位置に比べて所定距離だけ上方の位置に設定される領域であってもよい。この場合、顔領域の画像上での位置が基準位置に対して所定距離以上、上方向に移動した場合に、動き出しが検出される。なお、ここでの検出領域は、例えばライン状の領域であるが他の形状の領域が設定されてもよい。

　また撮像装置４１０は、顔認識処理によって対象の被介助者を特定できる。よって撮像装置４１０は、能力情報によって表される能力が所定閾値以下（起居動作ができないことに対応）である被介助者については動き出し検知を行い、能力が当該閾値より高い被介助者については動き出し検知を省略してもよい。

　また動き出しの検出処理は上記の手法に限定されない。例えば撮像装置４１０は、撮像画像に基づいて骨格トラッキング処理を行ってもよい。なお画像に基づく骨格トラッキングの手法としては、“Realtime Multi-Person 2D Pose Estimation using Part Affinity Fields” (https://arxiv.org/pdf/1611.08050.pdf), Zhe Cao他に開示されたOpenPose等、種々の手法が知られており、本実施形態ではそれらを広く適用できる。

　またOpenPoseでは、画像中に撮像された複数の人物のそれぞれについて骨格トラッキングを行い、その結果を表示する手法が開示されている。図８の例であれば、イメージセンサは３人の被介助者を含む撮像画像を出力し、撮像装置４１０は、３人の被介助者のそれぞれを対象として動き出しの有無を判定する。

　例えば、能力が低下することで起居が難しくなっている被介助者は、立ち上がる姿勢を取るだけでも転倒する可能性がある。よって撮像装置４１０は、骨格トラッキングによって立ち上がる姿勢を取っているかを判定してもよい。例えば撮像装置４１０は、座っている状態から手を膝や椅子の座面等について前屈みになったと判定した場合に、立ち上がる姿勢であると判定し、転倒リスクを介助者に通知する。例えば撮像装置４１０は、骨格トラッキング結果から手の位置と膝の位置の間の距離が所定以下であること、肩の位置が所定以上下方に移動したこと等を検出した場合に、被介助者が立ち上がる姿勢を取っていると判定してもよい。

　あるいは、撮像装置４１０は、処理対象データを数秒単位のウィンドウで区分し、各ウィンドウ内において頭や首等の特定の位置が、所定閾値以上移動した場合に立ち上がり等の姿勢変化が起こっていると判定してもよい。なお移動検出の対象となる部位は頭や首以外であってもよい。また移動方向は縦でも横でも斜めでもよい。また検出対象の部位に応じて、検出に用いる閾値が変更されてもよい。あるいは、撮像装置４１０は、静止状態の被介助者を対象とする骨格トラッキングによって検出された特徴点を内包する領域を求め、所定数以上の特徴点が当該領域から外れた場合に、立ち上がり等の動き出し動作があったと判定してもよい。その他、撮像装置４１０を用いた動き出し検出処理の手法については種々の変形実施が可能である。

　図８のＩＭ１は、撮像装置４１０の出力画像の例である。撮像装置４１０は、撮像画像上に何らかの表示オブジェクトを重畳表示してもよい。図８の例では、動き出しが検知された被介助者に対応付けて、「！」マークを含むオブジェクトが表示される。このようにすれば、動き出しが検知された被介助者を分かりやすく介助者に通知することが可能になる。例えば、図７のステップＳ２０３において、撮像装置４１０は出力画像ＩＭ１をサーバシステム１００に送信する。サーバシステム１００は、ステップＳ２０４において、介助者が使用するスマートフォン等に出力画像ＩＭ１を出力する。ただし、撮像装置４１０の出力は、動き出しが検知された被介助者を特定する情報（例えば被介助者のＩＤ）であってもよく、具体的な態様は種々の変形実施が可能である。例えばここでは動き出しが検知された被介助者を通知する例を示したが、被介助者の動きを停止させるための情報が出力されてもよい。例えば撮像装置４１０は、動き出した被介助者を特定し、当該被介助者の家族等の音声データ、動画データ等を出力してもよい。特に認知症の患者の場合、呼びかけへの応答が鈍くなるが、家族等の顔や声は覚えているケースが多く、動きの停止に有効である。このように被介助者の動きを停止させることによって、介助者が介入するまでの時間を稼ぐことが可能である。なお、家族の音声データや動画データを出力する例については、シーン情報に基づくデバイス制御に関連して後述する。

　図９は、ベッド６１０のボトムに配置されるベッドサイドセンサ４２０及び検出装置４３０の例を説明する図である。ベッドサイドセンサ４２０及び検出装置４３０は、例えば図９に示すように、ベッド６１０のボトムとマットレス６２０の間に設けられるシート状またはプレート状のデバイス２００である。なお図９ではベッドサイドセンサ４２０と検出装置４３０の両方を図示したが、何れか一方のみが用いられてもよい。また、以下で説明するようにベッドサイドセンサ４２０と検出装置４３０は圧力センサを有する点で共通するため、ベッドサイドセンサ４２０が検出装置４３０を兼ねてもよいし、検出装置４３０がベッドサイドセンサ４２０を兼ねてもよい。その他、具体的な態様については種々の変形実施が可能である。

　ベッドサイドセンサ４２０は、センシングデータとして圧力値を出力する圧力センサを含み、ボトムのうち、介助者がベッドの上り下りに用いる側に配置される。図９の例では、介助者の上り下りはベッド６１０の手前側を用いて行われる。この際、図９に示すように、ベッド６１０の手前側には転落防止用の柵が配置され、ベッドサイドセンサ４２０は当該柵が設けられない位置に配置されてもよい。このようにすれば、ベッド６１０の上り下りを行うユーザは、一旦、ベッドサイドセンサ４２０上に座る動作を行う。

　ベッドサイドセンサ４２０の処理部２１０は、例えばベッドサイドセンサ４２０にインストールされるアプリケーションに従って動作することによって、圧力値を入力データとして取得し、当該圧力値からベッド６１０上での被介助者の動きを判定する処理を実行する。

　例えば被介助者がベッド６１０から立ち上がる際には、被介助者は、ベッド上で臥位を取っている状態から、ベッドサイドで座位を取った状態（以下、端座位と表記）に移行し、さらに膝やボトム面に手をついて力を加えることで立ち上がり動作を実行することが想定される。ベッドサイドセンサ４２０が検出する圧力値は、臥位、端座位、立ち上がり動作の順で大きくなる。例えばベッドサイドセンサ４２０は、圧力値と所与の閾値の比較処理に基づいて、端座位から立ち上がり動作への変化を検出した場合に動き出しが検出されたと判定してもよい。あるいは、立ち上がり動作をより速い段階で検出するという観点から、ベッドサイドセンサ４２０は、圧力値と所与の閾値の比較処理に基づいて、臥位から端座位への変化を検出した場合に動き出しが検出されたと判定してもよい。

　あるいは、立ち上がり動作が継続されると、被介助者の臀部がボトム面から浮き上がるため、圧力センサから出力される圧力値は大きく減少する。よって処理部２１０は、圧力値の時系列変化に基づいて、圧力値が第１閾値以上に増加した後、第１閾値よりも小さい第２閾値以下に減少した場合に、立ち上がり動作が行われたと判定してもよい。その他、動き出し判定の具体的な処理内容については種々の変形実施が可能である。

　被介助者の動き出しが検出された場合、ベッドサイドセンサ４２０は、その旨を表す情報をサーバシステム１００に送信する。サーバシステム１００は、例えば介助者が使用するスマートフォン等に当該情報を送信し、スマートフォン等において報知処理が実行される。このようにすれば、動き出しが検出された被介助者を分かりやすく介助者に通知することが可能になる。

　また図９に示す検出装置４３０は、被介助者の睡眠に関する情報をセンシングするデバイス２００である。検出装置４３０は、圧力値を出力する圧力センサを含む。

　検出装置４３０は、ユーザが就床すると、マットレス６２０を介してユーザの体振動（体動、振動）を検知する。検出装置４３０が検知した体振動に基づいて、呼吸数、心拍数、活動量、姿勢、覚醒／睡眠、離床／在床に関する情報が求められる。また検出装置４３０は、ノンレム睡眠とレム睡眠の判定や、睡眠の深さの判定を行ってもよい。例えば体動の周期性を分析し、ピーク周波数から呼吸数、心拍数が算出されてもよい。周期性の分析は、例えばフーリエ変換等である。呼吸数は、単位時間あたりの呼吸の回数である。心拍数は、単位時間あたりの心拍の回数である。単位時間は、例えば１分である。また、サンプリング単位時間当たりに体振動を検出し、検出された体振動の回数が活動量として算出されてもよい。またユーザの離床時には、在床時に比べて検出される圧力値が減少するため、圧力値やその時系列的な変化に基づいて離床／在床の判定が可能である。

　例えば検出装置４３０の処理部２１０は、離床／在床の判定結果に基づいて、被介助者が在床から離床へと移行した場合に、動き出しが検出されたと判定してもよい。

　被介助者の動き出しが検出された場合、検出装置４３０は、その旨を表す情報をサーバシステム１００に送信する。サーバシステム１００は、例えば介助者が使用するスマートフォン等に当該情報を送信し、スマートフォン等において報知処理が実行される。このようにすれば、動き出しが検出された被介助者を分かりやすく介助者に通知することが可能になる。

　例えば図８～図９に示した各デバイス２００は、能力情報によって表される被介助者の能力が所定以上である場合には非アクティブである動作モード０に設定され、能力が所定未満である場合にはアクティブである動作モード１に設定される。能力が所定未満とは、ここでは起居動作ができないことを表す。このようにすれば、上述した動き出しの判定動作を適切な状況で実行できる。結果として、転倒リスクが高い被介助者が存在する場合に、当該被介助者の転倒リスクを適切に低減できる。

＜能力情報の更新＞
　また図７のステップＳ２０５に示したように、サーバシステム１００の能力情報取得部１１１は、センシングデータに基づいて能力情報を更新する処理を行ってもよい。例えば能力情報取得部１１１は、センシングデータに基づいて起居に関する状態の変化を判定する。

　例えば能力情報取得部１１１は、センシングデータに基づいて立ち上がりの仕方を判定してもよい。立ち上がり時には、上述したように端座位からボトム面等に手をつき、さらに足に体重をかけ、膝を伸ばしながら背筋を伸ばす動作が実行される。この際、足への体重移動が十分でない場合、重心が相対的に後ろに偏ってしまい、ボトム面に倒れ込む状態になってしまう。また足への体重移動が過剰である場合、重心が前に偏るため、前方へ転倒するおそれがある。また端座位での座り方が浅すぎれば、臀部がボトム面から転落する可能性もある。

　よって能力情報取得部１１１は、撮像装置４１０による骨格トラッキングのログ、ベッドサイドセンサ４２０や検出装置４３０からの圧力値のログに基づいて、立ち上がり時の被介助者の体の動きが適切であるかを判定してもよい。例えば立ち上がり時の動きが正常状態に近いほど能力が高いと判定され、重心の偏りや端座位における臀部の位置等が正常状態に対してずれるほど能力が低いと判定される。

　また能力情報取得部１１１は、所定期間内に実行された立ち上がり動作の回数に基づいて、能力情報を求めてもよい。例えば立ち上がり回数が多いほど能力が高いと判定され、回数が少ないほど能力が低いと判定される。

　また能力情報取得部１１１は、端座位となってから立ち上がるまでの経過時間に基づいて、能力情報を求めてもよい。臥位、端座位、立位は骨格トラッキングの特徴点の位置関係や、圧力値の時系列変化によって判定できる。例えば端座位となってから立ち上がるまでの経過時間が短いほど能力が高いと判定され、経過時間が長いほど能力が低いと判定される。

　また能力情報取得部１１１は、ベッド６１０での活動量に基づいて能力情報を求めてもよい。活動量は、例えば上述したように検出装置４３０によって検出される。また骨格トラッキングの結果やベッドサイドセンサ４２０の出力に基づいて活動量が求められてもよい。例えば活動量が多いほど能力が高いと判定され、活動量が少ないほど能力が低いと判定される。

　本実施形態の手法では、能力情報の判定は上記のうちの何れか１つを用いて実行されてもよいし、２以上が組み合わされてもよい。また上述したように、センシングデータと、センシングデータ以外のデータの組み合わせに基づいて能力情報が求められてもよい。本実施形態の手法によれば、起居動作ができない被介助者の転倒リスクを軽減するとともに、当該被介助者の能力情報の変化を適切に判定することが可能になる。

２．３　歩行ができない
＜デバイス及び動作の例：転落リスク＞
　次に歩行が難しくなった状態において、車椅子６３０等からの転落リスクに対応するために動作するデバイス２００について説明する。図１０～図１１は、転落リスク判定に用いられるデバイス２００の例である。

　図１０は、例えば車椅子６３０の座面に配置されるデバイス２００である座面センサ４４０を示す図である。座面センサ４４０は圧力値を出力する圧力センサを含み、当該圧力値に基づいて、被介助者が車椅子６３０に座った際の姿勢（以下、座姿勢とも記載する）が、正常、前ずれ、横ずれ等を含む複数の姿勢の何れであるかを判定する。前ずれとは、ユーザの重心が通常よりも前方にずれた状態を表し、横ずれとは、ユーザの重心が通常よりも左右の何れか一方にずれた状態を表す。前ずれと横ずれのいずれも、ずり落ちのリスクが相対的に高い状態に対応する。なお、座面センサ４４０は、通常の椅子に配置されるセンサデバイスであってもよいし、ベッド等に座っているユーザの姿勢を判定するセンサデバイスであってもよい。また座面センサ４４０は、被介助者が座面から転落する可能性の有無を判定する転落可能性の判定を行ってもよい。

　図１０の例では、車椅子６３０の座面に配置されるクッション４４１の裏面側に４つの圧力センサＳｅ１～Ｓｅ４が配置される。圧力センサＳｅ１は前方に配置されるセンサであり、圧力センサＳｅ２は後方に配置されるセンサであり、圧力センサＳｅ３は右方に配置されるセンサであり、圧力センサＳｅ４は左方に配置されるセンサである。なおここでの前後左右は、車椅子６３０に被介助者が座った状態において、当該被介助者から見た方向を表す。

　図１０に示すように、圧力センサＳｅ１～Ｓｅ４は、制御ボックス４４２に接続される。制御ボックス４４２は、内部に圧力センサＳｅ１～Ｓｅ４を制御するプロセッサと、プロセッサのワーク領域となるメモリを含む。例えばプロセッサは処理部２１０に対応し、メモリは記憶部２２０に対応する。プロセッサは、圧力センサＳｅ１～Ｓｅ４を動作させることによって圧力値を検出する。

　車椅子６３０に座っている被介助者は、臀部に痛みを感じ、臀部の位置をずらす可能性がある。例えば、臀部が通常よりも前にずれた状態が前ずれであり、左右にずれた状態が横ずれである。また、前ずれと横ずれが同時に発生し、重心が斜めにずれることもある。図１０に示すようにクッション４４１に配置した圧力センサを用いることによって、臀部の位置の変化を適切に検出できるため、前ずれや横ずれを精度よく検出することが可能になる。

　例えば、まず車椅子６３０に移乗して正常な姿勢を取ったタイミングを初期状態とする。初期状態では、被介助者は車椅子６３０の座面に深く座るため、後方の圧力センサＳｅ２の値が相対的に大きいことが想定される。一方、前ずれが起こると、臀部の位置が前方に移動するため、前方の圧力センサＳｅ１の値が大きくなる。例えば制御ボックス４４２のプロセッサは、圧力センサＳｅ１の値が初期状態に比べて所定以上増加した場合に、前ずれが発生したと判定してもよい。圧力センサＳｅ１の値がある閾値を超えると被介助者が車椅子６３０に乗っていると判定され、圧力センサＳｅ１との比較をせずに圧力センサＳｅ２の値の変化だけで前ずれが発生したと判定してもよい。また圧力センサＳｅ１の値を単体で用いるのではなく、圧力センサＳｅ２と圧力センサＳｅ１の値の関係を用いて処理が行われてもよい。例えば圧力センサＳｅ２と圧力センサＳｅ１の出力である電圧値の差が用いられてもよいし、電圧値の比率が用いられてもよいし、差や比率の初期状態に対する変化割合が用いられてもよい。

　同様に横ずれが起こると、臀部の位置が左右何れかの方向に移動するため、左ずれであれば圧力センサＳｅ４の値が大きくなり、右ずれであれば圧力センサＳｅ３の値が大きくなる。よってプロセッサは、圧力センサＳｅ４の値が初期状態に比べて所定以上増加した場合に、左ずれが発生したと判定し、圧力センサＳｅ３の値が初期状態に比べて所定以上増加した場合に、右ずれが発生したと判定してもよい。あるいは、プロセッサは、圧力センサＳｅ４と圧力センサＳｅ３の値の関係を用いて右ずれ及び左ずれを判定してもよい。前ずれの例と同様に、圧力センサＳｅ４と圧力センサＳｅ３の出力である電圧値の差が用いられてもよいし、電圧値の比率が用いられてもよいし、差や比率の初期状態に対する変化割合が用いられてもよい。

　前ずれや横ずれ等が検出された場合、座面センサ４４０は、その旨を表す情報をサーバシステム１００に送信する。サーバシステム１００は、例えば介助者が使用するスマートフォン等に当該情報を送信し、スマートフォン等において報知処理が実行される。また制御ボックス４４２が発光部等を含み、当該発光部を用いて介助者への報知が行われてもよい。このようにすれば、車椅子６３０等における座姿勢の変化を分かりやすく介助者に通知できるため、被介助者の転落を抑制することが可能になる。

　図１１は、車椅子ポジションの調整支援に用いられるデバイス２００である端末装置４５０を示す図である。車椅子ポジションとは、車椅子６３０における被介助者の位置、姿勢に関する情報である。車椅子ポジションは、上述した座姿勢を表してもよいし、クッション等の配置等を含む情報を表してもよい。図１１に示すように、車椅子ポジションの調整では、カメラを有し、当該カメラによって車椅子６３０に座った被介助者の少なくとも上半身を撮像可能な高さに固定された端末装置４５０が用いられてもよい。なお、端末装置４５０は、被介助者のより広い範囲を撮像可能であってもよく、例えば膝までを撮像してもよいし、全身を撮像してもよい。端末装置４５０は、例えば介護施設の所定位置に配置され、介助者は被介助者を車椅子６３０に移乗させた上で、端末装置４５０の正面まで移動させた後、車椅子ポジションの調整を行う。

　端末装置４５０は、表示部を含み、カメラによって撮像された画像と、教師データの比較結果を表示する。ここでの教師データとは、例えば熟練度の高い介助者が、被介助者を適切な姿勢で車椅子６３０に座らせた状態で、当該被介助者を撮像した画像データである。例えば教師データは、端末装置４５０等を用いて事前に登録される。また、サーバシステム１００の記憶部１２０に教師データが登録されてもよい。また教師データは、適切な姿勢を表す画像データそのものに限定されず、付加情報が付加されたデータであってもよい。ここでの付加情報とは、熟練度の高い介助者が重要と考えるポイントを示す情報であってもよい。また教師データは、骨格トラッキングの結果であってもよい。

　端末装置４５０（処理部２１０）は、実際の撮像画像に対して、透過処理が行われた教師データを重畳表示する画像を出力してもよい。また端末装置４５０は、教師データと実際の撮像画像の比較処理に基づいて、車椅子６３０における被介助者のポジションが適切であるか否かを判定し、判定結果を出力してもよい。また被介助者のポジションが適切でない場合、修正すべき点を提示してもよい。修正すべき点とは、例えば教師データと実際の撮像画像の差が所定以上の部位である。

　例えば図１０～図１１に示した各デバイス２００は、能力情報によって表される被介助者の能力が所定以上である場合には非アクティブである動作モード０に設定され、能力が所定未満である場合にはアクティブである動作モード１に設定される。能力が所定未満とは、ここでは歩行ができないことを表す。このようにすれば、上述した車椅子６３０等におけるポジション判定を適切な状況で実行できる。結果として、車椅子６３０やベッド６１０からの転落リスクが高い被介助者が存在する場合に、当該被介助者の転落リスクを適切に低減できる。

＜転倒リスクに関するデバイスの動作＞
　また図５に示したように、歩行ができない被介助者であっても、寝たきりではないため、立ち上がり等の動き出し動作を行う可能性があるため、転倒リスクは高い。歩行ができない被介助者を対象とする場合にも、図８～図９に示した各デバイス２００による動き出し検出は継続されることが望ましい。

　その際、起居できないが歩行ができる状態と、歩行ができない状態では、後者の方がより能力が低く、転倒リスクが高い場合がある。よって図８～図９に示した各デバイス２００は、起居できないが歩行ができる状態では動作モード１で動作し、歩行ができない状態では動作モード１とは異なる動作モード２で動作してもよい。例えば、デバイス２００として検出装置４３０が用いられる場合に、検出装置４３０の処理部２１０は、動作モード１では離床／在床の判定結果に基づいて動き出しを検出し、動作モード２では覚醒／睡眠の判定結果に基づいて動き出しを検出してもよい。例えば動作モード２において、処理部２１０は、睡眠状態から覚醒状態に移行した場合に、動き出しの可能性有りと判定する。このようにすれば、動作モード２では、動作モード１に比べて早い段階で動き出しを検出できるため、より転倒リスクを軽減することが可能になる。

＜能力情報の更新＞
　また図７のステップＳ２０５に示したように、サーバシステム１００の能力情報取得部１１１は、センシングデータに基づいて能力情報を更新する処理を行ってもよい。例えば能力情報取得部１１１は、センシングデータに基づいて座位状態を維持する能力である座位保持能力の変化を判定する。

　例えば能力情報取得部１１１は、センシングデータに基づいて前ずれや横ずれの回数を判定してもよい。例えば前ずれや横ずれの回数が少ないほど座位保持能力が高いと判定され、回数が少ないほど座位保持能力が低いと判定される。

　また能力情報取得部１１１は、姿勢を保持できる時間（以下、姿勢保持時間と表記する）に基づいて座位保持能力を求めてもよい。姿勢保持時間とは、例えば所与の基準姿勢となったタイミングを始点とし、被介助者の姿勢が当該基準姿勢に対して所定以上変化したタイミングを終点とする期間の長さである。姿勢保持時間は、例えば端末装置４５０を用いて介助者が被介助者の姿勢を修正してから、座面センサ４４０によって前ずれや横ずれと判定されるまでの時間であってもよい。例えば姿勢保持時間が長いほど座位保持能力が高いと判定され、姿勢保持時間が短いほど座位保持能力が低いと判定される。また座位保持能力が高ければ同じような姿勢を維持できるため、各圧力センサに対して同程度の圧力がかかった状態が継続される。一方、座位保持能力が下がってくると、前ずれや横ずれとは判定されなかったとしても、頻繁に体が傾いたり姿勢を直したりする。結果として、圧力値が減少するタイミング（圧力の抜け）が生じやすい。よって能力情報取得部１１１は、このような圧力の抜けの回数、頻度、値の減少度合い、抜けの方向（圧力センサＳｅ１～Ｓｅ４の何れの値が減少したか）等に基づいて座位保持能力を推定してもよい。

　本実施形態の手法では、能力情報の判定は上記のうちの何れか１つを用いて実行されてもよいし、２以上が組み合わされてもよい。また上述したように、センシングデータと、センシングデータ以外のデータの組み合わせに基づいて能力情報が求められてもよい。本実施形態の手法によれば、歩行ができない被介助者の転落リスクを軽減するとともに、当該被介助者の能力情報の変化を適切に判定することが可能になる。

２．４　食事がうまくできない
＜デバイス及び動作の例：誤嚥リスク＞
　次に食事がうまくできなくなった状態において、誤嚥リスク（狭義には誤嚥性肺炎リスク）に対応するために動作状態となるデバイス２００について説明する。図１２は、食事における誤嚥リスク判定に用いられるデバイス２００の例である。

　図１２は、食事の場面において利用されるデバイス２００である嚥下ムセ検出装置４６０を例示する図である。図１２に示すように、嚥下ムセ検出装置４６０は、被介助者の首回りに装着されるスロートマイク４６１と、カメラを有する端末装置４６２が用いられる。なお端末装置４６２に代えて、カメラを有する他の装置が用いられてもよい。スロートマイク４６１は、被介助者の嚥下や咳込み等による音声データを出力する。端末装置４６２のカメラは、被介助者の食事の様子を撮像した撮像画像を出力する。端末装置４６２は、例えば被介助者の食事をする卓上に置かれるスマートフォン等である。スロートマイク４６１は、Bluetooth（登録商標）等を用いて端末装置４６２に接続され、端末装置４６２はゲートウェイ３００を介してサーバシステム１００に接続される。ただし、スロートマイク４６１と端末装置４６２の両方がゲートウェイ３００に接続可能であってもよく、具体的な接続態様は種々の変形実施が可能である。

　例えば嚥下ムセ検出装置４６０に含まれるプロセッサは、スロートマイク４６１からの音声データと、カメラを用いて撮像した撮像画像を取得する。ここでのプロセッサは処理部２１０に対応し、例えば端末装置４６２に含まれるプロセッサであってもよい。

　プロセッサは、スロートマイク４６１の音声データに基づいて、被介助者のムセと、嚥下を判定する。首回りに装着したマイクを用いて嚥下を検出するデバイスは、例えば“Swallowing action measurement device and swallowing action support system”という２０１９年２月１５日に出願された米国特許出願第１６／２７６７６８号に記載されている。この特許出願は、その全体が本願明細書において参照により援用されている。プロセッサは、音声データに基づいて、ムセの回数、ムセの時間（発生時刻、継続時間等）、嚥下をしたか否かを検出できる。

　また端末装置４６２のカメラは、例えば図１２に示すように被介助者を正面方向から撮像することによって、被介助者の口、目、及び被介助者が使用する箸やスプーン等を検出できる。なお画像処理に基づいてこれらの顔のパーツや物体を検出する手法は種々知られており、本実施形態では公知の手法を広く適用可能である。

　例えばプロセッサは、カメラの撮像画像に基づいて、被介助者の口が開いているか否か、口から食事が出ているか否か、食事を噛んでいるか否かを判定できる。またプロセッサは、カメラの撮像画像に基づいて、被介助者の目が開いているか否かを判定できる。またプロセッサは、カメラの撮像画像に基づいて、箸やスプーン等が食器の近くにあるか否か、被介助者が持てているか否か、食事をこぼしているか否かを判定できる。

　本実施形態の手法では、これらの情報に基づいて、被介助者の嚥下やムセに関する状況を推定する。例えばプロセッサは、ムセ及び嚥下の検出結果、及び、被介助者の口の開閉判定結果に基づいて、処理を行ってもよい。

　例えばプロセッサは、ムセの回数や時間に基づいて、ムセが頻発しているか否かを判定し、判定結果を出力してもよい。例えばプロセッサは、単位時間あたりのムセの回数が閾値を超えた場合に、ムセが頻発したと判定してもよい。このようにすれば、ムセに関する状況を自動的に判定できる。

　またプロセッサは、嚥下の検出結果、及び、被介助者の口の開閉判定結果に基づいて、被介助者が口を開けてから嚥下するまでの嚥下時間を求めてもよい。このようにすれば、例えば嚥下の回数が減っていることが分かったとしても、食事を口に入れる動作自体が行われていないのか、食事を口に入れたのに嚥下が行われないのか等、具体的な状況を判定できる。例えばプロセッサは、端末装置４６２の撮像画像に基づいて口が閉じた状態から開いた状態に移行したときにタイマーのカウントアップを開始し、スロートマイク４６１によって嚥下が検出された場合にタイマーの計測を停止してもよい。停止時のタイムが、嚥下時間を表す。このようにすれば、食事において誤嚥リスクが高く、介助者が何らかのアクションを実行すべき状況であるかを精度よく判定できるため、熟練者の暗黙知を適切に利用することが可能になる。

　例えば、嚥下ムセ検出装置４６０は、嚥下時間を処理結果としてサーバシステム１００に出力してもよい。またプロセッサは嚥下時間に基づいて食事のペースを判定してもよい。またプロセッサは、１回の食事の中での嚥下時間の変化（例えば最初の方の嚥下時間に対する増加量や比率等）に基づいて、嚥下時間が長いか否かを判定してもよい。あるいはプロセッサは、同じ被介助者について、複数回の食事のそれぞれでの平均嚥下時間等を求め、当該平均嚥下時間の変化に基づいて嚥下時間が長くなったか否かを判定してもよい。

　また端末装置４６２の撮像画像による口の開閉判定結果を用いることによって、介助者がスプーン等を近づけても開口しなくなった状況であるかを判定できる。このように、被介助者が開口を渋る状況において、嚥下時間が長くなった場合、口内に食べ物が残るため込みが発生した状況であると推定できる。また撮像画像を用いて口から食事が出ているか否か、食事を噛んでいるか口の認識結果を用いることによって、被介助者が食べ物を噛み切れなくなった状況であるかを判定できる。例えば噛む回数は通常通りであるのに、嚥下時間が長い場合、噛み切れなくなった状況であると推定される。また撮像画像を用いて目が閉じていると判定された場合、被介助者が眠そうになった状況であるかを判定できる。

　また撮像画像を用いて箸やスプーン等の認識処理を行うことによって、食べ物で遊んでいる、器が持てない、食事をこぼしている等の状況であるか否かが判定されてもよい。

　以上のように、嚥下ムセ検出装置４６０を用いることによって、食事における種々の状況を判定できる。本実施形態の入力データの嚥下ムセ検出装置４６０では、これらの判定のそれぞれが、暗黙知に対応するアプリケーションとして実現されてもよい。例えば嚥下ムセ検出装置４６０は、ムセと嚥下の検出、及び、嚥下時間の算出を行うアプリケーション、ムセの頻発を検出するアプリケーション、危険なムセを検出するアプリケーション、眠そうになった状況かを判定するアプリケーション、食べ物で遊んでいるかを判定するアプリケーション、等を含んでもよい。そして本実施形態では、能力情報等に基づいて、各アプリケーションのアクティブ／非アクティブが制御される。換言すれば、上述した各種の処理は、実行／非実行が柔軟に設定可能であってもよい。そして嚥下ムセ検出装置４６０は、所定の状況であると判定された場合に、その旨を表す情報をサーバシステム１００に送信する。サーバシステム１００は、例えば当該情報に基づいて、介助者が使用する端末装置に報知処理を実行させてもよい。またサーバシステム１００は、嚥下ムセ検出装置４６０によって検出された食事状況に応じた適切なアクションを示す情報を、介助者が使用する機器に出力し、当該機器が当該情報に基づいてアクションを提示してもよい。介助者への提示は、例えばヘッドセットへの音声の出力であってもよいし、スマートフォン等の表示部での表示であってもよいし、他の手法を用いた提示であってもよい。

＜転倒リスクに関するデバイスの動作＞
　また図５に示したように、食事が難しい被介助者であっても、立ち上がり等の動き出し動作を行う可能性があるため、転倒リスクは高い。よって食事が難しい被介助者を対象とする場合にも、図８～図９に示した各デバイス２００による動き出し検出は継続されることが望ましい。各デバイス２００は、例えば上述した動作モード２で動作してもよい。また各デバイス２００は、動作モード２よりも早い段階で動き出し検知が可能な動作モード３で動作してもよい。

＜転落リスクに関するデバイスの動作＞
　また食事が難しい被介助者であっても、車椅子６３０等を用いることが考えられるため、転落リスクが高い。よって食事が難しい被介助者を対象とする場合にも、図１０～図１１に示した各デバイス２００による車椅子ポジションに関する処理は継続されることが望ましい。例えば各デバイス２００は、歩行ができない被介助者を対象とする場合と同様に動作モード１によって動作する。また各デバイス２００は、歩行ができない被介助者を対象とする場合とは異なるモードで動作してもよい。例えば歩行ができない被介助者を対象とする場合、前ずれ横ずれ判定のみを行う動作モードで動作し、食事が難しい被介助者を対象とする場合、前ずれ横ずれ判定に加えて転落可能性の判定を実行可能な動作モードで動作してもよい。

＜能力情報の更新＞
　また図７のステップＳ２０５に示したように、サーバシステム１００の能力情報取得部１１１は、センシングデータに基づいて能力情報を更新する処理を行ってもよい。例えば能力情報取得部１１１は、センシングデータに基づいて嚥下能力の変化を判定する。

　例えば能力情報取得部１１１は、被介助者が口を開けてから嚥下するまでの嚥下時間が短いほど嚥下能力が高いと判定し、嚥下時間が長いほど嚥下能力が低いと判定してもよい。例えば能力情報取得部１１１は、直近の被介助者の平均嚥下時間が過去の被介助者の平均嚥下時間より閾値以上長くなったとき、嚥下能力が低下したと判定し、平均嚥下時間が閾値より長くならなかったとき、嚥下能力が低下していない（維持された）と判定し、平均嚥下時間が短くなったときに、嚥下能力が回復したと判定してもよい。また食形態を変更する前後で、平均嚥下時間の変化が閾値以下であれば、嚥下能力が回復したと判定してもよい。また能力情報取得部１１１は、嚥下能力と座位保持能力の組み合わせに基づいて、能力情報を求めてもよい。例えば能力情報取得部１１１は、車椅子６３０の使用時間や使用頻度に基づいて能力情報を求めてもよい。例えば、座位保持能力が低下した被介助者はベッドでの食事に移行する場合があるため、車椅子６３０を使用できることは座位保持能力が高いことを表す。例えば車椅子の使用頻度が高いほど能力が高いと判定され、使用頻度が低いほど能力が低いと判定される。また、上述したように、嚥下ムセ検出装置４６０は、異なる処理を実行する種々のアプリケーションを実行可能であってもよい。例えば嚥下ムセ検出装置４６０は、まずムセと嚥下の検出、及び、嚥下時間の算出を行うアプリケーションをアクティブにし、能力情報取得部１１１は当該アプリケーションの出力に基づいて能力情報を求めてもよい。そして能力情報が変化した場合に、ムセの頻発を検出するアプリケーション等の他のアプリケーションが非アクティブからアクティブに変更される。このようにすれば、能力情報に基づいて、嚥下ムセ検出装置４６０で実行する処理内容を適切に制御できる。またアクティブであるアプリケーションの数が増えた場合、能力情報取得部１１１は各アプリケーションの出力を組み合わせることによって、より多くのセンシングデータに基づいて嚥下能力を求めてもよい。

２．５　寝たきり
＜デバイス及び動作の例：褥瘡リスク＞
　次にさらに能力が低下し、被介助者が寝たきりになった状態において、褥瘡リスクに対応するために動作するデバイス２００について説明する。図１３～図１４は、褥瘡リスク判定に用いられるデバイス２００の例である。

　図１３は、ベッド６１０の周辺に配置されるデバイス２００であるベッドポジション検出装置４７０を例示する図である。図１３に示すように、ベッドポジション検出装置４７０は、ベッド６１０のフットボード側に固定される第１端末装置４７１と、ベッド６１０のサイドレールに固定される第２端末装置４７２と、第２端末装置４７２の反対側に固定されるディスプレイ４７３を含む。なおディスプレイ４７３は、ベッド６１０に固定されるものには限定されず、ベッドポジション調整を行う介助者が自然に閲覧可能な他の位置に配置されてもよい。例えばディスプレイ４７３は壁面に固定されてもよいし、床面に自立するスタンド等に固定されてもよい。なおディスプレイ４７３は省略が可能である。また、第１端末装置４７１と第２端末装置４７２は何れか一方が省略されてもよい。例えば以下では、第１端末装置４７１がベッドポジションの調整に用いられ、第２端末装置４７２がオムツ交換に用いられる例を説明するがこれには限定されない。

　第１端末装置４７１及び第２端末装置４７２は、例えばカメラを有するスマートフォン等の装置である。第１端末装置４７１は直接サーバシステム１００に撮像画像を送信する。第２端末装置４７２は、直接、又は、第１端末装置４７１を介して、サーバシステム１００にカメラの撮像画像を送信する。ディスプレイ４７３は、サーバシステム１００から送信された画像を直接、または第１端末装置４７１等の他の装置を介して受信し、受信した画像を表示する。なお、第１端末装置４７１及び第２端末装置４７２は、カメラに代えて、あるいはカメラに加えて、深度センサを有してもよい。即ち、これらのデバイスは、デプス画像を出力してもよい。

　例えば、ベッドポジション調整では、教師データの登録処理と、当該教師データを用いたポジション調整処理が実行されてもよい。教師データは、例えば熟練の介助者によって登録される情報である。非熟練者である介助者は、ベッドポジションを調整する際に、教師データを選択し、当該教師データと、実際の被介助者の状態が近くなるように、ベッドポジションを調整する。例えば第１端末装置４７１は、調整対象の被介助者がベッドに横になった状態（クッション等の状態も含む）を撮像した撮像画像を取得し、ディスプレイ４７３は、当該撮像画像と教師データの比較結果を表す画像を表示する。このようにすれば、介助者の熟練度によらず、熟練者と同様のポジション調整を行わせることが可能になる。例えば熟練者は、被介助者をベッド６１０に横たわらせ、褥瘡対策等に好適なポジションとした上で、第１端末装置４７１を用いて対象の被介助者を撮像する。熟練者は、適切なベッドポジションとなっていることを確認した上で、登録ボタンを選択する。これにより、登録ボタンが操作された際に表示されていた静止画像が、教師データとしてサーバシステム１００に送信される。このようにすれば、熟練者が好ましいと考えるポジションを教師データとして登録することが可能になる。この際、付加情報が付加されてもよい点は、上述した車椅子ポジションの例と同様である。

　また実際に介助者がベッドポジションの調整を行う際には、まず第１端末装置４７１を起動し画像の撮像を開始する。例えば介助者が音声で第１端末装置４７１を音声起動させ、ディスプレイ４７３は、第１端末装置４７１が撮像している動画像を表示する。またベッドポジション検出装置４７０は、介助者による教師データの選択処理を受け付けてもよい。処理部１１０は、ユーザ操作に基づいて教師データを決定し、当該教師データをディスプレイ４７３に表示させる制御を行う。

　あるいはベッドポジションの調整対象である被介助者の属性と、教師データに撮像された被介助者の属性の類似度判定に基づいて、処理部１１０が教師データを自動的に選択する処理を行ってもよい。ここでの属性は、被介助者の年齢、性別、身長、体重、既往歴、投薬履歴等の情報を含む。

　あるいは、ベッドポジション検出装置４７０は、ベッドポジションの調整対象である被介助者の属性と、教師データに含まれる付加情報の比較処理に基づいて、教師データを自動的に選択する処理を行ってもよい。例えば教師データの付加情報として「ＸＸという傾向が見られる被介助者は、左肩がＹＹとなるように調整するとよい」といったテキストが含まれるとする。この場合、調整対象の被介助者がＸＸに該当する場合、当該教師データが選択されやすくなる。例えばベッドポジション調整を行う介助者は、第１端末装置４７１に被介助者を特定する情報を入力し、ベッドポジション検出装置４７０は当該情報に基づいて被介助者の属性を特定してもよい。

　ベッドポジション検出装置４７０は、例えば第１端末装置４７１によって撮像されているリアルタイムの撮像画像に対して、透過処理が施された教師データを重畳して表示する画像を出力してもよい。この際、教師データの付加情報が認識可能な態様で表示されてもよい。例えば介助者がヘッドセットのマイク等を用いて「ポイントを教えて」と発話したことが検出された場合、ベッドポジション検出装置４７０は例えばサーバシステム１００を介して、当該テキストを当該ヘッドセットから音声として出力してもよい。

　ベッドポジション検出装置４７０は、例えばポジション調整中に撮像されている画像と、教師データの類似度合いに基づいてＯＫ，ＮＧの何れかを判定し、判定結果を出力してもよい。判定結果は、直接またはサーバシステム１００を介してディスプレイ４７３に表示される。またベッドポジション検出装置４７０は、ＮＧと判定された具体的な点を表示する処理を行ってもよい。例えばサーバシステム１００またはベッドポジション検出装置４７０は、第１端末装置４７１で撮像された画像と教師データを比較し、差分が大きいと判定された箇所を強調表示する処理を行ってもよい。

　このようにすれば、被介助者のベッドポジションと、理想的なベッドポジションを比較して提示することや、理想的なベッドポジションを実現するための情報を提示することが可能になる。

　またベッドポジション検出装置４７０は、オムツ交換の支援に用いられてもよい。オムツ交換における暗黙知として、熟練者は以下の点を重視していることが分かった。
Ａ．側臥位になっているか
Ｂ．オムツの位置が適切か
Ｃ．オムツからパットがでていないか
Ｄ．オムツが適切に装着されたか

　よってベッドポジション検出装置４７０の処理部２１０は、上記のＡ～Ｄのポイントが満たされているか否かを判定し、判定結果をサーバシステム１００に送信する。ここでの処理部２１０は、例えば第２端末装置４７２のプロセッサに対応する。これにより、介助者の熟練度によらず、適切にオムツ交換を実行させることが可能になる。

　例えば第２端末装置４７２は、カメラを用いて被介助者を撮像した動画像を構成する各画像に対して骨格トラッキング処理を行い、元画像に骨格トラッキング結果が重畳表示された画像を処理結果として出力する。処理結果は、例えばディスプレイ４７３に表示されてもよい。このようにすれば、介助者は被介助者のオムツ交換を行いつつ、自然な姿勢でディスプレイ４７３を確認することが可能になる。

　なお、夜間にオムツ交換が行われる場合を考慮し、第２端末装置４７２は照明部を含んでもよい。また被介助者のプライバシーを考慮し、カメラではなく深度センサ等が用いられてもよい。深度センサは、ＴｏＦ（Time of Flight）方式を用いたセンサであってもよいし、構造化照明を用いたセンサであってもよいし、他の方式のセンサであってもよい。

　図１５Ａ及び図１５Ｂは、オムツ交換を行う場合において、ディスプレイ４７３に表示される画像の例である。上述したように、各画像には被介助者と、被介助者の骨格トラッキング結果が含まれる。

　図１５Ａの状態では、被介助者は側臥位で安定しており、第２端末装置４７２のカメラは被介助者を背面側からまっすぐ撮像した状態となる。例えば、図１５Ａでは、被介助者の体の前後方向と、カメラの光軸方向の差が小さい。結果として、図１５Ａに示すように骨格トラッキングの検出対象となる点が多数検出される。

　一方、図１５Ｂは図１５Ａに比べて姿勢が安定しておらず、仰向けに倒れそうな状態となっている。第２端末装置４７２のカメラは斜め後方から被介助者を撮像した状態となるため、骨格トラッキングで検出される点の数が減少する。例えば腰に対応する点がオムツ等に隠れることで検出されない。

　よって第２端末装置４７２は、骨格トラッキングの結果に基づいて上記Ａに示した側臥位になっているか否かを判定してもよい。例えば第２端末装置４７２は、腰等の特定の部位に対応する点が骨格トラッキングによって検出された場合に、側臥位になっていると判定してもよい。ただし、側臥位の判定に腰以外の点の検出有無や、複数の点の間の関係等が用いられてもよく、具体的な手法はこれに限定されない。

　またベッドポジション検出装置４７０は、第２端末装置４７２のカメラが撮像した動画像に基づいてオブジェクトトラッキング処理を行うことによって、継続的に画像中のオムツの領域を検出する。オブジェクトトラッキングについては公知であるため、詳細な説明は省略する。例えば図１５Ａ及び図１５Ｂではオムツ領域ＲｅＤが検出されている。

　ベッドポジション検出装置４７０は、例えば骨格トラッキングの結果と、オブジェクトトラッキングにより検出されたオムツ領域ＲｅＤとの関係に基づいて、上記Ｂに示したオムツの位置が適切か否かを判定してもよい。例えばオムツが装着される位置を考慮し、骨格トラッキングによって検出された腰の位置と、オムツ領域ＲｅＤが所定の位置関係にあるかを判定する。例えば処理部２１０は、骨盤に対応する２点を含む直線がオムツ領域ＲｅＤを通過する場合に、オムツの位置が適切であると判定してもよい。あるいは、熟練者による教師データから骨格トラッキングの結果とオムツ領域ＲｅＤの検出結果を特徴量として抽出し、当該特徴量を入力データとする機械学習が行われてもよい。学習済モデルは、例えば骨格トラッキングの結果とオムツ領域ＲｅＤの検出結果を受け付けた場合に、オムツの位置が適切である確からしさを出力するモデルである。

　またベッドポジション検出装置４７０は、オムツ領域ＲｅＤの水平方向での長さに基づいて、上記Ｃに示したオムツからパットがでていないかを判定してもよい。通常、パットはオムツの内部に収まるものであるため、画像上でのオムツ領域ＲｅＤの長さは、オムツ本体の長さに対応する長さとなる。なお想定されるオムツ領域ＲｅＤのサイズは、オムツの種類及びサイズと、第２端末装置４７２のカメラの光学特性等に基づいて推定できる。一方、パットがはみ出している場合、その分だけ画像上でのオムツ領域ＲｅＤの長さが長くなる。よって、ベッドポジション検出装置４７０は、画像から検出されたオムツ領域ＲｅＤの長さが、想定される長さよりも所定閾値以上大きい場合、オムツがパットから出ており不適切であると判定する。

　またベッドポジション検出装置４７０は、オムツを装着した状態で固定するテープを検出することによって、上記Ｄに示したオムツが適切に装着されたかを判定してもよい。通常、テープはオムツ本体とは異なる色の部材が用いられる。一例としては、オムツ本体が白色であり、テープが青色である。またオムツを適切に装着するために、テープをどのように固定すべきであるかはオムツの構造から既知である。よって処理部２１０は、色に基づいて画像中のテープ領域を検出し、当該テープ領域とオムツ領域ＲｅＤの関係、あるいはテープ領域と骨格トラッキングで検出された腰等の位置の関係に基づいて、オムツが適切に装着されたかを判定できる。なお、メーカや種類の異なる複数のオムツが用いられる場合、ベッドポジション検出装置４７０はオムツを特定する情報を取得し、特定されたオムツの種類等に基づいてオムツが適切に装着されたかを判定してもよい。

　例えばベッドポジション検出装置４７０は、上記Ａ～ＤのそれぞれについてＯＫ，ＮＧを判定し、判定結果をサーバシステム１００に送信する。サーバシステム１００は、判定結果をディスプレイ４７３等に送信する。またベッドポジション検出装置４７０は、ＮＧである場合、正解データとの乖離が大きい部分を強調表示してもよい。

　以上のようにすれば、褥瘡リスクを低減するポジションを取らせることだけでなく、オムツ交換における暗黙知を適切に利用して、介助者に適切にオムツ交換を実行させることが可能になる。なお、オムツ交換の作業において被介助者の体を動かす必要がある。例えば、オムツを配置しやすいように一旦側臥位にする、オムツをはかせるために足を上げる等の作業が介助者によって行われる。そのため、オムツ交換完了時には、被介助者がベッドで横になる際に適した姿勢になっていない可能性もある。よってベッドポジション検出装置４７０は、オムツ交換が完了したことが検出された場合、自動的に上述したベッドポジションを調整するための処理を実行してもよい。例えば第１端末装置４７１は、被介助者の撮像を開始し、ディスプレイ４７３は、第１端末装置４７１によって撮像されているリアルタイムの撮像画像に対して、透過処理が施された教師データを重畳して表示する。

　また以上ではベッドポジション調整支援やオムツ交換支援にスマートフォン等の第１端末装置４７１や第２端末装置４７２を用いる例を説明したが、具体的なデバイス２００はこれに限定されない。

　図１４は、ベッドポジション調整支援やオムツ交換支援に用いられるデバイス２００の他の例であるＡＲ（Augmented Reality）グラスやＭＲ（Mixed Reality）グラス等のメガネ型デバイス４８０を例示する図である。メガネ型デバイス４８０は例えばユーザの視界に対応する領域を撮像するカメラを有する。メガネ型デバイス４８０は、レンズ部分の一部または全部がディスプレイとなっており、外界からの光を透過することによって、あるいはカメラによって撮像されたユーザ視界に相当する画像を表示することによって、外界の状況をユーザに視認させることが可能である。さらにメガネ型デバイス４８０は、ディスプレイを用いることによって、ユーザの視界上に何らかの情報を付加表示する。

　メガネ型デバイス４８０を用いる場合であっても、ベッド６１０上のユーザを撮像した画像を取得できる点は同様である。よってメガネ型デバイス４８０は、上述したように撮像画像と教師データを重畳表示することによってベッドポジション調整を支援する処理を行ってもよい。またメガネ型デバイス４８０は、オムツ領域ＲｅＤに関する判定を行うことによって、オムツ交換を支援する処理を行ってもよい。またオムツ交換が完了した場合に、ベッドポジション調整が開始されてもよい点は、メガネ型デバイス４８０を用いる場合も同様である。例えばオムツ調整の完了が検出された場合に、ベッドポジション調整に係る正解データが、メガネ型デバイス４８０の表示部に透過表示されてもよい。

　またメガネ型デバイス４８０は、被介助者の皮膚を撮像した撮像画像に基づいて、褥瘡の有無や範囲を自動的に検出する処理を行ってもよい。このようにすれば、褥瘡が実際に発生しているか否か、また、発生している場合にはその状態を判定することが可能になる。例えば、被介助者を撮像した画像と、医師等の専門家によって付与された褥瘡領域を特定する正解データとを対応付けた訓練データに基づく機械学習によって、学習済モデルが生成される。メガネ型デバイス４８０は、当該学習済モデルに基づく処理を行うことによって褥瘡の判定を行う。

　また圧力検知及び自動体位変更が可能なマットレスや枕も知られている。圧力検知については、ベッドサイドセンサ４２０や検出装置４３０と同様に圧力センサを用いて行われる。またここでのマットレスや枕は、エアー等を用いて部分毎に高さ（厚み）を調整することによって、被介助者に寝返りを促すものであってもよい。また圧力検知を行うデバイス２００と、自動体位変更を促すデバイス２００は異なってもよい。例えば検出装置４３０は圧力値に基づいて同じ姿勢が継続していると判定した場合に、その旨を表す情報をサーバシステム１００に送信する。サーバシステム１００は、当該情報に基づいて、マットレスや枕を制御することによって、被介助者に体位変更を促してもよい。このようにしても、寝たきりである被介助者の褥瘡リスクを低減することが可能である。また、これらのマットレスや枕の制御手法は１通りに限定されない。例えば同じ寝たきりの中でも細かく能力情報（ＡＤＬ等）が判定され、当該能力情報の高低に応じて体位変更の促し方が変化してもよい。例えば能力が極端に下がっている被介助者の場合、姿勢の維持等も難しいため、体位変更を促した際に過剰に姿勢が変化してしまうケースも考えられる。よってマットレスや枕は、体位変更を促す頻度や、体位変更を促す際のエアーの量等が異なる複数の動作モードを有しており、能力情報の高低に応じて動作モードが制御されてもよい。またマットレス等は、能力が高い間は睡眠状況の改善（例えば側臥位を促すことによるいびき抑制等）を行うモードで動作し、被介助者が寝たきりになった場合に褥瘡リスクを低減するモードで動作してもよく、寝たきり以外の状態も含めて、能力情報に応じた動作モード制御が実行されてもよい。

　また寝たきりの被介助者を対象とする場合、看取りケアに関する暗黙知が用いられてもよい。当該暗黙知に対応するアプリケーションが動作するデバイス２００は、例えばスマートフォン等の端末装置であってもよい。例えばデバイス２００の処理部２１０は、入力データとして、各食事における種類（例えば主菜・副菜としてもよいし、肉類、魚類等材料ごとでもよい）毎の摂取量または摂取割合、水分の摂取量、摂取のタイミング、疾病に関する情報、体重（またはＢＭＩ）の５種類の情報を取得する。これらの入力データは、介助者が入力するものであってもよい。あるいは食事量の自動記録デバイスが用いられることによって、一部の入力データがデバイス２００によって自動的に取得されてもよい。

　処理部２１０は、当該入力データに基づいて、看取りケアを所定期間後に開始すべきか否か、看取りケア開始後にケアの内容を変更するタイミングか否か、を示す出力データを出力する。例えば入力データに対して、熟練者による正解データが付与された訓練データに基づいて、機械学習が行われてもよい。この場合、処理部２１０は学習済モデルに入力データを入力することによって出力データを求める。またＳＶＭ等の他の機械学習手法が用いられてもよいし、機械学習以外の手法が用いられてもよい。

　ここでの看取りケアとは、近い将来に死亡する可能性が高いと考えられる被介助者に対する介助を表す。看取りケアでは、身体的苦痛や精神的苦痛の緩和、対象の被介助者にとって尊厳のある生活の支援等が重視される点で、通常の介助とは異なる。また看取りケアを行っている中でも、時間の経過とともに被介助者の状態が変化することによって、対象の患者に適した介助が変化していく可能性もある。即ち、看取りケアの開始タイミングや、看取りケアの中での介助内容の変更タイミングを提示することによって、被介助者に対して最期まで適切な介助を行うことが可能になる。例えば、熟練の介助者は食事量等の種々の観点から、看取りケアが必要となるタイミングやケア内容を推定する暗黙知を備えており、当該暗黙知をデジタル化することによって、他の介助者も適切な看取りケアが可能になる。

　デバイス２００の処理部２１０は、能力情報によって表される能力が寝たきりを表す状態まで低下した場合に、上記入力データに基づく判定を開始し、判定結果を表す分析結果画面をサーバシステム１００に出力する。なお分析結果画面は、デバイス２００の表示部２４０に表示されてもよい。

　図１６は、分析結果画面の例を示す図である。分析結果画面は、入力データに基づいて求められる特徴量の時系列変化と、看取りケアを所定期間後に開始すべきか否かの判定結果を含んでもよい。ここでの特徴量は、食事量の移動平均等、入力情報のうち重要と判定された情報であってもよいし、上記５つの入力情報に基づいて演算される情報であってもよい。例えば、ＮＮが用いられる場合、特徴量は所与の中間層または出力層の出力であってもよい。例えば、入力データは２０２０年２月１３日までの主菜の摂取量、水分量、ＢＭＩの実測値を含む。処理部２１０は、学習済モデルに基づいて、２０２０年２月１４日以降の主菜の摂取量、水分量、ＢＭＩの推移を推定してもよい。分析画面は、この３つの項目についての実測値及び推定値の時系列変化を表すグラフを含んでもよい。なお、図１６では、これらの値の７日間での移動平均のグラフを例示している。このようにすれば、看取りケアにおいて重要な項目の推移を介助者に容易に把握させることが可能になる。なお、上述したように、入力データは他の項目を含んでもよく、分析結果画面に表示される情報は図１６の例に限定されない。

　また分析結果画面は、看取りケアが行われる可能性のある期間を表示してもよい。図１６の例では、「２０２０－０３－１４から看取りケアの可能性があります」というテキストが表示されるとともに、グラフにおける対応する期間が、それ以外の期間とは異なる背景色を用いて識別可能に表示される。このようにすれば、看取りケアが必要と推定されるタイミング、期間が明示されるため、看取りケアに関する情報を適切にユーザに提示することが可能になる。

＜転倒リスクに関するデバイスの動作＞
　また図５に示したように、寝たきりである介助者は自発的に立ち上がり等の動き出し動作を行う蓋然性が低いため、転倒リスクは想定的に低くなる。よって寝たきりの被介助者を対象とする場合、図８～図９に示した各デバイス２００は非アクティブである動作モード０に設定されてもよい。

＜転落リスクに関するデバイスの動作＞
　一方で、寝たきりの被介助者であっても、車椅子６３０等を用いることが考えられるため、転落リスクが高い。よって寝たきりの被介助者を対象とする場合にも、図１０～図１１に示した各デバイス２００による転落リスクに関する処理は継続されることが望ましい。この際、被介助者は自発的な姿勢変更が難しいため、褥瘡リスクの高くなる。よって図１０に示した座面センサ４４０は、前ずれ横ずれ判定や転落判定に加えて、車椅子６３０での褥瘡リスクの高低を判定する動作モード３で動作してもよい。例えば座面センサ４４０は、圧力値の変化が少ない状態が所定時間以上経過した場合に、褥瘡リスク有りと判定してもよい。同様に、図１１に示した端末装置４５０は、褥瘡を抑制するためのポジションを介助者に提示する動作モードで動作してもよい。

＜誤嚥リスクに関するデバイスの動作＞
　また寝たきりの被介助者であっても経口での食事を継続する場合がある。よって図１２に示した嚥下ムセ検出装置４６０は、寝たきりの被介助者を対象とする場合にも動作を行う。なお嚥下ムセ検出装置４６０は、寝たきりではないが食事が難しい被介助者を対象とする場合と、寝たきりの被介助者を対象とする場合とで同じ動作モードで動作してもよい。また嚥下ムセ検出装置４６０は、寝たきりではないが食事が難しい被介助者を対象とする場合に比べて、寝たきりの被介助者を対象とする場合には、より誤嚥リスクを低減できる動作モードで動作してもよい。例えば、嚥下ムセ検出装置４６０は、嚥下時間との比較に用いる閾値を下げることによって、より誤嚥リスクが検出されやすくしてもよい。あるいは嚥下ムセ検出装置４６０は、寝たきりの被介助者を対象とする場合、食形態に関する判定を追加することによって、誤嚥リスクを低減する動作を行ってもよい。あるいは、嚥下ムセ検出装置４６０は、寝たきりの被介助者を対象とする場合、通常のムセ検出や嚥下時間の算出等の処理に加えて、危険なムセの有無に関する判定を追加することによって、誤嚥リスクを低減する動作を行ってもよい。また嚥下ムセ検出装置４６０は、ムセが頻発しているかを判定する処理を追加してもよいし、被介助者が眠そうにしているか否かを判定する処理を追加してもよい。

　また上記の看取りケアにおいて上述したように、寝たきりの被介助者を対象とする場合、食事量の自動記録が行われてもよい。例えば嚥下ムセ検出装置４６０の端末装置４６２は食事の前後において食事の画像を撮像し、その差分に基づいて食事量を自動記録してもよい。即ち、嚥下ムセ検出装置４６０は、寝たきりの被介助者を対象とする場合、食事量の自動記録を含む動作モードで動作してもよい。また食事量を自動記録するデバイス２００として、嚥下ムセ検出装置４６０とは異なるデバイスが用いられてもよい。

＜能力情報の更新＞
　また図７のステップＳ２０５に示したように、サーバシステム１００の能力情報取得部１１１は、センシングデータに基づいて能力情報を更新する処理を行ってもよい。例えば能力情報取得部１１１は、センシングデータに基づいて褥瘡に関する評価を行い、評価結果に基づいて能力の変化を判定する。

　例えば能力情報取得部１１１は、検出装置４３０等を用いて圧力値の分散度合いを判定し、決まったところに所定時間以上圧力が加わっている場合、褥瘡を抑制する姿勢変化を実現できておらず、能力が低いと判定する。

　また能力情報取得部１１１は、ベッドポジション検出装置４７０からの情報に基づいてポジショニング調整中のＮＧと判定された回数、オムツの位置が適切でない回数を判定し、これらの回数に基づいて能力情報を求めてもよい。例えば、ＮＧと判定された回数が少ないほど、またはオムツの位置が適切でない回数が少ないほど能力が高く判定され、回数が多いほど能力が低く判定される。

　また能力情報取得部１１１は、ＭＲグラス等のメガネ型デバイス４８０から出力される褥瘡の有無に基づいて能力情報を更新してもよい。例えば、褥瘡がない場合、褥瘡がある場合に比べて能力が高く判定される。

２．６　まとめ
　以上、図８～図１４等を用いてデバイス２００の具体例、及び動作例を説明した。上述したように、各デバイス２００は、能力情報に応じて少なくとも非アクティブである動作モード０と、アクティブである動作モード１の間で動作モードを切り替える。また上述したように、アクティブである場合の動作モードも１つに限定されず、処理内容が異なる複数の動作モードが設定されてもよい。

　図１７は、各デバイス２００の動作モードの一例である。図１７に示すように、転倒リスクを検出する撮像装置４１０は、起居できない被介助者については動作モード１で動作し、歩行できない被介助者及び食事がうまくできない被介助者については動作モード２で動作し、寝たきりの被介助者については非アクティブである動作モード０で動作する。

　例えば動作モード１とは、端座位が検出された場合に動き出しがあったと判定されるモードであり、動作モード２とは、覚醒が検出された場合に動き出しがあったと判定されるモードであってもよい。動作モード２は、動作モード１に比べて早い段階で動き出しが検出されるため、より転倒リスクを低減できる。

　また転落リスクを検出する座面センサ４４０は、起居できない被介助者については非アクティブである動作モード０で動作し、歩行できない被介助者については動作モード１で動作し、食事がうまくできない被介助者については動作モード２で動作し、寝たきりの被介助者については動作モード３で動作する。

　例えば動作モード１は前ずれ横ずれのみを行うモードであり、動作モード２は転落可能性の判定が追加されるモードであり、動作モード３は車椅子での褥瘡判定が追加されるモードであってもよい。この例では、能力の低下とともに判定対象が追加されるため、能力変化に伴うリスクの増大に適切に対応できる。

　また誤嚥リスクを検出する嚥下ムセ検出装置４６０は、起居できない被介助者及び歩行できない被介助者については非アクティブである動作モード０で動作し、食事がうまくできない被介助者については動作モード１で動作し、寝たきりの被介助者については動作モード２で動作する。

　例えば動作モード１は嚥下時間に基づく判定を行うモードであり、動作モード２は動作モード１に加えて食形態等のオプションが追加されるモードであってもよい。この例では、能力の低下とともに判定対象が追加されるため、能力変化に伴うリスクの増大に適切に対応できる。

　また褥瘡リスクを検出するベッドポジション検出装置４７０は、起居できない被介助者、歩行できない被介助者、及び食事がうまくできない被介助者については非アクティブである動作モード０で動作し、寝たきりの被介助者については動作モード１で動作する。

　以上のように、本実施形態の手法によれば、能力と各種リスクの関係を考慮した上で、必要性の高い場面で適切にリスク有無の判定や、当該リスクを低減するための処理を行うことが可能になる。なお図１７はデバイス２００、能力情報、動作モードの関係の一例を示すものであり、本実施形態の手法はこれに限定されない。

　能力情報に基づいてデバイス２００の動作モードを設定する場合、被介助者の能力が下がるほど、それを補うためにデバイス２００の機能が追加されることが想定される。ただし、デバイス２００のうちの第１デバイスは、能力情報によって表される能力値が所定閾値以上の範囲において、能力値の低下に伴って使用する機能が増える動作モードに設定され、能力値が所定閾値未満の範囲において、所定閾値以上の範囲に比べて使用する機能が少ない動作モードに設定されてもよい。即ち、本実施形態のデバイスの一部は、ある程度の能力低下についてはそれを補うために機能を増やす方向で動作するが、一定以上の能力低下が見られた場合、機能を減らす方向にシフトしてもよい。このようにすれば、能力に応じた各暗黙知の要否を適切に考慮し、必要性の低い暗黙知に対応するアプリケーションを非アクティブとすることによって処理負荷を低減することが可能になる。

　ここでの第１デバイスは、被介助者の動き出しにおける転倒リスクの判定に用いられるデバイス２００であってもよい。例えば第１デバイスは、図８に示した撮像装置４１０、図９に示したベッドサイドセンサ４２０、図９に示した検出装置４３０のうちの少なくとも１つである。図１７の例であれば、「起居できない」、「歩行できない」、「食事がうまくできない」の範囲内では、これらのデバイス２００の動作モードは処理内容を追加する方向で変化するのに対して、より能力が低い「寝たきり」では非アクティブに対応する動作モードが設定される。このようにすれば、必要性が低下したデバイスの動作が継続することを抑制できる。なお検出装置４３０は「寝たきり」における看取り判定に用いられてもよく、動き出しにおける転倒リスクの判定に用いられるデバイス２００の全てが、能力値の低い状態で機能を減らす必要は無い。

３．シーン情報、デバイス種類情報に基づくデバイス制御
　また本実施形態の手法では、デバイス２００の動作モードの設定に能力情報以外の情報が用いられてもよい。以下、シーン情報及びデバイス種類情報について説明する。

３．１　概要
　図１８は、サーバシステム１００及びデバイス２００の動作を説明するシーケンス図であって、被介助者の能力情報、シーン情報、及びデバイス種類情報に基づいて、デバイス２００の動作モードが変化する例を説明する図である。

　まずステップＳ３０１において、サーバシステム１００は、デバイス２００に対して能力情報、シーン情報、デバイス種類情報を含むデータを送信する処理を行う。なおシーン情報とデバイス種類情報の一方が省略されてもよい。図１８では、ＡＤＬの指標値が２であり、シーンを特定するシーンＩＤが０であり、デバイス種類を特定するデバイス種類ＩＤがｘｘであるデータが送信された例を示している。

　ステップＳ３０２において、デバイス２００は、取得した能力情報、シーン情報、デバイス種類情報に基づいて、インストール済のベンダアプリのアクティブ／非アクティブを制御する。例えばデバイス２００の記憶部２２０は、ＡＤＬの指標値、シーンＩＤ、デバイス種類ＩＤと、各アプリケーションのアクティブ／非アクティブとを対応付けたテーブルデータを記憶してもよい。デバイス２００の処理部２１０は、当該テーブルデータのうち、受信したデータに合致するレコードを抽出することによって、各アプリケーションのアクティブ／非アクティブを決定する。また図１９、図２０、図２２を用いて後述するように、各デバイス２００は、能力情報、シーン情報及びデバイス種類情報に基づいて動作モードを決定するアルゴリズムを記憶してもよい。図１８では、ベンダアプリ１～ベンダアプリ３のうち、ベンダアプリ１及び２がアクティブとなり、ベンダアプリ３が非アクティブとなる動作モードが設定される例を示している。

　ステップＳ３０２の処理後、デバイス２００は、ベンダアプリ１に従った処理、及びベンダアプリ２に従った処理を実行する。ステップＳ３０３において、デバイス２００は、処理結果をサーバシステム１００に送信する。ここでの処理結果とは、熟練者の暗黙知を用いて実行された判断の結果に相当する。またここでの処理結果は、デバイス２００が検出したセンシングデータのログ等を含んでもよい。

　ステップＳ３０４において、サーバシステム１００は、デバイス２００から受信した処理結果に基づく制御を実行する。例えば、処理部１１０は、制御対象デバイスを特定し、当該制御対象デバイスを動作させる制御信号を送信する処理を行ってもよい。

　またステップＳ３０５において、サーバシステム１００は、被介助者の能力情報、シーン情報、デバイス種類情報を更新する処理を実行する。能力情報の更新処理については上述したとおりである。またシーン情報取得部１１２は、デバイス２００から取得したセンシングデータのログ、属性等の被介助者に関する情報、スケジュール等の介助者に関する情報の少なくとも１つに基づいて、シーン情報を求める。またデバイス種類情報取得部１１３は、対象のデバイス２００とともに用いられる他のデバイス２００の種類を表す情報をデバイス種類情報として取得する。具体的な処理の例については後述する。

　ステップＳ３０６において、サーバシステム１００は、デバイス２００に対して、更新後の能力情報、シーン情報、デバイス種類情報を含むデータを送信する処理を行う。図１８では、シーンＩＤが０から１に変更された例を示している。

　ステップＳ３０７において、デバイス２００は、取得したデータに基づいて、インストール済のベンダアプリのアクティブ／非アクティブを制御する。例えばデバイス２００は上述したように、テーブルデータに基づいて各ベンダアプリのアクティブ／非アクティブを決定する。図１８の例では、ベンダアプリ１及び２はアクティブな状態が維持され、且つ、ベンダアプリ３が非アクティブからアクティブに変更される。これにより、ステップＳ３０７以降では、デバイス２００は、ベンダアプリ１～ベンダアプリ３の全てがアクティブとなる動作モードによって動作する状態に移行する。ステップＳ３０７以降の動作は、例えばステップＳ３０３－Ｓ３０６と同様である。

　以下では、シーン情報に基づく動作モードの設定例、及び、デバイス種類情報を用いた動作モードの設定例についてそれぞれ説明する。

３．２　シーン情報に基づく処理の具体例
　サーバシステム１００は、被介助者の介助のシーンを特定するシーン情報を求め、求めたシーン情報をデバイスに送信してもよい。そしてデバイス２００は、能力情報及びシーン情報に基づいて、複数の動作モードのうちのいずれで動作するかを決定する。例えばデバイス２００の記憶部２２０は、能力情報及びシーン情報と、動作モードとを対応付けた情報を記憶する。処理部２１０は、当該情報と、サーバシステム１００から取得した能力情報及びシーン情報とに基づいて、動作モードを求める。能力情報及びシーン情報と、動作モードとを対応付けた情報は、例えば、能力情報の値、シーン情報の値、及び各アプリケーションのアクティブ／非アクティブを対応付けたテーブルデータであってもよい。あるいは、能力情報及びシーン情報と、動作モードとを対応付けた情報は、能力情報及びシーン情報に基づいて、各アプリケーションのアクティブ／非アクティブを求めるアルゴリズムであってもよい。このようにすれば、介助シーンに応じて適切なデバイス２００を動作させること、換言すれば、適切な暗黙知を使用した介助を実行させることが可能になる。

　例えばシーン情報取得部１１２は、被介助者の介助を実行する介助者に関する情報をシーン情報として求めてもよい。具体的には、シーン情報は、被介助者の介助を実行可能な介助者の人数に関する情報であってもよいし、勤務年数、熟練度、保有資格等に関する情報であってもよい。以下、介助者の人数を用いる例について説明する。この場合、デバイス２００は、介助者の人数に応じて動作モードを決定する。

　ここでのデバイス２００は、例えば図８を用いて上述した撮像装置４１０であってもよい。例えば被介助者がまとまって活動を行うリビング等に一定数以上の介助者が存在する場合、介助者同士でフォローすることが可能であるため、被介助者の動き出しを介助者が目視で判断することや、転倒リスク有りと介助者が判断した場合に、適切に介入を行うことが可能である。ここでの介入とは、例えば動き出そうとしている被介助者の近くまで移動し、必要に応じて体を支える等、動き出しをサポートすることを表す。この場合、撮像装置４１０がアクティブとなる必要性が相対的に低い。

　一方で、対象空間に位置する介助者の数が少ない場合、一人の介助者が実行すべきタスクが多くなるため、被介助者の動きを詳細に観察することが難しく、適切なタイミングでの介入が難しいおそれがある。この場合、撮像装置４１０がアクティブとなる必要性が相対的に高くなる。

　以上を鑑みれば、能力情報に加えてシーン情報を用いて撮像装置４１０の動作モードを決定することによって、撮像装置４１０を適切に動作させることが可能になる。

　図１９は、撮像装置４１０における動作モードの決定処理を説明するフローチャートである。まずステップＳ４０１において、撮像装置４１０の処理部２１０は、対象となる被介助者を特定する処理を行う。例えば処理部２１０は、撮像画像に基づく顔認識処理を行うことによって、被介助者を特定する。

　ステップＳ４０２において、処理部２１０は、被介助者の能力情報を取得する。例えば処理部２１０は、図１８のステップＳ３０１やＳ３０６に示すデータをサーバシステム１００から受信することによって、能力情報を特定する。

　ステップＳ４０３において、処理部２１０は、能力情報に基づいて、被介助者の能力が起居できない状態まで低下しているか否かを判定する。能力が低下していない場合（ステップＳ４０３：Ｎｏ）、転倒リスクは低いため、ステップＳ４０４において、処理部２１０は、撮像装置４１０の動作モードを非アクティブに対応するモード０に設定する。なお、本実施形態における能力情報は、ＡＤＬの指標値に限定されず、より詳細な情報、例えば上述した立ち上がりの仕方を表す情報、座位保持能力、嚥下能力、歩行能力等を表す情報であってもよい。さらに言えば、座位保持能力等を求める際に種々のセンシングデータを用いることが可能であるし、当該センシングデータから座位保持能力等を求める際のアルゴリズムにも種々の変形実施が可能である。ステップＳ４０３に示した被介助者の能力が起居できない状態まで低下しているか否かの判定においては、上記の通り、ＡＤＬの指標値に比べてデータ量の多い詳細な能力情報を用いた処理が実行されてもよい。この場合、ステップＳ４０３の処理負荷が大きくなるため、当該処理はサーバシステム１００において実行されてもよい。

　被介助者の能力が起居できない状態まで低下している場合（ステップＳ４０３：Ｙｅｓ）、ステップＳ４０５において処理部２１０はシーン情報に基づいて、介助者の人数を特定するする。例えばサーバシステム１００のシーン情報取得部１１２は、撮像画像に基づいて介助者の人数を判定してもよいし、介護施設等における介助スケジュール（例えば勤務表）に基づいて介助者の人数を判定してもよい。あるいは、介助者にＲＦＩＤ（radio frequency identifier）タグ等を装着するとともに、対象空間の出入り口等に読取り装置を設けることによって、対象空間内の介助者数を表す情報が求められてもよい。デバイス２００の処理部２１０は、これらの情報をサーバシステム１００から取得することによってステップＳ４０５に示す処理を実行する。

　ステップＳ４０６において、処理部２１０は、シーン情報に基づく判定を行う。具体的には、処理部２１０は介助者の人数が所定閾値以下であるかを判定する。人数が所定閾値よりも多い場合（ステップＳ４０６：Ｎｏ）、転倒リスクに対応可能な人員が確保されているため、ステップＳ４０４に移行し、処理部２１０は、撮像装置４１０の動作モードを非アクティブに対応するモード０に設定する。

　人数が所定閾値以下である場合（ステップＳ４０６：Ｙｅｓ）、介助者が不十分であり転倒リスク抑制のためにはデバイス２００のサポートが重要となる。よってステップＳ４０７において、処理部２１０は、撮像装置４１０の動作モードをアクティブに対応するモード１に設定する。なお、図１９ではステップＳ４０５，Ｓ４０６を処理部２１０が行う形態で説明したが、これに限定されることなく例えばサーバシステム１００がステップＳ４０５，Ｓ４０６を実施し、その結果のみを処理部２１０が受領してステップＳ４０４に遷移するか、ステップＳ４０７に遷移するかを判定してもよい。

　またシーン情報は、介助者に関する情報に限定されない。例えば、サーバシステム１００のシーン情報取得部１１２は、被介助者に関する情報をシーン情報として求めてもよい。具体的には、シーン情報は、被介助者の属性を表す属性情報であってもよい。属性情報には、被介助者の年齢、身長、体重、性別、既往歴、服用履歴等が含まれる。例えばシーン情報取得部１１２は、被介助者が認知症であるか否かを表す情報をシーン情報として求める。

　動き出し時の転倒リスク軽減のためには、介助者が呼びかけを行うことによって一旦動作を停止させることが重要であるが、認知症患者は介助者が呼びかけても反応しない場合がある。しかし認知症患者であっても、家族等の親しい関係にある人物の声は覚えているケースが多く、家族による呼びかけには反応する蓋然性が高いという知見がある。

　よって撮像装置４１０は、家族の声を録音した音声データまたは家族が注意喚起をする動画データを記憶し、不図示のスピーカを用いて当該音声データまたは動画データを出力する動作モードを有してもよい。例えば撮像装置４１０の処理部２１０は、図１９に示したように能力情報、及び介助者の人数であるシーン情報に基づいて、アクティブ／非アクティブを判定する。そして処理部２１０は、撮像装置４１０がアクティブに設定された場合、ステップＳ４０１で特定された被介助者が認知症患者であるかを判定する。撮像装置４１０は、被介助者が認知症患者である場合は、家族の音声データ等を出力する動作モードで動作し、認知症患者でない場合は音声データ等を出力しない動作モードで動作する。このようにすれば、被介助者の属性に合わせた動作モードを設定することが可能になる。なお、１人の被介助者に対して、家族等の音声データは複数用意されてもよい。例えば、家族等による呼びかけが１通りのみであると、被介助者は当該呼びかけを覚えてしまい反応が鈍くなる可能性がある。よって撮像装置４１０は、対象の被介助者に対応付けて記憶された複数の音声データのうち、ランダムに選択された１つを出力する処理を行ってもよい。このようにすれば、家族等による呼びかけのバリエーションを増やすことができるため、効果的に被介助者の動き出しを停止させることが可能になる。

　また本実施形態におけるシーン情報とは、食事介助、排泄介助、移動・移乗介助等、介助の種類を表す情報であってもよい。例えばシーン情報取得部１１２は、介助者によるユーザ入力に基づいて、介助の種類を表すシーン情報を取得してもよい。またシーン情報取得部１１２は、介護施設等における介助スケジュールと、現在時刻との関係に基づいて、実行されている介助の種類を求めてもよい。あるいはシーン情報取得部１１２は、介護施設等における被介助者の位置を推定することによって、介助の種類を求めてもよい。例えばシーン情報取得部１１２は、被介助者が食堂にいれば食事介助が行われており、トイレにいれば排泄介助や転倒防止のための介助が行われていると判定する。位置判定は、施設の各所に配置された人感センサ等を用いて行われてもよい。あるいは施設の各所にアクセスポイント（ＡＰ）を配置し、介助者が携帯するステーション機器（ＳＴＡ）がいずれのＡＰに接続したかに応じて位置判定が行われてもよい。

　例えば図１０に示した座面センサ４４０は、上述したように、前ずれ横ずれ判定と、転落可能性の判定を実行可能である。しかし、車椅子６３０に座って食事を行う場合、図１２に示すように被介助者の前には食事を並べるテーブル等が配置されるため、当該テーブルが支えとなり転落が発生する可能性が低い。よって座面センサ４４０は食事中には転落可能性の判定を非アクティブとすることによって、必要性の低い処理を省略できる。

　図２０は、座面センサ４４０における動作モードの決定処理を説明するフローチャートである。まずステップＳ５０１において、座面センサ４４０の処理部２１０は、対象となる被介助者を特定する処理を行う。例えば処理部２１０は、介助スケジュール等に基づいて被介助者を特定してもよいし、ユーザ入力に基づいて被介助者を特定してもよい。

　ステップＳ５０２において、処理部２１０は、被介助者の能力情報を取得する。例えば処理部２１０は、図１８のステップＳ３０１やＳ３０６に示すデータをサーバシステム１００から受信することによって、能力情報を特定する。

　ステップＳ５０３において、処理部２１０は、能力情報に基づいて、被介助者の能力が歩行できない状態まで低下しているか否かを判定する。能力が低下していない場合（ステップＳ５０３：Ｎｏ）、座面センサ４４０を用いた判定の必要性は低いため、ステップＳ５０４において、処理部２１０は、座面センサ４４０の動作モードを非アクティブに対応するモード０に設定する。またステップＳ４０３において上述した例と同様に、ステップＳ５０３では能力情報について、より詳細な情報まで考慮した処理が実行されてもよい。そのため、ステップＳ５０３の処理は、サーバシステム１００において実行されてもよい。

　被介助者の能力が歩行できない状態まで低下している場合（ステップＳ５０３でＹｅｓ）、ステップＳ５０５において処理部２１０はシーン情報として、介助の種類を表す情報を取得する。上述したように、ステップＳ５０５の処理は、ユーザ入力に基づいて行われてもよいし、何らかのセンシングデータに基づいて行われてもよい。

　ステップＳ５０６において、処理部２１０は、シーン情報に基づく判定を行う。具体的には、処理部２１０は介助種類が食事介助であるかを判定する。食事介助である場合（ステップＳ５０６：Ｙｅｓ）、前ずれ横ずれ判定は有用であるが、転落可能性の判定は必要性が低い。よってステップＳ５０７において、処理部２１０は、座面センサ４４０の動作モードを、前ずれ横ずれ判定を行い、且つ、転落可能性の判定を行わないモードに設定する。

　介助種類が食事介助でない場合（ステップＳ５０６：Ｎｏ）、被介助者の前にテーブルがあるとは限らず、車椅子６３０からの転落リスクが高い。よってステップＳ５０８において、処理部２１０は、座面センサ４４０の動作モードを、前ずれ横ずれ判定と、転落可能性の判定の両方を実行するモードに設定する。またステップＳ５０８において、処理部２１０は、座面センサ４４０の動作モードを、前ずれ横ずれ判定を実行せず、且つ、転落可能性の判定を実行するモードに設定してもよい。

　なお、以上では撮像装置４１０及び座面センサ４４０について、シーン情報に基づく処理を行う例を説明した。ただし、他のデバイス２００の動作モードがシーン情報に基づいて決定されてもよい点は言うまでもない。

３．３　デバイス種類情報に基づく処理の具体例
　またサーバシステム１００（デバイス種類情報取得部１１３）は、デバイス２００と同じ被介助者の介助に用いられる併用デバイスの種類を特定するデバイス種類情報を求めてもよい。サーバシステム１００は、デバイス種類情報をデバイス２００に送信する。デバイス２００は、能力情報及びデバイス種類情報に基づいて、複数の動作モードのうちのいずれで動作するかを決定する。例えばデバイス２００の記憶部２２０は、能力情報及びデバイス種類情報と、動作モードとを対応付けた情報を記憶する。処理部２１０は、当該情報と、サーバシステム１００から取得した能力情報及びデバイス種類情報とに基づいて、動作モードを求める。能力情報及びデバイス種類情報と、動作モードとを対応付けた情報は、例えば、能力情報の値、デバイス種類情報の値、及び各アプリケーションのアクティブ／非アクティブを対応付けたテーブルデータであってもよい。あるいは、能力情報及びデバイス種類情報と、動作モードとを対応付けた情報は、能力情報及びデバイス種類情報に基づいて、各アプリケーションのアクティブ／非アクティブを求めるアルゴリズムであってもよい。

　図２１は、図１２を用いて上述した嚥下ムセ検出装置４６０と併用デバイスの例を説明する図である。ここでの併用デバイスは、具体的には本実施形態に係るデバイス２００であってもよい。嚥下ムセ検出装置４６０は食事中に用いられるが、食事は車椅子６３０を用いて行われてもよいし、ベッド６１０を用いて行われてもよい。

　例えば、嚥下ムセ検出装置４６０の併用デバイスは、図１０に示した座面センサ４４０であってもよい。デバイス種類情報取得部１１３は、嚥下ムセ検出装置４６０がアクティブであり、且つ、座面センサ４４０からの検出結果やセンシングデータのログが取得されている場合に、嚥下ムセ検出装置４６０と座面センサ４４０が併用されていると判定してもよい。あるいはデバイス種類情報取得部１１３は、座面センサ４４０からの検出結果やセンシングデータのログに基づいて、被介助者が車椅子６３０に座っていると判定された場合に、嚥下ムセ検出装置４６０と座面センサ４４０が併用されていると判定してもよい。この場合、被介助者は車椅子６３０を用いて食事を行っていると考えられる。

　同様に、嚥下ムセ検出装置４６０の併用デバイスは、図９に示した検出装置４３０であってもよい。デバイス種類情報取得部１１３は、嚥下ムセ検出装置４６０がアクティブであり、且つ、検出装置４３０からの検出結果やセンシングデータのログが取得されている場合に、嚥下ムセ検出装置４６０と検出装置４３０が併用されていると判定してもよい。あるいはデバイス種類情報取得部１１３は、検出装置４３０からの検出結果やセンシングデータのログに基づいて、被介助者が在床状態であると判定された場合に、嚥下ムセ検出装置４６０と検出装置４３０が併用されていると判定してもよい。この場合、被介助者はベッド６１０を用いて食事を行っていると考えられる。

　図２２は、嚥下ムセ検出装置４６０における動作モードの決定処理を説明するフローチャートである。まずステップＳ６０１において、嚥下ムセ検出装置４６０の処理部２１０は、対象となる被介助者を特定する処理を行う。例えば処理部２１０は、端末装置４６２が撮像した撮像画像に対する顔認識処理に基づいて被介助者を特定してもよい。

　ステップＳ６０２において、嚥下ムセ検出装置４６０は、被介助者の能力情報を取得する。例えば処理部２１０は、図１８のステップＳ３０１やＳ３０６に示すデータをサーバシステム１００から受信することによって、能力情報を特定する。

　ステップＳ６０３において、嚥下ムセ検出装置４６０は、能力情報に基づいて、被介助者の能力が、食事がうまくできない状態まで低下しているか否かを判定する。能力が低下していない場合（ステップＳ６０３：Ｎｏ）、嚥下ムセ検出装置４６０を用いた判定の必要性は低いため、ステップＳ６０４において、処理部２１０は、嚥下ムセ検出装置４６０の動作モードを非アクティブに対応するモード０に設定する。

　食事がうまくできない状態まで被介助者の能力が低下している場合（ステップＳ６０３でＹｅｓ）、ステップＳ６０５において嚥下ムセ検出装置４６０はデバイス種類情報取得部１１３から併用デバイスを特定する情報を取得する。なお、上述した例からもわかるように、ここではベッド６１０での食事か車椅子６３０での食事かを判定できればよいため、併用デバイスの種類が重要である一方で、ベンダや型番まで特定する必要性は低い。よってステップＳ６０５において嚥下ムセ検出装置４６０は、併用デバイスのデバイス種類ＩＤを取得する。

　ステップＳ６０６において、嚥下ムセ検出装置４６０は、デバイス種類情報に基づく判定を行う。具体的には、嚥下ムセ検出装置４６０は食事が車椅子６３０を用いて行われているかを判定する。具体的には上述したように、嚥下ムセ検出装置４６０は、デバイス種類情報によって表される併用デバイスが、座面センサ４４０であるか検出装置４３０であるかを判定してもよい。食事が車椅子６３０を用いて行われている場合（ステップＳ６０６：Ｙｅｓ）、食堂等までの移動が可能であることになるため、被介助者の状態が相対的によい。よってステップＳ６０７において、処理部２１０は嚥下ムセ検出装置４６０の動作モードを、嚥下時間等を用いた通常の判定を行うモードに設定する。

　一方、食事がベッド６１０を用いて行われている場合（ステップＳ６０６：Ｎｏ）、被介助者は移動が容易でない、あるいはベッド６１０のように柔軟な背角度設定が可能な機器がなければ食事が難しい状態であると推定される。よってステップＳ６０８において、処理部２１０は嚥下ムセ検出装置４６０の動作モードを、より誤嚥リスクを低減可能なモードに設定する。例えば嚥下ムセ検出装置４６０は、単にムセの有無を検出するだけでなく、ムセの内容を判定する処理を行ってもよい。例えば嚥下ムセ検出装置４６０は、ムセが誤嚥につながりやすい危険なムセであるか否かを判定してもよい。また、嚥下ムセ検出装置４６０は、被介助者が眠そうにしているか否かの判定を行ってもよい。眠そうか否かの判定は、例えば端末装置４６２の撮像する撮像画像に基づいて、目の開閉、口や手の動く頻度等に基づいて行われてもよい。また眠そうか否かの判定が、検出装置４３０を用いて実行されてもよい。

　なお以上では、車椅子６３０とベッド６１０の２通りの併用デバイスを例示したがこれには限定されない。例えば車椅子６３０として、通常の車椅子とリクライニング車椅子とが用いられてもよい。この場合、背角度調整の柔軟性は、通常の車椅子、リクライニング車椅子、ベッド６１０の順で高くなる。よって嚥下ムセ検出装置４６０は、通常の車椅子、リクライニング車椅子、ベッド６１０の順でより手厚い介護が実行できるように、動作モードが制御されてもよい。例えば嚥下ムセ検出装置４６０は、上記の順で、アクティブに設定するアプリケーションの数を増やしてもよい。

　また以上では、嚥下ムセ検出装置４６０が動作モードの設定対象となるデバイス２００であり、座面センサ４４０や検出装置４３０が併用デバイスである例について説明した。ただし、座面センサ４４０や検出装置４３０が動作モードの設定対象となるデバイス２００であり、嚥下ムセ検出装置４６０が併用デバイスとなってもよい。換言すれば、本実施形態の手法では、複数のデバイス２００が併用される場合に、当該複数のデバイス２００が相互に連動することによって動作モードが変更されてもよい。例えば、図１０に示した座面センサ４４０と、図１１に示した車椅子ポジションの調整に用いられる端末装置４５０は、いずれか一方を用いることでも転落リスクの低減に有用である。ただし、座面センサ４４０及び端末装置４５０は両方が併用されてもよい。そしてこの場合、一方のデバイス２００の制御に連動して、他方のデバイス２００の制御が行われてもよい。

　例えば、能力情報に基づいて被介助者が歩行できない状態に移行したと判定された場合、まず座面センサ４４０がアクティブに対応する動作モードに移行し、端末装置４５０は非アクティブに対応する動作モードを維持してもよい。このようにすれば、まずは前ズレ横ズレ判定が行われるとともに、ログデータを用いて座位保持能力が求められる。

　そして、座位保持能力が所定以下に低下したと判定された場合、端末装置４５０はアクティブに対応する動作モードに移行する。これにより、デバイス種類情報取得部１１３は、座面センサ４４０に対して、端末装置４５０が併用デバイスである旨のデータを送信する。そして座面センサ４４０は、端末装置４５０が併用される場合、併用されない場合とは異なる動作モードに設定されてもよい。例えば座面センサ４４０の処理部２１０は、判定における閾値を変更してもよい。あるいは、座面センサ４４０は、前ズレ横ズレ判定等における基準（初期値）を内部で決定する動作モードから、端末装置４５０を用いたポジション調整が行われたタイミング等に基づいて当該基準を決定する動作モードへ切り替わってもよい。またこれ以外の場合にも同様に、座面センサ４４０と端末装置４５０の一方の情報に基づいて、他方の制御が変更されてもよい。

　あるいは、座面センサ４４０は、端末装置４５０において取得された情報に基づいて、動作モードが制御されてもよい。例えば端末装置４５０では、介助者が被介助者の姿勢を調整する際に気をつけるべきポイントを入力できる。例えば、右肩の位置を注意する、右腕の下にクッションを入れる等のポイントが入力されることがあり、端末装置４５０では、当該ポイントに基づいて、被介助者の属性を推定できる。上記の例であれば、被介助者が右肩麻痺気味であるという属性が求められる。座面センサ４４０は、これらの情報に基づいて動作モードを決定してもよい。例えば座面センサ４４０は、前ずれ横ずれ判定を行うアプリケーションとして、麻痺の有無や麻痺が生じている部位に応じて異なる複数のアプリケーションを記憶してもよい。そして座面センサ４４０は、端末装置４５０から取得された属性に基づいて、各アプリケーションのアクティブ／非アクティブを制御する。上記の例であれば、座面センサ４４０は、右肩麻痺の被介助者に適した前ずれ横ずれ判定を行うアプリケーションをアクティブとし、他の前ずれ横ずれ判定を行うアプリケーションを非アクティブに設定する。このようにすれば、前ずれ横ずれ判定の暗黙知を複数使用可能な座面センサ４４０において、被介助者の属性に合わせて暗黙知を切り替えることが可能になる。

　また本実施形態のサーバシステム１００は、併用デバイスの動作モードを特定するモード情報を取得し、デバイス種類情報及びモード情報をデバイス２００に送信してもよい。デバイス２００は、能力情報、デバイス種類情報及びモード情報に基づいて、複数の動作モードのうちのいずれで動作するかを決定する。

　例えば座面センサ４４０において、前ずれ横ずれ判定に加えて転落可能性の判定を行う動作モードに移行した場合、端末装置４５０では車椅子ポジションの適否を判定する通常処理に加えて、クッション等をレコメンドする追加処理を実行する動作モードに移行してもよい。あるいは、座面センサ４４０での動作モードが変化した場合に、端末装置４５０において正解と判定する教師データを切り替える処理が実行されてもよい。その他、具体的な動作モードの連携手法については種々の変形実施が可能である。

　このようにすれば、単純なアクティブ／非アクティブに限定されず、より詳細な動作モードを用いて、複数のデバイス２００を連動させることが可能になる。上記の例であれば、車椅子ポジションの検出に係るデバイス２００と、車椅子ポジションの調整支援に係るデバイス２００を適切に連携させられるため、被介助者の転落リスク等をより低減することが可能になる。なおここでは座面センサ４４０と端末装置４５０の連携について説明したが、他のデバイス２００が連携して動作することも妨げられない。

　また以上では能力情報とシーン情報の組み合わせ、及び能力情報とデバイス種類情報の組み合わせについて説明したが、能力情報、シーン情報及びデバイス種類情報の３つが組み合わされてもよい。

　また本実施形態の手法では、介助の種類とデバイス２００の種類とが対応付けられてもよい。例えば、図１２に示した嚥下ムセ検出装置４６０は、食事介助に特有のデバイス２００であり、嚥下ムセ検出装置４６０が動作中である場合、被介助者の食事介助が行われている蓋然性が高い。このように、デバイス２００の中にはデバイス種類情報と介助の種類の対応付けが可能なデバイスが存在する。例えば、嚥下ムセ検出装置４６０は、アクティブ状態であればゲートウェイ３００を介してサーバシステム１００と通信するため、シーン情報取得部１１２は、嚥下ムセ検出装置４６０との通信有無に基づいて、嚥下ムセ検出装置４６０の動作状態を判定できる。

　例えばサーバシステム１００のシーン情報取得部１１２は、デバイス種類情報取得部１１３が取得したデバイス種類情報に基づいて、介助の種類を表すシーン情報を求め、当該シーン情報をデバイス２００に送信してもよい。例えばシーン情報取得部１１２は、嚥下ムセ検出装置４６０がアクティブである場合に食事中と判定し、非アクティブである場合に食事中でないと判定する。あるいはサーバシステム１００は、デバイス種類情報取得部１１３が取得したデバイス種類情報をデバイス２００に送信し、デバイス２００において、当該デバイス２００に対応付けられた介助種類に応じて動作モードを決定する処理を行ってもよい。例えばデバイス２００は、嚥下ムセ検出装置４６０が併用デバイスである場合に、食事介助に適した動作モードを選択する処理を行ってもよい。以上のように、介助の種類に合わせた動作モード設定は、シーン情報に関する処理として実行されてもよいし、デバイス種類情報に関する処理として実行されてもよく、具体的な実施態様は種々の変形実施が可能である。

４．デバイスの他の例
　また本実施形態におけるデバイス２００は、上述したものに限定されない。例えば本実施形態のデバイス２００は、軽度認知障害（ＭＣＩ：Mild Cognitive Impairment）の判定を行うＭＣＩ判定デバイスであってもよい。例えばＭＣＩ判定デバイスは、音声や画像を用いて被介助者に対して質問を行い、当該質問に対する応答を受け付ける処理を行う。ここでの質問は、ＭＭＳＥ（Mini-Mental State Examination）等を用いたものであってもよいし、他の方式の質問であってもよい。ＭＣＩ判定デバイスは、被介助者の応答に基づいてＭＣＩ判定を行う。またＭＣＩ判定デバイスは、被介助者の睡眠に関する情報等に基づいてＭＣＩの判定を行ってもよい。

　また本実施形態におけるデバイス２００は、介助の履歴を自動で記録する介助記録デバイスであってもよい。例えば介助記録デバイスは、介助者及び被介助者の少なくとも一方の位置情報を検出するデバイス２００であってもよい。介助記録デバイスは、例えば対象の人物がベッド６１０にいる時間、トイレにいる時間、風呂にいる時間、食堂にいる時間等を判定し、判定結果に基づいてどのような種類の介助がどの程度の頻度、時間で行われたかを介助記録として記憶する処理を行う。介助記録デバイスは、例えば介助スケジュール等が厳密に設定されていない在宅介護等に有用である。

　また本実施形態のデバイス２００は、図２３に示す背もたれの角度調整が可能なリクライニング車椅子５１０や、図２４に示すボトム面の角度調整が可能な介護ベッド５２０を含んでもよい。リクライニング車椅子５１０及び介護ベッド５２０は、例えば図７や図１８に示した制御対象デバイスである。例えば、嚥下ムセ検出装置４６０によってムセが検出された場合に、被介助者の嚥下に適した角度に背もたれやボトムの角度が制御される。

　また、座面センサ４４０や端末装置４５０の処理結果に基づいてリクライニング車椅子５１０が制御されてもよい。例えば、図１０や図１１に示した車椅子６３０は、制御対象デバイスであるリクライニング車椅子５１０であってもよい。同様に、ベッドサイドセンサ４２０、検出装置４３０、ベッドポジション検出装置４７０、メガネ型デバイス４８０等の処理結果に基づいて介護ベッド５２０が制御されてもよい。例えば、図９、図１３、図１４に示したベッド６１０は制御対象デバイスである介護ベッド５２０であってもよい。

　その他、本実施形態で用いられるデバイス２００は、形状、センサの数や種類、処理内容等に関して種々の変形実施が可能である。

５．デバイス間通信
　以上の説明では、例えば図１８のステップＳ３０３に示したように、サーバシステム１００が、デバイス２００における処理結果を受信する。また図１８のステップＳ３０４に示したように、サーバシステム１００が当該処理結果に基づく制御を行わせるための制御信号を制御対象デバイスに送信する。また図１８のステップＳ３０６に示したように、動作モードを決定する情報が更新された場合、当該情報のデバイス２００への通知もサーバシステム１００が実行する。

　ただし、サーバシステム１００における処理負荷が過剰に増大することを抑制する観点から、本実施形態では、デバイス２００における処理結果に基づく制御対象デバイスの制御、及び、シーン情報等の通知の少なくとも一方が、サーバレスで実行されてもよい。以下、具体的な情報処理システム１０を例示しつつ説明する。

　図２５は、サーバレスでの制御が実行される場合の情報処理システム１０の構成例を示す図である。本実施形態の情報処理システム１０は、所与の空間へのデバイス２００の出入りを検出する入退室管理装置７００と、空間内に位置するデバイス２００とサーバシステム１００との通信を中継するゲートウェイ３００を含んでもよい。また図１と同様に、情報処理システム１０は、サーバシステム１００、デバイス２００を含む。図２５の例では、デバイス２００としてデバイス２００－１、デバイス２００－２、デバイス２００－３を例示している。

　図２５に示すように、ゲートウェイ３００は例えば介護施設等における居室に配置され、少なくとも当該居室内に位置するデバイス２００との間で十分な強度での電波の送受信が可能な機器である。

　また図２５に示す入退室管理装置７００は、例えば居室の出入り口の近傍に配置され、デバイス２００の入室または退室を検出する装置である。入退室管理装置７００は、例えばＢＬＥ（Bluetooth Low Energy）等の近距離無線通信を行う機器であり、所定距離以下の位置にあるBluetooth対応機器との通信を行う。例えば入退室管理装置７００は、居室内に配置され、当該入退室管理装置７００とＢＬＥ通信が可能なデバイス２００が当該居室内に位置すると判定してもよい。

　あるいは、入退室管理装置７００はより詳細な判定を行ってもよい。例えば、入退室管理装置７００は、居室内の異なる位置に複数配置されてもよい。そして複数の入退室管理装置７００が、それぞれデバイス２００と通信を行い、当該通信における電波強度（例えばＲＳＳＩ：Received Signal Strength Indicator）に基づいてデバイス２００との距離を推定する。このようにすれば、位置が既知である複数の点それぞれからの距離が求められるため、デバイス２００の位置を推定できる。入退室管理装置７００は、推定された位置と、既知の情報である居室の広さ、形状等に基づいて、デバイス２００が居室内に位置するか否かを判定してもよい。その他、入退室の具体的な判定は種々の変形実施が可能である。

　デバイス２００の記憶部２２０は、当該デバイス２００に関する情報を記憶する。デバイス２００に関する情報は、少なくともデバイス２００を特定するデバイスＩＤを含む。またデバイス２００に関する情報は、図３を用いて上述したデバイス情報１２２の一部または全部を含んでもよい。入退室管理装置７００は、デバイス２００とのＢＬＥ通信において、通信対象であるデバイス２００に関する情報を取得する。このようにすれば、入退室管理装置７００は、対象の空間に入室しているデバイス２００を適切に特定できる。

　またデバイス２００の記憶部２２０は、対象のデバイス２００がゲートウェイ３００を介した通信に用いるアドレス情報を記憶してもよい。ここでのアドレス情報は、例えばＩＰアドレスであってもよいし、ＩＰアドレスを特定可能な他の情報（例えばＭＡＣアドレス）であってもよい。入退室管理装置７００は、デバイス２００とのＢＬＥ通信において、通信対象であるデバイス２００のアドレス情報を取得する。

　また入退室管理装置７００はＢＬＥを用いる機器に限定されず、ＮＦＣ（Near Field Communication）等の他の通信方式等を広く適用可能である。

　入退室管理装置７００は、不図示のメモリを有し、当該メモリは居室内に位置する既存デバイスを特定する情報である既存デバイス情報を記憶してもよい。このようにすれば、対象の居室内にどのようなデバイス２００が位置しているかを適切に管理することが可能になる。図２５の例では、居室内には既にデバイス２００－１及びデバイス２００－２が入室済である。例えば入退室管理装置７００は、デバイス２００－１が入室した際に、デバイス２００－１とのＢＬＥ通信に基づいて、当該デバイス２００－１のデバイスＩＤを既存デバイス情報に追加する処理を実行する。同様に、入退室管理装置７００は、デバイス２００－２が入室した際に、デバイス２００－２のデバイスＩＤを既存デバイス情報に追加する処理を実行する。これにより、居室内にデバイス２００－１及びデバイス２００－２が存在しているという状態が既存デバイス情報として保持される。

　入退室管理装置７００は、保持している既存デバイス情報を、入室済のデバイス２００に対して送信する処理を行ってもよい。例えば入退室管理装置７００は、デバイス２００－１に対して、デバイス２００－１及びデバイス２００－２のデバイスＩＤを含む既存デバイス情報を送信する。このようにすれば、デバイス２００－１は、居室内にデバイス２００－１自身に加えて、デバイス２００－２が存在していることを認識できる。同様に、入退室管理装置７００がデバイス２００－２に対して既存デバイス情報を送信することによって、デバイス２００－２は、居室内にデバイス２００－１が存在していることを認識できる。

　また既存デバイス情報は、デバイスＩＤとアドレス情報とが対応付けられた情報であってもよい。例えば入退室管理装置７００は、各デバイス２００に対して、デバイス２００－１のデバイスＩＤ及びアドレス情報と、デバイス２００－２のデバイスＩＤ及びアドレス情報を送信する。このようにすれば、各デバイス２００は、他のデバイス２００が存在することを表す情報に加えて、当該他のデバイス２００とゲートウェイ３００を介して通信を行う際のアドレス情報も取得できる。

　図２５の例のように、新たにデバイス２００－３が居室に入室する場合も同様である。入退室管理装置７００は、空間に新規デバイスが入ったことを検出した場合に、新規デバイスと通信を行うことによって、ゲートウェイ３００を介した通信で用いられる新規デバイスのアドレス情報を取得し、取得したアドレス情報を空間内に位置するデバイス２００に通知してもよい。例えば入退室管理装置７００は、デバイス２００－３とＢＬＥ通信を行うことによって、デバイス２００－３のデバイスＩＤ及びアドレス情報を既存デバイス情報に追加する処理を行う。なお、デバイスＩＤとアドレス情報は同時に取得されるものに限定されない。例えば入室直後にはデバイス２００－３とゲートウェイ３００の接続が完了しておらず、動的なＩＰアドレスが割り振られていない場合、デバイス２００－３はゲートウェイ３００との接続確立を待ってから、アドレス情報を入退室管理装置７００に送信してもよい。

　入退室管理装置７００はデバイス２００－３の入室に伴う既存デバイス情報の更新後に、当該既存デバイス情報をデバイス２００－１～デバイス２００－３に送信する。これにより、居室内に位置する各デバイス２００は、当該居室内の他のデバイス２００、及びアドレス情報を特定できる。

　なお入退室管理装置７００は、既存デバイス（デバイス２００－１及びデバイス２００－２）と、新しく入室した新規デバイス（デバイス２００－３）とで、送信する情報を切り替えてもよい。例えば入退室管理装置７００は、既存デバイスに対しては、新規デバイスのデバイスＩＤ及びアドレス情報のみを送信し、既存デバイス情報の他のレコードの送信を省略してもよい。また入退室管理装置７００は、新規デバイスに対しては更新前の既存デバイス情報を送信してもよい。このようにすれば、必要性の低い情報の送信を省略できるため、通信負荷の軽減が可能である。

　またいずれかのデバイス２００が退室する場合も同様である。例えば入退室管理装置７００は、ＢＬＥ通信が行えなくなったデバイス２００、あるいは推定された位置が居室外と判定されたデバイス２００は、対象の居室から退室したと判定する。この場合、入退室管理装置７００は、退室したデバイス２００のデバイスＩＤ及びアドレス情報を既存デバイス情報から削除する処理を行う。また入退室管理装置７００は、デバイス２００の退室が発生したことを表す情報を既存デバイスに通知する。例えば入退室管理装置７００は、更新後の既存デバイス情報を各デバイス２００に送信してもよい。また入退室管理装置７００は、退室したデバイス２００のデバイスＩＤ等を各デバイス２００に送信し、各デバイス２００が保持する既存デバイス情報から該当するレコードを削除することを指示してもよい。

　また入退室管理装置７００は、対象空間に位置する既存デバイス情報を記憶するものに限定されず、入退室のログデータを記憶してもよい。ログデータは、例えば入室時刻、退室時刻、デバイスＩＤ等が対応付けられた情報である。

　次にサーバレスでの通信について説明する。例えば、デバイス２００－１がアクティブである動作モードで動作しており、その処理結果として、デバイス２００－２の制御が必要であると判定したとする。例えば、デバイス２００－１は嚥下ムセ検出装置４６０であり、危険なムセが検出されたため、介護ベッド５２０であるデバイス２００－２のボトム角度の変更が必要であると判定する。

　図７や図１８を用いて上述した例では、サーバシステム１００を経由した処理が行われた。ただし図２５の例においては、上述したように、デバイス２００－１は、デバイス２００－２が同じ居室内にあることが分かっており、そのＩＰアドレスも既知である。よってデバイス２００－１は、サーバシステム１００を介さずにデバイス２００－２に制御信号を送信してもよい。具体的には、デバイス２００－１は、デバイス２００－２のＩＰアドレスを指定したパケットを用いて制御信号をゲートウェイ３００に送信する。ゲートウェイ３００は、ＩＰアドレスに基づく判定によって、パケットの送信先が同じネットワーク内の機器であるデバイス２００－２であると判定する。よって制御信号を含むパケットは、図２５に「パケット１」として示したように、サーバシステム１００を介することなくデバイス２００－２に送信される。これにより、サーバシステム１００を介さずに必要なデバイス２００の制御を実行できるため、サーバシステム１００の負荷を軽減することや、制御に要する時間を短縮することが可能になる。

　また、シーン情報やデバイス種類情報は、サーバシステム１００の処理部１１０において求められるものに限定されない。例えばシーン情報として介助者の人数を用いる場合、デバイス２００－１が撮像装置４１０等であれば、撮像画像に対する画像処理に基づいて居室内の介助者数を求めることも可能である。またデバイス種類情報は、あるデバイス２００とともに用いられる他のデバイス２００の種類を表す情報である。よって、デバイス２００－１のデバイス種類ＩＤは、同じ居室内で動作するデバイス２００－２やデバイス２００－３にとってのデバイス種類情報となる可能性がある。

　また本実施形態のデバイス２００において、ＡＤＬ指数等の能力情報が求められることも妨げられない。例えば上述したように、能力情報の算出にはセンシングデータのログを用いることが可能であるため、当該センシングデータを取得するデバイス２００が能力情報を算出してもよい。

　図７や図１８を用いて上述した例では、サーバシステム１００において能力情報、シーン情報、デバイス種類情報が求められ、これらを含むデータがデバイス２００に送信された。ただし図２５の例においては、デバイス２００－１は、デバイス２００－２が同じ居室内にあることが分かっており、そのＩＰアドレスも既知である。よってデバイス２００－１は、サーバシステム１００を介さずにデバイス２００－２に能力情報、シーン情報、デバイス種類情報等を送信する。具体的には、上述した制御信号と同様であり、デバイス２００－１は、デバイス２００－２のＩＰアドレスを指定したパケットを用いることによって、サーバシステム１００を介することなく、能力情報等をデバイス２００－２に送信できる。これにより、サーバシステム１００を介さずに能力情報等に応じた動作モードの設定を行えるため、サーバシステム１００の負荷を軽減することや、制御に要する時間を短縮することが可能になる。例えば、居室内に位置する複数のデバイス２００は、それぞれがデバイス２００自身のデバイス種類情報を他のデバイス２００に通知し合うことによって、併用デバイスを特定する処理を実行してもよい。

　またデバイス２００－１は、制御対象デバイス（例えばデバイス２００－２）に対する制御に関するログデータを、サーバシステム１００に送信してもよい。上述の例であれば、嚥下ムセ検出装置４６０であるデバイス２００－１が、介護ベッド５２０であるデバイス２００－２の背角度をいつ、どの程度変更したかを表すデータ等がログデータとなる。同様に、能力情報等をデバイス２００－２に通知した場合、通知したタイミングや、通知内容である能力情報等の詳細がログデータとなる。これらのログデータをサーバシステム１００に送信することによって、サーバレスでの通信が行われた場合にも、その内容をサーバシステム１００と共有することが可能になる。

　例えばデバイス２００－１は、図２５に示すように、パケット１を用いて制御信号、能力情報、シーン情報、デバイス種類情報等を送信し、パケット２を用いてログデータを送信してもよい。ここでのログデータとは、上述したようにパケット１を用いた通信の履歴を表すデータである。またパケット１は、デバイス２００－１が属するネットワーク内で送受信されるパケットである。パケット２は、デバイス２００－１が属するネットワークを形成するゲートウェイ３００を超えて送信されるパケットである。パケット２は、狭義にはサーバシステム１００のＩＰアドレスを指定するパケットであってもよい。このように送信対象となるデータの内容に合わせてパケットを切り替えることによって、サーバシステム１００の通信負荷を軽減することが可能になる。

　なお、以上ではデバイス２００－１から他のデバイス２００に対してサーバレスでのデータ送信を行う例を示したが、デバイス２００－２等の他のデバイス２００がデータの送信元となってもよい。

　以上のように、本実施形態に係るデバイス２００は、動作結果をサーバシステム１００に送信するか（図７のステップＳ２０３等）、動作結果に基づいて、サーバシステム１００を介さずに、デバイス２００とは異なる制御対象デバイスに、制御対象デバイスを制御する情報を送信するか（図２５のパケット１）、を選択してもよい。このようにすれば、サーバシステム１００主導で処理を行うか、サーバレスでの処理を行うかを柔軟に変更できる。

　具体的にはデバイス２００は、入退室管理装置７００からの情報に基づいて制御対象デバイスのアドレス情報が取得されている場合に、サーバシステム１００を介さずに、制御対象デバイスを制御してもよい。このようにすれば、具体的な通信状況を考慮した上で、サーバレスでの処理を行うか否かを適切に決定することが可能になる。

　なお以上では入退室管理装置７００を用いてサーバレス通信を行う例を説明したが、本実施形態の手法はこれに限定されない。例えばサーバシステム１００は、デバイス２００から送信されるパケットを参照することによって、当該パケットがいずれのゲートウェイ３００を介して送信されたデータであるかを判定してもよい。そしてサーバシステム１００は、同じゲートウェイ３００に接続する複数のデバイス２００が存在する場合に、当該複数のデバイス２００は、近い距離にあると判定してもよい。

　そしてサーバシステム１００は、各デバイス２００に対して、当該デバイス２００からの距離が近いと判定された他のデバイス２００のアドレス情報を送信する。例えば、サーバシステム１００は、同一のゲートウェイ３００に接続される複数のデバイス２００の識別情報及びアドレス情報を対応付けた情報を求め、当該情報を上記複数のデバイス２００に定期的に送信する。このような手法であっても、各デバイス２００は近くにある他のデバイス２００のアドレス情報を特定できるため、サーバレス通信を実現できる。

６．通信の詳細例
６．１　概要
　図１に示した情報処理システム１０のうち、少なくとも１つのデバイス２００と、ゲートウェイ３００との間では、無線通信方式を用いた通信が行われる。ここでの無線通信方式は、例えばＩＥＥＥ８０２．１１に準拠した通信方式であってもよい。またサーバシステム１００は、有線通信方式を用いた通信を行ってもよいし、無線通信方式を用いた通信を行ってもよい。ここでの有線通信方式は、例えばＩＥＥＥ８０２．３に準拠した通信方式であってもよい。以下、説明を簡略化するため、サーバシステム１００、デバイス２００、ゲートウェイ３００のそれぞれがＩＥＥＥ８０２．１１に準拠した通信方式を用いる例について説明する。

　図２６は、サーバシステム１００の通信処理部１１４及び通信部１３０の構成例を示す図である。図２６に示すように、通信処理部１１４は、上位層処理部１１４１、ＭＡＣ層処理部１１４２、物理層処理部１１４３を含む。通信部１３０は、送受信回路１３１と、アンテナアレイ１３２を含む。ただし、通信処理部１１４及び通信部１３０の構成は図２６に限定されず、一部の構成を省略する、他の構成を追加する等の種々の変形実施が可能である。

　上位層処理部１１４１は、ＭＡＣ層よりも上位層における処理を行う。ここでの上位層とは、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）であってもよいし、ＵＤＰ／ＩＰ（User Datagram Protocol/Internet Protocol）であってもよいし、アプリケーション層であってもよい。例えば、上述した能力情報、シーン情報、デバイス種類情報を求める処理は、サーバシステム１００上で動作するソフトウェアによって実行されるものであって、ここでのアプリケーション層とは当該ソフトウェアに対応してもよい。上位層処理部１１４１は、ＭＡＣ層処理部１１４２と接続される。

　ＭＡＣ層処理部１１４２は、ＭＡＣ層における送信処理、受信処理を行う。ＭＡＣ層処理部１１４２は、物理層処理部１１４３と接続される。

　物理層処理部１１４３は、物理層における処理を行う。物理層処理部１１４３は、送受信回路１３１を介してアンテナアレイ１３２と接続される。

　送受信回路１３１は、デジタル／アナログ変換回路（以下、Ｄ／Ａ変換回路と記載）、ＲＦ回路等の回路を含み、物理層処理部１１４３からのデジタル信号をアナログ信号に変換して、アンテナアレイ１３２に出力する。また送受信回路１３１は、アナログ／デジタル変換回路（以下、Ａ／Ｄ変換回路と記載）を含み、アンテナアレイ１３２が受信した信号をデジタル信号に変換し、変換後のデジタル信号を物理層処理部１１４３に出力する。なお、物理層処理部１１４３がＡ／Ｄ変換回路やＤ／Ａ変換回路を有することも妨げられない。

　アンテナアレイ１３２は、送受信回路から出力されたアナログ信号に基づく電波の送信、及び、受信電波に基づくアナログ信号の出力を行う複数のアンテナを含む。

　例えばデータ受信時には、図２６に示す各部は以下のように動作する。まずアンテナアレイ１３２は、所定の周波数帯域における電波を受信し、当該電波に対応するアナログ信号を送受信回路１３１に出力する。送受信回路１３１は、アンテナアレイ１３２が受信したアナログ信号をベースバンド信号に変換する。また送受信回路１３１は、ベースバンド信号のＡ／Ｄ変換を行い、変換後のデジタル信号を物理層処理部１１４３に出力する。

　物理層処理部１１４３は、受信した信号の復調や誤り訂正等の処理を行う。また物理層処理部１１４３は、物理層に対応するヘッダである物理ヘッダを取り除き、ペイロード部分をＭＡＣ層処理部１１４２に出力する。

　ＭＡＣ層処理部１１４２は、受信したペイロード部分をＭＡＣフレームとして処理する。ＭＡＣフレームとは、ＩＥＥＥ８０２．１１におけるＭＰＤＵ（MAC Protocol data unit）であってもよい。ＭＡＣ層処理部１１４２は、ＭＡＣフレームのうち、ＭＡＣ層におけるヘッダであるＭＡＣヘッダ、及びトレイラを除いた部分であるフレームボディを上位層処理部１１４１に受け渡す。

　上位層処理部１１４１は、ＭＡＣ層処理部１１４２から受信したフレームボディに相当するデータを、ソフトウェア等に出力する。

　またデータ送信時には、この逆に相当する処理が実行される。まずサーバシステム１００上で動作するソフトウェアによって、送信対象となるデータが生成され、当該データが上位層処理部１１４１に出力される。

　上位層処理部１１４１は、当該データに対して上位層におけるヘッダ等を付与することによって、フレームボディに相当するデータを作成し、ＭＡＣ層処理部１１４２に出力する。

　ＭＡＣ層処理部１１４２は、受信したデータに対して、ＭＡＣヘッダ及びトレイラを付与することによって、ＭＡＣフレームを作成する。ＭＡＣ層処理部１１４２は、作成したＭＡＣフレームを物理層処理部１１４３に出力する。

　物理層処理部１１４３は、受信したデータに対して、物理ヘッダ等を付与することによって物理パケットを作成する。物理層処理部１１４３は、作成した物理パケットを送受信回路１３１に出力する。

　送受信回路１３１は、物理層処理部１１４３から受信したデータのＡ／Ｄ変換、及び、変調等を行うことによって、アナログ信号を生成する。送受信回路は、当該アナログ信号をアンテナアレイ１３２に出力する。アンテナアレイ１３２は、受信したアナログ信号に対応する電波を送出する。

　ＭＡＣ層処理部１１４２は、上述したＭＡＣフレームとして、データフレーム、制御フレーム、管理フレームを用いてもよい。データフレームとは、端末間での通信リンクが確立している状態において、当該端末間でのデータを送受信する際に用いられるフレームである。例えば上記のように、サーバシステム１００上で動作するソフトウェアが能力情報等を含むデータを作成し、当該データをデバイス２００に送信する場合には、データフレームが用いられる。

　また管理フレームとは、端末間での通信リンクを管理するために用いられるフレームである。なお管理フレームを用いて送受信される情報についてはＩＥＥＥ８０２．１１において種々定義されており、本実施形態でもそれらを広く適用可能である。制御フレームとは、管理フレーム及びデータフレームの送受信制御に用いられるフレームである。制御フレームにはＲＴＳ（Request to Send）フレーム、ＣＴＳ（Clear to Send）フレーム、ＡＣＫ（Acknowledgement）フレーム等、種々のフレームが含まれる。これらのフレームについては、ＩＥＥＥ８０２．１１の規格内において定義されているため詳細な説明は省略する。

　また以上ではサーバシステム１００の通信に関する構成を例示したが、デバイス２００及びゲートウェイ３００についても同様の構成が用いられてもよい。また上述したように、サーバシステム１００は有線通信方式を用いた通信を行ってもよく、その場合、上記の内容の一部をＩＥＥＥ８０２．３に準拠した内容に置き換えること等が可能である。

６．２　フレーム構成
　本実施形態の手法では、ＭＡＣフレーム（データフレーム）の構成は、通信対象であるデバイス２００によらずに共通化されてもよい。図７等を用いて上述したように、本実施形態におけるデバイス２００や、デバイス２００で動作するアプリケーションは、デバイスベンダによって作成されてもよい。そのため、種々のベンダが作成したデバイス２００が情報処理システム１０に登録される場合もある。その点、データフレームの構成を共通化することによって、ベンダによらず通信制御を統一することが可能になる。なおデータフレームの構成とは、狭義にはフレームボディにおけるビット割り付けである。

　図２７は、ＭＡＣフレームのフォーマット例である。なお、図２７に示すフォーマット例は管理フレームや制御フレームにも適用可能であるが、以下ではデータフレームを例に説明を行う。図２７に示すように、ＭＡＣフレームは、ＭＡＣヘッダ、フレームボディ、トレイラを含む。

　ＭＡＣヘッダは、Frame Control, Duration ID, Address 1, Address 2, Address 3, Sequence Control, Address 4, QoS Control, HT Controlの各フィールドを含む。またこれらのうちの一部が省略されてもよい。

　Frame Controlは、対象のＭＡＣフレームがデータフレームか、管理フレームか、制御フレームかの判別するためのタイプフィールドを含む。またFrame Controlはより細かい種別を特定するサブタイプフィールドを含んでもよい。Duration/IDには電波を使用する予定期間を表す情報が格納される。電波を使用する予定時間とは、フレーム送信に必要な時間と言い換えてもよい。Duration/IDはＲＴＳ／ＣＴＳ等に用いられる。

　Address 1～Address 4は、受信先や送信元の機器のアドレスを表す情報を格納する。例えばAddress 1は、受信先アドレスに対応し、Address 2は送信元アドレスに対応する。Address 3, Address 4には、フレーム用途に応じたデータが格納される。

　Sequence Controlは、送信するデータのシーケンス番号に対応する。QoS ControlはＱｏＳ制御に用いられる情報を格納する。ＱｏＳ制御とは、フレームの優先度を考慮して送信を行う制御を表す。HT Controlは例えば管理フレームにおいて用いられるフィールドである。

　フレームボディの構成については、図２８Ａ、図２８Ｂを用いて後述する。またトレイラは例えばＦＣＳ（Frame Check Sequence）である。ＦＣＳは、フレームの誤り検出に用いられる情報であり、例えばチェックサム符号である。ＦＳＣは、例えばＣＲＣ（Cyclic Redundancy Code）である。

　本実施形態に係る情報処理システム１０は、図１を用いて上述したようにサーバシステム１００と、デバイス２００を含む。デバイス２００は、熟練者の暗黙知に対応する処理を実行するアプリケーションを含む。サーバシステム１００は、図２７に示すように、デバイス２００との通信のデータリンク層において、ＭＡＣ（Media Access Control）ヘッダ、フレームボディ、及びトレイラを含むデータフレームを送信する。ここでサーバシステム１００は、被介助者の活動能力を表す能力情報を格納する第１領域、被介助者に対する介助のシーンを特定するシーン情報を格納する第２領域、及び、デバイス２００とともに用いられる併用デバイスの種類を特定するデバイス種類情報を格納する第３領域を含む固定長の領域が、フレームボディに含まれるデータフレームを送信する。そしてデバイス２００は、上述したように、能力情報、シーン情報及びデバイス種類情報の少なくとも１つに基づいて、アプリケーションのアクティブまたは非アクティブを決定する。

　このようにすれば、サーバシステム１００が能力情報等をデバイス２００に送信する際のデータフォーマットを統一することが可能になる。例えば、本実施形態の情報処理システム１０に種々のベンダのデバイス２００が登録される場合であっても、ベンダによらずにデータフレームの構成を統一できる。特に、第１～第３領域を固定長とすることによって、データフレームを受信したデバイス２００における当該データフレームの解釈が容易になるため、通信に関する処理負荷の軽減が可能である。例えば第１～第３領域は、フレームボディのうち、上位層におけるヘッダ等を除いた先頭部分に配置されてもよい。

　なお図７のステップＳ２０３に示したように、デバイス２００は、アプリケーションがアクティブに設定された場合に、アプリケーションの動作結果をサーバシステム１００に送信してもよい。ここでの動作結果とは、アプリケーションの出力であって、暗黙知に対応する処理の実行結果を表す。例えば動作結果とは、介助において発生しうる事象、被介助者、介助者の何れかに関する判断結果を含む。具体的には、動作結果は、介助において何らかの事象が発生したか否かの判断結果であってもよいし、被介助者の状態が正常であるか否かの判断結果であってもよいし、介助者による介助が正解か否かの判断結果であってもよい。このようにすれば、動作結果を表す情報をサーバシステム１００に集約することが可能になる。ただしサーバシステム１００を介した処理は必須ではなく、図２５を用いて上述したようにサーバレスでの処理が実行されてもよい。

　図２８Ａ及び図２８Ｂは、サーバシステム１００が送信するデータフレームのフレームボディのビット割り付け例を説明する図である。図２８Ａに示すように、フレームボディは、User ADL, scene flag, device type ID, data type ID, Instruction length, contentsの各フィールドを含んでもよい。

　User ADLは、被介助者の能力情報を格納するフィールドであり、上述した第１領域に対応する。例えば能力情報は、能力の程度を所定数の段階に区分した場合に、被介助者の能力がいずれの段階に属するかを表す数値データである。例えば段階が８個以下であればUser ADLは３ビットのフィールドである。また段階が９個以上である場合には、User ADLは４ビットかそれ以上のフィールドであってもよい。能力情報の定義に応じて必要なビット数は既知であるため、User ADLは固定長のフィールドであってもよい。User ADLに被介助者を特定するＩＤを含んでもよい。また図１９のステップＳ４０３等においても上述したように、本実施形態の能力情報は、ＡＤＬの指標値に限定されず、立ち上がりの仕方を表す情報、座位保持能力、嚥下能力、歩行能力等のより詳細な情報であってもよい。よってUser ADLは、これらの各能力を表現可能なビット数を有するフィールドであってもよい。

　Scene flagは、シーン情報を格納するフィールドであり、上述した第２領域に対応する。例えばシーン情報は、介助者の数が所定以上であるか否かを表すビットを含んでもよい。当該ビットが第１の値（例えば０）である場合に介助者の数が所定以上であり、第２の値（例えば１）の場合に所定未満であることを表す。またシーン情報は、介助の種類を特定するビットを含んでもよい。例えば介助の種類として、食事介助、排泄介助、移動・移乗介助、その他の４種類を識別する場合、シーン情報は介助の種類を特定するビットとして２ビットを含む。例えば、当該２ビットが００である場合は食事介助を表し、０１である場合は排泄介助を表し、１０である場合は移動・移乗介助を表し、１１である場合はその他を表す。またシーン情報はこれらに限定されず、他の情報が用いられてもよい。そのため、Scene flagの具体的なビット数や意味についても種々の変形実施が可能である。ただし、どのようなシーン情報を用いるかは既知であり、当該シーン情報の表現に必要なビット数も既知であるため、Scene flagは固定長のフィールドであってもよい。

　device type IDは、デバイス種類情報を格納するフィールドであり、上述した第３領域に対応する。デバイス種類情報は、図８～図１４を用いて上述したデバイス２００毎に異なる情報であってもよい。あるいは、転倒リスクに対応するデバイス２００であれば、図８の撮像装置４１０と図９のベッドサイドセンサ４２０に同じデバイス種類ＩＤが割り振られてもよい。あるいはデバイス２００が有するセンサ種類等に基づいてデバイス種類ＩＤが割り振られてもよい。対象とするデバイス種類ＩＤの数は既知であるため、device type IDは固定長のフィールドであってもよい。

　またサーバシステム１００は、デバイス２００での動作結果に基づいて、制御対象デバイスに対する制御の制御種別、及び、制御内容を求めてもよい。そしてサーバシステム１００は、フレームボディのうち、第１領域、第２領域及び第３領域を含む領域よりも後方の部分に、制御種別を格納する固定長の第４領域、及び、制御内容を格納し、制御種別に応じて長さの異なる第５領域が含まれるデータフレームを、制御対象デバイスに送信してもよい。制御種別とは、実行される制御の種類を表し、制御内容とは、実行される制御の内容を具体的に特定する情報を表す。このようにすれば、能力情報等の通知と、制御対象デバイスの制御の両方に共通のデータフレームを用いることが可能になる。この際、固定長のフィールドである第１～第３領域が相対的に前方に配置され、可変長のフィールドである第５領域が相対的に後方に配置されることによって、前方側のデータ構造をビット数まで含めて固定化できる。結果として、デバイス２００でのデータフレームの解釈処理が容易になる。

　例えば図２８Ａに示すdata type ID, Instruction length, contentsは、制御対象デバイスへの制御信号の送信に用いられるフィールドである。data type IDは、制御対象デバイスに対して出力される指示の種類を表す情報を格納するフィールドであり、上記第４領域に対応する。ここでの指示は、「報知（アラーム）」、「移動／搬送」、「制御」、「レコメンド等」の４つを含んでもよい。この場合、data type IDは４つの指示を識別可能な２ビットの固定長のフィールドである。

　「報知」とは、デバイス２００における処理結果を制御対象デバイスで報知する際に用いられる情報である。例えば「報知」は、転倒リスクを判定するデバイスにおいて転倒リスクが検出された場合に、その旨を制御対象デバイスで報知する際に用いられる指示であってもよい。「移動／搬送」とは、リクライニング車椅子５１０や歩行器等、移動可能な制御対象デバイスを移動させる指示である。例えば移動／搬送の指示は、転倒リスクが検出された場合に、対象の被介助者が捕まれるように歩行器等を近くに移動させる制御に用いられてもよい。「制御」とは、制御対象デバイスを動作させる「移動／搬送」以外の制御を広く含み、リクライニング車椅子５１０の背面部の角度変更や、介護ベッド５２０のボトム角度の変更等を含む。「レコメンド等」は、例えば介助の質向上のために用いられる製品の購入等のレコメンドを含む。例えばレコメンドは、ベッドポジション検出装置４７０においてクッションの使用を推奨するという判定が行われた場合に、その旨を介助者の端末装置等である制御対象デバイスに出力する指示を表してもよい。また「レコメンド等」には、ニュース配信等が含まれてもよい。例えば、「レコメンド等」は、人気のデバイス２００の紹介に用いられてもよい。

　contentsは、具体的な指示の内容を特定する情報を格納するフィールドであり、上記第５領域に対応する。図２８Ｂは、data type IDの値に応じたcontentsの具体例を説明する図である。例えばdata type ID = 0は上述した「報知」を表し、この場合のcontentsは、alarm contentsフィールドを含む。alarm contents は具体的な報知内容を表す情報を格納する可変長のフィールドである。alarm contentsは、報知態様（表示、発光、振動、音出力）を特定する情報を含んでもよいし、具体的な報知内容（テキスト、発光色、振動パターン、音声）を特定する情報を含んでもよい。

　data type ID = 1は上述した「移動／搬送」を表し、この場合のcontentsは、current location, destinationの各フィールドを含む。current locationは、対象のデバイス２００の現在位置を特定する情報である。destinationは、対象のデバイス２００の目標位置を特定する情報である。現在位置や目標位置をどのように表現するかは任意であるが、例えば２次元や３次元の座標値を表す固定長のフィールドである。

　data type ID = 2は上述した「制御」を表し、この場合のcontentsは、controlled part, how to controlの各フィールドを含む。controlled partは、対象のデバイス２００の制御対象箇所を特定する情報を格納する。例えば図２４に示した介護ベッド５２０の場合、それぞれが可動する複数のボトムを含む。controlled partは、当該複数のボトムの何れかを特定する情報を格納してもよい。how to controlは、制御対処箇所の具体的な制御手法を特定する情報を格納する。介護ベッド５２０の例であれば、how to control は、controlled partによって特定されたボトムをどの方向に何度だけ駆動するかを表す情報であってもよい。controlled part及びhow to controlは、それぞれが固定長のフィールドであってもよい。なお、ここでの「制御」は複数の制御対象箇所に対する指示を含んでもよい。よってdata type ID = 2の場合のcontentsは、controlled part及びhow to controlの組を、制御対象箇所の数だけ繰り返す構成であってもよい。

　data type ID = 3は上述した「レコメンド等」を表し、この場合のcontentsは、recommend contentsフィールドを含む。recommend contentsは、レコメンドやニュースの内容を表す可変長のフィールドである。ここでのrecommend contentsは、レコメンドする製品を特定する情報を含んでもよいし、製品の販売サイト、メーカの製品紹介Ｗｅｂページ等へのリンク情報を含んでもよい。またrecommend contentsは、ニュースの内容を表すテキストや、ニュースが表示されるＷｅｂページ等へのリンク情報を含んでもよい。

　なお以上のように、フレームボディ中のcontentsフィールドは、data type IDや具体的な指示内容に応じて長さが異なる。よって図２８Ａに示すように、フレームボディはcontentsフィールドの前に、当該contentsフィールドの長さを格納するinstruction lengthフィールドを含んでもよい。contentsフィールドの最大長は既知であると考えられるため、instruction lengthは例えば固定長のフィールドであってもよい。

　また図２５を用いて上述したように、本実施形態ではデバイス２００から他のデバイス２００に対して、サーバシステム１００を介さずに制御信号や能力情報等を含むデータが送信されてもよい。ただし、サーバシステム１００から送信されるデータ（図７のステップＳ３０４等）と、デバイス２００から送信されるデータ（図２５のパケット１）のフォーマットが大きく異なる場合、受信するデバイス２００において送信元に応じたデータの解釈処理が必要となる可能性がある。よってデバイス２００が送信元となる場合にも、図２８Ａ、図２８Ｂに示したフレーム構成に準じたフレーム構成が用いられてもよい。

　例えばデバイス２００は、サーバシステム１００を介さずに、制御対象デバイスを制御する場合、制御対象デバイスとの通信のデータリンク層において、第２領域及び第３領域を含む固定長の領域がフレームボディに含まれるデータフレームを、制御対象デバイスに送信してもよい。上述したように、第２領域はシーン情報に対応し、第３領域はデバイス種類情報に対応する。またデータフレームは、能力情報に対応する第１領域を含むことも妨げられない。このようにすれば、データフレームのフレームボディのうち、少なくとも能力情報、シーン情報、デバイス種類情報に対応する部分を共通化することが可能になる。例えば第１～第３領域は、フレームボディのうち、上位層におけるヘッダ等を除いた先頭部分に配置されてもよい。

　またデバイス２００は、当該デバイス２００でのアプリケーションの動作結果に基づいて、制御対象デバイスに対する制御の制御種別、及び、制御内容を求めてもよい。そしてフレームボディのうち、第２領域及び第３領域を含む領域よりも後方の部分に、第４領域、及び、第５領域を含むデータフレームを、サーバシステム１００を介さずに制御対象デバイスに送信してもよい。上述したように、第４領域は制御種別に対応し、第５領域は制御内容に対応する。このようにすれば、サーバレスでの制御が行われる場合についても、デバイス２００が受信するデータフレームの構成を共通化することが可能になる。

　図２９Ａ、図２９Ｂは、デバイス２００が他のデバイス２００に対して、制御信号や能力情報等を含むデータを送信する際のフレームボディの構成例を示す図である。図２９Ａと図２８Ａを比較すれば分かるように、フレームボディの構成は、device type ID, scene flag, User ADLの順序が異なる点を除いてサーバシステム１００が送信する際のフレームボディの構成と同様である。ここでのdevice type IDフィールドは、例えば送信元のデバイス２００のデバイス種類情報を格納してもよい。また図２９Ｂはdata type IDの値に応じたcontentsの具体例を説明する図である。デバイス２００が送信元となるため、data type ID =3の場合にレコメンド等に代えてログデータが送信される点を除き、contentsの内容も図２８Ｂと同様である。ログデータについては上述したとおりであり、サーバレスでの制御対象デバイスの制御が行われた際の履歴や、能力情報等の通知履歴等の情報を含む。

　このようにすれば、サーバシステム１００が送信元となる場合と、図２５に示したようにデバイス２００が送信元となる場合のいずれであっても、データフレームの構成を類似させることが可能になる。結果として、データフレームを受信したデバイス２００では、送信元によらずに同様の処理に基づいて動作モードの決定や、制御信号に応じた動作が可能になる。そのため、サーバシステム１００を起点とした処理とサーバレスでの処理の両方が行われる場合にも処理負荷増大を抑制できる。

　なお、図２８Ａ及び図２９Ａにおける各フィールドの順序、特に、User ADL, device type ID, scene flagの順序は種々の変形実施が可能である。よってサーバシステム１００が送信するデータフレームの構成と、デバイス２００が送信するデータフレームの構成が同じであることも妨げられない。またサーバシステム１００が送信するデータフレームの構成と、デバイス２００が送信するデータフレームの少なくとも一方において、User ADL, device type ID, scene flagの一部が省略されてもよい。例えば以上では、デバイス２００はセンシングデータを出力し、サーバシステム１００の能力情報取得部１１１が当該センシングデータに基づいて能力情報を算出する例を説明した。この場合、デバイス２００では能力情報が算出されないため、デバイス２００が送信するデータフレームからUser ADLが省略されてもよい。あるいは、デバイス２００が送信するデータフレームにUser ADLフィールドを設けた上で、当該フィールドの値が固定値（例えば全て０）に設定されてもよい。またデバイス２００が能力情報を算出することも妨げられず、この場合、デバイス２００が送信するデータフレームのUser ADLにはＡＤＬの指標値等の情報が格納される。

　また図２９Ａ及び図２９Ｂを用いて上述したデータフレームは、デバイス２００からサーバシステム１００へのデータ送信に用いられてもよい。例えば、デバイス２００は、処理結果として報知が必要であると判定した場合、data type IDの値が１に設定され、且つ、contentsのうちのalarm contentsに報知内容を表す情報が格納されたデータフレームをサーバシステム１００に送信する。これ以外にもデバイス２００は、処理結果に応じてdata type IDの値や、contentsの値を変更することによって、図２９Ａ及び図２９Ｂに示したデータフレームを用いて適切に処理結果をサーバシステム１００に送信できる。またdata type ID = 3の場合にcontentsに格納されるログデータは、サーバレス通信のログに限定されず、センシングデータのログを含んでもよい。即ち、センシングデータのログをサーバシステム１００に送信する際に、図２９Ａ及び図２９Ｂに示したデータフレームが用いられてもよい。

　また本実施形態の手法は、情報処理装置に適用されてもよい。情報処理装置は、例えばサーバシステム１００に対応する。情報処理装置は、熟練者の暗黙知に対応する処理を実行するアプリケーションを含むデバイス２００との通信のデータリンク層において、ＭＡＣ（Media Access Control）ヘッダ、フレームボディ、及びトレイラを含むデータフレームを送信する通信部（図３の通信部１３０に対応）と、通信部を制御する通信処理部（図３の通信処理部１１４に対応）と、を含む。通信部は、被介助者の活動能力を表す能力情報を格納する第１領域、被介助者に対する介助のシーンを特定するシーン情報を格納する第２領域、及び、デバイスとともに用いられる併用デバイスの種類を特定するデバイス種類情報を格納する第３領域を含む固定長の領域が、フレームボディに含まれるデータフレームを、アプリケーションのアクティブまたは非アクティブを決定する情報として、デバイス２００に送信する。このようにすれば、サーバシステム１００が能力情報等をデバイス２００に送信する際のデータフォーマットを、デバイス２００のベンダ等によらず、統一することが可能になる。

　また本実施形態の手法は、熟練者の暗黙知に対応する処理を実行するアプリケーションを含むデバイス２００と、デバイス２００との通信のデータリンク層において、ＭＡＣ（Media Access Control）ヘッダ、フレームボディ、及びトレイラを含むデータフレームを送信するサーバシステム１００とを含む情報処理システム１０における情報処理方法に適用できる。情報処理方法は、被介助者の活動能力を表す能力情報を格納する第１領域、被介助者に対する介助のシーンを特定するシーン情報を格納する第２領域、及び、デバイス２００とともに用いられる併用デバイスの種類を特定するデバイス種類情報を格納する第３領域を含む固定長の領域が、フレームボディに含まれるデータフレームを、サーバシステム１００からデバイス２００に送信するステップと、能力情報、シーン情報及びデバイス種類情報の少なくとも１つに基づいて、アプリケーションのアクティブまたは非アクティブを決定するステップと、を含む。

６．３　優先度
　また種々の通信方式において、通信の優先度を設定する手法が知られている。例えばＩＥＥＥ８０２．１１では、ＩＥＥＥ８０２．１１ｅにおいてＱｏＳを実現する方式が規格化されている。具体的には、ＩＥＥＥ８０２．１１ｅでは優先度の高いフレームを優先して送信するＥＤＣＡ（Enhanced Distributed Channel Access）という方式が用いられる。

　例えばＭＡＣフレームのうちの管理フレームのフレームボディに、ＥＤＣＡにおいて用いられるＥＤＣＡパラメータセットエレメントが含まれてもよい。図３０は、デフォルトのＥＤＣＡパラメータセットエレメントの例を示す図である。ＥＤＣＡでは、パケットを４つのアクセスカテゴリ（以下、ＡＣと記載）に分類する。デフォルトでのアクセスカテゴリは、ＡＣ＿ＶＯ、ＡＣ＿ＶＩ、ＡＣ＿ＢＥ、ＡＣ＿ＢＫの４つである。ＡＣ＿ＶＯはボイスに対応し、ＡＣ＿ＶＩはビデオに対応し、ＡＣ＿ＢＥはベストエフォートに対応し、ＡＣ＿ＢＫはバックグラウンドに対応する。ＡＣ＿ＶＯが最も優先度が高く、ＡＣ＿ＶＩ、ＡＣ＿ＢＥ、ＡＣ＿ＢＫの順に優先度が低くなる。

　また各ＡＣには、CWmin, CWmax, AIFSN等のパラメータが対応付けられる。CWmin及びCWmaxは、送信待ち時間を決めるパラメータであり、コンテンションウィンドウ（Contension Window, 以下ＣＷと記載）の最小値と最大値を表す。送信待ち時間はCWminとCWmaxの間の値に設定される。送信待ち時間が短いほど送信しやすくなるため、優先度が高いほどCWminやCWmaxの値は小さく設定される。

　例えば優先度の低いＡＣ＿ＢＥ及びＡＣ＿ＢＫについて、CWminがaCWminに設定され、CWmaxがaCWmaxに設定される場合に、優先度の高いＡＣ＿ＶＩでは、CWminが(aCWmin+1)/2 - 1に設定され、CWmaxがaCWminに設定されるため上記２つのＡＣに比べてCWmin及びCWmaxの値が小さくなる。また優先度の最も高いＡＣ＿ＶＯでは、CWminがＡＣ＿ＶＩに比べてさらに短い(aCWmin+1)/4 - 1に設定され、CWmaxがＡＣ＿ＶＩに比べてさらに短い(aCWmin+1)/2 - 1に設定される。

　またAIFSN(Arbitration Inter Frame Space Number)はフレームの送信間隔を表すパラメータであり、この値が小さいほどキューの優先度が高くなる。図３０の例では、ＡＣ＿ＶＯ及びＡＣ＿ＶＩのAIFSNが２であり、ＡＣ＿ＢＥのAIFSNが３であり、ＡＣ＿ＢＫのAIFSNが７である。

　またＡＣに対応付けられるパラメータは上記に限定されない。例えば図３０には不図示であるが、各ＡＣにはTXOP(Transmission Opportunity) limitが対応付けられてもよい。TXOPは、チャネルの占有時間を表す。例えば優先度の高いＡＣ＿ＶＩやＡＣ＿ＶＯにおいて、TXOP limitとして０でない値を設定することによって、これらのＡＣに設定されたパケットの送信にチャネルを占有させることが可能になる。

　本実施形態の情報処理システム１０は、多数のデバイス２００を含むことが想定される。そして各デバイス２００は、動作モードに応じた動作を実行し、ゲートウェイ３００を介して処理結果をサーバシステム１００に送信する。ここでの処理結果は、図２９Ｂを用いて上述した「報知」、「移動／搬送」、「制御」、「ログ」等、種々の内容が考えられる。

　本実施形態のデバイス２００には種々のベンダの製品が含まれる可能性があり、優先度の設定がベンダに応じてばらつく可能性もある。例えば、特定のベンダのデバイス２００の通信のみが、他のベンダのデバイス２００の通信に比べて優先されてしまう可能性もある。よって本実施形態では、優先度の設定を行うことによって通信の効率化を図ってもよい。例えば本実施形態の手法では、ＡＣの割り付けを更新する。

　本実施形態のサーバシステム１００は、デバイス種類情報に基づいて優先度を求め、優先度を特定する優先度情報をデバイスに送信してもよい。優先度情報とは、例えばデバイス種類情報と優先度を対応付けた情報であり、より具体的にはデバイス種類毎にＡＣを割り付けた情報である。そしてデバイス２００は、デバイスの種類及び優先度情報に基づいて特定された優先度に応じて、データフレームを送信する。このようにすれば、デバイス種類に応じた優先度を設定できるため、種々のデバイス２００を含む情報処理システム１０における通信を効率化できる。

　さらにサーバシステム１００は、デバイス種類情報及び制御種別に基づいて優先度を求め、優先度を特定する優先度情報をデバイス２００に送信してもよい。優先度情報は、例えばデバイス種類及び制御種別の組毎にＡＣを割り付けた情報である。そしてデバイス２００は、デバイスの種類、送信対象であるデータフレームに含まれる制御種別、及び、優先度情報に基づいて特定された優先度に応じて、データフレームを送信する。このようにすれば、デバイス種類に加えて制御種別を優先度に反映できるため、種々のデバイス２００が種々の情報を送信する場合にも、情報処理システム１０における通信を効率化できる。以下、デバイス種類情報と制御種別の両方を用いる例について具体的に説明する。ただし以下の説明において、デバイス種類情報と制御種別の何れか一方が省略されてもよい。

　図３１は、ＡＣの割り付けを表す表の例である。本実施形態の手法では、デバイス種類及びデータ種類に基づいて、ＡＣが決定されてもよい。ここでのデバイス種類（Device type）は、上述したデバイス種類情報に対応し、例えばデバイス種類ＩＤである。またここでのデータ種類（Data type）とは、例えば図２８Ａ～図２９Ｂを用いて上述したdata type IDに対応する。即ちデータ種類とは、デバイス２００での処理結果に基づいて、「報知」、「移動／搬送」、「制御」、「ログ」のいずれが送信されるかを表す情報であってもよい。

　例えばサーバシステム１００は、当該サーバシステム１００と通信を行うゲートウェイ３００ごとに、デバイス種類、データ種類及びＡＣの関係を求め、求めた情報を各ゲートウェイ３００に送信する処理を行う。例えばサーバシステム１００は、ゲートウェイ３００からの情報に基づいて、当該ゲートウェイ３００に接続するデバイス２００の数、種類、各デバイス２００が送信しうるデータ種類等を特定できる。

　例えばデータ種類の「ログ」とは、上述したようにセンシングデータのログや、サーバレスでの通信を行った場合のログを送信するケースを表すため、通信の優先度は低く、通信量が低下する深夜等に送信されても問題となりにくい。一方で、「報知」、「移動／搬送」、「制御」は、リスクの発生を介助者に知らせるため、あるいは発生したリスクによる影響を抑制するために使用される。そのため、デバイス２００においてリスクが検出されてからデータ送信までの時間は短いことが望ましい。よってサーバシステム１００は、データ種類が「報知」、「移動／搬送」、「制御」の何れかである場合、「ログ」である場合に比べて優先度を高く設定する。またサーバシステム１００は、「報知」、「移動／搬送」、「制御」の中で優先度を異ならせてもよい。

　また嚥下ムセ検出装置４６０による出力は誤嚥リスクの発生に対応するため、速やかに対応しなかった場合の深刻度が大きくなる可能性がある。一方で、ベッドポジション検出装置４７０によって検出される褥瘡リスクは、比較的長い期間での介助を想定した際に重要度が高いものであるため、褥瘡リスクがある旨の報知等が遅れて実行されたとしても深刻度は相対的に小さい。よってサーバシステム１００は、データ種類が同じ「報知」であったとしても、デバイス種類が嚥下ムセ検出装置４６０に対応する種類の場合、ベッドポジション検出装置４７０に対応する種類に比べて優先度を高くしてもよい。その他、サーバシステム１００は、図８～図１４等を用いて上述した種々のデバイスについて、デバイス種類に応じた優先度を設定できる。

　例えばサーバシステム１００は、デバイス種類及びデータ種類に応じた優先度を求め、当該優先度に応じてＡＣを割り当てる。なお、優先度の高いＡＣに割り当てられるパケットの割合が過剰に高くなった場合、衝突が発生しやすくなるためＥＤＣＡを用いる効果が損なわれることが知られている。よってサーバシステム１００は、ゲートウェイ３００毎にデバイス種類及びデータ種類に応じたＡＣ割り当てを変更してもよい。例えば同じデバイス種類、同じデータ種類であっても、第１ゲートウェイでは優先度が相対的に低いＡＣ＿ＶＩが割り当てられ、第２ゲートウェイでは優先度が相対的に高いＡＣ＿ＶＯが割り当てられるといったケースが発生してもよい。例えば第１ゲートウェイによって構成されるネットワークにおいて、嚥下ムセ検出装置４６０等の深刻度の高いリスクを検出するデバイス２００が多い場合、通常のネットワークではＡＣ＿ＶＯに割り当てられるパケットの優先度が、ＡＣ＿ＶＩに引き下げられる場合等が考えられる。

　ゲートウェイ３００及び当該ゲートウェイ３００に接続されるデバイス２００は、サーバシステム１００から送信されたＡＣ割り付けに基づいて、通信を行う。なおここでの通信は、デバイス２００からゲートウェイ３００へのデータ送信に限定されず、ゲートウェイ３００からデバイス２００へのデータ送信も含む。

　またサーバシステム１００は、デバイス種類とデータ種類に基づいてＡＣの割り付けを決定する処理に加えて、各ＡＣに対応するパラメータを調整する処理を行ってもよい。ここでのパラメータは、上述したCWmin, CWmax, AIFSN, TXOP limitの少なくとも１つを含む。このようにすれば、優先度の設定においてより細かい調整を行うことが可能になる。

　また本実施形態における優先度の設定処理は、上述したＥＤＣＡを用いたものに限定されない。例えば、無線通信における衝突回避の手法としてＲＴＳ／ＣＴＳが用いられる。これはデータ送信を行いたいＳＴＡが、ＡＰに対してＲＴＳフレームを送信し、ＡＰはＲＴＳフレームを送信したＳＴＡのうち、送信を許可するいずれか１つのＳＴＡにＣＴＳフレームを送信するものである。データ送信はＣＴＳフレームを受信したＳＴＡのみが可能となるため、データ衝突を抑制できる。

　本実施形態の手法では、サーバシステム１００は、ＣＴＳフレームを送信する際の優先順位を表す情報を、優先度情報としてゲートウェイ３００に送信してもよい。例えばサーバシステム１００は、対象の被介助者のＡＤＬが低い順や、データ種類に基づくデータの緊急性の高い順、あるいはこれらの組み合わせ等、ＣＴＳフレームの送信順を決定するための情報をゲートウェイ３００に送信する。ゲートウェイ３００は、ＲＴＳ／ＣＴＳに基づいて衝突回避を行う場合、ＲＴＳフレームを送信したデバイス２００のリストと、サーバシステム１００からの情報に基づいて優先順位を決定し、優先順位の高い方から順にＣＴＳフレームを送信する。このような手法によっても、適切な優先度設定が可能になるため、例えば特定のベンダのみの優先度が高くなること等を抑制できる。

　またゲートウェイ３００は、ＲＴＳフレームを受信した場合に、ビジー状態であることと、現在行っている通信の完了見込み時間をデバイス２００に提示する処理を行ってもよい。その上で、デバイス２００から送信待ちを許容できない旨のデータが送信された場合に、suspend commandによって割り込みを受け付け、対象のデバイス２００のデータ送信を許可してもよい。当該データ送信が終了した場合に、resume commandによって元のデータ送信が再開される。このようにすれば、特に緊急性が高いデータについては他のデータ送信を中断した上で優先的に通信を行うことが可能になる。ただしこの処理は既に開始されているデータ送信を中断するものであるため、頻繁に行われることや、中断時間が過剰に長くなることは好ましくない。よってsuspend commandによる割り込みを許容するデータは一部のデータに限定されてもよい。例えば、送信データ量が少なく、送信に要する時間が短いという条件が満たされる場合に、割り込みが許可されてもよい。

７．在宅介護への応用
　また本実施形態の手法は、被介助者の家庭において行われる在宅介護等に適用されてもよい。

７．１　家庭で用いられるシステムの例
　図３２は、在宅における情報処理システム１０の構成例を示す図である。図３２の情報処理システム１０は、サーバシステム１００、第３端末装置８１０、第４端末装置８２０、人感センサ８３１～８３３を含む。例えば情報処理システム１０のうち、第３端末装置８１０、第４端末装置８２０、人感センサ８３１～８３３が、在宅介護が行われる家庭内に配置される。また在宅介護では、ベッド６１０や、不図示の車椅子６３０等が用いられてもよい。

　第３端末装置８１０は、例えば被介助者の介助を行う家族によって用いられるスマートフォンやタブレット端末装置の携帯端末装置である。第４端末装置８２０は、例えば被介助者によって用いられるスマートフォンやタブレット端末装置の携帯端末装置である。

　人感センサ８３１～８３３は、家庭内の所定位置に配置されるセンサであり、例えば赤外線を用いて人の動きを検出するセンサである。なお人感センサ８３１～８３３は、音に反応する音感センサや、超音波を使って物を感知する超音波センサであってもよく、具体的な態様は種々の変形実施が可能である。人感センサ８３１～８３３は、例えばＢＬＥを用いて第３端末装置８１０と接続される。

　ベッド６１０は、被介助者によって使用されるベッドであり、ボトム角度や高さ等を調整可能な介護ベッド５２０であってもよい。

　例えば本実施形態に係るデバイス２００の一例である介助記録デバイスは、図３２における第３端末装置８１０、人感センサ８３１～８３３を含んでもよい。介助記録デバイスは、人感センサ８３１～８３３の検出結果に基づいて、介助が実行された場所を特定し、特定された場所に基づいて介助記録を作成する。

　例えば人感センサ８３１～８３３は、それぞれ特定の介助が実行される場所に配置されてもよい。例えば人感センサ８３１は、被介助者が使用するベッド６１０の近傍に配置される。人感センサ８３２は、トイレの近傍に配置される。人感センサ８３３は、食事を行うダイニングテーブルの近傍に配置される。また人感センサは、入浴介助が行われる浴室等、家庭内の他の場所に配置されてもよい。

　例えば人感センサ８３１によって人の動きが検出された場合、介助者は被介助者のベッドポジション調整やオムツ交換等の介助を行っていると考えられる。また人感センサ８３２によって人の動きが検出された場合、介助者はトイレでの排泄介助等を行っていると考えられる。また人感センサ８３３によって人の動きが検出された場合、介助者は被介助者の食事介助を行っていると考えられる。よってそれぞれにおいて動きが検出された時間を求めることによって、介助時間を求めることが可能である。例えば、１日のうち、人感センサ８３１で動きが検出された合計時間を求めることで、当該１日で行われたベッド６１０での介助時間が求められる。同様に、人感センサ８３２、８３３によって、トイレでの排泄介助の時間、食事介助の時間が求められる。また何時から何時までにどの場所で介助が行われたか等、より詳細な情報が求められてもよい。

　なお、人感センサ８３１～８３３が人の動きを検出したとしても、それが介助者単体または被介助者単体の動きである場合、介助は実行されていない可能性がある。本実施形態では、簡易的な判定を行うという観点から、検出された動きが一人のものであるか複数人のものであるかを区別せず、単純に動き検出の有無に基づく判定が実行されてもよい。あるいは、異なる手法により、介助の有無がより詳細に判定されてもよい。例えば、人感センサ８３１～８３３に変えて、各場所にＲＦＩＤリーダが設けられてもよい。そして介助者及び被介助者がＩＣタグを携帯する、または、第３端末装置８１０及び第４端末装置８２０にＩＣタグを内蔵することによって、各ＲＦＩＤリーダの近傍に介助者及び被介助者がいるかを判定できる。介助記録デバイスは、所定の場所に介助者と被介助者の両方が存在すると判定された場合に、介助が行われていると判定してもよい。また人感センサ８３１～８３３にかえて家庭内の各場所にカメラが配置されてもよい。例えば各カメラの撮像画像に基づく顔認識処理が行われることによって、各場所で介助が実行されているか否かが判定されてもよい。

　また食事がベッドで行われる場合、食事介助が行われることになるが、人の動き、有無だけでは、食事介助とベッドポジション調整等の他の介助との区別が容易でない可能性がある。この場合、介助記録デバイスは、後述する食事量計測アプリと連動してもよい。例えば食事量計測アプリでは写真が撮影されるため、写真が撮影されたタイミングを含む時間の介助は食事介助と判定され、それ以外の時間は食事以外のベッド介助と判定される。

　介助記録デバイスを用いることによって、介助者が介助に要している時間を容易に測定できる。よって例えば介助者の介助負担が過剰になっている場合に、それを介助者自身やケアマネージャに通知すること等が可能になる。

　また第３端末装置８１０には、他のアプリケーションがインストールされてもよい。例えば、スマートフォンに搭載される加速度センサやマイクを用いて、ユーザの睡眠状態を判定するアプリケーションが知られている。例えば第３端末装置８１０はユーザが就寝するベッドの枕元等に配置され、就寝中の振動に基づいて睡眠状態を判定する。また第３端末装置８１０は、マイクを用いていびき等に関する判定を行ってもよい。このようにすれば、検出装置４３０等の専用の機器を用いずに、容易に睡眠に関する判定を行うことが可能になる。

　また第３端末装置８１０には、上述したＭＣＩ判定を行うＭＣＩ判定アプリがインストールされてもよい。換言すれば、第３端末装置８１０は、ＭＣＩ判定デバイスとして機能してもよい。例えば介助者は自身のスマートフォンである第３端末装置８１０を被介助者の近傍まで携帯し、被介助者に受け答えを行わせることによってＭＡＣ判定を行う。

　また第３端末装置８１０には食事量計測アプリがインストールされてもよい。食事量計測アプリとは、例えば食前の料理の写真と、食後の料理の写真とを比較することによって、食事量や摂取カロリーを推定する手法である。写真に基づいて食事量を推定する手法については、特開２０２１－０８６３１３号公報等に開示された公知の手法等を広く適用可能である。

　図３３～図３５は、第３端末装置８１０の表示部に表示される画面の例である。これらの画面は、例えば第３端末装置８１０において、介助者のアカウントを用いて本実施形態の情報処理システム１０にログインする操作が行われた場合に表示されるユーザ画面であってもよい。ユーザ画面には、第３端末装置８１０において実行される上記の各処理を実行した結果が表示されてもよい。例えば第３端末装置８１０は、上記の各処理を実行し、実行結果をサーバシステム１００に送信する。サーバシステム１００は、実行結果に基づいて表示画面を生成し、当該表示画面を第３端末装置８１０の表示部に表示する制御を実行する。

　図３３は、例えばログイン時に表示されるホーム画面の例である。図３３に示すように、ホーム画面には、介助者の状態を示す情報、お知らせ、連絡ボタン、撮影ボタンが表示されてもよい。

　介助者の状態を示す情報とは、例えば介助者の睡眠状態を示すアイコンと、介助者のケア負担を示すアイコンを含んでもよい。図３３の例では、睡眠状態やケア負担の程度が人の表情を用いてわかりやすく提示される。ただし、各情報は数値等を用いて表現されてもよく、具体的な表示態様は種々の変形実施が可能である。

　例えば第３端末装置８１０は、上述した人感センサ８３１～８３３等を用いた処理に基づいて介助が行われた時間である介助時間を求め、当該介助時間と閾値とを比較することによって、ケア負担が複数の段階のいずれに属するかを判定してもよい。また第３端末装置８１０は、介助時間の時系列的な変化に基づいて、ケア負担を評価してもよい。

　また第３端末装置８１０は、上述した加速度センサやマイクを用いて睡眠状態を判定する。例えば第３端末装置８１０は、睡眠状態として１日あたりの睡眠時間を求めてもよい。第３端末装置８１０は、睡眠時間と閾値とを比較することによって、睡眠状態が複数の段階のいずれに属するかを判定してもよい。また第３端末装置８１０は、睡眠時間の時系列的な変化に基づいて、睡眠状態を評価してもよい。

　また図３３の画面のお知らせの欄には、例えば介助用具のレコメンドが表示されてもよい。図３３の例であれば、ベッドポジションの調整に利用されるポジショニングピローの使用を提案するテキストが表示されている。

　また連絡ボタンとは、例えばケアマネージャへの電話を行うためのボタンである。例えば連絡ボタンの選択操作が行われた場合、第３端末装置８１０は電話アプリケーションを起動し、予め登録されたケアマネージャの電話番号宛に発信を行う処理を実行する。このように、ケアマネージャと連絡を取りやすい態様とすることによって、介助者の負担が増大している場合に、適切な対応を促すことが可能になる。例えば図３３の上部に示したように、睡眠状態やケア負担が悪化している場合「担当ケアマネージャか親族に電話してください」といった警告のテキストを表示してもよい。このようにすれば、介助者が介助疲れにより深刻な不調をきたす前に、他者のサポートを受けることを促せる。

　撮影ボタンは、上述した食事量計測アプリを起動するトリガーとなるボタンである。例えば撮影ボタンの選択操作が行われた場合、第３端末装置８１０は食事量計測アプリを立ち上げる処理を行う。食事量計測アプリではカメラアプリが起動され、食前及び食後の料理の撮影が行われる。

　図３４は、図３３の介助者の状態を示す情報に対応付けて表示される履歴ボタンの選択操作が行われた場合に表示される履歴画面の例である。履歴画面には、介助者の睡眠状態の時系列変化、及び、介助者のケア負担の時系列変化が表示される。例えばサーバシステム１００の処理部１１０は、第３端末装置８１０からの情報に基づいて、１日あたりの睡眠時間の７日間での移動平均を求め、当該移動平均の時系列変化を履歴画面に表示する処理を行う。なお移動平均の算出単位は７日間に限定されず、他の期間であってもよい。また１日あたりの睡眠時間そのものの時系列変化が表示されてもよい。

　またケア負担の時系列変化とは、例えば１日あたりの介助時間の平均値の変化を示す情報である。睡眠状態の例と同様に、介助時間の平均値とは７日間での移動平均であってもよいし、他の期間を用いて算出される情報であってもよい。また１日あたりの介助時間そのものの時系列変化が表示されてもよい。

　図３４の例では、睡眠時間が時間経過とともに減少し、且つ、介助時間が時間経過とともに増加している。図３４に示す画面を表示することによって、介助者の状態が悪化していることをわかりやすく提示できる。また図３４に示すように、履歴画面は介助者の状態に関する情報を共有するための共有ボタンを含んでもよい。共有ボタンの選択操作が行われた場合、平均睡眠時間の時系列変化や平均介助時間の時系列変化等を含む情報が、予め登録された連絡先に送信される。ここでの連絡先は、ケアマネージャであってもよいし、介助者の家族等であってもよい。また介助者の状態に関する情報の共有先は、予め登録された連絡先に限定されない。例えば共有ボタンを選択する操作が行われた場合に、介助者の状態に関する情報へのリンク情報が表示されてもよい。ここでのリンク情報は、例えば介助者の状態に関する情報が表示されるＷｅｂページのアドレス情報であってもよい。アドレス情報は、ＵＲＬ（Uniform Resource Locator）であってもよいし、当該ＵＲＬを表す二次元バーコードであってもよい。例えば、介助者が体調不良によって病院で診察を受ける際に、リンク情報を介して医師に介助者の状態に関する情報を共有することによって、体調不良の原因を診断する上での判断材料を医師に提供することが可能である。

　図３５は、図３３の「お知らせ」に対応付けて表示される一覧ボタンの選択操作が行われた場合に表示される一覧画面の例である。一覧画面には、対象の介助者に対して送信されたレコメンド等の情報が時系列順に一覧表示される。図３５の例では、ポジショニングピローのレコメンド、及び、リクライニング車椅子のレコメンドが表示される。各レコメンドは、その商品がレコメンドされる理由、商品画像、商品の詳細情報を含む。商品の詳細情報は、商品名、メーカ、価格、評価、商品説明等を含んでもよい。

　またレコメンドでは、商品とともに利用可能なベンダアプリや本実施形態に係るデバイス２００が提示されてもよい。図３５の例では、ポジショニングピローとともに、ポジショニングアプリの導入を提案している。ポジショニングアプリとは、例えば図１３を用いて上述したベッドポジション検出装置４７０の第１端末装置４７１と同様の処理を実行するアプリケーションである。ポジショニングアプリを導入することによって、介助者によるベッドポジション調整を支援することが可能になる。同様に、第３端末装置８１０には、オムツ交換支援アプリがインストールされてもよい。例えば第３端末装置８１０は、例えば図１３を用いて上述したベッドポジション検出装置４７０の第２端末装置４７２と同様の処理を実行してもよい。

　また図３５に示す例では、リクライニング車椅子５１０とともに、座面センサ４４０の導入が提案されている。座面センサ４４０を導入することによって、介助者に対して前ずれ横ずれ判定の結果、転落可能性の判定結果を提示できるため、リクライニング車椅子５１０でのポジション調整を支援することが可能になる。

　また第３端末装置８１０において実行される処理は上記に限定されない。例えば、食事量計測アプリに基づいて食事のタイミングが推定でき、また、介助記録デバイスでの処理に基づいて、排泄介助が行われたタイミングを推定できる。よって、第３端末装置８１０は、食事と排泄のリズムに基づいて便漏れを予測する処理を行ってもよい。例えば第３端末装置８１０は、下剤の種類・量、おむつの種類、食事量、水分摂取量、食事や水分の摂取タイミングを入力データとし、所定時間後の便漏れの有無を判定する学習済モデル等に基づいて、便漏れを予測してもよい。またレコメンドとして、オムツの種類等をレコメンドしてもよい。

　また介助者が使用する第４端末装置８２０においても、種々の処理が実行される。例えば、第４端末装置８２０はＧＰＳセンサを有し、当該ＧＰＳセンサを用いた見守りアプリケーションがインストールされてもよい。従来、徘徊抑制等を目的に高齢者や認知症患者の位置を追跡する手法が知られており、本実施形態ではそれらを広く適用可能である。

　また第４端末装置８２０は、第３端末装置８１０と同様に睡眠状態を判定するアプリケーションがインストールされてもよい。第４端末装置８２０は、被介助者の睡眠状態を判定する。また第４端末装置８２０には、第３端末装置８１０と同様に、上述したＭＣＩ判定を行うＭＣＩ判定アプリがインストールされてもよい。

７．２　介護施設等との連携
　また以上では在宅介護で用いられる情報処理システム１０を例示したが、当該システムは、家庭外のシステムと連携してもよい。例えば在宅介護で取得された情報はケアマネージャの使用するＰＣ等の端末装置に送信されてもよい。例えば第３端末装置８１０や第４端末装置８２０での処理結果はサーバシステム１００に送信され、サーバシステム１００は、取得した処理結果に基づく情報をケアマネージャの端末装置に送信する。

　図３６Ａ～図３６Ｃは、ケアマネージャの端末装置に表示される画面例である。図３６Ａはホーム画面の例であり、上部に施設内及び施設外の２つのタブを有する。施設内タブは、ケアマネージャが担当する被介助者のうち、介護施設等に入居する被介助者に関する情報を表示するためのタブである。例えば施設内タブが選択された場合、別途対象の施設が導入している介護ソフトを起動する処理が行われてもよい。施設外タブとは、在宅介護を行っている被介助者、及び、当該被介助者を介助する介助者に関する情報を表示するためのタブである。図３６Ａでは、施設外タブが選択された状態の画面を例示している。

　図３６Ａに示す画面は、ユーザを一覧表示する領域と、当該領域で選択されたユーザの詳細情報を表示する領域を含む。ここでのユーザは、在宅介護を実行する被介助者の家族を表す。図３６ＡではユーザＡ～ユーザＤの４名がリスト表示されており、そのうちのユーザＡが選択状態となっている。なおここで表示される複数のユーザは、ケアマネージャにとっての重要度が高い順にソートされてもよい。例えば、介助者であるユーザの睡眠状態の悪化度合い、ケア負担の悪化度合いが大きい順にソートされる。このようにすれば、ケアマネージャが多数のユーザを担当する場合であっても、どのユーザがケアマネージャにとって注意すべきユーザであるかをわかりやすく提示できる。なおソート順はこれに限定されず、新しく連絡があったユーザを上位にしてもよいし、新たなデバイス２００を導入したユーザを上位にしてもよく、具体的な処理は種々の変形実施が可能である。

　詳細情報を表示する領域には、介助者であるユーザの睡眠状態、ケア負担、被介助者の睡眠状態が表示される。これらの情報は、例えば図３４と同様に、平均値の時系列変化を表すグラフや、段階を示すアイコン等を含んでもよい。

　またユーザＡの睡眠状態及びケア負担と対応付けて、ユーザとの連絡ボタンが表示されてもよい。図３６Ａでは、ユーザに電話する電話ボタン、及び、ユーザにメールを送信するメールボタンが表示される。電話ボタンの選択操作が行われた場合、通話アプリが起動され、予め登録されたユーザの電話番号への発信が行われる。メールボタンの選択操作が行われた場合、メールアプリが起動され、ユーザのメールアドレスが記入済のメール作成画面が表示される。またケアマネージャがユーザと連絡を取る手法は電話やメールに限定されず、チャットアプリ等が用いられてもよい。例えば図３６Ａの画面には、ケアマネージャとユーザの間でのトーク履歴が表示されてもよい。

　また図３６Ａに示すように、詳細情報を表示する領域は、データ出力ボタンを表示してもよい。データ出力ボタンの選択操作が行われた場合、ユーザの睡眠状態、ケア負担等に関するデータが出力される。ここでのデータは、csvファイルであってもよいし、他の形式のデータであってもよい。

　また被介助者の睡眠状態と対応付けて変換ボタンが表示されてもよい。図３６Ｂは、変換ボタンの選択操作が行われた場合に、表示される情報の例である。例えば変換ボタンが選択された場合、図３６Ａに示した平均睡眠時間の変化グラフに変えて、図３６Ｂに示す情報が表示されてもよい。図３６Ｂは、被介助者の一日あたりの覚醒状態、睡眠状態、離床状態の変化を、所定日数分まとめて表示する画面である。図３６Ｂに示す画面を表示することによって、平均睡眠時間だけでなく、睡眠に関するより詳細な情報を提示できる。例えば中途覚醒の有無や回数等、睡眠の質に関する情報をケアマネージャに提示することが可能である。

　例えば図３６Ｂに示す画面は、検出装置４３０のセンシングデータの表示に用いられる画面と同様であってもよい。このようにすれば、検出装置４３０を導入していない場合であっても、検出装置４３０を導入した場合と同様の表示を行うことが可能になる。

　また図３６Ａに示すように、詳細情報を表示する領域は、被介助者の能力情報に関する情報を含んでもよい。図３６Ａの例では、食事量、トイレ介助の時間、風呂介助の時間、在床時間のそれぞれの変化に基づいて、ＡＤＬ変化の推定結果が表示されている。例えば図３６Ａに示すように、食事量の減少や、各場所での介助時間の増大に基づいて、座位保持能力が低下している旨が表示されてもよい。このようにすれば、在宅介護を行う場合にも、能力情報の変化を推定することや、当該変化をケアマネージャや介助者に通知することが可能になる。

　なお、介護施設等においては、図８～図１４等を用いて上述した種々のデバイス２００を導入することが比較的容易であり、センシングデータとして種々のデータを取得できる。例えばセンシングデータとして、動き出し動作の内容、座位保持能力、嚥下能力、ベッドでの活動量等を求めるためのデータを取得できるため、能力情報の推定精度を高くすることが可能である。一方、在宅介護では介護施設と同等のデバイス２００を導入することは容易でない。そのため、取得できる情報は、上述したように食事量や介助時間等の限られた情報となる。

　よって本実施形態では、介護施設において取得される情報と、在宅介護で取得される情報を対応付けることによって、在宅介護における能力情報の推定精度を高くしてもよい。例えば普段は在宅介護を行っているが、定期的にデイケアを利用する被介助者が対象であるとする。デイケア時に介護施設のデバイス２００を用いて推定された能力情報の値は、当該タイミングにおける能力情報として信頼度が高い。また能力情報は疾病の発症や事故等の要因がなければ短時間で急激に変化するとは考えにくいため、デイケアの前後所定期間における能力情報は、デイケア時の能力情報と同等と考えられる。例えばデイケアの前後所定期間の在宅介護で取得された食事量や介助時間を入力データとし、当該入力データに対してデイケア時に推定された能力情報が正確データとして付与されたデータを訓練データとする機械学習が行われてもよい。このようにすれば、在宅介護時に取得可能な情報に基づいて、精度よく能力情報を推定することが可能になる。

　また在宅介護とデイケアとで重複する内容に基づいて、能力情報が推定されてもよい。例えば介護施設には図８～図１４を用いて上述した各デバイス２００が導入されており、サーバシステム１００の能力情報取得部１１１は、各デバイス２００からのセンシングデータに基づいて能力情報を求めるとする。例えば、サーバシステム１００は、各デバイス２００から取得されるセンシングデータ群と、能力情報とを対応付けたデータを１レコードとするテーブルデータを記憶してもよい。

　また在宅介護においては、図８～図１４の全てのデバイス２００を導入することは容易でないかもしれないが、一部のデバイス２００が導入される可能性はある。例えば、検出装置４３０が家庭にも導入され、被介助者の睡眠や活動量等に対応するセンシングデータが求められている。この場合、サーバシステム１００は、在宅介護で取得されたセンシングデータと、上記テーブルデータに含まれるセンシングデータ群とを比較することによって、上記テーブルデータから類似度の高いレコードを抽出する処理を行ってもよい。例えばセンシングデータ群の中には検出装置４３０のセンシングデータも含まれるため、当該センシングデータと在宅介護で取得されたセンシングデータの比較処理に基づいて類似度が算出される。そしてサーバシステム１００は、類似度の高いレコードに含まれる能力情報を、在宅介護を受ける被介助者の能力情報として出力する。このようにしても、在宅介護時に取得可能な情報に基づいて、精度よく能力情報を推定することが可能になる。

　図３６Ａに戻って説明を続ける。図３６Ａに示すホーム画面は、対象のユーザに対して提示された「お知らせ」に対する当該ユーザの反応に関する情報を表示してもよい。ここでのお知らせとは、例えば図３５に示した情報である。

　例えば図３６Ａに示す画面には、ユーザに対してレコメンドされたデバイス２００について、当該ユーザが購入したか否かが表示される。図３６Ａの例では、ポジショニングピロー、及び付随してレコメンドされたポジショニングアプリについて、ユーザに購入の意思がある。例えば図３６Ａに示したメーカ発注ボタンの選択操作が行われることによって、ユーザに変わってケアマネージャがポジショニングピローの発注処理を行ってもよい。

　なお、上述したように、１つのデバイス２００には種々のアプリケーション（ベンダアプリ）をインストール可能であるが、ユーザは介助の専門家ではないため、いずれのアプリケーションが被介助者の介助に適しているかを判定することが容易でない可能性もある。よって図３６Ａに示すように、介助に関する知識を有するケアマネージャが、インストールするアプリケーションを決定してもよい。アプリケーションの決定とは、上述してきたように使用する暗黙知を決定することに対応する。図３６Ａの例では、いくつかの候補の中から、右腕に麻痺を有する被介助者を対象として褥瘡リスクを抑制する際に適した暗黙知が選択されている。また、暗黙知は介護施設毎に作成されてもよく、ケアマネージャは、図３６Ａに示した画面において、暗黙知を作成した施設を選択可能であってもよい。例えば、選択されたアプリケーションが購入対象のデバイス２００にインストールされる場合、メーカ発注ボタンの選択操作に基づいて、対象のアプリケーションがプリインストールされた状態で商品が発送されてもよい。

　また購入するデバイス２００（例えばポジショニングピロー）と、アプリケーションがインストールされるデバイス２００（例えば第３端末装置８１０）とが異なる場合も考えられる。この場合、メーカ発注ボタンの選択操作等をトリガーとして、ユーザ及びアプリケーションを特定する情報がサーバシステム１００に送信されてもよい。サーバシステム１００は、対象ユーザの使用するデバイス２００に対して、指定されたアプリケーションを送信する処理を実行する。このようにすれば、ユーザ本人が手続きを行わなくとも、デバイス２００に適切なアプリケーションをインストールできる。なお、ここではデバイス購入時のアプリケーション選択について例示したが、使用途中でのアプリケーション変更等に図３６Ａの画面が用いられてもよい。例えば、ケアマネージャの閲覧する画面には対象ユーザが使用中のデバイス２００やアプリケーションが表示されており、被介助者等の状況に合わせて、ケアマネージャが使用するアプリケーションを変更する。例えば図３６Ａの例のように、プルダウンメニューから使用するアプリケーション（暗黙知）を選択してもよい。この場合も同様に、例えばサーバシステム１００を介して、アプリケーションのアンインストールやインストールが実行される。

　図３６Ｃは、図３６Ａの画面に追加表示される情報の例である。図３６Ｃに示すように、ケアマネージャの端末装置に表示される画面には、対象のユーザが使用しているデバイス２００やアプリケーションが表示されてもよい。図３６Ｃの例では、ユーザは嚥下ムセ検出装置４６０を導入しており、嚥下ムセアプリとして通常の機能を使用中である。通常の機能とは、嚥下及びムセの検出、及び嚥下時間の測定を行う機能である。これに対して、ケアマネージャは追加機能のインストールを実行可能であってもよい。例えば、図３６Ｃに示すように、危険度の高いムセの有無を検出する機能を追加してもよい。このようにすれば、ケアマネージャがオプション機能の追加を行うことが可能になる。

　上述したように、本実施形態の手法では能力情報等に基づいて、各デバイス２００の動作モードを切り替え可能であり、具体的には各アプリケーションのアクティブ／非アクティブを変更できる。よって在宅介護においても、アクティブ／非アクティブの判定は自動で行われてもよい。例えばサーバシステム１００は、在宅介護で取得されるセンシングデータから能力情報を推定し、当該能力情報に基づいてデバイス２００の動作モードを決定してもよい。ただしこれに限定されず、図３６Ｃ等の画面において、アプリケーションのアクティベート操作が可能であってもよい。このようにすれば、状況に応じた動作モード変更を、ケアマネージャが手動で行うことが可能になる。結果として、センシングデータの種類が少ない在宅介護においても、状況に合わせて動作モードを適切に変更することがかのうになる。

　なお、上記のように本実施形態について詳細に説明したが、本実施形態の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本開示の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語と共に記載された用語は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。また本実施形態及び変形例の全ての組み合わせも、本開示の範囲に含まれる。またサーバシステム、デバイス、情報処理システム等の構成及び動作等も、本実施形態で説明したものに限定されず、種々の変形実施が可能である。

Claims

　熟練者の暗黙知に対応する処理を実行するアプリケーションを含むデバイスと、
　前記デバイスとの通信のデータリンク層において、ＭＡＣ（Media Access Control）ヘッダ、フレームボディ、及びトレイラを含むデータフレームを送信するサーバシステムと、
　を含み、
　前記サーバシステムは、
　被介助者の活動能力を表す能力情報を格納する第１領域、前記被介助者に対する介助のシーンを特定するシーン情報を格納する第２領域、及び、前記デバイスとともに用いられる併用デバイスの種類を特定するデバイス種類情報を格納する第３領域を含む固定長の領域が、前記フレームボディに含まれる前記データフレームを送信し、
　前記デバイスは、
　前記能力情報、前記シーン情報及び前記デバイス種類情報の少なくとも１つに基づいて、前記アプリケーションのアクティブまたは非アクティブを決定する情報処理システム。
　請求項１において、
　前記デバイスは、
　前記アプリケーションがアクティブに設定された場合に、前記アプリケーションの動作結果を前記サーバシステムに送信する情報処理システム。
　請求項２において、
　前記サーバシステムは、
　前記動作結果に基づいて、制御対象デバイスに対する制御の制御種別、及び、制御内容を求め、
　前記フレームボディのうち、前記第１領域、前記第２領域及び前記第３領域を含む領域よりも後方の部分に、前記制御種別を格納する固定長の第４領域、及び、前記制御内容を格納し、前記制御種別に応じて長さの異なる第５領域が含まれる前記データフレームを、前記制御対象デバイスに送信する情報処理システム。
　請求項３において、
　前記デバイスは、
　前記動作結果を前記サーバシステムに送信するか、
　前記動作結果に基づいて、前記サーバシステムを介さずに、前記制御対象デバイスに、前記制御対象デバイスを制御する情報を送信するか、
　を選択する情報処理システム。
　請求項４において、
　前記デバイスは、
　前記サーバシステムを介さずに、前記制御対象デバイスを制御する場合、前記制御対象デバイスとの通信の前記データリンク層において、前記第２領域及び前記第３領域を含む固定長の領域が前記フレームボディに含まれる前記データフレームを、前記制御対象デバイスに送信する情報処理システム。
　請求項５において、
　前記デバイスは、
　前記動作結果に基づいて、前記制御対象デバイスに対する制御の前記制御種別、及び、前記制御内容を求め、
　前記フレームボディのうち、前記第２領域及び前記第３領域を含む領域よりも後方の部分に、前記第４領域、及び、前記第５領域を含む前記データフレームを、前記サーバシステムを介さずに前記制御対象デバイスに送信する情報処理システム。
　請求項５または６において、
　前記デバイスは、
　前記制御対象デバイスに対する前記制御に関するログデータを、前記サーバシステムに送信する情報処理システム。
　請求項４乃至６の何れか一項において、
　所与の空間への前記デバイスの出入りを検出する入退室管理装置と、
　前記空間内に位置する前記デバイスと、前記サーバシステムとの通信を中継するゲートウェイと、
　をさらに含み、
　前記入退室管理装置は、
　前記空間に新規デバイスが入ったことを検出した場合に、前記新規デバイスと通信を行うことによって、前記ゲートウェイを介した通信で用いられる前記新規デバイスのアドレス情報を取得し、取得した前記アドレス情報を前記空間内に位置する前記デバイスに通知する情報処理システム。
　請求項８において、
　前記デバイスは、
　前記入退室管理装置からの情報に基づいて前記制御対象デバイスの前記アドレス情報が取得されている場合に、前記サーバシステムを介さずに、前記制御対象デバイスを制御する情報処理システム。
　請求項４乃至６の何れか一項において、
　前記デバイスは、
　前記デバイスから所定距離内に位置する他のデバイスのアドレス情報を、前記サーバシステムから取得し、
　前記制御対象デバイスの前記アドレス情報が取得されている場合に、前記サーバシステムを介さずに、前記制御対象デバイスを制御する情報処理システム。
　請求項１乃至６の何れか一項において、
　前記サーバシステムは、
　前記デバイス種類情報に基づいて優先度を求め、前記優先度を特定する優先度情報を前記デバイスに送信し、
　前記デバイスは、
　前記デバイスの種類及び前記優先度情報に基づいて特定された前記優先度に応じて、前記データフレームを送信する情報処理システム。
　請求項３において、
　前記サーバシステムは、
　前記デバイス種類情報及び前記制御種別に基づいて優先度を求め、前記優先度を特定する優先度情報を前記デバイスに送信し、
　前記デバイスは、
　前記デバイスの種類、送信対象である前記データフレームに含まれる前記制御種別、及び、前記優先度情報に基づいて特定された前記優先度に応じて、前記データフレームを送信する情報処理システム。
　熟練者の暗黙知に対応する処理を実行するアプリケーションを含むデバイスとの通信のデータリンク層において、ＭＡＣ（Media Access Control）ヘッダ、フレームボディ、及びトレイラを含むデータフレームを送信する通信部と、
　前記通信部を制御する通信処理部と、
　を含み、
　前記通信部は、
　被介助者の活動能力を表す能力情報を格納する第１領域、前記被介助者に対する介助のシーンを特定するシーン情報を格納する第２領域、及び、前記デバイスとともに用いられる併用デバイスの種類を特定するデバイス種類情報を格納する第３領域を含む固定長の領域が、前記フレームボディに含まれる前記データフレームを、前記アプリケーションのアクティブまたは非アクティブを決定する情報として、前記デバイスに送信する情報処理装置。
　熟練者の暗黙知に対応する処理を実行するアプリケーションを含むデバイスと、前記デバイスとの通信のデータリンク層において、ＭＡＣ（Media Access Control）ヘッダ、フレームボディ、及びトレイラを含むデータフレームを送信するサーバシステムとを含む情報処理システムにおける情報処理方法であって、
　被介助者の活動能力を表す能力情報を格納する第１領域、前記被介助者に対する介助のシーンを特定するシーン情報を格納する第２領域、及び、前記デバイスとともに用いられる併用デバイスの種類を特定するデバイス種類情報を格納する第３領域を含む固定長の領域が、前記フレームボディに含まれる前記データフレームを、前記サーバシステムから前記デバイスに送信し、
　前記能力情報、前記シーン情報及び前記デバイス種類情報の少なくとも１つに基づいて、前記アプリケーションのアクティブまたは非アクティブを決定する、
　情報処理方法。