JP2014197395A - 通信装置および方法、並びにプログラム - Google Patents

Abstract

【課題】サービスとそのサービスの名称を登録し、そのサービス名が、ビューワから閲覧できるようにする。【解決手段】サービスを登録するとき、リーダライタ２０２から、第３アプリケーション２５６独自の通信方式で、登録されるサービスのデータが送信される。そのデータは、通信路３５１で第３アプリケーション２５６に供給される。登録されたサービスに対応するサービス名に関する情報が、通信路３５２でアプリケーションマネージャ２５２に供給される。アプリケーションマネージャ２５２は、供給されたデータに基づき、レジストリ２５３に、サービス名を登録する。本発明は、ＩＣカードと非接触で通信を行うリーダライタに適用できる。【選択図】図９

Description

本発明は通信装置および方法、並びにプログラムに関し、特に、複数の通信プロトコルに対応するチップやカードなどで管理されているデータを更新する際などに用いて好適な通信装置および方法、並びにプログラムに関する。

携帯電話機が普及し、携帯電話機でさまざまなサービスが提供されている。図１Ａを参照するに、携帯電話機１１には、チップ１２が組み込まれており、このチップ１２に、サービス１３−１やサービス１３−２が書き込まれている。また、サービス１３−１をユーザに提供する際の処理は、アプリケーション１４−１が行い、サービス１３−２をユーザに提供する際の処理は、アプリケーション１４−２が行うように構成されている。

アプリケーションは、携帯電話機上のソフトウェアに書き込まれる一連の実行可能なモジュールであり、チップ上に書き込まれるサービスとは異なる。携帯電話機には、非特許文献１に示すＭＩＤＰ ２．０仕様に準拠した製品であればアプリケーション管理ソフト（AMS: Application Management Software）が、非特許文献２に示すＭＩＤＰ １．０仕様に準拠した製品であれば同様の機能を持つＪＡＭ（Java（登録商標） Application Manager）が搭載されており、携帯電話に搭載されるアプリケーションの管理を行っている。ここでの管理とは、アプリケーションのダウンロード、インストール、削除といった一連の状態遷移を保持していることを指す。

アプリケーション管理ソフト１５は、まず、アプリケーション１４−１が携帯電話機にインストールされた事を管理し、さらにアプリケーションがサービス１３−１をチップ内に生成した際には、その情報も関連付けて管理する。同様にアプリケーション１４−２がインストールされた後にサービス１３−２をチップ内に生成した場合、その情報について関連付けを行う。例えば、アプリケーション管理ソフト１５は、アプリケーション１４−２を削除する場合、関連付けられているサービス１３−２を事前に削除する処理を必要とする。

ここで図１Ｂに示すように、ユーザが携帯電話機１１から携帯電話機３１に変えるときを考える。例えば、携帯電話機３１を購入する際、その購入した店で、携帯電話機１１から携帯電話機３１へのデータの移行のサービスが行われる。携帯電話機１１のチップ１２に記憶されているサービス１３−１やサービス１３−２（以下、個々にサービス１３−１，１３−２を区別する必要がない場合、単にサービス１３と記述する。他も同様の記述とする）は、携帯電話機３１のチップ３２に移行される。また、アプリケーション管理ソフト１５の情報も、アプリケーション管理ソフト３３に移行される。しかしながら、チップ１２で管理されていない携帯電話機上のアプリケーション１４は、携帯電話機３１に移行されない。

携帯電話機３１のアプリケーション管理ソフト３３は、チップ３２に記憶されているサービス１３があるが、それに対応するアプリケーション１４がないと、ユーザにサービス１３に対応するアプリケーション１４をダウンロードするように指示するメッセージを携帯電話機３１のディスプレイ上に表示させる。ユーザが、そのメッセージに対する処理として、アプリケーション１４をダウンロードすることで、新しい携帯電話機３１でも、サービス１３を利用できる状態となる。

Mobile Information Device Profile FOR Java TM 2 Micro Edition(JSR118) Mobile Information Device Profile (JSR-37) JCP Specification Java 2 Platform, Micro Edition, 1.0a

上記したように、現状、チップ１２でサービス１３が管理され、アプリケーション管理ソフト１５（３３）でアプリケーション１４との対応付けなどが行われているが、サービス１３をＵＩＣＣ（Universal Integrated Circuit Card)に記憶して管理することが考えられる。図２Ａに示すように、携帯電話機１１のＵＩＣＣ５１にサービス１３が記憶されている状態のとき、携帯電話機１１からＵＩＣＣ５１が外され、別の携帯電話機３１に、そのＵＩＣＣ５１が装着されると、携帯電話機３１でサービス１３が利用できるようになることが好ましい。

この場合、ＵＩＣＣ５１に記憶されているサービス１３などは、差し込まれた携帯電話機３１側に移行されることになるが、アプリケーション管理ソフト１５の情報は、アプリケーション管理ソフト３３には移行されない。その結果、アプリケーション管理ソフト１５で行われていた処理を、アプリケーション管理ソフト３３で行うことができず、結果として、ＵＩＣＣ５１に記憶されているサービス１３が利用できない可能性がある。

そこで、図２Ｂに示すように、携帯電話機１１に、ビューワ（Viewer）７１を設けることが考えられる。このビューワ７１は、各携帯電話機が備え、ＵＩＣＣ５１が管理しているサービスなどを閲覧できるように構成される。例えば、携帯電話機１１に装着されていたＵＩＣＣ５１が外されて、携帯電話機３１に装着された場合、携帯電話機３１もビューワ７１を備えているため、そのビューワ７１により、ＵＩＣＣ５１で管理されているサービスを閲覧することができる。

また例えば、サービス１３は管理されているが、そのサービス１３に対応付けられるアプリケーションがなかった場合、アプリケーションのダウンロードをユーザに促すメッセージを表示させるような機能を、ビューワ７１に持たせることも考えられる。

ＵＩＣＣ５１は、例えば、図３に示すような構成とされている。ＵＩＣＣハードウェア１０１の上に、ＵＩＣＣ内のアプリケーションマネージャ１０２があり、この上に、アプリケーション１０３、アプリケーション１０４、アプリケーション１０５が管理されている。アプリケーション１０３は、例えば、クレジットカードの機能を実現するサービスを提供するためのアプリケーションである。アプリケーション１０４は、例えば、交通機関に乗り降りするときの料金の支払いなどのときに用いられるトランスポート系のサービスを提供するためのアプリケーションである。

ＵＩＣＣ内のアプリケーションマネージャ１０２は、一例として、Sun Microsystems（商標）が開示しているＪａｖaＣａｒｄＴＭを実行環境とした場合、Installerがアプリケーションインストール・削除機能を司り、Global Platformが規定しているレジストリによる管理情報、認証方法を利用して、統合的なアプリケーションマネージメント機能を実現している。

アプリケーション１０５は、総合サービスを提供するためのアプリケーションであり、サービス１０６−１、サービス１０６−２、サービス１０６−３を提供する。例えば、サービス１０６−１は、クレジットの機能を実現するサービスであり、サービス１０６−２は、トランスポート系のサービスを提供するサービスであり、サービス１０６−３は、クーポンを提供するサービスである。

このようなアプリケーションが登録されているときに、ビューワ７１により、ＵＩＣＣ５１で管理されているアプリケーションの閲覧が行われると、例えば、図４に示したような表示が行われる。ビューワ７１は、アプリケーション１０３、アプリケーション１０４、アプリケーション１０５を認識するため、アプリケーション１０３が提供するサービスのサービス名である“サービス１０３”、アプリケーション１０４が提供するサービスのサービス名である“サービス１０４”という名称をユーザに提供する。そして、アプリケーション１０５が提供するサービスは、複数あるが、アプリケーション１０５の総称である“サービス１０５”という名称が、ユーザに提供される。

このように、アプリケーション１０５は、サービス１０６−１乃至１０６−３を提供するが、ビューワ７１は、ＵＩＣＣ内のアプリケーションマネージャ１０２上に登録されているアプリケーション１０３乃至１０５しか認識できず、アプリケーション１０５が提供するサービス１０６−１乃至１０６−３までも認識して、その情報をユーザに提示することができない。

本発明は、このような状況に鑑みてなされたものであり、例えば、ＵＩＣＣなどの所定の情報を管理する装置内の情報を、その情報を閲覧するためのビューワで正確に閲覧できるようにし、かつそのための更新を既存のインフラを用いて行えるようにするものである。

本技術の一側面の通信装置は、所定のアプリケーションを記憶する記憶部と、前記アプリケーションで提供されるサービスに関する情報を管理する管理部と、 他の装置から、前記サービスを登録するためのデータを受信する通信部と、前記通信部を介し前記データを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録するサービス登録部と、前記サービス登録部により登録された前記サービスに関する情報を生成する生成部と、前記生成部により生成された前記情報で、前記管理部に管理されている前記情報を更新する更新部とを備える。

前記通信部は、前記他の装置と非接触で通信を行うようにすることができる。

前記情報の表示を制御する制御部をさらに備えるようにすることができる。

前記制御部の制御に基づき前記情報の表示を行う表示部をさらに備えるようにすることができる。

前記生成部は、前記アプリケーションにより前記他の装置から供給されるコマンドが処理されることで、前記サービスに関する情報を生成するようにすることができる。

前記生成部と前記更新部は、予め規定されている前記サービスに関する情報を入れる定義ブロックの内容から前記管理部に管理されている前記情報を更新するようにすることができる。

前記生成部は、前記サービスを識別する番号と、前記サービスに関する情報が対応付けられた対応表を備え、その対応表を参照して、前記サービスに関する情報を生成するようにすることができる。

前記アプリケーションに登録されたサービスは、前記生成部によって採番されたダミーＡＩＤで管理され、前記管理部は、通常のＡＩＤと前記ダミーＡＩＤを管理するようにすることができる。

前記更新部は、前記サービスの削除によって、前記管理部が管理する前記ダミーＡＩＤに対応したサービスに関する情報を更新するようにすることができる。

前記サービスを登録するためのデータは、前記アプリケーション独自の通信方式におけるパケットであるようにすることができる。

本技術の一側面の通信方法は、所定のアプリケーションを記憶する記憶部、前記アプリケーションで提供されるサービスに関する情報を管理する管理部、および他の装置と通信を行う通信部を少なくとも備える通信装置の通信方法において、前記他の装置から、前記サービスを登録するためのデータを前記通信部で受信し、前記データを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、登録された前記サービスに関する情報を生成し、生成された前記情報で、前記管理部に管理されている前記情報を更新するステップを含む。

本技術の一側面のプログラムは、所定のアプリケーションを記憶する記憶部、前記アプリケーションで提供されるサービスに関する情報を管理する管理部、および他の装置と通信を行う通信部を少なくとも備える通信装置に、前記他の装置から、前記サービスを登録するためのデータを前記通信部で受信し、前記データを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、登録された前記サービスに関する情報を生成し、生成された前記情報で、前記管理部に管理されている前記情報を更新するステップを含む処理を実行させる。

本技術の一側面の通信装置、通信方法、並びにプログラムにおいては、所定のアプリケーションが記憶され、アプリケーションで提供されるサービスに関する情報が管理され、 他の装置から、サービスを登録するためのデータが受信され、データが受信された場合、そのデータに基づき、アプリケーションの処理によりサービスが登録され、登録されたサービスに関する情報が生成され、生成された情報で、管理されている情報が更新される。

本発明の一側面によれば、異なる機器で共通して用いられるビューワで、情報を管理している装置内の情報を閲覧できる。その閲覧は、個々の情報の中身までも正確に反映したものとすることができる。

本発明の一側面によれば、情報を管理している装置内の情報を、既存のインフラを用いて更新することができる。

従来の携帯電話機におけるサービスの移行について説明するための図である。 ＵＩＣＣを用いたときのサービスの移行について説明するための図である。 ＵＩＣＣにおけるサービスの登録について説明するための図である。 ビューワの処理で表示される画面の一例を示す図である。 本発明を適用したシステムの一実施の形態の構成を示す図である。 ＩＣカードの内部構成を示す図である。 通信路について説明するための図である。 通信路について説明するための図である。 通信路について説明するための図である。 通信方式、パケット、コマンドの関係について説明するための図である。 各通信方式における階層について説明するための図である。 サービス名の表示例を示す図である。 サービスについて説明するための図である。 サービスとサービス名の登録について説明するための図である。 リーダライタの機能について説明するための図である。 通信方式の決定処理を説明するためのフローチャートである。 通信方式の決定処理を説明するためのフローチャートである。 通信方式の決定処理を説明するためのフローチャートである。 通信方式の決定処理を説明するためのフローチャートである。 通信方式の決定処理を説明するためのフローチャートである。 通信方式の決定処理を説明するためのフローチャートである。 通信方式の決定処理を説明するためのフローチャートである。 通信方式の決定処理を説明するためのフローチャートである。 通信方式の決定処理を説明するためのフローチャートである。 通信方式、パケット、コマンドの関係について説明するための図である。 サービスとサービス名の登録について説明するためのフローチャートである。 サービスとサービス名の登録について説明するためのフローチャートである。 サービスとサービス名の登録について説明するためのフローチャートである。 サービスとサービス名の登録について説明するためのフローチャートである。 アプリケーションマネージャについて説明するための図である。 サービスとサービス名の登録について説明するためのフローチャートである。 サービスとサービス名の登録について説明するためのフローチャートである。 サービス名の表示例を示す図である。 サービス名の表示例を示す図である。 記録媒体について説明するための図である。

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

［システムについて］
図５は、本発明が適用されるシステムの一実施の形態の構成を示す図である。図５に示したシステムは、携帯電話機２０１とリーダライタ２０２から構成される。携帯電話機２０１とリーダライタ２０２は、非接触により通信を行う。ここでは携帯電話機２０１として説明を続けるが、リーダライタ２０２と通信を行い、何らかのデータを保持するＩＣカードなどにも本発明を適用することができる。

［携帯電話機２０１の構成について］
図６は、携帯電話機２０１の内部構成を示す図である。携帯電話機２０１は、ホスト２２１、ＵＩＣＣ（Universal Integrated Circuit Card)２２２を含み、ホスト２２１とＵＩＣＣ２２２は、ＵＡＲＴ（Universal Asynchronous Receiver Transmitter）２２３でデータの授受を行えるように接続されている。また、携帯電話機２０１とリーダライタ２０２との非接触な通信を制御するＣＬＦ（Contactless Frontend）２２４も、携帯電話機２０１は含む構成とされている。

なお、ここでは本発明に係わる部分を図示して説明するが、携帯電話機２０１は、図示していない通信部などにより電話として機能する機能や、ネットワークに接続する機能などを実現する部分も含む構成とされている。

ＵＩＣＣ２２２は、ＵＩＣＣハードウェア２５１、アプリケーションマネージャ２５２、レジストリ２５３を備える。またＵＩＣＣ２２２は、ここでは、第１アプリケーション２５４、第２アプリケーション２５５、および第３アプリケーション２５６を記憶し、管理するとする。第１アプリケーション２５４は、例えば、携帯電話機２０１でクレジットカードの機能を実現するサービスを提供するためのアプリケーションである。また例えば、第２アプリケーション２５５は、交通機関に乗り降りするときの料金の支払いなどのときに用いられるトランスポート系のサービスを携帯電話機２０１で提供するためのアプリケーションである。

また例えば、第３アプリケーション２５６は、総合サービスを提供するためのアプリケーションである。後述するように、第３アプリケーション２５６は、クレジットの機能を実現するサービス、トランスポート系のサービス、クーポンを提供するサービスなど、複数のサービスを提供するためのアプリケーションである。図６には図示していないが、図１４を参照して後述するように、ＵＩＣＣ２２２にサービスが追加で登録されることがあり、ＵＩＣＣ２２２は、登録されたサービスを記憶し、管理する機能も有する。各アプリケーションは、アプリケーションマネージャ２５２によって、管理されるものであるが、同じ実行環境で管理される事に限定されない。一例として、アプリケーションマネージャ２５２がＪａｖａＣａｒｄＴＭを搭載し、１つのアプリケーションがソフトウェアにより実現されていても、他のアプリケーションが、ＲＯＭの工場出荷時に書き込まれている場合や、別チップとして提供される場合もあり得る。

ＵＩＣＣハードウェア２５１は、ＵＩＣＣ２２２を構成するハードウェアの部分であり、例えば、ＣＬＦ２２４とデータの授受を行うインターフェイスを含む構成とされる。アプリケーションマネージャ２５２は、レジストリ２５３を備える。アプリケーションマネージャ２５２は、レジストリ２５３に書き込まれている情報を参照したり、アプリケーションからの指示に基づき、レジストリ２５３内の情報を更新したりする。

また、アプリケーションマネージャ２５２は、ＣＬＦ２２４を介して供給されたコマンドを解釈し、その解釈に基づき、アプリケーションにデータを供給したり、アプリケーションからのデータを、ＣＬＦ２２４に供給したりする処理を実行する。レジストリ２５３は、アプリケーションが提供するサービスの名称やサービス種別といったサービスに関する情報を管理する。

ここでアプリケーションやサービスが登録されたり、更新されたりするときのデータの流れについて説明する。

［登録、更新時のデータの流れについて］
図７は、第１アプリケーション２５４にアクセスするときのデータの流れについて説明するための図である。第１アプリケーション２５４にアクセスする場合、リーダライタ２０２からＣＬＦ２２４を介して、ＵＩＣＣハードウェア２５１経由でＵＩＣＣ２２２の第１アプリケーション２５４にアクセスする通信路３０１がある。また、同じくリーダライタ２０２からＣＬＦ２２４を介して、さらに、ＵＩＣＣ２２２のＵＩＣＣハードウェア２５１とアプリケーションマネージャ２５２を介して第１アプリケーション２５４にアクセスする通信路３０２がある。

通信路３０１と通信路３０２の違いは、それぞれ異なるコマンドフォーマットによるものである。通信路３０１で第１アプリケーション２５４に送信されるのは、第１アプリケーション２５４の通信プロトコルに対応した独自のコマンドフォーマットである。リーダライタ２０２とＣＬＦ２２４の間で、第１アプリケーション２５４対応するプロトコルによって通信を行い、ＣＬＦ２２４からＵＩＣＣハードウェア２５１には、通信で取得した独自のコマンドが渡される。また、通信路３０２で第１アプリケーション２５４に送信されるのは、通信プロトコルに対応した汎用のコマンドフォーマットである。リーダライタ２０２とＣＬＦ２２４の間で、第１アプリケーション２５４に対応するプロトコルによって通信を行い、ＣＬＦ２２４からＵＩＣＣハードウェア２５１には、通信で取得した汎用のコマンドフォーマットに準拠したコマンドが渡される。つまり、流れるコマンドフォーマットによって、アプリケーションマネージャ２５２を経由せずに第１アプリケーションに行く通信路３０１と、経由して第１アプリケーションに行く通信路３０２がある。

後述するように、通信プロトコルとしては、ＩＳＯ １４４４３で規格されている３と４に対応したＴｙｐｅ Ａ規格、Ｔｙｐｅ Ｂ規格、１８０９２で規格されている通称ＴｙｐｅＦ規格が存在する。その通信プロトコルを利用する汎用なコマンドフォーマットとしては、ＩＳＯ７８１６−４で規定されるApplication Protocol Data Unit（APDU）と呼ばれるコマンドフォーマットがある。ＡＰＤＵコマンドフォーマットに準拠したコマンドの事を、以下、ＡＰＤＵコマンドと記述する。

図７に説明を戻し、第１アプリケーション２５４にアクセスする通信路としては、通信路３０３もある。この通信路３０３は、ホスト２２１から、有線のＵＡＲＴ２２３を介し、さらにＵＩＣＣ２２２内のＵＩＣＣハードウェア２５１とアプリケーションマネージャ２５２を介して第１アプリケーション２５４にアクセスする通信路である。

このように、第１アプリケーション２５４へとアクセスする通信路は３系統ある。また、第１アプリケーション２５４は、アプリケーションマネージャ２５２内のレジストリ２５３にアクセスすることができ、この通信路を通信路３０４とする。

次に、図８を参照し、第２アプリケーション２５５にアクセスするときのデータの流れについて説明する。第２アプリケーション２５５にアクセスする場合、リーダライタ２０２からＣＬＦ２２４を介して、さらに、ＵＩＣＣ２２２のＵＩＣＣハードウェア２５１とアプリケーションマネージャ２５２を介して第２アプリケーション２５５にアクセスする通信路３２１がある。この通信路３２１で第２アプリケーション２５５に送信されるのは、汎用の通信プロトコルに対応したコマンドフォーマットである。

また、第１アプリケーション２５４と同じく有線経由の通信路３２２もある。通信路３２２は、ホスト２２１から、有線のＵＡＲＴ２２３を介し、さらにＵＩＣＣ２２２内のＵＩＣＣハードウェア２５１とアプリケーションマネージャ２５２を介して第２アプリケーション２５５にアクセスする通信路である。

このように、第２アプリケーション２５５へとアクセスする通信路は２系統ある。また、第２アプリケーション２５５は、アプリケーションマネージャ２５２内のレジストリ２５３にアクセスすることができるように構成されている。この通信路を通信路３２３とする。

次に、図９を参照し、第３アプリケーション２５６にアクセスするときのデータの流れについて説明する。第３アプリケーション２５６にアクセスする場合、リーダライタ２０２からＣＬＦ２２４を介して、ＵＩＣＣハードウェア２５１を経由して、ＵＩＣＣ２２２の第３アプリケーション２５６にアクセスする通信路３５１がある。また、同じくリーダライタ２０２からＣＬＦ２２４を介して、さらに、ＵＩＣＣ２２２のＵＩＣＣハードウェア２５１とアプリケーションマネージャ２５２を介して第３アプリケーション２５６にアクセスする通信路３５２がある。

第１アプリケーション２５４と同じく、この第３アプリケーション２５６における通信路３５１と通信路３５２の違いも、それぞれ異なるコマンドフォーマットによるものである。リーダライタ２０２とＣＬＦ２２４の間で、第３アプリケーション２５６に対応するプロトコルによって通信を行い、ＣＬＦ２２４からＵＩＣＣハードウェア２５１には、通信で取得した第３アプリケーション２５６独自のコマンドが渡される。

通信路３５１で第３アプリケーション２５６に送信されるのは、第３アプリケーション２５６の通信プロトコルに対応した独自のコマンドフォーマットである。また、通信路３５２で第３アプリケーション２５６に送信されるのは、汎用のプロトコルに対応したコマンドフォーマットである。リーダライタ２０２とＣＬＦ２２４の間で、第３アプリケーション２５６に対応するプロトコルによって通信を行い、ＣＬＦ２２４からＵＩＣＣハードウェア２５１には、通信で取得した汎用のコマンドフォーマットに準拠したコマンドが渡される。

すなわち、流れるコマンドフォーマットによって、アプリケーションマネージャ２５２を経由せずに第３アプリケーション２５６に行く通信路３５１と、経由して第３アプリケーション２５６に行く通信路３５２がある。

第３アプリケーション２５６にアクセスする通信路としては、通信路３５３もある。この通信路３５３は、ホスト２２１から、有線のＵＡＲＴ２２３を介し、さらにＵＩＣＣ２２２内のＵＩＣＣハードウェア２５１とアプリケーションマネージャ２５２を介して第３アプリケーション２５６にアクセスする通信路である。

このように、第３アプリケーション２５６へとアクセスする通信路は３系統ある。また、第３アプリケーション２５６は、アプリケーションマネージャ２５２内のレジストリ２５３にアクセスすることができ、この通信路を通信路３５４とする。

図１０を参照し、これらの通信路や通信プロトコル、コマンドフォーマットについて説明を加える。図１０では、具体的な例を挙げて説明する。第１アプリケーション２５４は、Type Aなどと称される通信方式に対応している。以下、適宜、第１アプリケーション２５４が対応している通信方式を第１通信方式と記述し、第１通信方式の具体例としては、Type Aであるとして説明を続ける。

第１通信方式は、通信プロトコルとして、Ｔｙｐｅ Ａと称する通信方式のうちＩＳＯ １４４４３−２〜３に準拠しており、送信パケットとして独自パケットを利用しているものと１４４４３−４にも準拠し、汎用パケットに対応したものの２種類が存在する。

独自パケットは、第１アプリケーション２５４独自のコマンドを送受信する目的で用いられる。よってリーダライタ２０２から、この独自パケットが送信された場合、CLF２２４で抜き出されたコマンドはＵＩＣＣハードウェア２５１を経由して第１アプリケーション２５４へと供給される。換言すれば、独自の規格のパケットなため、アプリケーションマネージャ２５２で処理せず、第１アプリケーション２５４に供給される。

なお、第１アプリケーション２５４の実現方法により、アプリケーションマネージャ２５２を経由する場合としない場合がある。例えば、第１アプリケーション２５４がUICCハードウェア２５１内で実現される場合は、アプリケーションマネージャ２５２の管理下から離れてアプリケーションマネージャ２５２を介さずハードウェア内で動作することが可能である。別の例として、第１アプリケーション２５４がモジュールとして後からメモリ上に展開されている場合は、アプリケーションマネージャ２５２の管理下に置かれ、その場合は、アプリケーションマネージャ２５２を介する。アプリケーションマネージャを介する時は、前記のように汎用コマンドでのアクセスになる。

ここでは、図７に示した例、すなわち上記したように、リーダライタ２０２から独自パケットが送信された場合、CLF２２４で抜き出されたコマンドはＵＩＣＣハードウェア２５１を経由して第１アプリケーション２５４へと供給され、その経路は、通信路３０１であるとして説明を続ける。

なお、以下の説明においては、独自コマンドは、第１アプリケーション２５４の独自のパケット（第１パケットと記述する）で送受信されるコマンドであることを示すために第１コマンドと記述する。独自コマンドを利用した第１アプリケーションの１例として、MIFARE（商標）がある。

アプリケーションマネージャ２５２は、ＣＬＦ２２４で処理された後に抜き出されるＡＰＤＵコマンドを扱う。よってリーダライタ２０２から、このＡＰＤＵコマンドが送信された場合、通信路３０２（図７）、すなわち、CLF２２４、ＵＩＣＣハードウェア２５１、およびアプリケーションマネージャ２５２を介して第１アプリケーション２５４へと供給される。この場合、アプリケーションマネージャ２５２が、供給されたコマンドは、第１アプリケーション２５４へのコマンドであるとの処理を実行することで、第１アプリケーション２５４へとコマンドが供給されることになる。

この汎用パケットは、汎用のコマンドフォーマット、ここでは、ＡＰＤＵコマンドを送受信する目的で用いられる。

第２アプリケーション２５５は、Type Bなどと称される通信方式に対応している。以下、適宜、第２アプリケーション２５５が対応している通信方式を第２通信方式と記述し、第２通信方式の具体例としては、Type Bであるとして説明を続ける。この第２通信方式は、対応プロトコルとして、ＩＳＯ １４４４３−２〜４に準拠している。

第２通信方式（Type B）は、送信可能パケットとして、汎用パケットがある。汎用パケットは、上記したように、汎用のコマンドフォーマットの送受信を目的としており、ＡＰＤＵコマンドを送受信する目的で用いられる。

リーダライタ２０２から、この汎用パケットが送信された場合、CLF２２４でパケットを処理し、その中からＡＰＤＵコマンドを抜き出し、ＵＩＣＣハードウェア２５１、およびアプリケーションマネージャ２５２を介して第２アプリケーション２５５へと供給される。この場合、その後、アプリケーションマネージャ２５２が、供給されたパケットから抜き出したＡＰＤＵコマンドを処理し、第２アプリケーション２５５へのコマンドであるとの処理を実行することで、第２アプリケーション２５５へとコマンドが供給されることになる。

なお、第２アプリケーション２５５の場合も、第１アプリケーション２５４の場合と同じく、第２アプリケーション２５５の実現方法により、アプリケーションマネージャ２５２を経由する場合としない場合が考えられる。ここでは、図８に示したように、アプリケーションマネージャ２５２を介する例を挙げて説明を続ける。

第３アプリケーション２５６は、Type Fなどと称される通信方式に対応している。以下、適宜、第３アプリケーション２５６が対応している通信方式を第３通信方式と記述し、第３通信方式の具体例としては、Type Fであるとして説明を続ける。この第３通信方式は、通信プロトコルとして、ＩＳＯ １８０９２に準拠している。

第３通信方式（Type F）は、送信可能パケットとしてFeliCa(商標)パケットと、FeliCaパケット上にさらに汎用パケットを載せたものがある。FeliCaパケットは、第３アプリケーション２５６の独自のパケットである。よってリーダライタ２０２から、このFeliCa パケットが送信された場合、CLF２２４で抜き出されたFeliCaコマンドがCLF２２４から第３アプリケーション２５６へと供給される。このFeliCa パケットは、FeliCa コマンドを送受信する目的で用いられる。

なお、第３アプリケーション２５６の場合も、第１アプリケーション２５４の場合と同じく、第３アプリケーション２５６の実現方法により、アプリケーションマネージャ２５２を経由する場合としない場合が考えられる。ここでは、図９に示したように、アプリケーションマネージャ２５２を介する例（通信路３５１での通信例）を挙げて説明を続ける。

なお、以下の説明においては、FeliCa コマンドは、第３アプリケーション２５６の独自のパケット（以下、第３パケットと記述する）で送受信されるコマンドであることを示すために第３コマンドと記述する。

このType Fは、送信可能パケットとして、FeliCaパケット上にさらに汎用パケットを載せて汎用コマンドの送受にも対応している。この汎用パケットは、上記したように、汎用コマンドの送受信を目的としており、ＡＰＤＵコマンドを送受信する目的で用いられる。

リーダライタ２０２から、この汎用パケットが送信された場合、CLF２２４でパケットを処理し、抜き出されたＡＰＤＵコマンドが、ＵＩＣＣハードウェア２５１、およびアプリケーションマネージャ２５２を介して第３アプリケーション２５６へと供給される。すなわち、通信路３５２（図９）でＡＰＤＵコマンドとそのレスポンスデータの授受が行われる。この場合、アプリケーションマネージャ２５２が、供給されたＡＰＤＵコマンドは、第３アプリケーション２５６へのコマンドであるとの処理を実行することで、第３アプリケーション２５６へとＡＰＤＵコマンドが供給されることになる。

このように、携帯電話機２０１とリーダライタ２０２が非接触でパケットの授受を行う場合、第１パケットや第３パケットといった、サービス独自のコマンドに対応したパケットで授受が行われるときと、汎用のＡＰＤＵコマンドといったＩＳＯ７８１６−４に準拠したコマンドフォーマットで授受が行われるときとがある。

さらに、有線という通信路もある。すなわち図１０を参照するに、通信路３０３(図７)、通信路３２２(図８)、通信路３５３(図９)で通信が行われるとき、そのプロトコルはシリアル通信を行うプロトコルとされる。そして、送受信可能なパケットとしては、有線独自のパケットと、ＴＰＤＵ（Transport Protocol Data Unit）（ＩＳＯ ７８１６−３）規格のパケットとがある。

第３アプリケーション２５６に対する処理を行いたい場合、独自の有線パケットは、第３コマンド（FeliCaコマンド）の授受を行うために用いられる。ＴＰＤＵ規格のパケットは、汎用のコマンド、この場合、ＡＰＤＵコマンドを授受するために用いられる。

図１１を参照し、さらに、第１通信方式（Type A）、第２通信方式（Type B）、第３通信方式（Type F）、および有線における階層構造について説明する。第１アプリケーション２５４に対応する第１通信方式は、初期化／衝突防止層として、ＩＳＯ １４４４３−３ Type A規格に対応している。また第１通信方式は、パケット層として、独自パケットと、ＩＳＯ １４４４３−４規格の汎用パケットに対応している。そして、第１通信方式のコマンド層は、パケット層の独自パケットに対応するコマンド層として、独自 コマンドフォーマットに対応し、パケット層のＩＳＯ １４４４３−４規格の汎用パケットに対応するコマンド層として、ＩＳＯ ７８１６−４に準拠したＡＰＤＵコマンドフォーマットに対応している。

第２アプリケーション２５５に対応する第２通信方式は、初期化／衝突防止層として、ＩＳＯ １４４４３−３ Type B規格に対応している。また第２通信方式は、パケット層として、ＩＳＯ １４４４３−４規格の汎用パケットに対応している。そして、Type Bのコマンド層は、パケット層のＩＳＯ １４４４３−４規格の汎用パケットに対応するコマンド層として、ＩＳＯ ７８１６−４に準拠したＡＰＤＵコマンドフォーマットに対応している。

第３アプリケーション２５６に対応する第３通信方式は、初期化／衝突防止層として、ＩＳＯ １８０９２規格に対応している。また第３通信方式は、パケット層として、ＩＳＯ １４４４３−４規格のパケットと、FeliCaパケットに対応している。そして、Type Fのコマンド層は、パケット層のＩＳＯ １４４４３−４規格のパケットに対応するコマンド層として、ＩＳＯ ７８１６−４に準拠したＡＰＤＵコマンドフォーマットに対応し、パケット層のFeliCaパケットに対応するコマンド層として、FeliCaコマンドフォーマットに対応している。

有線は、無線通信ではないため、初期化／衝突防止層を備える必要がない。物理的な接続については、ＩＳＯ７８１６−１と２により実現される。有線は、パケット層として、ＩＳＯ ７８１６−３規格のパケットに準拠している。そして、有線のコマンド層は、パケット層のＩＳＯ ７８１６−３規格のパケットに対応するコマンド層として、ＩＳＯ ７８１６−４に準拠したＡＰＤＵコマンドフォーマットに対応している。

このように、第１アプリケーション２５４、第２アプリケーション２５５、第３アプリケーション２５６に、それぞれアクセスする通信路は複数あるため、リーダライタ２０２は、どの通信路（通信方式）でデータの授受を行うかを判断する必要がある。

ここで、再度図６を参照する。図６に示したように、ＵＩＣＣ２２２で、第１アプリケーション２５４、第２アプリケーション２５５、および第３アプリケーション２５６が管理されているとき、ビューワ２４１による処理が実行されると、例えば、図１２に示すような画面がユーザに提供される。画面とは、例えば、携帯電話機２０１のディスプレイ４０１に表示される画面のことである。

図１２に示すようにビューワ２４１は、アプリケーションマネージャ２５２が認識した第１アプリケーション２５４、第２アプリケーション２５５、第３アプリケーション２５６を認識する。そしてビューワ２４１は、第１アプリケーション２５４が提供するサービスの名称である“第１サービス”、第２アプリケーション２５５が提供するサービスの名称である“第２サービス”、および第３アプリケーション２５６が提供するサービスの名称である“第３サービス”を、ディスプレイ４０１に表示させる。

第３アプリケーション２５６は、総合サービスであり、図１３に示すように複数のサービスを提供できる。すなわち、図１３に示した例では、第３アプリケーション２５６は、第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９を提供できるように構成されている。

このように、第３アプリケーション２５６が、第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９を提供できる場合であっても、ビューワ２４１は、アプリケーションマネージャ２５２上に登録されている第１アプリケーション２５４、第２アプリケーション２５５、第３アプリケーション２５６しか認識できず、第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９までも認識して、その情報をユーザに提示することができない。

これは、レジストリ２５３で、登録されているサービスの情報が管理されているからである。ここで、アプリケーションやサービスの登録について説明する。

図１４に示すように、ＵＩＣＣ２２２に第３−１サービス２５７が登録されていない状態（登録されていないことを示すために、図１４においては、点線で示す。またアプリケーションなどは図示していない）のときに、第３−１サービス２５７を登録する際、ＵＩＣＣ２２２の外部から、サービスを登録するためのデータ４３１が送信される。サービスを登録するためのデータは、サービス登録データとする。このサービス登録データ４３１は、第３−１サービス２５７を登録するためのものである。このようなサービス登録データ４３１によるサービスの登録は、現状でも行われているインフラを用いて行うことができる。図１４を使って説明すると、リーダライタ２０２からＣＬＦ２２４を経由して、ＵＩＣＣ２２２にサービス登録データ４３１を渡すことが出来る。または、ホスト２２１からＵＡＲＴを経由して、ＵＩＣＣ２２２にデータを渡すことも可能である。

しかしながら、サービス登録データ４３１で第３−１サービス２５７を登録しても、アプリケーションマネージャ２５２のレジストリ２５３には、第３−１サービス２５７の情報は登録されない。そのため、そのようなサービスが登録されたことが認識できない。よって、レジストリ２５３で管理されている情報を更新するために、サービス種別や名前を登録するための処理が行われる必要がある。

例えば、サービス種別・名前コマンド４３２をアプリケーションマネージャ２５２に対して送信し、アプリケーションマネージャ２５２での管理情報（レジストリ２５３内の情報）を更新する必要がある。この場合、第３アプリケーション２５６には、第３−１サービス２５７が含まれること（新たに登録されたこと）を、サービス種別・名前コマンド４３２でアプリケーションマネージャ２５２のレジストリ２５３に登録する必要がある。

仮に、第３アプリケーション２５６が提供する第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９毎に、第３のアプリケーションと同様に、第４、第５、第６とそれぞれ登録を行うようにすることも考えられる。このようにした場合、第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９は第４、第５、第６のアプリケーションとして、それぞれ登録することが可能となる。しかしながら、このような登録を行うようにすると、既存のサービス登録データ４３１を用いることができなくなり、現状のアプリケーション間の関係性を用いた運用が適用できなくなり、既存のインフラを用いたオペレーションができなくなる可能性がある。

既存のインフラをできる限り生かしつつも、ビューワ２４１で、個々のサービスが閲覧できるようにするためには、上記したように、サービス登録データ４３１とサービス種別・名称コマンド４３２をそれぞれ送信してサービス名を登録することが考えられる。ここでは、第３アプリケーション２５６が複数のサービスを含んでいるとして説明したが、第１アプリケーション２５４や第２アプリケーション２５５が複数のサービスを含んでいるような場合でも、同様のことが言える。

図７乃至１１を参照して説明したように、第１アプリケーション２５４、第２アプリケーション２５５、第３アプリケーション２５６のそれぞれは、複数の通信路によりアクセス可能である。第３アプリケーション２５６は、通信路３５１乃至３５４（図９）があるため、例えば、通信路３５１で、第３−１サービス２５７を登録し、通信路３５２で、レジストリ２５３の情報を更新することができる。

このようなことを可能にするためには、リーダライタ２０２が、携帯電話機２０１に対して登録や更新の処理を実行するとき、どの通信路を用いて登録を行い、どの通信路を用いて更新を行うかを判断し、その判断に基づき、適切なコマンド、例えば、選択した通信路に適合したプロトコルのパケットでのコマンドを生成する必要がある。

［リーダライタの構成について］
そこで、リーダライタ２０２は、図１５に示すような機能を有する構成とされる。すなわち、リーダライタ２０２は、通信制御部５０１、通信方式決定部５０２、サービス登録部５０３、および更新処理部５０４を備える。通信制御部５０１は、所定のアプリケーション（例えば、第３アプリケーション２５６）と、アプリケーションで提供されるサービス（例えば、第３−１サービス２５７）を管理するアプリケーションマネージャ２５２を備えるＵＩＣＣ２２２との非接触な通信を制御する。

通信方式決定部５０２は、ＵＩＣＣ２２２に対して所定のサービスの登録を行うときの通信方式と、レジストリ２５３に対する更新を行うときの通信方式をそれぞれ決定する処理を行う。

サービス登録部５０３は、通信方式決定部５０２により決定された通信方式で、ＵＩＣＣ２２２に所定のサービスを登録するためのコマンドの生成などを実行する。更新処理部５０４は、通信方式決定部５０２により決定された通信方式で、ＵＩＣＣ２２２のレジストリ２５３で管理されている情報を更新するためのコマンドの生成などを実行する。

［リーダライタの処理について］
次に、リーダライタ２０２の処理について図１６のフローチャートを参照して説明する。ステップＳ１において、通信方式決定部５０２により、通信方式が決定される。このステップＳ１において実行される通信方式の決定は、図１７乃至図２４を参照して後述する第１乃至第８の決定処理のいずれか１つの処理が実行されることで行われる。

ステップＳ１において、サービスを登録する通信方式とサービス名を登録する通信方式が決定されると、ステップＳ２において、サービス登録部５０３により、決定された通信方式で、まずサービスの登録処理が実行される。そして、ステップＳ３において、更新処理部５０４により、決定された通信方式で、サービス名の登録処理（レジストリ２５３の更新処理のための処理）が実行される。このサービスの登録とサービス名の登録に関する処理については、図２６以降のフローチャートを参照して後述する。

まずステップＳ１において実行されるＵＩＣＣ２２２に対してサービスを登録するときの通信方式と、レジストリ２５３の更新を行うときの通信方式を決定する際の処理について説明する。通信方式の決定に係わる処理について８通りの例を挙げて説明する。

［通信方式の第１の決定処理について］
通信方式の第１の決定処理として、全ての通信方式を試して、良好な通信を行える通信方式を選択する方法について図１７のフローチャートを参照して説明する。ステップＳ１１において、第１通信方式の利用が可能か否かが判断される。例えば、第１通信方式でのパケットが送信され、その返答があったか否かが判断されることで、第１通信方式の利用が可能か否かが判断される。

ステップＳ１１において、第１通信方式の利用が可能であると判断された場合、ステップＳ１２に処理が進められる。ステップＳ１２において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。例えば、ＡＰＤＵコマンドが生成され、そのＡＰＤＵコマンドに対する返答があったか否かが判断されることで、ＡＰＤＵコマンドフォーマットが利用可能であるか否かが判断される。

ステップＳ１２において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ１３に処理が進められる。また、ステップＳ１２において、ＡＰＤＵコマンドフォーマットが利用可能ではないと判断された場合も、ステップＳ１３に処理が進められる。さらに、ステップＳ１１において、第１通信方式の利用が可能ではないと判断された場合も、ステップＳ１３に処理が進められる。

すなわち、ステップＳ１１とステップＳ１２の処理が実行されることにより、第１通信方式で通信を行えるＣＬＦ２２４であるか否かの判断が行われ、第１通信方式で通信可能である場合には、さらにＡＰＤＵコマンドフォーマットが利用可能である否かの判断が行われることになる。このような判断結果は、適宜保持される。

ステップＳ１３において、第２通信方式の利用が可能か否かが判断される。ステップＳ１３において、第２通信方式の利用が可能であると判断された場合、ステップＳ１４に処理が進められる。ステップＳ１４において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ１４において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ１５に処理が進められる。また、ステップＳ１４において、ＡＰＤＵコマンドフォーマットが利用可能ではないと判断された場合も、ステップＳ１５に処理が進められる。さらに、ステップＳ１３において、第２通信方式の利用が可能ではないと判断された場合も、ステップＳ１５に処理が進められる。

すなわち、ステップＳ１３とステップＳ１４の処理が実行されることにより、第２通信方式で通信を行える携帯電話機２０１であるか否かの判断が行われ、第２通信方式で通信可能である場合には、さらにＡＰＤＵコマンドフォーマットが利用可能である否かの判断が行われることになる。このような判断結果は、適宜保持される。

ステップＳ１５において、第３通信方式の利用が可能か否かが判断される。ステップＳ１５において、第３通信方式の利用が可能であると判断された場合、ステップＳ１６に処理が進められる。ステップＳ１６において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ１６において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ１７に処理が進められる。また、ステップＳ１６において、ＡＰＤＵコマンドフォーマットが利用可能ではないと判断された場合も、ステップＳ１７に処理が進められる。さらに、ステップＳ１５において、第３通信方式の利用が可能ではないと判断された場合も、ステップＳ１７に処理が進められる。

すなわち、ステップＳ１５とステップＳ１６の処理が実行されることにより、第３通信方式で通信を行えるＣＬＦ２２４であるか否かの判断が行われ、第３通信方式で通信可能である場合には、さらにＡＰＤＵコマンドフォーマットが利用可能である否かの判断が行われることになる。このような判断結果は、適宜保持される。

ステップＳ１７において、全ての判断結果が保持される。利用可能であった場合には、フラグが立てられ、利用不可能であった場合には、フラグが立てられないという条件で管理されるテーブルが用いられ、各ステップにおける判断結果が保持されるようにしても良い。

ステップＳ１８において、状態から最適な処理が選択される。この選択は、利用可能であるとされた通信方式が選択される。場合によって、ＡＰＤＵコマンドフォーマットが利用可能と判断された通信方式が選択されたり、独自のパケットによる通信方式が選択される。選択される順位が設定されており、その順位に従って、利用可能であると判断された通信方式が選択される。このような、予め設定されている選択条件に基づいて選択が行われる。また、リーダライタ２０２の制約なども反映されて、選択が行われる。

ステップＳ１９において、ステップＳ１８において選択された通信方式で、通信が実行される。例えば、第１通信方式が選択された場合には、第１通信方式で通信が行われる。その結果、処理（通信）が成功したか否かが、ステップＳ２０において判断される。何らかの原因により、処理が正常に行われなかった場合、その通信方式での通信を中止し、異なる通信方式が選択される。

すなわち、ステップＳ２０において、選択された通信方式での処理は成功しなかったと判断された場合、ステップＳ２１に処理が進められ、状態（条件）の更新が行われ、その更新後に、ステップＳ１８に処理が戻され、それ以降の処理が繰り返される。ステップＳ２１において実行される更新は、例えば、通信が失敗した通信方式を、利用不可能な通信方式との判断結果に更新（変更）するなどの処理である。

一方、ステップＳ２０において、選択された通信方式で処理が成功したと判断された場合、通信方式の決定処理に係わる図１７に示したフローチャートの処理は終了される。後段の処理として、選択された通信方式で、サービスの登録やレジストリ２５３の更新が行われる。そのような処理については、後述する。

なお、図１７に示した処理の順序は一例であり、限定を示すものではない。すなわち、第１通信方式、第２通信方式、第３通信方式の全ての通信方式を試し、その結果を保持するため、どの通信方式から試すかによる差異はなく、どの通信方式から試しても良い。

このように、リーダライタ２０２がＣＬＦ２２４と、複数の通信方式で通信を行うことができるように構成されている場合、ＣＬＦ２２４と通信を行えるか否かが通信方式毎に判断され、通信を行えると判断された通信方式の中から、その時点で最適であると判断される通信方式が選択される。

このように、全ての通信方式を試すことにより通信方式を決定することで、仮に、選択された通信方式での通信に失敗したとしても、リカバリーがしやすくなるという利点がある。

［通信方式の第２の決定処理について］
通信方式の第２の決定処理として、第１通信方式、第２通信方式、第３通信方式の順で通信方式の利用が可能であるか否かを判断し、利用可能であると判断されたときに、その通信方式を選択することで通信方式が決定される場合について図１８のフローチャートを参照して説明する。

図１８乃至図２４のフローチャートを参照して説明する決定処理は、基本的な処理の流れは同じであり、まず複数の通信方式のうちの１つの通信方式が選択され、その通信方式でＵＩＣＣ２２２と通信が可能であるか否かが判断される。そして、通信できないと判断されたときには、他の通信方式が選択し直されて、再度、ＵＩＣＣ２２２との通信が試される。そして、選択された通信方式で通信が可能となった時点で、その通信が可能となった通信方式を選択するという処理である。

ステップＳ５１において、第１通信方式の利用が可能であるか否かが判断される。ステップＳ５１において、第１通信方式の利用が可能であると判断された場合、ステップＳ５２に処理が進められる。ステップＳ５２において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ５２において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ５３に処理が進められる。

ステップＳ５３において、第１通信方式で実現すると決定されて、通信方式の決定処理は終了される。すなわちこの場合、第１通信方式で通信可能であり、第１通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であるため、第１通信方式で、サービスの登録とレジストリ２５３の更新（登録されるサービスの名称の追加）が行われると設定される。後段の処理において、設定された通信方式で、サービスの登録とサービスの名称の追加が行われる。

一方、ステップＳ５２において、ＡＰＤＵコマンドフォーマットが利用できないと判断された場合、ステップＳ５４に処理が進められる。ステップＳ５４において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ５４において、第２通信方式の利用が可能であると判断された場合、ステップＳ５５に処理が進められる。

この場合、第１通信方式と第２通信方式の利用が可能であると判断されたことになるので、ステップＳ５５においては、第１通信方式と第２通信方式で、登録と更新の処理を実現すると設定される。具体的には、第１通信方式でサービスの登録が行われ、第２通信方式でサービス名の登録が行われると設定される。または第２の通信方式のみで、サービスとサービス名の登録が行われると設定される。

なお、この場合、第２通信方式は、ＡＰＤＵコマンドフォーマットで通信を行う方式であるので、第２通信方式の利用が可能と判断されたときには、ＡＰＤＵコマンドフォーマットが利用可能であるかの判断は行われない。

図１８中、「第１通信方式／第２通信方式」との記載は、／の前に記載されている第１通信方式では、ＡＰＤＵコマンドフォーマットが利用できないことを示し、／の後に記載されている第２通信方式では、ＡＰＤＵコマンドフォーマットが利用できることを示す。他の図面においても同様であり、Ａ／Ｂとの記載の場合、ＡはＡＰＤＵコマンドフォーマットが利用できないことを示し、ＢはＡＰＤＵコマンドフォーマットを利用できることを示す。

一方、ステップＳ５４において、第２通信方式が利用できないと判断された場合、ステップＳ５６に処理が進められる。ステップＳ５６において、第３通信方式の利用が可能であるか否かが判断される。ステップＳ５６において、第３通信方式の利用が可能であると判断された場合、ステップＳ５７に処理が進められる。

ステップＳ５７において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ５７において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ５８に処理が進められる。

この場合、第１通信方式、第３通信方式、および第３通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ５８においては、第１通信方式と第３通信方式で、登録と更新の処理を実現すると設定される。この場合、第１通信方式、第３通信方式、および第３通信方式におけるＡＰＤＵコマンドのいずれかが用いられて、サービスの登録が行われ、第３通信方式におけるＡＰＤＵコマンドが用いられてサービス名の登録が行われると設定される。

一方、ステップＳ５１において、第１通信方式の利用は可能ではないと判断された場合、ステップＳ６０に処理が進められる。ステップＳ６０において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ６０において、第２通信方式の利用が可能であると判断された場合、ステップＳ６１に処理が進められる。

この場合、第２通信方式の利用が可能であると判断されたことになるので、ステップＳ６１においては、第２通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ６０において、第２通信方式が利用できないと判断された場合、ステップＳ６２に処理が進められる。ステップＳ６２において、第３通信方式の利用が可能であるか否かが判断される。ステップＳ６２において、第３通信方式の利用が可能であると判断された場合、ステップＳ６３に処理が進められる。

ステップＳ６３において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ６３において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ６４に処理が進められる。

この場合、第３通信方式、および第３通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ６４においては、第３通信方式で、登録と更新の処理を実現すると設定される。具体的には、第３通信方式、または第３通信方式におけるＡＰＤＵコマンドでサービスの登録が行われ、第３通信方式におけるＡＰＤＵコマンドでサービス名の登録が行われると設定される。

一方、ステップＳ６２において、第３通信方式の利用は可能ではないと判断された場合、ステップＳ６５に処理が進められる。この場合、第１通信方式、第２通信方式、および第３通信方式の全ての通信方式で通信が行えない、換言すれば、リーダライタ２０２がサポートしている通信方式でＣＬＦ２２４と通信を行うことができないと判断されたときであるので、ステップＳ６５において、通信不可と判断される。

一方、ステップＳ６３において、ＡＰＤＵコマンドフォーマットの利用が可能ではないと判断された場合、ステップＳ５９に処理が進められる。この場合、第３通信方式で通信は可能であるが、ＡＰＤＵコマンドフォーマットの利用はできないと判断されたときである。同様に、ステップＳ５６において、第３通信方式の利用ができないと判断された場合も、ステップＳ５９に処理が進められる。この場合、第１通信方式では通信可能であるが、ＡＰＤＵコマンドフォーマットの利用が出来ない、第２通信方式、および第３通信方式では通信ができないと判断されたときである。

また同様に、ステップＳ５７において、ＡＰＤＵコマンドフォーマットの利用ができないと判断された場合も、ステップＳ５９に処理が進められる。この場合、第１通信方式と第３通信方式で通信は可能であるが、どちらの方式であってもＡＰＤＵコマンドフォーマットを利用した通信ができないと判断されたときである。

これらのステップＳ５９に処理が進められるときの共通の状況としては、ＡＰＤＵコマンドフォーマットの利用ができない点である。ＡＰＤＵコマンドフォーマットが利用できない場合、レジストリ２５３の更新が行えない。詳細は後述するが、レジストリ２５３の更新は、ＡＰＤＵコマンドが用いられて行われる。よって、ＡＰＤＵコマンドが利用できない場合、レジストリ２５３の更新ができないことになるため、付加機能で実現することになる。

付加機能で実現するとは、ＵＩＣＣ２２２や、ＵＩＣＣに搭載するアプリケーション側に何らかの機能を設けることにより、レジストリ２５３の更新を実現することを意味する。換言すれば、付加機能で実現する以外のときには、例えば、ステップＳ５３のように、第１通信方式で実現すると設定された場合には、ＵＩＣＣ２２２側の現状の機能のままで、サービスの登録やレジストリ２５３の更新を行えることを意味する。

このように、通信方式が決定されると、決定された通信方式に基づき、ステップＳ２とステップＳ３（図１６）に該当するサービスの登録とレジストリ２５３の更新が、後述するようにして実行される。

［通信方式の第３の決定処理について］
通信方式の第３の決定処理として、第１通信方式、第３通信方式、第２通信方式の順で通信方式の利用が可能であるか否かを判断し、利用可能であると判断されたときに、その通信方式を選択することで通信方式が決定される場合について図１９のフローチャートを参照して説明する。なお、図１８のフローチャートにおける処理と同様の処理を含むため、同様の処理に関する説明は適宜省略する。

ステップＳ１０１において、第１通信方式の利用が可能であるか否かが判断される。ステップＳ１０１において、第１通信方式の利用が可能であると判断された場合、ステップＳ１０２に処理が進められる。ステップＳ１０２において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ１０２において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ１０３に処理が進められる。

ステップＳ１０３において、第１通信方式で実現すると決定されて、通信方式の決定処理は終了される。すなわちこの場合、第１通信方式で通信可能であり、第１通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であるため、第１通信方式で、サービスの登録と更新が行われると設定される。

一方、ステップＳ１０２において、ＡＰＤＵコマンドフォーマットが利用できないと判断された場合、ステップＳ１０４に処理が進められる。ステップＳ１０４において、第３通信方式の利用が可能であるか否かが判断される。ステップＳ１０４において、第３通信方式の利用が可能であると判断された場合、ステップＳ１０５に処理が進められる。

ステップＳ１０５において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ１０５において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ１０６に処理が進められる。

この場合、第１通信方式、第３通信方式、および第３通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ１０６においては、第１通信方式と第３通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ１０４において、第３通信方式の利用は可能ではないと判断された場合、ステップＳ１０７に処理が進められる。ステップＳ１０７において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ１０７において、第２通信方式の利用が可能であると判断された場合、ステップＳ１０８に処理が進められる。

この場合、第１通信方式と第２通信方式の利用が可能であると判断されたことになるので、ステップＳ１０８においては、第１通信方式と第２通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ１０５において、ＡＰＤＵコマンドフォーマットの利用が可能ではないと判断された場合、ステップＳ１０９に処理が進められる。ステップＳ１０９において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ１０９において、第２通信方式の利用が可能であると判断された場合、ステップＳ１１０に処理が進められる。

この場合、第１通信方式、第３通信方式、および第２通信方式の利用が可能であると判断され、第１通信方式と第３通信方式は、ともにＡＰＤＵコマンドフォーマットの利用が可能ではないと判断されたことになるので、ステップＳ１１０においては、第１通信方式または第３通信方式で、登録を行い、第２通信方式で更新の処理を実現すると設定される。

一方、ステップＳ１０１において、第１通信方式の利用は可能ではないと判断された場合、ステップＳ１１２に処理が進められる。ステップＳ１１２において、第３通信方式の利用が可能であるか否かが判断される。ステップＳ１１２において、第３通信方式の利用が可能であると判断された場合、ステップＳ１１３に処理が進められる。

ステップＳ１１３において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ１１３において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ１１４に処理が進められる。

この場合、第３通信方式、および第３通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ１１４においては、第３通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ１１２において、第３通信方式が利用できないと判断された場合、ステップＳ１１５に処理が進められる。ステップＳ１１５において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ１１５において、第２通信方式の利用が可能であると判断された場合、ステップＳ１１６に処理が進められる。

この場合、第２通信方式の利用が可能であると判断されたことになるので、ステップＳ１１６においては、第２通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ１１３において、ＡＰＤＵコマンドフォーマットの利用が可能ではないと判断された場合、ステップＳ１１７に処理が進められる。ステップＳ１１７において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ１１７において、第２通信方式の利用が可能であると判断された場合、ステップＳ１１８に処理が進められる。

この場合、第３通信方式、第２通信方式の利用が可能であると判断されたことになるので、ステップＳ１１８においては、第３通信方式で、登録を行い、第２通信方式で更新の処理を実現すると設定される。

一方、ステップＳ１１５において、第２通信方式の利用は可能ではないと判断された場合、ステップＳ１１９に処理が進められる。この場合、第１通信方式、第２通信方式、および第３通信方式の全ての通信方式で通信が行えない、換言すれば、リーダライタ２０２がサポートしている通信方式でＣＬＦ２２４と通信を行うことができないと判断されたときであるので、ステップＳ１１９において、通信不可と判断される。

一方、ステップＳ１０７、ステップＳ１０９、またはステップＳ１１７において、第２通信方式の利用が可能ではないと判断された場合、ステップＳ１１１に処理が進められる。これらのステップで第２通信方式の利用が可能ではないと判断された場合は、ＡＰＤＵコマンドフォーマットの利用ができないと判断されたことを意味する。

このような場合、ＵＩＣＣ２２２に何らかの機能を設けることにより、レジストリ２５３の更新を実現し設定される（ＵＩＣＣ２２２の付加機能を用いた更新を行うと設定される）。

［通信方式の第４の決定処理について］
通信方式の第４の決定処理として、第２通信方式、第１通信方式、第３通信方式の順で通信方式の利用が可能であるか否かを判断し、利用可能であると判断されたときに、その通信方式を選択することで通信方式が決定される場合について図２０のフローチャートを参照して説明する。

ステップＳ１５１において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ１５１において、第２通信方式の利用が可能であると判断された場合、ステップＳ１５２に処理が進められる。

この場合、第２通信方式の利用が可能であると判断されたことになるので、ステップＳ１５２においては、第２通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ１５１において、第２通信方式の利用は可能ではないと判断された場合、ステップＳ１５３に処理が進められる。ステップＳ１５３において、第１通信方式の利用が可能であるか否かが判断される。ステップＳ１５３において、第１通信方式の利用が可能であると判断された場合、ステップＳ１５４に処理が進められる。ステップＳ１５４において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ１５４において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ１５５に処理が進められる。

この場合、第１通信方式で通信可能であり、第１通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であるため、ステップＳ１５５においては、第１通信方式で、サービスの登録と更新が行われると設定される。

一方、ステップＳ１５４において、ＡＰＤＵコマンドフォーマットが利用できないと判断された場合、ステップＳ１５６に処理が進められる。ステップＳ１５６において、第３通信方式の利用が可能であるか否かが判断される。ステップＳ１５６において、第３通信方式の利用が可能であると判断された場合、ステップＳ１５７に処理が進められる。ステップＳ１５７において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ１５７において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ１５８に処理が進められる。

この場合、第１通信方式、第３通信方式、および第３通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ１５８においては、第１通信方式と第３通信方式で、登録と更新の処理を実現すると設定される。この場合、第１通信方式または第３通信方式でサービスの登録が行われると設定され、第３通信方式でサービス名の登録が行われると設定される。

一方、ステップＳ１５３において、第１通信方式が利用できないと判断された場合、ステップＳ１６０に処理が進められる。ステップＳ１６０において、第３通信方式の利用が可能であるか否かが判断される。ステップＳ１６０において、第３通信方式の利用が可能であると判断された場合、ステップＳ１６１に処理が進められる。ステップＳ１６１において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ１６１において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ１６２に処理が進められる。

この場合、第３通信方式、および第３通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ１６２においては、第３通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ１６０において、第３通信方式が利用できないと判断された場合、ステップＳ１６４に処理が進められる。この場合、第１通信方式、第２通信方式、および第３通信方式の全ての通信方式で通信が行えない、換言すれば、リーダライタ２０２がサポートしている通信方式でＣＬＦ２２４と通信を行うことができないと判断されたときであるので、ステップＳ１６４において、通信不可と判断される。

一方、ステップＳ１５６において、第３通信方式の利用が可能ではないと判断された場合、ステップＳ１５７またはステップＳ１６１において、ＡＰＤＵコマンドフォーマットの利用が可能ではないと判断された場合、ステップＳ１６３に処理が進められる。このような場合は、ＡＰＤＵコマンドフォーマットの利用ができないと判断されたことを意味する。よって、ＵＩＣＣ２２２に何らかの機能を設けることにより、レジストリ２５３の更新を実現すると、ステップＳ１６３において設定される（ＵＩＣＣ２２２の付加機能を用いた更新を行うと設定される）。

［通信方式の第５の決定処理について］
通信方式の第５の決定処理として、第２通信方式、第３通信方式、第１通信方式の順で通信方式の利用が可能であるか否かを判断し、利用可能であると判断されたときに、その通信方式を選択することで通信方式が決定される場合について図２１のフローチャートを参照して説明する。

ステップＳ２０１において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ２０１において、第２通信方式の利用が可能であると判断された場合、ステップＳ２０２に処理が進められる。

この場合、第２通信方式の利用が可能であると判断されたことになるので、ステップＳ２０２においては、第２通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ２０１において、第２通信方式の利用は可能ではないと判断された場合、ステップＳ２０３に処理が進められる。ステップＳ２０３において、第３通信方式の利用が可能であるか否かが判断される。ステップＳ２０３において、第３通信方式の利用が可能であると判断された場合、ステップＳ２０４に処理が進められる。ステップＳ２０４において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ２０４において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ２０５に処理が進められる。

この場合、第３通信方式で通信可能であり、第３通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であるため、ステップＳ２０５においては、第３通信方式で、サービスの登録と更新が行われると設定される。

一方、ステップＳ２０４において、ＡＰＤＵコマンドフォーマットが利用できないと判断された場合、ステップＳ２０６に処理が進められる。ステップＳ２０６において、第１通信方式の利用が可能であるか否かが判断される。ステップＳ２０６において、第１通信方式の利用が可能であると判断された場合、ステップＳ２０７に処理が進められる。ステップＳ２０７において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ２０７において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ２０８に処理が進められる。

この場合、第３通信方式、第１通信方式、および第１通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ２０８においては、第３通信方式または第１通信方式で、サービスの登録が行われ、第１通信方式におけるＡＰＤＵコマンドで、サービス名の更新が行われると設定される。

一方、ステップＳ２０３において、第３通信方式が利用できないと判断された場合、ステップＳ２０９に処理が進められる。ステップＳ２０９において、第１通信方式の利用が可能であるか否かが判断される。ステップＳ２０９において、第１通信方式の利用が可能であると判断された場合、ステップＳ２１０に処理が進められる。ステップＳ２１０において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ２１０において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ２１１に処理が進められる。

この場合、第１通信方式、および第１通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ２１１においては、第１通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ２０９において、第１通信方式が利用できないと判断された場合、ステップＳ２１３に処理が進められる。この場合、第１通信方式、第２通信方式、および第３通信方式の全ての通信方式で通信が行えない、換言すれば、リーダライタ２０２がサポートしている通信方式でＣＬＦ２２４と通信を行うことができないと判断されたときであるので、ステップＳ２１３において、通信不可と判断される。

一方、ステップＳ２０６において、第１通信方式の利用が可能ではないと判断された場合、ステップＳ２０７またはステップＳ２１０において、ＡＰＤＵコマンドフォーマットの利用が可能ではないと判断された場合、ステップＳ２１２に処理が進められる。このような場合は、ＡＰＤＵコマンドフォーマットの利用ができないと判断されたことを意味する。よって、ＵＩＣＣ２２２に何らかの機能を設けることにより、レジストリ２５３の更新を実現すると、ステップＳ２１２において設定される（ＵＩＣＣ２２２の付加機能を用いた更新を行うと設定される）。

［通信方式の第６の決定処理について］
通信方式の第６の決定処理として、第３通信方式、第１通信方式、第２通信方式の順で通信方式の利用が可能であるか否かを判断し、利用可能であると判断されたときに、その通信方式を選択することで通信方式が決定される場合について図２２のフローチャートを参照して説明する。

ステップＳ２５１において、第３通信方式の利用が可能であるか否かが判断される。ステップＳ２５１において、第３通信方式の利用が可能であると判断された場合、ステップＳ２５２に処理が進められる。ステップＳ２５２において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ２５２において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ２５３に処理が進められる。

この場合、第３通信方式の利用が可能であり、第３通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であるため、第３通信方式で、サービスの登録と更新が行われるとステップＳ２５３において設定される。

一方、ステップＳ２５２において、ＡＰＤＵコマンドフォーマットが利用できないと判断された場合、ステップＳ２５４に処理が進められる。ステップＳ２５４において、第１通信方式の利用が可能であるか否かが判断される。ステップＳ２５４において、第１通信方式の利用が可能であると判断された場合、ステップＳ２５５に処理が進められる。ステップＳ２５５において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ２５５において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ２５６に処理が進められる。

この場合、第３通信方式、第１通信方式、および第１通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ２５６においては、第３通信方式と第１通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ２５４において、第１通信方式の利用は可能ではないと判断された場合、ステップＳ２５７に処理が進められる。ステップＳ２５７において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ２５７において、第２通信方式の利用が可能であると判断された場合、ステップＳ２５８に処理が進められる。

この場合、第３通信方式と第２通信方式の利用が可能であると判断されたことになるので、ステップＳ２５８においては、第３通信方式と第２通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ２５５において、ＡＰＤＵコマンドフォーマットの利用が可能ではないと判断された場合、ステップＳ２５９に処理が進められる。ステップＳ２５９において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ２５９において、第２通信方式の利用が可能であると判断された場合、ステップＳ２６０に処理が進められる。

この場合、第３通信方式、第１通信方式、および第２通信方式の利用が可能であると判断され、第３通信方式と第１通信方式は、ともにＡＰＤＵコマンドフォーマットの利用が可能ではないと判断されたことになるので、ステップＳ２６０においては、第３通信方式または第１通信方式で、登録を行い、第２通信方式で更新の処理を実現すると設定される。

一方、ステップＳ２５１において、第３通信方式の利用は可能ではないと判断された場合、ステップＳ２６２に処理が進められる。ステップＳ２６２において、第１通信方式の利用が可能であるか否かが判断される。ステップＳ２６２において、第１通信方式の利用が可能であると判断された場合、ステップＳ２６３に処理が進められる。ステップＳ２６３において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ２６３において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ２６４に処理が進められる。

この場合、第１通信方式、および第１通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ２６４においては、第１通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ２６２において、第１通信方式が利用できないと判断された場合、ステップＳ２６５に処理が進められる。ステップＳ２６５において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ２６５において、第２通信方式の利用が可能であると判断された場合、ステップＳ２６６に処理が進められる。

この場合、第２通信方式の利用が可能であると判断されたことになるので、ステップＳ２６６においては、第２通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ２６３において、ＡＰＤＵコマンドフォーマットの利用が可能ではないと判断された場合、ステップＳ２６７に処理が進められる。ステップＳ２６７において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ２６７において、第２通信方式の利用が可能であると判断された場合、ステップＳ２６８に処理が進められる。

この場合、第１通信方式、第２通信方式の利用が可能であると判断されたことになるので、ステップＳ２６８においては、第１通信方式で、登録を行い、第２通信方式で更新の処理を実現すると設定される。

一方、ステップＳ２６５において、第２通信方式の利用は可能ではないと判断された場合、ステップＳ２６９に処理が進められる。この場合、第１通信方式、第２通信方式、および第３通信方式の全ての通信方式で通信が行えない、換言すれば、リーダライタ２０２がサポートしている通信方式でＣＬＦ２２４と通信を行うことができないと判断されたときであるので、ステップＳ２６９において、通信不可と判断される。

一方、ステップＳ２５７、ステップＳ２５９、またはステップＳ２６７において、第２通信方式の利用が可能ではないと判断された場合、ステップＳ２６１に処理が進められる。これらのステップで第２通信方式の利用が可能ではないと判断された場合は、ＡＰＤＵコマンドフォーマットの利用ができないと判断されたことを意味する。

このような場合、ＵＩＣＣ２２２に何らかの機能を設けることにより、レジストリ２５３の更新を実現すると設定される（ＵＩＣＣ２２２の付加機能を用いた更新を行うと設定される）。

［通信方式の第７の決定処理について］
通信方式の第７の決定処理として、第３通信方式、第２通信方式、第１通信方式の順で通信方式の利用が可能であるか否かを判断し、利用可能であると判断されたときに、その通信方式を選択することで通信方式が決定される場合について図２３のフローチャートを参照して説明する。

ステップＳ３０１において、第３通信方式の利用が可能であるか否かが判断される。ステップＳ３０１において、第３通信方式の利用が可能であると判断された場合、ステップＳ３０２に処理が進められる。ステップＳ３０２において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ３０２において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ３０３に処理が進められる。

この場合、第３通信方式で通信可能であり、第３通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であるため、第３通信方式で、登録と更新が行われると、ステップＳ３０３において設定される。

一方、ステップＳ３０２において、ＡＰＤＵコマンドフォーマットが利用できないと判断された場合、ステップＳ３０４に処理が進められる。ステップＳ３０４において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ３０４において、第２通信方式の利用が可能であると判断された場合、ステップＳ３０５に処理が進められる。

この場合、第３通信方式と第２通信方式の利用が可能であると判断されたことになるので、ステップＳ３０５においては、第３通信方式と第２通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ３０４において、第２通信方式が利用できないと判断された場合、ステップＳ３０６に処理が進められる。ステップＳ３０６において、第１通信方式の利用が可能であるか否かが判断される。ステップＳ３０６において、第１通信方式の利用が可能であると判断された場合、ステップＳ３０７に処理が進められる。ステップＳ３０７において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ３０７において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ３０８に処理が進められる。

この場合、第３通信方式、第１通信方式、および第１通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ３０８においては、第３通信方式または第１通信方式で、サービスの登録を行い、第１通信方式におけるＡＰＤＵコマンドフォーマットで、サービス名の登録を行うと設定される。

一方、ステップＳ３０１において、第３通信方式の利用は可能ではないと判断された場合、ステップＳ３１０に処理が進められる。ステップＳ３１０において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ３１０において、第２通信方式の利用が可能であると判断された場合、ステップＳ３１１に処理が進められる。

この場合、第２通信方式の利用が可能であると判断されたことになるので、ステップＳ３１１においては、第２通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ３１０において、第２通信方式が利用できないと判断された場合、ステップＳ３１２に処理が進められる。ステップＳ３１２において、第１通信方式の利用が可能であるか否かが判断される。ステップＳ３１２において、第１通信方式の利用が可能であると判断された場合、ステップＳ３１３に処理が進められる。ステップＳ３１３において、ＡＰＤＵコマンドフォーマットの利用が可能であるか否かが判断される。ステップＳ３１３において、ＡＰＤＵコマンドフォーマットの利用が可能であると判断された場合、ステップＳ３１４に処理が進められる。

この場合、第１通信方式、および第１通信方式におけるＡＰＤＵコマンドフォーマットの利用が可能であると判断されたことになるので、ステップＳ３１４においては、第１通信方式で、登録と更新の処理を実現すると設定される。

一方、ステップＳ３１２において、第１通信方式の利用は可能ではないと判断された場合、ステップＳ３１５に処理が進められる。この場合、第３通信方式、第２通信方式、および第１通信方式の全ての通信方式で通信が行えない、換言すれば、リーダライタ２０２がサポートしている通信方式でＣＬＦ２２４と通信を行うことができないと判断されたときであるので、ステップＳ３１５において、通信不可と判断される。

一方、ステップＳ３０６において、第１通信方式の利用が可能ではないと判断された場合、ステップＳ３０７またはステップＳ３１３において、ＡＰＤＵコマンドフォーマットの利用が可能ではないと判断された場合、ステップＳ３０９に処理が進められる。このような場合は、ＡＰＤＵコマンドフォーマットの利用ができないと判断されたことを意味する。よって、ＵＩＣＣ２２２に何らかの機能を設けることにより、レジストリ２５３の更新を実現すると、ステップＳ３０９において設定される（ＵＩＣＣ２２２の付加機能を用いた更新を行うと設定される）。

［通信方式の第８の決定処理について］
通信方式の第８の決定処理として、携帯電話機２０１と通信を行い、携帯電話機２０１がサポートしている通信方式に関する情報を取得することで、通信方式が決定される場合について図２４のフローチャートを参照して説明する。

ステップＳ３５１において、第３通信方式の利用が可能であるか否かが判断される。ステップＳ３５１において、第３通信方式の利用が可能であると判断された場合、ステップＳ３５２に処理が進められる。ステップＳ３５２において、通信方式の情報交換が行われる。

この場合、ステップＳ３５１において、第３通信方式の利用が可能であると判断されているため、第３通信方式で、携帯電話機２０１と通信が行われ、携帯電話機２０１とリーダライタ２０２が互いにサポートしている通信方式の情報の交換が行われる。

例えば、リーダライタ２０２が、携帯電話機２０１に対して、携帯電話機２０１がサポートしている通信方式を通知するように指示するコマンドを、第３通信方式で携帯電話機２０１に出し、携帯電話機２０１が、その受信されたコマンドに対応して、自己がサポートしている通信方式を通知することで、通信方式の情報の交換が行われる。

または、第３通信方式で、リーダライタ２０２が、リーダライタ２０２自身がサポートしている通信方式を携帯電話機２０１に通知し、その通知を受けた携帯電話機２０１が、通知されてきた通信方式の中で自己がサポートしている通信方式を選択し、その選択した情報をリーダライタ２０２に返すことで、互いにサポートしている通信方式の情報交換が行われる。

ステップＳ３５２において、通信方式の情報交換が行われると、ステップＳ３５３に処理が進められる。ステップＳ３５３において、情報交換の結果、取得された通信方式の中から、処理内容が決定される。この処理内容とは、例えば、第３通信方式で、登録と更新の処理を実行するといった内容である。

一方、ステップＳ３５１において、第３通信方式の通信が可能ではないと判断された場合、ステップＳ３５４に処理が進められる。ステップＳ３５４において、第２通信方式の利用が可能であるか否かが判断される。ステップＳ３５４において、第２通信方式の利用が可能であると判断された場合、ステップＳ３５２に処理が進められる。

ステップＳ３５２における処理については上述したが、この場合、第２通信方式が用いられて、通信方式の情報交換が行われる点が、上述した場合と異なる。そして、ステップＳ３５３において、情報交換の結果得られた通信方式に関する情報から、処理内容が決定される。

一方、ステップＳ３５４において、第２通信方式の通信が可能ではないと判断された場合、ステップＳ３５５に処理が進められる。ステップＳ３５５において、第１通信方式の利用が可能であるか否かが判断される。ステップＳ３５５において、第１通信方式の利用が可能であると判断された場合、ステップＳ３５２に処理が進められる。

ステップＳ３５２における処理については上述したが、この場合、第１通信方式が用いられて、通信方式の情報交換が行われる点が、上述した場合と異なる。そして、ステップＳ３５３において、情報交換の結果得られた通信方式に関する情報から、処理内容が決定される。

一方、ステップＳ３５５において、第１通信方式の通信が可能ではないと判断された場合、ステップＳ３５６に処理が進められる。この場合、第１通信方式、第２通信方式、および第３通信方式の利用が可能ではないと判断されたことになるので、ステップＳ３５６において、携帯電話機２０１とは通信が不可能であると判断され、処理が終了される。

このように、リーダライタ２０２が複数の通信方式で通信が行えるように構成されている場合、まず複数の通信方式のうちの１つの通信方式が選択され、その通信方式でＵＩＣＣ２２２と通信が可能であるか否かが判断される。そして、通信が可能と判断されたときに、その通信方式で、ＵＩＣＣ２２２と通信方式に関する情報交換が行われ、その情報交換の結果が用いられて通信方式が選択される。

なおここでは、第３通信方式、第２通信方式、第１通信方式の順で、利用が可能であるか否かが判断されるとして説明したが、この順番に限定されることを意味するものではない。

ここでは、通信方式の決定処理として、第１の決定処理乃至第８の決定処理を例にあげて説明したが、これらの決定処理のうち、どの決定処理が用いられて処理が行われるかは、リーダライタ２０２の設計段階や、設置される場所などにより決定されればよい。

また、例えば、ユーザが通信方式を設定することができる場合、そのユーザが設定した通信方式により、第１の決定処理乃至第８の決定処理から決定処理が選択されるようにしても良い。例えば、第２の決定処理乃至第８の決定処理は、始めに、第１通信方式、第２通信方式、または第３通信方式のうちのいずれかの通信方式の利用が可能であるか否かを判断している。よって、ユーザにより選択された通信方式が、一番始めに利用可能であるか否かを判断する決定処理が選択されるようにしても良い。

例えばユーザが第１通信方式を選択した場合、図１８のフローチャートに示した第２の決定処理が開始されるようにしても良いし、図１９のフローチャートに示した第３の決定処理が開始されるようにしても良い。また、この場合、図２４のフローチャートに示した第８の決定処理において、第１通信方式が一番始めに利用可能であるか否かが判断される決定処理が実行されるようにしても良い。

［登録、更新に係わる処理について］
上記した処理が実行されることにより、サービスの登録を行う通信方式とレジストリ２５３の更新(サービス名の登録処理)を行う通信方式とが決定される。ここで、上記した処理の結果、設定される可能性のある通信方式の組み合わせを列挙する。

第１の組み合わせ（例えば、図２３のステップＳ３１４で設定）
登録、更新、ともに第１通信方式で行う（第１通信方式でＡＰＤＵコマンドフォーマットが利用できる）
第２の組み合わせ（例えば、図２３のステップＳ３１１で設定）
登録、更新、ともに第２通信方式で行う
第３の組み合わせ（例えば、図２３のステップＳ３０３で設定）
登録、更新、ともに第３通信方式で行う（第３通信方式でＡＰＤＵコマンドフォーマットが利用できる）

第４の組み合わせ（例えば、図１８のステップＳ５５で設定）
登録は、第１通信方式で行い、更新は、第２通信方式で行う（第１通信方式はＡＰＤＵコマンドフォーマットを利用できない）
第５の組み合わせ（例えば、図２２のステップＳ２６０で設定）
登録は、第１通信方式または第３通信方式で行い、更新は、第２通信方式で行う（第１通信方式と第３通信方式はＡＰＤＵコマンドフォーマットを利用できない）
第６の組み合わせ（例えば、図２３のステップＳ３０５で設定）
登録は、第３通信方式で行い、更新は、第２通信方式で行う（第３通信方式はＡＰＤＵコマンドフォーマットを利用できない）

第７の組み合わせ（例えば、図１８のステップＳ５８で設定）
登録は、第１通信方式で行い、更新は、第３通信方式で行う（第１通信方式はＡＰＤＵコマンドフォーマットを利用できない）
第８の組み合わせ（例えば、図２３のステップＳ３０８で設定）
登録は、第３通信方式で行い、更新は、第１通信方式で行う（第３通信方式はＡＰＤＵコマンドフォーマットを利用できない）

第９の組み合わせ（例えば、図２３のステップＳ３０９で設定）
付加機能で実現する（ＵＩＣＣ２２２側に機能を付加して登録、更新を行う）

このように、９通りの組み合わせが設定される可能性がある。また、上記した通信方式の決定処理では、有線に関しては説明していないが、有線、例えば、図９に示した通信路３５３であり、ホスト２２１から有線のＵＡＲＴ２２３経由での通信もある。

ここで、上記したように、第３アプリケーション２５６が第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９を提供するアプリケーションである場合を例にあげて説明する。またここでは、第３アプリケーション２５６に、第３−１サービス２５７を追加登録するような場合（図１４を参照して説明したような場合）を例にあげて説明する。

図２５に示したようなコマンドの組み合わせで第３−１サービス２５７の登録と更新を行うことが考えられる。図２５を参照するに、番号１の組み合わせで利用される通信方式は、第１通信方式または第２通信方式である場合である。番号１の組み合わせは、上記した第１の組み合わせまたは第２の組み合わせに該当する。

番号１の組み合わせにおいては、ＡＰＤＵコマンドフォーマットが送受信可能であるため、サービスの登録やサービス名の登録は、ＡＰＤＵコマンドフォーマットが用いられる。この際、サービスの登録には、設定された通信方式（この場合、第１通信方式または第２通信方式）で用いられるＡＰＤＵコマンドフォーマットにおけるパケットと、第３アプリケーション２５６の独自のコマンドである第３コマンドを関連付けたデータが生成され、送受信される。具体的には、この際、サービスの登録には、第３コマンドをＡＰＤＵコマンドフォーマットでラッピングしたものが用いられる。また、サービス名の登録（レジストリ２５３の更新）には、ＡＰＤＵコマンドが用いられる。

番号２の組み合わせで利用される通信方式は、第３通信方式である場合である。番号２の組み合わせは、上記した第３の組み合わせに該当する。番号２の組み合わせにおいては、ＡＰＤＵコマンドフォーマットと第３パケットの送受信が可能であるため、サービスの登録やサービス名の登録は、ＡＰＤＵコマンドフォーマットと第３パケットが用いられる。この際、サービスの登録は、第３コマンドが用いられる。また、サービス名の登録には、ＡＰＤＵコマンドが用いられ、そのパケットは、第３通信方式におけるＡＰＤＵコマンドフォーマットが用いられる。

また、番号２の組み合わせの場合、番号１の組み合わせの場合と同じく、サービスの登録は、第３コマンドをＡＰＤＵコマンドフォーマットでラッピングしたものが用いられるようにし、サービス名の登録（レジストリ２５３の更新）には、第３通信方式におけるＡＰＤＵコマンドが用いられるようにすることも可能である。

番号３の組み合わせで利用される通信方式は、第１通信方式と第３通信方式の組み合わせか、第２通信方式と第３通信方式との組み合わせである。番号３の組み合わせは、上記した第５乃至第８の組み合わせに該当する。番号３の組み合わせにおいては、ＡＰＤＵコマンドフォーマットと第３パケットの送受信が可能であるため、サービスの登録やサービス名の登録は、ＡＰＤＵコマンドフォーマットと第３パケットが用いられる。

この際、第３通信方式がＡＰＤＵコマンドフォーマットに対応していれば、番号２の組み合わせと同じく、サービスの登録は、第３コマンドが用いられ、サービス名の登録には、ＡＰＤＵコマンドが用いられる。また、第３通信方式がＡＰＤＵコマンドフォーマットに対応していていなければ、サービスの登録は、第３コマンドをＡＰＤＵコマンドフォーマットでラッピングしたものが用いられ、サービス名の登録には、ＡＰＤＵコマンドが用いられる。この際、第３コマンドをラッピングするＡＰＤＵコマンドフォーマットの送受信は、ＡＰＤＵコマンドフォーマットに対応している第１通信方式または第２通信方式に基づいて行われる。

番号４乃至６の組み合わせで利用される通信方式は、有線である。番号４の組み合わせは、ＡＰＤＵコマンドフォーマットが送受信可能なときであり、番号１の組み合わせと同じく、サービスの登録は、第３コマンドをＡＰＤＵコマンドフォーマットでラッピングしたものが用いられ、サービス名の登録には、ＡＰＤＵコマンドが用いられる。

番号５の組み合わせは、ＡＰＤＵコマンドフォーマットと有線プロトコルにおけるパケットが送受信可能なときであり、サービスの登録は、第３コマンドが用いられ、サービス名の登録には、ＡＰＤＵコマンドが用いられる。または、番号４の組み合わせと同じく、サービスの登録は、第３コマンドをＡＰＤＵコマンドフォーマットでラッピングしたものが用いられ、サービス名の登録には、ＡＰＤＵコマンドが用いられるようにすることも可能である。

番号６の組み合わせで利用される通信方式は、有線であり、有線プロトコルにおけるパケットが送受信可能なときである。番号７の組み合わせで利用される通信方式は、第３通信方式であり、第３パケットが送受信可能なときである。この番号６と番号７の組み合わせは、上記した第９の組み合わせに該当する。これは、独自のパケットでしか通信方式としてサポートしていないときである。

独自のパケットでの通信方式しか用いることができない場合、リーダライタ２０２側で、パケットなどを加工するだけでは、サービスの登録やサービス名の登録ができないため、ＵＩＣＣ２２２側に機能を付加して登録、更新が行われる。例えば、新たなサービス登録データ、新たなコマンド（またはブロック）が、アプリケーション経由（この場合、第３アプリケーション２５６経由）で、サービスの登録と更新が行われる。

次に、ステップＳ２（図１６）で実行されるサービスの登録と、ステップＳ３で実行されるサービス名の登録に、それぞれ係わる処理について、携帯電話機２０１側で実行される処理と合わせて、フローチャートを参照して説明する。

［第３通信方式と第２通信方式を用いたサービスとサービス名の登録について］
まず、図２６と図２７のフローチャートを参照して、第３通信方式の利用が可能であると判断されたが、第３通信方式におけるＡＰＤＵコマンドフォーマットは利用不可であると判断され、かつ、第２通信方式の利用が可能であると判断された場合について説明する。

このように設定されるのは、例えば、図２３に示したフローチャートの処理が実行された結果、ステップＳ３０５において、第３通信方式／第２通信方式で実現すると設定されたときであり、上記した第５の組み合わせや第６の組み合わせに該当する。また、図２５においては、番号３の組み合わせに該当する。

図２６のフローチャートは、サービスの登録を行うときの処理である。まず。ステップＳ６０１において、携帯電話機２０１は、カードを起動する。カードとは、ＵＩＣＣ２２２のことである。なお、カードの起動は、ステップＳ１（図１６）において、通信方式の決定の処理が、リーダライタ２０２側で行われたとき、リーダライタ２０２と携帯電話機２０１（ＣＬＦ２２４）は通信を行っているので、その時点で、携帯電話機２０１側ではカードが起動されている。

ステップＳ５５１において、リーダライタ２０２は、第３通信方式での応答を、携帯電話機２０１（ＣＬＦ２２４）に対して要求する。そのような要求をステップＳ６０２において受信した携帯電話機２０１（ＣＬＦ２２４）は、ステップＳ６０３において、レスポンスを返す。この場合、第３通信方式で通信を行うことを了承することを示す応答である。そのようなレスポンスを携帯電話機２０１（ＣＬＦ２２４）から、ステップＳ５５２において受信したリーダライタ２０２は、ステップＳ５５３において、データの読み出しの要求を携帯電話機２０１（ＣＬＦ２２４）に対して行う。

携帯電話機２０１（ＣＬＦ２２４）は、リーダライタ２０２からのデータの読み出しの要求を、ステップＳ６０４において受信すると、その要求を、第３アプリケーション２５６に転送する。この場合、第３通信方式で通信が行われているので、リーダライタ２０２からの第３パケットは、ＣＬＦ２２４（図９）を介して、第３アプリケーション２５６に供給される。すなわちこの場合、図９を参照して説明した通信路３５１で、リーダライタ２０２からのパケットが、第３アプリケーション２５６に供給される。

ステップＳ６３１において、そのような通信路３５１（図９）で、リーダライタ２０２からのデータの読み出し要求を受信すると、ステップＳ６３２において、その読み出し要求で要求されているデータを読み出し、携帯電話機２０１（ＣＬＦ２２４）に供給する。ＣＬＦ２２４は、ステップＳ６０６において、第３アプリケーション２５６から供給されたデータを、リーダライタ２０２からの要求に対応するレスポンスとして送信する。

ステップＳ５５４において、携帯電話機２０１（ＣＬＦ２２４）からのデータをレスポンスとして取得したリーダライタ２０２は、ステップＳ５５５において、読み出したデータに含まれるカードの状態を確認し、登録すべきサービスを確認する。例えば、第３−１サービス２５７（図１４）が登録されていない場合、第３−１サービス２５７のデータを準備する。データが準備されると、ステップＳ５５６において、サービスの登録が実行される。

この場合、第３通信方式で、第３パケットが用いられてサービスの登録が行われるため、サービス登録のためのデータを、第３パケットにパケット化し、第３通信方式で、携帯電話機２０１（ＣＬＦ２２４）に送信する処理が、ステップＳ５５６において実行される。この処理は、例えば、図１４を参照して説明したサービス登録データ４３１を送信する処理に該当する。リーダライタ２０２からサービス登録のためのデータを、ステップＳ６０７において受信した携帯電話機２０１（ＣＬＦ２２４）は、受信されたデータを、第３アプリケーション２５６に供給する。

第３アプリケーション２５６は、供給されたデータを、ステップＳ６３３における処理で取得すると、ステップＳ６３４において、サービスの登録の処理を実行する。ステップＳ６３４において、第３アプリケーション２５６が、サービスの登録を実行し、その結果、成功した場合、または失敗した場合、その登録処理の結果が、ステップＳ６３５において出される。

その結果を、ステップＳ６０８における処理で受信した携帯電話機２０１（ＣＬＦ２２４）は、ステップＳ６０９において、第３アプリケーション２５６における登録処理の結果を、レスポンスとしてリーダライタ２０２に送信する。ステップＳ５５７において、携帯電話機２０１（ＣＬＦ２２４）からのレスポンスが、リーダライタ２０２に受信される。

リーダライタ２０２は、レスポンスが、携帯電話機２０１側でサービスの登録が成功したことを示しているときには、引き続き、サービス名の登録（図２７を参照して後述）の処理を開始し、失敗したことを示しているときには、再度、例えば、ステップＳ５５６の処理を実行することでサービスの登録の処理を実行する。また、携帯電話機２０１（ＣＬＦ２２４）からのレスポンスが、失敗したことを示しているような場合、その時点で設定されている通信方式とは異なる通信方式で、サービスの登録の処理が実行されるようにしても良い。ここでは、サービスの登録の処理は成功したとして説明を続ける。

サービスの登録の処理が成功したと判断されると、サービス名の登録のための処理が開始される。このサービス名の登録のための処理について、図２７のフローチャートを参照して説明する。この場合、上記したサービスの登録の処理は、第３通信方式で行われ、サービス名の登録の処理は、第２通信方式で行われるため、通信方式の切り替えを行う必要がある。そこで、リーダライタ２０２は、ステップＳ５７１において、携帯電話機２０１（ＣＬＦ２２４）に対して、第２通信方式での応答を要求する。

そのような要求を、ステップＳ６６１において受信した携帯電話機２０１（ＣＬＦ２２４）は、ステップＳ６６２において、レスポンスを返す。この場合、第２通信方式で通信を行うことを了承することを示す応答である。そのようなレスポンスを携帯電話機２０１（ＣＬＦ２２４）から、ステップＳ５７２において受信したリーダライタ２０２は、ステップＳ５７３において、第２通信方式を選択するように、携帯電話機２０１に対して要求を出す。

そのような要求を、ステップＳ６６３において受信した携帯電話機２０１（ＣＬＦ２２４）は、第２通信方式での通信を行う状態に切り替え、その後、第２通信方式を選択したことを示すレスポンス（応答）を、リーダライタ２０２に対して行う。そのレスポンスを、ステップＳ５７４において受信したリーダライタ２０２は、受信したレスポンスを確認することで、携帯電話機２０１側で第２通信方式が選択されたことを認識する。

このようにして、リーダライタ２０２と携帯電話機２０１（ＣＬＦ２２４）が、第２通信方式で通信できる状態になると、ステップＳ５７５において、リーダライタ２０２は、サービス名の登録のための処理を実行する。例えばこの場合、第３−１サービス２５７を登録したので、この第３−１サービス２５７のサービス名を、携帯電話機２０１のレジストリ２５３に登録するためのパケットが生成される。また、この生成されるパケットは、第２通信方式に対応したパケット、すなわちこの場合、ＡＰＤＵコマンドフォーマットに準拠したデータをパケットに含んでいる。

ステップＳ５７５において、リーダライタ２０２によりサービス名の登録の処理が実行されることにより、リーダライタ２０２から携帯電話機２０１に対して送信されたデータは、ステップＳ６６５において、携帯電話機２０１により受信される。受信されたデータは、アプリケーションマネージャ２５２に供給される。

ＡＰＤＵコマンドフォーマットであるので、ＣＬＦ２２４により受信されたＡＰＤＵコマンドフォーマットは、ＵＩＣＣハードウェア２５１を介して、アプリケーションマネージャ２５２に供給される。ＡＰＤＵコマンドフォーマットは、アプリケーションマネージャ２５２で処理することが可能なパケットである。アプリケーションマネージャ２５２は、ステップＳ６９１において、ＡＰＤＵコマンドフォーマットでの、サービス名の登録に係わるデータを受信すると、ステップＳ６９２において、サービス名の登録の処理を実行する。

アプリケーションマネージャ２５２は、受信されたＡＰＤＵコマンドに従い、レジストリ２５３に、新たに登録されたサービスの名称や、種別などの情報を書き込む。これらの名称や種別などの情報は、リーダライタ２０２から供給されるＡＰＤＵコマンドに含まれている。

ステップＳ６９２において、サービス名などの登録が終了すると、アプリケーションマネージャ２５２は、その処理結果を、ステップＳ６９３の処理としてＣＬＦ２２４に出力する。ＣＬＦ２２４は、ステップＳ６６６において、アプリケーションマネージャ２５２からの処理結果を受信すると、レスポンスとして、リーダライタ２０２に送信する。このレスポンスには、サービス名の登録の処理が成功したか否かを示す情報が含まれている。

そのような結果を、ステップＳ５７６において受信したリーダライタ２０２は、レスポンスが成功したことを示しているときには、サービス名の登録の完了を認識し、処理を終了する。一方、受信されたレスポンスが、失敗したことを示しているときには、再度、例えば、ステップＳ５７５の処理が実行されることでサービス名の登録の処理が再度実行される。

このようにして、第３アプリケーション２５６で提供される第３−１サービス２５７を登録する際、その登録自体は、第３アプリケーション２５６で扱える第３通信方式（第３パケットおよび第３コマンド）が用いられて行われる。その一方で、第３−１サービス２５７に関する情報、例えば第３−１サービス２５７の名称や提供されるサービスの種別などの情報は、アプリケーションマネージャ２５２が扱える第２通信方式（ＡＰＤＵコマンド）が用いられて行われる。

このように、サービスの登録が行われ、サービス名の登録が行われることで、アプリケーションマネージャ２５２が、レジストリ２５３で、登録されたサービスに関連する情報を管理することができるようになる。レジストリ２５３で、登録されているサービスの情報が管理されることで、ビューワ２４１が、それらの情報を閲覧することが可能となる。ビューワ２４１が閲覧できるようになることで、その情報が、ユーザに提供することが可能となる。

そのため、第３アプリケーション２５６が総合サービスを提供するためのアプリケーションであり、第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９の３つのサービスを提供するような場合、これら３つのサービスがあることを、ユーザに提示することが可能となる。その提示の仕方については後述するとし、先に、通信方法の組み合わせとして、他の組み合わせが設定された場合のサービスとサービス名の登録について説明する。

［第２通信方式を用いたサービスとサービス名の登録について］
次に、図２８と図２９のフローチャートを参照して、第２通信方式のみが利用可能であると判断された場合（第２通信方式で、サービスとサービス名の登録を行うと設定された場合）について説明する。

このように設定されるのは、例えば、図２３に示したフローチャートの処理が実行された結果、ステップＳ３１１において、第２通信方式で実現すると設定されたときである。図２８のフローチャートは、サービスの登録を行うときの処理である。まずステップＳ８０１において、携帯電話機２０１は、カード（ＵＩＣＣ２２２）を起動する。

ステップＳ７０１において、リーダライタ２０２は、携帯電話機２０１（ＣＬＦ２２４）に対して、第２通信方式での応答を要求する。そのような要求を、ステップＳ８０２において受信した携帯電話機２０１（ＣＬＦ２２４）は、ステップＳ８０３において、レスポンスを返す。この場合、第２通信方式で通信を行うことを了承することを示す応答である。そのようなレスポンスを携帯電話機２０１（ＣＬＦ２２４）から、ステップＳ７０２において受信したリーダライタ２０２は、ステップＳ７０３において、第２通信方式を選択するように、携帯電話機２０１（ＣＬＦ２２４）に対して要求を出す。

そのような要求を、ステップＳ８０４において受信した携帯電話機２０１（ＣＬＦ２２４）は、第２通信方式での通信を行う状態にし、その後、第２通信方式を選択したことを示すレスポンス（応答）を、ステップＳ８０５において、リーダライタ２０２に対して行う。そのレスポンスを、ステップＳ７０４において受信したリーダライタ２０２は、受信したレスポンスを確認することで、携帯電話機２０１側で第２通信方式が選択されたことを認識する。

このようにして、リーダライタ２０２と携帯電話機２０１（ＣＬＦ２２４）が、第２通信方式で通信できる状態になると、ステップＳ７０５において、リーダライタ２０２は、データの読み出しの要求を携帯電話機２０１（ＣＬＦ２２４）に対して行う。

携帯電話機２０１（ＣＬＦ２２４）は、リーダライタ２０２からのデータの読み出しの要求を、ステップＳ８０６において受信すると、その要求を、第３アプリケーション２５６に転送する。この場合、第２通信方式で通信が行われているので、リーダライタ２０２からはＡＰＤＵコマンドフォーマットでラッピングされた第３コマンドが、ＣＬＦ２２４（図９）を介して、ＵＩＣＣハードウェア２５１に供給され、さらにＵＩＣＣハードウェア２５１から、アプリケーションマネージャ２５２に供給される。アプリケーションマネージャ２５２は、供給されたＡＰＤＵコマンドフォーマットを処理することで、第３コマンドを取り出し、第３アプリケーション２５６に供給する。

このパケットの流れは、図９を参照して説明した通信路３５２である。第３アプリケーション２５６は、通信路３５２を介してリーダライタ２０２からのデータの読み出し要求（第３コマンド）を受信すると、ステップＳ８３２において、その第３コマンドで要求されているデータを読み出し、携帯電話機２０１（ＣＬＦ２２４）に供給する。ＣＬＦ２２４は、ステップＳ８０７において、第３アプリケーション２５６から供給されたデータを受信すると、そのデータを、ステップＳ８０８で、リーダライタ２０２からの要求に対応するレスポンスとして送信する。

ステップＳ７０６において、携帯電話機２０１からのデータをレスポンスとして取得したリーダライタ２０２は、ステップＳ７０７において、登録されているサービスのデータを読み出す。例えば、サービス一覧情報として、第３−１サービス２５７（図１４）が登録されていない場合、第３−１サービス２５７を登録すべきことが判明する。データを読み出し、カードの状態を確認され、登録すべきサービスが無い事を確認すると、と、ステップＳ７０８において、サービスの登録が実行される。

この場合、第２通信方式で、ＡＰＤＵコマンドフォーマットが用いられてサービスの登録が行われるため、サービス登録のためのデータを、ＡＰＤＵコマンドフォーマットにパケット化し、第２通信方式で、携帯電話機２０１に送信するための処理が、ステップＳ７０８において実行される。リーダライタ２０２からサービス登録のためのデータを、ステップＳ８０９において受信した携帯電話機２０１（アプリケーションマネージャ２５２）は、受信されたデータを、第３アプリケーション２５６に供給する。

第３アプリケーション２５６は、供給されたデータを、ステップＳ８３３における処理で取得すると、ステップＳ８３４において、サービスの登録の処理を実行する。ステップＳ８３４において、第３アプリケーション２５６が、サービスの登録を実行し、その結果、成功した場合、または失敗した場合、その登録処理の結果が、ステップＳ８３５において、アプリケーションマネージャ２５２に対して出される。

その結果を、ステップＳ８１０における処理で受信したアプリケーションマネージャ２５２は、ステップＳ８１１において、第３アプリケーション２５６における登録処理の結果を、レスポンスとしてリーダライタ２０２に送信する。ステップＳ７０９において、携帯電話機２０１からのレスポンスが、リーダライタ２０２に受信される。

リーダライタ２０２は、受信されたレスポンスが、携帯電話機２０１側でサービスの登録が成功したことを示しているときには、引き続き、サービス名の登録（図２９を参照して後述）の処理を開始し、失敗したことを示しているときには、再度、例えば、ステップＳ７０８の処理を実行することでサービスの登録の処理を実行する。ここでは、サービスの登録の処理は成功したとして説明を続ける。

このようにして、第３アプリケーション２５６が提供する第３−１サービス２５７を登録するとき、設定された通信方式で用いられるパケット（ＡＰＤＵコマンドフォーマット）と、第３アプリケーション２５６独自のコマンドが関連付けられたデータが生成され、そのデータが授受されることで、登録処理が実行される。換言すれば、第３アプリケーション２５６が提供する第３−１サービス２５７を登録するとき、第３アプリケーション２５６で扱われる第３コマンドを、ＡＰＤＵコマンドフォーマットでラッピングして、登録処理が実行される。

このような処理が実行されることによりサービスが登録された後、引き続き行われる登録されたサービスに関する情報、例えば、サービス名やサービス種別に関する情報が登録される際の処理について図２９のフローチャートを参照して説明する。

この場合、サービスが登録されるときに、既に第２通信方式で通信が行われているため、リーダライタ２０２と携帯電話機２０１が、第２通信方式で通信できる状態になっている。そのため、第２通信方式で通信を開始するための処理は、省略され、ステップＳ７５１において、リーダライタ２０２は、サービス名の登録のための処理を実行する。

例えばこの場合、第３−１サービス２５７を登録したので、この第３−１サービス２５７のサービス名を、ＵＩＣＣ内のアプリケーションマネージャ２５２のレジストリ２５３に登録するためのパケットが生成される。また、この生成されるパケットは、第２通信方式に対応したパケット、すなわちこの場合、ＡＰＤＵコマンドを含んでいるパケットになる。

ステップＳ７５１において、リーダライタ２０２によりサービス名の登録の処理が実行されることにより、リーダライタ２０２から携帯電話機２０１に対して送信されたデータは、ステップＳ８５１において、携帯電話機２０１（ＣＬＦ２２４）により受信される。受信されたデータは、アプリケーションマネージャ２５２に供給される。

ＡＰＤＵコマンドフォーマットであるので、ＣＬＦ２２４により受信されたＡＰＤＵコマンドは、ＵＩＣＣハードウェア２５１を介して、アプリケーションマネージャ２５２に供給される。アプリケーションマネージャ２５２は、ステップＳ８８１において、ＡＰＤＵコマンドでの、サービス名の登録に係わるデータを受信すると、ステップＳ８８２において、サービス名の登録の処理を実行する。

アプリケーションマネージャ２５２は、受信されたＡＰＤＵコマンドに従い、レジストリ２５３に、新たに登録されたサービスの名称や、種別などの情報を書き込む。これらの名称や種別などの情報も、リーダライタ２０２から供給されるＡＰＤＵコマンドに含まれている。

ステップＳ８８２において、サービス名などの登録が終了すると、アプリケーションマネージャ２５２は、その処理結果を、ステップＳ８８３の処理としてＣＬＦ２２４に出力する。ＣＬＦ２２４は、ステップＳ８５２において、アプリケーションマネージャ２５２からの処理結果を受信すると、ステップＳ８５３において、レスポンスとして、リーダライタ２０２に送信する。このレスポンスには、サービス名の登録の処理が成功したか否かを示す情報が含まれる。

そのような結果を、ステップＳ７５２において受信したリーダライタ２０２は、レスポンスが成功したことを示しているときには、サービス名の登録の完了を認識し、処理を終了する。一方、受信されたレスポンスが、失敗したことを示しているときには、再度、例えば、ステップＳ７５１の処理が実行されることでサービス名の登録の処理が再度実行される。

このようにして、第３アプリケーション２５６で提供される第３−１サービス２５７を登録する際、第３アプリケーション２５６で扱える第３コマンドが、アプリケーションマネージャ２５２が扱うことができるＡＰＤＵコマンドフォーマットでラッピングされたものが用いられて行われる。

また、第３−１サービス２５７に関する情報、例えば第３−１サービス２５７の名称や提供されるサービスの種別などの情報は、アプリケーションマネージャ２５２が扱えるＡＰＤＵコマンドが用いられて行われる。

このように、サービスの登録が行われ、サービス名の登録が行われることで、アプリケーションマネージャ２５２が、レジストリ２５３で、登録されたサービスに関連する情報を管理することができるようになる。レジストリ２５３で、登録されているサービスの情報が管理されることで、その情報をビューワ２４１で閲覧することが可能となる。ビューワ２４１が閲覧できるようになることで、その情報を、ユーザに提供することが可能となる。

［アプリケーションマネージャによる処理について］
ＵＩＣＣ２２２の中には、アプリケーションマネージャと称されるアプリケーションを備えるものがある。図３０に示したＵＩＣＣ２２２は、アプリケーションマネージャ６０１を備える。このアプリケーションマネージャ６０１は、所定のＩＣカード上のＩＣチップ、この場合、ＵＩＣＣ２２２に格納されているアプリケーションであり、ＵＩＣＣ２２２内の中のリソース管理や、外部装置からのアプリケーションのダウンロード等の制御を行う。

ＵＩＣＣ２２２がアプリケーションマネージャ６０１を備える場合、各無線対応のアプリケーション、例えば、第１アプリケーション２５４、第２アプリケーション２５５、または第３アプリケーション２５６は、インストール時に、アプリケーションマネージャ６０１経由で搭載される。各無線対応のアプリケーションは、動作時には、アプリケーションの実行環境（Runtime Environment）から動作権限を譲渡される（選択される）必要がある。また、各アプリケーションの実行時には、直接アプリケーションマネージャ６０１からの影響はないように構成されている。

図３０に示すように、例えば、第２アプリケーション２５５や第３アプリケーション２５６がインストールされるときには、アプリケーションマネージャ６０１を介して、ＡＰＤＵコマンドが用いられてインストールされる。インストール後、アプリケーションマネージャ６０１により、第３アプリケーション２５６が選択された場合、第３アプリケーション２５６が動作中になり、アプリケーションマネージャ６０１を介さないで動作することになる。この場合、直接的に第３アプリケーション２５６に第３パケットが供給される。

このようなアプリケーションマネージャ６０１を備えるＵＩＣＣ２２２である場合、図２８のフローチャートを参照して説明した、第２通信方式で、第３−１サービス２５７を登録する際の処理は、図３１に示したフローチャートに基づく処理となる。

リーダライタ２０２側で実行されるステップＳ１００１乃至Ｓ１００９の処理は、図２８のステップＳ７０１乃至Ｓ７０９と同様の処理である。すなわち、リーダライタ２０２側の処理は、ＵＩＣＣ２２２がアプリケーションマネージャ６０１を備えているか否かに係わらず、同様の処理でサービスの登録を行うことができる。このことは、ＵＩＣＣ２２２がアプリケーションマネージャ６０１を備えているか否かに係わらず、同一のインフラを利用して、サービスの登録を行えることを意味する。

携帯電話機２０１側で実行されるステップＳ１１１１乃至Ｓ１１１５の処理は、図２８のステップＳ８０１乃至Ｓ８０５と同様の処理である。すなわち、第２通信方式で通信を行うための設定が、リーダライタ２０２側と、携帯電話機２０１側で行われる処理に関しては、ＵＩＣＣ２２２がアプリケーションマネージャ６０１を備えているか否かに係わらず同様に行われる。

その処理の結果、第２通信方式で通信が行える状態にされると、ステップＳ１００５において、リーダライタ２０２は、携帯電話機２０１（ＣＬＦ２２４）に対して、データの読み出しの要求を出す。携帯電話機２０１（ＣＬＦ２２４）は、リーダライタ２０２からのデータの読み出しの要求を、ステップＳ１１１６において受信すると、その要求を、アプリケーションマネージャ６０１に転送する。

アプリケーションマネージャ６０１は、ステップＳ１１５２において、要求されたデータをＣＬＦ２２４に出力する。ＣＬＦ２２４は、そのデータを、ステップＳ１１１７で受信すると、ステップＳ１１１８において、リーダライタ２０２からの要求に対応するレスポンスとして送信する。ステップＳ１００６において、携帯電話機２０１（ＣＬＦ２２４）からのデータをレスポンスとして取得したリーダライタ２０２は、ステップＳ１００７において、登録するサービスのデータを読み出す。

この場合、第２通信方式で、ＡＰＤＵコマンドが用いられてサービスの登録が行われるため、サービス登録のためのデータを、ＡＰＤＵコマンドフォーマットにパケット化し、第２通信方式で、携帯電話機２０１に送信する処理が、ステップＳ１００８において実行される。リーダライタ２０２からサービス登録のためのデータを、ステップＳ１１１９において受信した携帯電話機２０１（ＣＬＦ２２４）は、受信されたデータを、アプリケーションマネージャ６０１に供給する。

アプリケーションマネージャ６０１は、ステップＳ１１５３において、供給されたデータを、さらに第３アプリケーション２５６に転送する。第３アプリケーション２５６は、供給されたデータを、ステップＳ１１８１における処理で取得すると、ステップＳ１１８２において、サービスの登録の処理を実行する。ステップＳ１１８２において、第３アプリケーション２５６が、サービスの登録を実行し、その結果、成功した場合、または失敗した場合、その登録処理の結果が、ステップＳ１１８３において、アプリケーションマネージャ６０１に渡される。

アプリケーションマネージャ６０１は、ステップＳ１１５４において、第３アプリケーション２５６からの結果を受取、ステップＳ１１５５において、ＣＬＦ２２４に対して登録処理の結果が渡される。その結果を、ステップＳ１１２０における処理で受信したＣＬＦ２２４は、ステップＳ１１２１において、第３アプリケーション２５６における登録処理の結果を、レスポンスとしてリーダライタ２０２に送信する。ステップＳ１００９において、携帯電話機２０１からのレスポンスが、リーダライタ２０２に受信されることで、サービスの登録処理が終了される。

このようにして、アプリケーションマネージャ６０１を備えるＵＩＣＣ２２２に対しても、リーダライタ２０２は、アプリケーションマネージャ６０１を備えていないＵＩＣＣ２２２に対して行う処理と同様の処理を実行することで、サービスの登録を行うことができる。

このようにしてサービスの登録が行われると、引き続き、サービス名の登録の処理が実行されるが、その処理は、図２９に示したフローチャートにおける処理と同様に行われるため、ここではその説明を省略する。すなわち、アプリケーションマネージャ６０１を備えるＵＩＣＣ２２２に対して、サービス名を登録する際の処理は、アプリケーションマネージャ６０１を備えていないＵＩＣＣ２２２に対してサービス名を登録する際の処理と同様に行われる。

さらに換言すれば、サービス名の登録は、アプリケーションマネージャ２５２の処理により行われるため、アプリケーションマネージャ６０１における処理はなく、そのために、携帯電話機２０１側の処理としては、アプリケーションマネージャ６０１がない場合と同様の処理でサービス名の登録が行われる。

［付加機能を用いたサービスとサービス名の登録について］
次に、図３２のフローチャートを参照し、付加機能を用いたサービスとサービス名の登録について説明する。ここでは、第３通信方式の利用が可能であると判断されたが、第３通信方式でのＡＰＤＵコマンドフォーマットは利用できないと判断された場合であり、第３アプリケーション２５６で提供される第３−１サービス２５７が登録される場合を例にあげて説明する。

第３通信方式の利用が可能であると判断されたが、第３通信方式でのＡＰＤＵコマンドフォーマットは利用できないと判断された場合とは、第３アプリケーション２５６独自のパケットの送受信を行うと判断したときである。このような判断がなされるのは、例えば、図２０に示したフローチャートの処理が実行された結果、ステップＳ１６３において、付加機能で実現すると設定されたときである。

図３２に示したフローチャートにおける処理のうち、リーダライタ２０２側で実行されるステップＳ１３０１乃至Ｓ１３０７の処理は、図２６に示したフローチャートのステップＳ５５１乃至Ｓ５５７と同様に行われる。よってここでは、その詳細な説明は省略する。また、図３２に示したフローチャートにおける処理のうち、携帯電話機２０１側で実行されるステップＳ１４０１乃至Ｓ１４０９の処理は、図２６に示したフローチャートのステップＳ６０１乃至Ｓ６０９と同様に行われため、ここでは、その説明は省略する。

また、図３２に示したフローチャートにおける処理のうち、第３アプリケーション２５６側で実行されるステップＳ１４５１，Ｓ１４５２の処理は、図２６に示したフローチャートのステップＳ６３１，Ｓ６３２と同様に行われため、ここでは、その説明は省略する。

ステップＳ１４５３において、第３アプリケーション２５６は、リーダライタ２０２から、第３パケットで送信されてきたサービスの登録に関する第３コマンドを受信すると、ステップＳ１４５４において、その第３コマンドに基づき、サービスの登録を実行する。第３アプリケーション２５６は、サービスの登録を終了すると、ステップＳ１４５５において、サービス名を生成し、アプリケーションマネージャ２５２に対して出力する。

すなわちこの場合、第３アプリケーション２５６が、リーダライタ２０２からのコマンドを処理することで、サービス名（サービスに関する情報）を生成し、アプリケーションマネージャ２５２に供給する。

図９を再度参照する。第３アプリケーション２５６の通信プロトコルのパケットしか送受信できない場合、通信路３５１により、独自のパケットの送受信がされることになる。すなわち、リーダライタ２０２からの第３パケットは、ＣＬＦ２２４により受信され、ＣＬＦ２２４からＵＩＣＣハードウェア２５１を経由して第３アプリケーション２５６へと供給される。よって、第３アプリケーション２５６にはアクセスできるため、第３アプリケーション２５６で提供される第３−１サービス２５７を登録することはできる。

しかしながら、アプリケーションマネージャ２５２にアクセスするための通信プロトコルがないので、アプリケーションマネージャ２５２で管理されているレジストリ２５３に、リーダライタ２０２から直接的にアクセスすることができない。一方で、第３アプリケーション２５６は、レジストリ２５３にアクセスする通信路３５４を有する。

そこで、第３アプリケーション２５６が、アプリケーションマネージャ２５２に指示を出し、アプリケーションマネージャ２５２がレジストリ２５３内の情報を更新できるようにする。すなわちこの場合、第３アプリケーション２５６の処理により、サービス名やサービス種別などの情報を、レジストリ２５３に登録するようにする。

そのために、ステップＳ１４５５（図３２）において、第３アプリケーション２５６により、サービス名が生成される。サービス名を生成するためのデータは、リーダライタ２０２から供給され、その供給自体の処理は、ステップＳ１３０６におけるサービスの登録を実行する際に行われても、予め第３アプリケーションが用意しているデータから自動生成しても良い。よって、リーダライタ２０２は、サービスを登録するためのデータと、サービス名を登録するためのデータを、第３パケットで携帯電話機２０１（第３アプリケーション２５６）に送信する。

また、第３アプリケーション２５６がサービス名を生成するためのコマンドが用意され、そのコマンドが、リーダライタ２０２から送信されても良い。サービスを登録するタイミングで、自動的に第３アプリケーションが引き続き、処理を続けても良いまた、第３アプリケーション２５６側は、そのようなコマンドを認識し、処理を実行できるように構成されている。ステップＳ１４５５においては、このようなコマンドが、第３アプリケーション２５６で解釈され、サービス名が生成され、アプリケーションマネージャ２５２に出力される。

ステップＳ１４８１において、第３アプリケーション２５６からのサービス名と、そのサービス名をレジストリ２５３に登録するように指示するコマンドを、ＡＰＩ（Application Program Interface）経由で受信したアプリケーションマネージャ２５２は、ステップＳ１４８２において、受信されたコマンドに基づき、レジストリ２５３に、受信されたサービス名を登録する。その登録が終了されると、ステップＳ１４８３において、登録が終了したことを示すデータが、第３アプリケーション２５６に出される。

第３アプリケーション２５６は、ステップＳ１４５６において、アプリケーションマネージャ２５２から、登録の終了を示すデータを受信すると、ステップＳ１４５７において、ＣＬＦ２２４に対して、サービスの登録とサービス名の登録が終了したことを示すデータをレスポンスとして出力する。ＣＬＦ２２４は、ステップＳ１４０８において、第３アプリケーション２５６からのレスポンスを受信すると、ステップＳ１４０９において、そのレスポンスを，リーダライタ２０２に転送する。

リーダライタ２０２は、ステップＳ１３０７において、レスポンスを受信し、そのレスポンスを解釈することで、登録の処理が終了したことを認識する。

このように、第３アプリケーション２５６で、サービス名の登録のための処理が実行される。このような処理を可能とするために、サービスの定義を以下のようにすることが考えられる。

パターン１として、上記したように、第３アプリケーション２５６が解釈できるコマンドを用意する。パターン１の場合、サービス登録の開始を示すスタートと、終わりを示すエンドをそれぞれ示すコマンドを用意し、そのスタートとエンドの間のサービス登録データのやり取りをサービスの単位として一括りにする定義が考えられる。

パターン２として、一連のサービス領域を作る行為を１つのサービス単位として自動的に判別することにする。この場合、１つのコマンドもしくはコマンドを結合させた１つの固まりによって生成されるサービス領域をサービスの単位として見る。

このようなサービスに対する定義とともに、サービスに対するサービス名の渡し方、換言すれば、ステップＳ１４５５で実行されるサービス名の生成と登録の仕方についても定義しておく必要がある。

パターン１として、サービス名の生成や登録を指示するコマンドを用意し、そのコマンドを第３アプリケーション２５６が解釈できるようにする。リーダライタ２０２側からコマンドを送信することで、サービス名の登録を、第３アプリケーション２５６に実行させることができるようになる。

パターン２として、新たな領域を用意することでサービス名の登録を行うことが考えられる。パターン２では、サービス名を入れる定義ブロックが規定し、その内容が解釈され、アプリケーションマネージャ２５２のレジストリ２５３が更新される。この場合も、リーダライタ２０２からブロックへの書き込みが必要となり、リーダライタ２０２からのインプットが必要である。換言すれば、リーダライタ２０２からのインプットにより更新が行われるため、リーダライタ２０２側で更新のタイミングなどを制御することができる。

パターン３として、対応表を保持することでサービス名の登録を行うことが考えられる。パターン３では、システムコードやサービスコードなどの領域やサービスを識別するための番号とサービス名の対応表を、第３アプリケーション２５６が保持し、サービスが登録されるときに、そのサービスに対応する識別する番号とサービス名が対応表から読み出されることで、サービス名の登録が行われる。また、保持されている対応表に記載されていない新たなサービスが提供されるような場合、対応表自体が更新される。この対応表の更新も、リーダライタ２０２側からコマンドを送信するなどの処理が実行されることで行うことが可能である。

このようないずれかのパターンが採用され、サービス名の生成や登録の処理が実行される。第３アプリケーション２５６は、生成したサービス名を、ＡＰＩ経由でレジストリ２５３に登録する。

［サービス名の表示に関する処理について］
このようにして、サービスとサービス名が登録されることで、ビューワ２４１により、登録されているサービスの情報をユーザに提示するとき、図３３または図３４に示すような画面で情報を提示することができるようになる。

図３３に示すようにビューワ２４１は、アプリケーションマネージャ２５２が認識した第１アプリケーション２５４、第２アプリケーション２５５、第３アプリケーション２５６を認識する。さらにレジストリ２５３内には、上記した処理が実行されたことで、第３アプリケーション２５６には、第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９がサービスに関する情報が登録されているため、ビューワ２４１は、それらのサービスも認識する。

このような認識の結果、ビューワ２４１は、第１アプリケーション２５４が提供するサービスの名称である“第１サービス”、第２アプリケーション２５５が提供するサービスの名称である“第２サービス”、および第３アプリケーション２５６が提供するサービスの名称である“第３サービス”を、ディスプレイ４０１に表示させる。

さらに第３アプリケーション２５６は、総合サービスであり、第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９を提供できるように構成され、これらの情報もレジストリ２５３を参照することで認識されているため、これらの情報もディスプレイ４０１上に表示される。

すなわち図３３に示したように、第３アプリケーション２５６に対応する“第３サービス”という名称の下に、第３−１サービス２５７に対応する“第３−１サービス“という名称、第３−２サービス２５８に対応する“第３−２サービス“という名称、および第３−３サービス２５９に対応する“第３−３サービス“という名称が、“第３サービス”という名称に関連付けられた表示がされる。

このような表示がされることにより、ユーザは、第３サービスには、第３−１サービス、第３−２サービス、および第３−３サービスの３つのサービスがあることを認識することができる。このような表示が、レジストリ２５３で、第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９に対応するサービス名を管理することで可能となる。

他の表示例として、図３４を示す。図３４に示した表示例では、まず第１アプリケーション２５４が提供するサービスの名称である“第１サービス”と第２アプリケーション２５５が提供するサービスの名称である“第２サービス”がディスプレイ４０１に表示されている。さらに、その下に、第３−１サービス２５７に対応する“第３−１サービス“という名称、第３−２サービス２５８に対応する“第３−２サービス“という名称、および第３−３サービス２５９に対応する“第３−３サービス“という名称が表示されている。

このような表示がされることで、ユーザは、第１サービス、第２サービス、第３−１サービス、第３−２サービス、および第３−３サービスの５つのサービスがあることを認識することができる。この場合、ユーザは、第３アプリケーション２５６が、３つのサービスを提供することを認識することなく、第１サービスや第２サービスと同列に、第３−１サービス、第３−２サービス、および第３−３サービスを認識することが可能となる。このような表示が、レジストリ２５３で、第３−１サービス２５７、第３−２サービス２５８、および第３−３サービス２５９に対応するサービス名を管理することで可能となる。

このような表示の違いは、レジストリ２５３で、どのようにして、サービス名が管理されるかにより決定される。そこで、サービス名の管理の仕方について説明する。まず、サービスにダミーのＡＩＤを付け、そのダミーＡＩＤでサービスを管理することが考えられる。またそのダミーＡＩＤが、レジストリ２５３に書き込まれることで、サービスに関する情報が、レジストリ２５３で管理されるようにする。ＡＩＤは、Application IDentifierの略である。

ＵＩＣＣ２２２に複数のアプリケーションが登録されている場合、例えば、各アプリケーションに付けられたファイルの「名前」が偶然同じであったとき、正常に動作せず、ファイル破壊が生じる可能性がある。そのようなことを防ぐために、アプリケーション識別子（AID）が付与され、アプリケーションの一意性が確保されるようにされている。このように、アプリケーションは、ＡＩＤで管理されている。また一意性を確保するために、ＡＩＤは、ユニークな値とされている。

ＡＩＤは、ＩＳＯ７８１６−５で規定されており、１６バイトで構成され、５バイトはＲＩＤ、残り１１バイトはＰＩＸで構成されている。ＲＩＤは、アプリケーションの提供者であり、例えば所定の企業が取得したユニークなＩＤである。そのため、ＲＩＤは、基本的に１企業につき、１つのＩＤとされている。ＲＩＤはRegistered application provider Identifierの略称であり、ＰＩＸはProprietary application Identifier eXtensionの略称である。

ＰＩＸは、ＲＩＤを割り当てられた会社内でユニークに採番することができるＩＤである。そのため、第３アプリケーション２５６では、以下のルールに基づいて、ダミーＡＩＤを生成する。ダミーＡＩＤとは、実際には存在しないアプリケーションに割り当てられたＡＩＤである。また、ダミーＡＩＤは、ビューワ２４１から、ＵＩＣＣ２２２に登録されているアプリケーションを表示することを目的として設けられる。

よって、このダミーＡＩＤは、ユーザが選択してアプリケーションが起動されるようなことには利用されない。また、第３アプリケーション２５６内のサービスには、実際にはＡＩＤが存在しない。

そしてダミーＡＩＤは、以下の構成とされる。
ダミーＡＩＤ＝（ＲＩＤ）＋（第３アプリケーション２５６に割り当てられた値（ＰＩＸの一部）＋会社が規定するユニークなサービス番号（ＰＩＸの一部）

このような構成を有するダミーＡＩＤは、他のアプリケーションに影響を及ぼすことがない。ダミーＡＩＤが、レジストリ２５３に書き込まれることにより、第３アプリケーション２５６以外の、例えば第１アプリケーション２５４が何らかの影響を与えるようなことがなく、第３アプリケーション２５６の枠組み内で、ダミーＡＩＤを構成することができる。そのため、ダミーＡＩＤを指定してアプリケーションが呼ばれた場合、ダミーの元となった第３アプリケーションのＡＩＤと部分的に一致するため、第３アプリケーションが呼ばれても良い。

このように構成されるダミーＡＩＤが、ＡＰＩ経由で、第３アプリケーション２５６からレジストリ２５３に登録される。ビューワ２４１は、レジストリ２５３に管理されているダミーＡＩＤが見えるため、そのダミーＡＩＤが割り当てられているアプリケーションを認識することができる。

この場合、ダミーＡＩＤに割り当てられているのはサービスであるため、結果的に、ビューワ２４１は、登録されているサービスを認識することになる。このような認識ができるようになることで、ビューワ２４１の処理により提供される画面は、例えば、図３３や図３４に示したような画面とすることが可能となる。

ダミーＡＩＤ自体の構成や、ダミーＡＩＤのサービスに対する付け方などにより、図３３に示したように、所定のアプリケーションで実現されるサービスが階層的に表示されるようにすることも、図３４に示したように、所定のアプリケーションで実現されるサービスと同階層で表示されるようにすることもできる。

［効果について］
このように、ＵＩＣＣ２２２に、例えば、第３アプリケーション２５６で提供されるサービスが単独で登録されていても、異なる携帯電話機２０１で共通して用いられるビューワ２４１から、個々のサービスの存在を確認できるようになる。このような確認が行えるようになることで、上記したように、ユーザ側に個々のサービスの存在を認識させるための画面を提示することが可能となる。

またその表示は、例えば、図３４に示したように、他のアプリケーションで提供されるサービスと同列のサービスとしてユーザに参照させることができる表示とすることができる。また、新たなサービスであっても、既に登録されているサービスと同列のサービスとして表示することが可能となる。または、図３３に示したように、所定のアプリケーションで提供されるサービスは、そのアプリケーションと関連付けられた、階層的な表示とすることも可能となる。

また、サービスの存在確認が行えるようになれば、必要時に対向のアプリケーションの追加を行うことが可能となる。すなわち、サービスとアプリケーションの関係性に自由度を持たせることが可能となる。

またサービスの登録やサービス名の登録は、既存のインフラをできる限り生かして行うことができる。よって、ＵＩＣＣ２２２でサービスを管理するようにシステムが移行しても、移行後に係るコストを低減させることが可能となる。さらに、インフラを生かすことができることで、大幅な変更を伴わないでシステムの移行などが実行できるようになるため、ユーザにとっても、開発者側にとっても、システム移行にともなう混乱を生じさせるようなことを防ぐことが可能となる。

［記録媒体について］
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

図３５は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。コンピュータにおいて、ＣＰＵ（Central Processing Unit）１００１、ＲＯＭ（Read Only Memory）１００２、ＲＡＭ（Random Access Memory）１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェイス１００５が接続されている。入出力インターフェイス１００５には、入力部１００６、出力部１００７、記憶部１００８、通信部１００９、及びドライブ１０１０が接続されている。

入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記憶部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインタフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１０１１を駆動する。

以上のように構成されるコンピュータでは、ＣＰＵ１００１が、例えば、記憶部１００８に記憶されているプログラムを、入出力インターフェイス１００５及びバス１００４を介して、ＲＡＭ１００３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ（ＣＰＵ１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

コンピュータでは、プログラムは、リムーバブルメディア１０１１をドライブ１０１０に装着することにより、入出力インターフェイス１００５を介して、記憶部１００８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１００９で受信し、記憶部１００８にインストールすることができる。その他、プログラムは、ＲＯＭ１００２や記憶部１００８に、あらかじめインストールしておくことができる。

なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

なお、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。

２０１ 携帯電話機， ２０２ リーダライタ， ２２１ ホスト， ２２２ ＵＩＣＣ， ２２３ ＵＡＲＴ， ２２４ ＣＬＦ， ２５１ ＵＩＣＣハードウェア， ２５２ アプリケーションマネージャ， ２５３ レジストリ， ２５４ 第１アプリケーション， ２５５ 第２アプリケーション， ２５６ 第３アプリケーション， ５０１ 通信制御部， ５０２ 通信方式決定部， ５０３ サービス登録部， ５０４ 更新処理部

Claims (12)

1. 所定のアプリケーションを記憶する記憶部と、
   前記アプリケーションで提供されるサービスに関する情報を管理する管理部と、
   他の装置から、前記サービスを登録するためのデータを受信する通信部と、
   前記通信部を介し前記データを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録するサービス登録部と、
   前記サービス登録部により登録された前記サービスに関する情報を生成する生成部と、
   前記生成部により生成された前記情報で、前記管理部に管理されている前記情報を更新する更新部と
   を備える通信装置。
2. 前記通信部は、前記他の装置と非接触で通信を行う
   請求項１に記載の通信装置。
3. 前記情報の表示を制御する制御部をさらに備える
   請求項１に記載の通信装置。
4. 前記制御部の制御に基づき前記情報の表示を行う表示部をさらに備える
   請求項３に記載の通信装置。
5. 前記生成部は、前記アプリケーションにより前記他の装置から供給されるコマンドが処理されることで、前記サービスに関する情報を生成する
   請求項１に記載の通信装置。
6. 前記生成部と前記更新部は、予め規定されている前記サービスに関する情報を入れる定義ブロックの内容から前記管理部に管理されている前記情報を更新する
   請求項１に記載の通信装置。
7. 前記生成部は、前記サービスを識別する番号と、前記サービスに関する情報が対応付けられた対応表を備え、その対応表を参照して、前記サービスに関する情報を生成する
   請求項１に記載の通信装置。
8. 前記アプリケーションに登録されたサービスは、前記生成部によって採番されたダミーＡＩＤで管理され、
   前記管理部は、通常のＡＩＤと前記ダミーＡＩＤを管理する
   請求項１に記載の通信装置。
9. 前記更新部は、前記サービスの削除によって、前記管理部が管理する前記ダミーＡＩＤに対応したサービスに関する情報を更新する
   請求項８に記載の通信装置。
10. 前記サービスを登録するためのデータは、前記アプリケーション独自の通信方式におけるパケットである
    請求項１に記載の通信装置。
11. 所定のアプリケーションを記憶する記憶部、前記アプリケーションで提供されるサービスに関する情報を管理する管理部、および他の装置と通信を行う通信部を少なくとも備える通信装置の通信方法において、
    前記他の装置から、前記サービスを登録するためのデータを前記通信部で受信し、
    前記データを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、
    登録された前記サービスに関する情報を生成し、
    生成された前記情報で、前記管理部に管理されている前記情報を更新する
    ステップを含む通信方法。
12. 所定のアプリケーションを記憶する記憶部、前記アプリケーションで提供されるサービスに関する情報を管理する管理部、および他の装置と通信を行う通信部を少なくとも備える通信装置に、
    前記他の装置から、前記サービスを登録するためのデータを前記通信部で受信し、
    前記データを受信した場合、そのデータに基づき、前記アプリケーションの処理により前記サービスを登録し、
    登録された前記サービスに関する情報を生成し、
    生成された前記情報で、前記管理部に管理されている前記情報を更新する
    ステップを含む処理を実行させるコンピュータが読み取り可能なプログラム。

Images