(57)【特許請求の範囲】
【請求項１】
オペレーティング・システムの制御の下で少なくとも１つのアプリケーション・プログラムを実行する情報処理装置であって、前記情報処理装置は、
前記オペレーティング・システムのシステム・コマンドが発行したメッセージを、聴取またはスキャンすることにより前記メッセージの本来の宛先への通信を維持させながら取得し、前記メッセージが発行されるごとに発行元およびメッセージの内容をキュー・リストに登録するメッセージ監視部と、
前記オペレーティング・システムが発行した前記メッセージの発行元を識別する発行元識別値と、前記発行元のメッセージを要求するアプリケーション・プログラムの宛先として使用される送信元識別値とを格納するエントリ・テーブルを含む記憶部と、
前記メッセージ監視部から前記発行元識別値を受け取って前記記憶部の前記エントリ・テーブルを検索し、システム・コマンドのメッセージを待機する前記アプリケーション・プログラムが検索された場合、当該アプリケーション・プログラムの送信元識別値を宛先として設定し、OSプロセス識別値と、メッセージと、前記メッセージに対応するため前記アプリケーション・プログラムが実行可能なコードを対応づけた変換テーブルを使用して前記メッセージに対応する前記コードを取得するエントリ制御部と
を含む、情報処理装置。
【請求項２】
前記メッセージ監視部は、前記エントリ制御部による前記アプリケーション・プログラムの検索結果に応答して、前記メッセージを前記キュー・リストから削除する、請求項１に記載の情報処理装置。
【請求項３】
前記記憶部は、少なくとも前記発行元識別値および前記アプリケーション・プログラムの宛先を暗号化して格納し、前記エントリ制御部は、前記暗号化された前記発行元識別値および前記送信元識別値を復号して前記アプリケーション・プログラムの宛先を取得する、請求項１または２に記載の情報処理装置。
【請求項４】
前記情報処理装置は、エントリ制御部が取得した前記宛先に宛てて前記実行可能なコードを通信するプロセス通信処理部を含む、請求項１〜３のいずれか１項に記載の情報処理装置。
【請求項５】
前記記憶部の検索において、前記発行元識別値は、ウェルノウン・ポート番号または実行ファイル名で指定され、前記宛先は、レジスタード・ポート番号、ダイナミック・プライベート・ポート番号から選択されるか、または前記エントリ・テーブルにプロセス側名称とアプリケーション側名称とを対応付けるリストを格納して前記発行元識別値と、前記アプリケーション・プログラムとの対応付けを行う、請求項１〜４のいずれか１項に記載の情報処理装置。
【請求項６】
オペレーティング・システムの下で少なくとも１つのアプリケーション・プログラムを実行させる情報処理装置におけるメッセージ管理方法であって、前記メッセージ管理方法は、前記情報処理装置が、
メッセージ監視部が前記オペレーティング・システムのシステム・コマンドが発行したメッセージを、聴取またはスキャンすることにより前記メッセージの本来の宛先への通信を維持させながら取得し、前記メッセージが発行されるごとに発行元およびメッセージの内容をキュー・リストに登録するステップと、
エントリ制御部が前記オペレーティング・システムが発行した前記メッセージの発行元を識別する発行元識別値と、前記発行元のメッセージを要求するアプリケーション・プログラムの宛先として使用される送信元識別値とを格納するエントリ・テーブルを更新するステップと、
前記エントリ制御部が前記メッセージ監視部から前記発行元識別値を受け取って記憶部の前記エントリ・テーブルを検索し、システム・コマンドのメッセージを待機する前記アプリケーション・プログラムが検索された場合、当該アプリケーション・プログラムの送信元識別値を宛先として設定し、OSプロセス識別値と、メッセージと、前記メッセージに対応するため前記アプリケーション・プログラムが実行可能なコードを対応づけた変換テーブルを使用して前記メッセージに対応する前記コードを取得するステップと
を前記情報処理装置に実行させる、メッセージ管理方法。
【請求項７】
前記メッセージ管理方法は、前記情報処理装置に対して、前記エントリ・テーブルの検索結果に応答して、保持された前記メッセージを先入れ・先出し処理により削除するステップを実行させる、請求項６に記載のメッセージ管理方法。
【請求項８】
前記メッセージ管理方法は、前記情報処理装置に対して、少なくとも前記発行元識別値および前記アプリケーション・プログラムの宛先を暗号化して格納するステップと、
前記エントリ・テーブルの検索ステップの前に前記暗号化された前記発行元識別値およびアプリケーション・プログラムの宛先を復号するステップと
を実行させる、請求項６または７に記載のメッセージ管理方法。
【請求項９】
請求項６〜８のいずれか１項に記載のメッセージ管理方法を情報処理装置に対して実行させる装置実行可能なプログラム。
【請求項１０】
請求項９に記載のプログラムを格納した装置可読な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置におけるメッセージ管理に関し、より詳細には、オペレーション・システムによるメッセージを複数のアプリケーション・プログラムに対して使用させることにより、アプリケーション・プログラムとオペレーション・システムとの間の効率的な通信を可能とする情報処理装置、メッセージ管理方法、プログラムおよび記憶媒体に関する。
【背景技術】
【０００２】
近年の情報処理装置は、複数のアプリケーション・プログラムがインストールされ、オペレーション・システム（以下、OSとして参照する。）の管理下で、各アプリケーション・プログラム（以下、単にアプリとして参照する。）がメモリ、ハードディスク、入出力端末、ディスプレイ装置などを共有している。また、情報処理装置は、所定のアプリが単独で、または、複数の同一のアプリまたは異なるアプリが同時に実行される、マルチタスクまたはマルチジョブ環境とされている。
【０００３】
上述した情報処理装置の処理パフォーマンス向上、およびプログラミング言語の発展に伴って、パーソナル・コンピュータといった情報処理装置であっても、OSとアプリとの間が、プロセス間通信により通信され、アプリ間でのデータ共有および同期などの実行制御が行われるようになってきている。通常、OSによるプロセス間通信は、プロセスに固有のプロセス識別値（PID）を所定のプロセスが開始される時点で割当て、プロセスが消滅するまでPIDを保存することにより行われている。多くの場合、OS管理下でOSが発行するメッセージは、ソケット通信などを使用し、所定のポートを宛先として送信され、OS上で、またはリモート装置上で動作する他のアプリが受信することができる。
【０００４】
しかしながら、個々のアプリ特有のメッセージに関しては、個々のアプリの内部でしか処理できず、またOS側は、特定のアプリからの要求に対応してプロセス間通信に対応するOSメッセージを、要求元のアプリに対して送信することは可能ではある。このとき、要求元のアプリが、OSからのメッセージを直接解釈し実行できる場合には、受け取ったOSからのメッセージを実行可能コードに直接コンバートして処理を行うことができる。この場合にでも、アプリの提供元は、個々のアプリのモジュールとしてコンバート処理を行うオブジェクトを追加する作業が必要とされ、OSの対応するメッセージが変更されるごとに個々のアプリのAPIなどを修正しなければならないという労力が発生する。
【０００５】
一方では、当該OSメッセージを要求している他のアプリがあった場合でも、OSメッセージの宛先が異なるため、宛先アプリ以外のアプリは、プロセス間通信により送られるTCP/IPパケットまたはUDP/IPパケットを受け取ることができない。この結果、当該OSメッセージを受け取ることができれば効率的に処理を実行することができるアプリであっても、アプリ側でOSメッセージを改めて要求しない限り、当該アプリには、OSメッセージが配布されない。
【０００６】
この結果、OSメッセージの直接的な宛先とされるアプリであっても、アプリの実行タイミングによっては、OSに対する問い合わせを繰り返し行い、また問い合わせに対する応答を待ち続けることになり、必ずしも効率的な処理とはいえない。また、アプリによっては、直接的にOSに問い合わせを行うのではなく、特定のアプリに対して問い合わせを行うことしかできない場合もある。このような場合、特定のアプリだけはOSからのメッセージを受け取って対応する処理を行うことが可能である。しかしながら、特定のアプリがユーティリティ・ソフトウェア、データベース・ソフトウェア、または文書管理ソフトウェアなどに対して対応する通知を実行・解釈可能なコードとして発行することは保証されてはいない。したがって、ユーティリティ・ソフトウェアなどのアプリのユーザは、情報処理装置のハングアップなどの現象と区別ができず、それまで作成したデータを破棄して情報処理装置の再起動を行わざるを得ないことが生じる。
【０００７】
上述した状況は、近年、オブジェクト指向プログラミング技術の進歩に伴い、複数のアプリがそれぞれのスコープの下でデータを処理し、その結果を格納する処理を実行する情報処理装置では、頻繁に発生するようになる。このため、複数のアプリが共有メモリを使用して実行される場合や、共有ハードウェア資源を介して処理を行うことが多く、OSからのメッセージをより有効に利用することが好ましい。
【０００８】
また、上述した問題点に対処するために、ミドルウェアやユーティリティ・ツールを提供するアプリごとにAPIを形成させることでも対応することが可能である。しかしながら、パーソナル・コンピュータなど、ユーザの指向に応答して不特定のアプリがインストールされる可能性がある状況では、当該不特定多数のアプリに対応して、それらの間のプロセス間通信を調停することは、多くの場合不可能であるといってよい。
【０００９】
情報処理において複数のプロセスを調停させる方法として、例えば、特開平８−６３３５４号公報（特許文献１）には、２つのメモリ保存領域へのアクセスを制御するために、それぞれに対応するインタフェースを設け、プロセッサによる命令フェッチやデータアクセス要求に際して、使用するインタフェースを選択することで、プロセス間を調停する情報処理装置が開示されている。特許文献１に記載された技術は、マイクロプロセッサからの要求を判断して、２つのメモリ保存領域にプロセッサからの要求を割り当てる２つのインタフェースを提供することで、プロセス間の調停を行っている。この場合、プロセッサとそのプロセッサに対する命令フェッチを制御するという限定された環境であれば、上述したように、アプリ・レベルで各アプリにそれぞれ対応するAPIを形成させることも、可能であるということができる。
【００１０】
しかしながら、複数のアプリに対応する固有の命令を含むAPIをアプリごとに形成させるのでは、アプリの開発側の労力が増加し、また情報処理装置における記憶領域に占めるAPIの割合が重くなり、効率的なものということはできない。また、ユーザにより新たなアプリが任意的に追加される環境では、各アプリに対してOSからのメッセージを受け取って処理を実行する機能をそれぞれについて追加することは、アプリの作成の手間を増加させることにもなり、またアプリによって対応処理が異なるのでは、ユーザも混乱することになる。
【００１１】
また、特開平５−２３３３３５号公報（特許文献２）では、複数のプロセスから複数の資源をアクセスする方式であって、各プロセスに対して使用する資源を自動的に割り当てる方式が開示されている。特許文献２では、資源獲得調停手段を使用し、各プロセスの資源に対応するアクセス権と占有権とを割り当てるようにして、FIFO方式でプロセスごとに資源を占有させている。
【００１２】
特許文献２に開示された方式によれば、アクセス権の先取り順にプロセスに対して資源を利用させることは可能となる。しかしながら、プロセスがアプリである場合に、アプリの情報処理装置内でのステータスに関連し、かつユーザ要求に応答した処理を可能としない場合には、ユーザは、アプリが待機しているのか、またハングアップしているのかがわからないことになる。この結果、ユーザが情報処理装置に対して他の処理を行うために、ユーザがリセット処理を実行することになると、それまでにユーザが作成した付加価値の高いデータを無駄にしてしまうことになる。
【特許文献１】特開平８−６３３５４号公報
【特許文献２】特開平５−２３３３３５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
上述したように、種々の調停・管理方法が開示されているものの、調停の結果に応答し、アプリ側で解釈できるコマンドにOSメッセージをコンバートして、OSメッセージに対応する動作をアプリに対して実行させる方法については知られていない。また、アプリ側からの要求があった場合に、過去にOSが発行したOSメッセージを当該アプリ側に識別させ、使用可能とするメッセージ管理ができれば、OSと各アプリとの間のメッセージの共有化を行うことができ、より効率的にプロセス間通信を行うことが期待できる。
【００１４】
また、アプリ開発側およびユーザデータの保護の点からも、すでに発行されたOSからのメッセージを有効利用することが好ましい。
【課題を解決するための手段】
【００１５】
本発明は、プロセス間通信が主として設定されたポート間だけで行われることに着目し、宛先とされたプロセスだけではなく、同時に処理を行っているアプリやプロセスについても、すでに発行されたOSメッセージを有効に利用することができれば、よりプロセス間通信の効率および利用性を高めることができる、という着想の下になされたものである。
【００１６】
すなわち、本発明では、OS自体またはOSのシステム・コマンドにより発行されたメッセージを、宛先に拘わらず、かつ本来の宛先へのプロセス間通信を妨げることなく聴取またはスキャンして、キュー・リストに格納するメッセージ・ハンドラを形成する。キュー・リストに格納されたOSメッセージは、アプリが当該OSメッセージを要求しているか否かに応答してエントリ制御部においてアプリケーション側で実行可能なコードへと変換される。
【００１７】
変換されたアプリ側の実行可能なコードは、アプリへと送られて、アプリ側の処理のために使用され、またOSメッセージはメッセージ・ハンドラにより処理において、実行可能なコードへの変換の必要性または変換処理の終了に応答して、先入れ・先出し的に削除され、常にアプリケーション側の必要とするOSメッセージが最小限に格納された状態とされている。このため、本発明では、OSが過去に発行したメッセージを、当該メッセージを要求したプロセス以外のプロセスに対して共有させることができる。
【００１８】
すなわち、本発明によれば、
オペレーティング・システムの制御の下で少なくとも１つのアプリケーション・プログラムを実行する情報処理装置であって、前記情報処理装置は、
前記オペレーティング・システムのシステム・コマンドが発行したメッセージを、聴取またはスキャンすることにより前記メッセージの本来の宛先への通信を維持させながら取得し、前記メッセージが発行されるごとに発行元およびメッセージの内容をキュー・リストに登録するメッセージ監視部と、
前記オペレーティング・システムが発行した前記メッセージの発行元を識別する発行元識別値と、前記発行元のメッセージを要求するアプリケーション・プログラムの宛先として使用される送信元識別値とを格納するエントリ・テーブルを含む記憶部と、
前記メッセージ監視部から前記発行元識別値を受け取って前記記憶部の前記エントリ・テーブルを検索し、システム・コマンドのメッセージを待機する前記アプリケーション・プログラムが検索された場合、当該アプリケーション・プログラムの送信元識別値を宛先として設定し、OSプロセス識別値と、メッセージと、前記メッセージに対応するため前記アプリケーション・プログラムが実行可能なコードを対応づけた変換テーブルを使用して前記メッセージに対応する前記コードを取得するエントリ制御部と
を含む、情報処理装置が提供される。
【００１９】
本発明の前記メッセージ監視部は、前記エントリ制御部による前記アプリケーション・プログラムの検索結果に応答して、前記メッセージを前記キュー・リストから削除することができる。
【００２０】
本発明の前記記憶部は、少なくとも前記発行元識別値および前記アプリケーション・プログラムの宛先を暗号化して格納し、前記エントリ制御部は、前記暗号化された前記発行元識別値および前記送信元識別値を復号して前記アプリケーション・プログラムの宛先を取得することができる。
【００２１】
本発明では、前記記憶部の検索において、前記発行元識別値は、ウェルノウン・ポート番号または実行ファイル名で指定され、前記宛先は、レジスタード・ポート番号、ダイナミック・プライベート・ポート番号から選択されるか、または前記エントリ・テーブルにプロセス側名称とアプリケーション側名称とを対応付けるリストを格納して前記発行元識別値と、前記アプリケーション・プログラムとの対応付けを行うことができる。本発明の前記メッセージ監視部は、前記システム・コマンドが発行した前記メッセージの宛先への通信を妨げることなく聴取またはスキャンすることができる。
【００２２】
本発明の第２の構成によれば、オペレーティング・システムの下で少なくとも１つのアプリケーション・プログラムを実行させる情報処理装置におけるメッセージ管理方法であって、前記メッセージ管理方法は、前記情報処理装置が、
メッセージ監視部が前記オペレーティング・システムのシステム・コマンドが発行したメッセージを、聴取またはスキャンすることにより前記メッセージの本来の宛先への通信を維持させながら取得し、前記メッセージが発行されるごとに発行元およびメッセージの内容をキュー・リストに登録するステップと、
エントリ制御部が前記オペレーティング・システムが発行した前記メッセージの発行元を識別する発行元識別値と、前記発行元のメッセージを要求するアプリケーション・プログラムの宛先として使用される送信元識別値とを格納するエントリ・テーブルを更新するステップと、
前記エントリ制御部が前記メッセージ監視部から前記発行元識別値を受け取って記憶部の前記エントリ・テーブルを検索し、システム・コマンドのメッセージを待機する前記アプリケーション・プログラムが検索された場合、当該アプリケーション・プログラムの送信元識別値を宛先として設定し、OSプロセス識別値と、メッセージと、前記メッセージに対応するため前記アプリケーション・プログラムが実行可能なコードを対応づけた変換テーブルを使用して前記メッセージに対応する前記コードを取得するステップと
を前記情報処理装置に実行させる、メッセージ管理方法が提供される。
【００２３】
本発明の前記メッセージ管理方法は、前記情報処理装置に対して、前記エントリ・テーブルの検索結果に応答して、保持された前記メッセージを先入れ・先出し処理により削除するステップを実行させることができる。
【００２４】
本発明の前記メッセージ管理方法は、前記情報処理装置に対して、少なくとも前記発行元識別値および前記アプリケーション・プログラムの宛先を暗号化して格納するステップと、前記エントリ・テーブルの検索ステップの前に前記暗号化された前記発行元識別値およびアプリケーション・プログラムの宛先を復号するステップとを含むことができる。
【００２５】
本発明の第３の構成によれば、上記記載のメッセージ管理方法を情報処理装置に対して実行させる装置実行可能なプログラムを提供することができる。
【００２６】
本発明の第４の構成によれば、上記プログラムを格納した装置可読な記憶媒体が提供できる。
【発明の効果】
【００２９】
本発明によれば、任意にインストールまたはアンインストールされ、また独立して起動・終了するアプリの間において、OSメッセージを共有させることができれば、見かけ上のハングアップなどによるデータの損失などを防止することができ、アプリの利用性を高めると共に、データ作成効率を向上させることができる。
【００３０】
また、本発明によれば、不特定多数のアプリが使用される情報処理装置であっても、個別的にAPIを形成させること無く、変換のためのコンバートデータだけを変更するだけで複数のアプリについてOSメッセージを共有させることができ、効率的なアプリ利用を行うことができる。
【００３１】
さらに、本発明によれば、よりプロセス間通信の効率を高め、プロセス間通信の拡張性を向上させ、さらに、異なるアプリケーション間での共通のＩ／Ｆを介した処理を無駄なく実行することができる。
【００３２】
さらに、本発明によれば、不特定多数のアプリに対応するためにAPIを形成するのではなく、変換テーブルに対応する実行可能コードのエントリを追加するだけで済み、プログラミングにおける作業量を低減させることができ、アプリ開発側において、容易にプログラムの追加に対応することが可能となる。
【発明を実施するための最良の形態】
【００３３】
以下、本発明を図面に示した特定の実施の形態をもって説明するが、本発明は、後述する実施の形態に限定されるものではない。
【００３４】
図１は、本発明の情報処理装置１０の構成を示した概略図である。図１に示す情報処理装置１０は、MPU１２と、RAM１４と、ROM１４を含んでいて、オペレーティング・システムの制御下で、少なくとも１つのアプリを実行させている。MPU１２は、例えば、PENTIUM（登録商標）ファミリ、６４ビット・アーキテクチャのXEON（登録商標）、POWERPC（登録商標）などのCISCまたはRISCアーキテクチャの下で、Windows（登録商標）、Windows（登録商標）2000、Windows（登録商標）2000 Professional、Windows（登録商標）XP、Windows（登録商標）XP SP2、Windows（登録商標）XP Professional、Windows（登録商標）200X Server、Windows （登録商標）CEなどのオペレーティング・システム（OS）を実行している。
【００３５】
MPU１２は、オブジェクト指向プログラミングの実行を可能とする資源を使用して、例えば、C++、Java（登録商標）、Java（登録商標）Beans、Java（登録商標）Applet、Java（登録商標）Script、Perlなどのオブジェクト指向プログラムが実行可能とされている。OSは、種々のシステム・コールまたはシステム・コマンドを使用して、オブジェクト指向プログラムのプロセスを調停しており、同時にハードウェア資源の共有化およびデータの共有化を可能としている。
【００３６】
RAM１４は、MPU１２によるオブジェクト指向プログラムの実行に伴って生成されるインスタンスを提供する実行空間を提供しており、MPU１２による処理を可能としている。さらに、ROM１４は、BIOS(Basic Input Output System）などのマイクロ・コードやデータなどを格納していて、情報処理装置１０の起動に際してOSの起動に先立って、情報処理装置の検査を行い、また起動後の入出力装置の管理を実行する。
【００３７】
情報処理装置１０には、USBやIEEE1284などのシリアルまたはパラレル・バスを介してキーボード、マウス、またはプリンタなどの入出力装置１６に接続されており、適切なインタフェース１８を介してMPU１２へとユーザ入力を渡している。また、情報処理装置１０には、ATA、シリアルATA、ウルトラATA、ATAPIなどの規格のIDE、またはSCSI、SCSI-2、SCSI-3といったインタフェース２０を介して、記憶装置２２が接続されている。記憶装置２２は、ハードディスク装置または半導体メモリ装置などから選択することができ、情報処理装置１０に内蔵されていてもよく、またカード型ハードディスクや、随時読み書き可能な半導体メモリとされていてもよい。
【００３８】
MPU１２は、ユーザからの指令に基づき、実行形式のプログラムを読み出して実行し、その実行結果を、内部バス２４を介してRAM１４や記憶装置２２へと書き込みを行い、また記憶装置２２に格納されたデータを取得して処理に使用している。図１に示した情報処理装置１０は、内部バス２４を介してVRAM２６およびグラフィック・チップ２８と通信し、処理の結果などを適切なGUI(Graphical User Interface)を介してユーザに提供している。情報処理装置１０は、内部バス２４を介してイーサネット（登録商標）などのネットワーク・インタフェース３２と通信して、LAN(Local Area Network)、WAN(Wide Area Network)またはインターネットといったネットワーク３４と接続されて、Webサーバなどとの通信を可能としている。
【００３９】
図２は、本発明における情報処理装置１０のソフトウェア構成を示した図である。図２（ａ）は、複数のアプリがOSとプロセス間通信により通信を行って、処理しているのが示されている。図２（ａ）に示した形態では、アプリ４４ａは、OS４２と直接通信しており、プロセス間通信によるトランザクションが確立されていて、例えば、BIOSまたはデバイス・ドライバにより管理される記憶装置、通信装置などとの通信結果、または、OSにおける処理結果の送受信を行っている。また、アプリ４４ｂ、４４ｃについてもOS４２との間でプロセス通信を行っている。
【００４０】
図２（ａ）に示した特定の形態では、アプリ４４ｂ、４４ｃは、例えばワープロソフトウェア、または表計算ソフトウェア、またはデータベースなどとプロセス間通信を行うことは可能であるものの、直接OSとの間のプロセス間通信が可能とされていない。また、別の形態では、アプリ４４ｂ、４４ｃは、さらに別のアプリとの間でのプロセス間通信を確立させているものの、OSに対してプロセス間通信を行っていない状態とされている。このような場合、OSがアプリ４４ａに宛ててディスパッチしたOSメッセージ（以下、osmとして参照する。）は、アプリ４４ｂおよびアプリ４４ｃには宛てられていないため、アプリ４４ｂおよびアプリ４４ｃを素通りしてしまうことになる。
【００４１】
このとき、アプリ４４ａに送られたosmが、例えば、（１）ネットワークＩ／Ｆが使用できないこと、（２）着脱自在の外部記憶装置が使用できないこと、その他、（３）アプリ４４ａだけではなく、アプリ４４ｂ、４４ｃが共用するハードウェア資源またはプロセスへとアクセスするための特定プロセスが生成されていないこと、または異常があることなど、重大な問題を示す場合であっても、アプリ４４ａだけは、その結果を受け取ることができる。しかし、アプリ４４ｂ、４４ｃは、アプリ４４ａへと通知されたosmを受け取ることができないので、通知を受けないのでアプリ４４ｂ、４４ｃがその時点以後に対応するOSプロセスまたはデバイスを要求した場合、アプリ４４ｂ、４４ｃは、要求するプロセスに対応するosmの受信を待つことになる。
【００４２】
この間、タイムアウトを設定して、アプリ４４ｂ、４４ｃの実行を制御することも想定できる。しかしながら、タイムアウトの経過を待つ間ユーザは、情報処理装置１０のハングアップなのか、タイムアウト経過を待機しているだけなのかはわからず、ユーザによっては、情報処理装置をリセットする可能性もある。また、OS側に繰り返し問い合わせを行い、対応するosmを取得することでも対応することができるが、OSへの割込が頻繁に行われることになり、またすべてのアプリが当該処理を実行することができるわけではない。このとき、すでに対応するosmが発行されている場合には、当該osmを一旦管理しておき、アプリ４４ｂ、４４ｃに利用させることで、アプリ４４ｂ、４４ｃの処理効率を向上させることができる。
【００４３】
図２（ｂ）は、本発明のソフトウェア構成を示す。本発明では、アプリ４４ｂ、４４ｃとOS４２との間にメッセージ・ハンドラ４６をアプリ４４ｂ、４４ｃとOSの間に形成させる。メッセージ・ハンドラ４６は、アプリ４４ａに宛てて発行されたosmを妨げることなく、OSのプロセス間通信をモニタして、osm自体またはシステム・コマンドに対応して発行されたメッセージを格納させるか、またはリストとして蓄積する。一方、メッセージ・ハンドラ４６は、その時点でosmに関連した処理を実行する可能性のあるアプリ、またはすでにOSによる処理を依頼したアプリのリストを管理している。メッセージ・ハンドラ４６は、リストに登録されたosmに関連するアプリがメッセージ・ハンドラ４６が管理するエントリ・テーブルに登録されているか否かを検索する。
【００４４】
検索の結果、登録されている場合にはosmの内容に関連するアプリの理解可能なメッセージ（以下applmとして参照する。）を、osmからコンバートして生成する。その後、エントリ・テーブルに格納されたポート番号またはアプリ名称などのアプリ識別値を取得して各アプリに対して、適切な優先順位、例えば、アプリの先着順にapplmをプロセス間通信により伝送する。この結果、アプリ４４ｂ、４４ｃは、アプリの処理できるフォーマットとしてapplmを受信する。このため、各アプリ４４ｂ、４４ｃは、直接OSと通信せずとも、osmに対応するアプリ側の処理を実行し、例えば、ユーザに対してアプリの状態を通知する、またはアプリの状態に対応した処理、例えばデータのバックアップ処理などを行なうことができる。
【００４５】
図３は、本発明のメッセージ・ハンドラ４６の機能ブロック図である。本発明のメッセージ・ハンドラ４６は、メッセージ監視部４８と、エントリ制御部５０と、配布先・メッセージ格納部５２とから構成されている。メッセージ監視部４８は、OSの通信状態を、本来の宛先への通信を妨げることなく聴取またはスキャンするオブジェクトを含む構成とされる。図３に示した実施の形態では、OS４２は発行したosmは、本来の宛先および本発明のメッセージ・ハンドラ４６へと送られるか、またはメッセージ・ハンドラ４６が本来の宛先とされるように、メッセージ・ハンドラ４６がアクティブにosmを生成させる。
【００４６】
本発明でメッセージ監視部を構成するためのオブジェクトは、種々あり得るが、具体的には、例えば、本発明のメッセージ・ハンドラ４６をパッシブ駆動する場合には、メッセージ・ハンドラ４６に対してプロミスキャス・モードでのソケットを形成し、すべてのプロセス間通信を、プロセス間通信が伝送されることに応答して傍受させるオブジェクトとすることができる。このようなオブジェクトは、例えば、RAWソケットを使用するオブジェクトとして作成することができ、メッセージ監視部４８が機能している期間中、closeさせないコードとして実装させることができる。
【００４７】
また、本発明の他の実施の形態では、特定のosmをシステム・コマンドの返り値として生成することができる。この場合、osmは、OSのプロセス間通信により直接発生されるものではないが、プロセス間通信の状態を示すOSからのメッセージを発生させるシステム・コマンドを使用して、メッセージ・ハンドラ４６がアクティブにOSのメッセージ伝送状態に関連するメッセージを生成することができる。このためのシステム・コマンドとしては例えば、プロセス間通信の状態を検出するシステム・コマンドである、netstat-x(-xは、オプションであり、-aは、TCPおよびUDPのプロトコルで通信を行うプロセス間通信をモニタするオプションである。）を挙げることができる。本発明のメッセージ・ハンドラ４６の第２の実施の形態では、本発明のメッセージ監視部は、netstatコマンドを含むオブジェクトとして生成し、OS側に割り当てられているウェルノウン・ポートに関連する状態を回収することによっても作成することができる。なお、netstat-Xコマンドにより生成されるメッセージは、メッセージ・ハンドラを直接的な宛先として生成されるので、パッシブ・モードでosmを傍受する場合と同様、プロセス間通信の本来の宛先に対する通信を妨げることはない。
【００４８】
なお、-xの値としては、−ａ、−ｂ、−ｅ、−ｎ、−ｐ、−ｒ、−ｓ、−ｏ、−ｖなどがあり、−ａオプションを使用することにより、その時点で待機中のプロセスをosmとしてOSから返させることができる。また、メッセージ監視部におけるメッセージ監視オブジェクトに対して、定期的にメッセージをモニタさせる場合には、例えば、「netstat-a 1」のコードを記述しておくことにより、メッセージ監視部の起動後、１秒ごとに定期的にプロセス通信の状態を返す処理を実現することができる。なお、本発明において、定期的なメッセージのモニタのための時間間隔は、適宜設定することができる。
【００４９】
上述した構成のメッセージ監視部を使用することにより、プロセス間通信の状態をプロセスが発行したosmの宛先に関係なくモニタすることが可能となる。本発明では、メッセージ監視部４８は、OSが発行したosmを回収するか、またはプロセス間通信の状態をモニタする場合には、netstat-xの返り値を、先入れ・先出しリストを定義するqueue ()に登録することによって、キュー・リストを作成して、RAMなどの適切な格納領域に格納する。
【００５０】
配布先・メッセージ格納部５２は、その時点で少なくともosmを要求しているか、または他の実施の形態では、要求する可能性のあるアプリを格納したエントリ・テーブルを含む記憶部として構成されている。エントリ制御部５０は、キュー・リストに格納されているosmに対応するアプリを配布先・メッセージ格納部５２対して問い合わせ、osmを待機している、または要求する可能性のあるアプリを検索する。エントリ制御部５０は、検索されたアプリの宛先を取得し、またosmに対応するアプリ側の実行可能なコードapplmを、変換テーブルをルックアップして取得する。その後、エントリ制御部５０は、取得したアプリの宛先と実行可能なコードapplmとを引数として含むメッセージを、メッセージ監視部４８へと通知する。
【００５１】
本発明の特定の実施の形態では、通知を受け取ったメッセージ監視部４８は、通知された宛先およびapplmを、例えばsocket ()コマンドまたはこれに互換性のある指令、たとえばwinsockまたはwinsock2を使用してパケットとしてカプセル化する。メッセージ監視部４８は、カプセル化されたパケットは、TCP/IPまたはUDP/IPプロトコルを使用したプロセス間通信により、Appl-B、Appl-C、Appl-Dなど、エントリ制御部５０が検索した結果osmを必要とするか、または必要とする可能性があると判断したアプリ４４ｂ〜４４ｄへと通知する。なお、本発明では、上述した検索機能および変換機能は、必ずしもエントリ制御部５０に構成される必要はなく、メッセージ監視部４８や、配布先・メッセージ格納部５２の機能として実装することができる。
【００５２】
図４は、本発明のメッセージ・ハンドラを構成するメッセージ監視部の処理を示すフローチャートである。本発明のメッセージ・ハンドラは、本発明の特定の実施の形態では、システム・メモリに常駐するサービス、またはdaemonソフトウェアとして構成することができ、OSの起動と共に処理を開始することができる。しかしながら、本発明の特定の実施の形態では、OSの起動時から一定のディレイを持たせてメッセージ・ハンドラを起動させることで、起動時直後のプロセス通信の混雑を回避させてもよい。また、本発明の他の実施の形態では、メッセージ監視部は、ユーザによりアイコンクリックなどによる明示的な指令に応答して起動した時点から処理を開始する構成とすることもできる。
【００５３】
図４に従って、本発明のメッセージ監視部の処理を説明すると、ステップ４００で、OSの起動に応答してまたはユーザ指令によりメッセージ・ハンドラが起動されると、ステップ４０１でosmの監視を開始し、osmが発行されるごとに、ステップ４０２でqueue ()にエントリさせ、先入れ・先出し方式でosmを管理する。
【００５４】
ステップ４０２でqueue ()のエントリがnullでなくなると、ステップ４０３の処理を実行して、osm待ちのアプリの検索をエントリ制御部に依頼する。ステップ４０４では、エントリ制御部から、osmを待機しているアプリがあることの通知を受け取るか否かを判断し、通知がない場合（ｎｏ）には、ステップ４０８でosmを破棄してステップ４０１へと処理を戻し、さらに後続するosmを待機する。
【００５５】
ステップ４０４で、osmを待機しているアプリがあることが通知された場合（ｙｅｓ）には、ステップ４０５で通知に含まれるアプリの宛先と、アプリが実行可能なコードとを取得し、通信パケットを、socket ()またはwinsockまたはwinsock2での互換性のあるコマンドを使用して作成する。その後、ステップ４０６では、メッセージ監視部の通信機能を使用して対応するアプリへと実行可能なコードapplmを送付する。通信機能は、本発明に特定の実施の形態としてJava（登録商標）で作成する場合には、ソケット・プログラミング技術を使用するコードとして実装することができる。
【００５６】
本発明のソケット・プログラミングのコードの処理を概略的に説明すると、情報処理装置に対応するIPアドレスなどの３２ビットで指定される宛先アドレスおよび宛先ポート番号を使用してソケットを定義し、アプリ側に送信するメッセージであるapplmをバイトコードとして取得する。取得したバイトコードを、送信データとして例えばOutputStreamクラスに記述して送信を待機させる。その後、ソケットのコネクションを確立させ、確立させたソケットを通して宛先ポートに書き込みを行うことにより、対応するアプリに対してosmに対応するアプリの実行可能なコードであるapplmの送信が行なわれる。その後、当該コードは、ソケットをクローズし、処理を終了させる。
【００５７】
一方、メッセージ監視部では、後述するエントリ制御部から、applm、宛先（アプリの割り当てられるポート番号など）を含む、例えばメッセージ「applmsend」を受け取り、下記のコードを使用して「applmsend」メッセージからapplmおよび宛先を、文字列またはバイトコードとして取得する。その後、コードは、生成したソケットをクローズして、エントリ処理部による「applmsend」メッセージを取得する処理が終了する。
【００５８】
なお、本発明では送受信されるメッセージapplmsendは、固定長でも可変長でもよい。メッセージ監視部は、取得したメッセージを保持したバッファapplmRcvdbuffer内の値を解析して、applmおよび宛先を取得し、上述したソケット・コネクションを確立させるコードを用いて、対応するアプリに対してapplmを送付する。
【００５９】
図５は、図４のステップ４０２において生成される先入れ・先出しキュー・リストの構成を示した実施の形態である。図５に示すように、メッセージ監視部が生成し、管理するキュー・リスト５４は、待ち準位を示すQUEIDを格納するフィールドと、osmの全部の情報をエントリしたフィールドとから構成されている。osmフィールド５８は、本発明の特定の実施の形態では、osmの発行された日付、時間、プロトコル、ローカル・ポート番号（以下、本発明では、OSプロセス識別値(Piden)として参照する。)、例えば、0.0.0.0、127.0.0.1（ローカル・ループバック・アドレス）、または情報処理装置自体のIPアドレスなどから適宜選択される、ローカルIPアドレス、リモート（宛先）ポート番号、PID、ステータスなどが記述されている。
【００６０】
なお、本発明においてはポート番号を使用するのではなく、実行ファイル名をOSから返させ、実行ファイル名に基づいてキュー・リストに登録し、後に説明するエントリ・テーブルおよび変換テーブルの処理に使用することができる。
【００６１】
図５に示したキュー・リストに登録されたosmは、待ち順番が小さい方から順に処理されて行く。osmは、キュー・リスト内のosmに対応する処理が終了するか、または対応するosmがどのアプリからも要求されていない場合には、削除され、再度新たなosmが登録されるのを待機する。このため、キュー・リストは、適切な数のosmを管理して、検索の効率化を可能としている。
【００６２】
図６は、本発明のメッセージ・ハンドラが含む、エントリ制御部が実行する処理のフローチャートである。エントリ制御部は、ステップ７０１でOS起動時に応答して、またはユーザ指令によりメッセージ・ハンドラが起動された時点で処理を開始し、ステップ７０２でメッセージ監視部からの通知があるか否かを判断し、メッセージ監視部からのosmを含むエントリ・テーブルの検索要求メッセージであるget_queryメッセージがあれば（ｙｅｓ）、ステップ７０３へと処理を進め、get_queryメッセージを受け取るまでステップ７０２で待機する。
【００６３】
ステップ７０３では、通知されたosmを待機しているアプリが、配布先・メッセージ格納部に格納されているか否かの検索を実行して、その返り値を取得する。ステップ７０４では、エントリ制御部は、受け取った返り値を使用し、osmを待機しているアプリがエントリされているか否かを判断する。判断の結果、待機しているアプリがないことを示す返り値の場合（ｎｏ）には、ステップ７０８へと処理を進め、メッセージ監視部へと待機しているアプリが無いことを示すreplyを返し、ステップ７０２へと処理を戻し、その後のget_queryの通知を待機する。
【００６４】
また、待機しているアプリがある場合（ｙｅｓ）には、ステップ７０５で変換テーブルをルックアップしてget_queryから取得したosmをアプリが実行可能なコード(applm）に対応付け、ステップ７０６でメッセージ監視部にapplmおよびアプリの宛先を通知する。なお、これらの通知についてもプロセス間通信により行うことができ、エントリ制御部では、例えば、ソケット「applmsend」を定義し、上述したのと同様のソケットを作成し、applmおよび宛先をバイトコードとして、メッセージ監視部に送信する。
【００６５】
図７は、本発明のメッセージ監視部が利用し、エントリ制御部が含むステップ７０５で参照する変換テーブルの実施の形態を示す。図７に示すように本発明で使用する変換テーブル６０は、OSプロセス識別値を登録するフィールド６２と、当該OSプロセス識別値に対応して生成され、アプリ側で関連する状態を示すフィールド６４と、アプリ側が実行できる実行可能なコードをリストしたフィールド６６とが形成されている。例えば、Piden1は、外部記憶装置を管理するプロセスのポート番号または実行ファイル名を直接的に使用することができる。対応するosmとしては、プロミスキャス・モードで受信している場合には、本来の宛先プロセスに宛てた内容となっており、また、netstatを使用した場合には、closed、listening、syn_sent、syn_received、established、fin_wait_1、fin_wait_2、last_ackなどを挙げることができるが、本発明ではこれらに限定されるものではない。
【００６６】
また、Piden2は、プロセス状態を示すosmではなく、実際のOSプロセスの実行コマンドの値が対応付けられており、本発明では、いずれの実施の形態でも、osmから取得でき、アプリに関連するOS側の実行状態を示す値であればいかなるものでも使用することができる。
【００６７】
Piden1についてより具体的に説明すると、例えば、osmがestablished、listening、syn_sent、last_ackの場合には、他のアプリまたはプロセスがポートを占有していることを示しているか、または何らかの機能不全が発生し、対応するosmに対する応答がなされない場合がある。このため、それぞれに対応してアプリ側で実行可能なコードがフィールド６６に登録されている。いずれの場合にもメッセージ内容とアプリが実行可能なコードとが対応づけられている限り、本発明において特定の実施の形態に限定されるものではない。
【００６８】
さらに、図７に示すように、本発明の変換テーブル６０は、フィールド６６には、osmに対応した処理をアプリ側が実行可能なコードが記述されている。例えば、osmが「listening」の場合には、対応するapplmとして待機中であることを表示させる実行可能なコードを示す「display “wait”」が記述されている。また、osmがプロセス間通信の確立を示す「established」の場合であって、当該アプリの仕様に応じて、他の処理を先行して実行させることができる場合には、次の処理を実行させるべくcall function ()などのコマンドとされている。
【００６９】
さらに、例えば、osmが「syn_sent」の場合には、OS側の対応プロセスがメッセージを送った後、その応答を待っている状態なので、以後の占有時間が予測できず、また最悪の場合には対応するプロセスまたはデバイスが使用不能の状態に陥っている可能性がある。このため、図７の実施の形態では、対応するアプリ側の実行可能なコードとして、処理を一旦中断または終了させ、データなどを退避させる処理を指令するcall close ()などが対応して登録されている。なお、本発明では、どのようなOSプロセスの状態についてもアプリ側の処理が同一である場合には、osmと実行可能なコードとの対応を必要とせず、変換テーブル６０は、OSプロセス識別値とapplmとが対応した実施の形態とすることができる。
【００７０】
図８は、本発明のメッセージ・ハンドラの処理をUML(Unified Modeling Language)を使用して記述し、各オブジェクトのインスタンスの処理を示した図である。メッセージ監視オブジェクトは、OSが起動されたことに応答してそのインスタンスを生成し、osmの発生に応答して、または定期的に継続してメッセージの監視を行っており、メッセージがモニタされるごとにキュー・リストに追加している。その後、キュー・リストに格納されたosmについてのメッセージ配布オブジェクトのインスタンスが生成され、エントリ検索・読出しメッセージをエントリ制御部に渡す。
【００７１】
エントリ制御オブジェクトでは、エントリ検索・読出しメッセージを受け取って検索オブジェクトのインスタンスを生成し、配布先・メッセージ格納部への照会およびメッセージ・コンバートを実行し、その結果をメッセージ配布インスタンスへと渡す。メッセージ配布インスタンスは、受信した結果から、applmおよび宛先を取得し、新たなソケットを定義し、配布先であるアプリに通信する。メッセージ配布インスタンスは、アプリ側からの適切なフォーマットで記述された受信完了通知close_ackを受けて終了し、アプリに対して当該OSプロセスの状況に対応する処理を可能としている。また、メッセージ配布インスタンスは、送信するべきパケットを送信終了したときに、アプリからの通知を待たずに終了してもよい。
【００７２】
さらに、本発明の特定の実施の形態では、メッセージ配布のインスタンスからのメッセージを受け取ると、検索オブジェクトは、復号オブジェクトのインスタンスを生成させて、復号処理を実行させる。エントリ・テーブル内には、システムおよびアプリ側のコードが格納されており、不正なアクセルから各実行コードを秘匿しておくことが好ましい場合も生じる。本発明のエントリ制御部は、暗号化・復号処理を実行する暗号オブジェクトを含み、エントリ・テーブル内の選択したデータまたは全部のデータを、暗号化して格納させておき、必要に応じて復号オブジェクトのインスタンスを作成し、エントリ・テーブル内のデータを復号しながら検索を実行することができる。
【００７３】
以下、本発明において使用するエントリ・テーブルについて、図９〜図１１を使用して説明する。図９は、本発明のエントリ制御部が管理する、メモリまたはハードディスクなどの記憶部において管理される、配布先・メッセージ格納部が含むエントリ・テーブルの第１の実施の形態を示した図である。図９に示したエントリ・テーブル７０は、アプリからのOSメッセージ要求があった場合にエントリ・テーブルにアプリが動的に登録される。アプリの登録は、特に限定されるものではないが、アプリは何らかの処理を実行して待機している状態なので先着順に登録され、処理が終了するとエントリから削除される、待ち行列または先入れ・先出し処理を行うキューとして構成することができる。
【００７４】
図９に示されるように、エントリ・テーブル７０には、アプリ側でOSメッセージを待機しているプロセスをエントリしたフィールド７２と、待機側のプロセスが要求するOSプロセス識別値をエントリしたフィールド７４と、送信元識別値（例えば、待機プロセスのポート番号）をエントリしたフィールド７６とを備えており、対応する待機プロセスについて、要求OSプロセスと送信元識別値とがレコードを形成している。
【００７５】
エントリ制御部は、メッセージ監視部から、メッセージ配布インスタンスのアクセスを受けると、先入れ順にエントリを検索して行き、対応する要求OSプロセスを待機している待機プロセスに対して、先着順にメッセージをコンバートする。エントリ制御部は、送信元識別値と共にコンバート結果をapplmBufferなどにバッファリングしておき、問い合わせを受けたOSMを待機しているすべての待機プロセスについてapplmの変換を終了すると、結果を格納したapplmBufferの内容を送信データとしてカプセル化してメッセージ配布インスタンスに返している。また、エントリ制御部は、対応する待機プロセスの処理済みレコードを削除して処理を終了する。
【００７６】
図１０は、本発明で使用するエントリ・テーブルの別の実施の形態を示す。図１０に示したエントリ・テーブル８０は、フィールド８２と、フィールド８４と、フィールド８６に加えて、OSプロセスを要求した要求時刻など、時間的優先順位を示すことができるフィールド８８とがレコードを形成している。図１０に示したエントリ・テーブルには、新規なアプリがインストール／アンインストールされた時点、またはアプリのプロセスが起動／終了した段階で順次エントリ・テーブルに追加／削除され、図９に示されるように、アプリ側からの要求に応答して動的に、先入れ・先出しの処理に対応するものではない。
【００７７】
また、図１０に示したエントリ・テーブル８０の実施の形態では、アプリ側のプロセスがOSのメッセージを待機していることを、フィールド８８が対応するOSプロセスについてnullか否かを使用して判断することができる。さらに、フィールド８８がnullではない場合には、フィールド８８を参照してその時刻を判断する。エントリ制御部は、メッセージ監視部からの検索・読出しメッセージを受け取ると、対応するOSを待機しているアプリのプロセスがあるか否かを、フィールド８４をルックアップし、さらにフィールド８８を参照して複数エントリされている場合には、要求時刻の早い順に処理を行い、処理結果を、順次バッファリングさせ、待機する対応アプリに対して処理画終了した段階でカプセル化してメッセージ監視部へと返す。
【００７８】
図１１には、本発明のエントリ・テーブルの第３の実施の形態を示す。図１１に示したエントリ・テーブル９０は、エントリの追加・削除の処理については図１０に示したエントリ・テーブル８０と同様にして行われる。しかしながら、エントリ・テーブル９０に登録された各要素は、図１１に示した実施の形態では、フィールド９８に登録された要求時刻以外のフィールドのデータは、エントリに登録する時点でエントリ制御部が暗号鍵を使用して暗号化した後に格納される。このため、エントリ制御部のエントリには、適切な復号処理がなされない限り、アクセスできない構成とされている。なお、本発明の特定の実施の形態では、要求時刻データについても暗号化することが可能であるものの、エントリ・テーブルに対する不正アクセスによる影響は他のデータに比較して少ないので、暗号化せずに登録することができる。
【００７９】
本発明において図１１に示したエントリ・テーブル９０を使用する場合、暗号化方式として、公開鍵法、共通鍵方式、公開鍵方式のいずれの方式でも用いることができ、暗号化アルゴリズムについてもブロック暗号法、ストリーム暗号法、RSA暗号法、離散対数暗号法、だ円暗号法などを使用することができる。本発明においては、処理速度の点から共通鍵法を用いることができ、例えば、メッセージ監視部からの通信データとして復号鍵を送信し、復号鍵で復号しつつデータを取得することができる。
【００８０】
この他、さらに厳密なセキュリティを得る場合には、処理時間は多少要することになるものの、RSA暗号法などを用いた公開鍵方式を使用した暗号法を使用することができるし、メッセージ監視部から、送信するデータと、そのハッシュ値とを送り、エントリ制御部は、秘密鍵を使用してエントリ制御部が送信データを復号して、新たに得られたハッシュ値を生成し、受信したハッシュ値と比較を行うことでデータの改ざんをおよび送信元を特定する電子署名プロトコルを使用することもできる。
【００８１】
図１２は、本発明においてエントリ制御部が、エントリ・テーブルにエントリされたアプリを削除する場合の処理を、UMLを使用して説明した図である。なお、本発明では、エントリの追加および削除についても、エントリ制御部は同様の暗号処理および復号処理を使用することができる。図１２に示すように、配布先であるアプリからエントリ・テーブルへの追加を要求する場合には、配布先がエントリ制御部に対してエントリに対する追加を要求すると、メッセージaddentryがエントリ制御部へと渡される。
【００８２】
エントリ制御部では、当該メッセージaddentryを受け取って、例えばキューまたはリストにエントリを追加するlistクラスのメンバ関数などを含む、addentry ()オブジェクトのインスタンスを生成させ、ファイルをオープンするメッセージopenを配布先・メッセージ格納部へと通知する。通知を受けた配布先・メッセージ格納部では、ファイルをオープンし、エントリの数だけ読出し処理を行い、さらにエンコード処理を行い、エンコードが終了した時点で、エントリ・テーブルへとエンコードされたデータを記入する。
【００８３】
また、エントリを削除する場合には、配布先であるアプリから、エントリ削除を通知するメッセージdelentryを受け取ると、エントリ制御部は、例えば、エントリを削除するlistのメンバ関数を含むオブジェクトdelentry ()のインスタンスを生成し、デコード処理によりエントリ・テーブル内の値を取得し、対応するレコードをエントリ・テーブルから削除する処理を実行する。
【００８４】
図１３は、本発明のメッセージ・ハンドラの処理の第２の実施の形態を示した図である。図１３に示したメッセージ・ハンドラの処理は、エントリ制御部が、アプリからのosm要求を監視しており、アプリからのosm要求を受け取ってメッセージ監視部に問い合わせを発行する処理を実行する。本発明では特に限定するわけではないが、図１３に示したメッセージ・ハンドラの処理は、本はつん名の情報処理装置を、LAN、WAN、またはインターネットなどのネットワークを介して、情報処理装置をクライアント端末またはWebクライアントとして機能させる場合に好適な実施の形態である。
【００８５】
図１３に示す処理は、ステップ１３００から開始し、エントリ制御部は、ステップ１３０１でエントリ制御部に新たなメンバが追加されたか否かを、例えばエントリ・テーブルのデータ一致性または最終アクセス履歴などをチェックして判断するか、またはアプリからのosm要求を受け取ったことに対応して判断する。その結果、新たなメンバが追加されていないと判断される場合、およびosm要求を受け取っていない（ｎｏ）には、新たなメンバが追加されるまでステップ１３０１で待機する。
【００８６】
ステップ１３０１で、新たなメンバが追加されたまたはosm要求を受け付けた場合には、ステップ１３０２で新たなメンバがosmを要求しているか否かを判断する。なお、エントリ制御部が、図９に示したようにosm要求が明示的になされたアプリだけを管理する実施の形態を使用する場合には、ステップ１３０２の判断を省略し、直ちにステップ１３０３の処理を実行することができる。ステップ１３０２の判断の結果、メンバが追加されてもosmを要求していないと判断した場合（ｎｏ）には、再度ステップ１３０１へと処理を分岐させ、新たなメンバの追加をモニタする。
【００８７】
また、ステップ１３０２の判断が、新たなメンバがosmを要求している場合（ｙｅｓ）、またはエントリ・テーブルに追加されたこと自体がosmを要求している実施の形態を使用する場合には、ステップ１３０３へと処理を進め、メッセージ監視部が管理するPidenおよびそれに対応するosmを検索する。
【００８８】
ステップ１３０４では、ステップ１３０３の検索結果の返り値を使用してその返り値が、メッセージ監視部が外用するエントリを保有していないことを示す値を返すか否かを判断し、エントリを保有していないことを示す値が返された場合（ｙｅｓ）には、ステップ１３０１へと処理を戻しさらに新たなエントリが追加されるのを待機する。エントリを保有していることを示す値が返された場合（ｎｏ）には、ステップ１３０５においてメッセージ監視部に対して対応するosmを送付する要求を発行してosmを取得するか、またはステップ１３０５の返り値と同時に送付されるosmを使用して、変換テーブルをルックアップすることにより、待機中のアプリが実行可能なコードへと変換する。その後、ステップ１３０６でアプリの宛先に対してコードを送信する。なお、図１３に示した実施の形態でもエントリ制御部は、暗号化および復号の処理を実行しながら各処理を実行することができる。
【００８９】
また、ステップ１３０６の処理においてエントリ制御部は、単一の情報処理装置内で、またはネットワークを介した例えばWebサーバなどとして機能する場合には、宛先IPアドレスと、リモート・ポート番号をポート８０とを使用し、TCP/IPなどのプロトコルで実行可能なコードapplmを送信することができる。また、本発明の情報処理装置を、LANなどに接続されたクライアント−サーバ・システムで使用する場合には、TCP/IPまたはUDP/IPまたはその他の適切なプロトコル、例えばNETBEUIなどのプロトコルを使用して実行可能なコードapplmを発行することができる。
【００９０】
図１４は、本発明の図１３に示したエントリ制御部が実行する処理のオブジェクト間の通信を示すUMLを示す。メッセージ監視部は、OS起動に応答して、またはユーザ指令により監視オブジェクトのインスタンスを起動し、osmを登録している。その後、配布先のアプリが起動され、アプリがosmを要求するメッセージ、例えば、要求OSプロセスの識別値を引数とするrequest_osm(Piden)を、本発明のメッセージ・ハンドラに対して通知する。
【００９１】
この通知を受け取ったエントリ制御では、エントリ制御オジェクトのインスタンスを作成し、特定の実施の形態に応じて共有鍵または公開鍵と秘密鍵とを使用して暗号化および復号処理を実行し、配布先・メッセージ格納部が管理するエントリ・テーブルにアプリを追加する。その後、エントリ制御オブジェクトのインスタンスは、メッセージ監視部に対応するPidenのosmを問い合わせるメッセージであるsearch_request(Piden)を発行し、メッセージ監視部による検索の結果であるメッセージresponse_search(Piden, osm)を受け取る。
【００９２】
response_search(Piden, osm)を受け取ったエントリ制御部は、レスポンス・パケットを解析し、必要に応じて復号処理を行って、宛先をエントリ・テーブルから検索し、変換テーブルからアプリが実行可能なコードを取得し、取得した実行可能なコードを、例えばresponse_osm (Piden, code)としてアプリ側に発行する。その後、エントリ制御部は、エントリ・テーブルから処理を終了したアプリに対応するレコードを削除する。さらにその後、アプリ側のインスタンスは、エントリ制御部からのメッセージであるresponse_osm(Piden, code)を取得して対応するコードを実行し、osmに対応した処理を実行し、当該アプリ側のインスタンスを終了させる。
【００９３】
図１５は、本発明のメッセージ・ハンドラを実装する情報処理装置の実施の形態を示す。本発明の情報処理装置１００は、図示した実施の形態では、ノートブック型のパーソナル・コンピュータとして構成されている。情報処理装置１００は、イーサネット（登録商標）などを介して、LANなどのネットワーク１０２と通信を行っていて、クライアント・サーバタイプのサービスまたは、Webサーバからのサービスを受け取ることが可能とされている。
【００９４】
また、情報処理装置１００には、EPROMなどを含む半導体スティック、カード型HDDなどの外部記憶装置１０４が、USBポートまたはPCIバス、AGPバス、ISAバスなどを介して接続されていて、ユーザ指令に応じて、処理データの格納を行っている。ユーザは、マウス１０６やキーボード１０８を介して情報処理装置１００への入力を行っていて、文書管理・アプリケーションを介して、例えばワードプロセッサ・ソフトウェアおよびデータベース・ソフトウェアにより作成した文書の管理を行っている。
【００９５】
本発明のメッセージ・ハンドラは、例えば、特定の文書管理ソフトウェアの構成モジュールとすることもできるし、また独立したソフトウェア製品とすることができるが、いずれの場合でもOSの起動時と共に機能されるサービス・ソフトウェアまたはdaemonソフトウェアとすることができる。また、本発明のメッセージ・ハンドラは、ユーザ指令による起動のため、起動アイコンをディスプレイ・ウィンドウ上に表示させ、ユーザに対して明示的にメッセージ・ハンドラの起動を指令させることもできる。
【００９６】
図１５に示した実施の形態では、情報処理装置１００には、アプリとして文書管理ソフトウェアが実装されており、また他にもアプリとして、ワードプロセッサ・ソフトウェアまたはデータベース・ソフトウェアがインストールされ、ワードプロセッサ・ソフトウェアまたはデータベース・ソフトウェアは、OSからのメッセージを使用してプロセス管理が行われている。一方、文書管理ソフトウェアは、外部記憶装置１０４などと、ドライバ・ソフトウェアを介して通信を行っていて、その入出力は、BIOS、デバイス・マネージャなどを介して管理されている。
【００９７】
情報処理装置１００上で稼働している文書管理ソフトウェアは、OSが発行するメッセージに対する直接的な宛先として登録されておらず、この結果、OSプロセスがいくら発行されようとも、OSからのメッセージの宛先とされるアプリだけがOSからのメッセージを受け取ることができる。このため、文書管理ソフトウェアは、OSからのメッセージを取得することができず、最悪のケースでは、OSプロセスに対応するワードプロセッサ・ソフトウェアからのメッセージを待たなければ、常にレスポンスを待機する状態に放置され、その結果、情報処理装置１００の入出力状態が文書管理ソフトウェアの待機状態に保持されてしまうこともあり得る。
【００９８】
このような状況が発生すると、それまで作成した貴重なユーザデータは、ユーザがリセット動作などを行うことにより消去されることになり、文書管理上、およびユーザ負担を考えると文書管理ソフトウェアの利用性に制限を与えてしまう。また、ネットワークを介して高付加価値のデータの送受信を行っている場合にも、サーバ側の処理に応じては、要求したhttpリクエストに対して対応するhttpリクエストが返されない場合もある。また、作業の途中でメモリ・スティックやカード型HDDが取り外されたような場合、情報処理装置が「サーバが応答しません」または「接続されていません」などに対応するOS側のメッセージを返す場合もあるが、この場合でも、当該OSのメッセージは、文書管理ソフトウェアなどに対しては直接返されず、またそのメッセージを仮に受け取ったとしても文書管理ソフトウェアがそれに対応する処理を実行できない場合には、実質的に待機状態となってしまうので、それまでに作成した文書管理ドキュメントが無駄になってしまう可能性もある。
【００９９】
本発明のメッセージ・ハンドラは、上述したような場合でもOSメッセージを監視して、当該OSからのメッセージを待機している不特定多数のアプリケーションによる要求に応じて、または要求される可能性に応じてOSのステータスに対応した実行可能なコードを通知することができる。本発明では、アプリは、OSの実行状態に対応して、例えば、不揮発性メモリなどに作成したデータを退避させてバックアップ・ファイルを自動作成するなどの処理を実行させるなど、アプリ側で実行可能なコードを、OSからのメッセージの代わりに受け取ることができる。このため、情報処理装置は、ユーザにより作成された高付加価値のデータが失われない処理を実行して、ユーザの作業効率を向上させている。
【０１００】
図１６は、本発明の情報処理装置１００、１１０、１１２がネットワークに接続された場合の第２の実施の形態を示した図である。図１６に示された実施の形態では、情報処理装置１００は、LANまたはWANまたはインターネットといったネットワーク１０２を介して、クライアント−サーバ型またはWebサーバなどのサーバ１１４へと接続されており、データベース１１６などに対して文書の格納・取得などを行っている。情報処理装置１００、１１０、１１２は、メッセージ・ハンドラを備えており、例えばユーザ指令またはOS起動に応答してメッセージ・ハンドラが起動され、OSメッセージを監視している。このため、当該OSを使用しているが当該OSメッセージが宛先とされていない重要なメッセージが発行されてもOSメッセージが素通りしてしまうアプリケーションに対してもOSメッセージを認識させることができる。
【０１０１】
なお、本発明における好適な実施の形態では、OSメッセージの発行元の識別値としては、OS供給元によるウェルノウン・ポート番号または実行ファイル名から選択され、アプリケーション・プログラムの宛先は、レジスタード・ポート番号またはダイナミック・プライベート・ポート番号から直接使用して選択することで、プロセス間通信を効率化することができるが、ポート番号とプロセス固有に付された名称とをそれぞれ対応させるリストまたは対応付け機能部を設けて、プロセス側名称と、アプリケーション側名称とをエントリ・テーブルに格納して、ポート番号を使用せずに対応付けおよび変換処理を行うこともできる。
【０１０２】
本発明の上記機能は、C++、Java（登録商標）、Java（登録商標）Beans、Java（登録商標）Applet、Java（登録商標）Script、Servletなどのオブジェクト指向ブログラミング言語で記述することができ、また、本発明のプログラムは、フレキシブルディスク、ハードディスク、CD-ROM、CD-RW、MO、DVD、DVD-RW、半導体メモリまたは伝送媒体としてネットワークを介して頒布されて、情報処理装置にインストールされて本発明の各機能部を構成させることができる。さらに、本発明の情報処理装置は、特定の実施の形態として、パーソナル・コンピュータに実装されるものとして記述してきたが、電子写真複写機、プリンタ、MFPなど、CPUを含む、オブジェクト指向プログラミングが実行可能な画像処理に適した情報処理装置にも適用することができる。
【０１０３】
これまで本発明を図面に示した実施の形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、他の実施の形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【図面の簡単な説明】
【０１０４】
【図１】本発明の情報処理装置のハードウェア構成を示した図。
【図２】本発明の情報処理装置のソフトウェア構成を示した図。
【図３】本発明の情報処理装置が含むメッセージ・ハンドラの構成を示した図。
【図４】メッセージ監視部の処理を示したフローチャート。
【図５】キュー・リストのエントリされたOSメッセージを示した図。
【図６】本発明のエントリ制御部の処理を示した図。
【図７】本発明の変換テーブルを示した図。
【図８】本発明のメッセージ・ハンドラを使用するプロセスのUML図。
【図９】本発明のエントリ・テーブルの第１の実施の形態を示した図。
【図１０】本発明のエントリ・テーブルの第２の実施の形態を示した図。
【図１１】本発明のエントリ・テーブルの第３の実施の形態を示した図。
【図１２】本発明のエントリ・テーブルの追加・削除処理を示したUML図。
【図１３】本発明のエントリ制御部の処理の第２の実施の形態を示した図。
【図１４】図１３に示したエントリ制御部を使用する場合のオブジェクトの処理を示したUML図。
【図１５】本発明の情報処理装置の第１の実施の形態を示した図。
【図１６】本発明の情報処理装置の第２の実施の形態を示した図。
【符号の説明】
【０１０５】
１０…情報処理装置、１２…MPU、１４…メモリ（ＲＡＭ、ＲＯＭ）、１６…入出力装置、１８…インタフェース、２０…インタフェース、２２…記憶装置、２４…内部バス、２６…VRAM、２８…グラフィック・チップ、３０…ディスプレイ装置、３２…ネットワークI/F、３４…ネットワーク、４０…BIOS＆デバイス・ドライバ層、４２…オペレーティング・システム層、４４…アプリケーション・プログラム層、４６…メッセージ・ハンドラ、４８…メッセージ監視部、５０…エントリ制御部、５２…配布先・メッセージ格納部、５４…キュー・リスト、５６、５８…フィールド、６０…変換テーブル、６２〜６６…フィールド、７０…エントリ・テーブル、８０…エントリ・テーブル、９０…エントリ・テーブル、１００…情報処理装置、１０２…ネットワーク、１０４…外部記憶装置、１０６…マウス、１０８…キーボード、１１０、１１２…情報処理装置（クライアント端末）、１１４…Webサーバ、１１６…データベース
【図１】
0004725955.tif 000002
【図２】
0004725955.tif 000003
【図３】
0004725955.tif 000004
【図４】
0004725955.tif 000005
【図５】
0004725955.tif 000006
【図６】
0004725955.tif 000007
【図７】
0004725955.tif 000008
【図８】
0004725955.tif 000009
【図９】
0004725955.tif 000010
【図１０】
0004725955.tif 000011
【図１１】
0004725955.tif 000012
【図１２】
0004725955.tif 000013
【図１３】
0004725955.tif 000014
【図１４】
0004725955.tif 000015
【図１５】
0004725955.tif 000016
【図１６】
0004725955.tif 000017