説明

携帯端末及び携帯端末制御方法

【課題】電子マネー機能と経路誘導機能を備えた携帯端末おいて、経路誘導を行いながら、電子マネーの残金管理を行うことができる携帯端末を提供する。
【解決手段】目的地まで移動する経路を探索する目的地探索手段と、電子マネーを使用可能とする電子マネー処理手段とを備える携帯端末であって、目的地探索手段により探索した目的地において所定の目的を達成するために必要な必要費用を算出する費用算出手段と、電子マネーの残金を管理する残金管理手段と、必要費用と電子マネーの残金との比較結果を報知する報知手段とを備える。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電子マネー機能と経路誘導機能を備えた携帯端末に関わり、特に経路誘導を行いながら、電子マネーの残金管理を行う携帯端末及び携帯端末制御方法に関する。
【背景技術】
【0002】
携帯電話機は普段から持ち歩くと言う観点から非接触ICカードを用いた電子マネー機能を備え、料金等の支払い時に携帯電話機を読み取り装置に近づけるだけで支払い処理を行うことができるものがある。また、キャッシュレスによる支払い機能に加え、クレジットカード、商店の会員証やポイントカード等の一体化を図った携帯電話機も知られている。また、交通機関への乗降をキャッシュレスにするために、自動改札口においてカードを接触させるだけで通過することができるICカード等も利用されている。
【0003】
一方、携帯電話機や携帯情報端末(PDA)には 目的地までの経路を画面に表示しながらユーザを目的地まで誘導するナビゲーション機能を有しているものがあり、歩いている位置を端末画面上にリアルタイムで表示し、経路を音声等で知らせることにより、目的地までの経路を誘導するものがある。また、車載用のカーナビゲーション装置と自動料金徴収システム(ETC)を連動させて、ICカードの残金に見合った経路を探索する装置も提案されている(例えば、特許文献1参照)。これは目的地までの最適経路検索時に車載装置に挿入されているICカードから残金情報を取り出し、最適経路中の有料道路の利用料金と比較して、残金が少ないときはICカードへの入金を促す案内を行うものである。また、ICカードに対する入金が設定された場合は入金可能施設へ案内を行い、入金設定されなかったときには残金の範囲内において利用可能な有料道路を含む最適経路検索を行うこともできる。
【特許文献1】特開2001−074484号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
ところで、近年の携帯端末は、多機能化してきているため、今後経路誘導(ナビゲーション)機能と電子マネー機能とが搭載された機種が出てくることが考えられるが、従来の経路誘導機能は、目的地までの移動経路を誘導するものであり、また従来の電子マネー機能は、支払い時においてキャッシュレスを実現するのみのものである。これらの2つの機能は、それぞれ独立して機能するものであるため、目的地において所定の目的を達成するために必要な必要費用の決済を経路誘導に関連させて行うことができず使い勝手が悪いという問題がある。
【0005】
また、特許文献1に記載の技術は、車載用という観点からICカードに記録された残金に見合った経路を探索するものであるが、歩行者が移動する場合のように、近くの公共交通機関を利用する場合は、残金が不足しているから次の乗換駅まで歩くというのは現実的では無く、電子マネーの残金を適切に管理する必要がある。また、電子マネーは交通機関だけでなく、店舗での商品購入にも利用できるため、途中で商品購入などに伴う決済処理を考慮すると目的地までの移動に必要な残金管理のみでは最適な経路誘導と電子マネー決済の処理を行うことが困難であるという問題もある。
【0006】
本発明は、このような事情に鑑みてなされたもので、電子マネー機能と経路誘導機能を備えた携帯端末おいて、経路誘導を行いながら、電子マネーの残金管理を行うことができる携帯端末及び経路誘導方法を提供することを目的とする。
【課題を解決するための手段】
【0007】
本発明は、目的地まで移動する経路を探索する目的地探索手段と、電子マネーを使用可能とする電子マネー処理手段とを備える携帯端末であって、前記目的地探索手段により探索した目的地において所定の目的を達成するために必要な必要費用を算出する費用算出手段と、前記電子マネーの残金を管理する残金管理手段と、前記必要費用と前記電子マネーの残金との比較結果を報知する報知手段とを備えたことを特徴とする。
【0008】
本発明は、前記残金管理手段は、電子マネーによる支払い処理が生じる場合に、前記目的地までの移動に必要な必要費用が残金として残るように電子マネーの残金を管理することを特徴とする。
【0009】
本発明は、前記目的地探索手段により探索した移動経路に基づいて、前記目的地までの移動経路を誘導する経路誘導手段と、前記移動経路に基づく誘導時に、前記所定の時刻に前記目的を達成できるように移動の時間管理を行う時間管理手段とをさらに備えたことを特徴とする。
【0010】
本発明は、目的地まで移動する経路を探索する目的地探索手段と、電子マネーを使用可能とする電子マネー処理手段とを備える携帯端末における制御方法であって、前記目的地探索手段により探索した目的地において所定の目的を達成するために必要な必要費用を算出する費用算出ステップと、前記電子マネーの残金を管理する残金管理ステップと、前記必要費用と前記電子マネーの残金との比較結果を報知する報知ステップとを有することを特徴とする。
【0011】
本発明は、前記残金管理ステップは、電子マネーによる支払い処理が生じる場合に、前記目的地までの移動に必要な必要費用が残金として残るように電子マネーの残金を管理することを特徴とする。
【0012】
本発明は、前記目的地探索手段により探索した移動経路に基づいて、前記目的地までの移動経路を誘導する経路誘導ステップと、前記移動経路に基づく誘導時に、前記所定の時刻に目的を達成できるように移動の時間管理を行う時間管理ステップとをさらに備えたことを特徴とする。
【発明の効果】
【0013】
本発明によれば、電子マネー機能と経路誘導機能を備えた携帯端末おいて、経路誘導を行いながら、適切な電子マネーの残金管理を行うことができるという効果が得られる。
【発明を実施するための最良の形態】
【0014】
<第1の実施形態>
以下、本発明の一実施形態による携帯端末を図面を参照して説明する。図1は同実施形態の構成を示すブロック図である。この図において、符号1は、移動通信システムを利用する携帯端末である。符号2は、携帯端末1との間で無線通信回線を確立する基地局である。符号3は、複数の基地局2が接続されるネットワークである。符号4は、コンサートや映画のチケット予約の手続きや予約完了後にチケットデータや会場位置情報、日時情報を携帯端末1に対して送ると共に指定された口座等からチケット料金を引き落とすなどの処理を行うチケット管理サーバであり、ネットワーク3に接続されている。符号5は、要求に応じて指定の地図情報を送り出したり、目的地までの誘導経路情報などの情報を送り出すナビゲーションデータベースサーバであり、ネットワーク3に接続されている。符号6は、レストランなどの概算料金情報を含む諸情報を送り出すと共に、必要に応じて指定された口座等からレストラン利用料金等を引き落とすなどの処理を行うレストランデータベースサーバであり、ネットワーク3に接続されている。符号7は、電子マネーの決済に関わる管理を行う電子マネー管理サーバであり、ネットワーク3に接続されている。
【0015】
符号11は、基地局2との間に確立された無線通信回線を使用して音声又はデータの送受信をする送受信部である。符号12はGPS(Global Positioning System)等を利用して携帯端末1の位置を測定する位置測定部である。符号13は、ダイヤルキーやファンクションキーを配列したキーパネル等から構成し、データ入力等に用いられる操作部である。符号14は、液晶のディスプレイ装置等から構成する表示部である。符号15は、電子マネーに関わる処理を実行する電子マネー部である。符号16は、携帯端末1の処理動作を制御するCPUである。符号17は、携帯端末1の動作させるためのプログラム等が予め記憶されたROMである。符号18は、演算処理結果等を記憶するRAMである。符号19aは基地局2から送られてきた地図データを格納するメモリ、19bは目的地データに基づいた誘導経路情報を格納するメモリ、19cはチケット等の事前に予約したチケットデータや会場の位置、日時等の情報を格納するメモリ、19dはレストラン予約にかかわる概算料金等の情報を格納するメモリ、19eは電子マネーの情報を格納するメモリである。
【0016】
なお、電子マネー管理サーバ7と電子マネー部15の情報の授受は、電子マネー部15には特定番号等のみを収納しておき、実質的な演算処理や管理処理は電子マネー管理サーバ7に依存する方法と、電子マネー部15において演算処理や残金の管理処理まで行い実質的な支払い業務を電子マネー管理サーバ7に依存する方法とが適用可能ある。全ての演算処理や管理処理を電子マネー管理サーバ7で行う方法は、携帯端末1側のCPU16の負荷を軽減することができるが、残金情報を知るだけでも基地局2を介して、電子マネー管理サーバ7に接続して通信を行う必要がある。一方、電子マネー部15において処理する方法は、携帯端末1内に処理に必要な情報を保持してるため、電子マネー管理サーバ7と通信する頻度を下げることができるが、携帯端末1側のCPU16の負荷が高くなる。したがって、いずれの方法を適用するかは、電子マネー管理サーバ7や携帯端末1の能力に応じて、適宜選択してシステム構築を行えばよい。ここでは、説明を簡単にするために、電子マネー部15において演算処理や残金の管理処理まで行い実質的な支払い業務を電子マネー管理サーバ7に依存する方法を適用するものとして説明する。
【0017】
次に、図2〜図4を参照して、電子マネーの残金管理を行いながら目的地までの経路誘導を行う動作を説明する。まず、ユーザは、携帯端末1の操作部13を操作して、経路誘導(ナビゲーション機能)のアプリケーションを起動する。そして、ユーザが操作部13から自分の行くべき目的地を設定して入力する。ここでいう目的地とは、買い物目的であれば買い物をする百貨店、駅での待ち合わせであれば待ち合わせ場所の駅である。また、ユーザは、目的地において目的を達成するために必要な予算額を必要に応じて入力する。例えば、買い物が目的であれば、目的地における買い物の予算額を予め入力しておく。また、目的地における所定の目的を達成するために必要な費用には、目的地までの交通費を含むことができる。
なお、目的地は、経由地として複数設定してもよく、例えば、自宅を出発地として、第1の目的地(経由地)、第2の目的地(経由地)を順に設定し、最終的な目的地として自宅を設定するようにしてもよい。
【0018】
次に、目的地が入力されると、CPU16は、位置測定部12において取得した現在位置情報と入力された目的地の情報を、送受信部11を介してナビゲーションデータベースサーバ5に対して送信する(ステップS1)。このとき、ユーザが、通勤や通学のために既に所有している定期乗車券があれば、この定期乗車券の区間情報も合わせて入力するとともに、検索時に時刻を優先するか、料金を優先するか等の検索条件を入力する。ナビゲーションデータベースサーバ5は、この現在位置情報、目的地情報及び定期乗車券の区間情報とに基づいて、検索条件を満たすように誘導経路を検索して、移動に必要な交通費を算出する。またこのときナビゲーションデータベースサーバ5は、現在位置情報と目的地情報に基づいて検索された最適経路中に定期乗車券の区間が存在しているかを判定し、存在していれば、交通費の再計算を行い正確な交通費を算出する。そして、ナビゲーションデータベースサーバ5は、検索の結果得られた誘導経路情報と交通費情報とを携帯端末1へ送信する。この誘導経路情報と交通費情報を送受信部11を介して受信したCPU16は、受信したこれらの情報を表示部14へ表示する(ステップS2)。
【0019】
次に、ユーザは、交通費を片道のみ管理するか往復で管理するかを操作部13から選択して入力する。ここで、CPU16は、片道設定であるか否かを判定し(ステップS3)、往復設定が選択されると、交通費を2倍の額にして(ステップS4)、現在の位置情報とともにメモリ19bに記憶する(ステップS5)。続いて、CPU16は、メモリ19eに記憶されている電子マネーの残金額(以下、残金と称する)を読み出し、交通費が残金より小さい値であるか(残金は足りているか)否かを判定する(ステップS6)。この判定の結果、残金が足りない場合に、CPU16は、画面表示、発音、発光、振動発生などを用いて、残金が足りないことを示す報知(警告)を発して(ステップS7)、電子マネーの入金モードへ移行する。ここで、ユーザは必要に応じて電子マネーの入金を行う。そして、CPU16は、メモリ19eの入金状態を確認することにより、入金済みであるか否かを判定し(ステップS8)、入金があった場合、ステップS6へ移行する。
【0020】
一方、入金されなかった場合は交通費の最低料金より残金が多いか否かを判定する(ステップS9)。ここでいう交通費の最低料金とは、直近の交通機関の入出場、乗車に対して支障無く利用できる最低金額を示しており、例えば、初乗り運賃額等のことである。この判定の結果、残金が直近の交通機関の支払いに支障が生じない金額が残っていない(初乗り運賃の支払いが可能な金額残っていない)場合は、スキップモードへ移行する。ここでいうスキップモードとは入金するための設備がない等の場合を考慮したモードである。ここでスキップを拒否すると、CPU16は、残金が足りないことを示す報知(警告)を発して(ステップS7)、入金されるまで待機する。一方、スキップする設定がなされた場合、スキップモードに移行したことをメモリ19bに記憶する(ステップS10)。そして、CPU16は、誘導経路情報に基づいて、歩行経路や交通機関の乗り換えを含む目的地までの移動経路を表示部14に表示しながらユーザを目的地まで誘導する(ステップS11)。図10(a)に歩行時のナビ画面の一例、図10(b)に交通機関利用時のナビ画面の一例を示す。
【0021】
次に、CPU16は、目的地において、買い物の決済が無いかを判定し(ステップS12)、買い物の決済が発生する場合は、直近の交通機関の支払いに支障の無い金額と買い物の予算額を合計した値が残金より小さいか否かを判定する(ステップS13)。この判定の結果、残金の方が多い場合、CPU16は、電子マネー部15に対して、買い物の決済を行う指示を出す。これを受けて、電子マネー部15は、支払い処理を実行して、メモリ19eに記憶されている残金を更新して(ステップS14)、経路誘導を続行する(ステップS11)。
【0022】
一方、支払い金額が不足する場合は、残金が不足していることを示す報知(警告)を発する(ステップS15)。そして、操作部13から電子マネーによる支払い指示の操作が行われたか否かに基づいてCPU16は電子マネーを使用するか否かを判定し(ステップS16)、電子マネーによる支払いをせずに、現金等で支払いを済ませる場合は、電子マネーによる支払いを中止して(ステップS17)、経路誘導を続行する(ステップS11)。電子マネーによる支払いの指示が行われた場合、CPU16は、表示部14に入金を催促するメッセージを表示する。この表示を見て、ユーザが電子マネーの入金を行うことにより、メモリ19eに記憶されている残金が更新される(ステップS18)。入金が確認されると、CPU16は、直近の交通機関の支払いに支障の無い金額と買い物金額が不足していないかを再度判定し(ステップS19)、未だ残金が不足している場合は、再度報知(警告)を発する(ステップS15)。
【0023】
一方、残金が支払い可能な金額になった場合、CPU16は、電子マネー部15に対して、買い物の決済を行う指示を出す。これを受けて、電子マネー部15は、支払い処理を実行して、メモリ19eに記憶されている残金を更新する(ステップS20)。また、CPU16は、メモリ19bにスキップモードへ移行したことを示す情報が記憶されている場合はこの情報を抹消して(ステップS21)、経路誘導を続行する(ステップS11)。
【0024】
次に、ステップS12において、買い物が無いと判定された場合、CPU16は、位置測定部12により出力される自端末の位置情報に基づいて、交通費決済を行うべき位置に到達している否かを判定する(ステップS22)。この判定の結果、交通費決済位置に到達していない場合は、ステップS6へ移行する。一方、交通費決済を行うべき位置に到達している場合、CPU16はスキップモードであるか否かを判定し(ステップS23)、スキップモードである場合は残金が少なく支払いができないため、報知(警告)を発して(ステップS24)入金を催促する。ここで、ユーザが電子マネーの入金を行うことにより、メモリ19eに記憶されている残金が更新される(ステップS25)。そして、CPU16は、残金が直近の交通費決済に支障が無い金額になったか否かを判定し(ステップS26)、未だ不足している場合は再度報知(警告)を発する(ステップS24)。直近の交通費決済に支障のない金額が入金された場合、CPU16は、電子マネー部15に対して、買い物の決済を行う指示を出す。これを受けて、電子マネー部15は、支払い処理を実行して、メモリ19eに記憶されている残金を更新する(ステップS27)。
【0025】
次に、CPU16は、交通費の決済位置が目的地に対して最終支払い位置であるか否かを判定し(ステップS28)、最終支払い位置でない場合はステップS6へ移行する。一方、最終支払い位置である場合、CPU16は、メモリ19bを参照して、目的地を設定したときに片道設定を選択したか否かを判定する(ステップS29)。この判定の結果、片道設定が選択されている場合は、電子マネー部15に対して残金管理の終了を指示し(ステップS30)、目的地に到達するまで誘導を行う(ステップS31、S32)。一方、往復設定が選択されている場合、CPU16は、目的地に到達するまで誘導を行い(ステップS33、S34)、目的地に到達した時点で、経路誘導処理を終了する(ステップS35)。
【0026】
次に、CPU16は、買い物の決済が無いかを判定し(ステップS36)、買い物の決済が発生する場合は、直近の交通機関の支払いに支障の無い金額と買い物の予算額を合計した値が残金より小さいか否かを判定する(ステップS37)。この判定の結果、残金の方が多い場合、CPU16は、電子マネー部15に対して、買い物の決済を行う指示を出す。これを受けて、電子マネー部15は、支払い処理を実行して、メモリ19eに記憶されている残金を更新して(ステップS38)、買い物が終了するまで支払い処理を繰り返す。
【0027】
一方、支払い金額が不足する場合は、残金が不足していることを示す報知(警告)を発する(ステップS39)。そして、操作部13から電子マネーによる支払い指示の操作が行われたか否かに基づいてCPU16は電子マネーを使用するか否かを判定する(ステップS40)。この判定の結果、電子マネーによる支払いをせずに、現金等で支払いを済ませる場合は、電子マネーによる支払いを中止し(ステップS41)、電子マネーによる支払いの指示が行われた場合、CPU16は、表示部14に入金を催促するメッセージを表示する。この表示を見て、ユーザが電子マネーの入金を行うことにより、メモリ19eに記憶されている残金が更新される(ステップS42)。入金が確認されると、CPU16は、直近の交通機関の支払いに支障の無い金額と買い物金額が不足していないかを再度判定し(ステップS43)、未だ残金が不足している場合は、再度報知(警告)を発する(ステップS39)。
【0028】
一方、残金が支払い可能な金額になった場合、CPU16は、電子マネー部15に対して、買い物の決済を行う指示を出す。これを受けて、電子マネー部15は、支払い処理を実行して、メモリ19eに記憶されている残金を更新する(ステップS44)。続いて、ステップS36において、買い物が無いと判定された場合、CPU16は、位置測定部12により出力される自端末の位置情報に基づいて、交通費決済を行うべき位置に到達している否かを判定する(ステップS45)。この判定の結果、交通費決済位置に到達していない場合は、ステップS36へ移行する。一方、交通費決済を行うべき位置に到達している場合、CPU16は、直近の交通機関において支払いに支障がないか否かを判定し(ステップS46)、残金が不足している場合は支払いができないため、CPU16は報知(警告)発して(ステップS47)入金を催促する。ここで、ユーザが電子マネーの入金を行うことにより、メモリ19eに記憶されている残金が更新される(ステップS48)。そして、CPU16は、残金が直近の交通費決済に支障が無い金額になったか否かを判定し(ステップS49)、未だ不足している場合は再度報知(警告)を発する(ステップS47)。直近の交通費決済に支障のない金額が入金された場合、CPU16は、電子マネー部15に対して、買い物の決済を行う指示を出す。これを受けて、電子マネー部15は、支払い処理を実行して、メモリ19eに記憶されている残金を更新する(ステップS50)。
【0029】
次に、CPU16は、位置測定部12により出力される自端末の位置情報と、経路誘導開始時にメモリ19bに記憶しておいた自端末の位置情報と一致するか、または、経路誘導を開始してから一番最初に交通費の決済をした場所にいるか否かを判定し(ステップS51)、その位置にいないと判定された場合はステップS36へ移行する。一方、その位置まで到達した場合は、これ以上交通機関の決済をすることはないため、CPU16は電子マネー部15に対して残金管理を終了する指示を出力して(ステップS52)、処理を終了する。
【0030】
このように、経路誘導処理と電子マネー処理とを連携させて、経路誘導処理により経路検索を行った場合に交通費を計算し、電子マネー処理で決済可能か否か判定するようにしたため、電子マネーの残金が不足している場合に入金を促すメッセージ等を表示することができる。また、検索経路内にユーザが所有している定期乗車券区間が含まれている場合には、この区間の交通費を減算して必要な交通費の算出を行うことができるため、最適な経路誘導を実施することができる。また、誘導経路の途中の店舗で商品等を購入したことにより必要な交通費が不足すると判定された場合に入金を促す報知(警告)を行うことができる。
【0031】
さらに、入金を忘れた場合は自端末の位置情報により乗車、あるいは下車場所で入金額が不足していることを促す報知(警告)を行うことができる。また、経路誘導中に現金支払い等の電子マネーを利用しない方法で移動した場合は、経路の再検索を行うか、電子決済しなかった金額を交通費の管理外とすることで、店舗での利用金額を増やすことができる。また、経路誘導において往復設定を行うと、経路誘導設定時から最初の決済位置付近を通過することで、電子マネーの管理を解除するので、交通費不足が発生すること防止することができる。
【0032】
<第2の実施形態>
次に、図5を参照して、レストラン予約時の情報に基づいて、経路誘導と残金管理を行う動作を説明する。まず、ユーザは、操作部13を操作して、レストラン予約を行うアプリケーションを起動する。これを受けて、CPU16は、レストランデータベースサーバ6に接続して、レストラン情報を読み出し、表示部14に表示する。ユーザは、表示されたレストランの中から希望するレストランを選択する(ステップS61)とともに、予約する時間や人数等を設定する(ステップS62)。続いて、CPU16は、位置測定部12から出力される自端末の位置情報を取得し(ステップS63)、選択したレストランの位置情報と自端末の位置情報とから経路検索を行い(ステップS64)、レストランまで移動するのに必要な交通費の金額を算出するとともに、予約した時間に間に合うか否かを判定する(ステップS65)。この判定の結果、間に合わないと判定した場合、CPU16は、表示部14に間に合わないことを示す報知(警告)を表示すると共に再選択を促す表示を行い(ステップS66)、ステップS61へ移行する。
【0033】
次に、時間的に間に合うと判定された場合、CPU16は、レストランデータベースサーバ6に対して、レストラン予約確認依頼を送信する。これを受けて、レストランデータベースサーバ6は、内部のデータベースに記憶されている予約状況の情報を参照して、予約可能であるか否かを判定し、予約可能であれば予約処理を行い、予約結果を携帯端末1へ返信する。また予約ができない場合は、予約できないことを携帯端末1へ返信する。この返信を受けたCPU16は、この返信内容に基づいて予約できたか否かを判定する(ステップS67)。この判定の結果、予約できない場合、CPU16は、予約できないことを表示部14に表示すると共に、再選択を促す表示を行い(ステップS68)、ステップS61へ移行する。一方、予約ができた場合、CPU16は、設定に沿った料金又は概算料金の情報をレストランデータベースサーバ6から入手する(ステップS69)。そして、CPU16は、入手したレストランの概算料金と交通費を合算して、必要予算、位置情報、予約日時などの情報をメモリ19dに記憶し、経路誘導を行う。このとき、CPU16は、レストランの予約時間に間に合うように、経路誘導を行う。
【0034】
なお、アプリケーション起動時に自端末の位置を取得し、選択したレストランを優先するのであれば間に合わない予約時間設定をさせないようにしてもよい。また、予約時間を優先するのであれば間に合わないレストランを選択の候補から外すようにしてもよい。
【0035】
このように、携帯端末1を使用してレストラン等の予約を行うと、この店舗の概算予算を見積もり、予約当日にこの概算予算を電子マネーの残金管理に組み込むと共に、予約時間に遅れないように店舗まで経路誘導するようにしたため、残金管理を行いながら最適な経路誘導を行うことが可能となる。
【0036】
<第3の実施形態>
次に、図6を参照して、コンサート当日より以前にチケットの予約を行い、この予約情報に基づいて、経路誘導と残金管理を行う動作を説明する。まず、ユーザは、操作部13を操作して、チケット予約を行うアプリケーションを起動する。これを受けて、CPU16は、チケット管理サーバ4に接続して、コンサート情報を読み出し、表示部14に表示する。ユーザは、表示されたコンサートの中から希望するコンサート選択する(ステップS81)とともに、チケットの種類や購入枚数等を決定する(ステップS82)。これを受けてCPU16は、チケット管理サーバ4に対して、チケット予約確認依頼を送信する。これを受けて、チケット管理サーバ4は、内部のデータベースに記憶されている予約状況の情報を参照して、予約可能であるか否かを判定し、予約可能であれば予約処理を行い、予約結果を携帯端末1へ返信する。また予約ができない場合は、予約できないことを携帯端末1へ返信する。この返信を受けたCPU16は、この返信内容に基づいて予約できたか否かを判定する(ステップS83)。この判定の結果、予約できない場合、CPU16は、予約できないことを表示部14に表示すると共に、予約を中止するか否かを問い合わせるメッセージを表示部14に表示する。ここで、ユーザは、予約を中止するのであれば中止する操作を行い、同じコンサートで日付、時間、座席などの変更を行うのであれば再選択の操作を行う。CPU16は、予約を中止するか否かを判定し(ステップS84)、中止するのであれば処理を終了する。再選択を行うのであればステップS81へ移行し、再度選択を行う。
【0037】
一方、予約できた場合、CPU16は、予約が確定したチケットに付随する情報をチケット管理サーバ4から入手して、メモリ19cへ記憶する(ステップS85)。ここで入手する情報としては開催日、開演時刻、コンサート会場の位置情報、チケットに相当する電子チケットデータ等である。そして、CPU16は、自端末の日付変更時において、メモリ19cに記憶されているチケットデータの日付を確認し、コンサート開催日であればコンサート開催日であることを表示部14へ表示する(ステップS86、S87)。
【0038】
次に、CPU16は、位置測定部12から出力される自端末の位置情報を取得し(ステップS88)、メモリ19cに記憶されているコンサート会場の位置情報に基づいて、このコンサート会場を目的地とした誘導経路検索を行う(ステップS89)。そして、CPU16は、この誘導経路検索の結果得られる所要時間と、メモリ19cに記憶されているコンサート開演時刻に基づいて、出発時刻を逆算して求め(ステップS90)、自端末の時計と比較して時間的に余裕があるか否かを判定する(ステップS91)。この結果、余裕が無いときには音、振動、光、画面表示等を用いて報知(警告)を発し(ステップS94)、残金管理を伴う経路誘導へ移行する(ステップS96)。
【0039】
一方、ステップS91の判定において、時間的に余裕がある場合、CPU16は、位置測定部12から出力される自端末の位置情報に基づいて、自端末の位置に著しい変化があるか(コンサート会場への移動を開始しているか)否かを監視する(ステップS92)。この監視の結果、著しい位置変化が見られない場合は出発時刻に近いか否かを判定し(ステップS93)、出発時刻になるまで待機する。出発時刻に近い場合、CPU16は、報知(警告)を発して移動する(出かける)ことを促す(ステップS94)。一方、自端末の移動を検出した場合、CPU16は、目的地までの誘導経路に合致しているか否かを判定する(ステップS95)。誘導経路に合致している場合は早めに目的地へ移動を開始しているものと見なし残金管理を伴う経路誘導へ移行する(ステップS96)。また、誘導経路に合致していないと判定したときは、時間に余裕があるため別の場所へ移動しているものと見なして、自端末の位置確認を行う。
【0040】
このように、携帯端末1を利用してコンサートのチケットを予約すると、コンサート当日、開演時刻に遅れないようにコンサート会場まで、残金管理及び/または時間管理を行いながら経路誘導することが可能となる。また、終演時間や帰宅時間を入力すれば、自宅までの残金や時間管理も行うことが可能である。
【0041】
<第4の実施形態>
次に、図7を参照して、帰宅時の曖昧な交通費算出方法について説明する。まず、目的地を設定し最適経路の検索を行う(図2に示すステップS1と同様処理)。この時、CPU16は、最適経路検索と共に最適交通費と現在の時刻から推測される目的地到着時刻を算出する。CPU16は、設定条件において往復設定がなされたか否かを判定し(ステップS101)、片道設定であれば曖昧設定はされない(図2に示すステップS6へ移行する)。一方、往復設定がなされた場合、CPU16は、曖昧設定を行うか否かをユーザに問い合わせる。ユーザは、この問い合わせに対して、操作部13を操作して、曖昧設定を行うか否かを回答する。CPU16は、この回答内容に基づいて、曖昧設定を行うか否かを判定し(ステップS102)、曖昧設定を行わなずに、往路、復路共に同じ経路を選択する場合はステップSS4(図2)へ移行し、単純に交通費を2倍した残金の管理を行う。
【0042】
曖昧設定を行う場合、CPU16は、往路に掛かる時間に予め設定された定数(例えば1.1)を乗算した曖昧時間を算出し(ステップS103)、この曖昧時間を基準にして曖昧経路検索を行う(ステップS104)。この経路探索の結果、曖昧経路が複数有るか否かを判定し(ステップS105)、複数の検索経路が得られなかった場合は曖昧経路が最適経路となる。CPU16は、予め設定された上限定数(例えば2.0)に達しているかを判定し(ステップS106)、達している場合は最適経路に対して2倍の時間を掛ける迂回経路が存在しない(往復共に同じ経路しかない)と見なし、ステップS4へ移行する。
【0043】
一方、予め設定された上限定数(例えば2.0)に達していない場合、CPU16は、定数を予め設定されている定数への加算数(例えば0.1刻み)で定数を大きくして(ステップS107)、曖昧時間を再計算する。ステップS105において複数の曖昧経路が得られた場合、CPU16は、複数の曖昧経路から、最も高い交通費を曖昧交通費として設定する(ステップS108)。そして、CPU16は、この曖昧交通費を表示部14に表示し、ユーザに対してこの金額で管理することを確認させる(ステップS109)。表示部14に表示された金額で問題がない場合はステップS6(図2)へ移行する。ここで、適正経路の交通費と曖昧交通費の差が小さいと思われる場合(都心部に於いては時間と交通費は正比例する訳ではないので定数が小さいと交通費に変化が少なくなり、曖昧の意味が薄れてしまうので本人確認が必要となる)はステップS106へ移行する。
【0044】
このように、往復の交通費管理において、行きは最短、最適経路を通るが、帰りは必ずしも同じ経路で戻る保証はないため、行きの最短、最適経路の時間をベースに所定の定数を掛け合わせた曖昧時間を算出し、この曖昧時間から演算した交通費の高い経路の金額を交通費として管理することにより、途中で入金することなく別経路で帰宅することが可能となる。このような曖昧交通費を適用することより、往路と復路で経路が多少違っても交通費が不足して、帰れなくなってしまうという不具合が発生することを防止することができる。
【0045】
<第5の実施形態>
次に、図8を参照して、帰宅時経路上の途中下車に関する処理動作について説明する。目的地等の設定条件は既に入力されており、経路誘導又は交通費管理が成されている状態において、ステップS111へ移行して交通機関の入場口に到達したかを位置測定部12が出力する位置情報に基づいて判定し、入場口(改札口)に到達すると、CPU16は、電子マネー部15に対して決済処理を指示する。これを受けて、電子マネー部15は、入場可能な金額を決済する(ステップS112)。また、決済後、経路検索で定められた交通機関の出口に到達したか否かを判定し(ステップS113)、出口に到達した場合、交通機関の運賃精算を行う出口決済を行う(ステップS119)。この場合は経路検索時の管理金額と同じ金額の支払いが行われたことになる。
【0046】
一方、帰宅時に途中下車をした場合は、誘導経路上の途中駅で降りたことを位置測定部12が出力する位置情報に基づいて判定し、管理外の金額で帰宅までの交通費に不足が生じないかを判定し(ステップS114)、不足しない場合は出口決済を行う(ステップS119)。一方、不足する場合、CPU16は、音や光等を用いて報知(警告)を発する(ステップS115)とともに、表示部14には注意を促すメッセージを表示する(図10(c)参照)。そして、CPU16は、入金の意志の確認を行い(ステップS116)、入金された(ステップS118)場合は、ステップS119へ移行して出口決済を行う。入金の意志確認に対して、現金の持ち合わせが無いなどの理由から入金が拒否された場合は、途中下車を禁止し帰宅経路へ誘導する(ステップS117)。
【0047】
このように、帰宅時に途中下車した場合、帰宅経路内の途中駅で降りようとしていることを位置測定情報に基づいて検出すると、改札口で出口決済する前に、再入場して電車に乗る交通費を支払うことが可能な残金が残っているか否かを判定し、不足する場合には入金を促し、入金できない場合は経路検索で設定された決済位置の出口以外での支払いを行わせないようにしたため、交通費が不足して帰れなくなってしまうことを防止することができる。
【0048】
以上説明したように、電子マネー機能と経路誘導機能を搭載した携帯端末において、目的地を設定すると、目的地までの最適経路を誘導すると共に、交通費として必要な残金が残るように電子マネーの管理を行うようにしたため、目的地において所定の目的を達成するために支払いが生じても交通費不足が発生して移動が困難になるという事態の発生を防止することができる。
【0049】
なお、本発明の携帯端末は、移動通信を使用した携帯電話機や移動通信機能を有した携帯情報端末(PDA)、モバイル端末、カーナビ装置などを含むものである。
【0050】
なお、図1における処理部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより経路探索処理及び電子マネーの残金管理処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ(RAM)のように、一定時間プログラムを保持しているものも含むものとする。
【0051】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク(通信網)や電話回線等の通信回線(通信線)のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であっても良い。
【図面の簡単な説明】
【0052】
【図1】本発明の一実施形態の構成を示すブロック図である。
【図2】図1に示す携帯端末1の動作を示すフローチャートである。
【図3】図1に示す携帯端末1の動作を示すフローチャートである。
【図4】図1に示す携帯端末1の動作を示すフローチャートである。
【図5】図1に示す携帯端末1の動作を示すフローチャートである。
【図6】図1に示す携帯端末1の動作を示すフローチャートである。
【図7】図1に示す携帯端末1の動作を示すフローチャートである。
【図8】図1に示す携帯端末1の動作を示すフローチャートである。
【図9】図1に示す表示部14の画面表示例を示す説明図である。
【符号の説明】
【0053】
1・・・携帯端末、11・・・送受信部、12・・・位置測定部、13・・・操作部、14・・・表示部、15・・・電子マネー部、16・・・CPU、17・・・ROM、18・・・RAM、19a・・・メモリ(地図用)、19b・・・メモリ(誘導経路用)、19c・・・メモリ(チケット用)、19d・・・メモリ(レストラン用)、19e・・・メモリ(電子マネー用)、2・・・基地局、3・・・ネットワーク、4・・・チケット管理サーバ、5・・・ナビゲーションデータベースサーバ、6・・・レストランデータベースサーバ、7・・・電子マネー管理サーバ

【特許請求の範囲】
【請求項1】
目的地まで移動する経路を探索する目的地探索手段と、電子マネーを使用可能とする電子マネー処理手段とを備える携帯端末であって、
前記目的地探索手段により探索した目的地において所定の目的を達成するために必要な必要費用を算出する費用算出手段と、
前記電子マネーの残金を管理する残金管理手段と、
前記必要費用と前記電子マネーの残金との比較結果を報知する報知手段と
を備えたことを特徴とする携帯端末。
【請求項2】
前記残金管理手段は、
前記電子マネーによる支払い処理が生じる場合に、前記目的地までの移動に必要な必要費用が残金として残るように電子マネーの残金を管理することを特徴とする請求項1に記載の携帯端末。
【請求項3】
前記目的地探索手段により探索した移動経路に基づいて、前記目的地までの移動経路を誘導する経路誘導手段と、
前記移動経路に基づく誘導時に、前記所定の時刻に前記目的を達成できるように移動の時間管理を行う時間管理手段と
をさらに備えたことを特徴とする請求項1または2に記載の携帯端末。
【請求項4】
目的地まで移動する経路を探索する目的地探索手段と、電子マネーを使用可能とする電子マネー処理手段とを備える携帯端末における制御方法であって、
前記目的地探索手段により探索した目的地において所定の目的を達成するために必要な必要費用を算出する費用算出ステップと、
前記電子マネーの残金を管理する残金管理ステップと、
前記必要費用と前記電子マネーの残金との比較結果を報知する報知ステップと
を有することを特徴とする携帯端末制御方法。
【請求項5】
前記残金管理ステップは、
前記電子マネーによる支払い処理が生じる場合に、前記目的地までの移動に必要な必要費用が残金として残るように電子マネーの残金を管理することを特徴とする請求項4に記載の携帯端末制御方法。
【請求項6】
前記目的地探索手段により探索した移動経路に基づいて、前記目的地までの移動経路を誘導する経路誘導ステップと、
前記移動経路に基づく誘導時に、前記所定の時刻に前記目的を達成できるように移動の時間管理を行う時間管理ステップと
をさらに備えたことを特徴とする請求項4または5に記載の携帯端末制御方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate


【公開番号】特開2007−172432(P2007−172432A)
【公開日】平成19年7月5日(2007.7.5)
【国際特許分類】
【出願番号】特願2005−371311(P2005−371311)
【出願日】平成17年12月26日(2005.12.26)
【出願人】(000006633)京セラ株式会社 (13,660)
【Fターム(参考)】