JP4484277B2

JP4484277B2 - Service control device and gateway device

Info

Publication number: JP4484277B2
Application number: JP26986599A
Authority: JP
Inventors: 幸子武田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1998-09-25
Filing date: 1999-09-24
Publication date: 2010-06-16
Anticipated expiration: 2019-09-24
Also published as: JP2000224301A

Description

【０００１】
【発明の属する技術分野】
本発明は、インターネットユーザにサービス可能なインテリジェントネットワーク（ＩＮ）に関し、特にインターネット・コール・ウエイティング（Internet Call Waiting）サービス機能を有する「インテリジェントネットワークのサービス制御装置（Service Control Point）（以下、ＳＣＰと言う）」、上記ＳＣＰとの通信機能を有する「インターネット・プロトコル（ＩＰ）網に接続されたＩＰ通信装置」、および、上記ＳＣＰとＩＰ通信装置とを接続するサービス制御ゲートウェイ装置に関する。
【０００２】
【従来の技術】
公衆網からインターネットへの接続方法の１つとして、ダイヤル・アップ接続がある。ダイヤル・アップ接続を利用すると、一般的なアナログ電話回線やＩＳＤＮ回線を利用して、家庭のパソコンを必要な時に必要な時間だけ、インターネットに接続できる。ダイヤル・アップ接続を利用して、パソコンなどの端末装置をインターネットに接続する場合、「アナログ電話網やＩＳＤＮ網」とインターネット網とを接続するゲートウェイ装置によって、端末ユーザ（加入者）の認証やＩＰアドレスの割り当てが行われる。ユーザがダイヤル・アップ接続によってインターネットに接続している間、ユーザ端末の加入者線を収容している交換機は、加入者が通話中か否かは識別できたとしても、ユーザ端末がインターネットに接続中か否かを識別することはできない。
【０００３】
一方、サービスのカスタマイズ化や、迅速なサービス提供を可能にするインテリジェント・ネットワーク（ＩＮ）は、網構成をプレーンと呼ばれる機能別のプレーン（サービス・プレーン、グローバル機能プレーン、分散機能プレーン、物理プレーン）に分けて、各プレーンを規定した「能力セット１」と、網間接続サービスを含むサービスの生成、管理を規定した、より高度の「能力セット２」とが標準化されている（ITU-T勧告：Q.1220-Q.1228）。
【０００４】
インテリジェント・ネットワークは、複数の交換機からなる伝達（Transport Layer)網と、上記伝達網に共通線信号網で接続されたサービス制御装置（Service Control Point）からなる高機能(Intelligent Layer）網と、上記ＳＣＰに接続されたサービス管理装置（Service Management Point）とからなる。「ＩＮ能力セット２」における網間接続サービスは、ITU-T勧告Q.1224に記載されているように、ＩＮ網間におけるサービスデータ機能やサービス制御機能の連携によるサービス提供方法が中心であり、ＩＮのサービス制御機能とインターネット網との連携による通信サービスの提供方法については規定されていない。
【０００５】
ＩＮのサービス制御機能とインターネット網とが連携して通信サービスを提供する方法に関して、ＩＴＵ−Ｔでは、インターネット・ユーザからのサービス要求をＩＮのサービス制御機能（ＳＣＦ）に送信する目的で、「インターネット側に、ユーザがサービス要求を送信する“ユーザエージェント機能”を設け、インターネットと公衆網との間に、“サービス制御ゲートウェイ機能”を設ける」案が提案されているが、これらの機能を用いた具体的なサービスの提供方法とサービスの実現方法については、今後の検討課題となっている。
【０００６】
【発明が解決しようとする課題】
近年、通信サービスの多様化に伴い、ＩＮのサービス制御機能とインターネット網との連携による新たなサービスとして、例えば、インターネット・コール・ウエイティング（Internet Call Waiting：ＩＣＷ）サービスの提供が望まれている。ＩＣＷは、「インターネットに接続中のユーザに着信があった時、着信通知を受けたユーザが、着呼の継続処理方法（例えば、着信拒否、呼転送等）をユーザ端末からＩＮのサービス制御機能に指示できる」ようにしたサービス機能である。ＩＮのサービス制御機能は、ユーザからの指示に従って、呼処理を継続する。
【０００７】
しかしながら、従来の技術では、電話網においてユーザが通話状態にある時、交換機側で、通話中の呼が、インターネット接続呼か、電話機間を接続する一般呼かを判別することができない。一般呼で通信中の端末に着信があった場合は、被呼端末は、交換機からアナログ信号で与えられた着信通知信号を正常に受信できるが、インターネット接続呼で通信中の端末は、ディジタル信号で送受信動作しているため、交換機から与えたアナログ信号の着信通知はノイズとして扱われ、着信を通知できない。従って、現在のところ、インターネット接続中のユーザに着信を通知するＩＣＷサービスは実現されていない。
【０００８】
本発明の目的は、インターネットに接続中のユーザ端末にＩＮサービスを提供可能な通信ネットワークを提供することにある。
【０００９】
本発明の他の目的は、Internet Call Waitingサービス機能を有する「インテリジェントネットワークのサービス制御装置（Service Control Point）を提供することにある。
【００１０】
本発明の更に他の目的は、インテリジェントネットワークのサービス制御装置（Service Control Point）とインターネットとを接続するためのサービス制御ゲートウェイ装置を提供することにある。
【００１１】
【課題を解決するための手段】
上記目的を達成するために、本発明による、伝達網の構成する複数の交換機に共通線信号網を介して接続され、インターネット・プロトコル網にサービス制御ゲートウエイ装置を介して接続された「インテリジェント・ネットワークのサービス制御装置」は、上記伝達網に接続された端末装置（複数）がインターネットに接続中か否かを示すユーザ情報管理テーブルを有し、通話中の１つの端末に着信があった時、上記ユーザ情報管理テーブルを参照することによって、被呼端末が、一般呼がインターネット接続呼かを判断する。もし、被呼端末が、インターネット接続呼であれば、サービス制御装置は、上記サービス制御ゲートウエイ装置を介して、インターネット経由で、被呼端末に着信を通知する。
【００１２】
更に詳述すると、本発明による「インテリジェント・ネットワークのサービス制御装置」は、上記伝達網を介して上記インターネット・プロトコル網に接続された第１端末装置から、コール・ウエイティング・サービス要求を受信した時、「上記第１端末装置がインターネットに接続中である」ことを示す情報をユーザ情報管理テーブルに記憶するための第１の手段と、上記複数の交換機のうちの１つから、「上記第１端末装置に第２端末装置から着信があった」ことを通知された時、上記ユーザ情報管理テーブルを参照し、上記第１端末装置への着信通知メッセージを上記ゲートウエイ装置に送信するための第２手段とからなる。
【００１３】
上記ユーザ情報管理テーブルは、例えば、上記第１端末の電話番号と、該第１端末がインターネットに接続中か否かを示すフラグ情報と、上記ゲートウエイ装置のアドレス情報とからなるエントリを有し、上記第１手段が上記エントリの内容を更新し、上記第２手段が、上記エントリの上記フラグ情報とアドレス情報を参照する。
また、本発明によるサービス制御装置は、上記ゲートウエイ装置を介して、「上記着信通知に対する上記第１端末装置のユーザからの応答を示す」通知応答メッセージを受信した時、上記第２手段が、上記１つの交換機に、上記第１端末装置への着信呼を上記応答に従って接続サービスさせる。
【００１４】
本発明による、伝達網の構成する複数の交換機に共通線信号網を介して接続された「インテリジェント・ネットワークのサービス制御装置」と、上記伝達網に接続された「インターネット・プロトコル網」とを接続するための「サービス制御ゲートウエイ装置」は、
上記伝達網を介して上記インターネット・プロトコル網に接続された第１端末装置から送信された、上記サービス制御装置によるインターネット・コール・ウエイティング・サービスを要求する「サービス要求メッセージ」を、上記サービス制御装置で実行される複数のサービス制御プログラムのうちの１つを特定する識別子を含む「上記サービス制御装置宛のメッセージ」に変換するプロトコル変換手段と、
上記プロトコル変換されたメッセージを、上記サービス制御装置に接続された信号線に送信するための手段とからなる。
【００１５】
本発明の１つの特徴は、上記サービス制御ゲートウエイ装置が、
上記サービス制御装置から送信された、「上記第１端末装置に第２端末装置から着信があった」ことを示す着信通知メッセージを、上記インタネット・プロトコル網に含まれる「上記第１端末装置と通信中のサーバ」宛のメッセージに変換するプロトコル変換手段、上記プロトコル変換されたメッセージを、上記サーバと接続された信号線に送信するための手段、からなることにある。上記サーバは、上記サービス制御ゲートウエイ装置からの受信メッセージを上記第１端末装置に転送する機能を備えている。
【００１６】
本発明の他の特徴は、サービス制御ゲートウエイ装置が、
上記サービス制御装置から送信された、「上記第１端末装置に第２端末装置から着信があった」ことを示す着信通知メッセージを、上記インタネット・プロトコル網に含まれる「上記第１端末装置と通信中のアクセスポイント装置」宛のメッセージに変換するプロトコル変換手段、上記プロトコル変換されたメッセージを、上記インタネット・プロトコル網に接続された信号線に送信するための手段、からなることにある。上記アクセスポイント装置は、上記サービス制御ゲートウエイ装置からの受信メッセージを上記第１端末装置に転送する機能を備えている。
【００１７】
本発明の他の通信サービス制御方法では、複数の交換機によって構成される伝達網が、ゲートウェイ装置を介して、インターネット網に接続される。ユーザ毎のサービス用制御情報を記憶するための記憶装置を備えるサービス制御装置が、共通線信号網を介して、伝達網に接続されている。上記サービス制御装置は、上記ユーザ情報管理テーブルを記憶し、上記第１の手順と第２の手段を備える。
【００１８】
上記ゲートウェイ装置に加入者の付加サービスに関する情報を記憶する。
【００１９】
上記ゲートウェイ装置が、ユーザから交換機経由でインターネット網への接続要求を受信した時、上記ゲートウェイ装置は、上記付加サービスに関する情報を用いて、インターネット接続中のユーザに着信を通知する付加サービスへの加入状況を検索する。ユーザが該付加サービスに加入している場合、上記ゲートウェイ装置は、着信通知要求をサービス制御ゲートウェイ装置に送信し、該サービス制御ゲートウェイ装置は、予め蓄積されているサービス制御装置を識別する情報を参照して、サービス制御装置に着信通知要求を送信し、該要求を受信したサービス制御装置は、上記第１の手段を用いて、該当ユーザに対応するサービス情報を更新することを特徴とする。
【００２０】
また、サービス制御装置が、交換機から、「該当ユーザに対する着信」を通知された場合、該サービス制御装置が、上記第２の手段を用いて、サービス制御ゲートウェイ装置に着信通知信号を送信し、該ゲートウェイ装置を介して、ユーザに着信を通知することを第2の特徴とする。
【００２１】
更に、端末上の着信通知用プログラムを用いて、着信通知を受信したユーザに、呼の継続処理方法を選択する手段を提供し、ユーザの選択した手段を該着信通知信号に対する応答信号として、ゲートウェイ装置とサービス制御ゲートウェイ装置を介して、サービス制御装置に送信し、該当サービス制御装置は、受信情報を用いて、ＩＮサービスの処理を継続することを第3の特徴とする。
【００２２】
ユーザがインターネットにアクセスしているという情報をサービス制御ゲートウェイ装置を介して、サービス制御装置に登録しておくことにより、該当ユーザに着信があった場合に、該当ユーザの要求に応じたサービス（例えば、呼の転送先の指定）を提供することが可能となる。
【００２３】
【発明の実施の形態】
本発明の実施の形態を図面を用いて説明する。
【００２４】
図１は、本発明の第１の実施例として、「インテリジェントネットワークのＳＣＰとＩＰ網のＷＷＷサーバ３とがサービス制御ゲートウエイ装置１を介して接続された網構成」を示す。
【００２５】
インテリジェントネットワーク（ＩＮ）は、サービス制御ポイント（ＳＣＰ）２を含む高機能（Intelligent Layer）網と、それぞれ加入者線５（５ａ〜５ｎ）を介して複数の加入者端末装置６（６ａ〜６ｎ）を収容している複数の交換機４（４a、４ｂ）を含む伝達（Transport Layer）網と、上記２つの網を接続するための、例えば、Ｎｏ．７共通線信号方式（ＳＳ７）の共通線信号網９とからなっている。インテリジェントネットワークは、上記ＳＣＰに接続されたサービス管理ポイント（ＳＭＰ）を含むが、ＳＭＰは本発明に関係しないため、図面から省略してある。上記各交換機４は、サービス・スイッチング・ポイント（ＳＳＰ）と称されている。
上記ＳＣＰ２は、各交換機のみでは対応できない特殊な交換サービスを実行するためのものであり、これによって、例えば、ユーザが予め指定された番号をダイヤルすると着信側ユーザに課金されるフリーダイヤル・サービスや、番号変換サービスのような、「ネットワークワイドなサービス」と、例えば、ユーザ毎に予め登録してある着信サービスデータをアクセスすることによって時間帯によって異なるサービスを提供する「カスタマサービス」が実現される。
【００２６】
上記各交換機４は、例えば、発呼が検出された時、呼（またはダイヤル番号）と対応した新たなＢＣＳＭ（Basic Call State Model）を生成し、該ＢＣＳＭに従って、その後の基本呼処理を実行するように構成されている。上記各ＢＣＳＭは、複数の状態（またはステップ）からなり、これらの状態のうちの幾つかがＳＣＰをアクセスするためのトリガの設定対象となるＤＰ（Detection Point）として定義されている。検出された発呼が、上記ＳＣＰ２にアクセスする必要のある呼（ＩＮ呼）の場合、ＩＮサービスの種類によって決まる特定ＤＰに予めトリガを設定したＢＣＳＭが生成され、呼の状態が上記特定ＤＰに遷移した時点で、該ＤＰに設定されたトリガの種類に応じたメッセージが交換機からＳＣＰ２に送信される。ＳＣＰ２は、上記トリガ種類によって決まるサービスプログラムを実行することによって、各呼に前述した特殊な交換サービスを提供する。上記ＳＣＰ２にアクセスする必要のない呼（一般呼）の場合、ＳＣＰをアクセスするためのトリガを全く含まないＢＣＳＭが生成され、各交換機内で閉じた形で呼処理が実行される。
【００２７】
本発明の第１実施例によれば、インターネット（ＩＰ）網８は、例えば、ゲートウエイ装置からなるアクセスポイント７を介して、上記ＩＮの伝達網と接続され、ＷＷＷサーバ３とサービス制御ゲートウェイ装置（ＳＣＧＷ）１を介して、上記ＩＮのＳＣＰ２と接続されている。
【００２８】
図２は、サービス制御ゲートウェイ装置（ＳＣＧＷ）１の構成を示す。
【００２９】
ＳＣＧＷ１は、ＳＣＰ２やＷＷＷサーバ３との間の通信を制御するためのＣＰＵ１１と、メモリ１２と、ＷＷＷサーバと接続された信号線１４を終端するためのＩＰ網インタフェース部１３と、ＳＣＰと接続された信号線１６を終端するための高機能網インタフェース部１５と、これらの要素を接続するバス１７とからなっている。
【００３０】
ＳＣＧＷ１は、ＷＷＷサーバ３とＳＣＰ２との間で交信されるインターネット・コール・ウエイティング・サービスに関する制御メッセージのメッセージ形式の変換と、中継を行なうためのもので、メモリ１２に、上述したメッセージ形式の変換と中継を行なうためのプログラム、ユーザ認証に必要な情報と共に、図３Ａに示すＳＣＰアドレス管理テーブル４００と、図３Ｂに示すユーザ管理テーブル４１０を備えている。
【００３１】
ＳＣＰアドレス管理テーブル４００は、インターネット側（本実施例ではＷＷＷサーバ３）からメッセージを受信した時、アクセスすべきＳＣＰを決定するために参照されるもので、図３Ａに示すように、メッセージ種類４０１およびネットワークＩＤ４０２と対応して、該受信メッセージの送信先となるＳＣＰのアドレス４０３と、サービス番号４０４を定義している。
【００３２】
図１では、ＳＣＧＷ１には１つのＳＣＰ２しか接続されていないが、図３Ａに示すＳＣＰアドレス管理テーブル４００では、ＳＣＧＷ１に複数のＳＣＰが接続された通信網を想定し、インターネット・コール・ウエイティング・サービスの要求元端末装置が収容されているインテリジェント網のネットワークＩＤに応じて、異なるＳＣＰに受信メッセージを転送するようにしてある。サービス番号４０４は、トリガ情報に代わって、ＳＣＰ２に実行すべきサービスプログラムを指定するための情報である。
【００３３】
ユーザ管理テーブル４１０は、図３Ｂに示すように、ユーザＩＤ毎に生成された複数のエントリ（またはレコード）からなり、各エントリは、ユーザＩＤ４１１と対応して、インターネット・コール・ウエイティング・サービスの要求元端末を示す電話番号４１２と、ＳＣＰとＳＣＧＷ１との間での通信において送信メッセージと受信メッセージとの対応関係を判断するために使用される相関ＩＤ４１３と、ＷＷＷサーバ３とＳＣＧＷ１との間での通信において送信メッセージと受信メッセージとの対応関係を判断するために使用される相関ＩＤ４１４と、ＷＷＷサーバアドレス４１５と、サービスの状態コード４１６と、ＷＷＷサーバからサービス要求元の端末に送信すべき着信通知表示データの格納位置を示すＵＲＬ識別情報４１７とを記憶している。
【００３４】
ＷＷＷサーバ３は、インターネット上で提供される各種のサービス情報を蓄積しており、各ユーザは、ユーザ端末が備えるブラウザを介してＷＷＷサーバと交信することによって、希望するサービス情報を閲覧する。本実施例において、ＷＷＷサーバ３は、インターネット・コール・ウエイティング・サービスをサポートするために、例えば、図４Ａに示すリクエスト管理テーブル４３０と、図４Ｂに示すサービス管理テーブル４４０と、図４Ｃに示すユーザ状態管理テーブル４５０とを備える。
【００３５】
リクエスト管理テーブル４３０は、図４Ａに示すように、端末６とＳＣＧＷ１から受信するメッセージの種類（または要求種類）４３１に対応して、実行すべきサービスプログラム番号４３２を定義している。ＷＷＷサーバは、後述するＩＮサービス要求メッセージ、着呼通知メッセージ、通知応答メッセージなどのインターネット・コール・ウエイティング（ＩＣＷ）サービス用の制御メッセージを受信すると、これらのメッセージと対応したサービスプログラムを実行する。
【００３６】
サービス管理テーブル４４０は、図４Ｂに示すように、リクエスト管理テーブル４３０が示すＩＣＷサービス用のサービスプログラムの番号（４３２）４４１と対応して、ＳＣＧＷアドレス４４２と、ネットワークＩＤ４４３と、サービス番号４４４と、着信通知表示データの格納位置を示すＵＲＬ４４５を定義している。
【００３７】
ユーザ状態管理テーブル４５０は、図４Ｃに示すように、ユーザＩＤ４５１と対応して、サービス状態コード４５２と、ＷＷＷ３とＳＣＧＷ１との間の通信において送信メッセージと受信メッセージとの対応関係を判断するために使用される相関ＩＤ４５３とを定義している。ＷＷＷ３で使用すべき相関ＩＤ４５３は、ＳＣＧＷ１によって指定される。
【００３８】
図５Ａ−図５Ｃは、ＩＣＷサービスを行うためにＳＣＰ２が備えるテーブルの１例を示す。
【００３９】
図５Ａは、サービス決定テーブル４６０を示す。
【００４０】
サービス決定テーブル４６０は、「基本呼の所定の検出ポイント（ＤＰ）で交換機が発行したＩＮサービス要求」が示すトリガ情報４６１と、ダイヤル番号の一部を示す番号情報４６２と、公衆網の特定の加入者（複数）に割り当てられたサービスキー４６３との組み合わせに対応して、実行すべきサービス制御プログラムのプログラム番号４６５を定義した複数のエントリからなる。ここで、エントリ４６０−２が示すプログラム番号“500”をもつサービス制御プログラムは、着信があった電話番号について、図５Ｂに示すポインタアドレステーブル４７０に基いて、図５Ｃに示すユーザ情報管理テーブル４８０に蓄積されたユーザ情報を参照する機能を備えたサービス制御プログラムであると仮定する。
【００４１】
ＳＣＧＷ１からＳＣＰ２に与えられるＩＣＷサービス用のＩＮサービス要求メッセージは、交換機が発行するＩＮサービス要求とは異なり、トリガ情報を含んでいない。そこで、本発明では、ＳＣＰでＩＣＷサービスをサポートするために、「トリガ情報４６１と番号情報４６２とサービスキー４６３との組み合わせ」に代る情報として、サービス番号４６４を適用する。上記サービス決定テーブル４６０に、サービス番号４６４と対応して、ＩＣＷサービス用のサービス制御プログラムのプログラム番号（この例では、“600”）を定義しておく。
【００４２】
図５Ｂは、ＳＣＰのサービス制御プログラムによって参照されるユーザ情報ポインタアドレステーブル４７０を示す。
【００４３】
ユーザ情報ポインタアドレステーブル４７０は、プログラム番号４７１と電話番号（ダイヤル番号）４７２との組み合わせに対応して、図５Ｃに示すユーザ情報管理テーブル４８０の１つのエントリを指すポインタアドレス４７３を記憶している。本発明では、例えば、エントリ４７０−１と４７０−３が示すように、ＩＣＷサービスを受ける資格のある電話番号“0423231111”については、番号“500”のサービス制御プログラムからアクセスしても、番号“600”のサービス制御プログラムからアクセスしても、同一のポインタアドレス“ｘｘ”が得られるように、テーブルエントリが用意されている。
【００４４】
図５Ｃは、ユーザ情報管理テーブル４８０を示す。
【００４５】
ユーザ情報管理テーブル４８０の各エントリは、上記ユーザ情報ポインタアドレステーブル４７０が示すポインタアドレス（４７３）４８１と対応して、ユーザＩＤ４８２と、電話番号（ＤＮ）４８３と、ユーザがインターネットをアクセス中か否かを示すＩＰアクセスフラグ４８４と、制御メッセージの宛先となるＳＣＧＷアドレス４８５と、該ＳＣＰとＳＣＧＷとの間の通信において送信メッセージと受信メッセージとの対応関係を判断するために使用される相関ＩＤ４８６を記憶している。ＳＣＰで使用すべき上記相関ＩＤ４８６は、ＳＣＧＷによって指定される。
【００４６】
本実施例では、インターネットに接続中のユーザ端末からＩＣＷサービスの要求があった時、このサービス要求（ＩＮサービス要求メッセージ）をＷＷＷサーバ３とＳＣＧＷ１を介してＳＣＰ２に伝え、サービス制御プログラム“600”によって、上記ユーザ端末がＩＰアクセス中であることをユーザ情報管理テーブル４８０のＩＰアクセスフラグ４８４によって記憶しておく。上記ユーザ端末に着信があった時、ＳＣＰ２は、サービス制御プログラム“500”によって上記ユーザ情報管理テーブル４８０を参照し、もし、着信端末がＩＰアクセス中であれば、ＳＣＧＷ１とＷＷＷサーバ３とを介して、ＩＰパケットでユーザ端末に着信を通知する。着信端末がＩＰアクセス中でなければ、ＩＮサービスの要求元交換機からユーザ端末に着信が通知される。
【００４７】
図６は、端末６とＷＷＷサーバ３との間で、ＩＣＷサービスのために通信されるＩＰパケット５００のフォーマットを示す。
【００４８】
ＩＰパケット５００は、ＩＰヘッダ５１０と、ＴＣＰ／ＵＤＰヘッダ５２０と、ユーザデータフィールド５３０とからなり、上記ユーザデータフィールド５３０にＩＣＷサービス用の制御メッセージが設定される。
【００４９】
端末６からＷＷＷサーバ３に送信される「ＩＮサービス要求メッセージ」２０３は、メッセージ種類５３１と、メッセージ長５３２と、要求元端末の電話番号５３３と、ユーザＩＤ５３４とを含む。また、ＳＣＰ２からの着信通知に応答して、端末６からＷＷＷサーバ３に送信される「通知応答メッセージ」２６２には、上記項目５３１−５３４の他に、破線で示すように、着呼の取り扱い方法（継続方法）を指定するアクションコード５３５が含まれる。アクションコードが「着呼の転送」を示す場合には、アクションコード５３５の次に「転送先となる電話番号」３５６が続く。
【００５０】
ＳＣＧＷ１とＷＷＷサーバ３との間の通信には、例えば、ＩＥＴＦ(Internet Engineering Task Force）ＰＩＮＴ（PSTN and Internet Internetworking）ワーキンググループで検討されているメッセージ形式を適用できる。また、ＳＣＧＷ１とＳＣＰ２との間の通信には、例えば、ＩＮ用のメッセージ形式を適用できる。
【００５１】
図７は、ＳＣＧＷ１とＷＷＷサーバ３との間の通信に適用されるパケット５０１のフォーマットを示す。
【００５２】
パケット５０１は、ＩＰヘッダ５１０と、ＴＣＰ／ＵＤＰヘッダ５２０と、ＴＣＡＰ（Transaction Capability Application Part）ヘッダ５２５と、ユーザデータフィールド５４０とからなり、上記ユーザデータフィールド５４０に、図８Ａ―図８Ｃに示すメッセージが設定される。
【００５３】
図８Ａは、ＷＷＷサーバ３からＳＣＧＷ１に転送されるＩＮサービス要求メッセージ２０５のフォーマットを示す。
【００５４】
ＩＮサービス要求メッセージ２０５は、端末から受信したＩＮサービス要求メッセージ２０３に基いて生成されるもので、「メッセージ種類５５１と、メッセージ長５５２と、ＳＣＧＷアドレス５５３と、ＷＷＷサーバアドレス５５４と、サービス番号５５５と、電話番号（ダイアル番号）５５６と、ネットワークＩＤ５５７と、ユーザＩＤ５５８と、ＵＲＬ５５９と」をそれぞれ示す複数のフィールドからなっている。
【００５５】
メッセージ種類を示すフィールド５５１には、このメッセージがＩＮサービス要求メッセージであることを示すコードが設定される。また、電話番号フィールド５５６とユーザＩＤフィールド５５８には、端末から受信したＩＮサービス要求メッセージ２０３が示す電話番号５３３とユーザＩＤ５３４がそれぞれ設定され、フィールド５５３、５５５、５５７および５５９には、ユーザ管理テーブル４４０から得たデータが設定され、ＷＷＷサーバアドレスフィールド５５４には、サーバ３のアドレスが設定される。
【００５６】
図８Ｂは、ＳＣＧＷ１が、ＳＣＰ２から受信した図１０Ｂで説明する着呼通知メッセージ２３５に基いて生成し、ＷＷＷサーバ３に送信する「着呼通知メッセージ」２３７のフォーマットを示す。
【００５７】
上記着呼通知メッセージ２３７は、「このメッセージが着呼通知であることを示すメッセージ種類５５１と、メッセージ長５５２と、ＳＣＧＷアドレス５５３と、ＷＷＷサーバアドレス５５４と、ユーザＩＤ５５８と、ＵＲＬ５５９と、相関ＩＤ５６１と」をそれぞれ示す複数のフィールドからなっている。相関ＩＤ５６１は、ＷＷＷサーバからその後に受信する通知応答メッセージ２６４と着呼通知メッセージ２３７との対応関係を判別するためのものであり、上記相関ＩＤ５６１には、図３Ｂに示したユーザ管理テーブル４１０から得た相関ＩＤ４１４の値が適用される。
【００５８】
図８Ｃは、ＷＷＷサーバ３が、端末から受信した通知応答メッセージ２６２に基いて生成し、ＳＣＧＷ１に送信する「通知応答メッセージ」２６４のフォーマットを示す。
【００５９】
上記メッセージ２６４は、「このメッセージが通知応答であることを示すメッセージ種類５５１と、メッセージ長５５２と、ＳＣＧＷアドレス５５３と、ＷＷＷサーバアドレス５５４と、相関ＩＤ５７１と、アクションコード５７２と、転送先電話番号５７３と」をそれぞれ示す複数のフィールドからなっている。相関ＩＤ５７１は、図８Ｂに示した着呼通知メッセージ２３７で指定された相関ＩＤ５６１と同一の値をもつ。
【００６０】
図９は、ＳＣＧＷ１とＳＣＰ２との間の通信に適用されるパケット８００のフォーマットを示す。
【００６１】
上記パケット８００は、着局コード８０１と、発局コード８０２と、リンク選択８０３と、ＳＣＣＰ(Signaling Connection Control Part)ヘッダ８０４と、ＴＣＡＰ(Transaction Capabilities Application Part）ヘッダ８０５と、ユーザデータフィールド８１０とからなり、上記ユーザデータフィールド８１０に、図１０Ａ―図１０Ｃに示すメッセージが設定される。
【００６２】
リンク選択８０３には、現用系と予備系とからなる二重化されたリンクのうちの現用系リンクを指定する情報が設定される。
【００６３】
図１０Ａは、ＳＣＧＷ１からＳＣＰ２に送信される「ＩＮサービス要求メッセージ」２１６のフォーマットを示す。
【００６４】
ＩＮサービス要求メッセージ２１６は、ＷＷＷサーバから受信した図８Ａに示したＩＮサービス要求メッセージ２０５に基いてＳＣＧＷ１で生成されるもので、「メッセージ種類８２１と、メッセージ長８２２と、相関ＩＤ８２３と、送信元ＳＣＧＷアドレス８２４と、宛先ＳＣＰアドレス８２５と、サービス番号８２６と、電話番号（ダイアル番号）８２７と、ユーザＩＤ８２８と」をそれぞれ示す複数のフィールドからなっている。
【００６５】
メッセージ種類を示すフィールド８２１には、このメッセージがＩＮサービス要求メッセージであることを示すコードが設定される。また、宛先ＳＣＰアドレス８２５とサービス番号８２６には、ＳＣＰアドレス管理テーブル４００から検索されたデータが設定され、相関ＩＤ８２３には、ユーザ管理テーブル４１０の相関ＩＤ４１３の値が設定される。送信元ＳＣＧＷアドレス８２４には、ＳＣＧＷ１のアドレスが設定され、その他の項目８２７−８２８には、ＷＷＷサーバから受信したＩＮサービス要求メッセージ２０５から得られたデータが設定される。なお、ユーザデータフィールド８１０に上記ＩＮサービス要求メッセージ２１６を含むパケット８００は、着局コード８０１にＳＣＰ２のアドレス、発局コード８０２にＳＣＧＷ１のアドレスが設定される。
【００６６】
ＳＣＰ２は、上記ＩＮサービス要求メッセージ２１６を受信すると、サービスプログラム“600”によって、ユーザ管理テーブル４８０の該当エントリのＩＰアクセスフラグ４８４を“１”に設定し、ＳＣＧＷアドレス４８５と相関ＩＤ４８６に、上記ＩＮサービス要求メッセージ２１６が示すＳＣＧＷアドレス８２４と相関ＩＤ８２３の値をそれぞれ設定する。
【００６７】
図１０Ｂは、交換機から「ＩＮサービス加入ユーザへの着信を示すＩＮサービス要求」を受信したＳＣＰ２によって生成され、ＳＣＧＷ１に送信される「着呼通知メッセージ」２３５のフォーマットを示す。
【００６８】
上記着呼通知メッセージ２３５は、このメッセージが着呼通知であることを示すメッセージ種類８２１と、メッセージ長８２２と、相関ＩＤ８２３と、宛先ＳＣＧＷアドレス８３１と、送信元ＳＣＰアドレス８３２と、着信のあった電話番号８２７と、ユーザＩＤ８３３と」をそれぞれ示す複数のフィールドからなっている。相関ＩＤ８２３には、ユーザ管理テーブル４８０の相関ＩＤ４８６が示す値が設定される。
【００６９】
図１０Ｃは、ＳＣＧＷ１が、ＷＷＷサーバ３から受信した通知応答メッセージ２６４に基いて生成し、ＳＣＰ２に送信する「通知応答メッセージ」２６５のフォーマットを示す。
【００７０】
上記メッセージ２６５は、「このメッセージが通知応答であることを示すメッセージ種類８２１と、メッセージ長８２２と、相関ＩＤ８２３と、送信元ＳＣＧＷアドレス８２４と、宛先ＳＣＰアドレス８２５と、アクションコード８４１と、転送先電話番号８４２と」をそれぞれ示す複数のフィールドからなっている。
【００７１】
相関ＩＤ８２３には、ユーザ管理テーブル４１０の相関ＩＤ４１３が示す値が設定され、この値は、着呼通知メッセージ２３５の相関ＩＤ８２３と同一である。
【００７２】
次に、図１１〜図１３に示す信号シーケンスに従って、図１に示した通信網におけるInternet Call Waitingサービスの制御手順について説明する。
【００７３】
図１１は、ＩＣＷサービスに加入している端末６ｂのユーザが、交換機４ａ、４ｂとアクセスポイント（例えば、ゲートウエイ装置）７を介して、インターネット（ＷＷＷサーバ３）にアクセス中（２００）に、ＳＣＰから着呼通知を受けるための「ＩＮサービス要求」（２０２）の入力操作を行った場合に実行される「ＷＷＷサーバ３、ＳＣＧＷ１およびＳＣＰ２の動作とメッセージ・シーケンス」を示している。
【００７４】
端末６ｂでは、ＷＷＷサーバと通信するためのブラウザが動作している。ＩＮサービスを要求する場合、ユーザは、例えば、ブラウザ画面上で、端末６ｂの電話番号（ＤＮ）とユーザＩＤを入力した後、ＩＮサービス要求ボタンをクリックする（２０２）。これによって、図６に示した電話番号（ＤＮ）５３３とユーザＩＤ５３４を含むＩＮサービス要求メッセージ２０３が生成され、上記ＩＮサービス要求メッセージ２０３をユーザデータフィールド５３０に含み、「宛先アドレス（ＳＡ）５１１としてＷＷＷサーバアドレス、送信元アドレス（ＤＡ）５１２として端末６ｂのアドレス」を含むＩＰヘッダ５１０を持ったＩＰパケットが、ＷＷＷサーバ３に送信される。
【００７５】
上記ＩＮサービス要求メッセージ２０３を受信したＷＷＷサーバ３は、受信メッセージのメッセージ種類５３１から「ＩＮサービス要求が受信された」ことを検出すると（２０４）、リクエスト管理テーブル４３０で定義された「受信メッセージのメッセージ種類５３１」に対応したサービスプログラムを実行する。これによって、ユーザ状態管理テーブル４５０に、受信メッセージ２０３から抽出されたユーザＩＤ５３４を検索キー４５１とする新たなエントリが追加される。上記エントリの状態フィールド４５２は、ＩＮサービス要求中であることを示す状態コードが設定されている。また、サービス管理テーブル４４０から検索された「ＩＮサービス要求の宛先となるＳＣＧＷのアドレス４４２、サービス提供網識別子４４３、サービス番号４４４、ＵＲＬ４４５」と、受信メッセージ２０３から抽出された「電話番号（ＤＮ）５３３、ユーザＩＤ５３４」によって、図８Ａに示したＩＮサービス要求メッセージ２０５が生成される。上記ＩＮサービス要求メッセージ２０５は、ＩＰヘッダ５１０の宛先アドレスフィールド５１１にＳＣＧＷ１のアドレスを含む図７に示したＩＰパケットとして、ＳＣＧＷ１に送信される。
【００７６】
上記ＩＮサービス要求メッセージ２０５を受信したＳＣＧＷ１は、図１４に示すＩＰパケット処理ルーチン１４０に従って、ユーザの認証処理とプロトコル変換を行い（２１５）、図１０Ａに示したＩＮサービス要求メッセージ２１６を生成して、ＳＣＰ２に送信する。
【００７７】
すなわち、図１４に示すように、ＳＣＧＷ１は、ＷＷＷサーバが送信したＩＰパケットをＩＰ網インタフェース１３から受信すると（ステップ１４１）、受信メッセージに含まれるユーザＩＤ５５８を、予めメモリ１２に記憶されているＩＮサービス加入者のユーザＩＤリストと照合し、ユーザＩＤ５５８がＩＮサービス加入者として登録済みか否かを判定する（ステップ１４２）。ユーザＩＤ５５８が、登録されたＩＮサービス加入者でなかった場合、ＷＷＷサーバ３にエラーメッセージを送信する（ステップ１５２）。
【００７８】
ユーザＩＤ５５８が、登録されたＩＮサービス加入者であった場合、受信メッセージが相関ＩＤを含むか否かをチェックし（ステップ１４３）、もし、受信メッセージが相関ＩＤを含まなければ、受信メッセージから抽出されたメッセージ種類５５１とネットワークＩＤ５５７に基いて、図３Ａに示したＳＣＰアドレス管理テーブル４００を参照することによって、ＩＮサービス要求の宛先となるＳＣＰのアドレス４０３とサービス番号４０４を決定し、ＳＣＰとＳＣＧＷとの間の通信で使用する相関ＩＤ４１３と、ＷＷＷとＳＣＧＷとの間の通信で使用する相関ＩＤ４１４を割り当てた（ステップ１４４）後、「受信メッセージ２０５をＩＮサービス要求メッセージ２１６を含むパケット８００に変換する」プロトコル変換を行う（ステップ１４６）。受信メッセージが相関ＩＤを含む場合は、ユーザ管理テーブル４１０から、相関ＩＤ４１３、その他の必要データを読み出し（ステップ１４５）、これらのデータを適用して、プロトコル変換を行う（ステップ１４６）。
【００７９】
次に、ユーザ管理テーブル４１０において、ユーザＩＤと対応したエントリの状態コード４１６を更新する。ユーザＩＤと対応したエントリがユーザ管理テーブル４１０にない場合は、新たなエントリを追加する（ステップ１４７）。次に、ステップ１４６で生成されたパケットをＳＣＰ２に送信し（１４８）、ＳＣＰ２からの応答を待つ（ステップ１４９）。ＳＣＰ２から応答（ＡＣＫ）２１８を受信すると（ステップ１５０）、ＷＷＷサーバ３に応答２１９を送信し（ステップ１５１）、次のＩＰパケットの受信を待つ。
【００８０】
ＳＣＧＷ１からＩＮサービス要求メッセージ２１６を受信したＳＣＰ２は、受信パケットから抽出されたサービス番号８２６に基いて、サービス決定テーブル４６０を参照し、実行すべきサービス制御プログラム“600”を起動する。これによって、ユーザ情報ポインタアドレステーブル４７０から、受信メッセージ２１６に含まれる電話番号８２７と対応するポインタアドレス４７３（例えば、アドレス“ｘｘ”）が検索され、ユーザ情報管理テーブル４８０の上記ポインタアドレスが指すエントリにおいて、ユーザがインターネットをアクセス中であることを示すＩＰアクセスフラグ４８４と、受信メッセージ２１６から得られたＳＣＧＷアドレス４８５と相関ＩＤ４８６の値がそれぞれ記憶される。この後、ＳＣＰ２は、上記ＩＮサービス要求２１６に対する応答（ＡＣＫ）２１８をＳＣＧＷ１に送信する。
【００８１】
上述したＩＰ網からＩＮ網へのＩＮサービス要求メッセージの転送の結果、「ＩＣＷサービスに加入している特定ユーザ（ユーザＩＤまたは電話番号）が、現在、ＩＰ網（ＷＷＷサーバ）にアクセス中か否か」を、ユーザ管理テーブル４８０のＩＰアクセスフラグ４８４で判定可能となる。従って、交換機４ａから特定電話番号に着信があったことを通知されたとき、ＳＣＰ２は、例えば、サービス制御プログラム“500”によって、上記ユーザ管理テーブル４８０を参照し、上記特定電話番号に付随するＩＰアクセスフラグ４８４の状態から、もし、端末６ｂがＩＰ網をアクセス中の場合はＳＣＧＷ１とＷＷＷサーバ３を介して、そうでない場合は交換機４ａを介して、ユーザに着信を通知することが可能となる。
【００８２】
図１２は、ＷＷＷサーバ３にアクセス中の端末６ｂに、他の端末（電話機）６ａから着信があった場合のメッセージ・シーケンスを示す。
【００８３】
交換機４ａは、端末６ａからの発呼要求（Setup）２３１を受信し、着番号に対応するユーザがＩＮサービスに加入していることを検出すると、ＳＣＰ２に対してＩＮサービス要求（Initial DP）メッセージ２３２を送信する。また、端末６ａに対して、上記発呼要求の受け付け通知（Call proc）２３３を送信する。
【００８４】
上記ＩＮサービス要求メッセージ２３２を受信したＳＣＰ２は、受信メッセージ２３２に含まれるトリガ情報と着番号に基いて、サービス決定テーブル４６０から、実行すべきサービス制御プログラム（例えば、プログラム番号“500”のサービス制御プログラム）を決定する（ステップ２３４）。上記サービス制御プログラムを構成する機能ルーチンのうちの１つであるユーザ情報取得ルーチンが実行されると、プログラム番号４７１と着番号とに基づいて、ユーザ情報ポインタアドレステーブル４７０からポインタアドレス（例えば、“ｘｘ”）が検索され、該ポインタアドレスに従って、ユーザ情報管理テーブル４８０から、着番号に対応したＩＣＷサービス用の制御情報４８２−４８６が取得される。
【００８５】
上記制御情報の一部であるＩＰアクセスフラグ４８４の状態から、被呼ユーザがインターネット（ＷＷＷサーバ）にアクセス中であることが判明すると、上記サービス制御プログラム“500”は、図１０Ｂに示した着信通知メッセージ２３５を生成し、該メッセージを含むパケット８００をＳＣＧＷ１に対して送信した後、ＳＣＧＷ１からの受信応答（ＡＣＫ）待ちとなる。もし、被呼ユーザがインターネットをアクセス中でなければ、ＳＣＰ２は、ＩＮサービス要求（Initial DP）メッセージ２３２の送信元である交換機４ａに対して、着信通知を指令する。
【００８６】
ＳＣＧＷ１からの受信応答（ＡＣＫ）を受信すると、サービス制御プログラム“500”は、上記着信通知メッセージ２３５に対するユーザ回答である通知応答メッセージの受信待ち状態となる。
【００８７】
ＳＣＧＷ１は、上記着信通知メッセージ２３５を受信すると、図１５に示すＩＮパケット処理ルーチン１６０を実行する（２３６）。
【００８８】
ＩＮパケット処理ルーチン１６０では、ＳＣＰからメッセージを受信すると（ステップ１６１）、受信メッセージ２３５に含まれる相関ＩＤ８２３をチェックし（ステップ１６２）、該相関ＩＤが、上記受信メッセージ２３５に含まれるユーザＩＤ８３３と対応してユーザ管理テーブル４１０に記憶されている相関ＩＤ４１３と不一致の場合は、ＳＣＰに対して、エラー応答を送信する（ステップ１７０）。もし、相関ＩＤ８２３と相関ＩＤ４１３との一致が確認された場合、ユーザ管理テーブル４１０から相関ＩＤ４１４、ＷＷＷサーバアドレス４１５、ＵＲＬ４１７を読み出し（ステップ１６３）、図８Ｂに示した着信通知メッセージ２３７を含むＩＰパケット５０１を生成し（ステップ１６４）、ユーザ管理テーブル４１０の上記被呼ユーザと対応するエントリの状態フィールド４１６に着信通知中を示すコードを設定（ステップ１６５）した後、これを被呼ユーザがアクセスしているＷＷＷサーバ３に対して送信する（ステップ１６６）。
【００８９】
ＳＣＧＷ１は、ＷＷＷサーバ３からの応答（ＡＣＫ）を待ち（ステップ１６７）、ＷＷＷサーバ３からの応答（ＡＣＫ）２３８を受信すると（ステップ１６８）、ＳＣＰ２に上記着信通知メセージ２３５に対する応答（ＡＣＫ）２３９を送信して（ステップ１６９）、次のＩＮパケットの受信待ち状態となる。
【００９０】
上記着信通知メッセージ２３７を受信したＷＷＷサーバ３は、該着信通知に対する応答信号（ＡＣＫ）２３８をＳＣＧＷ１に送信した後、上記着信通知メッセージ２３７が示す相関ＩＤ５６１を、ユーザＩＤ５５８と対応するユーザ状態管理テーブルエントリの相関ＩＤフィールド４５３に記憶し、上記エントリの状態フィールド４５２に、着信通知があったことを示す状態コードを設定する。ＷＷＷサーバ３は、更に、上記着信通知メッセージ２３７で指定されたＵＲＬ５５９に基いてメモリから着信通知表示データを読み出し、これを着信通知メッセージ２４１として、ユーザ端末６ｂ上で動作中のブラウザに送信する（２４０）。
【００９１】
上述したＳＣＰ動作とメッセージ転送により、ユーザが、ＷＷＷサーバにアクセスしている最中に着信があった場合、ＳＣＰから発行された着信通知をＳＣＧＷ１とＷＷＷサーバ３を介して、ユーザ端末のブラウザ画面に表示することが可能となる。
【００９２】
図１３は、着信通知を受信したユーザが、着呼の取り扱い方法を指定する通知応答を入力した場合のメッセージ・シーケンスを示す。
【００９３】
ブラウザを介して着信通知を受信した端末６ｂのユーザは、着呼の取り扱い方法として、(ａ)発呼ユーザに被呼ユーザが話中である旨をアナウンスする、(b)着呼をメールボックスへ接続する、(ｃ)指定された転送先電話番号に接続する、（ｄ）呼を切断する、等のメニューから選択する。ここでは、ユーザが、上記着信通知に対する応答入力（２６１）として、転送メニューを選択し、転送先の電話番号を入力した場合の動作について説明する。
【００９４】
ユーザが、転送メニューを選択し、転送先の電話番号を入力すると、図６に示した「アクションコード５３５と転送先電話番号５３６を含む通知応答メッセージ２６２」を含むＩＰパケット５００が、端末６ｂからＷＷＷサーバ３に送信される。上記通知応答メッセージ２６２を受信すると、ＷＷＷサーバ３は、リクエスト管理テーブル４３０で定義された「受信メッセージのメッセージ種類５３１と対応するサービスプログラム」を実行する（２６３）。これによって、サービス管理テーブル４４０から読み出されたアドレス情報と、ユーザ状態管理テーブル４５０から読み出された「受信メッセージのユーザＩＤ５３４と対応する相関ＩＤ４５３」を適用して、図８Ｃに示した通知応答メッセージ２６４が生成され、ＩＰパケット５０１としてＳＣＧＷ１に送信される。
【００９５】
上記通知応答メッセージ２６４を受信したＳＣＧＷ１は、図１４に示したＩＰパケット処理ルーチンを実行し、ＳＣＰアドレス管理テーブル４００から得られたＳＣＰアドレス４０３と、ＩＮサービス要求メッセージ２０５の受信時にユーザ管理テーブル４１０に記憶された相関ＩＤ４１３と、受信パケット２６４が示すアクションコード５７２と転送先電話番号５７３を適用して、図１０Ｃに示す通知応答メッセージ２６５を生成し、これをパケット８００としてＳＣＰ２に送信する。
【００９６】
上記通知応答メッセージ２６５がＳＣＰ２で受信されると、該通知応答メッセージの受信待ちとなっていたサービス制御プログラム“500”によって、受信メッセージ２６５の相関ＩＤ８２３とユーザ情報管理テーブル４８０の相関ＩＤ４８６とを照合して、受信メッセージが認証される。受信メッセージから転送先電話番号８４２が特定されると、転送処理用のサービス制御プログラムが実行され、これによって、交換機４ａに、上記転送先電話番号を含むConnectメッセージ２６９が送信される。また、ＳＣＧＷ１に対して、上記通知応答メッセージ２６５に対する受信応答（ＡＣＫ）２６７が送信される（２６６）。
【００９７】
上記Connectメッセージ２６９を受信した交換機４ａは、端末６ｂに着信した呼を上記受信メッセージで指定された電話番号８４２に接続するための呼接続処理（２７０）を実行し、転送先端末にSetup信号２７１を送信する。一方、ＳＣＰから受信応答（ＡＣＫ）２６７を受信したＳＣＧＷ１は、ＷＷＷサーバ３に対して、受信応答（ＡＣＫ）２６８を送信する。
【００９８】
図１６は、加入者端末で動作するブラウザ機能の一部を構成するＩＮサービス要求ルーチンを示す。上記ＩＮサービス要求ルーチンは、ユーザが、加入者端末６ｂ上でブラウザを起動し、ＩＮサービスメニューを選択することにより実行される。
【００９９】
ユーザが、ＩＮサービスを中継するＷＷＷサーバ３を指定する入力操作を行うと、ＩＮサービス要求ルーチンは、ＷＷＷサーバに画面表示情報の送信を要求し（ステップ６０２）、ＷＷＷサーバからの応答を待つ（６０３）。ＷＷＷブラウザから画面表示情報を含むパケットを受信すると、受信情報を解析し（６０５）、表示情報をユーザ端末の表示画面に出力する（６０６）。これによって、ＩＮサービス要求のための入力画面がユーザに提供される。
【０１００】
ユーザが、上記入力画面で端末の電話番号（ＤＮ）とユーザＩＤを入力し（６０７）、表示画面に用意された送信ボタンをクリックすると、図６に示したＩＮサービス要求メッセージ２０３を含むＩＰパケットが生成され、ＷＷＷサーバに送信される（６０８）。ＷＷＷサーバからの応答を待ち（６０９）、ＷＷＷサーバが端末からの送信メッセージを正しく受理したことを示す応答信号を受信すると（６１０）、ユーザ情報として、上記電話番号（ＤＮ）と、ユーザＩＤと、ＩＮサービス要求中を示す状態コードとを記憶し（６１１）、このルーチンを終了する。ステップ６０４または６１０で、ＷＷＷサーバ３からエラー応答を受信した場合は、エラーが発生したことを端末画面に表示し（６１３）、ユーザからの入力待ち状態となる。
【０１０１】
図１７は、加入者端末で動作するブラウザ機能の一部を構成するＩＮサービス通知ルーチンの機能を示す。このルーチンは、ＳＣＧＷ１から着信通知２３７を受信したＷＷＷサーバ３が、端末６ｂで動作するブラウザに着信通知メッセージ２４１を送信した場合に起動される。
【０１０２】
ＩＮサービス通知ルーチンは、ＷＷＷサーバから送信された着信通知メッセージ２４１を受信し（ステップ６２２）、受信したメッセージ情報を解析する（６２３）。次に、上記受信メッセージに含まれる着信通知表示データを端末画面に表示し（６２４）、状態コードを着信通知受信を示すコードに更新する（６２５）。上記着信通知表示データによって、端末の表示画面には、ユーザが指定できる着呼の取り扱い方法として、例えば、（ａ）アナウンス、（ｂ）メールボックスへの接続、（ｃ）転送、（ｄ）切断のうちの１つを選択するためのメニューが提供されている。
【０１０３】
ユーザが、画面に表示されたメニューのうちの１つを選択し、もし、転送を選択した場合には、更に、転送先の電話番号を入力した後、送信ボタンをクリックすると（６２６）、アクションコード５３５と転送先電話番号５３６を含む通知応答メッセージ２６２が生成され、ＷＷＷサーバ３に送信される（６２７）。この後、ＩＮサービス通知ルーチンは、ＷＷＷサーバからの応答を待ち（６２８）、ＷＷＷサーバが上記通知応答メッセージ２６２を正しく受理したことを示す応答（ＡＣＫ）を受信すると（６２９）、このルーチンを終了し、ＷＷＷサーバからの新たなメッセージ待ち状態となる。
【０１０４】
上述したＩＮサービス要求ルーチンとＩＮサービス通知ルーチンを実行することによって、端末ユーザは、ブラウザ画面で、ＩＮサービス要求の入力、着信通知の受信、着呼の取り扱い方法の指定をすることが可能となる。
【０１０５】
図１８は、端末６ｂからＩＮサービスの取消し要求があった時、ＷＷＷサーバ３で実行されるＩＮサービス終了ルーチンのフローチャートを示す。ＩＮサービスの取消し要求メッセージは、ＩＮサービス要求メッセージ２０３と同様、電話番号とユーザＩＤを含み、例えば、ブラウザ画面に用意されたＩＮサービス終了ボタン、または、インターネットアクセスの終了ボタンが選択されたことに応答して、ＷＷＷサーバ３に送信される。
【０１０６】
ＩＮサービス終了ルーチンは、端末６ｂからＩＮサービスの取消し要求メッセージを受信すると（９０２）、受信メッセージを解析し（９０３）、ユーザ状態管理テーブル４５０の上記受信メッセージのユーザＩＤと対応するエントリの削除、または、該エントリの状態フィールド４５２をＩＮサービス取消し状態に変更する（９０４）。次に、ＳＣＧＷ１に対し、ＩＮサービス取消し要求メッセージを送信し（９０５）、ＳＣＧＷからの応答待ちとなる（９０６）。
【０１０７】
ＳＣＧＷ１は、上記取消し要求メッセージを受信すると、ユーザ管理テーブル４１０の上記メッセージのユーザＩＤと対応するエントリの削除、または、該エントリの状態フィールド４１６をＩＮサービス取消し状態に変更した後、ＳＣＰ２に対してＩＮサービス取消要求メッセージを送信する。上記ＩＮサービス取消要求メッセージを受信したＳＣＰ２は、ユーザ情報管理テーブル４８０の上記ユーザＩＤに該当するＩＰアクセスフラグ４８４をクリアした後、ＳＣＧＷに取消し確認応答信号を送信する。上記確認応答信号は、ＳＣＧＷ１からＷＷＷサーバ３に転送される。ＷＷＷサーバ３は、ＳＣＧＷ１から確認応答信号を受信すると（９０７）、端末６ｂ上で動作するブラウザに対して、取消確認信号を送信して（９０８）、このルーチンを終了する。
【０１０８】
図１９は、本発明の第２の実施例の網構成を示す。
【０１０９】
図１と比較すると、図１９の網構成は、「インテリジェントネットワークのＳＣＰとＩＰ網とがサービス制御ゲートウエイ装置（ＳＣＧＷ）１を介して接続され、インテリジェントネットワークの伝達網とＩＰ網とを接続するゲートウェイ装置７に、上記ＳＣＧＷ１との通信機能を備えた」ことを特徴とする。ＳＣＧＷ１は、例えば、図示しないルータを介してＩＰ網に接続される。但し、上記ＳＣＧＷ１は、ゲートウェイ装置７が備えるＩＰ網インタフェースに接続してもよい。
【０１１０】
本実施例において、ＳＣＧＷ１は、図１４に示したＩＰパケット処理ルーチンと図１５に示したＩＮパケット処理ルーチンにおけるＩＰ網側の通信相手をＷＷＷサーバ３からゲートウエイ装置７に変更すればよく、実質的に第１実施例と同じ構成となっている。
【０１１１】
ゲートウェイ装置７は、加入者端末６をダイヤル・アップ接続によってＩＰ網に接続するために必要な機能と、端末６とインターネットプロトコルによって通信する通信機能と、第１実施例でＷＷＷサーバ３によって行われていたＳＣＧＷ１との間でＩＮサービス制御メッセージを通信するための機能とを備える。
【０１１２】
これらの機能を実現するために、ゲートウエイ装置７は、加入者毎の認証情報と、加入者毎の付加サービス情報と、図４Ａ−図４Ｃで説明したインターネット・コール・ウエイティング・サービス用の管理テーブル４３０−４５０と、これらの情報を利用して制御動作を行うための複数のプログラムを蓄積している。
【０１１３】
また、第１の実施例では、インターネットアクセス中に、ユーザがＩＮサービス要求入力操作を行った時、ＩＮサービス要求メッセージが端末６からＩＰ網に送信されていたが、この第２実施例では、端末とゲートウエイ装置７との間にＩＰ通信のためのコネクションを確立した時、ゲートウエイ装置７が自動的にＩＮサービス要求メッセージを生成し、該メッセージをＳＣＧＷ１に送信するようにしている。上述したＩＮサービスメッセージ処理機能を装備するのに適したゲートウェイ装置７として、具体的には、サービスプロバイダによって運営、管理されているアクセスポイントがある。
【０１１４】
加入者端末６ｂは、ダイヤル・アップ接続機能と、インターネット接続中に、第１実施例のＷＷＷサーバの代わりに、ゲートウエイ装置７との間で、ＩＮサービス制御メッセージを送受信するための、図１７で説明したＩＮサービス通知ルーチンと同様のプログラムを備える。
【０１１５】
図２０は、ゲートウェイ装置７の構成を示す。
【０１１６】
ゲートウェイ装置７は、端末６やＳＣＧＷ１との間の通信を制御するためのＣＰＵ７１と、前述した各種の情報とプログラムを格納するためのメモリ７２と、ＩＰ網に接続された信号線７４を終端するためのＩＰ網インタフェース部７３と、インテリジェントネットワークの伝達網に接続された信号線７６を終端するための伝達網インタフェース部７５と、これらの要素を接続するバス７７とからなっている。ＣＰＵ７１とＳＣＧＷ１との間の通信は、図７に示したパケットを使用するインターネット・プロトコルに従って行われ、ＣＰＵ７１と伝達網との間の通信は、例えば、Ｎ−ＩＳＤＮのユーザ・網インタフェース・プロトコルに従って行われる。
【０１１７】
図２１〜図２３を参照して、第２実施例の通信網におけるInternet Call Waiting サービスの制御手順方法について説明する。
【０１１８】
図２１は、端末６ｂのユーザが、ダイヤル・アップ機能を利用してＩＰ網８と接続するため、ゲートウェイ装置７に対して発呼信号（Setup）１０１Ａを送信すると、上記端末６ｂが接続された交換機４ａが、上記発呼信号（Setup）１０１Ａを発呼信号（Setup）１０１Ｂとして、ゲートウェイ装置７に転送すると共に、端末６ｂに対して呼受付信号（Call Proc）１０２を返送する。
【０１１９】
ゲートウェイ装置７は、発呼信号（Setup）１０１に応答して、図２４に示す呼信号処理ルーチンを実行する。
【０１２０】
すなわち、伝達網インタフェース７５から発呼信号（Setup）１０１を受信すると（ステップ７４１）、受信信号に含まれる情報要素を解析し、着信を受け付け可能か否かを判別する（ステップ７４２）。着信を受け付ける場合は、ゲートウェイ装置７から交換機４ａに、応答信号（Ｃｏｎｎｅｃｔ）１０４を送信する（ステップ７４３）。上記応答信号を受信した交換機４ａが、端末６ｂに応答信号（Ｃｏｎｎｅｃｔ）１０５を送信することによって、ゲートウェイ装置７と端末６ｂが電話回線で接続される。
【０１２１】
この後、ゲートウェイ装置７は、上記電話回線を通して端末６ｂとＩＰパケット通信を行うために、ＰＰＰ（Point to Point）接続動作を開始する。先ず、端末６ｂとゲートウエイ装置７との間に、例えば、ＬＣＰ(Link Control Protocol)を適用して、リンク１０６を確立する。次に、端末６ｂからユーザＩＤとパスワードを含む認証要求を受信し（ステップ７４５）、メモリ７２に蓄積してある認証情報を用いて、上記ユーザＩＤとパスワードの認証処理１０８を行い（ステップ７４６）、上記ユーザＩＤとパスワードが認証された場合は、認証応答１０９を端末６ｂに送信する（ステップ７４７）。尚、上記認証処理は、ゲートウエイ装置７に接続された図示しないユーザ認証用サーバによって実行するようにしてもよい。
【０１２２】
ゲートウェイ装置７は、端末６ｂからＩＰアドレス割当て要求１１０を受信すると（ステップ７４８）、メモリ７２に形成されているＩＰアドレスプールから１つの空きＩＰアドレスを取得し、該空きＩＰアドレスとユーザＩＤとの対応関係をユーザ情報テーブルに記憶（ステップ７４９）した後、該ＩＰアドレス１１２を端末６ｂに通知する（ステップ７５０）。
【０１２３】
ゲートウェイ装置７は、次に、メモリ７２に予め蓄積されているユーザ毎のＩＮサービス情報テーブルを検索し（ステップ７５１）、端末６ｂのユーザがＩＮサービスの加入ユーザであることが判明すると、図８に示したＩＮサービス要求メッセージ２０５を生成し、ＳＣＧＷ１に送信（ステップ７５２）した後、ＳＣＧＷ１からの受信応答（ＡＣＫ）２１９を待つ。ＳＣＧＷ１からの応答（ＡＣＫ）２１９を受信すると（ステップ７５４）、ＰＰＰ接続中の状態１９９となる。
【０１２４】
尚、ステップ７４２で発呼信号の情報要素を解析した結果、着信できない場合、ステップ７４６でユーザ認証に失敗した場合、または、ステップ７４９でＩＰアドレスプールに空きＩＰアドレスがなかった場合は、端末６ｂにエラーメッセージを送信する（ステップ７５６）。
【０１２５】
上記ＩＮサービス要求メッセージ２０５を受信したＳＣＧＷ１は、第１実施例と同様、図１４に示したＩＰパケット処理ルーチンを実行し、ユーザ認証処理によってユーザの正当性を確認した後、プロトコル変換されたＩＮサービス要求メッセージ２１６をＳＣＰ２に送信する。また、ＳＣＰ２から受信応答（ＡＣＫ）２１８を受信すると、ＳＣＧＷ１は、ＩＮサービス要求メッセージ２０５の送信元であるゲートウエイ装置７に対して、受信応答（ＡＣＫ）２１９を送信した後、上記ＩＰパケット処理ルーチンを終了する。ＩＮサービス要求メッセージ２１６を受信した時、ＳＣＰ２は、第１実施例と同様のサービス要求登録処理２１７を実行する。
【０１２６】
図２２は、ゲートウエイ装置７とＰＰＰ接続中の端末６ｂに、他の端末６ａから着信があった場合のメッセージ・シーケンスを示す。
【０１２７】
図１２に示した第１実施例と比較して明らかなように、第２実施例では、ＳＣＧＷ１から送信された着信通知メッセージ２３７をゲートウエイ装置７が受信しており、ゲートウエイ装置７が、第１実施例のＷＷＷサーバ３に代わって、図２５に示すプログラムに従って、端末６ｂへの着信通知メッセージ２４１の転送と、ＳＣＧＷ１への受信応答（ＡＣＫ）２４２の送信を行っている。
【０１２８】
すなわち、ゲートウェイ装置７は、ＳＣＧＷ１から着信通知メッセージ２３７を受信すると（ステップ７６１）、受信メッセージのメッセージ種類５５１に対応したサービスプログラムを起動して、図２１のステップ１１１（図２４のステップ７４９）で記憶してある「ＩＰアドレスとユーザＩＤとの対応関係を示すユーザ情報テーブル」から、上記受信メッセージが示すユーザＩＤ５５８と対応したＩＰアドレスを読み出す（ステップ７６２）。次に、着信通知用の処理ルーチンを起動して、上記ＩＰアドレスを宛先アドレスとする着信通知ＩＰパケットを生成し（ステップ７６３）、端末６ｂに着信通知メッセージを送信し（ステップ７６４）、ＳＣＧＷ１に、上記着信通知２３７に対する応答（ＡＣＫ）２４２を送信する（ステップ７６５）。
【０１２９】
図２３は、着信通知を受信したユーザが、着呼の取り扱い方法を指定する通知応答を入力した場合のメッセージ・シーケンスを示す。
【０１３０】
図１３に示した第１実施例と比較して明らかなように、第２実施例では、端末６ｂから送信された通知応答メッセージ２６２をゲートウエイ装置７が受信し、ゲートウエイ装置７が、第１実施例のＷＷＷサーバ３に代わって、図２６に示すプログラムルーチンに従って、ＳＣＧＷ１へ通知応答メッセージ２６４を転送している。
【０１３１】
着信通知を受信した端末６ｂのユーザが、端末画面に表示されたメニューの中から、ユーザが希望する着呼の取り扱い、例えば、「転送」を選択し、転送先の電話番号を指定すると（２６１）、端末６ｂからゲートウエイ装置７に、図６に示したフォーマットの通知応答メッセージ２６２が送信される。ゲートウエイ装置７は、端末からの受信メッセージが通知応答の場合、図２６の通知応答処理ルーチンを実行する。
【０１３２】
上記通知応答処理ルーチンでは、通知応答メッセージ２６２を受信すると（ステップ７７１）、サービス管理テーブル４４０とユーザ状態管理テーブル４５０からそれぞれＳＣＧＷアドレスと相関ＩＤを読み出し、図８Ｃに示した通知応答メッセージ２６４を生成し（ステップ７７２）、ユーザ状態管理テーブル４５０の状態フィールド４５２を通知応答状態を示すコードに更新（ステップ７７３）した後、上記通知応答メッセージ２６４をＳＣＧＷ１に送信する（ステップ７７４）。この後、ＳＣＧＷ１からの受信応答（ＡＣＫ）２６８を待ち（ステップ７７５）、ＳＣＧＷ１からの受信応答（ＡＣＫ）２６８を受信すると（ステップ７７６）、このルーチンを終了する。上記通知応答メッセージ２６４を受信したＳＣＧＷ１の動作と、ＳＣＧＷ１から通知応答メッセージ２６５を受信したＳＣＰ２の動作は、第１実施例と同様である。
【０１３３】
図２７は、端末６ｂとゲートウェイ装置７との間の接続が切れた時、ゲートウェイ装置で実行されるＩＮサービス終了ルーチンのフローチャートを示す。
【０１３４】
ＩＮサービス終了ルーチンでは、交換機４から切断信号を受信すると（ステップ７８２）、受信信号を解析し（ステップ７８３）、ユーザ状態管理テーブル４５０から相関ＩＤ４５３を読み出し（ステップ７８４）、ＳＣＧＷ１にＩＮサービス取消要求メッセージを送信し（ステップ７８５）、ＳＣＧＷ１からの応答を待つ（ステップ７８６）。ＳＣＧＷ１から応答信号を受信すると（ステップ７８７）、ＰＰＰ通信に割り当てられたＩＰアドレスと、ゲートウェイ装置７とＳＣＧＷ１との間の通信に使用していた相関ＩＤ４５３とを開放すると共に、状態情報４５２をクリアし（ステップ７８８）、交換機４に対して解放信号を送信して（ステップ７８９）、このルーチンを終了する。
【０１３５】
ゲートウェイ装置７からＩＮサービス取消要求メッセージを受信したＳＣＧＷ１は、第１実施例で図１８を参照して説明したように、ユーザ管理テーブル４１０において、上記端末ユーザと対応するエントリの削除または状態コードの変更を行い、ＳＣＰ２に対してＩＮサービス取消要求メッセージを転送する。また、ＳＣＰ２も、上記ＩＮサービス取消要求メッセージを受信した時、ユーザ情報管理テーブルで上記端末ユーザと対応するＩＰアクセスフラグをクリアする。従って、ＳＣＰによるＩＰ網を介したユーザへの着信通知サービスは、ユーザがインターネットとの通信を切断した時点で、終了する。
【０１３６】
【発明の効果】
以上の実施例の説明から明らかなように、本発明によれば、インターネットを利用中のユーザに対して、インテリジェントネットワークのサービス制御装置（ＳＣＰ）から、インターネットを介して、着信通知メッセージを送付することができる。また、ユーザからの通知応答をインターネットを介してＳＣＰに転送することにより、ＳＣＰから交換機に「ユーザ指定端末への着呼の転送、発呼ユーザへのアナウンス、着呼の切断」などの接続指令を与えることができる。
【０１３７】
従って、ユーザに対して、柔軟な通信サービスの提供が可能になる。
【図面の簡単な説明】
【図１】本発明の第１の実施例である「インテリジェントネットワークのＳＣＰとＩＰ網のＷＷＷサーバ３とが、サービス制御ゲートウエイ装置１を介して接続された網構成」を示す図。
【図２】図１におけるサービス制御ゲートウェイ装置（ＳＣＧＷ）１の構成を示す図。
【図３】図３Ａは、ＳＣＧＷ１が備えるSCPアドレス管理テーブルの構成を示す図。図３Ｂは、ＳＣＧＷ１が備えるユーザ管理テーブルの構成を示す図。
【図４】図４Ａは、図１におけるＷＷＷサーバ３が備えるリクエスト管理テーブルの構成を示す図。図４Ｂは、ＷＷＷサーバ３が備えるサービス管理テーブルの構成を示す図。図４Ｃは、ＷＷＷサーバ３が備えるユーザ状態管理テーブルの構成を示す図。
【図５】図５Ａは、図１におけるＳＣＰ２が備えるサービス決定テーブルの構成を示す図。図５Ｂは、ＳＣＰ２が備えるユーザ情報ポインタアドレステーブルの構成を示す図。図５Ｃは、ＳＣＰ２が備えるユーザ情報管理テーブルの構成を示す図。
【図６】図１における端末装置６とＷＷＷサーバ３との間の通信で使用されるパケットフォーマットの１例を示す図。
【図７】図１におけるＷＷＷサーバ３とサービス制御ゲートウェイ（ＳＣＧＷ）１との間の通信で使用されるパケットフォーマットの１例を示す図。
【図８】図８Ａは、ＷＷＷサーバ３からＳＣＧＷ１に送信されるサービス要求メッセージのフォーマットを示す図。図８Ｂは、ＳＣＧＷ１からＷＷＷサーバ３に送信される着信通知メッセージのフォーマットを示す図。図８Ｃは、ＷＷＷサーバ３からＳＣＧＷ１に送信される通知応答メッセージのフォーマットを示す図。
【図９】図１におけるＳＣＧＷ１とサービス制御ポイント（ＳＣＰ）２との間の通信で使用されるパケットフォーマットの１例を示す図。
【図１０】図１０Ａは、ＳＣＧＷ１からＳＣＰ２に送信されるサービス要求メッセージのフォーマットを示す図。図１０Ｂは、ＳＣＰ２からＳＣＧＷ１に送信される着信通知メッセージのフォーマットを示す図。図１０Ｃは、ＳＣＧＷ１からＳＣＰ２に送信される通知応答メッセージのフォーマットを示す図。
【図１１】端末装置から「着呼通知を要求する」サービス要求メッセージが発行された時、図１に示した通信網において通信される制御信号とメッセージを示す信号シーケンス図。
【図１２】上記端末装置に着信があった時、図１に示した通信網において通信される制御信号とメッセージを示す信号シーケンス図。
【図１３】上記端末装置から通知応答メッセージが発行された時、図１に示した通信網において通信される制御信号とメッセージを示す信号シーケンス図。
【図１４】ＩＰ網からの制御メッセージの受信に応答して実行される、ＳＣＧＷ１の動作を示すフローチャート。
【図１５】ＩＮ網からの制御メッセージの受信に応答して実行される、ＳＣＧＷ１の動作を示すフローチャート。
【図１６】ユーザが着信通知サービスを要求する時に端末装置６において実行される、ブラウザの動作を示すフローチャート。
【図１７】ＷＷＷサーバから着信通知を受信した時に端末装置６において実行される、ブラウザの動作を示すフローチャート。
【図１８】呼切断時に実行される、ＷＷＷサーバの動作を示すフローチャート。
【図１９】本発明の第２の実施例である「ＩＰ網とインテリジェントネットワークのＳＣＰとが、ゲートウエイ装置７とサービス制御ゲートウエイ装置１を介して接続された網構成」を示す図。
【図２０】図１９におけるゲートウエイ装置７の構成を示す図。
【図２１】端末装置から発呼（呼設定）メッセージが発行された時に図１９に示した通信網において通信される制御信号とメッセージとを示す信号シーケンス図。
【図２２】上記端末装置に着信があった時に図１９に示した通信網において通信される制御信号とメッセージとを示す信号シーケンス図。
【図２３】上記端末装置から「指定した接続先への転送を要求する」通知応答が発行された時に図１９に示した通信網において通信される制御信号とメッセージとを示す信号シーケンス図。
【図２４】端末装置からの発呼（呼設定）メッセージの受信時にゲートウエイ７で実行される呼信号処理ルーチンを示すフローチャート。
【図２５】サービス制御ゲートウエイ１からの着信通知メッセージの受信時にゲートウエイ７で実行される着信通知処理ルーチンを示すフローチャート。
【図２６】端末からの通知応答メッセージの受信時にゲートウエイ７で実行される通知応答処理ルーチンを示すフローチャート。
【図２７】呼切断時にゲートウエイ７で実行されるＩＮサービス終了ルーチンを示すフローチャート。
【符号の説明】
１…サービス制御ゲートウェイ装置、２・・・ＳＣＰ、３・・・ＷＷＷサーバ、４…交換機、６・・・加入者端末、７・・・ゲートウェイ装置、１１・・・ＣＰＵ、１２・・・メモリ、１３…ＩＰ網インタフェース部、１５…高機能網インタフェース部。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an intelligent network (IN) serviceable to Internet users, and more particularly to an “intelligent network service control device (hereinafter referred to as SCP) having an Internet Call Waiting service function. The present invention relates to an “IP communication device connected to the Internet Protocol (IP) network” having a communication function with the SCP, and a service control gateway device that connects the SCP and the IP communication device.
[0002]
[Prior art]
One connection method from the public network to the Internet is dial-up connection. By using a dial-up connection, it is possible to connect a home personal computer to the Internet only when necessary, using a general analog telephone line or ISDN line. When a terminal device such as a personal computer is connected to the Internet using a dial-up connection, the terminal device (subscriber) authentication or IP is performed by a gateway device that connects the “analog telephone network or ISDN network” and the Internet network. Address assignment is performed. While the user is connected to the Internet by dial-up connection, the switch that accommodates the subscriber line of the user terminal can connect to the Internet even if the subscriber can identify whether the subscriber is busy. It is not possible to identify whether it is medium or not.
[0003]
On the other hand, the Intelligent Network (IN) that enables service customization and quick service provision is a function-specific plane called a plane (service plane, global function plane, distributed function plane, physical plane). The “capability set 1” that defines each plane and the higher-level “capability set 2” that defines the generation and management of services including inter-network connection services are standardized (ITU-T recommendation) : Q.1220-Q.1228).
[0004]
An intelligent network consists of a transport (Transport Layer) network composed of a plurality of exchanges, a high-function (Intelligent Layer) network composed of a service control device (Service Control Point) connected to the transport network via a common line signal network, and the above-mentioned It consists of a service management device (Service Management Point) connected to the SCP. As described in ITU-T Recommendation Q.1224, the network connection service in “IN Capability Set 2” is mainly a service providing method by linking service data functions and service control functions between IN networks. A method of providing a communication service by linking the IN service control function and the Internet network is not defined.
[0005]
With regard to a method for providing a communication service in cooperation between the IN service control function and the Internet network, ITU-T uses “Internet” for the purpose of transmitting a service request from an Internet user to the IN service control function (SCF). On the other hand, there is a proposal to provide a "user agent function" for users to send service requests and to provide a "service control gateway function" between the Internet and the public network. Specific service provision methods and service realization methods are for further study.
[0006]
[Problems to be solved by the invention]
In recent years, with the diversification of communication services, for example, it is desired to provide an Internet Call Waiting (ICW) service as a new service by linking an IN service control function and the Internet network. . ICW states that when a user who is connected to the Internet receives an incoming call, the user who has received the incoming call notification changes the incoming call continuation processing method (for example, incoming call rejection, call transfer, etc.) from the user terminal to the IN service control function. It is a service function that can be instructed. The IN service control function continues call processing in accordance with an instruction from the user.
[0007]
However, according to the conventional technology, when the user is in a call state on the telephone network, the switch side cannot determine whether the call in progress is an Internet connection call or a general call connecting telephones. When a terminal is communicating with a general call, the called terminal can normally receive an incoming notification signal given as an analog signal from the exchange, but a terminal communicating with an Internet connection call can receive a digital signal. Therefore, the incoming notification of the analog signal given from the exchange is treated as noise and cannot be received. Therefore, at present, an ICW service for notifying a user who is connected to the Internet of an incoming call has not been realized.
[0008]
An object of the present invention is to provide a communication network capable of providing an IN service to a user terminal connected to the Internet.
[0009]
It is another object of the present invention to provide an “intelligent network service control device (Service Control Point) having an Internet Call Waiting service function.
[0010]
Still another object of the present invention is to provide a service control gateway device for connecting an intelligent network service control device (Service Control Point) and the Internet.
[0011]
[Means for Solving the Problems]
To achieve the above object, according to the present invention, an "intelligent network" connected to a plurality of exchanges constituting a transmission network via a common line signal network and connected to an Internet protocol network via a service control gateway device. Service control device "has a user information management table indicating whether or not the terminal devices (multiple) connected to the transmission network are connected to the Internet. By referring to the user information management table, the called terminal determines whether the general call is an Internet connection call. If the called terminal is an Internet connection call, the service control apparatus notifies the called terminal of the incoming call via the service control gateway apparatus via the Internet.
[0012]
More specifically, the “intelligent network service control device” according to the present invention receives a call waiting service request from the first terminal device connected to the Internet protocol network via the transmission network. A first means for storing in the user information management table information indicating that “the first terminal device is connected to the Internet” and one of the plurality of exchanges; When the first terminal device is notified that an incoming call has been received from the second terminal device, the user information management table is referred to, and an incoming notification message for the first terminal device is transmitted to the gateway device. It consists of two means.
[0013]
The user information management table has, for example, an entry including a telephone number of the first terminal, flag information indicating whether or not the first terminal is connected to the Internet, and address information of the gateway device. The first means updates the contents of the entry, and the second means refers to the flag information and address information of the entry.
In the service control apparatus according to the present invention, when the notification response message “indicating a response from the user of the first terminal apparatus to the incoming call notification” is received via the gateway apparatus, the second means One exchange is caused to provide a connection service for an incoming call to the first terminal device according to the response.
[0014]
Connecting an "intelligent network service control device" connected to a plurality of exchanges constituting a transmission network via a common signal network and an "Internet protocol network" connected to the transmission network according to the present invention "Service control gateway device" to
A “service request message” transmitted from the first terminal device connected to the Internet protocol network via the transmission network and requesting an Internet call waiting service by the service control device is sent to the service control. Protocol conversion means for converting the message to the service control device, which includes an identifier that identifies one of a plurality of service control programs executed by the device;
And means for transmitting the protocol-converted message to a signal line connected to the service control apparatus.
[0015]
One feature of the present invention is that the service control gateway device comprises:
An incoming notification message transmitted from the service control device indicating that “the first terminal device has received an incoming call from the second terminal device” is transmitted to the “communication with the first terminal device” included in the Internet protocol network. A protocol conversion means for converting the message to the server in the middle, and means for transmitting the protocol-converted message to a signal line connected to the server. The server has a function of transferring a received message from the service control gateway device to the first terminal device.
[0016]
Another feature of the present invention is that the service control gateway device comprises:
An incoming notification message transmitted from the service control device indicating that “the first terminal device has received an incoming call from the second terminal device” is transmitted to the “communication with the first terminal device” included in the Internet protocol network. A protocol conversion means for converting the message to the “access point device in the middle”, and a means for transmitting the protocol-converted message to a signal line connected to the Internet protocol network. The access point device has a function of transferring a received message from the service control gateway device to the first terminal device.
[0017]
In another communication service control method of the present invention, a transmission network composed of a plurality of exchanges is connected to the Internet network via a gateway device. A service control device including a storage device for storing service control information for each user is connected to the transmission network via a common line signal network. The service control apparatus stores the user information management table and includes the first procedure and the second means.
[0018]
Information related to the subscriber's supplementary service is stored in the gateway device.
[0019]
When the gateway device receives a connection request to the Internet network from a user via an exchange, the gateway device uses the information related to the additional service to subscribe to the additional service for notifying the user who is connected to the Internet of an incoming call. Search the status. When the user subscribes to the additional service, the gateway device transmits an incoming call notification request to the service control gateway device, and the service control gateway device refers to information for identifying the service control device stored in advance. Then, the incoming call notification request is transmitted to the service control apparatus, and the service control apparatus that receives the request updates the service information corresponding to the user using the first means.
[0020]
Further, when the service control apparatus is notified of “incoming call to the user” from the exchange, the service control apparatus transmits an incoming call notification signal to the service control gateway apparatus using the second means, and A second feature is to notify the user of an incoming call via the gateway device.
[0021]
Further, a means for selecting a call continuation processing method is provided to a user who has received an incoming call notification using an incoming call notification program on a terminal, and the means selected by the user is used as a response signal for the incoming call notification signal. A third feature is that the information is transmitted to the service control apparatus via the apparatus and the service control gateway apparatus, and the corresponding service control apparatus uses the received information to continue processing the IN service.
[0022]
By registering information that the user is accessing the Internet in the service control device via the service control gateway device, when a call is received by the user, a service (for example, a request corresponding to the user) (for example, , Designation of call transfer destination).
[0023]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described with reference to the drawings.
[0024]
FIG. 1 shows a “network configuration in which an SCP of an intelligent network and a WWW server 3 of an IP network are connected via a service control gateway device 1” as a first embodiment of the present invention.
[0025]
The intelligent network (IN) includes an intelligent layer network including a service control point (SCP) 2 and a plurality of subscriber terminal devices 6 (6a to 6n) via subscriber lines 5 (5a to 5n), respectively. For connecting the above two networks with a transport (Transport Layer) network including a plurality of exchanges 4 (4a, 4b) accommodating the above-mentioned two networks. 7 common line signal system (SS7) common line signal network 9. The intelligent network includes a service management point (SMP) connected to the SCP, but the SMP is omitted from the drawing because it is not related to the present invention. Each of the exchanges 4 is called a service switching point (SSP).
The SCP 2 is for executing a special exchange service that cannot be handled only by each exchange. For example, when the user dials a number designated in advance, “Network-wide service” such as number conversion service and “customer service” that provides different services depending on time zones by accessing incoming service data registered in advance for each user, for example, are realized. .
[0026]
Each of the exchanges 4 generates, for example, a new BCSM (Basic Call State Model) corresponding to a call (or a dialed number) when a call is detected, and executes subsequent basic call processing according to the BCSM. It is configured as follows. Each of the BCSMs is composed of a plurality of states (or steps), and some of these states are defined as DP (Detection Point) to be set as a trigger for accessing the SCP. If the detected call is a call that requires access to the SCP 2 (IN call), a BCSM in which a trigger is set in advance for the specific DP determined by the type of IN service is generated, and the call state is set to the specific DP. At the time of transition, a message corresponding to the type of trigger set in the DP is transmitted from the exchange to the SCP 2. The SCP 2 provides the special switching service described above for each call by executing a service program determined by the trigger type. In the case of a call that does not require access to the SCP 2 (general call), a BCSM that does not include any trigger for accessing the SCP is generated, and call processing is executed in a closed form in each switch.
[0027]
According to the first embodiment of the present invention, an Internet (IP) network 8 is connected to the IN transmission network via an access point 7 comprising, for example, a gateway device, and is connected to a WWW server 3 and a service control gateway device ( It is connected to the SCP 2 of the IN via the SCGW 1.
[0028]
FIG. 2 shows the configuration of the service control gateway device (SCGW) 1.
[0029]
The SCGW 1 is connected to the CPU 11 for controlling communication with the SCP 2 and the WWW server 3, the memory 12, the IP network interface unit 13 for terminating the signal line 14 connected to the WWW server, and the SCP. The high-performance network interface unit 15 for terminating the signal line 16 and a bus 17 for connecting these elements.
[0030]
The SCGW 1 is used for converting and relaying the message format of control messages related to the Internet call waiting service communicated between the WWW server 3 and the SCP 2. The SCGW 1 stores the above message format in the memory 12. An SCP address management table 400 shown in FIG. 3A and a user management table 410 shown in FIG. 3B are provided together with a program for performing conversion and relay and information necessary for user authentication.
[0031]
The SCP address management table 400 is referred to when determining a SCP to be accessed when a message is received from the Internet side (WWW server 3 in this embodiment). As shown in FIG. Corresponding to the network ID 402, an SCP address 403 and a service number 404 as a transmission destination of the received message are defined.
[0032]
In FIG. 1, only one SCP 2 is connected to SCGW 1, but in the SCP address management table 400 shown in FIG. 3A, assuming a communication network in which a plurality of SCPs are connected to SCGW 1, Internet call waiting The received message is transferred to a different SCP according to the network ID of the intelligent network in which the service requesting terminal device is accommodated. The service number 404 is information for designating a service program to be executed in the SCP 2 instead of the trigger information.
[0033]
As shown in FIG. 3B, the user management table 410 includes a plurality of entries (or records) generated for each user ID. Each entry corresponds to the user ID 411 and is associated with the Internet call waiting service. Between the telephone number 412 indicating the request source terminal, the correlation ID 413 used for determining the correspondence between the transmission message and the reception message in the communication between the SCP and the SCGW 1, and between the WWW server 3 and the SCGW 1 Correlation ID 414, WWW server address 415, service status code 416, and incoming call to be transmitted from the WWW server to the service requesting terminal. URL identification information 417 indicating the storage location of the notification display data I remember it.
[0034]
The WWW server 3 stores various service information provided on the Internet, and each user browses desired service information by communicating with the WWW server via a browser provided in the user terminal. In this embodiment, the WWW server 3 supports, for example, the request management table 430 shown in FIG. 4A, the service management table 440 shown in FIG. 4B, and the service management table 440 shown in FIG. 4C in order to support the Internet call waiting service. A user status management table 450.
[0035]
As shown in FIG. 4A, the request management table 430 defines a service program number 432 to be executed corresponding to the type (or request type) 431 of the message received from the terminal 6 and the SCGW 1. When the WWW server receives control messages for the Internet call waiting (ICW) service such as an IN service request message, an incoming call notification message, and a notification response message, which will be described later, the WWW server executes a service program corresponding to these messages. .
[0036]
As shown in FIG. 4B, the service management table 440 corresponds to the service program number (432) 441 for the ICW service indicated by the request management table 430, and corresponds to the SCGW address 442, the network ID 443, the service number 444, A URL 445 indicating the storage location of incoming notification display data is defined.
[0037]
As shown in FIG. 4C, the user status management table 450 corresponds to the user ID 451 in order to determine the correspondence between the service status code 452 and the transmission message and the reception message in the communication between the WWW3 and the SCGW1. The correlation ID 453 used is defined. The correlation ID 453 to be used in WWW3 is specified by SCGW1.
[0038]
5A to 5C show an example of a table provided in the SCP 2 for performing the ICW service.
[0039]
FIG. 5A shows the service determination table 460.
[0040]
The service determination table 460 includes trigger information 461 indicated by “IN service request issued by the exchange at a predetermined detection point (DP) of basic call”, number information 462 indicating a part of a dialed number, and a public network specific information. Corresponding to the combination with the service key 463 assigned to the subscriber (plurality), it consists of a plurality of entries defining the program number 465 of the service control program to be executed. Here, the service control program having the program number “500” indicated by the entry 460-2 has the user information management table 480 shown in FIG. 5C based on the pointer address table 470 shown in FIG. It is assumed that the service control program has a function of referring to the user information stored in.
[0041]
Unlike the IN service request issued by the exchange, the IN service request message for ICW service given from SCGW 1 to SCP 2 does not include trigger information. Therefore, in the present invention, in order to support the ICW service by the SCP, the service number 464 is applied as information replacing the “combination of the trigger information 461, the number information 462, and the service key 463”. In the service determination table 460, the program number of the service control program for the ICW service (in this example, “600”) is defined in association with the service number 464.
[0042]
FIG. 5B shows a user information pointer address table 470 referred to by the SCP service control program.
[0043]
The user information pointer address table 470 stores a pointer address 473 that points to one entry of the user information management table 480 shown in FIG. 5C corresponding to the combination of the program number 471 and the telephone number (dial number) 472. . In the present invention, for example, as indicated by the entries 470-1 and 470-3, the telephone number “0423231111” that is eligible for the ICW service can be accessed even if accessed from the service control program of the number “500”. Table entries are prepared so that the same pointer address “xx” can be obtained even when accessed from the service control program “600”.
[0044]
FIG. 5C shows the user information management table 480.
[0045]
Each entry of the user information management table 480 corresponds to the pointer address (473) 481 indicated by the user information pointer address table 470, the user ID 482, the telephone number (DN) 483, and whether the user is accessing the Internet. An IP access flag 484 indicating the control message, an SCGW address 485 that is the destination of the control message, and a correlation ID 486 used to determine the correspondence between the transmission message and the reception message in the communication between the SCP and the SCGW. I remember it. The correlation ID 486 to be used in the SCP is specified by the SCGW.
[0046]
In this embodiment, when an ICW service request is received from a user terminal connected to the Internet, this service request (IN service request message) is transmitted to the SCP 2 via the WWW server 3 and the SCGW 1 and the service control program “600” is transmitted. Thus, the IP access flag 484 of the user information management table 480 stores that the user terminal is in IP access. When an incoming call is received at the user terminal, the SCP 2 refers to the user information management table 480 by the service control program “500”. If the incoming terminal is in IP access, the SCP 2 passes through the SCGW 1 and the WWW server 3. Then, the user terminal is notified of the incoming call with an IP packet. If the receiving terminal is not in IP access, the IN service request source exchange notifies the user terminal of the incoming call.
[0047]
FIG. 6 shows a format of an IP packet 500 communicated for the ICW service between the terminal 6 and the WWW server 3.
[0048]
The IP packet 500 includes an IP header 510, a TCP / UDP header 520, and a user data field 530, and a control message for ICW service is set in the user data field 530.
[0049]
The “IN service request message” 203 transmitted from the terminal 6 to the WWW server 3 includes a message type 531, a message length 532, a telephone number 533 of the request source terminal, and a user ID 534. The “notification response message” 262 sent from the terminal 6 to the WWW server 3 in response to the incoming call notification from the SCP 2 includes the handling of incoming calls as indicated by broken lines in addition to the above items 531-534. An action code 535 for specifying a method (continuation method) is included. When the action code indicates “transfer incoming call”, the action code 535 is followed by “phone number to be transferred” 356.
[0050]
For the communication between the SCGW 1 and the WWW server 3, for example, a message format studied by an IETF (Internet Engineering Task Force) PINT (PSTN and Internet Internetworking) working group can be applied. Further, for example, an IN message format can be applied to the communication between the SCGW 1 and the SCP2.
[0051]
FIG. 7 shows a format of a packet 501 applied to communication between the SCGW 1 and the WWW server 3.
[0052]
The packet 501 includes an IP header 510, a TCP / UDP header 520, a TCAP (Transaction Capability Application Part) header 525, and a user data field 540. In the user data field 540, the messages shown in FIGS. 8A to 8C are displayed. Is set.
[0053]
FIG. 8A shows a format of the IN service request message 205 transferred from the WWW server 3 to the SCGW 1.
[0054]
The IN service request message 205 is generated based on the IN service request message 203 received from the terminal. The message “message type 551, message length 552, SCGW address 553, WWW server address 554, and service number 555”. And a telephone number (dial number) 556, a network ID 557, a user ID 558, and a URL 559 ".
[0055]
In the message type field 551, a code indicating that this message is an IN service request message is set. Further, the telephone number field 556 and the user ID field 558 are respectively set with the telephone number 533 and the user ID 534 indicated by the IN service request message 203 received from the terminal, and the fields 553, 555, 557 and 559 are set in the user management table. Data obtained from 440 is set, and the address of the server 3 is set in the WWW server address field 554.
[0056]
FIG. 8B shows a format of an “incoming call notification message” 237 generated by SCGW 1 based on the incoming call notification message 235 described in FIG. 10B received from SCP 2 and transmitted to the WWW server 3.
[0057]
The incoming call notification message 237 is “message type 551 indicating that this message is an incoming call notification, message length 552, SCGW address 553, WWW server address 554, user ID 558, URL 559, and correlation ID 561. It consists of a plurality of fields indicating "and". The correlation ID 561 is used to determine the correspondence between the notification response message 264 and the incoming call notification message 237 that are subsequently received from the WWW server. The correlation ID 561 includes the correlation ID 561 from the user management table 410 shown in FIG. 3B. The value of the obtained correlation ID 414 is applied.
[0058]
FIG. 8C shows a format of a “notification response message” 264 generated by the WWW server 3 based on the notification response message 262 received from the terminal and transmitted to the SCGW 1.
[0059]
The message 264 is “a message type 551 indicating that this message is a notification response, a message length 552, an SCGW address 553, a WWW server address 554, a correlation ID 571, an action code 572, and a forwarding telephone number. It consists of a plurality of fields indicating "573". The correlation ID 571 has the same value as the correlation ID 561 specified by the incoming call notification message 237 shown in FIG. 8B.
[0060]
FIG. 9 shows a format of a packet 800 applied to communication between SCGW1 and SCP2.
[0061]
The packet 800 includes an arrival code 801, an origination code 802, a link selection 803, a SCCP (Signaling Connection Control Part) header 804, a TCAP (Transaction Capabilities Application Part) header 805, and a user data field 810. Thus, the messages shown in FIGS. 10A to 10C are set in the user data field 810.
[0062]
The link selection 803 is set with information for designating the working link among the duplex links consisting of the working system and the standby system.
[0063]
FIG. 10A shows a format of an “IN service request message” 216 transmitted from the SCGW 1 to the SCP 2.
[0064]
The IN service request message 216 is generated by the SCGW 1 based on the IN service request message 205 shown in FIG. 8A received from the WWW server. The message “message type 821, message length 822, correlation ID 823, transmission source” SCGW address 824, destination SCP address 825, service number 826, telephone number (dial number) 827, and user ID 828 ”.
[0065]
In the field 821 indicating the message type, a code indicating that this message is an IN service request message is set. Further, the data retrieved from the SCP address management table 400 is set in the destination SCP address 825 and the service number 826, and the value of the correlation ID 413 in the user management table 410 is set in the correlation ID 823. In the transmission source SCGW address 824, the address of SCGW1 is set, and in other items 827-828, data obtained from the IN service request message 205 received from the WWW server is set. In the packet 800 including the IN service request message 216 in the user data field 810, the SCP2 address is set in the incoming code 801 and the SCGW1 address is set in the outgoing code 802.
[0066]
When the SCP2 receives the IN service request message 216, the service program “600” sets the IP access flag 484 of the corresponding entry in the user management table 480 to “1”, and sets the SCGW address 485 and the correlation ID 486 to the IN The SCGW address 824 and the correlation ID 823 indicated by the service request message 216 are set.
[0067]
FIG. 10B shows the format of an “incoming call notification message” 235 generated by the SCP 2 that has received “IN service request indicating incoming call to an IN service subscriber” from the exchange and transmitted to the SCGW 1.
[0068]
The incoming call notification message 235 includes a message type 821 indicating that this message is an incoming call notification, a message length 822, a correlation ID 823, a destination SCGW address 831, a source SCP address 832, and an incoming call. The phone number 827 and the user ID 833 ”are each composed of a plurality of fields. In the correlation ID 823, a value indicated by the correlation ID 486 of the user management table 480 is set.
[0069]
FIG. 10C shows a format of a “notification response message” 265 that is generated by the SCGW 1 based on the notification response message 264 received from the WWW server 3 and transmitted to the SCP 2.
[0070]
The message 265 includes “a message type 821 indicating that this message is a notification response, a message length 822, a correlation ID 823, a source SCGW address 824, a destination SCP address 825, an action code 841, and a transfer destination. It consists of a plurality of fields each indicating a telephone number 842 and ".
[0071]
In the correlation ID 823, a value indicated by the correlation ID 413 of the user management table 410 is set, and this value is the same as the correlation ID 823 of the incoming call notification message 235.
[0072]
Next, the control procedure of the Internet Call Waiting service in the communication network shown in FIG. 1 will be described according to the signal sequence shown in FIGS.
[0073]
FIG. 11 shows that the user of the terminal 6b subscribing to the ICW service is accessing the Internet (WWW server 3) via the exchanges 4a and 4b and the access point (for example, gateway device) 7 (200). 4 shows the “operation and message sequence of WWW server 3, SCGW 1 and SCP 2” executed when an input operation of “IN service request” (202) for receiving an incoming call notification is performed.
[0074]
In the terminal 6b, a browser for communicating with the WWW server is operating. When requesting the IN service, for example, the user inputs the telephone number (DN) of the terminal 6b and the user ID on the browser screen, and then clicks the IN service request button (202). As a result, an IN service request message 203 including the telephone number (DN) 533 and the user ID 534 shown in FIG. 6 is generated, and the IN service request message 203 is included in the user data field 530 and “destination address (SA) 511” An IP packet having an IP header 510 including the address of the terminal 6 b as the WWW server address and the source address (DA) 512 is transmitted to the WWW server 3.
[0075]
When the WWW server 3 that has received the IN service request message 203 detects that an “IN service request has been received” from the message type 531 of the received message (204), the “reception message message” defined in the request management table 430 is displayed. The service program corresponding to “message type 531” is executed. As a result, a new entry with the user ID 534 extracted from the received message 203 as the search key 451 is added to the user status management table 450. The status field 452 of the entry is set with a status code indicating that an IN service request is being made. In addition, “SCGW address 442, service providing network identifier 443, service number 444, URL 445” as the destination of the IN service request retrieved from the service management table 440 and “telephone number (DN) extracted from the received message 203” 533, user ID 534 ", the IN service request message 205 shown in FIG. 8A is generated. The IN service request message 205 is transmitted to the SCGW 1 as the IP packet shown in FIG. 7 including the address of the SCGW 1 in the destination address field 511 of the IP header 510.
[0076]
The SCGW 1 that has received the IN service request message 205 performs user authentication processing and protocol conversion in accordance with the IP packet processing routine 140 shown in FIG. 14 (215), and generates the IN service request message 216 shown in FIG. 10A. , Transmitted to SCP2.
[0077]
That is, as shown in FIG. 14, when the SCGW 1 receives an IP packet transmitted from the WWW server from the IP network interface 13 (step 141), the user ID 558 included in the received message is stored in the memory 12 in advance. It is checked against the user ID list of the service subscriber to determine whether the user ID 558 has already been registered as an IN service subscriber (step 142). If the user ID 558 is not a registered IN service subscriber, an error message is transmitted to the WWW server 3 (step 152).
[0078]
If the user ID 558 is a registered IN service subscriber, it is checked whether the received message contains a correlation ID (step 143). If the received message does not contain a correlation ID, it is extracted from the received message. Based on the message type 551 and the network ID 557, the SCP address management table 400 shown in FIG. 3A is referred to determine the SCP address 403 and service number 404 that are the destination of the IN service request, and the SCP and SCGW. After assigning the correlation ID 413 used in the communication between and the correlation ID 414 used in the communication between the WWW and the SCGW (step 144), “the received message 205 is converted into the packet 800 including the IN service request message 216” Perform protocol conversion (step 146). If the received message includes a correlation ID, the correlation ID 413 and other necessary data are read from the user management table 410 (step 145), and these data are applied to perform protocol conversion (step 146).
[0079]
Next, in the user management table 410, the status code 416 of the entry corresponding to the user ID is updated. If there is no entry corresponding to the user ID in the user management table 410, a new entry is added (step 147). Next, the packet generated in step 146 is transmitted to SCP2 (148), and a response from SCP2 is awaited (step 149). When the response (ACK) 218 is received from the SCP 2 (step 150), the response 219 is transmitted to the WWW server 3 (step 151), and the reception of the next IP packet is awaited.
[0080]
The SCP 2 that has received the IN service request message 216 from the SCGW 1 refers to the service determination table 460 based on the service number 826 extracted from the received packet, and starts the service control program “600” to be executed. As a result, a pointer address 473 (eg, address “xx”) corresponding to the telephone number 827 included in the received message 216 is searched from the user information pointer address table 470, and the entry pointed to by the pointer address in the user information management table 480 is retrieved. , The IP access flag 484 indicating that the user is accessing the Internet, the SCGW address 485 obtained from the received message 216, and the value of the correlation ID 486 are stored. Thereafter, the SCP 2 transmits a response (ACK) 218 to the IN service request 216 to the SCGW 1.
[0081]
As a result of the transfer of the IN service request message from the IP network to the IN network described above, “whether or not the specific user (user ID or telephone number) subscribed to the ICW service is currently accessing the IP network (WWW server). Can be determined by the IP access flag 484 of the user management table 480. Therefore, when notified from the exchange 4a that there is an incoming call to the specific telephone number, the SCP 2 refers to the user management table 480 by the service control program “500”, for example, and the IP associated with the specific telephone number. From the state of the access flag 484, if the terminal 6b is accessing the IP network, it is possible to notify the user of the incoming call via the SCGW 1 and the WWW server 3, and otherwise, via the exchange 4a. .
[0082]
FIG. 12 shows a message sequence when the terminal 6b accessing the WWW server 3 receives an incoming call from another terminal (telephone) 6a.
[0083]
When the exchange 4a receives the call request (Setup) 231 from the terminal 6a and detects that the user corresponding to the called number is subscribed to the IN service, the switch 4a sends an IN service request (Initial DP) message to the SCP2. 232 is transmitted. In addition, the call request acceptance notification (Call proc) 233 is transmitted to the terminal 6a.
[0084]
The SCP 2 that has received the IN service request message 232 determines the service control program to be executed (for example, the service control of the program number “500”) from the service determination table 460 based on the trigger information and the called number included in the received message 232. Program) is determined (step 234). When a user information acquisition routine, which is one of the function routines constituting the service control program, is executed, a pointer address (for example, "" is read from the user information pointer address table 470 based on the program number 471 and the called number. xx ″) is retrieved, and control information 482-486 for the ICW service corresponding to the called number is acquired from the user information management table 480 according to the pointer address.
[0085]
If it is determined from the state of the IP access flag 484 that is a part of the control information that the called user is accessing the Internet (WWW server), the service control program “500” receives the incoming call shown in FIG. 10B. After the notification message 235 is generated and the packet 800 including the message is transmitted to the SCGW 1, the reception response (ACK) from the SCGW 1 is waited for. If the called user is not accessing the Internet, the SCP 2 instructs the exchange 4a that is the transmission source of the IN service request (Initial DP) message 232 to notify the incoming call.
[0086]
When the reception response (ACK) from the SCGW 1 is received, the service control program “500” enters a reception waiting state for a notification response message that is a user response to the incoming notification message 235.
[0087]
Upon receiving the incoming call notification message 235, the SCGW 1 executes an IN packet processing routine 160 shown in FIG. 15 (236).
[0088]
In the IN packet processing routine 160, when a message is received from the SCP (step 161), the correlation ID 823 included in the received message 235 is checked (step 162), and the correlation ID corresponds to the user ID 833 included in the received message 235. If the correlation ID 413 stored in the user management table 410 does not match, an error response is transmitted to the SCP (step 170). If a match between the correlation ID 823 and the correlation ID 413 is confirmed, the correlation ID 414, the WWW server address 415, and the URL 417 are read from the user management table 410 (step 163), and the IP packet including the incoming notification message 237 shown in FIG. 501 is generated (step 164), a code indicating that the incoming call is being notified is set in the status field 416 of the entry corresponding to the called user in the user management table 410 (step 165), and then the called user accesses this. It transmits to the WWW server 3 (step 166).
[0089]
The SCGW 1 waits for a response (ACK) from the WWW server 3 (step 167). When receiving the response (ACK) 238 from the WWW server 3 (step 168), the SCGW 1 sends a response (ACK) 239 to the incoming call notification message 235 in the SCP2. Is transmitted (step 169), and the next IN packet is awaiting reception.
[0090]
The WWW server 3 that has received the incoming call notification message 237 transmits a response signal (ACK) 238 to the incoming call notification to the SCGW 1 and then sets the correlation ID 561 indicated by the incoming call notification message 237 to the user state management table corresponding to the user ID 558. Stored in the correlation ID field 453 of the entry, a status code indicating that there is an incoming call notification is set in the status field 452 of the entry. Further, the WWW server 3 reads the incoming notification display data from the memory based on the URL 559 specified by the incoming notification message 237, and transmits it as an incoming notification message 241 to the browser operating on the user terminal 6b ( 240).
[0091]
When the user receives an incoming call while accessing the WWW server by the SCP operation and message transfer described above, the incoming call notification issued from the SCP is sent to the browser screen of the user terminal via the SCGW 1 and the WWW server 3. Can be displayed.
[0092]
FIG. 13 shows a message sequence when a user who receives an incoming call notification inputs a notification response that specifies how to handle an incoming call.
[0093]
The user of the terminal 6b that received the incoming call notification via the browser, as a method of handling the incoming call, (a) announces to the calling user that the called user is busy, (b) sends the incoming call to the mailbox Select from the menu such as (c) connect to the specified transfer destination telephone number, (d) disconnect the call, etc. Here, an operation when the user selects a transfer menu and inputs a transfer destination telephone number as a response input (261) to the incoming call notification will be described.
[0094]
When the user selects the transfer menu and inputs the transfer destination telephone number, the IP packet 500 including the “notification response message 262 including the action code 535 and the transfer destination telephone number 536” shown in FIG. It is transmitted to the WWW server 3. When the notification response message 262 is received, the WWW server 3 executes the “service program corresponding to the message type 531 of the received message” defined in the request management table 430 (263). As a result, the address information read from the service management table 440 and the “correlation ID 453 corresponding to the user ID 534 of the received message” read from the user state management table 450 are applied, and the notification response shown in FIG. 8C is applied. A message 264 is generated and transmitted to the SCGW 1 as an IP packet 501.
[0095]
The SCGW 1 that has received the notification response message 264 executes the IP packet processing routine shown in FIG. 14, and receives the SCP address 403 obtained from the SCP address management table 400 and the IN service request message 205 when receiving the user management table 410. The notification ID message 265 shown in FIG. 10C is generated by applying the correlation ID 413, the action code 572 and the transfer destination telephone number 573 indicated by the received packet 264, and this is sent to the SCP 2 as the packet 800.
[0096]
When the notification response message 265 is received by SCP2, the correlation ID 823 of the reception message 265 and the correlation ID 486 of the user information management table 480 are collated by the service control program “500” waiting to receive the notification response message. Then, the received message is authenticated. When the transfer destination telephone number 842 is specified from the received message, a service control program for transfer processing is executed, whereby the Connect message 269 including the transfer destination telephone number is transmitted to the exchange 4a. In addition, a reception response (ACK) 267 to the notification response message 265 is transmitted to the SCGW 1 (266).
[0097]
Upon receiving the Connect message 269, the exchange 4a executes call connection processing (270) for connecting a call received at the terminal 6b to the telephone number 842 specified by the received message, and sends a Setup signal 271 to the transfer destination terminal. Send. On the other hand, the SCGW 1 that has received the reception response (ACK) 267 from the SCP transmits a reception response (ACK) 268 to the WWW server 3.
[0098]
FIG. 16 shows an IN service request routine that constitutes a part of the browser function that operates on the subscriber terminal. The IN service request routine is executed when the user starts a browser on the subscriber terminal 6b and selects the IN service menu.
[0099]
When the user performs an input operation for designating the WWW server 3 that relays the IN service, the IN service request routine requests the WWW server to transmit screen display information (step 602) and waits for a response from the WWW server ( 603). When a packet including screen display information is received from the WWW browser, the received information is analyzed (605), and the display information is output to the display screen of the user terminal (606). This provides the user with an input screen for IN service request.
[0100]
When the user inputs the telephone number (DN) and user ID of the terminal on the input screen (607) and clicks a send button prepared on the display screen, the IP packet including the IN service request message 203 shown in FIG. Is generated and transmitted to the WWW server (608). Waiting for a response from the WWW server (609), and receiving a response signal indicating that the WWW server has correctly accepted the transmission message from the terminal (610), as the user information, the telephone number (DN), the user ID, The status code indicating that the IN service is being requested is stored (611), and this routine is terminated. If an error response is received from the WWW server 3 in step 604 or 610, the fact that an error has occurred is displayed on the terminal screen (613), and the apparatus waits for input from the user.
[0101]
FIG. 17 shows the function of the IN service notification routine that constitutes a part of the browser function that operates on the subscriber terminal. This routine is activated when the WWW server 3 that has received the incoming notification 237 from the SCGW 1 transmits the incoming notification message 241 to the browser operating on the terminal 6b.
[0102]
The IN service notification routine receives the incoming notification message 241 transmitted from the WWW server (step 622), and analyzes the received message information (623). Next, the incoming notification display data included in the received message is displayed on the terminal screen (624), and the status code is updated to a code indicating reception of incoming notification (625). For example, (a) announcement, (b) connection to a mailbox, (c) transfer, (d) disconnection as a method of handling an incoming call that can be specified by the user on the display screen of the terminal based on the incoming notification display data. A menu is provided for selecting one of these.
[0103]
If the user selects one of the menus displayed on the screen and selects transfer, when the user further inputs the transfer destination telephone number and clicks the send button (626), the action A notification response message 262 including the code 535 and the transfer destination telephone number 536 is generated and transmitted to the WWW server 3 (627). Thereafter, the IN service notification routine waits for a response from the WWW server (628), and upon receiving a response (ACK) indicating that the WWW server has correctly received the notification response message 262 (629), terminates this routine. Then, a new message waiting state from the WWW server is entered.
[0104]
By executing the above-described IN service request routine and IN service notification routine, the terminal user can input an IN service request, receive an incoming notification, and specify an incoming call handling method on the browser screen. .
[0105]
FIG. 18 shows a flowchart of an IN service end routine executed by the WWW server 3 when there is a request to cancel the IN service from the terminal 6b. The IN service cancellation request message, like the IN service request message 203, includes a telephone number and a user ID. For example, the IN service end button prepared on the browser screen or the Internet access end button is selected. In response, it is sent to the WWW server 3.
[0106]
The IN service termination routine receives the IN service cancellation request message from the terminal 6b (902), analyzes the received message (903), and deletes the entry corresponding to the user ID of the received message in the user status management table 450; Alternatively, the status field 452 of the entry is changed to the IN service canceled status (904). Next, an IN service cancellation request message is transmitted to the SCGW 1 (905), and a response from the SCGW is awaited (906).
[0107]
When the SCGW 1 receives the cancellation request message, the SCGW 1 deletes the entry corresponding to the user ID of the message in the user management table 410 or changes the status field 416 of the entry to the IN service cancellation status, and then An IN service cancellation request message is transmitted. Receiving the IN service cancellation request message, the SCP 2 clears the IP access flag 484 corresponding to the user ID in the user information management table 480, and then transmits a cancellation confirmation response signal to the SCGW. The confirmation response signal is transferred from the SCGW 1 to the WWW server 3. When the WWW server 3 receives the confirmation response signal from the SCGW 1 (907), the WWW server 3 transmits a cancellation confirmation signal to the browser operating on the terminal 6b (908), and ends this routine.
[0108]
FIG. 19 shows a network configuration of the second embodiment of the present invention.
[0109]
Compared with FIG. 1, the network configuration of FIG. 19 is “a gateway that connects the intelligent network SCP and the IP network via the service control gateway device (SCGW) 1 and connects the intelligent network transmission network and the IP network. The device 7 has a communication function with the SCGW 1 ”. The SCGW 1 is connected to the IP network via a router (not shown), for example. However, the SCGW 1 may be connected to an IP network interface provided in the gateway device 7.
[0110]
In the present embodiment, the SCGW 1 only has to change the communication partner on the IP network side in the IP packet processing routine shown in FIG. 14 and the IN packet processing routine shown in FIG. 15 from the WWW server 3 to the gateway device 7. In addition, the configuration is the same as that of the first embodiment.
[0111]
The gateway device 7 is performed by the WWW server 3 in the first embodiment, the function necessary for connecting the subscriber terminal 6 to the IP network by dial-up connection, the communication function for communicating with the terminal 6 by the Internet protocol, and And a function for communicating an IN service control message with the SCGW 1.
[0112]
In order to realize these functions, the gateway device 7 manages authentication for each subscriber, additional service information for each subscriber, and management for the Internet call waiting service described with reference to FIGS. 4A to 4C. Tables 430 to 450 and a plurality of programs for performing control operations using these pieces of information are stored.
[0113]
In the first embodiment, when a user performs an IN service request input operation during Internet access, an IN service request message is transmitted from the terminal 6 to the IP network. In this second embodiment, When a connection for IP communication is established between the terminal and the gateway device 7, the gateway device 7 automatically generates an IN service request message and transmits the message to the SCGW 1. As the gateway device 7 suitable for providing the above-described IN service message processing function, specifically, there is an access point operated and managed by a service provider.
[0114]
The subscriber terminal 6b transmits and receives an IN service control message to and from the gateway device 7 instead of the WWW server of the first embodiment during the dial-up connection function and the Internet connection, as shown in FIG. A program similar to the described IN service notification routine is provided.
[0115]
FIG. 20 shows the configuration of the gateway device 7.
[0116]
The gateway device 7 terminates a CPU 71 for controlling communication with the terminal 6 and the SCGW 1, a memory 72 for storing the various information and programs described above, and a signal line 74 connected to the IP network. An IP network interface unit 73, a transmission network interface unit 75 for terminating a signal line 76 connected to the transmission network of the intelligent network, and a bus 77 for connecting these elements. The communication between the CPU 71 and the SCGW 1 is performed according to the Internet protocol using the packet shown in FIG. 7, and the communication between the CPU 71 and the transmission network is, for example, according to the N-ISDN user / network interface protocol. Done.
[0117]
With reference to FIGS. 21 to 23, a control procedure method of the Internet Call Waiting service in the communication network of the second embodiment will be described.
[0118]
In FIG. 21, when the user of the terminal 6b uses the dial-up function to connect to the IP network 8, when the call signal (Setup) 101A is transmitted to the gateway device 7, the terminal 6b is connected. The exchange 4a transfers the call signal (Setup) 101A as the call signal (Setup) 101B to the gateway device 7 and returns a call acceptance signal (Call Proc) 102 to the terminal 6b.
[0119]
In response to the call signal (Setup) 101, the gateway device 7 executes a call signal processing routine shown in FIG.
[0120]
That is, when the call signal (Setup) 101 is received from the transmission network interface 75 (Step 741), the information element included in the received signal is analyzed to determine whether or not the incoming call can be accepted (Step 742). When the incoming call is accepted, a response signal (Connect) 104 is transmitted from the gateway device 7 to the exchange 4a (step 743). The exchange 4a that has received the response signal transmits a response signal (Connect) 105 to the terminal 6b, whereby the gateway device 7 and the terminal 6b are connected via a telephone line.
[0121]
Thereafter, the gateway device 7 starts a PPP (Point to Point) connection operation in order to perform IP packet communication with the terminal 6b through the telephone line. First, the link 106 is established between the terminal 6b and the gateway device 7 by applying, for example, LCP (Link Control Protocol). Next, an authentication request including the user ID and password is received from the terminal 6b (step 745), and the user ID and password authentication process 108 is performed using the authentication information stored in the memory 72 (step 746). If the user ID and password are authenticated, an authentication response 109 is transmitted to the terminal 6b (step 747). The authentication process may be executed by a user authentication server (not shown) connected to the gateway device 7.
[0122]
When the gateway device 7 receives the IP address assignment request 110 from the terminal 6b (step 748), the gateway device 7 acquires one free IP address from the IP address pool formed in the memory 72, and the free IP address and the user ID are obtained. After storing the correspondence in the user information table (step 749), the IP address 112 is notified to the terminal 6b (step 750).
[0123]
Next, the gateway device 7 searches the IN service information table for each user stored in advance in the memory 72 (step 751), and when it is determined that the user of the terminal 6b is a subscriber user of the IN service, FIG. The IN service request message 205 shown in FIG. 6 is generated and transmitted to the SCGW 1 (step 752), and then a reception response (ACK) 219 from the SCGW 1 is awaited. When the response (ACK) 219 from the SCGW 1 is received (step 754), the state 199 during PPP connection is established.
[0124]
As a result of analyzing the information element of the call signal in step 742, if the incoming call cannot be made, if user authentication fails in step 746, or if there is no free IP address in the IP address pool in step 749, the terminal 6b An error message is transmitted to (step 756).
[0125]
Upon receiving the IN service request message 205, the SCGW 1 executes the IP packet processing routine shown in FIG. 14 as in the first embodiment, confirms the validity of the user by the user authentication process, and then converts the protocol converted IN A service request message 216 is transmitted to SCP2. When receiving the reception response (ACK) 218 from the SCP 2, the SCGW 1 transmits the reception response (ACK) 219 to the gateway device 7 that is the transmission source of the IN service request message 205, and then the IP packet processing routine. Exit. When receiving the IN service request message 216, the SCP 2 executes a service request registration process 217 similar to that of the first embodiment.
[0126]
FIG. 22 shows a message sequence when an incoming call is received from the other terminal 6a to the terminal 6b connected to the gateway apparatus 7 and PPP.
[0127]
As is clear from the comparison with the first embodiment shown in FIG. 12, in the second embodiment, the gateway device 7 receives the incoming notification message 237 transmitted from the SCGW 1, and the gateway device 7 receives the first notification message 237. Instead of the WWW server 3 of the embodiment, the incoming notification message 241 is transferred to the terminal 6b and the reception response (ACK) 242 is transmitted to the SCGW 1 according to the program shown in FIG.
[0128]
That is, when the gateway device 7 receives the incoming notification message 237 from the SCGW 1 (step 761), the gateway device 7 starts a service program corresponding to the message type 551 of the received message, and in step 111 in FIG. 21 (step 749 in FIG. 24). An IP address corresponding to the user ID 558 indicated by the received message is read from the stored “user information table indicating the correspondence between the IP address and the user ID” (step 762). Next, an incoming notification processing routine is started to generate an incoming notification IP packet with the IP address as the destination address (step 763), and an incoming notification message is transmitted to the terminal 6b (step 764). Then, a response (ACK) 242 to the incoming notification 237 is transmitted (step 765).
[0129]
FIG. 23 shows a message sequence when the user who has received the incoming call notification inputs a notification response that specifies how to handle incoming calls.
[0130]
As is clear from the comparison with the first embodiment shown in FIG. 13, in the second embodiment, the gateway device 7 receives the notification response message 262 transmitted from the terminal 6b, and the gateway device 7 receives the first response. Instead of the example WWW server 3, the notification response message 264 is transferred to the SCGW 1 according to the program routine shown in FIG.
[0131]
When the user of the terminal 6b receiving the incoming call notification selects the handling of the incoming call desired by the user from the menu displayed on the terminal screen, for example, “Forward” and designates the destination telephone number (261) ), The notification response message 262 having the format shown in FIG. 6 is transmitted from the terminal 6b to the gateway device 7. When the message received from the terminal is a notification response, the gateway device 7 executes the notification response processing routine of FIG.
[0132]
In the notification response processing routine, when the notification response message 262 is received (step 771), the SCGW address and the correlation ID are read from the service management table 440 and the user state management table 450, respectively, and the notification response message 264 shown in FIG. 8C is generated. Then, after updating the status field 452 of the user status management table 450 to a code indicating the notification response status (step 773), the notification response message 264 is transmitted to the SCGW 1 (step 774). Thereafter, the control waits for a reception response (ACK) 268 from the SCGW 1 (step 775). When a reception response (ACK) 268 from the SCGW 1 is received (step 776), this routine ends. The operation of the SCGW 1 that has received the notification response message 264 and the operation of the SCP 2 that has received the notification response message 265 from the SCGW 1 are the same as in the first embodiment.
[0133]
FIG. 27 shows a flowchart of an IN service end routine executed by the gateway device when the connection between the terminal 6b and the gateway device 7 is disconnected.
[0134]
In the IN service end routine, when a disconnection signal is received from the exchange 4 (step 782), the received signal is analyzed (step 783), the correlation ID 453 is read from the user state management table 450 (step 784), and an IN service cancellation request is sent to SCGW1. A message is transmitted (step 785) and a response from SCGW1 is awaited (step 786). When a response signal is received from the SCGW 1 (step 787), the IP address assigned to the PPP communication and the correlation ID 453 used for communication between the gateway device 7 and the SCGW 1 are released and the status information 452 is cleared. (Step 788), a release signal is transmitted to the exchange 4 (Step 789), and this routine is terminated.
[0135]
The SCGW 1 that has received the IN service cancellation request message from the gateway device 7 deletes the entry corresponding to the terminal user or the status code in the user management table 410 as described with reference to FIG. 18 in the first embodiment. The change is made and the IN service cancellation request message is transferred to SCP2. Also, when the SCP 2 receives the IN service cancellation request message, the SCP 2 clears the IP access flag corresponding to the terminal user in the user information management table. Therefore, the incoming call notification service to the user via the IP network by the SCP ends when the user disconnects from the Internet.
[0136]
【The invention's effect】
As is clear from the description of the above embodiments, according to the present invention, an incoming call notification message is sent from the intelligent network service control device (SCP) to the user using the Internet via the Internet. be able to. In addition, by transferring the notification response from the user to the SCP via the Internet, a connection command such as “transfer of the incoming call to the user-designated terminal, announcement to the calling user, disconnection of the incoming call” from the SCP to the exchange Can be given.
[0137]
Therefore, a flexible communication service can be provided to the user.
[Brief description of the drawings]
1 is a diagram showing a “network configuration in which an SCP of an intelligent network and a WWW server 3 of an IP network are connected via a service control gateway device 1” according to a first embodiment of the present invention;
FIG. 2 is a diagram showing a configuration of a service control gateway apparatus (SCGW) 1 in FIG.
FIG. 3A is a diagram showing a configuration of an SCP address management table provided in SCGW 1; FIG. 3B is a diagram showing a configuration of a user management table provided in SCGW 1.
4A is a diagram showing a configuration of a request management table provided in the WWW server 3 in FIG. 1. FIG. FIG. 4B is a diagram showing a configuration of a service management table provided in the WWW server 3. FIG. 4C is a diagram showing a configuration of a user state management table provided in the WWW server 3.
5A is a diagram showing a configuration of a service determination table provided in SCP 2 in FIG. 1. FIG. FIG. 5B is a diagram showing a configuration of a user information pointer address table provided in SCP2. FIG. 5C is a diagram showing a configuration of a user information management table provided in SCP2.
6 is a diagram showing an example of a packet format used in communication between the terminal device 6 and the WWW server 3 in FIG.
7 is a diagram showing an example of a packet format used in communication between the WWW server 3 and the service control gateway (SCGW) 1 in FIG. 1;
FIG. 8A is a diagram showing a format of a service request message transmitted from the WWW server 3 to the SCGW 1; FIG. 8B is a diagram showing a format of an incoming call notification message transmitted from SCGW 1 to WWW server 3. FIG. 8C is a diagram showing a format of a notification response message transmitted from the WWW server 3 to the SCGW 1.
9 is a diagram showing an example of a packet format used in communication between SCGW 1 and service control point (SCP) 2 in FIG.
FIG. 10A is a diagram showing a format of a service request message transmitted from SCGW1 to SCP2. FIG. 10B is a diagram showing a format of an incoming call notification message transmitted from SCP2 to SCGW1. FIG. 10C is a diagram showing a format of a notification response message transmitted from SCGW1 to SCP2.
11 is a signal sequence diagram showing a control signal and a message communicated in the communication network shown in FIG. 1 when a service request message “requesting an incoming call notification” is issued from the terminal device.
12 is a signal sequence diagram showing a control signal and a message communicated in the communication network shown in FIG. 1 when an incoming call is received by the terminal device.
13 is a signal sequence diagram showing a control signal and a message communicated in the communication network shown in FIG. 1 when a notification response message is issued from the terminal device.
FIG. 14 is a flowchart showing an operation of SCGW 1 executed in response to reception of a control message from the IP network.
FIG. 15 is a flowchart showing the operation of the SCGW 1 executed in response to receiving a control message from the IN network.
FIG. 16 is a flowchart showing browser operation executed in the terminal device 6 when a user requests an incoming call notification service;
FIG. 17 is a flowchart showing browser operations executed in the terminal device 6 when an incoming call notification is received from a WWW server.
FIG. 18 is a flowchart showing the operation of the WWW server executed when a call is disconnected.
FIG. 19 is a diagram showing a “network configuration in which an IP network and an SCP of an intelligent network are connected via a gateway device 7 and a service control gateway device 1” according to a second embodiment of the present invention;
20 is a diagram showing a configuration of the gateway device 7 in FIG.
21 is a signal sequence diagram showing a control signal and a message communicated in the communication network shown in FIG. 19 when a call (call setting) message is issued from the terminal device.
22 is a signal sequence diagram showing a control signal and a message communicated in the communication network shown in FIG. 19 when there is an incoming call to the terminal device.
FIG. 23 is a signal sequence diagram showing a control signal and a message communicated in the communication network shown in FIG. 19 when a “request to transfer to a designated connection destination” notification response is issued from the terminal device.
FIG. 24 is a flowchart showing a call signal processing routine executed by the gateway 7 when a call (call setting) message is received from the terminal device.
FIG. 25 is a flowchart showing an incoming call notification processing routine executed by the gateway 7 when an incoming call notification message is received from the service control gateway 1;
FIG. 26 is a flowchart showing a notification response processing routine executed by the gateway 7 when a notification response message is received from the terminal.
FIG. 27 is a flowchart showing an IN service end routine executed by the gateway 7 when a call is disconnected.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1 ... Service control gateway apparatus, 2 ... SCP, 3 ... WWW server, 4 ... Switch, 6 ... Subscriber terminal, 7 ... Gateway apparatus, 11 ... CPU, 12 ... Memory , 13 ... IP network interface unit, 15 ... high-function network interface unit.

Claims

In an "intelligent network" service control device connected to a plurality of exchanges constituting a transmission network via a common line signal network and connected to an Internet protocol network via a gateway device,
When a service request message issued when a call waiting service request is input to the first terminal device communicating with the Internet protocol network via the transmission network, the “first terminal” First means for storing in the user information management table information indicating that the device is connected to the Internet;
When one of the plurality of exchanges notifies that the first terminal device has received an incoming call from the second terminal device, the user information management table is referred to the first terminal device. And a second means for transmitting the incoming notification message to the gateway device.

The user information management table includes an entry including a telephone number of the first terminal, flag information indicating whether the first terminal is connected to the Internet, and address information of the gateway device;
The service control apparatus according to claim 1, wherein the first means updates the contents of the entry, and the second means refers to the flag information and address information of the entry.

When receiving a notification response message “indicating a response from the user of the first terminal device to the incoming call notification” via the gateway device, the second means sends the first terminal device to the first switch. The service control apparatus according to claim 1, wherein an incoming call to a connection service is provided according to the response.

“Intelligent network service control device” connected to a plurality of exchanges constituting the transmission network via a common line signal network and “Internet protocol network” connected to the transmission network “ In "Service Control Gateway Device"
Internet call waiting by the service control device, which is issued when a call waiting service request is input to the first terminal device communicating with the Internet protocol network via the transmission network. Protocol conversion means for converting a “service request message” requesting a service into a “message addressed to the service control device” including an identifier that identifies one of a plurality of service control programs executed by the service control device When,
And a means for transmitting the protocol-converted message to a signal line connected to the service control apparatus.

An incoming notification message transmitted from the service control device indicating that “the first terminal device has received an incoming call from the second terminal device” is transmitted to the “communication with the first terminal device” included in the Internet protocol network. A protocol conversion means for converting the message into the server addressed to the server, wherein the server has a function of transferring a received message from the service control gateway device to the first terminal device, and the protocol-converted message is sent to the server The service control gateway apparatus according to claim 4, further comprising means for transmitting to a signal line connected to the service line.

An incoming notification message transmitted from the service control device indicating that “the first terminal device has received an incoming call from the second terminal device” is transmitted to the “communication with the first terminal device” included in the Internet protocol network. A protocol conversion means for changing the message to a message addressed to the access point device in the access point device, the access point device having a function of transferring a received message from the service control gateway device to the first terminal device;
5. The service control gateway apparatus according to claim 4, further comprising means for transmitting the protocol-converted message to a signal line connected to the Internet protocol network.