JPH0468639A - 情報配信制御装置及び情報配信制御方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、情報配信制御装置、及び、情報配信制御方法
に係り、特に、オンラインで収集したサービス情報を、
各サービス端末からの問い合わせに応じて配信する問い
合わせ応答サービス、あるいは、リアルタイム情報提供
光から新たなリアルタイム情報を受信したときに、新た
なリアルタイム情報に更新すべき情報の表示中のサービ
ス端末に配信するリアルタイム情報サービスにおこなう
だめの情報配信制御装置、及び、情報配信制御方法に関
する。

［従来の技術〕 自動配信サービスを実現する場合、ある情報が更新され
たタイミングで、その情報を表示中の端末全てに対して
、最新情報を一斉に送信する必要がある。

複数の端末へ一方向的、かつ、一斉にメツセージを送信
する処理は、例えば、ＨＩＴＡＣマニュアル　プログラ
ムプロダクトＶＯ３３ＴＭＳ−４Ｖ／ＳＰ　　ＤＣ解説
、ｐ、１６５〜１６７に記載されている一斉送信によっ
て実現することができる。

第３１図は、上記従来方式の一斉送信を用いて、株式市
況情報の株価自動配信サービスを実現した場合の、シス
テム構成と処理フローの概略を示したものである。即ち
、リアルタイム情報収集装置２１、端末４１，４２，４
３．４４からのメツセージが、通信回線１１，３１，３
２，３３，３４、及び、通信制御装置５４　、’　５３
を経由して、情報処理装置内メモリ５２に受信され処理
される様子を示している。情報処理装置内のメモリ５２
には、通信制御装置の制御を行う通信管理モジュール１
０１、端末からの問合せに応じて、当該端末が問合せた
情報の情報識別子（例えば、会社名）を記憶しておく端
末状態管理テーブル１０９の登録処理を行った後１問合
せのあった会社の最新株価を、配信情報管理テーブル１
１２から読み出し、問合せ元端束に応答する問合せ応答
処理タスク１０３、及び、リアルタイム情報収集装置２
１からの最新株価情報を受信して配信情報管理テーブル
１１２に格納するとともに、当該会社の株価を表示中の
全端末に対して、上記従来の一斉送信方法にて最新株価
メツセージを一斉送信する一斉送信処理タスク１０４、
端末ごとに設けた端末送信管理テーブル１１８、そして
、−失透信用に設けた一斉送信処理テーブル１２０があ
る。

〔発明が解決しようとする課題〕

第３１図を用いて、従来方式の問題点を説明する。第３
１図は、端末４１がＡ社株価を、また、端末４２，４３
．４４がＢ社の株価を表示中の時に、リアルタイム情報
収集装置２１、及び、端末４２からほぼ同時に、最新株
価情報とＡ社株価問合せを受付けた場合のシステムの状
況を示したものである。

つまり、■リアルタイム情報収集装置からＡ社の最新株
価（＝￥１５００）情報を一斉送信処理タスク１０４が
通信管理モジュール１０１経由で受信し、■配信情報管
理テーブル１１２内のＢ社株価を更新し、次に■Ｂ社株
価表示中の端末４２゜４３．４４に対して、最新株価を
一斉送信するべく制御ブロック１３１を一斉送信キュー
１２０に登録し、通信管理モジュール１０１を起動する
。

ここで、制御ブロック１３１には、送信メツセージ（即
ち、Ｂ社最新株価）のアドレスとメッセージ長等がセッ
トされている。

次に通信管理モジュールは一斉送信キューに登録された
メツセージについては、送信先端末、及び、メツセージ
のアドレスと長さを、逐次、通信制御装置に入力してゆ
く。通信制御装置内には、接続先端末ごとにＦＩＦ○（
先入れ先高し）の送信バッファが設けられているが、送
信バッファが満杯の場合（ビジー状態と呼ぶ）通信管理
モジュールはメツセージ入力を待つ必要がある。

第３１図では、端末４２の通信制御装置内バッファが満
杯であるとする。この場合、■端末４３゜４４に対して
一斉送信が行われ、端末４１については、バッファが空
くまで送信が延期されることになる。次に■端末４２か
ら、Ａ社の株価問合せを問合せ応答処理タスク１０３が
通信管理モジュール経由で受信し、■端末状態管理テー
ブル１０９を更新し、■Ａ社の株価を読み出し、■応答
メツセージとして端末４２の送信キューに応答メツセー
ジの制御ブロック１３０を登録して、通信管理モジュー
ルを起動する。この時、端末４２の通信制御装置内バッ
ファはまだ満杯であり、メツセージは通信制御装置に入
力されないものとする。次に、通信管理モジュールが通
信制御装置から端末４２について送信完了通知を受は取
ると、満杯であったバッファに空きが生じたことになる
ので、問合せ応答用の端末送信キュー１１８と一斉送信
キュー１２０をチエツクする。ここで、両方のキューに
メツセージが登録されている場合、従来は、問合せ応答
用の端末送信を先に行ってから一斉送信を行うという方
式をとっていた。そのため、第３０図の場合、端末送信
キュー１１８に登録されている応答セラセージ（＝ＡＡ
社新株価）が、先に通信制御装置内のバッファに入力さ
れ、その後、二斉送信メツセージ（＝Ｂ社最新株価）が
バッファに入力されることになる。その結果、端末４２
では、問合せたＡ社の最新株価が先に表示され。

その後、突然、８社の最新株価が表示されることにより
、端末利用者にとってはＡ社の最新株価情報を失ってし
まうという問題が発生する。

以上まとめると、従来方式では、問合せ応答用の送信キ
ューのメツセージを一斉送信キュー内のメツセージより
優先的に通信制御装置に送信するスケジューリング方法
を採用していた。そのため、自動配信において最新情報
を一斉送信キューに登録した直後、−失透信先の端末か
ら問合せを受付け、別の種類の情報を問合せ応答送信キ
ューに登録した場合、問合せ応答送信キューに登録され
た応答メソセージが、−失透信キューに登録されている
自動配信情報より先に端末に送信されるというメツセー
ジの追い越しが発生し、後から送信された自動配信情報
が先に送信された応答情報を破壊し、端末に正しい情報
が表示されなくなる。

尚、スケジューリング方法を、−失透信優先にしたとし
ても、今度は、問合せ応答メツセージを一斉送信メッセ
ージが追い越す可能性があり、やはり、情報が正しい順
番で端末に表示されなくなる、という問題が発生する。

本発明の目的は、上述した問い合わせ応答サービス機能
とリアルタイム情報サービス機能とを備えた情報配信制
御装置において、情報の追越し配信を防止する情報配信
制御装置、及び、情報配信制御方法を提供することにあ
る。

〔課題を解決するための手段〕

上記目的を達成するために、本発明の情報配信制御装置
では、情報配信処理を行うための通信制御プロセッサと
、通信制御プロセッサによって実行される情報配信プロ
グラム、及び、情報提供装置から予め受信しておいた情
報を格納するためのメモリ手段とから構成され、情報提
供装置から受信した情報が、各サービス端末からの問合
せに応じて配信すべき情報を追い越して配信されること
を防止するための追越し配信防止手段を備える。

具体的には、追越し配信防止手段は、各サービス端末か
らの問合せに応じて、該サービス端末に配信すべき情報
のメモリ手段上のアドレスとデータ長とを順次格納する
ための複数の応答送信キューと、情報提供装置からの最
新の提供情報の受信に応じて該最新の提供情報に更新す
べき情報を表示中のサービス端末に送信するため、最新
の提供情報が格納されるメモリ上のアドレスと最新の提
供情報のデータ長とを格納するための一斉送信キューと
を備えており、通信制御プロセッサは、失透信キューに
最新の提供情報が格納されるメモリ上のアドレスと最新
の提供情報のデータ長とを格納するときに、−失透信キ
ューの上記メモリ手股上のアドレスを上記応答送信キュ
ーに格納しておき、通信制御部から送信バッファが空き
状態である旨の通知に応じて、送信バッファに対応する
サービス端末に、該サービス端末に対応する最先の上記
問合せ応答送信キューの内容に応じた情報を配送制御す
るようにする。

また、追越し配信防止手段の別の態様としては。

各サービス端末からの問合せ、あるいは、情報提供装置
からの最新の提供情報の受信に応じて、順次登録番号を
発生する登録番号発生手段と、各サービス端末からの問
合せに応じて、該サービス端末に配信すべき情報のメモ
リ手段上のアドレスとデータ長と登録番号発生手段から
通知される第１の登録番号とを順次登録するための複数
の応答送信キューと、情報提供装置からの最新の提供情
報の受信に応じて該最新の提供情報に更新すべき情報を
表示中のサービス端末に送信するため、最新の提供情報
が格納されるメモリ上のアドレスと最新の提供情報のデ
ータ長と上記登録番号発生手段から通信される第２の登
録順番号とを格納するための一斉送信キューとを備え、
情報配信制御プロセッサが、通知制御部から送信バッフ
ァが空き状態である旨の通知に応じて、送信バッファに
対応するサービス端末の問合せ応答送信キュー内の上記
第１の登録番号と一斉送信キュー内の上記第２の登録番
号とを比較し、最先の登録番号を含む送信キューの内容
に応じた情報を配送制御する。

〔作用〕

本発明の情報配信制御装置によれば、上述した追越し配
信防止手段を備えるため、情報提供装置から受信した情
報が、各サービス端末からの問合せに応じて配信すべき
情報を追い越して配信されることを防止することができ
る。

また、一斉送信キューに最新の提供情報が格納されるメ
モリ上のアドレスと最新の提供情報のデータ長とを格納
するとともに、上記応答送信キューに一斉送信キューの
メモリ上のアドレスを格納するときに、一斉送信キュー
の内容のすべてを一緒に格納することが、後のプロセッ
サの負荷などの面では望ましいが、メモリの節約等を考
慮すれば、少なくとも、一斉送信キューのメモリ上のア
ドレスと次に送信すべきサービス情報に関する応答送信
キューのメモリ上のアドレス（ポインタ）とを格納する
こともできる。もっとも、上述した登録番号発生手段を
つかえば、メモリ節約等の問題はおのずと解消できる。

また、サービス情報を送るべき端末が少ない場合、上述
したアドレス管理は、プロセッサにとって過負荷となる
。従って、そのような過負荷を軽減するために、例えば
サービス情報を送るべき端末が１つの場合には、そのサ
ービス情報が一斉送信サービスをおこなうべきものであ
っても、そのサービス情報のメモリ上のアドレス等の登
録には応答送信キューを用いることもできる。また、こ
のような応答送信キューのみを用いる場合と、一斉送信
キューと応答送信キューとを併用する場合とを判断する
ために、所定の計数式を用いるようにすれば、プロセッ
サの過負荷を最小限にする柔軟な配信処理をおこなうこ
ともできる。

〔実施例〕

本発明の第１の実施例を第１図〜第１８図を用いて説明
する。

まず、実施例の詳細な説明に入る前に、本発明の概略を
第１図を用いて説明する。第１図は、第３１図と同様の
システム構成と状況において、本発明のメツセージ送信
制御方法を適用した時の処理のフローを示したものであ
り、端末４１がＡ社株価を、また、端末４２，４３．４
４がＡ社株価を、また、端末４２，４３．４４がＢ社の
株価を表示中の時に、リアルタイム情報収集装置２１、
及び、端末４２からほぼ同時に、最新株価情報とＡ社株
価問合せを受けた場合を想定してみる。

即ち、■リアルタイム情報収集装置はＡ社の最新株価（
＝￥１５００）情報を一斉送信処理タスク１０４に通信
管理モジュール経由で送信し、■−一斉信処理タスク１
０４は配信情報管理テーブル１１２内のＢ社株価を更新
し、０８社の株価表示中の端末４２，４３，４４に対し
て、最新株価を一斉送信するため制御ブロック１３１を
一斉送信キュー１２０に登録する。制御ブロックとは、
最新株価が格納された受信バッファ上のアドレスとその
データ長とからなる情報である。

この後、従来方法では通信管理モジュール１０１を起動
して、一斉送信処理に入るが１本発明では■一斉送信メ
ッセージの制御ブロック１３１のコピー等を含む子制御
ブロック１４１，１４２゜１４３を、送信先端末である
端末４２，４３゜４４ごとに作成し、それぞれを、端末
送信管理テーブル１１８の送信キューに登録した後、通
信管理モジュール１０１を起動する。

尚、子制御ブロックには、一斉送信キューに登録されて
いるコピー元の制御ブロック（親制御ブロックと呼ぶ）
へのポインタもセットされるが、その使用方法について
は、後述の実施例にて詳細に説明する。

子制御ブロック１４１，１４２，１４３には、一斉送信
メッセージ（即ち、Ｂ社最新株価）の配信情報管理テー
ブル１１２上のアドレスとメッセージ長等がセットされ
ており、起動された通信管理モジュールは、問合せ端末
送信キューに登録された子制御ブロックからメツセージ
のアドレスと長さを読み出し、逐次、通信制御装置に入
力してゆく。この時、第３１図と同様、端末４２の通信
制御装置内バッファが満杯であるとする。この場合、■
端末４３．４４に対して一斉送信が行われ、端末４１に
ついては、バッファが空くまで送信が延期されることに
なる。

バッファが空くまでの期間に■端末４２から、Ａ社の株
価問合せを問合せ応答処理タスク１０３が通信管理モジ
ュール経由で受信し、■端末状態管理テーブル１０９を
更新し、■Ａ社の株価を読み出し、■応答メツセージと
して端末４２の送信キューに応答メツセージの制御ブロ
ック１３０を登録して、通信管理モジュールを起動する
。

この時、端末４２の通信制御装置内バッファはまだ満杯
であり、メツセージは通信制御装置に入力されないもの
とする。

次に、通信管理モジュールが通信制御装置から端末４２
からの送信完了通知を受は取ると、満杯であったバッフ
ァに空きが生じたことになるので。

次のメツセージの送信処理を行うが、従来の様に端末送
信キュー１１８と一斉送信キュー１２０の両方をチエツ
クせず、端末送信キューのみをチエツクする。第１図の
場合、端末送信キュー１１８の先頭に登録されているの
は、一斉送信メッセージ（＝Ｂ社最新株価）の子制御ブ
ロックであり、その次に応答メツセージ（＝ＡＡ社新株
価）の制御ブロックが登録されている。よって、［相］
一斉送信メッセージが先に通信制御装置内のバッファに
入力され、その後、応答メツセージ１１がバッファに入
力されることになり、従来のようなメツセージの追越し
は発生しない、また、その結果、端末４２では問合せ以
前に表示されていたＢ社の最新株価が表示された後、問
合せたＡ社の最新株価が先に表示され、従来のように端
末利用者がＡ社の株価情報を失ってしまうという問題は
発生しない。

次に、本発明の詳細な実施例を示す。上述した実施例で
は、処理内容を株式市況情報の株価自動配信サービスに
限定したが、本発明は一般的な情報自動配信サービスシ
ステムにも適用しうることは明らかである。

以下、本発明を適用する情報自動配信サービスシステム
の詳細について説明する。

第２図は１本実施例のシステム全体構成を示す図であり
、リアルタイム情報収集装置２１、及び。

複数の端末４１，４２，４３．４４が、それぞれ回！１
１，３１，３２，３３．３４によって情報処理装置１に
接続されている。

情報処理装！１は、第３図に示すように、ＣＰＵ５１、
メモリ（ＭＭ）５２．リアルタイム情報収集装置や端末
への回線を制御する通信制御装置（ＣＣＵ）５３，５４
、そして、上記ＣＰＵ。

ＭＭ、ＣＣＵを接続するバス５５から構成される。

第４図は、上記情報処理装置内のメモリ５２の中に格納
されているソフトウェアの論理的な構成を示した図であ
る。ソフトウェアの機能は、ＣＣＵの制御や各種処理タ
スクの実行管理等を行うスーパバイザ１００と、上記通
信管理モジュール１０１内にあって、ＣＣＵへの受信バ
ッファのアドレス通知や回線種類に応じて予め登録され
た処理タスクの起動処理を行う受信処理モジュール１０
２と、端末からの問合せメツセージを受信バッファ１０
６から取り込み、要求のあった情報について、最新情報
を配信情報管理テーブル１１２から読み出して端末に応
答する問合せ応答処理タスク１０３と。

リアルタイム情報収集装置から送られてくるメツセージ
を受信バッファ１０６から取り込み、配信情報管理テー
ブル１１２に格納するとともに最新情報を当該情報表示
中の全端末に一斉送信する一斉送信処理タスク１０４と
、一斉送信処理タスク１０４に起動され、送信バッファ
１２１内のメツセージをＣＣＵ３３を介して順次各端末
に送出する送信処理モジュール１０５から構成されるこ
とを示している。

また、上記モジュールやタスク間には、受信メツセージ
キュー１０７と、受信メツセージ管理テーブル１０８と
、問合せ応答送信キュー１１７と端末送信管理テーブル
１１８と、一斉送信キュー１１９と一斉送信キュー管理
テーブル１２０とが設けられている。

これら各キューには、受信メツセージ、及び、送信メツ
セージの受信バッファ１０６内の格納アドレスとメッセ
ージ長をセットした制御ブロックがＦＩＦ○（先入れ先
出し方式）で登録される。

また、問合せ応答送信キュー１１７には一斉送信キュー
１１９に登録されている制御ブロックのコピーである子
制御ブロックも登録される。

さらに、一斉送信先端末グループを管理するための端末
グループ管理テーブル１１０、各端末グループことにグ
ループに属する端末の端末番号を登録する端末登録キュ
ー１１１、端末ごとに表示中情報の種類を記憶する端末
状態管理テーブル１ｏ９．受信バッファ内、及び、送信
バッファ内の未使用ブロックに対応した制御ブロックを
登録する空き受信バッファキュー１１４と空き送信ノベ
ッファキュ−１１５、及び、未使用の子制御ブロックを
登録する空き子制御ブロックキュー１１６、及びそれら
を管理するための空きバツプア管理テーブル１１３が設
けられている。

以上に示したモジュールやタスク、及び、テーブルやキ
ューについて、詳細に説明する。

まず、受信処理モジュール１０２は、メツセージが端末
等からＣＣＵを介して受信バッファ１０６内に転送され
た時点でスーパバイザ１００によって起動される。

受信メツセージ格納用の空き受信バッファを確保するた
め、空き受信バッファキュー１１４から制御ブロックを
取だし、制御ブロックで指定される空きバッファのアド
レスを通信制御装置５３゜５４に通知した後、今受信し
たメツセージのメッセージ長を、当該受信バッファの制
御ブロックとしてセットし、回線の種類に応じて、受信
メツセージキュー１０７に登録するとともに、処理タス
クを起動する。

本実施例では、リアルタイム情報収集装置２１から回線
１１を経由してメツセージを受信した場合は、一斉送信
処理タスク１０４を、また、端末４１・・・４４から回
線３１・・・３４を経由してメツセージを受信した場合
は、問合せ応答処理タスク１０３を起動するようにして
おくものとする。

次に、問合せ応答処理タスク１０３の処理フローを第５
図を用いて説明する。

本タスクは上記受信処理モジュール１０２によって起動
されると、受信キュー１０７をチエツクし、受信メツセ
ージの制御ブロックが登録されているか否かを調べ（処
理２０１）、！録されていなければ処理を終了する。制
御ブロックが登録されていれば、制御ブロックにセット
されているアドレスとメッセージ長に基づき、受信バッ
ファ１０６から受信メツセージ（端末からの問合せメツ
セージ）を取り出す（処理２０２）。

ここで、端末からの問合せメツセージは、第６図に示す
如く、メッセージ長（Ｌ）３０１．端末番号（ＴＭ’Ｎ
０）３０２．端末が要求している情報の識別子（ＩＮＱ
ｊＮＦｊＤ　：以後問合せ情報識別子と呼ぶ）３０３か
らなっている。

次に、上記問合せメツセージにセットされている端末番
号に基づいて端末状態管理テーブル（第４図１０９）を
アクセスし、当該端末の状態をチニックする（処理２０
３）。

第７図は、＠束状態管理テーブル１０９の構成を示した
図であり、端末番号に対応じてエントリー３１１，３１
２，３１３が設けられている。各エントリーには、当該
端末が最後に問合せた情報（＝現在、その端末が表示中
の情報）の識別子（情報ＩＤ）、及び、当該端末が属す
る端末グループのＩＤが、それぞれ格納されている。

まず、受信した問合せメツセージに含まれる問合せ情報
識別子ＩＮＱＪＮＦ　ＩＤと該当する端末番号に対応じ
て格納されている情報ＩＤとが一致するか否かをチエツ
クする（処理２０４）。一致しない場合は、前回の問合
せと異なる情報を端末が要求していることを意味する。

よって、該当するエントリーの端末グループＩＤを、受
信した情報に対応する端末グループＩＤ（こ変更する必
要がある。

そこで、端末状態管理テーブルの端末グループＩＤ３２
２を削除する。次に、問合せ情報識別子に対応した端末
グループを登録するため、配信情報管理テーブル（第４
図１１２）をアクセスする。

二こで、配信情報管理テーブルは第８図に示すごとく、
情報識別子（ＩＮＦＪＤ）ごとにエントリー３３１．３
３２，３３３が設けられている。また、各エントリーに
は、第９図に示す様に、当該情報のサイズ３４１．最新
情報３４２、そして、当該情報を表示中の端末グループ
の識別子を示す端末グループＩＤ３４３が、そ九ぞれ格
納されている。

この配信情報管理テーブル１１２を参照し、問合せ情報
識別子に対応したエントリーの端末グループＩＤ（＝新
たに属すべき端末グループのＩＤ。

以後、新端末グループＩＤと呼ぶ）、と対応する端末グ
ループ管理テーブル１１１上の登録端末数に１を加算し
、対応する端末登録キュー１１１に受信フレームに含ま
れていた端末番号３０２を登録する。

また端末状態管理テーブルの情報ＩＤ３２］と端末グル
ープＩＤ３２２を、それぞれ問合せ情報識別子と新らた
な端末グループＩＤの値に変更する（処理２０５）。

端末グループの登録、及び、登録削除処理は、具体的に
は端末グループ管理テーブル（第４図１１０）の更新処
理である。

第１０図に、端末グループ管理テーブル１１０の構成を
示す。本テーブルは端末グループよりごとにエントリー
３５１，３５２，３５３が設けられ、各エントリーには
、端末登録キュー（第４図１１１）へのポインタ３５４
と登録端末数３５５とがセットされている。端末登録キ
ューは当該端末グループに属する端末の端末番号（ＴＭ
ＮＯ）をセットしたブロック３５６・・・３６１の双方
向リストになっている。

端末グループへの登録／削除とは、この端末登録キュー
への登録／削除と登録端末数（３５５等）の加算（＋１
）／減算（−１）を行うことである。

尚、上記処理２０４において、問合せメツセージ内の問
合せ情報識別子（ＩＮＱｊＮＦＪＤ）と情報ＩＤが一致
する場合は、前回と同一の情報の問合せであり、上記端
末グループの登録変更処理２０５は不要である。

次に配信情報管理テーブル１１２より、情報識別子（Ｉ
ＮＱ　ＩＮＦ　ＩＤ）で指定されるエントリーの最新情
報を読みだし、端末への応答メツセージに編集するとと
もに（処理２０６）、空き送信バッファキュー（第４図
１１５）からメツセージ制御ブロック（ｍｃｂ　：　ｍ
ｅｓｓａｇｅ　ｃｏｎｔｒｏｌ　ｂｌｏｃｋ）を確保し
。

応答メツセージを上記確保した制御ブロックに対応する
送信バッファに転送する（処理２０７）。

ここで、１Ｉｌｃｂの構成、及び、応答メツセージのフ
ォーマットを第１１図、及び、第１２図に示す。

ｍｃｂはキューの次ぎのｍｃｂへのポインタ３７１、後
述する親ｃａｂへのポインタ３７２、キューの前のｌｌ
１ｃｂへのポインタ３７３．当該ｌｌ１ｃｂに対応づけ
られた送信メツセージのアドレス３７４とメッセージ長
３７５、そして、後述する送信先端末数３７６をそれぞ
れセットするフィールドから構成される。また、応答メ
ツセージは、メッセージ長（Ｌ）、及び、データ本体（
ＤＡＴＡ）をそれぞれセットするエリア３７７と３７８
とからなる。

処理２０７で確保したＩＩｃｂについて、フィールド３
７５に応答メツセージのサイズをセットした後（処理２
０Ｂ）、ｍｃｂを送信先端末番号に対応した問合せ応答
送信キューに登録する（処理２０９）。

ここで、問合せ応答送信キューは、第１３図に示すよう
に、端末送信管理テーブル１１８を参照することによっ
て管理されている。端末送信管理テーブルには端末番号
ごとに設けられたエントリー３８１，３８２，３８３が
あり、各エントリーは、問合せ応答送信キューポインタ
、次にＣＣＵへの送信処理を行うべき１Ｉｃｂをポイン
トするサービスポインタ、端末の物理アドレスをそれぞ
れセットするフィールド３８４，３８５，３８６から構
成される。

また、問合せ応答送信キューには例えば第１３図のよう
にｗｅｂ　３８７・・・３９６が登録される。上記処理
２０９でのｍｅｂ登録処理は、送信先端末の端末番号に
対応した問合せ応答送信キューの最後尾にｉｃｂを接続
する処理である。

次に１層ｃｂの登録の後、サービスポインタがリセット
状態か否かをチエツクする（処理２１０）。

もしリセット状態であれば、サービスポインタのポイン
ト先を今登録した■ｃｂにしく処理２１１）、送信処理
モジュール１０５を起動して（処理２１２）、再び処理
２０１に戻る。また、処理２１０でサービスポインタが
セット状態ならばサービスポインタの更新処理を行わず
、処理２１２を行う。以上の問合せ応答処理タスクの処
理により、端末からの問合せに対して、その時点で最新
の情報が問合せ応答キューに登録されることになる。

次に、第１４図を用いて上記一斉送信処理タスクの処理
フローを説明する。本タスクは上記受信処理モジュール
１０２によって起動されると、受信キュー１０７をチエ
ツクし、受信メツセージの制御ブロックが登録されてい
るか否かを調べ（処理４０１）、登録されていなければ
処理を終了する。制御ブロックが登録されていれば、制
御ブロックにセットされているアドレスとメッセージ長
に基づき、リアルタイム情報収集装置からの受信メツセ
ージを受信バッファ１０６から取り出す（処理４０２）
。ここで、リアルタイム情報収集装置からのメツセージ
は第１５図に示すフォーマットになっており、メッセー
ジ長（Ｌ）をセットするエリア４２１、情報の種類を識
別するための情報識別子（ＩＮＦｊＤ）をセットするエ
リア４２２、そして、情報の内容データ（ＤＡＴＡ）を
セットするエリア４２３からなっている。

次に、一斉送信処理タスクは、この受信メツセージをそ
の情報識別子に対応した配信情報管理テーブル１１２の
エントリー内の最新情報エリア（第９図３４２）に格納
し、情報サイズ（第９図３４１）にデータ長をセットす
る（処理４０３）。

以上の処理により、配信情報管理テーブル１１２には常
に最新の情報が格納されていることになる。

次に、配信情報管理テーブル内の端末グループＩＤ（第
９図３４３）で指定される端末グループについて端末グ
ループ管理テーブル１１０をアクセスし、登録端末数（
第１０図３５５）を参照して、当該情報を表示中の端末
が存在するか否かをチエツクする（処理４０４）、登録
端末数が０の場合は、当該情報の配信は不要であり、次
の受信メツセージの処理のため処理４０１に戻る。また
、登録端末があれば、当該端末グループに対して全受信
した最新情報を一斉に配信する必要があり、配信情報管
理テーブル１１２から、最新情報を読み出して端末グル
ープへの一斉送信メッセージに編集するとともに（処理
４０５）、空き送信バッファキュー１１５からメツセー
ジ制御ブロック（＋ｃｂ　：　ｍｅｓｓａｇｅ　ｃｏｎ
ｔｒｏｌ　ｂｌｏｃｋ）を確保し、上記編集した一斉送
信メッセージを送信バッファに転送する（処理４０６）
、ここで一斉送信メッセージのフォーマットは上述の応
答メツセージと同様である（第１２図参照）。

次に上記確保したｍｃｂについて、一斉送信メッセージ
のサイズをセットするとともに、メツセージ送信先端末
グループの端末数を送信先端末数のフィールド（第１１
図３７６）にセットしく処理４０７）、一斉送信キュー
にｗｅｂを登録する（処理４０８）。ここで、一斉送信
キュー１１９は、第１３図に示すように、一斉送信処理
テーブル１２０によって管理されるキューであり、端末
群対して一つ設けるキューである。

この一斉送信キューにｍｃｂを登録する場合は。

双方向リストにて接続する。これは、一斉送信完了時に
ｌ１ｌＣｂを取り出す順番が、必ずしも、キューへの登
録順と一致しないためである。

次に、送信先端末グループについて、端数グループ管理
テーブル１１０の端末登録キュー１１１より、順次、登
録端末の番号を読みだしく処理４０９）、子制御ブロッ
ク（以後子■ｃｂと呼ぶ）を上記空き子制御ブロックキ
ュー（第４図１１６）から確保して、上記一斉送信キュ
ーに登録した鳳ｃｂ　　（以降親ＩＩＣｂと呼ぶ）の内
容をコピーし、さらに、親ｗｅｂのアドレスをフィール
ド３７２にセットしく処理４１０）、上記端末グループ
管理テーブルから読みだした端末番号で指定される問合
せ応答送信キューに登録する（処理４１１）。次に、当
該問合せ応答送信キューのサービスポインタをチエツク
し、リセット状態の場合のみ、登録した子ｍｃｂにサー
ビスポインタをセットする（処理４１２，４１３）。

次に、上記端末グループ管理テーブルの端末登録キュー
に次の端末が登録されているか否かをチエツクしく処理
４１４）、登録されていれば処理４０９〜４１３を行う
。登録されていなければ、送信処理モジュール１０５を
起動しく処理４１５）、処理４０１に戻る。

以上の一斉送信処理タスクの処理により、ある情報につ
いて更新が発生した場合、最新メツセージが当該情報を
表示中の端末の問合せ応答送信キューに登録されること
になる。

最後に、第１６図〜第１８図を用いて送信処理モジュー
ル１０５の処理フローを説明する。送信処理モジュール
の起動要因としては、問合せ応答処理タスク、或いは、
一斉送信処理タスクからの送信要求発生、及び、ＣＣＵ
からのメツセージ送信完了通知受信がある。尚、起動要
因やその他のパラメータの受は渡しはスーパバイザが行
うものとする。

送信処理モジュールが起動されると、先ず起動要因を調
べる（処理４３１）。起動要因が送信完了の場合は後述
する送信完了処理（第１８図）を実行しく処理４４０）
、処理を終了する。起動要因が送信要求の場合、まず端
末番号を表す作業変数ｉを初期化しく処理４３２）、次
に、端末番号＝ｉの問合せ応答送信キューについて、サ
ービスポインタがセットされているか否かをチエツクす
る（処理４３３）。

もし、サービスポインタがリセット状態であり、送信す
べきメツセージがなければ、処理４３５に進む。サービ
スポインタがセット状態であれば、当該端末について、
後述する問合せ応答送信キュー送信処理（第１７図処理
４３４）を端末番号を引数として実行した後、すべての
端末について送信処理を終えたか否かをチエツクする（
処理４３５）。

終えていれば処理を終了する。また、終えていなければ
、作業変数ｉを更新しく処理４３６）、処理４３４に戻
る。

次に、第１７図を用いて、問合せ応答送信キュー送信処
理について説明する。

先ず、引数の端末番号で指定される端末の問合せ応答送
信キューをアクセスし、サービスポインタのポイント先
のＩＩｃｂで指定される送信メツセージについて、ＣＣ
Ｕに送信要求を発行する（処理４５１）。ここで、ＣＣ
Ｕへの送信要求とは、送信先端末の端末物理アドレス（
第１３図３８６）、送信メツセージのアドレスとメッセ
ージ長をＣＣＵに通知する処理である。

次に、要求の結果をチエツクしく処理４５２）、ＣＣＵ
がビジーであり、送信要求が拒否された場合は、サービ
スポインタを当該＋ｌｃｂにセットしく処理４５５）、
メインルーチンにリタンする。

ＣＣＵがビジーでなく送信要求が受は付けられた場合は
、問合せ応答送信キューに次のｌｌ１ｃｂが登録されて
いるか否かをチエツクする（処理４５３）。

もし次ｆｉＩｃｂがあれば、再び処理４５１に戻る。次
＋ｍｃｂがなければ、当該問合せ応答送信キューに登録
されたメツセージをすべて回線に送出したことになり、
サービスポインタをリセットしく処理４５５）、メイン
ルーチンにリタンする。

次に第１８図を用いて、送信完了処理（第１６図処理４
４０）の処理フローを説明する。まず、送信完了した端
末の問合せ応答送信キューについて、先頭のｗｅｂ（＝
送信完了したメツセージに対応したｍｃｂ）にアクセス
し、それが子ｍｃｂが否かをチエツクする（処理４６１
）。

親ｍｃｂへのポインタ（第１１図、３７２）がセットさ
れていれば子ｌｌ１ｃｂである。

もし、問合せ応答送信キューが子ｌｌ１ｃｂでない場合
は、問合せ応答送信キューから当該ｍｃｂを取り出しく
処理４６７）、空き送信バッファキューに返却しく処理
４６８）、処理４６９に進む。もし子ｗｅｂであれば、
一斉送信キューに登録されている親ｍｃｂポインタをア
クセスし、その送信先端末数（第１１図、３７６）を減
算（−１）Ｌ、た後（処理４６２）、送信先端末数がＯ
か否かをチエツクする（処理４６３）。Ｏの場合は、当
該端末も含めて送信先端末グループのすべてについて送
信が完了したことを意味する。したがって、一斉送信キ
ューからＭｒｒｒＣｂを取り出しく処理４６４）、親ｍ
ｃｂと子ｗｅｂをそれぞれ、空き送信バッファキュー１
１５と空き子制御ブロックキュー１１６に返却しく処理
４６５）、処理４６９に進む。処理４６３で送信先端末
数が０より大の場合は、子ｍｃｂを問合せ応答送信キュ
ーから取り呂して空き子制御ブロックキュー１１６に返
却しく処理４６６）、処理４６９に進む。

処理４６９では、送信完了した端末の問合せ応答送信キ
ューのサービスポインタの状態をチエツクする。サービ
スポインタがリセット状態であり、送信すべきメツセー
ジがない場合はメインルーチンにリタンする。また、サ
ービスポインタがセットされていわば、前述の問合せ応
育送信キュー送信処理（第１７図参照）を実行した後（
処理４７０）、メインルーチンにリタンする。

以上の一斉送信処理タスクにおけるメツセージ一斉送信
処理、及び、送信処理モジュールによれば、一斉送信に
おいて、送信メツセージを送信先端末ごとにコピー作成
せず、制御ブロックであるｗｅｂのみのコピーで済むた
め、処理のオーバヘッドを低く抑えることができる。ま
た、各端末ごとに見ると、一斉送信メッセージの子ｍｃ
ｂと、問合せ応答メツセージのｌ１ｃｂが一つの送信キ
ューに登録され、送信処理モジュールが順次ｍｃｂの登
録順にメツセージを端末に送信してゆくことになる。

これにより、一斉送信メッセージと問合せ応答メツセー
ジとの間で、キューの登録順と回線への送出順が食い違
う、メツセージの追越しの問題は発生しない。

次に、第２の実施例について説明する。

第１の実施例の一斉送信処理においては、送信先端末数
が多い場合、或いは、一斉送信の頻度が高くなった場合
、子ｎ＋ｃｂ生成のために必要となるメモリ容量も増大
する。そこで、子ｍｃｂを第１の実施例のように親ｍｃ
ｂと同一サイズにせず、必要最小限の情報のみを子ｌｌ
１ｃｂに設定することにより、子ｍｃｂ生成に必要とな
るメモリ容量を減らす方法が考えられる。即ち、子ｌｌ
１ｃｂを第１９図に示すように、問合せ応答送信キュー
の次１ｏｃｂへのポインタ５０１と親ｗｅｂへのポイン
タ５０２のみから構成する。一斉送信処理タスクの処理
フロー（第１４図）は第１の実施例と同様であるが、送
信処理モジュールの処理フロー（第１６図）における問
合せ応答送信キュー送信処理（処理４３４）を以下のよ
うに変更する。

即ち、問合せ応答送信キュー送信処理については、その
処理フロー（第１７図）のＣＣＵ送信処理（処理４５１
）において、サービスポインタが指すｍｃｂが子ｌ１ｃ
ｂか否かをチエツクし、子ｍｃｂならば、一斉送信キュ
ーの親ｍｃｂ　をアクセスして、送信メツセージのアド
レスとサイズを取り出し、ＣＣＵに送信要求する。また
子！１ｌｃｂでない場合は、第１の実施例と同様、サー
ビスポインタが指すｍｃｂにセットされた送信メツセー
ジのアドレスとサイズに基づいてＣＣＵに送信要求を発
行する。

次に、一斉送信メッセージのｍｃｂのコピーを用いない
第３の実施例について説明する。

第１の実施例では、一斉送信メッセージと問合せ応答メ
ツセージを正しく順序で端末に送信するため、一斉送信
メッセージのｗｅｂのコピー（子ｗｅｂ）を問合せ応答
送信キューに登録する方法をとった。

これに対し本第３の実施例では、子！ｌ１ｃｂを用いな
い方法を示す。

まず、基本的な考え方を示す。第２０図に示すように問
合せ応答送信処理と一斉送信処理とで共通にアクセス、
更新する送信要求通番６０１を設ける。各送信処理にお
いては、送信要求通番６０１をインクリメント（＋１）
した後、更新後の送信要求通番の値を送信メソセージの
ｍｃｂにセットするとともに、問合せ応答の場合は問合
せ応答送信キューに、また、一斉送信の場合は一斉送信
キューにそれぞれ、要求通番をセットしたｗｅｂを登録
してゆく。送信処理モジュール１０５は、各端末ごとの
送信処理において、問合せ応答送信キューと一斉送信キ
ューそれぞれの先端に登録されているｍｃｂの送信要求
通番を比較し、番号の小さい方、即ち、先に送信要求を
行った方について、メツセージをＣＣＵに入力する。こ
れにより、メツセージの追越しの問題を防ぐことができ
る。

第２１図は第３の実施例における問合せ応答処理タスク
の処理フローであり、処理７０１〜処理７０７は第１の
実施例第５図の処理２０１〜処理２０７と同じである。

処理７Ｑ８では、送信要求通番６０１を更新しく＋１す
る）、確保したｍｃｂにメッセージ長と更新後の送信要
求通番をセットする（処理７０９）。ここでｍｃｂは第
２２図に示す如く、次ｍｃｂへのポインタ、前ｗｅｂへ
のポインタ、メツセージアドレス、メツセージ長、送信
要求通番、送信先端末数、そして、後述の一斉送信処理
で使用する送信先ビットリスト８０８へのポインタ、を
それぞれセットするフィールド８０１゜８０２．８０３
，８０４，８０５，８０６、及び、８０７から構成され
る。処理７１０〜処理７１３は第１の実施例第５図の処
理２０９〜処理２１２と同じである（但し、本実施例で
は後述する一斉送信キューのサービスポインタと区別す
るため、問合せ応答送信キューのサービスポインタを問
合せ応答送信キューサービスポインタ′″と呼ぶ）。

次に、第２３図を用いて一斉送信処理タスクの処理フロ
ーを説明する。処理９０１〜処理９０６は第１の実施例
第１４図の処理４０１〜処理４０６と同しである。処理
９０７で送信要求通番６０１を更新しく＋１する）、確
保した１１１ｃｂにメツセージサイズ、送信先端末数、
及び、更新後の送信要求通番をセントするとともに、送
信先端末ビットリストエリアを確保してそのアドレスを
ｍｃｂのフィールド８０７にセントする。（処理９０８
）。

ここで送信先ビットリストとは、第２２図８０８に示す
ように、全端末数ビット分のサイズをもつデータであり
、端末番号に対応したビットのＯＮ／○ＦＦよって一斉
送信先の指定を行うものである。処理９０９，９１０は
第１の実施例第１４図の処理４０８〜処理４０９と同じ
である。処理９１１では、上記送信先端末ビットリスト
について、端未登録キューから読みだした端末番号に対
応するビット位置をＯＮにする処理を行う。

次に端未登録キューから読みだした端末番号に対応した
端末送信管理テーブルについて、一斉送信キューサービ
スポインタ（第２０図６１２）をチエツクする（処理９
１２）。ここで一斉送信キューサービスポインタとは、
第２０図に示すように、端末送信管理テーブルの各エン
トリーごとに設けられ、一斉送信キューの中で次しこＣ
ＣＵに送信要求ｍｃｂ　をポイントするものである。

一斉送信キューサービスポインタがυセント状態であれ
ば、一斉送信キューサービスポインタのポイント先を今
登録したｍｃｂにしく処理９１３）、処理９１４に進む
。また、処理９１２で一斉送信キューサービスポインタ
がセント状態ならばポインタの更新処理を行わず、処理
９１４を行う。処理９１４〜処理９１５は第１の実施例
第１４図の処理４１４〜処理４１５と同じである。

最後に、第２４図〜第２８図を用いて送信処理モジュー
ルの処理フローを説明する。第２４図は送信処理モジュ
ールのメインルーチンの処理フローである。送信処理モ
ジュールは起動されると、先ず起動要因を調へる（処理
１００１）。起動要因が送信完了の場合は後述する送信
完了処理（第２８図）を実行しく処理１００６）、処理
を終了する。起動要因が送信要求の場合、まず端末番号
を表す作業変数１を初期化しく処理１００２）、次に、
端末番号＝ｉの端末について、後述する端未送信処理（
第２５図）を端末番号を引数として実行した後（処理１
００３）、すべての端末について送信処理を終えたか否
かをチエツクする（処理１００４）。終えてれば処理を
終了する。また終えていなければ、作業変数ｉを更新し
く処理１００５）、処理１００３　ニ戻る。

次に、第２５図を用いて、端末送信処理について説明す
る。

先ず、引数の端末番号で指定される端末について、問合
せ応答送信キューサービスポインタと一斉送信キューサ
ービスポインタの状態をチエツクする（処理１１０１）
。チエツクの結果２問合せ応答送信キューサービスポイ
ンタのみセット状態の場合は第１の実施例第１７図で処
理フローを示した問合せ応答送信キュー送信処理を端末
番号を引数として実行しく処理１１０２）、メインルー
チンにリタンする。処理１１０１のチエツクの結果、一
斉送信キューサービスポインタのみセット状態の場合は
、後述する一斉送信キュー送信処理（第２６図）を端末
番号を引数として実行しく処理１１０３）、メインルー
チンにリタンする。処理１１０１のチエツクの結果、問
合せ応答送信キューサービスポインタ、及び、一斉送信
キューサービスポインタの両方がセット状態の場合は、
後述する問合せ応答／一斉送信キュー送信処理（第２７
図）を端末番号を引数として実行しく処理１１０４）、
メインルーチンにリタンする。そして、処理１１０１の
チエツクの結果、問合せ応答送信キューサービスポイン
タ、及び、一斉送信キューサービスポインタの両方とも
にリセット状態の場合は、即メインルーチンにリタンす
る。

次に、第２６図を用いて、上記一斉送信キュー送信処理
を説明する。

先ず、引数の端末番号で指定される端末送信管理テーブ
ルをアクセスし、一斉送信キューサービスポインタのポ
イント先のｍｅｂで指定される送信メツセージについて
ＣＣＵに送信要求を発行しく処理１２０１）、結果をチ
エツクする（処理１２０２）。もし、ＣＣＵがビジーで
あり、送信要求が拒否された場合は、一斉送信キューサ
ービスポインタを当該ｍｃｂにセットしく処理１２０７
）。

メインルーチンにリタンする。ＣＣＵがビジーでなく送
信要求が受は付けられた場合は、一斉送信キューに次の
醜ｃｂが登録されているか否かをチエツクする（処理１
２０３）。もし次ｍｃｂがあれば、その送信先端末ビッ
トリストにアクセスし、当該端末が送信先に指定されて
いるＩＩｃｂかどうか調べ（処理１２０４．１２０５）
、もし指定されていれば、処理１２ｏ１にもどる。また
、指定されていれば処理１２０３に戻る。処理１２０３
で次ｌ１ｃｂがなければ一斉送信キューサービスポイン
タをリセットしく処理１２０６）、メインルーチンにリ
タンする。

次に、第２７図を用いて、上記問合せ応答／一斉送信キ
ュー送信処理を説明する。先ず、引数の端末番号で指定
される端末送信管理テーブルをアクセスし、問合せ応答
キューサービスポインタのポイント先ｌ１ｃｂと一斉送
信キューサービスポインタのポイント先ｎ＋ｃｂについ
て、それぞれにセットされている送信要求通番を比較す
る（処理１３０１）。

問合せ応答送信キューサービスポインタの指すｍｃｂの
方がホさい場合は、ｍｃｂで指定される送信メツセージ
についてＣＣＵに送信要求を発行しその結果を真べる（
処理１３０２．１３０３）。もし、ＣＣＵがビジーであ
り、送信要求が拒否された場合は、問合せ応答送信キュ
ーサービスポインタを当該ｍｃｂにセットしく処理１３
０７）、メインルーチンにリタンする。ＣＣＵがビジー
でなく送信要求が受は付けら九た場合は１問合せ応答送
信キューに次のＩＩＩｃｂが登録されているが否がをチ
エツクする（処理１３０４）。もし次ｗｅｂがあれば、
処理１３０１に戻る。次ｌ１ｃｂがない場合は、指定さ
れていなければ問合せ応答送信キューサービスポインタ
をリセットしく処理１３０５）、前述の一斉送信キュー
送信処理を実行して（処理１３０６）メインルーチンに
リタンする。

次に上記処理１３ｏ１で一斉送信キューサービスポイン
タの指す■ｃｂの方が、送信要求通番が小さい場合は、
一斉送信キューサービスポインタのポイント先のｗｅｂ
で指定される指信メツセージについてＣＣＵに送信要求
を発行し、その結果をチエツクする（処理１３０８，１
３０９）。もし、ＣＣＵがビジーであり、送信要求が拒
否された場合は、一斉送信キューサービスポインタを当
該ｗｅｂにセットしく処理１３０７）、メインルーチン
にリタンする。ＣＣＵがビジーでなく送信要求が受は付
けられた場合は、一斉送信キューに次のｗｅｂが登録さ
れているか否かをチエツクする（処理１３１０）。もし
次ＩＩＣｂがあれば、その送信先端末ビットリストにア
クセスし、当該端末が送信先に指定されているｍｃｂか
どうかを調べ（処理１１１１．１３１２）、指定されて
いれば、処理１３０１にもどり、指定されていなければ
処理１３１０　ニ戻る。また、処理１３１０で次ｍｃｂ
がない場合は一斉送信キューサービスポインタをリセッ
トしく処理１３１３）、前述の問合せ応答送信キュー送
信処理（第１７図）を実行しく処理１３１４）メインル
ーチンにリタンする。

次に第２８図を用いて、送信完了処理（第２４図処理１
００６）の処理フローを説明する。まず、送信完了した
メツセージのｍＣｂが問合せ応答送信キューのものか、
一斉送信キューのものかをチエツクする（スーパバイザ
が通知してくれるものとする）（処理１４０１）。問合
せ応答送信キューのｌ１ｃｂの場合は１問合せ応答送信
キューから当該ｍｃｂを取り出しく処理１４０５）、空
き送信バッファキューに返却して（処理１４０６）処理
１４０７に進む。

一斉送信キューの＠ｅｂの場合は、その送信先端末数（
第２２図、８０６）を減算（−１）した後（処理１４０
２）、送信先端末数がＯか否かをチエツクする（処理１
４０３）、もし０の場合は、当該端末も含めて送信先端
末グループのすべてについて送信が完了したことを意味
し、よって、一斉送信キューからｍｃｂを取り出しく処
理１４０４）、ｍｃｂを空き送信バッファキュー１１５
に返却して（処理１４０６）、処理１４０７に進む。も
し処理１４０３で送信先端末数がＯより大の場合は、処
理１４０７に進む。処理１４０７では、送信完了した端
末について、第２５図で処理フローを示した端末送信処
理を実行し、メインルーチンにリタンする。

以上に示した方法によれば、第一の実施例のように、送
信先端末数分のｍｃｂコピーが不要となり、その分メモ
リ容量を節約することができる。逆に、各端末ごとの送
信処理において、問合せ応答送信キューのｌ１ｃｂと、
一斉送信キューのｗｅｂとの間で、それぞれの送信要求
通番の比較処理が発生し、その分、第１の実施例に比べ
て処理のオーバヘッドが増加するというデメリットがあ
る。

次に、第４の実施例について説明する。

第１の実施例の一斉送信処理においては、送信先端末の
数が１つ場合、ｗｅｂを２つ作成しく親ｗｅｂと子−ｃ
ｂ）で一斉送信キューと問合せ応答送信キューにそれぞ
れを登録する必要があった。しかしながら、送信先端末
が１つの場合は、問合せ応答送信でメツセージを端末に
送信すれば、作成する■ｃｂの数も１つで済み、結果と
して、オーバヘッドも少なくなる。そこで、本第４の実
施例では、一斉送信処理において、送信先端末数が１つ
の場合は１問合せ応答送信キューへの登録を行う方法を
とることにする。

第２９図は、本実施例における一斉送信処理タスクの処
理フローである。処理１５０１〜処理１５０６は第１の
実施例第１４図の処理４００〜処理４０６と同一である
。処理１５０７では情報配信する端末グループの登録端
末数をチエツクし、もし２つ以上ならば、第１の実施例
と同一の処理を実行する（処理１５０９〜１５１７）。

また、登録端末数が１つの場合は端末グルー　管理テー
ブル（第１０図参照）から検索した端末番号、送信メツ
セージ長、処理１５０６で確保したｍｃｂと送信バッフ
ァアドレスを引き数として問合せ応答送信キュー登録処
理を実行しく処理１５０８）、処理１５１７に進む。

第３０図は、上記問合せ応答処理キュー登録処理の処理
フローを示した図である。まず、引き数で渡された鳳ｃ
ｂについて、第１１図のフィールド３７５に送信メツセ
ージのサイズをセットした後（処理１６０１）、引き数
の端末番号に対応した問合せ応答送信キューに登録する
（処理１６０２）。

次に、当該問合せ応答送信キューのサービスポインタが
リセット状態か否かをチエツクする（処理１６０３）。

もしセット状態であれば、メインルーチンにリタンする
。また、サービスポインタがリセット状態ならばサービ
スポインタを今登録したｍｃｂにセットしく処理１６０
４）、メインルーチンにリタンする。

次に、第５の実施例について説明する。

第４の実施例では、送信先端末数が１つか、或いは、２
つ以上かで問合せ応答送信にするか、大送信にするかを
判定した。これは、送信先端末が複数の場合に問合せ応
答送信を行うと、送信メツセージのコピーが発生し、そ
の分オーバヘッドが高くなるからである。しかしながら
、送信メツセージの長さが小さければ、送信先端末数が
２つ以上でも、問合せ応答送信処理の方が一斉送信よリ
オーバヘッドが小さくなる場合が考えられる。

そこで、第２９図の処理１５０７の代わりに、登録端末
数（＝送信先端末数）と送信メッセージ長に基づいて問
合せ応答送信にするか、一斉送信番ニするかを決定する
。送信方法決定ロジックとしては、例えば、送信先端末
数がｎ、送信セラセージ長がＳの場合の一斉送信、及び
、問合せ応答送信のオーバヘッドをそれぞれ、Ｔ（−大
送信）、及び、Ｔ（問合せ応答送信）を次の式で評価す
る。

Ｔ（−大送信）”　Ｔ　（ｍｃｂ）　＋　Ｔ　（子ｍｃ
ｂ）宰ｎ。

Ｔ（問合せ応答送信）　＝　Ｔ　（ｍｃｂ）　＊　ｎ　
＋　Ｔ　（ｍｓｃｐｏｙ）傘Ｓ申（ｎ−１）。

ここで、　Ｔ（ｍｃｂ）はｍｃｂを作成登録するのに要
する処理時間、Ｔ（子ｍｃｂ）は子ｍｃｂを作成登録す
るのに要する処理時間、Ｔ　（ｍｓｃｐｏｙ）は単位長
のメツセージコピーに要する処理時間であり、それぞれ
、前もって計測しておくものとする。次に、Ｔ（−大送
信）とＴ（問合せ応答送信）の比較を行し）、Ｔ（−大
送信）≦Ｔ（問合せ応答送信）の場合は一斉送信にし、 Ｔ（−大送信）〉Ｔ（問合せ応答送信）の場合は問合せ
応答送信とする。

〔発明の効果〕

本発明によれば、多数の端末に対する、問合せ応答処理
と一斉送信処理が混在するシステムにおいて、応答メツ
セージと一斉送信メッセージが正しい順番で端末側に送
信され、端末に対して高信頼な情報サービスを実現する
ことができる。また、端末側にとっては、メツセージの
順番誤り制御が不用となるので、その分端末側受信ソフ
トが簡単になり、システムのコストを低く押さえること
ができる。

【図面の簡単な説明】

第１図は、第１の実施例の概略を示す図、第２図は、情
報サービスシステムの全体構成図、第３図は、情報処理
装置の内部構成図、第４図は、情報処理装置内ソフトウ
ェアの論理構成図、第５図は、問合せ応答処理タスクの
処理フロー、第６図は、問合せメツセージのフォーマッ
ト、第７図は。 端末状態管理テーブルの構成図、第８図は、配信情報管
理テーブルの全体構成図、第９図は、配信情報管理テー
ブルの各エントリーの構成図、第１０図は、端末グルー
プ管理テーブルの構成図、第１１図はメツセージ制御ブ
ロックｍｃｂの構成図、第１２図は、応答メツセージ、
及び、一斉送信メノセージのフォーマント、第１３図は
、問合せ応答送信キューと一斉送信キューの構成図、第
１４図は、−大送信処理タスクの処理フロー、第１５図
は、リアルタイム情報収集装置からの受信メツセージの
フォーマット、第１６図は、送信処理モジュールの処理
フロー、第１７図は、問合せ応答送信キュー送信処理の
処理フロー、第１８図は。 送信完了処理の処理フロー、第１９図は第２の実施例に
おける子ｗｅｂの構成図、第２０図は、第３の実施例に
おける問合せ応答送信キューと一斉送信キューの構成図
、第２１図は、第３の実施例における問合せ応答処理タ
スクの処理フロー、第２２図は、第３の実施例における
ｍｃｂの構成図、第２３図は、第３の実施例における一
斉送信処理タスクの処理フロー、第２４図は、第３の実
施例における送信処理モジュールの処理フロー、第２５
図は、第３の実施例における端末送信処理の処理フロー
、第２６図は、第３の実施例における一斉送信キュー処
理の処理フロー、第２７図は、第３の実施例における問
合せ応答／一斉送信キュー送信処理の処理フロー、第２
８図は、第３の実施例における送信完了処理の処理フロ
ー、第２９図は、第４の実施例における一斉送信方法タ
スクの処理フロー、第３０図は、第４の実施例における
問合せ応答送信キュー登録処理の処理フロー第３１図は
、従来の一斉送信方法とその問題点の説明図である。 ｍｃｂ・・・メツセージ制御ブロック、ＴＭＮＯ・・端
末番号。 だ 小川勝男

Claims (1)

1. 【特許請求の範囲】 １、複数のサービス端末と、情報提供装置とが接続され
   、上記情報提供装置から受信した情報を、上記各サービ
   ス端末からの問合せ、または上記情報提供装置からの提
   供情報に応じて、各サービス端末に必要な提供情報を配
   信するための情報配信制御装置において、 上記情報配信制御装置は、各サービス端末毎に送信バッ
   ファを備え、各サービス端末との間で通信制御を行うた
   めの通信制御部と、上記通信制御部と接続されて情報配
   信処理を行うための通信制御プロセッサと、上記通信制
   御プロセッサによって実行される情報配信プログラム、
   及び上記情報提供装置から予め受信しておいた情報を格
   納するためのメモリ手段とから構成され、 上記通信制御プロセッサは、各サービス端末からの問合
   せに応じて、該サービス端末に配信すべき情報の上記メ
   モリ手段上のアドレスとデータ長とを上記メモリ手段内
   の複数の応答送信キューに順次格納し、上記情報提供装
   置からの最新の提供情報の受信に応じて該最新の提供情
   報に更新すべき情報を表示中のサービス端末に送信する
   ため、上記最新の提供情報が格納されるメモリ上のアド
   レスと上記最新の提供情報のデータ長とを一斉送信キュ
   ーに格納すると共に、該一斉送信キューの上記メモリ手
   段上のアドレスを上記応答送信キューに格納しておき、
   上記通信制御部から送信バッファが空き状態である通知
   に応じて、該送信バッファに対応するサービス端末に、
   該サービス端末に対応する最先の上記問合せ応答送信キ
   ューの内容に応じた情報を配送制御することを特徴とす
   る情報配信制御装置。２、複数のサービス端末と、情報
   提供装置とが接続され、上記情報提供装置から受信した
   情報を、上記各サービス端末からの問合せ、または上記
   情報提供装置からの提供情報に応じて、各サービス端末
   に必要な提供情報を配信するための情報配信制御装置に
   おいて、 上記情報配信制御装置は、各サービス端末毎に送信バッ
   ファを備え、各サービス端末との間で通信制御を行うた
   めの通信制御部と、上記通信制御部と接続されて情報配
   信処理を行うための通信制御プロセッサと、上記通信制
   御プロセッサによって実行される情報配信プログラム、
   及び上記情報提供装置から予め受信しておいた情報を格
   納するためのメモリ手段とから構成され、 上記通信制御プロセッサは、各サービス端末からの問合
   せ、あるいは、上記情報提供装置からの最新の提供情報
   の受信に応じて、順次登録番号を発生する登録番号発生
   手段を備え、各サービス端末からの問合せに応じて、該
   サービス端末に配信すべき情報の上記メモリ手段上のア
   ドレスとデータ長と上記登録番号発生手段から通知され
   る第１の登録番号とを上記メモリ手段内の複数の応答送
   信キューに順次格納し、上記情報提供装置からの最新の
   提供情報の受信に応じて該最新の提供情報に更新すべき
   情報を表示中のサービス端末に送信するため、上記最新
   の提供情報が格納されるメモリ上のアドレスと上記最新
   の提供情報のデータ長と上記登録番号発生手段から通知
   される第２の登録順番号とを一斉送信キューに格納して
   おき、上記通信制御部から送信バッファが空き状態であ
   る通知に応じて、該送信バッファに対応するサービス端
   末の問合せ応答送信キュー内の上記第１の登録番号と一
   斉送信キュー内の上記第２の登録番号とを比較し、最先
   の登録番号を含む送信キューの内容に応じた情報を配送
   制御することを特徴とする情報配信制御装置。 ３、複数のサービス端末と、情報提供装置とが接続され
   、上記情報提供装置から受信した情報を、上記各サービ
   ス端末からの問合せ、または上記情報提供装置からの提
   供情報に応じて、各サービス端末に必要な提供情報を配
   信するための情報配信制御装置において、 上記情報配信制御装置は、情報配信処理を行うための通
   信制御プロセッサと、上記通信制御プロセッサによって
   実行される情報配信プログラム、及び、上記情報提供装
   置から予め受信しておいた情報を格納するためのメモリ
   手段とから構成され、上記通信制御プロセッサは、上記
   情報提供装置から受信した情報が、上記各サービス端末
   からの問合せに応じて配信すべき情報を追い越して配信
   されることを防止するための追越し配信防止手段を備え
   たことを特徴とする情報配信制御装置。 ４、前記追越し配信防止手段は、各サービス端末からの
   問合せに応じて、該サービス端末に配信すべき情報の上
   記メモリ手段上のアドレスとデータ長とを順次格納する
   ための複数の応答送信キューと、上記情報提供装置から
   の最新の提供情報の受信に応じて該最新の提供情報に更
   新すべき情報を表示中のサービス端末に送信するため、
   上記最新の提供情報が格納されるメモリ上のアドレスと
   上記最新の提供情報のデータ長とを格納するための一斉
   送信キューとを備え、前記通信制御プロセッサは、上記
   一斉送信キューに上記最新の提供情報が格納されるメモ
   リ上のアドレスと上記最新の提供情報のデータ長とを格
   納するときに、該一斉送信キューの上記メモリ手段上の
   アドレスを上記応答送信キューに格納しておき、上記通
   信制御部から送信バッファが空き状態である通信に応じ
   て、該送信バッファに対応するサービス端末に、該サー
   ビス端末に対応する最先の上記問合せ応答送信キューの
   内容に応じた情報を配送制御するようにしたことを特徴
   とする請求項第３項記載の情報配信制御装置。 ５、前記追越し配信防止手段は、各サービス端末からの
   問合せ、あるいは、上記情報提供装置からの最新の提供
   情報の受信に応じて、順次登録番号を発生する登録番号
   発生手段と、各サービス端末からの問合せに応じて、該
   サービス端末に配信すべき情報の上記メモリ手段上のア
   ドレスとデータ長と上記登録番号発生手段から通知され
   る第１の登録番号とを順次登録するための複数の応答送
   信キューと、上記情報提供装置からの最新の提供情報の
   受信に応じて該最新の提供情報に更新すべき情報を表示
   中のサービス端末に送信するため、上記最新の提供情報
   が格納されるメモリ上のアドレスと上記最新の提供情報
   のデータ長と上記登録番号発生手段から通知される第２
   の登録順番号とを格納するための一斉送信キューとを備
   え、前記情報配信制御プロセッサは、上記通信制御部か
   ら送信バッファが空き状態である旨の通信に応じて、該
   送信バッファに対応するサービス端末の問合せ応答送信
   キュー内の上記第１の登録番号と一斉送信キュー内の上
   記第２の登録番号とを比較し、最先の登録番号を含む送
   信キューの内容に応じた情報を配送制御することを特徴
   とする請求項第３項記載の情報配信制御装置。 ６、複数のサービス端末と、情報提供装置とが接続され
   、上記情報提供装置から受信した情報を、上記各サービ
   ス端末からの問合せ、または上記情報提供装置からの提
   供情報に応じて、各サービス端末に必要な提供情報を配
   信する情報配信制御装置のための情報配信制御方法にお
   いて、上記情報配信制御装置は、各サービス端末毎に送
   信バッファを備え、各サービス端末との間で通信制御を
   行うための通信制御部と、上記通信制御部と接続されて
   情報配信処理を行うための通信制御プロセッサと、上記
   通信制御部に接続され、上記通信制御プロセッサによつ
   て実行される情報配信プログラム、情報の識別番号と該
   情報を表示中のサービス端末との対応関係を表わすテー
   ブルを格納するためのメモリ手段とから構成され、 上記通信制御プロセッサは、各サービス端末からの問合
   せに応じ、該サービス端末に配信すべき情報の上記メモ
   リ手段上のアドレスとデータ長とを上記メモリ手段内の
   複数の応答送信キューに順次格納し、上記情報提供装置
   からの最新の提供情報の受信に応じて該最新の提供情報
   に更新すべき情報を表示中のサービス端末に送信するた
   め、上記最新の提供情報が格納されるメモリ上のアドレ
   スと上記最新の提供情報のデータ長とを一斉送信キュー
   に格納すると共に、該一斉送信キューの上記メモリ手段
   上のアドレスを上記応答送信キューに格納しておき、上
   記通信制御部から送信バッファが空き状態である通知に
   応じて、該送信バッファに対応するサービス端末に、該
   サービス端末に対応する最先の上記問合せ応答送信キュ
   ーの内容に応じた情報を配送制御することを特徴とする
   情報配信制御方法。 ７、複数のサービス端末と、情報提供装置とが接続され
   、上記情報提供装置から受信した情報を、上記各サービ
   ス端末からの問合せ、または上記情報提供装置からの提
   供情報に応じて、各サービス端末に必要な提供情報を配
   信する情報配信制御装置のための情報配信制御方法にお
   いて、上記情報配信制御装置は、各サービス端末毎に送
   信バッファを備え、各サービス端末との間で通信制御を
   行うための通信制御部と、上記通信制御部と接続されて
   情報配信処理を行うための通信制御プロセッサと、上記
   通信制御プロセッサによって実行される情報配信プログ
   ラム、及び情報の識別番号と該情報を表示すべきサービ
   ス端末との対応関係を表わすテーブルを格納するための
   メモリ手段とから構成され、 上記通信制御プロセッサは、各サービス端末からの問合
   せ、あるいは、上記情報提供装置からの最新の提供情報
   の受信に応じて、順次登録番号を発生する登録番号発生
   手段を備え、各サービス端末からの問合せに応じて、該
   サービス端末に配信すべき情報の上記メモリ手段上のア
   ドレスとデータ長と上記登録番号発生手段から通知され
   る第１の登録番号とを上記メモリ手段内の複数の応答送
   信キューに順次格納し、上記情報提供装置からの最新の
   提供情報の受信に応じて該最新の提供情報に更新すべき
   情報を表示中のサービス端末に送信するため、上記最新
   の提供情報が格納されるメモリ上のアドレスと上記最新
   の提供情報のデータ長と上記登録番号発生手段から通知
   される第２の登録順番号とを一斉送信キューに格納して
   おき、上記通信制御部から送信バッファが空き状態であ
   る通知に応じて、該送信バッファに対応するサービス端
   末の問合せ応答送信キュー内の上記第１の登録番号と一
   斉送信キュー内の上記第２の登録番号とを比較し、最先
   の登録番号を含む送信キューの内容に応じた情報を配送
   制御することを特徴とする情報配信制御方法。