JP5914236B2 - 交通費精算システム、交通費精算方法及び交通費精算プログラム - Google Patents

Description

本発明は、出張等の外出において支払った交通費の精算を支援するための交通費精算システム、交通費精算方法及び交通費精算プログラムに関する。

企業において社員が外出する場合には、社員が移動で使用した交通機関の交通費を社員が一旦立て替えておき、後日、精算を行なうことが多い。この交通費の精算時に、社員が立て替えた交通費や経路情報を記入した申請書を企業宛に提出する必要がある。このために、移動に利用した経路や金額を記録しておく必要があり、社員にとって負担になっていた。

そこで、効率的に交通費精算の申請を行なうための技術が検討されている（例えば、特許文献１、２を参照。）。
特許文献１に記載された技術においては、複合機に接続されたＩＣカード読み取り機から読み込まれたバスや鉄道の利用履歴と勤怠管理データとを連動することで、交通費の精算処理を行なう。この文献に記載された技術においては、外出精算の申請を受け付ける外出精算申請サーバと通信可能に接続された複合機を用いる。ユーザ識別情報に従って複合機にログインした後、ＩＣカードから読み取った履歴情報を記憶する。そして、履歴情報の中で、交通機関を使用する度に運賃が発生しない定期経路に該当する履歴情報を含まない外出精算情報を表示部に表示する。そして、外出精算申請として外出精算申請サーバに送信する指示を受け付ける。

また、特許文献２に記載された技術においては、交通機関を利用すると同時に交通費の申請を行なう。この文献に記載された技術においては、交通機関処理部が、交通機関の利用に係る料金精算時に、利用者が提示したＩＣカードに記録された組織ＩＤ、利用者ＩＤを読み取るとともに、利用者の生体情報を読み取る。そして、組織ＩＤ、利用者ＩＤ及び生体情報、並びに料金情報を企業等の交通費処理部に送信する。そして、交通費処理部が、組織ＩＤ、利用者ＩＤ及び生体情報を認証し、認証結果に応じて勤務実績情報データベースに登録されている勤務実績と交通機関の利用時間が妥当であるかを判定して、妥当であると認定したときのみ交通機関の利用に係る料金の精算処理を行なう。

特開２０１１−１１８８８１号公報（第１頁、図１） 特開２０１１−８６１３７号公報（第１頁、図１）

これらの特許文献に記載されている技術を用いることにより、ＩＣカード等の交通機関カード等に蓄積された利用情報を用いて、交通費精算の申請を行なうことができる。しかしながら、特定の場所に外出する場合においても、複数の経路を利用することができる場合がある。従って、企業が想定している経路と、社員が実際に利用した経路とが異なる場合には、利用情報に基づく申請が妥当でないこともある。また、企業活動において外出する場合には、通常、予め上司等の承認を得ている。更に、企業活動の拠点が複数ある場合には、特定の場所への外出を繰り返す場合もある。このような場合にも、交通費精算の申請や承認の作業負担を軽減できることが望ましい。

本発明は、上記問題点を解決するためになされたものであり、出張等の外出において支払った交通費について、効率的な精算を支援するための交通費精算システム、交通費精算方法及び交通費精算プログラムを提供することにある。

上記問題点を解決するために、請求項１に記載の発明は、利用者、イベント場所、イベント期間、イベント内容を含めたイベントスケジュールを記録したスケジュール記憶部と、認証条件を記録した認証辞書記憶部と、交通費精算の申請を記録する申請管理記憶部と、交通費精算の申請を支援する制御部とを備えた交通費精算システムであって、前記制御部が、前記スケジュール記憶部から、利用者のイベントスケジュールを取得し、前記イベントスケジュールにおけるイベント内容を特定し、前記イベント内容と、前記認証辞書記憶部に記録された認証条件とを照合し、前記イベント内容が認証条件を充足する場合には、前記イベントスケジュールのイベント場所に基づいて移動元から移動先までの交通機関経路の交通費を算出し、前記交通費及び認証情報を含む交通費精算の申請を前記申請管理記憶部に登録することを要旨とする。

請求項２に記載の発明は、請求項１に記載の交通費精算システムにおいて、前記制御部が、前記スケジュール記憶部において、前記イベントスケジュールの直前スケジュールを特定し、前記直前スケジュールのイベント場所を移動元として特定することを要旨とする。

請求項３に記載の発明は、請求項１又は２に記載の交通費精算システムにおいて、前記制御部が、前記スケジュール記憶部において、前記イベントスケジュールの直後スケジュールを特定し、前記直後スケジュールのイベント場所を移動先として特定することを要旨とする。

請求項４に記載の発明は、請求項１〜３のいずれか一つに記載の交通費精算システムにおいて、前記制御部が、前記イベントスケジュールのイベント期間に基づいて、前記交通機関経路についての障害情報を取得した場合、前記障害情報に基づいて代替の交通機関経路を特定して交通費を算出することを要旨とする。

請求項５に記載の発明は、請求項１〜４のいずれか一つに記載の交通費精算システムにおいて、利用者毎に通勤経路を記録した利用者情報記憶部を更に備え、前記制御部が、前記利用者情報記憶部から、前記利用者の通勤経路を特定し、前記交通機関経路において、前記通勤経路を考慮して交通費を算出することを要旨とする。

請求項６に記載の発明は、請求項１〜５のいずれか一つに記載の交通費精算システムにおいて、前記制御部が、前記交通費精算の申請についての承認情報を取得した場合、前記利用者が交通機関の利用時に使用する記録媒体に対して、前記交通費のチャージ処理を実行することを要旨とする。

請求項７に記載の発明は、請求項１〜６のいずれか一つに記載の交通費精算システムにおいて、イベントスケジュールに対応させて、エビデンスを記録するエビデンス記憶部を更に備え、前記制御部が、前記イベントスケジュールの交通費精算の申請においてエビデンスの要否を特定し、エビデンスが必要な場合には、前記イベントスケジュールについてのエビデンスを前記エビデンス記憶部において検索し、前記エビデンスを取得できた場合のみ、前記交通費精算の申請を前記申請管理記憶部に登録することを要旨とする。

請求項８に記載の発明は、請求項７に記載の交通費精算システムにおいて、前記エビデンスとして、イベントスケジュールを特定した情報を含めた報告を前記エビデンス記憶部に記録したことを要旨とする。

請求項９に記載の発明は、利用者、イベント場所、イベント期間、イベント内容を含めたイベントスケジュールを記録したスケジュール記憶部と、認証条件を記録した認証辞書記憶部と、交通費精算の申請を記録する申請管理記憶部と、交通費精算の申請を支援する制御部とを備えた交通費精算システムを用いて交通費精算を支援する方法であって、前記制御部が、前記スケジュール記憶部から、利用者のイベントスケジュールを取得し、前記イベントスケジュールにおけるイベント内容を特定し、前記イベント内容と、前記認証辞書記憶部に記録された認証条件とを照合し、前記イベント内容が認証条件を充足する場合には、前記イベントスケジュールのイベント場所に基づいて移動元から移動先までの交通機関経路の交通費を算出し、前記交通費及び認証情報を含む交通費精算の申請を前記申請管理記憶部に登録することを要旨とする。

請求項１０に記載の発明は、利用者、イベント場所、イベント期間、イベント内容を含めたイベントスケジュールを記録したスケジュール記憶部と、認証条件を記録した認証辞書記憶部と、交通費精算の申請を記録する申請管理記憶部と、交通費精算の申請を支援する制御部とを備えた交通費精算システムを用いて交通費精算を支援するプログラムであって、前記制御部を、前記スケジュール記憶部から、利用者のイベントスケジュールを取得し、前記イベントスケジュールにおけるイベント内容を特定し、前記イベント内容と、前記認証辞書記憶部に記録された認証条件とを照合し、前記イベント内容が認証条件を充足する場合には、前記イベントスケジュールのイベント場所に基づいて移動元から移動先までの交通機関経路の交通費を算出し、前記交通費及び認証情報を含む交通費精算の申請を前記申請管理記憶部に登録する手段として機能させることを要旨とする。

（作用）
請求項１、９又は１０に記載の発明によれば、制御部が、スケジュール記憶部から、利用者のイベントスケジュールを取得し、イベントスケジュールにおけるイベント内容を特定する。そして、イベント内容と、認証辞書記憶部に記録された認証条件とを照合する。イベント内容が認証条件を充足する場合には、イベントスケジュールのイベント場所に基づいて移動元から移動先までの交通機関経路の交通費を算出し、交通費及び認証情報を含む交通費精算の申請を申請管理記憶部に登録する。これにより、スケジュール登録された外出について、認証条件に対応した認証情報に基づいて、効率的に交通費精算の申請を行なうことができる。

請求項２に記載の発明によれば、制御部が、スケジュール記憶部において、イベントスケジュールの直前スケジュールを特定し、直前スケジュールのイベント場所を移動元として特定する。これにより、直前のスケジュールに基づいて、交通費を計算するための移動元を特定することができる。

請求項３に記載の発明によれば、スケジュール記憶部において、イベントスケジュールの直後スケジュールを特定し、直後スケジュールのイベント場所を移動先として特定する。これにより、直後のスケジュールに基づいて、交通費を計算するための移動先を特定することができる。

請求項４に記載の発明によれば、イベントスケジュールのイベント期間に基づいて、前記交通機関経路についての障害情報を取得した場合、障害情報に基づいて代替の交通機関経路を特定して交通費を算出する。これにより、交通機関において発生した障害を考慮して、精算対象の交通費を計算することができる。

請求項５に記載の発明によれば、制御部が、利用者情報記憶部から、利用者の通勤経路を特定し、交通機関経路において、通勤経路を考慮して交通費を算出する。これにより、通勤で用いる定期券経路を考慮して、交通費を計算することができる。

請求項６に記載の発明によれば、制御部が、交通費精算の申請についての承認情報を取得した場合、利用者が交通機関の利用時に使用する記録媒体に対して、交通費のチャージ処理を実行する。これにより、効率的に交通費の支払を受けることができる。

請求項７に記載の発明によれば、制御部が、イベントスケジュールの交通費精算の申請においてエビデンスの要否を特定し、エビデンスが必要な場合には、イベントスケジュールについてのエビデンスをエビデンス記憶部において検索する。エビデンスを取得できた場合のみ、交通費精算の申請を申請管理記憶部に登録する。これにより、外出の証跡に基づいて、交通費精算を行なうことができる。

請求項８に記載の発明によれば、エビデンスとして、イベントスケジュールを特定した情報を含めた報告をエビデンス記憶部に記録する。これにより、外出の報告を証跡として用いることができる。

本発明によれば、出張等の外出において支払った交通費について、効率的な精算を支援するための交通費精算システム、交通費精算方法及び交通費精算プログラムを提供することができる。

本発明の実施形態のシステム概略図。 本発明の実施形態の各データ記憶部に記録されたデータの説明図であって、（ａ）は認証辞書記憶部、（ｂ）は申請管理記憶部、（ｃ）はスケジュール記憶部、（ｄ）は社員管理情報記憶部の説明図。 第１の実施形態の処理手順の説明図。 第１の実施形態の処理手順の説明図。 第１の実施形態の処理手順の説明図。 第２の実施形態の処理手順の説明図であって、（ａ）は申請支援処理、（ｂ）は経路照合処理の説明図。 他の実施形態の説明図であって、（ａ）は通常の移動、（ｂ）は連続移動、（ｃ）は処理手順の説明図。 他の実施形態の処理手順の説明図であって、（ａ）はエビデンス確認処理、（ｂ）は確認画面の出力処理の説明図。 他の実施形態の処理手順の説明図。

＜第１の実施形態＞
以下、本発明を具体化した実施形態を図１〜図５に従って説明する。本実施形態では、企業の社員が交通機関を利用して、出張等で外出した場合、この外出において支払った交通費を精算する場合を想定する。

本実施形態では、図１に示すように、交通機関を利用して外出する場合には、電子マネーを含む電子バリューの利用情報が記録されている記録媒体７０を用いる。この記録媒体７０には、例えば、携帯端末７１や交通機関カード７２等がある。なお、記録媒体７０は、携帯端末７１や交通機関カード７２に限定されるものではない。この携帯端末７１や交通機関カード７２は、電子バリューの利用情報（利用年月日、時刻、入場駅情報、出場駅情報、利用金額、残高、利用用途等のメモ）や、携帯端末７１や交通機関カード７２を識別するための媒体コードに関するデータを保持している。

そして、交通機関を利用する場合には、携帯端末７１や交通機関カード７２を、改札ゲート８０のカードリーダにかざす。この場合、改札ゲート８０は、乗車駅である入場駅においては、移動元を特定するための乗車駅コードを、利用情報として携帯端末７１や交通機関カード７２に記録する。一方、改札ゲート８０は、降車駅である出場駅においては、移動先を特定するための降車駅コードを、利用情報として携帯端末７１や交通機関カード７２に記録する。更に、改札ゲート８０は、乗車駅から降車駅までの交通費を算出し、携帯端末７１や交通機関カード７２に記録されている残高から差し引く。また、改札ゲート８０は、これらの利用情報を、媒体コードとともに交通機関サーバ８５に送信する。交通機関サーバ８５は、媒体コードに関連付けて利用情報を利用情報記憶部に蓄積する。

また、交通費の精算を行なうために、携帯端末７１に電子バリューをチャージする場合には、企業が保有する金融機関口座から、交通費精算対象の金額を引き落とし、携帯端末７１に記録されている残高に加算する。

また、交通機関カード７２に電子バリューをチャージする場合には、券売機や店舗等（例えばコンビニエンスストア）におけるＰＯＳ端末等のカードチャージ端末を用いて、交通機関カード７２に記録されている残高に加算する。

このような電子バリューを用いた交通費の精算は、利用者（外出者）の申請、承認者の承認に基づいて行なわれる。この交通費の精算のために、図１に示す申請支援サーバ２０を用いる。
この申請支援サーバ２０は、ＬＡＮ等のネットワークを介して、クライアント端末（１０、１５）、スケジュール管理サーバ３０、社員管理サーバ５０に接続される。更に、申請支援サーバ２０は、インターネット等のネットワークを介して、交通情報提供サーバ６０、交通機関サーバ８５に接続される。

クライアント端末（１０、１５）は、申請者や承認者等のユーザが用いるコンピュータ端末である。申請者は、クライアント端末１０を用いて、交通費精算の申請を行なう。承認者は、クライアント端末１５を用いて、申請内容を確認して、承認を行なう。このクライアント端末（１０、１５）は、図示しないディスプレイ等から構成された表示部や、キーボードやポインティングデバイス等から構成された入力部を備える。

申請支援サーバ２０は、社員の交通費精算を支援するコンピュータシステムである。申請支援サーバ２０は、図１に示すように、制御部２１、認証辞書記憶部２２、申請管理記憶部２３を備える。また、申請支援サーバ２０は、外出先（企業の各拠点や顧客先等）を特定する識別子（拠点識別子）に対して、その住所に関するデータを記録した住所管理レコードを記録した住所記憶部（図示せず）を備えている。

制御部２１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）によって実現される。そして、この制御部２１は、後述する処理（精算情報取得段階、申請支援段階、支払支援段階等の各処理等）を行なう。そのための交通費精算プログラムを実行することにより、この制御部２１は、精算情報取得手段２１１、申請支援手段２１２、支払支援手段２１３等の各手段として機能する。

精算情報取得手段２１１は、交通費を精算する対象（外出）についてのスケジュール情報を取得する処理を実行する。この精算情報取得手段２１１は、交通費精算対象（移動元、移動先）を仮記憶する記憶部（精算対象メモリ）を備えている。

申請支援手段２１２は、スケジュール情報に基づいて、交通費精算の申請を行なう処理を実行する。
支払支援手段２１３は、利用者に対して、精算対象の交通費の支払を支援する処理を実行する。

認証辞書記憶部２２には、図２（ａ）に示すように、交通費精算対象を事前に認証するための認証辞書レコード２２０が記録される。この認証辞書レコード２２０は、スケジュールに基づいた外出について、予め認証するための条件が登録された場合に記録される。この認証辞書レコード２２０は、認証管理コード、認証条件、出発地、目的地、経路、金額、補足事項に関するデータを含んで構成される。

認証管理コードデータ領域には、各認証条件を特定するための識別子に関するデータが記録される。
認証条件データ領域には、予め認証されている外出を特定するための条件に関するデータが記録される。この認証条件は、社員の属する部署やプロジェクト等に応じて設定することができる。

出発地、目的地の各データ領域には、予め認証されている外出における出発地や目的地を特定するための識別子に関するデータが記録される。この出発地や目的地については、企業の各拠点や外出先の拠点識別子や住所を用いることが可能である。

経路データ領域には、この出発地から目的地までの交通機関経路（交通機関の種別、乗車駅、降車駅）に関するデータが記録される。
金額データ領域には、この経路を利用しての移動に要する交通費に関するデータが記録される。この経路や金額は、後述する交通情報提供サーバ６０から、定期的に経路情報を取得し、この経路情報に基づいて更新される。

補足事項データ領域には、この認証条件についての補足事項に関するデータが記録される。補足事項として、例えば、認証辞書レコード２２０が登録された経緯（理由）を記録する。

申請管理記憶部２３には、図２（ｂ）に示すように、交通費精算の申請を管理するための申請管理レコード２３０が記録される。この申請管理レコード２３０は、交通費精算対象を抽出した場合に生成されて記録される。この申請管理レコード２３０は、申請管理コード、申請者、所属コード、承認者、申請日、タイトル、利用日、経路、金額、メモ、認証状況、承認状況、精算状況に関するデータを含んで構成される。

申請管理コードデータ領域には、各申請を特定するための識別子に関するデータが記録される。
申請者データ領域には、交通費精算の申請を行なう社員（申請者）を特定するための識別子に関するデータが記録される。本実施形態では、申請者を特定するための識別子として、社員管理情報記憶部５２に記録された社員コードを用いる。

所属コードデータ領域には、この申請者が属する組織（部署）を特定するための識別子に関するデータが記録される。
承認者データ領域には、この組織において、申請の承認を行なう社員（承認者）を特定するための識別子に関するデータが記録される。本実施形態では、承認者を特定するための識別子として、社員管理情報記憶部５２に記録された社員コードを用いる。

申請日データ領域には、交通費精算の申請を行なった年月日に関するデータが記録される。
タイトルデータ領域には、交通費精算の対象となるスケジュールのイベントを特定するための識別子に関するデータが記録される。例えば、イベントを表わした表題やスケジュール管理コードが用いられる。

利用日データ領域には、交通機関を利用した年月日（開始、終了）に関するデータが記録される。
経路データ領域には、外出に利用した交通機関経路に関するデータが記録される。この経路には、利用した交通機関の種別や、乗車駅や降車駅に関する情報が含まれる。

金額データ領域には、交通費の金額に関するデータが記録される。
メモデータ領域には、この申請について必要な説明に関するデータが記録される。
認証状況データ領域には、承認依頼に先立っての認証（事前認証）の有無を判定するための識別子が記録される。このデータ領域には、認証辞書記憶部２２を用いて事前認証された場合には、認証済フラグが記録される。

承認状況データ領域には、この交通費精算の申請についての承認状況を特定するためのフラグが記録される。承認者に承認依頼を行なっている場合には、このデータ領域に、申請中フラグが記録される。また、承認者によって承認が行なわれた場合には承認済フラグ、差し戻す場合には差戻フラグが記録される。

精算状況データ領域には、このスケジュールにおける外出についての交通費の精算状況を特定するためのフラグが記録される。申請管理レコード２３０が登録された場合、このデータ領域には、初期値として未精算フラグが記録される。そして、このイベントにおける外出についての交通費の精算が行なわれた場合には、精算済フラグが記録される。

スケジュール管理サーバ３０は、社員のスケジュールを管理するコンピュータシステムである。スケジュール管理サーバ３０は、社員のスケジュールを管理するためのスケジュール記憶部３２を備える。

スケジュール記憶部３２には、図２（ｃ）に示すように、社員が関わるイベント（外出を含む）のスケジュール（イベントスケジュール）についてスケジュール管理レコード３２０が記録される。このスケジュール管理レコード３２０は、社員が関わる各イベントについてのスケジュールが登録された場合に記録される。このスケジュール管理レコード３２０は、スケジュール管理コード、社員コード、所属コード、登録日、タイトル、開始日時、終了日時、イベント場所、説明に関するデータを含んで構成される。更に、外出についてのスケジュール管理レコード３２０には、外出承認状況、報告承認状況、精算状況に関するデータを含んで構成される。なお、外出承認状況〜精算状況に関するデータについては、スケジュール記憶部３２とは別の記憶部に記録するようにしてもよい。この場合には、外出承認状況〜精算状況に関するデータを、スケジュール管理コードに関連付けて記録しておく。

スケジュール管理コードデータ領域には、各スケジュールを特定するための識別子に関するデータが記録される。
社員コードデータ領域には、このスケジュールに係る社員（利用者）を特定するための識別子（社員管理情報記憶部５２に記録された社員コード）に関するデータが記録される。

所属コードデータ領域には、この社員が属する組織（部署）を特定するための識別子に関するデータが記録される。
登録日データ領域には、このスケジュールが登録された年月日及び時刻に関するデータが記録される。

タイトルデータ領域には、このスケジュールのイベントのタイトル（イベント内容）に関するデータが記録される。このタイトルとしては、例えば「○○開発会議参加」等が記録される。

開始日時データ領域には、この社員における、このイベント期間の開始時（年月日及び時刻）に関するデータが記録される。なお、自宅からイベント場所へ直接、移動する場合には「直出」フラグが記録される。

終了日時データ領域には、この社員における、このイベント期間の終了時（年月日及び時刻）に関するデータが記録される。なお、イベント場所から自宅へ直接、移動する場合には「直帰」フラグが記録される。

イベント場所データ領域には、このイベントが行なわれる場所に関するデータが記録される。このデータ領域には、この拠点の拠点識別子や住所に関するデータが記録される。更に、このイベント場所データ領域において、外出が必要なイベントかどうかを識別するための情報（外出フラグ）が記録される。また、このイベント場所は、認証辞書記憶部２２に登録された目的地の中から選択したり、認証辞書記憶部２２に登録されていない場合には、直接、入力したりすることにより設定する。イベントのために外出する場合には、このイベント場所を目的地として移動することになる。

説明データ領域には、このイベントの詳細内容（イベント内容）に関するデータが記録される。例えば、このデータ領域には、イベントの目的等が記録される。
外出承認状況データ領域には、このスケジュールについて、承認者の承認状況を特定するためのフラグが記録される。スケジュール管理レコード３２０が登録された場合、このデータ領域には、初期値として未承認フラグが記録される。そして、このスケジュールについて承認者により、外出についての承認が行なわれた場合、このデータ領域には承認済フラグが記録される。

報告承認状況データ領域には、このイベントについての報告について、承認者の承認状況を特定するためのフラグが記録される。スケジュール管理レコード３２０が登録された場合、このデータ領域には、初期値として未承認フラグが記録される。そして、このスケジュールのイベントについての報告を承認者が確認した場合、このデータ領域に承認済フラグが記録される。

精算状況データ領域には、このスケジュールにおける外出についての交通費の精算状況を特定するためのフラグが記録される。スケジュール管理レコード３２０が登録された場合、このデータ領域には、初期値として未精算フラグが記録される。そして、このイベントにおける外出についての交通費の精算が行なわれた場合には、精算済フラグが記録される。

社員管理サーバ５０は、この企業の社員の属性情報や勤務情報を管理するコンピュータシステムである。社員管理サーバ５０は、各社員の各種情報を管理するための社員管理情報記憶部５２を備えている。

社員管理情報記憶部５２は利用者情報記憶部として機能し、社員管理情報記憶部５２には、図２（ｄ）に示すように、社員の属性情報を記録した社員管理レコード５２０が記録される。この社員管理レコード５２０は、社員の登録が行なわれた場合に記録される。この社員管理レコード５２０は、社員コード、パスワード、所属コード、連絡先、自宅住所、勤務地、定期券区間、利用媒体に関するデータを含んで構成される。

社員コードデータ領域には、各社員を特定するための識別子に関するデータが記録される。
パスワードデータ領域には、この社員を認証するための情報（パスワード）に関するデータが記録される。

所属コードデータ領域には、この社員が属する組織（部署）を特定するための識別子に関するデータが記録される。
連絡先データ領域には、この社員の連絡先（電子メールアドレスや電話番号）に関するデータが記録される。

自宅住所データ領域には、この社員の自宅の住所に関するデータが記録される。
勤務地データ領域には、通常、勤務している拠点を特定するための識別子に関するデータが記録される。

定期券区間データ領域には、自宅及び勤務地まで、定期券が付与されている通勤経路に関するデータが記録される。このデータ領域には、通勤のための乗降駅、利用する交通機関に関する情報が記録される。

利用媒体データ領域には、この社員が、外出時の交通費を支払う場合に用いる記録媒体７０を特定するための識別子に関するデータが記録される。このデータ領域には、携帯端末７１又は交通機関カード７２等の媒体種別や、媒体コードに関するデータが記録される。

更に、社員管理情報記憶部５２には、各組織（部署）における承認者を特定するための承認者テーブルが記録されている。この承認者テーブルにおいては、所属コードに対して承認者の社員コードが記録されている。

交通情報提供サーバ６０は、交通機関を利用する場合の経路情報（利用する交通機関の種別や乗換え案内、所要時間や料金）を提供する。具体的には、交通情報提供サーバ６０は、乗車駅と降車駅に関する情報を取得し、乗車駅・降車駅間の利用経路についての情報を提供する。この経路情報には、利用交通機関、所要時間、料金に関する情報が含まれる。

次に、本実施形態における認証処理について、図３〜図５に従って説明する。ここでは、申請支援処理（図３）、確認処理（図４）、支払支援処理（図５）の順番に説明する。
（申請支援処理）
まず、図３を用いて、申請支援処理について説明する。この処理は、例えば、月初に前月の交通費精算を支援するために、定期的に実行される。

まず、申請支援サーバ２０の制御部２１は、未精算の外出スケジュールの特定処理を実行する（ステップＳ１−１）。具体的には、制御部２１の精算情報取得手段２１１は、スケジュール管理サーバ３０のスケジュール記憶部３２にアクセスする。そして、精算情報取得手段２１１は、イベント場所データ領域に外出フラグが記録され、交通費精算の申請が行なわれていないスケジュール管理レコード３２０を特定する。ここでは、外出承認状況データ領域、報告承認状況データ領域に、承認済フラグが記録されているスケジュール管理レコード３２０であって、精算状況データ領域に未申請フラグが記録されているレコードを抽出する。

そして、申請支援サーバ２０の制御部２１は、抽出したスケジュール管理レコード３２０の中で処理対象のスケジュールを特定し、以下の処理を実行する。
ここでは、申請支援サーバ２０の制御部２１は、移動元、移動先の特定処理を実行する（ステップＳ１−２）。具体的には、制御部２１の申請支援手段２１２は、社員管理サーバ５０にアクセスする。そして、精算情報取得手段２１１は、社員管理情報記憶部５２から、処理対象のスケジュール管理レコード３２０の社員コードが記録されている社員管理レコード５２０を抽出する。次に、精算情報取得手段２１１は、社員管理レコード５２０から、この社員の勤務地情報を取得する。また、スケジュール管理レコード３２０の開始日時データ領域、終了日時データ領域に「直出」フラグ、「直帰」フラグが記録されている場合には、精算情報取得手段２１１は、社員管理レコード５２０から、この社員の自宅住所を取得する。

そして、精算情報取得手段２１１は、「直出」フラグ、「直帰」フラグの有無に基づいて、往路、復路の移動元や移動先を特定する。
スケジュール管理レコード３２０に「直出」フラグ、「直帰」フラグのいずれもが記録されていない場合には、精算情報取得手段２１１は、往路について、勤務地を移動元、イベント場所を移動先として特定し、復路については、イベント場所を移動元、勤務地を移動先として特定する。

また、スケジュール管理レコード３２０に「直出」フラグのみが記録されている場合には、精算情報取得手段２１１は、往路について、自宅住所を移動元、イベント場所を移動先として特定し、復路については、イベント場所を移動元、勤務地を移動先として特定する。

また、スケジュール管理レコード３２０に「直帰」フラグのみが記録されている場合には、精算情報取得手段２１１は、往路について、勤務地を移動元、イベント場所を移動先として特定し、復路については、イベント場所を移動元、自宅住所を移動先として特定する。

また、スケジュール管理レコード３２０に「直出」フラグ、「直帰」フラグの両方が記録されている場合には、精算情報取得手段２１１は、往路について、自宅住所を移動元、イベント場所を移動先として特定し、復路については、イベント場所を移動元、自宅住所を移動先として特定する。
そして、精算情報取得手段２１１は、特定した移動元から移動先までの交通費を精算対象として精算対象メモリに仮記憶する。

次に、申請支援サーバ２０の制御部２１は、認証条件との照合処理を実行する（ステップＳ１−３）。具体的には、制御部２１の申請支援手段２１２は、スケジュール管理レコード３２０に記録されているタイトル、イベント場所、説明と、認証辞書記憶部２２に記録されている各認証条件とを比較する。

次に、申請支援サーバ２０の制御部２１は、認証条件を充足するかどうかについての判定処理を実行する（ステップＳ１−４）。具体的には、制御部２１の申請支援手段２１２は、スケジュール管理レコード３２０に記録されている内容が認証条件に該当する場合には、認証条件を充足すると判定する。

スケジュール管理レコード３２０に記録されている内容が認証条件に該当せず、認証条件を充足しないと判定した場合（ステップＳ１−４において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、経路候補の取得処理を実行する（ステップＳ１−５）。具体的には、制御部２１の申請支援手段２１２は、開始日時の年月日、移動元（出発地）から移動先（目的地）までの往路情報、終了日時の年月日、移動元（目的地）から移動先（出発地）までの復路情報を、交通情報提供サーバ６０に提供する。なお、イベント場所として、拠点識別子が記録されている場合には、申請支援手段２１２は、住所記憶部（図示せず）において、この拠点識別子が記録された住所管理レコードを特定し、この住所管理レコードから拠点の住所に関するデータを取得する。そして、申請支援手段２１２は、この住所から所定範囲内に存在する駅を移動元や移動先として特定する。

次に、申請支援手段２１２は、交通情報提供サーバ６０から、往路情報、復路情報に対応した往復の経路情報（経路候補）を取得する。この経路情報には、所要時間や交通費の金額に関する情報が含まれる。そして、申請支援手段２１２は、新たな申請管理コードを付与し、取得した経路情報（経路、金額）を記録した申請管理レコード２３０を生成し、申請管理記憶部２３に登録する。この申請管理レコード２３０には、スケジュール管理レコード３２０に記録されている社員コード、所属コード、タイトルを記録する。更に、利用日データ領域には、開始日時、終了日時の年月日を記録する。なお、交通情報提供サーバ６０において、複数の経路候補を取得した場合には、申請支援手段２１２は、すべての経路情報を申請管理レコード２３０の経路データ領域に記録する。

次に、申請支援サーバ２０の制御部２１は、未認証の記録処理を実行する（ステップＳ１−６）。具体的には、制御部２１の申請支援手段２１２は、生成した申請管理レコード２３０の認証状況データ領域に未認証フラグを記録する。

一方、スケジュール管理レコード３２０に記録されている内容が認証条件に該当し、認証条件を充足すると判定した場合（ステップＳ１−４において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、認証済み経路の取得処理を実行する（ステップＳ１−７）。具体的には、制御部２１の申請支援手段２１２は、認証条件を充足した認証辞書レコード２２０に記録されている経路情報を取得する。そして、申請支援手段２１２は、新たな申請管理コードを付与し、取得した経路情報（経路、金額）を記録した申請管理レコード２３０を生成し、申請管理記憶部２３に登録する。この場合にも、この申請管理レコード２３０には、スケジュール管理レコード３２０に記録されている社員コード、所属コード、タイトルを記録する。更に、利用日データ領域には、開始日時、終了日時の年月日を記録する。

次に、申請支援サーバ２０の制御部２１は、認証済の記録処理を実行する（ステップＳ１−８）。具体的には、制御部２１の申請支援手段２１２は、生成した申請管理レコード２３０の認証状況データ領域に認証済フラグを記録する。

次に、申請支援サーバ２０の制御部２１は、定期券区間の特定処理を実行する（ステップＳ１−９）。具体的には、制御部２１の申請支援手段２１２は、この社員の社員管理レコード５２０に記録されている定期券区間情報を取得する。

次に、申請支援サーバ２０の制御部２１は、交通費の計算処理を実行する（ステップＳ１−１０）。具体的には、制御部２１の申請支援手段２１２は、申請管理レコード２３０に記録された経路において、定期券区間と重複している区間がある場合には、重複区間を除いた往路情報、復路情報（修正情報）を特定する。そして、申請支援手段２１２は、修正情報を交通情報提供サーバ６０に送信して、修正経路情報（経路、金額）を取得する。そして、申請支援手段２１２は、修正経路情報を用いて、申請管理レコード２３０の経路、金額を記録する。
以上の処理を、すべての未精算の外出スケジュールについて繰り返す。

そして、申請支援サーバ２０の制御部２１は、確認通知処理を実行する（ステップＳ１−１１）。具体的には、制御部２１の申請支援手段２１２は、新たに登録した申請管理レコード２３０に記録されている社員コードを取得する。次に、申請支援手段２１２は、取得した社員コードに関連付けられている連絡先情報を、社員管理サーバ５０の社員管理情報記憶部５２から取得する。そして、申請支援手段２１２は、取得した連絡先に対して、確認通知を送信する。この確認通知には、交通費精算の申請が登録されたことを示すメッセージを含める。

（確認処理）
次に、図４を用いて、確認処理を説明する。この確認処理は、申請者が交通費精算を申請する場合に行なわれる。ここでは、確認通知を受信した申請者は、クライアント端末１０を用いて、申請支援サーバ２０にアクセスする。

まず、申請支援サーバ２０の制御部２１は、申請者認証処理を実行する（ステップＳ２−１）。ここでは、申請者についての利用者認証処理を行なう。具体的には、制御部２１の申請支援手段２１２は、クライアント端末１０のディスプレイに利用者認証画面を出力する。この利用者認証画面には、社員コード及びパスワードの入力欄が設けられている。申請支援手段２１２は、利用者認証画面に入力された社員コード及びパスワードを取得し、社員管理サーバ５０の社員管理情報記憶部５２を用いて利用者認証を行なう。社員コード及びパスワードを用いて利用者認証ができない場合には、申請支援サーバ２０の利用を拒否する。一方、社員コード及びパスワードを用いて利用者認証を完了した場合には、申請支援手段２１２は、利用者認証により特定された社員コードを仮記憶する。

次に、申請支援サーバ２０の制御部２１は、確認画面の出力処理を実行する（ステップＳ２−２）。具体的には、制御部２１の申請支援手段２１２は、利用者認証された社員コードが申請者データ領域に記録された申請管理レコード２３０であって、承認状況データ領域に未申請フラグが記録されたレコードを抽出する。そして、申請支援手段２１２は、抽出した申請管理レコード２３０の内容を一覧表示させた申請確認画面を生成する。この申請確認画面においては、スケジュール年月日（申請管理レコード２３０の開始日時、終了日時）に関連付けて経路情報が候補経路として出力される。なお、申請管理レコード２３０に複数の経路候補が記録されている場合には、すべての経路情報を候補経路として申請確認画面に含める。更に、認証状況データ領域に認証済フラグが記録されている場合には、認証済みであることを示すアイコンを申請確認画面に含める。

更に、このアイコンには、認証辞書記憶部２２の認証辞書レコード２２０を特定するためのリンク情報が記録されている。このアイコンを選択することにより、認証辞書レコード２２０の内容を表示させることができる。そして、認証辞書レコード２２０の補足事項を確認することにより、認証の適否を判断することができる。

そして、申請支援手段２１２は、クライアント端末１０のディスプレイに申請確認画面を出力する。申請者は、この申請確認画面を用いて、申請内容を確認する。申請内容の確認を終了した場合には、申請確認画面において確認完了入力を行なう。一方、表示された経路と、実際に利用した経路とが異なる場合には、申請確認画面において経路を修正する。また、複数の経路候補が含まれている場合には、利用した経路を選択する。また、この申請について説明が必要な場合には、申請確認画面のメモ欄に説明を入力する。

そして、申請支援サーバ２０の制御部２１は、確認完了かどうかについての判定処理を実行する（ステップＳ２−３）。具体的には、制御部２１の申請支援手段２１２は、認証確認画面において、確認完了入力が行なわれた場合には、確認完了と判定する。一方、修正入力が行なわれることにより、確認完了でないと判定した場合（ステップＳ２−３において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、修正の受付処理を実行する（ステップＳ２−４）。具体的には、制御部２１の申請支援手段２１２は、申請確認画面において修正された内容を用いて、申請管理レコード２３０を更新する。

そして、申請支援サーバ２０の制御部２１は、認証済み経路において修正があるかどうかについての判定処理を実行する（ステップＳ２−５）。具体的には、制御部２１の申請支援手段２１２は、修正された申請管理レコード２３０において認証済フラグが記録されているかどうかを確認する。

申請管理レコード２３０に認証済フラグが記録されており、認証済み経路において修正があると判定した場合（ステップＳ２−５において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、未認証への変更処理を実行する（ステップＳ２−６）。具体的には、制御部２１の申請支援手段２１２は、申請管理レコード２３０の認証状況データ領域に記録されている認証済フラグを削除し、申請確認画面において認証済みであることを示すアイコンを消去する。そして、ステップＳ２−３に戻る。

一方、認証状況データ領域に認証済フラグが記録された申請管理レコード２３０における修正がなく、認証済み経路において修正がないと判定した場合（ステップＳ２−５において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、未認証への変更処理（ステップＳ２−６）をスキップして、ステップＳ２−３に戻る。

そして、確認完了入力が行なわれることにより、確認完了と判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、承認依頼処理を実行する（ステップＳ２−７）。具体的には、制御部２１の申請支援手段２１２は、申請管理レコード２３０の承認状況データ領域に申請中フラグを記録する。そして、申請支援手段２１２は、申請管理レコード２３０に記録されている所属コードを取得し、社員管理サーバ５０の承認者テーブルにおいて、この所属コードに関連付けられた承認者の社員コードを取得する。そして、申請支援手段２１２は、承認者の社員コードを、申請管理レコード２３０の承認者データ領域に記録する。更に、申請支援手段２１２は、社員管理サーバ５０の社員管理情報記憶部５２から、承認者の社員コードに関連付けられたメールアドレスを取得し、このメールアドレスに対して、承認依頼を送信する。この承認依頼には、未承認の交通費精算の申請があることを示すメッセージを含める。

承認依頼を受信した承認者は、クライアント端末１５を用いて、申請支援サーバ２０にアクセスする。この場合にも、申請支援サーバ２０の制御部２１は、承認者認証処理を実行する（ステップＳ２−８）。ここでは、ステップＳ２−１における利用者認証処理と同様に、承認者についての利用者認証処理を行なう。

次に、申請支援サーバ２０の制御部２１は、承認処理を実行する（ステップＳ２−９）。具体的には、制御部２１の申請支援手段２１２は、利用者認証された社員コードが承認者データ領域に記録された申請管理レコード２３０であって、承認状況データ領域に申請中フラグが記録されているレコードを抽出する。そして、申請支援手段２１２は、抽出した申請管理レコード２３０の内容を一覧表示させた承認確認画面を生成する。この承認確認画面においては、スケジュール年月日（申請管理レコード２３０の開始日時、終了日時）に関連付けた経路情報を含める。更に、認証状況データ領域に認証済フラグが記録されている場合には、認証済みであることを示すアイコンを承認確認画面に含める。

そして、申請支援手段２１２は、クライアント端末１５のディスプレイに承認確認画面を出力する。承認者は、承認確認画面を用いて申請内容を確認し、承認結果を入力する。この場合、申請支援手段２１２は、申請確認画面において入力された承認結果を用いて、申請管理レコード２３０を更新する。ここで、承認入力が行なわれた場合には、申請支援手段２１２は、申請管理レコード２３０の承認状況データ領域に承認済フラグを記録する。一方、差戻入力が行なわれた場合には、申請支援手段２１２は、申請管理レコード２３０の承認状況データ領域に差戻フラグを記録する。

（支払支援処理）
次に、図５を用いて、支払支援処理を説明する。この支払支援処理は、定期的に実行される。

ここでは、申請支援サーバ２０の制御部２１は、承認情報の取得処理を実行する（ステップＳ３−１）。具体的には、制御部２１の支払支援手段２１３は、申請管理記憶部２３から、承認状況データ領域に承認済フラグが記録されており、精算状況データ領域に未精算フラグが記録された申請管理レコード２３０を抽出する。

次に、申請支援サーバ２０の制御部２１は、携帯端末の利用かどうかについての判定処理を実行する（ステップＳ３−２）。具体的には、制御部２１の支払支援手段２１３は、社員管理サーバ５０の社員管理情報記憶部５２にアクセスする。次に、支払支援手段２１３は、抽出した申請管理レコード２３０の社員コードが記録されている社員管理レコード５２０を取得する。そして、支払支援手段２１３は、社員管理レコード５２０に記録されている利用媒体を特定する。利用媒体として携帯端末が記録されている場合には、携帯端末の利用と判定する。

携帯端末の利用と判定した場合（ステップＳ３−２において「ＹＥＳ」の場合）には、申請支援サーバ２０の制御部２１は、オートチャージ処理を実行する（ステップＳ３−３）。具体的には、制御部２１の支払支援手段２１３は、社員管理レコード５２０に記録されている媒体コードを取得する。そして、支払支援手段２１３は、交通機関サーバ８５に対して、申請管理レコード２３０に記録されている金額について、企業口座から媒体コードの携帯端末７１への、電子バリューのチャージ依頼を行なう。これにより、携帯端末７１において、電子バリューの残高が更新される。

一方、利用媒体として交通機関カードが登録されており、携帯端末の利用でないと判定した場合（ステップＳ３−２において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、チャージ伝票の発行処理を実行する（ステップＳ３−４）。具体的には、制御部２１の支払支援手段２１３は、店舗等において、利用可能なチャージ伝票を作成し出力する。このチャージ伝票には、精算対象の金額に関する情報が印字される。このチャージ伝票を、所定の店舗等に持参した場合、店舗等の店頭に設置されたＰＯＳ端末において、チャージ伝票を読み取り、この伝票に表示されている金額相当の電子バリューを、交通機関カード７２にチャージを行なう。これにより、交通機関カード７２において、電子バリューの残高が更新される。そして、店舗等は、回収したチャージ伝票を企業に提供して、チャージした金額を回収する。

以上、本実施形態によれば、以下に示す効果を得ることができる。
（１）上記実施形態では、申請支援サーバ２０の制御部２１は、認証条件との照合処理を実行する（ステップＳ１−３）。そして、スケジュール管理レコード３２０に記録されている内容が認証条件に該当し、認証条件を充足すると判定した場合（ステップＳ１−４において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、認証済み経路の取得処理（ステップＳ１−７）、認証済の記録処理（ステップＳ１−８）を実行する。これにより、予め辞書に登録されている外出の交通費については効率的に精算を行なうことができる。

（２）上記実施形態では、スケジュール管理レコード３２０に記録されている内容が認証条件に該当せず、認証条件を充足しないと判定した場合（ステップＳ１−４において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、経路候補の取得処理を実行する（ステップＳ１−５）。これにより、移動元や移動先に応じた経路候補を参照しながら、交通費清算の申請を行なうことができる。

（３）上記実施形態では、申請支援サーバ２０の制御部２１は、定期券区間の特定処理（ステップＳ１−９）、交通費の計算処理（ステップＳ１−１０）を実行する。これにより、定期券を利用している区間を考慮して交通費を精算することができる。

（４）上記実施形態では、申請支援サーバ２０の制御部２１は、移動元、移動先の特定処理を実行する（ステップＳ１−２）。ここで、精算情報取得手段２１１は、「直出」フラグ、「直帰」フラグの有無に基づいて、往路、復路の移動元や移動先を特定する。外出する場合、時間帯によっては、自宅から直接、出かけたり、自宅に直接戻ったりすることがある。このような状況を考慮して、交通費を精算することができる。

（５）上記実施形態では、申請支援サーバ２０の制御部２１は、確認画面の出力処理を実行する（ステップＳ２−２）。これにより、交通費精算の経路等を確認して申請を行なうことができる。

（６）上記実施形態では、申請支援サーバ２０の制御部２１は、認証状況データ領域に認証済フラグが記録されている場合には、認証済みであることを示すアイコンを申請確認画面に含める。これにより、予め認証されていることを示すアイコンを用いて、効率的に承認作業を行なうことができる。

（７）上記実施形態では、申請支援サーバ２０の制御部２１は、認証済み経路において修正があるかどうかについての判定処理を実行する（ステップＳ２−５）。申請管理レコード２３０に認証済フラグが記録されており、認証済み経路において修正があると判定した場合（ステップＳ２−５において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、未認証への変更処理を実行する（ステップＳ２−６）。これにより、認証条件から外れた場合には、この状況を考慮して承認作業を行なうことができる。

（８）上記実施形態では、申請支援サーバ２０の制御部２１は、承認処理を実行する（ステップＳ２−９）。認証状況データ領域に認証済フラグが記録されている場合には、認証済みであることを示すアイコンを承認確認画面に含める。これにより、予め認証されていることを示すアイコンを用いて、効率的に承認作業を行なうことができる。

（９）上記実施形態では、携帯端末の利用と判定した場合（ステップＳ３−２において「ＹＥＳ」の場合）には、申請支援サーバ２０の制御部２１は、オートチャージ処理を実行する（ステップＳ３−３）。これにより、携帯端末７１を利用している場合には、チャージ端末においてチャージする必要がなく、効率的に精算された交通費を受け取ることができる。

（１０）上記実施形態では、利用媒体として交通機関カードが登録されており、携帯端末の利用でないと判定した場合（ステップＳ３−２において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、チャージ伝票の発行処理を実行する（ステップＳ３−４）。これにより、オートチャージできない場合にも、精算された交通費を効率的に受け取ることができる。

＜第２の実施形態＞
本発明を具体化した第２の実施形態を図６に従って説明する。第１の実施形態では、スケジュール管理サーバ３０に登録されたスケジュールに基づいて、交通費精算についての申請を支援する処理を実行する。第２の実施形態では、携帯端末７１や交通機関カード７２に記録された交通機関の利用情報に基づいて交通費精算を行なうための構成であり、同様の部分については詳細な説明を省略する。

この場合には、精算情報取得手段２１１に、カード情報のフィルタリングを行なうためのキーワードを登録しておく。具体的には、携帯端末７１や交通機関カード７２にチャージされた電子バリューの利用において、交通費精算対象となる利用情報のみを抽出するためのキーワードが記録される。

更に、本実施形態では、申請者が用いるクライアント端末１０には、カードリーダが接続されている。このカードリーダを用いることにより、携帯端末７１や交通機関カード７２に記録されている利用情報や、媒体コードを取得する。この媒体コードを用いることにより、交通機関サーバ８５に蓄積されている利用情報を取得することができる。

また、社員管理サーバ５０には、各社員の出勤カレンダを記録しておく。この出勤カレンダには、各社員の出勤予定日や休日に関する情報が記録されている。
以下、申請支援処理を、図６に従って説明する。この処理は、社員が、交通費精算の申請を行なう場合に実行される。

図６（ａ）に示すように、まず、申請支援サーバ２０の制御部２１は、ステップＳ２−１と同様に、申請者認証処理を実行する（ステップＳ４−１）。
次に、申請支援サーバ２０の制御部２１は、ステップＳ１−１と同様に、未精算の外出スケジュールの特定処理を実行する（ステップＳ４−２）。

次に、申請支援サーバ２０の制御部２１は、利用情報の取得処理を実行する（ステップＳ４−３）。具体的には、制御部２１の精算情報取得手段２１１は、クライアント端末１０のディスプレイに、カードリーダに、携帯端末７１や交通機関カード７２をかざすようにメッセージを出力する。次に、精算情報取得手段２１１は、クライアント端末１０のカードリーダにおいて読み取った利用情報を照合対象として取得する。ここで、精算情報取得手段２１１は、携帯端末７１や交通機関カード７２から媒体コードを取得し、交通機関サーバ８５から、この媒体コードに関連付けられた利用情報を照合対象として取得するようにしてもよい。

次に、申請支援サーバ２０の制御部２１は、利用情報のフィルタリング処理を実行する（ステップＳ４−４）。具体的には、制御部２１の精算情報取得手段２１１は、取得した利用情報において利用用途を特定する。利用用途において、交通機関の利用以外の支払（例えば、物品購入）については処理対象外として除外する。また、精算情報取得手段２１１は、社員管理サーバ５０にアクセスし、この社員の出勤カレンダ情報（出勤日）を取得する。そして、精算情報取得手段２１１は、出勤カレンダ情報において、休暇日や休日についての利用情報についても対象外として除外する。

次に、申請支援サーバ２０の制御部２１は、スケジュール照合処理を実行する（ステップＳ４−５）。具体的には、制御部２１の精算情報取得手段２１１は、フィルタリングした利用情報及び特定したスケジュール管理レコード３２０を申請支援手段２１２に供給する。この場合、申請支援手段２１２は、利用情報に記録されている利用年月日及び時刻と、スケジュール管理レコード３２０に記録されている開始日時〜終了日時（イベント期間）とを比較する。

次に、申請支援サーバ２０の制御部２１は、経路照合処理を実行する（ステップＳ４−６）。この処理においては、利用情報の利用日とイベント期間（年月日）とが対応するレコード毎に、図６（ｂ）に示す以下の処理を実行する。

ここでは、申請支援サーバ２０の制御部２１は、ステップＳ１−２と同様に、移動元、移動先の特定処理を実行する（ステップＳ４−６１）。
次に、申請支援サーバ２０の制御部２１は、ステップＳ１−５と同様に、経路候補の取得処理を実行する（ステップＳ４−６２）。

次に、申請支援サーバ２０の制御部２１は、対応経路があるかどうかについての判定処理を実行する（ステップＳ４−６３）。具体的には、制御部２１の申請支援手段２１２は、利用情報に含まれる経路が、先のステップで取得した経路候補の中に含まれるかどうかを確認する。利用情報に含まれる経路が経路候補の中に含まれる場合には、対応経路があると判定する。

利用情報に含まれる経路が経路候補の中に含まれておらず、対応経路がないと判定した場合（ステップＳ４−６３において「ＮＯ」の場合）、このレコードについての経路照合処理を終了する。

一方、利用情報に含まれる経路が経路候補の中に含まれており、対応経路があると判定した場合（ステップＳ４−６３において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、ステップＳ１−９、Ｓ１−１０と同様に、定期券区間の特定処理（ステップＳ４−６４）、交通費の計算処理（ステップＳ４−６５）を実行する。

次に、申請支援サーバ２０の制御部２１は、申請登録処理を実行する（ステップＳ４−６６）。具体的には、制御部２１の申請支援手段２１２は、社員コード、所属コード、申請日、タイトル、利用日、経路、金額を含めた申請管理レコード２３０を生成し、申請管理記憶部２３に登録する。

そして、利用情報の利用日とイベント期間とが対応する全レコードについて処理を終了した場合、図６（ａ）の処理に戻る。
この場合、イベント期間から所定時間内に含まれる利用情報を検出できず、スケジュールに対応する移動実績がないレコードを検出した場合、申請支援サーバ２０の制御部２１は、不整合の確認処理を実行する（ステップＳ４−７）。具体的には、制御部２１の申請支援手段２１２は、クライアント端末１０のディスプレイに確認画面を出力する。この確認画面には、利用情報と対応しないスケジュール管理レコード３２０、及びスケジュール管理レコード３２０に対応しない利用情報について注意喚起するための一覧表示が含まれる。

利用情報に対応するスケジュール管理レコード３２０がない場合には、スケジュールの登録忘れの可能性がある。このスケジュールの登録忘れにおいて、新たにスケジュール管理レコード３２０を登録する場合に、事後登録アイコンを選択する。

この場合には、申請支援サーバ２０の制御部２１は、スケジュールの事後登録処理を実行する（ステップＳ４−８）。具体的には、制御部２１の申請支援手段２１２は、クライアント端末１０のディスプレイにスケジュール登録画面を出力する。このスケジュール登録画面には、スケジュールのタイトル、開始日時、終了日時、場所、説明等の入力欄が含まれる。そして、各入力欄への設定を終了した場合、申請支援手段２１２は、スケジュール登録画面に入力された内容について、スケジュール管理サーバ３０において登録を行なう。

次に、申請支援サーバ２０の制御部２１は、申請登録処理を実行する（ステップＳ４−９）。具体的には、制御部２１の申請支援手段２１２は、確認画面において、事後登録されたスケジュール管理レコード３２０と、利用情報とを照合する。照合ができた場合には、申請支援手段２１２は、申請管理レコード２３０を生成して、申請管理記憶部２３に登録する。

スケジュール管理レコード３２０に対応する利用情報がない場合には、現金支払等のように携帯端末７１や交通機関カード７２を使用しないで交通機関を利用した可能性がある。この携帯端末７１や交通機関カード７２を使用しなかった場合について、交通費精算の申請を行なう場合には、申請アイコンを選択する。

この場合には、申請支援サーバ２０の制御部２１は、ステップＳ１−５と同様に、経路候補の取得処理を実行する（ステップＳ４−１０）。
次に、申請支援サーバ２０の制御部２１は、申請登録処理を実行する（ステップＳ４−１１）。具体的には、制御部２１の申請支援手段２１２は、クライアント端末１０のディスプレイに申請入力画面を出力する。この申請入力画面においては、タイトル、利用日、経路、金額の入力欄が設けられている。タイトル、利用日の各入力欄には、対応する利用情報がないスケジュール管理レコード３２０から取得したタイトルやイベント期間（年月日）に関する情報が初期設定される。この経路や金額の各入力欄には、先のステップにおいて取得した経路候補（経路及び金額）に関する情報が初期設定されている。申請者は、この申請入力画面を用いて、申請内容を確認する。そして、申請の経路と、実際に利用した経路とが異なる場合には、申請確認画面において経路を修正する。確認を終了した場合、申請入力画面において確認終了入力を行なう。確認終了入力を検知した申請支援手段２１２は、申請入力画面において修正された内容を用いて、申請管理レコード２３０を登録する。
次に、申請支援サーバ２０の制御部２１は、ステップＳ２−７と同様に、承認依頼処理を実行する（ステップＳ４−１２）。

以上、本実施形態によれば、以下に示す効果を得ることができる。
（１１）上記実施形態では、申請支援サーバ２０の制御部２１は、スケジュール照合処理を実行する（ステップＳ４−５）。これにより、スケジュールと利用情報との相異を把握することができる。

（１２）上記実施形態では、イベント期間から所定時間内に含まれる利用情報を検出できず、スケジュールに対応する移動実績がないレコードを検出した場合、申請支援サーバ２０の制御部２１は、不整合の確認処理を実行する（ステップＳ４−７）。これにより、スケジュールと利用実績とにおいて不整合を確認することができる。

（１３）上記実施形態では、申請支援サーバ２０の制御部２１は、スケジュールの事後登録処理（ステップＳ４−８）、申請登録処理（ステップＳ４−９）を実行する。これにより、利用情報に対応しないスケジュールについて、スケジュールの登録忘れがある場合には、スケジュールの事後登録を行なうことができる。

（１４）上記実施形態では、この場合には、申請支援サーバ２０の制御部２１は、経路候補の取得処理（ステップＳ４−１０）、申請登録処理（ステップＳ４−１１）を実行する。これにより、スケジュールに対応しない利用情報について、交通費精算の申請を行なうことができる。

なお、上記実施形態は、以下の態様に変更してもよい。
・ 上記各実施形態では、申請支援サーバ２０の制御部２１は、移動元、移動先の特定処理を実行する（ステップＳ１−２、Ｓ４−６１）。この移動元や移動先の特定は、前後のスケジュールを用いて特定するようにしてもよい。例えば、図７（ａ）に示すように、通常、勤務している拠点Ａから、拠点Ｂや拠点Ｃに外出する場合を想定する。この場合、通常、拠点Ａから拠点Ｂに移動し、拠点Ｂでのイベント終了後に、拠点Ａに戻る。そして、改めて、拠点Ａから拠点Ｃに移動し、拠点Ｃでのイベント終了後に拠点Ａに戻る。一方、拠点Ｂでのイベントと拠点Ｃでのイベントとの時間間隔が短い場合には、図７（ｂ）に示すように、拠点Ｂでのイベント終了後に、拠点Ａに戻らず、拠点Ｂから拠点Ｃに直接、移動することがある。そこで、申請支援手段２１２は、二つのスケジュールにおけるイベント場所間の移動に要する所要時間と、前後のイベントのスケジュール間の時間の長さとを比較して、直接移動かどうかを判定する。このため、申請支援手段２１２に、先行の外出先から後続の外出先に直接移動かどうかを判定するための直接移動許容時間に関するデータを保持させておく。移動元、移動先の特定処理（ステップＳ１−２、Ｓ４−６１）の後で、直接移動を考慮した、移動元、移動先の修正処理を行なう。この処理を、図７（ｃ）を用いて説明する。

まず、申請支援サーバ２０の制御部２１は、直前スケジュールの特定処理を実行する（ステップＳ５−１）。具体的には、制御部２１の申請支援手段２１２は、処理対象のスケジュール管理レコード３２０の開始日時に対して、この社員の社員コード、及び直前の終了日時が記録されたスケジュール管理レコード３２０を、スケジュール管理サーバ３０のスケジュール記憶部３２において特定する。

次に、申請支援サーバ２０の制御部２１は、先行イベント場所から連続して移動したかどうかについての判定処理を実行する（ステップＳ５−２）。具体的には、制御部２１の申請支援手段２１２は、処理対象のスケジュール管理レコード３２０の開始日時と、直前スケジュールのスケジュール管理レコード３２０の終了日時とのスケジュール時間差を算出する。更に、申請支援手段２１２は、処理対象のスケジュール管理レコード３２０に記録されたイベント場所と、直前スケジュールのスケジュール管理レコード３２０に記録されたイベント場所とを取得する。次に、申請支援手段２１２は、二つのイベント場所についての情報を交通情報提供サーバ６０に送信し、二つのイベント場所間の移動所要時間を取得する。そして、申請支援手段２１２は、スケジュール時間差と移動所要時間とに基づいて、連続移動かどうかを判定する。ここでは、時間差と移動所要時間とが直接移動許容時間内に含まれる場合には、連続移動と判定する。

先行イベント場所からの連続移動と判定した場合（ステップＳ５−２において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、先行イベント場所からの復路の削除処理を実行する（ステップＳ５−３）。具体的には、制御部２１の申請支援手段２１２は、精算対象メモリに記録された復路を交通費精算の対象外として削除する。上述の例では、拠点Ｂから拠点Ａへの復路が交通費精算の対象外となる。

次に、申請支援サーバ２０の制御部２１は、後続スケジュールの移動元の修正処理を実行する（ステップＳ５−４）。具体的には、制御部２１の申請支援手段２１２は、直前スケジュールのスケジュール管理レコード３２０に記録されているイベント場所を移動元として特定する。上述の例では、拠点Ｃへの往路において、拠点Ｂが移動元となる。

一方、先行イベント場所からの連続移動でないと判定した場合（ステップＳ５−２において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、先行イベント場所からの復路の削除処理（ステップＳ５−３）、後続スケジュールの移動元の修正処理を実行する（ステップＳ５−４）をスキップする。

そして、上記の処理により特定された移動元及び移動先を用いて、経路の特定処理を実行する。これにより、前後のスケジュールによっては、外出先から、他の外出先に直接移動するようなスケジュール状況を考慮して、移動元や移動先を特定することができる。

・ 上記第１の実施形態では、スケジュール管理レコード３２０に記録されている外出承認状況や報告承認状況に基づいて、申請支援処理を実行する。この場合、外出の証跡（エビデンス）を求めるようにしてもよい。ここでは、申請支援サーバ２０に、エビデンス記憶部を更に設ける。このエビデンス記憶部には、報告や、交通機関の利用情報が登録される。報告には、外出スケジュールに対応させて、スケジュール管理コード、タイトルやイベント場所、開始日時、終了日時に関する情報を含める。交通機関の利用情報としては、携帯端末７１や交通機関カード７２から取得した利用情報、媒体コードに基づいて交通機関サーバ８５から取得した利用情報を登録しておく。

更に、申請者のクライアント端末１０には、携帯端末７１や交通機関カード７２に記録された情報を読み取るためのカードリーダが接続されている。
そして、認証辞書記憶部２２の認証条件には、エビデンス条件に関する情報を含めておく。このエビデンス条件には、エビデンスの種類（領収書、報告や利用情報等）や、エビデンスに含まれる必要内容を設定しておく。エビデンス条件が記録されている場合には、申請支援サーバ２０において、エビデンスの確認処理を実行する。申請支援サーバ２０において自動的に実行されるエビデンスの確認処理を、図８（ａ）を用いて説明する。

まず、申請支援サーバ２０の制御部２１は、エビデンスが必要かどうかについての判定処理を実行する（ステップＳ６−１）。具体的には、制御部２１の申請支援手段２１２は、認証辞書記憶部２２に記録されている認証条件に含まれるエビデンス条件の有無により判定する。

エビデンス条件が記録されておらず、エビデンスは不要と判定した場合（ステップＳ６−１において「ＮＯ」の場合）、エビデンスの確認処理を終了する。
一方、エビデンス条件が記録されており、エビデンスが必要と判定した場合（ステップＳ６−１において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、エビデンスの検索処理を実行する（ステップＳ６−２）。具体的には、制御部２１の申請支援手段２１２は、エビデンス記憶部において、スケジュール管理コードに関連付けられたエビデンスを検索する。なお、スケジュール管理コードの代わりに、エビデンス記憶部において、タイトルやイベント場所、開始日時、終了日時を用いて、該当するエビデンスを検索するようにしてもよい。

次に、申請支援サーバ２０の制御部２１は、エビデンス条件を満足しているかどうかについての判定処理を実行する（ステップＳ６−３）。具体的には、制御部２１の申請支援手段２１２は、エビデンス条件に記録されているエビデンス種別や内容を確認する。そして、エビデンス条件を満足するエビデンスを抽出できた場合には、エビデンス条件を満足と判定する。一方、エビデンスが登録されていない場合や、エビデンスにおいて必要内容が含まれていない場合は、エビデンス条件を満足していないと判定する。

エビデンス条件を満足していると判定した場合（ステップＳ６−３において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、エビデンス確認済の登録処理を実行する（ステップＳ６−４）。具体的には、制御部２１の申請支援手段２１２は、申請管理レコード２３０の認証状況データ領域に、エビデンスを確認したことを示すエビデンス認証済フラグを記録する。

一方、エビデンス条件を満足していないと判定した場合（ステップＳ６−３において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、エビデンスの要求登録処理を実行する（ステップＳ６−５）。具体的には、制御部２１の申請支援手段２１２は、申請管理レコード２３０の認証状況データ領域に、エビデンス未確認フラグを記録する。

そして、申請者のクライアント端末１０からのアクセスに応じた確認画面の出力処理（ステップＳ２−２）において、図８（ｂ）に示す処理を実行する。
ここでは、申請支援サーバ２０の制御部２１は、エビデンスを確認済かどうかについての判定処理を実行する（ステップＳ６−６）。具体的には、制御部２１の申請支援手段２１２は、申請管理レコード２３０においてエビデンス認証済フラグが記録されている場合には、エビデンスを確認済と判定する。

エビデンスを確認済みと判定した場合（ステップＳ６−６において「ＹＥＳ」の場合）、エビデンスの確認処理を終了する。
一方、エビデンス未確認フラグが記録されていることにより、エビデンスを確認できていないと判定した場合（ステップＳ６−６において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、エビデンス要求処理を実行する（ステップＳ６−７）。具体的には、制御部２１の申請支援手段２１２は、申請者のクライアント端末１０のディスプレイに、エビデンスの登録要求を出力する。このエビデンスの登録要求には、認証条件において設定されているエビデンス種別や内容が含まれる。例えば、交通機関の利用情報が必要な場合には、申請支援手段２１２は、クライアント端末１０に接続されているカードリーダにおいて、携帯端末７１や交通機関カード７２に蓄積されている利用情報を読み取らせ、エビデンス記憶部に登録する。また、報告が必要な場合には、作成した報告をエビデンス記憶部に登録する。

この場合、申請支援サーバ２０の制御部２１は、ステップＳ６−３と同様に、エビデンス条件を満足しているかどうかについての判定処理を実行する（ステップＳ６−８）。
そして、エビデンス条件を満足していると判定した場合（ステップＳ６−８において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、ステップＳ６−４と同様に、エビデンス確認済の登録処理を実行する（ステップＳ６−９）。

一方、エビデンス条件を満足していないと判定した場合（ステップＳ６−８において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、承認申請対象外処理を実行する（ステップＳ６−１０）。具体的には、制御部２１の申請支援手段２１２は、この申請管理レコード２３０を、申請対象から除外して、申請中フラグを記録する。

これにより、エビデンスが必要な場合にも、予め登録されたエビデンスを利用して、事前認証を行なうことができる。また、エビデンス条件を充足していない場合には、エビデンスの登録を促すことができる。

・ 上記第１の実施形態では、経路候補の取得処理（ステップＳ１−５）、移動元、移動先に基づいて、認証済み経路情報の取得処理（ステップＳ１−７）を実行する。この場合、交通機関の障害状況を考慮して、認証済み経路を変更したり、経路候補を取得したりするようにしてもよい。この場合には、交通情報提供サーバ６０において提供される障害情報を利用する。この障害情報には、障害が発生した路線情報や障害継続期間情報（障害発生日時、障害復旧日時）が含まれる。そして、申請支援サーバ２０の制御部２１は、経路候補や認証済み経路について、処理対象のスケジュール管理レコード３２０の開始日時から所定時間前や、終了日時から所定時間後の交通機関の障害情報を検索する。ここで、障害情報を取得した場合には、障害が発生した認証済み経路や経路候補を除き、これらの代替経路を交通情報提供サーバ６０から取得する。

更に、障害情報を取得した場合には、交通機関において障害状況を申請管理レコード２３０のメモデータ領域に記録する。これにより、交通機関において発生した障害を考慮して、経路を特定して申請を行なうことができる。

・ 上記第２の実施形態では、申請支援サーバ２０の制御部２１は、移動元、移動先の特定処理（ステップＳ４−６１）、経路情報の取得処理（ステップＳ４−６２）を実行する。ここで、利用情報に記録されている経路に基づいて申請登録を行なうようにしてもよい。具体的には、申請支援手段２１２は、交通情報提供サーバ６０から取得した経路（本来経路）の移動所要時間と、利用情報に含まれる経路の移動所要時間とを比較する。そして、利用情報に含まれる経路の移動所要時間が、本来経路の移動所要時間より短い場合には、利用情報に含まれる経路を用いて申請登録を行なう。

・ 上記第２の実施形態では、申請支援サーバ２０の制御部２１は、スケジュール照合処理（ステップＳ４−５）を実行するとともに、不整合の確認処理（ステップＳ４−７）を実行する。ここで、交通機関における障害発生状況に応じて、変更経路の検索処理を行なうようにしてもよい。この処理を、図９を用いて説明する。

まず、申請支援サーバ２０の制御部２１は、ステップＳ１−５と同様に、経路候補の取得処理を実行する（ステップＳ７−１）。
次に、申請支援サーバ２０の制御部２１は、利用情報の経路と一致するかどうかについての判定処理を実行する（ステップＳ７−２）。具体的には、制御部２１の申請支援手段２１２は、取得した経路候補と利用情報の経路とを比較する。利用情報の経路が経路候補の中に含まれる場合には、利用情報の経路と一致と判定する。

利用情報の経路と一致すると判定した場合（ステップＳ７−２において「ＹＥＳ」の場合）、申請支援サーバ２０の制御部２１は、申請登録処理を実行する（ステップＳ７−３）。具体的には、制御部２１の申請支援手段２１２は、利用情報の経路を申請管理レコード２３０の経路データ領域に記録するとともに、利用情報の利用金額を金額データ領域に記録する。

利用情報の経路が経路候補に含まれておらず、利用情報の経路と一致しないと判定した場合（ステップＳ７−２において「ＮＯ」の場合）、申請支援サーバ２０の制御部２１は、経路候補についての障害情報の検索処理を実行する（ステップＳ７−４）。具体的には、制御部２１の申請支援手段２１２は、交通情報提供サーバ６０にアクセスして、イベント期間の交通機関の障害情報を取得する。この障害情報には、障害が発生した路線情報や障害継続期間に関する情報が含まれる。そして、申請支援手段２１２は、取得した障害情報の中で、経路候補についての障害情報であって、イベント期間（開始日時、終了日時）の所定時間範囲内の障害情報を検索する。

次に、申請支援サーバ２０の制御部２１は、交通機関に障害があったかどうかについての判定処理を実行する（ステップＳ７−５）。具体的には、制御部２１の申請支援手段２１２は、経路候補について、イベント期間の所定時間範囲内の障害情報を抽出した場合には、交通機関に障害があったと判定する。

交通機関に障害があったと判定した場合（ステップＳ７−５において「ＹＥＳ」の場合）には、申請支援サーバ２０の制御部２１は、障害情報を追加して代替経路の登録処理を実行する（ステップＳ７−６）。具体的には、制御部２１の申請支援手段２１２は、障害情報を申請管理レコード２３０のメモデータ領域に記録する。そして、申請支援手段２１２は、利用情報に含まれる経路、金額を申請管理レコード２３０に記録する。

障害情報を抽出できず、交通機関に障害がなかったと判定した場合（ステップＳ７−５において「ＮＯ」の場合）には、申請支援サーバ２０の制御部２１は、ステップＳ４−７〜Ｓ４−１１と同様に、不整合の対応処理を実行する（ステップＳ７−７）。そして、申請支援サーバ２０の制御部２１は、図６に示す承認依頼処理（ステップＳ４−１２）を実行する。
これにより、交通機関において発生した障害を考慮して、経路を特定して申請を行なうことができる。

・ 上記各実施形態では、申請支援サーバ２０の制御部２１は、経路候補の取得処理を実行する（ステップＳ１−５、Ｓ４−６２、Ｓ４−１０）。ここで、移動に要する所要時間を考慮して、経路を特定するようにしてもよい。この場合には、申請支援手段２１２は、スケジュール管理サーバ３０のスケジュール記憶部３２から、先行スケジュールや後続スケジュールについてのスケジュール管理レコード３２０を取得する。そして、申請支援手段２１２は、先行スケジュールのスケジュール管理レコード３２０の終了日時から、処理対象のスケジュール管理レコード３２０の開始日時までの時間差を算出する。また、申請支援手段２１２は、処理対象のスケジュール管理レコード３２０の終了日時から、先行スケジュールのスケジュール管理レコード３２０の開始日時までの時間差を算出する。そして、申請支援手段２１２は、これらの時間差内に移動可能な経路を経路候補として特定する。

また、申請支援サーバ２０の制御部２１は、認証済み経路の取得処理（ステップＳ１−７）においても、先行スケジュールと後続スケジュールとの時間差に基づいて、認証済み経路を特定するようにしてもよい。この場合には、時間差を認証条件に含めて、時間差に対応した認証済み経路を認証辞書記憶部２２に登録しておく。そして、申請支援手段２１２は、算出したスケジュール間の時間差に対応した認証済み経路を認証辞書記憶部２２から取得する。
これにより、スケジュール状況に応じて、経路を特定することができる。

・ 上記各実施形態では、申請支援サーバ２０の制御部２１は、経路候補の取得処理を実行する（ステップＳ１−５、Ｓ４−６２、Ｓ４−１０）。ここで、移動時の天候を考慮して、経路を特定するようにしてもよい。この場合には、申請支援サーバ２０の制御部２１を、インターネットを介して、天候情報を提供する天候情報提供サーバに接続できるようにしておく。この天候情報提供サーバは、インターネットを介して取得した日時、地域に対応して、天候情報を提供する。そして、申請支援サーバ２０の制御部２１は、経路候補を取得する場合、天候情報提供サーバにアクセスし、処理対象のスケジュール管理レコード３２０のイベント期間（開始日時〜終了日時）、イベント場所の地域の天候情報を取得する。そして、申請支援手段２１２は、天候情報に基いて、経路候補を特定する。例えば、悪天候の場合には、乗換えが少ない経路や、天候の影響が少ない交通機関を利用した経路を経路候補として優先的に特定する。

また、申請支援サーバ２０の制御部２１は、認証済み経路の取得処理（ステップＳ１−７）においても、天候に応じて認証済み経路を特定するようにしてもよい。この場合には、天候を認証条件に含めて、天候に対応した認証済み経路を認証辞書記憶部２２に登録しておく。そして、申請支援手段２１２は、天候情報提供サーバから取得した天候情報に対応した認証済み経路を認証辞書記憶部２２から取得する。
これにより、天候に応じて、経路を特定することができる。

・ 上記第１の実施形態では、申請支援サーバ２０の制御部２１は、未認証への変更処理を実行する（ステップＳ２−６）。これに加えて、承認確認画面において、認証済み経路が変更されたことや、変更箇所を出力するようにしてもよい。この場合には、申請管理レコード２３０において、修正履歴を登録しておく。これにより、修正された内容を確認しながら、効率的に承認作業を行なうことができる。

・ 上記各実施形態では、例えば、月初に前月の交通費精算を支援するために、申請支援処理を定期的に実行する。申請支援処理を実行するタイミングは、これに限定されるものではない。例えば、スケジュール記憶部３２のスケジュール管理レコード３２０に記録された終了日時の経過後に、精算対象とすることも可能である。また、終了日時から所定期間（例えば３営業日）の経過後に、精算を促すアラームを出力するようにしてもよい。

・ 上記各実施形態では、スケジュール管理レコード３２０に「直出」フラグが記録されている場合には、精算情報取得手段２１１は、自宅住所を移動元として特定する。また、スケジュール管理レコード３２０に「直帰」フラグが記録されている場合には、精算情報取得手段２１１は、自宅住所を移動先として特定する。これに代えて、直出や直帰の場合には、社員管理情報記憶部５２の社員管理レコード５２０に記録された定期券区間に含まれる駅を移動元や移動先として特定するようにしてもよい。

・ 上記第１の実施形態では、認証辞書記憶部２２には、交通費精算対象を事前に認証するための認証辞書レコード２２０が記録される。この認証辞書レコード２２０は、認証管理コード、認証条件、出発地、目的地、経路、金額に関するデータを含んで構成される。ここで、社員毎に認証辞書レコード２２０を記録するようにしてもよい。この場合には、認証辞書レコード２２０に、各認証条件を適用する社員の社員コードを記録する。そして、認証条件との照合処理（ステップＳ１−３）において、スケジュール管理レコード３２０に記録された社員コードを特定し、この社員コードが記録された認証辞書レコード２２０の認証条件を用いて、照合処理を実行する。

・ 上記第２の実施形態では、対応経路があるかどうかについての判定処理を実行する（ステップＳ４−６３）。ここで、申請金額が、経路候補の交通費以下の場合には、他の経路を許容するようにしてもよい。

・ 上記第２の実施形態では、申請支援サーバ２０の制御部２１は、利用情報のフィルタリング処理を実行する（ステップＳ４−４）。ここでは、制御部２１の精算情報取得手段２１１は、出勤カレンダ情報において、休暇日や休日についての利用情報についても対象外として除外する。これに加えて、出退勤の時刻に応じて、フィルタリングを行なうようにしてもよい。この場合には、外出日における、申請者の勤務時間帯情報を社員管理サーバ５０から取得する。そして、この勤務時間帯から基準時間範囲外の利用情報をフィルタリングする。

・ 上記各施形態では、申請支援サーバ２０の制御部２１は、チャージ伝票の発行処理を実行する（ステップＳ３−４）。これに代えて、制御部２１は、申請者の口座に申請された金額を振り込むようにしてもよい。

・ 上記第１の実施形態では、申請支援サーバ２０の制御部２１は、承認処理を実行する（ステップＳ２−９）。ここで、認証状況データ領域に認証済フラグが記録されている場合には、認証済みであることを示すアイコンを承認確認画面に含める。認証状況データ領域に認証済フラグが記録されている場合の承認方法はこれに限定されるものではなく、認証済みでない申請よりも、承認手続きを簡略化できればよい。

・ 上記第２の実施形態では、経路照合処理を実行する（ステップＳ４−６）。ここで、認証辞書記憶部２２に記録されている経路と照合するようにしてもよい。この場合にも、申請管理レコード２３０の認証状況データ領域に認証済フラグを記録する。そして、承認処理時に、認証済みでない申請よりも、承認手続きを簡略化する。例えば、認証状況データ領域に認証済フラグが記録されている場合には、承認処理時に、認証済みであることを示すアイコンを承認確認画面に含める。

・ 上記第１の実施形態では、申請者による申請内容の確認後に交通費精算の申請が行なわれるとともに、承認者による申請内容の確認後に交通費の精算が行なわれる。ここで、これらの処理を簡略化するようにしてもよい。例えば、申請支援サーバ２０の制御部２１が、定期的に、スケジュール管理サーバ３０において、外出についてのスケジュール管理レコード３２０を検索する。スケジュール管理レコード３２０に記録された終了日時を経過しており、精算状況データ領域に未精算フラグが記録されているスケジュール管理レコード３２０を検出した場合、制御部２１は、この社員に対して、外出スケジュールの履行についての確認処理を行なう。この確認処理においては、社員（外出者）のクライアント端末１０に確認ダイアログを出力したり、確認メールを送信したりすることにより、外出状況の確認通知を行なう。この確認通知には、スケジュール管理レコード３２０に記録された開始日時、終了日時、イベント場所に関する情報を含める。

そして、外出者は、クライアント端末１０を用いて、申請支援サーバ２０にアクセスし、確認通知に対する外出確認入力を行なう。この場合、申請支援サーバ２０の制御部２１は、社員管理情報記憶部５２に記録された外出者の社員管理レコード５２０を用いて勤務地を特定する。そして、制御部２１は、認証辞書記憶部２２において、この勤務地が出発地として記録され、スケジュール管理レコード３２０に記録されたイベント場所が目的地として記録されている認証辞書レコード２２０があるかどうかを確認する。なお、出発地は勤務地に限定されるものではない。例えば、スケジュール時間差と移動所要時間とに基づいて、先行イベント場所から連続して移動したと判定した場合には、直前スケジュールのイベント場所を移動元として特定してもよい。

そして、認証辞書記憶部２２において、このような認証辞書レコード２２０を選択候補として抽出できた場合、制御部２１は、認証辞書レコード２２０の経路でよいかどうかを確認するためのダイアログをクライアント端末１０のディスプレイに表示する。クライアント端末１０において、この経路についての承認入力が行なわれた場合、制御部２１は、外出者による申請、承認者による承認が行なわれたものとみなして、この交通費（認証辞書レコード２２０に記録された金額）についての精算処理を行なう。これにより、簡易な処理により、交通費の精算を行なうことができる。

また、外出確認入力において、外出者が外出に用いた経路を入力させるようにしてもよい。具体的には、外出確認入力が行なわれた場合、申請支援サーバ２０の制御部２１は、認証辞書記憶部２２において、この勤務地が出発地として記録され、スケジュール管理レコード３２０に記録されたイベント場所が目的地として記録されている認証辞書レコード２２０があるかどうかを確認する。この場合にも、出発地は勤務地に限定されるものではなく、上述のように、直前スケジュールのイベント場所を移動元として特定してもよい。そして、認証辞書記憶部２２において、このような認証辞書レコード２２０を抽出できた場合、制御部２１は、外出者によって入力された経路と、この認証辞書レコード２２０に記録された経路とを比較する。両者が一致する場合には、制御部２１は、外出者による申請、承認者による承認が行なわれたものとみなして、この交通費についての精算処理を行なう。

更に、選択候補となる認証辞書レコード２２０が複数ある場合には、交通費精算に用いる認証辞書レコード２２０を外出者に選択させるようにしてもよい。この場合には、申請支援サーバ２０の制御部２１は、外出者の勤務地が出発地として記録され、スケジュール管理レコード３２０に記録されたイベント場所が目的地として記録されている認証辞書レコード２２０を抽出する。そして、制御部２１は、抽出した認証辞書レコード２２０の一覧リストをクライアント端末１０のディスプレイに表示する。ここで、認証辞書レコード２２０が選択された場合、制御部２１は、この認証辞書レコード２２０を用いて、外出者による申請、承認者による承認が行なわれたものとみなして、この交通費についての精算処理を行なう。

１０，１５…クライアント端末、２０…申請支援サーバ、２１…制御部、２１１…精算情報取得手段、２１２…申請支援手段、２１３…支払支援手段、２２…認証辞書記憶部、２３…申請管理記憶部、３０…スケジュール管理サーバ、３２…スケジュール記憶部、５０…社員管理サーバ、５２…社員管理情報記憶部、６０…交通情報提供サーバ、７０…記録媒体、７１…携帯端末、７２…交通機関カード、８０…改札ゲート、８５…交通機関サーバ。

Claims (10)

1. 利用者、イベント場所、イベント期間、イベント内容を含めたイベントスケジュールを記録したスケジュール記憶部と、
   認証条件を記録した認証辞書記憶部と、
   交通費精算の申請を記録する申請管理記憶部と、
   交通費精算の申請を支援する制御部とを備えた交通費精算システムであって、
   前記制御部が、
   前記スケジュール記憶部から、利用者のイベントスケジュールを取得し、
   前記イベントスケジュールにおけるイベント内容を特定し、
   前記イベント内容と、前記認証辞書記憶部に記録された認証条件とを照合し、
   前記イベント内容が認証条件を充足する場合には、前記イベントスケジュールのイベント場所に基づいて移動元から移動先までの交通機関経路の交通費を算出し、前記交通費及び認証情報を含む交通費精算の申請を前記申請管理記憶部に登録することを特徴とする交通費精算システム。
2. 前記制御部が、
   前記スケジュール記憶部において、前記イベントスケジュールの直前スケジュールを特定し、
   前記直前スケジュールのイベント場所を移動元として特定することを特徴とする請求項１に記載の交通費精算システム。
3. 前記制御部が、
   前記スケジュール記憶部において、前記イベントスケジュールの直後スケジュールを特定し、
   前記直後スケジュールのイベント場所を移動先として特定することを特徴とする請求項１又は２に記載の交通費精算システム。
4. 前記制御部が、
   前記イベントスケジュールのイベント期間に基づいて、前記交通機関経路についての障害情報を取得した場合、前記障害情報に基づいて代替の交通機関経路を特定して交通費を算出することを特徴とする請求項１〜３のいずれか一つに記載の交通費精算システム。
5. 利用者毎に通勤経路を記録した利用者情報記憶部を更に備え、
   前記制御部が、
   前記利用者情報記憶部から、前記利用者の通勤経路を特定し、
   前記交通機関経路において、前記通勤経路を考慮して交通費を算出することを特徴とする請求項１〜４のいずれか一つに記載の交通費精算システム。
6. 前記制御部が、
   前記交通費精算の申請についての承認情報を取得した場合、前記利用者が交通機関の利用時に使用する記録媒体に対して、前記交通費のチャージ処理を実行することを特徴とする請求項１〜５のいずれか一つに記載の交通費精算システム。
7. イベントスケジュールに対応させて、エビデンスを記録するエビデンス記憶部を更に備え、
   前記制御部が、
   前記イベントスケジュールの交通費精算の申請においてエビデンスの要否を特定し、
   エビデンスが必要な場合には、前記イベントスケジュールについてのエビデンスを前記エビデンス記憶部において検索し、
   前記エビデンスを取得できた場合のみ、前記交通費精算の申請を前記申請管理記憶部に登録することを特徴とする請求項１〜６のいずれか一つに記載の交通費精算システム。
8. 前記エビデンスとして、イベントスケジュールを特定した情報を含めた報告を前記エビデンス記憶部に記録したことを特徴とする請求項７に記載の交通費精算システム。
9. 利用者、イベント場所、イベント期間、イベント内容を含めたイベントスケジュールを記録したスケジュール記憶部と、
   認証条件を記録した認証辞書記憶部と、
   交通費精算の申請を記録する申請管理記憶部と、
   交通費精算の申請を支援する制御部とを備えた交通費精算システムを用いて交通費精算を支援する方法であって、
   前記制御部が、
   前記スケジュール記憶部から、利用者のイベントスケジュールを取得し、
   前記イベントスケジュールにおけるイベント内容を特定し、
   前記イベント内容と、前記認証辞書記憶部に記録された認証条件とを照合し、
   前記イベント内容が認証条件を充足する場合には、前記イベントスケジュールのイベント場所に基づいて移動元から移動先までの交通機関経路の交通費を算出し、前記交通費及び認証情報を含む交通費精算の申請を前記申請管理記憶部に登録することを特徴とする交通費精算方法。
10. 利用者、イベント場所、イベント期間、イベント内容を含めたイベントスケジュールを記録したスケジュール記憶部と、
    認証条件を記録した認証辞書記憶部と、
    交通費精算の申請を記録する申請管理記憶部と、
    交通費精算の申請を支援する制御部とを備えた交通費精算システムを用いて交通費精算を支援するプログラムであって、
    前記制御部を、
    前記スケジュール記憶部から、利用者のイベントスケジュールを取得し、
    前記イベントスケジュールにおけるイベント内容を特定し、
    前記イベント内容と、前記認証辞書記憶部に記録された認証条件とを照合し、
    前記イベント内容が認証条件を充足する場合には、前記イベントスケジュールのイベント場所に基づいて移動元から移動先までの交通機関経路の交通費を算出し、前記交通費及び認証情報を含む交通費精算の申請を前記申請管理記憶部に登録する手段として機能させることを特徴とする交通費精算プログラム。

Images