(57)【特許請求の範囲】
【請求項１】
サーバモードにあるチップカードと、各々が同じＩＰアドレスを有する複数のクライアントのいずれか１つまたは複数との間の、移動無線通信装置内での通信方法であって、
前記の複数のクライアントの各々について、クライアントポートに結びつけられるソケットを生成することと、
クライアント識別子を、結びつけられている複数のクライアントポートの各々に関連付けることと、
前記チップカードが前記の複数のクライアントを区別することができるように、前記チップカードが前記各クライアント識別子を利用できるようにすることと
を有する方法。
【請求項２】
前記チップカードが、サーバモードにあるＵＩＣＣを含む、請求項１に記載の方法。
【請求項３】
前記複数のクライアントが前記移動無線通信装置内に備えられている、請求項１または２に記載の方法。
【請求項４】
特定のソケットに結びつけられるように割り当てられる前記クライアントポートが、前記移動無線通信装置によって割り当てられる、請求項１から３のいずれか１項に記載の方法。
【請求項５】
特定のソケットに結びつけられるように割り当てられる前記クライアントポートが、複数のポートの所定の選択肢から得られる、請求項１から３のいずれか１項に記載の方法。
【請求項６】
前記クライアント識別子を、移動無線通信装置とチップカードのインターフェイスが利用できるようにすることを含む、請求項１から５のいずれか１項に記載の方法。
【請求項７】
サーバと複数のクライアントの間のユニバーサルデータグラムプロトコル通信をサポートするようになっている、請求項１から６のいずれか１項または複数に記載の方法。
【請求項８】
チップカードとＵＤＰサーバモードのサポートが、ＡＰＤＵコマンドの信号伝達内に備えられている、請求項７に記載の方法。
【請求項９】
チップカードＵＤＰサーバモードのサポートが、オープンチャネルプロアクティブコマンドの信号伝達内に備えられている、請求項７または８に記載の方法。
【請求項１０】
必要に応じてＴＣＰ通信とＴＣＰソケットの生成をサポートするようになっている、請求項１から６のいずれか１項に記載の方法。
【請求項１１】
前記複数のクライアントのうちの１つから前記チップカードへ信号伝達メッセージが送信され、
前記信号伝達メッセージは、前記チップカードが前記複数のクライアントを区別できるように、結びつけられているソケットおよびクライアントポートに関連するクライアント識別子を含む、請求項１から１０のいずれか１項に記載の方法。
【請求項１２】
前記信号伝達メッセージは端末応答メッセージを含む、請求項１１に記載の方法。
【請求項１３】
前記信号伝達メッセージはデータを入手可能なメッセージを含む、請求項１１に記載の方法。
【請求項１４】
前記チップカードから前記複数のクライアントのうちの少なくとも１つに信号伝達メッセージが送信され、
前記信号伝達メッセージは、前記チップカードが前記複数のクライアントを区別できるように、結びつけられているソケットおよびクライアントポートに関連するクライアント識別子を含む、請求項１から１０のいずれか１項記載の方法。
【請求項１５】
前記信号伝達メッセージはデータ送信コマンド信号を含む、請求項１４に記載の方法。
【請求項１６】
前記信号伝達メッセージはデータ受信コマンド信号を含む、請求項１４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動無線通信装置内における通信方法、関連する移動無線通信装置、および移動無線通信装置内で生じる信号伝達に関する。
【背景技術】
【０００２】
携帯電話機などの移動無線通信装置は、加入者識別モジュール（ＳＩＭ）などのチップカードを、そしていわゆる３Ｇ電話機に関してはユニバーサルＩＣカード（ＵＩＣＣ）を長い間使用してきた。そのようなカードは一般に、発呼者と、ネットワークに関連する情報を含み、メモリおよびマイクロコントローラの機能を内蔵するように構成されている。
【０００３】
移動無線通信装置内で使用されるそのような周知のチップカードは、ますます高性能化されつつあり、追加の機能として、例えば、ＵＩＣＣが、移動無線通信装置である移動体装置（ＭＥ）上の近くであろうと、またはその移動体装置から離れていても、１つまたは複数のクライアントに対してサーバモードで動作できるように、チップカード内にサーバを備えることが含まれる。
【０００４】
そのようなチップカードは、クライアントと通信するためのそのようなサーバ機能を容易に備えることができるが、サーバが、チップカードサーバと同じＭＥ上に備えられた複数のローカルクライアントなど、同じＩＰアドレスを有する複数のクライアントのうちの１つまたは複数と通信することが要求される状況も生じる。
【０００５】
チップカードサーバとＭＥの間の通信は通常、ベアラ独立プロトコル（ＢＩＰ）によってサポートされる。しかし、ＢＩＰチャネルを介して送られる情報ペイロードは、信号送信を開始するクライアントを示す情報を含まず、そのため、サーバチップカードが、同じＩＰアドレスを共有する異なるクライアントから生じる複数のペイロードを区別できる本質的な方法はない。
【０００６】
伝送制御プロトコル（ＴＣＰ）をＢＩＰチャネル上で、サーバモードにある、例えばＵＩＣＣのためにサポートし、同じＩＰアドレスを共有する複数のクライアントが存在することが知られている。ここでは、単一の特定のＢＩＰチャネルが、各特定のＴＣＰ接続ごとに設けられている。しかし、複数の別個のＢＩＰチャネルを備えることが、ＭＥと、例えばチップカードの両方にとってかなり資源を消費し、かつ通常いくつかのバッファを備えることを必要とする、様々なクライアントからのデータを分離した状態にしておくために追加の備えをする必要がある限りにおいて不利益が生じる。
【０００７】
さらに、ＴＣＰをＢＩＰチャネル上でサポートすることに伴うオーバヘッドは、サーバチップカードＭＥインターフェイスが動作する比較的安全、かつセキュアな環境に関して不利なことに限定的であると分かることがある。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明は、サーバモードにあるチップカードと、各々が同じＩＰアドレスを有する複数のクライアントのうちのいずれか１つとの間の、移動無線通信装置内での通信方法であって、公知のそのような方法に優る利点を有する方法を提供しようとするものである。同様に、本発明は、関連する移動無線通信装置およびその移動無線通信装置内で生じる信号伝達であって、そのような、公知の装置および関連する信号伝達に優る利点を示す、関連する移動無線通信装置およびその移動無線通信装置内で生じる信号伝達を提供しようとするものである。
【課題を解決するための手段】
【０００９】
本発明の典型的態様によれば、サーバモードにあるチップカードと、各々が同じＩＰアドレスを有する複数のクライアントのいずれか１つまたは複数との間の、移動無線通信装置内での通信方法であって、複数のクライアントの各々について、クライアントポートに結びつけられるソケットを生成するステップと、クライアント識別子を、結びつけられている複数のクライアントポートの各々に関連付けるステップと、チップカードが複数のクライアントを区別することができるように、チップカードが各クライアント識別子を利用できるようにするステップと、を有する方法が提供される。
【００１０】
したがって、有利なことに、本発明は、ＵＩＣＣなどのチップカードが、移動無線通信装置内で管理されるソケット−ポートの対に基づいて、いくつかのクライアントを区別することを可能にすることが理解される。
【００１１】
また、本方法は、サーバモードにある、ＵＩＣＣを含むチップカードと、いくつかのクライアントとの間の通信に提供されてもよい。
【００１２】
さらに、本方法は、チップカードと、移動無線通信装置内に備えられた複数のクライアントとの間の通信を提供することができる。
【００１３】
本通信方法は、移動無線通信装置内のＢＩＰチャネルによってサポートされるように構成できることを、勿論理解されるべきである。
【００１４】
有利なことに、本発明の方法では、特定のクライアントソケットに結びつけられるクライアントポートは、移動無線通信装置によって割り当てることができる。
【００１５】
あるいは、特定のクライアントソケットに結びつけられるクライアントポートは、複数のポートの所定の選択から得ることができる。
【００１６】
さらに、本方法は、移動無線通信装置が、クライアントポートおよび対をなすクライアント識別子の情報を記憶するように構成することができる。
【００１７】
有利なことに、本方法は、クライアント識別子を移動無線通信装置チップカードインターフェイスが利用できるようにするステップを含むことができる。
【００１８】
好ましくは、本方法は、サーバと１つまたは複数のクライアントとの間の、ユニバーサルデータグラムプロトコル（ＵＤＰ）通信のサポートを含むことができる。
【００１９】
このようにして、ＵＤＰサーバモードにあるチップカードのサポートを、ＡＰＤＵコマンド信号伝達内に備えることができる。
【００２０】
さらに、チップカードＵＤＰサーバモードのサポートを、オープンチャネル（ｏｐｅｎ  ｃｈａｎｎｅｌ）プロアクティブコマンド信号伝達内に備えることができる。
【００２１】
あるいは、本方法は、必要ならばＴＣＰ通信をサポートすることおよびＴＣＰソケットを生成することを含むことができる。
【００２２】
このようにして、本方法は、サーバポート上の入力接続要求をモニタするステップをさらに含むことができる。
【００２３】
本方法は、元のサーバソケットを他の入力接続要求のために残しておくように、他のＴＣＰサーバソケットを、入力接続要求に応答して生成することも含むことができる。
【００２４】
本発明の他の代表的態様によれば、チップカードを有し、上記に定めた通信方法に従って動作するように構成された移動無線通信装置が提供される。上記に述べたそのような移動無線通信装置は、この方法を制御するためのソフトウェア命令を実行するように構成することができる。
【００２５】
本発明のまた他の代表的態様によれば、移動無線通信装置内のサーバモードにあるチップカードへの信号伝達メッセージであって、各々が同じＩＰアドレスを有する複数のクライアントのうちの１つから生じ、チップカードが複数のクライアントからのメッセージを区別できるように、結びつけられているソケットおよびクライアントポートに関連するクライアント識別子を含む信号伝達メッセージが提供される。
【００２６】
好ましくは、この信号伝達は端末応答メッセージを含む。
【００２７】
本発明のさらに他の代表的態様によれば、移動無線通信装置内のサーバモードにあるチップカードへの信号伝達メッセージであって、各々が同じＩＰアドレスを有する複数のクライアントのうちの１つから発せられ、前記チップカードが前記複数のクライアントを区別できるように、結びつけられているソケットおよびクライアントポートに関連するクライアント識別子を含む信号伝達メッセージが提供される。
【００２８】
有利には、この信号はデータ送信コマンド信号を含む。
【００２９】
理解されるように、移動無線通信装置内の機能によって、例えば移動無線通信装置内のソケットレイヤを介して、または特定の種類のアプリケーションに割り当てられた所定のポート番号を介して、複数のクライアントの各々にポート番号を割り当てることができる。
【００３０】
さらに、したがって、本出願は有利なことに、チップカードが移動無線通信装置内の機能に基づいていくつかのクライアントを区別することを可能にし、本発明の後方互換性を支援するように、既存のカードインターフェイスに関して生じる制約を有利に考慮に入れる構成を提供する。
【００３１】
本発明は特に、各々が同じＩＰアドレスを有するいくつかのクライアントを区別するために、単に移動無線通信装置ではなく、チップカードに所要の能力を与えるように、ポート番号を識別することと、移動無線通信装置とチップカードインターフェイス上の所要のビット／バイトを減らすことができる、単純な識別子に関連付けることと、そのインターフェイス上の既存のパラメータの範囲を拡張することなどの手順ステップの組合せに基づいている。
【００３２】
したがって、例えば文書ETSI TS 102 223の中で現在定められているＢＭＰチャネル上のＵＩＣＣサーバモードは、ＴＣＰモードの通信しかサポートしないのに対し、本発明は、例えば移動無線通信装置内にあり、かつＵＤＰに基づくどんなアプリケーションも、ＵＤＰサーバモードの範囲内で機能するように同様に構成されるチップカードと対話することができるように、そのような通信をサポートする特に有利な機構を提供するだけでなく、ＵＤＰモードの動作もサポートする。
【００３３】
したがって、ＵＤＰモードを使用することに関して生じる速度および効率の利点を、移動無線通信装置およびチップカードサーバインターフェイスとの関連で容易に使用することができ、ＴＣＰモードの追加のセキュリティおよび信頼性がいずれにせよ必要とされない可能性がある状況でも容易に使用することができる。
【図面の簡単な説明】
【００３４】
【図１】図１は、ＵＤＰが移動無線通信装置内およびチップカード内の両方でサポートされる状況についての、プロトコルスタックと処理フローの概略ブロック図である。
【図２】図２は、ＢＩＰだけがインターフェイスのチップカード側でサポートされるシナリオを状況についての、図１のものと同様のスタックおよび処理フローの図である。
【図３】図３は、本発明の一実施形態による、チップカードと移動無線通信装置内の複数のクライアントの間の信号伝達の図である。
【図４】図４は、本発明の他の実施形態による、チップカードと移動無線通信装置内の複数のクライアントの間の、同様の、しかし一部の信号伝達の図である。
【図５】図５は、ＵＤＰサーバモード内のチップカードのサポートを可能にする、端末プロファイルメッセージ内の修正された構造を示す図である。
【発明を実施するための形態】
【００３５】
以下、本発明を、添付図面を参照して、例示のみによって詳しく説明する。
【００３６】
規約ＥＴＳＩ ＴＳ １０２ ２２３ Ｒｅｌ-８の仕様を参照すると、サーバモードにあるＵＩＣＣに対するＢＩＰチャネルを経て、かつ移動無線通信装置移動用機器（ＭＥ）内のＴＣＰクライアントアプリケーションと、ＵＩＣＣ内のＴＣＰサーバとだけがＢＩＰチャネルを経て通信することができるようにＴＣＰをサポートすることが知られている。
【００３７】
しかし、各々が同じＩＰアドレスを有する複数のクライアントと、サーバモードにあるＵＩＣＣとが通信できる方法が不利なことに限定され、ＴＣＰモードだけを単にサポートことも同様に不適切かつ限定的であると分かることがある。
【００３８】
上記したことから理解されるように、本発明は、各クライアントがＵＤＰクライアントを含むことができ、サーバモードにあるＵＩＣＣがＵＩＣＣ  ＵＤＰサーバを含むことができるように、例えば、サーバモードにあるＵＩＣＣが、各々が同じＩＰアドレスを有する複数のクライアントのうちの１つまたは複数と確実に通信できる機構だけでなく、ＵＤＰを、ＢＩＰチャネルを経てサポートすることを可能にする機構も提供する。
【００３９】
本発明の２つの特定の代表的な実施形態にしたがって生じる信号伝達について以下にさらに説明する。ＵＤＰ／ＩＰがインターフェイスのＭＥ側およびＵＩＣＣ側の両方でサポートされる状況に対するプロトコルスタックおよび処理フローを示す図１をまず参照するが、図１はクライアント側の処理のみを示すことを理解すべきである。すなわち、クライアント（アプリケーション）１０と、送信元ポート番号および宛先ポート番号を含むことができるヘッダをもたらすＵＤＰスタック１２をその後に備えることと、ＢＩＰまたはイーサネットエミュレーション１６、およびユニバーサルシリアルバス（ＵＳＢ）接続などを含むことがある、あるいは含まない物理レイヤ１８へのその後の送出に先立つ、ＩＰサポート１４をその後に備えることが示されている。
【００４０】
しかし、次に図２を参照すると、ＵＤＰ／ＩＰまたは実際ＴＣＰスタックが備えられていないようにＵＩＣＣ側ではＢＩＰのみがサポートされる状況が図示されている。
【００４１】
図示のように、インターフェイスのクライアント側２０に、クライアント（アプリケーション）２４と、関連するＵＤＰ送信要求２６が設けられている。ＭＥは、ＵＩＣＣ側ではＢＩＰのみがサポートされていることを確認できるので、ＵＤＰレイヤ２６はＵＤＰ送信要求をＢＩＰレイヤ２８に単に転送する。ここで、ＢＩＰレイヤ２８は、ＵＤＰ送信要求からクライアント（アプリケーション）２４のデータを抽出し、クライアントポートを後述する識別子と関連付ける。
【００４２】
該データは次に、インターフェイスを介してＵＩＣＣ側に送信する準備ができる。
【００４３】
インターフェイスのＵＩＣＣ２２側では、物理レイヤは、例えば、ＵＳＢ３４を含み、その後ＢＩＰ３６を介してＵＩＣＣ内のサーバ３８に送られるデータを受け取る。
【００４４】
前に述べたように、２つの別個の実施形態に関して生じる信号伝達の特定の例を、本願の図３および図４に関してさらに述べる。
【００４５】
複数のクライアントの１つまたは複数からのデータの識別をＵＩＣＣ内で特に効率的に行うに際し、本発明は、特に、ＵＤＰをＢＩＰチャネル上でサポートするのに向いている。
【００４６】
しかし、本発明はＵＤＰをサポートすることに決して限定されないことを理解すべきである。例えば、ＵＩＣＣが入力データのクライアント送信元を求めることができ、かつデータを返信として適切なターゲットクライアントに送ることができるこの有利な方法は、ＵＤＰあるいはＴＣＰなどのどのような特定の通信方式にも限定されない。
【００４７】
しかし、そして単にさらに説明するために、ＵＤＰをサポートすることに関し、本発明は、端末プロファイルＡＰＤＵコマンド内でＵＩＣＣ  ＵＤＰサーバモードのサポートを提供することができ、そしてまたオープンチャネルプロアクティブコマンド内でＵＩＣＣ  ＵＤＰサーバモードをサポートするのを追加できることを理解すべきである。
【００４８】
要求に応じて、複数のＵＤＰクライアントアプリケーションのいずれか１つまたは複数は、ＵＤＰソケットを生成し、そして重要なことに、該ソケットを特定のポート番号に結びつけるように構成されている。該ポート番号は、ＭＥによって割り当てられても、または所定の範囲から事前に取得されてもよく、その後、特定のクライアントアプリケーションの送信元（すなわちクライアント）ポート番号として定め、すなわち同定することができる。
【００４９】
ＭＥはその後、以下「ＵＤＰクライアント識別子」と呼ぶ識別子を、前述のクライアント送信元ポート番号のそれぞれに関連付けるようにすることができる。
【００５０】
そのような送信元ポート番号とＵＤＰクライアント識別子の対は、必要に応じてＭＥ内に格納されたままにしてもよい。
【００５１】
ＵＩＣＣ内における、本発明の所望の識別機能を可能にするために、ＵＤＰクライアント識別子をＭＥ−ＵＩＣＣインターフェイスが利用できるようにすることができ、これは、例えばエンベロープイベントダウンロードデータ（Ｅｎｖｅｌｏｐｅ  Ｅｖｅｎｔ  Ｄｏｗｎｌｏａｄ  Ｄａｔａ）、受信データ（Ｒｅｃｅｉｖｅｄ  Ｄａｔａ）、データ送信コマンド（Ｓｅｎｄ  Ｄａｔａ  Ｃｏｍｍａｎｄ）および／または端末応答コマンド（Ｔｅｒｍｉｎａｌ  Ｒｅｓｐｏｎｓｅ  Ｃｏｍｍａｎｄ）によって行うことができる。
【００５２】
ＵＩＣＣはその後、このＵＤＰクライアント識別子に基づいて、いくつかのＵＤＰクライアントを識別することができる。
【００５３】
次に、図３を参照すると、第１のクライアント４０、第２のクライアント４２、メインＭＥプロセッサ４４、およびＵＤＰサーバモードにあるＵＩＣＣ４６の間にＭＥ内で生じる信号伝達の図が示されている。
【００５４】
電源投入シーケンスの間、ＭＥ４４は、「ＵＩＣＣ  ＵＤＰサーバモード」がＭＥ４４によってサポートされていることを示す自身の端末プロファイルメッセージ４８をＵＩＣＣ４６に送信する。
【００５５】
電源投入シーケンスが完了すると、端末プロファイルが送信された後の任意の時点とすることができるが、ＵＩＣＣ４６は、チャネルをＵＩＣＣ  ＵＤＰサーバモードで開く、ＵＩＣＣ４６の要望を示すオープンチャネルプロアクティブコマンド５０をＭＥ４４に送信する。具体的には、このコマンド５０は、関連するサーバポート番号、すなわちＵＤＰクライアントアプリケーションと通信するためにＵＤＰサーバ４６によって使用されるポートを含む。
【００５６】
ＭＥ４４はそのコマンドを受け取り、そして特に、上述のＵＤＰサーバポート番号を記憶する。この信号伝達手順内の後続のステップのために、ＭＥ４４は何らかのデータがこの特定のサーバポート上で受信されたかどうかをモニタする（５２）。
【００５７】
ＭＥ４４内の第１のＵＤＰクライアント４０のアプリケーションが、ＵＤＰモードにあるＵＩＣＣサーバ４６と通信する（５３）ことを望むと仮定し、このアプリケーションはＵＤＰソケットをまず生成し（５４）、次いでこのソケットを、クライアント送信元ポート番号において参照することができる該送信元ポート番号に結びつける（５４）。前に述べたように、このポート番号は事前に固定されてよく、またはこのポート番号がＭＥ４４によって動的に割り当てられている場合には、例えば「ｇｅｔｓｏｃｋｎａｍｅ」プリミティブを呼び出して取得されてもよい。
【００５８】
その後、ＭＥ４４はこのクライアント送信元ポート番号を記憶し、このポート番号にＵＤＰクライアント識別子（例えば、ＭＥによって割り当てられる単純な数）を関連付ける（５６）。
【００５９】
このステップは、「クライアントポート番号−ＵＤＰクライアント識別子」対データを記憶する、ＭＥ内の単純なアレイを使用して行うことができる。
【００６０】
わかるように、同様の信号伝達５８、６０、および識別子の割り当て６２が次に第２のＵＤＰクライアントアプリケーション４２のために行われる。第１のＵＤＰクライアントアプリケーション４０が、データをＵＩＣＣ  ＵＤＰサーバ４６に送信する（６４）ためにＵＤＰデータ送信関数を呼び出すとき、ＵＤＰクライアントは、ＵＩＣＣ  ＵＤＰサーバのポート番号を事前に知っており、このポートはＩＡＮＡによって割り当てられる標準のポート番号であってもよいことに留意されたい。
【００６１】
ＭＥ４４は、この要求を、ＵＤＰクライアント４０によって送信関数６４内で示されたサーバポート番号のおかげで、ＵＩＣＣ  ＵＤＰサーバ４６への要求として認識し、ＭＥ４４は次に、この関数からペイロードを抽出し、自身のメモリ内に保存する。
【００６２】
ＭＥ４４は次に、「イベントダウンロード−データ入手可能（Ｅｖｅｎｔ  Ｄｏｗｎｌｏａｄ  Ｄａｔａ  Ａｖａｉｌａｂｌｅ）」エンベロープコマンド６６を、このエンベロープコマンド６６に含まれる、例えば装置アイデンティデータオブジェクト内の割り当てられたＵＤＰクライアント識別子を示すことによって、ＵＩＣＣ  ＵＤＰサーバ４６に送信する。
【００６３】
ＵＩＣＣ４６は、エンベロープ６６を受信することによって、ＵＤＰクライアント識別子に基づいて、自らが、ＵＩＣＣ  ＵＤＰサーバと通信しようと試みるものと特定するＵＤＰクライアントがあることを認識する。
【００６４】
ＵＩＣＣ４６は次に、ＵＤＰクライアント４０からデータを取得するために、データ受信コマンド６８をＭＥ４４に送信する。特に、このデータ受信コマンド６８はＵＤＰクライアント識別子も含むことができる。
【００６５】
このデータ受信コマンド６８を受信することによって、ＭＥ４４は、ＵＤＰクライアント識別子によって参照されるＵＤＰクライアントアプリケーションデータ（前に保存されたペイロード）を、「チャネルデータ」データオブジェクト内に封入し、ＵＤＰクライアント識別子を（例えば装置アイティティデータオブジェクト内に）含め、端末応答７０をＵＩＣＣ４６に送信することができる。
【００６６】
サーバの「データ受信−端末応答」のやり取り／サイクルは、ＵＤＰクライアントのデータを単一の端末応答を使用して送信できない、すなわちデータ量が単一の端末応答のデータ搬送能力を超える場合に使用できることを理解すべきである。
【００６７】
この端末応答７０を受信することによって、ＵＩＣＣ４６は、ＵＤＰクライアント識別子によってどのＵＤＰクライアントからのデータか（この場合は４０）を知ることができる。
【００６８】
ＭＥ４４は次に、そのＵＤＰクライアントに確認応答メッセージ７２を送信することによって、データが正確に送信されたことを確認することができる。
【００６９】
同様の信号のやり取り７４、７６、７８、８０、８２は、第２のクライアントアプリケーション４２のＵＤＰが、データ７４をＵＩＣＣ  ＵＤＰサーバ４６に送信する（７４）ＵＤＰ送信データ関数を呼び出すときに生じる。
【００７０】
次に、ＵＩＣＣサーバ４６はデータ８４、８６を特定のＵＤＰクライアント４０、４２に送信することができ、ＵＩＣＣは、本発明に基づき、データ送信プロアクティブコマンド８４内でＵＤＰクライアント識別子を単に指定する必要がある。
【００７１】
ＭＥ４４がこのデータ送信コマンド８４をＵＩＣＣ４６から受信すると、ＭＥ４４はこのデータ８６を正しいクライアントアプリケーション４０に送信することができる。
【００７２】
次に、図４を参照すると、第１のクライアント４０、第２のクライアント４２、ＭＥメインプロセッサ４４、およびＵＩＣＣ４６間に生じる信号伝達、ただし今度はＢＩＰチャネル上でＴＣＰをサポートすることによる信号伝達が示されている。すなわち、クライアント４０、４２のそれぞれは複数のＴＣＰクライアントを含み、ＵＩＣＣ４６はＴＣＰサーバモードで動作するとみなされる。
【００７３】
以下の説明から理解されるように、この信号伝達の後のやり取りは、図３の実施形態に関して図示したやり取りを単に反映するので、信号伝達の最初の段階しか図４には示されていない。
【００７４】
再び、電源投入シーケンスを開始して、ＭＥ４４は、ＴＣＰおよびサーバモードにあるＵＩＣＣをサポートすることを示す端末プロファイル信号８８をＵＩＣＣ４６に送信し、そして前と同じように、電源投入シーケンスを完了した後に、ＵＩＣＣ４６は、オープンチャネルプロアクティブコマンド９０をＭＥ４０に送信する。
【００７５】
この段階において、および９２において示されるように、ＭＥは次にＴＣＰソケットを生成し、このソケットを所要のサーバポートに結びつける。関連する「ｌｉｓｔｅｎ」関数およびその後の「ａｃｃｅｐｔ」関数も、ＭＥがそのサーバポート上の入力接続要求をモニタし始めることができるように、開始することができる。
【００７６】
第１のクライアント４０からの通信のその後のサポートのために、所要のＴＣＰソケットを生成し、その後そのソケットを適切なクライアントポート番号に結びつけるために、信号伝達９４、９６がクライアント４０からＭＥ４４に送られる。
【００７７】
ＭＥ４４内で、および９８において、ＭＥは上述した接続要求を受信し、元のサーバソケットを何らかの他の入力接続要求のために使用可能な状態にしておくために、新たなＴＣＰサーバソケットを実際に生成する。ＭＥは、新たなサーバポート番号を割り当てるように構成することができ、この時点からは、新たに割り当てられたポート番号が第１のクライアント４０に関連付けられ、このクライアントからのすべての他のデータはその特定のポートに送信される。
【００７８】
その後、ＭＥ４４は、信号伝達１００によって、受信確認および接続要求のイネーブルで応答することができる。
【００７９】
次に、そして第２のクライアント４２も、ＵＩＣＣ４６と通信することを同様に望むと仮定し、同様のソケット生成１０２および結び付け１０４の信号伝達がＭＥ４４においてこの第２のクライアントから受信される。したがって、１０６において、第１のクライアントに関して９８で行われたのと同じポート番号割当てプロセスが第２のクライアントに関して行われる。
【００８０】
受信と接続のイネーブル化の確認が、ＭＥ４４から第２のクライアント４２への信号伝達１０８として返される。その後のすべての信号伝達は、図３に示したＵＤＰのサポートについてと同じ内容で生じるため、これ以上は図示しない。確認として、ＭＥは第１のクライアント４０および第２のクライアント４２に２つの異なるポート番号を割り当てる。ＭＥは次に、これらのポート番号を２つの異なる識別子に関連付け、ＵＩＣＣが、２つの異なるクライアントからのデータを、たとえ該２つの異なるクライアントが同じＩＰアドレスを共有しても、区別できるように、この情報をＵＩＣＣによって使用されるように渡すことができる。
【００８１】
ＵＤＰをサポートする実施形態に戻ると、この実施形態は、ＴＣＰをサポートするために提案された信号伝達に基づくが、以下の提案によって示す様々な追加および修正を伴う信号伝達に基づくことができる。
【００８２】
例えば、「端末プロファイル」ＡＰＤＵコマンドは、「ＵＤＰサーバモードにあるＵＩＣＣ」のサポートを追加するように修正することができる。
【００８３】
ＡＰＤＵコマンドに対するそのような提案された修正の性質を、「ｂ６」において、サーバモードにあるＵＤＰ  ＵＩＣＣに対するサポートの追加を示す１７番目のバイトに関して図５に示されている。
【００８４】
また、「ＵＩＣＣサーバモードに関連するオープンチャネル」プロアクティブコマンドは、ＵＤＰサーバモードにあるＵＩＣＣのサポートを追加するために修正することができる。
【００８５】
より具体的には、このオープンチャネルコマンドに含まれる「ＵＩＣＣ／端末インターフェイストランスポートレベル」データオブジェクトを、ＵＤＰサーバモードにあるＵＩＣＣのサポートを追加するために修正することができる。
【００８６】
ＵＩＣＣ／端末インターフェイストランスポートレベルでは、クラス「ｅ」がサポートされている場合、この規定が当てはまる。
【００８７】
【表１】
0005447522.tif 000002
【００８８】
・トランスポートプロトコルの種類のコード化：
−「０１」：クライアントモード、リモート接続にあるＵＤＰ、ＵＩＣＣ
−「０２」：クライアントモード、リモート接続にあるＴＣＰ、ＵＩＣＣ
−「０３」：サーバモードにあるＴＣＰ、ＵＩＣＣ
−「０４」：クライアントモード、ローカル接続にあるＵＤＰ、ＵＩＣＣ
−「０５」：クライアントモード、ローカル接続にあるＴＣＰ、ＵＩＣＣ
−「０６」：サーバモードにあるＵＤＰ、ＵＩＣＣ
−他のすべての値は未使用である。
【００８９】
−ＵＤＰはRFC768[9]に定められ、ＴＣＰはRFC793[10]に定められている。
【００９０】
・ポート番号のコード化：
−整数。
【００９１】
値「０６」は本明細書のある特定のバージョンに基づくので、この値は一例として示されていると理解すべきだが、当然ながらこの値は必要ならば変更されてもよい。
【００９２】
「装置アイデンティティ」データオブジェクトに関し、このデータオブジェクトは、いくつかのＵＤＰクライアントが区別されることを可能にする識別子を追加するために修正することができる。また、値の新たな範囲を定めることができる。例えば、および本発明の一実施形態では、９個の考えられる値（３１から３９）を定めることができる。勿論、この９個の値に限定されるものではなく、さらに拡張することが、４１から４９などの他の値を使用して可能であることを理解すべきである。
【００９３】
次に、装置アイデンティティを参照すると、装置アイデンティティは以下の通りに定めることができる。
【００９４】
【表２】
0005447522.tif 000003
【００９５】
送信元装置アイデンティティ：
・内容：
−次に続くデータオブジェクト内に保持された情報の送信元装置
宛先装置アイデンティティ：
・内容：
−次に続くデータオブジェクト内に保持された情報の宛先装置
例の通り、コマンドの種類、データダウンロードの種類、および装置アイデンティティの一部の組合せしか許されないことに留意すべきである。これらの組合せは１０節に定義されている。
【００９６】
・コード化：
−送信元装置アイデンティティおよび宛先装置アイデンティティはいずれも以下の通りにコード化される：
・「０１」＝キーパッド
・「０２」＝ディスプレイ
・「０３」＝受話口
・「１０」から「１７」＝追加のカードリーダｘ（０から７）。値は端末によって割り当てられる。
【００９７】
・「２１」から「２７」＝チャネル識別子ｘ（１から７）を有するチャネル。値は、オープンチャネルコマンドの後に続く、端末応答のチャネル状況把握（Ｃｈａｎｎｅｌ  ｓｔａｔｕｓ  Ｃｏｍｐｒｅｈｅｎｓｉｏｎ）ＴＬＶ内で端末によって割り当てられる。
【００９８】
・「３１」から「３９」＝ＵＤＰサーバモードにあるＵＩＣＣがサポートされている場合の、ＵＤＰクライアントアプリケーション識別子（１から９）。
【００９９】
・「８１」＝ＵＩＣＣ
・「８２」＝端末
・「８３」＝ネットワーク
・他のすべての値は未使用。
【０１００】
この場合もやはり、この装置アイデンティティデータオブジェクトは以下のコマンドに含まれてもよいことに留意されたい：
−ＭＥからＵＩＣＣへ
＊エンベロープ「イベントダウンロード−データ入手可能」
＊端末応答
−ＵＩＣＣからＭＥへ
＊データ受信
＊データ送信
理解されるように、ＭＥは、ＵＤＰクライアントアプリケーション送信元ポート（以下参照）を、上記のＵＤＰクライアントアプリケーション識別子に関連付けなければならない。
【０１０１】
ＭＥ４４内のＵＤＰクライアントアプリケーション４０、４２と、ＵＩＣＣ４６内のＵＤＰサーバとの間の何らかの通信の前に、クライアントアプリケーション４０、４２は、サーバ４６から任意のデータ（返答）を取得できるためにまずポート番号に関連付けられ、前に述べたように、その手続きは次のものとすることができる。
【０１０２】
−クライアントが、ＵＤＰデータグラムソケットをまず生成し、ソケットの生成は任意の標準のソケットライブラリ
ｈＳｏｃｋｅｔ＝ｓｏｃｋｅｔ（ＡＦ＿ＩＮＥＴ，ＳＯＣＫ＿ＤＧＲＡＭ，ＩＰＰＲＯＴＯ＿ＵＤＰ）
を使用して行うことができる。
【０１０３】
−本発明のこの例にしたがって、クライアントは次にこのソケットを特定のポート番号（この番号は、クライアント送信元ポート番号になる）に結び付け、このポート番号は事前に固定されてよく、または例えば次のようにＭＥによって動的に割り当てられてもよい。
【０１０４】
ｂｉｎｄ（ｈＳｏｃｋｅｔ，（ｓｔｒｕｃｔ  ｓｏｃｋａｄｄｒ＊）＆  ａｄｄｒｅｓｓ，ｓｉｚｅ  ｏｆ（ａｄｄｒｅｓｓ））
クライアントのＩＰアドレスおよびポート番号は「ｓｏｃｋａｄｄｒ」構造に含まれ、この点から、ＭＥは、ＵＤＰクライアント識別子をこのクライアントポート番号に関連付けなければならないことに留意すべきである。これは、ＭＥのメモリ内に以下の形式で記憶されてもよい簡単な配列によって行うことができる。
【０１０５】
【表３】
0005447522.tif 000004
【０１０６】
いくつかのＵＤＰクライアントを区別するためにＵＤＰクライアント識別子がＭＥ−ＵＩＣＣインターフェイス上でその後使用される。
【０１０７】
ポート２２２２を使用するＭＥ４４内のＵＤＰクライアントアプリケーション４０、４２が、ＵＩＣＣ４６内のサーバにデータを送信するとき、例えば上記の値を使用して、ＭＥ４４は、そのデータとともに識別子「３１」をＵＩＣＣ４６に渡す。
【０１０８】
ＵＩＣＣ４６が応答を送信するとき、ＵＩＣＣ４６は自らの返答の中に「３１」を示し、次いでＭＥ４４は、このデータをＵＤＰポート２２２２に送信する。
【０１０９】
クライアントアプリケーションのＵＤＰソケットをいくつかのローカルＵＤＰポートに結びつけることによって、ＭＥは、これらのＵＤＰクライアントアプリケーションのそれぞれを簡単に、かつ明瞭に識別することができる。いくつかのＵＤＰクライアントをＵＩＣＣ  ＵＤＰサーバのためにＭＥからサポートすることは、ＵＩＣＣがいくつかのＵＤＰクライアントを区別できるようにするために単一の識別子しか必要ではないので、簡単な方法で行うことができる。
【０１１０】
新たなＵＤＰクライアント識別子は、すでに存在するデータオブジェクト内に通すことができ、かつどんな後方互換性の問題も引き起こさないので、本発明のそのような代表的実施形態は、既存のインターフェイスをほぼ変えないでおく代表的な利点も有する。
【０１１１】
本発明を、その代表的実施形態を参照して詳細に図示し、説明してきたが、本発明はこれらの例示的実施形態に限定されない。特許請求の範囲によって定められる本発明の趣旨および範囲から逸脱することなく、それらの実施形態の中で形式および詳細の様々な変更がなされてもよいことを当業者によって理解されるであろう。
【０１１２】
本願は、２００８年１１月２０日に出願され、参照によってその開示全体が本明細書に組み込まれる、英国特許出願第0821236.7号に基づき、その優先権の利益を主張するものである。
【図１】
0005447522.tif 000005
【図２】
0005447522.tif 000006
【図３】
0005447522.tif 000007
【図４】
0005447522.tif 000008
【図５】
0005447522.tif 000009