JP2005293492A - サーバ、端末、および情報システム - Google Patents

Abstract

【課題】 サーバベースドコンピューティングシステムにおいて、サーバ上で動作させるのに適さないアプリケーションの利用を可能にする。
【解決手段】 サーバ１１は、端末２０からのサービス要求に対応する対象アプリケーションを端末２０上で起動させるアプリケーション実行要求部１３を備え、アプリケーション実行要求部１３は、端末情報管理テーブル１９から、端末２０に関する情報を取得する接続先情報取得部１４と、アプリケーション情報コンフィグレーションファイル１８から、起動対象アプリケーションの起動に必要な起動情報を取得する起動アプリケーション情報取得部１５と、端末２０に起動情報と共に起動対象アプリケーションの起動要求を通知する起動要求部１６と、端末２０から対象アプリケーションの終了通知を受信した時に、アプリケーション実行要求部１３の処理を終了させるアプリケーション状態受信部１７を備える。
【選択図】 図１

Description

この発明は、サーバベースドコンピューティング（以下、ＳＢＣと記す。）システムにおける、サーバ、クライアント、および情報システムに関するものである。

近年のハードウェア技術、ソフトウェア技術の高度化に伴い、端末上で動作するアプリケーションについても多量のハードウェア資源を必要とするものが増えている。このようなアプリケーションを利用することは、高性能な端末でなければ困難である。一方、情報システムの管理の面から見ると、アプリケーションを端末にインストールして利用する場合、集中管理が困難になるという問題がある。

このような問題を解決するための方法として、ＳＢＣシステムの利用がある。ＳＢＣシステムでは、従来端末上で動作させていたアプリケーションをサーバ上で動作させる。サーバは、端末上に画面の遷移情報を送信し、端末からのキーボードやマウスを介した入力情報を受信することにより、端末からの指示に基づいてアプリケーションを動作させる。

ＳＢＣシステムを実現するミドルウェアとして、Ｃｙｔｒｉｘ社のＭｅｔａＦｒａｍｅやＧｒａｐｈＯｎ社のＧｏＧｌｏｂａｌなどが知られている。これらのＳＢＣミドルウェアを利用する場合、端末にはＳＢＣミドルウェアが提供するクライアントモジュールを予めインストールしておく。あるいは、動作時にダウンロードすることもできる。端末は、このクライアントモジュールを介してサーバ上のＳＢＣミドルウェアが提供するサーバモジュールと通信することにより、サーバ上で動作するアプリケーションを利用することができる。

ＳＢＣシステムを利用すれば、端末のＣＰＵ性能やメモリ容量不足により端末上では動作不可能であったアプリケーションが、サーバ上で動作させることにより当該端末から利用できるようになる。
また、すべてのアプリケーションがサーバ上にインストールされることから、アプリケーションの集中管理が可能となり、バージョンアップ等を容易に行うことができる。

このような、ＳＢＣシステムを利用した従来の技術の例として、特許文献１に開示された適応型画像制御システム装置がある。このシステム装置は、端末とサーバ間のネットワークの接続形態と起動するアプリケーションの特性に基づいて決定された画質制御情報をクライアントに通知し、クライアントは通知された情報に基づいて解像度の動的変更を行うことにより、快適なアプリケーション利用環境を実現する。

また、特許文献２に開示されたシステム装置は、サーバに搭載されたアプリケーションにより提供される画面更新情報をクライアントに転送すると共に、アプリケーションの操作権を有するクライアントからの操作情報はサーバに転送し、アプリケーション操作権は持たず、アプリケーション閲覧権のみを有するクライアントからの操作情報はサーバに転送せず破棄することにより、コラボレーションを実現するものである。

また、クライアントサーバモデルなどの遠隔アプリケーション実行形態の従来技術の例として以下のようなものがある。
例えば、特許文献３に記載された従来のＧＵＩアプリケーション実行システムでは、サーバがジョブデーモンを介して受信した端末からのリクエストに基づいてＧＵＩアプリケーションを起動することにより、端末からのサーバ上のＧＵＩアプリケーションの操作を可能とする。
また、特許文献４に記載された従来の計算機システムでは、サーバは、端末から受信した、端末上で動作している業務アプリケーションの稼動状況に基づき、管理端末からの要求に応じて端末上の起動停止関連コマンドを動作させることにより非運用中の端末を一斉または個別に起動停止させる。
また、特許文献５に記載された従来の遠隔サービス実行制御システムは、端末側からサーバ上のアプリケーションの起動要求があった場合に、同じアプリケーション起動可能なサーバのうち、最も負荷が低いサーバにその起動要求を送信するものである。

特開２００３−１４１０１０号公報 特開２００３−１８６８１５号公報 特開２００３−２８８２２３号公報 特開２００２−２４４７７０号公報 特開平５−１３４９５９号公報

しかし、ＳＢＣシステムではすべてのアプリケーションをサーバ上で動作させるため、例えば、ストリーミングを視聴するアプリケーションや端末上のデバイスを利用するアプリケーションなどには対応できないという課題があった。
ストリーミングを視聴するアプリケーションをサーバ上で動作させる場合、サーバは、まずストリーミングデータを受信して表示可能な形式に変換し、変換した情報を端末に送信するためのデータを作成し、端末にデータを送信する。これらの処理を行うため、サーバ上のリソースは多量に使用される。また、ストリーミングデータは帯域使用量を最小限に抑えるために圧縮などの処理が行われているが、ＳＢＣシステムではそのデータをすべて解凍した状態で端末に送信するため、ネットワークのリソースも多量に利用される。
また、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）等の端末上のデバイスを利用するアプリケーションについては、サーバアプリケーションから端末上のデバイスを直接制御することができないため、サーバ上で動作させることが出来ない。
特許文献１および特許文献２に記載の技術では、ＳＢＣシステムのサーバ上でアプリケーションを起動するので、サーバやネットワークのリソースを多量に消費するアプリケーションや端末上のデバイスを利用するアプリケーションをＳＢＣシステムで利用することが出来ない。

また、特許文献３に記載された技術は、クライアントプログラム側で起動するアプリケーション名および起動先端末情報をユーザが入力する入出力手段を保持し、その情報を基にサーバ上でアプリケーションが起動されることになる。このクライアントプログラムをサーバ上で動作するようにし、ＳＢＣシステムに登録した場合、ＳＢＣシステムからのリクエストに応じてクライアント画面がＳＢＣシステム経由で端末上に表示されることとなる。その画面で自身の端末名と起動するアプリケーションの情報を入力すると、ＳＢＣシステム経由でクライアントアプリケーションにユーザの入力情報が渡され、その情報を基に端末上でアプリケーションを起動するように端末上のジョブデーモンに送られ、端末上でアプリケーションが起動され、そのアプリケーションの画面情報がクライアントプログラムに戻り、ＳＢＣシステム経由で画面情報が端末上に表示されることになる。この方式では、端末、サーバ間で画面情報を何度も送受信するため、ネットワークのリソースを多量に消費する。あるいは、端末、サーバ上でデータ変換等を行う必要があり、サーバ上、端末上のリソースも多量に消費してしまうこととなる。
また、特許文献４に記載された技術における管理端末上のアプリケーションをサーバ上で動作するようにし、ＳＢＣシステムに登録した場合、ＳＢＣシステムからリクエストが来た際に、どの端末からの要求かを判断する手段がないため起動先端末情報を取得できない。さらに、管理端末上のアプリケーションを起動できた場合であっても、リクエスト送信先端末は、起動要求を行った端末ではなく業務アプリケーションの稼動状況から判断されてしまうため、実際にアプリケーションが起動される端末が起動要求端末とならない場合がある。
また、特許文献５に記載された技術において、クライアントアプリケーションをサーバ上で動作させるようにし、ＳＢＣシステムに登録した場合、ＳＢＣシステムからリクエストが来た際に、どの端末からの要求かを判断する手段がないため、起動先端末情報を取得することが出来ない。さらに、クライアントアプリケーションを起動できた場合であっても、リクエストが最も負荷の低いサーバに送信されてしまうため、要求元の端末のサービスを起動することが出来ない。

この発明は上記のような課題を解決するためになされたもので、端末からのサービス要求に対して、ＳＢＣシステムのユーザインタフェースを変えることなく、サーバ上で動作させるのに適さないアプリケーションの利用を可能にすることを目的とする。

この発明に係るサーバは、端末からのサービス要求に基づいてコンピュータプログラムを動作させるサーバにおいて、端末に関する情報を格納する端末情報管理テーブルと、サービス要求に基づいて起動するコンピュータプログラムの情報を格納するアプリケーション情報コンフィグレーションファイルと、サービス要求に対応する起動対象コンピュータプログラムを端末上で起動させるアプリケーション実行要求部を備え、アプリケーション実行要求部は、アプリケーション情報コンフィグレーションファイルから、起動対象コンピュータプログラムの起動に必要な起動情報を取得する起動アプリケーション情報取得部と、端末情報管理テーブルから、サービス要求を送信した端末の情報を取得し、その端末に起動情報と共に起動対象コンピュータプログラムの起動要求を通知する起動要求部と、端末から起動対象コンピュータプログラムの終了通知を受信した時に、アプリケーション実行要求部の処理を終了させるアプリケーション状態受信部を備えたものである。

この発明に係る端末は、サーバにサービス要求を送信して、サーバ上でコンピュータプログラムを動作させる端末において、サーバからアプリケーション起動要求を受信し、起動要求のあったコンピュータプログラムを起動するアプリケーション実行部を備え、アプリケーション実行部は、アプリケーション起動要求を受信する起動要求受信部と、アプリケーション起動要求に基づいて、対象コンピュータプログラムを検索して起動するアプリケーション起動部と、対象コンピュータプログラムが終了したら、サーバに終了通知を送信するアプリケーション状態通信部を備えたものである。

この発明に係る情報システムは、端末からの要求に基づいて、サーバ上でコンピュータプログラムを動作させる情報システムにおいて、サーバは、端末に関する情報を格納する端末情報管理テーブルと、サービス要求に基づいて起動するコンピュータプログラムの情報を格納するアプリケーション情報コンフィグレーションファイルと、サービス要求に対応する起動対象コンピュータプログラムを端末上で起動させるアプリケーション実行要求部を備え、アプリケーション実行要求部は、アプリケーション情報コンフィグレーションファイルから、起動対象コンピュータプログラムの起動に必要な起動情報を取得する起動アプリケーション情報取得部と、端末情報管理テーブルから、サービス要求を送信した端末の情報を取得し、その端末に起動情報と共に起動対象コンピュータプログラムの起動要求を通知する起動要求部と、端末から起動対象コンピュータプログラムの終了通知を受信した時に、アプリケーション実行要求部の処理を終了させるアプリケーション状態受信部を備え端末は、サーバからアプリケーション起動要求を受信し、起動要求のあったコンピュータプログラムを起動するアプリケーション実行部を備え、アプリケーション実行部は、アプリケーション起動要求を受信する起動要求受信部と、アプリケーション起動要求に基づいて、対象コンピュータプログラムを検索して起動するアプリケーション起動部と、対象コンピュータプログラムが終了したら、サーバに終了通知を送信するアプリケーション状態通信部を備えたものである。

端末からの起動要求に応じて、サーバのアプリケーション実行要求部が端末上のアプリケーションを起動するようにしたので、ＳＢＣシステムのユーザインタフェースを変えることなくサーバ上で動作させるのに適さないアプリケーションを利用することができる。

以下、この発明の実施の様々な形態を説明する。
実施の形態１．
図１は、この発明の実施の形態１による、ＳＢＣシステム１０の構成を示すブロック図である。
図に示すように、ＳＢＣシステム１０は、サーバ１１、端末２０を備えており、サーバ１１と端末２０は、通信回線２７を介して接続されている。通信回線２７は、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等のネットワークである。

サーバ１１は、ＳＢＣサーバ部１２、アプリケーション実行要求部１３、アプリケーション情報コンフィグレーションファイル１８、端末情報管理テーブル１９を備えている。
ＳＢＣサーバ部１２、アプリケーション実行要求部１３は、サーバ１１のプロセッサを動作させるプログラムのＳＢＣサーバモジュールおよびアプリケーション実行要求モジュールを表しており、これらは実際には一体としてプロセッサを構成する。
アプリケーション情報コンフィグレーションファイル１８および端末情報管理テーブル１９は記憶装置に格納される。記憶装置は、サーバ１１のメモリであってもよいし、サーバ１１と通信回線を介して接続される外部の記憶装置であってもよい。なお、アプリケーション情報コンフィグレーションファイル１８および端末情報管理テーブル１９は、同一の記憶装置に格納されていてもよい。
アプリケーション実行要求部１３は、接続先情報取得部１４、起動アプリケーション情報取得部１５、起動要求部１６、アプリケーション状態受信部１７を備えている。

端末２０は、ＳＢＣクライアント部２１、アプリケーション実行部２２、および起動対象アプリケーション２６を備えている。
ＳＢＣクライアント部２１、アプリケーション実行部２２は、端末２０のプロセッサを動作させるプログラムのＳＢＣクライアントモジュールおよびアプリケーション起動モジュールを表しており、これらは実際には一体としてプロセッサを構成する。
起動対象アプリケーション２６は、端末２０のプロセッサ上で動作するプログラムを表しており、実際には当該プロセッサの一部である。
アプリケーション実行部２２は、起動要求受信部２３、アプリケーション起動部２４、およびアプリケーション状態通信部２５を備えている。

次に、動作について説明する。
図２は、実施の形態１によるＳＢＣシステム１０の動作のフローチャートである。ここでは、サーバ１１のアプリケーション実行要求部１３と端末２０のアプリケーション実行部２２との間の処理を示している。
まず端末２０のＳＢＣクライアント部２１から、サーバ１１のＳＢＣサーバ部１２に対してアプリケーション実行要求部１３の起動要求が通知され、ＳＢＣサーバ部１２はアプリケーション実行要求部１３を起動する（ステップＳＴ１０１）。
起動要求には、起動を要求するアプリケーションの識別子が含まれる。

アプリケーション実行要求部１３が起動すると、接続先情報取得部１４は、端末情報管理テーブル１９を参照し、起動要求を送信した端末２０の情報を取得する（ステップＳＴ１０２）。端末情報管理テーブル１９の内容は、ＳＢＣサーバ部１２が提供する情報を基に生成され、接続先情報取得部１４は、ＳＢＣサーバ部１２経由で送信されたアプリケーション起動要求の送信元の端末情報を取得することができる。端末情報管理テーブル１９は、サーバ１１が各端末と通信する際に必要なネットワーク上のアドレス等の情報を保持している。

次に、起動アプリケーション情報取得部１５は、アプリケーション情報コンフィグレーションファイル１８を参照し、通知されたアプリケーション識別子に対応するアプリケーションについてのアプリケーション起動情報を取得する（ステップＳＴ１０３）。ここでは、アプリケーション識別子は、例えば、「Ｍｅｄｉａ Ｐｌａｙｅｒ」や「Ｂｒｏｗｓｅｒ」などのアプリケーションの種類を表す名称である。

図３は、実施の形態１による、アプリケーション情報コンフィグレーションファイル１８の例を示す図である。図に示すように、アプリケーション情報コンフィグレーションファイル１８には、あるアプリケーション識別子に対応するアプリケーションの起動に必要な情報が、＜ａｐｐｌｉｃａｔｉｏｎ＞タグの間に記述されている。
起動アプリケーション情報取得部１５は、例えば、アプリケーション識別子が「Ｂｒｏｗｓｅｒ」の場合、＜ａｐｐｌｉｃａｔｉｏｎ＞タグのｎａｍｅ属性がＢｒｏｗｓｅｒの部分の情報をすべて取得する。＜ａｐｐｌｉｃａｔｉｏｎ＞タグの１階層下には＜ｐｌａｔｆｏｒｍ＞タグがあり、各ＯＳに対応した、当該アプリケーション識別子のアプリケーション名（ａｐｐｎａｍｅ）や関連付け情報などが記述されている。

次に、起動要求部１６は、ステップＳＴ１０２で取得された端末２０の情報に基づいて、端末２０のアプリケーション実行部２２の起動要求受信部２３との間で接続を行い、ステップＳＴ１０３で取得されたアプリケーション情報を起動要求受信部２３に送信する（ステップＳＴ１０４）。
アプリケーション状態受信部１７は、端末２０のアプリケーション実行部２２のアプリケーション状態通信部２５からのアプリケーション終了通知を受信するまで待機する（ステップＳＴ１０５）。

一方、端末２０のアプリケーション実行部２２の起動要求受信部２３は、アプリケーション実行要求部１３の起動要求部１６からの起動要求およびアプリケーション情報の受信を待機する（ステップＳＴ１０８）。
ステップＳＴ１０８で起動要求およびアプリケーション情報を受信すると、アプリケーション起動部２４は、受信したアプリケーション情報に基づいて該当アプリケーションを検索する（ステップＳＴ１０９）。
アプリケーション起動部２４は、取得したアプリケーション（ここでは、起動対象アプリケーション２６とする。）をアプリケーション実行部２２配下のプロセスとして起動する（ステップＳＴ１１０）。
アプリケーション状態通信部２５は、当該プロセスの終了通知の受信を待つ（ステップＳＴ１１１）。

アプリケーション状態通信部２５は、プロセスの終了通知を受信すると、サーバ１１のアプリケーション実行要求部１３のアプリケーション状態受信部１７に、アプリケーションの終了を通知する（ステップＳＴ１１２）。
ステップＳＴ１０５でアプリケーション状態受信部１７がアプリケーション終了通知を受信すると、アプリケーション実行要求部１３の処理が終了する。

以上のように、実施の形態１によれば、端末２０のＳＢＣクライアント部２１からの起動要求に応じて、サーバ１１のアプリケーション実行要求部１３が端末２０上のアプリケーションを起動するようにしたので、端末２０のユーザは、ＳＢＣシステムのインタフェースを利用して、自端末上のアプリケーションを操作することができる。これにより、ＳＢＣシステムにおいて、ストリーミングを視聴するアプリケーションや端末上のデバイスを利用するアプリケーションのように、サーバ上で動作させるのに適さないアプリケーションを利用することが可能となる。

また、アプリケーション情報コンフィグレーションファイル１８に、端末側で該当アプリケーションを起動するのに必要な情報を格納し、端末２０に適宜必要な情報を送信するようにしたので、端末の使用ＯＳ等に依存せず、端末上のアプリケーションを起動することが可能となる。
また、アプリケーション実行要求部１３は、端末２０上で起動されたアプリケーションの終了情報を受信してから処理を終了するようにしたので、サーバ上でアプリケーションを動作させる場合と同等の管理が可能となる。
また、アプリケーション実行要求部１３は、端末情報管理テーブル１９を備え、アプリケーションの利用要求を受信する毎に該当端末の情報を取得するようにしたので、多数の端末を備えたＳＢＣシステムでも対応することができる。

実施の形態２．
実施の形態２は、端末に起動対象のアプリケーションが実装されていない場合でも、ＳＢＣシステムのインタフェースを利用して、自端末上でアプリケーションを動作させる。

図４は、この発明の実施の形態２による、ＳＢＣシステム３０の構成を示すブロック図である。図に示すように、ＳＢＣシステム３０は、サーバ３１、端末３２を備えており、サーバ３１と端末３２は、通信回線２７を介して接続されている。また、図１と同一の符号は、同一の構成要素を表している。

図に示すように、サーバ３１のアプリケーション実行要求部３３は、インストールモジュール取得部３６を備えている。また、サーバ３１は、アプリケーションインストールモジュール３５を備えている。
アプリケーションインストールモジュール３５は、アプリケーション情報コンフィグレーションファイル１８および端末情報管理テーブル１９と同様に、記憶装置に格納される。
また、端末３２のアプリケーション実行部３４は、アプリケーションインストール部３７、アプリケーション削除部３８を備えている。

次に動作について説明する。
図５は、実施の形態２によるＳＢＣシステム３０の動作のフローチャートである。ここでは、サーバ３１のアプリケーション実行要求部３３と端末３２のアプリケーション実行部３４との間の処理を示している。
まず端末３２のＳＢＣクライアント部２１から、サーバ３１のＳＢＣサーバ部１２に対してアプリケーション実行要求部３３の起動要求が通知され、ＳＢＣサーバ部１２はアプリケーション実行要求部３３を起動する（ステップＳＴ１０１）。
起動要求には、起動を要求するアプリケーションの識別子が含まれる。

アプリケーション実行要求部３３が起動すると、接続先情報取得部１４は、端末情報管理テーブル１９を参照し、起動要求を送信した端末２０の情報を取得する（ステップＳＴ１０２）。また、起動アプリケーション情報取得部１５は、アプリケーション情報コンフィグレーションファイル１８を参照し、通知されたアプリケーション識別子に対応するアプリケーションについてのアプリケーション起動情報を取得する（ステップＳＴ１０３）。

次に、インストールモジュール取得部３６は、ステップＳＴ１０３で取得されたアプリケーション起動情報に基づいてアプリケーションインストールモジュール３５を検索し、該当するアプリケーションのインストールモジュールを取得する（ステップＳＴ２０１）。
次に、起動要求部１６は、ステップＳＴ１０２で取得された端末３２の情報に基づいて、端末３２のアプリケーション実行部３４の起動要求受信部２３との間で接続を行い、ステップＳＴ１０３で取得されたアプリケーション情報およびステップＳＴ２０１で取得されたインストールモジュールを起動要求受信部２３に送信する（ステップＳＴ２０２）。
アプリケーション状態受信部１７は、端末３２のアプリケーション実行部３４のアプリケーション状態通信部２５からのアプリケーション終了通知を受信するまで待機する（ステップＳＴ１０５）。

一方、端末３２のアプリケーション実行部３４の起動要求受信部２３は、アプリケーション実行要求部３３の起動要求部１６からの起動要求、アプリケーション情報およびインストールモジュールの受信を待機する（ステップＳＴ１０８）。
ステップＳＴ１０８で起動要求、アプリケーション情報およびインストールモジュールを受信すると、アプリケーション起動部２４は、受信したアプリケーション情報に基づいて該当アプリケーションを検索し、有無を確認する（ステップＳＴ１０９、ステップＳＴ２０３）。
ステップＳＴ２０３で、該当するアプリケーションが存在すると判断された場合には、ステップＳＴ１１０へ進む。

ステップＳＴ２０３で、該当するアプリケーションが存在しないと判断された場合には、アプリケーションインストール部３７は、サーバ３１から受信したインストールモジュールを用いてアプリケーションのインストールを行う（ステップＳＴ２０４）。
アプリケーション起動部２４は、ステップＳＴ２０４でインストールしたアプリケーションまたはステップＳＴ１０９で検出されたアプリケーションをアプリケーション実行部２２配下のプロセスとして起動する（ステップＳＴ１１０）。
アプリケーション状態通信部２５は、当該プロセスの終了通知の受信を待つ（ステップＳＴ１１１）。
アプリケーション状態通信部２５は、プロセスの終了通知を受信すると、サーバ３１のアプリケーション実行要求部３３のアプリケーション状態受信部１７に、アプリケーションの終了を通知する（ステップＳＴ１１２）。

次に、アプリケーション削除部３８は、終了したアプリケーションが、今回の起動のためにインストールしたモジュールか、既にインストール済みであったものかを判断する（ステップＳＴ２０５）。既にインストール済みであったアプリケーションの場合にはステップＳＴ１０８へ戻る。
ステップＳＴ２０５で、今回インストールしたモジュールであると判断された場合には、アプリケーション削除部３８は、そのモジュールの削除（アンインストール）を行う（ステップＳＴ２０６）。
ステップＳＴ１０５でサーバ３１のアプリケーション状態受信部１７がアプリケーション終了通知を受信すると、アプリケーション実行要求部３３の処理が終了する。

以上のように、実施の形態２によれば、サーバ３１からアプリケーションのインストールモジュールを送信し、端末３２が起動対象アプリケーションをインストールできるようにしたので、端末３２に元々存在しないアプリケーションを起動したい場合にも対応することが可能となる。
また、アプリケーション操作終了後はインストールしたアプリケーションを削除するようにしたので、アプリケーションの不正利用等を防ぐことが可能となる。また、インストールモジュールはサーバ３１で管理するようにしたので、アプリケーションの集中管理が可能となる。

実施の形態３．
実施の形態３では、実施の形態２において、起動要求のあったアプリケーションが端末上に存在しない場合にのみ、端末にアプリケーションのインストールモジュールを送信する。
実施の形態３によるＳＢＣシステムを構成するサーバおよび端末の構成は図４に示す実施の形態２と同様である。

図６は、実施の形態３によるＳＢＣシステムの動作のフローチャートである。ここでは、サーバ３１のアプリケーション実行要求部３３と端末３２のアプリケーション実行部３４との間の処理を示している。
まず端末３２のＳＢＣクライアント部２１から、サーバ３１のＳＢＣサーバ部１２に対してアプリケーション実行要求部３３の起動要求が通知され、ＳＢＣサーバ部１２はアプリケーション実行要求部３３を起動し（ステップＳＴ１０１）、接続先情報取得部１４は、端末情報管理テーブル１９を参照し、起動要求を送信した端末２０の情報を取得する（ステップＳＴ１０２）。また、起動アプリケーション情報取得部１５は、アプリケーション情報コンフィグレーションファイル１８を参照し、通知されたアプリケーション識別子に対応するアプリケーションについてのアプリケーション起動情報を取得する（ステップＳＴ１０３）。
次に、起動要求部１６は、ステップＳＴ１０２で取得された端末３２の情報に基づいて、端末３２のアプリケーション実行部３４の起動要求受信部２３との間で接続を行い、ステップＳＴ１０３で取得されたアプリケーション情報を起動要求受信部２３に送信する（ステップＳＴ２０２）。

一方、端末３２のアプリケーション実行部３４の起動要求受信部２３は、アプリケーション実行要求部３３の起動要求部１６からの起動要求およびアプリケーション情報の受信を待機する（ステップＳＴ１０８）。
ステップＳＴ１０８で起動要求およびアプリケーション情報を受信すると、アプリケーション起動部２４は、受信したアプリケーション情報に基づいて該当アプリケーションを検索し、有無を確認する（ステップＳＴ１０９、ステップＳＴ２０３）。該当するアプリケーションが存在すると判断された場合には、ステップＳＴ１１０へ進む。
ステップＳＴ２０３で該当するアプリケーションが存在すると判断されなかった場合、アプリケーションインストール部３７は、サーバ３１に対し、該当アプリケーションのインストール用モジュールの送信を依頼する、インストールモジュール要求を送信する（ステップＳＴ３０４）。

アプリケーション状態受信部１７は、端末３２からのアプリケーション終了通知またはインストールモジュール要求の受信を待機する（ステップＳＴ３０１）。
アプリケーション状態受信部１７は、端末３２から受け取った要求がアプリケーション終了通知かインストールモジュール要求通知かを判断する（ステップＳＴ３０２）。アプリケーション終了通知の場合には処理を終了する。インストールモジュール要求通知の場合、インストールモジュール取得部３６は、ステップＳＴ１０３で取得されたアプリケーション起動情報に基づいてアプリケーションインストールモジュール３５を検索し、該当するアプリケーションのインストールモジュールを取得する（ステップＳＴ２０１）。
アプリケーション状態受信部１７は、アプリケーションのインストールモジュールを端末３２に送信する（ステップＳＴ３０３）。

アプリケーションインストール部３７は、サーバ３１から受信したインストールモジュールを用いてアプリケーションのインストールを行う（ステップＳＴ２０４）。
アプリケーション起動部２４は、ステップＳＴ２０４でインストールしたアプリケーションまたはステップＳＴ１０９で検出されたアプリケーションをアプリケーション実行部２２配下のプロセスとして起動する（ステップＳＴ１１０）。アプリケーション状態通信部２５は、当該プロセスの終了通知の受信を待つ（ステップＳＴ１１１）。

アプリケーション状態通信部２５は、プロセスの終了通知を受信すると、サーバ３１のアプリケーション実行要求部３３のアプリケーション状態受信部１７に、アプリケーションの終了を通知する（ステップＳＴ１１２）。
アプリケーション削除部３８は、終了したアプリケーションが、今回の起動のためにインストールしたモジュールか、既にインストール済みであったものかを判断する（ステップＳＴ２０５）。既にインストール済みであったアプリケーションの場合にはステップＳＴ１０８へ戻る。
ステップＳＴ２０５で、今回インストールしたモジュールであると判断された場合には、アプリケーション削除部３８は、そのモジュールの削除（アンインストール）を行う（ステップＳＴ２０６）。
アプリケーション状態受信部１７が端末３２からのアプリケーション終了通知を受信すると（ステップＳＴ３０１、ステップＳＴ３０２）、アプリケーション実行要求部３３の処理が終了する。

以上のように、実施の形態３によれば、端末３２が起動アプリケーションの存在の有無をチェックし、アプリケーションが存在しない場合にのみサーバ３１からインストールモジュールの送信を行うようにしたので、端末３２に元々存在しないアプリケーションを起動したい場合にも対応することが可能となると共に、不要なインストールモジュールの送信が避けられ、ネットワーク使用量を削減することができる。
また、アプリケーション操作終了後はインストールしたアプリケーションを削除するようにしたので、アプリケーションの不正利用等を防ぐことが可能となる。また、インストールモジュールはサーバ３１で管理するようにしたので、アプリケーションの集中管理が可能となる。

実施の形態４．
実施の形態４は、端末から起動要求のあったアプリケーションを起動するだけでなく、他のアプリケーションからの要求により起動されるアプリケーションを端末上で起動させることを可能とする。具体的には、例えばプロトコルやファイルの拡張子に関連付けられたアプリケーションを端末上で起動することを可能とする。

図７は、この発明の実施の形態４による、ＳＢＣシステム５０の構成を示すブロック図である。図１および図４と同一の符号は同一の構成要素を表している。
図に示すように、ＳＢＣシステム５０は、サーバ５１、端末３２を備えており、サーバ５１と端末３２は、通信回線２７を介して接続されている。
サーバ５１は、関連付け変更部５４を備えている。関連付け変更部５４は、サーバ５１のプロセッサを動作させるプログラムの関連付け変更モジュールを表しており、実際には当該プロセッサの部分を構成する。
関連付け変更部５４は、コンフィグレーション情報取得部５５および関連付け変更処理部５６を備えている。

次に、動作について説明する。
図８は、実施の形態４による、サーバ５１の関連付け変更部５４の動作のフローチャートである。なお、サーバ５１のアプリケーション実行要求部３３と端末３２のアプリケーション実行部３４との間の処理は、実施の形態２または実施の形態３の処理と同様である。また、実施の形態１によるサーバ１１と端末２０に適用することもできる。
関連付け変更部５４は、サーバ５１に新たなアプリケーションをインストールした時や、アプリケーション情報コンフィグレーションファイル１８の内容が変更された時に起動される（ステップＳＴ４０１）。
まず、コンフィグレーション情報取得部５５は、アプリケーション情報コンフィグレーションファイル１８の内容を読み込む（ステップＳＴ４０２）。
コンフィグレーション情報取得部５５は、読み込んだアプリケーション情報コンフィグレーションファイル１８の中から、プロトコルやファイルの拡張子に関連する記載の有無を調べる（ステップＳＴ４０３）。それらの記載がない場合には、関連付け変更部５４の処理を終了する。
それらの記載が存在する場合、関連付け変更処理部５６は関連付けの変更を行う（ステップＳＴ４０４）。

関連付けの変更について、図３に示すアプリケーション情報コンフィグレーションファイル１８の例を用いて説明すると、＜ｐｒｏｔｏｃｏｌ＞タグが存在することにより、プロトコルに関連する記載が存在すると判断され、＜ｐｒｏｔｏｃｏｌ＞タグで記載されたｍｍｓプロトコルとそのプロトコルに関連付けられているアプリケーション識別子「Ｍｅｄｉａ Ｐｌａｙｅｒ」についての情報、すなわち＜ａｐｐｌｉｃａｔｉｏｎ＞タグのｎａｍｅ属性がＭｅｄｉａ Ｐｌａｙｅｒの部分の情報をすべて取得する。
関連付け変更処理部５６は、アプリケーション情報コンフィグレーションファイル１８から取得した情報を基に関連付け情報を変更する。例えばＷｉｎｄｏｗｓ（登録商標）の場合であればレジストリの変更等を行い、ｍｍｓプロトコルのＵＲＩで記載されたリンクのクリック時に起動されるアプリケーションをアプリケーション実行要求部３３にする。
全ての変更を終了すると関連付け変更部５４は終了する。

以上のように、実施の形態４によれば、コンフィグレーション情報取得部５５がアプリケーション情報コンフィグレーションファイル１８からプロトコルやファイルの拡張子に関する記述のあるアプリケーションの情報を取得し、関連付け変更処理部５６が必要に応じてサーバ上の関連付けを変更するようにしたので、端末３２上で起動させるアプリケーション上で、あるプロトコルのＵＲＩにより指定されるコンテンツが指定されている場合、或いは、ある拡張子を持つファイルが指定されている場合でも、端末３２上でそれらのコンテンツ等を利用することが可能となる。
例えば、サーバ５１で動作するブラウザ上で表示されているリンクをクリックした時、または、ファイルの選択時等に起動されるアプリケーションを、端末３２上で起動させることができる。

実施の形態５．
実施の形態５では、サーバ上に配置されているコンテンツを端末上で起動されたアプリケーションによって利用する。
図９は、この発明の実施の形態５による、ＳＢＣシステム６０の構成を示すブロック図である。図１、図４および図７と同一の符号は同一の構成要素を表している。
図に示すように、ＳＢＣシステム６０は、サーバ６１、端末３２を備えており、サーバ６１と端末３２は、通信回線２７を介して接続されている。
サーバ６１のアプリケーション実行要求部６３は、コンテンツ公開部６４を備えている。

次に、動作について説明する。
図１０は、実施の形態５によるＳＢＣシステム６０の動作のフローチャートである。ここでは、サーバ６１のアプリケーション実行要求部６３と端末３２のアプリケーション実行部３４との間の処理を示している。

まず端末３２のＳＢＣクライアント部２１から、サーバ６１のＳＢＣサーバ部１２に対してアプリケーション実行要求部６３の起動要求が通知され、ＳＢＣサーバ部１２はアプリケーション実行要求部６３を起動する（ステップＳＴ１０１）。
アプリケーション実行要求部６３が起動すると、接続先情報取得部１４は、端末情報管理テーブル１９を参照し、起動要求を送信した端末３２の情報を取得する（ステップＳＴ１０２）。
次に、起動アプリケーション情報取得部１５は、アプリケーション情報コンフィグレーションファイル１８を参照し、通知されたアプリケーション識別子に対応するアプリケーションについてのアプリケーション起動情報を取得する（ステップＳＴ１０３）。

次に、コンテンツ公開部６４は、アプリケーション実行要求部６３の起動時に、端末３２からの起動要求によって指定されている引数の情報に基づいて、サーバ６１上のコンテンツが指定されているかどうかを判断する（ステップＳＴ５０１）。
例えば、端末３２からの起動要求に従ってストリーミングを視聴するアプリケーションを起動する際、指定されたストリーミングデータが例えば、ｍｍｓ：／／（配信サーバ名）／（コンテンツ名）といったＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）形式で記載されており、どの端末やサーバからもアクセス可能な形式で示されている場合には、端末３２で起動するアプリケーションに引数としてそのＵＲＩをそのまま渡してもアクセス可能である。よって、このような場合には、たとえサーバ６１が配信するコンテンツであったとしても、サーバ６１上のコンテンツではないと判断する。
しかし、例えばストリーミングデータがＣ：￥（コンテンツ名）といったローカルファイルを指定する形式で示されている場合には、その引数をそのまま端末３２上のアプリケーションに渡すと、端末３２上のＣドライブが検索されてしまい当該コンテンツを検出することができない。よって、この場合には、サーバ６１上のコンテンツが指定されていると判断する。

ステップＳＴ５０１で、サーバ６１上のコンテンツが指定されていないと判断された場合にはステップＳＴ２０２へ進む。
サーバ６１上のコンテンツが指定されていると判断された場合、コンテンツ公開部６４は、コンテンツ公開を実施する（ステップＳＴ５０２）。
例えば、端末３２上でアプリケーションが実行されている間のみファイル共有を行い、ｆｉｌｅ：／／（ファイルサーバ名）／（コンテンツ名）といったＵＲＩでコンテンツへのアクセスを可能にし、そのＵＲＩを引数として端末３２に通知する。
また、例えばストリーミングデータを配信する場合には、ストリーミング配信サービス機能を端末３２上でのアプリケーション実行中のみ稼動させる。ストリーミングデータは、例えば「ｍｍｓ：／／（配信サーバ名）／（コンテンツ名）」というような形式のＵＲＩでアクセス可能にし、そのＵＲＩを引数として端末３２に通知する。
ステップＳＴ１０８で起動要求およびアプリケーション情報を受信すると、アプリケーション起動部２４は受信したアプリケーション情報に基づいて該当アプリケーションを検索し、有無を確認する（ステップＳＴ１０９、ステップＳＴ２０３）。該当するアプリケーションが存在すると判断された場合には、ステップＳＴ１１０へ進む。
ステップＳＴ２０３で該当するアプリケーションが存在すると判断されなかった場合には、アプリケーションインストール部３７は、サーバ３１にインストールモジュール要求を送信する（ステップＳＴ３０４）。

アプリケーション状態受信部１７は、端末３２からのアプリケーション終了通知またはインストールモジュール要求の受信を待機する（ステップＳＴ３０１）。
アプリケーション状態受信部１７は、端末３２から受け取った要求がアプリケーション終了通知かインストールモジュール要求通知かを判断する（ステップＳＴ３０２）。アプリケーション終了通知の場合には処理を終了する。インストールモジュール要求通知の場合、インストールモジュール取得部３６は、ステップＳＴ１０３で取得されたアプリケーション起動情報に基づいてアプリケーションインストールモジュール３５を検索し、該当するアプリケーションのインストールモジュールを取得する（ステップＳＴ２０１）。
アプリケーション状態受信部１７は、アプリケーションのインストールモジュールを端末３２に送信する（ステップＳＴ３０３）。

アプリケーションインストール部３７は、サーバ３１から受信したインストールモジュールを用いてアプリケーションのインストールを行う（ステップＳＴ２０４）。
アプリケーション起動部２４は、ステップＳＴ２０４でインストールしたアプリケーションまたはステップＳＴ１０９で検出されたアプリケーションをアプリケーション実行部２２配下のプロセスとして起動する（ステップＳＴ１１０）。アプリケーション状態通信部２５は、当該プロセスの終了通知の受信を待つ（ステップＳＴ１１１）。

アプリケーション状態通信部２５は、プロセスの終了通知を受信すると、サーバ３１のアプリケーション実行要求部３３のアプリケーション状態受信部１７に、アプリケーションの終了を通知する（ステップＳＴ１１２）。
アプリケーション削除部３８は、終了したアプリケーションが、今回の起動のためにインストールしたモジュールか、既にインストール済みであったものかを判断する（ステップＳＴ２０５）。既にインストール済みであったアプリケーションの場合にはステップＳＴ１０８へ戻る。
ステップＳＴ２０５で、今回インストールしたモジュールであると判断された場合には、アプリケーション削除部３８は、そのモジュールの削除（アンインストール）を行う（ステップＳＴ２０６）。

アプリケーション状態受信部１７が端末３２からのアプリケーション終了通知を受信すると（ステップＳＴ３０１、ステップＳＴ３０２）、コンテンツ公開部６４はコンテンツの公開を行ったかを判断する（ステップＳＴ５０３）。コンテンツの公開を行っていないと判断された場合には、公開の解除を行い（ステップＳＴ５０４）、アプリケーション実行要求部３３の処理を終了する。
なお、実施の形態５では、実施の形態３にコンテンツ公開部６４による処理を適用したが、実施の形態１、２および４にも同様に適用することができる。

以上のように、実施の形態５によれば、コンテンツ公開部６４は、アプリケーションを用いて利用されるコンテンツがサーバ６１上に配備されたコンテンツである場合には、端末３２上で動作するアプリケーションが認識可能な形式で引数を渡すようにしたので、端末３２で起動されるアプリケーションによってサーバ６１上のコンテンツを利用することが可能となる。

実施の形態６．
実施の形態６では、端末からの起動要求を受けて端末上にインストールした場合に、アプリケーションのライセンス数等の管理を可能とする。一般に、ＳＢＣシステムではアプリケーションがサーバ上でのみ動作するため、同時使用数などの管理を行う必要はないが、本発明の実施の形態２あるいは３のように、アプリケーションのインストールモジュールを端末に送信すると、現在の同時使用数を管理することが必要となる。

図１１は、この発明の実施の形態６による、ＳＢＣシステム７０の構成を示すブロック図である。図１、図４、図７および図９と同一の符号は同一の構成要素を表している。
図に示すように、ＳＢＣシステム７０は、サーバ７１、端末３２を備えており、サーバ７１と端末３２は、通信回線２７を介して接続されている。
サーバ７１は、アプリケーション管理部７５および起動アプリケーション管理テーブル７８を備えている。アプリケーション管理部７５は、サーバ７１のプロセッサを動作させるアプリケーション管理モジュールを表しており、実際には当該プロセッサの部分を構成する。
アプリケーション管理部７５は、リクエスト受信部７６および起動アプリケーション管理部７７を備えている。
起動アプリケーション管理テーブル７８は、アプリケーション情報コンフィグレーションファイル１８や端末情報管理テーブル１９などと同様に、記憶装置に格納される。
また、サーバ７１のアプリケーション実行要求部７３は、管理情報通信部７４を備えている。

図１２は、起動アプリケーション管理テーブル７８の内容の例を示す図である。
図に示すように、起動アプリケーション管理テーブル７８には、各々の管理対象のアプリケーション名に対応して、当該アプリケーションの同時実行ライセンス数、および現在、実際に端末上で起動しているアプリケーション数が保持されている。

次に、動作について説明する。
図１３は、実施の形態６による、サーバ７１のアプリケーション実行要求部７３とアプリケーション管理部７５との間の処理のフローチャートである。なお、サーバ７１のアプリケーション実行要求部７３と端末３２のアプリケーション実行部３４との間の処理は、実施の形態２の処理と同様である。
まず端末３２のＳＢＣクライアント部２１から、サーバ７１のＳＢＣサーバ部１２に対してアプリケーション実行要求部７３の起動要求が通知され、ＳＢＣサーバ部１２はアプリケーション実行要求部７３を起動する（ステップＳＴ１０１）。
アプリケーション実行要求部７３が起動すると、接続先情報取得部１４は、端末情報管理テーブル１９を参照し、起動要求を送信した端末３２の情報を取得する（ステップＳＴ１０２）。
次に、起動アプリケーション情報取得部１５は、アプリケーション情報コンフィグレーションファイル１８を参照し、通知されたアプリケーション識別子に対応するアプリケーションについてのアプリケーション起動情報を取得する（ステップＳＴ１０３）。

次に、管理情報通信部７４は、端末３２に送信するアプリケーションが現在起動可能かどうかをアプリケーション管理部７５に問い合わせる（ステップＳＴ６０７）。
アプリケーション管理部７５のリクエスト受信部７６は、管理情報通信部７４からの問い合わせを待ち受ける（ステップＳＴ６０２）。
起動アプリケーション管理部７７は、リクエスト受信部７６が管理情報通信部７４からの問い合わせを受信すると、その問い合わせの内容がアプリケーションの起動確認か終了通知かを判断する（ステップＳＴ６０３）。
起動確認と判断された場合には、起動アプリケーション管理部７７は起動アプリケーション管理テーブル７８を参照し、当該アプリケーションの現在の起動数が同時実行ライセンス数に達していなければ当該アプリケーションを起動可能と判断し、またライセンス数に達している場合には起動不可能と判断して、判断結果を管理情報通信部７４に通知する（ステップＳＴ６０４）。
なお、ここでは、ＯＳインストール時にデフォルトでインストールされるアプリケーション等、ライセンス管理が不要なアプリケーションは起動アプリケーション管理テーブル７８に登録されていないので、確認対象アプリケーションが起動アプリケーション管理テーブル７８に登録されていない場合には、起動可能と判断する。
起動アプリケーション管理部７７は、ステップＳＴ６０４で管理情報通信部７４に、起動可能と通知した場合には、起動アプリケーション管理テーブル７８中の当該アプリケーションの現在の起動数を１増加する（ステップＳＴ６０５）。起動不可と通知した場合には、起動アプリケーション管理テーブル７８の内容を更新せずに、ステップＳＴ６０２へ戻り、管理情報通信部７４からの問い合わせを待ち受ける。

ステップＳＴ６０３で、終了通知と判断された場合には、起動アプリケーション管理部７７は、起動アプリケーション管理テーブル７８中の、終了したアプリケーション名を基に現在の起動数を１減少する（ステップＳＴ６０６）。
アプリケーション実行要求部７３は、アプリケーション管理部７５から問い合わせに対する返答を受信すると、当該アプリケーションが起動可能か否かを判断する（ステップＳＴ６０８）。起動不可であった場合には、端末３２にその旨を通知して処理を終了する。
起動可能であった場合には、インストールモジュール取得部３６により、当該アプリケーションのインストールモジュールを取得し（ステップＳＴ２０１）、起動要求部１６により、アプリケーション情報と共に、起動要求受信部２３に送信する（ステップＳＴ２０２）。
端末３２における処理は実施の形態２と同様である。
アプリケーション状態受信部１７において、端末３２のアプリケーション実行部３４からのアプリケーション終了通知を受信すると（ステップＳＴ１０５）、管理情報通信部７４は、アプリケーション管理部７５にアプリケーションの終了通知を行う（ステップＳＴ６０９）。

以上のように、実施の形態６によれば、端末上で起動しているアプリケーションの起動数を起動アプリケーション管理テーブル７８を用いてアプリケーション毎に管理するようにしたので、同時実行ライセンス数を超えたアプリケーションの起動を防ぐことが可能となり、アプリケーションの不正利用を防止することができる。

実施の形態７．
実施の形態７は、端末上にインストールされているアプリケーションの情報や端末のＯＳ情報の管理を可能とする。
図１４は、この発明の実施の形態７による、ＳＢＣシステム８０の構成を示すブロック図である。図１、図４、図７、図９および図１１と同一の符号は同一の構成要素を表している。
図に示すように、ＳＢＣシステム８０は、サーバ８１、端末８５を備えており、サーバ８１と端末８５は、通信回線２７を介して接続されている。
サーバ８１のアプリケーション管理部８２は、端末情報管理部８３を備えている。また、サーバ８１は端末構成情報管理テーブル８４を備えている。端末構成情報管理テーブル８４は、アプリケーション情報コンフィグレーションファイル１８や端末情報管理テーブル１９などと同様に、記憶装置に格納される。

図１５は、端末構成情報管理テーブル８４の内容の例を示す図である。
図に示すように、端末構成情報管理テーブル８４には、各々の端末名に対応して、その端末上で動作しているＯＳ名、ＯＳのバージョン、および端末にインストールされているアプリケーションが保持されている。

次に、動作について説明する。
図１６は、実施の形態７による、サーバ８１のアプリケーション管理部８２と、端末８５のアプリケーション実行部８６との間の処理のフローチャートである。なお、サーバ８１のアプリケーション実行要求部７３と端末８５のアプリケーション実行部８６との間の処理、およびアプリケーション実行要求部７３とアプリケーション管理部８２との間の処理は、実施の形態６と同様である。
まず、端末８５のアプリケーション実行部８６において、端末情報取得部８７が、端末上のＯＳの情報やインストールされているアプリケーションの情報（以下、端末情報と記す。）を取得する（ステップＳＴ７０３）。
次に、端末情報送信部８８は、ステップＳＴ７０３で端末情報取得部８７が取得した端末情報をサーバ８１に送信する（ステップＳＴ７０４）。

サーバ８１において端末８５からの端末情報が受信されると、アプリケーション管理部８２のリクエスト受信部７６は、管理情報通信部７４からの問い合わせを待ち受ける（ステップＳＴ６０２）。
起動アプリケーション管理部７７は、リクエスト受信部７６が管理情報通信部７４からの問い合わせを受信すると、その問い合わせの内容を判断する（ステップＳＴ６０３、ステップＳＴ７０１）。
起動確認であった場合にはステップＳＴ６０４に進み、終了通知であった場合にはステップＳＴ６０６に進む。端末情報であった場合には、ステップＳＴ７０２に進み、端末情報管理部８３は、受信した端末情報を基に、端末構成情報管理テーブル８４の該当する端末名のＯＳ名、バージョン名、アプリケーションの情報を更新する（ステップＳＴ７０２）。

以上のように、実施の形態７によれば、端末８５上で動作しているＯＳや起動可能なアプリケーション情報をサーバ側で管理することが可能となり、インストールモジュールの送信が必要かどうか、或いは送信するインストールモジュールの種類等を事前に知ることが可能となる。

実施の形態８．
実施の形態８は、サーバのアプリケーション実行要求部がＳＢＣシステムを介さずに起動された場合に対応する。
関連付けの変更を行った場合、ＳＢＣシステム以外で起動されたアプリケーションから起動される場合が出てくる。これに対応する形態である。

図１７は、この発明の実施の形態８による、ＳＢＣシステム９０の構成を示すブロック図である。図１、図４、図７、図９、図１１および図１４と同一の符号は同一の構成要素を表している。
図に示すように、ＳＢＣシステム９０は、サーバ９１、端末８５を備えており、サーバ９１と端末８５は、通信回線２７を介して接続されている。
サーバ９１のアプリケーション実行要求部９２は、アプリケーション起動部９３を備えている。

次に、動作について説明する。
図１８は、実施の形態８によるＳＢＣシステム９０の動作のフローチャートである。ここでは、サーバ９１のアプリケーション実行要求部９２と端末８５のアプリケーション実行部８６との間の処理を示している。

例えば、実施の形態４のように、関連付け情報の変更を行うと、アプリケーション実行要求部９２がＳＢＣサーバ部１２を介さずに起動されることがある。この場合、接続先情報取得部１４が端末情報管理テーブル１９から接続先情報を取得できないことになる。

アプリケーション実行要求部９２は、接続先情報取得部１４がステップＳＴ１０２で接続先情報を取得できなかった場合に、ＳＢＣサーバ部１２からの起動ではないと判断し（ステップＳＴ８０１）、ステップＳＴ８０２へ進む。
ステップＳＴ８０２において、アプリケーション起動部９３は、ステップＳＴ１０３で取得されるアプリケーション情報に基づいてからサーバ上でアプリケーションを起動する。この場合、ステップＳＴ１０５で端末８５からの終了通知を待つ必要はないため、当該アプリケーションを起動後、アプリケーション実行要求部９２の処理は終了する。

以上のように、実施の形態８によれば、アプリケーション実行要求部９２がＳＢＣシステムを介さずに起動された場合には、サーバ９１上で直接起動されたものと判断し、該当アプリケーションを動作させることが可能となり、例えば、関連付けの変更が行われてサーバ上でｍｍｓプロトコルのＵＲＩで記載されたリンクをクリックした場合であっても、サーバ上で該当アプリケーションを動作させることが可能となる。

この発明の実施の形態１による、ＳＢＣシステムの構成を示すブロック図である。 この発明の実施の形態１によるＳＢＣシステムの動作のフローチャートである。 この発明の実施の形態１による、アプリケーション情報コンフィグレーションファイルの例を示す図である。 この発明の実施の形態２による、ＳＢＣシステムの構成を示すブロック図である。 この発明の実施の形態２による、ＳＢＣシステムの動作のフローチャートである。 この発明の実施の形態３による、ＳＢＣシステムの動作のフローチャートである。 この発明の実施の形態４による、ＳＢＣシステムの構成を示すブロック図である。 この発明の実施の形態４による、サーバの関連付け変更部の動作のフローチャートである。 この発明の実施の形態５による、ＳＢＣシステムの構成を示すブロック図である。 この発明の実施の形態５による、ＳＢＣシステムの動作のフローチャートである。 この発明の実施の形態６による、ＳＢＣシステムの構成を示すブロック図である。 実施の形態６による、起動アプリケーション管理テーブルの内容の例を示す図である。 実施の形態６による、サーバのアプリケーション実行要求部とアプリケーション管理部との間の処理のフローチャートである。 この発明の実施の形態７による、ＳＢＣシステムの構成を示すブロック図である。 実施の形態７による、端末構成情報管理テーブルの内容の例を示す図である。 実施の形態７による、ＳＢＣシステムの動作のフローチャートである。 この発明の実施の形態８による、ＳＢＣシステムの構成を示すブロック図である。 この発明の実施の形態８による、ＳＢＣシステムの動作のフローチャートである。

符号の説明

１０，３０，５０，６０，７０，８０，９０ ＳＢＣシステム、１１，３１，５１，６１，７１，９１ サーバ、１２ ＳＢＣサーバ部、１３，３３，６３，７３，９２ アプリケーション実行要求部、１４ 接続先情報取得部、１５ 起動アプリケーション情報取得部、１６ 起動要求部、１７ アプリケーション状態受信部、１８ アプリケーション情報コンフィグレーションファイル、１９ 端末情報管理テーブル、２０，３２，８５ 端末、２１ ＳＢＣクライアント部、２２，３４，８６ アプリケーション実行部、２３ 起動要求受信部、２４ アプリケーション起動部、２５ アプリケーション状態通信部、２６ 起動対象アプリケーション、２７ 通信回線、３５ アプリケーションインストールモジュール、３６ インストールモジュール取得部、３７ アプリケーションインストール部、３８ アプリケーション削除部、５４ 関連付け変更部、５５ コンフィグレーション情報取得部、５６ 関連付け変更処理部、６４ コンテンツ公開部、７４ 管理情報通信部、７５，８２ アプリケーション管理部、７６ リクエスト受信部、７７ 起動アプリケーション管理部、７８ 起動アプリケーション管理テーブル、８３ 端末情報管理部、８４ 端末構成情報管理テーブル、８７ 端末情報取得部、８８ 端末情報送信部。

Claims (14)

1. 端末からのサービス要求に基づいてコンピュータプログラムを動作させるサーバにおいて、
   上記端末に関する情報を格納する端末情報管理テーブルと、
   上記サービス要求に基づいて起動するコンピュータプログラムの情報を格納するアプリケーション情報コンフィグレーションファイルと、
   上記サービス要求に対応する起動対象コンピュータプログラムを上記端末上で起動させるアプリケーション実行要求部を備え、
   上記アプリケーション実行要求部は、
   上記アプリケーション情報コンフィグレーションファイルから、上記起動対象コンピュータプログラムの起動に必要な起動情報を取得する起動アプリケーション情報取得部と、
   上記端末情報管理テーブルから、上記サービス要求を送信した端末の情報を取得し、その端末に上記起動情報と共に上記起動対象コンピュータプログラムの起動要求を通知する起動要求部と、
   上記端末から上記起動対象コンピュータプログラムの終了通知を受信した時に、上記アプリケーション実行要求部の処理を終了させるアプリケーション状態受信部を備えたことを特徴とするサーバ。
2. アプリケーション情報コンフィグレーションファイルは、起動対象コンピュータプログラム毎に、プログラム実行環境の種類に対応したアプリケーション情報を保持し、
   起動アプリケーション情報取得部は、上記起動対象コンピュータプログラムに関する情報全体を取得することを特徴とする請求項１記載のサーバ。
3. コンピュータプログラムのインストール用モジュールを格納するアプリケーションインストールモジュール記憶部と、
   起動アプリケーション情報取得部が取得した起動情報に基づいて、上記アプリケーションインストールモジュール記憶部から起動対象コンピュータプログラムのインストール用モジュールを取得するインストールモジュール取得部とを備え、
   端末に、上記起動対象コンピュータプログラムのインストールモジュールを送信することを特徴とする請求項１または請求項２記載のサーバ。
4. 起動要求部は、起動要求通知の際に、端末に起動対象コンピュータプログラムのインストールモジュールを送信することを特徴とする請求項３記載のサーバ。
5. アプリケーション状態受信部は、端末から起動対象コンピュータプログラムのインストール用モジュールの送信を依頼するインストールモジュール要求を受信したら、上記端末に起動対象コンピュータプログラムのインストールモジュールを送信することを特徴とする請求項３記載のサーバ。
6. アプリケーション情報コンフィグレーションファイルの内容に基づいて、サーバ上のコンピュータプログラムとデータ通信方式の関連付けを変更する関連付け変更部を備え、
   上記関連付け変更部は、
   アプリケーション情報コンフィグレーションファイルを参照し、データ通信方式に関する情報を取得するコンフィグレーション情報取得部と、
   上記コンフィグレーション情報取得部が取得した情報を基に、サーバ上のコンピュータプログラムと上記データ通信方式との関連付けを変更する関連付け変更処理部とを備えたことを特徴とする請求項１から請求項５のうちのいずれか１項記載のサーバ。
7. コンフィグレーション情報取得部は、アプリケーション情報コンフィグレーションファイルから、ファイル名に関する情報を取得し、
   関連付け変更処理部は、上記ファイル名を基に、サーバ上のコンピュータプログラムとファイルの種類との関連付けを変更する関連付け変更処理部とを備えたことを特徴とする請求項６記載のサーバ。
8. コンフィグレーション情報取得部は、アプリケーション情報コンフィグレーションファイルから、あるコンピュータプログラムに組み込まれた他のコンピュータプログラムの利用に関する情報を取得し、
   関連付け変更処理部は、上記コンフィグレーション情報取得部が取得した情報を基に、上記コンピュータプログラムから上記他のコンピュータプログラムの起動が可能なように関連付けを変更する関連付け変更処理部を備えたことを特徴とする請求項６または請求項７記載のサーバ。
9. サーバ上のコンテンツのＵＲＩを外部の端末からアクセス可能なＵＲＩに変更し、上記コンテンツを利用するコンピュータプログラムの起動時に、上記コンピュータプログラムが動作する端末に対してのみ上記ＵＲＩを通知してコンテンツを公開するコンテンツ公開部を備え、
   上記コンテンツ公開部は、上記コンピュータプログラムの動作が終了すると、上記コンテンツの公開を解除することを特徴とする請求項１から請求項８のうちのいずれか１項記載のサーバ。
10. コンテンツ公開部は、サーバ上のコンテンツを利用するコンピュータプログラムの起動時に、上記コンピュータプログラムが動作する端末に対してのみ上記コンテンツの利用に必要なプログラムを提供し、
    上記コンピュータプログラムの動作が終了すると、上記プログラムの提供を解除することを特徴とする請求項９記載のサーバ。
11. サーバにサービス要求を送信して、上記サーバ上でコンピュータプログラムを動作させる端末において、
    上記サーバからアプリケーション起動要求を受信し、起動要求のあったコンピュータプログラムを起動するアプリケーション実行部を備え、
    上記アプリケーション実行部は、
    上記アプリケーション起動要求を受信する起動要求受信部と、
    上記アプリケーション起動要求に基づいて、対象コンピュータプログラムを検索して起動するアプリケーション起動部と、
    上記対象コンピュータプログラムが終了したら、上記サーバに終了通知を送信するアプリケーション状態通信部を備えたことを特徴とする端末。
12. サーバから送信されたコンピュータプログラムのインストールモジュールを取得してインストールを行うアプリケーションインストール部と、
    上記コンピュータプログラムの動作が終了したら、当該コンピュータプログラムを削除するアプリケーション削除部を備えたことを特徴とする請求項１１記載の端末。
13. アプリケーション起動部は、サーバからのアプリケーション起動要求を受けて当該コンピュータプログラムが存在するかどうかを確認し、存在しない場合には上記サーバに当該コンピュータプログラムのインストール用モジュールの送信要求を通知することを特徴とする請求項１２記載の端末。
14. 端末からの要求に基づいて、サーバ上でコンピュータプログラムを動作させる情報システムにおいて、
    上記サーバは、
    上記端末に関する情報を格納する端末情報管理テーブルと、
    上記サービス要求に基づいて起動するコンピュータプログラムの情報を格納するアプリケーション情報コンフィグレーションファイルと、
    上記サービス要求に対応する起動対象コンピュータプログラムを上記端末上で起動させるアプリケーション実行要求部を備え、
    上記アプリケーション実行要求部は、
    上記アプリケーション情報コンフィグレーションファイルから、上記起動対象コンピュータプログラムの起動に必要な起動情報を取得する起動アプリケーション情報取得部と、
    上記端末情報管理テーブルから、上記サービス要求を送信した端末の情報を取得し、その端末に上記起動情報と共に上記起動対象コンピュータプログラムの起動要求を通知する起動要求部と、
    上記端末から上記起動対象コンピュータプログラムの終了通知を受信した時に、上記アプリケーション実行要求部の処理を終了させるアプリケーション状態受信部を備え
    上記端末は、
    上記サーバからアプリケーション起動要求を受信し、起動要求のあったコンピュータプログラムを起動するアプリケーション実行部を備え、
    上記アプリケーション実行部は、
    上記アプリケーション起動要求を受信する起動要求受信部と、
    上記アプリケーション起動要求に基づいて、対象コンピュータプログラムを検索して起動するアプリケーション起動部と、
    上記対象コンピュータプログラムが終了したら、上記サーバに終了通知を送信するアプリケーション状態通信部を備えたことを特徴とする情報システム。

Images