JP2009521155A - 電気通信システムにおける情報流通 - Google Patents

Abstract

通信システムにおける情報流通のための解決策。サービスビューが、一つ以上のページを備え、一つのページが、ページ定義データがページの出力におけるコンテンツデータのフォーマットを制御するように、コンテンツデータおよびページ定義データの組合せを備えた別々の出力項目である。サーバーは、サービスビューの一つ以上のページのコンテンツデータを集めて、コンテンツデータをサービスパッケージにパッケージ化する。ページ定義データは、ユーザ端末内に記憶されて、サービスパッケージ内のコンテンツデータと組み合わせられる。サービスビューの全てのページは、その後にユーザ端末で閲覧されることができる。
【選択図】図３

Description

本発明は、電気通信システムに、および、特にそれぞれの独立請求項の前文に従う方法、通信システム、サーバー、ユーザ端末およびコンピュータプログラム製品に関する。

電気通信は、概ね電磁信号による情報の交換を指す。電気通信システムの要素は、メッセージを電磁信号に符号化する送信器、電磁信号をメッセージへと戻して変換する復号化機構を備える受信器、および送信器と受信器との間で電磁信号を運ぶ媒体を備える。

電気通信システムにおける情報流通は、一般的に、かなりの作成後処理を情報に加えることをあてにされているのではなく、基本的にそれを局所的に消費すると予想される、ユーザ、または、複数のユーザに、音声、ビデオまたはその他のタイプの情報を伝達するための媒体の使用に関する。

電気通信システムは、例えば端点間の容認された遅延および相互作用のレベルに依存して、電気通信システムに情報を流通させるために複数の種々の方法を提供する。ストリーミングサービスは、基本的に同時伝送、および、全てのデータがさらに受信器に送信される前にさえ使用を開始することができるデータの使用に関する。ユーザは、情報が常に最新で直ちに利用できるので、一般的にストリーミングサービスを評価する。他方、ストリーミングサービスの導入は媒体をひどく占有し、および例えば、移動システムでは、エアーインタフェースのリソースの無線送信が制限され、他の形の流通が一般的に好まれる。

そのような形の一つは、一つ以上の中央で動作させられたコンピュータ内に情報を保持して、電気通信システムのユーザに対してこの情報をネットワーク経由でアクセス可能にすることである。この種のネットワークサービスを記述して、それらのサービスのユーザプロセスをモデル化する広範囲にわたって受け入れられて活用される手段は、クライアント−サーバーアーキテクチャである。サービスの一部として流通される情報はサーバー、基本的に、電気通信網を使用してそれにアクセスすることができる他のコンピュータの役に立つコンピュータ内に保持される。クライアントはコンピューターシステムまたはコンピューターシステム内のプロセスであり、それはサーバーにアクセスすることができ、サーバーに規定された作業を行うことを要求することができる。プルサービスは、ユーザがブラウザを使用してリクエストを行って、検索の結果を直接取得するように、ユーザ端末がブラウザを備える実装に関する。プッシュサービスは、サービスユーザの端末装置が単一の送信に対して別々のリクエストなしで情報を送信される実装に関する。

情報流通のための最も周知の従来技術解決策は、ウェブサイトを備える。ウェブサイトは、インターネット上のワールドワイドウェブ上の特定のドメイン名またはサブドメインに一般的に共通している一まとまりのウェブページを指す。ウェブサイトのページは、共通ルートＵＲＬからアクセス可能で、一般的に同じ物理的サーバー上に存在する。ウェブページは、ハイパーテキストマークアップ言語（ＨＴＭＬ）ファイルに基づく別々にアクセス可能な情報実体に対応して、ユーザのウェブブラウザによって再現されることができる。ウェブページは、単一のページ、または各フレームがＨＴＭＬページを含む別々のフレームから構成されるフレームセットのどちらかであることができる。

ユーザ端末では１つのウェブページが、ウエブブラウザウインドウ内に一度に示される。ユーザ端末内のウェブページのサイズとウエブブラウザウインドウとの間に直接の相関関係はない。実際のところ、ウェブページはブラウザウインドウよりしばしば高く、したがって、ユーザ端末の中で垂直スクロールを必要とする。いくつかの場合に、ページはまたその右側に追加的なコンテンツを有し、それは水平スクロールを必要とする。この種のページはしかしながらあまり一般的でない。なぜなら、大部分のユーザは２つの方向に同時スクロールを必要とする読取りは非常に不便であると思うからである。１つのページからもう一方に移動すると、新しいＨＴＭＬファイルが、サーバーまたはユーザ端末内のバッファーメモリからダウンロードされる必要がある。

移動通信では、サーバーとユーザ端末との間のアクセスは一般的にエアーインタフェースを介した送信を備え、それは、ウェブページファイルをダウンロードするのに利用できる帯域幅への制限を課す。機器が便利に持ち運ばれることができるように、移動ユーザ端末はまたサイズのコンパクトなことを必要とする。携帯機器上の使用のために特に設計されるウェブブラウザは、通常マイクロブラウザと呼ばれている。マイクロブラウザは、携帯機器上の小型スクリーンに対して最も効果的にインターネットコンテンツを表示し、かつ無線携帯機器の低記憶容量および狭帯域幅に対応するために小さなファイルサイズを有するように最適化されている。基本的に、マイクロブラウザは余分な装備のないウェブブラウザであって、それでも上で開示された類似した情報検索機構に従う。

これらの従来技術解決策に伴う問題は、一つ以上のページが一様なコンテンツ実体を作り出すサービスに関する。従来技術解決策においてコンテンツを形成する部分のリンク付けは、ハイパーリンクと呼ばれている他の文書に対する自動化された相互参照によって実行される。ハイパーリンクを選択すると、コンピュータに短い期間内でリンクされた文書を示させる。しかしながら、ネットワーク接続の品質が低い、または、限られた帯域幅だけが利用できる場合、次のページをダウンロードするために必要な期間はより長くなる。その上、サービスのユーザ経験は反復ダウンロード手順中に可能な限りの全ての起こりうる否定的出来事に影響されやすくなる。この種の特徴は、サービスの使用にフラストレーションを引き起こさせ、ユーザにサービスを活用することを思いとどまらせる傾向がある。

この種の使用場合の実際的な例は、モバイルニュースの発行である。いくつかのコンテンツプロバイダ、例えば通信社および放送会社が、インターネットニュースサービスを提供する。これは、頻繁に変化する情報を有するウェブページを備える動的なウェブサイトとして導入される。この種のウェブサイトはしばしば、携帯機器内へのダウンロードのために最適化されているさまざまなモバイルページによって補足される。ウェブサーバが所定のページに対するリクエストを受信すると、ページリクエストに直接応答して対応するページがサーバーの中で生成されて、要求元ユーザ端末に配信される。サービスは、一般的にユーザ端末内にこのサービスのホームページを読み出すことによって開始される。ホームページは、１つのページから別のものまでナビゲーションを可能にするハイパーテキストリンクを備える。

遅い接続、すなわち狭帯域幅モデムまたは無線アクセスネットワークを介して操作する場合、ダウンロードする次のページのために必要な時間は、一般的に不便に長くなり、および、ユーザは他のサイトおよびサービスへ移動する。エアーインタフェースの脆い性質のために、いくつかのダウンロード事例に関する問題は、モバイルニュースの流通において、より貧弱な有効到達エリアにおける断続的な接続、繰り返される再ローディングおよび長引くダウンロード時間に関して、きわめて具体的に経験される。

本発明の目的は、したがって、電気通信システムの情報流通における上記の問題を解決するための解決策を提供することである。本発明の目的は、独立請求項内に述べられることによって特徴づけられる方法および処理によって達成される。本発明の好ましい実施態様は、従属請求項内に開示される。

本発明は、サービスの一様なコンテンツ実体を作り出す一つ以上のページに対する定義を含む少なくとも一つのサービスビューを作り出す考えに基づく。一つ以上のページのコンテンツデータが集められて、ダウンロード可能なサービスパッケージにパックされる。このサービスパッケージは、好ましくは任意のタイプのアクセスネットワーク経由で、ユーザ端末にアクセス可能にされる。ページは、ここで少なくともコンテンツデータとページの出力におけるコンテンツデータのフォーマットを制御する定義データとの組合せとして形成される別々の出力項目を代表する。視覚出力において、ページはブラウザウインドウ内に別々に表示される実体に対応する。サービスビューの定義データは主としてユーザ端末内に記憶され、および、ユーザ端末がダウンロードされたページのコンテンツデータを受信すると、サービスの一様なコンテンツ実体が表示ウィンドウの典型的なスクロール動作によって何不自由なく閲覧可能になるように、コンテンツデータおよび定義データが結合される。

本発明に従う解決策の利点は、全ての必要な情報がユーザ端末内に直ちに利用できるようになる１つのリクエスト手順によって、ユーザが一様な実体にアクセスすることができることである。大部分の場合において真のペイロードだけがサーバーとユーザ端末との間を転送される必要があるので、狭帯域幅接続を介してさえ、かなり大きいコンテンツ実体がすばやく転送されることができる。パッキング段階が情報の任意の部分の即時のアップデートを可能にするので、流通した情報の動的な性質はしかしながら決して損なわれない。

本発明は、ユーザ端末が他のネットワーク要素内に保持される情報にアクセスするためにネットワークまたは相互に連結したネットワークの組合せを活用することができる任意の通信システムに適用されることができる。例えば、この種の電気通信システムは、ＧＳＭ１８００のような汎欧州ディジタル移動電話方式（ＧＳＭ）およびＰＣＳ（パーソナル移動通信システム）、およびそれに基づく任意のシステム、例えばＧＳＭ ２＋システム、に対応するユニバ−サル移動体通信システム（ＵＭＴＳ）システムのような移動通信システムを備える。ＧＳＭ ２＋フェーズのサービスはとりわけ、汎用パケット無線サービス（ＧＰＲＳ）、ＧＳＭ拡張版向け高速データレート（ＥＤＧＥ）および移動ネットワーク拡張ロジック用カスタマイズアプリケーション（ＣＡＭＥＬ）を備える。本発明は、さらに上記の要求条件を満たすことが可能な任意の固定通信システムに適用可能である。

本発明に従う解決策は、一例として移動通信システムを使用して例示される。移動通信システムは、一般にユーザがシステムのサービスエリアの範囲内で移動している場合、システムに対するアクセス点（一般的に無線アクセス）が変化することができる任意の電気通信システムを指す。この文脈におけるアクセスは、ユーザ機器とアクセス点との間の通信のためにユーザ機器をアクセス点に接続する機構と解釈される。アクセス点は例えば、ネットワークノードまたは他のユーザ機器であることができる。しかしながら、留意する必要があるのは、保護の範囲が、移動ネットワーク、固定ネットワークおよび各々の組合せを備えたシステムをカバーすることである。

典型的な移動通信システムは、公衆地上移動ネットワーク（ＰＬＭＮ）である。移動通信網は、しばしば外部ネットワーク、ホストまたは特定のサービスプロバイダによって提供されるサービスに対する無線アクセスをユーザに提供するアクセス網である。

移動通信システムは絶え間なく発達しており、および、主要な目的の１つは既存の、そしてまた、将来のサービスを導入することが可能な汎用インフラストラクチャを準備することである。以下において、本発明の実施態様は第三世代（３Ｇ）移動通信システムを用いて記載されているが、この解決策はさまざまなシステムに適用可能であり、および、保護の範囲はこの実施態様に固有な表現および概念によって限定されて解釈されてはならない。

図１のブロックチャートは、通信システムの論理アーキテクチャを例示する。このシステムの第１のレッグは、無線アクセス網（ＲＡＮ）として働く汎用パケット無線サービス（ＧＰＲＳ）システム、ＧＳＭシステム（汎欧州ディジタル移動電話方式）経由でコアネットワーク（ＣＮ）１０５に接続される移動局（ＭＳ）１００の動作モードを例示する。一般に、ＧＳＭネットワークの基本構造は２つの部分：基地局システム（ＢＳＳ）１１０およびネットワークサブシステム（ＮＳＳ）を備える。ＧＳＭ ＢＳＳは、無線インターフェースＵｍ１１５を介して無線接続経由で移動局（ＭＳ）１００と通信する。基地局システムＢＳＳ１１０において、各セルは基地トランシーバ局（ＢＴＳ）１２０によって取り扱われる。基地局１２０は基地局コントローラ（ＢＳＣ）１２５に接続され、それは基地局によって使用される無線周波数およびチャンネルを制御する。基地局コントローラＢＳＣ１２５は、Ａ−インターフェース１３０を介して移動スイッチングセンタ（ＭＳＣ）１３５に、すなわちＧＳＭ ＮＳＳの一部としてシステムのコアネットワークＮＣ１０５に接続される。

担当ＧＰＲＳ支持ノード（ＳＧＳＮ）１４０は、個々の移動局の場所の情報を得続けて、セキュリティ機能およびアクセス制御を行う。ＳＧＳＮ１４０は、Ｇｂインターフェース１４５を通してＧＳＭ基地局システムに接続される。ゲートウェイＧＰＲＳ支持ノード（ＧＧＳＮ）１５０は、パケットデータネットワークとのインタワーキングを提供し、かつＩＰベースのパケットドメインＰＬＭＮバックボーンネットワーク経由でＳＧＳＮに接続される。

ＧＰＲＳサービスを使用するために、ＭＳはＧＰＲＳ接続を行うことによってネットワークにその存在を最初に知らしめる。これはＭＳを、ＧＰＲＳを介したＳＭＳ、ＳＧＳＮを経たページングおよび入力パケットデータの通知に利用できるようにする。ＧＰＲＳサービスを用いてパケットデータを送受信するために、ＭＳはそれが使用したいパケットデータプロトコルコンテクストを起動させる。この動作は、ＭＳを対応するＧＧＳＮに知られるようにし、およびデータネットワークとのインタワーキングが始まることができる。

留意する必要があるのは、本発明を理解するのに重要な要素およびユニットだけが、図１内に例示されていることである。当業者にとって、通信システムが一般的に図１内に示されない複数の要素を備えることは明白である。

本実施態様の第１のアクセスタイプは、ＩＰマルチメディアサブシステムＩＭＳに対するアクセスを用いて記載されている。ＩＰマルチメディアサブシステムは、マルチメディアサービスの具備のためのＣＮ要素を備える。ＩＰマルチメディアサブシステムＩＭＳ１３３は、マルチメディア信号およびベアラトラフィックを搬送するためにＰＳドメインを活用する。ＩＰマルチメディアコアネットワークサブシステム（ＩＭ ＣＮサブシステム）は、音声、ビデオ、テキスト、チャット、その他およびＰＳドメインを介して配信されるそれらの組合せの類のＩＰマルチメディアサービスの具備のためにコアネットワーク要素を備える。ＩＰ ＣＮサブシステムセッションのセッションフロー手順は呼出しセッション制御機能（ＣＳＣＦ）によって制御され、それは異なるいくつかの役割に分けられる。プロキシ−ＣＳＣＦ（Ｐ−ＣＳＣＦ）は、ＩＰ ＣＮサブシステム内の実質的に第１の接触点である。Ｐ−ＣＳＣＦは、プロキシのようにふるまい、したがって、リクエストを受け入れ、および内部的にそれらにサービスするかまたはそれらを転送する。問合せ−ＣＳＣＦ（Ｉ−ＣＳＣＦ）は、そのネットワークオペレータのユーザに予定される全ての接続に対するオペレータのネットワーク内の接触点である。担当ＣＳＣＦ（Ｓ−ＣＳＣＦ）は、ユーザ機器に対するセッション制御サービスを行う。それは、サービスのサポートのためにネットワークオペレータによって必要に応じてセッション状態を維持する。Ｓ−ＣＳＣＦは、通常ユーザ端末がＳ−ＣＳＣＦに登録すると、要求購読データがダウンロードされる加入者データベースを含む。ＩＭＳセッションを導入することにおけるこれらのＩＭＳ呼出しセッション制御機能の役割および動作は、公衆遠距離通信規格内に記載されていて当業者にそのようなものとしてよく知られている。

ユーザ機器ＵＥは音声だけの簡略端末であることができ、または、サービスプラットホームとして働いて、かつローディングおよびこのサービスに関連したさまざまな機能の実行をサポートする多様なサービスのための端末であることができる。ユーザ機器ＵＥは実際の移動形機器ＭＥおよび、加入者認証モジュールとも呼ばれている、着脱可能に接続されたＩＤカードＵＳＩＭを備える。この文脈において、ユーザ機器ＵＥは一般に加入者認証モジュールおよび実際の移動形機器によって形成される実体を指す。加入者認証モジュールＵＳＩＭは、加入者認証を実質的に保持して、認証アルゴリズムを行って、移動局において必要である認証および暗号化キーならびに他のサブスクリプト情報を記憶するスマートカードである。移動形機器ＭＥは、移動通信システムの中で通信することが可能な任意の機器、または機器のいくつかの部分の組合せ、たとえばカード電話が移動接続を提供するためにそれに接続されたマルチメディアコンピュータ、であることができる。

本発明の解決策は、通信システムにおける情報流通を向上させる。情報流通は、モバイルニュースサービスを用いて実施される以下にあるが、当業者にとって明白であるのは、本発明が、非移動および移動ユーザが利用できる情報流通サービスの他のいくつかのタイプと関連づけることができることである。例えば、この種のサービスは通信システムの基本または追加サービス、通信システムを通してアクセス可能なサービスまたは最終的には通信システムから独立している通信サービスを備える。

第１の実施態様において、コンテンツの一定のサービスビューの形式の複数のページを備えたニュースサービスが、開示される。図２のブロックチャートは、本実施態様を実行するための論理要素を例示する。明確にするため、本発明を理解することにとって重要である要素だけが示されている。当業者にとって、異なるシステムにおいて、論理要素は、異なる物理的な要素に分けられるかまたは結合されることができることもまた明白である。

図１内に示される要素に基づいて、図２は基地局サブシステム（ＢＳＳ）２２、パケット交換コアネットワーク（ＰＳ−ＣＮ）２３、ＩＰマルチメディアサブシステム（ＩＭＳ−ＣＮ）２４およびＩＰネットワーク２５を通しての接続、好ましくはアプリケーションサーバー（ＡＳ）２６とユーザ機器（ＵＥ）２１との間のパケット交換接続を提供する構成を示す。本実施態様において、アプリケーションサーバーＡＳ２６はユーザ機器ＵＥ２１に対する一次接触点を代表する発行サーバーである。アプリケーションサーバーＡＳ２６は、この例におけるニュースサービスの実際のプロバイダを代表する第１のコンテンツソースＣＳ１ ２７およびニュースサービスを実施する際に活用される任意の外部コンテンツソースを代表する第２のコンテンツソースＣＳ３ ２８にＩＰネットワーク２５経由で接続される。当業者にとって明白であるのは、ＩＰネットワーク２５は本願明細書において種々の異なるタイプのネットワーク構成を代表し、およびこの解決策は、アプリケーションサーバーＡＳに対するアクセスが配置されることができる多様固定ユーザ機器２９に対応して適用可能なことである。

サービスの確立の際に、サービスのオペレータ、ここで第１のコンテンツソースＣＳ１がサービスビューを作り出す。図３は、本実施態様に伴うサービスビューの一例を例示する。サービスビュー３０は、サービスの援助でユーザが利用できるようにされることになる複数のページＰ１ないしＰ６によって形成されるコンテンツ実体に対応する。従来技術解決策において、この種のページは可変様式であり、別々のファイルとして記憶されて、ネットワーク経由でユーザにアクセス可能にされる。本発明において、しかしながら、サービスビューによって利用できるようにされるページはサービスの全てのページＰ１ないしＰ６によって共有される共通構造フォーマット部分を有する。したがって、サービスビュー３０はサービスのページの共通構造フォーマット部分を制御する要素ｆ１、ｆ２．．．を備える構造定義ＤＥＦ３１を確立する。この種の要素は、例えば、背景の色、コンテンツプロバイダの標準のロゴ、フォントのような、表示特性を制御することができる。サービスビュー３０はさらに、サービスのページ内に含まれるコンテンツ要素ＣＯＮＴ ｃ１１，ｃ１２、ｃ１３、ｃ２１、ｃ２２、ｃ２３、その他に対する定義を備えるコンテンツ定義ＣＯＮＴ３２を確立する。ページＰ３は、したがって、サービスビューの構造定義ＤＥＦ３１とコンテンツ要素ｃ３１、ｃ３２、ｃ３３を組み合わせることによって作り出されることができる別々の出力項目である。

サービスビューがサービスプロバイダによって適切に確立された場合、それはアプリケーションサーバーＡＳ２６へ転送される。その後に、ＡＳ２６がユーザ機器ＵＥ２１からサービスビューに関連したリクエストを受信すると、それは、第１のコンテンツソースＣＳ１からおよび／または任意の第２のコンテンツソースＣＳ２からサービスビューのコンテンツ要素ＣＯＮＴ（ｃ１１、ｃ１２、．．．、ｃ６３）を集めて取り出し、かつそれらをダウンロード可能なサービスパッケージにパッケージ化する編集手続きを開始する。このパッケージは、要求元ＵＥ２１にダウンロードされる。

サービスビューがサービスプロバイダによって適切に確立された場合、それは対応してサービスを購読することを決めるユーザ機器２１へ転送されることができる。構造定義ＤＥＦ３１がユーザ機器内にあり、および、新しいサービスパッケージがＡＳ２６からダウンロードされる場合、サービスの１つ以上のページがＵＥ２１内に出力されることができるように、サービスパッケージのコンテンツ要素が構造定義と組み合わせられることができる。ユーザは、１回のダウンロードでサービスの関連したページを受信して、次いでサービスを通して流通されるように設計されている全体のコンテンツをすばやくブラウズすることができる。図２の構成の要素内の本発明された解決策の実現が、更に詳細に下で開示される。

留意する必要があるのは、実施された実現においてたとえさまざまな要素の動作が別々に論じられるとしても、制御権または操作上の責任が本発明に関連しないことは明白なことである。対応して、たとえアクセスサーバーＡＳおよびコンテンツソースＣＳ１、ＣＳ２の各々が１つの別々の要素として示されるとしても、それらの物理的な実現は、本発明に関連しない。要素は１つの物理的な要素だけによって実現されることができ、または、考慮中の用途に従い、開示された機能はいくつかの物理的な要素に分配されることができる。

図４のフローチャートは、図３の接続において論じられる本発明の実施態様を考慮して、アプリケーションサーバーの機能の一例を例示する。ステップ４１において発行サーバーとして働くアプリケーションサーバーが、ニュースサービスのサービスビュー（ＳＶ）に関する情報を受信する。このサービスビューは、第１のコンテンツソースＣＳ１、ここで日刊の雑誌、のニュースページを流通させるニュースサービスを構成する。メッセージは、第１のコンテンツソースＣＳ１として働く日刊の雑誌のサーバーからネットワークを通して受信されることができる。当然、サービスビューはあるいは、アプリケーションサーバーのユーザインターフェースを通して設定されることができる。サービスビューは、サービスビュー内で利用できるようにされるページＰ１ないしＰ６の一群のコンテンツ要素に対する定義を備える。コンテンツ要素は、コンテンツ要素の識別およびコンテンツ要素のデータがアプリケーションサーバーに利用できるリソースファイルのアドレスとして有利に規定される。有利には、サービスビューはさらに、サービスのその後の機能を起動させる事象の定義を備える。サービスビューの受信は、新しいサービスを初期化して、アプリケーションサーバーの発明された動作を可能にする。

各サービスに対して、ＡＳ内にダウンロード可能なサービスパッケージの生成を起動させる少なくとも一つの、しかし一般的に一つを超える条件がある。新しいパッケージは、一次または二次コンテンツソースから受信される任意の新情報に応答して、または、ユーザ端末からのリクエストに応答して、例えばタイマーに従って所定の間隔で生成されることができる。いくつかの他のトリガーポイントが、本発明に対する保護の範囲から逸脱せずに活用されることができる。ステップ４２において、ＡＳはトリガー条件が満たされるかどうか調べる。そうでない場合には、ＡＳはスタンバイにあって、規定された間隔の後で再び条件を調べる。トリガー条件が満たされる場合、ＡＳはサービスビューを読み込んで（ステップ４４）、ダウンロード可能なサービスパッケージをコンパイルし始める。

コンパイルステップ４５は、サービスビュー内に参照されるリソースファイルの取り出しを含む。情報はアプリケーションサーバーにコンテンツソースによってすでに供給されることができ、および、取り出しは次いでアプリケーションサーバーの単なるメモリ操作によって実施されることができる。情報は、しかしながらまた、外部コンテンツソース内に保持されることができて、最初にアプリケーションサーバーと関連したコンテンツソースとの間のネットワーク接続を通してアプリケーションサーバーに取り出される必要がある。ネットワーク内の情報を参照するための有利な方法は、拡張可能なマークアップ言語（ＸＭＬ）、異なるシステム、特にインターネット経由で接続されるシステムを横断してデータの共有を容易にする汎用マークアップ言語、を使用することである。ＸＭＬは、キャラクタデータ、コンテナのような要素およびそれらの要素の属性の階層への分離を指示するマークアップによって散在するテキストとして現れる。ＸＭＬを用いた情報の共有は、当業者に一般に公知で、本願明細書において更に詳細に論じられない。

コンパイルステップは、さらにアプリケーションサーバーとユーザ端末との間の通信に関連したいくつかの追加的な属性の内包を備えることができる。この種の属性は、認証上の情報および／またはパッケージのタイミング、例えばサービスの主要な構造定義を補足するかまたはそれに優先するためのいくつかのフォーマットコマンドを備えることができる。

コンパイルの後、サービスパッケージのための例示的なデータは、次の通りでありえる：
＜ｃ１１＞
＜ｃ１２＞
＜ｃ１３＞
＜ｃ２１＞
＜ｃ２２＞
＜ｃ２３＞
＜ｃ３１＞
＜ｃ６１＞
＜ｃ６２＞
＜ｃ６３＞
＜エディション＞
＜オプション＞
ここで
＜Ｃｉｊ＞は、テキスト、画像、音声、スクリプト、などを含む様々な形のデータを備えることができるコンテンツ要素を指す。
＜エディション＞は、特定のパッケージ、例えば日付およびタイムスタンプに関する情報を備え、および、
＜オプション＞は、ディスプレイ内に示されるオプションキーの定義を備える。留意する必要があるのは、本発明を例示するために必要な要素だけが開示されていることである。当業者にとって、本当の実現において、パッケージがここで示されないかまたは論じられない複数の定義を備えることができることは明白である。

コンパイルステップの最後の段階は、圧縮である。圧縮において、データの既知の特性を活用することによって、一次情報が解凍によって回復されることができるというような方法で、データはコンパクトな形式に符号化される。圧縮は、ユーザ端末への伝送における帯域幅の使用を最小にするために導入される有利であるが強制的でない手順である。当業者に利用できるさまざまな代替圧縮方法、例えばＬＺＳＳ符号化、ＬＺＷ符号化、ハフマン符号化、算術符号化などが存在する。

コンパイルの後、サービスパッケージは、サービス加入者のユーザ端末に利用できるようにされ（ステップ４６）、情報を供給する手段は規定されたトリガー条件に依存している。例えば、サービスパッケージがユーザ端末からのリクエストに応答してコンパイルされる場合には、それは直接要求元ユーザ端末に送信されることができる。対応して、サービスパッケージがいくつかの他の一般的にネットワークベースの条件に応答してコンパイルされる場合には、アプリケーションサーバー内に以前に記憶されたパッケージは廃棄され、および、新しいコンパイルされたパッケージがＡＳ内のダウンロードに提供される。

アプリケーションサーバーの機能説明を含む図５を参照することによって、アプリケーションサーバー内の本発明の開示された実施態様の実現が例示される。ネットワークノードは処理手段５１、算術論理ユニット、複数の特殊レジスタおよび制御回路を備える要素、を備える。処理手段に接続されるのは、メモリ手段５２、コンピュータ可読のデータまたはプログラムまたはユーザデータが記憶されることができるデータ媒体、である。メモリ手段は、一般的に読出しおよび書込みの両方を可能にするメモリユニット（ＲＡＭ）、およびコンテンツが読み出されることができるだけのメモリ（ＲＯＭ）を備える。このユニットはさらに、ユニット内の内部処理のためのデータを入力するための入力手段５４およびデータをユニットの内部プロセスから出力するための出力手段５５を有するインターフェースブロック５３を備える。前記入力手段の具体例は、その外部接続ポイントに配信される情報に対するゲートウェイとして働くプラグインユニットを備える。アプリケーションサーバーのオペレータの情報を受信するために、アプリケーションサーバーＡＳはまた、キーパッドまたはタッチスクリーン、マイク、またはその他を備えることができる。前記出力手段の具体例は、その外部接続ポイントに接続されるラインに情報を供給するプラグインユニットを含む。アプリケーションサーバーＡＳのオペレータに情報を出力するために、それらはまた、スクリーン、タッチスクリーン、スピーカ、等を備えることができる。処理手段５１、メモリ手段５２およびインターフェースブロック５３は、ユニットの所定の、基本的にプログラムされたプロセスに従って受信されたおよび／または記憶されたデータの動作の系統的実行を行うために電気的に相互接続されている。本発明に従う解決策において、動作は上記の通りにアプリケーションサーバーの動作を実行するための機能を備える。

図６のフローチャートは、図３の接続において論じられる本発明の実施態様を考慮して、ユーザ機器の機能の一例を例示する。サービスの開始において、サービスの加入者のユーザ端末は端末アプリケーション、サービスの使用を容易にするサービスに特有のブラウザを備えている。ステップ６１において、ユーザ端末はニュースサービスのサービスビュー（ＳＶ）に関連したブラウザを受け取る。このブラウザは、図３および４と関連して論じられたニュースサービスを動作させるために端末機能を実現するように配置される。ブラウザは、ネットワークを通してメッセージ内に無線で配信されることができる。当然、サービスビューはあるいは、ユーザ端末のアプリケーションプログラミングインタフェース（ＡＰＩ）を通して設定されることができる。サービスビューに関連したブラウザは、サービスビューの構造定義に従って動作し、その定義によって、ユーザ端末は、サービスパッケージ内に受信されるコンテンツ要素を識別し、かつ例えばユーザ端末のディスプレイ内に、適切にそれらを出力することが可能である。サービスビューは、さらに全体のサービスの実施を制御する他の定義を備えることができる。

ステップ６２において、ユーザ端末は新しいサービスパケットが差し迫っているかどうか調べる。サービスがプッシュサービスとして導入される場合には、新しいサービスパケットの可用性は新しい配信されたパッケージの受信で検出されることができる。サービスがプルサービスとして導入される場合には、新しいサービスパケットの可用性は例えば連続したダウンロード間の間隔を計時するタイマーの満了で検出されることができる。ユーザ端末は、あるいは、アプリケーションサーバー内の新しいアップデートされたパッケージの可用性に関する通知を受信することができる。ユーザ端末はさらに、ユーザから端末のユーザインターフェースを通して、ユーザ端末のディスプレイに新しいサービスパッケージを供給するコマンドを受信することができる。保護の範囲内で、新しいサービスパッケージに関連した検出およびトリガー手続きのいくつかの可能な方法が存在する。

新しいサービスパケットが差し迫っている場合（ステップ６３）、ユーザ端末はサービスパッケージを取得するための必要な手続きを行う（ステップ６４）。プッシュサービスの場合には、新しいサービスパッケージはすでにユーザ端末内にあり、および、それは更なる処理のために取り出される必要があるだけである。プルサービスの場合には、ユーザ端末はリクエストを生成し、アプリケーションサーバーにそれを送信し、かつ応答して、以前に開示されたように、アプリケーションサーバーによってコンパイルされたサービスパッケージを受信する。

ステップ６５においてユーザ端末は、サービスビューの構造定義を読み出し、サービスパッケージ内に受信されるコンテンツ項目とそれを組み合わせ（ステップ６６）かつユーザ端末の加入者に定められたフォーマットでそれを出力する（ステップ６７）。ユーザは、１回の無線ダウンロード手続きだけでサービスの全ての関連したページＰ１．．．Ｐ６を受信して、その後に例えばユーザ端末のディスプレーウインドー内で、１ページずつブラウズすることができる。

ユーザ機器ＵＥの機能説明を含む図７を参照することによって、ユーザ機器内に記載されている機構の実現が、例示される。ユーザ機器ＵＥは、処理手段７１０、算術論理ユニット、複数の特殊レジスタおよび制御回路を備える要素を備える。処理手段に接続されるのは、メモリ手段７１５、コンピュータ可読のデータまたはプログラムまたはユーザデータが記憶されることができるデータ媒体、である。メモリ手段は、一般的に読出しおよび書込みの両方を可能にするメモリユニット（ＲＡＭ）、およびコンテンツが読み出されることができるだけのメモリ（ＲＯＭ）を備える。このユーザ機器ＵＥはさらに、ユニット内の内部処理のためのユーザによってデータを入力するための入力手段７２５およびユーザデータをユニットの内部プロセスから出力するための出力手段７３０を有するユーザインターフェースブロック７２０を備える。前記入力手段の具体例は、キーパッドまたはタッチスクリーン、マイク、またはその他を備える。前記出力手段の具体例は、スクリーン、タッチスクリーン、スピーカ、等を備える。ユーザ機器ＵＥはさらに、エアーインタフェースから情報を受信して、処理手段７１０に入力するためにそれを処理するための受信手段７４０によって、同じく、処理手段７１０から情報を受信して、エアーインタフェース経由で送信するために更にそれを処理するための送信手段７４５によって、構成される通信ユニット７３５を備える。この種の通信ユニットの実現は、当業者に一般に公知である。処理手段７１０、メモリ手段７１５、ユーザインターフェースブロック７２０および通信ユニット７３５は、ユニットの所定の、基本的にプログラムされたプロセスに従って受信されたおよび／または記憶されたデータの動作の系統的実行を行うために電気的に相互接続されている。本発明に従う解決策において、動作は上記の通りにユーザ機器ＵＥの機能を備える。

情報流通に関連した他の問題は、受電端の要求条件、すなわちサービスの加入者または考慮中のユーザ端末に従ってサービスを柔軟に調整することができないことであった。

例えば、ユーザ機器ＵＥは音声だけのための簡略端末とすることができ、または、それはサービスプラットホームとして働いて、かつサービスに関するさまざまな機能のローディングおよび実行をサポートする多様なサービスのための端末とすることができる。新しいシステムを市場に出す場合、異なるタイプのユーザ機器の機能セットおよび表示機能はかなり変化し、したがって、サービスが均一に提供されることができず、それらが、異なるタイプの端末に対して別々に調整される必要があることが気づかれていた。調整するこの種の必要性は、サービス導入をかなり減速した。

この問題を克服するために、コンテンツプロバイダは異なるタイプのユーザ端末に対する別々のダウンロード可能なページを提供した。これは、コンテンツプロバイダ側の導入作業の量を増加させ、およびしたがって、サービスの収益性が減少させられた。ユーザ側では、ユーザは自分のユーザ端末の設定およびバージョンを知っていなければならず、かつダウンロードのためのページの正しいバージョンを検索しなければならなかった。ユーザはこの種の動作および要求条件が不快であると思い、したがって、彼または彼女の端末とアプリケーションサーバーとの間の適切な通信を調整することに時間をかけるよりは、むしろサービスを未使用のままにしさえする。

他方、従来のウェブサイトまたはモバイルサイトにおいて、コンテンツプロバイダはダウンロードできる複数のページを提供し、および、加入者は単にそのページをダウンロードするべきかどうか選択するだけである。加入者にとって、彼または彼女がダウンロードしたいコンテンツに前もって影響を与える方法はない。

これらの問題は、アプリケーションサービスの洗練された調整を可能にする本発明の更なる実施態様において解決される。この実施態様は、図８のフローチャートを用いて例示される。このフローチャートのステップは、図３の状況ですでに論じられたニュースサービスのプルタイプの実施におけるアプリケーションサービスの機能に関する。ステップ８１において発行サーバーとして働くアプリケーションサーバーが、ニュースサービスのサービスビュー（ＳＶ）の情報を受信する。ステップ８２においてアプリケーションサーバーはさらに、ユーザ端末から、アップデートされたサービスパッケージの送信を要求するリクエストを受信する。アプリケーションサーバーは、コンテンツ要素が、コンテンツ要素の識別として、およびコンテンツ要素のデータがアプリケーションサーバーに利用できるリソースファイルのアドレスとして都合よく規定される、一群のコンテンツ要素に対する定義を備えたサービスビューを読み込む（ステップ８３）。加えて、アプリケーションサーバーはユーザ端末から受信されるリクエストが調整指示を備えるかどうか調べる。調整指示は、本願明細書において、例えばタグ、ビットチャートまたは構造化データブロックを用いて、リクエスト内に含まれる情報要素を指す。この種の調整指示がリクエスト内に見いだされる（ステップ８４）場合、アプリケーションサーバーはこの指示を解釈し、かつ、サービスビューのコンテンツ項目のグループから調整指示に従ってコンテンツ項目を切り離す（ステップ８５）。この後に、抽出されたコンテンツ項目は、上で議論したように、コンパイルされ（ステップ８６）、ユーザ端末に送信される（ステップ８７）。調整指示がリクエスト内に見いだされない（ステップ８４）場合、手続きは直接コンパイルステップへ移動する。

例示の実施態様は、それが１つのサービスビューの端末に依存するバージョンの必要性を実際に除去するための手段を提供するという点で、有利である。サービスに特有のブラウザ、換言すれば、ユーザ端末内の端末アプリケーションは、サービスの観点から関連する一群の端末機能詳細を検出するように配置されることができる。端末機能情報の検出は移動通信装置の標準の機能であり、および、ユーザ端末のデバイスインタフェースを通してのその実装は当業者にとって周知である。検出は、例えば端末アプリケーションのインストール中に端末がスイッチを入れられる場合、および／または端末の使用中に規定された間隔で、行われるように配置されることができる。リクエストを生成する場合、端末アプリケーションは、サービスパッケージのコンテンツを調整するためのアプリケーションサーバー内に使われることができる一つ以上の指示を自動的に含む。例えば、この種の指示は限られたメモリまたは色のついた画像を示すことができないことの指示または表示画面のサイズの指示であることができる。リクエストを受信したあと、アプリケーションサーバーは規定されたコンテンツ項目またはサービスパッケージのサイズを増加させるページ全体のコンテンツを出したままにしておくことができる。利点として、アプリケーションサーバーはしたがって、端末に特有のパッケージを生成することができ、コンテンツ項目の特性および端末の能力に依存して、元々サービスビュー内にリストされたコンテンツ項目の一部が含まれるかまたは抜けおちる。例えば、大きいコンテンツ項目または色のついたもしくは広い画像を備えるコンテンツ項目が、除外されることができる。コンテンツソースは１つの同意された形式でコンテンツ項目を提供することができ、サービスプロバイダは１つの同意された形式でサービスビューを提供することができ、および、柔軟な端末装置特有の調整がなお可能である。

その上、例示の実施態様は、それがさらに個々のサービス加入者の要望に従ってサービスを動的に調整するための手段を提供するという点で、有利である。端末アプリケーションは、ユーザ端末のユーザインターフェースを通して好まれたコンテンツ上の指示を受信するように配置されることができる。対応して、コンテンツプロバイダは指示の一つ以上と一致されることができる属性を備えた全てのコンテンツ項目のいくつかを提供するように配置されることができる。そのような場合、アプリケーションサーバーはサービスパッケージ内に、その属性がユーザ端末によるリクエスト内に含まれる指示または複数の指示に対応するコンテンツ項目だけを含むように配置されることができる。例えば、コンテンツ項目は、金融ニュース、スポーツニュース、ニュースアラートその他の様に、それらを規定されたニュースカテゴリにリンクする属性による補完であることができる。加入者は、その時、随意に、現在彼または彼女にとって興味があるニュースの一部だけをダウンロードすることができる。別の例として、コンテンツ項目は、それらを規定された階層レベルにリンクする属性によって補足されることができる。加入者はその時、その階層レベルがリクエスト内に与えられた限界値を超えるニュースの部分だけをダウンロードする自由を有する。

さらに、例示の実施態様は、それがさらに、ユーザの位置に従って、サービスを動的に調整するための手段を提供するという点で有利である。端末アプリケーションは、ユーザの位置の指示を受信するように配置されることができる。この種の指示は、例えば、端末装置内の統合位置決め装置から自動的に転送されることができ、それはネットワークまたはユーザ端末のユーザインターフェースを通してのユーザによる入力から受信されることができる。対応して、コンテンツプロバイダは規定された位置情報と一致されることができる属性を全てのコンテンツ項目のいくつかに提供するように配置されることができる。そのような場合、アプリケーションサーバーはサービスパッケージ内に、その属性がユーザ端末によるリクエスト内に含まれる位置指示または複数の指示に対応するコンテンツ項目だけを含むように配置されることができる。加入者は、その時例えば彼または彼女の現在の位置に極めて近傍の娯楽機会に関する広告だけを、提供されることができる。

留意する必要があるのは、コンテンツ属性の使用の一部の例だけが本願明細書において論じられることである。本発明は、当業者に利用できる複数の他の実現を包含する。

情報の転送が無料でない場合、従来の情報流通システムに関連した更なる問題は課金に関する。ハイパーリンクを押すことによって単一のページのダウンロードを開始する場合、加入者は一般的に、そのページがどの程度の情報を含むかの考えをもっていない。ページが多数のコンテンツを備える場合には、そのダウンロードはパーバイトベースで課金されるかもしれない大量データ伝送を必要とする。一般的に、サービスの使用によって被られるコストを制御できることを望む加入者はこの種の状況を嫌う。他方、毎月の購読料は一般的に平均化された使用に従って調整され、およびしたがって、一部の加入者に対してあまりに高く、および、一部のユーザに対してあまりに低い。最適に、使用に基づく課金が、好まれるであろう。

本発明の更なる実施態様はこの問題を、アプリケーションサーバーがサービスパッケージ内に、ユーザ端末が通信システムの規定されたアドレスにメッセージを生成して送信するようにさせるスクリプトを含む配置によって解決する。このアドレスに対するメッセージは、１回の個別的なダウンロードに関連した課金に対応するプレミアム課金チケットを生成するように配置される。例えば、サービスビューの最初のページのコンテンツ項目は文字列を生成して、規定された別々に課金されたＭＳＩＳＤＮ番号にテキストメッセージとしてこの文字列を送信するスクリプトを備えることができる。本実施態様の利点は、サービスが使用、すなわちダウンロードされたサービスパッケージの数に従って課金されることができるような単純で容易に実現可能な方法をそれが提供するという点である。その上、課金方針に対する動的な調整が、これによって可能にされる。

当業者に明白であるのは、技術が進むにつれて、本発明の概念はさまざまな方法で実現されることができるということである。例えば、複数のサービスビューが１つのサービスに対して規定されることができる。ページの一部はしたがって、異なる種類のニュースがわずかに異なる見た目を有することができるように、１つのサービスビューにリンクされ、およびページの一部は他のビューにリンクされることができる。本発明およびその実施態様は、したがって、上記した具体例に限定されず、請求の範囲の有効範囲内で変化することができる。

以下において、本発明は添付の［付随する］図面を参照して好適な実施態様を用いてより詳細に記載され、そこにおいて、

電気通信システムの機能アーキテクチャを例示する。 本実施態様を実現するための論理要素を例示する。 サービスビューの一例を例示する。 アプリケーションサーバーの機能の一例を例示する。 アプリケーションサーバーの機能説明を例示する。 ユーザ機器の機能の一例を例示する。 ユーザ機器の機能説明を示す。 図３のニュースサービスのプルタイプの実現におけるアプリケーションサービスの機能を例示する。

符号の説明

２１ユーザ機器（ＵＥ）
２２基地局サブシステム（ＢＳＳ）
２３パケット交換コアネットワーク（ＰＳ−ＣＮ）
２４ＩＰマルチメディアサブシステム（ＩＭＳ−ＣＮ）
２５ＩＰネットワーク
２６アプリケーションサーバー（ＡＳ）
２７第１のコンテンツソースＣＳ１
２８第２のコンテンツソースＣＳ３
３０サービスビュー
３１構造定義ＤＥＦ
３２コンテンツ定義ＣＯＮＴ
５１処理手段
５２メモリ手段
５３インターフェースブロック
５４入力手段
５５出力手段
１００移動局（ＭＳ）
１０５コアネットワーク（ＣＮ）
１１０基地局システム（ＢＳＳ）
１１５無線インターフェースＵｍ
１２０基地トランシーバ局（ＢＴＳ）
１２５基地局コントローラ（ＢＳＣ）
１３０Ａ−インターフェース
１３３ＩＰマルチメディアサブシステムＩＭＳ
１３５移動スイッチングセンタ（ＭＳＣ）
１４０担当ＧＰＲＳ支持ノード（ＳＧＳＮ）
１４５Ｇｂインターフェース
１５０ゲートウェイＧＰＲＳ支持ノード（ＧＧＳＮ）
７１０処理手段
７１５メモリ手段
７２０インターフェースブロック
７２５入力手段
７３０出力手段
７３５通信ユニット
７４０受信手段
７４５送信手段

Claims (18)

1. 通信システム内に情報流通サービスを導入する方法であって、前記システムが、サーバー、ユーザ機器、および前記サーバーと前記ユーザ機器との間の情報の交換を可能にするアクセス網を備え、前記方法が、
   情報流通サービス、の少なくとも一つのサービスビューを作り出すステップであって、前記サービスビューが一つ以上のページを備え、一つのページがコンテンツデータおよびページ定義データの組合せを備えた別々の出力項目であり、前記ページ定義データが前記ページの出力において前記コンテンツデータのフォーマットを制御するようにするステップと、
   前記サービスビューの各々の前記一つ以上のページの前記コンテンツデータを集め、かつ、サービスビューの前記一つ以上のページの前記コンテンツデータをサービスパッケージにパッケージ化するための編集手段によってサーバーを構成するステップと、
   前記ユーザ端末内に少なくとも一つのサービスビューの少なくとも一つのページ定義データを記憶するステップであって、前記定義データが、前記サービスビューの前記一つ以上のページのコンテンツデータと組み合わせられるように配置されるステップと、
   前記サービスビューの前記少なくとも一つのページ定義データと組み合わせられるべき前記サービスビューの前記一つ以上のページの前記コンテンツデータを備えた前記サービスパッケージを前記サーバーから受信するための受信手段によってユーザ端末を構成するステップと、
   前記サービスパッケージ内に前記サービスビューの前記少なくとも一つのページ定義データと前記一つ以上のページの前記コンテンツデータを組み合わせるためのかつ前記ユーザ端末において前記サービスビューの前記一つ以上のページを出力する、出力手段によって前記ユーザ端末を構成するステップと、を含むことを特徴とする方法。
2. 通信システムであって、前記システムが、サーバー、ユーザ機器、および前記サーバーと前記ユーザ機器との間の情報の交換を可能にするアクセス網を備え、前記システムが、
   情報流通サービスの少なくとも一つのサービスビューを作り出すための手段であって、前記サービスビューが一つ以上のページを備え、一つのページがコンテンツデータおよびページ定義データの組合せを備えた別々の出力項目であり、前記ページ定義データが前記ページの出力において前記コンテンツデータのフォーマットを制御するようにする手段と、
   前記サービスビューの各々の前記一つ以上のページの前記コンテンツデータを集め、かつ、サービスビューの前記一つ以上のページの前記コンテンツデータをサービスパッケージにパッケージ化するための、編集手段を備えたサーバーと、
   少なくとも一つのサービスビューの少なくとも一つのページ定義データを記憶するための記憶手段であって、前記ページ定義データが、前記サービスビューの前記一つ以上のページのコンテンツデータと組み合わせられるように構成される記憶手段を備えたユーザ端末と、
   前記サービスビューの前記少なくとも一つのページ定義データと組み合わせられるべき前記サービスビューの前記一つ以上のページの前記コンテンツデータを備えた前記サービスパッケージを前記サーバーから受信するための受信手段と、
   前記サービスパッケージ内に前記サービスビューの前記少なくとも一つのページ定義データと前記一つ以上のページの前記コンテンツデータを組み合わせるための、かつ前記サービスビューの前記一つ以上のページを出力するための出力手段と、を備えることを特徴とするシステム。
3. サーバーであって、
   アクセス網を通してユーザ機器と情報を交換するためのアクセス手段を備え、
   情報流通サービスの少なくとも一つのサービスビュー上のページ定義を受信するための通信手段であって、前記サービスビューが一つ以上のページを備え、一つのページがコンテンツデータおよびページ定義データの組合せを備えた別々の出力項目であり、前記ページ定義データが前記ページの出力において前記コンテンツデータのフォーマットを制御するようにする通信手段と、前記サービスビューの各々の前記一つ以上のページの前記コンテンツデータを集め、かつ、サービスビューの前記一つ以上のページの前記コンテンツデータをサービスパッケージにパッケージ化するための、編集手段と、を特徴とするサーバー。
4. 選択指示を前記リクエストから抽出するように調整される、サービスに対するリクエストを受信するための受信手段と、
   前記編集手段が、
   コンテンツ項目に付与される属性を決定し、かつ、
   その属性が前記選択指示と一致する前記コンテンツ項目だけを前記サービスパッケージの中にパッケージ化するように配置されていること、を特徴とする請求項３に記載のサーバー。
5. 前記編集手段が前記コンテンツ項目の特性から前記属性を決定するように配置されており、前記特性が端末機能要求条件に関連していること、を特徴とする請求項４に記載のサーバー。
6. 前記編集手段が、前記コンテンツ要素内に含まれるタグから前記属性を決定するように配置されていること、を特徴とする請求項４に記載のサーバー。
7. 前記編集手段が、メッセージを生成し、かつ前記通信システムの規定されたアドレスに送信するように受信端末を起動するためのスクリプトを前記サービスパッケージ内に含むように配置されていること、を特徴とする請求項３ないし６のいずれかに記載のサーバー。
8. ユーザ端末であって、
   アクセス網を通してサーバーにアクセスするためのアクセス手段、を備え、
   情報流通サービスの少なくとも一つのサービスビューの定義を受信し、前記サービスビューが一つ以上のページを備え、一つのページがコンテンツデータおよびページ定義データの組合せを備えた別々の出力項目であり、前記ページ定義データが前記ページの出力において前記コンテンツデータのフォーマットを制御するようにし、
   前記ユーザ端末内に少なくとも一つのサービスビューの少なくとも一つのページ定義データを記憶するための記憶手段であって、前記ページ定義データが、前記サービスビューの前記一つ以上のページのコンテンツデータと組み合わせられるように構成される記憶手段と、
   前記サービスビューの前記少なくとも一つのページ定義データと組み合わせられるべき前記サービスビューの前記一つ以上のページの前記コンテンツデータを備えた前記サービスパッケージを前記サーバーから受信するための受信手段と、
   前記サービスパッケージ内に前記サービスビューの前記少なくとも一つのページ定義データと前記一つ以上のページの前記コンテンツデータを組み合わせるための、かつ前記サービスビューの前記一つ以上のページを出力するための出力手段と、を特徴とするユーザ端末。
9. 前記サービスビューの前記少なくとも一つのページ定義データと組み合わせられるべき前記サービスビューの前記一つ以上のページの前記コンテンツデータを備えたサービスパッケージに対するリクエストを前記サーバーに起動するためのリクエスト手段を備えた受信手段、を特徴とする請求項８に記載のユーザ端末。
10. 前記リクエスト手段がリクエスト内に選択指示を含むように配置されること、を特徴とする請求項９に記載のユーザ端末。
11. 前記指示が必要端末機能に関していること、を特徴とする請求項１０に記載のユーザ端末。
12. 前記指示が前記コンテンツ要素のカテゴリ化に関していること、を特徴とする請求項１０に記載のユーザ端末。
13. 前記カテゴリ化が前記コンテンツの階層化レベルを代表する数として指示されていること、を特徴とする請求項１２に記載のユーザ端末。
14. 前記受信手段が、前記サービスパッケージ内にスクリプトを受信し、かつ、
    前記受信されたサービスパッケージに応答して、メッセージを生成し、かつ前記通信システムの規定されたアドレスに送信するように構成されていること、を特徴とする請求項８ないし１３のいずれかに記載のユーザ端末。
15. 通信システムのサーバー内の情報を管理するための方法であって、前記方法が、
    情報流通サービスのサービスビューを受信するステップであって、前記サービスビューが一つ以上のページを備え、一つのページがコンテンツデータおよびページ定義データの組合せを備えた別々の出力項目であり、前記ページ定義データが前記ページの出力において前記コンテンツデータのフォーマットを制御するようにするステップと、
    前記サービスビュー内のコンテンツデータ定義に従って前記一つ以上のページの前記コンテンツデータを集め、かつ、サービスビューの前記一つ以上のページの前記コンテンツデータをサービスパッケージにパッケージ化するステップと、を含むことを特徴とする方法。
16. 通信システムのユーザ端末内に情報を表示するための方法であって、前記方法が、
    情報流通サービスの少なくとも一つのサービスビューを受信するステップであって、前記サービスビューが一つ以上のページを備え、一つのページがコンテンツデータおよびページ定義データの組合せを備えた別々の出力項目であり、前記ページ定義データが前記ページの出力において前記コンテンツデータのフォーマットを制御するようにするステップと、
    少なくとも一つのサービスビューの少なくとも一つのページ定義データを記憶するステップであって、前記定義データが、前記サービスビューの前記一つ以上のページのコンテンツデータと組み合わせられるように構成されるステップと、
    前記サービスビューの前記少なくとも一つのページ定義データと組み合わせられるべき前記サービスビューの前記一つ以上のページの前記コンテンツデータを備えた前記サービスパッケージを前記サーバーから受信するステップと、
    前記サービスパッケージ内に前記サービスビューの前記少なくとも一つのページ定義データと前記一つ以上のページの前記コンテンツデータを組み合わせ、かつ前記ユーザ端末において前記サービスビューの前記一つ以上のページを出力するステップと、を含むことを特徴とする方法。
17. サーバーの中で実行可能なコンピュータプログラム製品であって、サーバー内の前記コンピュータプログラム製品の実行が、前記サーバーに請求項１５の方法のステップを実行させることを特徴とする製品。
18. ユーザ端末の中で実行可能なコンピュータプログラム製品であって、ユーザ端末内の前記コンピュータプログラム製品の実行が、前記ユーザ端末に請求項１６の方法のステップを実行させることを特徴とする製品。