(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
【FI】
G06Q50/40
G06Q30/0645
G16H50/80
(21)【出願番号】P 2022576347
(86)(22)【出願日】2021-07-02
(86)【国際出願番号】 JP2021025202
(87)【国際公開番号】W WO2022004887
(87)【国際公開日】2022-01-06
【審査請求日】2023-02-09
(32)【優先日】2020-07-02
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】000000033
【氏名又は名称】旭化成株式会社
(74)【代理人】
【識別番号】100147485
【氏名又は名称】杉村 憲司
(74)【代理人】
【識別番号】230118913
【氏名又は名称】杉村 光嗣
(74)【代理人】
【識別番号】100165951
【氏名又は名称】吉田 憲悟
(74)【代理人】
【識別番号】100213333
【氏名又は名称】鹿山 昌代
(72)【発明者】
【氏名】森住 昌弘
(72)【発明者】
【氏名】本庄 崇文
(72)【発明者】
【氏名】矢吹 勇人
(72)【発明者】
【氏名】平川 博之
【審査官】星野 昌幸
(56)【参考文献】
【文献】国際公開第2013/006618(WO,A2)
【文献】特開2020-008969(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 ~ 99/00
G16H 50/80
(57)【特許請求の範囲】
【請求項1】
車両の車室内の音響事象を検出するための音響センサを含む音響事象検出部と、
前記音響事象検出部に電気的に接続された車両端末と、
前記車両端末とネットワークを介して通信する外部サーバと、を備え、
前記車両端末および前記外部サーバの少なくとも一方はプロセッサを備え、
該プロセッサは、
前記検出した音響事象から、前記車両内の搭乗者の呼吸器疾患症状を抽出するステップと、
前記搭乗者の前記呼吸器疾患症状を評価して、前記車両に搭乗する予定の次の搭乗者の感染リスクに関連する感染リスク情報を生成するステップと、
前記感染リスク情報を、外部利用者端末、前記外部サーバまたは第三者に前記ネットワークを介して送信するステップと、を実行するように構成されている、共用車両管理システム。
【請求項2】
前記車両の現在位置を検出するための位置検出部をさらに備え、
前記プロセッサは、
前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方を、前記ネットワークを介して取得するステップを実行するように構成されており、
前記搭乗者の前記呼吸器疾患を評価するステップは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方に基づいても実行される、請求項1に記載のシステム。
【請求項3】
前記プロセッサは、
通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップを実行するようにさらに構成されている、請求項1に記載のシステム。
【請求項4】
前記車両内に空気清浄機をさらに備え、
前記プロセッサは、
前記呼吸器疾患症状の発生頻度に基づいて前記空気清浄機を制御するステップを実行するようにさらに構成されている、請求項1に記載のシステム。
【請求項5】
前記搭乗者の生体情報を取得する生体情報取得部をさらに備え、
前記プロセッサは、
前記呼吸器疾患症状の発生頻度に基づいて前記生体情報取得部を制御するステップを実行するようにさらに構成されている、請求項1に記載のシステム。
【請求項6】
前記プロセッサは、
前記感染リスク情報に基づいて、前記車両の次の利用前の消毒手順の必要性を示す車両車室汚染情報を生成するステップと、
前記車両車室汚染情報を前記外部利用者端末に前記ネットワークを介して送信するステップと、を実行するようにさらに構成されている、請求項1に記載のシステム。
【請求項7】
前記外部サーバは、前記共用車両の予約情報および状態情報を記憶するデータベースを備え、前記車両の前記状態情報を変更して前記車両車室汚染情報に反映させる、請求項6に記載のシステム。
【請求項8】
前記消毒手順が必要であることを前記車両車室汚染情報が示し、前記車両が予約されていることを前記予約情報が示す場合、前記外部サーバは、利用可能な他の車両を探し、前記利用可能な車両を前記予約に割り当てる、請求項7に記載のシステム。
【請求項9】
前記車両車室汚染情報は、前記消毒手順の完了後に、前記車両がクリーンであることを示すように更新される、請求項7に記載のシステム。
【請求項10】
前記外部サーバは、感染リスクが高いと判定された前記車両と類似の利用履歴を有する汚染の可能性のある車両を探し、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更する、請求項1に記載のシステム。
【請求項11】
前記音響センサは音響データを取得し、
前記プロセッサは、
前記音響データを、前記外部利用者端末、前記外部サーバまたは前記第三者に前記ネットワークを介して送信するステップを実行するように構成されている、請求項1に記載のシステム。
【請求項12】
前記プロセッサは、
前記感染リスク情報に基づいて、前記外部サーバ、前記車両端末、前記外部利用者端末または前記第三者に前記ネットワークを介して広告を配信するステップを実行するようにさらに構成されている、請求項1に記載のシステム。
【請求項13】
前記プロセッサは、
体調に関する前記搭乗者の報告と前記搭乗者の前記感染リスク情報とに基づいて、前記搭乗者を評価するステップを実行するようにさらに構成されている、請求項1に記載のシステム。
【請求項14】
車両の車室内の音響事象を検出するステップと、
前記検出した音響事象から、前記車両内の搭乗者の呼吸器疾患症状を抽出するステップと、
前記搭乗者の前記呼吸器疾患症状を評価して、前記車両に搭乗する予定の次の搭乗者の感染リスクに関連する感染リスク情報を生成するステップと、
前記感染リスク情報を、外部利用者端末
、外部サーバまたは第三者
にネットワークを介して送信するステップと、を含む共用車両の管理方法。
【請求項15】
前記車両の現在位置を検出するステップと、
前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方を、前記ネットワークを介して取得するステップをさらに含み、
前記搭乗者の前記呼吸器疾患を評価するステップは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方に基づいても実行される、請求項14に記載の方法。
【請求項16】
通信頻度および外部サーバに送信する情報の少なくとも一方を変更するステップ
をさらに含む、請求項14に記載の方法。
【請求項17】
前記呼吸器疾患症状の発生頻度に基づいて、前記車両内の空気清浄機を制御するステップ
をさらに含む、請求項14に記載の方法。
【請求項18】
前記呼吸器疾患症状の発生頻度に基づいて、前記搭乗者の生体情報を取得するステップ
をさらに含む、請求項14に記載の方法。
【請求項19】
前記感染リスク情報に基づいて、前記車両の次の利用前の消毒手順の必要性を示す車両車室汚染情報を生成するステップと、
前記車両車室汚染情報を前記外部利用者端末に前記ネットワークを介して送信するステップと、
をさらに含む、請求項14に記載の方法。
【請求項20】
前記共用車両の予約情報および状態情報を記憶するデータベースにアクセスするステップと、
前記車両の前記状態情報を変更して前記車両車室汚染情報に反映させるステップと、
をさらに含む、請求項19に記載の方法。
【請求項21】
前記消毒手順が必要であることを前記車両車室汚染情報が示し、前記車両が予約されていることを前記予約情報が示す場合、利用可能な他の車両を探し、前記利用可能な車両を前記予約に割り当てるステップ
をさらに含む、請求項20に記載の方法。
【請求項22】
前記消毒手順の完了後に、前記車両がクリーンであることを示すように前記車両車室汚染情報を更新するステップ
をさらに含む、請求項20に記載の方法。
【請求項23】
感染リスクが高いと判定された前記車両と類似の利用履歴を有する汚染の可能性のある車両を探し、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップ
をさらに含む、請求項14に記載の方法。
【請求項24】
音響データを取得するステップと、
前記音響データを、前記外部利用者端末、前記外部サーバまたは前記第三者に前記ネットワークを介して送信するステップと、
をさらに含む、請求項14に記載の方法。
【請求項25】
前記感染リスク情報に基づいて、前記外部サーバ
、車両端末、前記外部利用者端末または前記第三者に前記ネットワークを介して広告を配信するステップ
をさらに含む、請求項14に記載の方法。
【請求項26】
体調に関する前記搭乗者の報告と前記搭乗者の前記感染リスク情報とに基づいて、前記搭乗者を評価するステップ
をさらに含む、請求項14に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、共用車両、特に、レンタル/カーシェアリングの車両群(fleet)を管理するためのシステムおよび方法に関する。
【背景技術】
【0002】
車両群(fleet)を用いるレンタカーサービスやカーシェアリングサービスなどの事業においては、車両群を最大限に活用するうえで各車両の状態の管理が肝要となる。例えば、特許文献1は、車両の状態および使用に関する情報を容易に取得でき、これにより高効率かつ低コストで車両群を管理することができる車両管理システムを提案している。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、新型コロナウイルス感染症(COVID-19)により、これらのサービスは運用環境の急速な変化に直面している。顧客およびサービス提供業者の双方からの衛生面に対する要求が大幅に増大する可能性がある。サービス提供業者は、顧客の安全を確保するために十分な措置を講じていることを顧客に保証することが求められている。
【0005】
同ウイルスは、主に感染者の咳やくしゃみ、会話などの際に発生する呼吸器飛沫によって人から人へ感染すると考えられている。米国疾病対策センター(CDC)は、COVID-19の原因となるウイルスへの曝露リスクを低減するためのガイドラインを公表した。同ガイドラインは、サービス提供業者に対し、少なくとも、頻繁に触れる車内表面の清掃および消毒を推奨している。
【0006】
また、最近の研究から、ウイルスがエアロゾルと呼ばれる微粒子内に留まり、空気中で数時間にわたり活性を保持できる(survive)ことが示されている。この間、エアロゾルは細胞に感染する可能性があるため、搭乗者が同疾患に接触した疑いがある場合は、より徹底した清掃および消毒手順を行うことが理想的である。しかし、車両の返却時の感染リスクをサービス提供業者が把握することは困難である。
【0007】
したがって、本開示の目的は、車両の搭乗者の健康状態を遠隔で判断でき、これにより次の搭乗者の健康上の安全性を確保することができる共用車両管理システムおよび共用車両管理方法を提供することにある。
【課題を解決するための手段】
【0008】
上記目的を達成するために、本開示の一態様は、
車両の車室内の音響事象を検出するための音響センサを含む音響事象検出部と、
前記音響事象検出部に電気的に接続された車両端末と、
前記車両端末とネットワークを介して通信する外部サーバと、を備え、
前記車両端末および前記外部サーバの少なくとも一方はプロセッサを備え、
該プロセッサは、
前記検出した音響事象から、前記車両内の搭乗者の呼吸器疾患症状を抽出するステップと、
前記搭乗者の前記呼吸器疾患症状を評価して、前記車両に搭乗する予定の次の搭乗者の感染リスクに関連する感染リスク情報を生成するステップと、
前記感染リスク情報を、外部利用者端末、前記外部サーバまたは第三者に前記ネットワークを介して送信するステップと、を実行するように構成されている、共用車両管理システムである。
【0009】
本明細書において、「車両」という用語は、一般に、人がその中またはその上に乗って、またはそれによって輸送または牽引されるあらゆる装置を意味し、固定されたレール、線路等の上で、または空中もしくは水上で使用されてよい。このような車両として、自動車、バス、電車や汽車(train)、ケーブルカー、ゴンドラのリフト、遊園地の乗り物、航空機、モータボートなどを例示することができる。
【0010】
本明細書では、本発明に係るシステムおよび方法が、共用車両の管理に適用される場合を一例に挙げて説明するが、本発明に係るシステムおよび方法が適用される用途は、共用車両の管理に限定されない。
【0011】
したがって、本明細書において、本発明に係るシステムおよび方法により管理される対象は、移動する「車両」のみならず、移動しない「空間」であってもよい。「空間」とは、所定の部材に囲まれ、少なくとも人が存在することが可能な場所を意味する。限定するものではないが、「空間」の例として施設が挙げられる。施設の例としては、マンションの部屋、会議室、(病院、駅、空港等の)待合室、学校の教室、トイレなどが挙げられるが、これらに限定されるものではない。
【0012】
本開示では、対象が「車両」であることを想定している。このため、車両が「車両端末」を備えると表現している。しかし、対象が「施設」の場合は、「施設」が「施設端末」を備えると表現することができる。したがって、対象が「車両」である場合の「車両」に関する説明は、対象が「施設」である場合の「施設」にも適用される。同様に、対象が「車両」である場合の「車両端末」に関する説明は、対象が「施設」である場合の「施設端末」にも適用される。
【0013】
さらに、本明細書において、本開示に係るシステムおよび方法による管理の対象となる人は、「車両」に搭乗する「搭乗者」に限定されず、移動しない「空間」を利用する全ての人を含んでもよい。対象となる人の例としては、マンションの部屋の住人、病院の待合室で待つ患者、学校の教室で勉強する学生、ホテルの宿泊客などが挙げられる。これらの人達を総称して「利用者」と呼ぶことがある。
【0014】
前記車両端末は、汎用コンピュータ、パーソナルコンピュータ、専用コンピュータ、ワークステーション、PCS(個人通信システム)、セルラー式(携帯)電話、スマートフォン、RFID受信機、ノートパソコン、タブレット端末、およびその他の任意のプログラム可能なデータ処理装置である。
【0015】
前記ネットワークは特定の通信ネットワークに限定されるものではなく、例えば、移動体通信ネットワークやインターネットを含む任意の通信ネットワークを含んでよい。
【0016】
前記プロセッサは、限定するものではないが、汎用プロセッサでも、特定の処理に特化した専用プロセッサでもよい。前記プロセッサは、マイクロプロセッサ、中央処理装置(CPU)、特定用途向け集積回路(ASIC)、デジタル信号プロセッサ(DSP)、プログラマブル論理装置(PLD)、フィールドプログラマブルゲートアレイ(FPGA)、コントローラ、マイクロコントローラ、およびこれらの任意の組み合せを含む。
【0017】
前記呼吸器疾患症状としては、限定するものではないが、咳、くしゃみ、息切れ、鼻詰り(sniffle)、咳払い等が挙げられる。
【0018】
一実施形態では、前記システムは、前記車両の現在位置を検出するためのGPS(全地球測位システム)受信機などの位置検出部をさらに備えてよい。この場合、前記プロセッサは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方を、前記ネットワークを介して取得するステップを実行するようにさらに構成されており、前記搭乗者の前記呼吸器疾患を評価するステップは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方に基づいても実行されてよい。
【0019】
別の実施形態では、前記プロセッサは、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップを実行するようにさらに構成されてよい。
【0020】
さらなる実施形態では、前記システムは、前記車両内に空気清浄機をさらに備えてよく、前記プロセッサは、前記呼吸器疾患症状の発生頻度に基づいて前記空気清浄機を制御するステップを実行するようにさらに構成されてよい。これに加えて、またはこれに代えて、前記システムは、前記搭乗者の生体情報を取得する生体情報取得部をさらに備えてよく、前記プロセッサは、前記呼吸器疾患症状の発生頻度に基づいて前記生体情報取得部を制御するステップを実行するようにさらに構成されてよい。
【0021】
さらに別の実施形態では、前記プロセッサは、前記感染リスク情報に基づいて、前記車両の次の利用前の消毒手順の必要性を示す車両車室汚染情報を生成するステップと、前記車両車室汚染情報を前記外部利用者端末に前記ネットワークを介して送信するステップと、を実行するようにさらに構成されてよい。この実施形態では、前記外部サーバは、前記共用車両の予約情報および状態情報を記憶するデータベースを備えてよく、前記車両の前記状態情報を変更して前記車両車室汚染情報に反映させてよい。前記消毒手順が必要であることを前記車両車室汚染情報が示し、前記車両が予約されていることを前記予約情報が示す場合、前記外部サーバは、利用可能な他の車両を探し、前記利用可能な車両を前記予約に割り当ててよい。前記車両車室汚染情報は、前記消毒手順の完了後に、前記車両がクリーンであることを示すように更新されてよい。
【0022】
さらに別の実施形態では、前記外部サーバは、感染リスクが高いと判定された前記車両と類似の利用履歴を有する汚染の可能性のある車両を探し、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更してよい。
【0023】
本開示の別の態様は、
車両の車室内の音響事象を検出するステップと、
前記検出した音響事象から、前記車両内の搭乗者の呼吸器疾患症状を抽出するステップと、
前記搭乗者の前記呼吸器疾患症状を評価して、前記車両に搭乗する予定の次の搭乗者の感染リスクに関連する感染リスク情報を生成するステップと、
前記感染リスク情報を、外部利用者端末、前記外部サーバまたは第三者に前記ネットワークを介して送信するステップと、を含む、共用車両の管理方法である。
【0024】
前記方法は、
前記車両の現在位置を検出するステップと、
前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方を、前記ネットワークを介して取得するステップと、をさらに含んでよい。この場合、前記搭乗者の前記呼吸器疾患を評価するステップは、前記車両の周辺の環境情報および近隣の車両からの感染リスク情報の少なくとも一方に基づいても実行されてよい。
【0025】
前記方法は、
通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップ、前記呼吸器疾患症状の発生頻度に基づいて、前記車両内の空気清浄機を制御するステップ、および/または前記呼吸器疾患症状の発生頻度に基づいて、前記搭乗者の生体情報を取得するステップをさらに含んでよい。
【0026】
別の実施形態では、前記方法は、前記感染リスク情報に基づいて、前記車両の次の利用前の消毒手順の必要性を示す車両車室汚染情報を生成するステップと、前記車両車室汚染情報を前記外部利用者端末に前記ネットワークを介して送信するステップと、をさらに含んでよい。さらに、前記方法は、前記共用車両の予約情報および状態情報を記憶するデータベースにアクセスするステップと、前記車両の前記状態情報を変更して前記車両車室汚染情報に反映させるステップと、をさらに含んでよい。さらに、前記方法は、前記消毒手順が必要であることを前記車両車室汚染情報が示し、前記車両が予約されていることを前記予約情報が示す場合、利用可能な他の車両を探し、前記利用可能な車両を前記予約に割り当てるステップをさらに含んでよい。前記方法は、前記消毒手順の完了後に、前記車両がクリーンであることを示すように前記車両車室汚染情報を更新するステップをさらに含んでよい。
【0027】
さらなる実施形態では、感染リスクが高いと判定された前記車両と類似の利用履歴を有する汚染の可能性のある車両を探し、通信頻度および前記外部サーバに送信する情報の少なくとも一方を変更するステップをさらに含んでよい。
【発明の効果】
【0028】
共用車両管理システムおよび共用車両管理方法によれば、車両の1人の搭乗者または複数人の搭乗者の健康状態を遠隔で判断して、これにより次の搭乗者の健康上の安全性を確保することができる。
【0029】
これらの態様および他の態様は、以下の説明および添付の図面からより容易に理解できる。
【0030】
本発明の様々な他の目的、特徴および付随する利点は、添付の図面を参照して考慮すれば理解がより深まり、完全に理解される。図中、複数の図面にわたり同じ参照符号が同一または同様の部分を参照している。
【図面の簡単な説明】
【0031】
【
図1】本開示の一実施形態に係る共用車両管理システムの模式図である。
【
図2】本システムのうち、車両に搭載される部分の模式図である。
【
図3】本システムのうち、車両に搭載される部分を示すブロック図である。
【
図4】本開示の別の実施形態に係る車両端末によって実行されるステップを示すフローチャートである。
【
図5】本開示の別の実施形態に係る車両端末によって実行されるステップを示すフローチャートである。
【
図6】本開示の一実施形態に係る共用車両管理システムで用いられる外部サーバの例を示すブロック図である。
【
図7】本開示の別の実施形態に係る外部サーバによって実行されるステップを示すフローチャートである。
【
図8】データベースに記憶されている状態情報および予約情報の例である。
【
図9】本実施形態に係るシステムで送信される音響データの例を示す図である。
【
図10】本実施形態に係るシステムで送信される広告に関するデータまたは警告に関するデータの例を示す図である。
【
図11】航空機内の座席の危険度を示す画面の例を示す。
【
図12】本実施形態に係る外部サーバに設けられたデータベースに記憶されている状態情報および予約情報の例を示す図である。
【
図13】本実施形態に係るシステムにおける感染リスクの高い車両に対する処理の例を示す図である。
【
図14】本実施形態に係るシステムにおける感染リスクの高い航空機に対する処理の例を示す図である。
【発明を実施するための形態】
【0032】
以下、添付の図面を参照して実施形態について説明する。
図1は、本開示の一実施形態に係る共用車両管理システムの模式図であり、
図2は、本システムのうち、車両に搭載される部分の模式図である。
【0033】
システム10は共用車両20を管理するために設計されている。各車両20は、車両20の車室24内の音響事象を検出するための音響センサを含む音響事象検出部22を備える。音響センサは、マイクロフォンなど、音声信号(音波など)を、検出した信号に比例する電圧または電流に変換するセンサであれば、どのようなタイプのものでもよい。音響センサは、超音波範囲の音圧波を検出する静電センサまたは圧電センサ(例えば、高周波超音波センサ)を含んでもよい。音響センサは、例えば、車室24のサイズ、容積、設計などに応じて、複数個用いられてもよい。音響センサは、システム10専用のものでもよいが、ナビゲーションシステム、通信システム、オーディオシステムなど、他のシステムに設けられたマイクロフォンを用いてもよい。音響センサは、音響事象検出部22に有線または無線で接続されてもよい。また、ブルートゥース(登録商標)などの無線接続を経由することで、携帯電話が音響センサとして機能してもよい。
【0034】
また、車両端末30が車両20に設けられ、音響事象検出部22と電気的に接続されている。データセンタなどの遠隔地に設置された外部サーバ50が、ネットワーク12を介して、車両端末30および外部利用者端末60と通信している。
【0035】
また、システム10は、音響事象検出部22が検出した音響事象を処理して分析するためのプロセッサ32を有する。プロセッサ32は、車両端末30に設けられても、外部サーバ50に設けられても、これらの両方に設けられてもよい。
図2に示す実施形態では、プロセッサ32は車両端末30に設けられている。また、車両20は、後述する生体情報取得部26、空気清浄機28、および位置検出部34を備える。車両20の内部および/または外部の空気の質、温度、湿度等を測定するために1以上のセンサ(図示せず)が設けられてもよい。
【0036】
図3は、共用車両管理システム10のうち、車両20に搭載される部分を示すブロック図である。音響事象検出部22は、音響音を捕捉する音響センサとしてのマイクロフォン36を備え、車室24内の搭乗者Pが発する音響事象を検出する。マイクロフォン36は、音響事象検出部22自体に内蔵されていてもよいし、独立型として有線または無線で音響事象検出部22に結合されてもよい。いずれの場合も、音響事象検出部22は、捕捉した音響音をマイクロフォン36から電気信号として受け取り、その電気信号に対し、例えばアナログ/デジタル変換を行って音響データを生成するなどの処理を行う。
【0037】
車両端末30は、音響事象検出部22、生体情報取得部26、空気清浄機28、位置検出部(GPS部)34など、車両20に搭載された他の部分とI/O(入出力)部38を介して通信している。また、車両端末30は、ネットワークインタフェース40を介して外部サーバ50とも通信している。ネットワークインタフェース40は、第4世代(4G)や第5世代(5G)などの移動体通信規格に対応した通信モジュールを含んでよい。通信ネットワークは、アドホックネットワーク、ローカルエリアネットワーク(LAN)、メトロポリタンエリアネットワーク(MAN)、無線パーソナルエリアネットワーク(WPAN)、公衆交換電話網(PSTN)、地上無線ネットワーク、光ネットワーク、またはこれらの任意の組み合わせであってよい。また、車両端末30は、例えば、主記憶装置、補助記憶装置、またはキャッシュメモリとして機能することができる記憶部42を含む。記憶部42は、車両端末30の動作に用いられる任意の情報を記憶する。例えば、記憶部42には、システムプログラム、アプリケーションプログラム、他の部分からのデータ、外部サーバ50に送信するデータ、外部サーバ50から取得したデータなどが記憶されてよい。記憶部42に記憶されている情報は、例えば、ネットワークインタフェース40によって外部サーバ50から取得した情報により更新可能であってよい。記憶部42は、例えば、半導体メモリ、磁気メモリ、または光メモリであってよい。記憶部42は、特に限定するものではないが、長期記憶型メモリ、短期記憶型メモリ、揮発性メモリ、不揮発性メモリ、その他のメモリであってよい。さらに、記憶部42として機能するメモリモジュールの数や、情報を記憶する媒体の種類は限定されない。プロセッサ32、I/O部38、ネットワークインタフェース40および記憶部42は、バス44を介して電気的に相互接続されている。
【0038】
次に、
図4を参照して、共用車両管理システム10の動作について説明する。
【0039】
ステップS10において、音響事象検出部22のマイクロフォン36が、車室24内の搭乗者Pが発する音を含む環境音を捕捉し、この音を音響データに変換する。次に、音響データが車両端末30のI/O(入出力)部38に転送される。
【0040】
プロセッサ32は、ステップS20において、音響データから搭乗者Pの呼吸器疾患症状を抽出する。例えば、フィルタリングやその他のタイプの周波数および/または振幅分析を使用して、捕捉した音響データの独自の特徴を特定したり、あるいは、音響データから無関係な(例えば、背景)ノイズ成分を削除したりしてよい。プロセッサ32はさらに、例えば、特徴の属性を、記憶部42に記憶されている参照テーブル、データベース、または他のデータ編成構造と比較することによって独自の特徴を処理し、それにより呼吸器疾患症状を特定する。呼吸器疾患症状としては、例えば、咳、くしゃみ、喘鳴、鼻詰り、咳払い、鼻声、浅い呼吸、深い呼吸などを挙げることができる。呼吸器疾患症状の抽出に用いるモデルまたはアルゴリズムは、抽出の精度を上げるために、搭乗者の年齢、性別、人種、既往歴などの個人的な特徴によって変更されてよい。モデルまたはアルゴリズムが機械学習を用いて構築および改良されてよい。あるいは、モデルまたはアルゴリズムが、ネットワークを介して更新されてもよい。
【0041】
ステップS20において、プロセッサ32は、利用者の咳の音などの音響データから搭乗者の呼吸器疾患の症状を検出すると、該音響データを、外部の宛先に送信してよい。例えば、
図9に示すように、プロセッサ32は、利用者の承諾を得られた場合、利用者の掛かり付けの医療機関の医師に対して、利用者の咳の音を送信してよい。例えば、
図9に示すように、プロセッサ32は、利用者の承諾を得られた場合、SNS(ソーシャルネットワーキングサービス)に、利用者の咳の音をアップロードしてよい。
【0042】
具体的には、プロセッサ32は、
図9に示すように、配信リストに基づいて、音響データを外部サーバに送信してよい。また、プロセッサ32は、配信リストに基づいて、外部サーバおよびインターネットを介して、音響データを第三者に送信してよい。第三者の例としては特に限定するものではないが、SNS、利用者の掛かり付けの医療機関の医師、利用者の家族などが挙げられる。また、プロセッサ32は、配信リストに基づいて、外部サーバを介して、外部利用者端末に音響データを送信してよい。
【0043】
外部サーバまたは外部利用者端末は、例えば、外部サーバまたは外部利用者端末に搭載されている記憶部等に配信リストを記憶してよい。配信リストには、第三者の電子メールアドレスや第三者のURLなど、受取先を指定する情報が含まれる。なお、記憶部は、必ずしも外部サーバや外部利用者端末の内部に設けられている必要はなく、外部サーバや外部利用者端末の外部に設けられるように構成されてもよい。
【0044】
次に、ステップS30において、プロセッサ32は、呼吸器疾患症状を評価する。例えば、咳および/またはくしゃみの強さ、頻度および持続時間を記憶部42に記憶されている参照テーブルと比較して、症状の重症度が判定されてよい。呼吸器疾患症状の評価に用いるモデルまたはアルゴリズムは、評価の精度を上げるために、搭乗者の年齢、性別、人種、既往歴などの個人的な特徴によって変更されてよい。モデルまたはアルゴリズムが機械学習を用いて構築および改良されてよい。あるいは、モデルまたはアルゴリズムが、ネットワークを介して更新されてもよい。
【0045】
ステップS40において、プロセッサ32は、症状の重症度と、任意選択で車両の他の条件とに基づいて、感染リスク情報を生成する。例えば、搭乗者の人数、車室のサイズ、車室内の空気の質、湿度および温度などが計測されてよい。
【0046】
ステップS40において、プロセッサ32は、利用者の呼吸器疾患の症状に加えて、空間の換気状況に基づいて、利用者の感染リスク情報を生成してもよい。空間の換気状況を示す情報としては、例えば、エアコンがオンまたはオフであることを示す情報、エアコンの強弱を示す情報、エアコンの風量を示す情報、エアコンの運転モード(例えば、冷房、暖房、除湿、エコ)を示す情報、外気の取り入れの有無を示す情報、空間に設けられる窓の開閉状態を示す情報、空間の内部における気流の状態を示す情報、空間に存在する気体(例えば、二酸化炭素)の濃度を示す情報などが挙げられる。
【0047】
例えば、プロセッサ32は、二酸化炭素の濃度が高い場合、利用者の感染リスクが高いという利用者の感染リスク情報を生成してよい。例えば、プロセッサ32は、二酸化炭素の濃度が低い場合、利用者の感染リスクが低いという利用者の感染リスク情報を生成してよい。
【0048】
プロセッサ32は、ステップS50において、ネットワークインタフェース40を介して、感染リスク情報をネットワーク経由で外部サーバ50に送信する。その他、車両ID、有症状者の人数、有症状者の車室内での位置(例えば、助手席、運転席等)などの情報が外部サーバ50に送信されてもよい。外部サーバ50は、情報の全部または一部を外部利用者端末60に転送する。外部利用者端末60は、例えば、車両20が返却される予定のサービス提供業者の支店などに配置されてよい。外部サーバ50には、複数の外部利用者端末60が接続されている。また、外部サーバ50は、情報の全部または一部を第三者に転送してよい。車両端末30または外部サーバ50は、配信リストに基づいて、第三者に情報を転送してよい。「第三者」の例としては、限定するものではないが、病院、車両20の目的地の端末、表示部の制御装置、スピーカーの制御装置などが挙げられる。
【0049】
図5は、別の実施形態に係る車両端末によって実行されるステップを示すフローチャートである。
【0050】
ステップS110において、音響事象検出部22が環境音を捕捉し、この音が音響データに変換された後、I/O部38に転送される。プロセッサ32は、ステップS120において、音響データから搭乗者Pの呼吸器疾患症状を抽出する。これらのステップは、上記のステップS10、S20と同様に実施されてよい。
【0051】
ステップS120において、プロセッサ32は、利用者の咳の音などの音響データから搭乗者の呼吸器疾患の症状を検出すると、該音響データを、外部の宛先に送信してよい。例えば、
図9に示すように、プロセッサ32は、利用者の承諾を得られた場合、利用者の掛かり付けの医療機関の医師に対して、利用者の咳の音を送信してよい。例えば、
図9に示すように、プロセッサ32は、利用者の承諾を得られた場合、SNS(ソーシャルネットワーキングサービス)に、利用者の咳の音をアップロードしてよい。
【0052】
次に、ステップS122において、プロセッサ32は、GPS部34から車両20の現在位置を取得する。なお、GPS部34は、共用車両管理システム10専用のものでもよいが、ナビゲーションシステムなど他のシステム用に設けられたGPS部も使用可能である。また、携帯電話またはスマートフォンに内蔵されたGPS部が、ブルートゥースなどの無線接続を経由することでGPS部34として機能してもよい。
【0053】
ステップS124において、プロセッサ32は、車両20の現在位置を含む問い合わせを生成し、ネットワークインタフェース40を介して、問い合わせを外部サーバ50またはインターネット上の他のサーバに転送する。これに対し、サーバから、車両20の周辺の環境情報が返送される。環境情報には、天候、気温、湿度、気圧、風速、花粉数、大気質指数(AQI)、粒子状物質(PM)2.5や、呼吸器疾患を引き起こす可能性のある既知の原因に関連するその他の任意の情報が含まれてよい。環境情報に加えて、または環境情報に代えて、外部サーバ50は、同じ地域を現在走行している車両または最近走行した車両(近隣の車両)を探し、近隣の車両から得られた感染リスク情報があれば、プロセッサ32に返送する。
【0054】
プロセッサ32は、ステップS130において、呼吸器疾患症状を評価する。本実施形態では、ネットワークを介して取得した情報(すなわち、車両20の周辺の環境情報および/または近隣の車両からの感染リスク情報)も呼吸器疾患症状の評価に採用される。例えば、花粉数が多いおよび/またはAQIが高い場合、花粉または大気汚染によるくしゃみ(すなわち、呼吸器疾患とは無関係なくしゃみ)である可能性が高いため、プロセッサ32は、くしゃみの頻度のリスク閾値を上げる。また、外部サーバ50は、該外部サーバ50の管理下にある車両から得て蓄積した情報に基づいて、その地域における一人当たりのくしゃみの平均頻度を算出し、プロセッサ32に返送してもよい。プロセッサ32は、測定した搭乗者Pのくしゃみの頻度からくしゃみの平均頻度を引き、その差を評価に用いてもよい。
【0055】
ステップS140において、プロセッサ32は、症状の重症度に基づいて感染リスク情報を生成する。これに加えて、またはこれに代えて、車両車室24の汚染情報が生成されてもよい。車両20の車室24内のエアロゾルの濃度(すなわち、汚染度)は、呼吸器疾患症状の頻度だけでなく、車両20の車室24のサイズや容積、さらには症状の持続時間によっても変わる。このため、車両車室汚染情報は、これらの要素も考慮して求める必要がある。すなわち、感染リスク情報は、次に搭乗する予定の搭乗者が感染する可能性(リスク)を示すのに対し、車両車室汚染情報は、車両返却後、車両の次の利用前の消毒手順の必要性を示す。
【0056】
車室の汚染の可能性が上昇している場合、プロセッサ32は、ステップS142において、改善行動として空気清浄機28を(起動していない場合には)起動するか、または(起動している場合には)パワーアップしてよい。空気清浄機28は、花粉やPM2.5を含む粒子および微生物を除去して空気を浄化するフィルタ装置と、微生物を殺菌または不活化する紫外線ランプやオゾン発生装置などの殺菌装置の少なくとも一方を備えてよい。また、プロセッサ32は、搭乗者の追加の情報を収集し、次の搭乗者の感染リスクを正確に判定するために、生体情報取得部26を起動してよい。生体情報によって収集される追加の情報としては、例えば、心拍数(HR)、呼吸数(RR)、血圧(BP)、体温(BT)、酸素飽和度(SpO2)などを挙げることができる。
【0057】
ステップS142において、プロセッサ32は、上述した空間の換気状況を制御してよい。例えば、プロセッサ32は、エアコンをオンまたはオフにしてよい。例えば、プロセッサ32は、エアコンの強弱を制御してよい。例えば、プロセッサ32は、エアコンの風量を制御してよい。例えば、プロセッサ32は、エアコンの運転モードを制御してよい。例えば、プロセッサ32は、外気の取り入れ有無を切り替えてよい。例えば、プロセッサ32は、空間に設けられる窓の開閉を制御してよい。
【0058】
ステップS142において、プロセッサ32は、利用者の感染リスク情報に基づいて、利用者(例えば、タクシーの乗客)に対して、特定の製品の販売を促進させるような広告を配信してよい。広告は、
図10に示すように、表示部、スピーカー、またはSNSにより配信されてよい。プロセッサ32は、例えば、空間の管理者(例えば、電車内でホットタオルを配ったり軽食を販売したりする鉄道パーサーや、航空機の機内で乗客に各種サービスを提供する客室乗務員(CA))に対し、利用者(例えば、電車の乗客や航空機の乗客)の感染リスク情報に基づき特定の製品の利用を促す警告を表示部に表示させてよい。表示部は特に限定されず、例えば液晶ディスプレイや有機エレクトロルミネセンス(EL)ディスプレイなどであってよい。
【0059】
例えば、タクシーに搭載されるディスプレイに、「風邪薬はいかがでしょうか?」、「マスクをご購入されませんか?」のように、タクシーの乗客に対して、風邪薬またはマスクの販売を促進させるような広告が表示されてよい。例えば、電車または航空機に搭載されるディスプレイに、「咳込んでいる人がいます。咳込んでいる人の周りの乗客にマスクを配ってください。」のように、鉄道パーサーまたはCAに対して、電車内の咳込んでいる利用者または航空機内の咳込んでいる利用者へマスクの着用を促進させるような警告が表示されてよい。
【0060】
具体的には、
図10に示すように、プロセッサ32は、特定の製品の購入を利用者に促す広告に関連する情報、および特定の製品の着用を利用者に促す警告に関連する情報を、外部サーバに送信してよい。また、プロセッサ32は、特定の製品の購入を利用者に促す広告に関連する情報、および特定の製品の着用を利用者に促す警告に関連する情報を、外部サーバおよびインターネットを介して携帯電話に送信してよい。また、プロセッサ32は、特定の製品の購入を利用者に促す広告に関連する情報、および特定の製品の着用を利用者に促す警告に関連する情報を、外部サーバおよび制御装置を介して出力インタフェースに送信してよい。例えば、出力インタフェースが表示部である場合、表示部は制御装置によって制御され、これらの情報を表示する。例えば、出力インタフェースがスピーカーである場合、スピーカーは制御装置によって制御され、これらの情報を音声として出力する。制御装置は、出力インタフェースを制御できるものであれば、その構成は特に限定されない。制御装置は、例えば、PCやスマートフォンなどに搭載されたCPU(中央処理装置)であってよい。
【0061】
あるいは、特定の製品の購入を利用者に促す広告に関連する情報、特定の製品の着用を利用者に促す警告に関連する情報などが、広告主や管理者等によって外部サーバに登録されてもよい。例えば、広告主が、特定の製品の購入を利用者に促す広告に関連する情報を外部サーバに保存してよい。例えば、管理者が、特定の製品の着用を利用者に促す警告に関連する情報を外部サーバに記憶してよい。外部サーバは、これらの情報をプロセッサ32に送信し、プロセッサ32は、外部サーバから受信したこれらの情報を記憶することができる。
【0062】
ステップS144において、プロセッサ32と外部サーバ50との間の通信頻度や、外部サーバ50に送信する情報の種類が変更されてよい。例えば、通常の状態では、車両端末30および外部サーバ50の通信および/または負荷に関連するコストを削減するために、通信頻度は低く設定されている。搭乗者Pの感染リスクが高い場合は、搭乗者の健康状態をより頻繁に把握できるよう通信頻度が高く設定される。これに加えて、またはこれに代えて、搭乗者の健康状態をより正確に評価できるよう、生体情報取得部26が収集した追加の情報が、外部サーバ50に送信する情報に組み込まれてもよい。
【0063】
ステップS144において、プロセッサ32は、管理者の行為に応じて、プロセッサ32と外部サーバ50との通信頻度を制御してよい。管理者の行為としては、例えば、管理者が所定の回数ボタンを押す、管理者が所定のパターンで咳をする、管理者が所定のリズムで音声データを出力するなどが挙げられる。所定の回数、所定のパターン、所定のリズムなどは、あらかじめ設定され、記憶部に記憶されていてよい。音声データは、音響事象であってもよいし、新たに生成された音声データであってもよい。
【0064】
例えば、挙動不審で怪しい動きをしている乗客がタクシーに乗車してきた場合、タクシードライバーが3回ハンドルを叩くと、プロセッサ32は、プロセッサ32と外部サーバ50との通信頻度を高くしてよい。これにより、タクシードライバーは、挙動不審で怪しい動きをしている乗客に知られることなく、外部に危険を知らせ、外部からの助けを得ることが可能となる。
【0065】
次に、プロセッサ32は、ステップS150において、ネットワークインタフェース40を介して、感染リスク情報および/または車両車室汚染情報をネットワーク経由で外部サーバ50に送信する。外部サーバ50は、情報の全部または一部を外部利用者端末60に転送する。
【0066】
外部サーバ50は、プロセッサ32から受信した情報を様々な方法で利用してよい。例えば、外部サーバ50は、車両からのデータを経時的に蓄積し、呼吸器疾患および/またはアレルギーの発生の手掛かりを監視してよい。また、外部サーバ50は、複数の車両からの感染リスク情報を地図上に可視化し、ネットワークを介して、地図をドライバーに提供したり、感染リスクが高いと考えられるエリア内を走行している車両または該エリアに向かって走行する車両に対して警告を送ったりしてよい。この情報および地図が、他のサービス提供業者やCDCなどの政府機関に提供されてよい。
【0067】
ステップS150において、本発明に係るシステムおよび方法が、共用車両の管理に適用される場合、プロセッサ32は、利用者の感染リスク情報、および目的地にいる人達にとっての対策情報を送信して、目的地にいる人達に通知してもよい。
【0068】
例えば、タクシーまたはバスの目的地がアミューズメントパークである場合、プロセッサ32は、アミューズメントパークの来園者に対して、「これから、感染リスクの高い人が、ここに到着しますよ。マスクを全員着用してください。」という通知をしてもよい。例えば、救急車の目的地が病院である場合、プロセッサ32は、病院にいる医師達および看護師達に対して、「これから、感染リスクの高い患者が、ここに到着しますよ。注意して治療してください。」という通知をしてもよい。
【0069】
ステップS150において、プロセッサ32は、利用者、および利用者の周囲にいる利用者以外の人達に通知するために、利用者の感染リスク情報を外部サーバ、外部利用者端末または第三者に送信してもよい。例えば、プロセッサ32は、所定の利用者の感染リスクが高い旨または所定の利用者の感染リスクが低い旨を、表示部に表示させてよい。例えば、プロセッサ32は、所定の利用者の感染リスクが高い旨または所定の利用者の感染リスクが低い旨を、音声出力インタフェースに出力させてよい。これにより、利用者の周囲にいる利用者以外の人達を安心させることができ、且つ、利用者の周囲にいる利用者以外の人達の警戒意識を促進させることができる。
【0070】
例えば、プロセッサ32は、電車に乗っている乗客全員に対して、感染リスクの高い乗客の感染リスク情報を通知するために、電車に搭載されるディスプレイに、「3号車の車両には、感染リスクの高い乗客がいます。したがって、3号車の車両は、感染リスクが高くなっています。」という画面を表示させてもよい。例えば、プロセッサ32は、学校で勉強している生徒全員に対して、感染リスクの高い生徒の感染リスク情報を通知するために、校内のスピーカーから、「2組の教室には、感染リスクの高い生徒がいます。したがって、2組の教室は、感染リスクが高くなっています。」という音声を出力させてもよい。
【0071】
ステップS150において、プロセッサ32は、利用者の感染リスク情報に基づいて、空間を管理する管理者(例えば、タクシードライバー、空間を運営する機関の担当者)に対して、空間の換気状況を改善する旨を通知してよい。
【0072】
例えば、プロセッサ32は、タクシーの乗客の感染リスクが低いにも拘らず、タクシーの搭乗者の呼吸器疾患の症状を高頻度で検出した場合、タクシーの内部の環境が悪化していると予測し、タクシードライバーに、「タクシーの内部が埃っぽいので、直ちに、タクシーの内部の換気状況を改善してください。」という旨を通知してよい。
【0073】
例えば、プロセッサ32は、病院の待合室で待つ患者の感染リスクが低いにも拘らず、病院の待合室で待つ患者の呼吸器疾患の症状を高頻度で検出した場合、病院の待合室の内部の環境が悪化していると予測し、病院を運営する機関の担当者に、「病院の待合室の内部に外気を取り込んで、換気状況を改善してください。」という旨を通知してよい。
【0074】
これにより、管理者は、利用者の感染リスクが実際に高いのか否か、あるいは、空間の内部の環境が悪いため、利用者に呼吸器疾患の症状が現れているのか否か、を容易に判断することが可能となる。
【0075】
ステップS150において、プロセッサ32は、体調に関する利用者の報告(例えば、体調に関する質問に対する利用者の回答)、および利用者の感染リスク情報に基づいて、利用者の評価を行ってよい。
【0076】
例えば、乗車前の問診により、乗客が「咳およびくしゃみが続いていません。」と回答したにも拘らず、プロセッサ32が当該搭乗者の呼吸器疾患の症状を高頻度で検出した場合(すなわち、プロセッサ32が当該乗客の感染リスクが高いことを検出した場合)、プロセッサ32は、当該乗客が嘘をついていると判定し、当該乗客を低く評価してよい。
【0077】
例えば、乗車前の問診により、乗客が「咳およびくしゃみが続いていません。」と回答し、プロセッサ32が当該搭乗者の呼吸器疾患の症状を低頻度で検出した場合(すなわち、プロセッサ32が当該乗客の感染リスクが低いことを検出した場合)、プロセッサ32は、当該乗客が正直に答えていると判定し、当該乗客を高く評価してよい。
【0078】
正直に答えている利用者が高評価とされ、嘘をついている利用者が低評価とされることで、高評価を得ようとする利用者の意志を促進させることができるため、管理者に正直に回答しようとする利用者の数を増やすことができる。これにより、管理者は確かな情報に基づいて、利用者に適切な処置を施すことが可能となる。
【0079】
ステップS150において、プロセッサ32は、「空間」が、特に、広い空間である場合、広い空間の内部において、どの箇所の感染リスクが高いか、または、どの箇所の感染リスクが低いかを、利用者に通知してよい。広い空間としては、例えば、航空機、学校、バス、マンション、ホテルなどが挙げられる。
【0080】
例えば、プロセッサ32は、航空機の内部において、ファーストクラスの座席の感染リスクが高く、通常クラスの座席の感染リスクが低い、という旨を利用者に通知してよい。例えば、プロセッサ32は、ホテルの内部に設けられる複数のトイレにおいて、右から3番目のトイレの感染リスクが高く、その他のトイレの感染リスクが低い、という旨をディスプレイを用いた画像により利用者に通知してよい。また、プロセッサ32は、
図11に示すように、どの座席の感染リスクが高いかを利用者に通知してよい。
【0081】
プロセッサ32は、例えば、「空間」の危険度を示す画面をディスプレイに表示させてよい。具体的には、プロセッサ32は、
図11に示すように、航空機内の座席の危険度を示す画面を、航空機に搭載されたPCのディスプレイに表示させてもよい。航空機内の座席の危険度が、形態の変化で表現されてよい。例えば、航空機内の座席の危険度が色の変化で表現されてよい。
【0082】
図11は、航空機内の座席の危険度を示す画面の例であるが、「空間」の危険度を示す画面はこの例に限定されない。「空間」の危険度を示す画面は、船舶内の座席の危険度を示す画面、待合室内の座席の危険度を示す画面など、どのようなタイプの施設の危険度を示す画面でもよい。
【0083】
航空機内の座席の危険度を示す画面において、例えば、
図11に示すように、座席4Fおよび座席4Gに斜めストライプのパターンが表示されており、航空機内の座席のうち座席4Fおよび座席4Gが危険度が「高」の座席であることを示す。航空機内の座席の危険度を示す画面において、例えば、座席3D、座席3E、座席3F、座席3G、座席3H、座席3I、座席4D、座席4E、座席4H、座席4I、座席5D、座席5E、座席5F、座席5G、座席5H、および座席5Iにドットのパターンが表示されており、座席3D、座席3E、座席3F、座席3G、座席3H、座席3I、座席4D、座席4E、座席4H、座席4I、座席5D、座席5E、座席5F、座席5G、座席5H、および座席5Iが航空機内の座席のうち危険度が「中」の座席であることを示す。航空機内の座席の危険度を示す画面において、例えば、上記の座席以外の座席がパターンなしで表示されており、上記の座席以外の座席が航空機内の座席のうち危険度が「低」の座席であることを示す。危険度は、その座席を使用すると予想される次の利用者の感染の可能性(リスク)と関連付けて定義されてよい。例えば、1%未満が「低」、1%以上20%未満が「中」、20%以上が「高」と定義されてよい。また、危険度が、座席の次の利用前の消毒の必要性と関連して定義されてもよい。
【0084】
このように、航空機内の座席の危険度を示す画面を表示部に表示させることで、管理者(航空機内で搭乗者に各種サービスを提供するCAなど)は、感染リスクの高い座席と感染リスクの低い座席とを瞬時に判別することができる。
【0085】
また、航空機内の座席の危険度が色の変化で表現されてよい。航空機内の座席の危険度を示す画面において、例えば、座席4Fおよび座席4Gを赤色で表示して、航空機内の座席のうち座席4Fおよび座席4Gが危険度が「高」の座席であることを示してよい。航空機内の座席の危険度を示す画面において、例えば、座席3D、座席3E、座席3F、座席3G、座席3H、座席3I、座席4D、座席4E、座席4H、座席4I、座席5D、座席5E、座席5F、座席5G、座席5H、および座席5Iを黄色で表示して、座席3D、座席3E、座席3F、座席3G、座席3H、座席3I、座席4D、座席4E、座席4H、座席4I、座席5D、座席5E、座席5F、座席5G、座席5H、および座席5Iが航空機内の座席のうち危険度が「中」の座席であることを示してよい。航空機内の座席の危険度を示す画面において、例えば、上記の座席以外の座席を青色で表示して、上記の座席以外の座席が航空機内の座席のうち危険度が「低」の座席であることを示してよい。
【0086】
図6に示す一実施形態では、外部サーバ50は、情報を活用して、車両群全体のスケジュール管理を行う。外部サーバ50は、プロセッサ52、データベース54およびネットワークインタフェース56を備え、これらがバス58を介して相互に接続されている。データベース54は、システム10が管理する共用車両の予約情報および状態情報を記憶する。
【0087】
次に、
図7および
図8を参照して、車両群のスケジュールを管理する手順を説明する。
図7は、外部サーバが実行するステップを示すフローチャートであり、
図8は、データベース54が記憶している状態情報および予約情報を含む車両群スケジュールの例である。本実施形態では、外部サーバ50は、車両A、車両B、および車両Cのスケジュールを管理している。
【0088】
プロセッサ52は、ネットワークインタフェース56を介して、ネットワーク経由で車両端末30から車両車室汚染情報を受信する(S210)。車両車室汚染情報の内容に応じて、プロセッサ52は、車両20の状態情報を変更して、データベース54に記憶されている車両車室汚染情報に反映させる(S220)。例えば、車両Aからの車両車室汚染情報が消毒手順が必要であることを示す場合、プロセッサ52は、車両Aの状態情報を「使用中」から「利用不可」に変更し、車両Aに予約が割り当てられないようにする。次に、プロセッサ52は、車両Aの予約情報を参照する。この例では、正午から午後3時の間の時間帯に既に予約が存在する。車両Aは次の利用までに消毒が必要であり、消毒の手続きが完了するまで利用不可であるため、この予約を変更しなければならない。このため、プロセッサ52は、車両群スケジュールからこの時間帯に利用可能な車両を探す。この時間帯に車両Bが利用可能であるため、プロセッサ52は、車両Bに予約を再割り当てし、予約情報を車両Aから車両Bに移動させる(S230)。あるいは、プロセッサ52は、別の時間帯(例えば、午後3時から午後6時の間)に予約を再スケジュールして消毒手順を完了するのに十分な時間を確保する。消毒手順の完了報告を受けると、プロセッサ52は、車両がクリーンであることを示すために車両車室汚染情報を「利用不可」から「利用可」に更新する。
【0089】
任意選択で、外部サーバ50は、車両20と類似する利用履歴を有する車両を探してよい(S240)。類似の利用履歴を有する車両が見つかり、その車両の感染リスクが高い場合、外部サーバ50は、感染リスクの現在の状態に関わらず、プロセッサ32にコマンドを送信し、通信頻度および/または外部サーバ50に送信する情報を変更してもよい(S250)。
【0090】
任意選択で、外部サーバ50は、外部利用者端末60に通知を送信してもよい。この通知には、例えば、消毒手順の指示および予約の更新が含まれてよい。また、外部サーバ50は、このような通知を、電子メールまたはテキストメッセージを通じて消毒サービスの業者または予約済みの顧客に送信してよい。
【0091】
外部サーバは、上記のような車両群スケジュールだけでなく、施設スケジュールを記憶してもよい。
図12は、データベース54が記憶している状態情報および予約情報の例を示す図である。
図12では、この施設は、部屋A、部屋B、部屋Cの3つの部屋を有する。午前9時から正午、正午から午後3時、午後3時から午後6時など、3つの時間帯が図示されている。
【0092】
プロセッサ52は、ネットワークインタフェース56を介して、部屋Aの汚染情報、部屋Bの汚染情報、および部屋Cの汚染情報を受信する。プロセッサ52は、部屋Aの汚染情報、部屋Bの汚染情報、および部屋Cの汚染情報に基づいて、部屋Aの状態情報、部屋Bの状態情報、および部屋Cの状態情報を変更する。
【0093】
例えば、午前9時から正午の間の部屋Aの汚染情報として消毒手順が必要であることを示す情報を受信すると、プロセッサ52は、部屋Aの状態情報を「使用中」から「利用不可」に変更する。例えば、午前9時から正午の間の部屋Bの汚染情報として消毒手順が不要であることを示す情報を受信すると、プロセッサ52は、部屋Bの状態情報を変更せずに「使用中」のままとする。例えば、午前9時から正午の間の部屋Cの汚染情報として消毒手順が不要であることを示す情報を受信すると、プロセッサ52は、部屋Bの状態情報を変更せずに「利用可」のままとする。
【0094】
次に、プロセッサ52は、部屋Aの汚染情報、部屋Bの汚染情報、部屋Cの汚染情報に加えて、施設スケジュールに基づき、同時間帯に利用可能な別の部屋の予約情報、および同部屋が利用可能となる別の時間帯の予約情報を検索する。次に、プロセッサ52は、これらの予約情報に基づいて、部屋Aの予約情報、部屋Bの予約情報、または部屋Cの予約情報を変更する。
【0095】
例えば、プロセッサ52は、正午から午後3時の間、部屋Aは利用不可であり、部屋Bは利用可能であり、部屋Cは利用不可であると判定した場合、「部屋Aが正午から午後3時の間予約済みである」ことを示す部屋Aの予約情報を、「部屋Bが正午から午後3時の間予約済みである」ことを示す部屋Bの予約情報に変更する。例えば、プロセッサ52は、午後3時から午後6時の間、部屋Aは利用可能であり、部屋Bは利用可能あり、部屋Cは利用不可であると判定した場合、「部屋Aが正午から午後3時の間予約済みである」ことを示す部屋Aの予約情報を、「部屋Aが午後3時から午後6時の間予約済みである」ことを示す部屋Aの予約情報に変更する。また、プロセッサ52は、午後3時から午後6時の間、部屋Aは利用可能であり、部屋Bは利用可能であり、部屋Cは利用不可であると判定した場合、「部屋Aが正午から午後3時の間予約済みである」ことを示す部屋Aの予約情報を、「部屋Bが午後3時から午後6時の間予約済みである」ことを示す部屋Bの予約情報に変更することができる。
【0096】
このように、プロセッサ52が、部屋Aの汚染情報、部屋Bの汚染情報、部屋Cの汚染情報、および施設スケジュールに関連する情報に基づいて各部屋を適切に管理することにより、利用者は、適切な時間帯に、消毒手順が必要な部屋を使用することなく、消毒手順が不要な部屋のみを使用することができる。これにより、利用者の健康を害することなく、施設の利用者の安全を確保することができる共有施設の管理システム10を実現することができる。
【0097】
図13に示すように、「消毒手順が必要である」車両が、必要に応じて他の車両に変更されてよい。
【0098】
プロセッサ52は、1号車、2号車、および4号車について「消毒手順が不要」であることを示す情報を受信し、3号車について「消毒手順が必要である」であることを示す情報を受信すると、3号車を上記以外の車両(new car)に変更する旨を決定してよい。次に、プロセッサ52は、決定の結果、すなわち、3号車を上記以外の車両に変更する旨を、例えば、先頭車両に搭載されたPCのディスプレイに表示してよい。
【0099】
図14に示すように、「消毒手順が必要な」航空機が、必要に応じて別の航空機に機材変更されてよい。
【0100】
プロセッサ52は、第1の航空機について「消毒手順が必要である」ことを示す情報を受信し、第2の航空機および第3の航空機について「消毒手順が不要である」ことを示す情報を受信すると、第1の航空機を上記以外の航空機(new airplane)に機材変更することを決定し、当該機材変更処理に要する時間が1.5時間であると判定してよい。次に、プロセッサ52は、判定結果、すなわち、第1の航空機を上記以外の航空機に機材変更する旨と、当該機材変更処理に要する処理時間とを、例えば、運航管理センターに設けられたPCのディスプレイに表示させてよい。
【0101】
図14に示すように、「消毒手順が必要である」航空機に対し、必要に応じて消毒が行われてよい。
【0102】
プロセッサ52は、第1の航空機について「消毒手順が必要である」ことを示す情報を受信し、第2の航空機および第3の航空機について「消毒手順が不要である」ことを示す情報を受信すると、第1の航空機に対して消毒を行うことを決定し、当該消毒手順に要する時間を2時間と判定してよい。次に、プロセッサ52は、判定結果、すなわち、第1の航空機に対して消毒を行う旨と、消毒処理に要する処理時間とを、例えば、運行管理センターに設けられたPCのディスプレイに表示させてよい。
【0103】
図14に示すように、「消毒手順が必要である」航空機を、別の空港から回送飛行で到着した別の航空機に変更してよい。
【0104】
プロセッサ52は、第1の航空機について「消毒手順が必要である」ことを示す情報を受信し、第2の航空機および第3の航空機について「消毒手順が不要である」ことを示す情報を受信した場合、第1の航空機を、別の空港から回送飛行で到着する他の航空機を使用する旨を決定し、当該回送飛行処理に要する時間が特定の時間であると判定してよい。例えば、プロセッサ52は、第1の航空機を、回送飛行によって空港Aから到着する別の航空機に変更する旨を決定し、この回送飛行処理に要する時間が3時間であると判定してよい。例えば、プロセッサ52は、第1の航空機を、回送飛行によって空港Bから到着する別の航空機に変更する旨を決定し、当該回送飛行処理に要する時間が4時間であると判定してよい。
【0105】
次に、プロセッサ52は、判定結果、すなわち、第1の航空機を、回送飛行で別の空港から到着する別の航空機に変更する旨と、回送飛行の処理に要する処理時間とを、例えば、運航管理センターに設けられたPCのディスプレイに表示させてよい。例えば、プロセッサ52は、第1の航空機を、空港Aから回送飛行で到着する新しい航空機に変更するための回送飛行処理に要する時間が3時間であることを、表示部に表示させてよい。例えば、プロセッサ52は、第1の航空機を、空港Bから回送飛行で到着する新しい航空機に変更するための回送飛行処理に要する時間が4時間であることを、表示部に表示させてよい。
【0106】
「消毒手順が必要である」航空機に対して行う処理の種類、および「消毒手順が必要である」航空機に対して行うための処理時間は、特に限定されない。処理の種類および処理時間は、コントローラにより予め設定しておいてもよいし、管理者などが自由に設定してもよい。
【0107】
上記の説明および添付の図面に記載した事項は、例示のみを目的として提示したものであり、限定するものではない。特定の実施形態を図示および説明したが、本出願人の貢献のより広い態様から逸脱することなく、変更および修正を行ってもよいことは、当業者にとって明らかであろう。
【0108】
例えば、上記のステップが、一連の操作、または、プログラムを実行可能なコンピュータシステムまたは他のハードウェアによって実行される操作に関するプログラムとして、コンピュータ可読非一時的記憶媒体に記憶されてよい。また、当該操作が、プログラムコードを実装した専用回路、1つ以上のプロセッサで実行される論理ブロックやプログラムモジュール等によって実行されてもよい。さらに、上記の実施形態では、
図4および
図5に図示した全てのステップが、車両端末30のプロセッサ32によって実行されているが、これらのステップの全てまたは一部が、外部サーバ50によって実行されてもよい。
【産業上の利用可能性】
【0109】
本開示では、主にレンタカー/シェアカー施設に関する車両管理システムについて説明したが、本発明の利用は、このようなレンタカー事業に限定されるものではない。本発明は、タクシー車両群の管理、ライドシェア車両の管理、配送トラック車両群の管理、またはその他の車両管理業界にも利用可能である。
【0110】
保護を求める実際の範囲は、先行技術に基づく適切な観点から鑑みて下記の特許請求の範囲に規定されることが意図される。