ＳＩＰ機器
【課題】簡略な構成、簡略な手順でＷＡＮからの不正アクセスを的確に排除可能なＳＩＰ機器を提供する。
【解決手段】ＳＩＰリクエストを処理するＳＩＰ処理部と、ＷＡＮ側から着信したＳＩＰリクエストメッセージを、ＷＡＮ側から着信した旨の情報を付してＳＩＰ処理部に転送するＷＡＮ通信部と、ＬＡＮ側から着信したＳＩＰリクエストメッセージをＳＩＰ処理部に転送するＬＡＮ通信部とを備え、ＳＩＰ処理部は、そのＩＮＶＥＩＴＥリクエストメッセージが、当方から事前にＲＥＧＩＳＴＥＲリクエストメッセージを送信して登録された局からのものである場合、このＩＮＶＩＴＥリクエストを受け付ける。
【解決手段】ＳＩＰリクエストを処理するＳＩＰ処理部と、ＷＡＮ側から着信したＳＩＰリクエストメッセージを、ＷＡＮ側から着信した旨の情報を付してＳＩＰ処理部に転送するＷＡＮ通信部と、ＬＡＮ側から着信したＳＩＰリクエストメッセージをＳＩＰ処理部に転送するＬＡＮ通信部とを備え、ＳＩＰ処理部は、そのＩＮＶＥＩＴＥリクエストメッセージが、当方から事前にＲＥＧＩＳＴＥＲリクエストメッセージを送信して登録された局からのものである場合、このＩＮＶＩＴＥリクエストを受け付ける。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）リクエストをＬＡＮ側およびＷＡＮ側の両方から受け付けて処理するＳＩＰ機器に関する。
【背景技術】
【０００２】
ＩＰ電話は、端末（電話機）間の接続の確立をＳＩＰで行い、音声信号の伝送をＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）で行うものが一般的である。ところで、ＳＩＰパケット、ＶｏＩＰパケットともにルータに内蔵されているＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）部を通過することができないため、ローカルＩＰネットワークであるＬＡＮ上の端末（ＩＰ電話機）からグローバルＩＰネットワークであるＷＡＮ（インターネット上）に設置されている通信事業者のＳＩＰサーバにアクセスすることができなかった。このいわゆるＮＡＴ越えを実現するためには、大がかりなＳＩＰプロキシサーバ等を設置する必要があった。
【０００３】
そこで、出願人は、簡略な構成でこれを実現するため、ＬＡＮからＷＡＮにＳＩＰリクエストメッセージを通過させることができるＶｏＩＰルータ装置を提案した（特許文献１参照）。また、出願人は、ＬＡＮ−ＷＡＮ相互間でＳＩＰリクエストを転送可能なＶｏＩＰルータ装置を実現した。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−１６００５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＬＡＮとＷＡＮとに跨がるＳＩＰリクエストを受け付ける場合、不正なアクセスを有効に排除することが困難である。特にＷＡＮ側からのアクセスに対してセキュリティのしきい値を高くする必要があるが、ＩＰフィルタリングやＳＩＰによる認証ではＷＡＮ側からの着信とＬＡＮ側からの着信を区別して不正なアクセスを有効に排除することが困難である。すなわち、セキュリティレベルを低くするとＷＡＮ側からの不正アクセスを排除できず、セキュリティレベルを高くするとＬＡＮ側からの正当なアクセスも排除してしまうという問題点があった。
【０００６】
この発明は、簡略な構成、簡略な手順でＷＡＮからの不正アクセスを的確に排除可能なＳＩＰ機器を提供することを目的とする。
【課題を解決するための手段】
【０００７】
請求項１の発明であるＳＩＰ機器は、ＳＩＰリクエストを処理するＳＩＰ処理部と、ＷＡＮ側から着信したＳＩＰリクエストメッセージを、ＷＡＮ側から着信した旨の情報を付して前記ＳＩＰ処理部に転送するＷＡＮ通信部と、ＬＡＮ側から着信したＳＩＰリクエストメッセージを前記ＳＩＰ処理部に転送するＬＡＮ通信部と、を備え、
前記ＳＩＰ処理部は、ＷＡＮ側からＩＮＶＩＴＥリクエストメッセージが着信したとき、そのＩＮＶＥＩＴＥリクエストメッセージが、当方から事前にＲＥＧＩＳＴＥＲリクエストメッセージを送信して登録された局からのものである場合、このＩＮＶＩＴＥリクエストを受け付けることを特徴とする。
【０００８】
請求項２の発明は、前記ＳＩＰ処理部が、さらに、ＷＡＮ側から着信したＩＮＶＩＴＥリクエストメッセージの送信元ＵＲＩが、ＬＡＮ側から受け付けたＲＥＧＩＳＴＥＲリクエストに基づき既に登録済（内線レジスト済）のＵＲＩである場合、このＩＮＶＩＴＥリクエストを受け付けることを特徴とする。
【０００９】
請求項３の発明は、前記ＳＩＰ処理部が、さらに、ＷＡＮ側から着信したＩＮＶＩＴＥリクエストメッセージがピア・ツー・ピア接続のリクエストであり、且つ、送信元ＵＲＩが、ユーザの操作によって登録されるＵＲＩリスト（ＶｏＩＰ電話帳）に既に登録済みのＵＲＩである場合、このＩＮＶＩＴＥリクエストを受け付けることを特徴とする。
【００１０】
請求項４の発明は、前記ＳＩＰ処理部は、ＷＡＮ側から着信したＲＥＧＩＳＴＥＲリクエストメッセージを受け付けないことを特徴とする。
【００１１】
請求項５の発明は、前記ＳＩＰ処理部は、ＷＡＮ側から着信したＳＩＰリクエストメッセージを受け付けないとき、そのリクエストメッセージの送信元端末に対してエラーレスポンスを返信しないことを特徴とする。
【００１２】
請求項６の発明は、前記ＷＡＮ通信部および前記ＬＡＮ通信部との間に、パケットフィルタおよびネットワークアドレス変換部を含むルータ部を、前記ＳＩＰ処理部と並列に備え、前記ＷＡＮ通信部および前記ＬＡＮ通信部は、受信したパケットのうち、少なくともＳＩＰリクエストメッセージのパケットを前記ＳＩＰ処理部に転送することを特徴とする。
【発明の効果】
【００１３】
この発明によれば、ＷＡＮ側から着信したＳＩＰリクエストメッセージをＷＡＮ側から着信した旨の情報を付してＳＩＰ処理部に入力し、ＷＡＮ側から入力されたＳＩＰリクエストメッセージに対して種々のフィルタ処理を行うことにより、ＷＡＮ側からの不正アクセスを的確に排除することが可能になる。
【図面の簡単な説明】
【００１４】
【図１】この発明の実施形態であるＶｏＩＰルータを備えたＩＰ電話システムの構成図である。
【図２】前記ＶｏＩＰルータのブロック図である。
【図３】前記ＶｏＩＰルータの動作を示すフローチャートである。
【図４】前記ＶｏＩＰルータの動作を示すフローチャートである。
【図５】前記ＶｏＩＰルータの動作を示すフローチャートである。
【図６】前記ＶｏＩＰルータの動作を示すフローチャートである。
【発明を実施するための形態】
【００１５】
図面を参照してこの発明実施形態であるＩＰ電話システムおよびＶｏＩＰルータについて説明する。
【００１６】
図１はＩＰ電話システムの構成図である。ＶｏＩＰルータ１はローカルＩＰネットワークであるＬＡＮ２とグローバルＩＰネットワークであるＷＡＮ（インターネット）３とを接続するルータ機能を備えているとともに、ＬＡＮ２とＷＡＮ３との間でＳＩＰメッセージを変換して転送する簡易ＳＩＰサーバ機能を備えている。
【００１７】
ＬＡＮ２には内線端末としてのＩＰ電話機５、および、ＩＰ電話機５を交換回線に接続するためのゲートウェイ装置６が接続されている。また、ＬＡＮ２にはパーソナルコンピュータ７も接続されている。なお、この図ではＩＰ電話機５が１台のみ記載されているが１台に限定されない。また、ＶｏＩＰゲートウェイを介して通常の電話機を接続してもよい。一方、ＷＡＮ３には通信事業者のＳＩＰサーバ４が接続されている。通信事業者とは公衆ＩＰ電話サービスを提供する事業者である。
【００１８】
この構成のシステムでＶｏＩＰルータ１は、パーソナルコンピュータ７をインターネットであるＷＡＮ３に接続する通常のルータとして機能するとともに、簡易のＳＩＰサーバとしても機能する。ＶｏＩＰルータ１のＳＩＰサーバ機能は、ＬＡＮ２内におけるＩＰ電話機５同士の内線通話の接続管理、ＬＡＮ２上のＩＰ電話機５からＳＩＰサーバ４を介した外線ＩＰ電話の発呼管理、ＳＩＰサーバ４からＬＡＮ２上のＩＰ電話機５に対して着信する外線ＩＰ電話の着呼管理等である。
【００１９】
図２はＶｏＩＰルータ１のブロック図である。ＶｏＩＰルータ１は、ルータ機能を実現するため、ＬＡＮ通信部１０、ＴＣＰ／ＩＰ処理部１１、ＮＡＴ１２、ＩＰフィルタ１３、ＷＡＮ通信部１４がこの順に配列されている。ＬＡＮ通信部１０はＬＡＮポートを含み、ＬＡＮ２が接続されている。ＷＡＮ通信部１４はＷＡＮポートを含みＷＡＮ３が接続されている。ＴＣＰ／ＩＰ処理部１１は、ＬＡＮ２、ＷＡＮ３間でやりとりされるパケットの処理を行う機能部である。ＮＡＴ１２はグローバルＩＰアドレスとローカルＩＰアドレスの変換（ＩＰマスカレードを含む）を行う機能部である。ＩＰフィルタ１３は、ＷＡＮ通信部１４を介してＷＡＮから着信するパケットをそのヘッダに書き込まれている各種情報に基づいて通過／非通過のフィルタリングを行う機能部である。各種情報には、たとえばＩＰアドレス、サービス名、ポート番号などがある。このＩＰフィルタ３はＳＩＰパケットを通過させないように設定されている。
【００２０】
また、ＬＡＮ通信部１０およびＷＡＮ通信部１４には、上記ＴＣＰ／ＩＰ処理部１１、ＮＡＴ１２、ＩＰフィルタ１３の経路をバイパスするようにＳＩＰ処理部１５が接続されている。ＳＩＰ処理部１５は、ＬＡＮ２に対して内線ＳＩＰサーバとして機能するとともに、ＷＡＮ３とＬＡＮ２との間で簡易なＳＩＰプロキシサーバとして機能する。
【００２１】
ＬＡＮ通信部１０は、ＬＡＮ２から着信したパケットのサービスがＳＩＰまたはＶｏＩＰであったとき、そのパケットをＳＩＰ処理部１５に転送し、それ以外のサービスのパケットはＴＣＰ／ＩＰ処理部１１に転送する。ＷＡＮ通信部１４は、ＷＡＮ３から着信したパケットのサービスがＳＩＰまたはＶｏＩＰであったとき、そのパケットをＳＩＰ処理部１５に転送し、それ以外のサービスのパケットはＩＰフィルタ１３に転送する。また、ＷＡＮ通信部１４は、ＳＩＰのパケット（ＳＩＰリクエストメッセージ）をＳＩＰ処理部１５に転送するとき、そのパケットがＷＡＮ３から着信した旨を示す情報を添付する。
【００２２】
ＳＩＰ処理部１５は、ＬＡＮ通信部１０から転送されてくるＳＩＰリクエストメッセージについては通常の手順で処理する。また、ＳＩＰ処理部１５は、ＷＡＮ通信部１４からＳＩＰリクエストメッセージが転送されてきたとき、そのＳＩＰリクエストメッセージに上述の「ＷＡＮ３から着信した旨を示す情報」が付加されていることに基づいてＷＡＮ３からの着信したものであることを識別し、このＳＩＰリクエストメッセージについては、セキュリティを維持するため、デフォルトでは、通信事業者のＳＩＰサーバ４から送られてくるＩＮＶＩＴＥリクエストのみ着信を許可し、それ以外のリクエストメッセージは破棄する。また、リクエストメッセージを破棄した場合でもその送信元のＵＡ（Ｕｓｅｒ
Ａｇｅｎｔ）に対してエラーメッセージを返信しない。なお、ユーザによる設定により、ＳＩＰサーバ４以外から着信するＩＮＶＩＴＥリクエスト以外のリクエストメッセージの着信を許可することも可能であり、また、リクエストメッセージを破棄した場合にその送信元ＵＡに対してエラーメッセージを返信するよう設定することも可能である。
【００２３】
以下、ＳＩＰ処理部１５が、ＷＡＮ３から着信したＳＩＰリクエストメッセージを処理する処理手順を、図３〜図６のフローチャートを参照して詳細に説明する。ＳＩＰ処理部は、ＷＡＮ３からリクエストメッセージが着信した場合、すなわち、ＷＡＮ３から着信した旨を示す情報が付加されたＳＩＰのパケットがＷＡＮ通信部１４から転送されてきた場合、図３〜図６の処理動作を実行する。
【００２４】
図３はメインルーチンである。ＷＡＮ３からＳＩＰ処理部１５のドメイン宛にリクエストメッセージが着信するとそのリクエストメッセージがＲＥＧＩＳＴＥＲリクエストであるか（Ｓ１０）、ＩＮＶＩＴＥリクエストであるか（Ｓ１２）を判定する。ＲＥＧＩＳＴＥＲリクエストの場合には（Ｓ１０でＹＥＳ）、ＲＥＧＩＳＴＥＲ着信処理（Ｓ１１：図５参照）を実行する。また、ＩＮＶＩＴＥリクエストの場合には（Ｓ１２でＹＥＳ）、ＩＮＶＩＴＥ着信処理（Ｓ１３：図６参照）を実行する。ＷＡＮ３から着信したリクエストメッセージがＲＥＧＩＳＴＥＲリクエストまたはＩＮＶＩＴＥリクエスト以外のメッセージであった場合には（Ｓ１０、Ｓ１２でＮＯ）、このメッセージを破棄する（Ｓ１４）。すなわち、セキュリティ維持のためＷＡＮ３からはＲＥＧＩＳＴＥＲ、ＩＮＶＩＴＥ以外のリクエストメッセージは受け付けない。リクエストメッセージの破棄は図４に示す手順で行われる。
【００２５】
図４はリクエスト破棄処理を示すフローチャートである。着信したリクエストメッセージを破棄する場合この手順で行われる。まず、リクエストを破棄するの旨のエラーメッセージを送信元のＵＡに返信するか否かを判定する（Ｓ２０）。送信元ＵＡに対する返信を許可するか否かは予めユーザによって設定されている。送信元ＵＡ局に対する返信が許可されている場合（Ｓ２０でＹＥＳ）には、メッセージ破棄の理由に応じたエラーコード（４０１、４０３または４０４）を返信する（Ｓ２１）。図３のＳ１４の場合には、４０３「Ｆｏｒｂｉｄｄｅｎ」が返信される。送信元ＵＡに対する返信が許可されていない場合（Ｓ２０でＮＯ）には何もせずに終了する。エラーコードの返信を行わないのは、相手局にこのＳＩＰ処理部１５の存在を知らせないためである。
【００２６】
図５はＲＥＧＩＳＴＥＲ着信処理を示すフローチャートである。この処理動作は、ＷＡＮ３からＲＥＧＩＳＴＥＲリクエストを受信した場合に図３のＳ１１で実行される。まず、ＷＡＮ３からのＲＥＧＩＳＴＥＲリクエストの着信が許可されているか否かを判定する（Ｓ３０）。ＷＡＮ３からのＲＥＧＩＳＴＥＲリクエストの着信を許可するか否かは予めユーザによって設定されている。ＲＥＧＩＳＴＥＲリクエストの着信が許可されている場合には（Ｓ３０でＹＥＳ）、送信局の認証処理を行う（Ｓ３２）。この認証処理はたとえば一般的なダイジェスト認証等で行えばよい。認証がＯＫの場合には、リクエストのあったＵＲＩをデータベースに登録する（Ｓ３５）。その後、送信局に対して登録が完了した旨の返信を行う等の処理が実行される。
【００２７】
一方、ＷＡＮ３からのＲＥＧＩＳＴＥＲリクエストの着信が許可されていない場合には（Ｓ３０でＮＯ）、図４に示す手順でリクエストの破棄処理を行う（Ｓ３１）。エラーコードを返信する場合には４０３「Ｆｏｒｂｉｄｄｅｎ」を返信する。また、送信局の認証できなかった場合にも（Ｓ３３でＮＯ）同様に、図４に示す手順でリクエストの処理処理を行う（Ｓ３４）。この場合返信されるエラーコードは４０１「Ｕｎａｕｔｈｏｒｉｚｅｄ」である。
【００２８】
図６はＩＮＶＩＴＥ着信処理を示すフローチャートである。この処理動作は、ＷＡＮ３からＩＮＶＩＴＥリクエストを受信した場合に図３のＳ１３で実行される。この動作では、まず宛先ＵＲＩに相当するリクエストＵＲＩをチェックする（Ｓ４０）。リクエストＵＲＩが上位レジスト済のＵＲＩ、すなわち、本装置から通信事業者のＳＩＰサーバに対して送信したＲＥＧＩＳＴＥＲリクエストのコンタクトヘッダに記載したＵＲＩであった場合には（Ｓ４０でＹＥＳ）、通信事業者を経由した外線ＩＰ電話からの発信であるとして、データベースに記載されている電話番号のいずれかと一致するかを判定する（Ｓ４１）。一致した場合には（Ｓ４１でＹＥＳ）、その電話番号が割り振られている内線端末（ＩＰ電話機５）に対してこのＩＮＶＩＴＥリクエストを転送して着呼させる（Ｓ４２）。もし、電話番号が一致しなかった場合には番号違いの電話であるとして、図４に示す手順でリクエスト破棄処理を実行する（Ｓ４３）。エラーコードを返信する場合には４０４「Ｎｏｔ ｆｏｕｎｄ」を返信する。
【００２９】
ここで、このＶｏＩＰサーバ１が通信事業者のＳＩＰサーバに対して送信するＲＥＧＩＳＴＥＲリクエストメッセージのコンタクトＵＲＩには、なりすましによる不正なアクセスを防止するためにランダムな文字列が含めている。したがって、通信事業者がこのＶｏＩＰサーバに送ってくるリクエストメッセージのリクエストＵＲＩが、このランダムな文字列が含まれたＵＲＩであれば、正当なＳＩＰサーバから送られてきたリクエストメッセージであると判断することができる。上記Ｓ４０では、このＵＲＩを用いて相手局を認証している。また、上記Ｓ４１では、ＩＮＶＩＴＥリクエストメッセージのＴＯヘッダ（たとえば、電話番号＠ドメイン、または、電話番号＠ＩＰアドレス）から電話番号を抽出し、この電話番号でデータベースを検索する。
【００３０】
リクエストＵＲＩが上位レジスト済のＵＲＩでない場合には（Ｓ４０でＮＯ）、ヘッダのコンタクトＵＲＩをチェックする（Ｓ４４）。このコンタクトＵＲＩが本発明の送信元ＵＲＩに相当する。ヘッダ内のコンタクトＵＲＩが内線レジスト済のＵＲＩであった場合（Ｓ４４でＹＥＳ）には、ＬＡＮ２経由で内線登録されたＩＰ電話機５が外部に持ち出されてＷＡＮ３経由で着信したものであり、このＩＮＶＩＴＥを許可してもよいと判断し、Ｓ４１の処理に進む。なお、内線レジスト済のＵＲＩとは、ＬＡＮ２上のＩＰ電話機５から着信したＲＥＧＩＳＴＥＲリクエストによって内線データベースに登録済のＵＲＩである。
【００３１】
リクエストＵＲＩが上位レジスト済でも、コンタクトＵＲＩが内線レジスト済でもない場合には（Ｓ４４でＮＯ）、このＩＮＶＩＴＥリクエストがピア・ツー・ピア（Ｐ２Ｐ）通信のリクエストすなわちＰ２Ｐ着信であるかを判定する（Ｓ４５）。Ｐ２Ｐ着信である場合には（Ｓ４５でＹＥＳ）、ＷＡＮ３からのＰ２Ｐ着信（外線Ｐ２Ｐ着信）が許可されているかを判定する（Ｓ４６）。外線Ｐ２Ｐ着信が許可されている場合には、ＦＲＯＭのＵＲＩがＶｏＩＰ電話帳に登録されているかを判定する（Ｓ４７）。登録されている場合には（Ｓ４７でＹＥＳ）、このＶｏＩＰルータ１のユーザが自ら登録した通信相手からの着信であるとしてこのリクエストの着信を許可しＩＮＶＩＴＥ処理を実行する（Ｓ４８）。なお、ＶｏＩＰ電話帳とは、ユーザによって登録される発呼先ＵＲＩのリストである。
【００３２】
ＩＮＶＩＴＥリクエストがＰ２Ｐリクエストでない場合（Ｓ４５でＮＯ）、本機が外線Ｐ２Ｐ着信を許可していない場合（Ｓ４６でＮＯ）、または、ＶｏＩＰ電話帳に電話番号が登録されていない場合（Ｓ４７でＮＯ）には、図４に示す手順でリクエストの破棄処理を行う（Ｓ４９）。エラーコードを返信する場合には４０４「Ｎｏｔ ｆｏｕｎｄ」を返信する。
【００３３】
なお、この実施形態では、ＷＡＮ側からＩＮＶＩＴＥリクエストメッセージが着信したとき、「そのＩＮＶＥＩＴＥリクエストメッセージが、当方から事前にＲＥＧＩＳＴＥＲリクエストメッセージを送信して登録された局からのものである」か否かの判定を、「そのリクエストメッセージの宛先ＵＲＩが、当方から前記ＩＮＶＩＴＥリクエストメッセージの送信元の局に対して事前に送信したＲＥＧＩＳＴＥＲリクエストに記載した（上位レジスト済）ＵＲＩである」か否かで判定しているが、上記判定はこれに限定されない。
【符号の説明】
【００３４】
１ ＶｏＩＰルータ
２ ＬＡＮ
３ ＷＡＮ
１０ ＬＡＮ通信部
１４ ＷＡＮ通信部
１５ ＳＩＰ処理部
【技術分野】
【０００１】
この発明は、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）リクエストをＬＡＮ側およびＷＡＮ側の両方から受け付けて処理するＳＩＰ機器に関する。
【背景技術】
【０００２】
ＩＰ電話は、端末（電話機）間の接続の確立をＳＩＰで行い、音声信号の伝送をＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）で行うものが一般的である。ところで、ＳＩＰパケット、ＶｏＩＰパケットともにルータに内蔵されているＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）部を通過することができないため、ローカルＩＰネットワークであるＬＡＮ上の端末（ＩＰ電話機）からグローバルＩＰネットワークであるＷＡＮ（インターネット上）に設置されている通信事業者のＳＩＰサーバにアクセスすることができなかった。このいわゆるＮＡＴ越えを実現するためには、大がかりなＳＩＰプロキシサーバ等を設置する必要があった。
【０００３】
そこで、出願人は、簡略な構成でこれを実現するため、ＬＡＮからＷＡＮにＳＩＰリクエストメッセージを通過させることができるＶｏＩＰルータ装置を提案した（特許文献１参照）。また、出願人は、ＬＡＮ−ＷＡＮ相互間でＳＩＰリクエストを転送可能なＶｏＩＰルータ装置を実現した。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−１６００５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＬＡＮとＷＡＮとに跨がるＳＩＰリクエストを受け付ける場合、不正なアクセスを有効に排除することが困難である。特にＷＡＮ側からのアクセスに対してセキュリティのしきい値を高くする必要があるが、ＩＰフィルタリングやＳＩＰによる認証ではＷＡＮ側からの着信とＬＡＮ側からの着信を区別して不正なアクセスを有効に排除することが困難である。すなわち、セキュリティレベルを低くするとＷＡＮ側からの不正アクセスを排除できず、セキュリティレベルを高くするとＬＡＮ側からの正当なアクセスも排除してしまうという問題点があった。
【０００６】
この発明は、簡略な構成、簡略な手順でＷＡＮからの不正アクセスを的確に排除可能なＳＩＰ機器を提供することを目的とする。
【課題を解決するための手段】
【０００７】
請求項１の発明であるＳＩＰ機器は、ＳＩＰリクエストを処理するＳＩＰ処理部と、ＷＡＮ側から着信したＳＩＰリクエストメッセージを、ＷＡＮ側から着信した旨の情報を付して前記ＳＩＰ処理部に転送するＷＡＮ通信部と、ＬＡＮ側から着信したＳＩＰリクエストメッセージを前記ＳＩＰ処理部に転送するＬＡＮ通信部と、を備え、
前記ＳＩＰ処理部は、ＷＡＮ側からＩＮＶＩＴＥリクエストメッセージが着信したとき、そのＩＮＶＥＩＴＥリクエストメッセージが、当方から事前にＲＥＧＩＳＴＥＲリクエストメッセージを送信して登録された局からのものである場合、このＩＮＶＩＴＥリクエストを受け付けることを特徴とする。
【０００８】
請求項２の発明は、前記ＳＩＰ処理部が、さらに、ＷＡＮ側から着信したＩＮＶＩＴＥリクエストメッセージの送信元ＵＲＩが、ＬＡＮ側から受け付けたＲＥＧＩＳＴＥＲリクエストに基づき既に登録済（内線レジスト済）のＵＲＩである場合、このＩＮＶＩＴＥリクエストを受け付けることを特徴とする。
【０００９】
請求項３の発明は、前記ＳＩＰ処理部が、さらに、ＷＡＮ側から着信したＩＮＶＩＴＥリクエストメッセージがピア・ツー・ピア接続のリクエストであり、且つ、送信元ＵＲＩが、ユーザの操作によって登録されるＵＲＩリスト（ＶｏＩＰ電話帳）に既に登録済みのＵＲＩである場合、このＩＮＶＩＴＥリクエストを受け付けることを特徴とする。
【００１０】
請求項４の発明は、前記ＳＩＰ処理部は、ＷＡＮ側から着信したＲＥＧＩＳＴＥＲリクエストメッセージを受け付けないことを特徴とする。
【００１１】
請求項５の発明は、前記ＳＩＰ処理部は、ＷＡＮ側から着信したＳＩＰリクエストメッセージを受け付けないとき、そのリクエストメッセージの送信元端末に対してエラーレスポンスを返信しないことを特徴とする。
【００１２】
請求項６の発明は、前記ＷＡＮ通信部および前記ＬＡＮ通信部との間に、パケットフィルタおよびネットワークアドレス変換部を含むルータ部を、前記ＳＩＰ処理部と並列に備え、前記ＷＡＮ通信部および前記ＬＡＮ通信部は、受信したパケットのうち、少なくともＳＩＰリクエストメッセージのパケットを前記ＳＩＰ処理部に転送することを特徴とする。
【発明の効果】
【００１３】
この発明によれば、ＷＡＮ側から着信したＳＩＰリクエストメッセージをＷＡＮ側から着信した旨の情報を付してＳＩＰ処理部に入力し、ＷＡＮ側から入力されたＳＩＰリクエストメッセージに対して種々のフィルタ処理を行うことにより、ＷＡＮ側からの不正アクセスを的確に排除することが可能になる。
【図面の簡単な説明】
【００１４】
【図１】この発明の実施形態であるＶｏＩＰルータを備えたＩＰ電話システムの構成図である。
【図２】前記ＶｏＩＰルータのブロック図である。
【図３】前記ＶｏＩＰルータの動作を示すフローチャートである。
【図４】前記ＶｏＩＰルータの動作を示すフローチャートである。
【図５】前記ＶｏＩＰルータの動作を示すフローチャートである。
【図６】前記ＶｏＩＰルータの動作を示すフローチャートである。
【発明を実施するための形態】
【００１５】
図面を参照してこの発明実施形態であるＩＰ電話システムおよびＶｏＩＰルータについて説明する。
【００１６】
図１はＩＰ電話システムの構成図である。ＶｏＩＰルータ１はローカルＩＰネットワークであるＬＡＮ２とグローバルＩＰネットワークであるＷＡＮ（インターネット）３とを接続するルータ機能を備えているとともに、ＬＡＮ２とＷＡＮ３との間でＳＩＰメッセージを変換して転送する簡易ＳＩＰサーバ機能を備えている。
【００１７】
ＬＡＮ２には内線端末としてのＩＰ電話機５、および、ＩＰ電話機５を交換回線に接続するためのゲートウェイ装置６が接続されている。また、ＬＡＮ２にはパーソナルコンピュータ７も接続されている。なお、この図ではＩＰ電話機５が１台のみ記載されているが１台に限定されない。また、ＶｏＩＰゲートウェイを介して通常の電話機を接続してもよい。一方、ＷＡＮ３には通信事業者のＳＩＰサーバ４が接続されている。通信事業者とは公衆ＩＰ電話サービスを提供する事業者である。
【００１８】
この構成のシステムでＶｏＩＰルータ１は、パーソナルコンピュータ７をインターネットであるＷＡＮ３に接続する通常のルータとして機能するとともに、簡易のＳＩＰサーバとしても機能する。ＶｏＩＰルータ１のＳＩＰサーバ機能は、ＬＡＮ２内におけるＩＰ電話機５同士の内線通話の接続管理、ＬＡＮ２上のＩＰ電話機５からＳＩＰサーバ４を介した外線ＩＰ電話の発呼管理、ＳＩＰサーバ４からＬＡＮ２上のＩＰ電話機５に対して着信する外線ＩＰ電話の着呼管理等である。
【００１９】
図２はＶｏＩＰルータ１のブロック図である。ＶｏＩＰルータ１は、ルータ機能を実現するため、ＬＡＮ通信部１０、ＴＣＰ／ＩＰ処理部１１、ＮＡＴ１２、ＩＰフィルタ１３、ＷＡＮ通信部１４がこの順に配列されている。ＬＡＮ通信部１０はＬＡＮポートを含み、ＬＡＮ２が接続されている。ＷＡＮ通信部１４はＷＡＮポートを含みＷＡＮ３が接続されている。ＴＣＰ／ＩＰ処理部１１は、ＬＡＮ２、ＷＡＮ３間でやりとりされるパケットの処理を行う機能部である。ＮＡＴ１２はグローバルＩＰアドレスとローカルＩＰアドレスの変換（ＩＰマスカレードを含む）を行う機能部である。ＩＰフィルタ１３は、ＷＡＮ通信部１４を介してＷＡＮから着信するパケットをそのヘッダに書き込まれている各種情報に基づいて通過／非通過のフィルタリングを行う機能部である。各種情報には、たとえばＩＰアドレス、サービス名、ポート番号などがある。このＩＰフィルタ３はＳＩＰパケットを通過させないように設定されている。
【００２０】
また、ＬＡＮ通信部１０およびＷＡＮ通信部１４には、上記ＴＣＰ／ＩＰ処理部１１、ＮＡＴ１２、ＩＰフィルタ１３の経路をバイパスするようにＳＩＰ処理部１５が接続されている。ＳＩＰ処理部１５は、ＬＡＮ２に対して内線ＳＩＰサーバとして機能するとともに、ＷＡＮ３とＬＡＮ２との間で簡易なＳＩＰプロキシサーバとして機能する。
【００２１】
ＬＡＮ通信部１０は、ＬＡＮ２から着信したパケットのサービスがＳＩＰまたはＶｏＩＰであったとき、そのパケットをＳＩＰ処理部１５に転送し、それ以外のサービスのパケットはＴＣＰ／ＩＰ処理部１１に転送する。ＷＡＮ通信部１４は、ＷＡＮ３から着信したパケットのサービスがＳＩＰまたはＶｏＩＰであったとき、そのパケットをＳＩＰ処理部１５に転送し、それ以外のサービスのパケットはＩＰフィルタ１３に転送する。また、ＷＡＮ通信部１４は、ＳＩＰのパケット（ＳＩＰリクエストメッセージ）をＳＩＰ処理部１５に転送するとき、そのパケットがＷＡＮ３から着信した旨を示す情報を添付する。
【００２２】
ＳＩＰ処理部１５は、ＬＡＮ通信部１０から転送されてくるＳＩＰリクエストメッセージについては通常の手順で処理する。また、ＳＩＰ処理部１５は、ＷＡＮ通信部１４からＳＩＰリクエストメッセージが転送されてきたとき、そのＳＩＰリクエストメッセージに上述の「ＷＡＮ３から着信した旨を示す情報」が付加されていることに基づいてＷＡＮ３からの着信したものであることを識別し、このＳＩＰリクエストメッセージについては、セキュリティを維持するため、デフォルトでは、通信事業者のＳＩＰサーバ４から送られてくるＩＮＶＩＴＥリクエストのみ着信を許可し、それ以外のリクエストメッセージは破棄する。また、リクエストメッセージを破棄した場合でもその送信元のＵＡ（Ｕｓｅｒ
Ａｇｅｎｔ）に対してエラーメッセージを返信しない。なお、ユーザによる設定により、ＳＩＰサーバ４以外から着信するＩＮＶＩＴＥリクエスト以外のリクエストメッセージの着信を許可することも可能であり、また、リクエストメッセージを破棄した場合にその送信元ＵＡに対してエラーメッセージを返信するよう設定することも可能である。
【００２３】
以下、ＳＩＰ処理部１５が、ＷＡＮ３から着信したＳＩＰリクエストメッセージを処理する処理手順を、図３〜図６のフローチャートを参照して詳細に説明する。ＳＩＰ処理部は、ＷＡＮ３からリクエストメッセージが着信した場合、すなわち、ＷＡＮ３から着信した旨を示す情報が付加されたＳＩＰのパケットがＷＡＮ通信部１４から転送されてきた場合、図３〜図６の処理動作を実行する。
【００２４】
図３はメインルーチンである。ＷＡＮ３からＳＩＰ処理部１５のドメイン宛にリクエストメッセージが着信するとそのリクエストメッセージがＲＥＧＩＳＴＥＲリクエストであるか（Ｓ１０）、ＩＮＶＩＴＥリクエストであるか（Ｓ１２）を判定する。ＲＥＧＩＳＴＥＲリクエストの場合には（Ｓ１０でＹＥＳ）、ＲＥＧＩＳＴＥＲ着信処理（Ｓ１１：図５参照）を実行する。また、ＩＮＶＩＴＥリクエストの場合には（Ｓ１２でＹＥＳ）、ＩＮＶＩＴＥ着信処理（Ｓ１３：図６参照）を実行する。ＷＡＮ３から着信したリクエストメッセージがＲＥＧＩＳＴＥＲリクエストまたはＩＮＶＩＴＥリクエスト以外のメッセージであった場合には（Ｓ１０、Ｓ１２でＮＯ）、このメッセージを破棄する（Ｓ１４）。すなわち、セキュリティ維持のためＷＡＮ３からはＲＥＧＩＳＴＥＲ、ＩＮＶＩＴＥ以外のリクエストメッセージは受け付けない。リクエストメッセージの破棄は図４に示す手順で行われる。
【００２５】
図４はリクエスト破棄処理を示すフローチャートである。着信したリクエストメッセージを破棄する場合この手順で行われる。まず、リクエストを破棄するの旨のエラーメッセージを送信元のＵＡに返信するか否かを判定する（Ｓ２０）。送信元ＵＡに対する返信を許可するか否かは予めユーザによって設定されている。送信元ＵＡ局に対する返信が許可されている場合（Ｓ２０でＹＥＳ）には、メッセージ破棄の理由に応じたエラーコード（４０１、４０３または４０４）を返信する（Ｓ２１）。図３のＳ１４の場合には、４０３「Ｆｏｒｂｉｄｄｅｎ」が返信される。送信元ＵＡに対する返信が許可されていない場合（Ｓ２０でＮＯ）には何もせずに終了する。エラーコードの返信を行わないのは、相手局にこのＳＩＰ処理部１５の存在を知らせないためである。
【００２６】
図５はＲＥＧＩＳＴＥＲ着信処理を示すフローチャートである。この処理動作は、ＷＡＮ３からＲＥＧＩＳＴＥＲリクエストを受信した場合に図３のＳ１１で実行される。まず、ＷＡＮ３からのＲＥＧＩＳＴＥＲリクエストの着信が許可されているか否かを判定する（Ｓ３０）。ＷＡＮ３からのＲＥＧＩＳＴＥＲリクエストの着信を許可するか否かは予めユーザによって設定されている。ＲＥＧＩＳＴＥＲリクエストの着信が許可されている場合には（Ｓ３０でＹＥＳ）、送信局の認証処理を行う（Ｓ３２）。この認証処理はたとえば一般的なダイジェスト認証等で行えばよい。認証がＯＫの場合には、リクエストのあったＵＲＩをデータベースに登録する（Ｓ３５）。その後、送信局に対して登録が完了した旨の返信を行う等の処理が実行される。
【００２７】
一方、ＷＡＮ３からのＲＥＧＩＳＴＥＲリクエストの着信が許可されていない場合には（Ｓ３０でＮＯ）、図４に示す手順でリクエストの破棄処理を行う（Ｓ３１）。エラーコードを返信する場合には４０３「Ｆｏｒｂｉｄｄｅｎ」を返信する。また、送信局の認証できなかった場合にも（Ｓ３３でＮＯ）同様に、図４に示す手順でリクエストの処理処理を行う（Ｓ３４）。この場合返信されるエラーコードは４０１「Ｕｎａｕｔｈｏｒｉｚｅｄ」である。
【００２８】
図６はＩＮＶＩＴＥ着信処理を示すフローチャートである。この処理動作は、ＷＡＮ３からＩＮＶＩＴＥリクエストを受信した場合に図３のＳ１３で実行される。この動作では、まず宛先ＵＲＩに相当するリクエストＵＲＩをチェックする（Ｓ４０）。リクエストＵＲＩが上位レジスト済のＵＲＩ、すなわち、本装置から通信事業者のＳＩＰサーバに対して送信したＲＥＧＩＳＴＥＲリクエストのコンタクトヘッダに記載したＵＲＩであった場合には（Ｓ４０でＹＥＳ）、通信事業者を経由した外線ＩＰ電話からの発信であるとして、データベースに記載されている電話番号のいずれかと一致するかを判定する（Ｓ４１）。一致した場合には（Ｓ４１でＹＥＳ）、その電話番号が割り振られている内線端末（ＩＰ電話機５）に対してこのＩＮＶＩＴＥリクエストを転送して着呼させる（Ｓ４２）。もし、電話番号が一致しなかった場合には番号違いの電話であるとして、図４に示す手順でリクエスト破棄処理を実行する（Ｓ４３）。エラーコードを返信する場合には４０４「Ｎｏｔ ｆｏｕｎｄ」を返信する。
【００２９】
ここで、このＶｏＩＰサーバ１が通信事業者のＳＩＰサーバに対して送信するＲＥＧＩＳＴＥＲリクエストメッセージのコンタクトＵＲＩには、なりすましによる不正なアクセスを防止するためにランダムな文字列が含めている。したがって、通信事業者がこのＶｏＩＰサーバに送ってくるリクエストメッセージのリクエストＵＲＩが、このランダムな文字列が含まれたＵＲＩであれば、正当なＳＩＰサーバから送られてきたリクエストメッセージであると判断することができる。上記Ｓ４０では、このＵＲＩを用いて相手局を認証している。また、上記Ｓ４１では、ＩＮＶＩＴＥリクエストメッセージのＴＯヘッダ（たとえば、電話番号＠ドメイン、または、電話番号＠ＩＰアドレス）から電話番号を抽出し、この電話番号でデータベースを検索する。
【００３０】
リクエストＵＲＩが上位レジスト済のＵＲＩでない場合には（Ｓ４０でＮＯ）、ヘッダのコンタクトＵＲＩをチェックする（Ｓ４４）。このコンタクトＵＲＩが本発明の送信元ＵＲＩに相当する。ヘッダ内のコンタクトＵＲＩが内線レジスト済のＵＲＩであった場合（Ｓ４４でＹＥＳ）には、ＬＡＮ２経由で内線登録されたＩＰ電話機５が外部に持ち出されてＷＡＮ３経由で着信したものであり、このＩＮＶＩＴＥを許可してもよいと判断し、Ｓ４１の処理に進む。なお、内線レジスト済のＵＲＩとは、ＬＡＮ２上のＩＰ電話機５から着信したＲＥＧＩＳＴＥＲリクエストによって内線データベースに登録済のＵＲＩである。
【００３１】
リクエストＵＲＩが上位レジスト済でも、コンタクトＵＲＩが内線レジスト済でもない場合には（Ｓ４４でＮＯ）、このＩＮＶＩＴＥリクエストがピア・ツー・ピア（Ｐ２Ｐ）通信のリクエストすなわちＰ２Ｐ着信であるかを判定する（Ｓ４５）。Ｐ２Ｐ着信である場合には（Ｓ４５でＹＥＳ）、ＷＡＮ３からのＰ２Ｐ着信（外線Ｐ２Ｐ着信）が許可されているかを判定する（Ｓ４６）。外線Ｐ２Ｐ着信が許可されている場合には、ＦＲＯＭのＵＲＩがＶｏＩＰ電話帳に登録されているかを判定する（Ｓ４７）。登録されている場合には（Ｓ４７でＹＥＳ）、このＶｏＩＰルータ１のユーザが自ら登録した通信相手からの着信であるとしてこのリクエストの着信を許可しＩＮＶＩＴＥ処理を実行する（Ｓ４８）。なお、ＶｏＩＰ電話帳とは、ユーザによって登録される発呼先ＵＲＩのリストである。
【００３２】
ＩＮＶＩＴＥリクエストがＰ２Ｐリクエストでない場合（Ｓ４５でＮＯ）、本機が外線Ｐ２Ｐ着信を許可していない場合（Ｓ４６でＮＯ）、または、ＶｏＩＰ電話帳に電話番号が登録されていない場合（Ｓ４７でＮＯ）には、図４に示す手順でリクエストの破棄処理を行う（Ｓ４９）。エラーコードを返信する場合には４０４「Ｎｏｔ ｆｏｕｎｄ」を返信する。
【００３３】
なお、この実施形態では、ＷＡＮ側からＩＮＶＩＴＥリクエストメッセージが着信したとき、「そのＩＮＶＥＩＴＥリクエストメッセージが、当方から事前にＲＥＧＩＳＴＥＲリクエストメッセージを送信して登録された局からのものである」か否かの判定を、「そのリクエストメッセージの宛先ＵＲＩが、当方から前記ＩＮＶＩＴＥリクエストメッセージの送信元の局に対して事前に送信したＲＥＧＩＳＴＥＲリクエストに記載した（上位レジスト済）ＵＲＩである」か否かで判定しているが、上記判定はこれに限定されない。
【符号の説明】
【００３４】
１ ＶｏＩＰルータ
２ ＬＡＮ
３ ＷＡＮ
１０ ＬＡＮ通信部
１４ ＷＡＮ通信部
１５ ＳＩＰ処理部
【特許請求の範囲】
【請求項１】
ＳＩＰリクエストを処理するＳＩＰ処理部と、
ＷＡＮ側から着信したＳＩＰリクエストメッセージを、ＷＡＮ側から着信した旨の情報を付して前記ＳＩＰ処理部に転送するＷＡＮ通信部と、
ＬＡＮ側から着信したＳＩＰリクエストメッセージを前記ＳＩＰ処理部に転送するＬＡＮ通信部と、
を備え、
前記ＳＩＰ処理部は、ＷＡＮ側からＩＮＶＩＴＥリクエストメッセージが着信したとき、そのＩＮＶＥＩＴＥリクエストメッセージが、当方から事前にＲＥＧＩＳＴＥＲリクエストメッセージを送信して登録された局からのものである場合、このＩＮＶＩＴＥリクエストを受け付ける
ＳＩＰ機器。
【請求項２】
前記ＳＩＰ処理部は、さらに、ＷＡＮ側から着信したＩＮＶＩＴＥリクエストメッセージの送信元ＵＲＩが、ＬＡＮ側から受け付けたＲＥＧＩＳＴＥＲリクエストに基づき既に登録済のＵＲＩである場合、このＩＮＶＩＴＥリクエストを受け付ける
請求項１に記載のＳＩＰ機器。
【請求項３】
前記ＳＩＰ処理部は、さらに、ＷＡＮ側から着信したＩＮＶＩＴＥリクエストメッセージがピア・ツー・ピア接続のリクエストであり、且つ、送信元ＵＲＩが、ユーザの操作によって登録されるＵＲＩリストに既に登録済みのＵＲＩである場合、このＩＮＶＩＴＥリクエストを受け付ける
請求項１または請求項２に記載のＳＩＰ機器。
【請求項４】
前記ＳＩＰ処理部は、ＷＡＮ側から着信したＲＥＧＩＳＴＥＲリクエストメッセージを受け付けない請求項１乃至請求項３のいずれかに記載のＳＩＰ機器。
【請求項５】
前記ＳＩＰ処理部は、ＷＡＮ側から着信したＳＩＰリクエストメッセージを受け付けないとき、そのリクエストメッセージの送信元端末に対してエラーレスポンスを返信しない請求項１乃至請求項４のいずれかに記載のＳＩＰ機器。
【請求項６】
前記ＷＡＮ通信部および前記ＬＡＮ通信部との間に、パケットフィルタおよびネットワークアドレス変換部を含むルータ部を、前記ＳＩＰ処理部と並列に備え、
前記ＷＡＮ通信部および前記ＬＡＮ通信部は、受信したパケットのうち、少なくともＳＩＰリクエストメッセージのパケットを前記ＳＩＰ処理部に転送する請求項１乃至請求項５のいずれかに記載のＳＩＰ機器。
【請求項１】
ＳＩＰリクエストを処理するＳＩＰ処理部と、
ＷＡＮ側から着信したＳＩＰリクエストメッセージを、ＷＡＮ側から着信した旨の情報を付して前記ＳＩＰ処理部に転送するＷＡＮ通信部と、
ＬＡＮ側から着信したＳＩＰリクエストメッセージを前記ＳＩＰ処理部に転送するＬＡＮ通信部と、
を備え、
前記ＳＩＰ処理部は、ＷＡＮ側からＩＮＶＩＴＥリクエストメッセージが着信したとき、そのＩＮＶＥＩＴＥリクエストメッセージが、当方から事前にＲＥＧＩＳＴＥＲリクエストメッセージを送信して登録された局からのものである場合、このＩＮＶＩＴＥリクエストを受け付ける
ＳＩＰ機器。
【請求項２】
前記ＳＩＰ処理部は、さらに、ＷＡＮ側から着信したＩＮＶＩＴＥリクエストメッセージの送信元ＵＲＩが、ＬＡＮ側から受け付けたＲＥＧＩＳＴＥＲリクエストに基づき既に登録済のＵＲＩである場合、このＩＮＶＩＴＥリクエストを受け付ける
請求項１に記載のＳＩＰ機器。
【請求項３】
前記ＳＩＰ処理部は、さらに、ＷＡＮ側から着信したＩＮＶＩＴＥリクエストメッセージがピア・ツー・ピア接続のリクエストであり、且つ、送信元ＵＲＩが、ユーザの操作によって登録されるＵＲＩリストに既に登録済みのＵＲＩである場合、このＩＮＶＩＴＥリクエストを受け付ける
請求項１または請求項２に記載のＳＩＰ機器。
【請求項４】
前記ＳＩＰ処理部は、ＷＡＮ側から着信したＲＥＧＩＳＴＥＲリクエストメッセージを受け付けない請求項１乃至請求項３のいずれかに記載のＳＩＰ機器。
【請求項５】
前記ＳＩＰ処理部は、ＷＡＮ側から着信したＳＩＰリクエストメッセージを受け付けないとき、そのリクエストメッセージの送信元端末に対してエラーレスポンスを返信しない請求項１乃至請求項４のいずれかに記載のＳＩＰ機器。
【請求項６】
前記ＷＡＮ通信部および前記ＬＡＮ通信部との間に、パケットフィルタおよびネットワークアドレス変換部を含むルータ部を、前記ＳＩＰ処理部と並列に備え、
前記ＷＡＮ通信部および前記ＬＡＮ通信部は、受信したパケットのうち、少なくともＳＩＰリクエストメッセージのパケットを前記ＳＩＰ処理部に転送する請求項１乃至請求項５のいずれかに記載のＳＩＰ機器。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１２−８５００３（Ｐ２０１２−８５００３Ａ）
【公開日】平成２４年４月２６日（２０１２．４．２６）
【国際特許分類】
【出願番号】特願２０１０−２２７８１７（Ｐ２０１０−２２７８１７）
【出願日】平成２２年１０月７日（２０１０．１０．７）
【出願人】（０００１００７４６）アイコム株式会社 (273)
【Ｆターム（参考）】
【公開日】平成２４年４月２６日（２０１２．４．２６）
【国際特許分類】
【出願日】平成２２年１０月７日（２０１０．１０．７）
【出願人】（０００１００７４６）アイコム株式会社 (273)
【Ｆターム（参考）】
[ Back to top ]