(57)【要約】【課題】メッセージを適切な作業スケジューリングを保証し、反復的及び条件的処理をするように処理する。【解決手段】メッセージの順序処理を必要とする処理ノードが、メッセージの順序処理を必要としない複数の連続した処理ノードにおいて動作するように構成される。順序ノードの上流のノードは、（ｉ）処理中のメッセージと、順序が前記処理中のメッセージの後であり前記ノードの下流に転送されたメッセージとの間のスキューをモニターし、（ｉｉ）スキュー閾値に達したら処理を中断する。順序ノードの上流ノードは、メッセージＩＤで決まる他のメッセージのデルタ以内に、メッセージの出力を制限する。また、フロー経路から削除されたメッセージは、順序処理のためにヌルメッセージにより置き換えられる。子メッセージは順序体系を保存するため親ＩＤを組み込む。【選択図】図３Ａ
2015057710.tif 000002
【特許請求の範囲】
【請求項１】
複数の順序メッセージが流れる第１フロー経路に沿った第１ノードと、
前記第１フロー経路中で複数のメッセージを順序通りに処理して、削除したメッセージの替わりにヌルメッセージを認識する順序処理ノードと
を有するメッセージ処理システムであって、
前記第１ノードは前記複数の順序メッセージのうち一のメッセージを受け取り、該受け取ったメッセージはコンテントを有し、
前記第１ノードは前記第１フロー経路から前記受け取ったメッセージを削除し、前記削除したメッセージを処理のために第２フロー経路に転用し、前記第１ノードは、前記削除したメッセージの替わりに前記第１フロー経路に前記ヌルメッセージを挿入する、
システム。
【請求項２】
前記メッセージにメッセージＩＤを割り当てる割り当てノードをさらに有する、請求項１に記載のシステム。
【請求項３】
前記ヌルメッセージに、前記削除したメッセージと同じメッセージＩＤを割り当てる、請求項１に記載のシステム。
【請求項４】
前記ヌルメッセージは行き先ノードを示す、請求項１に記載のシステム。
【請求項５】
前記第１ノードは、前記受け取ったメッセージのリカバリ不能処理エラーに応じて、前記受け取ったメッセージを削除する、請求項１に記載のシステム。
【請求項６】
前記第１ノードは、前記第１フロー経路の分岐に応じて、前記受け取ったメッセージを削除する、請求項１に記載のシステム。
【請求項７】
前記第１フロー経路の分岐により前記削除したメッセージを再合成し、前記示された行き先ノードに基づきヌルメッセージを削除する合流ノードをさらに有する、請求項６に記載のシステム。
【請求項８】
メッセージを処理し、親メッセージから子メッセージを生成し、親ＩＤに子メッセージの数を示す情報を添付する処理ノードと、
メッセージＩＤを前記子メッセージに割り当てる割り当てノードとをさらに有し、関連する親ＩＤを組み込むように前記子メッセージＩＤをエンコードする、
請求項１に記載のシステム。
【請求項９】
関連する文書を含むメッセージのグループを識別する識別ノードをさらに有する、請求項１に記載のシステム。
【請求項１０】
前記受け取ったメッセージを処理する、前記第１ノードと前記順序処理ノードとを含む複数の連続的処理ノードをさらに有し、
前記第１ノードは、順序通りでないメッセージの出力を許すが、かかるメッセージの出力を他のメッセージのデルタ内に限定するようにさらに構成されている、請求項１に記載のシステム。
【請求項１１】
メッセージの出力の限定は、メッセージＩＤにより決まる、前記他のメッセージのデルタ外におけるメッセージの処理の中断を含む、請求項１０に記載のシステム。
【請求項１２】
各処理ノードは、非同期データ伝送を用いてメッセージを処理するように構成され、前記ヌルメッセージを認識して処理するようにさらに構成されている、請求項１０に記載のシステム。
【請求項１３】
電子処理システムにおけるメッセージ処理方法であって、
複数の順序メッセージが流れる第１フロー経路に沿った第１ノードにおいて、前記複数の順序メッセージのうち一のメッセージを受け取る段階であって、前記一のメッセージはコンテントを有する、段階と、
前記第１ノードにおいて、前記第１フロー経路から前記複数の順序メッセージのうちの前記受け取ったメッセージを削除し、該削除したメッセージのために前記ヌルメッセージを挿入する段階と、
前記除去したメッセージを処理のために第２フロー経路に転用する段階と、
順序処理ノードにおいて、前記第１フロー経路中でメッセージを順序通り処理して、前記削除したメッセージの替わりに前記ヌルメッセージを認識する段階とを有する方法。
【請求項１４】
前記複数の順序メッセージＩＤを前記メッセージに割り当てる段階をさらに有する、請求項１３に記載の方法。
【請求項１５】
前記ヌルメッセージに、前記削除したメッセージと同じメッセージＩＤを割り当てる、請求項１４に記載の方法。
【請求項１６】
前記ヌルメッセージは行き先ノードを示す、請求項１３に記載の方法。
【請求項１７】
前記受け取ったメッセージを削除する段階は、前記受け取ったメッセージのリカバリ不能処理エラーに応じて、前記受け取ったメッセージを削除する段階を含む、請求項１３に記載の方法。
【請求項１８】
前記受け取ったメッセージを削除する段階は、前記第１フロー経路の分岐に応じて、前記受け取ったメッセージを削除する段階を含む、請求項１３に記載の方法。
【請求項１９】
前記第１フロー経路の分岐による複数のメッセージを再合成し、前記示された送り先ノードに基づきヌルメッセージを削除する段階をさらに有する、請求項１８に記載の方法。
【請求項２０】
メッセージを処理し、親メッセージから子メッセージを生成し、親ＩＤに子メッセージの数を示す情報を添付する段階と、
メッセージＩＤを前記子メッセージに割り当てる段階をさらに有し、関連する親ＩＤを組み込むように前記子メッセージＩＤをエンコードする、請求項１４に記載の方法。
【請求項２１】
関連した文書を含むメッセージのグループを識別する段階をさらに有する、請求項１３に記載の方法。
【請求項２２】
前記メッセージを処理し、順序通りでないメッセージの出力を許し、かかるメッセージの出力を他のメッセージのデルタ内に限定する段階をさらに有する、請求項１３に記載の方法。
【請求項２３】
メッセージの出力の限定は、メッセージＩＤにより決まる、前記他のメッセージのデルタ外におけるメッセージの処理の中断を含む、請求項２２に記載の方法。
【請求項２４】
非同期データ伝送を用いてメッセージを処理し、前記ヌルメッセージを認識して処理する段階をさらに有する、請求項２２に記載の方法。
【請求項２５】
メッセージを処理するコンピュータ読み取り可能プログラムを化体した製品であって、前記プログラムは、
複数の順序メッセージが流れる第１フロー経路に沿った第１ノードにおいて、前記複数の順序メッセージのうち一のメッセージを受け取る命令であって、前記一のメッセージはコンテントを有する、命令と、
順序処理ノードにおいて、前記フロー経路中でメッセージを順序通り処理して、前記削除したメッセージの替わりに前記ヌルメッセージを認識する命令とを有する製品であり、
前記第１ノードは、前記第１フロー経路から前記受け取ったメッセージを削除し、該削除したメッセージのために前記ヌルメッセージを挿入し、前記削除したメッセージは処理のために第２フロー経路に転用される
製品。
【請求項２６】
メッセージＩＤを前記メッセージに割り当てる段階をさらに有する、請求項２５に記載の製品。
【請求項２７】
前記ヌルメッセージに、前記削除したメッセージと同じメッセージＩＤを割り当てる、請求項２６に記載の製品。
【請求項２８】
前記ヌルメッセージは行き先ノードを示す、請求項２５に記載の製品。
【請求項２９】
前記受け取ったメッセージを削除する段階は、前記受け取ったメッセージのリカバリ不能処理エラーに応じて、前記受け取ったメッセージを削除する段階を含む、請求項２５に記載の製品。
【請求項３０】
前記受け取ったメッセージを削除する段階は、前記フロー経路の分岐に応じて、前記受け取ったメッセージを削除する命令を含む、請求項２５に記載の製品。
【請求項３１】
前記フロー経路の分岐による複数のメッセージを再合成し、前記示された送り先ノードに基づきヌルメッセージを削除する段階をさらに有する、請求項３０に記載の製品。
【請求項３２】
メッセージを処理し、親メッセージから子メッセージを生成し、親ＩＤに子メッセージの数を示す情報を添付する段階と、
メッセージＩＤを前記子メッセージに割り当てる段階をさらに有し、関連する親ＩＤを組み込むように前記子メッセージＩＤをエンコードする、請求項２６に記載の製品。
【請求項３３】
関連した文書を含むメッセージのグループを識別する段階をさらに有する、請求項２５に記載の製品。
【請求項３４】
前記複数の順序メッセージを処理し、順序通りでないメッセージの出力を許し、かかるメッセージの出力を他のメッセージのデルタ内に限定する段階をさらに有する、請求項２５に記載の製品。
【請求項３５】
メッセージの出力の限定は、メッセージＩＤにより決まる、前記他のメッセージのデルタ外におけるメッセージの処理の中断を含む、請求項３４に記載の製品。
【請求項３６】
非同期データ伝送を用いてメッセージを処理し、前記ヌルメッセージを認識して処理する段階をさらに有する、請求項３４に記載の製品。
【請求項３７】
前記第２フロー経路は、前記受けったメッセージの再帰的処理を許容する、請求項１に記載のシステム。
【請求項３８】
前記第２フロー経路は、前記受けったメッセージの再帰的処理を許容する、請求項１３に記載のシステム。
【請求項３９】
複数の順序メッセージが流れる第１フロー経路に沿った第１ノードと、
前記第１フロー経路中で複数のメッセージを順序通りに処理して、削除したメッセージの替わりにヌルメッセージを認識する順序処理ノードとを有するメッセージ処理システムであって、
前記第１ノードは前記複数の順序メッセージのうち一のメッセージを受け取り、該受け取ったメッセージはコンテントを有し、
前記第１ノードは前記第１フロー経路から前記受け取ったメッセージを削除して、前記削除したメッセージを処理のために第２フロー経路に転用し、
前記第１ノードは、前記削除したメッセージの替わりに前記第１フロー経路に、前記受け取ったメッセージと同じメッセージＩＤに割り当てられる前記ヌルメッセージを挿入する、
システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の方法、システム、及び対応するコンピュータ読み取り可能プログラムを有する製品がメッセージ処理に関する。
【背景技術】
【０００２】
ハイスループットデータフロー処理の一般的なモデリング方法では、データフローを有向グラフとして表す。有向グラフでは、ノードが計算リソースを表し、エッジがノード間のデータ伝送経路を表している。このような場合、非同期データ伝送を用いて、ノードを互いにデカップリングできる。このデカップリングにより、各計算ノードの実行効率をできるだけ高くできる。何故なら、ノードは、下流のノードが処理を完了するのを待たずに、次のメッセージの処理を開始できるからである。場合によっては、複数の計算ノードが、「単一の」計算ノードとして、並行かつ共同して実行でき、多数の作業ユニット（units  of  work）を同時に処理できる。
【０００３】
段階的イベント駆動アーキテクチャ（ＳＥＤＡ）は、計算ノード間に制限キュー（bounded  queues）を挿入することにより、この方法（approach）を改善するものである。ノードＡが他のノードＢに処理データ（work）を転送するとき、ノードＡとノードＢ間のキューがいっぱいであれば、ノードＢがキューの処理データの一部を使うまで、Ａはブロックする。このようにＡをブロックすることにより、Ａが新しい処理データ（work）を使わないようにし、その入力キューをいっぱいにして、その前にある計算ノードをブロックする。かかる技術を利用するプロセスの例として、サーチエンジンによる文書取り込みがある。この文書取り込みでは、サーチエンジンは、後で検索するために、複数の形式の文書（電子メール、ＰＤＦ、マルチメディア、ブログポスティングなど）をすべて処理して、インデックス付けする必要がある。
［関連出願］
本出願は、２００８年６月１７日出願の米国仮出願第６１／０７３，１６４号（発明の名称「順序メッセージ処理」）の利益を主張するものである。上記の出願の教示はその全体をここに参照援用する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この方法は、データフロー処理システムにおける作業を絞る（throttle）効率的な方法である。しかし、特定の計算ノードに対して、それがメッセージを処理する順序を保証することが望ましい場合が多い。例えば、トランザクションのコミットメッセージは、作業がコミットされるまで処理できない。ＳＥＤＡによる並列非同期データフロー処理には、高スループット、低レイテンシで作業を絞る効率が極めて高いが、メッセージの順序を乱す性質がある。
【課題を解決するための手段】
【０００５】
複数の方法、システム、及び対応するコンピュータ読み取り可能プログラムを有する製品がメッセージ処理に関係する。複数の連続した処理ノードは、順序データを必要とするノードを含んでもよい。
【０００６】
文書の情報源（sources）がシステムに入力を供給する。情報源にはファイルシステムリポジトリ、電子メールサーバ、物理的媒体（例えば、ＣＤ−ＲＯＭ、ＤＶＤ）、音声認識システムで認識されたテキスト、データベースなどが含まれる。文書は連続したメッセージに挿入され、システムにより処理される。
【０００７】
メッセージＩＤを連続したメッセージに適用する。メッセージの処理により子メッセージが生成されることもある。子メッセージにはメッセージＩＤが割り当てられ、子メッセージＩＤは関連する親ＩＤを組み込むようにエンコードされる。親メッセージＩＤに、関連する子メッセージの数を示す情報を付加してもよい。
【０００８】
場合によっては、一連のメッセージが、関連する複数の文書を含む。関連する複数のメッセージを含むメッセージは、すべて同時にかつ送られた順序で永続的な記憶にコミットされる必要がある。そのため、関連する文書を含むメッセージのグループは、メッセージＩＤにより識別される。
【０００９】
有利にも、システムが生成するメッセージＩＤナンバーを用いて、ＩＤナンバー、各ノードの特徴、及びそのノードで実行した処理結果によりメッセージを処理してもよい。順序処理を必要とするノードは、メッセージＩＤに基づきそのノードにメッセージを送る（deliver）入力キューを有する。かかるノードは、完全順序モードで、または境界メッセージで分けられたメッセージの「グループ」で、動作可能である。場合によっては、システム生成されたメッセージＩＤナンバーは、そのシステムにおいて一意的である。
【００１０】
順序ノードの上流のノードは、（ｉ）処理中のメッセージと、順序が前記処理中のメッセージの後であり前記ノードの下流に転送されたメッセージとの間のスキューをモニターし、（ｉｉ）スキュー閾値に達したら処理を中断できる。
【００１１】
有利にも、アプリケーションによっては、非同期かつ並行度が高い任意の有向グラフ処理モデルを用いる能力を維持しつつ、任意のノードがメッセージを順序通りに処理する能力を保存する。個々のノードや処理するメッセージの特徴を用いて、システムの全体的な性能を損なうことなく、順序的な制約を満足し、再帰的処理を許容するように、メッセージフローの送り先を決める（direct）ことができる。例えば、計算ノードによっては、順序メッセージ処理を必要としない。同様に、メッセージタイプによっては、（順序メッセージ処理を必要とするノードにより処理されたものであっても）特定の順序で処理する必要がないものもある。２つの異なるＸＭＬ文書からフィールドを抽出するようなメッセージタイプは、どういう順序でも、並列でも実行でき、メッセージのグループの間の境界を表す（例えば、「シャットダウン」、「チェックポイント」、「コミット」など）。さらに、ノードによっては、次の境界メッセージまでに１グループのメッセージをすべて処理する限り、順序メッセージ処理を必要としないものもある。
【００１２】
順序ノードの上流のノードは、メッセージのスキューを、そのメッセージに関連するメッセージＩＤの関数としてモニターする。
【００１３】
各処理ノードは、非同期データ伝送を用いてメッセージを処理できてもよい。さらに、処理ノードは、互いに非結合状態であっても、メッセージを処理できてもよい。また、各処理ノードは、複数のスレッド（threads）を用いて複数のメッセージを同時に処理できてもよい。処理ノードは、ヌルメッセージを認識して処理できる。入力キューが各処理ノードの前段に設けられてもよい。
【００１４】
メッセージを、コンテンツに応じた異なるレートで処理でき、順序通りでないメッセージの出力が可能となる。メッセージの出力を、メッセージＩＤにより決まる他のメッセージのデルタ（スキュー）内に限定してもよい。順序通りでないメッセージの出力からの下流における順序メッセージ処理が可能となる。
【００１５】
メッセージの出力の限定は、メッセージＩＤにより決まる、他のメッセージのデルタ外におけるメッセージの処理の中断を含んでもよい。
【００１６】
第１ノードは、フロー経路において一連の順序メッセージのうち一メッセージを削除し、削除したメッセージの替わりにヌルメッセージを挿入することができる。順序処理ノードは、フロー経路中でメッセージを順序通り処理して、削除したメッセージの替わりにフロー経路におけるヌルメッセージを認識できる。
【００１７】
有利にも、アプリケーションによっては、メッセージＩＤが一致するヌルメッセージを用いてメッセージの順序を維持する。例えば、あるノードにおける文書の処理の結果が条件付きであれば（すなわち、メッセージを２つ以上のノードに転送する、またはメッセージを複数のサブメッセージに分離して複数のノードに送る場合）、分岐ノードを用いる。分岐ノードがその下流ノードの１つだけ（または全部未満）にメッセージを転送する場合、メッセージＩＤが一致するヌルメッセージを、メッセージを受け取らないノードに送る。各メッセージには「ｎ個のうちの１つ」であることを示す情報を添付する。ここでｎは下流ノードの数を表す。同様に、メッセージを削除したとき、ヌルメッセージをシステムに挿入し、処理される他のメッセージの順序を維持する。分岐した処理経路が合流（rejoin）する場合、サブメッセージを再合成してヌルメッセージを破棄する合流計算ノードを挿入する。
【００１８】
メッセージにリカバリ不能な処理エラーが発生したとき、メッセージを破棄する。メッセージは、フロー経路の分岐に応じて削除される。さらに、第１ノードはフロー経路からメッセージを削除してもよい。破棄したメッセージの替わりにヌルメッセージを用いて、順序処理を容易にする。
【００１９】
複数のフロー経路に分岐したメッセージは、再結合されて、元のフロー経路を再構成する。元のフロー経路の再構成とネストしたノード分岐を容易にするため、ヌルメッセージにおいて送り先ノードを示し、合流ノードがメッセージを再結合してフロー経路を再構成し、合流ノードが送り先ノードであるヌルメッセージを削除する。
【００２０】
文書タイプノードは、（ｉ）メッセージに含まれる文書タイプに基づき前記メッセージを構成メッセージノードに分岐し、（ｉｉ）前記メッセージノードを下流処理ノードに転送し、（ｉｉｉ）下流処理ノードに転送する、メッセージノードが特定されていないヌルメッセージを生成できる。
【００２１】
複数の文書処理ノードは、文書タイプを有するメッセージを処理するようにそれぞれ構成されていてもよい。
【００２２】
合流ノードは、文書処理ノードで処理された構成メッセージノードを受け取り、ヌルメッセージを削除してもよい。
【００２３】
本方法、システム、及び対応する製品のその他の態様と効果は、図面、詳細な説明、及び請求の範囲から明らかになるであろう。これらはすべて、本方法、システム、及び対応する製品の原理を例として示すものである。
【図面の簡単な説明】
【００２４】
上記のものは、添付した図面に示した本発明の実施形態の、以下に記載した具体的な説明により明らかになるであろう。異なる図面においても同じ参照文字は同一のものを示している。図面は必ずしも寸法通りではなく、本発明の実施形態の図示に当たり強調した部分もある。
【図１Ａ】非同期かつ並列度の高い任意有向グラフ処理モデルのシステムを示す図である。
【図１Ｂ】再帰的メッセージ処理及び非同期かつ並列度の高い任意有向グラフ処理モデルの他のシステムを示す図である。
【図１Ｃ】非同期かつ並列度の高い任意有向グラフ処理モデルの、分岐を含む他のシステムを示す図である。
【図２】非同期かつ並列度の高い任意的有向グラフ処理モデルの、スキュー検出を利用する方法を示すフロー図である。
【図３Ａ】非同期かつ並列度の高い任意的有向グラフ処理モデルの、ヌルメッセージを使用する方法を示すフロー図である。
【図３Ｂ】順序処理を含む、非同期かつ並列度の高い任意的有向グラフ処理モデルの、ヌルメッセージを使用する方法を示すフロー図である。
【図３Ｃ】フロー経路を再形成する、非同期かつ並列度の高い任意的有向グラフ処理モデルの、ヌルメッセージを使用する方法を示すフロー図である。
【図４】非同期かつ並列度の高い任意的有向グラフ処理モデルの、マルチパートメッセージＩＤを使用する方法を示すフロー図である。
【図５Ａ】有向グラフを用いて文書取り込みシステムにおける複数の処理ステップ（ノード）を表す別の実施例を示す図である。
【図５Ｂ】有向グラフを用いて文書取り込みシステムにおける複数の処理ステップ（ノード）を表す別の実施例を示す図である。
【図５Ｃ】有向グラフを用いて文書取り込みシステムにおける複数の処理ステップ（ノード）を表す別の実施例を示す図である。
【図５Ｄ】有向グラフを用いて文書取り込みシステムにおける複数の処理ステップ（ノード）を表す別の実施例を示す図である。
【発明を実施するための形態】
【００２５】
本発明の実施形態を以下に説明する。
【００２６】
ここに引用する特許、公開公報、参照文献の教示は、そのすべてをここに参照援用する。
【００２７】
文書と構造化データの処理と、インデックス付けした検索可能データ記憶装置への取り込みは、多くのステップを要し、そのうちの一部は特定の順序で実行しなければならず、その他は並列に処理できる。文書の処理と取り込みを容易にするため、文書を、一意的なメッセージＩＤを有するメッセージ中に保持する。ここで、文書とは、ｐｄｆファイル、ビデオ、オーディオ、電子メールなどの非構造化データ、またはＸＭＬファイル、ｃｓｖファイル、データベースソースから受け取ったデータなどの構造化データをいう。さらに、一部の文書（例えば、複数の添付ファイルを有する電子メール）の処理には、複数の処理スレッド、異なる処理時間、及び再帰的処理が生じる可能性がある。こうした複雑性のため、メッセージとメッセージコンポーネントの順序処理が不連続となる。真に非同期の処理は、メッセージの異なる要素を異なる時間に処理し、図１Ａないし図１Ｃに示したように、順序が狂った（out  of  order）処理となってしまう。
【００２８】
図１Ａは、非同期かつ並列度の高い任意有向グラフ処理モデルのシステムを示す。１つ以上の文書１１０が、レコードベース・データベース管理システム（ＲＤＢＭＳ）などの文書記憶装置１００からシステムに入力される。文書１００はメッセージ１１１に挿入される。各メッセージは一意的なメッセージＩＤを有する。処理ノード１２０ａ−ｃは、メッセージ１１１を受け取り、その中の文書を処理する。各処理ノード１２０ａ−ｃは、複数のスレッド（threads）を有し、多くのメッセージ１１１を同時に処理できる。各処理ノードの前には入力キュー１２５ａ−ｄが設けられている。各ノードは、入力キュー１２５ａ−ｄにより、キューがいっぱいになるとその前のノードをブロックするので、リソースを能力以上に割り当てずにメッセージを処理できる。このように、入力キュー１２５ａ−ｄによりシステム全体の負荷を制限する。各メッセージは、処理されると、例えば、インデックス付けされた検索可能データ記憶装置１４０に取り込まれる。各処理ノード１２０ａ−ｃは、メッセージ１１１の順序処理（ordered  processing）を要しない。しかし、順序処理ノード１３０は、順序付けてメッセージ１１１を処理する必要がある。結果として、順序処理ノード１３０は、処理を中断して、一連のメッセージ（sequential  set  of  messages）がそろうのを待たねばならない。一連のメッセージは、関連した文書を含む一組のメッセージであってもよい。順序処理ノード１３０に一連のメッセージがそろわないようなシナリオでは、システムが停止する。代替策としては、キュー１２５ｂを制限せずに、順序処理ノード１３０がすべてのメッセージ１１１にアクセスできるようにする。しかし、この代替策では、キューが有する負荷制限という特性が損なわれる。
【００２９】
図１Ｂは、非同期かつ並列度の高い任意有向グラフ処理モデルを用いる、再帰的メッセージ処理を有する他のシステムを示す。図示したように、文書１１０が添付ファイル１３７（ｄｏｃファイル、ｐｄｆファイル、画像、ビデオ、ｚｉｐファイルなど）を含む電子メールである場合、メッセージの一部は他の部分とは関わりなく処理・記憶され、データベースが不完全で不正確なものとなってしまう可能性がある。これが起こるのは、添付ファイルに追加的処理（ｕｎｚｉｐ、スキャン、インデックス付けなど）が必要だが、かかる処理をするリソースがビジー状態である場合である。例えば、処理ノード１２０ｂは、電子メール処理ノード１３５に、文書１１０、すなわち添付ファイル１３７を有する電子メールメッセージを送る。電子メール処理ノード１３５は、電子メールから添付ファイル１３７を取り出し、それを処理ノード１２０ａに送る。同時に、電子メール処理ノード１３５は、文書１１０のテキストを入力キュー１２５ｃに送る。それゆえ、電子メールメッセージは、それの添付ファイルの十分前に処理される。あるいは、場合によっては、文書１１０のテキストがノード１２０ｃに届く前に、添付ファイル１３７を処理して、添付ファイル１３７が文書１１０のテキストの前にインデックスに届くようにしてもよい。
【００３０】
図１Ｃは、非同期かつ並列度の高い任意的有向グラフ処理モデルにおいて分岐を含むシステムを示している。例えば、分岐ノード１１５が一連の文書１１０ａ−ｃを受け取ったものと仮定する。分岐ノード１１５は、文書を受け取ると、処理条件に基づいて、第１の文書１１０ａと第３の文書１１０ｃとを経路Ａに送る。同様に、分岐ノード１１５は、第２の文書１１０ｂを経路Ｂに送る。各フロー経路の処理ノードが順序処理を要しない場合、システムはスムースに動作し続け、合流ノード（joining  node）１４５は全ての文書を受け取り、それを再結合してインデックス１４０に送る。
【００３１】
この例では、フロー経路Ａの順序ノード１３０が順序処理（ordered  processing）を要する。順序ノード１３０は、第１の文書１１０ａと第３の文書１１０ｃとを受け取り、第２の文書１１０ｂを受け取るまで処理を停止する。しかし、第２の文書１１０ｂはフロー経路Ｂに送られてしまったので、順序ノード１３０が第２の文書１１０ｂを受け取ることはない。そのため、システムにはエラーが発生する。
【００３２】
一般的に、非同期かつ並列度の高い任意的有向グラフ処理モデルを用いる機能を維持しつつ、必要なメッセージの順序を保存する方法やシステムがある。個々のノードや処理するメッセージの特徴を用いて、システムの全体的な性能を損なうことなく、順序的な制約を満足し、再帰的処理を許容するように、メッセージフローの送り先を決める（direct）ことができる。例えば、計算ノードによっては順序付けたメッセージ処理を必要としないものがあり、メッセージのタイプによっては特定の順序で処理する必要がないものもある。
【００３３】
メッセージをシステムに取り込むとき、数字が大きくなっていく（increasing）メッセージＩＤでメッセージをマークし、処理ノードの順序的特徴に基づくメッセージを処理すべき順序を示す。このメッセージＩＤは、取り込んだときの順序を再構成できるものであれば、どんなデータであってもよい。順序付けたメッセージ処理を必要とする計算ノードは、そのように注釈され、その前にはメッセージＩＤ番号に基づく順序でメッセージを送る、修正入力キューを設ける。
【００３４】
順序処理ノードの上流のノードは、各メッセージＩＤのスキュー閾値（skew  thresholds）をモニターするように構成できる。上流ノードは、スキュー閾値に到達すると、下流の順序処理ノードが、その入力キューが文書により過負荷にならずに一連の文書に対応するメッセージＩＤを受け取るように、メッセージの処理を調整する。順序メッセージ処理を必要としないノードは、メッセージＩＤ番号を考慮せずに、他のノードと並列に実行できる。メッセージのタイプによっては、サブメッセージ（例えば、複数のメッセージ添付ファイル）の集まりを意味するメッセージの「グループ」間の境界を意味するものもある。処理ノードに境界メッセージ（グループになったメッセージの開始または終了を示すメッセージ）が到着すると、その境界メッセージを完全に処理するまで、新しいメッセージ（単一メッセージまたは次のグループに属する複数のメッセージ）の送りは中断される。ノードによっては、次の境界メッセージまでに１グループのメッセージをすべて処理する限り、順序メッセージ処理を必要としないものもある。
【００３５】
図１Ａに示したように、順序処理ノード１３０は、順序付けたメッセージの処理を必要とする。順序処理を必要としない処理ノード１２０ａ−ｂは、一般的には、メッセージをどんな順序でも処理する。結果として、順序処理ノード１３０は、一連のメッセージを受け取るまで、処理を中止しなければならない。しかし、順序処理ノード１３０は、一連のメッセージの最後のメッセージ（a  message  that  completes  a  sequential  set  of  messages）を受け取ると、メッセージで過負荷になってしまう場合がある。そのため、処理ノード１２０ａ−ｂは、スキュー検出を利用して、順序処理を必要とする下流ノードがメッセージで過負荷になるのを防止する。
【００３６】
図２は、非同期かつ並列度の高い任意的有向グラフ処理モデルの、スキュー検出を利用する方法２００を示すフロー図である。この方法は、用いるメッセージＩＤ案にかかわらず、スキューの精密な尺度を提供する。特に、この方法は、メッセージＩＤデータが数字であることには依存しない。他の方法を用いて、メッセージＩＤ案の場合のスキューを計算または評価してもよい。ステップ２０５において、図１に示した処理ノード１２０ａは、数字が増えるメッセージＩＤを有するメッセージを受け取る。メッセージＩＤは、処理ノードの順序的特徴に基づく、メッセージを処理すべき順序を示す。処理ノード１２０ａは、順序処理は必要としないが、図１の順序処理ノード１３０における順序処理をやりやすくするために、スキュー検出を行わねばならない。次に、ステップ２１０にいて、受け取ったメッセージをメッセージＩＤに従って順序リスト（ordered  list）に入れる。
【００３７】
ステップ２２０では、順序リスト上の各メッセージについてスキューカウントをインクリメントする。スキューカウントを、メッセージＩＤから最大メッセージＩＤまでの処理ノード１２０ａで処理されるメッセージ数として計算する。処理ノード１２０ａより下流での順序メッセージ処理を容易にするため、処理ノード１２０ａは、現在処理している他のメッセージよりもメッセージＩＤが大きい、所定のスキュー閾値までのメッセージの並列処理のみを行う。
【００３８】
例えば、スキュー閾値が２０メッセージと予め決まっており、処理ノードが、メッセージＩＤが「１」のメッセージを現在処理している場合、処理ノードは、メッセージＩＤが２１のメッセージの並列処理は行わない。そのため、ステップ２３０において、順序リストの最初のスキューカウントを取って、現在のスキューカウントを計算する。リストの最初のメッセージは、現在処理されているメッセージＩＤが最低のメッセージである。ステップ２４０において、ノードは、スキュー閾値に達したか判断する。達していなければ、ステップ２４５ａにおいて、ノードはメッセージを処理し、ステップ２５０において、処理したメッセージを順序リストから削除する。スキュー閾値に達したら、ステップ２４５ｂにおいて、ノードは、メッセージが完全に処理され、ステップ２３０を用いて現在の閾値を計算するまで、メッセージの処理を中断する。方法２００を具体的なシーケンスを有するものとして示したが、別の実施形態ではシーケンスは異なってもよい。
【００３９】
有向グラフで分岐が生じた場合（例えば、複数のメッセージコンポーネントが異なる処理ノードに送られた場合）、メッセージが送られていない分岐のすべてに、同じメッセージＩＤを有する特殊なヌルメッセージを送る。同様に、システム中のノードがメッセージを削除する場合、メッセージＩＤが最初のメッセージと一致するヌルメッセージ（Null  message）で、削除するメッセージを置き換える。また、ヌルメッセージは、ノードにリカバリ不能の処理エラーが発生してメッセージが失われたときに、失われたメッセージを置き換えるために用いる。分岐した処理経路が再び合流するとき、特殊な合流計算ノード（join  computation  node）が、メッセージＩＤが同じすべてのメッセージを合成し、そのメッセージに関連するヌルメッセージをドロップする。ヌルメッセージにより、順序処理ノードは、順序処理を中断することなく、削除したメッセージのプレースホルダー（place  holder）としてヌルメッセージを使える。
【００４０】
図３Ａは、非同期かつ並列度の高い任意的有向グラフ処理モデルの、ヌルメッセージの使用方法３００を示すフロー図である。ステップ３１０において、処理ノードは、メッセージＩＤが大きくなるメッセージを受け取る。ステップ３２０において、ノードは、状態に応じて、メッセージをフロー経路から削除しなければならないか、判断する。状態には、例えば、（ｉ）他のフロー経路へのメッセージの分岐、（ｉｉ）削除、または（ｉｉｉ）リカバリ不能な処理エラーが含まれる。メッセージを削除する必要がなければ、ステップ３２０ａに進む。ノードはメッセージを処理して、次のノードに送る。
【００４１】
しかし、ノードは、メッセージを削除しなければならないと判断すると、メッセージＩＤが削除するメッセージと一致するヌルメッセージを生成する。ステップ３３０において、ヌルメッセージには、送り先ノードの情報を付加する（annotate）。次に、ステップ３４０において、ノードは、削除したメッセージの替わりに、フロー経路にヌルメッセージを挿入する。方法３００を具体的なシーケンスを有するものとして示したが、別の実施形態ではシーケンスは異なってもよい。
【００４２】
図３Ｂは、順序処理を含む、非同期かつ並列度の高い任意的有向グラフ処理モデルの、ヌルメッセージを使用する方法３０１を示すフロー図である。ステップ３１１において、順序処理ノード（ordered  processing  node）は、メッセージＩＤが大きくなるメッセージ（messages  with  increasing  message  ID）を受け取る。ステップ３５０において、ノードが、一連のメッセージ中にヌルメッセージを受け取ったか、判断する。受け取っていれば、ノードは、ステップ３７０において、ヌルメッセージをプレースホルダーとして用い、ステップ３７５において、メッセージを順序通りに処理する。受け取っていなければ、ステップ３６０において、順序処理ノードは、一連のメッセージを順序通りに処理する。方法３０１を具体的なシーケンスを有するものとして示したが、別の実施形態ではシーケンスは異なってもよい。
【００４３】
図３Ｃは、フロー経路を再形成する、非同期かつ並列度の高い任意的有向グラフ処理モデルの、ヌルメッセージを使用する方法３０２を示すフロー図である。ステップ３１２において、合流ノードは、異なるフロー経路から、メッセージＩＤが増加するメッセージを受け取る。ステップ３８０において、合流ノードがヌルメッセージを受け取ったか判断する。受け取っていなければ、合流ノードは、メッセージを処理し、次の処理ノードに送る。受け取っていれば、ステップ３９０において、さらに、合流ノードは、自ノードがヌルメッセージの送り先ノードであるか判断し、送り先ノードであれば、ヌルメッセージを削除する。送り先ノードでなければ、ステップ３８５に進む。方法３０２を具体的なシーケンスを有するものとして示したが、別の実施形態ではシーケンスは異なってもよい。実施形態によっては、送り先ノードの情報（destination  node  annotation）を利用しなくてもよい（合流ノードは自ノードが送り先であると仮定する）。しかし、こうした実施形態では、計算分岐のネスト（nested  branching  of  computations）はサポートされない。
【００４４】
図１Ｃを参照して、ステップ３１０において、メッセージを受け取るノードが分岐ノード１１５であると仮定する。分岐ノード１１５は、メッセージＩＤが「１」、「２」、「３」と大きくなる３つのメッセージ１１０ａ−ｂを受け取っている。この例では、分岐ノードは、ステップ３２０において、処理条件に応じて、メッセージＩＤが「１」（１１０ａ）と「３」（１１０ｃ）のものをフロー経路Ａに送り、メッセージＩＤが「２」（１１０ｂ）のものをフロー経路Ｂに送っている。フロー経路Ａは順序処理ノード１３０を含むので、分岐ノードはメッセージＩＤが「２」のヌルメッセージを生成する。ステップ３３０において、分岐ノード１１５は、送り先が合流ノード１４５であることを示す情報をヌルメッセージに付加する。次に、ステップ３４０において、分岐ノードは、メッセージ１１０ｂの替わりに、フロー経路Ａに、メッセージＩＤが「２」のヌルメッセージを挿入する。
【００４５】
この場合、メッセージＩＤ「１」、「３」と、ヌルメッセージＩＤ「２」とが処理ノード１２０ａに送られ、下のメッセージＩＤ「２」は処理ノード１２０ｃに送られる。ステップ３１０において、順序処理ノードがメッセージを受け取る。次に、順序処理ノードは、ステップ３５０において、ヌルメッセージを受け取ったことを判断する。次に、順序処理ノードは、ステップ３７０において、メッセージを順序通りに処理するため、ヌルメッセージをプレースホルダーとして用いる。ステップ３７５において、受け取ったメッセージを順序通りに処理する。
【００４６】
次に、ステップ３１２において、合流ノードは、フロー経路Ａとフロー経路Ｂからメッセージを受け取る。合流ノードは、ステップ３８０において、ヌルメッセージを受け取ったと判断する。元のメッセージＩＤ「２」より前にヌルメッセージを受け取っているかも知れない。それゆえ、合流ノードは、ステップ３９０において、ヌルメッセージの送り先がその合流ノードであるか判断する。この場合、ヌルメッセージの送り先は合流ノードである。元のメッセージＩＤ「２」の送り先は同じだからである。ステップ３９５において、ヌルメッセージＩＤ「２」には送り先が合流ノードであるとの情報が付加されているので、合流ノードにはヌルメッセージを削除してもよいことが分かる。この情報（annotation）により、行流ノードは、各フロー経路からすべてのメッセージを受け取らなくても、ヌルメッセージを処理できる。
【００４７】
親メッセージに対する子メッセージのような新しく生成したメッセージには、親メッセージのメッセージＩＤを組み込んだメッセージＩＤを割り当ててもよい。さらに、親メッセージＩＤには、関連する子メッセージの数を示す情報を付加する。このように、順序処理を必要とするノードが親メッセージを受け取ると、そのノードとその前のノードとは、処理を調整するので、親メッセージと子メッセージの順序処理ができる。同様に、合流ノードは、フロー経路を再構成するために、関連する文書を含むすべてのメッセージを受け取った時を判断できる。
【００４８】
図４は、非同期かつ並列度の高い任意的有向グラフ処理モデルの、マルチパートメッセージＩＤを使用する方法４００を示すフロー図である。ステップ４１０において、メッセージＩＤを受け取り、連続したメッセージＩＤを割り当てる。次に、ステップ４２０において、メッセージを処理して、必要に応じて子メッセージを生成する。例えば、電子メール等のメッセージは複数の添付ファイルを含み、各添付ファイルに対して子メッセージを生成する。ステップ４３０において、子メッセージには、親メッセージＩＤを組み込んでエンコードしたメッセージＩＤが付与される。ステップ４４０において、親メッセージＩＤには、子メッセージの数を示す情報を付加する。この情報（annotation）により、下流ノードは、関連するすべてのメッセージを受け取ったか分かる。方法４００を具体的なシーケンスを有するものとして示したが、別の実施形態ではシーケンスは異なってもよい。
【００４９】
図１Ｂを参照して、ステップ４１０において、メッセージＩＤが「１」のメッセージ１１０は複数の添付ファイル１３７を含む電子メールメッセージであり、メッセージＩＤが大きくなる連続したメッセージとともに受け取ったものと仮定する。メッセージをシステムで処理する。ステップ４２０において、電子メール処理ノード１３５は、電子メールメッセージを処理して、各添付ファイル１３７に対して子メッセージを生成する。メッセージ１１０、例えばメッセージＩＤが「２」のメッセージには連続したメッセージが続くので、電子メール処理ノードは、添付ファイル１３７には、増加するメッセージＩＤ「２」を割り振れない。結果として、各添付ファイル１３７は、親のメッセージＩＤを組み込んだメッセージに挿入される。この場合、親ＩＤは「１」であり、２つの添付ファイルがあれば、第１の添付ファイルをマルチパートメッセージＩＤが「１．１」のメッセージに挿入し、第２の添付ファイルをマルチパートメッセージＩＤが「１．２」のメッセージに挿入する。ステップ４４０において、親ＩＤには２つの子文書があるとの情報を付加（annotate）する。このエンコード方法により、システムが受け取った連続する各文書に再付番（renumber）せずに、新しいメッセージを挿入できる。
【００５０】
さらに、子文書「１．１」は２つの子を有すると仮定する。ステップ４２０において、子メッセージを生成する。ステップ４３０において、子メッセージにＩＤ「１．１．１」と「１．１．２」を割り当てる。そして、ステップ４４０において、子文書「１．１」に２つの子文書があるとの情報を付加する。
【００５１】
図５Ａ−Ｄは、有向グラフを用いて文書取り込みシステムにおける複数の処理ステップ（ノード）を表す別の実施例を示す図である。文書の情報源は処理ノード５０２を介してシステムに入力を供給する。情報源にはファイルシステムリポジトリ、電子メールサーバ、物理的媒体（例えば、ＣＤ−ＲＯＭ、ＤＶＤ）、音声認識システムで認識されたテキスト、データベースなどが含まれる。処理ノード５０２は、外部情報源からの文書の取り込みを処理ステップに分けて管理する。または、添付文書（additional  documents）を処理中に「発見」し、システムに戻す場合もある。文書は最初に文書タイプスプリッタ５０４に送られる。スプリッタ５０４は、そのメッセージを、その後段のどの処理ノードに送るか判断する。例えば、システムは、テキスト（電子メールテキストとともにヘッダ情報及び／またはルーティング情報を含む場合もある）を処理する電子メールノード５０６、ｐｋＺＩＰまたはその他のファイルアーカイブプログラムやファイル圧縮プログラムを用いて作成した文書を処理する．ｚｉｐ処理ノード５０８、マイクロソフトワード（またはＧＯＯＧＬＥ  ＤＯＣＳ、ＯｐｅｎＯｆｆｉｃｅなどの文書処理プログラム）を用いて作成した文書を処理する．ｚｉｐ処理ノード５０８、ポータブルドキュメントフォーマットの文書を処理する．ｐｄｆ処理ノード５１２などを含む。図示はしていないが処理ノードの他の例として、画像を処理する．ｊｐｇ処理ノード、映画を処理する．ｍｐｅｇノード、オーディオを処理する．ａｖｉノード、その他いろいろな構成のデータフォーマットを処理するノードなどがある。ここに示した例には異なる４つの処理ノードがある。しかし、ノードの数はいくつでもよく、システムで利用する文書の数やタイプに応じて決まる。場合によっては、あるタイプの文書を頻繁に受け取り、及び／またはその処理が多くのリソースを要する場合、複数の処理ノードを同じ機能に割り当てる（例えば、３つのノードが．ｊｐｇファイルの処理に使われる）。
【００５２】
場合によっては、さらに分析をして、メッセージの最も基本的な要素の標準的な表示を求める必要がある。例えば、電子メールは添付ファイルを有し、各添付ファイルを異なる処理ノードで異なる処理をする必要があるかも知れない。さらに、文書インデックスのインテグリティを維持するため、２つ以上のコンポーネントを有する文書は、コンポーネントをすべて処理するまでは、インデックスに書き込むべきではない場合もある。言い換えると、電子メールの添付ファイルの処理が失敗した場合、その電子メールのテキスト（及び処理できたその他のコンポーネントや添付ファイル）をインデックスに書き込むべきではない。実装の仕方によっては、部分的文書インデックス化が可能であり、その他の実装では、この制約が例外なく強制される。場合によっては、どの「失敗」は許容でき、どれは致命的である判断するルールを用いてもよい。マルチパートメッセージＩＤを用いて、親メッセージ（例えば、電子メールを含むメッセージ）を子メッセージ（例えば、電子メールの添付ファイル）に関連付ける。親メッセージに、生成した子メッセージの数を示す情報を添付する（annotate）。
【００５３】
（処理ノード５０６、５０８、５１０、５１２のように）複数の処理分岐を用いる実施形態では、各分岐が処理したメッセージを送る共通ノードとして分岐合流ノード５１４を設ける。分岐合流５１４は、インデックスに取り込む文書及び／またはテキストを含むメッセージを識別し、ヌルメッセージ（null  messages）を削除する。さらに、分岐合流５１４は、マルチパートメッセージＩＤと親メッセージに付加された情報（parent  annotation）とを用いて、インデックスに同時に取り込む必要がある文書を識別する。
【００５４】
順序メッセージ処理を容易にするため、各処理ノードはメッセージキューを含む。メッセージキューを用いて、ノードでの処理を待つ複数のメッセージを記憶し、及び／またはメッセージが順序通りに処理キューに到着しないときに、メッセージＩＤに基づきメッセージを並べ替える。
【００５５】
図５Ａは、本発明の一実施形態により、単純な電子メールメッセージ（例えば、メッセージテキストは有するが添付ファイルを有さない電子メール）を処理するか示す。電子メールは、システムに入ると、メッセージＩＤ０が割り当てられたメッセージに挿入され、文書タイプスプリッタキュー５０４ａに転送される。文書は、リソースがあればスプリッタ５０４に送られる。スプリッタ５０４は、そのメッセージを電子メールであると認識し、電子メール処理ノード５０６による処理に備えて電子メールキュー５０６ａに転送する。同時に、スプリッタ５０４は、３つのヌルメッセージ（または、各ダウンストリームキューを満たすのに必要な数だけ）を生成し、．ｚｉｐキュー５０８ａ、．ｄｏｃキュー５１０ａ、及び．ｐｄｆキューに転送する。ヌルメッセージにはすべて同じメッセージＩＤである０を与え、分岐合流５１４の送り先の情報を添付する。ヌルメッセージにより、使用されない分岐にもメッセージを送ることにより（filling  the  game  that  would  result  otherwise）、順序メッセージ処理を必要とするコンポーネントを含む分岐が可能となる。
【００５６】
電子メールが添付ファイルを含む場合、その電子メールを含むメッセージに、その電子メールと関連する子メッセージがあることを示す情報を添付して、関連するすべてのメッセージを受け取ったことを合流ノード５１４が分かるようにする。ダウンストリームでの処理のために新しい「子」メッセージを生成するので、現在のメッセージには「子あり」とのマークを付し、新しい子メッセージには親ＩＤを組み込んでエンコードしたメッセージＩＤを割り当てる。このようにメッセージを相互参照することにより、すべての子（またはその親メッセージと兄弟メッセージ）が同じノードに到着するまで、メッセージを後の処理ノードに留める。
【００５７】
ヌルメッセージは、処理されることなく合流キュー５１４に転送され、すべての上流ノードからのメッセージが届くのを待つ。処理が必要なメッセージ（例えば、電子メールノード５０６で処理されるメッセージＩＤ０）は処理され、合流キュー５１４ａに転送され、合流ノード５１４が空いた時にリリースされる。合流ノード５１４では３つのヌルメッセージが削除されるので、集計（aggregator）ノード５１６はメッセージを処理しなくてもよく、メッセージは取り込みのためインデックスキュー５１８に転送される。
【００５８】
図５Ｂ−５Ｄは、もう少し複雑な場合を示しており、電子メールメッセージが２つの添付ファイル、すなわち．ｐｄｆファイルと、複数の圧縮された．ｄｏｃファイルを含む．ｚｉｐファイルとを有する。図５Ｂを参照して、電子メールノード５０６で処理後、各添付ファイルは、次のマルチパートメッセージＩＤが割り当てられ、処理ノード５０２に戻され、文書キュー５０４ａに入れられる。文書スプリッタ５０４は、．ｐｄｆファイルを含む子メッセージを．ｐｄｆキュー５１２ａに転送し、．ｚｉｐファイルを含む子メッセージを．ｚｉｐキュー５０８ａに転送する。この２つの子メッセージは、親メッセージＩＤの０でエンコードされており、それぞれの処理ノード５０８と５１２で処理される。．ｚｉｐノード５０８は、．ｚｉｐファイルを処理するとき、．ｚｉｐファイルには複数のファイルが含まれており、メッセージにはそれに関連するｎ個の子メッセージがあるとの情報を添付する。ここで、ｎは．ｚｉｐファイルに含まれたファイル数である。子メッセージを合流キュー５１４ａに転送する。合流ノードは、（２つのメッセージと２つのヌルメッセージがあることに基づいて）メッセージＩＤが同じすべてのメッセージを受け取ったと判断し、ヌルメッセージを削除する。しかし、合流ノードは、．ｚｉｐ子メッセージにはさらに２つのメッセージ（．ｄｏｃファイル）が含まれているとの情報が付加されているので、２つのメッセージを処理せずに、．ｚｉｐ子メッセージに含まれる２つのメッセージの処理の完了を待つ。
【００５９】
図５Ｃを参照して、．ｚｉｐファイルのコンテンツは、マルチパートメッセージＩＤを割り当てられ、処理ノード５０２に戻され、文書キュー５０４ａに転送される。スプリッタ５０４は、新しいマルチパートメッセージＩＤを有する２つの．ｄｏｃファイルを．ｄｏｃキュー５１０ａに転送し、新しいマルチパートメッセージＩＤを有するヌルメッセージを他の各処理ノードキュー５０６ａ、５０８ａ、及び５１２ａに転送する。新しいマルチパートメッセージＩＤを有するすべてのメッセージは、合流キュー５１４ａに送られ、ヌルメッセージは分岐合流５１４で削除される。合流ノードは、最初のマルチパートメッセージＩＤ（２つの子）と新しいマルチパートメッセージＩＤ（１つの子）を有する元のメッセージに示された子メッセージの受け取りを待ってから、メッセージをインデックスキュー５１８に転送する。図５Ｄは、インデックスキュー５１８にある、メッセージＩＤが０のメッセージと、その子メッセージ（．ｚｉｐファイルと．ｐｄｆファイル）と、孫メッセージ（．ｄｏｃファイル）とを階層的に示している。
【００６０】
本明細書により説明したモジュールは、好適なプログラミング言語（Ｃ＋＋、Ｃ＃、Ｊａｖａ、Ｖｉｓｕａｌ  Ｂａｓｉｃ、ＬＩＳＰ、ＢＡＳＩＣ、ＰＥＲＬなど）を用いた、プロセッサ上で動作するソフトウェアプログラムとして、及び／またはハードウェアデバイス（例えば、ＡＳＩＣ、ＦＰＧＡ、プロセッサ、メモリ、記憶装置など）として、その全部または一部を実施することができる。
【００６１】
本発明は、ハードウェア、ソフトウェア、またはこれらの組み合わせで実現することができる。本発明による方法とシステムの実施は、１つのコンピュータシステムにおいて集中的に、または異なる要素を相互接続された複数のコンピュータシステムに分散して分散的に実現することができる。いかなる種類のコンピュータシステムでも、またはここに説明した方法を実行するように構成されたその他の装置でも、ここに説明した機能の実行に適している。
【００６２】
ハードウェアとソフトウェアの典型的な組み合わせとしては、汎用コンピュータシステムと、それにロードされ実行されるとそのコンピュータシステムをここで説明した方法を実行するように制御するコンピュータプログラムとの組み合わせがある。本発明をコンピュータプログラム製品として実施することもできる。このコンピュータプログラム製品は、ここで説明した方法の実施を可能とするすべての特徴を有し、コンピュータシステムにロードされた時、これらの方法を実行することができる。
【００６３】
本発明の場合にコンピュータプログラムまたはアプリケーションとは、情報処理能力を有するシステムに直接、またはａ）他の言語、コード、または記法への変換、またはｂ）異なる素材形式での再生のいずれか、または両方の後に、特定の機能を実行させることを目的とする一組の命令のいかなる言語、コード、または記法のいかなる表現も含む。本発明は、その精神と本質的な属性から逸脱することなく、他の形式で化体することもできることは重要である。上記の実施形態は、すべての点で例示でありここに説明した発明を限定するものではないと考えなければならない。
【００６４】
実施形態を参照して本発明を図示し、説明したが、当業者には言うまでもなく、請求の範囲が含む本発明の範囲から逸脱することなく、形式的及び詳細上の変更が可能である。
【符号の説明】
【００６５】
１００  文書記憶装置
１１０  文書
１１０ａ−ｃ  文書
１１１  メッセージ
１２０ａ−ｃ  処理ノード
１２５ａ−ｄ  入力キュー
１３０  順序処理ノード
１３７  添付ファイル
１４０  データ記憶装置
【図１Ａ】
2015057710.tif 000003
【図１Ｂ】
2015057710.tif 000004
【図１Ｃ】
2015057710.tif 000005
【図２】
2015057710.tif 000006
【図３Ａ】
2015057710.tif 000007
【図３Ｂ】
2015057710.tif 000008
【図３Ｃ】
2015057710.tif 000009
【図４】
2015057710.tif 000010
【図５Ａ】
2015057710.tif 000011
【図５Ｂ】
2015057710.tif 000012
【図５Ｃ】
2015057710.tif 000013
【図５Ｄ】
2015057710.tif 000014