【手続補正書】
【提出日】平成25年6月19日(2013.6.19)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００３０
【補正方法】変更
【補正の内容】
【００３０】
【図１】従来の携帯電話機におけるサービスの移行について説明するための図である。
【図２】ＵＩＣＣを用いたときのサービスの移行について説明するための図である。
【図３】ＵＩＣＣにおけるサービスの登録について説明するための図である。
【図４】ビューワの処理で表示される画面の一例を示す図である。
【図５】本発明を適用したシステムの一実施の形態の構成を示す図である。
【図６】ＩＣカードの内部構成を示す図である。
【図７】通信路について説明するための図である。
【図８】通信路について説明するための図である。
【図９】通信路について説明するための図である。
【図１０】通信方式、パケット、コマンドの関係について説明するための図である。
【図１１】各通信方式における階層について説明するための図である。
【図１２】サービス名の表示例を示す図である。
【図１３】サービスについて説明するための図である。
【図１４】サービスとサービス名の登録について説明するための図である。
【図１５】リーダライタの機能について説明するための図である。
【図１６】通信方式の決定処理を説明するためのフローチャートである。
【図１７】通信方式の決定処理を説明するためのフローチャートである。
【図１８】通信方式の決定処理を説明するためのフローチャートである。
【図１９】通信方式の決定処理を説明するためのフローチャートである。
【図２０】通信方式の決定処理を説明するためのフローチャートである。
【図２１】通信方式の決定処理を説明するためのフローチャートである。
【図２２】通信方式の決定処理を説明するためのフローチャートである。
【図２３】通信方式の決定処理を説明するためのフローチャートである。
【図２４】通信方式の決定処理を説明するためのフローチャートである。
【図２５】通信方式、パケット、コマンドの関係について説明するための図である。
【図２６】サービスとサービス名の登録について説明するためのフローチャートである。
【図２７】サービスとサービス名の登録について説明するためのフローチャートである。
【図２８】サービスとサービス名の登録について説明するためのフローチャートである。
【図２９】サービスとサービス名の登録について説明するためのフローチャートである。
【図３０】アプリケーションマネージャについて説明するための図である。
【図３１】サービスとサービス名の登録について説明するためのフローチャートである。
【図３２】サービスとサービス名の登録について説明するためのフローチャートである。
【図３３】サービス名の表示例を示す図である。
【図３４】サービス名の表示例を示す図である。
【図３５】記録媒体について説明するための図である。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００３６
【補正方法】変更
【補正の内容】
【００３６】
また例えば、第３アプリケーション２５６は、総合サービスを提供するためのアプリケーションである。後述するように、第３アプリケーション２５６は、クレジットの機能を実現するサービス、トランスポート系のサービス、クーポンを提供するサービスなど、複数のサービスを提供するためのアプリケーションである。図６には図示していないが、図１４を参照して後述するように、ＵＩＣＣ２２２にサービスが追加で登録されることがあり、ＵＩＣＣ２２２は、登録されたサービスを記憶し、管理する機能も有する。各アプリケーションは、アプリケーションマネージャ２５２によって、管理されるものであるが、同じ実行環境で管理される事に限定されない。一例として、アプリケーションマネージャ２５２がＪａｖａＣａｒｄＴＭを搭載し、１つのアプリケーションがソフトウェアにより実現されていても、他のアプリケーションが、ＲＯＭの工場出荷時に書き込まれている場合や、別チップとして提供される場合もあり得る。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００４１
【補正方法】変更
【補正の内容】
【００４１】
通信路３０１と通信路３０２の違いは、それぞれ異なるコマンドフォーマットによるものである。通信路３０１で第１アプリケーション２５４に送信されるのは、第１アプリケーション２５４の通信プロトコルに対応した独自のコマンドフォーマットである。リーダライタ２０２とＣＬＦ２２４の間で、第１アプリケーション２５４対応するプロトコルによって通信を行い、ＣＬＦ２２４からＵＩＣＣハードウェア２５１には、通信で取得した独自のコマンドが渡される。また、通信路３０２で第１アプリケーション２５４に送信されるのは、通信プロトコルに対応した汎用のコマンドフォーマットである。リーダライタ２０２とＣＬＦ２２４の間で、第１アプリケーション２５４に対応するプロトコルによって通信を行い、ＣＬＦ２２４からＵＩＣＣハードウェア２５１には、通信で取得した汎用のコマンドフォーマットに準拠したコマンドが渡される。つまり、流れるコマンドフォーマットによって、アプリケーションマネージャ２５２を経由せずに第１アプリケーションに行く通信路３０１と、経由して第１アプリケーションに行く通信路３０２がある。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００４９
【補正方法】変更
【補正の内容】
【００４９】
第１アプリケーション２５４と同じく、この第３アプリケーション２５６における通信路３５１と通信路３５２の違いも、それぞれ異なるコマンドフォーマットによるものである。リーダライタ２０２とＣＬＦ２２４の間で、第３アプリケーション２５６に対応するプロトコルによって通信を行い、ＣＬＦ２２４からＵＩＣＣハードウェア２５１には、通信で取得した第３アプリケーション２５６独自のコマンドが渡される。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００５０
【補正方法】変更
【補正の内容】
【００５０】
通信路３５１で第３アプリケーション２５６に送信されるのは、第３アプリケーション２５６の通信プロトコルに対応した独自のコマンドフォーマットである。また、通信路３５２で第３アプリケーション２５６に送信されるのは、汎用のプロトコルに対応したコマンドフォーマットである。リーダライタ２０２とＣＬＦ２２４の間で、第３アプリケーション２５６に対応するプロトコルによって通信を行い、ＣＬＦ２２４からＵＩＣＣハードウェア２５１には、通信で取得した汎用のコマンドフォーマットに準拠したコマンドが渡される。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００６７
【補正方法】変更
【補正の内容】
【００６７】
第３通信方式（Type F）は、送信可能パケットとしてFeliCa(商標)パケットと、FeliCaパケット上にさらに汎用パケットを載せたものがある。FeliCaパケットは、第３アプリケーション２５６の独自のパケットである。よってリーダライタ２０２から、このFeliCa パケットが送信された場合、CLF２２４で抜き出されたFeliCaコマンドがCLF２２４から第３アプリケーション２５６へと供給される。このFeliCa パケットは、FeliCa コマンドを送受信する目的で用いられる。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００７６
【補正方法】変更
【補正の内容】
【００７６】
第２アプリケーション２５５に対応する第２通信方式は、初期化／衝突防止層として、ＩＳＯ １４４４３−３ Type B規格に対応している。また第２通信方式は、パケット層として、ＩＳＯ １４４４３−４規格の汎用パケットに対応している。そして、Type Bのコマンド層は、パケット層のＩＳＯ １４４４３−４規格の汎用パケットに対応するコマンド層として、ＩＳＯ ７８１６−４に準拠したＡＰＤＵコマンドフォーマットに対応している。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】０１１５
【補正方法】変更
【補正の内容】
【０１１５】
図１８乃至図２４のフローチャートを参照して説明する決定処理は、基本的な処理の流れは同じであり、まず複数の通信方式のうちの１つの通信方式が選択され、その通信方式でＵＩＣＣ２２２と通信が可能であるか否かが判断される。そして、通信できないと判断されたときには、他の通信方式が選択し直されて、再度、ＵＩＣＣ２２２との通信が試される。そして、選択された通信方式で通信が可能となった時点で、その通信が可能となった通信方式を選択するという処理である。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】０１５３
【補正方法】変更
【補正の内容】
【０１５３】
一方、ステップＳ１１５において、第２通信方式の利用は可能ではないと判断された場合、ステップＳ１１９に処理が進められる。この場合、第１通信方式、第２通信方式、および第３通信方式の全ての通信方式で通信が行えない、換言すれば、リーダライタ２０２がサポートしている通信方式でＣＬＦ２２４と通信を行うことができないと判断されたときであるので、ステップＳ１１９において、通信不可と判断される。
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】０１９３
【補正方法】変更
【補正の内容】
【０１９３】
一方、ステップＳ２６５において、第２通信方式の利用は可能ではないと判断された場合、ステップＳ２６９に処理が進められる。この場合、第１通信方式、第２通信方式、および第３通信方式の全ての通信方式で通信が行えない、換言すれば、リーダライタ２０２がサポートしている通信方式でＣＬＦ２２４と通信を行うことができないと判断されたときであるので、ステップＳ２６９において、通信不可と判断される。
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】０２２４
【補正方法】変更
【補正の内容】
【０２２４】
例えばユーザが第１通信方式を選択した場合、図１８のフローチャートに示した第２の決定処理が開始されるようにしても良いし、図１９のフローチャートに示した第３の決定処理が開始されるようにしても良い。また、この場合、図２４のフローチャートに示した第８の決定処理において、第１通信方式が一番始めに利用可能であるか否かが判断される決定処理が実行されるようにしても良い。
【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】０２３６
【補正方法】変更
【補正の内容】
【０２３６】
番号３の組み合わせで利用される通信方式は、第１通信方式と第３通信方式の組み合わせか、第２通信方式と第３通信方式との組み合わせである。番号３の組み合わせは、上記した第５乃至第８の組み合わせに該当する。番号３の組み合わせにおいては、ＡＰＤＵコマンドフォーマットと第３パケットの送受信が可能であるため、サービスの登録やサービス名の登録は、ＡＰＤＵコマンドフォーマットと第３パケットが用いられる。
【手続補正１３】
【補正対象書類名】明細書
【補正対象項目名】０２９６
【補正方法】変更
【補正の内容】
【０２９６】
その処理の結果、第２通信方式で通信が行える状態にされると、ステップＳ１００５において、リーダライタ２０２は、携帯電話機２０１（ＣＬＦ２２４）に対して、データの読み出しの要求を出す。携帯電話機２０１（ＣＬＦ２２４）は、リーダライタ２０２からのデータの読み出しの要求を、ステップＳ１１１６において受信すると、その要求を、アプリケーションマネージャ６０１に転送する。
【手続補正１４】
【補正対象書類名】明細書
【補正対象項目名】０３１０
【補正方法】変更
【補正の内容】
【０３１０】
図９を再度参照する。第３アプリケーション２５６の通信プロトコルのパケットしか送受信できない場合、通信路３５１により、独自のパケットの送受信がされることになる。すなわち、リーダライタ２０２からの第３パケットは、ＣＬＦ２２４により受信され、ＣＬＦ２２４からＵＩＣＣハードウェア２５１を経由して第３アプリケーション２５６へと供給される。よって、第３アプリケーション２５６にはアクセスできるため、第３アプリケーション２５６で提供される第３−１サービス２５７を登録することはできる。
【手続補正１５】
【補正対象書類名】図面
【補正対象項目名】図７
【補正方法】変更
【補正の内容】
【図７】
2012010207.tif 000001
【手続補正１６】
【補正対象書類名】図面
【補正対象項目名】図８
【補正方法】変更
【補正の内容】
【図８】
2012010207.tif 000002
【手続補正１７】
【補正対象書類名】図面
【補正対象項目名】図９
【補正方法】変更
【補正の内容】
【図９】
2012010207.tif 000003
【手続補正１８】
【補正対象書類名】図面
【補正対象項目名】図２２
【補正方法】変更
【補正の内容】
【図２２】
2012010207.tif 000004