(57)【特許請求の範囲】
【請求項１】
コンテンツ送信者のコンテンツと、当該コンテンツの宛先と、当該コンテンツに関連して生成される通知の通知条件とを受信した場合に、記憶装置に格納するステップと、
システムの利用状況を記憶装置に記録するステップと、
少なくとも前記利用状況及び前記通知条件に基づき、前記コンテンツの宛先であるユーザによる前記コンテンツへのアクセス状況に応じたイベントの発生を検出するステップと、
前記ユーザによる前記コンテンツへのアクセス状況に応じたイベントが発生したことが検出された場合には、少なくとも前記通知条件及び前記ユーザの通知希望条件に基づき、少なくとも通知先及び通知時期に関する通知態様を決定する通知態様決定ステップと、
を含む通知処理方法。
【請求項２】
前記通知条件が、未受信イベントの発生を検出する時期に関する情報を含むことを特徴とする請求項１記載の通知処理方法。
【請求項３】
前記通知態様決定ステップにおいて、前記通知先に前記コンテンツ送信者が含まれる場合には、前記特定のイベントの発生に応じて通知するか又は後にまとめて通知するかのいずれかを示す付加条件をさらに用いて前記通知時期を判断することを特徴とする請求項１記載の通知処理方法。
【請求項４】
前記システムの利用状況に、コンテンツの宛先であるユーザによるコンテンツの受信拒否指示の情報が含まれることを特徴とする請求項１記載の通知処理方法。
【請求項５】
請求項１乃至４のいずれか１つ記載の通知処理方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明は、電子メールの送受信処理技術に関し、より詳しくは、電子メールの到着、受信等のイベントを送信者や受信者に通知する技術に関する。
【０００２】
【従来の技術】
ウェブ（Ｗｅｂ）メールとは、Ｗｅｂブラウザによるメール送信や閲覧を特徴とするものであり、ユーザはＷｅｂサーバとの通信が可能なＷｅｂブラウザがあれば、特別な又は専用のメーラ等を一切必要とせずメールの送受信が行える。このＷｅｂメール・サービスを提供する配信センタは、メールのコンテンツを管理するメール・サーバと、メールのコンテンツの送信や閲覧、並びに添付ファイルのダウンロード処理を行うためのＷｅｂページを制御するＷｅｂサーバとから構成される。
【０００３】
配信センタのメール・サーバには、Ｗｅｂメールのユーザ宛に届いたコンテンツが保存される。従って通常は新着メールの確認を行うために、ユーザが自主的にＷｅｂブラウザで自らの受信メール一覧のＷｅｂページにアクセスする必要がある。このため、最近では新規のメール到着を受信者に別途通知するサービスも出てきている。すなわち、配信センタにおいて新規のメール着信を通知する到着通知メールを作成し、予め登録された通知先メール・アドレスへ送信するものである。このようにすれば、受信者は自分宛に新規のメールが到着したことをリアルタイムで知ることができる。そして、自分の都合の良いタイミングでコンテンツの閲覧や添付ファイルのダウンロードを行うことができる。
【０００４】
【発明が解決しようとする課題】
このように到着通知メールは有用ではあるが、自分宛のＷｅｂメールが増加すると、全ての自分宛Ｗｅｂメールに対して同じ内容の通知がなされるため、どの到着メールが重要なのかといった判断が困難になり、重要なメールの見落としにつながる可能性がある。また、回数が多くなれば受信者にとってその処理も煩雑になる。
【０００５】
さらに、送信者にとっても重要なメールを送信した場合、受信者のメール閲覧や添付ファイルのダウンロード等が行われたかどうかの確認を行えることが望ましい。配信センタから受信者のメール閲覧や添付ファイルのダウンロード等が行われた場合に確認通知メールを送付するような構成も可能であるが、受信者と同様に送信者も多数の宛先にメールを送信している場合には、配信センタが受信者の行為毎に確認通知メールを送信すると、その処理が煩雑になってしまう。
【０００６】
従って、本発明の目的は、送信者及び受信者の要望を反映させた態様にてメールの到着や受信等についての通知を行うことができるようにするための技術を提供することである。
【０００７】
【課題を解決するための手段】
本発明に係る通知処理方法は、コンテンツ送信者のコンテンツと、当該コンテンツの宛先と、当該コンテンツに関連して生成される通知の通知条件（例えば実施の形態における送信者設定情報）とを受信した場合に、記憶装置に格納するステップと、システムの利用状況（例えば実施の形態におけるアクセス情報及び発生イベント情報）を記憶装置に記録するステップと、少なくとも利用状況及び通知条件に基づき、特定のイベントの発生を検出するステップと、特定のイベントが発生したことが検出された場合には、少なくとも通知条件及び当該特定のイベントに関連するコンテンツの宛先であるユーザの通知希望条件（例えば実施の形態における受信者設定情報）に基づき、少なくとも通知先及び通知時期に関する通知態様を決定する通知態様決定ステップとを含む。このようにすればコンテンツ送信者及びユーザの希望に沿った通知態様にて特定のイベントについて通知がなされるようになる。
【０００８】
なお、上で述べた通知条件は、イベント種別だけの場合もあれば、イベント種別及び通知時期に関する情報を含む場合もある。コンテンツ送信者は必要なイベント等を指定できるようになる。また、通知時期に関する情報は、コンテンツの宛先への通知時期の場合もあれば、コンテンツ送信者宛の通知時期の場合もある。コンテンツ送信者宛の通知時期が設定されれば、コンテンツ送信者はコンテンツ毎に例えばイベントの発生に応じて通知するか又は後にまとめて通知するかのいずれかを選択できるようになる。また、この通知時期に関する情報が、例えば未受信イベントの発生を検出する時期に関する情報である場合もある。見方を変えれば、少なくともコンテンツの宛先であるユーザへの通知時期に関する情報となる。これによりコンテンツの宛先であるユーザに対して、受信を例えば所定の間隔で督促することができるようになる。
【０００９】
さらに、上で述べた通知態様決定ステップにおいて、通知先にコンテンツ送信者が含まれる場合には、特定のイベントの発生に応じて通知するか又は後にまとめて通知するかのいずれかを示す付加条件をさらに用いて通知時期を判断するような構成であってもよい。これにより多数のメールを送信するコンテンツ送信者も、イベント毎ではなくまとめて通知を受けられるようになるため、必要な通知を受けつつも、多数の通知に対する処理から開放されるようになる。
【００１０】
また、上で述べたシステムの利用状況に、コンテンツの宛先であるユーザによるコンテンツの受信拒否指示の情報が含まれるような構成も可能である。これにより、既存のＷｅｂメールにはないダウンロードの拒否を設定でき、ダウンロードの拒否についてもイベントとして取り扱うことができる。
【００１１】
さらに、上で述べたユーザの通知希望条件が、少なくともコンテンツ送信者あるいはコンテンツの種別又はコンテンツ送信者の重要度に関する情報を含むような構成であってもよい。また、少なくともコンテンツ送信者あるいはコンテンツの種別又はコンテンツ送信者毎の通知時期に関する情報であってもよい。これにより、重要度に応じた通知頻度を指定したり、コンテンツ種別又はコンテンツ送信者毎に希望の通知時期を指定できるようになる。
【００１２】
なお、通知時期に関する情報が、イベントの発生に応じて通知するか又は後にまとめて通知するかのいずれかを示す情報である場合もある。例えば重要なのでイベントの発生から直ぐに通知を受けたいものを指定しておいたり、重要性が低いのでまとめて見たいといった要求を満たすことができるようになる。また、どのくらい後でまとめるのかといった情報を設定することも可能である。
【００１３】
また、システムの利用状況のデータを含む、特定のイベントについての通知内容を生成し、通知態様に従って通知処理を実施する通知実施ステップをさらに含むような構成であってもよい。通知手段は、メールだけに限定されず、ＦＡＸや電話その他の手段であってもよい。また、システムの利用状況のデータについては、例えば最終アクセス日時等の情報を含めておけば、システムの利用は行っているのに受信していないのか又はシステムの利用さえも行っていないのかといったことをコンテンツ送信者は判断できるようになる。さらに、上で述べた通知実施ステップが、後にまとめて通知するという通知態様が決定された未通知の特定のイベントの通知のための通知内容を生成し、通知処理を実施するステップを含むような構成であってもよい。既に通知されている特定のイベントについて重ねて通知する必要はないためである。
【００１４】
なお、上で述べた通知実施ステップが、後にまとめて通知するという通知態様が決定された未通知の特定のイベントを、イベント種別又はコンテンツ送信者若しくはコンテンツ種別毎に分類して通知内容を生成し、通知処理を実施するステップを含むような構成であってもよい。このようにすれば、必要なイベントを探しやすくなる。
【００１５】
なお、上述の方法はプログラム及びコンピュータにて実施することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介して配布される場合もある。尚、中間的な処理結果はメモリに一時保管される。
【００１６】
【発明の実施の形態】
本発明の一実施の形態に係るシステム概要図を図１に示す。例えばインターネットであるネットワーク１には、コンテンツを送信する送信者が操作する１又は複数の送信者側装置５と、コンテンツの送信先である受信者が操作する１又は複数の受信者側装置７と、Ｗｅｂメール・サービスを提供し且つ本発明の一実施の形態における主要な処理を実施する配信センタ装置３とが接続されている。
【００１７】
送信者側装置５は、例えばパーソナル・コンピュータ等のコンピュータであって、Ｗｅｂブラウザ５１と、配信センタ装置３により送信され且つコンテンツの送信先である受信者がコンテンツを受信等したことを知らせる通知を受信する通知受信部５３とを含む。Ｗｅｂブラウザ５１には、コンテンツを配信センタ装置３に送信するためのコンテンツ送信部５５が含まれる。また、通知受信部５３は、例えばメーラであるが、本実施の形態において通知は例えば電話やＦＡＸ等でも実施可能であり、その場合には送信者側装置５とは別に設けられる電話機やＦＡＸ機となる場合もある。なお、ここでは説明を簡単にするため、通知受信部５３はメーラであるものとして説明する。
【００１８】
受信者側装置７は、例えばパーソナル・コンピュータ等のコンピュータであって、Ｗｅｂブラウザ７１と、受信者宛にメールが到着した場合や未受信である場合に配信センタ装置３により送信され且つ当該イベントを知らせるための通知を受信する通知受信部７３とを含む。なお、Ｗｅｂブラウザ７１は、コンテンツを配信センタ装置３から受信するためのコンテンツ受信部７５を含む。また、送信者側装置５と同様に、通知受信部７３は、例えばメーラであるが、本実施の形態において通知は例えば電話やＦＡＸ等でも実施可能であり、その場合には受信者側装置７とは別に設けられる電話機やＦＡＸ機となる場合もある。なお、ここでは説明を簡単にするため、通知受信部７３もメーラであるものとして説明する。
【００１９】
配信センタ装置３には、Ｗｅｂサーバ機能を実現し且つ送信者側装置５や受信者側装置７のＷｅｂブラウザからのアクセスに応答する利用者サービス部３３と、送信者設定情報ＤＢ４１を管理しており且つ送信者設定情報を保存・管理する送信者設定情報保存部３４と、受信者設定情報ＤＢ４２を管理しており且つ受信者設定情報を保存・管理する受信者設定情報保存部３５と、送信者側装置５から受信したコンテンツ情報等を蓄積するコンテンツＤＢ４３を管理するコンテンツ蓄積部３６と、送信者側装置５や受信者側装置７からのアクセス情報を蓄積するアクセス情報ＤＢ４４を管理するアクセス情報管理部３７と、発生イベント情報を蓄積する発生イベント情報ＤＢ４５を管理する発生イベント情報管理部３８と、送信者や受信者についてのユーザ情報を蓄積するユーザ情報ＤＢ４６を管理するユーザ情報管理部３９と、各イベントについての通知内容を生成する通知内容作成部３１と、本実施の形態に係るイベント通知処理全体を制御・管理し、通知内容作成部３１が作成した通知内容を送信者又は受信者宛に通知するイベント通知部３２とが含まれる。通知内容作成部３１には、各種通知のためのテンプレートが用意されており、通知内容作成部３１は通知の種類に応じたテンプレートを用いて通知内容を作成させる。
【００２０】
送信者設定情報ＤＢ４１に格納される情報の一例を図２に示す。図２は一人の送信者についての情報であって、送信者設定情報ＤＢ４１には他の送信者のデータについても登録されている。送信者設定情報は、送信すべきコンテンツと共に配信センタ装置３に送信され、送信者設定情報保存部３４により送信者設定情報ＤＢ４１に登録される。送信者設定情報には、図２に示すように、対象コンテンツの情報と、送信者又は受信者に通知を行うイベントの名称である通知イベントの情報と、受信者への通知手段の情報と、送信者への通知手段の情報と、受信者への通知頻度の情報とが含まれる。通知頻度は、ユーザが未受信である場合に督促を送信する頻度についての情報である。見方を変えれば、未受信イベントを発生させる時期についての情報とも言える。イベントには、コンテンツの到着（配信センタ装置３にとっての到着）、受信者による受信完了、受信者がコンテンツを通知頻度に係る期間内に受信していないことを表す未受信、及び受信者が明示的に受信を拒否する受信拒否が含まれる。また、受信者への通知手段としては上で述べたように電子メール（ｅ−ｍａｉｌ）だけでなく、ＦＡＸや電話といった手段であってもよい。送信者への通知手段についても同様である。なお、図示されていないが、送信者への通知頻度という情報を含む場合もある。これは、全ての対象コンテンツに共通の場合もあれば対象コンテンツごとに変更できるようにしても良い。
【００２１】
受信者設定情報ＤＢ４２に格納される情報の一例を図３に示す。図３は一人の利用者についての情報であって、受信者設定情報ＤＢ４２には他の利用者のデータについても登録されている。受信者設定情報は、利用者が例えば配信センタ装置３への利用登録の際に設定するものであって、後に変更することも可能である。受信者設定情報ＤＢ４２への登録や変更については受信者設定情報保存部３５が行う。受信者設定情報には、図３に示すように、送信者の情報と、重要度の情報と、分類の情報とが含まれる。すなわち、送信者毎に重要度と分類が設定されるものである。重要度は、例えば「高」「並」「低」といったレベル分けがなされる。また、分類は、まとめて通知を受ける際の通知（イベント）の分類を行うために用いられる。なお、重要度を設定するような構成を示しているが、後に説明する処理フローにおいては、通知時期を間接的に規定しているものと同様である。従って、例えば通知時期を直接的に設定するような構成であってもよい。すなわち、イベント発生後速やかに通知するか、所定期間まとめておいて例えば所定時刻に通知するかといった情報を設定する。この通知時期についての情報については、例えば送信者毎に設定するのではなく、分類毎に設定する場合や、例えば重要度毎に設定する場合等様々な態様が可能である。ここでは、例えば重要度「高」の場合にはイベント発生後直ぐに通知が行われ、重要度「並」の場合には一定期間（例えば２４時間）まとめて所定時刻（例えば１５時）に通知するといった情報が設定されているものとする。
【００２２】
アクセス情報ＤＢ４４に格納される情報の一例を図４に示す。アクセス情報管理部３７は、例えば利用者がアクセスする毎にユーザＩＤ（又はユーザ名）に対応してアクセス時刻を更新する。すなわち、図４に示すように、アクセス情報には、ユーザ名又はユーザＩＤと、最終アクセス日時とが含まれる。
【００２３】
発生イベント情報ＤＢ４５に格納される情報の一例を図５に示す。発生イベント情報管理部３８は、１つのコンテンツ及び送信先（受信者）の情報が送信者側装置５から送信され且つコンテンツ蓄積部３６に蓄積されると、１つのコンテンツ及び一人の受信者につき１つのレコードを生成し、以降受信者によるダウンロード（受信）や受信拒否、未受信イベント発生毎にデータを更新する。すなわち、発生イベント情報には、図５に示すように、コンテンツ名又はＩＤの情報と、送信者名又はＩＤ、受信者名又はＩＤ、到着日時、受信完了日時、受信拒否日時、未受信イベント発生最終日時が含まれる。未受信については、何回も発生し得るため、最終日時となっている。図５の第１行目のレコードを見ると、コンテンツＡが到着した後速やかに受信者が受信していることがわかる。また、第２行目のレコードを見ると、コンテンツＢが到着した後１週間受信が行われなかったため、未受信イベントが発生している。１週間は図２の送信者設定情報において受信者への通知頻度として設定された期間である。未受信イベントが発生したため受信者に通知がなされ、受信者は未受信イベント発生後５分後には受信を完了している。第３行目のレコードを見ると、コンテンツＣが到着した後１週間受信が行われなかったため、未受信イベントが発生している。１週間は第２行目と同様に送信者設定情報において受信者への通知頻度として設定された期間である。未受信イベントが発生したため受信者に通知がなされ、受信者は未受信イベント発生後３５分後には受信拒否を行っている。第４行目のレコードを見ると、コンテンツＤが到着した後何もイベントは発生していない状態である。
【００２４】
ユーザ情報ＤＢ４６に格納される情報の一例を図６に示す。図６の例では、ユーザ情報には、ユーザ名、電子メール（ｅ−ｍａｉｌ）アドレス、電話番号、ＦＡＸ番号が含まれている。これはイベント通知部３２により通知を行う際の宛先となる。なお、図示されていないが、ユーザＩＤ及びパスワードについても登録されており、認証処理に用いられる。
【００２５】
例えばコンテンツの送信者は配信センタ装置３にアクセスし、送信コンテンツ一覧を見ることができる。この際送信者は送信者側装置５のＷｅｂブラウザ５１を用いて配信センタ装置３にアクセスする。このアクセスに応答して配信センタ装置３の利用者サービス部３３は、送信者側装置５へユーザＩＤ及びパスワードの入力要求を送信する。送信者側装置５のＷｅｂブラウザ５１は、ユーザＩＤ及びパスワードの入力画面を表示して、送信者にユーザＩＤ及びパスワードの入力を促す。送信者がユーザＩＤ及びパスワードを入力して、送信を指示すると、送信者側装置５は入力されたユーザＩＤ及びパスワードを配信センタ装置３に送信する。配信センタ装置３の利用者サービス部３３は、例えばユーザ情報管理部３９に対して受信ユーザＩＤに対応する登録パスワードを要求する。ユーザ情報管理部３９は、ユーザ情報ＤＢ４６を検索して受信ユーザＩＤに対応する登録パスワードを読み出し、利用者サービス部３３に出力する。利用者サービス部３３では、受信パスワードと登録パスワードが一致するか確認することで認証処理を実施する。なお、ユーザ情報管理部３９が認証処理を実施しても良い。そして、受信パスワードと登録パスワードが一致する場合には、認証が成功したものとして以下の処理を実施する。すなわち、アクセス情報管理部３７に本送信者についてのアクセス情報の登録を要求する。なお、認証に失敗した場合にはその旨を送信者側装置５に通知する。
【００２６】
また、送信者が送信コンテンツ一覧の閲覧を希望している場合には、利用者サービス部３３は、発生イベント情報管理部３８に対して当該送信者が送信者として登録されている発生イベントのデータを要求する。発生イベント情報管理部３８は、発生イベント情報ＤＢ４５を検索して当該送信者が送信者として登録されている発生イベントのデータを抽出し、利用者サービス部３３に出力する。利用者サービス部３３は、発生イベントのデータを用いてＷｅｂページ・データを構成し、送信者側装置５に送信する。送信者側装置５のＷｅｂブラウザ５１は、受信したＷｅｂページ・データを表示装置に表示する。
【００２７】
この際表示される画面の一例を図７に示す。ここでは、４件の送信が行われた例を示しており、宛て先の欄、コンテンツ名の欄、到着日時の欄、最新イベントの欄が設けられている。最新イベントについては、発生イベントに対応して記録される日時のうち最新のイベントのイベント名を使用する。到着となっていれば、受信者はまだ見ていない状態である。受信完了であれば例えば添付ファイルのダウンロードが完了した状態である。未受信であれば、所定の期間未受信の状態が続いたことを示している。
【００２８】
送信者は図７の画面を見て、例えば送信したコンテンツを確認する場合には、コンテンツ名の欄のいずれかのコンテンツ名をクリックする。これに応じて送信者側装置５のＷｅｂブラウザ５１は、配信センタ装置３に当該コンテンツの要求を送信する。これに応答して配信センタ装置３の利用者サービス部３３は、送信者から要求されたコンテンツをコンテンツ蓄積部３６に要求する。コンテンツ蓄積部３６は、コンテンツＤＢ４３から要求されたコンテンツを読み出し、利用者サービス部３３に出力する。利用者サービス部３３は、受け取ったコンテンツ情報からＷｅｂページ・データを構成して、送信者側装置５に送信する。また、アクセス情報管理部３７は、送信者についてのアクセス情報を更新する。送信者側装置５のＷｅｂブラウザ５１は、受信したＷｅｂページ・データを表示装置に表示する。これにより、送信者は自らが送信したコンテンツの内容を確認することができるようになる。これ以外にも発生した各イベントの発生日時あるいは送信者設定情報も確認することができる。
【００２９】
次に、コンテンツを送信者側装置５から配信センタ装置３に送信する際の処理について図８乃至図１１を用いて説明する。送信者は、送信者側装置５を操作して、コンテンツ送信のためのＷｅｂページへの移動を指示する。送信者側装置５のＷｅｂブラウザ５１は、コンテンツ送信のためのＷｅｂページへアクセスする。なお、上で一度認証処理を実施しているのでここでは認証処理を必要としないものとするが、まだ認証を実施していない状態であれば、この段階にて認証処理を実施する。
【００３０】
配信センタ装置３の利用者サービス部３３は、コンテンツ送信のためのＷｅｂページ・データを送信者側装置５に送信する。また、アクセス情報管理部３７は、送信者についてのアクセス情報を更新する。送信者側装置５のＷｅｂブラウザ５１は、コンテンツ送信のためのＷｅｂページ・データを受信すると、表示装置に表示する。このコンテンツ送信のためのＷｅｂページでは、コンテンツ名（メールのタイトル）及びコメントの指定、送信先の指定又は送信先の情報を含むファイルの指定、及び図２に示したような送信者設定情報の指定が可能となっている。送信者が所定の入力を行って送信を指示すると、Ｗｅｂブラウザ５１のコンテンツ送信部５５は、コンテンツ（添付ファイル及びコメント）、送信先情報、及び送信者設定情報を配信センタ装置３に送信する。
【００３１】
これに応答して配信センタ装置３の利用者サービス部３３は、送信者側装置５からコンテンツ、送信先情報及び送信者設定情報を受信すると、コンテンツ及び送信先情報をコンテンツ蓄積部３６に出力し、コンテンツ蓄積部３６はコンテンツ及び送信先情報をコンテンツＤＢ４３に登録する。また、利用者サービス部３３は、送信者設定情報を送信者設定情報保存部３４に出力し、送信者設定情報保存部３４は送信者設定情報を送信者設定情報ＤＢ４１に登録する（ステップＳ１：図８）。また、利用者サービス部３３は、発生イベント情報管理部３８にも、送信者及びコンテンツの情報とコンテンツの送信先情報とを出力する。発生イベント情報管理部３８は、新たな発生イベント情報のレコードを生成し、発生イベント情報ＤＢ４５に登録する（ステップＳ３）。すなわち、コンテンツ名又はＩＤと、送信者又はＩＤと、受信者又はＩＤと、コンテンツ到着日時（配信センタ装置３における受信日時）とを含み、受信完了日時、受信拒否日時、最終未受信イベント発生日時が空のレコードを生成して、登録する。なお、アクセス情報管理部３７は、本送信者についてのアクセス情報を更新する。
【００３２】
このようにして発生イベント情報ＤＢ４５に新たなレコードが生成されると、到着イベントが発生したことになり、到着イベントの発生が検出されたことになる。発生イベント情報管理部３８は、イベント通知部３２に当該到着イベントの発生を通知する。イベント通知部３２は、発生イベント情報管理部３８から到着イベントの発生の通知を受けると、送信者設定情報保存部３４を介してこの到着イベントに係るコンテンツの送信者設定情報を取得し、当該コンテンツの送信者設定情報において到着イベントが送信者指定の通知対象イベントとなっているか判断する（ステップＳ７）。もし、通知対象イベントではないと判断された場合には、処理を終了する。一方、到着イベントが通知対象イベントであると判断された場合、イベント通知部３２は、コンテンツの送信先（受信者）にとっての当該コンテンツなどの重要度を受信者設定情報保存部３５を介して受信者設定情報ＤＢ４２から取得し、受信者にとって本コンテンツの重要度が高いか否かを判断する（ステップＳ９）。もし、受信者にとって本コンテンツの重要度が高いわけではない場合（ステップＳ９：Ｎｏルート）、後に詳しく述べる後処理を実施する（ステップＳ１３）。そして処理を終了する。
【００３３】
一方、受信者にとって本コンテンツの重要度が高い場合（ステップＳ９：Ｙｅｓルート）、イベント通知部３２は、送信者が送信者設定情報において設定した受信者への通知手段にて受信者にコンテンツの到着を通知する（ステップＳ１１）。この際、イベント通知部３２は、通知内容作成部３１に到着イベントの通知内容の生成を依頼し、通知内容作成部３１は到着イベントの通知内容を到着イベント用のテンプレートを用いて生成し、イベント通知部３２に出力する。イベント通知部３２は、電子メールや、ＦＡＸ、場合によっては電話にて受信者に対して到着イベントの通知を行う。電話の場合には、例えば音声合成にて到着イベントの通知内容を音声にて通知する。なお、電子メールの場合のメール・アドレス、ＦＡＸの場合のＦＡＸ番号、電話の場合の電話番号は、ユーザ情報管理部３９を介してユーザ情報ＤＢ４６から取得する。
【００３４】
図９に、ステップＳ１１で送信される電子メール又はＦＡＸの一例を示す。ここでは、コンテンツ名、送信者名、到着日時、及びコメントが含まれており、添付ファイルのダウンロードを促す内容となっている。
【００３５】
このような通知態様を採用することにより、受信者にとって重要度が高いコンテンツについての到着イベントについては速やかに通知を行い、あまり重要でないコンテンツの到着イベントについては後にまとめて通知を行うということができるようになる。
【００３６】
一方、ステップＳ９において本コンテンツの重要度が受信者にとって高くないと判断された場合の処理を図１０を用いて説明する。イベント通知部３２は、例えば受信者により設定された指定の時刻又はシステムが設定した指定の時刻まで処理を実施しない（ステップＳ２１）。もし、指定の時刻になると、イベント通知部３２は、受信者設定情報保存部３５を介して受信者設定情報ＤＢ４２から処理対象の受信者の受信者設定情報を取得し、発生イベント情報管理部３８に発生イベント情報ＤＢ４５から指定期間内に当該受信者について発生している処理対象イベント（ここでは到着イベント）の情報を読み出させる。指定期間についても受信者が設定するような構成であってもよい。指定期間内に発生している処理対象イベントか否かについては、処理対象イベントについての発生日時のデータにて判断する。そして、イベント通知部３２は、取得した処理対象イベントの情報から、受信者設定情報において重要度が「高」に設定されていない送信者又はコンテンツについての処理対象イベントの情報を抽出する（ステップＳ２３）。もし重要度が「高」に設定されていれば、図８のステップＳ１１にて到着イベント発生から速やかに通知がなされるため、重要度が「高」以外に設定されているコンテンツ又は送信者についてのイベントは未通知のイベントであると判断できる。このようにするのは、既に通知済みのイベントについての通知を再度行うのは適当ではないからである。イベント通知部３２は、抽出したイベントの情報を通知内容作成部３１に出力する。
【００３７】
なおステップＳ２３の処理については、未通知のイベントについてのキューを例えば通知先毎に用意しておき、図８のステップＳ９で直ぐに送信しないイベントの情報をこのキューに入れておけば、処理が簡単になる。
【００３８】
そして、通知内容作成部３１は、所定の基準に従ってイベントを分類し、処理対象イベントについてのテンプレートを用いて通知内容を作成する（ステップＳ２５）。なお、この分類のため、抽出したイベントに係るコンテンツの送信者設定情報を送信者設定情報保存部３４を介して送信者設定情報ＤＢ４１から取得し、さらに受信者設定情報を受信者設定情報保存部３５を介して受信者設定情報ＤＢ４２から取得する。そして、送信者設定情報に含まれる受信者への通知手段が同じもので一度分類した上で、さらに、受信者設定情報に含まれる分類に従って分類する。例えば、電子メール、電話、ＦＡＸといった通知手段ごとに分けた後に、さらに、公共料金についての到着イベントの情報、株についての到着イベントの情報、取引についての到着イベントの情報等といった分類がなされる。そして、イベント通知部３２は、通知内容作成部３１が生成した通知内容を、送信者が指定した各通知手段にて受信者に通知する（ステップＳ２７）。なお、この際ユーザ情報管理部３９を介してユーザ情報ＤＢ４６から具体的な通知先の情報を取得し、それに基づき通知を行う。
【００３９】
ステップＳ２７において電子メール又はＦＡＸにて送付される通知の一例を図１１に示す。図１１の例では、受信者の重要度が高くない３つの到着イベントが所定期間内に発生しており、公共料金の分類で２件、株の分類で１件となっている。そして、各コンテンツにつき、送信者名及び到着日時が示されている。
【００４０】
このような処理により、受信者にとって重要でもないコンテンツの到着イベント毎に通知が行われて煩わしい処理を行うといったことがなくなり、重要なコンテンツの到着イベントを見落としたりすることがなくなる。
【００４１】
なお、本実施の形態では到着イベントでは通知先は受信者のみになっているが、必ずしもこれに限定されるものではない。また、図１０の処理フローでは、送信者設定情報に設定されている受信者への通知手段毎に通知を分けるような構成を示したが、例えば最も指定の多い通知手段に集約してしまうといった方法を採用するようにしても良い。
【００４２】
一方、利用者は配信センタ装置３にアクセスし、到着コンテンツ一覧を見ることができる。これは到着イベント発生の通知を受けてからであってもよいし、そうでなくともよい。この際受信者側装置７のＷｅｂブラウザ７１を用いて配信センタ装置３にアクセスする。このアクセスに応答して配信センタ装置３の利用者サービス部３３は、受信者側装置７へユーザＩＤ及びパスワードの入力要求を送信する。受信者側装置７のＷｅｂブラウザ７１は、ユーザＩＤ及びパスワードの入力画面を表示して、利用者にユーザＩＤ及びパスワードの入力を促す。利用者がユーザＩＤ及びパスワードを入力して、送信を指示すると、受信者側装置７のＷｅｂブラウザ７１は入力されたユーザＩＤ及びパスワードを配信センタ装置３に送信する。配信センタ装置３の利用者サービス部３３は、例えばユーザ情報管理部３９に対して受信ユーザＩＤに対応する登録パスワードを要求する。ユーザ情報管理部３９は、ユーザ情報ＤＢ４６を検索して受信ユーザＩＤに対応する登録パスワードを読み出し、利用者サービス部３３に出力する。利用者サービス部３３では、受信パスワードと登録パスワードが一致するか確認することで認証処理を実施する。そして、受信パスワードと登録パスワードが一致する場合には、認証が成功したものとして以下の処理を実施する。すなわち、アクセス情報管理部３７に本利用者についてのアクセス情報の登録を要求する。なお、認証に失敗した場合には、認証に失敗した旨を受信者側装置７に通知する。
【００４３】
また、利用者が到着コンテンツ一覧の閲覧を希望している場合には、発生イベント情報管理部３８に対して当該利用者が受信者として登録されている発生イベントのデータを要求する。発生イベント情報管理部３８は、発生イベント情報ＤＢ４５を検索して当該利用者が受信者として登録されている発生イベントのデータを抽出し、利用者サービス部３３に出力する。なお、受信完了が記録されているコンテンツを除外してもよい。利用者サービス部３３は、発生イベントのデータを用いてＷｅｂページ・データを構成し、受信者側装置７に送信する。受信者側装置７のＷｅｂブラウザ７１は、受信したＷｅｂページ・データを表示装置に表示する。
【００４４】
この際表示される画面の一例を図１２に示す。ここでは、４件受信したコンテンツがある例を示しており、コンテンツ名の欄、到着日時の欄、送信者名の欄が設けられている。利用者は図１２の画面を見て、例えば到着したコンテンツを確認する場合には、コンテンツ名の欄のいずれかのコンテンツ名をクリックする。これに応じて受信者側装置７のＷｅｂブラウザ７１は、配信センタ装置３に当該コンテンツの要求を送信する。これに応答して配信センタ装置３の利用者サービス部３３は、利用者から要求されたコンテンツをコンテンツ蓄積部３６に要求する。コンテンツ蓄積部３６は、コンテンツＤＢ４３から要求されたコンテンツを読み出し、利用者サービス部３３に出力する。利用者サービス部３３は、受け取ったコンテンツ情報からＷｅｂページ・データを構成して、受信者側装置７に送信する。また、アクセス情報管理部３７は、当該利用者についてのアクセス情報を更新する。受信者側装置７のＷｅｂブラウザ７１は、受信したＷｅｂページ・データを表示装置に表示する。
【００４５】
この際表示される画面の一例を図１３に示す。これは一つの到着コンテンツの詳細情報であって、コンテンツ名、送信者名、到着日時、格納ファイル数、総ファイルサイズ、コメントが含まれている。また、添付ファイルをダウンロードするための「受信する」ボタンと、受信拒否を登録するための「受信を拒否する」ボタンも設けられている。以下、図１４及び図１５を用いて「受信する」ボタンがクリックされた場合の処理について説明する。また、図１６及び図１７を用いて「受信を拒否する」ボタンがクリックされた場合の処理について説明する。
【００４６】
もし、「受信する」ボタンがクリックされると、受信者側装置７のＷｅｂブラウザ７１は、添付ファイルのダウンロードの指示を配信センタ装置３に送信する。配信センタ装置３の利用者サービス部３３は、添付ファイルのダウンロードの指示を受信すると、コンテンツ蓄積部３６に指定の添付ファイルを要求する。コンテンツ蓄積部３６は、指定された添付ファイルをコンテンツＤＢ４３から読み出して、例えば利用者サービス部３３に出力し、利用者サービス部３３は受信者側装置７に送信する（ステップＳ３１：図１４）。また、アクセス情報管理部３７は、当該利用者についてのアクセス情報を更新する。受信者側装置７のコンテンツ受信部７５は、配信センタ装置３から添付ファイルを受信すると共に、例えば受信者側装置７の記憶装置に格納する。指定された添付ファイルのダウンロードが完了すると、利用者サービス部３３は発生イベント情報管理部３８に、当該添付ファイルに係るコンテンツの当該利用者によるダウンロード完了を通知する。発生イベント情報管理部３８は、当該コンテンツ及び利用者（受信者）の組み合わせについてのレコードにおいて受信完了日時を発生イベント情報ＤＢ４５に登録する（ステップＳ３３）。
【００４７】
このように発生イベント情報ＤＢ４４に受信完了日時が登録されると、受信完了イベントが発生したことになり、受信完了イベントの発生が検出されたことになる。発生イベント情報管理部３８は、受信完了イベントの発生をイベント通知部３２に通知する。イベント通知部３２は、当該受信完了イベントに係るコンテンツについての送信者設定情報を、送信者設定情報保存部３４を介して送信者設定情報ＤＢ４１から取得し、当該受信完了イベントは送信者指定の通知対象イベントか判断する（ステップＳ３５）。もし、当該コンテンツについて受信完了が通知対象イベントとして指定されていなければ、処理を終了する。
【００４８】
一方、当該コンテンツについて受信完了が通知対象イベントとして指定されている場合には、イベント通知部３２は、通知内容作成部３１に通知内容の作成を要求し、通知内容作成部３１は、受信完了通知用のテンプレートを用いて通知内容を作成し、イベント通知部３２に出力する。そして、イベント通知部３２は、送信者設定情報に含まれる送信者への通知手段に従って、通知内容作成部３１が生成した通知内容を送信者宛に通知する（ステップＳ３７）。具体的な通知先については、ユーザ情報管理部３９を介してユーザ情報ＤＢ４６から取得する。
【００４９】
電子メール又はＦＡＸにて送付される通知の一例を図１５に示す。図１５の例では、コンテンツの送付先（受信者）名と、コンテンツ名、到着日時及び受信日時が含まれる。
【００５０】
これにより、送信者は希望どおり、コンテンツの送信先である受信者がコンテンツの受信を完了したことを知ることができる。通知手段についても希望のとおりに用いられる。なお、本実施の形態では受信完了イベントについて、送信者のみが通知先になっているが、これに限定されるものではない。
【００５１】
但し、送信者は非常に多数の利用者向けにコンテンツを送付する場合がある。そのような場合に、図１４の処理フローでは、コンテンツを受信する利用者が現れる度に通知がなされ、送信者はこの通知の処理に忙殺されることになる。従って、送信者への通知についても、所定期間内に発生したイベントをまとめて所定の時刻に通知するような構成であってもよい。すなわち、送信者設定情報又はユーザ情報に所定期間及び所定の時刻についての情報が含まれている場合、又はシステム側で設定されている場合には、例えば図１０のような処理を実施すればよい。なお、通知先を受信者ではなく送信者にする。また、各送信者用のキューを別途設けておき、発生したイベントの情報をそこに蓄積しておき、所定の時刻がくるとキュー内の発生イベント情報を基に通知を作成して送付するような構成であってもよい。なお、コンテンツやイベントの種類によって、分類を行った上で通知を作成しても良い。
【００５２】
また図１３のような表示がなされている場面において、「受信を拒否する」ボタンがクリックされると、受信者側装置７のＷｅｂブラウザ７１は、当該添付ファイルの受信拒否指示を配信センタ装置３に送信する。配信センタ装置３の利用者サービス部３３は、当該コンテンツの当該利用者による受信拒否を発生イベント情報管理部３８に通知する。発生イベント情報管理部３８は、当該コンテンツ及び利用者（受信者）の組み合わせについてのレコードにおいて受信拒否日時を発生イベント情報ＤＢ４５に登録する（ステップＳ４１：図１６）。また、アクセス情報管理部３７は、当該利用者についてのアクセス情報を更新する。
【００５３】
このように発生イベント情報ＤＢ４５に受信拒否日時が登録されると、受信拒否イベントが発生したことになり、受信拒否イベントの発生が検出されたことになる。発生イベント情報管理部３８は、受信拒否イベントの発生をイベント通知部３２に通知する。イベント通知部３２は、受信拒否に係るコンテンツの送信者設定情報を送信者設定情報保存部３４を介して送信者設定情報ＤＢ４１から取得し、当該コンテンツについての受信拒否イベントが送信者指定の通知対象イベントであるか判断する（ステップＳ４３）。もし、当該コンテンツについての受信拒否イベントが送信者指定の通知対象イベントではない場合には、処理を終了する。
【００５４】
一方、本受信拒否イベントが送信者指定の通知対象イベントではある場合には、イベント通知部３２は、通知内容作成部３１に通知内容の作成を要求し、通知内容作成部３１は、受信拒否イベント用のテンプレートを用いて通知内容を作成し、イベント通知部３２に出力する。そして、イベント通知部３２は、送信者設定情報に含まれる送信者への通知手段に従って、通知内容作成部３１が生成した通知内容を送信者宛に通知する（ステップＳ４５）。具体的な通知先の情報については、ユーザ情報管理部３９を介してユーザ情報ＤＢ４６から取得する。
【００５５】
電子メール又はＦＡＸにて送付される通知の一例を図１７に示す。図１７の例では、コンテンツの送付先（受信者）名と、コンテンツ名、到着日時及び受信拒否日時が含まれる。
【００５６】
これにより、送信者は希望どおり、コンテンツの送信先である受信者がコンテンツの受信を拒否したことを知ることができる。通知手段についても希望のとおりに用いられる。なお、ここでは送信者のみについて通知する構成を示したが、これに限定されるものではない。
【００５７】
但し、送信者は非常に多数の利用者向けにコンテンツを送付する場合がある。そのような場合に、図１６の処理フローでは、コンテンツ受信を拒否する利用者が現れる度に通知がなされ、送信者はこの通知の処理に忙殺されることになる。従って、送信者への通知についても、所定期間内に発生したイベントをまとめて所定の時刻に通知するような構成であってもよい。これは受信イベント発生の場合と同様である。
【００５８】
以上は、コンテンツ送信者又は受信者が何らかのアクションを実施した場合の処理であったが、コンテンツの送信先の利用者がいつまでもコンテンツをダウンロードしない場合もある。この場合には、コンテンツの送信先の利用者に督促を行い且つ受信がない旨の通知を送信者にも送るべきである。以下、図１８乃至図２１を用いてコンテンツ未受信の場合の処理について説明する。
【００５９】
発生イベント情報管理部３８は、所定のタイミングにて送信者設定情報保存部３４を介して送信者設定情報ＤＢ４１から、各コンテンツの通知頻度の情報を取得しておく。そして、コンテンツ毎に送信者指定の通知頻度に係る期間内に当該コンテンツの受信及び受信拒否がなされていない、すなわち受信完了日時及び受信拒否日時が発生イベント情報ＤＢ４５に登録されていないという未受信イベントが発生したレコードを検出し、当該レコードに対して最終未受信イベント発生日時に日時を登録する（ステップＳ５１）。未受信イベントの発生と検出はここでは一致している。そして、発生イベント情報管理部３８は、当該未受信イベント発生をイベント通知部３２に通知する。イベント通知部３２は、当該コンテンツの送信者設定情報を送信者設定情報保存部３４を介して送信者設定情報ＤＢ４１から取得し、未受信イベントが送信者指定の通知対象イベントであるかを判断する（ステップＳ５３）。もし、送信者が指定した通知対象イベントではない場合には処理を終了する。
【００６０】
一方、送信者が通知対象イベントに指定している場合には、当該未受信イベントに係るコンテンツの送信先（受信者）の受信者設定情報を受信者設定情報保存部３５を介して受信者設定情報ＤＢ４２から取得し、当該受信者設定情報に含まれる当該コンテンツについての重要度が高いか否かを判断する（ステップＳ５５）。もし、重要度が高くない場合には、ステップＳ５９に移行して図１０で説明した処理を実施する。
【００６１】
未受信イベントの場合に図１０のステップＳ２７で送信される電子メールの一例を図１９に示す。ここでは、まとめて通知することになった３件の未受信イベントが存在しており、２件が公共料金についての未受信イベントであり、１件が株についての未受信イベントである。なお、通知内容作成部３１は、発生イベント情報に含まれる到着日時と最終未受信イベント発生日時との差から何日間未受信であるかを計算し、その情報についても通知内容に含ませている。
【００６２】
また、当該コンテンツの重要度が高いと判断される場合には、イベント通知部３２は、通知内容作成部３１に本未受信イベントについての通知内容の作成を要求し、通知内容作成部３１は受信者宛未受信イベント用のテンプレートを用いて作成した通知内容をイベント通知部３２に出力する。イベント通知部３２は、送信者設定情報において指定されている受信者への通知手段にて、コンテンツの送信先（受信者）に通知する（ステップＳ５７）。なお、この際、ユーザ情報管理部３９に対して通知手段に対応する通知先情報を要求し、ユーザ情報管理部３９はユーザ情報ＤＢ４６から要求された通知先情報を取得する。例えば電子メールであれば電子メール・アドレスを取得し、ＦＡＸであればＦＡＸ番号を取得し、電話であれば電話番号を取得する。
【００６３】
このようにすれば、自ら重要と指定されているのにもかかわらず受信していない利用者に未受信を通知することができるので、利用者はコンテンツの到着を再認識することができるようになる。
【００６４】
ステップＳ５７において電子メール又はＦＡＸで送付される通知の一例を図２０に示す。この通知には、重要な未受信イベントであるから１つの未受信イベントについての情報が含まれている。図２０の例では、コンテンツ名、送信者、到着日時、経過日数及びコメントが含まれている。経過日数については、通知内容作成部３１が、発生イベント情報に含まれる到着日時と最終未受信イベント発生日時との差を計算することにより求められる。
【００６５】
図１８の説明に戻って、ステップＳ５７の後に、発生イベント情報管理部３８は、当該未受信イベントが同一コンテンツ及び同一送信先（受信者）の組み合わせについて３回以上発生しているかを判断する（ステップＳ６１）。３回は一例であって、他の回数を基準にすることも可能である。この回数を送信者が設定するようにしても良い。回数については、到着日時と最終未受信イベント発生日時との差を通知頻度に係る期間で除すれば計算できる。もし、未受信イベント発生回数が、同一コンテンツ及び同一送信先の組み合わせについて３回未満であれば処理を終了する。もし、３回以上であれば、イベント通知部３２は、通知内容作成部３１に未受信イベントについての通知内容の作成を要求し、通知内容作成部３１は、送信先宛未受信イベント用のテンプレートを用いて通知内容を作成してイベント通知部３２に出力する。そして、イベント通知部３２は、送信者設定情報に含まれる送信者への通知手段に従って、通知内容作成部３１が生成した通知内容を送信者宛に通知する（ステップＳ６３）。なおこの際、ユーザ情報管理部３９に対して通知手段に対応する通知先情報を要求し、ユーザ情報管理部３９はユーザ情報ＤＢ４６から要求された通知先情報を取得して、イベント通知部３２に出力する。
【００６６】
ステップＳ６３にて電子メール又はＦＡＸにより送付される通知の一例を図２１に示す。図２１の例では、コンテンツ名、宛先（受信者）名、到着日時、経過日数、最終アクセス日時、受信者連絡先情報が含まれる。最終アクセス日時については、アクセス情報管理部３７を介してアクセス情報ＤＢ４４から取得する。最終アクセス日時より到着日時が前であれば、受信する機会はあったが受信していないことがわかり、最終アクセス日時より到着日時が後であれば、最近全く受信しておらず受信する機会も無かったことがわかる。最終アクセス日時に代わって、「最近アクセスしていない」や「ｘｘｘｘｘにアクセスがありましたが、受信されませんでした」というコメントを含めるような構成であってもよい。また、受信者連絡先情報については、ユーザ情報管理部３９を介してユーザ情報ＤＢ４６から取得する。
【００６７】
これにより、送信者は希望どおり、コンテンツの送信先の利用者がコンテンツの受信を通知頻度により特定される期間内に行っていないことを知ることができる。
【００６８】
但し、送信者は非常に多数の利用者向けにコンテンツを送付する場合がある。そのような場合に、図１８の処理フローでは、当該コンテンツを未受信である利用者毎に通知がなされ、送信者はこの通知の処理に忙殺されることになる。従って、送信者への通知についても、所定期間内に発生したイベントをまとめて所定の時刻に通知するような構成であってもよい。なお、未受信イベントのみをまとめて通知するような構成であってもよい。
【００６９】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されない。例えば、図１に示した配信センタ装置３の機能ブロック分けは一例であって、実際のプログラム・モジュール分けに対応するものでは必ずしもない。また、配信センタ装置３は、１台のコンピュータではなく、複数台のコンピュータにて実現するようにしてもよい。送信者側装置５及び受信者側装置７についても、パーソナル・コンピュータだけではなく、ＰＤＡ（Personal Digital Assistant）や携帯電話機の場合もある。一人の利用者が複数の端末を用いて利用する場合もある。また、図７、図１２及び図１３に示した画面例も一例であって、同様の内容であれば他の画面構成であってもよい。図９、図１１、図１５、図１７、図１９、図２０及び図２１の通知内容は一例であって、より多くの情報を含めたり、一部の情報を削除する等が可能である。
【００７０】
（付記１）
コンテンツ送信者のコンテンツと、当該コンテンツの宛先と、当該コンテンツに関連して生成される通知の通知条件とを受信した場合に、記憶装置に格納するステップと、
システムの利用状況を記憶装置に記録するステップと、
少なくとも前記利用状況及び前記通知条件に基づき、特定のイベントの発生を検出するステップと、
前記特定のイベントが発生したことが検出された場合には、少なくとも前記通知条件及び当該特定のイベントに関連するコンテンツの宛先であるユーザの通知希望条件に基づき、少なくとも通知先及び通知時期に関する通知態様を決定する通知態様決定ステップと、
を含む通知処理方法。
【００７１】
（付記２）
前記通知条件が、少なくともイベント種別及び通知時期に関する情報を含む付記１記載の通知処理方法。
【００７２】
（付記３）
前記通知時期に関する情報が、未受信イベントの発生を検出する時期に関する情報を含むことを特徴とする付記２記載の通知処理方法。
【００７３】
（付記４）
前記通知時期に関する情報が、少なくともコンテンツの宛先であるユーザへの通知時期に関する情報を含むことを特徴とする付記２記載の通知処理方法。
【００７４】
（付記５）
前記通知態様決定ステップにおいて、前記通知先に前記コンテンツ送信者が含まれる場合には、前記特定のイベントの発生に応じて通知するか又は後にまとめて通知するかのいずれかを示す付加条件をさらに用いて前記通知時期を判断することを特徴とする付記１乃至４のいずれか１つ記載の通知処理方法。
【００７５】
（付記６）
前記システムの利用状況に、コンテンツの宛先であるユーザによるコンテンツの受信拒否指示の情報が含まれることを特徴とする付記１乃至５のいずれか１つ記載の通知処理方法。
【００７６】
（付記７）
前記ユーザの通知希望条件が、少なくともコンテンツ送信者あるいはコンテンツの種別又はコンテンツ送信者の重要度に関する情報を含むことを特徴とする付記１乃至６のいずれか１つ記載の通知処理方法。
【００７７】
（付記８）
前記ユーザの通知希望条件が、少なくともコンテンツ送信者あるいはコンテンツの種別又はコンテンツ送信者毎の通知時期に関する情報であることを特徴とする付記１乃至７のいずれか１つ記載の通知処理方法。
【００７８】
（付記９）
前記通知時期に関する情報が、イベントの発生に応じて通知するか又は後にまとめて通知するかのいずれかを示す情報であることを特徴とする付記８記載の通知処理方法。
【００７９】
（付記１０）
前記システムの利用状況のデータを含む、前記特定のイベントについての通知内容を生成し、前記通知態様に従って通知処理を実施する通知実施ステップ
をさらに含む付記１乃至９のいずれか１つ記載の通知処理方法。
【００８０】
（付記１１）
前記通知実施ステップが、
後にまとめて通知するという通知態様が決定された未通知の前記特定のイベントの通知のための通知内容を生成し、通知処理を実施するステップ
を含む付記１０記載の通知処理方法。
【００８１】
（付記１２）
前記通知実施ステップが、
後にまとめて通知するという通知態様が決定された未通知の前記特定のイベントを、イベント種別又はコンテンツ送信者若しくはコンテンツ種別毎に分類して通知内容を生成し、通知処理を実施するステップ
を含む付記１０記載の通知処理方法。
【００８２】
（付記１３）
付記１乃至１２のいずれか１つ記載の通知処理方法をコンピュータに実行させるためのプログラム。
【００８３】
（付記１４）
コンテンツ送信者のコンテンツと、当該コンテンツの宛先と、当該コンテンツに関連して生成される通知の通知条件とを受信した場合に、記憶装置に格納する手段と、
システムの利用状況を記憶装置に記録する手段と、
少なくとも前記利用状況及び前記通知条件に基づき、特定のイベントの発生を検出する手段と、
前記特定のイベントが発生したことが検出された場合には、少なくとも前記通知条件及び当該特定のイベントに関連するコンテンツの宛先であるユーザの通知希望条件に基づき、少なくとも通知先及び通知時期に関する通知態様を決定する通知態様決定手段と、
を有する通知処理システム。
【００８４】
【発明の効果】
本発明によれば、送信者及び受信者の要望を反映させた態様にてメールの到着や受信等についての通知を行うことができるようになる。
【図面の簡単な説明】
【図１】  本発明の一実施の形態に係るシステム概要を説明するための図である。
【図２】  送信者設定情報の一例を示す図である。
【図３】  受信者設定情報の一例を示す図である。
【図４】  アクセス情報の一例を示す図である。
【図５】  発生イベント情報の一例を示す図である。
【図６】  ユーザ情報の一例を示す図である。
【図７】  送信者に示す送信コンテンツ一覧画面の一例である。
【図８】  コンテンツ送信時におけるイベント通知処理の処理フローを示す図である。
【図９】  受信者にとっての重要度が高いコンテンツの到着イベントにおいて送付される通知の一例を示す図である。
【図１０】  後でまとめてイベントの通知を行う際の処理フローを示す図である。
【図１１】  受信者にとっての重要度が低いコンテンツの到着イベントにおいて送付される通知の一例を示す図である。
【図１２】  利用者に示す到着コンテンツ一覧画面の一例を示す図である。
【図１３】  利用者に示す到着コンテンツ詳細画面を示す図である。
【図１４】  コンテンツ受信時におけるイベント通知処理の処理フローを示す図である。
【図１５】  送信者に通知される受信完了イベントの通知の一例を示す図である。
【図１６】  受信拒否時におけるイベント通知処理の処理フローを示す図である。
【図１７】  送信者に通知される受信拒否イベントの通知の一例を示す図である。
【図１８】  未受信イベント発生時におけるイベント通知処理の処理フローを示す図である。
【図１９】  受信者にとって重要度が低いコンテンツの未受信イベントにおいて送付される通知の一例を示す図である。
【図２０】  受信者にとって重要度が高いコンテンツの未受信イベントにおいて送付される通知の一例を示す図である。
【図２１】  送信者に通知される未受信イベントの通知の一例を示す図である。
【符号の説明】
１  ネットワーク    ３  配信センタ装置
５  送信者側装置    ７  受信者側装置
３１  通知内容作成部    ３２  イベント通知部
３３  利用者サービス部    ３４  送信者設定情報保存部
３５  受信者設定情報保存部    ３６  コンテンツ蓄積部
３７  アクセス情報管理部    ３８  発生イベント情報管理部
３９  ユーザ情報管理部    ４１  送信者設定情報ＤＢ
４２  受信者設定情報ＤＢ    ４３  コンテンツＤＢ
４４  アクセス情報ＤＢ    ４５  発生イベント情報ＤＢ
４６  ユーザ情報ＤＢ
【図１】
0003821710.tif 000002
【図２】
0003821710.tif 000003
【図３】
0003821710.tif 000004
【図４】
0003821710.tif 000005
【図５】
0003821710.tif 000006
【図６】
0003821710.tif 000007
【図７】
0003821710.tif 000008
【図８】
0003821710.tif 000009
【図９】
0003821710.tif 000010
【図１０】
0003821710.tif 000011
【図１１】
0003821710.tif 000012
【図１２】
0003821710.tif 000013
【図１３】
0003821710.tif 000014
【図１４】
0003821710.tif 000015
【図１５】
0003821710.tif 000016
【図１６】
0003821710.tif 000017
【図１７】
0003821710.tif 000018
【図１８】
0003821710.tif 000019
【図１９】
0003821710.tif 000020
【図２０】
0003821710.tif 000021
【図２１】
0003821710.tif 000022