JPH07160617A - マルチメディアサーバー - Google Patents

Abstract

(57)【要約】 【目的】 センタサーバーが各機能サーバを統合するサ
ーバーと仮想してアクセスすることができる。 【構成】 ローカルエリアネットワークを介して転送す
るセンタサーバー２６が各クライアント２０〜２５から
の発行される所定のプロセススクリプトとデータとが一
対となるメッセージを受信し、該受信したメッセージを
解釈して、各機能サーバー２７〜２９に対する通信プロ
トコル変換及びデータ変換を施して各機能サーバーに対
する連続した処理を代行しながらそれぞれのプロセスス
クリプトとデータを前記ネットワークを介して転送する
構成を特徴とする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、マルチメディアサーバ
ーに係り、ネットワーク化されたコンピュータに対して
印刷／スキャン，Ｆａｘ送受信，データベースアクセ
ス，コンピュータ会議等のさまざまなサービス機能を提
供するマルチメディアサーバーに関するものである。

【０００２】

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

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

【０００４】ＯＣＲに関しては、従来ネットワーク化の
概念がなかったために、ネットワークＯＣＲのアクセス
方法はこれから決まってくる。ネットワーク上の画像処
理アクセラレータの概念も従来はなかった。このよう
に、データベースならデータベース、ネットワークプリ
ンタならネットワークプリンタといった個別アプリケー
ション分野毎の標準化の努力はなされているが、分野を
またがる標準化はない。

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

【０００６】

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

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

【０００８】本発明は、上記の問題点を解消するために
なされたもので、ネットワーク上に固有の通信プロトコ
ルでクライアントと通信する複数の機能サーバー接続さ
れるシステムにおいて、クライアントから発行されるス
クリプトを解釈して各機能サーバーとのデータ通信を代
行処理することにより、複合的な機能処理を統合化して
処理できるマルチメディアサーバーを提供することを目
的とする。

【０００９】

【課題を解決するための手段】本発明に係る第１のマル
チメディアサーバーは、各クライアントからの発行され
る所定のプロセススクリプトとデータとが一対となるメ
ッセージを受信し、該受信したメッセージを解釈して、
各機能サーバーに対する通信プロトコル変換及びデータ
変換を施して各機能サーバに対するプロセススクリプト
とデータを前記ネットワークを介して転送するセンタサ
ーバーを前記ネットワークに接続したものである。

【００１０】本発明においては、本発明に係る第２のマ
ルチメディアサーバーは、各クライアントからの発行さ
れる所定のプロセススクリプトとデータとが一対となる
メッセージを受信し、該受信したメッセージを解釈し
て、各機能サーバーに対する通信プロトコル変換を施し
て各機能サーバに対するプロセススクリプトを前記ネッ
トワークを介して転送するセンタサーバーを前記ネット
ワークに接続したものである。

【００１１】本発明においては、本発明に係る第３のマ
ルチメディアサーバーは、センタサーバーからプロセス
スクリプトを受信した各機能サーバーは、プロセススク
リプト中のＩＤ情報に基づいてネットワークを介してク
ライアントからデータを受信するように構成したもので
ある。

【００１２】本発明においては、本発明に係る第４のマ
ルチメディアサーバーは、各クライアントからの発行さ
れる所定のプロセススクリプトとデータとが一対となる
メッセージを受信し、該受信したメッセージを解釈し
て、各機能サーバーに対する通信プロトコル変換及びデ
ータ変換を施して各機能サーバに対するプロセススクリ
プトとデータを前記ネットワークを介して転送するセン
タサーバーを前記ネットワークに接続可能に設け、さら
に、各クライアントとセンタサーバーとの電話回線を交
換する交換機を接続可能に設けたものである。

【００１３】

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

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

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

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

【００１７】

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

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

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

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

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

【００２２】そこで、サーバーマネジャー６を通じて既
存サーバー１０にアクセスし、アプリケーション１から
の要求に応える。７はクライアント通信プログラム、８
はローカルエリアネットワーク（ＬＡＮ）である。９は
サーバー通信プログラムであるが、扱うデータとインタ
フェースの作りは通信プログラム２，４と同じではな
い。

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

【００２４】また、ＬＡＮ８に関しては同様の理由によ
りＬＡＮ３と同一である必要はない。例えばＬＡＮ３が
AppleTalk でＬＡＮ８がEthernetであってもよい。既存
サーバー１０をコントロールするサーバーマネジャー６
は、既存サーバー１０のフロントエンドとして動作する
訳であるが、クライアント通信プログラム７とのインタ
フェースは、やはり既存のＡＰＩ（Application Prog
rammingInterface）となる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００４７】データの標準化は一本化ではなく、複数化
である。特定のアプリケーションに依存しない、業界標
準のフォーマットで標準化し、かつ、標準化されないデ
ータのやり取りも許容する。主なフォーマットとして現
在使用されているものは、ＱuickＤraw ，ＧＤＩ，ＲＴ
Ｆ，ＴＩＦＦ，ＰＩＣＴ，Ｂitmap ，ＰostS cript，Ｅ
ＰＳ，Ｇ３／Ｇ４，ＰＣＬ，ＨＰ−ＧＬ，ＡＮＳＩＳＱ
Ｌ，ＡＳＣIIＴext,ＵＮＩＣＯＤＥＴ ext，Ｂinary Ｄ
ata 等（登録商標及び商品名を含む）である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００７８】動画ファイルをサーバーに送って動画のプ
レゼンテーションを実行する場合。 〔従来例〕巨大な動画ファイル→サーバーに伝送 〔本実施例〕クライアント→センタサーバーに動画スク
リプトを伝送（センターサーバー−機能サーバー間通
信）センタサーバー→クライアントに結果を知らせる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００９８】

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

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

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

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

【０１０２】従って、各クライアントのアプリケーショ
ンは、ネットワーク上に接続された各機能サーバとの通
信プロトコル等を意識せずに、センタサーバーが各機能
サーバを統合するサーバーと仮想してアクセスすること
が可能となり、１本のアプリケーションから所望の機能
処理に関するスクリプトを転送するという処理で、複数
の機能サーバー処理を伴う複合的な機能処理を効率的に
処理することができる等の優れた効果を奏する。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

【符号の説明】

２０ クライアント ２１ クライアント ２２ クライアント ２３ クライアント ２４ クライアント ２５ クライアント ２６ センタサーバー ２７ 機能サーバー ２８ 機能サーバー ２９ 機能サーバー ３０ 機能サーバー

Claims (4)

【特許請求の範囲】
1. 【請求項１】 異なる機能処理を実行する複数の機能サ
   ーバーと複数のクライアントとがネットワークを介して
   接続されたマルチメディアサーバーにおいて、各クライ
   アントからの発行される所定のプロセススクリプトとデ
   ータとが一対となるメッセージを受信し、該受信したメ
   ッセージを解釈して、各機能サーバーに対する通信プロ
   トコル変換及びデータ変換を施して各機能サーバに対す
   るプロセススクリプトとデータを前記ネットワークを介
   して転送するセンタサーバーを前記ネットワークに接続
   したことを特徴とするマルチメディアサーバー。
2. 【請求項２】 異なる機能処理を実行する複数の機能サ
   ーバーと複数のクライアントとがネットワークを介して
   接続されたマルチメディアサーバーにおいて、各クライ
   アントからの発行される所定のプロセススクリプトとデ
   ータとが一対となるメッセージを受信し、該受信したメ
   ッセージを解釈して、各機能サーバーに対する通信プロ
   トコル変換を施して各機能サーバに対するプロセススク
   リプトを前記ネットワークを介して転送するセンタサー
   バーを前記ネットワークに接続したことを特徴とするマ
   ルチメディアサーバー。
3. 【請求項３】 センタサーバーからプロセススクリプト
   を受信した各機能サーバーは、プロセススクリプト中の
   ＩＤ情報に基づいてネットワークを介してクライアント
   からデータを受信することを特徴とする請求項２記載の
   マルチメディアサーバー。
4. 【請求項４】 異なる機能処理を実行する複数の機能サ
   ーバーと複数のクライアントとがネットワークを介して
   接続されたマルチメディアサーバーにおいて、各クライ
   アントからの発行される所定のプロセススクリプトとデ
   ータとが一対となるメッセージを受信し、該受信したメ
   ッセージを解釈して、各機能サーバーに対する通信プロ
   トコル変換及びデータ変換を施して各機能サーバに対す
   るプロセススクリプトとデータを前記ネットワークを介
   して転送するセンタサーバーを前記ネットワークに接続
   可能に設け、さらに、各クライアントとセンタサーバー
   との電話回線を交換する交換機を接続可能に設けたこと
   を特徴とするマルチメディアサーバー。