(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-04-11
(45)【発行日】2024-04-19
(54)【発明の名称】共用車両管理システムおよび共用車両管理方法
(51)【国際特許分類】
G06Q 50/40 20240101AFI20240412BHJP
G06Q 30/0645 20230101ALI20240412BHJP
G16H 50/80 20180101ALI20240412BHJP
【ＦＩ】
G06Q50/40
G06Q30/0645
G16H50/80
【請求項の数】
26
(21)【出願番号】P 2022576347
(86)(22)【出願日】2021-07-02
(65)【公表番号】
(43)【公表日】2023-07-14
(86)【国際出願番号】 JP2021025202
(87)【国際公開番号】W WO2022004887
(87)【国際公開日】2022-01-06
【審査請求日】2023-02-09
(31)【優先権主張番号】16/920,330
(32)【優先日】2020-07-02
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】000000033
【氏名又は名称】旭化成株式会社
(74)【代理人】
【識別番号】100147485
【弁理士】
【氏名又は名称】杉村 憲司
(74)【代理人】
【識別番号】230118913
【弁護士】
【氏名又は名称】杉村 光嗣
(74)【代理人】
【識別番号】100165951
【弁理士】
【氏名又は名称】吉田 憲悟
(74)【代理人】
【識別番号】100213333
【弁理士】
【氏名又は名称】鹿山 昌代
(72)【発明者】
【氏名】森住 昌弘
(72)【発明者】
【氏名】本庄 崇文
(72)【発明者】
【氏名】矢吹 勇人
(72)【発明者】
【氏名】平川 博之
【審査官】星野 昌幸
(56)【参考文献】
【文献】国際公開第２０１３／００６６１８（ＷＯ，Ａ２）
【文献】特開２０２０－００８９６９（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ ～ ９９／００
Ｇ１６Ｈ ５０／８０
(57)【特許請求の範囲】
【請求項1】
車両の車室内の音響事象を検出するための音響センサを含む音響事象検出部と、前記音響事象検出部に電気的に接続された車両端末と、
前記車両端末とネットワークを介して通信する外部サーバと、を備え、
前記車両端末および前記外部サーバの少なくとも一方はプロセッサを備え、
該プロセッサは、
前記検出した音響事象から、前記車両内の搭乗者の呼吸器疾患症状を抽出するステップと、
前記搭乗者の前記呼吸器疾患症状を評価して、前記車両に搭乗する予定の次の搭乗者の感染リスクに関連する感染リスク情報を生成するステップと、
前記感染リスク情報を、外部利用者端末、前記外部サーバまたは第三者に前記ネットワークを介して送信するステップと、を実行するように構成されている、共用車両管理システム。
【請求項2】
前記車両の現在位置を検出するための位置検出部をさらに備え、前記プロセッサは、
前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方を、前記ネットワークを介して取得するステップを実行するように構成されており、
前記搭乗者の前記呼吸器疾患を評価するステップは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方に基づいても実行される、請求項１に記載のシステム。
【請求項3】
前記プロセッサは、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップを実行するようにさらに構成されている、請求項１に記載のシステム。
【請求項4】
前記車両内に空気清浄機をさらに備え、前記プロセッサは、
前記呼吸器疾患症状の発生頻度に基づいて前記空気清浄機を制御するステップを実行するようにさらに構成されている、請求項１に記載のシステム。
【請求項5】
前記搭乗者の生体情報を取得する生体情報取得部をさらに備え、前記プロセッサは、
前記呼吸器疾患症状の発生頻度に基づいて前記生体情報取得部を制御するステップを実行するようにさらに構成されている、請求項１に記載のシステム。
【請求項6】
前記プロセッサは、前記感染リスク情報に基づいて、前記車両の次の利用前の消毒手順の必要性を示す車両車室汚染情報を生成するステップと、
前記車両車室汚染情報を前記外部利用者端末に前記ネットワークを介して送信するステップと、を実行するようにさらに構成されている、請求項１に記載のシステム。
【請求項7】
前記外部サーバは、前記共用車両の予約情報および状態情報を記憶するデータベースを備え、前記車両の前記状態情報を変更して前記車両車室汚染情報に反映させる、請求項６に記載のシステム。
【請求項8】
前記消毒手順が必要であることを前記車両車室汚染情報が示し、前記車両が予約されていることを前記予約情報が示す場合、前記外部サーバは、利用可能な他の車両を探し、前記利用可能な車両を前記予約に割り当てる、請求項７に記載のシステム。
【請求項9】
前記車両車室汚染情報は、前記消毒手順の完了後に、前記車両がクリーンであることを示すように更新される、請求項７に記載のシステム。
【請求項10】
前記外部サーバは、感染リスクが高いと判定された前記車両と類似の利用履歴を有する汚染の可能性のある車両を探し、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更する、請求項１に記載のシステム。
【請求項11】
前記音響センサは音響データを取得し、前記プロセッサは、
前記音響データを、前記外部利用者端末、前記外部サーバまたは前記第三者に前記ネットワークを介して送信するステップを実行するように構成されている、請求項１に記載のシステム。
【請求項12】
前記プロセッサは、前記感染リスク情報に基づいて、前記外部サーバ、前記車両端末、前記外部利用者端末または前記第三者に前記ネットワークを介して広告を配信するステップを実行するようにさらに構成されている、請求項１に記載のシステム。
【請求項13】
前記プロセッサは、体調に関する前記搭乗者の報告と前記搭乗者の前記感染リスク情報とに基づいて、前記搭乗者を評価するステップを実行するようにさらに構成されている、請求項１に記載のシステム。
【請求項14】
車両の車室内の音響事象を検出するステップと、前記検出した音響事象から、前記車両内の搭乗者の呼吸器疾患症状を抽出するステップと、
前記搭乗者の前記呼吸器疾患症状を評価して、前記車両に搭乗する予定の次の搭乗者の感染リスクに関連する感染リスク情報を生成するステップと、
前記感染リスク情報を、外部利用者端末、外部サーバまたは第三者にネットワークを介して送信するステップと、を含む共用車両の管理方法。
【請求項15】
前記車両の現在位置を検出するステップと、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方を、前記ネットワークを介して取得するステップをさらに含み、
前記搭乗者の前記呼吸器疾患を評価するステップは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方に基づいても実行される、請求項１４に記載の方法。
【請求項16】
通信頻度および外部サーバに送信する情報の少なくとも一方を変更するステップをさらに含む、請求項１４に記載の方法。
【請求項17】
前記呼吸器疾患症状の発生頻度に基づいて、前記車両内の空気清浄機を制御するステップをさらに含む、請求項１４に記載の方法。
【請求項18】
前記呼吸器疾患症状の発生頻度に基づいて、前記搭乗者の生体情報を取得するステップをさらに含む、請求項１４に記載の方法。
【請求項19】
前記感染リスク情報に基づいて、前記車両の次の利用前の消毒手順の必要性を示す車両車室汚染情報を生成するステップと、前記車両車室汚染情報を前記外部利用者端末に前記ネットワークを介して送信するステップと、
をさらに含む、請求項１４に記載の方法。
【請求項20】
前記共用車両の予約情報および状態情報を記憶するデータベースにアクセスするステップと、前記車両の前記状態情報を変更して前記車両車室汚染情報に反映させるステップと、
をさらに含む、請求項１９に記載の方法。
【請求項21】
前記消毒手順が必要であることを前記車両車室汚染情報が示し、前記車両が予約されていることを前記予約情報が示す場合、利用可能な他の車両を探し、前記利用可能な車両を前記予約に割り当てるステップをさらに含む、請求項２０に記載の方法。
【請求項22】
前記消毒手順の完了後に、前記車両がクリーンであることを示すように前記車両車室汚染情報を更新するステップをさらに含む、請求項２０に記載の方法。
【請求項23】
感染リスクが高いと判定された前記車両と類似の利用履歴を有する汚染の可能性のある車両を探し、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップをさらに含む、請求項１４に記載の方法。
【請求項24】
音響データを取得するステップと、前記音響データを、前記外部利用者端末、前記外部サーバまたは前記第三者に前記ネットワークを介して送信するステップと、
をさらに含む、請求項１４に記載の方法。
【請求項25】
前記感染リスク情報に基づいて、前記外部サーバ、車両端末、前記外部利用者端末または前記第三者に前記ネットワークを介して広告を配信するステップをさらに含む、請求項１４に記載の方法。
【請求項26】
体調に関する前記搭乗者の報告と前記搭乗者の前記感染リスク情報とに基づいて、前記搭乗者を評価するステップをさらに含む、請求項１４に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、共用車両、特に、レンタル／カーシェアリングの車両群（fleet）を管理するためのシステムおよび方法に関する。
【背景技術】
【0002】
車両群（fleet）を用いるレンタカーサービスやカーシェアリングサービスなどの事業においては、車両群を最大限に活用するうえで各車両の状態の管理が肝要となる。例えば、特許文献１は、車両の状態および使用に関する情報を容易に取得でき、これにより高効率かつ低コストで車両群を管理することができる車両管理システムを提案している。
【先行技術文献】
【特許文献】
【0003】
【文献】米国特許第７，１７７，７３８号明細書
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、新型コロナウイルス感染症（ＣＯＶＩＤ－１９）により、これらのサービスは運用環境の急速な変化に直面している。顧客およびサービス提供業者の双方からの衛生面に対する要求が大幅に増大する可能性がある。サービス提供業者は、顧客の安全を確保するために十分な措置を講じていることを顧客に保証することが求められている。
【0005】
同ウイルスは、主に感染者の咳やくしゃみ、会話などの際に発生する呼吸器飛沫によって人から人へ感染すると考えられている。米国疾病対策センター（ＣＤＣ）は、ＣＯＶＩＤ－１９の原因となるウイルスへの曝露リスクを低減するためのガイドラインを公表した。同ガイドラインは、サービス提供業者に対し、少なくとも、頻繁に触れる車内表面の清掃および消毒を推奨している。
【0006】
また、最近の研究から、ウイルスがエアロゾルと呼ばれる微粒子内に留まり、空気中で数時間にわたり活性を保持できる（survive）ことが示されている。この間、エアロゾルは細胞に感染する可能性があるため、搭乗者が同疾患に接触した疑いがある場合は、より徹底した清掃および消毒手順を行うことが理想的である。しかし、車両の返却時の感染リスクをサービス提供業者が把握することは困難である。
【0007】
したがって、本開示の目的は、車両の搭乗者の健康状態を遠隔で判断でき、これにより次の搭乗者の健康上の安全性を確保することができる共用車両管理システムおよび共用車両管理方法を提供することにある。
【課題を解決するための手段】
【0008】
上記目的を達成するために、本開示の一態様は、
車両の車室内の音響事象を検出するための音響センサを含む音響事象検出部と、
前記音響事象検出部に電気的に接続された車両端末と、
前記車両端末とネットワークを介して通信する外部サーバと、を備え、
前記車両端末および前記外部サーバの少なくとも一方はプロセッサを備え、
該プロセッサは、
前記検出した音響事象から、前記車両内の搭乗者の呼吸器疾患症状を抽出するステップと、
前記搭乗者の前記呼吸器疾患症状を評価して、前記車両に搭乗する予定の次の搭乗者の感染リスクに関連する感染リスク情報を生成するステップと、
前記感染リスク情報を、外部利用者端末、前記外部サーバまたは第三者に前記ネットワークを介して送信するステップと、を実行するように構成されている、共用車両管理システムである。
車両の車室内の音響事象を検出するための音響センサを含む音響事象検出部と、
前記音響事象検出部に電気的に接続された車両端末と、
前記車両端末とネットワークを介して通信する外部サーバと、を備え、
前記車両端末および前記外部サーバの少なくとも一方はプロセッサを備え、
該プロセッサは、
前記検出した音響事象から、前記車両内の搭乗者の呼吸器疾患症状を抽出するステップと、
前記搭乗者の前記呼吸器疾患症状を評価して、前記車両に搭乗する予定の次の搭乗者の感染リスクに関連する感染リスク情報を生成するステップと、
前記感染リスク情報を、外部利用者端末、前記外部サーバまたは第三者に前記ネットワークを介して送信するステップと、を実行するように構成されている、共用車両管理システムである。
【0009】
本明細書において、「車両」という用語は、一般に、人がその中またはその上に乗って、またはそれによって輸送または牽引されるあらゆる装置を意味し、固定されたレール、線路等の上で、または空中もしくは水上で使用されてよい。このような車両として、自動車、バス、電車や汽車（train）、ケーブルカー、ゴンドラのリフト、遊園地の乗り物、航空機、モータボートなどを例示することができる。
【0010】
本明細書では、本発明に係るシステムおよび方法が、共用車両の管理に適用される場合を一例に挙げて説明するが、本発明に係るシステムおよび方法が適用される用途は、共用車両の管理に限定されない。
【0011】
したがって、本明細書において、本発明に係るシステムおよび方法により管理される対象は、移動する「車両」のみならず、移動しない「空間」であってもよい。「空間」とは、所定の部材に囲まれ、少なくとも人が存在することが可能な場所を意味する。限定するものではないが、「空間」の例として施設が挙げられる。施設の例としては、マンションの部屋、会議室、（病院、駅、空港等の）待合室、学校の教室、トイレなどが挙げられるが、これらに限定されるものではない。
【0012】
本開示では、対象が「車両」であることを想定している。このため、車両が「車両端末」を備えると表現している。しかし、対象が「施設」の場合は、「施設」が「施設端末」を備えると表現することができる。したがって、対象が「車両」である場合の「車両」に関する説明は、対象が「施設」である場合の「施設」にも適用される。同様に、対象が「車両」である場合の「車両端末」に関する説明は、対象が「施設」である場合の「施設端末」にも適用される。
【0013】
さらに、本明細書において、本開示に係るシステムおよび方法による管理の対象となる人は、「車両」に搭乗する「搭乗者」に限定されず、移動しない「空間」を利用する全ての人を含んでもよい。対象となる人の例としては、マンションの部屋の住人、病院の待合室で待つ患者、学校の教室で勉強する学生、ホテルの宿泊客などが挙げられる。これらの人達を総称して「利用者」と呼ぶことがある。
【0014】
前記車両端末は、汎用コンピュータ、パーソナルコンピュータ、専用コンピュータ、ワークステーション、ＰＣＳ（個人通信システム）、セルラー式（携帯）電話、スマートフォン、ＲＦＩＤ受信機、ノートパソコン、タブレット端末、およびその他の任意のプログラム可能なデータ処理装置である。
【0015】
前記ネットワークは特定の通信ネットワークに限定されるものではなく、例えば、移動体通信ネットワークやインターネットを含む任意の通信ネットワークを含んでよい。
【0016】
前記プロセッサは、限定するものではないが、汎用プロセッサでも、特定の処理に特化した専用プロセッサでもよい。前記プロセッサは、マイクロプロセッサ、中央処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、プログラマブル論理装置（ＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、コントローラ、マイクロコントローラ、およびこれらの任意の組み合せを含む。
【0017】
前記呼吸器疾患症状としては、限定するものではないが、咳、くしゃみ、息切れ、鼻詰り（sniffle）、咳払い等が挙げられる。
【0018】
一実施形態では、前記システムは、前記車両の現在位置を検出するためのＧＰＳ（全地球測位システム）受信機などの位置検出部をさらに備えてよい。この場合、前記プロセッサは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方を、前記ネットワークを介して取得するステップを実行するようにさらに構成されており、前記搭乗者の前記呼吸器疾患を評価するステップは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方に基づいても実行されてよい。
【0019】
別の実施形態では、前記プロセッサは、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップを実行するようにさらに構成されてよい。
【0020】
さらなる実施形態では、前記システムは、前記車両内に空気清浄機をさらに備えてよく、前記プロセッサは、前記呼吸器疾患症状の発生頻度に基づいて前記空気清浄機を制御するステップを実行するようにさらに構成されてよい。これに加えて、またはこれに代えて、前記システムは、前記搭乗者の生体情報を取得する生体情報取得部をさらに備えてよく、前記プロセッサは、前記呼吸器疾患症状の発生頻度に基づいて前記生体情報取得部を制御するステップを実行するようにさらに構成されてよい。
【0021】
さらに別の実施形態では、前記プロセッサは、前記感染リスク情報に基づいて、前記車両の次の利用前の消毒手順の必要性を示す車両車室汚染情報を生成するステップと、前記車両車室汚染情報を前記外部利用者端末に前記ネットワークを介して送信するステップと、を実行するようにさらに構成されてよい。この実施形態では、前記外部サーバは、前記共用車両の予約情報および状態情報を記憶するデータベースを備えてよく、前記車両の前記状態情報を変更して前記車両車室汚染情報に反映させてよい。前記消毒手順が必要であることを前記車両車室汚染情報が示し、前記車両が予約されていることを前記予約情報が示す場合、前記外部サーバは、利用可能な他の車両を探し、前記利用可能な車両を前記予約に割り当ててよい。前記車両車室汚染情報は、前記消毒手順の完了後に、前記車両がクリーンであることを示すように更新されてよい。
【0022】
さらに別の実施形態では、前記外部サーバは、感染リスクが高いと判定された前記車両と類似の利用履歴を有する汚染の可能性のある車両を探し、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更してよい。
【0023】
本開示の別の態様は、
車両の車室内の音響事象を検出するステップと、
前記検出した音響事象から、前記車両内の搭乗者の呼吸器疾患症状を抽出するステップと、
前記搭乗者の前記呼吸器疾患症状を評価して、前記車両に搭乗する予定の次の搭乗者の感染リスクに関連する感染リスク情報を生成するステップと、
前記感染リスク情報を、外部利用者端末、前記外部サーバまたは第三者に前記ネットワークを介して送信するステップと、を含む、共用車両の管理方法である。
車両の車室内の音響事象を検出するステップと、
前記検出した音響事象から、前記車両内の搭乗者の呼吸器疾患症状を抽出するステップと、
前記搭乗者の前記呼吸器疾患症状を評価して、前記車両に搭乗する予定の次の搭乗者の感染リスクに関連する感染リスク情報を生成するステップと、
前記感染リスク情報を、外部利用者端末、前記外部サーバまたは第三者に前記ネットワークを介して送信するステップと、を含む、共用車両の管理方法である。
【0024】
前記方法は、
前記車両の現在位置を検出するステップと、
前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方を、前記ネットワークを介して取得するステップと、をさらに含んでよい。この場合、前記搭乗者の前記呼吸器疾患を評価するステップは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方に基づいても実行されてよい。
前記車両の現在位置を検出するステップと、
前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方を、前記ネットワークを介して取得するステップと、をさらに含んでよい。この場合、前記搭乗者の前記呼吸器疾患を評価するステップは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方に基づいても実行されてよい。
【0025】
前記方法は、
通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップ、前記呼吸器疾患症状の発生頻度に基づいて、前記車両内の空気清浄機を制御するステップ、および／または前記呼吸器疾患症状の発生頻度に基づいて、前記搭乗者の生体情報を取得するステップをさらに含んでよい。
通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップ、前記呼吸器疾患症状の発生頻度に基づいて、前記車両内の空気清浄機を制御するステップ、および／または前記呼吸器疾患症状の発生頻度に基づいて、前記搭乗者の生体情報を取得するステップをさらに含んでよい。
【0026】
別の実施形態では、前記方法は、前記感染リスク情報に基づいて、前記車両の次の利用前の消毒手順の必要性を示す車両車室汚染情報を生成するステップと、前記車両車室汚染情報を前記外部利用者端末に前記ネットワークを介して送信するステップと、をさらに含んでよい。さらに、前記方法は、前記共用車両の予約情報および状態情報を記憶するデータベースにアクセスするステップと、前記車両の前記状態情報を変更して前記車両車室汚染情報に反映させるステップと、をさらに含んでよい。さらに、前記方法は、前記消毒手順が必要であることを前記車両車室汚染情報が示し、前記車両が予約されていることを前記予約情報が示す場合、利用可能な他の車両を探し、前記利用可能な車両を前記予約に割り当てるステップをさらに含んでよい。前記方法は、前記消毒手順の完了後に、前記車両がクリーンであることを示すように前記車両車室汚染情報を更新するステップをさらに含んでよい。
【0027】
さらなる実施形態では、感染リスクが高いと判定された前記車両と類似の利用履歴を有する汚染の可能性のある車両を探し、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップをさらに含んでよい。
【発明の効果】
【0028】
共用車両管理システムおよび共用車両管理方法によれば、車両の１人の搭乗者または複数人の搭乗者の健康状態を遠隔で判断して、これにより次の搭乗者の健康上の安全性を確保することができる。
【0029】
これらの態様および他の態様は、以下の説明および添付の図面からより容易に理解できる。
【0030】
本発明の様々な他の目的、特徴および付随する利点は、添付の図面を参照して考慮すれば理解がより深まり、完全に理解される。図中、複数の図面にわたり同じ参照符号が同一または同様の部分を参照している。
【図面の簡単な説明】
【0031】
【図1】本開示の一実施形態に係る共用車両管理システムの模式図である。
【図2】本システムのうち、車両に搭載される部分の模式図である。
【図3】本システムのうち、車両に搭載される部分を示すブロック図である。
【図4】本開示の別の実施形態に係る車両端末によって実行されるステップを示すフローチャートである。
【図5】本開示の別の実施形態に係る車両端末によって実行されるステップを示すフローチャートである。
【図6】本開示の一実施形態に係る共用車両管理システムで用いられる外部サーバの例を示すブロック図である。
【図7】本開示の別の実施形態に係る外部サーバによって実行されるステップを示すフローチャートである。
【図8】データベースに記憶されている状態情報および予約情報の例である。
【図9】本実施形態に係るシステムで送信される音響データの例を示す図である。
【図10】本実施形態に係るシステムで送信される広告に関するデータまたは警告に関するデータの例を示す図である。
【図11】航空機内の座席の危険度を示す画面の例を示す。
【図12】本実施形態に係る外部サーバに設けられたデータベースに記憶されている状態情報および予約情報の例を示す図である。
【図13】本実施形態に係るシステムにおける感染リスクの高い車両に対する処理の例を示す図である。
【図14】本実施形態に係るシステムにおける感染リスクの高い航空機に対する処理の例を示す図である。
【発明を実施するための形態】
【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】
ステップＳ１４２において、プロセッサ３２は、上述した空間の換気状況を制御してよい。例えば、プロセッサ３２は、エアコンをオンまたはオフにしてよい。例えば、プロセッサ３２は、エアコンの強弱を制御してよい。例えば、プロセッサ３２は、エアコンの風量を制御してよい。例えば、プロセッサ３２は、エアコンの運転モードを制御してよい。例えば、プロセッサ３２は、外気の取り入れ有無を切り替えてよい。例えば、プロセッサ３２は、空間に設けられる窓の開閉を制御してよい。
【0058】
ステップＳ１４２において、プロセッサ３２は、利用者の感染リスク情報に基づいて、利用者（例えば、タクシーの乗客）に対して、特定の製品の販売を促進させるような広告を配信してよい。広告は、図１０に示すように、表示部、スピーカー、またはＳＮＳにより配信されてよい。プロセッサ３２は、例えば、空間の管理者（例えば、電車内でホットタオルを配ったり軽食を販売したりする鉄道パーサーや、航空機の機内で乗客に各種サービスを提供する客室乗務員（ＣＡ））に対し、利用者（例えば、電車の乗客や航空機の乗客）の感染リスク情報に基づき特定の製品の利用を促す警告を表示部に表示させてよい。表示部は特に限定されず、例えば液晶ディスプレイや有機エレクトロルミネセンス（ＥＬ）ディスプレイなどであってよい。
【0059】
例えば、タクシーに搭載されるディスプレイに、「風邪薬はいかがでしょうか？」、「マスクをご購入されませんか？」のように、タクシーの乗客に対して、風邪薬またはマスクの販売を促進させるような広告が表示されてよい。例えば、電車または航空機に搭載されるディスプレイに、「咳込んでいる人がいます。咳込んでいる人の周りの乗客にマスクを配ってください。」のように、鉄道パーサーまたはＣＡに対して、電車内の咳込んでいる利用者または航空機内の咳込んでいる利用者へマスクの着用を促進させるような警告が表示されてよい。
【0060】
具体的には、図１０に示すように、プロセッサ３２は、特定の製品の購入を利用者に促す広告に関連する情報、および特定の製品の着用を利用者に促す警告に関連する情報を、外部サーバに送信してよい。また、プロセッサ３２は、特定の製品の購入を利用者に促す広告に関連する情報、および特定の製品の着用を利用者に促す警告に関連する情報を、外部サーバおよびインターネットを介して携帯電話に送信してよい。また、プロセッサ３２は、特定の製品の購入を利用者に促す広告に関連する情報、および特定の製品の着用を利用者に促す警告に関連する情報を、外部サーバおよび制御装置を介して出力インタフェースに送信してよい。例えば、出力インタフェースが表示部である場合、表示部は制御装置によって制御され、これらの情報を表示する。例えば、出力インタフェースがスピーカーである場合、スピーカーは制御装置によって制御され、これらの情報を音声として出力する。制御装置は、出力インタフェースを制御できるものであれば、その構成は特に限定されない。制御装置は、例えば、ＰＣやスマートフォンなどに搭載されたＣＰＵ（中央処理装置）であってよい。
【0061】
あるいは、特定の製品の購入を利用者に促す広告に関連する情報、特定の製品の着用を利用者に促す警告に関連する情報などが、広告主や管理者等によって外部サーバに登録されてもよい。例えば、広告主が、特定の製品の購入を利用者に促す広告に関連する情報を外部サーバに保存してよい。例えば、管理者が、特定の製品の着用を利用者に促す警告に関連する情報を外部サーバに記憶してよい。外部サーバは、これらの情報をプロセッサ３２に送信し、プロセッサ３２は、外部サーバから受信したこれらの情報を記憶することができる。
【0062】
ステップＳ１４４において、プロセッサ３２と外部サーバ５０との間の通信頻度や、外部サーバ５０に送信する情報の種類が変更されてよい。例えば、通常の状態では、車両端末３０および外部サーバ５０の通信および／または負荷に関連するコストを削減するために、通信頻度は低く設定されている。搭乗者Ｐの感染リスクが高い場合は、搭乗者の健康状態をより頻繁に把握できるよう通信頻度が高く設定される。これに加えて、またはこれに代えて、搭乗者の健康状態をより正確に評価できるよう、生体情報取得部２６が収集した追加の情報が、外部サーバ５０に送信する情報に組み込まれてもよい。
【0063】
ステップＳ１４４において、プロセッサ３２は、管理者の行為に応じて、プロセッサ３２と外部サーバ５０との通信頻度を制御してよい。管理者の行為としては、例えば、管理者が所定の回数ボタンを押す、管理者が所定のパターンで咳をする、管理者が所定のリズムで音声データを出力するなどが挙げられる。所定の回数、所定のパターン、所定のリズムなどは、あらかじめ設定され、記憶部に記憶されていてよい。音声データは、音響事象であってもよいし、新たに生成された音声データであってもよい。
【0064】
例えば、挙動不審で怪しい動きをしている乗客がタクシーに乗車してきた場合、タクシードライバーが３回ハンドルを叩くと、プロセッサ３２は、プロセッサ３２と外部サーバ５０との通信頻度を高くしてよい。これにより、タクシードライバーは、挙動不審で怪しい動きをしている乗客に知られることなく、外部に危険を知らせ、外部からの助けを得ることが可能となる。
【0065】
次に、プロセッサ３２は、ステップＳ１５０において、ネットワークインタフェース４０を介して、感染リスク情報および／または車両車室汚染情報をネットワーク経由で外部サーバ５０に送信する。外部サーバ５０は、情報の全部または一部を外部利用者端末６０に転送する。
【0066】
外部サーバ５０は、プロセッサ３２から受信した情報を様々な方法で利用してよい。例えば、外部サーバ５０は、車両からのデータを経時的に蓄積し、呼吸器疾患および／またはアレルギーの発生の手掛かりを監視してよい。また、外部サーバ５０は、複数の車両からの感染リスク情報を地図上に可視化し、ネットワークを介して、地図をドライバーに提供したり、感染リスクが高いと考えられるエリア内を走行している車両または該エリアに向かって走行する車両に対して警告を送ったりしてよい。この情報および地図が、他のサービス提供業者やＣＤＣなどの政府機関に提供されてよい。
【0067】
ステップＳ１５０において、本発明に係るシステムおよび方法が、共用車両の管理に適用される場合、プロセッサ３２は、利用者の感染リスク情報、および目的地にいる人達にとっての対策情報を送信して、目的地にいる人達に通知してもよい。
【0068】
例えば、タクシーまたはバスの目的地がアミューズメントパークである場合、プロセッサ３２は、アミューズメントパークの来園者に対して、「これから、感染リスクの高い人が、ここに到着しますよ。マスクを全員着用してください。」という通知をしてもよい。例えば、救急車の目的地が病院である場合、プロセッサ３２は、病院にいる医師達および看護師達に対して、「これから、感染リスクの高い患者が、ここに到着しますよ。注意して治療してください。」という通知をしてもよい。
【0069】
ステップＳ１５０において、プロセッサ３２は、利用者、および利用者の周囲にいる利用者以外の人達に通知するために、利用者の感染リスク情報を外部サーバ、外部利用者端末または第三者に送信してもよい。例えば、プロセッサ３２は、所定の利用者の感染リスクが高い旨または所定の利用者の感染リスクが低い旨を、表示部に表示させてよい。例えば、プロセッサ３２は、所定の利用者の感染リスクが高い旨または所定の利用者の感染リスクが低い旨を、音声出力インタフェースに出力させてよい。これにより、利用者の周囲にいる利用者以外の人達を安心させることができ、且つ、利用者の周囲にいる利用者以外の人達の警戒意識を促進させることができる。
【0070】
例えば、プロセッサ３２は、電車に乗っている乗客全員に対して、感染リスクの高い乗客の感染リスク情報を通知するために、電車に搭載されるディスプレイに、「３号車の車両には、感染リスクの高い乗客がいます。したがって、３号車の車両は、感染リスクが高くなっています。」という画面を表示させてもよい。例えば、プロセッサ３２は、学校で勉強している生徒全員に対して、感染リスクの高い生徒の感染リスク情報を通知するために、校内のスピーカーから、「２組の教室には、感染リスクの高い生徒がいます。したがって、２組の教室は、感染リスクが高くなっています。」という音声を出力させてもよい。
【0071】
ステップＳ１５０において、プロセッサ３２は、利用者の感染リスク情報に基づいて、空間を管理する管理者（例えば、タクシードライバー、空間を運営する機関の担当者）に対して、空間の換気状況を改善する旨を通知してよい。
【0072】
例えば、プロセッサ３２は、タクシーの乗客の感染リスクが低いにも拘らず、タクシーの搭乗者の呼吸器疾患の症状を高頻度で検出した場合、タクシーの内部の環境が悪化していると予測し、タクシードライバーに、「タクシーの内部が埃っぽいので、直ちに、タクシーの内部の換気状況を改善してください。」という旨を通知してよい。
【0073】
例えば、プロセッサ３２は、病院の待合室で待つ患者の感染リスクが低いにも拘らず、病院の待合室で待つ患者の呼吸器疾患の症状を高頻度で検出した場合、病院の待合室の内部の環境が悪化していると予測し、病院を運営する機関の担当者に、「病院の待合室の内部に外気を取り込んで、換気状況を改善してください。」という旨を通知してよい。
【0074】
これにより、管理者は、利用者の感染リスクが実際に高いのか否か、あるいは、空間の内部の環境が悪いため、利用者に呼吸器疾患の症状が現れているのか否か、を容易に判断することが可能となる。
【0075】
ステップＳ１５０において、プロセッサ３２は、体調に関する利用者の報告（例えば、体調に関する質問に対する利用者の回答）、および利用者の感染リスク情報に基づいて、利用者の評価を行ってよい。
【0076】
例えば、乗車前の問診により、乗客が「咳およびくしゃみが続いていません。」と回答したにも拘らず、プロセッサ３２が当該搭乗者の呼吸器疾患の症状を高頻度で検出した場合（すなわち、プロセッサ３２が当該乗客の感染リスクが高いことを検出した場合）、プロセッサ３２は、当該乗客が嘘をついていると判定し、当該乗客を低く評価してよい。
【0077】
例えば、乗車前の問診により、乗客が「咳およびくしゃみが続いていません。」と回答し、プロセッサ３２が当該搭乗者の呼吸器疾患の症状を低頻度で検出した場合（すなわち、プロセッサ３２が当該乗客の感染リスクが低いことを検出した場合）、プロセッサ３２は、当該乗客が正直に答えていると判定し、当該乗客を高く評価してよい。
【0078】
正直に答えている利用者が高評価とされ、嘘をついている利用者が低評価とされることで、高評価を得ようとする利用者の意志を促進させることができるため、管理者に正直に回答しようとする利用者の数を増やすことができる。これにより、管理者は確かな情報に基づいて、利用者に適切な処置を施すことが可能となる。
【0079】
ステップＳ１５０において、プロセッサ３２は、「空間」が、特に、広い空間である場合、広い空間の内部において、どの箇所の感染リスクが高いか、または、どの箇所の感染リスクが低いかを、利用者に通知してよい。広い空間としては、例えば、航空機、学校、バス、マンション、ホテルなどが挙げられる。
【0080】
例えば、プロセッサ３２は、航空機の内部において、ファーストクラスの座席の感染リスクが高く、通常クラスの座席の感染リスクが低い、という旨を利用者に通知してよい。例えば、プロセッサ３２は、ホテルの内部に設けられる複数のトイレにおいて、右から３番目のトイレの感染リスクが高く、その他のトイレの感染リスクが低い、という旨をディスプレイを用いた画像により利用者に通知してよい。また、プロセッサ３２は、図１１に示すように、どの座席の感染リスクが高いかを利用者に通知してよい。
【0081】
プロセッサ３２は、例えば、「空間」の危険度を示す画面をディスプレイに表示させてよい。具体的には、プロセッサ３２は、図１１に示すように、航空機内の座席の危険度を示す画面を、航空機に搭載されたＰＣのディスプレイに表示させてもよい。航空機内の座席の危険度が、形態の変化で表現されてよい。例えば、航空機内の座席の危険度が色の変化で表現されてよい。
【0082】
図１１は、航空機内の座席の危険度を示す画面の例であるが、「空間」の危険度を示す画面はこの例に限定されない。「空間」の危険度を示す画面は、船舶内の座席の危険度を示す画面、待合室内の座席の危険度を示す画面など、どのようなタイプの施設の危険度を示す画面でもよい。
【0083】
航空機内の座席の危険度を示す画面において、例えば、図１１に示すように、座席４Ｆおよび座席４Ｇに斜めストライプのパターンが表示されており、航空機内の座席のうち座席４Ｆおよび座席４Ｇが危険度が「高」の座席であることを示す。航空機内の座席の危険度を示す画面において、例えば、座席３Ｄ、座席３Ｅ、座席３Ｆ、座席３Ｇ、座席３Ｈ、座席３Ｉ、座席４Ｄ、座席４Ｅ、座席４Ｈ、座席４Ｉ、座席５Ｄ、座席５Ｅ、座席５Ｆ、座席５Ｇ、座席５Ｈ、および座席５Ｉにドットのパターンが表示されており、座席３Ｄ、座席３Ｅ、座席３Ｆ、座席３Ｇ、座席３Ｈ、座席３Ｉ、座席４Ｄ、座席４Ｅ、座席４Ｈ、座席４Ｉ、座席５Ｄ、座席５Ｅ、座席５Ｆ、座席５Ｇ、座席５Ｈ、および座席５Ｉが航空機内の座席のうち危険度が「中」の座席であることを示す。航空機内の座席の危険度を示す画面において、例えば、上記の座席以外の座席がパターンなしで表示されており、上記の座席以外の座席が航空機内の座席のうち危険度が「低」の座席であることを示す。危険度は、その座席を使用すると予想される次の利用者の感染の可能性（リスク）と関連付けて定義されてよい。例えば、１％未満が「低」、１％以上２０％未満が「中」、２０％以上が「高」と定義されてよい。また、危険度が、座席の次の利用前の消毒の必要性と関連して定義されてもよい。
【0084】
このように、航空機内の座席の危険度を示す画面を表示部に表示させることで、管理者（航空機内で搭乗者に各種サービスを提供するＣＡなど）は、感染リスクの高い座席と感染リスクの低い座席とを瞬時に判別することができる。
【0085】
また、航空機内の座席の危険度が色の変化で表現されてよい。航空機内の座席の危険度を示す画面において、例えば、座席４Ｆおよび座席４Ｇを赤色で表示して、航空機内の座席のうち座席４Ｆおよび座席４Ｇが危険度が「高」の座席であることを示してよい。航空機内の座席の危険度を示す画面において、例えば、座席３Ｄ、座席３Ｅ、座席３Ｆ、座席３Ｇ、座席３Ｈ、座席３Ｉ、座席４Ｄ、座席４Ｅ、座席４Ｈ、座席４Ｉ、座席５Ｄ、座席５Ｅ、座席５Ｆ、座席５Ｇ、座席５Ｈ、および座席５Ｉを黄色で表示して、座席３Ｄ、座席３Ｅ、座席３Ｆ、座席３Ｇ、座席３Ｈ、座席３Ｉ、座席４Ｄ、座席４Ｅ、座席４Ｈ、座席４Ｉ、座席５Ｄ、座席５Ｅ、座席５Ｆ、座席５Ｇ、座席５Ｈ、および座席５Ｉが航空機内の座席のうち危険度が「中」の座席であることを示してよい。航空機内の座席の危険度を示す画面において、例えば、上記の座席以外の座席を青色で表示して、上記の座席以外の座席が航空機内の座席のうち危険度が「低」の座席であることを示してよい。
【0086】
図６に示す一実施形態では、外部サーバ５０は、情報を活用して、車両群全体のスケジュール管理を行う。外部サーバ５０は、プロセッサ５２、データベース５４およびネットワークインタフェース５６を備え、これらがバス５８を介して相互に接続されている。データベース５４は、システム１０が管理する共用車両の予約情報および状態情報を記憶する。
【0087】
次に、図７および図８を参照して、車両群のスケジュールを管理する手順を説明する。図７は、外部サーバが実行するステップを示すフローチャートであり、図８は、データベース５４が記憶している状態情報および予約情報を含む車両群スケジュールの例である。本実施形態では、外部サーバ５０は、車両Ａ、車両Ｂ、および車両Ｃのスケジュールを管理している。
【0088】
プロセッサ５２は、ネットワークインタフェース５６を介して、ネットワーク経由で車両端末３０から車両車室汚染情報を受信する（Ｓ２１０）。車両車室汚染情報の内容に応じて、プロセッサ５２は、車両２０の状態情報を変更して、データベース５４に記憶されている車両車室汚染情報に反映させる（Ｓ２２０）。例えば、車両Ａからの車両車室汚染情報が消毒手順が必要であることを示す場合、プロセッサ５２は、車両Ａの状態情報を「使用中」から「利用不可」に変更し、車両Ａに予約が割り当てられないようにする。次に、プロセッサ５２は、車両Ａの予約情報を参照する。この例では、正午から午後３時の間の時間帯に既に予約が存在する。車両Ａは次の利用までに消毒が必要であり、消毒の手続きが完了するまで利用不可であるため、この予約を変更しなければならない。このため、プロセッサ５２は、車両群スケジュールからこの時間帯に利用可能な車両を探す。この時間帯に車両Ｂが利用可能であるため、プロセッサ５２は、車両Ｂに予約を再割り当てし、予約情報を車両Ａから車両Ｂに移動させる（Ｓ２３０）。あるいは、プロセッサ５２は、別の時間帯（例えば、午後３時から午後６時の間）に予約を再スケジュールして消毒手順を完了するのに十分な時間を確保する。消毒手順の完了報告を受けると、プロセッサ５２は、車両がクリーンであることを示すために車両車室汚染情報を「利用不可」から「利用可」に更新する。
【0089】
任意選択で、外部サーバ５０は、車両２０と類似する利用履歴を有する車両を探してよい（Ｓ２４０）。類似の利用履歴を有する車両が見つかり、その車両の感染リスクが高い場合、外部サーバ５０は、感染リスクの現在の状態に関わらず、プロセッサ３２にコマンドを送信し、通信頻度および／または外部サーバ５０に送信する情報を変更してもよい（Ｓ２５０）。
【0090】
任意選択で、外部サーバ５０は、外部利用者端末６０に通知を送信してもよい。この通知には、例えば、消毒手順の指示および予約の更新が含まれてよい。また、外部サーバ５０は、このような通知を、電子メールまたはテキストメッセージを通じて消毒サービスの業者または予約済みの顧客に送信してよい。
【0091】
外部サーバは、上記のような車両群スケジュールだけでなく、施設スケジュールを記憶してもよい。図１２は、データベース５４が記憶している状態情報および予約情報の例を示す図である。図１２では、この施設は、部屋Ａ、部屋Ｂ、部屋Ｃの３つの部屋を有する。午前９時から正午、正午から午後３時、午後３時から午後６時など、３つの時間帯が図示されている。
【0092】
プロセッサ５２は、ネットワークインタフェース５６を介して、部屋Ａの汚染情報、部屋Ｂの汚染情報、および部屋Ｃの汚染情報を受信する。プロセッサ５２は、部屋Ａの汚染情報、部屋Ｂの汚染情報、および部屋Ｃの汚染情報に基づいて、部屋Ａの状態情報、部屋Ｂの状態情報、および部屋Ｃの状態情報を変更する。
【0093】
例えば、午前９時から正午の間の部屋Ａの汚染情報として消毒手順が必要であることを示す情報を受信すると、プロセッサ５２は、部屋Ａの状態情報を「使用中」から「利用不可」に変更する。例えば、午前９時から正午の間の部屋Ｂの汚染情報として消毒手順が不要であることを示す情報を受信すると、プロセッサ５２は、部屋Ｂの状態情報を変更せずに「使用中」のままとする。例えば、午前９時から正午の間の部屋Ｃの汚染情報として消毒手順が不要であることを示す情報を受信すると、プロセッサ５２は、部屋Ｂの状態情報を変更せずに「利用可」のままとする。
【0094】
次に、プロセッサ５２は、部屋Ａの汚染情報、部屋Ｂの汚染情報、部屋Ｃの汚染情報に加えて、施設スケジュールに基づき、同時間帯に利用可能な別の部屋の予約情報、および同部屋が利用可能となる別の時間帯の予約情報を検索する。次に、プロセッサ５２は、これらの予約情報に基づいて、部屋Ａの予約情報、部屋Ｂの予約情報、または部屋Ｃの予約情報を変更する。
【0095】
例えば、プロセッサ５２は、正午から午後３時の間、部屋Ａは利用不可であり、部屋Ｂは利用可能であり、部屋Ｃは利用不可であると判定した場合、「部屋Ａが正午から午後３時の間予約済みである」ことを示す部屋Ａの予約情報を、「部屋Ｂが正午から午後３時の間予約済みである」ことを示す部屋Ｂの予約情報に変更する。例えば、プロセッサ５２は、午後３時から午後６時の間、部屋Ａは利用可能であり、部屋Ｂは利用可能あり、部屋Ｃは利用不可であると判定した場合、「部屋Ａが正午から午後３時の間予約済みである」ことを示す部屋Ａの予約情報を、「部屋Ａが午後３時から午後６時の間予約済みである」ことを示す部屋Ａの予約情報に変更する。また、プロセッサ５２は、午後３時から午後６時の間、部屋Ａは利用可能であり、部屋Ｂは利用可能であり、部屋Ｃは利用不可であると判定した場合、「部屋Ａが正午から午後３時の間予約済みである」ことを示す部屋Ａの予約情報を、「部屋Ｂが午後３時から午後６時の間予約済みである」ことを示す部屋Ｂの予約情報に変更することができる。
【0096】
このように、プロセッサ５２が、部屋Ａの汚染情報、部屋Ｂの汚染情報、部屋Ｃの汚染情報、および施設スケジュールに関連する情報に基づいて各部屋を適切に管理することにより、利用者は、適切な時間帯に、消毒手順が必要な部屋を使用することなく、消毒手順が不要な部屋のみを使用することができる。これにより、利用者の健康を害することなく、施設の利用者の安全を確保することができる共有施設の管理システム１０を実現することができる。
【0097】
図１３に示すように、「消毒手順が必要である」車両が、必要に応じて他の車両に変更されてよい。
【0098】
プロセッサ５２は、１号車、２号車、および４号車について「消毒手順が不要」であることを示す情報を受信し、３号車について「消毒手順が必要である」であることを示す情報を受信すると、３号車を上記以外の車両（new car）に変更する旨を決定してよい。次に、プロセッサ５２は、決定の結果、すなわち、３号車を上記以外の車両に変更する旨を、例えば、先頭車両に搭載されたＰＣのディスプレイに表示してよい。
【0099】
図１４に示すように、「消毒手順が必要な」航空機が、必要に応じて別の航空機に機材変更されてよい。
【0100】
プロセッサ５２は、第１の航空機について「消毒手順が必要である」ことを示す情報を受信し、第２の航空機および第３の航空機について「消毒手順が不要である」ことを示す情報を受信すると、第１の航空機を上記以外の航空機（new airplane）に機材変更することを決定し、当該機材変更処理に要する時間が１．５時間であると判定してよい。次に、プロセッサ５２は、判定結果、すなわち、第１の航空機を上記以外の航空機に機材変更する旨と、当該機材変更処理に要する処理時間とを、例えば、運航管理センターに設けられたＰＣのディスプレイに表示させてよい。
【0101】
図１４に示すように、「消毒手順が必要である」航空機に対し、必要に応じて消毒が行われてよい。
【0102】
プロセッサ５２は、第１の航空機について「消毒手順が必要である」ことを示す情報を受信し、第２の航空機および第３の航空機について「消毒手順が不要である」ことを示す情報を受信すると、第１の航空機に対して消毒を行うことを決定し、当該消毒手順に要する時間を２時間と判定してよい。次に、プロセッサ５２は、判定結果、すなわち、第１の航空機に対して消毒を行う旨と、消毒処理に要する処理時間とを、例えば、運行管理センターに設けられたＰＣのディスプレイに表示させてよい。
【0103】
図１４に示すように、「消毒手順が必要である」航空機を、別の空港から回送飛行で到着した別の航空機に変更してよい。
【0104】
プロセッサ５２は、第１の航空機について「消毒手順が必要である」ことを示す情報を受信し、第２の航空機および第３の航空機について「消毒手順が不要である」ことを示す情報を受信した場合、第１の航空機を、別の空港から回送飛行で到着する他の航空機を使用する旨を決定し、当該回送飛行処理に要する時間が特定の時間であると判定してよい。例えば、プロセッサ５２は、第１の航空機を、回送飛行によって空港Ａから到着する別の航空機に変更する旨を決定し、この回送飛行処理に要する時間が３時間であると判定してよい。例えば、プロセッサ５２は、第１の航空機を、回送飛行によって空港Ｂから到着する別の航空機に変更する旨を決定し、当該回送飛行処理に要する時間が４時間であると判定してよい。
【0105】
次に、プロセッサ５２は、判定結果、すなわち、第１の航空機を、回送飛行で別の空港から到着する別の航空機に変更する旨と、回送飛行の処理に要する処理時間とを、例えば、運航管理センターに設けられたＰＣのディスプレイに表示させてよい。例えば、プロセッサ５２は、第１の航空機を、空港Ａから回送飛行で到着する新しい航空機に変更するための回送飛行処理に要する時間が３時間であることを、表示部に表示させてよい。例えば、プロセッサ５２は、第１の航空機を、空港Ｂから回送飛行で到着する新しい航空機に変更するための回送飛行処理に要する時間が４時間であることを、表示部に表示させてよい。
【0106】
「消毒手順が必要である」航空機に対して行う処理の種類、および「消毒手順が必要である」航空機に対して行うための処理時間は、特に限定されない。処理の種類および処理時間は、コントローラにより予め設定しておいてもよいし、管理者などが自由に設定してもよい。
【0107】
上記の説明および添付の図面に記載した事項は、例示のみを目的として提示したものであり、限定するものではない。特定の実施形態を図示および説明したが、本出願人の貢献のより広い態様から逸脱することなく、変更および修正を行ってもよいことは、当業者にとって明らかであろう。
【0108】
例えば、上記のステップが、一連の操作、または、プログラムを実行可能なコンピュータシステムまたは他のハードウェアによって実行される操作に関するプログラムとして、コンピュータ可読非一時的記憶媒体に記憶されてよい。また、当該操作が、プログラムコードを実装した専用回路、１つ以上のプロセッサで実行される論理ブロックやプログラムモジュール等によって実行されてもよい。さらに、上記の実施形態では、図４および図５に図示した全てのステップが、車両端末３０のプロセッサ３２によって実行されているが、これらのステップの全てまたは一部が、外部サーバ５０によって実行されてもよい。
【産業上の利用可能性】
【0109】
本開示では、主にレンタカー／シェアカー施設に関する車両管理システムについて説明したが、本発明の利用は、このようなレンタカー事業に限定されるものではない。本発明は、タクシー車両群の管理、ライドシェア車両の管理、配送トラック車両群の管理、またはその他の車両管理業界にも利用可能である。
【0110】
保護を求める実際の範囲は、先行技術に基づく適切な観点から鑑みて下記の特許請求の範囲に規定されることが意図される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】