JP5129567B2 - 添付ファイル付きメッセージを処理するためのメッセージングプロトコル - Google Patents

Description

本発明は、その一実施形態において、ルータを介して相互接続されたデータ網の集合（例えばインターネット）のための電子メッセージングプロトコルに関し、特に添付ファイルを有するメッセージの処理技術に関する。また、他の実施形態についても、本願明細書に記載し、特許請求をする。

インターネットを介してメッセージをやり取りするために用いられる電子メッセージングプロトコルのようなプロトコルは、広範に普及している。このようなプロトコルの例としては、電子メール（Ｅメール）、ニュース、オンラインチャット（しばしばインスタントメッセージングと呼ばれる）のプロトコルがある。これらのプロトコルは、通常、（ｉ）メール本文と（ii）１以上のヘッダ欄を持つ何らかの形のデータ構造と、メッセージを定義する。ヘッダ欄には、そのメッセージはどこから来たか（例えば、電子メールメッセージの「ｆｒｏｍ：」欄）、そのメッセージ情報はどこへ送られるか（例えば、電子メールメッセージの「ｔｏ：」欄）、メッセージの件名、送信日時等についての情報を書き込む。これに対して、メール本文には、例えば、そのメッセージの本文または要約が、通常予め決められたフォーマットを持つ（例えばアスキー文字のみからなる）データ形式で書き込まれる。

一部のプロトコルでは、発信者は、予め決められたフォーマットになっていないオブジェクトをメール本文に同封するかまたは「添付する」ことが可能である。これらのプロトコルは、予め決められたフォーマットと所与のソフトウェアアプリケーションで使用される他の何らかのフォーマットとの間の変換（例えば、７ビットアスキー文字と８ビットバイナリ文字との間の変換）を自動的に行う。メッセージの受信者は、変換プロトコルを用いて添付オブジェクトを「取り出す」ことができる。例えば、電子メールメッセージに関しては、多目的インターネットメール拡張仕様（ＭＩＭＥ）プロトコルを用いると、画像ファイル、オーディオ／ビデオファイル、アプリケーションソフトウェアファイル（例えば、ワードプロセッサ、スプレッドシート、データベースプログラムファイル等）のようなノンアスキーオブジェクトをメッセージの添付ファイルにすることが可能である。添付ファイルは、ディスプレイモニタ上で例えば小さいアイコンにファイル名のような識別子を付けてユーザに示される。

以下、本発明を添付図面に図解した実施形態により説明するが、これらは例示説明のためのものであって、限定のためのものではなく、図中、同じ参照符号は同様の要素を指すものとする。ここで留意しなければならないのは、本願明細書中、特定しない形で本発明の「一」実施形態とある場合、それは必ずしも同一実施形態を指すものではなく、少なくとも１つの実施形態を意味するということである。

本願発明者は、添付ファイル付き転送メッセージを受け取ったとき、従来の技術では、メッセージ受信者にその転送メッセージに関連する様々な発信者の中のどの発信者が添付ファイルの実際の添付者であるかということが示されず、あるいは示唆もされないということに着目した。例えば、電子メールの場合、添付ファイルを伴う少なくとも１回転送された電子メールメッセージを受け取ったとき、受信者は、そのメッセージの２以上の先行発信者の中のどの発信者が実際にその添付ファイルを挿入するよう要求したかを示す情報を持たない。このような情報があれば、グループをなす人々が、通常の電子メール機能を用いて１以上の文書の異なる版を添付ファイルとしてやり取りしながらそれらの文書について共同で作業するような場合に特に役立つものと思われる。

本発明の一実施態様によれば、メッセージの添付ファイル（電子メッセージングプロトコルに従って処理しようとする添付ファイル）に添付者固有の属性を関連づける。もちろん、これはそのメッセージを発信者に関連づけることに加えて行う。この方法は、複数の添付ファイル、さらには新たに作成されるかあるいは２回以上転送されたメッセージに適用して、そのメッセージの受信者が、誰が何をメッセージに添付したかをより容易に判断できるようにすることが可能である。この場合、グラフィカルユーザインタフェースは、メッセージの各添付ファイルについて、ファイル名のみならず、添付ファイルの添付者の任意の固有属性（例えば、名前、電子メールアドレス等）をも表示することができる。これは、例えば、メッセージの複数の添付ファイルや、メッセージチェーンのシングルスレッドまたは回帰スレッドの１以上の異なる添付者について行うことも可能である。

一例として、Ｊｏｈｎ Ｄｏｅという人がメッセージを作成して、これに「ａ．ｄｏｃ」という名前のファイルを添付する場合を考える。次に、そのメッセージはＪａｎｅ Ｓｍｉｔｈという人に送られ、Ｊａｎｅ Ｓｍｉｔｈは受け取ったメッセージに「ｂ．ｄｏｃ」という名前の別のファイルを添付する。次に、そのメッセージをＡｌｉｃｅ Ｃｏｏｐｅｒという人に転送する。Ａｌｉｃｅは、例えばこのような手順をサポートするクライアントプログラムまたは同様のサポートのあるウェブインタフェースを用いてメッセージを受け取り、開封する際、従来の意味での２つの添付ファイルを伴ったメッセージを知らされるだけでなく、各添付ファイルに直接関連する人物の名前または他の固有の属性も知らされる。このように、この例では、Ａｌｉｃｅは「ａ．ｄｏｃ」の添付ファイルアイコンが見え、その隣に「Ｊｏｈｎ Ｄｏｅ」と表示されることになる。さらに、Ａｌｉｃｅは「ｂ．ｄｏｃ」の添付ファイルアイコンが見え、その隣に「Ｊａｎｅ Ｓｍｉｔｈ」と表示されることになる。図１に示すもう一つの例は、「関連添付ファイル」機能を付加したメールボックスとのウェブインタフェースの役割を果たすクライアントプログラムによるウィンドウのスクリーンショットである。この例では、ディスプレイには、転送メッセージの最新転送区間に対応する「ｆｒｏｍ」欄１０と「ｔｏ」欄１４が表示されている。さらに、それより前の転送区間についても「ｆｒｏｍ」欄１８と「ｔｏ」欄２２が表示されている。画面の下端部には、ファイル名欄２６、３４で特定表示することができる２つの添付ファイルが表示されている。これらの各添付ファイルは、欄３０、３８を付け加えることによって、電子メール受信者に対して添付ファイルの添付者をより表示しやすくしたという意味で、「関連添付ファイル」である。しかしながら、より広義の意味では、以下に説明するように、この関連添付ファイル技術は他のタイプのメッセージングプロトコル、さらには他のタイプのデータ通信ネットワークにも適用することが可能である。

次に、図２は、本発明の関連添付ファイル機能を実施するためのデータ網の一例を示す。この実施形態においては、メッセージングプロトコルは、セントラルサーバモデルの形の単一のメッセージサーバ１０８を用いて、いくつかの互いに接続されたユーザシステム間でメッセージをやり取りする。ここで、一例のメッセージ１２０は、ユーザシステム１１６（発信元）から発して、対象受信者のユーザシステム１０４に届けられるものとする。メッセージ１２０は、ユーザシステム１０４のクライアントプログラムを使ってメッセージを読むことができるようになるまでの間、メッセージサーバ１０８の制御下において中央メッセージ記憶装置１１２に保管することが可能である。メッセージ１２０は、ユーザシステム１１６で添付ファイル１２４が挿入された場合におけるその添付ファイル１２４、発信者を特定するデータが書き込まれた発信者欄１２５、受信者を特定表示する受信者欄１２６、添付ファイル１２４を挿入するよう要求した添付者を特定表示する関連添付ファイル（ＡＡ）欄１２８を含む。このように作成されたメッセージ１２０は、受信者欄１２６のデータで特定される受信者に代わって中央メッセージ記憶装置１１２に保管される。

図３は、メッセージングプロトコルが１以上のルータにより相互接続された多数のネットワーク（例えば、インターネット）上で運用される本発明のもう一つの実施形態を示す。この実施形態では、システム内のすべてのユーザの要求に対応する単一のメッセージサーバ１０８を設けるのではなく、複数のシステムまたはネットワークをメッセージ転送エージェント２０４で接続する。この場合、メッセージ２２０は、例えばユーザエージェント２０８から発し、図示のように、１以上の添付ファイル１２４と各添付ファイルのＡＡ欄１２８を持つ。メッセージ２２０は、発信元ユーザエージェント２０８と宛先ユーザエージェント２１２との間の経路内のどこかに保管することが可能である。したがって、発信元ユーザエージェント２０８と宛先ユーザエージェント２１２との間には複数の「ホップ」が存在し得る。図２の実施形態におけるように、メッセージがある添付者からの添付ファイル、そのメッセージの発信者を特定表示する欄、添付者を特定表示するＡＡ欄を含む場合において、対象受信者は、電子メッセージングプロトコルに従って処理されたそのメッセージに関する情報を受け取る。この情報は、メッセージ２２０のいろいろな部分から取り出すことができ、１回の転送で受信者のユーザエージェント２１２に届けることも、あるいは何回かの異なる転送を経て届けることも可能である。

やはり図３において、１つのシステムから別のシステムへ、すなわち、１つのメッセージ転送エージェント２０４から別のメッセージ転送エージェントへのメッセージの移動は、ユーザエージェント２０８からメッセージを集めて宛先のメッセージ転送エージェント２０６へ渡すサーバソフトウェを用いて行うことができる。一例として、メール転送プロトコル（ＳＭＴＰ）を使用することによって、メッセージをどのようにして１つの記憶装置またはファイルシステムから他の記憶装置またはファイルシステムへ、あるいは１つのサーバから他のサーバへ移動させるかを規定することができる。

メッセージは、例えばポストオフィスプロトコル（ＰＯＰ）を用いて、ユーザエージェント２０８からメッセージ転送エージェント２０４のサーバへ、あるいはメッセージ転送エージェント２０６のサーバからユーザエージェント２１２へ送られる。このような場合は、受信者のクライアントソフトウェア（またはユーザエージェント）が、何かメッセージがないかどうか、受信者のメールボックスまたはメッセージ記憶装置をしばしばチェックする。メッセージがあった場合、そのメッセージは、ダウンロードしてローカル保管され、その後受信者に知らされる。同様に、発信元または発信者のサイトでも、クライアントソフトウェアまたはユーザエージェント２０８がメッセージを配信のためにメッセージ転送エージェント２０４のサーバへ送る。

図４は、クライアントプログラム（または単にクライアント）が関連添付ファイル機能を認識している発信者と受信者との間の通信の概念図である。この実施形態においては、送信側クライアント４０４は、これから送ろうとするメッセージに添付ファイルを挿入することができるばかりでなく、その送信側クライアント４０４のユーザが添付ファイルを挿入することを要求した添付者であるという情報を持ち、かつその添付者を特定表示するために新しい欄をそのメッセージに挿入し、記入することができるので、「ＡＡ認識型」という用語で表現する。

ここで留意しなければならないのは、このメッセージは、新たに作成したメッセージ、すなわちクライアント４０４で新たに作成したメッセージでも、転送メッセージ、すなわちクライアント４０４が前に受け取ったメッセージで１以上の先行発信者を特定できる情報を含むメッセージに基づいたメッセージでもよいということである。したがって、転送メッセージの場合は、そのメッセージに、先行発信者からの別の添付ファイルを、その先行発信者が別の添付ファイルを挿入した別の添付者であることを特定指示する情報と共に含めることも可能である。例えば、図１のスクリーンショットにこのような複数の添付ファイルが付いた転送メッセージが示されている。この例における情報は、添付者をその電子メールアドレスで特定指示する。他の情報としては添付者の名前があり、添付者が人の場合は、その人のイニシャルだけが表示される。複数の添付ファイルを持つ転送メッセージのもう一つの例を、メッセージ中のすべてのヘッダと共に下記に示す。

電子メールメッセージの例
From Jane Smith Fri Dec 12 15:14:392003
X-Apparently-To: alice@iapdomain..com via 216.136.225.53; Fri, 12 Dec 2003
15:14:58 -0800
Return-Path: <janes@iapdomain.com>
Received: from 64.202.166.29 (HELO smtpout-l-2d.secureserver.net)
(64.202.166.29) by mta222.mail.scd.yahoo.com with SMTP; Fri, 12 Dec 200315:14:5-0800
Received: (qmail 16195 invoked from network); 12 Dec 200323:14:58 -0000
Received: from unknown (67.100.80.253) by smtpout-l-2d.secureserver.net
(64.202.166.28) with ESMTP; 12 Dec 200323:14:58 -0000
Subject: FW: Pics
Date: Fri, 12 Dec 2003 15:14:39 -0800
Message-ID: <002201c3cl05$b84012f0$3201a8c0@Mike>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--
=_NextPart_000_0023_01C3C0C2AAlCD2F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Length: 434890

Forwarded Message

From: "John Doe" <johnd@iapdomain.com>
To: janes@iapdomain.com
Subject: Pics
Date: Thu, 11 Dec 200308:21:36 -0800
Message-ID: <39A8F53E4B5F7l4EB75663F972770BDA08CC92@fnserver.doe.local>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--
=_NextPart_000_001D_01C3C0C2.A9F91E50"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-Nonspam: Whitelist
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal

Attachment

a.doc
.jpg file, 750x563, 63k
X-AA_entity: "John Doe" <johnd@iapdomain.com>

Attachment

b.doc
.jpg file, 800x600, 66k

X-AA_entity: "Jane Smith" <janes@iapdomain.com>

上記の例では、特定の添付ファイルに関連する添付者の情報がＸ＿ＡＡ＿ｅｎｔｉｔｙと書かれた「Ｘ−ヘッダ」欄に表示される。例えば、周知のメッセージング基準に適合する他の任意のメッセージ欄を用いることも可能である。

やはり図４において、メッセージは送信側クライアント４０４からメッセージ転送エージェント（この実施形態ではＳＭＴＰサーバ／リレー４０８である）へ送ることが可能である。これは、インターネットへのユーザアクセスを可能にしかつインターネット・アクセス・プロバイダ（ＩＡＰ）が管理することが可能なアクセスポイント（ＰｏＰ）４０６経由で行うことができる。発信元ユーザは、例えばＩＡＰの加入者であり、例えば、ダイヤルアップ接続、デジタル加入者線（ＤＳＬ）または他の低水準伝送リンクを介してＰｏＰ４０６と通信することが可能なハードウェア（図示省略）を使用する。

メッセージはさらに、１以上のホップ、すなわちインターネットのノードによって転送され、受信者側のメール転送エージェント、ここではＳＭＴＰリレー４１６に届く。ＳＭＴＰリレー４１６では、メッセージを記憶装置（図示省略）に転送して、受信者に代わり保管することが可能である。すると、受信者のクライアントプログラム（または単にクライアント）４２０は、その受信者に割り当てられたメールボックスからメッセージを（例えば、新しいメッセージがあるかどうかポーリングすることにより）受け取ることができる。

ここで留意しなければならないのは、図４に示す実施形態においては、発信者と受信者のクライアント４０４、４２０がどちらも関連添付ファイル機能を認識しているということである。その場合、ＳＭＴＰサーバ／リレー４０８も、ＳＭＴＰリレー４１６もＡＡ機能を認識している必要があり、添付者に関する情報を処理し、表示するのはクライアント４０４、４２０の役割である。ＡＡ機能を持つよう修正することが可能なクライアント４０４、４２０の一例として、電子メールクライアントプログラム（例えば、ロータス・ディベロップメント・コープ社製のＮＯＴＥＳソフトウェア）がある。

図４との関連で行った上記説明の部分を要約すると、クライアント４０４、４２０は、各々がメッセージの特定のヘッダ欄をそのメッセージの添付ファイルと関連する添付者を指示するものと、元来の機能で解釈することができるという意味で、「ＡＡ認識型」と言われる。言い換えると、受信者クライアント４２０は（また、送信側クライアント４０４も同じく）、関連添付ファイル情報を解釈してユーザに正しく表示するために必要な（そのクライアントアプリケーションを構成するソフトウェアの発行者が提供するところの）プログラムコードを有する。クライアントプログラムが自動的には関連添付ファイル情報を解釈することができない本発明のもう一つの実施形態を図５に示す。例えば、任意型クライアント５０４は、発信元ユーザが自分が加入しているメールボックスサービス、例えばＹａｈｏｏ！Ｍａｉｌの電子メールソリューションにアクセスするために使用する通常のウェブブラウザであってもよい。この場合、ユーザはメッセージングサービスの加入者であり、特に関連添付ファイル機能を提供するメッセージングサービスの加入者である。ユーザは、Ｙａｈｏｏ！Ｍａｉｌの電子メールソリューションが提供するようなウェブインタフェースを介して、新しいメッセージを作成するよう要求することができ、また（通常の技術により）挿入する添付ファイルを指定することができる。そして、ユーザが特定の添付ファイルを要求していることを認識し、それに応じて発信元ユーザをその添付ファイルを挿入するよう要求した添付者として特定指示するための指定された欄をメッセージに追加するのは、その電子メールソリューションをホスティングするインターネットサービス・プロバイダ（ＩＳＰ）のネットワーク５０９の役割である。メッセージに対するこの修正は、（添付ファイル１２４も含む）そのメッセージの「発信者」をも添付者であるとして認識し、それに応じてＡＡ情報欄１２８をメッセージに付加するＩＳＰネットワーク５０９の新しいソフトウェアによって行うことができる。

受信者側では、任意型クライアント５２０（例えば、前述の場合同様、Ｙａｈｏｏ！Ｍａｉｌの電子メールソリューションのようなインターネットサービス・プロバイダが維持・管理する受信者のユーザ電子メールアカウントとのウェブインタフェースとして使用されるウェブブラウザ）を用いて「受信箱」にアクセスし、表示する。ＩＳＰネットワーク５０９に付加された関連添付ファイルメッセージングサービスは、任意型クライアント５２０に必要なデータを供給して、クライアント５２０が（添付ファイルを含む）メッセージについての情報を受け取ることができるようにする役割を果たし、この場合に受け取る情報は、そのメッセージの発信者欄とＡＡ情報欄から取り出される。例えば、この受け取った情報は、任意型クライアント５２０がダウンロードするウェブサイトコンテンツを介してメッセージの対象受信者に知らされる。

ここで留意しなければならないのは、図４、５に示す上記実施形態においては、発信者と受信者がどちらも同様のタイプのクライアントプログラムを有するが（例えば図４の実施形態では、クライアントプログラムは両方共ＡＡ認識型であるが、図５の実施形態では、クライアントプログラムはどちらもＡＡ認識型ではない）、この関連添付ファイル機能は、発信者クライアントと受信者クライアントのどちらか一方のみがＡＡ認識型である場合にも実施可能であるということである。その場合、任意型クライアント（すなわちＡＡ認識型ではないクライアント）を持つユーザが、自己の任意型クライアントがいずれか特定のメッセージに挿入されたかも知れない何らかの関連添付ファイル情報をそのユーザに正しく表示することができるよう、ＡＡメッセージングサービスの加入者になる必要が起こり得る。

図１に戻って、添付者は、例えば、図示の如く添付ファイルのファイル名の下側にユーザに対応して連続的に表示される電子メールアドレスによって、そのユーザであると特定される。しかしながら、別の実施態様は、この情報を「マウスオーバー」により表示するものである。これを図６に示す。表示されている添付ファイルのファイル名欄２６の上にカーソル６０８を置くと、ポップアップ６１０が現れて、添付者を特定指示する。ポップアップ６１０は、カーソルがファイル名欄２６外に移動すると消える。もう一つの実施形態においては、添付者についての情報は図７に示すようなコラプスダウン−コラプスアップ機能を用いて表示される。この場合、各添付ファイルは、別個の三角形アイコン７０４、７０８と関連づけられ、ユーザがこれらの各アイコンをクリックオンすることによって、関連添付ファイルについての情報をコラプスアップ／コラプスダウンする、すなわち簡易化表示したり展開したりすることができる。

図８、９は、関連添付ファイル機能付きメッセージを表示する本発明の他の実施形態を示す。図８においては、メッセージは添付ファイルセクション８０４が簡略化した状態で表示されている。この例の場合、図示のように３つ添付ファイルがある。そして、エンドユーザが展開アイコン８０８をクリックすると、図９に示すような展開された表示が現れる。３つの各添付ファイルについて表示された追加のデータ、すなわち添付者の名前と添付ファイルがその作成者によって作成された日付が見られる。別の態様として、これらの追加のデータには、添付者と関連づけることができる他のタイプの「メタ情報」を含めることも可能である。ただし、このメタ情報は、必ずしもそのすべてを表示する必要はない。

図８、９には、コラプス（簡略化／展開表示）可能セクション８０４の代わりに使用することが可能なもう一つの添付ファイルセクション８１２が示されている。この場合は、エンドユーザがメッセージを開封したとき、関連添付ファイル情報（例えば添付者の名前）がそれぞれの添付ファイルの隣に自動的に表示されて、（添付ファイルセクション８０４のように）表示をクリックにより展開しなくても済むようになっている。

図８、９のユーザインタフェースは、エンドユーザの電子メールサービスアカウントを見、管理するために使用されるウェブベースのクライアントであってもよい。その役割は、例えば、通常の電子メールの保管・伝送と、Ｊ２グローバル・コミュニケーションズ（ｊ２ Ｇｌｏｂａｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）社が提供するファックス／音声−電子メール機能とを結合することである。ユーザは、セクション８２０の名前によって、またインバウンド（入来）ファックス／音声番号によって特定指示される。セクション８２４はいろいろなフォルダのアイコンを表示し、その１つがＩｎｂｏｘ（受信箱）（強調表示される）である。ユーザインタフェースの優先順位の設定、フォルダの管理、カスタマーサポート、メッセージ受信箱セクションのような比較的高水準の操作は、セクション８２６にあるもう一組のアイコンを用いて行うことができる。最後に、セクション８２８には、電子メールサービスアカウントに関する記憶情報の詳細が表示される。

上に説明した本発明の実施形態は、コンピュータプログラム製品またはソフトウェアとして提供することが可能であり、これにはコンピュータ（または他の電子装置）をプログラムして本発明の一実施形態におけるプロセスを実行させるために使用することが可能な命令を記憶した機械可読またはコンピュータ可読媒体を備えることができる。他の実施形態としては、マイクロ命令、ハードワイヤード・ロジックを含む特定のハードウェアコンポーネントによって、あるいはプログラムドコンピュータコンポーネントとカスタムハードウェアコンポーネントの任意の組合せによって動作を行わせることも可能である。

要約すると、添付ファイルの処理を改善するためのメッセージングプロトコルの修正・改良方法を様々な実施形態により説明した。また、上記説明では、本発明をいくつかの特定の実施形態との関連で説明した。しかしながら、特許請求の範囲に記載する本発明の広義の趣旨と範囲を逸脱することなく上記実施形態について種々の修正態様や変更態様をなすことが可能なことは自明であろう。例えば、ＡＡ情報欄は、いくつかの電子メールメッセージ例で添付者を特定指示する情報のみ書き込むものとして説明したが、この欄は、添付ファイルのファイル名、および（例えば、添付ファイルをメッセージに挿入した時刻および／または日付あるいは添付ファイルがその作成者により作成された時刻および／または日付の）タイムスタンプのような他の情報を書き込むために使用することも可能である。したがって、本願明細書と添付図面は、本発明を限定する意味ではなく、例示説明的意味で解釈されるべきものである。

関連添付ファイルを伴う受信電子メールメッセージのスクリーンショットを示す。 本願記載のメッセージングプロトコルの一実施形態を実施することが可能なセントラルサーバメッセージ通信システムの概念図を示す。 メッセージ転送エージェントおよびユーザエージェントを使用するメッセージングプロトコルのためのもう一つの環境の概念図を示す。 クライアントプログラムが関連添付ファイル機能を認識している発信者と受信者との間の通信の概念図である。 関連添付ファイル機能を認識する必要がないという点でクライアントプログラムが任意型である発信者と受信者との間の通信の概念図である。 関連添付ファイルについての情報を表示するマウスオーバー機能を図解した説明図である。 関連添付ファイルについての情報を表示するコラプスダウン／コラプスアップ機能を図解した説明図である。 添付ファイルセクションを簡略化表示したメッセージの初期設定画面例を図解したユーザインタフェースのスクリーンショットを示す。 図８で添付ファイルセクションを展開したユーザインタフェースのスクリーンショットを示す。

Claims (2)

1. 電子メッセージングプロトコルに従って発信者のコンピュータにより、添付者からの添付ファイルを有するメッセージにおける第１ヘッダ欄と第２ヘッダ欄にメッセージの発信者と受信者をそれぞれ特定する情報を挿入するステップと、
   ネットワーク化されたサーバマシンにより、添付ファイルに関連している第３ヘッダ欄のメッセージに添付者の固有の属性を挿入するステップと、
   受信者のコンピュータにより、前記発信者と前記添付者に関する前記情報が挿入された前記メッセージを、前記電子メッセージングプロトコルにより前記メッセージを受け取った受信者に提示するステップとから構成され、
   前記添付者の固有の属性は、（ａ）添付者の名前、（ｂ）添付者が人の場合にはその人のイニシャルのいずれか一つを含み、
   前記メッセージ内において前記添付ファイルは前記第１ヘッダ欄、第２ヘッダ欄および第３ヘッダ欄の外にあることを特徴とする方法。
2. 前記電子メッセージングプロトコルは電子メールプロトコルであることを特徴とする請求項１に記載の方法。

Images