(57)【要約】  通信ネットワーク（１２）は、２地点間暗号化キー（２７）を用いて、２地点間通信（２３、２５）に関連するトランザクション（６０Ａ、６０Ｂ）の第１部分（６３Ａ）を暗号化する。終点間通信に関連するトランザクション（６０Ａ、６０Ｂ）の第２部分（６５）は、終点間暗号化キー（４６）を用いて暗号化される。
2005515664.tif 000002
【特許請求の範囲】
【請求項１】
トランザクションのデータのチャンネルを独立して暗号化する方法であって、
第１のセキュリティアソシエーションを用いて、前記トランザクションの第１のデータチャンネルを暗号化するステップと、
第２のセキュリティアソシエーションを用いて、前記トランザクションの第２のデータチャンネルを暗号化するステップと、
各チャンネルに独自のセキュリティアソシエーションを用いて、前記トランザクションに含まれる任意の数の追加のデータチャンネルを暗号化するステップとを有することを特徴とする方法。
【請求項２】
前記第１のデータチャンネルは２地点間制御データからなり、前記第２のデータチャンネルは終点間コンテンツデータからなる請求項１に記載の方法。
【請求項３】
前記第１のデータチャンネルの制御データは、トランザクション認証とルーティング情報とを含み、前記第２のデータチャンネルの終点間コンテンツデータは、電子メールメッセージ、電子ファイル又は他の電子データのコンテンツを含む請求項２に記載の方法。
【請求項４】
モバイル機器と、前記トランザクションのための配送エージェントとして機能するサーバとの間で、前記第１のデータチャンネルの第１の暗号化キーとセキュリティアソシエーションとを取り決めるステップと、
モバイル機器と、前記トランザクションのための終点として機能するコンピュータとの間で、前記第２のデータチャンネルの第２の暗号化キーとセキュリティアソシエーションとを取り決めるステップと、
前記サーバと終点との間で、前記第１のデータチャンネルの第３の暗号化キーとセキュリティアソシエーションとを取り決めるステップとを更に有する請求項１に記載の方法。
【請求項５】
前記第１の暗号化キーを用いて、前記サーバで前記第１のデータチャンネルを復号化するステップと、
前記第３の暗号化キーを用いて、前記サーバで前記第１のデータチャンネルを再暗号化するステップとを更に有する請求項４に記載の方法。
【請求項６】
暗号化され、変更されていない前記トランザクションの前記第２のデータチャンネルを前記サーバに残すステップを更に有する請求項５に記載の方法。
【請求項７】
暗号化されていない前記トランザクションの第３のデータチャンネルを残すステップを更に有する請求項１に記載の方法。
【請求項８】
前記トランザクションの各項目を前記データチャンネルの一つに割り当てるステップと、
前記割り当てられたデータチャンネルに応じて、前記トランザクションの異なる項目を分離するステップと、
前記分離された項目をデータグループに符号化するステップと、
各データグループに対応するデータチャンネルに割り当てられた前記セキュリティアソシエーションを用いて、前記データグループのいくつか又はすべてを暗号化するステップと、
前記処理されたデータグループを１以上のパケットに符号化するステップとを更に有する請求項１に記載の方法。
【請求項９】
前記パケットを受信するステップと、
前記異なるデータチャンネルに応じて、前記パケットのコンテンツを分離するステップと、
既知のセキュリティアソシエーションに対応する分離されたコンテンツのみを復号化するステップと、
前記復号化されたコンテンツを項目に翻訳するステップと、
未知のセキュリティアソシエーションを持つデータチャンネルのコンテンツが暗号化され、変更されていないまま残っている間、前記翻訳された項目に応じて、前記トランザクションを処理するステップとを更に有する請求項７に記載の方法。
【請求項１０】
前記第１のセキュリティアソシエーションを用いて、暗号化されたデータのみを含む第１のパケットセットを符号化するステップと、
前記第２のセキュリティアソシエーションを用いて、暗号化されたデータのみを含む第２のパケットセットを符号化するステップと、
暗号化されていないデータを含み、前記第１のパケットセットと前記第２のパケットセットのデータサイズを識別するパケットヘッダを符号化するステップと、
前記第１のパケットセットを転送し、前記第１のパケットセットのすぐ後に、前記第２のパケットセットを転送するステップとを更に有する請求項１に記載の方法。
【請求項１１】
第１のセキュリティアソシエーションを用いて暗号化されたデータの第１部分と、第２のセキュリティアソシエーションを用いて暗号化されたデータの第２部分とを有するトランザクションを送受信するプロセッサを備えることを特徴とするコンピュータデバイス。
【請求項１２】
前記プロセッサは、モバイル機器、デスクトップコンピュータ、サーバ、もう一つの計算ノードのいずれかに位置する請求項１１に記載のコンピュータデバイス。
【請求項１３】
前記データの第１部分は、ネットワークを介して前記トランザクションを転送するために用いられる制御情報を含み、前記データの第２部分は、ファイル、ドキュメント、メッセージあるいはドキュメント要求を含む請求項１１に記載のコンピュータデバイス。
【請求項１４】
前記プロセッサは、終点に転送するための中間サーバに、前記トランザクションを送信し、前記中間サーバとのみ２地点間暗号化キーを取り決め、前記終点とのみ終点間暗号化キーを取り決める請求項１１に記載のコンピュータデバイス。
【請求項１５】
前記プロセッサは、前記トランザクションのデータ項目を異なるチャンネルに分離し、対応するセキュリティアソシエーションに応じて、該データ項目のチャンネルを個々に符号化及び暗号化する請求項１１に記載のコンピュータデバイス。
【請求項１６】
前記プロセッサは、前記トランザクションを、それぞれが同じ暗号化キーを用いて暗号化されたデータを含む多数のパケットに符号化する請求項１１に記載のコンピュータデバイス。
【請求項１７】
前記プロセッサは、第１の暗号化キーを用いて暗号化されたデータを含む第１のパケットセットと、第２の暗号化キーを用いて暗号化されたデータを含む第２のパケットセットとを識別するヘッダを生成する請求項１１に記載のコンピュータデバイス。
【請求項１８】
第１の既知の暗号化キーを用いて暗号化されたデータの第１部分と、第２の既知の暗号化キーを用いて暗号化されたデータの第２部分とを含むトランザクションを受信し、前記データの第２部分が暗号化されたまま残っている間、前記トランザクションをどのように処理するか決定するために、前記データの第１部分を復号化するサーバを備えることを特徴とするシステム。
【請求項１９】
前記トランザクションは、暗号化されていないデータの第３部分を含み、前記サーバは、前記暗号化されたデータの第１部分を前記暗号化されていないデータの第３部分と結合し、結合されたデータの第１及び第３の部分に応じて、前記トランザクションを処理する請求項１８に記載のシステム。
【請求項２０】
前記サーバは、第３の暗号化キーを用いて、前記暗号化されたデータの第１部分の少なくともいくつかを再暗号化し、新しいトランザクションを形成するために、再暗号化されたデータの第１部分を前記暗号化されたデータの第２部分と結合する請求項１９に記載のシステム。
【請求項２１】
２つの終点間で転送される際、それぞれが前記トランザクションの異なる処理を実行する多数のサーバであって、前記トランザクションが該多数のサーバ間で転送されるとき、２地点間暗号化キーを取り決め、該取り決められた暗号化キーを用いて、前記トランザクションの部分を暗号化する、多数のサーバを更に備える請求項２０に記載のシステム。
【請求項２２】
情報を暗号化する方法であって、
異なるセキュリティアソシエーションを持つトランザクションの異なる種類の項目を結合するよう、ネットワーク処理装置をプログラムするステップと、
前記ネットワーク処理装置で、種々の異なるトランザクションを処理するステップと、
セキュリティアソシエーションと、前記トランザクションの異なるチャンネルとを関連付けるステップと、
対応するセキュリティアソシエーションに応じて、前記トランザクションの項目を暗号化し、あるいは復号化するステップとを有することを特徴とする方法。
【請求項２３】
暗号化キーを含み、データチャンネルの少なくともいくつかと関連付けられる異なるセキュリティアソシエーションで、前記ネットワーク処理装置を構成するステップと、
暗号化された既知のセキュリティアソシエーションなしにチャンネルを保持する間、構成された暗号化キーに関連付けられた対応する既知のセキュリティアソシエーションを有するデータチャンネルから前記項目のみを復号化するステップと、
前記復号化された項目に応じて、前記トランザクションを処理するステップとを更に有する請求項２２に記載の方法。
【請求項２４】
既知のセキュリティアソシエーションなしにデータチャンネルを変更されないままに保持する間、対応するセキュリティアソシエーションを有する処理されたトランザクションの前記項目のみを再暗号化するステップと、
再暗号化され、及び／又は変更されていないデータチャンネルを含むトランザクションを終点に転送するステップとを更に有する請求項２３に記載の方法。
【請求項２５】
受信したトランザクションの項目を、前記異なるセキュリティアソシエーションに関連付けられたチャンネルに分離するステップと、
各チャンネルの項目をビット列に符号化するステップと、
前記関連付けられた暗号化に応じて、各チャンネルの前記ビット列を暗号化し、あるいは、復号化するステップとを更に有する請求項２２に記載の方法。
【請求項２６】
前記トランザクションの異なる種類の項目を前記異なるセキュリティアソシエーションに関連付ける暗号化スキーマを持ち、該構成された暗号化スキーマに応じて、受信又は送信される種々のトランザクションの項目を暗号化し、あるいは復号化する前記ネットワーク処理装置を構成するステップを更に有する請求項２２に記載の方法。
【請求項２７】
前記異なる項目にインデックスを付した前記セキュリティアソシエーションのリストを前記ネットワーク処理装置にロードすることにより、前記暗号化スキーマを持つ前記ネットワーク処理装置を構成するステップを更に有する請求項２６に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
インターネットを介して情報を伝送する際、そのセキュリティは関心事である。暗号化技術は、インターネットなどのネットワークを越えて通信する２つのノード間で伝送されるデータを保護するために用いられ得る。特定のデータセットを伝送する際に関連するインターネットのインフラは、２つの終点間でパケットのルートを正確に決めるために、データの異なる部分を処理する必要がある１以上の中間ネットワーク処理ノードを含んでもよい。
【０００２】
中間ネットワーク処理ノードは、データを暗号化するために用いられる暗号化キーへのアクセスを許され得る。しかしながら、中間点でパケットを復号化することは、セキュリティ上のリスクをもたらす。例えば、盗聴者が、中間ネットワーク処理ノードで復号化した後のデータにアクセスできるかもしれない。
【０００３】
本発明は、先行技術に関連するこの及び他の問題を取り扱う。
【発明の開示】
【課題を解決するための手段】
【０００４】
通信ノードは、第１のセキュリティアソシエーション（ｓｅｃｕｒｉｔｙ  ａｓｓｏｃｉａｔｉｏｎ）に対応する２地点間暗号化キーを用いて、２地点間通信に関連付けられるトランザクションの第１部分を暗号化する。終点間通信に関連付けられるトランザクションの第２部分は、第２のセキュリティアソシエーションに対応する終点間暗号化キーを用いて暗号化される。
【０００５】
本発明の前述の及び他の目的、特徴並びに利点は、添付図面を参照して進められる本発明の好適実施形態の詳細な記述からより容易に明らかになるであろう。
【発明を実施するための最良の形態】
【０００６】
異なる種類のデータの伝送は、一般に、トランザクションとして以下に言及され得る。これらのトランザクションは、電子メールデータ、カレンダー、コンテンツ、タスク、ノート、電子ドキュメント、ファイル又はあらゆる他の種類の制御若しくは内容データを伝送するために用いられ得る。
【０００７】
図１は、通信ネットワーク１２の一実施形態を示す。通信ネットワーク１２は、モバイルネットワーク１４と、企業ネットワーク１８と、通信管理システム１６とを含む。通信管理システム１６は、モバイルネットワーク１４と企業ネットワーク１８の間の通信を管理する。モバイルネットワーク１４は、無線又は陸上通信サービスプロバイダを介して、ＩＰインフラで通信するモバイル機器２１を含む。モバイルネットワーク１４は周知であるので、ここではさらなる詳細を記述しない。
【０００８】
企業ネットワーク１８は、あらゆるビジネスネットワーク、個人的ユーザネットワーク、あるいは、１以上のユーザのためにローカル電子メールや他のデータを保持するローカルコンピュータシステムであり得る。図１に示す実施形態では、企業ネットワーク１８は、パーソナルコンピュータ（ＰＣ）３８を用いてアクセス可能なユーザメールボックス４４を含む電子メールサーバ３４を備える。一例では、電子メールサーバ３４は、マイクロソフトエクスチェンジ（Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ）サーバであってもよく、ＰＣ３８は、マイクロソフトアウトルック（Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ）ソフトウェアアプリケーションを介して、メールボックス４４にアクセスしてもよい（ここで、「マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）」、「エクスチェンジ（Ｅｘｃｈａｎｇｅ）」、「アウトルック（ｏｕｔｌｏｏｋ）」は登録商標である。）。メールボックス４４は、電子メール、コンタクトリスト（通信リスト）、カレンダー、タスク、ノート、あるいは、他のあらゆる種類のデータ若しくは電子ドキュメントを格納することができる。
【０００９】
ＰＣ３８は、ローカルエリアネットワーク（ＬＡＮ）３５を介して電子メールサーバ３４に接続される。ＰＣ３８は、他のあらゆる種類の電子ドキュメントとともに、個人電子メールデータを含むローカルファイルを格納するためのメモリ３９を備える。パーソナルクライアントソフトウェア４０は、ＰＣ３８内のプロセッサ３７によって実行される。パーソナルクライアント４０は、モバイル機器２１のローカルファイルと同様に、電子メールカレンダー、及びコンタクト情報にアクセス可能である。
【００１０】
通信管理システム１６は、プロセッサ３３を備える少なくとも１つの管理サーバ２８を含む。プロセッサ３３は、モバイル機器２１と企業ネットワーク１８の間のトランザクションを管理する配送エージェント３１を作動する。ユーザデータベース４２は、モバイル通信サーバの異なるユーザの設定情報を含む。例えば、ユーザデータベース４２は、モバイル通信サーバのユーザのログインデータを含んでもよい。管理システム１６と管理サーバ２８と称するが、これは、モバイルネットワーク１４と企業又は個人ネットワーク１８の間で作動する１以上の中間サーバを含むあらゆる中間システムであり得る。
【００１１】
パーソナルクライアント４０は、管理サーバ２８へのアウトバウンド接続２５をなす。パーソナルクライアント４０は、管理サーバ２８への特定のユーザの存在を登録し、暗号の暗号化方式（ｃｉｐｈｅｒｓｕｉｔｅ）（暗号化暗号文、キー長、及びデジタル署名アルゴリズムを含む）と、接続２５を介する独特で秘密の２地点間暗号化キー２９とを指定するセキュリティアソシエーションを取り決める。一例では、キー２９は、進歩した暗号化標準（ＡＥＳ）キーであり、ディフィーへルマン（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）暗号化アルゴリズムを用いて取り決められる。もちろん、ＡＥＳ以外の暗号化暗号文を用いることもできる。暗号化キー２９は、接続２５を介して、管理サーバ２８とＰＣ３８の間の安全な通信を可能にする。
【００１２】
モバイル機器２１は、２地点間セキュリティアソシエーションを取り決め、管理サーバ２８で、暗号の暗号化方式と独特の暗号化キー２７とを指定する。一例では、２地点間暗号化キー２７は、ＡＥＳ暗号化キーである。暗号化キー２７を含む、取り決められたセキュリティアソシエーションは、接続２３を介して、モバイル機器２１と管理サーバ２８との間の安全な２地点間通信を可能にする。各異なるモバイル機器２１は、管理サーバ２８で、独特の暗号化キー２７を含む、異なるセキュリティアソシエーションを取り決めなければならない。
【００１３】
２地点間暗号化キー２７は、モバイル機器２１と管理サーバ２８との間で伝送される必要がある制御データを暗号化するために用いられてもよい。また、２地点間暗号化キー２９は、管理サーバ２８とパーソナルクライアント４０の間で伝送される必要がある制御データを暗号化するために用いられてもよい。例えば、制御データは、ログイン情報と、トランザクションルーティング情報とを含んでもよい。
【００１４】
暗号の暗号化方式と独特の暗号化キー４６とを指定して、終点間セキュリティアソシエーションは、モバイル機器２１とパーソナルクライアント４０との間で取り決められる。一例では、終点間暗号化キー４６は、ＡＥＳ暗号化キーである。終点間暗号化キー４６は、パーソナルクライアント４０とモバイル機器２１との間で伝送されるトランザクションペイロードを暗号化するために用いられる。例えば、終点間暗号化キー４６は、電子メールの内容、ファイルパスネーム、コンタクト、ノート、カレンダー、電子ドキュメント、及び、モバイル機器とＰＣとの間で安全に伝送される必要がある他のあらゆる種類のデータを暗号化するために用いられてもよい。終点間暗号化キー４６は、モバイル機器２１とパーソナルクライアント４０のみに知られている。終点間暗号化キー４６を用いて暗号化されたデータを、管理サーバ２８により復号化することはできない。
【００１５】
図２は、メールボックス４４内のモバイル機器２１によって送信され、最新電子メールメッセージの検索を要求する同期トランザクション６０Ａの一例を示す。同期トランザクション６０Ａの一部分６３Ａは、２地点間暗号化キー２７を用いてモバイル機器２１により暗号化される（図１参照）。同期トランザクション６０Ａのもう一つの部分６５は、終点間暗号化キー４６を用いて暗号化される。同期トランザクション６０Ａのもう一つの第３の部分６１Ａは、全く暗号化されなくてもよい。モバイル機器２１は、接続２３を介して管理サーバ２８に、同期トランザクション６０Ａを送信する。
【００１６】
管理サーバ２８は、２地点間暗号化キー２７を用いて暗号化された同期トランザクション６０Ａの一部分６３Ａを復号化する。管理サーバ２８が暗号化キー４６を持たないので、同期トランザクション６０Ａの一部分６５を復号化しない。管理サーバ２８は、同期トランザクション６０Ａをどのように処理するかを決定するために、暗号化されていないデータ６１Ａと復号化された２地点間データ６３Ａとを解読する（デコードする）。処理の一部は、暗号化キー２９を用いて、復号化されたデータ６３Ａの一部あるいは全部を２地点間暗号化データ６３Ｂに再暗号化することを含んでもよい。また、管理サーバ２８は、新しい暗号化されていないデータ６１Ｂを生成するために、暗号化されていないデータ６１Ａに変更し、あるいは加えられてもよい。暗号化されていないデータ６１Ｂ及び再暗号化された２地点間データ６３Ｂは、新しい同期トランザクション６０Ｂを生成するために、２地点間暗号化データ６５と結合される。同期トランザクション６０Ｂは、接続２５を介してパーソナルクライアント４０に伝送される。
【００１７】
パーソナルクライアント４０は、暗号化キー２９を用いて、２地点間暗号化データ６３Ｂを復号化し、暗号化キー４６を用いて、終点間暗号化データ６５を復号化する。パーソナルクライアント４０は、同期トランザクション６０Ｂの復号化された指示に従って、メールボックス４４から電子メールメッセージ６２を取得する。パーソナルクライアント４０は、終点間暗号化キー４６を用いて、電子メールメッセージ６２の内容を暗号化する。
【００１８】
パーソナルクライアント４０は、終点間暗号化電子メールメッセージ６２にエンベロープ６４Ａを添付し得る応答トランザクション６６Ａを生成する。エンベロープ６４Ａは、応答トランザクション６６Ａを同期トランザクション６０Ｂへの応答として識別する通信パラメータを含んでもよく、電子メールメッセージ６２の大きさなどの他のメッセージパラメータを含んでもよい。
【００１９】
２地点間暗号化キー２９を用いて、エンベロープ６４Ａの一部あるいは全部を暗号化してもよい。そして、パーソナルクライアント４０は、メッセージ（応答トランザクション）６６Ａを管理サーバ２８に送信する。管理サーバ２８は、２地点間暗号化キー２９を用いて、エンベロープ６４Ａを復号化し、応答トランザクション６６Ａをモバイル機器２１に転送するために必要な復号化されたデータを処理する。応答トランザクション６６Ａのペイロード６２は、管理サーバ２８が終点間暗号化キー４６にアクセスしないので、復号化されない。
【００２０】
管理サーバ２８は、エンベロープ６４Ａの情報の一部あるいは全部をエンベロープ６４Ｂに再暗号化する。エンベロープ６４Ｂは、２地点間暗号化キー２７を用いて再暗号化される。エンベロープ６４Ｂと終点間暗号化ペイロード６２とを含む応答メッセージ６６Ｂが生成される。
【００２１】
応答メッセージ６６Ｂは、接続２３を介してモバイル機器２１に転送される。モバイル機器２１は、２地点間暗号化キー２７を用いて、エンベロープ６４Ｂを復号化し、終点間暗号化キー４６を用いて、ペイロード６２を復号化する。そして、復号化されたペイロード６２は、モバイル機器２１に表示される。例えば、メールボックス４４からの電子メールをモバイル機器２１に表示する。
【００２２】
図３は、本発明の他の実施形態を示す。通信管理システム１６は、それぞれが異なる通信管理タスクを実行する多数のサーバ７０、７２及び７４を含んでもよい。モバイル機器２１とＰＣ３８との間で送信されるトランザクション７１及び７３は、サーバ７０、７２及び７４の異なる組み合わせによって処理される必要があってもよい。
【００２３】
暗号化キー７６は、サーバ７０とサーバ７４の間で取り決められ、暗号化キー７８は、サーバ７０とサーバ７２との間で取り決められ、暗号化キー８０は、サーバ７２とサーバ７４の間で取り決められる。取り決められた暗号化キー７６、７８及び８０は、トランザクション７１及び７３を処理する際に用いられる。
【００２４】
例えば、トランザクション７３は、パーソナルクライアント４０からサーバ７４に送信されてもよい。パーソナルクライアント４０は、２地点間暗号化キー２９を用いて、トランザクション７３のエンベロープ７５の一部あるいは全部を暗号化し、終点間暗号化キー４６を用いてペイロード７７を暗号化する。トランザクション７３の受信後、サーバ７４は、２地点間暗号化キー２９を用いて、エンベロープ７５を復号化する。
【００２５】
そして、サーバ７４は、トランザクション７３をサーバ７０に送信する必要があってもよい。サーバ７４は、暗号化キー７６を用いて、復号化されたエンベロープ７５を再暗号化する。メッセージ７３を受信する際、サーバ７０は、暗号化キー７６を用いてエンベロープ７５を復号化する。その内容を処理した後、サーバ７０は、モバイル機器２１と前に取り決められた２地点間暗号化キーを用いて、エンベロープ７５を再暗号化する。そして、トランザクションは、サーバ７０からモバイル機器２１に送信される。図２の場合と同様に、サーバ７０、７２及び７４は、トランザクション７３の暗号化されたペイロード７７に決してアクセスしない。
【００２６】
一方、同期トランザクション７１は、３つのサーバ７０、７２及び７４のすべてによって処理される必要があってもよい。同期サーバ７１の一部は、モバイル機器２１からサーバ７０に転送される際、暗号化キー２７を用いて暗号化される。暗号化キー７８は、サーバ７０からサーバ７２に転送される際、このトランザクション７１の一部を暗号化するために用いられる。暗号化キー８０は、サーバ７２からサーバ７４に転送される際、同期トランザクション７１の一部を暗号化するために用いられる。そして、暗号化キー２９は、同期トランザクション７１がサーバ７４からＰＣ３８に転送される際、用いられる。
【００２７】
互いに直接通信し、あるいは中間ノードを介して通信する２つのノード間の暗号化キーの安全な取り決めを可能にするアルゴリズムが存在する。ネットワークトポロジーにかかわらず安全なキー取り決めを可能にする暗号化アルゴリズムの一例は、楕円曲線暗号作成ディフィーへルマン（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）法（ＥＣＣ−ＤＨ）である。
【００２８】
図４は、異なる種類のデータ又は異なる目的地に関連するデータのために暗号化がどのように異なって実行されるかを示す。トランザクション８２は、電子メールメッセージの内容、電子ドキュメント、あるいは、２つの終点によってのみアクセスされるべき他のあらゆる種類の情報などの内容データ８８を含む。内容データ８８は、終点間暗号化キーを用いて暗号化される。
【００２９】
トランザクションメッセージ８２の第２部分８６は、ある特定のサーバのみによって処理される必要がある制御情報を含んでもよい。この場合、制御データ８６は、第１の２地点間暗号化キーを用いて暗号化される。トランザクションメッセージ８２のデータ８４の第３部分は、異なるサーバによって処理される必要がある他の制御情報（例えば、エラーチェックデータ）を有していてもよい。したがって、エラーチェックデータ８４は、データ８８及び８６を暗号化するために用いられる他の２つの暗号化キーのいずれとも異なる第２の２地点間暗号化キーを用いて暗号化される。
【００３０】
図５は、暗号化スキーマが、ソースと目標装置の間のトランザクションを処理する際、モバイル機器２１、管理サーバ２８、及びパーソナルクライアント４０によってどのように用いられるかをより詳細に説明する。以下の例では、モバイル機器２１は、トランザクション９０を送信するソースとして機能する。トランザクション９０は、ＰＣ３８のローカルメモリ３９内のパーソナルディレクトリに位置するドキュメント９２を送信するよう、パーソナルクライアント４０に要求する。パーソナルクライアント４０は、トランザクション９０のターゲットとして機能し、管理サーバ２８は、モバイル機器２１からパーソナルクライアント４０にトランザクション９０を転送するための配送エージェントとして機能する。
【００３１】
これが一例に過ぎず、図５に示す装置が多くの異なる種類のトランザクションを処理することができることを理解されたい。例えば、トランザクション９０は、モバイル機器２１の電子メールとＰＣ３８の電子メールとの同期を要求してもよい。さらに、あらゆる装置が、トランザクションのソース又はターゲットとして機能することができる。例えば、トランザクション９１を要求９０に対する応答として送信する際、パーソナルクライアント４０は、ソースとして機能し、モバイル機器２１は、ターゲットとして機能する。
【００３２】
モバイル機器２１、管理サーバ２８及びパーソナルクライアント４０は、トランザクション９０の特定の項目がどのように暗号化されるべきかを識別する暗号化スキーマ９４ですべて構成される。また、各装置は、図１〜３で上述されるような異なるセキュリティアソシエーションで構成されてもよい。例えば、モバイル機器２１は、２地点間（ＰＰ）キー２７と終点間（ＥＥ）キー４６の両方を有する。管理サーバは、ＰＰキー２７とＰＰキー２９とを有し、ＰＣ３８は、ＰＰキー２９とＥＥキー４６とを有する。
【００３３】
図５及び図６において、ブロック１００では、モバイル機器２１は、要求トランザクション９０を形成する。要求の一例は、以下のようである。
【００３４】
要求：  ｛ａｕｔｈ＿ｔｏｋｅｎ  ＝  "ａｂｃ"，
ｄｅｖｉｃｅ＿ｉｄ  ＝  "ｘｙｚ"，
ｍｅｔｈｏｄ＿ｉｄ  ＝  "ＧｅｔＤｏｃｕｍｅｎｔ"，
ａｒｇｓ  ＝  ｛ｐａｔｈ  ＝  "／ｄｏｃｓ"｝
｝
【００３５】
モバイル機器２１は、管理サーバ２８に送信されるトランザクションにａｕｔｈ＿ｔｏｋｅｎ（認証トークン）を添付する。例えば、モバイル機器２１は、処理の他のトランザクションを提出するのを許される前に、ユーザネームとパスワードを伝送することによって、管理サーバ２８へ認証することを要求されてもよい。サーバ２８は、ユーザデータベース４２の情報に対してユーザネームとパスワードを確認するのに成功した後、モバイル機器２１にａｕｔｈ＿ｔｏｋｅｎを発行する。そして、モバイル機器２１は、管理サーバ２８に送信される次のトランザクションにそのａｕｔｈ＿ｔｏｋｅｎを添付する。管理サーバ２８は、各トランザクションのソースを識別・認証し、トランザクションのルートをどこに決定するかを決めるために、そのａｕｔｈ＿ｔｏｋｅｎを用いる。
【００３６】
ｄｅｖｉｃｅ＿ｉｄは、要求９０を送信する特定のモバイル機器２１を識別する。ｄｅｖｉｃｅ＿ｉｄは、例えば、ユーザが１つ以上のモバイル機器を有する際に必要であってもよい。パーソナルクライアント４０は、同期情報が多数の異なるモバイル機器のそれぞれに最後に送られたときを追跡するために、異なるｄｅｖｉｃｅ＿ｉｄ値を用いることができる。また、ｄｅｖｉｃｅ＿ｉｄは、特定の種類のモバイル機器２１に送信されたデータをどのようにフォーマットするかを決定するために、管理サーバ２８とパーソナルクライアント４０のいずれかによって用いられ得る。例えば、データは、パーソナルコンピュータとは対称的に、携帯電話のために異なってフォーマットされる必要があるかもしれない。また、ｄｅｖｉｃｅ＿ｉｄは、既知のセキュリティアソシエーションを特定のモバイル機器と関連付けるために用いられ得る。
【００３７】
上述の例のｍｅｔｈｏｄ＿ｉｄ項目は、要求９０に関連付けられる特定の機能ＧｅｔＤｏｃｕｍｅｎｔを識別する。また、ｍｅｔｈｏｄ＿ｉｄ項目は、ＧｅｔＤｏｃｕｍｅｎｔ機能のためのパラメータを識別する関連した主張項目の包含を必要とする。例えば、主張項目は、要求されたドキュメントが位置するパスネームを識別する表現ｐａｔｈ  ＝  "／ｄｏｃｓ"を含むであろう。
【００３８】
図６のブロック１０２において、図５に前に示される暗号化スキーマ９４が確立される。暗号化スキーマ９４の一例は、上記で示す例ＧｅｔＤｏｃｕｍｅｎｔ要求がモバイル機器２１と管理サーバ２８の間の通信の特定の場合にどのように処理されるかを以下のように示す。
【００３９】
暗号化スキーマ：
｛ＧｅｔＤｏｃｕｍｅｎｔ  ＝
｛ｃｌｅａｒ＝  ［"ｄｅｖｉｃｅ＿ｉｄ"］，
ｐｐ  ＝  ［"ａｕｔｈ  ｔｏｋｅｎ"，  "ｕｓｅｒ＿ｉｄ"］，
ｅｅ  ＝  ［"ａｒｇｓ．ｐａｔｈ"］
｝
ｄｅｆａｕｌｔ  ＝  ｛ｐｐ｝
｝
【００４０】
暗号化を要求しないあらゆる項目は、「クリア（ｃｌｅａｒ）」のラベルを貼られたデータチャンネルに割り当てられる。例えば、上述の例のｄｅｖｉｃｅ＿ｉｄ項目は、チャンネル「クリア」に割り当てられる。２地点間暗号化の使用を要求する項目は、データチャンネル「ＰＰ」に割り当てられ、そのため、図５に示すように、ＰＰキー２７を用いて暗号化される。この例では、ａｕｔｈ＿ｔｏｋｅｎは、「ＰＰ」チャンネルに割り当てられ、ＰＰキー２７を用いて暗号化される。終点間暗号化を要求する項目は、「ｅｅ」チャンネルに割り当てられ、図５に示すＥＥキー６を用いて暗号化される。
【００４１】
この例では、暗号化スキーマ９４に明示的に示されないあらゆる項目は、デフォルトにより、「ＰＰ」チャンネルに割り当てられる。ｍｅｔｈｏｄ＿ｉｄ項目が暗号化スキーマ９４に特に示されなかったので、それは、デフォルトにより「ＰＰ」チャンネルに割り当てられ、ＰＰキー２７を用いて暗号化される。
【００４２】
通信のコンテキストがチャンネルの暗号化のために選択された特定のセキュリティアソシエーションを決定することに注目することが重要である。例えば、モバイル機器２１と管理サーバ２８の間の第１の「ＰＰ」チャンネルは、管理サーバ２８とパーソナルクライアント４０の間の第２の、独立して確立された「ＰＰ」チャンネルのために確立されたものとは異なるセキュリティアソシエーションを用いる。この例では、第１の「ＰＰ」チャンネルは、モバイル機器と管理サーバの間のトランザクションのために、図５のＰＰキー２７を用いるが、第２の「ＰＰ」チャンネルは、管理サーバとパーソナルクライアントの間のトランザクションのために、ＰＰキー２９を用いる。各セキュリティアソシエーションが独立して取り決められるので、前述の２つの「ＰＰ」チャンネルの違いは、異なるキー長（例えば、２５６ビット対１２８ビット）、暗号化暗号文（例えば、Ｔｒｉｐｌｅ  ＤＥＳ対ＡＥＳ）、デジタル署名アルゴリズム（例えば、ＳＨＡ１対ＭＤ５）、あるいは他のセキュリティパラメータを含むために、独特のキーを有する各チャンネルを越えて拡大することができる。
【００４３】
トランザクションの要求９０を準備するために、モバイル機器２１は、図６のブロック１０４において、暗号化スキーマ９４を用いて要求９０のパターンマッチングを実行する。このパターンマッチングは、要求９０の項目を異なるチャンネルに分離する。異なるチャンネルの一例は、以下に示される。この例では、各チャンネルの項目は、再定義されたセキュリティアソシエーション、クリア、ＰＰ及びｅｅと関連付けられる。
【００４４】
チャンネル：
｛ｃｌｅａｒ  ＝  ｛ｄｅｖｉｃｅ＿ｉｄ  ＝  "ｘｙｚ"｝
ｐｐ  ＝  ｛ａｕｔｈ＿ｔｏｋｅｎ  ＝  "ａｂｃ"，  ｍｅｔｈｏｄ＿ｉｄ  ＝  "ＧｅｔＤｏｃｕｍｅｎｔ"｝
ｅｅ  ＝  ｛ａｒｇｓ  ＝  ｛ｐａｔｈ  ＝  ｛ｐａｔｈ  ＝  "／ｄｏｃｓ"｝｝｝
｝
【００４５】
ブロック１０６では、チャンネル内容（コンテンツ）は、（一般に連続放映として知られる処理を介して）ビット列又はデータグループとして言及されるバイトに符号化される。ビット又はバイトのこれらのグルーピングは、一般にアレイとして以下に言及されるが、あらゆる種類のパーティション、グループなどであり得る。
【００４６】
クリアチャンネルのコンテンツは、ｄａｔａ＿ｇｒｏｕｐ＿１として言及されるビットアレイに符号化され、ｐｐチャンネルのコンテンツは、ｄａｔａ＿ｇｒｏｕｐ＿２として言及されるビットアレイに符号化され、ｅｅチャンネルのコンテンツは、ｄａｔａ＿ｇｒｏｕｐ＿３として言及されるビットアレイに符号化される。各チャンネルのコンテンツは、暗号化することができるように、ビットアレイに符号化される必要がある。ビットアレイに符号化された後のチャンネルのコンテンツは、次のように表される。
【００４７】
符号化チャンネル：  ｛ｃｌｅａｒ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿１
ｐｐ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿２
ｅｅ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿３｝
【００４８】
その後、ビットアレイは、ブロック１０８において、各チャンネルのセキュリティアソシエーションに応じて暗号化される。暗号化スキーマ９４に応じて、クリアチャンネル（ｄａｔａ＿ｇｒｏｕｐ＿１）のビットは暗号化されない。ｐｐチャンネル（ｄａｔａ＿ｇｒｏｕｐ＿２）のビットは、モバイル機器２１と管理サーバ２８の間の２地点間セキュリティアソシエーションを用いて暗号化され、ＰＰキー２７を用いて、暗号化後ｐｐ＿ｄａｔａ＿ｇｒｏｕｐ＿２として言及される。ｅｅチャンネル（ｄａｔａ＿ｇｒｏｕｐ＿３）のビットは、モバイル機器２１とパーソナルクライアント４０の間の終点間セキュリティアソシエーションを用いて暗号化され、ＥＥキー４６を用いて、暗号化後ｅｅ＿ｄａｔａ＿ｇｒｏｕｐ＿３として言及される。データグループは、暗号化後次のように表される。
【００４９】
暗号化チャンネル：  ｛ｃｌｅａｒ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿１
ｐｐ  ＝  ｐｐ＿ｄａｔａ＿ｇｒｏｕｐ＿２
ｅｅ  ＝  ｅｅ＿ｄａｔａ＿ｇｒｏｕｐ＿３｝
【００５０】
その後、暗号化及び非暗号化チャンネルを作るビットは、ブロック１１０において、１以上のパケットに符号化される。明確さのため、以下の記述は、１つのパケットに言及するが、チャンネルからのデータは、多数のパケットに含まれてもよい。パケットのいくつかのコンテンツは、以下のように示される。
【００５１】
パケット
【００５２】
【表１】
2005515664.tif 000003
【００５３】
パケットヘッダの情報は、パケット長、バージョンナンバー、他のフラグを含んでもよい。パケットペイロードは、３対の項目を識別するカウントを含む。３つの項目は、クリアチャンネルの非暗号化コンテンツ、ｐｐチャンネルのｐｐ暗号化コンテンツ、及びｅｅチャンネルのｅｅ暗号化コンテンツを含む。そして、ブロック１１２において、パケットは、モバイル機器２１によって管理サーバ２８に伝送される。
【００５４】
図５〜７において、ブロック１１４では、サーバ２８で作動する配送エージェントは、パケットを受信する。パケットのビットは、ブロック１１６で、異なるチャンネル、ｃｌｅａｒ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿１、ｐｐ  ＝  ｐｐ＿ｄａｔａ＿ｇｒｏｕｐ＿２、及び、ｅｅ  ＝  ｅｅ＿ｄａｔａ＿ｇｒｏｕｐ＿３に分離される。
【００５５】
クリアチャンネルのデータは、復号化される必要がない。ブロック１１８では、配送エージェントは、既知のセキュリティアソシエーションを有するチャンネルのビットのみを復号化する。モバイル機器２１と管理サーバ２８の間の２地点間セキュリティアソシエーションの一部として、配送エージェントは、ＰＰキー２７を所有し、そのため、ｐｐチャンネルのコンテンツを復号化する。配送エージェントは、モバイル機器２１とパーソナルクライアント４０の間の終点間セキュリティアソシエーションの一部ではなく、ＥＥキー４６を有さない。そのため、配送エージェントは、ｅｅチャンネルのデータを復号化しない。復号化は、次のデータグループ、すなわち、ｃｌｅａｒ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿１、ｐｐ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿２、及び、ｅｅ  ＝  ｅｅ＿ｄａｔａ＿ｇｒｏｕｐ＿３を作り出す。
【００５６】
ブロック１２０において、配送エージェントは、クリアチャンネル及びｐｐチャンネルのコンテンツを解読する。暗号化されたｅｅチャンネルのコンテンツは、解読されず、その代わりに、パーソナルクライアント４０に最終的に伝送するために変更されない状態で保持される。解読（Ｄｅｃｏｄｉｎｇ）は、次のコンテンツを作り出す。
【００５７】
解読された
チャンネル：
｛ｃｌｅａｓｒ  ＝  ｛ｄｅｖｉｃｅ＿ｉｄ  ＝  "ｘｙｚ"｝
ｐｐ  ＝  ｛ａｕｔｈ＿ｔｏｋｅｎ  ＝  "ａｂｃ"，  ｍｅｔｈｏｄ＿ｉｄ  ＝  "ＧｅｔＤｏｃｕｍｅｎｔ"｝
ｅｅ  ＝  ｅｅ＿ｄａｔａ＿ｇｒｏｕｐ＿３
｝
【００５８】
ブロック１２２では、クリアチャンネル及びｐｐチャンネルの項目を併合することにより、部分的な要求を形成する。この例における部分的要求は、次と同様に見えるであろう：
部分的要求：
｛ａｕｔｈ＿ｔｏｋｅｎ  ＝  "ａｂｃ"，
ｄｅｖｉｃｅ＿ｉｄ  ＝"ｘｙｚ"，
ｍｅｔｈｏｄ＿ｉｄ  ＝  "ＧｅｔＤｏｃｕｍｅｎｔ"，
ａｒｇｓ  ＝  ｛｝
ｅｎｃｒｙｐｔｅｄ  ＝  ｛ｅｅ  ＝  ｅｅ＿ｄａｔａ＿ｇｒｏｕｐ＿３｝
｝
ブロック１２４では、配送エージェントは、部分的要求を処理する。この例では、配送エージェントは、ａｕｔｈ＿ｔｏｋｅｎ（"ａｂｃ"）の値とユーザデータベース４２（図５参照）の内容とをマッチングすることによりその要求が認証されることを確かめてもよい。Ａｕｔｈ＿ｔｏｋｅｎ及びｍｅｔｈｏｄ＿ｉｄ（"ＧｅｔＤｏｃｕｍｅｎｔ"）は、トランザクション９０がパーソナルクライアント４０に向けられたドキュメント要求であることを示す。
【００５９】
配送エージェントは、ａｕｔｈ＿ｔｏｋｅｎ  ＝  "ａｂｃ"に関連するｕｓｅｒ＿ｉｄ  ＝  "ｊｏｅ"を識別し、次の新しい要求を生成してもよい。
【００６０】
新しい要求：
｛ｕｓｅｒ＿ｉｄ  ＝  "ｊｏｅ"，
ｄｅｖｉｃｅ＿ｉｄ  ＝  "ｘｙｚ"，
ｍｅｔｈｏｄ＿ｉｄ  ＝  "ＧｅｔＤｏｃｕｍｅｎｔ"，
ａｒｇｓ  ＝  ｛｝
ｅｎｃｒｙｐｔｅｄ  ＝  ｛ｅｅ  ＝  ｅｅ＿ｄａｔａ＿ｇｒｏｕｐ＿３｝
｝
【００６１】
ブロック１２６では、配送エージェントは、異なるセキュリティアソシエーションに関連するチャンネルコンテンツを再形成するために、新しい要求と暗号化スキーマ９４とのもう一つのパターンマッチングを実行する。この例では、クリアチャンネル、ｐｐチャンネル、及びｅｅチャンネルの項目は、モバイル機器２１によって本来送信される項目にかなり類似している。再形成されたチャンネルコンテンツは以下に示される。
【００６２】
配送エージェントによって再形成されたチャンネル：
｛ｃｌｅａｒ  ＝  ｛ｄｅｖｉｃｅ＿ｉｄ  ＝  "ｘｙｚ"｝
ｐｐ  ＝  ｛ｕｓｅｒ＿ｉｄ  ＝  "ｊｏｅ"，  ｍｅｔｈｏｄ＿ｉｄ  ＝  "ＧｅｔＤｏｃｕｍｅｎｔ"｝
ｅｅ  ＝  ｅｅ＿ｄａｔａ＿ｇｒｏｕｐ＿３
｝
【００６３】
ブロック１２８において、配送エージェントは、クリアチャンネルのコンテンツをビットアレイに符号化する（ｃｌｅａｒ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿１）。暗号化スキーマ９４がクリアチャンネルの暗号化を定義しないので、ビットアレイｄａｔａ＿ｇｒｏｕｐ＿１は暗号化されない。ｐｐチャンネルのコンテンツは、ビットアレイｐｐ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿２に符号化され、管理サーバ２８とパーソナルクライアント４０の間の２地点間セキュリティアソシエーションを用いて暗号化され、ＰＰキー２９を用いて、暗号化されたビットアレイｐｐ  ＝  ｐｐ＿ｄａｔａ＿ｇｒｏｕｐを形成する。ｅｅチャンネルのコンテンツは、配送エージェントにより復号化されず、あるいは解読されない。それゆえ、それを再符号化又は暗号化する必要がない。再形成されたトランザクションのビットアレイは、次のように表される。
【００６４】
符号化／暗号化された
チャンネル：  ｛ｃｌｅａｒ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿１
ｐｐ  ＝  ｐｐ＿ｄａｔａ＿ｇｒｏｕｐ＿２
ｅｅ  ＝  ｅｅ＿ｄａｔａ＿ｇｒｏｕｐ＿３｝
【００６５】
ブロック１３０では、配送エージェントは、チャンネルコンテンツを上記で示したのと類似のパケットフォーマットに符号化する。そして、パケットは、ブロック１３２でパーソナルクライアント４０に伝送される。
【００６６】
図５及び図８において、パーソナルクライアント４０は、トランザクション９０の目標（ターゲット）である。パーソナルクライアント４０は、ブロック１４０において、パケットを受信し、ブロック１４２で、パケットのビットをチャンネルに分離する。
【００６７】
暗号化されたチャンネル：  ｛ｃｌｅａｒ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿１
ｐｐ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿２
ｅｅ  ＝  ｄａｔａ＿ｇｒｏｕｐ＿３｝
【００６８】
その後、チャンネルのコンテンツは、ブロック１４６において、解読され、次の要求項目を生成する。
【００６９】
解読されたチャンネル：
｛ｃｌｅａｒ  ＝  ｛ｄｅｖｉｃｅ＿ｉｄ  ＝  "ｘｙｚ"｝
ｐｐ＝  ｛ｕｓｅｒ＿ｉｄ  ＝  "ｊｏｅ"，
ｍｅｔｈｏｄ＿ｉｄ  ＝  "ＧｅｔＤｏｃｕｍｅｎｔ"｝
ｅｅ  ＝  ｛ａｒｇｓ  ＝  ｛ｐａｔｈ  ＝  "／ｄｏｃｓ"｝
｝
【００７０】
その後、チャンネルのコンテンツは、ブロック１４８において、結合され、ｕｓｅｒ＿ｉｄに取って代わるａｕｔｈ＿ｔｏｋｅｎを持つ再形成された要求９０を形成する。
【００７１】
要求９０：  ｛ｄｅｖｉｃｅ＿ｉｄ  ＝  "ｘｙｘ"，
ｕｓｅｒ＿ｉｄ  ＝  "ｊｏｅ"，
ｍｅｔｈｏｄ＿ｉｄ  ＝"ＧｅｔＤｏｃｕｍｅｎｔ"，
ａｒｇｓ  ＝  ｛ｐａｔｈ  ＝  "／ｄｏｃｓ"｝
｝
【００７２】
パーソナルクライアント４０は、ブロック１５０において要求９０を処理する。その要求９０に応じて、パーソナルクライアント４０は、識別されたドキュメントを検索し、要求９０を形成したモバイル機器２１と同様の方法で、応答トランザクション９１（図５参照）を生成する。例えば、検索されたドキュメントは、パーソナルクライアント４０とモバイル機器２１の間の終点間セキュリティアソシエーションを用いて暗号化され、ＥＥキー４６を用いて暗号化される。応答９１の制御情報の一部あるいは全部は、パーソナルクライアント４０と管理サーバ２８の間の２地点間セキュリティアソシエーションを用いて暗号化される。この２地点間セキュリティアソシエーションは、ＰＰキー２９を含む。応答９１は、次と同様に見ることができる。
【００７３】
応答９１：
｛ｍｅｔｈｏｄ＿ｉｄ  ＝  "ＧｅｔＤｏｃｕｍｅｎｔＲｅｓｐｏｎｓｅ"，
ａｒｇｓ  ＝  ｛ｄｏｃｕｍｅｎｔ  ＝  ｘｘｘ，
ｓｉｚｅ＝  ５１２３，
ｃｏｎｔｅｎｔ＿ｔｙｐｅ  ＝  "ｔｅｘｔ／ｐｌａｉｎ"，
ｎａｍｅ  ＝  "ｒｅａｄｍｅ．ｔｘｔ"｝
｝
【００７４】
暗号化スキーマに応じて、ｍｅｔｈｏｄ＿ｉｄは、ＰＰキー２９を用いて暗号化されてもよく、応答９１のコンテンツの残りは、ＥＥキー４６を用いて暗号化されてもよい。
【００７５】
データストリーミング
図９において、多数のパケット１６２〜１７４は、同じトランザクション１６０の異なる部分を伝送するために用いられる。マルチパケットトランザクション１６０は、１以上の大きいドキュメントがパーソナルクライアント４０とモバイル機器２１の間で伝送されるときに用いられてもよい。
【００７６】
一例では、所定の最大パケット長は１，０００バイトになるよう構成される。トランザクション１６０が１，０００バイト未満であると決定されるならば、クリアチャンネル、ｐｐチャンネル及びｅｅチャンネルの内容は、１つのパケットに符号化される。しかしながら、この例では、５００バイトのデータがｐｐチャンネル内に存在し、４，５００バイトのデータがｅｅチャンネル内に存在していると決定される。ＰＰチャンネルのすべてのコンテンツは、５００バイトのパケット１６４に符号化される。ＥＥチャンネルからのデータは、４つの別々の１，０００バイトのパケット１６６〜１７４と、１つの５００バイトのパケット１７４に符号化される。
【００７７】
同じトランザクション１６０の一部としてすべてのパケット１６２〜１７４を識別するヘッダパケット１６２が形成される。ヘッダパケット１６２のデータは暗号化されない。ヘッダパケット１６２が暗号化されないので、それは、クリアチャンネルからのデータを含むことができる。その代わりに、クリアチャンネルからのデータは、別の非暗号化パケットに符号化され得る。ヘッダパケット１６２は、ＰＰ暗号化キーを用いて暗号化される５００バイトのデータと、ＥＥ暗号化キーを用いて暗号化される４，５００バイトのデータとを識別する。
【００７８】
メッセージ１６０を受信するノードは、ヘッダ１６２を読み、トランザクション１６０がマルチパケットメッセージ（ｓｔｒｅａｍｉｎｇ  ＝  ｔｒｕｅ）であることを決定する。一実施形態では、クリアパケットヘッダ１６２は、常に最初に来て、ｐｐパケット１６４がすぐ後に続く。また、ＥＥパケット１６６〜１７４は、ｐｐパケット１６４のすぐ後に続く。この順序は、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）などのプロトコルを用いて生成され得る。この所定の順序でパケットを伝送することは、暗号化の種類を識別するために、各パケットにラベルを添付しなければならないことを排除する。その代わりに、シーケンス番号をパケット１６２〜１７４に割り当てることもできる。
【００７９】
トランザクション１６０を受信するノードは、同時にトランザクション１６０の異なる部分を受信し、復号化し、解読してもよい。例えば、処理ノードは、トランザクション１６０が認証されていないことを決定するために、まず、ヘッダパケット１６２の暗号化されていないクリアデータを処理してもよい。トランザクションが認証されないならば、処理ノードは、ｐｐパケット１６４とｅｅパケット１６６〜１７４とを復号化及び解読する必要なく、トランザクション１６０の残りを破棄することができる。
【００８０】
ヘッダパケット１６２の情報が認証されるならば、処理ノードは、ｐｐパケット１６４のデータを復号化及び解読する。ｐｐパケット１６４のデータが無効であるか、改ざんされていたならば、残りのｅｅパケット１６６〜１７４は、更に処理することなく、破棄され得る。
【００８１】
上述のシステムは、専用プロセッサシステム、マイクロコントローラ、プログラム可能な論理回路、あるいは、処理の一部又はすべてを実行するマイクロプロセッサを用いることができる。上述のいくつかの処理をソフトウェアで実行してもよく、他の処理をハードウェアで実行してもよい。
【００８２】
利便性のために、そのような処理は、種々の相関した機能ブロック、あるいは別個のソフトウェアモジュールとして記述される。しかしながら、このことが必要ではなく、これらの機能ブロックやモジュールが、明確な境界を持たず、一つの論理回路、プログラムあるいは処理に同等に統合された場合であってもよい。いずれにしても、機能ブロック及びソフトウェアモジュール、あるいは順応性のあるインターフェースの特徴は、自ら、あるいはハードウェアとソフトウェアのいずれかで他の処理と組み合わせて、実行され得る。
【００８３】
本発明の原理を、その好適実施形態を用いて記述したが、そのような原理を逸脱することなく、その配列や詳細において本発明を変更することができることは明白である。したがって、添付の特許請求の範囲の精神及び範囲内に含まれるすべての修正や変更を要求する。
【図面の簡単な説明】
【００８４】
【図１】暗号化キーが通信ネットワークでどのように変更されるかを示すブロック図である。
【図２】暗号化キーに応じてデータがどのように暗号化されるかを示すブロック図である。
【図３】多数の暗号化キーが通信ネットワークの異なるサーバ間でどのように変更されるかを示すブロック図である。
【図４】異なる種類のデータが異なる暗号化キーを用いてどのように暗号化されるかを示すブロック図である。
【図５】トランザクションを暗号化するために用いられる暗号化スキーマを示すブロック図である。
【図６】通信ネットワークの異なる装置がトランザクションを暗号化及び復号化するために暗号化スキーマをどのように用いるかを示すブロック図である。
【図７】通信ネットワークの異なる装置がトランザクションを暗号化及び復号化するために暗号化スキーマをどのように用いるかを示すブロック図である。
【図８】通信ネットワークの異なる装置がトランザクションを暗号化及び復号化するために暗号化スキーマをどのように用いるかを示すブロック図である。
【図９】多くのトランザクションがどのように多数のパケットに暗号化されるかを示す。
【図１】
2005515664.tif 000004
【図２】
2005515664.tif 000005
【図３】
2005515664.tif 000006
【図４】
2005515664.tif 000007
【図５】
2005515664.tif 000008
【図６】
2005515664.tif 000009
【図７】
2005515664.tif 000010
【図８】
2005515664.tif 000011
【図９】
2005515664.tif 000012
【国際調査報告】
2005515664.tif 000013
2005515664.tif 000014