JP2005526315A - ブラウザでの第１の媒体形式のコンテンツの画面処理 - Google Patents

Abstract

サーバ(13)からの画面処理サポートにより、クライアント(16)のブラウザ(10)で第１の媒体形式(11)のコンテンツを画面処理する方法とシステムとクライアントである。前記方法は：クライアントの限られたリソースが原因で、第１の媒体形式のコンテンツが画面処理に不適切であるか否かを判断し、そうである場合には、前記サーバからの画面処理サポートを処理及び受信するように準備して、第１のソフトウェアコンポーネント(12)を起動するステップと；クライアントから、サーバへの画面処理サポートの要求により、第１の媒体形式のコンテンツへのリンクを送信するステップと；受信したリンクの第２の媒体形式のコンテンツをサーバで判断するステップであって、前記第２の媒体形式のコンテンツがクライアントでの画面処理に適しているステップと；クライアントに第２の媒体形式のコンテンツを転送するステップと、；前記第１のソフトウェアコンポーネントにより、第２の媒体形式のコンテンツを画面処理するステップとを有する。前記方法は：第１のソフトウェアコンポーネントにより、第１の入力イベントを受信するステップと；第１のソフトウェアコンポーネントからサーバの第２のソフトウェアコンポーネント(15)に第１の入力イベントを送信するステップと；第２のソフトウェアコンポーネントにより、第１の入力イベントと第２の媒体形式のコンテンツに基づいて、受信した第１の入力イベントを第３の媒体形式のコンテンツに変換するステップと；第２のソフトウェアコンポーネントにより、第３の媒体形式のコンテンツを第１のソフトウェアコンポーネントに転送するステップと；第３の媒体形式のコンテンツを画面処理するステップとを更に有する。このことにより、クライアントのブラウザで、ブラウザが最初に適していなかった媒体形式又はシステムリソースを有していなかった媒体形式の画面処理が可能になる。

Description

本発明は、サーバからの画面処理サポートにより、クライアントのブラウザで第１の媒体形式のコンテンツを画面処理する方法に関するものである。

本発明はまた、前記方法を実行するコンピュータシステムに関するものである。

本発明は、前記方法を実行するコンピュータプログラム製品に更に関するものである。

加えて、本発明は、サーバからの画面処理サポートにより、ブラウザで第１の媒体形式のコンテンツを画面処理するクライアントに関するものである。

EP0,965.914は、クライアントでマークアップ言語のドキュメントを表示する方法の実施例を開示する。HTMLドキュメントが受信され、そのHTMLドキュメントから対応するプログラムがクライアントの外部で生成され、その後に前記ドキュメントを表示するため、クライアントで使用するために送信される。

画像コンテンツは一般的にパーソナルコンピュータのスクリーンに表示されるように元々は設計されているため、シン(Thin)クライアントのブラウザは、小さいディスプレイの大きさと前記クライアントの解像度に適するように、受信した画像コンテンツの変換を実行する必要があることが知られている。パーソナルコンピュータに比較して小型かつ安価にするために、シンクライアントは一般的に最小のシステムリソースで設計されているため、画像コンテンツの変換が大量の計算処理能力やメモリ空間等を必要とすることが課題である。

前述の先行技術の方法は、マークアップ言語のドキュメントをクライアントで表示する受信プログラムが多くのシステムリソースを必要とするという課題を有する。

従って、クライアントの計算処理能力とメモリ空間を最小限に使用することで、画像コンテンツ及び他の表示可能なコンテンツの画面処理をクライアントのブラウザに提供することが本発明の目的である。

前記の課題は、冒頭段落で前述した方法により解決され、前記方法は、
−前記クライアントの限られたリソースが原因で、前記第１の媒体形式のコンテンツが画面処理に不適切であるか否かを判断し、そうである場合には、前記サーバからの画面処理サポートを処理及び受信するように準備して、第１のソフトウェアコンポーネントを起動するステップと、
−前記クライアントから、前記サーバへの画面処理サポートの要求により、前記第１の媒体形式のコンテンツへのリンクを送信するステップと、
−前記受信したリンクの第２の媒体形式のコンテンツを前記サーバで判断するステップであって、前記第２の媒体形式のコンテンツが前記クライアントでの画面処理に適しているステップと、
−前記受信したリンクと前記要求に応じて、前記サーバから前記クライアントに前記第２の媒体形式のコンテンツを転送するステップと、
−前記第１のソフトウェアコンポーネントにより、前記受信した第２の媒体形式のコンテンツに応じて前記第２の媒体形式のコンテンツを画面処理するステップと
を有する。

最初のステップで、クライアントの限られたリソースが原因で、媒体形式のコンテンツが画面処理に不適切であることが判断されることがあり、その後に前記第１のソフトウェアコンポーネントが起動される。サーバからのその後の画面処理サポートの処理及び受信に対して準備するように、クライアント側で起動される。

次に、クライアントはサーバからのサポートを要求する。サポートの要求において、コンテンツにリンクする前記リンク(最初のステップにおいてクライアントのブラウザでの画面処理に適していないもの)が含まれることがある。

その後の３つのステップにおいて、サーバはリンクのコンテンツを取り出し、その後にフォーマット及びコンテンツ(第２の媒体形式のコンテンツ)に変換し、そのコンテンツがクライアントに転送され、その後にクライアントで画面処理される。

変換(ステップ3)がサーバで行われ、それによりクライアントのブラウザが前記第２の媒体形式のフォーマットで画面処理する最小限の計算処理能力しか必要としないため、画像コンテンツ及び他の表示可能なコンテンツの画面処理をコンテンツのブラウザに提供する目的が達成される。

従って、クライアントがサーバからの画面処理サポートを要求及び取得したことを、クライアントのユーザが気付かないため、クライアントでウェブサイトにアクセスする前記方法の前記ステップが、ユーザにトランスペアレントであることが本発明の利点である。前記方法のステップはまた、画面処理サポートが取得されないときも、この場合の画面処理はクライアントでのみ行われるためユーザにトランスペアレントである。

従って、画面処理の双方の方法(第１に、最初から画面処理可能なフォーマット、又は代替として、第２に画面処理可能なフォーマットに変換されたフォーマット)において、ユーザが画面処理の前記２つの方法の面倒な違いを受けないということが、本発明の更なる利点である。

本発明のその他の好ましい実施例において、前記方法は、
−前記第１のソフトウェアコンポーネントにより、第１の入力イベントを受信するステップと、
−前記第１のソフトウェアコンポーネントから前記サーバの第２のソフトウェアコンポーネントに前記第１の入力イベントを送信するステップと、
−前記第２のソフトウェアコンポーネントにより、前記第１の入力イベントと前記第２の媒体形式のコンテンツに基づいて、前記受信した第１の入力イベントを第３の媒体形式のコンテンツに変換するステップと、
−前記第２のソフトウェアコンポーネントにより、前記第３の媒体形式のコンテンツを前記第１のソフトウェアコンポーネントに転送するステップと、
−前記第１のソフトウェアコンポーネントにより、更に前記受信した第３の媒体形式のコンテンツに応じて前記第３の媒体形式のコンテンツを画面処理するステップと
を更に有する。

最初の５つのステップと対応して、これらの最後の５つのステップは、クライアントのマウス、キーボード等からの多様な入力に基づいて、(この場合も同様にサーバからの画面処理サポートにより)クライアントのディスプレイに画面処理する。

ステップ１と２において、これらの入力が(１つ以上の前記第１の入力イベントを用いて)サーバにより受信され、その入力を(再び)フォーマット及びコンテンツに変換する。そのフォーマット及びコンテンツが転送され、その後にクライアントで画面処理される。

本発明の好ましい実施例では、前記第１の媒体形式のコンテンツが不適切であるか否かを判断するステップ等は、
−前記ブラウザにより、前記第１の媒体形式のコンテンツが前記クライアントで画面処理可能でないことを判断し、
−そうである場合には、前記ブラウザにより前記第１のソフトウェアコンポーネントを起動すること
を有する。

これらのステップにおいて、ブラウザは、現在のコンテンツが画面処理されるのに不適切であることを最初に判断し、次に第１のソフトウェアコンポーネントがブラウザにより起動される。前記第１のソフトウェアは、処理の準備を行い、サーバからのその後の画面処理サポートの準備を行うために起動される。

本発明のその他の好ましい実施例では、前記クライアントからリンクを送信するステップ等は、
−前記第１のソフトウェアコンポーネントにより、前記第１の媒体形式のコンテンツへの前記リンクと前記要求を前記サーバのアプリケーションマネージャに転送し、
−前記アプリケーションマネージャにより、前記受信したリンクと要求に応じて、プラグイン・アプリケーションとして前記第２のソフトウェアコンポーネントを作ること
を有する。

最初のステップにおいて、前記リンクと要求がサーバのアプリケーションマネージャに送信され、サーバへのプラグイン・アプリケーションとして前記第２のソフトウェアコンポーネントを作る。

これによって、クライアントとサーバの第１と第２のソフトウェアコンポーネントは、それぞれエンド・ツー・エンドのクライアント・サーバ型アーキテクチャと、その後の通信を実行及び可能にするように設定される。

本発明のその他の好ましい実施例では、前記受信したリンクの第２の媒体形式のコンテンツを前記サーバで判断するステップは、
−前記第２のソフトウェアコンポーネントにより、前記受信したリンクに基づいて第１の媒体形式のコンテンツを受信し、
−前記第２のソフトウェアコンポーネントにより、前記第１の媒体形式のコンテンツを第２の媒体形式のコンテンツに変換すること
を有する。

最初のステップにおいて、受信したリンク(例えば完全なURL)は、どの(他の)サーバでリンクされているコンテンツを検出可能であるかをサーバに通知し、その後にサーバが前記第１の媒体形式のコンテンツを取り出すことがある。最後のステップにおいて、前記第１の媒体形式のコンテンツは前記第２の媒体形式のコンテンツに変換されることがあり、その第２の媒体形式のコンテンツが受信されると、クライアントで画面処理されることがある。

前述の課題は、サーバからの画面処理サポートにより、ブラウザで第１の媒体形式のコンテンツを画面処理するクライアントにより、更に解決される。前記クライアントは、
−限られたリソースが原因で、前記第１の媒体形式のコンテンツが画面処理に不適切であるか否かを判断し、そうである場合には、前記サーバからの画面処理サポートを処理及び受信するように準備して、第１のソフトウェアコンポーネントを起動する手段と、
−前記サーバへの画面処理サポートの要求により、前記第１の媒体形式のコンテンツへのリンクを送信する手段と、
−前記送信したリンクの第２の媒体形式のコンテンツを受信する手段であって、前記第２の媒体形式のコンテンツが前記クライアントでの画面処理に適しており、それが判断されて前記サーバから転送される手段と、
−前記受信した第２の媒体形式のコンテンツに応じて、前記第２の媒体形式のコンテンツを画面処理する手段と
を有する。

クライアントの好ましい実施例において、前記クライアントは、
−第１の入力イベントを受信する手段と、
−前記第１の入力イベントを、前記サーバの第２のソフトウェアコンポーネントに送信する手段と、
−第３の媒体形式のコンテンツを受信する手段であって、前記第３の媒体形式のコンテンツが、前記受信した第１の入力イベントと前記第２の媒体形式のコンテンツに基づいて、前記サーバで前記第２のソフトウェアコンポーネントにより変換されて転送される手段と、
−更に前記受信した第３の媒体形式のコンテンツに応じて前記第３の媒体形式のコンテンツを画面処理する手段と
を更に有する。

前記方法に関係して前述した同じ理由により、クライアントは同じ利点を提供する

本発明は、好ましい実施例と図面を参照して以下に更に説明される。

図面を通じて、同じ参照番号は類似の又は対応する特徴や機能等を示す。

図１は、クライアントに基本ブラウザと第１のソフトウェアコンポーネントを備え、サーバに第２のソフトウェアコンポーネントとアプリケーションマネージャを備えたクライアント・サーバ型アーキテクチャを示したものである。本発明の好ましい実施例では、それはエンド・ツー・エンドのクライアント・サーバ型アーキテクチャに基づいており、クライアント(参照番号16)は、第１のソフトウェアコンポーネントの機能が可能になる基本ブラウザ(参照番号10)を有する。Netscape Communicatorのようなブラウザの場合には、第１のソフトウェアコンポーネントは、基本ブラウザの機能に組み込まれたプラグインでもよい。基本ブラウザは、Netscape Communicator又はMicrosoftからのInternet Explorerのような如何なる商用のウェブブラウザでもよい。Netscape Communicatorの場合には、第１のソフトウェアコンポーネントは標準的なプラグイン機構を用いて実装されてもよく、基本ブラウザとしてNetscape Communicatorに備えられてもよい。第１のソフトウェアコンポーネントは、単なるプラグイン又はデフォルトのプラグインとしてのプラグインでもよい。逆に前記基本ブラウザがInternet Explorerである場合、第１のソフトウェアコンポーネントはActiveXコントロールにより実装されてもよい。

基本ブラウザが処理できない(すなわち基本ブラウザがクライアントでの表示に対して画面処理できない)媒体形式(参照番号11)
(例えばPDF(Portable Document Format)又はWordのフォーマット)で、ユーザがウェブサイトにアクセスすると常に、基本ブラウザは第１のソフトウェアコンポーネント(参照番号12)を起動し、特定の媒体形式を処理する。

しかし、第１のソフトウェアコンポーネントはその媒体形式用の実際の実行コード又は実行可能コードではなく、このことは、第１のソフトウェアコンポーネントが媒体形式のフォーマット自体を処理することができず、また、その媒体形式の画面処理機能(すなわち前記クライアントに前記媒体形式を提示する機能)を有していないことを意味する。その代わりに、第１のクライアントは、この媒体形式用のいわゆるプロキシとして機能することがある。アプリケーションサーバのプロフィール(例えばサーバのIPアドレス)は、第１のソフトウェアコンポーネントに認識されていなければならない。アプリケーションサーバ(参照番号13)は、ホームゲートウェイ、ISPサイト、ASPサイト、又はプロキシサーバにインストールされてもよい。

次に、第１のソフトウェアコンポーネントは、この媒体形式の画面処理サポートのために、アプリケーションサーバ(参照番号13)のアプリケーションマネージャ(参照番号14)にクエリ送出することがある。

次に、アプリケーションマネージャは、特定の媒体形式の処理のため、サーバに存在し又は配置されたプラグイン・アプリケーション(参照番号15)として、第２のソフトウェアコンポーネントを作ることがある。アプリケーションサーバは、この媒体形式をサポートするアプリケーションを有する如何なるオペレーティングシステムのプラットフォーム(一例ではWindows（登録商標）のオペレーティングシステムのプラットフォーム)でもよい。Windows（登録商標）のプラットフォームでは、ActiveXコントロールというウェブブラウザ・コントロールが存在することがある。このActiveXコントロールがActive Document Hostとして機能し得るため、クライアントは前記ActiveXコントロールをホストすることにより、そのActiveXコントロールを利用することがある。このことは、このウェブブラウザ・コントロールは、(必要に応じて、すなわちクライアントからの要求により)如何なる媒体形式も画面処理するために、如何なる種類のソフトウェアコンポーネントをもロードし得ることを意味する。例えば、PDF(Portable Document Format)の媒体形式に専用のソフトウェアコンポーネントが存在してもよく、Wordフォーマットで作られたドキュメント又はファイルに専用のソフトウェアコンポーネントが存在してもよい。第２のソフトウェアコンポーネント(すなわち、アプリケーションサーバのサイトのプラグイン・アプリケーション(参照番号15))が、第１のソフトウェアコンポーネント(参照番号12)から所定の媒体形式の画面処理サポートの要求を受信すると常に、サーバのサイトの第２のソフトウェアコンポーネント(参照番号15)は、コンテンツが存在する場所(すなわち、対応するウェブサイト又は他のサーバ若しくはネットワークドライブ)から直接に媒体形式のコンテンツにアクセスし、アプリケーションサーバのサイトで、クライアントへの提示又は画面処理に専用の(前記媒体形式の元々のコンテンツのフォーマットに比較して)処理可能な異なる簡単なフォーマットに、コンテンツをデコード(すなわち、媒体形式のコンテンツの変換)する。

更に、ウィンドウ更新イベントを付けることにより、前記第２のソフトウェアコンポーネントは、処理可能な簡単なフォーマットのコンテンツ(例えばそのコンテンツはjpegフォーマットでもよい)を、画面処理又は提示用にクライアントの第１のソフトウェアコンポーネントに返送することがある。

これによって、Word(.docフォーマット)又はAcrobat ReaderからのPortable Document Format(.pdfフォーマット)のような、元々の(クライアントで)画面処理不可能な複雑なフォーマットは、簡単な(クライアントで)画面処理可能な複雑でないフォーマット(例えばJPEGフォーマット)にサーバで変換されることがある。その後に、複雑でないフォーマット(又はより正確にはそのコンテンツ)が、クライアントのディスプレイの画面処理又は提示用にクライアントで使用されることがある。

図２は、クライアントの親ウィンドウのスクリーン領域で入出力機能を処理するクライアント・サーバ型アーキテクチャを示したものである。第１のソフトウェアコンポーネント(参照番号12)は、前述の図面での説明以外に、２つの基本機能を更に処理することがある。第１にクライアントのユーザからの入力機能(ボタンクリック、キーボード入力等)であり、第２に出力機能(すなわち、クライアントのディスプレイへの提示又は画面処理として認識され得る表示)である。ユーザが第１のソフトウェアコンポーネントにより処理されるスクリーン領域(参照番号20)へのいくつかのコマンドを入力すると常に、第１のソフトウェアコンポーネントは親ウィンドウ(参照番号21)から通知されることがある。第１のソフトウェアコンポーネントは、これらの入力イベント(参照番号21)を、サーバのサイトの対応する第２のソフトウェアコンポーネントに送信することがある。第２のソフトウェアコンポーネントは、クライアントからのこれらの入力イベントを、アプリケーションサーバ用の特有の入力イベントに変換することがある。第２のソフトウェアコンポーネントは、これらの入力イベントがサーバのサイトで生成されたものであるかのように、入力イベントに応じることがある。スクリーンのある領域がクライアントで変更されることを第２のソフトウェアコンポーネントが通知すると、第２のソフトウェアコンポーネントは出力イベント(参照番号23)を生成することがあり、クライアントのサイトの対応する第１のソフトウェアコンポーネント(参照番号12)にこの出力イベントを返信することがある。この出力イベントは、変更されたスクリーンデータの領域で構成されることがある。第１のソフトウェアコンポーネントが対応する第２のソフトウェアコンポーネント(参照番号15)から出力イベントを受信すると、第１のソフトウェアコンポーネントは、この出力イベントを変換することがあり、次にクライアントのディスプレイに画面処理することがある。サーバのサイトの第２のソフトウェアコンポーネント(参照番号15)のコードがクライアントで実行されているかのように、この動作はクライアントのユーザにトランスペアレントである。

第１のソフトウェアコンポーネントが主に基本I/Oイベントを処理することにより(すなわち簡単な(すなわちクライアントに画面処理可能な)フォーマットで表示し、ボタンクリックやキーボード入力等のようなキーボード又はマウスからの入力を処理する)、前記の更に複雑なフォーマットはサーバのサイトで更に大きい計算処理能力とメモリ空間の使用により計算及び変換されるため、計算処理能力とメモリ空間に関するクライアントのリソースの要件は最小限に設計されることがある。

図３は、第１のソフトウェアコンポーネントのツリー型モジュールの実装を示したものであり、本発明の好ましい実施例ではクライアントがアプリケーションサーバ用のダム・ウェブ端末として構成される。この場合、第１のソフトウェアコンポーネントは、HTTPサブモジュールと、XMLサブモジュールと、表示サブモジュールとを有する。HTTPサブモジュールは図面で参照番号31により示されており、表示サブモジュールは参照番号33により示されており、XMLサブモジュールは参照番号32により示されている。

この構成での第１のソフトウェアコンポーネントの呼び出しのステップは以下の通りになることがある。
１．第１のソフトウェアコンポーネントのスレッド(参照番号30)は、クライアントの主要なスレッドとして使用され、ブラウザ用のユーザ入力又はブラウザ中のユーザ入力に対してクエリ送出することがある。
２．第１のソフトウェアコンポーネントがユーザ入力からURLを取得すると常に、前記第１のソフトウェアコンポーネントのスレッドは適切なサイズで第１のソフトウェアコンポーネント(参照番号12)を作り、完全なURLのような関連情報を第１のソフトウェアコンポーネントに渡すことがあり、その第１のソフトウェアコンポーネントが前記関連情報をアプリケーションサーバに転送する。
３．クライアントからの要求の後に、アプリケーションマネージャ14は、対応する第１のソフトウェアコンポーネント用のプラグイン・アプリケーションとして、第２のソフトウェアコンポーネントを作ることがある。
４．第１のソフトウェアコンポーネントは、HTTPサブモジュールを使用するために、 (サーバの)第２のソフトウェアコンポーネントに入力コマンドを転送し、第２のソフトウェアコンポーネントがクライアントでの画面処理用の表示出力コマンドを第１のソフトウェアコンポーネントに返信することがある。
５．HTTPプロトコルのペイロードはXMLフォーマットにコード化されることがある。第１のソフトウェアコンポーネントのXMLサブモジュールは、クライアントに画面処理可能なフォーマットに解釈及び変換することがある。
６．第１のソフトウェアコンポーネントは、表示サブモジュールを使用することにより、ステップ２で作られた適切な領域に出力データを画面処理することがある。

前述のステップ１は、第１のソフトウェアコンポーネントのスレッドが、ユーザに入力ダイアログボックス(又はユーザがクリックする事前に定められたアイコン)をポップアップさせるように拡張されてもよい。前記第１のソフトウェアコンポーネントの動作が終了すると常に、第１のソフトウェアコンポーネントのスレッドが自動的に終了することがある。

クライアントとサーバとの間の通信は、クライアント側のネットワーク転送レイヤ(参照番号34)と、サーバ側の対応するネットワーク転送レイヤ(参照番号35)を用いて実行されることがある。

図４は、サーバからの画面処理サポートにより、クライアントのブラウザで第１の媒体形式のコンテンツを画面処理する方法を示したものである。

ステップ90で前記方法が開始する。クライアントとサーバで媒体形式や媒体形式のコンテンツや要求等を記録している変数やフラグやバッファ等は、デフォルト状態に設定される。前記方法が２度目に開始するときには、使用された変数やフラグやバッファや形式等がデフォルト値に設定される。

ステップ100において、クライアントの限られたリソースが原因で、第１の媒体形式のコンテンツが画面処理に不適切であるか否かが判断される。そうである場合には、第１のソフトウェアコンポーネントが起動されることがある。それによって(クライアントの)第１のソフトウェアコンポーネントは、サーバからの画面処理サポートを処理及び受信するように準備することがある。ステップ100は、ステップ101と102の一般化を構成する。一例として、クライアントの限られたリソース(すなわち、限られた処理能力、限られた量のRAM等)が原因で、クライアント自体で前記第１の媒体形式のコンテンツを画面処理することが適切でないことがある。その限られたリソースが原因で、その結果としてクライアントのブラウザが、対応する提示機能及び画面処理機能のみを有することがある。

前記第１の媒体形式のコンテンツは、Microsoft Wordの.doc形式でもよく、又はAcrobatの.pdf形式でもよい。これらの媒体形式の双方は、画面処理されるためにはクライアントから非常に多くのもの(すなわち、処理能力、RAM)を必要とすることがある。従って、後述するように、簡単な形式(例えばjpeg形式)に基づいて、クライアントがコンテンツ(ユーザの観点からは基本的に同じコンテンツ)を画面処理することが適切なことがある。

ステップ101において、第１の媒体形式のコンテンツがクライアントで画面処理可能でないことが判断されることがある。前のステップで説明したように、その形式は、処理能力又はRAMに関してクライアントから過度のリソースを必要とすることがあるという点で、クライアントでの画面処理に不適切なことがある。仮に実行されると、非常に長い時間を要することがあるため、画面処理がクライアントで実行されることに適していない。

一例として、第１の媒体形式のコンテンツがAdobe Portable Document Format(PDF)又はMicrosoft Word Document(DOC)のような媒体形式であることを仮定すると、クライアントのブラウザは大量のメモリリソースを必要とするため、クライアントのブラウザでの画面処理には不適切である。

ステップ102において、前のステップから、前記第１の媒体形式のコンテンツがクライアントで画面処理可能ではないことが判断されると、ブラウザは前記第１のソフトウェアコンポーネントをクライアントで起動することがある。第１のソフトウェアコンポーネントは、起動されると、以降のステップで、画面処理可能なフォーマット(例えばjpegフォーマット)に変換されたときに媒体形式のコンテンツの画面処理/提示を処理する準備を行うことがある。

ステップ200において、クライアントは、サーバへの画面処理サポートの要求により、前記第１の媒体形式のコンテンツへのリンクを送信することがある。ステップ200は、ステップ201と202の一般化を構成する。前のステップの結果として(クライアントがクライアント自体のリソースを有していない結果、又は画面処理に不十分なリソースを使用することが適切ではないと判断した結果)、クライアントは一般的に、クライアントでのその後の画面処理が適切なフォーマット(すなわち一例としてjpeg形式)で行われ得るように、サーバにサポートを要求する。他の形式でもその後に処理される時に過度のクライアントのCPU処理能力及び／又はメモリ容量を必要としない限り、jpeg以外の形式もクライアントに適していることがある。更に要求に対して、クライアントはまたサーバにリンクを供給することがある。そのリンクは、どの(他の)サーバでリンクされているコンテンツを検出可能であり、その後にステップ301で取り出すことができるかをサーバに通知することがある。

ステップ201において、第１のソフトウェアコンポーネントは、第１の媒体形式のコンテンツへのリンクと要求をサーバのアプリケーションマネージャに転送する。前のステップと比較して更に詳細にすると、前記リンクと要求がサーバのサイトの前記アプリケーションマネージャに転送されることがあり、それによってサーバのアプリケーションマネージャが、クライアントの第１のソフトウェアコンポーネントから、前記第１の媒体形式の画面処理サポートの要求を受ける。

ステップ202において、アプリケーションマネージャは、サーバでプラグイン・アプリケーションとして第２のソフトウェアコンポーネントを作ることがある。リンクと要求の受信に応じて、その作ることが実行されることがある。ステップ100での第１のソフトウェアコンポーネントの起動に対応して、サーバのプラグイン・アプリケーションとしての第２のソフトウェアコンポーネントは、第１の媒体形式のその後の処理に対して準備するために、サーバのサイトで作られることがある。

ステップ300において、サーバは、受信したリンクを反映する第２の媒体形式のコンテンツを判断することがある。前記第２の媒体形式のコンテンツは、クライアントでの画面処理に適することがある。ステップ300は、ステップ301と302の一般化を構成する。受信したリンクは、どの(他の)サーバでリンクされているコンテンツを検出可能であるかをサーバに通知し、その後に他のフォーマットに判断することがある(すなわち、第２の媒体形式のコンテンツに変換する)。換言すると、ステップ300から302において、前のステップからの第１の媒体形式のコンテンツ(クライアントで画面処理不可能なもの)は、クライアントで画面処理可能な前記第２の媒体形式のコンテンツに変換される。

ステップ301において、第２のソフトウェアコンポーネントは、受信したリンクに基づいて第１の媒体形式のコンテンツを受信することがある。受信したリンクは、どの(他の)サーバでリンクされているコンテンツを検出可能であるかをサーバに通知し、その後に第１の媒体形式のコンテンツとしてそれを取り出すことがある。

換言すると、ステップ300から302において、サーバは、第１のソフトウェアコンポーネントから送信されたリンクからの完全なURLを介して、第１の媒体形式のコンテンツにアクセスし、その後に画面処理可能なフォーマットのコンテンツ(すなわち第２の媒体形式のコンテンツ)に変換することがある。

ステップ302において、第２のソフトウェアコンポーネントは、サーバで第１の媒体形式のコンテンツを第２の媒体形式のコンテンツに変換することがある。前記第１の媒体形式のコンテンツは、その後にクライアントで画面処理可能な第２の媒体形式のコンテンツに変換される必要がある。クライアントとサーバは、クライアントが画面処理に適していると判断するフォーマットや形式に関する情報を更に交換してもよい。更に又は代替として、サーバは事前にフォーマット(すなわち、クライアントが適切な画面処理可能なフォーマットとして判断し得る形式)を通知されてもよい。更に、クライアントとサーバは、どのフォーマットが画面処理サポートを必要とするかを交渉してもよい。

ステップ400において、サーバは第２の媒体形式のコンテンツをクライアントに転送することがある。転送は、クライアントから受信したリンクと要求に応じて実行されてもよい。ここで、第２の媒体形式のコンテンツはユーザの観点からは第１の媒体形式のコンテンツと類似しており、その第２の媒体形式のコンテンツがクライアントに転送される。

ステップ500において、第１のソフトウェアコンポーネントは、第２の媒体形式のコンテンツをクライアントで画面処理することがある。画面処理は、第２の媒体形式のコンテンツがクライアントにより受信されたときに実行されてもよい。ここで、前述のステップの結果として、クライアントは適切なフォーマット(すなわち第２の媒体形式のフォーマット)で画面処理することができる。それによって、クライアントが実際にサーバから画面処理サポートを要求及び取得したことを、クライアントのユーザが気付かないため、クライアントでウェブサイトにアクセスする方法の前記ステップがユーザにトランスペアレントであるということが、本発明の利点である。

当然のことながら、前記方法の前述のステップは、全く画面処理サポートを必要としないウェブサイトからのコンテンツにも適用されることがある。全ての場合において、クライアントのユーザは、最初から画面処理可能なフォーマット(ステップ100でサポートが必要ない場合)と、画面処理可能なフォーマットに変換されたフォーマット(ステップ100から600で画面処理サポートが実際にサーバから必要な場合)との違いを全く認識しない。

ステップ600において、第１のソフトウェアコンポーネントは、クライアントで第１の入力イベントを受信することがある。インターネットをブラウズするために使用される他の装置と同様に、ユーザは、画面処理される情報(すなわちクライアントに表示される情報)に関連する更なる情報を探すため又は要求するために、マウスをクリックし、キーボードを操作し、タッチセンサ付ディスプレイに触れることがある。前述の通り、クライアントは処理能力及び／又はメモリ・セル(RAM、ROM等)の量に関して限られたリソースを有することがあるため、クライアントが非常に基本的な機能のみを処理し、複雑なフォーマットと形式の複雑な画面処理、及び大きいリソースを要求する入出力の処理を、大きい処理能力と割り当て可能なメモリ・セルを有することがあるサーバに任せることが適切なことがある。一般的にこのステップにおいて、クライアントはマウス、キーボードの使用、クライアントのタッチスクリーンの接触等により引き起こされる何らかの入力イベントを受信する。一般的に入力イベントは、その後にクライアントのディスプレイが提示しなければならない(すなわち少なくとも部分的にその他のコンテンツを画面処理する)効果を有する。

ステップ700において、第１のソフトウェアコンポーネントは、第１の入力イベントをサーバの第２のソフトウェアコンポーネントに送信することがある。ステップ200(リンクと要求がサーバに送信される)と同様に、クライアントでの何らかの入力手段(すなわち、クライアントのマウス、キーボード等)の使用を表す第１の入力イベントは、第１のソフトウェアコンポーネントによりクライアントに送信されることがある。換言すると、図２を参照して、前記第１の入力イベント(参照番号22)は、サーバ(参照番号13)の第２のソフトウェアコンポーネント(参照番号15)に送信される。前記第１の入力イベントが、クライアントに表示される媒体のコンテンツの完全なURLを有することもあり、又は表示されるコンテンツに埋め込まれたその他のURLを有することもある。前記第１の入力イベントは、考慮されると、クライアントに表示されるコンテンツのある程度の領域が変更される(すなわち再度画面処理される)必要があることを示すことがある。

サーバで、第２のソフトウェアコンポーネントがWindows（登録商標）プラットフォームのもとで如何なるサポート済のコンポーネントを自動的に画面処理するウェブブラウザ・コントロールのホストを更に有することがある。この利点は、ステップ800で説明するように、ステップ600においてクライアントからの前記受信した入力イベントにより、クライアントに現在表示されているコンテンツがどのように影響を受けるかを、サーバが容易に計算できることである。

ステップ800において、第２のソフトウェアコンポーネントは、受信した第１の入力イベントを第３の媒体形式のコンテンツにサーバで変換することがある。変換は、受信した第１の入力イベントと、ステップ302で既に利用可能でありサーバに存在する第２の媒体形式のコンテンツに基づくことがある。ステップ300と同様に、ステップ800において、第２のソフトウェアコンポーネントは、前記第３の媒体形式のコンテンツを判断することがある。当然のことながら、判断は、第１の入力イベントと、以前にサーバからダウンロードされてクライアントに現在表示されているコンテンツ(すなわち第２の媒体形式のコンテンツ)に基づくことがある。換言すると、第３の媒体形式のコンテンツは、クライアントに表示され、その後に前記受信した第１の入力イベントにより影響を受けた古いコンテンツの結果を表すことがある。

ステップ900において、第２のソフトウェアコンポーネントは、第３の媒体形式のコンテンツをクライアントの第１のソフトウェアコンポーネントに転送することがある。

ステップ1000において、第１のソフトウェアコンポーネントは、クライアントで第３の媒体形式のコンテンツを画面処理することがある。画面処理は、クライアントでの第３の媒体形式のコンテンツの受信に応じて実行されてもよい。ステップ500と同様に、第１のソフトウェアコンポーネントは、受信したコンテンツをクライアントで画面処理するが、ステップ500と対照的に、表示の一部分又は複数部分のみが新たに画面処理される必要があることがある。当然のことながら、元々は第１のソフトウェアコンポーネントにより受信した前記第１の入力イベントが、新しいリンク(すなわちその他のURL)へのマウスのクリックである場合には、クライアントの全表示又はスクリーン領域(図２の参照番号20)が必然的に全更新を必要とする。この場合、ステップ1000はステップ500と同様になることがある。

第１のソフトウェアコンポーネントが使用され、又は記載されている前述の全てのステップにおいて、第１のソフトウェアコンポーネントは、クライアントのブラウザへのデフォルトのプラグイン・アプリケーションであり、この場合に前記プラグインの動的リンクライブラリのみがクライアントにインストールされていることがある。これは、ブラウザ(図１の参照番号10)がNetscape Communicatorである場合に相当する。

代替として、前記ブラウザがMicrosoftのInternet Explorerである場合、第１のソフトウェアコンポーネントはActiveXコントロールでもよい。

更に、一般的に第１のソフトウェアコンポーネント又は第２のソフトウェアコンポーネントが記載されている場合、必要に応じてそれぞれクライアントとサーバで動作し得る実行可能コード解釈可能コードとして理解してもよい。

クライアントはインターネットへのアクセスを有し、ウェブページ並びに対応するリンク先のコンテンツ及び関連コンテンツをブラウザ可能及び／又は表示可能な電子装置でもよい。クライアントはウェブ・タブレットでもよく、ダム端末でもよく、携帯用装置でもよく、更に処理能力及び／又はメモリ使用に関して限られた割り当てリソースでブラウザを作動してもよい。更に、クライアントはサーバ用のダム・ウェブ端末として構成されてもよい。

通常は、クライアントとサーバが異なる媒体形式のコンテンツや要求等を適切に交換している限り、前記方法は初めから開始する。そうでない場合には、前記方法はステップ1100で終了することがあるが、クライアントとサーバが再起動すると、前記方法はステップ100から進むことがある。

コンピュータ読取可能媒体は、磁気テープ、光ディスク、デジタルビデオディスク(DVD)、コンパクトディスク(追記型CD又は書き込み可能CD)、ミニディスク、ハードディスク、フロッピー（登録商標）ディスク、スマートカード、PCMCIAカード等でもよい。

クライアントに基本ブラウザと第１のソフトウェアコンポーネントを備え、サーバに第２のソフトウェアコンポーネントとアプリケーションマネージャを備えたクライアント・サーバ型アーキテクチャを示したものである。 クライアントの親ウィンドウのスクリーン領域で入出力機能を処理するクライアント・サーバ型アーキテクチャを示したものである。 第１のソフトウェアコンポーネントのツリー型モジュールの実装を示したものであり、クライアントがアプリケーションサーバ用のダム・ウェブ端末として構成されたものである。 サーバからの画面処理サポートにより、クライアントのブラウザで第１の媒体形式のコンテンツを画面処理する方法を示したものである。

Claims (12)

1. サーバからの画面処理サポートにより、クライアントのブラウザで第１の媒体形式のコンテンツを画面処理する方法であって、
   −前記クライアントの限られたリソースが原因で、前記第１の媒体形式のコンテンツが画面処理に不適切であるか否かを判断し、そうである場合には、前記サーバからの画面処理サポートを処理及び受信するように準備して、第１のソフトウェアコンポーネントを起動するステップと、
   −前記クライアントから、前記サーバへの画面処理サポートの要求により、前記第１の媒体形式のコンテンツへのリンクを送信するステップと、
   −前記受信したリンクの第２の媒体形式のコンテンツを前記サーバで判断し、前記第２の媒体形式のコンテンツが前記クライアントでの画面処理に適しているステップと、
   −前記受信したリンクと前記要求に応じて、前記サーバから前記クライアントに前記第２の媒体形式のコンテンツを転送するステップと、
   −前記第１のソフトウェアコンポーネントにより、前記受信した第２の媒体形式のコンテンツに応じて前記第２の媒体形式のコンテンツを画面処理するステップと
   を有する方法。
2. 請求項１に記載の方法であって、
   −前記第１のソフトウェアコンポーネントにより、第１の入力イベントを受信するステップと、
   −前記第１のソフトウェアコンポーネントから前記サーバの第２のソフトウェアコンポーネントに前記第１の入力イベントを送信するステップと、
   −前記第２のソフトウェアコンポーネントにより、前記第１の入力イベントと前記第２の媒体形式のコンテンツに基づいて、前記受信した第１の入力イベントを第３の媒体形式のコンテンツに変換するステップと、
   −前記第２のソフトウェアコンポーネントにより、前記第３の媒体形式のコンテンツを前記第１のソフトウェアコンポーネントに転送するステップと、
   −前記第１のソフトウェアコンポーネントにより、更に前記受信した第３の媒体形式のコンテンツに応じて前記第３の媒体形式のコンテンツを画面処理するステップと
   を更に有することを特徴とする方法。
3. 請求項２に記載の方法であって、
   前記判断するステップが、
   −前記ブラウザにより、前記第１の媒体形式のコンテンツが前記クライアントで画面処理可能でないことを判断し、
   −そうである場合には、前記ブラウザにより前記第１のソフトウェアコンポーネントを起動すること
   を有することを特徴とする方法。
4. 請求項３に記載の方法であって、
   前記クライアントから送信するステップが、
   −前記第１のソフトウェアコンポーネントにより、前記第１の媒体形式のコンテンツへの前記リンクと前記要求を前記サーバのアプリケーションマネージャに転送し、
   −前記アプリケーションマネージャにより、前記受信したリンクと要求に応じて、プラグイン・アプリケーションとして前記第２のソフトウェアコンポーネントを作ること
   を有することを特徴とする方法。
5. 請求項４に記載の方法であって、
   前記受信したリンクの第２の媒体形式のコンテンツを前記サーバで判断するステップが、
   −前記第２のソフトウェアコンポーネントにより、前記受信したリンクに基づいて第１の媒体形式のコンテンツを受信し、
   −前記第２のソフトウェアコンポーネントにより、前記第１の媒体形式のコンテンツを第２の媒体形式のコンテンツに変換すること
   を有することを特徴とする方法。
6. 請求項５に記載の方法であって、
   前記第１のソフトウェアコンポーネントが、デフォルトのプラグイン・アプリケーションであり、
   前記デフォルトのプラグイン・アプリケーションの動的リンクライブラリのみが前記クライアントにインストールされることを特徴とする方法。
7. 請求項５に記載の方法であって、
   前記第１のソフトウェアコンポーネントが、ActiveXコントロールであることを特徴とする方法。
8. 請求項７に記載の方法であって、
   前記第１のソフトウェアコンポーネントが、HTTPサブモジュールと、XMLサブモジュールと、表示サブモジュールとを有し、
   前記クライアントがダム端末であることを特徴とする方法。
9. 請求項１ないし８のうちのいずれか１項に記載された方法を実行するコンピュータシステム。
10. コンピュータ読取可能媒体に格納されたプログラムコード手段を有し、コンピュータプログラムがコンピュータで動作すると、請求項１ないし８のうちのいずれか１項に記載された方法を実行するコンピュータプログラム製品。
11. サーバからの画面処理サポートにより、ブラウザで第１の媒体形式のコンテンツを画面処理するクライアントであって、
    −限られたリソースが原因で、前記第１の媒体形式のコンテンツが画面処理に不適切であるか否かを判断し、そうである場合には、前記サーバからの画面処理サポートを処理及び受信するように準備して、第１のソフトウェアコンポーネントを起動する手段と、
    −前記サーバへの画面処理サポートの要求により、前記第１の媒体形式のコンテンツへのリンクを送信する手段と、
    −前記送信したリンクの第２の媒体形式のコンテンツを受信する手段であって、前記第２の媒体形式のコンテンツが前記クライアントでの画面処理に適しており、それが判断されて前記サーバから転送される手段と、
    −前記受信した第２の媒体形式のコンテンツに応じて、前記第２の媒体形式のコンテンツを画面処理する手段と
    を有するクライアント。
12. 請求項１１に記載のサーバからの画面処理サポートにより、ブラウザで第１の媒体形式のコンテンツを画面処理するクライアントであって、
    −第１の入力イベントを受信する手段と、
    −前記第１の入力イベントを、前記サーバの第２のソフトウェアコンポーネントに送信する手段と、
    −第３の媒体形式のコンテンツを受信し、前記第３の媒体形式のコンテンツが、前記受信した第１の入力イベントと前記第２の媒体形式のコンテンツに基づいて、前記サーバで前記第２のソフトウェアコンポーネントにより変換されて転送される手段と、
    −更に前記受信した第３の媒体形式のコンテンツに応じて前記第３の媒体形式のコンテンツを画面処理する手段と
    を更に有するクライアント。

Images