JP2006505843A - 電子送信メッセージの翻訳 - Google Patents

Abstract

【課題】 電子送信メッセージのトランスペアレントな翻訳を提供する。
【解決手段】 この通信システムは、送信コンピュータシステム(11)と、受信コンピュータシステム(21a)と、翻訳ウエブサイト(31)とを有する。送信システム(11)は、通信を送信する際に送信者に関連づけられた第１の人間認知可能な言語と受信者に関連づけられた第２の人間認知可能な言語とを決定し、両言語が異なる場合には、該通信を翻訳してもらうために翻訳システム(31)へ送信する。受信者のアドレスも該通信と一緒に送られる。迂回させられた通信は翻訳システム(31)で翻訳され、そこから受信システム(21a)へ転送される。第１及び第２の人間認知可能な言語が同じである場合は、該通信は送信システム(11)から受信システム(21a)へ直接送られる。受信システムは、受け取った通信の言語を受信者の言語との対比で検査し、必要に応じて該通信を翻訳システム(31)へ送り、翻訳して送り返してもらう。

Description

本発明は、電子送信メッセージの自動翻訳に関する。本発明は、あらゆる形態の電子送信メッセージに応用可能だが、インターネットに基づく電子メールシステムと、インスタントメッセージングシステムと、電子メールに基づくＦＡＸシステムと、ＳＭＳメッセージ等の他の形態の電子送信テキストとにおいて特定の用途を有する。

電子的手段による国際通信の量が増加するにつれ、異なる自然言語を有する通信システムのユーザの問題は、徐々に大きくなりつつある。そのため、効果的な自動言語翻訳サービスの必要性は、重要性を増している。

電子メッセージの自動翻訳を提供する問題に対する解決策は、例えば、ＢｏｕｃｈｅｒらがＵＳ５８８４２４６において、ＳｃａｎｌａｎがＷＯ０１／０２９９４において提案している。Ｂｏｕｃｈｅｒのアプローチでは、翻訳サイトのアドレスをメッセージの送信先アドレスに連結し、メッセージが翻訳サイトに送給されるようにする。翻訳サイトでは、メッセージが翻訳され、その後、受信者に送給される。Ｂｏｕｃｈｅｒのアプローチは、いくつかの問題点を抱えている。
１）ユーザの既存のメッセージングシステムに統合された、メッセージの自動翻訳を提供する包括的なユーザ指向ソリューションではなく、翻訳のための中央サイトへのメッセージのリダイレクトについて、メカニズムが説明されている。
２）システムが翻訳するメッセージを自動的にリダイレクトする状態を確保するために、メッセージシステムのアドレス帳内の連絡先をどのように使用し得るかについて指摘されていない。受信者の言語が何らかの方法で予め規定されていなければ、システムはメッセージの翻訳が必要なのかどうか決定できない。
３）Ｂｏｕｃｈｅｒは、受信者の選択言語を定義する二つの方法を説明している。送信者が電子メールアドレス内で指定するか、或いは、受信者のトップレベルドメイン名を使用して、受信者の言語を推測できる。第一のアプローチは、ユーザの介入を意味し、そのため、メッセージ送信のための通常の作業慣例からの逸脱が生じ、一方、第二のアプローチは、特に二つ以上の公用語を有する国でメッセージを受信する人にとって適切ではない場合がある。
４）電子メッセージの複数の受信者でアドレス連結メカニズムをどのように使用し得るかについて指摘されていない。
５）メッセージの返信又は転送をどのように処理するべきかについて何ら指摘されていない。
６）好ましくない言語で受信者に受信されたメッセージをどのように処理するかについて指摘されていない。

Ｓｃａｎｌａｎのアプローチにおいて、受信者は、新しいメッセージアドレスを翻訳サイトに登録する必要がある。受信者にメッセージを送信する人は、この新しいアドレスにメッセージを送信し、その後、受信者は、自分のコンピュータシステムに常駐する既存のメッセージクライアントアプリケーションプログラムを使用して、翻訳メッセージを取り出す。Ｓｃａｎｌａｎのアプローチも、いくつかの問題を抱えている。
１）受信者は、翻訳メッセージを受信する目的で、新しいメッセージアドレスを登録する必要がある。
２）受信者は、受信を希望する言語毎に新しいメッセージアドレスを登録する必要があり、したがって、複数のアドレスを有する。
３）送信者は、この新しいメッセージアドレスを認知する必要がある。
４）提供された翻訳サービスの料金を送信者に請求できない。
５）新しいメッセージアドレスは、一つの言語で綴られるが、多数の言語領域のユーザによってアクセスされる。
６）送信者は、メッセージのどの部分が翻訳されるかを制御できない。
７）送信者は、翻訳メッセージの品質に影響を与え得る翻訳プロセスを制御できない。

Ｂｏｕｃｈｅｒ及びＳｃａｎｌａｎはどちらも、ユーザがメッセージに返信する時、或いはメッセージを転送する時に翻訳メッセージを処理する複雑性に対処していない。メッセージ内の情報を構造化された形でパッケージ化するステップを用いない限り、メッセージに返信する時には同じテキストの多重翻訳が発生し、メッセージを転送する時にはオリジナルテキストの縦続的翻訳が発生し得る。更に、メッセージが転送される時、メッセージには、メッセージが転送された回数と同じ数の翻訳が含まれ、返信が加わる時に、ユーザの選択言語であるメッセージ部分のみを閲覧するのに不都合となり得る。

人間翻訳は、厳正科学ではなく、機械翻訳は、依然として、人間翻訳で生じるものと同じ品質レベルに到達する努力を続けている。機械翻訳サービスを提供する任意の中央サイトは、翻訳プロセスを構成するのに使用される翻訳オプションに対応する能力をサポートし、これにより、翻訳出力の品質を高める必要がある。Ｂｏｕｃｈｅｒはこの問題に僅かに触れているが、Ｓｃａｎｌａｎは、翻訳オプションの問題に全く言及していない。

Ｂｏｕｃｈｅｒの特許は、主に、送信先アドレスの操作を介したメッセージのリダイレクトのためのメカニズムに関係する。リダイレクト方法は、リダイレクトを達成するために、ユニフォームリソースロケータ（ＵＲＬ）アドレスの基本的アーキテクチャに依存しており、そのためＢｏｕｃｈｅｒは、このアドレス方式を使用したメッセージのリダイレクトに限定される。Ｂｏｕｃｈｅｒは、コンピュータプログラミング業者によって構築可能なアドインモジュールの使用を介してメカニズムを自動化することに数回言及し、システムにおいてメカニズムをどのように応用できるかについて、いくつか示唆している。しかしながら、完全に機能するシステムを構築するのに必要なアドインの特徴及び機能は扱われておらず、翻訳プロセスを自動化するために、連絡先リストのようなメッセージングシステムの既存の特徴をどのように使用し得るかについての意見も全く存在しない。Ｓｃａｎｌａｎの特許は、本質的に、メッセージの翻訳が行われるＷｅｂサイトについて説明している。

電子メッセージの自動翻訳を提供すると主張するシステムは、以下の目的を満たす必要がある。
１）システムは電子メッセージの翻訳を達成するためにユーザの介入を必要としない。
２）ユーザの既存のメッセージングシステムとのシームレスな統合。
３）ユーザは、通常の作業慣例の変更を強いられない。
４）ユーザは、余分な又は専門的な電子メールアドレス等の追加的リソースの取得を強いられない。

こうした目的から生じた、自動電子メッセージ翻訳システムの顕著な特徴及び機能は、次の通りである。
１）ユーザが言語障壁を越えて通信するのを可能にすると同時に、ユーザが既存の通信アドレスを使用できるようにするシステム。
２）機械翻訳サービスを提供する中央サイトへメッセージをリダイレクトするメカニズム。
３）ユーザの介入を必要としないメッセージリダイレクトメカニズム。
４）電子メールメッセージと、電子通信のその他の形態とに等しく応用可能なメッセージリダイレクトメカニズム。
５）通信リンクの送信側及び受信側の両方で、翻訳のために中央サイトへメッセージをリダイレクトする能力。
６）ユーザ自身の言語と比較するために、着信メッセージの言語を自動的に検出する能力。
７）リダイレクトプロセスを自動化し、メッセージ翻訳サービスを提供する中央サイトと通信するアドインモジュールの提供。
８）翻訳が正当かどうかを判断するための比較が実行できるような、送信者及び受信者の言語へのアクセス。
９）メッセージを複数の受信者へ送信する能力を妨げないメッセージリダイレクトメカニズム。
１０）それぞれが異なる言語を有する可能性のある複数の受信者へメッセージを送信する能力をサポートするシステム。
１１）電子メールボディの翻訳を、何らかの添付物とは別個に処理する能力。
１２）電子メール及びその添付物内の電子メールを処理する能力。
１３）閲覧者自身の言語であるメッセージのセクションのみを閲覧するためのフィルタに加えて、メッセージの返信及び転送を処理する複雑性をサポートする翻訳メッセージの構造化パッケージの提供。
１４）翻訳品質を高めるためにメッセージ用の様々な翻訳オプションを定義する能力。
１５）アドレス等、翻訳するべきではないテキストのセクションをマークする能力。
１６）受信メッセージを翻訳サイトへ再提出し、翻訳品質を改善するために翻訳オプションを適用する能力。
１７）「単語が見つからない」等の翻訳の問題をモニタするために、送信者がメッセージのエコーバックを発生させる能力。
１８）受信者が未翻訳メッセージを翻訳のために中央サイトへ提出する能力。
１９）翻訳言語が受信者の選択言語ではない場合に翻訳言語を変更するため、及び後で翻訳の品質を改善するために、受信者がメッセージを中央サイトへ再提出する能力。
２０）暗号化メッセージと、安全ではないネットワークを介して送信されるメッセージとを対象とした安全な通信を処理する能力。
２１）システム全体は、新たな技能の学習又は追加的リソースの取得を必要とせずに、自動メッセージ翻訳の利点を提供するために、全てが統合されたものとして動作する。

上記の項目が提案の中で対処されていない限り、結果的なシステムは、電子メッセージの翻訳のための包括的な完全自動システムであるとは見なされない。

したがって、本発明は、送信者からの通信を送信するように構成された送信システムと、受信者に対する通信を受信するように構成された受信システムと、翻訳システムとを備える、人間のコミュニケーションのための通信システムを提供し、送信システムは、通信を送信する時、送信者に関連する第一の人間認知可能な言語と、受信者に関連する第二の人間認知可能な言語とを決定し、第一及び第二の言語が異なる場合には、受信システムのアドレスと共に通信を翻訳システムへ翻訳のために送信し、これにより、翻訳システムが迂回通信を翻訳のために受信し、翻訳済み通信を受信システムへ転送できるようにし、但し、第一及び第二の言語が同じである場合には、通信を直接受信システムへ送信するように構成され、受信システムは、通信の受信時に、送信者に関連する第一の人間認知可能な言語と受信者に関連する第二の人間認知可能な言語とを決定し、第一及び第二の言語が異なる場合には、受信システムのアドレスと共に通信を翻訳システムへ翻訳のために送信し、これにより、翻訳システムが通信を翻訳のために受信し、翻訳済み通信を受信システムへ返送できるようにし、但し、二つの言語が同じである場合には、受信システムへ送信された通信を受け入れるように構成される。

本発明は、更に、送信者から受信者へ通信を送信するように構成された送信システムと、翻訳システムとを備える通信システムを提供し、送信システムは、通信を翻訳する必要がある時を判断し、通信を翻訳システムへ翻訳のために転送するように構成され、送信システムは、送信者が通信を翻訳システムへ翻訳のために送信し、翻訳済み通信が受信者へ送信される前にチェックするために送信者へ返送できるように構成された送信者入力を含む。

本発明は、更に、受信者に対する通信を受信するように構成された受信システムと、翻訳システムとを備える通信システムを提供し、受信システムは、受信者による閲覧のために通信を表示するように構成された表示手段と、受信者が受信済み通信を少なくとも一つの翻訳パラメータと共に翻訳システムへ提出し、これにより、受信者の制御による受信済み通信の翻訳を提供できるように構成された受信者入力とを備える。

翻訳パラメータは、受信された通信の言語を含んでよく、或いは、専門的な又はカスタマイズされた翻訳辞典又は用語集、若しくは通信のコンテンツのスタイル又はカテゴリの指示を含んでよい。

本発明の好適な実施形態の特徴の一部の利点について、次に説明する。

本明細書で説明する本発明の一部の実施形態は、Ｂｏｕｃｈｅｒ及びＳｃａｎｌａｎのアプローチの欠点を克服し、更に返信及び転送中にメッセージを処理する問題に対処するシステム及び方法を提供する。システムは、好ましくは、翻訳サービスを提供する中央サイトと共に、ユーザのコンピュータシステムに常駐するアドインモジュールで構成される。アドインモジュールは、ユーザのコンピュータシステムに常駐する既存のメッセージクライアントアプリケーションプログラムと調和して動作する。アドインモジュールと翻訳サービスを提供する中央サイトとの間の協力的な関連性は、送信者から受信者へ渡される電子メッセージを翻訳するプロセスが両者にとって完全に不可視であることを意味する。

翻訳サービスを中央サイトに配置することは、多数の言語に渡る翻訳をサポートするあらゆる複雑性がユーザのシステムに搭載されないことを意味する。更に、中央翻訳リソースを有することは、原則として、翻訳リソースに全員がアクセス可能であり、全員が最新の機械翻訳技術を利用可能であり、広範な言語ペアを利用可能にできることを意味する。

アドインモジュールは、送信者及び受信者の言語に基づいて、メッセージが翻訳を必要とするかを判断する。二つの言語の違いにより、アドインは、メッセージを翻訳のために中央サイトへリダイレクトし、その後、翻訳済みメッセージは、受信者へ運ばれる。メッセージのリダイレクトは、送信者のコンピュータシステム、受信者のコンピュータシステム、或いは、送信者及び受信者の両者間で送信されるメッセージを処理する中間サーバにおいて開始できる。リダイレクトが送信者のコンピュータシステムで開始される時、アドインモジュールは、送信者の言語と受信者の選択言語とに関して以前に定義された情報を使用できる。対照的に、リダイレクトが受信者のコンピュータシステム又は中間サーバで開始される時、送信者の言語は、自動言語検出手法を使用してメッセージテキスト自体からのみ判断可能となり、一方、受信者の言語は、例えば、受信者が入力又は選択することで、以前に定義されていると想定される。

メッセージリダイレクトは、新規作成メッセージに対しては、送信者のコンピュータシステムで実行され、受信者の好まない言語でメッセージが送給された時には、受信者のシステム又は中間サーバで実行される。通信リンクの送信者側又は受信者側でのリダイレクトは、通信の両参加者がインターネットサービスプロバイダ（ＩＳＰ）に接続している時に適切であり、一方、中間サーバでのリダイレクトは、組織がローカルサーバを介した独自のメッセージング能力を保有する場合に特に適している。

翻訳サービスを提供する中央サイトは、アドインモジュールからメッセージを受領し、その後、アドインがメッセージヘッダ及びメッセージの本文に配置した情報を使用して、翻訳プロセスを構成する。翻訳が完了すると、メッセージヘッダの情報は、翻訳メッセージを意図する受信者へ運ぶために使用される。メッセージヘッダに配置された追加情報、或いはメッセージの専用セクションに添付された追加情報は、受信者へ送給される前にメッセージから削除される。

アドインモジュールと中央サイトとの間の協調によって、翻訳のプロセスが送信者及び受信者の両方にとって完全に不可視になる状態が確保される。更に、両者は、互いに通信するための既存の電子メールアドレスを使用する。

本発明の原則的な目的は、電子送信メッセージのトランスペアレントな翻訳を提供することである。本発明の更なる目的は、通信の参加者が通常の作業慣例を変更する必要のないシステム、或いは電子送信メッセージの翻訳を容易にするために追加的リソースを取得する必要のないシステムを提供することである。

本発明は、電子メールメッセージのようなテキスト通信の翻訳に関するが、この形態又は通信には限定されない。電子メッセージは、音声及びオーディオ／ビジュアル通信と、送信者から受信者へのメッセージの伝達において翻訳が必要となり得る他の任意の形態の電子通信とを含むことができる。

通信は、ローカルエリアネットワーク、イントラネット、及びインターネットに渡るコンピュータネットワークを介してトランスポートしてよいが、こうしたメッセージトランスポート形態には限定されない。

本発明は、コンピュータネットワークを介してトランスポートされる通信を翻訳するシステム及び方法を提供し、通信は、第一の人間認知可能な言語で発送され、第二の人間認知可能な言語で送信先に到着する。通信は、送信元サイトで開始され、コンピュータネットワークを渡って送信先サイトへトランスポートされる。送信元及び送信先サイトの両方の位置は、コンピュータネットワーク上で使用されるメッセージトランスポートプロトコルにおいて一般的に使用されるアドレスによって指定される。

本発明は、電子送信メッセージのトランスペアレントな翻訳を提供するシステム及び方法に存在する。システムは、ユーザのコンピュータシステムにインストールされ、電子メッセージを作成、送信、及び受信するために使用される既存のアプリケーションパッケージに統合されるモジュールによって構成される。追加的な特徴及び機能を提供するために既存のアプリケーションに統合されるモジュールは、コンピュータ業界ではアドイン又はプラグインモジュールとして知られている。アドインモジュールは、電子メッセージのトランスペアレントな翻訳を一部として含む付加価値サービスを提供する中央サイトと共同で動作する。

中央サイトは、単一の一貫した計算リソースを提供するために連結されたコンピュータシステムの配置によって構成してよい。中央サイトの目的は、アドインモジュールによって送信されたメッセージを受信し、メッセージを第一の人間認知可能な言語から第二の人間認知可能な言語へ翻訳し、翻訳メッセージを送信先サイトへ運ぶことである。アドインモジュールと中央サイトとの間での協調的な仕組みは、電子送信メッセージにおける透明性を提供し、通信の参加者に通常の作業慣例の変更、或いは追加的リソースの取得を要求しない。

アドインモジュールは、ユーザの既存のメッセージングシステムに対する、本明細書で説明する技術のシームレスな統合を容易にできるが、但し、本発明の別の実施形態では、アドインに含まれる技術は、そのシステムの製造業者によって既存のメッセージングシステムに統合できると認識される。このアプローチは、アドインとして同一の特徴及び機能を提供するが、これにより、技術は、特定のメッセージングシステムに限定される。したがって、本明細書で説明する実施形態はアドインモジュールの使用を介したものとする。

アドインモジュールは、送信者のコンピュータシステム、受信者のコンピュータシステム、或いは、送信者及び受信者の両者間で送信されるメッセージを処理する何らかの中間サーバに常駐できる。アドインモジュールは、メッセージをインタセプトし、送信者の言語と受信者の言語とを一致させる。二言語間の一致が生じた場合、アドインは、メッセージを無視し、メッセージを通常の形で処理させ、そうでない場合には、不一致によって、アドインは、メッセージを翻訳のために中央サイトへリダイレクトする。中央サイトがメッセージを翻訳した後、メッセージは、送信先サイトへ運ばれる。

送信者のシステムに常駐するアドインモジュールは、発信メッセージをインタセプトし、送信者の言語と受信者の言語とを一致させ、その後、これらの言語の不一致により、アドインモジュールは、メッセージを翻訳のために中央サイトへリダイレクトする。送信者の言語は、例えば、送信者又は送信システムのその他のユーザが送信システムを使用して入力又は選択することで、以前に定義されていると想定され、受信者の言語は、電子メッセージングアプリケーションに関連する電子アドレス帳から取得されるか、或いは送信者自身から要求される。

システムでのアドインモジュールの使用は、人間が読める形態での言語名の選択を容易にする。更に、アドインモジュールは言語名の地域固有の変形を全て共通の表現にマッピングできるため、言語名の選択は、特定の言語地域によって制約されない。アドインモジュールは、中央サイトへ送信されたメッセージ内にある言語名の共通表現を伝達し、その後、この言語名の共通表現は、中央サイトが言語情報を使用した後で、メッセージから廃棄される。

受信者のシステムに常駐するアドインモジュールは、着信メッセージをインタセプトし、送信者の言語と受信者の言語とを一致させ、その後、これらの言語の不一致により、アドインモジュールは、メッセージを翻訳のために中央サイトへリダイレクトする。送信者の言語は、十分に確立された自動言語検出手法をメッセージテキストに使用して取得され、受信者の言語は、例えば、受信者又は受信システムのその他のユーザが受信システムを使用して入力又は選択することで、以前に定義されていると想定される。

中間サーバに常駐するアドインモジュールは、着信メッセージをインタセプトし、送信者の言語と受信者の言語とを一致させ、その後、これらの言語の不一致により、アドインモジュールは、メッセージを翻訳のために中央サイトへリダイレクトする。送信者の言語は、十分に確立された自動言語検出手法をメッセージテキストに使用して取得され、受信者の言語は、中間サーバ上で実行されるメッセージトランスポートサーバアプリケーションに関連する電子アドレス帳から取得される。

送信者又は受信者のシステムに常駐するアドインモジュールは、インターネットに接続して電子メッセージの送受信を行うためにインターネットサービスプロバイダ（ＩＳＰ）を利用する人達による使用を対象としたものである。中間サーバに常駐するアドインモジュールは、独自のローカルサーバを使用してメッセージトランスポートサービスを提供する組織による使用を対象としたものである。

アドインモジュールは、メッセージヘッダの「ユーザ定義」フィールド内のオリジナルの送信先サイトアドレスを保存し、これを中央サイトのアドレスと置き換えることで、電子メッセージをリダイレクトする。メッセージが中央サイトで翻訳された後、オリジナルの送信先アドレスが復元され、メッセージヘッダに対する修正は、廃棄される。その後、中央サイトは、結果的に生じたメッセージを対象受信者へ転送する。

アドインモジュールは、送信者及び受信者の言語を両方とも決定した後、中央サイトでの使用のために、これらの言語をメッセージヘッダの「ユーザ定義」フィールドに追加する。中央サイトがこの情報を使用してメッセージを翻訳した後、メッセージヘッドに対して行った修正は廃棄される。その後、中央サイトは、結果的に生じたメッセージを対象受信者へ転送する。

アドインモジュールは、メッセージの原則的な受信者だけでなく、メッセージの他の任意の受信者も決定できる。この状況下では、存在するメッセージの受信者と同じ数の送信先言語が存在する可能性がある。アドインモジュールは、受信者全体に渡って、関与する送信先言語それぞれについて、中央サイトへのリダイレクトのためにメッセージをパッケージ化し、これにより、中央サイトでの多重翻訳を回避する。

本発明の基本的な態様は、翻訳サービスを提供するために中央サイトに結合された既存の電子メッセージングアプリケーションに特別な特徴及び機能を提供し、提供される翻訳サービスにおける透明性を提供するが、ユーザに通常の作業慣例を変更すること、或いは余分なメッセージアドレスのような追加的リソースを取得することを構成しない、アドインモジュールの使用である。

人間翻訳は、厳正科学ではなく、機械翻訳は、依然として、人間翻訳と同じ品質レベルに到達する努力を続けていると認識されており、したがって、同じテキストの多重翻訳は回避する必要がある。中央サイトは、メッセージが中央サイトで処理される度に、オリジナルテキストと翻訳バージョンとの両方をメッセージ内で単一の論理ユニットにパッケージ化する。ユーザがメッセージに返信する時、その寄稿は、完成したメッセージが最初の送信者に返送される前に、現在のメッセージの先頭に添付される。中央サイトはオリジナルテキストと翻訳バージョンとの両方をパッケージ化するため、これにより、多重翻訳を実行する要件は排除される。この方法は、返信が送られる度に繰り返され、オリジナルテキストと翻訳バージョンとで構成されたメッセージに更なる論理ユニットが追加される。両方の言語バージョンのオリジナルメッセージと返信とが通信の両方の参加者に利用可能となるため、それぞれが、自分の言語と、全ての言語を示す完成したメッセージとにおいて返信を閲覧できる。

返信を処理するために使用される上記の方法の変形は、ユーザがメッセージを転送する時に必要となる。この状況では、中央サイトは、メッセージが転送される機会毎に、オリジナルテキストと、テキストの翻訳バージョンとをパッケージ化する。オリジナルテキストはメッセージが転送される度に利用可能であるため、オリジナルテキストに由来する別の言語バージョンが、論理ユニットに添付され、これにより、オリジナルテキストの縦続的翻訳が回避される。オリジナルメッセージと全ての言語バージョンとが通信の全ての参加者に利用可能となるため、それぞれが、自分の言語でメッセージを閲覧できる。

中央サイトがオリジナルテキストと全ての翻訳バージョンとをメッセージ内で単一の論理ユニットにパッケージ化する方法は、メッセージに対する返信、及びメッセージの転送と、発生し得る任意の組み合わせとにおいて等しく機能する。

コンピュータ業界で現在使用されている、電子テキストに基づくメッセージの交換に対する規格は、プレーンテキスト、書式付きテキスト、音声、オーディオ／ビジュアル、及び画像を一部として含む他のタイプの通信をメッセージに添付する能力を提供する。こうしたメッセージタイプは、全てが翻訳を必要とする訳ではなく、或いは翻訳に適している訳ではないと認識される。したがって、方法は、メッセージを作成したユーザが特に命令しない限り、添付物は翻訳されないものとみなす。

ユーザが翻訳を選択した添付物を電子メッセージが含む時、メッセージの返信及び転送に関連する問題は、添付物にも同様に当てはまる。中央サイトは、メッセージテキストと全く同じ形で、オリジナルの添付物と翻訳バージョンとの両方を、単一の論理ユニットにパッケージ化する。

機械翻訳は、今のところ、翻訳品質を高めて人間の翻訳者によって達成可能なものに近付けるために、様々なオプションに関して人間による入力を必要とする。アドインモジュールによって、既存のメッセージングアプリケーションの外部で、こうした翻訳オプションの入力が可能となり、更に、こうしたオプションは、中央サイトが使用して機械翻訳プロセスを構成するために、電子メッセージ内の専用セクションにパッケージ化できる。中央サイトが翻訳オプションを利用した後、こうしたオプションは、中央サイトが翻訳メッセージを送信先サイトへ転送する前に、メッセージから廃棄される。

本発明の別の態様によれば、送信者がメッセージを発送した後、翻訳メッセージは送信先サイトへ転送されるため、翻訳プロセス中に遭遇した何らかの問題は、送信者には不可視になると認識される。アドインモジュールを介して、送信者は、メッセージを中央サイトへ提出し、機械翻訳プロセスが何らかの問題に遭遇したかの報告と、問題を解決するのに適切となり得る何らかの推奨とに加えて、翻訳メッセージを自分自身に返送させることができる。手順は、送信者が機械翻訳の結果に満足するまで反復できる。

本発明の別の態様によれば、通信リンクの受信者側でメッセージがインタセプトされる時、翻訳が必要かどうかを決定するために、自動言語検出が使用される。テキスト自体から言語を決定するために現在利用できる最も有効なアプローチは、統計に基づくアプローチを使用し、利用可能なテキストの長さが長いほど、結果の精度は高くなる。ソース言語及びメッセージに関する任意の不確実性は、受信者のメッセージボックスに配置して、ユーザが必要と考える何らかの適切な措置を実行可能にする必要がある。更に、メッセージをインタセプトするアドインモジュールは、メッセージの内容について予備知識を有しておらず、したがって、メッセージのために何らかの翻訳オプションを設定できないため、達成可能な機械翻訳の品質は、受信者がオリジナルメッセージを理解する上で十分なオリジナルテキストの要旨と表現するのが最適な程度のものとなる。この時点において考慮することが重要なシステムの更に別の面は、不適切な言語が選択され得るリスクが付随する状態で、送信者が受信者の選択言語を定義するという事実に関係する。こうした全ての問題を集約すると、アドインモジュールは、受信者が翻訳のために中央サイトへ選択メッセージを再提出することを選択可能な機能を提供する必要がある。アドインモジュールを介して、ユーザは、メッセージについて、自分が好む言語を指定可能であり、更に、適切と考える一組の翻訳オプションを定義可能である。手順は、送信者が機械翻訳の結果に満足するまで反復できる。

電子メッセージは、別の電子メッセージに埋め込んでもよいと認識される。本発明の別の態様によれば、埋め込みメッセージは、カプセル化電子メッセージを処理するのに使用されるものと同じ方法を使用して処理される。

次に、本発明の好適な実施形態について、以下の添付図面を参照して、単なる例証として説明する。

図１を参照すると、通信システムの一部を形成する送信システム１１は、パーソナルコンピュータの形態をとり、電子メールクライアントを備えるアプリケーション１０と、メッセージトランスポートサブシステムを含み、インターネットに接続されたオペレーティングシステム１２と、アドインモジュール１４とを含む。スクリーン１６は、下で説明するように、送信者によるシステムの様々な機能の操作を可能にするアプリケーションツールバー１８を表示する。電子メールクライアントは、更に、受信者の好適な言語を収容する連絡先リスト１０ａを含む。ユーザがメッセージを送信する時、アプリケーション１０は、ユーザがアプリケーションツールバーの「メッセージ送信」ボタン１０１（図４参照）を押すことに応答して、「メッセージ送信」イベントを発生させる。アドインモジュール１４は、「メッセージ送信」イベントをインタセプトし、翻訳が必要な場合、メッセージを操作して、中央サイト３１（図３参照）へリダイレクトする。操作されたメッセージは、オペレーティングシステム１２の基礎的なメッセージトランスポートサブシステムに渡される。次に、メッセージは、中央サイトへの送給のためにインターネットへ送信され、その後、送信先サイトへ転送される。

中央サイトへのメッセージのリダイレクトは、メッセージヘッダの「ユーザ定義」フィールド内のオリジナルの送信先サイトアドレスを保存し、これを中央サイトのアドレスと置き換えることで達成される。この動作は、アドインモジュールによって行われるため、ユーザには完全に不可視となる。中央サイトでは、メッセージが処理された後、保存済み送信先アドレスが中央サイトのアドレスに置き換わり、メッセージヘッダの「ユーザ定義」フィールドが削除され、これにより、メッセージは、中央サイトにリダイレクトされる前の最初の状態に復帰する。リダイレクトを達成する、このメッセージ操作の動作例を下に示す。
オリジナルメッセージ：
Ｆｒｏｍ：ｊｏｈｎ．ｄｏｅ＠ｃｏｍｐａｎｙ．ｃｏ．ｕｋ
Ｓｅｎｔ：１ Ｏｃｔｏｒｂｅｒ ２００２ １７：３５
Ｔｏ：ｐａｂｌｏ．ｍｕｎｏｚ＠ｃｏｍｐａｎｙ．ｅｓ
Ｓｕｂｊｅｃｔ：Ｇｒｅｅｔｉｎｇｓ
Ｔｈａｎｋ ｙｏｕ ｆｏｒ ｙｏｕｒ ｈｏｓｐｉｔａｌｉｔｙ ｌａｓｔ ｗｅｅｋ．
リダイレクトメッセージ：
Ｆｒｏｍ：ｊｏｈｎ．ｄｏｅ＠ｃｏｍｐａｎｙ．ｃｏ．ｕｋ
Ｓｅｎｔ：１ Ｏｃｔｏｒｂｅｒ ２００２ １７：３５
Ｔｏ：ａｎｏｎｙｍａｏｕｓ＠ｔｒａｎｓｌａｔｉｏｎ−ｓｉｔｅ．ｃｏｍ
Ｘ−ｔｏ：ｐａｂｌｏ．ｍｕｎｏｚ＠ｃｏｍｐａｎｙ．ｅｓ
Ｓｕｂｊｅｃｔ：Ｇｒｅｅｔｉｎｇｓ
Ｔｈａｎｋ ｙｏｕ ｆｏｒ ｙｏｕｒ ｈｏｓｐｉｔａｌｉｔｙ ｌａｓｔ ｗｅｅｋ．
翻訳メッセージ：
Ｆｒｏｍ：ｊｏｈｎ．ｄｏｅ＠ｃｏｍｐａｎｙ．ｃｏ．ｕｋ
Ｓｅｎｔ：１ Ｏｃｔｏｒｂｅｒ ２００２ １７：３５
Ｔｏ：ｐａｂｌｏ．ｍｕｎｏｚ＠ｃｏｍｐａｎｙ．ｅｓ
Ｓｕｂｊｅｃｔ：Ｓａｌｕｄｏｓ
Ｇｒａｓｉａｓ ｐｏｒ ｓｕ ｈｏｓｐｉｔａｌｉｄａｄ ｌａ ｓｅｍａｎａ ｐａｓａｄａ．

「オリジナルメッセージ」は、メッセージ作成パッケージを使用して、送信者が作成したものである。「リダイレクトメッセージ」は、アドインモジュールによって構築され、翻訳サイトへ送信されるものである。最初の送信先アドレスを保持するための「Ｘ−ｔｏ：」フィールドの追加と、翻訳サイトのアドレスに置き換えられた最初の送信アドレス（Ｔｏ：）とに留意されたい。翻訳サイトのアドレスを上の例に示したようなグローバルアクセスポイント（即ち、Ｔｏ：ａｎｏｎｙｍａｏｕｓ＠ｔｒａｎｓｌａｔｉｏｎ−ｓｉｔｅ．ｃｏｍ）にする代わりに、提供されたサービスの料金をユーザに請求するのを容易にするために、アドレスは、ユーザ固有にすることができる（即ち、ｊｏｈｎ．ｄｏｅ＠ｔｒａｎｓｌａｔｉｏｎ−ｓｉｔｅ．ｃｏｍ）。メッセージが翻訳された後、メッセージヘッダに施された調整は、「翻訳メッセージ」に示したように、メッセージが受信者へ転送される前に除去される。

本発明の主要な実施形態は電子メールメッセージのリダイレクトを対象とするが、必ずしも電子メールメッセージプロトコルには限定されない（ＲＦＣ８２２：ＡＲＰＡインターネットテキストメッセージのフォーマットに関する規格、ＲＦＣ２８２２：インターネットメッセージフォーマット、及びＲＦＣ８２１／ＲＦＣ２８２１：シンプルメール転送プロトコル参照）。メッセージプロトコルがメッセージヘッダ内の「ユーザ定義」フィールドをサポートし、フィールドがアーキテクチャにおいて自由形態であるならば、上に記載されたリダイレクトメカニズムは、原則として、電子メールメッセージだけでなく、メッセージを、中央サイトでの翻訳のために他のプロトコルを使用してリダイレクトするのに使用できる。

図４を参照すると、ツールバー１８は、例えば、電子メールクライアントのメインツールバーエリアに追加し得る多数のボタンを含む。送信ボタン１０１により、システムは、メッセージを受信者へ送信する。オプションボタン１０２により、ユーザは、多数の異なるダイアログを介してアクセスされた様々なグローバルオプションを変更できる。プロパティボタン１０３により、ユーザは、多数の翻訳オプションを修正できるが、変更は、現在のメッセージに対してのみ適用される。エコーバックボタン１０４によって、ユーザは、試験翻訳のためにメッセージを翻訳システム３１に提出でき、その後、翻訳プロセス中に遭遇した問題に関する情報がユーザに戻される。翻訳チェッカボタン１０５により、ユーザは、メッセージを翻訳システム３１に提出でき、その後、翻訳品質を改善するための推奨のリストが戻される。再提出ボタン１０６では、自分の母国語ではないメッセージを送信したユーザは、最初に目標言語を変更し、その後、そのメッセージを希望に応じて何度でも翻訳プロセスに通過させ、翻訳品質を改善できる。再送信ボタン１０７により、ユーザは、エコーバックボタン１０６を使用した試験翻訳で受領したメッセージ等、閲覧のために開いた、ユーザの受信トレイ内に現れるメッセージを、送信する準備ができる。フィルタボタン１０８により、ユーザは、自分の母国語であるメッセージのコンポーネントを閲覧でき、或いは、完全なメッセージを表示できる。これらのボタンの一部の動作については、下で更に詳細に説明する。

アドインは、追加的な挙動の提供のみを行い、付与されたプログラムの使用方法を変化させず、或いは付与されたプログラムによって現れる既存の挙動を損なわないことが好ましい。例えば、受信者が連絡先リスト１０ａ内で見つからない状況では、受信者の言語等の情報は、ユーザに求める必要がある。この要件を既存の「メッセージ送信」ボタンにおいて実施すれば、明らかに、プログラムの使用及び挙動は変更される。しかしながら、「メッセージプロパティ」ボタン１０３の追加により、受信者の言語及びその他の翻訳オプションといったメッセージ固有の情報の入力が容易となる。

図２ａを参照すると、受信システム２１ａは、メッセージトランスポートサブシステムを含むオペレーティングシステム２２ａと、電子メールクライアント２４ａと、言語検出ソフトウェアを含むアドインモジュール２６ａとを備える。電子メールクライアント２４ａがオペレーティングシステム２２ａの支援を使用してリモートサーバからメッセージをダウンロードする時、メッセージは、オペレーティングシステム２２ａによってサポートされる受信者の受信トレイに保存される。アドインモジュール２６ａは、オペレーティングシステム２２ａが発生させた「メッセージ格納」イベントに応答し、保存したばかりのメッセージを調べる。メッセージが処理を必要とする場合、メッセージは受信トレイから取り除かれ、オリジナルメッセージが翻訳を必要とすることをユーザに通知する「ダミーメッセージ」がその場所に残される。アドインモジュール２６ａは、メッセージを操作して、中央サイトへのリダイレクトを発生させる。操作されたメッセージは、オペレーティングシステム２２ａの基礎的なメッセージトランスポートサブシステムに渡される。次に、メッセージは、中央サイトへの送給のためにインターネットへ送信され、翻訳及び更なる操作を用いて修正される。修正済みメッセージは、次に、リモートサーバに存在するメッセージボックスに転送される。電子メールクライアント２４ａは、オペレーティングシステム２２ａの支援を使用して、リモートサーバから修正済みメッセージをダウンロードし、その後、修正済みメッセージは、オペレーティングシステム２２ａによってサポートされる受信トレイに保存される。受信トレイからは、例えば、ＰＣ画面上での表示のために、メッセージにアクセスできる。アドインモジュール２６ａは、オペレーティングシステム２２ａが発生させた「メッセージ格納」イベントに応答し、保存したばかりのメッセージを調べる。アドインモジュール２６ａは、保存メッセージを修正済みメッセージとして認識した時、中央サイトが電子メールヘッダに配置した余分なフィールドを除去する。修正済みメッセージは、その後、受信者の受信トレイに戻される。受信トレイからは、例えば、ＰＣ画面上での表示のために、メッセージにアクセスできる。

図２ｂを参照すると、更なる受信システム２１ｂは、メッセージトランスポートサブシステムを含むオペレーティングシステム２２ｂと、電子メールクライアント２４ｂと、言語検出ソフトウェアを含むアドインモジュール２６ｂとを備える。メッセージがインターネットから受信された時、オペレーティングシステム２２ｂは、メッセージの受信に応答して「メッセージ受信」イベントを発生させる。アドインモジュール２６ｂは、「メッセージ受信」イベント（電子メールサーバへ進んでしまうはずのもの）をインタセプトし、メッセージの処理が必要かをチェックし、必要な場合、アドインモジュール２６ｂは、メッセージを操作して、中央サイトへのリダイレクトを発生させる。操作されたメッセージは、オペレーティングシステム２２ｂの基礎的なメッセージトランスポートサブシステムに渡される。次に、メッセージは、中央サイトへの送給のためにインターネットへ送信され、翻訳及び更なる操作を用いて修正される。次に、修正済みメッセージは、返送され、その後、インターネットからオペレーティングシステム２２ｂによって再び受信され、オペレーティングシステムは、メッセージの受信に応答して「メッセージ受信」イベントを発生させる。次に、アドインモジュール２６ｂは、「メッセージ受信」イベントをインタセプトし、受信メッセージを修正済みメッセージとして認識した時、中央サイトが電子メールヘッダに配置した余分なフィールドを除去する。修正済みメッセージは、次に、電子メールサーバ２４ｂに転送され、その後、受信者によるアクセス及び表示のために受信者の受信トレイに置かれる。

図３を参照すると、翻訳システム３１は、送信及び受信コンピュータシステムからリモートに位置する中央サイトに位置し、オペレーティングシステム３２と、独自の辞書を含む翻訳モジュール３４と、メッセージリダイレクトモジュール３６とを備える。翻訳システム３１は、更に、中央サイトのインターネットポータルを介してユーザがアクセス及び閲覧可能な多数のオンライン辞書を含む。送信システム１１或いは受信システム２１ａ又は受信システム２１ｂのいずれかがメッセージを翻訳システム３１へ向かわせた時、メッセージは、翻訳モジュール３４へ渡され、翻訳モジュール３４からメッセージリダイレクトモジュール３６へ渡され、ここで、メッセージヘッダ内で、中央サイトのアドレスは、送信先サイトのアドレスに置き換えられる。翻訳メッセージは、その後、オペレーティングシステム３２の基礎的なメッセージトランスポートサブシステムへ渡され、送信先サイトへの送給のためにインターネットへ送信される。

図５は、通信リンクの送信者の側、即ち、図１の送信システムでのメッセージのリダイレクトにおいて実行されるタスクの概要を提供する。メッセージは、ツールバー１８上の「メッセージ送信」ボタン１０１の使用を介して、或いは対応するメニューオプションの選択を介して送信される。いずれのルートでも、「メッセージ送信」イベントハンドラ５０１へのエントリが発生し、ここでの第一のタスクは、図のステップ５０２に示したように、連絡先リスト１０ａから受信者の言語を取得することである。ステップ５０３では、送信者の言語を受信者のものと比較することで、その後の翻訳のための中央サイト３１へのメッセージのリダイレクトが正当であるかを判断する。翻訳の必要がないと仮定すると、メッセージは、原形のまま残され、そうでない場合、メッセージヘッダの送信先アドレスは、ステップ５０４において、中央サイト３１へのリダイレクトを達成するために変更され、オリジナルの受信者アドレスはメッセージヘッダ内に保存される。最後に、ステップ５０５において、送信者及び受信者の言語が、メッセージヘッダに追加される。

「メッセージ送信」イベントハンドラにおいて実行されるタスクの上記簡略図では、受信者が連絡先リスト１０ａ内に存在することを想定しているが、しかしながら、これが常に当てはまるとは限らない。受信者が連絡先リスト１０ａに存在しない状況、或いは受信者の選択言語が事前に定義されていない状況では、「メッセージ送信」ボタン１０１が使用された時、メッセージは、受信者に直接送信される。しかしながら、「メッセージ送信」ボタン１０１の前に「メッセージプロパティ」ボタン１０３が使用された場合、これによりダイアログが表示され、その後、受信者に関して、要求された情報を入力できる。受信者の言語が送信者のものと異なる場合、「メッセージ送信」ボタン１０１を押すことで、メッセージは翻訳システム３１へリダイレクトされる。「メッセージ送信」イベントハンドラにおいて行われる処置は、図６に例示している。最初の二つのステップ６０２及び６０３は、図５の第一のステップ５０２に対応する。次に、ステップ６０４において、送信者の言語が受信者の言語と異なるかがチェックされる。異ならない場合、メッセージは、受信者へ送信される。異なる場合、ステップ６０５において、メッセージヘッダが操作されてメッセージのリダイレクトが発生し、ステップ６０６において、送信者及び受信者の言語がメッセージヘッダに追加される。メッセージは、その後、翻訳のために翻訳システム３１へ送信される。

メッセージを送信する前に「メッセージプロパティ」ボタン１０３が使用されない場合、図６において行われるステップは、基本的に、図５に例示されたものとなる。「メッセージプロパティ」ボタン１０３が使用されたと仮定すると、受信者について以前に定義された任意の情報は、現在のメッセージのみについて無効となるか、或いは以前に定義されていない情報がユーザによって追加される。「メッセージ送信」ボタン１０１が使用されると、「メッセージ送信」イベントハンドラは、「メッセージプロパティ」からの情報を使用して、メッセージの送信を行う。

図７は、受信者のシステム、即ち、図２ａの受信システム２１ａのアドインモジュールによってメッセージのリダイレクトが開始される時に実行されるタスクの概要を提供する。ステップ７０１において、メッセージは、受信者の受信トレイから読み出される。その後、ステップ７０２において、メッセージは、中央サイト３１に由来するかを確認するためにチェックされる。メッセージが中央サイトに由来しない場合は、ステップ７０３において、メッセージのテキストに対する自動言語検出を実行して、送信者の言語を確定する必要がある。自動言語検出を実行するために使用される例又は方法は、「二つの言語識別方式の比較、Ｇｒｅｇｏｒｙ Ｇｒｅｆｅｎｓｔｅｔｔｅ、テキストデータの統計分析に関する第三回国際会議、ローマ、１９９５年１２月１１乃至１３日」において説明されている。次に、ステップ７０４において、翻訳が正当かどうかを立証するために、送信者の言語は、受信者の言語と比較される。送信者及び受信者の言語が同じであると仮定すると、メッセージは、ユーザによるアクセスのために受信トレイ内に残される。しかしながら、翻訳が必要である場合には、ステップ７０５において、メッセージヘッダが操作されてリダイレクトが発生し、ステップ７０６において、通信リンクの送信側で利用したものと同様の戦略で、送信者及び受信者の言語がメッセージヘッダに追加される。メッセージは、その後、ステップ７０７において、翻訳のために翻訳システム３１へ送信される。メッセージが翻訳システム３１によって翻訳された後、メッセージは、受信者に戻され、ここで、翻訳システム３１によってメッセージのヘッダに配置された情報が、翻訳メッセージであることを示すために使用され、これにより、自動言語検出を実行する必要性が回避される。この追加情報は、メッセージが受信者の受信トレイに戻される前に除去される。

高品質の機械翻訳は、現在利用可能な言語ペアの数において限定されており、こうした言語ペアは、いくつかの「コア」言語、特に英語及びフランス語を中心としたものであると認識される。こうしたコア言語は、ドイツ語、イタリア語、ポルトガル語、及びスペイン語といった多数の主要な欧州言語に翻訳し得るが、例えば、ドイツからスペイン語、或いはイタリア語からポルトガル語へのサポートは、今のところ利用できない。一部の翻訳エンジンは多数の言語ペアをサポートすると報告されているが、しかしながら、これらは、テーブル索引手法を使用した比較的単純なものであり、結果的に低品質の翻訳が生じると理解される。更に、サポートされるコア言語は、常に英語である。全ての言語を高い品質で他の任意の言語に機械翻訳可能になるまで、提案されるシステムは、限定された数の言語ペアに対処する必要がある。ユーザの言語は、デフォルト言語に加えて、第一及び第二の優先言語に分割される。最初に、ユーザの第一の優先言語を使用して、翻訳の言語ペアを決定し、この特定のペアが現在利用できない場合、第二の優先言語が使用され、その他の場合には、デフォルトが使用される。このようにして、システムは、翻訳の言語ペアの発見を試みる。ユーザの言語をデフォルト言語に加え第一及び第二の優先言語に分割する必要性は、現在利用可能な限られた数の高品質な言語ペアの側面である理解される。この特徴の必要性は、より多くの言語ペアが中央サイトに追加されるにしたがって、経時的に減少するであろう。

メッセージが受信者のマシン上で翻訳システム３１にリダイレクトされる時には、そのメッセージが戻されるまでには、インターネットトラフィックと翻訳システム３１の作業負荷とにより、ある程度の感知可能な時間を要する可能性が高い。対照的に、リダイレクトがユーザのメールボックスをサポートするサーバ上で実行された場合、メッセージの翻訳システム３１へのリダイレクトが発生させる遅延は、ユーザから完全に隠される。

図８は、通信リンクの受信者の側、即ち、図２ｂの受信システム２１ｂで電子メールサーバに常駐するアドインモジュールによってメッセージのリダイレクトが開始される時に実行されるタスクの概要を提供する。図８のステップは、図７で行われたものと非常に似ているため、１００だけ増加させた対応する番号を与えている。

通信リンクの受信者側におけるメッセージのインタセプトが、受信者のシステム（システム２１ａ及び図７）上でのもの、或いはローカル電子メールサーバ（システム２１ｂ及び図８）を使用したものについて、非常に類似していることは明らかである。受信システム上では、電子メールクライアントは、リモートサーバに対して、ユーザのメッセージボックスに保持するメッセージに関する情報の要求を送信する。その後、ＰＯＰ３プロトコル（ＲＦＣ１９３９：ポストオフィスプロトコル−バージョン３参照）又はＨＴＴＰプロトコル（ＲＦＣ２６１６：ハイパーテキスト転送プロトコル−ＨＴＴＰ／１．１参照）を使用して、個別の電子メールをサーバからユーザのマシンにダウンロードし、或いは、ＩＭＡＰ４プロトコル（ＲＦＣ２０６０：インターネットメッセージアクセスプロトコル−バージョン４ｒｅｖ１）を使用して、メッセージのセクション又は完全なメッセージをダウンロードする。繰り返すと、低レベルのメッセージングシステムによって始動されたイベントは、必ずしも完全なメッセージの到着を示さなくてもよい。正確には、イベントは、メッセージの何らかの下位区分が到着したことを示す。したがって、メッセージ又はメッセージの一部がローカル受信トレイに配置されるまで、アドインモジュールは、メッセージイベントに反応できない。対照的に、ローカル電子メールサーバ上において、イベントは、メッセージが到着した旨の通知を、こうした通知の受領の対象となるモジュールに対して行うために、低レベルのメッセージングシステムによって始動される。この「メッセージ受信」イベントは、任意の時点で発生し、完全なメッセージの到着を知らせることができる。アドインは、電子メールサーバの前に「メッセージ受信」イベントをインタセプトし、メッセージが中央サイトでの処理を必要とするかの判断が可能となる。その他の場合には、イベントは電子メールサーバに渡され、電子メールサーバは着信メッセージを処理可能となる。

電子メールメッセージは、アドレス情報を含むヘッダ、及びメッセージテキストを含む後続のボディによって構成される。単純なメッセージでは、電子メールのボディは、メッセージテキストのみで構成でき、他には何もない。例えば添付物を含む更に複雑なメッセージでは、電子メールのボディは、ＭＩＭＥプロトコル（ＲＦＣ１５２１／ＲＦＣ１５２２：多目的インターネットメール拡張参照）を使用して構築される。ＭＩＭＥは、電子メール内で様々な情報項目をカプセル化するために使用され、例えば、プレーンテキスト、書式付きテキスト、グラフィック、及びオーディオ／ビジュアル情報を対象とする。単純なＭＩＭＥメッセージを下に示す。
Ｆｒｏｍ：ｓｅｎｄｅｒｎａｍｅ＠ｃｏｍｐａｎｙ．ｃｏｍ
Ｓｅｎｔ：１ Ｏｃｔｏｂｅｒ ２００２ １７：３５
Ｔｏ：ｒｅｃｅｉｖｅｒｎａｍｅ＠ｃｏｍｐａｎｙ．ｃｏｍ
Ｓｕｂｊｅｃｔ：マルチパートＭＩＭＥメッセージの例
ＭＩＭＥ−Ｖｅｒｓｉｏｎ：１．０
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｍｕｌｔｉｐａｒｔ／ｍｉｘｅｄ；
ｂｏｕｎｄａｒｙ＝ｕｎｉｑｕｅ−ｂｏｕｎｄａｒｙ−１
これはマルチパートＭＩＭＥメッセージの序文エリアである。
マルチパートフォーマットを理解するメールリーダはこの序文を無視するべきである。
−−ｕｎｉｑｕｅ−ｂｏｕｎｄａｒｙ−１
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｔｅｘｔ／ｐｌａｉｎ
これは電子メールメッセージテキストである
−−ｕｎｉｑｕｅ−ｂｏｕｎｄａｒｙ−１
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｔｅｘｔ／ｐｌａｉｎ；
Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ：ａｔｔａｃｈｍｅｎｔ
ｆｉｌｅｎａｍｅ−”ｔｅｓｔ．ｔｘｔ”
これは添付テキストである
――ｕｎｉｑｕｅ−ｂｏｕｎｄａｒｙ−１

ＭＩＭＥプロトコルは、情報をボディ部とサブボディ部とに区分する。特定の境界マーカを使用して、各部分をブロックし、ボディ部の先頭の情報は、そのコンテンツの性質を示す。上の例は、単一の行のテキストと、添付物とを含む電子メールメッセージを示している。中央サイトは、下で説明するように、各ボディ部が認識され、一部のボディ部のみで翻訳が行われるように、ＭＩＭＥフォーマットの電子メールメッセージを処理する必要がある。更に、ＭＩＭＥサブボディ部は、本文書において後で説明するように、電子メールメッセージの返信及び転送を処理する複雑性を扱うために使用される。この本発明の実施形態では、ＭＩＭＥプロトコルがオリジナルテキストと翻訳バージョンの両方をパッケージする特徴及び機能を使用するが、本発明は、このプロトコルに限定されない。アプリケーション定義可能な記述子と共にメッセージの構造化格納をサポートする任意のプロトコルは、未翻訳及び翻訳済みのメッセージコンポーネントをカプセル化するために、本発明で使用できる可能性がある。

図９は、翻訳システム３１によって実行されるタスクを例示する。ステップ９０１においてメッセージを受信し、ステップ９０２においてメッセージ内の構成情報にアクセスすると、翻訳システム３１は、ステップ９０３において、ＭＩＭＥボディ部の最初のものをスキャンし、翻訳が必要かを特定する。メッセージのコンテンツの詳細については、下で更に詳細に説明する。メッセージヘッダから抽出された情報は、専用のＭＩＭＥボディ部に配置された翻訳パラメータと共に、翻訳プロセスの制御に使用される。翻訳が必要な各ＭＩＭＥボディ部は、ステップ９０４において、メッセージから抽出され、翻訳サーバ９０９に提供され、その後、翻訳され、ステップ９０５において、メッセージに戻される。ステップ９０６において、翻訳を必要とするＭＩＭＥボディ部が他にあるかを判断するためにチェックが行われ、その後、ステップ９０３乃至９０５とステップ９０９とが反復される。翻訳メッセージが完全に構築され、ステップ９０６においてメッセージの終了が検出されると、ステップ９０７において、メッセージヘッダ内の情報が変更され、翻訳システム３１へのリダイレクトに関する情報が除去され、ステップ９０８では、翻訳システムでの使用のためにアドインモジュールがヘッダに配置した追加フィールドも除去される。その後、メッセージは、受信者へ転送される。

明確にするため、図９では、メッセージが多数のＭＩＭＥボディ部を含む時、下で説明するように、最初のいくつかのボディ部のみが翻訳を必要とし、残りの部分は返信又は転送中に既に処理されている可能性があることを省いて図示している。更に、翻訳システム３１が翻訳プロセスを制御するために使用する、アドインモジュールによってメッセージに添付された情報は、その後、翻訳メッセージが受信者に転送される前に廃棄できる。こうした項目も、下で説明されており、翻訳プロセスを「最適化」する役割のみを有し、翻訳システム３１によるメッセージの処理中に行われる基本的なタスクを損なわない。

本発明の別の態様において、システムは、暗号化メッセージ、及び安全なネットワークを介して送給されるメッセージ、或いは両者の組み合わせを対象とする安全なメッセージングを処理するために拡張可能である。インターネットを介してメッセージを送信するために使用されるＲＦＣ８２１／８２２及びＲＦＣ１５２１／１５２２プロトコルは、安全な送給システムを提供せず、メッセージは、意図した受信者又は複数の受信者以外の人物が傍受及び閲覧可能である。この弱点は、公開鍵基盤（ＰＫＩ）及び仮想プライベートネットワーク（ＶＰＮ）技術の使用により対処できる。一方又は両方の技術を使用して、インターネットを介したメッセージ送給の安全を確保できる。

安全な通信のサポートは、デジタル証明書（ＲＦＣ２４５９：インターネットＸ．５０９公開鍵基盤、証明書、及びＣＲＬプロフィール参照）の使用と共に、セキュア／多目的インターネットメール拡張又はＳ／ＭＩＭＥプロトコル（ＲＦＣ２６３２：Ｓ／ＭＩＭＥバージョン３証明書の処理、ＲＦＣ２６３３：Ｓ／ＭＩＭＥバージョン３メッセージ仕様、及びＲＦＣ２６３４：Ｓ／ＭＩＭＥ用のセキュリティ強化参照）を使用したメッセージの作成を介して提供できる。暗号化通信の使用を希望するユーザは、自分の意思を中央サイトに登録する必要があり、その後、デジタル証明書を信頼できる認証局から入手する。公開鍵は、ユーザに送信され、秘密鍵は、中央サイトの安全な領域に保管される。ユーザは、自分のデジタル証明書の公開鍵を使用してメッセージを暗号化し、その後、中央サイトに保持される秘密鍵のみが、そのメッセージを復号化する。暗号化メッセージは、Ｓ／ＭＩＭＥフォーマットで中央サイトの待ち行列に入れられ、翻訳サーバに提供する前にメッセージを復号化するプログラムは、独自の安全な環境内で実行され、そのアクセス権は非常に僅かな個人に限定される。結果として、サイトをサポートするための管理者特権を有する可能性が高い中央サイトの保守担当者でさえ、安全なメッセージに全くアクセスできない。

メッセージは、翻訳された後、受信者へ送信する前に暗号化する必要がある。送信者の秘密鍵を使用すると、公開鍵を有する人は（受信者を含め）誰でもメッセージを復号可能となり、結果として安全でないメッセージが送信されるため、これは選択されない。受信者は、安全な通信に参加する場合には、中央サイトが公開鍵を使用してメッセージを暗号化し、その後、そのメッセージを受信者のみが復号可能となるように、自分だけのデジタル証明書を保有する必要がある。明らかに、受信者がデジタル証明書を保有していないため中央サイトが受信者の公開鍵を取得できない場合には、中央サイトは、暗号化メッセージを処理できない。こうした状況下では、中央サイトは、送信者に対して、安全なメッセージを処理することができない理由を示すメッセージを送給する必要がある。

安全な通信を開始する前に、送信者は、受信者がデジタル証明書へのアクセスを有しており、何らかの段階の公開鍵が中央サイトに保管されている状態を確保するために、プレーンテキストメッセージを使用して受信者に連絡できる。その後、二者間の安全な通信を開始できる。企業環境では、デジタル証明書は、企業、或いは組織内の特定のサイトに属してよい。代替として、コストが抑制要因となる可能性が低いため、個人が自分のデジタル証明書を取得するのを妨げるものは殆ど存在しない。更に重要なことに、この問題は、デジタル証明書技術でよく知られているものの一つであり、どの組織を通じてデジタル証明書を取得可能かが重要な要素となる。送信者の代わりにデジタル証明書を取得するために、中央サイトは信頼できる認証局との関係を確立する必要があることから、中央サイトは、受信者がデジタル証明書を取得するルートになることが可能であり、或いは、こうしたアイテムを取得可能な場所の情報を備えている。受信者がどのような経路でデジタル証明書へのアクセスを得るとしても、中央サイトが受信者の公開鍵へのアクセスを有する限り、安全な通信が可能となる。

ＰＫＩ技術を使用した安全な通信が、デジタル証明書を有する受信者に依存する点は留意する価値がある。中央サイトが通信経路内のルートであるという事実によって、この技術の基本的な要件は変更されない。

安全な通信の別のアプローチは、仮想プライベートネットワーク（ＶＰＮ）の使用によるものである。ＶＰＮの概念において実施される基本原則は、安全なプライベートネットワークを確立する多額の費用を発生させるのではなく、インターネット等のパブリックネットワークを介して送信される前に、メッセージを自動的に暗号化することである。ＶＰＮは、二つのノード間で安全なポイントツーポイントリンクを確立することに依存する。この安全なリンクは、「トンネル」として知られており、トンネルの一方の側で提供されたプレーンテキストメッセージがトンネルを通って送信される前に自動的に暗号化され、その後、受信側で受信者に提供される前にメッセージが復号化される際に通過するルートである。暗号化及び復号化を提供するノードは、組織の内部ネットワークを外部の世界から隔離するファイアウォール内に含めてよい。ポイントツーポイント通信リンクが確立されているため、ＶＰＮノードは、連絡しようとするＩＰアドレスと、連絡を受けるＩＰアドレスとを定義するように設定する必要がある。

中央サイトは、選択された顧客に対してＶＰＮ機能を提供可能であり、これにより、既存のＶＰＮノードは、通信を中央サイトへリダイレクトし、中央サイトに由来する通信を受け取ることができるように構成される。こうした条件下において、中央サイトは、顧客のＶＰＮの一部となり、これにより、その顧客からのメッセージを処理できる。

ＶＰＮ接続を実施するには、通信トラフィックが適切にルート指定されるように、ＶＰＮを構成するノードのＩＰアドレス（即ち、送信者から中央サイト及び中央サイトから受信者）の知識が必要となる。ＶＰＮは二つのノード間でポイントツーポイントリンクを確立するため、インターネットのグローバルドメインネームシステム（ＤＮＳ）は、テキストアドレスをＩＰアドレスへ変換するのに使用不可能であり、これは中央サイト上でローカルに実行する必要がある。したがって、中央サイトは、ＶＰＮ顧客用の独自のＤＮＳ機能をサポートする。ＶＰＮ環境が顧客用に中央サイトで設定される時、顧客の通信ネットワークの一部を形成する各ＶＰＮノードのＩＰアドレスは、中央サイトのＤＮＳ環境に登録される。これが行われた後、ＲＦＣ８２２メッセージヘッダフィールドは、リダイレクトメカニズムの一部として操作され、ＴＣＰ／ＩＰ通信層によって適切なＩＰアドレスに翻訳可能となり、したがって、正しいＶＰＮリンク上で、受信者に対してルート指定できる。

上記の実施形態は、コンピュータ業界で現在使用されている二種類の主要な技術を使用した安全な通信を本発明がどのように処理できるかを示しているが、その他の適切な技術も使用できると理解されるであろう。

本発明の実施の例として、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ^TMとの統合について、次に説明する。Ｏｕｔｌｏｏｋを選択したのは、コンピュータ業界での広範な使用のためであり、しかしながら、本発明は、この特定の電子メールプログラム、或いは、このアプリケーションが動作するＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ^TMオペレーティングシステムに限定されない。本発明は、Ｎｅｔｓｃａｐｅ^TM、Ｅｕｄｏｒａ^TM、及びＬｏｔｕｓ Ｎｏｔｅｓ^TMのような他の電子メールプログラムと、Ｕｎｉｘ^TM及びＬｉｎｕｘのような他のオペレーティングシステムとに、等しく応用可能である。

ユーザのシステム上での翻訳システムの実施は、既に上で説明したようにアドインモジュールの形態をとる。インストール後、ユーザは、ユーザとは言語が異なる人物の連絡リストエントリを更新するように促される。受信者の言語を連絡先リストに追加することで、アドインモジュールは、ユーザに何らかの介入を求めることなく、電子メールを翻訳のために翻訳システム３１へリダイレクトする必要があるかを自動的に判断可能になる。ユーザは、通常通り、送信ボタンを押すだけでよい。

受信者の言語が連絡先リストにおいて定義されていない状況では、二つの選択肢が可能となる。
１）送信ボタン１０１を押すことで、電子メールは、翻訳なしで受信者へ直接送信される。
２）受信者の言語及び翻訳のためにどの辞書を使用するべきかといった項目を含む様々な情報項目をユーザに求めるポップアップダイアログが現れる。必要な情報が入力された場合のみ、電子メールメッセージを翻訳のために翻訳システム３１にルート指定し、その後、受信者へ転送できる。

アドインモジュールは既存の挙動を変更せずに、追加的な特徴及び機能を提供することが好ましいため、既存の「電子メール送信」ボタンによって呼び出される場合、上記の動作方針は、互いに対立すると思われる。

しかしながら、ポップアップダイアログに現れる情報がメッセージのプロパティとして認識される場合、翻訳システム３１へのメッセージのリダイレクト及びその後の翻訳を制御するのに必要な情報を閲覧及び更新するための要件と、メッセージを実際に送信する動作との間での区別が可能となる。そのため、ツールバー１８は、「メッセージプロパティ」ボタンを、他の任意のボタン（例えば、オプション及びコンフィグレーションボタン）に加えて含む必要がある。以下に、「メッセージプロパティ」ボタン１０３と既存のメッセージ送信ボタン１０１との両方に関連する目的及び動作を示す。
１）「メッセージプロパティ」ボタン１０３
ポップアップダイアログが表示され、ここで、既に存在する情報を修正し（即ち、グローバルコンフィギュレーション情報）、その他の指定されていない情報を追加できる（即ち、連絡先リストに存在しない場合の受信者の言語）。ダイアログ底部のＣＡＮＣＥＬボタンを押すことで、加えた全ての修正が廃棄され、一方、ＯＫボタンの選択は、任意の変更の承認を示し、メッセージプロパティは相応に更新される。
２）送信ボタン１０１
このボタンの目的は、受信者への送給のために電子メールがインターネットへ送信されるという点では、アドインモジュール１４の存在によって変化しない。しかしながら、リダイレクト又は翻訳プロセスに関連する追加情報が存在する場合、アドインモジュール１４は、この情報に従って相応に作用する。代替として、どのような理由であっても、こうした情報が存在しない場合には、電子メールメッセージは、インターネットへ純粋に送信される。

「メッセージプロパティ」及び「メッセージ送信」ボタンの両方に関連する挙動及び動作を例示するために、以下のシナリオを検討できる。
１）連絡先リストにおいて現在定義されていない受信者にメッセージを送信する。送信ボタンを押すことで、そのメッセージは、修正なしで受信者へ送信される。しかしながら、「メッセージプロパティ」ボタンが最初に選択された場合、ユーザには、受信者の言語と、翻訳辞書と、他の任意の関連情報とを指定する機会が与えられる。その後、送信ボタンを押すことで、送信者と受信者との言語が異なる場合には、メッセージが翻訳システム３１へリダイレクトされ得る。
２）受信者が既に連絡先リストに定義されているが、言語が指定されていない場合、送信ボタンを押すことで、そのメッセージは、修正なしで受信者へ送信される。しかしながら、「メッセージプロパティ」ボタンが最初に選択され、ポップアップダイアログ上で受信者の言語が定義された場合、送信ボタンを押すことで、送信者と受信者との言語が異なる場合には、メッセージのリダイレクトが発生し得る。
３）受信者が、その言語と共に、既に連絡先リスト１０ａに定義されている。送信ボタンを押すことで、送信者と受信者との言語が異なる場合には、メッセージのリダイレクトが発生し得る。更に、メッセージを送信する前に、「メッセージプロパティ」ボタンが最初に選択された場合、連絡先リスト１０ａから取り出した受信者の言語は、他の任意の関連情報と共に（このメッセージに対してのみ）変更できる。その後、送信ボタンにより、メッセージは、インターネットへ送出される。

メッセージの中央サイトへのリダイレクトを制御するのに必要であり、更に翻訳プロセスを指示するのに必要となる情報を、メッセージのプロパティとして処理することは、この情報を閲覧及び更新するタスクから、メッセージを送信する動作が完全に分離されることを意味する。更に、こうした「メッセージプロパティ」は追加的情報であるため、既存の電子メールクライアントの挙動は、変更されない。最後に、何よりも重要な態様は、既に存在するメッセージ送信ボタンがメッセージをインターネットへ送信する動作を果たす唯一のものとなることである。

「メッセージプロパティ」ポップアップダイアログは、全受信者及び関連する言語（連絡先リストで既に指定されたものがある場合）のリストを翻訳オプションと共に表示する必要がある。提示する情報の量は、恐らくは二つ以上のダイアログを必要とし、例えば、最も一般的に変更される項目は最初のダイアログに現れ、修正の頻度が最も少ない項目は補助ダイアログに現れる。この情報の一部は、メッセージ全体に関連し、他の項目は、メッセージの個別のコンポーネントのみに影響する。

ポップアップダイアログの目的は、「メッセージプロパティ」情報を閲覧し、必要な任意の変更を行うことである。提示される情報は現在のメッセージのみに関係するため、連絡先リストから取得した受信者の言語等の既に存在する情報に対してポップアップダイアログ上で行った任意の変更によって、その既存のデータは変更されずに残される必要がある。したがって、ポップアップダイアログは、既に存在する情報を無効にする機会、或いは現在のメッセージのみに対して新しい情報を供給する機会を提供する。

システムは、Ｔｏ：リストにおいて特定される、主要受信者である第一のグループと、Ｃｃ：リストにおいて特定される、主要受信者ではないが通信のコピーを受信し、お互いと主要受信者とに確認される受信者の第二のグループと、Ｂｃｃ：リストにおいて特定される、通信のコピーを受信するが他の受信者に確認されない受信者の第三のグループとに通信を送るように構成される。電子メールが二人以上の人物（複数のＴｏ：、Ｃｃ：、及びＢｃｃ：エントリ）に送信される状況において、複数のＴｏ：リスト、Ｃｃ：リスト内の全受信者を対象とする単一のＳＭＴＰメッセージを作成し、Ｂｃｃ：リスト内の各受信者に対する個別のメッセージを作成できる。しかしながら、この仕組みに基づいて、メッセージを翻訳システム３１へリルートすることで、受信者の一部は同じ言語を有する可能性があるため、翻訳システム３１では重複する翻訳作業が発生する可能性が高い。したがって、アドインは、単一のメッセージを翻訳システム３１へ送信し、翻訳システム３１では単一の言語ペアでの翻訳が一度のみ実行され、その後でのみ、複数のＴｏ：、Ｃｃ：、及びＢｃｃ：受信者の処理を開始できる。「ユーザ定義」フィールド（Ｘ−ＲＥＣＩＰＩＥＮＴ−ＬＡＮＧＵＡＧＥ）を使用することで、アドインモジュールは、受信者リストに出現するのと同じ順序で、各受信者の言語を電子メールヘッダに配置する。したがって、Ｔｏ：、Ｃｃ：、及びＢｃｃ：フィールドに複数のエントリがあり、メッセージがスペイン語、ドイツ語、スペイン語、及びフランス語を話す人に送信される場合、「受信者言語」リストは、次のようになる。
ｘ−ｒｅｃｉｐｉｅｎｔ−ｌａｎｇｕａｇｅ：ｅｓ，ｄｅ，ｅｓ，ｆｒ

翻訳システム３１は、翻訳プロセスを最適化するために上の「受信者言語」リストをソート可能であり、その後、対応する個人に翻訳済みメッセージを発送するためにオリジナルのリストを複数の受信者に一致させる。

電子メールボディの翻訳バージョンは、オリジナルの電子メールの先頭に、二つのバージョンを分離するデリミタと共に追加される。受信者に送信される二つの電子メールボディにおいて、翻訳バージョンはより重要であるため、これを最初に配置することが基本となる。添付物については、添付物を翻訳するかどうかは送信者の裁量となるが、しかしながら、翻訳が指示された場合、翻訳バージョンは、メッセージ内でオリジナルの前に現れる。

中央サイトにおいて、メッセージは、処理のために構成要素に分割され、ここから、受信者又は複数の受信者への送給のために、修正された要素が新しいメッセージへと再構築される。複数の受信者が関与する時、Ｔｏ：及びＣｃ：フィールドにおいて遭遇した全受信者には、単一のメッセージを発送することで対処できる（Ｂｃｃ：フィールド内のエントリは全て除去される）。しかしながら、Ｂｃｃ：フィールドにリストアップされたものについては、そのリスト内の受信者毎に別個のメッセージを作成する必要があり、毎回Ｂｃｃ：フィールド内の一人のみの受信者が出力メッセージに現れる状態となる。全受信者が処理された後、翻訳されたメッセージコンポーネントは廃棄できる。

通信リンクの受信者側でのメッセージのリダイレクトの実施は、受信者のメールボックスをサポートするサーバ又はクライアントシステム上で開始できるが、両方の位置では開始できない。電子メールクライアントを使用して自分のメールボックスにアクセスするまで、ユーザはサーバにおける何らかのメッセージの到着を認識しないため、受信者のメールボックスに配置される前に、リダイレクトのためにサーバにおいてメッセージをインタセプトする方が侵入性は低い。対照的に、クライアントシステムでメッセージをインタセプトすることで、一つ以上のメッセージが翻訳システムにリダイレクトされる可能性があり、この結果として、サーバからのダウンロード動作の開始時に報告されたものより少ない数のメッセージが、ユーザのローカル受信トレイに現れる。この差は、以下のセクションで説明するように、結果的な実施の性質を決定づける。

ＩＳＰのサーバを使用してメッセージング機能を提供するインターネットサービスプロバイダ（ＩＳＰ）にリモートリンクを介して接続するユーザの場合、リダイレクトのためのメッセージのインタセプトは、ユーザシステム（クライアントシステム）上で、感知可能な形でのみ実行できる。この場合、メッセージは、ＰＯＰ３、ＩＭＡＰ４、又はＨＴＴＰプロトコルを使用してＩＳＰから要求され、これは、ＩＳＰのサーバがプロトコルコマンドに応答する結果として、メッセージ受信イベントに応答することを意味する。メッセージングサブシステムが着信ＳＭＴＰトラフィックのあらゆる態様を処理し、未請求メッセージの受信に応答してイベントをトリガするサーバとは異なり、Ｏｕｔｌｏｏｋは、ソケットを介したＩＳＰサーバとの直接的な通信によってＰＯＰ３／ＩＭＡＰ４／ＨＴＴＰプロトコルを実施し、メッセージングサブシステム（ＭＡＰＩ^TM）は、受信したメッセージのストレージ管理を提供するためのみに使用される。結果として、アドインモジュールは、以下の三種類の位置で着信メッセージに応答し得る。
１）ソケットインタフェース
このインタフェースで着信メッセージのインタセプトを試みることには、二つの問題があり、第一は、情報がＯｕｔｌｏｏｋに渡される前にアドインが動作を開始できるようにソケットを介して着信するトラフィックをインタセプトする能力であり、第二は、ＩＳＰサーバから戻されたメッセージと比較してデータを認識するために、アドインがＰＯＰ３、ＩＭＡＰ４、及びＨＴＴＰプロトコルに熟知しなければならないことである。
２）ＭＡＰＩイベント
ＭＡＰＩサブシステムは、メッセージの受信と、メッセージの待ち行列作成と、構造化された形でのストレージ（即ち、メッセージ受信トレイ）とを処理する。アドインモジュールは、メッセージが受信された時、及びストレージに配置された時に通知を受領するようにＭＡＰＩに登録できる。
３）Ｏｕｔｌｏｏｋイベント
一つ以上のメッセージがシステムによって受信された時、Ｏｕｔｌｏｏｋは、ＮｅｗＭａｉｌイベントをトリガし、その後、アドインは、受信トレイで新たに受信したメッセージを調べ、適切な動作を実行できる。

アドインが介入し、これにより着信メッセージに応答し得る三つの可能な場所のうち、ソケットインタフェースにおいて着信メッセージをインタセプトする複雑性は実施可能ではあるが、既に説明したように、問題の発生は、これが本発明の好適な実施形態ではないことを意味する。ＯｕｔｌｏｏｋのＮｅｗＭａｉｌイベントは、全てのメッセージが受信された後でのみトリガされる。結果として、アドインモジュールは、個別のメッセージを処理のためにインタセプトできない。正確には、受信されたメッセージを全て開く必要がある。この理由から、ＯｕｔｌｏｏｋのＮｅｗＭａｉｌイベントを使用した着信メッセージのインタセプトは、実施可能であるが、同じく本発明の好適な実施形態ではない。本発明の上の二つの実施形態とは対照的に、ＭＡＰＩイベントは、設定が簡単であり、受信された各メッセージについて、イベントがトリガされる。更に、考慮に入れる必要がある別の側面は、メッセージを翻訳のために中央サイトへリダイレクトするために、アドインがインターネットとのアクティブな通信リンクを有する必要があることである。ＡＤＳＬ又は専用回線のような永続的な「常時」インターネット接続を有するユーザについては、インターネットとの接続が常にアクティブであるため、これは問題にならない。しかしながら、インターネットとのダイヤルアップリンクを有するユーザでは、翻訳を必要とするメッセージをアドインが全て処理するまで、リンクをアクティブに維持する必要がある。アドインがタスクを完了する前にリンクを終了させ得る可能性は、全て回避する必要がある。この理由から、アドインがタスクを完了させる等の時点まで、ダイヤルアップリンクを切断する任意の試みを一時停止できるように、ＷＩＮ３２^TM関数ＲｅｓＣｕｓｔｏｍＨａｎｇＵｐ（）又は等価物を実施する必要がある。上記の全ての理由から、ＭＡＰＩフォルダイベントの使用は、本発明の好適な実施形態となる。

ＰＯＰ３及びＨＴＴＰプロトコルにおいて、クライアントシステムは、現在保持しているメッセージの数をＩＳＰサーバに問い合わせ可能であり、その後、クライアントシステムは、各メッセージをローカル受信トレイにダウンロードする。Ｏｕｔｌｏｏｋは、ステータスバー上で、ダウンロード動作の開始前に、ＩＳＰサーバが保持しているメッセージの数を表示し、順序内のどのメッセージが現在ダウンロードされているかを示す。したがって、こうしたメッセージの一つがアドインモジュールによるリダイレクトの対象となった場合、ユーザは、全てのメッセージが送給された訳ではないことに気が付く可能性がある。この問題を克服するために、アドインモジュールは、リダイレクトされたメッセージの代用を提供し、見かけ上の紛失の利用を知らせ、更に、恐らくはＯｕｔｌｏｏｋがＩＳＰサーバのメッセージボックスを次に調べた時に、翻訳バージョンが利用可能となることを知らせる必要がある。

ＩＭＡＰ４プロトコルは、ＰＯＰ３及びＨＴＴＰに比較して遙かに柔軟であり、メッセージの指定セクション、完全なメッセージ、或いはテキストの開始位置及び長さを前提とする何らかの恣意的な部分をダウンロードする機能と、サーバから除去することなくメッセージを覗き見る能力とを提供する。こうした機能の一部を使用することで、Ｏｕｔｌｏｏｋは、メッセージのヘッダを覗き見て、受信トレイに表示を配置してメッセージの存在を強調するが、メッセージを完全な状態でサーバに残す。ユーザは、ショート形式のメッセージを閲覧し、完全な状態でサーバに残しておき、メッセージを開封することでダウンロードを選択することが可能であり、或いは開封又はダウンロードせずに、ＩＳＰサーバに常駐するメッセージボックスからメッセージを削除することを選択できる。したがって、ユーザが完全なメッセージをダウンロードする時のみ、アドインモジュールは、そのメッセージをインタセプトし、その後、メッセージは翻訳のために中央サイトへリダイレクトしてよい。

ＯｕｔｌｏｏｋはＩＭＡＰ４プロトコルを使用してＩＳＰからの情報にアクセスする時、ユーザのシステムに表示されるのは、通常、メッセージヘッダのみである。ユーザがメッセージのダウンロードを選択し、メッセージが翻訳を必要とする場合、メッセージは、ＰＯＰ３／ＨＴＴＰ電子メールサーバと全く同じ形で、翻訳のために翻訳システムへ自動的にリダイレクトされる。その後の何らかの不確定な時点において、翻訳済みメッセージは、ＩＳＰサーバのメッセージボックスに送給される。

Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ^TM等のメッセージング機能を提供する独自のサーバを有するユーザについては、異なるアプローチを使用できる。通信リンクの受信者側でメッセージを処理する最も侵入性の低いアプローチは、ローカル電子メールサーバに到達し、受信者の受信トレイに配置される前に、メッセージをインタセプトすることである。これは、サーバ上で動作するオペレーティングシステムの基礎的なメッセージトランスポート環境の低レベルイベントメカニズムにつなぐことで達成できる。これは、コンピュータプログラミングの業者により容易に実施できる。これには、メッセージが汚染されていないことを証明するために、電子メールサーバが着信メッセージの通知を受ける前に、アドインモジュールによってウイルスチェッカが最初に呼び出されるような、権利レベル及びフィルタ仕様の設定が必要となる。

独自のメッセージングサーバを有するユーザと、ＩＳＰのメッセージングサーバとのリモート接続を使用するユーザとの両方において、着信メッセージの受信時には、電子メールのコンテンツ及び任意の添付物に対して自動言語検出が実行される必要があり、その後、所定の「送信先」言語と異なっている場合には、メッセージは、翻訳システム３１へのリダイレクトを必要とする。翻訳システム３１がメッセージを処理した後、メッセージは返送され、その後、翻訳システム３１がヘッダに追加した情報を使用して起源を迅速に特定し、これにより、リダイレクトが必要かどうかを判断するために着信メッセージに対して通常行われる処理を省く。翻訳システム固有であるヘッダ内の情報は除去され、電子メールが電子メールサーバに渡され、ここから、メッセージは、他のものと同様に処理され、受信者の受信トレイに配置される。

次に、返信及び転送が可能となるようにメッセージを構築する方法の詳細について説明する。最初に、二人のユーザが互いの電子メールメッセージに返信することで、メールのやり取りを行う状況について考える。通常、返信はメッセージの最初に配置され、オリジナルテキストが後に続き、結果的なメッセージは、オリジナルの送信者に戻される。このプロセスは、何度も繰り返すことが可能であり、新たな返信がメッセージの最初に配置されるにつれ、メッセージは、長さが増す。この通信の両方の参加者が同じ言語を話す時、これは簡単だが、異なる言語を話す時には、問題が発生する。

英語を話す人がドイツ語を話す人にメッセージを送信すると仮定すると、英語のソーステキストは、受信者に転送される前に、ドイツ語に翻訳される。ドイツ語を話す人がこのメッセージに返信することを選択した場合、ドイツ語のテキストは英語に翻訳されるが、既に一度（英語からドイツ語に）翻訳されたオリジナルメッセージも、別の翻訳を受け、ドイツ語から英語に再び変換される可能性がある。結果として生じる既に翻訳済みのテキストの翻訳は、現在の機械翻訳言語エンジンの限定された精度のため、オリジナルテキストとは同じにならず、理解可能性が大きく失われ得る。以前の全ての翻訳システムが利用したアプローチでは、多重翻訳を回避するための対策が講じられていなかった。この問題の解決策は、ドイツ人が返信する時に、オリジナルの英語テキストを返送して、既に翻訳されたテキストがその後再び翻訳されない状態を確保できるように、翻訳バージョンと共にオリジナルテキストを常に含めることである。同様に、英語を話す人がドイツ人に返信する時には、プロセスが反復される。したがって、メッセージは、下に示すように、英語及びドイツ語の両方のコンポーネントの連続を含む。
Ｅ１ → ＧＴ１，Ｅ１
ＥＴ２，Ｇ２｜ＧＴ１，Ｅ１ ← Ｇ２｜ＧＴ１，Ｅ１
Ｅ３｜ＥＴ２，Ｇ２｜ＧＴ１，Ｅ１ → ＧＴ３、Ｅ３｜ＥＴ２，Ｇ２｜ＧＴ１，Ｅ１
ここで：
Ｅ１ オリジナル英語テキスト
ＧＴ１ オリジナル英語テキスト（Ｅ１）の翻訳ドイツ語バージョン
Ｇ２ オリジナル英語テキストへの返信
ＥＴ２ ドイツ語の返信（Ｇ２）の翻訳英語バージョン
Ｅ３ メッセージに対する英語の返信
ＧＴ３ 英語の返信（Ｅ３）の翻訳ドイツ語バージョン

英語を話す人とドイツ語を話す人との間での通信の各段階では、受信者にとって直接的な関心の対象となるメッセージ部分であることから、オリジナルメッセージの翻訳バージョンが、常に最初に現れる。しかしながら、英語を話す人は、このメッセージの英語コンポーネントのみを見ることを好む可能性が高く、同様に、ドイツ語を話す人は、このメッセージのドイツ語コンポーネントのみを見ることを好む可能性が高い。結果として、アドインモジュールでは、一方又は他方の言語に適合するこのメッセージのこれらのコンポーネントをフィルタにより取り出す必要が生じ得る。しかしながら、こうしたメッセージを常にフィルタリングすることは、特にバイリンガルの人にとっては、非常に制限のあるものとなる可能性があり、したがって、フィルタリングプロセスのスイッチを切る能力が存在するべきである。ツールバーのボタン１０９は、フィルタリングプロセスに対する迅速なオン／オフ制御を提供するために使用される。

返信プロセスの各段階では、メッセージの最初の部分のみを中央サイトで翻訳する必要があり、これは残りの部分が翻訳テキストとオリジナルテキストとのペアで構成されるためである。ＭＩＭＥメッセージの各コンポーネント部分は、オリジナルテキスト又は翻訳テキストとしてマークできる。ＣＯＮＴＥＮＴ−ＬＡＮＧＵＡＧＥフィールド（ＲＦＣ１７６６参照）と、メッセージの各部分に対するＩＳＯ６３９言語コードを使用することで、メッセージは、このようにマーク可能となり、したがって、次のようになる。
ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ
ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ，ｄｅ

第一の例は、付随するＭＩＭＥボディが「英語のオリジナルテキスト」であることを示し、第二のものは、「英語からドイツ語に翻訳されたテキスト」を示す。したがって、ＣＯＮＴＥＮＴ−ＬＡＮＧＵＡＧＥが単一の言語識別子を含む時は常に、オリジナルテキストが意味され、二つの識別子を含む時は、翻訳されたテキストとなる。したがって、テキストの断片が翻訳されると、このように明確に識別され、中央サイトは、結果的な理解度の低下の可能性がある別の翻訳処理を行わない。

英語を話す人とドイツ語を話す人との間での上の通信の例を使用すると、ＭＩＭＥボディは、以下の情報を含む。
Ｅ１ ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ
ＧＴ１，Ｅ１ ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ，ｄｅ
ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ
Ｇ２｜ＧＴ１，Ｅ１ ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｄｅ
ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ，ｄｅ
ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ
ＥＴ２，Ｇ２｜ＧＴ１，Ｅ１ ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｄｅ，ｅｎ
ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｄｅ
ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ，ｄｅ
ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ

この情報は、ＭＩＭＥメッセージを構築する一環として、アドインモジュール及び中央サイトの両方によって容易に生成可能であり、表示に適した部分を特定するためにフィルタメカニズムによって使用される。更に、既に翻訳されたテキストが再翻訳されない状態を確保するために、中央サイトによって使用される。

論理的にグループ化されたテキストのブロック（ＥＴ２，Ｇ２｜ＧＴ１，Ｅ１）で構成されたＭＩＭＥメッセージを処理することは、この処理を支援するために各「メッセージコンポーネント」（即ち、ＥＴ２，Ｇ２及びＧＴ１，Ｅ１）をメッセージ内で何らかの形で区分できる場合、大幅に簡略化される。幸いにも、ＭＩＭＥ仕様は、データフォーマットの異なる同じテキストのいくつかの表現を単一の論理ユニットにおいてカプセル化するメカニズムを提供する（ＲＦＣ１５２１、７．２．３、マルチパート／代替参照）。
メッセージ（ｃｏｎｔｅｎｔ−ｔｙｐｅ：マルチパート／混合）
ボディパート１（ｃｏｎｔｅｎｔ−ｔｙｐｅ：マルチパート／代替）
ボディパート１．１（ｃｏｎｔｅｎｔ−ｔｙｐｅ：テキスト／プレーン）
ボディパート１．２（ｃｏｎｔｅｎｔ−ｔｙｐｅ：テキスト／ｈｔｍｌ）
ボディパート２（ｃｏｎｔｅｎｔ−ｔｙｐｅ：マルチパート／代替）
ボディパート２．１（ｃｏｎｔｅｎｔ−ｔｙｐｅ：テキスト／プレーン）
ボディパート２．２（ｃｏｎｔｅｎｔ−ｔｙｐｅ：テキスト／ｈｔｍｌ）

ＭＩＭＥ仕様では、データフォーマットの異なる同じメッセージのカプセル化を記録するが、この特徴をテキストの断片の未翻訳バージョンから翻訳バージョンを識別するために拡張できない理由は存在しないと思われる。ＲＦＣ１７６６において定義されるような「ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ」を使用することで、ＭＩＭＥメッセージは、次のように、同じメッセージの多言語バージョンを保持するように構築できる。
メッセージ（ｃｏｎｔｅｎｔ−ｔｙｐｅ：マルチパート／混合）
ボディパート１（ｃｏｎｔｅｎｔ−ｔｙｐｅ：マルチパート／代替）
ボディパート１．１（ｃｏｎｔｅｎｔ−ｔｙｐｅ：テキスト／プレーン）（ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｄｅ，ｅｎ）
ボディパート１．２（ｃｏｎｔｅｎｔ−ｔｙｐｅ：テキスト／ｈｔｍｌ）（ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｄｅ）
ボディパート２（ｃｏｎｔｅｎｔ−ｔｙｐｅ：マルチパート／代替）
ボディパート２．１（ｃｏｎｔｅｎｔ−ｔｙｐｅ：テキスト／プレーン）（ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ，ｄｅ）
ボディパート２．２（ｃｏｎｔｅｎｔ−ｔｙｐｅ：テキスト／ｈｔｍｌ）（ｃｏｎｔｅｎｔ−ｌａｎｇｕａｇｅ：ｅｎ）

このＭＩＭＥプロトコルに対する僅かな拡張は、メッセージの全コンポーネントを表示する際に、既存の電子メールクライアントに影響を与えるべきではないが、メッセージの送信者及び受信者の両方のために適切な言語コンポーネントをアドインモジュールがフィルタリングするのを大幅に助ける。

メッセージが第三者に転送される時には返信用の上のメカニズムを使用可能だが、この時、翻訳システム３１は、メッセージの第一の部分を翻訳することはなく、オリジナルテキストを使用して、追加コンポーネントを作成する。英語、ドイツ語、及びフランス語を話す人達が通信プロセスに関与し、英語を話す人がドイツ語を話す人に最初のメッセージを送信し、ドイツ語を話す人がフランス語を話す人にこれを転送すると仮定すると、次のようになる。
Ｅ１ → ＧＴ１，Ｅ１ → ＦＴ１，ＧＴ１，Ｅ１
ここで：
Ｅ１ オリジナル英語テキスト
ＧＴ１ オリジナル英語テキスト（Ｅ１）の翻訳ドイツ語バージョン
ＦＴ１ オリジナル英語テキスト（Ｅ１）の翻訳フランス語バージョン

英語を話す人とドイツ語を話す人との間の通信は上記のように進行するが、ドイツ語を話す人によるフランス語を話す人へのメッセージの転送は、翻訳のためにメッセージの第一のコンポーネント（ＧＴ１）ではなく、オリジナル英語テキスト（Ｅ１）にアクセスする必要があるため、異なる形で処理する必要がある。そうしない場合、翻訳済みのドイツ語テキストが更にフランス語に翻訳されるため、翻訳の品質の劣化が生じ得る。結果的に生じるＦＴ１，ＧＴ１，Ｅ１メッセージは、フランス語を話す人に受信され、メッセージの適切な言語コンポーネントを表示するためのフィルタリングが以前の通りに進行する。メッセージが転送される各段階では、オリジナル英語テキスト（Ｅ１）に由来する別の言語コンポーネントが、メッセージに追加される。例えば、フランス語を話す人が次にスペイン語を話す人にメッセージを転送する場合、受信されるメッセージは、オリジナル英語テキスト（Ｅ１）のスペイン語（ＳＴ１）、フランス語（ＦＴ１）、及びドイツ語（ＧＴ１）の翻訳を含み、次のようになる。
Ｅ１ → ＧＴ１，Ｅ１ → ＦＴ１，ＧＴ１，Ｅ１ → ＳＴ１，ＦＴ１，ＧＴ１，Ｅ１

したがって、転送するプロセスでは、オリジナルテキストの複数の言語バージョンがメッセージに添付され、一方、返信では、言語ペア（翻訳テキスト及びオリジナルテキスト）がメッセージに添付される。

事態を少々複雑にするために、フランス語を話す人が、前の例のようにスペイン語を話す人にメッセージを転送する代わりに、ドイツ語を話す人に返信し、次にドイツ語を話す人が英語を話す人に返信したと仮定すると、次のようになる。
Ｅ１ → ＧＴ１，Ｅ１ → ＦＴ１，ＧＴ１，Ｅ１
ＥＴ３，Ｇ３｜ＧＴ２，Ｆ２｜ＦＴ１，ＧＴ１，Ｅ１ ← Ｇ３｜ＧＴ２、Ｆ２｜ＦＴ１，ＧＴ１，Ｂ１ ← Ｆ２｜ＦＴ１，ＧＴ１，Ｅ１
ここで：
Ｅ１ オリジナル英語テキスト
ＧＴ１ オリジナル英語テキスト（Ｅ１）の翻訳ドイツ語バージョン
ＦＴ１ オリジナル英語テキスト（Ｅ１）の翻訳フランス語バージョン
Ｆ２ ドイツ語を話す人に対するフランス語の返信
ＧＴ２ フランス語を話す人からの返信（Ｆ２）の翻訳ドイツ語バージョン
Ｇ３ 英語を話す人に対するドイツ語の返信
ＥＴ３ ドイツ語を話す人からの返信（Ｇ３）の翻訳英語語バージョン

返信と転送との任意の組み合わせが、上に記載した例と同様に処理される。

メッセージの転送を処理するのに必要な挙動は、返信に必要なものと比較して、僅かに異なる。アドインモジュールはＯｕｔｌｏｏｋの返信及び転送ボタンイベントの両方に結合できるため、どの挙動が必要かを把握するための翻訳システム３１に負担をかけるよりも、メッセージにどの処理を適用する必要があるかを示す電子メールヘッダ内のアプリケーション固有パラメータ（即ち、ｘ−ｍｅｓｓａｇｅ−ｔｙｐｅ：＝ｒｅｐｌｙ）を含める方が賢明であると思われる。メッセージが翻訳システム３１によって処理された後、このアプリケーション固有パラメータは、メッセージが受信者へ送給される前に除去できる。この「メッセージタイプ」パラメータは、返信／転送メッセージ処理の目的でブール変数にできるが、その他のメッセージ処理のコンテクストで使用可能となるように、このパラメータを列挙のように扱うことが好ましい場合がある。

メッセージの返信及び転送の組み合わせは、翻訳システム３１上で多数の言語コアをサポートする必要性を劇的に増加させる。以下の言語ペアが必要となり得る上の例の英語、ドイツ語、フランス語、及びスペイン語を話す人達の間の通信は、想像に難くない。
英語−フランス語
英語−ドイツ語
英語−スペイン語
フランス語−英語
フランス語−ドイツ語
フランス語−スペイン語
ドイツ語−英語
ドイツ語−フランス語
ドイツ語−スペイン語
スペイン語−英語
スペイン語−フランス語
スペイン語−ドイツ語

言語の数が増加するにつれ、言語ペアの数は、劇的に増加する。特定の言語ペアが翻訳システム３１でサポートされておらず、ユーザが別の人物にメッセージを送信しようとした際に特定の言語ペアが利用できない場合、アドインモジュールは、ポップアップダイアログボックスを介して、この状況をユーザに警告する必要があり、その後、ユーザは何らかの是正措置を講じることができる。

メッセージの受信は、異なる形で処理する必要がある。ユーザの言語は、デフォルト言語に加えて、第一及び第二の優先言語に分割される。最初に、ユーザの第一の優先言語を使用して、翻訳の言語ペアを決定し、この特定のペアが現在利用できない場合、第二の優先言語が使用され、その他の場合には、デフォルト（現在利用可能な全ての高品質言語翻訳システムがソース言語から英語への翻訳をサポートすることから、通常は、英語である）が使用される。このようにして、システムは、翻訳の言語ペアの発見を試みる。ユーザの言語をデフォルト言語に加え第一及び第二の優先言語に分割する必要性は、現在利用可能な限られた数の高品質な言語ペアの側面である理解される。この特徴の必要性は、より多くの言語ペアが中央サイトに追加されるにしたがって、経時的に減少するであろう。

次に、メッセージの添付物が処理される方法の詳細について説明する。添付物は、プレーンテキスト、書式付きテキスト、スプレッドシート、プレゼンテーション、及びデータベースからオーディオ／ビジュアルファイルまで、多数の形態をとることができる。テキストに基づくもの、スプレッドシート、プレゼンテーション、及びデータベース添付物、即ち、相当量のテキストを有する任意の添付物では、翻訳が適切となり得る。しかしながら、オーディオ／ビジュアルデータについては、今のところ実行不可能である。更に、ユーザが何らかの理由でドキュメントの機械翻訳が不適切になり得ると考えていることから、添付物の翻訳をユーザが希望しない場合もある。したがって、添付物の翻訳は、電子メールボディの自動翻訳から完全に区別するべきである。しかしながら、翻訳が適切である時には、ファイルの添付時又は添付物のプロパティにアクセスするその後の何らかの時点で、添付物の翻訳は、ユーザがオン又はオフに切り替えることができる。

メッセージに添付されるドキュメントのタイプに応じて、書かれている言語に関する知識を、添付物自体から入手できる場合又は入手できない場合がある。例えば、プレーンＡＳＣＩＩテキストは、書かれた言語に関する情報を有していないが、ＲＴＦ又はＨＴＭＬドキュメント等の書式付きドキュメントは、書かれた言語に関する情報を有する場合がある。したがって、ファイルを添付する時点で、ドキュメントの言語を指定する必要が生じ得る。添付物が書式付きテキストを含む場合には、言語情報を十分に利用できる可能性があるため、ユーザは、この情報を要求される必要はない。対照的に、添付物がプレーンテキストである場合、ユーザは、ドキュメントを書くのに使用した言語を示す必要がある。

受信者がメッセージに返信する時、全ての添付物は失われ、返信が受信された時に、その存在を示すもののみが提供される。しかしながら、メッセージが転送される時、添付物は、メッセージの一部として残る。返信では、オリジナルの送信者に戻されることはないため、添付物が翻訳されているかどうかは問題にならない。しかしながら、転送は、上記のような電子メールボディと全く同じ問題が添付物について発生する点において、全く異なる事態となる。以前に引用した英語を話す人がドイツ人にメッセージを送信し、ドイツ人がフランス語を話す人にメッセージを転送する例について考えることができる。英語を話す人は、添付物を翻訳することを選択した時点では、ドイツ人がこのメッセージをフランス人に転送するという知識を有していない。したがって、メッセージは、オリジナルの英語バージョンの添付物をドイツ語バージョンと共に含む必要があり、ドイツ人がフランス語を話す人にメッセージを転送する時、フランス語に翻訳されるのは、次のように、オリジナルの英語の添付物となる。
ＥＡ１ → ＧＡＴ１，ＥＡ１ → ＦＡＴ１，ＧＡＴ１、ＥＡ１
ここで：
ＥＡ１ オリジナル英語添付物
ＧＡＴ１ オリジナル英語添付物（ＥＡ１）の翻訳ドイツ語バージョン
ＦＡＴ１ オリジナル英語添付物（ＥＡ１）の翻訳フランス語バージョン

メッセージが二つ以上の添付物を含む時には、ユーザが翻訳を選択した特定の添付物についてのみ、オリジナルと翻訳バージョンとがメッセージに含まれることになる。

添付物が修正され、その後、メッセージが送信者に戻されるか、或いは別の関係者に転送される時には、更なる複雑性が生じる。修正は、原位置で添付物を編集すること、或いは、修正済みドキュメントをディスクに保存し、その後、メッセージに再添付することで構成される可能性がある。いずれの場合でも、添付物は、メッセージに添付される全く新しいアイテムであるかのように扱われる必要がある。上の例において、ドイツ語を話す人が、フランス語を話す人にメッセージを転送する前に添付物を修正した場合、この時にフランス語に翻訳する必要があるのは添付物のドイツ語バージョンであるため、添付物のオリジナル英語バージョンがメッセージに含まれているかどうかは無関係となる。英語からドイツ語及びドイツ語からフランス語の二重翻訳が発生し、結果的な理解度の低下が生じるのは明白である。ユーザには、この潜在的な二重翻訳の危険性を警告し、メッセージの送信へ進む機会、或いは操作を中止して何らかの是正措置を講じる機会を与える必要がある。

添付物について考慮する必要がある別の動作は、削除である。これがオリジナル言語のドキュメントである場合には、更なる措置を講じる必要はない。しかしながら、メッセージがドキュメントのオリジナル及び翻訳バージョンを両方とも含む場合、一方又は他方を削除することで、次のように、翻訳に何らかの問題が生じる。
１）オリジナルが削除され、メッセージが転送される：
この状況下では、オリジナルが翻訳用としては失われ、翻訳バージョンのみが利用可能な状態で残され、その後、二重翻訳が生じる。
２）翻訳されたものが削除され、メッセージが転送される：
この状況では、オリジナルを翻訳に利用することが可能であり、メッセージは問題なく送信できる。

添付物のオリジナル及び翻訳バージョンの両方は、一方の除去によって他方が除去されるような単一のエンティティとして捉えることができる。実際には、両方の添付物を単一の論理エンティティとして扱うことは、一部のユーザにとって制限のあるものとなり得る。より良好なアプローチは、行動の結果をユーザに知らせる適切な警告を発生させることであり、その後、ユーザは、削除を進めるか、或いは操作をキャンセルするかを選択できる。

次に、電子メール内部の項目を処理する問題について検討する。Ｏｕｔｌｏｏｋは、電子メールボディ自体において追加テキストとして、或いは添付物において、電子メールへの様々な情報項目の追加をサポートする。以下のセクションでは、性質が基本的にテキストである項目についてのみ説明する。

電子メールメッセージ内の電子メールが送信される時、Ｏｕｔｌｏｏｋは、埋め込み電子メールを添付物としてカプセル化メッセージに挿入する。結果として、上記のような添付物を処理するための全ての特徴が、埋め込み電子メールに等しく適用される。

Ｏｕｔｌｏｏｋでは、テキスト又は添付物として、電子メールにメモを追加できる。テキストとして追加されると仮定すると、メモは、電子メールボディの一部を形成するため、残りの電子メールコンテンツから区別不可能となる。代替として、添付物として追加される場合、メモは、単純なテキストに基づく添付物となり、相応に処理される。

次に、翻訳品質を改善できる方法の詳細について説明する。ユーザは、機械翻訳が１００％完全ではないことを一般に認識している。しかしながら、翻訳品質を改善する適切なメカニズムがなければ、翻訳は、オリジナルテキストの「要旨」として特徴付けるのが最適な程度のものとなる可能性がある。翻訳の品質は、翻訳オプションをシステムに組み込むことで達成できるものより低くなるが、翻訳品質を改善するメカニズムを使用しない場合でも、オリジナルの意味を伝達するには十分に良好となる。しかしながら、翻訳の品質は、一部のユーザに翻訳サービスの使用を継続する意思を失わせ得る。したがって、翻訳品質を改善するメカニズムを設定する能力は、システムの基本的部分とする必要がある。

以下は、Ｓｙｓｔｒａｎ^TM翻訳サーバ等の代表的な翻訳サービスがサポートするオプションの一部のリストである。
ドキュメントタイプ
分野別用語集
非翻訳（ＤＮＴ）リスト
顧客固有辞書（ＣＳＤ）

Ｓｙｓｔｒａｎ翻訳サーバは、本発明での使用に適しており、開発される可能性が高いその他の翻訳製品も同様である。

ドキュメントタイプは、テキストのコンテンツ様式を定義し、翻訳の品質に大きく影響を与える可能性がある。以下は、Ｓｙｓｔｒａｎ翻訳サーバがサポートするドキュメントタイプのリストである。
要約
会話／口語
書簡
ジャーナリズム
議事録
なし
パーツリスト
特許
散文
ユーザマニュアル

選択される内容はリストからの任意の一項目で構成されることを考慮すると、プルダウン選択ボックスが、この情報を提示するのに最適な特徴となる。

分野別用語集は、翻訳の精度を改善するためのもう一つのツールである。適切な分野別用語集を選択することで、翻訳品質を大幅に改善できる。以下は、Ｓｙｓｔｒａｎ翻訳サーバがサポートする用語集のリストである。
自動車
航空／宇宙
化学
口語
コンピュータ／データ処理
地球科学
経済／ビジネス
エレクトロニクス
食品科学
一般
法律
生命科学
数学
機械工学
医学
金属学
軍事科学
船／海事
写真／光学
物理学／原子力
政治学

単一のメッセージに対して四つまでの用語集を選択し、ユーザが優先度順に配列してよい。メッセージが中央サイトに到着した時には、最も優先度の高い用語集が単語又は語句の意味を得るために最初に選択され、単語又は語句が発見された場合には、その意味が翻訳プロセスに使用される。しかしながら、単語又は語句が最も優先度の高い用語集で発見されなかった場合には、順番において次に優先度の高い用語集が選択され、以降も同様となる。いずれの用語集でも単語が発見されなかった際には、その言語ペア用の一般辞書からの意味が使用される。

「非翻訳」リストを使用して、翻訳品質を改善することもできる。単語の「非翻訳」リストは、翻訳エンジンが変更するべきではない人名及び地名のような項目を対象とする。この情報の入力及び更新には、単純な編集ボックスで十分となる。

上のドキュメントタイプ及び分野別用語集のオプションでは、こうした特徴に関する情報はアドインモジュール内ではなく中央サイトで保持されるが、これらとは異なり、「非翻訳」リストは、自由形式の情報であり、ユーザ固有である。したがって、ユーザが指定した単語のリストは、翻訳システム３１に送信される各メッセージに添付される。更に、独自のメッセージング機能を有するユーザでは、「非翻訳」リストは、ユーザ固有のリストとの組み合わせが可能なメッセージングサーバに常駐する。この場合、両リストは、メッセージに添付され、中央サイトへ渡される。

メッセージを構成する殆どの電子メールボディは、翻訳が必要になる可能性が高い。しかしながら、例えば、特定の語句を別の言語から借用して、電子メールテキスト内で使用した場合、或いは、ユーザが翻訳を望んでいないが非翻訳リストには存在しない特定の単語を、メッセージ内で使用した場合、このテキストが変更されずに維持されるように、翻訳エンジンに留意させるメカニズムが存在する必要がある。最も容易な方法は、ユーザにとっては、カット、コピー、及びペースト操作と同じ形でそのテキストを範囲指定して、テキストの断片をマークすることである。選択テキストは、翻訳システムメニューオプションの一つを使用して、「非翻訳」のためにマークできる。代替として、マウスの右クリックを使用して、ポップアップダイアログを呼び出すことが可能であり、その後、「プロパティ」を選択して、同じ操作を達成できる。明らかに、これには、この翻訳システム固有の特徴を挿入するための「共通ダイアログ」の修正が必要となる。

電子メールテキストにマーカを挿入することは、ＯｕｔｌｏｏｋテキストエディタがＲＴＦ又はＨＴＭＬのような書式付きテキスト用に構成されている時のみ実行可能となる。プレーンテキスト用に構成されている時も、マーカはテキストストリームに挿入できるが、しがしながら、ユーザの目に見えるようになり、メッセージの読みやすさを低下させ得る。そのため、「非翻訳」のためにテキストを範囲指定する能力は、ＲＴＦ、ＨＴＭＬ、又はその他の書式付きテキストが使用される時のみサポートされるべきである。

テキストのセクションを範囲指定するのに使用されるマーカは、翻訳エンジンによって使用されるものにはならない可能性が高い。そのため、アドインは、ＲＴＦ又はＨＴＭＬメッセージ内のテキストをマークするのに最も適した特徴を使用し、中央サイトは、こうしたマーカを認識し、メッセージを翻訳エンジンに提出する前に必要な任意の変換を実行する必要がある。

顧客固有辞書も、提供可能であり、これによりユーザは、標準辞書に含まれておらず、自分の組織又は業界において特定の意味又は例外的な意味を有する用語を定義できる。

明らかに、顧客固有辞書は特定のソース−ターゲット言語ペアに関連しており、結果として、その選択は、ツールバーオプションで定義された現在の言語ペアに基づく必要がある。顧客固有辞書の記載事項は、ソース言語の単語又は表現と、ターゲット言語での意味と、何らかの文法的情報とを含む。「非翻訳」リストと同様に、顧客固有辞書は特定のユーザに関連するため、顧客固有辞書は、翻訳システム３１に送信される各メッセージに添付する必要がある。更に、独自のメッセージングサーバを有するユーザについては、ユーザの顧客固有辞書と併せて使用される中央化顧客固有辞書をサポートできる。そのため、両方の辞書をメッセージに添付する必要があるが、翻訳システムには単一の顧客固有辞書が渡される。

上記の特徴又は類似するものがシステムでサポートされない場合、翻訳の品質は、オリジナルテキストの要旨として表現され得るレベルまで低下する。

上記の全てのオプションを使用した後でも、翻訳サーバが未知の単語又は語句に遭遇し、翻訳出力にオリジナルテキストが出現する可能性がないとは保証できない。一定のフィードバックを提供するために、翻訳システムは、理解できない全てのものを「未発見単語」としてマークできる。しかしながら、通常の過程において、送信者は、翻訳メッセージへのアクセスを有しておらず、したがって、「未発見単語」を明らかにするために、例えば、ＤＮＴ及びＣＳＤリスト等の翻訳オプションの適切な調整を行うことができない。

必要なものは、エコーバックボタン１０４によって起動されるエコーバック機能であり、これにより、ユーザは、メッセージを翻訳システム３１に提出し、何らかの形でマークした全ての「未発見単語」及び複数の翻訳と共に、翻訳メッセージを自分に返送させることができる。

「未発見単語」をチェックすることは、問題のメッセージを処理のために翻訳システム３１に送信することを伴うが、しかしながら、そのメッセージは、その後、受信者に送給されないため、「メッセージ送信」機能によってサポートされない動作となる。したがって、「未発見単語」のチェックには、この目的でのツールバー１８上の別個のボタンが必要である、そのため、エコーバックボタン１０４の追加が必要となる。

エコーバック機能を使用する時、ユーザは、通常の形でメッセージを作成し、ツールバー１８上のエコーバックボタン１０４を押して、メッセージを試験翻訳のために中央サイトへ送信する。メッセージは、翻訳プロセス中に遭遇した問題に関する情報と共に、送信者へ戻される。基本的には、翻訳プロセスが問題に遭遇し得る理由は二つ存在し、即ち、単語が翻訳エンジンの辞書において発見できなかったためか、或いは、単語が文脈に応じてターゲット言語への複数の翻訳を有し、翻訳エンジンがどの意味を使用するべきか判断できないためである。

翻訳エンジンが自分の辞書を使用して「未発見単語」状態を報告した場合、中央サイト３１の翻訳サービス３４は、一つ以上の更なるオンライン辞書で、適切な翻訳を探す。こうしたオンライン辞書は、中央サイト３１に存在してよく、或いは、他の場所に位置し、中央サイトからアクセスしてよい。未発見単語に対する任意の可能な翻訳オプションは、送信者に返送するメッセージに添付される。単語の翻訳がオンライン辞書で発見された場合には、ＣＳＤに追加される候補となり、発見されない場合、単語は、ＤＮＴリストに含める候補となる。単語がオンライン辞書で発見できなかったとしても、こうした辞書が言語の全ての単語又は語句を網羅している訳ではないため、必ずしも適切な翻訳が利用できないことを示すとは限らない。オンライン辞書に由来する情報を提示されたユーザは、この情報の使用を選択でき、或いは、適切と思われる任意の言語リソースを調べることが可能であり、オンライン辞書はそのうちの一つに過ぎない場合がある。

「未発見単語」の考えられる翻訳等、中央サイトのメッセージ処理コンポーネントによってオンライン辞書から取得した情報は、ＸＭＬ構造化データブロックとして翻訳メッセージに添付され、結果的なメッセージは送信者に戻され、その後、メッセージは通常の形で、ユーザの受信トレイに現れる。メッセージは、追加情報を包含するエコーバックメッセージであることを特定するために、ヘッダ内に情報を含む。したがって、ユーザがこのメッセージを選択した時、アドインモジュールは、添付ＸＭＬデータブロックを使用して、翻訳プロセスに問題を発生させた単語を強調表示する。強調表示された単語の一つを、例えばテキストの強調表示部分上で右マウスクリックを使用することで選択すると、問題の単語について戻された情報がユーザに対して表示される。ユーザは、その後、自分のＣＳＤに含めるために、エントリの一つを選択可能であり、或いは代替として、中央サイトへ行ってオンライン辞書を探し、更には適切な翻訳のために他のソースを調べて、この情報を自分のＣＳＤに追加できる。中央サイトが情報を戻さなかった場合、その単語は名詞である可能性があり、その後、ユーザは、ＤＮＴリストに追加できる。

ユーザは、強調表示テキストの一部又は全部を処理した後、自分のＣＳＤ及びＤＮＴに追加した新たな情報によって欠陥のない翻訳が生じるかをチェックするために、別のエコーバック動作を実行することを選択できる。この時点まで、ユーザは、メッセージに対する「閲覧のみ」の視点を提供するウィンドウを介して返送メッセージについての作業を行う。更なる試験翻訳のためにメッセージを送信する、或いはメッセージに訂正又は追加データを加える、或いは受信者のリストを変更するには、ユーザは、ツールバー１８上の「再送信」ボタン１０７を選択する必要があり、その後、メッセージは、ユーザが発送前にメッセージを修正可能な別のウィンドウにコピーされる。選択肢の一つは、エコーバック機能によって強調表示された翻訳に関する問題が解決できない場合に、単語又は単語群を異なる単語又は単語群に置き換えるために、メッセージを訂正することである。メッセージは、訂正された後、送信ボタン１０１を使用して送信可能であり、或いは、再度エコーバックボタン１０４を使用して、別の試験翻訳のために送り返すことができる。

ユーザは、結果的な翻訳に満足するまで、何度でもエコーバック機能を呼び出すことが可能であり、その後、送信ボタン１０１を使用して、通常の形で、意図する受信者へメッセージを送信できる。メッセージは、エコーバックプロセスを通過した時、「未発見単語」及び複数の翻訳を有する単語に関連するマークアップ情報を含む。この情報は、ユーザが自分のＤＮＴ又はＣＳＤにメッセージ内でマークされた情報を追加するための積極的行動を行うまで、メッセージに添付された状態を維持し、その後、任意の残存するマークアップ情報は、最終的にメッセージが翻訳サイトを介して受信者に送信される時に、メッセージに付随する。この時点で、翻訳サイトは、この情報を翻訳プロセスに使用し得るが、メッセージが受信者へ転送される前に、全てのマークアップテキストをメッセージから除去する。

エコーバック機能は、メッセージ構築の任意の段階で呼び出せるため、使用される時には、受信者が存在しなくても、一人であっても、或いは複数であってもよい。受信者が定義されていない、或いは複数の受信者が存在する状況において、システムは、メッセージが試験翻訳のために送信される前に、ターゲット言語の指定をユーザに促す。送信者の言語と一致しない言語を有する単一の受信者の場合、その言語を適用すると見なされる。複数の受信者が定義されている時、エコーバックは、考えられる各ターゲット言語について呼び出す必要がある。これは厳密に強制される訳ではなく、ユーザは、以前にエコーバックを呼び出していないターゲット言語において翻訳の問題が生じ得るのを理解した上で、任意の時点でメッセージを送信することを選択できる。

エコーバック機能は、結果的な翻訳をチェックする単純なメカニズムをユーザに提供する。この即時的なフィードバックがなければ、翻訳オプションに調整を加えることで翻訳品質を改善し、及び／又は、自分のＣＳＤ及びＤＮＴを強化することは、ユーザにとって問題の多いものとなる。

他の全てのメッセージオプションは、「未発見単語」チェッカによる影響を受けない。例えば、ユーザが添付物の翻訳を選択しなかった場合、添付物は翻訳エンジンによって処理されないため、添付物内の任意の未知の単語又は語句は、明らかにならない。「未発見単語」チェッカの一回以上の反復後、翻訳の問題が認められないことにユーザが満足した後、メッセージは、通常の形で受信者へ送信できる。

メッセージが翻訳されるまで、翻訳プロセスを改善するために適用可能な特徴に関して、ユーザが何らかの価値のある判断を下せないという点において、対応する状況は、通信リンクの受信者側にも存在する。したがって、受信された電子メールは、通常、コンピュータシステムのスクリーン上で、ユーザに提示され、その翻訳品質は、必ずしも可能な最善のものになるとは限らないが、基になったコンテンツの要旨を提供するには十分なものとなる。自分の言語でメッセージを受信した時、ユーザは、翻訳品質を改善するためにメッセージに適用するべき機能について判断を下す立場にある。したがって、メッセージが最初に翻訳された後、ユーザには、結果に満足するまで何度でも、翻訳品質を改善するとユーザが考えた機能を使用して再翻訳を行うために、再提出ボタン１０６を使用してメッセージを再提出する機会が与えられる。上記の全ての特徴は、「未発見単語」リストを含め、再提出プロセスの一部となる。

受信メッセージは送信者の母国語の情報を含み、最初の翻訳では、電子メールのボディのみが翻訳され、翻訳電子メールを読むことが可能となるまで、ユーザは任意又は全ての添付物を翻訳するべきかについて何らかの判断を下せないことから、添付物は全て翻訳されないままとなる。ユーザは、電子メールのボディのみの再翻訳を続行するか、或いは、プロセスに任意の添付物を含めるかを判断できる。例えば、添付物がスプレッドシートである場合、こうしたドキュメントの翻訳は、ユーザにとって意味がない可能性があるため、ユーザには、添付物の任意の一つ又は全部を再翻訳プロセスから除外するオプションが与えられる。このオプションは、例えば、再提出機能が選択された時に、再翻訳の対象となるメッセージの部分の選択リストを生成することで提供できる。これにより、ユーザは、再提出の対象となる部分を選択できる。

再提出は、返信及び転送によく似た、受信メッセージに対して行われる措置である。更に、再提出に僅かでも似たものを提供するボタンは、従来のシステムに存在せず、したがって、再提出ボタン１０６は、この目的でツールバー上に必要となる。

再提出の特徴により、メッセージの受信者は、メッセージを翻訳のために中央サイト３１へ送信し、結果として生じたメッセージを返送させることができる。この特徴は、未翻訳のメッセージを受信した時、及び自動言語検出プロセスでソース言語が誤って特定された時、或いは、翻訳サービスの加入者から翻訳メッセージを受信し、加入者が受信者の言語を間違って定義していた時に必要となる。いずれのケースにおいても、受信者は、翻訳プロセスのためにソース又はターゲット言語のいずれかを再定義し、メッセージを再提出できる。

上記のようにソース又はターゲット言語の相違を訂正することの他に、再提出機能の別の目的は、翻訳品質を高めることである。したがって、再提出機能が選択された時、ユーザには、ソース又はターゲット言語の再定義し、更に、優れた翻訳を得られるようにＣＳＤ又はＤＮＴリスト若しくは他の任意の翻訳パラメータを再定義できるウィンドウが提示される。

翻訳品質を高める際の主要なコンポーネントは、ソース言語からターゲット言語への翻訳において、翻訳エンジンの辞書にない翻訳、或いはこうした辞書に含まれる任意の項目を無効にする翻訳を提供するＣＳＤである。ＣＳＤの通常の使用では、メッセージ作成者の言語（ソース）から閲覧者の言語（ターゲット）への翻訳を提供する。再提出の状況でのＣＳＤの使用では、外国語を受信者の母国語にするＣＳＤが必要となる。個人ユーザでは、常に自分の言語から他の何らかの言語へのＣＳＤを有することから、これは特に問題となる。しかしながら企業ユーザでは、恐らくは言語間のいずれの方向の翻訳についてもＣＳＤを有しているため、再提出を使用して翻訳品質を高めることは、実行可能な操作となり得る。メッセージが翻訳サービスの加入者から送信された場合、翻訳の品質は、良好となる可能性が高く、これにより、再提出の特徴の必要性は軽減される。反対に、メッセージが非加入者を起源とする場合、最初の翻訳品質は、理想的とならない場合があるため、再提出機能は、価値のあるシステムの特徴となる。

ユーザは、翻訳出力の品質を制御するために様々な翻訳オプションを設定することになる。この情報は、中央サイトが翻訳エンジンを適切に設定できるように、メッセージ内で何らかの形で伝達する必要がある。この情報は、翻訳エンジンにとってのみ有用であり、そのため、受信者に送信される再構築済みメッセージの一部は形成しない。

幸いなことに、ＭＩＭＥプロトコル（ＲＦＣ１５２１参照）では、様々な標準ボディタイプを定義するだけでなく、システム設計者は、そのボディタイプがアプリケーション領域内のみに存在する場合には、アプリケーション固有のボディタイプを定義できる。この特定のアプリケーションにおいて、アドインモジュールは、メッセージに新しいボディタイプを挿入し、その後、中央サイトがこれを除去することにより、アプリケーション固有の基準に一致させる。

ＲＦＣ８２２プロトコルに類似するＲＦＣ１５２１は、ｘ−ｔｏｋｅｎフォーマットを使用してアプリケーション固有の定義を提供し、ｔｏｋｅｎは、新しいボディタイプに適切な任意の用語にできる。
ｃｏｎｔｅｎｔ−ｔｙｐｅ：ｘ−ｔｏｋｅｎ／ｓｕｂｔｙｐｅ

「ｓｕｂｔｙｐｅ」要素は、定義を更に限定するためにアプリケーションに適した任意の用語を含むことができる。例えば、全ての翻訳オプションを単一のＭＩＭＥボディにおいて伝達するのではなく、以下のように、再分割するのが適切となり得る。
ｃｏｎｔｅｎｔ−ｔｙｐｅ：ｘ−ｔｒａｎｓｌａｔｉｏｎ／ｄｏｃｕｍｅｎｔ−ｔｙｐｅ
ｃｏｎｔｅｎｔ−ｔｙｐｅ：ｘ−ｔｒａｎｓｌａｔｉｏｎ／ｔｏｐｉｃａｌ−ｇｌｏｓｓａｒｉｅｓ
ｃｏｎｔｅｎｔ−ｔｙｐｅ：ｘ−ｔｒａｎｓｌａｔｉｏｎ／ｄｏ−ｎｏｔ−ｔｒａｎｓｌａｔｅ

柔軟性を最大にするために、全ての翻訳オプションは、次の例のように、オプションパラメータが後に続くオプション名として伝達され、各項目は別個の行となる。
ｇｌｏｓｓａｒｙ１＝ｃｏｍｐｕｔｅｒｓ／ｄａｔａ ｐｒｏｃｅｓｓｉｎｇ
ｇｌｏｓｓａｒｙ２＝ｅｌｅｃｔｒｏｎｉｃｓ

翻訳オプションの一部は、処理時間を節約する列挙変数（例えば、Ｓｙｓｔｒａｎ^TM用語集）にできるが、しかしながら、情報の大部分は、テキストの性質となる。更に、使用されるべきＳｙｓｔｒａｎ^TM用語集は、列挙変数（例えば、ａｖｉａｔｉｏｎ／ｓｐａｃｅ＝４）を使用して指定できるが、このアプローチは、翻訳サーバに追加される他のエンジンにとって適切でない場合がある。考慮すべき別の要素は、ＭＩＭＥメッセージ処理が基本的には文字列解析及び比較の実行であるため、翻訳オプションを抽出するための余分な数ビットの文字列操作が、取るに足らないものとなることである。したがって、翻訳オプションを伝達するのにテキストに基づくアプローチを採用することで、将来発生し得る変化に対処する上で、最大の柔軟性と堅牢性とを提供できる。

句読点、データフォーマット、及び言語固有の略記等、考慮する必要があるその他の項目は無数に存在する。しかしながら、こうしたタイプの言語又は文化的ローカリゼーションの特徴は、全てのユーザに当てはまるため、中央サイトで処理可能となり、翻訳品質を改善するプロセスが簡略化される。

次に、アドインモジュールがユーザのシステムにインストールされた時に何が起こるかについて詳細に説明する。インストール時、アドインは、本発明で受信メッセージを処理するために、ユーザの第一の選択言語と、第二の選択言語と、デフォルト言語とに関する情報のみを必要とする。更に、連絡先リスト１０ａを修正し、連絡先情報入力フォームが連絡先の選択言語を包含できるようにする。ユーザは、翻訳サービスの自動操作のために、可能な限り早い時期に受信者の言語情報を記入した方がよいという指導を受ける。受信者の言語を連絡先リストに入力しない場合、上で説明したように、翻訳されることなく、受信者に直接送信されるメッセージが発生し得る。

ユーザのシステム上にインストールされたアドインモジュールにより、システム上の受信者及び送信者言語フィールドに挿入された情報は制御可能であり、ＩＳＯ−６３９言語コードを使用することで、例えば、フランス語等、場所に依存しない情報は、ローカリゼーションの目的から、アドインモジュール内で例えばフランス語、ｆｒａｎｃａｉｓ、ｆｒａｎｃｅｓ等に翻訳されるが、しかしながら、中央サイトには一貫して二文字のコード「ｆｒ」として常に提供される。

右マウスクリックを使用して、メッセージ送信フォームのＴｏ：、ＣＣ：、又はＢＣＣ：フィールド内で電子メールアドレスを選択することにより、ポップアップダイアログボックスが現れる。このポップアップにおいて「プロパティ」を選択することで、その特定の人物に関して連絡先リスト内に保持している情報を示す様々なタブシートを含むダイアログが表示される。このダイアログボックスは、好ましくは、その人物の基本情報が表示される第一のタブシート上に、受信者の言語を表示するように準備できる。

Ｏｕｔｌｏｏｋの最近のバージョンの特徴には、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）（ＲＦＣ２２５１参照）を使用して、プライベート又はパブリックディレクトリへのアクセスを得る「ディレクトリサービス」を設定する能力がある。ユーザは、企業内部のディレクトリ、或いはインターネット上の公的にアクセス可能なディレクトリを検索し、電子メールアドレス等、個人に関する詳細を取得できる。

Ｏｕｔｌｏｏｋの最近のバージョンにおいて、ディレクトリサービスは、メニュー項目「ツール／アカウント」を使用して設定可能であり、それ以降、「ツール／アドレス帳」にアクセスすることでアドレス帳ダイアログが表示され、その後、ツールバー上の「人物検索」ボタンを選択することで、「人物検索」ダイアログボックスが表示される。「ルックイン」プルダウンリストボックスを使用して、特定のディレクトリサービスを選択可能であり、所望の検索情報を入力した後、指定されたディレクトリを検索できる。検索が成功したと仮定すると、人物の詳細をユーザの連絡先リストに追加できる。この時点で、「プロパティ」ダイアログボックスが表示され、その後、個人の言語を定義できる。ＯＫボタンを選択することで、新しい情報が連絡先リストに保存される。

インストール時には、上記のように、専用の言語フィールドが、連絡先リストに追加される。この言語フィールドは、「プロパティ」ダイアログ（好ましくは最初のネームタブ上）に追加されるため、ユーザは、詳細を連絡先リストに保存する前に、個人のフィールドを更新できる。

Ｏｕｔｌｏｏｋジャーナルは、Ｏｕｔｌｏｏｋ内で発生した多数の異なるイベントに関する情報を保持可能であり、こうしたイベントの一つは、電子メールメッセージに関する。ジャーナルは、連絡先内の全人物又は選択した数の個人との間で送信又は受信が行われた電子メールメッセージを記録するように設定できる。この機能は、翻訳サービスが呼び出された個人を追跡するのに使用できる。

上のセクションでは、本発明をＭｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ^TMにおいてどのように実施できるかについて例示しているが、示した例は、決して包括的なものではない。しかしながら、電子メール通信を処理するために実行されるタスクは全体を通して共通であるため、全てではないとしても、説明した特徴の殆どは、Ｗｉｎｄｏｗｓ^TMに基づくコンピュータシステムで実行される他の電子メールクライアントと、Ｌｉｎｕｘ等のオペレーティングシステムで実行される同様の電子メールクライアントとに応用可能である。電子メールクライアント間で相違が発生する場合は、アドインモジュール内部で、ランタイムにおいて対応される可能性が高い。そうでない場合には、あるオペレーティングシステムから他の何らかのものに移植するために、コンパイル時間が変更されると思われる。

基本的に、本発明の中で説明した技術は、通信プロトコル固有ではなく、電子メールクライアント固有ではなく、オペレーティングシステム固有でもないため、多数の異なる通信環境での使用に適応できる。

本発明の第一の実施形態による、通信システムの一部を形成する送信システムの図である。 本発明の第一の実施形態による、通信システムの一部を形成する受信システムの図である。 本発明の第一の実施形態による、通信システムの一部を形成する受信システムの図である。 本発明の第一の実施形態による、通信システムの一部を形成する翻訳システムの図である。 図１の送信システム上で表示されるツールバーを示す図である。 図１の送信システムの第一の動作モードを示すフロー図である。 図１の送信システムの第二の動作モードを示すフロー図である。 図２ａの受信システムの第一の動作モードを示すフロー図である。 図２ｂの受信システムの変形例の動作モードを示すフロー図である。 図３の翻訳システムの動作を示すフロー図である。

符号の説明

１０ アプリケーション（例えば、電子メールクライアント、ワードプロセッサ）
１０ａ 連絡先リスト
１６ スクリーン
１４ アドインモジュール メッセージのリダイレクト
１２ オペレーティングシステム メッセージトランスポートサブシステム
２ インターネット
２２ａ オペレーティングシステム メッセージトランスポートサブシステム
２４ａ 電子メールクライアント
２６ａ アドインモジュール メッセージのリダイレクト及び言語検出ソフトウェア
２２ｂ オペレーティングシステム メッセージトランスポートサブシステム
２４ｂ 電子メールサーバ
２６ｂ アドインモジュール メッセージのリダイレクト及び言語検出ソフトウェア
３２ オペレーティングシステム メッセージトランスポートサブシステム
３４ 翻訳サービス
３６ メッセージリダイレクト

Claims (60)

1. 送信者からの通信を送信するように構成された送信システムと、受信者に対する前記通信を受信するように構成された受信システムと、翻訳システムとを備える、人間のコミュニケーションのための通信システムであって、
   前記送信システムは、通信を送信する時、前記送信者に関連する第一の人間認知可能な言語と、前記受信者に関連する第二の人間認知可能な言語とを決定し、前記第一及び第二の言語が異なる場合には、前記受信システムのアドレスと共に前記通信を前記翻訳システムへ翻訳のために送信し、これにより、前記翻訳システムが前記迂回通信を翻訳のために受信し、前記翻訳済み通信を前記受信システムへ転送できるようにし、但し、前記第一及び第二の言語が同じである場合には、前記通信を直接、前記受信システムへ送信するように構成され、前記受信システムは、通信の受信時に、前記送信者に関連する第一の人間認知可能な言語と前記受信者に関連する第二の人間認知可能な言語とを決定し、前記第一及び第二の言語が異なる場合には、前記受信システムの前記アドレスと共に前記通信を前記翻訳システムへ翻訳のために送信し、これにより、前記翻訳システムが前記通信を翻訳のために受信し、前記翻訳済み通信を前記受信システムへ返送できるようにし、但し、前記二つの言語が同じである場合には、前記受信システムへ送信された前記通信を受け入れるように構成されるシステム。
2. 前記送信システムは、人間認知可能な言語を複数の受信者のそれぞれに関連付けるアドレスリストを含む、請求項１記載のシステム。
3. 前記送信システムは、その後の前記翻訳システムによる抽出のために、前記迂回通信のヘッダに前記受信者の前記アドレスを保存するように構成される、請求項１又は請求項２記載のシステム。
4. 前記受信システムは、その後の前記翻訳システムによる抽出のために、前記迂回通信のヘッダに前記受信者の前記アドレスを保存するように構成される、前記請求項のいずれかに記載のシステム。
5. 前記翻訳システムは、前記受信システムに前記翻訳済みメッセージを送信する前に、前記メッセージから自分のアドレスを除去するように構成される、前記請求項のいずれかに記載のシステム。
6. 前記送信システムは、前記送信者が前記翻訳を制御するために前記送信システムと対話するのを可能にする送信者入力を含む、前記請求項のいずれかに記載のシステム。
7. 前記送信者入力によって、前記送信者は、特定の通信のための受信者言語を入力できる、請求項６記載のシステム。
8. 前記送信者入力によって、前記送信者は、少なくとも一つの翻訳パラメータを、送信するべき通信に関連付けることが可能となり、前記翻訳システムは、前記少なくとも一つの翻訳パラメータによって少なくとも部分的に決定された形で、前記通信を翻訳できるようになる、請求項６又は請求項７記載のシステム。
9. 前記送信者入力によって、前記送信者は、通信を前記翻訳システムへ翻訳のために送信し、前記翻訳済み通信が前記受信者へ送信される前に、チェックのために前記送信者に返送できる、請求項６乃至８のいずれかに記載のシステム。
10. 送信者から受信者へ通信を送信するように構成された送信システムと、翻訳システムとを備える通信システムであって、
    前記送信システムは、通信を翻訳する必要がある時を判断し、通信を翻訳システムへ翻訳のために転送するように構成され、前記送信システムは、前記送信者が通信を前記翻訳システムへ翻訳のために送信し、前記翻訳済み通信が前記受信者へ送信される前に、チェックのために前記送信者へ返送できるように構成された送信者入力を含むシステム。
11. 前記翻訳システムは、前記返送メッセージにおいて、前記翻訳の問題を強調表示するように構成される、請求項９又は請求項１０記載のシステム。
12. 前記翻訳システムは、前記返送メッセージの前記翻訳を改善する可能性を示唆するように構成される、請求項９乃至１１のいずれかに記載のシステム。
13. 前記送信者入力は、前記翻訳を改善するために、前記送信者が前記返送された通信を修正できるように構成される請求項９乃至１２のいずれかに記載のシステム。
14. 前記送信者入力は、前記翻訳を改善するために、前記送信者が返送された通信に関連する少なくとも一つの翻訳パラメータを修正できるように構成される、請求項９乃至１２のいずれかに記載のシステム。
15. 前記送信者入力によって、前記送信者は、前記通信に挿入された添付物を翻訳するべきかを制御できる、請求項６乃至１４のいずれかに記載のシステム。
16. 前記送信者入力によって、前記送信者は、前記通信に埋め込まれたメッセージを翻訳するべきかを制御できる、請求項６乃至１５のいずれかに記載のシステム。
17. 前記受信システムは、前記受信者が前記翻訳を制御するために前記受信システムと対話するのを可能にする受信者入力を含む、前記請求項のいずれかに記載のシステム。
18. 前記受信者入力によって、前記受信者は、少なくとも一つの翻訳パラメータを、送信するべき通信に関連付けることが可能となり、前記翻訳システムは、少なくとも一つの翻訳パラメータによって少なくとも部分的に決定された形で、前記通信を翻訳できるようになる、請求項１７記載のシステム。
19. 前記受信者入力は、前記受信者が受信済み通信を少なくとも一つの翻訳パラメータと共に前記翻訳システムに再提出し、これにより、前記受信済み通信の前記翻訳を改善できるように構成される、請求項１８記載のシステム。
20. 受信者に対する通信を受信するように構成された受信システムと、翻訳システムとを備える通信システムであって、
    前記受信システムは、前記受信者による閲覧のために前記通信を表示するように構成された表示手段と、前記受信者が前記受信済み通信を少なくとも一つの翻訳パラメータと共に前記翻訳システムへ提出し、これにより、受信者の制御による前記受信済み通信の翻訳を提供できるように構成された受信者入力とを備えるシステム。
21. 当該少なくとも一つの翻訳パラメータは、通信が翻訳される必要がある元の言語を含む、請求項１９又は請求項２０記載のシステム。
22. 当該少なくとも一つの翻訳パラメータは、通信を翻訳する必要がある翻訳後の受信者言語を含む請求項１９乃至２１のいずれかに記載のシステム。
23. 前記受信者入力は、前記受信者が翻訳又は再翻訳を必要とする前記通信の部分を特定できるように構成される、請求項１９乃至２２のいずれかに記載のシステム。
24. 前記受信者入力によって、前記受信者は、前記通信に挿入された添付物を翻訳するべきかを制御できる、請求項１７乃至２３のいずれかに記載のシステム。
25. 前記翻訳システムは、翻訳された後に前記通信から少なくとも一つの翻訳パラメータを除去するように構成される、請求項８乃至１４及び１８乃至２３のいずれかに記載のシステム。
26. 前記送信システムは、通信を複数の受信者に対してアドレス指定し、前記受信者のそれぞれの前記受信者言語を前記送信者の言語と比較し、前記受信者の言語とは異なる言語を有する任意の受信者について、前記通信を、翻訳が必要な各受信者の前記言語及びアドレスと共に、前記翻訳システムへ送信できるように構成される、前記請求項のいずれかに記載のシステム。
27. 前記送信システムは、前記翻訳システムが前記通信を各受信者言語へ一度だけ翻訳する必要が生じるように、前記受信者をその言語に基づいてグループ化するように構成される、請求項２６記載のシステム。
28. 前記送信システムは、前記通信の単一のコピーを、前記受信者のそれぞれに関連する情報と共に、前記翻訳システムに送信するように構成され、前記翻訳システムは、前記通信を前記必要な言語のそれぞれに翻訳するように構成される、請求項２６又は請求項２７記載のシステム。
29. 送信者から複数の受信者へ通信を送信するように構成された送信システムと、翻訳システムとを備える通信システムであって、
    前記送信システムは、前記受信者のそれぞれの前記受信者言語を前記送信者の言語と比較し、前記受信者の言語とは異なる言語を有する任意の受信者について、前記通信の単一のコピーを、翻訳が必要な各受信者の前記言語及びアドレスと共に、前記翻訳システムへ送信するように構成され、前記翻訳システムは、前記通信を前記必要な言語のそれぞれに翻訳し、前記翻訳済み通信を前記受信者に転送するように構成されるシステム。
30. 前記送信システムは、ステータスを前記受信者のそれぞれに関連付けるように構成され、前記翻訳システムは、当該ステータスによって少なくとも部分的に決定された形で、前記翻訳済みメッセージを前記受信者のそれぞれに転送するように構成される、請求項２８又は請求項２９記載のシステム。
31. 前記送信システムは、各受信者の前記ステータスを、前記受信者が前記通信のアドレス指定の対象である一次受信者であることを示す第一の受信者ステータスと、前記受信者が前記通信のコピーを受信するが、前記受信者が前記他の受信者のいずれに対しても特定されないことを示す第二の受信者ステータスとを含むステータスのグループの一つとして定義するように構成される、請求項３０記載のシステム。
32. 前記送信システムは、ステータスの当該グループ内で、前記受信者が前記通信のコピーを受信し、前記他の受信者に対して特定されることを示す第三の受信者ステータスを定義するように構成される。請求項３１記載のシステム。
33. 前記翻訳システムは、前記第一のステータスの受信者に前記翻訳済みメッセージを転送する時、前記第二のステータスの任意の受信者の詳細を前記通信から除去し、前記翻訳済み通信を前記第二のステータスの前記受信者のそれぞれに対して別々に転送するように構成される、請求項３１又は請求項３２記載のシステム。
34. 前記翻訳システムは、翻訳される前記通信の任意の部分について、その部分の前記翻訳バージョンと前記オリジナル言語バージョンとの両方を、修正済み通信として前記受信者に転送するように構成される、前記請求項のいずれかに記載のシステム。
35. 送信者からの通信を送信するように構成された送信システムと、受信者に対する前記通信を受信するように構成された受信システムとを備える、人間のコミュニケーションのための通信システムであって、
    前記通信システムは、前記通信の少なくとも一部分を翻訳し、前記翻訳部分と前記部分のオリジナル言語バージョンとを組み合わせて、前記受信システムへ送信するための修正済み通信を形成するように構成された翻訳システムを含むシステム。
36. 前記翻訳システムは、前記通信に、前記部分の前記オリジナル言語バージョンを識別可能にする識別手段を提供するように構成される、請求項３４又は請求項３５記載のシステム。
37. 前記送信システムは、前記翻訳システムによって各部分を適切な形で処理できるように、前記通信内部で複数の部分を定義するように構成される、請求項３４乃至３６のいずれかに記載のシステム。
38. 前記送信システムは、受信者の言語へ翻訳されない任意の当該部分を識別するように構成される、請求項３７記載のシステム。
39. 前記システムは、関連する独自の翻訳パラメータを前記部分のそれぞれが有することが可能となるような形で、前記部分のそれぞれを定義するように構成される、請求項３７又は請求項３８記載のシステム。
40. 当該部分の一つは、添付物を含む、請求項３７乃至３９のいずれかに記載のシステム。
41. 当該部分の一つは、前記通信に埋め込まれたメッセージを含む、請求項３７乃至４０のいずれかに記載のシステム。
42. 前記受信システムは、前記修正済み通信を少なくとも一人の更なる受信者に転送するのを可能にし、前記更なる受信者の言語を前記通信の前記オリジナル言語及び前記翻訳済み言語の両方と比較し、更なる翻訳が必要な場合、前記修正済み通信を、前記部分の前記オリジナル言語バージョンを識別可能な識別子と共に、更なる翻訳のために前記翻訳システムへ送信するように構成される、請求項３４乃至４１のいずれかに記載のシステム。
43. 前記翻訳システムは、当該更なる翻訳を前記部分の前記オリジナル言語バージョンから実行するように構成される、請求項３４乃至４２のいずれかに記載のシステム。
44. 前記翻訳システムは、前記部分の前記更なる翻訳を前記修正済み通信に追加して、言語の異なる前記部分の三種類のバージョンを含む更なる修正済み通信を形成するように構成される、請求項４３記載のシステム。
45. 前記翻訳システムは、前記通信の各部分の前記オリジナル言語バージョンの前記言語と、その部分の任意の後続の翻訳とを識別可能にする識別手段を提供するように構成される、請求項３４乃至４４のいずれかに記載のシステム。
46. 前記受信システムは、前記受信者に対して前記通信を表示するように構成された表示手段と、前記部分の前記言語に基づいて、表示する前記通信の部分を選択する制御手段とを含む、請求項４５記載のシステム。
47. 前記翻訳済み部分の少なくとも一部をどの言語又は言語群で表示されるかを前記受信者が選択できるように構成された入力手段を備える、請求項４６記載のシステム。
48. 前記受信システムは、前記翻訳システム以外から受信した通信をモニタして、それがどの人間理解可能な言語であるかを識別し、その言語を前記受信者の前記言語と比較し、異なる場合には、前記受信済み通信を前記受信者の言語への翻訳のために前記翻訳システムに送信するように構成される、前記請求項のいずれかに記載のシステム。
49. 前記受信システムは、前記受信済み通信のコンテンツを分析することで、前記受信済み通信の前記言語を識別するように構成される、請求項４８記載のシステム。
50. 前記翻訳システムは、前記送信システムからの暗号化通信を受け入れ、安全な形で前記メッセージを復号化及び翻訳し、その後、前記翻訳済みメッセージを暗号化し、前記受信システムへ転送するように構成される、前記請求項のいずれかに記載のシステム。
51. 前記翻訳システムは、前記送信システムからの安全なネットワークを介して通信を受け入れ、前記メッセージを翻訳し、同じ安全なネットワークを介して、前記翻訳済みメッセージを前記受信システムへ転送するように構成される、前記請求項のいずれかに記載のシステム。
52. 送信者から受信者への通信を送信するように構成された送信システムを備える人間のコミュニケーションのための通信システムであって、
    前記送信システムは、通信を送信する時、前記送信者に関連する第一の人間認知可能な言語と、受信者に関連する第二の人間認知可能な言語とを決定し、前記第一及び第二の言語が異なる場合には、前記受信システムのアドレスと共に前記通信を翻訳システムへ翻訳のために送信し、これにより、前記翻訳システムが前記迂回通信を翻訳のために受信し、前記翻訳済み通信を前記受信システムへ転送できるようにし、但し、前記第一及び第二の言語が同じである場合には、前記通信を直接、前記受信システムへ送信するように構成されるシステム。
53. 送信者から受信者への通信を受信するように構成された受信システムを備える人間のコミュニケーションのための通信システムであって、
    前記受信システムは、前記通信の受信時に、前記送信者に関連する第一の人間認知可能な言語と、前記受信者に関連する第二の人間認知可能な言語とを決定し、前記第一及び第二の言語が異なる場合には、前記受信システムのアドレスと共に前記通信を前記翻訳システムへ翻訳のために送信し、これにより、前記翻訳システムが前記通信を翻訳のために受信し、前記翻訳済み通信を前記受信システムへ返送できるようにし、但し、前記二つの言語が同じである場合には、前記受信システムへ送信された前記通信を受け入れるように構成されるシステム。
54. 通信を送信する方法であって、
    送信者から受信者へ送信されるべき通信を特定するステップと、前記送信者に関連する第一の人間認知可能な言語、及び受信者に関連する第二の人間認知可能な言語を決定するステップと、前記第一及び第二の言語が異なる場合には、前記受信システムのアドレスと共に前記通信を翻訳システムへ翻訳のために送信し、これにより、前記翻訳システムが前記迂回通信を翻訳のために受信し、前記翻訳済み通信を前記受信システムへ転送できるようにし、但し、前記第一及び第二の言語が同じである場合には、前記通信を直接、前記受信システムへ送信するステップと、を備える方法。
55. 通信を受信する方法であって、
    受信者に受信されるべき送信者からの通信を特定するステップと、前記送信者に関連する第一の人間認知可能な言語、及び受信者に関連する第二の人間認知可能な言語を決定するステップと、前記第一及び第二の言語が異なる場合には、前記受信システムのアドレスと共に前記通信を前記翻訳システムへ翻訳のために送信し、これにより、前記翻訳システムが前記通信を翻訳のために受信し、前記翻訳済み通信を前記受信システムへ返送できるようにし、但し、前記二つの言語が同じである場合には、前記受信システムへ送信された前記通信を受け入れるステップと、を備える方法。
56. 通信を送信する方法であって、
    送信システムから受信システムへ前記通信を送信するステップと、前記通信の少なくとも一部を翻訳するステップと、前記翻訳部分及び前記部分のオリジナル言語バージョンを組み合わせて修正済み通信を形成するステップと、前記修正済み通信を受信システムへ送信するステップと、を備える方法。
57. 送信者から複数の受信者へ通信を送信する方法であって、
    前記受信者のそれぞれの受信者言語を前記送信者の言語と比較するステップと、前記受信者の言語とは異なる言語を有する全受信者について、前記通信の単一のコピーを、翻訳が必要な各受信者の前記言語及びアドレスと共に、前記翻訳システムへ送信するステップと、前記翻訳システムにおいて前記通信を前記必要な言語のそれぞれに翻訳するステップと、前記翻訳済み通信を前記受信者へ転送するステップと、を備える方法。
58. 通信システムを使用して通信を送信する方法であって、
    通信を翻訳する必要がある時を判断するステップと、前記通信を翻訳システムへ翻訳のために転送するステップと、前記通信を送信システムへ返送して、ユーザに対して表示するステップと、前記翻訳をチェックするステップと、前記翻訳が満足できる場合、前記翻訳済み通信を受信者へ送信するステップと、を備える方法。
59. 通信システムを使用して通信を受信する方法であって、
    受信者に対する通信を受信するステップと、前記受信者による閲覧のために前記通信を表示するステップと、前記受信者による制御の下で、少なくとも一つの翻訳パラメータと共に、前記受信済み通信を翻訳システムへ再提出し、これにより、受信者の制御による前記受信済み通信の翻訳を提供するステップと、を備える方法。
60. 前記添付図面を参照して実質的に上記において説明したような通信システム。

Images