JP2019204202A - 移動目的判定方法、移動目的判定装置、移動目的判定システム - Google Patents

Abstract

【課題】移動履歴から移動の目的を判定する。【解決手段】本開示に係る移動目的判定では，業務のために交通機関を利用できる日時，地理的範囲，および，行先を指定した判定ルールと，交通機関の利用記録である入場駅，出場駅，利用日時，利用者識別情報，および，位置情報を取得する利用履歴取得手段とを備え，取得した情報と前記判定ルールに基づいて，移動の目的が業務利用であるか業務利用でないかの判定を行う。【選択図】図７

Description

本発明は，移動の履歴から移動の目的を判定する移動目的判定方法、移動目的判定装置及び移動目的判定システムに関するものである。

人の働き方が多様化していく中で，通勤の態様も変化しつつある。今後，在宅勤務やシェアオフィスの普及によって，毎日同じ場所に通う人は減少していくと考えられる。その場合には，毎日同じ場所に通うことを前提とした「通勤定期」に対して，企業が手当を支払うことが見直されることとなる。また，利用者にとっても定期券は固定された特定の交通手段しか利用できないため、移動の実態に適さないこととなる。

一方，鉄道やバス，タクシーなどの多様な交通手段をワンストップで検索，予約，決済可能なMaaS(Mobility as a Service)と呼ばれるサービスが普及しつつある。このMaaSでは，複数交通手段を組み合わせたパッケージや，利用量に応じた段階的な課金体系が検討されている。
ただし，ＭａａＳのようなサービスを企業が活用するためには、企業は，行先や交通手段が固定されていない従業員の日々の移動の中から，業務上必要な移動とそれ以外の移動を区別する必要がある。

これに対して，特願２０１６−８１１０１号公報（特許文献１）では、「鉄道利用料金を支払可能な記憶媒体から取得した日付と利用金額、及び、入場駅と出場駅を含む交通費申請と，前記入場駅を出発駅、前記出場駅を到着駅，及び前記日付を検索条件にして得た候補経路と料金から，前記利用金額が候補のうちの少なくとも１つに合致しているか否かに応じて前記交通費申請を許可または不許可と判断する。」という記載がある。

また，特開２０１４−４９０７６号公報（特許文献２）では、「交通費規則DBに予め交通費規則を設定しておき、探索された経路が交通費規則に適合しているか否かを判定し，探索された経路情報と判定結果とを表示することで，適切な経路候補を提示し、交通費規則に適合している交通費を申請する」という記載がある。

特願２０１６−８１１０１号公報 特開２０１４−４９０７６号公報

上記の特許文献１においては，ICカードなどの記憶媒体に記録された入場駅や出場駅等の情報から、利用者の移動経路を作成し、これに基づいて、交通費の申請が可能となる。また，作成した経路の料金が，経路検索結果に含まれる候補経路の料金のいずれか一つに合致していれば，交通費申請を許可するとしている。しかし，特許文献1においては、経路の料金のみを観点として判断しているため、当該移動が業務目的であるか否かの判定は行っていない。

また、上記の特許文献２においては，交通費規則DBに利用可能な交通手段を登録しておき，申請された経路が交通費規則に合致しているかを自動的に判定することが記載されている。この技術を用いて交通費申請の承認を行うためには，まず、交通費規則DBに業務における行先をあらかじめ登録しておき，申請内容と照合することで，交通費申請が業務上必要なものであったか判定することとなる。しかし，この場合、予め全ての業務上の行先を登録しておく必要があり，行先の追加や削除の負荷が大きい。

そこで，本発明では，交通手段の利用履歴や位置情報を利用して，業務遂行のために必要な移動行動や行先を判定し，交通機関利用履歴から業務目的の利用に該当する否か自動的に判断することを課題としている。

前述の課題を解決するために，代表的な本発明の移動目的判定方法の一つは、課金管理装置と、判定装置と、スケジュール管理サーバとがネットワークを介して接続された移動目的判定装置を用いる移動目的判定方法であって、前記移動目的判定装置は、履歴取得部と、スケジュール取得部と、判定部と、判定ルールデータベースとを有し、前記履歴取得部が、前記課金管理装置から交通機関の利用記録を示す利用日時，位置情報，利用者識別情報を含む利用履歴を取得する工程と、前記スケジュール取得部が、前記利用者識別情報と前記利用日時に基づいて，前記スケジュール管理サーバから利用者のスケジュールを取得する工程と，前記判定部が、前記判定ルールデータベースに格納される判定ルールに基づいて，前記利用履歴と，前記利用者の予定から移動の目的が業務利用であるか否かを判定する移動目的判定工程とを含む。

本発明によると，交通手段の利用履歴や位置情報を利用して，業務遂行のために必要な移動行動や行先を判定し，交通機関利用履歴から業務目的の利用に該当するものを抽出することができる。これにより、移動を管理する企業や利用者の負担が大幅に削減され、交通利用に対する請求・手当を従来より簡単に処理することが可能となる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明の一実施例におけるシステム構成，および，機能ブロックを示す図である。 本発明の一実施例における利用履歴，および，位置情報を示す図である。 本発明の一実施例におけるスケジュール情報を示す図である。 本発明の一実施例における利用明細を示す図である。 本発明の一実施例における判定ルール，および，承認済行先リストを示す図である。 本発明の一実施例におけるアカウント，および，契約プランを示す図である。 本発明の一実施例におけるシステム構成の一例を示す図である。 本発明の一実施例における利用者アプリケーション画面を示す図である。 本発明の一実施例における判定フローの全体を示す図である。 本発明の一実施例における判定フローを示す図である。 本発明の一実施例における承認済行先リストの追加フローを示す図である。 本発明の他の実施例におけるシステム構成の一例を示す図である。

以下、図面を参照して、本発明の実施形態について説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

[移動目的判定システムの構成]
まず、図１を参照して、本発明に係る態様を実現するためのハードウェアの構成について説明する。

図１は、本発明の一実施例におけるシステム構成，および，機能ブロックを示す図である。本実施例のシステム構成は、図１に示すように、課金管理装置１と、判定装置２と、ネットワーク３と、利用者端末４と、管理者端末５とから構成される。課金管理装置１と、判定装置２と、利用者端末４と、管理者端末５とがネットワーク３を介してお互いに通信可能に接続される。

課金管理装置１は、ＣＰＵ１２と、通信インターフェース（以下、「通信Ｉ／Ｆ」と記載することがある）１３と、課金管理プログラム１００と、課金管理データベース１５０とを備える。課金管理データベース１５０には、利用明細３１０，アカウント６３０及び契約プラン６４０が格納されている。そして、課金管理プログラム１００は、履歴取得部１０１と、明細作成部１０２とから成る。

判定装置２は、ＣＰＵ１２と、通信Ｉ／Ｆ１３と、判定プログラム２００と判定データベース２５０とを備える。判定データベース２５０には、判定ルール６１０と、承認済行先リスト６２０とが格納されている。そして、判定プログラム２００は、スケジュール取得部１０３と、プレゼンス取得部１０４と，メタデータ取得部１０５と，判定部１０６とから成る。

利用者端末４は、ＣＰＵ１２と、通信Ｉ／Ｆ１３と、利用者アプリケーション４００とを備える。そして、当該利用者アプリケーション４００は、課金管理装置１から取得する電子チケットを記録するチケット格納部４０１と、当該チケットを用いた交通機関の利用履歴を格納し、課金管理装置１へと送信する移動履歴送信部４０２と、緯度・経度などの位置情報を送信する位置情報送信部４０３とから成る。

管理者端末５は、ＣＰＵ１２と、通信Ｉ／Ｆ１３と、管理者アプリケーション５００とを備える。そして、当該管理者アプリケーション５００は，前記判定プログラム２００との間で，交通機関の利用明細に関するデータを送受信する明細送受信部５０１と，管理者が利用明細中の交通機関の利用目的を判定するための判定部５０２とから成る。

次に、上記の各構成要素の動作の概要を説明する。まず、課金管理装置１の課金管理プログラム１００の履歴取得部１０１は、通信Ｉ／Ｆ１３を介して，利用者端末４の利用者アプリケーション４００から、移動履歴および位置情報のデータを受信する。そして，課金管理プログラム１００の明細作成部１０２は、受信した移動履歴と位置情報とから利用明細を作成し，この利用明細を課金管理データベース１５０に利用明細３１０として格納する。

次に，判定装置２の判定プログラム２００は，課金管理装置1の課金管理データベース１５０から、利用明細３１０を取得し、当該利用明細３１０から利用者を識別するユーザＩＤと、利用日時を抽出する。そして、判定プログラム２００のスケジュール取得部１０３は、通信Ｉ／Ｆ１３を介して，企業が運用するスケジュール管理サーバ（図１に例示せず）から，当該利用日時における，当該ユーザＩＤを持つ従業員（すなわち、前記利用者）の予定情報を取得する。さらに，判定プログラム２００のプレゼンス取得部１０４は，当該利用日時における，当該ユーザＩＤを持つ従業員のオフィス入退室情報を取得する。そして，判定プログラム２００の判定部１０６は，取得した予定情報と、従業員のオフィス入退室情報を判定ルール６１０に照らし合わせて，当該明細が業務目的とみなせるか否かを判定する（この判定処理については、図９〜１０を参照して詳述する）。
なお、上述したデータの取得や判定は、プログラムを用いて実行される態様で説明したが、これらの機能は、専用ハードウエアによって実現されてもよく、ソフトウエアのモジュールによって実現されてもよい。

利用明細３１０が業務目的であると判定された場合には，課金管理装置１の課金管理プログラム１００は，明細中の交通機関利用分を，企業のアカウント６３０に加算する。このアカウントに計上された交通機関利用量に基づいて，課金管理プログラム１００は企業への請求額を決定する。

次に、利用者が交通機関を利用した場合の各構成要素の動作の概要を説明する。

利用者（企業の従業員等）は、利用者端末４で稼働する利用者アプリケーション４００に格納された電子チケットを用いて交通機関を利用する。ここで、電子チケットとは、NFC通信等の手段を通して、改札など交通事業者の端末に交通サービスの利用権を提示し、かつ、電子チケット内に交通サービスを利用した移動履歴を保存するものである。交通機関の利用後、利用者アプリケーション４００の移動履歴送信部４０２は，課金管理装置の課金管理プログラム１００に移動履歴を送信する。そして、課金管理装置１の課金管理プログラム１００は，移動履歴を利用者端末４から取得して、交通費明細（例えば、利用明細３１０）を作成し、判定装置２の判定プログラム２００に送信する。

次に、利用明細３１０を受信した判定装置２の判定プログラム２００は，利用明細３１０から利用者アプリケーション４００で検出されたGPS位置情報，BLEマーカーを取得し，さらに移動先滞在時間帯のオフィスの入退室情報（すなわち、プレゼンス情報）を取得し，判定ルール６１０に照らし合わせて業務利用か業務利用でないかを判断する。判定ルールの詳細については後述するが、例えば，判定プログラム２００は，利用者が社内のオフィス入退室情報やWi-Fi接続情報が取得できた（つまり、利用者は業務用とみなされる場所に滞在していた）場合には，利用明細３１０に記録されている移動が業務利用であると判定する。また，位置情報があらかじめ登録されている承認済行先リスト中の位置情報に該当する場合にも、利用明細３１０に記録されている移動が業務利用であると判定する。このように、本発明では、利用者の入退室情報を判定処理に用いるため、例えば利用者が休日に承認済行先リストに登録されている行先に行っても、この移動は業務目的と判定されない。

次に、利用明細３１０が業務利用と判定されなかった場合には、判定プログラム２００は、当該利用明細３１０を管理者端末５の管理者アプリケーション５００に送信する。そして、管理者は、この利用明細３１０の目的（つまり、業務利用であるか業務利用でないか）を判定して、この判定結果を判定装置２の判定プログラム２００に返信する。ここで、判定プログラム２００は，管理者が当該利用明細３１０を承認した場合には，当該利用明細３１０に記録される行先を承認済行先リスト６２０に追加する。この承認済行先リスト６２０を用いることで，その後，同一組織に所属する利用者（同じ従業員または別の従業員）が，一定期間内に，承認済の行先に行った場合には，その移動が自動的に業務利用とみなすことができる。

以上の処理により、交通機関の利用履歴を，業務を遂行するために必要な移動とそうでないものに分離し，業務を遂行するために必要な移動にかかる費用だけを企業に請求することができる。

次に、図２から図６を用いて、課金管理装置１及び判定装置２に格納される情報について説明する。

図２（ａ）（ｂ）は、利用者端末４の利用者アプリケーション４００によって作成され、課金管理装置１に送付される移動履歴２１０および位置情報２２０を示している。図２（ａ）に示されるように、この移動履歴２１０は，利用者の識別子であるユーザＩＤ２１１と，利用者が通過した改札の識別子である改札ＩＤ２１２と，入場または出場のどちらかを示す２１３と，前記利用者が通過した日時２１４等のような、利用者の移動に関する情報を有するものである。

図２（ｂ）に示されるように、位置情報２２０は，利用者の識別子であるユーザＩＤ２１１と，当該位置情報が観測された日時２２２と，利用者がいる場所に該当する緯度２２３及び経度２２４と、利用者携帯端末が接続されているWi-Fiステーション（例えば、駅や空港に設置されるWi-Fiステーション）を一意に識別するWi-FiステーションID２２５と、場所（駅、オフィスビル、ショッピングセンター、イベント会場等）を一意に識別するucode２２０とから成る。

図３（ａ）は，本発明の実施における判定プログラム２００のスケジュール取得部１０３が，企業が管理するスケジュール管理サーバ（例えば、後述する図７の社内スケジューラー７０３）から取得する利用者の予定情報３００を示す図である。予定情報３００とは、利用者のスケジュールや日程などを表す情報である。例えば、予定情報３００は、外出の行先や日時、会議の日程等を含む。この予定情報３００は、本人がコンピュータや端末等を介して事前に入力してもよく、第三者（同じ企業に属する事務員等）が入力した情報であってもよい。図３（ａ）に示されるように、この予定情報３００は，前記利用者の識別子であるユーザＩＤ３０１と，前記利用者の予定３０２と，前記予定の行先３０３と，前記予定の開始時刻３０４と，前記予定の終了時刻３０５と，行先の補足情報であるメタデータ３０６（例えば、BLEマーカーに対応するURL等）とから成る。

そして、図３（ｂ）は，前記判定プログラム２００のプレゼンス取得部１０４が取得する利用者のオフィス入退室情報３２０を示す図である。図３（ｂ）に示されるように、当該オフィス入退室情報３２０は，前記利用者の識別子であるユーザＩＤ３２１と，前記利用者が入退室したオフィスの出入り口を示すゲートＩＤ３２２と，入場または出場のどちらかを示す入/出３２３と，前記ゲート通過日時３２４とから成る。なお、以下では、利用者の、ある場所における滞在時間を示す入退室情報はプレゼンス情報と呼ぶこともある。

次に、図４を参照して、本発明の一実施例における利用明細について説明する。図４は，本発明の実施における前記課金管理プログラム１００の明細作成部１０２が，図２（ａ）に示す利用履歴２１５と，図２（ｂ）に示す位置情報２２０から作成する利用明細３１０を示す図である。当該利用明細３１０は，利用者の交通機関利用の履歴と，それらの交通機関を利用して行った場所の位置情報とを時系列順に並べたものである。
この利用明細３１０は移動の順番を示す移動順序３１１と，利用者が居た場所の地理的座標を示す位置情報３１２と，前記利用者が利用した路線を示す路線情報３１３と，利用者が入場した前記路線の入場場所を示す入場情報３１４と，利用者が出場した前記路線の出場場所を示す出場情報３１５と，利用者が前記路線に入場した入場時刻（例えば、入場駅の改札口を通過した時刻）を示す入日時３１６と，利用者が前記路線を出場した出場時刻を示す出日時３１７と，移動先で取得した、移動先を一意に識別する場所コード３１８（例えばucodeやBLEマーカーに対応するURL）と，業務利用の判定ステータス（例えば、業務利用、業務利用ではない、未判定）を示す判定結果３１９とから成る。
なお、ここで，利用者が交通機関を利用して移動した場合には，位置情報は存在せず（例えば、順序１〜２、４〜５），移動先の位置情報については，路線情報３１３，前記路線の入場情報３１４，前記路線の出場情報３１５は存在しない（例えば順序３）。

次に、図５（ａ）及び図５（ｂ）を参照して、本発明の一実施例における判定ルール，および，承認済行先リストについて説明する。図５（ａ）は，本実施例における前記判定ルール６１０の一例の構成を示す。前記判定ルール６１０は，ＩＦ−ＴＨＥＮ形式のルールであり，条件を定義する条件部６１１と、条件部６１１で定義された条件が満たされた場合の結論を定義する結論部６１２とからなる。さらに、条件部６１１は，日時条件６１２と，予定条件６１３と、位置条件６１４とから成る。利用者の移動に対応する利用明細３１０（つまり、利用履歴）がこの条件部６１１で指定された条件（日時条件、予定条件、位置条件）を満たす場合に，判定装置２の判定プログラムは、その移動が業務目的の移動であると判定する。判定ルール610を日時条件、予定条件、及び位置条件によって構成することで、様々な状況における利用者の移動（休日や出勤日の移動、事前に入力した予定と異なる移動、予め指定した経路と異なる移動）を柔軟かつ正確に判定することができる。

次に、上述した判定ルール６１０の具体例について説明する。日時条件６１２は，例えば、「２０１７年４月１日から２０１８年３月３１日まで」のように特定の期間を指定するか，または，「平日かつ７時から２２時の間」のように曜日と時間帯を指定するものであり、前記移動履歴２１０の日時２１４が当該指定に合致するかを確認する条件である。予定条件６１３は，勤務予定を指定するものであり，図３に示される予定情報３００の予定３０２が出勤となっているかを確認する条件である。また、位置条件６１４は，図２に示される位置情報２２０が東京都２３区内などのあらかじめ決められたエリアにあるか，前記位置情報２２０が承認済行先リスト６２０の位置情報と一致するか，または，社内や契約したオフィスの入室情報を示す前記プレゼンス情報（例えば、図４の入日時３１６と出日時３１７から計算される滞在時間）があるか，または，予定情報のメタデータ３０６が後述するメタデータ配信サーバ７０６から取得したメタデータと一致するかを確認する条件のうちいずれかを含む。

図５（ｂ）は，本発明の実施例における判定ルール６１０に内在されている位置条件６１４の一部を構成する承認済行先リスト６２０の一例を示す図である。当該承認済行先リスト６２０は，承認済行先の名称６２１と，当該承認済行先の入出口を識別するゲートID６２２と，承認済行先の経度６２３及び緯度６２４から成る。この承認済行先リスト６２０は、業務利用とみなされる行先として予め登録された場所を示すリストである。判定装置２の判定プログラム２００は、後述する判定処理において、利用明細３１０に記録される利用者の行先をこの承認済行先リスト６２０に比較することで移動の目的を判定する。

次に、図６（ａ）〜図６（ｃ）を参照し、本発明の一実施例におけるアカウントおよび契約プランについて説明する。図６（ａ）は，課金管理装置１の課金管理データベース１５０に格納されるアカウント６３０の構成を示す図である。前記アカウント6３０は，本実施例における交通機関ごとの利用量の累計を示すものであり，交通種別６３１と累計利用量６３２から成る。また，図６（ｂ）は，本実施例におけるＭａａＳ事業者が提供し、課金管理データベース１５０に格納される契約プラン６４０の構成を示す図である。契約プラン６４０は，複数交通機関の利用量の加重和である一般化利用量に対して料金を設定したものであり，一般化利用量上限６４１と，料金６４２から成る。そして、図６（ｃ）は，前記一般化利用量を算出するための係数６５０であり，交通種別６５１と，係数６５２から成る。この係数６５２と、交通種別６５１で示される交通手段の累計利用量（例えば累計利用量６３２）とを乗算することで、契約企業の累計利用料に応じて料金６４２を計算することができる。

次に、図７を参照して、本発明の一実施例におけるシステム構成について説明する。図７は，本発明の実施の一実施例に係る課金管理装置７０１と、判定装置７０２と、社内スケジューラー７０３と、利用者携帯端末７０４と、社内入室管理サーバ７０５と、メタデータ配信サーバ７０６との間のデータのやり取りを示す図である。上述した判定プログラム２００は，企業の従業員である利用者のスケジュールや位置情報を利用するために，企業の外部者が参照できないようにすることが望ましい。従って、このためには，図７に示すように，課金管理プログラム１００をＭａａＳ事業者の課金管理装置７０１で稼働させ，判定プログラム２００は顧客企業の判定装置７０２で稼働させることが望ましい。ただし、本発明はこれに限定されず、課金管理プログラム１００と，判定プログラム２００は，同一の計算機上で稼働させてもよい。

課金管理装置７０１は，顧客企業との契約に基づいて，顧客企業の従業員が持つ携帯端末（例えば、図１の利用者携帯端末４や図7の利用者携帯端末704）で稼働する利用者アプリケーション４００に電子チケットを送信する。そして、課金管理装置701は、当該チケットを用いた交通機関利用履歴や位置情報を前記利用者アプリケーションから収集して、利用明細３１０を作成し，従業員のユーザＩＤと利用明細３１０を判定装置７０２へと送信する。そして、判定装置７０２は，当該ユーザＩＤと前記利用明細３１０に含まれる日時によって，従業員の予定を管理する社内スケジューラー７０３から、該当する従業員の予定を取得し，従業員のオフィス入退室情報を管理する社内入退室管理サーバ７０５から，該当する従業員の入退室履歴（すなわち、プレゼンス情報）を取得する。

また，判定装置７０２は、社外のメタデータ配信サーバに対して，前記利用明細３１０に含まれる場所コード３１８をキーとして問い合わせを発行し，その場所に関するメタデータを得る。例えば，場所コードは，あるイベントの会場のBluetooth（登録商標）通信で発行されるucodeであってもよい。メタデータ配信サーバ７０６に対して，この場所コードで問い合わせを発行することで，その場所の緯度・経度などの位置情報や，イベントの情報，イベントのＵＲＬを取得することができる。

図７に示されるようなシステム構成を用いることで、ＭａａＳ事業者のサービスと契約企業の業務管理システムを連携させることができ、移動を管理する企業や利用者の負担が大幅に削減され、交通利用に対する請求・手当を従来より簡単に運営することが可能となる。

なお、ここでは、課金管理装置７０１から電子チケットを受信した利用者端末で稼働する利用者アプリケーション４００から利用履歴や位置情報を取得する態様について説明したが、本発明はこれに限定されない。例えば、利用者端末７０４が利用者アプリケーションを有さない態様も可能である。この場合には、利用者の移動履歴が、利用者が移動する時に利用する交通会社（例示せず）によって取得され、直接に課金管理装置７０１に送信される（つまり、利用履歴等のデータやり取りを交通会社とMaas事業者の間で行う。これにより、契約企業や利用者の、移動を管理する負担を更に削減することができる。

次に，図８を参照して、本発明の一実施例における利用者アプリケーション画面について説明する。図８は、本発明の実施例における利用者アプリケーション４００の移動履歴画面８００を示す図である。移動履歴画面８００は、前記利用者アプリケーション４００の利用者が，図２（ａ）に示す移動履歴２１０，および図２（ｂ）に示す位置情報２２０を確認するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）である。利用者が，当該移動履歴画面８００の移動履歴表示エリア８１０に表示された移動履歴２１０，および，位置情報２２０を確認し，登録ボタン８３０を押下することで，前記利用者アプリケーション４００は、当該移動履歴２１０および位置情報２２０を課金管理プログラム１００へと送信する。この処理は，利用者が手動で送信するようにしてもよいし，毎日定刻に自動で送信するようにしてもよい。

また、利用者の個人的事由による立ち寄り先がある場合には，利用者が、移動履歴表示エリア８１０の該当する立ち寄り先を選択して，プライベート設定ボタン８２０を押下することで，利用者アプリケーション４００は当該立ち寄り先に関する情報を削除した移動履歴２１０および位置情報２２０を送信することも可能である。

次に、図９を参照して、本発明の一実施例における判定フローの全体について説明する。図９は、判定装置２によって実行される判定プログラム２００の判定部１０６の判定処理の概要を示す図である。まず、判定プログラム２００のスケジュール取得部１０３は、課金管理装置１の課金管理データベース１５０から、未判定の利用明細３１０を取得する。そして、スケジュール取得部１０３は、各利用明細からユーザＩＤと利用日時を取り出し（Ｓ１０１），利用日時から行先滞在時間を特定し，当該滞在時間に該当する予定の情報を取得する（Ｓ１０２）。次に，プレゼンス取得部１０４は，当該滞在時間のプレゼンス情報を取得する（Ｓ１０３）。

続いて，メタデータ取得部１０５は，当該滞在時間に取得した場所コード３１８をキーとしてメタデータ配信サーバへ検索リスクエストを発行して，メタデータとして行先の場所やイベントのＵＲＬを取得する（Ｓ１０４）。そして，判定部１０６は，これらの情報を，判定ルール６１０に照らし合わせて，利用明細中の移動が業務目的であるか否かを判定する（Ｓ１０５）。この判定処理については，図１０を用いて後述する。ここで，判定部１０６は，判定の結果が業務利用であれば，当該明細に承認フラグを追加する（Ｓ１０７）。Ｓ１０７において，判定の結果が業務利用でない場合には、判定プログラム２００が当該利用明細を例えば、管理者携帯端末５の管理者アプリケーション５００へと送付する（Ｓ１０８）。そして、管理者アプリケーション５００を利用する管理者が、この利用明細に記録されている移動が業務利用と認めた場合には，当該明細に承認フラグを追加する（Ｓ１０７）。

次に、図１０を参照して、本発明の一実施例における判定フローの詳細について説明する。図１０は、判定部１０６の判定処理の詳細を示す図である。まず、上述した判定装置2で稼働する判定プログラム２００の判定部１０６は，処理対象の利用明細の日時（例えば、図４の利用明細３１０に示される入日時３１６及び出日時３１７）が，取得した予定情報（例えば、図３の予定情報３００）において出勤日に該当するかを確認する（Ｓ２０１）。取得した予定情報において、利用明細の日時が休日として指定されている場合には、この利用明細に記録されている移動が業務利用ではないと判定される（Ｓ２０７）。次に，判定部１０６は，処理対象の利用明細の日時が判定ルール６１０の日時条件に合致しているか確認する（Ｓ２０２）。利用明細の日時が判定ルール６１０の日時条件に合致していない場合には、利用明細に記録されている移動が業務利用ではないと判定される（Ｓ２０７）。

続いて，判定プログラム２００のプレゼンス取得部１０４は、当該利用明細の行先滞在時間帯におけるプレゼンス情報を企業の入退室管理サーバ（例えば、図７の社内入退室管理サーバ７０５）から取得する（Ｓ２０３）。判定ルール６１０に指定されている場所及び時間帯に該当するプレゼンス情報がある場合，この利用明細に記録されている移動が業務目的として判定される（Ｓ２０６）。Ｓ２０３では、判定ルール６１０に指定されている場所及び時間帯に該当するプレゼンス情報がない場合には、当該利用明細の位置情報（例えば、図４に示される位置情報３１２）が，承認済行先リスト（例えば、図５に示される承認済行先リスト６２０）における位置情報と一致していれば（Ｓ２０４），この利用明細に記録されている移動が業務目的と判定される（Ｓ２０６）。

Ｓ２０４では、利用明細の位置情報が承認済行先リストにおける位置情報に一致しなかった場合，判定部１０６は、前記予定情報に含まれる行先メタデータのＵＲＬと、行先の場所コードをキーとしてメタデータ配信サーバ（例えば、図７に示されるメタデータ配信サーバ７０６）から取得したＵＲＬとを比較する。予定情報に含まれる行先メタデータのＵＲＬとメタデータ配信サーバから取得したＵＲＬとが一致すれば（Ｓ２０５），利用明細に記録されている移動が業務目的と判定され（Ｓ２０６），一致しなかった場合には，業務目的ではないと判定される（Ｓ２０７）。
なお、図２（ｂ）に示されるWi-FiステーションID２２５が本判定処理に用いられていてもよい。例えば、Wi-FiステーションID２２５の情報がある場合には、判定部１０６は、このWi-FiステーションID２２５が社内のWi-FiステーションID、又は、承認済行先リストに登録されている行先リストのWi-FiステーションIDに一致するか否かを判定する。利用者端末４が接続されているWi-FiステーションのWi-FiステーションID２２５が社内又は承認済行先リストのWi-FiステーションIDに一致する場合、利用明細に記録されている移動が業務目的と判定され，一致しなかった場合には，業務目的ではないと判定される。
このように判定処理を行うことで、移動を管理する企業や利用者の負担が大幅に削減され、交通利用に対する請求・手当を従来より簡単に運営することが可能となる。

次に、図１１を参照して、本発明の一実施例における承認済行先リストの追加フローについて説明する。図１１は、判定部１０６の判定結果に基づく，承認済行先リスト追加処理を示す図である。判定プログラム２００の判定部１０６は，管理者アプリケーション５００から返送された利用明細（例えば、図９に示されるS１０７で返送された利用明細）を受信し（Ｓ３０１），判定装置２の判定データベース２５０に記録する（Ｓ３０２）。ここで，当該利用明細が，管理者によって業務目的と判定されているか確認する（Ｓ３０３）。当該利用明細に記録されている移動が業務目的と判定されている場合には，判定プログラム２００は当該利用明細中の行先情報を承認済行先リスト６２０に追加する（Ｓ３０４）。

本実施例によると，判定プログラム２００は，管理者により業務目的と判定された行先と，その行先に該当する位置を記録し，承認済行先として利用する。これにより、利用者がこの行先を，利用明細において行先として指定した場合に，一度承認された行先であることから，この行先が業務目的の行先であると判断することができる。

次に、図１２を参照して、本発明に係る実施例２について説明する。上述した実施例１では、利用者の予定情報（例えば図３で示される予定情報３００）は事前に入力され、利用者に変更不可能な形でスケジュール管理サーバ（例えば、図１２の社内スケジューラー７０３）に格納されたが、実施例２では、スケジュール管理サーバに格納される予定情報は利用者の遠隔操作により、リアルタイムで更新されてもよい。これにより、利用者の予定が変更された場合、利用者がスケジュール管理サーバに格納される予定情報を更新することで、移動目的の判定精度を向上させる効果が得られる。
なお、実施例２は、スケジュール管理サーバに格納される予定情報が利用者の遠隔操作によりリアルタイムで更新される点以外では、実施例１と同様であるため、上述した要素の説明はここで繰り返さない。

具体的には、図１２に示すように、利用者端末７０４は直接に社内スケジューラー７０３に通信可能に接続される。利用者の入力により、利用者端末７０４で稼働する利用者アプリケーションは、利用者を識別するユーザＩＤと、予定をどのように更新したいかを指定する更新指示とを含む予定更新要求を社内スケジューラー７０３に送信する。当該予定更新要求を受信した社内スケジューラー７０３は、ユーザＩＤを用いて、利用者に該当する予定情報を読み出し、予定更新要求の更新指示に基づいて、利用者の予定情報を更新し、更新した予定情報を保存する。

なお、社内スケジューラー７０３は、更新した予定情報に「未確認」のフラグを付し、管理者アプリケーション（例えば図１の管理者端末で稼働する管理者アプリケーション５００）に通知を送信してもよい。利用者の予定更新が管理者に認められた場合、この更新した予定情報は上述した移動目的判定処理に用いられてもよい。一方で、利用者の予定更新が管理者に認められなかった場合、更新前の予定情報は上述した移動目的判定処理に用いられる。

このように、社内スケジューラー７０３に格納される利用者の予定情報をリアルタイムで利用者の遠隔操作により更新できるようにすることで、判定処理の判定ミスを抑えることができ、より正確に利用者の移動目的を判定することができる。例えば、本来、外出中のユーザは、打ち合わせ相手や交通機関等の都合により、移動の経路や日時が社内スケジューラーで事前に入力した予定から逸脱した場合には、この移動が業務目的ではないと判定されてしまうことがある。
ただし、本実施例で上述したように、利用者が外出中でも、移動の経路や日時の変更に合わせて利用者アプリケーションで社内スケジューラー７０３に格納される利用者の予定情報をリアルタイムで更新できるため、最新の予定情報を移動目的の判定処理に用いることができ、移動目的の判定精度を向上させる効果が得られる。

以上、本発明のいくつかの実施例を説明してきたが、これらは、本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施する事が可能である。

１ 課金管理装置
２ 判定装置
４ 利用者携帯端末
５ 管理者携帯端末
１００ 課金管理プログラム
１０６ 判定部
２００ 判定プログラム
３１０ 利用明細
４００ 利用者アプリケーション
５００ 管理者アプリケーション
６１０ 判定ルール

Claims (15)

1. 課金管理装置と、判定装置と、スケジュール管理サーバとがネットワークを介して接続された移動目的判定装置を用いる移動目的判定方法であって、
   前記移動目的判定装置は、履歴取得部と、スケジュール取得部と、判定部と、判定ルールデータベースとを有し、
   前記履歴取得部が、前記課金管理装置から交通機関の利用記録を示す利用日時，位置情報，利用者識別情報を含む利用履歴を取得する工程と，
   前記スケジュール取得部が、前記利用者識別情報と前記利用日時に基づいて，前記スケジュール管理サーバから利用者のスケジュールを取得する工程と，
   前記判定部が、前記判定ルールデータベースに格納される判定ルールに基づいて，前記利用履歴と，前記利用者の予定から移動の目的が業務利用であるか否かを判定する移動目的判定工程と、
   を含む移動目的判定方法。
2. 前記判定ルールは条件部を有し，
   前記条件部は、
   業務利用とみなす日付，曜日，時間帯，または，期間を指定する日時条件と，
   業務利用とみなす予定情報を指定する予定条件と，
   業務利用とみなす位置情報，または，業務利用とみなす入室情報，または，接続情報を指定する位置条件と、
   を含むものである請求項１に記載の移動目的判定方法。
3. 前記移動目的判定工程は、
   前記利用履歴及び前記利用者の予定を前記判定ルールの前記条件部に比較し、
   前記利用者の予定が前記条件部の予定条件を満たし、
   かつ前記利用履歴が前記条件部の前記日時条件及び前記位置条件を満たす場合に、
   前記利用履歴が業務目的であると判定し、
   前記利用者の予定が前記条件部の予定条件を満たさない場合、
   あるいは、前記利用履歴が前記条件部の前記日時条件または前記位置条件のいずれかを満たさない場合には、前記利用履歴が業務目的ではないと判定する、
   ことを含む請求項２に記載の移動目的判定方法。
4. 前記判定ルールは，行先名称と行先位置情報とからなる承認済行先リストを含み，
   前記移動目的判定工程は、
   前記利用履歴の前記位置情報と、前記承認済行先リストにおける前記行先位置情報を比較し，
   前記位置情報が少なくとも一つの前記行先位置情報と一致する場合に，前記利用履歴が業務目的であると判定する、
   ことを含む請求項１に記載の移動目的判定方法。
5. 前記移動目的判定工程において，
   前記利用履歴が業務目的ではないと判定した場合に、
   前記利用履歴を管理者が利用する管理者アプリケーションへと送信する承認要求工程と、
   前記管理者により業務目的と判定された新たな行先及び新たな位置情報を含む判定結果を受信する判定結果受信工程と、
   前記新たな行先及び前記新たな位置情報を承認済行先リストへ追加する承認済行先リスト更新工程と、
   を更に含む請求項３に記載の移動目的判定方法。
6. 課金管理装置と、スケジュール管理サーバとネットワークを介して接続された移動目的判定装置であって、
   前記移動目的判定装置は、
   交通機関の利用記録を示す利用日時，位置情報，利用者識別情報を含む利用履歴を前記課金管理装置から取得する履歴取得部と、
   前記利用履歴の前記利用者識別情報と前記利用日時に基づいて，利用者の予定を前記スケジュール管理サーバから取得するスケジュール取得部と，
   判定ルールを格納する判定ルールデータベースと、
   前記判定ルールデータベースに格納される判定ルールに基づいて，前記利用履歴と，前記利用者の予定から移動の目的が業務利用であるか否かを判定する判定部と、
   を含む移動目的判定装置。
7. 前記判定ルールは条件部を有し，
   前記条件部は、
   業務利用とみなす日付，曜日，時間帯，または，期間を指定する日時条件と，
   業務利用とみなす予定情報を指定する予定条件と，
   業務利用とみなす位置情報，または，業務利用とみなす入室情報，または，接続情報を指定する位置条件と、
   を含むものである請求項６に記載の移動目的判定装置。
8. 前記判定部は、
   前記利用履歴及び前記利用者の予定を前記判定ルールの前記条件部に比較し、
   前記利用者の予定が前記条件部の予定条件を満たし、
   かつ前記利用履歴が前記条件部の前記日時条件及び前記位置条件を満たす場合に、
   前記利用履歴が業務目的であると判定し、
   前記利用者の予定が前記条件部の予定条件を満たさない場合、
   あるいは、前記利用履歴が前記条件部の前記日時条件または前記位置条件のいずれかを満たさない場合には、前記利用履歴が業務目的ではないと判定する、
   ものである請求項７に記載の移動目的判定装置。
9. 前記判定ルールは，行先名称と行先位置情報とからなる承認済行先リストを含み、
   前記判定部は、
   前記利用履歴の前記位置情報と、前記承認済行先リストにおける前記行先位置情報を比較し，
   前記位置情報が少なくとも一つの前記行先位置情報と一致する場合に，前記利用履歴が業務目的であると判定する、
   ものである請求項６に記載の移動目的判定装置。
10. 前記判定部は、
    前記利用履歴が業務目的ではないと判定した場合に、
    前記利用履歴を管理者が利用する管理者アプリケーションへと送信し、
    前記管理者により業務目的と判定された新たな行先及び新たな位置情報を含む判定結果を受信し、
    前記新たな行先及び前記新たな位置情報を承認済行先リストへ追加する、
    ことを特徴とする請求項８に記載の移動目的判定装置。
11. 利用者端末と、課金管理装置と、判定装置と、スケジュール管理サーバとがネットワークを介して接続された移動目的判定システムであって，
    前記判定装置は、判定部と、判定ルールデータベースとを具備し、
    前記課金管理装置は、
    前記利用者端末から、交通機関の利用記録を示す利用日時，位置情報，利用者識別情報を含む利用履歴を取得し，前記利用履歴を前記判定装置に送信し、
    前記判定装置は、
    前記利用履歴を前記課金管理装置から受信し、
    前記利用履歴の前記利用者識別情報と前記利用日時に基づいて，利用者の予定を前記スケジュール管理サーバから取得し，
    前記判定ルールデータベースに格納される判定ルールに基づいて，前記利用履歴と，前記利用者の予定から移動の目的が業務利用であるか否かを判定部によって判定する、
    ことを特徴とする移動目的判定システム。
12. 前記判定ルールは条件部を有し，
    前記条件部は、
    業務利用とみなす日付，曜日，時間帯，または，期間を指定する日時条件と，
    業務利用とみなす予定情報を指定する予定条件と，
    業務利用とみなす位置情報，または，業務利用とみなす入室情報，または，接続情報を指定する位置条件と、
    を含むものである請求項１１に記載の移動目的判定システム。
13. 前記判定装置は、
    前記利用履歴及び前記利用者の予定を前記判定ルールの前記条件部に比較し、
    前記利用者の予定が前記条件部の予定条件を満たし、
    かつ前記利用履歴が前記条件部の前記日時条件及び前記位置条件を満たす場合に、
    前記利用履歴が業務目的であると判定し、
    前記利用者の予定が前記条件部の予定条件を満たさない場合、
    あるいは、前記利用履歴が前記条件部の前記日時条件または前記位置条件のいずれかを満たさない場合には、前記利用履歴が業務目的ではないと判定する、
    ものである請求項１２に記載の移動目的判定システム。
14. 前記判定ルールは，行先名称と行先位置情報とからなる承認済行先リストを含み，
    前記判定装置は、
    前記利用履歴の前記位置情報と、前記承認済行先リストにおける前記行先位置情報を比較し，
    前記位置情報が少なくとも一つの前記行先位置情報と一致する場合に，前記利用履歴が業務目的であると判定する、
    ものである請求項１１に記載の移動目的判定システム。
15. 前記利用者携帯端末と、管理者携帯端末と、前記課金管理装置と、前記判定装置と、前記スケジュール管理サーバとがネットワークを介して接続された移動目的判定システムであって、
    前記判定装置は判定部と、判定ルールを格納する前記判定ルールデータベースとを具備し、
    前記判定ルールは、条件部を有し，
    前記条件部は、
    業務利用とみなす日付，曜日，時間帯，または，期間を指定する日時条件と，
    業務利用とみなす予定情報を指定する予定条件と，
    業務利用とみなす位置情報，または，業務利用とみなす入室情報，または，接続情報を指定する位置条件とを含み、
    前記課金管理装置は、
    前記利用者端末から、交通機関の利用記録を示す前記利用日時，前記位置情報，前記利用者識別情報を含む前記利用履歴を取得し，
    前記利用履歴に基づいて、利用明細を作成し、前記利用明細を前記判定装置に送信し、
    前記判定装置は、
    前記利用明細を前記課金管理装置から受信し、
    前記利用明細の前記利用者識別情報と前記利用日時に基づいて，前記利用者の予定を前記スケジュール管理サーバから取得し，
    前記判定部は、
    前記利用明細及び前記利用者の予定を前記判定ルールの前記条件部に比較し、
    前記利用者の予定が前記条件部の予定条件を満たし、
    かつ前記利用明細が前記条件部の前記日時条件及び前記位置条件を満たす場合に、
    前記利用明細が業務目的であると判定し、
    前記利用者の予定が前記条件部の予定条件を満たさない場合、
    あるいは、前記利用明細が前記条件部の前記日時条件または前記位置条件のいずれかを満たさない場合には、前記利用明細が業務目的ではないと判定する、
    ことを特徴とする請求項１１に記載の移動目的判定システム。

Images