ホーム > 特許ランキング > パラマウントベッド株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024110164
(43)【公開日】2024-08-15
(54)【発明の名称】端末装置及び制御方法
(51)【国際特許分類】
G06Q 50/22 20240101AFI20240807BHJP
【ＦＩ】
G06Q50/22
【審査請求】未請求
【請求項の数】9
【出願形態】ＯＬ
(21)【出願番号】P 2023014574
(22)【出願日】2023-02-02
(71)【出願人】
【識別番号】390039985
【氏名又は名称】パラマウントベッド株式会社
(74)【代理人】
【識別番号】110002848
【氏名又は名称】弁理士法人ＮＩＰ＆ＳＢＰＪ国際特許事務所
(72)【発明者】
【氏名】石川 隆史
(72)【発明者】
【氏名】中村 侑規
【テーマコード（参考）】
5L099
【Ｆターム（参考）】
5L099AA11
(57)【要約】
【課題】介助者による被介助者の介助を適切にサポートする端末装置及び制御方法等の提供。
【解決手段】 被介助者の介助を実行する介助者によって使用される端末装置であって、被介助者の介助に関する処理を行う第１アプリケーション及び第２アプリケーションを記憶する記憶部と、第１アプリケーション及び第２アプリケーションに従って動作する処理部と、を含み、処理部は、被介助者の認証処理が行われた後に第１アプリケーションが起動された場合、被介助者の認証結果を用いて第１アプリケーションを動作させ、第１アプリケーションの終了後に第２アプリケーションが起動された場合、被介助者の認証結果を維持した状態で第２アプリケーションを動作させる。
【選択図】図３
【解決手段】 被介助者の介助を実行する介助者によって使用される端末装置であって、被介助者の介助に関する処理を行う第１アプリケーション及び第２アプリケーションを記憶する記憶部と、第１アプリケーション及び第２アプリケーションに従って動作する処理部と、を含み、処理部は、被介助者の認証処理が行われた後に第１アプリケーションが起動された場合、被介助者の認証結果を用いて第１アプリケーションを動作させ、第１アプリケーションの終了後に第２アプリケーションが起動された場合、被介助者の認証結果を維持した状態で第２アプリケーションを動作させる。
【選択図】図３
【特許請求の範囲】
【請求項1】
被介助者の介助を実行する介助者によって使用される端末装置であって、
前記被介助者の前記介助に関する処理を行う第１アプリケーション及び第２アプリケーションを記憶する記憶部と、
前記第１アプリケーション及び前記第２アプリケーションに従って動作する処理部と、
を含み、
前記処理部は、
前記被介助者の認証処理が行われた後に前記第１アプリケーションが起動された場合、前記被介助者の認証結果を用いて前記第１アプリケーションを動作させ、
前記第１アプリケーションの終了後に前記第２アプリケーションが起動された場合、前記被介助者の前記認証結果を維持した状態で前記第２アプリケーションを動作させる端末装置。
前記被介助者の前記介助に関する処理を行う第１アプリケーション及び第２アプリケーションを記憶する記憶部と、
前記第１アプリケーション及び前記第２アプリケーションに従って動作する処理部と、
を含み、
前記処理部は、
前記被介助者の認証処理が行われた後に前記第１アプリケーションが起動された場合、前記被介助者の認証結果を用いて前記第１アプリケーションを動作させ、
前記第１アプリケーションの終了後に前記第２アプリケーションが起動された場合、前記被介助者の前記認証結果を維持した状態で前記第２アプリケーションを動作させる端末装置。
【請求項2】
請求項１において、
前記記憶部は、
さらに、検索アプリケーションを記憶し、
前記処理部は、
前記検索アプリケーションに従って動作することによって、
前記被介助者の前記認証処理、
前記第１アプリケーション及び前記第２アプリケーションを含む複数のアプリケーションから、認証された前記被介助者に関連するアプリケーションを検索する検索処理、及び、
検索結果を提示する提示処理、
を実行する端末装置。
前記記憶部は、
さらに、検索アプリケーションを記憶し、
前記処理部は、
前記検索アプリケーションに従って動作することによって、
前記被介助者の前記認証処理、
前記第１アプリケーション及び前記第２アプリケーションを含む複数のアプリケーションから、認証された前記被介助者に関連するアプリケーションを検索する検索処理、及び、
検索結果を提示する提示処理、
を実行する端末装置。
【請求項3】
請求項２において、
前記処理部は、
前記検索アプリケーションの前記検索処理において、前記被介助者と前記被介助者の属性とを対応付けた属性情報に基づいて、認証された前記被介助者の前記属性を特定し、前記属性と対応付けられた前記アプリケーションを前記記憶部から検索する端末装置。
前記処理部は、
前記検索アプリケーションの前記検索処理において、前記被介助者と前記被介助者の属性とを対応付けた属性情報に基づいて、認証された前記被介助者の前記属性を特定し、前記属性と対応付けられた前記アプリケーションを前記記憶部から検索する端末装置。
【請求項4】
請求項２において、
前記処理部は、
前記検索アプリケーションの前記検索処理において、前記端末装置の使用場所、処理実行時の時間帯、及び、前記端末装置の周辺に位置する介助機器の少なくとも１つの情報に基づいて、前記アプリケーションを前記記憶部から検索する処理を行う端末装置。
前記処理部は、
前記検索アプリケーションの前記検索処理において、前記端末装置の使用場所、処理実行時の時間帯、及び、前記端末装置の周辺に位置する介助機器の少なくとも１つの情報に基づいて、前記アプリケーションを前記記憶部から検索する処理を行う端末装置。
【請求項5】
請求項１乃至４の何れか一項において、
前記処理部は、
前記認証処理が行われずに前記第１アプリケーションが起動された場合、前記第１アプリケーションに従って動作することによって、前記被介助者の前記認証処理を実行する端末装置。
前記処理部は、
前記認証処理が行われずに前記第１アプリケーションが起動された場合、前記第１アプリケーションに従って動作することによって、前記被介助者の前記認証処理を実行する端末装置。
【請求項6】
請求項２乃至４の何れか一項において、
前記処理部は、
前記第１アプリケーションが前記検索アプリケーションを介した第１起動処理によって起動された場合と、前記第１アプリケーションが前記検索アプリケーションを介さない第２起動処理によって起動された場合とで、前記第１アプリケーションにおける処理を切り替える端末装置。
前記処理部は、
前記第１アプリケーションが前記検索アプリケーションを介した第１起動処理によって起動された場合と、前記第１アプリケーションが前記検索アプリケーションを介さない第２起動処理によって起動された場合とで、前記第１アプリケーションにおける処理を切り替える端末装置。
【請求項7】
請求項２乃至４の何れか一項において、
前記記憶部は、
前記第１アプリケーションと同じ介助内容に関する処理を行う第３アプリケーションを記憶し、
前記処理部は、
ホーム画面において前記第３アプリケーションを表示し、且つ、前記第１アプリケーションを表示せず、
前記検索アプリケーションの検索結果において前記第１アプリケーションを表示し、且つ、前記第３アプリケーションを表示しない端末装置。
前記記憶部は、
前記第１アプリケーションと同じ介助内容に関する処理を行う第３アプリケーションを記憶し、
前記処理部は、
ホーム画面において前記第３アプリケーションを表示し、且つ、前記第１アプリケーションを表示せず、
前記検索アプリケーションの検索結果において前記第１アプリケーションを表示し、且つ、前記第３アプリケーションを表示しない端末装置。
【請求項8】
請求項７において、
前記第１アプリケーションは、前記被介助者の前記認証処理を行う機能を有さず、
前記第３アプリケーションは、前記被介助者の前記認証処理を行う機能を有する端末装置。
前記第１アプリケーションは、前記被介助者の前記認証処理を行う機能を有さず、
前記第３アプリケーションは、前記被介助者の前記認証処理を行う機能を有する端末装置。
【請求項9】
被介助者の介助を実行する介助者によって使用され、前記被介助者の前記介助に関する処理を行う第１アプリケーション及び第２アプリケーションを記憶する端末装置の制御方法であって、
前記被介助者の認証処理が行われた後に前記第１アプリケーションが起動された場合、前記被介助者の認証結果を用いて前記第１アプリケーションを動作させ、
前記第１アプリケーションの終了後に前記第２アプリケーションが起動された場合、前記被介助者の前記認証結果を維持した状態で前記第２アプリケーションを動作させる、
制御方法。
前記被介助者の認証処理が行われた後に前記第１アプリケーションが起動された場合、前記被介助者の認証結果を用いて前記第１アプリケーションを動作させ、
前記第１アプリケーションの終了後に前記第２アプリケーションが起動された場合、前記被介助者の前記認証結果を維持した状態で前記第２アプリケーションを動作させる、
制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、端末装置及び制御方法等に関する。
【背景技術】
【0002】
従来、介助者が被介助者の介助を行う場面において利用されるシステムが知られている。特許文献１には、居住空間にセンサを配置し、当該センサにより取得された検知情報の時間変化に基づいて、居住空間に居住する居住者の状態に関する提供情報を生成する手法が開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０２１－１８７６０号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
介助者による被介助者の介助を適切にサポートする端末装置及び制御方法等を提供する。
【課題を解決するための手段】
【0005】
本開示の一態様は、被介助者の介助を実行する介助者によって使用される端末装置であって、前記被介助者の前記介助に関する処理を行う第１アプリケーション及び第２アプリケーションを記憶する記憶部と、前記第１アプリケーション及び前記第２アプリケーションに従って動作する処理部と、を含み、前記処理部は、前記被介助者の認証処理が行われた後に前記第１アプリケーションが起動された場合、前記被介助者の認証結果を用いて前記第１アプリケーションを動作させ、前記第１アプリケーションの終了後に前記第２アプリケーションが起動された場合、前記被介助者の前記認証結果を維持した状態で前記第２アプリケーションを動作させる端末装置に関係する。
【0006】
本開示の他の態様は、被介助者の介助を実行する介助者によって使用され、前記被介助者の前記介助に関する処理を行う第１アプリケーション及び第２アプリケーションを記憶する端末装置の制御方法であって、前記被介助者の認証処理が行われた後に前記第１アプリケーションが起動された場合、前記被介助者の認証結果を用いて前記第１アプリケーションを動作させ、前記第１アプリケーションの終了後に前記第２アプリケーションが起動された場合、前記被介助者の前記認証結果を維持した状態で前記第２アプリケーションを動作させる制御方法に関係する。
【図面の簡単な説明】
【0007】
【図1】情報処理システムの構成例を示す図である。
【図2】サーバシステムの構成例を示す図である。
【図3】端末装置の構成例を示す図である。
【図4A】ポジショニングアプリケーションの教師データの例である。
【図4B】ポジショニングアプリケーションで重畳表示される教師データの例である。
【図5】車椅子に配置される圧力センサの例である。
【図6】ベッドに配置されるデバイスの例である。
【図7】嚥下ムセ検出装置の例である。
【図8A】食事摂取量アプリケーションにおける表示画面例である。
【図8B】食事摂取量アプリケーションにおける表示画面例である。
【図9A】いじりを検出する通信タグの構成例である。
【図9B】いじりを検出する通信タグの構成例である。
【図9C】通信タグの板バネを操作した際の動きを説明する図である。
【図10】本実施形態に係るアプリケーション及びセンシングデバイスの関係例である。
【図11】起床時におけるアプリケーション等のユースケースを説明する図である。
【図12】被介助者の居室に配置されるデバイスの例である。
【図13】検索アプリケーションを用いる場合の処理を説明するフローチャートである。
【図14A】検索アプリケーションを用いる場合の表示画面例である。
【図14B】検索アプリケーションを用いる場合の表示画面例である。
【図14C】検索アプリケーションを用いる場合の表示画面例である。
【図14D】検索アプリケーションを用いる場合の表示画面例である。
【図14E】検索アプリケーションを用いる場合の表示画面例である。
【図15】検索アプリケーションを用いる場合の服薬アプリケーションの処理を説明するフローチャートである。
【図16A】食堂におけるアプリケーション等のユースケースを説明する図である。
【図16B】食堂におけるアプリケーション等のユースケースを説明する図である。
【図17】ホーム画面からアプリケーションを起動する場合の処理を説明するフローチャートである。
【図18A】ホーム画面からアプリケーションを起動する場合の表示画面例である。
【図18B】ホーム画面からアプリケーションを起動する場合の表示画面例である。
【図18C】ホーム画面からアプリケーションを起動する場合の表示画面例である。
【図18D】ホーム画面からアプリケーションを起動する場合の表示画面例である。
【図19】ホーム画面から起動された場合の服薬アプリケーションの処理を説明するフローチャートである。
【図20】就床時におけるアプリケーション等のユースケースを説明する図である。
【図21】漏れ通知を行う場合の服薬アプリケーションの処理を説明するフローチャートである。
【図22】介護施設等における服薬スケジュール及び〆タイミングを説明する図である。
【図23】〆タイミングにおける漏れ通知処理を説明するフローチャートである。
【図24】複数の装置で服薬管理の結果を共有する場合のシステム構成例である。
【図25】複数の装置で服薬管理の結果を共有する場合のシステム構成例である。
【図26】いじり検知と便検知の連携処理の例を示す図である。
【図27】いじり検知と便検知の連携処理の例を示す図である。
【図28】服薬アプリケーションにおける下剤に関する通知画面の例である。
【図29A】ポジショニングアプリケーションの正解データである撮像画像を取得する際の画面例である。
【図29B】ポジショニングアプリケーションにおける付加情報の入力画面例である。
【図29C】ポジショニングアプリケーションにおける付加情報の入力画面例である。
【図29D】ポジショニングアプリケーションにおける付加情報の入力画面例である。
【図30A】テキストまたは図形である付加情報の入力画面例である。
【図30B】テキストである付加情報の入力画面例である。
【図30C】テキストである付加情報の入力画面例である。
【図30D】図形である付加情報の入力画面例である。
【図31A】骨格トラッキングに関する付加情報の入力画面例である。
【図31B】骨格トラッキングに関する付加情報の入力画面例である。
【図32A】オブジェクト検出に関する付加情報の入力画面例である。
【図32B】オブジェクト検出に関する付加情報の入力画面例である。
【図33A】正解データの表示画面例である。
【図33B】ポジショニングアプリケーションの機能のオン／オフを設定する画面例である。
【図33C】ポジショニングアプリケーションの各機能を用いて表示される画面例である。
【発明を実施するための形態】
【0008】
以下、本実施形態について図面を参照しつつ説明する。図面については、同一又は同等の要素には同一の符号を付し、重複する説明は省略する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本開示の必須構成要件であるとは限らない。
【0009】
１．システム構成例
本実施形態に係る情報処理システム１０は、例えば介護施設での介助や訪問介護等の場面において、熟練の介助者の“勘”や“暗黙知”によって行われる作業について、当該“勘”や“暗黙知”をデジタル化することによって、熟練度によらず適切な介助を行えるように、他の介助者をサポートするものである。例えば、熟練者の暗黙知はアプリケーションソフトウェアとして実現される。以下、アプリケーションソフトウェアを単にアプリケーションと表記する。例えば本実施形態の情報処理システム１０は、介助に係るアプリケーションの利便性向上を実現するシステムであってもよい。なお本実施形態におけるアプリケーションは暗黙知をデジタル化したものに限定されず、暗黙知を用いずに介助者による介助をサポートするソフトウェアであってもよい。またここでの介助者とは、被介助者の介助を行う担当者であり、例えばケアマネージャー、介護士、訪問ヘルパー等を含む。また、在宅介護において被介助者の家族が当該被介助者の介助を行う場合もあるため、本実施形態の介助者は被介助者の家族を含んでもよい。以下、情報処理システム１０、及び情報処理システム１０に含まれる各装置について詳細に説明する。
本実施形態に係る情報処理システム１０は、例えば介護施設での介助や訪問介護等の場面において、熟練の介助者の“勘”や“暗黙知”によって行われる作業について、当該“勘”や“暗黙知”をデジタル化することによって、熟練度によらず適切な介助を行えるように、他の介助者をサポートするものである。例えば、熟練者の暗黙知はアプリケーションソフトウェアとして実現される。以下、アプリケーションソフトウェアを単にアプリケーションと表記する。例えば本実施形態の情報処理システム１０は、介助に係るアプリケーションの利便性向上を実現するシステムであってもよい。なお本実施形態におけるアプリケーションは暗黙知をデジタル化したものに限定されず、暗黙知を用いずに介助者による介助をサポートするソフトウェアであってもよい。またここでの介助者とは、被介助者の介助を行う担当者であり、例えばケアマネージャー、介護士、訪問ヘルパー等を含む。また、在宅介護において被介助者の家族が当該被介助者の介助を行う場合もあるため、本実施形態の介助者は被介助者の家族を含んでもよい。以下、情報処理システム１０、及び情報処理システム１０に含まれる各装置について詳細に説明する。
【0010】
図１は、本実施形態に係る情報処理装置を含む情報処理システム１０の構成例である。情報処理システム１０は、例えばサーバシステム１００、端末装置２００、センシングデバイス４００を含む。ただし、情報処理システム１０の構成は図１に限定されず、一部の構成を省略する、他の構成を追加する等の種々の変形実施が可能である。
【0011】
図１の端末装置２００は、本実施形態に係るアプリケーションが動作する機器であり、例えば介助者によって使用される端末である。端末装置２００は、例えばスマートフォンやタブレット端末等の携帯端末装置である。ただし端末装置２００は、ＰＣ（Personal Computer）、ヘッドセット、ＡＲ（Augmented Reality）グラスやＭＲ（Mixed Reality）グラス等のウェアラブル装置等、他の装置であってもよい。
【0012】
センシングデバイス４００は、被介助者の生活環境に配置され、被介助者自身、又は被介助者の環境に関する測定（センシング）を行う装置である。例えば端末装置２００で動作するアプリケーションは、センシングデバイス４００との連携を行う機能を有してもよい。センシングデバイス４００は、例えば図５を用いて後述する座面センサ４４０である。ただしセンシングデバイス４００は座面センサ４４０に限定されず、図６を用いて後述する検出装置４３０、図７を用いて後述する嚥下ムセ検出装置４６０、便検知を行うためのマイクや臭気センサ、被介助者の居室等に配置されるカメラ、図９Ａ－図９Ｃを用いて後述する通信タグ４７０及び当該通信タグ４７０を読み取るリーダ等、種々のデバイスを用いることが可能である。各センシングデバイス４００の詳細については後述する。
【0013】
サーバシステム１００は、例えばネットワークを介して端末装置２００及びセンシングデバイス４００と接続される。ここでのネットワークは、例えば、インターネット等の公衆通信網である。ただし、ネットワークは公衆通信網に限定されず、ＬＡＮ（Local Area Network）等であってもよい。例えばサーバシステム１００は、ＩＥＥＥ８０２．１１の規格に従った通信を行ってもよい。ただし、各機器の間の通信手法については種々の変形実施が可能である。例えば、センシングデバイス４００は、サーバシステム１００と直接接続されてもよいし、端末装置２００等の他の装置を介してサーバシステム１００に接続されてもよい。
【0014】
サーバシステム１００は、１つのサーバであってもよいし、複数のサーバを含んでもよい。例えばサーバシステム１００は、データベースサーバとアプリケーションサーバを含んでもよい。データベースサーバは、端末装置２００及びセンシングデバイス４００から送信される情報を記憶してもよい。アプリケーションサーバは、これらの情報に基づいて種々の処理を行う。また、以下の説明において端末装置２００やセンシングデバイス４００が実行する処理の少なくとも一部が、アプリケーションサーバによって実行されてもよい。なおここでの複数のサーバは、物理サーバであってもよいし仮想サーバであってもよい。また仮想サーバが用いられる場合、当該仮想サーバは１つの物理サーバに設けられてもよいし、複数の物理サーバに分散して配置されてもよい。以上のように、本実施形態におけるサーバシステム１００の具体的な構成は種々の変形実施が可能である。
【0015】
図２は、サーバシステム１００の詳細な構成例を示すブロック図である。サーバシステム１００は、例えば処理部１１０と、記憶部１２０と、通信部１３０を含む。ただしサーバシステム１００の構成は図２に限定されず、一部の構成を省略する、他の構成を追加する等の変形実施が可能である。
【0016】
本実施形態の処理部１１０は、下記のハードウェアによって構成される。ハードウェアは、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むことができる。例えば、ハードウェアは、回路基板に実装された１又は複数の回路装置や、１又は複数の回路素子によって構成できる。１又は複数の回路装置は例えばＩＣ（Integrated Circuit）、ＦＰＧＡ（field-programmable gate array）等である。１又は複数の回路素子は例えば抵抗、キャパシター等である。
【0017】
また処理部１１０は、下記のプロセッサによって実現されてもよい。本実施形態のサーバシステム１００は、情報を記憶するメモリと、メモリに記憶された情報に基づいて動作するプロセッサと、を含む。情報は、例えばプログラムと各種のデータ等である。メモリは、記憶部１２０であってもよいし、他のメモリであってもよい。プロセッサは、ハードウェアを含む。プロセッサは、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）等、各種のプロセッサを用いることが可能である。メモリは、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリなどの半導体メモリであってもよいし、レジスタであってもよいし、ハードディスク装置（ＨＤＤ：Hard Disk Drive）等の磁気記憶装置であってもよいし、光学ディスク装置等の光学式記憶装置であってもよい。例えば、メモリはコンピュータによって読み取り可能な命令を格納しており、当該命令をプロセッサが実行することによって、処理部１１０の機能が処理として実現される。ここでの命令は、プログラムを構成する命令セットの命令でもよいし、プロセッサのハードウェア回路に対して動作を指示する命令であってもよい。
【0018】
記憶部１２０は、処理部１１０のワーク領域であって、種々の情報を記憶する。記憶部１２０は、種々のメモリによって実現が可能であり、メモリは、ＳＲＡＭ、ＤＲＡＭ、ＲＯＭ（Read Only Memory）、フラッシュメモリなどの半導体メモリであってもよいし、レジスタであってもよいし、磁気記憶装置であってもよいし、光学式記憶装置であってもよい。
【0019】
通信部１３０は、ネットワークを介した通信を行うためのインターフェイスであり、サーバシステム１００が無線通信を行う場合、例えばアンテナ、ＲＦ（radio frequency）回路、及びベースバンド回路を含む。ただしサーバシステム１００は有線通信を行ってもよく、その場合の通信部１３０は、イーサネットコネクタ等の通信インターフェイス及び、当該通信インターフェイスの制御回路等を含んでもよい。通信部１３０は、処理部１１０による制御に従って動作してもよいし、処理部１１０とは異なる通信制御用のプロセッサを含んでもよい。通信部１３０は、例えばＩＥＥＥ８０２．１１やＩＥＥＥ８０２．３に規定された方式に従った通信を行ってもよい。ただし具体的な通信方式は種々の変形実施が可能である。
【0020】
図３は、端末装置２００の詳細な構成例を示すブロック図である。端末装置２００は、例えば処理部２１０と、記憶部２２０と、通信部２３０と、表示部２４０と、操作部２５０と、撮像部２６０を含んでもよい。ただし端末装置２００の構成は図３に限定されず、一部の構成を省略する、他の構成を追加する等の変形実施が可能である。
【0021】
処理部２１０は、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むハードウェアによって構成される。また処理部２１０は、プロセッサによって実現されてもよい。プロセッサは、ＣＰＵ、ＧＰＵ、ＤＳＰ等、各種のプロセッサを用いることが可能である。端末装置２００のメモリに格納された命令をプロセッサが実行することによって、処理部２１０の機能が処理として実現される。
【0022】
記憶部２２０は、処理部２１０のワーク領域であって、ＳＲＡＭ、ＤＲＡＭ、ＲＯＭ等の種々のメモリによって実現される。記憶部２２０は、本実施形態に係る種々のアプリケーションを記憶するものであり、ここでのアプリケーションは暗黙知を用いたものであってもよいし、用いないものであってもよい。アプリケーションの具体例については後述する。
【0023】
通信部２３０は、ネットワークを介した通信を行うためのインターフェイスであり、例えばアンテナ、ＲＦ回路、及びベースバンド回路を含む。通信部２３０は、例えばネットワークを介して、サーバシステム１００との通信を行う。通信部２３０は、例えばＩＥＥＥ８０２．１１の規格に準拠した無線通信をサーバシステム１００との間で実行してもよい。また通信部２３０は、被介助者の介助に用いられるセンシングデバイス４００との通信を行ってもよい。なお通信方式はＩＥＥＥ８０２．１１に限定されず、Bluetooth（登録商標）、ＮＦＣ（Near field communication）等の他の方式が用いられてもよい。
【0024】
表示部２４０は、種々の情報を表示するインターフェイスであり、液晶ディスプレイであってもよいし、有機ＥＬディスプレイであってもよいし、他の方式のディスプレイであってもよい。操作部２５０は、ユーザ操作を受け付けるインターフェイスである。操作部２５０は、端末装置２００に設けられるボタン等であってもよい。また表示部２４０と操作部２５０は、一体として構成されるタッチパネルであってもよい。
【0025】
撮像部２６０は、所定の撮像範囲を撮像することによって画像情報を出力するイメージセンサを有する。ここでの画像情報は、静止画像であってもよいし、動画像であってもよい。また画像情報は、カラーであってもよいし、モノクロであってもよい。また、撮像部は、被写体までの距離を検出する深度センサを含んでもよいし、被写体の熱を検出するセンサ（例えば赤外線センサ）等を含んでもよい。
【0026】
また端末装置２００は、図３には不図示の構成を含んでもよい。例えば端末装置２００は、加速度センサやジャイロセンサ等のモーションセンサ、圧力センサ、ＧＰＳ（Global Positioning System）センサ等の種々のセンサを有してもよい。また端末装置２００は、発光部、振動部、音入力部、音出力部等を含んでもよい。発光部は例えばＬＥＤ（light emitting diode）であり、発光による報知を行う。振動部は例えばモータであり、振動による報知を行う。音入力部は例えばマイクである。音出力部は例えばスピーカであり、音による報知を行う。
【0027】
上述したように、本実施形態の手法では、熟練介助者の介助に関する暗黙知がデジタル化される。デジタル化の一例として、暗黙知に対応する処理を行うアプリケーションを作成し、例えば端末装置２００において当該アプリケーションを動作させることが考えられる。ただし暗黙知は、被介助者の属性や、当該被介助者の環境等に応じて、被介助者ごとに個別最適化されたものであることが多い。なおここでの属性には、被介助者の年齢、性別、身長、体重、既往歴、投薬履歴等が含まれる。また本実施形態のアプリケーションは暗黙知を用いないものであってもよいが、この場合も、被介助者に応じて異なる処理が実行される場合も考えられる。
【0028】
例えば本実施形態に係るアプリケーションは、同種のアプリケーションであっても、被介助者に応じて異なるアプリケーションが作成されることもある。ここで同種のアプリケーションとは、例えば同じ内容の介助をサポートするためのアプリケーションを表す。例えば図１８Ａを用いて後述するように、端末装置２００には、被介助者ごとに異なる複数のポジショニングアプリケーションがインストールされてもよい。さらに言えば、ポジション調整の場面や目的等に応じて１人の被介助者のために複数のポジショニングアプリケーションが作成されてもよい。ポジショニングアプリケーションとは、人や物の位置姿勢の調整をサポートするアプリケーションである。詳細については後述する。
【0029】
あるいは、本実施形態のアプリケーションが、複数の被介助者に対応可能な１つのアプリケーションとして実装され、対象の被介助者に応じて当該アプリケーションの処理内容が変更されてもよい。ここでアプリケーションの処理内容の変更とは、当該アプリケーションが有する各機能のオン／オフの切り替えであってもよいし、当該アプリケーションの判定で用いられるパラメータ（例えば閾値等）の変更であってもよい。例えば１つのポジショニングアプリケーションに複数の被介助者用の教師データ（パラメータ）が登録されており、被介助者に応じて教師データが切り替えられることによって、当該ポジショニングアプリケーションが複数の被介助者を対象として使用されてもよい。
【0030】
このように個別最適化されたアプリケーション（特に暗黙知をデジタル化したアプリケーション）利用するために、例えば介助者が被介助者の認証（特定）に関する操作を行うことが考えられる。例えば被介助者ごとにアプリケーションが異なる場合、介助者は、介助対象の被介助者に応じて、起動するアプリケーションを選択する操作を行う。あるいは、複数の被介助者を対象とするアプリケーションを使用する場合、介助者は、被介助者の認証処理を行う操作を実行する。例えば、アプリケーションに被介助者を認証する認証機能が実装され、介助者は当該認証機能を使用するための操作を実行する。
【0031】
しかし、介護施設等における介助ではアプリケーションの利用に複数のユースケースが考えられる。そのため、場合によっては、適切にアプリケーションを利用するための介助者の作業が煩雑になる可能性があることがわかってきた。具体的には、端末装置２００に多数のアプリケーションがインストールされることによって所望のアプリケーションを探すことが容易でないケースが考えられる。従って本実施形態では、多様なユースケースに対応可能なアプリケーションの利用手法を提案する。
【0032】
例えば本実施形態に係る端末装置２００は以下の通りであってもよい。記憶部２２０は、被介助者の介助に関する処理を行う第１アプリケーション及び第２アプリケーションを記憶する。処理部２１０は、第１アプリケーション及び第２アプリケーションに従って動作する。そして処理部２１０は、被介助者の認証処理が行われた後に第１アプリケーションが起動された場合、被介助者の認証結果を用いて第１アプリケーションを動作させる。さらに処理部２１０は、第１アプリケーションの終了後に第２アプリケーションが起動された場合、第１アプリケーション起動前の被介助者の認証結果を維持した状態で第２アプリケーションを動作させる。
【0033】
介護施設等における介助では、特定の被介助者を対象として複数の介助を連続して実行する場面が考えられる。例えば図１１を用いて後述する起床時には、介助者は対象の被介助者の居室に入り、当該被介助者を対象として、ポジショニングアプリケーションを用いたポジション調整、服薬アプリケーションを用いた服薬管理等、複数の介助を連続して実行する。本実施形態の手法によれば、このような場面において、予め認証処理を行った上で、その結果を引き継いだ状態で複数のアプリケーションを動作させることが可能になる。従って、各アプリケーションにおいて個別に被介助者の認証を行う必要がない。例えば本実施形態の手法では、ポジショニングアプリケーションの起動時、及び、服薬アプリケーションの起動時にそれぞれ被介助者の認証を行う必要がないため、介助者の操作負担を軽減し、介助をスムーズに実行させることが可能になる。また端末装置２００に多数のアプリケーションがインストールされている場合であっても、対象の介助者に適した一部のアプリのみを提示することも可能であるため（例えば後述する図１４Ｂ、図１４Ｅ）、アプリケーションを探す際のユーザ負担を軽減できる。
【0034】
なお本実施形態では、各アプリケーション起動前の認証処理、及び、対象の被介助者に関係するアプリケーションを検索する処理を実行する検索アプリケーションが用いられてもよい。このようにすれば、例えば被介助者ごとにアプリケーションが作成されることで端末装置２００に多数のアプリケーションがインストールされている場面であっても、被介助者に適したアプリケーションが選択、提示される。結果として、介助者がアプリケーションを選択することが容易になるため、利便性向上が可能になる。検索アプリケーションの動作等については図１３－図１４Ｅ等を用いて後述する。以下、検索アプリケーションを用いて被介助者の認証処理を行ったうえで、当該検索アプリケーションの中でまたは当該検索アプリケーションから各アプリケーションを起動する処理を第１起動処理と表記する。第１起動処理が行われた場合、上述したように各アプリケーションでは認証結果を流用可能であるため、アプリケーションごとの認証は不要となる。なお第１起動処理は、認証処理の結果を複数のアプリケーションで利用可能な起動処理であればよく、検索アプリケーションを用いない処理を含んでもよい。
【0035】
また介護施設等におけるアプリケーションのユースケースは以上に限定されず、複数の被介助者を対象として同種の介助を実行する場面が考えられる。例えば図１６Ａ、図１６Ｂを用いて後述する食堂の場面では、介助者は数十人の被介助者を対象として、順次、服薬アプリケーションを用いた服薬管理を実行する。この場合、認証結果を維持するよりも、服薬アプリケーションの中で、管理対象となる被介助者の認証が繰り返し実行される方が、利便性に寄与すると考えられる。従って本実施形態では、認証結果を複数のアプリケーションで共有する処理と、１つのアプリケーションにおいて、都度、被介助者の認証を行う処理の両方が実行可能であってもよい。このようにすれば、多様なユースケースが想定される場合であっても、被介助者に容易にアプリケーション（特に暗黙知を用いたアプリケーション）を利用させることが可能になる。以下、検索アプリケーションを用いずに各アプリケーション起動する処理を第２起動処理と表記する。第２起動処理が行われた場合、アプリケーションごとに被介助者の認証処理が実行される。
【0036】
また、本実施形態の情報処理システム１０が行う処理の一部又は全部は、プログラムによって実現されてもよい。情報処理システム１０が行う処理とは、狭義には端末装置２００の処理部２１０が行う処理であるが、サーバシステム１００の処理部１１０が実行する処理であってもよい。また情報処理システム１０が行う処理は、センシングデバイス４００に含まれるプロセッサが実行する処理を含んでもよい。
【0037】
本実施形態に係るプログラムは、例えばコンピュータによって読み取り可能な媒体である非一時的な情報記憶媒体（情報記憶装置）に格納できる。情報記憶媒体は、例えば光ディスク、メモリーカード、ＨＤＤ、或いは半導体メモリなどによって実現できる。半導体メモリは例えばＲＯＭである。処理部２１０等は、情報記憶媒体に格納されるプログラムに基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体は、処理部２１０等としてコンピュータを機能させるためのプログラムを記憶する。コンピュータは、入力装置、処理部、記憶部、出力部を備える装置である。具体的には本実施形態に係るプログラムは、図１３、図１５、図１７、図１９、図２１、図２３等を用いて後述する各ステップを、コンピュータに実行させるためのプログラムである。
【0038】
また本実施形態の手法は、以下の各ステップを含む制御方法に適用できる。ここでの制御方法は、被介助者の介助を実行する介助者によって使用される端末装置であって、被介助者の介助に関する処理を行う第１アプリケーション及び第２アプリケーションを記憶する端末装置２００の制御方法である。当該制御方法は、被介助者の認証処理が行われた後に第１アプリケーションが起動された場合、被介助者の認証結果を用いて第１アプリケーションを動作させるステップと、第１アプリケーションの終了後に第２アプリケーションが起動された場合、被介助者の認証結果を維持した状態で第２アプリケーションを動作させるステップと、を含む。
【0039】
２．アプリケーション
次に、端末装置２００において動作するアプリケーションの具体例について説明する。なおここでのアプリケーションは、例えば処理パラメータの設定等において熟練者の判断結果が用いられる。なお、アプリケーションがセンシングデバイス４００と連携する場合、センシングデバイス４００の具体例についても併せて説明する。また図１０を用いて複数のアプリケーション及びセンシングデバイス４００の関係例についても説明する。
次に、端末装置２００において動作するアプリケーションの具体例について説明する。なおここでのアプリケーションは、例えば処理パラメータの設定等において熟練者の判断結果が用いられる。なお、アプリケーションがセンシングデバイス４００と連携する場合、センシングデバイス４００の具体例についても併せて説明する。また図１０を用いて複数のアプリケーション及びセンシングデバイス４００の関係例についても説明する。
【0040】
２．１ 具体例
＜ポジショニングアプリケーション＞
ポジショニングアプリケーションとは、介助における人及び物の少なくとも一方の位置に関する処理を行うアプリケーションである。ポジショニングアプリケーションは、ベッド６１０における被介助者等の姿勢調整に用いられてもよいし、車椅子６３０における被介助者等の姿勢調整に用いられてもよい。例えば、ポジショニングアプリケーションは、設定を行う設定モードと、当該設定に従って実際のポジション調整をサポートする利用モードで動作してもよい。例えば設定モードにおいて、ポジショニングアプリケーションは、熟練者の操作に基づいて、望ましい位置で人や物を撮像した教師データを取得する。そして動作モードにおいて、ポジショニングアプリケーションは、調整対象である人や物を撮像した撮像画像に対して、透過処理を施した教師データを重畳表示する。
＜ポジショニングアプリケーション＞
ポジショニングアプリケーションとは、介助における人及び物の少なくとも一方の位置に関する処理を行うアプリケーションである。ポジショニングアプリケーションは、ベッド６１０における被介助者等の姿勢調整に用いられてもよいし、車椅子６３０における被介助者等の姿勢調整に用いられてもよい。例えば、ポジショニングアプリケーションは、設定を行う設定モードと、当該設定に従って実際のポジション調整をサポートする利用モードで動作してもよい。例えば設定モードにおいて、ポジショニングアプリケーションは、熟練者の操作に基づいて、望ましい位置で人や物を撮像した教師データを取得する。そして動作モードにおいて、ポジショニングアプリケーションは、調整対象である人や物を撮像した撮像画像に対して、透過処理を施した教師データを重畳表示する。
【0041】
図４Ａは、設定モードにおいて取得される教師データの一例である。図４Ａの例では、「ＡＡＡ」という氏名の被介助者がベッド６１０に横たわる際の望ましい姿勢を表す画像情報が教師データとして取得される。図４Ｂは、利用モードにおいて撮像画像に重畳表示される画像であって、透過処理を施した教師データの例である。例えば端末装置２００は、ポジション調整の対象である被介助者を撮像した撮像画像に、図４Ｂの画像を重畳表示する。介助者は、撮像画像上の被介助者が、教師データに近づくように、当該被介助者の介助を行う。このようにすれば、介助者によるポジション調整を適切にサポートすることが可能になる。
【0042】
なおここでは画像情報である教師データの重畳表示を行う例を説明したが、ポジショニングアプリケーションは、被介助者等の姿勢が適切であるか否かの判定結果（ＯＫ／ＮＧ）を出力してもよい。例えばポジショニングアプリケーションは、ポジション調整中に撮像されている画像と、教師データの類似度合いに基づいてＯＫ，ＮＧの何れかを判定し、判定結果を出力してもよい。具体的には、ポジショニングアプリケーションは、被介助者や介助者の姿勢が適切か否かを判定してもよいし、クッション等の用具の位置が適切か否かを判定してもよい。なお、ＯＫ，ＮＧの何れかを判定は、教師データに含まれる被介助者の骨格情報とポジション調整中に撮像されている画像に含まれる被介助者の骨格情報に基づいてもよい（詳細は後述）。
【0043】
またポジショニングアプリケーションは、ＮＧと判定された具体的な点を表示する処理を行ってもよい。例えばポジショニングアプリケーションは、撮像された画像と教師データを比較し、差分が大きいと判定された箇所を強調表示する処理を行ってもよい。あるいはポジショニングアプリケーションは、クッションの位置をどのように変更すればよいか、姿勢をどのように変更すればよいかといった具体的な指示を出力してもよい。なお、差分が大きいと判定された箇所は、教師データに含まれる被介助者の骨格情報とポジション調整中に撮像されている画像に含まれる被介助者の骨格情報に基づいてもよい（詳細は後述）。
【0044】
またポジショニングアプリケーションは、設定モードにおいて熟練者が重要と考えるポイント等の付加情報を受け付け、利用モードにおいて当該付加情報を提示してもよい。付加情報には、所定部位の位置や角度、クッションの有無や大きさ、柔らかさ等の情報が含まれてもよい。またポジショニングアプリケーションは、被介助者の姿勢判定の結果に基づいて、当該被介助者がクッション等の福祉用具を用いることで姿勢調整が容易になると判定した場合、当該被介助者に適した福祉用具のレコメンドを行ってもよい。また被介助者がすでにクッションを使用している場合であっても、当該クッションの位置調整が適切に行われていない場合、当該クッションの大きさが教師データに含まれるクッションの大きさと異なる場合等には新たなクッション等をレコメンドしてもよい。ここでのレコメンドは、クッション等のサイズ、硬さ等を指定するものであってもよいし、具体的な商品（型番等）を指定するものであってもよい。また具体的な商品を指定する場合、ポジショニングアプリケーションは商品を販売するＥＣサイト等へのリンク情報を出力してもよい。
【0045】
【0046】
＜座面センサ連携アプリケーション＞
座面センサ連携アプリケーションは、センシングデバイス４００である座面センサ４４０と連携する機能を有するアプリケーションである。図５は、車椅子６３０の座面に配置される座面センサ４４０を示す図である。座面センサ４４０は圧力値を出力する圧力センサを含み、当該圧力値を出力する。
座面センサ連携アプリケーションは、センシングデバイス４００である座面センサ４４０と連携する機能を有するアプリケーションである。図５は、車椅子６３０の座面に配置される座面センサ４４０を示す図である。座面センサ４４０は圧力値を出力する圧力センサを含み、当該圧力値を出力する。
【0047】
図５の例では、車椅子６３０の座面に配置されるクッション４４１の裏面側に４つの圧力センサＳｅ１～Ｓｅ４が配置される。圧力センサＳｅ１は前方に配置されるセンサであり、圧力センサＳｅ２は後方に配置されるセンサであり、圧力センサＳｅ３は右方に配置されるセンサであり、圧力センサＳｅ４は左方に配置されるセンサである。なおここでの前後左右は、車椅子６３０に被介助者が座った状態において、当該被介助者から見た方向を表す。圧力センサＳｅ１～Ｓｅ４は、制御ボックス４４２に接続される。制御ボックス４４２は、内部に圧力センサＳｅ１～Ｓｅ４を制御するプロセッサと、プロセッサのワーク領域となるメモリを含む。プロセッサは、圧力センサＳｅ１～Ｓｅ４を動作させることによって圧力値を検出する。
【0048】
座面センサ連携アプリケーションは、例えば座面センサ４４０からの圧力値に基づいて、被介助者が車椅子６３０に座った際の姿勢（以下、座姿勢とも記載する）が、正常、前ずれ、横ずれ等を含む複数の姿勢の何れであるかを判定してもよい。前ずれとは、ユーザの重心が通常よりも前方にずれた状態を表し、横ずれとは、ユーザの重心が通常よりも左右の何れか一方にずれた状態を表す。例えば、座面センサ連携アプリケーションは、圧力センサＳｅ１の値が初期状態に比べて所定以上増加した場合に前ずれと判定し、圧力センサＳｅ３又はＳｅ４が初期状態に比べて所定以上増加した場合に横ずれと判定する。また座面センサ連携アプリケーションは、被介助者が座面から転落する可能性の有無を判定する転落可能性の判定を行ってもよい。
【0049】
以上の説明からも分かるとおり、座面センサ連携アプリケーションは、座面センサ４４０からの情報を用いて車椅子６３０における被介助者の位置姿勢を判定してもよく、上述したポジショニングアプリケーションに含まれてもよい。例えば、ポジショニングアプリケーションの設定モードにおいて、座面センサ４４０からのデータがユーザに提示されてもよい。このようにすれば、座面のデータを見ながら教師データを設定できるため、より適切な姿勢、位置に対応するデータを教師データとして設定できる。また本実施形態の端末装置２００は、圧力検知が可能なマットレス６２０と連携することによってベッド６１０での被介助者の姿勢に関する判定を行うマットレス連携アプリケーションを記憶してもよい。マットレス連携アプリケーションについても、ベッド６１０における被介助者の位置姿勢を判定するものであるため、上述したポジショニングアプリケーションに含まれてもよい。この場合も、例えばポジショニングアプリケーションの設定モードにおいて、マットレスからのデータがユーザに提示されてもよい。
【0050】
＜立ち上がり検知アプリケーション＞
立ち上がり検知アプリケーションは、被介助者がベッド６１０、車椅子６３０等から立ち上がることを検知するアプリケーションである。図６は、立ち上がり検知アプリケーションに利用可能なセンシングデバイス４００の例であって、ベッド６１０のボトムに配置される検出装置４３０の例を説明する図である。検出装置４３０は、例えば図６に示すように、ベッド６１０のボトムとマットレス６２０の間に設けられるシート状またはプレート状のデバイスである。
立ち上がり検知アプリケーションは、被介助者がベッド６１０、車椅子６３０等から立ち上がることを検知するアプリケーションである。図６は、立ち上がり検知アプリケーションに利用可能なセンシングデバイス４００の例であって、ベッド６１０のボトムに配置される検出装置４３０の例を説明する図である。検出装置４３０は、例えば図６に示すように、ベッド６１０のボトムとマットレス６２０の間に設けられるシート状またはプレート状のデバイスである。
【0051】
検出装置４３０は、圧力値を出力する圧力センサを含む。検出装置４３０は、ユーザが就床すると、マットレス６２０を介してユーザの体振動（体動、振動）を検知する。検出装置４３０が検知した体振動に基づいて、呼吸数、心拍数、活動量、姿勢、覚醒／睡眠、離床／在床に関する情報が求められる。また検出装置４３０は、ノンレム睡眠とレム睡眠の判定や、睡眠の深さの判定を行ってもよい。例えば体動の周期性を分析し、ピーク周波数から呼吸数、心拍数が算出されてもよい。周期性の分析は、例えばフーリエ変換等である。呼吸数は、単位時間あたりの呼吸の回数である。心拍数は、単位時間あたりの心拍の回数である。単位時間は、例えば１分である。また、サンプリング単位時間当たりに体振動を検出し、検出された体振動の回数が活動量として算出されてもよい。またユーザの離床時には、在床時に比べて検出される圧力値が減少するため、圧力値やその時系列的な変化に基づいて離床／在床の判定が可能である。
【0052】
立ち上がり検知アプリケーションは、検出装置４３０からの情報に基づいて、被介助者の動き出しに関する判定を行ってもよい。例えば立ち上がり検知アプリケーションは、被介助者が在床状態から離床状態に移行した場合に、動き出しがあったと判定する。またより早い段階で動き出しの兆候を検出するという観点から、立ち上がり検知アプリケーションは、被介助者が睡眠状態から覚醒状態に移行した場合に、動き出しがあったと判定してもよい。
【0053】
なおここでは圧力センサを含む検出装置４３０と連携する例を説明したが、立ち上がり検知アプリケーションはこれに限定されない。例えば、被介助者の居室、リビング、食堂、ベッド６１０等にカメラが設置され、立ち上がり検知アプリケーションは当該カメラの画像に基づいて被介助者の立ち上がり検知を行ってもよい。例えば立ち上がり検知アプリケーションは、公知の骨格トラッキング処理を行うことによって被介助者の姿勢を判定し、特定の関節の角度や、床面（座面）から頭までの距離等に基づいて立ち上がり検知を行ってもよい。
【0054】
また立ち上がり検知アプリケーションは、立ち上がり動作を抑制する処理を行ってもよい。例えば立ち上がり検知アプリケーションは、カメラ画像に基づく顔認証を含む処理を行うことによって、立ち上がろうとしている被介助者を特定してもよい。この場合、立ち上がり検知アプリケーションは、対象の被介助者の気を引く蓋然性の高い動画（例えば被介助者の家族や、当該被介助者にとって印象のよい介助者等の動画）を出力する。ここでの動画は、例えば立ち上がり検知がベッドで行われる場合には、ベッド周辺に配置されるディスプレイに表示される。また立ち上がり検知がリビングで行われる場合には、当該リビングに配置されたテレビに表示されてもよい。例えば、立ち上がりが非検知の状態ではテレビは通常の放送波に基づく映像を出力し、立ち上がりが検知された場合に、対象の被介助者に合わせた動画を出力する。タブレット端末等を使い慣れていない被介助者の場合、当該タブレット端末に動画を表示しても注視しない可能性があるが、テレビを用いることによって、被介助者の気を引く動画を自然に閲覧させることが可能になる。また、被介助者の検知及び動画の出力処理は、玄関で行われてもよい。例えばショートステイの被介助者等は、自宅に帰ろうとして玄関から外に出てしまう可能性がある。その点、玄関に設置したディスプレイで被介助者の気を引く動画を出力することによって、被介助者が施設外へ出てしまうことを抑制できる。なお、被介助者の検知処理は、例えば被介助者を所定期間だけ継続して検知する場合に、被介助者を検知したと判定してもよい。
【0055】
＜嚥下ムセ検出アプリケーション＞
嚥下ムセ検出アプリケーションは、被介助者の食事等において、嚥下の状態やムセの有無等を判定するアプリケーションである。嚥下ムセ検出アプリケーションは、センシングデバイス４００である嚥下ムセ検出装置４６０と連係して動作してもよい。
嚥下ムセ検出アプリケーションは、被介助者の食事等において、嚥下の状態やムセの有無等を判定するアプリケーションである。嚥下ムセ検出アプリケーションは、センシングデバイス４００である嚥下ムセ検出装置４６０と連係して動作してもよい。
【0056】
図７は、食事の場面において利用される嚥下ムセ検出装置４６０を例示する図である。図７に示すように、嚥下ムセ検出装置４６０は、被介助者の首回りに装着されるスロートマイク４６１と、カメラを有する端末装置４６２を含む。
【0057】
スロートマイク４６１は、被介助者の嚥下や咳込み等による音声データを出力する。端末装置４６２のカメラは、被介助者の食事の様子を撮像した撮像画像を出力する。端末装置４６２は、例えば被介助者が食事をする卓上に置かれるスマートフォンやタブレット型のＰＣ等である。スロートマイク４６１は、Bluetooth等を用いて端末装置４６２に接続される。ただし、具体的な接続態様は種々の変形実施が可能である。
【0058】
嚥下ムセ検出アプリケーションは、スロートマイク４６１の音声データに基づいて、被介助者のムセと、嚥下を判定する。首回りに装着したマイクを用いて嚥下を検出するデバイスは、例えば“Swallowing action measurement device and swallowing action support system”という２０１９年２月１５日に出願された米国特許出願第１６／２７６７６８号に記載されている。この特許出願は、その全体が本願明細書において参照により援用されている。嚥下ムセ検出アプリケーションは、音声データに基づいて、ムセの回数、ムセの時間（発生時刻、継続時間等）、嚥下をしたか否かを検出できる。
【0059】
また端末装置４６２のカメラは、例えば図７に示すように被介助者を正面方向から撮像する。従って嚥下ムセ検出アプリケーションは、撮像画像に基づいて、被介助者の口、目、及び被介助者が使用する箸やスプーン等を検出してもよい。なお画像処理に基づいてこれらの顔のパーツや物体を検出する手法は種々知られており、本実施形態では公知の手法を広く適用可能である。
【0060】
例えば嚥下ムセ検出アプリケーションは、嚥下の検出結果、及び、被介助者の口の開閉判定結果に基づいて、被介助者が口を開けてから嚥下するまでの嚥下時間を求めてもよい。このようにすれば、例えば嚥下の回数が減っている場合において、食べ物を口に入れる動作自体が行われていないのか、食べ物を口に入れたのに嚥下が行われないのか等、具体的な状況を判定できる。結果として、食事における誤嚥リスク等を精度よく判定できる。
【0061】
＜食事摂取量アプリケーション＞
食事摂取量アプリケーションは、被介助者の食事による食べ物の摂取量や水分の摂取量を判定するアプリケーションである。食事摂取量アプリケーションは、例えば配膳された食事を撮像した画像に基づいて摂取量を判定してもよい。ここでの画像は、嚥下ムセ検出装置４６０の端末装置４６２のカメラによって撮像されてもよいし、他のカメラによって撮像されてもよい。
食事摂取量アプリケーションは、被介助者の食事による食べ物の摂取量や水分の摂取量を判定するアプリケーションである。食事摂取量アプリケーションは、例えば配膳された食事を撮像した画像に基づいて摂取量を判定してもよい。ここでの画像は、嚥下ムセ検出装置４６０の端末装置４６２のカメラによって撮像されてもよいし、他のカメラによって撮像されてもよい。
【0062】
図８Ａ、図８Ｂは、食事摂取量アプリケーションが実行する処理を説明する図であり、撮像画像を含む表示画面の例である。図８Ａに示す例では、３つの器に盛り付けられた食事が撮像されている。食事摂取量アプリケーションは、図８Ｂに示すように、静止画像から料理に対応する領域を検出する。例えば、食事摂取量アプリケーションは、食べ物が盛り付けられた器を内包する矩形領域を検出する処理を行う。ここでは、検出処理によって３つの器のそれぞれを内包する矩形領域Ｒ１～Ｒ３が検出される。この処理には、公知のオブジェクト検出手法を広く適用できるため、詳細な説明は省略する。
【0063】
食事摂取量アプリケーションは、オブジェクト検出によって検出された矩形領域Ｒ１～Ｒ３に基づいて、食べ物の種類を求める処理を行う。例えばYanai等による“FOOD IMAGE RECOGNITION USING DEEP CONVOLUTIONAL NETWOK WITH PRE-TRAINING AND FINE-TUNING” (http://img.cs.uec.ac.jp/pub/conf15/150703yanai_0.pdf)には、ＤＣＮＮ（deep convolutional neural network）に基づいて、画像から食べ物を認識する手法が開示されている。本実施形態の食事摂取量アプリケーションは、これらの手法のように、画像処理の結果に基づいて食べ物の種類を求めてもよい。例えば食事摂取量アプリケーションは、ＤＣＮＮに矩形領域Ｒ１～Ｒ３のそれぞれに対応する画像を入力することによって、食べ物の種類を特定する。図８Ｂの例では、３つの料理がそれぞれ「ライス」、「豆腐とわかめの味噌汁」、「きのことレタスのソテー」であるとの特定結果が取得された例を示している。また食べ物の種類の特定結果に基づいて、各食べ物によって摂取されるカロリーや栄養素の種類が特定される。
【0064】
また食事摂取量アプリケーションは、食後の状態を撮像した撮像画像を取得し、同様の処理を行うことによって、食べ物の減少量を特定する。食事摂取量アプリケーションは、当該減少量を、被介助者による摂取量と判定してもよい。また食事摂取量アプリケーションは、上述したカロリーや栄養素の情報と、摂取量を組み合わせることによって、被介助者が摂取したカロリーや栄養素の量を求めてもよい。
【0065】
＜服薬アプリケーション＞
服薬アプリケーションは、被介助者による服薬を管理するためのアプリケーションである。服薬アプリケーションは、例えば撮像部２６０によって撮像される撮像画像に基づいて、服薬を行う被介助者を認証（特定）する処理、及び、袋詰めされた薬の情報を認証する処理を行う。本実施形態の手法では、上述したとおり、被介助者の特定は、服薬アプリケーションの起動前に行われた認証処理の結果を取得することで実行されてもよいし、服薬アプリケーションの機能として実行されてもよい。被介助者の特定は、顔認証により行われてもよいし、氏名等が記載されたラベルのＯＣＲ（Optical Character Recognition/Reader）処理によって行われてもよいし、被介助者に関する情報を含むＱＲコード（登録商標）の読取りによって行われてもよく、これらは状況に応じて選択されてもよい。詳細については後述する。また薬の情報とは、対象の薬の処方対象である被介助者、及び、当該薬が服用されるべきタイミング（以下、服薬タイミングと記載）を表す情報を含んでもよい。服薬タイミングとは、例えば起床時、朝食前、朝食後、昼食前、昼食後、間食前、間食後、夕食前、夕食後、就寝時のいずれかである。
服薬アプリケーションは、被介助者による服薬を管理するためのアプリケーションである。服薬アプリケーションは、例えば撮像部２６０によって撮像される撮像画像に基づいて、服薬を行う被介助者を認証（特定）する処理、及び、袋詰めされた薬の情報を認証する処理を行う。本実施形態の手法では、上述したとおり、被介助者の特定は、服薬アプリケーションの起動前に行われた認証処理の結果を取得することで実行されてもよいし、服薬アプリケーションの機能として実行されてもよい。被介助者の特定は、顔認証により行われてもよいし、氏名等が記載されたラベルのＯＣＲ（Optical Character Recognition/Reader）処理によって行われてもよいし、被介助者に関する情報を含むＱＲコード（登録商標）の読取りによって行われてもよく、これらは状況に応じて選択されてもよい。詳細については後述する。また薬の情報とは、対象の薬の処方対象である被介助者、及び、当該薬が服用されるべきタイミング（以下、服薬タイミングと記載）を表す情報を含んでもよい。服薬タイミングとは、例えば起床時、朝食前、朝食後、昼食前、昼食後、間食前、間食後、夕食前、夕食後、就寝時のいずれかである。
【0066】
服薬アプリケーションは、例えば被介助者の認証結果、薬の認証結果、及び現在時刻に基づいて、服薬を行う被介助者と薬の処方対象である被介助者が一致するかの判定、及び、現在時刻が服薬タイミングと合致するかの判定を行ってもよい。服薬アプリケーションは、これらの判定の少なくとも１つで不適切と判定された場合、介助者にその旨を警告する通知を行ってもよい。服薬アプリケーションの詳細については、図１５、図１９等を用いて後述する。
【0067】
＜いじり検出アプリケーション＞
いじり検出アプリケーションとは、被介助者が衣類（ズボンや下着）の中に手を入れて、被介助者の肌や衣類の内側等に触れようとしていること（いじりを行おうとしていること）を検出するための処理を行う。本いじり検出アプリケーションは、被介助者が衣類（ズボンや下着）の中に手をいれたことまたは被介助者が衣服を脱いだことを検知する場合にも適用できる。その結果として、被介助者が排尿したのちに痒みを感じて手を衣服に入れていじったり、排便をしたのちに排便を取り出すために手を衣服に入れていじったり、被介助者が例えばベッド上で衣服またはおむつを脱いで排泄をしたりすることを検知することが可能である。
いじり検出アプリケーションとは、被介助者が衣類（ズボンや下着）の中に手を入れて、被介助者の肌や衣類の内側等に触れようとしていること（いじりを行おうとしていること）を検出するための処理を行う。本いじり検出アプリケーションは、被介助者が衣類（ズボンや下着）の中に手をいれたことまたは被介助者が衣服を脱いだことを検知する場合にも適用できる。その結果として、被介助者が排尿したのちに痒みを感じて手を衣服に入れていじったり、排便をしたのちに排便を取り出すために手を衣服に入れていじったり、被介助者が例えばベッド上で衣服またはおむつを脱いで排泄をしたりすることを検知することが可能である。
【0068】
例えばいじりの検出は、図９Ａ～図９Ｃに示した通信タグ４７０と、当該通信タグ４７０からの信号を読み取るリーダを用いて実行されてもよい。ここでの通信タグ４７０とは、例えばＲＦＩＤ（radio frequency identification）タグであり、リーダとはＲＦＩＤリーダである。例えば本実施形態の通信タグ４７０は、被介助者の衣類に装着され、衣類を正常に装着した場合に通信不能状態であり、被介助者が衣類を動かした場合に通信可能状態となってもよい。リーダは、通信タグ４７０の読取り結果をサーバシステム１００に送信する。サーバシステム１００の処理部１１０は、リーダによって通信タグ４７０が読み取られたという読取り結果が取得された場合、被介助者は衣類に手を入れており、いじりの可能性があると判定する。
【0069】
図９Ａ、図９Ｂは、通信タグ４７０の構成例を示す図である。例えば通信タグ４７０は、平面状の第１タグ部４７１と、第１タグ部４７１の一部を内包可能で袋状に形成された第２タグ部４７２を含む。第１タグ部４７１の一端側にはクリップ部ＣＬ１が設けられる。また第１タグ部４７１には通信用のアンテナを含む回路ＡＴＣが設けられる。なお図９Ａ等には不図示であるが、当該回路ＡＴＣには、アンテナを動作させるためのコイル等が設けられてもよい。図９Ａに示すように、回路ＡＴＣの一部を覆うように、アンテナによる通信を遮蔽する遮蔽部材ＳＨが設けられてもよい。例えば回路ＡＴＣのうち、装着状態（図９Ｂ）において第２タグ部４７２から遠い側の一部が、遮蔽部材ＳＨによって覆われる。遮蔽部材ＳＨは例えば金属であるが、具体的な構成はこれに限定されず、電波を遮蔽可能な他の部材が用いられてもよい。
【0070】
第２タグ部４７２は平面視における形状が略矩形であり、長手方向の一方側に開口を有する袋状の部材である。あるいは第２タグ部４７２は、長手方向の両方向側に開口を有する筒状の部材であってもよい。第２タグ部４７２のうち、第１タグ部４７１が挿入される側の反対側の端部にはクリップ部ＣＬ２が設けられる。また第２タグ部４７１の表面の一部、又は、全部には、第１タグ部４７１のアンテナによる通信電波を遮蔽する遮蔽部材が設けられる。ここでの遮蔽部材は例えば電波が透過しにくい布であるが、金属等の部材が用いられてもよい。
【0071】
図９Ｂに示すように、例えば通信タグ４７０は、第１タグ部４７１のうち、回路ＡＴＣの少なくとも一部を含む部分が第２タグ部４７２に挿入された状態において、クリップ部ＣＬ１及びＣＬ２を用いて被介助者の衣類（例えばズボンの腰回りに相当する部分）に装着される。具体的には、第１タグ部４７１は、回路ＡＴＣのうち、遮蔽部材ＳＨによって遮蔽されない側から、第２タグ部４７２に挿入される。さらに具体的には、第１タグ部４７１は、回路ＡＴＣのうち、遮蔽部材ＳＨによって遮蔽されない部分の全てが第２タグ部４７２に収容された状態、換言すれば遮蔽部材ＳＨの少なくとも一部が第２タグ部４７２に収容された状態で装着されてもよい。この際、第１タグ部４７１は、第２タグ部４７２に挿入されるのみであり、第１タグ部４７１と第２タグ部の間には固定部材は設けられない。
【0072】
このような状態で被介助者が衣類に手を入れた場合、被介助者の手が衣類と被介助者の体（腹部）との間に入り込むため、衣類の腰回りが伸びた状態となる。腰回りが伸びると、クリップ部ＣＬ１の固定箇所と、クリップ部ＣＬ２の固定箇所との間の距離が伸びることになるため、第１タグ部４７１は、第２タグ部４７２から離れる方向に相対的に移動する。なお、第１タグ部４７１と第２タグ部４７２の相対的な移動を容易にするため、第１タグ部４７１及び第２タグ部４７２の少なくとも一方は伸縮性を有する部材により構成されてもよい。
【0073】
第１タグ部４７１が相対的に移動することによって、第１タグ部４７１のうち、平常状態では第２タグ部４７２に内包されていた部分が、第２タグ部４７２の外部に露出する。これにより、第１タグ部４７１のアンテナが通信可能な程度に第２タグ部４７２の外部に露出した場合、通信タグ４７０はリーダにより読み取り可能な状態に移行する。具体的には、第１タグ部４７１の回路ＡＴＣのうち、遮蔽部材ＳＨによって覆われない部分が第２タグ部４７２の外部に露出することによって、回路ＡＴＣに含まれるアンテナが通信可能な状態に移行する。一方、被介助者が手を衣類に入れていない平常状態や、衣類の伸び具合が小さい場合、第１タグ部４７１のアンテナは通信不能な程度に第２タグ部４７２によって遮蔽されるため（回路ＡＴＣのうち遮蔽部材ＳＨによって覆われていない部分は第２タグ部４７２によって遮蔽されるため）、通信タグ４７０はリーダにより読み取り不能な状態が維持される。
【0074】
【0075】
例えばいじり検出アプリケーションは、通信タグ４７０と被介助者の対応付けを行うアプリケーションであってもよい。例えばいじり検出アプリケーションは、被介助者を特定する情報を取得し、当該情報と、通信タグ４７０を特定する情報（例えばＩＤ等）を対応付けてサーバシステム１００に送信する処理を行う。このようにすれば、サーバシステム１００の処理部１１０は、リーダの読取り結果が、いずれの被介助者に関係する情報であるかを適切に対応付けることが可能になる。
【0076】
あるいはいじり検出アプリケーションは、リーダから読取り結果を取得してもよい。この場合、いじり検出アプリケーションは、通信タグ４７０と被介助者を対応付ける処理を行い、対象の被介助者に対応付けられた通信タグ４７０が読み取られたか否かに基づいて、いじりの可能性の有無を判定する。
【0077】
なお利便性向上のため、図９Ａ及び図９Ｂに示したように、通信タグ４７０の第１タグ部４７１は、第２タグ部４７２から露出する回路ＡＴＣの長さ（第２タグ部４７２に挿入される回路ＡＴＣの長さ）を指し示すための目盛りを有してもよい。被介助者の属性に応じていじりのリスクは異なる。例えば認知症に起因する不穏行動が見られる被介助者は、そうでない被介助者に比べていじり（例えば便をいじる便いじり）のリスクが高い。リスクの高い被介助者は、リスクが低い介助者に比べて、いじりの検出感度が高く設定されることが好ましい。その点、目盛りを用いて第１タグ部４７０のうち、どの程度の長さが第２タグ部４７２から露出しているかが明示されることによって、介助者が通信タグ４７０を被介助者に装着する際に、装着状態を適切に設定できる。例えばリスクが高い被介助者は、リスクが低い被介助者に比べて、回路ＡＴＣに含まれるアンテナが通信可能な状態となるまでのマージンの長さが短くなるように（第２タグ部４７２から飛び出している第１タグ部４７１の長さが長くなるように）通信タグ４７０が装着される。ここでのマージンとは、遮蔽部材ＳＨのうち、第２タグ部４７２に収容された部分の長さであり、図９Ｂにおける長さＬに相当する。マージンが相対的に短い場合、被介助者が衣類にわずかに手を入れるだけでもアンテナが通信可能な状態に移行するため、いじりを感度よく検出することが可能になる。一方、低リスクの被介助者についてはアンテナが露出するまでのマージンの長さを長くする（第１タグ部４７０のうち、第２タグ部４７２から露出している部分を短くする）ことで不必要な通知を抑制することが可能になる。
【0078】
また第２タグ部４７２の開口部には、図９Ａ、図９Ｂに示すように板バネＳＰが設けられてもよい。ここでの板バネＳＰは、所与の方向からの力が加えられた場合に、当該方向に交差する方向（狭義には直交する方向）への力を発生させるバネであってもよい。例えば図９Ｃに示すように、第２タグ部４７２の短手方向（装着状態における上下方向）からの力が加えられた場合、板バネＳＰは、それに交差する方向（装着状態における前後方向）、即ち、袋状または筒状である第２タグ部４７２を開口させる方向の力を発生させる。なお、板バネＳＰに代えて、所定方向の力を加えたときに第２タグ部４７２を開口させる方向に変形する硬質部材（例えばプラスチック等）が用いられてもよい。
【0079】
上述したように、被介助者が衣類に手を入れることで通信タグ４７０が読取り可能な状態に移行した場合、再度、第１タグ部４７１を第２タグ部４７２に挿入するまでは、読み取り可能な状態が継続する。そのため、例えばいじりを警告する通知が送信され続ける可能性もあるため、介助者による対応実施後は速やかに第１タグ部４７１が第２タグ部４７２に再挿入されることが望ましい。その点、板バネＳＰを用いることによって第２タグ部４７２を開口させやすくなるため、介助者による第１タグ部４７１の挿入を容易にすることが可能になる。
【0080】
＜便検知デバイス連携アプリケーション＞
便検知デバイス連携アプリケーションは、便検知を行うセンシングデバイス４００と連携するアプリケーションである。ここでのセンシングデバイス４００は、例えばトイレに設置されたマイクであってもよい。排便音、排尿音及び放屁音のいずれかを示す音データに基づいて、排便、排尿及び放屁のいずれが行われたかを識別するデバイスは、例えば「排出物識別方法、排出物識別装置及び排出物識別プログラム」という２０２０年１２月２５日に国際出願されたＪＰ２０２０／０４８９３９（国際公開２０２１／１９２４７５号）に記載されている。この特許出願は、その全体が本願明細書において参照により援用されている。
便検知デバイス連携アプリケーションは、便検知を行うセンシングデバイス４００と連携するアプリケーションである。ここでのセンシングデバイス４００は、例えばトイレに設置されたマイクであってもよい。排便音、排尿音及び放屁音のいずれかを示す音データに基づいて、排便、排尿及び放屁のいずれが行われたかを識別するデバイスは、例えば「排出物識別方法、排出物識別装置及び排出物識別プログラム」という２０２０年１２月２５日に国際出願されたＪＰ２０２０／０４８９３９（国際公開２０２１／１９２４７５号）に記載されている。この特許出願は、その全体が本願明細書において参照により援用されている。
【0081】
例えばトイレに設置されたマイクは、音データをサーバシステム１００に送信してもよい。サーバシステム１００の処理部１１０は、当該音データに基づいて、排便、排尿及び放屁を識別する。便検知デバイス連携アプリケーションは、例えば位置データに基づいて、対象の被介助者が使用するトイレを特定する情報、あるいは、当該トイレに設けられたマイクを特定する情報を取得してもよい。そして便検知デバイス連携アプリケーションは、認証処理によって特定された被介助者と、トイレ又はマイクを対応付ける情報をサーバシステム１００に送信する。このようにすれば、サーバシステム１００の処理部１１０において、マイクからの音データがいずれの被介助者に対応するデータであるかを適切に判定できる。
【0082】
また便検知を行うセンシングデバイス４００は、例えばトイレに設置された撮像装置（カメラ）であってもよい。尿や便を撮像した画像を画像解析することで、尿や便の状態を判定するデバイスは、例えば「生体情報提供装置、生体情報提供方法及び生体情報提供プログラム」という２０２０年６月３０日に出願された特願２０２０－１１３３４３号に記載されている。この特許出願は、その全体が本願明細書において参照により援用されている。例えば本実施形態のセンシングデバイス４００は、マイクとカメラの両方を含んでもよい。具体的には、マイクからの音データと、カメラからの画像データを併用することによって、排尿や排便に関する判定が行われる。例えば、撮像画像の明るさが急激に変化した場合、当該撮像画像の信頼度が低いと判定し、音データに基づいて排尿等を判定する等、状況に応じて音データと画像データの併用手法が切り替えられてもよい。
【0083】
あるいは便検知デバイス連携アプリケーションは、マイクから音データを取得してもよい。この場合、便検知デバイス連携アプリケーションは、音データと被介助者を対応付ける処理を行い、当該音データを入力とする識別処理に基づいて、被介助者の排便、排尿、放屁に関する判定処理を実行する。
【0084】
また便検知を行うセンシングデバイス４００はこれに限定されず、ベッド６１０等に設けられるデバイスであってもよい。例えば臭気センサや、液体を検出する静電容量センサ等を用いて尿や便を区分けしつつ検出するデバイスが知られており、本実施形態ではこれらのセンシングデバイス４００が便検知デバイスとして用いられてもよい。
【0085】
＜看取りアプリケーション＞
看取りアプリケーションとは、例えば看取りケアを開始するタイミングを判定するアプリケーションである。看取りケアとは、近い将来に死亡する可能性が高いと考えられる患者に対する介助を表す。看取りケアでは、身体的苦痛や精神的苦痛の緩和、対象の患者にとって尊厳のある生活の支援等が重視される点で、通常の介助とは異なる。
看取りアプリケーションとは、例えば看取りケアを開始するタイミングを判定するアプリケーションである。看取りケアとは、近い将来に死亡する可能性が高いと考えられる患者に対する介助を表す。看取りケアでは、身体的苦痛や精神的苦痛の緩和、対象の患者にとって尊厳のある生活の支援等が重視される点で、通常の介助とは異なる。
【0086】
例えば看取りアプリケーションは、心拍数や呼吸数に関する情報、被介助者の食事量（主菜、副菜、水分等）、体重変化またはＢＭＩ変化、ＡＤＬ（Activities of Daily Living）の変化等に基づいて、看取りケアの開始タイミングを判定してもよい。
【0087】
２．２ アプリケーションの関係例
図１０は、上述した複数のアプリケーションの関係例を示す図である。例えば食事摂取量アプリケーションは、検出した食事に関する情報を看取りアプリケーションとポジショニングアプリケーションに出力する。食事情報は、看取りアプリケーションの入力として利用される。またポジショニングアプリケーションは、食事情報を用いることで食事中のポジション調整に関する処理を実行できる。また食事情報により、被介助者の状況の推移（例えば健康状態の推移等）を判定できるため、食事情報に基づいて、被介助者をポジショニングアプリケーションの使用対象とするか否かが判定されてもよい。
図１０は、上述した複数のアプリケーションの関係例を示す図である。例えば食事摂取量アプリケーションは、検出した食事に関する情報を看取りアプリケーションとポジショニングアプリケーションに出力する。食事情報は、看取りアプリケーションの入力として利用される。またポジショニングアプリケーションは、食事情報を用いることで食事中のポジション調整に関する処理を実行できる。また食事情報により、被介助者の状況の推移（例えば健康状態の推移等）を判定できるため、食事情報に基づいて、被介助者をポジショニングアプリケーションの使用対象とするか否かが判定されてもよい。
【0088】
また通信タグ４７０の出力に基づいて、いじりの検出頻度や、検出場所、時間帯等の情報が求められる。なお通信タグ４７０を読取るリーダとして、被介助者の滞在時間の長い場所（例えば居室）に配置される第１リーダと、それ以外の場所に配置される第２リーダとが用いられてもよい。第１リーダは通常の生活の中での検出処理に用いられ、第２リーダは例えば所与の被介助者がトイレと誤認している場所での検出処理に用いられる。このように、リーダを適切に配置することで、検出場所に応じた処理が可能になる。第１リーダと第２リーダの詳細については、後述する。例えばサーバシステム１００の処理部は、これらの情報に基づいて、いじりが認知症の不穏行動である確からしさ（不穏スコア）を求めてもよい。例えばベッド上でのいじり回数が増加した場合、不穏行動の可能性が高いと判定され、不穏スコアが高くなる。不穏行動が見られる被介助者はベッド６１０や車椅子６３０からの転落、立ち上がり時の転倒等のリスクが大きい。特に、いじりの検出場所がベッドからトイレ以外の場所に移行している場合、トイレと誤認している場所への移動も行われるため、転倒リスクが増大する。従って、不穏スコアは、転落、転倒等に関連するポジショニングアプリケーションや立ち上がり検知アプリケーションに出力されてもよい。また不穏スコアが高い場合、被介助者は部屋の物の位置に敏感となり、不穏行動が発生する可能性がある。よって不穏スコアに基づいて、ポジショニングアプリケーションにおいて物の配置の教師データを取得し、当該教師データに基づいて、物の配置を維持するための介助をサポートする情報が出力されてもよい。例えば不穏スコアが高い場合、ポジショニングアプリケーションを用いて物の配置に関する教師データの取得を行うように、介助者に対するレコメンドが実行されてもよい。
【0089】
またポジショニングアプリケーションが座面センサ４４０や圧力検知が可能なマットレス６２０と連携してもよい点は上述したとおりである。例えば上述した座面センサ連携アプリケーションは、ポジショニングアプリケーションに含まれる。ポジショニングアプリケーションは、検出した姿勢のずれを嚥下ムセ検出アプリケーションに出力してもよい。嚥下ムセ検出アプリケーションは、姿勢のずれを判定することによって誤嚥リスク等を精度よく判定できる。また嚥下ムセ検出アプリケーションは、誤嚥や深刻度の高いムセが発生した場合に、姿勢のずれを表す情報に基づいて原因を判定し、判定結果を介助者に提示する処理を行ってもよい。
【0090】
ポジショニングアプリケーションがベッド６１０またはマットレス６２０の動作制御をしてもよい。起動されると、ポジショニングアプリケーションは教師データの被介助者を特定し、特定された被介助者のベッド６１０またはマットレス６２０の動作制御をしていいか、例えば音声でポジショニングアプリケーションを操作している介助者に伝えてもよい。この介助者からの了解の音声を受けると、ポジショニングアプリケーションはベッド６１０マットレス６２０に動作制御の指示を行う。ポジショニングアプリケーション使用時のベッド６１０マットレス６２０に動作制御の設定はベッド６１０マットレス６２０が記憶していてもよいし、ポジショニングアプリケーションが記憶していてもよい。その結果、介助者はポジショニングアプリケーションを使用時にベッド６１０またはマットレス６２０のリモコンを操作する必要がなくなり利便性が向上する。
【0091】
また、起動されると、ポジションアプリケーションは教師データの被介助者を特定し、特定された被介助者に装着されたウェアラブルセンサを起動してもよい。このウェアラブルセンサは例えばバイタル機器、加速度を搭載したデバイスである。ウェアラブルセンサは、被介助者の姿勢の向きを取得し、例えば所定期間以上、被介助者が左側臥位の姿勢になっているときには、介助者に体位交換の指示をしてもよい。このように、ポジショニングアプリケーションは、ウェアラブルセンサに基づいて被介助者が同じ姿勢を継続していると判定された場合に体位交換を指示できるため、被介助者の褥瘡を防ぐために用いることが可能である。
【0092】
ただし、ポジショニングアプリケーションはあるタイミングでの被介助者のポジションしか判定できず継続的な監視をすることはできない。また、ウェアブルセンサを継続的に動作させることによって被介助者の継続的な監視をすることが可能である。しかし、ウェアラブルセンサを継続的に動作させた場合、当該ウェアラブルセンサは監視が必要でないタイミングでも動作せざるを得ず、電池の交換の頻度が多くなってしまうデメリットがある。その点、ポジショニングアプリケーションをトリガーとしてウェアラブルセンサを動作させることで、当該ウェアラブルセンサを必要なタイミングだけ動作させることができ省電力に動作させることができる。さらにウェアラブルセンサの設定（狭義には動作／非動作のタイミング設定）を個別に行う必要もなく利便性が向上する。
【0093】
なお、以上ではポジショニングアプリケーションが窓口となって、ベッド６１０、マットレス６２０、ウェアラブルセンサの動作制御を行う例を説明したが、これには限定されない。例えばポジショニングアプリケーション以外のアプリケーション（例えば上述した座面センサ連携アプリケーション等の各アプリケーション）がベッド６１０等の動作制御を行ってもよい。つまり、本実施形態で用いられるポジショニングアプリケーション以外のアプリケーションについても、当該アプリケーションが窓口となってベッド６１０等を操作できるため、利便性向上が可能である。また、アプリケーションが動作制御を行う対象の機器はベッド６１０、マットレス６２０及びウェアラブルセンサに限定されず、例えば図１２を用いて後述する各種の機器（カーテン６５０、飲料サーバ６６０等）を含んでもよい。
【0094】
また本実施形態ではベッド６１０において体重測定、呼吸及び心拍の測定、離床判定が可能であってもよい。これらは上述した検出装置４３０を用いて実行されてもよいし、検出装置４３０とは異なるデバイスが用いられてもよい。体重測定結果、及び、呼吸心拍の情報は看取りアプリケーションの入力として用いられる。またベッド６１０での体動の情報は、嚥下ムセ検出アプリケーションに出力されてもよい。例えば嚥下ムセ検出アプリケーションは、体動を考慮することで、ベッド６１０で食事を行う際の誤嚥リスク等を精度よく判定できる。また体動に基づいて被介助者が食事中に眠ってしまっていないかが判定され、嚥下ムセ検出アプリケーションは当該判定結果に基づいた処理を実行することも可能である。例えば被介助者が眠っていると判定された場合、嚥下ムセ検出アプリケーションは声かけの実行を介助者に促してもよい。また図１０には不図示であるが、検出装置４３０は、呼吸、心拍、睡眠、体動等の情報に基づいて不穏スコアを算出してもよい。不穏スコアは、例えば立ち上がり検知アプリケーションに出力される。
【0095】
また便検知デバイスは、便に関する情報を服薬アプリケーションに出力してもよい。便検知デバイス連携アプリケーションは、例えば上述したように、便検知デバイスと被介助者の対応付けに利用される。服薬アプリケーションでは、便に関する情報に基づいて下剤の有無等に関する判定を行ってもよい。便検知デバイスと服薬アプリケーションの連携については図２８を用いて後述する。また図１０では省略されているが、便検知デバイスの出力に基づいて、いじり検出に係る制御が行われてもよい。例えば、通信タグ４７０の読み取りを行うリーダの電源オン／オフが、便検知デバイスの出力に基づいて制御されてもよい。便検知といじりを含めた連携の詳細については、図２６－図２７を用いて後述する。
【0096】
また食事摂取量アプリケーションは、食事情報、特に食事忘れや食べ残しに関する情報を服薬アプリケーションに出力する。服薬アプリケーションでは、食事情報に基づいて、薬を変更する提案等を行ってもよい。また食事摂取量アプリケーションは、例えば嚥下ムセ検出装置４６０の端末装置４６２のカメラを用いて、服薬時の被介助者の撮像画像を取得し、当該撮像画像に基づいて薬の飲み忘れや落薬を判定してもよい。例えば食事摂取量アプリケーションは、料理をのせたお盆の上に薬が残っていないかを判定してもよい。食事摂取量アプリケーションは、お盆に薬が残っている場合、落薬の場合と同様に、薬が適切に服用されていないと判定する。食事摂取量アプリケーションは、判定結果を服薬アプリケーションに出力する。服薬アプリケーションは、飲み忘れや落薬が検出された場合、介助者にその旨を通知してもよい。
【0097】
また立ち上がり検知アプリケーションでは、立ち上がり時の転倒のリスクの高低や、リスク要因等に関するアセスメントである転倒アセスメントを行ってもよい。例えば服薬アプリケーションは、服薬に関する情報を、転倒アセスメントの入力データとして立ち上がり検知アプリケーションに出力してもよい。また、本実施形態では被介助者の体温を検出する体温計が用いられてもよく、体温に関する情報は、転倒アセスメントの入力データとして立ち上がり検知アプリケーションに出力されてもよい。また体温に関する情報は、嚥下ムセ検出アプリケーションに出力されてもよい。例えば嚥下ムセ検出アプリケーションでは、体温を用いることによって被介助者の体調を考慮した判定を行う。例えば、誤嚥発生時には体温が上昇するため、嚥下ムセ検出アプリケーションが温度を考慮した判定を行うことによって、誤嚥の検出精度向上が可能になる。また転倒により内出血等が生じると被介助者の体温が上昇する。そのため、転倒アセスメントに体温を用いることによって、転倒による被介助者への影響（例えば怪我の度合い）等を適切に判定することが可能になる。なおここでは体温を検知する体温計を例示したが、例えば被介助者の皮膚に装着され、当該被介助者の発汗度合いを判定するセンシングデバイス４００が用いられてもよい。発汗に関する情報も、嚥下ムセ検出アプリケーションや転倒アセスメント等に利用が可能である。
【0098】
２．３ アプリケーションが動作する端末装置
以上で説明した各アプリケーションは、例えば介助者が携帯する端末装置２００で動作してもよい。例えば、一人の介助者に一台の端末装置２００が支給され、各介助者は介助業務を行う際に当該端末装置２００を携帯してもよい。あるいは、相対的に少数（例えば一フロアに一台）の端末装置２００が支給され、複数の介助者によって端末装置２００が共有されてもよい。
以上で説明した各アプリケーションは、例えば介助者が携帯する端末装置２００で動作してもよい。例えば、一人の介助者に一台の端末装置２００が支給され、各介助者は介助業務を行う際に当該端末装置２００を携帯してもよい。あるいは、相対的に少数（例えば一フロアに一台）の端末装置２００が支給され、複数の介助者によって端末装置２００が共有されてもよい。
【0099】
そして端末装置２００では、上述したように、アプリケーションの起動において、第１起動処理（被介助者の認証結果を複数のアプリケーションで利用する処理）と、第２起動処理（アプリケーションごとに被介助者の認証処理を実行する処理）のいずれかを選択可能である。即ち、端末装置２００は、本実施形態の手法に係る端末装置として機能する。
【0100】
ただし本実施形態では、他のデバイスにおいて上述したアプリケーションの一部又は前部が動作してもよい。例えば嚥下ムセ検出装置４６０に含まれる端末装置４６２において、アプリケーションが動作してもよい。嚥下ムセ検出装置４６０は、上述したように被介助者の食事の際に用いられるものであるため、端末装置４６２は例えば食堂に配置されるデバイスである。端末装置４６２は、介助者に携帯されなくてもよいため、例えばスマートフォン等に比べて大型のタブレット端末等により実現されてもよい。
【0101】
例えば、端末装置４６２において嚥下ムセ検出アプリケーションが動作することによって、端末装置４６２で撮像された撮像画像を端末装置４６２内で処理できるため、処理の高速化が可能である。また端末装置４６２において服薬アプリケーションが動作することによって、食後の服薬管理をスムーズに実行できる。特に、嚥下ムセ検出アプリケーションを用いた嚥下判定を併用することによって、服薬アプリケーションにおいて、薬を嚥下したか否かを判定することも可能になる。嚥下を用いた服薬管理については変形例において後述する。また端末装置４６２は、配膳された料理を撮像可能な位置にあることが想定されるため、端末装置４６２において食事摂取量アプリケーションが動作してもよい。また端末装置４６２では、食事中あるいは食後の立ち上がりを検知するための立ち上がり検知アプリケーションが動作してもよい。
【0102】
例えば各デバイスには以下のアプリケーションがインストールされ、状況に応じて使い分けが行われてもよい。例えば介助者は、食堂周辺の介助では端末装置４６２を使用し、それ以外の場所での介助では端末装置２００を使用する。ただし、使い分けの例はこれに限定されない。また、以下の記載はデバイスとアプリケーションの対応関係の一例であり、各デバイスについて一部のアプリケーションが省略されてもよいし、他のアプリケーションが追加されてもよい。
端末装置２００（例えばスマートフォン）
・ポジショニングアプリケーション
・嚥下ムセ検出アプリケーション
・食事摂取量アプリケーション
・服薬アプリケーション
・座面センサ連携アプリケーション
・検索アプリケーション
端末装置４６２（例えばタブレット端末）
・嚥下ムセ検出アプリケーション
・食事摂取量アプリケーション
・立ち上がり検知アプリケーション
・服薬アプリケーション
・看取りアプリケーション
端末装置２００（例えばスマートフォン）
・ポジショニングアプリケーション
・嚥下ムセ検出アプリケーション
・食事摂取量アプリケーション
・服薬アプリケーション
・座面センサ連携アプリケーション
・検索アプリケーション
端末装置４６２（例えばタブレット端末）
・嚥下ムセ検出アプリケーション
・食事摂取量アプリケーション
・立ち上がり検知アプリケーション
・服薬アプリケーション
・看取りアプリケーション
【0103】
そして端末装置４６２では、アプリケーションの起動において、第１起動処理が選択できず、第２起動処理のみが選択可能であってもよい。例えば端末装置４６２にインストールされた各アプリケーションは、ホーム画面から起動され、当該アプリケーションの中で被介助者の認証処理が実行される。
【0104】
あるいは端末装置４６２は、アプリケーションの起動において、第１起動処理と、第２起動処理のいずれかを選択可能であってもよい。例えば端末装置４６２は、食事中に嚥下ムセ検出アプリケーションを実行した場合、当該嚥下ムセ検出アプリケーションで用いた認証結果を、食後の服薬管理を行う服薬アプリケーションにおいて利用してもよい。このようにすれば、特定の被介助者に対して連続して介助を行う際に介助者の操作負担の軽減が可能になる。
【0105】
以上の説明から分かるように、端末装置４６２は、本実施形態に係る端末装置として機能してもよいし、機能しなくてもよい。
【0106】
３．処理の詳細
次に介護施設等における具体的なケアの流れに基づいて、アプリケーションのユースケースの例について説明する。なお、以下の説明はユースケースの一例であり、各場面で使用されるアプリケーションの一部が省略されてもよいし、他のアプリケーションが追加されてもよい。
次に介護施設等における具体的なケアの流れに基づいて、アプリケーションのユースケースの例について説明する。なお、以下の説明はユースケースの一例であり、各場面で使用されるアプリケーションの一部が省略されてもよいし、他のアプリケーションが追加されてもよい。
【0107】
３．１ ユースケース１（起床時）
図１１は、被介助者の起床時に実行される介助の流れ、及び、アプリケーション等の利用例を説明する図である。起床時の介助は、被介助者の居室で行われることが想定される。例えば個室であれば、居室内には対象の被介助者以外の被介助者はいないため、ここでの介助は特定の被介助者に対してのみ実行される。
図１１は、被介助者の起床時に実行される介助の流れ、及び、アプリケーション等の利用例を説明する図である。起床時の介助は、被介助者の居室で行われることが想定される。例えば個室であれば、居室内には対象の被介助者以外の被介助者はいないため、ここでの介助は特定の被介助者に対してのみ実行される。
【0108】
図１１に示すように、起床時の介助の例は、起床、着替え、整髪、顔拭、飲み物提供を行った後、起床時の服薬管理、バイタル情報の測定、トイレへの誘導が順次行われる。以下、具体的な流れについて説明する。
【0109】
介助者はまず、被介助者の起床、着替え、整髪、顔拭、飲み物提供を行う。例えば介助者は居室のカーテンを開ける作業、着替え等に適した状態となるようにベッド６１０の高さや背もたれの角度を調整する作業、被介助者の嚥下能力に応じたトロミの飲料を用意する作業を実行する。これらの作業は介助者が直接行ってもよいが、これには限定されない。
【0110】
図１２は、被介助者の居室の例を示す図である。図１２に示すように、居室には被介助者が就寝等に用いるベッド６１０、移動に用いられる車椅子６３０、カーテン６５０、トロミ飲料を提供する飲料サーバ６６０等が配置される。また居室にはユーザ（介助者）の音声認識を行い、音声認識結果に基づいて各機器を制御する通信装置６４０が配置されてもよい。また居室にはアロマディフューザー６７０や照明６８０が配置されてもよい。また居室に配置されるものは図１２の例に限定されず、一部が共有スペースに配置されてもよいし、他の物品が配置されてもよい。例えば車椅子６３０は、使用されない時間帯は居室外の保管場所に保管されてもよい。また飲料サーバ６６０は食堂や休憩室等の共有スペースに配置されてもよい。
【0111】
居室に配置されたベッド６１０等の操作は、例えば通信装置６４０を用いた音声認識によって行われてもよい。例えばベッド６１０、車椅子６３０、カーテン６５０（カーテン６５０を開閉させる駆動機構）、飲料サーバ６６０、アロマディフューザー６７０、照明６８０はそれぞれネットワークに接続されており、いわゆるスマートホームの例と同様に、外部機器からの操作信号に基づく動作が可能である。また通信機器６４０には、音声を受信するマイクが設けられるとともに、音声認識及び音声認識結果に基づいてデバイスに制御信号を送信するスマートホームアプリケーションがインストールされる。例えば、暗黙知を用いない処理については、上記の通り通信装置６４０が用いられ、暗黙知を用いた処理については、端末装置２００にインストールされたアプリケーションが用いられてもよい。
【0112】
例えば介助者は通信機器６４０に向かって「カーテン開けて」というコマンドを含む音声を発する。なおここでは省略しているが、コマンドの前に特定のホットワードの認識処理が実行されてもよい。通信機器６４０は、スマートホームアプリケーションに従って音声認識処理を行うことによって、当該音声がカーテン６５０に対する動作指示であることを認識する。端末装置２００は、ネットワークを介してカーテン６５０に制御信号を送信し、カーテン６５０は当該制御信号に従って、開く動作を実行する。なお、ここでは通信機器６４０を用いる例を示したが、端末装置２００にスマートホームアプリケーションがインストールされ、端末装置２００のマイクを用いて音声認識が行われてもよい。
【0113】
同様に介助者は、「着替えの高さにベッドを上げて」等の音声により、ベッド６１０の高さ等を調整する。また介助者は「トロミ３用意して」等の音声により、飲料サーバ６６０に対して所定のトロミの飲料の用意を指示する。このように、デバイスへの指示を音声認識により実行することによって、介助者の負担軽減が可能になる。例えば介助者は被介助者の着替えや、飲料を飲ませる作業に集中することが可能になる。
【0114】
また介助者は、音声を用いてアロマディフューザー６７０や照明６８０の制御を行ってもよい。例えば通信機器６４０は、対応するキーワードが認識された場合に、アロマディフューザー６７０のオン／オフや、照明６８０のオン／オフを制御してもよい。なおこれらの機器が複数の動作モードを有する場合（例えば風量や照度の細かい調整が可能である場合等）、通信機器６４０はユーザ音声に基づいて、具体的な動作モードを決定する制御を行ってもよい。なお、図１２では、照明６８０として、棚の上に配置される小型の照明とシーリングライトの両方を例示したが、何れか一方が省略されてもよい。また照明６８０として他の態様の照明が用いられてもよい。
【0115】
図１１に戻って説明を続ける。着替え等が完了した場合、次に起床時の服薬管理が行われる。まず介助者は、準備として「服薬用にベッドを背上げして」等の音声により、ベッド６１０のボトム角度を服薬に適した角度に調整する。
【0116】
次に介助者は、被介助者の服薬管理を行うために服薬アプリケーションを利用する。なお図１１の例からも分かるように、起床時のユースケースでは、服薬アプリケーションを用いた服薬管理の後にも、同じ被介助者を対象として、アプリケーションを利用した種々の介助が実行されることが分かっている。例えば介助者は、服薬管理の後、バイタルアプリケーションを用いたバイタル記録、座面センサ連携アプリケーションを用いた車椅子６３０の移乗・移動介助、便検知デバイス連携アプリケーションを用いた便検知等を順次実行する。
【0117】
従って、図１１に示すユースケースにおいては、予め認証処理を行いその結果を複数のアプリケーションで共有する処理が好適である。図１３は、当該ユースケースにおける端末装置２００の処理を説明するフローチャートである。
【0118】
まずステップＳ１０１において、処理部２１０は、介助者の操作に基づいて検索アプリケーションを起動する。検索アプリケーションとは被介助者に適したアプリケーションを検索、提示するアプリケーションである。例えば端末装置２００の表示部２４０に表示されるホーム画面やアプリケーション一覧画面に検索アプリケーションのアイコンが含まれ、当該アイコンの選択操作が行われた場合に、検索アプリケーションが起動される。
【0119】
ステップＳ１０２において、処理部２１０は、検索アプリケーションに従って動作することによって、被介助者の認証処理を行う。被介助者の認証処理は、例えば画像処理に基づいて実行されてもよい。例えば以下で説明するように、ここでの画像処理は、被介助者の顔認証処理であってもよいし、ＯＣＲ処理であってもよいし、ＱＲコードの読取り処理であってもよい。例えば、介助者の操作に基づいて、いずれの画像処理が行われるかが切り替え可能であってもよい。
【0120】
図１４Ａは、端末装置２００の表示部２４０に表示される画面例であって、ステップＳ１０２の処理を説明する図である。図１４Ａに示すように、被介助者の認証処理では、被介助者の顔を用いた顔認証が行われてもよい。例えば介助者は、端末装置２００の撮像部２６０を用いて被介助者の顔を撮像する。処理部２１０は、撮像画像と、記憶部２２０に記憶されたテンプレートデータとの比較処理に基づいて、被介助者を特定する。なお顔認証に機械学習が用いられてもよい。図１４Ａに示すように、表示部２４０は、認証結果である被介助者の氏名を表示してもよい。図１４Ａでは、顔認証に基づき、被介助者が「ＸＸＸＸ」という氏名であることが認識されている。
【0121】
なお認証処理は、被介助者の氏名が印刷されたラベルを撮像することによって行われてもよい。処理部２１０は、ラベルに記載された文字のＯＣＲ処理に基づいて被介助者を特定する。あるいはラベルには被介助者に関する情報を含むＱＲコード（登録商標）等のコードが印刷されてもよい。処理部２１０は、コードの認識処理に基づいて被介助者を特定する。
【0122】
認証処理の完了後、ステップＳ１０３において、処理部２１０は、検索アプリケーションに従って動作することによって、特定された被介助者に関連するアプリケーションの検索処理を行う。例えば記憶部２２０は、端末装置２００にインストールされたアプリケーションと、各アプリケーションを利用可能な被介助者と、を対応付けた情報を記憶してもよい。なお、ここでのアプリケーションは、１人の被介助者専用であってもよいがこれに限定されず、複数の被介助者による併用が可能であってもよい。即ち、１つのアプリケーションが複数の被介助者に対応付けられてもよい。処理部２１０は、当該情報とステップＳ１０２での認証結果に基づいて、被介助者に関係するアプリケーションを決定する。なお検索処理については種々の変形実施が可能であり、詳細については後述する。
【0123】
ステップＳ１０４において、処理部２１０は、検索アプリケーションに従って動作することによって、被介助者に関連するアプリケーションの提示処理を行う。図１４Ｂは、端末装置２００の表示部２４０に表示される画面例であって、ステップＳ１０４の処理を説明する図である。例えば表示部２４０は、被介助者に関連するアプリケーションを表す１または複数のアイコンを並べて表示してもよい。なお図１４Ｂでは、３つのアイコンが、図１４Ａに示した画面に重畳表示される例を示したが、これには限定されず、図１４Ａの画面が消去された上で、異なる画面において検索結果が表示されてもよい。
【0124】
以上のように、端末装置２００の記憶部２２０は、ポジショニングアプリケーション等の介助に係るアプリケーションに加えて、さらに検索アプリケーションを記憶してもよい。処理部２１０は、検索アプリケーションに従って動作することによって、被介助者の認証処理（ステップＳ１０２）、認証された被介助者に関連するアプリケーションを記憶部２２０から検索する処理（ステップＳ１０３）、及び、検索結果を提示する処理（ステップＳ１０４）を実行する。具体的には、検索アプリケーションは、第１アプリケーション及び第２アプリケーションを含む複数のアプリケーションから、被介助者に関連するアプリケーションを検索する。このようにすれば、複数のアプリケーションを使用する前に予め認証処理を済ませておくことが可能になる。さらに、認証結果に基づいて自動的に提示されるアプリケーションが検索されるため、例えば端末装置２００に多数のアプリケーションがインストールされている場合であっても、アプリケーション選択に係る介助者の負担を軽減することが可能になる。
【0125】
ステップＳ１０５において、処理部２１０は、検索アプリケーションに従って動作することによって、検索結果の何れかのアプリケーションが選択されたかを判定する。いずれのアプリケーションも選択されない場合（ステップＳ１０５：Ｎｏ）、再度、ステップＳ１０５の処理が実行される。即ち、処理部２１０は、何れかのアプリケーションが選択されるまで待機する。
【0126】
図１４Ｂの画面において何れかのアプリケーションが選択された場合（ステップＳ１０５：Ｙｅｓ）、ステップＳ１０６において処理部２１０は、選択されたアプリケーションを実行する。図１１の例であれば、まず服薬管理が行われるため、服薬アプリケーションが選択される。
【0127】
図１５は、ステップＳ１０６の処理の一例であって、服薬アプリケーションの処理を説明するフローチャートである。ステップＳ２０１において、服薬アプリケーションは薬の認識処理を実行する。具体的には、服薬アプリケーションは、薬のラベルを撮像した撮像画像に基づいて、薬が処方された被介助者や、服薬タイミングを特定する。
【0128】
ステップＳ２０２において、服薬アプリケーションは判定処理を行う。例えば服薬アプリケーションは、ステップＳ１０２において認証された被介助者と、ステップＳ２０１において取得された薬が処方された被介助者が一致するか否かを判定する。また服薬アプリケーションは、現在時刻が、ステップＳ２０１において取得された服用タイミングに合致するかを判定する。
【0129】
ステップＳ２０３において、判定に問題があったかを判定する。例えば服薬アプリケーションは、被介助者が一致しない、及び、現在時刻が服薬タイミングと合わない、の少なくとも一方の場合に、問題があると判定する。問題ありと判定された場合（ステップＳ２０３：Ｙｅｓ）、ステップＳ２０４においてその旨を介助者に通知する処理が行われる。問題なしと判定された場合（ステップＳ２０４：Ｎｏ）、例えば服薬アプリケーションの処理が終了する。
【0130】
図１４Ｃは、端末装置２００の表示部２４０に表示される画面例であって、ステップＳ２０１（服薬アプリケーションが選択された場合のステップＳ１０６）の処理を説明する図である。図１４Ｃの例では、薬のラベルを撮像した撮像画像に基づいてＯＣＲ処理が行われることによって、被介助者の氏名を表す文字列である「ＸＸＸＸ」、及び、服薬タイミングを表す文字列である「朝食後」が検出されている。検出された内容で問題がない場合（ステップＳ２０４：Ｎｏ）、図１４Ｄに示すように、問題がない旨の表示が行われ、服薬アプリケーションに関する処理が終了する。なお、図１４Ｃに示す画面から図１４Ｄに示す画面への遷移は、介助者の操作によって行われてもよいし、自動で行われてもよい。例えば、判定処理に問題がない場合、介助者の操作を省略して自動的に画面を遷移させることによって、操作負担の軽減が可能である。
【0131】
図１４Ｅは、端末装置２００の表示部２４０に表示される画面例であって、ステップＳ１０６の処理後に行われるステップＳ１０４の処理において表示される画面例である。例えば表示部２４０は、ステップＳ１０６の処理終了時の画面（図１４Ｄ）に対して、被介助者に関係するアプリケーションの検索結果を重畳表示してもよい。このようにすれば、所与のアプリケーション終了時に、速やかに他のアプリケーションを選択させることが可能になる。ただし、１つのアプリケーションが終了した際に、当該アプリケーションに関する画面を消去した上で、検索結果を表示する画面への遷移が行われてもよく、具体的な画面は図１４Ｅの例に限定されない。また図１４Ｄに示す画面から図１４Ｅに示す画面への遷移（服薬アプリケーションの終了判定）は、介助者の操作によって行われてもよいし、自動で行われてもよい。例えば、判定処理に問題がない場合、介助者の操作を省略して自動的に画面を遷移させることによって、操作負担の軽減が可能である。
【0132】
なお、介助者により検索アプリケーションを終了する操作が行われた場合、割り込み処理によって図１５に示す処理が終了する。例えば図１４Ｂ及び図１４Ｅに示したように、検索結果の表示画面（ステップＳ１０４）では、検索アプリケーションを終了するためのオブジェクトが表示されてもよい。図１４Ｂ及び図１４Ｅでは、「Finish smart search」という文字列を表示する例を示している。
【0133】
検索アプリケーションを終了する操作が行われない場合、ステップＳ１０４～Ｓ１０６の処理が繰り返される。図１１に示すユースケースの例であれば、服薬アプリケーションを用いた服薬管理の後には、バイタルアプリケーションを用いたバイタル記録が行われる。従って介助者は、図１４Ｅの画面に相当する画面において、バイタルアプリケーション（図１４Ｅには不図示）を選択する操作を実行する。これにより、ステップＳ１０６において、バイタルアプリケーションに従った処理が実行される。
【0134】
ここでのバイタルアプリケーションは、例えばＮＦＣを用いてバイタル記録機器からの情報を取得するアプリケーションである。例えば、介助者はＮＦＣ対応の体温計を保持しており、当該体温計を用いて被介助者の体温を測定した後、当該体温計を端末装置２００のＮＦＣ読取り部に近づける。バイタルアプリケーションは、読取り結果に基づいて、被介助者の体温、測定時刻等の情報を記憶する。なおバイタル記録機器は温度計に限定されず、血圧計や血中酸素飽和度の計測器等を含んでもよい。
【0135】
この際、図１３のステップＳ１０２に示したように、被介助者の認証処理は既に完了している。従って、バイタルアプリケーションは、バイタル情報と被介助者を対応付ける際に、改めて被介助者の認証処理を行う必要がない。具体的には、バイタルアプリケーションは、ステップＳ１０２の認証結果を取得し、当該認証結果により特定される被介助者と、ＮＦＣ経由で取得されたバイタル情報を対応付ける処理を行う。
【0136】
これ以降も同様である。図１１に示すユースケースの例であれば、バイタル記録の後には、被介助者を離床させ、トイレへ誘導する介助が行われる。従って被介助者は、まず音声認識によりベッド６１０を端座位に適した高さ、角度に調整するとともに、車椅子６３０をロックすることによって移乗時の転倒を抑制する。なお、車椅子６３０が自動走行可能である場合、音声認識に基づいて車椅子６３０をベッド６１０に近づける操作が行われてもよい。
【0137】
そして介助者は、被介助者に関係するアプリケーションの検索結果表示画面において、座面センサ連携アプリケーションを選択する操作を行う。処理部２１０は、図１３のステップＳ１０６において、座面センサ連携アプリケーションに従った処理を実行する。例えば座面センサ連携アプリケーションは、上述したように、座面センサ４４０から圧力値を取得し、当該圧力値に基づいて前ずれや横ずれの判定、転倒や転落の可能性等を判定する。これにより、ベッド６１０から車椅子６３０への移乗時、及び居室からトイレまでの移動時の転倒又は転落を抑制することが可能になる。この際、座面センサ連携アプリケーションは、ステップＳ１０２での被介助者の認証結果を用いるため、対象の被介助者に適した判定、例えば被介助者のＡＤＬ、不穏スコア、姿勢の特徴等を考慮した判定を実行できる。
【0138】
なお、座面センサ連携アプリケーションは、座面センサ４４０に対して、対象の被介助者に関する情報を送信する処理を行うものであって、前ずれや転倒等の判定は、座面センサ４４０の制御ボックス４４２で実行されてもよい。例えば座面センサ連携アプリケーションは、座面センサ４４０からデバイスタイプを取得することによって、対象の座面センサ４４０が座面センサ連携アプリケーションに対応したデバイスであるかを判定してもよい。また座面センサ連携アプリケーションは、被介助者を特定する情報、及び、当該被介助者に対応する暗黙知（アルゴリズム）を特定する情報を、座面センサ４４０に送信する。座面センサ４４０は、被介助者に適した暗黙知に従った処理を実行し、処理結果を被介助者と対応付けてサーバシステム１００に送信する。また制御ボックス４４２に発光部等の報知部が設けられ、異常検出時には当該報知部を用いた報知が行われてもよい。このようにしても、対象の被介助者に応じて、適切に前ずれや転倒等の判定を行うことが可能になる。
【0139】
なお、座面センサ４４０は複数の被介助者で共有されることが想定されるため、対象の被介助者に適したアルゴリズムがインストール済みでない可能性がある。例えば座面センサ４４０は、端末装置２００から通知された暗黙知（アルゴリズム）がインストール済みかを判定し、未インストールの場合、サーバシステム１００にアルゴリズムの取得要求を送信してもよい。この際、端末装置２００から取得した被介助者を特定する情報もあわせて送信してもよい。サーバシステム１００は、データの送信元である座面センサ４４０と、当該座面センサ４４０からの情報によって特定される被介助者を対応付けて登録する。このようにすれば、サーバシステム１００は、座面センサ４４０の利用時に、被介助者と座面センサ４４０の対応関係を適切に更新することが可能になる。
【0140】
さらに介助者は、被介助者に関係するアプリケーションの検索結果表示画面において、便検知デバイス連携アプリケーションを選択する操作を行う。処理部２１０は、図１３のステップＳ１０６において、便検知デバイス連携アプリケーションに従った処理を実行する。例えば便検知デバイス連携アプリケーションは、上述したように、場所を認識する処理を行い、認識された場所（トイレ）と、被介助者の対応付けをサーバシステム１００に要求する処理を実行する。この際、ステップＳ１０２での被介助者の認証結果を用いることが可能であるため、改めて被介助者の認証処理を行う必要が無い。例えばサーバシステム１００の処理部１１０は、便検知デバイス連携アプリケーションからの情報に基づいて、どのトイレの音声データが、いずれの被介助者のデータであるかを判定できる。従って処理部１１０は、被介助者の排泄に関する情報を適切に管理することが可能になる。
【0141】
以上で説明したように、記憶部２２０は、センシングデバイス４００を用いた介助に関する第４アプリケーションを記憶してもよい。第４アプリケーションは、座面センサ連携アプリケーションであってもよいし、バイタルアプリケーションであってもよいし、便検知デバイス連携アプリケーションであってもよい。
【0142】
そして処理部２１０は、第４アプリケーションに従って動作することによって、認証処理で認証された被介助者と、センシングデバイス４００の出力であるセンシング結果を対応付ける処理を行ってもよい。例えば、バイタルアプリケーションにおいて説明したように、第４アプリケーションはセンシングデバイス４００からセンシング結果を取得し、当該センシング結果に、認証結果である被介助者の情報を対応付ける処理を行う。あるいは座面センサ連携アプリケーションのように、第４アプリケーションは、センシング結果に基づいて何らかの判定処理を行い、判定結果と被介助者を対応付けてサーバシステム１００に送信してもよい。
【0143】
あるいは処理部２１０は、第４アプリケーションに従って、認証処理の結果をサーバシステム１００に送信することによって、センシング結果と被介助者との対応付けを要求する処理を行ってもよい。この場合の第４アプリケーションは、例えば便検知デバイス連携アプリケーションである。このようにすれば、アプリケーション内では被介助者とセンシングデバイス４００のセンシング結果を直接的には対応付けないものの、対応付けに必要な情報を適切に、且つ、介助者の操作負担を抑制しつつサーバシステム１００に提供できる。
【0144】
３．２ ユースケース２（食堂）
図１６Ａ、図１６Ｂは、食堂における介助の流れ、及び、アプリケーション等の利用例を説明する図である。なお被介助者のＡＤＬに応じて食堂での介助の流れが異なるため、ここではユースケース２Ａ（図１６Ａ）と、ユースケース２Ｂ（図１６Ｂ）の２つを例示している。以下、それぞれについて説明する。
図１６Ａ、図１６Ｂは、食堂における介助の流れ、及び、アプリケーション等の利用例を説明する図である。なお被介助者のＡＤＬに応じて食堂での介助の流れが異なるため、ここではユースケース２Ａ（図１６Ａ）と、ユースケース２Ｂ（図１６Ｂ）の２つを例示している。以下、それぞれについて説明する。
【0145】
＜ユースケース２Ａ＞
図１６Ａに示したユースケース２Ａは、ＡＤＬが相対的に低い被介助者を対象とした介助の流れであり、配膳、食事、服薬管理、下膳、摂取量管理、口腔ケア、オムツ交換、臥床の順に介助が実行される。ＡＤＬが低い被介助者は、誤嚥リスクが高い、不穏行動が見られる等の可能性があるため、手厚い介助が必要となる。なお以上の介助は一人の介助者によって実行されるものには限定されず、複数の介助者によって分担されてもよい。例えば第１介助者が配膳を担当し、第２介助者が食事以降の介助を担当してもよい。例えばシフトの切り替わりタイミングにおいて、前のシフト担当者（例えば夜勤担当）が配膳を担当し、後のシフト担当者（例えば日勤担当）がその間に図１１に示した居室での介助を行った上で、食事以降の食堂での介助を引き継ぐといった態様が考えられる。
図１６Ａに示したユースケース２Ａは、ＡＤＬが相対的に低い被介助者を対象とした介助の流れであり、配膳、食事、服薬管理、下膳、摂取量管理、口腔ケア、オムツ交換、臥床の順に介助が実行される。ＡＤＬが低い被介助者は、誤嚥リスクが高い、不穏行動が見られる等の可能性があるため、手厚い介助が必要となる。なお以上の介助は一人の介助者によって実行されるものには限定されず、複数の介助者によって分担されてもよい。例えば第１介助者が配膳を担当し、第２介助者が食事以降の介助を担当してもよい。例えばシフトの切り替わりタイミングにおいて、前のシフト担当者（例えば夜勤担当）が配膳を担当し、後のシフト担当者（例えば日勤担当）がその間に図１１に示した居室での介助を行った上で、食事以降の食堂での介助を引き継ぐといった態様が考えられる。
【0146】
例えば、配膳・食事の場面では、まず介助者は音声認識を用いて、自動走行が可能な配膳カートを操作する。さらに嚥下ムセ検出アプリケーションを用いて嚥下状況の確認や誤嚥リスクの判定が行われる。またポジショニングアプリケーションや座面センサ連携アプリケーションを用いて食事中の姿勢が判定される。なおここでは、画像や圧力センサ等の情報に基づいて、被介助者が眠ってしまっていないかが判定されてもよい。例えばこれらのアプリケーションに基づいて、誤嚥が生じにくい姿勢をとらせる等の介助が実行されてもよい。
【0147】
また服薬の場面では、服薬アプリケーションを用いて服薬管理が行われる。この際、後述するように、嚥下ムセ検出装置４６０を用いた薬の嚥下判定や、落薬の判定等が行われてもよい。
【0148】
また下膳の場面では、介助者は音声認識を用いて、自動走行が可能な配膳カートを操作することによって、食器等の後片付けを行ってもよい。また図１６Ａでは不図示であるが、この際に食事摂取量アプリケーションを用いて、被介助者による食事（主菜、副菜）や水分の摂取量が判定されてもよい。
【0149】
また口腔ケアの場面では、嚥下ムセ検出アプリケーションを用いて口周辺の画像判定を行うことによって、適切なケアをサポートすることが可能である。
【0150】
さらに、オムツ交換の場面では、ポジショニングアプリケーションを用いて、オムツ交換をサポートする処理が行われる。例えばオムツ交換に適した姿勢、オムツの位置、オムツ交換後の装着状態等に関するサポートが行われてもよい。またオムツ交換後に、ポジショニングアプリケーションを用いて被介助者のベッドポジション（臥床状態での体位）の調整が行わる。なお、オムツ交換とベッドポジション調整の両方にポジショニングアプリケーションを利用することは必須ではなく、一方、あるいは両方が省略されてもよい。
【0151】
また図１６Ａには不図示であるが、臥床状態に移行した後は、ベッド６１０からの転倒、転落に関するアプリケーションが用いられてもよい。ここでのアプリケーションは、例えば上述した立ち上がり検知アプリケーションであってもよいし、他のアプリケーションであってもよい。使用されるセンシングデバイス４００は、検出装置４３０であってもよいし、被介助者の周辺に配置されるカメラであってもよい。
【0152】
以上のように、ＡＤＬが低い介助者は手厚い介助が必要となるため、介助者が担当する被介助者の人数は相対的に少なくなり、例えば被介助者は一人であってもよい。従ってユースケース２Ａでは、図１１に示したユースケースと同様に、所定の被介助者を対象として、異なる介助が連続して実行されることが想定される。よって端末装置２００は、図１３を用いて上述した処理と同様の処理を行ってもよい。
【0153】
例えばユースケース２Ａに示した全てのアプリケーションが端末装置２００で実行される場合、まず検索アプリケーションが起動され（ステップＳ１０１）、当該検索アプリケーションの中で被介助者の認証処理が実行される（ステップＳ１０２，図１４Ａ）。そして認証結果に基づく検索処理が実行され（ステップＳ１０３）、検索結果が提示される（ステップＳ１０４、図１４Ｂ）。介助者は、検索結果から嚥下ムセ検出アプリケーション、座面センサ連携アプリケーション、ポジショニングアプリケーション（食事用）、服薬アプリケーション、嚥下ムセ検出アプリケーション、ポジショニングアプリケーション（オムツ交換用）を順次選択、実行する（ステップＳ１０６）。これにより、被介助者の認証結果を維持したまま、種々のアプリケーションを実行できるため、認証に係る介助者の負担軽減が可能である。
【0154】
なお、以上では端末装置２００において各アプリケーションが実行される例を示したがこれには限定されない。例えば、嚥下に関連する嚥下ムセ検出アプリケーション及び服薬アプリケーションは、嚥下ムセ検出装置４６０の端末装置４６２において実行されてもよい。例えば、端末装置２００は、検索アプリケーションの検索結果に基づいて、座面センサ連携アプリケーション、ポジショニングアプリケーション（食事用）、ポジショニングアプリケーション（オムツ交換用）を順次実行する。この場合であっても、端末装置２００で動作する複数のアプリケーションにおいて認証結果を引き継げるため、操作負担の軽減が可能である点は同様である。
【0155】
また端末装置４６２は、嚥下ムセ検出アプリケーション、服薬アプリケーションを記憶し、これらに従った処理を実行してもよい。例えば、端末装置４６２は、本実施形態の端末装置２００と同様に、被介助者の認証結果を維持してもよい。例えば端末装置４６２は、服薬アプリケーションの実行時に、嚥下ムセ検出アプリケーションで使用した認証結果を流用してもよい。また端末装置４６２における各アプリケーションは自動で起動されてもよい。例えば食事が終わったことが嚥下アプリケーションで検出された場合、服薬アプリケーションが自動で起動されてもよい。同様に、服薬アプリケーションにおいて服薬完了が検出された場合、あるいは、口腔ケアに必要な備品を検知された場合、嚥下ムセ検出アプリケーションが自動的に再起動されてもよい。
【0156】
ただし、端末装置４６２は、被介助者の認証結果を維持する処理を実行しなくてもよい。例えば嚥下ムセ検出アプリケーションや服薬アプリケーションでは、各アプリケーションの起動ごとに被介助者の認証処理が実行されてもよい。
【0157】
＜ユースケース２Ｂ＞
図１６Ｂに示すユースケース２Ｂは、ＡＤＬが相対的に高い被介助者を対象とした介助の流れであり、配膳、食事、服薬管理、下膳、摂取量管理、口腔ケア、トイレ誘導、リビングの順に介助が実行される。なおユースケース２Ａと同様に、以上の介助は一人の介助者によって実行されるものには限定されず、複数の介助者によって分担されてもよい。例えば第１介助者が配膳を担当し、第２介助者が食事以降の介助を担当してもよい。
図１６Ｂに示すユースケース２Ｂは、ＡＤＬが相対的に高い被介助者を対象とした介助の流れであり、配膳、食事、服薬管理、下膳、摂取量管理、口腔ケア、トイレ誘導、リビングの順に介助が実行される。なおユースケース２Ａと同様に、以上の介助は一人の介助者によって実行されるものには限定されず、複数の介助者によって分担されてもよい。例えば第１介助者が配膳を担当し、第２介助者が食事以降の介助を担当してもよい。
【0158】
ＡＤＬが高い被介助者は、介助なしに実行可能な行動も多いため、ユースケース２Ａに比べて手厚い介助は不要である。また介護施設等において、ＡＤＬが高い被介助者の数は相対的に多いと考えられる。従って介助者は多数（例えば数十人）の被介助者を担当することが想定される。
【0159】
例えば、配膳・食事の場面では、ユースケース２Ａと同様に、介助者は音声認識を用いて、自動走行が可能な配膳カートを操作する。ＡＤＬの高い介助者は、誤嚥リスク等が低く、食事に適した姿勢を自力でとることが可能である蓋然性が高いため、嚥下ムセ検出アプリケーションやポジショニングアプリケーションは使用されなくてもよい。
【0160】
また服薬の場面では、服薬アプリケーションを用いて服薬管理が行われる。例えば、介助者は、服薬アプリケーションを用いて薬の確認を行うが、具体的な嚥下等については被介助者に任せてもよい。例えば介助者は、数十人の被介助者を対象として、それぞれの薬が適切であるかを服薬アプリケーションで確認する。この場合、対象の被介助者が頻繁に変化するため、図１３を用いて上述した認証結果を維持する処理の必要性が低い。従って端末装置２００は、図１３とは異なる処理を行ってもよい。
【0161】
図１７は、この場合の端末装置２００の処理を説明するフローチャートである。まずステップＳ３０１において、処理部２１０は、表示部２４０にアプリケーション一覧画面を表示する処理を行う。ここでのアプリケーションは、例えば端末装置２００にインストールされた全アプリケーションであってもよい。あるいは、処理部２１０は、ステップＳ３０１において、端末装置２００のホーム画面を表示してもよい。この場合、予め介助者によってホーム画面上に配置されたアプリケーションが表示される。
【0162】
図１８Ａは、図１７のステップＳ３０１において端末装置２００の表示部２４０に表示される画面の例である。図１８Ａに示すように、表示部２４０は、複数のアプリケーションのアイコンを並べて表示してもよい。また複数のアイコンがグループ化され、当該グループが表示されてもよい。図１８Ａの例では、被介助者ごとに作成される複数のポジショニングアプリケーションが、「ポジション１Ｆ」、「ポジション２Ｆ」、「ポジション３Ｆ」の３つのフォルダに分けて管理されている。また図１８Ａでは、服薬アプリケーション、食事摂取量アプリケーション、嚥下ムセ検出アプリケーション、看取りアプリケーション（ケア予測アプリケーション）、いじり検出アプリケーション、座面センサ連携アプリケーションに対応する各アイコンが表示される例を示している。
【0163】
ステップＳ３０２において、処理部２１０は、何れかのアプリケーションが選択されたかを判定する。いずれのアプリケーションも選択されない場合（ステップＳ３０２：Ｎｏ）、再度、ステップＳ３０２の処理が実行される。即ち、処理部２１０は、何れかのアプリケーションが選択されるまで待機する。
【0164】
何れかのアプリケーションが選択された場合（ステップＳ３０２：Ｙｅｓ）、ステップＳ３０３及びステップＳ３０４において、処理部２１０は、選択されたアプリケーションを実行する。ただし、この場合には被介助者の認証処理が済んでいないため、例えば処理部２１０は、ステップＳ３０３において、選択されたアプリケーションの処理として被介助者の認証処理を行い、ステップＳ３０４において、認証結果に基づく具体的な処理を実行する。
【0165】
図１６Ｂに示したユースケース２Ｂの例であれば、まず服薬管理が行われるため、ステップＳ３０２において服薬アプリケーションが選択される。
【0166】
図１９は、ステップＳ３０３－Ｓ３０４の処理の一例であって、服薬アプリケーションの処理を説明するフローチャートである。ステップＳ４０１において、服薬アプリケーションは対象となる被介助者の認証処理を行う。
【0167】
図１８Ｂは、ステップＳ４０１における処理を説明する図である。例えば処理部２１０は、被介助者の氏名が記載されたタグに対するＯＣＲ処理に基づいて、認証処理を行ってもよい。図１８Ｂの例であれば、部屋番号や食事内容に関する文字列とともに、「ＹＹＹＹ」という氏名が検出される。処理部２１０は、文字列の内容（例えば敬称の表示位置）等に基づいて、検出された文字列から被介助者の氏名を特定する。なお、図１１のステップＳ１０２に関して上述したように、被介助者の認識処理は、顔認識処理が用いられてもよいし、ＱＲコードが用いられてもよい。
【0168】
ステップＳ４０２－Ｓ４０５については、図１５のステップＳ２０１－Ｓ２０４と同様である。具体的には、処理部２１０はステップＳ４０２において、薬の認識処理を実行し、ステップＳ４０３において判定処理を行う。なお、図１８Ｃに認識処理に関する表示画面例を示したが、これは図１４Ｃと同様である。また処理部２１０は、ステップＳ４０４において、判定に問題があったかを判定する。問題ありと判定された場合（ステップＳ４０４：Ｙｅｓ）、ステップＳ４０５においてその旨を介助者に通知する処理が行われる。
【0169】
問題なしと判定された場合（ステップＳ４０４：Ｎｏ）、ステップＳ４０６において、処理部２１０は、服薬が完了したかを判定する。例えば問題なしと判定された場合、処理部２１０は、図１８Ｄに示す画面を表示する処理を行ってもよい。図１８Ｄに示す画面は、問題ないことを表す文字列（「ＯＫ」）とともに、異なる被介助者を対象として服薬管理を継続するための第１ボタンと、服薬管理を終了するための第２ボタンが含まれる。例えば、第１ボタンは「次の方へ」との文字列が付与された表示オブジェクトであり、第２ボタンは「服薬完了」との文字列が付与された表示オブジェクトである。処理部２１０は、第２ボタンの選択操作が行われた場合、服薬完了と判定し（ステップＳ４０６：Ｙｅｓ）、服薬アプリケーションの処理を終了する。
【0170】
一方、第１ボタンの選択操作が行われた場合、処理部２１０は服薬が完了していないと判定し（ステップＳ４０６：Ｎｏ）、ステップＳ４０１に戻って処理を継続する。ステップＳ４０１に戻った場合の処理は以上の説明と同様であり、被介助者の認識、薬の認識、判定処理が繰り返される。上述したように、ユースケース２Ｂの例では、介助者は数十人の被介助者を対象として繰り返し服薬管理を実行する必要がある。そのため、服薬アプリケーションの中で繰り返し認証処理を実行することによって、効率的な介助が可能になる。例えば、一人の被介助者の服薬管理が終了するごとにアプリケーションを起動し直すような処理に比べて、介助者の操作負担を軽減できる。
【0171】
この際、第１ボタンの選択受け付け処理は省略されてもよい。例えば服薬アプリケーションは、判定内容に問題がない場合、介助者の操作を省略して自動的に認証処理用の画面（図１８Ｂに対応）に戻る処理を実行してもよい。このようにすれば、服薬管理を多数の被介助者を対象として繰り返す場合に、介助者の操作負担を軽減できる。例えばこの場合、第２ボタンに対応するオブジェクトが図１８Ｂに表示され、図１８Ｂの画面から服薬完了操作が実行されてもよい。また、認証処理において被介助者の認証が完了した際の図１８Ｂから図１８Ｃへの画面遷移、及び、薬の認証が完了した際の図１８Ｃから図１８Ｄの画面遷移も自動化されてもよい。即ち、本実施形態の服薬アプリケーションでは、薬の内容に問題が生じない限り、介助者による入力が省略可能であってもよい。
【0172】
以上の処理により、服薬アプリケーションを用いた服薬管理が完了する。例えば図１７のフローチャートにおいて、服薬アプリケーションの終了が検出された場合（ステップＳ３０５：Ｙｅｓ）、ステップＳ３０１に戻り処理が継続される。なお、ステップＳ３０５でＮｏの場合とは、例えば図１８Ｄの第２ボタンが選択されない場合であって、図１９のフローチャートにおけるステップＳ４０６からステップＳ４０１へ戻る処理に相当する。
【0173】
図１６のユースケース２Ｂに示したように、服薬管理の後は、食事摂取量アプリケーションを用いた食事量の記録が行われる。例えば端末装置２００の処理部２１０は、ステップＳ３０１でホーム画面を再表示し、ステップＳ３０２において食事摂取量アプリケーションの選択操作を受け付ける。食事摂取量アプリケーションは、食事の摂取量や、栄養素の摂取量を判定する。なお図１６では図示を省略しているが、例えば食事摂取量アプリケーションは配膳時にも起動され、配膳時に食前の皿を撮像する処理が行われてもよい。下膳時には、食後の皿を撮像する処理、及び、食前及び食後の画像の比較により食事量を判定する処理が実行されてもよい。
【0174】
なお食事量の記録についても、介助者は数十人の被介助者を対象とすることが想定される。従って食事摂取量アプリケーションについても服薬アプリケーションと同様に、食事摂取量アプリケーションの中で繰り返し被介助者の認証処理が行われてもよい。また食事摂取量アプリケーションは、端末装置２００ではなく、端末装置４６２において動作してもよい。
【0175】
また下膳の場面では、ユースケース２Ａと同様に、介助者は音声認識を用いて、自動走行が可能な配膳カートを操作することによって、食器等の後片付けを行ってもよい。
【0176】
ユースケース２Ｂでは、被介助者のＡＤＬが高いため、口腔ケアやトイレ誘導ではアプリケーションを用いた介助が行われなくてもよい。そしてトイレが終わった後には被介助者はリビングに誘導され、例えば集団活動や団らんを行う。この際、立ち上がり検知アプリケーションを用いることによって、転倒リスクの高い被介助者の監視が行われてもよい。立ち上がり検知アプリケーションは、例えばリビングに設置されたカメラの画像を用いて立ち上がり検知を行う。
【0177】
以上のユースケース２Ｂに示したように、処理部２１０は、認証処理が行われずに第１アプリケーションが起動された場合、第１アプリケーションに従って動作することによって、被介助者の認証処理を実行してもよい。例えば服薬アプリケーションや食事摂取量アプリケーションは、各アプリケーションが有する認証機能を用いて、被介助者の認証処理を実行する。このようにすれば、複数の被介助者を対象として同種の介助を繰り返し実行する場合の利便性向上が可能になる。
【0178】
またユースケース２Ａにおける服薬アプリケーションの処理（図１５）と、ユースケース２Ｂにおける服薬アプリケーションの処理（図１９）の比較から分かるように、本実施形態のアプリケーションは、利用状況に応じて処理が切り替わってもよい。換言すれば、処理部２１０は、第１アプリケーションが検索アプリケーションを介した第１起動処理によって起動された場合と、第１アプリケーションが検索アプリケーションを介さない第２起動処理によって起動された場合とで、第１アプリケーションにおける処理を切り替える。
【0179】
例えば検索アプリケーションから起動されるユースケース２Ａでは、認証処理は予め行われているため、服薬アプリケーションの中で再度認証を行う必要はない。また、ユースケース２Ａでは複数の被介助者を対象とする必要性が低いため、問題がない場合には服薬アプリケーションを自動で終了して検索結果の表示画面に遷移することが可能である。一方、検索アプリケーションを使用しない（ホーム画面から起動される）ユースケース２Ｂでは、服薬アプリケーションの中で認証処理が実行される。また、複数の被介助者の連続処理を考慮して、ある被介助者に関する処理が完了した場合、服薬アプリケーションを終了せずに認証処理を実行する画面に自動遷移が可能であってもよい。
【0180】
なお、以上では服薬アプリケーションの例を示したが、これ以外のアプリケーションについても別々の方法で起動可能であってもよい。そして本実施形態では、起動方法に応じて、当該アプリケーションの動作が変化する。このようにすれば、ユースケースに応じて各アプリケーションの動作（機能）を適切に切り替えられるため、利便性向上が可能になる。
【0181】
あるいは記憶部２２０は、第１アプリケーションと同じ介助内容に関する処理を行う第３アプリケーションを記憶してもよい。そして処理部２１０は、ホーム画面において第３アプリケーションを表示し、且つ、第１アプリケーションを表示しない。さらに処理部２１０は、検索アプリケーションの検索結果において第１アプリケーションを表示し、且つ、第３アプリケーションを表示しなくてもよい。例えば服薬アプリケーションとして、図１５に示した処理を実行する第１服薬アプリケーションと、図１９に示した処理を実行する第２服薬アプリケーションの２つがインストールされてもよい。この場合、処理部２１０は、起動方法に応じて表示するアプリケーションを切り替える。
【0182】
例えばホーム画面では、認証処理が完了していない場面を想定するため、認証機能を有する第２服薬アプリケーションが表示される。一方、認証機能を有さない第１服薬アプリケーションがホーム画面から選択可能であると、被介助者の認証ができないため、個別最適化されたアプリケーションを被介助者に合わせて使用することが難しくなる。従って、第２服薬アプリケーションはホーム画面では非表示とされる。一方、検索アプリケーションで検索結果を表示する際には、認証処理が完了している。従って、服薬アプリケーションの中での認証が不要となるため、検索結果では第１服薬アプリケーションのみが表示され、第２服薬アプリケーションが表示対象から除外される。このように、同種の介助を行うアプリケーションを複数用意することでも、ユースケースに応じた処理の実現が可能である。
【0183】
なお以上の例から分かるように、アプリケーションを分ける場合、検索アプリケーションの検索結果として表示される第１アプリケーションは、被介助者の認証処理を行う機能を有さず、ホーム画面に表示される第３アプリケーションは、被介助者の認証処理を行う機能を有する。これにより、起動方法（認証結果の共有の有無）に応じて、適切に表示対象となるアプリケーションを決定できる。
【0184】
３．３ ユースケース３（就床時）
図２０は、被介助者の就床時に実行される介助の流れ、及び、アプリケーション等の利用例を説明する図である。就床時の介助は、被介助者の居室で行われる。従って就床時の介助は、起床時の介助と同様に特定の被介助者に対してのみ実行される蓋然性が高い。
図２０は、被介助者の就床時に実行される介助の流れ、及び、アプリケーション等の利用例を説明する図である。就床時の介助は、被介助者の居室で行われる。従って就床時の介助は、起床時の介助と同様に特定の被介助者に対してのみ実行される蓋然性が高い。
【0185】
図２０に示すように、就床時の介助は、口腔ケア、着替え、臥床、就寝時の服薬管理、オムツ交換が順次行われる。以下、具体的な流れについて説明する。
【0186】
介助者はまず、口腔ケアを行う。居室には嚥下ムセ検出装置４６０が配置されていない可能性があり、ここでは特にアプリケーションは使用されない。ただし、嚥下ムセ検出装置４６０を居室に配置し、口腔ケアにおいて嚥下ムセ検出アプリケーションが用いられてもよい。
【0187】
次に着替え及び臥床が行われる。例えば介助者は、「ベッドを端座位しやすい形にして」、「ベッドを着替えしやすい形にして」等の音声を発することによって、音声認識によりベッド６１０の高さや角度を調整してもよい。
【0188】
次に介助者は服薬アプリケーションを用いた服薬管理を行う。ここでは特定の被介助者のみを対象と考えるため、介助者は検索アプリケーションを起動する操作を実行してもよい。端末装置２００は、図１３－図１５を用いて上述した例と同様に、検索アプリケーションの中で服薬アプリケーションを起動し、事前の認証結果を用いて処理を実行する。服薬アプリケーションの動作については上述した例と同様であるため詳細な説明は省略する。
【0189】
さらに介助者は、ポジショニングアプリケーションを用いてオムツ交換を用いる。例えば端末装置２００は、検索アプリケーションの検索結果として、対象の被介助者のオムツ交換に用いられるポジショニングアプリケーションを提示する。介助者は当該ポジショニングアプリケーションを用いて被介助者のオムツ交換を行う。ポジショニングアプリケーションが多数インストールされている場合であっても、検索結果には対象の被介助者に関するアプリケーションのみが表示されるため、介助者は所望のポジショニングアプリケーションを容易に選択できる。
【0190】
４．変形例
以下、いくつかの変形例について説明する。
以下、いくつかの変形例について説明する。
【0191】
４．１ 検索アプリケーションに関する変形例
図１３のステップＳ１０３及びＳ１０４において説明したように、検索アプリケーションは被介助者に関係するアプリケーションを検索し、検索結果を介助者に提示する処理を行う。この際、上述したように、アプリケーションと被介助者を対応付けた情報が記憶部２２０に記憶されてもよい。この場合、検索アプリケーションは、被介助者を検索キーとする検索処理を行うことによって、関係するアプリケーションを特定できる。ただし検索アプリケーションにおける検索処理はこれに限定されない。
図１３のステップＳ１０３及びＳ１０４において説明したように、検索アプリケーションは被介助者に関係するアプリケーションを検索し、検索結果を介助者に提示する処理を行う。この際、上述したように、アプリケーションと被介助者を対応付けた情報が記憶部２２０に記憶されてもよい。この場合、検索アプリケーションは、被介助者を検索キーとする検索処理を行うことによって、関係するアプリケーションを特定できる。ただし検索アプリケーションにおける検索処理はこれに限定されない。
【0192】
例えば処理部２１０は、検索アプリケーションの検索処理において、被介助者と当該被介助者の属性とを対応付けた属性情報に基づいて、認証された被介助者の属性を特定し、当該属性と対応付けられたアプリケーションを記憶部２２０から検索してもよい。属性情報は、例えば記憶部２２０に記憶される。また記憶部２２０は、アプリケーションと被介助者の属性を対応付ける情報を記憶してもよい。
【0193】
例えば、嚥下ムセ検出アプリケーションでは、ムセの頻度が所定以上、嚥下音が所定以下、ＡＤＬの指標値が所定以下、嚥下時間が所定以下、等の種々の属性に応じて、望ましい処理（例えば誤嚥リスクを検出する閾値等）が異なる。またここでの属性には、「ＡＡＡＡさんと同じ」のように、介護施設内の所与の被介助者を基準として設定されるものが含まれてもよい。この場合、被介助者一人一人ではなく、属性ごとに処理内容を切り替えればよいため、アプリケーションの効率的な実装が可能になる。例えば、複数のアプリケーションを作成する場合、アプリケーション数の削減が可能になる。あるいは、１つのアプリケーション内でアルゴリズムやパラメータを切り替える際に、当該アルゴリズムやパラメータの数を削減できる。
【0194】
上述したように、検索アプリケーションの検索処理において、属性を検索キーとした検索処理を行うことによって、アプリケーションを効率的に実装した上で、各被介助者に関係するアプリケーションを適切に検索、提示することが可能になる。
【0195】
また処理部２１０は、検索アプリケーションの検索処理において、端末装置２００の使用場所、処理実行時の時間帯、及び、端末装置２００の周辺に位置する介助機器の少なくとも１つの情報に基づいて、アプリケーションを記憶部２２０から検索する処理を行ってもよい。
【0196】
上述したユースケース１～ユースケース３に示したように、居室で行われる介助と食堂で行われる介助は異なる。またトイレであれば便検知の必要性が高く、リビングであれば立ち上がり検知（転倒抑制）の必要性が高い。このように、場所に応じて使用頻度の高いアプリケーションが異なる。例えば記憶部２２０は、アプリケーションと使用場所を対応付けた情報を記憶してもよい。処理部２１０は、端末装置２００の位置を検出することによって当該端末装置２００の使用場所を判定し、判定結果に基づいて使用頻度の高いアプリケーションを特定してもよい。なお位置検出はルータ等の通信機器との接続状況、ＲＦＩＤリーダでの読取り結果、ＧＰＳ出力等、種々の情報に基づく判定が可能である。処理部２１０は、検索結果の提示において、場所に基づいて特定されたアプリケーションを優先的に表示する処理を行う。
【0197】
またユースケース１～ユースケース３に示したように、各時間帯（例えば起床時、朝食時、昼食時、夕食時、就床時）に応じて想定される介助が異なるため、使用頻度の高いアプリケーションも異なる。よって記憶部２２０は、アプリケーションと使用時間帯を対応付けた情報を記憶してもよい。処理部２１０は、当該情報と現在時刻の比較処理を行うことによって、使用頻度の高いアプリケーションを特定してもよい。処理部２１０は、検索結果の提示において、時間帯に基づいて特定されたアプリケーションを優先的に表示する処理を行う。
【0198】
またユースケース２に示したように、食堂での介助では配膳カートが端末装置２００の近傍に配置される。従って配膳カートとの距離が所定以下であれば、食事介助が行われており、食事摂取量アプリケーションや嚥下ムセ検出アプリケーションを使用する蓋然性が高いと考えられる。よって記憶部２２０は、アプリケーションと介助機器を対応付けた情報を記憶してもよい。処理部２１０は、当該情報と、周辺に存在する介助機器に基づいて、使用頻度の高いアプリケーションを特定してもよい。例えば介助機器はＷｉＦｉ，Bluetooth、ＮＦＣ等を用いた通信機能を有してもよい。処理部２１０は、これらの通信機能を用いて介助機器と接続された場合に、当該介助機器が所定距離以下に位置すると判定してもよい。あるいは介助機器にＱＲコードが貼付されていてもよい。処理部２１０は、撮像部２６０を用いて当該ＱＲコードを読み取った場合に、介助機器が近傍に位置すると判定してもよい。処理部２１０は、検索結果の提示において、介助機器に基づいて特定されたアプリケーションを優先的に表示する処理を行う。
【0199】
あるいは処理部２１０は、検索アプリケーションの検索処理において、対象の被介助者の介助において過去に使用された履歴のあるアプリケーションを優先して表示してもよい。また、複数のアプリケーションの使用履歴がある場合、使用頻度の高いアプリケーションを特に優先して表示してもよい。このようにすれば、介助者が所望のアプリケーションを選択しやすくなるため、操作負担の軽減が可能になる。
【0200】
また介助者の操作負担を軽減するという観点からすれば、検索アプリケーションの起動及び操作が音声認識を用いて行われてもよい。例えば介助者は、検索アプリケーションを起動するキーワード、被介助者の氏名、属性等を発話することによって、検索アプリケーションを起動、操作する。この例では、画像での認証処理に代えて音声認識を用いた認証処理が行われるため、操作負担の軽減が可能である。
【0201】
４．２ 服薬アプリケーションに関する変形例
＜認証処理＞
上述したように、服薬アプリケーションにおける被介助者の認証処理は、顔を撮像した撮像画像に基づく顔認証が行われてもよいし、ラベル文字に対するＯＣＲ処理が行われてもよいし、ＱＲコードが用いられてもよい。以下の通り、それぞれが異なる特性を有するため、例えば状況に応じて認証処理が切り替え可能であってもよい。
＜認証処理＞
上述したように、服薬アプリケーションにおける被介助者の認証処理は、顔を撮像した撮像画像に基づく顔認証が行われてもよいし、ラベル文字に対するＯＣＲ処理が行われてもよいし、ＱＲコードが用いられてもよい。以下の通り、それぞれが異なる特性を有するため、例えば状況に応じて認証処理が切り替え可能であってもよい。
【0202】
顔認証は、介助者が被介助者の顔を覚えていない場合であっても、データベースに登録済みの人物であれば、当該人物の氏名等を正確に特定できるという利点がある。例えば本来の介助者とは異なるヘルプ担当者が服薬介助を行う場合や、新人介助者が服薬介助を行う場合であっても、被介助者を他の人物と誤認して薬を取り違えることを抑制できる。一方、顔認証を行う場合、被介助者の顔を撮像する必要がある。そのため、例えば認知症患者を対象とした場合、カメラに顔を向けてくれない、カメラを向けることで気分を害する等、認証が容易でない場面も考えられる。
【0203】
またＯＣＲ処理を用いる場合、文字列をそのまま認識できるため、ＱＲコード等のコード作成を行う必要が無いという利点がある。例えば介護施設では、図１８Ｂに示したように、被介助者の食事内容や、摂取させてはいけない食材等の情報がカード等を用いて管理されるケースがある。ＯＣＲ処理では、これらのカードを用いることが可能であるため、被介助者の認証処理を容易に実現できる。また、福祉用具等に名札をつけておき、ＯＣＲ処理では当該名札が用いられてもよい。介助の場面では介助者による被介助者の確認等を目的として名札が広く用いられているため、当該名札をＯＣＲ処理に流用することによって、本実施形態の処理を容易に実現することが可能である。
【0204】
またＱＲコードが用いられる場合、例えば被介助者の情報を含むＱＲコードが予め作成され、当該ＱＲコードを読み込む処理が行われる。コード作成が必要となるものの、ＯＣＲ処理等に比べて画像認識処理が容易であるため、カメラの前でＱＲコードが添付されたカード等を固定させる時間が短くてよく、作業効率が高いという利点がある。
【0205】
また、これらの処理によって自動的に被介助者を認識する場合、サーバシステム１００の記憶部１２０等に、介助対象となる被介助者の情報をデータベースとして登録しておく必要がある。そのため、何らかの理由で未登録の被介助者の服薬管理が必要となった場合、当該被介助者の認証が行えない。従って本実施形態では、被介助者の氏名を手動で入力することが可能であってもよい。この場合、例えば手動入力されたことを表す情報を服用管理の結果と対応付けてもよい。このようにすれば、手動入力の内容を後から確認することが容易になる。また手動入力された被介助者の氏名はＯＣＲ処理で認識できるようにしてもよいし、次回以降も手動入力を求めてもよい。また、手動入力結果をＯＣＲ処理に利用可能とした上で、次回以降ＯＣＲ処理を行うか、再度手動入力を行うかを介助者が選択可能であってもよい。
【0206】
また薬の認証処理についても同様に、ＯＣＲ処理が用いられてもよいし、ＱＲコードが用いられてもよい。例えば薬の認証処理では、図１４Ｃ、図１８Ｃに示したように、薬の服薬タイミングごとに小分けにされた袋のラベルを撮像する処理が想定される。ここで、薬を小分けして包装し、ラベル付けする作業は、薬剤師や看護師等の専門家によって行われる。従って、当該ラベルを判定に用いることによって、介護施設内での薬の取り違えを抑制できる。
【0207】
またＱＲコードが用いられる場合、例えば被介助者及び薬の服薬タイミングの情報を含むＱＲコードが予め作成され、当該ＱＲコードを上記小分けされた薬の袋に貼付する作業が行われる。この場合、ＱＲコードと、薬袋との対応付けを介護施設で行う必要があるものの、ＯＣＲ処理等に比べて画像認識処理が容易であるという利点がある。
【0208】
＜嚥下判定、下剤通知＞
服薬アプリケーションの処理は図１５及び図１９を用いて上述したとおりである。例えばホーム画面から起動される場合は、（１）被介助者の認証処理、（２）薬の認証処理、（３）判定、記録によって一人分の処理が完了し、（１）に戻って次の被介助者を対象とした処理が継続される（図１９参照）。
服薬アプリケーションの処理は図１５及び図１９を用いて上述したとおりである。例えばホーム画面から起動される場合は、（１）被介助者の認証処理、（２）薬の認証処理、（３）判定、記録によって一人分の処理が完了し、（１）に戻って次の被介助者を対象とした処理が継続される（図１９参照）。
【0209】
一方、検索アプリケーションから起動される場合、上記（１）の被介助者の認証処理が省略され、（２）薬の認証処理、（３）判定、記録が行われる（図１５参照）。この場合、（３）の処理により服薬アプリケーションの処理は終了し、検索アプリケーションの検索結果表示画面に戻る。
【0210】
以上の処理は、例えば端末装置２００において服薬アプリケーションが実行される場合の処理に対応する。ただし本実施形態では、上述したように嚥下ムセ検出装置４６０の端末装置４６２において服薬アプリケーションが実行されてもよい。この場合、端末装置４６２は、スロートマイク４６１から嚥下音に関する音データを取得すること、及び、被介助者の口周辺を撮像することが可能である。従って、端末装置４６２で動作する服薬アプリケーションは、嚥下等に基づく判定を行ってもよい。
【0211】
例えば端末装置４６２は、上述した（３）の処理の後に、嚥下判定を行ってもよい。例えば端末装置４６２は、薬を飲むために口を開けてから所定時間以内に嚥下が検出されたかを判定してもよい。端末装置４６２は、嚥下が検出された場合に薬が適切に服用されたと判定し、嚥下が検出されなかった場合に、問題がある旨を介助者に通知する。また端末装置４６２は、撮像画像から薬を検出するオブジェクト検出を行うことによって、被介助者が薬を落とす落薬が発生していないかを判定してもよい。
【0212】
また端末装置４６２は、被介助者を撮像した画像を端末装置４６２の記憶部や、サーバシステム１００の記憶部１２０に記憶させる処理を行ってもよい。なお、端末装置４６２における服薬アプリケーションの動作は、嚥下判定及び録画記憶を行える点を除いて、端末装置２００における動作と同じであってもよい。
【0213】
また端末装置２００及び端末装置４６２の少なくとも一方において、便検知デバイスからの便情報に基づく処理が行われてもよい。例えば、排便が見られない被介助者には下剤が処方されることがある。具体的には、看護師等が薬袋に被介助者用の薬を入れる際に、便秘傾向の被介助者には下剤を追加する。ただし、看護師が薬袋を用意するタイミングと、実際の服用タイミングにはラグが生じる。そのため、看護師が薬を用意するタイミングでは排便が長時間行われていなかったが、下剤の服用までの期間に排便が行われるというケースも考えられる。この場合、下剤の服用は不要であるため、服薬管理において下剤を取り除く作業が必要となる。
【0214】
従来、介護施設では排便の情報が記録され、共有可能な状態となっていることが想定されるが、服薬管理（服薬アプリケーション）との連携が十分でなかった。例えば、排泄を確認した介助者と、服薬管理を行う介助者が異なる場合、口頭で申し送りされたとしても、服薬管理の時まで正確に覚えておくことは容易でない。またデータベースに排泄記録が残っていたとしても、介助者が能動的にデータを閲覧するのでは負担が大きかった。
【0215】
そこで本実施形態では、服薬アプリケーションは、便検知デバイスからの情報に基づいて、下剤を抜くか否かを提示してもよい。例えば端末装置２００及び端末装置４６２のいずれにおいても、服薬アプリケーションは便検知デバイスからの情報を取得し、排便があった場合に、下剤を抜く旨の報知処理を行う。この処理は、例えば上記（２）の薬の認証処理の後に行われてもよい。上述したように、端末装置２００と端末装置４６２のいずれであっても、また、ホーム画面から起動される場合と検索アプリケーションから起動される場合のいずれであっても、上記（２）の処理は必ず行われるものである。従って（２）の処理後に下剤に関する報知を行うことによって、状況に応じて処理順序を入れ替える必要がない（アルゴリズムの変更を少なくできる）と言う利点がある。また報知タイミングが一定となるため、介助者にとって処理の流れが分かりやすい。
【0216】
＜データ共有（漏れ通知）＞
なお以上で説明した服薬アプリケーションの処理では、被介助者及び服薬タイミングが正しいかを確認できる。さらに本実施形態では、服薬アプリケーションは、服薬に漏れがないかを判定してもよい。ここでの服薬漏れとは、例えば介護施設において薬を服用させるべき被介助者の少なくとも一部に対して、服薬管理が行われていない状況を表す。
なお以上で説明した服薬アプリケーションの処理では、被介助者及び服薬タイミングが正しいかを確認できる。さらに本実施形態では、服薬アプリケーションは、服薬に漏れがないかを判定してもよい。ここでの服薬漏れとは、例えば介護施設において薬を服用させるべき被介助者の少なくとも一部に対して、服薬管理が行われていない状況を表す。
【0217】
ここで服薬漏れを判定する単位は、介護施設全体であってもよいし、フロアごとであってもよい。また服薬漏れを行うタイミングは、例えば服薬アプリケーションが終了するタイミングであってもよいし、服薬時間帯に基づいて設定される〆タイミングであってもよい。
【0218】
図２１は、アプリケーション終了時に服薬漏れの通知処理を行う場合の服薬アプリケーションの処理を説明するフローチャートである。この処理は、例えば端末装置２００において実行される。ステップＳ５０１－Ｓ５０６については、図１９のステップＳ４０１－Ｓ４０６と同様であるため詳細な説明は省略する。またステップＳ５０１－Ｓ５０６の処理に変えて、図１５のＳ２０１－Ｓ２０４と同様の処理が行われてもよい。また、嚥下判定及び録画記憶が追加で実行されてもよい。
【0219】
ステップＳ５０６で服薬管理が完了したと判定された場合、ステップＳ５０７において、処理部２１０は、服薬漏れがないかを判定する。例えば処理部２１０は、ステップＳ５０１－Ｓ５０４（及び必要に応じてＳ５０５）の処理が行われた被介助者を服薬済みの被介助者と判定し、介護施設全体または対象フロアの全被介助者が服薬済みになっているかを判定する。
【0220】
服薬済みになっていない被介助者が残っている場合、処理部２１０は服薬漏れがあると判定し（ステップＳ５０７：Ｙｅｓ）、ステップＳ５０８において、その旨を介助者に通知する処理を行う。全被介助者が服薬済みである場合、処理部２１０は服薬漏れがないと判定し（ステップＳ５０７：Ｎｏ）、処理を終了する。
【0221】
また図２２は、介護施設における服薬スケジュールの例を示す図である。図２２の例では、起床時、朝食時、昼食時、夕食時、就床時に服薬が行われる。各被介助者の具体的な服薬時刻は介助の順序や、介助者の配置、インシデントの発生状況等に応じてばらつくことになるが、これらのばらつきを鑑みた上で全被介助者の服薬管理が完了しているべきタイミングが〆タイミングとして設定される。図２２の例では、起床時の服薬管理における〆タイミングは８：００である。同様に、朝食時の服薬管理における〆タイミングは１０：００、昼食時の服薬管理における〆タイミングは１３：００、夕食時の服薬管理における〆タイミングは１９：００、就床時の服薬管理における〆タイミングは２１：００である。
【0222】
図２３は、〆タイミングに基づく服薬漏れの判定処理を説明するフローチャートである。図２３に示す処理は、例えば図１５、図１９、図２１等に示す処理を行う服薬アプリケーションとは異なるアプリケーションにより実行されてもよいし、服薬アプリケーションがバックグラウンドで動作することによって実行されてもよい。
【0223】
この処理が開始されると、まずステップＳ６０１において、処理部２１０は、〆タイミングを経過しているかを判定する。例えば処理部２１０は、８：００、１０：００、１３：００、１９：００、２１：００の各時刻を記憶しておき、現在時刻がこれらの時刻の何れかを経過した最初のタイミングにおいて、〆タイミングを過ぎたと判定する。
【0224】
〆タイミングを過ぎている場合（ステップＳ６０１：Ｙｅｓ）、ステップＳ６０２において、処理部２１０は、服薬漏れがないかを判定する。例えば、ステップＳ６０１において、８：００を過ぎたと判定された場合、処理部２１０は、起床時の服薬漏れを判定する。具体的には、処理部２１０は、起床時に服薬が必要な被介助者のリストを保持しておき、当該リストに記載された全被介助者の服薬管理が行われたかを判定してもよい。服薬済みになっていない被介助者が残っている場合、処理部２１０は服薬漏れがあると判定し（ステップＳ６０２：Ｙｅｓ）、ステップＳ６０３において、その旨を介助者に通知する処理を行う。全被介助者が服薬済みである場合、処理部２１０は服薬漏れがないと判定し（ステップＳ６０２：Ｎｏ）、処理を終了する。
【0225】
処理部２１０は、図２３に示す処理を定期的に実行することによって、〆タイミングにおける服薬漏れの判定処理を行う。
【0226】
本実施形態の手法によれば、服薬漏れがある場合にその旨が介助者に通知されるため、適切な対応を促すことが可能になる。さらに、図２１に示したアプリケーション実行時の処理、及び、図２３に示した〆タイミングに基づく処理というトリガーの異なる２つの処理を併用することによって、何れか一方を用いる場合に比べて服薬漏れを抑制することが可能になる。服薬漏れの通知先は、服薬管理が行われていない被介助者を担当する介助者であってもよいが、これ以外の介助者が対象に含まれてもよい。例えば対象の被介助者が生活するフロアを担当する全介助者に通知が行われてもよいし、同じ時間帯に勤務する全介助者に通知が行われてもよい。このようにすれば、例えばインシデントへの対応等で本来の担当介助者に余裕がない場合であっても、他の介助者がフォローすることが可能になる。
【0227】
ただし、本実施形態の服薬管理は、複数の端末で分散して実行されることが想定される。例えば上述したように、服薬アプリケーションは、端末装置２００と端末装置４６２で動作してもよい。嚥下ムセ検出装置４６０の端末装置４６２を用いる場合、上述したように嚥下判定及び録画記憶を行うことが可能であるため、例えば被介助者のＡＤＬに応じて、服薬管理に用いられる端末が異なってもよい。
【0228】
あるいは、介護施設には多数の被介助者が入居することも考えられるため、一人の介助者が全ての被介助者の服薬管理を行うことが現実的でない場合もある。この場合、複数の介助者が、それぞれ異なる端末を用いて服薬管理を実行する。
【0229】
このように服薬管理が複数の端末を用いて行われる場合、少なくとも図２３に示した〆タイミングにおける服薬漏れの判定までには、各端末からの情報を集約する必要がある。そうでなければ、どの被介助者が服薬済みになったかという情報が、端末ごとに相違してしまい、介護施設全体あるいはフロアごとといった単位での服薬漏れの判定が行えないためである。
【0230】
例えば全ての端末装置２００及び端末装置４６２が常時サーバシステム１００との通信が可能である場合、各端末は、服薬アプリケーションを終了するタイミング等において、当該端末に記憶された情報をサーバシステム１００に送信する。このようにすれば、サーバシステム１００は、対象の介護施設における服薬管理の全ての情報を収集したマスターデータを作成できる。各介助者の端末装置２００は、サーバシステム１００からマスターデータを取得することによって、服薬漏れの判定処理を実行する。
【0231】
ただし、介護施設によっては、施設内に通信用の電波が届きにくい場所がある、あるいは、他の通信にリソースが必要であるため、服薬結果の共有のために通信リソースを割り当てることが難しい等の事情があることも考えられる。
【0232】
よって例えば、端末装置２００によって、端末装置４６２に蓄積されたデータを読み出す処理が行われてもよい。例えば端末装置２００と端末装置４６２は、それぞれ計時部を用いて現在時刻と〆タイミングの比較処理を行う。そして〆タイミングに近いタイミングになったら、端末装置２００がアラームを出力するとともに、端末装置４６２は服薬情報を含むＱＲコードを表示部に表示してもよい。ここでの服薬情報は、対象の端末装置４６２において服薬管理が行われた被介助者や服薬タイミング等の情報を含む。アラームを認識した介助者は、端末装置４６２の設置場所まで移動し、端末装置２００を用いてＱＲコードを読み取る処理を行う。端末装置２００は、ＱＲコードに基づいて端末装置４６２の服薬情報を取得した場合に、アラームを消去する。このようにすれば、端末装置２００に、端末装置４６２の情報を集約できるため、服薬漏れの判定処理を適切に実行できる。
【0233】
あるいは介護施設内にマスタ機器３００が配置され、各端末で実行された服薬管理の結果が当該マスタ機器３００に送信されてもよい。図２４はこの場合のシステム構成例を示す図である。例えばマスタ機器３００は介護施設等の所定位置に配置され、端末装置２００及び端末装置４６２は、施設内ネットワークを介してマスタ機器３００に接続される。マスタ機器３００は、端末装置４６２のうちのいずれかであってもよいし、端末装置４６２とは異なるデバイスであってもよい。この際、マスタ機器３００は、デイケア等を利用する介助者の自宅での服薬管理の結果や録画記憶等を収集してもよい。このようにすれば、介護施設外での服薬状況についても適切に管理することが可能になる。
【0234】
また図２４に示したように、マスタ機器３００は、便検知デバイスからの情報に基づいて、各被介助者の排便状況に関する情報を収集してもよい。そして端末装置２００や端末装置４６２は、当該情報をマスタ機器３００から取得することによって、上述した下剤を抜くか否かの判定を行ってもよい。
【0235】
またマスタ機器３００は、介護施設全体の服薬管理を行うものに限定されず、介護施設の一部の情報の管理に用いられてもよい。例えば図２５に示すように、あるフロアに複数の端末装置４６２が配置され、且つ、当該フロアを担当する複数の介助者が１つの端末装置２００を共有するケースを考える。この場合、フロア内の各機器の情報が収集されれば、当該フロアの服薬漏れの判定処理を含めた服薬管理を適切に実行することが可能である。
【0236】
例えば、ここでのマスタ機器３００及び端末装置４６２はフロア内をカバーする程度の通信距離を有する近距離無線通信（例えばBluetooth等）を用いて通信を行ってもよい。各端末装置４６２での服薬管理の結果は、逐次、マスタ機器３００に収集される。また端末装置２００は、例えば〆タイミングに近いタイミングにおいて、マスタ機器３００との通信を求めるアラームを出力してもよい。介助者が端末装置２００をマスタ機器３００に接続することによって、端末装置２００とマスタ機器３００との間で情報が共有される。具体的には、端末装置２００はマスタ機器３００から各端末装置４６２での服薬管理の結果を取得することによって、〆タイミングにおける服薬漏れの判定処理を適切に実行できる。なお、図２５ではマスタ機器３００にドック３１０が設けられ、端末装置２００が当該ドック３１０に接続される（例えば無接点接続であればドック３１０上に載置される）ことによって、マスタ機器３００と端末装置２００の通信が実行される例を示している。ただし、マスタ機器３００と端末装置２００が無線通信を行ってもよく、具体的な通信態様は種々の変形実施が可能である。また一部の端末装置４６２は、マスタ機器３００を介さずに端末装置２００に直接データを送信可能であってもよい。
【0237】
４．３ いじり検知アプリケーション
図９Ａ～図９Ｃを用いて上述したように、通信タグ４７０を用いることによって、被介助者のいじりを検知することが可能である。ただし、通信タグ４７０は、第１タグ部４７１が所定以上、第２タグ部４７２の外部に露出していればリーダにより読み取りが可能となりいじり検知と判定される。そのため、必要性が低い状況、例えば被介助者が衣類を少し触っただけでもリーダで読み取られる可能性もあり、このようなケースで通知が行われるとかえって介助者による介助を妨げることも考えられる。
図９Ａ～図９Ｃを用いて上述したように、通信タグ４７０を用いることによって、被介助者のいじりを検知することが可能である。ただし、通信タグ４７０は、第１タグ部４７１が所定以上、第２タグ部４７２の外部に露出していればリーダにより読み取りが可能となりいじり検知と判定される。そのため、必要性が低い状況、例えば被介助者が衣類を少し触っただけでもリーダで読み取られる可能性もあり、このようなケースで通知が行われるとかえって介助者による介助を妨げることも考えられる。
【0238】
従って、通信タグ４７０の読取り結果に基づく通知は、所定の条件が満たされた場合に行われてもよい。図２６、図２７は、いじりの通知を適切に制御する際のアプリケーション及びデバイス間の関係例を説明する図である。ここでのリーダは、例えば被介助者の居室等、対象の被介助者がいじりを行う蓋然性の高い位置に配置される。そしてリーダは、外部からの制御信号に基づいてオン／オフ（アクティブ／スリープを含む）を制御可能な機器であってもよい。例えば、リーダがＬＡＮ等のネットワークに接続され、当該ネットワークを介した他の機器から通信に基づいてオン／オフが制御されてもよい。あるいは、リーダは、接続された機器への電源供給のオン／オフを制御可能なＩｏＴ機器（狭義にはスマートプラグ）に接続されてもよい。この場合、ネットワークを介した他の機器から通信に基づいて、ＩｏＴ機器がリーダへの電源供給を制御することによって、リーダのオン／オフが制御されてもよい。平常状態において、リーダの電源はオフに設定される。これにより、必要性が低い状況ではそもそも通信タグ４７０の読み取りが行われないため、いじりに関する通知が行われることを抑制できる。
【0239】
図２６は、被介助者がオムツを装着する場合のアプリケーション及びデバイス間の関係例を説明する図である。この場合、通信タグ４７０は、オムツに装着されてもよいし、ズボンに装着されてもよい。オムツにおける排泄状態を検出するデバイスは、例えば「尿失禁の管理のためのモノのインターネット（ＩＯＴ）ソリューション」という２０２０年３月４日に出願された特願２０２１－５５３００４号、あるいは「おむつの状態を検出する検出装置およびその検出装置を収容するおむつ」という２０２０年６月１２日に出願された特願２０２１－５７３７２４号に記載されている。これら特許出願は、その全体が本願明細書において参照により援用されている。なお、上記特許出願では、ＲＦＩＤを用いる手法、あるいは抵抗値や導電率を検出する手法が開示されているが、本実施形態に係る便検知デバイスは、においセンサ等の他の手法を用いたデバイスであってもよい。
【0240】
そして例えば便検知デバイスが便と尿を分類可能な場合、便検知デバイス連携アプリケーションによって便検知デバイスと被介助者が対応付けられ、当該被介助者の便の情報及び尿の情報がサーバシステム１００に蓄積される。例えばサーバシステム１００は、被介助者が排便を行ったことが検出された場合、図２６に示すように、まず当該被介助者を担当する介助者の端末装置２００にオムツ交換を指示する情報を出力する処理を行う。なお通知対象は一人の介助者に限定されず、当該介助者をサポートする他の介助者（例えば同じフロアを担当する介助者）等が含まれてもよい。
【0241】
当該通知に対して、介助者がオムツ交換を実行できた場合、当該オムツ交換によりオムツの中には便が無い状態に移行する。この場合、被介助者がオムツ内に手を入れたとしても、便をいじることがないため、いじりの通知の必要性は低い。従って、リーダの電源はオフの状態が維持される。
【0242】
一方、他の業務によって担当の介助者が即座にオムツ交換をできない場合、あるいは、被介助者が睡眠中であるため、不用意にオムツ交換をすることで睡眠が妨げられると判断した場合等には、オムツ交換が行われない状態が継続する。この場合、図２６に示すように、サーバシステム１００は、リーダの電源をオフからオンにする制御を行ってもよい。これにより、リーダは通信タグ４７０との通信を実行可能な状態に移行する。従って、被介助者が衣類に手を入れることで通信タグ４７０のアンテナが遮蔽されなくなった場合、リーダは通信タグ４７０の読み取りを行う。例えばサーバシステム１００は、リーダの読取り結果を取得し、当該読取り結果に基づいて通信タグ４７０に対応付けられた被介助者のいじりを検知する。サーバシステム１００は、例えば被介助者を担当する介助者の端末装置２００に対して、いじりを通知する処理を行う。このようにすれば、平常状態ではいじりの通知をオフにしつつ、必要な場面で当該通知をオンにすることが可能になる。
【0243】
また図２６に示したように、便検知デバイスが被介助者の排尿を検出した場合、リーダの電源がオンに設定されてもよい。排尿が検出された場合であっても、尿の量が想定内である場合、オムツ内の吸収剤によって尿の大部分が吸収可能であり、排便と比較した状況の深刻度合いは低い。従って、オムツ交換が積極的に行われない（例えばルーチンとして設定されたオムツ交換時刻までそのままの状態が維持される）場合がある。しかし、被介助者がオムツに手を入れて吸収剤に触れることは不衛生であるし、排尿が行われているのであるから平常状態に比べてオムツに関して注視すべき状況であると考えられる。その点、図２６に示したように、排尿をトリガーとしてリーダの電源をオンに設定することによって、適切なタイミングでいじりの検知及び通知を行うことが可能になる。
【0244】
なお、排便検知をトリガーとしてリーダの電源がオンにされた場合と、排尿検知をトリガーとしてリーダの電源がオンにされた場合とでは、いじりが検知された場合の通知の優先度が異なってもよい。具体的には、排便検知の場合は、排尿検知の場合に比べて通知の優先度が高く設定される。このようにすれば、被介助者が衣類に手を入れることで、より深刻な状態（便に触れる、手についた便を投げる等）になる可能性がある場合に、優先度の高い通知を行うことが可能になる。結果として、当該通知を受け取った介助者に適切な対応を促すことが可能になる。
【0245】
また図２６に示したように、ポジショニングアプリケーションの処理が終了後、所定の期間において、リーダの電源がオンにされてもよい。ここでのポジショニングアプリケーションは、具体的にはベッドポジションの判定、さらに具体的にはオムツ交換における被介助者、介助者、オムツの位置等の判定を行ってもよい。オムツ交換が行われた場合、装着状態によっては（例えばオムツの当て方によっては）被介助者が違和感を覚えて手を衣類に入れやすくなる可能性がある。その点、ポジショニングアプリケーションとの連携に基づいてオムツ交換後にリーダをオンにすることによって、そのような被介助者の動きを適切に検出し、通知を行うことが可能になる。
【0246】
また便検知デバイスのセンサ構成や処理アルゴリズムによっては、排便と排尿を分類しないことも考えられる。この場合、図２６に示したように、便検知デバイスが排泄を検知した場合、リーダの電源がオンに設定されてもよい。この場合、排便と排尿を分類する場合に比べて細かい状況の切り分けは難しくなるが、必要性の高い場面でいじりの検知及び通知が可能であるという利点については同様である。
【0247】
また服薬アプリケーションに関連して上述したように、被介助者に下剤が処方されている場合において、当該下剤を処方通りに服用させるか、あるいは下剤を抜いて服用させないかが切り替え可能であってもよい。例えば図２６に示したように、便検知デバイスの出力に基づいて排便が検出された場合、オムツ交換の通知に加えて、服薬アプリケーションとの連携処理が実行されてもよい。以下、サーバシステム１００を介したアプリケーション間の連携を例示するが、便検知デバイスと、服薬アプリケーションが動作する端末装置２００が直接通信を行ってもよく、連携手法は種々の変形実施が可能である。
【0248】
例えばサーバシステム１００の処理部１１０は、便検知デバイスからの情報、及び、便検知デバイス連携アプリケーションからの被介助者の情報に基づいて、各被介助者について排便の検知を行う。そして下剤が処方されている被介助者の排便が検出された場合、当該被介助者の下剤を抜くための処理を実行する。例えば、記憶部１２０は、服薬漏れの判定処理に関連して上述したように、各被介助者の服薬管理に用いられるマスターデータを記憶してもよい。そして処理部１１０は、当該マスターデータに対して、対象の被介助者の下剤を除外する旨を表す情報を追加する処理を行う。
【0249】
服薬アプリケーションの処理においては、図１５のステップＳ２０２及び図１９のステップＳ４０３に示したように、被介助者及び薬が正しいかを判定する。この際、服薬アプリケーションはマスターデータを参照することによって、対象の被介助者に関して、下剤を除外する情報が付加されているかを判定してもよい。そして下剤を除外する情報が付加されている場合、服薬アプリケーションは下剤を抜いて服用させない旨を表す情報を介助者に通知する。図２８は、下剤を抜く旨を通知する画面例である。例えば、服薬アプリケーションは、被介助者と薬が処方された患者の対応付け、現在時刻と服薬タイミングの対応付けに問題がない場合、その旨を表す「ＯＫ」という文字列を表示する処理を行う。この処理は、図１４Ｄや図１８Ｄと同様である。図２８では、「ＯＫ」という文字列に加えて、「下剤を抜いてください」という文章の表示処理も行われる。このようにすれば、既に排便が行われている場合、必要性の低い下剤が服用されることを抑制できる。ただし、下剤を抜く旨の通知は文字に限定されない。例えば端末装置２００は、スピーカを用いて「下剤を抜いてください」という音声を出力してもよい。このようにすれば、介助者は端末装置２００の表示部２４０を注視する必要が無いため、介助者の負担軽減が可能になる。
【0250】
図２７は、被介助者がトイレで排泄可能な場合のアプリケーション及びデバイス間の関係例を説明する図である。この場合、通信タグ４７０は、下着に装着されてもよいし、ズボンに装着されてもよい。なおトイレでの排便、排尿は、例えば上述した国際公開２０２１／１９２４７５号に開示されているデバイスが用いられてもよいし、他のデバイスが用いられてもよい。
【0251】
この場合、トイレで排便や排尿が検知されたとしても、便や尿が衣類の中に残ることは考えにくい。そのため、排泄が検知されたことは直接的にいじりのリスクが高いことを表すわけではないため、リーダの電源はオンに設定されない。例えばサーバシステム１００は、トイレに配置されたデバイス（マイクやカメラ等）により排便または排尿が検知された場合、排泄の内容や時刻等を表す情報を記憶部１２０に記憶する。また図２６を用いて上述した例と同様に、排便が検出された場合、服薬アプリケーションとの連携処理が実行されてもよい。
【0252】
またサーバシステム１００の処理部１１０は、トイレに配置された便検知デバイスからの排便、排尿の情報に基づいて、被介助者ごとに排泄予測を行ってもよい。ここでの排泄予測とは、例えば排尿の間隔、排便の間隔等を求める処理であってもよいし、次の排便・排尿が何分後に発生するかを予測する処理であってもよい。これらの処理は、実際の排泄記録に基づく統計処理によって行われてもよいし、当該排泄記録を正解データとする機械学習に基づいて実行されてもよい。
【0253】
そして処理部１１０は、排泄が予測されたタイミングを含む所定期間において、リーダの電源をオンに設定する制御を行ってもよい。このようにすれば、排泄が行われる蓋然性が高いタイミングにおいて、いじりを検知することが可能になる。例えば被介助者がトイレに行くことができず居室で失禁をしてしまい、その上で衣類に手を入れた場合、いじりが発生する蓋然性が高く深刻度合いも高い。また、被介助者がトイレに行かずに例えば居室のベッドで意図的に衣服を脱いで排泄（排尿・排便）する場合も、深刻度合いも高い。その点、本実施形態によれば排泄が行われる蓋然性の高い時間帯でいじりを検知できるため、当該深刻度合いの高い状況を適切に検知し、介助者に通知を行うことが可能になる。この場合の通知は、優先度の高い通知であってもよい。一方で、被介助者が通常通りトイレに行って排泄を行う場合、ズボンや下着を下ろす動作を行うことになるが、当該動作を行うトイレと、リーダが配置される居室は離れていることが想定される。従って、上記の通り居室のリーダの電源がオンに設定されている状態でズボンを下ろしたとしても、リーダは通信タグ４７０を読み取ることがないため、不必要ないじりを通知することを抑制できる。また排泄が行われる蓋然性の低い時間帯ではそもそもリーダの電源がオフに設定されるため、この期間においても必要性の低い通知を抑制できる。
【0254】
なお以上では、トイレに設置されたマイクやカメラ等の便検知デバイスの出力に基づいて排便及び排尿を記録し、当該記録に基づいて排泄予測を行う例を説明したがこれには限定されない。例えば、当該便検知デバイスとともに、あるいは当該便検知デバイスにかえて、他の排泄予測用のデバイスが用いられてもよい。例えば、https://dfree.biz/には、超音波センサに基づいて膀胱の膨らみを計測し、計測結果に基づいて排泄タイミングを予測するデバイスが開示されている。本実施形態では、これらのデバイスに基づいて排泄予測が実行されてもよい。
【0255】
また以上では、通信タグ４７０を読み取るリーダが被介助者の居室に配置される例を説明した。このように、被介助者が滞在する蓋然性の高い位置にリーダを設定することによって、通常の生活を行っている中でのいじりを適切に検知することが可能になる。ただし、被介助者の状況によっては、深刻度合いの高いいじりが居室以外の場所で発生する可能性もある。例えば認知症患者である被介助者は、トイレ以外の所与の場所をトイレと誤認することによって、当該所与の場所で習慣的に排泄を行ってしまう場合がある。この場合、当該所与の場所において、衣類に手を入れたことを検出することによって、トイレ以外の場所での排泄の可能性を介助者に通知することが可能になる。
【0256】
従って、本実施形態では被介助者の居室に配置されるリーダと、被介助者の居室以外の所与の位置に配置される第２リーダとが用いられてもよい。第２リーダは、上述したように、対象の被介助者がトイレと誤認する場所であるため、被介助者に応じて異なる。第２リーダは、例えば常時電源がオンに設定される。ただし第２リーダは上述した例と同様に、何らかの条件が満たされた場合に電源がオンに設定され、他の期間において電源がオフに設定されてもよい。第１リーダと第２リーダを用いることによって、通信タグ４７０を読み取ったリーダの種類に応じて、適切な通知を介助者に行うことが可能になる。
【0257】
また被介助者によっては、他の被介助者の居室をトイレと誤認する可能性も考えられる。例えば被介助者Ａが、被介助者Ｂの居室をトイレと誤認する。この場合、被介助者Ｂの居室に設けられ、被介助者Ｂの居室でのいじり等を検出するためのリーダが、被介助者Ａにとっての第２リーダとして機能してもよい。例えば、当該リーダは、被介助者Ａにとっての第２リーダであるため、常時電源がオンに設定される。この場合、リーダは、通信タグ４７０を識別する情報（例えばＩＤ、登録番号）を読取ってもよい。例えばサーバシステム１００は、リーダの読取り結果として、読み取った通信タグ４７０の登録番号を含む情報を取得する。そして登録番号が被介助者Ａに対応するか、被介助者Ｂに対応するかで処理を切り替えてもよい。
【0258】
例えば、登録番号が被介助者Ａに対応する場合、被介助者Ａは、トイレと誤認して被介助者Ｂの居室に入り、衣類に手を入れた状況であると推定される。従って処理部１１０は、被介助者Ａを担当する介助者に優先度の高い通知を行ってもよい。
【0259】
一方、登録番号が被介助者Ｂに対応する場合、被介助者Ｂは、自身の居室において、衣類に手を入れた状況である。つまり、上述したように、状況に応じて深刻度が高く通知が必要である場合もあれば、通知の必要性が低い場合もある。従って処理部１１０は、被介助者Ｂの通信タグ４７０が読み取られた場合、他のデバイスやアプリケーションからの情報に基づいて端末装置２００への通知を行うか否かを判定してもよい。例えば図２６に示したように、排便が検知されたがオムツ交換対応が行われない場合、排尿が検知された場合、排便と排尿を分類しないときに排泄が検知された場合、及び、ポジショニングアプリケーションの終了から所定期間の間である場合の少なくとも１つが満たされた場合に、処理部１１０は端末装置２００への通知を行う。あるいは図２７に示したように、排泄が行われる蓋然性の高いタイミングを含む所定期間内である場合に、処理部１１０は端末装置２００への通知を行ってもよい。
【0260】
またリーダの電源がオンに設定される条件は上記の例に限定されない。例えばリーダは、検出装置４３０によって、体動が閾値以上と判定された場合に電源がオンに設定されてもよい。いじりが行われる場合、平常時に比べて体動が大きくなることが想定される。従って、体動が閾値未満であれば、いじりを行っていない蓋然性が高いため、上記条件により不必要な通知を抑制できる。
【0261】
またリーダは、不穏スコアが閾値以上と判定された場合にオンに設定されてもよい。不穏スコアは、例えば検出装置４３０からの生体情報（呼吸、心拍、活動量等）に基づいて求められてもよい。不穏スコアが高い場合、被介助者は認知症を患っている蓋然性が高く、不潔な行動であるいじりを行ってしまう可能性がある。そのため、不穏スコアを用いることによって、必要性が高い状況で通知を行うことが可能になる。
【0262】
また、便検知、体動、不穏スコア等の情報は、いじり検知のオン／オフの切り替えに用いられるものには限定されない。例えば、いじり検知はオン状態を維持しつつ、便検知、体動、不穏スコア等の情報を付加情報としていじり検知結果に対応付ける処理が行われてもよい。このようにすれば、介助者は、いじりが通知された原因を理解しやすくなる。例えば、いじりの通知に合わせて便検知が通知された場合、オムツ交換によりいじりを抑制できるといった対応決定が容易になる。
【0263】
またいじりに関する判定結果に基づいて、ＡＤＬや看取りケアに関する評価処理が行われてもよい。この場合、例えば、一日分のデータが収集された際に、評価処理が自動的に実行されてもよい。
【0264】
またいじりの検知を通知する際に、介入の有無や介入タイミングの提案が行われてもよい。例えば、時系列的に、排泄検知→いじり検知→介入→睡眠という流れの例を考える。この場合、それまで睡眠状態にあった被介助者は、少なくとも介入後の段階では中途覚醒していると考えられる。この場合、速やかに睡眠状態に再移行し、翌朝の起床時間まで睡眠をとることが望ましい。しかし、具体的な状況に応じて、寝付きがよくなりやすい介入タイミングが異なる可能性もある。具体的な状況とは、いじりの検知時刻、付加情報（便検知、体動、不穏スコア）の内容、被介助者の属性等が考えられる。例えば処理部１１０は、いじりの検知結果、及び付加情報の内容に基づいて、介入時の寝付きの程度を評価してもよい。例えば処理部１１０は、評価値が所定値以上の場合に介入を提案し、評価値が所定値未満の場合に介入を提案しない処理を行ってもよい。あるいは処理部１１０は、評価結果に基づいて好ましい介入タイミングを推定し、推定結果を介助者の端末装置２００に通知してもよい。
【0265】
また端末装置２００は、いじりの通知を受けた介助者が行った対応（介入）を入力可能であってもよい。この処理は、例えばいじり検出アプリケーションに従って処理部２１０が動作することによって実現されてもよいし、他のアプリケーションを用いて実現されてもよい。ここでの介入には、オムツの当て方を直す、トイレ誘導する、声かけする、ワセリンを塗る、等の種々の対応を含むことが可能である。
【0266】
例えば処理部１１０は、介入の内容と、介入後に検出装置４３０等を用いて取得される睡眠状態に関する情報に基づいて、介入内容と、介入後の睡眠スコアとの対応関係を求めてもよい。睡眠スコアとは、睡眠の質を表す指標値であり、睡眠時間、睡眠の深さ、中途覚醒の頻度や継続時間、ベッドに入ってから睡眠状態に移行するまでの時間等に基づいて決定される。例えば処理部１１０は、被介助者に関する介入内容と睡眠スコアの関係に基づいて、介入後に眠りにつきやすい介入内容を決定し、当該介入内容を端末装置２００に通知してもよい。また処理部１１０は、介助を行うべきか否かを通知してもよいし、介入を行う際の注意点等を通知してもよい。
【0267】
４．４ ポジショニングアプリケーション
次にポジショニングアプリケーションの具体的な画面インターフェイスの例について説明する。上述したように、ポジショニングアプリケーションは、設定を行う設定モードと、当該設定に従って実際のポジション調整をサポートする利用モードで動作してもよい。
次にポジショニングアプリケーションの具体的な画面インターフェイスの例について説明する。上述したように、ポジショニングアプリケーションは、設定を行う設定モードと、当該設定に従って実際のポジション調整をサポートする利用モードで動作してもよい。
【0268】
図２９Ａ～図２９Ｄは、例えば設定モードにおいて熟練の介助者が正解データを入力する際に用いられる画面の例である。例えば介助者は、図２９Ａに示すように、端末装置２００の撮像部２６０を用いて、位置姿勢が正しいと考えられる状態の撮像画像を撮像する。図２９Ａでは、被介助者が正しい寝姿勢をとるとともに、複数のクッションが望ましい位置に配置された状態を撮像した画像が正解データとして取得される。
【0269】
図２９Ｂ～図２９Ｄは、撮像画像に対して付加情報を追加する際に用いられる画面例である。例えばポジショニングアプリケーションは、設定モードにおいて、テキストや図形を付加する画面（図２９Ｂ）、骨格トラッキングの結果に関する情報を付加する画面（図２９Ｃ）、オブジェクト検出処理の結果に関する情報を付加する画面（図２９Ｄ）を表示してもよい。
【0270】
ポジショニングアプリケーションは、例えば図２９Ａに示す画面において撮像画像が取得された場合に、図２９Ｂに示す画面に遷移してもよい。そして、ポジショニングアプリケーションは、図２９Ｂに示す画面において、画面を左にスワイプする操作が行われた場合に、図２９Ｃに示す画面に遷移する処理を行う。同様にポジショニングアプリケーションは、図２９Ｃに示す画面において、画面を左にスワイプする操作が行われた場合に、図２９Ｄに示す画面に遷移する処理を行う。また画面を右にスワイプする操作が行われた場合、図２９Ｄ→図２９Ｃ→図２９Ｂに示す順に画面遷移が行われてもよい。またポジショニングアプリケーションは、画面上部に設けられる「透かす写真」、「Ｓｋｅｌｔｏｎ」、「Ｏｂｊｅｃｔ」の各タブの選択操作に基づいて、図２９Ｂ～図２９Ｄに示す画面間での遷移処理を実行してもよい。このようにすれば、各種の付加情報をわかりやすいインターフェイスを用いて介助者に入力させることが可能になる。以下、それぞれの付加情報の入力画面について説明する。
【0271】
図３０Ａ～図３０Ｄは、テキストや画像を付加する画面の例である。図３０Ａは、図２９Ｂと同様の画面であり、例えばテキスト等の付加に用いられる基本画面である。図３０Ａに示すように、この画面は、付加対象となる情報に応じて「テキスト入力」、「図形追加」、「音声」の各項目を表すアイコンや文字列が表示されてもよい。また図３０Ａに示す画面は、正解データを重畳する際の透過率を設定するためのアイコンを含んでもよい。
【0272】
図３０Ｂは、図３０Ａに示す画面において、「テキスト入力」に対応するアイコンが選択された場合に表示されるテキスト入力画面の例である。テキスト入力画面では、例えば図３０Ｂに示すように、テキストを入力するためのテキストボックスが表示される。当該テキストボックスの選択操作が行われた場合、ポジショニングアプリケーションは不図示のソフトウェアキーボード等、テキスト入力用のインターフェイスを表示し、介助者によるテキスト入力を受け付ける。図３０Ｃは、介助者によるテキスト入力後の画面例である。図３０Ｃの例では、「膝下に入れるクッションは３つ。足側のクッションは横にしてください」、「左足と右足の間にもクッションをいれてください」というクッションの配置に関する説明文が入力されている。なお図３０Ｂ及び図３０Ｃに示すように、テキストボックスの背景色、フォントの太さ、フォントの色等が変更可能であってもよい。またテキストボックスの向きや画面上での位置が変更可能であってもよい。
【0273】
図３０Ｄは、図３０Ａに示す画面において、「図形追加」に対応するアイコンが選択された場合に表示される図形追加画面の例である。図形追加画面では、例えば図３０Ｄに示すように、長方形、円形、直線等の図形の種類と、当該図形の色を選択するためのアイコンが表示される。図３０Ｄでは、直線が選択された例を示している。例えば介助者は、撮像画像に重畳して表示される図形の変形や回転を行うことによって、撮像画像の任意の位置に種々の図形を追加可能である。例えば図３０Ｄに示すように、被介助者の膝を立てる際の角度を指定するための直線が付加されてもよい。あるいは、クッションの位置やサイズを特定するために、対象となるクッションに重なるように何らかの図形が付加されてもよい。
【0274】
図３１Ａ～図３１Ｂは、骨格トラッキング結果に関する情報を付加する画面の例である。図３１Ａは、図２９Ｃと同様の画面であり、例えば撮像画像に対して、骨格トラッキング結果が重畳表示される画面である。図３１Ａに示すように、骨格トラッキング結果は、被介助者（または介助者）の肩、肘、手首、腰、股関節、膝、足首等、所定数の位置を表す点と、各点を接続する線分を含んでもよい。この画面は、検出された点のうち重要と考えられる点の選択を促すテキストを含んでもよい。図３１Ａの例では、骨格トラッキング結果に含まれる所定数（例えば１７点）の点のうち、２点または３点の選択を促すテキストが表示されている。選択された点は、正誤判定（ＯＫ／ＮＧ）や介助実行時の具体的な指示に用いられる。
【0275】
図３１Ｂは、骨格トラッキング結果のうちの何れかの点が選択された状態の画面例である。図３１Ｂの例では、足首に対応する点が選択されたことによって、当該点の色が他の点と異なる色に変更されている。ただし、選択された点が識別可能であればよく、具体的な表示態様は種々の変形実施が可能である。
【0276】
図３２Ａ～図３２Ｂは、オブジェクト検出結果に関する情報を付加する画面の例である。図３２Ａは、図２９Ｄと同様の画面であり、例えば撮像画像に対して、クッションを対象としたオブジェクト検出処理が行われ、検出されたクッションを含む矩形領域が表示される画面である。なお、オブジェクト検出の対象はクッションに限定されない。この画面は、例えば特に重要と考えられるオブジェクトの選択を促すテキストを含んでもよい。図３１Ａの例では、重要なクッションの選択を促すテキストが表示されている。またより精度の高い正誤判定や、介助時に分かりやすい指示を行うために、骨格トラッキング結果とオブジェクト検出に対する選択入力を連動させてもよい。例えば図３２Ａでは、オブジェクトの選択を促すテキストとともに、骨格トラッキング結果での点の選択を促すテキストが表示される。
【0277】
図３２Ｂは、オブジェクト検出結果のうちの何れかのオブジェクトが選択された状態の画面例である。図３２Ｂの例では、膝下に配置される小型のクッションのうちの１つが選択されたことによって、当該クッションを囲む矩形が他の矩形と異なる色または太さに変更されている。ただし、選択されたオブジェクトが識別可能であればよく、具体的な表示態様は種々の変形実施が可能である。
【0278】
図２９Ａ～図３２Ｂに示す画面を用いることによって、撮像画像に対して種々の付加情報を付加することが可能になる。特に、テキストまたは図形（図３０Ａ～図３０Ｄ）、骨格トラッキング（図３１Ａ、図３１Ｂ）、オブジェクト検出（図３２Ａ、図３２Ｂ）のそれぞれについて異なる画面を用い、各画面間をスワイプ操作等により遷移可能とすることによって、入力操作を分かりやすくすることが可能である。例えば、コンピュータやソフトウェアに関する介助者の知識が乏しい場合であっても、当該介助者に適切に付加情報を入力させることができる。
【0279】
なお、ポジショニングアプリケーションは、図２９Ａ～図３２Ｂに示す画面を用いて行われた設定の結果をサーバシステム１００に送信してもよい。例えば諸所の設定を行ったのちに、登録ボタンを押すと図２９から図３２までで行った設定がまとめて登録される。またポジショニングアプリケーションは、登録ボタンを押す操作が行われた場合に、アンケートをポップアップで出力してもよい。アンケートは、ポジションアプリの目的や、注意すべきまたは注目すべき骨格部位、ご利用者の属性等を含む。ポジションアプリケーションは、設定情報とともに、このアンケートの結果をサーバシステム１００に送信する。このようにすれば、具体的な設定内容に加えて、設定を行った介助者の意図や、被介助者の情報等を収集することが可能になる。
【0280】
例えばサーバシステム１００は、類似する目的・骨格部位・利用者属性ごとにポジションアプリケーションで収集した設定情報をカテゴライズしてもよい。サーバシステム１００は、例えば類似する目的・骨格部位・利用者属性ごとに設定情報を学習する。このようにすれば、類似する目的・骨格部位・利用者属性毎に、好ましいと推定される設定情報を決定できる。結果として、介助者が設定情報を具体的に設定せずとも、類似する目的・骨格部位・利用者属性を選択するだけで正誤判定や姿勢またはクッションの配置指示を行うアプリケーションを生成することが可能になる。例えば、介助者の熟練度によらず、適切な設定が行われたポジショニングアプリケーションを生成することが可能である。
【0281】
図３３Ａ～図３３Ｃは、上記の画面を用いて入力された付加情報を含む正解データの表示画面を例示する図である。例えば透過処理が施された正解データが、リアルタイムの撮像画像に重畳して表示されるが、図面の見やすさの便宜上、図３３Ａ及び図３３Ｂではリアルタイムの撮像画像を省略している。なお、図３３Ａ～図３３Ｃに示す画面は、設定モードの完了後に実行される利用モードで表示されてもよいし、設定モードの中で正解データを確認するためのプレビューとして表示されてもよい。
【0282】
図３３Ａの例では、設定時に撮像された撮像画像、図３０Ｂや図３０Ｃに示す画面を用いて入力されたテキスト、及び、図３０Ｄに示す画面を用いて入力された図形が正解データとして表示される。ポジショニングアプリケーションを利用する介助者は、テキスト、図形等を参照しつつ被介助者が正解データに近づくように介助を行うことによって、被介助者の姿勢を適切に調整することが可能になる。なお、正解データが複数存在する場合、画面下部に示すアイコンによって、正解データの切り替えが可能であってもよい。図３３３Ａでは、２つの正解データが登録済みであり、そのうちの１番目の正解データが表示された状態を示している。なおここでの複数の正解データとは、同じ被介助者を対象としたものであってもよいし、異なる被介助者を対象としたものであってもよい。
【0283】
なお、ポジショニングアプリケーションは正解データの透過処理だけでなく、正誤判定を行う機能、姿勢を指示する情報を提示する機能、クッションの配置指示を行う情報を提示する機能、クッション等の介助器具をレコメンドする機能等を有してもよい。これらの機能は、それぞれについてオン／オフが切り替え可能であってもよい。
【0284】
例えば、介護施設等においてある程度の経験がある介助者は、熟練介助者のような暗黙知を備えていなかったとしても、透過処理が施された画像等が表示されれば、それに合わせて位置調整を行うことは可能であると考えられる。この場合、姿勢等の指示を提示することによって、かえって煩わしさを感じさせてしまう場合もあるし、当該指示に従うことに注力することによって自ら考える（スキルを向上させる）ことを怠る可能性もある。よってこのような介助者を対象とする場合、上記の各機能はオフに設定されてもよい。
【0285】
一方、介護施設の新人介助者や、被介助者の家族が在宅介護を行う場合には、単に正解となる画像のみが提示されても、重要なポイントを理解できず、望ましい調整を実行できない可能性がある。よってこのような介助者については、上記の各機能はオンに設定されてもよい。
【0286】
各機能のオン／オフは、例えばポジショニングアプリケーションの設定項目として個別に切り替えが可能であってもよい。図３３Ｂは、機能のオン／オフを切り替える設定画面例である。図３３Ｂの画面は、例えば図３３Ａにおいて不図示の設定ボタンの選択操作が行われた場合や、画面左部を右にスワイプする操作が行われた場合に表示される。ただし、他の操作により図３３Ｂに示す画面が表示されてもよい。図３３Ｂの例では、各機能に対応するボタンの選択またはスライド操作が実行されることによって、当該機能のオン／オフが切り替えられる。
【0287】
図３３Ｃは、各機能が用いられる場合のポジショニングアプリケーションの表示画面例である。図３３Ｃでは、透過処理が施された正解データが図３３Ａと同様に破線で示され、リアルタイムに撮像された被介助者やクッションが実線で表示されている。例えば正誤判定機能がオンになっている場合、ポジショニングアプリケーションは、正解データに基づいて対象（図３３Ｃの例では被介助者）の位置や姿勢が適切であるか否かを判定し、判定結果を画面の上部に「ＯＫ」または「ＮＧ」と表示してもよい。骨格トラッキングに基づく正誤判定としては、例えば設定モードで検出された点のうち３点を選んだ順番に線を結んだ時の内角を基準として、利用モードでは、設定モードで選択された３点をリアルタイムの撮像画像から検出し、その内角が所定範囲にあるかどうかで判定してもよい。またポジショニングアプリケーションは、オブジェクト検出結果を用いた正誤判定を行ってもよい。例えばポジショニングアプリケーションは、設定モードで検出された点のうち少なくとも１点と選択されたオブジェクトの位置関係を基準として設定する。ここでの１点は、例えば骨格トラッキング結果で検出された点のいずれかであるが、他の点が用いられてもよい。そしてポジショニングアプリケーションは、利用モードでは、設定モードで選択された１点とオブジェクトをリアルタイムの撮像画像から検出し、基準に合致するオブジェクトがあるかどうかを判定する。ポジショニングアプリケーションは、基準に合致しない場所にオブジェクトがある場合には、不正解（ＮＧ）と判定してもよい。
【0288】
また姿勢指示機能がオンである場合、ポジショニングアプリケーションは、対象の姿勢を適切に調整させるための具体的な情報を提示する。図３３Ｃの例では、リアルタイムの撮像画像に対する骨格トラッキング処理が行われ、図３１Ｂに示す画面で選択された重要な点（ここでは足首）が表示される。ポジショニングアプリケーションは、リアルタイムの撮像画像から検出された点と、正解データにおける点を比較し、例えば図３３Ｃに示すように点の位置を移動させるべき方向を矢印とテキストで提示する。これにより、介助者が修正すべき点をわかりやすく提示することが可能になる。あるいはポジショニングアプリケーションは、利用モードにおいて、正誤判定の例と同様に設定モードで選択された３点をリアルタイムの撮像画像から検出してもよい。そしてポジショニングアプリケーションは、リアルタイムに検出された３点の内角の値が、正解データにおける内角の値に近づくように、当該３点の内の少なくとも一つの部位の調整を指示する。
【0289】
またクッション指示機能がオンである場合、ポジショニングアプリケーションは、クッションの配置を適切にするための具体的な情報を提示する。図３３Ｃの例では、リアルタイムの撮像画像に対するオブジェクト検出処理が行われ、そのうち、図３２Ｂに示す画面で選択されたオブジェクト（例えば膝下のクッション）を示す矩形領域が表示される。ポジショニングアプリケーションは、リアルタイムの撮像画像から検出されたオブジェクトと、正解データにおけるオブジェクトの位置姿勢を比較し、例えば図３３Ｃに示すようにクッションを移動させるべき方向を矢印とテキストで提示する。これにより、介助者が修正すべき点をわかりやすく提示することが可能になる。また上述したように、ポジショニングアプリケーションは、設定モードで選択された１点とオブジェクトをリアルタイムの撮像画像から検出し、基準に合致するオブジェクトがない場合に、対象のオブジェクトを基準位置へ追加あるいは移動させる指示を行ってもよい。
【0290】
なお、上記のように本実施形態について詳細に説明したが、本実施形態の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本開示の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語と共に記載された用語は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。また本実施形態及び変形例の全ての組み合わせも、本開示の範囲に含まれる。また情報処理システム、サーバシステム、端末装置、センシングデバイス等の構成及び動作等も、本実施形態で説明したものに限定されず、種々の変形実施が可能である。
【符号の説明】
【0291】
１０…情報処理システム、１００…サーバシステム、１１０…処理部、１２０…記憶部、１３０…通信部、２００…端末装置、２１０…処理部、２２０…記憶部、２３０…通信部、２４０…表示部、２５０…操作部、２６０…撮像部、３００…マスタ機器、３１０…ドック、４００…センシングデバイス、４３０…検出装置、４４０…座面センサ、４４１…クッション、４４２…制御ボックス、４６０…嚥下ムセ検出装置、４６１…スロートマイク、４６２…端末装置、４７０…通信タグ、４７１…第１タグ部、４７２…第２タグ部、６１０…ベッド、６２０…マットレス、６３０…車椅子、６４０…通信機器、６５０…カーテン、６６０…飲料サーバ、６７０…アロマディフューザー、６８０…照明、ＡＴＣ…回路、ＣＬ１－ＣＬ２…クリップ部、ＳＰ…板バネ、Ｒ１－Ｒ３…矩形領域、Ｓｅ１－Ｓｅ４…圧力センサ
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図5】
【図6】
【図7】
【図8A】
【図8B】
【図9A】
【図9B】
【図9C】
【図10】
【図11】
【図12】
【図13】
【図14A】
【図14B】
【図14C】
【図14D】
【図14E】
【図15】
【図16A】
【図16B】
【図17】
【図18A】
【図18B】
【図18C】
【図18D】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29A】
【図29B】
【図29C】
【図29D】
【図30A】
【図30B】
【図30C】
【図30D】
【図31A】
【図31B】
【図32A】
【図32B】
【図33A】
【図33B】
【図33C】