JP4348271B2

JP4348271B2 - Ｓｉｐ端末制御システム

Info

Publication number: JP4348271B2
Application number: JP2004293126A
Authority: JP
Inventors: 善博岡; 新二大西
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2004-10-05
Filing date: 2004-10-05
Publication date: 2009-10-21
Anticipated expiration: 2024-10-05
Also published as: CN101053244A; EP1798944A4; JP2006109111A; WO2006038436A1; EP1798944A1; US20080059640A1

Description

本発明は、ＳＩＰ端末（ＳＩＰによる接続制御が可能な端末の意味）に各種データ等をダウンロードしたり、ＳＩＰ端末から各種データ等をアップロードしたりするために、センターシステムで発生したダウンロード要求、アップロード要求、アップグレード要求等をＩＰ網経由でＳＩＰ端末に通知するＳＩＰ端末制御システムに関する。

従来、センター側からＩＰ網経由で端末にアクセスして端末のソフトウエアを更新するシステムとして、携帯電話端末のファームウエアを更新するファームウエア配信システムが知られている（例えば、特許文献１参照）。かかるファームウエア配信システムでは、ファームウエア配信サーバに、全ての携帯電話端末についての機種名、実装ファームウエアの版数情報等をデータベース化して保持する。このデータベースを参照して指定された機種の携帯電話端末について現時点でのファームウエアの版数をチェックし、最新バージョンのファームウエアが搭載されていない携帯電話端末に対して携帯電話網経由でアクセスする。ファームウエア配信サーバは、このアクセスが携帯端末に着信して携帯電話端末が動作可能な状態にあることを確認した後、その携帯電話端末に更新用ファームウエアモジュールを送信する。

また、携帯電話端末に限らず、パーソナルコンピュータ、ネットワーク接続型の事務機器（ネットワークプリンタ、インターネットＦＡＸ等）、ネット家電（ＩＰ電話機、ＩＰテレビ装置等）、ゲートウェイ、ルータ等についても、ＩＰ網を介して各種データ（ソフトウエア、設定データ等）をダウンロードしたり、端末からアップロードしたりすることが望まれている。現状は、機器管理サーバで管理対象の全端末のアドレス情報（ＩＰアドレス、電話番号等）を管理し、機器管理サーバがアドレス情報を利用して個々の端末に１つ１つ呼接続し、回線接続した状態でダウンロード、アップグレード等を実行している。

なお、ＩＰ網側の機器管理サーバからアクセス先の端末を見た場合、端末がファイアーウォールの内側に配置されていると、ＩＰ網側から端末に対してダウンロード要求、アップグレード要求、アップロード要求を通知しようとしても、ファイアーウォールで拒否されてしまう。このため、一つの対策として、機器管理サーバが各端末に対して１つ１つ呼接続してセッションを確立する必要があった。
特開２００３−２０９５１０号公報

しかしながら、機器管理サーバが全端末のアドレス情報を管理する場合、端末のＩＰアドレスが変化することも予想されるため、常に全端末の正確なアドレス情報を管理しなければならず、端末数が増えて来たときに管理負担が増大する問題がある。

また、端末側から機器管理サーバに対して登録情報（アクセス情報を含む）を通知させて、その端末情報を基にアクセス情報を更新することも考えられるが、この場合には登録情報を通知してきた個々の端末を認証する認証機構が必要となり、機器管理サーバ側の構成が複雑化する問題が発生する。

本発明は、以上のような実情に鑑みてなされたものであり、端末制御のために各端末のＩＰアドレスを管理するデータベースや各端末を認証する認証機構を独自に備える必要が無く、しかもＩＰ網側から各端末に対してダウンロード要求、アップグレード要求、アップロード要求を通知することのできるＳＩＰ端末制御システムを提供することを目的とする。

本発明は、ＳＩＰ端末に対するダウンロード要求、アップロード要求、アップグレード要求等の各種要求を、該当ＳＩＰ端末を収容するＩＰ呼制御装置からＳＩＰを用いてＳＩＰ端末へ通知することにより、各端末のＩＰアドレスを管理するデータベースや各端末を認証する認証機構はＩＰ呼制御装置の既存の機能を利用できると共にＳＩＰを用いることによりファイアーウォールを越えてＳＩＰ端末へアクセスすることができる。

本発明によれば、端末制御のために各端末のＩＰアドレスを管理するデータベースや各端末を認証する認証機構を独自に備える必要が無く、しかもＩＰ網側から各端末に対してダウンロード要求、アップグレード要求、アップロード要求を通知することができるＳＩＰ端末制御システムを提供できる。

本発明の第１の態様は、センターシステムが端末に対するダウンロード要求を発生し、このダウンロード要求の発生を受けてＩＰ呼制御装置がアドレス情報データベースから端末のアドレス情報を取得し、このアドレス情報を用いて前記ＩＰ呼制御装置がＩＰ網経由で前記端末に接続してダウンロード要求を通知するＳＩＰ端末制御システムである。

このように構成されたＳＩＰ端末制御システムによれば、センターシステムが発した端末に対するダウンロード要求をＩＰ呼制御装置が受け取り、ＩＰ呼制御装置がＩＰ網経由で前記端末に接続してダウンロード要求を通知するので、端末制御のために各端末のＩＰアドレスを管理するデータベースや各端末を認証する認証機構をセンターシステムが独自に備える必要が無くなるとともに、ＩＰ呼制御装置が収容端末に対して接続することになるのでファイアーウォールを越えてＳＩＰ端末へアクセスすることができ、ダウンロード要求を通知することができる。

なお、前記ＩＰ呼制御装置は、ＳＩＰメッセージを使用して前記端末に接続し、当該端末に対してダウンロード要求を通知すると共にダウンロードサーバのアドレス情報を通知することが望ましい。

本発明の第２の態様は、センターシステムが端末に対するアップロード要求を発生し、このアップロード要求の発生を受けてＩＰ呼制御装置がアドレス情報データベースから端末のアドレス情報を取得し、このアドレス情報を用いて前記ＩＰ呼制御装置がＩＰ網経由で前記端末に接続してアップロード要求を通知することを特徴とするＳＩＰ端末制御システムである。

このように構成されたＳＩＰ端末制御システムによれば、センターシステムが発した端末に対するアップロード要求をＩＰ呼制御装置が受け取り、ＩＰ呼制御装置がＩＰ網経由で前記端末に接続してアップロード要求を通知するので、端末制御のために各端末のＩＰアドレスを管理するデータベースや各端末を認証する認証機構をセンターシステムが独自に備える必要が無くなるとともに、ＩＰ呼制御装置が収容端末に対して接続することになるのでファイアーウォールを越えてＳＩＰ端末へアクセスすることができ、アップロード要求を通知することができる。

なお、前記ＩＰ呼制御装置は、ＳＩＰメッセージを使用して前記端末に接続し、当該端末にアップロード要求を通知すると共にアップロード先のアドレス情報を通知することが望ましい。

本発明の第３の態様は、センターシステムが端末に対する内部ソフトウエア又は環境ファイルのアップグレード要求を発生し、このアップグレード要求の発生を受けてＩＰ呼制御装置がアドレス情報データベースから端末のアドレス情報を取得し、このアドレス情報を用いて前記ＩＰ呼制御装置がＩＰ網経由で前記端末に接続してアップグレード要求を通知することを特徴とするＳＩＰ端末制御システムである。

このように構成されたＳＩＰ端末制御システムによれば、センターシステムが発した端末に対するアップグレード要求をＩＰ呼制御装置が受け取り、ＩＰ呼制御装置がＩＰ網経由で前記端末に接続してアップグレード要求を通知するので、端末制御のために各端末のＩＰアドレスを管理するデータベースや各端末を認証する認証機構をセンターシステムが独自に備える必要が無くなるとともに、ＩＰ呼制御装置が収容端末に対して接続することになるのでファイアーウォールを越えてＳＩＰ端末へアクセスすることができ、アップグレード要求を通知することができる。

なお、前記ＩＰ呼制御装置は、ＳＩＰメッセージを使用して前記端末に接続し、当該端末にアップグレード要求を通知すると共にダウンロードサーバのアドレス情報を通知することが望ましい。

本発明の他の態様は、端末制御サーバがＩＰ電話機に対する留守番録音データファイルのアップロード要求を発生し、このアップロード要求の発生を受けてＩＰ呼制御装置がアドレス情報データベースから前記ＩＰ電話機のアドレス情報を取得し、このアドレス情報を用いて前記ＩＰ呼制御装置がＩＰ網経由で前記ＩＰ電話機に接続してアップロード要求及びアップロード先のアドレス情報を通知し、このアップロード要求を受けたＩＰ電話機がアップロード先に指定されたアップロードサーバへ留守番録音データファイルをアップロードすることを特徴とする留守番録音データファイルのアップロード方法である。

本発明のさらに他の態様は、端末制御サーバが発する端末に対するダウンロード要求を受け付けるステップと、この受け付けたダウンロード要求の通知先となる端末のアドレス情報を収容端末のアドレス情報データベースから取得するステップと、このアドレス情報を用いてＩＰ網経由で前記端末にＳＩＰメッセージを用いて接続してダウンロード要求を通知するステップと、を具備した通知方法である。

本発明のさらに他の態様は、端末制御サーバが発する端末に対するアップロード要求を受け付けるステップと、この受け付けたアップロード要求の通知先となる端末のアドレス情報を収容端末のアドレス情報データベースから取得するステップと、このアドレス情報を用いてＩＰ網経由で前記端末にＳＩＰメッセージを用いて接続してアップロード要求を通知するステップと、を具備した通知方法である。

本発明のさらに他の態様は、管理サーバが発する端末に対する内部ソフトウエア又は環境ファイルのアップグレード要求を受け付けるステップと、この受け付けたアップグレード要求の通知先となる端末のアドレス情報を収容端末のアドレス情報データベースから取得するステップと、このアドレス情報を用いてＩＰ網経由で前記端末にＳＩＰメッセージを用いて接続してアップグレード要求を通知するステップと、を具備した通知方法である。

以下、図面を参照して本発明の一実施の形態について詳細に説明する。

図１は本実施の形態に係るＳＩＰ端末制御システムの全体構成図である。ＳＩＰ端末側システム１０は、ＳＩＰ端末としてのＩＰ電話１１をＬＡＮ１２に接続し、ルータ１３及びゲートウェイ１４を経由してＩＰ網３０に接続する。ゲートウェイ１４はＮＡＴ機能及びファイアーウォール機能を備える。また、ＳＩＰ端末側システム１０は、ＶｏＩＰゲートウェイ１５を介して既存の交換装置１６に接続し、公衆交換網に接続可能な構成となっている。なお、ＳＩＰ端末はＩＰ電話１１等に限定されるものではなく、ＩＰ網３０に接続するゲートウェイ１４、公衆交換網に接続するＶｏＩＰゲートウェイ１５も対象となり得る。また、図１ではＳＩＰ端末としてＩＰ電話１１を例示しているが、その他にもパーソナルコンピュータ、ネットワーク接続型の事務機器（ネットワークプリンタ、インターネットＦＡＸ等）、ネット家電（ＩＰテレビ装置、ＩＰビデオカメラ等）も対象となり得る。

センター側システム２０は、ＩＰ呼制御装置４１、端末制御サーバ５１、ダウンロードサーバ６１にて構成されている。本実施の形態では、ＩＰ呼制御装置４１と端末制御サーバ５１との間、並びにＩＰ呼制御装置４１とダウンロードサーバ６１との間を専用線で接続している。但し、ＩＰ呼制御装置４１と端末制御サーバ５１との間は必ずしも専用線で結ぶ必要はないが、セキュアなデータ通信環境が望ましい。また、ＩＰ呼制御装置４１及びダウンロードサーバ６１をセンター側システム２０に包含しないでＩＰ網３０上に独立して配置し、同一又は異なる事業者が運用する構成とすることもできる。

ＩＰ呼制御装置４１は、ＬＡＮ４２を経由してルータ４３及びＳＢＣ（Session Border Controller）４４からＩＰ網３０に接続している。ＳＢＣ４４はＳＩＰ及びＲＴＰにおけるＮＡＴ機能及びファイアーウォール機能を備える。ＩＰ呼制御装置４１は、ＩＰ電話１１等の収容端末（ゲートウェイ装置等を含む）のアドレス情報（ＩＰアドレス）を登録したアドレス情報データベース４５を備えている。アドレス情報データベース４５には認証に必要な情報（ユーザＩＤ、パスワード等）も登録するが、呼制御以外に使用する情報も登録することができる。例えば、収容端末のファイル版数情報や端末の状態を登録しても良い。ＩＰ呼制御装置４１は、アドレス情報データベース４５に対する読み出し及び書き込みを行うデータベース制御部４６と、アドレス情報データベース４５を参照しＳＩＰによるＳＩＰ端末間の接続を制御する呼制御部４７と、ＳＩＰ端末からの登録要求に対する認証処理の他各種アプリケーションを実行するアプリ部４８とを備える。なお、ＩＰ呼制御装置４１は、端末制御サーバ５１に対してはルータ４９を介して専用線接続し、ダウンロードサーバ６１に対してはルータ４０を介して専用線接続している。

端末制御サーバ５１は、ＬＡＮ５２を経由してゲートウェイ５３からＩＰ網３０に接続している。ゲートウェイ５３は、ルータとして機能していて、ＮＡＴ機能及びファイアーウォール機能を備える。端末制御サーバ５１は、ＩＰ呼制御装置４１によるＳＩＰ接続サービスを利用してＳＩＰ端末に接続し、ダウンロード要求、アップグレード要求、又はアップロード要求を通知する。これら要求の通知に限らず、ＩＰ呼制御装置４１によって端末制御サーバ５１とＳＩＰ端末とを接続することにより、端末制御サーバ５１からＳＩＰ端末に対してＩＰ網３０経由でアクセスして各種制御を行うことが可能になっている。なお、端末制御サーバ５１は、ＩＰ呼制御装置４１に対してルータ５４を介して専用線接続している。

ダウンロードサーバ６１は、ＬＡＮ６２を経由してゲートウェイ６３からＩＰ網３０に接続している。ゲートウェイ６３は、ルータとして機能していて、ＮＡＴ機能及びファイアーウォール機能を備える。ダウンロードサーバ６１は、端末からの要求を受けて要求元の端末に対してデータをダウンロードする。データの転送にはデータ内容に応じてＦＴＰ等の適当なプロトコルを使用する。

なお、上記ＳＩＰ端末制御システムにおいて、ルータ１３、４０、４３、４９、５４、６４の機能をスイッチで実現する構成としても良い。

次に、以上のように構成された本実施の形態に係るＳＩＰ端末制御システムの動作内容について説明する。

図２はＳＩＰ端末がＩＰ呼制御装置４１に登録要求した場合のシーケンス図である。なお、ＳＩＰ端末は、ＩＰ呼制御装置４１にアドレス情報の登録を要求するクライアントとなるので同図ではＳＩＰ端末をクライアント端末と記載している。クライアント端末は、ＳＩＰを実装していてＩＰ呼制御装置４１によってセッション接続可能な機器であれば、ＩＰ電話１１に限らない。例えば、ＶｏＩＰゲートウェイ１５も対象になり得るし、図示されていないパーソナルコンピュータ、ネットワーク接続型の事務機器（ネットワークプリンタ、インターネットＦＡＸ等）、ネット家電（ＩＰ電話機、ＩＰテレビ装置等）等もクライアント端末となり得る。

クライアント端末は、ＩＰ呼制御装置４１に対して自己の最新情報（例えばアドレス情報、ユーザＩＤ）の登録を要求する登録要求を発する（Ｓ１０１）。登録要求は定期的に行っても良いし、何等かのイベントを契機にして発するようにしても良い。

ＩＰ呼制御装置４１は、クライアント端末の発した登録要求をＩＰ網３０経由で受信する。ＩＰ呼制御装置４１は、受信した登録要求を受け付けて（Ｔ１０１）、要求元のクライアント端末に対して認証要求を発する（Ｔ１０２）。ＩＰ呼制御装置４１がクライアント端末に対して送信する認証要求には認証に必要な情報が含まれる。

クライアント端末は、ＩＰ呼制御装置４１が発した認証要求を受け付け（Ｓ１０２）、認証情報を含む登録要求をＩＰ呼制御装置４１に対して返信する（Ｓ１０３）。返信する認証情報には認証に必要な情報が含まれる。

ＩＰ呼制御装置４１は、クライアント端末が送信した認証情報を受信すると（Ｔ１０３）、認証情報の確認を行う（Ｔ１０４）。例えば、アドレス情報データベース４５に当該クライアント端末のユーザが事前登録していたパスワードとの一致を見る。パスワードが一致すれば認証成功情報を設定するが（Ｔ１０５）、パスワードが不一致の場合は認証失敗情報を設定する（Ｔ１０６）。認証結果はクライアント端末へ通知する（Ｔ１０７）。

クライアント端末は、ＩＰ呼制御装置４１から通知された認証結果を受け付ける（Ｓ１０４）。受け付けた認証結果が認証失敗を示している場合、再び登録要求を発して登録を試みるようにしても良い。

ＩＰ呼制御装置４１は、認証成功情報が設定されたクライアント端末についてはＴ１０１で受付けた情報（例えばアドレス情報、ユーザＩＤ）でアドレス情報データベース４５の該当箇所を更新する。これにより、アドレス情報データベース４５に当該クライアント端末の最新のアドレス情報等が登録されたことになる。ＩＰ呼制御装置４１に登録している全てのＳＩＰ端末（クライアント端末）が定期的又は不定期に上記登録要求を発生することにより、アドレス情報データベース４５に登録されたアドレス情報は最新のものに更新される。例えば、クライアント端末がアクセスポイントを移動することでＩＰアドレスが変化する場合であっても、クライアント端末からの登録要求によって、ＩＰ呼制御装置４１において常に最新のアドレス情報を把握することができる。

次に、センター側システム２０がＳＩＰ端末を管理する一例として、ＳＩＰ端末にインストールしたソフトウエアの版数管理について説明する。

図３はクライアント端末が版数管理装置に対して自己の版数情報を通知するシーケンスを示している。センター側システム２０の端末制御サーバ５１が版数管理装置を兼ねることもできるし、別にＩＰ網３０上に版数管理装置を設置するシステム構成を採ることもできる。

クライアント端末は、現在インストールしているソフトウエアの版数情報を、定期的又は何等かのイベント発生を契機にして、ＩＰ呼制御装置４１へ通知する（Ｓ２０１）。クライアント端末とＩＰ呼制御装置４１との間の通信にはＳＩＰを利用している。具体的には、クライアント端末は、ＳＩＰのイベント通知の一つであるSUBSCRIBEリクエストを利用して版数通知を行っている。図８はクライアント端末の版数情報を版数管理装置へ通知するために使用するSUBSCRIBEリクエストの具体例である。SUBSCRIBEリクエストのEventヘッダフィールドに当該クライアント端末の版数情報（最新ファイルに関する情報）を記述している。具体的には、sip-profile,profile-name=,vendor=,model=,version=によって版数情報を定義する。

ＩＰ呼制御装置４１は、クライアント端末から発せられたSUBSCRIBEリクエストを受信してそのEventヘッダフィールドの記述から版数通知であると認識し、当該版数通知を受け付ける（Ｔ２０１）。なお、クライアント端末がＩＰ呼制御装置４１のアドレス情報データベース４５に登録されたユーザ以外であれば、版数通知は受け付け拒否される。ＩＰ呼制御装置４１は、版数通知を受け付けると、版数管理装置に対して版数情報をデータ送信する（Ｔ２０２）。本例ではＩＰ呼制御装置４１と版数管理装置との間でもＳＩＰを利用して通信している。ＩＰ呼制御装置４１がＴ２０１で受け付けた版数情報はSUBSCRIBEリクエストの形式で版数管理装置へ通知する。

版数管理装置は、ＩＰ呼制御装置４１からSUBSCRIBEリクエストの形式で送られてきた版数情報を受信する（Ｑ２０１）。版数管理装置は、版数情報をクライアント毎に保存した版数データベースを有している。受信した版数情報は版数データベースへ保存する（Ｑ２０２）。版数管理装置は、受信版数情報を版数データベースへ保存するのに成功すると、版数通知を受け取ったことを示す版数通知ＯＫを返信する（Ｑ２０３）。具体的には、ＩＰ呼制御装置４１に対して２００ＯＫを返す。

ＩＰ呼制御装置４１は、版数管理装置から２００ＯＫを受信すると（Ｔ２０３）、接続先のクライアント端末に対して２００ＯＫを送信する（Ｔ２０４）。

クライアント端末は、２００ＯＫを受信して版数通知が完了したことを確認し（Ｓ２０２）、版数通知の処理を終了する。

このように、クライアント端末は、ＩＰ呼制御装置４１を介して版数管理装置にＳＩＰで接続し、ＳＩＰでサポートされたSUBSCRIBEリクエストを使用して自己の版数情報を版数管理装置へ通知するものとした。

次に、端末制御サーバ５１がクライアント端末に対してダウンロード要求する場合の動作について説明する。

図４は端末制御サーバ５１が発したダウンロード要求によりクライアント端末がデータをダウンロードするシーケンス図である。本実施の形態ではダウンロード要求の通知にＳＩＰのNOTIFYリクエストを使用する。

端末制御サーバ５１は、クライアント端末に対するダウンロード要求を発生する（Ｑ３０１）。ダウンロード要求はNOTIFYリクエストの形式でＩＰ呼制御装置４１へ通知する。通知先となるクライアント端末の特定情報（例えばユーザＩＤ）をNOTIFYリクエストに含めるものとする。

ＩＰ呼制御装置４１は、端末制御サーバ５１からのNOTIFYリクエストを受信してダウンロード要求を受け付ける（Ｔ３０１）。本実施の形態では、ＩＰ呼制御装置４１が通知先とされたクライアント端末への新ファイルのダウンロードの要否を判断し（Ｔ３０２）、新ファイルのダウンロードが必要であると判断した場合はNOTIFYリクエストを使用してクライアント端末へダウンロード要求を通知する（Ｔ３０３）。

例えば、端末制御サーバ５１が各クライアント端末にインストールされているファイルの版数情報を管理する。ＩＰ呼制御装置４１に版数管理機構を備える。図３に示す版数管理装置をＩＰ呼制御装置４１の内部に含んだ形態としても良いし、外部に配置して版数管理装置にその都度接続して問い合わせる形態としても良い。そして、ダウンロード要求の通知先となるクライアント端末の最新の版数を版数管理機構によって取得する。クライアント端末の最新の版数と今回ダウンロード要求のあった版数とを比較し、一致していればダウンロード不要と判断する。この場合、端末制御サーバ５１に対して「２００ＯＫ」を返信して処理を終了する。一方、今回ダウンロード要求のあった版数がクライアント端末の最新の版数よりも新しかった場合、ダウンロード要求を通知するNOTIFYリクエストをクライアント端末に対して送信する。図９はダウンロード要求をクライアント端末へ通知するために使用するNOTIFYリクエストの具体例を示している。NOTIFYリクエストのEventヘッダフィールドにファイルのダウンロード要求の通知であることを記述している。また、Content-TypeヘッダフィールドでMultipart/mixedを指定し、メッセージボディに当該クライアント端末にダウンロードすべきファイルを格納したサイト（ダウンロードサーバ）に関するアクセス方法(access-type)、アクセス有効期限(expiration)、アドレス情報(URL)を記述している。

クライアント端末は、ＩＰ呼制御装置４１からNOTIFYリクエストを受信し、そのEventヘッダフィールドの記述内容からダウンロード要求通知であることを認識し、当該要求を受け付ける（Ｓ３０１）。要求受付したクライアント端末は、NOTIFYリクエストからファイルのダウンロードに必要な情報を取り出す。本例では、ダウンロードすべきファイルがダウンロードサーバ６１に保存されていて、当該ダウンロードサーバ６１がＨＴＴＰにてクライアント端末からのダウンロード要求を受け付ける設定としている。クライアント端末は、NOTIFYリクエストに記述されたダウンロードサーバ６１のＵＲＬを使用してダウンロードサーバ６１にＨＴＴＰでアクセスする。そして、NOTIFYリクエストで指示されたファイルを要求するダウンロード要求を通知する（Ｓ３０２）。

ダウンロードサーバ６１は、クライアント端末からダウンロード要求を受け付けると（Ｄ３０１）、要求元のクライアント端末に対して指定されたファイルをデータ送信する（Ｄ３０２）。例えばファイルの転送にはＦＴＰ、ＨＴＴＰといったプロトコルを使用できる。ダウンロードサーバ６１は、ファイルのデータ送信が終了したら（Ｄ３０３）、処理を終了する。

クライアント端末は、ダウンロードサーバ６１からファイルのダウンロードを実行する（Ｓ３０３）。ダウンロードが終了したら（Ｓ３０４）、ダウンロードが成功したか否か判断し（Ｓ３０５）、成功した場合は成功情報を設定し（Ｓ３０６）、失敗した場合は失敗情報を設定する（Ｓ３０７）。最後に、クライアント端末は、Ｓ３０６又はＳ３０７での設定内容を、ＩＰ呼制御装置４１に対して結果通知する（Ｓ３０８）。結果通知は、２００ＯＫを返信する。このようにして、端末制御サーバ５１が発したダウンロード要求に対してクライアント端末にファイルがダウンロードされたことになる。

ＩＰ呼制御装置４１は、Ｔ３０３でクライアント端末に通知したダウンロード要求に対して２００ＯＫを受信すると（Ｔ３０４）、ダウンロード要求が受理されたと認識し、端末制御サーバ５１に対して２００ＯＫを送信する（Ｔ３０５）。

端末制御サーバ５１は、Ｑ３０１でＩＰ呼制御装置４１に通知したダウンロード要求に対して２００ＯＫを受信すると（Ｑ３０２）、ダウンロード要求が受理されたと認識して当該クライアント端末に対するダウンロード要求処理を終了する。

このように、クライアント端末（ＩＰ電話１１等）から見てファイアーウォールの外側にある端末制御サーバ５１が発したダウンロード要求を、そのクライアント端末を収容するＩＰ呼制御装置４１がＳＩＰリクエストを使って当該クライアント端末へ伝えるように構成したので、端末制御サーバ５１はＩＰ呼制御装置４１に収容される全端末（ゲートウェイ等を含む）の最新アドレス情報、認証機構を持つことなく、またファイアーウォールを乗り越えてクライアント端末までダウンロード要求を通知できる。したがって、センターシステムとして機能する端末制御サーバ５１のシステム構成を簡素化でき、コストダウンを図ることができる。

次に、端末制御サーバ５１がクライアント端末に対してアップロード要求する場合の動作について説明する。

図５は端末制御サーバ５１が発したアップロード要求によりクライアント端末がアップロードするシーケンス図である。本実施の形態ではアップロード要求の通知にＳＩＰのSUBSCRIBEリクエストを使用する。アップロードするデータは、クライアント端末に保持されているデータであれば特に限定されない。例えば、通信品質情報、通信履歴（ログ）、制御プログラム、環境情報などを対象とできる。

端末制御サーバ５１は、クライアント端末に保持されているデータのアップロードを要求する場合、クライアント端末を収容端末としているＩＰ呼制御装置４１に対してアップロード要求を通知する（Ｑ４０１）。アップロード要求は、SUBSCRIBEリクエストの形式で行う。

ＩＰ呼制御装置４１は、端末制御サーバ５１からSUBSCRIBEリクエストを受信してアップロード要求を受け付ける（Ｔ４０１）。ＩＰ呼制御装置４１は、端末制御サーバ５１から通知先として指定されたクライアント端末のＩＰアドレスを、SUBSCRIBEリクエストに含まれたユーザＩＤをキーにしてアドレス情報データベース４５から取得する。クライアント端末のＩＰアドレスがアドレス情報データベース４５に存在すれば、当該クライアント端末は、ＩＰ呼制御装置４１の収容端末であることを意味する。ＩＰ呼制御装置４１は、クライアント端末に対してアップロード要求を通知する（Ｔ４０２）。アップロード要求はSUBSCRIBEリクエストを用いて行われる。図１０はＩＰ呼制御装置４１からクライアント端末へアップロード要求を通知するSUBSCRIBEリクエストの具体例を示す図である。SUBSCRIBEリクエストのEventヘッダフィールドにアップロードを要請するデータ種別（本例では端末設定データ）が記述されている。またContactヘッダフィールドにアップロード先（ＩＰ呼制御装置）のアドレス情報が記述されている。クライアント端末は、端末設定データをＩＰ呼制御装置４１へアップロードする（Ｓ４０２ａ）。SUBSCRIBEリクエストで要請された端末設定データの通知にはNOTIFYリクエストを用いる。図１１はクライアント端末からＩＰ呼制御装置４１へ送信するNOTIFYリクエストの具体例である。NOTIFYリクエストのEventヘッダフィールドに通知するデータ種別（本例では端末設定データ）が記述されている。またメッセージボディにアップロードするデータ本体である設定データが記述される。

ＩＰ呼制御装置４１は、Ｔ４０２で送信したSUBSCRIBEリクエストに対してNOTIFYリクエストを受信する（Ｔ４０３ａ）。受信したNOTIFYリクエストからMIME本文を切り出して端末設定データを取得し、その端末設定データを端末制御サーバ５１へデータ送信する（Ｔ４０４）。端末制御サーバ５１に対するデータ送信にもNOTIFYリクエストの形式を用いることができる。

端末制御サーバ５１は、Ｑ４０１で送信したSUBSCRIBEリクエストに対してNOTIFYリクエストを受信する（Ｑ４０２）。受信したNOTIFYリクエストから端末設定データを取り出し、端末管理用に保存し、アップロード要求処理を終了する。

なお、図５に点線で示すように、クライアント端末がＩＰ呼制御装置４１にアップロードしたら（Ｓ４０２ｂ）、ＩＰ呼制御装置４１から端末制御サーバ５１へ送信せずに、ＩＰ呼制御装置４１が保存して管理するようにしても良い（Ｔ４０３ｂ）。例えば、クライアント端末の版数情報をＩＰ呼制御装置４１へアップロードし、端末制御サーバ５１からファイルのダウンロード要求を受信したときに該当クライアント端末の版数情報を確認するのに用いるようにする。

また、端末制御サーバ５１及びＩＰ呼制御装置４１とは別のアップロード用サーバをＩＰ網３０上に設置し、アップロード要求を受け付けたクライアント端末からアップロード用サーバへ直接アップロードするようにしても良い。この場合、ＩＰ呼制御装置４１がＴ４０２で送信するSUBSCRIBEリクエストにアップロード先のアドレス情報としてアップロード用サーバのアドレスを記述しておく。

また、クライアント端末からＩＰ呼制御装置４１又はアップロード用サーバへのデータアップロードに使用するプロトコルはＳＩＰに限定されるものではなく、ＨＴＴＰ、ＦＴＰ等のプロトコルを使用しても良い。

このように、クライアント端末から見てファイアーウォールの外側にある端末制御サーバ５１が発したアップロード要求を、そのクライアント端末を収容するＩＰ呼制御装置４１がＳＩＰリクエストを使って当該クライアント端末へ伝えるように構成したので、端末制御サーバ５１はＩＰ呼制御装置４１に収容される全端末（ゲートウェイ等を含む）の最新アドレス情報、認証機構を持つことなく、またファイアーウォールを乗り越えてクライアント端末までアップロード要求を通知できる。したがって、センターシステムとして機能する端末制御サーバ５１のシステム構成を簡素化でき、コストダウンを図ることができる。

次に、端末管理サーバ／版数管理装置の発するアップグレード要求によりクライアント端末の内部ソフトウエア又は環境ファイルをアップグレードする場合の動作について説明する。本実施の形態ではアップグレード要求を発する装置として端末管理サーバ又は版数管理装置を例に挙げているが、その他の装置であっても良い。また、図１には端末管理サーバ／版数管理装置は図示していないが、端末制御サーバ５１が兼用しても良いし、ＩＰ網３０上に設置しても良い。ここでは、端末制御サーバ５１が兼用する端末管理サーバがアップグレード要求を発生するものとする。

図６は端末管理サーバが発したアップグレード要求によりクライアント端末が内部ソフトウエア又は環境ファイルをアップグレードするシーケンス図である。本実施の形態ではＩＰ呼制御装置４１からクライアント端末へのアップグレード要求の通知にNOTIFYリクエストを用いている。

端末管理サーバは、ＩＰ呼制御装置４１の収容端末である各クライアント端末の版数情報を確認し（Ｑ５０１）、内部ソフトウエア又は環境ファイルのアップグレードが必要であると判断すると、アップグレード要求を発生する（Ｑ５０２）。例えば、クライアント端末から送られてきた版数情報から内部ソフトウエア又は環境ファイルのアップグレードの要否を判断し、旧バージョンの内部ソフトウエア又は環境ファイルを使用しているクライアント端末を検出したら当該クライアント端末に対してアップグレード要求を発する。アップグレード要求はNOTIFYリクエスト形式でＩＰ呼制御装置４１に通知することができる。

ＩＰ呼制御装置４１は、端末管理サーバから通知されたアップグレード要求を受け付ける（Ｔ５０１）。ＩＰ呼制御装置４１は、要求受付を行って、通知先となるクライアント端末のＩＰアドレスをアドレス情報データベース４５からユーザＩＤをキーにして検索する。クライアント端末のアドレス情報がアドレス情報データベース４５に登録されていれば、当該クライアント端末はＩＰ呼制御装置４１に認証された収容端末ということになる。ＩＰ呼制御装置４１は、クライアント端末のＩＰアドレスを取得できたら、そのＩＰアドレスを送信先としてアップグレード要求を送信する（Ｔ５０２）。本実施の形態では、ＩＰ呼制御装置４１がクライアント端末に対して通知するアップグレード要求はNOTIFYリクエストを用いて行われる。このNOTIFYリクエストは図９に示したものと同様の構成とすることができる。すなわち、NOTIFYリクエストのEventヘッダフィールドを内部ソフトウエア又は環境ファイルのアップグレードを要請する記述とし、NOTIFYリクエストのメッセージボディにアップグレードデータを保存したサーバのアドレス情報（ＵＲＬ）及びアップグレードデータを特定する情報を記述する。

クライアント端末は、アップグレード要求に関するNOTIFYリクエストを受信してアップグレード要求を受け付け（Ｓ５０１）、アップグレード可能な状態であるか否か判断する（Ｓ５０２）。例えば、アップグレード対象のソフトウエアを使用中であればアップグレード不可と判断して処理を終了する。一方、Ｓ５０２でアップグレード可能と判断した場合、受信NOTIFYリクエストに含まれたコンタクト情報を参照してサーバに対してダウンロード要求を発する（Ｓ５０３）。コンタクト情報はアップグレードデータを保存したサーバのアドレス情報（ＵＲＬ）及びアップグレードデータを特定する情報等のデータである。本例では図１に示すダウンロードサーバ６１がコンタクト情報で指定されているものとする。

ダウンロードサーバ６１は、クライアント端末からダウンロード要求を受信して要求受付を行った後（Ｄ５０１）、クライアント端末に対して要求されたデータ（内部ソフトウエア又は環境ファイル等）を送信する（Ｄ５０２）。全ての該当データの送信が終了したら（Ｄ５０３）、ダウンロードを終了する。

クライアント端末は、ダウンロード要求に対する応答データを受信して保存する（Ｓ５０４）。このような、ダウンロードが終了したら（Ｓ５０５）、Ｓ５０１で受信したNOTIFYリクエストに対して２００ＯＫをＩＰ呼制御装置４１に返す（Ｓ５０６）。これにより、アップグレード要求された内部ソフトウエア又は環境ファイルのダウンロードが完了したことを通知したことになる。

ＩＰ呼制御装置４１は、Ｔ５０２で送信したNOTIFYリクエストに対して２００ＯＫを受信すると（Ｔ５０３）、Ｔ５０１で受信したNOTIFYリクエストに対して２００ＯＫを返信する（Ｔ５０４）。これにより、要求元の端末管理サーバに対してアップグレード要求に対する結果が通知される。

端末管理サーバは、Ｑ５０２で送信したNOTIFYリクエストに対して２００ＯＫを受信すると（Ｑ５０３）、アップグレード要求に対する結果を受信したことになり、一連のアップグレード要求の処理を終了する。

次に、端末制御サーバ５１からの指示に従い、ＳＩＰ端末に保持するデータをサーバへアップロードする場合の一例について説明する。

図７は、自宅の留守番電話に録音されたデータファイルをサーバへアップロードする場合のシステム構成例を示している。自宅のＩＰ電話７１に録音装置７２が付設されていて、録音装置７２に録音されたデータファイルはＩＰ電話７１からＩＰ網３０へ送信可能に構成している。ＩＰ電話７１はＬＡＮ７３に接続されていて、ルータ７４経由でＩＰ網３０に接続可能になっている。ユーザは会社のパーソナルコンピュータ（ＰＣ）８１からアップロードサーバ９１にアクセスして録音されたデータファイルを取得できる。ＰＣ８１はＬＡＮ８２に接続されていて、ルータ８３及びゲートウェイ８４を経由してＩＰ網３０に接続可能になっている。アップロードサーバ９１はＷｅｂサーバで構成することができる。アップロードサーバ９１は、ＬＡＮ９２に接続されていて、ゲートウェイ９３を経由してＩＰ網３０に接続可能になっている。

以上のようなシステム構成において、自宅のＩＰ電話７１は留守録音モード時に着信があると、発信者から入力されたメッセージを留守番電話録音データに変換して録音装置７２に記憶する。ＩＰ電話７１の録音装置７２に記憶したデータファイルを、端末制御サーバ５１からのアップロード要求によってアップロードサーバ９１にアップロードする。かかるアップロードには図５に示すようにＩＰ呼制御装置４１が介在する。すなわち、端末制御サーバ５１が発したアップロード要求をＩＰ呼制御装置４１が受け付け、ＩＰ呼制御装置４１から該当するＩＰ電話７１に対してSUBSCRIBEリクエストを送信してアップロード要求を通知する。ＳＩＰ端末であるＩＰ電話７１はSUBSCRIBEリクエストを受信すると、録音装置７２に記憶している留守番電話録音データのデータファイルをアップロードサーバ９１へデータ送信する。

一方、ユーザは自宅外のＰＣ８１からアップロードサーバ９１へアクセスして、自宅のＩＰ電話７１からアップロードした留守番電話録音データのデータファイルをダウンロードする。そして、ＰＣ８１にダウンロードした留守番電話録音データのデータファイルを再生することにより自宅の留守番電話に録音された内容を聞くことができる。

このように、自宅のＩＰ電話７１で録音されたる留守電録音データを、センター側の端末制御サーバ５１が発したアップロード要求によってアップロードサーバ９１へアップロードできるので、ＩＰ電話７１に留守録機能及びアップロード機能を搭載するだけで、自宅外のＰＣ８１から自宅の留守番電話に録音された内容を聞くことができる。

なお、ＳＩＰ端末からアップロードするアップロードデータの対象は上述したデータに限定されるものではない。例えば、ＳＩＰ端末の各種の通信記録（情報）を対象とすることができ、音声情報の品質、接続において音声が届いていたか否かの情報、通信履歴（ログ）を対象としてもよい。

本発明は、端末制御のために各端末のＩＰアドレスを管理するデータベースや各端末を認証する認証機構を独自に備える必要が無く、しかもＩＰ網側から各端末に対してダウンロード要求、アップグレード要求、アップロード要求を通知することができ、ＳＩＰ端末制御システムに適用可能である。

本発明の一実施の形態に係るＳＩＰ端末制御システムの全体構成図上記実施の形態においてＳＩＰ端末が登録要求した場合のシーケンス図上記実施の形態においてＳＩＰ端末が版数通知した場合のシーケンス図上記実施の形態において端末制御サーバがダウンロード要求した場合のシーケンス図上記実施の形態において端末制御サーバがアップロード要求した場合のシーケンス図上記実施の形態において端末管理サーバ／版数管理装置がアップグレード要求した場合のシーケンス図自宅の留守番電話に録音されたデータファイルをサーバへアップロードする場合のシステム構成例を示す図クライアント端末の版数情報を版数管理装置へ通知するために使用するSUBSCRIBEリクエストの具体例を示す図ダウンロード要求をクライアント端末へ通知するために使用するNOTIFYリクエストの具体例を示す図ＩＰ呼制御装置からクライアント端末へアップロード要求を通知するSUBSCRIBEリクエストの具体例を示す図クライアント端末からＩＰ呼制御装置へ送信するNOTIFYリクエストの具体例を示す図

符号の説明

１０ＳＩＰ端末側システム
１１ＩＰ電話
１２、４２、５２、６２ＬＡＮ
１３、４０、４３、４９、５４、６４ルータ
１４、５３、６３ゲートウェイ
１５ＶｏＩＰゲートウェイ
１６既存の交換装置
２０センター側システム
４１ＩＰ呼制御装置
４５アドレス情報データベース
４６データベース制御部
４７呼制御部
４８アプリ部
５１端末制御サーバ
６１ダウンロードサーバ

Claims

センターシステムが端末に対するダウンロード要求を発生し、このダウンロード要求の発生を受けてＩＰ呼制御装置がアドレス情報データベースから端末のアドレス情報を取得し、このアドレス情報を用いて前記ＩＰ呼制御装置がＩＰ網経由で前記端末に接続してダウンロード要求を通知するＳＩＰ端末制御システム。
前記ＩＰ呼制御装置は、ＳＩＰメッセージを使用して前記端末に接続し、当該端末に対してダウンロード要求を通知すると共にダウンロードサーバのアドレス情報を通知することを特徴とする請求項１記載のＳＩＰ端末制御システム。
センターシステムが端末に対するアップロード要求を発生し、このアップロード要求の発生を受けてＩＰ呼制御装置がアドレス情報データベースから端末のアドレス情報を取得し、このアドレス情報を用いて前記ＩＰ呼制御装置がＩＰ網経由で前記端末に接続してアップロード要求を通知することを特徴とするＳＩＰ端末制御システム。
前記ＩＰ呼制御装置は、ＳＩＰメッセージを使用して前記端末に接続し、当該端末にアップロード要求を通知すると共にアップロード先のアドレス情報を通知することを特徴とする請求項３記載のＳＩＰ端末制御システム。
センターシステムが端末に対する内部ソフトウエア又は環境ファイルのアップグレード要求を発生し、このアップグレード要求の発生を受けてＩＰ呼制御装置がアドレス情報データベースから端末のアドレス情報を取得し、このアドレス情報を用いて前記ＩＰ呼制御装置がＩＰ網経由で前記端末に接続してアップグレード要求を通知することを特徴とするＳＩＰ端末制御システム。
前記ＩＰ呼制御装置は、ＳＩＰメッセージを使用して前記端末に接続し、当該端末にアップグレード要求を通知すると共にダウンロードサーバのアドレス情報を通知することを特徴とする請求項５記載のＳＩＰ端末制御システム。
端末制御サーバがＩＰ電話機に対する留守番録音データファイルのアップロード要求を発生し、このアップロード要求の発生を受けてＩＰ呼制御装置がアドレス情報データベースから前記ＩＰ電話機のアドレス情報を取得し、このアドレス情報を用いて前記ＩＰ呼制御装置がＩＰ網経由で前記ＩＰ電話機に接続してアップロード要求及びアップロード先のアドレス情報を通知し、このアップロード要求を受けたＩＰ電話機がアップロード先に指定されたアップロードサーバへ留守番録音データファイルをアップロードすることを特徴とする留守番録音データファイルのアップロード方法。
端末制御サーバが発する端末に対するダウンロード要求を受け付けるステップと、この受け付けたダウンロード要求の通知先となる端末のアドレス情報を収容端末のアドレス情報データベースから取得するステップと、このアドレス情報を用いてＩＰ網経由で前記端末にＳＩＰメッセージを用いて接続してダウンロード要求を通知するステップと、を具備した通知方法。
端末制御サーバが発する端末に対するアップロード要求を受け付けるステップと、この受け付けたアップロード要求の通知先となる端末のアドレス情報を収容端末のアドレス情報データベースから取得するステップと、このアドレス情報を用いてＩＰ網経由で前記端末にＳＩＰメッセージを用いて接続してアップロード要求を通知するステップと、を具備した通知方法。
管理サーバが発する端末に対する内部ソフトウエア又は環境ファイルのアップグレード要求を受け付けるステップと、この受け付けたアップグレード要求の通知先となる端末のアドレス情報を収容端末のアドレス情報データベースから取得するステップと、このアドレス情報を用いてＩＰ網経由で前記端末にＳＩＰメッセージを用いて接続してアップグレード要求を通知するステップと、を具備した通知方法。