JP4521480B1 - 未送信の受信者のあるｅメール・メッセージを訂正するための方法、システム、およびコンピュータ・プログラム - Google Patents

Abstract

【課題】クライアント・コンピュータ（１０５）など、複数のデータ処理エンティティ中で、メッセージ（Ｅメールなど）を交換するための解決策を提供すること。
【解決手段】対応する方法は、元のメッセージを、送信側エンティティから、１組の元の受信側エンティティに送信するステップ（４０３〜４１２）で開始し、元のメッセージは、元の情報コンテンツと、元の受信側エンティティの指示とを含む。この方法は、訂正メッセージを、送信側エンティティから、元の受信側エンティティに対しては少なくとも部分的に、かつ元のメッセージ中で失われている１組の未送信の受信側エンティティに対しては完全に送信する（４１５〜４２４）ステップによって続き、訂正メッセージは、元の情報コンテンツと、元の受信側エンティティおよび未送信の受信側エンティティの指示とを含む。そして各元の受信側エンティティに対する元のメッセージは、訂正メッセージに従って訂正される（４２７〜４９６）。
【選択図】図２〜５

Description

本発明は、データ処理の分野に関する。より具体的には、本発明は、データ処理システムにおけるメッセージ（たとえば、Ｅメール）の交換に関する。

電子メール（Ｅメールと略記される）サービスは、近年（個人用途またはビジネス用途で）、ますます普及してきた。これらのサービスは、通信ネットワークを介して、コンピュータのユーザ間で電子メッセージ（Ｅメール・メッセージ、または単にＥメールと呼ぶ）を交換できるようにする。いくつかの（専用の）Ｅメール・サービスが、会社などの特定の組織内で情報を交換するために使用されるが、Ｅメール・サービスは、特に、世界中のどこにでも伝達できるようにするインターネットのおかげで非常に広まってきている。Ｅメールは、情報を、直接かつ即時に伝達することを可能にする。それは、高速で、柔軟性があり、かつ信頼性の高い通信チャネルを提供する。

しかし、広く普及したＥメールの使用は、いくつかの問題を引き起こしている。実際に、Ｅメールの送信が非常に低コストである（インターネットへの対応する接続がすでに確立されている場合は、実質的に無料である）ことが、その普及を容易にしているが、その結果、大部分のユーザによって毎日、膨大な数のＥメールが送信される。

さらに、Ｅメールを扱うために必要な操作の簡単さは、その実行をますます速くする。これは、熟練したユーザでは特にそうであり、これらの操作をほとんど機械的に行う傾向がある。

しかし、上記のことはすべて、Ｅメールの管理に払われる注意レベルを低下させる。その結果、Ｅメールが作成され、送られ、受信され、または保管される場合、エラーが日常的に生ずることになる。

特に、典型的な問題は、Ｅメールが、送信側ユーザ（または、単に送信者）により、受信側ユーザ（または、単に受信者）のリストに沿って送られるときに生ずる。実際に、この場合、所望の受信者のうちの１つまたは複数のものが、Ｅメール中で失われている可能性がある。通常、これは、送信者がそれらをＥメール中に挿入するのを忘れた場合に発生する。そのアドレスがミスプリントされた場合にも、同様な問題が経験される。

送信者が、（たとえば、送信されたＥメール中に未送信の受信者のあることに気付いたため、またはミスプリントされたアドレスを有する受信者に対する不履行メッセージを受信したため）そのエラーに気付いた後は、問題を解決するために２つの選択肢が利用可能である。

第１の可能性は、未送信の受信者に対して同じＥメールを転送することである。しかし、この場合、Ｅメールの（元の）受信者は、未送信の受信者の指示を何も有していない。したがって、元の受信者が、Ｅメール中に示されているすべてのユーザに対して返答するために一般に利用可能な機能により、（元の）Ｅメールに自動的に返信するとき、エラーは広がる。実際に、（返信）Ｅメールは次に、送信者と、（未送信の受信者ではなく）他の元の受信者とに対して送られるに過ぎない。

代替の可能性は、すべての受信者（すなわち、元の受信者および未送信の受信者）に新しいＥメール（同じ情報を有する）を送ることである。そうではあるが、この場合、元の受信者には、同じＥメールが２度送られることになり、したがって、間違ったＥメールを正しいものと取り替える必要がある。しかし、これは、元の受信者にとって非常に面倒なことである。さらに、元の受信者は、新しいＥメールを（元のＥメールに代えて再度保管するよりも速いので）破棄することが非常に多い。したがって、上記で指摘された同様の問題が、今度はこれらの元の受信者により経験されることになる。

これは、両方の場合において、Ｅメールを普通であれば受信するように意図されていたユーザにとって価値ある情報を失うことになり得る。この問題は、ビジネス用途で、たとえば、Ｅメールが情報要求、タスク割当てなどに関するものである場合に特に重大である。

その一般的な用語において、本開示は、未送信の受信者を追加してメッセージを訂正する考えに基づいている。

特に、本発明の異なる態様は、独立請求項で述べられる解決策を提供する。本発明の有利な実施形態は、従属請求項で述べられる。

より具体的には、本発明の態様は、複数のデータ処理エンティティ（クライアント・コンピュータなど）の中で、メッセージ（Ｅメールなど）を交換するための方法を提案する。この方法は、元のメッセージを、送信側エンティティから、１組の元の受信側エンティティに送信するステップで開始し、元のメッセージは、元の情報コンテンツと、元の受信側エンティティの指示とを含む。この方法は、訂正メッセージを、送信側エンティティから、元の受信側エンティティに対しては少なくとも部分的に、かつ元のメッセージ中で失われている１組の未送信の受信側エンティティに対しては完全に送信するステップによって続き、訂正メッセージは、元の情報コンテンツと、元の受信側エンティティおよび未送信の受信側エンティティの指示とを含む。そして各元の受信側エンティティに対する元のメッセージは、訂正メッセージに従って訂正される。

本発明の実施形態では、訂正は、元のメッセージに対して、未送信の受信側エンティティの指示を追加することにより行われる。

提案する実施形態では、訂正メッセージの縮小版（元の情報コンテンツを除くことにより、またはその少なくとも一部を除くことにより得られる）が、元の受信側エンティティに送られる。

通常、訂正すべき元のメッセージは、訂正メッセージ中に含まれる対応する識別子により識別される。

元のメッセージの訂正は、（元のメッセージが受信されている）各元の受信側エンティティ上で実施されることが好ましい。

さらなる改良として、読取りインジケータ（元のメッセージが読まれたときアサートされる）が、その訂正に応じてディアサート（deassert）される。

さらに、元の受信側エンティティの指示、および未送信の受信側エンティティの指示を有する訂正されたメッセージを、異なる視覚的モードで表示することも可能である。

同じプロセスを、（その訂正の前に、元のメッセージに対する返信として送られた）任意の返信メッセージに対して繰り返すこともできる。

通常、提案する解決策は、Ｅメール・メッセージに適用される。

本発明の他の態様は、上記で述べた方法を実施するためのコンピュータ・プログラムを提案する。

本発明のさらなる態様は、対応するシステムを提案する。

本発明のさらに他の態様は、このシステムで使用するためのデータ処理エンティティ（クライアント・コンピュータなど）を提案する。

本発明それ自体、ならびにそのさらなる特徴および利点は、単に非限定的に示すものとして与えられた、添付の図面と共に読むべき以下の詳細な説明を参照すれば、最もよく理解されよう。

本発明の実施形態による解決策が適用可能なデータ処理システムの高水準の概観図である。 本発明の実施形態による解決策の例示的な適用例を示す図である。 本発明の実施形態による解決策の例示的な適用例を示す図である。 本発明の実施形態による解決策の例示的な適用例を示す図である。 本発明の実施形態による解決策の例示的な適用例を示す図である。 本発明の実施形態による解決策を実施するために使用できる異なるソフトウェア・コンポーネントの役割を表すコラボレーション図である。 本発明の実施形態による解決策の実施に関するアクティビティの流れを記述する図である。 本発明の実施形態による解決策の実施に関するアクティビティの流れを記述する図である。

具体的に図１を参照すると、分散アーキテクチャを有するデータ処理システム１００が示されている。システム１００は、複数のクライアント・コンピュータ１０５（または単に、クライアント）を含む。クライアント１０５は、（たとえば、インターネットからなる）ネットワーク１１０に対して、それに直接接続された他のコンピュータ１１５を介してアクセスするが、そのコンピュータ１１５はアクセス・プロバイダとして働く。この目的のために、各クライアント１０５は、（それが登録されている）選択されたアクセス・プロバイダ１１５にダイヤルする。クライアント１０５は、次いで、対応するアクセス・プロバイダ１１５を経由し、インターネット１１０を介して情報またはコマンドあるいはその両方を送信し、かつ受信することができる。こうすることにより、クライアント１０５は、インターネット１１０の１つまたは複数のサーバ・コンピュータ１２０により提供される異なるサービスを利用することが可能になる。

各クライアント１０５は、一般に、パーソナル・コンピュータ（ＰＣ）からなる。詳細には、クライアント１０５は、システム・バス１３０に並列に接続されるいくつかのユニットにより形成される。具体的には、マイクロプロセッサ（μＰ）１３５は、クライアント１０５の動作を制御し、ＲＡＭ１４０は、マイクロプロセッサ１３５により、作業メモリとして直接使用され、またＲＯＭ１４５は、クライアント１０５のブート・ストラップのための基本コードを記憶する。いくつかの周辺ユニットが、ローカル・バス１５０の周囲に（各インターフェースにより）群をなしている。具体的には、大容量メモリは、ハードディスク１５５、およびＣＤ−ＲＯＭ１６５を読み取るためのドライブ１６０から構成される。さらに、クライアント１０５は、入力ユニット１７０（たとえば、キーボードおよびマウス）、および出力ユニット１７５（たとえば、モニタおよびプリンタ）を含む。モデム１８０（たとえば、ＡＤＳＬタイプのもの）は、クライアント１０５を、対応するアクセス・プロバイダ１１５に（次いで、インターネット１１０に）接続するために使用される。ブリッジ・ユニット１８５は、システム・バス１３０とローカル・バス１５０とのインターフェースをとる。マイクロプロセッサ１３５およびブリッジ・ユニット１８５は、情報を送信するために、システム・バス１３０へのアクセスを要求するマスタ・エージェントとして働くことができる。アービタ（arbiter）１９０は、相互排除を用いてシステム・バス１３０へのアクセスの許可を管理する。

上記で示したように、サーバ１２０は、いくつかのサービスを提供することができる。本発明の実施形態の特定の場合、サーバ１２０は、Ｅメール・サービスを実施し、それは、クライアント１０５のユーザが、Ｅメールを送信し、受信することを可能にする。一般的に言えば、Ｅメールは、対応するクライアント１０５により、インターネット１１０を介して、送信側ユーザ（または、単に送信者）から、１つまたは複数の受信側ユーザ（または、単に受信者）に送信されるメッセージである。この目的のために、各（送信側／受信側）ユーザは、対応するアドレスにより識別され、そのアドレスは、関連するメール・サーバ１２０のドメイン中における一意の個人的なユーザ名と、その後に続く記号＠と、関連するメール・サーバ１２０のドメイン名とから構成される（「MyName@MyDomain」など）。Ｅメールは、さまざまな情報を受信者に伝達するために使用される。たとえば、情報は、テキスト、画像などからなり、さらに、外部ファイルの形式で、１つまたは複数の添付ファイルを追加することも可能である。

インターネット１１０では、Ｅメールのフォーマットは、ＭＩＭＥ（MultipurposeInternet Mail Extensions）規格により定義される。簡単にいうと、各Ｅメールは、ヘッダ部分と、（空白行によって分離された）本体部分とからなる。ヘッダ部分は、対応するヘッダ・フィールドによりＥメールを定義し、各ヘッダ・フィールドは、記号「：」により分離されたフィールド名およびフィールド値により構成された名前／値の対から構成される。１組の事前定義のヘッダ・フィールドが、ＭＩＭＥ規格により指定される。任意選択のヘッダ・フィールド（ＭＩＭＥ規格に対して予約されたものとは異なるヘッダ名を有する）をまた、カスタム情報を伝達するために使用することができる（その任意選択のヘッダ・フィールドは、サポートされていない場合、単に破棄される）。

さらに具体的には、ヘッダ部分は、Ｅメールの識別子（フィールド名「Message-ID（メッセージＩＤ）」）を含む。識別子は、（送信者と関連付けられたメール・サーバ１２０により保証されるように）大域的に一意の値から構成される。たとえば、Ｅメールの識別子は、メール・サーバ１２０によるその処理に関する現在の絶対的な日付および時刻と、その後に続く記号「＠」と、メール・サーバ１２０のドメイン名とにより形成される（「MyTime@MyDomain」など）。ヘッダ部分はまた、送信者のアドレスおよびおそらく名前（フィールド名「From（送信元）:」）と、１つまたは複数の受信者のアドレスおよびおそらく名前（フィールド名「To（宛先）:」）とを提供し、他のヘッダ・フィールドは、カーボン・コピー受信者（フィールド名「Cc:」）を、あるいは未公開のカーボン・コピー受信者（フィールド名「Ccn:」）を示すことができる。ヘッダ部分は、次いで、Ｅメールの主題（フィールド名「Subject（件名）:」）、その表示タイプ（フィールド名「Content-Type（コンテンツ・タイプ）:」）、任意の添付ファイルの名前（フィールド名「Attachment（添付ファイル）:」）、対応する日付および時刻（フィールド名「Date（日付）:」）などを含む。一方、本体部分は、そのコンテンツ（すなわち、テキストまたは画像あるいはその両方）を含み、通常、本体部分は、送信者の署名で終了する。

送信者が特定の受信者にＥメールを送る必要のある場合は常に、Ｅメールは（ＭＩＭＥ規格に従ってフォーマット化された後）、ＳＭＴＰ（Simple Mail Transfer Protocol:メール転送プロトコル）により、関連するメール・サーバ１２０に送信される。メール・サーバ１２０は、次いで、Ｅメール・メッセージが配信される必要のある各受信者のアドレスを（ヘッダ部分からではなくＳＭＴＰプロトコルから）抽出する。メール・サーバ１２０は、インターネット１１０のＤＮＳ（DomainName Servers）のシステムを利用して、各受信者と関連付けられたメール・サーバ１２０のドメイン名を、Ｅメールが（ＳＭＴＰプロトコルを用いて）次いで送信されるメール・サーバ１２０の物理的な位置へと変換する。任意のユーザにより受信されたＥメール・メッセージはすべて、関連するメール・サーバ１２０上の対応する電子的なメール・ボックスに保管される。ユーザは、ＰＯＰ３（PostOffice Protocol）により、受信したＥメールを、自分のクライアント１０５上へと取り出すことができる。

上記で述べたＥメールサービスの例示的な適用例が図２〜５で示されている。特に図２を参照し、総称的な送信者「MySender」が、１つまたは複数の受信者（問題としている例における受信者「MyRec1」および「MyRec2」など）にＥメールを送信することを望むことを考える。Ｅメールは、対応する識別子「MyID」を有しており（ヘッダ・フィールド「Message-ID:MyID」)、ヘッダ部分はまた、Ｅメールが、送信者「MySender」（ヘッダ・フィールド「From:MySender」）から、受信者「MyRec1」および「MyRec2」（ヘッダ・フィールド「To:MyRec1、MyRec2」)に送信されることを示している。Ｅメールの情報コンテンツ（受信者に配信される）は、総称的に「MyContent」で示され、たとえば、情報コンテンツは、その本体部分と共に、（対応するヘッダ・フィールド中で示される）Ｅメールの主題と、任意の添付ファイルとを含む。

上記で述べたＥメールは、その受信者「MyRec1」および「MyRec2」により、図３で示すように受信される。受信者「MyRec1」など、各受信者は、次いで、Ｅメールを開いて読むことができる。通常、Ｅメールが読まれた後、（たとえば、Ｅメールの近くに表示される小さな緑色のフラグを用いて）対応するインジケータが設定される。受信者「MyRec1」はまた、Ｅメールに返信するように決める可能性がある。この目的のために、受信者「MyRec1」は、通常、返信したい（親）Ｅメールのコンテンツを繰り返す（返信）Ｅメールの作成を可能にする「全員に返信」機能を利用する。返信Ｅメールは、親Ｅメール中で示されたすべての他の（送信側および受信側）ユーザに対して自動的にアドレス指定される。返信Ｅメールは、対応する識別子「MyIDR」（ヘッダ・フィールド「Message-ID:MyIDR」）を有する。追加のヘッダ・フィールド（フィールド名「In-Reply-To（に対する返信）:」）は、識別子「MyID」（ヘッダ・フィールド「In-Reply-To:MyID」）を有する親Ｅメールを示すために使用される。返信Ｅメールは、受信者「MyRec1」（ヘッダ・フィールド「From:MyRec1」）から他のユーザ「MySender」および「MyRec2」（ヘッダ・フィールド「To:MySender、MyRec2）に送られる。Ｅメールの情報コンテンツ（概して、親Ｅメールの情報コンテンツに対する追加の情報を含む）は、全体として「MyContentR」で示される。

図４に進むと、次に、送信者「MySender」が、（元の）受信者「MyRec1」および「MyRec2」に送られた（元の）Ｅメールはまた、（未送信の受信者「MyRecM」などの）１つまたは複数の未送信の受信者に送信されるべきであったと気付くものと仮定する。本発明の実施形態による解決策では、この場合、訂正Ｅメールが作成される。訂正Ｅメールは、元のＥメールの情報コンテンツと同じものを含むが、それは、所望されるすべての受信者（すなわち、元の受信者および未送信の受信者の両方）に対してアドレス指定される。訂正Ｅメールは、通常通り、未送信の受信者へと送信される。訂正Ｅメール（または少なくともその一部）はまた、元の受信者にも送られる。この場合、訂正Ｅメールは、元のＥメールを訂正するために（未送信の受信者を追加するために）使用される。

提案の解決策は、あらゆる受信者が、（すべての受信者の指示を有する）正しいＥメールを得ることを保証する。この方法では、（元のＥメールが訂正された後は、）元の受信者による元のＥメールへの返信により生ずるさらなるどんなエラーも阻止することが可能である。

元の受信者による何らかの手動の介入を必要とすることなく、所望の結果が自動的に達成される。

この方法では、普通であれば受信するように意図されていたユーザにとって価値ある情報のどんな損失も回避する（または少なくとも大幅に低減する）ことが可能である。この利点は、（同じ解決策を個人的な用途で使用することを排除しないとしても）ビジネス用途で明確に認識される。

問題としている例では、（送信者「MySender」上の元のＥメールを置き換える）訂正Ｅメールは、それに対応する識別子「MyIDC」（ヘッダ・フィールド「Message-ID:MyIDC」）を有する。任意選択のヘッダ・フィールド（たとえば、フィールド名「Replace（置換）」により定義される）が、置き換えられる識別子「MyID」を有する元のＥメールを示すために使用される（ヘッダ・フィールド「Replace:MyID」。訂正Ｅメールは、送信者「MySender」（ヘッダ・フィールド「From:Mysender」）から、すべての受信者「MyRec1」、「MyRec2」、および「MyRecM」（ヘッダ・フィールド「To:MyRec1、MyRec2、MyRecM」）に送信される。Ｅメールの情報コンテンツは、元のＥメールのもの（すなわち、「MyContent」）と等しい。

訂正Ｅメールと元のＥメールの間の差（すなわち、追加された未送信の受信者）は、送信者「MySender」上で強調表示されることが好ましい。問題としている例では、所望の結果は、未送信の受信者「MyRecM」のアドレス（およびおそらく名前）を、色の付いた背景を用いて表示することにより達成される。この追加の機能は、元のＥメールに対して行われた訂正の識別を容易にする。

図５に進むと、各未送信の受信者（すなわち、問題としている例では、受信者「MyRecM」）は、上記で述べたように送信者「MySender」から訂正Ｅメールを受信する。反対に、各元の受信者（すなわち、受信者「MyRec1」および「MyRec2」）は、単に、訂正Ｅメールに従って、（ヘッダ・フィールド「Replace:」で識別された）元のＥメールを訂正するだけである。この目的のために、図で示すように、元のＥメールは、（識別子「MyIDC」を有する）訂正Ｅメールにより置き換えられる。代替的には、未送信の受信者「MyRecM」を、（識別子「MyID」を有する）元のＥメールに追加することも可能である。

元のＥメールが、元の受信者「MyRec1」上などですでに読まれている場合、対応する読取りインジケータは、（たとえば、フラグを除くことにより）リセットされることが好ましい。この方法では、元のＥメールに対して行われた訂正に対して、元の受信者「MyRec1」の注意をひくようにすることも可能である。

上記のように、訂正されたＥメールと元のＥメールの間の差（すなわち、追加された未送信の受信者）が強調表示され、したがって、元のＥメールに対して行われた訂正の識別がさらに容易になる。

同様の訂正がまた、元のＥメールに対してすでに返信した各元の受信者に対しても伝えられる。この場合、返信Ｅメールを訂正するためにさらなる訂正Ｅメールが使用される。提案の解決策は、元のＥメールにより（直接的、または間接的に）生じたどんなエラーも、（情報の何らかの損失を回避するために）自動的に訂正されることを保証する。

問題としている例では、上記で述べたように、元の受信者「MyRec1」が、識別子「MyIDR」を有する返信Ｅメールを、他のユーザ「MySender」および「MyRec2」へと送信している。その訂正Ｅメールは、対応する識別子「MyIDCR」（ヘッダ・フィールド「Message-ID:MyIDCR」）を有する。置換される識別子「MyIDR」を有する返信Ｅメールを示すために、任意選択のヘッダ・フィールドが次に使用される（ヘッダ・フィールド「Replace:MyIDR」）。訂正Ｅメールは、識別子「MyIDC」（ヘッダ・フィールド「In-Reply-To:MyIDC」）を有する（訂正された）親Ｅメールへの返信である。訂正Ｅメールは、受信者「MyRec1」（ヘッダ・フィールド「From:MyRec1」）から、他のすべてのユーザ「MySender」、「MyRec2」、および「MyRecM」（ヘッダ・フィールド「To:MySender、MyRec2、MyRecM」）に対して送信される。訂正Ｅメールの情報コンテンツは、返信Ｅメールのコンテンツ（すなわち、「MyContentR」）と等しい。訂正Ｅメールと（元の）返信Ｅメールの間の差（すなわち、追加された未送信の受信者）は、再度、強調表示されることが好ましい。

上記で述べた同様のオペレーションが、次いで、この訂正Ｅメールの各受信者に対して繰り返される（さらに他の訂正Ｅメールを次に生成する可能性もある）。

図６を次に参照すると、一般的なクライアントに対して、上記で述べた解決策を実施するために使用され得る主要なソフトウェア・コンポーネントが、全体として参照３００で示されている。情報（プログラムおよびデータ）は、通常、ハードディスク上に記憶されており、プログラムが動作するとき、オペレーティング・システムおよび他のアプリケーション・プログラム（図中に示されていない）と共に、クライアントの作業メモリ中に（少なくとも部分的に）ロードされる。プログラムは、最初に、たとえば、ＣＤ−ＲＯＭからハードディスクへとインストールされる。具体的には、図は、（対応するコンポーネントにより）システムの静的な構造と、（前に記号「Ａ」が付されたシーケンス番号で示された、対応するアクションをそれぞれが表す一連の交換メッセージにより）その動的な挙動を説明している。

詳細には、メール・クライアント３０５は、Ｅメールをローカルに作成し、送信し、かつ保管するために使用される。市場で入手できる市販のメール・クライアント３０５の例は、IBM Corporation（ＩＢＭ社）による「Lotus Notes」である。本発明の実施形態による解決策では、専用のプラグイン３１０（以降、コレクタと呼ぶ）が、（誤って所望の受信者全員には送られなかった）Ｅメールの上記で述べた訂正を管理するために、メール・クライアント３０５に追加される。

通常通り、どの新しい送出Ｅメールも送出ボックス３１５中に置かれる。メール・クライアント３０５は、次いで、そのヘッダ部分で示された受信者に対して送出Ｅメールを送信し、それを送信箱３２０に移動する（アクション「Ａ１．送信する」）。元のＥメールが、１つまたは複数の未送信の受信者を含めずに送信された（また、次いで、送信箱３２０に保管された）場合、コレクタ３１０は、対応する訂正Ｅメールを作成する。訂正Ｅメールは、送出ボックス３１５中に置かれ、同時に、元のＥメールが送信箱３２０から除かれる（アクション「Ａ２．訂正する」）。この方法では、メール・クライアント３０５は通常通り、送出ボックス３１５中の訂正Ｅメールを、すべてのその（元のかつ未送信の）受信者に送り、それを送信箱３２０へ移動する（アクション「Ａ３．送信する」）。

クライアントが、新しい着信Ｅメールを受信する場合は常に、イベントは、コレクタ３１０によりインターセプトされる（アクション「Ａ４．インターセプトする」）。この目的のために、コレクタ３１０は、バックグラウンドで連続的に動作するエージェント（図に示されていない）を含んでおり、そのエージェントは、（たとえば、フッキング（hooking）技法により）どの着信Ｅメールの受信も検出する。着信Ｅメールが訂正Ｅメールではない場合、コレクタ３１０は、それをメール・クライアント３０５に転送する。その結果、（標準の）着信Ｅメールが、通常通り受信され、次いで、受信箱３２５に追加される（アクション「Ａ５．受信する」）。

それとは反対に、着信Ｅメールが訂正Ｅメールである場合、コレクタ３１０は、それに従って、受信箱３２５中の対応する元のＥメールを訂正する（アクション「Ａ６．訂正する」）。さらに、コレクタ３１０は、送信箱３２０が、同じ元のＥメールに応答して送られた何らかの返信Ｅメールを含むかどうかを検証する。含む場合は、訂正されたものと同じ親Ｅメールへの返信として、対応するさらなる訂正Ｅメールが作成される。この訂正Ｅメールは送出ボックス３１５に追加され、同時に、送信箱３２０から返信Ｅメールが除かれる（アクション「Ａ７．訂正する」）。上記のように、メール・クライアント３０５は、次いで、送出ボックス３１５中の訂正Ｅメールを、すべてのその（元のかつ未送信の）受信者へと送信し、それを送信箱３２０へと移動する（アクション「Ａ８．送信する」）。

次に、図７〜８を検討すると、未送信の受信者を有するＥメールを訂正するために、上記で述べたクライアント中で実施することのできる例示的なプロセスの論理流れが、方法４００で表されている。

本方法は、メール・クライアントにおけるスイム・レーン（swim-lane）中の黒の開始円４０３で始まり、クライアントのユーザが、新しいＥメールを送信したい場合は直ちにブロック４０６に進む。それに応じて、ユーザは、ブロック４０９で、メール・クライアントにより提供されるＧＵＩ（グラフィカル・ユーザ・インターフェース）を利用することにより、所望のＥメールを作成する。この目的のために、ユーザは、（「Subject」入力フィールド中の）Ｅメールの主題、および（「Body（本体）」フレーム中の）そのテキストをタイプする。ユーザは、次いで、（「To」入力フィールド中に）所望の受信者を、たとえば、そのアドレスをタイプすることにより、またはアドレス・ブックから受信者を選択することにより追加する。そのようにして得られたＥメールは、次いで、ブロック４１２で、（たとえば、対応するボタン上をマウスでクリックすることにより）示された受信者に送信される。

ブロック４１５に進むと、ユーザは、（元の）受信者に送信された（元の）Ｅメールを、１つまたは複数の未送信の受信者にも送信すべきであったことに気付く。したがって、ユーザは、送信箱中の元のＥメールを選択し、次いで、（たとえば、選択された後、元のＥメールを表示するために使用されるポップアップ・ウィンドウのプルダウン・メニュー中の対応するコマンドを選択することにより）コレクタにより提供される訂正コマンドを呼び出す。それに応じて、コレクタは、ブロック４１８で、ユーザに未送信の受信者を（さらに「To」入力フィールド中に）入力するように促す。ブロック４２１に進むと、コレクタは、元のＥメールをコピーし、次いで、未送信の受信者を追加することにより訂正Ｅメールを作成する。訂正Ｅメールは送出ボックス中に配置され、同時に、送信箱から元のＥメールが除かれる。メール・クライアントのスイム・レーンに戻ると、ブロック４２４で、訂正Ｅメールが、次いで、すべての（元のかつ未送信の）受信者に対して送信される。

特に、訂正Ｅメールは、未送信の受信者へと常に完全に送信される。それとは反対に、訂正Ｅメールを、元の受信者に対して完全に、または縮小版でのみ送信してもよい。縮小された訂正Ｅメールは、さらなる任意選択のヘッダ・フィールド（たとえば、「Reduced（縮小）:Yes」）を追加することによって、その完全版とは区別される。縮小された訂正Ｅメールは、対応する元のＥメールを識別するために必要な情報（すなわち、ヘッダ・フィールド「Replace:」中のその識別子）、かつそれを訂正するために必要な情報（すなわち、ヘッダ・フィールド「To:」中の未送信の受信者）を含む。そうではあるが、他の情報（本体部分および添付ファイルなど）は、すでに元の受信者に利用可能である（元のＥメール中に同様に含まれている）ので、除去することができる。この方法では、同じ情報のどんな繰返し送信も回避する（ネットワーク・トラフィックに対して有利な影響を与える）ことが可能である。

本方法は、次いで、クライアントが、新しい着信Ｅメールを受信すると直ちに、ブロック４２７へと下がる。イベントは、ブロック４３０で、コレクタによりインターセプトされる。アクティビティの流れは、次に、ブロック４３３で、着信Ｅメールのタイプに従って分岐する。

具体的には、（ヘッダ・フィールド「Replace:」により示されるように）訂正Ｅメールが受信された場合、ブロック４３６で、コレクタが、受信箱中で（訂正Ｅメールのヘッダ・フィールド「Replace:」中に示された識別子を有する）対応する元のＥメールを検索する。

判断ブロック４３９で、元のＥメールが見つからない場合（元のＥメールが、元の受信者によりまだ受信されていないこと、または訂正Ｅメールが未送信の受信者により受信されていることを意味する）、アクティビティの流れは、ブロック４４２へと渡される。この段階で、（訂正）Ｅメールは通常通り受信箱に追加される。ブロック４４５に進むと、クライアントのユーザは、このＥメールを開き、かつ読み取る。したがって、対応する読取りインジケータが、ブロック４４８で（フラグを表示することにより）設定される。次にブロック４５１を参照すると、クライアントのユーザはまた、（たとえば、Ｅメールが送信箱で選択されたときに開かれるポップアップ・ウィンドウのプルダウン・メニュー中で対応するコマンドを選択することにより）「全員に返信」機能を用いて、Ｅメールに返信するように決めることもできる。それに応じて、新しい（返信）Ｅメールは、ブロック４５４で、（「Subject」入力フィールド中に、および「Body」フレーム中に、それぞれ）親Ｅメールの主題および本体を繰り返すことにより、また（「To」入力フィールド中に）親Ｅメールの他の（送信側および受信側）ユーザを挿入することにより、自動的に作成される。ユーザは、次いで、同じ「Body」フレーム中に、親Ｅメールに対する応答を（またおそらく「To」入力フィールド中に任意の追加の受信者を）挿入することにより、返信Ｅメールを完了する。そのようにして得られたＥメールは、次いで、ブロック４５７で、指示された受信者に送信される。方法は、次に、同心の白／黒の停止円４６０へと下がる。

ブロック４３９に戻ると、ちょうど受信された訂正Ｅメールに対する元のＥメールが受信箱で見つかった場合、方法はブロック４６３に進む。この段階では、（訂正Ｅメールを元のＥメールと比較することにより決定された）元のＥメールに追加されるべき未送信の受信者がセーブされる。ブロック４６６に進むと、元のＥメールは、次いで、訂正Ｅメールに従って訂正される。具体的には、（ヘッダ・フィールド「Reduced:Yes」がないことにより示される）完全な訂正Ｅメールが受信されたとき、受信箱中の元のＥメールは、訂正Ｅメールで置き換えられる。それとは反対に、（ヘッダ・フィールド「Reduced:Yes」を含む）縮小された訂正Ｅメールが受信された場合、元のＥメールは、そのヘッダ・フィールド「To:」の中に未送信の受信者を追加することによって更新される。

ブロック４６９で、次いで、元のＥメールがすでに読まれているかどうか（メール・クライアントにより管理される対応する読取りインジケータがアサートされていることにより示される）を検証するテストが行われる。読まれている場合、ブロック４７２で、読取りインジケータはリセットされる（それによりフラグを削除する）。ブロック４７５に進むと、（訂正された元のＥメールに追加された）未送信の受信者が強調表示される。方法は、次いで、ブロック４７８へと下がる。元のＥメールがまだ読まれていない場合もまた、ブロック４６９から直接、同じ点に到達する。

コレクタは、次に、送信箱中で（ヘッダ・フィールド「In-Reply-To:」中にその識別子を有する）元のＥメールへの何らかの返信Ｅメールを検索する。

判断ブロック４８１で、少なくとも１つの返信Ｅメールが見つかった場合、各返信Ｅメールに対してループが行われる。ループは、ブロック４８４で開始し、（現在の）返信Ｅメールに対応する訂正Ｅメールが作成される。訂正されたＥメールが、元のＥメールを訂正Ｅメールで置き換えることによって得られている場合、このさらなる訂正Ｅメールは、ヘッダ・フィールド「To:」に未送信の受信者を追加することにより、また元のＥメールの識別子を、ヘッダ・フィールド「In-Reply-To:」中の訂正Ｅメールの識別子で置き換えることにより、返信Ｅメールから取得される。反対に、訂正されたＥメールが、元のＥメールを更新することにより得られている場合、このさらなる訂正Ｅメールは、（ヘッダ・フィールド「In-Reply-To:」中で維持される元のＥメールの識別子を用いて）未送信の受信者をヘッダ・フィールド「To:」に追加するだけで、返信Ｅメールから取得される。訂正Ｅメールは、次いで、送出ボックス中に置かれ、同時に、送信箱から返信Ｅメールが除かれる。メール・クライアントのスイム・レーンに戻ると、ブロック４８７で、訂正Ｅメールがその受信者すべてに送られる。方法は、次いで、ブロック４９０で、（コレクタのスイム・レーンで）すべての返信Ｅメールが処理されたかどうかを検証する。処理されていない場合、アクティビティの流れは、ブロック４８４へと戻り、次の返信Ｅメールに対して同じオペレーションを繰り返す。処理されている場合、方法は、同心の白／黒の停止円４６０へと下がる。元のＥメールへの返信Ｅメールが何も見つからない場合もまた、ブロック４８１から直接、同じ点に到達する。

ブロック４３３に戻ると、（ヘッダ・フィールド「Replace:」のない）標準のＥメールが受信された場合、ブロック４９３で、コレクタは、受信箱中で（そのヘッダ・フィールド「Replace:」中に着信Ｅメールの識別子を有する）対応する訂正Ｅメールを検索する。

判断ブロック４９６で、訂正Ｅメールが見つからない場合（着信Ｅメールが正しいこと、または対応する訂正Ｅメールがまだ受信されていないことを意味する）、アクティビティの流れは、（上記で示すように）通常通り着信Ｅメールを処理するために、ブロック４４２に進む。反対の場合（すなわち、訂正Ｅメールが、対応する元のＥメールの前に受信されていた場合）、受信されたＥメールは、訂正Ｅメールにより入れ替えられるので、ブロック４９９で、破棄される。方法は、次いで、同心の白／黒の停止円４６０へと下がる。

当然であるが、ローカルかつ特有の要件を満たすために、当業者は、上記で述べた解決策に対して、多くの論理的または物理的あるいはその両方の変更および改変を適用することができる。より具体的には、本発明は、その好ましい実施形態（複数可）を参照して、ある程度特定化して述べられてきているが、その形態および細部におけるさまざまな省略、置換え、および変更、ならびに他の諸実施形態が可能であることを理解されたい。特に、提案の解決策は、そのさらなる十分な理解を提供するために、上記の説明中で述べられた（数値的な諸例など）特有の細部なしに実施することも可能である。反対に、不必要な詳細で説明をあいまいにしないために、よく知られた機能を省略し、または簡単化することもある。さらに、本発明の任意の開示された実施形態と共に述べられた特有のエレメントまたは方法ステップあるいはその両方を、一般的な設計選択の問題として、任意の他の実施形態に組み込むことも可能であることが明示的に意図される。

特に、提案の解決策は、（同様なステップを使用することにより、本質的ではないいくつかのステップを除くことにより、またはさらなる任意選択のステップを追加することにより）均等な方法を用いて実施するのに適している。さらに、諸ステップは、異なる順序で、同時に、または（少なくとも部分的に）交互に配置する方法で実施することができる。

Ｅメールが、何らかの他の方法で作成される場合、同様の考慮事項が適用される。たとえば、（元のまたは未送信のあるいはその両方の）受信者は、配信リストにより指定することができる。

当然であるが、ＭＩＭＥ規格に基づいた上記で述べた実施形態は、限定的に解釈されるべきではない。たとえば、同様の解決策はまた、異なる任意選択のヘッダ・フィールドを用いることにより、既存のヘッダ・フィールドを利用することにより、またはさらに、本体部分における特有の情報を符号化することによっても実施することができる。異なるプロトコルまたはフォーマットあるいはその両方（「Ｘ．４００」」または何らかの独自の解決策など）に基づいてさえ、他のＥメール・サービスに対しても同様の考慮事項が適用される。代替的には、Ｅメールは、異なる方法で、たとえば、（ローカル・ネットワークのクライアントに直接接続された）ローカル・メール・サーバにより、ファット・クライアントにより、「ウェブメール」インターフェースなどにより、管理することができる。

上記で示したように、元のＥメールは、未送信の受信者を追加することにより、またはそれを訂正Ｅメールで置き換えることにより、（あるいは任意の他の均等な方法で）訂正することができる。

さらに、訂正Ｅメールは、元の受信者に対して完全に、または一部だけを送信することもできる。後者の場合、訂正Ｅメールの縮小版は、添付ファイルだけを除くことにより、添付ファイルと本体部分を除くことにより、またはその全体の情報コンテンツを除く（元のＥメールおよび未送信の受信者の識別子を含むだけである縮小された訂正Ｅメールに低減される）ことにより取得することができる。

訂正Ｅメールと関連付けられた元のＥメールを別の方法で識別することを妨げるものはなく、どの任意選択のヘッダ・フィールドを使用しなくても（たとえば、その情報コンテンツを比較することにより）可能である。

さらに、（たとえば、対応するクライアントに元のＥメールがまだダウンロードされていない場合）メール・サーバ上で元のＥメールを訂正する可能性も排除されない。

すでに読まれたＥメールに対して、均等な読取りインジケータが使用される場合、同様の考慮事項が適用される（たとえば、さまざまな色、チェック・ボックスなどでチェック・マークを付ける）。しかし、訂正された元のＥメールの読取りインジケータをリセットする機能は、必ずしも必要なものではなく、本発明の簡単化された実施形態では省略することができる。

元のＥメールに追加される未送信の受信者は、元のＥメールと訂正Ｅメールの間を比較することにより決定することができるが、あるいは（それが元の受信者を含まない縮小版中にある場合には）訂正Ｅメールから直接抽出することもできる。いずれの場合であっても、元の受信者および未送信の受信者は、関連するＥメール中で、任意の他の方法で（たとえば、異なるフォント、色、または任意の他の視覚的モードを用いて）区別することができる。しかし、すべての受信者を（すなわち、元の受信者および未送信の受信者を共に）、同じ方法で表示するのを妨げるものはない。

同様の考慮事項が、必要な変更を加えて、返信Ｅメールの訂正に対しても適用される。代替的には、この機能は、異なる方法で実施することができるが（たとえば、返信Ｅメール・チェーンの最大レベルに限定する、元のＥメールへの直接返信のものだけに減らす）、あるいは完全に省略することさえ可能である。

上記の説明では、Ｅメール・サービスに対して参照が行われてきたが、これを、限定的なものとして解釈されるべきではない。より一般的に、同様の解決策をさらに、インスタント・メッセージ・サービス、チャットルーム、ニュース・サービスに対して適用することができ、またさらに一般的には、どんなメッセージであっても、その交換に基づく、任意の他のコンピュータで実施されるサービスに対して適用することができる。

提案の解決策が、異なるメール・クライアントを用いて実施される場合、同様の考慮事項が適用される。代替的には、着信Ｅメールは、異なる方法で（たとえば、そのsubject（件名）中などを、事前定義のキーワードに従って訂正Ｅメールをフィルタリングすることにより）インターセプトすることができる。いずれにしても、提案の解決策を直接サポートするために、メール・クライアントを（何らかの専用のプラグインを使用せずに）カスタム化するのを妨げるものはない。

プログラム（本発明の各実施形態を実施するために使用することのできる）が、異なる方法で構造化される場合、または追加のモジュールもしくは機能が提供される場合、同様の考慮事項が適用される。同様に、メモリ構造を他のタイプのものとすることができ、あるいは（必ずしも物理的な記憶媒体から構成されない）均等なエンティティで置き換えることもできる。いずれにしても、プログラムは、外部もしくは常駐するソフトウェア、ファームウェア、またはマイクロコードなど（たとえば、コンパイルもしくは解釈されるオブジェクト・コードまたはソース・コードで）、任意のデータ処理システムにより使用される、またはそれと併せて使用されるのに適した任意の形態を取ることができる。さらに、プログラムを任意のコンピュータで使用可能な媒体上で提供することが可能であり、媒体は、そのプログラムを含み、記憶し、通信し、伝達し、または転送するのに適切な任意のエレメントとすることができる。たとえば、媒体は、電子的、磁気的、光学的、電磁的、赤外線、または半導体のタイプとすることができ、このような媒体の例は、固定ディスク（この場合、プログラムが事前にロードされ得る）、取外し可能ディスク、テープ、カード、ワイヤ、ファイバ、無線接続、ネットワーク、放送波などである。いずれにしても、本発明の実施形態による解決策は、ハードウェア（たとえば、半導体材料のチップに集積された）構造で、またはソフトウェアおよびハードウェアの組合せで実装するのに適している。

提案の方法はまた、（複数のユーザをサポートする単一のメインフレームに至るまで）異なるトポロジを有する、または均等なユニットを含むシステム上で実施することもできる。さらに、各コンピュータは、他の構造を有することもでき、あるいは同様のエレメント（実行中に、大容量メモリへのアクセスを減らすために、プログラムまたはその一部を一時的に記憶するキャッシュ・メモリなど）を含むこともできる。いずれにしても、コンピュータを、任意のコード実行エンティティ（ＰＤＡ、移動電話など）で、あるいはその組合せ（クライアント／サーバ・アーキテクチャ、グリッド・コンピューティング・インフラストラクチャなど）で置き換えることが可能である。

Claims (3)

1. 複数のデータ処理エンティティ（１０５）中で、メール・クライアント（３０５）またはコレクタ（３１０）が以下の複数のステップを実行することによって、メッセージを交換する方法（４００）であって、
   元のメッセージを、送信側エンティティから、１組の元の受信側エンティティに送信するステップ（４０３〜４１２）であり、前記元のメッセージが、元の情報コンテンツと、前記元の受信側エンティティの指示とを含む、前記送信するステップ（４０３〜４１２）と、
   訂正メッセージを、前記送信側エンティティから、前記元の受信側エンティティに対しては少なくとも部分的に、かつ前記元のメッセージ中で不足していた１組の未送信の受信側エンティティに対しては完全に送信するステップ（４１５〜４２４）であり、前記訂正メッセージが、前記元の情報コンテンツと、前記元の受信側エンティティおよび前記未送信の受信側エンティティの指示とを含む、前記送信するステップ（４１５〜４２４）と、
   前記訂正メッセージに従って、各元の受信側エンティティに対する前記元のメッセージを訂正するステップ（４２７〜４９６）とを含み、
   各元の受信側エンティティ上で前記元のメッセージを受信するステップ（４２７）をさらに含み、前記元のメッセージを訂正する前記ステップが前記元の受信側エンティティ上で実施され、
   前記元のメッセージを訂正する前に、前記元の受信側エンティティから、前記元のメッセージへの返信として返信メッセージを、前記送信側エンティティおよびその他の元の受信側エンティティを含む１組の返信先受信側エンティティに対して送信するステップ（４５１）であり、前記返信メッセージが、返信情報コンテンツと、前記返信先受信側エンティティの指示とを含む、前記送信するステップ（４５１）と、
   前記元のメッセージの前記訂正に応じて、さらなる訂正メッセージを、前記元の受信側エンティティから、前記返信先受信側エンティティに対しては少なくとも部分的に、かつ前記未送信の受信側エンティティに対しては完全に送信するステップ（４８４〜４８７）であり、前記さらなる訂正メッセージが、前記返信情報コンテンツと、前記返信先受信側エンティティおよび前記未送信の受信側エンティティの指示とを含む、前記送信するステップ（４８４〜４８７）と、
   前記さらなる訂正メッセージに従って、各返信先受信側エンティティに対する前記返信メッセージを訂正するステップ（４２７〜４９６）と
   をさらに含む、
   方法（４００）。
2. 複数のデータ処理エンティティ（１０５）中で、メール・クライアント（３０５）またはコレクタ（３１０）が以下の複数のステップを実行することによって、メッセージを交換する方法（４００）であって、
   元のメッセージを、送信側エンティティから、１組の元の受信側エンティティに送信するステップ（４０３〜４１２）であり、前記元のメッセージが、元の情報コンテンツと、前記元の受信側エンティティの指示とを含む、前記送信するステップ（４０３〜４１２）と、
   訂正メッセージを、前記送信側エンティティから、前記元の受信側エンティティに対しては少なくとも部分的に、かつ前記元のメッセージ中で不足していた１組の未送信の受信側エンティティに対しては完全に送信するステップ（４１５〜４２４）であり、前記訂正メッセージが、前記元の情報コンテンツと、前記元の受信側エンティティおよび前記未送信の受信側エンティティの指示とを含む、前記送信するステップ（４１５〜４２４）と、
   前記訂正メッセージに従って、各元の受信側エンティティに対する前記元のメッセージを訂正するステップ（４２７〜４９６）とを含み、
   各元の受信側エンティティ上で前記元のメッセージを受信するステップ（４２７）をさらに含み、前記元のメッセージを訂正する前記ステップが前記元の受信側エンティティ上で実施され、
   前記元のメッセージを読み取るステップ（４４５）と、
   前記元のメッセージの読取りに応じて、前記元のメッセージに対する読取りインジケータをアサートするステップ（４４８）と、
   前記元のメッセージの前記訂正に応じて、前記読取りインジケータをディアサートするステップ（４７２）とをさらに含み、
   前記元のメッセージを訂正する前に、前記元の受信側エンティティから、前記元のメッセージへの返信として返信メッセージを、前記送信側エンティティおよびその他の元の受信側エンティティを含む１組の返信先受信側エンティティに対して送信するステップ（４５１）であり、前記返信メッセージが、返信情報コンテンツと、前記返信先受信側エンティティの指示とを含む、前記送信するステップ（４５１）と、
   前記元のメッセージの前記訂正に応じて、さらなる訂正メッセージを、前記元の受信側エンティティから、前記返信先受信側エンティティに対しては少なくとも部分的に、かつ前記未送信の受信側エンティティに対しては完全に送信するステップ（４８４〜４８７）であり、前記さらなる訂正メッセージが、前記返信情報コンテンツと、前記返信先受信側エンティティおよび前記未送信の受信側エンティティの指示とを含む、前記送信するステップ（４８４〜４８７）と、
   前記さらなる訂正メッセージに従って、各返信先受信側エンティティに対する前記返信メッセージを訂正するステップ（４２７〜４９６）と
   をさらに含む、
   方法（４００）。
3. 複数のデータ処理エンティティ（１０５）中で、メール・クライアント（３０５）またはコレクタ（３１０）が以下の複数のステップを実行することによって、メッセージを交換する方法（４００）であって、
   元のメッセージを、送信側エンティティから、１組の元の受信側エンティティに送信するステップ（４０３〜４１２）であり、前記元のメッセージが、元の情報コンテンツと、前記元の受信側エンティティの指示とを含む、前記送信するステップ（４０３〜４１２）と、
   訂正メッセージを、前記送信側エンティティから、前記元の受信側エンティティに対しては少なくとも部分的に、かつ前記元のメッセージ中で不足していた１組の未送信の受信側エンティティに対しては完全に送信するステップ（４１５〜４２４）であり、前記訂正メッセージが、前記元の情報コンテンツと、前記元の受信側エンティティおよび前記未送信の受信側エンティティの指示とを含む、前記送信するステップ（４１５〜４２４）と、
   前記訂正メッセージに従って、各元の受信側エンティティに対する前記元のメッセージを訂正するステップ（４２７〜４９６）とを含み、
   各元の受信側エンティティ上で前記元のメッセージを受信するステップ（４２７）をさらに含み、前記元のメッセージを訂正する前記ステップが前記元の受信側エンティティ上で実施され、
   前記元の受信側エンティティの指示を有する前記訂正された元のメッセージを第１の視覚的モードで、また前記未送信の受信側エンティティの指示を前記第１の視覚的モードとは異なる第２の視覚的モードで表示するステップ（４７５）をさらに含み、
   前記元のメッセージを訂正する前に、前記元の受信側エンティティから、前記元のメッセージへの返信として返信メッセージを、前記送信側エンティティおよびその他の元の受信側エンティティを含む１組の返信先受信側エンティティに対して送信するステップ（４５１）であり、前記返信メッセージが、返信情報コンテンツと、前記返信先受信側エンティティの指示とを含む、前記送信するステップ（４５１）と、
   前記元のメッセージの前記訂正に応じて、さらなる訂正メッセージを、前記元の受信側エンティティから、前記返信先受信側エンティティに対しては少なくとも部分的に、かつ前記未送信の受信側エンティティに対しては完全に送信するステップ（４８４〜４８７）であり、前記さらなる訂正メッセージが、前記返信情報コンテンツと、前記返信先受信側エンティティおよび前記未送信の受信側エンティティの指示とを含む、前記送信するステップ（４８４〜４８７）と、
   前記さらなる訂正メッセージに従って、各返信先受信側エンティティに対する前記返信メッセージを訂正するステップ（４２７〜４９６）と
   をさらに含む、
   方法（４００）。

Images