JP2555222B2

JP2555222B2 - ネットワーク・コントロール・システム

Info

Publication number: JP2555222B2
Application number: JP2512443A
Authority: JP
Inventors: 忠光龍; 善雄茂木; 孝則深津; 秀世岡崎; 元筧; 朗橋本; 守遠藤; 満彦山縣
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1989-09-14
Filing date: 1990-09-11
Publication date: 1996-11-20
Anticipated expiration: 2011-11-20

Description

【発明の詳細な説明】〔技術分野〕本発明は，複数の処理機能をもつ端末が通信網に連繋
されて，例えばチャットや配信（メール）やRCS（リモ
ート・コンピュータ・サービス）や相手不在時の処理な
どの複数のリモート・サービスを実行するネットワーク
・コントロール・システムに関する。

最近，通信網を介して遠隔端末と交信しつつ処理を実
行することが考慮されつつあり，そのための通信回線を
効率よく利用することが望まれている。また公衆網内で
の通信，あるいは公衆網と専用線とが混在する網内での
通信に当たっては，網の接続態様によってはより安価な
通信コストで足りる場合が存在する。そして，最近の如
く，大量の画像伝送が行われるようになるにつれて，上
記通信コストの低減が重要な課題となる。更に，相手方
が不在であるような事態が生じても，必要に応じて相手
方を緊急に呼び出してサービスできるシステムを提供す
ることが望まれている。

〔背景技術〕

近年，第29図に示す如く通信ネットワークが複雑とな
り，各端末は，或るものは公衆網に連繋され，また或る
ものは専用線（言わば私的な専用回線網）に連繋されて
おり，それらの各端末相互で，画面情報を含む各種の情
報を交信することが行われるようになりつつある。

第29図はネットワークの一例を示す。図中の符号１は
公衆網,2は専用線,10A,10B,10C,10Dは夫々群,3A,3B,3C,
3Dは夫々管理局端末,4A,4B,4C,4Dは夫々一般端末を表わ
している。

端末3,4は，夫々，同一通信網に連繋されていること
や地域的に近接していることなどを判断されて，群10A,
10B,……に区分される。

各群内には少なくとも１つの管理局端末3A,3B,……が
存在し，当該管理局のうちの幾つかは，公衆網１と専用
線２との両者に連繋されている。

第29図に示す如きネットワークの下で，最近，各端末
相互間で，チャットや配信（メール）やRCS（リモート
・コンピュータ・サービス）や相手不在時に処理などの
複数のリモート・サービスを実行できるようにすること
が望まれている。

上記の如きリモート・サービスを行うことが望まれて
いるが，次の如き問題がある。

即ち従来の場合には，サービス中には通信回線が開か
れたままにあることから，直接送受が行われていないデ
ッド・タイム分についても通信コストに計上されること
となる。また，これをさけるために，通信回線を開いた
りあるいは閉じたりすることを考慮したとしても，当該
実施に当たっては，運用者がいちいち関与せざるを得な
かった。

また，公衆網の利用料金はその利用距離に比例してい
るわけではなく，地域によっては利用区間の料金がその
途中のある地点までの料金とそこから目的地までの料金
との和よりも高い場合がある。しかし，現状ではこのよ
うな場合であっても，例えば中継手段を採用して料金を
安価にするなどの利用態様は存在していない。

またデータを転送したい遠距離の相手方端末が複数台
存在していて，かつ当該相手方端末がきわめて近接した
位置にある場合でも，夫々の相手方端末に対して個別に
遠距離通信によってデータを送ることが必要となる。

更に，通信コストを低減するために専用線をもうける
ことが行われているが，当該専用線に連繋されている端
末から公衆網上の端末へ，あるいは公衆網上の端末から
専用線上の端末へ通信するに当たっても，夫々の端末の
状況を意識して，専用線のコストメリットとの公衆網が
全国ネットであるという点との夫々の長所を生かした接
続態様をとることが望まれる。

更に上記配信（メール）を行うに当たっても次の如き
問題がある。

第30図（ａ）及び（ｂ）は実データを一つの端末（発
信局）121から他の複数の端末（受信局）122〜124へ配
信するシステムとしての従来例を概略的に示したもの
で，以下，それぞれのシステムについて説明する。

第30図（ａ）図示の場合には，発信局121が第１受信
局122に，例えば回覧すべき会議議事録等の実データを
送信し，この第１受信局122が受信した実データの内容
を確認・加工し，一旦発信局121に返送する。発信局121
が第１発信局122からの返信データの有無を確認する
と，その返信データを第２受信局123に送信し，第２受
信局123でも同様にしてデータの内容を確認・加工し，
一旦発信局121に返送する。そして，このような方法を
例えば第３受信局124以降についても繰り返し，発信局1
21から順次実データを配信していく。

第30図（ｂ）図示の場合には，発信局121がホストセ
ンター130に実デーダを送信すると，今度はこのホスト
センター（130）が（ａ）の発信局121の代わりに機能し
て順次各受信局122〜124と実データの遣り取りを行い，
ホストセンター130を中心に順次配信して行く。

上記のような従来例では，或る受信局で実データを受
けた後，一旦必ず発信局に確認・加工した実データを返
信してから次の受信局への送信を行っているので，実デ
ータが通信経路を往復することになるので，回線の使用
が非効率的となると共に，発信局又はホストセンターの
情報システムを常時稼動させる必要性が生じるため，発
信局では他の必要な処理が待機させられるという問題点
があった。

また更に，上記RCSを行うに当っても次の如き問題が
ある。

第31図は従来技術説明図であり，データ・スルー方式
による端末間通信について示している。

第31図において,201は所定の端末,202（202−１ない
し202−６）は所定の端末201以外の（一般）端末,215は
交換機及び通信網（又は公衆網）である。

従来，端末202間の通信は，図示の如く，所定の端末2
01を介して行われている。所定の端末201は，このネッ
トワークにおいて，端末間通信のホストとして定められ
た計算機である（以下，ホストという）。

例えば，端末202−１が端末202−３と通信を行う場
合，次の処理が行われる。まず，要求元端末202−１
が，交換機及び通信網215を介して回線をホスト201に接
続し，要求先端末202−３の端末番号を通知する。ホス
ト201は，この端末番号から端末202−３の電話番号を知
り，交換機及び通信網215を介して回線を端末202−３に
接続する。この後，端末202−１及び202−３間でのデー
タ転送が行われる。まず，例えば，端末202−１からホ
スト201にデータが送られ，このデータがホスト201から
端末202−３に送られる。従って，ホスト201は，端末20
2−１に接続された回線から受信したデータをそのまま
端末202−３に接続された回線に送出する処理（データ
・スルー処理）を行う。

前述の如く，ホスト（所定の端末）201が行うデータ
・スルー処理によって端末202間の通信を行うと，以下
の如き問題を生じる。

第31図図示の如く，略同時に，端末202−１及び202−
３間の通信，端末202−２及び202−４間の通信，端末20
2−５及び202−６間の通信等，複数の通信の要求がホス
ト201に対して行われることが考えられる。このような
場合，複数の通信要求の各々に対応して，データ・スル
ー処理を行う必要があるが，これによる負荷は，ホスト
201にとって相当大きなものとなってしまう。従って，
ホスト201が他の処理を行うことができなくなる可能性
がある。逆に，ホスト201は交換機ではなく計算機であ
るから，接続回線数及び交換機能が制限を受ける。従っ
て，一時に通信要求が集中した場合には，ホスト201側
の原因によって，通信が行えなくなる可能性がある。

上記相手不在時の処理においても，また，次の如き問
題を含んでいる。

オペレータを介在して不在端末局の管理者を捜し出し
てもらう場合，管理者としては，自局のオペレータに外
出先を知らせておかなければならないので，この点面倒
が生じるという欠点があった。また，オペレータに外出
先を知らせておくことを忘れていれば，勿論捜し出すこ
とは不可能であるという問題点があった。電話機の不在
転送機能を利用して当該管理者を捜し出す場合，当該管
理者の外出先が時間とともに移り変って行けば，結局捜
し出すことはできないという問題点があった。すなわ
ち，不在端末局は，送信してきた他端末局と交信する機
能がなく，なかんずく管理者を捜し出せるような機能は
全く不備となっているという状況にある。

〔発明の開示〕

本発明は，上記の如き種々の問題を解決することを目
的としており，第１図は本発明の原理説明図である。図
中の符号１は通信網（公衆網）,2は専用線,10A,10B,10
C,10Dは夫々群,3A,3B,3C,3Dは夫々管理局端末,4A,4B,4
C,4Dは夫々一般端末を表している。

各群内には少なくとも１つの管理局端末3A,3B,……が
存在し，抽出機能と通知機能とをそなえている。例えば
管理局端末3Aにおける抽出機能としては，（ｉ）少なく
とも自己群10Aに属する端末（3A,4A）に関してはメモリ
上に保持し，（ii）他群10B,10C,……に属する端末（3
B,4B,3C,4C,……）に関しては，メモリ上に保持するか
必要に応じて対応する管理局端末3B,3C,……に問い合わ
せるなどして図示の如き端末情報を把握できるように構
成される。当該端末情報には，（ｉ）Ｔ−NO:端末IDで記述される。

（ii）群名：いずれの管理局端末に関連する群かが管理
局端末IDで記述される。

（iii）タイプ：いずれの網に連繋されているかが網ID
で記述される。

（iv）通信形態：どのような連続態様をもって接続すべ
きかについての通信形態が記述される。

端末3A,3B,3C,3Dや端末4A,4B,4C,4Dは，第１図図示下
半部に概念的に示す如き構成をもっている。即ち，図示
の符号1,4Aは第１図図示の上半部に対応しており,13は
送信処理機能部,14は受信処理機能部,15は送信テーブ
ル,16は受信テーブル,17は接続タイミング・テーブルで
あって本発明において用意されるもの,18は振分けコマ
ンド部であって受信された通信コマンドの内容にもとづ
いて当該受信に対応した各種の処理に振分けを行うも
の,19−1,19−２は夫々アプリケーション処理プログラ
ムを表している。

送信テーブル15や受信テーブル16は，送信すべき通信
コマンドや受信された通信コマンドを一時的にバッファ
リングする機能を有するものである。

送信処理機能部13や受信処理機能部14は，端末3iや4i
がもつ各種の例えばリモート・コンピューティング・サ
ービスに対応した通信プロトコルに対処する機能をもっ
ている。当該サービスとしては，少なくとも画面を含む
情報を他端末に伝送して表示せしめる画面表示機能や，
キーボードを操作しつつ他端末とリアルタイムで交信す
るチャット機能が存在する。

接続タイミング・テーブル17には，上記各種のサービ
スに対応した個々の「モード」と，当該モードの下での
各種の通信コードとに対応して，通信回線を開く指示や
通信回線を閉じる指示が記述されている。

他端末例えば4Bに対して通信コマンドが送出されるこ
とに対応して，当該通信コマンド中に記述されている上
記モードと通信コードとが解読され，当該モードと通信
コードとにもとづいて接続タイミング・テーブル17が索
引され，その内容にもとづいて通信回線が開かれあるい
は閉じられる。

即ち，個々のモードの下での個々の通信コードに対応
して，如何に通信回線を開きまたは閉じるかが指示され
る。例えば，他端末に対して情報を配信するメール処理
の場合には，メール通知（ML）コードまたはメール代行
（MI）コードを記述された通信コマンドに対応して通信
回線が開かれかつ相手端末からのOKデータの受信に対応
して通信回線が閉じられる。また画面表示処理の場合に
は，（ｉ）端末出力データ送出（TS）コードや固定デー
タ送出（CS）コードや可変データ送出（VS）コードを記
述された通信コマンドに対応して通信回線が開かれかつ
相手端末からのOKデータの受信に対応して通信回線が閉
じられ，（ii）端末出力データ要求（TR）コードや固定
データ要求（CR）コードや可変データ要求（VR）コード
を記述された通信コマンドに対応して通信回線が開かれ
かつ相手端末からの実データの受信に対応して通信回線
が閉じられ，（iii）ミシングモード通知（MM）コード
やミシングモード解除（MN）コードを記述された通信コ
マンドに対応して通信回線が開かれかつ相手端末からの
OKデータの受信に対応して通信回線が閉じられる。

受信側となる端末においては，伝送されてきた相手端
末からの通信コマンドの内容にもとづいて当該受信に対
応した各種の処理に振分けられ，夫々の処理が実行され
る。

第２図は本発明における端末の処理態様を表わすメイ
ンフローを示す。

端末は，システム運用開始に対応して，一般処理を実
行しており，当該一般処理の途中において，たとえば手
入力によって，（ｉ）チャット・モード，（ii）配信
（メール）モード，（iii）RCSモード，（iv）相手不在
時の処理（図示の「不在登録／処理」）が指示される
と，それらのいずれかの処理に入ってゆく。勿論，その
他のモードの場合には，それに対応した一般処理を実行
して終了となる。

〔図面の簡単な説明〕

第１図は本発明の原理説明図，第２図は本発明におけ
る端末の処理態様を表わすメインフロー，第３図はチャ
ットの動作フロー，第４図および第５図は配信の動作フ
ロー，第６図はRCSの動作フロー，第７図は不在登録／
処理開始動作フロー，第８図は通信処理方式の動作フロ
ー，第９図は接続タイミング・テーブルの一実施例記述
内容，第10図は画面表示処理の一例を示す図，第11図は
配信モードの概念図，第12図は配信システムを構成する
端末の構成例，第13図は第12図図示の制御部の実施例フ
ロー，第14図はRCSモードにおいてデータ・スルー処理
が行われる構成，第15図はホストとなる端末の構成，第
16図は２つの図面（その１とその２）が一緒になって１
つの図面を構成する端末間通信フロー，第17図は端末間
通信の状態を示す説明図，第18図（ａ）（ｂ）（ｃ）は
不在登録／処理モードの場合の原理説明図，第19図は不
在端末の要部構成図，第20図は不在登録／処理の動作の
一例を示すフローチャート，第21図は通信制御方式を説
明する説明図，第22図ないし第26図は夫々本発明による
通信形態，第27図は直接通信する場合の処理態様，第28
図は管理局端末経由の通信を行う場合の処理態様，第29
図はネットワークの一例，第30図（ａ）（ｂ）は配信モ
ードの場合の従来例概略図，第31図はRCSモードの場合
の従来技術説明図を示す。

〔発明を実施するための最良の形態〕

第３図はチャットの場合の動作フローを示し，第４図
および第５図は配信の場合の動作フローを示し，第６図
はRCSの場合の動作フローを示し，第７図は不在登録／
処理開始動作フローを示している。また第８図は第３図
ないし第６図図示の各フローにおける「通信処理方式」
の動作フローをまとめて示した図である。

本発明に用いられる通信コマンドは一例として，￥￥ ×× （××××，××××， ××××〔×××××××……〕）の如きデータ・フォーマットをもっており，（ｉ）最初の￥￥は通信の始まりを示し，（ii）次の２文字（××）は通信コードを与えるもので
ある。当該通信コードの次には必ず右開きカッコが与え
られる。

（iii）右開きカッコの次には，自端末ナンバ（通常９
桁分）と，他端末ナンバ（通常９桁分）とが記述され，（iv）他端末ナンバに続いて論理コマンド（通常６桁
分）が与えられ，当該論理コマンドの内容が本発明にい
う上記「モード」を指示していると考えてよい。

（ｖ）当該論理コマンドに続いて，データを必要とする
場合には，カギ・カッコ〔××……〕が用いられ，当該
カギ・カッコ内にデータが記述される。

（vi）そして，最後に左開きカッコをもって結びとされ
る。

第９図は接続タイミング・テーブルの一実施例記述内
容を示している。

（１）画面表示処理モードの下では，（ｉ）通信コードTSとCSとVSとのいずれかが記述された
通信コマンドの送出に対応して通信回線が開かれ，かつ
相手端末からのOKデータの受信に対応して通信回線が閉
じられ，（ii）通信コードTRとCRとVRとのいずれかが記述された
通信コマンドの送出に対応して通信回線が開かれ，かつ
相手端末からの実データの受信に対応して通信回線が閉
じられ，（iii）通信コードMMとMNのいずれかが記述された通信
コマンドの送出に対応して通信回線が開かれ，かつ相手
端末からのOKデータの受信に対応して通信回線が閉じら
れる。

（２）配信を行うメール処理モードの下では，通信コー
ドMLとMIとのいずれかが記述された通信コマンドの送出
に対応して通信回線が開かれ，かつ相手端末からのOKデ
ータの受信に対応して通信回線が閉じられる。

（３）チャット処理モードの下では，通信コードCHが記
述された通信コマンドの送出に対応して通信回線が開か
れ，かつ相手端末からのチャット終了データの受信に対
応して通信回線が閉じられる。

以下同様に，（４）故障発生時などの際に他端末にデ
ータを退避する退避処理モード，（５）ホストとの通信
を行う際の仮センター処理モード，（６）個人IDを通信
する個人ID処理モード，（７）時計を送信する時計処理
モードなどに対応して，図示の各種通信コードが記述さ
れた通信コマンドの送出に対応して通信回線が開かれ
（図示の接続の欄参照），かつ図示の切断の欄に記述さ
れた内容の受信に対応して通信回線が閉じられる。

なお，各種の通信コードは次の表１に示す如き処理を
指示するものである。

第10図は画面表示処理の一例を示す図である。図中の
符号4A,4Bは夫々第１図に対応している。また21はキー
ボードをもつディスプレイ,22はポインティング・デバ
イス,23は表示テーブルであってディスプレイ21に表示
される内容が記憶されるもの,24は現在表示属性テーブ
ルであってディスプレイ21上に現に表示されている画面
についての属性が記述されているもの,25は端末出力フ
ァイル,26はアプリケーション・プログラムを表してい
る。

端末4Aから他端末4Bで作られた画面を要求する（処理
）ことによって，端末4Bの端末出力ファイル25から当
該要求された画面が転送され，ディスプレイ21上に表示
されると共に現在表示属性テーブル24上に記述が行われ
る（処理）。端末4Aにおいてポインティング・デバイ
ス22などを用いて指示が行われると，プログラム起動を
かける処理が行われる（処理）。起動をかけられたア
プリケーション・プログラム26は，画面の要求によっ
て，現在つながっている端末4Aに対して別の画面を表示
させることができる（処理）。またアプリケーション
・プログラム26は，端末4Aにおける表示テーブル23にメ
ッセージを送って表示要求を行うことができ（処理
），また端末4Aからのデータ入力催促などのデータを
受け取ることができる（処理）。

以下フローチャートを説明する。第２図図示の処理選
択においてチャット・モードが選択されているとする
と，第３図図示の「処理Ａ」が実行される。なお当該
「処理Ａ」は，第４図ないし第６図図示の「処理Ａ」と
して示されている個所において，同じ処理が行われるも
のである。

第３図図示の場合，第１図図示の接続タイミング・テ
ーブル17が参照されて，処理Ａに入る。処理Ａにおいて
は，管理局端末3A,3B,3C,3D…に存在するターミナル情
報ファイル（FiLE 1）を索引して相手端末情報を参照す
る。即ち，第１図図示の接続タイミング・テーブル17の
内容にもとづいて，送信処理機能部13が送信テーブル15
を利用して，管理局端末3Aなどと交信し，上記ターミナ
ル情報ファイル（FiLE 1）を索引し，相手端末の情報を
調べる。そして，相手端末が確認できない場合（NGの場
合）相手端末未確認通知をCRT表示して，第２図図示の
に戻る。しかし，相手端末が確認できると（OKの場
合），相手端末のタイプを判断し，チャット・モードで
の通信に入る。

チャット・モードの下での通信を含めて「通信処理方
式」については具体的には第８図を参照して説明される
が，第３図図示の「通信処理方式」に関連するカギ・カ
ッコ状の矢印αが記述されている所は，或る端末が管理
局端末を介在することなく他端末と直接チャット・モー
ドでの通信を行う場合のフローである。

第１図図示の送信処理機能部13が接続タイミング・テ
ーブル17を索引しつつ，チャット要求（送信）やチャッ
ト終了要求に対応して通信回線を開き（接続し）次いで
相手端末からの情報を受信する動作が繰返されるが，デ
ータの送受信が行われない期間では回線が切断される
（回線が閉じられる）。なお，第３図において下半部分
にカギ・カッコ状の矢印αが記述されているが，矢印α
に対応する個所の動作が，「通信処理方式」による処理
であることを表わしている，第４図ないし第６図におい
ても同様である。

第３図図示の動作フローに示す如く，チャット・モー
ドの下での通信に当っては，送信と返送とが行われるた
びに，回線が一旦切断される形となり，回線の使用効率
が向上する。そしてどのタイミングで接続し，またどの
タイミングで切断するかは，上述の接続タイミング・テ
ーブルに記述されている。

第２図図示の処理選択において配信モードが選択され
ているとすると，第４図（Ａ）図示の如く接続タイミン
グ・テーブル（第１図図示の17）が参照されると共に，
配信方法が選択される。図示の場合「単端末へ」の場合
には，第４図（Ｂ）（２−１）へ進み，「登録パター
ン」の場合には，第５図（２−２）へ進み，「任意パタ
ーン」の場合には第５図（２−３）へ進む。なお，「単
端末へ」とは，単一の端末へ配信する場合であり，「登
録パターン」とは予め登録されている配信順序パターン
に従って複数の端末へ配信する場合であり，「任意パタ
ーン」とは任意の配信順序パターンで複数の端末へ配信
する場合である。

「単端末へ」の場合には，第４図（Ｂ）図示の如く，
まず第３図図示の「処理Ａ」をへて，「通信処理方式」
の下で，相手端末へ送信し，受信を確認する。

「登録パターン」の場合には，第５図図示（２−２）
から，登録パターンを選択する指示が与えられると，
「配信パターン検索」が行われる。即ち，予め登録され
ている配信パターンが配信パターンファイル（FiLE 2）
から読出される。

また「任意パターン」の場合には，第５図図示（２−
３）から，手入力によって配信順序が指定され，配信順
路データが作成される。

そして，「登録パターン」の場合も「任意パターン」
の場合も，第２図図示の「処理Ａ」をへて，「通信処理
方式」の下で，配信すべきデータを次々と相手端末に送
信してゆく。即ち，受信した相手端末は，確認信号を送
信した上で，順路データを解析し，次の相手端末へデー
タを送信する。そして，すべての相手端末への配信が終
了すると，配信終了通知となり，終了が確認される。

本発明における配信モードにおいては，第30図を参照
して説明した問題を解決するために，発信局と各受信局
との間で実データをいちいち返信させることをせずに，
例えばどの端末において受信が行われたかのみを発信局
に返送するようにしている。

第11図は配信モードの概念図を示し，発信局4₁が，自
局の配信実データと複数の受信局4₂〜4_nの配信順序を指
定するための配信順路データとを通信網１を介して最初
の受信局4₂に送信する。

これにより，最初の受信局4₂では，受信確認後，発信
局4₁が指定した配信順序に従って次の受信局4₃に対して
通信網１を介して実データを送り，以後，該配信順序に
従って通信網２を介して各受信局4₂〜4_n間で実データを
転送して行く。

また，本発明では，各受信局4₂〜4_nが，該実データの
配信を受けたとき，該通信網１を介して該発信局に対し
て受信確認情報を返信すると共に，最終受信局が，該受
信確認信号及び該実データを返信することができる。

第12図は，配信システムを構成する各端末の一実施例
を概略的に示すもので，発信局及び受信局のいずれにも
共通して，配信実データの入出力動作と着配信確認作業
等を行うための入出力機器31と，配信実データ及び配信
制御情報（配信順路情報，確認情報）を格納記憶し出力
するためのファイル32と，入出力機器31に対して配信実
データ及び配信制御情報の入力・表示の制御を行い，フ
ァイル32に対して配信実データ及び配信制御情報の格納
記憶・出力の制御を行い，更に外部の他の端末に対して
は通信網１を通して配信実データ及び配信制御情報の遣
り取りの制御を行う順次配信制御・システム制御部（入
出力テーブル）33と，で構成されている。

次に，第12図図示の制御部の動作を第11図及び第13図
に示すフローチャートを参照して説明する。

まず，各端末は自局が発信局又は受信局のいずれに設
定されているかを判定する（ステップS0）。

この判定の結果，各端末においては，各設定に応じて
下記の動作を行う。

発信局の場合：配信実データの特定動作（ステップS1）制御部33は，入出力機器31から入力された配信実デー
タをファイル32に記憶格納して特定する。

順次配信経路決定動作（ステップS2）次に順次配信経路情報（以下，配信順路データと言
う）を同様に入出力機器31から入力しファイル32に格納
する。

配信動作（ステップS3）制御部33は，ファイル32から配信実データ及び配信順
路データを取り出しこれらを一緒にして１つの情報とし
て通信網１を介して第１受信局4₂に配信する。この配信
順路データは例えば，配信順路の端末番号の数字列で，
第１受信局4₂の端末番号，第２受信局4₃の端末番号，…
…第ｎ受信局4_nの端末番号，自局（受信局）の端末番
号，と言う形態を採ることができる。

配信確認動作（ステップS4）発信局4₁はその制御部33により各受信局4₂〜4_nの順次
配信状況を次の２通りの方法で確認することができる。

イ）各受信局4₂〜4_nが受信・配信時に発信局4₁に受信・
配信の状況を通信網２を経て送信する方法。

ロ）発信局4₁が各受信局毎に配信状況を通信網１を経て
確認して行く方法。

最終受信動作（ステップS5）最後の受信局4_nが確認動作終了後，その配信実データ
が発信局4₁に返送される。

受信局（第１受信局及び中間受信局）の場合：配信実データの受信動作（ステップS6）受信局では，その制御部33により，配信実データを受
信し，ファイル32に自動記憶格納すると共に，利用者が
配信実データを参照できるように必要に応じてファイル
32から入出力機器31に出力して内容確認を行う。

配信実データ確認動作（ステップS7）配信実データの内容確認作業（ステップS6）により確
認した旨の受信確認情報を発信局4₁に返送する（上記の
確認方法イの場合）か，又は受信確認情報を準備し発信
局4₁から受信確認の問い合わせ（上記確認方法ロの場
合）が来るまで待機させる。

配信動作（ステップS8）受信局において受信内容確認作業の終了後は順路デー
タによって指定される次の受信局に配信される。この場
合も配信実データ＋配信順路データの形で通信網１を介
して送信される。

受信局（最終受信局）の場合：配信実データの受信動作（ステップS9）これは上記（ステップS6）と同じである。

配信実データ確認動作（ステップS10）これは上記（ステップS7）と同じである。

配信動作（ステップS11）自局が最終受信局4_nであることが判定された（ステッ
プS0）ときには，実データを発信局4₁へ返信する。

尚，自局が受信局として最終受信局であるか否かは，
順路データから判別することができる。

第２図図示の処理選択においてRCSモードが選択され
ているとすると，第６図図示の如く，第１図図示の接続
タイミング・テーブル17が参照された上で，第３図図示
の「処理Ａ」をへて，「通信処理方式」の下での通信処
理に入る。第６図図示の「通信処理方式」以降の処理
は，相手端末が第１図図示の自己群例えば10A内に存在
することから管理局端末の介在を不要としている場合の
処理に対応している。なお管理局端末の介在を必要とす
る場合の処理については第８図を参照して後述される。

第６図図示の「通信処理方式」の下で，例えば第１図
図示の端末T₁が相手端末T₂に対して，回線を接続してプ
ログラム処理要求を発したとすると，相手端末T₂におい
ては，自己内のプログラムを起動し実行する。処理の途
中で当該処理に必要ならばデータを要求する。端末T₁側
においては，当該要求を受信すると，端末T₂との間の回
線を一旦切断し，オペレータが所望されるデータを入力
すると，再び回線を接続して当該データを送信する。端
末T₂はデータ入力処理を行ってプログラムを実行する。
プログラムが終了すると，端末T₂は端末T₁に対して終了
を通知し，端末T₁は先に行ったプログラム処理要求が終
了されたことを確認する。なお言うまでもなく，上記終
了の通知に対応して，要求されたプログラム処理におい
て行われた処理結果が，端末T₁に送られる。

本発明におけるRCSモードにおいては，第31図を参照
して上述した如き問題即ちホストとなる端末における負
荷が増大するという問題を解決したRCSモードを提供し
ている。

第14図はRCSモードにおいてデータ・スルー処理が行
われる構成，第15図はホストとなる端末の構成，第16図
は２つの図面（その１とその２）が一緒になって１つの
図面を構成する端末間通信フロー，第17図は端末間通信
の状態を示す説明図である。

第14図において,3Aはホスト（所定の端末）,4（4A,4
D）はホスト3A以外の（一般）端末,40は交換機,1は通信
網,41は交換回線である。

端末４は，複数設けられ，これらの間で互いにデータ
転送を伴う通信を行う。この通信は，ホスト3Aによって
制御される。このために，端末４は，通信網１及び交換
回線41を介して，交換機40及びホスト3Aに接続される。

ホスト3Aは，このネットワークにおいて，予め定めら
れた所定の端末であり，端末４間の通信のホストとして
定められる計算機である。ホスト3Aは，端末４間の通信
を行うために，交換機40を制御する。

交換機40は，必要に応じて，ホスト3Aと端末４の間を
通信網１（及び交換回線41）を介して接続する。また，
このために，交換回線41の切換えを行う。更に，交換機
40は，ホスト3Aからの制御に従って，端末２の間を通信
網１（及び交換回線41）を介して接続する。また，この
ために，交換回線41の切換えを行う。

１つの端末4Aが，他の端末4Dとの間で通信を行うもの
とする。

端末4Aは，交換機40を介して，ホスト3Aを呼出し，端
末4Dとの通信を要求する。

ホスト3Aは，この要求に応じて，交換機40を介して，
端末4Dを呼出し，その応答を待って端末4Dを確認する。
この時点では，ホスト3Aは，交換機40により，交換回線
41を介して，端末4A及び4Dの双方と接続されている。

この後，ホスト3Aは，交換機40に対して，端末4A及び
4D間を接続するように制御を行う。

交換機40は，この制御に従って，端末4A及び4D間を接
続する。即ち，それまでホスト3Aと接続されていた端末
4A及び4Dからの交換回線41を，ホスト3Aから切離し互い
に接続するように，回線切換えする。そして，交換機40
は，端末4Aから送出されてきたデータを，そのままスル
ー（通過）させ，端末4Dへ送出する。

以上により，端末４間の通信の際のデータ・スルー
を，ホスト3A側でなく交換機40側で行うことができる。
従って，ホスト3Aの負荷を軽減し，ホスト3Aを他の処理
のために活用できる。また，ホスト3Aのネットワークポ
ート数以上の回線制御が可能となり接続回線数や交換機
能による通信への制限が大幅に無くなるので，端末４間
での通信を円滑に行うことができる。

第15図は実施例構成図であり，主に，ホスト3Aの構成
について示している。

第15図において,42はインタフェース部,43は制御線,4
4は制御部,45は通信制御部,46は処理部,47は切換制御
部,48はターミナル管理ファイル,49は送受信部である。

ホスト3Aは，端末４間での通信におけるデータ・スル
ー制御等の処理を行う制御部44と，端末４との間での通
信を行う送受信部49と，ネットワーク管理のためのデー
タベースとしてのターミナル管理ファイル48とを備え
る。

送受信部49は，電気（ベースバンド）信号と音声帯域
信号との間の変換，及び，その信号の送受信を行うモデ
ム（MODEM）部である。送受信部49は，交換回線41を介
して，交換機42と接続される。従って，ホスト3Aと端末
４との間の通信は，交換回線41を通して行われる。

なお，ホスト3Aは，代表電話番号で端末４から呼出さ
れる。従って，ホスト3Aがデータ・スルーを行わないこ
とと合せて，ホスト3Aが１つの端末４との間でデータの
送受信を行っている最中でも，他の端末４から通信要求
を受取り，回線切換え及びデータ・スルーの制御を行う
ことができる。

また，ホスト3Aは，交換機40を介して通信網１に接続
される。端末４は，通信網１に接続されている。従っ
て，ホスト3Aと端末４又は通信網１との間に，交換機40
が設けられる（第14図参照）。このような構成により，
ホスト3Aにおけるデータ・スルーを，その前段の交換機
40により円滑に代行することができる。

ターミナル管理ファイル48は，ネットワークの各端末
４について，その端末番号と電話番号とを格納する。こ
れにより，ホスト3Aは，全端末４をその端末番号により
管理できる。このために，端末４の電話番号の変更があ
った場合には，当該端末４からホスト3Aに対して通知が
なされ，変更後の電話番号がターミナル管理ファイル48
に登録される。ターミナル管理ファイル48は，処理部46
によって管理される。

制御部44は，通信制御部45,処理部46及び切換制御部4
7を備える。

通信制御部45は，送受信部49で受信した信号を処理部
46に取込み，また，処理部46からの送信すべき信号を送
受信部49に送り送信制御を行う。受信信号としては，例
えば，通信要求元端末4Aからの呼出し及び端末番号通
知，通信要求先端末4Dからの（呼出しに対する）応答，
交換機40からの通信終了通知がある。送信信号として
は，例えば，通信要求元端末4Aへの（呼出しに対する）
応答，通信要求先端末4Dへの呼出しがある。

処理部46は，端末４間での通信のための種々の信号処
理を行い，また，このためのデータベースであるターミ
ナル管理ファイル48の管理を行う。

即ち，端末4Aからの通信要求があった場合，処理部46
は，通信要求先の端末4Dの端末番号を用いてターミナル
管理ファイル48を検索し，通信要求先端末4Dの電話番号
を求める。そして，通信要求先端末4Dを呼出す。従っ
て，通信要求元端末4Aは，端末番号のみで，所望の端末
４との間での通信を行うことができる。

処理部46は，また，各端末４について，その端末番号
と電話番号とをターミナル管理ファイル48に登録する。
そして，端末４の電話番号の変更に応じて，ターミナル
管理ファイル48を更新する。

更に，処理部46は，前述の呼出した通信要求先端末4D
を確認した後，交換機40にデータ・スルーを行わせるた
めの処理を切換制御部47に依頼する。

切換制御部47は，処理部46からの依頼を受けて，交換
機40にデータ・スルーを行わせるための制御信号を形成
し，これを交換機40に送信する。この送信は，ホスト3A
と交換機40との間に設けられた専用の制御線43を介して
行われる。従って，送受信部49及び交換回線41は用いら
れない。このように，ホスト3Aは交換回線41とは別の制
御線43を介して，交換機40を制御する。また，切換制御
部47は，制御線43を介して，交換機40から端末４間での
通信終了の通知を受ける。

交換機40は，ホスト3Aとの間での制御線43による通信
を行うために，インタフェース部42を備える。インタフ
ェース部42は，切換制御部47からの制御信号を受信する
と，回線切換えを行う。即ち，通信要求元端末4A及び通
信要求先端末4Dの各々が交換機40を介してホスト3Aに接
続されている状態において，交換機40とホスト3Aとの間
を切断し，交換機40内で通信要求元及び要求先の２つの
端末４を互いに接続する。また，インタフェース部42
は，端末４間での通信が終了すると，通信終了通知のた
めの制御信号を形成し，これを切換制御部47に送信す
る。この後，交換機40において，端末４間の回線接続は
切断される。

なお，一旦開始された端末４間の通信であっても，ホ
スト3Aからの制御により，これを切断することができ
る。例えば，何らかの理由で処理部46が切断が必要であ
ると判断した場合，処理部46は，データ・スルー処理の
中断を切換制御部47に依頼する。切換制御部47は，この
ための制御信号を形成し交換機40に送出する。交換機40
は，これを受けて，データ・スルーを行っている回線接
続を切断する。

また，ホスト3Aは，それ自体，端末４との間で通信を
行う。この通信は，交換回線41を介して行われる。

第16図は端末間通信フローであり，第17図は端末間通
信の状態を示す図である。なお，通信要求元端末（ター
ミナル）を4A,通信要求先端末（ターミナル）を4Dとし
て区別することとする。

通信要求元の端末4Aが，ホスト3Aの代表電話番号をダ
イヤルすると，交換機40により端末4Aの回線（41）がホ
スト3Aの回線（41）に接続される（第17図（Ａ））。ホ
スト3Aの処理部46は，この呼出しに対する応答を，この
接続回線を介して端末4Aに返信する。

返信を受けた端末4Aが，前記接続回線を介して，通信
要求先の端末4Dの端末番号をホスト3Aに通知する（第17
図（Ａ））。

端末番号を受信すると，処理部46が，これを用いてタ
ーミナル管理ファイル48を検索する。

検索により，端末4Dの電話番号を知ることができなか
った（要求先を確認できなかった）場合，処理部46は，
前記接続回線を介して，未確認通知を端末4Aに送信す
る。

端末4Aにおいて，リトライを行わない場合は，処理を
終了する。

リトライを行う場合には，処理以下をくり返す。
検索により，端末4Dの電話番号を知ることができた（要
求先を確認できた）場合，処理部46が，当該電話番号に
より，端末4Dを呼出す。これに応じて，交換機40により
ホスト3Aの他の回線（41）が端末4Dの回線（41）に接続
される（第17図（Ｂ））。端末4Dは，この呼出しに対す
る応答を，この接続回線を介して，ホスト3Aに返信す
る。

返信を受けたホスト3Aの処理部46は，この応答によ
り，要求先である端末4Aとの間の接続がなされたこと
（通信が可能であること）を確認する（第17図
（Ｂ））。

処理部46が，切換制御部47に，交換機40でデータ・ス
ルーを行わせるための処理を依頼する。

切換制御部47が，回線切換えのための制御信号を形成
し，制御線43を介して交換機40に送信し切換えをコント
ロールする（第17図（Ｂ））。

交換機40のインタフェース部42が，ホスト3Aと接続さ
れていた端末4A及び4Dの回線（41）を，ホスト3Aから切
離し，互いに接続する（第17図（Ｃ））。

端末4Aがデータを送出すると，交換機40内をスルーし
て，端末4Dへ送られる（第17図（Ｃ））。

交換機40のインタフェース部42が，端末4Aと4Dとの間
の通信が終了すると，制御線43を介してこれを通知する
（第17図（Ｄ））。

ホスト3Aの切換制御部47は，この通知を受けて通信終
了を認識し，これを処理部46に通知する。

第２図図示の処理選択において相手不在時の処理（不
在登録／処理）モードが選択されているとすると，第７
図図示の動作フローに入る。即ち，図示左上に示す如く
「不在登録／処理・開始」となり，処理選択が行われ
る。選択内容は，（ｉ）メール参照設定−他端末からのメールを一旦登録
しておいたものを，不在であった管理者が後刻当該メー
ルを参照するための処理を設定すること，（ii）行き先登録−管理者が自己の行き先を登録するこ
と，（iii）行き先不明設定−管理者の行き先を予め決める
ことができず，ポケットベルを用いて通知してもらうこ
とを設定すること，のいずれかであると考えてよい。なお或る端末に対し
て他端末からのアクセスがあった場合の処理フローにつ
いては，第７図上には図示してないが，後述の説明から
自ら理解されよう。

メール参照設定に当っては，管理者は，メール参照す
べく自己のキーワードを入力する。これによって，キー
ワードがキーワード・ファイル（FiLE 3）に登録され
る。そして，メールを参照すべく入力したキーワードが
本来のキーワード（ファイルFiLE 3上のキーワード）と
が一致した際に，自己あてのメールを参照し得るように
される。

行き先登録に当っては，管理者は，自己の行き先ター
ミナル・ナンバを設定する。このときシステム側では，
当該設定された行き先ターミナル・ナンバがシステムに
おいて管理しているターミナルに該当しているか否か
を，ターミナル情報ファイル（FiLE 1）を検索して確め
る。ターミナルの存在が確認できたら，当該行き先ター
ミナル・ナンバを可変ファイル（FiLE 4）に登録する。
そして後刻，自己管理者あてに他端末からメールなどが
送られてきた際に，上記行き先ターミナル・ナンバを用
いて，転送してもらうようにされる。

行き先不明設定に当っては，管理者は自己の行き先が
１つの場所に確定されないことから，ポケットベルによ
る連絡を依頼すべく，ポケットベル・ナンバを設定す
る。当該ポケットベル・ナンバは，可変ファイル（FiLE
4）に登録され，後刻，利用されることとなる。

以下，本発明の不在登録／処理モードについて説明す
る。

第18図（ａ）（ｂ）（ｃ）は不在登録／処理モードの
場合の原理説明図を示している。

第18図（ａ）（ｂ）（ｃ）において符号１は通信網で
あり，例えば公衆電話回線である。3A,4A,4B,4Cは電子
計算機を備えた端末であり，ここでは端末4Aが管理者不
在である不在端末，端末4Dが端末4Aに対してメールを送
信した端末，端末4Bが管理者の外出先である端末である
ものとする。

なお，同図（ｃ）において端末3Aはポケベル送信機能
をもつ端末であり,50は管理者所持のポケットベルであ
る。

第18図（ａ）（ｂ）（ｃ）における不在端末4A内の符
号74は不在モード設定機能であり，管理者が外出時に例
えばキー操作などを行うことにより，後述する各機能を
作動可能とするようになっている。75はメール検知機能
であり，不在モード中において，他端末4D…からメール
が送信された際，これを検知するようになっている。

この他，特に最初の不在端末4Aに備えられた符号76
は，メール記憶部であり，自局4Aのターミナル情報（Ｔ
出力）ファイル（図示省略）が利用され，他端末4D…か
ら送信されたメールおよびその他端末4D…の端末No.やI
D・No.が記憶されるようになっている。77は不在または
メール通知機能であり，メールを送信してきた他端末4D
…に対して管理者不在であることを通知したり，メール
参照要求を送信してきた管理者の外出先である他端末4B
に対して既に記憶されてあるメールを通知したりするよ
うになっている。85はメール報告機能であり，管理者が
外出先である他端末4Bから自局4Aに連絡を行った際，自
局4Aにメールが届いている旨報告するようになってい
る。

また不在端末4Aに備えられた符号78は，外出先データ
記憶部であり，自局4Aの例えば可変ファイル（図示省
略）が利用され，管理者の外出先である他端末4Bの端末
No.などが記憶されるようになっている。この外出先デ
ータ記憶部78は，管理者のスケジュール表（日時と時刻
ごとの外出先）が記憶できるように構成することが可能
である。79は不在および外出先データ通知機能であり，
メールを送信した他端末4D…に対して管理者不在である
こと，および前記外出先データを通知するようになって
いる。80は捜索依頼機能であり，メールを送信した他端
末4D…の要望により，通信網１を介して前記外出先デー
タ，および自局4Aの端末No.,または当該他端末4D…の端
末No.を送信して管理者を捜し出すことを依頼するよう
になっている。

さらに次の不在端末4Aに備えられた符号82は，ポケベ
ル番号記憶部であり，管理者所持のポケットベル50の電
話番号データが記憶されるようになっている。83は不在
および電話番号データ通知機能であり，メールを送信し
た他端末4D…に対して管理者不在であること，および前
記電話番号データを通知するようになっている。84はポ
ケベル呼び出し機能であり，メールを送信した他端末4D
…からの要望によりポケベル送信端末3Aに対して前記電
話番号データを送信し，管理者所持のポケットベルを呼
び出せるようになっている。

上述した各記憶部76,78,82および各機能74,75,77,79,
80,83,84,85を全て備えた不在端末4Aと，これにメール
を送信した他端末4Dとでは少なくとも次のような交信を
行うことができる。

１つは，不在端末4Aに対してメールを送信した他端末
4Dでは，管理者不在であることが通知されるとともに，
当該メールをこちらに保存するが，その場合，当該他端
末4Dの端末No.やID・No.を知らせよとの通知を受け取
る。そこで，それら必要なデータを送信すると，不在端
末4Aでは当該メールがメール記憶部76内に記憶される。
これにより，後刻管理者が外出先である他端末4Bから特
種なキーワードなどをもってメール参照要求（矢線）
を出せば，ときにメール報告機能85などを介して自局4A
に他端末4D…からメールが届いていること，および端末
No.やID・No.を（必要に応じて簡単なメールの内容を含
む）参照する（矢線）ことができる。

もう一つは，不在端末4Aに対してメールを送信した他
端末4Dでは，管理者不在であることが通知されるととも
に，管理者の外出先データが通知される（矢線）。こ
れにより，メールを送信した他端末4D側では，管理者の
外出先である他端末4Bが判り，そこに改ためてメールな
ど送信し，当該管理者と交信する（矢線）ことができ
る。

さらにもう一つは，不在端末4Aに対してメールを送信
した他端末4Dでは，管理者不在であることが通知される
とともに，管理者所持のポケットベル50の電話番号デー
タが送信される（矢線。なお後述するように，管理者
所持のポケットベル50の電話番号データを他端末4Dに送
ることなく，不在端末4Aがポケベル送信端末3Aに対して
呼び出しを依頼するようにしてもよい）。これにより，
メールを送信した他端末4D側では，ポケベル送信端末3A
に対して当該電話番号データを送出して発信を依頼する
と（矢線），管理者所持のポケットベル50が呼び出さ
れる（矢線）。これによって管理者は外出先である他
端末4Bから自局4Aに対してメール参照要求などをもって
連絡を取ると（矢線），既に届いているメールの簡単
な内容，端末No.やID・No.などを参照でき（矢線），
先のメールを送信した他端末4Dと交信する（矢線）こ
とができる。

第19図は不在端末の要部構成図を示す。

同図符号4Aは不在端末,51は通信オブジェクト,52は不
在モード設定機能,53は外出先データ記憶部,55はポケベ
ル番号記憶部,57はメール検知機能,59は不在または各種
データ（メール保存可否，外出先データ，ポケベル番号
データ，捜索依頼データ，保存済メールデータなど）通
知機能,61は捜索依頼機能,62はデータ確認機能,63はメ
ール記憶部,65はメール報告機能,66は留守番電話機能で
ある。また符号FiLE 1,FiLE 4,FiLE5は夫々ファイル,60
は表示テーブルである。

これらのうち，不在モード設定機能52としては，自局
4Aに複数の端末（コンピュータ）が接続されてあれば，
各端末の「在／不在」が登録される個人ファイルFiLE5
において，該当する自端末を「不在」として設定するよ
うになっている。ただし,1つの端末（コンピュータ）し
か有していない場合，例えばフリップフロップなど利用
して構成しても良い。

外出先データ記憶部53としては，例えば自局4A内の可
変ファイルFiLE 4が利用され，管理者の外出先となる他
端末4B…（図示省略）の端末No.が記憶される。ただ
し，ここでは管理者の行動予定，すなわち，時刻と外出
先としての端末No.とが書込まれたスケジュール表とし
て記憶される。

ポケベル番号記憶部55としては，例えば前記自局4A内
の可変ファイルFiLE 4が利用され，管理者所持のポケッ
トベル50における電話番号データ（以下ポケベル番号デ
ータと称する）が記憶される。

メール検知機能57としては，例えば，ゲートなど利用
して構成され，不在モード中に他端末4B,4D…からメー
ルが届いた際，これを検知するようになっている。メー
ルを検知すると，個人ファイルFiLE 5を検索して該当す
る端末（コンピュータ）が不在であるか確認したうえで
不在および各種デーダ通知機能59を作動させる。

不在および各種データ通知機能59としては，相手端末
のディスプレイ（図示省略）に対して各種データを表示
するための表示テーブル60を必要に応じて設定し，これ
を相手端末すなわちメールを送信してきた他端末4B,4D
…に対して通信オブジェクト51を介して通知するように
なっている。その各種データとしては,1つには，メール
を受信した際において通知する不在データである。具体
的には，第１に現在管理者が外出中であること，これに
付加えて第２に当該メール内容をこちらに保存するかを
確認すること，第３に管理者の外出先またはポケットベ
ル50の電話番号を知りたいかを確認すること，第４に交
換手に管理者を捜し出してもらいたいかを確認するこ
と，そして第５に前記第2,第3,第４のいずれか，もしく
はその全てが所望されるならば相手端末（この場合他端
末4B,4D…）の端末No.やID・No.,氏名など送信してもら
いたいこと等々を示すデータである。

もう１つには，前記第４にあたる相手端末からの端末
No.やID・No.や氏名などを受信し，これを後述するデー
タ確認機能62により確認したうえで通知するデータであ
り，前述した外出先データ記憶部53内に記憶された管理
者の外出先データ，またはポケベル番号記憶部55内に記
憶されたポケベル番号データ，もしくはその双方であ
る。

捜索依頼機能61としては，交換網の交換手（オペレー
タ）に対して管理者を捜索してもらうことを依頼する機
能を有している。これは，先の不在および各種データ通
知機能59を介して，管理者の捜索要求データ，および外
出先データ，またはポケベル番号データ，さらに自端末
No.,またはメールを送信した側の端末No.などを送信す
る機能である。

なお，捜索依頼機能61は，メールを送信した他端末4
B,4D…の端末No.やID・No.などが知らされたことを後述
するデータ確認機能62によって確認されたときに，上述
の如く作動するようになっている。

データ確認機能62としては，他端末4B,4D…から送ら
れたデータの種類などを識別できるようになっている。
具体的には，メールを送信した他端末4D…から知らされ
る端末No.やID・No.などに係わるデータ，更にはその他
端末4D…からの返答であり，メール保存要求，外出先デ
ータ転送要求，ポケベル番号データ転送要求，捜索依頼
要求に係わるデータなどを識別することができる。これ
らデータの種類を確認すると，それが例えば前記端末N
o.やID・No.などに係わるデータであれば後述するメー
ル記憶部63にそのデータおよび当該メールの内容を保存
させるとともに，後述するメール報告機能65に対してそ
の旨知らせるように働く。一方，前記各種要求に係わる
データであれば先の不在および各種データ通知機能59に
対していかなるデータを通知すべきか指示するように働
く。

この他，管理者が外出先である他端末例えば4B（図示
省略）から特種なキーワードなどをもってメール参照要
求を送った際にもこれを確認することができる。この場
合，その外出先である他端末4B,4Dに対して後述するメ
ール記憶部63内に保存されてあるメール，および他端末
No.やID・No.などのデータを送信するように働く。

メール記憶部63としては，例えば自局4A内のＴ出力フ
ァイルFiLE 1が利用され前述した他端末例えば4D（図示
省略）からのメール，端末No.やID,No.,氏名などが保存
されるようになっている。

メール報告機能65としては，管理者が外出先である例
えば公衆電話機（図示省略）などから自局4Aの電話機
（図示省略）の留守番電話機能66に対して連絡を入れた
際，この留守番電話機能66に例えばメロディーなどを出
力してメールが届いている旨報告するよう機能するよう
になっている。

第20図は不在登録／処理の動作の一例を示すフローチ
ャートである。なお，ここではメールを送信した他端末
4Dがポケベル番号を入手する際のフローとして説明す
る。

また，メールを送信した側を甲端末4Dとし，管理者不
在側を乙端末4Aとし，管理者の外出先側を丙端末4Bとす
る。

まず，ステップ20−１において，甲端末4Dにて乙端末
4Aにおける目的ID要求を発生すると，続いてステップ20
−２において，この要求が乙端末4Aの通信オブジェクト
51に伝達される。

この状態のもと，ステップ20−３において，当該要求
データが乙端末4Aにて個人情報ファイル（又は個人ファ
イル）FiLE 5へ伝送される。続いてステップ20−４にお
いて，前記個人情報ファイルFiLE 4は「目的IDなし」す
なわち管理者不在であると回答する。そして，ステップ
20−５において，その回答とともに目的IDすなわに管理
者のポケベル番号データも送出する。

この状態に至ると，ステップ20−６において，甲端末
4Dでは，自局4Dの通信オブジェクトを経て先の回答，お
よびポケベル番号データに係わる情報を受信する。これ
により，ステップ20−７において，甲端末4Dでは，交換
網（図示省略）におけるポケベル送信端末3Aに対してポ
ケベル番号を送出する。

このようにして管理者を捜し出して呼び出せる状態に
なると，まず，ステップ20−８において，管理者所持の
ポケットベル50にて「呼び出し」であることを目的IDが
受信する。続いて，ステップ20−９において，目的IDで
ある持ち主，すなわち乙端末4Aの管理者は，外出先であ
る丙端末4Bより乙端末4A（自端末）を呼び出す。続いて
ステップ20−10において，丙端末4Bにて乙端末4Aより端
末No.と要求元のID・No.を入手する。

このようにして，ステップ20−11において，管理者は
丙端末4Bより甲端末4Aを呼び出す。これにより，甲端末
4Aは管理者のいる丙端末4Bと通信可能になる。

したがって，本実施例によれば，メールを送信してき
た甲端末4Aに対して管理者不在である乙端末4Aでは，ポ
ケベル番号データを用いることによって管理者と連絡を
とることが可能であるとの考えをもって交信することが
できる。これにより，外出先である丙端末4Bから交信を
得た甲端末4Aでは，先の乙端末4Aから例えばプログラム
を借用したい，もしくは当該乙端末4Aにおいてデータ保
存を代行して欲しい等々といった希望を伝えることがで
きる。そのようなとき管理者は，先の乙端末4Aに対し
て，遠隔操作など行うことにより，乙端末4Aでは，甲端
末4Dに対して，その希望に沿うように交信することなど
が可能となる。

なお，第20図のフローチャートには，ステップ20−５
に管理者のスケジュール表やオペレータに捜索依頼を出
すか否かなどのデータを送出するようにしても良いし，
各記憶部53,55,63は同一のファイルで構成しても良いこ
とは勿論である。

上記第３図に関連して説明したチャット，第４図や第
５図に関連して説明した配信（メール），第６図に関連
して説明したRCS（リモート・コンピュータ・サービ
ス）に関して，夫々の動作フロー内に「通信処理方式」
に対応する交信処理が介在することを示した。

当該第３図ないし第６図にて説明した通信処理方式に
おいては，いわば１対１通信を前提として説明してい
る。しかし，一般には，第29図に関連して説明した如
く，通信網が複雑となっており，公衆網や専用線が混在
する。そして通信網の利用の仕方によって通信コストが
増・減する。

以下，公衆網と専用線とが混在する通信網における効
率のよい通信制御方式について説明する。

第21図は通信制御方式を説明する図であり，図中の符
号１−１は公衆網,2は専用線,10A,10B,10C,10Dは夫々
群,3A,3B,3C,3Dは夫々管理局端末,4A,4B,4C,4Dは夫々一
般端末を表している。

各群内には少なくとも１つの管理局端末3A,3B,……が
存在し，抽出機能11Tiと通知機能12−１Tiとをそなえて
いる。例えば管理局端末3Aにおける抽出機能11Aとして
は，（ｉ）少なくとも自己群10Aに属する端末（3A,4A）
に関してはメモリ上に保持し，（ii）他群10B,10C,……
に属する端末（3B,4B,3C,4C,……）に関しては，メモリ
上に保持するか必要に応じて対応する管理局端末3B,3C,
……に問い合わせるなどして図示の如き端末情報を把握
できるように構成される。当該端末情報には，（ｉ）Ｔ−NO:端末IDで記述される。

（iv）通信形態：どのような接続態様をもって接続すべ
きかについての通信形態が記述される。

また通知機能12−1Aは，例えば端末（T₁）からの問い
合わせによって，上記端末情報を端末（T₁）などに通知
するよう構成される。

なお，各一般端末４および各管理局端末３には，通信
形態判断機能12−２がもうけられている。当該通信形態
判断機能12−２は，自端末のオペレータが発呼した発信
呼について，あるいは他端末から転送されてきた発信呼
について，当該発信呼を接続すべき通信形態を判断し，
必要とする処理態様をとるように構成されている（発信
呼に通信形態が自動的に定まるか記述されていると考え
てよい）。

例えば図示端末（T₁）が端末（T₂）と通信する場合に
は，端末（T₁）のオペレータは，所望する通信形態を知
り，端末（T₂）に直接通信する。

また端末（T₁）が端末（T₄）と通信する場合には，管
理局端末（AT）3Aから専用線２を経由し管理局端末（B
T）3Bを利用して，通信するようにする。

端末（T₁）が端末（T₉）と通信する場合には，管理局
端末（AT）3Aを経由して通信するようにする。

更に，端末（T₁）が端末（T₁₁）と通信する場合に
は，管理局端末（DT）3Dに通信し，当該管理局端末（D
T）3Dが端末（T₁₁）に通信するようにする。

更に言えば，端末（T₁）が端末（T₁₁）と端末（T₁₂）
とに夫々同じ内容を通信する場合には，端末（T₁）が管
理局端末（DT）3Dに通信し，当該管理局端末（DT）3Dが
端末（T₁₁）と端末（T₁₂）とに通信する。

第22図は本発明による第１の通信形態を示す。端末
（T₁）から端末（T₁₁）に通信する場合，端末（T₁）か
ら端末（T₁₁）に直接通信する場合の通信コストが，端
末（T₁）から管理局端末（DT）3Dへの通信コストと，管
理局端末（DT）3Dから端末（T₁₁）への通信コストとの
和より安価であることがある。このような場合には，第
21図図示の抽出機能11Aにおいて通信形態として「DT経
由」が抽出される。

第23図は本発明による第２の通信形態を示す。端末
（T₁）からの遠隔地の端末（T₁₁）と端末（T₁₂）とに同
じデータを通信する場合，従来は夫々の端末に対して夫
々遠隔通信を行っていたが，第23図図示の如く，管理局
端末（DT）3Dに通信を行い，管理局端末（DT）3Dから端
末（T₁₁）と端末（T₁₂）とに夫々通信する。

第24図は本発明の第３の通信形態を示す。端末（T₁）
から専用線を利用する通信の場合，端末（T₁）に最も近
い管理局端末（AT）3Aを経由して専用線に通信するよう
にする。なお管理局端末（AT）3Aは公衆網１−１と専用
線２との両者に連繋されているものとする。この場合，
通信形態として第21図図示の如く「AT経由」が抽出され
る。

第25図は本発明の第４の通信形態を示す。専用線上の
端末例えば端末（T₉）から端末（T₄）に通信する場合，
端末（T₄）に最も近い管理局端末（BT）3Bを経由して通
信するようにする。なお管理局端末（BT）3Bは公衆網１
−１と専用線２との両者に連繋されているものとする。
第21図図示の如き抽出機能11iにおいては，管理局端末
（CT）3Cにおける抽出機能11C（図示せず）が通信形態
として「専用線経由」を抽出する。

第26図は本発明の第５の通信形態を示す。端末（T₁）
から端末（T₄）と通信する場合，専用線を有効に利用す
ることが望まれるものとすると，端末（T₁）から管理局
端末（AT）3Aに通信し，ついで専用線２上の端末である
管理局端末（BT）3Bに通信し，ついで端末（T₄）に通信
する。第21図図示の抽出機能11Aによって通信形態とし
て「専用線経由」が抽出される。

第27図は直接通信する場合の処理態様を示す。第21図
図示の端末（T₁）が端末（T₃）と通信する如き場合，端
末（T₁）からオペレータが端末（T₃）に対して通信要求
を発したとすると，端末（T₁）における通信形態判断機
能12−２T₁は，（ｉ）端末（T₁）からのオペレータの指
示した情報によるか，（ii）あるいは管理局端末（AT）
3Aからの端末情報中の端末（T₃）に対応する「通信形
態」を受け取っていて，端末（T₃）に対して直接接続を
行うように呼び出しをかける。

第28図は管理局端末経由の通信を行う場合の処理態様
を示す。図示の場合には，端末（T₁）が専用線上の端末
（T₁₀）と通信するものとして示されている。

オペレータが端末（T₁₀）に対して通信要求を発した
とすると，端末（T₁）における通信形態判断機能12−２
T₁は，管理局端末（AT）3Aを呼び出し，当該管理局端末
（AT）3Aと接続されると，データ送信を行う（端末（T
₁₀）あてのデータ）。一方，管理局端末（AT）3Aにおい
ては，当該データを受信し，当該データをメモリ上に記
憶する。そして，管理局端末（AT）3Aにおける通信形態
判断機能12−2Aは，端末（T₁₀）に対する通信形態を確
認し，専用線２を選択し，端末（T₁₀）を呼び出す。当
該端末（T₁₀）と接続されると，データ送信を行う。こ
れに対応して，端末（T₁₀）はデータを受信する。

なお，第21図図示の端末（T₁）が端末（T₄）と通信す
る如き場合には，第28図図示の通信形態判断機能12−2A
と図示の端末（T₁₀）との間に，管理局端末（BT）3Bに
よる仲介が今１つ介在する形となる。

第８図図示の通信処理方式の動作フローは，上記第21
図ないし第28図に関連して説明した動作に対応してい
る。

第８図において，「単」／「複」としているのは，通
信網が単一の網であるか複数の網（少なくとも１つが専
用線である場合も含む）であるかを表わしている。また
第８図において「自網」／「相手網」としているのは，
自己端末が属する網内の端末に対する通信か，自己端末
が属する網以外の網における端末に対する通信かを表わ
している。

第３図ないし第６図に示す各動作フローにおいて，図
示の「通信処理方式」の個所に至ると，夫々が第８図図
示の「通信形態判断」の処理に入ると考えてよい。

当該通信形態判断は，第21図を参照して説明した通信
形態判断機能12−2Aなどによって判断される。第３図な
いし第６図に示す各動作フローにおいて図示の「通信処
理方式」の後段に記述されているフローは，例えば第21
図図示の端末T₁が同一群内の端末T₂へ通信する場合の如
く，管理局端末AT,BT,…を介在することなく直接的に通
信することができる場合に対応するフローを表わしてい
る。しかし，一般には，第21図を参照して説明した如
く，通信網が複雑であり，第８図図示の動作フローにし
たがう形となる。

第８図図示の「通信形態判断」において「振り分け」
が行われる。そして，上述した如く管理局端末（AT,BT,
CT,DT）を介在することなく直接通信できる場合には，
第３図ないし第６図図示の動作フローに向う。しかし，
管理局端末を経由する場合には，上記「単」／「複」の
判断が行われる。

「単」の場合には，第21図図示の専用線２が存在して
いない如き通信網において図示の端末T₁から端末T₁₁へ
の通信に関して第22図や第23図を参照して説明した如き
「端末間通信方式」の形態がとられる。これに対して
「複」の場合には上述の「自網」／「相手網」の判断が
行われる。

ここで自網の場合も相手網の場合も，動作フローにつ
いて言えば実質的に同じであるので，以下自網の場合に
ついて説明をつづける。この際の動作フローは，第28図
図示の場合と同じであるが，第８図図示の場合には自網
の管理局端末が呼び出されるべき旨が判明した後のもの
と考えてよい。

第21図図示の端末T₁が端末T₄と通信する場合を例にと
ると，自網の管理局端末（AT）3Aが管理局端末（BT）3B
を呼び出す。そして，送信すべきデータと相手端末T₄の
ナンバとを送信する。なお，このときのデータは，チャ
ットの場合のデータであったり，配信の場合のデータで
あったり,RCSの場合のデータであったりする。

呼び出された管理局端末（BT）3Bは，データを受信し
て，それを記憶する。そして，相手端末T₄を確認する。

その後，端末T₄に対応する網を選択する。即ち今の場
合には，管理局端末（BT）3Bにおける通信形態判断機能
12−2Bにおいて，端末T₄と交信する通信形態が明らかに
される。この結果にもとづいて，管理局端末（BT）3Bは
端末T₄を呼び出し，データを送信する。端末T₄において
データを受信すると，管理局端末（BT）3Bは更に送信す
べき端末が存在するか否かにしたがって，存在すれば複
数回繰返される。

なお，第８図図示の動作フローにおいては明らかにし
ていないが，相手端末との交信に当って，上述のチャッ
トやRCSなどの場合に，非所望に長期間回線を確保して
おくことを避けるために，第３図や第６図図示の如く，
一回分の通信が終了すれば，回線を切断し，必要なデー
タが現われたとき回線を接続するような形態での通信が
行われる。このことは，第１図に関連して説明した如
く，接続タイミング・テーブル17を利用して行われる。

〔産業上の利用可能性〕

以上のように，本発明に係るネットワーク・コントロ
ール・システムは，複雑な通信網の下で，チャットや配
信やRCSなどの各動作や相手方不在時の処理などに当っ
て，通信網を効率よく利用する技術に適用できる。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号特願平2 −4810 (32)優先日平２(1990)１月12日 (33)優先権主張国日本（ＪＰ） (31)優先権主張番号特願平2 −9334 (32)優先日平２(1990)１月18日 (33)優先権主張国日本（ＪＰ） (72)発明者岡崎秀世東京都八王子市久保山町１―39―１富士通宇津木寮440号室 (72)発明者筧元神奈川県横浜市緑区荏田南５丁目20―９ ―101 (72)発明者橋本朗神奈川県横浜市緑区松風台30―１―207 (72)発明者遠藤守神奈川県相模原市南台２―８―１―110 (72)発明者山縣満彦埼玉県久喜市東１丁目６番15号 (56)参考文献特開昭61−148941（ＪＰ，Ａ) 特開昭62−24792（ＪＰ，Ａ) 特開昭61−184022（ＪＰ，Ａ) 特開昭62−236238（ＪＰ，Ａ) 特開昭61−210745（ＪＰ，Ａ) 特開昭62−190951（ＪＰ，Ａ) 特開昭63−250953（ＪＰ，Ａ) 特開平１−226248（ＪＰ，Ａ)

Claims

(57)【特許請求の範囲】

【請求項１】画面を含む情報を他端末に伝送し表示する
画面表示機能とキーボードを操作しつつ他端末とリアル
タイムで交信するチャット機能とを少なくとも含む複数
の機能を有する端末（3,4……）をそなえると共に、当該各端末（3,4……）が通信網（１）を介して連繋さ
れてなり、上記端末相互間において上記画面表示機能あるいはチャ
ット機能にもとづく通信を実行するようにされるネット
ワーク・コントロール・システムにおいて、少なくとも送信側となる端末（３又は４）において送出
する通信コマンド内に、上記複数の機能のうちの自己が
現に行おうとする１つの機能を特定するモードと当該モ
ードの下における複数種類の動作のうちの１つを特定す
る通信コードとを記述すると共に、当該送信側となる端末（３又は４）が、上記モードと上
記通信コードとを解読して当該モードと当該通信コード
とを用いて接続タイミング・テーブル（17）を索引する
よう構成され、かつ当該接続タイミング・テーブル（1
7）の内容で与えられる通信回線の接続または切断指示
にもとづいて、相手方となる上記他端末（３又は４）と
の間の通信回線を接続しまたは切断するよう構成されて
なることを特徴とするネットワーク・コントロール・システ
ム。
【請求項２】上記端末は、同一の通信網（１）に連繋さ
れている複数の端末（３又は４）をグループ化した群
（10）を構成すると共に、当該単一の群（10）毎に少な
くとも１つの管理局端末（３）をそなえ上記夫々の群（10）内の管理局端末（３）が、自己群
（10）内の端末（４）と他群（10）内の端末（３又は
４）とに関する端末情報を抽出可能に構成される抽出機
能（11）を有すると共に、少なくとも自己群（10）内の
端末（４）からの問い合わせに対応して上記端末情報の
全部または一部を通知する通知機能（12−１）を有し、上記夫々の端末（４）は、通信相手となる端末（３又は
４）に関する上記端末情報を知り、少なくとも自己群内
の管理局端末（３）あるいは他群内の管理局端末（３）
を経由して、上記相手となる端末に対して通信するよう
にしたことを特徴とするクレーム（１）記載のネットワーク・
コントロール・システム。
【請求項３】上記通信網（１）が、少なくとも１つの公
衆網（１−１）と少なくとも１つの専用線（２）とより
なり、上記少なくとも２つの群内の管理局端末（３）が、上記
公衆網（１−１）と上記専用線（２）との両者に連繋さ
れて、両者間での通信の中継を行うよう構成されていることを特徴とするクレーム（１）記載のネットワーク・
コントロール・システム。
【請求項４】上記夫々の端末（４）および上記夫々の管
理局端末（３）において、発信呼に対応して当該発信呼
が採用すべき通信形態を判断する通信形態判断機能（12
−２）を有し、当該通信形態判断機能（12−２）の判断
にもとづいて個々の発信呼を処理するようにしたことを特徴とするクレーム（１）記載のネットワーク・
コントロール・システム。
【請求項５】一つの端末（３又は４）を発信局とし、他
の複数の端末（３又は４）を受信局として通信網（１）
を介して端末間で実データを配信するネットワーク・コ
ントロール・システムにおいて、該発信局が、自局の配信実データと該受信局の配信順序
を指定するための配信順路データとを該通信網（１）を
介して最初の受信局に送信し、以後、該配信順序に従っ
て該通信網（１）を介して各受信局間で該実データの転
送を行うことを特徴としたクレーム（１）記載のネット
ワーク・コントロール・システム。
【請求項６】受信局が、該実データの配信を受けたと
き、該通信網を介して該発信局に対して受信確認情報を
返信すると共に、最終受信局が、該受信確認信号及び該
実データを返信することを特徴としたクレーム（５）記
載のネットワーク・コントロール・システム。
【請求項７】互いの間で通信を行う複数の端末（３又は
４）と、前記端末（３又は４）の間での通信を制御する
ホスト（３）とを備えた通信システムにおいて、前記端末（３又は４）と前記ホスト（３）との間及び前
記端末（３又は４）の間を通信網（１）を介して接続す
る交換機（３）を備え、前記ホスト（３）が、前記夫々の端末のネットワーク上
のアドレスを管理するよう構成されてなり、当該ホスト（３）が、１つの端末（３又は４）からの他
の端末（３又は４）との通信の要求に応じて当該他の端
末（３又は４）を呼出して確認し、この後、前記交換機
（３）に対して当該１つの端末（３又は４）及び他の端
末（３又は４）を接続するように制御を行い、前記交換機（３）が、この制御に従って、当該１つの端
末（３又は４）及び他の端末（３又は４）を接続し、当
該１つの端末（３又は４）からのデータを当該他の端末
（３又は４）へスルーさせることを特徴とするネットワーク・コントロール・システ
ム。
【請求項８】通信網に加入する多くの端末のうち、管理
者不在である端末（4A）と、これにメールを送信した他
端末（4D…）とを交信させるようにした通信システムに
おいて、少なくとも１つの前記端末（4A）に、不在モード設定機能（74）と、当該管理者所持のポケットベル（50）における電話番号
データを記憶するポケベル番号記憶部（82）と、前記他端末（4D…）からのメールを検知するメール検知
機能（75）と、前記他端末（4D…）からの前記メールおよびその他端末
（4D…）の端末ナンバ又はIDナンバを記憶するメール記
憶部（76）と、管理者不在および前記ポケベル番号記憶部（82）に記憶
された電話番号データを通知する不在および電話番号デ
ータ通知機能（83）とを備え、前記端末（4A）に他端末（4D…）からメールが送信され
た際、前記不在および電話番号データ通知機能（83）の
起動により、前記ポケベル番号記憶部（82）内に記憶さ
れた電話番号データを通知し、管理者所持のポケットベ
ル（50）を呼び出させることを可能にした、ことを特徴とするネットワーク・コントロール・システ
ム。
【請求項９】前記端末（4A）に、管理者所持のポケットベル（50）を呼び出すポケベル呼
び出し機能（84）を備え、メールを送信してきた他端末（4D）側からの要望によ
り、前記ポケベル呼び出し機能（84）を起動させ、当該
他端末（4D）では、管理者からの連絡を待てるようにし
たことを特徴とするクレーム（８）記載のネットワーク・
コントロール・システム。
【請求項１０】前記端末（4A）に、自局（4A）の電話機に交信要求が出された際、この電話
機に自局（4A）にメールが届いている旨出力させるメー
ル報告機能（85）を備えた、ことを特徴とするクレーム（８）記載のネットワーク・
コントロール・システム。