[第1実施形態]
次に、本発明の一実施形態について、図面を参照しながら説明する。本実施形態によるタクシー利用支援システム1は、例えば組織(企業等)に属する利用者がタクシーを利用する際に、例えばモバイル端末装置を用いて、少なくともタクシー会社を識別する情報と、タクシー料金等の金額の情報とを、記録するものである。このような記録を、タクシー利用実績と呼ぶ。利用者は、タクシーの利用に先立って、あるいはタクシーの利用後に事後的に、決定者(例えば、利用者の上長)による承認を得るようにしてもよい。タクシー利用実績は、サーバー装置10側のデータベースに蓄積される。データベースに蓄積されたデータは、利用者や、決定者や、タクシー利用支援システム1の管理者(経理担当者を含む)や、タクシー会社担当者らが、それぞれのアクセス権限の範囲に応じて、閲覧したり確認したりすることができる。タクシー会社を識別する情報が利用実績に含まれているため、サーバー装置10側では、タクシー会社ごとの料金等の集計が可能である。また、タクシー会社担当者は、自社分の利用実績のデータに基づいて、料金の請求処理を行うことができる。タクシー利用支援システム1を利用することにより、原則として紙のタクシー券(紙券)を使用することなく、利用実績の蓄積、集計を行うことができ、且つ、紙のハンドリング等の手間を削減することができる。また、タクシー利用支援システム1が承認プロセスについての機能を含む場合には、承認プロセスと、タクシー利用プロセスと、事後的な精算のプロセスとを、整合的に実行することが可能となる。また、タクシー利用支援システム1が、利用者の勤怠状況のデータを取り込むことにより、勤務状況と、タクシー利用実績との関係を、自動的に確認することが可能となる。
本実施形態において、タクシー、ハイヤー、乗り合いタクシー、バス、カーサービス等の有償の輸送サービスを、代表して「タクシー」と呼ぶ。本実施形態をタクシー以外の輸送手段に適用する場合には、適宜、「タクシー」を適切に読み替える。また、本実施形態において、「タクシー会社」とは、上記のタクシー等の輸送サービスを提供する事業者(会社や個人等)である。つまり、「タクシー会社」は、必ずしも会社ではなくてもよい。また、本実施形態のタクシー利用支援システム1を運営する「組織」とは、会社等の法人や、公的機関や、各種の事業体等である。また、本実施形態において、タクシー利用支援システム1は、上記「組織」における利用者、決定者、および管理者のための情報処理機能を提供する。ここで、「利用者」は、業務上等の目的でタクシーを利用する者である。「決定者」は、上記利用者によるタクシーの利用等を承認する権限を持つ者(通常は、利用者の組織上の上長)である。また「管理者」は、タクシー利用支援システム1の運営を管理する者である。管理者は、典型的には、企業等における総務担当者あるいは人事担当者である。また、本実施形態では、管理者は、企業等における経理担当者を含んでもよい。
図1は、本実施形態によるタクシー利用支援システムの構成例を示すブロック図である。図示するように、タクシー利用支援システム1は、サーバー装置10と、組織内端末装置20と、利用者用モバイル端末装置30と、タクシー会社用端末装置40とを含んで構成される。サーバー装置10は、通信ネットワークを介して、組織内端末装置20や、利用者用モバイル端末装置30や、タクシー会社用端末装置40との間で通信を行える。なお、同図は、システムにおける通信ネットワークの物理的な構成を示すものではない。また、ここでは、各1台の、サーバー装置10と、組織内端末装置20と、利用者用モバイル端末装置30と、タクシー会社用端末装置40とを示しているが、これらの装置の台数は任意である。
サーバー装置10は、本システムにおいて必要なデータを記憶し、それらのデータを処理するための装置である。サーバー装置は、例えば、サーバー型コンピューターを用いて実現される。また、サーバー装置10が、物理的には複数台のサーバー型コンピューターを用いて実現されてもよい。
組織内端末装置20は、組織の内部で使用される端末装置である。組織内端末装置20は、上記のサーバー装置10に対するクライアントとして機能する。組織内端末装置20は、例えば、PC(パーソナルコンピューター)や、タブレット型端末や、スマートフォン等を用いて実現される。組織内端末装置20では、ウェブブラウザーや各種のアプリ(アプリケーションプログラム)の稼働が可能である。組織内端末装置20は、利用者や、決定者や、管理者によって使用されるものである。
利用者用モバイル端末装置30は、本システムの利用者(タクシーに乗車する人)が、移動しながら使用することのできる端末装置である。利用者用モバイル端末装置30は、単に「利用者端末装置」とも呼ばれる。利用者用モバイル端末装置30は、上記のサーバー装置10に対するクライアントとして機能する。利用者用モバイル端末装置30は、利用者を認証する機能を持つようにしてもよい。具体的には、利用者用モバイル端末装置30が持つ認証機能は、パスワードや、パスコードや、利用者個人の指紋や、顔や、声紋等を用いることによって、利用者個人を認証する。このような個人認証を行うことによって、利用者用モバイル端末装置30は、意図された利用者当人が操作していることを保証する。さらに、利用者用モバイル端末装置は、サーバー装置10によって発行された利用者コードを用いた認証を行うようにしてもよい。利用者コードは、後述するように、サーバー装置10側の利用者コード発行機能部1220等によって発行されるコード情報である。サーバー装置10側で発行した利用者コードを、利用者用モバイル端末装置30は、内部に記憶しておく。利用者用モバイル端末装置30がサーバー装置10にアクセスする際には、利用者用モバイル端末装置30は、内部に記憶している利用者コードを読み出して、サーバー装置10に送信する。サーバー装置10は、利用者用モバイル端末装置30から受信した利用者コードの有効性(正当に発行された利用者コードであるか否か等)を検証し、利用者用モバイル端末装置30からの有効であるアクセスだけを受け入れる。利用者用モバイル端末装置30が、例えば、サーバー装置10側では既に削除されている利用者コードや、正当に発行されていない利用者コードを送信した場合には、サーバー装置10は、アクセスを拒絶する。また、ある利用者に関して、利用者コードが更新された(再発行された)場合にも、サーバー装置10は、過去の(更新前の)利用者コードによるアクセスを拒絶する。このようにして、利用者コードを用いることにより、利用者用モバイル端末装置30からサーバー装置10へのアクセスの有効性の検証を行う。なお、利用者用モバイル端末装置30は、例えば、スマートフォンや、ウェアラブル端末装置や、タブレット型端末や、PC等を用いて実現される。利用者用モバイル端末装置30では、ウェブブラウザーや各種のアプリの稼働が可能である。
タクシー会社用端末装置40は、タクシー会社側において使用される端末装置である。タクシー会社用端末装置40は、上記のサーバー装置10に対するクライアントとして機能する。タクシー会社用端末装置40は、例えば、PCや、タブレット型端末等を用いて実現される。タクシー会社用端末装置40では、ウェブブラウザーや各種のアプリの稼働が可能である。
なお、組織内端末装置20や利用者用モバイル端末装置30やタクシー会社用端末装置40において実行される機能は、ウェブブラウザー上で稼働するアプリであってもよいし、ウェブブラウザーを用いずに稼働する形態のアプリであってもよい。
図2は、図1に示したタクシー利用支援システム1の構成をより詳細に示したブロック図である。図2は、通信ネットワークの概略構成をも示している。ここに示す構成では、タクシー利用支援システム1は、外部ネットワーク61に接続されている装置群と、組織内ネットワーク62に接続されている装置群とを用いて実現される。図示するように、タクシー利用支援システム1は、サーバー装置10と、組織内端末装置20と、利用者用モバイル端末装置30と、タクシー会社用端末装置40と、中継装置50と、外部ネットワーク61と、組織内ネットワーク62とを含んで構成される。
図示するように、本実施形態では、サーバー装置10は、クラウドサーバー装置11と組織内サーバー装置12とで構成される。つまり、クラウドサーバー装置11と組織内サーバー装置12とは、機能を分担している。クラウドサーバー装置11と組織内サーバー装置12とは、それぞれ、別の通信ネットワークに接続されている。クラウドサーバー装置11は、外部ネットワーク61に接続されている。また、組織内サーバー装置12は、組織内ネットワーク62に接続されている。ここで、外部ネットワーク61は、組織外に設けられたオープンなネットワークである。例えば、外部ネットワーク61として、インターネットを用いることができる。また、組織内ネットワーク62は、組織内に閉じたネットワークである。
クラウドサーバー装置11は、外部ネットワーク61を介して、利用者用モバイル端末装置30や、タクシー会社用端末装置40との間で通信を行うことができる。
また、組織内サーバー装置12は、組織内ネットワーク62を介して、組織内端末装置20との間で通信を行うことができる。また、中継装置50は、外部ネットワーク61と組織内ネットワーク62との間の中継を行うものである。クラウドサーバー装置11と組織内サーバー装置12とは、中継装置50を介して、相互に通信を行うことができる。これにより、クラウドサーバー装置11と組織内サーバー装置12のそれぞれが保持するデータ間で、データ更新の同期を取ることができる。
なお、利用者用モバイル端末装置30は、GPS(グローバル・ポジショニング・システム)の機能を有している。利用者用モバイル端末装置30は、GPS衛星71からのGPS信号を受信することによって、自装置の位置の情報を、例えば緯度および経度の形で、取得することができる。
図3は、サーバー装置10内の概略機能構成を示すブロック図である。サーバー装置10が、クラウドサーバー装置11と組織内サーバー装置12とを用いて実現され得ることは、既に述べた通りである。なお、組織内サーバー装置12自体が、いわゆるクラウドの構成で実現されてもよい。図示するように、クラウドサーバー装置11は、第1データ記憶部110と、第1利用者機能部111と、タクシー会社機能部112とを含んで構成される。また、組織内サーバー装置12は、第2データ記憶部120と、第2利用者機能部121と、決定者機能部122と、管理者機能部123と、利用実績確認部124とを含んで構成される。これらの各機能部は、例えば、コンピューターと、プログラムとで実現することが可能である。また、各機能部は、必要に応じて、記憶手段を有する。記憶手段は、例えば、プログラム上の変数や、プログラムの実行によりアロケーションされるメモリーである。また、必要に応じて、磁気ハードディスク装置やソリッドステートドライブ(SSD)といった不揮発性の記憶手段を用いるようにしてもよい。また、各機能部の少なくとも一部の機能を、プログラムではなく専用の電子回路として実現してもよい。各部の機能の概略は、次に説明する通りである。
第1データ記憶部110は、クラウドサーバー装置11が使用するデータを記憶する。第1データ記憶部110のデータは、クラウドサーバー装置11内から読み書き可能である。第1データ記憶部110が記憶するデータの詳細については、後で別の図面を参照しながら説明する。
第1利用者機能部111は、利用者用モバイル端末装置30に必要なデータを提供するとともに、利用者用モバイル端末装置30側からデータを取得する。
タクシー会社機能部112は、タクシー会社用端末装置40に必要なデータを提供するとともに、タクシー会社用端末装置40側からデータを取得する。
第2データ記憶部120は、組織内サーバー装置12が使用するデータを記憶する。第2データ記憶部120のデータは、組織内サーバー装置12内から読み書き可能である。第2データ記憶部120が記憶するデータの詳細については、後で別の図面を参照しながら説明する。
なお、第1データ記憶部110と第2データ記憶部120との間で、データの内容の一部が重複していてもよい。前述の通り、クラウドサーバー装置11と組織内サーバー装置12とは相互に通信可能であり、第1データ記憶部110と第2データ記憶部120との間では、定期的にデータの同期が図られる。例えば、いわゆるマスターデータは、主に組織内サーバー装置12側で維持され更新されるが、そのうちの必要なデータは、クラウドサーバー装置11側にも渡される。また、取引実績(タクシーの利用実績)を表すデータは、主にクラウドサーバー装置11側でまず取得され、適時に組織内サーバー装置12側にも渡される。
第2利用者機能部121は、組織内端末装置20を介して、利用者にデータを提示したり、利用者側からデータを取得したりする。また、第2利用者機能部121は、適宜、第2データ記憶部120へのデータの書き込み等を行う。
決定者機能部122は、組織内端末装置20を介して、決定者にデータを提示したり、決定者側からデータを取得したりする。また、決定者機能部122は、適宜、第2データ記憶部120へのデータの書き込み等を行う。
管理者機能部123は、組織内端末装置20を介して、管理者にデータを提示したり、管理者側からデータを取得したりする。また、管理者機能部123は、適宜、第2データ記憶部120へのデータの書き込み等を行う。
利用実績確認部124は、第2データ記憶部120内に蓄積されたタクシーの利用実績データの内容を確認する。利用実績確認部124は、具体的には、個々のタクシー利用実績のデータのうち、所定のアラート条件に合致するデータに関して、アラートを発生させる(アラートフラグをオンにする)。なお、利用実績確認部124は、利用実績を確認するために、利用者(組織の従業員)の勤怠データを外部(例えば、勤怠管理システム)から取り込んで参照するようにしてよい。勤怠データは、各日の、利用者の勤務状況(出勤時刻、退勤時刻、休日、休暇等)の情報を含む。具体的なアラート条件については、後述する。
クラウドサーバー装置11および組織内サーバー装置12が備えるより具体的な機能の内容については、後でさらに説明する。
図4は、タクシー利用支援システム1の代表的な処理の手順(決定者による事前承認、およびタクシーの利用)を示すシーケンス図である。以下、このシーケンス図を参照しながら、利用者がタクシーを利用する際におけるタクシー利用支援システム1の動作を説明する。
ステップS1からS4までの手順は、利用者による事前の利用申請と、決定者によるその承認のための手順である。この事前承認は、タクシーの利用のために必須ではない。後述するように決定者によって事後承認が行われてもよい。
ステップS1において、利用者の操作に基づき、利用者用の組織内端末装置20は、利用申請のデータを組織内サーバー装置12に送信する。この利用申請に関する情報は、サーバー装置10内に保存される。
ステップS2において、決定者の操作に基づき、組織内サーバー装置12は、利用申請一覧のデータを決定者用の組織内端末装置20に送信する。決定者用の組織内端末装置20は、利用申請一覧の情報を、画面に表示する。
ステップS3において、利用申請の情報を見た決定者の操作に基づき、決定者用の組織内端末装置20は、利用申請承認のデータを、組織内サーバー装置12に送信する。組織内サーバー装置12は、これを受けて、その申請のステータスを「承認済み」に更新する。
ステップS4において、利用者の操作に基づき、組織内サーバー装置12は、利用申請一覧のデータをその申請の利用者用の組織内端末装置20に送信する。利用者用の組織内端末装置20は、申請一覧の情報を画面に表示する。これにより、利用者は、自身が起こした申請が承認されているか否かを知ることができる。なお、利用申請一覧の情報を、利用者が、利用者用モバイル端末装置30を用いて参照できるようにしてもよい。
ステップS5からS7までの手順は、利用者が実際にタクシーに乗車してから降車するまでの間における、タクシー利用支援システム1の処理である。なお、利用申請が事前に為されているか否かに関わらず、また利用申請が事前に承認されているか否かに関わらず、このステップS5からS7までの手順を実行することができる。
ステップS5において、利用者用モバイル端末装置30は、乗車登録のデータを、インターネット等を介して、クラウドサーバー装置11に送信する。本ステップの処理は、利用者が、タクシーに乗車した際に、利用者用モバイル端末装置30を操作することによって行われる。このとき送信される乗車登録のデータは、利用者を識別するための利用者コードと、タクシー会社(および、場合によってはタクシーの車番号)を識別するためのコード情報と、乗車位置の情報(緯度および経度)と、日時とを含む。なお、利用者コードは、利用者用モバイル端末装置30が予め保持している。タクシー会社(および、場合によってはタクシーの車番号)を識別するためのコード情報は、利用者用モバイル端末装置30が、タクシーが備えている2次元コード情報を光学的に読み取ることによって獲得される。乗車位置の情報は、利用者用モバイル端末装置30がGPS衛星71から受信するGPS信号に基づいて獲得されるものである。
ステップS6において、利用者用モバイル端末装置30は、経由地登録のデータを、インターネット等を介して、クラウドサーバー装置11に送信する。本ステップの処理は、タクシーが経由地に立ち寄った際に、利用者が利用者用モバイル端末装置30を操作することによって行われる。このとき送信される乗車登録のデータは、利用者を識別するための利用者コードと、タクシー会社(および、場合によってはタクシーの車番号)を識別するためのコード情報と、経由地の情報(緯度および経度)とを含む。
ステップS7において、利用者用モバイル端末装置30は、降車登録のデータを、インターネット等を介して、クラウドサーバー装置11に送信する。本ステップの処理は、利用者が降車する際に、利用者用モバイル端末装置30を操作することによって行われる。このとき送信される乗車登録のデータは、利用者を識別するための利用者コードと、タクシー会社(および、場合によってはタクシーの車番号)を識別するためのコード情報と、降車位置の情報(緯度および経度)と、料金(例えば、タクシーのメーター料金と、メーター以外の有料道路料金)と、日時との情報とを含む。
図5は、タクシー利用支援システム1における処理の手順(決定者に依る事後承認)を示すシーケンス図である。ステップS8からS11までの手順は、利用者がタクシーを利用した後に、決定者が事後的に承認する際の、タクシー利用支援システム1の処理である。なお、事前に決定者による承認が行われている場合、この事後承認は必須ではない。
ステップS8において、利用者の操作に基づき、組織内サーバー装置12は、利用実績一覧のデータをその利用者用の組織内端末装置20に送信する。利用者用の組織内端末装置20は、利用実績一覧の情報を画面に表示する。これにより、利用者は、利用実績の情報を確認することができる。また、補完入力を必要とする利用実績がある場合には、利用者は、利用者用の組織内端末装置20から、補完入力を行うことができる。
ステップS9において、利用者の操作に基づき、利用者用の組織内端末装置20は、補完対応のデータを、組織内サーバー装置12に対して送信する。この補完対応のデータは、利用者が補完入力したデータを含む。
ステップS10において、決定者の操作に基づき、組織内サーバー装置12は、利用実績一覧のデータをその決定者用の組織内端末装置20に送信する。決定者用の組織内端末装置20は、利用実績一覧の情報を画面に表示する。これにより、決定者は、利用実績の情報の承認を行うことができる。
ステップS11において、決定者の操作に基づき、決定者用の組織内端末装置20は、利用実績の承認のデータを、組織内サーバー装置12に対して送信する。組織内サーバー装置12は、これを受けて、その利用実績のステータスを「承認済み」に更新する。
図6は、利用されたタクシーの会社(事業者)やその支店等を特定するためのコード情報の例を示す概略図である。このコード情報は、紙等の媒体に印刷され、利用者用モバイル端末装置30が光学的に読み取り可能なものである。図示する例では、コード情報は、二次元コードである。二次元コードの例は、QRコード(登録商標)である。ただし、コード情報は、二次元コード以外の方法(例えば、バーコード、文字等で表されてもよい。また、例えば、RFID(radio frequency identifier、無線識別タグ)等を用いて、利用者用モバイル端末装置30が無線信号(電波)によるコード情報を読み取れるようにしてもよい。このコード情報は、例えば、タクシー車内に備え付けられ、あるいは置かれる。
このコード情報は、少なくともタクシー会社(事業者)を一意に識別する情報を含む。また、コード情報が、タクシー会社等の、支社、支店、部署等を識別する情報をさらに含んでもよい。さらに、コード情報が、タクシーの個別の車両を識別する情報(車番)を含んでいてもよい。つまり、タクシー会社を識別する情報や、車両を識別する情報を基に、二次元コードが生成される。利用者がタクシー利用時に、利用者用モバイル端末装置30を用いてこのコード情報を読み取ることにより、利用者用モバイル端末装置30は、少なくともそのタクシーを運営するタクシー会社を特定する情報を取得する。また、利用者用モバイル端末装置30は、少なくともタクシー会社を特定する情報を、サーバー装置10側に送信することができる。
なお、図示するように、2次元コードとともに、タクシー会社識別情報「0001」やタクシー会社名「〇〇タクシー」を文字でも印刷するようにしてもよい。
次に、利用者用モバイル端末装置30に表示されるユーザーインターフェースについて説明する。図7から図11までは、タクシー利用支援システム1において、利用者がタクシーを利用する際に利用者用モバイル端末装置30に表示されるユーザーインターフェース(画面)の例を示す概略図である。
図7は、乗車登録前において、利用者用モバイル端末装置30に表示される画面を示す概略図である。図示するように、この画面には、「乗車記録」、「経由地記録」、「降車記録」の3つのボタンが含まれる。利用者は、いずれかのボタンを選択する(タップ等の操作)ことにより、各ボタンに対応する機能を実行させることができる。
図7に示す画面において、利用者が「乗車記録」を選択した場合、利用者用モバイル端末装置30は、乗車記録を登録するための機能を実行させる。具体的には、利用者用モバイル端末装置30は、GPSにより現在位置(乗車位置)を取得し、タクシーに備えられたコード情報(図6)を読み取る。また、利用者用モバイル端末装置30は、当該利用者を識別するための利用者コードを予め記憶している。また、利用者用モバイル端末装置30は、内部の時計から現在日時(乗車日時)を取得する。そして、利用者用モバイル端末装置30は、これらの、現在位置(乗車位置)の情報と、タクシーから読み取ったコード情報と、利用者コードと、現在日時(乗車日時)とを含んだ乗車記録のデータを、クラウドサーバー装置11に送信し、登録する。なお、利用者用モバイル端末装置30は、予め利用者が行っていた利用申請の情報(車券番号)を関連付ける形で、乗車記録を登録するようにしてもよい。
図8は、乗車登録後において、利用者用モバイル端末装置30に表示される画面を示す概略図である。図示するように、この画面には、「経由地記録」、「降車記録」の2つのボタンが含まれる。利用者は、いずれかのボタンを選択する(タップ等の操作)ことにより、各ボタンに対応する機能を実行させることができる。
図8に示す画面において、利用者が「経由地記録」を選択した場合、利用者用モバイル端末装置30は、経由地記録を登録するための機能を実行させる。具体的には、利用者用モバイル端末装置30は、GPSにより現在位置(経由位置)を取得する。また、利用者用モバイル端末装置30は、当該利用者を識別するための利用者コードを予め記憶している。また、利用者用モバイル端末装置30は、内部の時計から現在日時(経由日時)を取得する。そして、利用者用モバイル端末装置30は、現在位置(経由位置)の情報と、利用者コードと、現在日時(経由日時)とを含んだ経由地記録のデータを、クラウドサーバー装置11に送信し、登録する。なお、特に経由地がない場合、即ちタクシーが乗車位置から降車位置まで直行する場合には、この経由地を登録する動作は不要である。
図8に示す画面において、利用者が「降車記録」を選択した場合、利用者用モバイル端末装置30は、降車記録を登録するための機能を実行させる。そのための画面が、次の図9、図10、図11である。
図9は、タクシー降車時に、利用者が金額等を入力するための画面である。図示するように、この画面は、使用理由と、乗車料金と、有料道路料金とを入力するための欄が設けられている。使用理由は、利用者がこのタクシーを利用した理由を入力するための欄である。例えば、いくつかの選択肢の中から使用理由を選択できるようなユーザーインターフェースとしてよい。また、利用者が申請時に選択した使用理由が、この画面におけるデフォルトとして表示されるようにしてもよい。また、乗車料金および有料道路料金の欄には数値を入力できるようにしている。また、この画面は、「降車確認」というボタンを含んでいる。利用者は、乗車料金等の情報を入力した後に、この「降車確認」のボタンを押す(例えば、タップする)ことができる。「降車確認」のボタンが押されると、利用者用モバイル端末装置30は、入力された上記データを、クラウドサーバー装置11に送信する。また、利用者用モバイル端末装置30は、GPSにより取得した現在位置(降車位置)と、予め記憶していた利用者コードと、内部の時計から取得した現在日時(降車日時)をも、クラウドサーバー装置11に送信する。
図10は、降車確認画面である。この降車確認画面は、図9に示した画面において「降車確認」ボタンが押された後に、利用者用モバイル端末装置30に表示される。図10の降車確認画面は、クラウドサーバー装置11が利用者用モバイル端末装置30に表示させるものであり、タクシー会社、車番、乗車料金、有料道路料金、合計、乗車日時、降車日時といった項目のデータを含む。
図10の画面に表示される、タクシー会社と車番とは、利用者用モバイル端末装置30がクラウドサーバー装置11側に送信したデータに基づく。クラウドサーバー装置11は、マスターデータ(後述)を参照することによって、タクシー会社識別情報からタクシー会社名情報を求める。なお、車番は、特定されない場合もあり、その場合には表示されない。また、乗車料金と有料道路料金とは、図9の画面で入力された値によるものである。また、合計は、乗車料金と有料道路料金との和であり、図9の画面で入力された値に基づいてクラウドサーバー装置11側で算出された値である。乗車日時および降車日時は、それぞれ、乗車時と降車時に、利用者用モバイル端末装置30からクラウドサーバー装置11に送信されたデータである。
なお、上記の降車確認画面に、経由地に関する情報をさらに表示するようにしてもよい。
降車確認画面は、「決定・乗車情報登録」のボタンと、「修正」のボタンとを含んでいる。利用者が「決定・乗車情報登録」のボタンを押した(タップ等の操作)場合、登録する旨の情報がクラウドサーバー装置11側に伝えられ、降車確認画面に表示されていたデータをクラウドサーバー装置11が確定する。また、利用者が「修正」のボタンを押した場合、例えば図9の画面の表示に戻って、利用者がデータを修正する操作を行うことが可能である。なお、データを確定する際に、利用者が、タクシーのサービス提供者(ドライバー等)に画面を見せて確認し合ってもよい。
図11は、降車記録完了画面である。図10の降車確認画面において「決定・乗車情報登録」のボタンが押された後、この図11の降車記録完了画面の表示に移る。この降車記録完了画面もまた、クラウドサーバー装置11が利用者用モバイル端末装置30に表示させるものであり、タクシー会社と、車番と、乗車料金と、有料道路料金と、合計と、乗車日時と、降車日時と、車券番号の各項目のデータを含んでいる。この降車記録完了画面は、サーバー側で確定したデータを確認するためのものである。この降車記録完了画面を、利用者がタクシーのサービス提供者(ドライバー等)に見せてその内容を確認し合ってもよい。また、降車記録完了画面の段階において初めて、利用者用モバイル端末装置30に車券番号が表示されるため、タクシーのサービス提供者(ドライバー等)は、サーバー側でデータが確定したことを確認することができる。また、タクシーのサービス提供者は、この車券番号を乗務記録あるいは他の書類等に控えておくことにより、後でこの利用実績のデータを参照しやすくなる。
図12は、タクシーの乗車と経由地と降車との各段階で発生するデータと、その流れとをまとめた概略図である。図示するように、タクシーへの乗車時には、利用者用モバイル端末装置30は、サーバー装置10に、乗車記録を送信し登録する。乗車記録は、利用者コード、車券番号、乗車日時、乗車位置、タクシー会社コード情報といったデータを含む。サーバー装置10側では、乗車記録を受け取ると、そのデータを記憶手段に書き込む。また、タクシーが経由地を経由した際には、利用者用モバイル端末装置30は、サーバー装置10に、経由地記録を送信し登録する。経由地記録は、利用者コード、車券番号、経由日時、経由位置といったデータを含む。サーバー装置10側では、経由地記録を受け取ると、そのデータを記憶手段に書き込む。なお、経由地記録は、タクシーの1回の乗降車につき、例えば、0回以上N回以下(Nは、非負整数であり、一例としてN=10)の登録を可能とする。図示するように、タクシーの降車時には、利用者用モバイル端末装置30は、サーバー装置10に、降車記録を送信し登録する。降車記録は、利用者コード、車券番号、降車日時、降車位置、料金(メーター料金)、有料道路料金、使用理由といったデータを含む。サーバー装置10側では、降車記録を受け取ると、そのデータを記憶手段に書き込む。なお、料金の情報は、利用者が端末装置の画面上等で手入力するものであってよい。
図13は、サーバー装置10が管理するデータの一部であり、タクシー会社、その支店等、および個々の車を識別するための情報を保持するテーブル(タクシーマスター)の構成を示す概略図である。このテーブルは2次元の表形式のデータとして構成され、タクシー会社コード、タクシー会社名、支店コード、支店名、車番号といったデータ項目を持つ。タクシー会社コードは、タクシー利用支援システム1のために各事業者に付与されたコードである。図示する例では、0001、0002といったコードが付与されている。タクシー会社名は、その事業者の名称等である。図示する例では、タクシー会社コードが0001の会社の名称は「〇〇タクシー」である。また、タクシー会社コードが0002の会社の名称は「△△自動車」である。支店コードは、タクシー会社の支店、支社、支所、部署、出張所、あるいはこれらに類するものを識別するためのコードである。また、支店コードが、タクシー会社と業務提携する別のタクシー会社(あるいは、個人)を識別するためのコードであってもよい。例えば、複数のタクシー会社が組合を形成し、その組合自体あるいはその組合を代表するタクシー会社(「チケット取り扱い会社」等とも呼ばれる。)に対してタクシー会社コードが付与される場合に、当該組合に加盟するタクシー会社等に支店コードを付与する場合があり得る。ここで挙げた「組合」は、共同して料金の請求を行うための事業者の組合である。なお、ここで挙げた支店、支社、支所、出張所、業務提携会社等を、代表して、「支店」あるいは「支店等」と呼ぶ場合がある。支店名は、上記の支店等の名称である。図示する例では、タクシー会社コードが0001の会社では、支店コードが0321の代々木支店と、支店コードが0322の品川支店とが登録されている。タクシー会社コードが0002の会社では、支店コードは用いられていない。また、車番号は、個々の車両を識別するために付与される番号である。図示する例では、タクシー会社コードが0001の会社では、車番号は用いられていない。また、タクシー会社コードが0002の会社では、0001から0500までの車番号が付与され、用いられている。図6で例示した二次元コードは、例えばタクシー会社コードおよび車番号の組み合わせを基に、所定の計算手順で、作成されるものである。二次元コードを読み取った場合、タクシー会社コードと、支店コードと、車番号が得られる。また、タクシー会社コードや支店コードをキーとしてこの図13のデータを検索すると、それぞれ、タクシー会社名や支店名の情報が得られる。
図14は、サーバー装置10が管理するデータの一部であり、システムの利用者に関する情報を保持するテーブル(利用者マスター)の構成を示す概略図である。図示するように、このテーブルは、利用者コード、氏名、部署コード、自宅住所、自宅緯度・経度といったデータ項目を含む。なお、自宅住所と自宅緯度・経度の各データ項目については、組織内サーバー装置12側のテーブルでのみ保持し、クラウドサーバー装置11側のテーブルでは持たないようにしてもよい。利用者コードは、タクシー利用支援システム1のために付与され、利用者を個々に識別するためのコード情報である。氏名は、利用者の氏名である。部署コードは、当該利用者が組織内において所属する部署を識別するためのコード情報である。自宅住所は、利用者の自宅の住所である。自宅緯度・経度は、利用者の自宅の位置を緯度および経度で表した情報である。なお、データベースを検索することにより、住所から緯度および経度への変換は可能である。なお、タクシー利用支援システム1が後述するアラートを発生させる処理のために、自宅住所やその緯度・経度の情報が参照される場合がある。また、自宅住所や、その緯度・経度の情報は、限られた者(例えば、本人等)のみが参照できるよう、アクセス制御がなされる。
図15は、サーバー装置10が管理するデータの一部であり、個々のタクシー利用状況を蓄積するためのテーブルの構成を示す概略図である。このテーブルの各行が、1回のタクシーの利用に対応する。図示するように、このテーブルは、確認日時、車券番号、タクシー会社コード、車番号、利用者コード、乗車日時、降車日時、乗車区間、使用理由、乗車料金、有料道路料金といったデータ項目を含む。
各項目のデータの意味は、次の通りである。確認日時は、降車時のデータが最終的に確認されたときの日時である。車券番号は、1回のタクシーの利用に対応する番号である。車券番号は、例えば、利用申請が行われたとき、または利用申請がない状態で乗車記録が登録されたときに、発行される。タクシー会社コードと車番号については、図13を参照しながら説明した通りである。利用者コードについては、図14を参照しながら説明した通りである。乗車日時は、乗車記録を登録する処理が行われた日時である。降車日時は、降車記録を登録する処理が行われた日時である。乗車区間は、乗車記録の登録時の位置情報と、降車記録の登録時の位置情報とを基に構成されるデータである。乗車位置と降車位置のそれぞれは、緯度と経度とで表されてもよいし、緯度および経度を基に求められる地名あるいは施設名等で表されてもよい。使用理由と、乗車料金と、有料道路料金とは、降車時に登録されたデータである。なお、上記の確認日時や乗車日時や降車日時は、例えば、「YYYY/MM/DD hh:mm」(年・月・日、時・分)の形式で表現される。
なお、すべての利用者のタクシー利用状況は、図15に示す構造を有する単一のテーブルに蓄積される。
次に、図16から図20までの各図を参照しながら、各機能部のさらに内部の機能構成について説明する。
図16は、第1利用者機能部111内の概略機能構成を示すブロック図である。図示するように、第1利用者機能部111は、乗車登録機能部1111と、経由地登録機能部1112と、降車登録機能部1113とを含んで構成される。
乗車登録機能部1111は、利用者がタクシーに乗車したことをデータベースに登録する。なお、乗車登録機能部1111は、利用者用モバイル端末装置30が読み取ったタクシーのコード情報(少なくとも、タクシー会社を識別する情報を含む)を、取得する。また、乗車登録機能部1111は、乗車時に収集する他のデータを、利用者用モバイル端末装置30から取得する。乗車登録機能部1111が乗車時に取得するデータの項目については、図12等を参照しながら説明した通りである。
経由地登録機能部1112は、利用者が経由地を経由したことをデータベースに登録する。経由地登録機能部1112は、図12等を参照しながら説明したように、経由地記録のデータを取得して保存する。
降車登録機能部1113は、利用者が降車したことをデータベースに登録する。降車登録機能部1113は、図12等を参照しながら説明したように、降車記録のデータを取得して保存する。
図17は、第2利用者機能部121内の概略機能構成を示すブロック図である。図示するように、第2利用者機能部121は、自宅登録機能部1212と、利用申請機能部1213と、利用申請一覧機能部1214と、利用実績一覧機能部1215と、アラート対応機能部1216と、補完対応機能部1217とを含んで構成される。
自宅登録機能部1212は、利用者の自宅住所を登録する機能を有する。自宅登録機能部1212は、例えば利用者の操作に基づき、利用者が入力した自宅住所を図14に示したテーブルに書き込む。また、併せて、自宅登録機能部1212は、登録された自宅住所に基づいて地理データ(不図示)を参照することにより、当該利用者の自宅の緯度および経度を求め、図14に示したテーブルに書き込む。
利用申請機能部1213は、利用者によるタクシー利用申請の処理を行う。利用申請機能部1213は、利用者用の組織内端末装置20に、乗車予定日や、乗車予定区間(乗車位置の地名と、降車位置の地名と、必要に応じて経由地の地名)や、使用理由や、当該申請を承認すべき決定者といった情報を入力(一部の項目は選択肢から選択)するための画面を表示する。利用者がそれらの項目のデータを入力(一部の項目は選択)して「申請」ボタンを押すと、利用申請機能部1213は、その申請を登録する。また、利用申請機能部1213は、適切な決定者がその利用申請を承認できる状態とする。後で説明する利用申請一覧機能部1214が、申請が承認されたか否かを表す情報を表示する。また、利用者がタクシーに乗車する際には、その乗車と利用申請とを関連付けることができる(例えば、乗車時に、申請を選択できる)ようにする。
なお、利用申請機能部1213は、申請を承認すべき決定者が不在(例えば、一時的に外出中)の場合には、決定者不在状態のまま利用申請を登録しておくことができるようにしてもよい。また、利用申請機能部1213は、申請時に入力されるべきデータ項目のうち、一部の項目については空白のまま申請を受け付けるようにしてよい。これらの、決定者不在での申請や、一部項目空白での申請が行われた場合、後述する補完対応機能部1217が、これらの不足を補完するための機能を提供する。
また、利用申請機能部1213は、複数の利用申請をまとめて行えるようなユーザーインターフェースを提供してもよい。例えば、特定の乗車区間を毎日繰り返して利用するような場合には、利用者が複数の利用申請をまとめて行える(複数の車券番号をまとめて申請できる)機能が便利である。
利用申請一覧機能部1214は、利用者用の組織内端末装置20に、特定の利用者(ログインしている利用者)のタクシー利用申請の一覧情報を表示させる。これにより、利用者は、利用申請の状況(例えば、既に承認されているか否か等)をまとめて把握することが可能となる。利用申請一覧機能部1214は、表示すべき利用申請を絞り込むための検索条件を受け付けるようにしてもよい。検索条件としては、例えば、利用者名や、利用申請の状況(既に承認されているか否か)や、申請した日付を絞り込むための期間や、その他のフリーワードに関する条件を含んでよい。
利用実績一覧機能部1215は、利用者が利用実績を一覧できる情報を利用者用の組織内端末装置20に表示させる機能を持つ。利用実績一覧機能部1215は、表示すべき利用実績を絞り込むための検索条件を受け付けるようにしてもよい。検索条件としては、例えば、利用者名や、利用した日付を絞り込むための期間や、補完入力が必要か否かを示す条件や、使用理由や、アラートの有無あるいは種別や、その他のフリーワード(例えば乗車区間等に関する検索語)に関する条件を含んでよい。検索条件が利用者に依って指定された場合には、利用実績一覧機能部1215は、指定された検索条件に合致する利用実績のみを一覧表示するようにする。
アラート対応機能部1216は、利用実績に関するアラートが発生している場合に、利用者がそのアラートに対応するためのアクションを可能とする機能を有する。例えば、アラートを含む利用実績がある場合、アラート対応機能部1216は、補足説明欄を表示し、利用者が当該アラートに関する補足説明を入力できるようにする。補足説明は、例えば、自由なテキストとして受け付けられる。アラート対応機能部1216は、利用者が入力した補足説明を当該利用実績に関連付ける形で記憶させる。また、アラート対応機能部1216は、決定者が利用者の利用実績を閲覧する際に、その補足説明を併せて表示できるようにする。これにより、利用者が入力した補足説明に基づいて、決定者は、その利用実績を承認するか否かを判断することができるようになる。
補完対応機能部1217は、補完が必要な利用実績に関して、利用者が補完入力を行うための機能を有する。補完対応が必要となるのは、例えば、次のような場合である。前述の通り、利用者は、利用申請の際に、決定者不在の状態での申請を行ったり、一部項目空白での申請を行ったりすることができる。これらの不足のある申請や、その申請に基づく利用実績に関して、補完対応機能部1217は、「要補完入力」であることを示す表示を行う。そして、補完対応機能部1217は、「要補完入力」である申請に関して、補足説明欄を表示し、利用者が補足説明を入力できるようにする。補足説明は、テキストとして受け付けられる。補完対応機能部1217は、利用者が入力した補足説明を当該申請に関連付ける形で記憶させる。また、補完対応機能部1217は、補完入力された申請(あるいはそういった申請に基づく利用実績)を決定者が閲覧する際に、その補足説明を併せて表示できるようにする。これにより、利用者が補完した内容(補足説明等)に基づいて、決定者は、その利用実績を承認するか否かを判断することができるようになる。
なお、上記の場合(一部空白、あるいは決定者不在)の他に、利用者の属するクラスに応じて、特定の使用理由での申請については、補完対応機能部1217が、同様に「要補完入力」として扱うようにしてもよい。一例として、特定のクラスに属する利用者が「緊急」、「夜回」、「朝駆」以外の使用理由を用いた場合に、補完対応機能部1217は、その申請を「要補完入力」として扱う。
図18は、決定者機能部122内の概略機能構成を示すブロック図である。図示するように、決定者機能部122は、利用者コード発行機能部1220と、利用申請承認機能部1221と、利用申請一覧機能部1222と、利用実績一覧機能部1223と、アラート対応機能部1224と、補完対応機能部1225とを含んで構成される。
利用者コード発行機能部1220は、利用者に対して利用者コードを発行する。利用者コードは、タクシー利用支援システム1内におけるコード情報である。利用者コード発行機能部1220は、例えば、利用者となる可能性のある人(従業員等)のリストを表示し、決定者が、利用者コード発行対象の人をチェックボックス等で選択できるようにする。利用者コード発行機能部1220は、そのような決定者の操作に基づいて選択された利用者に、新たな利用者コードを発行する。利用者コードは、例えば連番を用いるなどの方法により、他の利用者と重複しないように決められる。利用者コード発行機能部1220は、発行した利用者コードを、図14に示したテーブルの利用者コード欄に書き込む。
利用者コード発行機能部1220は、利用者コードの発行の完了後に、当該利用者宛に、発行された利用者コードを送る。利用者コード発行機能部1220は、一例として、電子メールの文面内の、URL(ユニフォーム・リソース・ロケーター)の文字列の中に、暗号化した利用者コードあるいは平文の利用者コードを埋め込む。これを受信した利用者は、例えば利用者用モバイル端末装置30から、そのURLで表されるリソースにアクセスする。すると、利用者用モバイル端末装置30内のウェブブラウザー上で稼働するアプリが、その利用者コードを利用者用モバイル端末装置30内の記憶手段に書き込む。あるいは、そのウェブブラウザー自体が、その利用者コードを記憶手段(例えば、ブラウザーの管理情報の記憶部)に書き込む。これにより、利用者用モバイル端末装置30は、利用者のための機能を実行する際に、当該利用者の利用者コードを記憶手段から読み出して使用することができるようになる。
利用申請承認機能部1221は、決定者が利用申請を承認するための機能を持つ。具体的には、利用申請承認機能部1221は、決定者用の組織内端末装置20に、当該決定者による承認を必要とする申請の一覧を表示させる。なお、利用申請承認機能部1221は、一覧として表示する申請を絞り込むための検索条件を受け付けるようにしてもよい。また、利用申請承認機能部1221は、それらの申請を一括して、あるいは各申請個別に、承認するか否かを選択するための手段(例えば、「承認」あるいは「否認」のボタン)を、決定者用の組織内端末装置20に表示させる。そして、決定者の操作に応じて、利用申請承認機能部1221は、それらの申請を承認あるいは否認する処理を行う。申請が承認された場合には、申請のデータにおいて、承認済のフラグがオンに更新される。つまり、申請が承認された場合には、利用申請承認機能部1221は、承認済の利用実績データ(利用申請データ)には承認済であることを表す情報を付加する。
利用申請一覧機能部1222は、利用申請の一覧を、決定者用の組織内端末装置20に表示させる機能を持つ。利用申請一覧機能部1222は、表示すべき利用申請を絞り込むための検索条件を受け付けるようにしてもよい。検索条件は、例えば、利用申請一覧機能部1214について既に説明したものと同様の条件であってよい。
利用実績一覧機能部1223は、タクシーの利用実績の一覧を、決定者用の組織内端末装置20に表示させる機能を持つ。利用実績がアラートを持つものである場合には、利用実績一覧機能部1223は、その利用実績について、アラートがある旨の表示を併せて行う。なお、利用実績一覧機能部1223は、表示すべき利用実績を絞り込むための検索条件を受け付けるようにしてもよい。検索条件は、例えば、利用者名や、日付や、使用理由や、金額(乗車料金等)についての条件であってよい。また、利用実績一覧機能部1223は、決定者による操作に基づき、一覧表示した利用実績のデータを承認する機能を持つ。
アラート対応機能部1224は、タクシーの利用実績のデータがアラートを持つものである場合に、決定者が補足説明を入力するための欄を表示する。また、アラート対応機能部1224は、決定者が入力する補足説明(テキスト)を受け付ける。アラート対応機能部1224は、受け付けた補足説明のデータを、当該利用実績のデータと関連付けて保存する。また、アラート対応機能部1224は、決定者による操作に基づき、アラートを持っていた利用実績のデータを承認する機能を持つ。
補完対応機能部1225は、タクシーの利用申請または利用実績のデータが「要補完入力」の状態である場合に、決定者が補足説明を入力するための欄を表示する。「要補完入力」となる条件については、既に述べた通りである。また、補完対応機能部1225は、決定者が入力する補足説明を受け付ける。補完対応機能部1225は、受け付けた補足説明のデータを、当該利用実績のデータと関連付けて保存する。また、補完対応機能部1225は、決定者による操作に基づき、「要補完入力」であった利用実績のデータを承認する機能を持つ。
図19は、タクシー会社機能部112内の概略機能構成を示すブロック図である。図示するように、タクシー会社機能部112は、データ確定機能部1121と、データ編集機能部1122と、請求実行機能部1123と、請求明細出力機能部1125と、請求明細追加機能部1126と、紙券明細追加機能部1127とを含んで構成される。タクシー会社機能部112は、タクシー会社用端末装置40に対して、タクシー会社ごとに仕分けた利用実績のデータを提供する。なお、タクシー会社機能部112は、当該タクシー会社に関するデータのみを、タクシー会社用端末装置40に対して提供する。
データ確定機能部1121は、利用実績のデータを確定させる機能を持つ。具体的には、データ確定機能部1121は、利用実績の個々のデータ(「明細」と呼ぶ)の一覧を、タクシー会社用端末装置40に表示させる。このとき、データ確定機能部1121は、確定済のデータと、未確定のデータとを、異なる表示方法で(例えば、異なる表示色で)表示する。データ確定機能部1121は、この一覧を見たタクシー会社担当者が、例えばチェックボックスをチェックするなどといった操作により、確定させる機能を有する。データ確定機能部1121は、タクシー会社担当者の操作に基づき、確定したデータ(明細)の確定フラグを更新する。
データ編集機能部1122は、利用実績のデータをタクシー会社担当者が編集できる機能を提供する。タクシー会社担当者がデータを編集する(修正する)必要が生じるのは、例えば、次のような場合である。
a)乗車時に電波伝搬状況が良くないなどの状況により、クラウドサーバー装置11側で乗車記録を取得できなかった場合(降車時に、乗車記録と降車記録とがまとめて登録される場合もある)。
b)利用者による操作のタイミングがずれることなどにより、乗車記録、経由地記録、降車記録の、日時あるいは位置が、実際とずれてしまった場合。
c)利用者が料金の入力を誤り、タクシーのサービス提供者(ドライバー)による確認も漏れてしまった場合。
請求実行機能部1123は、タクシー会社側から、利用者の属する組織(企業等)の側への料金の請求を実行するための機能を有する。具体的には、請求実行機能部1123は、例えばタクシー会社担当者の操作等に基づき、タクシーの利用実績のうちの、確定済で且つ未請求のデータを検索して提示する。請求実行機能部1123は、タクシー会社担当者が、請求のためのデータを確認したのちに、請求を実行できるように、「OK」のボタンを画面に提示する。請求実行機能部1123は、この「OK」のボタンが押されると、請求が実行されたものとして、データ(明細)のステータスを「請求済」に更新する。また、請求実行機能部1123は、明細データのそれぞれに、請求日(請求実行の当日)のデータを書き込む。
請求明細出力機能部1125は、上記の請求に関する請求明細データを出力する機能を持つ。請求明細出力機能部1125は、タクシー会社用端末装置40から、検索条件として、請求日の指定を受け付ける。請求明細出力機能部1125は、指定された請求日に該当するデータを、検索によって抽出する。請求明細出力機能部1125は、条件にしたがって抽出されたデータを、帳票として印刷出力したり、スプレッドシート用のデータとして出力したりする。これにより、タクシー会社担当者は、印刷出力された帳票(明細データの集合)や、スプレッドシートのデータを、利用者が属する組織への請求書に添付して送ることが可能となる。
請求明細追加機能部1126は、何らかの事情により漏れてしまった利用実績について、請求のための明細データを追加で作成する機能である。請求明細追加機能部1126は、タクシー会社担当者の操作に基づき、追加すべき明細データを作成する。
紙券明細追加機能部1127は、紙のタクシー券(紙券)に基づいて請求用の明細データを追加で作成する機能を持つ。紙券は、都合により、タクシー利用支援システム1による乗車記録や降車記録を作成することができない場合に、利用され得るものである。
図20は、管理者機能部123内の概略機能構成を示すブロック図である。図示するように、管理者機能部123は、利用者登録機能部1231と、利用者変更機能部1232と、利用者削除機能部1233と、承認済申請廃棄機能部1234と、利用者コード発行機能部1235と、利用者コード更新機能部1236と、経理関連機能部1239とを含んで構成される。
利用者登録機能部1231は、タクシー利用支援システム1を利用する利用者を登録する機能を有する。利用者登録機能部1231は、例えば、別のデータベース管理システム(DBMS)で管理されている利用者(従業員等)のデータや、PC用の表計算ソフトが作成したスプレッドシートのデータ等をインポートすることにより、利用者を登録する。インポートされるデータは、図14に示したテーブルが有するデータ項目の少なくとも一部を持っている。利用者登録機能部1231は、インポートしたデータを、図14に示したテーブルに書き込む。また、管理者が利用者の情報を手で入力することにより利用者を登録するようにしてもよい。
利用者変更機能部1232は、利用者の情報を変更する。利用者変更機能部1232は、例えば管理者の操作に基づいて、利用者の氏名や、部署コードや、その他の属性情報を変更することができる。
利用者削除機能部1233は、タクシー利用支援システム1に登録されていた利用者を削除する。例えば、従業員である利用者が退職する場合に、例えば管理者の操作により、利用者削除機能部1233は、当該利用者の登録を削除する。利用者削除機能部1233は、当該ユーザーを図14に示したテーブルから削除したり、あるいは同等のデータの更新(例えば無効フラグをオンにする)を行ったりする。削除された利用者は、タクシー利用支援システム1を使用することが出来なくなる。
承認済申請廃棄機能部1234は、承認済の利用申請(まだ実際にタクシーの利用が行われていない申請)のうち、所定の条件等に合致するものを廃棄するための機能を持つ。承認済申請廃棄機能部1234は、管理者用の組織内端末装置20に、利用申請を検索する条件を入力するための欄を表示させる。これにより、管理者は、検索条件を設定することが可能となる。具体例として、管理者は、利用者(例えば、利用申請が承認された後に人事異動等によって所属部署が変わった従業員)の氏名等を検索条件として入力する。承認済申請廃棄機能部1234は、指定された検索条件にしたがって、利用申請を検索し、条件に合致した利用申請を画面に表示する。管理者は、その表示を確認し、必要に応じて廃棄対象の利用申請を選択する操作等を行い、「廃棄」ボタンを押す。この操作に基づいて、承認済申請廃棄機能部1234は、承認済の利用申請を廃棄することができる。
利用者コード発行機能部1235は、利用者に対して利用者コードを発行する。利用者コードは、タクシー利用支援システム1内におけるコード情報である。利用者コード発行機能部1235は、例えば管理者の操作に基づいて選択された利用者に、新たな利用者コードを発行する。利用者コード発行機能部1235は、発行した利用者コードを、図14に示したテーブルの利用者コード欄に書き込む。
利用者コード更新機能部1236は、利用者コードを更新(変更)する機能を持つ。利用者コード更新機能部1236は、例えば管理者の操作に基づいて選択された利用者に、従来とは異なる利用者コードを発行する。利用者コード更新機能部1236は、変更後の利用者コードを用いて、図14に示したテーブルの利用者コード欄を更新する。
経理関連機能部1239は、タクシーの利用に関して、経理の観点から必要な機能を提供するものである。例えば、経理関連機能部1239は、管理者(特に、経理担当者)が、指定された期間について、タクシー会社別に、利用実績データや、料金の合計額のデータを閲覧できるようにする。また、経理関連機能部1239は、利用実績データを決定者が承認済みであるか否かを確認する機能を持つ。さらに、経理関連機能部1239は、利用実績データを管理者が承認済みであるか否かを確認する機能を持ってもよい。また、経理関連機能部1239は、タクシー会社から料金が請求済であるか否かを表すフラグを、利用実績データ上で更新する機能を持つ。また、経理関連機能部1239は、タクシー会社からの請求が漏れている利用実績を画面上で目立つように(例えば、色を変えるなどして)表示する。また、経理関連機能部1239は、タクシー会社ごとに、精算用のデータ(タクシー会社からの料金請求と、支払いによる未払金の消込等のためのデータ)を出力する機能を持つ。また、経理関連機能部1239は、実際にタクシーが利用されたにもかかわらず何らかの理由で利用実績データがない場合等に、利用実績データを追加作成する機能を持つ。また、タクシー利用支援システム1の仕組みを使用せずにタクシーの利用が行われた場合(この場合には、例えば、紙に印刷されたタクシー利用券(紙券)が用いられる)の料金を、タクシー会社との精算のデータに反映させる機能を、経理関連機能部1239は、持つ。
上記のように、タクシー利用支援システム1は、企業等の会計システムとシームレスにデータのやり取りを行うことができる。
なお、前述の利用実績確認部124がデータの確認のために用いるアラート条件は、例えば、次の通りである。ただし、アラート条件は、ここに列挙したものに限定されない。アラート条件を、適宜、追加したり変更したりするようにしてもよい。なお、出勤時刻や退勤時刻等の勤怠データは、前述の通り参照可能である。
(1)退勤後時間超過: 当該利用者の退勤時刻よりもタクシーの乗車時刻が予め定められた所定時間を超えて離れている。
(2)降車後時間超過: タクシーの降車時刻よりも当該利用者の出勤時刻が予め定められた所定時間を超えて離れている。
(3)1日所定金額以上: 同一利用者に関してタクシーの1日の料金の合計が予め定められた所定金額以上である。
(4)徹宵/深夜早朝: 勤怠データにおいて徹宵勤務区分となっている日に、当該利用者が深夜・早朝の使用理由でタクシーを利用している。
(5)深夜早朝/所定距離以上: 深夜・早朝の使用理由でタクシーを利用している場合に、乗車地または降車地(いずれか自宅側)が、自宅位置(緯度・経度)と所定距離以上離れている。
(6)深夜早朝時間外乗車: 深夜・早朝の使用理由でタクシーを利用している場合に、勤務地ごと(あるいは部署ごと)に定められている利用可能時間帯以外に、タクシーを利用している。
(7)自宅付近乗車: 深夜早朝の使用理由以外のタクシー利用において、自宅付近(所定距離以内)での乗車位置がある。
(8)自宅付近降車: 深夜早朝の使用理由以外のタクシー利用において、自宅付近(所定距離以内)での降車位置がある。
(9)休日利用: 勤怠データ上の休日あるいは休暇の日に、タクシーの利用がある。
(10)勤務時間外乗降: 深夜早朝の使用理由以外のタクシー利用において、乗車時刻あるいは降車時刻が、勤務時間内に収まっていない。
利用実績確認部124が例えば上記のようなアラート条件に基づいてタクシーの利用実績を確認する。つまり、利用実績確認部124は、予め定められた所定のアラート条件に合致するか否かを判定し、前記アラート条件に合致する場合には、当該利用実績データについてのアラートを発生させる。このため、適切ではないタクシー利用の可能性がある場合に、利用者に、補足説明の入力を求めることが可能となる。
なお、上述した実施形態におけるタクシー利用支援システム1内の少なくとも一部の機能をコンピューターで実現することができる。その場合、この機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、OSや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD-ROM、DVD-ROM、USBメモリー等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、一時的に、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
本実施形態についてまとめると、次の通りである。
サーバー装置は、少なくとも、利用者機能部と、データ記憶部と、決定者機能部と、輸送会社機能部とを備える。クラウドサーバー装置11や組織内サーバー装置12は、サーバー装置である。第1利用者機能部111や第2利用者機能部121は、利用者機能部である。第1データ記憶部110や第2データ記憶部120は、データ記憶部である。タクシー会社機能部112は、輸送会社機能部である。
利用者機能部は、利用者の端末装置から、輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報と輸送料金の金額の情報とを含んだ利用実績データを受信する。なお、タクシーが人を運び届けるサービスは、輸送サービスである。タクシー会社は、輸送事業者である。タクシー会社を識別する情報は、輸送事業者識別情報である。
データ記憶部は、受信された前記利用実績データを記憶し蓄積する。
決定者機能部は、前記利用者による前記輸送サービスの利用を、前記輸送サービスの実施の前または後の少なくともいずれかに承認する処理(事前承認または事後承認)を実行し、承認済の前記利用実績データには承認済であることを表す情報を付加する。
輸送会社機能部は、承認済の前記利用実績データを基に、輸送事業者の端末装置に対して、輸送事業者ごとに仕分けた前記利用実績データを提供する。
輸送事業者識別情報(タクシー会社識別情報)は、輸送事業者(タクシー会社)が有する輸送手段(タクシーの車両等)であって前記輸送サービスのために用いられる輸送手段に、光学的に読み取り可能な形態で設けられたコード情報を、利用者の端末装置が読み取ることによって取得されるものである。
利用者の端末装置は、前記輸送サービスの開始時(タクシーへの乗車時)に、前記コード情報を読み取るものである。
利用者機能部は、当該コード情報に基づく前記輸送事業者識別情報をサービス開始記録(乗車記録)の一部として前記利用者の端末装置から受信する。
利用者の端末装置は、前記輸送サービスの終了時(タクシーからの降車時)の、前記輸送サービスについての輸送料金(メーター料金や有料道路料金、およびその合計)の金額の決定(確定)後に、当該輸送料金の金額の情報を取得するものである。
利用者機能部は、当該輸送料金の金額の情報をサービス終了記録(降車記録)の一部として前記利用者の端末装置から受信する。
利用者の端末装置は、前記輸送料金の金額の情報を、利用者の手入力によって取得するものである。つまり、タクシーのメーター等から料金データを受信する手段を設ける必要がない。
輸送会社機能部は、輸送事業者の端末装置に対して、当該輸送事業者用の前記利用実績データを提供する際に、前記輸送サービスの実施の単位で、前記利用実績データを当該輸送事業者が確認済であるか否かを表す情報を併せて送信し、前記輸送事業者の端末装置から確認済であると指示された前記利用実績データについては、確認済であることを表す情報を付加する(確認済フラグの更新)。
前記輸送会社機能部は、輸送事業者の端末装置に対して、当該輸送事業者用の前記利用実績データを提供する際に、前記輸送サービスの実施の単位で、前記利用実績データについて当該輸送事業者が料金請求済であるか否かを表す情報を併せて送信し、前記輸送事業者の端末装置から料金請求済であると指示された前記利用実績データについては、料金請求済であることを表す情報を付加する(請求済フラグの更新)。
サーバー装置は、前記利用実績データの内容を確認する利用実績確認部、をさらに具備する。
利用者機能部は、前記輸送サービスの開始時(乗車時)に、前記輸送サービスの開始時の時刻(乗車時刻)の情報と前記輸送サービスの開始時の位置(乗車位置)の情報とを前記利用者の端末装置から受信するとともに、前記輸送サービスの終了時(降車時)に、前記輸送サービスの終了時の時刻(降車時刻)の情報と前記輸送サービスの終了時の位置(降車位置)の情報とを前記利用者の端末装置から受信する。
データ記憶部は、前記利用実績データの一部として、前記輸送サービスの開始時の時刻の情報と、前記輸送サービスの開始時の位置の情報と、前記輸送サービスの終了時の時刻の情報と、前記輸送サービスの終了時の位置の情報と、を記憶する。
利用実績確認部は、前記利用者の勤怠状況を表す勤怠データを参照することによって、前記勤怠データと、前記輸送サービスの開始時の時刻の情報と、前記輸送サービスの開始時の位置の情報と、前記輸送サービスの終了時の時刻の情報と、前記輸送サービスの終了時の位置の情報とが、予め定められた所定のアラート条件に合致するか否かを判定し、前記アラート条件に合致する場合には、当該利用実績データについてのアラートを発生させる。
利用者用モバイル端末装置30(利用者端末装置)は、輸送サービスのために用いられる輸送手段に光学的に読み取り可能な形態で設けられたコード情報を読み取ることによって輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報を取得するとともに、前記輸送料金の金額の情報を取得し、前記輸送事業者識別情報と前記輸送料金の金額の情報とを含んだ利用実績データをサーバー装置に対して送信する。さらに、利用者用モバイル端末装置30(利用者端末装置)は、前記輸送サービスの開始時に、前記コード情報を読み取ることによって前記輸送事業者識別情報を含んだ前記利用実績データを前記サーバー装置に送信し、前記輸送料金の金額の決定後に、利用者の手入力により前記輸送料金の金額の情報を取得して前記輸送料金の金額の情報を含んだ前記利用実績データを前記サーバー装置に送信し、前記輸送料金の金額の情報を含んだ確認画面を表示するとともに、当該確認画面に含まれる「登録」ボタンが操作されると前記利用実績データを確定することの通知である確定通知を前記サーバー装置に送信する。さらに、利用者用モバイル端末装置30(利用者端末装置)は、確定通知を前記サーバー装置に送信した後に、前記サーバー装置によって付与される車券番号を画面に表示する。
以上説明したように、本実施形態によれば、過大な装置等を必要とせずに(特にタクシー等の車両側に追加の通信手段を設けずに)、料金の決済が可能となる。また、本実施形態によれば、利用者は、予めサーバー側で決定されたタクシー会社に限らず、タクシーを利用することができる。また、本実施形態によれば、利用者の端末装置が、タクシー利用時にアプリをわざわざダウンロードしてインストールする必要がない。また、本実施形態によれば、利用者の組織内における承認プロセスと、タクシーの利用プロセスと、タクシー会社からの請求プロセスとを、シームレスにつなぐことができる。
[第2実施形態]
次に、第2実施形態について、図面を参照しながら、説明する。なお、前実施形態において既に説明した事項については以下において説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。本実施形態の特徴は、クラウドサーバー装置11が持つ機能の構成である。クラウドサーバー装置11は、第1実施形態における第1利用者機能部111に代えて、本実施形態では第1利用者機能部211を持つように構成される。
図21は、本実施形態における第1利用者機能部211の概略機能構成を示すブロック図である。図示するように、第1利用者機能部211は、乗車登録機能部2111と、経由地登録機能部2112と、降車登録機能部2113と、利用申請機能部2118と、利用申請一覧機能部2119とを含んで構成される。これらのうち、乗車登録機能部2111と、経由地登録機能部2112と、降車登録機能部2113とは、それぞれ、第1実施形態における乗車登録機能部1111と、経由地登録機能部1112と、降車登録機能部1113と同様の機能を持つ。つまり、本実施形態においても、利用者は、利用者用モバイル端末装置30を操作することによって、乗車登録、経由地登録、降車登録といった処理を実行させることができる。本実施形態での特徴は、第1利用者機能部211が、利用申請機能部2118、および利用申請一覧機能部2119をも含む点である。
利用申請機能部2118は、第1実施形態における第2利用者機能部121内の利用申請機能部1213と同等の機能を持つ。これにより、本実施形態では、利用者は、組織内端末装置20からだけではなく、利用者用モバイル端末装置30からも、タクシーの利用申請の処理を行うことができる。具体的には、利用申請機能部2118は、利用者用モバイル端末装置30に、利用申請機能部1213と同様の、申請に関する必要事項を入力(一部の項目は選択肢から選択)するための画面を表示する。また、利用者がそれらのデータを入力して「申請」ボタンを操作(タップ等)すると、利用申請機能部1213は、その申請を登録する。この申請のデータは、適切なタイミングで、クラウドサーバー装置11側から組織内サーバー装置12側にも転送される。つまり、利用申請機能部2118が処理する申請は、組織内サーバー装置12側の利用申請機能部1213で処理された申請と同等に扱われる。つまり、適切な決定者がその利用申請を承認できる状態となる。
利用申請機能部2118は、ここで記載を省略している機能についても、利用申請機能部1213と同等の機能を持つ。
なお、本実施形態においても、第2利用者機能部121は、第1実施形態と同等の利用申請機能部1213の機能を持つ。つまり、利用者は、組織内端末装置20を用いても、利用者用モバイル端末装置30を用いても、同等に、タクシーの利用の申請に関する処理を行うことができる。
なお、利用申請機能部1213または利用申請機能部2118のいずれかの機能によって利用者がタクシーの利用の申請を行ったときに、当該申請について決定を行うべき決定者に対して電子メールでの通知が送られるようにしてもよい。その一例としては、新規の申請を監視するデーモンが組織内サーバー装置12内で常時稼働するようにしておき、そのデーモンが、新規の申請に関連付けられる決定者に対して電子メールを送信するようにする。
利用申請一覧機能部2119は、第1実施形態における第2利用者機能部121内の利用申請一覧機能部1214と同等の機能を持つ。これにより、本実施形態では、利用者は、組織内端末装置20からだけではなく、利用者用モバイル端末装置30からも、タクシーの利用申請の一覧を閲覧することができる。
利用申請一覧機能部2119は、利用者用モバイル端末装置30に、特定の利用者(ログインしている利用者)のタクシー利用申請の一覧情報を表示させる。これにより、利用者は、利用申請の状況(例えば、既に承認されているか否か等)をまとめて把握することが可能となる。その他の機能についても、利用申請一覧機能部2119は、利用申請一覧機能部1214と同等の機能を持つようにする。
なお、本実施形態による利用者用モバイル端末装置30は、上記の通り、輸送サービス(タクシーのサービス)を利用するための申請データをサーバー装置に送信する。また、利用者用モバイル端末装置30は、第1実施形態においても説明したように、降車確認が行われた際(確定通知をサーバー装置に送信した後)に、降車記録完了画面を表示する。この降車確認完了画面には、車券番号も表示されている。この車券番号は、上記の申請データに関連付けてサーバー装置によって付与された番号である。
以上、第1実施形態および第2実施形態を説明したが、本発明はさらに次のような変形例でも実施することが可能である。
変形例1: 上記実施形態では、サーバー装置10の機能を、クラウドサーバー装置11と組織内サーバー装置12とに分けて、システムを構成した。変形例1として、これら両者を分けずに、1台のサーバー装置としてシステムを構成してもよい。また、サーバー装置10の機能を、3台以上の装置に分けてシステムを構成してもよい。
変形例2: 上記実施形態では、乗車時に、利用者用モバイル端末装置30が2次元コード情報(タクシー会社を少なくとも識別するコード情報)を読み取って、乗車記録としてその情報をサーバー側に送信するようにした。変形例2として、利用者用モバイル端末装置30がこの2次元コード情報を読み取るのは、タクシーの乗車時から降車時までの間の(輸送サービスが行われている間の)いつ行ってもよい。また、利用者用モバイル端末装置30が、タクシー会社を識別する情報をサーバー側に送信するのも、タクシーの乗車時から降車時までの間のいつ行ってもよい。
また、複数の変形例を、組み合わせて実施してもよい。
以上、この発明の複数の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。