呼制御装置、方法及びプログラム
【課題】メインメモリ上で更新された呼制御アプリケーション及び呼制御情報を不揮発性メモリに保存できるようにする。
【解決手段】本発明の呼制御装置は、揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を揮発性メモリにローディングして呼処理を行い、不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置で、ＲＡＭディスク領域の書き込み情報から、呼処理により揮発性メモリにローディングされた呼制御アプリケーション、呼制御情報を格納する不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理手段と、更新検知処理手段の検知に基づいてＲＡＭディスク領域の書き込み情報のうち呼制御アプリケーション、呼制御情報の領域に対する書き込み情報の不揮発性メモリへの書き込みを行う書き込み処理手段を備える。
【解決手段】本発明の呼制御装置は、揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を揮発性メモリにローディングして呼処理を行い、不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置で、ＲＡＭディスク領域の書き込み情報から、呼処理により揮発性メモリにローディングされた呼制御アプリケーション、呼制御情報を格納する不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理手段と、更新検知処理手段の検知に基づいてＲＡＭディスク領域の書き込み情報のうち呼制御アプリケーション、呼制御情報の領域に対する書き込み情報の不揮発性メモリへの書き込みを行う書き込み処理手段を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼制御装置、方法及びプログラムに関し、例えば、交換機のメインメモリで更新された呼制御情報（例えば、局データ、加入者データ等）及び呼制御アプリケーションを適宜に不揮発性メモリに記憶する呼制御装置、方法及びプログラムに適用し得るものである。
【背景技術】
【０００２】
旧来の電子交換機では、交換システムで動作させる呼制御アプリケーション及び局データを、揮発性メモリに格納した状態で運用する構成をとるのが一般的である。
【０００３】
電子交換機に電源を投入すると、呼制御アプリケーション及び局データが、不揮発性メモリから揮発性メモリに呼び込まれる。そのため、電子交換機の呼制御アプリケーション及び局データの更新を行う際に、運用中のデータ更新のための揮発性メモリへの更新作業と、次回の電子交換機の起動の際に読み出されることとなる不揮発性メモリへの更新作業の２つの更新作業が必要になる。
【０００４】
また、現代の電子交換機として、揮発性メモリとしてのＤＩＭＭ（Dual Inline Memory Module）や不揮発性メモリとしてのＳＳＤ（Solid State Drive）の採用、ＲＡＭディスクによる揮発性メモリ及び不揮発性メモリの管理方法の適用がある。
【０００５】
現代の電子交換機においても、呼制御アプリケーション及び局データの更新の際には、揮発性メモリと不揮発性メモリとの双方の更新が必要である。
【０００６】
例えば、特許文献１に記載の技術は、操作者が保守コンソールから交換機のメモリ書き込みプログラム及びメモリ読み出しプログラムを制御し、メモリから情報を出し入れするという技術が記載されている。
【０００７】
さらに、現代の電子交換機の構成としては、例えば汎用的なＰＣ／ＡＴ互換のＭＢ（Main Bord）で外部記憶装置としてＳＳＤを有し、メインメモリとしてＤＩＭＭを有するものが挙げられる。
【０００８】
この場合、ＤＩＭＭ上にＲＡＭディスクを形成し、ＤＩＭＭを記憶装置のように扱える仮想ディスク（Virtual Disk）の技術が利用されることがある。ところが、ＲＡＭディスク領域は揮発性メモリ（ＤＩＭＭ）内に生成した仮装ディスク領域なので、例えば停電などにより交換機への給電が絶たれシステムダウンすると、ＲＡＭディスク上のデータは、交換機のリセットに伴い消去されるため、適宜、ＲＡＭディスクの内容をＳＳＤに反映する必要がある。
【０００９】
このＲＡＭディスクに適用される仮想ディスクの技術としてＥＷＦ（Enhanced Write Filter）等が存在し、例えば特許文献２には、ＲＡＭディスクの内容をＤＭＡ転送で磁気ディスクに書き込む方法が示されている。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開平５−３００２２９号公報
【特許文献２】特開平２−３９３４２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ところで、汎用的なＭＢに、不揮発性メモリのＳＳＤの記憶装置、揮発性メモリのＤＩＭＭのメモリを有し、ＤＩＭＭ上にＲＡＭディスクを形成して動作する交換機において、電源が投入されＯＳが起動すると、例えばＯＳ状態情報、ＯＳ起動ログ、ネットワークからのアクセスログ、呼制御アプリケーションの起動ログ、呼制御により発生する課金情報等を記憶するためにディスクＩ／Ｏが発生する。このディスクＩ／Ｏは、ＥＷＦの仕組みでＲＡＭディスク領域に書き込み情報として保存される。
【００１２】
また、例えばバグの修正や機能追加等のために作業者がＳＳＤ内に記憶されている呼制御アプリケーションをバージョンアップする場合や、例えば交換機の収容端末の増減に伴って局データを更新する場合にもディスクＩ／Ｏが行われ、ディスクＩ／ＯがＥＷＦの仕組みでＲＡＭディスク領域に書き込み情報として保存される。
【００１３】
しかしながら、呼制御アプリケーション及び局データは、交換機として最低限必要な要素であり、直ちにＳＳＤに記憶する必要がある。
【００１４】
また、記憶装置として適用される不揮発性メモリのＳＳＤは、その書き込み・削除回数に限界があるため（例えば１０万回）、なるべくＳＳＤへの書き込み・削除回数を減らし、ＳＳＤの寿命を延命させることが望まれる。
【００１５】
そのため、呼制御アプリケーションと呼制御情報（例えば局データなど）が更新されたときに、ＲＡＭディスク領域に保存される不揮発性メモリに対する書き込み情報の内容が不揮発性メモリ上に反映させることができ、かつ、書き込み・削除回数が限定されている不揮発性メモリの寿命を延命させることができる呼制御装置、方法及びプログラムが求められている。
【課題を解決するための手段】
【００１６】
第１の本発明の呼制御装置は、揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を揮発性メモリにローディングして呼処理を行い、不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置において、（１）ＲＡＭディスク領域の書き込み情報から、呼処理により揮発性メモリにローディングされた呼制御アプリケーション及び又は呼制御情報を格納する不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理手段と、（２）更新検知処理手段の検知に基づいてＲＡＭディスク領域の書き込み情報のうち呼制御アプリケーション及び又は呼制御情報の領域に対する書き込み情報の不揮発性メモリへの書き込みを行う書き込み処理手段を備えることを特徴とする。
【００１７】
第２の本発明の呼制御方法は、揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を揮発性メモリにローディングして呼処理を行い、不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置の呼制御方法において、（１）更新検知処理手段が、ＲＡＭディスク領域の書き込み情報から呼処理により揮発性メモリにローディングされた呼制御アプリケーション及び又は呼制御情報を格納する不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理工程と、（２）書き込み処理手段が、更新検知処理手段の検知に基づいてＲＡＭディスク領域の書き込み情報のうち呼制御アプリケーション及び又は呼制御情報の領域に対する書き込み情報の不揮発性メモリへの書き込みを行う書き込み処理工程を有することを特徴とする。
【００１８】
第３の本発明の呼制御プログラムは、揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を揮発性メモリにローディングして呼処理を行い、不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置を、（１）ＲＡＭディスク領域の書き込み情報から、呼処理により揮発性メモリにローディングされた呼制御アプリケーション及び又は呼制御情報を格納する不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理手段と、（２）更新検知処理手段の検知に基づいてＲＡＭディスク領域の書き込み情報のうち呼制御アプリケーション及び又は呼制御情報の領域に対する書き込み情報の不揮発性メモリへの書き込みを行う書き込み処理手段として機能させることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、呼制御アプリケーションと呼制御情報（例えば局データなど）が更新されたときに、ＲＡＭディスク領域に格納される書き込み情報の内容が不揮発性メモリ上に反映させることができ、かつ、書き込み・削除回数が限定されている不揮発性メモリの寿命を延命させることができる。
【図面の簡単な説明】
【００２０】
【図１】第１〜第５の実施形態の交換機の内部構成を示す構成図である。
【図２】第１〜第５の実施形態の通話システムの構成を示す構成図である。
【図３】第１の実施形態の交換機において、フラッシュメモリ部への書き込み処理を示すフローチャートである。
【図４】第１の実施形態の交換機においてフラッシュメモリ部への書き込み処理示すフローチャートである。
【図５】第１の実施形態の書き込み処理の機能部の構成を示すブロック図である。
【図６】フラッシュメモリ部への書き込み処理を説明する説明図である。
【図７】第２の実施形態の書き込み処理の機能部の構成を示すブロック図である。
【図８】第２の実施形態の交換機においてフラッシュメモリ部への書き込み処理示すフローチャートである。
【図９】第３の実施形態の書き込み処理の機能部の構成を示すブロック図である。
【図１０】第３の実施形態の交換機においてフラッシュメモリ部への書き込み処理示すフローチャートである。
【図１１】フラッシュメモリ部の保存領域の構成と、局データ及び呼制御プログラムの書き換えとを説明する説明図である。
【図１２】第４の実施形態のフラッシュメモリ部への書き込みを判断する判断テーブルの構成を示す構成図である。
【図１３】第５の実施形態のフラッシュメモリ部への書き込みを判断する判断テーブルの構成を示す構成図である。
【発明を実施するための形態】
【００２１】
（Ａ）第１の実施形態
以下では、本発明の呼制御装置、方法及びプログラムの第１の実施形態について、図面を参照しながら説明する。
【００２２】
第１の実施形態は、揮発性メモリ上にＲＡＭディスク領域を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報（局データ、加入者データ等）を揮発性メモリにローディングして呼制御を行い、不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置に、本発明を適用する実施形態を説明する。
【００２３】
（Ａ−１）第１の実施形態の構成
図２は、第１の実施形態の通話システムの全体構成を示す全体構成図である。また、図１は、第１の実施形態の交換機の構成を示す構成図である。
【００２４】
図２において、第１の実施形態の通話システム１０は、交換機１、電話端末２−１〜２−ｎ（ｎは正の整数）を有して構成される。
【００２５】
図１において、第１の実施形態の交換機１は、制御部１１、通信部１２、ＲＡＭ部１３、フラッシュメモリ部１５を少なくとも有して構成される。
【００２６】
通信部１２は、接続する通信回線との間で、所定の通信方式に従って情報の送受信を行うものである。通信部１２の接続回線は、例えばアナログ回線、ＩＰ（インターネットプロトコル）回線、ディジタル回線、光回線等を適用することができ、又通信方式は、種々の方式を適用することができる。
【００２７】
制御部１１は、交換機１の呼制御機能を司るものであり、例えばＣＰＵ等が該当する。
【００２８】
ＲＡＭ部１３は、揮発性メモリであり、ＤＩＭＭを適用することができる。また、ＲＡＭ部１３は、メモリ領域上の一部にＲＡＭディスク部１４を形成するものである。
【００２９】
ＲＡＭディスク部１４は、フラッシュメモリ部１５に対する書き込み情報を格納する領域である。
【００３０】
フラッシュメモリ部１５は、不揮発性メモリであり、例えばＳＳＤを適用することができる。また、フラッシュメモリ部１５は、制御部１１の制御を受けて、ＲＡＭディスク部１４に格納される書き込み情報の内容を保存するものである。さらに、フラッシュメモリ部１５は、ＯＳ（オペレーティングシステム）１６、呼制御アプリケーション１７、局データ１８を格納する。この呼制御アプリケーション１７と局データ１８を、制御部１１がＲＡＭ１３に呼び込み（ローディング）呼制御に利用する。
【００３１】
ＯＳ１６は、ＲＡＭ部１３上に生成されたＲＡＭディスク部１４を使用可能にするオペレーティングシステムであり、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｗｉｎｄｏｗｓ（登録商標） ｅｍｂｅｄｄｅｄが適用できる。
【００３２】
続いて、交換機１において、ＲＡＭ部１３にローディングされた呼制御アプリケーション１７及び局データ１８のいずれか又は両方を格納するフラッシュメモリ部１５の領域に対する書き込み情報を検知する場合に、その検知に基づいてＲＡＭディスク部１４の書き込み情報のうち呼制御アプリケーション１７及び局データ１８のいずれか又は両方の書き込み情報の内容を、フラッシュメモリ部１５に書き込みを行う書き込み処理の機能部を説明する。
【００３３】
なお、以下では、局データ１８が更新された場合に、更新された局データ１８をフラッシュメモリ部１５に書き込む場合を例示するが、呼制御アプリケーション１７の更新の場合も基本的には同様に機能する。
【００３４】
図５は、ＲＡＭディスク部１４の内容をフラッシュメモリ部１５に書き込み行う書き込み処理を実現する機能部の構成を示すブロック図である。
【００３５】
図５に示すように、第１の実施形態の書き込み処理を実現する機能部としては、局データ更新検知部２１、局データ呼び込み制御部２２、局データ復旧部２３、ＣＰＵ使用率確認部２４、書き込み制御部２５がある。
【００３６】
局データ更新検知部２１は、呼制御の開始後に、ＲＡＭディスク部１４に格納される書き込み情報から、ＲＡＭ部１３にローディングされた局データ１８を格納するフラッシュメモリ部１５の領域に対する書き込み情報を検知することで局データ１８が更新されたか否かを検知するものである。
【００３７】
ここで、局データ１８の更新検知方法としては、例えば、フラッシュメモリ部１５に格納された局データ１８のファイル名に対する書き込み情報を検知する方法等を適用することができる。このファイル名は、ＯＳ１６がフラッシュメモリ部１５をマウントした際のファイルシステムに基づくファイル名で、ファイルシステム中に存在するファイルの領域を特定する識別子である。また、ファイル名の表し方としては、単にファイル名を示す場合と、ファイルシステム中のディレクトリ構造を含めた絶対パス又は相対パスで示す場合が適用できる。
【００３８】
また、局データ更新検知部２１は、局データ１８を格納するフラッシュメモリ部１５の領域に対する書き込み情報を検知するために、局データ１８がローディングされるときに局データ１８のファイル名を保持しておく。
【００３９】
また、呼制御アプリケーション１７の更新検知方法としては、上記のファイル名に対する書き込み情報を検知する方法に加え、例えば、呼制御アプリケーション１８のバージョン変化を検知する方法等を適用することができる。この場合、局データ更新検知部２１は、呼制御アプリケーション１７を格納するフラッシュメモリ部１５の領域に対する書き込み情報を検知するために、呼制御アプリケーション１７がローディングされるときに呼制御アプリケーション１７のファイル名又はバージョンを保持しておく。バージョンの情報は、呼制御アプリケーション１７を呼び込んだ結果、出力する自律メッセージから受け取ることで取得できるものである。
【００４０】
局データ呼び込み制御部２２は、局データ更新検知部２１が局データ１８の更新を検知した場合に、呼制御アプリケーション１７に対して、更新された局データ１８を呼び込ませるものである。
【００４１】
局データ復旧部２３は、呼制御アプリケーション１７が更新された局データ１８を呼び込む際に、更新された局データ１８の呼び込みが失敗したときに、それ以前の局データ１８を復旧するものである。
【００４２】
ＣＰＵ使用率確認部２４は、呼制御アプリケーション１７により更新された局データ１８の呼び込みが正常に行われた場合に、ＣＰＵ使用率が閾値を超えているか否かを確認するものである。
【００４３】
書き込み制御部２５は、ＲＡＭディスク部１４に格納されている内容を、フラッシュメモリ部１５に書き込み制御するものである。
【００４４】
ここで、後述するフラッシュメモリ部１５（例えばＳＳＤ）は、書き込み制限が設けられている（例えば１０万回）。従って、最新の呼制御アプリケーション１７及び局データ１８を正しくフラッシュメモリ部１５に効率的かつ有効に保存するために、第１の実施形態の書き込み制御部２５は、フラッシュメモリ部１５への書き込み制限を掛けながら行う。
【００４５】
書き込み制御部２５は、例えば、Enhanced Write Filter（以下、ＥＷＦという）を利用する。このＥＷＦは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ｅｍｂｅｄｄｅｄのＯＳに特有の機能であり、ＯＳランタイムイメージへの書き込み制限を行う機能である。
【００４６】
これにより、ＲＡＭ部１３上のＲＡＭディスク部１４を保護パティーションに対する書き込み情報をリダイレクトする領域とし、ＲＡＭディスク部１４に格納された書き込み情報をフラッシュメモリ部１５の空き領域に格納することができる。つまり、リダイレクトする領域であるＲＡＭディスク部１４はＥＷＦの仕組におけるオーバーレイの領域で、オーバーレイの領域にはディスクＩ／Ｏがリダイレクトされ書き込みＩ／Ｏ後のディスクの状態（Ｉ／Ｏ結果）を表すＩ／Ｏキャッシュ（ディスクイメージ）が保存される。したがって、このリダイレクトとはフラッシュメモリ部１５に対するすべての書き込み情報をＲＡＭディスク部１４にキャッシュを格納し保存することである。
【００４７】
そのため、図６に示すように、フラッシュメモリ部（ＳＳＤ）１５からのデータ読み込みや、ＲＡＭディスク部（オーバレイ）１４へのデータ書き込み又は再読み込みが可能となる。再読み込みについては、ＲＡＭディスク部１４に書き込み情報がある場合にはＲＡＭディスク部１４から書き込み情報に基づいて読み込みを行い、書き込み情報がない場合にはフラッシュメモリ部１５から読み込みを行うことで再読込みを行う。
【００４８】
また、ＲＡＭディスク部１４は、揮発性メモリであるＲＡＭ部１３上に形成された領域なので、リブートするとＲＡＭディスク部１４の格納内容は破棄される。
【００４９】
さらに、第１の実施形態では、ＲＡＭディスク部１４に格納される書き込み情報から局データ１８の更新を検知し、更新した場合にフラッシュメモリ部１５に書き込むようにし、直接フラッシュメモリ部１５への書き込まれないようにしたので、フラッシュメモリ部１５への書き込み回数を削減することができる。
【００５０】
さらに、急な電源断（例えば、ＰＫＧ抜去、交換機１の電源ＯＦＦ等）に対してシステムを保護することができる。
【００５１】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態の交換機１において、ＲＡＭディスク部１４の内容をフラッシュメモリ部１５に書き込みを行う処理の動作を、図面を参照しながら説明する。
【００５２】
以下では、図１において、最初に電話端末２−１及び電話端末２−２のみが交換機１と接続しており、その後新たに電話端末２−ｎが追加され、この追加に伴い局データ１８を更新する場合を例示して説明する。
【００５３】
なお、以下では、局データ１８の更新の場合を例示するが、呼制御アプリケーション１７の更新の場合にも基本的な処理は同様の処理で実現できる。
【００５４】
ただし、図４のステップＳ４１では、局データ１８の場合と呼制御アプリケーション１７の場合とで具体的な処理が異なるので、この点について後で詳細に説明する。
【００５５】
図３は、第１の実施形態の交換機１における局データが更新されない場合の処理を示すフローチャートである。また、図４は、第１の実施形態の交換機１における局データの更新後の処理を示すフローチャートである。
【００５６】
まず、交換機１に電源が投入されて起動すると、交換機１は呼制御を開始できるよう準備する。
【００５７】
具体的には、交換機１において、ＯＳ１６が起動し（ステップＳ３１）、ＲＡＭ部１３の領域にＲＡＭディスク部１４が構築され（ステップＳ３２）、呼制御アプリケーション１７の起動（ステップＳ３３）及び局データ１８の呼び込み（ステップＳ３４）が行われ、かかる後に呼制御を開始（ステップＳ３５）する。ここで、ＯＳ１６はＲＡＭディスク部１４を構築する機能を有しており、これを使用することでＲＡＭ部１３の領域にＲＡＭディスク部１４を構築することができる。ＲＡＭディスク部１４の構築後は、ＯＳ状態情報、ＯＳ起動ログ、ネットワークからのアクセスログ、呼制御アプリケーションの起動ログ、呼制御により発生する課金情報等を記憶するためのフラッシュメモリ部１５に対する書き込みは、ＲＡＭディスク部１４に書き込み情報として格納される。
ステップＳ３６で、交換機１が電話端末２−１及び電話端末２−２間の呼制御を開始した後、局データ１８の更新がない場合であって、交換機１においてシャットダウンした場合（ステップＳ３７）、ＲＡＭディスク部１４の内容をフラッシュメモリ部１５に書き込み（ステップＳ３８）、この書き込み終了後に、交換機１が停止する。
【００５８】
ステップＳ３８において、フラッシュメモリ部１５への書き込みについては、ＯＳ１６のシャットダウン処理の一環として実行されるため、書き込みの際には、ＣＰＵ使用率は参照されない。このステップＳ３８は、ＲＡＭディスク部１４のすべての内容をフラッシュメモリ部１５に書き込むものである。
【００５９】
なお、ステップＳ３６において局データの更新がなく、さらに交換機１がシャットダウンしない場合（ステップＳ３７）には、通常の運用中であるとみなし、フラッシュメモリ部１５への書き込みアクセスを行わない。
【００６０】
ステップＳ３６において、交換機１で呼制御が行われている状態で、局データ１８が更新されたことを検出した際の動作について図４を参照しながら説明する。
【００６１】
例えば、交換機１が新たに電話端末２−ｎを収容することに伴い、局データ１８が更新されると（ステップＳ３６）、ステップＳ４１に遷移する。
【００６２】
ここで、更新された局データ１８はＲＡＭディスク部１４に書き込み情報として格納される。
【００６３】
なお、ここでの事例では１台の電話端末の追加を例示しているが、長時間に亘る大容量の局データ１８の更新作業を考慮して、局データ１８の更新を検知した後に、一定時間待ち状態とし、この待ち状態の間に局データ１８が更新されなかった場合に局データ１８の更新作業が終了したとみなして処理ステップＳ４１に遷移させるようにしてもよい。
【００６４】
この場合、待ち状態の間に局データ１８が更新された場合には、局データ１８の更新作業が継続する可能性があると判断し、局データ１８の更新作業が終了するまでステップＳ４１への処理に遷移させることを保留させる。
【００６５】
ステップＳ４１では、呼制御アプリケーション１７が、局データ１８を正常に呼び込めることを確認する。そして、呼制御アプリケーション１７が局データ１８の呼び込みに成功した場合は前記局データ１８をフラッシュメモリ部１５に書き込み可能と判断し、ステップＳ４２に遷移する。
【００６６】
ここで、呼び込む局データ１８は更新された局データ１８であるから、呼制御アプリケーション１７はＲＡＭディスク部１４の書き込み情報に基づいて再読み込みし、局データ１８を呼び込む。
【００６７】
なお、局データ１８の呼び出し方法としては、例えば、更新されたデータのみを呼び込む方法（例えば、新たな電話端末２−ｎに関する局データ１８のみを呼び出す方法等）、局データ１８全体を呼び込む方法等を適用することができる。
【００６８】
呼制御アプリケーション１７が正常に局データ１８を呼び込めない場合、ステップＳ３７に遷移して通常の運用状態に戻り、ＲＡＭディスク部１４の内容をフラッシュメモリ部１５に書き込まないようにする（ステップＳ４１）。
【００６９】
ここで、上述したように、局データ１８の呼び込みの正常性判断の具体的な方法と、呼制御アプリケーション１７の呼び込みの正常性判断の具体的な方法とは異なるので、この点について詳細に説明する。
【００７０】
（ア）局データ１８の呼び込みの正常性判断の方法
呼制御アプリケーション１７による局データ１８の呼び込みの正常性判断の方法としては、次の２つのいずれか又は双方を適用することができる。なお、次の２つのいずれか又は双方を適用するか否かは予め交換機１に設定しておくことで実現できる。
【００７１】
第１の方法は、呼制御アプリケーション１７が局データ１８を呼び込むためのルーチン（routine）のリターンコードで正常に呼び込めたか否かを判断する方法である。リターンコード０のとき正常に呼び込みができたことを示し、リターンコード１のとき正常に呼び込みができなかったことを示す。この場合、制御部１１は、呼制御アプリケーションからリターンコードを受け取るインタフェースを有することが必要であり、このインタフェースを介して受け取ったリターンコードから判断することで実現できる。
【００７２】
第２の方法は、呼制御アプリケーション１７が局データ１８を呼び込んだ結果、出力する自律メッセージにより正常に呼び込んだか否かを判断する方法である。呼制御アプリケーション１７は、局データ１８を呼び込んだ際、正常に呼び込めたか否かを自律メッセージに出力する。この自律メッセージはログファイルに出力される場合と、ＯＳの標準出力に出力される場合とを適用できる。この場合、制御部１１は、ログファイルにアクセスするインタフェース又は標準出力を受け取るインタフェースを有することが必要であり、制御部１１がログの内容から正常に呼び込めたか否かを判断する。具体的には、制御部１１はログの内容から、自律メッセージのタイプが通常メッセージであることを示す「＃・・」を検索できた場合、局データ１８のローディングが成功して出力されていることを判断し、局データ１８を正常に呼び込めたものと判断し、通常メッセージを示す「＃・・」を検索できなかった場合、局データ１８のローディングが成功して出力されていないと判断し、局データ１８の呼び込みが正常でないと判断することができる。
【００７３】
ここで、自律メッセージには、例えば、重要度により最緊急メッセージ、緊急メッセージ、エラーメッセージおよび通常メッセージの４つのタイプがある。
【００７４】
例えば、最緊急メッセージはメッセージの冒頭に「＊＊＊」が付与されるもので、呼制御アプリケーションのシステム動作確認により装置のハード及びソフトを含めて障害の状態と検出し、呼処理を再開できないシステムダウンの状態を示すものである。緊急メッセージはメッセージの冒頭に「＊＊・」が付与されるもので、呼制御アプリケーションのシステム動作確認は行っていないが装置が故障の状態であり、故障状態で強制的に呼処理を継続しシステムダウンに至る恐れがある状態を示すものである。エラーメッセージはメッセージの冒頭に「＊・・」が付与されるもので、呼処理エラーやプログラムエラーの状態を示すものである。通常メッセージはメッセージの冒頭に「＃・・」が付与されるもので、局データのローディングの成功、回線接続成功、ＰＫＧ挿抜、ＰＫＧ制御などの状態を示すものである。
【００７５】
なお、第１の実施形態では、第１の方法により、制御部１１が、呼制御アプリケーション１７による局データ１８の呼び込みが正常に行われたことを判断する場合を示す。
【００７６】
また、呼制御アプリケーション１７が局データ１８の呼び込みに失敗した場合、その局データ１８を以前の局データ１８に復旧するようにしても良い。
【００７７】
この局データ１８の復旧方法としては、例えば、フラッシュメモリ部１５から局データ１８を再度ＲＡＭ部１３に呼び込んで復旧する方法を適用したりＲＡＭ部１３で以前の局データ１８を保持しておき、新しい局データ１８の呼び出しに失敗した場合に、その更新前の局データ１８に切り戻す方法等を適用することができる。
【００７８】
（イ）呼制御アプリケーションデータ１７の呼び込みの正常性判断の方法
呼制御アプリケーション１７を呼び込んだ結果、出力する自律メッセージにより正常に呼び込めたか否かを判断する方法である。呼制御アプリケーション１７は、自身が呼び込まれた際、呼び込みにより自身が障害や異常を検出すると自律メッセージに出力する。この自律メッセージはログファイルに出力される場合と、ＯＳの標準出力に出力される場合とを適用できる。この場合、制御部１１は、ログファイルにアクセスするインタフェース又は標準出力を受け取るインタフェースを有することが必要であり、制御部１１がログの内容から正常に呼び込めたか否かを判断する。具体的には、交換機１で呼制御アプリケーション１７を呼び込み障害や異常を検出せず呼処理をし、更新により新たな呼制御アプリケーション１７を呼び込み障害や異常を検出し自律メッセージに出力すれば、新たな呼制御アプリケーション１７は正常でないと判断できる。
【００７９】
したがって、制御部１１はログの内容から、「＊＊＊」を検索し自律メッセージの最緊急メッセージが出力されていないことを判断することで障害や異常あるか否かを判断することができる。
【００８０】
ステップＳ４２では、交換機１のＣＰＵ使用率がある閾値以下になった時点で、ＲＡＭディスク部１４に保存される書き込み情報の内容をフラッシュメモリ部１５に書き込めるようにし（ステップＳ４３）、ステップＳ３７に遷移する。
【００８１】
ステップＳ４２を実行する時点でのＣＰＵ使用率が閾値より大きい場合、再度ステップＳ４２に遷移し、ＣＰＵ使用率が閾値を下回るまで待つ。
【００８２】
ここで、ＣＰＵ使用率の閾値の決定方法としては、交換機１の環境に応じて適宜決定することができるが、例えばWindows（登録商標）をＯＳに使用する場合においては、ＣＰＵ使用率を８０％以内の状態でコンピュータを動作させることを推奨することがあり、この推奨値からの猶予を見て、閾値を７０％とする。他のＯＳによるＲＡＭディスク部１４からフラッシュメモリ部１５への書き込み処理においても、同様にして閾値を決定することが可能であり、７０％以外の値を設定可能であることは当然である。
【００８３】
ステップＳ４３で、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込めるようにしてステップＳ３７に遷移し、交換機１が通常の動作をすれば、ＲＡＭディスク部１４の内容が、フラッシュメモリ部１５に書き込まれる。このステップＳ４３は、ＲＡＭディスク部１４に格納される書き込み情報のうち更新された局データ１８の書き込み情報の内容をフラッシュメモリ部１５に書き込むものである。
【００８４】
なお、ステップＳ３６の局データ１８の更新の検知で、フラッシュメモリ部１５に格納された局データ１８のファイル名に対する書き込み情報を検知するので、ステップＳ４３の書き込みの際、ＲＡＭディスク部１４に格納される書き込み情報のうち更新された局データ１８に関わる書き込み情報とそれ以外の書き込み情報を区別できるものである。
【００８５】
（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、フラッシュメモリ部１５に更新後の局データ１８以外を書き込まない制限をしつつ、局データ１８の更新要求のみで、ＲＡＭディスク部１４に対してのみならず、フラッシュメモリ部１５に対して更新後の局データ１８を保存することができる。
【００８６】
これにより、局データ１８の更新手順の簡素化、局データ１８のフラッシュメモリ部１５への更新漏れの防止、交換機１の故障によるＲＡＭディスク部１４の局データ１８の消失に対する救済策の提供が可能となる。
【００８７】
（Ｂ）第２の実施形態
次に、本発明の呼制御装置、方法及びプログラムの第２の実施形態について図面を参照しながら説明する。
【００８８】
第１の実施形態では、局データ（又は呼制御アプリケーション）の更新があった場合に、局データの呼び込みが正常に行えたか否かを判断した後に、ＲＡＭディスク部に格納される書き込み情報の内容をフラッシュメモリ部に書き込む実施形態を例示した。
【００８９】
しかしながら、更新後の局データのシンタックスが正常であるために、呼制御アプリケーションが呼び込みに成功できたとしても、実際の交換システムで正しく動作する保証は必ずしもない。
【００９０】
このような場合に、フラッシュメモリ部１５への書き込みを許容すると、正しく動作し得ない局データをフラッシュメモリ部１５に保存することになる。また、この余分な書き込み作業により書き込み回数を消費することにもなる。
【００９１】
そこで、第２の実施形態は、局データの更新があった場合に、呼制御に成功したか否かを判断した後に、ＲＡＭディスク部に格納される書き込み情報の内容をフラッシュメモリ部に書き込む実施形態を例示する。
【００９２】
（Ｂ−１）第２の実施形態の構成
第２の実施形態が第１の実施形態の構成と異なる点は、フラッシュメモリ部１５への書き込み処理を実現する機能部である。そこで、第２の実施形態では、この書き込み処理の機能部の構成について詳細に説明し、第１の実施形態で既に説明した構成の説明については省略する。
【００９３】
図７は、第２の実施形態のフラッシュメモリ部１５への書き込みを行う書き込み処理の機能部の構成を示す構成図である。図７において、第２の実施形態の書き込み処理機能部は、局データ更新検知部２１、局データ呼び込み制御部２２、局データ復旧部２３、ＣＰＵ使用率確認部２４、呼制御確認部２６、呼制御エラー発生状況確認部２７、異常通知部２８、書き込み制御部２５を有する。
【００９４】
なお、局データ更新検知部２１、局データ呼び込み制御部２２、局データ復旧部２３、ＣＰＵ使用率確認部２４、書き込み制御部２５は、第１の実施形態で説明した機能と同じであるので、ここでの説明を省略する。
【００９５】
呼制御確認部２６は、局データ１８又は呼制御アプリケーション１７が更新された後、当該交換機１がその更新された局データ１８を用いて呼制御を行い、その呼制御が成功するか否かを確認するものである。
【００９６】
呼制御エラー発生状況確認部２７は、呼制御確認部２６により呼制御が失敗したと判断した場合に、局データ１８又は呼制御アプリケーション１７の更新から現時点までの呼制御エラーの発生状況を確認するものである。
【００９７】
異常通知部２８は、呼制御のエラーが頻繁に発生するような場合に、交換機１の作業者に対し、更新後の局データ１８又は呼制御アプリケーション１７に異常があったこと、かかる異常に付随するエラーログ、更新後の局データ１８又は呼制御アプリケーション１７のフラッシュメモリ部１５への書き込みが行われないこと、局データ１８又は呼制御アプリケーション１７への更新を破棄する旨のいずれか又はこれらを組み合わせた情報を通知するものである。エラーログの情報は、呼制御アプリケーション１７を呼び込んだ結果、出力する自律メッセージから受け取ることで取得できるものである。
【００９８】
（Ｂ−２）第２の実施形態の動作
次に、第２の実施形態の交換機１において、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込みを行う書き込み処理の動作を図面を参照しながら説明する。
【００９９】
第２の実施形態は、局データ１８の更新後の処理が第１の実施形態と異なる。従って、局データ１８が更新されない場合の処理（図３に示す処理）は、第１の実施形態と同じであるので、ここでの再度の説明は省略する。
【０１００】
なお、局データ１８の更新の場合を例示するが、呼制御アプリケーション１７の更新の場合を同様にして適用できる。
【０１０１】
図８は、第２の実施形態の局データの更新後の処理を示すフローチャートである。
【０１０２】
まず、交換機１において呼制御の開始後、局データ１８が更新するとステップＳ５１に遷移する。
【０１０３】
ステップＳ５１では、呼制御アプリケーション１７が更新後の局データ１８を呼び込むことにより、更新後の局データ１８の正常性を確認すると（ステップＳ５１）、呼制御アプリケーション１７は、更新後の局データ１８を使用して呼制御の実行を待つ（ステップＳ５２）。
【０１０４】
ステップＳ５２において、例えば交換機１が電話端末２−ｎからの通話要求を受信する場合に、その呼制御が成功したとき、制御部１１は、ＣＰＵ使用率が閾値以下であるか否かを確認して閾値以下であれば（ステップＳ５５）、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込む（ステップＳ５６）。
【０１０５】
ここで、実際の交換システム１０の運用における呼制御確認のタイミングとしては、例えば、保守作業の確認時としても良いし、局データ１８の更新後に最初のオペレータが発呼するタイミングとしても良い。すなわち、必ずしもリアルタイムに呼制御の確認を行う必要はない。
【０１０６】
一方、ステップＳ５２では、例えば、着信先の無応答や着信先の話中といった発呼のタイミングにより解決可能な呼制御エラーや、また例えば、更新後の局データ１８の内容と電話端末情報の相違の存在や、呼制御アプリケーション１７やＯＳ１６の不具合といった、交換機１に起因する呼制御エラーが発生し得る。このような呼制御に関するエラーが生じた場合、呼制御に失敗したとして、ステップＳ５３に遷移する。
【０１０７】
ステップＳ５３では、局データ１８の更新後から現時点までの、呼制御エラーの発生状況を確認する（ステップＳ５３）。
【０１０８】
ここで、呼制御エラーの発生状況の確認としては、例えば、過去のエラー発生回数が少ない（閾値以下である場合）又はエラー発生頻度が低い（閾値以下である場合）には、直近の呼制御エラーは一時的な事象であるとみなし、ステップＳ５２に遷移し、処理を繰り返す。
【０１０９】
一方、過去の呼制御エラー発生回数が多い（閾値を超えている場合）又はエラー発生頻度が高い（閾値を超えている場合）、直近の局データ１８の更新により呼制御を正常に行えなくなったとみなし、ステップＳ５４に遷移する。
【０１１０】
ここで、ステップＳ５３におけるエラー発生状況の確認方法としては、種々の方法を適用できるが、例えば、所定時間の間に、所定回数以上の呼制御エラーが発生しているかどうかを確認する方法や、同種類の呼制御エラーが所定回数以上発生しているか否かを確認する方法や、ステップＳ５２における全ての呼制御エラーが所定回数以上発生しているかどうかを確認する方法を適用することができる。
【０１１１】
なお、ステップＳ５３からステップＳ５４に遷移する場合には、制御部１１は、交換機１の作業者に対し、更新後の局データ１８に異常があったこと、かかる異常に付随するエラーログ、更新後の局データ１８のフラッシュメモリ部１５への書き込みが行われないこと、及び又は、局データ１８への更新を破棄する旨を通知するようにしてもよい。
【０１１２】
ステップＳ５４では、直近の局データ１８の更新を破棄し、更新直前の局データ１８にロールバックして、図３のステップＳ３７に遷移する（ステップＳ５４）。
【０１１３】
このように、呼制御が正常に行われた後に、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込むようにしたので、呼制御を正常に行えない局データ１８をフラッシュメモリ部１５に書き込むことを防ぐことができる。
【０１１４】
また、局データ１８の更新により呼制御が正常に行われなくなった場合であっても、過去の正常に動作することを保証された局データ１８への回復及び回復後の局データ１８を用いた交換機１の稼動、及び交換機１が稼動状態に復帰可能であることにより、局データ１８の更新の失敗後であっても、局データ１８に対する新たなデータ更新を受理することが可能となる。
【０１１５】
（Ｂ−３）第２の実施形態の効果
以上のように、第２の実施形態では、第１の実施形態により得られる効果に加えて、実際に呼制御が可能な局データ１８のみをＲＡＭディスク部１４の書き込み情報の内容からフラッシュメモリ部１５に書き込むことが可能になった。
【０１１６】
これにより、交換機１として正常に動作する局データ１８のみを選別してフラッシュメモリ部１５に書き込むことが可能になる。
【０１１７】
さらに、第２の実施形態によれば、呼制御に供することができない局データのフラッシュメモリ部１５への書き込み処理による、フラッシュメモリ部１５の書き込み回数の延命が可能になる。
【０１１８】
（Ｃ）第３の実施形態
次に、本発明の呼制御装置、方法及びプログラムの第３の実施形態について図面を参照しながら説明する。
【０１１９】
第３の実施形態は、局データの更新があるときに、直ちにフラッシュメモリ部１５に書き込みをした後にシステムを再起動又はシャットダウンする実施形態を例示して説明する。
【０１２０】
（Ｃ−１）第３の実施形態の構成
第３の実施形態が第１の実施形態の構成と異なる点は、フラッシュメモリ部１５への書き込みを行う書き込み処理の機能部の構成であるので、以下では、第３の実施形態の書き込み処理機能部の構成を詳細に説明し、第１の実施形態で既に説明した構成の説明については省略する。
【０１２１】
図９は、第３の実施形態の書き込み処理の機能部の構成を示す構成図である。図９において、第３の実施形態の書き込み機能部は、局データ更新検知部２１、局データ呼び込み制御部２２、局データ復旧部２３、ＣＰＵ使用率確認部２４、書き込み制御部２５、再起動部２９を有する。
【０１２２】
なお、局データ更新検知部２１、局データ呼び込み制御部２２、局データ復旧部２３、ＣＰＵ使用率確認部２４、書き込み制御部２５は、第１の実施形態で説明した機能と同じであるので、ここでの説明を省略する。
【０１２３】
再起動部２９は、局データ１８の更新があるときに、直ちにフラッシュメモリ部１５に書き込みをした後にシステムを再起動又はシャットダウンするものである。
【０１２４】
（Ｃ−２）第３の実施形態の動作
次に、第３の実施形態の交換機１において、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込みを行う書き込み処理の動作を、図面を参照しながら説明する。
【０１２５】
図１０は、第３の実施形態の交換機１における処理を示すフローチャートである。図１０において、図３に示す処理と同一の処理については、同一の番号を付与する。
【０１２６】
交換機１においてＯＳが起動し、呼制御が開始した後（ステップＳ３１〜Ｓ３５）、呼制御アプリケーション１７は、局データ１８の更新を監視し、局データ１８の更新がない限り、通常の交換機１を運用する（ステップＳ６１）。
【０１２７】
ステップＳ６１において、局データ１８の更新処理が検知されると、ステップＳ６２に遷移する。ステップＳ６２では、ＲＡＭディスク部１４に格納される書き込み情報の内容が、フラッシュメモリ部１５に書き込まれる（ステップＳ６２）。
【０１２８】
なお、局データ１８の更新検知方法や、局データ１８のフラッシュメモリ部１５への書き込み方法は、第１の実施形態と同様の処理を適用できる。
【０１２９】
また、ステップＳ６１からステップＳ６２に遷移する前に、第１又は第２の実施形態で説明した処理を適用することができる。
【０１３０】
つまり、制御部１１において監視しているＣＰＵ使用率が閾値を下回るまで待機させることも可能であること（図４におけるステップＳ４２の挿入）、呼制御アプリケーション１７が更新後の局データ１８を呼び込み、かかる呼び込みが成功した場合にのみステップＳ６２に遷移し、ＲＡＭディスク部１４に格納された局データ１８をフラッシュメモリ部１５に書き込むことも可能であること（図４におけるステップＳ４１の挿入）、および実際の呼制御が成功した場合にのみステップＳ６２に遷移し、ＲＡＭディスク部１４に格納された局データ１８をフラッシュメモリ部１５に書き込むことも可能であること（図８におけるステップＳ５２の挿入）は当然である。
【０１３１】
次に、ステップＳ６３では、ＲＡＭディスク部１４に格納された局データ１８のフラッスメモリ部１５への書き込み処理の終了後に、ＯＳ１６は交換機１をシャットダウン又はリブートする。
【０１３２】
このように、ＯＳ１６がシャットダウン又はリブートすることにより、ＲＡＭディスク部１４を開放し、起動時に再度構築することで、ＲＡＭディスク部１４のクリーンアップを行い、新たな局データ１８をローディングした呼制御アプリケーション１７で呼制御を行うことができる。
【０１３３】
また、交換機１がリブートされた場合、ステップＳ３１に遷移し、再度呼制御を提供できる状態となる。
【０１３４】
（Ｃ−３）第３の実施形態の効果
以上のように、第３の実施形態によれば、第１の実施形態の効果に加えて、更新された局データをフラッシュメモリ部１５に書き込みした後に、ＯＳが再起動することにより、再度ＲＡＭディスク部１４をクリーンアップして再構築することができ、新たな局データ１８で呼制御を行うことができる。
【０１３５】
（Ｄ）第４の実施形態
次の本発明の呼制御装置、方法及びプログラムの第４の実施形態を、図面を参照しながら説明する。
【０１３６】
第４の実施形態は、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込む際、フラッシュメモリ部１５の空き領域を判断した後に書き込みを行う実施形態を例示する。
【０１３７】
図１１（Ａ）は、フラッシュメモリ部１５の保存領域を説明する説明図である。図１１に示すように、フラッシュメモリ部１５の保存領域の構成を見ると、ＯＳ１６等の保存領域、呼制御アプリケーション１７の保存領域、局データ１８の保存領域があり、この他に空きの保存領域が存在する。
【０１３８】
このとき、局データ１８又は呼制御アプリケーション１７をフラッシュメモリ部１５に書き込む際、この書き込みを許容するためには、空きの保存領域の容量を考慮する必要がある。
【０１３９】
つまり、図１１（Ｂ）に示すように、新たにフラッシュメモリ部１５に書き込みを行う局データ１８の保存領域の容量は、現在の局データ１８の保存領域の容量に、現在の局データ１８の空きの保存領域の容量を加えた範囲内であることが望ましい。この点については、呼制御プログラムの場合も同様である。
【０１４０】
そこで、第４の実施形態では、フラッシュメモリ部１５に更新後の局データ１８又は呼制御アプリケーション１７を書き込む際に、空きの保存領域も判断する。
【０１４１】
書き込み制御部２５は、第１〜第３の実施形態と同様の処理を行うと共に、フラッッ種メモリ部１５への書き込みの際に、更新後の局データ１８の保存領域の容量と、現在の局データ１８の保存領域及び空き領域の容量とを比較して、その比較結果に応じて更新後の局データ１８の書き込みをするか否かの判断を行う。
【０１４２】
そして、書き込み制御部２５は、書き込みＯＫと判断した場合、更新後の局データ１８をフラッシュメモリ部１８に書き込み、そうでない場合、更新後の局データ１８の書き込みを行わない。なお、書き込み制御部２５は、呼制御アプリケーション１７の場合も同様に行う。
【０１４３】
また、第３の実施形態ではフラッシュメモリ部１５への書き込み終了後に、リブートなどを行う場合を説明したが、その場合でも、更新後の局データ１８（又は呼制御アプリケーション１７）をフラッシュメモリ部１５に書き込んだ後にリブート等を行うため、更新後の局データ１８等を担保することができる。つまり更新した最新の局データ（もしくは呼制御プログラム）をフラッシュメモリに記憶しつつ運用を継続ができる。
【０１４４】
この書き込み制御部２５による判断方法としては、例えば、図１２に示す判断テーブルを用いて行う。
【０１４５】
図１２において、新たな呼制御アプリケーション１７の保存領域の容量が、現在の呼制御プログラムの保存領域に空き領域を加えた保存領域の容量を超越する場合、書き込み制御部２５は、新たな呼制御アプリケーション１７のフラッシュメモリ部１５への書き込みを行わない。
【０１４６】
一方、新たな呼制御アプリケーション１７の保存領域の容量が、現在の呼制御プログラムの保存領域に空き領域を加えた保存領域の容量以下である場合、書き込み制御部２５は、新たな呼制御アプリケーション１７のフラッシュメモリ部１５への書き込みを行う。
【０１４７】
局データ１８の場合も同様に、新たな局データ１８の保存領域の容量が、現在の局データ１８の保存領域に空き領域を加えた保存領域の容量を超越する場合、書き込み制御部２５は、新たな局データ１８のフラッシュメモリ部１５への書き込みを行わない。
【０１４８】
一方、新たな局データ１８の保存領域の容量が、現在の局データ１８の保存領域に空き領域を加えた保存領域の容量以下である場合、書き込み制御部２５は、新たな局データ１８のフラッシュメモリ部１５への書き込みを行う。
【０１４９】
新たな局データ１８及び呼制御アプリケーション１７を、フラッシュメモリ部１５に書き込みを行わない場合、ＲＡＭディスク部１４上にキャッシュとして残る。しかし、再起動すると、その新たな局データ１８及び呼制御アプリケーション１７はフラッシュメモリ部１５に保存されていないので、更新後の局データ１８及び呼制御アプリケーション１７を担保することはできない。つまり更新した最新の局データ（もしくは呼制御プログラム）で単に運用を継続する。
【０１５０】
こうすることで、フラッシュメモリ部１５の空き容量があるときに適宜にＲＡＭディスク部１４上の内容がフラッシュメモリ部１５上に反映され、書き込み・削除回数の限定されているフラッシュメモリ部１５の寿命を延命することができる。
【０１５１】
例えば、ＷｉｎｄｏｗｓなどのＯＳで、１００ＭＢの空き容量があるＨＤＤに、３００ＭＢのファイルを書き込もうとするとき、３００ＭＢのうち１００ＭＢ書き込みを行い１０１ＭＢの書き込みを行うときにＨＤＤの空き容量が無いという警告のポップアップウインドウが表示される。
【０１５２】
このとき、ＨＤＤでは１００ＭＢの空き容量に１００ＭＢを書き込み、（ＨＤＤの空き容量が無いという警告のポップアップウインドウを作業者に表示し）その後、書き込んだ１００ＭＢを削除する処理をする。ＨＤＤがＳＳＤである場合も同じであるから、書き込み・削除回数が限定されているＳＳＤの寿命が目減りしてしまう。
【０１５３】
しかし、第４の実施形態によれば、更新後の局データ１８等の容量が、保存領域の容量を超えている場合には、その局データ１８等の書き込み自体を行わないので、書き込み回数を減らすことができ、フラッシュメモリ部１５の寿命を延命できる。
【０１５４】
（Ｅ）第５の実施形態
次に、本発明の呼制御装置、方法及びプログラムの第５の実施形態を、図面を参照しながら説明する。
【０１５５】
第４の実施形態では、フラッシュメモリ部１５への書き込みを行う際に、フラッシュメモリ部１５の空き領域の容量を判断することとした。
【０１５６】
第５の実施形態では、第４の実施形態において、局データ１８と呼制御アプリケーション１７の双方が更新されたときに、フラッシュメモリ部１５の空き領域に対し、局データ１８と呼制御アプリケーション１７の双方が書き込めるか否かの判断をし、書き込みをする実施形態を説明する。
【０１５７】
書き込み制御部２５は、第１〜第４の実施形態で説明した処理の他に、更新後の局データ１８と更新後の呼制御アプリケーション１７の双方を、フラッシュメモリ部１５に書き込む際に、更新後の局データ１８及び呼制御プログラムの双方の容量と、それぞれの空き領域の容量とを比較して、これら更新後の局データ１８及び呼制御プログラムの書き込みを行うかどうかを判断するものである。
【０１５８】
この書き込み制御部２５の判断方法としては、例えば、図１３に示す判断テーブルを用いて判断する。
【０１５９】
例えば、図３及び図４において、作業者により局データ１８の更新が行われると、図３のステップＳ３６から、図４のステップＳ４１及びＳ４２を経て、ステップＳ４３に至る。このとき、ステップＳ４３では、更新後の局データ１８の容量が、フラッシュメモリ部１５の空き領域の容量を超えるか又は容量以下であるかを判断し、所定時間の待ち状態となる。
【０１６０】
また、この待ち状態のあいだに、作業者により呼制御アプリケーション１７の更新が行われると、図３のステップＳ３６から、図４のステップＳ４１及びＳ４２を経て、ステップＳ４３に至る。このときも、ステップＳ４３では、呼制御アプリケーション１７の容量が、フラッシュメモリ部１５の空き領域の容量を用いた判断を行う。
【０１６１】
上記のような状況の場合、書き込み制御部２５は、図１３に示す判断テーブルを用いて判断を行う。
【０１６２】
例えば、図１３に示すように、「新たな局データ１８の容量が空き領域の容量以下」で「新たな呼制御アプリケーション１７の容量が空き領域の容量以下」の場合は、新たな局データ１８及び呼制御アプリケーション１７を、フラッシュメモリ部１５に書き込みを行う。つまり、更新した最新の局データ１８及び呼制御アプリケーション１７を、フラッシュメモリ部１５に記憶しつつ運用を継続する。
【０１６３】
一方、「新たな局データ１８の容量が空き領域の容量を超え」で「新たな呼制御アプリケーション１７の容量が空き領域の容量を超える」の場合は、新たな局データ１８及び呼制御アプリケーション１７のフラッシュメモリ部１５への書き込みは行わない。
【０１６４】
ところで、図１３に示すように、例えば、「新たな呼制御アプリケーション１７の容量が空き領域の容量を超え」の条件で、「新たな局データ１７の容量が空き領域の容量以下」となる場合、新たな局データ１７は、空き容量以下であるから書き込みが可能だが、ここではＮＧの判断をし、書き込みを行わない。逆に、
これは、交換機特有の理由があるからである。旧来のＤ６０形自動交換機などのディジタル交換機は、交換用プログラムと局データが備えられ、これらにより電話の接続処理をしている。この交換用プログラムはプログラムごとに局データの構成が異なっている。なぜなら交換用プログラムのシステムデータで信号形式やサービス条件が決定し、信号形式やサービス条件が決定したこの交換用プログラムを含む局の局条件としてハード構成や課金条件や番号計画などを決定するものが局データだからである。
【０１６５】
交換用プログラムごとに局データの構成が異なるから、単に新たな局データを生成し、これを更新したとしても、交換用プログラムの信号形式やサービス条件に見合った構成の局データでなければ、この局データは交換用プログラムで利用できない。
【０１６６】
また、単に新たな交換用プログラムを生成し、これを更新したとしても、新たな交換用プログラムの信号形式やサービス条件に見合った構成の局データがなければ、この交換用プログラムは利用できない。つまり、交換用プログラムと局データは双方が利用できるものを対にしておく必要がある。
【０１６７】
したがって、第５の実施形態でも同様に、例えば図１３の左の列の最上段から一つ下の段で「新たな呼制御プログラムが空き容量以上」の条件で、右から２列目の最上段から二つ下の段で「新たな局データが空き領域以下」となっている場合、新たな局データ１８は空き容量以下であるから書き込みが可能だが、新たな呼制御アプリケーション１７が空き容量以上なので、結局のところ新たな局データ１８しか書き込めず、交換機１として動作できなくなる可能性が生じ得る。
【０１６８】
そのため、ここでは、局データ１８及び呼制御アプリケーション１７の書き込みを行わない。
【０１６９】
なお、ステップＳ４３での待ち時間のあいだに、作業者による更新がないと第４の実施形態と同様の動作になる。
【０１７０】
また、図１３で、ＮＧの判断のときは書き込みを行わず、ＲＡＭディスク上にキャッシュとして残るのみである。書き込みを行いませんので装置が再起動すると更新した局データおよび呼制御プログラムは担保されない。つまり更新した最新の局データおよび呼制御プログラムで単に運用を継続する。
【０１７１】
（Ｆ）他の実施形態
（Ｆ−１）第１〜第５の実施形態では、局データ１８の更新を契機に、ＲＡＭディスク部１４上の更新後の局データ１８の内容をフラッシュメモリ部１５に書き込む動作を説明したが、更新後の呼制御アプリケーション１７の更新動作についても、同様の処理によりフラッシュメモリ部１５に書き込むことができる。
【０１７２】
（Ｆ−２）本発明は、アナログ電話に限定せず、ＩＰ電話等にも適用可能である。
【０１７３】
また、本発明は、交換機１のコンソールを経由した局データ１８の更新、電話端末を経由した局データ１８の更新、自動実行による局データ１８の更新においても適用可能である。また、交換機１のコンソールについては、ローカルアクセス、リモートアクセスの別を問わない。
【０１７４】
（Ｆ−３）第１〜第５の実施形態で、局データ１８をフラッシュメモリ部１５（ＳＳＤ）に更新すると同時に、交換機１において重要な情報となる、呼処理するごとにＲＡＭディスク領域の課金情報のファイル（データ）の書き込み情報の内容もフラッシュメモリ部１５（ＳＳＤ）に反映するようにしてもよい。
【０１７５】
（Ｆ−４）第５の実施形態においては、呼制御アプリケーション１７と局データ１８の双方を判断しましたが、主装置が加入者データを記憶する場合は、呼制御アプリケーションと局データと加入者データの３つの書き込みが行えるか否かの判断をしてもよい。
【０１７６】
ここで、加入者データは加入者に対するサービス条件をいう。これは、呼制御アプリケーションが決定すると局データの構成が決定し、局データの構成が決定すると加入者データの構成が決定する関係にある。
【符号の説明】
【０１７７】
１…交換機、１１…制御部、１２…通信部、１３…ＲＡＭ部、１４…ＲＡＭディスク部、
１５…フラッシュメモリ部、１６…ＯＳ、１７…呼制御アプリケーション、
１８…局データ、２−１〜２−ｎ…電話端末、１０…通話システム。
【技術分野】
【０００１】
本発明は、呼制御装置、方法及びプログラムに関し、例えば、交換機のメインメモリで更新された呼制御情報（例えば、局データ、加入者データ等）及び呼制御アプリケーションを適宜に不揮発性メモリに記憶する呼制御装置、方法及びプログラムに適用し得るものである。
【背景技術】
【０００２】
旧来の電子交換機では、交換システムで動作させる呼制御アプリケーション及び局データを、揮発性メモリに格納した状態で運用する構成をとるのが一般的である。
【０００３】
電子交換機に電源を投入すると、呼制御アプリケーション及び局データが、不揮発性メモリから揮発性メモリに呼び込まれる。そのため、電子交換機の呼制御アプリケーション及び局データの更新を行う際に、運用中のデータ更新のための揮発性メモリへの更新作業と、次回の電子交換機の起動の際に読み出されることとなる不揮発性メモリへの更新作業の２つの更新作業が必要になる。
【０００４】
また、現代の電子交換機として、揮発性メモリとしてのＤＩＭＭ（Dual Inline Memory Module）や不揮発性メモリとしてのＳＳＤ（Solid State Drive）の採用、ＲＡＭディスクによる揮発性メモリ及び不揮発性メモリの管理方法の適用がある。
【０００５】
現代の電子交換機においても、呼制御アプリケーション及び局データの更新の際には、揮発性メモリと不揮発性メモリとの双方の更新が必要である。
【０００６】
例えば、特許文献１に記載の技術は、操作者が保守コンソールから交換機のメモリ書き込みプログラム及びメモリ読み出しプログラムを制御し、メモリから情報を出し入れするという技術が記載されている。
【０００７】
さらに、現代の電子交換機の構成としては、例えば汎用的なＰＣ／ＡＴ互換のＭＢ（Main Bord）で外部記憶装置としてＳＳＤを有し、メインメモリとしてＤＩＭＭを有するものが挙げられる。
【０００８】
この場合、ＤＩＭＭ上にＲＡＭディスクを形成し、ＤＩＭＭを記憶装置のように扱える仮想ディスク（Virtual Disk）の技術が利用されることがある。ところが、ＲＡＭディスク領域は揮発性メモリ（ＤＩＭＭ）内に生成した仮装ディスク領域なので、例えば停電などにより交換機への給電が絶たれシステムダウンすると、ＲＡＭディスク上のデータは、交換機のリセットに伴い消去されるため、適宜、ＲＡＭディスクの内容をＳＳＤに反映する必要がある。
【０００９】
このＲＡＭディスクに適用される仮想ディスクの技術としてＥＷＦ（Enhanced Write Filter）等が存在し、例えば特許文献２には、ＲＡＭディスクの内容をＤＭＡ転送で磁気ディスクに書き込む方法が示されている。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開平５−３００２２９号公報
【特許文献２】特開平２−３９３４２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ところで、汎用的なＭＢに、不揮発性メモリのＳＳＤの記憶装置、揮発性メモリのＤＩＭＭのメモリを有し、ＤＩＭＭ上にＲＡＭディスクを形成して動作する交換機において、電源が投入されＯＳが起動すると、例えばＯＳ状態情報、ＯＳ起動ログ、ネットワークからのアクセスログ、呼制御アプリケーションの起動ログ、呼制御により発生する課金情報等を記憶するためにディスクＩ／Ｏが発生する。このディスクＩ／Ｏは、ＥＷＦの仕組みでＲＡＭディスク領域に書き込み情報として保存される。
【００１２】
また、例えばバグの修正や機能追加等のために作業者がＳＳＤ内に記憶されている呼制御アプリケーションをバージョンアップする場合や、例えば交換機の収容端末の増減に伴って局データを更新する場合にもディスクＩ／Ｏが行われ、ディスクＩ／ＯがＥＷＦの仕組みでＲＡＭディスク領域に書き込み情報として保存される。
【００１３】
しかしながら、呼制御アプリケーション及び局データは、交換機として最低限必要な要素であり、直ちにＳＳＤに記憶する必要がある。
【００１４】
また、記憶装置として適用される不揮発性メモリのＳＳＤは、その書き込み・削除回数に限界があるため（例えば１０万回）、なるべくＳＳＤへの書き込み・削除回数を減らし、ＳＳＤの寿命を延命させることが望まれる。
【００１５】
そのため、呼制御アプリケーションと呼制御情報（例えば局データなど）が更新されたときに、ＲＡＭディスク領域に保存される不揮発性メモリに対する書き込み情報の内容が不揮発性メモリ上に反映させることができ、かつ、書き込み・削除回数が限定されている不揮発性メモリの寿命を延命させることができる呼制御装置、方法及びプログラムが求められている。
【課題を解決するための手段】
【００１６】
第１の本発明の呼制御装置は、揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を揮発性メモリにローディングして呼処理を行い、不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置において、（１）ＲＡＭディスク領域の書き込み情報から、呼処理により揮発性メモリにローディングされた呼制御アプリケーション及び又は呼制御情報を格納する不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理手段と、（２）更新検知処理手段の検知に基づいてＲＡＭディスク領域の書き込み情報のうち呼制御アプリケーション及び又は呼制御情報の領域に対する書き込み情報の不揮発性メモリへの書き込みを行う書き込み処理手段を備えることを特徴とする。
【００１７】
第２の本発明の呼制御方法は、揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を揮発性メモリにローディングして呼処理を行い、不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置の呼制御方法において、（１）更新検知処理手段が、ＲＡＭディスク領域の書き込み情報から呼処理により揮発性メモリにローディングされた呼制御アプリケーション及び又は呼制御情報を格納する不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理工程と、（２）書き込み処理手段が、更新検知処理手段の検知に基づいてＲＡＭディスク領域の書き込み情報のうち呼制御アプリケーション及び又は呼制御情報の領域に対する書き込み情報の不揮発性メモリへの書き込みを行う書き込み処理工程を有することを特徴とする。
【００１８】
第３の本発明の呼制御プログラムは、揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を揮発性メモリにローディングして呼処理を行い、不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置を、（１）ＲＡＭディスク領域の書き込み情報から、呼処理により揮発性メモリにローディングされた呼制御アプリケーション及び又は呼制御情報を格納する不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理手段と、（２）更新検知処理手段の検知に基づいてＲＡＭディスク領域の書き込み情報のうち呼制御アプリケーション及び又は呼制御情報の領域に対する書き込み情報の不揮発性メモリへの書き込みを行う書き込み処理手段として機能させることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、呼制御アプリケーションと呼制御情報（例えば局データなど）が更新されたときに、ＲＡＭディスク領域に格納される書き込み情報の内容が不揮発性メモリ上に反映させることができ、かつ、書き込み・削除回数が限定されている不揮発性メモリの寿命を延命させることができる。
【図面の簡単な説明】
【００２０】
【図１】第１〜第５の実施形態の交換機の内部構成を示す構成図である。
【図２】第１〜第５の実施形態の通話システムの構成を示す構成図である。
【図３】第１の実施形態の交換機において、フラッシュメモリ部への書き込み処理を示すフローチャートである。
【図４】第１の実施形態の交換機においてフラッシュメモリ部への書き込み処理示すフローチャートである。
【図５】第１の実施形態の書き込み処理の機能部の構成を示すブロック図である。
【図６】フラッシュメモリ部への書き込み処理を説明する説明図である。
【図７】第２の実施形態の書き込み処理の機能部の構成を示すブロック図である。
【図８】第２の実施形態の交換機においてフラッシュメモリ部への書き込み処理示すフローチャートである。
【図９】第３の実施形態の書き込み処理の機能部の構成を示すブロック図である。
【図１０】第３の実施形態の交換機においてフラッシュメモリ部への書き込み処理示すフローチャートである。
【図１１】フラッシュメモリ部の保存領域の構成と、局データ及び呼制御プログラムの書き換えとを説明する説明図である。
【図１２】第４の実施形態のフラッシュメモリ部への書き込みを判断する判断テーブルの構成を示す構成図である。
【図１３】第５の実施形態のフラッシュメモリ部への書き込みを判断する判断テーブルの構成を示す構成図である。
【発明を実施するための形態】
【００２１】
（Ａ）第１の実施形態
以下では、本発明の呼制御装置、方法及びプログラムの第１の実施形態について、図面を参照しながら説明する。
【００２２】
第１の実施形態は、揮発性メモリ上にＲＡＭディスク領域を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報（局データ、加入者データ等）を揮発性メモリにローディングして呼制御を行い、不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置に、本発明を適用する実施形態を説明する。
【００２３】
（Ａ−１）第１の実施形態の構成
図２は、第１の実施形態の通話システムの全体構成を示す全体構成図である。また、図１は、第１の実施形態の交換機の構成を示す構成図である。
【００２４】
図２において、第１の実施形態の通話システム１０は、交換機１、電話端末２−１〜２−ｎ（ｎは正の整数）を有して構成される。
【００２５】
図１において、第１の実施形態の交換機１は、制御部１１、通信部１２、ＲＡＭ部１３、フラッシュメモリ部１５を少なくとも有して構成される。
【００２６】
通信部１２は、接続する通信回線との間で、所定の通信方式に従って情報の送受信を行うものである。通信部１２の接続回線は、例えばアナログ回線、ＩＰ（インターネットプロトコル）回線、ディジタル回線、光回線等を適用することができ、又通信方式は、種々の方式を適用することができる。
【００２７】
制御部１１は、交換機１の呼制御機能を司るものであり、例えばＣＰＵ等が該当する。
【００２８】
ＲＡＭ部１３は、揮発性メモリであり、ＤＩＭＭを適用することができる。また、ＲＡＭ部１３は、メモリ領域上の一部にＲＡＭディスク部１４を形成するものである。
【００２９】
ＲＡＭディスク部１４は、フラッシュメモリ部１５に対する書き込み情報を格納する領域である。
【００３０】
フラッシュメモリ部１５は、不揮発性メモリであり、例えばＳＳＤを適用することができる。また、フラッシュメモリ部１５は、制御部１１の制御を受けて、ＲＡＭディスク部１４に格納される書き込み情報の内容を保存するものである。さらに、フラッシュメモリ部１５は、ＯＳ（オペレーティングシステム）１６、呼制御アプリケーション１７、局データ１８を格納する。この呼制御アプリケーション１７と局データ１８を、制御部１１がＲＡＭ１３に呼び込み（ローディング）呼制御に利用する。
【００３１】
ＯＳ１６は、ＲＡＭ部１３上に生成されたＲＡＭディスク部１４を使用可能にするオペレーティングシステムであり、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｗｉｎｄｏｗｓ（登録商標） ｅｍｂｅｄｄｅｄが適用できる。
【００３２】
続いて、交換機１において、ＲＡＭ部１３にローディングされた呼制御アプリケーション１７及び局データ１８のいずれか又は両方を格納するフラッシュメモリ部１５の領域に対する書き込み情報を検知する場合に、その検知に基づいてＲＡＭディスク部１４の書き込み情報のうち呼制御アプリケーション１７及び局データ１８のいずれか又は両方の書き込み情報の内容を、フラッシュメモリ部１５に書き込みを行う書き込み処理の機能部を説明する。
【００３３】
なお、以下では、局データ１８が更新された場合に、更新された局データ１８をフラッシュメモリ部１５に書き込む場合を例示するが、呼制御アプリケーション１７の更新の場合も基本的には同様に機能する。
【００３４】
図５は、ＲＡＭディスク部１４の内容をフラッシュメモリ部１５に書き込み行う書き込み処理を実現する機能部の構成を示すブロック図である。
【００３５】
図５に示すように、第１の実施形態の書き込み処理を実現する機能部としては、局データ更新検知部２１、局データ呼び込み制御部２２、局データ復旧部２３、ＣＰＵ使用率確認部２４、書き込み制御部２５がある。
【００３６】
局データ更新検知部２１は、呼制御の開始後に、ＲＡＭディスク部１４に格納される書き込み情報から、ＲＡＭ部１３にローディングされた局データ１８を格納するフラッシュメモリ部１５の領域に対する書き込み情報を検知することで局データ１８が更新されたか否かを検知するものである。
【００３７】
ここで、局データ１８の更新検知方法としては、例えば、フラッシュメモリ部１５に格納された局データ１８のファイル名に対する書き込み情報を検知する方法等を適用することができる。このファイル名は、ＯＳ１６がフラッシュメモリ部１５をマウントした際のファイルシステムに基づくファイル名で、ファイルシステム中に存在するファイルの領域を特定する識別子である。また、ファイル名の表し方としては、単にファイル名を示す場合と、ファイルシステム中のディレクトリ構造を含めた絶対パス又は相対パスで示す場合が適用できる。
【００３８】
また、局データ更新検知部２１は、局データ１８を格納するフラッシュメモリ部１５の領域に対する書き込み情報を検知するために、局データ１８がローディングされるときに局データ１８のファイル名を保持しておく。
【００３９】
また、呼制御アプリケーション１７の更新検知方法としては、上記のファイル名に対する書き込み情報を検知する方法に加え、例えば、呼制御アプリケーション１８のバージョン変化を検知する方法等を適用することができる。この場合、局データ更新検知部２１は、呼制御アプリケーション１７を格納するフラッシュメモリ部１５の領域に対する書き込み情報を検知するために、呼制御アプリケーション１７がローディングされるときに呼制御アプリケーション１７のファイル名又はバージョンを保持しておく。バージョンの情報は、呼制御アプリケーション１７を呼び込んだ結果、出力する自律メッセージから受け取ることで取得できるものである。
【００４０】
局データ呼び込み制御部２２は、局データ更新検知部２１が局データ１８の更新を検知した場合に、呼制御アプリケーション１７に対して、更新された局データ１８を呼び込ませるものである。
【００４１】
局データ復旧部２３は、呼制御アプリケーション１７が更新された局データ１８を呼び込む際に、更新された局データ１８の呼び込みが失敗したときに、それ以前の局データ１８を復旧するものである。
【００４２】
ＣＰＵ使用率確認部２４は、呼制御アプリケーション１７により更新された局データ１８の呼び込みが正常に行われた場合に、ＣＰＵ使用率が閾値を超えているか否かを確認するものである。
【００４３】
書き込み制御部２５は、ＲＡＭディスク部１４に格納されている内容を、フラッシュメモリ部１５に書き込み制御するものである。
【００４４】
ここで、後述するフラッシュメモリ部１５（例えばＳＳＤ）は、書き込み制限が設けられている（例えば１０万回）。従って、最新の呼制御アプリケーション１７及び局データ１８を正しくフラッシュメモリ部１５に効率的かつ有効に保存するために、第１の実施形態の書き込み制御部２５は、フラッシュメモリ部１５への書き込み制限を掛けながら行う。
【００４５】
書き込み制御部２５は、例えば、Enhanced Write Filter（以下、ＥＷＦという）を利用する。このＥＷＦは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ｅｍｂｅｄｄｅｄのＯＳに特有の機能であり、ＯＳランタイムイメージへの書き込み制限を行う機能である。
【００４６】
これにより、ＲＡＭ部１３上のＲＡＭディスク部１４を保護パティーションに対する書き込み情報をリダイレクトする領域とし、ＲＡＭディスク部１４に格納された書き込み情報をフラッシュメモリ部１５の空き領域に格納することができる。つまり、リダイレクトする領域であるＲＡＭディスク部１４はＥＷＦの仕組におけるオーバーレイの領域で、オーバーレイの領域にはディスクＩ／Ｏがリダイレクトされ書き込みＩ／Ｏ後のディスクの状態（Ｉ／Ｏ結果）を表すＩ／Ｏキャッシュ（ディスクイメージ）が保存される。したがって、このリダイレクトとはフラッシュメモリ部１５に対するすべての書き込み情報をＲＡＭディスク部１４にキャッシュを格納し保存することである。
【００４７】
そのため、図６に示すように、フラッシュメモリ部（ＳＳＤ）１５からのデータ読み込みや、ＲＡＭディスク部（オーバレイ）１４へのデータ書き込み又は再読み込みが可能となる。再読み込みについては、ＲＡＭディスク部１４に書き込み情報がある場合にはＲＡＭディスク部１４から書き込み情報に基づいて読み込みを行い、書き込み情報がない場合にはフラッシュメモリ部１５から読み込みを行うことで再読込みを行う。
【００４８】
また、ＲＡＭディスク部１４は、揮発性メモリであるＲＡＭ部１３上に形成された領域なので、リブートするとＲＡＭディスク部１４の格納内容は破棄される。
【００４９】
さらに、第１の実施形態では、ＲＡＭディスク部１４に格納される書き込み情報から局データ１８の更新を検知し、更新した場合にフラッシュメモリ部１５に書き込むようにし、直接フラッシュメモリ部１５への書き込まれないようにしたので、フラッシュメモリ部１５への書き込み回数を削減することができる。
【００５０】
さらに、急な電源断（例えば、ＰＫＧ抜去、交換機１の電源ＯＦＦ等）に対してシステムを保護することができる。
【００５１】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態の交換機１において、ＲＡＭディスク部１４の内容をフラッシュメモリ部１５に書き込みを行う処理の動作を、図面を参照しながら説明する。
【００５２】
以下では、図１において、最初に電話端末２−１及び電話端末２−２のみが交換機１と接続しており、その後新たに電話端末２−ｎが追加され、この追加に伴い局データ１８を更新する場合を例示して説明する。
【００５３】
なお、以下では、局データ１８の更新の場合を例示するが、呼制御アプリケーション１７の更新の場合にも基本的な処理は同様の処理で実現できる。
【００５４】
ただし、図４のステップＳ４１では、局データ１８の場合と呼制御アプリケーション１７の場合とで具体的な処理が異なるので、この点について後で詳細に説明する。
【００５５】
図３は、第１の実施形態の交換機１における局データが更新されない場合の処理を示すフローチャートである。また、図４は、第１の実施形態の交換機１における局データの更新後の処理を示すフローチャートである。
【００５６】
まず、交換機１に電源が投入されて起動すると、交換機１は呼制御を開始できるよう準備する。
【００５７】
具体的には、交換機１において、ＯＳ１６が起動し（ステップＳ３１）、ＲＡＭ部１３の領域にＲＡＭディスク部１４が構築され（ステップＳ３２）、呼制御アプリケーション１７の起動（ステップＳ３３）及び局データ１８の呼び込み（ステップＳ３４）が行われ、かかる後に呼制御を開始（ステップＳ３５）する。ここで、ＯＳ１６はＲＡＭディスク部１４を構築する機能を有しており、これを使用することでＲＡＭ部１３の領域にＲＡＭディスク部１４を構築することができる。ＲＡＭディスク部１４の構築後は、ＯＳ状態情報、ＯＳ起動ログ、ネットワークからのアクセスログ、呼制御アプリケーションの起動ログ、呼制御により発生する課金情報等を記憶するためのフラッシュメモリ部１５に対する書き込みは、ＲＡＭディスク部１４に書き込み情報として格納される。
ステップＳ３６で、交換機１が電話端末２−１及び電話端末２−２間の呼制御を開始した後、局データ１８の更新がない場合であって、交換機１においてシャットダウンした場合（ステップＳ３７）、ＲＡＭディスク部１４の内容をフラッシュメモリ部１５に書き込み（ステップＳ３８）、この書き込み終了後に、交換機１が停止する。
【００５８】
ステップＳ３８において、フラッシュメモリ部１５への書き込みについては、ＯＳ１６のシャットダウン処理の一環として実行されるため、書き込みの際には、ＣＰＵ使用率は参照されない。このステップＳ３８は、ＲＡＭディスク部１４のすべての内容をフラッシュメモリ部１５に書き込むものである。
【００５９】
なお、ステップＳ３６において局データの更新がなく、さらに交換機１がシャットダウンしない場合（ステップＳ３７）には、通常の運用中であるとみなし、フラッシュメモリ部１５への書き込みアクセスを行わない。
【００６０】
ステップＳ３６において、交換機１で呼制御が行われている状態で、局データ１８が更新されたことを検出した際の動作について図４を参照しながら説明する。
【００６１】
例えば、交換機１が新たに電話端末２−ｎを収容することに伴い、局データ１８が更新されると（ステップＳ３６）、ステップＳ４１に遷移する。
【００６２】
ここで、更新された局データ１８はＲＡＭディスク部１４に書き込み情報として格納される。
【００６３】
なお、ここでの事例では１台の電話端末の追加を例示しているが、長時間に亘る大容量の局データ１８の更新作業を考慮して、局データ１８の更新を検知した後に、一定時間待ち状態とし、この待ち状態の間に局データ１８が更新されなかった場合に局データ１８の更新作業が終了したとみなして処理ステップＳ４１に遷移させるようにしてもよい。
【００６４】
この場合、待ち状態の間に局データ１８が更新された場合には、局データ１８の更新作業が継続する可能性があると判断し、局データ１８の更新作業が終了するまでステップＳ４１への処理に遷移させることを保留させる。
【００６５】
ステップＳ４１では、呼制御アプリケーション１７が、局データ１８を正常に呼び込めることを確認する。そして、呼制御アプリケーション１７が局データ１８の呼び込みに成功した場合は前記局データ１８をフラッシュメモリ部１５に書き込み可能と判断し、ステップＳ４２に遷移する。
【００６６】
ここで、呼び込む局データ１８は更新された局データ１８であるから、呼制御アプリケーション１７はＲＡＭディスク部１４の書き込み情報に基づいて再読み込みし、局データ１８を呼び込む。
【００６７】
なお、局データ１８の呼び出し方法としては、例えば、更新されたデータのみを呼び込む方法（例えば、新たな電話端末２−ｎに関する局データ１８のみを呼び出す方法等）、局データ１８全体を呼び込む方法等を適用することができる。
【００６８】
呼制御アプリケーション１７が正常に局データ１８を呼び込めない場合、ステップＳ３７に遷移して通常の運用状態に戻り、ＲＡＭディスク部１４の内容をフラッシュメモリ部１５に書き込まないようにする（ステップＳ４１）。
【００６９】
ここで、上述したように、局データ１８の呼び込みの正常性判断の具体的な方法と、呼制御アプリケーション１７の呼び込みの正常性判断の具体的な方法とは異なるので、この点について詳細に説明する。
【００７０】
（ア）局データ１８の呼び込みの正常性判断の方法
呼制御アプリケーション１７による局データ１８の呼び込みの正常性判断の方法としては、次の２つのいずれか又は双方を適用することができる。なお、次の２つのいずれか又は双方を適用するか否かは予め交換機１に設定しておくことで実現できる。
【００７１】
第１の方法は、呼制御アプリケーション１７が局データ１８を呼び込むためのルーチン（routine）のリターンコードで正常に呼び込めたか否かを判断する方法である。リターンコード０のとき正常に呼び込みができたことを示し、リターンコード１のとき正常に呼び込みができなかったことを示す。この場合、制御部１１は、呼制御アプリケーションからリターンコードを受け取るインタフェースを有することが必要であり、このインタフェースを介して受け取ったリターンコードから判断することで実現できる。
【００７２】
第２の方法は、呼制御アプリケーション１７が局データ１８を呼び込んだ結果、出力する自律メッセージにより正常に呼び込んだか否かを判断する方法である。呼制御アプリケーション１７は、局データ１８を呼び込んだ際、正常に呼び込めたか否かを自律メッセージに出力する。この自律メッセージはログファイルに出力される場合と、ＯＳの標準出力に出力される場合とを適用できる。この場合、制御部１１は、ログファイルにアクセスするインタフェース又は標準出力を受け取るインタフェースを有することが必要であり、制御部１１がログの内容から正常に呼び込めたか否かを判断する。具体的には、制御部１１はログの内容から、自律メッセージのタイプが通常メッセージであることを示す「＃・・」を検索できた場合、局データ１８のローディングが成功して出力されていることを判断し、局データ１８を正常に呼び込めたものと判断し、通常メッセージを示す「＃・・」を検索できなかった場合、局データ１８のローディングが成功して出力されていないと判断し、局データ１８の呼び込みが正常でないと判断することができる。
【００７３】
ここで、自律メッセージには、例えば、重要度により最緊急メッセージ、緊急メッセージ、エラーメッセージおよび通常メッセージの４つのタイプがある。
【００７４】
例えば、最緊急メッセージはメッセージの冒頭に「＊＊＊」が付与されるもので、呼制御アプリケーションのシステム動作確認により装置のハード及びソフトを含めて障害の状態と検出し、呼処理を再開できないシステムダウンの状態を示すものである。緊急メッセージはメッセージの冒頭に「＊＊・」が付与されるもので、呼制御アプリケーションのシステム動作確認は行っていないが装置が故障の状態であり、故障状態で強制的に呼処理を継続しシステムダウンに至る恐れがある状態を示すものである。エラーメッセージはメッセージの冒頭に「＊・・」が付与されるもので、呼処理エラーやプログラムエラーの状態を示すものである。通常メッセージはメッセージの冒頭に「＃・・」が付与されるもので、局データのローディングの成功、回線接続成功、ＰＫＧ挿抜、ＰＫＧ制御などの状態を示すものである。
【００７５】
なお、第１の実施形態では、第１の方法により、制御部１１が、呼制御アプリケーション１７による局データ１８の呼び込みが正常に行われたことを判断する場合を示す。
【００７６】
また、呼制御アプリケーション１７が局データ１８の呼び込みに失敗した場合、その局データ１８を以前の局データ１８に復旧するようにしても良い。
【００７７】
この局データ１８の復旧方法としては、例えば、フラッシュメモリ部１５から局データ１８を再度ＲＡＭ部１３に呼び込んで復旧する方法を適用したりＲＡＭ部１３で以前の局データ１８を保持しておき、新しい局データ１８の呼び出しに失敗した場合に、その更新前の局データ１８に切り戻す方法等を適用することができる。
【００７８】
（イ）呼制御アプリケーションデータ１７の呼び込みの正常性判断の方法
呼制御アプリケーション１７を呼び込んだ結果、出力する自律メッセージにより正常に呼び込めたか否かを判断する方法である。呼制御アプリケーション１７は、自身が呼び込まれた際、呼び込みにより自身が障害や異常を検出すると自律メッセージに出力する。この自律メッセージはログファイルに出力される場合と、ＯＳの標準出力に出力される場合とを適用できる。この場合、制御部１１は、ログファイルにアクセスするインタフェース又は標準出力を受け取るインタフェースを有することが必要であり、制御部１１がログの内容から正常に呼び込めたか否かを判断する。具体的には、交換機１で呼制御アプリケーション１７を呼び込み障害や異常を検出せず呼処理をし、更新により新たな呼制御アプリケーション１７を呼び込み障害や異常を検出し自律メッセージに出力すれば、新たな呼制御アプリケーション１７は正常でないと判断できる。
【００７９】
したがって、制御部１１はログの内容から、「＊＊＊」を検索し自律メッセージの最緊急メッセージが出力されていないことを判断することで障害や異常あるか否かを判断することができる。
【００８０】
ステップＳ４２では、交換機１のＣＰＵ使用率がある閾値以下になった時点で、ＲＡＭディスク部１４に保存される書き込み情報の内容をフラッシュメモリ部１５に書き込めるようにし（ステップＳ４３）、ステップＳ３７に遷移する。
【００８１】
ステップＳ４２を実行する時点でのＣＰＵ使用率が閾値より大きい場合、再度ステップＳ４２に遷移し、ＣＰＵ使用率が閾値を下回るまで待つ。
【００８２】
ここで、ＣＰＵ使用率の閾値の決定方法としては、交換機１の環境に応じて適宜決定することができるが、例えばWindows（登録商標）をＯＳに使用する場合においては、ＣＰＵ使用率を８０％以内の状態でコンピュータを動作させることを推奨することがあり、この推奨値からの猶予を見て、閾値を７０％とする。他のＯＳによるＲＡＭディスク部１４からフラッシュメモリ部１５への書き込み処理においても、同様にして閾値を決定することが可能であり、７０％以外の値を設定可能であることは当然である。
【００８３】
ステップＳ４３で、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込めるようにしてステップＳ３７に遷移し、交換機１が通常の動作をすれば、ＲＡＭディスク部１４の内容が、フラッシュメモリ部１５に書き込まれる。このステップＳ４３は、ＲＡＭディスク部１４に格納される書き込み情報のうち更新された局データ１８の書き込み情報の内容をフラッシュメモリ部１５に書き込むものである。
【００８４】
なお、ステップＳ３６の局データ１８の更新の検知で、フラッシュメモリ部１５に格納された局データ１８のファイル名に対する書き込み情報を検知するので、ステップＳ４３の書き込みの際、ＲＡＭディスク部１４に格納される書き込み情報のうち更新された局データ１８に関わる書き込み情報とそれ以外の書き込み情報を区別できるものである。
【００８５】
（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、フラッシュメモリ部１５に更新後の局データ１８以外を書き込まない制限をしつつ、局データ１８の更新要求のみで、ＲＡＭディスク部１４に対してのみならず、フラッシュメモリ部１５に対して更新後の局データ１８を保存することができる。
【００８６】
これにより、局データ１８の更新手順の簡素化、局データ１８のフラッシュメモリ部１５への更新漏れの防止、交換機１の故障によるＲＡＭディスク部１４の局データ１８の消失に対する救済策の提供が可能となる。
【００８７】
（Ｂ）第２の実施形態
次に、本発明の呼制御装置、方法及びプログラムの第２の実施形態について図面を参照しながら説明する。
【００８８】
第１の実施形態では、局データ（又は呼制御アプリケーション）の更新があった場合に、局データの呼び込みが正常に行えたか否かを判断した後に、ＲＡＭディスク部に格納される書き込み情報の内容をフラッシュメモリ部に書き込む実施形態を例示した。
【００８９】
しかしながら、更新後の局データのシンタックスが正常であるために、呼制御アプリケーションが呼び込みに成功できたとしても、実際の交換システムで正しく動作する保証は必ずしもない。
【００９０】
このような場合に、フラッシュメモリ部１５への書き込みを許容すると、正しく動作し得ない局データをフラッシュメモリ部１５に保存することになる。また、この余分な書き込み作業により書き込み回数を消費することにもなる。
【００９１】
そこで、第２の実施形態は、局データの更新があった場合に、呼制御に成功したか否かを判断した後に、ＲＡＭディスク部に格納される書き込み情報の内容をフラッシュメモリ部に書き込む実施形態を例示する。
【００９２】
（Ｂ−１）第２の実施形態の構成
第２の実施形態が第１の実施形態の構成と異なる点は、フラッシュメモリ部１５への書き込み処理を実現する機能部である。そこで、第２の実施形態では、この書き込み処理の機能部の構成について詳細に説明し、第１の実施形態で既に説明した構成の説明については省略する。
【００９３】
図７は、第２の実施形態のフラッシュメモリ部１５への書き込みを行う書き込み処理の機能部の構成を示す構成図である。図７において、第２の実施形態の書き込み処理機能部は、局データ更新検知部２１、局データ呼び込み制御部２２、局データ復旧部２３、ＣＰＵ使用率確認部２４、呼制御確認部２６、呼制御エラー発生状況確認部２７、異常通知部２８、書き込み制御部２５を有する。
【００９４】
なお、局データ更新検知部２１、局データ呼び込み制御部２２、局データ復旧部２３、ＣＰＵ使用率確認部２４、書き込み制御部２５は、第１の実施形態で説明した機能と同じであるので、ここでの説明を省略する。
【００９５】
呼制御確認部２６は、局データ１８又は呼制御アプリケーション１７が更新された後、当該交換機１がその更新された局データ１８を用いて呼制御を行い、その呼制御が成功するか否かを確認するものである。
【００９６】
呼制御エラー発生状況確認部２７は、呼制御確認部２６により呼制御が失敗したと判断した場合に、局データ１８又は呼制御アプリケーション１７の更新から現時点までの呼制御エラーの発生状況を確認するものである。
【００９７】
異常通知部２８は、呼制御のエラーが頻繁に発生するような場合に、交換機１の作業者に対し、更新後の局データ１８又は呼制御アプリケーション１７に異常があったこと、かかる異常に付随するエラーログ、更新後の局データ１８又は呼制御アプリケーション１７のフラッシュメモリ部１５への書き込みが行われないこと、局データ１８又は呼制御アプリケーション１７への更新を破棄する旨のいずれか又はこれらを組み合わせた情報を通知するものである。エラーログの情報は、呼制御アプリケーション１７を呼び込んだ結果、出力する自律メッセージから受け取ることで取得できるものである。
【００９８】
（Ｂ−２）第２の実施形態の動作
次に、第２の実施形態の交換機１において、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込みを行う書き込み処理の動作を図面を参照しながら説明する。
【００９９】
第２の実施形態は、局データ１８の更新後の処理が第１の実施形態と異なる。従って、局データ１８が更新されない場合の処理（図３に示す処理）は、第１の実施形態と同じであるので、ここでの再度の説明は省略する。
【０１００】
なお、局データ１８の更新の場合を例示するが、呼制御アプリケーション１７の更新の場合を同様にして適用できる。
【０１０１】
図８は、第２の実施形態の局データの更新後の処理を示すフローチャートである。
【０１０２】
まず、交換機１において呼制御の開始後、局データ１８が更新するとステップＳ５１に遷移する。
【０１０３】
ステップＳ５１では、呼制御アプリケーション１７が更新後の局データ１８を呼び込むことにより、更新後の局データ１８の正常性を確認すると（ステップＳ５１）、呼制御アプリケーション１７は、更新後の局データ１８を使用して呼制御の実行を待つ（ステップＳ５２）。
【０１０４】
ステップＳ５２において、例えば交換機１が電話端末２−ｎからの通話要求を受信する場合に、その呼制御が成功したとき、制御部１１は、ＣＰＵ使用率が閾値以下であるか否かを確認して閾値以下であれば（ステップＳ５５）、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込む（ステップＳ５６）。
【０１０５】
ここで、実際の交換システム１０の運用における呼制御確認のタイミングとしては、例えば、保守作業の確認時としても良いし、局データ１８の更新後に最初のオペレータが発呼するタイミングとしても良い。すなわち、必ずしもリアルタイムに呼制御の確認を行う必要はない。
【０１０６】
一方、ステップＳ５２では、例えば、着信先の無応答や着信先の話中といった発呼のタイミングにより解決可能な呼制御エラーや、また例えば、更新後の局データ１８の内容と電話端末情報の相違の存在や、呼制御アプリケーション１７やＯＳ１６の不具合といった、交換機１に起因する呼制御エラーが発生し得る。このような呼制御に関するエラーが生じた場合、呼制御に失敗したとして、ステップＳ５３に遷移する。
【０１０７】
ステップＳ５３では、局データ１８の更新後から現時点までの、呼制御エラーの発生状況を確認する（ステップＳ５３）。
【０１０８】
ここで、呼制御エラーの発生状況の確認としては、例えば、過去のエラー発生回数が少ない（閾値以下である場合）又はエラー発生頻度が低い（閾値以下である場合）には、直近の呼制御エラーは一時的な事象であるとみなし、ステップＳ５２に遷移し、処理を繰り返す。
【０１０９】
一方、過去の呼制御エラー発生回数が多い（閾値を超えている場合）又はエラー発生頻度が高い（閾値を超えている場合）、直近の局データ１８の更新により呼制御を正常に行えなくなったとみなし、ステップＳ５４に遷移する。
【０１１０】
ここで、ステップＳ５３におけるエラー発生状況の確認方法としては、種々の方法を適用できるが、例えば、所定時間の間に、所定回数以上の呼制御エラーが発生しているかどうかを確認する方法や、同種類の呼制御エラーが所定回数以上発生しているか否かを確認する方法や、ステップＳ５２における全ての呼制御エラーが所定回数以上発生しているかどうかを確認する方法を適用することができる。
【０１１１】
なお、ステップＳ５３からステップＳ５４に遷移する場合には、制御部１１は、交換機１の作業者に対し、更新後の局データ１８に異常があったこと、かかる異常に付随するエラーログ、更新後の局データ１８のフラッシュメモリ部１５への書き込みが行われないこと、及び又は、局データ１８への更新を破棄する旨を通知するようにしてもよい。
【０１１２】
ステップＳ５４では、直近の局データ１８の更新を破棄し、更新直前の局データ１８にロールバックして、図３のステップＳ３７に遷移する（ステップＳ５４）。
【０１１３】
このように、呼制御が正常に行われた後に、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込むようにしたので、呼制御を正常に行えない局データ１８をフラッシュメモリ部１５に書き込むことを防ぐことができる。
【０１１４】
また、局データ１８の更新により呼制御が正常に行われなくなった場合であっても、過去の正常に動作することを保証された局データ１８への回復及び回復後の局データ１８を用いた交換機１の稼動、及び交換機１が稼動状態に復帰可能であることにより、局データ１８の更新の失敗後であっても、局データ１８に対する新たなデータ更新を受理することが可能となる。
【０１１５】
（Ｂ−３）第２の実施形態の効果
以上のように、第２の実施形態では、第１の実施形態により得られる効果に加えて、実際に呼制御が可能な局データ１８のみをＲＡＭディスク部１４の書き込み情報の内容からフラッシュメモリ部１５に書き込むことが可能になった。
【０１１６】
これにより、交換機１として正常に動作する局データ１８のみを選別してフラッシュメモリ部１５に書き込むことが可能になる。
【０１１７】
さらに、第２の実施形態によれば、呼制御に供することができない局データのフラッシュメモリ部１５への書き込み処理による、フラッシュメモリ部１５の書き込み回数の延命が可能になる。
【０１１８】
（Ｃ）第３の実施形態
次に、本発明の呼制御装置、方法及びプログラムの第３の実施形態について図面を参照しながら説明する。
【０１１９】
第３の実施形態は、局データの更新があるときに、直ちにフラッシュメモリ部１５に書き込みをした後にシステムを再起動又はシャットダウンする実施形態を例示して説明する。
【０１２０】
（Ｃ−１）第３の実施形態の構成
第３の実施形態が第１の実施形態の構成と異なる点は、フラッシュメモリ部１５への書き込みを行う書き込み処理の機能部の構成であるので、以下では、第３の実施形態の書き込み処理機能部の構成を詳細に説明し、第１の実施形態で既に説明した構成の説明については省略する。
【０１２１】
図９は、第３の実施形態の書き込み処理の機能部の構成を示す構成図である。図９において、第３の実施形態の書き込み機能部は、局データ更新検知部２１、局データ呼び込み制御部２２、局データ復旧部２３、ＣＰＵ使用率確認部２４、書き込み制御部２５、再起動部２９を有する。
【０１２２】
なお、局データ更新検知部２１、局データ呼び込み制御部２２、局データ復旧部２３、ＣＰＵ使用率確認部２４、書き込み制御部２５は、第１の実施形態で説明した機能と同じであるので、ここでの説明を省略する。
【０１２３】
再起動部２９は、局データ１８の更新があるときに、直ちにフラッシュメモリ部１５に書き込みをした後にシステムを再起動又はシャットダウンするものである。
【０１２４】
（Ｃ−２）第３の実施形態の動作
次に、第３の実施形態の交換機１において、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込みを行う書き込み処理の動作を、図面を参照しながら説明する。
【０１２５】
図１０は、第３の実施形態の交換機１における処理を示すフローチャートである。図１０において、図３に示す処理と同一の処理については、同一の番号を付与する。
【０１２６】
交換機１においてＯＳが起動し、呼制御が開始した後（ステップＳ３１〜Ｓ３５）、呼制御アプリケーション１７は、局データ１８の更新を監視し、局データ１８の更新がない限り、通常の交換機１を運用する（ステップＳ６１）。
【０１２７】
ステップＳ６１において、局データ１８の更新処理が検知されると、ステップＳ６２に遷移する。ステップＳ６２では、ＲＡＭディスク部１４に格納される書き込み情報の内容が、フラッシュメモリ部１５に書き込まれる（ステップＳ６２）。
【０１２８】
なお、局データ１８の更新検知方法や、局データ１８のフラッシュメモリ部１５への書き込み方法は、第１の実施形態と同様の処理を適用できる。
【０１２９】
また、ステップＳ６１からステップＳ６２に遷移する前に、第１又は第２の実施形態で説明した処理を適用することができる。
【０１３０】
つまり、制御部１１において監視しているＣＰＵ使用率が閾値を下回るまで待機させることも可能であること（図４におけるステップＳ４２の挿入）、呼制御アプリケーション１７が更新後の局データ１８を呼び込み、かかる呼び込みが成功した場合にのみステップＳ６２に遷移し、ＲＡＭディスク部１４に格納された局データ１８をフラッシュメモリ部１５に書き込むことも可能であること（図４におけるステップＳ４１の挿入）、および実際の呼制御が成功した場合にのみステップＳ６２に遷移し、ＲＡＭディスク部１４に格納された局データ１８をフラッシュメモリ部１５に書き込むことも可能であること（図８におけるステップＳ５２の挿入）は当然である。
【０１３１】
次に、ステップＳ６３では、ＲＡＭディスク部１４に格納された局データ１８のフラッスメモリ部１５への書き込み処理の終了後に、ＯＳ１６は交換機１をシャットダウン又はリブートする。
【０１３２】
このように、ＯＳ１６がシャットダウン又はリブートすることにより、ＲＡＭディスク部１４を開放し、起動時に再度構築することで、ＲＡＭディスク部１４のクリーンアップを行い、新たな局データ１８をローディングした呼制御アプリケーション１７で呼制御を行うことができる。
【０１３３】
また、交換機１がリブートされた場合、ステップＳ３１に遷移し、再度呼制御を提供できる状態となる。
【０１３４】
（Ｃ−３）第３の実施形態の効果
以上のように、第３の実施形態によれば、第１の実施形態の効果に加えて、更新された局データをフラッシュメモリ部１５に書き込みした後に、ＯＳが再起動することにより、再度ＲＡＭディスク部１４をクリーンアップして再構築することができ、新たな局データ１８で呼制御を行うことができる。
【０１３５】
（Ｄ）第４の実施形態
次の本発明の呼制御装置、方法及びプログラムの第４の実施形態を、図面を参照しながら説明する。
【０１３６】
第４の実施形態は、ＲＡＭディスク部１４に格納される書き込み情報の内容をフラッシュメモリ部１５に書き込む際、フラッシュメモリ部１５の空き領域を判断した後に書き込みを行う実施形態を例示する。
【０１３７】
図１１（Ａ）は、フラッシュメモリ部１５の保存領域を説明する説明図である。図１１に示すように、フラッシュメモリ部１５の保存領域の構成を見ると、ＯＳ１６等の保存領域、呼制御アプリケーション１７の保存領域、局データ１８の保存領域があり、この他に空きの保存領域が存在する。
【０１３８】
このとき、局データ１８又は呼制御アプリケーション１７をフラッシュメモリ部１５に書き込む際、この書き込みを許容するためには、空きの保存領域の容量を考慮する必要がある。
【０１３９】
つまり、図１１（Ｂ）に示すように、新たにフラッシュメモリ部１５に書き込みを行う局データ１８の保存領域の容量は、現在の局データ１８の保存領域の容量に、現在の局データ１８の空きの保存領域の容量を加えた範囲内であることが望ましい。この点については、呼制御プログラムの場合も同様である。
【０１４０】
そこで、第４の実施形態では、フラッシュメモリ部１５に更新後の局データ１８又は呼制御アプリケーション１７を書き込む際に、空きの保存領域も判断する。
【０１４１】
書き込み制御部２５は、第１〜第３の実施形態と同様の処理を行うと共に、フラッッ種メモリ部１５への書き込みの際に、更新後の局データ１８の保存領域の容量と、現在の局データ１８の保存領域及び空き領域の容量とを比較して、その比較結果に応じて更新後の局データ１８の書き込みをするか否かの判断を行う。
【０１４２】
そして、書き込み制御部２５は、書き込みＯＫと判断した場合、更新後の局データ１８をフラッシュメモリ部１８に書き込み、そうでない場合、更新後の局データ１８の書き込みを行わない。なお、書き込み制御部２５は、呼制御アプリケーション１７の場合も同様に行う。
【０１４３】
また、第３の実施形態ではフラッシュメモリ部１５への書き込み終了後に、リブートなどを行う場合を説明したが、その場合でも、更新後の局データ１８（又は呼制御アプリケーション１７）をフラッシュメモリ部１５に書き込んだ後にリブート等を行うため、更新後の局データ１８等を担保することができる。つまり更新した最新の局データ（もしくは呼制御プログラム）をフラッシュメモリに記憶しつつ運用を継続ができる。
【０１４４】
この書き込み制御部２５による判断方法としては、例えば、図１２に示す判断テーブルを用いて行う。
【０１４５】
図１２において、新たな呼制御アプリケーション１７の保存領域の容量が、現在の呼制御プログラムの保存領域に空き領域を加えた保存領域の容量を超越する場合、書き込み制御部２５は、新たな呼制御アプリケーション１７のフラッシュメモリ部１５への書き込みを行わない。
【０１４６】
一方、新たな呼制御アプリケーション１７の保存領域の容量が、現在の呼制御プログラムの保存領域に空き領域を加えた保存領域の容量以下である場合、書き込み制御部２５は、新たな呼制御アプリケーション１７のフラッシュメモリ部１５への書き込みを行う。
【０１４７】
局データ１８の場合も同様に、新たな局データ１８の保存領域の容量が、現在の局データ１８の保存領域に空き領域を加えた保存領域の容量を超越する場合、書き込み制御部２５は、新たな局データ１８のフラッシュメモリ部１５への書き込みを行わない。
【０１４８】
一方、新たな局データ１８の保存領域の容量が、現在の局データ１８の保存領域に空き領域を加えた保存領域の容量以下である場合、書き込み制御部２５は、新たな局データ１８のフラッシュメモリ部１５への書き込みを行う。
【０１４９】
新たな局データ１８及び呼制御アプリケーション１７を、フラッシュメモリ部１５に書き込みを行わない場合、ＲＡＭディスク部１４上にキャッシュとして残る。しかし、再起動すると、その新たな局データ１８及び呼制御アプリケーション１７はフラッシュメモリ部１５に保存されていないので、更新後の局データ１８及び呼制御アプリケーション１７を担保することはできない。つまり更新した最新の局データ（もしくは呼制御プログラム）で単に運用を継続する。
【０１５０】
こうすることで、フラッシュメモリ部１５の空き容量があるときに適宜にＲＡＭディスク部１４上の内容がフラッシュメモリ部１５上に反映され、書き込み・削除回数の限定されているフラッシュメモリ部１５の寿命を延命することができる。
【０１５１】
例えば、ＷｉｎｄｏｗｓなどのＯＳで、１００ＭＢの空き容量があるＨＤＤに、３００ＭＢのファイルを書き込もうとするとき、３００ＭＢのうち１００ＭＢ書き込みを行い１０１ＭＢの書き込みを行うときにＨＤＤの空き容量が無いという警告のポップアップウインドウが表示される。
【０１５２】
このとき、ＨＤＤでは１００ＭＢの空き容量に１００ＭＢを書き込み、（ＨＤＤの空き容量が無いという警告のポップアップウインドウを作業者に表示し）その後、書き込んだ１００ＭＢを削除する処理をする。ＨＤＤがＳＳＤである場合も同じであるから、書き込み・削除回数が限定されているＳＳＤの寿命が目減りしてしまう。
【０１５３】
しかし、第４の実施形態によれば、更新後の局データ１８等の容量が、保存領域の容量を超えている場合には、その局データ１８等の書き込み自体を行わないので、書き込み回数を減らすことができ、フラッシュメモリ部１５の寿命を延命できる。
【０１５４】
（Ｅ）第５の実施形態
次に、本発明の呼制御装置、方法及びプログラムの第５の実施形態を、図面を参照しながら説明する。
【０１５５】
第４の実施形態では、フラッシュメモリ部１５への書き込みを行う際に、フラッシュメモリ部１５の空き領域の容量を判断することとした。
【０１５６】
第５の実施形態では、第４の実施形態において、局データ１８と呼制御アプリケーション１７の双方が更新されたときに、フラッシュメモリ部１５の空き領域に対し、局データ１８と呼制御アプリケーション１７の双方が書き込めるか否かの判断をし、書き込みをする実施形態を説明する。
【０１５７】
書き込み制御部２５は、第１〜第４の実施形態で説明した処理の他に、更新後の局データ１８と更新後の呼制御アプリケーション１７の双方を、フラッシュメモリ部１５に書き込む際に、更新後の局データ１８及び呼制御プログラムの双方の容量と、それぞれの空き領域の容量とを比較して、これら更新後の局データ１８及び呼制御プログラムの書き込みを行うかどうかを判断するものである。
【０１５８】
この書き込み制御部２５の判断方法としては、例えば、図１３に示す判断テーブルを用いて判断する。
【０１５９】
例えば、図３及び図４において、作業者により局データ１８の更新が行われると、図３のステップＳ３６から、図４のステップＳ４１及びＳ４２を経て、ステップＳ４３に至る。このとき、ステップＳ４３では、更新後の局データ１８の容量が、フラッシュメモリ部１５の空き領域の容量を超えるか又は容量以下であるかを判断し、所定時間の待ち状態となる。
【０１６０】
また、この待ち状態のあいだに、作業者により呼制御アプリケーション１７の更新が行われると、図３のステップＳ３６から、図４のステップＳ４１及びＳ４２を経て、ステップＳ４３に至る。このときも、ステップＳ４３では、呼制御アプリケーション１７の容量が、フラッシュメモリ部１５の空き領域の容量を用いた判断を行う。
【０１６１】
上記のような状況の場合、書き込み制御部２５は、図１３に示す判断テーブルを用いて判断を行う。
【０１６２】
例えば、図１３に示すように、「新たな局データ１８の容量が空き領域の容量以下」で「新たな呼制御アプリケーション１７の容量が空き領域の容量以下」の場合は、新たな局データ１８及び呼制御アプリケーション１７を、フラッシュメモリ部１５に書き込みを行う。つまり、更新した最新の局データ１８及び呼制御アプリケーション１７を、フラッシュメモリ部１５に記憶しつつ運用を継続する。
【０１６３】
一方、「新たな局データ１８の容量が空き領域の容量を超え」で「新たな呼制御アプリケーション１７の容量が空き領域の容量を超える」の場合は、新たな局データ１８及び呼制御アプリケーション１７のフラッシュメモリ部１５への書き込みは行わない。
【０１６４】
ところで、図１３に示すように、例えば、「新たな呼制御アプリケーション１７の容量が空き領域の容量を超え」の条件で、「新たな局データ１７の容量が空き領域の容量以下」となる場合、新たな局データ１７は、空き容量以下であるから書き込みが可能だが、ここではＮＧの判断をし、書き込みを行わない。逆に、
これは、交換機特有の理由があるからである。旧来のＤ６０形自動交換機などのディジタル交換機は、交換用プログラムと局データが備えられ、これらにより電話の接続処理をしている。この交換用プログラムはプログラムごとに局データの構成が異なっている。なぜなら交換用プログラムのシステムデータで信号形式やサービス条件が決定し、信号形式やサービス条件が決定したこの交換用プログラムを含む局の局条件としてハード構成や課金条件や番号計画などを決定するものが局データだからである。
【０１６５】
交換用プログラムごとに局データの構成が異なるから、単に新たな局データを生成し、これを更新したとしても、交換用プログラムの信号形式やサービス条件に見合った構成の局データでなければ、この局データは交換用プログラムで利用できない。
【０１６６】
また、単に新たな交換用プログラムを生成し、これを更新したとしても、新たな交換用プログラムの信号形式やサービス条件に見合った構成の局データがなければ、この交換用プログラムは利用できない。つまり、交換用プログラムと局データは双方が利用できるものを対にしておく必要がある。
【０１６７】
したがって、第５の実施形態でも同様に、例えば図１３の左の列の最上段から一つ下の段で「新たな呼制御プログラムが空き容量以上」の条件で、右から２列目の最上段から二つ下の段で「新たな局データが空き領域以下」となっている場合、新たな局データ１８は空き容量以下であるから書き込みが可能だが、新たな呼制御アプリケーション１７が空き容量以上なので、結局のところ新たな局データ１８しか書き込めず、交換機１として動作できなくなる可能性が生じ得る。
【０１６８】
そのため、ここでは、局データ１８及び呼制御アプリケーション１７の書き込みを行わない。
【０１６９】
なお、ステップＳ４３での待ち時間のあいだに、作業者による更新がないと第４の実施形態と同様の動作になる。
【０１７０】
また、図１３で、ＮＧの判断のときは書き込みを行わず、ＲＡＭディスク上にキャッシュとして残るのみである。書き込みを行いませんので装置が再起動すると更新した局データおよび呼制御プログラムは担保されない。つまり更新した最新の局データおよび呼制御プログラムで単に運用を継続する。
【０１７１】
（Ｆ）他の実施形態
（Ｆ−１）第１〜第５の実施形態では、局データ１８の更新を契機に、ＲＡＭディスク部１４上の更新後の局データ１８の内容をフラッシュメモリ部１５に書き込む動作を説明したが、更新後の呼制御アプリケーション１７の更新動作についても、同様の処理によりフラッシュメモリ部１５に書き込むことができる。
【０１７２】
（Ｆ−２）本発明は、アナログ電話に限定せず、ＩＰ電話等にも適用可能である。
【０１７３】
また、本発明は、交換機１のコンソールを経由した局データ１８の更新、電話端末を経由した局データ１８の更新、自動実行による局データ１８の更新においても適用可能である。また、交換機１のコンソールについては、ローカルアクセス、リモートアクセスの別を問わない。
【０１７４】
（Ｆ−３）第１〜第５の実施形態で、局データ１８をフラッシュメモリ部１５（ＳＳＤ）に更新すると同時に、交換機１において重要な情報となる、呼処理するごとにＲＡＭディスク領域の課金情報のファイル（データ）の書き込み情報の内容もフラッシュメモリ部１５（ＳＳＤ）に反映するようにしてもよい。
【０１７５】
（Ｆ−４）第５の実施形態においては、呼制御アプリケーション１７と局データ１８の双方を判断しましたが、主装置が加入者データを記憶する場合は、呼制御アプリケーションと局データと加入者データの３つの書き込みが行えるか否かの判断をしてもよい。
【０１７６】
ここで、加入者データは加入者に対するサービス条件をいう。これは、呼制御アプリケーションが決定すると局データの構成が決定し、局データの構成が決定すると加入者データの構成が決定する関係にある。
【符号の説明】
【０１７７】
１…交換機、１１…制御部、１２…通信部、１３…ＲＡＭ部、１４…ＲＡＭディスク部、
１５…フラッシュメモリ部、１６…ＯＳ、１７…呼制御アプリケーション、
１８…局データ、２−１〜２−ｎ…電話端末、１０…通話システム。
【特許請求の範囲】
【請求項１】
揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を上記揮発性メモリにローディングして呼処理を行い、上記不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置において、
上記ＲＡＭディスク領域の書き込み情報から、呼処理により上記揮発性メモリにローディングされた上記呼制御アプリケーション及び又は上記呼制御情報を格納する上記不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理手段と、
上記更新検知処理手段の検知に基づいて上記ＲＡＭディスク領域の書き込み情報のうち上記呼制御アプリケーション及び又は上記呼制御情報の領域に対する書き込み情報の不揮発性メモリへの書き込みを行う書き込み処理手段と
を備えることを特徴とする呼制御装置。
【請求項２】
上記書き込み処理手段は、更新された上記呼制御アプリケーション及び又は上記呼制御情報の正常性を確認した後に、その更新された上記呼制御アプリケーション及び又は上記呼制御情報の上記不揮発性メモリへの書き込みを行うことを特徴とする請求項１に記載の呼制御装置。
【請求項３】
上記書き込み処理手段が、さらに当該呼制御装置のＣＰＵ使用率が閾値以下である場合に、その更新された上記呼制御アプリケーション及び又は上記呼制御情報の上記不揮発性メモリへの書き込みを行うことを特徴とする請求項２に記載の呼制御装置。
【請求項４】
上記書き込み処理手段は、更新された上記呼制御アプリケーション及び又は上記呼制御情報を用いた呼制御処理が成功した後に、その更新された上記呼制御アプリケーション及び又は上記呼制御情報の上記不揮発性メモリへの書き込みを行うことを特徴とする請求項１〜３のいずれかに記載の呼制御装置。
【請求項５】
上記書き込み処理手段は、更新された上記呼制御アプリケーション及び又は上記呼制御情報を用いた呼制御処理が失敗した場合、更新前の上記呼制御アプリケーション及び又は上記呼制御情報を復旧させ、これを用いて再開させることを特徴とする請求項４に記載の呼制御装置。
【請求項６】
上記書き込み処理手段が、更新された上記呼制御アプリケーション及び又は上記呼制御情報の上記不揮発性メモリへの書き込み後、直ちに再起動を行う請求項１〜５のいずれかに記載の呼制御装置。
【請求項７】
上記書き込み処理手段が、上記不揮発性メモリに書き込みを行う前に、更新された上記呼制御アプリケーション又は上記呼制御情報の容量と、上記不揮発性メモリ上の空き領域の容量とを比較して保存領域の容量以下の場合に、上記不揮発性メモリへの書き込みを許容することを特徴とする請求項１〜６のいずれかに記載の呼制御装置。
【請求項８】
上記書き込み処理手段が、更新された上記呼制御アプリケーションと上記呼制御情報との双方を上記不揮発性メモリに書き込みを行う前に、更新された上記呼制御アプリケーションの容量と空き領域の容量との比較、及び、更新された上記呼制御情報の容量と空き領域の容量との比較により、上記不揮発性メモリへの書き込みをするか否かを判断することを特徴とする請求項１〜７のいずれかに記載の呼制御装置。
【請求項９】
上記書き込み処理手段が、更新された上記呼制御アプリケーション又は上記呼制御情報のいずれかの容量が空き領域の容量以下であっても、更新された上記呼制御情報又は上記呼制御アプリケーションが空き領域を超越している場合、上記不揮発性メモリへの書き込みを抑制することを特徴とする請求項８に記載の呼制御装置。
【請求項１０】
揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を上記揮発性メモリにローディングして呼処理を行い、上記不揮発性メモリに対する書き込み情報を上記ＲＡＭディスク領域に格納する呼制御装置の呼制御方法において、
更新検知処理手段が、上記ＲＡＭディスク領域の書き込み情報から、呼処理により上記揮発性メモリにローディングされた上記呼制御アプリケーション及び又は上記呼制御情報を格納する上記不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理工程と、
書き込み処理手段が、上記更新検知処理手段の検知に基づいて上記ＲＡＭディスク領域の書き込み情報のうち上記呼制御アプリケーション及び又は上記呼制御情報の領域に対する書き込み情報の上記不揮発性メモリへの書き込みを行う書き込み処理工程と
を有することを特徴とする呼制御方法。
【請求項１１】
揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を上記揮発性メモリにローディングして呼処理を行い、上記不揮発性メモリに対する書き込み情報を上記ＲＡＭディスク領域に格納する呼制御装置を、
上記ＲＡＭディスク領域の書き込み情報から、呼処理により上記揮発性メモリにローディングされた上記呼制御アプリケーション及び又は上記呼制御情報を格納する上記不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理手段、
上記更新検知処理手段の検知に基づいて上記ＲＡＭディスク領域の書き込み情報のうち上記呼制御アプリケーション及び又は上記呼制御情報の領域に対する書き込み情報の上記不揮発性メモリへの書き込みを行う書き込み処理手段
として機能させることを特徴とする呼制御プログラム。
【請求項１】
揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を上記揮発性メモリにローディングして呼処理を行い、上記不揮発性メモリに対する書き込み情報をＲＡＭディスク領域に格納する呼制御装置において、
上記ＲＡＭディスク領域の書き込み情報から、呼処理により上記揮発性メモリにローディングされた上記呼制御アプリケーション及び又は上記呼制御情報を格納する上記不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理手段と、
上記更新検知処理手段の検知に基づいて上記ＲＡＭディスク領域の書き込み情報のうち上記呼制御アプリケーション及び又は上記呼制御情報の領域に対する書き込み情報の不揮発性メモリへの書き込みを行う書き込み処理手段と
を備えることを特徴とする呼制御装置。
【請求項２】
上記書き込み処理手段は、更新された上記呼制御アプリケーション及び又は上記呼制御情報の正常性を確認した後に、その更新された上記呼制御アプリケーション及び又は上記呼制御情報の上記不揮発性メモリへの書き込みを行うことを特徴とする請求項１に記載の呼制御装置。
【請求項３】
上記書き込み処理手段が、さらに当該呼制御装置のＣＰＵ使用率が閾値以下である場合に、その更新された上記呼制御アプリケーション及び又は上記呼制御情報の上記不揮発性メモリへの書き込みを行うことを特徴とする請求項２に記載の呼制御装置。
【請求項４】
上記書き込み処理手段は、更新された上記呼制御アプリケーション及び又は上記呼制御情報を用いた呼制御処理が成功した後に、その更新された上記呼制御アプリケーション及び又は上記呼制御情報の上記不揮発性メモリへの書き込みを行うことを特徴とする請求項１〜３のいずれかに記載の呼制御装置。
【請求項５】
上記書き込み処理手段は、更新された上記呼制御アプリケーション及び又は上記呼制御情報を用いた呼制御処理が失敗した場合、更新前の上記呼制御アプリケーション及び又は上記呼制御情報を復旧させ、これを用いて再開させることを特徴とする請求項４に記載の呼制御装置。
【請求項６】
上記書き込み処理手段が、更新された上記呼制御アプリケーション及び又は上記呼制御情報の上記不揮発性メモリへの書き込み後、直ちに再起動を行う請求項１〜５のいずれかに記載の呼制御装置。
【請求項７】
上記書き込み処理手段が、上記不揮発性メモリに書き込みを行う前に、更新された上記呼制御アプリケーション又は上記呼制御情報の容量と、上記不揮発性メモリ上の空き領域の容量とを比較して保存領域の容量以下の場合に、上記不揮発性メモリへの書き込みを許容することを特徴とする請求項１〜６のいずれかに記載の呼制御装置。
【請求項８】
上記書き込み処理手段が、更新された上記呼制御アプリケーションと上記呼制御情報との双方を上記不揮発性メモリに書き込みを行う前に、更新された上記呼制御アプリケーションの容量と空き領域の容量との比較、及び、更新された上記呼制御情報の容量と空き領域の容量との比較により、上記不揮発性メモリへの書き込みをするか否かを判断することを特徴とする請求項１〜７のいずれかに記載の呼制御装置。
【請求項９】
上記書き込み処理手段が、更新された上記呼制御アプリケーション又は上記呼制御情報のいずれかの容量が空き領域の容量以下であっても、更新された上記呼制御情報又は上記呼制御アプリケーションが空き領域を超越している場合、上記不揮発性メモリへの書き込みを抑制することを特徴とする請求項８に記載の呼制御装置。
【請求項１０】
揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を上記揮発性メモリにローディングして呼処理を行い、上記不揮発性メモリに対する書き込み情報を上記ＲＡＭディスク領域に格納する呼制御装置の呼制御方法において、
更新検知処理手段が、上記ＲＡＭディスク領域の書き込み情報から、呼処理により上記揮発性メモリにローディングされた上記呼制御アプリケーション及び又は上記呼制御情報を格納する上記不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理工程と、
書き込み処理手段が、上記更新検知処理手段の検知に基づいて上記ＲＡＭディスク領域の書き込み情報のうち上記呼制御アプリケーション及び又は上記呼制御情報の領域に対する書き込み情報の上記不揮発性メモリへの書き込みを行う書き込み処理工程と
を有することを特徴とする呼制御方法。
【請求項１１】
揮発性メモリ上にＲＡＭディスク領域部を生成しておき、不揮発性メモリに格納される呼制御アプリケーション及び呼制御情報を上記揮発性メモリにローディングして呼処理を行い、上記不揮発性メモリに対する書き込み情報を上記ＲＡＭディスク領域に格納する呼制御装置を、
上記ＲＡＭディスク領域の書き込み情報から、呼処理により上記揮発性メモリにローディングされた上記呼制御アプリケーション及び又は上記呼制御情報を格納する上記不揮発性メモリの領域に対する書き込み情報を検知する更新検知処理手段、
上記更新検知処理手段の検知に基づいて上記ＲＡＭディスク領域の書き込み情報のうち上記呼制御アプリケーション及び又は上記呼制御情報の領域に対する書き込み情報の上記不揮発性メモリへの書き込みを行う書き込み処理手段
として機能させることを特徴とする呼制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１０−２１２９９０（Ｐ２０１０−２１２９９０Ａ）
【公開日】平成２２年９月２４日（２０１０．９．２４）
【国際特許分類】
【出願番号】特願２００９−５６８９５（Ｐ２００９−５６８９５）
【出願日】平成２１年３月１０日（２００９．３．１０）
【出願人】（３０８０３３７２２）株式会社ＯＫＩネットワークス (165)
【Ｆターム（参考）】
【公開日】平成２２年９月２４日（２０１０．９．２４）
【国際特許分類】
【出願日】平成２１年３月１０日（２００９．３．１０）
【出願人】（３０８０３３７２２）株式会社ＯＫＩネットワークス (165)
【Ｆターム（参考）】
[ Back to top ]