JP6180577B1 - 交通費申請処理装置及び交通費申請処理プログラム - Google Patents

Abstract

【課題】交通費申請に関する利用経路の妥当性を判断することができる交通費申請処理装置及び交通費申請処理プログラムを提供する。【解決手段】本実施形態に係る交通費申請処理装置は、鉄道利用料金を支払可能な記憶媒体から取得した日付と利用金額、及び、入場駅と出場駅を含む交通費申請を取得する取得部と、前記入場駅に対応する出発駅、前記出場駅に対応する到着駅及び前記日付を含む検索条件を経路検索サーバへ送信する送信処理部と、前記検索条件に合致する候補経路及び前記候補経路に関連付けられている候補料金を含むｎ（ｎは１以上の整数）個の候補で構成されている検索結果を前記経路検索サーバから受信する受信処理部と、前記利用金額が前記ｎ個の候補のうちの少なくとも１つに合致しているか否かに応じて前記交通費申請を許可または不許可と判断する判断部と、を備える。【選択図】図７

Description

本発明の実施形態は、経路検索サーバによる検索結果を用いた交通費申請処理装置及び交通費申請処理プログラムに関する。

鉄道利用料金を支払可能な交通系ＩＣ（Integrated Circuit）カードが普及している。これに伴い、交通系ＩＣカードに記憶されている実際の鉄道利用に関する情報を用いた様々な交通費精算手法が提案されている。他方、会社側には、出張等の交通費に関するルールが規定されていることが多い。ルールは、例えば、料金が安い経路の利用、移動時間の早い経路の利用などを規定する。

特許文献１には、パーソナルコンピュータがカードリーダを介してＩＣカードから乗降履歴データを取り込み、乗降履歴データを表計算ソフトウェアに読み込む技術が記載されている。特許文献１に記載されている技術によれば、申請者は、交通費申請を紙に代えてデータで行うことができる。

特許文献２には、旅費精算の申請内容の妥当性を判断する技術が記載されている。特許文献２に記載されている技術は、実際の交通費と、申請者による申請データに含まれる出張予定の駅などのデータに基づいて検索される交通費とを比較している。

特開２００７−７９９１１号公報 特開２０１０−１２２７１９号公報

しかしながら、特許文献１には、交通費申請が妥当か否かを判断する技術は記載されていない。また、特許文献２に記載されている技術は、ある駅から別の駅までの移動に要した交通費の額自体が正しいか否かを判断することはできるが、前提となる利用経路自体の妥当性を判断することができない。つまり、特許文献２に記載されている技術は、利用経路が会社側で規定されている交通費に関するルールに沿っているのか否かを判断することはできない。

本発明が解決しようとする課題は、交通費申請に関する利用経路の妥当性を判断することができる交通費申請処理装置及び交通費申請処理プログラムを提供することにある。

本実施形態に係る交通費申請処理装置は、鉄道利用料金を支払可能な記憶媒体から取得した日付と利用金額、及び、入場駅と出場駅を含む交通費申請を取得する取得部と、前記入場駅に対応する出発駅、前記出場駅に対応する到着駅及び前記日付を含む検索条件を経路検索サーバへ送信する送信処理部と、前記検索条件に合致する候補経路及び前記候補経路に関連付けられている候補料金を含むｎ（ｎは１以上の整数）個の候補で構成されている検索結果を前記経路検索サーバから受信する受信処理部と、前記利用金額が前記ｎ個の候補のうちの少なくとも１つに合致しているか否かに応じて前記交通費申請を許可または不許可と判断する判断部と、を備える。

本実施形態に係る交通費申請処理プログラムは、鉄道利用料金を支払可能な記憶媒体から取得した日付と利用金額、及び、入場駅と出場駅を含む交通費申請を取得する機能と、前記入場駅に対応する出発駅、前記出場駅に対応する到着駅及び前記日付を含む検索条件を経路検索サーバへ送信する機能と、前記検索条件に合致する候補経路及び前記候補経路に関連付けられている候補料金を含むｎ（ｎは１以上の整数）個の候補で構成されている検索結果を前記経路検索サーバから受信する機能と、前記利用金額が前記ｎ個の候補のうちの少なくとも１つに合致しているか否かに応じて前記交通費申請を許可または不許可と判断する機能と、をコンピュータに実行させる。

本実施形態によれば、交通費申請処理装置及び交通費申請処理プログラムは、交通費申請に関する利用経路が会社側で規定されている交通費に関するルールに沿っているのか否かを判断することで、交通費申請に関する利用経路の妥当性を判断することができる。これにより、会社側は、煩雑な作業を要することなく、ルールに沿って適切に交通費申請を処理することができる。

実施形態に係る交通費申請処理システムの一例を示すブロック図。 実施形態に係る利用履歴の一例を示す図。 実施形態に係る交通費申請の登録手順の一例を説明するフローチャート。 実施形態に係る交通費申請の一例を示す図。 実施形態に係る検索パラメータ及び検索結果を構成する情報の一例を示す図。 実施形態に係る検索結果の一例を示す図。 実施形態に係る交通費申請に関する利用経路の妥当性の判断手順を説明するフローチャート。 実施形態に係る交通費申請の他の例を示す図。 実施形態に係る検索結果の他の例を示す図。

以下、図面を参照して実施形態について説明する。
図１は、実施形態に係る交通費申請処理システム１００のブロック図である。
交通費申請処理システム１００は、交通費申請処理装置１、経路検索サーバ２及びユーザ端末３を有する。図１には、交通費申請処理装置１、経路検索サーバ２及びユーザ端末３はそれぞれ別の装置として示されているがこれに限られない。交通費申請処理装置１及び経路検索サーバ２は、後述するそれぞれの機能を有する一体の装置で構成されていてもよい。交通費申請処理装置１及びユーザ端末３は、後述するそれぞれの機能を有する一体の装置で構成されていてもよい。

交通費申請処理装置１は、申請者からの交通費申請に関する利用経路の妥当性を判断する。申請者とは、例えば交通費申請処理装置１が設置されている会社等の組織（以下、会社という）の社員であって、会社に対して交通費申請を行う者である。交通費申請を構成する情報及び交通費申請の登録手順については後述する。交通費申請処理装置１は、例えばサーバ装置（コンピュータ）である。

交通費申請処理装置１は、制御部１１、記憶部１２及び通信部１３を有する。交通費申請処理装置１を構成する各部は、互いに信号を伝送可能となるように接続されている。

制御部１１は、交通費申請処理装置１の各部を制御する。制御部１１は、例えばＣＰＵ（Central Processing Unit）等で構成されている。制御部１１は、機能構成として、取得部１１１、送信処理部１１２、受信処理部１１３、判断部１１４及び記録処理部１１５を有する。

取得部１１１は、記憶部１２から後述する交通費申請に対応する申請情報１２３を取得する。
送信処理部１１２は、検索条件を経路検索サーバ２へ送信する。検索条件は、経路検索サーバ２が鉄道における候補となる経路（以下、候補経路という）を検索するための条件となる検索パラメータを指定する情報で構成されている。検索パラメータについては後述する。
受信処理部１１３は、検索結果を経路検索サーバ２から受信する。検索結果は、経路検索サーバ２が検索条件に基づいて検索したｎ（ｎは１以上の整数）個の候補で構成されている。検索結果を構成する情報については後述する。
判断部１１４は、交通費申請に関する利用経路の妥当性を判断する。
記録処理部１１５は、検索結果から得られる情報を記憶部１２に記録する。
各機能構成による具体的な処理については後述する。

記憶部１２は、各種情報を記憶する。記憶部１２は、例えばＨＤＤ（Hard Disk Drive）である。記憶部１２は、制御部１１が有する各機能構成による機能を交通費申請処理装置１に実行させるプログラムを記憶する。さらに、記憶部１２は、識別情報１２１、定期区間情報１２２、申請情報１２３及び検索条件指定情報１２４を記憶する。

識別情報１２１は、社員に割り当てられている識別コード（以下、社員コードという）及び社員所有の後述する記憶媒体５に割り当てられている識別コード（以下、媒体コードという）のうちの少なくとも何れか一方を有する。社員コード及び媒体コードは、例えば複数桁の文字列である。記憶部１２は、社員毎に識別情報１２１を記憶する。なお、社員コードは、媒体コードと同じこともある。

定期区間情報１２２は、定期区間の経路情報である。定期区間情報１２２は、出発駅、到着駅及び路線を特定する。交通費申請処理装置１は、例えば、社員による識別情報１２１を関連付けた定期区間情報１２２の登録に基づいて、定期区間情報１２２を記憶部１２に記録する。これにより、記憶部１２は、社員毎に定期区間情報１２２を識別情報１２１に関連付けて記憶することができる。

申請情報１２３は、申請者が登録した交通費申請の情報である。交通費申請は後述するように識別情報１２１を含む。そのため、記憶部１２は、社員毎に申請情報１２３を識別情報１２１に関連付けて記憶することができる。

検索条件指定情報１２４は、検索条件を構成する情報である。検索条件指定情報１２４は、検索パラメータのうち任意に指定可能な任意パラメータを指定する情報である。任意パラメータの例については後述する。検索条件指定情報１２４は、会社側で規定される交通費に関するルールに沿って会社側によって予め登録されている。検索条件指定情報１２４は、適宜変更可能である。

通信部１３は、ネットワークを介して経路検索サーバ２及びユーザ端末３と通信する。ネットワークは、内部ネットワークであっても、外部ネットワークであってもよい。通信部１３は、例えば通信インターフェースである。

経路検索サーバ２は、検索条件に基づいて候補経路を検索する。
経路検索サーバ２は、制御部２１、記憶部２２及び通信部２３を有する。経路検索サーバ２を構成する各部は、互いに信号を伝送可能となるように接続されている。

制御部２１は、経路検索サーバ２の各部を制御する。制御部２１は、例えばＣＰＵ等で構成されている。制御部２１は、検索条件を交通費申請処理装置１から受信する機能を有する。制御部２１は、記憶部２２に記憶されている後述する各種情報を用いて、検索条件によって指定される検索パラメータから導き出される検索結果を生成する機能を有する。なお、制御部２１は、交通費申請処理装置１から送信される検索条件に未指定のパラメータがあればデフォルト値を用いて検索結果を生成する。制御部２１は、検索結果を交通費申請処理装置１へ送信する機能を有する。

記憶部２２は、各種情報を記憶する。記憶部２２は、例えばＨＤＤである。記憶部２２は、制御部２１の各機能を経路検索サーバ２に実行させるプログラムを記憶する。
記憶部２２は、さらに経路情報２２１、時刻表情報２２２及び料金情報２２３を有する。

経路情報２２１は、鉄道各社の路線に関する情報である。経路情報２２１は、例えば、各路線と、各路線上の駅等の情報を含む。
時刻表情報２２２は、各路線の時刻表に関する情報である。時刻表情報２２２は、例えば、各駅における発着時刻等の情報を含む。
料金情報２２３は、鉄道利用時の料金に関する情報である。料金情報は、例えば、運賃、有料特急及び新幹線利用時の料金、及び、座席指定時の料金（指定席料金及びグリーン席料金等）等の情報を含む。
通信部２３は、ネットワークを介して交通費申請処理装置１と通信する。

ユーザ端末３は、申請者が交通費申請を作成するための端末である。ユーザ端末３は、例えばパーソナルコンピュータ、スマートフォンまたは携帯電話等である。
ユーザ端末３は、制御部３１、記憶部３２、入力部３３、表示部３４、第１通信部３５及び第２通信部３６を有する。ユーザ端末３を構成する各部は、互いに信号を伝送可能となるように接続されている。

制御部３１は、ユーザ端末３の各部を制御する。制御部３１は、例えばＣＰＵ等で構成されている。制御部３１は、機能構成として、取得部３１１、生成部３１２及び送信処理部３１３を有する。

取得部３１１は、電子マネー機能を有する記憶媒体５から電子マネー機能の利用履歴を取得する。電子マネー機能は、例えば鉄道利用料金の支払、バス料金の支払及び物品購入の支払等である。なお、本実施形態では、記憶媒体５は、少なくとも鉄道利用料金を支払可能であればよい。記憶媒体５は、例えばＩＣカードであっても、スマートフォンまたは携帯電話等に搭載されている要素であってもよい。また、記憶媒体５は、定期券の機能を有していてもよい。利用履歴の例については後述する。
生成部３１２は、申請者による入力に基づいて交通費申請を生成する。
送信処理部３１３は、生成した交通費申請を交通費申請処理装置１へ送信する。

記憶部３２は、各種情報を記憶する。記憶部３２は、例えばＨＤＤである。記憶部３２は、制御部３１が有する各機能構成による機能をユーザ端末３に実行させるプログラムを有する。
入力部３３は、交通費申請の作成時における申請者による入力を受け付ける。入力部３３は、例えばキーボードまたはタッチパネルである。
表示部３４は、交通費申請の作成画面を表示する。表示部３４は、例えばディスプレイである。

第１通信部３５は、有線または無線により読取装置４と通信する。第１通信部３５は、読取装置４が記憶媒体５から読み取った利用履歴を受信する。第１通信部３５は、例えば通信インタ−フェースである。読取装置４は、例えばカードリーダである。

第２通信部３６は、ネットワークを介して交通費申請処理装置１と通信する。第２通信部３６は、例えば通信インターフェースである。なお、第２通信部３６は、経路検索サーバ２と通信することもできる。

次に、記憶媒体５に記憶されている利用履歴について説明する。
図２は、利用履歴の一例を示す図である。
利用履歴は、「日付」、「利用機器」、「内容」、「入場駅」、「出場駅」、「利用金額」及び「利用後残高」の情報で構成されている。利用履歴は、記憶媒体５を用いた支払毎にこれらの情報を関連付けている。

「日付」は、記憶媒体５で支払をした年月日である。「利用機器」は、記憶媒体５での支払に用いられた機器（例えば、自動改札機、物販端末など）である。「内容」は、記憶媒体５で支払をした内容（例えば、運賃支払、物品購入など）である。記憶媒体５が定期券の機能を有している場合、運賃支払は、定期外となることもあるし、定期内となることもあるし、一部定期外となることもある。「入場駅」及び「出場駅」は、それぞれ、鉄道利用時における実際に入場した駅及び実際に出場した駅である。
「利用金額」は、記憶媒体５で支払をした金額である。「利用後残高」は、記憶媒体５で支払をした後の記憶媒体５で支払可能な残高である。

次に、交通費申請の登録手順について説明する。
図３は、交通費申請の登録手順の一例を説明するフローチャートである。この登録手順は、申請者がユーザ端末３を用いて交通費申請を作成する際にユーザ端末３によって実行される。

取得部３１１は、利用履歴を取得する（ステップＳ１０１）。ステップＳ１０１では、取得部３１１は、申請者が読取装置４に翳した記憶媒体５から利用履歴を取得する。

生成部３１２は、利用履歴のうち交通費申請の対象とする項目の選択を受け付ける（ステップＳ１０２）。申請者は、入力部３３を用いて図２に示す利用履歴のうち交通費申請の対象とする１以上の項目を選択することができる。なお、生成部３１２は、「入場駅」、「出場駅」、「日付」及び「利用金額」の情報を、交通費申請における必須の情報として利用履歴から取得する。

生成部３１２は、付加情報の入力を受け付ける（ステップＳ１０３）。付加情報は、交通費申請の対象とする項目に対応付けられる情報である。付加情報は、例えば、「外出先」、「要件」、「時刻」、「定期利用の有無」及び「申請経路」である。付加情報は、申請者の自己申告による情報である。付加情報は、主として、交通費申請の参考情報である。付加情報の一つである「時刻」は、入場駅からの出発時刻または出場駅での到着時刻である。付加情報の一つである「申請経路」は、申請者が申請する利用経路である。申請者は、入力部３３を用いて付加情報を入力することができる。申請者は、ユーザ端末３を用いて経路検索サーバ２にアクセスすることで申請経路を調べることができる。なお、付加情報の各情報は、設定変更により必須または任意の何れかに切り替え可能である。

生成部３１２は、ステップＳ１０２で受け付けた利用履歴から選択された項目及びステップＳ１０３で受け付けた付加情報に基づいて交通費申請を生成する（ステップＳ１０４）。交通費申請を構成する情報については後述する。なお、生成部３１２は、交通費申請に識別情報１２１を含める。取得部３１１が記憶媒体５から利用履歴と共に媒体コードを取得できる場合には、生成部３１２は、交通費申請に媒体コードを含めることができる。取得部３１１が記憶媒体５から利用履歴と共に媒体コードを取得できない場合には、生成部３１２は、申請者がユーザ端末３へのログイン時に入力した社員コードを取得することができる。別の例として、生成部３１２は、ステップＳ１０３において、付加情報として社員コードの入力を要求してもよい。

送信処理部３１３は、交通費申請を交通費申請処理装置１へ送信する（ステップＳ１０５）。これにより、ユーザ端末３は、交通費申請を交通費申請処理装置１に登録することができる。交通費申請処理装置１は、交通費申請に含まれている社員コードまたは媒体コードを参照して、交通費申請を識別情報１２１に関連付けて申請情報１２３として記憶部１２に記録する。

なお、ステップＳ１０１における利用履歴の取得手法は上述の手法に限られない。例えば、以下で説明するケースでは、取得部３１１は、交通費申請処理装置１の記憶部１２に予め記憶されている利用履歴を交通費申請処理装置１から取得することができる。ここでは、記憶媒体５は、電子マネー機能を有し、かつ、会社内の入退室時に電子ロックを解除可能な機能を有しているものとする。社員が電子ロックを解除するためにカードリーダ（図示せず）に対して記憶媒体５を翳す毎に、カードリーダは、利用履歴及び識別情報１２１を記憶媒体５から読み出す。カードリーダは、利用履歴及び識別情報１２１を交通費申請処理装置１へ送信する。交通費申請処理装置１の記憶部１２は、利用履歴を識別情報１２１に関連付けて記憶する。取得部３１１は、申請者が交通費申請の作成開始時に識別情報１２１を入力部３３で入力した際に、申請者の識別情報１２１に関連付けられている利用履歴を交通費申請処理装置１から取得することができる。

次に、交通費申請を構成する情報について説明する。
図４は、交通費申請の一例を示す図である。
図４に示す交通費申請は、定期区間を利用していないＡ駅とＢ駅との間の移動に関する。交通費申請を構成する情報のうち「日付」、「入場駅」、「出場駅」及び「利用金額」の情報は、利用履歴から抽出される情報に基づいて生成される。交通費申請を構成する情報のうち「用件」、「時刻」、「定期利用の有無」及び「申請経路」の情報は、申請者が入力した付加情報に基づいて生成される。

次に、検索パラメータ及び検索結果を構成する情報について説明する。
図５は、検索パラメータ及び検索結果を構成する情報の一例を示す図である。
図５に示す「ＩＮＰＵＴ」は、検索パラメータを構成するパラメータを示している。検索パラメータは、図５に示すパラメータ以外のパラメータを有していてもよい。検索パラメータは、検索条件に含まれる情報に基づいて指定される。

検索パラメータは、必須パラメータとして、「出発駅」、「到着駅」及び「日付」を有する。
「出発駅」は、駅名または駅コードである。「出発駅」パラメータは、交通費申請から抽出され、検索条件に含まる「入場駅」に対応する「出発駅」の情報に基づいて指定される。
「到着駅」は、駅名または駅コードである。「到着駅」パラメータは、交通費申請から抽出され、検索条件に含まれる「出場駅」に対応する「到着駅」の情報に基づいて指定される。
「日付」は、年月日である。「日付」パラメータは、交通費申請から抽出され、検索条件に含まれる「日付」の情報に基づいて指定される。
このように、必須パラメータは、検索条件に含まれる交通費申請を構成する情報、つまり、記憶媒体５に記憶されている実際の鉄道利用に関する情報に基づいて指定される。

検索パラメータは、任意パラメータとして、「時刻」、「優先順位」、「検索結果候補数」、「有料特急／新幹線利用」、「座席指定」及び「定期区間」を有する。
「時刻」は、出発駅からの出発時刻または到着駅への到着時刻である。「時刻」パラメータは、交通費申請の付加情報から抽出され、検索条件に含まれる「時刻」の情報に基づいて指定される。

「優先順位」は、移動時間が短い順、料金が安い順、及び、乗り換え回数が少ない順から１つ選択されたｎ個の候補を抽出するためパラメータである。
「検索結果候補数」は、検索結果を構成する候補の数ｎを指定する値である。
「有料特急／新幹線利用」は、有料特急及び新幹線のうちの少なくとも何れか一方の利用の可否の指定である。
「座席指定」は、有料特急及び新幹線における自由席、指定席及びグリーン席のうち優先する座席の指定である。
「優先順位」、「検索結果候補数」、「有料特急／新幹線利用」及び「座席指定」のパラメータは、検索条件に含まれる検索条件指定情報１２４に基づいて指定される。なお、検索条件指定情報１２４は、上述の何れかのパラメータを指定するための少なくとも１つの情報を有していてもよい。

「定期区間」は、定期区間の利用を指定し、定期区間の経路情報を含む。「定期区間」のパラメータは、検索条件に含まれる定期区間情報１２２に基づいて指定される。

図５に示す「ＯＵＴＰＵＴ」は、検索結果を構成する情報を示している。
検索結果は、最大ｎ個の候補で構成されている。各候補は、候補経路及び候補経路に関連付けられている料金（以下、候補料金という）を含む。候補経路は、出発駅、路線、乗換駅及び到着駅を含む。候補経路において１回以上の乗換が発生している場合には、経路候補は、路線及び乗換駅の１回以上の繰り返しを含む。なお、路線は、徒歩による移動となることもある。候補料金は、候補経路における全区間の料金である。候補料金は、有料特急及び新幹線利用時には、運賃に特急料金等を加算した額である。

図６は、検索結果の一例を示す図である。
検索条件は、図４に示す交通費申請を構成する情報に基づく「出発駅」、「到着駅」及び「日付」の情報を含んでいるものとする。必須パラメータである「出発駅」はＡ駅、「到着駅」はＢ駅、「日付」は２０１６年２月１日である。任意パラメータである「優先順位」は、料金が安い順、「検索結果候補数」は３であるものとする。

検索結果は、料金が安い順に、候補１、候補２及び候補３の順で構成されている。候補１は、候補経路として、出発駅をＡ駅、路線をＩ線、到着駅をＢ駅とする情報を有し、候補料金として５６０円とする情報を有する。候補２及び候補３も候補１と同様に候補経路及び候補料金の情報を有する。

次に、交通費申請に関する利用経路の妥当性の判断手順について説明する。
図７は、交通費申請に関する利用経路の妥当性の判断手順を説明するフローチャートである。この判断手順は、申請情報１２３に対して交通費申請処理装置１によって実行される。

取得部１１１は、交通費申請を取得する（ステップＳ２０１）。ステップＳ２０１では、取得部１１１は、記憶部１２から申請情報１２３に対応する交通費申請を取得する。なお、交通費申請は、上述のように、鉄道利用料金を支払可能な記憶媒体５から取得した「入場駅」、「出場駅」、「日付」及び「利用金額」の情報を含んでいる。

送信処理部１１２は、検索条件を経路検索サーバ２へ送信する（ステップＳ２０２）。検索条件は、上述のように、「入場駅」に対応する「出発駅」、「出場駅」に対応する「到着駅」及び「日付」の情報を含んでいる。送信処理部１１２は、交通費申請の付加情報として「時刻」が入力されている場合には、付加情報から抽出される「時刻」の情報を検索条件に含める。送信処理部１１２は、記憶部１２に定期区間情報１２２が記憶されている場合には、定期区間情報１２２を検索条件に含める。送信処理部１１２は、記憶部１２に検索条件指定情報１２４が記憶されている場合には、検索条件指定情報１２４を検索条件に含める。送信処理部１１２は、検索条件と共に、検索条件に基づく検索を要求するコマンド及び検索条件に基づく検索結果の返信を要求するコマンドを経路検索サーバ２へ送信する。

受信処理部１１３は、検索結果を経路検索サーバ２から受信する（ステップＳ２０３）。検索結果は、上述のように、検索条件に合致する候補経路及び候補経路に関連付けられている候補料金を含むｎ個の候補で構成されている。

判断部１１４は、交通費申請と検索結果を比較する（ステップＳ２０４）。
判断部１１４は、「利用金額」がｎ個の候補のうちの少なくとも１つに合致しているか否かを判断する（ステップＳ２０５）。「利用金額」がｎ個の候補のうちの少なくとも１つに合致している場合（ステップＳ２０５、Ｙｅｓ）、判断部１１４は、交通費申請を許可と判断する（ステップＳ２０６）。
「利用金額」がｎ個の候補の何れにも合致していない場合（ステップＳ２０５、Ｎｏ）、判断部１１４は、交通費申請を不許可と判断する（ステップＳ２０７）。この場合、交通費申請処理装置１は、交通費申請が不許可である旨のメッセージを、申請者がアクセス権限を有するユーザ端末３へ送信してもよい。申請者は、アクセス権限を有するユーザ端末３において特段の事情（例えば、料金の高い経路を利用した理由）を交通費申請に追加入力し、管理者のユーザ端末３へ送信することができる。管理者は、アクセス権限を有するユーザ端末３において、申請者が入力した特段の事情に応じて、交通費申請の許可を入力することができる。別の例として、交通費申請処理装置１は、交通費申請が不許可である旨のメッセージを、管理者のアクセス権限を有するユーザ端末３へ送信してもよい。管理者は、申請者から特段の事情を確認することで、アクセス権限を有するユーザ端末３において、交通費申請の許可を入力することができる。

このように、判断部１１４は、「利用金額」がｎ個の候補のうちの少なくとも１つに合致しているか否かに応じて交通費申請を許可または不許可と判断することができる。なお、ｎの値が１に設定されている場合、交通費申請処理装置１は、より厳格に交通費申請に関する利用経路の妥当性を判断することができる。

ここで再び図４に示す交通費申請及び図６に示す検索結果を参照して、判断部１１４によるステップＳ２０５〜Ｓ２０７の処理の例について説明する。
図４を参照すると、「利用金額」は５６０円である。ステップＳ２０５では、判断部１１４は、「利用金額」である５６０円が経路１の候補料金に合致していると判断する。ステップＳ２０６において、判断部１１４は、図４に示す交通費申請を許可と判断する。

他方、図４に示す交通費申請の「利用料金」が８００円であったと仮定し、検索結果が図６に示すように出たと仮定する。この場合、ステップＳ２０５では、判断部１１４は、「利用金額」である８００円が経路１〜経路３の何れの候補料金にも合致しないと判断する。ステップＳ２０７において、判断部１１４は、交通費申請を不許可と判断する。

次に、他の例として図８に示す交通費申請及び図９に示す検索結果を参照して、図７に示す処理の例について説明する。
ステップＳ２０１では、取得部１１１は、図８に示す交通費申請を取得する。図８に示す交通費申請は、一部に定期区間を利用したＥ駅とＦ駅との間の移動に関する。申請者は、定期区間内のＥ駅で入場したものとする。「利用料金」は、定期区間の料金が控除されている。ここでは、Ｅ駅とＦ駅は、路線Ｊの駅であり、Ｅ駅とＦ駅との間にはＸ駅があるものとする。また、申請者は、Ｅ駅とＸ駅との間の定期を所有し、記憶部１２は、申請者の定期区間情報１２２を記憶しているものとする。

ステップＳ２０２では、送信処理部１１２は、「入場駅」であるＥ駅に対応する「出発駅」、「出場駅」であるＦ駅に対応する「到着駅」及び「日付」である２０１６年３月１日の情報を含み、定期区間情報１２２及び検索条件指定情報１２４を含む検索条件を経路検索サーバ２へ送信する。なお、送信処理部１１２は、定期区間の料金を控除した候補料金の算出を要求するコマンドを経路検索サーバ２へ送信してもよい。

ステップＳ２０３では、受信処理部１１３は、検索結果を経路検索サーバ２から受信する。図９は、検索結果の一例を示す図である。必須パラメータである「出発駅」はＥ駅、「到着駅」はＦ駅、「日付」は２０１６年３月１日である。任意パラメータである「優先順位」は、料金が安い順、「検索結果候補数」は３であるものとする。また、任意パラメータである「定期区間」は、定期区間の経路情報が指定されている。候補１は、候補経路として、出発駅をＥ駅、路線をＪ線、到着駅をＦ駅とする情報を有し、候補料金として２００円とする情報を有する。候補料金は、Ｅ駅とＸ駅との間の定期区間の料金が控除されたＸ駅とＦ駅との間の料金である。

ステップＳ２０４では、判断部１１４は、交通費申請と検索結果を比較する。
ステップＳ２０５では、判断部１１４は、図８に示す「利用金額」である２００円が経路１の候補料金に合致していると判断する。ステップＳ２０６において、判断部１１４は、図８に示す交通費申請を許可と判断する。

他方、図８に示す交通費申請の「利用料金」が６００円（定期区間を使用しない経路を利用した料金）であったと仮定し、検索結果が図９に示すように出たと仮定する。この場合、ステップＳ２０５では、判断部１１４は、「利用金額」である６００円が経路１〜経路３の何れの候補料金にも合致しないと判断する。ステップＳ２０７において、判断部１１４は、交通費申請を不許可と判断する。

本実施形態によれば、交通費申請に関する利用経路が会社側で規定されている交通費に関するルールに沿っているのか否かを判断することで、交通費申請に関する利用経路の妥当性を判断することができる。これにより、会社側は、煩雑な作業を要することなく、ルールに沿って適切に交通費申請を処理することができる。例えば、会社側は、ルールに沿っていない経路を利用した高額な交通費申請の精算を防止することができる。
また、本実施形態によれば、定期区間を考慮して、交通費申請に関する利用経路の妥当性を判断することができる。これにより、会社側は、定期区間を考慮して適切に交通費精算を処理することができる。例えば、会社側は、定期区間の料金を含んだ交通費申請の精算を防止することができる。

なお、本実施形態は、以下で説明するように、交通費申請の付加情報に応じて、より高い精度で交通費申請に関する経路の妥当性を判断することができる。

交通費申請が「時刻」の情報として申請者の入力に基づく入場駅からの出発時刻または出場駅への到着時刻の情報を含む態様について説明する。
この場合、上述のステップＳ２０２において送信処理部１１２が送信する検索条件は、「時刻」パラメータを指定する出発時刻または到着時刻の情報を含む。検索条件が出発時刻または到着時刻の情報を含んでいる場合、経路検索サーバ２は、出発時刻または到着時刻に合致するｎ個の候補を指定された優先順位に応じて検索する。他方、検索条件が出発時刻または到着時刻の情報を含んでいない場合には、経路検索サーバ２は、例えば任意の時間帯におけるｎ個の候補を指定された優先順位に応じて検索する。

ここで、第１の駅と第２の駅との間の経路を考える。第１の駅と第２の駅との間は、複数の路線が通っているとする。このような場合、第１の駅と第２の駅との間における移動時間が短い経路の順序、料金が安い経路の順序、及び、乗り換え回数が少ない経路の順序は、時間帯によって異なる可能性がある。

ここで説明する態様のように、経路検索サーバ２が出発時刻または到着時刻に合致するｎ個の候補を検索できれば、検索結果はより精度の高いものとなる。そのため、交通費申請処理装置１は、より高い精度で交通費申請に関する経路の妥当性を判断することができる。

なお、検索条件が出発時刻または到着時刻を含む場合には、申請者の利用路線は、一義的に決まる可能性が高い。また、検索結果を構成する候補の数が少ないほど、交通費申請処理装置１による妥当性の判断の精度は高くなる。そのため、送信処理部１１２は、検索条件指定情報１２４における「検索結果候補数」パラメータの指定に関わらず、「検索結果候補数」パラメータのｎを１に指定する検索条件を経路検索サーバ２へ送信してもよい。これにより、検索結果を構成する候補の数は１つとなる。したがって、交通費申請処理装置１は、より高い精度で交通費申請に関する経路の妥当性を判断することができる。

次に、交通費申請が申請者の入力に基づく「申請経路」を含んでいる態様について説明する。
判断部１１４は、ステップＳ２０５において「利用金額」がｎ個の候補のうちの少なくとも１つに合致していると判断した場合、さらに、「申請経路」が「利用金額」と合致する候補に含まれる候補経路と合致するか否かを判断する。判断部１１４は、申請経路が「利用金額」と合致する候補に含まれる候補経路と合致すると判断した場合には、ステップＳ２０６において交通費申請を許可と判断する。他方、判断部１１４は、「申請経路」が「利用金額」と合致する候補に含まれる候補経路と合致しないと判断した場合には、ステップＳ２０７において交通費申請を不許可と判断する。

ここでは、第１の駅と第２の駅との間の移動に関して以下のケースを想定する。第１の駅と第２の駅との間には複数の路線が通っている。路線ａの料金と路線ｂの料金は同一である。路線ａでの移動時間は、路線ｂでの移動時間よりも長い。このようなケースにおいて、申請者は、路線ａを利用したものとする。検索結果は、移動時間が短い順にｎ個の候補で構成され、路線ｂの候補を含んでいるが、路線ａの候補を含んでいないものとする。

この場合、「利用料金」は申請者が利用していない路線ｂの料金と同じであるため、上述の図７の処理では、判断部１１４は、交通費申請を許可と判断する。つまり、交通費申請処理装置１は、申請者が検索結果に含まれていない候補経路を利用したにも関わらず、交通費申請を許可と判断する。

ここで説明する態様によれば、交通費申請処理装置１は、検索結果に「利用料金」と同じ額の候補料金が含まれているとしても、申告経路と検索結果に含まれる候補経路とをさらに比較する。これにより、交通費申請処理装置１は、より高い精度で交通費申請に関する経路の妥当性を判断することができる。例えば、会社側は、同一の利用料金であっても、時間がかかる経路を利用した申請者の交通費申請を妥当ではないと判断することができる。

次に、本実施形態の変形例について説明する。
１つ目の変形例として、記録処理部１１５は、ステップＳ２０６において交通費申請を許可と判断した後に、ｎ個の候補のうちの利用金額と合致する候補に含まれる候補経路を利用経路として交通費申請に関連付けて記憶部１２に記録するようにしてもよい。

上述のように、利用履歴は、「入場駅」及び「出場駅」の情報を含んでいるが、利用経路の情報を含んでいない。そのため、交通費申請も利用路線の情報を含んでいない。交通費申請処理装置１は、利用金額と合致する候補金額に関連付けられている候補経路を利用路線として推定することができる。

この変形例によれば、交通費申請処理装置１は、社員毎に申請情報１２３に関連付けた利用路線の情報を収集することができる。これにより、会社側は、会社側で規定したルールに沿いつつ、社員が複数ある経路のうちどの経路を用いて移動したのかなど、社員の行動を把握することができる。

２つ目の変形例として、記憶部１２は、複数の検索条件指定情報１２４を記憶していてもよい。例えば、会社側は、ある役職以上については有料特急及び新幹線の利用を可とする検索条件指定情報１２４を記憶部１２に登録し、ある役職未満については有料特急及び新幹線の利用を不可とする検索条件指定情報１２４を記憶部１２に登録することができる。なお、複数の検索条件指定情報１２４は、それぞれ、社員の識別情報１２１に関連付けられている。

この場合、図７に示すステップＳ２０２において、送信処理部１１２は、交通費申請に含まれる識別情報１２１を参照して、検索条件に含める検索条件指定情報１２４を記憶部１２から取得する。そして、取得した検索条件指定情報１２４を含めた検索条件を経路検索サーバ２へ送信する。

この変形例によれば、社員の役職等で異なるルールが規定されているとしても、交通費申請処理装置１は、異なるルールに応じて交通費申請に関する経路の妥当性を判断することができる。

３つ目の変形例について説明する。申請者が定期区間を利用した場合、利用履歴を構成する「入場駅」及び「出場駅」のうちの何れか一方の情報は、申請者が実際に入場した駅または出場した駅ではない可能性がある。

はじめに、申請者が定期区間内の駅で入場し、定期区間外の駅で出場（以下、定期外出場という）した場合について説明する。利用履歴を構成する「入場駅」は、定期区間の駅のうち、申請者が実際に出場した定期区間外の駅との間の料金が最安値となる駅である。つまり、利用履歴を構成する「入場駅」は、申請者が実際に入場した駅ではない。他方、利用履歴を構成する「出場駅」は、定期区間外の駅なので申請者が実際に出場した駅である。

次に、申請者が定期区間外の駅で入場（以下、定期外入場という）し、定期区間内の駅で出場した場合について説明する。利用履歴を構成する「入場駅」は、定期区間外の駅なので申請者が実際に入場した駅である。利用履歴を構成する「出場駅」は、定期区間の駅のうち、申請者が実際に入場した定期区間外の駅との間の料金が最安値となる駅である。つまり、利用履歴を構成する「出場駅」は、申請者が実際に出場した駅ではない。

上述のように利用経路のうちの一部に定期区間を利用した場合には、利用履歴の「内容」には、運賃支払の情報と共に、利用経路のうちの一部に定期区間を利用した旨の情報（例えば、定期外出場または定期外入場）が記録される。例えば、図２に示す利用履歴の一例においては、３番目の要素については、内容欄に「定期外出場」と記録されている。この場合、出場駅についてはＦ駅で確定するが、入場駅については実際はＥ駅ではなく定期内区間のどこかの駅であるという解釈となり、実際の入場駅が利用履歴からは特定することができない。

再び図３を参照して、この変形例における交通費申請の登録手順について説明する。
ステップＳ１０１では、取得部３１１は、上述のように利用履歴を取得する。
ステップＳ１０２では、生成部３１２は、上述のように利用履歴のうち交通費申請の対象とする項目の選択を受け付ける。生成部３１２は、利用履歴の「内容」の情報を参照して、利用経路のうちの一部に定期区間を利用しているか否かを判断する。例えば、生成部３１２は、利用履歴の「内容」に定期外出場または定期外入場の情報が記録されていれば、利用経路のうちの一部に定期区間を利用していると判断する。利用経路のうちの一部に定期区間を利用している場合、生成部３１２は、「日付」及び「利用金額」の情報を、交通費申請における必須の情報として利用履歴から取得する。これに加えて、利用履歴の「内容」に定期外出場が記録されている場合、生成部３１２は、「出場駅」の情報を、交通費申請における必須の情報として利用履歴から取得する。「入場駅」は実際の入場駅ではないので、生成部３１２は、「入場駅」の情報を交通費申請における必須の情報として利用履歴から取得しない。他方、利用履歴の「内容」に定期外入場が記録されている場合、生成部３１２は、「入場駅」の情報を、交通費申請における必須の情報として利用履歴から取得する。「出場駅」は実際の出場駅ではないので、生成部３１２は、「出場駅」の情報を交通費申請における必須の情報として利用履歴から取得しない。

ステップＳ１０３では、生成部３１２は、付加情報として、上述の「外出先」、「要件」、「時刻」、「定期利用の有無」及び「申請経路」に加えて、利用履歴から取得しなかった「入場駅」または「出場駅」の入力を受け付ける。少なくとも「入場駅」または「出場駅」は、必須の入力項目である。
ステップＳ１０４では、生成部３１２は、上述のように交通費申請を生成する。
ステップＳ１０５では、送信処理部３１３は、上述のように交通費申請を交通費申請処理装置１へ送信する。

交通費申請処理装置１では、取得部１１１は、上述のように生成された交通費申請を取得する。交通費申請は、記憶媒体５から取得した「日付」と「利用金額」、及び、「入場駅」と「出場駅」を含む。「入場駅」及び「出場駅」の何れか一方は記憶媒体５の利用履歴から取得され、もう一方は申請者の入力に基づく付加情報から取得される。

この変形例によれば、記憶媒体５の利用履歴に実際の入場駅または実際の出場駅の何れか一方が記録されていないとしても、申請者に実際の入場駅または実際の出場駅の入力を要求することで、交通費申請に関する利用経路の妥当性を判断することができる。

４つ目の変形例について説明する。検索条件指定情報１２４は、移動時間が短い順、料金が安い順、及び、乗り換え回数が少ない順から少なくとも１つ選択された「優先順位」パラメータを指定する情報を含んでいてもよい。「優先順位」パラメータを指定する情報が１つ選択されている場合の態様については上述のとおりである。

再び図７を参照して、「優先順位」パラメータを指定する情報が２つ以上選択されている場合における交通費申請処理装置１の処理について説明する。交通費申請処理装置１は、後述するように、「優先順位」パラメータを指定する情報の数だけステップＳ２０２及びステップＳ２０３の処理を繰り返す。
ステップＳ２０１では、取得部１１１は、上述のように交通費申請を取得する。
ステップＳ２０２では、送信処理部１１２は、「優先順位」パラメータを指定する第１の情報を含む検索条件を経路検索サーバ２へ送信する。「優先順位」パラメータを指定する第１の情報は、例えば移動時間が短い順を指定する情報であるものとする。
ステップＳ２０３では、受信処理部１１３は、例えば移動時間が短い順に抽出されたｎ個の候補を含む検索結果を経路検索サーバ２から受信する。

次に、交通費申請処理装置１は、ステップＳ２０２及びステップＳ２０３の処理を繰り返す。つまり、ステップＳ２０２では、送信処理部１１２は、「優先順位」パラメータを指定する第２の情報を含む検索条件を経路検索サーバ２へ送信する。「優先順位」パラメータを指定する第２の情報は、例えば料金が安い順を指定する情報であるものとする。その後、ステップＳ２０３では、受信処理部１１３は、例えば料金が安い順に抽出されたｎ個の候補を含む検索結果を経路検索サーバ２から受信する。
検索条件指定情報１２４が「優先順位」パラメータを指定する第３の情報（例えば乗り換え回数が少ない順を指定する情報）を含んでいれば、交通費申請処理装置１は、同様にステップＳ２０２及びステップＳ２０３の処理を繰り返す。

次に、ステップＳ２０４では、判断部１１４は、交通費申請と、検索条件指定情報１２４に含まれる「優先順位」パラメータを指定する情報の数に相当する数の検索結果を比較する。つまり、判断部１１４は、交通費申請と、複数の検索結果に含まれる全ての候補を比較する。ステップＳ２０５では、判断部１１４は、「利用金額」がα×ｎ個の候補のうちの少なくとも１つに合致しているか否かを判断する。ここでαは、「優先順位」パラメータを指定する情報の数である。ステップＳ２０５の処理に応じて、ステップＳ２０６では判断部１１４は上述のように交通費申請を許可と判断し、ステップＳ２０７では判断部１１４は上述のように交通費申請を不許可と判断する。

この変形例によれば、会社側で規定されている交通費に関するルールが複数の「優先順位」を認めている場合であっても、交通費申請処理装置１は、ルールに沿って交通費申請に関する利用経路の妥当性を判断することができる。

なお、本願発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、実施形態及び変形例は可能な限り適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適当な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。

１…交通費申請処理装置、２…経路検索サーバ、３…ユーザ端末、１１…制御部、１２…記憶部、１３…通信部、２１…制御部、２２…記憶部、２３…通信部、３１…制御部、３２…記憶部、３３…入力部、３４…表示部、３５…第１通信部、３６…第２通信部、１００…交通費申請処理システム、１１１…取得部、１１２…送信処理部、１１３…受信処理部、１１４…判断部、１１５…記録処理部、１２１…識別情報、１２２…定期区間情報、１２３…申請情報、１２４…検索条件指定情報、２２１…経路情報、２２２…時刻表情報、２２３…料金情報、３１１…取得部、３１２…生成部、３１３…送信処理部。

Claims (6)

1. 鉄道利用料金を支払可能な記憶媒体から取得した日付と利用金額、及び、入場駅と出場駅を含む交通費申請を取得する取得部と、ここで、前記取得部は、前記入場駅及び前記出場駅のそれぞれを、前記記憶媒体の利用履歴または申請者の入力に基づいて取得し、さらに、前記取得部は、前記申請者が定期区間内の駅で入場し前記定期区間外の駅で出場した場合、または、前記申請者が前記定期区間外の駅で入場し前記定期区間内の駅で出場した場合、前記定期区間外の駅を前記記憶媒体の前記利用履歴から取得し、前記定期区間内の駅を前記申請者の入力に基づいて取得し、
   前記入場駅に対応する出発駅、前記出場駅に対応する到着駅、前記日付、前記申請者の前記定期区間の経路情報、及び、組織で規定される交通費に関するルールに沿った指定情報を含む検索条件を経路検索サーバへ送信する送信処理部と、
   前記検索条件に合致する候補経路及び前記候補経路に関連付けられている候補料金を含むｎ（ｎは１以上の整数）個の候補で構成されている検索結果を前記経路検索サーバから受信する受信処理部と、
   前記交通費申請と前記検索結果を比較し、少なくとも前記利用金額が前記ｎ個の候補のうちの少なくとも１つに合致しているか否かに応じて前記交通費申請を許可または不許可と判断する判断部と、
   前記交通費申請が許可と判断された後に、前記ｎ個の候補のうちの前記利用金額と合致する候補に含まれる候補経路を利用経路として、少なくとも前記入場駅及び前記出場駅を含む前記交通費申請に関連付けて記憶部に記録する記録処理部と、
   を備える交通費申請処理装置。
2. 前記指定情報は、移動時間が短い順、料金が安い順、及び、乗り換え回数が少ない順から少なくとも１つ選択された前記ｎ個の候補を抽出するための優先順位を指定する情報を有する、
   請求項１記載の交通費申請処理装置。
3. 前記交通費申請は、前記申請者の入力に基づく前記入場駅からの出発時刻または前記出場駅への到着時刻の情報を含み、
   前記検索条件は、前記出発時刻または前記到着時刻を含む、請求項１記載の交通費申請処理装置。
4. 前記交通費申請は、前記申請者の入力に基づく申請経路を含み、
   前記判断部は、前記申請経路が前記利用金額と合致する候補に含まれる候補経路と合致すると判断した場合には前記交通費申請を許可と判断し、前記申請経路が前記利用金額と合致する候補に含まれる候補経路と合致しないと判断した場合には前記交通費申請を不許可と判断する、請求項１記載の交通費申請処理装置。
5. 前記指定情報は、前記ｎを指定する値、有料特急及び新幹線のうちの少なくとも何れか一方の利用の可否の指定、及び、前記有料特急及び前記新幹線における自由席、指定席及びグリーン席のうちの優先する座席の指定のうちの少なくとも１つの情報を有する、
   請求項１記載の交通費申請処理装置。
6. 鉄道利用料金を支払可能な記憶媒体から取得した日付と利用金額、及び、入場駅と出場駅を含む交通費申請を取得する機能と、ここで、前記交通費申請を取得する機能は、前記入場駅及び前記出場駅のそれぞれを、前記記憶媒体の利用履歴または申請者の入力に基づいて取得し、さらに、前記交通費申請を取得する機能は、前記申請者が定期区間内の駅で入場し前記定期区間外の駅で出場した場合、または、前記申請者が前記定期区間外の駅で入場し前記定期区間内の駅で出場した場合、前記定期区間外の駅を前記記憶媒体の前記利用履歴から取得し、前記定期区間内の駅を前記申請者の入力に基づいて取得し、
   前記入場駅に対応する出発駅、前記出場駅に対応する到着駅、前記日付、前記申請者の前記定期区間の経路情報、及び、組織で規定される交通費に関するルールに沿った指定情報を含む検索条件を経路検索サーバへ送信する機能と、
   前記検索条件に合致する候補経路及び前記候補経路に関連付けられている候補料金を含むｎ（ｎは１以上の整数）個の候補で構成されている検索結果を前記経路検索サーバから受信する機能と、
   前記交通費申請と前記検索結果を比較し、少なくとも前記利用金額が前記ｎ個の候補のうちの少なくとも１つに合致しているか否かに応じて前記交通費申請を許可または不許可と判断する機能と、
   前記交通費申請が許可と判断された後に、前記ｎ個の候補のうちの前記利用金額と合致する候補に含まれる候補経路を利用経路として、少なくとも前記入場駅及び前記出場駅を含む前記交通費申請に関連付けて記憶部に記録する機能と、
   をコンピュータに実行させる交通費申請処理プログラム。