JP7597096B2 - 遠隔サービスの管理方法及び管理装置 - Google Patents

Description

本開示は、移動体を対象とする遠隔サービスを管理する方法及び装置に関する。

特開２０１８－１４２２６５号公報は、自動運転車両の遠隔サービスの管理方法を開示する。この従来の方法では、ある自動運転車両の遠隔操作が必要であると判定された場合、複数のオペレータの中から待機中のオペレータが選出され、この選出されたオペレータに遠隔操作が割り当てられる。そのため、この従来の方法によれば、複数の自動運転車両の遠隔サービスを、少数のオペレータで効率的に運用することが可能となる。

本開示に関連する技術分野の技術水準を示す文献としては、特開２０１８－１４２２６５号公報の他に、特開２０２１－１４４７３２号公報を例示することができる。

特開２０１８－１４２２６５号公報 特開２０２１－１４４７３２号公報

自動運転車両を含む移動体の遠隔操作を行うオペレータは、この遠隔操作に際して移動体に関する情報を取得し、移動体の周囲状況や、オペレータに要求される遠隔操作のタスクの内容を把握する。移動体に関する情報には、移動体に搭載されたカメラにより取得されたカメラ画像に代表されるセンサ情報が含まれる。このセンサ情報は、典型的には可視化されてディスプレイに出力される。センサ情報のディスプレイへの出力は、移動体の周囲状況等の早期把握を助けることが期待される。

しかしながら、遠隔操作を待機していたオペレータによる周囲状況等の把握に要する時間は、移動体の運転席に座っているドライバによるそれに比べて長くなることは避けられない。何故なら、ドライバは自らが乗っている移動体の周囲状況を常に把握することが期待されるのに対し、遠隔操作を待機していたオペレータにドライバによる周囲状況の把握と同程度の把握を期待することは現実的に困難だからである。

遠隔操作を待機していたオペレータにドライバによる周囲状況の把握と同程度の把握を要求することは、オペレータによる単位時間当たりの業務処理量の減少や人件費の高騰に繋がるため望ましくない。また、複数のオペレータの中から１人のオペレータを選出してこれに遠隔操作を割り当てる場合は、そもそも、遠隔操作が必要であるとの判定がなされる以前に、遠隔操作が必要な移動体に関する情報を各オペレータが把握することが実質的に不可能であるという側面もある。

本開示の１つの目的は、遠隔操作を含む移動体の遠隔サービスを複数のオペレータによって提供する場合において、この遠隔サービスの円滑な運用を実現する技術を提供することにある。

本開示の第１の観点は、移動体を対象とする遠隔サービスを管理する方法であり、次の特徴を有する。
前記方法は、
前記遠隔サービスの業務の終了リクエストを受信した場合、前記終了リクエストを受け入れるか否かを判定するステップと、
前記終了リクエストの判定の結果を、前記終了リクエストを送信したオペレータの端末に送信するステップと、
を含む。
前記サービス業務は、前記提供対象の走行効率に影響を及ぼす第１業務と、前記走行効率に影響を及ぼさない第２業務と、を含む。
前記終了リクエストの判定ステップは、
前記終了リクエストが前記第２業務の終了リクエストの場合、当該第２業務の提供対象に対する前記第１業務の開始が予想されるか否かを判定するステップと、
前記第１業務の開始が予想されると判定された場合、前記第２業務の終了リクエストの受け入れを拒絶するステップと、
を含む。

本開示の第２の観点は、移動体を対象とする遠隔サービスを管理する装置であり、次の特徴を有する。
前記装置は、前記遠隔サービスを管理するプロセッサを含む。
前記プロセッサは、
前記遠隔サービスの業務の終了リクエストを受信した場合、前記終了リクエストを受け入れるか否かを判定する処理と、
前記終了リクエストの判定の結果を、前記終了リクエストを送信したオペレータの端末に送信する処理と、
を行うように構成されている。
前記遠隔サービスの業務は、前記遠隔サービスの提供対象の走行効率に影響を及ぼす第１業務と、前記走行効率に影響を及ぼさない第２業務と、を含む。
前記終了リクエストの受け入れを判定する処理において、前記プロセッサは、
前記終了リクエストが前記第２業務の終了リクエストの場合、当該第２業務の提供対象に対する前記第１業務の開始が予想されるか否かを判定する処理と、
前記第１業務の開始が予想されると判定された場合、前記第２業務の終了リクエストの受け入れを拒絶する処理と、
を行うように構成されている。

本開示によれば、遠隔サービスの業務の終了リクエストを受信した場合、この終了リクエストを受け入れるか否かが判定される。終了リクエストが遠隔サービスの提供対象の走行効率に影響を及ぼさない第２業務の終了リクエストの場合、この提供対象の走行効率に影響を及ぼす第１業務の開始が予想されるか否かが判定される。そして、第１業務の開始が予想されると判定された場合、第２業務の終了リクエストの受け入れが拒絶される。

第２業務の終了リクエストの受け入れが拒絶されれば、第２業務が継続される。そのため、近い将来において第１業務が発生したときに、第２業務に従事するオペレータにこの第１業務を割り当てることが可能となる。そのため、このオペレータによる提供対象の周囲状況等の把握に要する時間を短縮することが可能となる。従って、遠隔サービスを複数のオペレータによって提供する場合において、この遠隔サービスの円滑な運用に貢献することが期待される。

遠隔サービスを説明する概念図である。 オペレータにより操作される端末のディスプレイから出力される画像の例を示す図である。 オペレータにより操作される端末のディスプレイから出力される画像の別の例を示す図である。 車両に対する第１業務が割り当てられるときにディスプレイに表示される画像の例を、この割り当てが行われる前のオペレータの２種類の状態に対応させて説明する図である。 第２業務の終了リクエストが出力されたときにディスプレイに表示される画像の例を、この終了リクエストに対する２種類の応答態様に対応させて説明する図である。 実施形態に特に関連する管理サーバのプロセッサの第１の機能構成例を示すブロック図である。 管理サーバ（プロセッサ）による実施形態に特に関連する第１の処理の流れを示すフローチャートである。 実施形態に特に関連する管理サーバのプロセッサの第２の機能構成例を示すブロック図である。 管理サーバ（プロセッサ）による実施形態に特に関連する第２の処理の流れを示すフローチャートである。

以下、図面を参照しながら、本開示の実施形態に係る遠隔サービスの管理方法及び管理装置について説明する。尚、実施形態に係る管理方法は、実施形態に係る管理装置において行われるコンピュータ処理により実現される。また、各図において、同一又は相当する部分には同一符号を付してその説明を簡略化し又は省略する。

１．概要
１－１．遠隔サービス
図１は、遠隔サービスを説明する概念図である。図１には、管理サーバＭＳと、複数の車両ＶＨと、複数のオペレータＯＰと、が描かれている。

管理サーバＭＳは、実施形態に係る管理装置の一例である。管理サーバＭＳは、遠隔サービスを管理する。管理サーバＭＳは、典型的に、遠隔サービスの事業者によって管理される。管理サーバＭＳは、複数の車両ＶＨ及び複数のオペレータＯＰと通信する。

複数の車両ＶＨのそれぞれは、実施形態に係る移動体の一例である。複数の車両ＶＨのそれぞれは、遠隔サービスの提供対象である。複数の車両ＶＨの一部又は全部は、遠隔サービスの事業者が所有する車両でもよいし、この事業者との間で遠隔サービスの提供契約を行った法人又は個人が所有する車両でもよい。複数の車両ＶＨの総台数はＭ（Ｍ≧２）である。以下、説明の便宜上、複数の車両ＶＨのうちの任意の１台に言及する場合は「車両ＶＨｍ」と称す。車両ＶＨｍの構成は特に限定されないが、自律走行が可能な構成を有していることが望ましい。

複数のオペレータＯＰのそれぞれは、遠隔サービスの提供対象に対するサービス業務ＳＢ（Service Business）を行う。複数のオペレータＯＰは、遠隔サービスを提供する事業者の従業員でもよいし、この事業者との間で業務委託の契約を締結した法人の従業員又は個人でもよい。複数のオペレータＯＰの総人数はＮ（Ｎ≧２）である。以下、説明の便宜上、複数のオペレータＯＰのうちの任意の１人に言及する場合は「オペレータＯＰｎ」と称す。

１－２．サービス業務
オペレータＯＰｎが行うサービス業務ＳＢには、第１業務ＳＢ１及び第２業務ＳＢ２が含まれる。これらの業務は、例えば、その業務の実行が車両ＶＨｍの走行効率に影響を及ぼすか否かにより区別することができる。例えば、第１業務ＳＢ１は、走行効率に影響を及ぼすサービス業務ＳＢであり、第２業務ＳＢ２は走行効率に影響を及ぼさないサービス業務ＳＢである。ここでいう「走行効率」は、例えば、オペレータＯＰｎが行うサービス業務ＳＢの実行量に対する成果の割合であり、この成果としては、車両ＶＨｍが目的地点に到達する時刻が例示される。

第１業務ＳＢ１としては、操作業務（Operation business）が例示される。操作業務には、運転業務（Driving business）、指示業務（Command business）及び支援業務（Assistance business）が含まれる。運転業務は、車両ＶＨｍに搭載されたカメラ（以下、「車載カメラ」とも称す。）から取得された車両ＶＨｍの周囲画像をモニタしながら、車両ＶＨｍの走行に直接的又は間接的に関連する装置（例えば、車両ＶＨｍのステアリングホイール、ペダル、シフトレバー、ウィンカーなど）の操作を行う業務である。

指示業務は、車両ＶＨｍの走行に関連する装置の操作を目的とした業務ではない。ただし、指示業務では、車両ＶＨｍの走行に関連する情報が生成されて、車両ＶＨｍに提供される。例えば、車両ＶＨｍの前方に落下物があり、どのような走行を車両ＶＨｍが行うべきかの判断を下すことがオペレータＯＰｎに求められている場合を考える。この場合、落下物を認識したオペレータＯＰｎが「道なりに進め」、「障害物を避けて進め」等の指示情報を生成する業務は指示業務に含まれる。また、逆光等の理由から車両ＶＨｍによる交通信号機の認識が困難であり、この認識を行うことがオペレータＯＰｎに求められている場合を考える。この場合、交通信号機を認識したオペレータＯＰｎが「交通信号機は青信号である」という認識情報を生成する業務も指示業務に含まれる。

指示業務同様、支援業務では、車両ＶＨｍの走行に関連する情報が車両ＶＨｍに提供される。指示業務と異なり、支援業務では、オペレータＯＰｎ（人間）による運転経験や運転知識を考慮した情報が生成されて車両ＶＨｍに提供される。例えば、交通信号機の無い交差点において右折予定の車両ＶＨｍが、この交差点で右折予定の対向車と遭遇し、どのようなタイミングで右折を行うべきかの判断を下すことがオペレータＯＰｎに求められている場合を考える。この場合、対向車のドライバ又はこのドライバのジェスチャを認識したオペレータＯＰｎが「対向車が発進しそうなので対向車の右折を優先させる」、「対向車のドライバが譲っているので右折を先に行ってもよい」という支援情報を生成する業務は支援業務に含まれる。

第２業務ＳＢ２としては、監視業務が例示される。監視業務には、車載カメラから取得された車両ＶＨｍの周囲画像をモニタして、車両ＶＨｍの走行安全を確認する業務が含まれる。車載カメラには、車両Ｖｍの室内画像を取得するカメラが含まれていてもよい。この場合の監視業務には、車載カメラから取得された車両ＶＨｍの室内画像をモニタして、車両ＶＨｍの乗員（例えば、ドライバ）の状態を確認する業務が含まれる。尚、車載カメラから取得される各種の画像は典型的には動画であるが、静止画像でもよい。

監視業務には、車載カメラ以外の認識センサ（例えば、車両ＶＨｍに搭載されたＬｉＤＡＲ）から取得された周囲物体の可視化画像をモニタする業務が含まれてもよい。監視業務には、道路構造物（例えば、交差点に設置された交通信号機）に取り付けられたカメラから取得された交通流の画像、又は、カメラ以外の認識センサ（例えば、赤外線センサ）から取得された交通流の可視化画像をモニタして、車両ＶＨｍの走行安全を間接的に確認する業務が含まれてもよい。以下、道路構造物に取り付けられたカメラ及び認識センサを「インフラセンサ」と総称する。

監視業務には、車両ＶＨｍに搭載された状態センサ（例えば、加速度センサ、舵角センサ）から取得された車両ＶＨｍの走行情報をモニタする業務が含まれてもよい。監視業務には、車両ＶＨｍに搭載されたマイク（例えば、車外又は車室内マイク）から取得された車両ＶＨｍの音情報（例えば、車外音、乗員同士の会話）を聞く業務が含まれていてもよい。

第１及び第２業務ＳＢ１及びＳＢ２においてオペレータＯＰによりモニタされる車載カメラ、認識センサ等の画像は、オペレータＯＰｎにより操作される端末のディスプレイＤＰｎから出力される。図２は、オペレータＯＰ１により操作される端末のディスプレイＤＰ１から出力される画像ＩＭＧ１の例を示す図である。図２に示される例では、画像ＩＭＧ１が画像ＩＭ＿ＣＦ１を含んでいる。画像ＩＭ＿ＣＦ１は、車両ＶＨ１の車載カメラにより取得された車両ＶＨ１の中央前方の画像である。

また、画像ＩＭ＿ＣＦ１の左方の部分には画像ＩＭ＿ＬＦ１が重畳されており、画像ＩＭ＿ＣＦ１の右方の部分には画像ＩＭ＿ＲＦ１が重畳されている。画像ＩＭ＿ＬＦ１は、車両ＶＨ１の車載カメラにより取得された車両ＶＨ１の左前方の画像であり、画像ＩＭ＿ＲＦ１は、車両ＶＨ１の車載カメラにより取得された車両ＶＨ１の右前方の画像である。また、画像ＩＭ＿ＣＦ１の上方の一部には画像ＩＭ＿ＣＲ１が重畳されている。画像ＩＭ＿ＣＲ１は、車両ＶＨ１の車載カメラにより取得された車両ＶＨ１の中央後方の画像である。

図２に示される画像ＩＭＧ１は、オペレータＯＰ１が第１業務ＳＢ１を行うときにディスプレイＤＰ１から出力される画像例に相当する。尚、画像ＩＭＧ１には、図２に示した画像以外の車両ＶＨ１の周囲画像（例えば、車両ＶＨ１の側方の画像）が含まれていてもよい。また、ディスプレイＤＰ１は、２台以上のディスプレイから構成されていてもよい。この場合、画像ＩＭ＿ＬＦ１、ＩＭ＿ＲＦ１及びＩＭ＿ＣＲ１は、画像ＩＭ＿ＣＦ１が出力されるディスプレイとは別のディスプレイから出力されてもよい。

図３は、オペレータＯＰ１により操作される端末のディスプレイＤＰ１から出力される画像ＩＭＧ１の別の例を示す図である。図３に示される画像ＩＭＧ１は、オペレータＯＰ１が第２業務ＳＢ２を行うときにディスプレイＤＰ１から出力される画像例に相当する。図３に示される例では、ディスプレイＤＰ１の表示領域が４つに分けられ、各領域に画像ＩＭ＿ＣＦ１～ＩＭ＿ＣＦ４がそれぞれ出力されている。画像ＩＭ＿ＣＦ２～ＩＭ＿ＣＦ４は、車両ＶＨ２～ＶＨ４の車載カメラにより取得されたこれらの車両の中央前方の各画像である。

図３から分かるように、第２業務ＳＢ２には、２台以上の車両ＶＨの周囲画像をモニタして、これらの車両ＶＨの走行安全を同時並行で確認する業務が含まれる。この理由は、車両ＶＨｍの第１業務ＳＢ１を担当するオペレータＯＰｎは、この第１業務ＳＢ１に集中することが期待され、又は、この第１業務ＳＢ１以外のサービス業務ＳＢに従事することが禁止されるのに対し、第２業務ＳＢ２ではそのような制約が少ないためである。尚、図３に示した例は一例であり、オペレータＯＰｎによる第２業務ＳＢ２の最中に、１台の車両に関する情報（つまり、車両ＶＨｍに関する情報）のみがディスプレイＤＰｎから出力されていてもよい。

１－３．サービス業務ＳＢの開始トリガ
オペレータＯＰｎによるサービス業務ＳＢは、トリガの出力に伴い開始される。サービス業務ＳＢの開始トリガＴＲＧの出力源としては、車両ＶＨｍ、オペレータＯＰｎ、管理サーバＭＳ及び任意の予測機が例示される。以下では、これらの出力源及びこれらの出力源における開始トリガＴＲＧの出力例を説明する。

車両ＶＨｍは、車両ＶＨｍの周囲画像に含まれる物体の認識を行う。また、車両ＶＨｍは、認識された物体の動作の検出を行う。例えば、周囲画像に含まれる物体の認識が困難な場合、車両ＶＨｍは管理サーバＭＳに対し、この物体の認識を行うことを要求する。このとき、開始トリガＴＲＧが出力される。別の例では、物体の認識は行われたが、この物体の不自然な動作が検出された場合、車両ＶＨｍは管理サーバＭＳに対し、この物体の状態の確認を行うことを要求する。このときにも開始トリガＴＲＧが出力される。

車両ＶＨｍは、車両ＶＨｍの室内画像に含まれる乗員（ドライバ）の状態の認識を行ってもよい。そして、ドライバの異常状態が認識された場合、車両ＶＨｍは管理サーバＭＳに対し、この異常状態の確認を行うことを要求してもよい。このときにも開始トリガＴＲＧが出力される。車両ＶＨｍは、車載カメラ以外の認識センサからの情報に基づいて、車両ＶＨｍの周囲の物体の動作の検出を行ってもよい。そして、この物体の不自然な動作が検出された場合、車両ＶＨｍは管理サーバＭＳに対し、この物体の状態の確認を行うことを要求してもよい。このときにも開始トリガＴＲＧが出力される。

サービス業務ＳＢを待機しているオペレータＯＰｎは、任意のタイミングで車両ＶＨｍに対する第２業務ＳＢ２を開始する。任意のタイミングとしては、オペレータＯＰｎがサービス業務ＳＢを開始するタイミングが例示される。任意のタイミングの別の例としては、オペレータＯＰｎによる車両ＶＨｍに対する第１業務ＳＢ１が終了したタイミングも挙げられる。このような場合、オペレータＯＰｎは管理サーバＭＳに対し第２業務ＳＢ２の要求を行う。このとき、開始トリガＴＲＧが出力される。

第２業務ＳＢ２に従事している間、オペレータＯＰｎは、ディスプレイＤＰｎから出力された少なくとも１台の車両の周囲画像をモニタする。オペレータＯＰｎは、また、周囲画像以外の情報（例えば、室内画像、認識センサ情報、交通流画像、走行情報）をモニタしてもよい。オペレータＯＰｎは、更に、スピーカから出力された少なくとも１台の車両に関する情報（即ち、音情報）を聞くことができる。そして、第２業務ＳＢ２の最中、ある１台の車両に対する第１業務ＳＢ１が必要であるとオペレータＯＰｎが判断した場合、オペレータＯＰｎは管理サーバＭＳに対しこのサービス業務ＳＢの要求を行う。このとき、開始トリガＴＲＧが出力される。

開始トリガＴＲＧの出力は、管理サーバＭＳにおいて検出することができる。例えば、車両ＶＨｍが出力源の場合、この車両ＶＨｍからのサービス業務ＳＢの要求信号を管理サーバＭＳが受信することで開始トリガＴＲＧが検出される。第２業務ＳＢ２に従事するオペレータＯＰｎが出力源の場合、このオペレータＯＰｎからの第１業務ＳＢ１の要求信号を管理サーバＭＳが受信することで開始トリガＴＲＧが検出される。

管理サーバＭＳは、車両ＶＨｍの車載カメラの画像（例えば、周囲画像、室内画像）を適宜取得することができる。そのため、車両ＶＨｍが有する物体認識機能や、ドライバ状態認識機能が付与されている場合、管理サーバＭＳは、車両ＶＨｍの周囲画像に含まれる物体の認識、この認識された物体の動作の検出や、車両ＶＨｍのドライバの状態の認識を行うことができる。管理サーバＭＳは、また、車載カメラの画像以外の情報（例えば、認識センサ情報、交通流画像、走行情報、音情報）を適宜取得することができる。そのため、サービス業務ＳＢの開始判断機能が付与された場合、管理サーバＭＳは能動的に開始トリガＴＲＧを出力することができる。

管理サーバＭＳは、車両ＶＨｍの稼働中、所定時間が経過するたびに車両ＶＨｍに対する第２業務ＳＢ２の開始トリガＴＲＧを出力してもよい。管理サーバＭＳは、また、車両ＶＨｍの稼働中、車両ＶＨｍの累積走行距離が区切りとなる距離に到達するたびに車両ＶＨｍに対する第２業務ＳＢ２の開始トリガＴＲＧを出力してもよい。管理サーバＭＳは、また、車両ＶＨｍの稼働の開始時又は停止時に、車両ＶＨｍの各種装置の動作確認（例えば、ライトの点灯確認）のために第１業務ＳＢ１の開始トリガＴＲＧを出力してもよい。管理サーバＭＳは、更に、車両ＶＨｍの稼働の開始時又は停止時に、車両ＶＨｍの各種状態の確認（タイヤ空気圧の確認、オイル確認、バッテリ確認、走行距離確認、外観確認）のために第２業務ＳＢ２の開始トリガＴＲＧを出力してもよい。

任意の予測機は、例えば、管理サーバＭＳの内部に形成される。任意の予測機は、管理サーバＭＳの外部に形成されてもよい。任意の予測機は、サービス業務ＳＢの提供履歴（時間帯及び場所）を用いた機械学習により、車両ＶＨｍに対するサービス業務ＳＢの発生を予測する。任意の予測機は、サービス業務ＳＢの提供履歴を用いた機械学習により、インフラセンサが着目する地点でのサービス業務ＳＢの発生を予測してもよい。インフラセンサが着目する地点は、例えば、インフラセンサの検知範囲と地図情報とから設定される。サービス業務ＳＢの発生が予測された場合、管理サーバＭＳの内部に形成された任意の予測機は、開始トリガＴＲＧを出力する。管理サーバＭＳの外部に形成された任意の予測機は、開始トリガＴＲＧに相当する信号を管理サーバＭＳに送信する。

以下、説明の便宜上、車両ＶＨｍに対する第１業務ＳＢ１の開始トリガＴＲＧを「開始トリガＴＲＧ＿ＳＢ１」とも称し、車両ＶＨｍに対する第２業務ＳＢ２の開始トリガＴＲＧを「開始トリガＴＲＧ＿ＳＢ２」とも称す。

１－４．サービス業務ＳＢの終了リクエスト
オペレータＯＰｎによるサービス業務ＳＢは、このサービス業務ＳＢを開始した原因の消失、解消等に伴いその終了を迎える。又は、オペレータＯＰｎによる能動的な意思表示によって、このオペレータＯＰｎによるサービス業務ＳＢの終了を迎える。所定時間が経過するたびに開始される第２業務ＳＢ２は、この業務に対するオペレータＯＰｎの従事時間が事前に設定された時間に到達することでその終了を迎える。

サービス業務ＳＢがその終了を迎えた場合、サービス業務ＳＢの終了リクエストＲＦＣ（Request For Close）が出力される。終了リクエストＲＦＣの出力源としては、車両ＶＨｍ、オペレータＯＰｎ及び管理サーバＭＳが例示される。つまり、終了リクエストＲＦＣの出力源としては、任意の予測機以外の開始トリガＴＲＧの出力源が例示される。

例えば、サービス業務ＳＢの対象（以下、「車両ＶＨ＿ＳＢ」とも称す。）は、サービス業務ＳＢを開始した原因の消失、解消等に伴いこのサービス業務ＳＢの終了リクエストＲＦＣを出力する。サービス業務ＳＢを開始した原因の消失の例としては、車両ＶＨｍの室内で立ち上がった乗客が認識されたことに伴いサービス業務ＳＢ（第２業務ＳＢ２）が開始された場合において、この乗客の着席が認識されたことが挙げられる。サービス業務ＳＢを開始した原因の消失の別の例としては、インフラセンサが着目する地点でのサービス業務ＳＢ（第２業務ＳＢ２）が開始された場合において、インフラセンサの画角の範囲から車両ＶＨ＿ＳＢから外れたことが挙げられる。

サービス業務ＳＢを開始した原因の解消の例としては、車両ＶＨｍの横方向への大きな移動量が検出されたことが原因でサービス業務ＳＢ（第２業務ＳＢ２）が開始された場合において、オペレータＯＰｎによって車両ＶＨ＿ＳＢの行動に問題がない（例えば、複数台の路上駐車車両を避ける車両動作）ことが確認されたことが挙げられる。

２．実施形態の特徴
車両ＶＨｍに対するサービス業務ＳＢの開始トリガＴＲＧが出力された場合、管理サーバＭＳは、このサービス業務ＳＢを割り当てるオペレータＯＰｎを複数のオペレータＯＰのうちから選出する。以下、説明の便宜上、サービス業務ＳＢが割り当てられたオペレータＯＰｎを「オペレータＯＰ＿ＳＢ」とも称す。また、第１業務ＳＢ１が割り当てられているオペレータＯＰｎを「オペレータＯＰ＿ＳＢ１」とも称し、第２業務ＳＢ２が割り当てられているオペレータＯＰｎを「オペレータＯＰ＿ＳＢ２」とも称す。

ここで、車両ＶＨｍに対する開始トリガＴＲＧ＿ＳＢ１が出力されたときに、オペレータＯＰ＿ＳＢ１の候補がモニタしているディスプレイＤＰｎを考える。オペレータＯＰ＿ＳＢ１の候補としては、サービス業務ＳＢへの従事を待機しているオペレータＯＰｎと、第２業務ＳＢ２に従事しているオペレータＯＰｎ（つまり、オペレータＯＰ＿ＳＢ２）とが想定される。前者は、開始トリガＴＲＧ＿ＳＢ１に応じて行う第１業務ＳＢ１を、新規のサービス業務ＳＢとして受け入れ可能な状態のオペレータＯＰｎである。後者は、現在従事している第２業務ＳＢ２から、開始トリガＴＲＧ＿ＳＢ１に応じて行う第１業務ＳＢ１への切り替えが可能な状態のオペレータＯＰｎである。

図４に示される“ＣＡＳＥ１”は、サービス業務ＳＢへの従事を待機しているオペレータＯＰｎに対し、車両ＶＨ３に対する第１業務ＳＢ１が割り当てられるときにディスプレイＤＰｎから出力される画像ＩＭＧｎの例である。図４に示される“ＣＡＳＥ２”は、車両ＶＨ３に対する第２業務ＳＢ２に従事しているオペレータＯＰｎに対し、この車両ＶＨ３に対する第１業務ＳＢ１が割り当てられるときにディスプレイＤＰｎから出力される画像ＩＭＧ１の例である。

“ＣＡＳＥ１”と“ＣＡＳＥ２”を比較すると、前者よりも後者の方が車両ＶＨ３の周囲状況等の早期把握が期待される。この理由は、車両ＶＨ３に対する第１業務ＳＢ１が割り当てられる前においてオペレータＯＰｎは既にこの車両ＶＨ３に対する第２業務ＳＢ２に従事しているので、車両ＶＨ３の周囲状況等の把握に時間を要しないためである。

このような観点に基づき、実施形態では、車両ＶＨｍに対する第１業務ＳＢ１の開始トリガＴＲＧ＿ＳＢ１が出力された場合、この車両ＶＨｍに対する第２業務ＳＢ２に既に従事しているオペレータＯＰｎが存在するか否かが判定される。そして、車両ＶＨｍに対する第２業務ＳＢ２に既に従事しているオペレータＯＰｎが存在すると判定された場合、このオペレータＯＰｎに第１業務ＳＢ１が優先的に割り当てられる。このような優先割り当てが行われることは、遠隔サービスの円滑な運用に貢献することが期待される。

ここで課題となるのが、車両ＶＨｍに対する第１業務ＳＢ１の開始トリガＴＲＧ＿ＳＢ１が出力される直前までこの車両ＶＨｍに対する第２業務ＳＢ２に従事していたオペレータＯＰｎが存在していた場合である。終了リクエストＲＦＣの出力は、開始トリガＴＲＧの出力同様、管理サーバＭＳにおいて検出される。終了リクエストＲＦＣが検出された場合、管理サーバＭＳは、この終了リクエストＲＦＣを受け入れる。そして、管理サーバＭＳは、終了リクエストＲＦＣに対応する車両ＶＨｍに対するサービス業務ＳＢを終了して、このサービス業務ＳＢに従事しているオペレータＯＰｎにより操作される端末に終了リクエストＲＦＣの許可情報を送信する。

そのため、車両ＶＨｍに対する第２業務ＳＢ２の対象（以下、「車両ＶＨ＿ＳＢ２」とも称す。）、又は、この車両ＶＨｍに対する第２業務ＳＢ２に従事していたオペレータＯＰｎから終了リクエストＲＦＣが出力されると、この第２業務ＳＢ２からオペレータＯＰｎが外されてしまう。図５に示される“ＣＡＳＥ３”は、第２業務ＳＢ２に対する終了リクエストＲＦＣ（以下、「終了リクエストＲＦＣ＿ＳＢ２」とも称す。）を受け入れるときにディスプレイＤＰｎから出力される画像ＩＭＧｎの例である。この例では、終了リクエストＲＦＣ＿ＳＢ２の受け入れに伴い、サービス業務ＳＢへの従事を待機する画像ＩＭＧｎに切り替わっている。

そうすると、車両ＶＨｍに対する第２業務ＳＢ２からの開放の直後にこの車両ＶＨｍに対する第１業務ＳＢ１の開始トリガＴＲＧ＿ＳＢ１が出力されたときに、上述した優先割り当てを行うことができない。そこで、実施形態では、車両ＶＨｍに対する終了リクエストＲＦＣ＿ＳＢ２の出力が検出された場合、任意の予測機の機能を活用してこの車両ＶＨｍに対する第１業務ＳＢ１の開始が予想されるか否かを判定する。そして、この第１業務ＳＢ１の開始が予想されると判定された場合、終了リクエストＲＦＣ＿ＳＢ２の受け入れを拒絶する。

図５に示される“ＣＡＳＥ４”は、終了リクエストＲＦＣ＿ＳＢ２の受け入れが拒絶されるときにディスプレイＤＰｎから出力される画像ＩＭＧｎの例である。この例では、終了リクエストＲＦＣ＿ＳＢ２の受け入れの拒絶に伴い、終了リクエストＲＦＣ＿ＳＢ２の出力の前と同じ画像ＩＭＧｎがディスプレイＤＰｎから出力される。そのため、“ＣＡＳＥ４”では、近い将来において車両ＶＨｍに対する開始トリガＴＲＧ＿ＳＢ１が出力されたときに、終了リクエストＲＦＣ＿ＳＢ２の受け入れを拒絶したオペレータにこの車両ＶＨｍに対する第１業務ＳＢ１を優先的に割り当てることが可能となる。

以下、実施形態に係る管理方法及び管理装置について詳細に説明する。

３．遠隔サービスの管理装置
３－１．第１構成例
図６は、実施形態に特に関連する管理サーバＭＳのプロセッサ１０の第１の機能構成例を示すブロック図である。図６に示される例では、プロセッサ１０が、状態情報取得部１１と、第１トリガ出力判定部１２と、割り当て方法設定部１３と、第１業務割り当て部１４と、第１業務付与部１５と、を備えている。これらのブロックの各機能は、プロセッサ１０が遠隔サービスプログラムを実行することにより実現される。

状態情報取得部１１は、複数の車両ＶＨ及び複数のオペレータＯＰの現在状態に関する情報を取得する。複数の車両ＶＨの現在状態に関する情報には、例えば、稼働状態の情報と、サービス業務ＳＢの提供状態の情報と、が含まれる。稼働状態は、車両ＶＨｍの駆動源（例えば、電動機、エンジン）が稼働されている状態と、そうでない状態とに分けられる。提供状態は、サービス業務ＳＢが提供されている状態と、そうでない状態とに分けられる。車両ＶＨｍに対してサービス業務ＳＢが提供されている場合、提供中のサービス業務ＳＢの種類（つまり、第１業務ＳＢ１及び第２業務ＳＢ２）の情報が、提供状態の情報に追加される。

複数のオペレータＯＰの現在状態に関する情報には、サービス業務ＳＢへの従事状態の情報が含まれる。従事状態は、サービス業務ＳＢへの従事を待機している状態と、サービス業務ＳＢに従事している状態とに分けられる。オペレータＯＰｎがサービス業務ＳＢに従事している場合、従事中のサービス業務ＳＢの種類（つまり、第１業務ＳＢ１及び第２業務ＳＢ２）の情報が現在状態に関する情報に追加される。オペレータＯＰｎがサービス業務ＳＢに従事している場合、このサービス業務ＳＢの対象（つまり、車両ＶＨ＿ＳＢ）の固有情報（例えば、ＩＤ情報）が、従事状態の情報に追加される。尚、図３の説明から理解されるように、第２業務ＳＢ２の対象（つまり、車両ＶＨ＿ＳＢ２）の総台数は少なくとも１である。

状態情報取得部１１は、これが取得した現在状態に関する情報を割り当て方法設定部１３及び第１業務割り当て部１４に送信する。

第１トリガ出力判定部１２は、車両ＶＨｍに対する開始トリガＴＲＧ＿ＳＢ１が出力されたか否かを判定する。既に説明したように、開始トリガＴＲＧの出力源は、車両ＶＨｍ、オペレータＯＰｎ、管理サーバＭＳ及び任意の予測機を含んでいる。第１トリガ出力判定部１２は、開始トリガＴＲＧ＿ＳＢ１の出力が検出された場合、この開始トリガＴＲＧ＿ＳＢ１を出力させた車両（以下、「車両ＶＨ＿ＴＲＧ＿ＳＢ１」とも称す。）の固有情報（例えば、ＩＤ情報）を割り当て設定部１３に送信する。

割り当て方法設定部１３は、状態情報取得部１１から受信した複数の車両ＶＨの現在状態に関する情報と、第１トリガ出力判定部１２から受信した車両ＶＨ＿ＴＲＧ＿ＳＢ１の固有情報とに基づいて、この車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１の割り当て方法を設定する。具体的に、割り当て方法設定部１３は、車両ＶＨ＿ＴＲＧ＿ＳＢ１が現在における第２業務ＳＢ２の対象（つまり、車両ＶＨ＿ＳＢ２）に含まれるか否かを判定する。この判定は、車両ＶＨ＿ＴＲＧ＿ＳＢ１の固有情報と、車両ＶＨ＿ＳＢ２のそれとを照合することにより行われる。

車両ＶＨ＿ＴＲＧ＿ＳＢ１が車両ＶＨ＿ＳＢ２に含まれると判定された場合、割り当て方法として「優先割り当て」が設定される。そうでないと判定された場合、割り当て方法として「通常割り当て」が設定される。割り当て方法設定部１３は、設定した割り当て方法の情報と、車両ＶＨ＿ＴＲＧ＿ＳＢ１の固有情報とを第１業務割り当て部１４に送信する。

第１業務割り当て部１４は、状態情報取得部１１から受信した複数のオペレータＯＰの現在状態に関する情報と、割り当て方法設定部１３から受信した割り当て方法の情報及び車両ＶＨ＿ＴＲＧ＿ＳＢ１の固有情報と、に基づいて、車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１を担当するオペレータＯＰｎを選出する。

割り当て方法として「優先割り当て」が設定されている場合を考える。この場合、複数のオペレータＯＰの現在状態に関する情報と、車両ＶＨ＿ＴＲＧ＿ＳＢ１の固有情報とに基づいて、車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第２業務ＳＢ２に既に従事しているオペレータＯＰ＿ＳＢ２が特定される。車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１を担当するオペレータＯＰ＿ＳＢ１には、この特定されたオペレータＯＰ＿ＳＢ２が選出される。車両ＶＨｍに対する第２業務ＳＢ２の終了リクエストの拒絶に伴い、この車両ＶＨｍに対する第１業務ＳＢ１の開始を待機しているオペレータがいる場合、このオペレータが特定される。車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１を担当するオペレータＯＰ＿ＳＢ１には、この特定されたオペレータＯＰ＿ＳＢ２が選出されることが望ましい。

割り当て方法として「通常割り当て」が設定されている場合を考える。この場合は、例えば、複数のオペレータＯＰの現在状態に関する情報に基づいて、サービス業務ＳＢの待機中の複数のオペレータＯＰがオペレータＯＰ＿ＳＢ１の候補に設定される。そして、車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１を担当するオペレータが、この候補の内から選出される。

尚、「通常割り当て」が設定されている場合におけるオペレータＯＰ＿ＳＢ１の選出手法には公知の手法を適用することができる。例えば、公知の手法に従い、オペレータＯＰ＿ＳＢ１の候補によるサービス業務ＳＢの待機時間の長さ（稼働率）、サービス業務ＳＢの熟練度（経験回数）等に基づいて候補の絞り込みが行われてもよい。

第１業務付与部１５は、第１業務割り当て部１４によって選出されたオペレータＯＰ＿ＳＢ１により操作される端末に、車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１の開始に必要な情報を送信する。第１業務ＳＢ１の開始に必要な情報としては、車両ＶＨ＿ＴＲＧ＿ＳＢ１の周囲画像が例示される。

第１業務付与部１５は、また、この端末に、車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第２業務ＳＢ２から、この車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１に移行したことを通知する情報を送信する。第１業務付与部１５は、更に、車両ＶＨ＿ＴＲＧ＿ＳＢ１の走行に関連する装置の操作（例えば、ステアリングホイール、ペダル、シフトレバー、ウィンカーなど）を有効にする情報をこの端末に送信する。

第１業務付与部１５は、また更に、第１業務割り当て部１４によってオペレータＯＰ＿ＳＢ１が選出された場合、このオペレータＯＰ＿ＳＢ１の現在状態に関する情報を更新する。具体的には、従事中のサービス業務ＳＢの種類の情報が更新される。第１業務付与部１５は、また更に、オペレータＯＰ＿ＳＢ１による第１業務ＳＢ１が開始された場合、複数の車両ＶＨの現在状態に関する情報を更新する。具体的には、提供中のサービス業務ＳＢの種類の情報が更新される。

３－２．第１処理例
図７は、管理サーバＭＳ（プロセッサ１０）による実施形態に特に関連する第１の処理の流れを示すフローチャートである。図７に示されるルーチンは、例えば、所定の制御周期で繰り返し実行される。

図７に示されるルーチンでは、まず、開始トリガＴＲＧ＿ＳＢ１が出力されたか否かが判定される（ステップＳ１１）。例えば、開始トリガＴＲＧの出力源から所定信号をプロセッサ１０が受信した場合、開始トリガＴＲＧ＿ＳＢ１が出力されたと判定される。ステップＳ１１の判定結果が否定的な場合、今回の処理が終了する。

ステップＳ１１の判定結果が肯定的な場合、複数の車両ＶＨ及び複数のオペレータＯＰの現在状態に関する情報が取得される（ステップＳ１２）。現在状態に関する情報は、例えば、管理サーバＭＳのデータベースに格納されており、プロセッサ１０はここから最新の情報を取得する。

ステップＳ１２の処理に続いて、開始トリガＴＲＧ＿ＳＢ１を出力させた車両（つまり、車両ＶＨ＿ＴＲＧ＿ＳＢ１）が、現在における第２業務ＳＢ２の対象（つまり、車両ＶＨ＿ＳＢ２）に含まれるか否かが判定される（ステップＳ１３）。ステップＳ１３の判定は、例えば、車両ＶＨ＿ＴＲＧ＿ＳＢ１の固有情報と、車両ＶＨ＿ＳＢ２のそれとを照合することにより行われる。

ステップＳ１３の判定結果が肯定的な場合、車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第２業務ＳＢ２に従事しているオペレータＯＰ＿ＳＢ２に、この車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１が割り当てられる（ステップＳ１４）。一方、ステップＳ１３の判定結果が否定的な場合、公知の手法に従い第１業務ＳＢ１の割り当てが行われる（ステップＳ１５）。ステップＳ１５では、例えば、サービス業務ＳＢの待機中の複数のオペレータＯＰをオペレータＯＰ＿ＳＢ１の候補とし、この候補の内から１人のオペレータが選出される。そして、選出されたオペレータに対し、車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１が割り当てられる。

ステップＳ１４又はＳ１５の処理に続いて、車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１の実施指令が、選出されたオペレータのコンピュータに送信される（ステップＳ１６）。この実施指令には、第１業務ＳＢ１の開始に必要な情報、この第１業務ＳＢ１に移行したことを通知する情報、及び、車両ＶＨ＿ＴＲＧ＿ＳＢ１の走行に関連する装置の操作を有効にする情報が含まれる。

３－３．第２構成例
図８は、実施形態に特に関連する管理サーバＭＳのプロセッサ１０の第２の機能構成例を示すブロック図である。図８に示される例では、プロセッサ１０が、状態情報取得部１１に加えて、第２リクエスト出力判定部１６と、第１業務開始予想部１７と、リクエスト許諾判定部１８と、第２リクエスト応答部１９と、を備えている。これらのブロックの各機能は、プロセッサ１０が遠隔サービスプログラムを実行することにより実現される。

第２リクエスト出力判定部１６は、第２業務ＳＢ２に対する終了リクエストＲＦＣ（以下、「終了リクエストＲＦＣ＿ＳＢ２」とも称す。）が出力されたか否かを判定する。既に説明したように、終了リクエストＲＦＣの出力源は、車両ＶＨｍ、オペレータＯＰｎ及び管理サーバＭＳを含んでいる。第２リクエスト出力判定部１６は、終了リクエストＲＦＣ＿ＳＢ２の出力が検出された場合、この終了リクエストＲＦＣ＿ＳＢ２を出力させた車両（以下、「車両ＶＨ＿ＲＦＣ＿ＳＢ２」とも称す。）の固有情報（例えば、ＩＤ情報）をリクエスト許諾判定部１８に送信する。

第１業務開始予想部１７は、状態情報取得部１１から受信した複数の車両ＶＨの現在状態に関する情報に基づいて、車両ＶＨｍに対する第１業務ＳＢ１の開始を予想する。この予想を行うための情報としては、車両ＶＨｍの位置、速度、加速度といった車両状態に関する情報、車両ＶＨｍが現在走行している車線、将来走行する予定の車線といったルート情報、車両ＶＨｍに対する第１業務ＳＢ１の提供履歴情報などが例示される。これらの情報は、現在状態に関する情報に追加されている。車両ＶＨｍがバスなどのライドシェア車両の場合は、運行スケジュール（ルート、停留所の位置、停留所への到着時刻、停留所での停留時間など）の情報が現在状態に関する情報に追加されていることが望ましい。

現在状態に関する情報には、更に、時刻情報や車両ＶＨｍの周囲の気象情報（例えば、天気、気温、風速など）が追加されていることが望ましい。時刻情報や気象情報によれば、車両ＶＨｍの周囲の物体の認識の精度が低下することを予測することができ、故に、第１業務ＳＢ１の開始を予想することが可能となる。また、現在状態に関する情報には、車両ＶＨｍの周囲の交通情報（例えば、渋滞情報）が追加されていることが望ましい。交通情報によれば、オペレータＯＰｎ（人間）による運転経験や運転知識に基づいた判断が求められるケースが発生することを予測することができ、故に、第１業務ＳＢ１の開始を予想することが可能となる。

第１業務開始予想部１７は、車両ＶＨｍに対する第１業務ＳＢ１の開始が予想された場合、この第１業務ＳＢ１の開始が予想される時刻の情報を生成し、リクエスト許諾判定部１８に送信する。

リクエスト許諾判定部１８は、車両ＶＨ＿ＲＦＣ＿ＳＢ２の固有情報を第２リクエスト出力判定部１６から受信した場合、この車両ＶＨ＿ＲＦＣ＿ＳＢ２に対する第２業務ＳＢ２の終了リクエストＲＦＣ＿ＳＢ２を許諾するか否かを判定する。この判定では、例えば、車両ＶＨ＿ＲＦＣ＿ＳＢ２に対する第１業務ＳＢ１の開始が予想される時刻の情報の有無が判定される。予想時刻の情報が無い場合は、終了リクエストＲＦＣ＿ＳＢ２が許諾される。一方、予想時刻の情報がある場合は、この予想時刻と、車両ＶＨ＿ＲＦＣ＿ＳＢ２の固有情報を受信した時刻との時間差が計算される。

この時間差は、将来発生する第１業務ＳＢ１の開始をオペレータＯＰｎが待機する時間に相当する。実施形態では、オペレータＯＰｎが許容可能な待機時間に相当する閾値が設定される。そして、時間差が閾値（例えば、数秒～数十秒）以下の場合、終了リクエストＲＦＣ＿ＳＢ２が拒絶される。リクエスト許諾判定部１８は、終了リクエストＲＦＣ＿ＳＢ２の許諾判定の結果を第２リクエスト応答部１９に送信する。

第２リクエスト応答部１９は、リクエスト許諾判定部１８から受信した終了リクエストＲＦＣ＿ＳＢ２の許諾判定の結果に基づいて、終了リクエストＲＦＣ＿ＳＢ２に対応する第２業務ＳＢ２に従事しているオペレータＯＰｎに送信する情報を生成する。第２リクエスト応答部１９により生成される情報は、許可情報又は拒絶情報である。許可情報には、終了リクエストＲＦＣ＿ＳＢ２を受け入れる旨の情報が少なくとも含まれる。許可情報には、サービス業務ＳＢを待機するために必要な情報、又は、車両ＶＨ＿ＲＦＣ＿ＳＢ２に対する第２業務ＳＢ２以外のサービス業務ＳＢの開始に必要な情報が含まれてもよい。

拒絶情報には、終了リクエストＲＦＣ＿ＳＢ２の受け入れを拒絶する情報が少なくとも含まれる。拒絶情報には、終了リクエストＲＦＣ＿ＳＢ２の受け入れを待機する時間の情報が含まれていてもよい。尚、この待機時間としては、リクエスト許諾判定部１８において計算された時間差に所定マージンを加えた時間が考えられる。

３－４．第２処理例
図９は、管理サーバＭＳ（プロセッサ１０）による実施形態に特に関連する第２の処理の流れを示すフローチャートである。図７で説明したルーチン同様、図９に示されるルーチンは所定の制御周期で繰り返し実行される。

図９に示されるルーチンでは、まず、終了リクエストＲＦＣ＿ＳＢ２が出力されたか否かが判定される（ステップＳ２１）。例えば、終了リクエストＲＦＣ＿ＳＢ２の出力源から所定信号をプロセッサ１０が受信した場合、終了リクエストＲＦＣ＿ＳＢ２が出力されたと判定される。ステップＳ１１の判定結果が否定的な場合、今回の処理が終了する。

ステップＳ２１の判定結果が肯定的な場合、車両ＶＨ＿ＲＦＣ＿ＳＢ２の現在状態に関する情報が取得される（ステップＳ２２）。現在状態に関する情報は、例えば、管理サーバＭＳのデータベースに格納されており、プロセッサ１０はここから最新の情報を取得する。

ステップＳ２２の処理に続いて、終了リクエストＲＦＣ＿ＳＢ２を出力させた車両（つまり、車両ＶＨ＿ＲＦＣ＿ＳＢ２）に対する第１業務ＳＢ１の開始が予想される（ステップＳ２３）。車両ＶＨ＿ＲＦＣ＿ＳＢ２に対する第１業務ＳＢ１の開始の予想は、ステップＳ２２で取得された車両ＶＨ＿ＲＦＣ＿ＳＢ２の現在状態に関する情報に基づいて行われる。尚、現在状態に関する情報の例については、第１業務開始予想部１７の説明において述べたものが挙げられる。第１業務ＳＢ１の開始が予想された場合、この第１業務ＳＢ１の開始が予想される時刻の情報が生成される。

ステップＳ２３の処理に続いて、現在時刻ｔｃと、第１業務ＳＢ１の開始が予想される時刻ｔｅとの時間差が閾値ＴＨ以下であるか否かが判定される（ステップＳ２４）。現在時刻ｔｃは、終了リクエストＲＦＣ＿ＳＢ２の出力源から所定信号をプロセッサ１０が受信した時刻でもよい。予想時刻ｔｅの情報が無い場合、又は、時間差が閾値を上回ると判定された場合、ステップＳ２５の処理が行われる。時間差が閾値以下であると判定された場合、ステップＳ２６の処理が行われる。

ステップＳ２５の処理では、終了リクエストＲＦＣ＿ＳＢ２に対する許可情報が生成される。許可情報には、終了リクエストＲＦＣ＿ＳＢ２を受け入れる旨の情報が少なくとも含まれる。ステップＳ２６の処理では、拒絶情報が生成される。拒絶情報には、終了リクエストＲＦＣ＿ＳＢ２の受け入れを拒絶する情報が少なくとも含まれる。許可情報又は拒絶情報は、車両ＶＨ＿ＲＦＣ＿ＳＢ２に対する第２業務ＳＢ２に従事するオペレータＯＰｎの端末に送信される。

４．効果
以上説明した実施形態によれば、車両ＶＨｍに対する開始トリガＴＲＧ＿ＳＢ１が出力された場合において、車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第２業務ＳＢ２に既に従事しているオペレータＯＰｎが存在するときは、車両ＶＨ＿ＴＲＧ＿ＳＢ１に対する第１業務ＳＢ１がこのオペレータＯＰｎに割り当てられる。そのため、このオペレータＯＰによる車両ＶＨ＿ＴＲＧ＿ＳＢ１の周囲状況等の把握に要する時間を短縮することが可能となる。このことは、遠隔サービスの円滑な運用に貢献することが期待される。

実施形態によれば、また、車両ＶＨｍに対する終了リクエストＲＦＣ＿ＳＢ２が出力された場合に、この車両ＶＨｍに対する第１業務ＳＢ１の開始が予想されるか否かが判定される。そして、この第１業務ＳＢ１の開始が予想されると判定された場合、終了リクエストＲＦＣ＿ＳＢ２の受け入れが拒絶される。そのため、近い将来において車両ＶＨｍに対する開始トリガＴＲＧ＿ＳＢ１が出力されたときに、終了リクエストＲＦＣ＿ＳＢ２の受け入れを拒絶したオペレータにこの車両ＶＨｍに対する第１業務ＳＢ１を優先的に割り当てることが可能となる。

１０ プロセッサ
１１ 状態情報取得部
１２ 第１トリガ出力判定部
１３ 割り当て方法設定部
１４ 第１業務割り当て部
１５ 第１業務付与部
１６ 第２リクエスト出力判定部
１７ 第１業務開始予想部
１８ リクエスト許諾判定部
１９ 第２リクエスト応答部
ＤＰ１，ＤＰ２ ディスプレイ
ＭＳ 管理サーバ
ＯＰ１，ＯＰ２ オペレータ
ＶＨ１，ＶＨ２ 車両
ＳＢ サービス業務
ＳＢ１ 第１業務
ＳＢ２ 第２業務
ＴＲＧ 開始トリガ

Claims (6)

1. 移動体を対象とする遠隔サービスを管理する方法であって、
   前記遠隔サービスの業務の終了リクエストを受信した場合、前記終了リクエストを受け入れるか否かを判定するステップと、
   前記終了リクエストの判定の結果を、前記終了リクエストを送信したオペレータの端末に送信するステップと、
   を含み、
   前記遠隔サービスの業務は、前記遠隔サービスの提供対象の走行効率に影響を及ぼす第１業務と、前記走行効率に影響を及ぼさない第２業務と、を含み、
   前記終了リクエストの判定ステップが、
   前記終了リクエストが前記第２業務の終了リクエストの場合、当該第２業務の提供対象に対する前記第１業務の開始が予想されるか否かを判定するステップと、
   前記第１業務の開始が予想されると判定された場合、前記第２業務の終了リクエストの受け入れを拒絶するステップと、
   を含むことを特徴とする遠隔サービスの管理方法。
2. 請求項１に記載の方法であって、
   前記終了リクエストの判定ステップが、
   前記第２業務の提供対象に対する前記第１業務の開始が予想される時刻を計算するステップと、
   前記第１業務の開始が予想される時刻に基づいて、前記第２業務の終了リクエストを送信したオペレータが当該第１業務の開始を待機する時間を計算するステップと、
   更に含み、
   前記第１業務の開始を待機する時間が閾値以下の場合、前記第２業務の提供対象に対する前記第１業務の開始が予想されると判定される
   ことを特徴とする遠隔サービスの管理方法。
3. 請求項１又は２に記載の方法であって、
   前記第２業務の終了リクエストを送信したオペレータが前記第１業務の開始を待機する間に当該第１業務の開始トリガが出力された場合、前記第１業務の開始を待機する前記オペレータを、当該第１業務を担当するオペレータに任命するステップを更に含む
   ことを特徴とする遠隔サービスの管理方法。
4. 移動体を対象とする遠隔サービスを管理する装置であって、
   前記遠隔サービスを管理するプロセッサを含み、
   前記プロセッサは、
   前記遠隔サービスの業務の終了リクエストを受信した場合、前記終了リクエストを受け入れるか否かを判定する処理と、
   前記終了リクエストの判定の結果を、前記終了リクエストを送信したオペレータの端末に送信する処理と、
   を行うように構成され、
   前記遠隔サービスの業務は、前記遠隔サービスの提供対象の走行効率に影響を及ぼす第１業務と、前記走行効率に影響を及ぼさない第２業務と、を含み、
   前記終了リクエストの受け入れを判定する処理において、前記プロセッサは、
   前記終了リクエストが前記第２業務の終了リクエストの場合、当該第２業務の提供対象に対する前記第１業務の開始が予想されるか否かを判定する処理と、
   前記第１業務の開始が予想されると判定された場合、前記第２業務の終了リクエストの受け入れを拒絶する処理と、
   を行うように構成されていることを特徴とする遠隔サービスの管理装置。
5. 請求項４に記載の装置であって、
   前記終了リクエストの受け入れを判定する処理において、前記プロセッサは
   前記第２業務の提供対象に対する前記第１業務の開始が予想される時刻を計算する処理と、
   前記第１業務の開始が予想される時刻に基づいて、前記第２業務の終了リクエストを送信したオペレータが当該第１業務の開始を待機する時間を計算する処理と、
   を行うように構成され、
   前記第１業務の開始を待機する時間が閾値以下の場合、前記第２業務の提供対象に対する前記第１業務の開始が予想されると判定される
   ことを特徴とする遠隔サービスの管理装置。
6. 請求項４又は５に記載の装置であって、
   前記プロセッサは、更に、
   前記第２業務の終了リクエストを送信したオペレータが前記第１業務の開始を待機する間に当該第１業務の開始トリガが出力された場合、前記第１業務の開始を待機する前記オペレータを、当該第１業務を担当するオペレータに任命する処理を行うように構成されていることを特徴とする遠隔サービスの管理装置。

Images