特許 6181214 モバイル機器

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6181214

(24)【登録日】2017年7月28日

(45)【発行日】2017年8月16日

(54)【発明の名称】モバイル機器

(51)【国際特許分類】

   H04M 1/00 20060101AFI20170807BHJP

   G06F 9/445 20060101ALI20170807BHJP

【ＦＩ】

   H04M1/00 R

   G06F9/06 650A

【請求項の数】4

【全頁数】17

(21)【出願番号】特願2016-2963(P2016-2963)

(22)【出願日】2016年1月8日

(62)【分割の表示】特願2013-500820(P2013-500820)の分割

【原出願日】2011年3月16日

(65)【公開番号】特開2016-123103(P2016-123103A)

(43)【公開日】2016年7月7日

【審査請求日】2016年1月8日

(31)【優先権主張番号】1005034.2

(32)【優先日】2010年3月25日

(33)【優先権主張国】GB

(73)【特許権者】

【識別番号】314008976

【氏名又は名称】レノボ・イノベーションズ・リミテッド（香港）

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(74)【代理人】

【識別番号】100084250

【弁理士】

【氏名又は名称】丸山 隆夫

(72)【発明者】

【氏名】ダーン、オリビエール

【審査官】 中村 信也

(56)【参考文献】

【文献】 欧州特許出願公開第０１９６２４８２（ＥＰ，Ａ１）

【文献】 国際公開第２０１０／０１６６７９（ＷＯ，Ａ２）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｍ １／００

Ｈ０４Ｍ １／２４−１／８２

Ｈ０４Ｍ ９９／００

Ｇ０６Ｆ ９／０６

(57)【特許請求の範囲】

【請求項1】

モバイル機器であって、
ＵＩＣＣに接続するためのＵＩＣＣインタフェースと、
前記ＵＩＣＣインタフェースを介して前記ＵＩＣＣと通信するように動作可能であるＵＩＣＣモジュールと、
前記モバイル機器によって実行される複数のアプリケーションを格納するメモリと、
ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供するＵＩモジュールと、
を有し、
前記ＵＩＣＣモジュールは、ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記ＵＩＣＣ上で利用可能なＵＩＣＣアプリケーションのＵＩＣＣアプリケーションメタデータを前記ＵＩＣＣから取得するように構成され、かつ、前記ＵＩＣＣアプリケーションメタデータを前記メモリに格納するように構成され、
前記ＵＩモジュールは、前記ＵＩＣＣアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるＵＩＣＣアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり、
前記ＵＩＣＣモジュールは、ＵＩＣＣアプリケーションを選択するユーザ入力に応答して、前記選択されたＵＩＣＣアプリケーションを起動するコマンドを前記ＵＩＣＣに送信するように動作可能であり、
前記コマンドは、起動される前記ＵＩＣＣアプリケーションを識別するエンベロープコマンドであり、
前記ＵＩモジュールは、前記モバイル機器上および前記ＵＩＣＣ上で利用可能な複数のアプリケーションの組合せを表示するユーザインタフェースを生成するように動作可能である、モバイル機器。

【請求項2】

前記ＵＩＣＣアプリケーションメタデータは、カテゴリデータを含み、前記ＵＩモジュールは、同じカテゴリのＵＩＣＣアプリケーションとモバイル機器アプリケーションとを前記ユーザインタフェース上でまとめるように動作可能である、請求項１に記載のモバイル機器。

【請求項3】

前記ＵＩＣＣアプリケーションメタデータは、エレメントファイル内の前記ＵＩＣＣ上に格納され、前記ＵＩＣＣモジュールは、前記エレメントファイルからメタデータを読み出すように動作可能である、請求項１又は請求項２に記載のモバイル機器。

【請求項4】

前記ＵＩＣＣアプリケーションメタデータは、前記ＵＩＣＣのために設けられたＵＩＣＣサービスメニューシステムを実行するプロセッサに与えられる、請求項１から３のいずれかに記載のモバイル機器。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信装置に関し、特に、汎用集積回路カード（ＵＩＣＣ）を内部に有するモバイル機器（ＭＥ）に関する。

【背景技術】

【0002】

携帯（セルラー）電話のようなＭＥは、特に、コアネットワークに対してユーザを識別するセキュアデータを保持するＵＩＣＣを含む。ＵＩＣＣは、いくつかのソフトウェアアプリケーションを実行することができる内蔵マイクロプロセッサおよびメモリを有するスマートカードである。ＵＩＣＣは、モバイル通信システムにおける非常にセキュアな要素である。さらに、高速プロトコルが定められ、ＵＩＣＣフラッシュメモリのサイズが増大した結果、ＵＩＣＣは、今では、高度なセキュリティレベルを必要とする、携帯支払いアプリケーションのようなアプリケーションの良好な記憶場所として考えられている。

【0003】

１つの既存の実現例では、ＵＩＣＣアプリケーションはＵＩＣＣサービスメニュー（または、ＵＳＩＭツールキットメニュー）によってアクセス可能である。エンドユーザは、実際のＵＩＣＣアプリケーションに達する前に、いくつかのメニューとサブメニュー（それらは、ユーザがＵＩＣＣサービスメニューを入力するときに、ＵＳＩＭツールキットプロアクティブコマンドを使用して、段階的に動的に作られる）を通過しなければならない。図４ａと図４ｂは、ＵＩＣＣアプリケーション、この例ではゲームのアプリケーション「エニグマ」にアクセスするために行われるステップを示している。ＭＥとＵＩＣＣ（図４ｂに示されている）の間で送信されるメッセージや、メニューおよびサブメニューの動的な生成のために、プロセス全体の時間が、特に低性能の移動端末上で非常に長くなることがある。この既存の実現例の他の欠点は、現在のＩＳＯインタフェースにある。すなわち、ＵＩＣＣサービスメニューにおいて既存の提案されている項目の多くは現在、テキスト形式で表示される。これらのメニュー項目にアイコン／画像を追加することは、ＵＩＣＣからＭＥへ送られるデータの量を増加させるであろうし、それによってＵＩＣＣサービスのメニュー／サブメニューの項目をエンドユーザに提示／表示する速度を低下させるであろう。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特表２００８−５２２３０１号公報

【特許文献2】特開２００８−２７１１２１号公報

【特許文献3】国際公開第２００９／０５１３７７号

【発明の概要】

【発明が解決しようとする課題】

【0005】

スマートカードウェブサーバ（ＳＣＷＳ）に基づく他の実現例は、ＥＴＳＩ ＳＣＰ（Ｒｅｌ−７）によって既に定められているが、今日未だ実施されていない。多くの場合、ＳＣＷＳに基づく解決策は、ＵＩＣＣの内容にアクセスする次世代のユーザインタフェースが中心になるであろう。すなわち、エンドユーザは、ウェブページのようなインタフェースを使用して、ＵＩＣＣの内容（アプリケーション、電話帳、ＳＭＳ、ローカルウェブサーバなど）にアクセスするであろう。ＳＣＷＳが今日、実際に実施されていない主な理由は、プロトコルのスタックと、下部にある物理インタフェースにある。ＳＣＷＳは、通常ＴＣＰ／ＩＰスタック上で実行されるＨＴＴＰに基づいている。ＵＩＣＣにおけるＴＣＰ／ＩＰのサポートは、ＥＴＳＩ ＳＣＰ Ｒｅｌ−７（ＥＴＳＩ標準書類ＴＳ １０２ ２２１、ＴＳ １０２ ６００、ＴＳ １０２ ２２３を参照）に定められている。この特徴をサポートする市販の製品（ＵＩＣＣとＭＥの両方）は現在のところ未だ存在しない。さらに、定められた高速プロトコル（ＵＳＢ）の物理インタフェースをサポートする既存の携帯電話機も存在しない。

【0006】

ＳＣＷＳは、ＵＩＣＣの内容にアクセスする、次世代のユーザインタフェースの正当な候補と目されているが、ＵＩＣＣのアプリケーションにアクセスすることは、いくつかのステップ、すなわち、アプリケーションの記憶場所に到達するまでに、ＭＥのブラウザアプリケーションを起動し、ＳＣＷＳ ＵＲＬを入力し、ＵＩＣＣをブラウズし、それから該アプリケーションの選択／起動を行うことを、なお必要としている。本発明者は、このプロセスがエンドユーザにとって依然として面倒であること、ユーザがＵＩＣＣのアプリケーションにアクセスする際により使いやすい方法が望ましいであろうこと、に気づいた。

【課題を解決するための手段】

【0007】

一実施態様では、これを達成し、ユーザエクスペリエンスをさらに高めるために、本発明者は、ＭＥが、利用可能なＵＩＣＣアプリケーションに関連する一組の関連データを検索することを可能にする新しいプロトコルを定めることを提案し、その結果、これら全てのＵＩＣＣアプリケーションがＭＥアプリケーションと同じようにエンドユーザに提示／表示されかつアクセスされることを可能にする（通常、アイコンとして提示される）。提案されるプロトコルはまた、エンドユーザが、対応するアイコンをクリック／選択することによって、ＵＩＣＣアプリケーションをダイレクトに起動することも可能にする。好適な実施態様では、ＵＩＣＣアプリケーションおよびＭＥアプリケーションのメニュー項目（例えば、アイコン）が、統一されたユーザインタフェースで一緒に表示され、その結果、ユーザは、アプリケーションがＵＩＣＣまたはＭＥによって格納され、ＵＩＣＣまたはＭＥによって実行されたか否かに気づかない。

【0008】

下記の例は、提案される解決策を使用して得られる結果を示している。‐「iＰｈｏｎｅ」のようなユーザインタフェースを考慮して、ＵＩＣＣアプリケーションに関連するアイコンは、他のＭＥアプリケーションのように、主メニュー内にダイレクトに示される。
‐例えば、ゲーム、ツールなどの異なる種類のアプリケーションに対して異なるフォルダーを含むＭＥユーザインタフェースを考慮して、ＵＩＣＣアプリケーションのアイコンは、同じカテゴリのＭＥアプリケーションのアイコン、例えば、ＵＩＣＣのゲームアプリケーションのアイコンがＭＥゲームアプリケーションなどと同じフォルダー内に位置するのと並んで、これらのフォルダー内に送られるであろう。

【0009】

提案された新しいプロトコルは次を使用し、含んでもよい。
‐ＵＩＣＣアプリケーションを特徴付けるメタデータ（例えば、カテゴリ、名前、（ユーザに提示される）アイコン、アプリケーションを起動するのに必要なパラメータ、利用可能なネットワークサービス（例えば、パケットサービス）への依存性など）を定める
‐ＵＩＣＣアプリケーションに関連するメタデータを全て格納する新しい専用のエレメントファイル（ＥＦ）（線形の一定の種類のＥＦ、ＵＩＣＣアプリケーション当たり１つのレコード）をＵＩＣＣ上に定める
‐ＵＩＣＣおよびＭＥの両方についてのサービス宣言ルーチン内に新しいサービスを追加する
‐この新しいエレメントファイルの読出しを含めることによって、ＭＥの電源投入シーケンスを更新する
‐ＭＥがエレメントファイルを一旦、検索すると、ＭＥは、これらＵＩＣＣアプリケーションのためのＵＩを、それ自身のＵＩアーキテクチャおよび能力に基づいて構築する
‐メタデータが、ＵＩＣＣアプリケーションの起動前にいくつかの追加の動作を必要とする場合に、エンドユーザと相互作用するモジュールをＭＥ内に定める（例えば、ログイン／パスワード、ネットワークサービスの利用可能性をチェックするなど）
‐ＭＥがＵＩＣＣに、選択されたＵＩＣＣアプリケーションを起動することを実際に要求することを可能にする、新しいエンベロープコマンドを定める
一実施態様では、ダイレクトアクセスのために必要なデータは、ＭＥの電源投入の間、
ＵＩＣＣからＭＥに転送される。これは、電源投入動作に数ミリセカンドを追加することになり、エンドユーザにとって完全にトランスペアレントとなる。それから、エンドユーザがＵＩＣＣアプリケーションを起動するとき、単一のエンベロープコマンドがＭＥによってＵＩＣＣに送られる。

【0010】

この新しいプロセスをＳＩＭツールキットに基づく既存の実現例と比較すると、（ＵＩＣＣアプリケーションを起動する）新しいエンベロープコマンドは、既存の実現例に要求される全ての必要なセットアップメニュー／エンベロープ（メニュー選択）／項目選択／…コマンド（図４ｂに示されている）に単純に置き換えられる。さらに、エンドユーザは、ＵＩＣＣアプリケーションに達する前にＳＩＭサービスメニューと数回、相互作用する必要はもはやない（これは、ユーザエクスペリエンスの著しい改善である）。

【0011】

一態様によれば、本発明は、モバイル機器であって、ＵＩＣＣに接続するためのＵＩＣＣインタフェースと、ＵＩＣＣインタフェースを介してＵＩＣＣと通信するＵＩＣＣモジュールと、モバイル機器によって実行される複数のアプリケーションを格納するメモリと、ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供するＵＩモジュールと、を有し、ＵＩＣＣモジュールは、ユーザのユーザインタフェースとの相互作用の前にまたはそれとは無関係に、ＵＩＣＣ上で利用可能なＵＩＣＣアプリケーションのＵＩＣＣアプリケーションメタデータをＵＩＣＣから取得するように構成され、かつ、ＵＩＣＣアプリケーションメタデータをメモリに格納するように構成され、ＵＩモジュールは、ＵＩＣＣアプリケーションメタデータを使用して、ユーザが、起動されるアプリケーションを選択できるようにするためのユーザインタフェースを生成し、ＵＩＣＣモジュールは、ＵＩＣＣアプリケーションを選択するユーザ入力に応答して、選択されたＵＩＣＣアプリケーションを起動するコマンドをＵＩＣＣに送信する、モバイル機器を提供する。一実施態様では、モバイル機器は、ＵＩＣＣアプリケーションメタデータを電源投入またはリセットルーチンの間に取得する。他の実施態様では、モバイル機器は、ユーザがモバイル機器上でまたはＵＩＣＣ上でアプリケーションをナビゲートするのを可能にするユーザインタフェースの表示の前に、ＵＩＣＣアプリケーションメタデータを取得するのを開始する。

【0012】

一実施態様では、ＵＩＣＣアプリケーションメタデータは、ＵＩＣＣアプリケーションの起動に必要な条件を含み、ＵＩＣＣモジュールは、ＵＩＣＣアプリケーションのユーザ選択に応答して、選択されたＵＩＣＣアプリケーションを起動するコマンドを送信する前に、選択されたＵＩＣＣアプリケーションに関連する条件をチェックする。前記条件は、必要なネットワークサービスを定めてもよい。この場合、ＵＩＣＣモジュールは、必要なネットワークサービスが利用可能であることをチェックしてもよく、必要なネットワークサービスが利用可能な場合にのみ、選択されたＵＩＣＣアプリケーションを起動するコマンドを送信する。前記条件は、ユーザ認証が必要であることを、代わりにまたは追加して定めてもよい。この場合、ＵＩＣＣモジュールは、ユーザ認証を実行し、ユーザ認証が成功した場合にのみ、選択されたＵＩＣＣアプリケーションを起動するコマンドを送信するであろう。ＵＩＣＣモジュールは、ユーザの名前とパスワードの少なくとも一方を入力するようにユーザに促すことによって、そして入力されたユーザの名前とパスワードの少なくとも一方を、ＵＩＣＣアプリケーションメタデータに用意されているユーザの名前とパスワードの少なくとも一方と比較することによって、認証を実行してもよい。

【0013】

一実施態様では、ＵＩＣＣアプリケーションメタデータは、アイコンまたはアイコンへのポインタを含み、ＵＩモジュールは、複数のアイコンを使用してユーザインタフェースを生成する。

【0014】

ＵＩモジュールは、モバイル機器上およびＵＩＣＣ上で利用可能な複数のアプリケーションの組合せを表示するユーザインタフェースを生成してもよい。ＵＩＣＣアプリケーションメタデータは、カテゴリデータを含み、ＵＩモジュールは、該カテゴリデータを使用して、同じカテゴリのＵＩＣＣアプリケーションとモバイル機器アプリケーションとをユーザインタフェース上でまとめることが可能である。

【0015】

一実現例では、ＵＩＣＣアプリケーションメタデータは、エレメントファイル内のＵＩＣＣ上に格納され、ＵＩＣＣモジュールは、エレメントファイルからメタデータを読み出す。

【0016】

本発明はまた、ＵＩＣＣであって、モバイル機器に接続するためのインタフェースと、複数のＵＩＣＣアプリケーションと該ＵＩＣＣアプリケーションに関するＵＩＣＣアプリケーションメタデータを格納するメモリと、モバイル機器と通信する制御モジュールと、を有し、制御モジュールは、ユーザの相互作用の前に、モバイル機器にＵＩＣＣアプリケーションメタデータを与えるように動作可能であり、かつ、モバイル機器からＵＩＣＣアプリケーションを起動するコマンドを受信するのに応答して、該ＵＩＣＣアプリケーションを起動するように動作可能である、ＵＩＣＣも提供する。好適な実施態様では、制御モジュールは、ＵＩＣＣのオペレーティングシステムの一部を構成するが、他の実施態様では、制御モジュールはＵＩＣＣ上の１つまたは複数の別個のモジュールとして設けられてもよい。

【0017】

ＵＩＣＣアプリケーションメタデータは、モバイル機器によって使用されるＵＩＣＣアプリケーションを起動するのに必要な条件を含み、モバイル機器は、選択されたＵＩＣＣアプリケーションを起動するコマンドを送信する前に、前記必要な条件が満たされたことをチェックする。前記条件は、例えば、必要なネットワークサービスと、ユーザ認証が必要であること、の少なくとも一方を定めてよい。ユーザ認証が必要な場合、ＵＩＣＣアプリケーションメタデータは通常、ユーザの名前とパスワードの少なくとも一方を含む。

【0018】

ＵＩＣＣアプリケーションメタデータは、ユーザインタフェース（例えば、ディスプレイ）上でユーザに表示されるアイコンまたはアイコンへのポインタを含んでもよい。ＵＩＣＣアプリケーションメタデータは、各ＵＩＣＣアプリケーションに関連するカテゴリを識別するカテゴリデータも含んでよい。

【0019】

一実現例では、ＵＩＣＣアプリケーションメタデータは、エレメントファイル内に格納され、ＵＳＡＴモジュールは、エレメントファイルからのメタデータをモバイル機器に与える。

【0020】

ＵＩＣＣアプリケーションメタデータが変更された場合、例えば、ＵＩＣＣアプリケーションが更新された場合、ＵＳＡＴモジュールは、エレメントファイルからアプリケーションメタデータを再度、読み出すように、モバイル機器を作動させることができる。このようにして、メタデータが変更された場合、モバイル機器を、新しいデータを反映するように更新することもできる。

【0021】

本発明はまた、対応する方法と、コンピュータで実行可能な命令製品も提供する。コンピュータで実行可能な命令はＣＤ−ＲＯＭなどの記録媒体に格納されてもよい。

【0022】

本発明のこれらおよび他の態様は、添付の図面を参照して記載された代表的な実施形態の以下の詳細な記載から明らかとなる。

【図面の簡単な説明】

【0023】

【図1】モバイル通信システムの主要な構成要素を示すブロック図である。

【図2】図１に示されたシステムの一部を構成するＭＥおよびＵＩＣＣの主要な構成要素を示すブロック図である。

【図3】ＵＩＣＣアプリケーションにアクセスするときの、ＭＥとＵＩＣＣとエンドユーザ間の通信を示す通信タイミング図である。

【図4a】ＵＩＣＣとＭＥの既存の構成を使用してＵＩＣＣアプリケーションにアクセスするために動的に生成される表示のシーケンスを示す図である。

【図4b】ユーザが図４ａのＵＩＣＣアプリケーションを選択するときのＭＥとＵＩＣＣ間の通信を示す通信タイミング図である。

【図5】ターミナルプロファイル構造の例を示す図である。

【発明を実施するための形態】

【0024】

概要
以下により詳細に説明するように、この実施形態の主要なアイデアは、ＭＥが、ＵＩＣＣアプリケーションに関連する一組の関連データを検索することを可能にする新しいプロトコルを定め、その結果、これら全てのＵＩＣＣアプリケーションが、ＭＥアプリケーション（通常、アイコンとして提示される）と同じ（少なくとも類似した）方法でエンドユーザに提示され／表示され、かつエンドユーザがアクセスできるようにすることである。提案されるプロトコルはまた、エンドユーザが、既存のＵＩＣＣサービスのメニューを入力することなく、対応するアイコンをクリック／選択することによって、ＵＩＣＣアプリケーションをダイレクトに起動することを可能にするであろう。

【0025】

図１は、モバイル通信システム１の主要な構成要素を示すブロック図である。図示のように、本システムは、セルラー電話のようなモバイル機器（ＭＥ）３と、通常、ＭＥ３内に搭載されているＵＩＣＣ５と、ＭＥ３へ信号を送信し、ＭＥ３から信号を受信する基地局７と、ＭＥ３にデータおよび音声電話サービスを提供するオペレータネットワーク９と、を含んでいる。図示のように、オペレータネットワーク９は、オペレータネットワーク９内のサーバ１３またはインターネット１５内のサーバ（不図示）にアクセスするために、ＭＥ３が接続するいくつかのアクセスポイント１１を含んでいる。

【0026】

図２は、この実施形態で使用されるＭＥ３およびＵＩＣＣ５の主要な構成要素を示すブロック図である。図示のように、ＭＥ３は、１つまたは複数のアンテナ２５を経て基地局７に信号を送信し、基地局７から信号を受信するように動作可能である送受信回路２３を含んでいる。図示のように、送受信回路２３は、通常の方法でラウドスピーカ２７とマイクロフォン２９に接続されており、ユーザが電話をかけ、またかかってきた電話を取ることができるようになっている。ＭＥ３はまた、ＭＥ３の動作を制御し、ユーザがディスプレイ３３およびキーパッド３５を介してＭＥ３と相互作用するのを制御するプロセッサ３１を含んでいる。プロセッサ３１は、メモリ３１内に格納されているソフトウェア命令にしたがって動作する。図示のように、これらのソフトウェア命令は、特に、オペレーティングシステム３９と、ＭＥ３とＵＩＣＣ５の間の相互作用を制御するＵＩＣＣモジュール４１と、いくつかのＭＥアプリケーション４３と、ＵＩ（ユーザインタフェース）モジュール４５と、を含んでいる。メモリ３７はまた、アプリケーションデータ４７も格納し、アプリケーションデータ４７は、利用可能なアプリケーションのアイコンを含み、該アプリケーションのアイコンがユーザによって選択された場合に該アプリケーションを開始できるようにリンク付けされている。ＭＥ３はまた、ＵＩＣＣ５に対して物理インタフェースを提供するＵＩＣＣインタフェース４９も含んでいる。この実施形態では、ＵＩＣＣモジュール４１はＭＥ３内の別個のソフトウェアモジュールである。当業者が理解するように、他の実施形態では、ＵＩＣＣモジュール４１はオペレーティングシステム３９の一部として設けられてもよい。

【0027】

図２に示されているように、ＵＩＣＣ５は、ＭＥ３に物理インタフェースを提供するＭＥインタフェース５１を含む。ＵＩＣＣ５はまた、メモリ５５内に格納されているソフトウェア命令にしたがって動作するプロセッサ５３も含む。図示のように、これらのソフトウェア命令は、オペレーティングシステム５６と、ＵＳＡＴモジュール５７（ユニバーサルＳＩＭ（加入者アイデンティティモジュール）アプリケーションキット）と、いくつかのアプリケーション５９と、を含んでいる。ＵＳＡＴモジュール５７は、ＵＩＣＣアプリケーション５９が、ＭＥ３またはオペレータネットワーク９（またはインターネット１５）内のリモートエンティティと相互作用して動作することを可能にするメカニズムであって、ＵＩＣＣアプリケーション５９に必要な特定のメカニズムをサポートするメカニズムを提供する。メモリ５５はまた、ＵＩＣＣアプリケーションメタデータ６１も含んでおり、ＵＩＣＣアプリケーションメタデータ６１は、ユーザが利用可能な全ての異なったＵＩＣＣアプリケーション５９を識別し、かつ、各ＵＩＣＣアプリケーション５９の実行に関連するデータを含んでいる。

【0028】

この実施形態におけるＭＥ３およびＵＩＣＣ５の動作方法を、図３を参照して次に説明する。最初に、電源が投入されまたはリセットされると、ＵＩＣＣモジュール４１は、ステップｓ１において、電源投入またはリセットの信号をＵＩＣＣ５に送る。ステップｓ３において、オペレーティングシステム５６は、この信号に対し、ＵＩＣＣ５がサポートするサービスを示すＡＴＲ（リセットに対する回答）応答で応答する。この実施形態では、ＡＴＲ応答は、本願で提案されている、ＵＩＣＣアプリケーション５９へのダイレクトアクセスを提供する新しいサービスを、ＵＩＣＣ５がサポートしていることを示すデータを含む。ステップｓ５において、ＵＩＣＣモジュール４１は、ＡＴＲメッセージに対し、ＭＥ３がサポートしているサービスをＵＩＣＣ５に知らせる端末プロファイルコマンドで応答する。この実施形態では、この端末プロファイルコマンドは、ＭＥ３がＵＩＣＣアプリケーションサービスへの新しいダイレクトアクセスをサポート可能であることを示すデータを含む。ステップｓ７において、ＵＩＣＣモジュール４１は、ＵＩＣＣアプリケーション５９のメタデータ６１を含むエレメントファイル（この例では、ＥＦ ＵＩＣＣ ＡＰＰ）にアクセスするために、一連の選択コマンドとリード レコード ＡＰＤＵコマンドを送る。これらのコマンドの受信に応答して、オペレーティングシステム５６は、ステップｓ９において、ＥＦ ＵＩＣＣ Ａｐｐに保持されているメタデータ６１をＵＩＣＣモジュール４１に送る。ＵＩＣＣモジュール４１は、ユーザがユーザインタフェースを介してアプリケーションにアクセスしようとしたときに、メタデータ６１を、その後の使用のためにアプリケーションデータ４７と共に格納する。ＭＥ３が一旦全てのメタデータ６１を有すると、ＵＩモジュール４５は、ステップｓ１１において、メタデータ６１を使用して、ユーザのＵＩＣＣアプリケーション５９へのダイレクトアクセスを可能にするユーザインタフェースを構築することができる。ＵＩモジュール４５は、通常、ユーザが、利用可能なアプリケーションを要求する所定の入力（例えば、キーパッド３５上のメニューキーを押す）を入力したときにユーザインタフェースを生成するが、ユーザインタフェースは予め生成されてメモリ３７に格納されていてもよい。ステップｓ１３において、ＵＩモジュール４５は、生成されたユーザインタフェースを（ディスプレイ３３によって）ユーザに提示し、これによってユーザは、表示されたユーザインタフェースからＵＩＣＣアプリケーション５９を閲覧し、選択することができる。好適な実施形態では、ＵＩモジュール４５は、（ＭＥ３上に格納されているアプリケーションデータ４７から求められた）ＭＥアプリケーション４３と、ＵＩＣＣアプリケーション５９と、の両方に対するアイコンを含むユーザインタフェースを構築する。このようにして、アプリケーションがＭＥアプリケーション４３であるかＵＩＣＣアプリケーション５９であるかを、ユーザにトランスペアレントなものにすることができる。

【0029】

ユーザが、ステップｓ１５において、ＵＩＣＣアプリケーション５９を実行することを選択すると、ＵＩＣＣモジュール４１は、ステップｓ１７において、所望のアプリケーションを起動するのに必要な全ての条件が満たされたかどうかをチェックする（ＵＩＣＣモジュール４１がステップｓ９で得た、選択されたＵＩＣＣアプリケーションに関連するメタデータ６１から決定する）。これらの条件が満たされていない場合、ＵＩＣＣモジュール４１は、ユーザを認証するログイン／パスワードを出力するようにユーザに要求するか、または、適切なネットワークサービスの利用可能性をチェックすることなどの、適切な動作を行う。アプリケーションを起動するのに必要な条件が一旦満たされると、ＵＩＣＣモジュール４１は、ステップｓ１９において、選択されたＵＩＣＣアプリケーション５９を起動するコマンドをＵＩＣＣ５に送る。この例では、選択されたＵＩＣＣアプリケーション５９はエニグマゲームである。起動コマンドの受信に応答して、オペレーティングシステム５６は、ＵＳＡＴモジュール５７を呼び出し、該コマンドを解釈し、一旦解釈されると、ステップｓ２１において、選択されたアプリケーション５９を起動する。ＵＩＣＣ５とＭＥ３の間のその後のやり取りは、起動されたアプリケーションに依存し、以前と同じであり、したがってそれらのステップの記述は省略する。

【0030】

したがって、上記の記述からわかるように、ＵＩＣＣメニューのナビゲーションの遅くて面倒なタスクは、ＵＩＣＣインタフェース４９を通じて通信する必要なしに、より高速なＭＥプロセッサ３１によって行われる。ＵＩＣＣ５からＵＩＣＣアプリケーションメタデータ６１を読み出すために、起動時またはリセット時に追加の時間が必要になるが、これが終了した後は、ＵＩＣＣアプリケーション５９へアクセスするためのその後の処理は、ＭＥの既存のメニューベースの、ＭＥアプリケーション４３にアクセスするシステムによって制御される。

【0031】

実施例
Ａ）ＵＩＣＣアプリケーションメタデータ６１の定義
メタデータはアプリケーションを特徴付けるデータである。

【0032】

この実施形態では、次のメタデータが各ＵＩＣＣアプリケーション５９について格納されている。

【0033】

−名称：（ＴＳ １２３ ０３８に定められたＳＭＳデータ符号化方式について符号化されたテキスト文字列）
−識別子（２バイト）：０ｘ０００１から０ｘＦＦＦＦ
−カテゴリ（１バイトの文字）：例えば、「ゲーム」、「モバイル・ペイメント」、「ユーティリティ」など。

【0034】

−アイコン（１バイトの文字）：このバイトは、エレメントファイル内のレコードである、アイコン画像を含む「ＩＭＧ」を示している。アイコンを示す他の方法は、アイコン用のＵＲＬを定めることである。この場合、テキスト文字列は１バイトの文字の代わりに与えられるであろう。

【0035】

−ネットワークサービス（１バイトの文字）：例えば、ネットワークサービスは必要ない、回路交換サービスは必要、ＧＰＲＳは必要、ＥＤＧＥサービスは必要、ＰＤＮサービスは必要など。

【0036】

−ペアレンタル・コントロール（１バイトの文字）：アプリケーションが制限ありまたは制限なしに利用可能かどうかを示す。

【0037】

−ログイン／パスワード（１バイトの文字）：ログイン／パスワードがアプリケーションにアクセスするのに必要かどうかを示す。

【0038】

上記のメタデータのリストは無論、メタデータを全て網羅したものではなく、他のメタデータを含む可能性がある。

【0039】

Ｂ）（ＥＴＳＩ ＴＳ １０２ ２２１に追加される）新しいエレメンタリファイルの定義：ＥＦ ＵＩＣＣ ａｐｐ
注記：以下に記載するＥＦ ＵＩＣＣ Ａｐｐの構造はほんの一例として示すものである。例えば、他のメタデータ６１を収容するために、または上記したメタデータ６１のために異なった大きさの割り当てが準備されているならば、他の構造も勿論可能であろう。

【0040】

この新しいＥＦは、マスターファイル（ＭＦ）の下に位置し、次の構造を有する。

【0041】

【表1】

【0042】

これは「線形固定」の種類のＥＦである。ＥＦはいくつかのレコードで構成され、各レコードは１つのＵＩＣＣアプリケーション５９のメタデータ６１を含んでいる。

【0043】

内容および符号化：
−名称（ＥＴＳＩ ＴＳ １２３ ０３８に定められたＳＭＳデータ符号化方式について符号化されたテキスト文字列）
−識別子：ＵＩＣＣによって割り当てられた固有の識別子
符号化：
有効な値は０ｘ０００１と０ｘＦＦＦＦの間に定められている。

【0044】

０ｘ００００は将来の使用のために未使用となっている。

【0045】

−カテゴリ：アプリケーションのカテゴリを示す。

【0046】

符号化：
「０１」：ゲーム
「０２」：モバイル・ペイメント
「０３」：ユーティリティ
「０４」：その他
注記：本リストはここでは一例として示されている。他のカテゴリも定めることできるであろう。

【0047】

−アイコン：ＥＦ ＩＭＧ内のレコード番号を示している。

【0048】

注記：もし「アイコン」の欄に含まれる値が有意（すなわち、値がないか０）であれば、ＭＥ３は、ＵＩＣＣアプリケーション５９のために、（ＭＥによって定められた）デフォルトのアイコンを割り当てる可能性がある。

【0049】

−ネットワークサービス：ネットワークサービスが必要か否かを示す。

【0050】

符号化：
「０１」：ＣＳ
「０２」：ＧＰＲＳ
「０３」：ＥＤＧＥ
「０４」：ＰＤＮ（ＬＴＥ）
注記：本リストはここでは一例として示されている。他の値も定めることできるであろう。

【0051】

−ペアレンタル・コントロール：ペアレンタル・コントロールがセットされていた場合に、アプリケーションにアクセス可能であるか否かを示す。

【0052】

符号化
「００」：アプリケーションが制限なしに利用できる
「０１」：ペアレンタル・コントロールがセットされている場合に、アプリケーションを、利用できない／隠す必要がある
他の値は、将来の使用のために未使用となっている。

【0053】

−ログイン／パスワード：アプリケーションを実行するのに認証が必要か否かを示す。

【0054】

符号化
「００」：ログイン／パスワードが必要でない
「０１」：ログイン／パスワードが必要
他の値は、将来の使用のために未使用となっている。

【0055】

Ｃ）ＵＩＣＣ５とＭＥ３の両方による新しいプロトコルのサポート
１）端末プロファイルコマンドは、ＭＥがサポートするサービスをＵＩＣＣに知らせるためにＭＥによって使用される。この新しいサービスのサポートを宣言するために、新しいビットを端末プロファイルコマンドのデータ構造に割り当てることが提案される。

【0056】

一例として、図５に示すように、（ＴＳ １０２ ２２３に定められている）端末プロファイル構造の３１番目のバイト内のビット１は、この特徴のサポートを示すために使用することができる（１にセットされたｂ１は、この特徴がサポートされていることを意味する）。

【0057】

２）この新しいサービスがＵＩＣＣ５によってサポートされている場合、ＵＩＣＣ５は、そのことをＡＴＲ（リセットに対する回答）バイトの中で宣言しなければならない。

【0058】

（ＴＳ １０２ ２２１に定められている）ＡＴＲ内のＴ＝１５の後の最初のグローバルインタフェースバイトは、このために使用することができる。例えば、このグローバルインタフェースバイトの既存の符号化を、新しいサービスのサポートの導入のために拡張することができる。

【0059】

（次の表２（ＥＴＳＩ ＴＳ １０２ ２２１内の表６．７）はＥＴＳＩ ＴＳ １０２ ２２１から抽出され、新しい入力をして更新されている）
表２：ＡＴＲのＴ＝１５の後の最初のＴＢi（ｉ＞２）の符号化

【0060】

【表2】

【0061】

この実施形態では、ＭＥ３内のＵＩＣＣモジュール４１は、ＵＩＣＣアプリケーション５９へのアクセスを制御する。これを行うために、ＵＩＣＣモジュール４１は、次の役割を担っている。

【0062】

●ＥＦ ＵＩＣＣ Ａｐｐから読み出されたメタデータ６１を全て格納する
●ＵＩＣＣアプリケーション５９を起動する（メタデータによって定められた）必要な条件が、このアプリケーションの実行要求をＵＩＣＣ５に実際に送る前に全て満たされたことをチェックする
特に、ＥＦ ＵＩＣＣ Ａｐｐ内の上記した複数のパラメータについて、ＵＩＣＣモジュール４１は、（関連するＵＩＣＣアプリケーションについて）次の動作の役割を担っている。

【0063】

○必要なネットワークサービスが利用可能であることをチェックする
○ペアレンタル・コントロールの状態をチェックする
○ユーザにログイン／パスワードを入力するように要求する
注記：これらの格納とチェックの特徴を達成するいくつかのソフトウェアモジュールがＭＥ３内に存在してもよい。特定の構成が実現例に特有である。

【0064】

Ｄ）（ＥＴＳＩ ＴＳ １０２ ２２３に追加される）新しいエンベロープコマンドの定義
この新しいエンベロープコマンドは、ＵＩＣＣアプリケーション５９を実際に起動するために、ＭＥ３からＵＩＣＣ５に送られる。

【0065】

（ＵＩＣＣアプリケーションを起動する）エンベロープの構造
−方向：端末（ＭＥ）からＵＩＣＣへ
コマンドのヘッダは、３ＧプラットフォームのためのＥＴＳＩ ＴＳ １０２ ２２３と、２ＧプラットフォームのためのＥＴＳＩ ＴＳ １５１ ０１１と、に明記されている。

【0066】

−コマンドパラメータ／データ

【0067】

【表3】

【0068】

−装置アイデンティティー：ＴＳ １０２ ２２３に定められている符号化
−ＵＩＣＣアプリケーションＩＤ（ＴＳ １０２ ２２３に追加される新しいＴＬＶデータオブジェクト）
４．１ ８．ｖｖＵＩＣＣアプリケーションＩＤ

【0069】

【表4】

【0070】

−識別子：
−０ｘ０００１から０ｘＦＦＦＦ（１から６５５３６）の間に定められた値 −０は将来の使用のための未使用
−ＵＩＣＣアプリケーションログイン／パスワード：これらのパラメータは、それらがＵＩＣＣアプリケーション５９によって要求された場合にのみ存在する。

【0071】

Ｅ）ＯＴＡによるＵＩＣＣアプリケーションの更新
ＵＩＣＣ５内に位置するアプリケーション５９は、Ｏｖｅｒ Ｔｈｅ Ａｉｒ（ＯＴＡ）更新メカニズムを経て、オペレータ／スマートカードベンダーによってリモートで更新することができる。ＥＦ ＵＩＣＣ Ａｐｐ内のメタデータ６１が（例えば、ユーザに表示される新しいアイコンに対して）変わった場合には、ＵＩＣＣ５は、ＭＥ３が更新されたメタデータ６１を検索できるように、Ｒｅｆｒｅｓｈプロアクティブコマンドを使用して、ＭＥ３にメタデータ６１を再度読み出すように要求する。

【0072】

修正および代替
詳細な実施形態を上記で記載した。当業者が理解するように、幾つかの修正および代替を、ここに具体化された発明から、なお利益を得ながら上記の実施形態を行うことができる。

【0073】

上記の実施形態では、ＵＩＣＣアプリケーションメタデータは、電源投入またはリセット処理の間にＵＩＣＣから読み出されていた。他の実施形態では、ＵＩＣＣアプリケーションメタデータは、異なった時間に読み出され（または読出しを開始され）てもよいが、ユーザが、起動するアプリケーションを選択するユーザインタフェースを使用し始める（または、使用することができる）前であってもよい。

【0074】

上記の実施形態では、携帯電話をベースとした通信システムについて記載した。当業者が理解するように、本願で記載した技術は他の通信システムでも使用することができる。他の通信ノードまたは通信装置は、例えば、パーソナルディジタルアシスタント、携帯電話、ラップトップコンピュータなどのユーザ装置を含んでいてもよい。

【0075】

上記の実施形態では、いくつかのソフトウェアモジュールについて記載した。当業者が理解するように、これらソフトウェアモジュールはコンパイルされたまたはコンパイルされていない形式で提供されてよく、そしてコンピュータネットワークを通じてまたは記録媒体に記録して信号としてＵＩＣＣまたはＭＥへ供給されてもよい。さらに、このソフトウェアの一部または全てによって行われる機能は、１つまたは複数の専用のハードウェアモジュールを使用してなされてもよい。しかしながら、ソフトウェアモジュールの使用は、ソフトウェアの機能を更新するために、ＵＩＣＣ５とＭＥ３の更新を容易にするので好ましい。同様に、上記した様々なソフトウェアモジュールによって果たされる機能は、任意の数の別個のソフトウェアモジュールによってなされてもよく、または、オペレーティングシステムのような、単一のソフトウェアモジュールによってなされてもよい。

【0076】

上記の実施形態では、ＵＩＣＣは、各装置上のインタフェースによってＭＥと接続していた。当業者が理解するように、これらのインタフェースは物理的（接触）タイプのインタフェースであってよく、または無線（非接触）タイプのインタフェースであってもよい。

【0077】

他の様々な変形が当業者に明らかであり、ここではさらに詳しくは説明しない。

【0078】

この出願は、２０１０年３月２５日に出願された英国特許出願第１００５０３４．２号に基づき、その優先権の利益を請求する。

【符号の説明】

【0079】

１ モバイル通信システム
３ ＭＥ
５ ＵＩＣＣ
７ 基地局
９ オペレータネットワーク
１１ アクセスポイント
１３ サーバ
１５ インターネット
２３ 送受信回路
２５ アンテナ
２７ スピーカー
２９ マイクロフォン
３１、５３ プロセッサ
３３ ディスプレイ
３５ キーパッド
３７、５５ メモリ
３９、５６ オペレーティングシステム
４１ ＵＩＣＣモジュール
４３ ＭＥアプリケーション
４５ ＵＩモジュール
４７ アプリケーションデータ
４９ ＵＩＣＣインタフェース
５１ ＭＥインタフェース
５７ ＵＳＡＴモジュール
５９ ＵＩＣＣアプリケーション
６１ ＵＩＣＣアプリケーションメタデータ

【図1】

【図2】

【図3】

【図4a】

【図4b】

【図5】