JP3945270B2 - 発呼サーバー装置 - Google Patents
発呼サーバー装置 Download PDFInfo
- Publication number
- JP3945270B2 JP3945270B2 JP2002052758A JP2002052758A JP3945270B2 JP 3945270 B2 JP3945270 B2 JP 3945270B2 JP 2002052758 A JP2002052758 A JP 2002052758A JP 2002052758 A JP2002052758 A JP 2002052758A JP 3945270 B2 JP3945270 B2 JP 3945270B2
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- information
- communication
- call
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Telephonic Communication Services (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、インターネットを介したサーバークライアントシステムにおけるサーバー装置に関するものである。
【０００２】
【従来の技術】
インターネットの急速な普及に伴い、サーバークライアント型のシステムが広まっている。特に、商用システムでは、ＷＷＷ（World Wide Web）を中核とした、ＡＳＰ（Application Service Provider）システムが普及している。このシステムの従来例を図７に示す。
【０００３】
１０１は家庭内やオフィス内にある端末である。通常は、パソコンや携帯電話などの端末が多いが、サービスに特化された専用の端末もある。１０２はＷｅｂサーバーやＣＧＩなどのプログラムからなるアプリケーションサーバー。１０３はユーザ情報などサービスに関わるすべての情報を格納するデータベースである。図に示すように、アプリケーションサーバー１０２とデータベース１０３は情報センター内に設置されている。
【０００４】
従来では、宅内に設置された端末１０１は、公衆電話回線を利用してプロバイダへ接続し、さらにインターネットを介して情報センター内のアプリケーションサーバー１０２に接続する。アプリケーションサーバー１０２では、データベース１０３とデータのやり取りを行いながら情報処理を行い、ユーザが希望する情報通信サービスを行う。
【０００５】
なお、この図ではファイヤウォールやルータなどのネットワーク機器を省略して記載している。
【０００６】
【発明が解決しようとする課題】
しかしながら、上記した従来のシステムでは、以下のような課題があった。
【０００７】
（１）端末と情報センター内のサーバーがインターネットを介して通信を行うためには、まず端末側からプロバイダへ発呼する必要があり、サーバー側からデータ送信を開始することができない。
【０００８】
つまり、サーバー側がイニシアチブを取って、情報をタイムリーに宅内端末に送信することができなかった。
【０００９】
（２）端末のインターネットへの接続には、さまざまな種類の通信媒体が利用されている。例えば、アナログ電話、ＩＳＤＮ回線、携帯電話などの無線通信など。接続の手順や通信方法はこれらの回線種別に異なるため、サーバーから端末への発呼はすべてのケースを考慮しなければならず、実現が難しかった。
【００１１】
【課題を解決するための手段】
本発明は上記課題を解決するために、情報センター内に発呼サーバー装置を設ける。発呼サーバー装置は、端末に対して情報通信サービスを行う少なくともひとつ以上のアプリケーションサーバーからの発呼命令を受信し、ユーザＩＤ・端末ＩＤ情報を抽出する命令解釈部と、少なくとも一種類以上の通信回線と接続してデータの送受信を行う通信部と、前記ユーザに関連する情報を記憶するユーザ情報データベースと、前記端末に関する情報を記憶する端末情報データベースと、端末種別および回線種別毎に発呼手順や発呼方式を記憶する発呼方式データベースと、前記命令解釈部で得られた前記ユーザＩＤと前記端末ＩＤ情報とから、前記ユーザ情報データベース、前記端末情報データベース、前記発呼方式データベースを検索し、得られた通信相手先情報・回線種別・通信手順情報にしたがって前記通信部を制御し、前記端末へ向けて発呼する発呼制御部とを備える。
【００１５】
【発明の実施の形態】
本発明の請求項１にかかる発呼サーバー装置は、端末に対して情報通信サービスを行う少なくともひとつ以上のアプリケーションサーバーからの発呼命令を受信し、ユーザＩＤ・端末ＩＤ情報を抽出する命令解釈部と、少なくとも一種類以上の通信回線と接続してデータの送受信を行う通信部と、前記ユーザに関連する情報を記憶するユーザ情報データベースと、前記端末に関する情報を記憶する端末情報データベースと、端末種別および回線種別毎に発呼手順や発呼方式を記憶する発呼方式データベースと、前記命令解釈部で得られた前記ユーザＩＤと前記端末ＩＤ情報とから、前記ユーザ情報データベース、前記端末情報データベース、前記発呼方式データベースを検索し、得られた通信相手先情報・回線種別・通信手順情報にしたがって前記通信部を制御し、前記端末へ向けて発呼する発呼制御部とを備える。
【００１６】
この構成では、ユーザがどの回線を利用しているか、端末にどの通信手順を用いるか、などの情報が、ユーザ情報データベースや端末情報データベース、発呼方式データベースに格納されている。したがって、アプリケーションサーバーは発呼に際しての、回線種別毎の制約や端末な相違を意識することなく、サービスを実現することができる。また、ユーザ・端末・通信手順に関する情報が発呼サーバーに一元管理されているので、複数のアプリケーションサーバーが１台の発呼サーバーを共有する場合などは、発呼や回線に関する情報をそれぞれのアプリケーションで管理する必要がないというメリットもある。
【００３５】
【実施例】
以下、本発明の実施例について図面を用いて説明する。
【００３６】
（実施例１）
図１は本実施例の全体構成を示した図である。図１において、１は宅内に設置された端末（サービスに特化した専用端末やパソコン、携帯電話、インターネットＴＶなど）。２は情報センター等の中に設置されたアプリケーションサーバーであり、端末１とデータの送受信を行い、ユーザに情報通信サービスを提供する。アプリケーションサーバー２は、一般にＷｅｂサーバーやメールサーバーなどを中心に構築されることが多く、コンテンツ情報であるＨＴＭＬ／ＸＭＬファイルや画像・音声ファイルだけでなく、認証、データベース接続、メール配信、データ処理、ＨＴＭＬ／ＸＭＬ動的生成などを行うＣＧＩ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ などにより書かれたプログラムも含んでいる。３はデータベースであり、アプリケーションサーバー２で実行される情報サービスに必要なデータを記憶する。一般的には顧客情報データベースやＨＴＭＬ／ＸＭＬなどコンテンツ、端末情報、処理履歴などであり、この内容は提供するサービスに応じて変化する。４は発呼サーバーであり、アプリケーションサーバー２から発行される命令に応じて、宅内の端末１へ向けて発呼する装置である。
【００３７】
図１に示すように、端末とサーバーへの接続方法には２つの経路がある。ひとつは、端末１から発呼して、アナログ電話回線やＩＳＤＮ回線などの公衆電話網を経由してプロバイダ（インターネットサービスプロバイダ）へ接続し、その後インターネットを経由してアプリケーションサーバー２へ接続する経路である（図中の（Ａ））。もうひとつは、発呼サーバー４から発呼して、インターネットを利用せず、公衆電話網を介して端末へ直接接続する経路（図中の（Ｂ））である。
【００３８】
なお、発呼サーバー４へ発呼命令を発行するのは、ひとつのアプリケーションサーバー２だけでなく、図に示すように同一情報センター内の複数のアプリケーションサーバー（ａ，ｂ，ｃ）であってもよいし、また、さらに通信回線で結ばれた他の情報センターのアプリケーションサーバー（図中２’）であっても良い。発呼サーバー４は、複数のアプリケーションで共有可能であり、それによりサービスあたりの運用コストが安くなるというメリットが出てくる。また、図１では端末は宅内にあるとしたが、宅外に存在するモバイル端末の様な物でも良い。
【００３９】
図２は、発呼サーバー４の構成の詳細を示したものである。１０はアプリケーションサーバー２からの命令を解釈して、通信相手先情報や端末ＩＤを抽出する命令解釈部。１１は命令解釈部１０で得られた情報から発呼に必要な情報を検索し、通信を制御する発呼制御部。１２は端末の種別や利用する回線種別毎もしくは、サービス内容毎に発呼手順や発呼方式を記憶する発呼方式データベース。１３は端末に関する情報（端末ＩＤ、メーカ名、品番、製造番号、機能コードなど）と、端末を電源オフあるいは待機状態から動作状態へ遷移させるための起動信号や起動コードを、端末毎に記憶している端末情報データベース。１４はユーザに関する個人情報およびユーザＩＤ，利用している端末種別、端末ＩＤ，使用回線種別などユーザと端末に関する情報を記憶しているユーザ情報データベース。１５は複数の種類種類の回線と繋がっており発呼制御部１４の命令にしたがって端末と通信回線を介して接続する通信部。１６は発呼制御部１４からの命令に応じて通信デバイスを選択し、指定された通信手順に応じて発呼処理を行うデバイス制御部。１７はＰＢ信号（ＤＴＭＦ信号）や音声信号を出力するＰＢモデム。１８はアナログ電話回線を介したＰＰＰ接続やＴＣＰ／ＩＰによるデータ通信や音声信号出力を行うモデム。１９はＩＳＤＮ回線に接続して発呼および通信を行うＴＡ／ＤＳＵ。２０はアナログおよびデジタルの電話回線に接続して発呼し、シリアル通信を行うリンギング用Ｃ−ＮＣＵ。２１はアナログ電話回線に接続してノーリンギング発呼を行い端末に着信してデータ通信を行うノーリンギング用Ｃ−ＮＣＵである。
【００４０】
なお、図２に示すように１６〜２１は通信部１５の構成要素である。２２は発呼制御部１１およびデバイス制御部１４の制御内容をログとして記録し、ユーザ毎、サービス毎、アプリケーションサーバー毎などについて、発呼時刻、通信時間、通信結果などを記録するログ記憶部である。
【００４１】
以上のように構成された発呼サーバー装置について、図３のフローチャートを用いて各部の動作を説明する。
【００４２】
アプリケーションサーバー２は、端末とインターネットなどを介して通信を行い情報サービスを行うサーバーである。これは、前述したように、Ｗｅｂサーバーを中心に構成されており、ＣＧＩやＪａｖａなどのプログラムと、ＨＴＭＬ／ＸＭＬや画像・音声などのコンテンツファイルなどが格納されている。プログラムやコンテンツの内容は、ユーザに提供するサービスの種類に応じて異なる。図３は、アプリケーションサーバー２が提供する情報サービスの一部として、アプリケーションサーバー２から、ユーザの端末に向けて発呼命令が出された場合を示している。
【００４３】
（ステップＡ１）アプリケーションサーバー２内のプログラムは、発呼サーバー４に向けて発呼命令（コマンド）を出力する。ここでは。以下のような命令が出力された例を説明する。
【００４４】
命令：Send（"１００１"，"Ｍ０１２３４５６７８９"，"test.dat"）；
"１００１"はユーザＩＤ、"Ｍ０１２３４５６７８９"は端末ＩＤ、"test.dat"は転送する情報ファイルの例である。この命令は、「ユーザ（ユーザＩＤ"１００１"）の利用する端末（端末ＩＤ"Ｍ０１２３４５６７８９"）へ発呼し、"test.dat"というファイルを転送せよ。」という命令である。ユーザＩＤとは、各ユーザ毎に一意に割り振られている番号であり、通常はデータベース３およびユーザ情報データベース１４にユーザの氏名・住所などの個人情報とともに記録されている。端末ＩＤは、端末毎に一意に割り振られている番号であり、これもデータベース３および端末情報データベース１３に記録されている。
【００４５】
"test.dat"は、転送するファイルの一例である。ファイルはサービスに応じて様々な場合があり、さらにコールバックをさせる場合などは、転送する必要がない。ファイル送信が必要出ない場合は、Send（"１００１"，"Ｍ０１２３４５６７８９"）；といった形で、ファイル名を指定する必要はない。
【００４６】
なお、上述した命令は一例にすぎず、発呼に必要な様々な他のパラメータをこの命令と同時に発呼サーバー４へ送ることができる。また、端末ＩＤが一意に付与されていない場合は、メーカ名や製造番号などの他のパラメータを指定しても良い。
【００４７】
（ステップＡ２）アプリケーションサーバー２から出力された発呼命令を命令解釈部１０で解析し、命令で指定されたユーザＩＤ、端末ＩＤや、その他の発呼に必要な通信パラメータを取り出す。取り出した情報は発呼制御部１１へ出力する。
【００４８】
（ステップＡ３）発呼制御部１１は、命令で指定されたユーザＩＤからユーザ情報データベース１４を検索し、ユーザの利用している回線に関する情報（回線種別や相手先情報など）を取得する。
【００４９】
ユーザ情報データベース１４には、各ユーザの情報が記憶されている。具体的な例を挙げると、以下のような項目が記憶されている。
【００５０】
個人情報：ユーザＩＤ、氏名、性別、年齢、住所、電話番号、電子メールアドレス、職業などの個人情報など。
【００５１】
端末情報：ユーザが利用している端末のＩＤ（ユーザＩＤ毎に）回線情報：回線種別、相手先情報（回線番号）、認証情報、設置形態、ルータの有無（端末ＩＤ毎に）。
【００５２】
ここでの回線種別とは、アナログ電話回線、ＩＳＤＮ回線、ＰＨＳ、ＡＤＳＬなど、通信媒体の種類を意味している。相手先情報（回線番号）とは、電話番号やＩＰアドレスなど通信において通信先を特定するために必要な情報を意味する。また、認証情報とは回線を接続する際に、認証が必要な場合（ログインＩＤ、パスワードなどが求められる場合）に設定する情報である。ユーザＩＤ、端末ＩＤは、全体に渡ってユニークになるように設定する。
【００５３】
この検索により、ユーザ毎に固有な通信情報（回線種別、電話番号などの通信相手先情報など）が取得できる。
【００５４】
（ステップＡ４）発呼制御部１１は、命令で指定された端末ＩＤから、端末情報データベース１３を検索し、端末種別や起動コードなどの情報を取得する。端末情報データベース１３には、各端末に固有の情報が記憶されている。例えば以下のような項目の情報である。
【００５５】
端末情報：端末ＩＤ、メーカ名、端末分類、端末種別、品番、製造番号、出荷日、端末起動コード。
【００５６】
ここでの端末分類とは、端末種類の大分類であり、例えば、携帯電話、ＰＣ、健康機器、セキュリティ機器などといった内容の項目である。端末種別とは、端末種類毎にユニークに付与された番号である。端末起動コードとは、端末が電源オフあるいは待機状態から動作状態へ移行させるための命令である。端末起動コードが必要でない端末や、常時電源が入って動作状態にある端末については、記憶させる必要はない。
【００５７】
この検索により、端末毎に固有な情報（端末種別、起動コード）などが取得できる。
【００５８】
（ステップＡ５）発呼制御部１１は、ステップＡ３およびＡ４で得られた端末種別と回線種別から、発呼方式データベース１２を検索、ユーザが利用している回線と端末に適した通信手順や通信方法を取得する。
【００５９】
通信手順や方法は、データの送受信動作を記述するスクリプトで記載する。ただし、通信手順についてはプログラムのような形で記述しても良い。また、発呼時のリンギングの回数や、リンギング時間のような内容や、通信先が話中などの場合にエラーと判断するまでのタイムアウト時間なども、発呼方法として発呼方式データベース１２に端末種別・回線種別毎に記憶されている。
【００６０】
なお、本実施例では、端末種別と回線種別から通信手順を検索したが、サービス種類やアプリケーションサーバー種別などで、検索できるようにしても良い。
【００６１】
（ステップＡ６）発呼制御部１１は、上記のステップで得られた情報（１）回線種別、（２）電話番号やＩＰアドレス等の通信相手先情報、（３）通信手順、（４）必要であれば端末起動コード、（５）必要であればデータファイル名（ここでは、"test.dat"）を基に、通信部１５を制御して発呼を行う。なお、アプリケーションサーバー２から発行された命令に他の通信パラメータ情報が加えられていれば、その情報も加えて発呼を行う。
【００６２】
ここでの発呼の手順は、ステップＡ５で得た通信手順に従って行う。通信手順は上述したように端末種別や回線種別によって異なる。
【００６３】
典型的な通信手順の例を図４および図５のフローチャートに示す。図では、端末種別を仮に機種Ａ〜Ｅとし、アナログ電話回線、ＩＳＤＮ回線などの通信媒体を利用した時の通信手順の事例を示している。
【００６４】
図４（ａ）は、端末が機種Ａという端末種別で、アナログ電話回線で接続する場合の通信手順を示している。この端末ではＰＢ信号（ＤＴＭＦ信号）で通信を行う。
【００６５】
デバイス制御部１６は発呼制御部１１の検索により得られた回線種別や機種種別にしたがって、モデムなどの通信デバイスを制御する。図４（ａ）の場合は回線種別はアナログ電話回線で、端末種別は機種Ａということになる。この場合、デバイス制御部１６は、ＰＢモデム１７を選択し、発呼制御部１１から得られた通信相手先情報（電話番号）にダイアルする（ステップａ１）。宅内の端末に着信後、ＰＢ信号でコールバック用の電話番号情報を送信して（ステップａ２−ａ３）、回線を切断する（ステップａ４）。この時の通信経路は図１の（Ｂ）である。コールバック用の電話番号情報は、アプリケーションサーバー２より、引数のひとつとして渡される。端末は、この通信の後に、通信により指定された電話番号へコールバックして通信を行う。このコールバックの通信経路は、図１の（Ａ）になる。
【００６６】
図４（ｂ）は、端末種別が機種Ｂで、回線種別がアナログ電話回線の場合に、発呼制御部１１で行われる通信手順を示している。この端末ではＰＰＰ（Point to Point Protocol）で接続を確立し、ＴＣＰ／ＩＰを用いてサーバーと通信を行う。
【００６７】
この場合、デバイス制御部１６はモデム１８を選択し、発呼制御部１１から指定された通信相手先（電話番号）へ発呼する（ステップｂ１）。端末へ着信後、端末側モデムとのネゴシエーションを行い、接続が確立された後、発呼制御部１１から指定された認証情報（ログインＩＤ、パスワード）で認証を行いＰＰＰ接続を確立させる（ステップｂ２−ｂ６）。その後、ＴＣＰ／ＩＰを用いてサーバーと端末の間でデータの送受信（例えば、"test.dat"）を行う（ステップｂ７）。データ通信終了後は回線を切断する（ステップｂ８）。
【００６８】
なお、（ａ）の例と同様にデータ通信の時点で電話番号情報を送信し、端末側からコールバックさせるようにしても良い。
【００６９】
また、図４（ｂ）に示すように、端末側に着信したにも関わらず、モデムとの接続に失敗した場合は、何らかの形でユーザが宅内の電話機を操作している可能性が高い。このような場合は、デバイス制御部１６から音声メッセージを出力させて、ユーザに使用法を教えたり、注意を促したりしても良い（ステップｂ５）。この音声メッセージは、アプリケーションサーバー２からも指定可能であるし、また発呼制御部１１で固定にしても良い。
【００７０】
図５（ｃ）は、端末種別が機種Ｃで、回線種別がＩＳＤＮ回線の場合に発呼制御部１１で行われる通信手順を示している。この場合、デバイス制御部１６はＴＡ／ＤＳＵ１９を選択し、発呼制御部１１から指定された通信相手先（電話番号）へ、発番通知情報"１８６"を付加して発呼する（ステップｃ１）。そして端末側回線が使用中（話中）でなければ、発呼制御部１１から指定された回数（時間）だけリンギングして回線を切断する（ステップｃ２−ｃ４）。
【００７１】
この情報により、端末側はサーバーから着信を受けたことがわかるので、端末は所定の電話番号へコールバックできる。
【００７２】
図５（ｄ）は、端末種別が機種Ｄで、回線種別がアナログ電話回線の場合に発呼制御部１１で行われる通信手順を示している。この場合、デバイス制御部１６はリンギング用Ｃ−ＮＣＵ（central network control unit）２０を制御して、発呼制御部１１から指定された通信相手先（電話番号）へ発呼し（ステップｄ１）、指定された時間（回数）だけリンギングして回線を切断する（ステップｄ２−ｄ４）。端末側は、この所定時間もしくは所定回数のリンギングを検出したときに、コールバックする。
【００７３】
図５（ｅ）は、端末種別が機種Ｅで、回線種別がアナログ電話回線の場合に発呼制御部１１で行われる通信手順を示している。この場合は、デバイス制御部１６はノーリンギング用Ｃ−ＮＣＵ２１を制御して発呼し（ステップｅ１）、データ通信を行う（ステップｅ２−ｅ４）。ノーリンギングとは、ＮＴＴの電話サービスのひとつであり、電話などの端末機器のベルを鳴らす（リンギング）こと無しに着信させることができる。データ通信終了後は回線を切断する（ステップｅ４）。なお、データ通信時に電話番号情報を通信させて、切断後に端末側からコールバックさせるようにしても良い。
【００７４】
ここでは、５つの例を示したが、端末種別と回線種別の組み合わせ毎に、通信手順を発呼方式データベースに１２に記憶させているため、どのようなサービスに対しても対応できる。したがって、ＰＨＳ、Ｄｏｐａなどの無線通信回線や、ＡＤＳＬやＣＡＴＶなど他の回線へも容易に適用可能である。
【００７５】
また、端末によっては通常は電源オフあるいは待機状態になっている装置がある。この場合は、端末情報データベース１３に記憶されている端末を起動させる信号（端末起動コード）を発呼サーバーから送信させる通信手順を用いても良い。これにより、必要に応じて、宅内の端末をサーバーから起動させることができる。
【００７６】
（ステップＡ７）発呼制御部１１および通信部１５の動作は、その通信手順毎に詳細に成否や内容がログ情報としてログ記憶部２２に格納される。
【００７７】
ログには、通信や操作を行った日時や通信時間だけでなく、ユーザＩＤ、端末ＩＤ、発呼命令を発効したアプリケーションサーバー２を特定できる情報（サーバー名、ＩＰアドレス）なども付加する。これにより、アプリケーションサーバー２毎や、ユーザ毎に課金が可能になる。
【００７８】
以上のような手順にしたがい、発呼サーバー４はアプリケーションサーバー２の指示にしたがって端末に発呼し、通信が可能となる。
【００７９】
なお、本実施例では、図２に示すようにアプリケーションサーバー２で指定する内容は、ユーザＩＤ、端末ＩＤを基本としたが、具体的に電話番号など通信相手先を指定する方式でも良い。この場合、端末情報データベース１３とユーザ情報データベース１４が必要なくなり、構成は図６のようになる。
【００８０】
図６では、アプリケーションサーバー２が、以下の命令を発呼サーバー４に発行している。
【００８１】
Send(
Line,“AnalogTel”
Type,“V90 modem1",
Tel,"03-321-1234",
connection, "PPP",
file,"test.dat",
Process,“1”);
これは、「V90 modem１を利用し、アナログ電話回線で、電話番号０３−３２１−１２３４に発呼し、ＰＰＰで接続してtest.datという名前のファイルのデータ転送を行う。基本的な通信手順は１番を用いる」という内容を意味している。基本的な通信手順とは、端末側が話中時のタイムアウトや、リンギングの最大時間（回数）などの指定がされている基本的な通信手順であり、この内容は発呼方式データベース１２に登録されることになる。
【００８２】
この方式では、Sendという関数の引数として、リンギング時間（回数）、ＰＢ信号で送る情報、発番通知オプション、ノーリンギングオプションなど、さまざまな内容が用意されており、すべての通信に対応可能である。なお、この構成ではユーザ情報や端末に関する情報を、アプリケーションサーバー２や、それに接続しているデータベース３が管理することになる。
【００８３】
なお、本実施例をプログラムによって汎用コンピュータやサーバーを用いて実現してもよい。
【００８４】
【発明の効果】
以上説明したように、発呼サーバー装置をセンター側のサーバー構成のひとつとして設けることにより、以下のような効果を発揮できる。
【００８５】
（１）端末が事前にインターネットに接続して無くとも、アプリケーションサーバーの指示で、発呼サーバーから宅内の端末に向けて発呼でき、端末を起動したり、通信を接続させたりすることができる。つまり、サーバー側がイニシアチブを取って、情報をタイムリーに宅内端末に送信することができる。
【００８６】
（２）デバイス制御部は複数の回線種別に対応する機器に接続しているため、宅内の端末がどのような通信媒体に接続していても、サーバーからの発呼が着信できる。また、発呼における通信手順は、回線種別および端末種別毎に発呼方式データベースに記憶されているため、通信媒体の特性にあった特別な通信手順が必要なものでも、手順を登録することにより柔軟に対応できる。
【図面の簡単な説明】
【図１】実施例１における発呼サーバー装置を含む全体構成図
【図２】実施例１における発呼サーバー装置の構成図
【図３】実施例１における発呼サーバーの動作を示すフローチャート
【図４】実施例１におけるデバイス制御部の動作を示すフローチャート
【図５】実施例１におけるデバイス制御部の動作を示すフローチャート
【図６】実施例２における発呼サーバー装置の構成図
【図７】従来のクライアントサーバーシステムの構成図
【符号の説明】
１ 端末
２ アプリケーションサーバー
３ データベース
４ 発呼サーバー
１０ 命令解釈部
１１ 発呼制御部
１２ 発呼方式データベース
１３ 端末情報データベース
１４ ユーザ情報データベース
１５ 通信部
１６ デバイス制御部
１７ ＰＢモデム
１８ モデム
１９ ＴＡ／ＤＳＵ
２０ リンギング用Ｃ−ＮＣＵ
２１ ノーリンギング用Ｃ−ＮＣＵ
２２ ログ記憶部
【発明の属する技術分野】
本発明は、インターネットを介したサーバークライアントシステムにおけるサーバー装置に関するものである。
【０００２】
【従来の技術】
インターネットの急速な普及に伴い、サーバークライアント型のシステムが広まっている。特に、商用システムでは、ＷＷＷ（World Wide Web）を中核とした、ＡＳＰ（Application Service Provider）システムが普及している。このシステムの従来例を図７に示す。
【０００３】
１０１は家庭内やオフィス内にある端末である。通常は、パソコンや携帯電話などの端末が多いが、サービスに特化された専用の端末もある。１０２はＷｅｂサーバーやＣＧＩなどのプログラムからなるアプリケーションサーバー。１０３はユーザ情報などサービスに関わるすべての情報を格納するデータベースである。図に示すように、アプリケーションサーバー１０２とデータベース１０３は情報センター内に設置されている。
【０００４】
従来では、宅内に設置された端末１０１は、公衆電話回線を利用してプロバイダへ接続し、さらにインターネットを介して情報センター内のアプリケーションサーバー１０２に接続する。アプリケーションサーバー１０２では、データベース１０３とデータのやり取りを行いながら情報処理を行い、ユーザが希望する情報通信サービスを行う。
【０００５】
なお、この図ではファイヤウォールやルータなどのネットワーク機器を省略して記載している。
【０００６】
【発明が解決しようとする課題】
しかしながら、上記した従来のシステムでは、以下のような課題があった。
【０００７】
（１）端末と情報センター内のサーバーがインターネットを介して通信を行うためには、まず端末側からプロバイダへ発呼する必要があり、サーバー側からデータ送信を開始することができない。
【０００８】
つまり、サーバー側がイニシアチブを取って、情報をタイムリーに宅内端末に送信することができなかった。
【０００９】
（２）端末のインターネットへの接続には、さまざまな種類の通信媒体が利用されている。例えば、アナログ電話、ＩＳＤＮ回線、携帯電話などの無線通信など。接続の手順や通信方法はこれらの回線種別に異なるため、サーバーから端末への発呼はすべてのケースを考慮しなければならず、実現が難しかった。
【００１１】
【課題を解決するための手段】
本発明は上記課題を解決するために、情報センター内に発呼サーバー装置を設ける。発呼サーバー装置は、端末に対して情報通信サービスを行う少なくともひとつ以上のアプリケーションサーバーからの発呼命令を受信し、ユーザＩＤ・端末ＩＤ情報を抽出する命令解釈部と、少なくとも一種類以上の通信回線と接続してデータの送受信を行う通信部と、前記ユーザに関連する情報を記憶するユーザ情報データベースと、前記端末に関する情報を記憶する端末情報データベースと、端末種別および回線種別毎に発呼手順や発呼方式を記憶する発呼方式データベースと、前記命令解釈部で得られた前記ユーザＩＤと前記端末ＩＤ情報とから、前記ユーザ情報データベース、前記端末情報データベース、前記発呼方式データベースを検索し、得られた通信相手先情報・回線種別・通信手順情報にしたがって前記通信部を制御し、前記端末へ向けて発呼する発呼制御部とを備える。
【００１５】
【発明の実施の形態】
本発明の請求項１にかかる発呼サーバー装置は、端末に対して情報通信サービスを行う少なくともひとつ以上のアプリケーションサーバーからの発呼命令を受信し、ユーザＩＤ・端末ＩＤ情報を抽出する命令解釈部と、少なくとも一種類以上の通信回線と接続してデータの送受信を行う通信部と、前記ユーザに関連する情報を記憶するユーザ情報データベースと、前記端末に関する情報を記憶する端末情報データベースと、端末種別および回線種別毎に発呼手順や発呼方式を記憶する発呼方式データベースと、前記命令解釈部で得られた前記ユーザＩＤと前記端末ＩＤ情報とから、前記ユーザ情報データベース、前記端末情報データベース、前記発呼方式データベースを検索し、得られた通信相手先情報・回線種別・通信手順情報にしたがって前記通信部を制御し、前記端末へ向けて発呼する発呼制御部とを備える。
【００１６】
この構成では、ユーザがどの回線を利用しているか、端末にどの通信手順を用いるか、などの情報が、ユーザ情報データベースや端末情報データベース、発呼方式データベースに格納されている。したがって、アプリケーションサーバーは発呼に際しての、回線種別毎の制約や端末な相違を意識することなく、サービスを実現することができる。また、ユーザ・端末・通信手順に関する情報が発呼サーバーに一元管理されているので、複数のアプリケーションサーバーが１台の発呼サーバーを共有する場合などは、発呼や回線に関する情報をそれぞれのアプリケーションで管理する必要がないというメリットもある。
【００３５】
【実施例】
以下、本発明の実施例について図面を用いて説明する。
【００３６】
（実施例１）
図１は本実施例の全体構成を示した図である。図１において、１は宅内に設置された端末（サービスに特化した専用端末やパソコン、携帯電話、インターネットＴＶなど）。２は情報センター等の中に設置されたアプリケーションサーバーであり、端末１とデータの送受信を行い、ユーザに情報通信サービスを提供する。アプリケーションサーバー２は、一般にＷｅｂサーバーやメールサーバーなどを中心に構築されることが多く、コンテンツ情報であるＨＴＭＬ／ＸＭＬファイルや画像・音声ファイルだけでなく、認証、データベース接続、メール配信、データ処理、ＨＴＭＬ／ＸＭＬ動的生成などを行うＣＧＩ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ などにより書かれたプログラムも含んでいる。３はデータベースであり、アプリケーションサーバー２で実行される情報サービスに必要なデータを記憶する。一般的には顧客情報データベースやＨＴＭＬ／ＸＭＬなどコンテンツ、端末情報、処理履歴などであり、この内容は提供するサービスに応じて変化する。４は発呼サーバーであり、アプリケーションサーバー２から発行される命令に応じて、宅内の端末１へ向けて発呼する装置である。
【００３７】
図１に示すように、端末とサーバーへの接続方法には２つの経路がある。ひとつは、端末１から発呼して、アナログ電話回線やＩＳＤＮ回線などの公衆電話網を経由してプロバイダ（インターネットサービスプロバイダ）へ接続し、その後インターネットを経由してアプリケーションサーバー２へ接続する経路である（図中の（Ａ））。もうひとつは、発呼サーバー４から発呼して、インターネットを利用せず、公衆電話網を介して端末へ直接接続する経路（図中の（Ｂ））である。
【００３８】
なお、発呼サーバー４へ発呼命令を発行するのは、ひとつのアプリケーションサーバー２だけでなく、図に示すように同一情報センター内の複数のアプリケーションサーバー（ａ，ｂ，ｃ）であってもよいし、また、さらに通信回線で結ばれた他の情報センターのアプリケーションサーバー（図中２’）であっても良い。発呼サーバー４は、複数のアプリケーションで共有可能であり、それによりサービスあたりの運用コストが安くなるというメリットが出てくる。また、図１では端末は宅内にあるとしたが、宅外に存在するモバイル端末の様な物でも良い。
【００３９】
図２は、発呼サーバー４の構成の詳細を示したものである。１０はアプリケーションサーバー２からの命令を解釈して、通信相手先情報や端末ＩＤを抽出する命令解釈部。１１は命令解釈部１０で得られた情報から発呼に必要な情報を検索し、通信を制御する発呼制御部。１２は端末の種別や利用する回線種別毎もしくは、サービス内容毎に発呼手順や発呼方式を記憶する発呼方式データベース。１３は端末に関する情報（端末ＩＤ、メーカ名、品番、製造番号、機能コードなど）と、端末を電源オフあるいは待機状態から動作状態へ遷移させるための起動信号や起動コードを、端末毎に記憶している端末情報データベース。１４はユーザに関する個人情報およびユーザＩＤ，利用している端末種別、端末ＩＤ，使用回線種別などユーザと端末に関する情報を記憶しているユーザ情報データベース。１５は複数の種類種類の回線と繋がっており発呼制御部１４の命令にしたがって端末と通信回線を介して接続する通信部。１６は発呼制御部１４からの命令に応じて通信デバイスを選択し、指定された通信手順に応じて発呼処理を行うデバイス制御部。１７はＰＢ信号（ＤＴＭＦ信号）や音声信号を出力するＰＢモデム。１８はアナログ電話回線を介したＰＰＰ接続やＴＣＰ／ＩＰによるデータ通信や音声信号出力を行うモデム。１９はＩＳＤＮ回線に接続して発呼および通信を行うＴＡ／ＤＳＵ。２０はアナログおよびデジタルの電話回線に接続して発呼し、シリアル通信を行うリンギング用Ｃ−ＮＣＵ。２１はアナログ電話回線に接続してノーリンギング発呼を行い端末に着信してデータ通信を行うノーリンギング用Ｃ−ＮＣＵである。
【００４０】
なお、図２に示すように１６〜２１は通信部１５の構成要素である。２２は発呼制御部１１およびデバイス制御部１４の制御内容をログとして記録し、ユーザ毎、サービス毎、アプリケーションサーバー毎などについて、発呼時刻、通信時間、通信結果などを記録するログ記憶部である。
【００４１】
以上のように構成された発呼サーバー装置について、図３のフローチャートを用いて各部の動作を説明する。
【００４２】
アプリケーションサーバー２は、端末とインターネットなどを介して通信を行い情報サービスを行うサーバーである。これは、前述したように、Ｗｅｂサーバーを中心に構成されており、ＣＧＩやＪａｖａなどのプログラムと、ＨＴＭＬ／ＸＭＬや画像・音声などのコンテンツファイルなどが格納されている。プログラムやコンテンツの内容は、ユーザに提供するサービスの種類に応じて異なる。図３は、アプリケーションサーバー２が提供する情報サービスの一部として、アプリケーションサーバー２から、ユーザの端末に向けて発呼命令が出された場合を示している。
【００４３】
（ステップＡ１）アプリケーションサーバー２内のプログラムは、発呼サーバー４に向けて発呼命令（コマンド）を出力する。ここでは。以下のような命令が出力された例を説明する。
【００４４】
命令：Send（"１００１"，"Ｍ０１２３４５６７８９"，"test.dat"）；
"１００１"はユーザＩＤ、"Ｍ０１２３４５６７８９"は端末ＩＤ、"test.dat"は転送する情報ファイルの例である。この命令は、「ユーザ（ユーザＩＤ"１００１"）の利用する端末（端末ＩＤ"Ｍ０１２３４５６７８９"）へ発呼し、"test.dat"というファイルを転送せよ。」という命令である。ユーザＩＤとは、各ユーザ毎に一意に割り振られている番号であり、通常はデータベース３およびユーザ情報データベース１４にユーザの氏名・住所などの個人情報とともに記録されている。端末ＩＤは、端末毎に一意に割り振られている番号であり、これもデータベース３および端末情報データベース１３に記録されている。
【００４５】
"test.dat"は、転送するファイルの一例である。ファイルはサービスに応じて様々な場合があり、さらにコールバックをさせる場合などは、転送する必要がない。ファイル送信が必要出ない場合は、Send（"１００１"，"Ｍ０１２３４５６７８９"）；といった形で、ファイル名を指定する必要はない。
【００４６】
なお、上述した命令は一例にすぎず、発呼に必要な様々な他のパラメータをこの命令と同時に発呼サーバー４へ送ることができる。また、端末ＩＤが一意に付与されていない場合は、メーカ名や製造番号などの他のパラメータを指定しても良い。
【００４７】
（ステップＡ２）アプリケーションサーバー２から出力された発呼命令を命令解釈部１０で解析し、命令で指定されたユーザＩＤ、端末ＩＤや、その他の発呼に必要な通信パラメータを取り出す。取り出した情報は発呼制御部１１へ出力する。
【００４８】
（ステップＡ３）発呼制御部１１は、命令で指定されたユーザＩＤからユーザ情報データベース１４を検索し、ユーザの利用している回線に関する情報（回線種別や相手先情報など）を取得する。
【００４９】
ユーザ情報データベース１４には、各ユーザの情報が記憶されている。具体的な例を挙げると、以下のような項目が記憶されている。
【００５０】
個人情報：ユーザＩＤ、氏名、性別、年齢、住所、電話番号、電子メールアドレス、職業などの個人情報など。
【００５１】
端末情報：ユーザが利用している端末のＩＤ（ユーザＩＤ毎に）回線情報：回線種別、相手先情報（回線番号）、認証情報、設置形態、ルータの有無（端末ＩＤ毎に）。
【００５２】
ここでの回線種別とは、アナログ電話回線、ＩＳＤＮ回線、ＰＨＳ、ＡＤＳＬなど、通信媒体の種類を意味している。相手先情報（回線番号）とは、電話番号やＩＰアドレスなど通信において通信先を特定するために必要な情報を意味する。また、認証情報とは回線を接続する際に、認証が必要な場合（ログインＩＤ、パスワードなどが求められる場合）に設定する情報である。ユーザＩＤ、端末ＩＤは、全体に渡ってユニークになるように設定する。
【００５３】
この検索により、ユーザ毎に固有な通信情報（回線種別、電話番号などの通信相手先情報など）が取得できる。
【００５４】
（ステップＡ４）発呼制御部１１は、命令で指定された端末ＩＤから、端末情報データベース１３を検索し、端末種別や起動コードなどの情報を取得する。端末情報データベース１３には、各端末に固有の情報が記憶されている。例えば以下のような項目の情報である。
【００５５】
端末情報：端末ＩＤ、メーカ名、端末分類、端末種別、品番、製造番号、出荷日、端末起動コード。
【００５６】
ここでの端末分類とは、端末種類の大分類であり、例えば、携帯電話、ＰＣ、健康機器、セキュリティ機器などといった内容の項目である。端末種別とは、端末種類毎にユニークに付与された番号である。端末起動コードとは、端末が電源オフあるいは待機状態から動作状態へ移行させるための命令である。端末起動コードが必要でない端末や、常時電源が入って動作状態にある端末については、記憶させる必要はない。
【００５７】
この検索により、端末毎に固有な情報（端末種別、起動コード）などが取得できる。
【００５８】
（ステップＡ５）発呼制御部１１は、ステップＡ３およびＡ４で得られた端末種別と回線種別から、発呼方式データベース１２を検索、ユーザが利用している回線と端末に適した通信手順や通信方法を取得する。
【００５９】
通信手順や方法は、データの送受信動作を記述するスクリプトで記載する。ただし、通信手順についてはプログラムのような形で記述しても良い。また、発呼時のリンギングの回数や、リンギング時間のような内容や、通信先が話中などの場合にエラーと判断するまでのタイムアウト時間なども、発呼方法として発呼方式データベース１２に端末種別・回線種別毎に記憶されている。
【００６０】
なお、本実施例では、端末種別と回線種別から通信手順を検索したが、サービス種類やアプリケーションサーバー種別などで、検索できるようにしても良い。
【００６１】
（ステップＡ６）発呼制御部１１は、上記のステップで得られた情報（１）回線種別、（２）電話番号やＩＰアドレス等の通信相手先情報、（３）通信手順、（４）必要であれば端末起動コード、（５）必要であればデータファイル名（ここでは、"test.dat"）を基に、通信部１５を制御して発呼を行う。なお、アプリケーションサーバー２から発行された命令に他の通信パラメータ情報が加えられていれば、その情報も加えて発呼を行う。
【００６２】
ここでの発呼の手順は、ステップＡ５で得た通信手順に従って行う。通信手順は上述したように端末種別や回線種別によって異なる。
【００６３】
典型的な通信手順の例を図４および図５のフローチャートに示す。図では、端末種別を仮に機種Ａ〜Ｅとし、アナログ電話回線、ＩＳＤＮ回線などの通信媒体を利用した時の通信手順の事例を示している。
【００６４】
図４（ａ）は、端末が機種Ａという端末種別で、アナログ電話回線で接続する場合の通信手順を示している。この端末ではＰＢ信号（ＤＴＭＦ信号）で通信を行う。
【００６５】
デバイス制御部１６は発呼制御部１１の検索により得られた回線種別や機種種別にしたがって、モデムなどの通信デバイスを制御する。図４（ａ）の場合は回線種別はアナログ電話回線で、端末種別は機種Ａということになる。この場合、デバイス制御部１６は、ＰＢモデム１７を選択し、発呼制御部１１から得られた通信相手先情報（電話番号）にダイアルする（ステップａ１）。宅内の端末に着信後、ＰＢ信号でコールバック用の電話番号情報を送信して（ステップａ２−ａ３）、回線を切断する（ステップａ４）。この時の通信経路は図１の（Ｂ）である。コールバック用の電話番号情報は、アプリケーションサーバー２より、引数のひとつとして渡される。端末は、この通信の後に、通信により指定された電話番号へコールバックして通信を行う。このコールバックの通信経路は、図１の（Ａ）になる。
【００６６】
図４（ｂ）は、端末種別が機種Ｂで、回線種別がアナログ電話回線の場合に、発呼制御部１１で行われる通信手順を示している。この端末ではＰＰＰ（Point to Point Protocol）で接続を確立し、ＴＣＰ／ＩＰを用いてサーバーと通信を行う。
【００６７】
この場合、デバイス制御部１６はモデム１８を選択し、発呼制御部１１から指定された通信相手先（電話番号）へ発呼する（ステップｂ１）。端末へ着信後、端末側モデムとのネゴシエーションを行い、接続が確立された後、発呼制御部１１から指定された認証情報（ログインＩＤ、パスワード）で認証を行いＰＰＰ接続を確立させる（ステップｂ２−ｂ６）。その後、ＴＣＰ／ＩＰを用いてサーバーと端末の間でデータの送受信（例えば、"test.dat"）を行う（ステップｂ７）。データ通信終了後は回線を切断する（ステップｂ８）。
【００６８】
なお、（ａ）の例と同様にデータ通信の時点で電話番号情報を送信し、端末側からコールバックさせるようにしても良い。
【００６９】
また、図４（ｂ）に示すように、端末側に着信したにも関わらず、モデムとの接続に失敗した場合は、何らかの形でユーザが宅内の電話機を操作している可能性が高い。このような場合は、デバイス制御部１６から音声メッセージを出力させて、ユーザに使用法を教えたり、注意を促したりしても良い（ステップｂ５）。この音声メッセージは、アプリケーションサーバー２からも指定可能であるし、また発呼制御部１１で固定にしても良い。
【００７０】
図５（ｃ）は、端末種別が機種Ｃで、回線種別がＩＳＤＮ回線の場合に発呼制御部１１で行われる通信手順を示している。この場合、デバイス制御部１６はＴＡ／ＤＳＵ１９を選択し、発呼制御部１１から指定された通信相手先（電話番号）へ、発番通知情報"１８６"を付加して発呼する（ステップｃ１）。そして端末側回線が使用中（話中）でなければ、発呼制御部１１から指定された回数（時間）だけリンギングして回線を切断する（ステップｃ２−ｃ４）。
【００７１】
この情報により、端末側はサーバーから着信を受けたことがわかるので、端末は所定の電話番号へコールバックできる。
【００７２】
図５（ｄ）は、端末種別が機種Ｄで、回線種別がアナログ電話回線の場合に発呼制御部１１で行われる通信手順を示している。この場合、デバイス制御部１６はリンギング用Ｃ−ＮＣＵ（central network control unit）２０を制御して、発呼制御部１１から指定された通信相手先（電話番号）へ発呼し（ステップｄ１）、指定された時間（回数）だけリンギングして回線を切断する（ステップｄ２−ｄ４）。端末側は、この所定時間もしくは所定回数のリンギングを検出したときに、コールバックする。
【００７３】
図５（ｅ）は、端末種別が機種Ｅで、回線種別がアナログ電話回線の場合に発呼制御部１１で行われる通信手順を示している。この場合は、デバイス制御部１６はノーリンギング用Ｃ−ＮＣＵ２１を制御して発呼し（ステップｅ１）、データ通信を行う（ステップｅ２−ｅ４）。ノーリンギングとは、ＮＴＴの電話サービスのひとつであり、電話などの端末機器のベルを鳴らす（リンギング）こと無しに着信させることができる。データ通信終了後は回線を切断する（ステップｅ４）。なお、データ通信時に電話番号情報を通信させて、切断後に端末側からコールバックさせるようにしても良い。
【００７４】
ここでは、５つの例を示したが、端末種別と回線種別の組み合わせ毎に、通信手順を発呼方式データベースに１２に記憶させているため、どのようなサービスに対しても対応できる。したがって、ＰＨＳ、Ｄｏｐａなどの無線通信回線や、ＡＤＳＬやＣＡＴＶなど他の回線へも容易に適用可能である。
【００７５】
また、端末によっては通常は電源オフあるいは待機状態になっている装置がある。この場合は、端末情報データベース１３に記憶されている端末を起動させる信号（端末起動コード）を発呼サーバーから送信させる通信手順を用いても良い。これにより、必要に応じて、宅内の端末をサーバーから起動させることができる。
【００７６】
（ステップＡ７）発呼制御部１１および通信部１５の動作は、その通信手順毎に詳細に成否や内容がログ情報としてログ記憶部２２に格納される。
【００７７】
ログには、通信や操作を行った日時や通信時間だけでなく、ユーザＩＤ、端末ＩＤ、発呼命令を発効したアプリケーションサーバー２を特定できる情報（サーバー名、ＩＰアドレス）なども付加する。これにより、アプリケーションサーバー２毎や、ユーザ毎に課金が可能になる。
【００７８】
以上のような手順にしたがい、発呼サーバー４はアプリケーションサーバー２の指示にしたがって端末に発呼し、通信が可能となる。
【００７９】
なお、本実施例では、図２に示すようにアプリケーションサーバー２で指定する内容は、ユーザＩＤ、端末ＩＤを基本としたが、具体的に電話番号など通信相手先を指定する方式でも良い。この場合、端末情報データベース１３とユーザ情報データベース１４が必要なくなり、構成は図６のようになる。
【００８０】
図６では、アプリケーションサーバー２が、以下の命令を発呼サーバー４に発行している。
【００８１】
Send(
Line,“AnalogTel”
Type,“V90 modem1",
Tel,"03-321-1234",
connection, "PPP",
file,"test.dat",
Process,“1”);
これは、「V90 modem１を利用し、アナログ電話回線で、電話番号０３−３２１−１２３４に発呼し、ＰＰＰで接続してtest.datという名前のファイルのデータ転送を行う。基本的な通信手順は１番を用いる」という内容を意味している。基本的な通信手順とは、端末側が話中時のタイムアウトや、リンギングの最大時間（回数）などの指定がされている基本的な通信手順であり、この内容は発呼方式データベース１２に登録されることになる。
【００８２】
この方式では、Sendという関数の引数として、リンギング時間（回数）、ＰＢ信号で送る情報、発番通知オプション、ノーリンギングオプションなど、さまざまな内容が用意されており、すべての通信に対応可能である。なお、この構成ではユーザ情報や端末に関する情報を、アプリケーションサーバー２や、それに接続しているデータベース３が管理することになる。
【００８３】
なお、本実施例をプログラムによって汎用コンピュータやサーバーを用いて実現してもよい。
【００８４】
【発明の効果】
以上説明したように、発呼サーバー装置をセンター側のサーバー構成のひとつとして設けることにより、以下のような効果を発揮できる。
【００８５】
（１）端末が事前にインターネットに接続して無くとも、アプリケーションサーバーの指示で、発呼サーバーから宅内の端末に向けて発呼でき、端末を起動したり、通信を接続させたりすることができる。つまり、サーバー側がイニシアチブを取って、情報をタイムリーに宅内端末に送信することができる。
【００８６】
（２）デバイス制御部は複数の回線種別に対応する機器に接続しているため、宅内の端末がどのような通信媒体に接続していても、サーバーからの発呼が着信できる。また、発呼における通信手順は、回線種別および端末種別毎に発呼方式データベースに記憶されているため、通信媒体の特性にあった特別な通信手順が必要なものでも、手順を登録することにより柔軟に対応できる。
【図面の簡単な説明】
【図１】実施例１における発呼サーバー装置を含む全体構成図
【図２】実施例１における発呼サーバー装置の構成図
【図３】実施例１における発呼サーバーの動作を示すフローチャート
【図４】実施例１におけるデバイス制御部の動作を示すフローチャート
【図５】実施例１におけるデバイス制御部の動作を示すフローチャート
【図６】実施例２における発呼サーバー装置の構成図
【図７】従来のクライアントサーバーシステムの構成図
【符号の説明】
１ 端末
２ アプリケーションサーバー
３ データベース
４ 発呼サーバー
１０ 命令解釈部
１１ 発呼制御部
１２ 発呼方式データベース
１３ 端末情報データベース
１４ ユーザ情報データベース
１５ 通信部
１６ デバイス制御部
１７ ＰＢモデム
１８ モデム
１９ ＴＡ／ＤＳＵ
２０ リンギング用Ｃ−ＮＣＵ
２１ ノーリンギング用Ｃ−ＮＣＵ
２２ ログ記憶部
Claims (1)
- 端末に対して情報通信サービスを行う少なくともひとつ以上のアプリケーションサーバーからの発呼命令を受信し、ユーザＩＤ・端末ＩＤ情報を抽出する命令解釈部と、
少なくとも一種類以上の通信回線と接続してデータの送受信を行う通信部と、
前記ユーザに関連する情報を記憶するユーザ情報データベースと、
前記端末に関する情報を記憶する端末情報データベースと、
端末種別および回線種別毎に発呼手順や発呼方式を記憶する発呼方式データベースと、
前記命令解釈部で得られた前記ユーザＩＤと前記端末ＩＤ情報とから、前記ユーザ情報データベース、前記端末情報データベース、前記発呼方式データベースを検索し、得られた通信相手先情報・回線種別・通信手順情報にしたがって前記通信部を制御し、前記端末へ向けて発呼する発呼制御部とを備えた発呼サーバー装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002052758A JP3945270B2 (ja) | 2002-02-28 | 2002-02-28 | 発呼サーバー装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002052758A JP3945270B2 (ja) | 2002-02-28 | 2002-02-28 | 発呼サーバー装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003259034A JP2003259034A (ja) | 2003-09-12 |
| JP3945270B2 true JP3945270B2 (ja) | 2007-07-18 |
Family
ID=28664369
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002052758A Expired - Fee Related JP3945270B2 (ja) | 2002-02-28 | 2002-02-28 | 発呼サーバー装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3945270B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7412180B2 (en) * | 2004-11-30 | 2008-08-12 | Xerox Corporation | Glossing system for use in a printing system |
| JP2007142616A (ja) * | 2005-11-16 | 2007-06-07 | Nakayo Telecommun Inc | 呼返し機能を有する通信装置 |
| JP5243645B2 (ja) | 2011-05-24 | 2013-07-24 | 株式会社エヌ・ティ・ティ・ドコモ | サービスサーバ装置、サービス提供方法、サービス提供プログラム |
-
2002
- 2002-02-28 JP JP2002052758A patent/JP3945270B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003259034A (ja) | 2003-09-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102187620B (zh) | 在家庭网络上发送和接收呼叫的系统和方法 | |
| US9270661B2 (en) | Communication network system, gateway, data communication method and program providing medium | |
| US6430174B1 (en) | Communication system supporting simultaneous voice and multimedia communications and method of operation therefore | |
| US6829474B1 (en) | System for providing multimedia value-added services | |
| US20070183396A1 (en) | Set top box supporting bridging between a packet switched network and the public switched telephone network | |
| US20070183401A1 (en) | Set top box supporting selective local call termination and call bridging | |
| WO1998018237A1 (en) | A system and method for personal multimedia communication over a packet switched network | |
| WO2008106431A2 (en) | Technique for providing data objects prior to call establishment | |
| US7254610B1 (en) | Delivery of services to a network enabled telephony device based on transfer of selected model view controller objects to reachable network nodes | |
| KR20070051235A (ko) | 통신 시스템에서 서비스 메뉴 제공 방법 및 시스템 | |
| EP2116033B1 (en) | Method and apparatus for event-based synchronization of information between communication devices | |
| CN1921518B (zh) | 录制设备、存储服务器、录制系统及方法和回放系统及方法 | |
| US7899912B2 (en) | Pervasive, personal data interactivity over voice-grade circuit-switched cellular networks | |
| JP2009540754A (ja) | 通信網内の発呼者へのカスタマイズされたマルチメディアグリーティングを配信するための方法 | |
| JP2003110596A (ja) | データ通信サービス提供方法 | |
| JP2004186893A (ja) | Ｌａｎ外接続ｉｐキーテレフォンシステム及びその端末と主装置並びにそのｌａｎ外接続方法 | |
| EP1816831A1 (en) | Computing device supporting bridging between a packet switched network and the public switched telephone network | |
| JP3945270B2 (ja) | 発呼サーバー装置 | |
| US20070183397A1 (en) | Computing device supporting selective local call termination and call bridging | |
| JP4677350B2 (ja) | 呼制御信号転送装置、呼制御信号転送方法および呼制御信号転送プログラム | |
| Cisco | Release Notes for Cisco 700 Series Router Software Version 4.4.1 | |
| US20020128003A1 (en) | Telecommunication gateway between a private network and mobile network | |
| JPH11341152A (ja) | インターネット電話システム | |
| US20060280190A1 (en) | UPnP mirroring systems and methods | |
| KR20010050717A (ko) | 최적화된 통신 시스템 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040914 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20050706 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060712 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061226 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070207 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070320 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070402 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110420 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120420 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130420 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130420 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140420 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |