WO2010053064A1

WO2010053064A1 - アプリケーションサーバ、制御端末及び通信システム

Info

Publication number: WO2010053064A1
Application number: PCT/JP2009/068746
Authority: WO
Inventors: 真史新本
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2008-11-06
Filing date: 2009-11-02
Publication date: 2010-05-14
Anticipated expiration: 2011-05-06

Abstract

　通信端末２０ｃから被制御端末１５に接続要求がなされた場合、アプリケーションサーバ４０に対し、通信が許可されているか否かを問い合わせる。ここで、通信端末２０ｃのアクセス許否が、アプリケーションサーバ４０に登録されていない場合は、制御端末１０ａ及び制御端末１０ｂに対して、被制御端末１５に対する接続の許否を問い合わせる。これにより、ＰＮ内に複数の制御端末を配置し、複数の制御端末からＰＮのアクセス制御テーブルへの通信を許可／拒否する通信端末の登録手順と、ＰＮのアクセス制御テーブルに登録されていない通信端末から被制御通信へのアクセス時、複数の制御端末へ被制御端末へのアクセスの許否を問い合わせる手順を提供することとなり、利便性の高い、より高度な通信サービスを提供することができる。

Description

アプリケーションサーバ、制御端末及び通信システム

　本発明は、被制御端末と、他の通信端末から被制御端末への接続を制御する複数の制御端末とを含んで構成されるパーソナルネットワークと、ＳＩＰ（Session Initiation Protocol）に基づいたセッション制御を行う移動通信事業者ネットワークを介して前記パーソナルネットワークに接続する通信端末と、端末間のセッション接続を制御するセッション制御装置とを備えたネットワークシステムに接続されるアプリケーションサーバ等に関する。

　移動通信ネットワークにおいて、一人のユーザが所持する複数の通信端末／通信機器（以下、通信端末と記す）をグループとして管理し、このようなグループ化された複数の通信端末を利用して、高機能なサービスを提供するパーソナルネットワーク（以下、「ＰＮ」と記す）が近年提案されている。

　この、ＰＮ及びＰＮの管理方法、つまり、ＰＮＭ（Personal Network Management）の規格が、例えば非特許文献１に提案されている。

　非特許文献1には、ＰＮのサービスとして、ＰＮに属する通信端末のうち、制御する通信端末（制御端末）が、制御される通信端末（被制御端末）に対するアクセスの許否を制御するアクセス制御が規定されている。

　これにより、例えば、家庭の母親の所有する携帯電話端末と、子の所有する携帯電話端末をＰＮとして管理し、母親の所有する携帯電話端末を制御端末とし、子の所有する携帯電話端末を被制御端末とする。これにより、子の所有する携帯電話端末へ発呼する発呼者に応じて、接続の許否を母親の携帯電話端末で制御することができる。したがって、見知らぬ人からの子への発信や不必要と判断する人からの発信を制限することができ、安全な通信環境を提供することができる。

　さらに、非特許文献２では、非特許文献１を基に、制御メッセージの詳細を定めている。具体的には、ＰＮ内の制御端末からネットワーク内部のアクセス管理装置への、ＨＴＴＰに基づいた制御情報の構成や、発呼者からアクセス管理装置を経由して、被制御端末と送受信するＳＩＰに基づいたセッション情報の構成が記されている。ここで、アクセス管理装置は、アクセス制御テーブルを用いることにより、通信の許可／拒否を管理することとなる。

　ここで、従来のＰＮのアクセス制御について、図１３、図１４を用いて説明する。図１３は、従来のＰＮのアクセス制御を行うネットワークシステムの概略である。ネットワークには、ＰＮを管理するためのアプリケーションサーバ７０と、各通信端末のセッションの制御を行うセッション制御装置７２とが配置されている。

　また、パーソナルネットワーク（ＰＮ）に、通信端末８０ａ、８０ｂ及び８０ｃが属している、また、ＰＮに属している通信端末と通信を行う端末は、通信端末９０及び９２である。

　また、各通信端末にはＳＩＰ　ＵＲＬが割り当てられている。本ネットワークシステムにおいては、通信端末８０ａに「user1_public80a@home1.net」が、通信端末８０ｂに「user1_public80b@home1.net」が、通信端末８０ｃに「user1_public80c@home1.net」が、通信端末９０に「user90_public@home1.net」が、通信端末９２に「user92_public@home1.net」が、それぞれ割り当てられている。

　ここで、アプリケーションサーバ７０は、ＰＮの通信端末を管理するためのアクセス制御テーブルを記憶している。ここで、アプリケーションサーバ７０が記憶しているアクセス制御テーブルの一例を示したのが図１４である。

　図１４は、従来技術のＰＮのアクセス制御テーブルを示している。アクセス制御テーブルには、ＰＮに属する端末に対応づけて、被制御端末か否かを示す属性と、被制御端末を制御する制御端末と、許可端末及び拒否端末と登録するアクセスリストとが記憶されている。

　図１４のアクセス制御テーブルによれば、制御端末は通信端末８０ａとなり、被制御端末は通信端末８０ｃである。すなわち、通信端末８０ｃ（user1_public80c@home1.net）は被制御端末の属性が「Ｙｅｓ」であり、制御端末として「ＵＥ８０ａ（通信端末８０ａ）」と記憶されている。したがって、ＰＮ以外からの通信端末から通信端末８０ｃへのアクセスに対する許否を通信端末８０ａが制御することを表している。

　ここで、アクセスリストを参照すると、アクセスを許可する端末として「user90_public@home2.net」（通信端末９０）が、アクセスを拒否する端末として「user92_public@home3.net」が登録されている。

　なお、アクセスリストに登録されていない端末から通信端末８０ｃ（被制御端末）へアクセスがあった場合は、一度通信端末８０ａ（制御端末）に問い合わせを行い、通信の許否が判断された後に、当該結果に応じて通信が許可又は拒否される。

３ＧＰＰ　ＴＳ　２３．２５９（Personal Network Management（PNM）；Procedures and Information Flows）; Stage2 ３ＧＰＰ　ＴＳ　２４．２５９（Personal Network Management（PNM）；Stage3

　従来技術では、ＰＮに属する通信端末のうち、被制御端末は複数とすることはできるが、制御端末は１台のみで、複数の制御端末がＰＮの被制御端末へのアクセス制御をすることはできなかった。

　したがって、制御端末をＰＮに複数配置したとしても、複数の制御端末からＰＮのアクセス制御テーブルへの通信を許可／拒否する通信端末の登録手順が規定されていないため、実現することはできなかった。

　さらに、ＰＮのアクセス制御テーブルに登録されていない通信端末から制御端末へのアクセス時、複数の制御端末へ被制御端末へのアクセスの許否を問い合わせる手順も規定されておらず、複数の制御端末からどの端末を優先して問い合わせるか、制御端末からの応答が異なる場合にどの応答に基づいて制御するかなどの規定がないため、ＰＮに複数の制御端末を配置することはできないといった問題点があった。

　ここで、従来技術の組み合わせとして、被制御端末が複数のＰＮに属することにより、制御端末を複数にする方法が考えられる。例えば、被制御端末が２つのＰＮに属すれば、ＰＮ毎に一台の制御端末があるため、被制御端末に対して２台の制御端末とすることができる。しかしながら、図１４の管理テーブルに示すとおり、端末を識別するＳＩＰ　ＵＲＩは、ＰＮ毎に異なるドメインを持つため、制御端末となる通信端末が２つのＰＮに属する場合には、「user1_public2@home1.net」と、「user1_public2@anotherpn.net」と２つのＳＩＰ　ＵＲＩを持つ必要がある。ＰＮとＳＩＰ　ＵＲＬは１対１に対応しているため、ＰＮ以外の通信端末が制御端末にアクセスする場合、結果としてＰＮに対応する同一の制御端末にアクセスする必要があるため、上述した問題点を解消することはできなかった。

　これらにより、以下のような不都合が生じていた。例えば、家族の携帯端末でＰＮを構成している場合、制御端末が１台の場合は、母親の携帯端末でしかＰＮのアクセス制御テーブルを更新することができず、父親の携帯端末でアクセス制御テーブルを更新するといったことができなかった。また、単一のユーザが複数の通信端末を所有してＰＮを構成している場合に、いずれかの端末からアクセス制御テーブルを更新しようとしても、必ず決められた制御端末を利用しなければならず、利便性が良いとはいえなかった。

　さらに、制御端末が一台しかない場合、テーブルに登録されていない通信端末からのアクセスに対する問い合わせを受けた制御端末のユーザが、手元に端末がないなどのなんらかの理由により応答できないだけで、通信端末からは被制御端末へのアクセスができなくなってしまうといった問題点もあった。

　上述した課題に鑑み、本発明が目的とするところは、ＰＮ内に複数の制御端末を配置し、複数の制御端末からＰＮのアクセス制御テーブルへの通信を許可／拒否する通信端末の登録手順と、ＰＮのアクセス制御テーブルに登録されていない通信端末から被制御通信へのアクセス時、複数の制御端末へ被制御端末へのアクセスの許否を問い合わせる手順を提供することにより、利便性の高い、より高度な通信サービスを実現するアプリケーションサーバ等を提供することを目的とする。

　上述した課題に鑑み、本発明のアプリケーションサーバは、被制御端末と、他の通信端末から被制御端末への接続を制御する複数の制御端末とを含んで構成されるパーソナルネットワークと、ＳＩＰ（Session Initiation Protocol）に基づいたセッション制御を行う移動通信事業者ネットワークを介して前記パーソナルネットワークに接続する通信端末と、端末間のセッション接続を制御するセッション制御装置とを備えたネットワークシステムに接続されるアプリケーションサーバであって、前記被制御端末に対応づけて、複数の制御端末と、接続を許可する通信端末とが登録されているアクセス制御テーブルと、前記通信端末から、被制御端末への接続要求を受信する接続要求受信手段と、前記接続要求受信手段により受信された接続要求を行う通信端末が、前記アクセス制御テーブルに接続を許可する端末と登録されていない場合は、被制御端末に対応する複数の制御端末に接続の許否を問い合わせる問い合わせ手段と、前記複数の制御端末から、通信端末と被制御端末との接続の許否の結果を受信し、接続の許否を判定する接続許否判定手段と、を備えることを特徴とする。

　また、本発明のアプリケーションサーバにおいて、前記接続許否判定手段は、複数の制御端末のうち、一の制御端末から接続許可の結果を受信した場合には、前記通信端末と前記被制御端末との接続を許可したと判定することを特徴とする。

　また、本発明のアプリケーションサーバにおいて、前記接続許否判定手段は、複数の制御端末のうち、総ての制御端末から接続許可の結果を受信した場合に、前記通信端末と前記被制御端末との接続を許可したと判定することを特徴とする。

　また、本発明のアプリケーションサーバにおいて、前記問い合わせ手段は、複数の制御端末に接続の許否を問い合わせる場合に、制御端末に対して一斉に問い合わせを行うことを特徴とする。

　また、本発明のアプリケーションサーバにおいて、前記問い合わせ手段は、複数の制御端末に接続の許否を問い合わせる場合に、一の制御端末に対して問い合わせた結果、タイムアウトとなった場合に他の制御端末に問い合わせを行うことを特徴とする。

　本発明の制御端末は、被制御端末と、他の通信端末から被制御端末への接続を制御する複数の制御端末とを含んで構成されるパーソナルネットワークと、ＳＩＰ（Session Initiation Protocol）に基づいたセッション制御を行う移動通信事業者ネットワークを介して前記パーソナルネットワークに接続する通信端末と、端末間のセッション接続を制御するセッション制御装置と、該パーソナルネットワークを管理するアプリケーションサーバとを含む通信システムに用いられる制御端末において、前記アプリケーションサーバから、前記通信端末と、前記被制御端末とのアクセス制御要求を受信するアクセス制御要求受信手段と、前記アクセス制御要求に基づいて、前記通信端末と、前記被制御端末との接続許否を判断し、判断結果を送信する判断結果送信手段と、を備えることを特徴とする。

　本発明の通信システムは、被制御端末と、他の通信端末から被制御端末への接続を制御する複数の制御端末とを含んで構成されるパーソナルネットワークと、ＳＩＰ（Session Initiation Protocol）に基づいたセッション制御を行う移動通信事業者ネットワークを介して前記パーソナルネットワークに接続する通信端末と、端末間のセッション接続を制御するセッション制御装置と、該パーソナルネットワークを管理するアプリケーションサーバとを含む通信システムにおいて、前記アプリケーションサーバは、前記被制御端末に対応づけて、複数の制御端末と、接続を許可する通信端末とが登録されているアクセス制御テーブルと、前記通信端末から、被制御端末への接続要求を受信する接続要求受信手段と、前記接続要求受信手段により受信された接続要求を行う通信端末が、前記アクセス制御テーブルに接続を許可する端末と登録されていない場合は、被制御端末に対応する複数の制御端末に接続の許否を問い合わせる問い合わせ手段と、前記複数の制御端末から、通信端末と被制御端末との接続の許否の結果を受信し、接続の許否を判定する接続許否判定手段と、を備え、前記制御端末は、前記アプリケーションサーバから、前記通信端末と、前記被制御端末とのアクセス制御要求を受信するアクセス制御要求受信手段と、前記アクセス制御要求に基づいて、前記通信端末と、前記被制御端末との接続許否を判断し、判断結果を送信する判断結果送信手段と、を備えることを特徴とする。

　本発明によれば、ＰＮ内に複数の制御端末を配置し、複数の制御端末からＰＮのアクセス制御テーブルへの通信を許可／拒否する通信端末の登録と、ＰＮのアクセス制御テーブルに登録されていない通信端末から被制御通信への通信要求のとき、複数の制御端末へ被制御端末への通信の許否を問い合わせることが可能になり、複数の制御端末が被制御端末のアクセス制御を行うことが可能となり、より高機能な通信システムを構築できる。

本実施形態におけるネットワークシステムの概略を説明する為の図である。本実施形態におけるＰＮアクセス制御情報の設定手順を説明するための図である。本実施形態におけるアクセス制御テーブルの一例を示す図である。本実施形態におけるアクセス制御テーブルの一例を示す図である。本実施形態におけるＰＮアクセス制御情報の設定手順を説明するための図である。第１実施例における処理の流れを説明するための図である。第１実施例におけるアプリケーションサーバの処理を説明するための図である。第２実施例における処理の流れを説明するための図である。第２実施例におけるアプリケーションサーバの処理を説明するための図である。第３実施例における処理の流れを説明するための図である。第３実施例におけるアプリケーションサーバの処理を説明するための図である。第３実施例におけるアプリケーションサーバの処理を説明するための図である。従来におけるネットワークシステムの概略を説明する為の図である。従来におけるアクセス制御テーブルの一例を示す図である。

　以下添付図面を参照しながら、本発明の実施の形態について説明し、本発明の理解に供する。尚、以下の実施の形態は、本発明を具体化した一例であって、本発明の技術的範囲を限定する性格のものではない。

　〔実施の形態〕
　［１．ネットワーク構成］
　図１は、本発明を適用した場合におけるネットワークシステムの概略を説明するための図である。ネットワークシステムの中には、パーソナルネットワーク（ＰＮ）が構築されており、複数の通信端末が接続されている。そして、パーソナルネットワークには、制御する通信端末である制御端末１０（制御端末１０ａ及び１０ｂ）と、制御端末により制御される通信端末である被制御端末１５とが接続されている。また、各通信端末のセッション制御を行うセッション制御装置３０が配置されており、ＰＮに配置された通信端末と、通信端末２０（通信端末２０ａ、２０ｂ及び２０ｃ）とが接続されている。また、セッション制御装置３０は、アプリケーションサーバ４０に接続されている。

　ここで、制御端末１０、被制御端末１５、通信端末２０は、ＵＳＩＭカード（Universal Subscriber Identity Module Card）が装着可能な携帯端末、例えば、携帯電話機、ＰＤＡ（Personal Digital Assistant）である。制御端末１０及び被制御端末１５はグループとして管理されるパーソナルネットワーク（ＰＮ）を構成する。ＰＮの端末は、それぞれを識別する識別子を持ち、識別子をグループとして管理する。識別子にＳＩＰ　ＵＲＩを利用した例では、ＰＮの端末は等しいドメインで表され（home1.net）、グループを構成することとなる。

　セッション制御装置３０は、各通信端末間（通信端末２０、制御端末１０及び被制御端末１５）のセッション制御を行う。例えば、ＳＩＰプロトコルを用いたセッション制御を行うＳＩＰサーバ等であり、通信端末間の接続の確立及び当該接続の確立から当該確立した接続を切断するまでに実行される通信端末間のセッション情報は、セッション制御装置３０を介して実行される。

　アプリケーションサーバ４０は、制御端末１０及び被制御端末１５の利用者に対して、高度なマルチメディア通信サービス等のアプリケーションサービスを提供する。具体的には、被制御端末１５と、通信端末２０との間の通信を拒否または許容するためのアクセス制御を行い、アクセス制御を実行するためにアクセス制御テーブルを記憶している。

　［２．ＰＮアクセス制御情報設定手続き］
　ここで、制御端末１０は、他の通信端末が、被制御端末１５へのアクセスする場合のアクセス制御を行うための情報（ＰＮアクセス制御情報）をアプリケーションサーバ４０に記憶する。ここで、ＰＮアクセス制御情報の設定手順を図２にもとづいて説明する。

　図２は、制御端末１０ａと、制御端末１０ｂと、アプリケーションサーバ４０との処理手順を示す図である。

　まず、制御端末１０ａから、制御端末と、被制御端末との指定と、被制御端末１５に対するアクセスの許否を設定する通信端末の情報をアプリケーションサーバ４０に通知し、ＰＮアクセス設定情報の設定を要求する（ステップＳ１００）。なお、制御端末１０ａは予めアプリケーションサーバ４０の情報を記憶しているものとする。

　図２においては、制御端末１０ａ、被制御端末１５とし、通信端末２０ａから被制御端末１５に対する通信を許可する設定とする。また、制御端末１０ａからアプリケーションサーバ４０に通知する情報は、具体的な例としては、識別情報は「ＳＩＰ　ＵＲＩ」であり、アプリケーションサーバ４０のＵＲＩに対して、ＨＴＴＰなどの通知手段を用いて情報の送受信を行う。本実施形態の登録では、制御端末１０ａは、被制御端末１５の通信端末２０ａからの通信を許可するように登録する。

　つぎに、アプリケーションサーバ４０は、ＰＮアクセス制御設定要求に基づいて、アクセス制御テーブルを更新する（ステップＳ１０２）。この場合、被制御端末１５に対する制御端末として、制御端末１０ａが登録されているために、ステップＳ１０２においてアクセス制御テーブルが更新されることとなる。

　ここで、本実施形態におけるアクセス制御テーブルを示した図が、図３（ａ）である。図３（ａ）に示すように、アクセス制御テーブルは、ＰＮに配置された通信端末に対応づけて、被制御端末及び制御端末との設定と、アクセスリストとを記憶している。そして、ステップＳ１００により送信されたＰＮアクセス設定要求に含まれる内容から更新された状態を示すのが図３（ｂ）である。ステップＳ１００において、通信端末２０ａを「許可」と受信したところから、アクセスリストの「許可」の欄に通信端末が（user2_public@home2.net）記憶される。

　なお、アプリケーションサーバ４０は、制御端末１０ａ及び制御端末１０ｂが制御端末であることを把握している。アプリケーションサーバ４０は、ＰＮに対して複数の制御端末を保持することができるとともに、被制御端末毎に、被制御端末に対する制御端末を複数保持することができる。

　つづいて、アプリケーションサーバ４０は、アクセス制御テーブルの更新後、制御端末１０ａにＰＮアクセス制御情報設定応答を送信する（ステップＳ１０４）。すなわち、これにより制御端末１０ａに、アクセス制御テーブルが更新されたことが通知される。通知手段としては、ＨＴＴＰに基づいてステップＳ１００の要求に対して応答する。

　つづいて、制御端末１０ｂは、制御端末１０ａと同様の手段で、被制御端末１５への通信端末２０ｂからの通信を却下するよう登録する（ステップＳ１０６）。すなわち、ＰＮアクセス制御情報設定として、「制御端末１０ｂ」、「被制御端末１５」として、通信端末として「通信端末２０ｂ（拒否）」を送信する。

　アプリケーションサーバ４０は、ステップＳ１０２と同様の手順で、被制御端末１５に対しての通信端末２０ｂからの通信を拒否するよう、アクセスリストに通信端末２０ｃを登録して、アクセス制御テーブルを更新する（ステップＳ１０８）。この場合、被制御端末１５に対する制御端末として、制御端末１０ｂが登録されているために、ステップＳ１０８においてアクセス制御テーブルが更新されることとなる。ここで、更新されたアクセス制御テーブルの一例を図４に示す。

　アプリケーションサーバ４０は、アクセス制御テーブルの更新後、制御端末１０ｂにＰＮアクセス制御情報設定応答を送信する（ステップＳ１１０）。すなわち、これにより制御端末１０ｂに、アクセス制御テーブルが更新されたことが通知される。

　なお、ステップＳ１０８において、制御端末１０ｂが、ステップＳ１００の手順で制御端末１０ａが要求した内容と競合する設定を要求した場合、本実施形態においては、後から受信された情報の更新を行うこととする。例えば、制御端末１０ｂが被制御端末１５に対する通信端末２０ａからの通信を拒否するよう要求した場合、通信端末２０ａを許可するアクセスリストから削除し、拒否するアクセスリストに更新する。

　また、アプリケーションサーバ４０が、被制御端末１５の制御端末が制御端末１０ａ及び制御端末１０ｂであるよう情報を保持するために、制御端末からアプリケーションサーバ４０へ登録する。

　この登録は、制御端末１０ａがアプリケーションサーバに、被制御端末１５に対する制御端末が制御端末１０ａと通知し、制御端末１０ｂがアプリケーションサーバに被制御端末１５に対する制御端末が制御端末１０ｂと通知するなどの個別に行うこともできるし、図５に示すように、被制御端末１５に対する制御端末が制御端末１０ａ及び制御端末１０ｂであると複数の制御端末を登録することもできる。

　すなわち、図５のステップＳ１３０に示す用に、制御端末１０ａからアプリケーションサーバ４０に送信されるＰＮアクセス制御情報設定要求において、制御端末１０ａ及び制御端末１０ｂが、被制御端末１５の制御端末であると送信する。これにより、アクセス制御テーブルへ登録され（ステップＳ１３２）、ＰＮアクセス制御情報設定応答がアプリケーションサーバ４０から、制御端末１０ａに送信される（ステップＳ１３４）。

　なお、アプリケーションサーバ４０は、制御端末１０ａが図３（ａ）のアクセス制御テーブルにおいて、制御端末として登録されていることから、ステップＳ１３０から要求を受け入れ、ステップＳ１３２においてアクセス制御テーブルが更新されることとなる。また、本実施形態においては、登録に関する処理について説明しているが、削除についても同様に説明できることはもちろんである。

　以上の手順により、アプリケーションサーバ４０は複数の制御端末１０からのアクセス制御情報を登録することができる。以下、具体的に通信端末から被制御端末へ通信が行われる場合の実施例について説明する。

　［３．実施例］
　［３．１　第１実施例］
　まず、図６を用いて、アクセス制御手続きの第１実施例を説明する。図６は、通信端末（通信端末２０ｃ）がＰＮの被制御端末１５へ接続を要求した場合の、手続きを示した図である。

　ここで、アプリケーションサーバ４０で管理するアクセス制御テーブルでは、図４に示すように、通信端末２０ｃは被制御端末１５に対するアクセスリストには許可／拒否のエントリが登録されていない通信端末である。また、セッション情報は、具体的にはＳＩＰプロトコルに基づいたメッセージを用いることができる。

　まず、通信端末２０ｃは被制御端末１５に対して接続の開始を要求するセッション情報（接続要求）をセッション制御装置３０に宛てに送信する（ステップＳ２００）。ここで、ステップＳ２００における通信先は被制御端末１５である。

　つづいて、セッション制御装置３０は、アクセス制御を行わない場合にはセッション情報をそのまま被制御端末１５へ送信するが、本実施例ではＰＮのアクセス制御を行うために、被制御端末１５にセッション情報を送信することなく、まずアプリケーションサーバ４０へＰＮアクセス接続要求をセッション情報として送信する（ステップＳ２０２）。

　続いて、アプリケーションサーバ４０は、受信したセッション情報（ＰＮアクセス接続要求）に基づいてアクセス制御処理を実行する。ここで、アプリケーションサーバ４０が実行するアクセス制御処理について、図７を用いて説明する。

　まず、アプリケーションサーバ４０が、ＰＮアクセス制御要求を受信すると（ステップＳ２５０）、ＰＮアクセス制御機能が有効か否かを判定する（ステップＳ２５２）。ここで、ＰＮアクセス制御機能が有効でない場合は、アクセス制御機能は動作せずに本処理を終了する。

　ここで、ＰＮアクセス制御機能が有効であるか否かは、例えば、アクセス制御テーブルに登録されている状態から判定しても良いし、ＰＮアクセス制御機能が有効か否かを別情報としてアプリケーションサーバ４０が管理していても良い。

　そして、ＰＮアクセス制御機能が有効である場合には（ステップＳ２５２；Ｙｅｓ）、要求が被制御端末に対するものか否かを判定する（ステップＳ２５４）。ここで、通信先の通信端末が、被制御端末に対するものでない場合は（ステップＳ２５４；Ｎｏ）、アクセス制御機能は動作せずに本処理を終了する。

　つづいて、被制御端末に対する要求の場合、通信元は許可する通信端末として登録されているか否かを判定する（ステップＳ２５６）。ここで、通信元が許可する端末として登録されていない場合は、制御端末に問い合わせる必要があるか否かを判定する（ステップＳ２５８）。

　ここで、制御端末に問い合わせるか否かは、アプリケーションサーバ４０の運用方針に基づいて決定するなど、なんらかの方法で決定する。また、本実施例では、制御端末への問い合わせを行う例を示すが、問い合わせを行わない場合には、接続要求（セッション開始の要求）は拒否する。拒否するには、セッション制御装置３０に拒否する旨を通知し、セッション制御装置３０は通信端末２０ｃへ拒否する旨を通知する（ステップＳ２５８；Ｎｏ→ステップＳ２６２）。

　具体的には、アクセスリストの「拒否」として通信元が登録されている場合、制御端末に問い合わせる必要が無いため、接続要求を拒否する。

　他方、制御端末に問い合わせる必要がある場合、例えば、被制御端末のアクセスリストに通信元が登録されていない場合、制御端末に接続の許否を問い合わせる処理を行う（ステップＳ２５８；Ｙｅｓ→ステップＳ２６０）。

　また、通信元が許可する通信端末としてアクセスリストに登録されている場合には（ステップＳ２５６；Ｙｅｓ）、接続要求を被制御端末に転送する（ステップＳ２６４）。

　なお、問い合わせ先となる制御端末が複数ある場合、アプリケーションサーバ４０は優先して問い合わせを行う制御端末を選択し、問い合わせを行う。優先順位の決定は、制御端末のユーザが決定し、ＰＮアクセス制御情報設定要求において、優先順位を決定するための情報を付加する。そして、アプリケーションサーバ４０は、アクセス制御テーブルにおいて、制御端末から通知された優先順位を含めて管理し、それに基づいて制御端末を選択する方法や、単にエントリされている制御端末を任意に選択する等種々の方法で決定する。本実施例では、まず制御端末１０ａから問い合わせを行うものとして説明する。
　ここで、図６の処理に戻り説明を続ける。アプリケーションサーバ４０は、セッション制御装置３０に制御端末１０ａへ問い合わせ要求を行う（ステップＳ２０６）。そのため、問い合わせ情報に制御端末１０ａへ送信することを記してセッション制御装置３０へ転送する。

　続いて、セッション制御装置３０は、アプリケーションサーバ４０から制御端末１０ａへ問い合わせ情報を送信する（ステップＳ２０８）。

　受信した制御端末１０ａは、通信端末２０ｃから被制御端末１５への通信の許否を判断する接続許否判断処理を実行する（ステップＳ２１０）。通信の許否の判断は、各制御端末のユーザの意思やネットワーク事業者の意向などを反映するなどのなんらかの方法で決定すればよい。本実施例においては、通信を許可した場合を以下で説明し、通信を却下する場合の動作は後述する。

　制御端末１０ａは、ステップＳ２１０における通信の許否を決定した結果（本実施例では「許可」とした結果）をセッション制御装置３０に通知する（ステップＳ２１２）。通知を受けたセッション制御装置３０は、アプリケーションサーバ４０に結果を転送する（ステップＳ２１４）。

　アプリケーションサーバ４０は、セッション制御装置３０から受信された結果に基づいて、接続判定／要求処理を実行する（ステップＳ２１６）。

　ここで、セッション制御装置３０から、接続を許可すると結果を受信している場合には、アクセス制御テーブルの被制御端末１５のアクセスリストに、通信端末２０ｃに対して通信を許可する端末として登録する。アプリケーションサーバ４０は、被制御端末１５へセッション開始要求をセッション制御装置３０へ送信する（ステップＳ２１８）。セッション制御装置３０は、接続要求（セッション開始要求）を被制御端末１５へ送信する（ステップＳ２２０）。

　以上の手続きで、通信端末２０ｃが送信した接続要求は、被制御端末である被制御端末１５へ到達する。その後の動作は、従来のセッション制御手続きに基づいて行い、通信端末２０ｃと被制御端末１５は通信を開始する。上記手続きで、従来と異なる点はステップＳ２０４において、アプリケーションサーバ４０は、複数の制御端末を情報として保持し、その中から選択をして問い合わせを行う点である。

　なお、ステップＳ２１０の接続許否判定処理において、通信を却下する場合について説明する。ＰＮアクセス制御要求を受信した制御端末１０ａは、通信端末２０ｃから被制御端末１５への通信の許否を判定する接続許否判定処理を実行し、接続をしないと判定した結果を、セッション制御装置３０に通知する（ステップＳ２１２）。そして、セッション制御装置３０から、アプリケーションサーバ４０に対し、通信を許可しないという結果をアプリケーションサーバ４０に転送する（ステップＳ２１４）。

　アプリケーションサーバ４０は、接続判定／要求処理において、接続却下処理を実行する（ステップＳ２１６）。具体的には、アプリケーションサーバ４０から、セッション制御装置３０へ切断要求を送信する。セッション制御装置３０は、アプリケーションサーバ４０からの切断要求に応じ、通信端末２０ｃへ切断要求を送信することとなる。

　［３．２　第２実施例］
　続いて、図８を用いて第２実施例を説明する。第２実施例は、第１実施例と同様に、通信端末（通信端末２０ｃ）がＰＮの被制御端末（被制御端末１５）へ通信を開始する際の、通信開始を要求する接続要求（セッション開始要求）が、通信端末２０ｃから被制御端末１５へ届くまでの手続きを示している。

　アプリケーションサーバ４０で管理するアクセス制御テーブルにおいても、第１実施例と同様に、図４に示すように通信端末２０ｃは被制御端末１５に対してアクセスリストには許可／拒否のエントリが無い通信端末である。

　第２実施例では、第１実施例のステップＳ２０８での制御端末への問い合わせに対して、制御端末からの応答を受信しなかった場合の処理について示す。第１実施例と同様に、セッション情報は、具体的にはＳＩＰプロトコルに基づいたメッセージを用いることができる。

　制御端末からの応答を受信できない状況は、制御端末のユーザの手元に端末がないことや、ユーザの状況に応じて端末を操作できないなど、日常において容易に起こりうる。このような場合においても、複数の制御端末を備えることで、アプリケーションサーバが応答を受信できない可能性を下げることができる。

　以下では、図８をもとに手続きを説明する。ただし、ステップＳ３００からＳ３０８までは、前述した第１実施例のステップＳ２００からＳ２０８までと同様であるため省略する。

　アプリケーションサーバ４０は、タイマーを管理し、問い合わせ送信から一定時間応答を待った後に、応答を受信しなかった場合には、アクセス制御テーブルから他の制御端末を選択して問い合わせを行う（ステップＳ３１０）。

　問い合わせ先となる制御端末が複数ある場合は、応答を受信することができなかった制御端末以外の制御端末のうち、優先して問い合わせを行う制御端末を選択し、問い合わせを行う。優先順位の決定は、第１実施例のステップＳ２０６と同様に、ＰＮアクセス制御情報設定時に、制御端末からの設定に決定し、それに基づいて選択することや、単にエントリされている制御端末を任意に選択するなどで決定する。本実施例では、制御端末１０ａの次の端末として、制御端末１０ｂへの問い合わせを行う。

　ここで、第１実施例の図６のステップＳ２０６からＳ２２０が制御端末１０ａを制御端末として問い合わせを行い、セッション情報を被制御端末１５へ送信するのに対して、図８のステップＳ３１２からＳ３２６は、制御端末が制御端末１０ｂであるだけの違いであり、処理は同様であるため説明は省略する。

　ここで、上記の図８のステップＳ３１０の処理を含んで、アプリケーションサーバ４０が制御端末への問い合わせを行った場合の処理（アクセス制御処理及び接続判定／要求処理）について、図９の処理のフローをもちいて説明する。

　アプリケーションサーバ４０は、制御端末を選択し、問い合わせを要求する（ステップＳ３５０）。ここで、問い合わせを要求した端末から、応答を受信しなかった場合には（ステップＳ３５２；Ｎｏ）、タイムアウトか否かを判定する（ステップＳ３５４）。ここで、タイムアウトでない場合、すなわち所定時間経過していない場合は、端末からの応答の受信を更に行う（ステップＳ３５４；Ｎｏ→ステップＳ３５２）。

　ここで、所定時間が経過することにより、タイムアウトとなった場合には（ステップＳ３５４；Ｙｅｓ）、再選択出来る制御端末があるか否かを判定する（ステップＳ３５６）。ここで、再選択出来る制御端末がある場合には（ステップＳ３５６；Ｙｅｓ）、制御端末を変えて問い合わせ要求を行い、新たな制御端末からの応答の受信を待機する（ステップＳ３５８→ステップＳ３５２）。

　他方、再選択できる制御端末が無い場合は、通信元からの接続要求を拒否する（ステップＳ３５６；Ｎｏ→ステップＳ３６４）。

　また、制御端末から応答を受信した場合（ステップＳ３５２；Ｙｅｓ）、通信元が許可されているか否かを判定する（ステップＳ３６０）。ここで、通信元が許可されている場合には、接続要求を被制御端末に送信し（ステップＳ３６０；Ｙｅｓ→ステップＳ３６２）、通信元が許可されていない場合は接続要求を拒否する（ステップＳ３６０；Ｎｏ→ステップＳ３６４）。

　［３．３　第３実施例］
　続いて、図１０を用いてアクセス制御手続きの第３実施例を説明する。第３実施例においても、第１実施例と同様に、通信端末（通信端末２０ｃ）がＰＮの被制御端末（被制御端末１５）へ通信を開始する際の、通信開始を要求する接続要求（セッション情報）が、通信端末２０ｃから被制御端末１５へ届くまでの手続きを示している。

　アプリケーションサーバ４０で管理するアクセス制御テーブルにおいても、第１実施例と同様に、図４に示すように通信端末２０ｃは被制御端末１５に対してアクセスリストには許可／拒否のエントリが無い通信端末である。第１実施例と同様に、セッション情報は、具体的にはＳＩＰプロトコルに基づいたメッセージを用いることができる。

　第３実施例が第１実施例と異なるのは、第１実施例のステップＳ２０８で単一の制御端末へ問い合わせを行うのに対して、複数の制御端末へ一斉に問い合わせを行う点である。

　図１０のステップＳ４００、Ｓ４０２によりアプリケーションサーバ４０が通信端末２０ｃからの接続要求を受信するまでの処理は、第１実施例で説明した図６のステップＳ２００、Ｓ２０２と同様であるため説明は省略する。

　アプリケーションサーバは、ＰＮアクセス接続要求を受信すると、アクセス制御処理を実行する（ステップＳ４０４）。ここで、アクセス制御処理として、第１実施例と異なるのは、制御端末への問い合わせが必要になった場合、図４に示すアクセス制御テーブルに登録されるすべての制御端末に対して問い合わせ行うための問い合わせ要求をセッション制御装置３０へ送信する。

　本実施例では通信端末２０ｃが通信開始を要求する被制御端末１５の制御端末である制御端末１０ａに対する問い合わせ要求（ステップＳ４０６）と、制御端末１０ｂに対する問い合わせ要求（ステップＳ４０８）とを送信する。図１０ではそれぞれの制御端末に対して個別の問い合わせ要求をセッション制御装置３０へ送信したが、複数の制御端末への問い合わせの要求を単一の問い合わせ要求メッセージで送信することとしても良い。

　その後、制御端末１０ａへの問い合わせから応答までの手続きは、ステップＳ４１０、Ｓ４１４、Ｓ４１６，Ｓ４１８で行われ、制御端末１０ｂへの問い合わせから応答までの手続きは、ステップＳ４１２，Ｓ４１４，Ｓ４２０，Ｓ４２２で行われる。それぞれの問い合わせて続きは、制御端末が異なるのみで処理は第１実施例のステップＳ２０６からＳ２１４と同様に行われるため、説明は省略する。

　また、結果が転送された後に、接続判定／要求処理を実行し（ステップＳ４２４）、セッション制御装置３０に接続要求をし（ステップＳ４２６）、当該セッション制御装置３０から被制御端末１５に接続要求がされる（ステップＳ４２８）のは、第１実施例における図６のステップＳ２１６～Ｓ２２０と同様の処理が実行される。

　ここで、上記の図１０のステップＳ４０４の処理を含んで、アプリケーションサーバ４０が制御端末への問い合わせを行った場合の処理（アクセス制御処理及び接続判定／要求処理）について、図１１の処理のフローを利用して説明する。

　まず、アプリケーションサーバ４０は、複数の制御端末に問い合わせ要求を送信する（ステップＳ４５０）。ここで、問い合わせ要求を送信した制御端末から応答を受信する（ステップＳ４５２）。

　制御端末から応答を受信したら（ステップＳ４５２；Ｙｅｓ）、通信元が「拒否」する端末として設定されているか否かを判定する（ステップＳ４５４）。ここで、「拒否」の場合には（ステップＳ４５４；Ｙｅｓ）、接続要求を拒否する（ステップＳ４６０）。

　他方、ステップＳ４５４において、通信元が「許可」の場合には、総ての制御端末から応答を受信したか否か判定する（ステップＳ４５４；Ｎｏ→ステップＳ４５６）。ここで、まだ未応答の制御端末がある場合には、ステップＳ４５２に処理を移行し、残りの制御端末からの応答を受信する（ステップＳ４５６；Ｎｏ→ステップＳ４５２）。他方、総ての制御端末から「許可」と応答されている場合には、送信要求を被制御端末１５に送信する（ステップＳ４５６；Ｙｅｓ→ステップＳ４５８）。

　ここで、ステップＳ４５２において、制御端末から応答を受信していない場合、応答待ちとしてタイムアウトが発生したか否かを判定する（ステップＳ４５２；Ｎｏ→ステップＳ４６２）。タイムアウトが発生していなければ、そのまま制御端末から応答を受信する処理を継続する（ステップＳ４６２；Ｎｏ→ステップＳ４５２）。

　ここで、タイムアウトが発生した場合（ステップＳ４６２；Ｙｅｓ）、制御端末から応答を受信しているか否かを判定する。ここで、応答を受信している場合には、送信要求を被制御端末１５に送信する（ステップＳ４６４；Ｙｅｓ→ステップＳ４６６）。他方、制御端末から全く応答を受信していない場合には、送信要求を拒否する（ステップＳ４６４；Ｎｏ→ステップＳ４６８）。

　なお、アプリケーションサーバ４０は、複数の制御端末のうち、一方が通信を許可し、他方が通信を却下するように、異なる結果を応答した場合、通信却下を優先して要求を却下することとしたが、異なる結果を応答した場合、通信許可を優先することもできる。どちらを優先するかは運用者があらかじめ決定するなどなんらかの方法で決定する。

　通信許可を優先する場合のアプリケーションサーバ４０の処理について、図１２を用いて説明する。まず、アプリケーションサーバ４０は、複数の制御端末に問い合わせ要求を送信する（ステップＳ５００）。ここで、問い合わせ要求を送信した制御端末から応答を受信する（ステップＳ５０２）。

　制御端末から応答を受信したら（ステップＳ５０２；Ｙｅｓ）、通信元が「許可」する端末として設定されているか否かを判定する（ステップＳ５０４）。ここで、「許可」の場合には（ステップＳ５０４；Ｙｅｓ）、接続要求を送信する（ステップＳ５１０）。

　他方、ステップＳ５０４において、通信元が「拒否」の場合には、総ての制御端末から応答を受信したか否か判定する（ステップＳ５０４；Ｎｏ→ステップＳ５０６）。ここで、まだ未応答の制御端末がある場合には、ステップＳ５０２に処理を移行し、残りの制御端末からの応答を受信する（ステップＳ５０６；Ｎｏ→ステップＳ５０２）。他方、総ての制御端末から「拒否」と応答されている場合には、送信要求を拒否する（ステップＳ５０６；Ｙｅｓ→ステップＳ５０８）。

　ここで、ステップＳ５０２において、制御端末から応答を受信していない場合、応答待ちとしてタイムアウトが発生したか否かを判定する（ステップＳ５０２；Ｎｏ→ステップＳ５１２）。タイムアウトが発生していなければ、そのまま制御端末から応答を受信する処理を継続する（ステップＳ５１２；Ｎｏ→ステップＳ５０２）。

　ここで、タイムアウトが発生した場合（ステップＳ５１２；Ｙｅｓ）、送信要求を拒否する（ステップＳ５１２；Ｎｏ→ステップＳ５１４）。

　このように、第３実施例では、第１実施例及び第２実施例とは異なり、複数の制御端末に一斉に問い合わせを行う。これにより、アプリケーションサーバは、制御端末からの応答結果を決定するための処理をあらたに必要とするが、第２実施例のように順に制御端末への問い合わせを行うより場合に比べて早く結果を決定することが可能となる。

　［４．変形例］
　以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も特許請求の範囲に含まれる。

　また、上述した実施形態において、例えば制御端末に優先度を付し、優先度の高い端末から接続許否判断処理を実行することとしてもよい。この場合、例えば、ＰＮにおいて「母親」と「父親」の制御端末があるとした場合、優先度の高い端末を「母親」の端末、優先度の低い端末を「父親」の端末にするといった利用方法が考えられる。

１０ａ、１０ｂ　制御端末
１５　被制御端末
２０ａ、２０ｂ、２０ｃ　通信端末
３０　セッション制御装置
４０　アプリケーションサーバ

Claims

　被制御端末と、他の通信端末から被制御端末への接続を制御する複数の制御端末とを含んで構成されるパーソナルネットワークと、ＳＩＰ（Session Initiation Protocol）に基づいたセッション制御を行う移動通信事業者ネットワークを介して前記パーソナルネットワークに接続する通信端末と、端末間のセッション接続を制御するセッション制御装置とを備えたネットワークシステムに接続されるアプリケーションサーバであって、
　前記被制御端末に対応づけて、複数の制御端末と、接続を許可する通信端末とが登録されているアクセス制御テーブルと、
　前記通信端末から、被制御端末への接続要求を受信する接続要求受信手段と、
　前記接続要求受信手段により受信された接続要求を行う通信端末が、前記アクセス制御テーブルに接続を許可する端末と登録されていない場合は、被制御端末に対応する複数の制御端末に接続の許否を問い合わせる問い合わせ手段と、
　前記複数の制御端末から、通信端末と被制御端末との接続の許否の結果を受信し、接続の許否を判定する接続許否判定手段と、
　を備えることを特徴とするアプリケーションサーバ。
　前記接続許否判定手段は、複数の制御端末のうち、一の制御端末から接続許可の結果を受信した場合には、前記通信端末と前記被制御端末との接続を許可したと判定することを特徴とする請求項１に記載のアプリケーションサーバ。
　前記接続許否判定手段は、複数の制御端末のうち、総ての制御端末から接続許可の結果を受信した場合に、前記通信端末と前記被制御端末との接続を許可したと判定することを特徴とする請求項１に記載のアプリケーションサーバ。
　前記問い合わせ手段は、複数の制御端末に接続の許否を問い合わせる場合に、制御端末に対して一斉に問い合わせを行うことを特徴とする請求項１から３の何れか一項に記載のアプリケーションサーバ。
　前記問い合わせ手段は、複数の制御端末に接続の許否を問い合わせる場合に、一の制御端末に対して問い合わせた結果、タイムアウトとなった場合に他の制御端末に問い合わせを行うことを特徴とする請求項１から３の何れか一項に記載のアプリケーションサーバ。
　被制御端末と、他の通信端末から被制御端末への接続を制御する複数の制御端末とを含んで構成されるパーソナルネットワークと、ＳＩＰ（Session Initiation Protocol）に基づいたセッション制御を行う移動通信事業者ネットワークを介して前記パーソナルネットワークに接続する通信端末と、端末間のセッション接続を制御するセッション制御装置と、該パーソナルネットワークを管理するアプリケーションサーバとを含む通信システムに用いられる制御端末において、
　前記アプリケーションサーバから、前記通信端末と、前記被制御端末とのアクセス制御要求を受信するアクセス制御要求受信手段と、
　前記アクセス制御要求に基づいて、前記通信端末と、前記被制御端末との接続許否を判断し、判断結果を送信する判断結果送信手段と、
　を備えることを特徴とする制御端末。
　被制御端末と、他の通信端末から被制御端末への接続を制御する複数の制御端末とを含んで構成されるパーソナルネットワークと、ＳＩＰ（Session Initiation Protocol）に基づいたセッション制御を行う移動通信事業者ネットワークを介して前記パーソナルネットワークに接続する通信端末と、端末間のセッション接続を制御するセッション制御装置と、該パーソナルネットワークを管理するアプリケーションサーバとを含む通信システムにおいて、
　前記アプリケーションサーバは、
　前記被制御端末に対応づけて、複数の制御端末と、接続を許可する通信端末とが登録されているアクセス制御テーブルと、
　前記通信端末から、被制御端末への接続要求を受信する接続要求受信手段と、
　前記接続要求受信手段により受信された接続要求を行う通信端末が、前記アクセス制御テーブルに接続を許可する端末と登録されていない場合は、被制御端末に対応する複数の制御端末に接続の許否を問い合わせる問い合わせ手段と、
　前記複数の制御端末から、通信端末と被制御端末との接続の許否の結果を受信し、接続の許否を判定する接続許否判定手段と、
　を備え、
　前記制御端末は、
　前記アプリケーションサーバから、前記通信端末と、前記被制御端末とのアクセス制御要求を受信するアクセス制御要求受信手段と、
　前記アクセス制御要求に基づいて、前記通信端末と、前記被制御端末との接続許否を判断し、判断結果を送信する判断結果送信手段と、
　を備えることを特徴とする通信システム。