(57)【要約】  本発明は、無線装置に挿入されるのに適したセキュアデバイスがアクセスしようとするターゲットサーバのＩＰアドレスをセキュアデバイスが解決する方法に関し、セキュアデバイスはターゲットサーバのＩＰアドレスを解決する要求を前記無線装置上に存在するＤＮＳクライアントに送信し、前記ターゲットサーバは、前記ターゲットサーバのＦＱＤＮにより識別される。
2013504235.tif 000002
【特許請求の範囲】
【請求項１】
無線装置に挿入されるのに適したセキュアデバイスがアクセスしようとするターゲットサーバのＩＰアドレスをセキュアデバイスが解決する方法であって、セキュアデバイスがターゲットサーバのＩＰアドレスを解決する要求を前記無線装置上に存在するＤＮＳクライアントに送信し、前記ターゲットサーバが前記ターゲットサーバのＦＱＤＮにより識別される、方法。
【請求項２】
要求がプロアクティブコマンドを含む、請求項１に記載の方法。
【請求項３】
ＤＮＳクライアントがそれ自体でＩＰアドレスを解決する、請求項１から２に記載の方法。
【請求項４】
ＤＮＳクライアントがターゲットサーバのＩＰアドレスを解決するためにＤＮＳサーバに接続し、次に、ＤＮＳサーバが、解決されたＩＰアドレスを無線装置上に存在するＤＮＳクライアントに戻す、請求項１から２に記載の方法。
【請求項５】
ＤＮＳクライアントが、ターゲットサーバの解決されたＩＰアドレスをセキュアデバイスに戻す、請求項３または４に記載の方法。
【請求項６】
セキュアデバイスが、解決されたアドレスを使用してターゲットサーバとのＢｅａｒ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｐｒｏｔｏｃｏｌ（Ｂｅａｒ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｐｒｏｔｏｃｏｌ）セッションを開始する、請求項５に記載の方法。
【請求項７】
ＤＮＳクライアントがターゲットサーバとのＢＩＰチャネルを開く、請求項３または４に記載の方法。
【請求項８】
スマートカードをセキュアデバイスとして使用することを含む、請求項１から７のいずれか一項に記載の方法。
【請求項９】
請求項１から８のいずれか一項に記載の方法を使用することによりアクセスしようとするターゲットサーバのＩＰアドレスを解決するセキュアデバイスを含み、かつＤＮＳクライアントを内部に有する移動機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線通信の分野に関する。
【０００２】
本発明は、セキュアデバイス（ｓｅｃｕｒｅ  ｄｅｖｉｃｅ）がアクセスしようとするターゲットサーバのＩＰアドレスをセキュアデバイスが解決する方法を特に扱う。
【背景技術】
【０００３】
セキュアデバイス、たとえばスマートカードとも呼ばれるＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ  Ｃａｒｄ）がインターネット内のどこかに位置するサーバとのＩＰ接続を開始するために、セキュアデバイスはターゲットサーバのＩＰアドレスをまず知る必要がある。
【０００４】
ＩＰアドレスは動的に割り当てられ、時間がたつにつれ変わっていることがあり得る。したがって、セキュアデバイスは、知られている情報たとえばサーバのＦＱＤＮ（ｆｕｌｌｙ  ｑｕａｌｉｆｉｅｄ  ｄｏｍａｉｎ  ｎａｍｅ）に基づきＩＰアドレスを解決する必要がある。ＤＮＳクライアントが、必要があればＤＮＳサーバからのサポートを得て、ＩＰアドレスを解決することができる。
【０００５】
このとき、セキュアデバイスがＤＮＳクライアントを内部でサポートしていない場合、セキュアデバイスは、無線装置たとえば移動機器（ＭＥ）上に存在するＤＮＳクライアントにＩＰアドレスを解決するように要求する必要がある。
【０００６】
主要な問題は、ＤＮＳリゾルバが無線装置上に存在し、かつセキュアデバイスがＤＮＳリゾルバにＯＴＡ（Ｏｖｅｒ−Ｔｈｅ−Ａｉｒ）サーバのＩＰアドレスを解決するように要求する標準的方法がないことである。セキュアデバイスが無線装置内部のＤＮＳクライアントにターゲットサーバのＩＰアドレスを解決するように要求する標準的方法がない。
【０００７】
たとえば、現在のＥＴＳＩまたは３ＧＰＰの規格は、ＵＩＣＣがアクセスしようとするサーバのＩＰアドレスを解決するように、ＵＩＣＣが移動機器（ＭＥ）上に存在するＤＮＳクライアントに要求する手段を提供しない。そして、現在の規格は、サーバのＩＰアドレスが前もってＵＩＣＣにより知られていると仮定する。このことは、ＵＩＣＣがターゲットサーバのＩＰアドレスを解決することができないので、特にサーバのＩＰアドレスが動的に変わっているとき、ＵＩＣＣがインターネット内のどこかに位置するサーバとのＩＰセッションを開始するのを妨げる。
【０００８】
ＭＥまたはＵＩＣＣとすることができる装置上でＯＴＡサーバのＩＰアドレスが解決されるためには、１つの知られている解決策が、ＵＩＣＣ内にＤＮＳリゾルバ機能を置くことである。ＵＩＣＣがＩＰアドレスを解決する必要がある場合、ＵＩＣＣはＤＮＳサーバと通信する必要がある。そうするためには、ＵＩＣＣは、ネットワークへ取り付けたときにネットワークからＭＥが受信するＤＮＳサーバのＩＰアドレスを知る必要がある。それにもかかわらず、ＵＩＣＣはこのＤＮＳサーバのＩＰアドレスを得ることができない。
【０００９】
この場合、１つの方法が、デバイス管理（Ｄｅｖｉｃｅ  Ｍａｎａｇｅｍｅｎｔ）プロトコルに頼ることにある。ＯＭＡ（Ｏｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ）のデバイス管理プロトコルでは、ＵＩＣＣはＭＥ構成を診断することができるＤＭサーバを含む。このことは、ＤＭサーバがＭＥ内に記憶されるＤＮＳ  ＩＰアドレスを得ることができるようにする。ＵＩＣＣ内部にＤＭサーバ機能を有することにより、ＵＩＣＣはたとえばＢＩＰ（Ｂｅａｒ  Ｉｎｄｅｐｅｎｄｅｎｔ  ｐｒｏｔｏｃｏｌ）ＵＩＣＣサーバモードを使用してＭＥからＤＮＳ  ＩＰアドレスを得ることができる。ＤＮＳ  ＩＰアドレスが得られると、ＵＩＣＣはＢＩＰ  ＵＩＣＣクライアントモードでその他のステップを行う。ＢＩＰ  ＵＩＣＣサーバモードおよびＢＩＰ  ＵＩＣＣクライアントモードはよく知られている。ＢＩＰ  ＵＩＣＣサーバモードはスマートカードＷｅｂサーバに対応する。たいていは、ＢＩＰにはＵＩＣＣサーバまたはＵＩＣＣクライアントという２つのモードがある。ここで、ＵＩＣＣ内でＤＭサーバが使用されるとき、このステップだけにＢＩＰサーバモードを必要とする。それにもかかわらず、この方法の１つの主要な欠点が、ＢＩＰ  ＵＩＣＣサーバモードを必要とし、かつ現在では市場に十分に展開されていないＤＭサーバの可用性である。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ＵＩＣＣがアクセスしようとするターゲットサーバのＩＰアドレスをスマートカードが解決する方法を提供する必要が依存としてある。
【課題を解決するための手段】
【００１１】
無線装置内に挿入されるのに適したセキュアデバイスがアクセスしようとするターゲットサーバのＩＰアドレスをセキュアデバイスが解決する方法を提供することが本発明の１つの目的であり、セキュアデバイスは、ターゲットサーバのＩＰアドレスを解決する要求を前記無線装置上に存在するＤＮＳクライアントに送信し、前記ターゲットサーバのＦＱＤＮにより識別される。
【００１２】
本発明の別の様態によれば、
要求はプロアクティブコマンドを含むことができる、
ＤＮＳクライアントはそれ自体でＩＰアドレスを解決することができる、
ＤＮＳクライアントは、ターゲットサーバのＩＰアドレスを解決するためにＤＮＳサーバに接続することができ、次に、ＤＮＳサーバは、解決されたＩＰアドレスを無線装置上に存在するＤＮＳクライアントに戻す、
ＤＮＳクライアントは、ターゲットサーバの解決されたＩＰアドレスをセキュアデバイスに戻すことができる、
セキュアデバイスは、解決されたアドレスを使用してターゲットサーバとのＢｅａｒ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｐｒｏｔｏｃｏｌセッションを開始することができる、
ＤＮＳクライアントは、ターゲットサーバとのＢＩＰチャネルを開くことができる、
方法はスマートカードをセキュアデバイスとして使用することを含むことができる。
【００１３】
有利なことに、セキュアデバイスはサーバとのＩＰセッションを開始することができ、サーバのＩＰアドレスが動的に割り当てられ、無線装置上のＤＮＳクライアントにより（必要な場合にはＤＮＳサーバからのサポートを得て）解決されることができる。
【００１４】
この方法のおかげで、セキュアデバイスは、ＥＴＳＩ  ＴＳ  １０２  ２２３で規定されるＢｅａｒ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｐｒｏｔｏｃｏｌを使用してサーバとのＩＰセッションを要求することができる。
【００１５】
方法を使用することによりアクセスしようとするターゲットサーバのＩＰアドレスを解決する前記セキュアデバイスを含み、かつＤＮＳクライアントを内部に有する移動機器を提供することが、本発明の別の目的である。
【００１６】
ここで、本発明が、添付図面を参照して例によって説明される。
【００１７】
上記で列挙された方法、ならびに本発明の別の利点および特徴が得られるために、上記で簡潔に説明された本発明のより詳細な説明が参照により行われる。
【００１８】
任意の別の形態が本発明の範囲に入り得るにもかかわらず、ここで、本発明の好ましい形態が添付図面を参照して例示としてのみ説明される。
【図面の簡単な説明】
【００１９】
【図１】解決されたＩＰアドレスがセキュアデバイスに戻される、本発明による方法の図を概略的に示す。
【図２】解決されたＩＰアドレスがセキュアデバイスに戻されない、別の実施形態による方法の図を概略的に示す。
【発明を実施するための形態】
【００２０】
本発明は、本明細書で提供される詳細な説明により理解されることができる。
【００２１】
図１に示されているのは、本発明の一実施形態による方法である。方法は、ＵＩＣＣ１が接続しようとするターゲットサーバ３の解決されたＩＰアドレスを得るために、セキュアデバイスたとえばＵＩＣＣ１が無線装置たとえばＭＥ２上に存在するＤＮＳクライアント２１との対話をもつことができるようにする異なるステップを含む。以下の説明では、ターゲットサーバ３はサーバＡと呼ばれる。
【００２２】
そうするために、ＵＩＣＣはＭＥ２上に存在するＤＮＳクライアント２１にＩＰアドレスを解決するように要求する。要求は、たとえば、ＥＴＳＩ  ＴＳ  １０２  ２２３ですでに規定されている既存のプロアクティブコマンドの拡張、または新しいプロアクティブコマンドとすることができるプロアクティブコマンドの形とすることができる。このプロアクティブコマンドに応答して、ＭＥ内のＤＮＳクライアント２１がターゲットサーバ３の解決されたＩＰアドレスを戻す。
【００２３】
より詳細には、方法は、ＵＩＣＣ１が、ＭＥ２内上に存在するＤＮＳクライアント２１に、サーバのＦＱＤＮにより識別されるサーバのＩＰアドレスを解決するように要求するステップ１１を含む。要求が、たとえば既存のＰＲＯＶＩＤＥ  ＬＯＣＡＬ  ＩＮＦＯＲＭＡＴＩＯＮコマンドまたは既存のＯＰＥＮ  ＣＨＡＮＮＥＬコマンドとすることができる既存のプロアクティブコマンドでもよい。プロアクティブコマンドでは、パラメータの一部を設定することが可能である。現在の規格は、ＦＱＤＮをパラメータの１つとして設定することを許可しない。拡張は、これらのプロアクティブコマンドが、ターゲットサーバのＦＱＤＮをこれらのプロアクティブコマンドのパラメータの１つとして有することができるようにすることである。
【００２４】
ＭＥ２上に存在するＤＮＳクライアント２１は、まずそれ自体で、すなわちたとえばキャッシュ内にローカルに記憶される自分自身のデータベース上で検索することによりＩＰアドレスを解決しようとする。
【００２５】
ＭＥ２内のＤＮＳクライアントがどうにかしてＩＰアドレスをローカルに見つけるまたは解決する場合、知られているＤＮＳサーバ４に接続する必要がない。そうでない場合、別のステップ１２で、ＤＮＳクライアント２１はＤＮＳサーバ４に接続し、ＤＮＳサーバ４はターゲットサーバ３の解決されたＩＰアドレスを戻す。
【００２６】
次のステップ１３では、ＭＥ２上に存在するＤＮＳクライアント２１は、サーバＡ３の解決されたＩＰアドレスをＵＩＣＣ１に戻す。この手順に従うことにより、ＵＩＣＣ１はターゲットサーバ３のＩＰアドレスを得て、次に、ステップ２０で、この解決されたＩＰアドレスを使用して、たとえばＥＴＳＩ  ＴＳ  １０２  ２２３に従ってターゲットサーバとのＢｅａｒ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｐｒｏｔｏｃｏｌセッションを開始することができる。このステップ２０では、プロアクティブコマンドは、サーバＡのＩＰアドレスがこのプロアクティブコマンドのパラメータの１つとして設定されたＯＰＥＮ  ＣＨＡＮＮＥＬである。
【００２７】
この実施形態では、このとき、ＵＩＣＣは、解決されたＩＰアドレスをまず得て、サーバＡとのＩＰセッションを確立することである２つの主要なステップに関係している。解決されたＩＰアドレスはＵＩＣＣ１に戻される。
【００２８】
特に、このプロアクティブコマンドに応答してＤＮＳサーバが返し受信されるいくつかのアドレスからＩＰアドレスの選択を行う可能性をＵＩＣＣ１に提供することが望まれるときに、この任意選択は効果的である。それは、たとえば、ＤＮＳサーバが２つのＩＰドレス（主アドレスおよび副アドレス）を１つのＩＰアドレス解決要求に対して返す場合に言える。２つのＩＰアドレスがＵＩＣＣ１に戻される場合、ＵＩＣＣ１は、接続をセットアップするときに、２つのＩＰアドレスのうちの一方を自由に使用することができる。このことは、事業者がＵＩＣＣ１に主サーバと副サーバの間の負荷バランスを管理させる場合に有用となり得る。
【００２９】
図２に示されているのは、ＵＩＣＣがターゲットサーバのＦＱＤＮを提供するときの方法の別の実施形態である。
【００３０】
この実施形態では、方法は、ＭＥ２にＩＰセッションを開くように要求する手段を提供する。ＵＩＣＣ１がターゲットサーバに対するＦＱＤＮを提供するときに、ＭＥ２にＩＰセッションを開くように要求する方法は、Ｂｅａｒ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｐｒｏｔｏｃｏｌを開始する既存のＯＰＥＮ  ＣＨＡＮＮＥＬコマンドの拡張の形とすることができる。
【００３１】
より詳細には、方法は、ＵＩＣＣ１が、ＭＥ２内に存在するＤＮＳクライアント２１にサーバのＦＱＤＮにより識別されるサーバのＩＰアドレスを解決するように要求するステップ１１０を含む。ちょうど上述されたように、既存のプロアクティブコマンドが、たとえば、プロアクティブコマンドのパラメータの１つとしてＦＱＤＮが設定された既存のＯＰＥＮ  ＣＨＡＮＮＥＬコマンドとすることができる。有利なことに、既存のＯＰＥＮ  ＣＨＡＮＮＥＬコマンドは、ＢＩＰチャネルを開いてＩＰセッションを確立することを可能にする。
【００３２】
ＭＥ２上に存在するＤＮＳクライアント２１は、それ自体で、すなわちローカルに記憶される自分自身のデータベース上で検索することによりＩＰアドレスをまず解決しようとする。ＭＥ２内のＤＮＳクライアントがどうにかしてローカルにＩＰアドレスを見つけるまたは解決する場合、ＤＮＳサーバに接続する必要がない。そうでない場合、別のステップ１２０で、ＤＮＳクライアント２１は知られているＤＮＳサーバ４に接続し、ＤＮＳサーバ４はターゲットサーバ３の解決されたＩＰアドレスを返す。
【００３３】
次のステップ１３０では、ＭＥ２上に存在するＤＮＳクライアント２１は、サーバＡ３の解決されたＩＰアドレスをＵＩＣＣ１に返さない。ＤＮＳクライアント２１は、解決されたＩＰアドレスを設定してターゲットサーバとのＢＩＰチャネルを開く。
【００３４】
ＯＰＥＮ  ＣＨＡＮＮＥＬ内にＦＱＤＮを設定する可能性を提供することにより、ＭＥ２はＩＰアドレスを解決し、ターゲットサーバ３とのＩＰセッションを開く。この場合、このＩＰセッションが確立されると、ＵＩＣＣ１はＭＥ２から通知だけを受信する。
【００３５】
この実施形態では、ＵＩＣＣ１はＦＱＤＮだけを提供し、サーバＡ３とのＩＰ接続を確立する１つの主要なステップだけに関係している。ＤＮＳサーバ２１から戻されるＩＰアドレスはＵＩＣＣ１に戻されない。
【００３６】
有利なことに、図２に示される実施形態は、ＵＩＣＣ１が行う必要がある唯一のことがターゲットサーバのＦＱＤＮを提供することであるので、ＵＩＣＣ１のための最も簡単な解決策を提供する。このとき、その他のステップはＭＥ２内のＤＮＳクライアント２１により処理され、ＵＩＣＣ２は、どんなさらなる動作もなしに確立されたサーバ３への接続を得る。
【００３７】
これらの２つの実施形態は、両方ともＭＥ２内のＤＮＳクライアント２１を頼りにする。
【００３８】
図１に示されるような実施形態による方法は、事業者が、ＵＩＣＣ１が主ＩＰアドレスと副ＩＰアドレスの間で何らかの選択または操作をすることを望むときに利点を有する。
【００３９】
図２に示されるような実施形態による方法は、事業者が、ＭＥ２内のＤＮＳクライアント２１に完全に頼る最も簡単な解決策を有することを望むときに利点を有する。
【００４０】
本発明のおかげで、ＵＩＣＣ１は、ＩＰドレスが動的に割り付けられ、かつＭＥ２上に存在するＤＮＳクライアント２１により（必要があればＤＮＳサーバからのサポートを得て）解決されることができるサーバとのＩＰセッションを開始することができる。
【図１】
2013504235.tif 000003
【図２】
2013504235.tif 000004
【国際調査報告】
2013504235.tif 000005
2013504235.tif 000006
2013504235.tif 000007