JP4343196B2 - クライアント装置、ソフトウェアストリーミング方法及びプログラム - Google Patents

Description

本発明は、サーバ装置からネットワークを介してソフトウェアの配信を受けるクライアント装置、ソフトウェアストリーミング方法及びプログラムに関する。

昨今、インターネット等のネットワークを介したソフトウェア（コンピュータプログラム）の配信サービスが盛んに行われるようになってきている。その際、配信を受けたソフトウェアを自由に利用可能とする方法の他に、利用期間や利用回数に制限を設ける方法もある（例えば、利用回数制限が１回の場合、各利用時にダウンロードすることになる）。他方、ソフトウェアのダウンロードを伴うサービスとして、ユーザがインターネット上のあるサイトの有するストレージの記憶領域を利用できるようにしたいわゆるアーカイブサービスがある。このサービスでは、ユーザは自身の持つソフトウェアを該サイト側に保存しておき、必要時に自身のコンピュータ側にダウンロードして使用することができる。これらのようなサービスは、その形態によって、ソフトウェアの受け渡しに記録媒体を必要とせず且つ直ちに受け渡しに入れること、クライアント側のマシンに大容量の記憶装置が必要なくなること、大規模なネットワークの管理者にとってクライアントマシンの管理が容易になること、などの種々の利点が得られ、今後ますます普及するものと予想される。

このように、サーバ側からユーザ側へソフトウェアをダウンロードする場合、ソフトウェアのファイル全体のダウンロードが完了するのを待ってから、ソフトウェアを起動する必要がある。

一方、既存のソフトウェアを改良等する場合に、新規にソフトウェアを作り直すのではなく、当該既存のソフトウェアに機能の追加又は更新を行うことで対応する方法が多くとられている。その際、ユーザは、例えばインターネット経由であるいはディスク状記録媒体から、アップデート用ファイルをコンピュータに読み込み、アップデート対象のソフトウェアが現在起動していないことを確認した上で、該アップデート用ファイルを起動させるとともに、画面上に提示されたインストラクションに従って幾つかの入力操作（例えば対象プログラムの指定など）を行う、といったような手続きが必要である。

従来、サーバ側からユーザ側へソフトウェアをダウンロードする場合、ソフトウェアのファイル全体のダウンロードが完了するのを待ってから、ソフトウェアを起動する必要があった。また、ソフトウェアをアップデートする場合、該ソフトウェアを停止させてから、アップデートする必要があった。また、アップデートには、ユーザの操作が必要であった。

本発明は、上記事情を考慮してなされたもので、クライアント装置がサーバ装置からソフトウェアをダウンロードして実行する場合に、該ソフトウェアのファイル全体のダウンロードが完了するのを待たずに該ソフトウェアを起動でき、また、該ソフトウェアの動作中にその機能部を追加又は更新できるようにしたクライアント装置、ソフトウェアストリーミング方法及びプログラムを提供することを目的とする。

本発明は、所定のネットワークを介してサーバ装置からアプリケーションプログラムのストリームによる配信を受けるクライアント装置であって、前記サーバ装置へ、前記アプリケーションプログラムのストリーミング要求を送信する手段と、前記サーバ装置が前記ストリーミング要求に応答して送信する、前記アプリケーションプログラムの基本的な機能を実現するための機能部群を含む基本システムを受信するとともに、前記サーバ装置が該基本システムの送信後に連続して送信する、前記アプリケーションプログラムに対して追加又は更新すべき機能を実現するための機能部と該機能部に関連する他の機能部の識別情報を含むプロファイル情報との組を、１組ずつ連続して受信する手段と、最初に、受信した前記基本システムを対象とし、該基本システムに含まれていない機能部を利用不可の状態にして、該基本システムを起動し、以降、受信した前記機能部を一つずつ対象とし、該機能部を動作可能にするとともに、該機能部に係る前記プロファイル情報に含まれる前記他の機能部に対して該機能部が利用可能になった旨を通知する制御を行う制御手段とを備えたことを特徴とする。

なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。

本発明によれば、ストリーミングによって機能部の追加又は更新用のファイルを連続的に配信し、コンピュータプログラムの動作中に（コンピュータプログラムを停止することなく）、自動的かつ逐次的に機能部の追加又は更新を行うことができる。

また、従来は、ネットワークにおけるストリーミングの利用は、ビデオやオーディオコンテンツなどのデータ配信でしか実現できなかったが、本発明によれば、コンピュータプログラムのストリーミング（例えば、機能部の単位でのストリーミング）が可能になる。

本発明によれば、クライアント装置がサーバ装置からソフトウェアをダウンロードして実行する場合に、該ソフトウェアのファイル全体のダウンロードが完了するのを待たずに該ソフトウェアを起動でき、また、該ソフトウェアの動作中にその機能部を追加又は更新できるようになる。

以下、図面を参照しながら発明の実施の形態を説明する。

図１に、本発明の一実施形態に係るネットワークシステムの構成例を示す。

図１に示されるように、本実施形態のネットワークシステムは、ストリーミング要求に応じて所定のソフトウェア（コンピュータプログラム）をストリーミング配信する機能を有するストリーミング・サーバ・システム（以下、サーバ）１と、サーバ１からソフトウェアのストリーミング配信を受け、そのソフトウェアを実行する機能を有するクライアント・システム（以下、クライアント）２とを含んで構成される。サーバ１と各クライアント２とは、所定のネットワーク３を介して通信可能である。サーバ１は、複数のクライアント２に対して（同時に又は順次に）ストリーミング配信できる。なお、ネットワーク３上にサーバ１が複数存在しても構わない（この場合、各クライアント２は、所望のサーバ１にアクセスする）。

なお、ネットワーク３がイントラネット等のＬＡＮでもインターネット等のＷＡＮでも本発明は適用可能である。また、本発明は、サーバ・クライアント間の通信プロトコルがどのようなものであっても適用可能である。本実施形態では、ネットワーク３として、インターネットを例にとって説明する。なお、この場合に、クライアント２は、ＬＡＮを介してインターネットに接続されるものであってもよいし、ＬＡＮを介さずにインターネットに接続されるものであってもよいし、また、有線リンクのみでインターネットに接続されるものであってもよいし、無線リンクを介してインターネットに接続されるものであってもよいし。

サーバ１やクライアント２は、計算機とソフトウェアなどによって構成可能である。本実施形態では、一例として、サーバ１は、インターネット上のＷＷＷサーバ（もしくはサイト）を想定し、クライアント２は、表示画面／入力装置（例えば、マウスなどのポインティングデバイスとキーボード等）によるユーザインタフェース手段やＷｅｂブラウザ等の機能を搭載した計算機（あるいはプログラム実行機能を搭載した携帯電話端末等）を想定して説明する。なお、ＷＷＷサーバとしては、コンテンツ配信サービスあるいはアーカイブサービスなど、ソフトウェアを配信もしくは転送する手続きを含むサービスを提供するサーバ・システム（サービス・サイト）であれば、どのようなものにも本発明は適用可能である。

図２に、本実施形態のサーバ１およびクライアント２の構成例を示す。なお、図２では、ソフトウェアのストリーム配信、ストリーム配信されたソフトウェアの実行および実行中における機能の追加や更新のための処理などに関係する部分を中心に示している。

図２に示されるように、サーバ１は、送受信処理部１１、機能更新ファイル格納部１２、プロファイル情報格納部１３を備えている。なお、機能更新ファイル格納部１２とプロファイル情報格納部１３は、同じ物理デバイス上に存在していても、違う物理デバイス上に存在していてもよい。

サーバ１では、ストリーミング配信対象のソフトウェアについて、機能更新ファイル格納部１２にて、自動機能追加更新部のプログラム（クライアント２上で起動される自動機能追加更新部（自動機能追加更新プロセス）２４のプログラム）を含むファイル（以下、自動機能追加更新ファイル）と所定数（１又は複数）の機能更新ファイルとを格納するとともに、プロファイル情報格納部１３にて、自動機能追加更新ファイルに対応するプロファイル情報と各々の機能更新ファイルに対応するプロファイル情報とを格納する。なお、複数のソフトウェアを格納する場合には、例えば、ソフトウェアごとにフォルダあるいはディレクトリを分けて、自動機能追加更新ファイル／機能更新ファイル／プロファイル情報を格納するなどの手段を用いてもよい（この点は、クライアント２についても同様である）。

ここで、「機能更新ファイル」は、当該ソフトウェアの実行中に所定の機能部の追加又は更新を行うためのものであり、ある１つ以上の機能を実現するためのプログラムコードのまとまりを含むファイルである（具体的には、例えば、コンポーネントウェアやオブジェクトなどを用いることができる）。
また、自動機能追加更新プロセスは、クライアント２上で起動され、プロファイル情報を参照して、機能更新ファイルを自プロセスにロードすることによって、当該ソフトウェアの実行中に所定の機能部の追加又は更新を行うためのものであり、「自動機能追加更新ファイル」は、この自動機能追加更新プロセスを実現するためのプログラムコードのまとまりを含むファイルである。
また、「プロファイル情報」は、自動機能追加更新ファイルに対するものとしては、該自動機能追加更新ファイルに関する情報（例えば、アプリケーション名、当該ファイルの名称やサイズなど）を含むものであり、各々の機能更新ファイルに対するものとしては、当該機能更新ファイルに関する情報（例えば、アプリケーション名、当該ファイルの名称やサイズなど）の他に、当該機能更新ファイルよって追加又は更新される機能部を示す情報（例えば、追加又は変更される機能部の名称の一覧）や該機能部に関連する他の機能部を示す情報（例えば、他の機能部の名称の一覧）などを含むものである。

送受信処理部１１は、クライアント２からのストリーミング要求を受け付け、ストリーミング要求に応答して、要求元から指定されたソフトウェアのストリーミング配信を行う（なお、予め定められたソフトウェアのみを配信するサーバにおいては当該予め定められたソフトウェアのストリーミング配信を行う）。ストリーミング配信では、順次、自動機能追加更新ファイルとそれに対応するプロファイル情報、そして各々の機能更新ファイルとそれらに対応するプロファイル情報を、（このようなアプリケーション形式から）所定のフォーマットのストリームに変換して、要求元のクライアント２に送信していく。

図３に、このコンピュータプログラムのストリームのフォーマットの一例を示す。

このストリーム例では、プログラムの核となる自動機能追加更新ファイルを先頭とし、これに個々の機能更新ファイルが後続する構成になっている。また、該ストリームにおいて、自動機能追加更新ファイル及び各機能更新ファイルのそれぞれの前に、それぞれに対応するプロファイル情報を配置する構成になっている。すなわち、図３において、Ｐ０が自動機能追加更新ファイルに対応するプロファイル情報、Ｐ１，Ｐ２，Ｐ３…が各機能更新ファイルに対応するプロファイル情報を表している。なお、本発明は、実装上のストリーム形式（フォーマット）がどのようなものであっても適用可能である。例えば、ＭＰＥＧ４などを用いることも可能である。

なお、１つのストリームにおいて機能更新ファイルが複数ある場合に、各機能更新ファイルの配信の順序（ストリームにおける配置順）は、予め定めておくようにしてもよい（例えば、各機能更新ファイルを、その配信順に従って格納しておく、あるいは各機能更新ファイルの名称にその配信順を示す数字あるいは文字を含ませる、あるいは各機能更新ファイルとその配信順との関係を示すテーブルを保持しておく、など）。

次に、クライアント２は、図２に示されるように、送受信処理部２１、機能更新ファイル格納部２２、プロファイル情報格納部２３を備えている。なお、機能更新ファイル格納部２２とプロファイル情報格納部２３は、同じ物理デバイス上に存在していても、違う物理デバイス上に存在していてもよい。

クライアント２では、サーバ１からストリーミングによって配信されたソフトウェアについて、機能更新ファイル格納部２２にて、自動機能追加更新ファイルおよび各機能更新ファイルを格納するとともに、プロファイル情報格納部２３にて、自動機能追加更新ファイルおよび各機能更新ファイルに対応するプロファイル情報を格納する。

送受信処理部２１は、ユーザからの所望のソフトウェアに対する要求（例えば、所望のソフトウェアの配信要求、所望のソフトウェアの起動要求など）に基づいて、サーバ１（側の送受信処理部１１）に該ソフトウェアのストリーミング要求を送信する（なお、予め定められたソフトウェアのみを配信するサーバについてはソフトウェアの選択あるいは指定はされない）。また、送受信処理部２１は、サーバ１側から送られてきた該ソフトウェアについてのストリームを受信し、順次、このストリームを元のアプリケーション形式に戻して、自動機能追加更新ファイル及び対応するプロファイル情報、そして個々の機能更新ファイル及び対応するプロファイル情報として、機能更新ファイル格納部２２及びプロファイル情報格納部２３に保存していく。さらに、送受信処理部２１は、当該ストリームにおいて最初に受信され格納される自動機能追加更新ファイル（自動機能追加更新部のプログラム）を、自計算機においてプロセスとして（すなわち、自動機能追加更新部２４として）起動する。ここで、プロセスは、コンピュータシステムにおける基本実行単位である（例えば、多くの場合、１つのコンピュータプログラムは、１つのプロセスとして、コンピュータシステムのメインメモリ上にロードされて実行される）。

起動された自動機能追加更新部２４は、所定のタイミングで（例えば、常時連続的に、あるいは一定期間毎に）プロファイル情報格納部２３を参照し、新規のプロファイル情報があれば、該プロファイル情報基づいて、該当する機能更新ファイルを自プロセスにロードして機能部を追加又は更新するとともに、関連する他の機能部があれば通知を行うなどすることによって、コンピュータプログラムを停止させることなく、コンピュータプログラムの機能を追加又は更新を行うものである。ここで、コンピュータプログラムの停止とは、プロセスが終了すること（つまりメインメモリ上から消えること）を意味し、したがって、コンピュータプログラムを停止させることなく機能を追加又は更新するとは、プロセスを終了させることなく機能を追加又は更新することを意味する。

なお、機能更新ファイルを複数持つストリームの場合であって、かつ、複数の機能更新ファイルの処理順が任意である場合に、クライアント２の自動機能追加更新部２４は、ストリームの受信中において、例えば、受信され格納された機能更新ファイルから順番に（未処理の機能更新ファイルが複数格納されているときはランダムにあるいは受信順に選択して）処理するようにしてもよい。

また、１つのストリームにおいて機能更新ファイルが複数ある場合に、クライアント２における各機能更新ファイルの処理順を予め定め、その順番をサーバ１からクライアント２へ指定し、クライアント２の自動機能追加更新部２４は、ストリームの受信中において、該サーバ１から指定される順番に従って、各機能更新ファイルを処理するようにしてもよい（例えば、サーバ１が各機能更新ファイルをその処理順に送信し、各機能更新ファイルを受信した順番を保持しておき、その受信順に従って処理する、あるいは各機能更新ファイルの名称にその処理順を示す数字あるいは文字が含まれている場合に、その処理順に従って処理する、あるいはサーバ１からクライアント２へ各機能更新ファイルとその処理順との関係を示すテーブルを送信し、このテーブルに従って処理する、など）。

ここで、図４に、ソフトウェアとしてワードプロセッサーを例にとった場合におけるストリーム構成の一例を示す（図４ではプロファイル情報を省略している）。図４の例では、自動機能追加更新ファイルに続いて、機能更新ファイル（１）として、文字入力機能部等の基本的な機能部群を含む基本システムを配信し、次に、機能更新ファイル（２）として、文字レイアウト調整機能部を配信し、次に、機能更新ファイル（３）として、図形描画機能部を配信し、次に、機能更新ファイル（４）として、印刷機能部を配信する。

また、図５に示すように、自動機能追加更新ファイルに機能更新ファイルを含ませる構成も可能である。

なお、自動機能追加更新ファイルをストリームにおける最初の順番ではなく若干後の順番で配信することも可能である（自動機能追加更新ファイルより前に配信される機能更新ファイルは、自動機能追加更新ファイルが配信され、自動機能追加更新プロセスが起動されてから、利用されることになる）。

また、図６に、プロファイル情報のフォーマットの一例を示す。

この例では、プロファイル情報は、少なくとも、対象とするアプリケーションの名称、当該プロファイル情報が表す機能更新ファイルの名称、追加される機能部の名称、追加される機能部に関連する他の機能部の名称、更新される機能部の名称、更新される機能部に関連する他の機能部の名称、当該プロファイル情報が（サーバの）プロファイル情報格納部に保存された日時、後に続くファイル（自動機能追加更新ファイルまたは機能更新ファイル）のサイズの項目を持ち、それらのうち必要な情報が記述される。

図６は、ソフトウェアとしてワードプロセッサーを例にとった場合における機能を追加する機能更新ファイルに対応するプロファイル情報の一例を示している。この例では、アプリケーションの名称として「ワードプロセッサー○○○ver.1」、機能更新ファイルの名称として「機能追加ファイル１」、追加される機能部の名称として「印刷機能部」、追加される機能部に関連する他の機能部の名称として「メニュー機能部」および「ファイル出力部」、保存された日時として「２０００／０３／０９ ２２：５３」、ファイルのサイズとして「３００ｂｙｔｅ」が記述されている。

また、図７に、ソフトウェアとしてワードプロセッサーを例にとった場合における自動機能追加更新ファイルに対応するプロファイル情報の一例を示す。

また、図８に、ソフトウェアとしてワードプロセッサーを例にとった場合における機能を更新する機能更新ファイルに対応するプロファイル情報の一例を示している。

次に、本実施形態の動作について説明する。

図９に、本実施形態に係るネットワークシステムの基本的なシーケンスの一例を示す。

図１０、サーバ１の送受信処理部１１の処理手順の一例を示す。

図１１、クライアント２の送受信処理部２１の処理手順の一例を示す。

まず、ユーザは、クライアント２に、例えば所望のソフトウェアのストリーミング配信の指示あるいはソフトウェアの起動の指示など、サーバ１へストリーミング要求を送信する契機となる所定の入力を行う（その際、必要に応じて、サーバやソフトウェアを指定する）。例えば、所望のサーバ２から転送され表示された、ソフトウェアのリストを含むＷｅｂページ画面上で、所望のソフトウェアを選択する。

このようなユーザからの要求を契機として（Ｓ２１）、クライアント２は、サーバ１にストリーミング要求を送信する（Ｓ１）（Ｓ２２）。このときの様子を図１２に示す。

サーバ１の送受信処理部１１は、クライアント２からストリーミング要求を受けると（Ｓ１１）、指定のアプリケーションを、所定のフォーマット（図３参照）のストリームに変換し、クライアント２へ配信する手続きを開始する。

まず、プロファイル格納部１３から、自動機能追加更新ファイルに対応するプロファイル情報（０）を読み込み（Ｓ１２）、機能更新ファイル格納部１２から自動機能追加更新ファイルを読み込み（Ｓ１３）、それらプロファイル情報（０）と自動機能追加更新ファイルをストリームとして要求元のクライアント２へ送信する（Ｓ２）（Ｓ１４）。

一方、クライアント２の送受信処理部２１は、受信したストリームのうち、プロファイル情報を受け取った時点を一区切りとして、元のアプリケーション形式に戻し、機能更新ファイル格納部２２とプロファイル格納部２３に保存していく手続きを開始する。

サーバ２からの配信が開始されると、まず、そのストリームにより自動機能追加更新ファイルに対応するプロファイル情報（０）の部分を受信し（Ｓ２）（Ｓ２３）、次いで、該プロファイル情報（０）で指定されたバイト数まで、ストリームを自動機能追加更新ファイルとして受信する（Ｓ２）（Ｓ２４）。そして、受信したプロファイル情報（０）と自動機能追加更新ファイルをそれぞれプロファイル格納部２３と機能更新ファイル格納部２２に格納する（Ｓ２５）。

そして、クライアント２の送受信処理部２１は、ストリームの先頭部分の自動機能追加更新ファイルを保存した時点で（Ｓ２６）、自動機能追加更新部２４をプロセスとして起動する（Ｓ３）（Ｓ２７）。このときの様子を図１３に示す。

起動された自動機能追加更新部２４は、プロファイル情報を参照しながら、順次、機能の追加又は更新を行っていく手続きを開始する。

続いて、サーバ１の送受信処理部１１は、プロファイル格納部１３から、機能更新ファイル（１）に対応するプロファイル情報（１）を読み込み（Ｓ１２）、機能更新ファイル格納部１２から機能更新ファイル（１）を読み込み（Ｓ１３）、それらプロファイル情報（１）と機能更新ファイル（１）をストリームとして要求元のクライアント２へ送信する（Ｓ４）（Ｓ１４）。

クライアント２は、そのストリームにより機能更新ファイル（１）に対応するプロファイル情報（１）の部分を受信し（Ｓ２）（Ｓ２３）、次いで、該プロファイル情報（１）で指定されたバイト数まで、ストリームを機能更新ファイル（１）として受信する（Ｓ４）（Ｓ２４）。そして、受信したプロファイル情報（１）と機能更新ファイル（１）をそれぞれプロファイル格納部２３と機能更新ファイル格納部２２に格納する（Ｓ２５）。

すると、クライアント２上で動作する自動機能追加更新部２４は、プロファイル情報（１）を参照して、機能更新ファイル（１）により機能の追加又は更新のための処理を行う（Ｓ５）。このときの様子を図１４に示す。

以降、ストリームの最後尾に位置すべき機能更新ファイルについての処理が完了するまで、同様にして、機能更新ファイル（２）、機能更新ファイル（３）、…の配信が行われ、機能の追加又は更新が行われていく（Ｓ６，Ｓ７，Ｓ８，Ｓ９）。

次に、図１５に、クライアント２上で起動された自動機能追加更新部２４の処理手順の一例を示す。

クライアント２上で起動された自動機能追加更新部２４は、プロファイル格納部２３を参照し（Ｓ３１）、新しいプロファイル情報（未処理のプロファイル情報）があれば（Ｓ３２）、プロファイル格納部２３から該当するプロファイル情報を１つ取り出す（Ｓ３３）。

次に、自動機能追加更新部（自動機能追加更新プロセス）２４は、該プロファイル情報に記述されているファイル名に該当する機能更新ファイルを機能更新ファイル格納部２２から取り出し（Ｓ３４）、該機能更新ファイルに所定の機能部を自プロセス上にロードして、当該機能部を新たに動作可能とする（Ｓ３５）。なお、前述したように、個々の機能部は例えばコンポーネントウェアなどとして実装されている。

次に、自動機能追加更新部２４は、自身で保持するロード済み機能部管理テーブル（自プロセスにロードした機能部の情報を保持するテーブル）を参照し、同じ名称の機能部が既にロードされていたならば、機能の更新とみなして、同じ名称の古い機能部をアンロードする（Ｓ３６）。

次に、自動機能追加更新部２４は、ロード済み機能部管理テーブルを参照し、自プロセスにロードした該新たな機能部に関連する他の機能部（他の機能部の情報は、プロファイル情報に記述されている）のうちロード済みのものに、該新たな機能部が動作可能となった旨を通知する（Ｓ３７）。

次に、自動機能追加更新部２４は、自プロセスにロードした該新たな機能部の情報を、ロード済み機能部管理テーブルに追加する（Ｓ３８）。

以降、ストリームの最後尾に位置すべき機能更新ファイルについての処理が完了するまで、同様の処理が繰り返し行われる。

一方、上記のＳ３７で通知を受けた他の機能部は、新たに追加された機能部に関連する機能を有効にする。例えば、メニュー機能部は、印刷機能部が追加された時点で、メニュー上の「印刷」項目がマウスによって選択できるようにするとともに、ユーザにわかるように表示形態を変更する。

なお、自動機能追加更新部２４は、所定のタイミングでプロファイル情報格納部２３をチェックし、新しいプロファイル情報（未処理のプロファイル情報）があれば、機能の追加又は更新を行ったが、その代わりに、送受信処理部２１が新しいプロファイル情報を取得した旨を自動機能追加更新部２４に通知し、自動機能追加更新部２４は、この通知に従って、機能の追加又は更新を行うようにしてもよい。

また、自動機能追加更新部（自動機能追加更新プロセス）２４は、例えば、ユーザの明示的な終了指示の入力（例えば、通常のアプリケーションを終了させるのと同じ方法による終了指示入力）に従って、終了するようにすればよい。また、ユーザの要求により、アプリケーション自体は終了しないが、新たに受信したプロファイル情報／機能更新ファイルは格納のみ行いそれらを処理しないようすることを可能にしてもよい。

また、ストリームの終了の判断については、これを特に行わずに自動機能追加更新部２４の動作中は（たとえストリームが一応終了したとしても）プロファイル情報／機能更新ファイルの受信／保存をチェックを続けるようにしてもよいが、ストリームの終了の判断を行い、ストリームが終了したと判断された場合には、以降は、例えば、送受信処理部２１からプロファイル情報／機能更新ファイルの受信を通知されたときに新たに到着したプロファイル情報／機能更新ファイルを処理するようにしてもよいし、あるいは、例えば、ユーザあるいは他のプロセスから要求があるまで新たにプロファイル情報／機能更新ファイルを処理しないようにしてもよい。ストリームの終了の判断としては、例えば、ストリームの最後でサーバ１からクライアント２へストリームが終了する旨の情報を転送する方法、ストリームの最初に送信する更新ファイルの数を示す情報を転送する方法、最後にプロファイル情報／機能更新ファイルを受信してから予め定められた期間経過しても新たなプロファイル情報／機能更新ファイルを受信しないときにストリームが終了したと判断する方法など、種々の方法がある。

また、送受信処理部２１についても、例えば、自動機能追加更新部（自動機能追加更新プロセス）２４が終了したときに、あるいはストリームが終了したと判断されたときに、あるいはユーザから要求されたときに、受信を終了するようにしてもよい。

なお、上記では、ユーザからの要求を契機としたが、例えば、起動中のあるプロセスが、所定のソフトウェア（コンピュータプログラム）のストリーミング配信の要求あるいは所定のソフトウェアの起動の要求などを出したときに、クライアント２から該当するサーバ１へ所定のソフトウェアのストリーミング要求を送信するようにすることも可能である。もちろん、ユーザからの要求を契機とすることと、起動中のプロセスからの要求を契機とすることとを併せて実施することも可能である。

また、上記では、ある複数の機能更新ファイルを持つソフトウェアについてストリーミング要求された場合に、そのソフトウェアについての全ての機能更新ファイルを配信するものとしたが、例えば条件や指定内容などに応じて、一部の機能更新ファイルのみを配信対象とする（あるいは、一部の機能更新ファイルについては配信対象から除外する）ことを可能にしてもよい。例えば、あるソフトウェアについて幾つかのオプションを設定しておき（例えば、あるオプションが指定されたときに、どの機能更新ファイル群を配信するかを決定しておき）、例えばユーザが任意にあるいはクライアントマシンが自計算機の性能あるいは装備を考慮するなどして、該ソフトウェアについてオプションを選択し、クライアント２からサーバ１へ該ソフトウェアのストリーミング要求を送信する際に該オプションを指定し、サーバ１は、要求されたソフトウェアについて指定されたオプションに対応する機能更新ファイルを送信するようにしてもよい。例えば、クライアントからサーバへオプション指定がなかった場合にサーバからクライアントへ配信する機能更新部のセット（ミニマム・セット）を設定しておき、ユーザがある機能部…例えば、描画機能部…を必要とする場合に、ユーザが描画オプションを選択し、クライアントからサーバへ描画オプションを指定し、サーバでは描画オプションが指定された場合にのみ、該当する機能更新部を（適当なストリーム位置で）さらに送信するようにしてもよい（あるいは、逆に、ユーザが描画機能部を必要としない場合に、ユーザが描画オプションを選択し、クライアントからサーバへ描画オプションを指定し、サーバでは描画オプションが指定された場合にのみ、該当する機能更新部を送信しないようにしてもよい）。

ところで、上記では、Ｓ３７において、自動機能追加更新部２４がロード済み機能部管理テーブルを参照した際に、自プロセスにロードした該新たな機能部に関連する他の機能部（該新たな機能部が動作可能になった旨を通知すべき通知先となる１又は複数の機能部）のうちロード済みでないものは存在しないことを想定した（例えば、予め定められた順番に機能更新ファイルを実行すれば、通知先の機能部は必ず先行してロード済みになるように、ストリームが構成されているケースなど）。

ただし、例えば、予め定められた順番に機能更新ファイルを実行すれば、通知先の機能部は必ず先行してロード済みになるように、ストリームが構成されているようになっていても、通信プロトコルの仕様によって、伝送エラー等のためのある機能更新ファイルの再送が、それよりストリームにおいて後に位置する機能更新ファイルの転送の後になる可能性がある場合、あるいは伝送エラー等がなくても機能更新ファイルのサーバでの送信順とクライアントでの受信順が前後する可能性がある場合などには、ある機能部についての通知先となる他の機能部がロード済みでない状態が発生し得る。また、例えば、通信プロトコルの仕様にかかわらず、ある機能部ａ（その追加用の機能更新ファイルをＡとする）がある機能部ｂ（その追加用の機能更新ファイルをＢとする）を通知先とし、逆に、機能部ｂが機能部ａを通知先とするような場合には、どのような順番で機能更新ファイル（Ａ，Ｂ）を処理しても、通知先の機能部がロード済みでない状態が発生する。そこで、このような場合に対応するための幾つかの方法が考えられる。

例えば、通知先の機能部がロード済みでない場合には、該通知先の機能部の情報を保持しておき、該通知先の機能部がロード済みになったときに、該通知先の機能部に必要な通知を行うようにしてもよい。

また、例えば、処理対象となった機能更新ファイルについての通知先の機能部が全てロード済みか否かチェックし、通知先の機能部が全てロード済みではない場合には、該ある機能更新ファイルの処理を１回（あるいは複数回）延期して、他の処理可能な機能更新ファイルを先に処理し、その後に、あらためて、該延期した機能更新ファイルについての通知先の機能部が全てロード済みか否かチェックし…（以下、同様の処理）、という方法もある。あるいは、例えば、ある機能更新ファイルについての通知先の機能部が全てロード済みになるまで、該ある機能更新ファイルの処理を保留し、該通知先の機能部が全てロード済みになったときに、該ある機能更新ファイルを処理するという方法もある。なお、これらの場合には、複数の機能更新ファイルが互いに相手が起動した後でないと起動できないようなデッドロックの状態が発生しないことを必ずしも保証しないで実施するケースでは、そのような状態を検出し（例えば、プロファイル情報を参照して検出し、あるいはサーバからクライアントにデッドロックになる機能更新ファイルの情報を通知し）、これを回避する（例えば、一方を先に起動する）必要がある。

他の方法としては、例えば、各機能更新ファイルに対応するプロファイル情報に、該機能更新ファイルで追加又は更新する当該機能部の通知先となる他の機能部の情報と、該機能更新ファイルで追加又は更新する当該機能部を通知先とする他の機能部の情報とを記述しておき、各機能部がロードされた際に、自身の通知先に通知を行うとともに、自身を通知先とする他の機能部が起動されているか否かをロード済み機能部管理テーブルをチェックして、該他の機能部が動作可能になったことを知るようにする方法もある。

なお、これまでは、通知の内容として、当該機能部が動作可能になった旨を扱ったが、例えば、同じ名称の機能部でもその機能のグレード等が異なるものが複数ある場合に、いずれのグレード等のものが組み込まれたかなどの他の情報も必要に応じて通知するようにしてもよい。

以下では、ワープロ・アプリケーションをストリーミング配信することで、ダウンロード開始当初からワープロ・アプリケーションが起動され、また、その実行中に逐次的に機能が追加又は更新されていく場合を例にとって説明する。

なお、この場合のストリームの構成は、例えば、図４のようになっているものとする。

まず、（クライアント２の）ユーザは、例えば、所望のサーバから所望のワープロアプリケーションを選択し、ストリーミングを要求する（あるいは、例えば、所望のワープロアプリケーションの起動を指示し、クライアント２は、クライアント２へのストリーミングが必要と判断する）。そして、クライアント２からサーバ１へストリーミング要求を送信し、サーバ１からクライアント２へストリーミング配信を行い、クライアント２はストリームを受信しながら、起動したアプリケーションに機能部を次々と組み込むなどしていく。

従来のインターネットにおけるソフトウェアのダウンロードでは、そのファイルの全ての部分がダウンロードされるまで、ワープロ・アプリケーションを使用（起動）することはできない。したがって、アプリケーションが大きなものであれば、ユーザはかなり時間を待たされることになる（また、なんらかの理由で通信が途中で切れてしまった場合には、ダウンロードを初めからやり直さなくてはならない）。

しかし、本実施形態のストーミングによるアプリケーションの配信では、図１６に示すように、ワープロ・アプリケーションの自動機能追加更新ファイルとワープロとしての最小限の役割を提供する機能更新ファイルがクライアント２に到着し、自動機能追加更新部（自動機能追加更新プロセス）２４が起動され、該ワープロとしての最小限の役割を提供する機能更新ファイルが自動機能追加更新プロセス２４にロードされた時点から、ワープロ・アプリケーションが最小限の機能で起動されたことになって、ユーザは最小限の機能でワープロ・アプリケーション使用することができるようになる（また、なんらかの理由で通信が途中で切れてしまっても、その途中からダウンロードをやり直せばよいようになる）。ここで、ワープロとしての最小限の役割を提供する機能は、例えば、白いウィンドウが開き、文字の入力が可能になる、などのシンプルな機能である。

図１７に、ワープロ・アプリケーションが最小限の機能で起動されたときの画面の様子を示す。このときに、メニューバーの項目「レイアウト調整」は、まだ、選択できないようになっている。また、例えば、図１８のように、メニューバーの項目「ファイル」を選択したときに表示されるプルダウンメニューにおいて、項目「新規作成」と項目「保存」は選択できるが、項目「印刷」は選択できないようになっている。

そして、図１９に示すように、ユーザが文字入力をしている間にも、図２０に示すように、次々と機能を追加又は更新するファイルがストリーミングによって配信され、それが自動機能追加更新プロセス２４にロードされるとともに、それに関連する他の機能への通知が行われ、その都度ワープロとしての機能が向上していく。

例えば、適当なタイミングで、文書のレイアウトを調整する機能が追加され、図２１に示すように、メニューバーの項目「レイアウト調整」が選択できるように変更される。

また、例えば、適当なタイミングで、プリンタに印刷する機能が追加され、図２２に示すように、メニューバーの項目「ファイル」を選択したときに表示されるプルダウンメニューにおいて、項目「印刷」が選択できるように変更される。

その他、図を書く機能等、種々の機能が順次追加されていく。

このように、例えば、ワープロ・アプリケーションが起動された当初は、文字を入力するなどの簡単な機能だけであったのが、ユーザが必要な文書を入力し終えた頃には、印刷する機能が可能となり、ユーザはプリンタに印刷することができるようになる、という使い方ができる。

また、図２３に示すように、必要に応じて、同じ機能を古いものから新しいものへ入れ替えることも可能になる。この更新の機構は、ソフトウェアのバージョンアップに使用できるが、それだけでなく、例えば、１つのワープロ・アプリケーションのストリームで、ある機能部についてストリームの前の部分で簡易な機能を配信しておき、後の部分で同じ機能部についてより高度な機能に入れ替えるという使い方もできるようになる。

以下では、幾つかのバリエーションについて説明する。

これまでの説明では、サーバ１からクライアント２へ自動機能追加更新ファイルを送信したが、例えば、図２４のシーケンス例に示すように、クライアント２側で１又は複数の特定のソフトウェアに固有の自動機能追加更新プログラムあるいは全ソフトウェアに共通の自動機能追加更新プログラムを保持しておき、サーバ１からクライアント２へ、自動機能追加更新ファイルを配信する代わりに、自動機能追加更新プロセスを起動させるための自動機能追加更新プロセス起動コマンドを送信するようにしてもよい。

また、例えば、図２５のシーケンス例に示すように、クライアント２側で１又は複数の特定のソフトウェアに固有の自動機能追加更新プログラムあるいは全ソフトウェアに共通の自動機能追加更新プログラムを保持しておき、クライアント２は、ユーザから要求を受けたときなどに該自動機能追加更新プログラムをプロセスとして起動してからサーバ１へストリーミング要求を送信し（あるいは、サーバ１へストリーミング要求を送信した直後に該自動機能追加更新プログラムをプロセスとして起動し）、サーバ１からクライアント２へは、自動機能追加更新ファイルあるいは自動機能追加更新プロセス起動コマンドの送信を行わずに、ストリームの最初から機能更新ファイルを配信するようにしてもよい。

ところで、これまでは、主にアプリケーションのストリームが連続して送られてくる場合について説明したが、アプリケーションがバージョンアップするときに、バージョンアップのための機能更新ファイル（群）からなるストリームの配信を行う場合に本発明を適用することも同様に可能である。この場合も、ユーザは使用しているアプリケーションを停止することなく使い続けたままアプリケーションのアップグレードが可能である。

例えば、図２６のシーケンス例に示すように、自動機能追加更新プロセスによって起動されたソフトウェアの実行中に、さらに、例えばユーザの要求に応じるなどして該ソフトウェアのバージョンアップのためのストリーミング要求をサーバ１へ送信し、サーバ１からクライアント２へ、バージョンアップのための機能更新ファイルを送信し、クライアント２において、該ソフトウェアを該機能更新ファイルでバージョンアップするようにすることも可能である。

あるいは、クライアント２がユーザの要求に応じて又は定期的に若しくは何らかの条件が成立したときにあるソフトウェアのバージョンアップのためのストリーミング要求をサーバ１へ送信するような場合に、該ソフトウェアが自動機能追加更新プロセスによって起動されて実行中であっても、同様にして、バージョンアップのための機能更新ファイルをダウンロードして、該ソフトウェアをバージョンアップすることが可能になる（なお、該ソフトウェアが実行中でなければ、例えば、バージョンアップのための機能更新ファイルをダウンロードして、格納しておけばよい）。

また、サーバ１が必要時にソフトウェアのバージョンアップのためのストリームをクライアント２へプッシュする場合に、該ソフトウェアが自動機能追加更新プロセスによって起動されて実行中であっても、同様にして、バージョンアップのための機能更新ファイルをダウンロードして、該ソフトウェアをバージョンアップすることが可能になる（なお、該ソフトウェアが実行中でなければ、例えば、バージョンアップのための機能更新ファイルをダウンロードして、格納しておけばよい）。

さて、ストリーミング配信によるソフトウェアの利用を行った後においては、配信された自動機能追加更新ファイルと１又は複数の機能更新ファイルとそれらに対応するプロファイル情報をクライアント２上からは削除し、次に同じソフトウェアを利用する際にはあらためてストリーミング配信を受けるようにするような形態で実施することも可能であるが、そのようにするのではなく、配信された自動機能追加更新ファイルと１又は複数の機能更新ファイルとそれらに対応するプロファイル情報をクライアント２内に保存しておき、その後に、ユーザはそのソフトウェアを使用したいときに、そのソフトウェアが保存されていれば、そのソフトウェアの起動を指示し、クライアント２は、ユーザから該ソフトウェアに対する要求を受けた場合には、サーバ１へ要求を出さずに、クライアント２内に存在する自動機能追加更新ファイルと１又は複数の機能更新ファイルとそれらに対応するプロファイル情報を使って、該ソフトウェアを起動できるようにすることも可能である。すなわち、図２７に示すように、ストリーミング配信のときと同様に、まず、自動機能追加更新プロセスを起動し、以降、自動機能追加更新プロセスがプロファイル情報を参照しながら機能更新ファイルに所定の機能部を追加又は更新していく。なお、ユーザが自動機能追加更新プロセスを起動する方法については、例えば、自動機能追加更新ファイルを、アプリケーションのアイコンとして表示し、このアイコンをユーザがマウスでダブルクリックなどすることによって、起動するようにする方法をとれば、ユーザは通常のアプリケーションとストリーミングによるアプリケーションとの区別を特に意識せずに起動させることができる。

また、初期バージョンの機能更新ファイルおよびバージョンアップするごとに配信される機能更新ファイルを、そのバージョンを示す情報を対応付けて格納しておき、ユーザがバージョンを指定できるようにしてもよい。この場合、指定されたバージョンに対応する機能更新ファイルを使用すればよい。また、ユーザがバージョンを指定しなかった場合には、最新バージョンで起動し、ユーザがバージョンを指定した場合には、指定されたバージョンで起動するような方法も可能である。

また、例えば、配信された自動機能追加更新ファイルと１又は複数の機能更新ファイルとそれらに対応するプロファイル情報をクライアント２内に保存しておき、その後に、ユーザはそのソフトウェアを使用したいときに、そのソフトウェアが保存されているか否かを考慮せずに、そのソフトウェアの配信（あるいは起動）を指示し、クライアント２は、ユーザから該ソフトウェアに対する要求を受けた場合には、そのソフトウェアが保存されているか否か調べ、保存されていれば、サーバ１へ要求を出さずに、保存されている自動機能追加更新ファイルと１又は複数の機能更新ファイルとそれらに対応するプロファイル情報を使って、該ソフトウェアを起動できるようにすることも可能である。すなわち、この場合には、サーバ１に対するキャッシュとして機能する（アプリケーションの全機能が短時間で起動することになる）。

なお、例えば図２８に示すように、イントラネット１００内にプロキシサーバ（あるいはキャッシュサーバ等）１０１が存在するような構成において、本発明は、該プロキシサーバ１０１にも適用可能である。すなわち、プロキシサーバ１０１は、サーバ１からのソフトウェアのストリーミング配信が行われた際に、配信された自動機能追加更新ファイルと１又は複数の機能更新ファイルとそれらに対応するプロファイル情報を保存しておき、その後にイントラネット１００内のクライアント２からストリーミング要求があった際に、指定されたプログラムについての自動機能追加更新ファイルと１又は複数の機能更新ファイルとそれらに対応するプロファイル情報が自プロキシ内に保存されていれば、自プロキシから要求元のクライアント２へストリーミング配信を行い、自プロキシ内に保存されていなければ、該当するサーバ２へ指定のソフトウェアについてのストリーミング要求を転送するようにしてもよい。

また、本発明は、暗号化されたコンピュータプログラムの配信にも適用可能である。この場合には、転送時に、自動機能追加更新ファイル及び各機能更新ファイルを暗号化し、プロファイル情報は暗号化しない方法や、自動機能追加更新ファイル及び各機能更新ファイルに加えて、プロファイル情報の全部又は一部を暗号化する方法などがある。この場合、クライアント２は、自動機能追加更新ファイルや各機能更新ファイルなどを復号した後に、処理すればよい。

また、本発明は、通常のコンピュータプログラムだけでなく、移動エージェントのプログラムにも適用可能である。この場合、移動エージェントを本実施形態のようなストリーミングによって移動させれば、移動エージェントの全プログラムの転送が完了する前に、移動エージェントが処理を開始することができる。

なお、以上では、ソフトウェアあるいはバージョンアップ用のファイルをネットワークを介して配信する場合について説明したが、本発明は、ＣＤ−ＲＯＭ等のリムーバブル記録媒体からソフトウェアあるいはそのバージョンアップ用のファイルを読み込んで起動する場合にも適用可能である。この場合には、送受信処理部２１（あるいは、これと同様の機能を持つ処理部）が、ＣＤ−ＲＯＭ等のリムーバブル記録媒体から、ソフトウェアを構成する自動機能追加更新ファイルと各機能更新ファイルと各プロファイル情報、あるいはバージョンアップのための各機能更新ファイルと各プロファイル情報を、読み込めばよい。

なお、以上の各機能は、ソフトウェアとして実現可能である。
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムとして実施することもでき、該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。

なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。
また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。また、この発明の実施の形態は、個別装置としての発明、関連を持つ２以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。

本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。

本発明の一実施形態に係るネットワークシステムの構成例を示す図 同実施形態に係るサーバ・システムの構成例及びクライアント・システムの構成例を示す図 同実施形態に係るコンピュータプログラムのストリームのフォーマットの一例を示す図 同実施形態に係るコンピュータプログラムのストリームの一構成例を示す図 同実施形態に係るコンピュータプログラムのストリームの他の構成例を示す図 同実施形態に係るプロファイル情報のフォーマットの一例を示す図 同実施形態に係るプロファイル情報のフォーマットの一例を示す図 同実施形態に係るプロファイル情報のフォーマットの一例を示す図 同実施形態に係るネットワークシステムの基本的なシーケンスの一例を示す図 同実施形態に係るサーバ・システムの送受信処理部の処理手順の一例を示すフローチャート 同実施形態に係るクライアント・システムの送受信処理部の処理手順の一例を示すフローチャート 同実施形態の動作及び情報の流れについて説明するための図 同実施形態の動作及び情報の流れについて説明するための図 同実施形態の動作及び情報の流れについて説明するための図 同実施形態に係るクライアント・システム上で起動された自動機能追加更新部（自動機能追加更新プロセス）の処理手順の一例を示すフローチャート 同実施形態に係る自動機能追加更新部（自動機能追加更新プロセス）の最初の機能更新ファイルによるコンピュータプログラムの起動について説明するための図 同実施形態に係る自動機能追加更新部（自動機能追加更新プロセス）により起動されたコンピュータプログラムの表示画面例を示す図 同実施形態に係る自動機能追加更新部（自動機能追加更新プロセス）により起動されたコンピュータプログラムのメニュー画面例を示す図 同実施形態に係る自動機能追加更新部（自動機能追加更新プロセス）により起動されたコンピュータプログラムの表示画面例を示す図 同実施形態に係る自動機能追加更新部（自動機能追加更新プロセス）の機能更新ファイルによる機能部の追加について説明するための図 同実施形態に係る自動機能追加更新部（自動機能追加更新プロセス）により起動されたコンピュータプログラムの表示画面例を示す図 同実施形態に係る自動機能追加更新部（自動機能追加更新プロセス）により起動されたコンピュータプログラムのメニュー画面例を示す図 同実施形態に係る自動機能追加更新部（自動機能追加更新プロセス）の機能更新ファイルによる機能部の更新について説明するための図 同実施形態に係るネットワークシステムの基本的なシーケンスの他の例を示す図 同実施形態に係るネットワークシステムの基本的なシーケンスのさらに他の例を示す図 同実施形態に係るネットワークシステムの基本的なシーケンスの他の例を示す図 同実施形態に係るネットワークシステムの基本的なシーケンスの他の例を示す図 同実施形態に係るネットワークシステムの他の構成例を示す図

符号の説明

１…サーバ・システム、２…クライアント・システム、３…ネットワーク、１１，２１…送受信処理部、１２，２２…機能更新ファイル格納部、１３，２３…プロファイル情報格納部、２４…自動機能追加更新部

Claims (19)

1. 所定のネットワークを介してサーバ装置からアプリケーションプログラムのストリームによる配信を受けるクライアント装置であって、
   前記サーバ装置へ、前記アプリケーションプログラムのストリーミング要求を送信する手段と、
   前記サーバ装置が前記ストリーミング要求に応答して送信する、前記アプリケーションプログラムの基本的な機能を実現するための機能部群を含む基本システムを受信するとともに、前記サーバ装置が該基本システムの送信後に連続して送信する、前記アプリケーションプログラムに対して追加又は更新すべき機能を実現するための機能部と該機能部に関連する他の機能部の識別情報を含むプロファイル情報との組を、１組ずつ連続して受信する手段と、
   最初に、受信した前記基本システムを対象とし、該基本システムに含まれていない機能部を利用不可の状態にして、該基本システムを起動し、以降、受信した前記機能部を一つずつ対象とし、該機能部を動作可能にするとともに、該機能部に係る前記プロファイル情報に含まれる前記他の機能部に対して該機能部が利用可能になった旨を通知する制御を行う制御手段とを備えたことを特徴とするクライアント装置。
2. ある機能部が、別の機能部に係る機能の利用をユーザが選択するためのＧＵＩ画像の表示を行うものである場合に、該ある機能部は、該別の機能部が利用可能になった旨の通知を受けるまでは、該別の機能部に係る機能の利用をユーザが選択できない第１の状態にしておき、該別の機能部が利用可能になった旨の通知を受けたときに、該別の機能部に係る機能の利用をユーザが選択できる第２の状態に変更することを特徴とする請求項１に記載のクライアント装置。
3. 前記第１の状態にしておくにあたっては、前記ＧＵＩ画像の表示形態を、前記第１の状態であることをユーザに知らしめる表示形態にしておき、前記第２の状態に変更するにあたっては、前記ＧＵＩ画像の表示形態を、前記第２の状態であることをユーザに知らしめる表示形態に変更することを特徴とする請求項２に記載のクライアント装置。
4. 前記ＧＵＩ画像は、メニューを表現する画像であることを特徴とする請求項２または３に記載のクライアント装置。
5. 前記制御手段は、動作可能にする前記機能部が前記更新すべき機能部である場合には、該更新すべき機能部を動作可能にするのに加えて、該更新すべき機能部により更新される元の機能部を動作不可にすることを特徴とする請求項１ないし３のいずれか１項に記載のクライアント装置。
6. 前記制御手段は、前記旨を通知する対象となる前記他の機能部が未だ動作可能になっていない場合に、該他の機能部が動作可能になった後に前記旨を通知するための制御を行うことを特徴とする請求項１ないし５のいずれか１項に記載のクライアント装置。
7. 前記制御手段は、ある機能部を動作可能にしたならば、前記旨を通知する対象となる前記他の機能部が未だ動作可能になっていないために、前記旨の通知ができないことになる場合には、該他の機能部が動作可能になった後に、該ある機能部を動作可能にするとともに、該他の機能部に対して該ある機能部が利用可能になった旨を通知することを特徴とする請求項１ないし５のいずれか１項に記載のクライアント装置。
8. 前記制御手段は、受信した前記機能部を、予め定められた順番で、動作可能にしていくことを特徴とする請求項１ないし７のいずれか１項に記載のクライアント装置。
9. 前記制御手段は、前記ストリーミング要求を与えた前記サーバ装置から受信した所定のプログラムを所定のプロセスとして起動することによって実現されたものであることを特徴とする請求項１ないし８のいずれか１項に記載のクライアント装置。
10. 前記制御手段は、前記ストリーミング要求を与えた前記サーバ装置から所定の起動命令を受信したことを契機として、自装置が予め保持している所定のプログラムを所定のプロセスとして起動することによって実現されたものであることを特徴とする請求項１ないし８のいずれか１項に記載のクライアント装置。
11. 前記制御手段は、ユーザから所定の要求が入力されたこと又は自装置上で動作する他のプロセスから所定の要求が出されたことを契機として、自装置が予め保持している所定のプログラムを所定のプロセスとして起動することによって実現されたものであることを特徴とする請求項１ないし８のいずれか１項に記載のクライアント装置。
12. ユーザから所定の要求が入力されたこと又は自装置上で動作する他のプロセスから所定の要求が出されたことを契機として、前記ストリーミング要求の送信が行われることを特徴とする請求項９ないし１１のいずれか１項に記載のクライアント装置。
13. 前記ストリーミング要求を与えた前記サーバ装置から受信した前記アプリケーションプログラムに係る前記基本システム並びに所定組数の前記機能部及び前記プロファイル情報を保存するための保存手段を更に備えたことを特徴とする請求項１ないし１２のいずれか１項に記載のクライアント装置。
14. 前記保存手段に前記アプリケーションプログラムに係る前記基本システム並びに所定組数の前記機能部及び前記プロファイル情報が保存されている場合には、前記サーバ装置へ前記ストリーミング要求を送信せずに、前記保存手段に保存されている前記基本システム並びに前記機能部及び前記プロファイル情報を対象として前記制御手段による前記制御を行うことを特徴とする請求項１３に記載のクライアント装置。
15. 前記アプリケーションプログラムは、ワードプロセッサーのプログラムであることを特徴とする請求項１ないし１４のいずれか１項に記載のクライアント装置。
16. 前記基本システムは、少なくとも文字入力に係る機能部を含むものであり、
    前記追加すべき機能部には、文字レイアウト調整に係る機能部、図形描画に係る機能部、及び印刷に係る機能部が存在することを特徴とする請求項１５に記載のクライアント装置。
17. 前記更新すべき機能部には、これにより更新される元の機能部と同種で且つ該元の機能部よりも高度な機能を実現する機能部が存在することを特徴とする請求項１５または１６に記載のクライアント装置。
18. 所定のネットワークを介してサーバ装置からアプリケーションプログラムのストリームによる配信を受けるクライアント装置におけるソフトウェアストリーミング方法であって、
    前記サーバ装置へ、前記アプリケーションプログラムのストリーミング要求を送信するステップと、
    前記サーバ装置が前記ストリーミング要求に応答して送信する、前記アプリケーションプログラムの基本的な機能を実現するための機能部群を含む基本システムを受信するステップと、
    前記基本システムを受信した場合に、該基本システムに含まれていない機能部を利用不可の状態にして、該基本システムを起動するステップと、
    前記サーバ装置が前記基本システムの送信後に連続して送信する、前記アプリケーションプログラムに対して追加又は更新すべき機能を実現するための機能部と該機能部に関連する他の機能部の識別情報を含むプロファイル情報との組を、１組ずつ連続して受信するステップと、
    受信した前記機能部を一つずつ対象とし、該機能部を動作可能にするとともに、該機能部に係る前記プロファイル情報に含まれる前記他の機能部に対して該機能部が利用可能になった旨を通知するステップとを有することを特徴とするソフトウェアストリーミング方法。
19. 所定のネットワークを介してサーバ装置からアプリケーションプログラムのストリームによる配信を受けるクライアント装置としてコンピュータを機能させるためのプログラムであって、
    前記サーバ装置へ、前記アプリケーションプログラムのストリーミング要求を送信するステップと、
    前記サーバ装置が前記ストリーミング要求に応答して送信する、前記アプリケーションプログラムの基本的な機能を実現するための機能部群を含む基本システムを受信するステップと、
    前記基本システムを受信した場合に、該基本システムに含まれていない機能部を利用不可の状態にして、該基本システムを起動するステップと、
    前記サーバ装置が前記基本システムの送信後に連続して送信する、前記アプリケーションプログラムに対して追加又は更新すべき機能を実現するための機能部と該機能部に関連する他の機能部の識別情報を含むプロファイル情報との組を、１組ずつ連続して受信するステップと、
    受信した前記機能部を一つずつ対象とし、該機能部を動作可能にするとともに、該機能部に係る前記プロファイル情報に含まれる前記他の機能部に対して該機能部が利用可能になった旨を通知するステップとをコンピュータに実行させることを特徴とするプログラム。

Images