(57)【要約】【課題】送信者が気軽にサービスを利用でき、かつ、メール配信が不要な受信者も、煩雑な手続き無く受信拒否の手続きができる。【解決手段】送信クライアント１２から、送信先のメールアドレス、および、送信すべき情報を指定するための情報を受理すると、送信先のメールアドレスを含む送信リストが生成される。メール制御サーバ２８の照合処理部３０および送信リスト修正部３２は、メール受信を拒否するユーザの情報を記憶したサービス拒否リスト４４を参照して、リスト４４に載っているメールアドレスを、送信リストから除外する。メールサーバ２６は、メールアドレスを特定する固有ＵＲＬを含むメールを送信する。メールの送信先となった受信クライアント１６から、固有ＵＲＬによるアクセスを受理すると、サービス拒否登録部３８は、固有ＵＲＬにしたがって、メールアドレスなどを、サービス拒否リスト４４に追加する。【選択図】　図２
2004086236.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを提供するサーバにおいて、送信クライアントからの依頼にしたがって、所定の情報を含むメールを、１以上の送信先に送信するメール配信制御方法において、
前記送信クライアントから、ネットワークを介して、少なくとも１以上の送信先のメールアドレス、および、送信クライアントからの送信すべき情報を指定するための情報を受理し、前記送信先のメールアドレスのリストを生成するステップと、
メール受信を拒否するユーザに関するメールアドレスおよび受信の拒否にかかる情報のカテゴリを記憶したサービス拒否テーブルを参照して、前記メールアドレスおよび送信すべき情報のカテゴリと一致するものを見出し、当該メールアドレスを、前記１以上のメールアドレスのリストから除外するステップと、
前記所定のメールアドレスが除外されたリストに基づき、前記送信すべき情報、および、メール受信を拒否するためにメール送信および送信先であるメールアドレスを特定する固有情報を含むメールを生成ステップと、
生成されたメールを、送信先に向けてそれぞれ送信するステップと、
前記メールの送信先となった受信クライアントから、前記ネットワークを介して、前記固有情報によるアクセスを受理するステップと、
前記固有情報にしたがって、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリを、前記サービス拒否テーブルに追加するステップとを備えたことを特徴とするメール配信制御方法。
【請求項２】
前記送信すべき情報を指定するための情報が、前記コンテンツの内容を示すサービスコードであり、かつ、前記サービス拒否テーブルに、メールアドレスおよびサービスコードの組が記憶されることを特徴とする請求項１に記載のメール配信制御方法。
【請求項３】
前記固有情報を生成するステップが、
前記メールアドレスおよび前記サービスコードをパラメータとして含む、当該メールアドレスへのメール配信を一意的に特定する固有ＵＲＬを生成するステップを有することを特徴とする請求項２に記載のメール配信制御方法。
【請求項４】
前記固有情報を生成するステップが、
さらに、前記メールアドレスに基づき、所定の関数を利用して、当該メールアドレスを一意的に特定するトークンを生成するステップと、
前記トークンを含む固有ＵＲＬを生成するステップとを有し、
さらに、受信クライアントからの、前記ネットワークを介して、前記固有ＵＲＬを用いたアクセスに応答して、前記固有ＵＲＬ中のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、前記固有ＵＲＬ中のトークンとを照合するステップを備え、
前記トークンが一致した場合に、メールアドレスおよびサービスコードの組を、前記サービス拒否テーブルに追加することを特徴とする請求項３に記載のメール配信制御方法。
【請求項５】
さらに、前記サービス拒否テーブル中の前記メールアドレスおよび受信の拒否にかかる情報のカテゴリを、選択的に削除するステップを備えたことを特徴とする請求項１ないし４の何れか一項に記載のメール配信制御方法。
【請求項６】
前記選択的に削除するステップが、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリが前記サービス拒否テーブルに記憶されてから、所定期間を経過した場合に実行されることを特徴とする請求項５に記載のメール配信制御方法。
【請求項７】
さらに、メール受信を拒否するユーザに関して、その拒否を解除し、メール配信を再開するまでの期間を示す情報を、前記受信クライアントから受理するステップと、
前記サービス拒否テーブルに、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリと関連付けて、前記期間或いは再開時を示す情報を記憶するステップとを備えたことを特徴とする請求項５または６に記載のメール配信制御方法。
【請求項８】
さらに、メール受信を拒否したメールアドレスに対して、特定の送信者からのメール受信の再開を求めるための個別再開情報を生成するステップと、
前記送信クライアントに、メール受信を拒否したメールアドレス、および、前記個別再開情報を通知するステップと、
前記送信クライアントから受信クライアントを経て、前記受信クライアントから伝達された個別再開情報に基づき、送信者のメールアドレス、受信者のメールアドレスを特定するステップと、
前記サービス拒否テーブル中、前記受信者のメールアドレスに関連付けて、個別にメール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶するステップとを備えたことを特徴とする請求項１ないし７の何れか一項に記載のメール配信制御方法。
【請求項９】
さらに、前記受信者のメールアドレス宛てに、前記送信者からのメール受信の再開を確認するためのメールを送信するステップを備え、
前記送信したメールに対する前記受信者の応答の受理があった場合に、前記サービス拒否テーブル中に、メール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶するステップが実行されることを特徴とする請求項８に記載のメール配信制御方法。
【請求項１０】
前記個別再開情報を生成するステップが、
前記送信者のメールアドレスおよび受信者のメールアドレスをパラメータとして含む、当該送信者から受信者へのメール送信を一意的に特定する個別再開用固有ＵＲＬを生成するステップを有し、
前記個別再開ＵＲＬの伝達により、送信者および受信者のメールアドレスが特定されることを特徴とする請求項８または９に記載のメール配信制御方法。
【請求項１１】
前記固有情報を生成するステップが、
さらに、前記送信者のメールアドレスに基づき、所定の関数を利用して、当該送信者のメールアドレスを一意的に特定する送信者特定用のトークンを生成するステップと、
前記受信者のメールアドレスに基づき、所定の関数を利用して、当該受信者のメールアドレスを一意的に特定する受信者特定用のトークンを生成するステップと、
双方のトークンを含む個別再開用固有ＵＲＬを生成するステップとを有し、
受信クライアントからの、前記個別再開用固有ＵＲＬを用いたアクセスに応答して、前記個別再開用固有ＵＲＬ中の受信者のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、前記個別再開用固有ＵＲＬ中の受信者特定用のトークンとを照合するとともに、前記個別再開用固有ＵＲＬ中の送信者のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、個別再開用固有ＵＲＬ中の送信者特定用のトークンとを照合するステップを備え、
双方のトークンが一致した場合に、サービス拒否テーブル中、前記受信者のメールアドレスに関連付けて、個別にメール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶することを特徴とする請求項１０に記載のメール配信制御方法。
【請求項１２】
さらに、メール受信を拒否するユーザに関して、当該ユーザにより選択された、受信の拒否にかかる情報のカテゴリを受理するステップを備え、
前記サービス拒否テーブルに、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリが記憶されることを特徴とする請求項１ないし１１の何れか一項に記載のメール配信制御方法。
【請求項１３】
さらに、所定の条件が成立した場合に、送信者のメールアドレスからの依頼を拒否するために、依頼拒否リストを生成するステップを備えたことを特徴とする請求項１ないし１２の何れか一項に記載のメール配信制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ウェブサイトを介したメール配信に関し、より詳細には、受信者が望まないメールの配信を制限するメール配信制御の手法に関する。
【０００２】
【従来の技術】
インターネットを利用して所望の情報（たとえば、グルメ情報、ショッピング、ニュース）などを取得する種々の情報配信サイトが存在する。これら情報配信サイトにおいては、ユーザが操作するクライアントマシンの要求に応答して、必要な情報を含むコンテンツを配信する。
【０００３】
上記情報配信サイトでは、コンテンツを配信するだけでなく、ユーザが指定した情報（たとえば、パッケージツアーやレストランの情報、ニュースなど）を、他のユーザにメールにて配信するサービスが実現されている。このサービスを享受するために、ユーザは、クライアントマシンのブラウザにコンテンツが表示されている状態で、所望の記事を指定した上で、ブラウザ上に表示された画像中のメール送信のためのボタンをオンする。
【０００４】
これに応答して、サイトからはメール配信のためのダイアログがクライアントマシンに配信される。ユーザは、送信先のメールアドレス（他のユーザのメールアドレス）、メッセージ、および、サイトポリシにしたがって必要な場合には、送信者の氏名やメールアドレスを入力した上で、入力済みのダイアログを、サイトのサーバに対して送信する。メールサーバは、ＨＴＴＰサーバを介して、必要な情報（送信すべきコンテンツ或いはテキストや、送信先のメールアドレス）を受理し、メールを作成して、メールアドレス宛てに送信する。このようなサービスにより、送信者は、複数の相手に、自分の伝えたい情報を通知することができる。
【０００５】
【発明が解決しようとする課題】
特に、上述したメール配信サービスにおいて、送信者（ユーザ）のメールアドレスの記入を不要としている場合には、送信者匿名の状態で、多数のメールを送信することが可能であり、このサービスがスパムメール発信源として悪用されるという可能性があった。その一方、スパムメールを防止するためには、送信者の氏名やメールアドレスを必須入力事項とした上で、そのメールアドレスを用いて、送信者と実際に連絡が取れることを確認した上で、メールを配信することも考えられる。しかしながら、この場合には、善意のユーザを含む全ユーザに、氏名やメールアドレスなどの開示を求める必要があり、気軽にサービスを利用することを阻害する要因となり得る。
【０００６】
また、従来、受信者が、上記メール配信サービスによる、メールの受信を拒否したい場合、当該ユーザは、電話等を利用してサイトのオペレータに直接コンタクトし、或いは、別途、メールを送信して、受信拒否の意思を表明する必要があり、受信者が、別途何らかの手続きを行わなければならないという問題点もあった。
さらに、いわゆるスパムメールの送信源から、上記メール配信サービスを利用したメール送信については、サービスの利用自体を拒否できる枠組みが作られるのが望ましい。
【０００７】
本発明は、送信者が気軽にサービスを利用でき、かつ、メール配信が不要な受信者も、煩雑な手続き無く受信拒否の手続きをなすことができるシステムを提供することを目的とする。
また、本発明は、いわゆるスパムメールの送信源からの、メール配信サービスの利用要求を拒否することができるシステムを提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明の目的は、コンテンツを提供するサーバにおいて、送信クライアントからの依頼にしたがって、所定の情報を含むメールを、１以上の送信先に送信するメール配信制御方法において、前記送信クライアントから、ネットワークを介して、少なくとも１以上の送信先のメールアドレス、および、送信クライアントからの送信すべき情報を指定するための情報を受理し、前記送信先のメールアドレスのリストを生成するステップと、メール受信を拒否するユーザに関するメールアドレスおよび受信の拒否にかかる情報のカテゴリを記憶したサービス拒否テーブルを参照して、前記メールアドレスおよび送信すべき情報のカテゴリと一致するものを見出し、当該メールアドレスを、前記１以上のメールアドレスのリストから除外するステップと、前記所定のメールアドレスが除外されたリストに基づき、前記送信すべき情報、および、メール受信を拒否するためにメール送信および送信先であるメールアドレスを特定する固有情報を含むメールを生成ステップと、生成されたメールを、送信先に向けてそれぞれ送信するステップと、前記メールの送信先となった受信クライアントから、前記ネットワークを介して、前記固有情報によるアクセスを受理するステップと、前記固有情報にしたがって、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリを、前記サービス拒否テーブルに追加するステップとを備えたことを特徴とするメール配信制御方法により達成される。
【０００９】
本発明によれば、メールを受信したユーザが、受信したメールに含まれる固有情報を利用してアクセスすることにより、コンテンツを提供するサーバが、固有情報にしたがって、当該ユーザのメールアドレスへの、当該サーバを介したメール送信を行わないよう、サービス拒否テーブルに、前記メールアドレス及び受信の拒否にかかる情報のカテゴリを登録する。これにより、送信者が、当該メールアドレスを有するユーザに、コンテンツを提供するサーバを利用して、ある情報、たとえば、コンテンツ中の所定の記事などをメールにて送りたい場合であっても、受信者であるユーザの意思にしたがって、当該メールの送信を防止することができる。
【００１０】
たとえば、サーバにて提供されるコンテンツには、レストランガイド、ショップガイド、商品紹介、旅行ガイド、ニュースなどが含まれる。また、コンテンツを提供するサーバは、単一のサーバから構成されている必要は無い。たとえば、ＨＴＴＰサーバ、メールサーバ、および、前記サービス拒否テーブルを含み、送信者がメールを送信しようとするメールアドレスのリストから、所定のメールアドレスを除去する処理を実行するメール制御サーバからなるサーバ群が設けられていても良い。
【００１１】
好ましい実施態様においては、前記送信すべき情報を指定するための情報が、前記コンテンツの内容を示すサービスコードであり、かつ、前記サービス拒否テーブルに、メールアドレスおよびサービスコードの組が記憶される。サービスコードを、サービスのカテゴリにしたがって設定することにより、特定のサービスについてのメール配信のみを拒否することが可能となる。
【００１２】
また、好ましい実施態様においては、固有情報を生成するステップが、前記メールアドレスおよび前記サービスコードをパラメータとして含む、当該メールアドレスへのメール配信を一意的に特定する固有ＵＲＬを生成するステップを有する。この実施態様によれば、メール中に固有ＵＲＬを記述しておき、受信クライアントにおいて、ユーザがメール中の固有ＵＲＬを指定することで、一定のサービスに関するメール配信を拒否することが可能となる。
【００１３】
より好ましい実施態様においては、前記固有情報を生成するステップが、さらに、前記メールアドレスに基づき、所定の関数を利用して、当該メールアドレスを一意的に特定するトークンを生成するステップと、前記トークンを含む固有ＵＲＬを生成するステップとを有し、さらに、受信クライアントからの、前記ネットワークを介して、前記固有ＵＲＬを用いたアクセスに応答して、前記固有ＵＲＬ中のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、前記固有ＵＲＬ中のトークンとを照合するステップを備え、前記トークンが一致した場合に、メールアドレスおよびサービスコードの組を、前記サービス拒否テーブルに追加するように構成されている。
【００１４】
この実施態様によれば、固有ＵＲＬ中のトークンと、メールアドレスから再生成したトークンとを照合し、これらが一致した場合のみ、真正なユーザからのメール配信の拒否と判断する。したがって、いわゆるなりすましによるメール配信の拒否を防止することが可能となる。
【００１５】
また、別の好ましい実施態様においては、さらに、前記サービス拒否テーブル中の前記メールアドレスおよび受信の拒否にかかる情報のカテゴリを、選択的に削除するステップを備えている。上記削除するステップは、たとえば、メール受信拒否を解除するための第２の固有ＵＲＬを作成し、配信するメール中に当該第２の固有ＵＲＬを記述し、当該第２の固有ＵＲＬを利用したアクセスに応答して実行されても良い。或いは、サービス拒否テーブル中に情報を記憶する期間を設定し、その期間の経過後に、所定のものを削除しても良い。
【００１６】
より好ましい実施態様においては、前記選択的に削除するステップが、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリが前記サービス拒否テーブルに記憶されてから、所定期間を経過した場合に実行される。これにより、たとえば、１ヶ月、６ヶ月などの期間が経過すると、当該メールアドレスの受信者へのメール配信が再開される。
【００１７】
さらに、メール受信を拒否するユーザに関して、その拒否を解除し、メール配信を再開するまでの期間を示す情報を、前記受信クライアントから受理するステップと、前記サービス拒否テーブルに、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリと関連付けて、前記期間或いは再開時を示す情報を記憶するステップとを備えているのが望ましい。これにより、受信者であるユーザは、メール配信の再開までの期間を指定することができる。この期間には、たとえば、「無限」、つまり、永久にメール配信を拒否することを意味するものを含んでも良い。
【００１８】
別の好ましい実施態様においては、さらに、メール受信を拒否したメールアドレスに対して、特定の送信者からのメール受信の再開を求めるための個別再開情報を生成するステップと、前記送信クライアントに、メール受信を拒否したメールアドレス、および、前記個別再開情報を通知するステップと、前記送信クライアントから受信クライアントを経て、前記受信クライアントから伝達された個別再開情報に基づき、送信者のメールアドレス、受信者のメールアドレスを特定するステップと、前記サービス拒否テーブル中、前記受信者のメールアドレスに関連付けて、個別にメール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶するステップとを備えている。
【００１９】
この実施態様によれば、基本的にはメール受信を拒否したいが、特定の送信者からの依頼に基づくメールだけは受信したいようなユーザに対して、柔軟に対応することができる。つまり、ユーザは、所望の送信者からの依頼によるメールのみを受信することが可能となる。なお、個別再開情報として、再開を依頼するためのサイトのＵＲＬ、送信者および受信者が一意的に特定される、後述する個別再開固有ＵＲＬなどを利用することができる。
【００２０】
より好ましい実施態様においては、さらに、前記受信者のメールアドレス宛てに、前記送信者からのメール受信の再開を確認するためのメールを送信するステップを備え、前記送信したメールに対する前記受信者の応答の受理があった場合に、前記サービス拒否テーブル中に、メール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶するステップが実行される。
【００２１】
この実施態様によれば、メール受信の再開を依頼した受信者に対して、本人確認の意味で、当該受信者のメールアドレス宛てにメールを送信し、その応答を受理したことを条件に、これ以降の処理が実行される。これにより、送信者や上記個別再開情報を取得した第三者が、受信者になりすまして、上記メール受信の再開を依頼し、その依頼に応答して、当該送信者の依頼によるメール配信が再開されることを防止することができる。　より好ましい実施態様においては、前記個別再開情報を生成するステップが、前記送信者のメールアドレスおよび受信者のメールアドレスをパラメータとして含む、当該送信者から受信者へのメール送信を一意的に特定する個別再開用固有ＵＲＬを生成するステップを有し、前記個別再開ＵＲＬの伝達により、送信者および受信者のメールアドレスが特定される。これにより、受信者は、個別再開用固有ＵＲｌにアクセスするだけで、特定の送信者からの依頼に基づくメールの受信を再開することができる。
【００２２】
より好ましくは、前記固有情報を生成するステップが、さらに、前記送信者のメールアドレスに基づき、所定の関数を利用して、当該送信者のメールアドレスを一意的に特定する送信者特定用のトークンを生成するステップと、前記受信者のメールアドレスに基づき、所定の関数を利用して、当該受信者のメールアドレスを一意的に特定する受信者特定用のトークンを生成するステップと、双方のトークンを含む個別再開用固有ＵＲＬを生成するステップとを有し、受信クライアントからの、前記個別再開用固有ＵＲＬを用いたアクセスに応答して、前記個別再開用固有ＵＲＬ中の受信者のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、前記個別再開用固有ＵＲＬ中の受信者特定用のトークンとを照合するとともに、前記個別再開用固有ＵＲＬ中の送信者のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、個別再開用固有ＵＲＬ中の送信者特定用のトークンとを照合するステップを備え、双方のトークンが一致した場合に、サービス拒否テーブル中、前記受信者のメールアドレスに関連付けて、個別にメール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶する。これにより、送信者および受信者の双方が真正であることを担保することが可能となる。
【００２３】
また、別の好ましい実施態様においては、さらに、メール受信を拒否するユーザに関して、当該ユーザにより選択された、受信の拒否にかかる情報のカテゴリを受理するステップを備え、前記サービス拒否テーブルに、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリが記憶される。たとえば、受信者であるユーザは、すべてのカテゴリの受信の拒否、或いは、特定のカテゴリの受信の拒否を選択することが可能となる。
【００２４】
別の好ましい実施態様においては、さらに、所定の条件が成立した場合に、送信者のメールアドレスからの依頼を拒否するために、依頼拒否リストを生成するステップを備えている。たとえば、ある送信者のメールアドレスに関して、クレーム数、メール受信の拒否を表明したメールアドレスの数などが一定数に達したときには、当該送信者からの依頼によるメール配信自体を拒否する。
【００２５】
【発明の実施の形態】
以下、添付図面を参照して、本発明の実施の形態につき説明を加える。図１は、本発明の実施の形態にかかるメール配信のためのシステムを概略的に示すブロックダイヤグラムである。図１に示すように、種々のクライアントマシン１２、１６−１、１６−２、・・・が、インターネット１８に接続されている。また、インターネット１８には、あるサイト１４を構成するサーバ群が接続される。サーバ群は、クライアントマシンにコンテンツを提供するＨＴＴＰサーバ２４と、インターネット１８を介してクライアントマシンにメールを送信するメールサーバ２６と、送信すべきメールに関して種々の処理を実行するメール制御サーバ２８を含む。
【００２６】
本実施の形態においては、あるクライアントマシン１２がサイトにアクセスしてコンテンツを閲覧し、当該コンテンツ中の所望の情報を、他のクライアントマシンにメールで通知できるようになっている。そこで、本実施の形態において、メールの送信を求めるクライアントマシンを、便宜上、送信クライアント１２と称し、メールを受信するクライアントマシンを、便宜上、受信クライアント１６と称する。図１においては、２つの受信クライアント１６−１、１６−２が図示されているが、実際には、送信クライアント１２は、サイトにおける制限の範囲内で、任意の電子メールアドレスを宛先として、メールの送信を求めることができる。
【００２７】
図２は、本実施の形態にかかるメール制御サーバ２８の構成を示すブロックダイヤグラムである。メール制御サーバ２８は、メールサーバ２６から、送信クライアント１２がメールの送信を要求した送信先のメールアドレスから、受信を拒否するものを除外する処理を実行する。
【００２８】
図２に示すように、メール制御サーバ２８は、メールサーバからメールアドレスのリスト（初期的な送信リスト）およびサービスの内容を示すサービスコードを受理して、送信リスト中のメールアドレスを、後述するサービス拒否リスト（サービス拒否テーブル）４４と照合する照合処理部３０と、サービス拒否リスト４４を含むデータベース（ＤＢ）３２と、照合結果にしたがって、送信リストを修正する送信リスト修正部３４と、修正されたリスト中のメールアドレスに対する固有のＵＲＬ（固有ＵＲＬ）を生成、追加するＵＲＬ生成・追加部３６と、受信クライアント１３からのメール受信拒否を登録するサービス拒否登録部３８と、メール受信の再開を登録するサービス再開制御部４０と、送信クライアントから受信クライアントへのメールの送信ログを記憶する送信ログＤＢ４２とを備えている。
【００２９】
このように構成されたメール制御サーバ２８を利用した受信クライアントへのメール配信につき、図３を参照して説明を加える。
送信クライアント１２のブラウザ２０が、ＨＴＴＰサーバ２４に、コンテンツ配信を要求すると、ＨＴＴＰサーバ２４は、要求されたコンテンツを、インターネット１８を介して送信クライアント１２に返し、ブラウザ２０によりコンテンツが送信クライアント１２の表示装置の画面上に表示される。このような処理が、コンテンツの閲覧中に繰り返される。本実施の形態において、コンテンツ中には、所定のサービス、たとえば、レストラン紹介、パッケージツアーの紹介、ニュース記事などの各々を、メールにて、他のクライアントマインに通知することができる。たとえば、コンテンツ中の所定の単位に対応させて、「この＊＊（たとえば、レストラン、ツアー、ニュース）を友だちに知らせる」という記述を含ませ、これをユーザが指定することにより、メール送信依頼が、ＨＴＴＰサーバ２４に伝達される。
【００３０】
クライアントマシン１２からのメール送信依頼は、ブラウザ２０からＨＴＴＰサーバ２４を介してメールサーバ２６に伝達される（ステップ３０１）。メール送信依頼は、ＨＴＴＰサーバ２４が、送信クライアント１２に図４に示すような入力ダイアログを送信し、送信クライアント１２にて、入力欄に必要な事項を記入した上で、これを返信することにより実現される。図４は、入力ダイアログの一例を示す図である。入力ダイアログ４００には、たとえば、送信先のメールアドレスの入力欄（たとえば、符号４０１参照）、送信するユーザの名前の入力欄（符号４０２参照）およびメッセージ入力欄（符号４０３）が含まれる。これらのうち、送信するユーザの名前の記入欄およびメッセージ入力欄への記入は必須とせず、これらを空欄のまま、「送信」ボタン４０４がクリックされても良い。その一方、ユーザの名前や当該ユーザのメールアドレスを必須入力項目としても良いことは明らかである。
【００３１】
メールサーバ２６は、メール送信依頼の受理に応答して、メールアドレスのリスト（送信リスト）および配信する情報の内容を示す情報を、メール制御サーバ２８に伝達する（ステップ３０２）。サイト１４において、コンテンツは、車、グルメ（レストラン紹介）、旅行、教育、趣味、ニュースなど、サイト中のコンテンツを概略的に分ける大分類、および、大分類にしたがったカテゴリ中の小分類に分けられる。たとえば、図８に示すように、「車」という大分類のカテゴリには、「新車情報」、「中古車情報」、「試乗」という小分類のカテゴリが含まれ、「旅行」という大分類のカテゴリには、「国内旅行」、「海外旅行」という小分類のカテゴリが含まれる。また、たとえば、「グルメ」や「ニュース」には、大分類のカテゴリのみが存在する。大分類、小分類のカテゴリには、それぞれ、対応するサービスコードが割り当てられている。
【００３２】
そこで、メールサーバ２６は、ユーザがメール送信を要求した情報のカテゴリに基づき、サービスコードを特定し、これを、メールアドレスのリスト（送信リスト）ともに、メール制御サーバ２８に伝達する。
メール制御サーバ２８は、後述するように、ＤＢ３２中のサービス拒否リスト４４を参照して、メール受信を拒否するユーザのメールアドレスを特定し、そのようなユーザにはメールを送信しないよう、送信リストを修正し（ステップ３０３）、メールサーバ２６に返す（ステップ３０４）。なお、ステップ３０４では、各メールアドレスに対応した固有ＵＲＬも、メールサーバ２６に伝達される。この固有ＵＲＬについては、メール制御サーバ２８の処理の説明に関連して詳述する。
【００３３】
メールサーバ２６は、修正された送信リストにあるメールアドレスのそれぞれを宛先とするメールを生成し（ステップ３０５）、これらメールを送信する（ステップ３０６）。これにより、受信クライアント１６−１、１６−２、・・・のメーラ２２−１、２２−２、・・・により、受信者は自己に宛てられたメールの受信及びそのメールの内容を知ることができる。その後、メールサーバ２６は、メール制御サーバ２８にメール送信が完了したことを通知する（ステップ３０７）。メール制御サーバ２８は、メール送信時刻や送信先のメールアドレスなどを含む送信ログを、送信ログＤＢ４２に記録する（ステップ３０８）。その一方、送信が完了した旨を示す通知、例えば通知メールを、ＨＴＴＰサーバ２４を介して、送信クライアント１２に伝達することもできる（ステップ３０９）。このステップ３０９の処理は必須ではなく、送信クライアントのメールアドレスを特定できない場合、例えば入力を強要しない場合は、通知メールが伝達されることは無い。
【００３４】
次に、メール制御サーバ２８によるリスト修正処理（ステップ３０３）につき、図５を参照してより詳細に説明を加える。メール制御サーバ２８の照合処理部３０は、サービス拒否リスト４４を参照して、送信リスト中の各メールアドレスおおびサービスコードの組と、サービス拒否リスト４４中のデータの組とが合致するものを検索する（ステップ５０１）。
【００３５】
本実施の形態において、メール受信の拒否は、サービスコードにて特定されるカテゴリごとに設定できるようになっている。このため、サービス拒否リスト４４には、メールアドレスおよび当該メールアドレスに関してメールを送信すべきでない情報のサービスコードが、関連付けられ、データの組として記憶されている。送信リスト中のメールアドレスと、今回送信される情報のカテゴリを示すサービスコードの組と、サービス拒否リスト４４中のデータの組とが一致する場合には、当該メールアドレスが、送信リスト修正部３４により、送信リストから削除される（ステップ５０２）。
【００３６】
次いで、ＵＲＬ生成・追加部３６は、送信リストに残ったメールアドレスの各々を特定するための種々のパラメータを生成し、当該パラメータを含む、各メールアドレスの固有ＵＲＬを生成する（ステップ５０３）。以下に、固有ＵＲＬにつき説明を加える。
ＵＲＬ生成・追加部３６は、メールアドレスに基づき、所定の関数を利用して、当該メールアドレスを一意的に特定する他の文字列を生成する。これは、後のサービス拒否登録の処理において、ユーザを特定するトークンとして利用される。
【００３７】
ＵＲＬ生成・追加部３６は、サービスコード、ユーザのメールアドレスおよび上述のように生成した文字列からなるＵＲＬを、固有ＵＲＬとする。たとえば、固有ＵＲＬは、以下のような構成となる。
ｈｔｔｐ：／／ｗｗｗ．＊＊＊．ｃｏｍ／・・・／＄＄＿Ａ＿＄＄／＄＄＿Ｂ＿＄＄／＄＄＿Ｃ＿＄＄
パラメータについて説明すると、「＄＄＿Ａ＿＄＄」はサービスコード、「＄＄＿Ｂ＿＄＄」はユーザのメールアドレス、「＄＄＿Ｃ＿＄＄」はトークンとして利用される文字列である。この固有ＵＲＬが、受信クライアント１６から送られると、ユーザ（メールアドレス）およびサービスコードが特定されるとともに、メールアドレスから、上記関数を利用して文字列を再生成し、固有ＵＲＬ中の文字列と照合を図ることにより、メールを受信したユーザからのアクセスであることを確認することができる。
【００３８】
次いで、メール制御サーバ２８は、修正された送信リストと、各メールアドレスに対応する固有ＵＲＬとを、メールサーバ２６に返信する（ステップ５０４）。
先に述べたように、メールサーバ２６は、メール制御サーバ２８から返信された送信リストを参照して、送信リスト中のメールアドレス宛てのメールを生成する。ここで、メール中には宛先のメールアドレスに対応した固有ＵＲＬが含まれる。
【００３９】
図６（ａ）は、メールサーバ２６から受信クライアント１６に宛てて送信されるメールの例を示す図である。図６に示すように、メール６００中には、本文６０１の他、メール制御サーバ２８にて生成された固有ＵＲＬ（符号６０２参照）が記述される。
受信クライアント１６のユーザが、上記固有ＵＲＬを指定することにより、後述するサービス拒否登録の処理が実行される。図３の処理にしたがって、メールサーバ２６から送信されたメールを受信したユーザが、当該メールを不要と感じ、これ以降、同種のメールの受信を拒否したいと考えた場合には、受信クライアント１６を操作して、図６（ａ）に示す固有ＵＲＬ６０２を指定する。図７は、受信クライアントからの要求に基づくサービス拒否登録の処理を示すフローチャートである。
【００４０】
上述したユーザによる固有ＵＲＬの指定により、受信クライアント１６からオプトアウト要求がＨＴＴＰサーバ２４を介してメール制御サーバ２８に伝達される。メール制御サーバ２８のサービス拒否登録部３８は、オプトアウト要求にかかる固有ＵＲＬを参照して、当該固有ＵＲＬ中のメールアドレスから、所定の関数を利用した文字列を生成し、前記固有ＵＲＬ中の文字列（＄＄＿Ｃ＿＄＄）と照合する（ステップ７０２）。ここで、両者が一致すれば、なりすましではなく、メールを受理した真正なユーザ（つまりユーザ本人）からのアクセスであると判断される。
【００４１】
メールを受理したユーザ本人からのアクセスであると判断された場合には、メール制御サーバ２８からＨＴＴＰサーバ２４を介して、メール配信の停止（サービス拒否）の確認を求めるコンテンツが、受信クライアント１６に与えられる（ステップ７０３）。図６（ｂ）に示す画像６１０は、このようなコンテンツの例を示す。ここで、ユーザが受信クライアント１６を操作して、「登録」ボタン６１１をオンすると、配信停止登録の確認がＨＴＴＰサーバ２４を介してメール制御サーバ２８に伝達される（ステップ７０４）。なお、メール配信の停止の確認を求めるコンテンツの配信に際しては、受信クライアント１６からのアクセス情報を参照して、当該受信クライアントの機種（たとえば、パーソナルコンピュータ、携帯電話、ＰＤＡなど）を判別し、受信クライアントの表示装置の画面上に適したコンテンツを生成するのが望ましい。
【００４２】
メール制御サーバ２８は、配信停止登録の確認の受理に応答して、オプトアウト要求中、固有ＵＲＬ中のメールアドレス（＄＄＿Ｂ＿＄＄）およびサービスコード（＄＄＿Ａ＿＄＄）を関連付けて、ＤＢ３２中のサービス拒否リスト４４に追加する（ステップ７０５）。その後、ＨＴＴＰサーバ２４を介して、配信停止登録が完了したことを示す通知が受信クライアント１６に伝達される。
これにより、送信クライアント１２から、メール送信要求があった場合でも、特定のサービスコードについて、あるメールアドレスのユーザが、その受信を拒否している場合には、当該ユーザには、メールを送信することを防止できる。
【００４３】
次に、配信の再開について説明を加える。たとえば、あるサービスコードに対応するサービスについて、メールの配信を拒否しているユーザが、当該サービスに関するメールの配信を再開する際の処理につき、簡単に説明する。
たとえば、ユーザは電話やメールなどにより、サイトにコンタクトをとって、オペレータがメール制御サーバ２８を操作して、ユーザに指示された、メールアドレスおよびサービスコードの組を、サービス拒否リスト４４から削除する。これにより、メール配信が再開される。
【００４４】
或いは、図６（ａ）に示すような、固有ＵＲＬのほか、受信を再開するための第２の固有ＵＲＬを、「受信を再開する際にはクリックする」ことを示す記述とともに配置しても良い。この第２の固有ＵＲＬにおいては、たとえば、サブドメイン名やファイル名は、先に説明した固有ＵＲＬと異なるが、当該固有ＵＲＬと同様に、サービスコード、ユーザのメールアドレスおよびトークンとして利用される文字列を含む。
【００４５】
ユーザがこの第２の固有ＵＲＬをクリックすると、メール制御サーバ２８のサービス再開制御部４０が、ＨＴＴＰサーバ２４を介して、メールアドレスおよび第２の固有ＵＲＬを受理し、図７に相当する処理を実行して、ＤＢ３２のサービス拒否リスト４４から、要求にかかるメールアドレスとサービスコードの組を、削除すればよい。すなわち、第２の固有ＵＲＬを参照してユーザを確認し（ステップ７０２参照）、配信開始の確認の一連の手続き（ステップ７０３、７０４参照）の後、メールアドレスとサービスコードの組を、サービス拒否リスト４４から削除すればよい。このような構成にすれば、ユーザは、サイトに電話などにて直接コンタクトをとり、或いは、別途メールを作成することなく、サービスの再開をサイト側に求めることが可能となる。
【００４６】
本実施の形態によれば、送信クライアントからの送信要求に応えて、サイト側（メールサーバ）から送信されたメール中に、メール受信を拒否する意思を示すための固有ＵＲＬを含めておく。受信クライアントのユーザは、当該固有ＵＲＬを指定することで、一定のサービスに関して、上記メール送信を拒否することが可能となる。
【００４７】
次に、本発明の第２の実施の形態につき説明を加える。第２の実施の形態においても、図１に示すように、送信クライアント１２からのメール配信要求に応答して、サイト１４を構成するサーバ群においてメールが作成され、指定された送信先に向けて、メールが送信される。受信クライアント１６においては、送信先のユーザが、それぞれ、サイト１４からのメールを受理し、当該メールを読むことができる。また、第２の実施の形態においては、メール配信サービスを利用するユーザ（送信者）に、送信者自身のメールアドレスの入力を求めるようになっている。
【００４８】
図９は、第２の実施の形態にかかるメール制御サーバ２８の構成を示すブロックダイヤグラムである。図９において、図２に示す第１の実施の形態と同一の部材には同一の符号を付す。図９に示すように、第２の実施の形態にかかるメール制御サーバ２８は、照合処理部３０、ＤＢ３２、送信リスト修正部３４、ＵＲＬ生成・追加部３６、サービス拒否登録部３８、サービス再開制御部４０、送信ログＤＢ４２に加えて、送信者に関する種々の処理を実行する送信者管理部５０および依頼拒否リストＤＢ５２を備えている。
【００４９】
送信者管理部５０は、サイトのオペレータが入力した指示や、サービス拒否リストの参照結果に基づいて、依頼拒否リストＤＢ５２中の依頼拒否リストに、ユーザのメールアドレスを追加し、或いは、所定の条件が成立した場合には、依頼拒否リスト中のメールアドレスを削除する処理を実行する。
本実施の形態において、依頼拒否リストは、メール配信サービスの利用者、つまり、メールの送信を希望するユーザに対して、そのサービスの利用を拒否するために利用される。
【００５０】
図１０は、第２の実施の形態における送信クライアント１２からのメール送信依頼に伴って実行される処理を示すフローチャートである。送信クライアント１２のブラウザ２０とＨＴＴＰサーバ２４との間では、コンテンツ配信要求およびコンテンツ配信が繰り返される。メール送信依頼においては、第１の実施の形態と同様に、図４に示すようなダイアログが送信クライアント１２に与えられ、送信クライアント１２から、必要事項が入力されたダイアログが、送信クライアント１２から送信されることにより実現される。なお、第２の実施の形態においては、送信するユーザのメールアドレス（送信者メールアドレス）の入力が必須となる。また、第２の実施の形態においては、真正な送信者であることを確認するため、つまり、送信者のなりすましを防止するために、メールサーバ２６から、送信者メールアドレス宛てに、メール配信サービスの利用を確認するメールを送信し、当該送信者から、サービス利用の確認を示す情報を受理することを条件として、図１０に示す処理が実行される。
【００５１】
図１０に示すように、送信クライアント１２のブラウザ２０から、メール送信依頼が、ＨＴＴＰサーバ２４を介してメールサーバ２６に伝達されると（ステップ１００１）、ダイアログ中の送信者メールアドレスが、メール制御サーバ２８に伝達される（ステップ１００２）。メール制御サーバの送信者管理部５０は、依頼拒否リストＤＢ５２の依頼拒否リスト中のメールアドレスと、送信者メールアドレスとを照合し、送信者メールアドレスが、依頼拒否リスト中に掲載されているか否かを判断する（ステップ１００３）。
【００５２】
依頼拒否リスト中に送信者メールアドレスが掲載されていた場合には、リストに掲載されたことを示す照合結果がメールサーバ２６に返される（ステップ１００４）。これに応答して、メールサーバ２６は、サービス利用の拒否を送信クライアントに通知する（ステップ１００５）。
その一方、図１１に示すように、メール送信依頼（ステップ１１０１）、送信者メールアドレスのメール制御サーバ２８への伝達（ステップ１１０２）、および、メール制御サーバ２８における照合（ステップ１１０３）の結果、送信者メールアドレスが、依頼拒否リスト中に掲載されていなかった場合、メール制御サーバ２８から、リストに掲載されていないことを示す照合結果が、メールサーバ２６に返される（ステップ１１０４）。
【００５３】
メールサーバ２６は、送信者メールアドレスが、リストに掲載されていないことに応答して、送信者メールアドレスに宛てて、サービス利用意思を確認するためのメール（確認メール）を送信する（ステップ１１０５）。この確認メールには、たとえば、ユーザが送信しようとした情報、送信先のメールアドレスおよびサービス利用の確定を指示するためのＵＲＬが含まれる。
【００５４】
ユーザが、上記メール中のＵＲＬを指定すると、確定指示がＨＴＴＰサーバ２４を介して、メールサーバ２６に伝達される（ステップ１１０６）。これにより、第１の実施の形態と同様に、送信先のメールアドレスおよびサービスコードがメール制御サーバ２８に伝達され、リスト修正処理（図３のステップ３０３および図５参照）が実行される。
【００５５】
以下、メール制御サーバ２８からメールサーバ２６への送信リストおよび固有ＵＲＬの返送（ステップ３０４）、各受信者へのメールの生成（ステップ３０５）、メール送信（ステップ３０６）、メール完了通知の伝達（ステップ３０７、３０９）、および、送信ログの記録（ステップ３０８）の処理は、第１の実施の形態と同様である。なお、第２の実施の形態においては、送信ログにおいて、送信者メールアドレスと、送信先のメールアドレス群とが関連付けて記録される。
【００５６】
さらに、第２の実施の形態においては、メール送信完了通知が、メールを送信することができた送信先のメールアドレスと、メール送信が拒否されたメールアドレスとを示すリストを含む。また、第２の実施の形態において、メール完了通知（図３のステップ３０７参照）に応答して、メール制御サーバ２８は依頼拒否リスト５２中、ある送信者メールアドレスに関するメール送信が拒否されたメールアドレス数（サービス拒否表明アドレス数）を更新する処理を実行する。これについては、後述する。
【００５７】
次に、第２の実施の形態にかかる依頼拒否リストＤＢの依頼拒否リストへの、送信者メールアドレスの追加や削除に関する処理を説明する。図１２は、依頼拒否リストの一例を示す図である。図１２に示すように、依頼拒否リスト１２００においては、送信者アドレスに関連付けられた、「依頼拒否フラグ」、「拒否開始日時」、「クレーム数」、「サービス拒否表明アドレス数」、「平均送信間隔」および「単位時間送信数」などの項目のそれぞれに値が付与される。
【００５８】
「依頼拒否フラグ」は、「１」或いは「０」の値を有する。この値が「１」であれば、関連する送信者メールアドレスからのサービス利用が拒否される。「拒否開始日時」は、上記「依頼拒否フラグ」の値が「１」に設定された日時を示す。
「クレーム数」は、送信者ユーザアドレスを依頼者とするメール配信に対して、受信者からの電話やメールによる苦情の数を意味する。これは、たとえば、メール制御サーバ２８のオペレータが、入力装置を操作することで、当該送信者メールアドレスに関連付けられた値を更新することができる。「サービス拒否表明アドレス数」は、メール完了通知（図３のステップ３０７）に応答して、メール送信が拒否されたメールアドレスの数、元のサービス拒否表明アドレス数に加えることで値が更新される。これは、ある送信者メールアドレスについて、サービスを利用したメールの受信を拒否したメールアドレスの延べ数を表す。
【００５９】
また、「平均送信間隔」には、サイト１４を利用したメール送信サービスを利用する間隔の平均値が与えられ、「単位時間送信数」は、一定の時間（たとえば１時間）あたりの、サイト１４を利用したメール送信における送信先メールアドレスの平均値が与えられる。これらの値については、送信者管理部５０が、所定のタイミング（たとえば夜間バッチ処理など）で、依頼拒否リスト更新処理を実行し、送信ログＤＢ４２を参照して、平均値を算出し、該当する項目の値を更新すればよい。
【００６０】
図１３は、第２の実施の形態にかかる依頼拒否リスト更新処理を示すフローチャートである。送信者管理部５０は、送信ログＤＢ４２を参照して（ステップ１３０１）、送信ログ中の送信者アドレスを特定する（ステップ１３０２）。次いで、依頼拒否リストＤＢ５２の依頼拒否リスト中、当該送信者メールアドレスに関連するレコードを特定し、当該レコード中の項目の値を更新する（ステップ１３０３）。この値の更新は、上に記載した「平均送信間隔」や「単位時間送信数」の値の更新に対応する。また、送信者メールアドレスが、依頼拒否リスト中に存在しない場合には、新たにその送信者メールアドレスに関するレコードを生成すればよい。
【００６１】
次いで、更新された項目の値と、依頼拒否の条件（拒否条件）とが照合される（ステップ１３０４）。本実施の形態においては、以下の拒否条件が設けられており、何れかに該当する場合には、当該送信者メールアドレスに関する「拒否リスト」が「１」にされる。
（１）「クレーム数」がある一定数に達した場合に、拒否条件により拒否される範囲であると判断される。
（２）「サービス拒否表明アドレス数」がある一定数に達した場合に、拒否条件により拒否される範囲であると判断される。
（３）「平均送信間隔」が、ある一定時間より短くなった場合に、拒否条件により拒否される範囲であると判断される。
（４）「単位時間送信数」が、ある一定数に達した場合に、拒否条件により拒否される範囲であると判断される。
【００６２】
送信者管理部５０は、ある送信者メールアドレスについて、上記（１）〜（４）の何れかに該当する場合、つまり、拒否される範囲であった場合には（ステップ１３０５でイエス（Ｙｅｓ））、当該送信者メールアドレスに関するレコード中、「拒否フラグ」を「１」に設定する（ステップ１３０６）。次いで、メール制御サーバ２８は、「拒否フラグ」が「１」に設定された送信者メールアドレスを宛先に、サービス利用が拒否されることを通知するためのメールの作成を、メールサーバ２６に依頼する。これにより、サービス利用の拒否を通知するメールが、当該送信者メールアドレス宛てに送信される（ステップ１３０７）。本実施の形態においては、サービス利用、つまり、所定の送信先メールアドレス宛てにメールを送信する際に、送信元を確認するためのメールを送信している。したがって、ステップ１３０７におけるメール送信は、送信者の存在を、再度確認する確認することを意図している。
このような処理を、送信ログの末尾までの各送信ログ中の送信者メールアドレスについて繰り返す（ステップ１３０８参照）。
【００６３】
たとえば、図１２において、レコード１２０１の送信者メールアドレスについては、前記（１）〜（４）のいずれの条件にも該当しないため、「依頼拒否フラグ」は「０」となっている。その一方、レコード１２０２の送信者メールアドレスについては、（１）〜（４）の少なくとも１つの条件に該当するため、「依頼拒否フラグ」が「１」となっている。
【００６４】
このように、第２の実施の形態によれば、一定の条件に該当する送信者メールアドレスについて、依頼拒否フラグを「１」とすることにより、当該送信者メールアドレスを依頼元とする、メール送信のサービスを拒否することが可能となる。これにより、スパムメールの発信源と考えられる送信元からのサービスの利用自体を拒否することが可能となる。
【００６５】
なお、依頼拒否リストにおいて、「拒否フラグ」の値が「１」となった送信者メールアドレスについては、拒否フラグの値を「１」にしたとき、つまり、サービスの利用ができなくなったときから、所定の期間（たとえば１年間）が経過した場合に、自動的に、当該送信者メールアドレスの「拒否フラグ」の値を「０」に戻して、サービスの利用を可能にしても良い。或いは、電話やメールなどの他の手段により当該送信者から復旧要請があった場合に、今後不正な使用をしない旨の誓約書の提出を条件として、その送信者メールアドレスの拒否フラグの値を「０」に戻しても良い。
【００６６】
次に、第２の実施の形態にかかるサービス拒否リストからのメールアドレスの削除につき説明を加える。第２の実施の形態においては、送信先のメールアドレスをもつユーザ（受信者）が、サービス拒否リストに掲載される期間を指定できる。図１４は、第２の実施の形態にかかる受信クライアントからの要求に基づくサービス拒否登録の処理を示すフローチャートである。
【００６７】
これに先立って、第２の実施の形態においても、図３に示す処理により、メール拒否リストに掲載されていないメールアドレスを宛先としたメールが、受信者宛てに送信される（ステップ３０１〜３０６）。メールを受信し、その内容を確認した受信者は、受信拒否を要求したい場合に、メール中の固有ＵＲＬを指定する。これにより、オプトアウト要求が、ＨＴＴＰサーバ２４を介してメール制御サーバ２８に伝達される（ステップ１４０１）。
【００６８】
図１５（ａ）は、第２の実施の形態かかる受信クライアント１６に宛てて送信されるメールの例を示す図である。図１５（ａ）に示す例では、メール１５００は、いわゆるＨＴＭＬ形式であり、固有ＵＲＬ（符号１５０２）、および、メール送信を拒否する期間を指定するボタン群（符号１５０３参照）が設けられている。ユーザは、受信クライアント１６を操作して、メール送信を拒否する期間（たとえば、「永久」、「１年間」或いは「６ヶ月間」の何れか）に対応するボタンをオンすればよい。したがって、第２の実施の形態では、ステップ１４０１において、オプトアウト要求とともに、受信者に指定された期間指定情報が、メール制御サーバ２８に伝達される。
【００６９】
メール制御サーバ２８のサービス拒否登録部３８は、固有ＵＲＬを参照して、ユーザを確認する（ステップ１４０２）。これは、図７のステップ７０２に相当する。つまり、オプトアウト要求にかかる固有ＵＲＬを参照して、当該固有ＵＲＬ中のメールアドレスから、所定の関数を利用した文字列を生成し、固有ＵＲＬ中の文字列と照合する。
【００７０】
次いで、拒否する期間の記述を含むサービス拒否（配信停止）の確認を求めるコンテンツが、受信クライアント１６に与えられる（ステップ１４０３）。図１５（ｂ）に示す画像１５１０は、配信停止の確認を求めるコンテンツの例を示す。ここでは、メール配信を停止する期間（たとえば、１年間）が表示される。ここで、ユーザが受信クライアント１６を操作して、「登録」ボタン１５１１をオンすると、配信停止登録の確認が、ＨＴＴＰサーバ２４を介してメール制御サーバ２８に伝達される（ステップ１４０４）。
【００７１】
メール制御サーバ２８は、処理が実行されている日時と、拒否する期間とから、メール配信の再開日時を算出し（ステップ１４０５）、オプトアウト要求中、固有ＵＲＬ中のメールアドレス、サービスコードおよび再開日時を関連付けて、ＤＢ３２中のサービス拒否リスト１４４に追加する（ステップ１４０６）。したがって、第２の実施の形態においては、サービス拒否リスト１４４には、第１の実施の形態にあった項目（メールアドレスおよびサービスコード）に、再開日時が加えられる。その後、配信停止を登録したことを示す通知が、メール制御サーバ２８から、ＨＴＴＰサーバ２４を介して受信クライアント１６に伝達される（ステップ１４０７）。
【００７２】
メール制御サーバ２８は、所定のタイミング（たとえば、夜間など）に、サービス拒否リスト１４４中の再開日時を操作して、再開日時が、処理日時以前であれば、当該再開日時に関連付けられたメールアドレスおよびサービスコードを含むレコードを、サービス拒否リスト１４４から削除する。これ以後、当該メールアドレスを宛先とするメール配信が再開される。
このように、本実施の形態によれば、ユーザが希望した期間だけ、サイトを利用したメール配信を拒否することができる。
【００７３】
上記実施の形態においては、ユーザが、メール配信を拒否する期間を指定しているが、これに限定されるものではなく、あらかじめ定められた期間（たとえば１年間）の経過後に、メール配信を再開するようにしても良い。この場合には、図７のステップ７０１〜７０４が実行された後、処理が実行された日時に上記定められた期間を加えて、メール再開日時が算出され、メールアドレス、サービスコードおよび再開日時からなるレコードが、サービス拒否リスト４４に追加されれば良い。
【００７４】
或いは、メール配信を拒否する期間を、サービスコード、ユーザの属性などにより設定できるようにしても良い。たとえば、新卒予定学生を対象としたサービス（新卒者用の就職案内サイト）では、卒業とともにメールアドレス自体が無効となり、或いは、就業によりメールアドレスが変更されることが考えられる。このようなサービスについては、他の情報配信サービスよりも、上記期間を短く（たとえば、１ヶ月）設定しても良い。また、携帯電話のユーザについても、メールアドレスの廃止および再利用の周期が短いと考えられる。したがって、このようなユーザに関して、他のユーザよりも、上記期間を短く設定することもできる。
【００７５】
さらに、前記実施の形態においては、ＨＴＭＬ形式のメールから、ボタンの指定によりメール配信を拒否する期間を指定しているが、これに限定されるものではなく、テキスト形式のメールを利用することも可能である。この場合には、図１６に示すオプトアウト要求（ステップ１６０１：図７のステップ７０１に相当）、固有ＵＲＬを参照したユーザ確認（ステップ１６０２：図７のステップ７０２に相当）の後、メール制御サーバ２８から、ユーザを確認したことを示す通知がＨＴＴＰサーバ２４に伝達される（ステップ１６０３）。
【００７６】
ＨＴＴＰサーバ２４は、これに応答して、ユーザにメール配信を拒否する期間を指定させるためのコンテンツ（期間確認コンテンツ）を受信クライアント１６に伝達する（ステップ１６０４）。このコンテンツには、所望の期間（たとえば、「永久」、「１年間」、「６ヶ月間」）の何れかを指定するためのボタンが設けられている。ユーザが受信クライアント１６を操作して、何れかのボタンを指定すると、期間指定情報１６０５がＨＴＴＰサーバ２４を介してメール制御サーバ２８に伝達される（ステップ１６０５）。これ以降、配信を拒否する期間の記述を含む配信停止確認要求の送信（ステップ１６０６：図１４のステップ１４０３に相当）、配信停止登録確認（ステップ１６０７：図１４のステップ１４０４に相当）、再開日時の算出（ステップ１６０８：図１４のステップ１４０５に相当）、メールアドレス、サービスコードおよび再開日時からなるレコードの、サービス拒否リスト１４４への追加（ステップ１６０９：図１４のステップ１４０６に相当）、および、配信停止登録通知（ステップ１６１０：図１４のステップ１４０７に相当）が実行される。
【００７７】
次に、本発明の第３の実施の形態について説明する。サイトを利用したメールの受信を基本的に拒否したいが、特定の送信者からのメールのみ、受理しても良いと考えるユーザも存在する。そこで、第３の実施の形態においては、送信者から受信者にメール送信し、当該受信者がサイトにアクセスして所定の手続を行うことにより、受信者がメール配信を拒否している場合であっても、当該送信者からのメール配信を受理できるようにしている。
【００７８】
図１７は、第３の実施の形態にかかるメール再開処理の概略を示すフローチャートである。図１７の処理に先立って、ＨＴＴＰサーバ２４、メールサーバ２６およびメール制御サーバ２８は、送信クライアント１２からの依頼にしたがって、図３に示す処理を実行し、ＨＴＴＰサーバ２４を介して、メール送信完了通知が送信クライアント１２に送信される（ステップ１７００）。これは、図３のステップ３０９にほぼ対応する。
【００７９】
第３の実施の形態において、メール送信完了通知は、メールを送信することができた送信先のメールアドレスと、メール送信が拒否されたメールアドレスとを示すリストを含む。さらに、メール送信が拒否されたメールアドレスについて、それぞれのメールアドレスに固有の個別再開用固有ＵＲＬがメールに記述されている。このメール送信完了通知により、送信者は、受信を拒否するユーザを知ることができる。また、個別再開用固有ＵＲＬを添付することにより、当該ユーザへのメール配信の再開の可能性があることを知ることもできる。
【００８０】
個別再開用固有ＵＲＬは、第１の実施の形態の固有ＵＲＬに類似し、受信者であるユーザのメールアドレス、そのトークンとして用いられる文字列、送信者であるユーザのメールアドレス、そのトークンとして用いられる文字列を有する。
たとえば、固有ＵＲＬは以下のような構成を備えている。
ｈｔｔｐ：／／ｗｗｗ．＊＊＊．ｃｏｍ／・・・／＄＄＿Ｄ＿＄＄／＄＄＿Ｅ＿＄＄／＄＄＿Ｆ＿＄＄／＄＄＿Ｇ＿＄＄
ここに、「＄＄＿Ｄ＿＄＄」は受信者のメールアドレス、「＄＄＿Ｅ＿＄＄」は受信者メールアドレスのトークンとして利用される文字列、「＄＄＿Ｆ＿＄＄」は送信者のメールアドレス、「＄＄＿Ｇ＿＄＄」は、送信者メールアドレスのトークンとして利用される文字列である。メール制御サーバ２８は、図３のステップ３０３において、送信リストおよび固有ＵＲＬに加えて、メール配信を拒否した受信者（ユーザ）の個別再開用固有ＵＲＬを生成し、これを、メールサーバ２６に伝達している。これにより、メールサーバ２６からＨＴＴＰサーバ２４を介して、送信クライアント１２に、上記個別再開用固有ＵＲＬを伝達することができる。
【００８１】
送信者は、上記メール送信完了通知中、メール配信が拒否されているが、個別に、メール配信の再開を依頼したいユーザ（受信者）がいる場合に、送信クライアント１２のメーラを使用して、メール配信の再開を求める文面および宛先となる受信者（ユーザ）の個別再開用固有ＵＲＬを含む送信メールを生成して、これを当該ユーザ宛てに送信する（ステップ１７０１）。
【００８２】
受信者は、受信クライアント１４のメーラを利用して、メールの内容を確認し、メール中の送信者からのメール配信を受け付けても良いと判断した場合には、当該個別再開用固有ＵＲＬにアクセスする（ステップ１７０２）。メール制御サーバ２８は、上記アクセスに応答して、当該個別再開用固有ＵＲＬ中のパラメータ（「＄＄＿Ｄ＿＄＄」、「＄＄＿Ｅ＿＄＄」など）を利用して、受信者および送信者を確認する。
受信者や送信者の確認は、第１の実施の形態とほぼ同様の手法で実現できる。受信者については、パラメータ「＄＄＿Ｄ＿＄＄」と、「＄＄＿Ｅ＿＄＄」に所定の関数を施した文字列とを照合し、両者が一致すれば、なりすましなどが生じていないと判断される。同様に、送信者については、パラメータ「＄＄＿Ｆ＿＄＄」と、「＄＄＿Ｇ＿＄＄」に所定の関数を施した文字列とを照合し、両者が一致すれば、なりすましなどが生じていないと判断される。
【００８３】
このようなユーザ照合の後、メール制御サーバ２８は、サービス拒否リスト１４４中、前記受信者メールアドレスに関連付けられたデータ群（レコード）を見出す（ステップ１７０３）。
次いで、送信者メールアドレスからのメール配信を再開することの確認が受信クライアント１４に求められる（ステップ１７０４）。受信クライアント１４からの確認の通知に応答して（ステップ１７０５）、メール制御サーバ２８は、上記受信者メールアドレスに関連付けされたレコード中、「個別配信アドレス」という項目に、前記送信者メールアドレスを追加する（ステップ１７０６）。なお、図１７においては、再開確認要求がメール制御サーバ２８からＨＴＴＰサーバ２４を介して、受信クライアント１４に送信され、その確認通知が、ＨＴＴＰサーバ２４を介してメール制御サーバ２８に受理されるように記載されている。しかしながら、このようなデータ送信に限定されることはない。
【００８４】
メール制御サーバ２８において、ユーザ（送信者および受信者）を確認した後（ステップ１７０３）、メール制御サーバ２８からの依頼に基づき、メールサーバ２６が、個別再開用固有ＵＲＬによるアクセスをしたユーザのメールアドレス（受信者メールアドレス）を宛先とする、再開確認要求のメールを送信し、当該受信者が、再開確認要求メールを参照して、確認を示す通知を、ＨＴＴＰサーバ２４或いはメールサーバ２６に向けて返すように構成しても良い。後者のデータ通信により、個別再開用固有ＵＲＬを含むメールの送信者や、上記個別再開用固有ＵＲＬを取得した第三者のなりすましによる再開要求に基づく、個別再開を排除することができる。したがって、送信確認要求メールを利用した後者の方が、なりすまし防止の見地から望ましい。　図１８は、第３の実施の形態にかかるサービス拒否リストの構成例を示す図である。図１８に示すように、サービス拒否リスト１８００は、ユーザ（受信者）の「メールアドレス」、「サービスコード」および「個別配信メールアドレス」の項目を備え、各レコードには、それぞれの項目値が与えられている。なお、個別配信メールアドレスは、ユーザ（受信者）が自らの意思で、特定のメールアドレスからのメール配信を受理することを通知しない限り、空欄となる。
【００８５】
したがって、第３の実施の形態においては、送信クライアントからのメール送信依頼（図３のステップ３０１参照）に応答して、メールサーバ２６からメール制御サーバ２８に与えられる送信リストには、送信者のメールアドレスが加えられ、かつ、メール制御サーバ２８にて実行されるリスト修正処理（図３のステップ３０３）において、図５に示すステップに加えて、以下に述べるような処理が加えられる。
【００８６】
図５において、メール制御サーバ２８の照合処理部３０は、サービス拒否リストを参照して、送信リスト中のメールアドレスおよびサービスコードの組と、サービス拒否リスト１４４中のデータの組とが一致するものを検索する（ステップ５０１）。さらに、照合処理部３０は、一致した場合に、その受信者のメールアドレスに関連付けられた個別配信メールアドレスを参照して、送信者メールアドレスと一致するものが存在するか否かを判断する。ここで、個別配信メールアドレスが存在すれば、送信リスト修正部３４は、送信リストから、前記受信者のメールアドレスを削除することなく、そのままリストした状態に維持する。これにより、受信者が希望した場合には、特定の送信者からのメール送信依頼に応答して、当該受信者のメールアドレス宛てにメールを送信することが可能となる。
【００８７】
次に、本発明の第４の実施の形態につき説明を加える。第３の実施の形態においては、個別再開用固有ＵＲＬを利用し、当該個別再開用ＵＲＬにて、受信者および送信者のメールアドレスを確認している。これに対して、第４の実施の形態においては、受信者がサイトにアクセスして、自己のメールアドレスなどを入力するような構成となっている。
【００８８】
図１９は、第４の実施の形態にかかるメール再開処理の概略を示すフローチャートである。図１７の処理に先立って、ＨＴＴＰサーバ２４、メールサーバ２６およびメール制御サーバ２８は、送信クライアント１２からの依頼にしたがって、図３に示す処理を実行し、ＨＴＴＰサーバ２４を介して、メール送信完了通知が送信クライアント１２に送信される（ステップ１９００）。これは、図３のステップ３０９にほぼ対応する。
【００８９】
第４の実施の形態において、メール送信完了通知は、メールを送信することができた送信先のメールアドレスと、メール送信が拒否されたメールアドレスとを示すリストに加えて、後述するように受信者がアクセスして、特定の送信者からのメール送信を再開することを要求するための固有のＵＲＬである個別再開用固有ＵＲＬを含む。受信者は、受信クライアント１４を操作して、後述するように、サイトにアクセスして、ＨＴＴＰサーバから入力ダイアログを受理し、特定の送信者のメールアドレス等を入力する。この固有ＵＲＬは、第３の実施の形態と同様のものを利用しても良い。また、送信者メールアドレスおよび受信者メールアドレスをそれぞれ確認するためのトークンを含んでいても良いし、含んでいなくても良い。
【００９０】
送信者は、上記メール送信完了通知中、メール配信が拒否されているが、個別に、メール配信の再開を依頼したいユーザ（受信者）がいる場合に、送信クライアント１２のメーラを使用して、メール配信の再開を求める文面および個別再開用固有ＵＲＬを含む送信メールを生成して、これを当該ユーザ宛てに送信する（ステップ１９０１）。
【００９１】
受信者は、受信クライアント１４のメーラを利用して、メールの内容を確認し、メール中の送信者からのメール配信を受け付けても良いと判断した場合には、当該個別再開用固有ＵＲＬにアクセスする（ステップ１９０２）。これに応答して、ＨＴＴＰサーバは、メール配信の再開を指定するためのダイアログ（再開指定用コンテンツ）を受信クライアント１４に返信する（ステップ１９０３）。図２０（ａ）は、再開指定用コンテンツの例を示す図である。ＨＴＴＰサーバ２６は、個別再開用固有ＵＲＬ中の送信者メールアドレスおよび受信者メールアドレスを確認して、メール配信を受け入れる特定の送信者のメールアドレスの記入欄２００１に、上記送信者メールアドレスを記載し、個別再開のためのアクセスにかかるユーザのメールアドレスの記入欄２００２に、上記受信者メールアドレスを記載しておく。また、ユーザは、ダイアログ中の各記入欄２００１，２００２中のメールアドレスを修正することも可能である。なお、図２０（ａ）に示すように、全ての送信者の依頼によるメール配信を再開するため、つまり、メール配信拒否を全面的に解除するためのボタン２００３を設けても良い。
【００９２】
ユーザが、受信クライアント１４を操作して、上記記入欄中の、送信者メールアドレス（メール配信の再開を認める送信者のメールアドレス）、および、受信者メールアドレス（自己のメールアドレス）を、それぞれ確認した後、送信を指示することにより、これらメールアドレスが、ＨＴＴＰサーバ２４に伝達される（ステップ１９０４）。ＨＴＴＰサーバ２４から、受信者メールアドレスを受理したメールサーバ２６は、これに応答して、当該受信者メールアドレスを宛先とする、メール配信の確認を要求するメールを送信する（ステップ１９０５）。図２０（ｂ）は、ステップ１４０５にて伝達されるメール（再開確認要求メール）の例を示す図である。ユーザ（受信者）が受信クライアント１４を操作して、メール２０１０中の「登録」ボタン２０１１をオンすることにより、再開確認通知がＨＴＴＰサーバ２４を介してメール制御サーバ２８に伝達される（ステップ１９０６）。図２０（ｂ）に示す例は、いわゆるＨＴＭＬメールであるが、これに限定されず、テキスト形式のメールであっても良い。この場合には、「登録」ボタンの代わりに、確認の意思を伝達するためのＵＲＬが記述されていれば良い。このように、個別の送信者からのメール受信の再開（個別再開）を求めてきたユーザに対して、当該ユーザ宛てのメールを送信することにより、送信者や、個別再開用固有ＵＲＬを取得した第三者からのなりすましによる、個別再開を排除することが可能となる。
【００９３】
再開確認通知の受理に応答して、メール制御サーバ２８において、受信者メールアドレスに関連付けされたレコード中、「個別配信アドレス」という項目に、前記送信者メールアドレスを追加する（ステップ１９０７）。このようにして、当該送信者からの依頼によるメール配信は、拒否されない状態となる。
このように、第４の実施の形態によっても、受信者が希望した場合には、特定の送信者からのメール送信依頼に応答して、当該受信者のメールアドレス宛てにメールを送信することが可能となる。
【００９４】
なお、第３の実施の形態および第４の実施の形態において、メール制御サーバ２８或いはメールサーバ２６が、所定期間だけ、メール受信を拒否したユーザ宛てのメールを記憶しておき、上記特定の送信者の依頼によるメール配信の再開に伴って、前記記憶されたメールのうち、当該メール配信の再開にかかる送信者の依頼によるものを、受信者に配信するように構成しても良い。これにより、受信者によりメール配信が拒否された期間に送信されたメールであっても、所定の期間内のものであれば、受信者はこれらを受信し、内容を確認することができる。
【００９５】
さらに、受信者が、メール配信の再開を認めた送信者について、さらに、メール配信を拒否するような仕組みを加えても良い。たとえば、第１の実施の形態にかかる、メール中に含まれるサービス拒否のための固有ＵＲＬにアクセスしても良い（図６および図７参照）。
或いは、個別にメール配信が再開されている送信者の依頼にしたがって配信されたメールにおいて、当該送信者からの送信を再度拒否するための固有ＵＲＬを含ませても良い。これにより、受信者が、当該固有ＵＲＬをアクセスすることにより、メール制御サーバ２８が、サービス拒否リスト１４４中、該当する個別配信メールアドレスの項目から、送信者のメールアドレスを削除することにより、再度のメール配信拒否を実現することもできる。
【００９６】
次に、本発明の第５の実施の形態につき説明を加える。第５の実施の形態においては、受信者が、メール配信を拒否するカテゴリを指定することができるようになっている。受信者に配信されたメールには、図６（ａ）に示すように、受信を拒否するための固有ＵＲＬが記述されている（符号６０２参照）。第５の実施の形態では、複数の固有ＵＲＬを用意し、それぞれが、メール受信自体の拒否、および、送信されたメールのカテゴリに属するようなメール受信の拒否のために利用される。
【００９７】
上記メール受信自体の拒否のための固有ＵＲＬが指定された場合には、メール制御サーバ２８は、当該固有ＵＲＬを参照して、ユーザを確認した後（図７のステップ７０２参照）、メールアドレスとサービスコードとの組のレコードをサービス拒否リストに追加する（図７のステップ７０５参照）。ここで、サービスコードとして、サービス全体を現す特定の値を利用すれば良い。
【００９８】
その一方、特定のカテゴリに属するようなメール受信を拒否するための固有ＵＲＬが指定された場合には、メール制御サーバ２８は、ユーザ確認の後、メールアドレスと当該カテゴリに対応するサービスコードとの組のレコードをサービス拒否リストに追加すればよい。このように、第５の実施の形態によれば、受信者は、メール受信を拒否する範囲を指定することが可能となる。
【００９９】
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
たとえば、第３の実施の形態或いは第４の実施の形態においては、特定の送信者からのメールのみを受理できるような構成を採っている。また、第５の実施の形態においては、メールのカテゴリごと、或いは、メール受信全体の拒否が可能となっている。つまり、前者は、送信者をキーとするメール配信の選択であり、後者は、カテゴリをキーとするメール配信の選択である。本発明においては、これらの双方、つまり、送信者およびカテゴリをキーとするメール配信の選択ができるようにしても良いことは言うまでもない。
また、第２の実施の形態におけるメール受信を拒否する期間の設定を、上記第３ないし第５の実施の形態に加えても良い。
【０１００】
【発明の効果】
本発明によれば、送信者が気軽にサービスを利用でき、かつ、メール配信が不要な受信者も、煩雑な手続き無く受信拒否の手続きをなすことができるシステムを提供することが可能となる。
【図面の簡単な説明】
【図１】図１は、本発明の実施の形態にかかるメール配信のためのシステムを概略的に示すブロックダイヤグラムである。
【図２】図２は、本実施の形態にかかるメール制御サーバの構成を示すブロックダイヤグラムである。
【図３】図３は、本実施の形態にかかるメール制御サーバを利用した受信クライアントへのメール配信を示すフローチャートである。
【図４】図４は、本実施の形態にかかる入力ダイアログの例を示す図である。
【図５】図５は、本実施の形態にかかるメール制御サーバによるリスト修正処理を示すフローチャートである。
【図６】図６は、本実施の形態において受信クライアントに送信されるメール等の例を示す図である。
【図７】図７は、本実施の形態にかかるメール受信拒否の際に実行される処理を示すフローチャートである。
【図８】図８は、本実施の形態にかかるサービスの分類の例を説明するための図である。
【図９】図９は、第２の実施の形態にかかるメール制御サーバの構成を示すブロックダイヤグラムである。
【図１０】図１０は、第２の実施の形態における送信クライアントからのメール送信依頼に伴って実行される処理を示すフローチャートである。
【図１１】図１０は、第２の実施の形態における送信クライアントからのメール送信依頼に伴って実行される処理を示すフローチャートである。
【図１２】図１２は、第２の実施の形態にかかる依頼拒否リストの一例を示す図である。
【図１３】図１３は、第２の実施の形態にかかる依頼拒否リスト更新処理を示すフローチャートである。
【図１４】図１４は、第２の実施の形態にかかる受信クライアントからの要求に基づくサービス拒否登録の処理を示すフローチャートである。
【図１５】図１５は、第２の実施の形態かかる受信クライアント１６に宛てて送信されるメールの例、および、ユーザの確認を求める画像例を示す図である。
【図１６】図１６は、受信クライアントからの要求に基づくサービス拒否登録の処理の他の例を示すフローチャートである。
【図１７】図１７は、第３の実施の形態にかかるメール再開処理の概略を示すフローチャートである。
【図１８】図１８は、第３の実施の形態にかかるサービス拒否リストの構成例を示す図である。
【図１９】図１９は、第４の実施の形態にかかるメール再開処理の概略を示すフローチャートである。
【図２０】図２０は、再開指定用コンテンツ、および、確認用のメールの例を示す図である。
【符号の説明】
１２　　送信クライアント
１４　　サーバ群
１６　　受信クライアント
１８　　インターネット
２０　　ブラウザ
２２　　メーラ
２４　　ＨＴＴＰサーバ
２６　　メールサーバ
２８　　メール制御サーバ
３０　　照合処理部
３２　　送信リスト修正部
３４　　データベース
３６　　ＵＲＬ生成・追加部
３８　　サービス拒否登録部
４０　　サービス再開制御部
４２　　送信ログＤＢ
４４　　サービス拒否リスト（サービス拒否テーブル）
【図１】
2004086236.tif 000003
【図２】
2004086236.tif 000004
【図３】
2004086236.tif 000005
【図４】
2004086236.tif 000006
【図５】
2004086236.tif 000007
【図６】
2004086236.tif 000008
【図７】
2004086236.tif 000009
【図８】
2004086236.tif 000010
【図９】
2004086236.tif 000011
【図１０】
2004086236.tif 000012
【図１１】
2004086236.tif 000013
【図１２】
2004086236.tif 000014
【図１３】
2004086236.tif 000015
【図１４】
2004086236.tif 000016
【図１５】
2004086236.tif 000017
【図１６】
2004086236.tif 000018
【図１７】
2004086236.tif 000019
【図１８】
2004086236.tif 000020
【図１９】
2004086236.tif 000021
【図２０】
2004086236.tif 000022