JP7414470B2 - サーバー装置、プログラム、利用者端末装置、およびシステム - Google Patents

Description

本発明は、サーバー装置、プログラム、利用者端末装置、およびシステムに関する。

企業等の組織において、業務等の目的で利用したタクシー料金の情報を、効率的に収集し、集計することが望まれる。例えば紙のタクシー券を用いた場合には、タクシー券の配布の管理や、紙に記載されたタクシー料金の金額をデータ化して集計する処理などに、多大な手間（人手）を要する。そこで、情報機器と通信とを用いて、これらのデータ処理を効率化することが考えられる。

例えば、特許文献１の段落０００２（背景技術の欄）には、「タクシーチケットを管理する管理システムから携帯電話機やＩＣカードなどの携帯型装置にタクシーチケット識別情報などのタクシーチケット情報を送信して記憶し、タクシー利用者が携帯している携帯型装置に記憶されているタクシーチケット情報をタクシーに搭載されているタクシー装置が読み出し、タクシー利用料金の精算を行うタクシーチケット処理方法や、タクシーチケット決済システム」について記載されている。

また、特許文献１の実施形態の欄には、タクシーチケット処理システムが記載されている。

具体的には、段落００３０には、チケット生成システムは、チケット申請情報をチケット申請サーバーから受信し、タクシーチケットの生成依頼を受け付ける（Ｓ２１０）こと、タクシー会社選択部は、タクシー会社情報ＤＢに格納されているタクシー会社情報及びチケット申請情報に基づいて、タクシー会社を選択（Ｓ２３０）すること、携帯電話機は、この電子メールを受信し（Ｓ３１０）、電子メールに含まれているＵＲＬへ接続し（Ｓ３２０）、認証情報を送信し、タクシーチケットアプリケーションのダウンロードを要求する（Ｓ３３０）ことが記載されている。

また、段落００３１には、タクシーチケットアプリケーションを携帯電話機にダウンロードした利用者は、このアプリケーションを起動し、ディスプレイにチケットデータ、タクシー会社情報を表示すること、利用者は、サービス内容などに基づいて表示されるタクシー会社のいずれかを選択し、携帯電話機がその電話番号に電話をかけ、利用者は、配車を依頼すること、利用者の乗車時に携帯電話機及びタクシー装置間で近距離無線通信（赤外線など）などの通信を行い、チケットデータをタクシー装置へ送信すること（Ｓ４１０）、タクシー装置は、このチケットデータを受信し（Ｓ５１０）、利用可能か否かを判定する（Ｓ５２０）ことが記載されている。つまり、タクシー装置は、電子署名に基づいて、チケットデータの正当性が確認でき、現在位置、時刻などが利用制限情報の制限を満たしていることを確認できた場合に、チケットデータが利用可能であると判定することが、記載されている。

また、段落００２５には、タクシー装置は、タクシーに搭載され、タクシー利用料金の算出、精算などを行う装置であって、携帯電話機、タクシー会社のデータ管理サーバー、決済代行会社のチケット決済サーバーなどと通信を行うことが可能であること、各タクシーに搭載されているタクシー装置は、データ管理サーバー、チケット決済サーバーとの通信を制御する通信装置、携帯電話機との近距離無線通信を制御する近距離通信装置などを備えていることが、記載されている。

また、段落００２７には、データ管理サーバーは、通信回線を介して、タクシー装置、チケット決済サーバーなどと通信を行うことが可能であって、タクシー会社におけるデータ処理を管理するサーバーであること、データ管理サーバーは、タクシー装置から利用実績情報を受信し、タクシーＩＤごとに記憶し、管理すること、データ管理サーバーは、記憶している利用実績情報におけるチケットデータによって支払処理が行われた利用料金を定期的に集計し、集計結果を決済代行会社のチケット決済サーバーへ送信し、この料金の支払を要求することが、記載されている。

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

しかしながら、特許文献１に記載された技術では、様々な問題が残っている。

例えば、「タクシー利用者が携帯している携帯型装置に記憶されているタクシーチケット情報をタクシーに搭載されているタクシー装置が読み出し、タクシー利用料金の精算を行う」という方法では、携帯型装置とタクシー装置との間での通信が必要であり、装置そのもののコストや、ソフトウェアの大規模化によるコストが、過大なものとなってしまう。

また、（サーバー側の）タクシー会社選択部３３が、タクシー会社情報ＤＢ３６に格納されているタクシー会社情報及びチケット申請情報に基づいて、タクシー会社を選択する方式は、利用者にとってはタクシー会社の選択の自由度が狭まるという点において不便であり、且つ、タクシーへの乗車前の段階で、タクシー会社の選択等の処理の負荷がサーバー側にかかってしまうという不都合がある。

また、携帯電話機４０が、受信した電子メールに基づき、タクシーチケットアプリケーションのダウンロードを要求する、という方式は、利用者にとって、必要以上に、アプリのダウンロード（およびインストール）が求められるもので、不都合である。

また、携帯電話機４０とタクシー装置５０との間で、近距離無線通信（赤外線など）などの通信によって、チケットデータを受け渡しする処理は、手順が煩雑であり、可能ならば避けられることが望ましい。

また、特許文献１に記載のシステムでは、企業等の組織の側でのタクシー利用に関する承認プロセスを組み込むことが困難である。

本発明は、上記の課題認識に基づいて行なわれたものであり、タクシー側（輸送手段用の車両側）に追加の通信手段を必要とせず、低コストな装置を用いて、簡便な手段でタクシー等の料金のキャッシュレス決済を実現することのできるサーバー装置、プログラム、利用者端末装置、およびシステムを提供しようとするものである。

［１］上記の課題を解決するため、本発明の一態様によるサーバー装置は、利用者の端末装置から、輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報と輸送料金の金額の情報とを含んだ利用実績データを受信する利用者機能部と、受信された前記利用実績データを蓄積するデータ記憶部と、前記利用者による前記輸送サービスの利用を、前記輸送サービスの実施の前または後の少なくともいずれかに承認する処理を実行し、承認済の前記利用実績データには承認済であることを表す情報を付加する決定者機能部と、輸送事業者の端末装置に対して、輸送事業者ごとに仕分けた前記利用実績データを提供する輸送会社機能部と、を具備する。

［２］また、本発明の一態様は、上記のサーバー装置において、前記輸送事業者識別情報は、前記輸送事業者が有する輸送手段であって前記輸送サービスのために用いられる輸送手段に、光学的に読み取り可能な形態で設けられたコード情報を、前記利用者の端末装置が読み取ることによって取得されるものである。

［３］また、本発明の一態様は、上記のサーバー装置において、前記利用者の端末装置は、前記輸送サービスの開始時に、前記コード情報を読み取るものであり、前記利用者機能部は、当該コード情報に基づく前記輸送事業者識別情報をサービス開始記録の一部として前記利用者の端末装置から受信する、ものである。

［４］また、本発明の一態様は、上記のサーバー装置において、前記利用者の端末装置は、前記輸送サービスの終了時の、前記輸送サービスについての輸送料金の金額の決定後に、当該輸送料金の金額の情報を取得するものであり、前記利用者機能部は、当該輸送料金の金額の情報をサービス終了記録の一部として前記利用者の端末装置から受信する、ものである。

［５］また、本発明の一態様は、上記のサーバー装置において、前記利用者の端末装置は、前記輸送料金の金額の情報を、利用者の手入力によって取得するものである。

［６］また、本発明の一態様は、上記のサーバー装置において、前記輸送会社機能部は、輸送事業者の端末装置に対して、当該輸送事業者用の前記利用実績データを提供する際に、前記輸送サービスの実施の単位で、前記利用実績データを当該輸送事業者が確認済であるか否かを表す情報を併せて送信し、前記輸送事業者の端末装置から確認済であると指示された前記利用実績データについては、確認済であることを表す情報を付加する、ものである。

［７］また、本発明の一態様は、上記のサーバー装置において、前記輸送会社機能部は、輸送事業者の端末装置に対して、当該輸送事業者用の前記利用実績データを提供する際に、前記輸送サービスの実施の単位で、前記利用実績データについて当該輸送事業者が料金請求済であるか否かを表す情報を併せて送信し、前記輸送事業者の端末装置から料金請求済であると指示された前記利用実績データについては、料金請求済であることを表す情報を付加する、ものである。

［８］また、本発明の一態様は、上記のサーバー装置において、前記利用実績データの内容を確認する利用実績確認部、をさらに具備し、前記利用者機能部は、前記輸送サービスの開始時に、前記輸送サービスの開始時の時刻の情報と前記輸送サービスの開始時の位置の情報とを前記利用者の端末装置から受信するとともに、前記輸送サービスの終了時に、前記輸送サービスの終了時の時刻の情報と前記輸送サービスの終了時の位置の情報とを前記利用者の端末装置から受信し、前記データ記憶部は、前記利用実績データの一部として、前記輸送サービスの開始時の時刻の情報と、前記輸送サービスの開始時の位置の情報と、前記輸送サービスの終了時の時刻の情報と、前記輸送サービスの終了時の位置の情報と、を記憶し、前記利用実績確認部は、前記利用者の勤怠状況を表す勤怠データを参照することによって、前記勤怠データと、前記輸送サービスの開始時の時刻の情報と、前記輸送サービスの開始時の位置の情報と、前記輸送サービスの終了時の時刻の情報と、前記輸送サービスの終了時の位置の情報とが、予め定められた所定のアラート条件に合致するか否かを判定し、前記アラート条件に合致する場合には、当該利用実績データについてのアラートを発生させる、ものである。

［９］また、本発明の一態様は、利用者の端末装置から、輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報と輸送料金の金額の情報とを含んだ利用実績データを受信する利用者機能部と、受信された前記利用実績データを蓄積するデータ記憶部と、前記利用者による前記輸送サービスの利用を、前記輸送サービスの実施の前または後の少なくともいずれかに承認する処理を実行し、承認済の前記利用実績データには承認済であることを表す情報を付加する決定者機能部と、輸送事業者の端末装置に対して、輸送事業者ごとに仕分けた前記利用実績データを提供する輸送会社機能部と、を具備するサーバー装置、としてコンピューターを機能させるためのプログラムである。

［１０］また、本発明の一態様は、輸送サービスのために用いられる輸送手段に光学的に読み取り可能な形態で設けられたコード情報を読み取ることによって輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報を取得するとともに、輸送料金の金額の情報を取得し、前記輸送事業者識別情報と前記輸送料金の金額の情報とを含んだ利用実績データをサーバー装置に対して送信する、利用者端末装置である。

［１１］また、本発明の一態様は、上記の利用者端末装置において、前記利用者端末装置は、前記輸送サービスの開始時に、前記コード情報を読み取ることによって前記輸送事業者識別情報を含んだ前記利用実績データを前記サーバー装置に送信し、前記輸送料金の金額の決定後に、利用者の手入力により前記輸送料金の金額の情報を取得して前記輸送料金の金額の情報を含んだ前記利用実績データを前記サーバー装置に送信し、前記輸送料金の金額の情報を含んだ確認画面を表示するとともに、当該確認画面に含まれる「登録」ボタンが操作されると前記利用実績データを確定することの通知である確定通知を前記サーバー装置に送信するものである。

［１２］また、本発明の一態様は、上記の利用者端末装置において、前記輸送サービスを利用するための申請データを前記サーバー装置に送信するとともに、前記確定通知を前記サーバー装置に送信した後に、前記申請データに関連付けて前記サーバー装置によって付与される車券番号を画面に表示するものである。

［１３］また、本発明の一態様は、利用者の端末装置から、輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報と輸送料金の金額の情報とを含んだ利用実績データを受信する利用者機能部と、受信された前記利用実績データを蓄積するデータ記憶部と、前記利用者による前記輸送サービスの利用を、前記輸送サービスの実施の前または後の少なくともいずれかに承認する処理を実行し、承認済の前記利用実績データには承認済であることを表す情報を付加する決定者機能部と、輸送事業者の端末装置に対して、輸送事業者ごとに仕分けた前記利用実績データを提供する輸送会社機能部と、を具備するサーバー装置と、前記輸送サービスのために用いられる輸送手段に光学的に読み取り可能な形態で設けられたコード情報を読み取ることによって前記輸送事業者識別情報を取得するとともに、前記輸送料金の金額の情報を取得し、前記輸送事業者識別情報と前記輸送料金の金額の情報とを含んだ利用実績データをサーバー装置に対して送信する、利用者端末装置と、を含むシステムである。

本発明によれば、輸送手段用の車両側に追加の通信手段を必要とせず、低コストな装置を用いて、簡便な手段でタクシー等の料金の決済を実現することができる。

本発明の第１実施形態によるタクシー利用支援システムの構成例を示すブロック図である。 同実施形態によるタクシー利用支援システムの構成（通信ネットワークの概略構成を含む）をより詳細に示したブロック図である。 同実施形態によるサーバー装置内の概略機能構成を示すブロック図である。 同実施形態によるタクシー利用支援システムの典型的な処理手順（決定者による事前承認、およびタクシーの利用）を示すシーケンス図である。 同実施形態によるタクシー利用支援システムの典型的な処理手順（決定者に依る事後承認）を示すシーケンス図である。 同実施形態において利用対象であるタクシーの会社等（事業者）を特定するためのコード情報（二次元コード）の例を示す概略図である。 同実施形態によるタクシー利用支援システムの稼働時に、利用者用モバイル端末装置において表示される画面の例を示す概略図である（タクシー乗車前）。 同実施形態によるタクシー利用支援システムの稼働時に、利用者用モバイル端末装置において表示される画面の例を示す概略図である（乗車確認終了直後）。 同実施形態によるタクシー利用支援システムの稼働時に、利用者用モバイル端末装置において表示される画面の例を示す概略図である（降車時の金額等入力）。 同実施形態によるタクシー利用支援システムの稼働時に、利用者用モバイル端末装置において表示される画面の例を示す概略図である（降車確認時）。 同実施形態によるタクシー利用支援システムの稼働時に、利用者用モバイル端末装置において表示される画面の例を示す概略図である（後者の際の登録完了時）。 同実施形態において、タクシーの乗車と経由地と降車との各段階で発生するデータと、その流れとを示す概略図である。 同実施形態によるサーバー装置が管理するデータの一部であり、タクシー会社および自動車を識別するための情報を保持するテーブルの構成を示す概略図である。 同実施形態によるサーバー装置が管理するデータの一部であり、システムの利用者に関する情報を保持するテーブルの構成を示す概略図である。 同実施形態によるサーバー装置が管理するデータの一部であり、個々のタクシー利用状況を蓄積するためのテーブルの構成を示す概略図である。 同実施形態による第１利用者機能部内の概略機能構成を示すブロック図である。 同実施形態による第２利用者機能部内の概略機能構成を示すブロック図である。 同実施形態による決定者機能部内の概略機能構成を示すブロック図である。 同実施形態によるタクシー会社機能部内の概略機能構成を示すブロック図である。 同実施形態による管理者機能部内の概略機能構成を示すブロック図である。 第２実施形態によるタクシー利用支援システムにおける第１利用者機能部の概略機能構成を示すブロック図である。

［第１実施形態］
次に、本発明の一実施形態について、図面を参照しながら説明する。本実施形態によるタクシー利用支援システム１は、例えば組織（企業等）に属する利用者がタクシーを利用する際に、例えばモバイル端末装置を用いて、少なくともタクシー会社を識別する情報と、タクシー料金等の金額の情報とを、記録するものである。このような記録を、タクシー利用実績と呼ぶ。利用者は、タクシーの利用に先立って、あるいはタクシーの利用後に事後的に、決定者（例えば、利用者の上長）による承認を得るようにしてもよい。タクシー利用実績は、サーバー装置１０側のデータベースに蓄積される。データベースに蓄積されたデータは、利用者や、決定者や、タクシー利用支援システム１の管理者（経理担当者を含む）や、タクシー会社担当者らが、それぞれのアクセス権限の範囲に応じて、閲覧したり確認したりすることができる。タクシー会社を識別する情報が利用実績に含まれているため、サーバー装置１０側では、タクシー会社ごとの料金等の集計が可能である。また、タクシー会社担当者は、自社分の利用実績のデータに基づいて、料金の請求処理を行うことができる。タクシー利用支援システム１を利用することにより、原則として紙のタクシー券（紙券）を使用することなく、利用実績の蓄積、集計を行うことができ、且つ、紙のハンドリング等の手間を削減することができる。また、タクシー利用支援システム１が承認プロセスについての機能を含む場合には、承認プロセスと、タクシー利用プロセスと、事後的な精算のプロセスとを、整合的に実行することが可能となる。また、タクシー利用支援システム１が、利用者の勤怠状況のデータを取り込むことにより、勤務状況と、タクシー利用実績との関係を、自動的に確認することが可能となる。

本実施形態において、タクシー、ハイヤー、乗り合いタクシー、バス、カーサービス等の有償の輸送サービスを、代表して「タクシー」と呼ぶ。本実施形態をタクシー以外の輸送手段に適用する場合には、適宜、「タクシー」を適切に読み替える。また、本実施形態において、「タクシー会社」とは、上記のタクシー等の輸送サービスを提供する事業者（会社や個人等）である。つまり、「タクシー会社」は、必ずしも会社ではなくてもよい。また、本実施形態のタクシー利用支援システム１を運営する「組織」とは、会社等の法人や、公的機関や、各種の事業体等である。また、本実施形態において、タクシー利用支援システム１は、上記「組織」における利用者、決定者、および管理者のための情報処理機能を提供する。ここで、「利用者」は、業務上等の目的でタクシーを利用する者である。「決定者」は、上記利用者によるタクシーの利用等を承認する権限を持つ者（通常は、利用者の組織上の上長）である。また「管理者」は、タクシー利用支援システム１の運営を管理する者である。管理者は、典型的には、企業等における総務担当者あるいは人事担当者である。また、本実施形態では、管理者は、企業等における経理担当者を含んでもよい。

図１は、本実施形態によるタクシー利用支援システムの構成例を示すブロック図である。図示するように、タクシー利用支援システム１は、サーバー装置１０と、組織内端末装置２０と、利用者用モバイル端末装置３０と、タクシー会社用端末装置４０とを含んで構成される。サーバー装置１０は、通信ネットワークを介して、組織内端末装置２０や、利用者用モバイル端末装置３０や、タクシー会社用端末装置４０との間で通信を行える。なお、同図は、システムにおける通信ネットワークの物理的な構成を示すものではない。また、ここでは、各１台の、サーバー装置１０と、組織内端末装置２０と、利用者用モバイル端末装置３０と、タクシー会社用端末装置４０とを示しているが、これらの装置の台数は任意である。

サーバー装置１０は、本システムにおいて必要なデータを記憶し、それらのデータを処理するための装置である。サーバー装置は、例えば、サーバー型コンピューターを用いて実現される。また、サーバー装置１０が、物理的には複数台のサーバー型コンピューターを用いて実現されてもよい。

組織内端末装置２０は、組織の内部で使用される端末装置である。組織内端末装置２０は、上記のサーバー装置１０に対するクライアントとして機能する。組織内端末装置２０は、例えば、ＰＣ（パーソナルコンピューター）や、タブレット型端末や、スマートフォン等を用いて実現される。組織内端末装置２０では、ウェブブラウザーや各種のアプリ（アプリケーションプログラム）の稼働が可能である。組織内端末装置２０は、利用者や、決定者や、管理者によって使用されるものである。

利用者用モバイル端末装置３０は、本システムの利用者（タクシーに乗車する人）が、移動しながら使用することのできる端末装置である。利用者用モバイル端末装置３０は、単に「利用者端末装置」とも呼ばれる。利用者用モバイル端末装置３０は、上記のサーバー装置１０に対するクライアントとして機能する。利用者用モバイル端末装置３０は、利用者を認証する機能を持つようにしてもよい。具体的には、利用者用モバイル端末装置３０が持つ認証機能は、パスワードや、パスコードや、利用者個人の指紋や、顔や、声紋等を用いることによって、利用者個人を認証する。このような個人認証を行うことによって、利用者用モバイル端末装置３０は、意図された利用者当人が操作していることを保証する。さらに、利用者用モバイル端末装置は、サーバー装置１０によって発行された利用者コードを用いた認証を行うようにしてもよい。利用者コードは、後述するように、サーバー装置１０側の利用者コード発行機能部１２２０等によって発行されるコード情報である。サーバー装置１０側で発行した利用者コードを、利用者用モバイル端末装置３０は、内部に記憶しておく。利用者用モバイル端末装置３０がサーバー装置１０にアクセスする際には、利用者用モバイル端末装置３０は、内部に記憶している利用者コードを読み出して、サーバー装置１０に送信する。サーバー装置１０は、利用者用モバイル端末装置３０から受信した利用者コードの有効性（正当に発行された利用者コードであるか否か等）を検証し、利用者用モバイル端末装置３０からの有効であるアクセスだけを受け入れる。利用者用モバイル端末装置３０が、例えば、サーバー装置１０側では既に削除されている利用者コードや、正当に発行されていない利用者コードを送信した場合には、サーバー装置１０は、アクセスを拒絶する。また、ある利用者に関して、利用者コードが更新された（再発行された）場合にも、サーバー装置１０は、過去の（更新前の）利用者コードによるアクセスを拒絶する。このようにして、利用者コードを用いることにより、利用者用モバイル端末装置３０からサーバー装置１０へのアクセスの有効性の検証を行う。なお、利用者用モバイル端末装置３０は、例えば、スマートフォンや、ウェアラブル端末装置や、タブレット型端末や、ＰＣ等を用いて実現される。利用者用モバイル端末装置３０では、ウェブブラウザーや各種のアプリの稼働が可能である。

タクシー会社用端末装置４０は、タクシー会社側において使用される端末装置である。タクシー会社用端末装置４０は、上記のサーバー装置１０に対するクライアントとして機能する。タクシー会社用端末装置４０は、例えば、ＰＣや、タブレット型端末等を用いて実現される。タクシー会社用端末装置４０では、ウェブブラウザーや各種のアプリの稼働が可能である。

なお、組織内端末装置２０や利用者用モバイル端末装置３０やタクシー会社用端末装置４０において実行される機能は、ウェブブラウザー上で稼働するアプリであってもよいし、ウェブブラウザーを用いずに稼働する形態のアプリであってもよい。

図２は、図１に示したタクシー利用支援システム１の構成をより詳細に示したブロック図である。図２は、通信ネットワークの概略構成をも示している。ここに示す構成では、タクシー利用支援システム１は、外部ネットワーク６１に接続されている装置群と、組織内ネットワーク６２に接続されている装置群とを用いて実現される。図示するように、タクシー利用支援システム１は、サーバー装置１０と、組織内端末装置２０と、利用者用モバイル端末装置３０と、タクシー会社用端末装置４０と、中継装置５０と、外部ネットワーク６１と、組織内ネットワーク６２とを含んで構成される。

図示するように、本実施形態では、サーバー装置１０は、クラウドサーバー装置１１と組織内サーバー装置１２とで構成される。つまり、クラウドサーバー装置１１と組織内サーバー装置１２とは、機能を分担している。クラウドサーバー装置１１と組織内サーバー装置１２とは、それぞれ、別の通信ネットワークに接続されている。クラウドサーバー装置１１は、外部ネットワーク６１に接続されている。また、組織内サーバー装置１２は、組織内ネットワーク６２に接続されている。ここで、外部ネットワーク６１は、組織外に設けられたオープンなネットワークである。例えば、外部ネットワーク６１として、インターネットを用いることができる。また、組織内ネットワーク６２は、組織内に閉じたネットワークである。

クラウドサーバー装置１１は、外部ネットワーク６１を介して、利用者用モバイル端末装置３０や、タクシー会社用端末装置４０との間で通信を行うことができる。
また、組織内サーバー装置１２は、組織内ネットワーク６２を介して、組織内端末装置２０との間で通信を行うことができる。また、中継装置５０は、外部ネットワーク６１と組織内ネットワーク６２との間の中継を行うものである。クラウドサーバー装置１１と組織内サーバー装置１２とは、中継装置５０を介して、相互に通信を行うことができる。これにより、クラウドサーバー装置１１と組織内サーバー装置１２のそれぞれが保持するデータ間で、データ更新の同期を取ることができる。

なお、利用者用モバイル端末装置３０は、ＧＰＳ（グローバル・ポジショニング・システム）の機能を有している。利用者用モバイル端末装置３０は、ＧＰＳ衛星７１からのＧＰＳ信号を受信することによって、自装置の位置の情報を、例えば緯度および経度の形で、取得することができる。

図３は、サーバー装置１０内の概略機能構成を示すブロック図である。サーバー装置１０が、クラウドサーバー装置１１と組織内サーバー装置１２とを用いて実現され得ることは、既に述べた通りである。なお、組織内サーバー装置１２自体が、いわゆるクラウドの構成で実現されてもよい。図示するように、クラウドサーバー装置１１は、第１データ記憶部１１０と、第１利用者機能部１１１と、タクシー会社機能部１１２とを含んで構成される。また、組織内サーバー装置１２は、第２データ記憶部１２０と、第２利用者機能部１２１と、決定者機能部１２２と、管理者機能部１２３と、利用実績確認部１２４とを含んで構成される。これらの各機能部は、例えば、コンピューターと、プログラムとで実現することが可能である。また、各機能部は、必要に応じて、記憶手段を有する。記憶手段は、例えば、プログラム上の変数や、プログラムの実行によりアロケーションされるメモリーである。また、必要に応じて、磁気ハードディスク装置やソリッドステートドライブ（ＳＳＤ）といった不揮発性の記憶手段を用いるようにしてもよい。また、各機能部の少なくとも一部の機能を、プログラムではなく専用の電子回路として実現してもよい。各部の機能の概略は、次に説明する通りである。

第１データ記憶部１１０は、クラウドサーバー装置１１が使用するデータを記憶する。第１データ記憶部１１０のデータは、クラウドサーバー装置１１内から読み書き可能である。第１データ記憶部１１０が記憶するデータの詳細については、後で別の図面を参照しながら説明する。

第１利用者機能部１１１は、利用者用モバイル端末装置３０に必要なデータを提供するとともに、利用者用モバイル端末装置３０側からデータを取得する。

タクシー会社機能部１１２は、タクシー会社用端末装置４０に必要なデータを提供するとともに、タクシー会社用端末装置４０側からデータを取得する。

第２データ記憶部１２０は、組織内サーバー装置１２が使用するデータを記憶する。第２データ記憶部１２０のデータは、組織内サーバー装置１２内から読み書き可能である。第２データ記憶部１２０が記憶するデータの詳細については、後で別の図面を参照しながら説明する。

なお、第１データ記憶部１１０と第２データ記憶部１２０との間で、データの内容の一部が重複していてもよい。前述の通り、クラウドサーバー装置１１と組織内サーバー装置１２とは相互に通信可能であり、第１データ記憶部１１０と第２データ記憶部１２０との間では、定期的にデータの同期が図られる。例えば、いわゆるマスターデータは、主に組織内サーバー装置１２側で維持され更新されるが、そのうちの必要なデータは、クラウドサーバー装置１１側にも渡される。また、取引実績（タクシーの利用実績）を表すデータは、主にクラウドサーバー装置１１側でまず取得され、適時に組織内サーバー装置１２側にも渡される。

第２利用者機能部１２１は、組織内端末装置２０を介して、利用者にデータを提示したり、利用者側からデータを取得したりする。また、第２利用者機能部１２１は、適宜、第２データ記憶部１２０へのデータの書き込み等を行う。

決定者機能部１２２は、組織内端末装置２０を介して、決定者にデータを提示したり、決定者側からデータを取得したりする。また、決定者機能部１２２は、適宜、第２データ記憶部１２０へのデータの書き込み等を行う。

管理者機能部１２３は、組織内端末装置２０を介して、管理者にデータを提示したり、管理者側からデータを取得したりする。また、管理者機能部１２３は、適宜、第２データ記憶部１２０へのデータの書き込み等を行う。

利用実績確認部１２４は、第２データ記憶部１２０内に蓄積されたタクシーの利用実績データの内容を確認する。利用実績確認部１２４は、具体的には、個々のタクシー利用実績のデータのうち、所定のアラート条件に合致するデータに関して、アラートを発生させる（アラートフラグをオンにする）。なお、利用実績確認部１２４は、利用実績を確認するために、利用者（組織の従業員）の勤怠データを外部（例えば、勤怠管理システム）から取り込んで参照するようにしてよい。勤怠データは、各日の、利用者の勤務状況（出勤時刻、退勤時刻、休日、休暇等）の情報を含む。具体的なアラート条件については、後述する。

クラウドサーバー装置１１および組織内サーバー装置１２が備えるより具体的な機能の内容については、後でさらに説明する。

図４は、タクシー利用支援システム１の代表的な処理の手順（決定者による事前承認、およびタクシーの利用）を示すシーケンス図である。以下、このシーケンス図を参照しながら、利用者がタクシーを利用する際におけるタクシー利用支援システム１の動作を説明する。

ステップＳ１からＳ４までの手順は、利用者による事前の利用申請と、決定者によるその承認のための手順である。この事前承認は、タクシーの利用のために必須ではない。後述するように決定者によって事後承認が行われてもよい。

ステップＳ１において、利用者の操作に基づき、利用者用の組織内端末装置２０は、利用申請のデータを組織内サーバー装置１２に送信する。この利用申請に関する情報は、サーバー装置１０内に保存される。

ステップＳ２において、決定者の操作に基づき、組織内サーバー装置１２は、利用申請一覧のデータを決定者用の組織内端末装置２０に送信する。決定者用の組織内端末装置２０は、利用申請一覧の情報を、画面に表示する。

ステップＳ３において、利用申請の情報を見た決定者の操作に基づき、決定者用の組織内端末装置２０は、利用申請承認のデータを、組織内サーバー装置１２に送信する。組織内サーバー装置１２は、これを受けて、その申請のステータスを「承認済み」に更新する。

ステップＳ４において、利用者の操作に基づき、組織内サーバー装置１２は、利用申請一覧のデータをその申請の利用者用の組織内端末装置２０に送信する。利用者用の組織内端末装置２０は、申請一覧の情報を画面に表示する。これにより、利用者は、自身が起こした申請が承認されているか否かを知ることができる。なお、利用申請一覧の情報を、利用者が、利用者用モバイル端末装置３０を用いて参照できるようにしてもよい。

ステップＳ５からＳ７までの手順は、利用者が実際にタクシーに乗車してから降車するまでの間における、タクシー利用支援システム１の処理である。なお、利用申請が事前に為されているか否かに関わらず、また利用申請が事前に承認されているか否かに関わらず、このステップＳ５からＳ７までの手順を実行することができる。

ステップＳ５において、利用者用モバイル端末装置３０は、乗車登録のデータを、インターネット等を介して、クラウドサーバー装置１１に送信する。本ステップの処理は、利用者が、タクシーに乗車した際に、利用者用モバイル端末装置３０を操作することによって行われる。このとき送信される乗車登録のデータは、利用者を識別するための利用者コードと、タクシー会社（および、場合によってはタクシーの車番号）を識別するためのコード情報と、乗車位置の情報（緯度および経度）と、日時とを含む。なお、利用者コードは、利用者用モバイル端末装置３０が予め保持している。タクシー会社（および、場合によってはタクシーの車番号）を識別するためのコード情報は、利用者用モバイル端末装置３０が、タクシーが備えている２次元コード情報を光学的に読み取ることによって獲得される。乗車位置の情報は、利用者用モバイル端末装置３０がＧＰＳ衛星７１から受信するＧＰＳ信号に基づいて獲得されるものである。

ステップＳ６において、利用者用モバイル端末装置３０は、経由地登録のデータを、インターネット等を介して、クラウドサーバー装置１１に送信する。本ステップの処理は、タクシーが経由地に立ち寄った際に、利用者が利用者用モバイル端末装置３０を操作することによって行われる。このとき送信される乗車登録のデータは、利用者を識別するための利用者コードと、タクシー会社（および、場合によってはタクシーの車番号）を識別するためのコード情報と、経由地の情報（緯度および経度）とを含む。

ステップＳ７において、利用者用モバイル端末装置３０は、降車登録のデータを、インターネット等を介して、クラウドサーバー装置１１に送信する。本ステップの処理は、利用者が降車する際に、利用者用モバイル端末装置３０を操作することによって行われる。このとき送信される乗車登録のデータは、利用者を識別するための利用者コードと、タクシー会社（および、場合によってはタクシーの車番号）を識別するためのコード情報と、降車位置の情報（緯度および経度）と、料金（例えば、タクシーのメーター料金と、メーター以外の有料道路料金）と、日時との情報とを含む。

図５は、タクシー利用支援システム１における処理の手順（決定者に依る事後承認）を示すシーケンス図である。ステップＳ８からＳ１１までの手順は、利用者がタクシーを利用した後に、決定者が事後的に承認する際の、タクシー利用支援システム１の処理である。なお、事前に決定者による承認が行われている場合、この事後承認は必須ではない。

ステップＳ８において、利用者の操作に基づき、組織内サーバー装置１２は、利用実績一覧のデータをその利用者用の組織内端末装置２０に送信する。利用者用の組織内端末装置２０は、利用実績一覧の情報を画面に表示する。これにより、利用者は、利用実績の情報を確認することができる。また、補完入力を必要とする利用実績がある場合には、利用者は、利用者用の組織内端末装置２０から、補完入力を行うことができる。

ステップＳ９において、利用者の操作に基づき、利用者用の組織内端末装置２０は、補完対応のデータを、組織内サーバー装置１２に対して送信する。この補完対応のデータは、利用者が補完入力したデータを含む。

ステップＳ１０において、決定者の操作に基づき、組織内サーバー装置１２は、利用実績一覧のデータをその決定者用の組織内端末装置２０に送信する。決定者用の組織内端末装置２０は、利用実績一覧の情報を画面に表示する。これにより、決定者は、利用実績の情報の承認を行うことができる。

ステップＳ１１において、決定者の操作に基づき、決定者用の組織内端末装置２０は、利用実績の承認のデータを、組織内サーバー装置１２に対して送信する。組織内サーバー装置１２は、これを受けて、その利用実績のステータスを「承認済み」に更新する。

図６は、利用されたタクシーの会社（事業者）やその支店等を特定するためのコード情報の例を示す概略図である。このコード情報は、紙等の媒体に印刷され、利用者用モバイル端末装置３０が光学的に読み取り可能なものである。図示する例では、コード情報は、二次元コードである。二次元コードの例は、ＱＲコード（登録商標）である。ただし、コード情報は、二次元コード以外の方法（例えば、バーコード、文字等で表されてもよい。また、例えば、ＲＦＩＤ（radio frequency identifier、無線識別タグ）等を用いて、利用者用モバイル端末装置３０が無線信号（電波）によるコード情報を読み取れるようにしてもよい。このコード情報は、例えば、タクシー車内に備え付けられ、あるいは置かれる。

このコード情報は、少なくともタクシー会社（事業者）を一意に識別する情報を含む。また、コード情報が、タクシー会社等の、支社、支店、部署等を識別する情報をさらに含んでもよい。さらに、コード情報が、タクシーの個別の車両を識別する情報（車番）を含んでいてもよい。つまり、タクシー会社を識別する情報や、車両を識別する情報を基に、二次元コードが生成される。利用者がタクシー利用時に、利用者用モバイル端末装置３０を用いてこのコード情報を読み取ることにより、利用者用モバイル端末装置３０は、少なくともそのタクシーを運営するタクシー会社を特定する情報を取得する。また、利用者用モバイル端末装置３０は、少なくともタクシー会社を特定する情報を、サーバー装置１０側に送信することができる。

なお、図示するように、２次元コードとともに、タクシー会社識別情報「０００１」やタクシー会社名「〇〇タクシー」を文字でも印刷するようにしてもよい。

次に、利用者用モバイル端末装置３０に表示されるユーザーインターフェースについて説明する。図７から図１１までは、タクシー利用支援システム１において、利用者がタクシーを利用する際に利用者用モバイル端末装置３０に表示されるユーザーインターフェース（画面）の例を示す概略図である。

図７は、乗車登録前において、利用者用モバイル端末装置３０に表示される画面を示す概略図である。図示するように、この画面には、「乗車記録」、「経由地記録」、「降車記録」の３つのボタンが含まれる。利用者は、いずれかのボタンを選択する（タップ等の操作）ことにより、各ボタンに対応する機能を実行させることができる。

図７に示す画面において、利用者が「乗車記録」を選択した場合、利用者用モバイル端末装置３０は、乗車記録を登録するための機能を実行させる。具体的には、利用者用モバイル端末装置３０は、ＧＰＳにより現在位置（乗車位置）を取得し、タクシーに備えられたコード情報（図６）を読み取る。また、利用者用モバイル端末装置３０は、当該利用者を識別するための利用者コードを予め記憶している。また、利用者用モバイル端末装置３０は、内部の時計から現在日時（乗車日時）を取得する。そして、利用者用モバイル端末装置３０は、これらの、現在位置（乗車位置）の情報と、タクシーから読み取ったコード情報と、利用者コードと、現在日時（乗車日時）とを含んだ乗車記録のデータを、クラウドサーバー装置１１に送信し、登録する。なお、利用者用モバイル端末装置３０は、予め利用者が行っていた利用申請の情報（車券番号）を関連付ける形で、乗車記録を登録するようにしてもよい。

図８は、乗車登録後において、利用者用モバイル端末装置３０に表示される画面を示す概略図である。図示するように、この画面には、「経由地記録」、「降車記録」の２つのボタンが含まれる。利用者は、いずれかのボタンを選択する（タップ等の操作）ことにより、各ボタンに対応する機能を実行させることができる。

図８に示す画面において、利用者が「経由地記録」を選択した場合、利用者用モバイル端末装置３０は、経由地記録を登録するための機能を実行させる。具体的には、利用者用モバイル端末装置３０は、ＧＰＳにより現在位置（経由位置）を取得する。また、利用者用モバイル端末装置３０は、当該利用者を識別するための利用者コードを予め記憶している。また、利用者用モバイル端末装置３０は、内部の時計から現在日時（経由日時）を取得する。そして、利用者用モバイル端末装置３０は、現在位置（経由位置）の情報と、利用者コードと、現在日時（経由日時）とを含んだ経由地記録のデータを、クラウドサーバー装置１１に送信し、登録する。なお、特に経由地がない場合、即ちタクシーが乗車位置から降車位置まで直行する場合には、この経由地を登録する動作は不要である。

図８に示す画面において、利用者が「降車記録」を選択した場合、利用者用モバイル端末装置３０は、降車記録を登録するための機能を実行させる。そのための画面が、次の図９、図１０、図１１である。

図９は、タクシー降車時に、利用者が金額等を入力するための画面である。図示するように、この画面は、使用理由と、乗車料金と、有料道路料金とを入力するための欄が設けられている。使用理由は、利用者がこのタクシーを利用した理由を入力するための欄である。例えば、いくつかの選択肢の中から使用理由を選択できるようなユーザーインターフェースとしてよい。また、利用者が申請時に選択した使用理由が、この画面におけるデフォルトとして表示されるようにしてもよい。また、乗車料金および有料道路料金の欄には数値を入力できるようにしている。また、この画面は、「降車確認」というボタンを含んでいる。利用者は、乗車料金等の情報を入力した後に、この「降車確認」のボタンを押す（例えば、タップする）ことができる。「降車確認」のボタンが押されると、利用者用モバイル端末装置３０は、入力された上記データを、クラウドサーバー装置１１に送信する。また、利用者用モバイル端末装置３０は、ＧＰＳにより取得した現在位置（降車位置）と、予め記憶していた利用者コードと、内部の時計から取得した現在日時（降車日時）をも、クラウドサーバー装置１１に送信する。

図１０は、降車確認画面である。この降車確認画面は、図９に示した画面において「降車確認」ボタンが押された後に、利用者用モバイル端末装置３０に表示される。図１０の降車確認画面は、クラウドサーバー装置１１が利用者用モバイル端末装置３０に表示させるものであり、タクシー会社、車番、乗車料金、有料道路料金、合計、乗車日時、降車日時といった項目のデータを含む。

図１０の画面に表示される、タクシー会社と車番とは、利用者用モバイル端末装置３０がクラウドサーバー装置１１側に送信したデータに基づく。クラウドサーバー装置１１は、マスターデータ（後述）を参照することによって、タクシー会社識別情報からタクシー会社名情報を求める。なお、車番は、特定されない場合もあり、その場合には表示されない。また、乗車料金と有料道路料金とは、図９の画面で入力された値によるものである。また、合計は、乗車料金と有料道路料金との和であり、図９の画面で入力された値に基づいてクラウドサーバー装置１１側で算出された値である。乗車日時および降車日時は、それぞれ、乗車時と降車時に、利用者用モバイル端末装置３０からクラウドサーバー装置１１に送信されたデータである。

なお、上記の降車確認画面に、経由地に関する情報をさらに表示するようにしてもよい。

降車確認画面は、「決定・乗車情報登録」のボタンと、「修正」のボタンとを含んでいる。利用者が「決定・乗車情報登録」のボタンを押した（タップ等の操作）場合、登録する旨の情報がクラウドサーバー装置１１側に伝えられ、降車確認画面に表示されていたデータをクラウドサーバー装置１１が確定する。また、利用者が「修正」のボタンを押した場合、例えば図９の画面の表示に戻って、利用者がデータを修正する操作を行うことが可能である。なお、データを確定する際に、利用者が、タクシーのサービス提供者（ドライバー等）に画面を見せて確認し合ってもよい。

図１１は、降車記録完了画面である。図１０の降車確認画面において「決定・乗車情報登録」のボタンが押された後、この図１１の降車記録完了画面の表示に移る。この降車記録完了画面もまた、クラウドサーバー装置１１が利用者用モバイル端末装置３０に表示させるものであり、タクシー会社と、車番と、乗車料金と、有料道路料金と、合計と、乗車日時と、降車日時と、車券番号の各項目のデータを含んでいる。この降車記録完了画面は、サーバー側で確定したデータを確認するためのものである。この降車記録完了画面を、利用者がタクシーのサービス提供者（ドライバー等）に見せてその内容を確認し合ってもよい。また、降車記録完了画面の段階において初めて、利用者用モバイル端末装置３０に車券番号が表示されるため、タクシーのサービス提供者（ドライバー等）は、サーバー側でデータが確定したことを確認することができる。また、タクシーのサービス提供者は、この車券番号を乗務記録あるいは他の書類等に控えておくことにより、後でこの利用実績のデータを参照しやすくなる。

図１２は、タクシーの乗車と経由地と降車との各段階で発生するデータと、その流れとをまとめた概略図である。図示するように、タクシーへの乗車時には、利用者用モバイル端末装置３０は、サーバー装置１０に、乗車記録を送信し登録する。乗車記録は、利用者コード、車券番号、乗車日時、乗車位置、タクシー会社コード情報といったデータを含む。サーバー装置１０側では、乗車記録を受け取ると、そのデータを記憶手段に書き込む。また、タクシーが経由地を経由した際には、利用者用モバイル端末装置３０は、サーバー装置１０に、経由地記録を送信し登録する。経由地記録は、利用者コード、車券番号、経由日時、経由位置といったデータを含む。サーバー装置１０側では、経由地記録を受け取ると、そのデータを記憶手段に書き込む。なお、経由地記録は、タクシーの１回の乗降車につき、例えば、０回以上Ｎ回以下（Ｎは、非負整数であり、一例としてＮ＝１０）の登録を可能とする。図示するように、タクシーの降車時には、利用者用モバイル端末装置３０は、サーバー装置１０に、降車記録を送信し登録する。降車記録は、利用者コード、車券番号、降車日時、降車位置、料金（メーター料金）、有料道路料金、使用理由といったデータを含む。サーバー装置１０側では、降車記録を受け取ると、そのデータを記憶手段に書き込む。なお、料金の情報は、利用者が端末装置の画面上等で手入力するものであってよい。

図１３は、サーバー装置１０が管理するデータの一部であり、タクシー会社、その支店等、および個々の車を識別するための情報を保持するテーブル（タクシーマスター）の構成を示す概略図である。このテーブルは２次元の表形式のデータとして構成され、タクシー会社コード、タクシー会社名、支店コード、支店名、車番号といったデータ項目を持つ。タクシー会社コードは、タクシー利用支援システム１のために各事業者に付与されたコードである。図示する例では、０００１、０００２といったコードが付与されている。タクシー会社名は、その事業者の名称等である。図示する例では、タクシー会社コードが０００１の会社の名称は「〇〇タクシー」である。また、タクシー会社コードが０００２の会社の名称は「△△自動車」である。支店コードは、タクシー会社の支店、支社、支所、部署、出張所、あるいはこれらに類するものを識別するためのコードである。また、支店コードが、タクシー会社と業務提携する別のタクシー会社（あるいは、個人）を識別するためのコードであってもよい。例えば、複数のタクシー会社が組合を形成し、その組合自体あるいはその組合を代表するタクシー会社（「チケット取り扱い会社」等とも呼ばれる。）に対してタクシー会社コードが付与される場合に、当該組合に加盟するタクシー会社等に支店コードを付与する場合があり得る。ここで挙げた「組合」は、共同して料金の請求を行うための事業者の組合である。なお、ここで挙げた支店、支社、支所、出張所、業務提携会社等を、代表して、「支店」あるいは「支店等」と呼ぶ場合がある。支店名は、上記の支店等の名称である。図示する例では、タクシー会社コードが０００１の会社では、支店コードが０３２１の代々木支店と、支店コードが０３２２の品川支店とが登録されている。タクシー会社コードが０００２の会社では、支店コードは用いられていない。また、車番号は、個々の車両を識別するために付与される番号である。図示する例では、タクシー会社コードが０００１の会社では、車番号は用いられていない。また、タクシー会社コードが０００２の会社では、０００１から０５００までの車番号が付与され、用いられている。図６で例示した二次元コードは、例えばタクシー会社コードおよび車番号の組み合わせを基に、所定の計算手順で、作成されるものである。二次元コードを読み取った場合、タクシー会社コードと、支店コードと、車番号が得られる。また、タクシー会社コードや支店コードをキーとしてこの図１３のデータを検索すると、それぞれ、タクシー会社名や支店名の情報が得られる。

図１４は、サーバー装置１０が管理するデータの一部であり、システムの利用者に関する情報を保持するテーブル（利用者マスター）の構成を示す概略図である。図示するように、このテーブルは、利用者コード、氏名、部署コード、自宅住所、自宅緯度・経度といったデータ項目を含む。なお、自宅住所と自宅緯度・経度の各データ項目については、組織内サーバー装置１２側のテーブルでのみ保持し、クラウドサーバー装置１１側のテーブルでは持たないようにしてもよい。利用者コードは、タクシー利用支援システム１のために付与され、利用者を個々に識別するためのコード情報である。氏名は、利用者の氏名である。部署コードは、当該利用者が組織内において所属する部署を識別するためのコード情報である。自宅住所は、利用者の自宅の住所である。自宅緯度・経度は、利用者の自宅の位置を緯度および経度で表した情報である。なお、データベースを検索することにより、住所から緯度および経度への変換は可能である。なお、タクシー利用支援システム１が後述するアラートを発生させる処理のために、自宅住所やその緯度・経度の情報が参照される場合がある。また、自宅住所や、その緯度・経度の情報は、限られた者（例えば、本人等）のみが参照できるよう、アクセス制御がなされる。

図１５は、サーバー装置１０が管理するデータの一部であり、個々のタクシー利用状況を蓄積するためのテーブルの構成を示す概略図である。このテーブルの各行が、１回のタクシーの利用に対応する。図示するように、このテーブルは、確認日時、車券番号、タクシー会社コード、車番号、利用者コード、乗車日時、降車日時、乗車区間、使用理由、乗車料金、有料道路料金といったデータ項目を含む。

各項目のデータの意味は、次の通りである。確認日時は、降車時のデータが最終的に確認されたときの日時である。車券番号は、１回のタクシーの利用に対応する番号である。車券番号は、例えば、利用申請が行われたとき、または利用申請がない状態で乗車記録が登録されたときに、発行される。タクシー会社コードと車番号については、図１３を参照しながら説明した通りである。利用者コードについては、図１４を参照しながら説明した通りである。乗車日時は、乗車記録を登録する処理が行われた日時である。降車日時は、降車記録を登録する処理が行われた日時である。乗車区間は、乗車記録の登録時の位置情報と、降車記録の登録時の位置情報とを基に構成されるデータである。乗車位置と降車位置のそれぞれは、緯度と経度とで表されてもよいし、緯度および経度を基に求められる地名あるいは施設名等で表されてもよい。使用理由と、乗車料金と、有料道路料金とは、降車時に登録されたデータである。なお、上記の確認日時や乗車日時や降車日時は、例えば、「ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ」（年・月・日、時・分）の形式で表現される。

なお、すべての利用者のタクシー利用状況は、図１５に示す構造を有する単一のテーブルに蓄積される。

次に、図１６から図２０までの各図を参照しながら、各機能部のさらに内部の機能構成について説明する。

図１６は、第１利用者機能部１１１内の概略機能構成を示すブロック図である。図示するように、第１利用者機能部１１１は、乗車登録機能部１１１１と、経由地登録機能部１１１２と、降車登録機能部１１１３とを含んで構成される。

乗車登録機能部１１１１は、利用者がタクシーに乗車したことをデータベースに登録する。なお、乗車登録機能部１１１１は、利用者用モバイル端末装置３０が読み取ったタクシーのコード情報（少なくとも、タクシー会社を識別する情報を含む）を、取得する。また、乗車登録機能部１１１１は、乗車時に収集する他のデータを、利用者用モバイル端末装置３０から取得する。乗車登録機能部１１１１が乗車時に取得するデータの項目については、図１２等を参照しながら説明した通りである。

経由地登録機能部１１１２は、利用者が経由地を経由したことをデータベースに登録する。経由地登録機能部１１１２は、図１２等を参照しながら説明したように、経由地記録のデータを取得して保存する。

降車登録機能部１１１３は、利用者が降車したことをデータベースに登録する。降車登録機能部１１１３は、図１２等を参照しながら説明したように、降車記録のデータを取得して保存する。

図１７は、第２利用者機能部１２１内の概略機能構成を示すブロック図である。図示するように、第２利用者機能部１２１は、自宅登録機能部１２１２と、利用申請機能部１２１３と、利用申請一覧機能部１２１４と、利用実績一覧機能部１２１５と、アラート対応機能部１２１６と、補完対応機能部１２１７とを含んで構成される。

自宅登録機能部１２１２は、利用者の自宅住所を登録する機能を有する。自宅登録機能部１２１２は、例えば利用者の操作に基づき、利用者が入力した自宅住所を図１４に示したテーブルに書き込む。また、併せて、自宅登録機能部１２１２は、登録された自宅住所に基づいて地理データ（不図示）を参照することにより、当該利用者の自宅の緯度および経度を求め、図１４に示したテーブルに書き込む。

利用申請機能部１２１３は、利用者によるタクシー利用申請の処理を行う。利用申請機能部１２１３は、利用者用の組織内端末装置２０に、乗車予定日や、乗車予定区間（乗車位置の地名と、降車位置の地名と、必要に応じて経由地の地名）や、使用理由や、当該申請を承認すべき決定者といった情報を入力（一部の項目は選択肢から選択）するための画面を表示する。利用者がそれらの項目のデータを入力（一部の項目は選択）して「申請」ボタンを押すと、利用申請機能部１２１３は、その申請を登録する。また、利用申請機能部１２１３は、適切な決定者がその利用申請を承認できる状態とする。後で説明する利用申請一覧機能部１２１４が、申請が承認されたか否かを表す情報を表示する。また、利用者がタクシーに乗車する際には、その乗車と利用申請とを関連付けることができる（例えば、乗車時に、申請を選択できる）ようにする。

なお、利用申請機能部１２１３は、申請を承認すべき決定者が不在（例えば、一時的に外出中）の場合には、決定者不在状態のまま利用申請を登録しておくことができるようにしてもよい。また、利用申請機能部１２１３は、申請時に入力されるべきデータ項目のうち、一部の項目については空白のまま申請を受け付けるようにしてよい。これらの、決定者不在での申請や、一部項目空白での申請が行われた場合、後述する補完対応機能部１２１７が、これらの不足を補完するための機能を提供する。

また、利用申請機能部１２１３は、複数の利用申請をまとめて行えるようなユーザーインターフェースを提供してもよい。例えば、特定の乗車区間を毎日繰り返して利用するような場合には、利用者が複数の利用申請をまとめて行える（複数の車券番号をまとめて申請できる）機能が便利である。

利用申請一覧機能部１２１４は、利用者用の組織内端末装置２０に、特定の利用者（ログインしている利用者）のタクシー利用申請の一覧情報を表示させる。これにより、利用者は、利用申請の状況（例えば、既に承認されているか否か等）をまとめて把握することが可能となる。利用申請一覧機能部１２１４は、表示すべき利用申請を絞り込むための検索条件を受け付けるようにしてもよい。検索条件としては、例えば、利用者名や、利用申請の状況（既に承認されているか否か）や、申請した日付を絞り込むための期間や、その他のフリーワードに関する条件を含んでよい。

利用実績一覧機能部１２１５は、利用者が利用実績を一覧できる情報を利用者用の組織内端末装置２０に表示させる機能を持つ。利用実績一覧機能部１２１５は、表示すべき利用実績を絞り込むための検索条件を受け付けるようにしてもよい。検索条件としては、例えば、利用者名や、利用した日付を絞り込むための期間や、補完入力が必要か否かを示す条件や、使用理由や、アラートの有無あるいは種別や、その他のフリーワード（例えば乗車区間等に関する検索語）に関する条件を含んでよい。検索条件が利用者に依って指定された場合には、利用実績一覧機能部１２１５は、指定された検索条件に合致する利用実績のみを一覧表示するようにする。

アラート対応機能部１２１６は、利用実績に関するアラートが発生している場合に、利用者がそのアラートに対応するためのアクションを可能とする機能を有する。例えば、アラートを含む利用実績がある場合、アラート対応機能部１２１６は、補足説明欄を表示し、利用者が当該アラートに関する補足説明を入力できるようにする。補足説明は、例えば、自由なテキストとして受け付けられる。アラート対応機能部１２１６は、利用者が入力した補足説明を当該利用実績に関連付ける形で記憶させる。また、アラート対応機能部１２１６は、決定者が利用者の利用実績を閲覧する際に、その補足説明を併せて表示できるようにする。これにより、利用者が入力した補足説明に基づいて、決定者は、その利用実績を承認するか否かを判断することができるようになる。

補完対応機能部１２１７は、補完が必要な利用実績に関して、利用者が補完入力を行うための機能を有する。補完対応が必要となるのは、例えば、次のような場合である。前述の通り、利用者は、利用申請の際に、決定者不在の状態での申請を行ったり、一部項目空白での申請を行ったりすることができる。これらの不足のある申請や、その申請に基づく利用実績に関して、補完対応機能部１２１７は、「要補完入力」であることを示す表示を行う。そして、補完対応機能部１２１７は、「要補完入力」である申請に関して、補足説明欄を表示し、利用者が補足説明を入力できるようにする。補足説明は、テキストとして受け付けられる。補完対応機能部１２１７は、利用者が入力した補足説明を当該申請に関連付ける形で記憶させる。また、補完対応機能部１２１７は、補完入力された申請（あるいはそういった申請に基づく利用実績）を決定者が閲覧する際に、その補足説明を併せて表示できるようにする。これにより、利用者が補完した内容（補足説明等）に基づいて、決定者は、その利用実績を承認するか否かを判断することができるようになる。

なお、上記の場合（一部空白、あるいは決定者不在）の他に、利用者の属するクラスに応じて、特定の使用理由での申請については、補完対応機能部１２１７が、同様に「要補完入力」として扱うようにしてもよい。一例として、特定のクラスに属する利用者が「緊急」、「夜回」、「朝駆」以外の使用理由を用いた場合に、補完対応機能部１２１７は、その申請を「要補完入力」として扱う。

図１８は、決定者機能部１２２内の概略機能構成を示すブロック図である。図示するように、決定者機能部１２２は、利用者コード発行機能部１２２０と、利用申請承認機能部１２２１と、利用申請一覧機能部１２２２と、利用実績一覧機能部１２２３と、アラート対応機能部１２２４と、補完対応機能部１２２５とを含んで構成される。

利用者コード発行機能部１２２０は、利用者に対して利用者コードを発行する。利用者コードは、タクシー利用支援システム１内におけるコード情報である。利用者コード発行機能部１２２０は、例えば、利用者となる可能性のある人（従業員等）のリストを表示し、決定者が、利用者コード発行対象の人をチェックボックス等で選択できるようにする。利用者コード発行機能部１２２０は、そのような決定者の操作に基づいて選択された利用者に、新たな利用者コードを発行する。利用者コードは、例えば連番を用いるなどの方法により、他の利用者と重複しないように決められる。利用者コード発行機能部１２２０は、発行した利用者コードを、図１４に示したテーブルの利用者コード欄に書き込む。

利用者コード発行機能部１２２０は、利用者コードの発行の完了後に、当該利用者宛に、発行された利用者コードを送る。利用者コード発行機能部１２２０は、一例として、電子メールの文面内の、ＵＲＬ（ユニフォーム・リソース・ロケーター）の文字列の中に、暗号化した利用者コードあるいは平文の利用者コードを埋め込む。これを受信した利用者は、例えば利用者用モバイル端末装置３０から、そのＵＲＬで表されるリソースにアクセスする。すると、利用者用モバイル端末装置３０内のウェブブラウザー上で稼働するアプリが、その利用者コードを利用者用モバイル端末装置３０内の記憶手段に書き込む。あるいは、そのウェブブラウザー自体が、その利用者コードを記憶手段（例えば、ブラウザーの管理情報の記憶部）に書き込む。これにより、利用者用モバイル端末装置３０は、利用者のための機能を実行する際に、当該利用者の利用者コードを記憶手段から読み出して使用することができるようになる。

利用申請承認機能部１２２１は、決定者が利用申請を承認するための機能を持つ。具体的には、利用申請承認機能部１２２１は、決定者用の組織内端末装置２０に、当該決定者による承認を必要とする申請の一覧を表示させる。なお、利用申請承認機能部１２２１は、一覧として表示する申請を絞り込むための検索条件を受け付けるようにしてもよい。また、利用申請承認機能部１２２１は、それらの申請を一括して、あるいは各申請個別に、承認するか否かを選択するための手段（例えば、「承認」あるいは「否認」のボタン）を、決定者用の組織内端末装置２０に表示させる。そして、決定者の操作に応じて、利用申請承認機能部１２２１は、それらの申請を承認あるいは否認する処理を行う。申請が承認された場合には、申請のデータにおいて、承認済のフラグがオンに更新される。つまり、申請が承認された場合には、利用申請承認機能部１２２１は、承認済の利用実績データ（利用申請データ）には承認済であることを表す情報を付加する。

利用申請一覧機能部１２２２は、利用申請の一覧を、決定者用の組織内端末装置２０に表示させる機能を持つ。利用申請一覧機能部１２２２は、表示すべき利用申請を絞り込むための検索条件を受け付けるようにしてもよい。検索条件は、例えば、利用申請一覧機能部１２１４について既に説明したものと同様の条件であってよい。

利用実績一覧機能部１２２３は、タクシーの利用実績の一覧を、決定者用の組織内端末装置２０に表示させる機能を持つ。利用実績がアラートを持つものである場合には、利用実績一覧機能部１２２３は、その利用実績について、アラートがある旨の表示を併せて行う。なお、利用実績一覧機能部１２２３は、表示すべき利用実績を絞り込むための検索条件を受け付けるようにしてもよい。検索条件は、例えば、利用者名や、日付や、使用理由や、金額（乗車料金等）についての条件であってよい。また、利用実績一覧機能部１２２３は、決定者による操作に基づき、一覧表示した利用実績のデータを承認する機能を持つ。

アラート対応機能部１２２４は、タクシーの利用実績のデータがアラートを持つものである場合に、決定者が補足説明を入力するための欄を表示する。また、アラート対応機能部１２２４は、決定者が入力する補足説明（テキスト）を受け付ける。アラート対応機能部１２２４は、受け付けた補足説明のデータを、当該利用実績のデータと関連付けて保存する。また、アラート対応機能部１２２４は、決定者による操作に基づき、アラートを持っていた利用実績のデータを承認する機能を持つ。

補完対応機能部１２２５は、タクシーの利用申請または利用実績のデータが「要補完入力」の状態である場合に、決定者が補足説明を入力するための欄を表示する。「要補完入力」となる条件については、既に述べた通りである。また、補完対応機能部１２２５は、決定者が入力する補足説明を受け付ける。補完対応機能部１２２５は、受け付けた補足説明のデータを、当該利用実績のデータと関連付けて保存する。また、補完対応機能部１２２５は、決定者による操作に基づき、「要補完入力」であった利用実績のデータを承認する機能を持つ。

図１９は、タクシー会社機能部１１２内の概略機能構成を示すブロック図である。図示するように、タクシー会社機能部１１２は、データ確定機能部１１２１と、データ編集機能部１１２２と、請求実行機能部１１２３と、請求明細出力機能部１１２５と、請求明細追加機能部１１２６と、紙券明細追加機能部１１２７とを含んで構成される。タクシー会社機能部１１２は、タクシー会社用端末装置４０に対して、タクシー会社ごとに仕分けた利用実績のデータを提供する。なお、タクシー会社機能部１１２は、当該タクシー会社に関するデータのみを、タクシー会社用端末装置４０に対して提供する。

データ確定機能部１１２１は、利用実績のデータを確定させる機能を持つ。具体的には、データ確定機能部１１２１は、利用実績の個々のデータ（「明細」と呼ぶ）の一覧を、タクシー会社用端末装置４０に表示させる。このとき、データ確定機能部１１２１は、確定済のデータと、未確定のデータとを、異なる表示方法で（例えば、異なる表示色で）表示する。データ確定機能部１１２１は、この一覧を見たタクシー会社担当者が、例えばチェックボックスをチェックするなどといった操作により、確定させる機能を有する。データ確定機能部１１２１は、タクシー会社担当者の操作に基づき、確定したデータ（明細）の確定フラグを更新する。

データ編集機能部１１２２は、利用実績のデータをタクシー会社担当者が編集できる機能を提供する。タクシー会社担当者がデータを編集する（修正する）必要が生じるのは、例えば、次のような場合である。
ａ）乗車時に電波伝搬状況が良くないなどの状況により、クラウドサーバー装置１１側で乗車記録を取得できなかった場合（降車時に、乗車記録と降車記録とがまとめて登録される場合もある）。
ｂ）利用者による操作のタイミングがずれることなどにより、乗車記録、経由地記録、降車記録の、日時あるいは位置が、実際とずれてしまった場合。
ｃ）利用者が料金の入力を誤り、タクシーのサービス提供者（ドライバー）による確認も漏れてしまった場合。

請求実行機能部１１２３は、タクシー会社側から、利用者の属する組織（企業等）の側への料金の請求を実行するための機能を有する。具体的には、請求実行機能部１１２３は、例えばタクシー会社担当者の操作等に基づき、タクシーの利用実績のうちの、確定済で且つ未請求のデータを検索して提示する。請求実行機能部１１２３は、タクシー会社担当者が、請求のためのデータを確認したのちに、請求を実行できるように、「ＯＫ」のボタンを画面に提示する。請求実行機能部１１２３は、この「ＯＫ」のボタンが押されると、請求が実行されたものとして、データ（明細）のステータスを「請求済」に更新する。また、請求実行機能部１１２３は、明細データのそれぞれに、請求日（請求実行の当日）のデータを書き込む。

請求明細出力機能部１１２５は、上記の請求に関する請求明細データを出力する機能を持つ。請求明細出力機能部１１２５は、タクシー会社用端末装置４０から、検索条件として、請求日の指定を受け付ける。請求明細出力機能部１１２５は、指定された請求日に該当するデータを、検索によって抽出する。請求明細出力機能部１１２５は、条件にしたがって抽出されたデータを、帳票として印刷出力したり、スプレッドシート用のデータとして出力したりする。これにより、タクシー会社担当者は、印刷出力された帳票（明細データの集合）や、スプレッドシートのデータを、利用者が属する組織への請求書に添付して送ることが可能となる。

請求明細追加機能部１１２６は、何らかの事情により漏れてしまった利用実績について、請求のための明細データを追加で作成する機能である。請求明細追加機能部１１２６は、タクシー会社担当者の操作に基づき、追加すべき明細データを作成する。

紙券明細追加機能部１１２７は、紙のタクシー券（紙券）に基づいて請求用の明細データを追加で作成する機能を持つ。紙券は、都合により、タクシー利用支援システム１による乗車記録や降車記録を作成することができない場合に、利用され得るものである。

図２０は、管理者機能部１２３内の概略機能構成を示すブロック図である。図示するように、管理者機能部１２３は、利用者登録機能部１２３１と、利用者変更機能部１２３２と、利用者削除機能部１２３３と、承認済申請廃棄機能部１２３４と、利用者コード発行機能部１２３５と、利用者コード更新機能部１２３６と、経理関連機能部１２３９とを含んで構成される。

利用者登録機能部１２３１は、タクシー利用支援システム１を利用する利用者を登録する機能を有する。利用者登録機能部１２３１は、例えば、別のデータベース管理システム（ＤＢＭＳ）で管理されている利用者（従業員等）のデータや、ＰＣ用の表計算ソフトが作成したスプレッドシートのデータ等をインポートすることにより、利用者を登録する。インポートされるデータは、図１４に示したテーブルが有するデータ項目の少なくとも一部を持っている。利用者登録機能部１２３１は、インポートしたデータを、図１４に示したテーブルに書き込む。また、管理者が利用者の情報を手で入力することにより利用者を登録するようにしてもよい。

利用者変更機能部１２３２は、利用者の情報を変更する。利用者変更機能部１２３２は、例えば管理者の操作に基づいて、利用者の氏名や、部署コードや、その他の属性情報を変更することができる。

利用者削除機能部１２３３は、タクシー利用支援システム１に登録されていた利用者を削除する。例えば、従業員である利用者が退職する場合に、例えば管理者の操作により、利用者削除機能部１２３３は、当該利用者の登録を削除する。利用者削除機能部１２３３は、当該ユーザーを図１４に示したテーブルから削除したり、あるいは同等のデータの更新（例えば無効フラグをオンにする）を行ったりする。削除された利用者は、タクシー利用支援システム１を使用することが出来なくなる。

承認済申請廃棄機能部１２３４は、承認済の利用申請（まだ実際にタクシーの利用が行われていない申請）のうち、所定の条件等に合致するものを廃棄するための機能を持つ。承認済申請廃棄機能部１２３４は、管理者用の組織内端末装置２０に、利用申請を検索する条件を入力するための欄を表示させる。これにより、管理者は、検索条件を設定することが可能となる。具体例として、管理者は、利用者（例えば、利用申請が承認された後に人事異動等によって所属部署が変わった従業員）の氏名等を検索条件として入力する。承認済申請廃棄機能部１２３４は、指定された検索条件にしたがって、利用申請を検索し、条件に合致した利用申請を画面に表示する。管理者は、その表示を確認し、必要に応じて廃棄対象の利用申請を選択する操作等を行い、「廃棄」ボタンを押す。この操作に基づいて、承認済申請廃棄機能部１２３４は、承認済の利用申請を廃棄することができる。

利用者コード発行機能部１２３５は、利用者に対して利用者コードを発行する。利用者コードは、タクシー利用支援システム１内におけるコード情報である。利用者コード発行機能部１２３５は、例えば管理者の操作に基づいて選択された利用者に、新たな利用者コードを発行する。利用者コード発行機能部１２３５は、発行した利用者コードを、図１４に示したテーブルの利用者コード欄に書き込む。

利用者コード更新機能部１２３６は、利用者コードを更新（変更）する機能を持つ。利用者コード更新機能部１２３６は、例えば管理者の操作に基づいて選択された利用者に、従来とは異なる利用者コードを発行する。利用者コード更新機能部１２３６は、変更後の利用者コードを用いて、図１４に示したテーブルの利用者コード欄を更新する。

経理関連機能部１２３９は、タクシーの利用に関して、経理の観点から必要な機能を提供するものである。例えば、経理関連機能部１２３９は、管理者（特に、経理担当者）が、指定された期間について、タクシー会社別に、利用実績データや、料金の合計額のデータを閲覧できるようにする。また、経理関連機能部１２３９は、利用実績データを決定者が承認済みであるか否かを確認する機能を持つ。さらに、経理関連機能部１２３９は、利用実績データを管理者が承認済みであるか否かを確認する機能を持ってもよい。また、経理関連機能部１２３９は、タクシー会社から料金が請求済であるか否かを表すフラグを、利用実績データ上で更新する機能を持つ。また、経理関連機能部１２３９は、タクシー会社からの請求が漏れている利用実績を画面上で目立つように（例えば、色を変えるなどして）表示する。また、経理関連機能部１２３９は、タクシー会社ごとに、精算用のデータ（タクシー会社からの料金請求と、支払いによる未払金の消込等のためのデータ）を出力する機能を持つ。また、経理関連機能部１２３９は、実際にタクシーが利用されたにもかかわらず何らかの理由で利用実績データがない場合等に、利用実績データを追加作成する機能を持つ。また、タクシー利用支援システム１の仕組みを使用せずにタクシーの利用が行われた場合（この場合には、例えば、紙に印刷されたタクシー利用券（紙券）が用いられる）の料金を、タクシー会社との精算のデータに反映させる機能を、経理関連機能部１２３９は、持つ。

上記のように、タクシー利用支援システム１は、企業等の会計システムとシームレスにデータのやり取りを行うことができる。

なお、前述の利用実績確認部１２４がデータの確認のために用いるアラート条件は、例えば、次の通りである。ただし、アラート条件は、ここに列挙したものに限定されない。アラート条件を、適宜、追加したり変更したりするようにしてもよい。なお、出勤時刻や退勤時刻等の勤怠データは、前述の通り参照可能である。

（１）退勤後時間超過： 当該利用者の退勤時刻よりもタクシーの乗車時刻が予め定められた所定時間を超えて離れている。
（２）降車後時間超過： タクシーの降車時刻よりも当該利用者の出勤時刻が予め定められた所定時間を超えて離れている。
（３）１日所定金額以上： 同一利用者に関してタクシーの１日の料金の合計が予め定められた所定金額以上である。
（４）徹宵／深夜早朝： 勤怠データにおいて徹宵勤務区分となっている日に、当該利用者が深夜・早朝の使用理由でタクシーを利用している。
（５）深夜早朝／所定距離以上： 深夜・早朝の使用理由でタクシーを利用している場合に、乗車地または降車地（いずれか自宅側）が、自宅位置（緯度・経度）と所定距離以上離れている。
（６）深夜早朝時間外乗車： 深夜・早朝の使用理由でタクシーを利用している場合に、勤務地ごと（あるいは部署ごと）に定められている利用可能時間帯以外に、タクシーを利用している。
（７）自宅付近乗車： 深夜早朝の使用理由以外のタクシー利用において、自宅付近（所定距離以内）での乗車位置がある。
（８）自宅付近降車： 深夜早朝の使用理由以外のタクシー利用において、自宅付近（所定距離以内）での降車位置がある。
（９）休日利用： 勤怠データ上の休日あるいは休暇の日に、タクシーの利用がある。
（１０）勤務時間外乗降： 深夜早朝の使用理由以外のタクシー利用において、乗車時刻あるいは降車時刻が、勤務時間内に収まっていない。

利用実績確認部１２４が例えば上記のようなアラート条件に基づいてタクシーの利用実績を確認する。つまり、利用実績確認部１２４は、予め定められた所定のアラート条件に合致するか否かを判定し、前記アラート条件に合致する場合には、当該利用実績データについてのアラートを発生させる。このため、適切ではないタクシー利用の可能性がある場合に、利用者に、補足説明の入力を求めることが可能となる。

なお、上述した実施形態におけるタクシー利用支援システム１内の少なくとも一部の機能をコンピューターで実現することができる。その場合、この機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢメモリー等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、一時的に、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

本実施形態についてまとめると、次の通りである。

サーバー装置は、少なくとも、利用者機能部と、データ記憶部と、決定者機能部と、輸送会社機能部とを備える。クラウドサーバー装置１１や組織内サーバー装置１２は、サーバー装置である。第１利用者機能部１１１や第２利用者機能部１２１は、利用者機能部である。第１データ記憶部１１０や第２データ記憶部１２０は、データ記憶部である。タクシー会社機能部１１２は、輸送会社機能部である。
利用者機能部は、利用者の端末装置から、輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報と輸送料金の金額の情報とを含んだ利用実績データを受信する。なお、タクシーが人を運び届けるサービスは、輸送サービスである。タクシー会社は、輸送事業者である。タクシー会社を識別する情報は、輸送事業者識別情報である。
データ記憶部は、受信された前記利用実績データを記憶し蓄積する。
決定者機能部は、前記利用者による前記輸送サービスの利用を、前記輸送サービスの実施の前または後の少なくともいずれかに承認する処理（事前承認または事後承認）を実行し、承認済の前記利用実績データには承認済であることを表す情報を付加する。
輸送会社機能部は、承認済の前記利用実績データを基に、輸送事業者の端末装置に対して、輸送事業者ごとに仕分けた前記利用実績データを提供する。

輸送事業者識別情報（タクシー会社識別情報）は、輸送事業者（タクシー会社）が有する輸送手段（タクシーの車両等）であって前記輸送サービスのために用いられる輸送手段に、光学的に読み取り可能な形態で設けられたコード情報を、利用者の端末装置が読み取ることによって取得されるものである。

利用者の端末装置は、前記輸送サービスの開始時（タクシーへの乗車時）に、前記コード情報を読み取るものである。
利用者機能部は、当該コード情報に基づく前記輸送事業者識別情報をサービス開始記録（乗車記録）の一部として前記利用者の端末装置から受信する。

利用者の端末装置は、前記輸送サービスの終了時（タクシーからの降車時）の、前記輸送サービスについての輸送料金（メーター料金や有料道路料金、およびその合計）の金額の決定（確定）後に、当該輸送料金の金額の情報を取得するものである。
利用者機能部は、当該輸送料金の金額の情報をサービス終了記録（降車記録）の一部として前記利用者の端末装置から受信する。

利用者の端末装置は、前記輸送料金の金額の情報を、利用者の手入力によって取得するものである。つまり、タクシーのメーター等から料金データを受信する手段を設ける必要がない。

輸送会社機能部は、輸送事業者の端末装置に対して、当該輸送事業者用の前記利用実績データを提供する際に、前記輸送サービスの実施の単位で、前記利用実績データを当該輸送事業者が確認済であるか否かを表す情報を併せて送信し、前記輸送事業者の端末装置から確認済であると指示された前記利用実績データについては、確認済であることを表す情報を付加する（確認済フラグの更新）。

前記輸送会社機能部は、輸送事業者の端末装置に対して、当該輸送事業者用の前記利用実績データを提供する際に、前記輸送サービスの実施の単位で、前記利用実績データについて当該輸送事業者が料金請求済であるか否かを表す情報を併せて送信し、前記輸送事業者の端末装置から料金請求済であると指示された前記利用実績データについては、料金請求済であることを表す情報を付加する（請求済フラグの更新）。

サーバー装置は、前記利用実績データの内容を確認する利用実績確認部、をさらに具備する。
利用者機能部は、前記輸送サービスの開始時（乗車時）に、前記輸送サービスの開始時の時刻（乗車時刻）の情報と前記輸送サービスの開始時の位置（乗車位置）の情報とを前記利用者の端末装置から受信するとともに、前記輸送サービスの終了時（降車時）に、前記輸送サービスの終了時の時刻（降車時刻）の情報と前記輸送サービスの終了時の位置（降車位置）の情報とを前記利用者の端末装置から受信する。
データ記憶部は、前記利用実績データの一部として、前記輸送サービスの開始時の時刻の情報と、前記輸送サービスの開始時の位置の情報と、前記輸送サービスの終了時の時刻の情報と、前記輸送サービスの終了時の位置の情報と、を記憶する。
利用実績確認部は、前記利用者の勤怠状況を表す勤怠データを参照することによって、前記勤怠データと、前記輸送サービスの開始時の時刻の情報と、前記輸送サービスの開始時の位置の情報と、前記輸送サービスの終了時の時刻の情報と、前記輸送サービスの終了時の位置の情報とが、予め定められた所定のアラート条件に合致するか否かを判定し、前記アラート条件に合致する場合には、当該利用実績データについてのアラートを発生させる。

利用者用モバイル端末装置３０（利用者端末装置）は、輸送サービスのために用いられる輸送手段に光学的に読み取り可能な形態で設けられたコード情報を読み取ることによって輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報を取得するとともに、前記輸送料金の金額の情報を取得し、前記輸送事業者識別情報と前記輸送料金の金額の情報とを含んだ利用実績データをサーバー装置に対して送信する。さらに、利用者用モバイル端末装置３０（利用者端末装置）は、前記輸送サービスの開始時に、前記コード情報を読み取ることによって前記輸送事業者識別情報を含んだ前記利用実績データを前記サーバー装置に送信し、前記輸送料金の金額の決定後に、利用者の手入力により前記輸送料金の金額の情報を取得して前記輸送料金の金額の情報を含んだ前記利用実績データを前記サーバー装置に送信し、前記輸送料金の金額の情報を含んだ確認画面を表示するとともに、当該確認画面に含まれる「登録」ボタンが操作されると前記利用実績データを確定することの通知である確定通知を前記サーバー装置に送信する。さらに、利用者用モバイル端末装置３０（利用者端末装置）は、確定通知を前記サーバー装置に送信した後に、前記サーバー装置によって付与される車券番号を画面に表示する。

以上説明したように、本実施形態によれば、過大な装置等を必要とせずに（特にタクシー等の車両側に追加の通信手段を設けずに）、料金の決済が可能となる。また、本実施形態によれば、利用者は、予めサーバー側で決定されたタクシー会社に限らず、タクシーを利用することができる。また、本実施形態によれば、利用者の端末装置が、タクシー利用時にアプリをわざわざダウンロードしてインストールする必要がない。また、本実施形態によれば、利用者の組織内における承認プロセスと、タクシーの利用プロセスと、タクシー会社からの請求プロセスとを、シームレスにつなぐことができる。

［第２実施形態］
次に、第２実施形態について、図面を参照しながら、説明する。なお、前実施形態において既に説明した事項については以下において説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。本実施形態の特徴は、クラウドサーバー装置１１が持つ機能の構成である。クラウドサーバー装置１１は、第１実施形態における第１利用者機能部１１１に代えて、本実施形態では第１利用者機能部２１１を持つように構成される。

図２１は、本実施形態における第１利用者機能部２１１の概略機能構成を示すブロック図である。図示するように、第１利用者機能部２１１は、乗車登録機能部２１１１と、経由地登録機能部２１１２と、降車登録機能部２１１３と、利用申請機能部２１１８と、利用申請一覧機能部２１１９とを含んで構成される。これらのうち、乗車登録機能部２１１１と、経由地登録機能部２１１２と、降車登録機能部２１１３とは、それぞれ、第１実施形態における乗車登録機能部１１１１と、経由地登録機能部１１１２と、降車登録機能部１１１３と同様の機能を持つ。つまり、本実施形態においても、利用者は、利用者用モバイル端末装置３０を操作することによって、乗車登録、経由地登録、降車登録といった処理を実行させることができる。本実施形態での特徴は、第１利用者機能部２１１が、利用申請機能部２１１８、および利用申請一覧機能部２１１９をも含む点である。

利用申請機能部２１１８は、第１実施形態における第２利用者機能部１２１内の利用申請機能部１２１３と同等の機能を持つ。これにより、本実施形態では、利用者は、組織内端末装置２０からだけではなく、利用者用モバイル端末装置３０からも、タクシーの利用申請の処理を行うことができる。具体的には、利用申請機能部２１１８は、利用者用モバイル端末装置３０に、利用申請機能部１２１３と同様の、申請に関する必要事項を入力（一部の項目は選択肢から選択）するための画面を表示する。また、利用者がそれらのデータを入力して「申請」ボタンを操作（タップ等）すると、利用申請機能部１２１３は、その申請を登録する。この申請のデータは、適切なタイミングで、クラウドサーバー装置１１側から組織内サーバー装置１２側にも転送される。つまり、利用申請機能部２１１８が処理する申請は、組織内サーバー装置１２側の利用申請機能部１２１３で処理された申請と同等に扱われる。つまり、適切な決定者がその利用申請を承認できる状態となる。

利用申請機能部２１１８は、ここで記載を省略している機能についても、利用申請機能部１２１３と同等の機能を持つ。

なお、本実施形態においても、第２利用者機能部１２１は、第１実施形態と同等の利用申請機能部１２１３の機能を持つ。つまり、利用者は、組織内端末装置２０を用いても、利用者用モバイル端末装置３０を用いても、同等に、タクシーの利用の申請に関する処理を行うことができる。

なお、利用申請機能部１２１３または利用申請機能部２１１８のいずれかの機能によって利用者がタクシーの利用の申請を行ったときに、当該申請について決定を行うべき決定者に対して電子メールでの通知が送られるようにしてもよい。その一例としては、新規の申請を監視するデーモンが組織内サーバー装置１２内で常時稼働するようにしておき、そのデーモンが、新規の申請に関連付けられる決定者に対して電子メールを送信するようにする。

利用申請一覧機能部２１１９は、第１実施形態における第２利用者機能部１２１内の利用申請一覧機能部１２１４と同等の機能を持つ。これにより、本実施形態では、利用者は、組織内端末装置２０からだけではなく、利用者用モバイル端末装置３０からも、タクシーの利用申請の一覧を閲覧することができる。

利用申請一覧機能部２１１９は、利用者用モバイル端末装置３０に、特定の利用者（ログインしている利用者）のタクシー利用申請の一覧情報を表示させる。これにより、利用者は、利用申請の状況（例えば、既に承認されているか否か等）をまとめて把握することが可能となる。その他の機能についても、利用申請一覧機能部２１１９は、利用申請一覧機能部１２１４と同等の機能を持つようにする。

なお、本実施形態による利用者用モバイル端末装置３０は、上記の通り、輸送サービス（タクシーのサービス）を利用するための申請データをサーバー装置に送信する。また、利用者用モバイル端末装置３０は、第１実施形態においても説明したように、降車確認が行われた際（確定通知をサーバー装置に送信した後）に、降車記録完了画面を表示する。この降車確認完了画面には、車券番号も表示されている。この車券番号は、上記の申請データに関連付けてサーバー装置によって付与された番号である。

以上、第１実施形態および第２実施形態を説明したが、本発明はさらに次のような変形例でも実施することが可能である。
変形例１： 上記実施形態では、サーバー装置１０の機能を、クラウドサーバー装置１１と組織内サーバー装置１２とに分けて、システムを構成した。変形例１として、これら両者を分けずに、１台のサーバー装置としてシステムを構成してもよい。また、サーバー装置１０の機能を、３台以上の装置に分けてシステムを構成してもよい。
変形例２： 上記実施形態では、乗車時に、利用者用モバイル端末装置３０が２次元コード情報（タクシー会社を少なくとも識別するコード情報）を読み取って、乗車記録としてその情報をサーバー側に送信するようにした。変形例２として、利用者用モバイル端末装置３０がこの２次元コード情報を読み取るのは、タクシーの乗車時から降車時までの間の（輸送サービスが行われている間の）いつ行ってもよい。また、利用者用モバイル端末装置３０が、タクシー会社を識別する情報をサーバー側に送信するのも、タクシーの乗車時から降車時までの間のいつ行ってもよい。
また、複数の変形例を、組み合わせて実施してもよい。

以上、この発明の複数の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

本発明は、例えば、企業等の組織において従業員または関係者らによる移動手段の利用の管理の目的で利用することができる。但し、本発明の利用範囲はここに例示したものには限られない。

１ タクシー利用支援システム
１０ サーバー装置
１１ クラウドサーバー装置
１２ 組織内サーバー装置
２０ 組織内端末装置
３０ 利用者用モバイル端末装置（利用者端末装置）
４０ タクシー会社用端末装置
５０ 中継装置
６１ 外部ネットワーク
６２ 組織内ネットワーク
１１０ 第１データ記憶部
１１１ 第１利用者機能部
１１２ タクシー会社機能部
１２０ 第２データ記憶部
１２１ 第２利用者機能部
１２２ 決定者機能部
１２３ 管理者機能部
１２４ 利用実績確認部
２１１ 第１利用者機能部
１１１１ 乗車登録機能部
１１１２ 経由地登録機能部
１１１３ 降車登録機能部
１２１２ 自宅登録機能部
１２１３ 利用申請機能部
１２１４ 利用申請一覧機能部
１２１５ 利用実績一覧機能部
１２１６ アラート対応機能部
１２１７ 補完対応機能部
１２２０ 利用者コード発行機能部
１２２１ 利用申請承認機能部
１２２２ 利用申請一覧機能部
１２２３ 利用実績一覧機能部
１２２４ アラート対応機能部
１２２５ 補完対応機能部
１１２１ データ確定機能部
１１２２ データ編集機能部
１１２３ 請求実行機能部
１１２５ 請求明細出力機能部
１１２６ 請求明細追加機能部
１１２７ 紙券明細追加機能部
１２３１ 利用者登録機能部
１２３２ 利用者変更機能部
１２３３ 利用者削除機能部
１２３４ 承認済申請廃棄機能部
１２３５ 利用者コード発行機能部
１２３６ 利用者コード更新機能部
１２３９ 経理関連機能部
２１１１ 乗車登録機能部
２１１２ 経由地登録機能部
２１１３ 降車登録機能部
２１１８ 利用申請機能部
２１１９ 利用申請一覧機能部

Claims (10)

1. 利用者の端末装置から、利用者を識別するための利用者コードと輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報と輸送料金の金額の情報とを含んだ利用実績データを受信する利用者機能部と、
   受信された前記利用実績データを蓄積するデータ記憶部と、
   前記利用者による前記輸送サービスの利用を、前記輸送サービスの実施の前または後の少なくともいずれかに承認する処理を実行し、承認済の前記利用実績データには承認済であることを表す情報を付加する決定者機能部と、
   前記利用者による前記輸送サービスの利用に関して、決定者の操作に基づき、承認済の前記利用実績データには承認済であることを表す情報を付加する決定者機能部と、
   輸送事業者の端末装置に対して、輸送事業者ごとに仕分けた前記利用実績データを提供する輸送会社機能部と、
   を具備するサーバー装置。
2. 前記輸送事業者識別情報は、前記輸送事業者が有する輸送手段であって前記輸送サービスのために用いられる輸送手段に、光学的に読み取り可能な形態で設けられたコード情報を、前記利用者の端末装置が読み取ることによって取得されるものである、
   請求項１に記載のサーバー装置。
3. 前記利用者の端末装置は、前記輸送サービスの開始時に、前記コード情報を読み取るものであり、
   前記利用者機能部は、当該コード情報に基づく前記輸送事業者識別情報をサービス開始記録の一部として前記利用者の端末装置から受信する、
   請求項２に記載のサーバー装置。
4. 前記利用者の端末装置は、前記輸送サービスの終了時の、前記輸送サービスについての輸送料金の金額の決定後に、当該輸送料金の金額の情報を取得するものであり、
   前記利用者機能部は、当該輸送料金の金額の情報をサービス終了記録の一部として前記利用者の端末装置から受信する、
   請求項１から３までのいずれか一項に記載のサーバー装置。
5. 前記利用者の端末装置は、前記輸送料金の金額の情報を、利用者の手入力によって取得するものである、
   請求項４に記載のサーバー装置。
6. 前記輸送会社機能部は、輸送事業者の端末装置に対して、当該輸送事業者用の前記利用実績データを提供する際に、前記輸送サービスの実施の単位で、前記利用実績データを当該輸送事業者が確認済であるか否かを表す情報を併せて送信し、前記輸送事業者の端末装置から確認済であると指示された前記利用実績データについては、確認済であることを表す情報を付加する、
   請求項１から５までのいずれか一項に記載のサーバー装置。
7. 前記輸送会社機能部は、輸送事業者の端末装置に対して、当該輸送事業者用の前記利用実績データを提供する際に、前記輸送サービスの実施の単位で、前記利用実績データについて当該輸送事業者が料金請求済であるか否かを表す情報を併せて送信し、前記輸送事業者の端末装置から料金請求済であると指示された前記利用実績データについては、料金請求済であることを表す情報を付加する、
   請求項６に記載のサーバー装置。
8. 前記利用実績データの内容を確認する利用実績確認部、
   をさらに具備し、
   前記利用者機能部は、前記輸送サービスの開始時に、前記輸送サービスの開始時の時刻の情報と前記輸送サービスの開始時の位置の情報とを前記利用者の端末装置から受信するとともに、前記輸送サービスの終了時に、前記輸送サービスの終了時の時刻の情報と前記輸送サービスの終了時の位置の情報とを前記利用者の端末装置から受信し、
   前記データ記憶部は、前記利用実績データの一部として、前記輸送サービスの開始時の時刻の情報と、前記輸送サービスの開始時の位置の情報と、前記輸送サービスの終了時の時刻の情報と、前記輸送サービスの終了時の位置の情報と、を記憶し、
   前記利用実績確認部は、前記利用者の勤怠状況を表す勤怠データを参照することによって、前記勤怠データと、前記輸送サービスの開始時の時刻の情報と、前記輸送サービスの開始時の位置の情報と、前記輸送サービスの終了時の時刻の情報と、前記輸送サービスの終了時の位置の情報とが、予め定められた所定のアラート条件に合致するか否かを判定し、前記アラート条件に合致する場合には、当該利用実績データについてのアラートを発生させる、
   請求項１から７までのいずれか一項に記載のサーバー装置。
9. 利用者の端末装置から、利用者を識別するための利用者コードと輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報と輸送料金の金額の情報とを含んだ利用実績データを受信する利用者機能部と、
   受信された前記利用実績データを蓄積するデータ記憶部と、
   前記利用者による前記輸送サービスの利用に関して、決定者の操作に基づき、承認済の前記利用実績データには承認済であることを表す情報を付加する決定者機能部と、
   輸送事業者の端末装置に対して、輸送事業者ごとに仕分けた前記利用実績データを提供する輸送会社機能部と、
   を具備するサーバー装置、としてコンピューターを機能させるためのプログラム。
10. 利用者の端末装置から、利用者を識別するための利用者コードと輸送サービスを行う輸送事業者を識別するための輸送事業者識別情報と輸送料金の金額の情報とを含んだ利用実績データを受信する利用者機能部と、
    受信された前記利用実績データを蓄積するデータ記憶部と、
    前記利用者による前記輸送サービスの利用に関して、決定者の操作に基づき、承認済の前記利用実績データには承認済であることを表す情報を付加する決定者機能部と、
    輸送事業者の端末装置に対して、輸送事業者ごとに仕分けた前記利用実績データを提供する輸送会社機能部と、
    を具備するサーバー装置と、
    前記輸送サービスのために用いられる輸送手段に光学的に読み取り可能な形態で設けられたコード情報を読み取ることによって前記輸送事業者識別情報を取得するとともに、前記輸送料金の金額の情報を取得し、前記輸送事業者識別情報と前記輸送料金の金額の情報とを含んだ利用実績データをサーバー装置に対して送信する、利用者端末装置と、
    を含むシステム。

Images