JP2005050262A - Ｉｃモジュール、ｉｃカード、携帯端末、及びサービス処理方法 - Google Patents

Abstract

【課題】 携帯端末に搭載されたＩＣモジュール（ＩＣカード機能を有するセキュアエレメント）が、サービス端末との間の非接触通信により行なった処理について、ユーザに適切な通知を行なう。
【解決手段】 セキュアエレメント１００は、サービスに関する状態のデータを保持するメモリ１０４と、所定の場所に設置されたサービス端末１２０との非接触通信によりサービスに関する処理が行なわれるように制御する制御部１０２と、この処理により状態のデータについてユーザに確認を要求することなく行なわれた変更が、ユーザの注意を喚起すべきとして設定された条件を満たすか否かを判断し、満たすとの判断に応じて、携帯端末１４０の表示部１５０がユーザへの通知を行なうように指示する処理判断部１１０とを備える。
【選択図】 図１

Description

本発明は、携帯端末（携帯電話、ＰＤＡ等）に、ＩＣモジュールを含むＩＣカードを装着するか、もしくは、ＩＣカードの機能を実現するＩＣモジュールを内蔵させることにより、携帯端末を利用した様々なサービスを提供する技術に関する。ここで、ＩＣモジュールとは、一つ又は複数のＩＣチップにより構成されたモジュールであり、プロセッサとメモリを備え、プロセッサがメモリに格納されたプログラムを実行することにより所定の機能を実現するものであればよく、その具体的構造は問わないものとする。

近年、自動販売機、商店等における精算カウンター、駅の改札口等の交通機関の乗降口、コンサート等のイベント会場の出入口、オフィスや工場のゲートなどの、所定の場所に、ＩＣカードのリーダ／ライタを備えたサービス端末を設置し、ユーザがかざしたＩＣカードとの間で非接触の通信を行なって、電子マネーによる決済、商品の購入等に伴うポイントサービス、交通機関の利用精算、電子チケットによる入場処理、入退室や勤務管理などの各種サービスを提供することを可能にする技術の検討が進んでいる。

ＩＣカードに搭載されるＩＣモジュールは、論理演算や算術演算等を行うＣＰＵ又はＭＰＵ等のプロセッサ、及びプログラムやデ−タを格納するＲＯＭ、ＲＡＭ、又はＥＥＰＲＯＭ等のメモリを備える。そして、非接触通信を行うＩＣカードの場合、これらに加えてリーダ／ライタとの間で非接触通信を行なうための非接触インタフェースを備える。ＩＣカード用のＩＣモジュールにおいては、プログラムや重要なデータがＩＣチップ内に密閉され、権限を有する装置以外からは、重要な情報もそれにアクセスするための鍵やロジックも見えないように構成されており、重要な情報を格納したり、モジュール内で暗号処理を行ったりすることができる。

また、最近は、ＩＣカードに搭載されるメモリも大容量になってきており、複数のアプリケーションを同時に格納しておくことができるので、１枚のＩＣカードで複数のサービスを利用することができる。これにより、例えば、特定の鉄道に乗降するためのプリペイド乗車券と、特定のコンサート会場に入場するための電子チケットなど、２つ以上のアプリケーションを１枚のＩＣカードに格納しておけば、サービス毎に異なるＩＣカードを取り出す面倒がなく、１枚のＩＣカードで様々なサービスに対応することができる。

さらに、ＩＣカードがリーダ／ライタとの非接触インタフェースの他に、外部機器と接続するための接触インタフェースを備えることにより、ＩＣモジュールを搭載したＩＣカードを携帯電話やＰＤＡ等の携帯端末に接続して用いることができる。このようにＩＣカードが接続された携帯端末は、ＩＣモジュールを搭載した携帯端末となる。あるいは、ＩＣモジュール自体を携帯端末に内蔵することによっても（この場合も、ＩＣモジュールと携帯端末内のＩＣモジュール以外の部分とは、接触インタフェースを介して接続されているとみなすことができる）、ＩＣモジュールを搭載した携帯端末を実現することができる。

特許文献１には、Ｅコマースモジュールを搭載した携帯電話機を用いて、各種電子商取引サービスを利用する技術が開示され、特に、商取引を行なう際に、ユーザが携帯電話機のキーパッドからパスワードを入力するように要求することに関して、次のような発明が記載されている。すなわち、特許文献１の発明では、買い物の際に電子マネーとして使用するような場合にはパスワード入力が要求されるが、駅改札ゲートにおいて通勤（通学）定期券として使用するような場合はパスワード入力が不要となるように、ユーザがパスワード入力の要否を設定できるようにしている。また、パスワード入力が不要に設定されている場合には、携帯電話機の表示灯を点灯させることで、ユーザが設定状態を認知できるようにしている。
特開２００３−１２５０４３号公報

非接触式のＩＣカードの大きな利点の一つは、サービス端末に対してタッチ・アンド・ゴーで処理が可能なことである。このため、非接触式のＩＣモジュール搭載携帯端末においても、パスワードフリーとするアプリケーションが多く適用される可能性が高い。

しかし、上述した特許文献１の技術では、ユーザは、パスワード不要に設定されていることは、表示灯の点灯により知ることができるが、パスワード不要に設定されたサービスを利用したときに実際にどのような処理がなされたのかについては、全く知ることができない。なお、処理の内容や結果について、サービス端末の表示画面には表示される可能性があるが、タッチ・アンド・ゴーの処理速度が要求される場合、ユーザがＩＣモジュール付き携帯端末をかざしてサービス端末の側を通過する間に、その表示画面の表示を的確に読み取ることには困難が伴う。さらに、ＩＣモジュール付き携帯端末の場合、ＩＣカード単体の場合とは異なり、携帯端末が有する表示部を利用して処理の内容や結果を表示することも可能であるが、パスワードフリーで行なうような処理の全てについて細かく表示をしていては、煩わしく、ユーザの注意が散漫になり、意図しない処理や誤り等がなされても気づくことができない可能性が高くなってしまう。

本発明は、上記した背景に鑑み、携帯端末に搭載されたＩＣモジュールが、サービス端末との間の非接触通信により行なった処理について、ＩＣモジュールと接触インタフェースを介して接続されている携帯端末の表示部等のユーザインタフェース機能を使って、ユーザに適切な通知を行なうことができる機構を提供することを目的とする。

本発明に係る、携帯端末に搭載されて使用されるＩＣモジュールは、所定の場所に設置されたサービス端末との非接触通信により前記サービス端末が提供するサービスに関する処理を行なう手段と、前記サービスに関する状態のデータを保持する手段と、前記処理により前記状態のデータについてユーザに確認を要求することなく行なわれた変更が、ユーザの注意を喚起すべきとして設定された条件を満たすか否かを判断し、満たすとの判断に応じて、前記携帯端末が備えるユーザインタフェース機能に対し、ユーザへの通知を指示する手段とを具備することを特徴とする。

この構成により、ユーザがあるサービスを利用するために所定の場所を通過する際、サービス端末にＩＣモジュール搭載携帯端末をかざすと、そのサービス端末とＩＣモジュールとの間で非接触通信により処理が行なわれ、この処理により当該サービスに関する状態のデータが変更されることがある。この変更は、ユーザに、例えば処理開始前にパスワードやＰＩＮ（パーソナルＩＤナンバーと言われる暗証番号）の入力を要求したり処理確定前に変更内容の承認を要求したりすることなく行なわれるが、ＩＣモジュールによりユーザの注意を喚起すべきとして設定された条件を満たす変更であると判断された場合は、携帯端末が備えるユーザインタフェース機能を使って、ユーザに通知される。例えば、携帯端末の表示部を光らせたり、音を鳴らしたり、バイブレーション機能を用いたりして、ユーザの注意が喚起される。

本発明に係るＩＣモジュールは、前記処理に係わるデータのうち所定のデータ及び前記処理を行なうためのプログラムに対し、前記サービスに関して正当な権限を有する端末以外からのアクセスがされないよう制御する手段を更に具備した構成としてもよい。

この構成により、サービスに関して正当な権限を有する端末（例えばそのサービスを行なうサービス端末）以外からは、ＩＣモジュール内のプログラムや機密性の高いデータにアクセスできないため、Ｅコマース等のセキュリティが要求されるサービスにも対応することができる。なお、ＩＣモジュール内に格納されたデータの一部（例えば処理結果等）を、サービスに関して正当な権限を有する端末ではない携帯端末の表示部に表示させることも可能であるが、これは、ＩＣモジュール内のプログラムにより許可されている（機密性の比較的低い）データのみが、接触インタフェースを介して携帯端末へ出力されるものである。

本発明に係るＩＣカードは、上記本発明に係るＩＣモジュールを備え、前記携帯端末に着脱可能であることを特徴とする。

この構成を持つＩＣカードを携帯端末に接続することで、携帯端末のユーザは、サービスを利用できるようになるとともに、サービス端末とＩＣカードとの間で行なわれた処理による変更のうち、注意を払う必要のあるものについて選択的に、携帯端末のユーザインタフェース機能を通じて通知を受けることができるようになる。

本発明に係るＩＣカードは、前記非接触通信を行なうためのインタフェースを更に備えた構成としてもよい。

これにより、ＩＣカードは、非接触インタフェースを介してサービス端末との通信を行なう一方で、接触インタフェースを介して携帯端末との間でデータの入出力を行なうことができる。

本発明に係る携帯端末は、上記本発明に係るＩＣモジュールと、前記ユーザインタフェース機能とを備えることを特徴とする。

このように、ＩＣモジュールが内蔵された携帯端末、もしくはＩＣカード化されたＩＣモジュールが接続された携帯端末のユーザは、そのユーザインタフェース機能を通じて、携帯端末に搭載されたＩＣモジュールとサービス端末との間で行なわれた処理による変更のうち、注意を払う必要のあるものについて選択的に、通知を受けることができる。

本発明に係る携帯端末は、前記ＩＣモジュールと前記サービス端末とが前記非接触通信を行なうためのインタフェースを更に備えた構成としてもよい。

この構成により、ＩＣモジュールは、携帯端末との間の接触インタフェースしか外部とのインタフェースを有しなくても、そのインタフェースを介して携帯端末が有する非接触インタフェースを利用して、サービス端末との間の非接触通信を行なうことができる。

上述した本発明に係るＩＣモジュールにおいて、複数のアプリケーションプログラムを記憶する手段を更に備え、前記サービスに関する処理は、前記複数のアプリケーションプログラムのうちの一つにより行なわれ、前記処理により前記状態のデータについて行なわれた変更についての判断及びユーザへの通知の指示は、前記複数のアプリケーションプログラムとは別のプログラムであって前記複数のアプリケーションプログラムの各処理による変更を共通に検出可能に構成されたプログラムにより行なわれるようにしてもよい。

これにより、同様の変更が行なわれたのに、あるアプリケーションプログラムの処理による変更であれば通知され、別のアプリケーションプログラムの処理による変更であると通知されないといった不整合が起こることを防止でき、通知の一貫性を保つことができる。また、新規アプリケーションプログラムを開発する度に、変更についての判断及びユーザへの通知の指示の機能を新たに実装しなくてもよいため、開発投資を抑制できる。

上記本発明に係るＩＣモジュールにおける前記状態のデータの一つの例は、ユーザが現在所有する金銭的な価値のデータであり、前記金銭的な価値を減少させる処理が行なわれたか否かに応じて、前記設定された条件を満たすか否かを判断してもよい。

これにより、例えば定期券付きプリペイド乗車券のように、改札ゲートをタッチ・アンド・ゴーすなわちパスワードレスで通過するサービスで、金銭的な価値が変化しない場合（定期券の区間内での乗降、最低料金区間内での降車等）にはユーザへの通知は行なわず、金銭的な価値を消費する処理が行なわれた場合（定期券の区間外での乗降等）に選択的にユーザへの通知を行なうことができる。また、例えばポイントサービスにおいて、金銭的な価値が増加する場合（ポイントを貯めて決済）にはユーザへの通知は行なわず、金銭的な価値を消費する処理が行なわれた場合（ポイントを使用して決済）に選択的にユーザへの通知を行なうこともできる。ここで、さらに、金銭的な価値の減少の度合いに基づいて（減少量が閾値以上である、減少した額の残額に対する割合が閾値以上である等）ユーザへの通知の要否を判断してもよい。このように、サービス処理結果について、ユーザの注意を適切に喚起することができる。

上記本発明に係るＩＣモジュールにおける前記状態のデータが、ユーザが現在所有する金銭的な価値のデータである例において、前記処理の結果前記金銭的な価値が閾値以下となったか否かに応じて、前記設定された条件を満たすか否かを判断してもよい。

これにより、例えばそのサービスを利用するために最低限必要な金額（自動販売機であれば販売商品の最低額、交通機関であれば最低乗車運賃等）を閾値として設定すれば、残高が閾値以下となったときにユーザへ通知されることにより、ユーザは次回そのサービスを利用する前に予めＩＣモジュール内の残高を増加させるチャージ処理を行なうことができ、サービス端末により残高不足が指摘されて多数のユーザによるタッチ・アンド・ゴーの流れが妨げられてしまう事態を回避することが可能になる。

上記の閾値は、本発明に係るＩＣモジュールが前記サービスを利用するための料金に関する情報を前記サービス端末との非接触通信により受信する手段を更に備え、受信した前記料金に関する情報に基づいて設定されるようにしてもよい。

これにより、例えばそのサービスを利用するために最低限必要な金額が改定された場合でも、新しい商品販売額や運賃等に関する情報がサービス端末からＩＣモジュールへ伝達され、改訂後の料金に基づいて閾値を設定することができるので、残高不足になる可能性を予めユーザに通知する機能を有効に働かせることができる。

上記本発明に係るＩＣモジュールにおける前記状態のデータが、ユーザが現在所有する金銭的な価値のデータであり、前記所定の場所が交通機関への乗降時にユーザが通過する場所である例において、ユーザが前記交通機関を前記所定の場所を通過した後に利用するために必要となる金額を予測し、予測した前記金額に基づいて、前記金銭的な価値がユーザの注意を喚起すべき程度まで減少したか否かを判断するための閾値を設定するようにしてもよい。

これにより、ユーザがその交通機関のあるサービス端末が設置された場所（例えば改札ゲート）を通過した際（乗車時又は降車時）、その交通機関の別のサービス端末の設置場所を次に通過すると（目的地での降車時又は直前に降車した場所での乗車時）ＩＣモジュール内の金銭的価値がどの程度減少させられるかを予測することができ、予測結果に基づいて動的に閾値を設定することにより、残高不足となる可能性をより的確にユーザに通知することができる。

上記の必要となる金額は、前記交通機関の種類、ユーザが前記交通機関へ乗車した場所、ユーザが前記交通機関から降車した場所、ユーザが前記交通機関を利用した曜日、ユーザが前記交通機関を利用した時間、ユーザが前記交通機関を利用した際に消費した金銭的価値、及び前記交通機関においてユーザが所有する定期乗車券の情報のうち、少なくとも一つに基づいて、予測してもよい。

これにより、例えば同じＩＣモジュールで複数の鉄道の乗降に対応する場合でも、ユーザがどの鉄道を利用しようとしているかによって異なる最低乗車運賃に基づいて必要金額を予測したり、ユーザの金銭的価値の消費傾向（例えばいつどの駅を頻繁に利用しているか、またその際に消費した金額等）を記憶しておき、これを参照して必要金額を予測したりすることができる。ユーザの消費傾向と、現在の日時やユーザが直前に通過したサービス端末の設置場所等とを照合して、必要金額を予測しても構わない。

上記の必要となる金額は、また、前記交通機関の運賃に関するデータを取得し、ユーザが通過した前記所定の場所が前記ユーザの所有する定期乗車券の区間外である場合に、前記運賃に関するデータに基づいて、ユーザが通過した前記所定の場所から前記定期乗車券の区間内の場所までの額を算出することにより、予測してもよい。

これにより、例えばユーザが定期乗車券の区間を越えて日常的には行かない場所で鉄道を利用するため、必要となる料金の見当がユーザ自身にはつかないような場合でも、定期乗車券の区間内までの必要金額が予測され、ＩＣモジュール内の残高が足りるか否かがユーザに通知される。そして、このために、ＩＣモジュール内に格納されているかもしくは携帯端末により外部から収集される運賃に関するデータを取得することができる。

上記の必要となる金額は、また、前記交通機関の運賃に関するデータとユーザが前記所定の場所を通過した後に向かうべき場所に関するデータとを取得し、前記所定の場所からの前記運賃に関するデータに基づいて、前記向かうべき場所に関するデータにより前記ユーザが前記交通機関から降車すると予想される場所までの額を算出することにより、予測してもよい。

これにより、例えばＩＣモジュール内に格納されている電子チケットの情報（イベントの日時と場所の情報を含む）や携帯端末が保持しているユーザのスケジュール情報（行動予定として日時と場所の情報を含む）から、ユーザが降車する場所を予想することにより、そこまでの必要金額が予測され、ＩＣモジュール内の残高が足りるか否かがユーザに通知される。チケットやスケジュールの情報と、現在の日時やユーザが直前に通過したサービス端末の設置場所等とを照合して、降車場所を予測しても構わない。

上記本発明に係るＩＣモジュールにおける前記状態のデータの別の例は、ユーザが前記所定の場所を通過した後に行くべき場所を示すデータであり、前記処理の結果前記行くべき場所が新たに決定もしくは変更されたか否かに応じて、前記設定された条件を満たすか否かを判断してもよい。

これにより、例えばコンサートのチケットや航空券において、コンサート会場の入口や航空会社のチェックインカウンターを通過する際に、そこに設置されたサービス端末により、会場内や機内の確定した席（行くべき場所）が、ＩＣモジュールに書き込まれる場合に、購入時に暫定的にＩＣモジュールもしくは携帯端末に保持されていた席の情報と確定した席とが一致するならばユーザへの通知は行なわず、購入時には席の情報が与えられていなかったかもしくは暫定の席と確定した席とが異なるならばユーザへの通知を行なうことができる。また、例えば建物のゲートを通過する際に、そこに設置されたサービス端末が、その建物内で出席すべき会議が行なわれる場所をＩＣモジュールに書き込む場合にも、同様に選択的なユーザへの通知を行なうことができる。

上記本発明に係るＩＣモジュールにおける前記状態のデータのさらに別の例は、ユーザが前記所定の場所を通過した後の行動予定についてのデータであり、前記処理の結果前記行動予定の時刻が新たに決定もしくは変更されたか否かに応じて、前記設定された条件を満たすか否かを判断してもよい。

これにより、例えば出勤時に会社の入口を通過する際に、そこに設置されたサービス端末が、その日の確定したスケジュールの時刻をＩＣモジュールに書き込む場合に、前日以前からＩＣモジュールもしくは携帯端末に保持されていたスケジュールの時刻に対して変更がなければユーザへの通知は行なわず、時刻が変更されているかもしくは新たに決定されているならばユーザへの通知を行なうことができる。

上記本発明に係るＩＣモジュールにおける前記状態のデータのさらに別の例は、ユーザが前記所定の場所を通過した後に予定されているイベントについてのデータであり、前記処理の結果前記イベントの内容が新たに決定もしくは変更されたか否かに応じて、前記設定された条件を満たすか否かを判断してもよい。

これにより、例えばイベント会場の入口を通過する際に、そこに設置されたサービス端末が、イベントの確定した内容（演目・題目や出演者・パネラー等）をＩＣモジュールに書き込む場合に、以前からＩＣモジュールもしくは携帯端末に保持されていたイベントの内容に対して変更がなければユーザへの通知は行なわず、内容が変更されているかもしくは新たに決定されているならばユーザへの通知を行なうことができる。

本発明に係るサービス処理方法は、携帯端末に搭載されて使用されるＩＣモジュール内で実行されるものであって、所定の場所に設置されたサービス端末との非接触通信により前記サービス端末が提供するサービスに関する処理を行ない、前記処理により前記ＩＣモジュール内に保持している前記サービスに関する状態のデータを変更し、前記状態のデータについてユーザに確認を要求することなく行なわれた変更が、ユーザの注意を喚起すべきとして設定された条件を満たすか否かを判断し、前記条件を満たすとの判断に応じて、前記携帯端末が備えるユーザインタフェース機能に対し、ユーザへの通知を指示することを特徴とする。

なお、本発明に係るＩＣモジュールに関して上記に述べた事項は、全て、本発明に係るサービス処理方法に関しても適用可能なものである。また、本発明は、携帯端末に搭載されて使用されるＩＣモジュール内のメモリに格納されてサービス処理を実行するためのプログラムとしても、また、そのようなプログラムを記憶する記憶媒体としても、実施可能なものである。

上述したように、本発明によれば、非接触式のＩＣモジュール搭載携帯端末において、タッチ・アンド・ゴーという非接触式の利点を生かすためパスワードフリーに設定した場合でも、サービス端末とＩＣモジュールとの通信によりユーザの注意が喚起されるべき処理が行なわれた場合には、これを携帯端末のユーザインタフェース機能を活用してユーザに通知することができ、意図しない処理や誤りが生じていないかどうかをユーザが簡単にチェックすることができるようになる。

以下、本発明の実施の形態について図面を用いて説明する。

本実施形態において、ＩＣモジュールは、ＩＣカード機能に対して要求される耐タンパ性を有し、ＩＣモジュール内に閉じ込められたプログラムや重要なデータの機密性を保つことができるものとする。このため、本実施形態におけるＩＣモジュールは、セキュアエレメント（ＳＥ）と呼ばれる。

図１は、本実施形態に係るセキュアエレメント（ＳＥ）１００、サービス端末１２０、及び携帯端末１４０の構成例を示す。なお、ＳＥ１００は、携帯端末１４０に着脱可能なＩＣカードに搭載されても良いし、携帯端末に内蔵されていても良い。前者の場合、ＳＥ１００がＩＣカードを構成することになり、後者の場合、ＳＥ１００と携帯端末１４０とを合わせた全体を携帯端末と呼ぶことになる。

ＳＥ１００は、ＳＥ内のアプリケーションプログラムの動作制御や他装置との通信の制御を行なう制御部１０２と、サービスを受けるためのアプリケーションプログラムやサービスに関するデータ等を格納するメモリ１０４とを備える。制御部１０２は、機能的なブロックを示し、実際にはＣＰＵ及びＥＥＰＲＯＭ等により実現される。ＳＥ１００はまた、サービス端末１２０と非接触通信を行なうためのインタフェース（非接触Ｉ／Ｆ）１０６と、携帯端末１４０と接続されるためのインタフェース（接触Ｉ／Ｆ）１０８とを有する。処理判断部１１０は、後に詳述するように、ＳＥ内のアプリケーションプログラムによる処理を監視、判断して、接触Ｉ／Ｆ１０８を介して携帯端末１４０に通知する機能を有する。

サービス端末１２０は、自動販売機、精算カウンター、駅の改札や空港のチェックインカウンター、コンサート会場の出入口、オフィスや工場のゲートなどの、所定の場所に設置されており、サービス端末内のアプリケーションプログラムの動作制御や他装置との通信の制御を行なう制御部１２２と、サービスを提供するためのアプリケーションプログラムや必要なデータ等を格納するメモリ１２４とを備える。サービス端末１２０はまた、ＳＥ１００と非接触通信を行なうことができるインタフェース１２６を有し、ユーザが所定の場所を通過するときに、携帯しているＳＥ１００をサービス端末１２０に近づけることにより、所定のサービスを受けることができる。

携帯端末１４０は、携帯端末の動作や他装置との通信を制御する制御部１４２、携帯端末に様々な動作をさせるためのアプリケーションプログラムや必要なデータ等を格納するメモリ１４４、携帯電話網への通信を行なう通信部１４８、及びＳＥ１００の接触Ｉ／Ｆ１０８と接続可能な接触Ｉ／Ｆ１４６とを備える。携帯端末１４０はまた、キーパッドやボタン、マイクロホンなどによりユーザの操作を受け付ける操作部１５２と、携帯端末の表示画面や着信表示ＬＥＤ、その他専用の表示灯などによりユーザに対する出力を行なう表示部１５０とを備える。表示部１５０は、ユーザの視覚に対する出力に限らず、聴覚に対する出力（スピーカやヘッドホンジャック）でもよいし、触覚に対する出力（バイブレーション機能）でもよい。

図２には、本実施形態の別の構成例を示す。セキュアエレメント（ＳＥ）２００は、非接触Ｉ／Ｆ１０６を有しない以外は、図１のＳＥ１００と同様である。携帯端末２４０は、非接触Ｉ／Ｆ２４６が追加された以外は、図１の携帯端末１４０と同様である。サービス端末２２０は、非接触Ｉ／Ｆ１２６が、携帯端末２４０の非接触Ｉ／Ｆ２４６と非接触通信を行なう以外は、図１のサービス端末１２０と同様である。ＳＥ２００は、接触Ｉ／Ｆ１０８及び１４６を介して、携帯端末２４０の非接触Ｉ／Ｆ２４６を用いて、サービス端末２２０と非接触通信を行なうことになる。なお、ＳＥ２００は、携帯端末２４０に着脱可能なＩＣカードに搭載されても良いし、携帯端末に内蔵されていても良い。前者の場合、ＳＥ２００がＩＣカードを構成することになり、後者の場合、ＳＥ２００と携帯端末２４０とを合わせた全体を携帯端末と呼ぶことになる。

図３（ａ）及び（ｂ）には、上述したＳＥ、サービス端末、及び携帯端末の三者間で行なわれる連携通信により、タッチ・アンド・ゴーで行なわれたサービスの各処理について、ユーザに適切な通知が行なわれる様子を示す。ここでは、従来バリュー（金銭的価値）を消費する場合もパスワードレスで処理が行われていたため、ユーザが意識していない間にバリューが減っていってしまう可能性があったサービスを例にとり、説明する。

本例におけるＳＥは、サービス端末との非接触通信による処理の際、ユーザにバリューの消費を明確に通知する。このため、ＳＥ内部の処理を、処理判断部１１０において監視・判断し、バリューを消費（減算）する処理が行われた場合には、非接触通信処理終了後、携帯端末へ通知の指示を出し、表示部１５０のＬＥＤを点灯させるなどして、ユーザの注意を促す。減算に相当するものとして、削除や無効化の処理が行われた場合も、携帯端末へ通知の指示（例えばＬＥＤ点灯命令）を出す。このように、一つのサービスでも、ＳＥ内部の処理内容に応じて通知がなされることになる。

例えば、鉄道の改札におけるサービスの場合、ＳＥ内に改札アプリ（アプリケーションプログラム）があり、その中に定期券データと電子マネーとがセキュアに保護された形で格納されている。この改札アプリでは、定期券データのみを使う場合と、定期券区間外で精算が伴う場合とがある。定期区間内で乗り降りをした場合には、携帯端末のＬＥＤを消灯したままとする。一方、定期券区間外での改札入場又は出場時に改札機で精算が行われた場合には、携帯端末のＬＥＤを赤色に点灯させるなどの明確な表示を行い、ユーザに通知する。

また、例えば、ポイントカードを利用するサービスの場合、ＳＥ内にポイントアプリ（アプリケーションプログラム）があり、その中に現在のポイントのデータがセキュアに保護された形で格納されている。このポイントアプリでは、ポイントは貯めて決済をする場合と、ポイントを使用して割引価格で購入する場合とがある。ポイントを貯めた場合には、携帯端末のＬＥＤを消灯したままとするが、ポイントを使用して決済処理をした場合には、ＬＥＤを青色に点灯させるなどの明確な表示を行い、ユーザに通知する。

図３（ａ）は、定期券での改札処理やポイントを貯める処理のように、バリューが消費されない処理Ａが、ＳＥのアプリ１１２（改札アプリやポイントアプリ）とサービス端末のアプリ１２８との間の非接触通信により行われた場合を示している。この非接触通信は、非接触Ｉ／Ｆ１０６及び１２６を介して行われ、制御部１０２がＳＥ内のアプリ１１２の実行と非接触Ｉ／Ｆ１０６を介した通信とを制御し、制御部１２２がサービス端末内のアプリ１２８の実行と非接触Ｉ／Ｆ１２６を介した通信とを制御している。

ＳＥの制御部１０２の一部を構成する処理判断部１１０は、制御部１０２がその動作を制御するアプリ１１２によって行なわれた処理を監視し、ユーザに通知すべきか否かを判断することができる。処理判断部１１０は、処理結果としてセキュアに書き込まれるバリューの値を監視しており、処理前のバリューの値と比較することにより、バリューを消費する処理が行われたか否かを判断するものであっても良いし、アプリ１１２がその処理に用いたライブラリの種類を監視することにより、バリューを消費する処理が行われたか否かを判断するものであっても良い。

図３（ａ）では、処理Ａの結果、バリューは消費されないので、携帯端末の表示部１５０に対する指示は行われない。但し、携帯端末に搭載されたアプリケーション１５４によっては、バリューが消費されなくても処理結果の通知が要求される可能性がある。その場合には、そのアプリ１５４に対して、処理判断部１１０ではなくＳＥのアプリ１１２が、接触Ｉ／Ｆ１０８及び１４６を介して、処理Ａの結果情報を通知することにより、処理判断部１１０がユーザの注意を喚起するために用いる例えばＬＥＤとは別の、表示画面等に、現在のバリューの値や「定期区間内での改札処理がされました」等の情報を表示するようにしても構わない。なお、携帯端末のアプリ１５４により処理結果情報を表示するために用いる表示画面等を、処理判断部１１０がユーザの注意を喚起するために用いる表示部１５０と同じにすることも可能であるが、その場合でも、ユーザの注意を喚起するための表示は表示画面等の全体を点滅させるなど、通常の表示よりも目立つものとする。

図３（ｂ）は、定期区間を越える利用の精算処理やポイントを使う処理のように、バリューが消費される処理Ｂが、ＳＥのアプリ１１２（改札アプリやポイントアプリ）とサービス端末のアプリ１２８との間の非接触通信により行われた場合を示している。ＳＥの処理判断部１１０は、バリューの値の変化もしくはアプリ１１２の処理の種類を監視することにより、バリューを消費する処理が行われたことを検出し、接触Ｉ／Ｆ１０８及び１４６を介して、携帯端末の表示部１５０（例えばＬＥＤ）に対する指示を送り、ユーザの注意を喚起する。なお、これに加えて、携帯端末のアプリ１５４に対してＳＥのアプリ１１２が、処理Ｂの結果情報を通知することにより、携帯端末の表示画面等に、現在のバリューの値や「定期区間外での精算処理のため、３４０円が引かれました」等の情報を表示するようにしても構わない。

図４（ａ）及び（ｂ）は、処理判断部の実装のバリエーションを示す。図３（ａ）及び（ｂ）は、図４（ａ）のように制御部１０２が処理判断部１１０を含む実装をした場合を例にとり説明したが、図４（ｂ）のようにＳＥのアプリケーション１１２が処理判断部１１６を含む実装をした場合でも、ＳＥ、サービス端末、及び携帯端末の三者間での連携通信は同様に実現できる。

図４（ａ）では、処理判断部１１０が、ＳＥ内の個々のアプリと独立して存在し、これらのアプリを共通に監視できるように、実装されていることにより、異なるサービスを行う新規アプリ１１４の追加を、ユーザの注意を喚起する通知の一貫性を保ちつつ簡単に実現することができる。すなわち、新規アプリ１１４がサービス端末のアプリ１３０と非接触通信することにより処理Ｃが行われ、これがバリューを消費する処理であった場合には、処理判断部１１０が、アプリ１１２の処理Ｂが行われた場合にバリューが消費されたことを検出したのと同様に、バリューの消費を検出して、携帯端末の表示部１５０への通知を行なう。

これにより、あるアプリ１１２でのバリュー消費処理についても、別のアプリ１１４でのバリュー消費処理についても、一貫した注意喚起がなされるため、ユーザは混乱しなくて済む。そして、新規アプリ１１４が既に実装されたアプリ１１２と同一のバリューを扱うものであれば（例えばアプリ１１２が改札アプリで、新規アプリが同じ鉄道の乗車券購入アプリであるなど）、処理判断部１１０は、そのままでも新規アプリ１１４についての監視、判断を行なうことができる。新規アプリ１１４がアプリ１１２と異なるバリューを扱うものであっても（例えばアプリ１１２が改札アプリで、新規アプリがその鉄道とは関係の無いポイントアプリであるなど）、これらのアプリが処理を行なう際には制御部１０２が提供する共通のライブラリを使用するものであり、処理判断部１１０が各アプリの用いたライブラリの種類を検出するものであれば、この処理判断部１１０はそのままで新規アプリ１１４についての監視、判断を行なうことができる。処理判断部１１０がバリューの値の変化を検出するものであれば、新規アプリ１１４を追加する際に、処理判断部１１０に、新規アプリ１１４が扱う新たなバリューの読み出し方法を指示し、各アプリに対応したバリューの値を読み出せるようにすれば、処理判断部１１０は、アプリ１１２についても新規アプリ１１４についても監視、判断ができるようになる。

一方、図４（ｂ）では、処理判断部１１６、１１８は、それぞれのアプリケーション１１２、１１４内に実装されている。処理判断部１１６が、アプリ１１２の処理Ｂが行われた場合にバリューが消費されたことを検出し、携帯端末の表示部１５０への通知を行なうものである場合に、ユーザに対する通知の一貫性を保つためには、新規アプリ１１４に、次の機能を有する処理判断部１１８が実装される。すなわち、処理判断部１１８は、新規アプリ１１４がサービス端末のアプリ１３０と非接触通信することにより処理Ｃが行われ、これがバリューを消費する処理であった場合には、携帯端末の表示部１５０への通知を処理判断部１１６と同様に行なう。図４（ｂ）の方式では、処理判断部の機能を実装していない新規アプリを追加するとバリューを消費する処理をしても通知が行われず、アプリによって通知されたりされなかったりするためユーザが混乱する可能性がある。そして、これを防ぐためには、図４（ｂ）の方式ではアプリ毎に処理判断部の機能を実装することになり、重複開発がデメリットとなる場合がある。但し、本例のように単純にバリューが消費されたか否かを判断するだけではなく、各アプリケーションに特化してそれぞれ異なる判断手法をとる場合（詳細後述）など、処理判断部を共通化するよりも、アプリケーション毎に実装した方が好ましい場合もあり得る。

図５には、上述した処理判断部１１０を備えた制御部１０２の動作を、改札アプリを例にとり説明する。まず、ユーザがＳＥを搭載した携帯端末をサービス端末にかざすと、ＳＥの制御部１０２は、そのサービス端末がある鉄道の改札に設置されたものであることを知り、そのサービスに対応する改札アプリ（例えばアプリ１１２）を起動する（Ｓ５０１）。そして、サービス端末との非接触通信により改札処理命令を受信し（Ｓ５０３）、この命令に従って改札処理（例えば乗車駅と定期券データをサービス端末へ送信し、これに応答してサービス端末から返信される精算金額をＳＥ内のその鉄道用のバリューから減算する等）を行なう（Ｓ５０５）。上記改札処理命令の受信と改札処理は、制御部１０２の制御の下でアプリ１１２により行なわれ、これによりＳＥ内のバリューの値が減らされたか否かを、処理判断部１１０が判断する（Ｓ５０７）。減算と判断した場合は、携帯端末のＬＥＤ等を点灯してユーザの注意を喚起し（Ｓ５０９）、減算でないと判断した場合は、何もせずに、改札処理を終了する（Ｓ５１３）。いずれの判断をした場合も、改札処理終了の前に、オプショナルで、改札結果を携帯端末の表示画面等に表示するようにしても構わない（Ｓ５１１）。

図５には、バリューを消費する処理であれば常にユーザの注意喚起のための通知を行なう例を示したが、それでも通知回数が多く煩わしいと感じられる場合には、真に通知が必要と推測されるときに絞って、通知を行なうようにすることが可能である。どのようなときに真に通知が必要かは、アプリケーションの性質等によって異なり、サービス提供事業者等により又はユーザ自身により設定することになるが、種々の設定の例を以下に説明する。

まず、同じくバリューを消費した場合であっても、バリューの減算の額が大きい（例えば５００円を超える）ときには携帯端末の表示部を点灯させるが、減算の額が小さい（例えば５００円以下）ときには消灯したままとするという判断手法があり得る。また、同じくバリューを消費した場合であっても、バリューの総額に対する減算額の割合が大きい（例えば５０００円の残額に対し５０１円以上の減算、すなわち１０％を超える）ときには携帯端末の表示部を点灯させるが、減算の割合が小さい（例えば１０％以下）ときには消灯したままとするという判断手法もあり得る。このような手法における、閾値となる減算の額や割合は、複数のアプリで共通としても良いし、アプリ毎に異なるものを設定しても良い。

そして、バリューの残高を閾値以下に下げる処理であった場合には携帯端末の表示部を点灯させるが、そうでない場合には消灯したままとするという判断手法もある。図６には、この判断手法を採る処理判断部１１０を備えた制御部１０２の動作を、改札アプリを例にとり説明する。判断の基準となる閾値は、例えば図７（ａ）に示されるように処理判断部１１０により保持され、これらの数値は、ユーザがサービス毎又は処理毎に設定することとしても良いし、サービス提供事業者等が予め設定しておくこととしても良い。なお、図７（ａ）に示す閾値管理表は、ＴＬＶ構造のデータとして保持されていても良い。

ユーザがＳＥを搭載した携帯端末をサービス端末にかざすと、ＳＥの制御部１０２は、そのサービス端末がある鉄道の改札に設置されたものであることを知り、そのサービスに対応するＡ鉄道用の改札アプリ（例えばアプリ１１２）を起動する（Ｓ６０１）。そして、サービス端末との非接触通信により改札処理命令を受信し（Ｓ６０３）、この命令に従って改札処理（例えば乗車駅と定期券データをサービス端末へ送信し、これに応答してサービス端末から返信される精算金額をＳＥ内のその鉄道用のバリューから減算する等）を行なう（Ｓ６０５）。

ここで、処理判断部１１０は、現在動作中のアプリがＡ鉄道用の改札アプリであることを知っており、上記改札処理命令の受信により、現在の処理が改札出場時のものであることを知るので、これらの情報に基づいて図７（ａ）の閾値管理表を参照すると、閾値として１５０円が得られる（Ｓ６０７）。一方、例えば、現在動作中のアプリがＢ鉄道用の改札アプリであり、上記改札処理命令が最低乗車運賃をＳＥ内のバリューから減算する命令であれば、現在の処理は改札入場時のものであるから、これらの情報に基づいて図７（ａ）の閾値管理表を参照すると、閾値として１２０円が得られる。これらの閾値は、例えば、ＳＥ内の電子マネーを増額するチャージ処理を行なってバリューの値を増加させておかないと、次回に残高不足で同種のサービス端末を利用できない事態になることを、前もってユーザに知らせることができるように、設定される。この例では、改札出場時（降車時）の閾値は、次に同じ鉄道に入場（乗車）するときに必要となる最低乗車運賃に基づいて、改札入場時（乗車時）に設定される閾値は、降車するときに必要となる追加運賃を適当に予測した値に基づいて、設定すればよい。

さて、上記改札処理は、制御部１０２の制御の下でアプリ１１２により行なわれるが、これによりＳＥ内のバリューの残高が、上記のように設定された閾値を下回ったか否かを、処理判断部１１０が判断する（Ｓ６０９）。閾値を下回ったと判断した場合は、携帯端末のＬＥＤ等を点灯してユーザの注意を喚起し（Ｓ６１１）、下回っていないと判断した場合は、何もせずに、改札処理を終了する（Ｓ６１５）。いずれの判断をした場合も、改札処理終了の前に、オプショナルで、改札結果を携帯端末の表示画面等に表示するようにしても構わない（Ｓ６１３）。

また、閾値を下回ったと判断した場合は、上記のようにユーザの注意を喚起するとともに、改札処理終了時に自動的にオンラインチャージアプリを起動して（Ｓ６１５）、ユーザがすぐに必要なチャージ処理を行なえるようにしてもよい。チャージ処理は、チャージを行なうサービス端末とＳＥとの非接触通信によっても行なえるが、ＳＥが携帯端末の通信部１４８を介し遠隔の例えば銀行サービス端末と通信することによっても行なえ、後者をオンラインでのチャージ処理と言う。

また、図７（ａ）に例示された閾値は、鉄道運賃の改定により変更の必要が生じる可能性があるが、料金改定後に初めてその鉄道のサービス端末と非接触通信を行なったＳＥに対して、例えば改定された最低乗車運賃等のデータを、非接触Ｉ／Ｆ１２６及び１０６を介して送信することにより、ＳＥ内で自動的に変更することも可能である。

また、判断の基準となる閾値を、ユーザにカスタマイズされた値となるように動的に算出する（Ｓ６０７）ことも可能である。この場合に、算出されたデータもしくは算出の基礎となるデータの例を、図７（ｂ）に示す。図７（ｂ）のうち、平均消費バリューと高頻度乗降区間のデータは、処理判断部１１０により作成、保持されるものであり、定期券データは、改札アプリによりＳＥのメモリ１０４にセキュアに保持されているものを処理判断部１１０が参照するものである。

一つの例は、ユーザのバリュー消費傾向を管理テーブルとして保持しておき、閾値を動的に更新するものである。例えば、図７（ｂ）で平均消費バリューとして示すように、曜日、時間帯毎にバリュー消費額の平均値を保持する。このデータは、例えば、ユーザの降車時にサービス端末で改札出場処理を行なう度に、そこで得られる日時の情報と消費されたバリューの額の情報とをＳＥ内に記憶し、記憶された消費額の過去数週間もしくは数ヶ月間の平均値を曜日、時間帯毎に計算することにより、求められる。なお、改札出場処理の際に消費されるバリューは、追加運賃の額であるが、これと入場処理時に引かれる最低乗車運賃とを足した乗降区間の料金を、代わりに記憶しても良い。そして、図６に従って動作する処理判断部１１０は、改札アプリを起動した日時に基づいて、該当する曜日、時間帯のバリュー消費額の平均値を読み出し、読み出した数値に基づいて判断の基準となる閾値を設定することができる。なお、現在の処理が改札出場処理の場合は、図７（ａ）を参照して、同じ鉄道の最低乗車運賃に基づく閾値を設定し、現在の処理が改札入場処理の場合に、図７（ｂ）を参照して、降車時に必要になる可能性の高い追加運賃に基づく閾値を設定するようにしても良い。

また、図７（ｂ）で高頻度乗降区間として示すように、複数回乗降車した駅の組と必要額の上位数個のデータを保持しておいても良い。このデータは、例えば、ユーザの降車時にサービス端末で改札出場処理を行なう度に、そこで得られる乗車駅及び降車駅の情報をＳＥ内に記憶し、過去数週間もしくは数ヶ月間、同じ乗車駅及び降車駅の組が何度記憶されたかをカウントすることにより、求められる。なお、乗降車した駅の組に対応する必要運賃の額として、該当する乗降車をしたときの改札出場処理の際に消費されたバリュー（追加運賃）の額を記憶しても良いし、これと入場処理時に引かれる最低乗車運賃とを足した乗降区間の料金を記憶しても良いし、後述する運賃データベースを参照して該当する乗降区間の料金を調べても構わない。そして、図６に従って動作する処理判断部１１０は、行なわれた改札処理が入場処理である場合にサービス端末から得られる乗車駅の情報をキーとして、図７（ｂ）の高頻度乗降区間を検索し、一致するものの中で最も高い頻度の区間に対応する必要運賃の額に基づいて、判断の基準となる閾値を設定することができる。

別の例として、その他のＳＥ内部（もしくは携帯端末内部又はオンライン上）の登録データと連携して、閾値を動的に更新するものも挙げられる。例えば、ＳＥのメモリ１０４（もしくは携帯端末のメモリ１４４又は通信部１４８を介してアクセスできる遠隔のデータベースサーバ）に格納された運賃データベースとの連携が可能である。すなわち、図７（ｂ）の定期券情報で示される定期区間と、ＳＥをかざしたサービス端末の設置駅の情報とに基づいて、運賃データベースを参照することにより、定期区間外で入場／出場した場合、その乗車駅／降車駅から定期区間までの額を算出することができる。この額に従って閾値を設定することにより、ユーザは、定期区間から離れた駅を利用する場合にバリューの残額が定期区間まで戻るのに足りるか否かを、一目で知ることができるようになる。

また、ＳＥ内に後述するチケットアプリ又はスケジュール管理アプリが並存する場合、チケットやスケジュールが示す日時及び場所の情報との連携も可能である。なお、スケジュール管理アプリはＥコマースの範囲外のため、ＳＥではなく携帯端末のアプリ１５４として存在しても構わない。また、これらのチケットやスケジュールの情報は、ＳＥではなく携帯端末のメモリ１４４に格納されていても構わない。そして、ＳＥの処理判断部１１０は、改札入場処理を行なったサービス端末から得られる日時をキーとして、チケットやスケジュールの日時及び場所情報を検索し、近い日時のものがあれば対応する場所情報から降車駅を予測し、更に運賃データベースを参照することにより、必要な額を算出することができる。この額に従って閾値を設定することにより、ユーザは、これから向かう駅の改札での出場処理にバリューの残額が足りるか否かを、一目で知ることができるようになる。

以上のように、バリューの減算を行ったことを明確にユーザに通知することにより、気が付かないうちにバリューを使われているかもしれないというユーザの不安を失くすことができ、ユーザがバリューの減算されないはずの処理を意図している場合に減算されれば、おかしな精算であることにすぐに気が付くことができる。また、バリューの残高が閾値以下になったことを明確にユーザに通知しチャージを促すことにより、例えば改札で足止めされるユーザを減らし、改札通過をスムーズにすることができ、さらにユーザにカスタマイズされた閾値によって残高が不足していることを通知するようにすれば、使い勝手が向上する。

以下には、入場・入室処理を行なうサービスにおいて、入場・入室を許可する処理に必須ではない（したがってユーザに意識されない可能性がある）付随的な処理をも行なう場合に、この付随的な処理により、ユーザにとって次の行動の指針となるデータが変更される可能性があるサービスを例にとり、説明する。

例えば、イベント会場の入口や、空港のチェックインカウンター等を通過（入場処理）するためには、事前にチケットを購入していることを示すことが必要である。このため、ＳＥ内にチケットアプリが存在し、その中にチケットデータ（イベント又はフライトの日時、イベント名又は便名、会場の場所又は搭乗空港名などを特定可能な情報）がセキュアに保護された形で格納されている。図８は、このようなチケットによる入場サービスにおいて、本実施形態の処理判断部１１０を備えた制御部１０２が行なう動作例を示す。

まず、ユーザがＳＥを搭載した携帯端末をサービス端末にかざすと、ＳＥの制御部１０２は、そのサービス端末が提供するサービスに対応するチケットアプリ（例えばアプリ１１２）を起動する（Ｓ８０１）。そして、サービス端末との非接触通信によりチケット処理命令を受信し（Ｓ８０３）、この命令に従ってチケット処理（例えばチケットデータをサービス端末へ送信し、これに応答してサービス端末から返信される付随データを受信する等）を行なう（Ｓ８０５）。サービス端末の方は、ＳＥから送信されたチケットデータを基に、そのユーザの入場を許可するか拒絶するかを判断する。サービス端末から返信される付随データには、例えば、ユーザに最終的に割り当てられた席の情報（これを場所の情報と言う）が含まれ、イベントの場合の最終的に確定した演目や出演者の情報、飛行機の場合の最終的に確定した便名の情報（これらを内容の情報と言う）もあり得る。非接触Ｉ／Ｆ１０６を介して受信した付随データは、ＳＥ内のメモリ１０４に書き込んでも良いが、チケットデータのように機密性の高いデータでなければ、接触Ｉ／Ｆ１０８を介して携帯端末のメモリ１４４に書き込んでも構わない。

上記チケット処理命令の受信とチケット処理は、制御部１０２の制御の下でアプリ１１２により行なわれ、これによりＳＥ内又は携帯端末内のメモリに既に（チケット購入時に又はその後適宜に）書き込まれている場所の情報及び内容の情報のいずれかが変更されたか否かを、処理判断部１１０が判断する（Ｓ８０７）。ＳＥ内か携帯端末内のメモリに、場所の情報及び内容の情報のいずれかが書き込まれておらず、チケット処理により初めて書き込まれた場合にも、書き込まれた情報が変更された場合と同様に取り扱う。変更があったと判断した場合は、携帯端末のＬＥＤ等を点灯してユーザの注意を喚起し（Ｓ８０９）、変更がなかったと判断した場合は、何もせずに、チケット処理を終了する（Ｓ８１３）。いずれの判断をした場合も、チケット処理終了の前に、オプショナルで、チケット処理結果（例えばサービス端末からＳＥに返信されてきた付随データ）を携帯端末の表示画面等に表示するようにしても構わない（Ｓ８１１）。

上述した図８のような制御は、チケットによらない入場サービスにも応用できる。例えば、訪問した建物のゲートに設置されたサービス端末に、ＳＥ内にセキュアに格納されたユーザを特定するデータを送信し、訪問が予定されたユーザのみに対して建物へ入ることを許可するサービスが挙げられる。このとき、サービス端末が、入場が許可されたユーザのＳＥへ、そのユーザが出席を予定している会合がその建物内のどの部屋で行なわれるかを示す付随データを返信するものとすれば、処理判断部１１０は、この付随データによりＳＥ内又は携帯端末内のメモリに既に書き込まれている場所の情報が変更される場合には、携帯端末のＬＥＤ等を点灯してユーザの注意を喚起し、変更や新たな情報がない場合には消灯したままとすることができる。

また、例えば、オフィスや工場など、入退室管理が必要な場所の出入口を通過するためには、入室が許可された例えば会社の従業員であることを示すことが必要である。このような状況では、同じアプリケーションで、入退室管理とともに、勤務管理も行なうと便利である。このため、ＳＥ内に勤務管理アプリが存在し、その中に従業員データがセキュアに保護された形で格納されているものとする。図９は、このような従業員カードによる出退勤管理サービスにおいて、本実施形態の処理判断部１１０を備えた制御部１０２が行なう動作例を示す。

まず、ユーザがＳＥを搭載した携帯端末をサービス端末にかざすと、ＳＥの制御部１０２は、そのサービス端末が提供するサービスに対応する勤務管理アプリ（例えばアプリ１１２）を起動する（Ｓ９０１）。そして、サービス端末との非接触通信によりＳＥが送信した従業員データに基づいて、サービス端末により入退室処理や出退勤管理が実行され（Ｓ９０３）、この従業員の当日の確定したスケジュールが、付随データとしてサービス端末からＳＥへ送信される（Ｓ９０５）。処理判断部１１０は、この付随データによりＳＥ内又は携帯端末内のメモリに既に書き込まれているスケジュールの情報（ここでは特に時刻の情報）が変更されたか否かを判断する（Ｓ９０７）。ＳＥ内か携帯端末内のメモリに、時刻の情報が書き込まれておらず、付随データの受信により初めて書き込まれた場合にも、書き込まれた情報が変更された場合と同様に取り扱う。変更があったと判断した場合は、携帯端末のＬＥＤ等を点灯してユーザの注意を喚起し（Ｓ９０９）、変更がなかったと判断した場合は、何もせずに、勤務管理処理を終了する（Ｓ９１３）。いずれの判断をした場合も、勤務管理処理終了の前に、オプショナルで、勤務管理処理結果又は受信した付随データを携帯端末の表示画面等に表示するようにしても構わない（Ｓ９１１）。

上記のように各アプリケーションに応じて判断対象が異なる場合、判断手法も異なるものとして、図４（ｂ）に示したように、アプリ毎に処理判断部を実装しても良いが、この場合でも、図４（ａ）に示したように、共通の処理判断部により実装することも可能である。例えば、処理判断部１１０に、各アプリが扱うデータの読み出し方法（例えばデータの格納場所）を指示しておき、各アプリによる処理前のデータと処理後のデータとを取得できるようにしておけば、最低でも、データが数値の場合には処理前の数値と処理後の数値を比較することにより、バリューの減算処理が行なわれたか否かを判断することができ、データが文字列の場合には処理前の文字列と処理後の文字列を比較することにより、ユーザにとって次の行動の指針となる場所や内容、時刻等の情報が変更されたか否かを判断することができる。

以上説明した実施の形態はあくまで一例であり、本発明は上述した実施の形態に限定されず、種々に変形、応用して実施することができる。例えば、上記では、処理判断部がユーザの注意を喚起すべき変更が行なわれた場合に、ユーザへの通知を携帯端末に指示する例を説明したが、制御部１０２が非接触通信処理終了後に、変更内容に関わらず携帯端末へ何らかのデータ（所定バイトが０であるデータ）を送るように構成し、処理判断部１１０がユーザの注意を喚起すべき変更が行なわれた場合に、携帯端末へ送られる上記データの所定バイトを１に変更するようにしても良い。この場合、携帯端末の制御部１４２がこのデータを受信し、所定バイトが１であれば表示部１５０を用いてユーザへの通知を行ない、０であればユーザへの通知は行なわないように動作する。

以上説明したように、本発明に係るＩＣモジュールは、携帯端末に搭載されて使用され、サービス端末との非接触通信により各種処理を行ない、これにより生じた変更がユーザの注意を喚起すべきものである場合は、携帯端末のユーザインタフェース機能を活用してユーザに明確に通知がなされるので、例えば、電子決済や、入場・入室処理、交通機関の利用精算処理等に有用である。

実施の形態に係るセキュアエレメント（ＳＥ）、サービス端末、及び携帯端末の構成例を示す図 実施の形態に係るＳＥ、サービス端末、及び携帯端末の他の構成例を示す図 処理Ａ（非通知となる処理）の場合のＳＥ、サービス端末、及び携帯端末間の連携通信の様子を示す図 処理Ｂ（通知となる処理）の場合のＳＥ、サービス端末、及び携帯端末間の連携通信の様子を示す図 共通の処理判断部を用いるＳＥにおいて新規アプリケーションが追加されたときの連携通信の様子を示す図 アプリケーション毎の処理判断部を用いるＳＥにおいて新規アプリケーションが追加されたときの連携通信の様子を示す図 バリューの消費に応じてユーザ通知を行なう場合のＳＥの制御部の動作例を示す図 バリューの残高に応じてユーザ通知を行なう場合のＳＥの制御部の動作例を示す図 バリューの残高と比較する閾値の情報を管理するテーブルの例を示す図 バリューの残高と比較する閾値の情報を管理するテーブルの別の例を示す図 場所もしくは内容の変更に応じてユーザ通知を行なう場合のＳＥの制御部の動作例を示す図 時刻の変更に応じてユーザ通知を行なう場合のＳＥの制御部の動作例を示す図

符号の説明

１００、２００ セキュアエレメント（ＳＥ）
１０２ 制御部
１０４ メモリ
１０６ 非接触インタフェース
１０８ 接触インタフェース
１１０、１１６、１１８ 処理判断部
１１２、１１４ アプリケーションプログラム
１２０、２２０ サービス端末
１２２ 制御部
１２４ メモリ
１２６ 非接触インタフェース
１２８、１３０ アプリケーションプログラム
１４０、２４０ 携帯端末
１４２ 制御部
１４４ メモリ
１４６ 接触インタフェース
１４８ 通信部
１５０ 表示部
１５２ 操作部
１５４ アプリケーションプログラム

Claims (20)

1. 携帯端末に搭載されて使用されるＩＣモジュールであって、
   所定の場所に設置されたサービス端末との非接触通信により前記サービス端末が提供するサービスに関する処理を行なう手段と、
   前記サービスに関する状態のデータを保持する手段と、
   前記処理により前記状態のデータについてユーザに確認を要求することなく行なわれた変更が、ユーザの注意を喚起すべきとして設定された条件を満たすか否かを判断し、満たすとの判断に応じて、前記携帯端末が備えるユーザインタフェース機能に対し、ユーザへの通知を指示する手段とを具備することを特徴とするＩＣモジュール。
2. 前記処理に係わるデータのうち所定のデータ及び前記処理を行なうためのプログラムに対し、前記サービスに関して正当な権限を有する端末以外からのアクセスがされないよう制御する手段を更に具備したことを特徴とする請求項１に記載のＩＣモジュール。
3. 請求項１に記載のＩＣモジュールを備え、前記携帯端末に着脱可能であることを特徴とするＩＣカード。
4. 前記非接触通信を行なうためのインタフェースを更に備えたことを特徴とする請求項３に記載のＩＣカード。
5. 請求項１に記載のＩＣモジュールと、前記ユーザインタフェース機能とを備えることを特徴とする携帯端末。
6. 前記ＩＣモジュールと前記サービス端末とが前記非接触通信を行なうためのインタフェースを更に備えたことを特徴とする請求項５に記載の携帯端末。
7. 複数のアプリケーションプログラムを記憶する手段を更に備え、
   前記サービスに関する処理は、前記複数のアプリケーションプログラムのうちの一つにより行なわれ、
   前記処理により前記状態のデータについて行なわれた変更についての判断及びユーザへの通知の指示は、前記複数のアプリケーションプログラムとは別のプログラムであって前記複数のアプリケーションプログラムの各処理による変更を共通に検出可能に構成されたプログラムにより行なわれることを特徴とする請求項１に記載のＩＣモジュール。
8. 前記状態のデータは、ユーザが現在所有する金銭的な価値のデータであり、前記金銭的な価値を減少させる処理が行なわれたか否かに応じて、前記設定された条件を満たすか否かを判断することを特徴とする請求項１に記載のＩＣモジュール。
9. 前記状態のデータは、ユーザが現在所有する金銭的な価値のデータであり、前記処理の結果前記金銭的な価値が閾値以下となったか否かに応じて、前記設定された条件を満たすか否かを判断することを特徴とする請求項１に記載のＩＣモジュール。
10. 前記サービスを利用するための料金に関する情報を前記サービス端末との非接触通信により受信する手段を更に備え、
    受信した前記料金に関する情報に基づいて前記閾値が設定されることを特徴とする請求項９に記載のＩＣモジュール。
11. 前記所定の場所は、交通機関への乗降時にユーザが通過する場所であり、
    ユーザが前記交通機関を前記所定の場所を通過した後に利用するために必要となる金額を予測する手段を更に備え、
    予測した前記金額に基づいて前記閾値が設定されることを特徴とする請求項９に記載のＩＣモジュール。
12. 前記交通機関の種類、ユーザが前記交通機関へ乗車した場所、ユーザが前記交通機関から降車した場所、ユーザが前記交通機関を利用した曜日、ユーザが前記交通機関を利用した時間、ユーザが前記交通機関を利用した際に消費した金銭的価値、及び前記交通機関においてユーザが所有する定期乗車券の情報のうち、少なくとも一つに基づいて、前記金額の予測を行なうことを特徴とする請求項１１に記載のＩＣモジュール。
13. 前記交通機関の運賃に関するデータを取得する手段を更に備え、
    ユーザが通過した前記所定の場所が前記ユーザの所有する定期乗車券の区間外である場合に、前記運賃に関するデータに基づいて、ユーザが通過した前記所定の場所から前記定期乗車券の区間内の場所までの額を算出することにより、前記金額の予測を行なうことを特徴とする請求項１１に記載のＩＣモジュール。
14. 前記交通機関の運賃に関するデータとユーザが前記所定の場所を通過した後に向かうべき場所に関するデータとを取得する手段を更に備え、
    前記所定の場所からの前記運賃に関するデータに基づいて、前記向かうべき場所に関するデータにより前記ユーザが前記交通機関から降車すると予想される場所までの額を算出することにより、前記金額の予測を行なうことを特徴とする請求項１１に記載のＩＣモジュール。
15. 前記状態のデータは、ユーザが前記所定の場所を通過した後に行くべき場所を示すデータであり、前記処理の結果前記行くべき場所が新たに決定もしくは変更されたか否かに応じて、前記設定された条件を満たすか否かを判断することを特徴とする請求項１に記載のＩＣモジュール。
16. 前記状態のデータは、ユーザが前記所定の場所を通過した後の行動予定についてのデータであり、前記処理の結果前記行動予定の時刻が新たに決定もしくは変更されたか否かに応じて、前記設定された条件を満たすか否かを判断することを特徴とする請求項１に記載のＩＣモジュール。
17. 前記状態のデータは、ユーザが前記所定の場所を通過した後に予定されているイベントについてのデータであり、前記処理の結果前記イベントの内容が新たに決定もしくは変更されたか否かに応じて、前記設定された条件を満たすか否かを判断することを特徴とする請求項１に記載のＩＣモジュール。
18. 携帯端末に搭載されて使用されるＩＣモジュール内で実行されるサービス処理方法であって、
    所定の場所に設置されたサービス端末との非接触通信により前記サービス端末が提供するサービスに関する処理を行ない、
    前記処理により前記ＩＣモジュール内に保持している前記サービスに関する状態のデータを変更し、
    前記状態のデータについてユーザに確認を要求することなく行なわれた変更が、ユーザの注意を喚起すべきとして設定された条件を満たすか否かを判断し、
    前記条件を満たすとの判断に応じて、前記携帯端末が備えるユーザインタフェース機能に対し、ユーザへの通知を指示することを特徴とするサービス処理方法。
19. 前記所定の場所は、交通機関への乗降時にユーザが通過する場所であり、
    前記状態のデータは、ユーザが現在所有する金銭的な価値のデータであり、
    ユーザが前記交通機関を前記所定の場所を通過した後に利用するために必要となる金額を予測し、
    予測した前記金額に基づき、前記金銭的な価値がユーザの注意を喚起すべき程度まで減少したか否かを判断するための閾値を、前記条件として設定することを特徴とする請求項１８記載のサービス処理方法。
20. 携帯端末に搭載されて使用されるＩＣモジュール内のメモリに格納されてサービス処理を実行するためのプログラムであって、
    所定の場所に設置されたサービス端末との非接触通信により前記サービス端末が提供するサービスに関する処理を行ない、
    前記ＩＣモジュール内のメモリに前記サービスに関する状態のデータを書き込み、
    前記処理により前記状態のデータについてユーザに確認を要求することなく行なわれた変更が、ユーザの注意を喚起すべきとして設定された条件を満たすか否かを判断し、
    前記条件を満たすとの判断に応じて、前記携帯端末が備えるユーザインタフェース機能に対し、ユーザへの通知を指示するためのプログラム。
    
    
    

Images