JPH0764893A

JPH0764893A - ネットワーク・システム

Info

Publication number: JPH0764893A
Application number: JP5215590A
Authority: JP
Inventors: Yoshikazu Yokomizo; 良和横溝
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1993-08-31
Filing date: 1993-08-31
Publication date: 1995-03-10
Also published as: US6163796A

Abstract

(57)【要約】【目的】複数のサーバへのアクセス方法を共通化す
る。【構成】クライアント１０がサービスを要求すると
き、センタ・サーバ１８にプロセス・スクリプトを発行
する。センタ・サーバ１８は、プロトコル及びデータを
変換し、利用したい既存サーバ２８に固有の言語で既存
サーバ２８にアクセスする。既存サーバ２８からの最終
結果を、共通の使用で、クライアント１０に返す。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、コンピュータのネット
ワーク・システムに関する。

【０００２】

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

【０００３】また、リレーショナル・データベース（Ｒ
ＤＢ）に関しては、一応、ＡＮＳＩのＳＱＬ言語が標準
とされているが、ＲＤＢへのアクセス・プロトコルやフ
ロントエンドのインターフェース（いわゆる、ＡＰＩ）
は各社ばらばらである。印刷に関しては、ＯＳごとの標
準は存在するが、マルチベンダ環境におけるネットワー
ク・プリンタのアーキテクチャは標準化されていない。
ＯＣＲは従来、ネットワーク化の概念が無かったので、
ネットワークＯＣＲのアクセス方法はこれから考慮され
るべき問題である。ネットワーク上の画像処理アクセラ
レータの概念も、従来存在しない。

【０００４】このように個別アプリケーション分野ごと
の標準化の努力はなされているが、分野をまたがる標準
化は、未だ無い。例えば、ＦＡＸサーバで受信した画像
をＯＣＲサーバによりコードに変換し、そのコードをデ
ータベースに蓄積するといった一連の作業を行なうに
は、各サーバ間の連携が無いので、クライアント側でフ
ァクシミリ、ＯＣＲ及びデータベースの３本のクライア
ント側プログラムを起動し、順次作業を進めて行くこと
になる。

【０００５】それでも、もし３本のプログラムが、最新
のＯＳの提供する機能をフルに用いて、アプリケーショ
ン間通信により上記の作業を自動化できるかもしれな
い。しかし、最新のＯＳでも、アプリケーション間通信
の仕組を提供するものの、その利用方法は使用者任せで
あり、何も決まっていないに等しい。

【０００６】

【発明が解決しようとする課題】従来から、各種のサー
バへのアクセス方法は、個別的に開発されている。しか
し、あらゆるサーバを１種類の統一された簡単なアクセ
ス方法でアクセスできるようにしたいとする要望があ
る。即ち、シームレスで無駄の無いサーバ環境が望まれ
ている。

【０００７】例えば、上述のように、ＦＡＸサーバで受
信した画像をＯＣＲサーバでコードに変換し、得られた
コードをデータベースに蓄積する一連の作業を想定する
と、各サーバ間の連携が無いので、クライアント側でフ
ァクシミリ・フロントエンド、ＯＣＲフロントエンド及
びデータベース・フロントエンドの３本のフロントエン
ド・プログラムを起動し、順次作業を進めて行くことに
なる。しかし、その作業は多くの「カット＆ペースト」
や「一時ファイル」へのアクセスの繰り返しとなり、苦
痛を伴う。

【０００８】また、ここのサーバへのアクセス方法は、
サーバが発明された歴史上の必然によりバラバラであ
り、サービスの分野にまたがるアクセスはほとんど不可
能である。

【０００９】そこで、本発明は、サーバ毎の互換性を無
くし、１本のアプリケーションから簡単に多くのサーバ
機能を利用できるネットワーク・システムを提示するこ
とを目的とする。

【００１０】本発明はまた、ネットワーク上の既存のバ
ラバラなインターフェースを有するサーバに１つの統一
されたアクセス方法でアクセスできるようにしたネット
ワーク・システムを提示することを目的とする。

【００１１】本発明は更に、市販のパーソナル・コンピ
ュータでも手軽にテレビ会議システムを構築できるよう
なネットワーク・システムを提示することを目的とす
る。

【００１２】

【課題を解決するための手段】本発明に係るネットワー
ク・システムは、ネットワーク上に、交換機と当該交換
機を制御するインターフェースを有するサーバとを配置
し、ネットワーク上の第１のクライアントから、ネット
ワーク上の第２のクライアントに接続すると共に、第１
のクライアントから当該サーバに対して第１及び第２の
クライアント同士を回線接続するコマンドを発行し、当
該サーバは当該コマンドに従い、第１のクライアント及
び第２のクライアントを相互に回線接続することを特徴
とする。

【００１３】

【作用】上記手段により、共通ＡＰＩで個々のサーバの
サービス機能を利用できるようになる。また、パケット
伝送を主体としリアルタイム系のデータ伝送を苦手とす
るローカルエリア・ネットワーク（ＬＡＮ）と、音声／
動画の交換を得意とするが同報通信やインテリジェント
制御を苦手とする交換機とを有機的に結合することが可
能になり、手軽にテレビ会議システムを構築できるよう
になる。

【００１４】

【実施例】以下、図面を参照して本発明の実施例を詳細
に説明する。

【００１５】サーバの提供する機能を利用するために
は、通常、サーバ／クライアントと呼ばれる通信のリン
クを設定する。クライアントは、利用者の操作するコン
ピュータ端末であり、サーバは、ネットワーク上のどこ
かに存在してサービスを提供するコンピュータである。
サーバとクライアント間は、一般的にはＬＡＮ（ＷＡＮ
を含む。）で接続され、予め決められた種々のコマンド
がやり取りされ、サーバとクライアントが連携を以って
サービスをやり取りする。この時、やりとりされるコマ
ンドは、時間軸上でのみ存在し、実際にサーバ及びクラ
イアントが受け取る情報は、処理された結果としてのデ
ータのみである。

【００１６】１つのサーバへのアクセスに関して、所定
のサービス開始コマンドのやりとりがなされた後、デー
タの授受が行なわれ、サーバは、受信したデータを加工
して、再びクライアントに送り返し、サービス終了コマ
ンドのやりとりが行なわれる。これでようやく、１種類
のサーバへのアクセスが完了する。従って、３種類のサ
ーバにアクセスするばあい、このプロセスを３回繰り返
すことになる。

【００１７】本発明は、複数種類のサービスに対する処
理手順を「プロセス・スクリプト」という記述形式で記
述し、加工したいデータとセットでサーバに伝送した
後、該当する複数のサーバ間で上記プロセス・スクリプ
トとデータのセットを順次「たらい回し」的に（シーケ
ンシャル・バッチ・パッシング）順送りしながら、デー
タが加工される。クライアントは最後の結果を待つのみ
なので、その間、別の作業が可能になり、スループット
が向上する。

【００１８】また、多くのサーバ・システムの場合、過
去の膨大な資産が存在するので、新規サーバに移行する
のは困難な場合が多い。そのため、本発明では、そのよ
うな既存サーバへのアクセスを間接的に代行するセンタ
・サーバを設け、クライアントからの標準のアクセス方
法でセンタ・サーバにアクセスし、そこから既存サーバ
を間接的に制御する仕組を提案する。特に重要な点は、
センタ・サーバがサービス機能を実際に提供する「実体
サーバ」であるか、単にスレーブのサーバを制御するだ
けの「仮想サーバ」であるのかは、クライアントは知る
必要がないという点である。

【００１９】サーバの制御をスクリプトで行なうことに
した結果、色々な応用が考えられるようになった。スク
リプトの伝送方法は、「一括伝送」と「逐次伝送」とが
ある。一括伝送は、バッチ的であり、先に述べた「たら
い回し」処理（シーケンシャル・バッチ・パッシング）
もこれに当たる。一方、逐次伝送はオンライン接続であ
り、サーバが受け取ったデータをリアルタイムで画面に
表示させ、オペレータが次の処理を指示するやり方であ
る。

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

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

【００２２】図１は、本実施例における、センサ・サー
バを介して既存サーバにアクセスする方法の説明図であ
る。図１において、１０はサーバをアクセスするフロン
トエンドとしてのアプリケーションである。１２はクラ
イアント／サーバ型の通信プログラム、１４はローカル
・エリア・ネットワーク（ＬＡＮ）、１６はクライアン
ト／サーバ型の通信プログラムである。１８はフロント
エンド・アプリケーション１０に対して統合化された標
準のアクセス環境を提供するセンサ・サーバである。フ
ロントエンド・アプリケーション１０はからは全てのサ
ービスがセンタ・サーバ１８から提供されているように
見える。

【００２３】センタ・サーバ１８は、既存の各種サーバ
を論理的に統合するのが基本機能であり、通常のサーバ
のようなサービス機能は持たない。センタ・サーバ１８
は、サーバ・マネージャ２０を通じて既存サーバ２８に
アクセスし、フロントエンド・アプリケーション１０か
らの要求に応える。２２，２４，２６はそれぞれ、通信
プログラム１２、ＬＡＮ１４及び通信プログラム１６に
対応するクライアント通信プログラム、ＬＡＮ及びサー
バ通信プログラムであるが、扱うデータとインターフェ
ースの作りが、通信プログラム１２、ＬＡＮ１４及び通
信プログラム１６とは異なる。

【００２４】既存サーバ２８にアクセスする言語（又は
コマンド）は、それぞれのサーバの発達の歴史の関係で
サーバ毎に固有のものになっている。従って、クライア
ント／サーバ通信プログラム２２，２６も独自のもので
あることが多い。従って、複数のサーバを統合するため
のセンタ・サーバ１８と接続するクライアント／サーバ
通信プログラム１２，１６とは異なる場合もある。ま
た、ＬＡＮ２４に関しては、同様の理由によりＬＡＮ１
４と同一である必要は無い。例えば、ＬＡＮ１４がＡｐ
ｐｌｅＴａｌｋ（米国のアップル・コンピュータ社の商
標）で、ＬＡＮ２４がＥｔｈｅｒｎｅｔ（米国のゼロッ
クス社の商標）であってもよい。既存サーバ２８を制御
するサーバ・マネージャ２０は、既存サーバ２８のフロ
ンとエンドとして動作するが、クライアント通信プログ
ラム２２とのインターフェースは、やはり既存のＡＰＩ
（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇ
Ｉｎｔｅｒｆａｃｅ）となる。

【００２５】一方、センタ・サーバ１８は全てのサーバ
に共通のアクセス方法を提供し、サーバ／クライアント
通信プログラム１２，１６を介して提供するＡＰＩも共
通のものとなる。従って、センタ・サーバ１８とサーバ
・マネージャ２０との間でアーキテクチャの違いを吸収
するためのプロトコル変換とデータ変換を行なうことに
なる。このため、センタ・サーバ１８とサーバ・マネー
ジャ２０は同一コンピュータの中で密接な関連のもとに
動作する。そして、センタ・サーバ１８とサーバ・マネ
ージャ２０が合わさったものが、センタ・サーバの概念
そのものとなる。従って、機能を明確に区分する必要の
あるとき、センタ・サーバ１８をサーバ・サーバと呼
ぶ。

【００２６】図２は、本発明によるセンタ・サーバを介
した既存サーバへのアクセス方法を更に解りやすく説明
する図である。クライアント３２〜４２は、共通のアク
セス方法によりセンタ・サーバ４４にアクセスすると、
センタ・サーバ４４はクライアントからの要求に基づ
き、必要なサーバ４６〜５２に個別のアクセス方法を通
じてアクセスする。したがって、各クライアント３２〜
４２は、個別の機能サーバＡ〜Ｄへのアクセス方法はお
ろか、それらの存在する知る必要は無い。

【００２７】図３は、メッセージの構造を説明する図で
ある。メッセージはプロセス・スクリプト・フォーク
と、データ・フォークからなる。簡単のため、単にプロ
セス・スクリプトとデータと呼ぶことにする。プロセス
・スクリプトとデータは、それぞれ共通の内容を持つタ
グ・エレメントを持つ。簡単のため、単にタグと呼ぶこ
とにする。このタグには、メッセージが作成された「時
間」、メッセージが消去されるべき「ライフタイム」、
一連の「ＩＤ番号」、データの「種類」、及び、データ
を作成したアプリケーションの「サイン」が記載され
る。この内、「ＩＤ番号」は必須であるが、他はオプシ
ョンである。

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

【００２９】プロセス・スクリプトは、センタ・サーバ
が機能サーバ群を使って一連の仕事をするための手順を
記述したプログラム・リストである。センタ・サーバは
プロセス・スクリプトに従って一連の作業を実行し、最
終結果だけをクライアントに返送する。従って、クライ
アントの負荷は、従来のように個々のサーバ群に個別に
アクセスを繰り返していくよりも極めて小さくなる。プ
ロセス・スクリプトは、クライアントのデバイス・ドラ
イバが自動生成することもある。プロセス・スクリプト
は、クライアントにとっては通信プロトコルの一連の関
数コール集まりにしか過ぎず、センタ・サーバにとって
は一連の通信プロトコルの中から生成されるスクリプト
言語であり、機能サーバ群にとっては通信プロトコルそ
のものである。

【００３０】図５は、機能サーバが既存サーバである場
合のアクセス方法を示す。図４と同じ構成要素には同一
の符号を付してある。この場合、メッセージ５６とプロ
セス・スクリプトとデータは分離せずにセンタ・サーバ
５８にリクエストとして送られる。リクエストされた機
能がセンタ・サーバに無い場合には、その機能を代行し
てくれる機能サーバ６０を探し、それに既存のアクセス
方法でクライアント５４のリクエストを伝え、結果を受
け取る。受け取った結果は、メッセージ６８としてクラ
イアント５４に返される。

【００３１】マルチメディア・サーバにおけるセンタ・
サーバの役割の１つは、種々のサーバのバラバラなアク
セス方法を標準化することになる。アプリケーション
は、標準化されたインターフェースを持つセンタ・サー
バにアクセスすれば、センタ・サーバが個々のサーバへ
のアクセスを代行してくれる。標準化する項目は、大き
く分けると、データの標準化とアクセス方法の標準化の
２つである。データの標準化は必ずしも一本化ではな
く、複数でも良い。特定のアプリケーションに依存しな
い業界標準のフォーマットで標準化し、且つ、標準化さ
れないデータのやり取りも許容する。主なフォーマット
は、以下の通りである。なお、ほとんどは、開発した会
社又は販売する会社の商標である。

【００３２】ＱｕｉｃｋＤｒａｗＧＤＩＲＴＦＴＩＦＦＰＩＣＴＢｉｔｍａｐＰｏｓｔＳｃｒｉｐｔＥＰＳＧ３／Ｇ４ＰＣＬＨＰ−ＧＬＡＮＳＩＳＱＬＡＳＣＩＩＴｅｘｔＵＮＩＣＯＤＥＴｅｘｔＢｉｎａｒｙＤａｔａ一方、アクセス方法の標準化は一本化に近い。統一され
たアクセス方法により、さまざまなサービスを統一的に
簡単に利用できる。但し、業界標準のアクセス方法をサ
ポートしない訳にはいかない。

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

【００３４】例えば、クライアントからＦＡＸサーバに
アクセスするための関数コールを以下のようにする。

【００３５】 MM_open("server", "fax_service"); MM_send(service_id, "MM_send", "G3","data", "destination"); MM_data(service_id, "MM_send", "data_id", "length", "content_buffe r"); MM_close(service_id); その結果、以下のようなスクリプトがセンタ・サーバに
渡される。

【００３６】アプリケーション、クライアント及びセンタ・サーバ間
のやり取りは以下の通りである。即ち、アプリケーションクライアントセンタ・サーバ MM_open("server", "fax_service"); Message("MM_open server fax_service")----> <----Message("service_id MM_open_ack") qservice_id = service_id; return(MM_open_ack); MM_send(service_id, "MM_send", "G3","data", "destination"); Message("service_id MM_send G3 data destination")----> <----Message("service_id MM_send_ack"); return(MM_send_ack); MM_data(service_id, "MM_send", "data_id", "length", "content_buffer"); Message("service_id MM_send data_id length content")----> <----Message("service_id MM_data_ack data_id); qdata_id = data_id; return(MM_data_ack); : : : MM_close(service_id); Message("service_id MM_close")----> <----Message("service_id MM_close_ack) return(MM_close_ack); アクセス・シーケンスには、以下の２種類の方式があ
る。即ち、ストアードフォワードリアルタイムである。ストアードフォワード方式は蓄積交換であり、
プロセス・スクリプトとデータのペアを伝送し終わった
ら、処理結果の成功／失敗に無関係に通信を一旦終了
し、処理の最終的な結果は、改めて通信を再開して調べ
る。サーバに作業を委託し終わったら、クライアント側
では次の作業に移れるので、資源の利用効率が高まる。
リアルタイム方式は、最終的な処理結果が確定するまで
通信回線を確保し続ける方式であり、クライアントの作
業が拘束される欠点はあるものの、処理の信頼性が高
い。

【００３７】ディジタル交換機は、公衆回線交換網及び
構内回線交換網の接続を制御するのみならず、センタ・
サーバからの接続詞時に基づいて呼制御を行なえる。Ｌ
ＡＮを経由して遅延のある通信回線を確立している複数
のクライアント簡易、構内回線交換網を経由した遅延の
無い第２の通信回線を確立することにより、リアルタイ
ム性を要求される情報（音声など）を伝達できる。

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

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

【００４０】センタ・サーバ９０はまた、制御線９６を
介してＰＢＸ９２にアクセスし、クライアント８０及び
同８２の近く（又は内臓）の電話機同士を接続詞、音声
の伝送を可能にする。

【００４１】このようにして、各クライアント８０，８
２のオペレータは、コンピュータの画面上の共通の画面
を見ながら音声で会話し、ＰＣ会議を行なうことができ
る。ＰＣ会議は１対１の接続である必要は無く、３つ以
上のクライアントを同じに接続することができる。

【００４２】上記実施例では、今日、比較的入手しやす
いコンポーネントを想定してシステム構築しているが、
ＦＤＤＩのような１００ＭＢ／秒ないしそれ以上の伝送
レーとを有するネットワークが利用できる場合には、デ
ータ・パケットと音声回線をマルチプレックスしてもよ
い。同様に、交換機ＰＢＸに接続する公衆網としてＩＳ
ＤＮを想定しているが、Ｂ−ＩＳＤＮであってもよい。
更には、米国のＳＭＤＳクラス公衆網が利用できる場合
には、ＬＡＮ側の接続を外線に接続しても構わない。多
少速度を犠牲にしてもよい場合には、ＵＮＩＸのＳＬＩ
Ｐ（ＳｅｒｉａｌＬｉｎｅＩＰ）のように、ＬＡＮ
間接続をＩＳＤＮ網を介して接続してもよい。現状の技
術でも、ＩＳＤＮルータを用いれば、ＩＳＤＮもうを介
してＬＡＮ間接続が可能である。

【００４３】以下に、本発明を適用できる分野とサービ
スの例を示す。

【００４４】（分野）（サービス）印刷カラー印刷スキャンカラー・スキャナＯＣＲＯＣＲ、ファイル・キーパ、伝票処理翻訳日英ファイルシステムＮＦＳデータベーステキスト、静止画、動画、音声会議システム共通ウインドウ＋リアルタイム音声メールテキスト、静止画、動画、音声投稿システムテキスト、静止画、動画、音声画像処理ＣＭＭ、フィルタリング、画像処理アクセラレータＦＡＸＦＡＸ送信／受信／配信ＭＨＳテキスト、ＦＡＸ、ＣＡＴＳ予約システム会議室予約次に、１０枚の原稿をスキャンし、それをＯＣＲにかけ
て文字コードに変換し、テキスト・ファイルとしてデー
タ・サーバのディスクにセーブする作業を考える。この
作業は、従来例は、以下のように処理される。即ち、スキャナで原稿をスキャン---＞クライアントに伝送イメージ・データ---＞ＯＣＲサーバに再転送ＯＣＲにかけてテキスト・データに変換テキスト・データ---＞クライアントに伝送テキスト・データ---＞データ・サーバのディスクに転
送以上を１０回繰り返す。

【００４５】これに対して、本発明では、以下のように
なる。即ち、クライアント---＞センタ・サーバにプロセス・スクリ
プトを伝送（スキャナで原稿をスキャン---＞クライアントに伝
送）（ＯＣＲにかけてテキスト・データに変換）（テキスト・データ---＞データ・サーバのディスクに
転送）センタ・サーバ---＞クライアントに結果を通知従来例では、クライアントが介在するデータ転送が４回
必要であり、パーソナル・コンピュータ程度では、通
常、１０枚もの原稿を一気にスキャンすることはしない
ので、最悪で、４０回のデータ転送が必要になる。これ
に対して本発明では、クライアントが介在するデータ転
送は２回で済み、その他は全てサーバ同士の通信であ
る。全体のデータ転送も減っている。データ転送の回数
が減るということは、コンピュータを操作する回数も減
るということになり、作業の大幅な自動化を実現でき
る。

【００４６】Ａ３サイズの原稿をネットワーク・スキャ
ナで４００ｄｐｉフルカラーでスキャンし、それを色処
理してプリンタ・サーバにより印刷する作業を考える。
従来例では、以下のように処理される。即ち、原稿のスキャン---＞クライアントに伝送イメージ・データ---＞色処理色処理後のイメージ・データ---＞プリンタ・サーバに
伝送印刷これに対して、本発明では、以下のようになる。即ち、クライアント---＞センタ・サーバにプロセス・スクリ
プトを伝送（原稿のスキャン）（イメージ・データ---＞色処理）（色処理後のイメージ・データ---＞プリンタ・サーバ
に伝送）（印刷）センタ・サーバ---＞クライアントに結果を通知なお、Ａ３サイズの原稿を４００ｄｐｉフルカラーでス
キャンすると、約９６ＭＢｙｔｅになる。このような巨
大なメインメモリを管理できるのは、ワークステーショ
ンのクラスになる。

【００４７】次に、動画ファイルをサーバに送って動画
のプレゼンテーションを実行する場合を説明する。従来
例では、次のようになる。即ち、巨大な動画ファイル---＞サーバに伝送これに対して、本発明では、次のようになる。即ち、クライアント---＞センタ・サーバに動画スクリプトを
伝送（センタ・サーバ＜---＞機能サーバ間通信）センタ・サーバ---＞クライアントに結果を通知動画ファイルは一般的に極めてサイズが大きくなる。数
１０分程度の映画で１Ｇバイトを越えることもある。こ
のようなサイズのデータを扱うためには、クライアント
のメモリやハード・ディスクを増設し、場合によって
は、ＣＰＵも高速ななものに交換する必要がある。しか
し、本発明では、サーバが動画データを記憶するので、
クライアントのメモリやハード・ディスクを増設する必
要はなく、ＣＰＵも遅いもので構わない。ネットワーク
を介してマルチメディア・サーバ（センタ・サーバ）に
プロセス・スクリプトを発行すれば、動画の再生はサー
バが代行してくれる。

【００４８】次に、複数のクライアントを同じに接続
詞、同じファイルをオープンしてどこからでも書き込め
る電子黒板を用意し、同時に交換機にアクセスしてそれ
ぞれの内線電話同士を接続し、パソコン会議を行なう場
合を説明する。従来例では、音声の入らないテキスト・
ベースの会議システム程度しか構築できないが、本発明
では、次のようになる。即ち、クライアント---＞センタ・サーバに会議要プロセス・
スクリプトを伝送（センタ・サーバ＜---＞機能サーバ間通信）クライアント---＞電子黒板アプリが起動し、電話が鳴
る。

【００４９】（クライアント＜---＞クライアント間のパソコン会
議）クライアント---＞センタ・サーバに終了プロセス・ス
クリプトを伝送センタ・サーバ---＞クライアントに結果を通知図７は、本発明のマルチメディア・サーバを米国アップ
ル・コンピュータ社製造のパーソナル・コンピュータＭ
ａｃｉｎｔｏｓｈの画像描画アクセラレータとして用い
た場合の構成例を示す。例えば、Ｂ５、４００ｄｐｉフ
ルカラー貞殿以上のビットマップ画像の編集を行なうた
めには、主メモリが数十メガバイト必要であり、従来の
パーソナル・コンピュータでは、仮に仮想メモリを使用
しても、処理速度の点で実質的に不可能に近かった。図
７に示す実施例では、マルチメディア・サーバをネット
ワーク上の仮想メモリとして使用することにより、Ａ３
サイズ程度以上のフルカラー高解像度画像の編集が可能
になる。

【００５０】図７において、アプリケーション１１０
は、モニタに何かを表示させる時に必ずＯＳの一部であ
るＱｕｉｃｋＤｒａｗ（米国アップル・コンピュータ社
の商標）１１２に描画命令を送り、画像メモリ１２６へ
のラスタライズを依頼する。アプリケーションが画像メ
モリ１２６に直接アクセスすることはない。

【００５１】一方、ビットマップ画像をモニタに表示さ
せる時には、通常、アプリケーションの責任で描画用バ
ッファ・メモリを確保し、そこにバックグラウンドで描
画した後、ＱｕｉｃｋＤｒａｗ１１２にメモリ転送の依
頼を出す。従って、描画用バッファ・メモリはアプリケ
ーションの管理下にある。描画用バッファ・メモリを仮
想メモリにして実メモリをハード・ディスク上に設定す
ることは従来から行なわれていたが、本実施例では、実
メモリをネットワーク上のマルチメディア・サーバ上に
設け、画面がアップデートされた時に、ローカル・メモ
リに部分コピーする。

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

【００５３】アプリケーションは必ずしもマルチメディ
ア・サーバを意識して設計されているわけではないの
で、アプリケーション１１０又はＱｕｉｃｋＤｒａｗ１
１２への関数コールをフックして描画コマンドハンドラ
ー１１４に強制的に制御を渡しても構わない。Ｑｕｉｃ
ｋＤｒａｗの関数コールは全て例外処理で実行されてお
り、その処理を分岐させるのは容易である。この場合、
画像メモリに対するドロー命令はＱｕｉｃｋＤｒａｗに
スルーさせる。いうまでもなく、マルチメディア・サー
バを意識して設計されたアプリケーションの方が描画効
率が高い。一方、メモリに対するビットマップ描画コマ
ンドはクライアント１１６及びサーバ１１８を介してＰ
ＤＬラスタライザ１２０に送られる。ビットマップ描画
コマンドはここでビットマップ・データにラスタライザ
され、マルチメディア・サーバ内のリモート実メモリ１
２４に描画される。リモート実メモリ１２４は１ページ
分のビットマップ・データを全て記憶できる容量を具備
する。

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

【００５５】

【発明の効果】以上の説明により容易に理解できるよう
に、本発明によれば、マルチメディア情報を扱うのに適
したサーバ・システムを提供できる。従来、ＯＣＲサー
バ、ＳＰサーバ、ＦＡＸサーバ、データベース、及び画
像処理といった単独で提供されていたサービス機能を、
ネットワーク上に仮想的な１個の統合サーバにより統合
して提供できる。

【００５６】また、共通通信プロトコルに基づいてセン
タ・サーバと接続すれば、全てのサービスを簡単に利用
できる。更に、クライアントの処理をサーバが加速する
アクセラレータ機能を提供することも可能となる。電子
メール、ニュース、ＦＴＰ及びｕｕｃｐのようなＵＮＩ
Ｘ上のサービスを、パーソナル・コンピュータのＧＵＩ
環境から簡単に利用できるようになる。

【図面の簡単な説明】

【図１】センサ・サーバを介した既存サーバへのアク
セスの説明図である。

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

【図３】メッセージの構造図である。

【図４】プロセス・スクリプトの伝送方法の説明図で
ある。

【図５】機能サーバが既存サーバである場合のアクセ
ス方法を示す図である。

【図６】センタ・サーバと交換機を結合したマルチメ
ディア・サーバの実施例の構成図である。

【図７】画像描画アクセラレータとして用いる実施例
の構成例である。

【符号の説明】

１０：アプリケーション１２：クライアント／サーバ
型通信プログラム１４：ローカル・エリア・ネットワ
ーク（ＬＡＮ）１６：クライアント／サーバ型通信プ
ログラム１８：センサ・サーバ２０：サーバ・マネ
ージャ２２：通信プログラム２４：ＬＡＮ２６：
サーバ通信プログラム２８：既存サーバ３２〜４２：
クライアント４４：センタ・サーバ４６〜５２：サ
ーバ５４：クライアント５６：メッセージ５８：
センタ・サーバ６０：機能サーバ６２：プロセス・
スクリプト・フォーク６４：データ・フォーク６
６：プロセス・スクリプト６８：結果７０〜７８：
機能サーバ８０〜８８：クライアント９０：センタ
・サーバ９２：交換機（ＰＢＸ）９４：ローカル・
エリア・ネットワーク（ＬＡＮ）９６：制御線９
８，１００：ノード１１０：アプリケーション１１
２：ＱｕｉｃｋＤｒａｗ１１４：描画コマンドハンド
ラー１１６：クライアント１１８：サーバ１２
０：ＰＤＬラスタライザ１２２：ローカル仮想メモリ
１２４：リモート実メモリ１２６：画像メモリ

Claims

【特許請求の範囲】

【請求項１】ネットワーク上に、交換機と当該交換機
を制御するインターフェースを有するサーバとを配置
し、ネットワーク上の第１のクライアントから、ネット
ワーク上の第２のクライアントに接続すると共に、第１
のクライアントから当該サーバに対して第１及び第２の
クライアント同士を回線接続するコマンドを発行し、当
該サーバは当該コマンドに従い、第１のクライアント及
び第２のクライアントを相互に回線接続することを特徴
とするネットワーク・システム。