JP5613350B2 - 通信ネットワーク上の端末に含まれる保全素子をアップデートする方法及び対応するアップデートサーバ - Google Patents

Description

本発明は通信の分野に係り、より詳細には例えばセルラ方式の通信ネットワーク上の端末に含まれる保全素子をアップデートする方法に関する。端末は、例えば携帯電話、通信媒体又はＰＤＡ等のモバイル端末である。

フランス特許出願第２８９２８３７号により、プロセス中に無線通信ネットワークに存在する保全素子へデータをダウンロードすることが知られている。ダウンロードは通信ネットワークに接続したアップデートサーバから実行される。

保全素子は、ＭＭＣ（マルチメディアカード）、ＳＤ（セキュアデジタル）、又はＵＩＣＣ（汎用集積回路カード）などの、チップカードである。ＵＩＣＣチップカードは、たとえば、ＵＭＴＳ（汎用モバイル通信システム）またはＵＴＲＡＮ（ＵＭＴＳ地上無線アクセス・ネットワーク）タイプの第３世代（３ＧＰＰ）、またはＣＤＭＡ２０００タイプの第３世代（３ＧＰＰ２）のＣＤＭＡ（符号分割多重アクセス）、あるいは第４世代（ＬＴＥ）で作動するモバイル端末に関連付けられた、端末がＧＳＭ（登録商標）またはＧＰＲＳタイプの携帯電話である場合のＳＩＭ（加入者識別モジュール）アプリケーション、あるいは、ＵＳＩＭ（汎用加入者識別モジュール）、ＲＵＩＭ（取り外し可能ユーザ識別モジュール）、またはＩＳＩＭ（ＩＰ加入者識別モジュール）アプリケーションが提供されたカードである。

アップデートサーバは、アクティブサーバ又はＯＴＡ（Ｏｖｅｒ Ｔｈｅ Ａｉｒ）カード管理プラットフォームとも呼ばれ、無線通信ネットワークを管理するオペレータが、モバイル端末内のチップカードを制御し、それらのコンテンツを修正できるようにする、ソフトウェアを備える。このようなオペレータ主導（プッシュ・モード）の操作は、たとえば、オペレータによって管理される複数のカードの内の所定のカードへのファイルのダウンロード、あるいは、オペレータによって管理されるカード内での、所与のアプリケーションのダウンロードまたは削除、または、ファイルまたは所与のアプリケーション内のデータの修正に関する。

既存の通信ネットワークにおいて、保全素子の自動アップデートは、大量のアップデートプロセスの中から計画される。このような自動アップデートでは、保全素子を、結合しているモバイル端末を介してアップデートサーバに接続するようプログラムする。これにより所与の保全素子は、自らアップデートサーバへ例えば定期的に（例えば毎週）接続する。その後アップデートサーバは、必要がある場合には保全素子へデータをダウンロードする。アップデートサーバは、再度サーバへ接続する必要がある日時を保全素子へ通知してもよい。

既存のＩＰネットワークにおいて、保全素子はｈｔｔｐプロトコルに従ってサーバへ接続する：サーバとの間でセキュアリンクを開通し、サーバはこのリンクを用いてアップデートデータを送信する。実際には、保全素子はｈｔｔｐｓ上に「オープンチャネル」を作成し、サーバは可能であれば応答する。サーバは、数千の保全素子に応答し、それらのアップデートを実行するために、同数のセキュアな接続を並行して同時に管理することができる。
従ってアップデートサーバは、数百万個、又は数億個もの保全素子を経時的に管理することができる。

フランス特許出願第２８９２８３７号明細書

既存のアップデートサーバが有する問題の１つは、保全素子の早急なアップデート、即ちサーバへの自動的な接続を待たずに行われるアップデートが必要とされる場合に、時としてアップデートプロセスのアクティブサーバからのトリガが必要となることである。このような早急なアップデートは、例えば、保全素子のオペレーティングシステムの誤りを修正すること（「パッチャ」）、又は安全対策に欠陥が発見された場合に銀行のアプレットを他のものに交換することであってもよい。このようなアップデートでは、保全素子が自発的にサーバへ接続することを待つことはできず、故に保全素子のアップデートプロセスを開始する必要がある。通常このようなプロセスは、サーバへ接続するよう、各保全素子へ接続を要求するメッセージを送信することで開始される。このようなプロセスは例えば、数千の保全素子の群に、アップデートサーバへ接続する必要があることを通知する、ＳＭＳ又はＥ−ＳＭＳメッセージ（すなわちコマンドを含むＳＭＳメッセージ）を送信することで行われる。接続が確立されるとすぐに、上述のように、サーバは接続している保全素子へアップデートデータ（例えば、オペレーションシステムのパッチ又はアプリケーションの交換）を送信する。

しかしながら、この方法には多数の欠点がある。
この方法の一つ目の欠点は、送信するＳＭＳ又はＥ−ＳＭＳの数が大量であるため、ネットワークのオーバーロードを引き起こしうる点である。
二つ目の欠点は、サーバが、ネットワーク上で実際にアクティブな保全素子だけではなく、ネットワークのオペレータのＨＬＲ（ホーム位置レジスタ）に提供された保全素子にもコンタクトをとる点である。実際に、そのような保全素子の内のいくつかは、例えば最終的な使用者に配布されていないために、アクティブではない可能性がある。アクティブではなく、故に、接続を要求するメッセージの指示に応答することができない保全素子への対処が試みられている。

本方法の三つ目の欠点は、自動アップデートに必要とされる数に加え、接続を要求するメッセージと同じ数のオープンｈｔｔｐｓチャネルの開通を可能としなければならない点である。これはサーバのオーバーロードを引き起こす可能性があるため、同時に維持できる数の保全素子に対してのみ接続を要求することとなり、その結果プロセスが行う保全素子のアップデートの数は減少してしまう。

本発明は、より具体的には、これらの欠点を解消することを目的とする。
より詳しくは、本発明の１つの目的は、アップデートプロセスの際にサーバから保全素子へ送信される接続要求のメッセージの数を限定する、保全素子をアップデートするための方法を提供することであり、この方法は、ネットワーク上で実際にアクティブな保全素子にのみメッセージを送信し、サーバの安定した負荷を保つ。

この目的は、後述のその他の目的と同様、通信ネットワーク上の端末に含まれる保全素子をアップデートする方法により達成され、端末は、自動アップデートを行うために、ネットワーク上のサーバがデータを送信できるよう、当該サーバに第一の順で接続し、本方法は、保全素子をアップデートするプロセスでは、サーバへ接続するよう、接続を要求するメッセージを保全素子へ送信し、また、自動アップデートにより最後にアップデートされた保全素子をアップデートプロセスの開始時点以降に優先順位に基いてアップデートするために、接続を要求するメッセージを第一の順と反対の順で保全素子に優先的に送信する。

有利には、保全素子はＳＩＭカードである。
もう一つの実施形態では、保全素子はＥＳＥである。
端末は好ましくは携帯電話である。
接続を要求するメッセージは、有利にはＥＳＭＳである。
本発明に係る方法では、好ましくはアップデートプロセスの間に、サーバから保全素子へ将来の自動アップデートの日付を送信する。

本発明はまた、通信ネットワーク上の端末に含まれる保全素子をアップデートするサーバに関し、当該サーバは、保全素子のアップデートの日付に関するデータベースに接続したフローコントローラを有し、当該フローコントローラは、接続を要求するメッセージを、保全素子の最後のアップデートの日付に基づいて、アップデートプロセスの開始時点以降に、最も新しいアップデート日から最も古いアップデート日の順で保全素子へ送信することを制御する。
本発明は、限定事項としてではなく例として挙げられた、以下の好適な実施形態の説明を添付の図面と共に読むことで、最もよく理解されるだろう：

保全素子のアップデートプロセスの工程を示す図である。 本発明に係るサーバを含むシステムを示す図である。

図１は、保全素子のアップデートプロセスの工程を示す図である。図には、３つのタイムスケール１Ａ、１Ｂ及び１Ｃが含まれている。
スケール１Ａは、アップデートプロセスの開始に対応する時点ＤＣにおける、保全素子の自動アップデートの状況を示している。この例では、時点ｔ０に開始されたアップデート時間Ｔの間に、２千万の保全素子がアップデートされたと考えられる。

スケール１Ｂは、本発明に係るアップデートプロセスの工程を示している。時間軸より下の保全素子の群は、自動アップデートが実行された保全素子であり、アップデートサーバでの特定の動作は行なわれていないことを意味する（サーバから保全素子への接続を要求するメッセージの送信は行なわれていない）。時間軸より上の保全素子の群は、アップデートプロセスの中でアップデートが実行された保全素子であり、サーバがこれらの保全素子へ接続を要求するメッセージを送信することを意味する。

スケール１Ｂに示されるように、アップデートプロセスの開始時点ＤＣ以降に最初にアップデートプロセスに関与する保全素子は、最後に自動アップデートによる更新を行った保全素子である。番号１の保全素子の群が自動アップデートにより更新された場合、最後にこの自動アップデートにより更新された保全素子の群２０が、最初にプロセスに関与する保全素子の群となる。従って接続を要求するメッセージが、サーバから保全素子の群へ送信される。サーバへ接続するとすぐにアップデートプロセスに関するデータが送信される。次に保全素子の群２が自動アップデートにより自動的に更新される。その後アップデートプロセスは保全素子の群１９についてアップデートを行い、図１に示される、プロセスの終了時点ＦＣまで同様の動作が繰り返される。

プロセスの開始時点において、保全素子の群が１から２０の順で並んでいた場合には、現在は経時的に１−２０−２−１９−３−１８−４−１７−…−１２−８−１１の順となることが示され、またプロセスは恐らく、保全素子９の自動アップデートの後に保全素子１０のアップデートを行うことで終了することが示されている。
アップデートプロセスにおいて、保全素子が、矢印５０によって示される第一の順（１から２０まで）でサーバへ接続する場合には、このアップデートプロセスは、接続を要求するメッセージを、第一の順とは逆の順番で保全素子へ優先的に送信することが示されている。これにより、保全素子１から９は接続要求を送信する必要のない自動アップデートにより更新され、保全素子１０から２０のみがプロセスに関与するため、送信する接続要求の数は限定されることとなる。

更に、保全素子１０から２０は事前に最近アップデートされた保全素子であるため（スケール１Ａ）、接続を要求するメッセージは、事前に接続したことで実際にアクティブである保全素子へ送信されることになる。
最後に、アップデートを最近終えたばかりの保全素子に第一に送信することで、保全素子をアップデートするために自動アップデート時間Ｔ（ｔ０+２Ｔ）が終了するまで待つ必要がなくなる。

図２は、本発明に係るサーバを含むシステムを示す図である。
図２のシステムは、ショートメッセージサービスセンタ（ＳＭＳＣ）１０１から成る通信ネットワークの一部と、サーバ１００によって管理可能な、モバイル又は固定端末に含まれる保全素子１０２の群と共に、保全素子をアップデートするためのサーバ１００を含む。システムはまた、保全素子１０２のアップデートプロセスを指示するためにサーバ１００に接続できるユーザ１０３も含む。

サーバ１００は、プロセス構築部１０４、サーバフローコントローラ１０５、及び保全素子１０２のアップデートの履歴を有するデータベース１０６を、ｈｔｔｐｓモジュール１０７と共に含む。ｈｔｔｐｓモジュール１０７は、セキュアモードで実行されるインターネットアプリケーションを有する。これは、例えばアプリケーションサーバに配備されたｗａｒモジュールであってもよい。

本発明によると、二つのプロセスが並行して実行される：保全素子１０２の自動アップデート（例えば時間Ｔごとに行われる）と、プロセス（例えば保全素子１０２をアップデートするために時間Ｔの終了を待つことができない、緊急と考えられるプロセス）によるこの保全素子のアップデートである。

保全素子１０２の自動アップデートでは、まず初めに初期設定段階において、定期的にサーバ１００へ接続するよう保全素子１０２をプログラムする。保全素子は、クロックを備えた、与えられた端末と連携する。保全素子１０２は、接続している端末のクロックを定期的に参照し、サーバ１００に接続するよう求められている時間が来ると、ｈｔｔｐｓモジュール１０７に、セキュアチャネルを開通するためのリクエスト１１０を送信する。このようなリクエスト１１０は、例えばＩＰネットワーク（例えばＬＴＥタイプ）の場合には、ｈｔｔｐｓモジュール１０７へ「オープンチャネル」コマンドを送信することで行われる。通信チャネルを保護するために、保全素子１０２とｈｔｔｐｓモジュール１０７との間の仲介としてアパッチタイプのｈｔｔｐサーバが使用されてもよい。このチャネルが確立されると、ｈｔｔｐｓモジュール１０７は保全素子１０２のアップデートを実行し（図示せず）、ステップ１１１において、保全素子１０２の最新のアップデートを、接続しているデータベース１０６に保存する。

プロセスによる保全素子１０２のアップデートは、クライアント１０３により決定される。クライアント１０３は、例えばＴＳＭ（Ｔｒｕｓｔｅｄ Ｐａｒｔｙ Ｍａｎａｇｅｒ）、又は保全素子１０２の緊急アップデートが必要であることを決定する権限のあるエンティティである。
この目的のために、クライアント１０３は、このプロセスの実行に必要なエレメント（保全素子１０２を操作するシステムのパッチ、保全素子１０２にインストールするための新しいプログラム、実行されるタスクのシナリオ、等）と共にコマンド１１２をプロセス構築部１０４へ送信する。

次にプロセス構築部１０４は、接続を要求するメッセージの送信要求１１３を、例えば「保全素子１０２へトリガＳＭＳを送信せよ」といった形式で、フローコントローラ１０５へ送信する。

このようなコマンドを受信するとすぐに、フローコントローラ１０５は、ステップ１１４においてデータベース１０６をポーリングし、ステップ１１５で保全素子１０２のアップデートの履歴を提供するよう要求する。この履歴、より詳細には最新のアップデートの日付をもとに、サーバ１００が許容しうる最大同時接続数を認知しているフローコントローラ１０５は、ステップ１１６において、ＳＭＳＣ１０１へ接続を要求するメッセージ（「トリガＳＭＳ」）を送信する。ＳＭＳＣ１０１へ送信されるメッセージの数は、自動アップデートにより生じるサーバ１００の負荷を考慮して決定される。次にＳＭＳＣ１０１は、ステップ１１７において、ｈｔｔｐチャネル（例えば「オープンチャネル」タイプ）を開通するためのコマンド（ＳＭＳ又はＥ−ＳＭＳ）を保全素子１０２へ送信する。その後保全素子はオープン通信チャネルを通じてｈｔｔｐｓモジュール１０７にコンタクトし（ステップ１１８）、ｈｔｔｐｓモジュール１０７はプロセス構築部１０４に保存された必要なエレメントによって保全素子をアップデートし、アップデートの日付をデータベース１０６へ送信する（ステップ１１９）。

アップデートされる保全素子は、一般的にはＳＩＭまたはＵＩＣＣカードである。ＳＩＭの機能を、端末内で端末に結合している部品に統合することも可能である。この場合、これらはＥＳＥ（埋設保全素子）と呼ばれる。
本発明はまた、保全素子が車、自動販売機又はカメラ等の機械に備えられている、Ｍ２Ｍ通信にも適用される。

Claims (7)

1. 通信ネットワーク上の端末に含まれる保全素子（１０２）をアップデートする方法であって、前記端末は、自動アップデートを行うために、前記ネットワーク上のサーバ（１００）がデータを送信できるよう、当該サーバに第一の順（５０）で接続し、本方法は、前記保全素子（１０２）をアップデートするプロセスでは、前記サーバ（１００）へ接続するよう、接続を要求するメッセージ（１１６）を前記保全素子（１０２）へ送信し、
   前記自動アップデートにより最後にアップデートされた保全素子（１０２）を前記アップデートプロセスの開始時点（ＤＣ）以降に優先順位に基づいてアップデートするために、接続を要求する前記メッセージ（１１６）を前記第一の順（５０）と反対の順（５１）で前記保全素子（１０２）に優先的に送信することを特徴とする方法。
2. 前記保全素子（１０２）はＳＩＭカードであることを特徴とする、請求項１に記載の方法。
3. 前記保全素子（１０２）はＥＳＥであることを特徴とする、請求項１に記載の方法。
4. 前記端末は携帯電話であることを特徴とする、請求項１乃至３のいずれか１項に記載の方法。
5. 接続を要求する前記メッセージ（１１６）はＥＳＭＳであることを特徴とする、請求項１乃至４のいずれか１項に記載の方法。
6. 前記アップデートプロセスの間に、前記サーバ（１００）から前記保全素子（１０２）へ将来の自動アップデートの日付の送信も行うことを特徴とする、請求項１乃至５のいずれか１項に記載の方法。
7. 通信ネットワーク上の端末に含まれる保全素子（１０２）をアップデートするサーバ（１００）であって、前記サーバ（１００）は、前記保全素子（１０２）のアップデートの日付に関するデータベース（１０６）に接続したフローコントローラ（１０５）を有し、前記フローコントローラ（１０５）は、接続を要求するメッセージ（１１６）を、前記保全素子（１０２）の最後のアップデートの日付に基づいて、アップデートプロセスの開始時点（ＤＣ）以降に、最も新しいアップデート日から最も古いアップデート日の順で前記保全素子（１０２）へ送信する指令を出す、サーバ。

Images