JP3561016B2

JP3561016B2 - Multimedia system

Info

Publication number: JP3561016B2
Application number: JP31390394A
Authority: JP
Inventors: ガーランドジェー．ディヴィッド; アール．マックギーアンドリュー
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 1993-12-21
Filing date: 1994-12-19
Publication date: 2004-09-02
Anticipated expiration: 2019-09-02
Also published as: JPH07202981A; EP0660576A2; DE69432287T2; EP0660576B1; DE69432287D1; EP0660576A3; CA2118278A1; US5754784A; CA2118278C

Abstract

The provisioning of a multimedia application is enhanced by using a communications protocol which defines a number of different functions and which allows a multimedia application to be segmented into a plurality of logical blocks such that a user may enter a request characterizing one such function and, in response thereto, the system performs the function with respect to a particular one of the logical blocks. The underlying multimedia system is also enhanced by arranging it so that an application provider may interact with the system via a telecommunications network for the purpose of, for example, storing the application thereon and/or "debugging" the stored application. <IMAGE>

Description

【０００１】
【産業上の利用分野】
本発明は、マルチメディア通信システムに関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
公衆遠隔通信網におけるＩＳＤＮの提供の結果、多くの新規なサービスが導入されている。前記サービスの１つは、マルチメディア、すなわち映像（すなわち画像）及び対応する音声信号の伝送を伴う。マルチメディアアプリケーションの結果として、発呼者及び被呼者は、ＩＳＤＮ通信パスを介して電話会話中にお互いを見たり聞いたりすることができる。マルチメディアは、ＩＳＤＮを介して発呼者に提供することができる他のサービスアプリケーション、例えば、音声付き動画のような、発呼者を楽しませるアプリケーション、を含む。このようなマルチメディアサービスアプリケーションは、おそらく種々のマルチメディアアプリケーション提供者によって開発されていると思われる。それが実情とわかれば、使用者に、アクセスを遂行するのに用いる機器の形式、例えばコンピュータ端末、にかかわらず、種々の提供者により開発された種々のマルチメディアアプリケーションをアクセスするのを許すことが望ましい。
【０００３】
マルチメディアアプリケーションの開発は容易な仕事ではなく、典型的には、アプリケーションの設計、“デバッギング”、そして使用者への提供のためのマルチメディアシステムへの格納を伴うことが認められる。アプリケーションは、新たに設計されたマルチメディアアプリケーションとマルチメディアシステム間に生じるかもしれないインターフェース問題を処理するために、マルチメディアシステムに格納された後で追加の“デバッギング”を要する場合がある。マルチメディアアプリケーションの設計者／提供者は、マルチメディアシステムを複製し、そのシステムをマルチメディアアプリケーションの設計／開発及びデバッギング段階の間のツールとして用いることによって、後者の問題を処理することができる。しかし、マルチメディアアプリケーションの設計及びデバッグに用いる目的でマルチメディアシステムを複製するのは、費用がかかりかつ多少無益なものとなると認められる。
【０００４】
【課題を解決するための手段】
マルチメディアサービスの提供は、マルチメディアアプリケーションを使用者への提供のための複数の区分に分割させる通信プロトコルを用いることによって強化される。詳細には、本発明の通信プロトコルは、マルチメディアアプリケーションを使用者への提供のための多数の論理ブロックに分割させる方法で、各機能（遠隔通信、データ、音声等）を定義する複数のメッセージに埋め込まれる。したがって、本発明によれば、使用者が、特定のマルチメディアアプリケーションとインターフェースして、上述の機能のうちの１つを表わす特定の要求を入力した場合、使用者の関連データ端末は、その機能を定義するメッセージを発生してマルチメディアシステムに送り、該マルチメディアシステムは、使用者がアクセス中のマルチメディアアプリケーションを構成するプログラムブロックのうちの特定のブロックに関して要求された機能を実行することによって、それに応答する。
【０００５】
本発明の他の態様によれば、マルチメディアアプリケーションの提供者は、前記アプリケーションを遠隔通信網を介して格納のためマルチメディアシステムに送り、前記アプリケーションの“デバッギング”及び／または開発を含む多数の異なる目的のために遠隔通信網を介して格納されているアプリケーションと対話させることができる。
【０００６】
【実施例】
さて、図１を参照すると、本発明の原理を具体化したマルチメディアシステム１００の主要ブロック図が示されている。詳細には、システム１００は、使用者に特定のマルチメディアアプリケーションを提供するために互いに協動する多数の制御装置を含む。前記制御装置は、データサーバー１０、アプリケーション制御装置２０、音声サーバー３０、ワークステーション４０、開発プラットフォーム１５０及び動作援助装置５０を含む。データサーバー１０は、例えばＡＴ＆Ｔから入手できる３８６−ＷＧＳワークステーションとすることができ、ＭＳＤＯＳオペレーティングシステムのもとに動作して、マルチメディアアプリケーションの提供に関連するデータ機能を与えるようにプログラムされている。より詳細には、データサーバー１０は、通信パス１１−１を介して使用者とインターフェースし、使用者からの要求の受信に応じて、前記要求そのものを処理するかまたは前記要求をアプリケーション制御装置２０もしくは音声サーバー（制御装置）３０に送るかを決定する。例えば、要求が（ａ）音楽の特定の選択のような音声に向けられたものならば、データサーバー１０は前記要求を処理するためにＬＡＮ４５を介して音声サーバー３０に送り、あるいは要求が（ｂ）特定のマルチメディアアプリケーションに向けられたものならば、データサーバー１０は前記要求をＬＡＮ４５を介してアプリケーション制御装置２０に送る。要求がデータ機能、例えばメモリ６１に格納されている特定データ、に関するものならば、データサーバー１０は、メモリ６１から前記データをおろし、前記データを通信パス１１−１を介して使用者に送る。本発明の実施例では、前記データは、例えば、データベース６１に格納されている数値化された画像、文書、図形原線、アニメーション原線、実行可能なプログラム等でも良い。本発明の実施例では、前記データは圧縮されたフォーマットでデータベース６１に格納することができる。（下記に説明されるように、前記データの圧縮解除は、データが使用者に提供される前に端末Ｔ１で行なわれる。）
【０００７】
また、データサーバー１０が使用者に与えるインターフェースは、通信パス１１−１を介して到来する呼の受信を確認するように動作する。本発明の実施例では、通信パス１１−１は、例えば、２３のＢチャンネルと１つのＤチャンネルからなるＩＳＤＮ一次群速度インターフェース（ＰＲＩ）通信パスとすることができる。周知のように、各Ｂチャンネルは電話呼（音声またはデータ）を転送するために用いられ、Ｄチャンネルは、Ｂチャンネルを介して転送される呼に関する信号情報を運ぶために用いられる。また、通信パス１１−２、１１−３及び１５２もＩＳＤＮＰＲＩとすることができる。
詳細には、使用者がマルチメディアシステム１００に呼をかけると、電話通信網２００は従来通りにその呼を処理し、通信パス１１−１を介してデータサーバー１０まで伸びているＩＳＤＮＤ信号チャンネルを経由して到来する呼に対してシステム１００を待機させる。前記待機は、呼を運ぶＩＳＤＮＢチャンネルの身元（番号）のデータサーバー１０への通知を含む。次に、データサーバー１０は、前記信号に応じて、信号チャンネルを介して網２００に呼受付メッセージを送り、それにより、システム１００と使用者間の通信接続を確立する。その時点で、使用者及びシステム１００は、下記に述べるように、互いにメッセージを交換し始めることができる。
【０００８】
アプリケーション制御装置２０は、より詳細には、システム１００（制御装置２０）が使用者の端末例えば端末Ｔ１に送る全てのマルチメディアアプリケーションを実行する責任がある。すなわち、制御装置２０は、例えばＡＴ＆Ｔから入手できる３８６−ＷＧＳコンピュータとすることができ、Ｕｎｉｘオペレーティングシステムの制御のもとに動作して、使用者にマルチメディアアプリケーションを提供する。ここで、アプリケーションはデータ及び／または声（音）を含むことができる。上述のように、前記データは、データベース６１に格納されている数値化された画像、文書、図形原線、アニメーション原線、実行可能なプログラム等を含むことができる。前記データ中に付属しているアナログ部分はデジタル形式でデータベース６０に格納される。アプリケーションのデータ部分については、制御装置２０は、メモリ６１からデータをおろして通信パス１１−１を介して使用者に提供するように、ＬＡＮ４５を介してデータサーバー１０に命令する。アプリケーションの音声部分については、制御装置２０は、メモリ６０から数値化された音声をおろして通信パス１１−２のＩＳＤＮチャンネルを介して使用者に提供するように、ＬＡＮ４５を介して音声サーバー１０に指示する。また、アプリケーション制御装置２０は、使用者により入力されることになるデータ（音声）ファイルの受信を待ち設けて前記ファイルをメモリ６１（６０）に格納するように、サーバー１０（３０）に指示する。アプリケーション制御装置２０は、情報を、データサーバー１０を介して使用者に運ぶためにＬＡＮ４５上にのせることにより、使用者にその情報を送る。前記情報は、要求されたアプリケーションの状態またはそれと関連するエラーに関するものでも良い。
【０００９】
音声サーバー３０は、同様に３８６−ＷＧＳとしてＵＮＩＸオペレーティングシステムのもとに動作するものとすることができ、使用者またはアプリケーション制御装置２０とメモリ６０間のインターフェースを提供する。本発明の実施例では、各アプリケーションと関連する数値化された音声及び／または使用者より与えられる数値化された音声がメモリ６０に格納される。したがって、音声サーバー３０は、各マルチメディアアプリケーションと関連する音声の格納及び“再生”の責を負う。
【００１０】
動作援助装置（ＯＳＳ）５０は、例えばＡＴ＆Ｔから入手できるＣｏｍｐｕＬｅｒｔ装置とすることができ、システム１００の総合動作状態を監視する。詳細には、データサーバー１０、アプリケーション制御装置２０及び音声サーバー３０は、それぞれ通信リンク１０−１、２０−１及び３０−１を介してＯＳＳ５０に状態メッセージを周期的に送るように手配される。前記状態メッセージ（“心拍”メッセージと呼ばれることがある）は、制御装置またはサーバーがそれぞれまだ動作中であることをＯＳＳに示す。ＯＳＳ５０は、予め決められた時間内に、例えば１分につき１回、前記メッセージを受け取ることができなかった場合は、状態メッセージを送ることができなかった制御装置またはサーバーが不良であると推定し、システム端末（図示しない）に適当なメッセージを出力してシステム１００管理者に通知する。制御装置またはサーバーは、エラーそのもの、例えば通信パス、メモリ６０か６１、またはＬＡＮ４５に起こり得る故障、を検出した場合は、リンク１０−１、２０−１または３０−１の各リンクを介してその事をＯＳＳ５０に通知する。次いで、ＯＳＳ５０は故障確認メッセージを上述のシステム端末に出力する。
【００１１】
使用者は端末Ｔ１を操作してシステム１００にアクセスすることができる。他端末Ｔ１は、例えば、ＭＳＤＯＳオペレーティングシステムの制御のもとに動作する、３８６または４８６をベースとした処理装置とすることができる。詳細には、端末Ｔ１は、システム１００と関連するマルチメディア機能のライブラリと、網２００とインターフェースできるようにするための従来の電話回路網を含む。前記回路網は、例えば、ニュージャージー州マウントローレルのＤＧＭ＆Ｓ社から入手できるモデルＩＤＣ回路基板とすることができ、図において通信パス９で表わされているＩＳＤＮ基本速度インターフェース（ＢＲＩ）インターフェースを実行する。前記機能は、とりわけ、システム１００から通信パス９のＢＲＩＢチャンネルのうちの一方または両方を介して受信されるデータの圧縮解除を含む。次いで、圧縮解除されたデータは、端末Ｔ１の表示装置１２に表示するか、またはフロッピーまたはハードディスクメモリのようなＴ１の内部メモリに格納することができる。本発明の実施例では、圧縮解除されたデータは、端末Ｔ１に格納された後で端末Ｔ１にランされ次いで実行されるべき実行可能なプログラムとすることができる。
【００１２】
図１では、端末Ｔ１は端末機Ｓ１及び任意の音声装置５と関連しているのがわかる。音声装置５は、より詳細には、使用者の音声情報を提供するように動作し、この音声情報は、通信パス９の２つのＢチャンネルのうちのいずれか一方を介してシステム１００から受信される。その代わり、使用者は、端末機Ｓ１のハンドセットに話すことによって、メモリ６０に格納するためにシステム１００に音声情報を提供することができる。次いで、端末機Ｓ１から受信された通話信号は、上述のＩＤＣ回路網に提供されて数値化され、通信パス９のＢチャンネルを介してシステム１００に送信される。また、図１から、端末Ｔ１は、従来のテレビモニタすなわち映像表示装置８と関連することもできることがわかる。このように、端末Ｔ１の表示装置１２に表示される情報はモニタ８に表示することもできる。それを行なうために、端末Ｔ１は、ＶＧＡフォーマット化信号をモニタ８への表示用のＮＴＳＣ映像信号に変換するための従来回路を含む。そのようなものとして、情報は端末表示装置１２またはモニタ８のどちらかまたは両方に表示することができる。
【００１３】
また、使用者は、音声ファイルとしてメモリ６０に格納するためにシステム１００に端末Ｔ１を介して音声を送信する手段として、音声入力装置（またはレコーダ）６を用いることができる。そのようなものとして、音声入力装置６は例えばマイクロフォンまたはオーディオテープレコーダとすることができる。マイクロフォン（またはレコーダ）６より出力される音声信号は増幅器３に提供され、増幅器３は、上記に説明した通信パス９への送信のため、前記信号を端末Ｔ１のＩＤＣ回路網に送る。
【００１４】
（使用者は同様に、下記に説明されるように、サーバー１０と関連するデータベース６１にデータを格納することができることが注目される。）
本発明の実施例では、独特のマルチメディアプロトコルを構成するマルチメディア機能のライブラリが、通信網を介する使用者へのマルチメディアアプリケーションの開発及び提供を援助するために与えられる。詳細には、このプロトコルは、本発明の態様に従って、システム１００、マルチメディアアプリケーション及び端末Ｔ１と無関係になるように取り決められる。このため、種々のマルチメディア機能をシステム１００と端末Ｔ１間に継ぎ目なく分配することができる。したがって、プロトコルは、使用者端末を含む網状マルチメディアシステムを構成する構成要素間の通信を容易にする。そして、好都合にも、前記プロトコルにしたがって開発されたマルチメディアアプリケーションは、システムが本発明のプロトコルを維持するかぎり、たいていのマルチメディアシステムにランさせることができる。
【００１５】
このプロトコルは、より詳細には、（ａ）遠隔通信機能、（ｂ）データアクセス機能、（ｃ）音声機能、及び（ｄ）分散アプリケーション機能を呼び出すためのメッセージを含む。遠隔通信機能は、端末Ｔ１とシステム１００間の通信接続を確立したり会議接続を確立したりするメッセージ群を含む。このメッセージ群は、（ａ）接続、（ｂ）切断、（ｃ）ブリッジ呼、及び（ｄ）非ブリッジ呼を含む。データアクセス機能は、（ａ）データファイルのダウンロード、（ｂ）データファイルのアップロード、（ｃ）データダウンロードの停止、（ｄ）データアップロードの停止、（ｅ）データダウンロードの再開、及び（ｆ）データアップロードの再開からなるメッセージ群を含む。音声機能は、（ａ）音声ファイルの再生、（ｂ）音声再生の中断、（ｃ）音声再生の再開、（ｄ）音声再生のスキップ、（ｅ）音量調整、（ｆ）音声再生の停止、（ｇ）録音、（ｈ）録音の中断、（ｉ）録音の再開、及び（ｊ）録音の停止を含む。分散アプリケーション機能は、（ａ）アプリケーション開始、（ｂ）アプリケーション停止、及び（ｃ）アプリケーション中断、及び（ｄ）アプリケーション再開からなるメッセージ群を含む。（音声サーバーに関連する種々の命令は付属書類Ａに示される。データサーバー命令及びアプリケーション制御装置命令のフォーマットと機能は、付属書類Ａに示されるものと同じである。）
【００１６】
本発明のプロトコルの結果として、また本発明の態様にしたがって、マルチメディアアプリケーションは論理構成要素すなわちブロックに分割することができるが、その提供は使用者の管理下にある。好都合にも、使用者より要求されるマルチメディアアプリケーションのこれらのブロックのみが使用者の端末にダウンロードされ、それにより遠隔通信網帯域の効率的な利用が行なわれる。好都合にも、前記分割は、アプリケーションの構成要素が、送信されるデータ形式に最も適する方法で格納され送信されるのを許す。例えば、音声情報を予め決められたフォーマット、例えばＡＤＰＣＭフォーマット、でデータベース６０に格納することができる。前記ＡＤＰＣＭフォーマットは、使用者への電話通信網を介する送信のための音声信号に容易に復調、変換することができるものである。
【００１７】
前記プロトコルの結果として、アプリケーションを各ブロックに区分け（分割）することができる。これが意味することは、アプリケーションは効率的かつ迅速な方法で使用者に提供されるということである。例えば、アプリケーションの特定のブロックをバックグラウンドモードで端末Ｔ１にダウンロードし、前記ブロックを、使用者が要求した時に端末表示装置１２に迅速に持ち出せるように端末Ｔ１に格納することができる。例えば、使用者選択の見込みが最も高い表示メニューアイテムを援助するアプリケーションプログラムのブロックを、バックグラウンドにまずダウンロードすることができ、使用者選択の見込みが次に高いメニューを援助するアプリケーションプログラムのブロックを次にダウンロードすることができ、以下同様である。したがって、使用者が表示メニューアイテムを選択する時、その選択を援助するアプリケーションデータ及び／またはソフトウェアが、使用者の端末に内在（格納）されているのが適当である。
【００１８】
（その代わりとして、ブロックを、選択の見込みよりむしろ各々のサイズに基づいて順次ダウンロードすることができる。なお、表示メニューアイテムを援助するアプリケーションブロックを、並列にバックグラウンドモード（すなわちプリローディング）でダウンロードすることができ、ここでは、網帯域幅は、使用者により選択される関連メニューアイテムの見込みに基づいてブロック間に割り当てられる。他の代替物として、前記帯域幅割当てはデータブロックのサイズに基づくことができる。前記ブロックがバックグラウンドにおいて順次または並列にダウンロードされる順番は、アプリケーション提供者によって明快に指定される。すなわち、帯域幅の大部分は小さい方のデータブロックより大きいデータブロックに割当てられる。反対に、帯域幅の大部分は、使用者がメニュー選択を行なう前にブロックが使用者の端末に内在しているということを確実にするために、小さい方のデータブロックに割当てることもできる。）
【００１９】
前記のことを心に留めておいて、次に、マルチメディアアプリケーションが端末機Ｓ１及び端末Ｔ１と関連する使用者に要求され提供される方法を説明する。詳細には、使用者がマルチメディア機能を呼び出すための命令を入力すると、端末Ｔ１は、使用者に割当てられた唯一のシステム１００識別子、例えば従来のログイン、を入力し、次に使用者のパスワードを入力するよう、使用者への要求を表示する。使用者がその要求に応じると、それに応じて、端末Ｔ１は、その関連電話回路網に網２００を介してシステム１００にＩＳＤＮデータ呼をかけさせる。システム１００（データサーバー１０）が前記呼を受け付けると、網２００は、通信パス９のＢチャンネルのうちの１チャンネルと通信パス１１−１の休止Ｂチャンネル間の接続を確立する。いったんＩＳＤＮ接続が確立されれば、端末Ｔ１は、使用者が入力したログイン及びパスワードを送信する。その受信に基づき、データサーバー１０は、受信したログイン及びパスワードを有効と認めた場合端末Ｔ１に受取通知を返送する。さもなければ、データサーバー１０は無効メッセージを端末Ｔ１に返送し、前記呼から切り離す。
【００２０】
受取通知に加えて、データサーバー１０は、システム１００に内在するマルチメディアアプリケーションのメニューを返送する。システム１００では、メニューは圧縮されたフォーマットになっている。また、データサーバー１０は、メニューと共に、メニューアイテムのそれぞれと関連する各マルチメディアアプリケーションがメモリ６１及び／またはメモリ６０にあることを確認する情報も送る。その受信に基づき、端末Ｔ１は、従来の圧縮解除アルゴリズムを用いてデータ（メニュー）を圧縮解除し、この圧縮解除されたメニューを端末表示装置１２に表示する。また、端末Ｔ１は圧縮解除されたアプリケーション位置情報をその内部メモリに格納する。
【００２１】
表示されるマルチメディアアプリケーションのメニューは、例えば、紀行映画、ゲーム、カタログショッピング、教育等を含む。また、このメニューには、良く知られているセサミストリート（ＣｈｉｌｄｒｅｎｓＴｅｌｅｖｉｓｉｏｎＷｏｒｋｓｈｏｐＣｏｒｐｏｒａｔｉｏｎの商標）テレビ番組に関連があるマルチメディアアプリケーションを入れることもできる。よって、以下、セサミストリートアプリケーションに関連して説明する。（しかし、以下の説明は他のマルチメディアアプリケーション、例えば上述のマルチメディアアプリケーション、に平等に関係があることがわかる。）
【００２２】
使用者が、例えばその表示されたメニューアイテムに従来のマウスカーソルを合わせて関連マウスボタンを操作することによって、セサミストリートアプリケーションを選ぶと、端末Ｔ１は、その内部メモリからそれに関する“アプリケーション位置情報”を得て、セサミストリートアプリケーション及びそれに関する位置情報を送信するための要求を含むメッセージを生成する。次いで、端末Ｔ１は、このメッセージを網２００で確立されたＩＳＤＮ接続を介してシステム１００に送信する。メッセージの受信に基づき、データサーバー１０は、メッセージから位置情報を抽出し、この情報を用いて、データベース６１における要求されたアプリケーションの第１ブロックの格納位置を確認する。次いで、データサーバー１０は、アプリケーションの第１ブロックを降ろして、その圧縮された形式のものを端末Ｔ１に送信する。ここで、第１ブロックは、（ａ）端末Ｔ１に表示されることになる仕切りと、（ｂ）実行可能なプログラムとからなる。第１ブロックの受信に基づき、端末Ｔ１は前記データを圧縮解除し、受信したプログラムを実行する。受信したプログラムは、順次、付随の仕切りを表示装置１２に表示させ、セサミストリートの番組主題歌の再生を始めるための要求を音声サーバーに送る。
【００２３】
前記仕切りは、種々の対象物、例えば、ボール、汽車、本箱、アーケードゲーム等、で満たされた部屋を示す。各対象物はメニュー選択を表わす。例えば、（ａ）ボールを選択すると、弾むボールが関連の音響効果を伴って表示され、（ｂ）汽車を選択すると、円形軌道を走る汽車が関連の音響効果を伴って表示され、（ｃ）本箱を選択すれば、物語の本機能が表示される。本発明の一態様として、システム１００は、上述のように、使用者がどのメニューアイテムを選ぶかを決める間、考慮中のアプリケーション部分をダウンロードすることができる。例えば、ボールと汽車は、使用者がメニューアイテムを選択する前にダウンロードすることができるアニメーション型アプリケーションである。
【００２４】
使用者が例えば汽車マルチメディアアプリケーション（動画プラス音）を選択すると、その選択を援助するアプリケーションブロックは既に端末Ｔ１に内在する。したがって、端末Ｔ１は、その使用者選択に迅速に応じて、汽車アニメーションと関連の音響効果の再生を表示することができる。汽車アニメーションは、より詳細には、やや円形の軌道上を動いている汽車を、汽笛を表わす音を伴って表示する。一方、使用者が本箱メニューアイテムを選択すると、端末Ｔ１はそのアプリケーションを援助するメニューを表示する。ここで、前記メニューは、プリ−ダウンローディングフィーチャの結果として既に端末Ｔ１に格納されている。本箱メニューは、表示装置１２に表示される場合、各々が各本の書名を含む種々の本の表紙を描く画像を示す。このメニューは背景音すなわちセサミストリート番組主題歌を伴う。前記本は各々、一連の絵と、物語を話す音から構成される。使用者がどのメニューアイテムを選択するか決める間、システム１００は、上記に説明したように、前記各本の第１ページを端末Ｔ１にダウンロードする。使用者が本を選択した場合は、端末Ｔ１は、予め格納されている選択された本の第１ページを表示する。さらに、端末Ｔ１は、選択された第１ページと関連する音声ファイルの名前を含むメッセージを生成し、このメッセージを通信パス９を介してシステム１００に送る。アプリケーションは、音声チャンネルを必要とする場合（これは上述の音響効果を再生する場合である）、データサーバー１０を介して音声サーバー３０にその音響効果の要求を送る。音声サーバー３０は、この要求に応じて、特定の命令を網２００に送って通信パス１１−２を確立させる。
【００２５】
前記メッセージの受信に基づき、データサーバー１０はこの要求をＬＡＮ４５を介して音声サーバー３０に送る。サーバー３０は、順次、メモリ６０から確認されるファイルを降ろし、網２００を経由して端末Ｔ１間で伸びる通信パス１１−２の関連Ｂチャンネルを介して、連続（等時）ビットストリームとして前記ファイルを送信する。端末Ｔ１は次に、受信したビットストリームをアナログ信号に変換して端末機Ｓ１または音声装置５に提供する。同様に、使用者が音声を聞きながらそのページを見ている間、システム１００は選択されたほんの次のページを端末Ｔ１にダウンロードする。端末Ｔ１及びシステム１００は、選択された本の最終ページが使用者に提供されるまで上記のように動作し続ける。その時点で、使用者は本メニューの再表示を要求して、上記に説明したように続けることができる。その代わりとして、本選択メニューが表示された時、使用者はメインメニューを選択することができる。
【００２６】
本発明の一態様として、使用者、例えば端末機Ｓ１及び端末Ｔ１と関連する使用者、は特定のマルチメディアアプリケーションを見ながら、“本物の”代理者、例えば旅行代理業者、にアクセスすることができる。例えば、使用者は、端末機Ｓ１または案末Ｔ１のどちらかに出力される音声を伴う表示装置１２上のマルチメディア紀行映画アプリケーションを見ていて、旅行代理業者との接続を望む場合、システム１００にこのような接続の要求を入力することができる。使用者は、紀行映画と共に表示されている特定のアイコンにスクリーンカーソルを合わせてそのアイコンを従来のやり方で選択することにより、この事を行なうことができる。端末Ｔ１はこれに応じてブリッジ呼メッセージ（下記に説明される）をシステム１００に送る。そのメッセージの受信に基づき、データサーバー１０はＬＡＮ４５を介して音声サーバー３０に指示して、通信パス１１−２の利用できるＩＳＤＮＢチャンネルを介する呼を、前記アプリケーションと関連する代理者（操作者）、例えば案内者すなわち操作者２２５、にかけさせる。前記呼が応答されると、音声サーバー３０は網２００に信号を出し、その呼を通信パス９を介してシステム１００に届く使用者の呼に橋渡しさせる。次いで、音声サーバー３０はブリッジ呼の接続を断ち、紀行映画アプリケーションは、代理者への呼が完了するまで一時停止される。前記呼が完了すると、音声サーバー３０は通信パス１１−２を介して端末Ｔ１に再接続する。次いで、システム１００は紀行映画の提供を継続する。
【００２７】
図１からわかるように、システム１００は、ワークステーション４０とアプリケーション開発プラットフォーム（ＡＤＰ）１５０も含み、これらは、システムと、それぞれアプリケーション供給装置１２５及び１７５のような、マルチメディアアプリケーションの開発者と関連するマルチメディアアプリケーション開発設備をインターフェースさせるために用いられる。本発明の実施例では、ワークステーション４０は、例えばゲートウェイ（Ｇａｔｅｗａｙ）社から入手できるゲートウェイ２０００コンピュータとすることができ、アプリケーション供給装置例えば供給装置１２５がシステム１００（データベース６０及び６１）に開発中のアプリケーションを格納することができるメカニズムを提供する。供給装置１２５は、ＢＲＩＩＳＤＮパス１２６を介してＩＳＤＮ呼をかけてワークステーション４０との接続を確立することにより、その通り行なうことができる。いったん接続が確立されれば、供給装置１２５はワークステーション４０とやり取りして、メモリ６０及び／または６１にアプリケーションを格納するようにワークステーション４０に指示することができる。システム１００へのアプリケーションの転送を有効にするために、供給装置１２５は、データのアップロード命令（下記に説明される）を用いて、アプリケーションを構成する各ファイルをパス１２６を介してワークステーション４０に送信する。ワークステーション４０は、ファイルの受信に応じて、受信したファイルのデータ（音またはデジタルデータ）の形式に基づいてメモリ６０または６１にそのファイルを格納する。前記ファイルの全てがシステム１００に格納されると、供給装置１２５は、パス１２６を介してアプリケーション開発プラットフォーム（ＡＤＰ）１５０に呼をかけることによって、格納されたアプリケーションを“デバッグ”することができる。
【００２８】
ＡＤＰ１５０は、同様にゲートウェイ２０００コンピュータとすることができ、呼に応答して、まるで供給装置が使用者例えば端末機Ｓ１や端末Ｔ１と関連する使用者であるかのように、供給装置の格納されるアプリケーションを供給装置に提供することに関連するシステム１００の機能をまねる（エミュレートする）ように、サーバー１０及び３０と制御装置２０を反復させる。したがって、本発明の一態様により、システム１００は、アプリケーション供給装置に、供給装置が開発中のアプリケーションをシステム１００に格納させ、そのあと遠隔通信網２００を介してそのアプリケーションを“デバッグ”する（すなわちエラーを発見して訂正する）ようにシステム１００をアクセスさせる機能を提供する。したがって、アプリケーション供給装置は、使用者が最終的にアプリケーションとインターフェースするのと実質的には同じように関連アプリケーションとインターフェースする。
【００２９】
マルチメディアアプリケーションを働かせるソフトウェアは端末Ｔ１とシステム１００間で分割することができる。図２を参照すると、端末Ｔ１に格納されて、端末Ｔ１を操作する使用者にマルチメディアシステムすなわちプラットフォーム１００にアクセスさせるメインメニュープログラムが示される。より詳細には、使用者が名メニュープログラムを呼び出すと、プログラムはブロック３００に入って、ブロック３０１に進み、使用者にログイン及びパスワードの入力を促す。使用者がそれを行なうと、プログラムはブロック３０２に進み、上述のＩＳＤＮ基板の動作を制御するソフトウェアばかりでなく該基板も初期化する。次いで、プログラムは、基本速度ＩＳＤＮチャンネルの２チャンネルのうちの一方を用いてマルチメディアプラットフォーム１００への電話呼を確立する（ブロック３０３）。電話呼が確立されると、メインメニュープログラムとシステム（プラットフォーム）１００は互いに通信する。前記通信は、プラットフォーム１００に入力されるパスワード及びログオンの通過を含む。プラットフォーム１００がログオンを無効と認めると、プラットフォーム１００はＩＳＤＮ接続を終わらせる。プログラムは、それに応じて、その事を表わすメッセージを表示し、退出する。しかし、プラットフォームは、入力されたログオンを有効と認めると、その事をプログラムに通知し（ブロック３０４）、使用者がアクセスできるマルチメディアサービスのメニューをダウンロードする。その受信に基づき、プログラム（ブロック３０５）は前記サービスを表示し、使用者が選択を入力するのを待つ（ブロック３０６）。使用者が選択を入力すると、プログラム（ブロック３０６）はその選択をプラットフォーム１００に送り、そのあと、下記に説明されるように、プラットフォーム１００から受信された時にその選択をランする（ブロック３０７）。マルチメディア選択が終わると、プログラムはサービスのメニューを表示し（ブロック３０８）、使用者が次の選択を入力するのを待ち受ける。使用者が選択を入力すると、上記に説明したように、プログラムは入力された選択をマルチメディアプラットフォームに送る。（ブロック３０６）。一方、使用者がその活動期間を終わらせることを望んで、その事を表わす識別子、例えばｑｕｉｔの“ｑ”を入力した場合は、プログラムはそれをプラットフォームに通知してＩＳＤＮ接続を終わらせる。
【００３０】
メインメニュープログラムは、バックグラウンドモードでランするように設計されている多くの他のプログラムすなわちタスクによって援助される。前記プログラムの１つは、図３に示されるようなＩＳＤＮタスクを実行する。詳細には、このタスクは、ブロック４００で入力されると、多数の機能の初期化に進む（ブロック４０１）。前記初期化は、選択されたアプリケーションに関連するデータファイルの格納のために必要な待ち行列の設定を含む。前記データファイルは、プラットフォームから使用者の端末への及びその逆のファイルのダウンローディングを含む。また、初期化は、データ圧縮及び圧縮解除タスクを呼び出すことも含む。次いで、プログラムは、アプリケーションからの要求すなわち次のデータファイルを“得る”ための要求の受信を待ち受ける。また、ＩＳＤＮタスクは、いわゆる簿記タスクの呼出し（ブロック４０８）を含む。この簿記タスクは、下記に説明されるような種々のＩＳＤＮ機能ばかりでなく、使用者の端末がプラットフォームとの通信中に実行するログオン及びログオフ機能をたどるものである。また、ＩＳＤＮタスクはデータ転送機能も呼び出す（ブロック４０５）。このデータ転送機能は、使用者の端末とプラットフォーム間でデジタルデータファイルを転送するように動作する（ブロック４０９）。同様に、ＩＳＤＮタスクは音声機能も呼び出す（ブロック４０６）。この音声機能は、選択されたアプリケーションの指令を受けて、アプリケーションプラットフォームからの数値化音声ファイルを受信してスピーカ４でこの音声を“再生”する用に動作する（ブロック４１０）。選択されたアプリケーションからの受信される要求に上記機能（ブロック４０３、４０５または４０６）がなければ、ＩＳＤＮタスクはいわゆる否定的な受取通知をアプリケーションに送り（ブロック４０７）、選択されたアプリケーションからの次の要求を待ち受ける（ブロック４０２）。
【００３１】
上述の簿記機能４０３のフローチャートは図４に示される。詳細には、簿記機能は、呼び出されると（ブロック５００）、受信された要求が上述のＩＳＤＮハードウェアを初期化するための要求かどうかを確認する（ブロック５０１）。そうであった場合は、プログラムはＩＳＤＮハードウェアを初期化する（ブロック５０６）。前記初期化を行なうための要求は、通常、アプリケーションプログラムが、使用者の端末とプラットフォーム１００間のＩＳＤＮ通信パスが不明の状態にある、例えば端末が“切られている”、と推断した時に生じる。それが違うならば、プログラム（ブロック５０２／５０３）は、要求が特定形式のＩＳＤＮ接続／切断のための要求かどうかを知るためにチェックする。接続要求については、プログラム（ブロック５０７）は、プラットフォーム１００への特定の接続を定義するパラメータを含む、いわゆる接続命令を送る。切断要求については、プログラム（ブロック５０８）は、プラットフォーム１００との切断を定義するパラメータを含む切断命令を送る。特定の機能（すなわちブロック５０６、５０７または５０８）が首尾良く実行された場合は（ブロック５０４）、プログラムは、“ＶＡＬ”と呼ばれる識別子を、要求された機能が首尾良く完了したことを表わす１にセットし（ブロック５０５）、そのあとブロック４０２に戻る。さもなければ、プログラムは、ＶＡＬを、要求された機能４０５が失敗したことを表わす０にセットする（ブロック５０９）。
【００３２】
上述のデータ機能のフローチャートは図５に示される。詳細には、データ機能は、呼び出されると（ブロック６００）、選択されたアプリケーションから受信されたデータ要求の形式を確認する。データ要求が、いわゆるプラットフォームから使用者の端末へデータをダウンロードするための要求とわかった場合（ブロック６０１）は、プログラムは、いわゆるダウンロード処理待ち行列にこの要求を加え（ブロック６０４）、そのあと図３のブロック４０２に戻る。一方、要求が、使用者の端末からプラットフォームへデータをアップロードするための要求とわかった場合（ブロック６０２）は、プログラムは、いわゆるアップロード処理待ち行列にこの要求を加え（ブロック６０５）、そのあとブロック４０２に戻る。プログラムは、要求が、ダウンロードまたはアップロード以外の何か、すなわち、処理のために既に待ち行列に並んでいる特定の要求の取消し、であるとわかった場合は、この特定の要求のために状態を更新する（ブロック６０６）。プログラムは、この特定の要求に関する取消しメッセージをプラットフォームすなわちデータまたは音声サーバーに送る（ブロック６０７）。そのあと、プログラムはブロック４０２に戻る。
【００３３】
図６は、データファイルダウンローディング機能を実行するためにバックグラウンドモードでランするタスクすなわちプログラムをフローチャート形式で示す。呼び出されると（ブロック７００）、プログラム（ブロック７０１）は、プラットフォームから使用者の端末へファイルをダウンロードするための要求を受信したかどうかを知るためにチェックする。それがその通りならば、プログラム（ブロック７０３）は、関連待ち行列にこの要求を格納し、そのあとブロック７０２に進む。次いで、プログラム（ブロック７０２）は、現在プラットフォームからデータを受信中かどうかを知るためにチェックし、そうであるとわかればブロック７０１に戻る。そうでなければ、プログラム（ブロック７０４）は、その関連待ち行列が空いているかどうかを知るためにチェックし、空いていればブロック７０１に戻る。さもなければ、プログラム（ブロック７０５）は、（ａ）プラットフォームから受信したデータファイルを読み取って圧縮解除し、（ｂ）そのあと前記ファイルに含まれている命令に従って前記ファイルを処理するためのものであるタスクを呼び出す（生成する）。そのあと、プログラムはブロック７０１に戻る。
【００３４】
図７は、データファイルアップローディング機能を実行するためにバックグラウンドモードでランするタスクすなわちプログラムをフローチャート形式で示す。図７に示されるプログラムは、図６に示されるプログラムに多少類似しているが、異なる機能を実行する。詳細には、呼び出されると（ブロック８００）、プログラム（ブロック８０１）は、使用者の端末からプラットフォームすなわちデータまたは音声サーバーへ特定のファイルを送信するための要求を受信したかどうかを知るためにチェックする。それがその通りならば、プログラム（ブロック８０３）は、関連待ち行列にこの要求を格納し、そのあとブロック８０２に進む。次いで、プログラム（ブロック８０２）は、現在プラットフォームにデータを送信中かどうかを知るためにチェックし、それがその通りとわかればブロック８０１に戻る。プログラムは、アップロードモードにないことがわかれば、その関連待ち行列が空いているかどうかを知るためにチェックし（ブロック８０４）、空いているとわかればブロック８０１に戻る。さもなければ、プログラム（ブロック８０５）は、アップロードされるべきデータファイルを圧縮し、このファイルをプラットフォームに送信する（生成する）。そのあと、プログラムはブロック７０１に戻る。
【００３５】
図８乃至図１９は、音声サーバー３０（図１）において本発明を実行するプログラムをフローチャート形式で示す。詳細には、図８を参照すると、アナログサーバーがオンにされて“役立てられる”と、プログラムはブロック９００に入り、網と音声サーバーをインターフェースするインターフェース（Ｉ／Ｆ）回路基板の初期化に進む（ブロック９０１）。また、プログラムは多数のプログラム変数も初期化して、使用者の端末に網２００を介して接続されるべき音声ＩＳＤＮ＿Ｂチャンネルを要求するデータサーバーからのメッセージの受信を待ち受ける（ブロック９０２）。このメッセージの受信に応じて、プログラム（ブロック９０３）はＢ＿チャンネル＿サーバー処理を生成し、下記に説明されるように、後者の処理を使用者の端末に接続されたＢ＿チャンネルと関連させる。次いで、プログラム（ブロック９０４）は新しく生成された処理と関連する待ち行列に受信したメッセージを格納し、そのあとブロック９０２に戻って、データサーバー１０からの次の接続メッセージの受信を待ち受ける。
【００３６】
図９は、音声サーバーに接続される特定のＩＳＤＮ＿Ｂチャンネルを使えるようにするために生成されるＢ＿チャンネル＿サーバー処理をフローチャート形式で示す。すなわち、Ｂ＿チャンネル＿サーバー処理は前記各接続に役立つように生成される。詳細には、生成された場合、Ｂ＿チャンネル＿サーバー処理（“プログラム”）はブロック１０００に入り、特定のＩＳＤＮ＿Ｂチャンネルを使えるようにするために用いる多数のプログラム変数を初期化する。次いで、プログラム（ブロック１００１）はその関連待ち行列から要求メッセージを降ろし、そのあとメッセージに含まれている要求の形式に基づいて分岐する（ブロック１００２）。前記分岐は、プログラムを、図に示される１０１６を介して１４のサブルーチンのうちの１つ１００３に分岐せしめる。プログラムは、要求メッセージが不明の形式からなる場合は最後の前記サブルーチン１０１７に分岐する。サブルーチン１０１７はエラーを記録し、そのあと、関連待ち行列に格納されている次の要求メッセージを処理すべくブロック１００１に戻る。
【００３７】
残っている１０１６を介するサブルーチン１００３について次に説明する。詳細には、ブロック１００３の拡大したものが図１０に示される。プログラム獲得ブロック１００３は、要求メッセージが音声サーバーと使用者の端末間の一次群（ＰＲＩ）速度Ｂチャンネル音声接続を確立するための要求であることを意味する。その通り行なうために、プログラム（ブロック１００３−２）はまず、データ及びアナログサーバーの両方でアクセスされる、いわゆる包括情報テーブルをチェックして、使用者に割当てることができる２Ｂチャンネルが、データサーバー１０及び／または音声サーバー３０によりデータパスとして既に割当てられているかどうかを確認する。それがその通りならば、プログラムは接続メッセージに応じることができない。さもなければ、プログラムは休止Ｂチャンネルを接続に割当て、そのあと、割当てられたチャンネルが使用中であることを示すために関連メモリテーブルを更新する。次いで、プログラム（ブロック１００３−３）は、（上述のように）ＩＳＤＮ網と音声サーバーをインターフェースするインターフェース（Ｉ／Ｆ）回路基板とのＢチャンネル接続を確立するための命令を送る。ここでは、命令は応答側電話番号と選択されたＢチャンネルのチャンネル番号とを含む。Ｉ／Ｆ回路は、次に、関連ＩＳＤＮ＿Ｄチャンネルを介して前記電話番号及びチャンネル番号を含む呼設定メッセージを送り、それにより使用者の端末に呼を効果的に掛ける。次いで、プログラム（ブロック１００３−４）は、各々の実際の使用者と、各使用者により選択されたアプリケーションに割当てることができるＩＳＤＮチャンネルの２チャンネルの状態を追跡するのに用いられる上述の包括情報テーブルを更新する。そのあと、プログラムはブロック１００１に戻る。
【００３８】
ブロック１００４の拡大したものが図１１に示され、これは、受信された要求が特定のアナログファイルを再生するための要求に関連する場合に入る（ブロック１００４−１）。入った場合、プログラム（ブロック１００４−２）は、再生サーバーが、同一の前の要求の結果として既に作動（生成）中であるかどうかを知るためにチェックする。それがその通りならば、プログラム（ブロック１００４−３）は、音声アプリケーション、例えば接続されたＢチャンネルを介する音楽ファイルの再生、のための使用者の要求に役立つように生成された再生サーバーの待ち行列に現在の要求を格納する。次に、プログラム（ブロック１００４−４）は、使用者の要求に役立つ再生サーバールーチン（再生＿サーバー）を生成し、そのあとブロック１００４−３に進む。
【００３９】
ブロック１００４−４（図１１）で生成されるプログラムは図１２に示される。詳細には、入った場合、プログラム（ブロック１００４−４１）は、ランニング時間中に用いる多数の変数及びリスト、例えば再生リスト、を初期化する。プログラム（ブロック１００４−４２）は、次に、使用者に対して“再生される”準備を整えているファイルの１つ以上の再生要求を含むかどうかを知るためにその待ち行列をチェックする待ち行列が空いていれば、プログラムは退出する。（すなわち、プログラムは、関連待ち行列にエントリが入っている限りランし続ける。）さもなければ、プログラム（ブロック１００４−４３）は、ファイルを“再生”できることを表わすインジケータと関連するファイル、例えば数値化された音楽または物語を含むファイル、のリストを作成する。より詳細には、“ファイルの再生”は、プログラムが、ファイルを構成する数値化データをその関連音声メモリ６０から降ろしてＩ／Ｆ基板に供給することを意味する。Ｉ／Ｆ基板は、次に、数値化データをアナログ形式に変換して、割当てられたアナログＢチャンネルを介して使用者に送信する。インジケータが意味するものは、ファイルの再生、中断、スキップ、または再開（それぞれブロック１００５、１００７及び１００６）のための要求である。ファイルを確認する要求であって、ファイルの再生を中断するための、待ち行列に並んでいる他の要求（インジケータ）と関連する要求は、待ち行列から除去されず、ファイルの再生を再開するための要求が受信されて関連待ち行列に格納されるまで前記待ち行列内に留まる。ファイルの再生の停止（ブロック１００７）のための要求、またはファイル内容の“再生”の終了は、プログラムに、前記再生を停止させ、そのファイルを確認する関連要求を退けさせる。
【００４０】
プログラムが、このようなリストの作成が終わると、プログラム（ブロック１００４−４５）は、上述のように、リスト中の各ファイルを再生せしめる、すなわち使用者に送信せしめる、再生＿リスト処理に入る（図１３のブロック４５１）。実際のファイル再生は、ブロック４５４で生成される、ファイル＿プレーヤ処理で行なわれる。しかし、ファイル＿プレーヤ処理が既に能動状態にあれば（ブロック４５２）、プログラムは前記要求をファイルプレーヤの待ち行列に加える。図１２に戻ると、再生リストが空いていれば（ブロック１００４−４４）、プログラム（ブロック１００４−４６）は、新しいエントリ（すなわち再開または再生要求）が関連要求待ち行列に格納されるまで待機する。前記通知の受信に基づき、プログラムはブロック１００４−４２に戻る。
【００４１】
ブロック４５４で生成されるファイル＿プレーヤ処理は図１４に示され、ブロック４５４−１から入る。詳細には、プログラム（ブロック４５４−１）は、種々のソフトウェア変数を初期化し、次いで、その関連待ち行列が空いているかどうかを確認する（ブロック４５４−２）。もしその通りならば、プログラムは退出する。さもなければ、プログラムは、使用者がある番号ファイルの再生（すなわち再生モード）を要求したことを書き留めるために使用者の情報テーブルを更新する。次いで、プログラムは、上記に説明した方法で、すなわちファイル内容を降ろしてＩ／Ｆ基板に送ることによって、そのファイルを“再生”する。前記降ろし作業中、プログラムは、ファイル終了（ＥＯＦ）インジケータに行き当たったかどうかまたはファイルの再生停止ための使用者要求を受信したかどうかを調べるために追求する。プログラム（ブロック４５４−５）が、ファイルの再生を停止するための使用者要求（ＲＱＳＴ）に行き当たった場合、プログラム（ブロック４５４−６）は、ファイルの送信を終わらせるための命令をＩ／Ｆ基板に送り、その結果、そのファイルの再生が終了する。さもなければ、プログラムはブロック４５４−２に戻る。
【００４２】
上記に説明したように、マルチメディアプラットフォーム１００の多才さは、使用者が音楽のようなアナログファイルをディスクファイル６０に格納するのを許すオプションを備えたアプリケーション開発装置を提供する。そのために、使用者は、ディスクに音声ファイルを格納するための要求を入力することによって前記オプションを呼び出すことができ、ここでは、この要求はデータ及び音声サーバーを介してＢチャンネルサーバーに運ばれる。（使用者により創作されたファイルをディスクメモリ６０に格納するというアイデアは、ここではファイルの“記録”と呼ばれる。）前記要求の受信に応じて、図９のＢチャンネルサーバーは、ブロック１００９に分岐して要求を処理する。ブロック１００９の拡大したものは図１５に示される。入った場合（ブロック１００９−１）、記録＿要求ルーチンは、記録サーバーが使用者の要求を処理するために既に生成されているかどうかを知るためにチェックする（ブロック１００９−２）。それがその通りならば、プログラム（ブロック１００９−３）は、使用者の要求を記録＿サーバー処理と関連する待ち行列に格納する。また、プログラムは、待ち行列に、使用者の記録を格納するために用いられるファイルの身元（位置）も格納する。そのあと、プログラムはブロック１００１に戻る。サーバーがそのように生成されていなければ、プログラム（ブロック１００９−４）は、前記要求を処理するためのサーバーの複製を生成し、そのあとブロック１００９−３に進む。
【００４３】
図１６は、図１５のブロック１００９−４で生成される記録＿サーバー処理をフローチャート形式で示す。この記録＿サーバー処理は、使用者が将来使用するために、例えば音楽の特性を表わすアナログデータをディスク６０に格納するためのものである。詳細には、入った場合（ブロック１００９−４１）、プログラムは、多数の変数及びその現在のエントリ中に用いるリスト、例えば記録リスト、を初期化する。次いで、プログラム（ブロック１００９−４２、１００９−４３、１００９−４４及び１００９−４５）は、使用者のためにメモリに格納される準備ができているファイルの１つ以上の記録要求を含むかどうかを知るために、待ち行列をチェックする。待ち行列が空いていれば、プログラムは退出する。（すなわち、プログラムは、エントリがその関連待ち行列に含まれている限りランし続ける。）さもなければ、プログラム（ブロック１００９−４３）は、インジケータと関連するファイルであって、プログラムがメモリ６０への格納のためにＩ／Ｆ基板を介して受信するのを期待するファイルのリストを作成する。より詳細には、“ファイルの記録”とは、プログラムが、使用者に接続されたＢチャンネルと関連するＩ／Ｆ基板からファイルを構成するデータを受信して、使用者のためにメモリ６０に格納することを意味する。Ｉ／Ｆ基板は、関連Ｂチャンネルを介するアナログデータの受信に基づき、該アナログデータをデジタル形式に変換する。次いで、記録＿サーバー（すなわち下記に説明される記録＿リスト処理）は、上記に説明されるように、数値化データを格納する。インジケータが意味するものは、（ａ）ファイルの“記録”、（ｂ）ファイルの記録の“中断”（ブロック１０１０）、（ｃ）ファイルの記録の“再開”（ブロック１０１１）、及び（ｄ）ファイルの記録の“停止”（ブロック１０１２）のための要求である。ファイルを確認する要求であって、ファイルの記録を中断するための、待ち行列に並んでいる要求（インジケータ）と関連する要求は、待ち行列から除去されず、前記記録を再開するための要求が受信されて関連待ち行列に格納されるまで前記待ち行列内に留まる。ファイルの記録の停止のための要求は、またはファイルを構成するデータの最後の受信に基づき、プログラムに前記記録を停止させる。プログラムの一態様（ブロック１００９−４６）は、図１７に示される記録＿リスト処理に入いることである。
【００４４】
記録＿リスト処理の構成は、図１３に示される再生＿リスト処理の構成に類似しているのがわかる。そのようなものとして、記録＿リスト処理の動作は、図１３及び図１７の両方を参照することによって容易に理解することができるので、図１７についてはここでは説明しない。しかし、記録＿リスト処理は、（ａ）ファイル＿レコーダ処理を、まだ能動状態になっておらず使用者に役立つ場合に生成し、（ｂ）該ファイル＿レコーダ処理の待ち行列に前記記録リストを加え、そのあとブロック１００９−４２に戻る、と言うにとどめておく。
図１８は、記録＿リスト処理で生成されるファイル＿レコーダ処理をフローチャート形式で示す。図１８から、ファイル＿レコーダ処理の構成はファイル＿プレーヤ処理の構成に多少類似しているのがわかる。したがって、ファイル＿レコーダ処理を構成する多数のブロックで実行される機能は、その類似性とファイル＿プレーヤ処理の前記説明との結果として容易に確かめることができるので、図１８についてはここでは説明しない。
【００４５】
使用者が前記ファイルを聞いていて、再生音量が高すぎるかまたは低過ぎる場合には、使用者は音量調整のための要求を入力することができる。この要求の受信に応じて、図９のブロック１０１３のＢ＿チャンネルプログラムは、使用者に接続されたＢチャンネルと関連するＩ／Ｆ基板に命令して、そのチャンネルを介して使用者に送信中の情報、例えば音楽、の音量を増減する。
いくつかのアプリケーション例えば紀行映画アプリケーションでは、使用者は、アプリケーションと関連する本物の操作者または代理者との交信を求めることができる。例えば、紀行映画に関連するマルチメディアアプリケーションを見ていて、使用者は、旅行代理業者と交信して、アプリケーションにおいて見渡される観光“場所”についてさらなる詳細を得たいと思うかもしれない。その通りならば、アプリケーションは、使用者に、アプリケーションと関連する旅行代理業者と交信するための要求を入力させるのが適当である。したがって、このような要求に応じて、プログラムは、会議機能を実行するためのものである図９のブロック１０１４に分岐する。ブロック１０１４の拡大したものは図１９に示される。図１９に示されるサブルーチンすなわちプログラムは、図１０に示されるサブルーチンに多少類似しているのがわかる。しかし、ブリッジ＿呼プログラムは多少異なる動作を行なう。詳細には、このプログラムは、入った場合（ブロック１０１４−１）、休止Ｂチャンネルを入手し（１０１４−２）、チャンネル割当て表において話中として該チャンネルに符号をつける。次いで、プログラムは、インターフェース基板に命令を送って、要求メッセージに含まれる電話番号とのＢチャンネルを介する電話呼を確立する。このメッセージは、この場合にはデータサーバーによって起こされたものである。また、プログラムは、前記命令に、使用者に割当てられたアナログＢチャンネルで新たに確立される呼と会議する（ブリッジする）ための要求も含む。次いで、プログラム（ブロック１０１４−４）は、アプリケーションの状態を追求してＢチャンネルの割当てを記録する包括使用者情報テーブルを更新する。そのあと、プログラムはブロック１００１に戻る。
【００４６】
この時点で、Ｉ／Ｆ基板が第三者（例えば旅行代理業者）との接続を確立すれば、使用者と第三者は互いに交信することができることがわかる。使用者と第三者の会話が終わった時、使用者は第三者との接続を終わらせる（ブリッジをやめる）ための要求を入力することができる。このような要求は、使用者により入力されるほとんどの要求と同様に、使用者の端末とデータサーバー間のＩＳＤＮ接続によりＢチャンネルサーバーに運ばれる。このような要求の受信に基づき、Ｂ＿チャンネル＿サーバープログラムは、ブロック１０１５で表わされる非ブリッジ呼ルーチンに分岐する。ブロック１０１５の拡大したものは図２０に示される。より詳細には、非ブリッジ呼ルーチンは、入った場合（ブロック１０１５−１）、第三者との呼を確立するために用いられたＩＳＤＮＢチャンネルの身元を使用者の情報テーブルから得る。次いで、プログラム（ブロック１０１５−２）は、Ｂチャンネル接続を終わらせるための命令をＩ／Ｆ基板に送る。ここで、この命令はＢチャンネルを確認するためのものである。次いで、プログラム（ブロック１０１５−３）は、（ａ）Ｂチャンネルが休止して使用者情報テーブルを更新すること、（ｂ）第三者との接続は切断されたこと、及び（ｃ）使用者に割当てられたＢチャンネルはブリッジされていないことを示すためにチャンネル割当てテーブルを更新する。そのあと、プログラムは図９のブロック１００１に戻る。
【００４７】
使用者と関連するアナログＢチャンネルがもはや必要がなくなった場合は、プログラムは図９のブロック１０１６に分岐する。ブロック１０１６の拡大したものは図２１に示される。入った場合（図２１のブロック１０１６−１）、プログラムは、関連Ｂチャンネルを切断するための切断命令をＩ／Ｆ基板に送る（ブロック１０１６−２）。ここで、この命令は関連Ｂチャンネルを確認するためのものである。次いで、Ｉ／Ｆ基板は、切断命令中の情報を用いて信号メッセージを生成し、関連信号（Ｄ）チャンネルを介して送る。次いで、プログラム（ブロック１０１６−３）は、Ｃチャンネルが休止し、それに応じて使用者情報テーブルを更新することしを示すために割当てテーブルを更新する。そのあと、プログラムはブロック１００１に戻る。
【００４８】
データサーバーを働かせるプログラムは、下記に見られるように、音声サーバーを働かせるプログラムに多少類似している。詳細には、データサーバーに電力が印加されて“使えるようになる”と、図２２に示される処理を生じさせて、マルチメディアプラットフォーム（図１）に役立つＢチャンネルの各チャンネルと関連させるために、簡単なプログラム（図示しない）が入力される。図２２のプログラムは、より詳細には、まずＢチャンネル管理者ルーチンを入力する（ブロック２００１）簡単なループ配置である。Ｂチャンネル管理者ルーチンがそのタスクを終了すると、プログラムはＢチャンネルサーバールーチンに入る（ブロック２００２）。ブロック２００１の拡大したものは図２３に示される。詳細には、入った場合（ブロック２００３）、プログラムは関連Ｂチャンネルからのメッセージの受信を待ち受ける。関連Ｂチャンネルに接続されたＩ／Ｆ基板からのメッセージの受信により、プログラムは、受信したメッセージの形式に基づいて、多数の異なるルーチンのうちの１つに分岐する。メッセージ形式が不明の場合は、プログラムはブロック２００４に分岐し、ここで、プラットフォーム管理者による処理のために受信メッセージを格納するＯＳシステム５０にエラーを送る。次いで、プログラムはブロック２００３に戻り、関連Ｂチャンネルを介する新たなメッセージの受信を待ち受ける。
【００４９】
受信メッセージが到来呼に関するものならば、プログラムは接続ルーチンに分岐する（ブロック２００５）。ブロック２００５の拡大したものは図２４に示される。入った場合（ブロック２００５−１）、接続ルーチンは、関連ＢチャンネルとインターフェースするＩ／Ｆ基板に、Ｂチャンネルとインターフェース基板間の接続を確立する方法としてＤチャンネルを介して応答監視信号メッセージを送るためのメッセージを送る。次いで、このルーチンは、発呼者（例えば図１の端末Ｔ１）が既に他のＢチャンネルに接続されているかどうかを知るためにチェックする（ブロック２００５−３）。（すなわち、受信メッセージは第２のＢチャンネルのための要求である。）それが違っていれば、ルーチン（プログラム）（ブロック２００５−４）は、新たな接続に役立つＢ＿チャンネルサーバーを生成し、次に、上記に説明したように、チャンネルが話中であることを示すためにＢ＿チャンネル割当てテーブルを更新する（ブロック２００５−５）。そのあと、ルーチンは図２３のブロック２００３に戻る。発呼者が既に接続されていれば、ルーチン（ブロック２００５−６）は、いわゆるチャンネルメッセージを、該メッセージがブロック２００３で受信されたＢチャンネルと関連するＢチャンネルサーバーの待ち行列に加える。
【００５０】
到来メッセージが切断要求の場合は、図２３のブロック２００３のプログラムは代わりにブロック２００６に進み、ここで、Ｂチャンネルが休止していることを示すためにＢチャンネル割当てテーブルを更新する。しかし、到来メッセージが発呼を掛けることに向けられていれば、Ｂ＿チャンネル管理者はブロック２００７に進む。ブロック２００７の拡大したものは図３１に示される。詳細には、入った場合、プログラムはブロック２００７−１からブロック２００７−２に進み、ここで、休止Ｂチャンネルを、受信メッセージ中に確認される発呼に割当てる。次いで、プログラムは、メッセージに含まれる電話番号をダイヤルするようにＩ／Ｆ基板に指示し、次に、Ｉ／Ｆ基板より返送される、発呼を掛けることに関する状態情報を処理する（ブロック２００７−４）。その時点で、プログラムはブロック２００３に戻る。
【００５１】
図２５に示されるＢ＿チャンネルサーバープログラムがブロック２００５−４で生成されると、関連Ｂチャンネルを介してその後受信される全メッセージは、Ｂ＿チャンネル管理者プログラムよりむしろ生成されたＢ＿チャンネルサーバーに送られることが注目される。詳細には、そのように生成されると（図２４のブロック２００５−４）、図２５のプログラムはブロック２４００に入り、ここで、関連Ｂチャンネルを介するメッセージの受信を待ち受ける。メッセージの受信により、プログラムは、受信したメッセージの形式に基づいて多数の異なるルーチン（ブロック２４０１乃至２４０４）のうちの１つに分岐する。メッセージが既知の形式のものでなければ、プログラム（ブロック２４０４）はこのイベントをエラーとして符号をつけ、このエラーをＯＳシステムに送る。そのあと、プログラムはブロック２４００に戻り、次のメッセージの受信を待ち受ける。メッセージ形式がアプリケーション制御装置プログラム（下記に説明される）に関するものならば、プログラム（ブロック２４０１）は、前記メッセージをこのプログラムの待ち行列に格納する。同様に、メッセージ形式が音声サーバープログラムと関連する機能に関するものならば、プログラム（ブロック２４０２）は、前記メッセージをこのプログラムの待ち行列に格納する。メッセージ形式がデータサーバー機能に関するものならば、プログラム（ブロック２４０３）は、前記メッセージをいわゆるデータサーバー命令処理装置の待ち行列に格納する。図２５は、ブロック２４０１乃至２４０４の各々がそれぞれのタスクを終了した後ブロック２４００に戻ることを示している。
【００５２】
データ＿サーバー＿命令プログラム（データ＿サーバー＿ｃｍｄ）（ブロック２４０３）は図２６にフローチャート形式で示される。詳細には、ブロック２５００でそのように入った場合、プログラムは多数の局部変数を初期化する。次いで、プログラムは、メッセージがその中に格納されているかどうかを知るためにその関連待ち行列をチェックする。格納されていなければ、プログラムは退出し、そのあと、予め決められた時間、例えば２５ミリ秒、が経過した後再度入る。待ち行列にメッセージが入っていれば、プログラムは、上記に説明したＢ＿処理と同様に、それぞれブロック２５０１乃至２５１４で表わされる多数の異なるルーチンのうちの１つに前記メッセージの形式に基づいて分岐する。まずブロック２５１４を、次にブロック２５０１乃至２５１３の各々を調べると、プログラムは、メッセージ形式が不明なイベントについてはブロック２５１４に分岐する。ブロック２５１４では、プログラムはエラーをＯＳシステム５０に送り、そのあとブロック２４００に戻る。
【００５３】
メッセージが、第２のＢチャンネルがデータ送信のために使用者に割当てられていることを示す場合は、プログラムはブロック２５０１に分岐し、ここで、そのトランザクションを追求するために使用者の関連情報テーブルを更新し、そのあとブロック２４００に戻る。メッセージが接続要求に関するものならば、プログラムは接続を確立するためのブロック２５０２に分岐する。詳細には、プログラムは、まず、音声接続を要求しているかどうかを確認するためにメッセージをチェックし、その通りならばメッセージをアナログサーバーに送る。その通りでなければ、プログラムは、上述の包括情報テーブルをチェックして、２Ｂチャンネルが既に使用者に割当てられているかどうかを確認する。その通りならば、プログラムは、両チャンネルがデータチャンネルとして割当てられているかどうかを知るためにチェックする。その通りならば、プログラムは接続メッセージに応じることができず、ブロック２４００に戻る。さもなければ、プログラムは、上記に説明した方法で休止Ｂチャンネルを使用者に割当てるか、または既に使用者に割当てられているＢチャンネルの状態を変更し、次いで、この場合はあるかもしれない、割当てチャンネルがデータチャンネルとして使用中であることを示すために、包括情報チャンネル割当てテーブルを更新する。そのあと、プログラムはブロック２４００に戻る。
【００５４】
使用者が端末Ｔ１でランしているアプリケーションが、音声またはデータモードのいずれかに使用中のＢチャンネルをもはや必要としない場合は、メッセージは前記チャンネルを切断するための要求になり、それにより、プログラムをブロック２５０３に進ませる。ブロック２５０３では、プログラムは、メッセージが、音声用に用いられていたＢチャンネルを切断するための要求かどうかを知るためにチェックする。その通りならば、プログラムは前記メッセージを音声サーバーに送り、そのあとブロック２４００に戻る。さもなければ、プログラムは、音声サーバーに関する上記に説明したように、休止モードにつかせることによって前記チャンネルを切断する。次いで、プログラムは上述の種々のテーブルを更新し、そのあとブロック２４００に戻る。
【００５５】
メッセージが、特定のデータファイルを使用者の端末にダウンロードするためのアプリケーションプログラムからの要求である場合は、プログラムはブロック２５０４に進む。ブロック２５０４では、プログラムは、“ダウンロード”処理が、現在、使用者により選択されたアプリケーションのランニングと関連しているかどうかを確認する。もしそうなら、プログラムはそのダウンロード処理の待ち行列に前記要求を加え、そのあとブロック２４００に戻る。さもなければ、プログラムはダウンロード処理を生成して、受信メッセージで確認されるデータファイルをダウンロードする。次いで、プログラムは、新たに生成されたダウンロード処理の待ち行列に受信メッセージを格納し、そのあとブロック２４００ニモドル。ダウンロード処理のフローチャートは図２７に示される。詳細には、入った場合（ブロック２６００）、プログラムは、使用する種々の変数を初期化し、次に、その要求待ち行列が空いているかどうかを確認する（ブロック２６０１）。もし空いていれば、プログラムは退出する。さもなければ、プログラム（ブロック２６０２）は、使用者の端末にダウンローディングされるファイル名のリスト（ＩＮＰＲＯＧ＿ＬＩＳＴ）を作成する。それを行なう際、プログラムは、下記に説明されるように、マルチメディアプラットフォームと使用者の端末間に接続される２Ｂチャンネル（または１Ｂチャンネル）の現形態を考慮する。次いで、プログラム（ブロック２６０３）は、ＩＮＰＲＯＧ＿ＬＩＳＴが空いているかどうかを知るためにチェックする。リストが空いていなければ、プログラムはサブルーチンＸＭＩＴ＿ＬＩＳＴに入り、ＩＮＰＲＯＧ＿ＬＩＳＴで確認された各ファイルを送信する。プログラムは、ＩＮＰＲＯＧ＿ＬＩＳＴが空いていることがわかれば、同様に、新たな要求が待ち行列に格納されているＢチャンネルサーバーからの通知を待ち受け（ブロック２６０５）、前記通知の受信によりブロック２６０１に戻る。
【００５６】
ＸＭＩＴ＿ＬＩＳＴサブルーチンすなわちプログラムは図２８に示される。詳細には、入った場合（ブロック２６０４−１）、プログラムは、ＩＮＰＲＯＧ＿ＬＩＳＴからファイル名を除去し、ディスクメモリからファイルを構成するデータを降ろし始める。それを行なう際、プログラムは、降ろしたデータを、関連Ｂチャンネルに役立つＩ／Ｆ基板と関連する関連送信バッファ（ｘｍｉｔ＿バッファ）に格納する。すなわち、もし２Ｂチャンネルが使用中ならば、データは、これらの２チャンネルに用いられるＩ／Ｆ基板送信バッファに格納される。この方法では、送信帯域幅が２倍になり、そのためデータファイルの送信速度が早まる。Ｂチャンネルの１チャンネルだけがデータ用に用いられている場合は、降ろされたファイルは、そのチャンネルに用いられるＩ／Ｆ基板送信バッファに格納される。また、ファイル番号がダウンロードされることになった場合は、２チャンネルまたは１チャンネルの帯域幅がファイルのダウンローディングに割当てられる。例えば、２つのファイルがダウンロードされることになって、２Ｂチャンネルが使用中の場合である。それなら、一方のファイルを一方のチャンネルに、他方のファイルを他方のチャンネルに割当てることができる。他の例として、１つのファイルを１．５チャンネルに割当てることができる。これが意味することは、前記ファイルの一部が一方のチャンネルを介して送信され、前記ファイルの他の部分ともう１つのファイルが他方のチャンネルを介して多重化されることである。他の例として、一方のＢチャンネルだけが利用可能な場合は、該チャンネルの帯域幅の３／４を一方のファイルの専用とし、残りの帯域幅を他方のファイルの専用とすることもできる。Ｂチャンネル帯域幅の前記分割は、前記プログラムで計算され、ＩＮＰＲＯＧ＿ＬＩＳＴに記録される。
【００５７】
続いて、前記の降ろし作業中、プログラム（ブロック２６０４−３）がファイル終了（ＥＯＦ）を表わすデータに行き当たると、ファイルを閉じ、ＩＮＰＲＯＧ＿ＬＩＳＴ及び要求待ち行列から前記ファイルの身元を削除する（２６０４−７）。次いで、プログラム（ブロック２６０４−４）は、Ｉ／Ｆ基板に、ｘｍｉｔ＿バッファの内容を送信するよう基板に指示する命令を送る。次いで、プログラム（ブロック２６０４−５）は、新たな要求がその関連要求待ち行列に格納されていることを表わす通知メッセージを受信したかどうかを知るためにチェックする。もしそうならば、プログラムは図２７のブロック２６０１に戻る。さもなければ、プログラム（ブロック２６０４−６）は、ＩＮＰＲＯＧ＿ＬＩＳＴが空いているかどうかを知るためにチェックし、その通りならばブロック２６０１に戻る。さもなければ、ブロック２６０４−２に戻る。
プログラム（図２６）は、ブロック２５０５、２５０６または２５０７に進む場合は、それぞれ、特定ファイルのダウンローディングを取消し、中断または再開するようにダウンロード処理（図２７）に命令する。受信メッセージが、使用者の端末からマルチメディアプラットフォームへのデータファイルのダウンローディングに関するものならば、プログラムはブロック２５０８に進み、ここで、マルチメディアプラットフォームすなわちディスクメモリに格納するために、使用者の端末からのデータファイルを受信するように設定する。すなわち、プログラムは、降ろし処理に入り、降ろし処理の待ち行列に受信メッセージを格納する。
【００５８】
ブロック２５０８から入る処理は図２９に示される。降ろし処理はダウンロード処理（図２７）に多少類似していることがわかる。したがって、図２９については簡単に説明する。同様に、プログラムは、入った場合（ブロック２８００）、使用している種々の変数を初期化し、次いで、関連要求待ち行列が空いていれば退出する。さもなければ、プログラムは、その関連待ち行列に含まれかつ関連Ｂチャンネルの形態に基づいたメッセージ（使用者から受信されるファイル名）のリスト（ＩＮＰＲＯＧ＿ＬＩＳＴ）を作成する（ブロック２８０２）。次いで、プログラム（ブロック２８０３）はそのＩＮＰＲＯＧ＿ＬＩＳＴをチェックし、リストが空いている場合の通知メッセージの受信を待ち受ける（ブロック２８０５）。さもなければ、プログラムは、使用者の端末より送信されるファイルを受信するための処理（ＲＣＶ＿ＬＩＳＴ）に入る。
【００５９】
ＲＣＶ＿ＬＩＳＴ処理は、図３０にフローチャート形式で示される。Ｉ／Ｆ基板は、関連Ｂチャンネルからファイルを受信し、該ファイルを受信したとたんに関連受信バッファ（ＲＣＶ＿ＢＵＦ）に格納する設備である。バッファがいっぱいになると、Ｉ／Ｆ基板はＲＣＶ＿ＬＩＳＴ処理を通知する。ＲＣＶ＿ＬＩＳＴ処理すなわちプログラム（ブロック２９０１）はそれに応じてバッファを空にする。次いで、プログラム（ブロック２９０２）は、バッファメモリから降ろされたデータをディスクメモリ６１に格納する。前記データは１つ以上のファイルと関連させることができ、ここでは、チャンネル形態は、１つ以上のファイルが降ろされている場合に、チャンネル帯域幅はファイル間でどのように分割されたかを表わすことが注目される。前記降ろし及び格納作業中に、プログラムがＥＯＦに行き当たった場合は（ブロック２９０３）、ファイルを閉じてその関連待ち行列及びＩＮＰＲＯＧ＿ＬＩＳＴからファイル名を削除する（ブロック２９０６）。そのあと、プログラムはブロック２８０１に戻る。さもなければ、プログラム（ブロック２９０４）は、新たな降ろし要求メッセージがその待ち行列に格納されているかどうかを知るためにチェックし、その通りならば、図示のように２８０１に戻る。それが違っていれば、プログラム（ブロック２９０５）は、ＩＮＰＲＯＧ＿ＬＩＳＴが空いていないことがわかった場合にブロック２９０１に戻る。さもなければ、プログラムはブロック２８０１に戻る。
【００６０】
図２６において、プログラムがブロック２５０９、２５１０または２５１１に進む場合は、それぞれ、特定ファイルのアップローディングを中断、再開または取消しするようにアップロード処理（図２９）に命令する。
図２６のブロック２５１２は、データサーバープログラムとアプリケーションプログラム間のインターフェースを提供する。すなわち、ブロック２５１２は、それにより、プログラムが、アプリケーションプログラムから受信される要求に応じて、特定のダウンロードまたはアップロードが終了する度にアプリケーションプログラムに通知する手段となる。詳細には、ブロック２５１２におけるプログラムは、アプリケーションプログラムから受信される要求に含まれるファイル名のためのダウンロード及びアップロード処理と関連する要求待ち行列をサーチする。プログラムが、どちらの待ち行列にも関連ファイル名を見い出した場合は、データ転送が終了していなかった（または転送が停止された）ことを表わすためにアプリケーションプログラムに第１のフラグ、例えば間違った値、を戻す。さもなければ、プログラムはアプリケーションプログラムに第２のフラグ、例えば正しい値、を戻す。
【００６１】
図２６のデータサーバープログラムは、メッセージの形式が、使用者と関連していた２Ｂチャンネルを再構成するための要求である場合には、ブロック２５１３に進む。すなわち、この要求は、典型的には、２Ｂ＿チャンネルを再構成する、例えばＢ＿チャンネルのうちの１チャンネルを落とす、ためのアプリケーションプログラムからのものである。詳細には、ブロック２５１３におけるプログラムは、再構成要求に従うために使用者情報テーブル及びチャンネル割当てテーブルを更新する。次いで、プログラムは、チャンネル再構成が生じたことをダウンロード及びアップロード処理に通知し、前記更新の間、ダウンロード及びアップロード処理のランニングを停止させる。
【００６２】
使用者選択に応答するアプリケーションのエントリは、アプリケーション制御装置に備わっているアプリケーション制御装置プログラムの制御を受ける。より詳細には、アプリケーション制御装置が使用可能にされると、アプリケーション制御装置プログラム（ＡＰＰ＿ＣＴＬＲ）図３２がブロック３００から入り、ここで、特定のアプリケーション、すなわち既に入っているアプリケーションの停止、中断または再開、の使用者の選択を確認する要求メッセージの受信を待ち受ける。より詳細には、要求の受信により、プログラム（ブロック３００１）は、受信されるメッセージの形式に基づいて多数の異なるサブルーチン（ブロック３００２乃至３００６）のうちの１つに分岐する）。メッセージ形式が不明の場合は、プログラムはそのメッセージをエラーとみなし、処理のためＯＳシステム５０に送る（ブロック３００６）。そのあと、プログラムはブロック３０００に戻り、次のアプリケーション関連要求の受信を待ち受ける。
【００６３】
要求が特定のアプリケーションの開始のためのものであれば、プログラムはブロック３００２に進み、ここで、そのアプリケーションを呼び出す。さらに、プログラムは、呼び出されたアプリケーションプログラムに、使用者と関連するＢチャンネルの構成を送る。次いで、制御装置プログラムは、選択されたアプリケーションを確認するために使用者情報テーブルを更新する。そのあと、プログラムはブロック３０００に戻る。要求が、呼び出されたアプリケーションプログラムの停止に向けられたものならば、制御装置は、その効果のためのメッセージをアプリケーションプログラムに送り、それに応じて使用者情報テーブルを更新する（ブロック３００３）。同様に、制御装置プログラムは、中断（再開）のための要求に応じて、その効果のためのメッセージを前記アプリケーションに送る（ブロック３００４または３００５）。次に、アプリケーションは、（ブロック３００３、３００４または３００５を介して送られた）前記要求の受信に応じて、要求された動作を行なう。
下記は、音声ファイルを再生するために音声サーバーに命令する（要求する）ものである。
ｉｎｔｐｌａｙ＿ａｕｄｉｏ＿ｆｉｌｅ（ｉｎｔｈａｎｄｌｅ，ｃｈａｒ ^＊ａｐ，ｃｈａ ^＊ｔｕｎｅ）
ｈａｎｄｌｅは、下記にさらに説明されるように、接続が確立された時に接続機能により返送される値、ａｐは、アプリケーション名を指定するストリングの指針、ｔｕｎｅは、音声ファイル名を指定するストリングの指針である。以上は前に確立されたＢチャンネル音声接続に関するものである。
下記は、現時点で音声ファイルの再生を中断するために音声サーバーに命令するものである。
ｉｎｔｐａｕｓｅ＿ａｕｄｉｏ＿ｐｌａｙｂａｃｋ（ｉｎｔｈａｎｄｌｅ）
下記は、中断された音声ファイルの再生を再開するために音声サーバーに命令するものである。
ｉｎｔｒｅｓｕｍｅ＿ａｕｄｉｏ＿ｐｌａｙｂａｃｋ（ｉｎｔｈａｎｄｌｅ）
下記は、再生リストにある次の音声ファイルの初めにスキップしてそれの再生を開始するために音声サーバーに命令するものである。
ｉｎｔｓｋｉｐ＿ａｕｄｉｏ＿ｐｌａｙｂａｃｋ（ｉｎｔｈａｎｄｌｅ）
下記は、Ｂチャンネル音声接続を介して送信される音声の音量を調整するために音声サーバーに命令するものである。
ｉｎｔａｄｊｕｓｔ＿ｖｏｌｕｍｅ（ｉｎｔｈａｎｄｌｅ）
下記は、Ｂチャンネル音声接続を介して再生中の音声ファイルの再生を阻止するために音声サーバーに命令するものである。
ｉｎｔｓｔｏｐ＿ａｕｄｉｏ＿ｐｌａｙｂａｃｋ（ｉｎｔｈａｎｄｌｅ）
下記は、Ｂチャンネル音声接続上に他の音声接続を橋渡しするために音声サーバーに命令するものである。
ｉｎｔｂｒｉｄｇｅ＿ｃａｌｌ（ｉｎｔｈａｎｄｌｅ）
下記は、発呼上に以前に橋渡しされていた音声接続を除去するために音声サーバーに命令するものである。
ｉｎｔｕｎｂｒｉｄｇｅ＿ｃａｌｌ（ｉｎｔｈａｎｄｌｅ）
下記は、音声接続を介して受信中の音声を音声ファイルに記録するために音声サーバーに命令するものである。
ｒｅｃｏｒｄ＿ａｕｄｉｏ（ｉｎｔｈａｎｄｌｅ）
下記は、現時点で音声ファイルの記録を中断するために音声サーバーに命令するものである。
ｉｎｔｐａｕｓｅ＿ａｕｄｉｏ＿ｒｅｃｏｒｄ（ｉｎｔｈａｎｄｌｅ）
下記は、中断された音声ファイルの記録を再開するために音声サーバーに命令するものである。
ｉｎｔｒｅｓｕｍｅ＿ａｕｄｉｏ＿ｒｅｃｏｒｄ（ｉｎｔｈａｎｄｌｅ）
下記は、音声ファイルの記録を停止するために音声サーバーに命令するものである。
ｉｎｔｓｔｏｐ＿ａｕｄｉｏ＿ｒｅｃｏｒｄ（ｉｎｔｈａｎｄｌｅ）
上記について、命令“ｈａｎｄｌｅ”は、接続が確立された時に接続機能により返送される値であり、確立成功なら０を、不成功なら−１を返送する。
【図面の簡単な説明】
【図１】本発明の原理を実施することができるマルチメディアシステムを示す。
【図２】図１の使用者端末において本発明の原理を実行するプログラムをフローチャート形式で示す。
【図３】図１の使用者端末において本発明の原理を実行するプログラムをフローチャート形式で示す。
【図４】図１の使用者端末において本発明の原理を実行するプログラムをフローチャート形式で示す。
【図５】図１の使用者端末において本発明の原理を実行するプログラムをフローチャート形式で示す。
【図６】図１の使用者端末において本発明の原理を実行するプログラムをフローチャート形式で示す。
【図７】図１の使用者端末において本発明の原理を実行するプログラムをフローチャート形式で示す。
【図８】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図９】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図１０】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図１１】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図１２】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図１３】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図１４】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図１５】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図１６】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図１７】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図１８】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図１９】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図２０】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図２１】図１の音声サーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図２２】図１のデータサーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図２３】図１のデータサーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図２４】図１のデータサーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図２５】図１のデータサーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図２６】図１のデータサーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図２７】図１のデータサーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図２８】図１のデータサーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図２９】図１のデータサーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図３０】図１のデータサーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図３１】図１のデータサーバーにおいて本発明の原理を実行するプログラムをフローチャート形式で示す。
【図３２】図１のアプリケーション制御装置において本発明の原理を実行するプログラムをフローチャート形式で示す。
【符号の説明】
１０データサーバー
２０アプリケーション制御装置
３０音声サーバー
４０ワークステーション
５０動作援助装置
１５０開発プラットフォーム[0001]
[Industrial applications]
The present invention relates to multimedia communication systems.
[0002]
Problems to be solved by the prior art and the invention
As a result of the provision of ISDN in the public telecommunications network, many new services have been introduced. One of the services involves the transmission of multimedia, ie, video (ie, images) and corresponding audio signals. As a result of the multimedia application, the calling and called parties can see and hear each other during a telephone conversation via the ISDN communication path. Multimedia includes other service applications that can be provided to the caller via the ISDN, for example, applications that entertain the caller, such as video with audio. Such multimedia service applications are probably developed by various multimedia application providers. If that is the case, allow the user to access various multimedia applications developed by various providers, regardless of the type of equipment used to perform the access, such as a computer terminal. Is desirable.
[0003]
It is recognized that developing a multimedia application is not an easy task and typically involves designing the application, "debugging", and storing it in a multimedia system for presentation to the user. The application may require additional "debugging" after being stored in the multimedia system to handle interface issues that may arise between the newly designed multimedia application and the multimedia system. Multimedia application designers / providers can address the latter problem by duplicating the multimedia system and using the system as a tool during the multimedia application design / development and debugging phases. However, duplicating a multimedia system for use in designing and debugging multimedia applications is perceived to be expensive and somewhat useless.
[0004]
[Means for Solving the Problems]
Provision of multimedia services is enhanced by using a communication protocol that divides a multimedia application into multiple sections for provision to a user. In particular, the communication protocol of the present invention comprises a plurality of messages that define each function (telecommunications, data, voice, etc.) in a manner that divides a multimedia application into a number of logical blocks for presentation to a user. Embedded in Thus, according to the present invention, when a user interfaces with a particular multimedia application and enters a particular request representing one of the functions described above, the user's associated data terminal will Generates and sends a message to the multimedia system, which performs the required function on a particular block of program blocks that make up the multimedia application being accessed by the user. And respond to it.
[0005]
In accordance with another aspect of the invention, a multimedia application provider sends the application to a multimedia system for storage via a telecommunications network and provides a number of "debugging" and / or development of the application. It can interact with stored applications via a telecommunications network for different purposes.
[0006]
【Example】
Referring now to FIG. 1, there is shown a main block diagram of a multimedia system 100 embodying the principles of the present invention. In particular, system 100 includes a number of controllers that cooperate with each other to provide a particular multimedia application to a user. The control device includes a data server 10, an application control device 20, a voice server 30, a workstation 40, a development platform 150, and an operation support device 50. Data server 10 may be, for example, a 386-WGS workstation available from AT & T and is programmed to operate under the MSDOS operating system to provide data functions related to providing multimedia applications. . More specifically, the data server 10 interfaces with the user via the communication path 11-1 and, upon receiving a request from the user, processes the request itself or processes the request itself in the application control device 20. Alternatively, it is determined whether or not to send to the voice server (control device) 30. For example, if the request is directed to (a) a voice, such as a particular selection of music, the data server 10 sends the request to the voice server 30 via the LAN 45 to process the request, or 2.) If the request is for a particular multimedia application, the data server 10 sends the request to the application controller 20 via the LAN 45. If the request is for a data function, such as specific data stored in memory 61, data server 10 drops the data from memory 61 and sends the data to the user via communication path 11-1. In the embodiment of the present invention, the data may be, for example, a digitized image, a document, a graphic primitive, an animation primitive, an executable program, or the like stored in the database 61. In an embodiment of the present invention, the data may be stored in the database 61 in a compressed format. (As explained below, the decompression of the data is performed at the terminal T1 before the data is provided to the user.)
[0007]
The interface provided by the data server 10 to the user operates to confirm the reception of a call arriving via the communication path 11-1. In the embodiment of the present invention, the communication path 11-1 may be, for example, an ISDN primary rate interface (PRI) communication path including 23 B channels and one D channel. As is well known, each B channel is used to carry telephone calls (voice or data), and the D channel is used to carry signaling information for calls transferred over the B channel. Further, the communication paths 11-2, 11-3, and 152 can also be ISDN PRIs.
In particular, when a user places a call to the multimedia system 100, the telephone network 200 processes the call in a conventional manner and the ISDN D signal channel extending to the data server 10 via the communication path 11-1. The system 100 waits for calls arriving via. The waiting includes notifying the data server 10 of the identity (number) of the ISDN B channel carrying the call. Next, in response to the signal, the data server 10 sends a call admission message to the network 200 via the signal channel, thereby establishing a communication connection between the system 100 and the user. At that point, the user and the system 100 can begin exchanging messages with each other, as described below.
[0008]
The application controller 20 is more particularly responsible for executing all multimedia applications that the system 100 (controller 20) sends to the user's terminal, for example the terminal T1. That is, the controller 20 can be, for example, a 386-WGS computer available from AT & T and operates under the control of the Unix operating system to provide the user with multimedia applications. Here, the application may include data and / or voice (sound). As described above, the data can include digitized images, documents, graphic primitives, animation primitives, executable programs, and the like stored in the database 61. The analog part attached to the data is stored in the database 60 in digital form. For the data portion of the application, controller 20 instructs data server 10 via LAN 45 to drop the data from memory 61 and provide it to the user via communication path 11-1. For the audio portion of the application, the control device 20 sends the digitized audio from the memory 60 to the audio server 10 via the LAN 45 so that the digitized audio is provided to the user via the ISDN channel of the communication path 11-2. Instruct. Further, the application control device 20 waits for reception of a data (voice) file to be input by the user, and instructs the server 10 (30) to store the file in the memory 61 (60). . The application controller 20 sends the information to the user by placing the information on the LAN 45 for transport to the user via the data server 10. The information may relate to a requested application state or an error associated therewith.
[0009]
Voice server 30 may also operate under the UNIX operating system as 386-WGS, and provides an interface between user or application controller 20 and memory 60. In an embodiment of the present invention, the digitized audio associated with each application and / or the digitized audio provided by the user is stored in memory 60. Thus, the audio server 30 is responsible for storing and "playing" the audio associated with each multimedia application.
[0010]
The operating assistance device (OSS) 50 may be, for example, a CompuLert device available from AT & T and monitors the overall operating status of the system 100. Specifically, the data server 10, the application control device 20, and the voice server 30 are arranged to periodically send status messages to the OSS 50 via the communication links 10-1, 20-1 and 30-1. The status message (sometimes called a "heartbeat" message) indicates to the OSS that the controller or server is still running, respectively. If the OSS 50 fails to receive the message within a predetermined time period, for example, once per minute, the OSS 50 estimates that the controller or server that failed to send a status message is defective. An appropriate message is output to a system terminal (not shown) to notify the system 100 administrator. If the control device or server detects an error itself, for example, a possible failure of the communication path, the memory 60 or 61, or the LAN 45, the control device or the server transmits the error via the link 10-1, 20-1 or 30-1. The OSS 50 is notified of the fact. Next, the OSS 50 outputs a failure confirmation message to the above-mentioned system terminal.
[0011]
The user can operate the terminal T1 to access the system 100. The other terminal T1 can be, for example, a 386- or 486-based processing device that operates under the control of the MSDOS operating system. In particular, terminal T1 includes a library of multimedia functions associated with system 100 and conventional telephone circuitry to enable it to interface with network 200. The network may be, for example, a model IDC circuit board available from DGM & S, Inc. of Mount Laurel, NJ, which implements an ISDN Basic Rate Interface (BRI) interface represented by communication path 9 in the figure. Said functions include, inter alia, decompression of data received from the system 100 via one or both of the BRIB channels of the communication path 9. The decompressed data can then be displayed on the display 12 of the terminal T1 or stored in T1's internal memory, such as a floppy or hard disk memory. In an embodiment of the present invention, the decompressed data may be an executable program to be stored in terminal T1, run on terminal T1, and then executed.
[0012]
In FIG. 1, it can be seen that terminal T1 is associated with terminal S1 and optional audio device 5. The audio device 5 operates more particularly to provide the user's audio information, which is received from the system 100 via one of the two B channels of the communication path 9. You. Instead, the user can provide audio information to the system 100 for storage in the memory 60 by talking to the handset of the terminal S1. Next, the call signal received from the terminal S1 is provided to the above-described IDC network, digitized, and transmitted to the system 100 via the B channel of the communication path 9. It can also be seen from FIG. 1 that the terminal T1 can be associated with a conventional television monitor or video display device 8. Thus, the information displayed on the display device 12 of the terminal T1 can also be displayed on the monitor 8. To do so, terminal T1 includes a conventional circuit for converting a VGA formatted signal into an NTSC video signal for display on monitor 8. As such, the information can be displayed on either or both the terminal display 12 or the monitor 8.
[0013]
In addition, the user can use the voice input device (or recorder) 6 as a means for transmitting voice to the system 100 via the terminal T1 for storage in the memory 60 as a voice file. As such, the audio input device 6 can be, for example, a microphone or an audio tape recorder. The audio signal output from the microphone (or recorder) 6 is provided to the amplifier 3, which sends said signal to the IDC network of the terminal T1 for transmission to the communication path 9 described above.
[0014]
(It is noted that the user can also store data in the database 61 associated with the server 10, as described below.)
In an embodiment of the present invention, a library of multimedia functions comprising a unique multimedia protocol is provided to assist in developing and providing multimedia applications to users over a communications network. In particular, this protocol is arranged to be independent of the system 100, the multimedia application and the terminal T1, according to aspects of the present invention. Thus, various multimedia functions can be seamlessly distributed between the system 100 and the terminal T1. Thus, the protocol facilitates communication between the components that make up the mesh multimedia system, including the user terminal. And advantageously, multimedia applications developed according to said protocol can be run on most multimedia systems as long as the system maintains the protocol of the present invention.
[0015]
The protocol more specifically includes messages to invoke (a) telecommunications functions, (b) data access functions, (c) voice functions, and (d) distributed application functions. The remote communication function includes a group of messages for establishing a communication connection and a conference connection between the terminal T1 and the system 100. This group of messages includes (a) connected, (b) disconnected, (c) bridged calls, and (d) non-bridged calls. The data access functions include (a) data file download, (b) data file upload, (c) data download stop, (d) data upload stop, (e) data download restart, and (f) data Contains a group of messages that consist of restarting the upload. The audio functions include (a) reproduction of an audio file, (b) interruption of audio reproduction, (c) resumption of audio reproduction, (d) skip of audio reproduction, (e) volume adjustment, (f) stop of audio reproduction, (G) recording, (h) interruption of recording, (i) restart of recording, and (j) stop of recording. The distributed application function includes a message group consisting of (a) application start, (b) application stop, (c) application suspension, and (d) application restart. (The various instructions relating to the voice server are shown in Appendix A. The format and function of the data server instructions and the application controller instructions are the same as those shown in Appendix A.)
[0016]
As a result of the protocol of the present invention, and in accordance with aspects of the present invention, multimedia applications can be divided into logical components, or blocks, but their provision is under the control of the user. Advantageously, only those blocks of the multimedia application requested by the user are downloaded to the user's terminal, thereby making efficient use of the telecommunications network bandwidth. Advantageously, the partitioning allows the components of the application to be stored and transmitted in a manner that best suits the data format to be transmitted. For example, audio information can be stored in the database 60 in a predetermined format, for example, the ADPCM format. The ADPCM format can be easily demodulated and converted into an audio signal for transmission to a user via a telephone communication network.
[0017]
As a result of the protocol, an application can be partitioned (divided) into blocks. This means that the application is provided to the user in an efficient and quick way. For example, a specific block of the application can be downloaded to the terminal T1 in the background mode and the block can be stored in the terminal T1 so that it can be quickly taken to the terminal display device 12 when requested by the user. For example, a block of an application program that assists the displayed menu item with the highest likelihood of user selection can be first downloaded to the background, and a block of the application program that assists the menu with the next highest likelihood of user selection. It can then be downloaded, and so on. Therefore, when the user selects a display menu item, it is appropriate that application data and / or software for assisting the selection is resident (stored) in the user's terminal.
[0018]
(Alternatively, blocks can be downloaded sequentially based on their size rather than the likelihood of selection. Note that application blocks that assist in displaying menu items can be downloaded in parallel in background mode (ie, preloading). Where the network bandwidth is allocated between blocks based on the likelihood of a relevant menu item selected by the user.As another alternative, the bandwidth allocation is based on the size of the data block. The order in which the blocks are downloaded sequentially or in parallel in the background is explicitly specified by the application provider, ie a large part of the bandwidth is allocated to data blocks larger than the smaller data blocks. Conversely, most of the bandwidth may be allocated to smaller data blocks to ensure that the blocks are inherent in the user's terminal before the user makes a menu selection. )
[0019]
With the foregoing in mind, the following describes how multimedia applications are requested and provided to users associated with terminal S1 and terminal T1. Specifically, when the user enters a command to invoke the multimedia function, the terminal T1 enters a unique system 100 identifier assigned to the user, for example a conventional login, and then the user's password. Displays a request to the user to enter In response to the user's request, terminal T1 causes its associated telephone network to place an ISDN data call to system 100 via network 200. When the system 100 (data server 10) accepts the call, the network 200 establishes a connection between one of the B channels of the communication path 9 and the dormant B channel of the communication path 11-1. Once the ISDN connection is established, terminal T1 sends the login and password entered by the user. Based on the reception, the data server 10 returns a receipt notification to the terminal T1 when the received login and password are recognized as valid. Otherwise, data server 10 returns an invalid message to terminal T1 and disconnects from the call.
[0020]
In addition to the acknowledgment, the data server 10 returns a menu of multimedia applications resident in the system 100. In the system 100, the menu is in a compressed format. The data server 10 also sends along with the menu, information confirming that each multimedia application associated with each of the menu items is in the memory 61 and / or the memory 60. Based on the reception, the terminal T1 decompresses the data (menu) using the conventional decompression algorithm, and displays the decompressed menu on the terminal display device 12. The terminal T1 also stores the decompressed application location information in its internal memory.
[0021]
The displayed menu of the multimedia application includes, for example, travel movies, games, catalog shopping, education, and the like. The menu may also include multimedia applications related to the well-known Sesame Street (trademark of Children's Television Workscorp) television program. Therefore, the following description will be made in connection with the Sesame Street application. (However, it will be understood that the description below is equally relevant to other multimedia applications, such as the multimedia applications described above.)
[0022]
When the user selects the Sesame Street application by, for example, positioning the conventional mouse cursor on the displayed menu item and operating the associated mouse button, the terminal T1 will retrieve its "application location information" from its internal memory. To generate a message containing a request to send the Sesame Street application and its location information. Terminal T1 then sends this message to system 100 via the ISDN connection established in network 200. Based on the receipt of the message, the data server 10 extracts the location information from the message and uses this information to confirm the storage location of the first block of the requested application in the database 61. Next, the data server 10 unloads the first block of the application and sends the compressed block to the terminal T1. Here, the first block includes (a) a partition to be displayed on the terminal T1, and (b) an executable program. Upon receiving the first block, the terminal T1 decompresses the data and executes the received program. The received program sequentially displays the accompanying partitions on the display device 12 and sends a request to the audio server to start reproducing the theme song of the program on Sesame Street.
[0023]
The partition indicates a room filled with various objects, such as balls, trains, bookcases, arcade games, and the like. Each object represents a menu selection. For example, when (a) a ball is selected, a bouncing ball is displayed with associated sound effects, (b) when a train is selected, a train running on a circular track is displayed with associated sound effects, and (c) If you select a bookcase, the book function of the story is displayed. In one aspect of the invention, the system 100 can download the portion of the application under consideration while deciding which menu item to select, as described above. For example, balls and trains are animated applications that can be downloaded before a user selects a menu item.
[0024]
When the user selects, for example, a train multimedia application (movie plus sound), an application block for assisting the selection already exists in the terminal T1. Therefore, the terminal T1 can promptly display the train animation and the reproduction of the sound effects related to the user selection. More specifically, the train animation displays a train moving in a slightly circular orbit, with a sound indicating a whistle. On the other hand, when the user selects the bookcase menu item, the terminal T1 displays a menu supporting the application. Here, the menu is already stored in terminal T1 as a result of the pre-downloading feature. The bookcase menu, when displayed on display device 12, shows images depicting various book covers, each including the book title of each book. This menu is accompanied by a background sound, the theme song of the Sesame Street program. Each of the books is composed of a series of pictures and sounds telling the story. While the user decides which menu item to select, the system 100 downloads the first page of each book to the terminal T1, as described above. When the user selects a book, the terminal T1 displays the first page of the selected book stored in advance. Further, terminal T1 generates a message including the name of the audio file associated with the selected first page and sends the message to system 100 via communication path 9. If the application requires an audio channel (this is the case when playing the sound effects described above), the application sends a request for the sound effects to the sound server 30 via the data server 10. In response to this request, the voice server 30 sends a specific command to the network 200 to establish the communication path 11-2.
[0025]
Upon receiving the message, the data server 10 sends the request to the voice server 30 via the LAN 45. The server 30 sequentially removes the file identified from the memory 60 and outputs the file as a continuous (isochronous) bit stream via the associated B channel of the communication path 11-2 extending between the terminals T1 via the network 200. Send The terminal T1 then converts the received bit stream into an analog signal and provides the analog signal to the terminal S1 or the audio device 5. Similarly, while the user is watching the page while listening to the audio, the system 100 downloads only the next selected page to the terminal T1. Terminal T1 and system 100 continue to operate as described above until the last page of the selected book is provided to the user. At that point, the user may request a redisplay of this menu and continue as described above. Alternatively, when the main selection menu is displayed, the user can select the main menu.
[0026]
In one aspect of the present invention, a user, eg, a user associated with terminal S1 and terminal T1, may access a “real” agent, eg, a travel agent, while viewing a particular multimedia application. it can. For example, if a user is watching a multimedia travel movie application on display 12 with audio output to either terminal S1 or terminal T1, and wishes to connect with a travel agent, system 100 A request for such a connection can be input to the. The user can do this by pointing the screen cursor to a particular icon being displayed with the travel movie and selecting that icon in a conventional manner. Terminal T1 responds by sending a bridge call message (described below) to system 100. Based on the reception of the message, the data server 10 instructs the voice server 30 via the LAN 45 to make a call via the available ISDN B channel of the communication path 11-2 and a proxy (operator) associated with the application. , For example, a guide, that is, an operator 225. When the call is answered, the voice server 30 signals the network 200 to bridge the call to a user's call that reaches the system 100 via the communication path 9. The voice server 30 then disconnects the bridge call and the travel movie application is suspended until the call to the agent is completed. When the call is completed, the voice server 30 reconnects to the terminal T1 via the communication path 11-2. The system 100 then continues to provide the travel movie.
[0027]
As can be seen from FIG. 1, the system 100 also includes a workstation 40 and an application development platform (ADP) 150, which are associated with the system and developers of multimedia applications, such as application supply devices 125 and 175, respectively. Used to interface multimedia application development facilities. In an embodiment of the present invention, workstation 40 may be, for example, a Gateway 2000 computer available from Gateway Company, and an application supply device, such as supply device 125, is being developed into system 100 (databases 60 and 61). Provides a mechanism by which applications can be stored. The supply device 125 can do so by making an ISDN call via the BRI ISDN path 126 to establish a connection with the workstation 40. Once the connection is established, the supply device 125 can interact with the workstation 40 and instruct the workstation 40 to store the application in the memory 60 and / or 61. To enable the transfer of the application to the system 100, the feeder 125 transfers each of the files that make up the application to the workstation 40 via path 126 using a data upload instruction (described below). Send. Upon receipt of the file, the workstation 40 stores the file in the memory 60 or 61 based on the format of the received file data (sound or digital data). Once all of the files are stored in the system 100, the supply 125 can "debug" the stored application by calling the application development platform (ADP) 150 via path 126.
[0028]
The ADP 150 may also be a gateway 2000 computer, which, in response to the call, stores the supply device as if it were a user, eg, a user associated with terminal S1 or terminal T1. Mimic the functionality of the system 100 associated with providing an application to a supply device (Emulate) As described above, the servers 10 and 30 and the control device 20 are repeated. Thus, in accordance with one aspect of the present invention, system 100 causes the application provider to store the application being developed by system in system 100 and then "debug" the application via telecommunications network 200 (ie, (To find and correct errors). Thus, the application supply device interfaces with the associated application in substantially the same way that the user eventually interfaces with the application.
[0029]
The software running the multimedia application can be split between the terminal T1 and the system 100. Referring to FIG. 2, a main menu program stored in the terminal T1 to allow a user operating the terminal T1 to access the multimedia system, that is, the platform 100 is shown. More specifically, when the user invokes the name menu program, the program enters block 300 and proceeds to block 301, prompting the user to log in and enter a password. When the user does so, the program proceeds to block 302, which initializes the ISDN board as well as the software that controls the operation of the board. The program then establishes a telephone call to multimedia platform 100 using one of the two basic rate ISDN channels (block 303). When a telephone call is established, the main menu program and the system (platform) 100 communicate with each other. The communication includes passing a password and logon input to the platform 100. If the platform 100 determines that the logon is invalid, the platform 100 terminates the ISDN connection. The program will display a message to that effect and exit. However, if the platform recognizes the entered logon as valid, it notifies the program (block 304) and downloads a menu of multimedia services that the user can access. Upon receipt, the program (block 305) displays the service and waits for the user to enter a selection (block 306). When the user enters a selection, the program (block 306) sends the selection to platform 100, and then runs the selection when received from platform 100 (block 307), as described below. Upon completion of the multimedia selection, the program displays a menu of services (block 308) and waits for the user to enter a next selection. When the user enters a selection, the program sends the entered selection to the multimedia platform, as described above. (Block 306). On the other hand, if the user desires to end the activity period and inputs an identifier indicating the fact, for example, "q" of "quit", the program notifies the platform and terminates the ISDN connection.
[0030]
The main menu program is assisted by a number of other programs or tasks that are designed to run in background mode. One of the programs performs an ISDN task as shown in FIG. In particular, the task, when entered at block 400, proceeds to initialize a number of functions (block 401). Said initialization includes setting up the necessary queues for storing data files associated with the selected application. The data file includes the downloading of the file from the platform to the user's terminal and vice versa. Initialization also involves invoking data compression and decompression tasks. The program then waits to receive a request from the application, ie, a request to "get" the next data file. The ISDN task also includes calling a so-called bookkeeping task (block 408). This bookkeeping task follows the logon and logoff functions that the user's terminal performs during communication with the platform, as well as various ISDN functions as described below. The ISDN task also invokes a data transfer function (block 405). The data transfer function operates to transfer a digital data file between the user's terminal and the platform (block 409). Similarly, the ISDN task also calls the voice function (block 406). The audio function operates to receive a digitized audio file from the application platform and "play" this audio on the speaker 4 in response to a command of the selected application (block 410). If the request received from the selected application does not have the above function (block 403, 405 or 406), the ISDN task sends a so-called negative acknowledgment to the application (block 407), and the next request from the selected application is sent. (Block 402).
[0031]
A flowchart of the bookkeeping function 403 described above is shown in FIG. Specifically, when the bookkeeping function is invoked (block 500), it checks whether the received request is a request to initialize the ISDN hardware described above (block 501). If so, the program initializes the ISDN hardware (block 506). The request to perform the initialization typically occurs when the application program determines that the ISDN communication path between the user's terminal and the platform 100 is in an unknown state, for example, that the terminal is "disconnected". . If not, the program (blocks 502/503) checks to see if the request is for a particular type of ISDN connect / disconnect. For a connection request, the program (block 507) sends so-called connection instructions, including parameters defining a particular connection to the platform 100. For a disconnection request, the program (block 508) sends a disconnection instruction that includes parameters defining a disconnection with the platform 100. If a particular function (ie, block 506, 507 or 508) was successfully performed (block 504), the program changes the identifier called "VAL" to a 1 indicating that the requested function was successfully completed. Set (block 505) and then return to block 402. Otherwise, the program sets VAL to 0 indicating that the requested function 405 failed (block 509).
[0032]
A flowchart of the above data function is shown in FIG. In particular, the data function, when invoked (block 600), verifies the format of the data request received from the selected application. If the data request is found to be a request to download data from a so-called platform to the user's terminal (block 601), the program adds this request to a so-called download processing queue (block 604) and then proceeds to FIG. Returning to block 402 of FIG. On the other hand, if the request is found to be a request to upload data from the user's terminal to the platform (block 602), the program adds this request to a so-called upload processing queue (block 605) and then blocks Return to 402. If the program finds that the request is something other than a download or upload, that is, a cancellation of a particular request that is already queued for processing, it will set the status for this particular request. Update (block 606). The program sends a cancellation message for this particular request to the platform or data or voice server (block 607). Thereafter, the program returns to block 402.
[0033]
FIG. 6 illustrates, in flowchart form, a task or program that runs in a background mode to perform a data file downloading function. When called (block 700), the program (block 701) checks to see if it has received a request to download a file from the platform to the user's terminal. If so, the program (block 703) stores the request in the associated queue and then proceeds to block 702. The program (block 702) then checks to see if data is currently being received from the platform, and if so, returns to block 701. Otherwise, the program (block 704) checks to see if its associated queue is free, and returns to block 701 if it is. Otherwise, the program (block 705) is for (a) reading and decompressing the data file received from the platform, and (b) thereafter processing the file according to the instructions contained in the file. Call (create) a task. Thereafter, the program returns to block 701.
[0034]
FIG. 7 illustrates, in flowchart form, a task or program that runs in a background mode to perform a data file upload function. The program shown in FIG. 7 is somewhat similar to the program shown in FIG. 6, but performs different functions. Specifically, when invoked (block 800), the program (block 801) checks to see if it has received a request from the user's terminal to send a particular file to the platform or data or voice server. I do. If so, the program (block 803) stores the request in the associated queue and then proceeds to block 802. The program (block 802) then checks to see if data is currently being sent to the platform, and if so, returns to block 801. If the program finds that it is not in upload mode, it checks to see if its associated queue is free (block 804), and if so, returns to block 801. Otherwise, the program (block 805) compresses the data file to be uploaded and sends (generates) this file to the platform. Thereafter, the program returns to block 701.
[0035]
8 to 19 show, in the form of a flowchart, a program for executing the present invention in the voice server 30 (FIG. 1). Referring specifically to FIG. 8, when the analog server is turned on and "helped", the program enters block 900 and proceeds to initialize an interface (I / F) circuit board that interfaces the network with the voice server. (Block 901). The program also initializes a number of program variables and waits for a message from the data server requesting a voice ISDN_B channel to be connected to the user's terminal via the network 200 (block 902). In response to receiving this message, the program (block 903) creates a B_Channel_Server process and associates the latter process with the B_Channel connected to the user's terminal, as described below. The program (block 904) then stores the received message in a queue associated with the newly created process, and then returns to block 902 to wait for the next connection message from the data server 10.
[0036]
FIG. 9 illustrates, in flowchart form, a B_Channel_Server process that is generated to enable the use of a particular ISDN_B channel connected to a voice server. That is, a B_Channel_Server process is created to serve each of the connections. In particular, if created, the B_Channel_Server process (“program”) enters block 1000 and initializes a number of program variables used to make a particular ISDN_B channel available. The program (block 1001) then drops the request message from its associated queue and then branches based on the type of request contained in the message (block 1002). The branch causes the program to branch to one of the 14 subroutines 1003 via 1016 as shown. The program branches to the last subroutine 1017 if the request message has an unknown format. Subroutine 1017 records the error and then returns to block 1001 to process the next request message stored in the associated queue.
[0037]
Next, the remaining subroutine 1003 via 1016 will be described. In particular, an enlarged version of block 1003 is shown in FIG. Program acquisition block 1003 means that the request message is a request to establish a primary rate (PRI) rate B channel voice connection between the voice server and the user's terminal. To do so, the program (block 1003-2) first checks the so-called comprehensive information table, which is accessed by both the data and analog servers, and finds that the 2B channel that can be assigned to the user is And / or check if it has already been assigned as a data path by the voice server 30. If it is, the program cannot respond to the connection message. Otherwise, the program assigns a dormant B channel to the connection and then updates the associated memory table to indicate that the assigned channel is busy. The program (block 1003-3) then sends instructions (as described above) to establish a B-channel connection between the ISDN network and an interface (I / F) circuit board that interfaces the voice server. Here, the instructions include the answering telephone number and the channel number of the selected B channel. The I / F circuit then sends a call setup message containing the telephone number and channel number over the associated ISDN_D channel, thereby effectively placing the call to the user's terminal. The program (block 1003-4) then provides the above comprehensive information used to track the status of each actual user and the two ISDN channels that can be assigned to the application selected by each user. Update the table. Thereafter, the program returns to block 1001.
[0038]
An expanded version of block 1004 is shown in FIG. 11, which enters when the received request is related to a request to play a particular analog file (block 1004-1). If so, the program (block 1004-2) checks to see if the playback server is already running (generating) as a result of the same previous request. If so, the program (block 1004-3) waits for a playback server created to serve the user's request for an audio application, eg, playing a music file over the connected B channel. Store the current request in a matrix. Next, the program (block 1004-4) generates a play server routine (play_server) that serves the user's request, and then proceeds to block 1004-3.
[0039]
The program generated in block 1004-4 (FIG. 11) is shown in FIG. Specifically, upon entry, the program (blocks 1004-41) initializes a number of variables and lists, such as playlists, to use during the running time. The program (blocks 1004-42) then checks its queue to see if it contains one or more playback requests for the file that is ready to be "played" for the user. If the queue is empty, the program exits. (I.e., the program continues to run as long as the entry is in the associated queue.) Otherwise, the program (blocks 1004-43) returns an indicator indicating that the file can be "played", such as a numeric value. Create a list of files, including encrypted music or stories. More specifically, "playing a file" means that the program drops the digitized data constituting the file from its associated audio memory 60 and supplies it to the I / F board. The I / F board then converts the digitized data into analog form and sends it to the user via the assigned analog B channel. What the indicator means is a request to play, suspend, skip, or resume the file (blocks 1005, 1007, and 1006, respectively). Requests to verify the file, which are related to other queued requests (indicators) to interrupt playback of the file, are not removed from the queue and resume playback of the file. Remain in the queue until the request is received and stored in the associated queue. A request to stop playback of the file (block 1007), or the end of "play" of the file contents, causes the program to stop the playback and reject the associated request to confirm the file.
[0040]
When the program finishes creating such a list, the program (blocks 1004-45) enters play_list processing, which causes each file in the list to be played, ie, sent to the user, as described above (block 1004-45). Block 451 in FIG. 13). The actual file playback is performed in the file_player process generated in block 454. However, if file_player processing is already active (block 452), the program adds the request to the file player's queue. Returning to FIG. 12, if the playlist is free (block 1004-44), the program (block 1004-46) waits until a new entry (ie, a resume or play request) is stored in the associated request queue. . Upon receiving the notification, the program returns to block 1004-42.
[0041]
The file_player process generated at block 454 is shown in FIG. 14 and enters at block 454-1. Specifically, the program (block 454-1) initializes various software variables and then checks whether its associated queue is free (block 454-2). If so, the program exits. Otherwise, the program updates the user's information table to note that the user has requested playback of a numbered file (ie, playback mode). The program then "plays" the file in the manner described above, ie, by unloading the file content and sending it to the I / F board. During the unloading operation, the program seeks to see if an end-of-file (EOF) indicator has been encountered or if a user request to stop playing the file has been received. If the program (block 454-5) encounters a user request (RQST) to stop playing the file, the program (block 454-6) issues an instruction to end the transmission of the file to the I / O. The file is sent to the F board, and as a result, the reproduction of the file ends. Otherwise, the program returns to block 454-2.
[0042]
As explained above, the versatility of multimedia platform 100 provides an application development device with the option of allowing a user to store analog files, such as music, in disk file 60. To that end, the user can invoke the option by entering a request to store the audio file on the disc, where the request is carried via the data and audio server to the B channel server. (The idea of storing the file created by the user in the disk memory 60 is referred to herein as "recording" the file.) In response to receiving the request, the B-channel server of FIG. And process the request. An enlarged version of block 1009 is shown in FIG. If so (block 1009-1), the record_request routine checks to see if the record server has already been generated to process the user's request (block 1009-2). If so, the program (block 1009-3) stores the user's request in a queue associated with the record_server process. The program also stores, in the queue, the identity (location) of the file used to store the user's record. Thereafter, the program returns to block 1001. If the server has not been so created, the program (block 1009-4) creates a replica of the server to process the request, and then proceeds to block 1009-3.
[0043]
FIG. 16 illustrates, in flowchart form, the record_server process generated in block 1009-4 of FIG. This recording_server processing is for storing analog data representing, for example, the characteristics of music on the disk 60 for the user to use in the future. Specifically, upon entry (blocks 1009-41), the program initializes a number of variables and a list to be used in its current entry, eg, a record list. Then, whether the program (blocks 1009-42, 1009-43, 1009-44 and 1009-45) includes one or more recording requests for files ready to be stored in memory for the user. Check the queue to find out. If the queue is free, the program exits. (I.e., the program continues to run as long as the entry is included in its associated queue.) Otherwise, the program (blocks 1009-43) is the file associated with the indicator and the program is Create a list of files expected to be received via the I / F board for storage of. More specifically, “recording a file” means that a program receives data constituting a file from an I / F board associated with a B channel connected to a user and stores the data in a memory 60 for the user. Means to store. The I / F board converts the analog data into a digital format based on the reception of the analog data via the associated B channel. The record_server (ie, the record_list process described below) then stores the digitized data, as described above. The indicators mean (a) "recording" the file, (b) "pausing" the recording of the file (block 1010), (c) "resume" the recording of the file (block 1011), and (d). This is a request for "stopping" the recording of the file (block 1012). A request to confirm a file, which is associated with a queued request (indicator) for interrupting the recording of a file, is not removed from the queue and the request to resume the recording is made. Stay in the queue until it is received and stored in the associated queue. A request to stop recording a file, or upon the last reception of the data comprising the file, causes the program to stop the recording. One aspect of the program (blocks 1009-46) is to enter the record_list process shown in FIG.
[0044]
It can be seen that the configuration of the record_list process is similar to the configuration of the playback_list process shown in FIG. As such, the operation of the record_list process can be easily understood by reference to both FIG. 13 and FIG. 17, so FIG. 17 is not described here. However, the record_list process generates (a) a file_recorder process if it is not yet active and is useful to the user, and (b) the record list is queued in the file_recorder process. In addition, only return to block 1009-42 after that.
FIG. 18 is a flowchart illustrating a file_recorder process generated in the recording_list process. From FIG. 18, it can be seen that the configuration of the file_recorder process is somewhat similar to the configuration of the file_player process. Accordingly, FIG. 18 will not be described here because the functions performed by the many blocks making up the file_recorder process can be easily ascertained as a result of their similarity and the above description of the file_player process. .
[0045]
If the user is listening to the file and the playback volume is too high or too low, the user can enter a request for volume control. In response to receiving this request, the B_channel program in block 1013 of FIG. 9 instructs the I / F board associated with the B channel connected to the user to transmit to the user via that channel. Increase or decrease the volume of information, for example music.
In some applications, such as travelogue applications, a user may seek to interact with a genuine operator or agent associated with the application. For example, watching a multimedia application related to a travel movie, a user may wish to contact a travel agent to obtain more details about the touristic "places" seen in the application. If so, the application suitably allows the user to enter a request to communicate with a travel agent associated with the application. Thus, in response to such a request, the program branches to block 1014 of FIG. 9 for performing the conference function. An enlargement of block 1014 is shown in FIG. It can be seen that the subroutine or program shown in FIG. 19 is somewhat similar to the subroutine shown in FIG. However, the bridge_call program operates somewhat differently. In particular, when the program enters (block 1014-1), it obtains the dormant B channel (1014-2) and marks the channel as busy in the channel assignment table. The program then sends instructions to the interface board to establish a telephone call over the B channel with the telephone number included in the request message. This message was originated by the data server in this case. The program also includes in the instructions a request to conference (bridge) with the newly established call on the analog B channel assigned to the user. Next, the program (block 1014-4) updates the comprehensive user information table that records the B channel assignments in pursuit of the state of the application. Thereafter, the program returns to block 1001.
[0046]
At this point, if the I / F board establishes a connection with a third party (for example, a travel agency), it can be seen that the user and the third party can communicate with each other. When the conversation between the user and the third party ends, the user can input a request to terminate the connection with the third party (stop the bridge). Such requests, like most requests entered by the user, are carried to the B-channel server by an ISDN connection between the user's terminal and the data server. Upon receiving such a request, the B_Channel_Server program branches to the non-bridge call routine represented by block 1015. An enlargement of block 1015 is shown in FIG. More specifically, the unbridged call routine, when entered (block 1015-1), obtains from the user's information table the identity of the ISDN B channel used to establish the call with the third party. Next, the program (block 1015-2) sends a command to terminate the B-channel connection to the I / F board. Here, this command is for confirming the B channel. Next, the program (block 1015-3) includes: (a) the B channel is paused to update the user information table; (b) the connection with the third party has been disconnected; and (c) the user Update the channel assignment table to indicate that the B channel assigned to is not bridged. Thereafter, the program returns to block 1001 in FIG.
[0047]
If the analog B channel associated with the user is no longer needed, the program branches to block 1016 of FIG. An enlargement of block 1016 is shown in FIG. If so (block 1016-1 in FIG. 21), the program sends a disconnection command to disconnect the associated B channel to the I / F board (block 1016-1). Here, this command is for confirming the related B channel. The I / F board then generates a signaling message using the information in the disconnection command and sends it over the associated signal (D) channel. The program (block 1016-3) then updates the assignment table to indicate that the C channel is dormant and update the user information table accordingly. Thereafter, the program returns to block 1001.
[0048]
The program that runs the data server is somewhat similar to the program that runs the voice server, as seen below. In particular, when power is applied to the data server and it becomes "usable," the process shown in FIG. 22 occurs to associate with each of the B channels serving the multimedia platform (FIG. 1). , A simple program (not shown) is input. More specifically, the program of FIG. 22 is a simple loop arrangement that first enters a B channel manager routine (block 2001). When the B-channel administrator routine has completed its task, the program enters the B-channel server routine (block 2002). An enlarged version of block 2001 is shown in FIG. Specifically, upon entry (block 2003), the program awaits receipt of a message from the associated B-channel. Upon receipt of a message from the I / F board connected to the associated B channel, the program branches to one of a number of different routines based on the type of message received. If the message format is unknown, the program branches to block 2004, where it sends an error to the OS system 50 that stores the received message for processing by the platform administrator. The program then returns to block 2003 and awaits receipt of a new message via the associated B channel.
[0049]
If the received message is for an incoming call, the program branches to a connection routine (block 2005). An enlargement of block 2005 is shown in FIG. If so (block 2005-1), the connection routine sends a response monitor signal message via the D channel to the I / F board that interfaces with the associated B channel as a way to establish a connection between the B channel and the interface board. Send a message for The routine then checks to see if the caller (eg, terminal T1 in FIG. 1) is already connected to another B channel (block 2005-3). (That is, the received message is a request for the second B channel.) If not, the routine (program) (block 2005-4) creates a B_Channel server to serve the new connection, Next, the B_channel assignment table is updated to indicate that the channel is busy, as described above (block 2005-5). Thereafter, the routine returns to block 2003 of FIG. If the caller is already connected, the routine (block 2005-6) adds a so-called channel message to the queue of the B-channel server associated with the B-channel on which the message was received in block 2003.
[0050]
If the incoming message is a disconnect request, the program of block 2003 of FIG. 23 proceeds instead to block 2006 where the B channel allocation table is updated to indicate that the B channel is dormant. However, if the incoming message is to place a call, the B_Channel Manager proceeds to block 2007. An enlargement of block 2007 is shown in FIG. Specifically, upon entry, the program proceeds from block 2007-1 to block 2007-2, where the dormant B channel is assigned to the call identified in the received message. The program then instructs the I / F board to dial the telephone number contained in the message, and then processes the status information about making the call returned from the I / F board (block 2007). -4). At that point, the program returns to block 2003.
[0051]
When the B_Channel server program shown in FIG. 25 is generated in block 2005-4, all messages subsequently received over the associated B channel are sent to the generated B_Channel server rather than the B_Channel manager program. It is noted that. In particular, when so generated (block 2005-4 of FIG. 24), the program of FIG. 25 enters block 2400, where it awaits receipt of a message over the associated B channel. Upon receipt of a message, the program branches to one of a number of different routines (blocks 2401-2404) based on the type of message received. If the message is not of a known type, the program (block 2404) marks the event as an error and sends the error to the OS system. Thereafter, the program returns to block 2400 and waits for the receipt of the next message. If the message format is for an application controller program (described below), the program (block 2401) stores the message in the program's queue. Similarly, if the message format is for a function associated with a voice server program, the program (block 2402) stores the message in the queue of the program. If the message type is for a data server function, the program (block 2403) stores the message in a queue of a so-called data server instruction processor. FIG. 25 illustrates that blocks 2401 through 2404 each return to block 2400 after completing their respective tasks.
[0052]
The data_server_command program (data_server_cmd) (block 2403) is shown in flowchart form in FIG. In particular, if so entered at block 2500, the program initializes a number of local variables. The program then checks its associated queue to see if the message is stored therein. If not, the program exits and then reenters after a predetermined time, eg, 25 milliseconds, has elapsed. If there is a message in the queue, the program branches to one of a number of different routines, represented by blocks 2501 through 2514, respectively, based on the type of the message, similar to the B_ process described above. . Examining block 2514 first and then each of blocks 2501-2513, the program branches to block 2514 for events of unknown message type. At block 2514, the program sends an error to OS system 50 and then returns to block 2400.
[0053]
If the message indicates that the second B channel has been assigned to the user for data transmission, the program branches to block 2501 where the user's relevant information to pursue the transaction. Update the table and then return to block 2400. If the message is for a connection request, the program branches to block 2502 for establishing a connection. Specifically, the program first checks the message to see if it is requesting a voice connection, and if so, sends the message to the analog server. If not, the program checks the above comprehensive information table to see if the 2B channel has already been assigned to the user. If so, the program checks to see if both channels have been assigned as data channels. If so, the program cannot respond to the connect message and returns to block 2400. Otherwise, the program assigns the dormant B channel to the user in the manner described above, or changes the state of the B channel already assigned to the user, then there may be cases, The global information channel assignment table is updated to indicate that the assigned channel is in use as a data channel. Thereafter, the program returns to block 2400.
[0054]
If the application that the user is running on terminal T1 no longer needs the B-channel in use for either voice or data mode, the message will be a request to disconnect said channel, whereby: The program proceeds to block 2503. At block 2503, the program checks to see if the message is a request to disconnect the B channel used for voice. If so, the program sends the message to the voice server and then returns to block 2400. Otherwise, the program disconnects the channel by going to sleep mode, as described above for the voice server. The program then updates the various tables described above and then returns to block 2400.
[0055]
If the message is a request from an application program to download a particular data file to the user's terminal, the program proceeds to block 2504. At block 2504, the program determines whether the "download" process is currently associated with running the application selected by the user. If so, the program adds the request to its download queue and then returns to block 2400. Otherwise, the program generates a download process to download the data file identified in the received message. The program then stores the received message in the newly created download process queue, after which block 2400 nimodol. A flowchart of the download process is shown in FIG. Specifically, upon entry (block 2600), the program initializes the various variables used and then checks to see if its request queue is free (block 2601). If free, the program exits. Otherwise, the program (block 2602) creates a list of file names (INPROG_LIST) to be downloaded to the user's terminal. In doing so, the program considers the current form of the 2B channel (or 1B channel) connected between the multimedia platform and the user's terminal, as described below. The program (block 2603) then checks to see if the INPROG_LIST is free. If the list is not empty, the program enters the subroutine XMIT_LIST and sends each file identified in INPROG_LIST. If the program finds that the INPROG_LIST is free, it similarly waits for a notification from the B-channel server whose new request is stored in the queue (block 2605), and returns to block 2601 upon receipt of the notification.
[0056]
The XMIT_LIST subroutine or program is shown in FIG. In particular, if entered (block 2604-1), the program removes the file name from the INPROG_LIST and begins dropping the data making up the file from disk memory. In doing so, the program stores the dropped data in an associated transmit buffer (xmit_buffer) associated with the I / F board serving the associated B channel. That is, if the 2B channels are in use, the data is stored in the I / F board transmit buffer used for these two channels. In this way, the transmission bandwidth is doubled, thereby increasing the data file transmission speed. If only one of the B channels is used for data, the unloaded file is stored in the I / F board transmission buffer used for that channel. If the file number is to be downloaded, the bandwidth of channel 2 or channel 1 is allocated for downloading the file. For example, a case where two files are to be downloaded and the 2B channel is in use. Then one file can be assigned to one channel and the other file to the other channel. As another example, one file can be assigned to 1.5 channels. This means that part of the file is transmitted over one channel and the other part of the file and another file are multiplexed over the other channel. As another example, if only one B channel is available, 3/4 of the bandwidth of that channel may be dedicated to one file and the remaining bandwidth dedicated to the other file. The division of the B channel bandwidth is calculated by the program and recorded in INPROG_LIST.
[0057]
Subsequently, when the program (block 2604-3) encounters data representing the end of file (EOF) during the unloading operation, the file is closed, and the identity of the file is deleted from the INPROG_LIST and the request queue (2604). 7). The program (block 2604-4) then sends an instruction to the I / F board instructing the board to transmit the contents of the xmit_buffer. The program (block 2604-5) then checks to see if it has received a notification message indicating that a new request is stored in its associated request queue. If so, the program returns to block 2601 of FIG. Otherwise, the program (block 2604-6) checks to see if INPROG_LIST is free, and returns to block 2601 if so. Otherwise, return to block 2604-2.
When the program (FIG. 26) proceeds to block 2505, 2506 or 2507, the program (FIG. 27) instructs the download process (FIG. 27) to cancel the downloading of the particular file and suspend or resume, respectively. If the received message is for downloading a data file from the user's terminal to the multimedia platform, the program proceeds to block 2508, where the user's terminal is stored for storage on the multimedia platform or disk memory. Set to receive data files from. That is, the program enters the unloading process, and stores the received message in the queue of the unloading process.
[0058]
The process entering from block 2508 is shown in FIG. It can be seen that the unloading process is somewhat similar to the download process (FIG. 27). Therefore, FIG. 29 will be described briefly. Similarly, upon entry (block 2800), the program initializes the various variables it is using and then exits if the associated request queue is free. Otherwise, the program creates a list (INPROG_LIST) of messages (file names received from the user) contained in its associated queue and based on the type of the associated B channel (block 2802). The program (block 2803) then checks its INPROG_LIST and waits to receive a notification message if the list is free (block 2805). Otherwise, the program enters a process (RCV_LIST) for receiving a file transmitted from the user terminal.
[0059]
The RCV_LIST process is shown in a flowchart form in FIG. The I / F board is a facility for receiving a file from the related B channel and storing the file in the related reception buffer (RCV_BUF) as soon as the file is received. When the buffer becomes full, the I / F board notifies the RCV_LIST processing. The RCV_LIST process or program (block 2901) empties the buffer accordingly. Next, the program (block 2902) stores the data dropped from the buffer memory in the disk memory 61. The data can be associated with one or more files, where the channel configuration indicates how the channel bandwidth was divided between the files if one or more files were dropped. It is noted that. If the program encounters an EOF during the unload and store operation (block 2903), it closes the file and deletes the file name from its associated queue and INPROG_LIST (block 2906). Thereafter, the program returns to block 2801. Otherwise, the program (block 2904) checks to see if a new unload request message is queued, and if so, returns to 2801 as shown. If not, the program (block 2905) returns to block 2901 if it finds that INPROG_LIST is not empty. Otherwise, the program returns to block 2801.
[0060]
In FIG. 26, if the program proceeds to block 2509, 2510 or 2511, it respectively instructs the upload process (FIG. 29) to interrupt, resume or cancel uploading of the particular file.
Block 2512 of FIG. 26 provides an interface between the data server program and the application program. That is, block 2512 thereby provides a means for the program to notify the application program upon completion of a particular download or upload in response to a request received from the application program. In particular, the program at block 2512 searches the request queue associated with the download and upload process for the file name included in the request received from the application program. If the program finds the associated file name in either queue, the application program may indicate to the application program a first flag, such as an incorrect flag, to indicate that the data transfer was not completed (or the transfer was stopped). Returns the value. Otherwise, the program returns a second flag, eg, the correct value, to the application program.
[0061]
The data server program of FIG. 26 proceeds to block 2513 if the format of the message is a request to reconfigure the 2B channel associated with the user. That is, the request is typically from an application program to reconfigure the 2B_channel, eg, drop one of the B_channels. Specifically, the program at block 2513 updates the user information table and the channel assignment table to comply with the reconfiguration request. The program then notifies the download and upload process that a channel reconfiguration has occurred, and stops running the download and upload process during the update.
[0062]
The application entry responding to the user selection is controlled by an application control device program provided in the application control device. More specifically, when the application controller is enabled, the application controller program (APP_CTLR) FIG. 32 enters from block 300 where a particular application, ie, an already contained application, is stopped, suspended or resumed. , Waits for the reception of a request message confirming the user's selection. More specifically, upon receiving the request, the program (block 3001) branches to one of a number of different subroutines (blocks 3002 through 3006) based on the type of message received. If the message type is unknown, the program considers the message an error and sends it to OS system 50 for processing (block 3006). Thereafter, the program returns to block 3000 and waits for the receipt of the next application related request.
[0063]
If the request is for the initiation of a particular application, the program proceeds to block 3002, where the application is invoked. In addition, the program sends the configuration of the B channel associated with the user to the called application program. Next, the control device program updates the user information table to confirm the selected application. Thereafter, the program returns to block 3000. If the request is for termination of the called application program, the controller sends a message to the application program for the effect and updates the user information table accordingly (block 3003). Similarly, in response to a request for interruption (resume), the controller program sends a message for the effect to the application (block 3004 or 3005). The application then performs the requested action in response to receiving the request (sent via block 3003, 3004 or 3005).
The following instructs (requests) the audio server to play the audio file.
int play_audio_file (int handle, char ^* ap, cha ^* tune)
handle is the value returned by the connection function when the connection is established, ap is a string pointer that specifies the application name, and tune is the string pointer that specifies the audio file name, as described further below. It is. The above is for a previously established B-channel audio connection.
The following is an instruction to the audio server to interrupt the playback of the audio file at this time.
int pause_audio_playback (int handle)
The following instructs the audio server to resume playing the interrupted audio file.
int resume_audio_playback (int handle)
The following instructs the audio server to skip to the beginning of the next audio file in the playlist and start playing it.
int skip_audio_playback (int handle)
The following is an instruction to the audio server to adjust the volume of the audio transmitted over the B-channel audio connection.
int adjust_volume (int handle)
The following is an instruction to the audio server to prevent the playback of the audio file being played over the B channel audio connection.
int stop_audio_playback (int handle)
The following instructs the audio server to bridge another audio connection over a B-channel audio connection.
int bridge_call (int handle)
The following instructs the voice server to remove the voice connection previously bridged on the call.
int unbridge_call (int handle)
The following instructs the audio server to record the audio being received over the audio connection into an audio file.
record_audio (int handle)
The following instructs the audio server to interrupt recording of the audio file at this time.
int pause_audio_record (int handle)
The following instructs the audio server to resume recording the interrupted audio file.
int resume_audio_record (int handle)
The following instructs the audio server to stop recording the audio file.
int stop_audio_record (int handle)
Regarding the above, the command "handle" is a value returned by the connection function when the connection is established, and returns 0 if the connection is successful and -1 if the connection is not successful.
[Brief description of the drawings]
FIG. 1 illustrates a multimedia system that can implement the principles of the present invention.
FIG. 2 is a flowchart showing a program for executing the principle of the present invention in the user terminal of FIG. 1;
FIG. 3 is a flowchart showing a program for executing the principle of the present invention in the user terminal of FIG. 1;
FIG. 4 is a flowchart showing a program for executing the principle of the present invention in the user terminal of FIG. 1;
FIG. 5 is a flowchart showing a program for executing the principle of the present invention in the user terminal of FIG. 1;
FIG. 6 is a flowchart showing a program for executing the principle of the present invention in the user terminal of FIG. 1;
FIG. 7 is a flowchart showing a program for executing the principle of the present invention in the user terminal of FIG. 1;
FIG. 8 is a flowchart showing a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 9 is a flowchart showing a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 10 shows, in the form of a flowchart, a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 11 is a flowchart illustrating a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 12 shows, in the form of a flowchart, a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 13 is a flowchart illustrating a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 14 is a flowchart illustrating a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 15 shows, in the form of a flowchart, a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 16 shows, in the form of a flowchart, a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 17 shows, in the form of a flowchart, a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 18 shows, in the form of a flowchart, a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 19 is a flowchart showing a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 20 shows, in the form of a flowchart, a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 21 shows, in the form of a flowchart, a program for executing the principle of the present invention in the voice server of FIG. 1;
FIG. 22 is a flowchart illustrating a program for executing the principle of the present invention in the data server of FIG. 1;
FIG. 23 shows, in the form of a flowchart, a program for executing the principle of the present invention in the data server of FIG. 1;
FIG. 24 shows, in the form of a flowchart, a program for executing the principle of the present invention in the data server of FIG. 1;
FIG. 25 shows, in the form of a flowchart, a program for executing the principle of the present invention in the data server of FIG. 1;
FIG. 26 shows, in the form of a flowchart, a program for executing the principle of the present invention in the data server of FIG. 1;
FIG. 27 shows, in the form of a flowchart, a program for executing the principle of the present invention in the data server of FIG. 1;
FIG. 28 shows, in the form of a flowchart, a program for executing the principle of the present invention in the data server of FIG. 1;
FIG. 29 shows, in the form of a flowchart, a program for executing the principle of the present invention in the data server of FIG. 1;
FIG. 30 shows, in a flowchart form, a program for executing the principle of the present invention in the data server of FIG. 1;
FIG. 31 shows, in the form of a flowchart, a program for executing the principle of the present invention in the data server of FIG. 1;
FIG. 32 is a flowchart showing a program for executing the principle of the present invention in the application control device of FIG. 1;
[Explanation of symbols]
10. Data server
20 Application control device
30 voice server
40 workstation
50 Operation support device
150 Development Platform

Claims

A multimedia communication protocol used in a multimedia system, wherein the communication protocol operates to transfer different segments of a multimedia application from the multimedia system to a data terminal having a display device.
A plurality of messages respectively defining telecommunications, data access, voice and distribution application functions so that each of the multimedia applications can be divided into respective logical blocks for provision to a user of the terminal. When,
Characterize the function requested by the user in response to the user being incorporated into the data terminal and interfacing with one of the multimedia applications and entering a request to indicate one of the functions Means for generating one of said messages and sending said message to said multimedia system;
Means embedded in the multimedia system for performing a requested function for a particular one of the blocks of the one multimedia application in response to receiving the message. protocol.

2. The communication protocol according to claim 1, wherein one of the functions is a remote communication function, and the execution means executes a remote communication function for at least one communication path connecting the terminal to the multimedia system. A communication protocol comprising means for performing.

3. The communication protocol according to claim 2, wherein said remote communication function is a disconnection function, and said executing means includes means for terminating said at least one communication connection.

2. The communication protocol according to claim 1, further comprising one of said functions being a remote communication function, wherein said execution means includes a remote communication path for connecting said terminal to said multimedia system and another remote communication path. A communication protocol comprising means for performing a communication bridge function.

2. The communication protocol according to claim 1, further comprising one of said functions being a remote communication function, wherein said executing means comprises a communication path connecting said terminal to said multimedia system and another remote communication path. A communication protocol comprising means for terminating a conference bridge between them.

2. The communication protocol according to claim 1, further comprising the step of inputting the request relating to a specific file stored in a memory, wherein the execution means establishes a communication path connecting the terminal to the multimedia system. A communication protocol including means for downloading the stored file from the multimedia system to the terminal via the multimedia protocol.

7. The communication protocol according to claim 6, wherein the input request is a request to stop downloading of the storage file, and the execution unit stops downloading of the storage file in response to the request. A communication protocol comprising:

7. The communication protocol according to claim 6, wherein the input request is a request for interrupting downloading of the storage file, and the execution unit interrupts downloading of the storage file in response to the request. A communication protocol comprising:

9. The communication protocol according to claim 7, wherein the input request is a request for restarting downloading of the storage file, and the execution unit downloads the storage file in response to the request. A communication protocol comprising means for resuming loading.

7. The communication protocol according to claim 6, wherein said storage file is a data file.

7. The communication protocol according to claim 6, wherein said stored file is an audio file.

2. The communication protocol according to claim 1, wherein the input request further relates to uploading a specific file stored in an internal memory of the terminal to the multimedia system, wherein the terminal includes: further, the communication protocol, characterized in that it comprises means for uploading the stored files in the multimedia system for storage into the multimedia system.

13. The communication protocol according to claim 12, wherein the input request is a request to stop uploading of the file, and the terminal further transmits the file to the multimedia system in response to the request. communication protocol, characterized in that it includes means for stopping the up pro over loading.

13. The communication protocol according to claim 12, wherein the input request is a request to interrupt uploading of the file, and the terminal further transmits the file to the multimedia system in response to the request. A communication protocol comprising means for interrupting the uploading of the communication protocol.

15. The communication protocol according to claim 14, further comprising the request to resume uploading of the file, wherein the terminal further responds to the request by the file to the multimedia system. A communication protocol, comprising means for resuming uploading of the communication protocol.

In multimedia systems,
Means for interfacing the system with a telecommunications network;
Stores various multimedia applications in the memory, in response to said receiving a request identifying the one of the application that through the telecommunications network, the multimedia signal for individual applications of the subscriber application Means for providing via a telecommunications network;
Receiving the multimedia application over the telecommunications network in response to receiving a call from a multimedia application provider; storing the received multimedia application in the memory; Means for enabling a request for a stored multimedia application.

In claim 16, wherein the system further, the work in accordance with the telephone call from the provider via the network, the stored multimedia application even fully developed and / or debugged without Tei, wherein A system comprising an application development platform that emulates the functionality of the system operable to cause a provider to access the stored multimedia application.

In claim 17 of wherein the system, the application development platform is further of the multimedia applications that the error is corrected by said provider as a result of the access comprise one or more errors before the access A system comprising means for receiving a partition from the provider over the network.

17. The system of claim 16, further comprising: operating in response to a telephone call from the provider via the network, and providing the stored multimedia application to the provider via the network. It was Tadashisa errors that may be included in the application to the provider Osamu, the Osamu Tadashisa multimedia application operative to receive from the provider for storage in memory, application development to emulate the functionality of the system A system comprising a platform.

17. The system of claim 16, further comprising: operating in response to a telephone call from the provider over the network and as if the provider were the subscriber, but included in the multimedia application. in obtaining errors amendments purposes, the so provider has access to the multimedia application, and the provider and the interface through the network, to store Osamu Tadashisa the said multimedia application into the memory A system comprising an application development platform that operates to receive from the provider and emulates the functionality of the system.