(57)【特許請求の範囲】
【請求項１】
複数のインターフェースソケットを有し、各インターフェースソケットはサポートされた送信元プロトコルを一つ割り当てられており、前記インターフェースソケットを介して送信先装置に対する送信元装置からの情報を受け取るようになっている受信機回路マネージャと、
前記受信機回路マネージャから情報を受け取る１または複数の受信機と、
前記情報を、有限状態オートマトンを用いて送信先のフォーマットに変換する１または複数のメッセージコンバータと、
前記情報に対してどの送信先のプロトコルが適しているかを決定するメッセージルーターと、
前記情報を送信先のフォーマット及びプロトコルで前記送信先装置へ送る１または複数のメッセージ送信装置と、を備え、
前記有限状態オートマトンは、第１のステージ及びそれに続く複数の次のステージを有するマルチステージパイプラインを有しており、該マルチステージパイプラインの各ステージは、結果が１つあるいは複数の入力変数の関数として得られるマトリクスを有しており、前記複数の次のステージのそれぞれのステージにおける前記複数の入力変数のうちの１つは、当該ステージよりも前のステージの前記結果を有することを特徴とする送信元装置から送信先装置への情報を変換可能な汎用プロトコル変換機。
【請求項２】
前記マルチステージパイプラインの一つのステージは、プロトコル判別ステージを有しており、該ステージへの前記入力変数は、さらに、送信元プロトコルタイプ識別子、接続状態識別子及び送信先プロトコルタイプ識別子を有しており、前記ステージから得られる前記結果は、さらに、プロトコルアクションインデックスを有しており、該プロトコルアクションインデックスは、さらに、前記接続状態識別子と、同種の送信元プロトコルのカテゴリと関連付けられた識別子と、同種の送信先プロトコルのカテゴリと関連付けられた識別子とを含むプロトコル変数に対応する識別子を有することを特徴とする請求項１に記載の汎用プロトコル変換機。
【請求項３】
前記マルチステージパイプラインの一つのステージは、装置判別ステージを有しており、前記ステージへの前記入力変数は、さらに、プロトコルアクションインデックスと、送信元装置タイプ識別子と、送信先装置タイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、装置インデックスを有しており、該装置インデックスは、さらに、前記プロトコルアクションインデックスと、同種の送信元装置のカテゴリと関連付けられた識別子と、同種の送信先装置のカテゴリと関連付けられた識別子とを有する装置変数に対応する識別子を有することを特徴とする請求項１に記載の汎用プロトコル変換機。
【請求項４】
前記マルチステージパイプラインの一つのステージは、アプリケーション判別ステージを有しており、前記ステージへの前記入力変数は、さらに、装置インデックスと、送信元アプリケーションタイプ識別子と、送信先アプリケーションタイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、アプリケーションインデックスを有しており、該アプリケーションインデックスは、さらに、前記装置インデックスと、同種の送信元アプリケーションのカテゴリと関連付けられた識別子と、同種の送信先アプリケーションのカテゴリと関連付けられた識別子とを有するアプリケーション変数に対応する識別子を有することを特徴とする請求項１に記載の汎用プロトコル変換機。
【請求項５】
前記マルチステージパイプラインの一つのステージは、フォーマット判別ステージを有しており、該ステージへの前記入力変数は、さらに、アプリケーションインデックスと、送信元フォーマットタイプ識別子と、送信先フォーマットタイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、フォーマットインデックスを有しており、該フォーマットインデックスは、さらに、前記アプリケーションインデックスと、同種の送信元フォーマットのカテゴリと関連付けられた識別子と、同種の送信先フォーマットのカテゴリと関連付けられた識別子とを有するフォーマット変数に対応する識別子を有していることを特徴とする請求項１に記載の汎用プロトコル変換機。
【請求項６】
前記マルチステージパイプラインの一つのステージは、アクション選択ステージを有しており、前記ステージへの前記入力変数は、さらに、少なくともフォーマットインデックスと現在のオートマトン状態識別子とを有しており、前記ステージから得られる前記結果は、さらに、次のオートマトン状態識別子とアクションとを有しており、該アクションは、さらに、(i)何もしない、(ii)入ってくるメッセージを修正する、(iii)メッセージを送信先装置へ送る、(iv)入ってくるメッセージを拒絶する、及び(v)メッセージを送信元装置へ送る、からなるアクションの一つ以上を実行するための一連の実行可能な命令を有していることを特徴とする請求項１に記載の汎用プロトコル変換機。
【請求項７】
複数のインターフェースソケットを有し、各インターフェースソケットはサポートされた送信元プロトコルを一つ割り当てられており、前記インターフェースソケットを介して送信先装置に対する送信元装置からの情報を受け取るようになっている受信機回路マネージャと、
前記受信機回路マネージャから情報を受け取る１または複数の受信機と、
前記情報を有限状態オートマトンを用いて送信先のフォーマットに変換する１または複数のメッセージコンバータと、
前記情報に対してどの送信先のプロトコルが適しているかを決定するメッセージルーターと、
前記情報を送信先のフォーマット及びプロトコルで前記送信先装置へ送る１または複数のメッセージ送信装置と、を備え、
前記有限状態オートマトンは、第１のステージ及びそれに続く複数の次のステージを有するマルチステージパイプラインを有しており、該マルチステージパイプラインの各ステージは、結果が１つあるいは複数の入力変数の関数として得られるマトリクスを有しており、前記複数の次のステージのそれぞれのステージにおける前記複数の入力変数のうちの１つは、当該ステージよりも前のステージの前記結果を有することを特徴とする送信元装置から送信先装置への情報を変換可能な汎用プロトコル変換システム。
【請求項８】
前記マルチステージパイプラインの一つのステージは、プロトコル判別ステージを有しており、記ステージへの前記入力値は、さらに、送信元プロトコルタイプ識別子と、接続状態識別子と、送信先プロトコルタイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、プロトコルアクションインデックスを有しており、該プロトコルアクションインデックスは、さらに、前記接続状態識別子と、同種の送信元プロトコルのカテゴリと関連付けられた識別子と、同種の送信先プロトコルのカテゴリと関連付けられた識別子とを有するプロトコル変数に対応する識別子を有することを特徴とする請求項７に記載の汎用プロトコル変換システム。
【請求項９】
前記マルチステージパイプラインの一つのステージは、装置判別ステージを有しており、前記ステージへの前記入力変数は、さらに、プロトコルアクションインデックスと、送信元装置タイプ識別子と、送信先装置タイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、装置インデックスを有しており、該装置インデックスは、さらに、前記プロトコルアクションインデックスと、同種の送信元装置のカテゴリと関連付けられた識別子と、同種の送信先装置のカテゴリと関連付けられた識別子とを有する装置変数に対応する識別子を有することを特徴とする請求項７に記載の汎用プロトコル変換システム。
【請求項１０】
前記マルチステージパイプラインの一つのステージは、アプリケーション判別ステージを有しており、前記ステージへの前記入力変数は、さらに、装置インデックスと、送信元アプリケーションタイプ識別子と、送信先アプリケーションタイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、アプリケーションインデックスを有しており、該アプリケーションインデックスは、さらに、前記装置インデックスと、同種の送信元アプリケーションのカテゴリと関連付けられた識別子と、同種の送信先アプリケーションのカテゴリと関連付けられた識別子とを有するアプリケーション変数に対応する識別子を有することを特徴とする請求項７に記載の汎用プロトコル変換システム。
【請求項１１】
前記マルチステージパイプラインの一つのステージは、フォーマット判別ステージを有しており、該ステージへの前記入力変数は、さらに、アプリケーションインデックスと、送信元フォーマットタイプ識別子と、送信先フォーマットタイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、フォーマットインデックスを有しており、該フォーマットインデックスは、さらに、前記アプリケーションインデックスと、同種の送信元フォーマットのカテゴリと関連付けられた識別子と、同種の送信先フォーマットのカテゴリと関連付けられた識別子とを有するフォーマット変数に対応する識別子を有していることを特徴とする請求項７に記載の汎用プロトコル変換システム。
【請求項１２】
前記マルチステージパイプラインの一つのステージは、アクション選択ステージを有しており、前記ステージへの前記入力変数は、さらに、少なくともフォーマットインデックスと現在のオートマトン状態識別子とを有しており、前記ステージから得られる前記結果は、さらに、次のオートマトン状態識別子とアクションとを有しており、該アクションは、さらに、(i)何もしない、(ii)入ってくるメッセージを修正する、(iii)メッセージを送信先装置へ送る、(iv)入ってくるメッセージを拒絶する、及び(v)メッセージを送信元装置へ送る、からなるアクションの一つ以上を実行するための一連の実行可能な命令を有していることを特徴とする請求項７に記載の汎用プロトコル変換システム。
【請求項１３】
送信元装置から受け取った情報を送信先装置へ転送するために変換する方法であって、前記方法は、
送信元装置から情報を受信するステップと、
前記情報を評価し、かつ、必要であれば、前記情報を有限状態オートマトンを用いて変換するステップとを有し、
前記変換ステップは、さらに、(i) 前記情報を送信元プロトコルから送信先プロトコルへ変換するステップ、(ii)前記情報を送信元アプリケーションフォーマットから送信先アプリケーションフォーマットへ変換するステップ、(iii)前記情報を送信元データフォーマットから送信先データフォーマットへ変換するステップの一つ以上のステップを含み、
前記有限状態オートマトンは、第１のステージ及びそれに続く複数の次のステージを有するマルチステージパイプラインを有しており、該マルチステージパイプラインの各ステージは、結果が１つあるいは複数の入力変数の関数として得られるマトリクスを有しており、前記複数の次のステージのそれぞれのステージにおける前記複数の入力変数のうちの１つは、当該ステージよりも前のステージの前記結果を有することを特徴とする前記変換方法。
【請求項１４】
前記マルチステージパイプラインの一つのステージは、プロトコル判別ステージを有しており、記ステージへの前記入力値は、さらに、送信元プロトコルタイプ識別子と、接続状態識別子と、送信先プロトコルタイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、プロトコルアクションインデックスを有しており、該プロトコルアクションインデックスは、さらに、前記接続状態識別子と、同種の送信元プロトコルのカテゴリと関連付けられた識別子と、同種の送信先プロトコルのカテゴリと関連付けられた識別子とを有するプロトコル変数に対応する識別子を有することを特徴とする請求項１３に記載の変換方法。
【請求項１５】
前記マルチステージパイプラインの一つのステージは、装置判別ステージを有しており、前記ステージへの前記入力変数は、さらに、プロトコルアクションインデックスと、送信元装置タイプ識別子と、送信先装置タイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、装置インデックスを有しており、該装置インデックスは、さらに、前記プロトコルアクションインデックスと、同種の送信元装置のカテゴリと関連付けられた識別子と、同種の送信先装置のカテゴリと関連付けられた識別子とを有する装置変数に対応する識別子を有することを特徴とする請求項１３に記載の変換方法。
【請求項１６】
前記マルチステージパイプラインの一つのステージは、アプリケーション判別ステージを有しており、前記ステージへの前記入力変数は、さらに、装置インデックスと、送信元アプリケーションタイプ識別子と、送信先アプリケーションタイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、アプリケーションインデックスを有しており、該アプリケーションインデックスは、さらに、前記装置インデックスと、同種の送信元アプリケーションのカテゴリと関連付けられた識別子と、同種の送信先アプリケーションのカテゴリと関連付けられた識別子とを有するアプリケーション変数に対応する識別子を有することを特徴とする請求項１３に記載の変換方法。
【請求項１７】
前記マルチステージパイプラインの一つのステージは、フォーマット判別ステージを有しており、該ステージへの前記入力変数は、さらに、アプリケーションインデックスと、送信元フォーマットタイプ識別子と、送信先フォーマットタイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、フォーマットインデックスを有しており、該フォーマットインデックスは、さらに、前記アプリケーションインデックスと、同種の送信元フォーマットのカテゴリと関連付けられた識別子と、同種の送信先フォーマットのカテゴリと関連付けられた識別子とを有するフォーマット変数に対応する識別子を有していることを特徴とする請求項１３に記載の変換方法。
【請求項１８】
前記マルチステージパイプラインの一つのステージは、アクション選択ステージを有しており、前記ステージへの前記入力変数は、さらに、少なくともフォーマットインデックスと現在のオートマトン状態識別子とを有しており、前記ステージから得られる前記結果は、さらに、その次のオートマトン状態識別子とアクションとを有しており、前記アクションは、さらに、(i)何もしない、(ii)入ってくるメッセージを修正する、(iii)メッセージを送信先装置へ送る、(iv)入ってくるメッセージを拒絶する、及び(v)メッセージを送信元装置へ送る、からなるアクションの一つ以上を実行するための一連の実行可能な命令を有していることを特徴とする請求項１３に記載の変換方法。
【請求項１９】
複数のインターフェースソケットを有し、各インターフェースソケットはサポートされた送信元プロトコルを一つ割り当てられており、前記インターフェースソケットを介して送信先装置に対する送信元装置からの情報を受け取るようになっている受信機回路マネージャを提供するステップと、
前記受信機回路マネージャから情報を受け取る１または複数の受信機を該受信機回路マネージャに接続するステップと、
前記受信機に接続されており、前記情報を有限状態オートマトンを用いて送信先のフォーマットに変換する１または複数のメッセージコンバータを提供するステップと、
前記メッセージコンバータに接続されており、前記情報に対してどの送信先のプロトコルが適しているかを決定するメッセージルーターを提供するステップと、
前記メッセージルーターに接続されており、前記情報を送信先のフォーマット及びプロトコルで前記送信先装置へ送る１つまたは複数のメッセージ送信装置を提供するステップと、を含み、
前記有限状態オートマトンは、第１のステージ及びそれに続く複数の次のステージを有するマルチステージパイプラインを有しており、該マルチステージパイプラインの各ステージは、結果が１つあるいは複数の入力変数の関数として得られるマトリクスを有しており、前記複数の次のステージのそれぞれのステージにおける前記複数の入力変数のうちの１つは、当該ステージよりも前のステージの前記結果を有することを特徴とする送信元装置から送信先装置への情報を変換可能な汎用プロトコル変換機を製作する方法。
【請求項２０】
前記マルチステージパイプラインの一つのステージは、プロトコル判別ステージを有しており、該ステージへの前記入力変数は、さらに、送信元プロトコルタイプ識別子、接続状態識別子及び送信先プロトコルタイプ識別子を有しており、前記ステージから得られる前記結果は、さらに、プロトコルアクションインデックスを有しており、該プロトコルアクションインデックスは、さらに、前記接続状態識別子と、同種の送信元プロトコルのカテゴリと関連付けられた識別子と、同種の送信先プロトコルのカテゴリと関連付けられた識別子とを含むプロトコル変数に対応する識別子を有することを特徴とする請求項１９に記載の方法。
【請求項２１】
前記マルチステージパイプラインの一つのステージは、装置判別ステージを有しており、前記ステージへの前記入力変数は、さらに、プロトコルアクションインデックスと、送信元装置タイプ識別子と、送信先装置タイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、装置インデックスを有しており、該装置インデックスは、さらに、前記プロトコルアクションインデックスと、同種の送信元装置のカテゴリと関連付けられた識別子と、同種の送信先装置のカテゴリと関連付けられた識別子とを有する装置変数に対応する識別子を有することを特徴とする請求項１９に記載の方法。
【請求項２２】
前記マルチステージパイプラインの一つのステージは、アプリケーション判別ステージを有しており、前記ステージへの前記入力変数は、さらに、装置インデックスと、送信元アプリケーションタイプ識別子と、送信先アプリケーションタイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、アプリケーションインデックスを有しており、該アプリケーションインデックスは、さらに、前記装置インデックスと、同種の送信元アプリケーションのカテゴリと関連付けられた識別子と、同種の送信先アプリケーションのカテゴリと関連付けられた識別子とを有するアプリケーション変数に対応する識別子を有することを特徴とする請求項１９に記載の方法。
【請求項２３】
前記マルチステージパイプラインの一つのステージは、フォーマット判別ステージを有しており、該ステージへの前記入力変数は、さらに、アプリケーションインデックスと、送信元フォーマットタイプ識別子と、送信先フォーマットタイプ識別子とを有しており、前記ステージから得られる前記結果は、さらに、フォーマットインデックスを有しており、該フォーマットインデックスは、さらに、前記アプリケーションインデックスと、同種の送信元フォーマットのカテゴリと関連付けられた識別子と、同種の送信先フォーマットのカテゴリと関連付けられた識別子とを有するフォーマット変数に対応する識別子を有していることを特徴とする請求項１９に記載の方法。
【請求項２４】
前記マルチステージパイプラインの一つのステージは、アクション選択ステージを有しており、前記ステージへの前記入力変数は、さらに、少なくともフォーマットインデックスと現在のオートマトン状態識別子とを有しており、前記ステージから得られる前記結果は、さらに、次のオートマトン状態識別子とアクションとを有しており、該アクションは、さらに、(i)何もしない、(ii)入ってくるメッセージを修正する、(iii)メッセージを送信先装置へ送る、(iv)入ってくるメッセージを拒絶する、及び(v)メッセージを送信元装置へ送る、からなるアクションの一つ以上を実行するための一連の実行可能な命令を有していることを特徴とする請求項１９に記載の方法。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明は、ソフトウェア通信およびメッセージングプロトコルの分野に関する。さらに詳しくは、本発明は、(1)無線、(2)シリアルケーブル経由、(3)ダイアルアップモデム、あるいは(4)ネットワークケーブルで接続された広範囲な種類の新規または既存の計算機装置(computing device)間での、よりロバスト性が高く効率的なインターフェースのための方法に関する。より詳しく述べると、本発明は、そのような装置がその装置特有のアプリケーション操作を行う際に用いられる(1)装置の種類、(2)プロトコルの種類、及び(3)アプリケーションデータの形式(format)の種類のような送信元と送信先の属性の設定が可能(configurable)なセットを変換する(translation)ためのインフラストラクチャに関する。
【０００２】
【背景技術】
組み込まれた演算能力を持った新しい電子装置は、様々な消費者やビジネスやその他の産業や応用のために、継続的に開発が続けられている。
【０００３】
これらの装置の例としては、スマートフォン(smart-phones)、ハンドヘルド（携帯）コンピュータ(handheld computers)やPDA(personal data assistants)、テレビジョン・セットトップボックス(television set-top boxes)、高画質テレビ(high-definition television)、リアルタイムＧＰＳナビゲーションシステムのような自動車の付属装置、セキュリティシステムセンサー、ポケットベル(pagers)などが含まれるが、これらに限定されるものではない。これらの装置は、通常、通信とデータの必要性や能力がそれぞれ異なっている。これらの例が示すように、データ通信のプロトコルと技術の問題は、もはや、電気通信産業やコンピューター産業や放送産業に限られたものではない。
【０００４】
しかしながら、これらの装置間でのデータ共有はしばしば困難である。共有が可能な少数のケースでは、そのような共有は２つの特定の装置間で起こり、通常は複雑で不便な手動による介入を必要とする。例えば、上で列挙した装置のような２つの電子装置間でのデータ共有に対しては次のような典型的なシナリオが考えられる。最初に、電子装置のユーザーは、もう一方の演算装置（一般にはパーソナルコンピュータ（ＰＣ））との接続を持たなくてはならない。共有されるデータは、普通は特別で専用のソフトウェアを用いて、ＰＣ以外の装置から間を取り持つＰＣへコピーされ、次いで暫定的な形式へ変換され、そして最終的に、別の専用ソフトウェアパッケージを変換のために用いて、目的の装置へ再びコピーすることになる。データを送信する装置と受信する装置が２つの異なる場所にある場合、インターネットがデータ伝送のための一般的な媒体であるが、これはデータの送信元と送信先にインターネット接続と電子メールの能力をもった複数のＰＣを必要とする。このシナリオでは、送信先のＰＣがデータを受信する装置のために、（例えば、電子メールに添付して）データを受け取り、その後、変換とダウンロードの操作を行って、データを送信先の装置へ入れる。この例が示すように、この方法は、通常、データの送信元とデータの送信先との間で人間による重大な調整を必要とする。さらに、データを受け取ったときに、送信元と送信先のデータ形式が非互換であることが発見されることもしばしばあり、これは送信の企てをすべてを無益なものにし、送信元と送信先の間でのデータ共有を不可能にする。
【０００５】
この問題に対するひとつの解決法を提供するものとして、最初に送信元と送信先の装置のタイプとデータ形式に対する要求を決定し、それから実際に送信元から送信先へと情報を伝送するような機器または装置がある。現在これらの機能を提供するゲートウェイ(gateway)として知られる既存の装置が存在するが、現在のゲートウェイは、設計過程で実装のために確認された通信プロトコルの特定のセット（通常は組（一対）である）のみを扱うことのできる非常に限定されたものである。新しいプロトコルやデータフォーマットに対するサポートを既存のゲートウェイに追加すると、重大な再設計や更新や変更が必要となることが多く、それらはすべて時間を浪費しエラーを発生させやすくする。
【０００６】
例えば、Darland, et al.に対する米国特許第5,793,771号では、ＳＳ７電気通信プロトコルからネットワーク情報分散サービス（ＮＩＤＳ）プロトコルへの変換またはその逆を行う電気通信産業に関連したゲートウェイについて開示している。他のゲートウェイと同様に、このゲートウェイもひとつの通信における要求を解決するために設計されたものであるから、異なる装置や異なる産業に利用される新しいプロトコルを重大な作り直しを行うことなく伝送可能にすることはできない。
【０００７】
【発明が解決しようとする課題】
そのため、新しい装置やプロトコルが導入された際に、継続的に更新や変更をすることを必要とせず、日々進化する多様な産業の電子装置分野に追従することのできる変換機を提供する新しい解決策が必要とされている。
【０００８】
【課題を解決するための手段】
本発明は、このような汎用通信プロトコル変換機である。本発明は、送信元と送信先の装置の種類とデータ形式に対する要求を決定し、その後に送信元から送信先への情報伝達を扱う。本発明は、１０個の主要な識別（判別）装置(discriminator)を評価することによって、様々な通信プロトコルのオンザフライな認識(on-the-fly recognition)、分類及び変換が可能である。これにより、本発明は、将来のプロトコル、装置の種類、アプリケーションのデータ形式を、設計変更や更新を必要とせず、認識しかつ操作することを可能とする。
【０００９】
本発明は、クライアント・サーバーのベンダーが、アプリケーションとプロトコルに特有なデータを、その内部のデータ構造や実装コードに対して変更を加えることなく、装置アプリケーションから装置アプリケーションへと送受信することができるようにする広域なインフラストラクチャを構成する。本発明は、新しい装置の種類とアプリケーションデータの形式の速やかな組み込みを提供することによって、新規の装置が開発されたときに、既存の装置と新規の装置との間で効果的にデータ共有を行うことを可能とする。この能力は、既存のアプリケーションベンダーが、新規装置の直接的なサポートを実装コードに組み込む必要がないこと、また、新規の装置のベンダーも通信したい他のそれぞれの装置の種類とアプリケーションに対するサポートを組み込む必要もないことを保証する。
【００１０】
最後に、本発明は、既存のコンピュータアプリケーションベンダーに、既存のソースコードに対して重大な変更を加えることなしに、無線装置からまたはそれに向けて、データを伝送する能力を提供するものである。
【００１１】
発明の理解をさらに助けるため、添付した図面は発明の特定の特徴を記載している。添付した図表の簡単な説明は後で記載する。
【００１２】
【発明の実施の形態】
この発明のひとつの目的は、装置ベンダーとアプリケーション開発者が、継続的で高価な変更をその生産ラインに加えることなく、内部操作(interoperate)することができるようになる安定したインターフェースを提供することである。この発明の主な利点は、装置やアプリケーションの開発者が、情報を共有する装置が使用するプロトコル、データフォーマットまたはアプリケーションセマンティクスがどれであるかについての詳細に関与することなく、サービスとして利用できるようなインターフェースとインフラストラクチャを提供することである。この発明は、プロジェクトの最初からその認識と定義を要求するというよりはむしろ、利用可能になりかつ関心を持ったときに、新しいプロトコルとデータフォーマットを組み込むことを提供するものである。
【００１３】
本発明は、送信元Ｓから送信先Ｄへ情報を移すための手段と装置を含んでいる。ここで、ＳとＤは異なるデータ形式を有しており、それぞれのインターフェースでは異なるプロトコルを用いている。本発明は、Ｓからのデータを受け取り、データ形式Ｆｓをもつ送信元の装置の種類とデータフォーマットＦｄをもつ送信先の装置の種類とを判定する。本発明は、入ってくるデータをＦｓからＦｄへ変換し、新しい形式ＦｄのデータをＤへ移す。ここでは、本発明の完全な理解を提供するために、特定の項目、特定のプロトコルの種類、特定の構造を記述する。しかしながら、当業者は、レコードや配列のようなよく知られたソフトウェアの構成概念に精通しているので、本発明の理解の妨げとなるのを避けるために、この中ではそれらの詳細については述べない。同様に、通信プロトコルに関する当業者は、内部プロトコル形式とその詳細によく精通している。そのため、本発明は、それらのプロトコルやフォーマットをサポートしているが、詳細についてはここでは述べない。当業者は、これらの特別な詳細な説明なしで本発明を実施することができることを理解されたい。
【００１４】
図１は、本発明がサポートできるインターフェースの一般的な種類を図示したブロック図である。図１で示されている典型的な無線ネットワーク８は、ワイアレス・アプリケーション・プロトコル（ＷＡＰ）を用いている。ＷＡＰは、ＷＡＰフォーラムや無線装置製造会社の協会や無線電話事業者やその他の無線通信と装置産業の会社によって規格化された無線通信プロトコルの標準である。ＷＡＰ標準は、アンブレラスタンダード(umbrella standard)であると考えられ、実際その中に、様々な無線のアプリケーションや装置の種類に特有である一連のＷＡＰフォーラム認定の仕様を含んでいる。ＷＡＰ１．１技術仕様書(The WAP 1.1 Technical Specifications)は、以下の仕様を含んでおり、それらを引用することにより、あらゆる目的のために、その内容が本件出願に組み込まれている。
【００１５】
・Wireless Application Protocol Architecture Specification dated 4/30/98
・Wireless Application Environment Overview, dated 6/16/99
・Wireless Application Environment Specification, dated 5/24/99
・Wireless Markup Language Specification, dated 6/16/99
・Binary XML Content Format Specification, dated 6/16/99
・WML Script Language Specification, dated 6/17/993
・WML Script Standard Libraries Specification, dated 6/17/99
・WML Script Statement of Intent, dated 4/30/98
・WAP Caching Model Specification, dated 2/11/99
・Wireless Session Protocol Specification, dated 5/28/99
・Wireless Transaction Protocol Specification, dated 6/11/99
・Wireless Datagram Protocol Specification, dated 5/14/99
・WAP over GSM USSD Specification, dated 5/31/99
・Wireless Control Message Protocol Specification, dated 5/14/99
・Wireless Transport Layer Security Specification, dated 2/11/99
・Wireless Telephony Application Interface Specification, dated 5/31/99
・Wireless Telephony Application Interface Specification, GSM Specific Addendum, dated 2/10/99
・Wireless Telephony Application Interface Specification, IS-136 Specific Addendum, dated 4/30/99
・Wireless Telephony Application Interface Specification, PDC Specific Addendum, dated 4/30/99
【００１６】
これらの仕様のコピーは、インターネットの www.wapforum.org/what/technical.htmで手に入れることができる。
【００１７】
図１を参照すると、本発明に係るメッセージの送信元と送信先は、人間/機械のインターフェース(man/machine interface)１０を有している。必要とする装置の種類によって、人間/機械のインターフェースは、キーボードでもよく、ナンバーパッド、コントロールパネル、モニター、インジケーターライト、スイッチパネル、また一般的に、情報を入力したり、操作するオペレーターやユーザーに画面を表示したりするようなメカニズムのものでもよい。図１に示されている典型的なＷＡＰベースの無線ネットワーク８において、人間/機械のインターフェース１０は、ＷＡＥエージェント１２とＷＴＡユーザーエージェント１４と連結されている。ＷＡＥエージェント１２は、無線アプリケーション環境の要素であり、ＷＡＥエージェントの機能は、上記の無線アプリケーション環境概要(Wireless Application Environment Overview)と無線アプリケーション環境仕様(Application Environment Specification)に記載されている。同様に、ＷＴＡユーザーエージェント１４は、テレフォニーアプリケーションインターフェース(Telephony Application Interface)の要素であり、その機能は先に列挙したテレフォニーアプリケーションインターフェース仕様の中に記載されている。一般的に、これらのネットワーク要素は、汎用無線装置や無線電話装置との相互作用をサポートする。完全にするという理由のみで、図１には、この他に、リポジトリ１６、ネットワーク層２０、モバイルネットワーク２６、ＷＡＴサーバー２４、そして、本発明が接続するＷＡＰネットワークの入り口のＷＡＰゲートウェイ２２を含むＷＡＰベースのネットワークの一般的な要素も示されている。これらのＷＡＰネットワーク要素をより詳細に知りたい場合は、先に列挙した仕様書、特に、Wireless Application Environment Overview、Wireless Application Environment Specification、Telephony Application Interface Specificationを参照されたい。これらの仕様書や先に列挙した他のＷＡＰの仕様は、特徴や機能や様々なネットワークの要素と機能とのインターフェース（そのいくつかは図１に示されている）に関係した詳細を提供している。
【００１８】
本発明の好適実施例である汎用通信プロトコル変換機は、図１中のブロック３２に示されており、ＷＡＰゲートウェイ２２と、直接またはファイアーウォール２８を介してイントラネット２９またはインターネット３０に対しての両方向のインターフェースとを有している。図１で示されているように、プロトコル変換機３２は、多数のプライベート送信元(private source)２７とプライベート送信先(private destination)２４に対する一方向または両方向のインターフェースを持っている。
【００１９】
プロトコル変換機３２は、例えばＷＡＰゲートウェイ２２、（直接またはファイアーウォール２８を介して）インターネット３０またはイントラネット２９あるいは潜在する多様なプライベート送信元２７のような送信元からメッセージを受け取り、そのメッセージを変換し、さらにそれをＷＡＰゲートウェイ２２、インターネット３０、イントラネット２９、プライベート送信元２７、またはブロック３４で示されているプライベート送信先のいくつかに対して、転送することが可能である。
【００２０】
ＷＡＰゲートウェイから受け取るメッセージは、上記の仕様によって定義されている一つまたはそれ以上のＷＡＰプロトコルに符号化されやすい。図１で示されているその他の潜在するメッセージ送信元から受け取るメッセージは、次の例のプロトコルのいずれかであってもよい。
【００２１】
・分散プロセスコントロールプロトコル（ＤＰＣＰ）、またはそれに似たパフォーマンスのためにカスタマイズされ、どこにも一般的な目的の無いような、固定的で特別であり、しばしば専用のプロトコル。
・ＴＣＰ／ＩＰやNetware、wireless ASCII、またその他のプリンタープロトコルを含むかなり特別で専用なプロトコル。
・モバイルアプリケーションリンク、すなわちＭＡＬプロトコルというＰＤＡ装置の分類に関連するオープンなプロトコルである。これは、基本的なファイル転送メカニズムとして、ＴＣＰ／ＩＰとＨＴＴＰを用いるかもしれないが、送信先装置に適合するためのアプリケーションデータの変換を扱っていない。
・その他のオープンまたは専用のプロトコル。
【００２２】
この可能性のあるプロトコルのリストは、本発明がサポートできる入力メッセージのプロトコルと出力メッセージプロトコルの種類の網羅的なリストというよりむしろ、ひとつの例を意図している。入力メッセージのプロトコルの認識は、特定のポート接続を特定のプロトコルに割り当てることで行われる。言い換えれば、ある特定のポートでメッセージを受け取ったとき、本発明はメッセージを受け取り、以下により詳細に記述するように、適切に経路を決める。
【００２３】
プロトコル変換機がメッセージを受け取ることができるプライベート送信元２７とメッセージを転送することができるプライベート送信先３４は、プロトコル変換機が確定することのできる通信能力を持ち、プロトコル変換機と意味のある情報をやり取りできるような装置である。プライベート送信元２７とプライベート送信先３４は、先に列挙したプロトコル例のような専用のプロトコルまたはオープンのプロトコルを用いて通信する装置を表すことを意図している。言い換えれば、本発明は、電子装置に対して、その言語が装置に特有な専用言語、または様々な装置やその種類で用いられているより標準な言語であるとき、その独自の言語で電子装置に接続し直接通信することができる。この詳細の背景として、「プライベート」である送信元と送信先は、装置特有のやり方で通信する装置を意味し、その装置の通信インターフェースは、ＷＡＰやコンピューターのプライベートネットワークやインターネットを使用していない。
【００２４】
図２は、本発明の好適実施例に係る高レベルの機能フローを表した図である。スタートアップ６０では、本発明は情報を受け取り変換する準備として、例えばメモリの割り当てやネットワークインターフェースの初期化のような一般的な保守や管理を行う。ステップ６２において、本発明はメッセージを受け取る。メッセージを受け取った後に本発明が最初に行う動作は、ステップ６４で入力メッセージを受け取るために用いるプロトコル（「送信元プロトコル」）を決定することである。上記のように、これは特定のポート接続を特定のプロトコルに割り当てることによって行う。ステップ６６において、本発明は、送信元プロトコルが既知のものであるかどうかを決定する。既知のものでなければ、本発明はブロック６８へと進み、そこに列挙されているタスクを行う。一方、送信元プロトコルが既存のプロトコルであるなら、本発明はメッセージに関する作業を継続する。
【００２５】
ステップ７０では、本発明は、ターゲット（目標の）装置（送信先装置）を入力メッセージから確定することができるかどうか判定する。もし、ターゲット装置が入力メッセージから確定できなければ、本発明は、ステップ７２において、既定の（デフォルトの）ターゲット装置を選択し、入力メッセージから（もしあれば）すべてのグラフィックスを取り除く。ターゲット装置が確定された（または、デフォルトのものが選択された）後、本発明は、ステップ７３で示されているように、出力メッセージの構成に関する作業を開始する。
【００２６】
本発明は、その後、ターゲット装置の通信プロトコルを認識できるかどうかを判定するために、ステップ７４へと進む。認識できる場合、本発明は、ブロック７８へ進み、ターゲット装置上のターゲットアプリケーションを決定できるかどうかを確認する。一方、本発明がターゲット装置に適したプロトコルを知らない場合は、ステップ７６でデフォルトの一般的なプロトコルを選択し、メッセージを規定に従って作成し、「ニア・ミス(near miss)」というログを残す。このログ機能の目的は、以下で説明する。
【００２７】
ブロック７８において、もしターゲットアプリケーションが既知である場合、本発明はメッセージを変換し送信するためにブロック８２へと進む。それに加えて、本発明は、（もし必要であれば）送信元に対して確認エコー(confirmation echo)を送り返し、メッセージを削除する。この時点で、本発明は、別の受信メッセージを処理する準備が整う。
【００２８】
図２で示された実施例では、本発明がブロック７８でターゲットアプリケーションを既知ではないと判定したとき、メッセージは８０で拒否され、その旨が送信元に伝えられる。また別の方法として、この時点でメッセージを拒否するというのではなく、本発明を実施する者がメッセージをブロック７４で決定したプロトコルへ変換することを選択し、ブロック７０で決定したターゲット装置にメッセージを送信してもよい。このアプローチは、事実上、ターゲット装置自身がメッセージを適切な内部アプリケーションへ誘導してくれると仮定している。
【００２９】
ブロック６８、７６、８０で示されているログの機能は、潜在的な分析のサポートとユーザーが将来のある時点で望むかもしれない動作の更新のために含まれている。例えば、もし分析ログが、ある特定の送信元プロトコルまたはターゲット装置/プロトコルが繰り返し出現しているが、繰り返し既知ではないとしてログ出力されていることを示していれば、これらのプロトコルのサポートを提供するために、調査及び本発明に対する更新と変更の可能性が示されているかもしれない。新規追加のプロトコルを組み込むための更新や変更の柔軟性と容易さを提供する本発明の特徴は、以下において図４に基づいてより詳細に述べる。
【００３０】
図３は、送信元と送信先の装置の両方が典型的な無線装置であるような例として描いたプロトコル変換機３２のブロック図である。典型的な無線装置９０は、メッセージを生成し、それはプロトコル変換機３２によって、ＴＣＰ／ＩＰソケットタイプのインターフェース１０４経由で受け取られる。ＴＣＰ／ＩＰソケットタイプのインターフェース１０４は、プロトコル変換機がサポートする入力のメッセージプロトコルのすべてに対するインターフェースを提供する。作図上の理由で、図３で示されるサポートされている入力のメッセージプロトコルは、無線アクセスプロトコル／Wireless Access Protocol (WAP)９４、Proprietary Protocols (Prop Prot)９６、９８、モバイルアプリケーションリンク／Mobile Application Link (MAL)９９、及び他の標準プロトコル (Std Prot)１００、１０２だけを含んでいる。当業者は、この明細書を読むかあるいは本発明を実施した後に、図３で示されている本発明がサポートする入力のメッセージプロトコルがただの作図上の目的であり、本発明がサポートできるプロトコルの網羅的なリストではないということを理解するであろう。
【００３１】
図３に戻って説明するに、受信機回線マネージャ(receiver circuit manager)９２は入力メッセージを受け取り、エラーとセキュリティの基本的なチェックを行い、受信機プロセスを初期化し、多数の受信機１０６のうちのひとつにメッセージを渡す。各受信機１０６は、それぞれ回線マネージャ９２からさらなる処理のためにメッセージを受け取り、以下に詳説する作業を行う。さらに、メッセージの送信先に向けられているとして指定されているメッセージキュー(message queue)108に、メッセージをいれる。
【００３２】
各受信機１０８は、それぞれ、入力メッセージのプロトコルを分類し、メッセージの内部構造に関する２つ目の通過チェックを行い、拒否のためにメッセージに対し適切なところに印を付け、その後、ルーティングのために（経路を定めるために）メッセージをキューに入れる。
【００３３】
メッセージキュー１０８は、すべての送信機、受信機、ルーター、変換プロセスの中で、メッセージキューとして振る舞いかつ同期化のための作業を行う。メッセージキュー１０８は、自己が管理するヒープ(heap)の中で、動的に大きくなったり縮んだりする。
【００３４】
メッセージルーター(message router)１１２は、送信元と送信先のタイプの属性を比較し、変換が必要かどうかを決定する。そして、適切なときに、メッセージをメッセージキュー１０８を介してコンバータ１１０へ送る。メッセージコンバータ１１０は、メッセージを分類し、それを適切な送信先形式へと変換する。メッセージコンバータ１１０は、ひとつのプロセッサ上で実行されてもよく、あるいは負荷分散のために多数のプロセッサに分散してもよい。さらに、メッセージの変換は、送信元と送信先の種類のために及び負荷とキューのバランスのために必要とされる場合には、全く同一の多数の変換プロセスから成るものでもよく、また異なる複数のプロセスからなるものでもよい。
【００３５】
一旦変換された後、メッセージは、どの送信先プロトコルがプロトコル変換機３２からメッセージを配送するために使われるかについて、ルーター１１２によって評価される。その後、ルーターは、再びメッセージキュー１０８を介して、メッセージを適切な送信機１１４へ転送する。図３に示されているように、本発明は、プロトコル変換機がサポートしている出力メッセージプロトコルと装置の種類に応じて、多数の送信機１１４を含んでもよい。送信機１１４は、送信先の装置とプロトコルが必要とする場合には、さらに、出力メッセージの物理的な伝送をサポートするのに適したすべてのハードウェアを含んでいる。
【００３６】
送信機１１４は、さらに、変換された出力メッセージを有線または無線インターフェースを経由して、送信先装置１１６へと送信する。
【００３７】
図４Ａから４Ｅは、１０個の判別回路を組み込んだ多次元有限状態オートマトンを用いた好適実施例におけるメッセージコンバータ１１０の変換と分類の機能を示している。この好適実施例は、インフラストラクチャに変更を加えることなく多数の将来のプロトコルや装置の種類やアプリケーション形式を組み込むことができる拡張可能かつ保守可能な設計となっている。また、新規のプロトコルや装置やアプリケーションは、ほとんどエラーをだすことなく追加することが可能で、従来の設計技術よりもより良い性能を達成することができる。
【００３８】
好適実施例としての状態機械オートマトン(state machine automata)の使用の重要な利点のひとつは、本発明を極限的に拡張可能とすることである。また、状態機械オートマトンのハードウェアの実装は、シリコンの中に配置可能であり、その結果、高速で信頼性のある変換方法が得られる。さらに、フラッシュメモリ技術を組み込むことで、シリコンはフィールドで「再プログラム」することができ、ユーザーが供給された更新を読み込むかあるいはそれ自身の改良を開発することができるようになる。それにもかかわらず、当業者は、この明細書を読んだ後または本発明を実施した後には、好適な有限状態オートマトンの実装を用いないハードウェアやソフトウェアの別の実装が、たとえ拡張性やパフォーマンスや変更容易性の点で有効でないとしても、本発明から逸脱することなく採用可能であることを認識するだろう。
【００３９】
同様に、当業者は、この明細書を読んだ後または本発明を実施した後に、この明細書が有限状態オートマトンをメッセージコンバータ１１０の中に完全に存在するものとして記述している一方で、有限状態オートマトン（または、同等のもの）の１つ以上のステージがメッセージルーター１１２の中に存在するようにすることも本発明から逸脱しないことを理解するであろう。
【００４０】
多次元有限状態オートマトンに対する入力は、以下のものを含む。
・入ってくるメッセージのメモリブロックとアドレス
・オートマトンの現在の状態
・入ってくるメッセージが到着するときに用いられるプロトコルの種類
・入ってくるメッセージが生じた装置の種類
・入ってくるメッセージが生じたアプリケーションの種類
・入ってくるメッセージが生じた形式の種類（しばしば、アプリケーションの種類によって暗に示される）
・両方の装置の接続状態（接続/非接続、オンライン、オフライン）
・出て行くメッセージが送られるときに用いられなければならないプロトコルの種類
・出て行くメッセージが送られる装置の種類
・出て行くメッセージが変形されなくてはならないアプリケーションの種類
・出て行くメッセージが変形されなくてはならない形式の種類
【００４１】
図４Ａに戻って、多次元有限状態オートマトンの最初のステージ１２０は、プロトコルの判別手段である。プロトコルの判別手段のステージ１２０は、接続状態１２２、送信元プロトコルの種類１２４、そして送信先プロトコルの種類１２６に基づいた３次元マトリクスからプロトコルアクションインデックス(action index)１３８を選択する。
【００４２】
プロトコルアクションインデックス１３８は、“ｘ”、“ｙ”及び“ｚ”の形式のプロトコル変数に一致する整数か識別子である。ここで、“ｘ”は本発明と送信元もしくは送信先の装置との間の接続の状態を示す整数又は識別子を含んでおり、“ｙ”は同様の送信元プロトコルのカテゴリと関係した整数又は識別子を含んでおり、“ｚ”が送信先プロトコルのカテゴリに関係する整数又は識別子を含んでいる。
【００４３】
プロトコルアクションインデックス(protocol action index)が選択される手順を説明するために、ユーザーがＰＣ(Personal Computer)上の住所録アプリケーションを使ってＰＤＡ中の住所録を更新する例を考える。この例において、前提として、ユーザーの住所録アプリケーションはＰＤＡの組み込み機能によって対応されていないこととし、そのため、本発明は２つの装置間の通信を容易にすることが要求されるとする。以下のプロトコルカテゴリの不完全なリストは、本発明の実施例においてサポートされていると仮定する。
【００４４】
1.Wireless Access Protocol (ＷＡＰ)
2.Mobile Application Link (ＭＡＬ)
3.DPCP(Proprietary binary protocol)
4.Internet Presence Protocol (ＩＭＰＰ)
5.RSVP (a common receive/respond protocol)
6.Starfish Software TrueSync Protocol
7.Application-specific proprietary protocol A
8.Application-specific proprietary protocol B
9.Client-specific proprietary protocol A
10. Application-specific proprietary protocol B
【００４５】
本発明では、入力されたメッセージからソースプロトコル１２４と送信先プロトコル１２６を決定し、その後プロトコル変数のｙ及びｚコンポーネントを確定するために適切なプロトコルカテゴリを選択する。前記例を用いて説明するに、ユーザーのコンピューター(送信元装置)上の住所録アプリケーションは、アプリケーションに特化した私有プロトコル(application-specific proprietary protocol)Ａ(前述リストの７番目)に似た特徴を持つプロトコルを利用し、ＰＤＡはアプリケーションに特化した私有プロトコルＢ(前述リストの８番目)に似た特徴を持つプロトコルを利用すると仮定する。送信元装置とターゲット装置は、両方とも変換機に接続されており、接続状態(connection status)が"１"であるとする。また、プロトコル変数"１，７，８"に対応するプロトコルアクションインデックスは"１２"であると仮定する。言い換えると、この例では、"アプリケーションに特化した私有プロトコルＡ"のプロトコルカテゴリに属すプロトコルを利用する送信元装置が"アプリケーションに特化した私有プロトコルＢ"のプロトコルカテゴリに属すプロトコルを利用する送信先装置と通信することを希望しかつ両装置が現在接続されている場合、本発明はプロトコルアクションインデックス"１２"を選択することを意味する。
【００４６】
各プロトコルカテゴリは、それぞれ単一のプロトコルか複数の同様なプロトコルから構成される。好適実施例においては、重要度の高い順に並べられた以下の基準に基づいて２つのプロトコルが"同様"であるとみなされ、ともに単一のカテゴリ("アプリケーションに特化した私有プロトコルＡ"など)に分類される。
【００４７】
1.ASCII/unicodeで符号化されたコンテンツ対バイナリデータ
2.同一のヘッダー
3.マークアップ言語における同じ記述子の集合
4.同じ基本構造(例えば、ヘッダーとボディー)
5.同様に分解できる正規表現
【００４８】
通信プロトコルに精通している当業者は、本発明の確かな動作を達成するために、本発明を実施する者が、特別な実装において、これらの基準の1つあるいはそれ以上を削除したり、重要度の順を変更したり、ここに挙げていない他の基準を追加したりすることができることを理解するであろう。前記リストは、一般的な変換能力を実現することができる好適実施例である。また、本発明から逸脱することなく、他のプロトコルカテゴリや他の手法を導入することもできる。
【００４９】
同様に、本発明を実施する者は、接続状態(connection status)の入力として様々な状況を想定することができる。例えば、好適実施例では、１つの接続状態識別子を送信元装置とターゲット装置とが共に現在接続されていることを示すために割り当てることができるし、また送信元装置は接続されているがターゲット装置が接続されていないことを示すために他の識別子を割り当てることができるし、さらに送信元装置は接続されていてターゲット装置は接続されていないが未来の適当な時点(例えば、ターゲット装置がワイヤレス装置であり、それを使って送信機１１４がＷＡＰゲートウェイ２２を介して接続を確立したかもしれない場合)に接続することが可能であるということを示すために他の識別子を割り当てることができる。この実施例では、他のすべての入力は等価であり、本発明はターゲット装置の接続状態に基づいて３つの異なる動作を選択することができる。
【００５０】
最終的に、当業者は、前記プロトコル変数の３つのコンポーネントの順番は重要でないということを認識するであろう。換言すると、"ｘ"が送信先プロトコルカテゴリ識別子を表し、"ｙ"がコネクションリンク状態を表し、"ｚ"がソースプロトコルカテゴリ識別子を表す場合、"ｘ、ｙ、ｚ"という形式のプロトコル変数は本発明から逸脱するものではない。これは、以下において有限状態オートマトンの各ステージの説明との関係で述べる３つのコンポーネント変数(three-component variables)のそれぞれに対しても正しいものである。
【００５１】
図４Ｂは、多次元有限状態オートマトン(poly-dimensional finite state automaton)１４０の２番目のステージを表す。この２番目のステージ１４０は、装置識別手順であって、そこでは、１番目のステージ１２０で決定されたプロトコルアクションインデックス１３８、送信元装置のタイプ(source device type)１４２及び送信先装置のタイプ(destination device type)１４６から三次元マトリクスを用いて装置インデックス(device index)１４８が選択される。この送信元装置のタイプ１４２は、メッセージを受信する接続ポート(connection port)から求められる。また、送信先装置のタイプ１４６は、使用される実装に応じて、様々な要因で決定される。例えば、使用される送信元（ソース）プロトコル(source protocol)によっては、送信先装置は、ＨＴＴＰヘッダーの中でＵＲＬ形式の命名規則によって特定（識別）してもよく、あるいはメッセージのヘッダーやボディー中にあってもよい。
【００５２】
装置インデックスは、"ｘ,ｙ,ｚ"という形式の装置変数を表す整数あるいは他の識別子である。ここで、"ｘ"が前記プロトコルアクションインデックスを含み、"ｙ"が同様な送信元装置のカテゴリに関連付けられた整数あるいは他の識別子を含み、"ｚ"が同様な送信先装置のカテゴリに関連付けられた整数あるいは他の識別子を含む。好適実施例においては、２つの装置が同じタイプのデータを受け取る場合に"同様"であるとみなされ、ともに単一のカテゴリに分類される。例えば、本発明の実施例は、装置インデックスのｙ,ｚコンポーネントを含む以下のカテゴリを有するようにしてもよい。
【００５３】
1.ASCII文字のみを許容する装置
2.解像度(resolution)Ａのビットマップ(bit-mapped)を許容する装置
3.解像度(resolution)Ｂのビットマップを許容する装置
4.Nokia 9000ilのような装置
5.Symbianの装置
6.Palm Pilotファミリーの装置
【００５４】
もちろんこのリストは、説明の目的のためだけのものであり、本発明が対応可能な装置の完全なリストではない。さらに、当業者は、本発明を実施する者は、本発明から逸脱することなく、装置を"同様"であると分類するためにデータの類似性に加えてあるいはその代わりに他の基準を導入することができることを理解するであろう。
【００５５】
前記実施例に続いて、有限状態オートマトンの２番目のステージは、ｘ,ｙ,ｚという形式の装置変数を表す装置インデックスとして"６"を選択する場合がある。この場合、ｘのプロトコルアクションインデックスは"１２"(前のステージで選択されたもの)となり、ｙの送信元装置タイプのカテゴリ(source device type category)は"３"(送信元装置として適当なＰＣ)となり、ｚの送信先装置タイプのカテゴリ(destination device type category)は"６"(ターゲット装置に相当するＰＤＡ)となる。
【００５６】
図４Ｃの多次元有限状態オートマトンで表される３番目のステージ１５０は、アプリケーション識別手順である。このアプリケーション識別ステージ１５０は、前のステージ１４０で決定された装置インデックス(device index)１４８、送信元アプリケーション識別子１５２、送信先アプリケーション識別子１５６から三次元マトリクスを用いてアプリケーションインデックス１５８を選択する。送信元アプリケーション識別子１５２及び送信先アプリケーション識別子１５６は、ともに入力されたメッセージを元に決定される。これまでのインデックスと同様に、アプリケーションインデックスはｘ，ｙ，ｚという形式の変数に対応する整数である。ここで、ｘが前のステージ１４０で決定された装置インデックス１４８であり、ｙ及びｚがそれぞれ送信元アプリケーションとターゲットアプリケーションとして適切なアプリケーションカテゴリに対応するカテゴリ識別子である。送信元アプリケーションとターゲットアプリケーションは、以下のカテゴリを含むことができるが、これらに限定されわけではない。
【００５７】
1.XML
2.HTML
3.HDML
4.Text
5.EPOC
6.FAT16
7.ハンドヘルド装置(handheld device)上の予定表やカレンダータイプのアプリケーション
8.ハンドヘルド装置上のデータベースタイプのアプリケーション
9.モバイルアプリケーションリンクデータベースアプリケーション(Mobile Application Link database application)
10.ＷＡＰ (Wireless Access Protocol)ファイル構造を利用するアプリケーション
【００５８】
好適実施例においては、二つのアプリケーションがアプリケーションの最小で完全なデータ表現をカプセル化するためにレコード、ファイル、その他のオブジェクトを記述するのに同じ形式（フォーマット）を用いる場合、これらの２つのアプリケーションが同様であるとみなされ、ともに単一のカテゴリに分類される。前述した他のステージと同様に、本発明を実施する者(practitioner)は、本発明から逸脱することなく、本発明の特別な振る舞いに関するデザイナーのゴール(designer's goals)に基づいて、同様なアプリケーションを分類するための他の基準を選ぶことができる。
【００５９】
図４Ｄは、フォーマット識別を行うための多次元有限状態オートマトンで表される４番目のステージ１８０である。このフォーマット識別ステージ１８０は、前のステージ１５０で決定されたアプリケーションインデックス１５８、送信元フォーマットタイプ(source format type)１６２、送信先フォーマットタイプ(destination format type)１６６から三次元マトリクスを用いてフォーマットインデックス(format index)１６８を選択する。送信元フォーマットタイプと送信先フォーマットタイプの双方は、ともに入力されたメッセージを元に決定される。このフォーマットインデックスは、"ｘ、ｙ、ｚ"という形式のフォーマット変数(format variable)を表す整数あるいは識別子である。ここで、"ｘ"が前のステージ１５０で決定されたアプリケーションインデックス１５８であり、"ｙ"が送信元データフォーマット(source data format)を含むデータフォーマットカテゴリ(data format category)に対応しており、"ｚ"がターゲットのためにデータが整形されなくてはならないデータフォーマットカテゴリに対応する。データフォーマットカテゴリは、以下のデータフォーマットを含むことができるが、これらに限定されるわけではない。
【００６０】
1.１バイト文字データ
2.２バイト文字データ
3.符号なし３２ビット整数
4.リトルエンディアン(Little Endian)
5.ビッグエンディアン(Big Endian)
6.符号付き３２ビット整数
7.IEEE浮動小数点数
8.６４ビット整数
【００６１】
最後に、図４Ｅは、アクション選択を行うための多次元有限状態オートマトンで表される最後のステージ１７０である。このアクション選択ステージ１７０は、オートマトンの"アクション"と呼ばれる最終出力１８０を選択する。このアクション１８０は、ターゲット、その送信元、メッセージのコンテンツを生成するアプリケーション及び協働動作する装置の接続状態に基づいて入力されたメッセージを修正するために汎用プロトコル変換機３２によって使用される一連の実行可能な命令からなる。アクション１８０は、これに限るわけではないが、何もしない命令、入力されたメッセージを修正する命令、送信先装置にメッセージを送る命令、入力されたメッセージを破棄する命令、指示されたメッセージのコンテンツの変換を行う命令または送信元装置にメッセージを送る命令を含むことができる。さらに、アクション１８０は、送信元の割り当てや開放や情報の記録(logging information)などの内部の補助的な命令を含むこともできる。
【００６２】
このアクション１８０と有限状態オートマトンの次の状態１７８は、前のステージ１８０で決定されたフォーマットインデックス１６８や有限状態オートマトンの現在の状態や今後使用される可能性がある未割当変数１７６から選択される。未割当変数１７６は、本発明が十分な自由度、速度及び長期の保守性を達成するために、図４に示された好適実施例に含まれている。変数１７６が割当されない場合、アクションセレクター１７９は、フォーマットインデックス１６８とオートマトンの現在の状態１７２の関数としてアクション１８０と次の状態１７８が選択される二次元マトリクスを含むことができる。しかしながら、未割当変数１７６にインデックスや他の値を割り当てることで、追加のアクション１８０と次の状態１７８を定義しかつ選択することができる。
【００６３】
本発明の好適実施例では、多次元有限状態オートマトンの様々なステージを経た結果、これらのアクションの１またはそれ以上を選択する。図４Ｅから明らかなように、変数１７６は、選択されるアクションがこれらのアクションの１またはそれ以上のアクションあるいは新たなアクションとなるように、定義することができる。
【００６４】
変数１７６は、変換機のコード設計時に、知識を要求するというよりはむしろ、進化的なやり方でサポートされたプロトコルやデータフォーマットセットの拡張をする方法を提供する。ソフトウェアへの変更が必要な唯一の状況は、新たなデータ型(例えば、浮動小数点数、整数、文字列、ASCIIなど)が定義されたときなどの全く新しい形態の変換が必要となったときである。最終的に、図４Ａから図４Ｅは、前のステージの結果を用いて順に操作をしていく多次元有限状態オートマトンの様々なステージを表しているが、本発明を実施する者は、他の実装を採用してもよい。例えば、本発明を実施する者は、図４Ａから図４Ｅのように、実行時に決定されていない予め定義された入力を使用して、様々なステージの中の1つあるいはいくつかのステージを単独であるいは一緒に採用することができる。また、当業者は、図４Ａから図４Ｅのようにステージをパイプライン状に使うことがより自由度を高めロバスト性が高い設計であるだけでなく前衛的な取り組みとなることを認識するであろう。
【００６５】
図４Ａから図４Ｅが本発明の振る舞いの静的な部分を表しているのに対して、図５Ａと図５Ｂは、図２と同様のより詳細な状態駆動(state driven)の観点から本発明の振る舞いの実行時の動的な部分を表している。
【００６６】
図５Ａにおいて、本発明は１９０で初期化される。この初期化は、ネットワーク管理者あるいは同等の権限をもつ者あるいは"run"実行文を実行するプログラム２００によって起動される。初期化の際に本発明はブロック１９０に挙げられた機能を実行する。
【００６７】
初期化が終了すると、本発明は"await message"（メッセージ待ち）状態１９２に移行する。"await message"状態において、本発明は、メッセージの受信に成功して待機状態が変更されるまで待つ。メッセージが到着すると、本発明は受信したメッセージを前段階で初期化された内部のアドレス空間(local address space)に対応付ける"await queue"状態１９４に移行する。その後、本発明は、図２で示したようにメッセージを評価する。図２で示したように、図５Ａの２０４において、入力されたメッセージのプロトコルが不明の場合、メッセージは破棄され、破棄が記録され、本発明は"await message"状態１９２に移行する。一方、送信元プロトコルが認識された場合、メッセージは２０８に示されたように処理される。
【００６８】
図５Ａで示されるように、ステップ２０６で実行される機能の１つは、送信元装置とターゲット装置を特定することである。送信元装置が不明の場合、本発明はステップ２１０のように標準の送信元装置を選択してメッセージの処理を続行する。ターゲット装置が不明の場合、好適実施例においては、本発明はステップ２０８のように入力されたメッセージをテキスト形式に変換し、最小公約数のような"best effort"条件として(as a lowest common denominator "best effort" condition)標準の（デフォルトの）ターゲット装置を選択する。本発明は、内部のワークキュー(work queue)中のすべてのメッセージが処理されるまで、ステップ１９４の"await queue"状態に留まる。その後、本発明は、状態機械(state machine)用の"既知"の装置として標準（デフォルト）の装置を継続する。それは、ステップ２１２において実行されかつステップ２１２において獲得されるアクションである。
【００６９】
いくつかの状況においては、本発明を実施する者は、前記デフォルトのアクションを無視し、メッセージを破棄し、失敗を記録し、メッセージキュー(message queue)を空にして、ステップ１９２の"await message"状態に移行することを選択することができる。同様に、本発明を実施する者は、ステップ２０６において、ターゲット装置の接続状態を決定することができる。送信先装置が接続されておらず、送信先装置が未来の適当な時点で接続されるかどうかを本発明が決定できない場合、本発明を実施する者は、性能向上のために、入力されたメッセージを破棄し、キューを空にし、かつ適切な情報を記録し、そしてステップ１９２の"await message"状態に移行することを選択することができる。
【００７０】
図５Ａに関してさらに説明するに、送信元装置とターゲット装置の種類が既知の場合(あるいは前記ように標準のものが選択された場合)、本発明は図４Ａから図４Ｅで示すようにステップ２１２に進み、多次元有限状態オートマトンを実行するとともにアクションを取得する。ターゲット装置、プロトコル及びアプリケーションが既知の場合は、構文解析が成功し、メッセージを送信先フォーマットへ変換するの用意がなされる。その後、入力されたメッセージは、図５ＢBのステップ１９６，２１６，２１８において解析されかつ変換される。そして、本発明は、send message状態（メッセージ送信状態）２１８に移行し、ステップ２２０で示されているようにメッセージ送信に関連付けられたタスクを実行する。送信先メッセージが送信された後、本発明はステップ１９２の"await message"状態へ移行する。
【００７１】
一方、ターゲットアプリケーションが決定できず解析が成功しないことがある。ステップ２１４は、この状況を示す。好適実施例では、ターゲットアプリケーションが不明の場合、本発明はメッセージを破棄し、適当な情報を記録し、そしてそのターゲット装置やアプリケーションに関連するこれ以降のメッセージをキューから取り除き、ステップ１９２の"await message"状態に移行する。
【００７２】
当業者は、ターゲット装置やターゲットプロトコルを確定できない場合にテキスト表現のメッセージを送信することを除いて、本発明から逸脱することなくアクションを選択することができることを理解するであろう。同様に、本発明を実施する者は、ターゲット装置とプロトコルが既知だがターゲットアプリケーションが確定できない場合に、(前記ようにメッセージを破棄するのではなく)メッセージを送信することを選択してもよい。また、当業者は、これらの変更は本発明から逸脱することなく実行できるということを理解するであろう。
【００７３】
前記説明や図５Ａ及び図５Ｂから明らかなように、ブロック２２２，２２４，２２８は、発明の操作とは非同期に発生するエラーやシャットダウンの状況を表している。これらの状況のすべてにおいて、本発明は、現在の状態から終了状態に遷移することとなる。すなわち、ブロック２２６はワークキューが空の場合(入力されたメッセージがすべて処理されて送信されたかあるいは破棄された場合)、本発明がステップ１９２の"await message"状態に遷移することを表している。
【００７４】
以下のコードは、説明の目的だけものであるが、本発明のハイレベルな作用を表している。この例では、本発明の主要な機能を分かりやすく説明するために、特定のメモリ管理手法などのローレベルな詳細は省かれている。当業者は、これらの詳細を補う様々なよく知られた方法に精通し、それを実現できるだろう。以下に示すハイレベルなコードは、次の一般的な機能や本発明の特徴の好適な実施（実装）を含んでいる。
【００７５】
・ネットワーク接続管理
・メッセージ破棄（拒絶）
・データフォーマット変換
・メッセージヘッダー変換
・メッセージコンテンツ変換
・メモリ管理
・エラー報告
【００７６】
コードの例を以下に挙げる。
/* Sense environment (e.g. memory available, O/S version, processor, I/O ports available) */
/* Set up I/O ports based on configuration details */
/* Initialize memory region for gateway */
/* Initialize status and other internal structures for logging purposes */
/* Allocate screen region on any console device for interactive status logging */
/* Spawn master circuit process */
/* Spawn receiver and sender processes */
/* Create internal queuing mechanism */
/* Spawn traffic router function */
/* Create synchronization elements */
/* Await first message */
/* Repeat the following forever */
check wait status: /*Wait not satisfied, continue waiting */
/* Wait satisfied, determine why based on wait status */
switch wait status: /*map received message into local address space */
Do_nothing: /* take no action */
Establish_circuit: /* save requisite identifier information, formally accept connection, spawn new receiver task
and hand off connection */
Destory_circuit: /* Deallocate socket id, clean up memory */
Build_rejection: /* allocate memory, copy base header to reply, upgrade status fields,
enqueue message for sending */
Build_target: /* Allocate memory, fill in base fields from originate message,
enqueue message for parsing */
ASCII_Big_Little: /* Transform big-endian into little endian format */
ASCII_Little_Big: /* Transform little-endian into big-endian format */
Map_headers: /* Based on device type, app type, protocol type, transform
necessary fields from source message into appropriate destination
fields */
Map_content: /* Based on device type, app type, protocol type, transform
content               data into destination content body*/
Allocate_memory: /* Calculate requisite destination memory size and allocate it */
Free_memory: /* Return used space to local heap */
Send_Msg: /* Send message to destination. Log any errors. */
Update_State: /* assign current state to n+ext state value */
Otherwise: /* unknown action and thus internal state machine error. Log serious
error to console and log file */
Buffer_overflow: /* Log failure to log file and console */
Otherwise: /* Log failure to log file and console */
/* end switch on wait result */
【００７７】
要約すれば、本発明は汎用プロトコル変換手法と送信元装置から情報を受信し、必要なら変換を行い、送信先装置に提供する仕組みを含む。汎用プロトコル変換機は、ソケットのようなインターフェスを持つ受信機回路マネージャ、１つあるいはそれ以上の受信機、１つあるいはそれ以上のコンバータ、メッセージルーター(message router)、及び１つあるいはそれ以上の送信機を含む。好適実施例では、メッセージコンバータは、1つあるいはそれ以上の入力変数から出力を得る関数として振る舞うマトリクスからなるステージを持つマルチステージパイプライン有限状態オートマトン(multi-stage pipelined finite state automaton)を用いて入力された情報を送信先フォーマットおよびプロトコルに変換する。好適実施例では、オートマトンのステージには、プロトコル識別ステージ、装置識別ステージ、アプリケーション識別ステージ、フォーマット識別ステージ、及びアクション選択ステージを含む。アクションセレクターによって選択されるアクションは、何もしないアクション、入力されたメッセージを修正するアクション、送信先装置にメッセージを送るアクション、入力されたメッセージを破棄する命令、送信元装置にメッセージを送るアクションを含むが、これらに限定されるわけではない。
【００７８】
本発明の他の実施例は、本明細書を検討するかあるいは開示された発明を実施した後に、当業者に明らかになるであろう。本明細書や例は、例示的なものであり、発明の正しい範囲は、請求項で示される。
【図面の簡単な説明】
【図１】  図１は、無線ネットワーク、有線コンピューターネットワーク、そして特定の送信元及び送信先装置を含む様々なインターフェースをサポートする本発明の能力を説明するブロック図である。
【図２】  図２は、本発明の好適実施例を用いた２つの装置間の伝送例の高レベルなシーケンスを表したフローチャートである。
【図３】  図３は、本発明の好適実施例のデータフローを表す高レベルな機能ブロック図である。
【図４】  図４Ａ−図４Ｅは、様々な通信プロトコルや装置のインターフェースを認識しかつ分類するために、また効率的な伝送のため情報を変換するために、本発明がどのように有限状態オートマトン技術を用いているのかを表現している。
【図５】  図５Ａ及び５Ｂは、状態をもとにした見地から、本発明の好適実施例の振る舞いを詳細に示したものである。
【図１】
0004668422.tif 000002
【図２】
0004668422.tif 000003
【図３】
0004668422.tif 000004
【図４】
0004668422.tif 000005
0004668422.tif 000006
0004668422.tif 000007
【図５】
0004668422.tif 000008
0004668422.tif 000009