(57)【特許請求の範囲】
【請求項１】
通信ネットワーク内で複数の端末とＯＴＡサーバ（１２）との間でＯＴＡセッションを確立する方法であって、
前記端末の各々は、保全素子（１０）と協同して前記ＯＴＡサーバ（１２）に問いかけ、リバース・プロキシ・サーバ（１１）を介して前記ＯＴＡサーバ（１２）から前記保全素子（１０）を更新するためにデータをダウンロードするために、安全なセッションを確立し、
前記方法は、
−前記ＯＴＡサーバ（１２）が前記リバース・プロキシ・サーバ（１１）に、更新が利用可能な前記保全素子（１０）の識別子のリストを提供し、
−前記保全素子（１０）と前記ＯＴＡサーバ（１２）との間で、前記リストに含まれる識別子を有する前記保全素子（１０）に限り、安全なセッションを確立することを特徴とする方法。
【請求項２】
前記保全素子（１０）が更新されると、前記リストから保全素子（１０）の前記識別子を除去することを特徴とする請求項１に記載の方法。
【請求項３】
前記識別子はＰＳＫ−ＩＤであることを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記安全なセッションはＴＬＳ-ＰＳＫセッションであることを特徴とする請求項１乃至３のいずれかに記載の方法。
【請求項５】
前記ＯＴＡサーバ（１２）はその料金レベルを前記リバース・プロキシ・サーバ（１１）に提供することを特徴とする請求項１乃至４のいずれかに記載の方法。
【請求項６】
通信ネットワーク内で、複数の端末と相互に作用する保全素子（１０）を更新するよう意図されたＯＴＡサーバ（１２）であって、
前記保全素子（１０）の各々は、リバース・プロキシ・サーバ（１１）を介して前記ＯＴＡサーバ（１２）からデータをダウンロードし、前記保全素子（１０）を更新するために、保全セッションを確立するよう前記ＯＴＡサーバ（１２）に問いかけることができ、
前記リバース・プロキシ・サーバ（１１）に更新が利用可能な前記保全素子（１０）の識別子のリストを提供することを特徴とするＯＴＡサーバ。
【請求項７】
前記ＯＴＡサーバ（１２）は、前記リバース・プロキシ・サーバ（１１）に、料金レベルを提供する手段を具備することを特徴とする請求項６に記載のＯＴＡサーバ。
【請求項８】
通信ネットワーク内のリバース・プロキシ・サーバ（１１）であって、
前記リバース・プロキシ・サーバ（１１）は、前記リバース・プロキシ・サーバ（１１）を介しての前記保全素子（１０）の要請に基づき、一方で、保全素子（１０）と協同する複数の端末と協同し、他方で、前記保全素子（１０）を更新することのできるＯＴＡサーバ（１２）と協同し、
前記リバース・プロキシ・サーバ（１１）は、
更新が利用可能な前記保全素子（１０）の識別子のリストを備え、前記リストは前記ＯＴＡサーバ（１２）によって更新されるものであり、
前記リバース・プロキシ・サーバ（１１）は、
前記ＯＴＡサーバ（１２）と前記リストに含まれている前記識別子を持った前記保全素子（１０）との間に安全なセッションの確立を許可する手段と、前記ＯＴＡサーバ（１２）と前記リストに含まれていない前記識別子を持った前記保全素子（１０）との間に安全なセッションの確立を禁止する手段と、を備え、前記リストは前記ＯＴＡサーバ（１２）によって更新されることを特徴とするリバース・プロキシ・サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信分野に係り、特に、電話機、スマートフォン、ＰＤＡ又はコンピュータなどの例えば携帯端末のような端末と相互作用するＵＩＣＣ（搬用集積回路カード）のような保全素子の遠隔管理の分野に関する。保全素子は例えばＭ２Ｍ（マシーントゥマシーン）の分野のように、機械に集積された回路の形で存在する。保全素子は必ずしも物理的に端末に接続されている必要はなく、近距離接続を通して端末と通信することができ、保全素子は分離され近距離チャネル（例えば、ブルートゥース（登録商標）又はＷｉＦｉ）を介して端末と通信する。
【背景技術】
【０００２】
このような保全素子管理は、保全素子を更新又はデータやプログラムをインストールするために、従来、ＯＴＡ（Over The Air）を介して提供されてきた。
この種の管理は、ｈｔｔｐプロトコルを使用し、‘ＲＦＭ’ （遠隔ファイル管理）又はｈｔｔｐ（ハイパーテキスト伝送プロトコル）を介した‘ＲＡＭ’（遠隔管理）とも呼ばれている。
【０００３】
保全素子は二つの方法で管理されうる。
−第１の方法は、ＯＴＡプラットフォームからデータ又はプログラムを例えば更新キャンペーン中に目標の保全素子に送信する方法である。
このタイプの管理は“プッシュ（push）”と呼ばれ、ＳＭＳモードでの送信に基づいている。
この方法の問題点は、ＳＭＳをサポートしていないＬＴＥネットワーク（これは完全にｈｔｔｐである）のような新世代ネットワークには適合しないことである。更に、ｈｔｔｐを介したＲＡＭ又はＲＦＭタイプ管理がＳＭＳのような信頼性のないプロトコルを回避するために開発されてきた。
【０００４】
−第２の方法は、更新が利用できるか否かを知るために、例えば、定期的に又はイベントの発生時にＯＴＡプラットフォームに問いかける方法である。
この問いかけは保全素子によって開始され、“polling（ポーリング）”又は“pull（プル）”と呼ばれている（保全素子はプラットフォームが送信すべきものを持っているか否かをチェックする。）。
この方法の問題点は、一般に、保全素子はＯＴＡプラットフォームに問いかけるためのイベントの発生を待たないことである。
“polling”は定期的、例えば毎２週間又は月毎に行われる。
ほどんどの時間、ＯＴＡプラットフォームは保全素子に対して送信するものを持っていない。例えば、出願人は、この分野で保全素子によるＯＴＡへの問いかけの９０％で、更新やプログラム又はデータが保全素子に送信されることはないということに気付いた。
【０００５】
これは、不必要なマイクロ波トラフィックとＯＴＡプラットフォームの過負荷とを招来している（保全素子の問いかけ毎にＴＬＳ−ＰＳＫリンクが保全素子とＯＴＡプラットフォームとの間に確立されるからである。）。
その上、データセンタの内部ネットワークが保全素子の更新に関与している時（例えば、携帯電話オペレータがそのサービスに信頼している、保全素子の製造者のデータセンタ）、そのネットワークも不必要に問いかけられる。加えて、ネットワークが物理的に分散されたサーバを使用していると、追加の通信を付加しなくてはならない。
【０００６】
第２の方法の運用における欠点を解決するために、２つの方法が可能である。
−ＯＴＡプラットフォームの２つの問いかけ“polling”間の時間を延長すること（保全素子のアプリケーションを更新して時間を延長する）。欠点は、更新が前回の問いかけの直後に利用可能となったとき、保全素子はずっと後になってやっと更新されることである。
−“push”モードに切替えること。前述の問題点が再現される。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
以上から、保全素子によるＯＴＡプラットフォームへの規則的な問いかけは決して満足できるものではなく、非常に否定的なインパクトを特にＯＴＡプラットフォームに与えるということに気付く。即ち、ＯＴＡプラットフォームは保全素子の更新に結びつかないｈｔｔｐ要請にアクセスするよう常に要請され、不必要なトラフィックを発生させるからである。
【課題を解決するための手段】
【０００８】
本発明は上記欠点を解決することを意図している。
特に本発明の１つの目的は、“polling”（問いかけ）をしている保全素子とサーバ又はＯＴＡプラットフォームとの間で、該プラットフォームが送信すべきデータを保有しているのか又はデータ又はプログラムの単なる更新なのかを知るための不必要なデータトラフィックの発生を防止することにある。ここで「データ」なる用語は広い意味で用いられており、プログラムや加入者情報（保全領域と対応キーとを持つ新たな加入者情報：ＩＭＳI／Ｋｉ）又はデータ又はプログラムの単なる更新を含む。この不必要なデータトラフィックは、主として“polling”を行っている保全素子とＯＴＡプラットフォームとの間でＴＬＳ-ＰＳＫセッションが確立されることに起因する。
前記目的及び後に明らかになる他の目的は、通信ネットワーク内で複数の端末とＯＴＡサーバとの間でＯＴＡセッションを確立するプロセスを通して実現される。
【０００９】
本発明では、端末各々は、保全素子と協同してＯＴＡサーバに問いかけ、リバース・プロキシ・サーバを介してＯＴＡサーバから保全素子を更新するためにデータをダウンロードするために安全なセッションを確立し、前記ＯＴＡサーバが前記リバース・プロキシ・サーバに、更新が利用可能な前記保全素子の識別子のリストを提供し、前記保全素子と前記ＯＴＡサーバとの間で、前記リストに含まれる識別子を有する前記保全素子に限り、安全なセッションを確立する。
【００１０】
保全素子（１０）が更新されると、リストから保全素子（１０）の識別子を除去する。また、識別子はＰＳＫ−ＩＤであり、安全なセッションはＴＬＳ-ＰＳＫセッションである。また、ＯＴＡサーバ（１２）はその料金レベルをリバース・プロキシ・サーバ（１１）に提供する。
【００１１】
本発明のＯＴＡサーバは、通信ネットワーク内で、複数の端末と相互に作用する保全素子（１０）を更新するよう意図されたＯＴＡサーバ（１２）であって、保全素子（１０）の各々は、リバース・プロキシ・サーバ（１１）を介してＯＴＡサーバ（１２）からデータをダウンロードし、保全素子（１０）を更新するために、保全セッションを確立するようＯＴＡサーバ（１２）に質問することができ、リバース・プロキシ・サーバ（１１）に更新が利用可能な保全素子（１０）の識別子のリストを提供する。
また、ＯＴＡサーバ（１２）は、リバース・プロキシ・サーバ（１１）に、料金レベルを提供する手段を具備する。
【００１２】
本発明のリバース・プロキシ・サーバは、通信ネットワーク内のリバース・プロキシ・サーバ（１１）であって、リバース・プロキシ・サーバ（１１）は、リバース・プロキシ・サーバ（１１）を介しての保全素子（１０）の要請に基づき、一方で、保全素子（１０）と協同する複数の端末と協同し、他方で、保全素子（１０）を更新することのできるＯＴＡサーバ（１２）と協同し、リバース・プロキシ・サーバ（１１）は、更新が利用可能な保全素子（１０）の識別子のリストを備え、リストはＯＴＡサーバ（１２）によって更新されるものであり、リバース・プロキシ・サーバ（１１）は、ＯＴＡサーバ（１２）とリストに含まれている識別子を持った保全素子（１０）との間に安全なセッションの確立を許可する手段と、ＯＴＡサーバ（１２）とリストに含まれていない識別子を持った保全素子（１０）との間に安全なセッションの確立を禁止する手段と、を備えている。
また、リストはＯＴＡサーバ（１２）によって更新される。
【図面の簡単な説明】
【００１３】
【図１】本発明の通信ネットワーク内で複数の端末ＯＴＡサーバとの間でＯＴＡセッションを確立する方法を説明する図。
【発明を実施するための形態】
【００１４】
本発明の他の特徴及び利点は以下の好ましい実施例についての詳細な説明を読むことにより明らかになるであろう。なお好ましい実施例は図１に図示されているが、これに限定されるものではない。
図１は、通信ネットワーク内で複数の端末とＯＴＡサーバとの間でＯＴＡセッションを確立する本発明の方法を説明する図である。
【００１５】
図１では、保全素子１０、リバース・プロキシ・サーバ１１、及びＯＴＡサーバ１２が図示されている。保全素子１０は、ここではＳＩＭ又はＵＩＣＣとして示されており、例えばスマートフォン（図示しない）のような端末と相互作用（協同）する。“pull”モードでは、保全素子１０は、典型的には時間ベース（例えば１５日）で、ＯＴＡサーバ１２が送信すべきデータを有しているかを知るためにＯＴＡサーバ１２（アプリケーションサーバ）に問いかけを行うことを決定する。
この問いかけに、従来はリバース・プロキシ・サーバ１１が関与していた。リバース・プロキシ・サーバ１１は保全素子１０とＯＴＡサーバ１２との間にＴＬＳ−ＰＳＫリンクを確立するのに使用される。
【００１６】
本発明は、このリバース・プロキシ・サーバ１１を保全素子１０とＯＴＡサーバ１２との間のフィルタとして使用することを提案している。
このフィルタの作用により、ＯＴＡサーバ１２が保全素子１０に送信すべきデータを持っていないときには、保全素子１０とＯＴＡサーバ１２との間の安全なセッションは確立されないという結果になる。
【００１７】
本発明の方法はより詳細には、以下のように動作する。
ステップ２０で、保全素子１０はＯＴＡサーバ１２に対して“polling”要請を開始する。この“polling”要請は、従来通りリバース・プロキシ・サーバ１１に届く。
本発明では、リバース・プロキシ・サーバ１１は、ステップ２１において前もってＯＴＡサーバ１２から、ＯＴＡサーバ１２に接続を許可される保全素子１０のリスト又は更新のリストを受け取っておく。
このリストは、通常、ＯＴＡサーバ１２において更新が利用可能な保全素子１０の識別子（好ましくは、ＰＳＫ−ＩＤ又はＩＣＣＩＤ）を含んでいる（データは広義で使用される。）。
【００１８】
リバース・プロキシ・サーバ１１はこれより更新が利用できる保全素子１０を知る。
ステップ２２において、リバース・プロキシ・サーバ１１は、受信した識別子から“polling”ステップ２０を開始した保全素子１０がＯＴＡサーバ１２での更新の資格があるか否かをチェックする。
受信した識別子が更新データが利用できる識別子に合致していると、リバース・プロキシ・サーバ１１は、ステップ２３において、保全素子１０はＯＴＡサーバ１２からデータを受け取ることが出来、保全素子１０とＯＴＡサーバ１２との間にリバース・プロキシ・サーバ１１を介して安全なセッション、好ましくはＴＬＳ−ＰＳＫセッションが確立されるという情報をＯＴＡサーバ１２に送信する。
【００１９】
そこで、ＯＴＡプラットフォーム１２から保全素子１０へ送信されるべきデータは安全なチャネル上で送信される。セッションが終了するとチャネルは閉じられる。
これに対し、リバース・プロキシ・サーバ１１が受信した識別子が、更新データが利用出来る保全素子１０の識別子と合致しないときには、リバース・プロキシ・サーバ１１は、ステップ２４で、保全素子１０にＯＴＡサーバ１２から保全素子１０に対して送信されるべきデータは存在せず、保全素子１０とＯＴＡサーバ１２との間には安全なセッションは確立されない旨の情報を送信する。
【００２０】
ステップ２５で、保全素子１０にデータの更新が行なわれると、リバース・プロキシ・サーバ１１はリストをリフレッシュし、更新されたばかりの保全素子１０の識別子を取り除く。この動作は上述したステップ２１（更新されるべき保全素子のリストのリフレッシュ）でも実行することができる。
【００２１】
リバース・プロキシ・サーバ１１において、ＰＳＫ−ＩＤをフィルタ基準として使用することには２つの利点がある。
−リバース・プロキシ・サーバ１１のフィルタリングは、ＴＬＳ−ＰＳＫセッションの確立に先立って実行される。
ＰＳＫ−ＩＤは、ＯＴＡサーバ１２中でサービスが実行される保全フィールドを含んでいるため、アクションが取られるべき対象（保全素子１０）をまさに代表するものである。選択ステップ２６では、リバース・プロキシ・サーバ１１に料金の状態を通知する。仮に料金が高すぎる場合、リバース・プロキシ・サーバ１１は、更新すべきデータの利用可能性について問いただし、ＯＴＡサーバ１２と保全素子１０との間の安全なリンクを組織的に禁止するか、保全素子から更新要請を取り扱うことの出来るサーバへの要請を再指示する。
【００２２】
本発明は、また、通信ネットワーク内で複数の端末と相互作用する保全素子１０を更新する様に意図されたＯＴＡサーバ１２に関する。保全素子１０は、それぞれ、保全素子１０を更新するために、リバース・プロキシ・サーバ１１を介してＯＴＡサーバ１２からデータをダウンロードする安全なセッションを確立するためにＯＴＡサーバ１２に問いかけすることが可能である。ＯＴＡサーバ１２は、更新が利用できる保全素子１０の識別子のリストをリバース・プロキシ・サーバ１１に提供する手段を備えている。ＯＴＡサーバ１２はリバース・プロキシ・サーバ１１に料金レベルを提供する手段も備えている。
【００２３】
本発明は、また、一方で保全素子１０と相互作用する複数の端末と相互作用し、他方で、リバース・プロキシ・サーバ１１を介しての要請に基づいて保全素子１０を更新することの出来るＯＴＡサーバ１２と相互作用（協同）するリバース・プロキシ・サーバ１１に関する。
【００２４】
リバース・プロキシ・サーバ１１は、更新が利用できる保全素子１０の識別子のリストを備えている。リストはＯＴＡサーバ１２により更新される（ステップ２１）。リバース・プロキシ・サーバ１１は、ＯＴＡサーバ１２と保全素子１０との間に安全なセッションの確立を許可する手段を備え、その識別子はリスト中に含まれている。またリバース・プロキシ・サーバ１１は、ＯＴＡサーバ１２と保全素子１０との間の安全なセッションの確立を禁止する手段を備え、その識別子はリスト中には含まれていない。
【産業上の利用可能性】
【００２５】
従って本発明では、更新する必要のない保全素子をリバース・プロキシ・サーバ１１においてＯＴＡサーバ１２のアップストリームをフィルタリングするように構成される。
これにより、ＯＴＡサーバ１２の動作が過負荷とならないようにし、不必要なトラフィックを発生させないようにしている。リバース・プロキシ・サーバ１１は、ＴＬＳ−ＰＳＫリンクの確立に先立って、アップストリームで、更新されるべきではない保全素子１０からの要請を拒否する。これにより、ＯＴＡサーバ１２とオペレータのネットワークに接続されるデータセンタのワークロードを９０％削減することが可能となる。
【００２６】
保全素子１０において新しいアプリケーションがインストール又は変更される毎に、アプリケーションサーバ又はＯＴＡサーバ１２は、リバース・プロキシ・サーバ１１において、関連する保全素子１０の識別子のリストを更新する。
優先度に基づくフィルタリングポリシ（例えば重要な更新）、アプリケーション（他のアプリケーションや更新に対しての優先度を有する）の有効期間又はリバース・プロキシ・サーバ１１にその識別子と共に提供されるリスト中で優先度を持ち更新されるアプリケーションの有効期間の満期も同様に提供される。
【符号の説明】
【００２７】
１０・・・保全素子
１１・・・リバース・プロキシ・サーバ
１２・・・ＯＴＡサーバ
【図１】
0006377837.tif 000002