特開 2023-67726 アルコール検知管理システム、情報処理装置、情報処理装置プログラム

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

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

(11)【公開番号】P2023067726

(43)【公開日】2023-05-16

(54)【発明の名称】アルコール検知管理システム、情報処理装置、情報処理装置プログラム

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20230509BHJP

【ＦＩ】

G06Q50/10

【審査請求】未請求

【請求項の数】16

【出願形態】ＯＬ

(21)【出願番号】P 2022100958

(22)【出願日】2022-06-23

(31)【優先権主張番号】P 2021177254

(32)【優先日】2021-10-29

(33)【優先権主張国・地域又は機関】JP

(71)【出願人】

【識別番号】509215765

【氏名又は名称】株式会社パイ・アール

(74)【代理人】

【識別番号】110000626

【氏名又は名称】弁理士法人英知国際特許商標事務所

(72)【発明者】

【氏名】安田 功

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

5L049

【Ｆターム（参考）】

5L049CC11

(57)【要約】

【課題】アルコール検知センサやアルコール検知システム全体の保守管理を容易にならしめ、また、適正なアルコール検知を実施し、全体の作業の効率化に寄与する技術を提供することを目的とする。
【解決手段】センサカートリッジを交換可能なアルコール検知器と組合せて用いるアルコール検知管理システムであって、情報処理装置と、管理サーバーを備え、情報処理装置は、アルコール検知器及び管理サーバーと通信を行うものであり、センサカートリッジに固有のセンサ識別番号を取得し保持するセンサ識別番号記憶手段と、アルコール検知の検知結果を取得する検知結果取得手段を少なくとも有し、管理サーバーは、情報処理装置からアルコール検知の検知結果を受信し、アルコール検知の検知結果に基づいてセンサカートリッジの交換時期につき及び／又は適正なアルコール検知が実施されているか否かにつき判定することを特徴とするアルコール検知管理システム。
【選択図】図１

【特許請求の範囲】

【請求項1】

センサカートリッジを交換可能なアルコール検知器と組合せて用いるアルコール検知管理システムであって、
情報処理装置と、管理サーバーを備え、
情報処理装置は、アルコール検知器及び管理サーバーと通信を行うものであり、センサカートリッジに固有のセンサ識別番号を取得し保持するセンサ識別番号記憶手段と、アルコール検知の検知結果を取得する検知結果取得手段を少なくとも有し、
管理サーバーは、情報処理装置からアルコール検知の検知結果を受信し、アルコール検知の検知結果に基づいてセンサカートリッジの交換時期につき及び／又は適正なアルコール検知が実施されているか否かにつき判定する
ことを特徴とするアルコール検知管理システム。

【請求項2】

管理サーバーが受信する検知結果には、アルコール検知を実行した日時と場所の情報及び／又はアルコール検知の検知回数の情報が含まれる
ことを特徴とする請求項１に記載のアルコール検知管理システム。

【請求項3】

管理サーバーは、アルコール検知の検知結果を受信すると、センサ識別番号に応じたセンサカートリッジの検知回数を更新する
ことを特徴とする請求項１に記載のアルコール検知管理システム。

【請求項4】

管理サーバーは、交換のために回収されたセンサカートリッジのセンサ識別番号が入力され、回収情報を生成するものであり、回収情報と登録情報に基づいて未返却のセンサカートリッジを最後使用した被検者に紐づけられた情報処理装置に対して通知を行う
ことを特徴とする請求項２又は３に記載のアルコール検知管理システム。

【請求項5】

センサ識別番号には、利用期限、検知期限回数、最終検知日時、総検知回数、現在の利用者、会社情報、使用態様の少なくとも１が紐づけられる
ことを特徴とする請求項４に記載のアルコール検知管理システム。

【請求項6】

情報処理装置を利用する際に、センサ識別番号、情報処理装置、利用者の紐づけが行われ、どの従業者が利用したかを把握できる
ことを特徴とする請求項５に記載のアルコール検知管理システム。

【請求項7】

さらに、管理者端末を備え、
情報処理装置と管理者端末との間で通話が実行されることを特徴とする請求項６記載のアルコール検知管理システム。

【請求項8】

通話は、音声のみによる通話とビデオも用いたビデオ通話とから選択可能である
ことを特徴とする請求項７に記載のアルコール検知管理システム。

【請求項9】

ビデオ通話において、複数人との同時通話が可能である
ことを特徴とする請求項８に記載のアルコール検知管理システム。

【請求項10】

管理者端末毎に、参加可能な通話人数が設定可能である
ことを特徴とする請求項９に記載のアルコール検知管理システム。

【請求項11】

管理者端末画面には、同時通話している複数人の被検者に対し、番号が割り振られて表示される
ことを特徴とする請求項１０に記載のアルコール検知管理システム。

【請求項12】

アルコール検知器の検知結果と、ビデオ通話の通話結果との総合判定により、アルコール検知の判断がなされる
ことを特徴とする請求項８に記載のアルコール検知管理システム。

【請求項13】

センサカートリッジを交換可能なアルコール検知器と管理サーバーを組合せて用いる情報処理装置であって、
アルコール検知器と通信を行う第１通信手段と、管理サーバーと通信を行う第２通信手段と、センサカートリッジに固有のセンサ識別番号を取得し保持するセンサ識別番号記憶手段と、アルコール検知の検知結果を取得する検知結果取得手段を備え、
第２通信手段は、少なくともアルコール検知の検知結果を管理サーバーに送信する
ことを特徴とする情報処理装置。

【請求項14】

センサカートリッジを交換可能なアルコール検知器と管理サーバーを組合せて用いる情報処理装置のコンピュータに、
センサカートリッジに固有のセンサ識別番号を取得し保持するセンサ識別番号記憶ステップと、
アルコール検知の検知結果を取得する検知結果取得ステップと、
センサ識別番号と紐づけられたアルコール検知の検知結果を管理サーバーに送信する送信ステップ
を実行させる情報処理装置プログラム。

【請求項15】

センサカートリッジを交換可能なアルコール検知器、管理サーバー、管理者端末を組合せて用いる情報処理装置であって、
アルコール検知器と通信を行う第１通信手段と、管理サーバーと通信を行う第２通信手段と、センサカートリッジに固有のセンサ識別番号を取得し保持するセンサ識別番号記憶手段と、アルコール検知の検知結果を取得する検知結果取得手段を備え、
第２通信手段は、少なくともアルコール検知の検知結果を管理サーバーに送信し、かつ、管理サーバーを介して管理者端末と通信を行う
ことを特徴とする情報処理装置。

【請求項16】

センサカートリッジを交換可能なアルコール検知器と管理サーバーを組合せて用いる情報処理装置のコンピュータに、
センサカートリッジに固有のセンサ識別番号を取得し保持するセンサ識別番号記憶ステップと、
アルコール検知の検知結果を取得する検知結果取得ステップと、
センサ識別番号と紐づけられたアルコール検知の検知結果を管理サーバーに送信する送信ステップと、
管理サーバーを介して、管理者端末と通信を行うステップ
を実行させる情報処理装置プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、インターネット等のネットワークを利用したアルコール検知管理システム、情報処理装置、情報処理装置プログラムに関する。

【背景技術】

【0002】

飲酒運転の罰則は、１９６０年に法定化された。それ以降、２００２年、２００７年、２００９年と三度の罰則強化が行われた。それにも関わらず、近年も大きな飲酒運転事故は発生し続けている。このような飲酒運転の問題は運転者だけの問題に限られない。すなわち、輸送サービスや配送サービスの運転者或いは営業担当であっても自動車等を業務として運転する従業員を雇い入れている事業主には使用者責任がある。飲酒運転を行った本人が刑事責任を負うことは当然であるが、従業員個人だけでなく、事業主に対しても刑事責任が及ぶこともある。
特許文献１には、運転を行う従業員である被検者がアルコール検知器のマウスピースを口へ入れたときに被検者の顔を含む画像を情報処理端末の撮像装置で撮像することによって、アルコール検査を行う技術が開示されている。この技術を用いて、従業員が事業所から出発する前および事業所へ帰った後に、アルコール検知器の使用により酒気帯びの有無の確認を行い、その結果を記録するようにしている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１５－１７５６６５号公報

【発明の概要】

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

【0004】

特許文献１に開示の技術において、アルコール検知センサには使用期間や使用回数に伴う経年劣化の問題があり、管理者は検知器が使用期限や想定使用回数を迎える迄に検知センサが交換された新しい検知器をメーカーから受け取り、貸与された古い検知器をメーカーへ返却するようにしている。このプロセスにおいて、自社が保有する大量の検知器のうちセンサ耐用年数経過に伴うメンテナンスの要否確認、事業所間での移動に伴う検知器の存在場所の確認、個々の利用者に割り当てられ管理者が把握すべき検知器一台ずつに固有の識別番号の把握という管理作業が求められる。この管理は膨大で煩雑なものであり、管理者にとって大きな負担となっていた。また、検知器は本体とセンサが一体型で提供されていたため、交換はセンサのみで済むにもかかわらず本体ごと交換する必要があり廃棄に無駄が生じ、環境保全の面でも問題があった。検知器の中には、本体とセンサが分離するものが存在し、これを採用することも可能であるが、細かい部品であるセンサカートリッジが管理対象となるため、上記した管理作業の負担増に拍車をかけることになってしまう虞があった。

【0005】

本発明は、上記に鑑みてなされたものであり、アルコール検知センサやアルコール検知システム全体の保守管理を容易にならしめ、また、適正なアルコール検知を実施し、全体の作業の効率化に寄与する技術を提供することを目的とする。

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

【0006】

本発明は、センサカートリッジを交換可能なアルコール検知器と組合せて用いるアルコール検知管理システムであって、情報処理装置と、管理サーバーを備え、情報処理装置は、アルコール検知器及び管理サーバーと通信を行うものであり、センサカートリッジに固有のセンサ識別番号を取得し保持するセンサ識別番号記憶手段と、アルコール検知の検知結果を取得する検知結果取得手段を少なくとも有し、管理サーバーは、情報処理装置からアルコール検知の検知結果を受信し、アルコール検知の検知結果に基づいてセンサカートリッジの交換時期につき及び／又は適正なアルコール検知が実施されているか否かにつき判定することを特徴とするアルコール検知管理システムにより、前述の課題を解決した。
また、本発明は、センサカートリッジを交換可能なアルコール検知器と管理サーバーを組合せて用いる情報処理装置であって、アルコール検知器と通信を行う第１通信手段と、管理サーバーと通信を行う第２通信手段と、センサカートリッジに固有のセンサ識別番号を取得し保持するセンサ識別番号記憶手段と、アルコール検知の検知結果を取得する検知結果取得手段を備え、第２通信手段は、少なくともアルコール検知の検知結果を管理サーバーに送信することを特徴とする情報処理装置により、前述の課題を解決した。

【発明の効果】

【0007】

アルコール検知センサやアルコール検知システム全体の保守管理を容易にならしめ、また、適正なアルコール検知を実施し、全体の作業の効率化に寄与することができる。

【図面の簡単な説明】

【0008】

【図1】本発明の第１実施形態に係るアルコール検知管理システムのシステム構成図

【図2】本発明の第１実施形態に係るアルコール検知管理システムにおける情報処理装置の一例を示す機能ブロック図

【図3】本発明の第１実施形態に係るアルコール検知管理システムにおける管理サーバーの一例を示す機能ブロック図

【図4】本発明の第１実施形態に係るアルコール検知管理システムが対象とするアルコール検知器の一例を示す機能ブロック図

【図5】本発明の第１実施形態に係るアルコール検知管理システムにおける情報処理装置及びアルコール検知管理システムが対象とするアルコール検知器の動作を示すフロー図

【図6】本発明の第１実施形態に係るアルコール検知管理システムにおける情報処理装置及び管理サーバーの動作を示すフロー図

【図7】アルコール検査を行っている被検者の様子を示す模式図

【図8】本発明の第２実施形態に係るアルコール検知管理システムのシステム構成図

【図9】本発明の第１実施形態に係るアルコール検知管理システムにおけるビデオ通話の実行待機中の動作を示すフロー図

【図10】本発明の第１実施形態に係るアルコール検知管理システムにおけるビデオ通話継続中の動作を示すフロー図

【図11】本発明の第１実施形態に係るアルコール検知管理システムにおける定時メンテナンス処理の動作を示すフロー図

【図12】ビデオ通話（ビデオ点呼）の流れを示すフロー図

【図13】後からビデオ点呼を行う場合の画面遷移の前半を示す図

【図14】後からビデオ点呼を行う場合の画面遷移の後半を示す図

【図15】ビデオ点呼中にアルコールチェック等を行う場合の画面遷移の前半を示す図

【図16】ビデオ点呼中にアルコールチェック等を行う場合の画面遷移の後半を示す図

【図17】管理者の情報処理装置の画面遷移を示す図（その１）

【図18】管理者の情報処理装置の画面遷移を示す図（その２）

【図19】管理者の情報処理装置の画面遷移を示す図（その３）

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

【0009】

＜第１実施形態＞
以下、本発明の第１実施形態を図面に基づいて説明する。以下の図面は説明を目的に作成されたもので、分かりやすくするため、説明に不要な部材を意図的に図示していない場合がある。また、説明のため部材を意図的に大きくまたは小さく図示している場合があり、正確な縮尺を示す図面ではない。

【0010】

図１は、本発明の第１実施形態に係るアルコール検知管理システムのシステム構成図を示しており、図２は、本発明の第１実施形態に係るアルコール検知管理システムにおける情報処理装置の一例を示しており、図３は、本発明の第１実施形態に係るアルコール検知管理システムにおける管理サーバーの一例を示している。また、図４は、本発明の第１実施形態に係るアルコール検知管理システムが対象とするアルコール検知器の一例を示している。

【0011】

（全体構成）
図１に示すように、第１実施形態に係るアルコール検知管理システム１００は、情報処理装置１及び管理サーバー２から構成され、当該情報処理装置１と管理サーバー２とは携帯電話通信網及び／又はインターネット通信網で接続されている。情報処理装置１は、アルコール検知器３とＢｌｕｅｔｏｏｔｈ（登録商標）や赤外線通信等の所定の通信方式により通信を行うように構成されている。管理サーバー２は、管理者が扱うノートＰＣ等の管理者端末４とインターネット通信網で接続されている。

【0012】

情報処理装置１は、スマートフォン、タブレット端末等の携帯通信端末であってもよいし、パーソナルコンピュータであってもよいが、第１実施形態において、情報処理装置１はスマートフォンであり、タッチパネル１１とフロントカメラ１２ａを備えている。

【0013】

管理サーバー２は、情報処理装置１から情報を受け取り、管理に必要な情報の収集や蓄積を行い、また、情報処理装置１や管理者端末４に必要な通知を行うためのものである。管理サーバー２は、管理事業者が保持して本発明のアルコール検知管理システムを直接に管理する態様か、或いは、第三者が所有しているサーバーの一部貸与を受ける等して管理事業者が本発明のアルコール検知管理システムを管理するために使用される態様かの何れであってもよい。

【0014】

アルコール検知器３は、第１実施形態に係るアルコール検知管理システム１００が管理の対象とする機器であって、呼気流入部３１と検出部３６から成るセンサカートリッジ、表示部３２ａ、検査開始ボタン３３ａ等を備えている。

【0015】

管理者端末４は、通話機能を有する情報処理装置１との間で通話を行ったり、管理サーバー２にアクセスして、各種データが集積された管理者画面を閲覧したり、登録情報を適宜編集したりすることが可能とされている。

【0016】

（情報処理装置の構成）
図２は、図１に示す情報処理装置１の概略構成を示すブロック図である。以下、図１及び図２を参照して情報処理装置１の構成について説明する。

【0017】

図２に示すように、情報処理装置１は、タッチパネル１１、撮像部１２、記憶部１３、通信部１４、及び制御部１５を備える。

【0018】

タッチパネル１１は、タッチセンサが設けられたディスプレイで構成される。ディスプレイは、液晶ディスプレイや有機ＥＬディスプレイ等で構成される。タッチセンサは、例えば静電容量式のタッチセンサであり、表示領域においてユーザの指等が接触した位置の静電容量の変化を検出する。タッチパネル１１は、制御部１５の制御の下、各種画像を表示する。

【0019】

撮像部１２は、フロントカメラ１２ａとバックカメラ１２ｂとを含む。フロントカメラ１２ａ及びバックカメラ１２ｂは、ＣＣＤイメージセンサやＣＭＯＳイメージセンサ等の撮像素子と複数のレンズが収納されたレンズユニットとを含む。フロントカメラ１２ａは、情報処理装置１においてタッチパネル１１が設けられた面方向の被写体を撮像する。バックカメラ１２ｂは、情報処理装置１においてタッチパネル１１と反対側の面方向の被写体を撮像する。撮像部１２は、動画撮影を行う動画モード及び静止画撮影を行う静止画モードを含む撮像モードを有する。撮像部１２は、制御部１５の制御の下、指定された撮像モードで、被検者自身がフロントカメラ１２ａを用いて、又は、補助者の助けを得てバックカメラ１２ｂを用いて撮像を行う。また、撮像部１２は、管理者端末４との間でのビデオ通話にも用いられる。

【0020】

記憶部１３は、ｅＭＭＣ（embedded Multi Media Card）やＵＦＳ（Universal Flash Storage）等の不揮発性メモリで構成される。記憶部１３は、制御部１５の制御の下、アルコール検査に必要な画像データや、アルコール検知器３からの検出結果等を含む各種データを記憶する。

【0021】

通信部１４は、Ｂｌｕｅｔｏｏｔｈ（登録商標）や赤外線通信等の所定の通信方式によりアルコール検知器３との間で通信を行う。この他、スマートフォンが普通に備える４Ｇ、５Ｇ、Ｗｉ-Ｆｉ等の通信部（不図示）も備えており、携帯電話通信網及び／又はインターネット通信網を通じて、管理サーバー２等の外部機器との間で通話や通信を行う。

【0022】

制御部１５は、ＣＰＵと、ＣＰＵとバス接続されたメモリ（ＲＯＭ及びＲＡＭ）を含む。ＣＰＵは、バスを介して、タッチパネル１１、撮像部１２、記憶部１３、通信部１４と接続されている。制御部１５は、ＣＰＵが、ＲＯＭに記憶されたアルコール検査プログラムを実行することにより、ＣＰＵと接続された各部を制御してアルコール検査処理を実行する。

【0023】

具体的には、制御部１５は、ＣＰＵによるアルコール検査プログラムの実行により、検出制御部１５１、撮影制御部１５２、パスワード生成部１５３、表示制御部１５４として機能する。

【0024】

すなわち、被検者がアルコール検査プログラムの起動操作を行うと、表示制御部１５４は、タッチパネル１１にアルコール検査の開始指示を表示して、被検者にアルコール検知器３を起動するように促す。検出制御部１５１は、アルコール検知器３から通信部１４を介して検知回数情報を受信してメモリに記憶する。検出制御部１５１が検知回数情報を受信すると、パスワード生成部１５３は、真正な被検者についてのアルコール検知が実行されたか否か判定するための識別情報の一例としてワンタイムパスワードを生成する。この際、パスワード生成部１５３は、所定のアルゴリズムに基づいて、アルファベット、数字、及び記号等の少なくとも１つを用いてランダムにワンタイムパスワードを生成し、通信部１４を介してアルコール検知器３にワンタイムパスワードを送信する。検出制御部１５１が通信部１４を介してアルコール検知器３から後述するクリーニングが終了した旨の情報を受信すると、表示制御部１５４は、タッチパネル１１にアルコール検査の開始指示を表示して、被検者にアルコール検知器３に息を吹き込むよう促す表示を行うよう制御すると共に、撮影制御部１５２は、フロントカメラ１２ａ又はバックカメラ１２ｂを用いた撮像を開始させる。また、検出制御部１５１は、アルコール検知器３から通信部１４を介して検知結果を取得する。検知結果は、通信による取得に加えて、アルコール検知器３に表示された画像を撮影することによっても取得される。

【0025】

なお、図２では図示を省略するが、情報処理装置１は、図２に示す構成に加え、通話機能に必要なマイクロフォンやスピーカ等を備える。

【0026】

（管理サーバーの構成）
管理サーバー２は、アルコール検知システムにおける保守管理に関する各種の情報処理を担うことにより、アルコール検知管理システム１００の全体動作を制御するものである。この管理サーバー２は、図３に例示するように、表示部２１、操作部２２、通信部２３、ＣＰＵ２４、ＲＯＭ２５、ＲＡＭ２６、大容量記憶部２７などを備えるコンピュータシステムにおいて、ＲＯＭ２５あるいは大容量記憶部２７に予め格納される所定の動作プログラムをＣＰＵ２４において実行させることにより実現される。

【0027】

特に、ＣＰＵ２４は、後述するように、被検者が適正なスケジュールの下でアルコール検知を実施しているか否かについての判定や、真正な被検者についてのアルコール検知が実行されたか否かについての判定を行う判断手段としての機能を担うものである。

【0028】

また、ＣＰＵ２４は、情報処理装置１の端末識別番号及びセンサカートリッジに固有のセンサ識別番号を取得して端末識別番号及びセンサ識別番号についてリスト化された登録情報を生成する生成手段としての機能も担う。

【0029】

大容量記憶部２７には、センサカートリッジの保守管理のために必要なセンサ識別番号や端末識別番号が登録されており、特徴的なこととして、従業員の顔データも登録されており、管理者ＤＢとして構成される。さらには、アルコール検知器３が検出した検知結果データや、事業所間や従業員間での使いまわしにより移動する可能性のあるアルコール検知器３の位置データも管理者ＤＢには蓄積される。ただし、これらの管理情報の項目については全てが必須のものではなく、管理をどの程度にきめ細かく行いたいかという要求仕様に応じて、管理情報の項目は適宜に選択される。

【0030】

（アルコール検知器３）
アルコール検知器３は、第１実施形態のアルコール検知管理システム１００を構成する要素ではないが、システムが直接に保守管理する対象であるという観点で重要であるので、以下に説明する。図４は、図１に示すアルコール検知器３の概略構成を示すブロック図である。図１及び図４を参照してアルコール検知器３の構成を説明する。

【0031】

図４に示すように、アルコール検知器３は、呼気流入部３１、報知部３２、操作受付部３３、記憶部３４、通信部３５、検出部３６、及び制御部３７を備える。

【0032】

呼気流入部３１は、マウスピースの如き管状部材で構成される。図１に示すように、呼気流入部３１の一部はアルコール検知器３の外部に突出し、呼気流入部３１の他の部分はアルコール検知器３内において検出部３６として機能し、センサカートリッジを構成している。呼気流入部３１において、アルコール検知器３の外部に突出した部分の端部は、被検者の口にくわえられ、被検者の呼気が吹き込まれる吹込み口である。被検者から吹き込まれた呼気は、呼気流入部３１の内部を通り、検出部３６に導かれる。

【0033】

報知部３２は、表示部３２ａ及び音声出力部３２ｂを含む。表示部３２ａは、液晶ディスプレイや有機ＥＬディスプレイ等で構成され、制御部３７の制御の下、画像を表示する。音声出力部３２ｂは、スピーカを含み、制御部３７の制御の下、ビープ音等の音声を出力する。

【0034】

操作受付部３３は、アルコール検知器３の電源ボタン（図示略）や、検査開始ボタン３３ａ（図１参照）等の操作ボタンを含む。操作受付部３３は、操作ボタンの押下操作を示す操作信号を制御部３７に出力する。

【0035】

記憶部３４は、ＥＥＰＲＯＭやフラッシュメモリ等の不揮発性メモリで構成される。記憶部３４は、アルコール検知器３におけるアルコール検知処理に必要な各種データを記憶する。

【0036】

通信部３５は、情報処理装置１とアルコール検知器３との間で、Ｂｌｕｅｔｏｏｔｈ（登録商標）や赤外線通信等の所定の通信方式により通信を確立する。もっとも、通信部３５は、通信ケーブルを介して情報処理装置１との間で通信を行うように構成してもよい。

【0037】

検出部３６は、圧力センサや、アルコール濃度を検出するアルコールセンサを含む（いずれも図示略）。第１実施形態では、半導体式アルコールセンサが用いられるが、この方式に限らず、アルコール濃度を検出する方式は、半導体方式に限定されず、燃料電池方式、非拡散赤外線吸収方式、及び化学反応方式等であってもよい。

【0038】

また、検出部３６は、半導体式アルコールセンサを加熱するヒータを含む加熱機構（図示略）を備える。ただし、他の方式を採用する場合には加熱機構を備えないこともある。検出部３６は、呼気が吹き込まれる前に、アルコールセンサを加熱機構によって加熱し、アルコールセンサの表面の残気ガス等を除去することで、アルコールセンサをクリーニングする。

【0039】

検出部３６は、制御部３７の制御の下、一定以上の圧力で呼気流入部３１に吹き込まれた呼気中のアルコール濃度を検出する。

【0040】

呼気流入部３１と検出部３６で構成されるセンサカートリッジは、固有のセンサ識別番号（シリアルナンバーであってよいが、シーケンシャルなものでなくてもよく、要は、個体を一意に識別できればよい。）を有している。センサ識別番号は、ＩＣチップ等（不図示）に保持され、センサカートリッジが装填された際にアルコール検知器３が認識できるようになっている。また、センサ識別番号は、ＲＦタグにも記憶されており、管理者が回収した際の番号取得を簡便なものとしている。もちろん、センサカートリッジに刻印されて表示し、回収時に手入力される態様が排除されるものではない。この他、第１実施形態においては、センサカートリッジのＩＣチップ等（不図示）には、後述する検知回数情報が更新記憶されるように構成されているが、必須ではない。すなわち、管理サーバー２で更新記憶するように構成することが可能であるし、検知回数ではなく使用期限といった管理サーバー２が当然に保有する情報で管理することも可能である。また、回収時に管理するためのＲＦタグについては、バーコードや２次元バーコードといった他の識別認証手段を用いるようにしてもよい。

【0041】

制御部３７は、マイクロコントローラ（ＭＣＵ）、ＭＣＵとバス接続されたメモリ（ＲＯＭ及びＲＡＭ）とを含む（いずれも図示略）。ＭＣＵは、バスを介して報知部３２、操作受付部３３、記憶部３４、通信部３５、及び検出部３６と接続されている。

【0042】

制御部３７は、ＭＣＵがＲＯＭに記憶された制御プログラムを実行することにより、ＭＣＵと接続された各部を制御してアルコール検知処理を行う。具体的には、制御部３７は、ＭＣＵによる制御プログラムの実行により、生成部３７１、検出制御部３７２、及び報知制御部３７３として機能する。

【0043】

生成部３７１は、情報処理装置１から受信したワンタイムパスワードに基づいて、７セグメント数字表示、バーコード、二次元コードといったコード化データを生成する。生成された７セグメント数字表示、バーコード、二次元コードは、表示部３２ａに表示される。

【0044】

検出制御部３７２は、検査開始ボタン３３ａが押下された後、検出部３６にクリーニング処理とアルコール検知処理とを順次行わせる。検出制御部３７２は、検出部３６の検出結果をメモリに記憶し、通信部３５を介して検出結果を示す情報を情報処理装置１へ送信する。

【0045】

報知制御部３７３は、息が吹き込まれた旨の報知や、検知結果が情報処理装置１へ送信された旨の報知処理を実行する。また、報知制御部３７３は、メモリに記憶された検出結果を示す画像（以下、検出結果画像）と、パスワードを示す画像（以下、パスワード画像）とを表示部３２ａに表示させる。パスワード画像は、パスワードをバーコードや二次元バーコードで表した画像である。ただし、簡便のため、パスワードを文字で表した画像としてもよい。また、報知制御部３７３は、クリーニング処理の終了後、クリーニング終了を示す画像又は音声を報知部３２により報知させる。

【0046】

＜第１実施形態のアルコール検査処理動作＞
以下、アルコール検知管理システム１００におけるアルコール検査処理（アルコールチェック）の動作を説明する。図５は、アルコール検知工程であって、情報処理装置１とアルコール検知器３が協働して動作する様子を示すフロー図である。また、図６は、アルコール検知後の登録等処理工程であって、情報処理装置１と管理サーバー２が協働して動作する様子を示すフロー図である。なお、水平方向の実線矢印は、装置間での通信が行われることを意味するものであり、水平方向の点線矢印は、表示画面を用いて相手方装置の操作を促すことや表示画面を撮像することを意味するものである。以下、図５及び６を用いてアルコール検査処理について説明する。

【0047】

（アルコール検知工程）
図５のステップＳ１０１において、情報処理装置１は、アルコール検査アプリを起動し、ステップＳ１０２において検知開始指示操作が入力されると、ステップＳ１０３においてタッチパネル１１には、アルコール検知器３の電源ボタン及び検査開始ボタン３３ａを操作するよう促す表示が行われる。

【0048】

アルコール検知器３において電源ボタン及び検査開始ボタン３３ａの操作が順次なされると、ステップＳ３０１において電源オンとされ、ステップＳ３０２において、更新された検知回数情報が情報処理装置１に送信される。検知回数情報は、新規に製造される場合やリユースのためリフレッシュされた後にセンサカートリッジが工場等から出荷される時を起点として計数が開始されるものであり、カートリッジのＩＣチップ等（不図示）に記憶更新される情報である。当該情報は情報処理装置１を介して管理サーバー２へ引き継がれることになる。なお、第１実施形態において、検知回数情報はセンサカートリッジが記憶する構成とされているが、適宜の管理情報と照合して情報処理装置１や管理サーバー２が検知回数を計数するように構成することも可能であり、その場合には、ステップＳ３０２において送信される情報は、これから検知を開始するという検知開始情報のみということになる。

【0049】

ステップＳ１０４において検知回数情報若しくは検知開始情報を受信すると、ステップＳ１０５において、情報処理装置１は、真正な被検者についてのアルコール検知が実行されたか否か判定するためのワンタイムパスワードを生成する。ワンタイムパスワードの生成は所定のアルゴリズムに基づいて、アルファベット、数字、及び記号等の少なくとも１つを用いてランダムに行われる。続くステップＳ１０６において、ワンタイムパスワードがアルコール検知器３に向けて送信される。

【0050】

ステップＳ３０３においてワンタイムパスワードを受信すると、ステップＳ３０４において、アルコール検知器３は、クリーニング処理を行う。すなわち、アルコール検知器３は、検出制御部３７２により、検出部３６における加熱機構（図示略）を加熱させてアルコールセンサをクリーニングする。続くステップＳ３０５において、クリーニング終了信号が情報処理装置１に向けて送信される。

【0051】

ステップＳ１０７においてクリーニング終了信号を受信すると、ステップＳ１０８において、情報処理装置１は、被検者に自身の姿とアルコール検知器３の表示部３２ａが情報処理装置１の撮像部で捉えられるようにしつつ、アルコール検知器３に息を吹き込むように促す画像をタッチパネル１１に表示させる。この表示は画像と文字を適宜に組み合わせた画面とするとよい。アルコール検知器３の表示部３２ａが撮像される必要性については後述する。続くステップＳ１０９において、情報処理装置１の撮影制御部１５２は、フロントカメラ１２ａ又はバックカメラ１２ｂを用いた撮像を開始する。

【0052】

撮像は、次のように行われる。すなわち、被検者が情報処理装置１のタッチパネル１１に表示される画像を確認しながら、自分とアルコール検知器３とがフロントカメラ１２ａに映るように、アルコール検知器３と情報処理装置１とを両手で把持し、アルコール検知器３の呼気流入部３１に呼気を吹き込む。撮像補助者がいる場合には、バックカメラ１２ｂを用いることによって、アルコール検知器３を保持する被検者を撮像補助者が撮像するようにしてもよい。この間、アルコール検知器３は、ステップＳ３０６～Ｓ３０８において、呼気流入部３１から一定以上の圧力で吹き込まれる呼気中のアルコール濃度に基づいて呼気中のアルコール有無を検出して、検知結果を情報処理装置１へ向けて送信する。また、アルコール検知器３は、検知結果の送信に加えて、自身の表示部３２ａに画像として表示する（ステップＳ３０９）。この画像には、検出結果画像とパスワード画像が含まれている。パスワード画像はパスワードを７セグメント数字表示、バーコード、二次元コード等で表した画像であり、被検者には判別がつかないものとされている。

【0053】

撮像している間、情報処理装置１は、通信により検知結果が取得できたかを判定し、一定時間内に検知結果を取得できなかった際には、エラーとして記録する（ステップＳ１１０，Ｓ１１２～Ｓ１１３）。通信による検知結果を取得できた際に、情報処理装置１は、ステップＳ１１１において、アルコール検知器３の表示部３２ａに表示された検出結果画像とパスワード画像を記録した後に撮像を終了する。

【0054】

（アルコール検知後の登録等処理工程）
アルコール検知器３での検知が終了し、全ての情報が情報処理装置１へ引き継がれた後に、情報処理装置１と管理サーバー２が協働して行う検知結果の登録処理等について説明する。

【0055】

図６のステップＳ１１４において、情報処理装置１は、検知結果を管理サーバー２へ向けて送信する。第１実施形態において、検知結果には、アルコールの検知量、検知日時、検知場所、ワンタイムパスワードの元データ、二次元バーコード等にエンコードされたワンタイムパスワード画像、被検者の顔写真、センサカートリッジ交換からの検知回数が含まれているが、全てのものが必須な訳ではない。例えば、アルコール検知管理システム１００で保守部品の管理だけを行い、適正な検知が行われたか否かについては管理を行わない、或いは、情報処理装置１側で判定を行い、適正検知の実行の有無の結果だけを管理サーバー２が取得するのであれば、顔写真やワンタイムパスワードの送信は不要である。また、保守部品の管理、具体的にはセンサカートリッジの交換時期の把握についても、前述したように、管理サーバー２が検知回数の計数を行うのであれば、検知回数の送信は不要となる。さらには、略毎日、同じ頻度でアルコール検査が実施される運用が想定されているのであれば、センサカートリッジの交換時期を使用回数に依らずとも使用期間で把握することが可能となるため、検知回数の判定すら不要となる。要するに、管理する内容の多寡や判断主体をシステム要素のどの部分に担わせるかということに応じて、検知結果に含ませる情報については、適宜に設定すればよい。

【0056】

第１実施形態においては、管理サーバー２が真正な被検者についてのアルコール検知が実行されたか否かにつき判定するように構成されており、ステップＳ２０２～Ｓ２０４ではそのための処理が実行される。以下、図７も併せて参照しつつ説明する。

【0057】

図７は、アルコール検査を行っている被検者の様子を示す模式図である。より具体的には、図７は、被検者がアルコール検知器３に呼気を吹き込みながら情報処理装置１で撮影し、アルコール検知器３の表示部３２ａに、検出結果画像３２０ａとワンタイムパスワード画像３２０ｂとが表示された状態を示している。このように、第１実施形態では、検出結果画像３２０ａとワンタイムパスワード画像３２０ｂとが表示部３２ａに表示されるまで、被検者がアルコール検査を行っている様子が撮影される。

【0058】

ステップＳ２０２において、判定部として機能する管理サーバー２のＣＰＵ２４が、撮像データにワンタイムパスワードと一致する画像が含まれているか否か判定する。すなわち、撮像データに含まれる二次元バーコードなどを所定の解析アルゴリズムに従ってデコードし、デコード結果とワンタイムパスワードの元データとが一致するか否か判定する。

【0059】

デコード結果とパスワードの元データ判定処理後、ステップＳ２０３において、判定部として機能する管理サーバー２のＣＰＵ２４が、撮像データに予め定められた被検者の顔画像と一致する画像が含まれるか否か判定する。

【0060】

ワンタイムパスワードと被検者の顔画像の判定処理が終了した後、ステップＳ２０４において管理サーバー２はその結果を情報処理装置１へ向けて送信し、ステップＳ１１５において当該結果を受信した情報処理装置１は、エラーがあった場合には、その旨を表示し、エラーがなかった場合には、全ての処理を終了する。管理サーバー２は、ステップＳ２０５において必要な情報を大容量記憶部２７に蓄積し、管理者ＤＢを更新する。

【0061】

第１実施形態において、例えば、真の被検者が、他人のアルコール検知器でアルコール検査を行っている仕草を情報処理装置１で撮影すると同時に、真の被検者に成りすました他人が、真の被検者のアルコール検知器３に呼気を吹き込み、アルコール検査を偽装した場合に情報処理装置１において撮像されたデータに、真の被検者のアルコール検知器３で生成されたパスワードと一致する画像は含まれない。このため、被検者のアルコール検知器３から情報処理装置１に送信された検出結果は、管理サーバー２によって正当ではないと判定される。管理サーバー２の判定結果を受信した情報処理装置１は、図５のステップＳ１１２で判定される検知結果が取得できない旨の状況と併せた包括的なエラーメッセージをタッチパネル１１に表示させる（Ｓ１１７）。

【0062】

ここでの説明では、「有効な検知ができませんでした」といったメッセージ等の包括的なエラー表示を行うようにしている。しかし、「他の方が息を吹き込みませんでしたか？」といった具体的なメッセージを表示するようにしてもよい。或いは、エラーの内容は曖昧にしておき、具体的なエラーの内容を管理者ＤＢに蓄積しておき、後日に管理者から従業員に警告するといった運用も可能である。これらのエラーの報知態様について、適宜に設定変更することが可能とされている。

【0063】

（管理サーバーを中心とする保守フロー）
第１実施形態において、管理サーバー２を中心としたセンサカートリッジやアルコール検知器本体の保守管理を容易に行うことができる。以下に説明することは、保守フローの一例である。

【0064】

まず、アルコール検知器及びセンサカートリッジの製造業者は、アルコール検知器に固有の本体識別番号とセンサカートリッジに固有のセンサ識別番号、利用期限日、検知期限回数についての情報を管理サーバー２に登録する。ここで、センサ識別番号はシリアル番号であってもよい。一方、管理者は、各従業員が利用する端末識別番号の登録を行う。
なお、登録作業を行う主体は適宜に取り決めることができる。例えば、製造業者は、センサ識別番号についての情報を管理者に提供するに止め、登録は管理者自身が行う運用可能であるし、逆に、端末識別番号の登録についても製造業者が代行して行うようにしてもよい。

【0065】

以上の登録作業を経て利用者情報を含む管理者ＤＢが構築される。利用者または管理者は、利用者情報を登録または編集することが可能である。登録及び編集作業を経ると、端末識別番号と利用者の紐づけが行われ、端末についてどの従業者が利用したかを把握することが可能となる。さらに、利用者がアルコール検査アプリを利用し、アルコール検知器の情報（本体識別番号とセンサ識別番号）が取得され、端末識別番号を仲立ちとしてセンサ識別番号および利用者情報の更新が実施される。つまり、センサ識別番号、端末識別番号、利用者の紐づけが行われ、センサカートリッジについてどの従業者が利用したかを把握・確認できるようになる。

【0066】

センサ識別番号に紐づけられる情報の例としては、例えば、a.センサの利用期限、b.検知期限回数、c.最終検知日時、d.総検知回数、e.現在の利用者、f.会社情報、g.使用態様（従業員毎の支給、事業者内共用、予備機の別）といった項目が挙げられる。以上の他に、装填されているアルコール検知器の本体識別番号や本体の利用期限に関する情報を加えてもよい。

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

（ａ６）において、ビデオ点呼が開始される。「４人参加中」と表示されているように、本実施形態では、複数人とのビデオ点呼が同時に進行することになる。その上の「ビデオ点呼」との表示の右隣に表示されている「１」の数字は、複数人点呼において自身に割り当てられた番号を意味している。画面中に、大きく表示されている者は管理者（運転管理者）のカメラ映像であり、右上にある「１」の数字は管理者の番号である。このような数字や他の情報については、点滅や適宜のアニメーション表示とさせて、目立つ表示にすると良い。画面中に、小さく表示されている者は情報処理装置１を操作している被検者（ドライバー）自身のカメラ映像である。なお、他のドライバーのカメラ映像は表示されていない。（チャットルームの如き）点呼用のルームとしての仮想空間に入室している被検者（ドライバー）のみが管理者と会話できる。管理者の声は、被検者（ドライバー）全員に聞こえる一方で、ドライバー同士の声は聞こえない設定とされている。

【0099】

（ａ６）の画面下の方に、ポップアップ表示がされているが、これは、点呼終了時に表示されるものである。ここでは、点呼の結果として「ＯＫ」が、また、指示事項として「スリップ注意」とのワーニングが表示されているが、点呼の結果が「ＮＧ」となることも当然ある。一番下に表示されている「点呼終了。ＴＯＰに戻る」というボタンは、管理者（運転管理者）が点呼終了の指示操作をしたら、アクティベートされ、被検者がボタンをタッチして選択できるようになっており、それまでは選択できないように構成されている。

【0100】

（ビデオ点呼中にアルコールチェック等を行う場合の画面遷移）
次に、ビデオ点呼中に通常点呼及びアルコール検知器によるアルコールチェックを行う場合の画面遷移について、図１５及び図１６を用いて説明する。図１５（ｂ１）において、下方に示される検知開始のボタンをタッチして、その後の処理に進む。（ｂ２）において、「ビデオ点呼」をタッチして、ビデオ点呼に進む。なお、「通常点呼」のボタンは、「（後からビデオ点呼をする場合の画面遷移）」において説明したように、ビデオ点呼に先立って、予め通常点呼を実施しておきたいと考える被検者のための選択肢として、用意されているものである。

【0101】

ビデオ点呼が選択されると、（ｂ３）に示されるように、管理者ごとに、点呼を待っているドライバーの人数や管理者は待機中であるのか不在であるのか、といった情報が表示される。この例では、管理者が不在との情報が表示されているが、不在の管理者は、項目自体を表示させないようにしてもよい。また、管理者の候補を表示させずに、自動抽出できるようにしても良いことは、「（後からビデオ点呼をする場合の画面遷移）」において説明したことと同様である。
この例では、管理者の候補が表示され、指定選択できるようにされている。すなわち、（ｂ３）の画面で、管理者１を選択して、「ビデオ点呼申請」のボタンをタッチしてから、（ｂ４）に示される画面に遷移して、「○○人待ち」との人数表示が行われるようにされている。その後、ビデオ点呼が進行して人数が減数表示されていき、人数分のビデオ点呼が消化され、自身の順番が回ってくると、図１６（ｂ５）の画面に遷移する。

【0102】

（ｂ５）において、ビデオ点呼が開始される。「４人参加中」と表示されているように、本実施形態では、複数人とのビデオ点呼が同時になされる。その上の「ビデオ点呼」との表示の右隣に表示されている「１」の数字は、複数人点呼において自身に割り当てられた番号を意味している。画面中に、大きく表示されている者は管理者（運転管理者）のカメラ映像であり、右上にある「１」の数字は管理者の番号である。番号を用いることで、氏名でやり取りするよりもスムーズな点呼が期待できる。ビデオ点呼ならではの臨機応変な具体的会話がされるのに先立って、先ず、通常点呼（定型点呼）とアルコール検知器によるアルコールチェックが実行されることになる。ただし、この時点で、情報処理装置１（スマートフォン）のカメラの映像が管理者（運転管理者）に送信開始されるので、管理者は、管理者端末４の画面で通常点呼やアルコールチェック実施中の被検者（ドライバー）の様子を適宜観察することができる。被検者は、（ｂ６）に示されるような定型質問に対する回答を入力した後、（ｂ７）のような操作指示画面に沿って、図５及び図７を用いて説明したアルコールチェックを実施し、（ｂ８）において「結果送信」のボタンをタッチして、アルコールチェックの結果を送信する。
その後、ビデオ点呼が実施され、点呼終了時に、点呼結果やワーニングがポップアップ表示され、「点呼終了。ＴＯＰに戻る」のボタンが、管理者（運転管理者）の点呼終了の指示操作により、アクティベートされ、選択できるようになることは、図１４（ａ６）で説明したことと同様である。

【0103】

この他、画面遷移に際して、説明したこと以外に、アルコール検査アプリには、次のような機能を持たせることが可能である。
・通信に異常が発生した場合でも、定型点呼とアルコールチェックをやり直す必要がないように、定型点呼とアルコールチェックは継続するが、ビデオ点呼のみ中断することが可能。
・声が小さいときにドライバーへ警告を行う。
・点呼する管理者（点呼部屋）を選択する際、並び順を工夫してすぐに最適な点呼部屋を選ぶことが可能である。例えば、前回やり取りした管理者 → 空いている管理者 → その他といった順で並べる。
・点呼の担当者が特定できるように点呼中には管理者名が表示される。
・アルコール検査アプリで点呼部屋に入室して（開始）から一定時間経過してもビデオ点呼が完了しない場合、警告をした後、回線を切断する（所謂タイムキーパー機能）。

【0104】

（管理者が操作する情報処理装置の画面遷移）
管理者が操作する管理者端末４（汎用ＰＣ）の画面遷移についても説明しておく。図１７（ｃ）に示されるように、また、図９及び図１０を用いて説明したことから理解されるように、ビデオ点呼が開始された後、管理者及び管理者が操作する管理者端末４では、点呼待機状態と点呼中の状態が、点呼終了まで繰り返し続けられることになる。

【0105】

図１７（ｃ０）に示されるのは、管理者端末４に表示される画面のヘッダ部分のみを示したものである。ヘッダ中の「ビデオ点呼」を選択すると、点呼処理が開始されることになる。先ず、（ｃ１）に示される画面で、点呼を行うべき営業所（ここでは、「営業所１」）を選択し、画面下方の「点呼開始」を選択すると、（チャットルームの如き）点呼用のルームとしての仮想空間が生成される。なお、この営業所での選択という階層の設定については、規模に応じては、設けなくてもかまわない。すなわち、管理者には、対象点呼者の一群を抱える営業所が固定的に紐づけられるように構成してもよい。

【0106】

図１８（ｃ２）は、待機中の画面であり、右の画像は、管理者のカメラ映像である。左上の「終了」を選択すれば、点呼を終了させることが可能であり、その場合に、当該管理者のステイタスは不在ということになる。若しくは、点呼ルーム自体が立ち下げられることになる。

【0107】

ビデオ点呼が開始されると、（ｃ３）に示される画面に遷移する。４人の男性の画像は、被検者（ドライバー）の画像であり、それぞれの左に示される数字は、このビデオ点呼で一時的に割り当てられた番号である。太枠で囲まれた被検者１が現在ビデオ点呼の対象となっている被検者であり、管理者は、具体的な質問をして、その回答振りを観察する。ただし、被検者１に質問を行っている最中にも他の被検者の画像を観察することが可能である。また、管理者のカメラ画像は、右上に小さく表示されている。

【0108】

被検者１の画像の右上隅に表示されているアイコンをクリックすると、被検者１の画像が拡大される。また、顔画像をクリックすることによっても、画像が拡大される。画像の右下隅に表示されているマイクを示すアイコンをクリックすると、管理者側（運転管理者側）で被験者（ドライバー）のマイクをミュートとすることができる。この際、被験者には、ミュートとされたことがポップアップ表示で伝えられる。各被検者の下に表示されている項目は、通常点呼（定型点呼）及びアルコールチェックの実施の有無の情報であり、右の数字は接続時間を示している。例えば、管理者が対応困難と判断した場合に、画面左下の「途中参加禁止」のチェックボックスをチェックすると、まだ制限人数に余裕があっても、入室ができないように制限される。ここで示された画面例は、定員の４人が既に入室済みの例である。また、ここで、被検者は４人表示されるように、画面が４分割表示とされているが、１人や２人のみが参加した場合には、画面分割がされないか、２分割表示とされる。図１９（ｃ４）の画面は１人が参加している場合、若しくは、複数人参加時に、一人の被検者の画面を拡大表示させた場合の表示例である。図１９（ｃ５）の画面は２人が参加している場合の表示例である。

【0109】

図１８（ｃ３）に戻って、画面右側には、「１」と表示され、その下に「端末番号」、「車両名」、「点呼項目１」、「検知結果」等の表示がされているが、現在ビデオ点呼の対象となっている被検者１の通常点呼やアルコールチェックの結果である。「指示事項」はコンボボックスで選択し、適宜入力することが可能とされている。一人一人の点呼を個別に完了しようとする際には、個別完了のチェックボックスにチェックを入れて点呼を完了する。逆に、チェックを入れなければ、入室中の被検者全員の点呼完了処理を一度に済ませることができ、効率的である。

【0110】

このようにして、実行される通常点呼の回答、アルコール検知器によるアルコールチェックの結果、ビデオ点呼による諮問内容を総合判定することによって、管理者が勤務ＯＫ若しくはＮＧの最終判定を行うことになる。この他、画面遷移に際して、説明したこと以外に、管理者端末には、次のような機能を持たせることが可能である。
・点呼時に管理者が不在の場合は、管理者が携帯するスマートフォン等に対して通知を行うことにより管理者を呼び出す。
・ドライバーが管理者選択画面を選択しようとした際に、管理者が不在もしくは途中参加可能な部屋が存在しない場合であっても、誰かが対応できるように、管理者画面にダイアログ表示を行い、併せて、警告音、メール、チャットｂｏｔ等を用いて全管理者宛に通知を送信する。
・特定ドライバーとやり取りが不要な場合は、ミュートでき、ドライバーにもミュート済みを伝える。
・会話は音声として表示されるだけでなく、吹き出し・字幕に変換して表示してもよい。他の被検者と通話が行われている最中に緊急で伝えたいことが発生した場合や、自身がミュートの扱いとされている場合に、有効である。
・テキストチャットでドライバーへ定型文の指示事項を送信することが可能。
・検知待ちの人数がわかるよう、人数も表示してリアルタイムで更新可能。

【0111】

以上、本発明の実施形態に係るアルコール検知管理システムについて、図面を参照して詳述してきたが、具体的な構成は、これらの実施例に限られるものではなく、本発明の要旨を逸脱しない範囲の設計の変更等があっても本発明に含まれる。例えば、適正なアルコール検知が実施されているかという観点につき、各実施形態では、真正な被検者についてのアルコール検知が実行されたか否かについて判定を行うものとして説明したが、被検者が適正なスケジュールの下でアルコール検知を実施しているか否かについての判定を行うといった簡易的なチェックに止まるものであっても十分に実効性がある。規則で出発前と到着後に行う検査を従業員が「うっかり忘れてしまった」等と不作為とする誤魔化しも横行される虞があるからである。また、息を吹き込むように画面表示で指示する際に、撮影が開始される旨も画面表示させる態様が被検者には直感的で分かり易いため、撮影開始をこの直後から実行するようにしているが、実際の撮影開始は遅らせてもよいし、さらには、何枚かの静止画を不連続的に撮影させるようにしてもよく、要は、被検者の顔とワンタイムパスワード画像とが同時に映り込めばよい。また、アルコール検知器によるアルコールチェック、ビデオ点呼による内容の総合判定は、全てを実施せずとも、例えば、アルコール検知器によるアルコールチェックと、より簡易的な音声通話と、で行うようにしたり、適宜の重みづけをして判断を行うようにしたりするように構成してもよい。

【符号の説明】

【0112】

１００ アルコール検知管理システム
１０１ アルコール検知管理システム（於第２実施形態）
１ 情報処理装置
１１ タッチパネル
１２ 撮像部
１２ａ フロントカメラ
１２ｂ バックカメラ
１３ 記憶部
１４ 通信部
１５ 制御部
１５１ 検出制御部
１５２ 撮影制御部
１５３ パスワード生成部
１５４ 表示制御部
２ 管理サーバー
２１ 表示部
２２ 操作部
２３ 通信部
２４ ＣＰＵ
２５ ＲＯＭ
２６ ＲＡＭ
２７ 大容量記憶部
３ アルコール検知器
３’ アルコール検知器（於第２実施形態）
３１ 呼気流入部
３１’ 呼気流入部（於第２実施形態）
３２ 報知部
３２ａ 表示部
３２ｂ 音声出力部
３３ 操作受付部
３３ａ 操作開始ボタン
３４ 記憶部
３５ 通信部
３６ 検出部
３７ 制御部
３７１ 生成部
３７２ 検出制御部
３７３ 報知制御部
３８ フロントカメラ（於第２実施形態）
４ 管理者端末

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】