JP2010525627A - エンドユーザの端末システムにおけるデータベース更新を通知するための方法および装置 - Google Patents

Abstract

本発明は、エンドユーザの端末システムにおけるデータベース更新を通知するための方法および装置に関するものである。この方法は、移動システム（１００，２００）において利用可能なサービス（３００，４００，５００，６００）にデータベース（８００）の更新を通知するためのもので、前記サービスの順序付リストに従って複数のサービスにデータベースの更新を信号伝送するソフトウェアモジュール（７００）に依存する。
【選択図】 図１

Description

本発明はエンドユーザの端末システムにおけるデータベースの更新を通知するための方法および装置に係り、端末システムに格納されたサービスが確実にデータベースの最新のコンテンツを利用できるようにするためのものである。より詳細には、本発明は、いかなるデータベースの更新をも認識するための効率的なやり方を提供する、装置で実行される方法に関する。この方法は、システムに格納されたすべてのアプリケーションが利用することができる。

例えば、本発明は、電話帳と情報のやり取りを行う通信スマートカードに埋め込まれたすべてのアプリケーションに関する。

本発明の目的は、個人トークンに格納されたサービスを実行するすべてのアプリケーション間で共有される正しい電話帳情報をサービスが利用することを担保することである。この個人トークンは、移動端末システムの一部である。

こうしたサービスはますます増加し、且つますます複雑化しており、また、電話帳はそれらのほとんどにとって中心的なデータベースとなっている。そのため、そのようなサービスを実行するアプリケーションにとっては、少なくとも電話帳の更新が行われるたびに起動されるという問題は極めて重大となりうる。

実際、次のような様々な種類の更新が管理されなければならない。
・「外部」ファイル更新イベントの登録およびアプレットのトリガ順序
・「内部」ファイル更新イベントの登録およびアプレットのトリガ順序
・ＯＴＡアプレット管理のための動的登録／登録解除
・電話帳にまつわるすべてのサービス（検索、分類等）

現在のところ、そのような特定のファイルへのアクセスが行われる場合には、３ＧＧＰ標準 ＥＴＳＩ ＴＳ １０２．２４１ ｖ６．１１．０、「§６．２イベントの定義」に開示されているように、求められたアプリケーションを起動するために、専用のイベントＥＶＥＮＴ＿ＥＸＴＥＲＮＡＬ＿ＦＩＬＥ＿ＵＰＤＡＴＥが用いられる。更新は移動端末のエンドユーザインタフェースを用いて行われるので、このことは、入力／出力アクセスのみにとっては機能的である。しかし、別のアプリケーションが前記した専用ファイルに内部アクセスする場合、あるいは専用ファイルがＯＴＡ（Ｏｖｅｒ Ｔｈｅ Ａｉｒ：無線）で更新される場合にはそうではない。

すると、少なくとも電話帳への更新が行われるたびに起動されるという問題は、ＥＶＥＮＴ＿ＥＸＴＥＲＮＡＬ＿ＦＩＬＥ＿ＵＰＤＡＴＥの利用に基づく標準化実装によっては解決されない。また、例えば個人トークンに格納された他のアプリケーションによって行われた内部更新についても同様である。

ＳＩＭツールキットアプリケーションは事業者により提供される便利なサービスを含み、加入者識別モジュールの内部に埋め込まれる。したがって、アプリケーションライタが、そのアプリケーションが最新の電話帳コンテンツを利用するであろうことを確認するには、定期的にその電話帳のすべてのコンテンツを再読しなければならず、煩雑である（そのようなサービスの一例は、ＯＴＡサーバサービスにおける電話帳バックアップである）。あるいは更に煩雑なことには、アプリケーションライタは、自分が開発しているサービス（連絡先交換サービスや電話番号サービスの国際化など）が、電話帳が変更されるたびに呼び出されることを確かめなければならない場合もある。

したがって、通信事業者およびパートナーが電話帳に基づいた統合サービスを提案できるようにするために、エンドユーザの端末システムにおけるデータベース更新の検出を容易にする、携帯可能で使い勝手の良いやり方を提供することが望ましい。
この目的は、特許請求の範囲に記載された発明によって達成されるものである。
本発明の他の目的、利益および側面は、以下の説明により明らかになるであろう。説明は、添付の図面を参照してなされる。

本発明は、通信事業者に、電話帳あるいは他のファイルおよび／またはデータベースのどんな更新にもサービスが適応することを確実にするための安全なやり方を提供する。
この開示されたソリューションは、アプリケーション間のハードコード化されたリンクを置き換える。すなわち、他のいずれのサービスにも影響を与えることなくアプレットをＳＩＭから除去するかまたはＳＩＭに追加することができる。移動事業者は、どんな電話帳更新もさらに検出および伝送されるであろうことを確信する。

開示されたソリューションは、Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ Ｓｔｅｐｐｉｎｇ Ｓｔｏｎｅｓ Ｒｅｌｅａｓｅ ６に記載のＳＩＭａｌｌｉａｎｃｅ組織によって利用されるような、現在のＥＴＳＩ／３ＧＰＰ／ＧｌｏｂａｌＰｌａｔｆｏｒｍ標準と互換性を持つすべてのスマートカードに準拠する。

本発明は、ブランドおよびモデルに関わりなくすべての携帯電話機で使用できる携帯可能なソリューションであるため、実際、同様に市販されているすべての移動システムにおいて実装可能であり、同一のエンドユーザエクスペリエンスをもたらすことができる。

電話帳が様々なサービスにより利用される様子を表すことにより、なぜデータベースの更新がすべての関与するサービスに対して利用可能にされなければならないのかを説明する図。 プレイヤの様々な役割を表し、更新が内部サービスによってなされる場合に、電話帳の少なくとも１つの項目の更新が検出され、関係するすべてのアプリケーションに伝送される様子を示す図。 プレイヤの様々な役割を表し、更新が端末のＭＭＩ（マン・マシン・インタフェース）を用いてなされる場合に、電話帳の少なくとも１つの項目の更新が検出され、関係するすべてのアプリケーションに伝送される様子を示す図。 本発明の一実施形態において、更新が内部サービスによってなされる場合に、電話帳の少なくとも１つの項目の更新が検出され、関係するすべてのアプリケーションに伝送される様子を説明する一連のステップを示すフロー図。 本発明の一実施形態において、更新が端末を用いてなされる場合に、電話帳の少なくとも１つの項目の更新が検出され、関係するすべてのアプリケーションに伝送される様子を説明する一連のステップを示すフロー図。

図１に開示されるように、エンドユーザが、移動端末１００および個人トークン２００からなる自身の移動端末システムを用いて電話帳８００に変更を加える場合、その変更とは、データベースの項目の更新、追加または削除である。このとき、電話帳８００において発生しているすべてのイベントを集中させそれらを電話帳インデクセーション３００、連絡先交換５００、電話帳バックアップ／復元６００および国際リナンバリング４００などの関係するアプリケーションで送出する専用のソフトウェアモジュール７００を用いることによって、サービスのすべての関係するアプリケーションが起動される（３００，４００，５００および６００）。

選択的には、前記モジュールは電話帳にまつわるサービス（連絡先検索、好適な基準を用いた連絡先の分類など）を集中させてもよい。

本発明はまた、すべての関係するアプリケーションが利用可能な、効率的かつ信頼できる更新検出方法を提供するための専用ソフトウェアモジュール７００にも関わるものである。それらのアプリケーションは、個人トークンそれ自体２００または移動デバイス１００の内部に格納される。

本発明の一実施形態によれば、この専用ソフトウェアモジュール７００は、個人トークン２００に格納されたアプレットである。

以下、本発明の実施例を説明する。この実施例においては、エンドユーザが、加入者識別モジュール２００に関連しＧＳＭや第３世代通信網（図示しない）などの移動無線通信網を介して接続された自身の移動端末１００すなわち携帯電話機の電話帳８００に格納された連絡先携帯電話番号を更新している。

加入者識別モジュール（ＳＩＭ）２００では、ＲＯＭメモリ、フラッシュメモリまたはＥＥＰＲＯＭメモリなどの専用メモリに専用アプリケーション７００が格納されている。このアプリケーションは、市場に出される前の個人化の段階においてカードのメモリにインストール可能である。または、無線（ＯＴＡ）インフラストラクチャや販売時点情報管理ソリューション等の発行後インフラストラクチャを用いてインストールすることができる。
この専用アプリケーションはまた、別の実施形態においては、移動端末メモリに格納することもできる。

電話帳共有の例は、ＥＴＳＩ ＴＳ １０２．２２６および／または動的メニューＳＩＭツールキットサービスに記載されているように、第３世代電話帳バックアップ／復元、国際リナンバリング、連絡先交換、電話帳インデクセーション、遠隔ファイル管理アプリケーションなどの、電話帳にまつわる一連のアプリケーションであってもよい。
これらのアプリケーションのうちいくつかは、電話帳のコンテンツを使用し、および／または更新する。一方、いくつかの他のアプリケーションは、閲覧モードでのみそのようなデータベースのコンテンツにアクセスする。
更新とは、データベースの１つまたはいくつかの記録の追加、修正または削除であってもよい。

データベースは前記端末システム１００および２００に格納されたあらゆる種類のデータであり、移動デバイスそれ自体１００および／または個人トークン２００に格納される。好適な一例は、ＥＴＳＩにより標準化された周知の第２世代または第３世代の電話帳８００であり、個人トークン２００に格納され、エンドユーザには移動装置１００の画面上で利用可能である。しかしながら、当業者には、この方法が、個人トークンを有するまたは有さない携帯電話機と、同一または異なるネットワーク上で動作可能なＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）やスマートフォンなどの移動デバイスを含む他のタイプの移動システムにも適用できることが認識されるであろう。

より具体的には、個人トークン２００に格納されたＳＩＭツールキットアプリケーションについては、そのようなアプリケーションは専用モジュール７００に登録され、どんな更新であれ電話帳８００の更新がなされるとすぐに確実に呼び出されるようになっている。エンドユーザは、電話帳に基づいたサービスを、それらのサービスが電話帳の最新版を利用していることを確信して利用することができる。

このソリューションは、更新のすべてを集中化し、関係するすべてのアプリケーションに所定の順序に従って更新情報を伝送する専用モジュール７００に基づくものである。

このようなサービスを運営する通信事業者が、ＯＴＡソリューションを用いて電話帳に何らかの変更を行いたい場合、例えば国の識別番号を変更したい場合には、事業者は、電話帳に関係するすべてのサービスがそのような新しい識別番号を利用することを確認しなければならないであろう。これは、ここに開示される本発明を用いて、専用モジュール７００が電話帳に対するそのような修正を検出し、その更新をすべての関係するアプリケーションに伝送することによって行うことができる。

図１に示すように、本発明によれば、電話帳のどんな修正についても、加入者識別モジュール２００に格納された専用ソフトウェアモジュール７００が起動され、すべての関係するサービスが、信頼性のあるやり方で、電話帳の何かが変更されたことを認識できる。この信号伝送は、すべての加入サービス間で所定の順序に従って行われる。

例えば、図１において、エンドユーザが、ＳＩＭカードに格納されている自身の第２世代電話帳の連絡先の１つの電話番号を変更するか、あるいは内部サービス３００，４００，５００または６００が電話帳に何らかの変更を行うとすぐに、ソフトウェアモジュール２００が起動され、関係するサービスに更新信号を伝送する。

図２は、電話帳の変更がサービス５００によって行われる場合に、電話帳の項目の更新を検出し、それをすべての関係するアプリケーションに伝送するために専用ソフトウェアモジュール２００がたどる主な段階を示す。

連絡先交換サービス５００はそのような変更をソフトウェアモジュール２００に通知し、ソフトウェアモジュール２００は、所定の信号伝送順序に従って、電話帳インデクセーション３００、電話帳バックアップ／復元６００および国際リナンバリング４００などの登録されたサービスに更新を通知する。

図３は、電話帳の変更が、例えば移動端末１００を利用するエンドユーザによって行われる場合に、電話帳の項目の更新を検出し、その更新をすべての関係するアプリケーションに伝送するために専用ソフトウェアモジュール２００がたどる主な段階を示す。

移動端末はこのような変更を専用のイベントを用いてソフトウェアモジュール７００に通知し、するとソフトウェアモジュール７００は、電話帳インデクセーション３００、電話帳バックアップ／復元６００および国際リナンバリング４００などの登録されたサービスに更新を通知する。

図４には、電話帳８００における変更がサービス５００（図２を参照）によってなされる場合を詳細に示す。

・ステップ０： 登録段階： データベース修正についての通知を必要とするサービスが専用ソフトウェアモジュール７００に登録される。認可され順序付けられたすべてのサービスからなる信号伝送順序リストは、新しく登録されたサービスで更新されなければならない。この登録段階（ステップ０）は、当然ながら１つのサービスにつき１回のみ行われる。

・ステップ１： 更新段階： 電話帳バックアップ／復元サービス６００が電話帳８００において更新を行い、ソフトウェアモジュール７００により提示されるＮｏｔｉｆｙＩＮＣａｒｄ関数の呼び出しを利用して、その修正を、ソフトウェアモジュール７００に、修正されたファイルの識別参照番号および１つまたはいくつかの修正された記録番号とともに通知する。

・ステップ２： 通知段階： ソフトウェアモジュール７００が、電話帳インデクセーション３００、国際リナンバリング４００および連絡先交換５００などのすべての登録されたサービスに電話帳更新通知を伝送する。これは、先にｎｏｔｉｆｙＩＮにおいて供給されたパラメータを用い、専用の関数ｎｏｔｉｆｙＯＵＴを用いて行われる。このような通知は、信号伝送順序リストにおいて定義された順序に従ってなされる。
・ステップ３： 適用可能な処理： 通知されたサービスは内部で処理可能である。

国際リナンバリングサービス４００がデータベースにおいて更新を行った場合でも、処理の段階は全く同じになる。唯一の違いは、その場合には国際リナンバリングサービス４００は通知を受けないため、ソフトウェアモジュール７００がたどる信号伝送の順序が異なるという点である（発明者による例では、電話帳インデクセーション３００、その後連絡先交換５００）。
更新が発生したサービスに対しては、その変更は当然ながら既にデータベース８００において認識されているので、通知は行われない。

１つの好適な実施形態においては、登録されていないサービスが、ＮｏｔｉｆｙＩＮＣａｒｄを用いて、自身がデータベース８００で更新を行ったことを通知できる。しかし、いずれにせよ登録されていないので、通知を受信することになる。

図５には、電話帳における変更が端末１００を利用して行われる場合（図３も参照）が詳細に示される。

・ステップ０： 登録段階： データベース修正についての通知を必要とするサービスが専用ソフトウェアモジュール７００に登録される。信号伝送順序リストは、登録されたすべてのサービスを含むように更新されなければならない。この登録段階（ステップ０）は、当然ながら１つのサービスにつき１回のみ行われる。

・ステップ１： 更新段階： 端末１００は電話帳で更新を行い、ＥＶＥＮＴ＿ＥＸＴＥＲＮＡＬ＿ＦＩＬＥ＿ＵＰＤＡＴＥイベントを用いて、ソフトウェアモジュール７００に修正を通知する。通知を受けたソフトウェアモジュール７００は、ＥＴＳＩ １０２．２４１標準イベントであるＥＶＥＮＴ＿ＥＸＴＥＲＮＡＬ＿ＦＩＬＥ＿ＵＰＤＡＴＥを投げる。そのパラメータはファイル識別番号および１つまたはいくつかの修正された記録番号である。

・ステップ２： 通知段階： ソフトウェアモジュール７００は、受信したパラメータを再フォーマットし、それから電話帳インデクセーション３００、国際リナンバリング４００、電話帳バックアップ／復元６００および連絡先交換５００などのすべての登録されたサービスに電話帳更新通知を伝送する。これは、先にＥＶＥＮＴ＿ＥＸＴＥＲＮＡＬ＿ＦＩＬＥ＿ＵＰＤＡＴＥにおいて提供されたパラメータを有する専用の関数ｎｏｔｉｆｙＯＵＴを用いて行われる。このような通知は、信号伝送順序リストに定められた順序に従って行われる。
・ステップ３： 適用可能な処理： 通知されたサービスは内部で処理可能である。

ある好適な実施形態においては、各アプリケーションは、電話帳への更新が行われる場合、どのような条件の下で起動されるかを選択することができる。条件は、例えば「削除のみ」、「何らかの変更」、「電話番号変更のみ」などであってもよい。

別の実施形態においては、個人トークン２００に格納されたすべてのアプリケーションが、電話帳８００に何らかの更新が行われる場合に、通信事業者により送信されたリストまたはサービスのアプリケーションＩＤを用いて構築されたリストに従い、デフォルトの順番で起動される。

図２乃至５を参照してより詳細に見ていくと、本実施例はＳＩＭツールキット標準化コマンドおよびイベントならびにＪａｖａ（登録商標）カードの共有可能なインタフェースの使用に基づいている。

ある実施形態における好適な実施例は専用モジュール７００に依存し、選択的にはカードオペレーティングシステムの一部である。この場合、そのカードオペレーティングシステムは、電話帳または他のいずれかのファイルおよび／またはデータベースの何らかの更新の検出および伝送を管理する。

有利には、電話帳更新に関する最も重要な優先度を有するサービスとより重要でない優先度を有するサービスとの分類は、更新が行われるたびに電話帳更新に関して最も実用的なアプリケーションが最初に検出され、その他のアプリケーションは好ましいシーケンスに従った順序で通知を受けるように行われる。これは、サービスＮの動作がサービス（ｎ−１）、（ｎ−ｃ）の結果に基づく場合に非常に重要となりうる。例えば、リナンバリングサービスはバックアップサービスよりも前に実行されるのがよい。

複数のサービスが起動される順序は、この事前登録順序に依存する。例えば、移動システム（１００，２００）に格納されたテーブルまたはファイル（図示しない）を通して実装される専用リストは、ソフトウェアモジュール７００によって実際に使用される。このリストは、データベース８００における更新を信号伝送するときに前記ソフトウェアモジュール７００が従うべき順序を定める。

開示された発明を実装する専用モジュール（図示しない）は、好適には個人トークン２００に格納される。
この個人トークンは、使用されるネットワークを担当する通信事業者が用いる技術に応じて、加入者識別モジュール（ＳＩＭ）、ＵＳＩＭ（ＵＭＴＳ加入者識別モジュール）、またはＩＳＩＭ（ＩＰマルチメディアサービス識別モジュール）である。

一実施形態によれば、この加入者識別モジュールは１つのソフトウェアであってもよく、この場合、専用モジュールも１つのソフトウェアであってもよい。

別の一実施形態によれば、この専用モジュールはＳＩＭツールキットアプリケーションであり、加入者識別モジュールメモリに格納されて上述の方法を実行する。そのようなアプリケーションはアプレットとして、あるいはより具体的には、Ｊａｖａ（登録商標）カードタイプの加入者識別モジュールで実装される場合、カードレットとしても知られる。以下、このアプリケーションをエージェントアプリケーションと称する。加入者識別モジュールプロセッサがこのエージェントアプリケーションを実行する。

移動端末１００および個人トークン２００は、連結されたデバイスとして示され説明されているが、そのような構成に限定されるものではない。例えば、赤外線ＩｒＤＡまたはＩＳＯ１４４４３などの非接触チャネルを用いて通信を行う２つの別々のデバイスであってもよい。

したがって、これらのデバイスは、公衆交換電話網（ＰＳＴＮ）、移動通信網、インターネットプロトコル（ＩＰ）ネットワークなどを含むネットワーク上で動作する。通信セッションは音声またはデータ通信セッションであってもよい。データ通信セッションの例としては、音声ストリーミング、画像ストリーミング、テレビ会議、ボイス・オーバー・アイピー（ＶＯＩＰ）があるが、これらに限られない。

好適な実施形態において、個人トークン２００に格納されたこのスタンドアロンモジュール７００は、発生する時間がいつであれどんな電話帳更新も確実に検出されるように、移動デバイス１００のハードウェアまたはソフトウェアの再起動によって起動される。

前記モジュールが電話帳更新を検出できるやり方はいくつかある。
・移動システム（１００，２００）に格納された内部サービスからデータベース８００に行われた更新については、ＮｏｔｉｆｙＩＮＣａｒｄ関数が内部サービス自身によりソフトウェアモジュール７００内で起動される。
・移動端末１００からの入力を用いてデータベースでなされた更新については、ＮｏｔｉｆｙＩＮＴｅｒｍ関数を起動するためのＥＶＥＮＴ＿ＥＸＴＥＲＮＡＬ＿ＦＩＬＥ＿ＵＰＤＡＴＥを用いて、ソフトウェアモジュール７００でＮｏｔｉｆｙＩＮＴｅｒｍ関数が起動される。

特定の実施形態においては、いくつかのサービスは、移動事業者の要求により、このソフトウェアモジュール７００を使用できる。

開示した方法においては、他の追加的な任意のステップを追加することが可能である。例えば、ある実施形態においては別の専用アプリケーションを利用可能であり、それにより移動事業者またはエンドユーザは、正しい暗証コードまたはキーを入力した後、信号伝送リスト内の、電話帳更新検出で起動されるサービスの優先度の順序を再整理することができる。
これらの様々なステップは、移動端末スクリーンに用いられるような通常のマン・マシン・インタフェースの使用を含むが、これに限定されない。

１００，２００ 移動システム
３００，４００，５００，６００ サービス
７００ ソフトウェアモジュール
８００ データベース

Claims (12)

1. 移動システム（１００，２００）において利用可能なサービス（３００，４００，５００，６００）にデータベース（８００）の更新を通知する方法であって、
   前記移動システムは前記データベースを予め格納し、
   前記方法は、前記サービスの順序付リストに従って前記複数のサービスに前記データベースの更新を信号伝送するソフトウェアモジュール（７００）に依存することを特徴とする方法。
2. 請求項１に記載の方法において、前記ソフトウェアモジュール（７００）は、前記データベースの更新の信号伝送のために新しいサービスの認可を考慮し、それに伴って前記サービスの順序付リストを再定義することを特徴とする方法。
3. 請求項１または２に記載の方法において、前記移動システムは少なくとも個人トークン（２００）と移動端末（１００）とから構成され、前記個人トークンは前記データベース（８００）を予め格納することを特徴とする方法。
4. 請求項２または３に記載の方法において、前記個人トークン（２００）はＵＩＣＣカードであることを特徴とする方法。
5. 請求項２乃至４のいずれかに記載の方法において、前記サービスは前記個人トークン（２００）に格納されることを特徴とする方法。
6. 請求項２乃至５のいずれかに記載の方法において、前記ソフトウェアモジュール（７００）は前記個人トークン（２００）に格納されることを特徴とする方法。
7. 請求項１乃至６のいずれかに記載の方法において、前記データベース（８００）は電話帳であることを特徴とする方法。
8. 請求項１乃至７のいずれかに記載の方法において、１つのサービスが電話帳インデクセーションサービス（３００）であることを特徴とする方法。
9. 請求項１乃至７のいずれかに記載の方法において、１つのサービスが電話帳バックアップ／復元サービス（６００）であることを特徴とする方法。
10. 請求項１乃至７のいずれかに記載の方法において、１つのサービスが国際リナンバリングサービス（４００）であることを特徴とする方法。
11. 移動端末（１００）と個人トークン（２００）とを備えた移動システムであって、
    前記移動システムは、前記移動システム（１００，２００）において利用可能なサービス（３００，４００，５００，６００）にデータベース（８００）の更新を通知するための指示を格納および実行し、
    前記移動システムは、前記データベースおよび／または前記サービスを予め格納し、
    前記指示が、前記サービスの順序付リストに従って前記複数のサービスにデータベースの更新を信号伝送するよう前記端末システムを誘導することを特徴とする移動システム。
12. 端末（１００）に関連付けられた個人トークン（２００）であって、
    前記個人トークンはデータベース（８００）およびサービス（３００，４００，５００，６００）を予め格納し、前記サービスの順序付リストに従って前記複数のサービスにデータベースの更新を信号伝送するよう前記個人トークンを誘導する指示を格納および実行することを特徴とする個人トークン。

Images