JPH08138033A - 画像編集装置とその方法及び画像表示制御装置とその方法及び画像編集装置と画像表示制御装置から構成されるシステム - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】 クライアントの画像描画処理をサーバーに代
行させることができる。 【構成】 アプリケーション１０１からオペレーティン
グシステム１０２に対して発行される描画関数コールを
捉えてサーバー１０５に前記描画関数コールに対応する
スクリプトを発行し、該スクリプトを解釈して前記サー
バー１０５上に確保されたリモート実メモリ１０８上に
画像を描画し、該描画された描画画像データをネットワ
ークを介して前記リモート実メモリ１０８から前記オペ
レーティングシステムに取り込み、画面メモリ１０９に
表示する構成を特徴とする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ネットワークに接続さ
れたホストコンピュータ等の画像表示制御装置及びその
方法とサーバー等の画像編集装置及びその方法と当該画
像表示制御装置と当該画像編集装置から構成されるシス
テムに関する。

【０００２】

【従来の技術】従来、ネットワーク化の進展に伴い種々
の端末が通信機能を持つようになると、相互接続性が非
常に重要になってくる。例えば、Ｆａｘの場合、公衆網
にアクセスする方法に関してはＣＣＩＴＴが規定したフ
ァクシミリ通信手順が存在するが、Ｆａｘサーバーとし
てネットワーク化しようとする場合の手順は標準化され
ていない。

【０００３】また、リレーショナルデータベース（ＲＤ
Ｂ）に関しては、一応ＡＮＳＩのＳＱＬ言語が標準とし
ての地位を確立しているが、ＲＤＢへのアクセスプロト
コルやフロントエンドのインタフェース（ＡＰＩ）は各
社バラバラである。印刷に関しては、ＯＳ毎の業界標準
は存在するが、マルチベンダー環境におけるネットワー
クプリンタのアーキテクチャは標準化されていない。

【０００４】ＯＣＲに関しては、従来ネットワーク化の
概念がなかったために、ネットワークＯＣＲのアクセス
方法はこれから決まってくる。ネットワーク上の画像処
理アクセラレータの概念も従来はなかった。このよう
に、データベースならデータベース、ネットワークプリ
ンタならネットワークプリンタといった個別アプリケー
ション分野毎の標準化の努力はなされているが、分野を
またがる標準化はない。例えば、Ｆａｘサーバーで受信
した画像をＯＣＲサーバーでコードに変換し、それをデ
ータベースに蓄積するといった一連の作業を行うには、
各サーバー間の連携はないから、クライアント側でＦａ
ｘとＯＣＲとデータベースの３本のクライアント側プロ
グラムを起動し順次作業を進めていくことになる。それ
でも、もし３本のプログラムが、最新のＯＳの提供する
機能をフルに用いて、アプリケーション間通信を行え
ば、上記の作業は自動化できるかも知れない。しかし、
最新のＯＳはアプリケーション間通信の仕組は提供する
が、そのやり方はベンダー任せであり、何も決まってい
ない。

【０００５】

【発明が解決しようとする課題】しかしながら、従来の
サーバーシステムにおいては、例えば、Ｆａｘサーバー
で受信した画像をＯＣＲサーバーでコードに変換し、そ
れをデータベースに蓄積するといった一連の作業を行う
ためには、各サーバー間の連携はないから、クライアン
ト側でＦａｘフロントエンドとＯＣＲフロントエンドと
データベースフロントエンドの３本のフロントエンドプ
ログラムを起動し順次作業を進めていくことになる。し
かし、その作業は多くの「カット＆ペースト」や「一時
ファイル」へのアクセスの繰り返しとなり苦痛を伴う。

【０００６】また、個々のサーバーへのアクセス方法
は、サーバーが発明された歴史上の必然によりバラバラ
で、サービスの分野にまたがるアクセスはほとんど不可
能である。本発明は、ネットワーク上に分散している独
立サーバーを仮想的に統合し、巨大な仮想サーバーを論
理的に構築することにより、サーバー毎の互換性をなく
し、１本のアプリケーションから簡単に多くのサーバー
機能を利用可能ならしむるためのものである。

【０００７】また、従来、小さなパーソナルコンピュー
タではメモリの不足により、大画面、高精細画像の編集
はできなかった。例えば、４００ｄｐｉ（ドット／イン
チ）でＡ４サイズのフルカラー画像は、４７メガバイト
ものメモリを必要とする。パーソナルコンピュータでこ
の様に大きな画像を扱える様にするのはコスト的にも、
速度的にも、非現実的であり、信頼性の面からも問題で
あった。なぜならシングルチップアーキテクチャの制約
から、パーソナルコンピュータのＣＰＵパワーは、それ
ほど大きくなく、速度的に遅くなる。また、ハードディ
スクをＲＡＭの一部に取り込む方法だと、スワップが発
生する度に絶望的な遅延が発生する。また、今日のパー
ソナルコンピュータのＯＳの場合、この様に大きなメモ
リを扱っていると、クラッシュしてしまう事が多い。

【０００８】かかる問題点を解決するために本発明の目
的は、サーバに描画命令を出力し、出力した前記描画命
令を解釈してサーバー上に確保された画像描画メモリ上
に描画された画像データを取得し、取得した画像データ
を画面メモリに表示する画像表示制御装置及びその方法
を提供することである。

【０００９】かかる問題点を解決するために本発明の目
的は、ホストコンピュータから描画命令を入力し、入力
した前記描画命令を解釈して、確保した画像描画メモリ
上に画像データを描画し、描画した画像データをホスト
コンピュータの画面メモリに表示する為に、画像データ
をホストコンピュータへ出力する画像編集装置及びその
方法を提供することである。

【００１０】かかる問題点を解決するために本発明の目
的は、サーバに描画命令を出力し、出力した前記描画命
令を解釈して、サーバー上に確保された画像描画メモリ
上に描画された画像データを取得し、取得した前記画像
データを画面メモリに表示する表示制御手段とを有する
ホストコンピュータと、ホストコンピュータから描画命
令を入力し、入力した前記描画命令を解釈して、確保し
た画像描画メモリ上に画像データを描画し、描画した前
記画像データを前記ホストコンピュータの画面メモリに
表示する為に、画像データをホストコンピュータへ転送
するサーバーとから構成されるシステムを提供すること
である。

【００１１】

【課題を解決するための手段】上記問題点を解決するた
めに本発明の画像表示制御装置は、画像処理を実行する
サーバーと接続された画像表示制御装置であって、前記
サーバに描画命令を出力する出力手段と、前記出力手段
で出力した前記描画命令を解釈して、前記サーバー上に
確保された画像描画メモリ上に描画された画像データを
取得する取得手段と、前記取得手段で取得した前記画像
データを画面メモリに表示する表示制御手段とを有す
る。

【００１２】上記問題点を解決するために本発明の画像
編集装置は、ホストコンピュータと接続された画像編集
装置であって、前記ホストコンピュータから描画命令を
入力する入力手段と、前記入力手段で入力した前記描画
命令を解釈して、確保した画像描画メモリ上に画像デー
タを描画する描画手段と、前記描画手段で描画した前記
画像データを前記ホストコンピュータの画面メモリに表
示する為に、前記画像データを前記ホストコンピュータ
へ出力する出力手段とを有する。

【００１３】上記問題点を解決するために本発明のシス
テムは、画像処理を実行するサーバーとホストコンピュ
ータとがネットワークに接続されたシステムであって、
前記ホストコンピュータは、前記サーバに描画命令を出
力する出力手段と、前記出力手段で出力した前記描画命
令を解釈して、前記サーバー上に確保された画像描画メ
モリ上に描画された画像データを取得する取得手段と、
前記取得手段で取得した前記画像データを画面メモリに
表示する表示制御手段とを有し、前記サーバーは、前記
ホストコンピュータから描画命令を入力する入力手段
と、前記入力手段で入力した前記描画命令を解釈して、
確保した画像描画メモリ上に画像データを描画する描画
手段と、前記描画手段で描画した前記画像データを前記
ホストコンピュータの画面メモリに表示する為に、前記
画像データを前記ホストコンピュータへ転送する転送手
段とを有する。

【００１４】上記問題点を解決するために本発明の画像
表示制御方法は、画像処理を実行するサーバーと接続さ
れた画像表示制御装置における画像表示制御方法であっ
て、前記サーバに描画命令を出力する出力工程と、前記
出力工程で出力した前記描画命令を解釈して、前記サー
バー上に確保された画像描画メモリ上に描画された画像
データを取得する取得工程と、前記取得工程で取得した
前記画像データを画面メモリに表示する表示制御工程と
を有する。

【００１５】上記問題点を解決するために本発明の画像
編集方法は、ホストコンピュータと接続された画像編集
装置における画像編集方法であって、前記ホストコンピ
ュータから描画命令を入力する入力工程と、前記入力工
程で入力した前記描画命令を解釈して、確保した画像描
画メモリ上に画像データを描画する描画工程と、前記描
画工程で描画した前記画像データを前記ホストコンピュ
ータの画面メモリに表示する為に、前記画像データを前
記ホストコンピュータへ出力する出力工程とを有する。

【００１６】

【作用】以上の構成によれば、サーバに描画命令を出力
し、出力した前記描画命令を解釈してサーバー上に確保
された画像描画メモリ上に描画された画像データを取得
し、取得した画像データを画面メモリに表示すること
で、クライアントでの画像描画処理をサーバーに代行さ
せることができる。

【００１７】以上の構成によれば、ホストコンピュータ
から描画命令を入力し、入力した前記描画命令を解釈し
て、確保した画像描画メモリ上に画像データを描画し、
描画した画像データをホストコンピュータの画面メモリ
に表示する為に、画像データをホストコンピュータへ出
力することで、クライアントでの画像描画処理を代行し
画像編集処理できる。

【００１８】

【実施例】図１は本発明の一実施例を示すマルチメディ
アサーバーのシステム構成を説明するブロック図であ
る。特に、センタサーバー１１を介した既存サーバー１
０のアクセスを行う場合に対応する。

【００１９】なお、本実施例に示すマルチメディアサー
バーにおいて、マルチメディア情報を扱うのに適したサ
ーバーは、「統合化サーバー」と「ディジタル交換機」
とから構成され、ネットワーク上に仮想的な１個の統合
化サーバーを構築して各種のサービスを提供する。

【００２０】本実施例において、「統合化サーバー」と
は、ネットワーク上に分散するサーバー群を論理的に統
合したもので、従来型の種々のサービスを提供する複数
の機能サーバーと、それらをコントロールする１個のセ
ンタサーバーとからなる。センタサーバーは専用サーバ
ーであってもよいし、クライアントが兼用するものであ
ってもよい。

【００２１】クライアント（ホストコンピュータ）から
センタサーバーを見ると、ネットワーク上に分散する複
数の機能サーバー群が、統合化した１個の巨大なサーバ
ーのように見える。勿論個々のサーバーにも従来通り個
別にアクセスしてもよいが、センタサーバーに「プロセ
ススクリプト」を渡して以後の処理はセンタサーバーに
処理を任せた方が、クライアントは次の作用に素早く移
れるので効率的である。

【００２２】図において、１はサーバーをアクセスする
「フロントエンド」としてのアプリケーションである。
ここで、「フロントエンド」を簡単に説明する。

【００２３】もし、サーバーがクライアントと同じコン
ピュータに同居していたら、アプリケーションはサーバ
ーの機能を直接呼び出して利用できる。しかし、サーバ
ーがネットワークを介して、別のコンピュータ上にある
時は、簡単ではない。なぜなら、アプリケーションは、
通信プログラムを介してサーバーにアクセスしなければ
ならないからである。

【００２４】これではアプリケーションのプログラマー
は簡単にはサーバーにアクセスするプログラムが書けな
い。そこで、サーバーのベンダーは、たとえそのサーバ
ーがネットワーク上にある場合でも、ローカルにある場
合と同じ呼び方でアクセスする仕組みを用意するのが普
通である。

【００２５】その仕組みは、サーバーの一部の様なもの
で、通信機能を持ち、クライアントにインストールされ
る。この小さなプログラムの事を、サーバーに対するフ
ロントエンドと呼び、プログラマーは通信の事を何等意
識する事なしにネットワーク上のサーバーにアクセスす
るアプリケーションを作る事ができる。

【００２６】ユーザがデータを入出力するのは、すべて
このアプリケーション１を通じて行う。２、４はクライ
アント／サーバー型の通信プログラム、３はローカルエ
リアネットワーク（ＬＡＮ）である。５は前記アプリケ
ーション１に対して統合化された標準のアクセス環境を
提供するセンタサーバーである。アプリケーション１か
らはこのセンタサーバー５が全てのサービスを提供する
ように機能する。センタサーバー５は、既存の各種サー
バーを論理的に統合するのが基本機能なので、通常はサ
ーバー本来のサービス機能は備えていない。そこで、サ
ーバーマネジャー６を通じて既存サーバー１０にアクセ
スし、アプリケーション１からの要求に応える。７はク
ライアント通信プログラム、８はローカルエリアネット
ワーク（ＬＡＮ）である。９はサーバー通信プログラム
であるが、扱うデータとインタフェースの作りは通信プ
ログラム２、４と同じではない。

【００２７】既存サーバー１０をアクセスする言語（コ
マンド）は、それぞれのサーバーの構成との関係でサー
バー毎の固有の言語を持っている。従って、アクセスす
るためのクライアント／サーバー通信プログラム７、９
も独自のものである場合も多く、複数のサーバーを統合
するためのセンタサーバー５と接続するクライアント／
サーバー通信プログラム２、４とクライアント／サーバ
ー通信プログラム７、９とは異なる場合もある。

【００２８】また、ＬＡＮ８に関しては同様の理由によ
りＬＡＮ３と同一である必要はない。例えばＬＡＮ３が
ＡｐｐｌｅＴａｌｋ（商品名）でＬＡＮ８がＥｔｈｅｒ
ｎｅｔ（商品名）であってもよい。既存サーバー１０を
コントロールするサーバーマネジャー６は、既存サーバ
ー１０のフロントエンドとして動作する訳であるが、ク
ライアント通信プログラム７とのインタフェースは、や
はり既存のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇ
ｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）となる。

【００２９】一方、センタサーバー５は全てのサーバー
に共通のアクセス方法を提供し、サーバー／クライアン
ト通信プログラム２、４を介して提供するＡＰＩも共通
のものとなる。

【００３０】従って、センタサーバー５とサーバーマネ
ジャー６との間でアーキテクチャの違いを吸収するため
のプロトコル変換とデータ変換を行うことになる。

【００３１】このため、センタサーバー５とサーバーマ
ネジャー６は同一コンピュータの中にあって密接な関連
の下で動作する。そして、センタサーバー５とサーバー
マネジャー６との機能を統合した手段がセンタサーバー
としての機能である。従って、センタサーバー５は、機
能を明確に区別する必要のある時はサーバー−サーバー
と呼ぶ。

【００３２】図２は、図１に示したセンタサーバー５を
介した既存サーバーのアクセス方法を説明する図であ
る。

【００３３】図において、クライアント２０〜２５は、
共通のアクセス方法によりセンタサーバー２６にアクセ
スすると、センタサーバーはクライアントからの要求に
基づき、必要な機能サーバー２７〜３０に個別のアクセ
ス方法を通じてアクセスする。従って、各クライアント
２０〜２５は個別の機能サーバーＡ〜Ｄへのアクセス方
法はおろか、それらの存在すら関知する必要はない。

【００３４】この様に構成されたマルチメディアサーバ
ーにおいては、ネットワークを介して転送するセンタサ
ーバーが各クライアントからの発行される所定のプロセ
ススクリプトとデータとが一対となるメッセージを受信
し、該受信したメッセージを解釈して、各機能サーバー
に対する通信プロトコル変換及びデータ変換を施して各
機能サーバーに対する連続した処理を代行しながらそれ
ぞれのプロセススクリプトとデータを前記ネットワーク
を介して転送するので、クライアントの各プログラムは
センタサーバーを複数の機能を実行させる場合であって
も、センタサーバーにその複合化された機能処理に対応
するプロセススクリプト及びデータを転送するだけで、
所望の結果データを得ることが可能となる。

【００３５】ここで「プロセススクリプト」を説明す
る。プロセススクリプトとは、通信プロトコルによって
データ通信をする基本単位で、コマンドがテキストで記
述されている。コマンドとデータを一緒に送る事もでき
る。通常は機械と機械の間の通信を行う為に用いるの
で、コマンドはテキストであってもバイナリであっても
差はない。しかし、テキストは人間が読めるので、機械
が電子メールを介して人間に送り、その結果を電子メー
ルで送ってもらうと言った変わった応用も可能である。

【００３６】プロセススクリプトの最大の特徴は、通信
プロトコル自身もスクリプトで送れるので、通信手順を
ダイナミックに変更しながら通信を成立させる事が可能
となる。例えば、Ｇ４Ｆａｘの通信手順を思い出してみ
よう。サービスが、極めて厳格なプロトコルの上に構築
されてるので、Ｆａｘを受け取ったら同じ文書を何箇所
かに配信するなどという芸当は、標準プロトコルの中で
はできない。

【００３７】プロセススクリプトは、通信手順というよ
り、サービスの手順を記述したものだから、通信方法や
通信媒体はなんでも良く、基本サービスを理解できる端
末なら、複合動作も簡単に指定できる。一例として、日
本からアメリカのオフィスにあるプリンターにＤＴＰ文
書を印刷する事を考えて見よう。普通はネットワークが
繋がっていないので、この様な事はできない。新しい方
式ならＤＴＰアプリが吐き出す印刷コマンドをプロセス
スクリプトで包んで、電子メールで相手に届ける。相手
がメールサーバーなら自動的に、そうでなければ手動
で、受信したスクリプトをスクリプトマネジャに送る
と、その内容が解析され、相手のオフィスのプリンター
に印刷出力が出て来る。

【００３８】また、各クライアントからの発行される所
定のプロセススクリプトとデータとが一対となるメッセ
ージを受信し、該受信したメッセージを解釈して、各機
能サーバーに対する通信プロトコル変換を施して各機能
サーバーに対するプロセススクリプトを前記ネットワー
クを介して転送するセンタサーバーを前記ネットワーク
に接続したので、クライアントの各プログラムはセンタ
サーバーを複数の機能を実行させる場合であっても、セ
ンタサーバーにその複合化された機能処理に対応するプ
ロセススクリプトを転送するだけで、所望の結果データ
を得ることが可能となる。

【００３９】さらに、センタサーバーからプロセススク
リプトを受信した各機能サーバーは、プロセススクリプ
ト中のＩＤ情報に基づいてネットワークを介してクライ
アントからデータを受信するので、クライアント間と各
機能サーバーにスクリプトとデータとを独立して転送す
ることが可能となる。

【００４０】また、ネットワークに接続されたセンタサ
ーバーが各クライアントからの発行される所定のプロセ
ススクリプトとデータとが一対となるメッセージを受信
し、該受信したメッセージを解釈して、各機能サーバー
に対する通信プロトコル変換及びデータ変換を施して各
機能サーバーに対するプロセススクリプトとデータを前
記ネットワークを介して転送し、交換機が各クライアン
トとセンタサーバーとの電話回線を交換するので各機能
処理実行中に音声情報等のリアルタイム情報を並行して
クライアント相互間でマルチセッションしながら複合情
報を転送することが可能となる。

【００４１】これにより、あらゆるサーバーのサービス
を１種類の統一のとれた簡単なアクセスで処理手順を標
準化し、シームレスで無駄の無いサーバー環境が提供で
き、例えばＦＡＸサーバーで受信した画像をＯＣＲサー
バーでコードに変換し、さらに、ファイルサーバーでデ
ータベースに蓄積するといった一連の複合作業を、１つ
のスクリプトで連続して処理することが可能となる。従
って、従来同様のクライアント側で処理に必要とされる
ような、クライアント側でＦＡＸフロントエンドとＯＣ
Ｒフロントエンドとデータベースフロントエンドの計３
本のフロントエンドプログラムを起動し、順次作業を進
める、カット＆ペーストや一時ファイルへのアクセスの
繰返し処理を大幅に軽減することができる。

【００４２】また、ネットワーク上に分散している独立
サーバーを仮想的に統合できるため、サーバー毎の互換
性をクライアントが意識することなく、１本のアプリケ
ーションから簡単に、かつ多くのサーバー機能もしくは
複合的なサーバー機能を利用することが可能となる。

【００４３】さらに、従来、個別の企業／業界におい
て、ばらばらに開発されてきたサーバー装置へのアクセ
ス方法を統合化し、ネットワーク上の既存のばらばらな
インタフェースを有するサーバーに１つの統合されたア
クセス方法でアクセスする手段を提供することが可能と
なる。以下、それぞれの実施例に分けて詳述する。

【００４４】図３は本発明に係るマルチメディアサーバ
ーにおけるメッセージの構造を説明する図である。

【００４５】図３に示すように、本実施例におけるメッ
セージは、プロセススクリプトフォーク（プロセススク
リプト）とデータフォーク（データ）とから構成されて
いる。また、プロセススクリプトとデータは、それぞれ
共通の内容を持つタグエレメント（タグ）を備えてい
る。

【００４６】このタグには、メッセージが作成された
「時間」、メッセージが消去されるべき「ライフタイ
ム」、一連の「ＩＤ番号」、データの「種類」、データ
を作成したアプリケーションの「サイン」等が記載され
る。

【００４７】この内「ＩＤ番号」は必須であるが、他は
オプションである。

【００４８】図４は本発明に係るマルチメディアサーバ
ーにおける第１のプロセススクリプトの送出手順を説明
するブロック図である。

【００４９】通常、クライアント４１、センタサーバー
４３、機能サーバー４４は、全て同一のＬＡＮ上に存在
する場合が多い。そして、機能サーバー４４が本発明に
準拠したプロセススクリプトを理解できるサーバーの場
合には、センタサーバー４３がクライアント４１にその
事を指示し、クライアント４１はメッセージ４２をプロ
セススクリプト４５とデータフォーク（データ）４６と
に切り放して、それぞれセンタサーバー４３と機能サー
バー４４に別々に送信することができる。センタサーバ
ー４３は、受信したプロセススクリプト４５に必要な編
集を施した後、機能サーバー４４に新たなプロセススク
リプト４７を送り届ける。機能サーバー４４にとって
は、クライアント４１もセンタサーバー４３も共にクラ
イアントであるから、別々に届いたプロセススクリプト
４７とデータ４６を結合し、データに必要な処理を施し
て結果のメッセージ４８をＬＡＮを介してクライアント
４１に返す。

【００５０】なお、本実施例において、プロセススクリ
プトとは、センタサーバー４３が機能サーバー４４群を
使って一連の仕事をするための手順を記述したプログラ
ムリストであり、センタサーバー４３はそれに基づいて
一連の作業を実行し、最終結果のメッセージ４８だけを
クライアント４１に返すので、クライアント４１の負荷
は、従来型の機能サーバー群に個別にアクセスを繰り返
していくよりも極めて小さくなる。

【００５１】プロセススクリプトは、クライアント４１
のデバイスドライバーが自動生成することもあり、該プ
ロセススクリプトはクライアント４１にとっては、通信
プロトコルの一連の関数コールの集りにしか過ぎず、セ
ンタサーバー４３にとっては一連の通信プロトコルの中
から生成されるスクリプト言語であり、機能サーバー４
４群にとっては通信プロトコルそのものである。

【００５２】プロセススクリプトの特徴として、従来の
コンピュータ通信の形態を大きく分けると、 リアルタイム処理 バッチ処理 の２つがあった。

【００５３】バッチ処理は、大型コンピュータ（メイン
フレーム）で処理する時に良く使われた手法で、大勢の
ユーザ（クライアント）が処理を集中させた場合、ジョ
ブをキューに順番に溜め込み、順番に処理してユーザに
返すというやり方である。結果がいつ出てくるのか分か
らないという欠点があり、どうしても進捗を見たい場合
には、キューを覗いたりしなければならなかった。

【００５４】リアルタイム処理は、プロトコルのやり取
りによって何時でも進捗が分かる仕組みが用意されてお
り、そのプロセスの中で必要な処理が実行される。

【００５５】一見便利に見えるリアルタイム処理である
が、これにはネットワークもリアルタイム系でなければ
ならないという条件が付く。例えば、ネットワークがイ
ンターネットの様な「ストアード・フォーワード」型の
場合、ハブを何箇所か中継して行くと、その度に数分の
遅延が生ずる。この様なネットワークでは、リアルタイ
ム処理が使えない。

【００５６】プロセススクリプトは、この様な「ストア
ード・フォーワード」型のネットワークに最適な通信方
法で、リアルタイム処理とバッチ処理の中間的な特性を
持っている。スクリプトとは「記述する」という意味
で、コマンドがテキストで記述されており、その分プロ
トコルが簡単になる。

【００５７】リアルタイム処理の例を、図５に示す。こ
の図では、ユーザが「データを送るよ」というコマンド
を発行し、サーバーから「いいよ」という返事をもらっ
たら、「データ」を送り、「完了」という返事に対し、
「了解」という送達確認を送っている。この様なプロト
コルが使えるのは、間に何もハブを介さないユーザとサ
ーバーのエンドツーエンドの通信だからである。

【００５８】これがもし図６の様に、ハブ１、２、３を
介在する通信の場合どうなるかと言うと、同図の様に
「データを送るよ」から「いいよ」まで順番に遅延が蓄
積して行き、「データ」送信にたどり着くだけでも大変
で、そのうちどこかの通信接続が（タイムアウト等で）
切れてしまう。全く実用にならない。

【００５９】図７はストアードフォーワード型のネット
ワークを考慮したバッチ処理の例である。「データを送
るよ」に対して「いいよ」の返事は、近接したハブから
もらっている。この様にすれば、比較的早く「データ」
を送れる。しかし、この方法でも、途中で何らかの通信
エラーが発生した時の回復ルーチンは、気が遠くなるほ
ど複雑である。「データを送るよ」が途中で紛失した場
合ならなんとかなるだろうが、「いいよ」が紛失した
ら、その回復は多分不可能であろう。

【００６０】図８はプロセススクリプトを用いた通信方
法の例である。「処理して返事しろ」というコマンドと
「データ」がセットになって順に送られる。処理結果も
「処理結果だよ」というコマンドと処理済みの「デー
タ」がセットで送られるので、このネットワークではこ
れより早い通信方法は無い。通信異常でプロセススクリ
プトが紛失した場合でも、コマンドとデータがセットに
なっているので回復も容易である。

【００６１】図９は本発明に係るマルチメディアサーバ
ーにおける第２のプロセススクリプトの送出手順を説明
するブロック図であり、特に、機能サーバーが既存のサ
ーバーである場合のアクセス方法を示したものであり、
図４と同一のものには同一の符号を付してある。

【００６２】この図において、メッセージ４２のプロセ
ススクリプトとデータは分離せずにセンタサーバー４３
にリクエストとして送られる。リクエストされた機能が
センタサーバー４３に無い場合には、その機能を代行し
てくれる機能サーバー４４を捜し、それに既存のアクセ
ス方法でクライアント４１のリクエストを伝え結果を受
け取る。その結果はメッセージ４８としてクライアント
４１に返される。〈通信プロトコル〉マルチメディアサ
ーバーにおけるセンタサーバーの役割の一つは、種々の
サーバーのバラバラなアクセス方法を標準化することに
ある。アプリケーションは、標準化されたインタフェー
スを持つセンタサーバーにアクセスすれば、そこから個
々のサーバーへのアクセスはセンタサーバーが代行して
くれる。標準化する項目は、大きく分けると、データの
標準化とアクセス方法の標準化の２つある。

【００６３】データの標準化は一本化ではなく、複数化
である。特定のアプリケーションに依存しない、業界標
準のフォーマットで標準化し、かつ、標準化されないデ
ータのやり取りも許容する。

【００６４】主なフォーマットとして現在使用されてい
るものは、ＱｕｉｃｋＤｒａｗ、ＧＤＩ、ＲＴＦ、ＴＩ
ＦＦ、ＰＩＣＴ、Ｂｉｔｍａｐ、ＰｏｓｔＳｃｒｉｐ
ｔ、ＥＰＳ、Ｇ３／Ｇ４、ＰＣＬ、ＨＰ−ＧＬ、ＡＮＳ
ＩＳＱＬ、ＡＳＣＩＩＴｅｘｔ、ＵＮＩＣＯＤＥＴｅｘ
ｔ、Ｂｉｎａｒｙ Ｄａｔａ等（登録商標及び商品名を
含む）である。

【００６５】一方、アクセス方法の標準化は一本化に近
い。統一されたアクセス方法により、さまざまなサービ
スを統一的に簡単に利用できる。

【００６６】ただし、業界標準のアクセス方法はサポー
トしない訳にはいかない。一方、図３で説明したよう
に、伝送する内容はメッセージ、すなわち、「プロセス
スクリプト」と「データ」とがセットになっている。
「データ」は、処理されるべき情報そのものであり、
「プロセススクリプト」はその情報をどう扱うかを記述
したコマンドシーケンスである。「プロセススクリプ
ト」と「データ」のセットがサーバー間を伝送され、必
要な処理がなされていく。「プロセススクリプト」の受
渡し方法を標準化することにより、さまざまなサーバー
に同じアクセス方法でアクセスできる。

【００６７】また、プロトコルの異なるサーバーに対し
ては、センタサーバー４３がゲートウェイとして機能す
る。例えばクライアント４１からＦａｘサーバーにアク
セスするための関数コールが図１０の（ａ）に示す内容
が発せられ、その結果、図６の（ｂ）に示すようなスク
リプトがセンタサーバー４３に渡される。

【００６８】図１０は図９で用いるプロセススクリプト
の例である。（ａ）はプロセススクリプトを生成する時
の関数。（ｂ）は実際にネットワーク上に送出されるス
クリプト部分である。この場合、Ｇ３ファクシミリを例
に取っているので、データとしてはＭＭＲデータが流れ
るが、省略してある。

【００６９】ＭＭ ｏｐｅｎでサーバーのアドレス（ｓ
ｅｒｖｅｒ）とサービス種別（ｆａｘ ｓｅｒｖｉｃ
ｅ）を指定する。

【００７０】ＭＭ ｓｅｎｄでｆａｘ ｓｅｒｖｉｃｅ
の形式はＧ３である事を指定する。送信先Ｆａｘ番号
（ｄｅｓｔｉｎａｔｉｏｎ）もセットする。

【００７１】ＭＭ ｄａｔａで送信データバッファのサ
イズ（ｌｅｎｇｔｈ）と中身（ｃｏｎｔｅｎｔ ｂｕｆ
ｆｅｒ）を送る。

【００７２】ＭＭ ｃｌｏｓｅでこのサービスを終了さ
せる。プロセススクリプトは柔軟なので、この時はリア
ルタイム系に近い使い方をしている。

【００７３】図１１では、図１０で簡略化して書いたシ
ーケンスを詳細に説明している。

【００７４】アプリケーション、クライアントとセンタ
サーバーとの通信プロトコルは、図１１に示す手順に従
うものとする。

【００７５】なお、アクセスシーケンスとして、以下の
２種類の方式がある。

【００７６】第１は、ストアードフォーワード方式で、
蓄積交換であり、プロセススクリプトとデータのペアを
伝送し終わったら、処理結果の成功／失敗に関係なく通
信を一旦終了し、処理の最終的な結果は、改めて通信を
再開して調べる。サーバーに作業を委託し終わったら、
クライアント側では次の作業に移れるので、資源の利用
効率が高まる。

【００７７】第２は、リアルタイム方式であり、最終的
な処理結果が確定するまでは通信の接続を確保し続ける
方式で、クライアントの作業が拘束される欠点はあるも
のの、処理の信頼性は高い。

【００７８】以下、本実施例におけるディジタル交換機
の機能処理について説明する。

【００７９】本実施例のディジタル交換機は、公衆回線
交換網および構内回線交換網を接続制御する交換機で、
センタサーバー４３からの接続指示に基づいて呼制御を
行える。ＬＡＮを経由した遅延のある接続がなされてい
る複数のクライアントの間に、構内回線交換網を経由し
た遅延のない第２の接続を行うことにより、リアルタイ
ム性を要求される情報（音声）等を伝達できる。

【００８０】図１２は本発明におけるセンタサーバーと
交換機を結合したマルチメディアサーバーとによるシス
テム構成を説明するブロック図であり、図２の応用例で
ある。

【００８１】図１２において、６１〜６５は各種の機能
サーバー、６６〜７０はクライアント、７１は各機能サ
ーバー６１〜６５を統合するセンタサーバー、７３はロ
ーカルエリアネットワーク（ＬＡＮ）、７２は内線／外
線の電話回線を交換する交換機（ＰＢＸ）である。ＬＡ
Ｎ７３を介したデータ転送は、パケット化されて伝送さ
れるため、音声や動画等のリアルタイム系の伝送には適
さないが、全てのクライアントが常に接続されていると
いう特徴を生かして、接続制御の不要なデータ転送や、
同報通信に適する。

【００８２】一方、ＰＢＸ７２は音声や動画等のリアル
タイム系の伝送に適する。ＬＡＮとＰＢＸの特徴を生か
して、パソコン会議システム（ＰＣ会議）を構築するこ
とができる。いま、クライアント６６から６７にアクセ
スしてＰＣ会議を行う場合を考える。クライアント６６
はノード７５を介してセンタサーバー７１に対し、クラ
イアント６７とＰＣ会議を開始するための開始命令スク
リプトを発行する。センタサーバー７１は、クライアン
ト６７のマルチメディアクライアントデーモン（ＭＣ
Ｄ）と接続しＰＣ会議の開始を指示するスクリプトを発
行する。ここで、デーモンとはバックグラウンドで常に
走っているプログラムのことをいう。そのスクリプトに
はＰＣ会議のＩＤ番号が書かれているので、以後そのＩ
Ｄ番号宛にクライアントからスクリプトを送り合うこと
により、各クライアント間でデータ通信が可能となる。

【００８３】一方、同時に、センタサーバー７１は、制
御線７４を介してＰＢＸ７２にアクセスし、クライアン
ト６６と６７の近く（または内蔵）の電話機同士を接続
し、音声の伝送を可能にする。この様にして各クライア
ント６６、６７のオペレータはコンピュータの画面上の
共通の画面を見ながら音声で会話をし、ＰＣ会議を行う
事ができる。ＰＣ会議は、１対１の接続である必要は無
く、複数のクライアントを同時に接続する事もできる。

【００８４】これにより、パケット伝送を主体とし、リ
アルタイム系のデータ伝送を苦手とするＬＡＮと、音声
／動画の交換を得意とするが、同報通信やインテリジェ
ントな制御を苦手とする交換機を有機的に結合し、市販
のパソコンに何等特別なオプションパーツを付加接続す
ることなく、パソコン会議システムを構築することも可
能となる。

【００８５】以下、高速データハイウェーを利用したサ
ービス機能について説明する。

【００８６】なお、本実施例では、今日比較的入手し易
いコンポーネントを想定してシステム構築を考えたが、
ＦＤＤＩ（Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａ
ｔａＩｎｔｅｒｆａｃｅ：米国ＡＮＳＩ規格）の様な１
００Ｍｂｐｓないしそれ以上の伝送レートを有するネッ
トワークが利用できる場合には、データパケットと音声
回線をマルチプレックスしても良い。

【００８７】同様に本実施例では、交換機ＰＢＸに接続
する公衆網として、ＩＳＤＮを想定しているが、Ｂ−Ｉ
ＳＤＮであっても構わない。また、米国のＳＭＤＳクラ
ス公衆網が利用できる場合にはＬＡＮ側の接続を外側に
接続しても構わない。

【００８８】また、多少速度を犠牲にしても構わない場
合には、ＵＮＩＸのＳＬＩＰ（ＳｅｒｉａｌＬｉｎｅＩ
Ｐ）の様に、ＬＡＮ間接続をＩＳＤＮ網を介して接続し
ても構わない。また、現状の技術でも、ＩＳＤＮルータ
を用いればＩＳＤＮ網を介してＬＡＮ間接続が可能であ
る。

【００８９】以下に、本発明が適応可能なサービスの例
を示す。

【００９０】（分野）−（サービス） 印刷−カラー印刷 スキャン−カラースキャナ ＯＣＲ−ＯＣＲ、ファイルキーパー、伝票処理 翻訳−日英 ファイルシステム−ＮＦＳ データベース−テキスト、静止画、動画、音声 会議システム−共用ウインドウ＋リアルタイム音声 メール−テキスト、静止画、動画、音声 投稿システム−テキスト、静止画、動画、音声 画像処理−ＣＭＭ、フィルタリング、画像処理アクセラ
レータ Ｆａｘ−Ｆａｘ送信／受信／配信 ＭＨＳ−テキスト、Ｆａｘ、ＣＡＴＳ 予約システム−会議室予約等である。

【００９１】以下、ＯＣＲサービスを例としてサービス
機能処理について従来と本実施例とを対比して説明す
る。

【００９２】いま、１０枚の原稿をスキャンし、それを
ＯＣＲにかけて文字コードに変換し、それをテキストフ
ァイルとしてデータサーバーのディスクにセーブする作
業を考える。

【００９３】従来では、（スキャナで原稿のスキャンし
てクライアントに伝送）（イメージデータをＯＣＲサー
バーに再転送ＯＣＲに掛けてテキストデータに変換）
（テキストデータをクライアントに伝送）（テキストデ
ータをデータサーバーのディスクに転送）を１０回繰り
返す。

【００９４】一方、本実施例では、クライアント→セン
タサーバーにプロセススクリプトを伝送（スキャナで原
稿のスキャン→ＯＣＲサーバーに伝送）（ＯＣＲに掛け
てテキストデータに変換）（テキストデータ→データサ
ーバーのディスクに転送）センタサーバー→クライアン
トに結果を知らせる。

【００９５】従来例では、クライアントが介在するデー
タ転送が４回必要で、通常のパソコンではハードディス
ク容量の制限から、１０枚もの原稿を一気にスキャンす
る事はしないので、最悪４０回のデータ転送が必要にな
る。それに対してクライアントが介在するデータ転送は
２回で済み、その他はすべてサーバー同士の通信であ
る。全体のデータ転送も減っている。クライアントが関
係しないデータ通信／処理はカッコで示してある。デー
タ転送の回数が減るという事は、コンピュータを操作す
る回数も減る事になるので、作業の大幅な自動化が実現
される。

【００９６】以下、スキャンサービスを例としてサービ
ス機能処理について従来と本実施例とを対比して説明す
る。

【００９７】Ａ３サイズの原稿をネットワークスキャナ
で４００ｄｐｉフルカラーでスキャンし、それに色処理
して、プリンタサーバーに印刷する作業を考える。

【００９８】従来例では、原稿のスキャン→クライアン
トに伝送イメージデータ→色処理後のイメージデータ→
プリンタサーバーに伝送印刷 一方、本実施例では、クライアント→センタサーバーに
プロセススクリプトを伝送（原稿のスキャン）（イメー
ジデータ→色処理）（色処理後のイメージデータ→プリ
ンタサーバーに伝送）（印刷）センタサーバー→クライ
アントに結果を知らせる。

【００９９】通常のパソコンではメモリ容量の制限があ
るので、実は、従来例というのは机上の計算値でしかな
く、実際には９６ＭＢｙｔｅもの巨大なメインメモリを
管理できるＯＳは事実上存在しないに等しい。

【０１００】以下、メールサービスを例としてサービス
機能処理について従来と本実施例とを対比して説明す
る。

【０１０１】動画ファイルをサーバーに送って動画のプ
レゼンテーションを実行する場合。

【０１０２】従来例では、 巨大な動画ファイル→サーバーに伝送 一方、本実施例では、クライアント→センタサーバーに
動画スクリプトを伝送（センタサーバー−機能サーバー
間通信）センタサーバー→クライアントに結果を知らせ
る。

【０１０３】動画ファイルは一般的に極めてサイズが大
きくなる。数１０分程度の映画で１ギガバイトを越える
事もある。

【０１０４】この様なサイズのデータを扱うためには、
従来のクライアントのメモリやハードディスクを増設
し、場合によってはＣＰＵ本体も高速な物に交換する必
要があった。

【０１０５】しかし、本実施例では、サーバーが動画デ
ータを記憶してくれるのでクライアントのメモリやハー
ドディスクを増設する必要は無く、ＣＰＵも遅い物で構
わない。ネットワークを介してマルチメディアサーバー
（センタサーバー）にプロセススクリプトを発行すれ
ば、動画の再生はサーバーが代行してくれる。

【０１０６】以下、メールサービスを例として会議シス
テム機能処理について従来と本実施例とを対比して説明
する。

【０１０７】複数のクライアントを同時に接続し、同じ
ファイルをオープンしてどこからでも書き込める電子黒
板を用意し、同時に交換機にアクセスしてそれぞれの内
線電話同士を接続し、パソコン会議を行う。

【０１０８】従来例では、音声の入らない、テキストベ
ースの会議システム程度一方、本実施例では、クライア
ント→センタサーバーに会議用プロセススクリプトを伝
送（センタサーバー−機能サーバー間通信）（クライア
ントとクライアント間のパソコン会議）（クライアント
→センタサーバーに終了プロセススクリプトを伝送）伝
送センタサーバー→クライアントに結果を知らせる。

【０１０９】以下、図１３を参照しながら本発明に係る
マルチメディアサーバーを画像描画アクセラレータとし
て機能させる場合について説明する。

【０１１０】図１３は本発明に係るマルチメディアサー
バーを画像描画アクセラレータとして機能させる場合の
概念を説明するブロック図である。特に、本実施例で
は、マルチメディアサーバーをアップルコンピュータ株
式会社のコンピュータ（登録商標：Ｍａｃｉｎｔｏｓ
ｈ）の画像描画アクセラレータとして用いた場合の例で
ある。

【０１１１】例えば、Ｂ５で４００ｄｐｉフルカラー程
度以上のビットマップ画像の編集を行う為には、メイン
メモリが数十メガバイトも必要になり、従来のパソコン
では不可能であった。最新のＯＳの提供する仮想メモリ
機能を利用しても、処理速度の点からＡ４で４００ｄｐ
ｉフルカラー程度が限度であろう。

【０１１２】一方、本実施例のマルチメディアサーバー
をネットワーク上の仮想メモリとして利用する事によ
り、Ａ３サイズ程度以上のフルカラー高解像度画像の編
集を可能にする。ここで、仮想メモリを説明する。

【０１１３】極めて巨大なメモリを利用する方法。実メ
モリとは、通常は半導体メモリ（あるいは主記憶）の事
を言い、要求された巨大なメモリサイズのごく一部しか
存在しない。それに対して、仮想メモリとは、ハードデ
ィスクやネットワーク上のサーバーのメモリ（あるいは
補助記憶）の事を言い、アクセス速度は遅いが極めて巨
大な記憶空間を有する。

【０１１４】主記憶と補助記憶をうまく組み合わせて、
アプリから見たら、全メモリ空間が一様でシームレスな
空間であるかの様に見せる方法を仮想メモリと言う。

【０１１５】アプリが主記憶に無い部分をアクセスしに
行くと、メモリコントローラはエラーを検知するので、
それまであった主記憶の情報を補助記憶に退避させ、逆
に補助記憶から必要な情報を主記憶に呼び出し、かつ、
その主記憶のアドレスを要求されたメモリ空間にスワッ
プさせる事により、アプリから見たらあたかも巨大なメ
モリが実際に存在するかの様に見える。

【０１１６】具体的には、アプリケーション１０１は、
モニタに何かを表示させる時には、必ずＯＳの一部であ
る描画管理プログラム（商品名ＱｕｉｃｋＤｒａｗ）１
０２に描画命令を送り、画面メモリ１０９へのラスタラ
イズを依頼する。アプリケーションが画像メモリを直接
アクセスする事は無い。

【０１１７】一方、ビットマップ画像をモニタに表示さ
せる場合には、通常アプリケーションの責任で描画用バ
ッファメモリを確保し、そこにバックグラウンドで描画
した後、ＱｕｉｃｋＤｒａｗ１０２にメモリ転送の依頼
を出す。

【０１１８】従って、描画用バッファメモリはアプリケ
ーションの管理下にあり、それを仮想メモリにして実メ
モリをハードディスク上に設定する事は従来から行われ
ていた。

【０１１９】本実施例においては、実メモリをネットワ
ーク上のマルチメディアサーバー上に設け、画面がアッ
プデートされた時にローカルメモリに部分コピーを行
う。

【０１２０】１０３はマルチメディアサーバーの機能を
クライアント側でアプリケーションに引き渡す為のＡＰ
Ｉ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ
Ｉｎｔｅｒｆａｃｅ）である描画コマンドハンドラで
ある。アプリケーション１０１がこのＡＰＩに対してＱ
ｕｉｃｋＤｒａｗに対するコールと同じパラメータを渡
してネットワーク上のサーバーに確保したメモリに描画
する。

【０１２１】アプリケーションは必ずしもマルチメディ
アサーバーを意識して設計されている訳ではないので、
アプリケーション１０１かＱｕｉｃｋＤｒａｗ１０２へ
の関数コールをフックして描画コマンドハンドラ１０３
に強制的に制御を渡しても構わない。ＱｕｉｃｋＤｒａ
ｗの関数コールは全て例外処理で行っており、その処理
を分岐させる事はたやすい。この場合、画像メモリに対
するドロー描画コマンドはＱｕｉｃｋＤｒａｗにスルー
させる。マルチメディアサーバーを意識して設計された
アプリケーションの方が描画効率が高い事は言うまでも
ない。

【０１２２】一方、メモリに対するビットマップ描画コ
マンドはクライアント１０４、サーバー１０５を介して
ＰＤＬラスタライザー１０６に送られる。ビットマップ
描画コマンドはここでビットマップデータにラスタライ
ズされ、マルチメディアサーバー内のリモート実メモリ
１０８に描画される。リモート実メモリ１０８は１ペー
ジ分のビットマップデータを全て記憶できる容量があ
る。それに対してローカル仮想メモリ１０７の容量は限
定されたものである。

【０１２３】ローカル仮想メモリ１０７は、仮想的にリ
モート実メモリ１０８と重なり合うものであるが、実際
にメモリが割り当てられている部分は、現在編集中の限
られた領域のみである。編集中の領域が変更になれば、
新しい領域の画像データをリモート実メモリ１０８から
コピーして来る。

【０１２４】これにより、通常ではメモリ容量等の制限
から、Ａ３、４００ｄｐｉフルカラー画像の編集等、従
来ならば不可能な画像編集処理を安価な端末からネット
ワーク上の資源を利用して処理することができる。

【０１２５】図１４に本発明による画像描画アクセラレ
ータのブロック図を示す。点線から右がサーバー側、点
線から左がクライアント側である。図１３と同じ機能要
素には同じ番号を付与してある。

【０１２６】例えば、クライアントがＭａｃｉｎｔｏｓ
ｈ（商品名）の場合を例に取って説明すると、普通の使
い方ではアプリケーション１０１が画面に描画する場
合、ｇｒａｆｐｏｒｔと呼ばれる画面メモリ管理システ
ム１０９をコールし、描画ポートを確保する。ｇｒａｆ
ｐｏｒｔが確保する画面バッファメモリはビットマップ
系であり、その解像度は７２ｄｐｉ（ドット／インチ）
である。

【０１２７】アプリケーション１０１はＱｕｉｃｋＤｒ
ａｗ（商品名）と呼ばれる一連の画面描画関数をコール
する事ができ、通常それはＴｏｏｌＢｏｘコール（ＯＳ
のシステムコール）の形でＯＳ１０２Ｕ制御が渡され
る。ＯＳは受け取った画面描画関数コールをビットマッ
プにラスタライズしてｇｒａｆｐｏｒｔに描画する。

【０１２８】本発明では、ＱｕｉｃｋＤｒａｗのＴｏｏ
ｌＢｏｘコールをフック（盗んで）して一旦ネットワー
ク描画アクセラレータ１１０（ｎｅｔ ｇｒａｆｐｏｒ
ｔ）に制御を渡し、それが改めてＴｏｏｌＢｏｘコール
を発生させている。ネットワーク描画アクセラレータ１
１０は描画コマンドハンドラ１０３とクライアン通信プ
ログラム１０４を包含した部分を説明している。

【０１２９】ここで、クライアン通信プログラム１０４
は、単に通信手段を提供する通信プログラムであるが、
クライアント側と言うと、図の点線から左すべてを差し
て呼ぶ。サーバー側とサーバーの呼び方についても同様
で、通信プログラム部分だけを指す場合とサーバー側と
言うと点線から右全体を指す場合とがある。

【０１３０】さて、ネットワーク描画アクセラレータ１
１０は、アプリケーション１０１からのＱｕｉｃｋＤｒ
ａｗのＴｏｏｌＢｏｘコールをプロセススクリプトに変
換してＬＡＮを介してネットワーク描画アクセラレータ
サーバー（サーバー側）にも伝える。それを受信した画
像処理サーバ１１１は、例えば、４００ｄｐｉ（ドット
／インチ）の高精細の解像度で高精細描画システム１０
８（ｓｅｒｖｅｒ ｇｒａｆｐｏｒｔ）にクライアント
と同じ画像を描画する。ローカル画面メモリ（画面メモ
リ管理システム１０９が管理するバッファメモリ）への
描画が完了すると同時に、サーバー側では高精細な画像
の描画が完了しており、必要ならそのまま印刷出力もで
きるし、フィルムに焼く事もできる。

【０１３１】図１５にネットワーク描画アクセラレータ
１１０のブロック図を示す。クライアント側に関しては
全てソフトウエアで実現する事も可能であるが、処理を
高速化させる為にアクセラレータボードによるハードウ
エアで実現する事もできるこのアクセラレータはボード
の形でクライアントのコンピュータのバス（νバス）２
０９に挿入する。バスＩ／Ｏ２０６はボード内部の内部
バス２０５と外部バス２０９との接続とアービトレーシ
ョンを行う為のバスＩ／Ｏである。内部バス上にはＣＰ
Ｕ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＬＡＮＩ／Ｆ
２０４があり、マイクロコンピュータを形成している。

【０１３２】割込ハンドラ２０７は、クライアントコン
ピュータ本体の割り込み信号線２１０をボード上のＣＰ
Ｕ２０１に導入する為のものである。ＢＵＳ ＩＮＴ信
号２１１は、Ｉ／Ｏ２０８を介してマザーボードに出力
され、クライアントコンピュータ本体のＣＰＵにバスの
使用を要求するための制御線である。ＢＵＳ ＡＣＫ信
号２１２は、バスが解放されたかどうかを知らせる制御
線である。

【０１３３】アプリケーションが描画コマンドを発行す
ると、何らかのＱｕｉｃｋＤｒａｗルーチンがコールさ
れ、割り込み（ＩＮＴ）が発生するから、その信号は割
り込み信号線２１０を介して検知する事ができる。その
割り込み信号に基づき、ＣＰＵ２０１はＩ／Ｏ２０８を
イネーブルにし、ＢＵＳＩＮＴ信号２１１をグラントし
てマザーボードのＣＰＵにバス解放要求を出す。バスが
実際に解放されてトライステート状態になったら、ＢＵ
ＳＡＣＫ信号が帰されてＣＰＵ２０１はバス２０９が使
える状態になった事を知る。そこでＢＵＳＩ／Ｏ２０６
をアクセスして内部バス２０５と外部バス２０９を結合
し、所定の外部メモリ（図示せず）に書かれている割り
込みジャンプテーブルのポインターをフェッチして来
る。ポインターの指し示すメモリの内容を読むと、割り
込みの種類が判別できるから、ＱｕｉｃｋＤｒａｗルー
チンに関する割り込みであった場合には、ＲＡＭ２０３
上でＱｕｉｃｋＤｒａｗコマンドをプロセススクリプト
に変換してそれをＬＡＮ Ｉ／Ｆ２０４からサーバーに
伝送する。

【０１３４】サーバー側で、全画面のリモート実メモリ
に描画された内容のミラーイメージが、ローカル仮想メ
モリ１０７に反映される。実際には、画面メモリ１０９
と同じ大きさのローカル実メモリ１１２の部分のみがコ
ピーされる。アドレスコンバーター１１３は、外部バス
２０９から見た実メモリ１１２が、あたかも仮想メモリ
１０７の一部であるかの様に見せかける為のアドレス変
換を行う回路である。仮想メモリ１０７の原点（左上）
の座標が、Ｘ、Ｙであり、実メモリ１１２の矩形領域の
座標が、ｘ、ｙであるなら、アドレスコンバーター１１
３は外部バス２０９からアクセスされるアドレスに対
し、Ｘ−ｘ、Ｙ−ｙ、の演算を実行する。

【０１３５】マザーボードのＣＰＵ（図示せず）がＣＲ
Ｔに表示している部分、すなわち実メモリ１１２の内部
だけで演算している場合は、仮想メモリ上の実メモリの
位置関係は変化しない。しかし、スクロール等で実メモ
リの外側をアクセスしようとすると、割り込み信号１１
４を発生させ、ＣＰＵ２０１に割り込み信号を与える。
ＣＰＵ２０１は割り込みの原因を調べ、ＬＡＮ２０４を
介してサーバーに対して新しい座標位置のビットマップ
画像を送信する事を要求すると共に、アドレスコンバー
ターをセットしなおし、実メモリの相対位置を変更す
る。割り込み信号１１４は、実際にはアドレスコンバー
ター１１３が生成する。

【０１３６】以下、図１６を参照しながら本発明に係る
マルチメディアサーバーにおけるローカル仮想メモリ処
理動作の概要について説明する。

【０１３７】図１６は発明に係るマルチメディアサーバ
ーにおけるローカル仮想メモリ処理の概要を示すチャー
トである。例えばＭａｃＯＳによるＱｕｉｃｋＤｒａｗ
のアクセラレータ処理について説明する。

【０１３８】なお、本実施例のローカルメモリは、本来
アプリケーションがＯＳに要求して実メモリとして確保
する代りに、ネットワークで接続されたサーバー上に確
保した実メモリを仮想的にリモートのメモリであるかの
ように処理する。従って、ローカル仮想メモリは、ロー
カルなクライアントマシン上に仮想的に存在し、実メモ
リはリモートのサーバー上に実在する。

【０１３９】具体的には、アプリケーションが描画を開
始する時、ＭａｃＯＳに対してメモリ確保コマンドとし
て、例えばＮｅｗＰｔｒ（Ｎｅｗ Ｐｏｉｎｔｅｒの略
でメモリ領域を確保するコマンド）を発行する。描画コ
マンドハンドラは、そのコマンドをストール（盗んで）
してプロセススクリプト（Ｐスクリプト）に変換し、ク
ライアント／サーバーの通信路を介してＰＤＬスタライ
ザ／サーバー（以後、リモート描画エンジン）にプロセ
ススクリプト（Ｐスクリプト）を送る。

【０１４０】リモート描画エンジンは、リモートのＯＳ
（図示しない）にｍａｌｌｏｃコマンド（ｍｅｍｏｒｙ
ａｌｌｏｃａｔｅの略でＮｅｗ Ｐｔｒと同じ働きを
する）を発行して実メモリを確保するとともに、プロセ
ススクリプトをクライアントに返す。そのプロセススク
リプトは、描画コマンドハンドラからアプリケーション
に対し、メモリのポインタとして返されるので、アプリ
ケーションからはあたかもローカルに実メモリがあるか
のように見える。

【０１４１】次に、アプリケーションは、ローカル仮想
メモリに何かを描画しようとして、ＭａｃＯＳに「描画
コマンド」を発行する。その「描画コマンド」は同様に
描画コマンドハンドラにストールされ、プロセススクリ
プトに変換され、「リモート描画エンジン」に送られて
リモート実メモリ上に実際に描画される。これは、４０
０ｄｐｉの高解像度で行われる。描画コマンドハンドラ
は、クライアントのモニタ上にも描画する必要があるの
で、クライアントのＭａｃＯＳに対しても描画コマンド
をエミュレートして伝送する。この場合は、７２ｄｐｉ
の低解像度で描画される。

【０１４２】一方、描画の結果はプロセススクリプトに
変換され、同様にクライアントに戻される。このプロセ
スは、必要な回数だけ繰り返し実行される（図中の太線
の流れに対応する）。

【０１４３】描画が終了して印刷をする場合、本実施例
によらなければ、ローカルのクライアント上で４００ｄ
ｐｉの高解像度でラスタライズし、その膨大なデータを
プリンタに伝送することになるが、本実施例によれば、
描画が終了した時点で高解像度のラスタライズは「リモ
ートエンジン」上で完了しているので、膨大なデータを
送ることなしに、直ちに印刷を開始できる。従って、伝
送されるのは、「印刷コマンド」のみである。

【０１４４】なお、完成したビットマップの高解像度の
画像データを２次記憶装置等（図示しない）にセーブす
る場合にも、「セーブコマンド」を発行するものの、そ
れによって「リモート描画エンジン」から送られてきた
「Ｄａｔａ」を直接２次記憶装置等にセーブすれば、ロ
ーカルに実メモリを備える必要はなくなる。

【０１４５】以下、図１３のシステム原理図と図１７の
フローチャートの両方を参照しながら、画像描画アクセ
ラレータの動作を詳細に説明する。

【０１４６】図１７は画像描画アクセラレータ１１０の
動作フローチャートであり、中央から左半分がクライア
ント側、右側がサーバー側の動作を示す。図では、クラ
イアント／サーバー間の一般的な接続動作（例えばＡｐ
ｐｌｅＴａｌｋやＴＣＰ／ＩＰなどのコネクション）は
完了しているものとして説明している。なお、図１６の
左半分のフローチャートに示すプログラムは、クライア
ント側のネットワーク描画アクセラレータ１１０のＲＯ
Ｍ２０２或いはＲＡＭ２０３に格納されており、ＣＰＵ
２０１により実行される。また、図１６の右半分のフロ
ーチャートに示すプログラムは、サーバー側の不図示の
ＲＯＭ或いはＲＡＭに格納されており、不図示のＣＰＵ
により実行される。

【０１４７】クライアントのアプリケーションが描画作
業を実行する前には、その結果を保存するメモリを確保
しに行く。その動作はＯＳに対する要求動作であり、一
般的にはシステムコールと呼ばれる。Ｍａｃｉｎｔｏｓ
ｈの場合にはツールボックスコールという。描画コマン
ドハンドラ１０３を介してＣＰＵ２０１はその関数コー
ルをフックして、サーバー側に実メモリを確保する様に
要求する。それがステップＳ１２と２３のやり取りに示
される。

【０１４８】同時に描画コマンドハンドラ１０３を介し
てＣＰＵ２０１は、ステップＳ１３に示す様に、ローカ
ルマシン上にも、画面メモリ用の最低限のバッファメモ
リを確保する。このローカルマシンの画面は７２ｄｐｉ
（ドット／インチ）なので、バッファメモリのサイズは
極めて小さい。

【０１４９】次に、リモート実メモリ１０８と同じサイ
ズのローカル仮想メモリ１０７のポインターのみを確保
し、ステップＳ２３で帰された実メモリへのポインター
で、上書きする。さらに、ステップＳ１３で確保した画
面メモリのポインターを、仮想メモリ１０７空間の適当
な部分に割り当てる。これによって、巨大なリモート実
メモリ１０８に描画された絵の一部分がクライアントの
画面に表示される様になる。

【０１５０】その後、描画コマンドハンドラ１０３を介
してＣＰＵ２０１はイベント待ち（ステップＳ１５）に
なり、もし何らかの描画イベントが発生すると（ステッ
プＳ１６）その描画コマンドをサーバー側に送信すると
共にローカルマシンの画面メモリにも同じ描画を実行し
て（ステップＳ１７）画面表示する。描画コマンドを受
信したサーバー側はＰＤＬラスタライザ１０６を介して
不図示のＣＰＵが実メモリ１０８に高精細で描画する
（ステップＳ２４）。

【０１５１】先にも述べた様に、ローカルマシンの画面
には巨大なリモート実メモリ１０８に描画された絵の一
部分が表示されているので、イベントとしては描画コマ
ンドだけではなく、画面を上下左右にスクロールさせる
スクロールイベント待ちになる（ステップＳ１８）。こ
の場合、ローカル仮想メモリ１０７の表現するメモリ空
間の一部に存在する様に割り当てられているローカル画
面メモリ１０９の矩形領域を表すパラメータが、スクロ
ールさせる分だけ変更になる（ステップＳ１９）。

【０１５２】ローカル画面メモリ１０９をローカル仮想
メモリ１０７空間内で移動させると、ローカル画面メモ
リに書かれている絵と、リモート実メモリ１０８に描画
された同じ位置の絵とが食い違って来る。そこで描画コ
マンドハンドラ１０３を介してＣＰＵ２０１はサーバー
に対して新しい矩形領域のビットマップ画像を送る様に
要求する（ステップＳ２５）。

【０１５３】サーバーの不図示のＣＰＵは指定された領
域のビットマップ画像情報をクライアント側に送り（ス
テップＳ２６）、クライアント側のＣＰＵ２０１はそれ
をローカル仮想メモリ１０７にコピーする。すなわち、
結果としてその画像情報はローカル画面メモリ１０９上
に上書きされ、表示画面は新しくなる。

【０１５４】その後はイベント待ちを繰り返す。

【０１５５】アプリケーション１０１がビットマップ画
像を編集する場合、ＯＳの描画機能１０２を用いてロー
カル実メモリ（図示せず）上で画像編集し、その結果を
画面メモリ１０９を介してモニター（図示せず）に表示
する。しかし、本発明で用いるローカルメモリは、その
一部しか実体として持たない仮想メモリ１０７である。
これによって巨大なメモリを用意する必要がなくなっ
た。この場合、図１３の×印の様に本来全ての描画コマ
ンドがＯＳのラスタライザ１０２に渡されていた所をス
トールして描画コマンドハンドラ１０３に導き、必要に
応じてラスタライザ１０２でローカル仮想メモリ１０７
と画面メモリ１０９を間接的に制御する。

【０１５６】ストールされた描画コマンドは、クライア
ント通信プログラム１０４、サーバー通信プログラム１
０５を介してサーバー側のラスタライザ１０６に伝達さ
れる。そして高精細なリモート実メモリ１０８にビット
マップ画像が描画される。リモート実メモリ１０８上に
ラスタライザされた画像は、そのまま印刷できる。

【０１５７】ローカル仮想メモリ１０７は、画面メモリ
１０９と同じサイズのメモリで、リモート実メモリ１０
８の一部分に相当する。ネットワーク画像処理を行う場
合、まず１０４と１０５の間で一般的なクライアント／
サーバーコネクションを張ったあと、アプリケーション
が要求する画像メモリを確保する。メモリ確保要求は描
画コマンドハンドラ１０３がフェッチし、実際にはロー
カルマシン上には仮想メモリ１０７が確保され、本当の
メモリの実体は、ステップＳ１２と２３のやり取りによ
り、サーバー上のリモート実メモリ１０８として確保さ
れる。仮想メモリ１０７及びリモート実メモリ１０８の
仮想的な大きさは一致しており、扱う原稿サイズ毎に異
なる。

【０１５８】画面メモリ用のバッファも同時にステップ
Ｓ１３でローカルマシン上に確保される。その後はアプ
リケーション１０１は描画入力イベント待ちの状態にな
り、すなわち描画コマンドハンドラ１０３も入力待ちに
なる。これはステップＳ１５に示される。もし操作者が
マウス等を操作して、何らかの描画のコマンドを入力す
ると、それがもし描画イベントならば描画コマンドがロ
ーカルマシンのラスタライザ１０２とサーバーのラスタ
ライザ１０６の両方に送られて、画面メモリ１０９とロ
ーカル仮想メモリ１０７及びリモート実メモリ１０８の
３箇所にそれぞれＣＰＵ２０１、サーバーの不図示のＣ
ＰＵによって描画される。このステップを１６、１７、
２４に示す。

【０１５９】もし、先の描画イベントが画面のスクロー
ルの場合には、ローカル仮想メモリ１０７における画面
メモリ１０９の参照座標が変化するが、そこには画像が
存在しないので、ステップＳ１９及び２５の様にサーバ
ーに矩形領域の変更が知らされ、ステップＳ２０、２６
の様にリモート実メモリ１０８の所定の位置からビット
マップ情報がクライアントに転送される。その後サーバ
ーもクライアントもそれぞれ次のイベント待ちに入る。

【０１６０】以上説明したように、本実施例によれば、
アプリケーションからオペレーティングシステムに対し
て発行される描画関数コールを捉えて前記サーバーに前
記描画関数コールに対応するスクリプトを発行し、該ス
クリプトを解釈して前記サーバー上に確保された画像描
画メモリ上に画像を描画し、該描画された描画画像デー
タを前記ネットワークを介して前記画像メモリから前記
オペレーティングシステムに取り込み、画面メモリに描
画するので、クライアントで処理可能なデータ量を越え
る大容量の画像描画処理を高速に行うことができる。

【０１６１】また、本実施例によれば、アプリケーショ
ンからオペレーティングシステムに対して発行される描
画関数コールを捉えて前記サーバーに前記描画関数コー
ルに対応するスクリプトを発行し、該スクリプトを解釈
して前記サーバー上に確保された画像描画メモリ上に画
像を描画し、該描画された描画画像データを前記ネット
ワークを介して前記画像メモリからローカル仮想メモリ
を介して前記オペレーティングシステムに取り込み、画
面メモリに描画するので、クライアントで処理可能なデ
ータ量を越える大容量の画像描画、特に編集画面に対応
した描画処理を高速に行うことができる。

【０１６２】また、本実施例によれば、各クライアント
から画像描画開始を指示するスクリプトを前記サーバー
に発行し、該発行されたスクリプトに基づいて画像描画
プログラムを起動するとともに、画像描画メモリを確保
し、該確保された画像メモリに対応するパラメータを前
記クライアントに返信して、前記クライアントからネッ
トワークを介して受信する各描画命令に基づいて前記画
像メモリに所望の画像を描画するので、クライアントの
画像処理能力を越える画像編集処理を行うことができ
る。

【０１６３】また、本実施例によれば、サーバーは、各
クライアントから画像描画開始を指示するスクリプトを
解析して、クライアントの出力デバイスに対応する解像
度よりも高解像度の画像描画を保証する画像描画メモリ
を確保するので、クライアントの画像処理能力を越える
高解像度の画像編集処理を高速に行うことができる。

【０１６４】

【発明の効果】以上説明した様に本発明によれば、サー
バーに描画命令を出力し、出力した前記描画命令を解釈
してサーバー上に確保された画像描画メモリ上に描画さ
れた画像データを取得し、取得した画像データを画面メ
モリに表示することで、クライアントでの画像描画処理
をサーバーに代行させることができるという効果を奏す
る。

【０１６５】以上説明した様に本発明によれば、ホスト
コンピュータから描画命令を入力し、入力した前記描画
命令を解釈して、確保した画像描画メモリ上に画像デー
タを描画し、描画した画像データをホストコンピュータ
の画面メモリに表示する為に、画像データをホストコン
ピュータへ出力することで、クライアントでの画像描画
処理を代行し画像編集処理できるという効果を奏する。

【図面の簡単な説明】

【図１】本発明の一実施例を示すマルチメディアサーバ
ーのシステム構成を説明するブロック図である。

【図２】図１に示したセンタサーバーを介した既存サー
バーのアクセス方法を説明する図である。

【図３】本発明に係るマルチメディアサーバーにおける
メッセージの構造を説明する図である。

【図４】本発明に係るマルチメディアサーバーにおける
第１のプロセススクリプトの送出手順を説明するブロッ
ク図である。

【図５】本発明に係るリアルタイム処理を説明する図で
ある。

【図６】本発明に係る他のリアルタイム処理を説明する
図である。

【図７】本発明に係るバッチ処理を説明する図である。

【図８】本発明に係るプロセススクリプトを用いた通信
方法を説明する図である。

【図９】本発明に係るマルチメディアサーバーにおける
第２のプロセススクリプトの送出手順を説明するブロッ
ク図である。

【図１０】本発明に係るクライアントからセンタサーバ
ー転送されるスクリプト例を示す図である。

【図１１】本発明に係るクライアント、アプリケーショ
ンとセンタサーバーと通信プロトコルの一例を示す図で
ある。

【図１２】本発明におけるセンタサーバーと交換機を結
合したマルチメディアサーバーとによるシステム構成を
説明するブロック図である。

【図１３】本発明に係るマルチメディアサーバーを画像
描画アクセラレータとして機能させる場合の構成を説明
するブロック図である。

【図１４】本発明に係る画像描画アクセラレータのシス
テムブロック図である。

【図１５】本発明に係るネットワーク描画アクセラレー
タの具体的なブロック図である。

【図１６】本発明に係るマルチメディアサーバーにおけ
るローカル仮想メモリ処理の概要を示すチャートであ
る。

【図１７】本発明に係る画像描画アクセラレータの動作
を示すフローチャートである。

【符号の説明】

２０１ ＣＰＵ ２０２ ＲＯＭ ２０３ ＲＡＭ ２０４ ＬＡＮ／ＩＦ ２０５ 内部バス ２０６ Ｂｕｓ Ｉ／Ｏ ２０７ ＩＮＴ ２０８ Ｉ／Ｏ ２０９ 外部バス

Claims (34)

【特許請求の範囲】
1. 【請求項１】 画像処理を実行するサーバーと接続され
   た画像表示制御装置であって、 前記サーバに描画命令を出力する出力手段と、 前記出力手段で出力した前記描画命令を解釈して、前記
   サーバー上に確保された画像描画メモリ上に描画された
   画像データを取得する取得手段と、 前記取得手段で取得した前記画像データを画面メモリに
   表示する表示制御手段とを有することを特徴とする画像
   表示制御装置。
2. 【請求項２】 前記サーバー上に確保された前記画像描
   画メモリは、前記画像表示制御装置の前記画面メモリよ
   り大きいことを特徴とする請求項１記載の画像表示制御
   装置。
3. 【請求項３】 前記サーバー上に確保された前記画像描
   画メモリの解像度は、前記画像表示制御装置の前記画面
   メモリの解像度より高いことを特徴とする請求項１記載
   の画像表示制御装置。
4. 【請求項４】 前記画像表示制御装置の画面メモリに表
   示される画像データは、前記サーバー上に確保された前
   記画像描画メモリに描画される画像データの一部である
   ことを特徴とする請求項１記載の画像表示制御装置。
5. 【請求項５】 前記画像表示制御装置の画面メモリに表
   示される画像データをスクロールすると、前記サーバー
   上に確保された前記画像描画メモリに描画される画像デ
   ータの一部が前記画面メモリに複写されることを特徴と
   する請求項１記載の画像表示制御装置。
6. 【請求項６】 前記画像表示制御装置は、ホストコンピ
   ュータであることを特徴とする請求項１記載の画像表示
   制御装置。
7. 【請求項７】 前記サーバーと前記画像表示制御装置
   は、ネットワークを介して接続されていることを特徴と
   する請求項１記載の画像表示制御装置。
8. 【請求項８】 ホストコンピュータと接続された画像編
   集装置であって、 前記ホストコンピュータから描画命令を入力する入力手
   段と、 前記入力手段で入力した前記描画命令を解釈して、確保
   した画像描画メモリ上に画像データを描画する描画手段
   と、 前記描画手段で描画した前記画像データを前記ホストコ
   ンピュータの画面メモリに表示する為に、前記画像デー
   タを前記ホストコンピュータへ出力する出力手段とを有
   することを特徴とする画像編集装置。
9. 【請求項９】 前記画像編集装置に確保された前記画像
   描画メモリは、前記ホストコンピュータの前記画面メモ
   リより大きいことを特徴とする請求項８記載の画像編集
   装置。
10. 【請求項１０】 前記画像編集装置に確保された前記画
    像描画メモリの解像度は、前記ホストコンピュータの前
    記画面メモリの解像度より高いことを特徴とする請求項
    ８記載の画像編集装置。
11. 【請求項１１】 前記ホストコンピュータの画面メモリ
    に表示される画像データは、前記画像編集装置に確保さ
    れた前記画像描画メモリに描画される画像データの一部
    であることを特徴とする請求項８記載の画像編集装置。
12. 【請求項１２】 前記ホストコンピュータの画面メモリ
    に表示される画像データをスクロールすると、前記画像
    編集装置に確保された前記画像描画メモリに描画される
    画像データの一部が前記画面メモリに複写されることを
    特徴とする請求項８記載の画像編集装置。
13. 【請求項１３】 前記画像編集装置は、サーバーである
    ことを特徴とする請求項８記載の画像編集装置。
14. 【請求項１４】 前記ホストコンピュータと前記画像編
    集装置は、ネットワークを介して接続されていることを
    特徴とする請求項８記載の画像編集装置。
15. 【請求項１５】 画像処理を実行するサーバーとホスト
    コンピュータとがネットワークに接続されたシステムで
    あって、 前記ホストコンピュータは、 前記サーバに描画命令を出力する出力手段と、 前記出力手段で出力した前記描画命令を解釈して、前記
    サーバー上に確保された画像描画メモリ上に描画された
    画像データを取得する取得手段と、 前記取得手段で取得した前記画像データを画面メモリに
    表示する表示制御手段とを有し、 前記サーバーは、 前記ホストコンピュータから描画命令を入力する入力手
    段と、 前記入力手段で入力した前記描画命令を解釈して、確保
    した画像描画メモリ上に画像データを描画する描画手段
    と、 前記描画手段で描画した前記画像データを前記ホストコ
    ンピュータの画面メモリに表示する為に、前記画像デー
    タを前記ホストコンピュータへ転送する転送手段とを有
    することを特徴とする。
16. 【請求項１６】 前記サーバー上に確保された前記画像
    描画メモリは、前記ホストコンピュータの前記画面メモ
    リより大きいことを特徴とする請求項１５記載のシステ
    ム。
17. 【請求項１７】 前記サーバー上に確保された前記画像
    描画メモリの解像度は、前記ホストコンピュータの前記
    画面メモリの解像度より高いことを特徴とする請求項１
    ５記載のシステム。
18. 【請求項１８】 前記ホストコンピュータの画面メモリ
    に表示される画像データは、前記サーバー上に確保され
    た前記画像描画メモリに描画される画像データの一部で
    あることを特徴とする請求項１５記載のシステム。
19. 【請求項１９】 前記ホストコンピュータの画面メモリ
    に表示される画像データをスクロールすると、前記サー
    バー上に確保された前記画像描画メモリに描画される画
    像データの一部が前記画面メモリに複写されることを特
    徴とする請求項１５記載のシステム。
20. 【請求項２０】 前記サーバーと複数のホストコンピュ
    ータが前記ネットワークに接続されていることを特徴と
    する請求項１５記載のシステム。
21. 【請求項２１】 画像処理を実行するサーバーと接続さ
    れた画像表示制御装置における画像表示制御方法であっ
    て、 前記サーバに描画命令を出力する出力工程と、 前記出力工程で出力した前記描画命令を解釈して、前記
    サーバー上に確保された画像描画メモリ上に描画された
    画像データを取得する取得工程と、 前記取得工程で取得した前記画像データを画面メモリに
    表示する表示制御工程とを有することを特徴とする画像
    表示制御方法。
22. 【請求項２２】 前記サーバー上に確保された前記画像
    描画メモリは、前記画像表示制御装置の前記画面メモリ
    より大きいことを特徴とする請求項２１記載の画像表示
    制御方法。
23. 【請求項２３】 前記サーバー上に確保された前記画像
    描画メモリの解像度は、前記画像表示制御装置の前記画
    面メモリの解像度より高いことを特徴とする請求項２１
    記載の画像表示制御方法。
24. 【請求項２４】 前記画像表示制御装置の画面メモリに
    表示される画像データは、前記サーバー上に確保された
    前記画像描画メモリに描画される画像データの一部であ
    ることを特徴とする請求項２１記載の画像表示制御方
    法。
25. 【請求項２５】 前記画像表示制御装置の画面メモリに
    表示される画像データをスクロールすると、前記サーバ
    ー上に確保された前記画像描画メモリに描画される画像
    データの一部が前記画面メモリに複写されることを特徴
    とする請求項２１記載の画像表示制御方法。
26. 【請求項２６】 前記画像表示制御装置は、ホストコン
    ピュータであることを特徴とする請求項２１記載の画像
    表示制御方法。
27. 【請求項２７】 前記サーバーと前記画像表示制御装置
    は、ネットワークを介して接続されていることを特徴と
    する請求項２１記載の画像表示制御方法。
28. 【請求項２８】 ホストコンピュータと接続された画像
    編集装置における画像編集方法であって、 前記ホストコンピュータから描画命令を入力する入力工
    程と、 前記入力工程で入力した前記描画命令を解釈して、確保
    した画像描画メモリ上に画像データを描画する描画工程
    と、 前記描画工程で描画した前記画像データを前記ホストコ
    ンピュータの画面メモリに表示する為に、前記画像デー
    タを前記ホストコンピュータへ出力する出力工程とを有
    することを特徴とする画像編集方法。
29. 【請求項２９】 前記画像編集装置に確保された前記画
    像描画メモリは、前記ホストコンピュータの前記画面メ
    モリより大きいことを特徴とする請求項２８記載の画像
    編集方法。
30. 【請求項３０】 前記画像編集装置に確保された前記画
    像描画メモリの解像度は、前記ホストコンピュータの前
    記画面メモリの解像度より高いことを特徴とする請求項
    ２８記載の画像編集方法。
31. 【請求項３１】 前記ホストコンピュータの画面メモリ
    に表示される画像データは、前記画像編集装置に確保さ
    れた前記画像描画メモリに描画される画像データの一部
    であることを特徴とする請求項２８記載の画像編集方
    法。
32. 【請求項３２】 前記ホストコンピュータの画面メモリ
    に表示される画像データをスクロールすると、前記画像
    編集装置に確保された前記画像描画メモリに描画される
    画像データの一部が前記画面メモリに複写されることを
    特徴とする請求項２８記載の画像編集方法。
33. 【請求項３３】 前記画像編集装置は、サーバーである
    ことを特徴とする請求項２８記載の画像編集方法。
34. 【請求項３４】 前記ホストコンピュータと前記画像編
    集装置は、ネットワークを介して接続されていることを
    特徴とする請求項２８記載の画像編集方法。