(57)【特許請求の範囲】
【請求項１】
ネットワークシステムにおいてサーバからクライアントへバイト・コードを配信するための方法であって、前記バイト・コードが第１のクラスに対応する方法において、
前記バイト・コードをヘッダとともにサーバからクライアントへ前記サーバが移送するステップと、
前記クライアント上で実行する仮想計算機によってロードすべき追加のクラスを記述した追加のクラス情報を前記ヘッダから前記クライアントが抽出するステップと、
前記ヘッダから第１のタイム・スタンプを前記クライアントが抽出するステップであって、前記仮想計算機が前記追加のクラスのローディングを開始する第１の時間を前記第１のタイム・スタンプが指定する、ステップと、
前記ヘッダから第２のタイム・スタンプを前記クライアントが抽出するステップであって、前記仮想計算機が前記追加のクラスのローディングを完了する第２の時間を前記第２のタイム・スタンプが指定する、ステップと、そして
前記第１の時間の後であって前記第２の時間の前に前記追加のクラスを前記クライアントがロードするステップであって、前記ローディングが前記仮想計算機によって遂行される、ステップと
を含む方法。
【請求項２】
ネットワークシステムにおいてサーバからクライアントへバイト・コードを配信するためにその内部で実施されるコンピュータ・プログラムを記録したコンピュータ可読媒体であって、前記バイト・コードが第１のクラスに対応するコンピュータ可読媒体において、前記コンピュータ・プログラムは、
サーバによってそのサーバからクライアントへヘッダとともに移送される前記バイト・コードを受信し、
前記クライアント上で実行する仮想計算機によってロードすべき追加のクラスを記述した追加のクラス情報を前記ヘッダから抽出し、
前記ヘッダから第１のタイム・スタンプを抽出し、前記仮想計算機が前記追加のクラスのローディングを開始する第１の時間を前記第１のタイム・スタンプが指定し、
前記ヘッダから第２のタイム・スタンプを抽出し、前記仮想計算機が前記追加のクラスのローディングを完了する第２の時間を前記第２のタイム・スタンプが指定し、そして
前記第１のタイム・スタンプによって指定された第１の時間の後であって前記第２のタイム・スタンプによって指定された第２の時間の前に前記追加のクラスをロードする
ことをコンピュータに指示するように構成されている
ことを特徴とするコンピュータ可読媒体
【請求項３】
サーバからクライアントへバイト・コードを配信するためのネットワークシステムであって、前記バイト・コードが第１のクラスに対応するネットワークシステムにおいて、
クライアントへ送信する前記バイト・コード・ファイルにヘッダを付加するように構成されたサーバであって、前記ヘッダは第１のタイム・スタンプ、第２のタイム・スタンプおよびクラス情報を含み、前記クラス情報は前記クライアント上で実行する仮想計算機によってロードすべき追加のクラスを記述し、前記第１のタイム・スタンプが前記ローディングを開始する第１の時間を指定し、そして前記第２のタイム・スタンプが前記ローディングを完了する第２の時間を指定する、サーバと、
前記ヘッダとともに前記バイト・コード・ファイルをサーバから受信するクライアントであって、前記クライアントは第１の時間の後であって第２の時間の前に前記追加のクラスをロードするように構成され、前記ローディングは前記クライアント上で実行する仮想計算機によって遂行される、ネットワークシステム。
【請求項４】
タイムリーにバイト・コードを受信し使用するための方法であって、前記バイト・コードは第１のクラスに対応し、前記バイト・コードは計算機に依存しないコードである、方法において
ネットワークを介してサーバ・コンピュータからヘッダーとともに前記バイト・コードをクライアントが受信するステップであって、前記クライアント・コンピュータ上で実行する仮想計算機によってロードすべき追加のクラスを記述した追加のクラス情報を前記ヘッダが含む、ステップと、
前記クライアント・コンピュータが第１の時間を前記ヘッダから抽出するステップと、
前記クライアント・コンピュータが第２の時間を前記ヘッダから抽出するステップと、
前記クライアント・コンピュータが前記追加のクラスのローディングを開始する前記第１の時間まで待つステップであって、前記ローディングは前記クライアント・コンピュータ上で実行する仮想計算機によって遂行される、ステップと、
前記追加のクラスのローディングが前記第２の時間までに完了したか否かを前記クライアント・コンピュータが決定するステップと、そして
前記追加のクラスのローディングが前記第２の時間までに完了したとの決定に応答して前記バイト・コードを前記クライアント・コンピュータが実行するステップであって、前記バイト・コードは前記仮想計算機によって遂行される、ステップと、
を含むことを特徴とする方法。
【請求項５】
前記バイト・コードがＪａｖａ仮想計算機仕様に一致していることを特徴とする請求項４に記載の方法。
【請求項６】
ヘッダとともに前記バイト・コードを受信する前記ステップがリアル−タイム転送プロトコル（ＲＴＰ）にしたがって遂行されることを特徴とする請求項５に記載の方法。
【請求項７】
前記追加のクラスのローディングが前記第２の時間までに完了していないときローディング遅れエラー処理を前記クライアント・コンピュータが遂行することを特徴とする請求項５に記載の方法。
【請求項８】
ユーザ・データグラム・プロトコル（ＵＤＰ）を使用してヘッダとともにデータを前記クライアント・コンピュータが受信することを特徴とする請求項５に記載の方法。
【請求項９】
前記クライアント・コンピュータが、ヘッダに含まれた識別情報に基づいて前記バイト・コードに適用すべき圧縮方式を識別し、その圧縮方式を前記バイト・コードに適用して圧縮バイト・コードを生成するステップをさらに含むことを特徴とする請求項５に記載の方法。
【請求項１０】
前記クライアント・コンピュータが、ヘッダに含まれた識別情報に基づいて前記バイト・コードに適用すべきエラー訂正方式を識別し、そのエラー訂正方式を前記バイト・コードに適用して訂正バイト・コードを生成するステップをさらに含むことを特徴とする請求項５に記載の方法。
【請求項１１】
ネットワーク・システムを介してサーバから少なくとも第１のクライアントへ配信するためのバイト・コードを用意するための方法であって、前記バイト・コードは第１のクラスに対応している方法において、
サーバがトランスポートの用意ができているバイト・コードを決定するステップと、
前記サーバが前記バイト・コードのためのヘッダを構成するステップであって、前記クライアント上で実行する仮想計算機によってロードされるべき追加のクラスを識別する追加のクラス情報を前記ヘッダは含み、また前記ヘッダは第１のタイム・スタンプおよび第２のタイム・スタンプを含み、前記第１のタイム・スタンプは前記仮想計算機が前記追加のクラスのローディングを開始する第１の時間を指定し、前記第２のタイム・スタンプは前記仮想計算機が前記追加のクラスのローディングを完了する第２の時間を指定する、ステップと、そして
前記ヘッダと前記バイト・コードをデータ・ストリームとして少なくとも前記第１のクライアントへ前記サーバが送るステップと
を含む方法。
【請求項１２】
第１のクライアントを含む複数のクライアントへマルチキャスト方式で前記ヘッダと前記バイト・コードを送るように前記サーバが構成されていることを特徴とする請求項１１に記載の方法。
【請求項１３】
ブロードキャストとして複数のクライアントへ前記ヘッダと前記バイト・コードを送るように前記サーバが構成されていることを特徴とする請求項１１に記載の方法。
【請求項１４】
コンピュータ・プログラムをコンパイルして前記バイト・コードを生成するように前記サーバが構成されていることを特徴とする請求項１２に記載の方法。
【請求項１５】
ユーザ・データグラム・プロトコル（ＵＤＰ）にしたがって前記送るステップが遂行されることを特徴とする請求項１１に記載の方法。
【請求項１６】
前記送るステップは前記第１のクライアント上で実行するブラウザ・アプリケーションからの要求の受信に応答して前記送るステップが遂行されることを特徴とする請求項１１に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータ・ソフトウェアの分野に関し、より具体的にはオブジェクト指向コンピュータ・アプリケーションに関する。
【０００２】
本特許文書の開示内容の一部は、著作権保護の対象となるデータを含む。著作権所有者は、米国特許商標庁のファイルまたは記録に現れる特許文書または特許開示をどのような人がそのまま複写してもそれに対して一切異議はないが、その他の点ではすべての著作権権利を保有する。Ｓｕｎ、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ、Ｓｕｎのロゴ、Ｓｏｌａｒｉｓ、ＳＰＡＲＣ、「Ｗｒｉｔｅ  Ｏｎｃｅ，Ｒｕｎ  Ａｎｙｗｈｅｒｅ」、Ｊａｖａ、ＪａｖａＯＳ、ＪａｖａＳｔａｔｉｏｎ、すべてのＪａｖａベースの商標およびロゴは、米国およびその他の国におけるＳｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ社の商標または登録商標である。
【０００３】
【従来の技術】
ネットワーク技術の進歩に伴い、テキスト、グラフィック、オーディオなどのメディア情報の配布を容易にするためのネットワークの使用は、特にインターネットおよびワールド・ワイド・ウェブの場合、大幅に拡大した。現在の開発努力の焦点分野の１つは、ウェブ・アプリケーションおよびネットワーク・インタラクティビティの分野である。ＨＴＭＬ定義などの受動的なメディア・コンテンツに加え、ネットワークに結合されたコンピュータ・ユーザまたは「クライアント」は、たとえば、ネットワーク上の「サーバ」から、アプレットの形のアプリケーション・コンテンツにアクセスするかまたはそれをダウンロードすることができる。
【０００４】
クライアントが使用するハードウェア・システムの多様性に対処するため、アプリケーションまたはアプレットは、ＪａｖａTMクラス・ファイル・フォーマットなどのプラットフォーム独立フォーマットで配布される。オブジェクト指向アプリケーションは、必要に応じて個別にサーバからアクセスされ、ダウンロードされる複数のクラス・ファイルから形成される。クラス・ファイルはバイトコード命令を含む。特定のハードウェア・プラットフォーム上で実行される「仮想計算機」プロセスは、個々のクラス・ファイルをロードし、内部に含まれるバイトコードを実行するものである。
【０００５】
クラス・ファイル・フォーマットとクラス・ローディング・プロセスの問題は、クラス・ファイルの適時配信を保証するためのメカニズムが一切設けられていないことである。したがって、個々のクラス・ファイルの格納、転送、処理のタイミングは、特定の時間フレーム内で発生するようにスケジュールまたは保証されない。また、１つのアプリケーションは多くのクラス・ファイルを含む可能性があり、そのすべてが別々のトランザクションでロードされ処理される。したがって、１つのクラス・ファイルであっても配信が遅れると、アプリケーションが減速し、パフォーマンスが低下する。
【０００６】
このような問題は、一般的なオブジェクト指向プログラミングの検討と、現在のネットワーク・アプリケーション環境の例から理解することができる。
【０００７】
オブジェクト指向プログラミング
オブジェクト指向プログラミングは、所与の基本構成要素を組み合わせ、構成要素間の関係を構築することにより、コンピュータ・プログラムを作成する方法である。オブジェクト指向プログラミング・システムの構成要素は「オブジェクト」と呼ぶ。オブジェクトは、データ構造（１つまたは複数のインスタンス変数）とそのデータを使用するかまたはそれを左右しうる操作（メソッド）とをまとめてグループ化するプログラミング単位である。したがって、１つのオブジェクトは、データとそのデータ上で実行可能な１つまたは複数の操作または手続きからなる。データと操作を単一構成要素に結合することは「カプセル化」と呼ぶ。
【０００８】
オブジェクトは、「メッセージ」を受け取ったときにそのメソッドの１つを実行するよう指示される。メッセージは、所与のメソッドを実行するようオブジェクトに送られるコマンドまたは命令である。１つのメッセージは、メソッド選択（たとえば、メソッド名）と複数の引数からなる。メッセージは、どの操作を実行すべきかを受取り側オブジェクトに指示するものである。
【０００９】
オブジェクト指向プログラミングの利点の１つは、メソッドを呼び出す方法である。メッセージがオブジェクトに送られる場合、メッセージが所与のメソッドを実行する方法をオブジェクトに指示する必要はない。オブジェクトがメソッドを実行することを要求することだけが必要である。このため、プログラム開発は大幅に簡略化される。
【００１０】
オブジェクト指向プログラミング言語は主に「クラス」方式に基づく。クラスベースのオブジェクト指向プログラミング方式については、Ｌｉｅｂｅｒｍａｎの「Ｕｓｉｎｇ  Ｐｒｏｔｏｔｙｐｉｃａｌ  Ｏｂｊｅｃｔｓ  ｔｏ  Ｉｍｐｌｅｍｅｎｔ  Ｓｈａｒｅｄ  Ｂｅｈａｖｉｏｒ  ｉｎ  Ｏｂｊｅｃｔ−Ｏｒｉｅｎｔｅｄ  Ｓｙｓｔｅｍｓ」（ＯＯＰＳＬＡ  ８６  Ｐｒｏｃｅｅｄｉｎｇｓ、１９８６年９月、２１４〜２２３ページ）に一般的に記載されている。
【００１１】
クラスとは、通常、そのクラス用の変数とメソッドの両方を含むオブジェクトのタイプを定義するものである。オブジェクト・クラスは、オブジェクトの特定のインスタンスを作成するために使用する。オブジェクト・クラスのインスタンスは、そのクラス用に定義された変数とメソッドを含む。１つのオブジェクト・クラスから同じクラスの複数のインスタンスを作成することができる。そのオブジェクト・クラスから作成される各インスタンスは同じタイプまたはクラスであると言う。
【００１２】
例示のため、従業員オブジェクト・クラスは、「氏名」および「給与」インスタンス変数と、「ｓｅｔ＿ｓａｌａｒｙ」メソッドとを含むことができる。従業員オブジェクト・クラスのインスタンスは、組織内の各従業員ごとに作成することができる。各オブジェクト・インスタンスは「従業員」タイプのものであると言う。各従業員オブジェクト・インスタンスは、「氏名」および「給与」インスタンス変数と、「ｓｅｔ＿ｓａｌａｒｙ」メソッドとを含む。各従業員オブジェクト・インスタンス内の「氏名」および「給与」変数に関連する値は、組織内の従業員の氏名と給与を含む。「ｓｅｔ＿ｓａｌａｒｙ」メソッドを呼び出して従業員の給与（すなわち、従業員の従業員オブジェクト内の「給与」変数に関連する値）を変更するために、従業員の従業員オブジェクト・インスタンスにメッセージを送ることができる。
【００１３】
クラスの階層は、１つのオブジェクト・クラス定義が１つまたは複数のサブクラスを持つように定義することができる。サブクラスは、その親（および祖父母など）の定義を継承する。階層内の各サブクラスは、その親クラスによって指定された挙動を拡充しまたはそれを変更することができる。一部のオブジェクト指向プログラミング言語は、１つのサブクラスが複数の親クラスからのクラス定義を継承できる多重継承をサポートしている。他のプログラミング言語は単一継承のみをサポートし、サブクラスは１つの親クラスのみのクラス定義の継承に限定される。ＪａｖａTMプログラミング言語は、１組の定数および抽象メソッド宣言を含む「インタフェース」というメカニズムも提供する。オブジェクト・クラスは、インタフェース内に定義された抽象メソッドを実装することができる。単一継承と多重継承はいずれもインタフェースにとって使用可能なものである。すなわち、インタフェースは複数の親インタフェースからのインタフェース定義を継承することができる。
【００１４】
オブジェクトは、関連コードおよび変数を含むモジュールを指すためにオブジェクト指向プログラミング環境で使用する総称である。ソフトウェア・アプリケーションは、それによりプログラムの機能性がオブジェクトによって実現されるオブジェクト指向プログラミング言語を使用して作成することができる。
【００１５】
ＪａｖａTMプログラミングおよび実行
ＪａｖａTMプログラムは複数のクラスおよびインタフェースから構成される。プログラムがマシン依存の実行可能プログラム・コードにコンパイルされる多くのプログラミング言語とは異なり、ＪａｖａTMクラスはマシン独立バイトコード・クラス・ファイルにコンパイルされる。各クラスは、クラス・ファイル・フォーマットというプラットフォーム独立フォーマットのコードおよびデータを含む。実行手段（ｅｘｅｃｕｔｉｖｅ  ｖｅｈｉｃｌｅ）として動作するコンピュータ・システムは仮想計算機というプログラムを含み、そのプログラムはＪａｖａTMクラスでそのコードの実行を担当する。仮想計算機は、バイトコード・クラスのマシンの独立性と下にあるコンピュータ・ハードウェアのマシン依存命令セットとの間のあるレベルの抽象化を可能にする。仮想計算機内の「クラス・ローダ」は、必要に応じてバイトコード・クラス・ファイルのロードを担当し、インタプリタがそのバイトコードをそのまま実行するかまたは「ジャストインタイム」（ＪＩＴ）コンパイラがそのバイトコードをマシン・コードに変換し、プロセッサによって実行できるようにする。
【００１６】
サンプルＪａｖａTMネットワーク・アプリケーション環境
図１は、ＪａｖａTMアプリケーションまたはアプレットの実行のためにＪａｖａTMクラス・ファイルにアクセスするためにネットワーク１０１によりサーバ１００に結合されたクライアント・プラットフォーム１０２を含むサンプルＪａｖａTMネットワーク環境を示すブロック図である。
【００１７】
図１のサーバ１００は、所与のアプリケーション用のＪａｖａTMクラス・ファイルを作成する際に使用するためのＪａｖａTM開発環境１０４を含む。ＪａｖａTM開発環境１０４は、クラス・ファイルを生成し、アプレットをプレビューするためのエディタおよびアプレット・ビューアなどのメカニズムを提供する。１組のＪａｖａTMコア・クラス１０３は、他の／新しいＪａｖａTMクラスを含むソース・ファイルによって参照可能なＪａｖａTMクラスのライブラリを含む。ＪａｖａTM開発環境１０４から１つまたは複数のＪａｖａTMソース・ファイル１０５が生成される。ＪａｖａTMソース・ファイル１０５は、データ構造、メソッド・インプリメンテーション、他のクラスへの参照を含むプログラマ可読クラス定義を含む。ＪａｖａTMソース・ファイル１０５はＪａｖａTMコンパイラ１０６に供給され、そのコンパイラはＪａｖａTMソース・ファイル１０５をコンパイルし、ＪａｖａTM仮想計算機によって実行可能なバイトコードを含むコンパイル済み「．ｃｌａｓｓ」ファイル１０７を作成する。バイトコード・クラス・ファイル１０７は、サーバ１００上に（たとえば、一時または永久記憶装置に）格納され、ネットワーク１０１によるダウンロード用として使用可能になる。
【００１８】
クライアント・プラットフォーム１０２はＪａｖａTM仮想計算機（ＪＶＭ）１１１を含み、その仮想計算機は、使用可能なネイティブ・オペレーティング・システム（Ｏ／Ｓ）呼出し１１２の使用により、バイトコード・クラス・ファイルを実行し、実行中に必要になったときにネイティブＯ／Ｓ呼出しを実行することができる。
【００１９】
ＪａｖａTMクラス・ファイルは、しばしばＨＴＭＬ（ハイパーテキスト・マークアップ言語）文書内のアプレット・タグで識別される。ウェブ・サーバ・アプリケーション１０８はサーバ１００上で実行され、「ウェブ・ページ」とも呼ばれるＨＴＭＬ文書へのＵＲＬ（ユニバーサル・リソース・ロケータ）を含むＨＴＴＰ（ハイパーテキスト・トランスポート・プロトコル）要求に応答する。ウェブ・サーバ１０８にＵＲＬ１０９を転送することなどにより、クライアント・プラットフォーム１０２上で実行されるブラウザ・アプリケーションがＨＴＭＬ文書を要求すると、ブラウザはＨＴＭＬ文書のアプレット・タグで識別されるクラス・ファイル１０７のダウンロードを自動的に開始する。クラス・ファイル１０７は通常、必要に応じて個別にサーバからダウンロードされ、仮想計算機１１１内にロードされる。
【００２０】
ＪａｖａTMプログラムのクラスがプログラムの実行中のできるだけ遅い時期にロードされることは一般的なことであり、それらは、ＪａｖａTMプログラムの実行中に最初に参照されたときにネットワークから（サーバ上に格納されている）またはローカル・ファイル・システムから要求があり次第、ロードされる。仮想計算機は、各クラス・ファイルを突き止めてロードし、クラス・ファイル・フォーマットを解析し、そのクラスの様々な構成要素用にメモリを割り振り、そのクラスをすでにロードされた他のクラスとリンクする。このプロセスにより、クラス内のコードは仮想計算機によって容易に実行可能なものになる。
【００２１】
適時配信
ＪａｖａTMバイト・コードまたはシリアル化オブジェクトを適時にクライアントに配信しなければならない様々なアプリケーションが存在する。たとえば、ＪａｖａTMバイト・コードを使用して、プッシュ・シナリオで時間意識の強いメディアを制御するときには、バイト・コードの適時配信を保証することは不可欠である。
【００２２】
現在、適時にバイト・コードを配信するメカニズムは一切使用されていなかった。現在、バイト・コードを配信するための技法は、伝送制御プロトコル（ＴＣＰ）を使用してサーバからクライアントにバイト・コードを伝送している。ＴＣＰは、情報の適時配信を保証するものではない。
【００２３】
メディア・ストリームとして伝送するための時間に敏感なデータ（たとえば、オーディオ、ビデオなど）を作成するために使用可能な方式（たとえば、ＭＰＥＧ−１、ＭＰＥＧ−２、ＭＰＥＧ−４などのＭｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）規格）がいくつか存在する。同様に、「時間意識の強い」メディア・ストリームを適時に配信するために、リアルタイム・トランスポート・プロトコル（ＲＴＰ）およびＭＰＥＧ−２トランスポート・ストリームのような方式がいくつか存在する。「時間意識の強い」情報とは、ある情報の使用に関連するタイミングを表す追加情報をその情報とともに伝達する情報である。たとえば、ある方法で処理されなければならないデッドラインを示すタイム・スタンプを含む情報は、「時間意識の強い」情報と見なされる。
【００２４】
しかし、このような技法は、実行可能なバイト・コードではなく、オーディオおよびビデオ・データなどのメディア・ストリームを配信するように設計されている。メディア・ストリームは通常、本質的に破損または完全性の喪失に対して抵抗力のある情報を含む。たとえば、数ミリ秒分のオーディオまたはビデオ・データが一時的に破損しても、聴取者または視聴者にとってはわずかに気が散るだけである。しかし、実行可能なバイト・コードの破損は最も軽微なものでも適切な実行を妨げる可能性がある。
【００２５】
さらに、あるクラス・ファイルのバイト・コードは、適切な実行のために他のクラス・ファイルに依存する場合が多い。メディア・ストリームの適時配信のための既存の技法は、このような依存関係に対する備えを含んでいない。したがって、バイト・コードの適時配信を可能にするための技法が必要になっている。
【００２６】
また、クラス・ファイル（またはシリアル化オブジェクト）を時間意識の強いストリームに変換するための技法も必要である。ＪａｖａTMバイト・コード・ストリームが時間意識の強いものになっている場合、ＲＴＰのような他のリアル・タイム・トランスポート・メカニズムを使用して、そのストリームを適時に移送することができるだろう。このような方式は、マルチキャストまたは同報通信シナリオでのバイト・コードの使用を促進するだろう。このため、ユーザ・データグラム・プロトコル（ＵＤＰ）のようなインターネット・プロトコルを使用してバイト・コードを伝送することが可能になるだろう。このような方式がない場合、ＵＤＰはバイト・コードの配信に不適当なものである。というのは、ＵＤＰは信頼できないプロトコル（データの配信を保証しないもの）であるからである。信頼できないプロトコルによりバイト・コードを伝送すると、バイト・コードの一部分が喪失し、それにより、バイト・コードを適切に実行できなくなるであろう。
【００２７】
【発明が解決しようとする課題】
バイト・コード・ストリームの適時配信を可能にするための方法および装置を提供することが本発明の課題である。
【００２８】
【課題を解決するための手段】
本発明により、バック・チャネルの有無に関わらずマルチキャスト／同報通信シナリオでのＪａｖａTMバイト・コードの適時配信が可能になる。同じメカニズムは、（シリアル化）オブジェクトの配信にも使用することができる。マルチキャストにより、特別にアドレス指定したデータ・ストリームを多くのユーザに伝送することができる。マルチキャストの場合、データ・ストリームは各ユーザに個別に伝送する必要がない。むしろ、ユーザは、たとえば、特別にアドレス指定したデータ・ストリームのアドレスを指定することにより、マルチキャスト・サービスに加入することができる。同報通信により、マルチキャストの加入プロセスなしにユーザに伝送することができる。
【００２９】
本発明は、ユーザが情報を要求する必要なしに情報がユーザに伝送される「プッシュ」メディアでの使用に適している。「プッシュ」メディアは、ユーザがメディアのソースに返答できるようにするためのバック・チャネルが一切設けられていない環境でも伝送することができる。また、本発明は、ユーザがメディアのソースから情報を要求する「プル」メディアでの使用にも適している。
【００３０】
本発明実施態様は、ＪａｖａTMバイト・コード（クラス・ファイル内の）を「時間意識の強いもの」にする働きをする。バイト・コードの適時配信を保証するため、コンテンツとともに適切なデッドラインがタイム・スタンプとしてクライアントに伝達される。これらのタイム・スタンプは、このような配信メカニズムを促進するためにヘッダで使用する。ヘッダはバイト・コードに付加され、バイト・コード・ストリームの適時配信を可能にする。
【００３１】
バイト・コードの適時配信で扱われる伝送態様の１つはパケット喪失である。従来の技法では、ＪａｖａTMバイト・コード・ストリーミングの場合にパケット喪失から回復する方法を一切提供していない。考えられる手法の１つは、バック・チャネルがない場合に、一定の間隔でクラス全体を再伝送するものである。これは、メディアの場合にランダム・アクセス・ポイントを促進するのに役立つだろう。しかし、これは、クライアントの数が多すぎる場合またはクラス（またはオブジェクト）が非常に大きく、再伝送が法外なものになる場合には不可能になる。
【００３２】
バック・チャネルが存在する場合、パケット喪失をサーバに通知することができ、喪失パケットを再伝送することができる。信頼できるマルチキャスト方式を使用すると、サーバ以外の場所からデータを再伝送することもできる。
【００３３】
部分パケット喪失から回復するために使用可能な、固有の冗長性を備えたエラー回復方式（ｅｒｒｏｒ  ｒｅｓｉｌｉｅｎｔ  ｓｃｈｅｍｅｓ）がいくつか存在する。たとえば、順方向エラー訂正のような方式を使用することができる。また、パケット喪失問題は、何らかの信頼できるマルチキャスト方式を使用することにより、部分的に解決することができる。本発明の実施態様は、パケット喪失を克服するために任意のエラー回復または任意の信頼できるマルチキャスト・アルゴリズムの使用を促進する。
【００３４】
扱われるもう１つの態様はセキュリティの面である。クライアントの安全を保証するため、バイト・コードは本物である必要がある。バイト・コードが本物であることを保証するために使用可能なセキュリティ方式はいくつか存在する。本発明の実施態様は、ＪａｖａTMセキュリティＡＰＩのセキュリティ・モデル内で任意のセキュリティ方式を使用することを扱う。
【００３５】
さらに他の態様は圧縮の面である。圧縮は、所与の量の情報を伝送するために必要な時間を短縮することにより、配信の効率を高める。効率のためにクラス・ファイルを圧縮するために、ＬＺＷ、ＬＺＳなどのいくつかの圧縮方式が使用可能である。
【００３６】
【発明の実施の形態】
本発明は、バイト・コード・ストリームの適時配信を可能にするための方法および装置を提供する。以下の説明では、本発明をより完全に理解できるようにするために多数の具体的な詳細を示す。しかし、当業者にとっては、このような具体的な詳細がなくても本発明を実施できることは明らかになるだろう。他の事例では、本発明を不必要に不明確にしないために、周知の特徴については詳細に記載していない。
【００３７】
コンピュータ実行環境（ハードウェア）の実施形態
本発明の実施形態は、図２に示すコンピュータ２００などの汎用コンピュータ上で実行されるコンピュータ可読プログラム・コードの形またはこのようなコンピュータ上で動作する仮想計算機によって実行可能なバイトコード・クラス・ファイルの形でコンピュータ・ソフトウェアとして実現することができる。キーボード２１０およびマウス２１１は双方向システム・バス２１８に結合されている。このキーボードおよびマウスは、ユーザ入力をコンピュータ・システムに導入し、そのユーザ入力を中央演算処理装置（ＣＰＵ）２１３に連絡するためのものである。マウス２１１およびキーボード２１０に加えまたはその代わりに、他の適当な入力装置を使用することもできる。双方向システム・バス２１８に結合されたＩ／Ｏ（入力／出力）ユニット２１９は、プリンタ、Ａ／Ｖ（オーディオ／ビデオ）Ｉ／ＯなどのＩ／Ｏ要素を表す。
【００３８】
コンピュータ２００は、ビデオ・メモリ２１４と、メイン・メモリ２１５と、大容量記憶装置２１２とを含み、いずれもキーボード２１０、マウス２１１、ＣＰＵ２１３とともに双方向システム・バス２１８に結合されている。大容量記憶装置２１２は、磁気記憶システム、光学記憶システム、または磁気光学記憶システムあるいは使用可能な他の大容量記憶技術などの固定メディアと取外し可能メディアの両方を含むことができる。バス２１８は、ビデオ・メモリ２１４またはメイン・メモリ２１５をアドレス指定するために、たとえば、３２本のアドレス線を含むことができる。また、システム・バス２１８は、ＣＰＵ２１３、メイン・メモリ２１５、ビデオ・メモリ２１４、大容量記憶装置２１２などの構成要素間でデータを転送するために、たとえば、３２ビットのデータ・バスも含む。あるいは、別々のデータ線とアドレス線の代わりに、多重データ／アドレス線を使用することもできる。
【００３９】
本発明の一実施形態では、ＣＰＵ２１３は、６８０Ｘ０プロセッサなどのＭｏｔｏｒｏｌａ（登録商標）製のマイクロプロセッサあるいは８０Ｘ８６またはＰｅｎｔｉｕｍ（登録商標）プロセッサなどのＩｎｔｅｌ（登録商標）製のマイクロプロセッサあるいはＳｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）のＳＰＡＲＣ（登録商標）マイクロプロセッサである。しかし、他のどのような適当なマイクロプロセッサまたはマイクロコンピュータでも使用することができる。メイン・メモリ２１５は、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）からなる。ビデオ・メモリ２１４は、デュアルポート式ビデオ・ランダム・アクセス・メモリである。ビデオ・メモリ２１４の１つのポートはビデオ増幅器２１６に結合されている。ビデオ増幅器２１６は、陰極線管（ＣＲＴ）ラスタ・モニタ２１７を駆動するために使用する。ビデオ増幅器２１６は、当技術分野では周知のものであり、適切などのような装置も使用できる。この回路は、ビデオ・メモリ２１４に格納されたピクセル・データをモニタ２１７が使用するために適したラスタ信号に変換する。モニタ２１７は、グラフィック・イメージを表示するのに適したタイプのモニタである。
【００４０】
本コンピュータ２００は、バス２１８に結合された通信インタフェース２２０も含んでいる。通信インタフェース２２０は、ネットワーク・リンク２２１によりローカル・ネットワーク２２２に結合する両方向データ通信を可能にする。たとえば、通信インタフェース２２０が統合サービス・ディジタル網（ＩＳＤＮ）カードまたはモデムである場合、通信インタフェース２２０は、ネットワーク・リンク２２１の一部を含む対応するタイプの電話回線へのデータ通信接続を可能にする。通信インタフェース２２０がローカル・エリア・ネットワーク（ＬＡＮ）カードである場合、通信インタフェース２２０は、ネットワーク・リンク２２１により互換性のあるＬＡＮへのデータ通信接続を可能にする。ワイヤレス・リンクも可能である。このような実施形態のいずれにおいても、通信インタフェース２２０は、様々なタイプの情報を表すディジタル・データ・ストリームを伝達する電気信号、電磁信号、または光学信号を送受信することができる。
【００４１】
ネットワーク・リンク２２１は、通常、１つまたは複数のネットワークによる他のデータ装置へのデータ通信を可能にする。たとえば、ネットワーク・リンク２２１は、ローカル・ネットワーク２２２によりホスト・コンピュータ２２３またはインターネット・サービス・プロバイダ（ＩＳＰ）２２４が運営するデータ機器へ接続することができる。ＩＳＰ２２４は、一般に「インターネット」２２５と呼ばれるワールド・ワイド・パケット・データ通信ネットワークによりデータ通信サービスである。ローカル・ネットワーク２２２およびインターネット２２５はどちらもディジタル・データ・ストリームを伝達する電気信号、電磁信号、または光学信号を使用する。様々なネットワークによる信号ならびにネットワーク・リンク２２１上および通信インタフェース２２０による信号は、コンピュータ２００との間でディジタル・データを伝達するものであり、情報を移送する搬送波の例示的な形式である。
【００４２】
コンピュータ２００は、ネットワーク（複数も可）、ネットワーク・リンク２２１、通信インタフェース２２０により、メッセージを送信し、プログラム・コードを含むデータを受信することができる。インターネットの例では、サーバ２２６は、インターネット２２５、ＩＳＰ２２４、ローカル・ネットワーク２２２、通信インタフェース２２０により、アプリケーション・プログラム用の要求されたコードを伝送するだろう。本発明によれば、このようなダウンロードされたアプリケーションの１つは、本明細書に記載するクラス・ファイルを前処理し、パッケージングするための装置である。
【００４３】
受信したコードは、受信したときにＣＰＵ２１３によって実行するか、または後で実行するために大容量記憶装置２１２または他の不揮発性記憶装置に格納するか、あるいはその両方を行うことができる。このようにして、コンピュータ２００は、搬送波の形でアプリケーション・コードを獲得することができる。
【００４４】
前述のコンピュータ・システムは、例示のみを目的とするものである。本発明の実施形態は、どのようなタイプのコンピュータ・システムあるいはプログラミング環境または処理環境でも実現することができる。
【００４５】
クラス・ファイル構造
クラス・ファイル・フォーマットの諸形態を参照すると、本発明の実施形態をより十分に理解することができる。ＪａｖａTMクラス・ファイル・フォーマットの説明を以下に示す。ＪａｖａTMクラス・ファイル・フォーマットの追加説明は、１９９６年９月にＡｄｄｉｓｏｎ−Ｗｅｓｌｅｙから発行されたＴｉｍ  ＬｉｎｄｈｏｌｍおよびＦｒａｎｋ  ＹｅｌｌｉｎのＴｈｅ  ＪａｖａTM  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（（Ｃ）Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．）の第４章「Ｔｈｅ  ｃｌａｓｓ  Ｆｉｌｅ  Ｆｏｒｍａｔ」および第５章「Ｃｏｎｓｔａｎｔ  Ｐｏｏｌ  Ｒｅｓｏｌｕｔｉｏｎ」に記載されている。
【００４６】
ＪａｖａTMクラス・ファイルは、連続する８ビット・バイトから構築した１６ビット構造、３２ビット構造、６４ビット構造の８ビット・バイトのストリームからなる。そのクラス・ファイルには、単一のクラスまたはインタフェース・ファイル構造が含まれている。このクラス・ファイル構造は以下の通りである。
【００４７】
0004397460.tif 000002
【００４８】
ただし、ｕ２およびｕ４は、符号なしの２バイト量と４バイト量を意味する。この構造については図３に図示する。
【００４９】
図３のクラス・ファイル３００は、４バイトのマジック値３０１と、２バイトのマイナー・バージョン番号３０２と、２バイトのメジャー・バージョン番号３０３と、２バイトの定数プール・カウント値３０４と、可変長要素からなる定数プール・アレイに対応する定数プール・テーブル３０５と、２バイトのアクセス・フラグ値３０６と、２バイトの「このクラス」識別子３０７と、２バイトのスーパ・クラス識別子３０８と、２バイトのインタフェース・カウント値３０９と、２バイトの要素からなるインタフェース・アレイに対応するインタフェース・テーブル３１０と、２バイトのフィールド・カウント値３１１と、可変長要素からなるフィールド・アレイに対応するフィールド・テーブル３１２と、２バイトのメソッド・カウント値３１３と、可変長要素からなるメソッド・アレイに対応するメソッド・テーブル３１４と、２バイトの属性カウント値３１５と、可変長要素からなる属性アレイに対応する属性テーブル３１６とを含む。上記の構造のそれぞれについて、以下に簡単に説明する。
【００５０】
マジック値３０１はクラス・ファイル・フォーマットを識別する番号を含む。ＪａｖａTMクラス・ファイル・フォーマットの場合、マジック番号は０ｘＣＡＦＥＢＡＢＥという値を有する。マイナー・バージョン番号３０２とメジャー・バージョン番号３０３は、クラス・ファイルの生成を担当するコンパイラのマイナー・バージョン番号とメジャー・バージョン番号を指定する。
【００５１】
定数プール・カウント値３０４は、定数プール・テーブル３０５内の項目数を識別する。定数プール・テーブル３０５は、ＣｌａｓｓＦｉｌｅ構造内で参照される様々なストリング定数、数値定数、クラス名、フィールド名、その他の定数を表す可変長データ構造のテーブルである。定数プール・テーブル内の各項目は以下の一般構造を有する。
【００５２】
0004397460.tif 000003
【００５３】
ただし、１バイトの「ｔａｇ」は特定の定数タイプを指定する。ｉｎｆｏ［］アレイのフォーマットは定数タイプに基づいて異なる。ｉｎｆｏ［］アレイは、整数定数および浮動小数点定数用などの数値、ストリング定数用のストリング値、定数プール・テーブル内の異なる定数タイプの他の項目を指すインデックスにすることができる。定数プール・テーブル構造および定数タイプの詳細については、Ｔｈｅ  ＪａｖａTM  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（上記）の第４章に記載されている。
【００５４】
アクセス・フラグ値３０６は、クラスおよびインタフェース宣言で使用する変更子からなるマスクである。「このクラス」値３０７は、このクラス・ファイルが定義するクラスまたはインタフェースを表す定数タイプ構造を指す定数プール・テーブル３０５内のインデックスである。スーパ・クラス値３０８は、そのクラスがｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔのサブクラスであることを示す０であるか、またはこのクラス・ファイルが定義するクラスのスーパクラスを表す定数タイプ構造を指す定数プール・テーブル内のインデックスである。
【００５５】
インタフェース・カウント値３０９は、このクラスまたはインタフェースの直接スーパインタフェースの数を識別し、したがって、インタフェース・テーブル３１０内の要素の数を識別する。インタフェース・テーブル３１０は、定数プール・テーブル３０５内の２バイトのインデックスを含む。定数プール・テーブル３０５内の各対応項目は、このクラス・ファイルが定義するクラスまたはインタフェースの直接スーパインタフェースであるインタフェースを表す定数タイプ構造である。
【００５６】
フィールド・カウント値３１１は、フィールド・テーブル３１２内の構造の数を示す。フィールド・テーブル３１２内の各項目は、クラス・タイプ内のフィールドの記述を示す可変長構造である。フィールド・テーブル３１２は、このクラス・ファイルが定義するクラスまたはインタフェースが宣言するフィールドのみを含む。
【００５７】
メソッド・カウント値３１３は、メソッド・テーブル３１４内の構造の数を示す。メソッド・テーブル３１４の各要素は、クラスまたはインタフェース内のメソッドの記述およびそのメソッド用の仮想計算機コードを示す可変長構造である。
【００５８】
属性カウント値３１５は、属性テーブル３１６内の属性の数を示す。属性テーブル３１６内の各要素は可変長構造である。属性構造については、Ｔｈｅ  ＪａｖａTM  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（上記）の第４章の４．７項に記載されている。
【００５９】
本発明の実施形態により、バック・チャネルの有無に関わらずマルチキャスト／同報通信シナリオでのＪａｖａTMバイト・コードの適時配信が可能になる。同じメカニズムは、（シリアル化）オブジェクトの配信にも使用することができる。マルチキャストにより、特別にアドレス指定したデータ・ストリームを多くのユーザに伝送することができる。マルチキャストの場合、データ・ストリームは各ユーザに個別に伝送する必要がない。むしろ、ユーザは、たとえば、特別にアドレス指定したデータ・ストリームのアドレスを指定することにより、マルチキャスト・サービスに加入することができる。同報通信により、マルチキャストの加入プロセスなしにユーザに伝送することができる。
【００６０】
本発明の実施形態は、ユーザが情報を要求する必要なしに情報がユーザに伝送される「プッシュ」メディアでの使用に適している。「プッシュ」メディアは、ユーザがメディアのソースに返答できるようにするためのバック・チャネルが一切設けられていない環境でも伝送することができる。また、本発明の実施形態は、ユーザがメディアのソースから情報を要求する「プル」メディアでの使用にも適している。
【００６１】
本発明の実施形態は、ＪａｖａTMバイト・コード（クラス・ファイル内の）を「時間意識の強いもの」にする働きをする。バイト・コードの適時配信を保証するため、コンテンツとともに適切なデッドラインがタイム・スタンプとしてクライアントに伝達される。これらのタイム・スタンプは、このような配信メカニズムを促進するようにヘッダで使用する。ヘッダはバイト・コードに付加され、バイト・コード・ストリームの適時配信を可能にする。
【００６２】
バイト・コードの適時配信で扱う伝送態様の１つは、パケット喪失である。従来の技法では、ＪａｖａTMバイト・コード・ストリーミングの場合にパケット喪失から回復する方法を一切示していない。考えられる手法の１つは、バック・チャネルがない場合に一定の間隔でクラス全体を再伝送することを含む。これは、メディアの場合にランダム・アクセス・ポイントを促進するのに役立つだろう。しかし、これは、クライアントの数が多すぎる場合またはクラス（またはオブジェクト）が非常に大きく、再伝送が法外なものになる場合には不可能になる。
【００６３】
バック・チャネルが存在する場合、パケット喪失をサーバに通知することができ、喪失パケットを再伝送することができる。信頼できるマルチキャスト方式を使用すると、サーバ以外の場所からデータを再伝送することもできる。
【００６４】
部分パケット喪失から回復するために使用可能な、固有の冗長性を備えたエラー回復方式がいくつか存在する。たとえば、順方向エラー訂正のような方式を使用することができる。また、パケット喪失問題は、何らかの信頼できるマルチキャスト方式を使用することにより、部分的に解決することができる。本発明の実施形態は、パケット喪失を克服するために任意のエラー回復または任意の信頼できるマルチキャスト・アルゴリズムの使用を促進する。
【００６５】
対処するもう１つの状況はセキュリティである。クライアントの安全を保証するため、バイト・コードは本物である必要がある。バイト・コードが本物であることを保証するために使用可能なセキュリティ方式はいくつか存在する。本発明の実施形態は、ＪａｖａセキュリティＡＰＩのセキュリティ・モデル内で任意のセキュリティ方式を使用することができる。
【００６６】
扱うさらに他の状況は圧縮の状況である。圧縮は、所与の量の情報を伝送するために必要な時間を短縮することにより、配信の効率を高める。効率のためにクラス・ファイルを圧縮するのに、ＬＺＷ、ＬＺＳなどのいくつかの圧縮方式が使用可能である。
【００６７】
図５は、本発明の一実施形態により適時にクラス・ファイルを配信するための技法を示す概略図である。クラス・ファイル（またはオブジェクト）５０１が用意される。クラス・ファイル（またはオブジェクト）５０１は、１つまたは複数の適当な任意選択の圧縮方式、エラー回復方式、セキュリティ方式により処理される場合もあれば、処理されない場合もある。ヘッダ５０２がクラス・ファイル（またはオブジェクト）５０１に追加される。ヘッダ５０２を備えたクラス・ファイル（またはオブジェクト）５０１は、他へ配信するためにトランスポート・メカニズム５０８に渡される。トランスポート・メカニズム５０８はパケッタイザ５０３を使用して、ヘッダ５０２を備えたクラス・ファイル（またはオブジェクト）５０１を一連のパケット５０４、５０５、５０６、５０７として移送する。トランスポート・メカニズム５０８は、ヘッダ５０２を備えた所与のクラス・ファイル（またはオブジェクト）５０１を移送するためのパケットの適切な数を決定する。
【００６８】
図４は、本発明の一実施形態による適時配信を保証するクラス・ファイルまたは（シリアル化）オブジェクト用のヘッダを示す図である。このヘッダは、バイト・コード・ヘッダとして示され、図５に示すようにパケット化される前にクラス・ファイルに付加される。パケット化後、「時間意識の強い」トランスポート・メカニズム（たとえば、ＲＴＰ、ＭＰＥＧ−２トランスポート・ストリームなど）を使用すると、そのデータをクライアント側に移送することができる。この方式は、圧縮方式、セキュリティ方式、エラー回復方式用のテーブルを定義することにより、特定のメディア・コンテンツ（たとえば、ＭＰＥＧ−１、ＭＰＥＧ−２など）およびトランスポート・メカニズム（ＭＰＥＧ−２トランスポート・ストリーム、ＲＴＰなど）用に採用することができる。
【００６９】
ヘッダの一実施形態は、ヘッダの長さ、バージョン、クラスまたはオブジェクトを示すフラグ、必要なクラスの数、「ロード開始」タイム・スタンプ、「ロード期限（ｌｏａｄ  ｂｙ）」タイム・スタンプ、クラスのサイズ、使用中の圧縮のタイプ、使用中のセキュリティ方式のタイプ、使用中のエラー訂正のタイプ、その他のタイプ情報、クラス識別子（ＩＤ）の長さ、クラス識別子（ＩＤ）、必要なクラスのそれぞれのクラスＩＤの長さ、必要なクラスのそれぞれのクラスＩＤを表す情報を含む。
【００７０】
ヘッダの長さ情報４０１の一実施形態は、適時配信を可能にするためにバイト・コード・ファイルに追加されたヘッダのサイズをバイト単位で示す１６ビットを含む。バージョン情報４０２の一実施形態は、バイト・コード・ファイルの適時配信を可能にするために使用する方式のバージョンを示す２ビットを含む。クラス／オブジェクト・フラグ４０３の一実施形態は、ヘッダが付加されるバイト・コード・ファイルがクラスであるかオブジェクトであるかを示す１ビットを含む。たとえば、１はクラスを表し、０はオブジェクトを表す。
【００７１】
必要なクラスの数情報４０４の一実施形態は、このクラスをロードする前に（または、オブジェクトの場合はインスタンス化の前に）必要なクラスの数を示す１３ビットを含む。「ロード開始」タイム・スタンプ４０５の一実施形態は、クラスが受信され、完全にアセンブルし直されたときにその後でクラスのロードを開始できる時間を示す６４ビットを含む。タイム・スタンプの長さは、ＮＴＰタイム・スタンプに対処するために６４ビットに設定されている。６４ビットの長さを満たすために、ビット数の少ないタイム・スタンプは余分なビットで埋め込まれる。各方式は、端数のタイム・スタンプを表すために小数点の位置を定義することができる。クロック・ティックを使用する場合（ＭＰＥＧ−２）、６４ビットをすべて使用することができる。
【００７２】
タイム・スタンプは、絶対時間または相対時間の表現を含むことができる。たとえば、タイム・スタンプは、実際の時刻またはその他の絶対時間量を表すことができ、あるいはタイム・スタンプは、セッションの開始以降の経過時間、事象の発生、またはその他の相対時間量を表すことができる。
【００７３】
「ロード期限」タイム・スタンプ４０６の一実施形態は、クラスを絶対的にロードしなければならない時間を示す６４ビットを含む。クラスのサイズ情報４０７の一実施形態は、伝送中のデータのサイズをバイト単位で示す１６ビットを含む。
【００７４】
本発明の一実施形態はタイプ・フィールドを含む。圧縮タイプ・フィールド４０８は、使用する圧縮のタイプを指定するための４ビットを含む（オブジェクトの場合またはいかなる圧縮も使用しない場合は００００）。セキュリティ・タイプ４０９フィールドは、使用するセキュリティ方式を指定するための４ビットを含む（いかなる方式も使用しない場合は００００）。エラー訂正タイプ・フィールド４１０は、使用するエラー訂正方式を指定するための４ビットを含む（いかなる方式も使用しない場合は００００）。タイプ・フィールド４１１は、今後の使用のために予約されている４ビットを含む。
【００７５】
クラスＩＤ長情報４１２の一実施形態は、クラスＩＤ情報４１３の長さをバイト単位で示す３２ビットを含む。クラスＩＤ情報４１３は、クラスを識別する可変長ストリングを含む（各セッションごとに固有）。クラスＩＤ長情報４１２とクラスＩＤ情報４１３との組合せの長さが３２ビットの倍数になるように、ストリングが埋め込まれる。
【００７６】
ヘッダの一実施形態は、必要なクラスのそれぞれのクラスＩＤと、クラスＩＤ長とを含む。クラスＩＤ１長情報４１４は、第１の必要なクラス用のクラスＩＤの長さを示す１６ビットの情報を含む。クラスＩＤ１情報４１５は、第１の必要なクラスを識別し、クラスＩＤ１長情報４１４とクラスＩＤ１情報４１５とを組み合わせた長さが３２ビットの倍数になるように埋め込まれた可変長ストリングを含む。
【００７７】
第１の必要なクラスを超える必要なクラスのクラスＩＤ長情報およびクラスＩＤ情報は、クラスＩＤ１情報４１５に続き、領域４１６を占める。クラスＩＤｎ長情報４１７は、１６ビットを含み、ｎ番目の必要なクラス用のクラスＩＤの長さを指定する。クラスＩＤｎ情報４１８は、ｎ番目の必要なクラスを識別し、次の３２ビット境界まで埋め込まれた可変数のビットを含む。
【００７８】
本発明の一実施形態では各クラスは個別のユニットとしてパッケージングされる。したがって、適時配信を可能にするために各クラスにヘッダが付加される。適時配信は、クラスをロードすべき時間フレームを設けることによって促進される。「ロード開始」タイム・スタンプは、クラスをロードできる時間を示すために各クラスごとに用意される。「ロード期限」タイム・スタンプは、各クラスをロードする必要がある時間を示すために各クラスごとに用意される。「ロード期限」タイム・スタンプは、そのクラスがアプリケーション側で使用可能になるものと期待できる保証時間を示す。
【００７９】
この方式によって配信されるペイロードは、クラス（圧縮済みまたは未圧縮）またはインスタンスにすることができる。効率がよく安全で信頼性を与えるためにヘッダ内には３つのタイプ・フィールドが存在し、これがデータの属性（クラスまたはオブジェクト）を指定する。
【００８０】
利用可能などのような圧縮方式も本発明の実施形態とともに使用することができる。ヘッダの一部分（たとえば、４ビット）は、使用する圧縮方式のタイプを識別するように指定されている。たとえば、ビット・パターン００００は圧縮なしであることを示すために使用し、ビット・パターン０００１〜１１１１は特定の圧縮技法を示すために使用する。
【００８１】
利用可能などのようなセキュリティ方式も本発明の実施形態とともに使用することができる。ヘッダの一部分（たとえば、４ビット）は、使用するセキュリティ方式のタイプを識別するように指定されている。たとえば、ビット・パターン００００はセキュリティ方式を使用しないことを示すために使用し、ビット・パターン０００１〜１１１１は特定のセキュリティ方式を示すために使用する。
【００８２】
利用可能などのようなエラー回復方式も本発明の実施形態とともに使用することができる。ヘッダの一部分（たとえば、４ビット）は、使用するエラー回復方式のタイプを識別するように指定されている。たとえば、ビット・パターン００００はエラー回復方式を使用しないことを示すために使用し、ビット・パターン０００１〜１１１１は特定のエラー回復方式を示すために使用する。ヘッダの一部分（たとえば、４ビット）は今後の使用のために予約されている。
【００８３】
エラー回復方式の使用による利点の１つは、バイト・コードを伝送するためにＵＤＰなどの信頼できないプロトコルを使用できることである。不完全であるかまたはエラーによる影響を受けているバイト・コードは適切に実行されない。ＵＤＰなどの信頼できないプロトコルは、完全かつエラーのない情報配信を保証するものではない。しかし、エラー回復方式を追加することにより、完全性を検証し、バイト・コードを実行する前にエラーを訂正することができる。したがって、バイト・コードの伝送はもはや信頼できるトランスポート・メカニズムのみに拘束されない。
【００８４】
クラスは、セッションに固有のＩＤによって識別される。このＩＤを使用すると、それを何度も受け取ったときにクラスを識別することができる。これは、それぞれがインスタンスであるクラスを識別するためにオブジェクトが使用することができる。ＪａｖａTMクラス名はＩＤとして使用する。これらは可変長ストリングであるので、ストリングの長さもヘッダに含まれる。クラスＩＤとその長さ（１６ビット）の組合せは次の３２ビット境界まで埋め込まれる。
【００８５】
本発明の実施形態は、必要なクラスのリストも用意している。それぞれの必要なクラスの「ロード期限」時間は、それを必要とするクラスの「ロード開始」時間より前である必要がある。クラス／オブジェクト・データをロード／インスタンス化する前に必要になるクラスの数を指定するために１３ビット使用する。必要なクラスはそれぞれのクラスＩＤ（それぞれのクラスＩＤの長さとともに）によって指定する。
【００８６】
図６は、本発明の一実施形態による適時配信のためにバイト・コードを作成するプロセスを示す流れ図である。このプロセスはステップ６０１から始まる。ステップ６０２では、配信すべきバイト・コードを用意する。ステップ６０３では、そのバイト・コードについて所望の圧縮方式、エラー回復方式、セキュリティ方式を実行する。圧縮方式、エラー回復方式、セキュリティ方式のどのような組合せも任意の順序で実行することができる。たとえば、セキュリティ方式を適用し、次にエラー回復方式が続き、圧縮を使用しないことが可能である。したがって、圧縮方式、エラー回復方式、セキュリティ方式、またはそのサブセットのどのような順列も使用することができる。ステップ６０４では、バイト・コードにヘッダを付加する。このヘッダはバイト・コードに関する情報を含む。このようなヘッダの一実施形態については、上記の図４に関連して説明する。ヘッダは、ヘッダ情報がバイト・コードの前に付くようにバイト・コードに付加されているものとして記載されているが、バイト・コードに対して任意の位置に、たとえば、バイト・コードの終わり、バイト・コードの部分間に配置するか、またはバイト・コードによってインタリーブすることができる。
【００８７】
ステップ６０５では、付加したヘッダを備えたバイト・コードをトランスポート・メカニズムにより配信する。どのような適当なトランスポート・メカニズムも使用することができる。たとえば、ＴＣＰなど、単独で配信を保証するが、配信のタイミングは保証しないトランスポート・メカニズムを使用することができる。あるいは、ＲＴＰなど適時性を保証するトランスポート・メカニズムを使用することもできる。もう１つの代替例として、ＵＤＰなど、配信を保証しないトランスポート・メカニズムを使用することもできる。ステップ６０６では、プロセスが終了する。
【００８８】
図７および図８は、本発明の一実施形態により適時にバイト・コードを受信し、使用するプロセスを示す流れ図である。このプロセスはステップ７０１から始まる。ステップ７０２では、付加したヘッダを備えたバイト・コードをトランスポート・メカニズムにより受信する。トランスポート・メカニズムはどのようなトランスポート・メカニズムでもよい。ステップ７０３では、ヘッダに含まれる情報を読み取る。ステップ７０４では、バイト・コードを実行する前に追加のクラスをロードする必要があるか否かについて判断を行う。この判定を行うために使用する情報はヘッダから抽出することができる。追加のクラスをロードする必要がある場合、プロセスはステップ７０６に継続する。
【００８９】
ステップ７０６では、ヘッダに指定した「ロード開始時間」がすでに経過したか否かについて判断を行う。まだ経過していない場合、プロセスはステップ７０６に戻り、「ロード開始時間」に達するまで待つ。「ロード開始時間」に達した場合、プロセスは参照Ｂ７０７によりステップ７０８に継続する。ステップ７０８では、必要なクラスをロードする。ステップ７０９では、必要なすべてのクラスがロードされたか否かについて判断を行う。すべてがロードされたわけではない場合、プロセスはステップ７１０に継続する。ステップ７１０では、ヘッダに指定した「ロード期限時間」が経過したか否かについて判断を行う。「ロード期限時間」が経過していない場合、プロセスはステップ７０８に戻り、そこで必要なクラスのロードを続行する。ステップ７１０で「ロード期限時間」がすでに経過した場合、プロセスはステップ７１２に継続する。ステップ７１２では、ロード遅れエラーを処理する。このロード遅れエラー処理は、「ロード期限時間」デッドラインまでに必要なクラスを正常にロードできなかったという通知を含むことができる。この通知に基づき、（たとえば、新しい「ロード期限時間」デッドラインを指定することにより）ロードを再スケジュールすべきかどうか（または（バイト・コードを実行せずに）ロード・プロセスを取り消すべきかどうか）について判断を行うことができる。ステップ７１２から、プロセスはステップ７１３で終了する。
【００９０】
ステップ７０９で必要なすべてのクラスがロードされた場合、プロセスはステップ７１１に継続する。また、ステップ７０４で追加のクラスを一切ロードする必要がない場合、プロセスは参照Ａ７０５によりステップ７１１に継続する。ステップ７１１では、バイト・コードを実行する。バイト・コードについてセキュリティ方式、圧縮方式、および／またはエラー回復方式を実行した場合、バイト・コードの実行は追加のステップを含む場合がある。所与の追加ステップを含むプロセスの一例を図８に示す。ステップ７１１から、プロセスはステップ７１３で終了する。
【００９１】
図９は、本発明の一実施形態により配信したバイト・コードを実行するために作成し、実行するプロセスを示す流れ図である。このプロセスはステップ８０１から始まる。ステップ８０２では、セキュリティ方式を使用したか否かについて判断を行う。セキュリティ方式を使用した場合、プロセスはステップ８０３に継続する。ステップ８０３では、使用したセキュリティ方式を識別し、そのセキュリティ方式に応じてバイト・コードを処理する。セキュリティ方式の識別は、ステップ７０３で読み取ったものなど、ヘッダ情報で検出される情報に基づいて実行することができる。ステップ８０３から、プロセスはステップ８０４に継続する。ステップ８０２でいかなるセキュリティ方式も使用しなかったと判定された場合、プロセスはステップ８０４に継続する。
【００９２】
ステップ８０４では、圧縮方式を使用したか否かについて判断を行う。圧縮方式を使用した場合、プロセスはステップ８０５に継続する。ステップ８０５では、使用した圧縮方式を識別し、その圧縮方式に応じてバイト・コードを圧縮解除する。圧縮方式の識別は、ステップ７０３で読み取ったものなど、ヘッダ情報で検出される情報に基づいて実行することができる。ステップ８０５から、プロセスはステップ８０６に継続する。ステップ８０４でいかなる圧縮方式も使用しなかったと判定された場合、プロセスはステップ８０６に継続する。
【００９３】
ステップ８０６では、エラー回復方式を使用したか否かについて判断を行う。エラー回復方式を使用した場合、プロセスはステップ８０７に継続する。ステップ８０７では、使用したエラー回復方式を識別し、発生している可能性のあるエラーまたは脱落を訂正または補正する。圧縮方式の識別は、ステップ７０３で読み取ったものなど、ヘッダ情報で検出される情報に基づいて実行することができる。ステップ８０６から、プロセスはステップ８０８に継続する。ステップ８０６でいかなるエラー回復方式も使用しなかったと判定された場合、プロセスはステップ８０８に継続する。
【００９４】
ステップ８０８では、バイト・コードを実行する。本発明の一実施形態ではバイト・コードの実行を試みる前に必要なすべてのクラスがロードされることを保証するためのメカニズムを用意しているので、バイト・コードの正常実行が行われる。ステップ８０９では、プロセスが終了する。
【００９５】
したがって、１つまたは複数の具体的な実施形態に関連して、バイト・コード・ストリームの適時配信を可能にするための方法および装置を説明してきた。本発明は特許請求の範囲およびそれと同等の範囲全体によって定義される。
【図面の簡単な説明】
【図１】ＪａｖａTMネットワーク・アプリケーション環境の実施形態を示す図である。
【図２】本発明の実施形態用の適当な実行環境を提供できるコンピュータ・システムの実施形態のブロック図である。
【図３】クラス・ファイル・フォーマットの実施形態のブロック図である。
【図４】本発明の一実施形態による適時配信を保証するためのクラス・ファイルまたは（シリアル化）オブジェクト用のヘッダを示す図である。
【図５】本発明の一実施形態により適時にクラス・ファイルを配信するための技法を示す概略図である。
【図６】本発明の一実施形態による適時配信のためにバイト・コードを作成するプロセスを示す流れ図である。
【図７】本発明の一実施形態により適時にバイト・コードを受信し、使用するプロセスを示す流れ図である。
【図８】本発明の一実施形態により適時にバイト・コードを受信し、使用するプロセスを示す流れ図である。
【図９】本発明の一実施形態により配信したバイト・コードを実行用に作成し、実行するプロセスを示す流れ図である。
【符号の説明】
５０１  クラス・ファイル
５０２  ヘッダ
５０３  パケッタイザ
５０４  パケット
５０５  パケット
５０６  パケット
５０７  パケット
５０８  トランスポート・メカニズム
【図１】
0004397460.tif 000004
【図２】
0004397460.tif 000005
【図３】
0004397460.tif 000006
【図４】
0004397460.tif 000007
【図５】
0004397460.tif 000008
【図６】
0004397460.tif 000009
【図７】
0004397460.tif 000010
【図８】
0004397460.tif 000011
【図９】
0004397460.tif 000012