特開 2024-173147 情報処理システム、情報処理方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024173147

(43)【公開日】2024-12-12

(54)【発明の名称】情報処理システム、情報処理方法、及びプログラム

(51)【国際特許分類】

   G06Q 10/105 20230101AFI20241205BHJP

   G16H 10/00 20180101ALI20241205BHJP

【ＦＩ】

G06Q10/105

G16H10/00

【審査請求】未請求

【請求項の数】18

【出願形態】ＯＬ

(21)【出願番号】P 2023091369

(22)【出願日】2023-06-02

(71)【出願人】

【識別番号】000101617

【氏名又は名称】アマノ株式会社

(74)【代理人】

【識別番号】110003339

【氏名又は名称】弁理士法人南青山国際特許事務所

(72)【発明者】

【氏名】岩室 拓海

(72)【発明者】

【氏名】井本 健太郎

(72)【発明者】

【氏名】今出 守人

(72)【発明者】

【氏名】若杉 祐依

【テーマコード（参考）】

5L010

5L049

5L099

【Ｆターム（参考）】

5L010AA20

5L049AA20

5L099AA15

(57)【要約】

【課題】効率的な業務管理が実現可能となる情報処理システム、情報処理方法、及びプログラムを提供すること。
【解決手段】本発明の一形態に係る情報処理システムは、取得部と、通知部と、回答受付部とを具備する。前記取得部は、従業員の同居人から検出される生体情報を取得する。前記通知部は、取得された前記生体情報が異常である場合に、その旨を前記従業員に通知する。前記回答受付部は、前記通知部からの通知に対して入力される前記従業員からの前記同居人の体調に関する回答を受け付ける。
【選択図】図１０

【特許請求の範囲】

【請求項1】

従業員の同居人から検出される生体情報を取得する取得部と、
取得された前記生体情報が異常である場合に、その旨を前記従業員に通知する通知部と、
前記通知部からの通知に対して入力される前記従業員からの前記同居人の体調に関する回答を受け付ける回答受付部と
を具備する情報処理システム。

【請求項2】

請求項１に記載の情報処理システムであって、
前記通知部は、取得された前記生体情報が異常である旨を、前記従業員の業務を管理する管理者に通知する
情報処理システム。

【請求項3】

請求項１に記載の情報処理システムであって、
前記通知部は、前記従業員からの前記同居人の体調が不良の旨の回答が受け付けられた場合に、その旨を前記従業員の業務を管理する管理者に通知する
情報処理システム。

【請求項4】

請求項２又は３に記載の情報処理システムであって、さらに、
前記従業員及び前記管理者の少なくとも一方により入力される前記従業員の業務に関する所定の手続きを受け付ける手続き受付部を具備する
情報処理システム。

【請求項5】

請求項１に記載の情報処理システムであって、さらに、
前記従業員からの前記同居人の体調が不良の旨の回答が受け付けられた場合に、前記従業員に対して、前記従業員の業務及び前記同居人の体調の不良の少なくとも一方に関する提案を行う提案部を具備する
情報処理システム。

【請求項6】

請求項１に記載の情報処理システムであって、
前記通知部は、前記従業員の居住空間に配置される音声入出力装置を介して、音声により、取得された前記生体情報が異常である旨を通知し、
前記回答受付部は、前記音声入出力装置を介して音声により入力される、前記従業員からの前記同居人の体調に関する回答を受け付ける
情報処理システム。

【請求項7】

請求項１に記載の情報処理システムであって、さらに、
前記従業員及び前記同居人の各々の発話内容を解析する発話解析部と、前記発話解析部による解析結果に基づいて、所定の応答処理を実行する応答処理部とを具備する
情報処理システム。

【請求項8】

請求項７に記載の情報処理システムであって、
前記取得部は、前記発話内容が解析された結果、前記同居人の体調が不良である可能性が検出された場合に、前記生体情報を取得する
情報処理システム。

【請求項9】

請求項８に記載の情報処理システムであって、
前記取得部は、前記発話内容が解析された結果、前記同居人のうち特定の人物の体調が不良である可能性が検出された場合、前記特定の人物から検出される前記生体情報を取得する
情報処理システム。

【請求項10】

請求項７に記載の情報処理システムであって、
前記応答処理部は、前記発話内容が解析された結果、前記同居人の体調が不良である可能性が検出された場合に、前記同居人から前記生体情報を検出するセンサに対して前記生体情報の出力を指示する
情報処理システム。

【請求項11】

請求項１０に記載の情報処理システムであって、
前記応答処理部は、前記発話内容が解析された結果、前記同居人のうち特定の人物の体調が不良である可能性が検出された場合、前記特定の人物から前記生体情報を検出するセンサに対して前記生体情報の出力を指示する
情報処理システム。

【請求項12】

請求項７に記載の情報処理システムであって、
前記応答処理部は、前記発話内容が解析された結果、前記従業員からの前記同居人の体調が不良である旨の回答が検出された場合、前記従業員の業務及び前記同居人の体調の不良の少なくとも一方に関する提案を行う
情報処理システム。

【請求項13】

請求項７に記載の情報処理システムであって、
前記応答処理部は、前記発話内容が解析された結果、前記従業員の業務及び前記同居人の体調の不良の少なくとも一方に関する指示が検出された場合、前記指示に応じた応答処理を実行する
情報処理システム。

【請求項14】

請求項７に記載の情報処理システムであって、
前記応答処理部は、前記従業員の業務に関する業務情報、及び流行している病気、天候、及び社会情勢の少なくとも１つを含む社会情勢・環境情報の少なくとも一方を反映させて、前記応答処理を実行する
情報処理システム。

【請求項15】

請求項１４に記載の情報処理システムであって、
前記応答処理部は、前記応答処理に反映させる項目に関する重み付け情報に基づいて、前記業務情報及び前記社会情勢・環境情報の少なくとも一方を反映させて、前記応答処理を実行する
情報処理システム。

【請求項16】

請求項７に記載の情報処理システムであって、
前記応答処理部は、前記発話内容が解析された結果、体調が重篤である人物が存在する可能性が検出された場合、救急車の出動を要請する
情報処理システム。

【請求項17】

従業員の同居人から検出される生体情報を取得し、
取得された前記生体情報が異常である場合に、その旨を前記従業員に通知し、
前記通知に対して入力される前記従業員からの前記同居人の体調に関する回答を受け付ける
ことをコンピュータが実行する情報処理方法。

【請求項18】

従業員の同居人から検出される生体情報を取得するステップと、
取得された前記生体情報が異常である場合に、その旨を前記従業員に通知するステップと、
前記通知に対して入力される前記従業員からの前記同居人の体調に関する回答を受け付けるステップと
をコンピュータに実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、従業員の業務管理等に適用可能な情報処理システム、情報処理方法、及びプログラムに関する。

【背景技術】

【0002】

特許文献１に記載の健康管理システムでは、ユーザを認証するための生体認証情報を取得するタイミングで、同時にユーザの体温情報が測定される。これにより、簡単にユーザの健康状態の情報を取得することが可能となり、出勤可否を判断することが可能となる。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許７２１１６６３号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

このような効率的な業務管理を実現可能とする技術が求められている。

【0005】

以上のような事情に鑑み、本発明の目的は、効率的な業務管理が実現可能となる情報処理システム、情報処理方法、及びプログラムを提供することにある。

【課題を解決するための手段】

【0006】

上記目的を達成するため、本発明の一形態に係る情報処理システムは、取得部と、通知部と、回答受付部とを具備する。
前記取得部は、従業員の同居人から検出される生体情報を取得する。
前記通知部は、取得された前記生体情報が異常である場合に、その旨を前記従業員に通知する。
前記回答受付部は、前記通知部からの通知に対して入力される前記従業員からの前記同居人の体調に関する回答を受け付ける。

【0007】

前記通知部は、取得された前記生体情報が異常である旨を、前記従業員の業務を管理する管理者に通知してもよい。

【0008】

前記通知部は、前記従業員からの前記同居人の体調が不良の旨の回答が受け付けられた場合に、その旨を前記従業員の業務を管理する管理者に通知してもよい。

【0009】

前記情報処理システムは、さらに、前記従業員及び前記管理者の少なくとも一方により入力される前記従業員の業務に関する所定の手続きを受け付ける手続き受付部を具備してもよい。

【0010】

前記情報処理システムは、さらに、前記従業員からの前記同居人の体調が不良の旨の回答が受け付けられた場合に、前記従業員に対して、前記従業員の業務及び前記同居人の体調の不良の少なくとも一方に関する提案を行う提案部を具備してもよい。

【0011】

前記通知部は、前記従業員の居住空間に配置される音声入出力装置を介して、音声により、取得された前記生体情報が異常である旨を通知してもよい。この場合、前記回答受付部は、前記音声入出力装置を介して音声により入力される、前記従業員からの前記同居人の体調に関する回答を受け付けてもよい。

【0012】

前記情報処理システムは、さらに、前記従業員及び前記同居人の各々の発話内容を解析する発話解析部と、前記発話解析部による解析結果に基づいて、所定の応答処理を実行する応答処理部とを具備してもよい。

【0013】

前記取得部は、前記発話内容が解析された結果、前記同居人の体調が不良である可能性が検出された場合に、前記生体情報を取得してもよい。

【0014】

前記取得部は、前記発話内容が解析された結果、前記同居人のうち特定の人物の体調が不良である可能性が検出された場合、前記特定の人物から検出される前記生体情報を取得してもよい。

【0015】

前記応答処理部は、前記発話内容が解析された結果、前記同居人の体調が不良である可能性が検出された場合に、前記同居人から前記生体情報を検出するセンサに対して前記生体情報の出力を指示してもよい。

【0016】

前記応答処理部は、前記発話内容が解析された結果、前記同居人のうち特定の人物の体調が不良である可能性が検出された場合、前記特定の人物から前記生体情報を検出するセンサに対して前記生体情報の出力を指示してもよい。

【0017】

前記応答処理部は、前記発話内容が解析された結果、前記従業員からの前記同居人の体調が不良である旨の回答が検出された場合、前記従業員の業務及び前記同居人の体調の不良の少なくとも一方に関する提案を行ってもよい。

【0018】

前記応答処理部は、前記発話内容が解析された結果、前記従業員の業務及び前記同居人の体調の不良の少なくとも一方に関する指示が検出された場合、前記指示に応じた応答処理を実行してもよい。

【0019】

前記応答処理部は、前記従業員の業務に関する業務情報、及び流行している病気、天候、及び社会情勢の少なくとも１つを含む社会情勢・環境情報の少なくとも一方を反映させて、前記応答処理を実行してもよい。

【0020】

前記応答処理部は、前記応答処理に反映させる項目に関する重み付け情報に基づいて、前記業務情報及び前記社会情勢・環境情報の少なくとも一方を反映させて、前記応答処理を実行してもよい。

【0021】

前記応答処理部は、前記発話内容が解析された結果、体調が重篤である人物が存在する可能性が検出された場合、救急車の出動を要請してもよい。

【0022】

本発明の一形態に係る情報処理方法は、コンピュータが実行する情報処理方法であって、従業員の同居人から検出される生体情報を取得することを含む。
取得された前記生体情報が異常である場合に、その旨が前記従業員に通知される。
前記通知に対して入力される前記従業員からの前記同居人の体調に関する回答が受け付けられる。

【0023】

本発明の一形態に係るプログラムは、コンピュータに以下のステップを実行させる。
従業員の同居人から検出される生体情報を取得するステップ。
取得された前記生体情報が異常である場合に、その旨を前記従業員に通知するステップ。
前記通知に対して入力される前記従業員からの前記同居人の体調に関する回答を受け付けるステップ。

【発明の効果】

【0024】

以上のように、本発明によれば、効率的な業務管理が実現可能となる。

【図面の簡単な説明】

【0025】

【図1】第１の実施形態に係る業務管理システムを適用することが可能な従業員の家族構成例を示す模式図である。

【図2】業務管理システムの構成例を示す説明するための模式図である。

【図3】サーバ装置の機能的な構成例を示すブロック図である。

【図4】ＤＢに記憶される業務情報の一例を示す模式図である（従業員データテーブル）。

【図5】ＤＢに記憶される業務情報の一例を示す模式図である（同居人データテーブル）。

【図6】ライフログ情報取得部により取得されるライフログ情報の一例を示す模式図である。

【図7】生体情報の異常判定に用いられる判定基準値の一例を示す模式図である。

【図8】ＤＢに業務情報として記憶される休暇申請情報の一例を示す模式図である。

【図9】サーバ装置の基本的な動作例を示すフローチャートである。

【図10】とくに同居人の生体情報に対して動作する処理例を示すフローチャートである。

【図11】業務管理システムにおける処理例を示すフローチャートである。

【図12】従業員端末に表示される異常通知画面の一例を示す模式図である。

【図13】サーバ装置から管理端末への通知例を示すフローチャートである。

【図14】管理端末に表示される異常通知画面の一例を示す模式図である。

【図15】管理端末に表示される異常通知画面の一例を示す模式図である。

【図16】第２の実施形態に係る業務管理システムを適用することが可能な従業員の家族構成例を示す模式図である。

【図17】業務管理システムの構成例を示す説明するための模式図である。

【図18】ＤＢに記憶される業務情報の一例を示す模式図である（従業員データテーブル）。

【図19】業務管理システムにおける処理例を示すフローチャートである。

【図20】とくに同居人の体調不良に着目して動作する処理例を示すフローチャートである。

【図21】センサ装置、管理端末、サーバ装置、及びスマートスピーカとして用いることが可能なコンピュータのハードウェア構成例を示すブロック図である。

【発明を実施するための形態】

【0026】

以下、本発明に係る実施形態を、図面を参照しながら説明する。

【0027】

＜第１の実施形態＞
［業務管理システム］
図１及び図２は、本発明の第１の実施形態に係る業務管理システムの構成例を説明するための模式図である。業務管理システム１は、企業等の団体における業務管理を行うことが可能である。例えば、企業等の団体に所属する従業員２の業務に関する種々の手続きを実行し、従業員２ごとの業務に関する業務情報を管理することが可能である。

【0028】

とくに、本実施形態に係る業務管理システム１は、従業員２の健康状態が業務に影響を与える点に着目し、効率的な業務管理を実現することを目的として構築される。本業務管理システム１を、健康管理システムと呼ぶことも可能である。

【0029】

本開示において、業務管理は、業務に関する任意の事項に対する任意の管理業務を含む。例えば、就業管理、勤怠管理、人事管理、予算管理等が、本技術に関する業務管理に含まれる。また、業務内容に関する任意の事項に対する管理業務も、業務管理に含まれる。例えば、業務計画の立案、業務内容の見直し、人員の配置等も、業務管理に含まれる。

【0030】

図１は、本業務管理システム１を適用することが可能な従業員２の家族構成例を示す模式図である。図１に示す例では、従業員２が「Living room」「Hobby room」「Bed room」を備える居住空間Ｓにて、妻と子供と３人で生活している。妻及び子供は、従業員２にとって同居人３となる（妻を３ａとし、子供を３ｂとする）。

【0031】

本開示において、従業員２の同居人３とは、居住空間Ｓの少なくとも一部を、従業員２と共有する任意の人物を含むものとする。例えば、一軒家やマンション等の居住空間Ｓにて、ともに生活をおくる人物は、従業員２の同居人３に含まれる。また、社員寮やシェアハウス等の、各々が主に自分の部屋で生活しつつ「Living room」やお風呂等の所定の居住空間Ｓを従業員２と共有して生活する人物も、従業員２の同居人３に含まれる。

【0032】

図１に例示したような従業員２の家族に限定されず、従業員２の友人やルームメイト等、様々な人物が従業員２の同居人３になり得る。また従業員２が、他の従業員２の同居人３となる場合もあり得る。

【0033】

図２は、業務管理システム１の構成例を示す説明するための模式図である。本業務管理システム１では、従業員２及び同居人３の各々から検出されるライフログ情報、とくに生体情報が有効に活用される。以下、詳しく説明する。

【0034】

図２に示すように、業務管理システム１は、センサ装置５と、従業員端末６と、管理端末７と、サーバ装置８と、データベース（ＤＢ）９とを含む。

【0035】

センサ装置５、従業員端末６、管理端末７、及びサーバ装置８は、ネットワーク１０を介して、互いに通信可能に接続されている。ネットワーク１０は、例えばインターネットや広域通信回線網等により構築される。その他、任意のＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）等が用いられてよく、ネットワーク１０を構築するためのプロトコルは限定されない。

【0036】

センサ装置５、従業員端末６、管理端末７、及びサーバ装置８は、例えばＣＰＵ、ＧＰＵ、ＤＳＰ等のプロセッサ、ＲＯＭ、ＲＡＭ等のメモリ、ＨＤＤ等の記憶デバイス等、コンピュータに必要なハードウェアを有する（図２１参照）。プロセッサが記憶部やメモリに記憶されている本技術に係るプログラムをＲＡＭにロードして実行することにより、本技術に係る情報処理方法（健康管理方法）が実行される。

【0037】

センサ装置５は、従業員２及び同居人３のライフログ情報を検出し、ネットワーク１０を介して、サーバ装置８に送信する。

【0038】

本開示において、ライフログ情報は、日々の生活を送る従業員２及び同居人３の様々な行いや様々な状態が記録された任意のログ情報を含む。例えば、従業員２及び同居人３の位置情報（行動履歴情報）や生体情報のログ情報が、ライフログ情報に含まれる。

【0039】

例えば、従業員２及び同居人３の現在地の情報、さらに詳しく屋内であるか、屋外であるか、会議中であるか等の情報が、ライフログ情報に含まれる。また例えば、移動距離、移動時間、移動速度、歩数、歩いた距離、走った距離、使用した交通手段、交通手段を利用した時間、交通手段で移動した距離等が、ライフログ情報に含まれる。

【0040】

また、従業員２及び同居人３の様々な生体情報が、ライフログ情報に含まれる。なお、本開示において、生体情報は、生体に関する任意の情報を含むものとする。

【0041】

例えば、従業員２及び同居人３の生体的な特徴を示す任意の情報や、従業員２及び同居人３の生体的な特徴を抽出することが可能な任意の情報は、生体情報に含まれる。また従業員２及び同居人３が活動することで生み出される任意の情報は、生体情報に含まれる。その他、生体に関する任意の情報が、生体情報に含まれる。

【0042】

例えば、体温、血圧、脈拍数、心拍数、発汗量、血糖値、水分量、体脂肪率、体重、身長、筋肉量バランス、骨密度、呼吸数、肺活量、血液検査の結果、ＭＲＳの検査結果、尿検査、血中アルコール濃度等が生体情報に含まれる。また、睡眠状態であるか覚醒状態であるか、どのような睡眠状態であるか（レム睡眠、ノンレム睡眠、深い睡眠、浅い睡眠等）の情報も、生体情報に含まれる。

【0043】

また従業員２及び同居人３が行う運動に関する運動情報も、生体情報に含まれる。例えば歩行中、走行中、電車にて移動中、運転中等の情報が、生体情報として取得可能である。また座っているか、立っているか、前屈みか、横を向いているか、上を向いているか等の、姿勢に関する情報等も、生体情報として取得可能である。

【0044】

また、カメラにより撮影された従業員２及び同居人３の画像や、マイクにより取得された従業員２及び同居人３の会話等の音声情報等も、生体情報に含まれる。なお本開示において、画像は、静止画像及び動画像（映像）の両方を含む。

【0045】

上記のような様々なライフログ情報は、例えば、ＩＭＵ（Inertial Measurement Unit）センサ、ＧＰＳ、様々な種類の生体センサ、イメージセンサ（カメラ）等の、各種センサを用いて検出することが可能である。これらのセンサにより検出される検出結果（値等）自体を、ライフログ情報として利用することが可能である。これに限定されず、センサにより検出される検出結果に基づいて、さらに様々なライフログ情報を生成することも可能である。

【0046】

例えばＧＰＳにより位置情報として緯度及び経度の座標値がライフログ情報として検出される。当該ライフログ情報に基づいて、従業員２及び同居人３が立ち寄ったランドマーク等の情報を含む行動履歴情報が、さらにライフログ情報として生成されてもよい。

【0047】

また、体温を測定可能な温度センサ、心拍数を測定可能な心拍センサ、発汗量を測定可能な発汗センサ等の検出値がライフログ情報（生体情報）として検出される。これらの検出値に基づいて、従業員２及び同居人３の健康状態や睡眠状態等がライフログ情報（生体情報）として生成されてもよい。

【0048】

センサにより検出される検出結果（値等）自体を、ライフログ情報として利用する場合、当該ライフログ情報が検出された時間が、ライフログ情報の検出時間となる。一方で、センサにより検出される検出結果に基づいて、さらに様々なライフログ情報が生成される場合は、ライフログ情報の生成に用いられるセンサの検出結果が検出された時間が、ライフログ情報の検出時間となる。

【0049】

例えば、所定の時刻（年月日時刻Ａとする）にてＩＭＵセンサにより「加速度」が検出されたとする。この場合、当該「加速度」がライフログ情報として利用される場合は、「加速度」が検出された時間（年月日時刻Ａ）が、ライフログ情報の検出時間となる。

【0050】

一方で、年月日時刻ＡにてＩＭＵセンサにより検出された「加速度」に基づいて、「歩行中」というライフログ情報が生成されたとする。この場合、「歩行中」というライフログ情報が生成された時間ではなく、「加速度」が検出された時間（年月日時刻Ａ）が、「歩行中」というライフログ情報の検出時間であるとする。すなわち、従業員２及び同居人３が「歩行中」である年月日時刻が、その「歩行中」というライフログ情報の検出時間となる。

【0051】

センサ装置５は、ライフログ情報を検出可能なセンサを搭載したコンピュータにより構成される。あるいは、ライフログ情報を検出可能であり、ネットワーク１０を介して通信可能なセンサにより構成される。

【0052】

図２に示す例では、センサ装置５として、スマートフォン、ＨＭＤ（眼鏡型のウェアラブルデバイスともいえる）、時計型（リストバンド型）のウェアラブルデバイス、カメラが例示されている。もちろん、これらのデバイスに限定されず、センサ装置５を実現するために様々な構成が採用されてよい。

【0053】

また図２では、従業員２、同居人３ａ（妻）及び同居人３ｂ（子供）の各々に対して、センサ装置５ａ～５ｃが準備されている。これに限定されず、所定の居住空間Ｓに設置されたカメラにより、従業員２、同居人３ａ及び３ｂの画像が撮影され、その撮影画像に基づいて従業員２、同居人３ａ及び３ｂの各々のライフログ情報が取得されてもよい。

【0054】

本開示において、情報等の取得は、当該情報を他の装置から受信すること、及び自ら解析処理、抽出処理、推定処理等を実行することで、当該情報を生成することの両方を含む。すなわち、本開示において、ライフログ情報の取得は、例えばセンサ装置５により検出されたライフログ情報を受信する場合と、センサ装置５の検出結果に基づいてライフログ情報を自身で生成する場合の両方を含む。

【0055】

センサ装置５により、自身で検出した検出結果に基づいて、ライフログ情報が生成されてもよい。また、サーバ装置８により、センサ装置５から受信した検出結果や、センサ装置５により生成されたライフログ情報等に基づいて、さらにライフログ情報が生成されてもよい。

【0056】

ライフログ情報の取得等のために、任意の技術（アルゴリズム等）が用いられてよい。例えばＤＮＮ（Deep Neural Network：深層ニューラルネットワーク）、ＲＮＮ（Recurrent Neural Network：回帰型ニューラルネットワーク）、ＣＮＮ（Convolutional Neural Network：畳み込みニューラルネットワーク）等を用いた任意の機械学習アルゴリズムが用いられてもよい。例えばディープラーニング（深層学習）を行うＡＩ（人工知能）等を用いることで、各処理を高い精度で実行することが可能となる。

【0057】

例えば、ライフログ情報を出力するための機械学習を行った学習済みの学習モデルに、センサの検出結果等を入力することで、ライフログ情報を学習モデルから取得することが可能である。

【0058】

学習モデルの学習方法として、例えば誤差逆伝播法が用いられる。誤差逆伝播法は、ニューラルネットワークの学習のために一般的に良く利用される学習手法である。ニューラルネットワークとは、元々人間の脳神経回路を模倣したモデルであり、入力層、中間層（隠れ層）、出力層の３種類の層からなる層構造を持ったモデルである。

【0059】

多数の中間層を持つニューラルネットワークは特にディープニューラルネットワークと呼ばれ、これを学習するためのディープラーニング技術は、大量データの中に潜んでいる複雑なパターンを学習できるモデルとして知られている。誤差逆伝播法はこのような学習手法の１つであり、例えば、画像や動画の認識に用いられるＣＮＮなどの学習によく用いられる。

【0060】

また、このような機械学習を実現するハードウェア構造としては、ニューラルネットワークの概念を組み込まれたニューロチップ／ニューロモーフィック・チップが用いられ得る。

【0061】

学習モデルを学習させるためのアルゴリズムは限定されず、任意の機械学習アルゴリズムが用いられてよい。例えば、機械学習アルゴリズムとして、教師あり学習、教師なし学習、半教師学習、強化学習、逆強化学習、能動学習、転移学習等が挙げられる。また、ＨＭＭ（Hidden Markov Model：隠れマルコフモデル）やＳＶＭ（Support Vector Machine）等の機械学習モデルが用いられてもよい。

【0062】

学習モデルを学習させるための学習ブロック（学習部）が、センサ装置５やサーバ装置８に構成されてもよい。あるいは、学習ブロック（学習部）が、センサ装置５やサーバ装置８とは異なるコンピュータ内に構成され、学習が実行されたのちの学習済みの学習モデルが、センサ装置５やサーバ装置８に搭載されてもよい。その他、学習モデル、及び学習モデルを学習するための学習ブロック（学習部）の具体的な構成は限定されない。

【0063】

なお機械学習アルゴリズムの適用は、本開示内の任意の処理に対して実行されてよい。すなわち、本開示内にて説明する任意の処理について、機械学習を用いた処理が実行されてよい。

【0064】

また従業員２及び同居人３が撮影された撮影画像からライフログ情報を抽出するための方法も限定されず、任意の技術（アルゴリズム）が用いられてよい。例えば物体のモデル画像を用いたマッチング処理、エッジ検出、射影変換等の任意の画像認識技術が用いられてよい。また骨格推定（ボーン推定）等が用いられてもよい。また外部で構築された既存の画像処理や機械学習等の機能を持つライブラリが利用されてもよい。

【0065】

撮影画像からライフログ情報を抽出するために、任意の機械学習アルゴリズムが用いられてもよい。例えば、画像情報に対してセマンティックセグメンテーションを実行することで、画像内の各画素に対して、物体の種類を判定することも可能となる。

【0066】

サーバ装置８は、業務管理サービスを提供するための装置である。サーバ装置８により、業務管理に関する様々な処理が実行される。例えば、就業管理、勤怠管理、人事管理、予算管理、業務内容に関する任意の事項に対する管理業務に関する様々な処理が実行される。

【0067】

ＤＢ９には、業務に関する任意の情報（業務情報）が記憶される。例えば従業員２の名前、性別、住所、電話番号等の従業員情報や、従業員２ごとに支払われる給与、出退勤、休暇、残業等に関する就業情報や勤怠情報が記憶される。その他、人事、予算、業務内容等に関する任意の情報が、業務情報として記憶される。

【0068】

またＤＢ９には、従業員２の同居人３に関する同居人情報が記憶される。またＤＢ９には、従業員２及び同居人３の各々から検出されるライフログ情報が記憶される。

【0069】

図２に示す例では、ＤＢ９が、サーバ装置８とは別体の記憶装置等により構成されており、サーバ装置８に接続されている。この構成に限定されず、サーバ装置８の記憶部（図２７参照）によりＤＢ９が構成されてもよい。またネットワーク１０上にＤＢ９が構築され、ネットワーク１０を介しＤＢ９にアクセス可能な構成が採用されてもよい。

【0070】

なお図２では、サーバ装置８が、１つの筐体からなるコンピュータにより模式的に図示されている。もちろんこのような構成に限定されず、様々な機能を有する複数のサーバ装置が協働することで、業務に関する様々な処理が実行されてもよい。

【0071】

従業員端末６は、従業員２が使用する端末である。図２に示すように、従業員端末６は、主に従業員２が自宅等から企業の所定の従業員（例えば管理者１１等）や総務部等に連絡するために用いられる。

【0072】

例えば、スマートフォンやタブレット端末等の携帯端末に、本業務管理サービスを提供するアプリケーションがインストールされる。従業員２は、当該アプリケーションを起動させることで、本業務管理サービスを利用することが可能となる。

【0073】

例えば従業員２は、従業員端末６を使って、本業務管理システム１へログインするためのログイン画面を表示させる。そして、自分の個人ＩＤ及びパスワード等を入力して、ログインを行う。このログイン操作により、サーバ装置８は、ログインを行った従業員２の情報を把握することが可能となる。

【0074】

従業員２は、従業員端末６を操作することで、例えば所定のＵＩ（User Interface）やメール機能等を介して、サーバ装置８や管理端末７等からの通知を受け取ることが可能となる。また所定のＵＩやメール機能等を介して、サーバ装置８や管理端末７等へ、連絡等を行うことが可能となる。また管理者１１や総務部等に電話を行う（架電する）ことも可能である。

【0075】

本開示において、従業員２等に対するＵＩの提供は、ＧＵＩ（Graphical User Interface）の表示や、音声によるＵＩ（音声ＵＩ）の出力等を含む。例えば、サーバ装置８等から従業員２への情報の出力、及び従業員２からサーバ装置８等への情報の入力は、従業員端末６の表示デバイスに表示されたＧＵＩ等を介して行うことが可能である。これに限定されず、従業員端末６のスピーカ等の音声出力装置や、マイク等の音声入力装置等を介して、会話形式で情報の出力及び入力が行われてもよい。もちろん、ＧＵＩの表示及び音声の出入力がともに行われてもよい。

【0076】

管理端末７は、管理者１１が使用する端末である。管理者１１は、従業員２よりも大きな権限を有し従業員２の業務を管理する従業員の一例であり、具体的な役職等はとくに限定されない。例えば、本業務管理サービスを提供するアプリケーションがインストールされた携帯端末に対して、管理者１１によりログイン操作が行われる。これにより、サーバ装置８は、ログインを行った管理者１１の情報を把握することが可能となる。

【0077】

管理者１１は、管理端末７を操作することで、例えば所定のＵＩやメール機能等を介して、サーバ装置８や従業員端末６等からの通知を受け取ることが可能となる。また所定のＵＩやメール機能等を介して、サーバ装置８や従業員端末６等へ、連絡等を行うことが可能となる。また従業員２や総務部等に電話を行う（架電する）ことも可能である。

【0078】

図２では、１人の従業員２と、２人の同居人３ａ及び３ｂと、１人の管理者１１が図示されている。もちろん、本業務管理システム１が適用可能な従業員２（同居人３）の数や、管理者１１の数等は限定されない。より多い人数の従業員２（同居人３）及び管理者１１に対して、本業務管理システム１は適用可能である。

【0079】

［サーバ装置の機能的な構成例］
図３は、サーバ装置８の機能的な構成例を示すブロック図である。図３に示すように本実施形態では、サーバ装置８のプロセッサが所定のプログラムを実行することで、機能ブロックとして、ライフログ情報取得部１３、異常判定部１４、異常通知部１５、回答受付部１６、手続き受付部１７、及び手続き処理部１８が構成される。もちろん機能ブロックを実現するために、ＩＣ（集積回路）等の専用のハードウェアが用いられてもよい。

【0080】

プログラムは、例えば種々の記録媒体を介してサーバ装置８にインストールされる。あるいは、インターネット等を介してプログラムのインストールが実行されてもよい。プログラムが記録される記録媒体の種類等は限定されず、コンピュータが読み取り可能な任意の記録媒体が用いられてよい。例えば、コンピュータが読み取り可能な非一過性の任意の記憶媒体が用いられてよい。

【0081】

ライフログ情報取得部１３は、従業員２及び同居人３から検出されるライフログ情報を取得する。ライフログ情報取得部１３により、センサ装置５から検出されたライフログ情報の受信、センサ装置５により生成されたライフログ情報の受信、センサ装置５により検出された検出結果に基づいたライフログ情報の生成等が実行される。

【0082】

とくに本実施形態では、ライフログ情報取得部１３により、従業員２及び同居人３から検出される生体情報が取得される。すなわち、ライフログ情報取得部１３により、センサ装置５から検出された生体情報の受信、センサ装置５により生成された生体情報の受信、センサ装置５により検出された検出結果に基づいた生体情報の生成等が実行される。

【0083】

ライフログ情報取得部１３により取得されたライフログ情報（生体情報）は、ＤＢ９に記憶される。例えば、従業員２ごとに付与される従業員ＩＤ（「個人ＩＤ」）に基づいて、種別ごとにライフログ情報が記憶される。ライフログ情報の種別は、ライフログ情報の項目ともいえる。

【0084】

異常判定部１４は、ライフログ情報取得部１３により取得されたライフログ情報が異常であるか否かが判定される。とくに本実施形態では、異常判定部１４により、従業員２及び同居人３から検出された生体情報が異常であるか否かが判定される。生体情報が異常であるか否かの判定は、例えば生体情報の種別ごとに設定される判定基準値（閾値）に基づいて実行される（図７参照）。もちろん、そのような判定方法に限定されるわけではない。

【0085】

異常通知部１５は、ライフログ情報取得部１３により取得されたライフログ情報が異常である場合に、その旨を従業員２に通知する。具体的には、ライフログ情報が異常である旨の情報を、従業員端末６を介して通知する。従業員２に対する従業員端末６を介した通知の態様は限定されず、任意の態様で通知が行われてよい。

【0086】

とくに本実施形態では、異常通知部１５により、従業員２及び同居人３から検出された生体情報が異常である場合に、その旨が従業員２に通知される。例えば図１及び図２に示す例では、同居人３ａである妻の生体情報や、同居人３ｂである子供の生体情報について異常であると判定された場合に、その旨が従業員端末６を介して従業員２に通知される。

【0087】

回答受付部１６は、異常通知部１５からの通知に対して入力される従業員２からの回答を受け付ける。具体的には、従業員２により、通知に対する回答が従業員端末６に入力され、入力された回答がサーバ装置８の回答受付部１６に受け付けられる。

【0088】

とくに本実施形態では、回答受付部１６により、異常通知部１５からの同居人３から検出された生体情報が異常である旨の通知に対して入力される、従業員２からの同居人３の体調に関する回答が受け付けられる。

【0089】

手続き受付部１７は、管理者１１により入力される従業員２の業務に関する所定の手続きを受け付ける。具体的には、管理端末７を介して管理者１１が、所望の手続きを行うための指示を入力する。手続き受付部１７は、当該指示に応じて、管理者１１が所望する手続きを受け付ける。

【0090】

また手続き受付部１７は、従業員２により入力される、従業員２の業務に関する所定の手続きを受け付ける。具体的には、従業員端末６を介して従業員２が、所望の手続きを行うための指示を入力する。手続き受付部１７は、当該指示に応じて、従業員２が所望する手続きを受け付ける。

【0091】

手続き処理部１８は、手続き受付部１７により受け付けられた手続きを実行する。もちろん、手続きを行わない旨の処理が実行される場合もあり得る。すなわち、手続き処理部１８により、受け付けられた手続きを実行するか否かが判定されてもよい。

【0092】

手続き受付部１７により、指示された手続きが適正か否か等が判定され、適正ではないと判定された手続きに関しては、受付を拒否するといった設定も可能である。

【0093】

従業員２の業務に関する手続きとしては、例えば、テレワークの申請、有給申請（休暇申請）の申請等、従業員２の業務に関する様々な任意の手続きが含まれる。

【0094】

図４及び図５は、ＤＢ９に記憶される業務情報の一例を示す模式図である。図４に示すように、本実施形態では、ＤＢ９に「従業員データテーブル」が記憶される。

【0095】

図４に示すように、「従業員データテーブル」は、従業員２（管理者１１も含む）に関する以下の情報を含む。
「個人ＩＤ」…従業員２を識別可能なＩＤ。例えば４桁の数字等で構成される。もちろん、他の任意の形態のデータが「個人ＩＤ」として用いられてよい。
「氏名」…従業員２の氏名。
「所属名」…従業員２が所属している部署等の名称。
「性別」…従業員２の性別。
「生年月日」…従業員２の生年月日。
「センサ装置ＩＤ」…従業員２のライフログ情報（生体情報）を検出するセンサ装置５を識別可能なＩＤ。例えば１０桁の数字等で構成される。もちろん、他の任意の形態のデータが「センサ装置ＩＤ」として用いられてよい。
「メールアドレス」…従業員２に対して配布されるメールアドレス。本メールアドレス宛に送信されるメールは、従業員端末６（管理端末７）にて確認可能である。

【0096】

図４に示す例では、「営業一課」に所属する「△△隆之」さんと、「〇〇潤一」さんとのデータが格納されている。「△△隆之」さんは「課長」であり、「主事」である「〇〇潤一」の上司となる。例えば、図１及び図２に示す従業員２を「〇〇潤一」さん、管理者１１を「△△隆之」さんとして、本業務管理システム１に関する説明を当てはめることが可能である。

【0097】

図５に示すように、業務情報として、「同居人データテーブル」も記憶される。「同居人データテーブル」は、以下の情報を含む。
「個人ＩＤ」…従業員２を識別可能なＩＤ。この「個人ＩＤ」を有する従業員２の同居人３の情報が格納されることになる。
「同居人氏名」…同居人３の氏名。
「続柄」…従業員２に対する同居人３の続柄（従業員から見た同居人３の続柄）。
「性別」…同居人３の性別。
「生年月日」…同居人３の生年月日。
「センサ装置ＩＤ」…同居人３のライフログ情報（生体情報）を検出するセンサ装置５を識別可能なＩＤ。

【0098】

図５に示す例では、「個人ＩＤ」が「3333」である「営業一課」の「〇〇潤一」さんの同居人３のデータが格納されている。具体的には、「〇〇潤一」さんの「父」の「〇〇浩司」さん、「〇〇潤一」さんの「母」の「〇〇奈津子」さん、「〇〇潤一」さんの「妻」の「〇〇亜由美」さん、「〇〇潤一」さんの「子」の「〇〇健」さん、これら４人のデータが、同居人３のデータとして格納されている。

【0099】

図４及び図５に示す「従業員データテーブル」及び「同居人データテーブル」は、本技術を実施する上での基本データともいえる。また、従業員２の業務に関する業務情報として、他の任意の情報が記憶されてよい。

【0100】

図６は、ライフログ情報取得部１３により取得されるライフログ情報の一例を示す模式図である。ＤＢ９には、ライフログ情報のデータである「ログデータテーブル」が記憶される。

【0101】

「ログデータテーブル」は、以下の情報を含む。
「センサ装置ＩＤ」…ライフログ情報（生体情報）を検出したセンサ装置５を識別可能なＩＤ。図４に示す「従業員データテーブル」及び図５に示す「同居人データテーブル」にて格納される「センサ装置ＩＤ」と同じ情報が用いられる。
「日付」…ライフログ情報が検出された日付。
「時刻」…ライフログ情報が検出された時刻。
「種別」…ライフログ情報の種別。
「値」…ライフログ情報の内容を表すデータ。センサ装置５により検出される検出結果が格納される場合もあるし、センサ装置５の検出結果に基づいて生成されるデータが格納される場合もある。

【0102】

図６に示す例では、「〇〇潤一」さんの「子」の「〇〇健」さんのライフログ情報（生体情報）を検出するセンサ装置５（「センサ装置ＩＤ」＝「EEEEEEEEEE」）により検出されたライフログ情報が格納される。すなわち、「〇〇健」さんから検出されたライフログ情報が格納される。

【0103】

具体的には、「2023/4/3」の「6:00」に「起床（覚醒）」した「〇〇健」さんの「体温」(＝「38.5」℃)、「心拍数」（＝「100」）、及び「ＧＰＳ」（＝「35.681111,139,766667」）が格納されている。

【0104】

なお、「睡眠」は、睡眠センサにより検出可能である。「ＧＰＳ」は、ＧＰＳにより検出可能である。「心拍数」は、心拍センサにより検出可能である。もちろん、図６に図示された種別以外の、様々なライフログ情報を取得することが可能である。

【0105】

図７は、生体情報の異常判定に用いられる判定基準値の一例を示す模式図である。ＤＢ９には、判定基準値のデータである「判定基準値データテーブル」が記憶される。

【0106】

「判定基準値データテーブル」は、以下の情報を含む。
「種別」…生体情報の種別。
「基準値（正常範囲）」…生体情報が異常であるか否かを判定するための閾値。図７に示す例では、生体情報の種別ごとに正常範囲のデータが格納される。取得される生体情報が、「基準値（正常範囲）」から外れる場合には、当該生体情報は異常であると判定される。もちろん、異常と判断される異常範囲が「基準値」として格納されてもよい。また、ある生体情報には正常範囲が「基準値」として格納され、別の生体情報には異常範囲が「基準値」として格納される。このような設定も可能である。

【0107】

図７に示す例では、「体温」に対して「基準値（正常範囲）」が「35～37」(℃)に設定される。従って、３５度よりも低い体温、及び３７度よりも高い体温は、異常状態として判定される。また「心拍数」に対して「基準値（正常範囲）」が「60～90」(bpm)に設定される。従って、６０ｂｍｐよりも遅い心拍数、及び９０ｂｐｍよりも速い心拍数は、異常状態として判定される。

【0108】

また、「血圧」に対して「基準値（正常範囲）」が「115/75以下」(mmHg)に設定される。従って、収縮期血圧（最大血圧）が１１５ｍｍＨｇよりも大きい値となる状態、及び拡張期血圧（最小血圧）が７５ｍｍＨｇよりも大きい値となる状態のいずれか一方でも該当する場合には、異常状態として判定される。

【0109】

また、「酸素飽和度」に対して「基準値（正常範囲）」が「96～99」(％)に設定される。従って、９６％よりも低い酸素飽和度、及び９９％よりも高い酸素飽和度は、異常状態として判定される。

【0110】

生体情報の種別ごとの「基準値」は限定されず、任意に設定することが可能である。もちろん、図７に例示した「体温」「心拍数」「血圧」「酸素飽和度」以外の、様々な種別の生体情報に対して、異常判定の基準となる基準値を任意に設定することが可能である。

【0111】

図８は、ＤＢ９に業務情報として記憶される休暇申請情報の一例を示す模式図である。ＤＢ９には、休暇申請情報のデータとして「休暇申請データ」が記憶される。

【0112】

「休暇申請データ」は、以下の情報を含む。
「個人ＩＤ」
「休暇年月日」…休暇申請の対象となる年月日。
「ステータス」…休暇申請に対する処理状況のステータス。例えば、「受付中」「承認中」「承認済」「却下」等の情報が格納される。
「休暇種別」…休暇の種別。例えば、「有給休暇」「夏期休暇」「忌引休暇」「育児休暇」等の情報が格納される。
「事由」…休暇を申請する理由。

【0113】

図８に示す例では、「個人ＩＤ」が「3333」である「〇〇潤一」さんに関する「家族の体調不良」を理由とする「有給休暇」の申請が、「承認中」である旨の情報が格納されている。

【0114】

なお、従業員２の休暇申請等は、従業員２自身で、従業員端末６を介して入力することが可能である。また従業員２の業務を管理する管理者１１により、管理端末７を介して入力することも可能である。

【0115】

［サーバ装置の基本動作］
図９は、サーバ装置８の基本的な動作例を示すフローチャートである。ライフログ情報取得部１３により、従業員２及び同居人３から検出された生体情報が取得される（ステップ１０１）。例えば、センサ装置５により、所定のフレームレートで定期的に従業員２及び同居人３に対して生体情報の検出が実行される。そして、検出された生体情報が、ネットワーク１０を介して、サーバ装置８に送信される。ライフログ情報取得部１３は、センサ装置５から送信された生体情報を受信する。

【0116】

または、センサ装置５が生体情報を送信するためのトリガが適宜設定されてもよい。例えば、所定の時刻になると、センサ装置５により、その時刻までに検出された未送信の生体情報が送信される。あるいは、サーバ装置８からの要求等があった場合に、センサ装置５により、それまでに検出された生体情報が送信される。その他、任意の設定が採用されてよい。

【0117】

異常判定部１４により、取得された生体情報が異常であるか否かが判定される（ステップ１０２）。当該判定は、例えば図７に例示する判定基準値データテーブルを参照して実行される。生体情報が異常ではない場合（ステップ１０２のＮｏ）、処理は終了する。

【0118】

生体情報が異常である場合（ステップ１０２のＹｅｓ）、異常通知部１５により、取得された生体情報が異常である旨が従業員２に通知される（ステップ１０３）。

【0119】

回答受付部１６により、従業員２から入力される、異常と判定された生体情報が検出された人物の体調に関する回答が受け付けられる。例えば、ステップ１０２にて、従業員２から検出された生体情報が異常であると判定された場合は、ステップ１０３にて、その旨が従業員２に通知される。そして、ステップ１０４にて、従業員２の体調に関する回答が受け付けられる。

【0120】

またステップ１０２にて、同居人３から検出された生体情報が異常であると判定された場合は、ステップ１０３にて、その旨が従業員２に通知される。そして、ステップ１０４にて、同居人３の体調に関する回答が受け付けられる。

【0121】

図１０は、とくに同居人３の生体情報に対して動作する処理例を示すフローチャートである。すなわち、図９に示すフローにおいて、従業員２の生体情報に対しては動作せず、同居人３の生体情報に対して動作するフローとなる。

【0122】

ライフログ情報取得部１３により、同居人３から検出された生体情報が取得される（ステップ２０１）。異常判定部１４により、取得された生体情報が異常であるか否かが判定される（ステップ２０２）。生体情報が異常ではない場合（ステップ２０２のＮｏ）、処理は終了する。

【0123】

生体情報が異常である場合（ステップ２０２のＹｅｓ）、異常通知部１５により、取得された生体情報が異常である旨が従業員２に通知される（ステップ２０３）。回答受付部１６により、従業員２から入力される、異常と判定された生体情報が検出された同居人３の体調に関する回答が受け付けられる。

【0124】

このように、同居人３の生体情報に着目して、本業務管理システム１を動作させることも可能である。

【0125】

図１１は、業務管理システム１における処理例を示すフローチャートである。図１１には、同居人３の生体情報に対して動作する、センサ装置５ｂ及び５ｃ、従業員端末６、及びサーバ装置８の処理例が図示されている。

【0126】

同居人３の生体情報を検出するセンサ装置５（５ｂ及び５ｃ）により、同居人３の生体情報が検出され、サーバ装置８に送信される（ステップ３０１）。サーバ装置８のライフログ情報取得部１３により、センサ装置５から送信される同居人３の生体情報が取得される。図６に例示するように、取得された同居人３の生体情報は、ＤＢ９に記憶される（ステップ３０２）。

【0127】

異常判定部１４により、同居人３の生体情報が、図７に例示する判定基準値と比較され、生体情報が異常であるか否かが判定される（ステップ３０３及び３０４）。同居人３の生体情報が異常でない場合は（ステップ３０４のＮｏ）、処理は終了する。

【0128】

同居人３の生体情報が異常である場合（ステップ３０４のＹｅｓ）、異常通知部１５により、その旨が従業員２に通知される（ステップ３０５）。具体的には、同居人３の生体情報が異常である旨の情報が、従業員端末６に送信される。そして、従業員端末６の表示デバイスに、同居人３の生体情報が異常である旨が表示される（ステップ３０６）。

【0129】

図１２は、従業員端末６に表示される異常通知画面の一例を示す模式図である。図１２に示す異常通知画面２０は、同居人３の生体情報が異常である旨を表示して従業員２に通知するための画面である。

【0130】

図１２に示す異常通知画面 は、以下の項目の情報を含む。
「送信日時」…本例では、「2023/4/3 6:05AM」。
「送信元」…本例では、「健康管理システム」。
「送信先」…本例では、「営業一課 〇〇潤一」。
「件名」…本例では、「ヘルスデータ異常のご連絡」
「本文」…本例では、従業員２の情報、異常と判定された生体情報が検出された同居人３の情報、異常と判定された生体情報の値、同居人３の体調の確認をお願いする旨の内容等が、本文に表示される。

【0131】

具体的には、営業一課の〇〇潤一さんの家族である〇〇健さんの生体情報（ヘルスデータ）が、異常値である旨が本文に表示される。また「ご確認をお願いします」といった文章と、異常値となった体温（38.1度）及び心拍数（100）が、本文に表示される。

【0132】

さらに、図１２に示す異常通知画面２０では、この異常通知に対する回答を入力するか否かを従業員２に尋ねる旨の文章と、ＯＫボタンが表示される。従業員２は、異常通知に対する回答を入力する場合には、ＯＫボタンを選択する。そうすると、異常通知に対する回答を入力するための入力画面に移動する（図示は省略）。

【0133】

異常通知に対する回答は、典型的には、同居人３の体調に関する回答である。例えば、生体情報が異常であると判定された同居人３が実際に体調不良であるか否かの情報を、同居人３の体調に関する回答として入力することが可能である。すなわち、同居人３の体調が不良の旨の回答や、同居人３の体調は不良ではなく正常である旨の回答等を入力することが可能である。

【0134】

例えば、〇〇健は実際に体温が高く心拍数も速い状態であり、体調が不良であるといった情報を、同居人３の体調に関する回答として入力することが可能である。また、〇〇健は実際には平熱で心拍数も正常であり、いたって元気であるといった情報を、同居人３の体調に関する回答として入力することが可能である。

【0135】

図１１に示す例では、ステップ３０７にて、従業員２からの異常通知に対する回答の入力の有無が判定される。異常通知に対する回答の入力がない場合は（ステップ３０７のＮｏ）、処理は終了する。例えば、所定の時間が経過するまでに回答の入力がない場合に、ステップ３０７にてＮｏと判定されてもよい。あるいは、異常通知画面２０内に、回答しない旨のボタンが準備されており、当該ボタンが選択された場合にステップ３０７にてＮｏと判定されてもよい。

【0136】

異常通知に対する回答の入力がある場合は（ステップ３０７のＹｅｓ）、同居人３の体調に関する回答が、サーバ装置８に送信される（ステップ３０８）。サーバ装置８の回答受付部１６により、従業員端末６から送信された回答が受け付けられる（ステップ３０９）。

【0137】

ステップ３０５にて、同居人３の生体情報が異常である旨の情報を従業員端末６に送信するための形態は限定されない。例えば、メール機能、ＳＮＳ機能、ショートメッセージ機能等、任意の形態で、生体情報が異常である旨の情報が送信されてよい。

【0138】

また、従業員端末６に表示される異常通知画面２０の構成（例えば文章構成や文章内容等）も限定されず、任意の構成が採用されてよい。異常通知画面２０の表示に代えて、もしくは異常通知画面２０の表示に加えて、音声により、同居人３の生体情報が異常である旨が通知されてもよい。

【0139】

また、従業員２が異常通知に対する回答、すなわち同居人３の体調に関する回答を入力するためのＵＩも限定されず、任意のＧＵＩや音声ＵＩが採用されてよい。例えば、従業員２によるテキスト入力、音声入力、プルダウンの選択等、同居人３の体調に関する回答を入力することが可能な任意の形態を採用することが可能である。

【0140】

同居人３の生体情報が異常である旨の情報、及び異常通知に対する従業員２からの同居人３の体調に関する回答は、業務管理に有効に利用することが可能である。

【0141】

図１３は、サーバ装置８から管理端末７への通知例を示すフローチャートである。まず、サーバ装置８の異常通知部１５により、同居人３の生体情報が異常となった従業員２が特定される（ステップ４０１）。本ステップは、例えは、図６に示す「ログデータテーブル」、図５に示す「同居人データテーブル」を参照することで実行可能である。

【0142】

また、異常通知部１５により、ステップ４０１にて特定された従業員２の業務を管理する管理者１１が特定される（ステップ４０２）。本ステップは、例えば、図４に示す「従業員データテーブル」を参照することで実行可能である。

【0143】

異常通知部１５により、従業員２から同居人３の体調に関する回答の有無が判定される（ステップ４０３）。同居人３の体調に関する回答がない場合は（ステップ４０３のＮｏ）、異常通知部１５により、同居人３の生体情報が異常である旨が、管理者１１に通知される（ステップ４０４）。具体的には、同居人３の生体情報が異常である旨の情報が、管理端末７に送信される。そして、管理端末７の表示デバイスに、同居人３の生体情報が異常である旨が表示される（ステップ４０５）。

【0144】

図１４は、管理端末７に表示される異常通知画面の一例を示す模式図である。図１４に示す異常通知画面２２は、同居人３の生体情報が異常である旨を表示して管理者１１に通知するための画面である。

【0145】

図１４に示す異常通知画面２２は、以下の項目の情報を含む。
「送信日時」…本例では、「2023/4/3 6:15AM」。
「送信元」…本例では、「健康管理システム」。
「送信先」…本例では、「営業一課 △△隆之」。
「件名」…本例では、「ヘルスデータ異常のご連絡（〇〇潤一の同居人）」。
「本文」…本例では、同居人３の生体情報が異常となった従業員２の情報、異常と判定された生体情報が検出された同居人３の情報、異常と判定された生体情報の値が、本文に表示される。

【0146】

具体的には、営業一課の〇〇潤一さんの家族である〇〇健さんの生体情報（ヘルスデータ）が、異常値である旨が本文に表示される。また異常値となった体温（38.1度）及び心拍数（100）が本文に表示される。

【0147】

さらに、図１４に示す異常通知画面２２では、行いたい関連手続きを選択可能なチェックボックスと、ＯＫボタンとが表示される。関連手続きは、同居人３の生体情報が異常である状況に関連する任意の手続きを含む。

【0148】

図１４に示す例では、同居人３の生体情報が異常となった従業員２である「〇〇潤一」さんの休暇申請手続き、同居人３の生体情報が異常となった従業員２である「〇〇潤一」さんのテレワーク申請手続き、及び総務部への連絡が、関連手続きとして表示される。

【0149】

管理者１１は、行いたい関連手続きのチェックボックスを選択し、ＯＫボタンを押す。そうすると、選択した関連手続きを実行するための画面に移動する（図示は省略）。

【0150】

図１３に示す例では、ステップ４０６にて、関連手続きを行う旨の入力の有無が判定される。関連手続きを行う旨の入力がない場合は（ステップ４０６のＮｏ）、処理は終了する。例えば、所定の時間が経過するまでに、図１４に示すいずれかの関連手続きの選択がない場合に、ステップ４０６にてＮｏと判定されてもよい。あるいは、異常通知画面２２内に、関連手続きを行わない旨のボタンが準備されており、当該ボタンが選択された場合にステップ４０６にてＮｏと判定されてもよい。

【0151】

関連手続きを行う旨の入力がある場合（ステップ４０６のＹｅｓ）、当該関連手続きの指示が、サーバ装置８に送信される（ステップ４０７）。例えば、図１４に示す異常通知画面２２に表示されたいずれかの関連手続きのチェックボックスが選択され、ＯＫボタンが選択される。そうすると、ステップ４０６にてＹｅｓと判定される。そして、ステップ４０７にて、選択された関連手続きの指示が、サーバ装置８に送信される。

【0152】

サーバ装置８の手続き受付部１７により、管理者１１により選択された関連手続きの指示が受け付けられる。当該関連手続きの指示の受け付けは、管理者１１により入力される従業員２の業務に関する所定の手続きの受け付けの一実施形態に相当する。

【0153】

そして、サーバ装置８の手続き処理部１８により、手続き受付部１７による受け付けられた関連手続きが実行される（ステップ４０８）。例えば、休暇申請の手続きが受け付けられて処理される場合には、図８に示す「休暇申請データ」が作成されて記憶される。

【0154】

ステップ４０３にて、同居人３の体調に関する回答があった場合は（Ｙｅｓ）、受け付けられた回答が、同居人３が実際に体調不良である旨の回答であるか否かが判定される。すなわち、回答受付部１６により、従業員２から同居人３の体調が不良の旨の回答が受け付けられたか、それとも従業員２から同居人３の体調が不良でない旨の回答が受け付けられたかが判定される（ステップ４０９）。なお、本ステップは、回答受付部１６により実行されてもよいし、異常通知部１５により実行されてもよい。

【0155】

従業員２から同居人３の体調が不良の旨の回答が受け付けられない場合（ステップ４０９のＮｏ）、処理は終了する。

【0156】

従業員２から同居人３の体調が不良の旨の回答が受け付けられた場合（ステップ４０９のＹｅｓ）、異常通知部１５により、その旨が管理者１１に通知される（ステップ４１０）。具体的には、同居人３の体調が不良である旨の情報が、管理端末７に送信される。そして、管理端末７の表示デバイスに、同居人３の体調が不良である旨が表示される（ステップ４１１）。

【0157】

図１５は、管理端末７に表示される異常通知画面の一例を示す模式図である。図１５に示す異常通知画面２４は、同居人３の体調が不良である旨を表示して管理者１１に通知するための画面である。

【0158】

図１５に示す異常通知画面２４は、以下の項目の情報を含む。
「送信日時」…本例では、「2023/4/3 6:15AM」。
「送信元」…本例では、「健康管理システム」。
「送信先」…本例では、「営業一課 △△隆之」。
「件名」…本例では、「体調不良のご連絡（〇〇潤一の同居人）」。
「本文」…本例では、同居人３の体調が不良となった従業員２の情報、体調が不良となった同居人３の情報、異常と判定された生体情報の値が、本文に表示される。

【0159】

具体的には、営業一課の〇〇潤一さんの家族である〇〇健さんの体調が不良である旨が本文に表示される。また異常値となった体温（38.1度）及び心拍数（100）が本文に表示される。

【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】

あるいは、「あなた、健がぐったりしてて熱があるみたいなの」という妻（同居人３ａ）の発話や、「お母さん、体が熱くて辛いよ」という子供（同居人３ｂ）の発話等を解析することで、従業員２及び同居人３のうち、どの人物が体調不良の可能性があるのかを解析して特定することも可能である。

【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】

また例えば、流行している感染症の対策を重視したい場合には、当該感染症に関する情報に関する項目や政府から発せられる注意喚起の情報に関する項目重み付け（優先度）を高く設定する。その他、任意の設定が可能である。

【0237】

業務情報や社会情勢・環境情報に基づいて、どのような提案を行うことに関する重み付けを行うことも可能である。例えば、直近で締め切り予定がないデスクワークのみの勤務スケジュールである場合には、一日休暇の提案の重み付けを高くする。役員との打合せやクライアントとの会合が勤務スケジュールに入っている場合は、休暇申請の提案の重み付けを低くする。当月の売上達成度が低い場合は、休暇申請の提案の重み付けを低くする。かかりつけの病院が休診日の場合は、休暇申請の提案の重み付けを高くする。体温が３７度以上でもその人の平熱との乖離が一定以下の場合は、通常出勤の重み付けを高くする。このような、業務情報に応じた適切な応答が実現可能となる。

【0238】

業務情報や社会情勢・環境情報を反映した応答動作、応答処理に反映させる項目に関する重み付け情報に基づいた応答動作、従業員２に対する提案の種類に対する重み付けを実現するための具体的なアルゴリズムは限定されない。例えば、機械学習アルゴリズムにより学習された学習モデルが用いられて、これらの応答処理が実行されてもよい。

【0239】

本実施形態において、業務管理システム２６は、本発明に係る情報処理システムの一実施形態に相当する。
スマートスピーカ２７は、本発明に係る音声入出力装置の一実施形態として機能する。
発話解析部２８は、本発明に係る発話解析部の一実施形態として機能する。
応答処理部２９は、本発明に係る応答処理部の一実施形態として機能する。

【0240】

＜その他の実施形態＞
本発明は、以上説明した実施形態に限定されず、他の種々の実施形態を実現することができる。

【0241】

図２に示す例では、各センサ装置５が、ネットワーク１０に接続されている。これに限定されず、従業員端末６のみがネットワーク１０に接続されており、センサ装置５は、従業員端末６を介してライフログ情報をサーバ装置８に送信する。このような構成が採用されてもよい。

【0242】

第１の実施形態で説明した従業員端末６と、第２の実施形態で説明したスマートスピーカ２７とが併用されてもよい。また、第１の実施形態で説明した従業員端末６に、第２の実施形態で説明したスマートスピーカ２７の機能を搭載することも可能である。また、第２の実施形態で説明したスマートスピーカ２７により、第１の実施形態で説明した従業員端末６と同等の機能を発揮させることも可能である。この場合、スマートスピーカ２７を従業員端末６として用いる形態ともいえる。

【0243】

第１の実施形態において、サーバ装置８に従業員２からの同居人３の体調が不良の旨の回答が受け付けられた場合に、従業員２に対して、従業員２の業務及び同居人３の体調の不良の少なくとも一方に関する提案を行う提案部が構築されてもよい。そして、サーバ装置８の提案部が動作することにより、第２の実施形態で説明したような従業員２に対する様々な提案が実現されてもよい。当該提案は、例えば、従業員端末６を介して実行される。

【0244】

図６に示す「ログデータテーブル」では、同居人３の位置情報（ＧＰＳ座標）も取得されている。例えば、同居人３の生体情報が異常である場合に、当該同居人３の位置情報が参照されてもよい。すなわち、生体情報が異常となる同居人３がどこにいるかが参照されてもよい。

【0245】

例えば、同居人３が従業員２から離れた位置や、隔離された位置にいる場合には、従業員２の体調への影響はほとんどないだろうといった推定を行うことも可能である。また、従業員２との距離に応じて、従業員２の体調への影響度が算出されてもよい。このように、ライフログ情報のうちの生体情報以外の情報が適宜利用されてもよい。

【0246】

上記の各実施形態では、ライフログ情報のうち生体情報に着目して、生体情報の異常判定や異常通知、従業員２からの同居人３の体調に関する回答の受け付け、従業員２や管理者１１からの関連手続きの受付及び関連手続きの実行、従業員２に対する様々な提案について説明した。これに限定されず、ライフログ情報のうちの生体情報以外の情報に対しても、同様の処理を実行することが可能である。

【0247】

例えば、位置情報に対して、異常判定や異常通知が実行される。例えば、同居人３である子供が、家等の所定の位置（所定の地域）から外れた場合に、位置情報が異常であると判定され、従業員２に異常通知が実行される。そして、従業員２から入力される同居人３の位置に関する回答が受け付けられる。また従業員２や管理者１１からの同居人３の位置が異常状態であることに関連する任意の関連手続きの受け付け、及び関連手続きの処理が実行される。また従業員２に対して、同居人３の位置に関する様々な提案が実行される。このようなシステムを構築することも可能である。

【0248】

もちろん、ライフログ情報のうち、生体情報及び位置情報以外の情報に対して、同様のシステムを構築することも可能である。

【0249】

図２１は、センサ装置５、管理端末７、サーバ装置８、及びスマートスピーカ２７として用いることが可能なコンピュータ６０のハードウェア構成例を示すブロック図である。なお、センサ装置５には、さらにセンサが備えられる。

【0250】

コンピュータ６０は、ＣＰＵ６１、ＲＯＭ６２、ＲＡＭ６３、入出力インタフェース６５、及びこれらを互いに接続するバス６４を備える。入出力インタフェース６５には、表示部６６、入力部６７、記憶部６８、通信部６９、及びドライブ部７０等が接続される。
表示部６６は、例えば液晶、ＥＬ等を用いた表示デバイスである。入力部６７は、例えばキーボード、ポインティングデバイス、タッチパネル、その他の操作装置である。入力部６７がタッチパネルを含む場合、そのタッチパネルは表示部６６と一体となり得る。
記憶部６８は、不揮発性の記憶デバイスであり、例えばＨＤＤ、フラッシュメモリ、その他の固体メモリである。ドライブ部７０は、例えば光学記録媒体、磁気記録テープ等、リムーバブルの記録媒体７１を駆動することが可能なデバイスである。
通信部６９は、ＬＡＮ、ＷＡＮ等に接続可能な、他のデバイスと通信するためのモデム、ルータ、その他の通信機器である。通信部６９は、有線及び無線のどちらを利用して通信するものであってもよい。通信部６９は、コンピュータ６０とは別体で使用される場合が多い。
上記のようなハードウェア構成を有するコンピュータ６０による情報処理は、記憶部６８またはＲＯＭ６２等に記憶されたソフトウェアと、コンピュータ６０のハードウェア資源との協働により実現される。具体的には、ＲＯＭ６２等に記憶された、ソフトウェアを構成するプログラムをＲＡＭ６３にロードして実行することにより、本発明に係る情報処理方法が実現される。
プログラムは、例えば記録媒体７１を介してコンピュータ６０にインストールされる。あるいは、グローバルネットワーク等を介してプログラムがコンピュータ６０にインストールされてもよい。その他、コンピュータ読み取り可能な非一過性の任意の記憶媒体が用いられてよい。

【0251】

ネットワーク等を介して通信可能に接続された複数のコンピュータが協働することで、本発明に係る情報処理方法（健康管理方法）及びプログラムが実行され、本発明に係る情報処理システムや情報処理装置が構築されてもよい。
すなわち本発明に係る情報処理方法、及びプログラムは、単体のコンピュータにより構成されたコンピュータシステムのみならず、複数のコンピュータが連動して動作するコンピュータシステムにおいても実行可能である。
なお本開示において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれもシステムである。

【0252】

コンピュータシステムによる本発明に係る情報処理方法、及びプログラムの実行は、例えばライフログ情報（生体情報）の取得、ライフログ情報（生体情報）が異常である旨の通知、従業員からの通知に対する回答の受け付け、関連手続きの受け付け、関連手続きの処理、発話内容の解析、応答処理の実行、従業員に対する提案等が、単体のコンピュータにより実行される場合、及び各処理が異なるコンピュータにより実行される場合の両方を含む。また所定のコンピュータによる各処理の実行は、当該処理の一部または全部を他のコンピュータに実行させその結果を取得することを含む。
すなわち本発明に係る情報処理方法及びプログラムは、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成にも適用することが可能である。

【0253】

各図面を参照して説明した業務管理システム、センサ装置、サーバ装置、管理端末、ＤＢ、スマートスピーカ、各種異常通知画面の各構成、ライフログ情報（生体情報）の検出、ライフログ情報（生体情報）の異常判定、異常通知、回答受付等の各処理フロー等はあくまで一実施形態であり、本発明の趣旨を逸脱しない範囲で、任意に変形可能である。すなわち本発明を実施するための他の任意の構成やアルゴリズム等が採用されてよい。

【0254】

本開示において、説明の理解を容易とするために、「略」「ほぼ」「おおよそ」等の文言が適宜使用される場合がある。一方で、これら「略」「ほぼ」「おおよそ」等の文言を使用する場合と使用しない場合とで、明確な差異が規定されるわけではない。
すなわち、本開示において、「中心」「中央」「均一」「等しい」「同じ」「直交」「平行」「対称」「延在」「軸方向」「円柱形状」「円筒形状」「リング形状」「円環形状」等の、形状、サイズ、位置関係、状態等を規定する概念は、「実質的に中心」「実質的に中央」「実質的に均一」「実質的に等しい」「実質的に同じ」「実質的に直交」「実質的に平行」「実質的に対称」「実質的に延在」「実質的に軸方向」「実質的に円柱形状」「実質的に円筒形状」「実質的にリング形状」「実質的に円環形状」等を含む概念とする。
例えば「完全に中心」「完全に中央」「完全に均一」「完全に等しい」「完全に同じ」「完全に直交」「完全に平行」「完全に対称」「完全に延在」「完全に軸方向」「完全に円柱形状」「完全に円筒形状」「完全にリング形状」「完全に円環形状」等を基準とした所定の範囲（例えば±１０％の範囲）に含まれる状態も含まれる。
従って、「略」「ほぼ」「おおよそ」等の文言が付加されていない場合でも、いわゆる「略」「ほぼ」「おおよそ」等を付加して表現される概念が含まれ得る。反対に、「略」「ほぼ」「おおよそ」等を付加して表現された状態について、完全な状態が必ず排除されるというわけではない。

【0255】

本開示において、「Ａより大きい」「Ａより小さい」といった「より」を使った表現は、Ａと同等である場合を含む概念と、Ａと同等である場合を含まない概念の両方を包括的に含む表現である。例えば「Ａより大きい」は、Ａと同等は含まない場合に限定されず、「Ａ以上」も含む。また「Ａより小さい」は、「Ａ未満」に限定されず、「Ａ以下」も含む。
本技術を実施する際には、上記で説明した効果が発揮されるように、「Ａより大きい」及び「Ａより小さい」に含まれる概念から、具体的な設定等を適宜採用すればよい。

【0256】

以上説明した本発明に係る特徴部分のうち、少なくとも２つの特徴部分を組み合わせることも可能である。すなわち各実施形態で説明した種々の特徴部分は、各実施形態の区別なく、任意に組み合わされてもよい。また上記で記載した種々の効果は、あくまで例示であって限定されるものではなく、また他の効果が発揮されてもよい。

【産業上の利用可能性】

【0257】

本発明は、従業員の健康管理を行う業務管理システムにおいて、好適に利用することができる。

【符号の説明】

【0258】

Ｓ…居住空間
１、２６…業務管理システム
２…従業員
３……同居人
５…センサ装置
６…従業員端末
７…管理端末
８…サーバ装置
９…データベース（ＤＢ）
１１…管理者
２０、２２、２４…異常通知画面
２７…スマートスピーカ
６０…コンピュータ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】