(57)【特許請求の範囲】
【請求項１】
コンテンツ・プロバイダからモバイル・デバイスに情報コンテンツを提供するシステムであって、
データ・ファイルとしての前記コンテンツおよび対応するスクリプト・ファイルを格納する第１ストアであって、前記データ・ファイルは表現すべき前記コンテンツを示すデータを含み、前記スクリプト・ファイルは前記データを表現する所望の表現形態を示すスクリプトを含み、前記スクリプト・ファイルおよび前記データ・ファイルを互いに独立して送信する、第１ストアと、
前記第１ストアに結合してあり、前記データ・ファイルおよび前記スクリプト・ファイルを検索し、前記データおよびスクリプトを未変換形態から変換形態に変換するように構成した第１変換レイヤであって、前記データおよびスクリプト上において実行された変換動作を示すタグ情報であって前記変換されたデータおよびスクリプトをパケット送信する際のパケットヘッダ部に格納されるタグ情報を与え、かつ前記変換される形式の前記スクリプトおよびデータと共に前記タグ情報を提供する、第１の変換レイヤと、
前記第１ストアに結合可能であり、前記モバイル・デバイスに前記コンテンツを送信するように構成した送信機と、
を含むプロバイダ・コンポーネントと、
前記送信機から前記コンテンツを受信するように構成した受信機と、
前記受信機に結合してあり、前記タグ情報に基づいて前記データおよびスクリプトを変換形態から未変換形態に変換するように構成した第２変換レイヤと、
第２ストアと、
前記受信機および前記第２ストアに結合してあり、前記スクリプト・ファイルおよび前記データ・ファイルを前記第２ストアに供給するように構成したルータと、
前記第２ストアに結合してあり、前記データ・ファイルを選択的に検索し、前記スクリプトを実行して前記データを前記所望の表現形態とするトランスポートと、
を含む、前記モバイル・デバイス上に配置してある、モバイル・デバイス・コンポーネントと、
前記プロバイダ・コンポーネントに選択的に結合可能であり、前記データ・ファイルおよび前記スクリプト・ファイルを検索するように構成したデスクトップ・コンピュータと、
前記デスクトップ・コンピュータ上に、前記モバイル・デバイスに選択的に結合可能となるように構成した同期コンポーネントとをさらに備え、
前記モバイル・デバイス・コンポーネントは、
前記モバイル・デバイス上にあり、前記デスクトップ・コンピュータ上の前記同期コンポーネントに選択的に結合可能な同期コンポーネントを備え、前記デスクトップ・コンピュータ上の前記同期コンポーネントおよび前記モバイル・デバイス上の前記同期コンポーネントが、前記モバイル・デバイスへの前記スクリプト・ファイルおよび前記データ・ファイルを選択的に同期するように構成され、前記モバイル・デバイス・コンポーネント上の同期コンポーネントによって同期化される前記データ・ファイルおよびスクリプト・ファイルは、前記第２の変換レイヤによって変換されないことを特徴とするシステム。
【請求項２】
前記第１変換レイヤは、前記データおよびスクリプトを非圧縮形態から圧縮形態に圧縮するように構成した圧縮部を備え、前記第２変換レイヤは、前記受信機に結合してあり、前記データおよびスクリプトを前記圧縮形態から前記非圧縮形態に伸長するように構成した伸長部を備える請求項１記載のシステム。
【請求項３】
前記第１変換レイヤは、前記スクリプトおよびデータを暗号化するように構成した暗号化部を備え、前記第２変換レイヤは、前記データおよび前記スクリプトを解読するように構成した解読部を備える請求項１記載のシステム。
【請求項４】
前記第１変換レイヤは、前記スクリプトおよびデータを符号化するように構成したエンコーダを備え、前記第２変換レイヤは前記スクリプトおよびデータを復号するように構成したデコーダを備える請求項１記載のシステム。
【請求項５】
前記第１変換レイヤは、前記スクリプトおよびデータを複数の部分に分割し、該部分を送信に適したパケットに変換するように構成したパッケージャを備え、前記第２変換レイヤは、前記パケットを逆変換し組み立てるように構成したアンパッケージャを備える請求項１記載のシステム。
【請求項６】
前記送信機が、
前記コンテンツをワイヤレス伝送リンクを通じて送信するワイヤレス送信機を備え、前記受信機は、前記ワイヤレス伝送リンクを通じて前記コンテンツを受信するように構成したワイヤレス受信機を備える請求項１記載のシステム。
【請求項７】
前記第１ストアは、記録特性を含む前記情報コンテンツの特性を記載した定義ファイルを含み、前記トランスポートは、前記モバイル・デバイス上で前記情報コンテンツを表現したことを示す表現情報を記録する請求項１記載のシステム。
【請求項８】
前記モバイル・デバイス上の前記同期コンポーネントは、前記デスクトップ・コンピュータへ前記表現情報を同期するように構成され、前記検索コンポーネントは、前記プロバイダ・コンポーネントに前記表現情報を供給するように構成された請求項７記載のシステム。
【請求項９】
前記表現情報は、前記情報コンテンツを前記モバイル・デバイス上で表現した回数を示す表現カウントと、前記情報コンテンツを前記モバイル・デバイス上で表現した時間を示す表現時間とを含む請求項８記載のシステム。
【請求項１０】
前記プロバイダ・コンポーネントが、更に、 ワイヤレス伝送リンクを通じて前記コンテンツを送信するワイヤレス送信機を備え、前記受信機が、更に、前記ワイヤレス伝送リンクを通じて前記コンテンツを受信するように構成したワイヤレス受信機を備える請求項１記載のシステム。
【請求項１１】
前記情報コンテンツは、オペレーティングシステムに依存しない言語を用いて表現する情報から成る請求項１記載のシステム。
【請求項１２】
前記情報コンテンツは、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）を用いて表現する情報から成る請求項１１記載のシステム。
【請求項１３】
前記第１変換レイヤは前記スクリプトおよびデータを、前記変換形態において、複数の別個のフィルタリング・セグメントとして供給し、前記モバイル・デバイス上の受信機は、前記複数のフィルタリング・セグメントの内第１フィルタリング・セグメントに基づいて、前記スクリプトおよびデータを選択的に受信および破棄し、前記第２変換レイヤは、前記複数のフィルタリング・セグメントの内第２フィルタリング・セグメントに基づいて、前記スクリプトおよびデータを選択的に受信および破棄する請求項１記載のシステム。
【請求項１４】
前記情報コンテンツは、加入可能なチャネルに関するグループ情報およびトピック情報を備え、前記複数のフィルタリング・セグメントの内前記第２フィルタリング・セグメントは、前記グループ情報に対応する第１フィルタリング部と、前記トピック情報に対応する第２フィルタリング部とを含み、前記第２変換レイヤは、互いに独立した前記群およびトピック・フィルタリング部に基づいて、フィルタリングする請求項１３記載のシステム。
【請求項１５】
モバイル・デバイスによって読み取り可能な命令を含むコンピュータ読み取り可能な記憶媒体であって、前記命令を実装すると、
データ・ファイル、対応するスクリプト・ファイル、およびタグ情報を間欠的に受信するステップであって、前記データ・ファイルおよび前記対応するスクリプト・ファイルは変換された形態で受信され、前記データ・ファイルが情報を示すデータを含み、前記スクリプト・ファイルが前記データを表現する所望の態様を示すスクリプト情報を含み、前記データ・ファイルおよび対応するスクリプト・ファイルを前記モバイル・デバイスが独立して受信可能であり、前記タグ情報は、前記変換された形態のデータおよびスクリプトをパケット送信する際のパケットヘッダ部に格納され、前記データおよびスクリプト上において実行された変換動作を示すタグ情報である、ステップと、
前記データ・ファイルおよびスクリプト・ファイルを前記タグ情報に基づいて変換されていない形態に変換するステップと、
前記スクリプト・ファイルおよびデータ・ファイルを格納するステップと、
前記データ・ファイルから前記データを検索し、前記対応するスクリプト・ファイルにおける前記スクリプトを実行して前記データを表現するステップと、
前記表現するデータをデスクトップ・コンピュータと同期するステップと、
を実行することにより、前記モバイル・デバイスに情報を処理させるコンピュータ読み取り可能な記憶媒体であって、
前記同期化された表現するデータは前記変換するステップによって変換されないことを特徴とする記憶媒体。
【請求項１６】
モバイル・デバイスによって読み取り可能な命令を含み、実装すると、
更新データを含む更新データ・ファイルを間欠的に受信するステップと、
前記モバイル・デバイス上に既に格納してある、前記対応するスクリプト・ファイル内の前記スクリプトを実行することによって、前記更新データを表現するステップと、
を実行することにより、前記モバイル・デバイスに情報を処理させる請求項１５記載のコンピュータ読み取り可能な記憶媒体。
【請求項１７】
前記モバイル・デバイス上に既に格納してある、前記対応のスクリプト・ファイル内の前記スクリプトを実行するステップを、前記更新データの受信に応答して実行する請求項１６記載のコンピュータ読み取り可能な記憶媒体。
【請求項１８】
前記スクリプトを実行するステップが、
オペレーティング・システに依存しない形態で前記データを表現するステップを含む請求項１７記載のコンピュータ読み取り可能な記憶媒体。
【請求項１９】
前記スクリプトを実行するステップが、
前記データをハイパーテキスト・マークアップ言語（ＨＴＭＬ）形態で表現するステップを含む請求項１８記載のコンピュータ読み取り可能な記憶媒体。
【請求項２０】
更に、モバイル・デバイスによって読み取り可能な命令を含み、実装すると、
更新スクリプトを含む更新スクリプト・ファイルを間欠的に受信するステップと、
前記モバイル・デバイス上に既に格納してある、前記対応のデータ・ファイルにおけるデータに対して前記更新スクリプトを実行し、前記更新スクリプトに応じて前記データを表現するステップと、を実行することにより、前記モバイル・デバイスに情報を処理させる請求項１５記載のコンピュータ読み取り可能な記憶媒体。
【請求項２１】
前記データ・ファイルおよび対応するスクリプト・ファイルは、変換形態で受信し、更に、モバイル・デバイスによって読み取り可能な命令を含み、実装すると、
前記データ・ファイルおよびスクリプト・ファイルを無変換形態に逆変換するステップを実行することにより、前記モバイル・デバイスに情報を処理させる請求項１６記載のコンピュータ読み取り可能な記憶媒体。
【請求項２２】
更に、モバイル・デバイスによって読み取り可能な命令を含み、実装すると、
追加スクリプトを含む追加スクリプト・ファイルを間欠的に受信するステップと、
前記追加スクリプト・ファイルに対応し追加のデータを含む追加データ・ファイルを間欠的に受信するステップと、
を実行することにより、前記モバイル・デバイスに情報を処理させる請求項１５記載のコンピュータ読み取り可能な記憶媒体。
【請求項２３】
更に、モバイル・デバイスによって読み取り可能な命令を含み、実装すると、
前記追加スクリプト・ファイル内の前記追加スクリプトを、前記対応する追加データ・ファイル内のデータに対して実行し、前記追加スクリプトに応じて前記追加データを表現するステップを実行することにより、前記モバイル・デバイスに情報を処理させる請求項２２記載のコンピュータ読み取り可能な記憶媒体。
【請求項２４】
更に、モバイル・デバイスによって読み取り可能な命令を含み、実装すると、
前記情報の表現に基づいて、表現データを記録するステップを実行することにより、前記モバイル・デバイスに情報を処理させる請求項１５記載のコンピュータ読み取り可能な記憶媒体。
【請求項２５】
更に、モバイル・デバイスによって読み取り可能な命令を含み、実装すると、
前記スクリプト・ファイルおよびデータ・ファイルを、複数の別個のフィルタリング・セグメントとして受信するステップと、
前記複数のフィルタリング・セグメントに基づいて、前記スクリプトおよびデータを選択的に受信および破棄するステップと、
を実行することにより、前記モバイル・デバイスに情報を処理させる請求項１５記載のコンピュータ読み取り可能な記憶媒体。
【請求項２６】
前記情報コンテンツは、加入可能なチャネルに関するグループ情報およびトピック情報を備え、前記コンピュータ読み取り可能媒体は、更に、モバイル・デバイスによって読み取り可能な命令を含み、実装すると、
前記グループ情報に対応する第１フィルタリング部および前記トピック情報に対応する第２フィルタリング部に基づいて前記スクリプトおよびデータを選択的に受信および破棄し、前記フィルタリングは、互いに独立した前記グループおよびトピック・フィルタリング部に基づいて行なうステップを実行することにより、前記モバイル・デバイスに情報を処理させる請求項２５記載のコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【０００１】
（発明の背景）
本発明は、一般にモバイル・デバイスとして知られている、パーソナル・モバイル計算デバイスに関する。更に特定すれば、本発明は、情報を配信しモバイル・デバイス上で受信するシステムおよび方法に関するものである。
【０００２】
モバイル・デバイスは、多くの場合パーソナル・ディジタル・アシスタントと呼ばれている、小型電子計算デバイスのことである。このようなモバイル・デバイスの多くは、ハンド・ヘルド・デバイスまたは手の平サイズのデバイスであり、手の中にすんなり納まるようなものである。商業的に入手可能なモバイル・デバイスの１つに、ワシントン州、ＲｅｍｏｎｄのＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎ（マイクロソフト社）が供給するソフトウエアを有し、ＨａｎｄＨｅｌｄ  ＰＣ（またはＨ／ＰＣ）という商標で販売されているものがある。
【０００３】
一般に、モバイル・デバイスは、プロセッサ、ランダム・アクセス・メモリ（ＲＡＭ）、およびキーボードやディスプレイのような入力デバイスを含む。キーボードを接触感応ディスプレイとして組み込む場合等では、キーボードをディスプレイと一体化することができる。オプションとして、通信インターフェースを備え、デスクトップ・コンピュータと通信するために一般的に用いられている。交換可能なバッテリまたは再充電可能なバッテリがモバイル・デバイスに給電する。オプションとして、モバイル・デバイスは、内蔵バッテリを無視または再充電する、外部電源から電力を受けることが可能である。
【０００４】
従来のアプリケーションには、モバイル・デバイスをデスクトップ・コンピュータと共に用いるものもある。例えば、モバイル・デバイスのユーザは、仕事場または家庭、あるいは双方においてデスクトップ・コンピュータにアクセスし、使用する場合もある。ユーザは、通常、デスクトップ・コンピュータおよびモバイル・ユニット双方で同じ種類のアプリケーションを走らせる。したがって、モバイル・デバイスをデスクトップ・コンピュータと結合し、モバイル・デバイスと情報を交換したり、情報を共有するように設計することは非常に有利である。
【０００５】
このようなモバイル・デバイスに情報を提供する別の技法に、ワイヤレス伝送リンクを介するものがある。このような情報は、電子メールまたはニュース、天気予報、スポーツ、交通、および地域のイベント情報を含むことができる。この情報は、通常、インターネットに接続したデスクトップ・コンピュータから得られ、有線接続を介して配信される。しかしながら、このような情報を同様にワイヤレス接続を通じて配信することが望ましい場合もある。モバイル・デバイス上のワイヤレス受信機は、情報がモバイル・デバイスに向けて送られると、これを受信するように動作することができる。
【０００６】
現在、プッシュ型コンテンツ（インターネットやワールド・ワイド・ウェブのようなグルーバル・ネットワーク上で提供されるハイパーテキスト・マークアップ言語（ＨＴＭＬ）コンテンツ等）をこのようなデバイスに、ワイヤレスにそしてオープンに利用可能なアーキテクチャで配信する適当な方法がない。従来のワイヤレス・チャネルのビット・レートはかなり低い。したがって、非常に大きなコンテンツ（ＨＤＭＬコンテンツ等）の配信は非常に非現実的である。
【０００７】
このような情報を配信する従来型の手法の１つは、コンテンツをＨＴＭＬのようなデバイスに適したフォーマット（ｄｅｖｉｃｅ  ｆｒｉｅｎｄｌｙ  ｆｏｒｍａｔ）に書き換えることである。すると、プル型モデルでコンテンツが得られる。現在ワイヤレス媒体によって情報を配信するために用いられている別の手法にクローズド・モデル（ｃｌｏｓｅｄ  ｍｏｄｅｌ）がある。クローズド・モデルでは、コンテンツ・プロバイダは、特定のタイプのソフトウエアを実装している特定のデバイスが受信するのに適したフォーマットで書かれたコンテンツのみを提供することができる。これが意味するのは、ウェブ・コンテンツの大部分はこのようなデバイス上で見られないということである。
（発明の概要）
本発明は、情報コンテンツをモバイル・デバイスに配信するシステムを提供する。ウェブ・コンテンツをデータおよびスクリプト情報に分割する。スクリプト情報を用いてデータ上で動作させ、データを所定のフォーマットで表現する（ｒｅｎｄｅｒ）。
（好適な実施形態の詳細な説明）
図１は、本発明を実現するシステム１０を一例として示す。システム１０は、コンテンツ・プロバイダ１２、ワイヤレス・キャリア１４、デスクトップ・コンピュータ１６およびモバイル・デバイス１８を含む。コンテンツ・プロバイダ１２は、データベースまたはその他のデータ・ソースから、適切なタイプのあらゆるデータを提供する。例えば、コンテンツ・プロバイダ１２は、以下ではインターネットのワールド・ワイド・ウェブ・コンテンツのプロバイダとして論ずることにする。好適な実施形態では、コンテンツは、ＨＴＭＬ、ＪＰＥＧ、ＧＩＦ、ＷＡＶ等のような標準的なフォーマットで提供する。また、ウェブ・コンテンツは、チャネル定義フォーマット（ＣＤＦ：ｃｈａｎｎｌｅ  ｄｅｆｉｎｉｔｉｏｎ  ｆｏｒｍａｔ）ファイルで記述することも好ましい。コンテンツ（ウェブ・ページまたはウェブ・サイト等）の単一部分を、ここではモバイル・チャネルと呼ぶ。
【０００８】
モバイル・チャネルは、自己記述型ウェブ・サイト（ｓｅｌｆ  ｄｅｓｃｒｉｂｉｎｇ  ｗｅｂ  ｓｉｔｅ）であり、ウェブ・コンテンツのモバイル・デバイス１８への効率的なダウンロードに必要な情報全てを含む。好ましいモバイル・チャネルには、３つのコンポーネントを備えている。これらのコンポーネントは、チャネル定義フォーマット（ＣＤＦ）ファイル、チャネルを表現するための１組のスクリプト・ファイル、および１組の表現するデータ・ファイルを含むＣＤＦファイルについては、ＣＨＡＮＮＥＬ  ＤＥＦＩＮＩＴＩＯＮ  ＡＲＣＨＩＴＥＣＴＵＲＥ  ＥＸＴＥＮＳＩＯＮ（チャネル定義アーキテクチャの拡張）と題する同時係属中の米国特許出願番号第 号に更に詳細に記載されている。その内容は、この言及により本願にも全てが含まれるものとする。端的に言えば、ＣＤＦは、モバイル・チャネル上に含まれるコンテンツの項目表である。
【０００９】
スクリプト・ファイルは、モバイル・デバイス１８のスクリーン上におけるデータの出現を指定するテンプレートを定義するスクリプトを含む。スクリプトは、ビジュアル・ベーシック・スクリプト（ＶＢＳ）で書くことが好ましい。
【００１０】
データ・ファイルは、１つ以上のスクリプト・ファイルに対応し、表現すべきチャネルの直接的なコンテンツを示すデータを含む。このデータは、小さく単純なテキスト・ファイルにパケージ化する。この情報の全てを用いて、ウェブ・コンテンツを定義する。
【００１１】
ワイヤレス・キャリア１４については、本願では後程更に詳しく説明する。しかしながら、端的に言えば、ワイヤレス・キャリア１４は、ウェブ・コンテンツを、ウェブ・コンテンツ・プロバイダ１２から、ダイアル・アップまたは直接インターネット接続あるいはネットワーク接続によって受信するように構成してある。また、ワイヤレス・キャリア１４はワイヤレス・プッシュ・サーバ（ＷＰＳ）２０も含む。サーバ２０は、コンテンツ・プロバイダ１２から受信したコンテンツを、ワイヤレス・キャリア１４が用いる特定のトランスポート・タイプと互換性のある断片に分割する。例えば、サーバ２０は、用いるチャネル・タイプまたはトランスポート・タイプのために、データを分割し、最大パケット・サイズの制約、キャラクタ・セットに対する要求に合わせるようにすることができる。伝送に先立って、データを異なる形態に変換することが好ましい。本願では後に更に詳細に説明するが、このような変換は、圧縮、符号化、およびパッケージ化を含むことができる。一旦データを適切に分割しトランスポートの制約に合わせたならば、次にワイヤレス・ネットワーク（ページング・チャネルを通じてというように）を通じて、空中を伝送し、モバイル・デバイス１８上で直接受信するように構成する。伝送データは、モバイル・デバイス１８上のワイヤレス受信機およびドライバ・コンポーネント２２が受信し、ここでモバイル・デバイス１８による使用のためにデータを調整する。
【００１２】
また、モバイル・デバイス１８はモデム２４を含むことも望ましい。したがって、ワイヤレス・キャリア１４を介して伝送するのではなく、サービス・コンテンツは、コンテンツ・プロバイダ１２から直接ダイアルアップ・モデム接続を通じて、モバイル・デバイス１８に伝送することができる。
【００１３】
デスクトップ・コンピュータ１６についても、この明細書では後に更に詳細に説明する。しかしながら、端的に言えば、デスクトップ・コンピュータは、ワシントン州、ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎから商業的に入手可能なＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒのような、標準的なウェブ・ブラウザを備えることが好ましい。その場合、デスクトップ・コンピュータ１６のユーザは、オフラインまたはオンラインで閲覧可能な所定のチャネル・コンテンツをユーザに提供するチャネルに、標準的な方法で加入することができるので好ましい。デスクトップ・コンピュータ１６は、（本発明の一態様による）ローダブル・トランスポートを備えることが好ましく、これはスクリプト・ファイルにアクセスし、コンテンツを表現するための（スクリプトに応じて）対応するデータ・ファイル上に作用する。この場合、デスクトップ・コンピュータ１６がデータを表現する。デスクトップ・コンピュータ１６は、このトランスポートを通じて、新たなそして更新したスクリプト、データ、およびＣＤＦファイルを、更にモバイル・デバイス１８に送信するため、または単にデータを表現するためのいずれかに、周期的に検索または受信することができる。スクリプト、データおよびＣＤＦファイルは、一緒にまたは互いに独立して送信することができる。スクリプティング・ファイルは通常データ・ファイルよりも更新する必要性は遥かに低いので、デスクトップ上で（オフライン）ウェブ・コンテンツを視認する機能をユーザに与えつつ、データ・ファイルを徐々に更新するために必要な帯域幅は少量のみで済む。
【００１４】
また、デスクトップ・コンピュータ１６は、同期コンポーネント２６を含むことも好ましい。端的に言えば、同期コンポーネント２６は、モバイル・デバイス１８上の同様の同期コンポーネントと双方向処理を行い、同期対象のファイルが、デスクトップ・コンピュータ１６からモバイル・デバイス１８に、またはその逆に同期することを可能とする。一旦同期が取れたならば、双方のファイル（コンピュータ１６およびモバイル・デバイス１８上のファイル）は、最新のデータを含むことになる。
【００１５】
より具体的には、モバイル・デバイス１８は、好適な実施形態では、デスクトップ・コンピュータ１６、または他のモバイル・デバイス１８、あるいは双方と同期することができる。その場合、モバイル・デバイス１８上のオブジェクト・ストアに格納してあるオブジェクトのプロパティは、デスクトップ・コンピュータ１６または別のモバイル・デバイス１８上のオブジェクト・ストア上に格納してある同じオブジェクトの別のインスタンスのプロパティと同様となる。したがって、例えば、ユーザがデスクトップ・コンピュータ１６上のオブジェクト・ストアに格納してあるオブジェクトのあるインスタンスを変更すると、モバイル・デバイス１８を次回デスクトップ・コンピュータ１６に接続したときに、モバイル・デバイス１８のオブジェクト・ストア内の当該オブジェクトの第２インスタンスが更新されるので、同じオブジェクトの双方のインスタンスは最新のデータを含むことになる。これを同期と呼ぶ。
【００１６】
同期を取るためには、同期コンポーネント２６および２８をモバイル・デバイス１８およびデスクトップ・コンピュータ１６（または別のモバイル・デバイス１８）双方で走らせる。同期コンポーネントは、的確なインターフェースを介して互いに通信し、通信および同期を管理する。
【００１７】
また、モバイル・デバイス１８は、スクリプト・インタープリタも備えることが好ましい。スクリプト・インタープリタは、好適な一実施形態では、デスクトップ・コンピュータ１６上のローダブル・トランスポートと同一または同様である。このようなトランスポートは、例えば、ダウン・サイズ型ビジュアル・ベーシック・インタープリタとすることができ、フォーマッティング・スクリプトを受け取り、解釈する。スクリプトには、ウェブ・コンテンツの生データを保持する所定のデータ・ファイル（通常テキスト・ファイル）が関連付けてある。したがって、スクリプト・インタープリタは、所与のスクリプトに関連するデータ上で動作し、モバイル・デバイス１８のユーザに、ウェブ・コンテンツの表現を与える。
【００１８】
スクリプトをウェブ・コンテンツ内のデータから分離することにより、ウェブ・非常にビット・レートが低いチャネル上でコンテンツをモバイル・デバイス１８に送信することが可能となる。通常、スクリプトはさほど頻繁に送信する必要はない。また、個々のファイルは通常スクリプト・ファイルよりもかなり小さいので、非常に頻繁にデータを更新することができ、新たなスクリプトを送信することなく、モバイル・デバイス１８のユーザに更新ウェブ・コンテンツ情報を与えることができる。このように、スクリプトおよびデータの分離によって、ウェブ・コンテンツ情報の送信は、低ビット・レート・チャネル上で非常に効率的行なうことが可能となる。
【００１９】
尚、好適な実施形態では、モバイル・デバイス１８をデスクトップ・コンピュータ１６に結合可能であるが、別のモバイル・デバイスにも結合可能であることは、注記するに値しよう。この接続は、適当な商業的に入手可能ないずれの通信リンクを用いても、そして適当な通信プロトコルを用いて行なうことができる。例えば、好適な一実施形態では、モバイル・デバイス１８は、シリアル通信プロトコルを用いて通信を行なう物理的なケーブルによって、デスクトップ・コンピュータ１６または別のモバイル・デバイス１８と通信する。また、本発明によって、赤外線（ＩＲ）通信またはその他の適当な通信機構のような、別の通信機構も考えられる。
【００２０】
図２は、モバイル・デバイス１８の更に詳細なブロック図である。モバイル・デバイス１８は、マイクロプロセッサ３０、メモリ３２、入出力（Ｉ／Ｏ）コンポーネント３４、デスクトップ通信インターフェース３６、ワイヤレス受信機３７、およびアンテナ３９を含むことが好ましい。一実施形態では、これらのコンポーネントは、適切なバス３８を通じて、互いの通信のために結合してある。
【００２１】
メモリ３２は、バッテリ・バックアップ・モジュール（図示せず）を備えたランダム・アクセス・メモリ（ＲＡＭ）のような不揮発性電子メモリとして実現し、モバイル・デバイス１８全体の電力が停止した場合に、メモリ３２に格納してある情報を失わないようにすることができる。メモリ３２の一部は、プログラム実行のためにアドレス可能なメモリとして割り当てることが好ましく、一方メモリ３２の残りの部分は、ディスク・ドライブ上の格納をシミュレートするためというように、格納のために用いることが好ましい。
【００２２】
メモリ３２は、オペレーティング・システム４０、アプリケーション・プログラム４２（パーソナル情報マネージャ即ちＰＩＭ等）、およびオブジェクト・ストア４４を含む。動作中、オペレーティング・システムは、メモリ３２からプロセッサ３０によって実行することが好ましい。オペレーティング・システム４０は、好適な一実施形態では、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎから商業的に入手可能なＷｉｎｄｏｗｓ  ＣＥブランドのオペレーティング・システムである。オペレーティング・システム４０は、モバイル・デバイス用に設計し、１組の外から見える（ｅｘｐｏｓｅｄ）アプリケーション・プログラミング・インターフェースおよびメソッドを通じてＰＩＭ４２が利用可能なデータベース機能を実装することが好ましい。オブジェクト・ストア４４内のオブジェクトは、少なくとも部分的に、前述の外から見えるアプリケーション・プログラム・インターフェースおよびメソッドへのコールに応答して、ＰＩＭ４２およびオペレーティング・システム４０によって維持することが好ましい。
【００２３】
Ｉ／Ｏコンポーネント３４は、好適な一実施形態では、モバイル・デバイス１８のユーザからの入力および出力動作を簡便化するために備えたものである。Ｉ／Ｏコンポーネント３４については、図３および図４に関して更に詳細に説明する。
【００２４】
オプションとして、デスクトップ通信インターフェース３６は、あらゆる適当な通信インターフェースを提供する。好ましくは、インターフェース３６は、図１に関して説明したように、デスクトップ・コンピュータ１６、コンテンツ・プロバイダ１２、ワイヤレス・キャリア、そして任意に別のモバイル・デバイス１８と通信するために用いる。したがって、通信インターフェース３６は、デスクトップ・コンピュータ１６と通信するために同期コンポーネント２８、そしてコンテンツ・プロバイダ１２と通信するためにモデム２４を含むことが好ましい。ワイヤレス受信機およびドライバ２２は、ワイヤレス・キャリア１４と通信するために用いる。
【００２５】
図３は、本発明と共に使用可能なモバイル・デバイス１０の好適な一実施形態の概略構成図である。モバイル・デバイス１０は、図３に示すように、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎが提供するソフトウエアを有し、Ｈ／ＰＣという名称で販売しているデスクトップ・アシスタントである。好適な一実施形態では、モバイル・デバイス１８は、小型化キーボード４３、ディスプレイ４５およびスタイラス４６を含む。小型化ディスプレイ４５は、スタイラス４６と共に用いる接触感応画面を有する液晶ディスプレイ（ＬＣＤ）である。スタイラス４６は、指定した座標においてディスプレイ４５を押下するかまたはディスプレイ４５に接触し、あるユーザ入力機能を実行するために用いる。小型化キーボード４３は、好ましくは、あらゆる適当かつ望ましい機能キーを有し、所定のユーザ入力機能を実行することも可能な、小型化英数字キーボードとして実施する。
【００２６】
図４は、本発明の別の好適な実施形態によるモバイル・デバイス１８の別の簡略構成図である。図４に示すように、モバイル・デバイス１８は、図３に関して説明した部品と同様のものを含み、同様に付番してある。例えば、図４に示すように、モバイル・デバイス１８は、接触感応スクリーン４５も含み、これをスタイラス４６と共に用いて、所定のユーザ入力機能を実行するために用いることができる。尚、図３および図４に示すモバイル・デバイス用ディスプレイ４５は、互いに同一サイズとすることも互いに異なるサイズとすることも可能であるが、通常は、デスクトップ・コンピュータと共に用いる従来からのディスプレイよりは遥かに小型であることを注記しておく。例えば、図３および図４に示すディスプレイは、２４０×３２０座標、または１６０×１６０座標、またはその他のいずれかの適当なサイズのマトリクスによって定義することができる。
【００２７】
また、図４に示すモバイル・デバイス１８は、多数のユーザ入力キーまたはボタン（スクロール・ボタン４７等）も含み、ユーザは、ディスプレイ４５上に表示してあるメニュー・オプションまたはその他のディスプレイ・オプションによってスクロールすることができ、あるいは、ユーザはディスプレイ４５に接触することなく、アプリケーションを変更することができる。加えて、図４に示すモバイル・デバイス１８は、電源ボタン４９も含み、これを用いて、モバイル・デバイス１８への全体的な電力をオンおよびオフに切り替えることができるようにすることが好ましい。
【００２８】
尚、図４に示す実施形態では、モバイル・デバイスは、手書きエリア５１を含むことをも注記しておく。手書きエリア５１は、スタイラス４６と共に用い、ユーザがメッセージを書き込み、メモリ４２に格納して、モバイル・デバイス１８が後に用いるようにする。例示としての一実施形態では、手書きメッセージを単に手書き形態で格納し、後にユーザが呼び出してディスプレイ・スクリーン４５上に表示し、ユーザがモバイル・デバイス１８に入力した手書きメッセージを見直すことを可能にする。別の好適な実施形態では、モバイル・デバイス１８にはキャラクタ認識モジュールを備え、ユーザがスタイラス４６を用いてエリア５１上に英数字情報を書き込むことによって、モバイル・デバイス１８に英数字情報を入力可能とする。この場合、モバイル・デバイス１８内のキャラクタ認識モジュールは、英数字キャラクタを認識し、これらのキャラクタをコンピュータ認識可能な英数字キャラクタに変換し、これをモバイル・デバイス１８内のアプリケーション・プログラム４２が用いることができるようにする。
【００２９】
図５および関連する論述は、本発明を実現可能とするのに適したデスクトップ・コンピュータ１６の全体的な説明を手短に行うことを意図するものである。必須ではないが、本発明の説明は、少なくとも部分的に、パーソナル・コンピュータ１６またはモバイル・デバイス１８が実行するプログラム・モジュールのようなコンピュータ実行可能命令に関して概略的に行うこととする。一般に、プログラム・モジュールは、特定のタスクを実行したり、あるいは特定の抽象的データ形式を使用する、ルーチン・プログラム、オブジェクト、コンポーネント、データ構造等を含む。更に、本発明は、マルチプロセッサ・システム、マイクロプロセッサを用いた消費者用電子機器またはプログラム可能な消費者用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ等を含む、その他のコンピュータ・システム・コンフィギュレーションとでも実施可能であることを当業者は認めよう。また、本発明は、分散型計算機環境において、通信ネットワークを通じてリンクしたリモート処理デバイスによってタスクを実行するという実施も可能である。分散型計算機環境では、プログラム・モジュールは、ローカルおよびリモート・メモリ記憶装置双方に配置することができる。
【００３０】
図５を参照すると、デスクトップ・コンピュータ１６を実現するためのシステム例は、従来のパーソナル・コンピュータ１６の形態とした汎用計算機を含み、演算装置４８、システム・メモリ５０、およびシステム・メモリ５０から演算装置４８までを含む種々のシステム・コンポーネントを結合するシステム・バス５２を含む。システム・バス５２は、種々のバス・アーキテクチャのいずれかを用いたメモリ・バスまたはメモリ・コントローラ、周辺バス、およびローカル・バスを含む、数種類のバス構造のいずれでもよい。システム・メモリ５０は、リード・オンリ・メモリ（ＲＯＭ）５４、およびランダム・アクセス・メモリ（ＲＡＭ）５５を含む。起動中等においてデスクトップ・コンピュータ１６内のエレメント間の情報転送に供する基本ルーチンを収容する基本入出力システム（ＢＩＯＳ）５６は、ＲＯＭ５４に格納してある。また、デスクトップ・コンピュータ１６は、ハード・ディスク（図示せず）の読み取りおよび書き込みを行うハード・ディスク・ドライブ５８、リムーバブル磁気ディスク５９の読み取りおよび書き込みを行う磁気ディスク・ドライブ５８、ならびにＣＤ−ＲＯＭまたはその他の光媒体のようなリムーバブル光ディスク６１の読み取りおよび書き込みを行う光ディスク・ドライブ６０も含むことができる。ハード・ディスク・ドライブ５７、磁気ディスク・ドライブ５８、および光ディスク・ドライブ６０は、ハード・ディスク・ドライブ・インターフェース５２、磁気ディスク・ドライブ・インターフェース６３、および光ディスク・ドライブ・インターフェース６４によって、それぞれシステム・バス５２に接続してある。これらのドライブおよびそれに関連するコンピュータ読み取り可能媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、およびデスクトップ・コンピュータ１６用のその他のデータの不揮発性格納を行う。
【００３１】
ここに記載する環境の一例は、ハード・ディスク、リムーバブル磁気ディスク５９およびリムーバブル光ディスク６１を採用するが、磁気カセット、フラッシュ・メモリ・カード、ディジタル・ビデオ・ディスク（ＤＶＤ）、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）等のような、コンピュータによるアクセスが可能なデータを格納することができる、他の種類のコンピュータ読み取り可能媒体も、動作環境の一例において使用可能であることは、当業者には認められよう。
【００３２】
多数のプログラム・モジュールを、ハード・ディスク、磁気ディクス５９、光ディスク６１、ＲＯＭ５４またはＲＡＭ５５上に格納することができ、オペレーティング・システム６５、（ＰＩＭを含むこともできる）１つ以上のアプリケーション・プログラム６６、（同期コンポーネント２６を含むこともできる）その他のプログラム・モジュール６７、およびプログラム・データ６８を含む。ユーザは、キーボード７０、ポインティング・デバイス７２およびマイクロフォン７４のような入力デバイスによって、コマンドおよび情報をデスクトップ・コンピュータ１６に入力することができる。他の入力デバイス（図示せず）として、ジョイスティック、ゲーム・パッド、衛星ディッシュ（ｓａｔｅｌｌｉｔｅ  ｄｉｓｈ）、スキャナ等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、システム・バス５２に結合してあるシリアル・ポート・インターフェース７６を介して、演算装置４８に接続しているが、サウンド・カード、パラレル・ポート、ゲーム・ポートまたはユニバーサル・シリアル・バス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ）のようなその他のインターフェースによって接続することも可能である。モニタ７７または別の種類の表示装置も、ビデオ・アダプタ７８のようなインターフェースを介して、システム・バス５３に接続する。モニタ７７に加えて、デスクトップ・コンピュータは、通常、スピーカ７５やプリンタのような、その他の周辺出力デバイスを含むこともできる。
【００３３】
デスクトップ・コンピュータ１６は、リモート・コンピュータ７９のような１つ以上のリモート・コンピュータ（モバイル・デバイス１８以外）への論理接続を用いて、有線またはワイヤレス・ネットワーク環境で動作することも可能である。リモート・コンピュータ７９は、別のパーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス、またはその他のネットワーク・ノードとすることができ、通常、デスクトップ・コンピュータ１６に関して先に記載したエレメントの多くまたは全てを含むが、メモリ記憶装置８０だけを図４に示す。図４に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）８１およびワイド・エリア・ネットワーク（ＷＡＮ）８２を含む。このようなネットワーク環境は、事務所、企業規模のコンピュータ・ネットワーク・イントラネットおよびインターネットでは一般的である。
【００３４】
ＬＡＮネットワーク環境で用いる場合、デスクトップ・コンピュータ１６は、ネットワーク・インターフェースまたはアダプタ８３を介して、ローカル・ネットワーク８１に接続する。ＷＡＮネットワーク環境で用いる場合、デスクトップ・コンピュータ１６は通常モデム８４またはインターネットのようなワイド・エリア・ネットワーク８２上で通信を確立するその他の手段を含む。モデム８４は、内蔵型でも外付け型でもよく、シリアル・ポート・インターフェース７６を介してシステム・バス５２に接続する。ネットワーク環境では、デスクトップ・コンピュータ１６に関して図示したプログラム・モジュールまたはその一部を、リモート・メモリ記憶装置に格納することも可能である。図示のネットワーク接続は一例であり、コンピュータ間に通信リンクを確立するその他の手段も使用可能であることは認められよう。
【００３５】
デスクトップ・コンピュータ１６は、通常不揮発性メモリ５４に格納してあるオペレーティング・システム６５を走らせ、演算装置４８上で実行する。適切なオペレーティング・システムの１つは、Ｗｉｎｄｏｗｓ９５またはＷｉｎｄｏｗｓ  ＮＴ、あるいはＷｉｎｄｏｗｓブランドのオペレーティング・システムの別の派生バージョンのような、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎ（マイクロソフト社）が販売するＷｉｎｄｏｗｓブランドのオペレーティング・システム、あるいはそれ以外の適切なオペレーティング・システムである。他の適切なオペレーティング・システムには、Ａｐｐｌｅ  Ｃｏｒｐｏｒａｔｉｏｎ（アップル社）が販売するＭａｃｉｎｔｏｓｈ  ＯＳや、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ（ＩＢＭ）が販売するＯＳ／２プレゼンテーション・マネージャのようなシステムが含まれる。アプリケーション・プログラムは、プログラム・モジュール６７、揮発性メモリまたは不揮発性メモリ内に格納することが好ましく、あるいは、フロッピ・ディスケット５９、ＣＤＲＯＭドライブ６１から図５に示すコンポーネントのいずれかにロードしたり、ネットワーク・アダプタ８３を介してネットワークからダウンロードしたり、またはその他の適当な機構を用いてロードすることも可能である。
【００３６】
動的リンク・ライブラリ（ＤＬＬ）は、複数の実行可能機能から成り、プロセッサ４８による実行のために、メモリ内のＰＩＭと関連付けてある。プロセッサ間およびコンポーネント間のコールは、コンポーネント・オブジェクト・モデル（ＣＯＭ）を用いることにより簡便化される。これは、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓブランドのオペレーティング・システム用に書かれたプログラムでは共通である。端的に言うと、ＣＯＭを用いる場合、ＤＬＬのようなソフトウエア・コンポーネントは多数のインターフェースを有する。各インターフェースは、複数のメソッドを露出（ｅｘｐｏｓｅ）させる。これらのメソッドは、個々にコールして、ソフトウエア・コンポーネントが提供する異なるサービスを利用することができる。加えて、任意に１つ以上のパラメータ引数を受け取りそして返す別のソフトウエア・コンポーネントから、メソッドまたは関数を呼び出すことを可能にするインターフェースを備える。
【００３７】
一般に、特定のＰＩＭと関連するＤＬＬは、特定的に当該ＰＩＭと共に動作し、デスクトップ同期インターフェースを露出させるように設計してある。デスクトップ同期インターフェースは、先により詳しく説明したように、同期プロトコルにしたがって機能する。一方、ＤＬＬは、ＰＩＭによって露出されたインターフェースをコールし、オブジェクト・ストア内に維持してあるオブジェクトの個々のプロパティを表わすデータにアクセスする。勿論、オブジェクト・ストア６は、図４に関して記載した適当なメモリ素子のいずれにも常駐することができる。
（アーキテクチャ・ブロック図）
図６は、モバイル・デバイス１８の機能的アーキテクチャを示すブロック図である。図６は、本明細書において既に示した構成物（ｉｔｅｍ）と同様の構成物を示す。同様の構成物には、同様に付番する。図６は、モバイル・デバイス１８が、ウェブ・コンテンツ情報を、同期コンポーネント２６、ワイヤレス受信機（無線受信機およびドライバ）２２、またはモデム２４のいずれかを通じて受信することを示す。これらのいずれの場合でも、ブロック２０２および２０４で示すように、スクリプト・テンプレートおよびデータ・ファイルだけでなくＣＤＦファイルも、最終的にキャッシュ・メモリ２０６に供給される。同期コンポーネント２６を通じてウェブ・コンテンツ情報を受信する場合、スクリプト・テンプレートおよびデータ・ファイルは、これらをワイヤレスまたはモデム・チャネルを通じて送信する場合と同様に、暗号化または符号化、あるいはその他方法によるフォーマットを行なわなくてもよい。つまり、スクリプト・テンプレート２０４およびデータ・ファイル２０２を直接キャッシュ・マネージャ２０８に供給する。キャッシュ・マネージャ２０８は、スクリプト・テンプレートおよびデータ・ファイルを受け取り、これらをキャッシュ・メモリ２０６に供給する。キャッシュ・マネージャ２０８は、メモリ操作およびタイミング・コンポーネント、ならびにデータ転送コンポーネントを含む。これらはスクリプト・テンプレートおよびデータ・ファイルをキャッシュ・メモリ２０６内における特定のロケーションに転送し、そのロケーションを追跡するのに適している。
【００３８】
一方、ウェブ・コンテンツをワイヤレス受信機およびドライバ２２またはモデム２４を通じて受信する場合、データをキャッシュする前に追加の処理ステップを行なう必要がある。ワイヤレス受信機およびドライバ２２は、メッセージを受信してフィルタリングし、モバイル・デバイスにウェイク・アップ・イベント（ｗａｋｅ−ｕｐ  ｅｖｅｎｔ）を発生する物理レイヤである。好適な一実施形態では、図８に関して以下で説明するが、送信した情報を最初に変換し（圧縮、暗号化、符号化、およびパッケージ化等）、その後に送信する。したがって、データは、モバイル・デバイス１８が使用する前に、その元の状態に再度変換しなければならない。このために、最初にデータをメッセージ・ルータ２１０に供給する。メッセージ・ルータ２１０は、メッセージを受け取り、受け取ったメッセージを変換レイヤ２０９に導出するように作用する。図６では、変換レイヤ２０９は、分解および合体コンポーネント２１２（ｕｎｐａｃｋａｇｅｒ  ａｎｄ  ｊｏｉｎｅｒ  ｃｏｍｐｏｎｅｎｔ）２１２、全体的に２１４で示す追加の変換器群、ならびに更に別のルーティング・コンポーネント２１６を含む。
【００３９】
分解および合体ブロック２１２は、送信されたパケット・グループを受け取り、アンパックし、順に並べるように作用する。分解部は、ワイヤレス・キャリア１５によって分割されたあらゆる長いメッセージのパケットを再度合体する。順に並べたデータは、変換コンポーネント２１４に供給する。
【００４０】
変換コンポーネント２１４は、データを、コンテンツ・ハンドラ２１６が処理するのに適した形態に再フォーマット即ち変換するように作用する。例えば、一旦メッセージを含むパケットを分解および合体部２１２でアンパックまたは再結合したなら、変換コンポーネント２１４は、通常これらのパケットの伸長、解読、および復号を行なうことができる。
【００４１】
コンテンツ・ハンドラ２１６は、アンパックし、合体し変換したメッセージを、モバイル・デバイス１８上の適切な登録済みの宛先（即ち、適切なアプリケーションまたはその他の機能的ブロック）に送出する。図５に示す実施形態では、コンテンツ・ハンドラ２１６は、この情報をキャッシュ・マネージャ２０８に供給し、これをキャッシュ２０６に格納する。
【００４２】
ユーザがキャッシュ２０６に格納したウェブ・コンテンツをオフラインでブラウズしたい場合、ユーザは、図５におけるチャネル・ブラウザ・ブロック２１８で示す、適当なアプリケーション・プログラムを起動する。チャネル・ブラウザ２１８は、ディスプレイ４５上で適当なユーザ・インターフェースを生成し、ユーザが所定のチャネルを選択し見ることができるようにすることが好ましい。
【００４３】
チャネル・ブラウザ２１８は、ローダブルト・ランスポート（ｌｏａｄａｂｌｅ  ｔｏｒａｎｓｐｏｒｔ）２２０と相互作用するように構成してあり、一方、ローダブル・トランスポート２２０はキャッシュ・マネージャ２０８に結合してある。ユーザが選択したチャネルを通じて供給された情報を見たいという要求に応答して、ローダブル・トランスポート２２０は、キャッシュ・マネージャ２０８に、対応するウェブ・コンテンツ情報（スクリプト・テンプレートおよびデータ・ファイルの形式）をキャッシュ２０６から検索するように要求する。所望のスクリプト・テンプレート２０４およびデータ・ファイル２０２は、キャッシュ・マネージャ２０８からローダブル・トランスポート２２０に供給する。
【００４４】
トランスポート２２０におけるスクリプト・インタープリタは、ビジュアル・ベーシック・スクリプト・インタープリタであり、スクリプト・テンプレート２０４を解釈し、データ・ファイル２０２に作用して、ウェブ・コンテンツの所望の表現を与えることが好ましい。図５に示す実施形態では、ウェブ・コンテンツは、従来のハイパーテキスト・マークアップ言語（ＨＴＭＬ）ページ２２４として表現してある。ローダブル・トランスポート２２０は、次に、ＨＴＭＬページの表現（ｒｅｎｄｅｒｉｎｇ）をチャネル・ブラウザ２１８に供給し、モバイル・デバイス１８のユーザはこれをディスプレイ４５上で見ることができる。
（情報記録）
本発明の一態様は、コンテンツ・プロバイダ１２が使用するために、所望の情報の記録（ｒｏｇｇｉｎｇ）を可能にする。言い換えると、ＣＤＦファイル内にエントリを設けることによって、コンテンツ・プロバイダは、追跡したい所定の項目にタグを付けることができる（即ち、いつ、どの位の間これらの項目がいずれかの所与のユーザによって見られたのかについて知りたい所定の項目にタグを付けることができる）。本発明は、この機能性を実現する。
【００４５】
例えば、ユーザがチャネル・ブラウザ２１８を立ち上げ、ローダブル・トランスポート２２０から情報を要求した場合、ローダブル・トランスポート２２０は、要求された情報が適切なＣＤＦタグを含み、この情報が見られた時刻および時間に関する情報をコンテンツ・プロバイダが記録したいことを示すか否かについて判定を行なう。肯定の場合、ローダブル・トランスポート２２０は、ユーザがその情報を見た時刻および時間を表わす情報を記録する。この情報は、当該特定のウェブ・コンテンツ情報に対応するキャッシュ２０６内のロケーションに格納する。
【００４６】
モバイル・デバイス１８が次回デスクトップ・コンピュータ１６と同期する場合、デスクトップ・コンピュータ１６が受信した現ウェブ・コンテンツでモバイル・デバイス１８を更新するだけでなく、デスクトップ・コンピュータ１６も、モバイル・デバイス１８が保持する現記録情報で更新する。同様に、デスクトップ・コンピュータ１６上のブラウザが次回コンテンツ・プロバイダ１２から適切なウェブ・コンテンツにアクセスする場合、記録情報をデスクトップ・コンピュータ１６からコンテンツ・プロバイダ１２に送信する。好適な一実施形態では、デスクトップ・コンピュータ１６上のブラウザはＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ４．０であるので、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ４．０のスケジューラが次回デスクトップ・コンピュータ１６上で呼び出されたときに、デスクトップ・コンピュータ１６に同期し終えた記録情報をコンテンツ・プロバイダ１２に送信する。
【００４７】
（データ構造およびフィルタリング）
図７は、無線受信機およびドライバ１０が受信するウェブ・コンテンツ・データのパケットの一実施形態を示す。無線受信機は、実質的にあらゆるフォーマットのメッセージでも受信可能であることが好ましい。多くの異なるタイプのヘッダ・フォーマットが、無線機によって受信のために定義することができる。図７は、パケット・フォーマット・タイプの一例を与えるに過ぎない。
【００４８】
パケット２３０は、無線トランスポート・ヘッダ２３２、グループおよびトピック・フィルタリング・バイト２３４、ルーティング・ヘッダ２３６、およびデータ２３８というような複数の部分を含むことが好ましい。無線トランスポート・ヘッダ３２３は、アドレス情報を含むことが好ましい。アドレス情報は、無線メッセージを無線受信機２２（またはその他のいずれかの同様のタイプの無線カード）に送る際に用いる識別子である。例えば、１つの一般的な商業的に入手可能なページング伝送プロトコルでは、無線トランスポート・ヘッダ２３２内のアドレス情報は、キャップコード（ｃａｐｃｏｄｅ）を備えている。キャップコードとは、アドレシング情報を格納してある、物理的ハードウエア無線カード・デバイス２２上の格納ロケーションのことである。無線トランスポート・ヘッダ２３２は、好適な一実施形態では、１６個の異なるアドレスに対応する。無線受信機およびドライバ２２は、アドレスのいずれにも一致しないメッセージを全てフィルタリングし破棄する。一致が認められた場合、無線受信機２２は、潜在的にそれにアドレスされた可能性があるメッセージを検出し、そのメッセージを受信し更に処理しなければならない。次に、メッセージをメッセージ・ルータ２１０に渡し、変換レイヤ２０９と共に、メッセージを処理するためには、モバイル・デバイス１８上のどのコンポーネントが必要かについて判定を行なう。
【００４９】
グループおよびトピック・フィルタリング・バイト２３４も備えることが好ましい。ここで言うグループとは、本発明にしたがってアドレスのフィルタリング機能を拡張するために用いる、アドレスのサブクラスのことである。更に、トピックとはグループのサブクラスであり、これもアドレスおよびグループ情報のフィルタリング機能を拡張するために設けたものである。
【００５０】
尚、無線受信機およびドライバ２２に適切なアドレスと共に到達したメッセージには、前もってグループおよびトピック・フィルタリング・バイト２３４が添付されていない場合もある。しかしながら、これらのバイトがある場合、無線受信機およびドライバ２２内のドライバは、グループおよびトピック・フィルタリング・バイトに基づいて、メッセージをフィルタリングするように動作する。
【００５１】
無線受信機およびドライバ２２内のドライバは、最初にパケット２３０を検査してパケット２３０内にいずれかのグループおよびトピック・フィルタリング・バイト２３４が含まれているか否かについて判定を行なうロジックを実装する。好適な実施形態では、無線受信機およびドライバ２２内のドライバは、関数ＡｎａｌｙｚｅＭｅｓｓａｇｅ（）を含むライブラリに対応する。ＡｎａｌｙｚｅＭｅｓｓａｇｅ関数は、着信メッセージにおいて、サービス・グループ・コードおよびその他の情報を孤立させる。グループおよびトピック・フィルタリング・バイトがある場合、グループおよびトピック・フィルタリング機能を実行しなければならない。
【００５２】
好適な実施形態では、モバイル・デバイス１８は、グループ・テーブルを収容するメモリを含む。これについては、先に本願にも含まれるものとした出願に詳細に記載されている。端的に言うと、グループ・テーブルは、サービス・グループのエントリを収容し、その各々をいずれかの適当なアドレスと関連付けることができる。また、好ましくは、あらゆる適当な数のサービス・グループでも１つのアドレスに関連付けることができる。したがって、好適な実施形態では、グループ・テーブル内のグループ・エントリをアドレス番号でソートし、次いでサービス・グループ・コードでソートする。グループ・テーブルの好適な一実施形態の内容は、先に本願にも含まれるものとした出願に更に詳細に明記されている。
【００５３】
グループまたはトピック・フィルタリング・バイトを検出した場合、無線受信機およびドライバ２２内のドライバはグループ・テーブルを探索し、パケット２３０内で検出したサービス・グループ・コードがグループ・テーブル内にリストされているか否か、およびそれがアクティブかインアクティブかについて判定を行なう。サービス・グループ・コードがテーブル内において見つからない場合、またはそれが不活性化されている（またはディスエーブルされている）ことがわかった場合、ドライバ２２はそのメッセージを破棄し、このメッセージに関してこれ以上の処理を行なわない。しかしながら、ドライバ２２が、グループ・テーブル内にグループおよびトピック・フィルタリング・バイト２３４が含まれると判定した場合、メッセージはその特定のモバイル・デバイス１８に意図されたものであると判断し、次の処理を続ける。
【００５４】
このグループおよびトピック・フィルタリングの全てはドライバ２２のレベルで行われるので、モバイル・デバイス１８のプロトコル・スタック、即ち、システム・アーキテクチャにおいては、非常に低いところで行われる。したがって、フィルタリングはプロセスの早期に行われるので、アドレスおよびメッセージに対して必要な格納空間は非常に少ない。加えて、ドライバ自体がこのフィルタリングの多くを実行するので、グループおよびトピック・フィルタリング・バイト２３４は、モバイル・デバイス１８上で走るあらゆるアプリケーションでも、正確なフィルタリング情報をグループおよびトピック・テーブルに渡し、ドライバ２２のレベルでのフィルタリングを行なうことができる。これは、従来の設計に対して、電力消費を大幅に改善する。何故なら、メッセージは、フィルタリングされる前に、モバイル・デバイス１８のプロトコル・スタック即ちアーキテクチャにおけるアプリケーション・レベルまでの全てにおいて受信し、処理し、受け渡す必要がないからである。
（送信および変換アーキテクチャ）
図８は、ワイヤレス・プッシュ・サーバ（ＷＰＳ）コンポーネント２０からモバイル・デバイス１８へのデータ・パケットの送信を示す、更に詳細なブロック図である。ワイヤレス・プッシュ・サーバ２０は、ウェブ・コンテンツ・キャッシュ２５０、スケジューラ２５２、変換レイヤ２５４、パッケージャ（ｐａｃｋａｇｅｒ）２５６、および無線送信機２５８を含むことが好ましい。好ましくは、変換器を用いてウェブ・コンテンツに動作し（例えば、データ・ファイル、スクリプト・ファイルおよびＣＤＦファイル）、コンテンツを所望の形態で無線送信機２５８のパッケージャ２５６に供給し、モバイル・デバイス１８に送信する。図８に示す実施形態では、変換レイヤ２５４は、圧縮部２６０、暗号化部２６２およびエンコーダ２６４を含む。
また、図８は、モバイル・デバイス１８の一部も更に詳細に示す。同様の構成物には、図６に示したものと同様に付番してある。しかしながら、図８は、変換レイヤ２０９を更に詳細に示す。変換レイヤ２０９は、所望の数およびタイプの変換器を含み、ＷＰＳ２０上の変換レイヤ２５４において行われる変換の逆を行なうように動作することが好ましい。したがって、図８に示す実施形態は、アンパッケージャ（ｕｎｐａｃｋａｇｅｒ）２１２、デコーダ２６６、暗号化部２６８、および伸長部２７０を含む。
【００５５】
動作において、スケジューラ２５２は周期的にウェブ・コンテンツ・キャッシュ２５０にアクセスし、更新または追加のウェブ・コンテンツをモバイル・デバイス１８に供給する。最初に、この情報を変換レイヤ２５４に供給する。変換レイヤ２５４内の各変換器は、着信データに対して変換動作を実行し、ヘッダまたはタグのような識別子をデータ出力に添加することにより、実行した変換のタイプを示すことが好ましい。例えば、好適な実施形態では、スケジューラ２５２がウェブ・コンテンツ・キャッシュ２５０から抽出した（そして、スケジューラ２５２が変換レイヤ２５４のために準備した）ウェブ・コンテンツの一部を、最初に圧縮部２６０に供給する。圧縮部２６０は、それが受け取った情報のブロッブ（ｂｌｏｂ）を圧縮し、４バイトのヘッダを添加し、データを圧縮するために用いた圧縮方式を識別する。圧縮は、暗号化の前に行なうことが好ましい。何故なら、純粋なテキストの方が通常暗号化されたテキストよりも高い圧縮が可能であるからである。
【００５６】
暗号化部２６２は、圧縮部２６０から圧縮データを受け取り、圧縮部２６０の出力を暗号化し、更に４バイトのヘッダを添加し、このデータを暗号化するために用いた暗号化方式を識別する。次に、暗号化部２６２は、暗号化したデータをエンコーダ２６４に供給する。
【００５７】
エンコーダ２６４は、暗号化部２６２の出力を符号化し、データ・ストリームを、選択したワイヤレス媒体上での送信に適したキャラクタから成るストリームに変換する。例えば、ワイヤレス媒体が従来のページング・チャネルである場合、エンコーダ２６４はデータを、印刷可能なＡＳＣＩＩキャラクタのみから成るストリームに符号化し、ワイヤレス・リンクを通じて送信可能とする。また、エンコーダ２６４も４バイトのヘッダをデータに添加し、データを符号化するために用いた特定の符号化方式を識別する。
【００５８】
先に詳細に説明したように、パッケージャ２５６はエンコーダ２６４の出力を、ワイヤレス・リンクを通じた送信に適した、小型化したパッケージに分割する。パッケージャ２５６はデータ・パケットの前にヘッダを添加するので、情報の受信機によってパケットを一意に特定することができる。例えば、変換レイヤ２５４に入力したデータを最初に圧縮し、次いで暗号化し、符号化した場合、エンコーダ２６４の出力は、
（Ｅｎｃｏｄｉｎｇｓｃｈｅｍｅ、［ＥｎｃｒｙｐｔｉｏＩＤ  ｛ＣｏｍｐｒｅｓｓｉｏｎＩＤ，Ｄａｔａ｝］）によって表わすことができる。
【００５９】
したがって、パッケージャは前述のデータを取り込み、概略的に図７に示した形態のパッケージを生成する。これは、
｛Ｈｄｒ，ｄａｔａ｝、｛Ｈｄｒ，ｄａｔａ｝．  ．  ．［Ｈｄｒ，ｄａｔａ｝
によって与えられる。
【００６０】
パッケージャ２５６（変換器として見ることも可能である）は、データおよびヘッダを無線送信機２５８に供給し、無線変換器２５８はデータを無線受信機およびドライバ２２に送信する。即ち、パッケージャ２５６はコンテンツ・プロバイダ１２からの入力データを、特定のキャリアに応じて約１２８ないし５００バイトの間のいずれかのサイズの多数のパケットに分解する。各パケットは、インターネット、電子メール、ワイヤレス・キャリアを通じて、またはモデムを介してというようにして、ページング・ゲートウェイ（例えば、無線送信機２５８）に送られる。パッケージは、どのような順序でもページャ・チャネルまで送ることができる。
【００６１】
一実施形態では、各レコードまたはパケットは、パケット・ヘッダ情報の１１〜２３バイト、および概略的に図７に示すパケット２３０の形態のＮバイトのパケット・データ情報を収容する。パケット・ヘッダ情報内の無線トランスポート・ヘッダは、ＩＰアドレス、シーケンス番号、パケット番号、およびオプションのヘッダ数（例えば、グループおよびトピック・フィルタリング・バイト２３４ならびにルーティング・ヘッダ２３６）を含むことが好ましい。
【００６２】
ＩＰアドレスは、サービス・プロバイダのアドレスである。シーケンス番号は、送信するパケット・ストリームに対する特定のシーケンス番号を与える。ＩＰアドレスおよびシーケンス番号（の組み合わせ）は、パケット・ストリームに一意の識別を与え、モバイル・デバイス１８のような受信機が、多重化して到達した多数のパケット・ストリームを組み立てることを可能にする。
【００６３】
無線受信機およびドライバ２２は、先に論じたように、データをフィルタリングし、受信対象のデータをルータ２１０に供給する。ルータ２１０は、各パケット上のヘッダ情報を検査する。ヘッダ情報は、ルータに、データに動作するためには変換器を呼び出す必要があるか否かについての指示を与える。図８に示す実施形態では、変換器２１２，２６６，２６８および２７０は、単に、変換器２５６，２６０，２６２および２６４として、逆の順序で備えている。ルータは、これらの変換器の動的リンク・ライブラリ（ＤＬＬ）を参照して、使用可能な変換器全てのテーブルを維持する。４バイトのヘッダまたはタグを用いて、適切な変換器を突き止める。変換器は、このタグを除去し、変換したデータをディスパッチまたは返送する役割を担う。
【００６４】
変換器の多くは、変換器の出力を別の変換器に供給することができる、変換器チェーンの一部である。これによって、コンテンツ・プロバイダに柔軟性を持たせることができる。何故なら、これらは一連の変換器を、必要性または特定のデータに応じて変更できるからである。しかしながら、変換器を備えると、システムのどこかに出力を置き、これによって変換チェーンを断ち切るという意味では、入力を浪費するということもあり得る。
【００６５】
ルータは、終端する変換器の１つによってアーティクル（ａｒｔｉｃｌｅ）が使い尽くされるまで、変換器に印加し続ける。好適な一実施形態では、残りのタグまたはヘッダが見つからず、アーティクルがまだ使い尽くされていない場合、データを電子メール・インボックス２７２に渡す。
【００６６】
このように、ルータ２１０は、第１データ・パケットを得て、これをアンパッケージャ２１２に供給し、アンパッケージャ２１２から分解し合体したデータを再度受け取る。これは、パケットを順番を外して受け取り、多数のストリームを（異なるコンテンツ・プロバイダまたは同じコンテンツ・プロバイダから）受け取ることができる。つまり、アンパッケージャ２１２は、単純なファイル・システムを実現し、ファイルは、パッケージ化の前に、送られた完全なデータを含む。
【００６７】
ファイル名は、サービス・プロバイダのＩＰアドレス、およびシーケンス番号で形成され、パッケージ・ストリーム・シーケンス・メンバを示すことに加えて、この特定のパッケージが、送信されたシーケンスの内最後のパケットであるか否かについても示す。パケットは、分解および合体部２１２によって受け取られ、整順リンク・リスト内に格納される。
【００６８】
無線受信機およびドライバ２２は、完全な情報ページを受け取り、バッファする。次いで、このページをメッセージ・ルータ２１０に渡し、ページをファイルに書き込む。次に、ルータ２１０は、分解および合体部２１２をコールする。パッケージは、所与のパケット内に含まれるＩＰアドレスおよびシーケンス番号の組み合わせから名称を取ったファイルに添付される。ファイルがまだ存在しない場合、アンパッケージャ２１２が新たに作成する。
【００６９】
最後のパッケージと印されたパッケージを受け取った場合、アンパッケージャ２１２は、どれ位のパケットがあるか把握している。最後のパケットは時間的に最後に到達する必要はないことを思い出されたい。アンパッケージャ２１２は、既に受け取ったパッケージの数を格納し、予期するパッケージ数をカウンタに格納する。複製でないパッケージを添付する毎に、カウンタを減数する。ゼロになったときには、全てのパッケージを受け取り終えている。次に、アンパッケージャ２１２は、インデックス・ファイル全体を調べる。このインデックス・ファイルは、アンパッケージャ２１２が作成し、受け取ったパッケージの順序を示すタイム・スタンプを収容している。アンパッケージャは、正しい順序でデータ・ファイルを作成し、データ・ファイルを渡し、更に処理を進める。
【００７０】
全てのパケットが到達し終えたら直ちに、整順リンク・リストを収容するデータ・ファイルを、アンパッケージャ２１２内のファイル・システムから取り出し、変換レイヤ２０９内の追加の変換器に渡すか、あるいは逆にルータ２１０に渡す。
【００７１】
失われたパケット、複製パケット、および誤りパケットに対処するために、データ・バイトのファイル全体に対して（即ち、ヘッダ・バイトは全て除外する）、循環冗長コード−３２（ＣＲＣ−３２）を用いたチェックサム・エラー検出方法を実施する。
【００７２】
失われたパケットを検出するために、インデックス・ファイル内の失われた受信パケットのタイム・スタンプを記録する。アンパッケージャ２１２は、現データ・ファイルまたは他のあらゆるデータ・ファイルのパケットを処理する毎に、このタイム・スタンプをチェックする。現時点と最後に受信したパケットの時点との間の時間差が所望の分数（または他のいずれか適当な時間間隔）を超過する場合、データ・ファイルの残りパケットのいずれかが失われたか、あるいはデータ・ファイルが削除されたと想定する。
【００７３】
複製パケットを検出するには、当該パケットに対して初期化したエントリを既に有するインデックス・ファイルを参照する。複製パケットに対処するには、２つの選択肢を実施することができる。第１に、新たなパケットを破棄し、古い方のパケットを保持することができる。第２に、最初の（即ち、古い）パケットのインデックス・エントリに上書きすることによって、新たなパケットをデータ・ファイルに添付することができる。
【００７４】
いずれの場合でも、図８に示す例を終了するには、一旦パッケージをアンパックし合体し終えたなら、ルータ２１０はデータ上のヘッダを検査し、データを最初にデコーダ２６６に供給しなければならないことを発見する。デコーダ２６６はデータを復号し、これを逆にルータ２１０に供給する。データ上の次のヘッダをルータ２１０が検査し、データを解読部２６８に供給する必要があることを示す。解読部２６８は、データを解読し、次いでこれをルータ２１０に返す。次に、ルータ２１０は、解読したデータと共に残っているヘッダ情報に基づいて、データを伸長部２７０に供給する。伸長部２７０は、データを伸長し、これをルータ２１０に返すか、あるいはルータ・コンポーネント２１６に供給する。ルータ・コンポーネント２１６は、そのデータの具体的な宛先を特定する。好適な実施形態では、ルーティング・コンポーネント２１６は、ウェブ・コンテンツ・キャッシュ２０８、および電子メール・インボックス２７２に結合してある。勿論、他の宛先も備えることができる。
【００７５】
変換器の具体的な実施態様の１つが、例示の圧縮、暗号化、および符号化変換器の更に詳細な説明と共に、先に引用した同時係属中の米国特許出願に示されている。これらは、この言及により、補足試料Ａと同様、本願にもその全てが含まれるものとする。
【００７６】
このように、コンテンツを別個のスクリプト・テンプレートおよびデータ・ファイルに分離することによって、本発明は、経済的かつ効率的に、低ビット・レート・チャネルを通じてコンテンツをモバイル・デバイスに配信することを可能にする。ＨＴＭＬページ全体の代わりに、小さなデータ・セグメントを配信することができる。また、本発明は、効率的に記録およびフィルタリングを行なうことができる機構も提供する。
【００７７】
以上、好適な実施形態を参照しながら本発明について説明したが、本発明の精神および範囲から逸脱することなく、形態および詳細において変更が可能であることを当業者は認めよう。
【００７８】
補足試料
モバイル・チャネル・スクリプティング環境
モバイル・チャネル・スクリプティング・モデルは、ＩＩＳにおいて規定されているように、アクティブ・サーバ・ページ（ＡＳＰ）を基本とする。ＡＳＰコードは、ＶＢＳで書かれている。モバイル・チャネルでは、ＡＳＰおよびＶＢＳ双方を縮小し、Ｗｉｎｄｏｗｓ  ＣＥデバイスの制約に適合させている。ストリームラインＡＳＰは、ポケットＡＳＰ（ｐＡＳＰ）としても知られている。ｐＡＳＰおよびＶＢＳを併せて、モバイル・チャネル・スクリプティング環境と呼ぶ。ここに提示する論述は、モバイル・チャネル用ｐＡＳＰ／ＶＢＳとアクティブ・チャネル用ＡＳＰ／ＶＢＳとの間の相違を中心に行なう。
タイプ
モバイル・チャネル・スクリプティングには、３つの正しいデータ・タイプ、STRING,  NUMERIC,  およびBOOLEANがある。しかしながら、内部で対応するのはSTRINGのみである。他の２つは、STRINGから派生する。ストリングの文字は、二重引用符記号（“）を用いて、表現を括弧内に入れることによって指定することができる。数値ストリングは、引用符なしで指定することができる。数値は、整数のみが可能であり、その値の範囲は、−３２，７６８ないし３２７６７である。ブール表現は、真については１、偽については０と評価する。これらは、Ｖｉｓｕａｌ  Ｂａｓｉｃにおけるように、TRUEまたはFALSEに割り当てなくてもよい。例えば、
【表１】
0004404480.tif 000002
データ構造
モバイル・チャネルは、以下のデータ構造に対応する。
【表２】
0004404480.tif 000003
キーワード
以下のキーワードを予約してあり、変数名として用いることはできない。
If, Then, Else, Elself, End If
For, Next, Do While, Loop, Exit For, Exit While
Set, Response, Request, MobileChannels
Now, LocDate, Len, Mid, Split, Asc, Chr, StrComp, Random
コメント
コメントは、単一引用符（‘）から始まり、ライン上のどこに現れてもよい。ＶＢＳのＲＥＭは、モバイル・チャネル・スクリプティングに対応しない。以下にコメントの例を示す。
' this is an example comment.
演算子および優先度
【表３】
0004404480.tif 000004
表現は、演算子の優先度にしたがって評価する。優先度が高い演算子（１が最高）が最初に評価を受ける。同じレベルの演算子は、左から右に評価する。優先度は、ネストすることができる括弧を用いて無視することができる。最も内側にある括弧を最初に評価する。
ＶＢＳの場合とは異なり、ステートメント内の表現は全て、常に表かされる。以下の例では、arr.countが０より大きくない場合、arr(1)およびarr(2)を評価し、arr(j)に対する引用の結果、エラーとなる。
If arr.count>0 and arr(1) = "foo" then
arr(2) = "bar"
End If
最初の論理表現が偽の場合、続く表現は無効となる。正しい実施は次のようにしなければならない。
If arr.count > 0 then
If arr(1) = "foo" then
arr(2) = "bar"
End If
End If
特殊キャラクタの回避
二重引用符のような特殊キャラクタは、バック・スラッシュ・キャラクタ（＼）をその前に置くことにより、ストリング文内では「回避」することができる。バック・スラッシュ・キャラクタは、同様にそれを回避することによってストリング内に含めることも可能である。例えば、
"This is a string that contains \"double quates\"."
"This is a string that contains back slshes as in a file path:
\\c:\\windows."
ステートメント
モバイル・チャネル・スクリプティング環境では、５つのステートメント・クラスがある。
割り当て
割り当てステートメントは、以下の形態とする。
<variable> = <expression>
条件
Ifステートメントが制御の条件付きフローを与える。End If部分が必要である。論理表現の後のステートメントは、論理表現が真（１）と評価しなければ、評価しない。条件ステートメントは、以下の形態の１つとすることができる。
If <logical expression> Then
<statement>
End IF
または
If <logical expression> Then
<statement1>
Else
<statement2>
End If
または
If <logical expression1> Then
<statement1>
ElseIf <logical expression2> Then
<statement2>
End If
または
If <logical expression1> Then
<statement1>
ElsIf <logical expression2> Then
<statement2>
Else
<statement3>
End If
ループ
ループ・ステートメントには、For/NextおよびDo/Whileという２つのタイプがある。
Forループは、最初に変数を数値表現１に設定し、この値をステップ量（表現３）だけループを通過する毎に増分することによって、ループを繰り返し通過する。オプションのステップ・クロースを省略すると、ステップ１のデフォルト・クロースが呼び出される。ループは、変数が表現２よりも大きな値に達したときに終了する。
For <variable>=expressionl> To <expression2> [Step <expression3>]
<statements1>
(Exit For) ' optional
<statements2>
Next
Do Whileループは、論理表現logExpressionが偽（０）になるまで、ループを続ける。Exitステートメントが、正常な終了基準を満たさなくても、ループを終了する方法を与える。Exitがあった場合、ループは途切れ、ループ直後のステートメントから実行を再開する。Exitは通常条件文と共に用いる。
Do while <logExpression>
<statements1>
(Exit while) 'optiona
<statements2>
Loop
アクティブ・サーバ
アクティブ・サーバ・ステートメントは、ResponseおよびRequestのようなｐＡＳＰオブジェクトのメソッドを引用する。Response.Writeステートメントは、出力をＨＴＭＬストリームに返す。例えば、
Response.write ("<A Href=MCTP://MSNBC/ch2> Click here to jump to Sports </A>").
モバイル・チャネル・スクリプティング環境は、所定のサーバ変数を露出させる。Request.Server Variablesステートメントを用いてサーバ変数を問い合わせることができる。これは、名称ストリング表現を取り、その名称に関連する値ストリング表現を返す。したがって、
newURL=Request.ServerVariables("URL")
は、ページのチャネルに対してループＵＲＬを得る。更に、
platStr=Request.ServerVariables("platform")
は以下の１つとしてプラットフォーム・ストリングを返す。
【表４】
0004404480.tif 000005
同様に、Request.QueryStringステートメントは、ＵＲＬの一部として、ページに渡される指定の引数の値を返す。例えば、ページのＵＲＬの名称を"MCTP:msnbc/ch2? city=seattle", とすると、ステートメント
theCity = Request.QuerString("city")
は、シアトルをtheCity変数に割り当てる。
セット
Setステートメントは、変数をオブジェクトのインスタンスに割り当てる。しかしながら、モバイル・チャネル・スクリプティング環境は、MobileChannels.Utilities疑似オブジェクトのみに対応する。したがって、Setステートメントの使用だけで、MobileChannels.Utilitiesオブジェクトを作成し、それにインスタンス変数を割り当てる。
set mc#variable = Server.Create("MobileChannels.utilities")
ステートメントを評価する際、ライン・ブレークを無視する。したがって、ステートメントは１行を超えて包むことができる。ステートメント連続記号("#")を推奨するが、必須ではない。例えば、
MyVar = "This is an example of "  &#
"a statement appearing " &
"on multiple lines."  MyVar
関数
以下の関数が、モバイル・チャネル・スクリプティング環境において露出する。
Now
今現在の日付および時刻を返し、引数を取らない。例えば、
Response.Write("Today's date is "& Now).
LocDate
現領域設定値を用いて日付をフォーマットする日付を返す。例えば、
Response.Write ("Date: " & LocDate )
Len(<string>)
ストリングの長さを返す。例えば、
Len("Hello?")
は６を返す。
Mid(aStringExpression, StartNumExpression, [Length])
は、既存のストリングのサブストリングを返す。得られるサブストリングは、length個のキャラクタ長を有し、元のストリング表現において、Startキャラクタ番号（０ではなく、１から計数する）で始まる。例えば、
Foo = Mid("This is my String", 9, 2).
Fooはここでは"my"にセットされる。
Split(aStringExpression, delimiterStringExpression)
は、指定したデリミッタに基づいて、ストリングを解析し、サブストリングに分解する。結果は、ストリングのアレイとして返される。例えば、
names = Split("Bob; Fred; Joe;",";")
では、次のサブストリングが得られる。
Names (0) ="Bob"
Names (l) ="Fred"
Names (2)="Joe"
Names (3)=" "
Asc(aStringExpression)
キャラクタ・ストリングを数値ＡＳＣＩＩ値に変換し、数値表現を返す。aStringExpressionが１キャラクタよりも長い場合、この関数は最初のキャラクタのＡＳＣＩＩ値のみを返す。
Chr(numericExpression)
ＡＳＣＩＩ数値を関連するキャラクタに変換し、１キャラクタ長のストリング表現を返す。例えば、１つのnewlineキャラクタを含むストリングを作成する場合、
str = Chr(10)
を用いる。
StrComp(S1, S2 [,Compare])
この関数は、２つのストリングＳ１およびＳ２を比較し、オプションとして比較モード、Compareを指定する。Compare引数は０または１とすることができる。Compareを省略すると、二進比較が行われる。
この関数は、次の値の１つを返す。
【表５】
0004404480.tif 000006
Random（range）
この関数は、０からrangeよりも１小さい値までの乱数を発生する。例えば、
num = Random(10)
は、０から９までを含む乱数を発生する。
モバイル・チャネル・スクリプティング・オブジェクト
MobileChannels.Utilitiesは、モバイル・チャネル・スクリプティング環境における疑似オブジェクトであり、ＣＤＦファイルにおいてオブジェクトのナビゲーションおよび操作を支援する。Utilitiesオブジェクトは、モバイル・チャネル・スクリプティングに多数のメソッドを提供する。これらのメソッドを以下のテーブルに纏める。
【表６】
0004404480.tif 000007
これらのサービスを用いるには、最初にSet関数を次のように用いて、Utilitiesオブジェクトをインスタンス化する。
set MC = Server.Create("MobileChannels.Utilities")
MCは、以下ではMobileChannels.Utilitiesスクリプティング・オブジェクトのショートハンドとして用いるが、オブジェクトはいずれの変数名にも割り当てることができる。
Utilitiesオブジェクトのナビゲート・メソッド
MC.Navigate()コマンドは、強力であり、頻繁に用いられ、ｐＡＳＰにおいて群を抜いて最も重要なメソッドである。これは、実行時に、ＣＤＦにおいて表現されるモバイル・チャネルの構造を検査するのを助けるために指定する。このコマンドのビヘービャを理解するために、背景および用語に関する短い論述を与えると役立つであろう。
Navigateコマンドの基本オペランドは、ＣＤＦファイルにおける情報の最小単位の要素である。各要素はタグと、オプションとして値とを有する。ｐＡＳＰのMC.Tag()およびMC.Value()メソッドは、いずれの要素についてもこれらのストリングを取り出すために用いることができる。要素は、ＣＤＦファイルを解析しつつ、ＸＭＬが指定するツリー構造に編成する。Navigateコマンドによって、ツリー内の特定の要素に移動したり、ある関係で要素間を移動することができる。この情報は、ＣＤＦを用いて実行時にチャネルに対してＨＴＭＬページを動的に生成するチャネル・スクリプトには非常に有用となり得る。
以下の論述では、サンプルのＣＤＦファイルおよびそれに関連する解析ツリーを頻繁に引用する。これらはこの文書の末尾に提示する。解析ツリーは、サンプルＣＤＦファイルの内部表現を示す。解析ツリーの各ラインは、要素と同等であり、全て当該要素のタグで始まる。奥に引っ込んだ要素は、それよりも前にある親の子である。同じ位置にある要素は子孫である。ＣＤＦファイルでは、例えば、BASE要素は、最上位のCHANNEL要素の子である。HREF要素はBASE要素の子孫である。INTERVALTIME要素はSCHEDULEエレメントの子である。
多くの要素は、デフォルト値を有すると見なす。これらは、解析ツリーにおいて、要素のタグに続く"=[string]"表現によって示す。デフォルト値は、次の方式で決定する。最初に、考慮対象の要素がそれに直接関連するストリングを有する場合、そのストリングがデフォルト値となる。次に、子のVALUE要素がある場合、子の値がデフォルトとなる。VALUE要素が与えられていないが、子のHREF要素がある場合、その値がデフォルト値となる。これらのいずれも見つからない場合、VALUEは空とする。例えば、最初のＩＤタグの値は直接ストリングであり、TITLEタグは明示的なVALUE要素を有するので、これを用い、最初のLOGOタグの値はそのHREFである。SCHEDULEタグは直接ストリングも、VALUEもHREFの子も有さないので、その値は空である。
Navigate関数は以下のシンタックスを有する。
NewElem = MC.Navigate( StartElem, NavAction, [,mathc])
この関数は、コマンドが指定の要素を見つけることができなかった場合、新たな要素または０を返す。
IF NOT NewElem THEN
' not found
END IF
というような標準的なＶＢＳ比較を用いて、この戻り値を検査することができる。
StartElemパラメータは、相対的な移動コマンドの基準となる開始要素である。絶対移動コマンド"Jump"を用いている場合、StartElemパラメータには""を用いなければならない。しかし、他の全ての場合には、以前のNavigate()コマンドから返された有効な要素でなければならない。
NavActionパラメータは、以下のストリングの１つでなければならない。
"Jump"
"Jump"アクションは、開始要素を得るために用いる最初のコマンドである。これは、MC.Locate()コマンド（以下を参照）と同等である。StartElemパラメータは、空のストリングでなければならない。"Jump"アクションは、供給されたＩＤによって識別されるＣＤＦにおける特定要素に直接ナビゲートする。例えば、以下のステートメント
NewElem = MC.Navigate( "", "Jump", "D1")
は、ＣＤＦファイル例における最初のデータ項目要素にジャンプする。NewElemはＩＤ要素に対するITEMの親要素である（"D1",ＣＤＦファイル例では、約半分程下にある）。
"First"
"First"アクションは、所与のレベルの最初の要素に移動する。例えば、ＣＤＦファイル例における最初のLOGO要素のID要素から、"First"アクションはそのLOGOのSTYLEタグに移動する。実際に近い場面では、このアクションを用いて、サブチャネル下のITEMリストの先頭に戻る。
NewElem = MC.Navigate( StartElem, "First")
"Out"
"Out"アクションは、現在の要素から親要素に、または解析ツリー図内の左に１つ下がった所に移動する。例えば、ＣＤＦ例のTITLE要素から、"Out"アクションは最上位のチャネル要素に移動させる。
NewElem = MC.Navigate( StartElem, "Out")
"In"
"In"アクションは、現要素の直下にある第１の子要素に移動する。例えば、ＣＤＦファイル例における最初のUSAGE要素から、"In"アクションはVALUE要素に移動させる。
NewElem = MC.(Navigate( StartElem, "In")
"Prev"
"Prev"アクションは、現要素の直前の同じレベルにある要素に移動する。同じレベルにおいて前の要素が見つからない場合、０を返し、次に親要素に行かない。例えば、ＣＤＦファイル例におけるBASE要素からの場合、"Prev"アクションは、その直ぐ前にあるHREF要素に移動させる。"Prev"をコールした場合も０を返す。何故なら、このレベルにはそれ以上子孫がないからである。
NewElem = MC.Navigate( StartElem, "Prev")
"Next"
"Next"アクションは、同じレベルの次の要素に移動する。"Prev"アクションの場合と同様、このような子孫要素が見つからない場合、０を返す。例えば、ＣＤＦファイル例では、最初のLOGOタグから、"Next"アクションは、２番目のＬＯＧＯ要素に移動する。
NewElem = MC.Navigate( StartElem, "Next")
"Match"
"Match"アクションは、指定の一致ストリングと一致するタグを有する子孫要素を発見しようとする。一致を見出すか、他の子孫が見つからなくなるまで、必要なだけの子孫を詳しく調べる。"Match"アクションが一致した要素から開始する場合、単に現要素を返す。現要素以外で照合する場合、"Match"アクションは"Next"アクションに従わなければならない。
NewElem = MC.Navigate ( StartElem, "Match", "TagTOMatch")
"InMatch"
"InMatch"アクションは、現要素の最初の子から探索を開始することを除いて、前述の"Match"と同一である。これは、囲む要素を変更する特定のサブタグを探す際に有用となり得る。例えば、以下のステートメントでは、
UsageElem = MC.Navigate( StartElem, InMatch", "USAGE" )
If UsageEl em Then
usageval = Mc.val( UsageElem )
' test for specific usage...
End If
特定の項目に対するUSAGEタグを探す。
オプションの第３パラメータを用いるアクションのみが"Match"および"InMatch"である。
Utilitiesオブジェクトのその他のメソッド
Tag
このメソッドは要素のタグ名を返す
tagString=MC.Tag(elementID)
Value
このメソッドは要素の値を返す。
valString=MC.value(elementID)
Data
このメソッドは、モバイル・チャネル・データ・ファイルからデータを獲得し、現ロケーションおよび指定されたブロック数に基づいて、名称値の対のアレイを返す。名称は、ITEMFORMATステートメントにおいて指定したフィールド名であり、値はデータ・ファイルから取り出したデータ項目（ライン）である。以下の例では、dataItemsがデータ項目を保持するアレイである。
dataItems =MC.data(elementID, blockNum)
ここで、elementIDはＣＤＦファイル内の現在のロケーション、例えば、ＭＣＤファイルのＩＤ項目であり、blockNumはこのファイル内のブロック番号である。ブロックは０から始まる。したがって、ブロックを最初に実行する際、常に（ヘッダがない場合でも）ブロック番号は１となる。その結果得られるアレイdataItemsは、ブロック内の各項目（ライン）毎に要素を含む。ブロック内の項目は、０から計数する。
各データ項目は、実際には、Tag, TypeおよびValueメソッドに対応し、それ自体のプロパティを露出するオブジェクトである。
Tag
dataItems(index)。Tagは、<ITEMFORMAT>要素内で宣言した、インデックス化したアレイ位置に対するフィールド名を返す。
Value
dataItems(index)。Valueは、インデックス化したアレイ位置に対するフィールドの値を返す。
Type
dataItems(index)。Typeは、<ITEMFORMAT>ステートメントで指定したタイプを返す。タイプがリストされていない場合、または<ITEMFORMAT>タグがない場合、Typeメソッドは"HTML"を返す。他のタイプには、"TEXT", "IMG"および"HREF"が含まれる。
【表７】
0004404480.tif 000008
Locate
この関数は次の形態を取る。
newElem = MC.Locate("ID")
そして、Navigateメソッド
newElem = MC.Navigate( "", "Jump", "ID")
の"jump"アクションに対するショートハンドである。
LibraryCall
この関数は、スクリプトがカスタムＤＬＬにアクセスし、標準的なスクリプティングでは得られない関数を実行することを可能にする。メソッドは、次の形態を取る。
Result = MC.LibraryCall( LibName, FuncName [, param]* )
最初に、メソッドはセキュリティをチェックし、ＤＬＬがｐＡＳＰスクリプティングを通じたアクセスのために適正に登録されていることを検証する。アクセス可能なＤＬＬは、ＤＬＬの名称と一致する、\HKLM\software\Microsoft\MobileChannels\Components内にレジスタ・エントリを有していなければならない。
次に、LibraryCallメソッドは、GetProcAddress関数をコールして指定の関数を参照することにより、指定のＤＬＬを動的にロードする。追加のパラメータは、そのいずれも、ＤＬＬ関数に渡す前に、整列しなければならない。８個までの任意のパラメータを渡すことができる。
ＤＬＬ関数はLPWSTR値を返さなければならない。戻り値がNULLの場合、LibraryCallはゼロ（０）を返す。それ以外の場合、ストリング自体を標準的なｐＶＢＳストリング値として返す。
Debug(Mesg)
Debugメソッドは、スクリプトの実行中にデバッグ・ストリングを書き出すことを可能にする。これは、開発中に、プログラム・フローを検査するのに役立てると有用である。デバッグ・メッセージは、OutputDebugStringＡＰＩと同様に、取り付けたいずれかのデバッガのコンソール・ウインドウに現れる。関数は何の値も返さない。
HrefExists(Href)
このメソッドは、指定のＵＲＬをキャッシュ内で見つけることができるか否かについて判定する検査を行なう。これによって、スクリプトは、失われた画像、データ要素、またはスクリプトが必要とするその他のコンポーネントを円滑に処理することができる。ＵＲＬは、完全に適正なｈｔｔｐ型ＵＲＬでなければならない。
このメソッドは、キャッシュ内で見つけられた場合には１、それ以外の場合には０を返す。
Href(Elem)
このメソッドは、ＣＤＦファイルにおいて指定された場合、指定の要素に対するＵＲＬ全体を返す。ＵＲＬを見つけることができない場合、０を返す。
IsSubscribed(ChanElem)
これは、指定のチャネルまたはサブチャネル要素をユーザが現在予約しているか否か確認するために検査する。チャネルを予約している場合１を返し、見つからない場合または予約していない場合０を返す。
注記：これは項目には作用せず、チャネルに対してのみ作用する。更に、デスクトップ上で（ＩＥ４において）走っている場合は、常に１を返す。
Title
このメソッドは、次の形態を取る。
titleString = MC.Title( ElemString )
更に、以下の手段により、所与の要素のタイトルを解読しようとする。
この要素に対する明示的なTITLEタグがある場合、その値を返す。
TITLEフィールドを指定するITEMFORMATを有する.mcdデータ項目である場合、そのデータ項目を開き、そこからタイトルを抽出する。
ＩＤ要素が与えられている場合、その値を返す。
それ以外の場合、NULLを返す。
尚、このメソッドは、タイトルを取り出す際、データ項目に「既読」の印を付けないことを注記しておく。これは、Navigateを用いてタイトルを得る場合と異なる。後者のメソッドは、ユーザが実際にそれを見ていなくても、「既読」の印を付ける。
IsUnread
このメソッドは、関連する項目またはチャネルが読み出し済みか否かを示すブーリアンを返す。
newContent = MC.IsUnread( Elem )
関数は、未読の項目上で直接コールした倍、非ゼロ値を返す。サブチャネル上でコールした場合、当該サブチャネル内の項目またはその他のサブチャネルが全く読み出されていないのであれば、非ゼロを返す。
SetUnread
このメソッドは、ある項目に対して既読／未読状態をセットし、値は返さない。更に、次のフォーマットを有する。
SetUnread(Elem [, Flag])
Elemパラメータは、以前のNavigate()またはLocate()コールからの有効な要素でなければならない。任意のFlagパラメータは、Elemの状態を印するために用いるブーリアンであり、「未読」では０、「既読」では１となる。Flagのデフォルト値は、「未読」である。
注記：モバイル・チャネルのバージョン１．０の実施態様の制限のために、画像項目には自動的に「既読」と印されない（ＭＤＣ項目では行われる）。このため、画像は、読み出されていても、「未読」と印されたままとなる。更に、親サブチャネルの全ては、その中のいずれかの画像が未読である限り、「未読」として示す。この状況を改めるために、スクリプトの著者は、各画像を表示する毎に、手作業で「未読」と印しなければならない。SetUnread()ユーティリティは、これを行なう正しい方法である。          チャネル・ブラウザおよびアクティブ・デスクトップＨＴＭＬ拡張版
ＨＴＭＬ拡張版には、アクティブ・デスクトップのために一層進んだスクリプトを各ため、およびチャネル・ブラウザにおいてデータ更新を制御するために追加の機能性を備えているものもある。
アプリケーション・リンク
Ｗｉｎｄｏｗｓ  ＣＥアクティブ・デスクトップは、ハイパーリンクからアプリケーションを立ち上げるための特殊ＨＴＭＬHrefに対応する。そのフォーマットは次の通りである。
<A HREF="mcexe://[appname]">Launch Text<A/>
appnameは、リンクをクリックしたときに立ち上げるアプリケーションの名称である。
アプリケーションは、レジストリ内の\HKLM\Software\Microsoft\Mobileにおいて.exeとして同じ名前の値を置くことによって、登録しておかなければならない。
ＭＥＴＡ  タグ
チャネル・ブラウザおよびアクティブ・デスクトップは、以下の特殊ＭＥＴＡタグを認識する。直接またはスクリプティングを介してページのヘッダ内にこれらのＭＥＴＡタグを埋込むと、特定の方法でページを自動的に処理または更新することが可能となる。尚、これらのＭＥＴＡタグ（Refreshの例外を有する）は、ＩＥ４によって無視される。
【表８】
0004404480.tif 000009
以下に各タグについて詳細に説明する。
Notify
このＭＥＴＡタグは、特定のデータベースに更新があった場合、またはキャッシュ内で特定の項目を更新した場合に、ページを自動的に更新することを可能にする。これは、ページ（またはそのコンポーネントの１つ）の新たなバージョンが同期またはその他の機構を通じて得られた場合に、自動的にページを生成し直すために用いることができる。このＭＥＴＡタグには、次の２つの形態がある。
<META HTTP-EQUIV=''Notify
CONTENT= DSUPDATE= [DBname]; URL= [RefreshUrl] ">
<META HTTP-EQUIV=''Notify
CONTENT= CACHEUPDATE= twatchurl ]; URL= [RefreshUrl] ' >
Dbnameは、更新を監視するデータベースの名称である。
WatchUrlは、キャッシュの更新を監視する項目のＵＲＬである。
RefreshUrlは、更新を検出した場合にロードするＵＲＬである。
Refresh
このＭＥＴＡタグは、指定の時間間隔後、ページを自動的に再ロードさせる。その形態は次の通りである。
<META HTTP-EQUIV="Refresh" CONTENT="[secs];URL=[RefreshUrl]">
secsは、ページを再ロードするまでの秒数をセットする。
RefreshUrlは、指定の間隔後にロードするＵＲＬである。
LaunchApp
このＭＥＴＡタグは、デバイス上のアクティブ・デスクトップのヘッダ上でクリックすることによって、アプリケーションを立ち上げることを可能にする。その形態は次の通りである。
<META HTTP-EQUIV="LaunchApp" CONTENT="[appname][?params]"
appnameは立ち上げるエクゼキュータブルの名称である。
paramsは、呼び出し時にアプリケーションに渡すparamsの任意の共通個別リストである。
アプリケーションは、レジストリ内の\HKLM\Software\Microsoft\Mobile\Channels\Componentsにおいて.exeとして同じ名前の値を置くことによって、登録しておかなければならない。
Autosize
このＭＥＴＡタグは、特定のページについて、デフォルトの画像スケーリング・ビヘービャをディスエーブルすることを可能にする。デフォルトでは、ＨＴＭＬ制御は、より小さい形状係数の画面上に表示するために、画像を調整しようとする。しかしながら、このＭＥＴＡをページヘッダ内で指定すると、画像は最大サイズで表示され、必要であれば、スクロールバーを表示させる。その形態は次の通りである。
<META HTTP-EQUI="Autosize" CONTENT="off">
尚、デフォルト値は常に「オン」であるので、CONTENTフィールドには他の値は全く必要でない。
ＣＤＦファイルの一例
<?XML version="1.0"?>
<CHANNEL
HREF="mctp://mySite/34droad/34droad.cdf "
BASE="http://mySite/" ID="34droad">
<SELF HREF="http://mysite/34droad/34droad.cdf" />
<SCHEDULE><INTERVALTIME MIN="40"/></SCHEDULE>
<USAGE VALUE=MobileChannel"/>
<TITLE>3 4 D Road</>
<ABSTRACT>Things to think about while you're away...</>
<LOGO STYLE="IMAGE" HREF= 34droad/3410go.gif" ID="LOGO"/>
<LOGO STYLE="ICON" HREF="34droad/34icon.gif" ID="ICON"/>
<CHANSCRIPT VALUE="SS"/>
<ITEMSCRIPT VALUE="SS"/>
<ITEM HREF="34droad/34.mcs" ID="SS">
<ABSTRACT>Things to think about while you're away...</>
</ITEM>
<ITEM HREF="Cgi-bin/deep1.mcd?l' ID="Dl">
<USAGE vALuE=Mobilechannel
<LDG VALUE=document:view/>
</ITEM>
<ITEM HREF=cgi-bin/deep1.mcd?2 ID="D2">
<USAGE VALUE=MobileChannel"/>
<LOG VALUE="document:view"/>
</ITEM>
<ITEM HREF="cgi-bin/deepl.mcd?3" ID="D3">
<USAGE VALUE=MobileChannel"/>
<LOG VALUE="document:view"/>
</ITEM>
<ITEM HREF="34droad/34logo.gif" ID="LOGO'>
<USAGE VALUE="None"/>
</ITEM>
<ITEM HREF="34droad/34icon.gif" ID="ICON">
<USAGE VALUE="None />
</ITEM>
<ITEM HREF="34droad/34main.gif" ID="MGIF">
<USAGE VALUE-'None"/>
<LOG VALUE="document:view"/>
</ITEM>
</CHANNEL>
ＣＤＦファイルの一例の解析ツリー
CHANNEL = mctp://mysite/34droad/34droad.cdf
HREF = mctp://mysite/34droad/34droad.cdf
BASE = http://mySite/
ID = 34droad
SELF = http://mySite/34droad/34droad.cdf
HREF = http://mySite/34droad/34droad.cdf
SCHEDULE
INTERVALTIME
MIN = 40
USAGE = Mobilechannel
VALUE = MobileChannel
TITLE = 3 4 D Road
VALUE = 3 4 D Road
ABSTRACT = Things to think about while you're away...
VALUE = Things to think about while you're away...
LOGO = 34droad/3410go.gif
STYLE = IMAGE
HREF = 34droad/3410go.gif
ID = LOGO
LOGO = 34droad/34icon.gif
STYLE = ICON
HREF = 34droad/34icon.gif
ID = ICON
CHANSCRIPT = SS
VALUE = SS
ITEMSCRIPT = SS
VALUE = SS
ITEM = 34droad/34.mcs
HREF = 34droad/34.mcs
ID = SS
ABSTRACT = Things to think about while you're away...
VALUE = Things to think about while you're away...
ITEM = cgi-bin/deep1.mcd?1
HREF = cgi-bin/deep1.mcd?1
ID = D1
USAGE = MobileChannel
VALUE = MobileChannel
LOG  document:view
VALUE = document:view
ITEM = cgi-bin/deep1.mcd?2
HREF = cgi-bin/deep1    .mcd?2
ID = D2
USAGE = MobileChannel
VALUE = MobileChannel
LOG = document:view
VALUE = document:view
ITEM = cgi-bin/deepl.mcd?3
HREF = cgi-bin/deepl.mcd?3
ID = D3
USAGE = MobileChannel
VALUE = MobileChannel
LOG = document:view
VALUE = document:view
ITEM = 34droad/3410go.gif
HREF = 34droad/3410go.gif
ID = LOGO
USAGE = None
VALUE = None
ITEM = 34droad/34icon.gif
HREF = 34droad/34icon.gif
ID = ICON
USAGE = None
VALUE = None
ITEM = 34droad/34main.gif
HREF = 34droad/34main.gif
ID = MGIF
USAGE = None
VALUE = None
LOG = document:view
VALUE = document:view
【図面の簡単な説明】
【図１】  本発明によるシステムにおけるモバイル・デバイスの一実施形態を示す簡略ブロック図である。
【図２】  図１に示すモバイル・デバイスの一実施形態の更に詳細なブロック図である。
【図３】  図２に示すモバイル・デバイスの一実施形態の簡略構成図である。
【図４】  図２に示すモバイル・デバイスの別の実施形態の簡略構成図である。
【図５】  本発明の一態様によるデスクトップ・コンピュータの一実施形態のブロック図である。
【図６】  本発明の一態様によるモバイル・デバイスの動作を示すフロー図である。
【図７】  本発明の一態様にしたがってモバイル・デバイスに送信するパケットの一般的データ構造を示す。
【図８】  ルーティングおよび変換レイヤ、ならびに本発明の一態様による伝送のためのパケットの準備を示す、更に詳細なフロー図である。
【図１】
0004404480.tif 000010
【図２】
0004404480.tif 000011
【図３】
0004404480.tif 000012
【図４】
0004404480.tif 000013
【図５】
0004404480.tif 000014
【図６】
0004404480.tif 000015
【図７】
0004404480.tif 000016
【図８】
0004404480.tif 000017