JP5882436B1 - 通信装置 - Google Patents

Abstract

【課題】OSGiフレームワークでJava化されたサービス機能を提供するにあたり、現在のJavaの仕様の範疇で、バンドルの再配信による通信の切断を回避する。【解決手段】Native機能１３として、バンドル配信サーバ３５のドメイン名５１を解決するＤＮＳ機能部４１と、ドメイン名５１に対応するＩＰアドレスを記録するＩＰアドレス管理テーブル５２と、Java Native Interface(JNI)１６経由で送信されるパケットの宛先が、ドメイン名５１に対応する上記ＩＰアドレスであるか否かを判断するパケットフィルタリング機能部４２と、上記ＩＰアドレス宛のパケットについてパケット破棄を実行するルータ機能部４３とを備える通信装置とする。【選択図】図１

Description

この発明は、Java仮想マシン上のバンドルとして機能を搭載、更新、拡張できる通信装置に関する。

近年、ホームゲートウェイ（HGW）のような通信装置においても、Java（登録商標）仮想マシン（Java virtual machine:JVM）機能が搭載されるようになっている。このJVMを有する通信装置では、通信装置が本来有する機能であるネイティブ（Native）機能に加えて、Java領域で実行されるアプリケーションソフトウエアであるバンドルによって様々な機能を追加し、それをさらに更新することができる。すなわち、ネットワーク技術の進歩やサービスの追加に対応した新たな機能を、バンドルとして配信、更新されることで追加することができる。これにより、通信装置を必要なNative機能を有するハードウェアから開発し直さなくても、ソフトウェアであるバンドルの開発のみで対応できることが多くなる。HGWであれば機器を交換しなければならないケースが減り、個々の家庭での利用者にとって継続的に利用しやすくなる。また、サービスを提供する業者にとっては、最新の機能を速やかに普及させることができる。さらに、開発コストを削減することができる。さらにまた、エラーの修正やセキュリティのためのアップデートも容易にできる。

JVM上でバンドルを動かそうとすると、Native機能によって同じ機能を実装する場合に比べて、CPUやメモリなどの要求スペックが高くなる。このため、当初はGUI機能やUPnP機能などの一部機能のみがバンドルとして提供されていた。しかし、時代と共に機器の処理能力が向上することに伴い、より多くの機能をJVM上のバンドルとして提供可能になりつつある。

例えば、非特許文献１，２には、フレッツジョイント（登録商標）という名称で、ＩＰｖ６で構成された事業者ネットワーク（Next Generation Network:NGN）に接続する各家庭に設置されたHGWに、Javaを用いて機能を提供し、追加する方法が提示されている。

ここでは、Open Services Gateway Initiative（OSGi）と呼ばれる技術を用いている。ネットワーク上に設置したセンタシステムと呼ばれるサーバには、バンドルを配信可能に登録しておく。このバンドルを利用する、ゲートウェイ、ルータ、ＡＶ機器、自動車、携帯電話その他の通信装置は、JVM上にOSGiフレームワークと呼ばれる機能部を有する。OSGiフレームワークは、各々のバンドルのダウンロード、起動、停止、バンドル間サービス、セキュリティ機構、イベント処理などの基本機能を提供するものであり、各々のバンドルはJVMで機能するこのOSGiフレームワーク上で動作する。バンドルの中でも共通的に用いられる機能は基本サービスバンドルとして標準化されており、機器の用途に応じて開発されるバンドルは別途アプリケーションバンドルと呼ばれる。センタシステムからはどちらのバンドルも提供できる。

特許文献１には、アプリケーションプログラムの配信を行うサーバ装置に対して、サーバ用アプリケーションプログラムとアプリケーション用プログラムとを一括して配信し、サーバ装置が記憶手段に記憶させたクライアント用アプリケーションプログラムをクライアント端末に送信するステップを実行する旨が記載されている。これはバンドル配信するしくみそのものを開示したものである。

ところで、バンドルの中にはファームウェアのアップデートのように自動的に更新すべきものもあれば、ユーザが主体的に実行や更新の可否を決定することが必要なものもある。また、サービスを実現するためには複数のバンドルを適切に組み合わせてインストール及び実行しなければならない場合もある。特許文献２では、サーバ装置が個々のホームゲートウェイ装置を識別するデータベースを有し、それぞれのホームゲートウェイ装置に配信されているバンドルをサーバ装置が管理できるようにする旨が提示されている。また、悪意有るサーバから送付されたサービスを実行しないように、インストールに必要な情報のみをサーバ装置に返すインストーラをホームゲートウェイ装置に配布して、バンドルを実行する際には再度サーバ装置に実行の可否を確認できるようにすることも提案されている。

また、特許文献３には、家庭内に設置されたホーム機器で用いるバンドルについて、それらホーム機器と接続されたホームゲートウェイが管理できるように、ホーム機器管理テーブルを備え、ホームゲートウェイがホーム機器に対して必要なプログラムの配信を行う旨が記載されている。

特開２００６−３０２０３１号公報 特開２０１１−００３１１０号公報 特開２０１２−２３８９４３号公報

http://flets-w.com/joint/ https://flets.com/joint/

しかしながら、通信装置で提供するサービス機能をJava化し、機能をバンドルで提供していくと、特定の条件下でサービス機能を一時的に提供できなくなったり、切断せざるを得ない状況に陥ったりすることがある。これは、バンドルがバージョンアップした場合などに、センタシステムからバンドルが再配信されるときに起こる。バンドルがセンタシステムからホームゲートウェイなどの通信装置に再配信されると、即座にJVM上でインストールされ、そのバンドルは再起動が行われる。この再起動の際に、当該バンドルは当然に、そのバンドルによるサービス機能を提供することができなくなる。

例えばＩＰ電話などの呼処理を行うバンドルや、ＶＰＮ（Virtual Private Network）を構築するバンドル、IPsec（Security Architecture for Internet Protocol）などが、当該バンドルが再配信される前から通信処理を継続していても、再配信とインストール後の再起動によって当該通信処理が突然に切断されてしまう。具体的には確立済の通話呼が切断されたり、ＶＰＮ等のデータ通信が切断されたりといった事象が起こりうる。

通信中のバンドルについてのみ再配信を止めることができればこのような事態は回避できる。しかし、現在のJavaの仕様では各バンドルからの通信状態とバンドル再配信とを直接関連付けることができないため、現状では再配信を止めることができずに通信の切断が起きてしまう。

そこでこの発明は、OSGiフレームワークでJava化されたサービス機能を提供するにあたり、現在のJavaの仕様の範疇で、バンドルの再配信による通信の切断を回避することを目的とする。

この発明は、
Java Virtual Machine（JVM）上のOSGiフレームワークにインストールされるバンドルであり、外部ネットワーク上のバンドル配信サーバに対して問い合わせを行い、個々のバンドルがバージョンアップされている場合には当該バンドルのバージョンアップされたパッケージを上記バンドル配信サーバからダウンロードして更新させることができるOSAPエージェントを、上記JVM上に有する通信装置であって、
上記通信装置自体が有するNative機能として、
上記バンドル配信サーバのドメイン名を解決するＤＮＳ機能部と、
上記のドメイン名に対応するＩＰアドレスを記録するＩＰアドレス管理テーブルと、
Java Native Interface(JNI)経由で送信されるパケットの宛先が、上記ドメイン名に対応する上記ＩＰアドレスであるか否かを判断するパケットフィルタリング機能部と、
上記ＩＰアドレス宛のパケットについてパケット破棄を実行するルータ機能部と、
を有する通信装置により、上記の課題を解決したのである。

上記OSAPエージェントは上記バンドル配信サーバからバンドルをダウンロードする。そのためには当然に上記バンドル配信サーバに対して接続しなければならない。多くの通信装置は、ＩＰアドレスではなくドメイン名を含むアドレスで上記バンドル配信サーバを記録して、サーバが移転した場合でもサービスを対応可能にしている。従って、当該通信装置が上記バンドル配信サーバに接続するためには、その前にドメイン名を解決するステップが介在する。そこで、上記ＤＮＳ機能部により上記バンドル配信サーバのアドレスについて名前の解決が行われたときに、その解決された返答に含まれるＩＰアドレス（IPv6）を上記ＩＰアドレス管理テーブルに記録しておく。その後、上記JNI経由で当該ＩＰアドレス宛のパケットが送信されれば、そのパケットはバンドル配信サーバへの問い合わせであるとわかるので、これを破棄することで、OSAPエージェントは上記バンドル配信サーバからバンドルをダウンロードすることができなくなり、バンドルの再配信を遮断できる。

このようなパケットフィルタリング機能部でのフィルタリングとルータ機能部でのパケット破棄を、必要に応じて実行する。完全にバンドルの更新を止める場合は常時フィルタリングを行うことになるが、バンドルの更新を全く行わないと、バンドルによる機能追加やセキュリティ上の更新が可能であるOSGiフレームワークの利点が活かせない。このため、フラグを管理して上記のフィルタリング及びパケット破棄を行うか否かを設定する条件を記録するブロック条件データベースを設け、条件を満たす場合のみ上記フィルタリングを行うと好ましい。具体的には、通話が行われているか、ＶＰＮのように維持が必要な通信が行われている条件下で上記フィルタリングを行うと、それらの接続がバンドルの再配信に伴う再起動によって切断されることを防止できる。

この発明により、バンドルの再配信に伴う再起動によって、維持しなければならない通信が切断される事態を、防ぐことができる。

この発明にかかる通信装置の機能ブロック及び通信する装置の概念図 この発明にかかる通信装置が備えるブロック条件データベースの例図 ＩＰアドレス管理テーブルへの登録手順を示すフロー例図 （ａ）通話フラグの変更手順を示すフロー例図、（ｂ）通話フラグの変復手順を示すフロー例図 （ａ）継続通信フラグの変更手順を示すフロー例図、（ｂ）継続通信フラグの変復手順を示すフロー例図 実際にパケットの遮断を行う際のフロー例図

以下、この発明について実施形態の例を示して詳細に説明する。この発明は、呼処理やＶＰＮなどの継続的に接続状態が続く通信を取り扱う、ホームゲートウェイなどの通信装置である。

この通信装置の機能ブロックと、それと通信するその他の装置やネットワークの関係を図１に示す。通信装置１１は、NativeOS（図示せず）上に実装され実際のCPU上で動作するNative機能１３を有する。また通信装置１１はそれに加えて、仮想マシンであるJVM（Java Virtual Machine）１４を有している。このJVM１４には、バンドルと呼ばれるソフトウェアモジュールを動的に追加することができるOSGiフレームワーク１５が実装されている。JVM１４がNative機能１３と連携する際には、一方から他方の機能を利用するためのAPI（Application Programming Interface）のセットであるJNI（Java Native Interface）１６を介してデータや命令を相互に受け渡しする。

OSGiフレームワーク１５上では、後述する個々の機能を提供するバンドル（２２，２３……）の他に、バンドルを管理するバンドルであるOSAPエージェント２１が動作する。OSAPエージェント２１は、JNI１６を介して、後述する外部ネットワーク３１上に設けられたセンタサーバ３４内のバンドル配信サーバ３５と通信する。バンドル配信サーバ３５は、センタシステムとも呼ばれ、要求に応じてバンドルの配信及び再配信を行うサーバである。OSAPエージェント２１は定期的にバンドル配信サーバ３５に接続して、当該OSGiフレームワーク１５にインストールされたバンドルについて、更新があるか否かを問い合わせ、更新があれば新たなバージョンのバンドルをダウンロードし、インストールして、当該バンドルを再起動させる。

上記の外部ネットワーク３１のうち、通信装置１１とＵＮＩ（User-Network Interface）で直接接続される事業者ネットワーク３２には、通信装置１１がＤＮＳの名前の解決の問い合わせを行う先となるＤＮＳサーバ３６が設けられている。少なくともこのＤＮＳサーバ３６は、通信装置１１が記録しているバンドル配信サーバ３５のドメイン名から、その時点で稼働しているバンドル配信サーバ３５のＩＰアドレスを返答できる必要がある。事業者ネットワーク３２の中に設けることで、ドメイン名を一般で使われない固定のものとすることができる。

また、事業者ネットワーク３２の外には、複数のサーバからなりホームゲートウェイなどの通信装置１１を管理するためのセンタサーバ３４があり、その中にバンドルの配信を行うバンドル配信サーバ３５が設けてある。さらに、外部ネットワーク３１には、任意の対向装置３７があり、この発明にかかる通信装置１１と、ＩＰ電話やＶＰＮなどのバンドルによる機能によって継続的な通信を確立する。この対向装置３７とは、具体的には他の家庭のＨＧＷ、及びそれに接続する各家庭内ネットワークの機器などが挙げられる。通信装置１１は、これらの対向装置３７との間で、通話を行ったり、ＶＰＮを構築したり、その他の通信を行う。

なお、実際の処理としては、バンドル配信サーバ３５は、個々の通信装置１１が個々のバンドルについて配信を受ける契約があるか否かを別途把握した上で、通信装置１１に対して配信を行う。契約上は提供されていないサービスに関するバンドルを配信すると、管理上問題となるからである。これに対応するため、個々の通信装置１１はNative機能として、個々の通信装置１１を識別できる端末情報を有し、センタサーバ３４又はそれと接続可能なサーバに対してその端末情報を登録する端末登録インターフェース機能部を有する。

一方、センタサーバ３４又はそれと接続可能なサーバは、個々の通信装置１１の端末情報を管理し、また、個々の通信装置１１についてバンドルの配信サービスを受ける契約の有無を管理する端末管理部を有する。バンドル配信サーバ３５は、この端末管理部から、上記端末情報及び契約の有無についての情報を受け取り、個々の通信装置１１がバンドルを配信すべきものであるか否かを確認した上で、OSAPエージェント２１からの配信要求に応える。

通信装置１１は、演算装置（図示せず）と記憶部（図示せず）とを有し、家庭内ネットワーク３０と外部ネットワーク３１とのそれぞれに接続されるネットワークインターフェースを少なくとも有する。上記記憶部には、Native機能１３となるソフトウェアが格納され、演算装置によって実行される。

通信装置１１はNative機能１３として、以下に説明する機能部やデータベースなどのデータを有する。基本的な機能は一般的なＨＧＷなどに搭載されているものと同一であるが、この発明にかかる通信装置１１では、後述する追加要素とともに、それぞれの特有の実行手段を実行することで、この発明を構成する。

通信装置１１は、上記Native機能１３として、ドメイン名を解決するＤＮＳ機能部４１を有する。このＤＮＳ機能部４１は、上記記憶部に記録されているバンドル配信サーバ３５を示すドメイン名５１の名前の解決を行うＣＳドメイン名解決手段を実行できる。また、通常のルータ等が有するＤＮＳプロキシの機能として、家庭内ネットワーク３０からのＤＮＳの名前の解決の問い合わせを中継して、その他の名前の解決を行ってもよい。

通信装置１１の上記記憶部は、上記のドメイン名に対応するＩＰアドレスを記憶するＩＰアドレス管理テーブル５２を有する。この記憶は一時的なものであり、OSAPエージェント２１の定期的な動作の度に更新されることが望ましい。バンドル配信サーバ３５が移転する場合があるからである。

通信装置１１は、上記Native機能１３として、通過するパケットを監視するパケットフィルタリング機能部４２を有する。このパケットフィルタリング機能部４２は、JNI経由で経由されるパケットが、上記ドメイン名５１に対応するＩＰアドレスのパケットであるか否かを判断するフィルタリングである、ＣＳアドレスチェック手段を実行できる。またその他に、通常のルータ等が行うパケットの監視を行ってもよい。

通信装置１１は上記Native機能１３として、上記のパケットフィルタリング機能部４２と連携して、ルーティングやパケットの破棄を行うルータ機能部４３を有する。このルータ機能部４３は、上記のドメイン名５１に対応するＩＰアドレス宛のパケットについて、所定の条件を満たした際にパケット破棄を行う、ＣＳ宛パケット破棄手段を実行できる。またその他に、通常のＨＧＷが行うルーティングを行ってもよい。

また、通信装置１１は、上記Native機能１３として、JNI１６を経由する通信中のパケットのプロトコルと流量を監視する通信監視機能部４４を有すると好ましい。この通信監視機能部４４は、パケット破棄を実行する場合の条件を登録するブロック条件データベース５３の条件に従って、当該条件に合致する通信が行われているか否かを判断する通信状況監視手段を実行する。また、ブロック条件データベース５３は上記の記憶部中に保持される。

さらに、上記の記憶部中には、上記のＣＳ宛パケット破棄手段を実行するか否かを設定する破棄フラグ５４を有すると好ましい。破棄フラグ５４は１ｂｉｔである必要はなく、上記バンドル（２２、２３……）が行う通話やデータ通信などの種類ごとに、バンドルの更新を防止すべき条件を定めておき、それぞれについての複数のフラグの群からなるものでもよい。例えば、上記のバンドル（２２）が呼処理を行って通話が継続中であるか否かを示す通話フラグ５４ａ、呼処理以外のバンドル（２３）が行っているデータ通信の時間あたり容量や流れているプロトコルの種類により継続すべき通信が継続しているか否かをしめす継続通信フラグ５４ｂなどが挙げられる。具体的にこれらのフラグを立てるか否かの条件は、上記ブロック条件データベース５３において定めておくと、その条件によって通信監視機能部４４により上記通信状況監視手段が実行されて、パケットを適切に監視できるので好ましい。なお、これらのフラグ（５４ａ，５４ｂ）に関するバンドルだけでなく、一旦再起動されるとサービスが継続できなくなって不都合が生じるその他のバンドルがあれば、それに該当する条件を上記ブロック条件データベース５３に登録して同様の運用を行うと好ましい。基本的には、複数のフラグからなる場合でも、そのうちのいずれかのフラグによって、上記のＣＳ宛パケット破棄手段を実行する値となっていれば、上記のＣＳ宛パケット破棄手段を実行する。それぞれのフラグを分けることで、どの要因によってバンドルの再配信を一時停止しているのかを把握しやすくなる。

さらにまた、通信装置１１は、上記のブロック条件データベース５３の条件を含むNative機能１３に関する設定を、ＷＥＢブラウザを有する端末からのアクセスに応じて閲覧、操作可能であるｗｅｂページを生成し、そのｗｅｂページからの通信により設定変更を行うｗｅｂ−ＧＵＩ（Graphical User Interface）４６を有する。これはルータ機能部４３やパケットフィルタリング機能部４２などが通常のルータなどとして動作する際の条件などを設定できるものでもよい。

この通信装置１１では、ブロック条件データベース５３にフィルタリングを行う条件を設定可能とする。具体的には、通信装置１１を提供する事業者が、センタサーバ３４を構成するサーバから自動的に管理できるようにしてもよいし、家庭内ネットワーク３０を管理する利用者が管理できるようにしてもよい。家庭内ネットワーク３０を管理する利用者が管理できるようにする場合は、ｗｅｂ−ＧＵＩ４６が生成するｗｅｂページを介して、ブロック条件データベース５３の値を変更可能とする。この変更の受け付けは、基本的には、家庭内ネットワーク３０に属する端末３９から、ｗｅｂブラウザを用いて通信装置１１にアクセスした場合に行う。

少なくともこのブロック条件データベース５３は、フィルタ処理を行うか否かの設定を有する。この設定は破棄フラグ５４（通話フラグ５４ａ、継続通信フラグ５４ｂ、……ｅｔｃ．）そのものではなく、破棄フラグ５４の真偽値を変更するか否かを判断するために、通信監視機能部４４が上記の通信状況監視手段を実行するか否かの設定である。

ブロック条件データベース５３の例を図２に示す。この例では、通信の中でも、ＳＩＰプロトコルによる呼処理、すなわち音声通信を有する際には、他のデータ通信とは別枠で、フィルタリングを行うか否かの条件を設定可能としている（ＩＤ１）。この項目は、「フィルタする」と「フィルタしない」の２種類の設定値を取り得る。「フィルタする」に設定されている場合は、上記の通信状況監視手段によって音声通信を把握されたときに、パケット破棄を実行する設定となる。このように、呼処理の場合はフィルタリングにおいて基本的に有無のみを判断する。

一方で、呼処理以外のデータ通信についても、フィルタリングを行うか否かの条件を設定可能としている（ＩＤ２）。この項目も、「フィルタする」と「フィルタしない」の２種類の設定値を取り得る。このＩＤ２が「フィルタしない」の設定値となっているとき、呼処理以外のデータ通信については、そもそも内容をチェックするフィルタリング自体を行わない。一方、このＩＤ２が「フィルタする」になっているとき、データ通信のパケットについてフィルタリングする。このとき、該当するデータ通信があれば自動的に上記パケット破棄を行う設定とするのではなく、ＩＤ２の条件とａｎｄの条件で、フィルタリングされるデータ通信の、単位時間内における合計データ量の平均値である速度の範囲（kbps）を設定可能とするとよい（ＩＤ３、ＩＤ４）。このうちパケット破棄を実行する範囲の最小値であるＩＤ３を設定することで、微小量の通信だけがやりとりされている場合にはバンドル（２２，２３……）の更新を可能にすることができる。特に持続の必要性が高いわけではない通信がやりとりされているだけで上記パケット破棄を実行していると、バンドルの更新をほとんど行えなくなってしまうからである。図２の例では、ｋｂｐｓ単位で通信速度を規定し、実際のデータ通信量がそれを下回る場合には、パケット破棄を行わない、すなわち、データ通信の条件ではバンドルの更新を遮らないものとする。ただしもちろん、データ通信とは別枠で上記の呼処理についての項目がある場合には、そちらの条件が満たされる場合にはバンドルの更新を遮ることとなる。一方、上限を設定することもできる（ＩＤ４）。なお、図２ではＩＤ４は空欄になっており、上限が設定されていない状態を示す。

また、ＩＤ２でフィルタリングするか否か設定されるデータ通信について、全てのデータ通信を対象とするのではなく、プロトコル毎に対象とするか否かを変更できると好ましい。バンドルの再起動に伴って切断しても特に問題とならない通信を担うプロトコルと、そうでないプロトコルとを分けて扱うことができる。図２の例では、ｈｔｔｐプロトコル（ＩＤ５）、ｆｔｐプロトコル（ＩＤ６）、ｔｅｌｎｅｔプロトコル（ＩＤ７）を挙げている。それぞれのプロトコルについて「対象とする」と「対象としない」の２種類の設定値を取りうる。図２の例ではｈｔｔｐプロトコルのみ対象としており、ｈｔｔｐプロトコルであるデータ通信のみについて、ＩＤ３及びＩＤ４で規定される範囲の通信速度でデータがやり取りされている場合に、フィルタリングを行う設定となる。ｆｔｐやｔｅｌｎｅｔで別途通信がされていても、特にフィルタリングの際に考慮しない設定となっている。

ブロック条件データベース５３の構成は図２の構成に限られるものではなく、他の様々なプロトコルや数値の上限及び下限、ＩＰアドレスやポート番号などについて設定されるものでもよい。また、通信条件以外にも、通信装置１１自体の状態や、その他のソフトウェア又はハードウェアとして認識可能な条件が設定可能であってもよい。

この発明を図１の構成要素を備えた実施形態にかかる通信装置１１で実行し、バンドルの更新を阻止する際の手順を、図３以下のフローとともに説明する。まず前提として、通常の環境で通信装置１１が実行されている状態とする。ホームゲートウェイであれば、NAPT変換を行って家庭内ネットワーク３０と外部ネットワーク３１との通信を中継したり、ＤＮＳプロキシとして動作したりする。

図３に、通信を遮断する宛先であるバンドル配信サーバ３５のＩＰアドレスを登録する際のフロー例図を示す。OSAPエージェント２１は、定期的にバンドル配信サーバ３５へ問い合わせを行う。定期的とは例えば１日毎、一週間毎などである。バンドル配信サーバ３５のアドレスは、上記記憶部中にドメイン名５１として記録されており、ドメイン名５１を指定して通信を行う。そのためにはまず、ＤＮＳの名前を解決しなければならず、OSAPエージェント２１はJNI１６経由でＤＮＳの名前の解決要求を送信する。なお、ＤＮＳ機能部４１はJNI１６経由の要求だけでなく、家庭内ネットワーク３０からのＤＮＳの名前の解決の要求に対しても、ＤＮＳプロキシとして作用する。このため、ＤＮＳ機能部４１は通信装置１１の内外から名前の解決の要求を受信する（Ｓ１０２）。

ＤＮＳ機能部４１が受信した名前の解決要求が、上記のドメイン名５１と完全一致しなかった場合（Ｓ１０３→Ｎｏ）、ＤＮＳ機能部４１は通常のＤＮＳプロキシとして動作して、ＤＮＳサーバ３６へＤＮＳの名前の解決要求を中継する。当然に、要求に対する返答結果に含まれるＩＰｖ６アドレスを、要求を送信した家庭内ネットワーク３０内の機器や、通信装置１１内の他の構成要素に返却する（Ｓ１０４）。それらのその後の通信は特に阻害されない。

一方、ＤＮＳ機能部４１が受信した名前の解決要求が、上記のドメイン名５１と完全一致した場合（Ｓ１０３→Ｙｅｓ）、ＤＮＳプロキシとしてＤＮＳサーバ３６へＤＮＳの名前の解決を中継し、その返答結果であるＩＰｖ６アドレスをOSAPエージェント２１に返却する上記ＣＳドメイン名解決手段を実行する（Ｓ１０５）。このときさらにＤＮＳ機能部４１は、その返答結果に含まれるＩＰｖ６アドレスを、ＩＰアドレス管理テーブル５２に記録するＣＳアドレス登録手段を実行する（Ｓ１０６）。この登録したＩＰｖ６アドレスを、この後のフィルタリングの際に使用する。なお、ＩＰアドレス管理テーブル５２に記録したＩＰｖ６アドレスは、次にＳ１０６が実行されたときに上書きされる。ＤＮＳサーバ３６から返答されるバンドル配信サーバ３５のＩＰｖ６アドレスが変更になっている場合があるからである。

いずれにしても、ＤＮＳ機能部４１はＤＮＳプロキシとして動作し、返答を受けた通信装置１１内の機能部やバンドル、通信装置１１外の家庭内ネットワーク３０にある機器などは、その返答されたＩＰｖ６アドレス宛に通信を行う。後述する条件による遮断が無ければ、そのまま通信は続行される。OSAPエージェント２１がバンドル配信サーバ３５と通信しようとした場合にはそのまま接続がされ、バンドル（２２，２３……）が更新されている場合には配信され、OSGiフレームワーク１５上でバンドルが再起動される。

次に、バンドルの配信による再起動を防ぐために、通信装置１１が破棄フラグ５４の設定値を変更する際の手順を説明する。ここでは、破棄フラグ５４が、通話フラグ５４ａと、継続通信フラグ５４ｂとの２つを有する場合について説明する。まず、通話フラグ５４ａについて図４（ａ）（ｂ）を用いて説明する。

まず（Ｓ１１１）、Native機能１３の通信監視機能部４４が通信状況監視手段を実行し、JNI１６を経由した呼処理が行われていることを認識する（Ｓ１１２）。具体的には、JNI１６を通過するパケットの中に、呼処理に用いるＳＩＰプロトコルが含まれていることで認識することができる。呼処理が行われていることを認識した際に、上記のブロック条件データベース５３の設定値が、呼処理について「フィルタリングする」ことを許可する値になっていなければ（Ｓ１１３→Ｎｏ)、特に変更されることはない（Ｓ１１５）。一方、呼処理について「フィルタリングする」ことを許可する値になっていれば（Ｓ１１３→Ｙｅｓ）、通話フラグ５４ａを、通話があることでバンドルの再配信を遮断する、すなわち上記パケット破棄を行う設定値に変更するフラグ変更手段を実行する（Ｓ１１４）。この通話フラグ５４ａを用いる処理については後述する。

なお、呼処理のみについてではなく、より大きな区分についてフィルタリングする条件であって該当する場合も同様のフローとなる。例えば呼処理とデータ通信とを含む全ての通信について、フィルタリングする条件でブロック条件データベース５３の値が設定されていたら、上記と同様の処理を行うことができる。また、Ｓ１１３における分岐の際に、数値上の上限や下限を含むさらなる条件が付け加わっても良い。

その後（Ｓ１２１）、Native機能１３の通信監視機能部４４が上記通信状況監視手段を実行し続け、JNI１６を経由した呼処理が終了したことを認識する（Ｓ１２２）。具体的には、呼処理を終了するパケットを認識したり、一定時間に亘って呼処理に関するパケットが観測されないことによって認識される。認識されたら、通話フラグ５４ａを、バンドルの配信を遮断しない、すなわち上記パケット破棄を行わない設定値に変更するフラグ変復手段を実行する（Ｓ１２３）。呼処理が終わったため、バンドルの更新を遮る必要がなくなるからである。

同様に、所定のデータ通信が行われている際に、バンドルの配信による再起動を防ぐために、通信装置１１が破棄フラグ５４の継続通信フラグ５４ｂを変更する場合について、図５（ａ）（ｂ）を用いて説明する。

まず（Ｓ１４１）、Native機能１３の通信監視機能部４４が通信状況監視手段を実行し、JNI１６を経由した呼処理以外のデータ通信が行われていることを認識する（Ｓ１４２）。データ通信を認識した際に、上記のブロック条件データベース５３の設定値が、データ通信について「フィルタリングする」ことを許可する値になっていなければ（Ｓ１４３→Ｎｏ)、特に変更されることはなく（Ｓ１４６）、バンドルの配信を遮断しない。一方、データ通信について「フィルタリングする」ことを許可する値になっていれば（Ｓ１４３→Ｙｅｓ）、さらに、そのデータ通信がブロック条件データベース５３で設定されている他の条件を満たすか否かを判断するフィルタリングを行う。図２のブロック条件データベース５３の場合は、ｈｔｔｐプロトコルのデータ通信について（ＩＤ５）、通信量の下限値（ＩＤ３）と上限値（ＩＤ４）とで規定される範囲に含まれるか否かを判断する（Ｓ１４４）。上記のプロトコルに該当するデータ通信が範囲外の通信量であれば（Ｓ１４４→Ｎｏ)、特に変更されることはなく、バンドルの配信を遮断しない。一方、上記のプロトコルに該当するデータ通信の通信量が規定される範囲内であれば（Ｓ１４４→Ｙｅｓ）、継続通信フラグ５４ｂを、継続すべき通信があることでバンドルの配信を遮断する設定値に変更するフラグ変更手段を実行する（Ｓ１４５）。

その後（Ｓ１５１）、Native機能１３の通信監視機能部４４が通信状況監視手段を実行し続け、JNI１６を経由した上記の条件を満たすデータ通信が終了したことを認識する（Ｓ１５２）。具体的には、上記通信状況監視手段を実行し続けて、やり取りされる通信のプロトコルや単位時間内における送受信の合計データ量等を監視し続け、その値がブロック条件データベース５３に規定される設定値範囲などの条件から外れたら、継続通信フラグ５４ｂを、バンドルの配信を遮断しない設定値に変更するフラグ変復手段を実行する（Ｓ１５３）。継続すべき通信が終わったため、バンドルの更新を遮る必要がなくなるからである。

これらの破棄フラグ５４の設定値に応じて、実際のパケットを破棄するか否かの判断を行う。このフローを図６とともに説明する。まず（Ｓ１７１）、JNI１６からパケットを受信したら（Ｓ１７２）、ルータ機能部４３は、それを外部ネットワーク３１や家庭内ネットワーク３０へ中継するために、該当のパケットの宛先を確認する（Ｓ１７３）。この発明では、Native機能１３中のパケットフィルタリング機能部４２が、当該パケットの宛先と、Ｓ１０６にてＩＰアドレス管理テーブル５２に記録されたバンドル配信サーバ３５のＩＰｖ６アドレスとが一致するか否かを判断するＣＳアドレスチェック手段を実行する（Ｓ１７４）。一致しなければ（Ｓ１７４→Ｎｏ）、ルータ機能部４３にそのまま受け渡し、宛先のアドレスに基づいて外部ネットワーク３１又は家庭内ネットワーク３０へ、通常のルーティングを行うルーティング手段を実行する（Ｓ１７５）。

一方、ＩＰアドレス管理テーブル５２に記録されたバンドル配信サーバ３５のＩＰｖ６アドレスと、当該パケットの宛先アドレスとが一致する場合（Ｓ１７４→Ｙｅｓ）、当該パケットは、バンドル配信サーバ３５に対するOSAPエージェント２１の再配信の問い合わせパケットであるといえる。その場合、破棄フラグ５４をチェックして、バンドルの再起動を止めるべき条件に合致すれば、パケットを破棄する上記パケット破棄手段を実行する（Ｓ１８１〜）。通話フラグ５４ａか（Ｓ１８１）、継続通信フラグ５４ｂか（Ｓ１８２）、それとも図示しないいずれかの条件について付されたフラグかのいずれかが、バンドルの再配信を遮断すべき設定値になっていれば、ルータ機能部４３は、そのパケットを破棄するＣＳ宛パケット破棄手段を実行する（Ｓ１８３）。これにより、これら破棄フラグ５４が該当する設定値になっている間は、OSAPエージェント２１からのパケットはバンドル配信サーバ３５に到達せず、バンドルの再配信がされることがない。すなわち、バンドルの更新後に起こる再起動によって、継続中の呼処理や所定のデータ通信が切断されてしまうという事態が生じることを防ぐ。

一方、いずれのフラグも該当しなければ、バンドルの再配信による再起動が起きても問題ないと判断され（Ｓ１８１→Ｎｏ，Ｓ１８２→Ｎｏ）、OSAPエージェント２１からのパケットがルータ機能部４３によって適切にルーティングされ、事業者ネットワーク３２中のバンドル配信サーバ３５に送信される（Ｓ１７５）。バンドルが更新されていれば、そのまま通信装置１１にバンドルが配信され、更新された後、バンドルが再起動する。このとき、当該バンドルによって継続していたセッションは切断される。

１１ 通信装置
１３ Native機能
１４ JVM
１５ OSGiフレームワーク
１６ JNI
２１ OSAPエージェント
２２ 呼処理用バンドル
２３ データ通信用バンドル
３０ 家庭内ネットワーク
３１ 外部ネットワーク
３２ 事業者ネットワーク
３４ センタサーバ
３５ バンドル配信サーバ
３６ ＤＮＳサーバ
３７ 対向装置
３９ 端末
４１ ＤＮＳ機能部
４２ パケットフィルタリング機能部
４３ ルータ機能部
４４ 通信監視機能部
４６ Ｗｅｂ−ＧＵＩ
５１ ドメイン名
５２ ＩＰアドレス管理テーブル
５３ ブロック条件データベース
５４ 破棄フラグ
５４ａ 通話フラグ
５４ｂ 継続通信フラグ

Claims (3)

1. Java Virtual Machine（JVM）上のOSGiフレームワークにインストールされるバンドルであり、外部ネットワーク上のバンドル配信サーバに対して問い合わせを行い、個々のバンドルがバージョンアップされている場合には当該バンドルのバージョンアップされたパッケージを上記バンドル配信サーバからダウンロードして更新させることができるOSAPエージェントを、上記JVM上に有する通信装置であって、
   上記通信装置自体が有するNative機能として、
   上記バンドル配信サーバのドメイン名を解決するＤＮＳ機能部と、
   上記のドメイン名に対応するＩＰアドレスを記録するＩＰアドレス管理テーブルと、
   Java Native Interface(JNI)経由で送信されるパケットの宛先が、上記ドメイン名に対応する上記ＩＰアドレスであるか否かを判断するパケットフィルタリング機能部と、
   上記ＩＰアドレス宛のパケットについてパケット破棄を実行するルータ機能部と、
   を有する通信装置。
2. 上記Native機能として、
   パケットのプロトコルと通信量とを監視する通信監視機能部と、
   上記ルータ機能部によるパケット破棄を実行する際の条件を登録するブロック条件データベースと、
   上記監視の結果が、上記ブロック条件データベースに登録された条件を満たす際に、パケット破棄を実行する旨を設定する破棄フラグと、
   を有し、
   上記破棄フラグが上記条件に合致する場合に上記ルータ機能部によるパケット破棄を実行する、
   請求項１に記載の通信装置。
3. 上記ブロック条件データベースが、呼処理についての条件を有し、
   上記通信監視機能部がSIPプロトコルによる呼処理を検知した場合、パケット破棄を実行するように上記破棄フラグを設定する、
   請求項２に記載の通信装置。

Images