JP2004086236A - メール配信制御方法 - Google Patents

メール配信制御方法 Download PDF

Info

Publication number
JP2004086236A
JP2004086236A JP2002237589A JP2002237589A JP2004086236A JP 2004086236 A JP2004086236 A JP 2004086236A JP 2002237589 A JP2002237589 A JP 2002237589A JP 2002237589 A JP2002237589 A JP 2002237589A JP 2004086236 A JP2004086236 A JP 2004086236A
Authority
JP
Japan
Prior art keywords
mail
address
sender
mail address
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2002237589A
Other languages
English (en)
Inventor
Yuji Hori
堀 雄治
Yoshinobu Hirakawa
平川 嘉伸
Noriyuki Mizoguchi
溝口 則行
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Recruit Co Ltd
Original Assignee
Recruit Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Recruit Co Ltd filed Critical Recruit Co Ltd
Priority to JP2002237589A priority Critical patent/JP2004086236A/ja
Publication of JP2004086236A publication Critical patent/JP2004086236A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】送信者が気軽にサービスを利用でき、かつ、メール配信が不要な受信者も、煩雑な手続き無く受信拒否の手続きができる。
【解決手段】送信クライアント12から、送信先のメールアドレス、および、送信すべき情報を指定するための情報を受理すると、送信先のメールアドレスを含む送信リストが生成される。メール制御サーバ28の照合処理部30および送信リスト修正部32は、メール受信を拒否するユーザの情報を記憶したサービス拒否リスト44を参照して、リスト44に載っているメールアドレスを、送信リストから除外する。メールサーバ26は、メールアドレスを特定する固有URLを含むメールを送信する。メールの送信先となった受信クライアント16から、固有URLによるアクセスを受理すると、サービス拒否登録部38は、固有URLにしたがって、メールアドレスなどを、サービス拒否リスト44に追加する。
【選択図】 図2

Description

【0001】
【発明の属する技術分野】
本発明は、ウェブサイトを介したメール配信に関し、より詳細には、受信者が望まないメールの配信を制限するメール配信制御の手法に関する。
【0002】
【従来の技術】
インターネットを利用して所望の情報(たとえば、グルメ情報、ショッピング、ニュース)などを取得する種々の情報配信サイトが存在する。これら情報配信サイトにおいては、ユーザが操作するクライアントマシンの要求に応答して、必要な情報を含むコンテンツを配信する。
【0003】
上記情報配信サイトでは、コンテンツを配信するだけでなく、ユーザが指定した情報(たとえば、パッケージツアーやレストランの情報、ニュースなど)を、他のユーザにメールにて配信するサービスが実現されている。このサービスを享受するために、ユーザは、クライアントマシンのブラウザにコンテンツが表示されている状態で、所望の記事を指定した上で、ブラウザ上に表示された画像中のメール送信のためのボタンをオンする。
【0004】
これに応答して、サイトからはメール配信のためのダイアログがクライアントマシンに配信される。ユーザは、送信先のメールアドレス(他のユーザのメールアドレス)、メッセージ、および、サイトポリシにしたがって必要な場合には、送信者の氏名やメールアドレスを入力した上で、入力済みのダイアログを、サイトのサーバに対して送信する。メールサーバは、HTTPサーバを介して、必要な情報(送信すべきコンテンツ或いはテキストや、送信先のメールアドレス)を受理し、メールを作成して、メールアドレス宛てに送信する。このようなサービスにより、送信者は、複数の相手に、自分の伝えたい情報を通知することができる。
【0005】
【発明が解決しようとする課題】
特に、上述したメール配信サービスにおいて、送信者(ユーザ)のメールアドレスの記入を不要としている場合には、送信者匿名の状態で、多数のメールを送信することが可能であり、このサービスがスパムメール発信源として悪用されるという可能性があった。その一方、スパムメールを防止するためには、送信者の氏名やメールアドレスを必須入力事項とした上で、そのメールアドレスを用いて、送信者と実際に連絡が取れることを確認した上で、メールを配信することも考えられる。しかしながら、この場合には、善意のユーザを含む全ユーザに、氏名やメールアドレスなどの開示を求める必要があり、気軽にサービスを利用することを阻害する要因となり得る。
【0006】
また、従来、受信者が、上記メール配信サービスによる、メールの受信を拒否したい場合、当該ユーザは、電話等を利用してサイトのオペレータに直接コンタクトし、或いは、別途、メールを送信して、受信拒否の意思を表明する必要があり、受信者が、別途何らかの手続きを行わなければならないという問題点もあった。
さらに、いわゆるスパムメールの送信源から、上記メール配信サービスを利用したメール送信については、サービスの利用自体を拒否できる枠組みが作られるのが望ましい。
【0007】
本発明は、送信者が気軽にサービスを利用でき、かつ、メール配信が不要な受信者も、煩雑な手続き無く受信拒否の手続きをなすことができるシステムを提供することを目的とする。
また、本発明は、いわゆるスパムメールの送信源からの、メール配信サービスの利用要求を拒否することができるシステムを提供することを目的とする。
【0008】
【課題を解決するための手段】
本発明の目的は、コンテンツを提供するサーバにおいて、送信クライアントからの依頼にしたがって、所定の情報を含むメールを、1以上の送信先に送信するメール配信制御方法において、前記送信クライアントから、ネットワークを介して、少なくとも1以上の送信先のメールアドレス、および、送信クライアントからの送信すべき情報を指定するための情報を受理し、前記送信先のメールアドレスのリストを生成するステップと、メール受信を拒否するユーザに関するメールアドレスおよび受信の拒否にかかる情報のカテゴリを記憶したサービス拒否テーブルを参照して、前記メールアドレスおよび送信すべき情報のカテゴリと一致するものを見出し、当該メールアドレスを、前記1以上のメールアドレスのリストから除外するステップと、前記所定のメールアドレスが除外されたリストに基づき、前記送信すべき情報、および、メール受信を拒否するためにメール送信および送信先であるメールアドレスを特定する固有情報を含むメールを生成ステップと、生成されたメールを、送信先に向けてそれぞれ送信するステップと、前記メールの送信先となった受信クライアントから、前記ネットワークを介して、前記固有情報によるアクセスを受理するステップと、前記固有情報にしたがって、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリを、前記サービス拒否テーブルに追加するステップとを備えたことを特徴とするメール配信制御方法により達成される。
【0009】
本発明によれば、メールを受信したユーザが、受信したメールに含まれる固有情報を利用してアクセスすることにより、コンテンツを提供するサーバが、固有情報にしたがって、当該ユーザのメールアドレスへの、当該サーバを介したメール送信を行わないよう、サービス拒否テーブルに、前記メールアドレス及び受信の拒否にかかる情報のカテゴリを登録する。これにより、送信者が、当該メールアドレスを有するユーザに、コンテンツを提供するサーバを利用して、ある情報、たとえば、コンテンツ中の所定の記事などをメールにて送りたい場合であっても、受信者であるユーザの意思にしたがって、当該メールの送信を防止することができる。
【0010】
たとえば、サーバにて提供されるコンテンツには、レストランガイド、ショップガイド、商品紹介、旅行ガイド、ニュースなどが含まれる。また、コンテンツを提供するサーバは、単一のサーバから構成されている必要は無い。たとえば、HTTPサーバ、メールサーバ、および、前記サービス拒否テーブルを含み、送信者がメールを送信しようとするメールアドレスのリストから、所定のメールアドレスを除去する処理を実行するメール制御サーバからなるサーバ群が設けられていても良い。
【0011】
好ましい実施態様においては、前記送信すべき情報を指定するための情報が、前記コンテンツの内容を示すサービスコードであり、かつ、前記サービス拒否テーブルに、メールアドレスおよびサービスコードの組が記憶される。サービスコードを、サービスのカテゴリにしたがって設定することにより、特定のサービスについてのメール配信のみを拒否することが可能となる。
【0012】
また、好ましい実施態様においては、固有情報を生成するステップが、前記メールアドレスおよび前記サービスコードをパラメータとして含む、当該メールアドレスへのメール配信を一意的に特定する固有URLを生成するステップを有する。この実施態様によれば、メール中に固有URLを記述しておき、受信クライアントにおいて、ユーザがメール中の固有URLを指定することで、一定のサービスに関するメール配信を拒否することが可能となる。
【0013】
より好ましい実施態様においては、前記固有情報を生成するステップが、さらに、前記メールアドレスに基づき、所定の関数を利用して、当該メールアドレスを一意的に特定するトークンを生成するステップと、前記トークンを含む固有URLを生成するステップとを有し、さらに、受信クライアントからの、前記ネットワークを介して、前記固有URLを用いたアクセスに応答して、前記固有URL中のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、前記固有URL中のトークンとを照合するステップを備え、前記トークンが一致した場合に、メールアドレスおよびサービスコードの組を、前記サービス拒否テーブルに追加するように構成されている。
【0014】
この実施態様によれば、固有URL中のトークンと、メールアドレスから再生成したトークンとを照合し、これらが一致した場合のみ、真正なユーザからのメール配信の拒否と判断する。したがって、いわゆるなりすましによるメール配信の拒否を防止することが可能となる。
【0015】
また、別の好ましい実施態様においては、さらに、前記サービス拒否テーブル中の前記メールアドレスおよび受信の拒否にかかる情報のカテゴリを、選択的に削除するステップを備えている。上記削除するステップは、たとえば、メール受信拒否を解除するための第2の固有URLを作成し、配信するメール中に当該第2の固有URLを記述し、当該第2の固有URLを利用したアクセスに応答して実行されても良い。或いは、サービス拒否テーブル中に情報を記憶する期間を設定し、その期間の経過後に、所定のものを削除しても良い。
【0016】
より好ましい実施態様においては、前記選択的に削除するステップが、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリが前記サービス拒否テーブルに記憶されてから、所定期間を経過した場合に実行される。これにより、たとえば、1ヶ月、6ヶ月などの期間が経過すると、当該メールアドレスの受信者へのメール配信が再開される。
【0017】
さらに、メール受信を拒否するユーザに関して、その拒否を解除し、メール配信を再開するまでの期間を示す情報を、前記受信クライアントから受理するステップと、前記サービス拒否テーブルに、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリと関連付けて、前記期間或いは再開時を示す情報を記憶するステップとを備えているのが望ましい。これにより、受信者であるユーザは、メール配信の再開までの期間を指定することができる。この期間には、たとえば、「無限」、つまり、永久にメール配信を拒否することを意味するものを含んでも良い。
【0018】
別の好ましい実施態様においては、さらに、メール受信を拒否したメールアドレスに対して、特定の送信者からのメール受信の再開を求めるための個別再開情報を生成するステップと、前記送信クライアントに、メール受信を拒否したメールアドレス、および、前記個別再開情報を通知するステップと、前記送信クライアントから受信クライアントを経て、前記受信クライアントから伝達された個別再開情報に基づき、送信者のメールアドレス、受信者のメールアドレスを特定するステップと、前記サービス拒否テーブル中、前記受信者のメールアドレスに関連付けて、個別にメール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶するステップとを備えている。
【0019】
この実施態様によれば、基本的にはメール受信を拒否したいが、特定の送信者からの依頼に基づくメールだけは受信したいようなユーザに対して、柔軟に対応することができる。つまり、ユーザは、所望の送信者からの依頼によるメールのみを受信することが可能となる。なお、個別再開情報として、再開を依頼するためのサイトのURL、送信者および受信者が一意的に特定される、後述する個別再開固有URLなどを利用することができる。
【0020】
より好ましい実施態様においては、さらに、前記受信者のメールアドレス宛てに、前記送信者からのメール受信の再開を確認するためのメールを送信するステップを備え、前記送信したメールに対する前記受信者の応答の受理があった場合に、前記サービス拒否テーブル中に、メール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶するステップが実行される。
【0021】
この実施態様によれば、メール受信の再開を依頼した受信者に対して、本人確認の意味で、当該受信者のメールアドレス宛てにメールを送信し、その応答を受理したことを条件に、これ以降の処理が実行される。これにより、送信者や上記個別再開情報を取得した第三者が、受信者になりすまして、上記メール受信の再開を依頼し、その依頼に応答して、当該送信者の依頼によるメール配信が再開されることを防止することができる。 より好ましい実施態様においては、前記個別再開情報を生成するステップが、前記送信者のメールアドレスおよび受信者のメールアドレスをパラメータとして含む、当該送信者から受信者へのメール送信を一意的に特定する個別再開用固有URLを生成するステップを有し、前記個別再開URLの伝達により、送信者および受信者のメールアドレスが特定される。これにより、受信者は、個別再開用固有URlにアクセスするだけで、特定の送信者からの依頼に基づくメールの受信を再開することができる。
【0022】
より好ましくは、前記固有情報を生成するステップが、さらに、前記送信者のメールアドレスに基づき、所定の関数を利用して、当該送信者のメールアドレスを一意的に特定する送信者特定用のトークンを生成するステップと、前記受信者のメールアドレスに基づき、所定の関数を利用して、当該受信者のメールアドレスを一意的に特定する受信者特定用のトークンを生成するステップと、双方のトークンを含む個別再開用固有URLを生成するステップとを有し、受信クライアントからの、前記個別再開用固有URLを用いたアクセスに応答して、前記個別再開用固有URL中の受信者のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、前記個別再開用固有URL中の受信者特定用のトークンとを照合するとともに、前記個別再開用固有URL中の送信者のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、個別再開用固有URL中の送信者特定用のトークンとを照合するステップを備え、双方のトークンが一致した場合に、サービス拒否テーブル中、前記受信者のメールアドレスに関連付けて、個別にメール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶する。これにより、送信者および受信者の双方が真正であることを担保することが可能となる。
【0023】
また、別の好ましい実施態様においては、さらに、メール受信を拒否するユーザに関して、当該ユーザにより選択された、受信の拒否にかかる情報のカテゴリを受理するステップを備え、前記サービス拒否テーブルに、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリが記憶される。たとえば、受信者であるユーザは、すべてのカテゴリの受信の拒否、或いは、特定のカテゴリの受信の拒否を選択することが可能となる。
【0024】
別の好ましい実施態様においては、さらに、所定の条件が成立した場合に、送信者のメールアドレスからの依頼を拒否するために、依頼拒否リストを生成するステップを備えている。たとえば、ある送信者のメールアドレスに関して、クレーム数、メール受信の拒否を表明したメールアドレスの数などが一定数に達したときには、当該送信者からの依頼によるメール配信自体を拒否する。
【0025】
【発明の実施の形態】
以下、添付図面を参照して、本発明の実施の形態につき説明を加える。図1は、本発明の実施の形態にかかるメール配信のためのシステムを概略的に示すブロックダイヤグラムである。図1に示すように、種々のクライアントマシン12、16−1、16−2、・・・が、インターネット18に接続されている。また、インターネット18には、あるサイト14を構成するサーバ群が接続される。サーバ群は、クライアントマシンにコンテンツを提供するHTTPサーバ24と、インターネット18を介してクライアントマシンにメールを送信するメールサーバ26と、送信すべきメールに関して種々の処理を実行するメール制御サーバ28を含む。
【0026】
本実施の形態においては、あるクライアントマシン12がサイトにアクセスしてコンテンツを閲覧し、当該コンテンツ中の所望の情報を、他のクライアントマシンにメールで通知できるようになっている。そこで、本実施の形態において、メールの送信を求めるクライアントマシンを、便宜上、送信クライアント12と称し、メールを受信するクライアントマシンを、便宜上、受信クライアント16と称する。図1においては、2つの受信クライアント16−1、16−2が図示されているが、実際には、送信クライアント12は、サイトにおける制限の範囲内で、任意の電子メールアドレスを宛先として、メールの送信を求めることができる。
【0027】
図2は、本実施の形態にかかるメール制御サーバ28の構成を示すブロックダイヤグラムである。メール制御サーバ28は、メールサーバ26から、送信クライアント12がメールの送信を要求した送信先のメールアドレスから、受信を拒否するものを除外する処理を実行する。
【0028】
図2に示すように、メール制御サーバ28は、メールサーバからメールアドレスのリスト(初期的な送信リスト)およびサービスの内容を示すサービスコードを受理して、送信リスト中のメールアドレスを、後述するサービス拒否リスト(サービス拒否テーブル)44と照合する照合処理部30と、サービス拒否リスト44を含むデータベース(DB)32と、照合結果にしたがって、送信リストを修正する送信リスト修正部34と、修正されたリスト中のメールアドレスに対する固有のURL(固有URL)を生成、追加するURL生成・追加部36と、受信クライアント13からのメール受信拒否を登録するサービス拒否登録部38と、メール受信の再開を登録するサービス再開制御部40と、送信クライアントから受信クライアントへのメールの送信ログを記憶する送信ログDB42とを備えている。
【0029】
このように構成されたメール制御サーバ28を利用した受信クライアントへのメール配信につき、図3を参照して説明を加える。
送信クライアント12のブラウザ20が、HTTPサーバ24に、コンテンツ配信を要求すると、HTTPサーバ24は、要求されたコンテンツを、インターネット18を介して送信クライアント12に返し、ブラウザ20によりコンテンツが送信クライアント12の表示装置の画面上に表示される。このような処理が、コンテンツの閲覧中に繰り返される。本実施の形態において、コンテンツ中には、所定のサービス、たとえば、レストラン紹介、パッケージツアーの紹介、ニュース記事などの各々を、メールにて、他のクライアントマインに通知することができる。たとえば、コンテンツ中の所定の単位に対応させて、「この**(たとえば、レストラン、ツアー、ニュース)を友だちに知らせる」という記述を含ませ、これをユーザが指定することにより、メール送信依頼が、HTTPサーバ24に伝達される。
【0030】
クライアントマシン12からのメール送信依頼は、ブラウザ20からHTTPサーバ24を介してメールサーバ26に伝達される(ステップ301)。メール送信依頼は、HTTPサーバ24が、送信クライアント12に図4に示すような入力ダイアログを送信し、送信クライアント12にて、入力欄に必要な事項を記入した上で、これを返信することにより実現される。図4は、入力ダイアログの一例を示す図である。入力ダイアログ400には、たとえば、送信先のメールアドレスの入力欄(たとえば、符号401参照)、送信するユーザの名前の入力欄(符号402参照)およびメッセージ入力欄(符号403)が含まれる。これらのうち、送信するユーザの名前の記入欄およびメッセージ入力欄への記入は必須とせず、これらを空欄のまま、「送信」ボタン404がクリックされても良い。その一方、ユーザの名前や当該ユーザのメールアドレスを必須入力項目としても良いことは明らかである。
【0031】
メールサーバ26は、メール送信依頼の受理に応答して、メールアドレスのリスト(送信リスト)および配信する情報の内容を示す情報を、メール制御サーバ28に伝達する(ステップ302)。サイト14において、コンテンツは、車、グルメ(レストラン紹介)、旅行、教育、趣味、ニュースなど、サイト中のコンテンツを概略的に分ける大分類、および、大分類にしたがったカテゴリ中の小分類に分けられる。たとえば、図8に示すように、「車」という大分類のカテゴリには、「新車情報」、「中古車情報」、「試乗」という小分類のカテゴリが含まれ、「旅行」という大分類のカテゴリには、「国内旅行」、「海外旅行」という小分類のカテゴリが含まれる。また、たとえば、「グルメ」や「ニュース」には、大分類のカテゴリのみが存在する。大分類、小分類のカテゴリには、それぞれ、対応するサービスコードが割り当てられている。
【0032】
そこで、メールサーバ26は、ユーザがメール送信を要求した情報のカテゴリに基づき、サービスコードを特定し、これを、メールアドレスのリスト(送信リスト)ともに、メール制御サーバ28に伝達する。
メール制御サーバ28は、後述するように、DB32中のサービス拒否リスト44を参照して、メール受信を拒否するユーザのメールアドレスを特定し、そのようなユーザにはメールを送信しないよう、送信リストを修正し(ステップ303)、メールサーバ26に返す(ステップ304)。なお、ステップ304では、各メールアドレスに対応した固有URLも、メールサーバ26に伝達される。この固有URLについては、メール制御サーバ28の処理の説明に関連して詳述する。
【0033】
メールサーバ26は、修正された送信リストにあるメールアドレスのそれぞれを宛先とするメールを生成し(ステップ305)、これらメールを送信する(ステップ306)。これにより、受信クライアント16−1、16−2、・・・のメーラ22−1、22−2、・・・により、受信者は自己に宛てられたメールの受信及びそのメールの内容を知ることができる。その後、メールサーバ26は、メール制御サーバ28にメール送信が完了したことを通知する(ステップ307)。メール制御サーバ28は、メール送信時刻や送信先のメールアドレスなどを含む送信ログを、送信ログDB42に記録する(ステップ308)。その一方、送信が完了した旨を示す通知、例えば通知メールを、HTTPサーバ24を介して、送信クライアント12に伝達することもできる(ステップ309)。このステップ309の処理は必須ではなく、送信クライアントのメールアドレスを特定できない場合、例えば入力を強要しない場合は、通知メールが伝達されることは無い。
【0034】
次に、メール制御サーバ28によるリスト修正処理(ステップ303)につき、図5を参照してより詳細に説明を加える。メール制御サーバ28の照合処理部30は、サービス拒否リスト44を参照して、送信リスト中の各メールアドレスおおびサービスコードの組と、サービス拒否リスト44中のデータの組とが合致するものを検索する(ステップ501)。
【0035】
本実施の形態において、メール受信の拒否は、サービスコードにて特定されるカテゴリごとに設定できるようになっている。このため、サービス拒否リスト44には、メールアドレスおよび当該メールアドレスに関してメールを送信すべきでない情報のサービスコードが、関連付けられ、データの組として記憶されている。送信リスト中のメールアドレスと、今回送信される情報のカテゴリを示すサービスコードの組と、サービス拒否リスト44中のデータの組とが一致する場合には、当該メールアドレスが、送信リスト修正部34により、送信リストから削除される(ステップ502)。
【0036】
次いで、URL生成・追加部36は、送信リストに残ったメールアドレスの各々を特定するための種々のパラメータを生成し、当該パラメータを含む、各メールアドレスの固有URLを生成する(ステップ503)。以下に、固有URLにつき説明を加える。
URL生成・追加部36は、メールアドレスに基づき、所定の関数を利用して、当該メールアドレスを一意的に特定する他の文字列を生成する。これは、後のサービス拒否登録の処理において、ユーザを特定するトークンとして利用される。
【0037】
URL生成・追加部36は、サービスコード、ユーザのメールアドレスおよび上述のように生成した文字列からなるURLを、固有URLとする。たとえば、固有URLは、以下のような構成となる。
http://www.***.com/・・・/$$_A_$$/$$_B_$$/$$_C_$$
パラメータについて説明すると、「$$_A_$$」はサービスコード、「$$_B_$$」はユーザのメールアドレス、「$$_C_$$」はトークンとして利用される文字列である。この固有URLが、受信クライアント16から送られると、ユーザ(メールアドレス)およびサービスコードが特定されるとともに、メールアドレスから、上記関数を利用して文字列を再生成し、固有URL中の文字列と照合を図ることにより、メールを受信したユーザからのアクセスであることを確認することができる。
【0038】
次いで、メール制御サーバ28は、修正された送信リストと、各メールアドレスに対応する固有URLとを、メールサーバ26に返信する(ステップ504)。
先に述べたように、メールサーバ26は、メール制御サーバ28から返信された送信リストを参照して、送信リスト中のメールアドレス宛てのメールを生成する。ここで、メール中には宛先のメールアドレスに対応した固有URLが含まれる。
【0039】
図6(a)は、メールサーバ26から受信クライアント16に宛てて送信されるメールの例を示す図である。図6に示すように、メール600中には、本文601の他、メール制御サーバ28にて生成された固有URL(符号602参照)が記述される。
受信クライアント16のユーザが、上記固有URLを指定することにより、後述するサービス拒否登録の処理が実行される。図3の処理にしたがって、メールサーバ26から送信されたメールを受信したユーザが、当該メールを不要と感じ、これ以降、同種のメールの受信を拒否したいと考えた場合には、受信クライアント16を操作して、図6(a)に示す固有URL602を指定する。図7は、受信クライアントからの要求に基づくサービス拒否登録の処理を示すフローチャートである。
【0040】
上述したユーザによる固有URLの指定により、受信クライアント16からオプトアウト要求がHTTPサーバ24を介してメール制御サーバ28に伝達される。メール制御サーバ28のサービス拒否登録部38は、オプトアウト要求にかかる固有URLを参照して、当該固有URL中のメールアドレスから、所定の関数を利用した文字列を生成し、前記固有URL中の文字列($$_C_$$)と照合する(ステップ702)。ここで、両者が一致すれば、なりすましではなく、メールを受理した真正なユーザ(つまりユーザ本人)からのアクセスであると判断される。
【0041】
メールを受理したユーザ本人からのアクセスであると判断された場合には、メール制御サーバ28からHTTPサーバ24を介して、メール配信の停止(サービス拒否)の確認を求めるコンテンツが、受信クライアント16に与えられる(ステップ703)。図6(b)に示す画像610は、このようなコンテンツの例を示す。ここで、ユーザが受信クライアント16を操作して、「登録」ボタン611をオンすると、配信停止登録の確認がHTTPサーバ24を介してメール制御サーバ28に伝達される(ステップ704)。なお、メール配信の停止の確認を求めるコンテンツの配信に際しては、受信クライアント16からのアクセス情報を参照して、当該受信クライアントの機種(たとえば、パーソナルコンピュータ、携帯電話、PDAなど)を判別し、受信クライアントの表示装置の画面上に適したコンテンツを生成するのが望ましい。
【0042】
メール制御サーバ28は、配信停止登録の確認の受理に応答して、オプトアウト要求中、固有URL中のメールアドレス($$_B_$$)およびサービスコード($$_A_$$)を関連付けて、DB32中のサービス拒否リスト44に追加する(ステップ705)。その後、HTTPサーバ24を介して、配信停止登録が完了したことを示す通知が受信クライアント16に伝達される。
これにより、送信クライアント12から、メール送信要求があった場合でも、特定のサービスコードについて、あるメールアドレスのユーザが、その受信を拒否している場合には、当該ユーザには、メールを送信することを防止できる。
【0043】
次に、配信の再開について説明を加える。たとえば、あるサービスコードに対応するサービスについて、メールの配信を拒否しているユーザが、当該サービスに関するメールの配信を再開する際の処理につき、簡単に説明する。
たとえば、ユーザは電話やメールなどにより、サイトにコンタクトをとって、オペレータがメール制御サーバ28を操作して、ユーザに指示された、メールアドレスおよびサービスコードの組を、サービス拒否リスト44から削除する。これにより、メール配信が再開される。
【0044】
或いは、図6(a)に示すような、固有URLのほか、受信を再開するための第2の固有URLを、「受信を再開する際にはクリックする」ことを示す記述とともに配置しても良い。この第2の固有URLにおいては、たとえば、サブドメイン名やファイル名は、先に説明した固有URLと異なるが、当該固有URLと同様に、サービスコード、ユーザのメールアドレスおよびトークンとして利用される文字列を含む。
【0045】
ユーザがこの第2の固有URLをクリックすると、メール制御サーバ28のサービス再開制御部40が、HTTPサーバ24を介して、メールアドレスおよび第2の固有URLを受理し、図7に相当する処理を実行して、DB32のサービス拒否リスト44から、要求にかかるメールアドレスとサービスコードの組を、削除すればよい。すなわち、第2の固有URLを参照してユーザを確認し(ステップ702参照)、配信開始の確認の一連の手続き(ステップ703、704参照)の後、メールアドレスとサービスコードの組を、サービス拒否リスト44から削除すればよい。このような構成にすれば、ユーザは、サイトに電話などにて直接コンタクトをとり、或いは、別途メールを作成することなく、サービスの再開をサイト側に求めることが可能となる。
【0046】
本実施の形態によれば、送信クライアントからの送信要求に応えて、サイト側(メールサーバ)から送信されたメール中に、メール受信を拒否する意思を示すための固有URLを含めておく。受信クライアントのユーザは、当該固有URLを指定することで、一定のサービスに関して、上記メール送信を拒否することが可能となる。
【0047】
次に、本発明の第2の実施の形態につき説明を加える。第2の実施の形態においても、図1に示すように、送信クライアント12からのメール配信要求に応答して、サイト14を構成するサーバ群においてメールが作成され、指定された送信先に向けて、メールが送信される。受信クライアント16においては、送信先のユーザが、それぞれ、サイト14からのメールを受理し、当該メールを読むことができる。また、第2の実施の形態においては、メール配信サービスを利用するユーザ(送信者)に、送信者自身のメールアドレスの入力を求めるようになっている。
【0048】
図9は、第2の実施の形態にかかるメール制御サーバ28の構成を示すブロックダイヤグラムである。図9において、図2に示す第1の実施の形態と同一の部材には同一の符号を付す。図9に示すように、第2の実施の形態にかかるメール制御サーバ28は、照合処理部30、DB32、送信リスト修正部34、URL生成・追加部36、サービス拒否登録部38、サービス再開制御部40、送信ログDB42に加えて、送信者に関する種々の処理を実行する送信者管理部50および依頼拒否リストDB52を備えている。
【0049】
送信者管理部50は、サイトのオペレータが入力した指示や、サービス拒否リストの参照結果に基づいて、依頼拒否リストDB52中の依頼拒否リストに、ユーザのメールアドレスを追加し、或いは、所定の条件が成立した場合には、依頼拒否リスト中のメールアドレスを削除する処理を実行する。
本実施の形態において、依頼拒否リストは、メール配信サービスの利用者、つまり、メールの送信を希望するユーザに対して、そのサービスの利用を拒否するために利用される。
【0050】
図10は、第2の実施の形態における送信クライアント12からのメール送信依頼に伴って実行される処理を示すフローチャートである。送信クライアント12のブラウザ20とHTTPサーバ24との間では、コンテンツ配信要求およびコンテンツ配信が繰り返される。メール送信依頼においては、第1の実施の形態と同様に、図4に示すようなダイアログが送信クライアント12に与えられ、送信クライアント12から、必要事項が入力されたダイアログが、送信クライアント12から送信されることにより実現される。なお、第2の実施の形態においては、送信するユーザのメールアドレス(送信者メールアドレス)の入力が必須となる。また、第2の実施の形態においては、真正な送信者であることを確認するため、つまり、送信者のなりすましを防止するために、メールサーバ26から、送信者メールアドレス宛てに、メール配信サービスの利用を確認するメールを送信し、当該送信者から、サービス利用の確認を示す情報を受理することを条件として、図10に示す処理が実行される。
【0051】
図10に示すように、送信クライアント12のブラウザ20から、メール送信依頼が、HTTPサーバ24を介してメールサーバ26に伝達されると(ステップ1001)、ダイアログ中の送信者メールアドレスが、メール制御サーバ28に伝達される(ステップ1002)。メール制御サーバの送信者管理部50は、依頼拒否リストDB52の依頼拒否リスト中のメールアドレスと、送信者メールアドレスとを照合し、送信者メールアドレスが、依頼拒否リスト中に掲載されているか否かを判断する(ステップ1003)。
【0052】
依頼拒否リスト中に送信者メールアドレスが掲載されていた場合には、リストに掲載されたことを示す照合結果がメールサーバ26に返される(ステップ1004)。これに応答して、メールサーバ26は、サービス利用の拒否を送信クライアントに通知する(ステップ1005)。
その一方、図11に示すように、メール送信依頼(ステップ1101)、送信者メールアドレスのメール制御サーバ28への伝達(ステップ1102)、および、メール制御サーバ28における照合(ステップ1103)の結果、送信者メールアドレスが、依頼拒否リスト中に掲載されていなかった場合、メール制御サーバ28から、リストに掲載されていないことを示す照合結果が、メールサーバ26に返される(ステップ1104)。
【0053】
メールサーバ26は、送信者メールアドレスが、リストに掲載されていないことに応答して、送信者メールアドレスに宛てて、サービス利用意思を確認するためのメール(確認メール)を送信する(ステップ1105)。この確認メールには、たとえば、ユーザが送信しようとした情報、送信先のメールアドレスおよびサービス利用の確定を指示するためのURLが含まれる。
【0054】
ユーザが、上記メール中のURLを指定すると、確定指示がHTTPサーバ24を介して、メールサーバ26に伝達される(ステップ1106)。これにより、第1の実施の形態と同様に、送信先のメールアドレスおよびサービスコードがメール制御サーバ28に伝達され、リスト修正処理(図3のステップ303および図5参照)が実行される。
【0055】
以下、メール制御サーバ28からメールサーバ26への送信リストおよび固有URLの返送(ステップ304)、各受信者へのメールの生成(ステップ305)、メール送信(ステップ306)、メール完了通知の伝達(ステップ307、309)、および、送信ログの記録(ステップ308)の処理は、第1の実施の形態と同様である。なお、第2の実施の形態においては、送信ログにおいて、送信者メールアドレスと、送信先のメールアドレス群とが関連付けて記録される。
【0056】
さらに、第2の実施の形態においては、メール送信完了通知が、メールを送信することができた送信先のメールアドレスと、メール送信が拒否されたメールアドレスとを示すリストを含む。また、第2の実施の形態において、メール完了通知(図3のステップ307参照)に応答して、メール制御サーバ28は依頼拒否リスト52中、ある送信者メールアドレスに関するメール送信が拒否されたメールアドレス数(サービス拒否表明アドレス数)を更新する処理を実行する。これについては、後述する。
【0057】
次に、第2の実施の形態にかかる依頼拒否リストDBの依頼拒否リストへの、送信者メールアドレスの追加や削除に関する処理を説明する。図12は、依頼拒否リストの一例を示す図である。図12に示すように、依頼拒否リスト1200においては、送信者アドレスに関連付けられた、「依頼拒否フラグ」、「拒否開始日時」、「クレーム数」、「サービス拒否表明アドレス数」、「平均送信間隔」および「単位時間送信数」などの項目のそれぞれに値が付与される。
【0058】
「依頼拒否フラグ」は、「1」或いは「0」の値を有する。この値が「1」であれば、関連する送信者メールアドレスからのサービス利用が拒否される。「拒否開始日時」は、上記「依頼拒否フラグ」の値が「1」に設定された日時を示す。
「クレーム数」は、送信者ユーザアドレスを依頼者とするメール配信に対して、受信者からの電話やメールによる苦情の数を意味する。これは、たとえば、メール制御サーバ28のオペレータが、入力装置を操作することで、当該送信者メールアドレスに関連付けられた値を更新することができる。「サービス拒否表明アドレス数」は、メール完了通知(図3のステップ307)に応答して、メール送信が拒否されたメールアドレスの数、元のサービス拒否表明アドレス数に加えることで値が更新される。これは、ある送信者メールアドレスについて、サービスを利用したメールの受信を拒否したメールアドレスの延べ数を表す。
【0059】
また、「平均送信間隔」には、サイト14を利用したメール送信サービスを利用する間隔の平均値が与えられ、「単位時間送信数」は、一定の時間(たとえば1時間)あたりの、サイト14を利用したメール送信における送信先メールアドレスの平均値が与えられる。これらの値については、送信者管理部50が、所定のタイミング(たとえば夜間バッチ処理など)で、依頼拒否リスト更新処理を実行し、送信ログDB42を参照して、平均値を算出し、該当する項目の値を更新すればよい。
【0060】
図13は、第2の実施の形態にかかる依頼拒否リスト更新処理を示すフローチャートである。送信者管理部50は、送信ログDB42を参照して(ステップ1301)、送信ログ中の送信者アドレスを特定する(ステップ1302)。次いで、依頼拒否リストDB52の依頼拒否リスト中、当該送信者メールアドレスに関連するレコードを特定し、当該レコード中の項目の値を更新する(ステップ1303)。この値の更新は、上に記載した「平均送信間隔」や「単位時間送信数」の値の更新に対応する。また、送信者メールアドレスが、依頼拒否リスト中に存在しない場合には、新たにその送信者メールアドレスに関するレコードを生成すればよい。
【0061】
次いで、更新された項目の値と、依頼拒否の条件(拒否条件)とが照合される(ステップ1304)。本実施の形態においては、以下の拒否条件が設けられており、何れかに該当する場合には、当該送信者メールアドレスに関する「拒否リスト」が「1」にされる。
(1)「クレーム数」がある一定数に達した場合に、拒否条件により拒否される範囲であると判断される。
(2)「サービス拒否表明アドレス数」がある一定数に達した場合に、拒否条件により拒否される範囲であると判断される。
(3)「平均送信間隔」が、ある一定時間より短くなった場合に、拒否条件により拒否される範囲であると判断される。
(4)「単位時間送信数」が、ある一定数に達した場合に、拒否条件により拒否される範囲であると判断される。
【0062】
送信者管理部50は、ある送信者メールアドレスについて、上記(1)〜(4)の何れかに該当する場合、つまり、拒否される範囲であった場合には(ステップ1305でイエス(Yes))、当該送信者メールアドレスに関するレコード中、「拒否フラグ」を「1」に設定する(ステップ1306)。次いで、メール制御サーバ28は、「拒否フラグ」が「1」に設定された送信者メールアドレスを宛先に、サービス利用が拒否されることを通知するためのメールの作成を、メールサーバ26に依頼する。これにより、サービス利用の拒否を通知するメールが、当該送信者メールアドレス宛てに送信される(ステップ1307)。本実施の形態においては、サービス利用、つまり、所定の送信先メールアドレス宛てにメールを送信する際に、送信元を確認するためのメールを送信している。したがって、ステップ1307におけるメール送信は、送信者の存在を、再度確認する確認することを意図している。
このような処理を、送信ログの末尾までの各送信ログ中の送信者メールアドレスについて繰り返す(ステップ1308参照)。
【0063】
たとえば、図12において、レコード1201の送信者メールアドレスについては、前記(1)〜(4)のいずれの条件にも該当しないため、「依頼拒否フラグ」は「0」となっている。その一方、レコード1202の送信者メールアドレスについては、(1)〜(4)の少なくとも1つの条件に該当するため、「依頼拒否フラグ」が「1」となっている。
【0064】
このように、第2の実施の形態によれば、一定の条件に該当する送信者メールアドレスについて、依頼拒否フラグを「1」とすることにより、当該送信者メールアドレスを依頼元とする、メール送信のサービスを拒否することが可能となる。これにより、スパムメールの発信源と考えられる送信元からのサービスの利用自体を拒否することが可能となる。
【0065】
なお、依頼拒否リストにおいて、「拒否フラグ」の値が「1」となった送信者メールアドレスについては、拒否フラグの値を「1」にしたとき、つまり、サービスの利用ができなくなったときから、所定の期間(たとえば1年間)が経過した場合に、自動的に、当該送信者メールアドレスの「拒否フラグ」の値を「0」に戻して、サービスの利用を可能にしても良い。或いは、電話やメールなどの他の手段により当該送信者から復旧要請があった場合に、今後不正な使用をしない旨の誓約書の提出を条件として、その送信者メールアドレスの拒否フラグの値を「0」に戻しても良い。
【0066】
次に、第2の実施の形態にかかるサービス拒否リストからのメールアドレスの削除につき説明を加える。第2の実施の形態においては、送信先のメールアドレスをもつユーザ(受信者)が、サービス拒否リストに掲載される期間を指定できる。図14は、第2の実施の形態にかかる受信クライアントからの要求に基づくサービス拒否登録の処理を示すフローチャートである。
【0067】
これに先立って、第2の実施の形態においても、図3に示す処理により、メール拒否リストに掲載されていないメールアドレスを宛先としたメールが、受信者宛てに送信される(ステップ301〜306)。メールを受信し、その内容を確認した受信者は、受信拒否を要求したい場合に、メール中の固有URLを指定する。これにより、オプトアウト要求が、HTTPサーバ24を介してメール制御サーバ28に伝達される(ステップ1401)。
【0068】
図15(a)は、第2の実施の形態かかる受信クライアント16に宛てて送信されるメールの例を示す図である。図15(a)に示す例では、メール1500は、いわゆるHTML形式であり、固有URL(符号1502)、および、メール送信を拒否する期間を指定するボタン群(符号1503参照)が設けられている。ユーザは、受信クライアント16を操作して、メール送信を拒否する期間(たとえば、「永久」、「1年間」或いは「6ヶ月間」の何れか)に対応するボタンをオンすればよい。したがって、第2の実施の形態では、ステップ1401において、オプトアウト要求とともに、受信者に指定された期間指定情報が、メール制御サーバ28に伝達される。
【0069】
メール制御サーバ28のサービス拒否登録部38は、固有URLを参照して、ユーザを確認する(ステップ1402)。これは、図7のステップ702に相当する。つまり、オプトアウト要求にかかる固有URLを参照して、当該固有URL中のメールアドレスから、所定の関数を利用した文字列を生成し、固有URL中の文字列と照合する。
【0070】
次いで、拒否する期間の記述を含むサービス拒否(配信停止)の確認を求めるコンテンツが、受信クライアント16に与えられる(ステップ1403)。図15(b)に示す画像1510は、配信停止の確認を求めるコンテンツの例を示す。ここでは、メール配信を停止する期間(たとえば、1年間)が表示される。ここで、ユーザが受信クライアント16を操作して、「登録」ボタン1511をオンすると、配信停止登録の確認が、HTTPサーバ24を介してメール制御サーバ28に伝達される(ステップ1404)。
【0071】
メール制御サーバ28は、処理が実行されている日時と、拒否する期間とから、メール配信の再開日時を算出し(ステップ1405)、オプトアウト要求中、固有URL中のメールアドレス、サービスコードおよび再開日時を関連付けて、DB32中のサービス拒否リスト144に追加する(ステップ1406)。したがって、第2の実施の形態においては、サービス拒否リスト144には、第1の実施の形態にあった項目(メールアドレスおよびサービスコード)に、再開日時が加えられる。その後、配信停止を登録したことを示す通知が、メール制御サーバ28から、HTTPサーバ24を介して受信クライアント16に伝達される(ステップ1407)。
【0072】
メール制御サーバ28は、所定のタイミング(たとえば、夜間など)に、サービス拒否リスト144中の再開日時を操作して、再開日時が、処理日時以前であれば、当該再開日時に関連付けられたメールアドレスおよびサービスコードを含むレコードを、サービス拒否リスト144から削除する。これ以後、当該メールアドレスを宛先とするメール配信が再開される。
このように、本実施の形態によれば、ユーザが希望した期間だけ、サイトを利用したメール配信を拒否することができる。
【0073】
上記実施の形態においては、ユーザが、メール配信を拒否する期間を指定しているが、これに限定されるものではなく、あらかじめ定められた期間(たとえば1年間)の経過後に、メール配信を再開するようにしても良い。この場合には、図7のステップ701〜704が実行された後、処理が実行された日時に上記定められた期間を加えて、メール再開日時が算出され、メールアドレス、サービスコードおよび再開日時からなるレコードが、サービス拒否リスト44に追加されれば良い。
【0074】
或いは、メール配信を拒否する期間を、サービスコード、ユーザの属性などにより設定できるようにしても良い。たとえば、新卒予定学生を対象としたサービス(新卒者用の就職案内サイト)では、卒業とともにメールアドレス自体が無効となり、或いは、就業によりメールアドレスが変更されることが考えられる。このようなサービスについては、他の情報配信サービスよりも、上記期間を短く(たとえば、1ヶ月)設定しても良い。また、携帯電話のユーザについても、メールアドレスの廃止および再利用の周期が短いと考えられる。したがって、このようなユーザに関して、他のユーザよりも、上記期間を短く設定することもできる。
【0075】
さらに、前記実施の形態においては、HTML形式のメールから、ボタンの指定によりメール配信を拒否する期間を指定しているが、これに限定されるものではなく、テキスト形式のメールを利用することも可能である。この場合には、図16に示すオプトアウト要求(ステップ1601:図7のステップ701に相当)、固有URLを参照したユーザ確認(ステップ1602:図7のステップ702に相当)の後、メール制御サーバ28から、ユーザを確認したことを示す通知がHTTPサーバ24に伝達される(ステップ1603)。
【0076】
HTTPサーバ24は、これに応答して、ユーザにメール配信を拒否する期間を指定させるためのコンテンツ(期間確認コンテンツ)を受信クライアント16に伝達する(ステップ1604)。このコンテンツには、所望の期間(たとえば、「永久」、「1年間」、「6ヶ月間」)の何れかを指定するためのボタンが設けられている。ユーザが受信クライアント16を操作して、何れかのボタンを指定すると、期間指定情報1605がHTTPサーバ24を介してメール制御サーバ28に伝達される(ステップ1605)。これ以降、配信を拒否する期間の記述を含む配信停止確認要求の送信(ステップ1606:図14のステップ1403に相当)、配信停止登録確認(ステップ1607:図14のステップ1404に相当)、再開日時の算出(ステップ1608:図14のステップ1405に相当)、メールアドレス、サービスコードおよび再開日時からなるレコードの、サービス拒否リスト144への追加(ステップ1609:図14のステップ1406に相当)、および、配信停止登録通知(ステップ1610:図14のステップ1407に相当)が実行される。
【0077】
次に、本発明の第3の実施の形態について説明する。サイトを利用したメールの受信を基本的に拒否したいが、特定の送信者からのメールのみ、受理しても良いと考えるユーザも存在する。そこで、第3の実施の形態においては、送信者から受信者にメール送信し、当該受信者がサイトにアクセスして所定の手続を行うことにより、受信者がメール配信を拒否している場合であっても、当該送信者からのメール配信を受理できるようにしている。
【0078】
図17は、第3の実施の形態にかかるメール再開処理の概略を示すフローチャートである。図17の処理に先立って、HTTPサーバ24、メールサーバ26およびメール制御サーバ28は、送信クライアント12からの依頼にしたがって、図3に示す処理を実行し、HTTPサーバ24を介して、メール送信完了通知が送信クライアント12に送信される(ステップ1700)。これは、図3のステップ309にほぼ対応する。
【0079】
第3の実施の形態において、メール送信完了通知は、メールを送信することができた送信先のメールアドレスと、メール送信が拒否されたメールアドレスとを示すリストを含む。さらに、メール送信が拒否されたメールアドレスについて、それぞれのメールアドレスに固有の個別再開用固有URLがメールに記述されている。このメール送信完了通知により、送信者は、受信を拒否するユーザを知ることができる。また、個別再開用固有URLを添付することにより、当該ユーザへのメール配信の再開の可能性があることを知ることもできる。
【0080】
個別再開用固有URLは、第1の実施の形態の固有URLに類似し、受信者であるユーザのメールアドレス、そのトークンとして用いられる文字列、送信者であるユーザのメールアドレス、そのトークンとして用いられる文字列を有する。
たとえば、固有URLは以下のような構成を備えている。
http://www.***.com/・・・/$$_D_$$/$$_E_$$/$$_F_$$/$$_G_$$
ここに、「$$_D_$$」は受信者のメールアドレス、「$$_E_$$」は受信者メールアドレスのトークンとして利用される文字列、「$$_F_$$」は送信者のメールアドレス、「$$_G_$$」は、送信者メールアドレスのトークンとして利用される文字列である。メール制御サーバ28は、図3のステップ303において、送信リストおよび固有URLに加えて、メール配信を拒否した受信者(ユーザ)の個別再開用固有URLを生成し、これを、メールサーバ26に伝達している。これにより、メールサーバ26からHTTPサーバ24を介して、送信クライアント12に、上記個別再開用固有URLを伝達することができる。
【0081】
送信者は、上記メール送信完了通知中、メール配信が拒否されているが、個別に、メール配信の再開を依頼したいユーザ(受信者)がいる場合に、送信クライアント12のメーラを使用して、メール配信の再開を求める文面および宛先となる受信者(ユーザ)の個別再開用固有URLを含む送信メールを生成して、これを当該ユーザ宛てに送信する(ステップ1701)。
【0082】
受信者は、受信クライアント14のメーラを利用して、メールの内容を確認し、メール中の送信者からのメール配信を受け付けても良いと判断した場合には、当該個別再開用固有URLにアクセスする(ステップ1702)。メール制御サーバ28は、上記アクセスに応答して、当該個別再開用固有URL中のパラメータ(「$$_D_$$」、「$$_E_$$」など)を利用して、受信者および送信者を確認する。
受信者や送信者の確認は、第1の実施の形態とほぼ同様の手法で実現できる。受信者については、パラメータ「$$_D_$$」と、「$$_E_$$」に所定の関数を施した文字列とを照合し、両者が一致すれば、なりすましなどが生じていないと判断される。同様に、送信者については、パラメータ「$$_F_$$」と、「$$_G_$$」に所定の関数を施した文字列とを照合し、両者が一致すれば、なりすましなどが生じていないと判断される。
【0083】
このようなユーザ照合の後、メール制御サーバ28は、サービス拒否リスト144中、前記受信者メールアドレスに関連付けられたデータ群(レコード)を見出す(ステップ1703)。
次いで、送信者メールアドレスからのメール配信を再開することの確認が受信クライアント14に求められる(ステップ1704)。受信クライアント14からの確認の通知に応答して(ステップ1705)、メール制御サーバ28は、上記受信者メールアドレスに関連付けされたレコード中、「個別配信アドレス」という項目に、前記送信者メールアドレスを追加する(ステップ1706)。なお、図17においては、再開確認要求がメール制御サーバ28からHTTPサーバ24を介して、受信クライアント14に送信され、その確認通知が、HTTPサーバ24を介してメール制御サーバ28に受理されるように記載されている。しかしながら、このようなデータ送信に限定されることはない。
【0084】
メール制御サーバ28において、ユーザ(送信者および受信者)を確認した後(ステップ1703)、メール制御サーバ28からの依頼に基づき、メールサーバ26が、個別再開用固有URLによるアクセスをしたユーザのメールアドレス(受信者メールアドレス)を宛先とする、再開確認要求のメールを送信し、当該受信者が、再開確認要求メールを参照して、確認を示す通知を、HTTPサーバ24或いはメールサーバ26に向けて返すように構成しても良い。後者のデータ通信により、個別再開用固有URLを含むメールの送信者や、上記個別再開用固有URLを取得した第三者のなりすましによる再開要求に基づく、個別再開を排除することができる。したがって、送信確認要求メールを利用した後者の方が、なりすまし防止の見地から望ましい。 図18は、第3の実施の形態にかかるサービス拒否リストの構成例を示す図である。図18に示すように、サービス拒否リスト1800は、ユーザ(受信者)の「メールアドレス」、「サービスコード」および「個別配信メールアドレス」の項目を備え、各レコードには、それぞれの項目値が与えられている。なお、個別配信メールアドレスは、ユーザ(受信者)が自らの意思で、特定のメールアドレスからのメール配信を受理することを通知しない限り、空欄となる。
【0085】
したがって、第3の実施の形態においては、送信クライアントからのメール送信依頼(図3のステップ301参照)に応答して、メールサーバ26からメール制御サーバ28に与えられる送信リストには、送信者のメールアドレスが加えられ、かつ、メール制御サーバ28にて実行されるリスト修正処理(図3のステップ303)において、図5に示すステップに加えて、以下に述べるような処理が加えられる。
【0086】
図5において、メール制御サーバ28の照合処理部30は、サービス拒否リストを参照して、送信リスト中のメールアドレスおよびサービスコードの組と、サービス拒否リスト144中のデータの組とが一致するものを検索する(ステップ501)。さらに、照合処理部30は、一致した場合に、その受信者のメールアドレスに関連付けられた個別配信メールアドレスを参照して、送信者メールアドレスと一致するものが存在するか否かを判断する。ここで、個別配信メールアドレスが存在すれば、送信リスト修正部34は、送信リストから、前記受信者のメールアドレスを削除することなく、そのままリストした状態に維持する。これにより、受信者が希望した場合には、特定の送信者からのメール送信依頼に応答して、当該受信者のメールアドレス宛てにメールを送信することが可能となる。
【0087】
次に、本発明の第4の実施の形態につき説明を加える。第3の実施の形態においては、個別再開用固有URLを利用し、当該個別再開用URLにて、受信者および送信者のメールアドレスを確認している。これに対して、第4の実施の形態においては、受信者がサイトにアクセスして、自己のメールアドレスなどを入力するような構成となっている。
【0088】
図19は、第4の実施の形態にかかるメール再開処理の概略を示すフローチャートである。図17の処理に先立って、HTTPサーバ24、メールサーバ26およびメール制御サーバ28は、送信クライアント12からの依頼にしたがって、図3に示す処理を実行し、HTTPサーバ24を介して、メール送信完了通知が送信クライアント12に送信される(ステップ1900)。これは、図3のステップ309にほぼ対応する。
【0089】
第4の実施の形態において、メール送信完了通知は、メールを送信することができた送信先のメールアドレスと、メール送信が拒否されたメールアドレスとを示すリストに加えて、後述するように受信者がアクセスして、特定の送信者からのメール送信を再開することを要求するための固有のURLである個別再開用固有URLを含む。受信者は、受信クライアント14を操作して、後述するように、サイトにアクセスして、HTTPサーバから入力ダイアログを受理し、特定の送信者のメールアドレス等を入力する。この固有URLは、第3の実施の形態と同様のものを利用しても良い。また、送信者メールアドレスおよび受信者メールアドレスをそれぞれ確認するためのトークンを含んでいても良いし、含んでいなくても良い。
【0090】
送信者は、上記メール送信完了通知中、メール配信が拒否されているが、個別に、メール配信の再開を依頼したいユーザ(受信者)がいる場合に、送信クライアント12のメーラを使用して、メール配信の再開を求める文面および個別再開用固有URLを含む送信メールを生成して、これを当該ユーザ宛てに送信する(ステップ1901)。
【0091】
受信者は、受信クライアント14のメーラを利用して、メールの内容を確認し、メール中の送信者からのメール配信を受け付けても良いと判断した場合には、当該個別再開用固有URLにアクセスする(ステップ1902)。これに応答して、HTTPサーバは、メール配信の再開を指定するためのダイアログ(再開指定用コンテンツ)を受信クライアント14に返信する(ステップ1903)。図20(a)は、再開指定用コンテンツの例を示す図である。HTTPサーバ26は、個別再開用固有URL中の送信者メールアドレスおよび受信者メールアドレスを確認して、メール配信を受け入れる特定の送信者のメールアドレスの記入欄2001に、上記送信者メールアドレスを記載し、個別再開のためのアクセスにかかるユーザのメールアドレスの記入欄2002に、上記受信者メールアドレスを記載しておく。また、ユーザは、ダイアログ中の各記入欄2001,2002中のメールアドレスを修正することも可能である。なお、図20(a)に示すように、全ての送信者の依頼によるメール配信を再開するため、つまり、メール配信拒否を全面的に解除するためのボタン2003を設けても良い。
【0092】
ユーザが、受信クライアント14を操作して、上記記入欄中の、送信者メールアドレス(メール配信の再開を認める送信者のメールアドレス)、および、受信者メールアドレス(自己のメールアドレス)を、それぞれ確認した後、送信を指示することにより、これらメールアドレスが、HTTPサーバ24に伝達される(ステップ1904)。HTTPサーバ24から、受信者メールアドレスを受理したメールサーバ26は、これに応答して、当該受信者メールアドレスを宛先とする、メール配信の確認を要求するメールを送信する(ステップ1905)。図20(b)は、ステップ1405にて伝達されるメール(再開確認要求メール)の例を示す図である。ユーザ(受信者)が受信クライアント14を操作して、メール2010中の「登録」ボタン2011をオンすることにより、再開確認通知がHTTPサーバ24を介してメール制御サーバ28に伝達される(ステップ1906)。図20(b)に示す例は、いわゆるHTMLメールであるが、これに限定されず、テキスト形式のメールであっても良い。この場合には、「登録」ボタンの代わりに、確認の意思を伝達するためのURLが記述されていれば良い。このように、個別の送信者からのメール受信の再開(個別再開)を求めてきたユーザに対して、当該ユーザ宛てのメールを送信することにより、送信者や、個別再開用固有URLを取得した第三者からのなりすましによる、個別再開を排除することが可能となる。
【0093】
再開確認通知の受理に応答して、メール制御サーバ28において、受信者メールアドレスに関連付けされたレコード中、「個別配信アドレス」という項目に、前記送信者メールアドレスを追加する(ステップ1907)。このようにして、当該送信者からの依頼によるメール配信は、拒否されない状態となる。
このように、第4の実施の形態によっても、受信者が希望した場合には、特定の送信者からのメール送信依頼に応答して、当該受信者のメールアドレス宛てにメールを送信することが可能となる。
【0094】
なお、第3の実施の形態および第4の実施の形態において、メール制御サーバ28或いはメールサーバ26が、所定期間だけ、メール受信を拒否したユーザ宛てのメールを記憶しておき、上記特定の送信者の依頼によるメール配信の再開に伴って、前記記憶されたメールのうち、当該メール配信の再開にかかる送信者の依頼によるものを、受信者に配信するように構成しても良い。これにより、受信者によりメール配信が拒否された期間に送信されたメールであっても、所定の期間内のものであれば、受信者はこれらを受信し、内容を確認することができる。
【0095】
さらに、受信者が、メール配信の再開を認めた送信者について、さらに、メール配信を拒否するような仕組みを加えても良い。たとえば、第1の実施の形態にかかる、メール中に含まれるサービス拒否のための固有URLにアクセスしても良い(図6および図7参照)。
或いは、個別にメール配信が再開されている送信者の依頼にしたがって配信されたメールにおいて、当該送信者からの送信を再度拒否するための固有URLを含ませても良い。これにより、受信者が、当該固有URLをアクセスすることにより、メール制御サーバ28が、サービス拒否リスト144中、該当する個別配信メールアドレスの項目から、送信者のメールアドレスを削除することにより、再度のメール配信拒否を実現することもできる。
【0096】
次に、本発明の第5の実施の形態につき説明を加える。第5の実施の形態においては、受信者が、メール配信を拒否するカテゴリを指定することができるようになっている。受信者に配信されたメールには、図6(a)に示すように、受信を拒否するための固有URLが記述されている(符号602参照)。第5の実施の形態では、複数の固有URLを用意し、それぞれが、メール受信自体の拒否、および、送信されたメールのカテゴリに属するようなメール受信の拒否のために利用される。
【0097】
上記メール受信自体の拒否のための固有URLが指定された場合には、メール制御サーバ28は、当該固有URLを参照して、ユーザを確認した後(図7のステップ702参照)、メールアドレスとサービスコードとの組のレコードをサービス拒否リストに追加する(図7のステップ705参照)。ここで、サービスコードとして、サービス全体を現す特定の値を利用すれば良い。
【0098】
その一方、特定のカテゴリに属するようなメール受信を拒否するための固有URLが指定された場合には、メール制御サーバ28は、ユーザ確認の後、メールアドレスと当該カテゴリに対応するサービスコードとの組のレコードをサービス拒否リストに追加すればよい。このように、第5の実施の形態によれば、受信者は、メール受信を拒否する範囲を指定することが可能となる。
【0099】
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
たとえば、第3の実施の形態或いは第4の実施の形態においては、特定の送信者からのメールのみを受理できるような構成を採っている。また、第5の実施の形態においては、メールのカテゴリごと、或いは、メール受信全体の拒否が可能となっている。つまり、前者は、送信者をキーとするメール配信の選択であり、後者は、カテゴリをキーとするメール配信の選択である。本発明においては、これらの双方、つまり、送信者およびカテゴリをキーとするメール配信の選択ができるようにしても良いことは言うまでもない。
また、第2の実施の形態におけるメール受信を拒否する期間の設定を、上記第3ないし第5の実施の形態に加えても良い。
【0100】
【発明の効果】
本発明によれば、送信者が気軽にサービスを利用でき、かつ、メール配信が不要な受信者も、煩雑な手続き無く受信拒否の手続きをなすことができるシステムを提供することが可能となる。
【図面の簡単な説明】
【図1】図1は、本発明の実施の形態にかかるメール配信のためのシステムを概略的に示すブロックダイヤグラムである。
【図2】図2は、本実施の形態にかかるメール制御サーバの構成を示すブロックダイヤグラムである。
【図3】図3は、本実施の形態にかかるメール制御サーバを利用した受信クライアントへのメール配信を示すフローチャートである。
【図4】図4は、本実施の形態にかかる入力ダイアログの例を示す図である。
【図5】図5は、本実施の形態にかかるメール制御サーバによるリスト修正処理を示すフローチャートである。
【図6】図6は、本実施の形態において受信クライアントに送信されるメール等の例を示す図である。
【図7】図7は、本実施の形態にかかるメール受信拒否の際に実行される処理を示すフローチャートである。
【図8】図8は、本実施の形態にかかるサービスの分類の例を説明するための図である。
【図9】図9は、第2の実施の形態にかかるメール制御サーバの構成を示すブロックダイヤグラムである。
【図10】図10は、第2の実施の形態における送信クライアントからのメール送信依頼に伴って実行される処理を示すフローチャートである。
【図11】図10は、第2の実施の形態における送信クライアントからのメール送信依頼に伴って実行される処理を示すフローチャートである。
【図12】図12は、第2の実施の形態にかかる依頼拒否リストの一例を示す図である。
【図13】図13は、第2の実施の形態にかかる依頼拒否リスト更新処理を示すフローチャートである。
【図14】図14は、第2の実施の形態にかかる受信クライアントからの要求に基づくサービス拒否登録の処理を示すフローチャートである。
【図15】図15は、第2の実施の形態かかる受信クライアント16に宛てて送信されるメールの例、および、ユーザの確認を求める画像例を示す図である。
【図16】図16は、受信クライアントからの要求に基づくサービス拒否登録の処理の他の例を示すフローチャートである。
【図17】図17は、第3の実施の形態にかかるメール再開処理の概略を示すフローチャートである。
【図18】図18は、第3の実施の形態にかかるサービス拒否リストの構成例を示す図である。
【図19】図19は、第4の実施の形態にかかるメール再開処理の概略を示すフローチャートである。
【図20】図20は、再開指定用コンテンツ、および、確認用のメールの例を示す図である。
【符号の説明】
12  送信クライアント
14  サーバ群
16  受信クライアント
18  インターネット
20  ブラウザ
22  メーラ
24  HTTPサーバ
26  メールサーバ
28  メール制御サーバ
30  照合処理部
32  送信リスト修正部
34  データベース
36  URL生成・追加部
38  サービス拒否登録部
40  サービス再開制御部
42  送信ログDB
44  サービス拒否リスト(サービス拒否テーブル)

Claims (13)

  1. コンテンツを提供するサーバにおいて、送信クライアントからの依頼にしたがって、所定の情報を含むメールを、1以上の送信先に送信するメール配信制御方法において、
    前記送信クライアントから、ネットワークを介して、少なくとも1以上の送信先のメールアドレス、および、送信クライアントからの送信すべき情報を指定するための情報を受理し、前記送信先のメールアドレスのリストを生成するステップと、
    メール受信を拒否するユーザに関するメールアドレスおよび受信の拒否にかかる情報のカテゴリを記憶したサービス拒否テーブルを参照して、前記メールアドレスおよび送信すべき情報のカテゴリと一致するものを見出し、当該メールアドレスを、前記1以上のメールアドレスのリストから除外するステップと、
    前記所定のメールアドレスが除外されたリストに基づき、前記送信すべき情報、および、メール受信を拒否するためにメール送信および送信先であるメールアドレスを特定する固有情報を含むメールを生成ステップと、
    生成されたメールを、送信先に向けてそれぞれ送信するステップと、
    前記メールの送信先となった受信クライアントから、前記ネットワークを介して、前記固有情報によるアクセスを受理するステップと、
    前記固有情報にしたがって、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリを、前記サービス拒否テーブルに追加するステップとを備えたことを特徴とするメール配信制御方法。
  2. 前記送信すべき情報を指定するための情報が、前記コンテンツの内容を示すサービスコードであり、かつ、前記サービス拒否テーブルに、メールアドレスおよびサービスコードの組が記憶されることを特徴とする請求項1に記載のメール配信制御方法。
  3. 前記固有情報を生成するステップが、
    前記メールアドレスおよび前記サービスコードをパラメータとして含む、当該メールアドレスへのメール配信を一意的に特定する固有URLを生成するステップを有することを特徴とする請求項2に記載のメール配信制御方法。
  4. 前記固有情報を生成するステップが、
    さらに、前記メールアドレスに基づき、所定の関数を利用して、当該メールアドレスを一意的に特定するトークンを生成するステップと、
    前記トークンを含む固有URLを生成するステップとを有し、
    さらに、受信クライアントからの、前記ネットワークを介して、前記固有URLを用いたアクセスに応答して、前記固有URL中のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、前記固有URL中のトークンとを照合するステップを備え、
    前記トークンが一致した場合に、メールアドレスおよびサービスコードの組を、前記サービス拒否テーブルに追加することを特徴とする請求項3に記載のメール配信制御方法。
  5. さらに、前記サービス拒否テーブル中の前記メールアドレスおよび受信の拒否にかかる情報のカテゴリを、選択的に削除するステップを備えたことを特徴とする請求項1ないし4の何れか一項に記載のメール配信制御方法。
  6. 前記選択的に削除するステップが、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリが前記サービス拒否テーブルに記憶されてから、所定期間を経過した場合に実行されることを特徴とする請求項5に記載のメール配信制御方法。
  7. さらに、メール受信を拒否するユーザに関して、その拒否を解除し、メール配信を再開するまでの期間を示す情報を、前記受信クライアントから受理するステップと、
    前記サービス拒否テーブルに、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリと関連付けて、前記期間或いは再開時を示す情報を記憶するステップとを備えたことを特徴とする請求項5または6に記載のメール配信制御方法。
  8. さらに、メール受信を拒否したメールアドレスに対して、特定の送信者からのメール受信の再開を求めるための個別再開情報を生成するステップと、
    前記送信クライアントに、メール受信を拒否したメールアドレス、および、前記個別再開情報を通知するステップと、
    前記送信クライアントから受信クライアントを経て、前記受信クライアントから伝達された個別再開情報に基づき、送信者のメールアドレス、受信者のメールアドレスを特定するステップと、
    前記サービス拒否テーブル中、前記受信者のメールアドレスに関連付けて、個別にメール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶するステップとを備えたことを特徴とする請求項1ないし7の何れか一項に記載のメール配信制御方法。
  9. さらに、前記受信者のメールアドレス宛てに、前記送信者からのメール受信の再開を確認するためのメールを送信するステップを備え、
    前記送信したメールに対する前記受信者の応答の受理があった場合に、前記サービス拒否テーブル中に、メール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶するステップが実行されることを特徴とする請求項8に記載のメール配信制御方法。
  10. 前記個別再開情報を生成するステップが、
    前記送信者のメールアドレスおよび受信者のメールアドレスをパラメータとして含む、当該送信者から受信者へのメール送信を一意的に特定する個別再開用固有URLを生成するステップを有し、
    前記個別再開URLの伝達により、送信者および受信者のメールアドレスが特定されることを特徴とする請求項8または9に記載のメール配信制御方法。
  11. 前記固有情報を生成するステップが、
    さらに、前記送信者のメールアドレスに基づき、所定の関数を利用して、当該送信者のメールアドレスを一意的に特定する送信者特定用のトークンを生成するステップと、
    前記受信者のメールアドレスに基づき、所定の関数を利用して、当該受信者のメールアドレスを一意的に特定する受信者特定用のトークンを生成するステップと、
    双方のトークンを含む個別再開用固有URLを生成するステップとを有し、
    受信クライアントからの、前記個別再開用固有URLを用いたアクセスに応答して、前記個別再開用固有URL中の受信者のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、前記個別再開用固有URL中の受信者特定用のトークンとを照合するとともに、前記個別再開用固有URL中の送信者のメールアドレスに基づき、再度所定の関数を利用して生成したトークンと、個別再開用固有URL中の送信者特定用のトークンとを照合するステップを備え、
    双方のトークンが一致した場合に、サービス拒否テーブル中、前記受信者のメールアドレスに関連付けて、個別にメール受信を拒否しないメールアドレスとして、前記送信者のメールアドレスを記憶することを特徴とする請求項10に記載のメール配信制御方法。
  12. さらに、メール受信を拒否するユーザに関して、当該ユーザにより選択された、受信の拒否にかかる情報のカテゴリを受理するステップを備え、
    前記サービス拒否テーブルに、前記メールアドレスおよび受信の拒否にかかる情報のカテゴリが記憶されることを特徴とする請求項1ないし11の何れか一項に記載のメール配信制御方法。
  13. さらに、所定の条件が成立した場合に、送信者のメールアドレスからの依頼を拒否するために、依頼拒否リストを生成するステップを備えたことを特徴とする請求項1ないし12の何れか一項に記載のメール配信制御方法。
JP2002237589A 2002-07-03 2002-08-16 メール配信制御方法 Pending JP2004086236A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2002237589A JP2004086236A (ja) 2002-07-03 2002-08-16 メール配信制御方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2002194529 2002-07-03
JP2002237589A JP2004086236A (ja) 2002-07-03 2002-08-16 メール配信制御方法

Publications (1)

Publication Number Publication Date
JP2004086236A true JP2004086236A (ja) 2004-03-18

Family

ID=32071942

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002237589A Pending JP2004086236A (ja) 2002-07-03 2002-08-16 メール配信制御方法

Country Status (1)

Country Link
JP (1) JP2004086236A (ja)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006268335A (ja) * 2005-03-23 2006-10-05 Nec Corp 電子メールシステム、電子メールシステムにおけるリンク先のフィルタ方法およびプログラム
JP2007207159A (ja) * 2006-02-06 2007-08-16 Copcom Co Ltd ゲーム運営システム、ゲームサーバ及びゲームプログラム
JP2008034923A (ja) * 2006-07-26 2008-02-14 Ricoh Co Ltd 画像読取装置
JP2010095357A (ja) * 2008-10-17 2010-04-30 Toshiba Elevator Co Ltd エレベータの情報通知システム
JP2010239241A (ja) * 2009-03-30 2010-10-21 Fujitsu Ltd 携帯電話網における電子メールの受信拒否方法及び携帯端末
JP2014149781A (ja) * 2013-02-04 2014-08-21 Ricoh Co Ltd 画像形成装置、情報管理システム、情報管理方法および情報管理プログラム
JP5843997B1 (ja) * 2015-07-07 2016-01-13 株式会社 Post−On オプトアウトサーバ、オプトアウト方法およびオプトアウトプログラム
JP6152521B1 (ja) * 2016-12-05 2017-06-28 株式会社Special Medico 位置通知方法、サーバ及びプログラム
JP2021144722A (ja) * 2016-04-11 2021-09-24 フェイスブック,インク. メッセージングエージェントプラットフォームのための技術
WO2022113654A1 (ja) * 2020-11-24 2022-06-02 株式会社アクリート メッセージ通信方法及びプログラムを記憶した記憶媒体
US11552910B1 (en) 2016-04-11 2023-01-10 Meta Platforms, Inc. Techniques for messaging bot controls based on machine-learning user intent detection
US11729128B1 (en) 2016-09-21 2023-08-15 Meta Platforms, Inc. Module ranking for a modular inbox
US11757820B1 (en) 2016-09-21 2023-09-12 Meta Platforms, Inc. Methods and systems for presenting modules in an inbox interface

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006268335A (ja) * 2005-03-23 2006-10-05 Nec Corp 電子メールシステム、電子メールシステムにおけるリンク先のフィルタ方法およびプログラム
JP2007207159A (ja) * 2006-02-06 2007-08-16 Copcom Co Ltd ゲーム運営システム、ゲームサーバ及びゲームプログラム
JP2008034923A (ja) * 2006-07-26 2008-02-14 Ricoh Co Ltd 画像読取装置
JP2010095357A (ja) * 2008-10-17 2010-04-30 Toshiba Elevator Co Ltd エレベータの情報通知システム
JP2010239241A (ja) * 2009-03-30 2010-10-21 Fujitsu Ltd 携帯電話網における電子メールの受信拒否方法及び携帯端末
JP2014149781A (ja) * 2013-02-04 2014-08-21 Ricoh Co Ltd 画像形成装置、情報管理システム、情報管理方法および情報管理プログラム
JP5843997B1 (ja) * 2015-07-07 2016-01-13 株式会社 Post−On オプトアウトサーバ、オプトアウト方法およびオプトアウトプログラム
US11552910B1 (en) 2016-04-11 2023-01-10 Meta Platforms, Inc. Techniques for messaging bot controls based on machine-learning user intent detection
JP2021144722A (ja) * 2016-04-11 2021-09-24 フェイスブック,インク. メッセージングエージェントプラットフォームのための技術
JP7242750B2 (ja) 2016-04-11 2023-03-20 メタ プラットフォームズ, インク. メッセージングエージェントプラットフォームのための技術
US11729128B1 (en) 2016-09-21 2023-08-15 Meta Platforms, Inc. Module ranking for a modular inbox
US11757820B1 (en) 2016-09-21 2023-09-12 Meta Platforms, Inc. Methods and systems for presenting modules in an inbox interface
JP2018092391A (ja) * 2016-12-05 2018-06-14 株式会社Special Medico 位置通知方法、サーバ及びプログラム
JP6152521B1 (ja) * 2016-12-05 2017-06-28 株式会社Special Medico 位置通知方法、サーバ及びプログラム
WO2022113654A1 (ja) * 2020-11-24 2022-06-02 株式会社アクリート メッセージ通信方法及びプログラムを記憶した記憶媒体
JP2022083234A (ja) * 2020-11-24 2022-06-03 株式会社アクリート メッセージ通信方法及びプログラム

Similar Documents

Publication Publication Date Title
US6175831B1 (en) Method and apparatus for constructing a networking database and system
US8117339B2 (en) Tracking domain name related reputation
US9015263B2 (en) Domain name searching with reputation rating
US10454998B2 (en) Method and system for controlled distribution of information over a network
US7003546B1 (en) Method and system for controlled distribution of contact information over a network
CN1573765B (zh) 数据处理系统、电子邮件系统、附加数据管理方法和程序
US20060095459A1 (en) Publishing domain name related reputation in whois records
US20060095404A1 (en) Presenting search engine results based on domain name related reputation
US20150213131A1 (en) Domain name searching with reputation rating
US20130191402A1 (en) Contact management system and method
US7571220B1 (en) Method and system for managing e-mails
JP2006101474A (ja) メール受信方法、メール受信装置およびメールサーバ
JP2004086236A (ja) メール配信制御方法
JP3371208B1 (ja) 情報配信方法、サーバ及びプログラム
US20040193690A1 (en) Electronic mail distributing apparatus, electronic mail distributing method, program for controlling the method, and storage medium storing the program
JP4097203B2 (ja) 郵便物受領代行システム及び方法
US20220070663A1 (en) Address retrieval systems and methods
JP2000134257A (ja) メール配信装置及びメール配信方法
JP2002132674A (ja) コミュニケーションシステム
JP4401892B2 (ja) メッセージ配送システム、メッセージ配送方法およびメッセージ配送プログラム
JP2002007276A (ja) 電子掲示板システム
JP5362916B2 (ja) メッセージ配信システム
JP4248004B2 (ja) サイトアクセスを必要としないメール送信元確認方法及びメール受信確認方法
JP2003016230A (ja) 図書転貸支援システム、方法、認証サーバ、書籍データベースサーバ、メールサーバ、書籍データベースプログラム、それを記録した記録媒体、メールプログラム及びそれを記録した記録媒体
JP2005208970A (ja) 会員情報管理システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050812

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20071207

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080909

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090127