JP3982622B2 - 電子メール送信装置 - Google Patents
電子メール送信装置 Download PDFInfo
- Publication number
- JP3982622B2 JP3982622B2 JP2003042585A JP2003042585A JP3982622B2 JP 3982622 B2 JP3982622 B2 JP 3982622B2 JP 2003042585 A JP2003042585 A JP 2003042585A JP 2003042585 A JP2003042585 A JP 2003042585A JP 3982622 B2 JP3982622 B2 JP 3982622B2
- Authority
- JP
- Japan
- Prior art keywords
- transmission
- target person
- theoretical value
- list
- 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.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/214—Monitoring or handling of messages using selective forwarding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/23—Reliability checks, e.g. acknowledgments or fault reporting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/48—Message addressing, e.g. address format or anonymous messages, aliases
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、対象者に対して電子メール等を用いて情報を伝達するための手法に係り、特に、複数の連絡先(例えばメールアドレス)を所有する対象者に対してより的確に情報を伝達するための手法に関する。
【０００２】
【従来の技術】
近年、個人が所有する情報受信手段は多岐にわたっている。この種の情報受信手段として電子メールを例にとると、会社のＰＣ(Personal Computer)で使用するメールアドレス、自宅のＰＣで使用するメールアドレス、携帯電話やＰＤＡで使用するメールアドレス等がある。そして、個人が所有する情報受信端末の数が増えるほど、使用可能なメールアドレスも増大していく傾向にある。
【０００３】
このような状況の中で、情報発信者(連絡者)は、情報受信者(送信対象者)に対して適切に情報を送信することが要求される。例えば連絡者が送信対象者の自宅のＰＣに設定されたメールアドレスを宛先として電子メールを送信したとしても、そのときに送信対象者が自宅にいなければ、送信対象者が送信された電子メールを直ちに受け取ることはできない。また、情報発信者が送信対象者の所有しているすべてのメールアドレスを宛先として情報を送信した場合には、確かに、送信対象者が送信された電子メールを直ちに受け取ることは可能かもしれないが、情報のトラフィック量が増大してしまうという問題がある。
このような複数のメールアドレスを所有する送信対象者に対して電子メールを送信する技術としては、従来、特許文献１に記載される技術が提案されている。なお、特許文献１には、送信先のメールアドレスが所定期間使用されていないときに、このメールアドレスを削除する点が開示されている。
【０００４】
【特許文献１】
特開２００２−２６９６１号公報(第１１頁、図９)
【０００５】
【発明が解決しようとする課題】
しかしながら、所定期間使用されていないメールアドレスを削除したとしても、情報のトラフィック量の増大を根本的に解決することは困難である。
また、特許文献１には、連絡者の現在位置情報と送信対象者の現在位置情報とに基づいて対象者のメールアドレスを選択する技術が記載されているが、送信対象者の現在位置に誤りがあった場合には、送信対象者に情報を伝達できなくなるという問題がある。
【０００６】
本発明は、以上の技術的課題を解決するためになされたものであって、その目的とするところは、複数のメールアドレスや連絡先を有する対象者に対して、的確に情報を伝達することにある。
本発明の他の目的は、情報のトラフィック量の増大を抑えつつ、対象者に対して的確に情報を伝達することにある。
本発明のさらに他の目的は、対象者から得られる現在位置情報等の送信対象者の現在の状況を示す情報が少ない場合にも、対象者に対して的確に情報を伝達することにある。
【０００７】
【課題を解決するための手段】
かかる目的のもと、本発明は、複数のメールアドレスを所有する送信対象者に対して、この送信対象者が電子メールを受け取れる可能性が高い順に電子メールを送信することを提案する。また、電子メールの送信結果、すなわち、どの電子メールアドレスで送信対象者が電子メールを受け取ったかという結果を、次に電子メールを送信する際の送信順序に反映させることを提案する。
すなわち、本発明の電子メール送信装置は、複数のメールアドレスを所有する送信対象者に対して電子メールを送信する電子メール送信装置であって、送信対象者の状況とメールアドレスとが対応付けされて格納される記憶手段と、送信対象者に対して電子メールを送信する際に送信対象者がおかれている状況を予測する予測手段と、予測された状況に基づいて、記憶手段から所定数のメールアドレスを取り出すと共に、取り出した所定数のメールアドレスを順位付けする順位付け手段と、順位付けがなされた所定数のメールアドレスを用いて、電子メールを順次送信する送信手段とを含んでいる。
【０００８】
ここで、予測手段は、送信対象者のスケジュールを取得し、取得したスケジュールに基づいて状況を予測することを特徴とすることができる。また、送信手段によって送信された電子メールに対して、所定のメールアドレスから返信された受け取り確認を受信する受信手段をさらに含み、送信手段は、受け取り確認を受信した場合に電子メールの送信を中止することを特徴とすることができる。さらに、送信手段によって送信された電子メールに対して、所定のメールアドレスから返信された受け取り確認を受信する受信手段をさらに含み、順位付け手段は、次の順位付けにおいて所定のメールアドレスの順位を変更することを特徴とすることができる。さらにまた、順位付け手段は、予測手段によって予測された状況に合致するメールアドレスを記憶手段から取り出すことを特徴とすることができる。
【０００９】
また、他の観点から捉えると、本発明の電子メール送信装置は、複数のメールアドレスを所有する送信対象者に対して電子メールを送信する電子メール送信装置であって、送信対象者の送信希望条件と送信対象者が送信を希望するメールアドレスとを関連付けたレコードを記憶する記憶手段と、送信対象者に対して電子メールを送信する際に送信対象者がおかれると想定される状況を取得する状況取得手段と、状況取得手段によって取得された状況に適合するレコードを記憶手段より取得して送信希望リストを作成する送信リスト作成手段と、送信対象者に対する電子メールの届きやすさに関する理論値を作成する理論値作成手段と、理論値作成手段によって作成された理論値に基づいて、送信リスト作成手段で作成された送信リスト中のメールアドレスを順位付けして送信優先順位リストを作成する送信優先順位リスト作成手段と、送信優先順位リスト作成手段によって作成された送信優先順位リストに基づいて、優先順位の高いメールアドレスから順に電子メールを送信する送信手段とを含んでいる。
【００１０】
この電子メール送信装置では、送信手段によって送信された電子メールの受け取り確認を受信する受信手段をさらに含み、理論値作成手段は、受信手段によって受信された受け取り確認に基づいて理論値を修正することを特徴とすることができる。また、送信希望条件と、送信手段による電子メールの送信試行回数および受信手段による受け取り確認回数とを関連付けて格納するカウント格納手段と、カウント格納手段に格納されたカウント値に基づいて、各送信希望条件に対応する期待値を作成する期待値作成手段とをさらに備え、理論値作成手段は、期待値作成手段で作成された期待値に基づいて理論値を修正することができる。さらに、予め送信対象者によって設定された送信希望条件の優先順位のリストを格納する初期優先順位格納手段をさらに含み、理論値作成手段は、初期優先順位格納手段より取得した初期優先順位リストに基づいて最初の理論値を決定することを特徴とすることができる。
【００１１】
また、本発明は、上述した電子メール送信装置の他、連絡先案内装置としても捉えることができる。
すなわち、本発明の連絡先案内装置は、複数の連絡先を有する対象者に対して連絡を行う際に、連絡者に連絡先を案内する連絡先案内装置であって、対象者の状況と連絡先との対応関係を取得する取得手段と、対象者に対して連絡を行う際に対象者がおかれる状況を予測する予測手段と、予測された状況に基づいて、取得手段により所定数の連絡先を取得すると共に、取得した所定数の連絡先を順位付けする順位付け手段とを含んでいる。
【００１２】
この連絡先案内装置において、取得手段によって取得される連絡先は、電子メールアドレス、電話番号、ファクシミリ番号の少なくともいずれか一つを含むことを特徴とすることができる。また、順位付け手段は、順位付けに基づいて連絡を行った結果を次の順位付けに反映させることを特徴とすることができる。
【００１３】
また、本発明はコンピュータに、所定の送信対象者に対する複数のメールアドレスが格納された記憶装置から、特定のメールアドレスに対して電子メールを送信させるプログラムであって、送信対象者に対して電子メールを送信する際に送信対象者がおかれた状況を予測する機能と、記憶装置から複数のメールアドレスを取り出すと共に、予測された状況に基づいて複数のメールアドレスを順位付けする機能と、順位付けに基づいて、電子メールを順次送信する機能とを実現させるプログラムとして把握することができる。
【００１４】
これらのコンピュータに実行させるプログラムは、このコンピュータが読み取り可能に記憶した記憶媒体に格納される形態がある。この記憶媒体としては、例えばＣＤ−ＲＯＭ媒体等が該当し、コンピュータにおけるＣＤ−ＲＯＭ読取装置によってプログラムが読み取られ、例えば、コンピュータにおけるハードディスク等の各種メモリにこのプログラムが格納され、実行される形態が考えられる。また、これらのプログラムは、例えば、プログラム伝送装置によってネットワークを介してノートＰＣや携帯端末に提供される形態が考えられる。このようなプログラム伝送装置としては、プログラムを格納するメモリと、ネットワークを介してプログラムを提供するプログラム伝送手段とを備えていれば足りる。
【００１５】
また、本発明は、上述したプログラムの発明における各機能をステップで表現した方法の発明として把握することもできる。
【００１６】
【発明の実施の形態】
以下、添付図面を参照して、実施の形態について詳細に説明する。
図１は、実施の一形態に係る電子メール送信システムの概要を説明するブロック図である。この電子メール送信システムは、複数の電子メール送信端末１ａ〜１ｅを有する電子メール送信端末群１、これら電子メール送信端末群１に接続される電子メール送信装置としてのデリバリーサーバ１０、デリバリーサーバ１０に通信ネットワークとしてのインターネット２０を介して接続される第一の電子メール受信端末群３０および第二の電子メール受信端末群４０を有している。ここで、第一の電子メール受信端末群３０は、デリバリーサーバ１０に登録された送信対象者Ａが保有あるいは使用可能な複数の電子メール受信端末であって、本例では、携帯可能なＰＤＡ３１、仕事先に設置されたＰＣ(以下、ＰＣ(Office)と称する)３２、自宅に設置されたＰＣ(以下、ＰＣ(Home)と称する)３３、両親宅に設置されたＰＣ(以下、ＰＣ(Parents)と称する)３４がある。そして、これらＰＤＡ３１、ＰＣ(Office)３２、ＰＣ(Home)３３、ＰＣ(Parents)３４には、それぞれ送信対象者ＡのメールアドレスＡ１、Ａ２、Ａ３、Ａ４が個別に設定されている。一方、第二の電子メール受信端末群４０は、デリバリーサーバ１０に登録された送信対象者Ｂが保有あるいは使用可能な複数の電子メール受信端末であって、本例では、自宅に設置されたＰＣ(Home)４１、携帯可能なＷＡＰ(Wireless Application Protocol Phone：以後の説明ではＷＡＰと称する)４２がある。そして、第二の電子メール受信端末群４０を構成するＰＣ(Home)４１、ＷＡＰ４２には、それぞれ送信対象者ＢのメールアドレスＢ１、Ｂ２が個別に設定されている。
【００１７】
図２は、本実施の形態におけるデリバリーサーバ１０を実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示したものである。
図２に示すコンピュータ装置は、演算手段であるＣＰＵ（Central Processing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２及びＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２及びＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、このビデオカード１０４を介して接続される表示装置１０５と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続されたハードディスク１０６、ネットワークインターフェイス１０７及びＵＳＢポート１０８と、さらにこのＰＣＩバスからブリッジ回路１０９及びＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１１０及びキーボード／マウス１１１とを備える。
尚、図２は本実施の形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、ＡＴＡ（AT Attachment）などのインターフェイスを介してＣＤ−ＲＯＭ（Compact Disc Read Only Memory）やＤＶＤ−ＲＯＭ（Digital Versatile Disc Read Only Memory）のドライブを設けても良い。
【００１８】
また、電子メール送信端末群１、第一の電子メール受信端末群３０および第二の電子メール受信端末群４０についても、図２に示すコンピュータ装置のハードウェア構成を有するものを用いることが可能である。ただし、これら電子メール送信端末群１、第一の電子メール受信端末群３０および第二の電子メール受信端末群４０については、後述するように少なくとも電子メールを送受信できる機能を有していればよく、もっと簡易な構成であってもよい。
【００１９】
図３は、デリバリーサーバ１０の機能を説明するブロック図である。デリバリーサーバ１０は、送信要求受付部１１、状況取得手段あるいは予測手段としてのPersonal Condition取得部１２、記憶手段としてのContext DataBase部１３、送信リスト作成手段としてのTheoretical Delivery Address List作成部１４、優先順位リスト作成手段としてのDelivery Address List作成部１５、送信手段としての送信部１６ａ、受信手段としての受信部１６ｂ、理論値作成手段としてのCount記憶部１７、Score作成記憶部１８および理論値作成記憶部１９を有している。なお、Score作成記憶部１８にはPriority List記憶部１８ａが接続されている。また、Theoretical Delivery Address List作成部１４およびDelivery Address List作成部１５は順位付け手段として機能する。
【００２０】
送信要求受付部１１は、電子メール送信端末群１(図１参照)から電子メールの送信要求を受け付け、送信部１６ａに対して受け付けた電子メールの送信要求を出す。Personal Condition取得部１２は、送信要求受付部１１で送信要求を受け付けた電子メールの送信対象者(本例ではＡまたはＢ)が、現在おかれると想定される状況(Personal Condition)を取得する。具体的には、時計から現在の時刻／日付(Time/Date)、記憶装置(図示せず)に格納される送信対象者のスケジュール表から予定滞在場所(Location)、Ｗｅｂ情報から送信対象者の予定滞在場所の天候(Weather)を取得する。なお、時計については、デリバリーサーバ１０に内蔵されるものであってもよいし、外部に設けられるものであってもよい。また、送信対象者のスケジュールは、予め送信対象者が登録を行う。ここで、取得されるPersonal Conditionは送信対象者の実際の現在の状況ではなく、あくまで事前情報に基づいて予測された状況である。従って、Personal Condition取得部１２は、送信対象者の状況を予測する機能を有していると言える。Context DataBase部１３には、送信対象者によって予め登録されたレコード(送信希望条件と送信希望メール受信端末とを関連付けたデータ)が格納される。これを具体的に説明すると、Context DataBase部１３は、時刻／日付と電子メールの送信を希望する電子メール受信端末(device)とを関連付けて格納するTime/Date-device格納部１３ａと、送信対象者の居場所と電子メールの送信を希望する電子メール受信端末とを関連付けて格納するLocation-device格納部１３ｂと、送信対象者の居場所における天候と電子メールの送信を希望する電子メール受信端末とを関連付けて格納するWeather-device格納部１３ｃとを備えている。なお、Context DataBase部１３には、各電子メール受信端末に対応するメールアドレスもそれぞれ関連付けて記憶される。
【００２１】
Theoretical Delivery Address List作成部１４は、Context DataBase部１３より、Personal Condition取得部１２によって取得された送信対象者のPersonal Conditionと合致する送信希望条件およびこれに対応するレコードを読み出して理論的な送信アドレスリスト(Theoretical Delivery Address List)を作成する。Delivery Address List作成部１５は、Theoretical Delivery Address List作成部１４によって作成されたTheoretical Delivery Address Listを基本に、後述する理論値作成記憶部１９から取得した送信希望条件の理論値を加味して重み付けを行い、送信対象者に届きやすいと想定される電子メール受信端末(メールアドレス)順に順位付けを行った送信アドレスリスト(Delivery Address List)を作成する。
【００２２】
送信部１６ａは、Delivery Address List作成部１５によって作成されたDelivery Address Listに基づいて、リストの上位から順に送信先のメールアドレスを設定し、電子メール送信端末群１(図１参照)から送信要求のあった電子メールをインターネット２０を介して送信する。具体的な電子メールの送信手順については後述する。受信部１６ｂは、送信部１６ａから送信された電子メールを送信対象者が確認することによって送信対象者から返信された確認メール(Confirmation)を受信する。Count記憶部１７は、各送信希望条件において、送信部１６ａから電子メールを送信した回数と受信部１６ｂで確認メールを受信した回数とをそれぞれカウントして記憶する。Score作成記憶部１８は、理論値作成記憶部１９に格納される送信希望条件の理論値とCount記憶部１７に格納されるCount値とに基づいて、期待値(以下、必要に応じてScoreという)を作成して記憶する。理論値作成記憶部１９は、Score作成記憶部１８で作成されたScoreに基づいて送信希望条件の理論値を作成して記憶する。また、Priority List記憶部１８ａは、送信希望条件の優先順位(Priority List)を記憶する。このPriority Listは、予め送信対象者が登録を行う。
【００２３】
ここで、Personal Condition取得部１２、Context DataBase部１３、Theoretical Delivery Address List作成部１４、Delivery Address List作成部１５、Count記憶部１７、Score作成記憶部１８、Priority List記憶部１８ａ、 理論値作成記憶部１９は、図２に示したプログラム制御されたＣＰＵ１０１にて実現されるソフトウェアブロックであり、ＣＰＵ１０１を制御してこれらの機能を実現するプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記憶媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供され、メインメモリ１０３に読み込まれる。また、送信要求受付部１１、送信部１６ａ、受信部１６ｂは、ネットワークインターフェイス１０７によって実現される。尚、メインメモリ１０３に保持されるデータやプログラムは、必要に応じてハードディスク１０６などの記憶装置に待避させることができる。
【００２４】
図４は、ＰＤＡ３１のメール送受信機能を説明するブロック図である。このＰＤＡ３１は、インターネット２０を介して電子メールを受信する受信部３１ａと、この受信部３１ａによって受信した電子メールを閲覧すると共に、電子メールの作成を実行可能なメール読み書き部３１ｂと、メール読み書き部３１ｂで作成した電子メールをインターネット２０を介して送信する送信部３１ｃとを有している。なお、ＰＤＡ３１の他、第一の電子メール受信端末群３０を構成するＰＣ(Office)３２、ＰＣ(Home)３３、ＰＣ(Parents)３４や、第二の電子メール受信端末群４０を構成するＰＣ(Home)４１およびＷＡＰ４２も、同様の構成を有している。また、電子メール送信端末群１を構成する電子メール送信端末１ａ〜１ｅも、同様の構成を有している。
【００２５】
図５は、本実施の形態にかかる電子メール送信システムにおいて、送信対象者によるレコードおよびPriority Listの入力プロセスを説明するフローチャートである。
送信対象者は、まず、Time/Dateに対するメールアドレス(Address)を入力する(ステップ１１)。具体的には、一日を複数の時間帯(例えば朝、昼、晩など)に区切って、各時間帯において電子メールの送信を希望する電子メール受信端末(device)およびそのメールアドレスを入力する。入力された時間に関するレコードは、Context DataBase部１３のTime/Date-device格納部１３ａに格納される。送信対象者は、次に、Locationに対するメールアドレスを入力する(ステップ１２)。具体的には、複数の居場所(自宅、会社、外など)に分け、各居場所において電子メールの送信を希望する電子メール受信端末(device)およびそのメールアドレスを入力する。入力された居場所に関するレコードは、Context DataBase部１３のLocation-device格納部１３ｂに格納される。送信対象者は、さらに、Weatherに対するメールアドレスを入力する(ステップ１３)。具体的には、複数の天候(晴れ、曇り、雨など)に分け、各天候において電子メールの送信を希望する電子メール受信端末(device)およびそのメールアドレスを入力する。入力された天候に関するレコードは、Context DataBase部１３のWeather-device格納部１３ｃに格納される。送信対象者は、最後に、Time/Date、Location、WeatherのPriorityを入力する(ステップ１４)。つまり、これら各送信希望条件(Time/Date、Location、Weather)のうち、どの条件を優先するかを順位付けする。入力された優先順位(Priority List)は、Priority List記憶部１８ａに格納される。これら送信希望条件およびPriority Listは、送信対象者(本例ではＡ、Ｂ)毎にContext DataBase部１３およびPriority List記憶部１８ａにそれぞれ格納される。
【００２６】
図６および図７は、本実施の形態における電子メール送信処理の基本的な流れを示すフローチャートである。次に、図６および図７を参照して、本実施の形態に係る電子メール送信処理について説明する。
本処理は、送信要求受付部１１が電子メール送信端末群１より電子メールの送信要求を受け付けることによって開始される(ステップ１０１)。電子メールの送信要求があった場合は、Personal Condition取得部１２が、受け付けた電子メールの宛先に基づいて送信対象者がＡであるかＢであるかを特定し、特定した送信対象者のPersonal Conditionを取得する(ステップ１０２)。一方、電子メールの送信要求がない場合は、ステップ１０１に戻って電子メールの送信要求を待つ。次に、Theoretical Delivery Address List作成部１４が、Context DataBase部１３に保存されているContext DataBaseより、送信対象者のPersonal Conditionに合致する希望送信条件およびこれに対応するレコードを取得し(ステップ１０３)、これら取得したPersonal ConditionおよびレコードよりTheoretical Delivery Address Listを作成する(ステップ１０４)。
【００２７】
次に、Delivery Address List作成部１５が、理論値作成記憶部１９で作成、記憶された送信希望条件の理論値を取得し(ステップ１０５)、取得された送信希望条件の理論値に基づき、Theoretical Delivery Address List作成部１４から取得した送信希望リストを順位付けし(ステップ１０６)、Delivery Address Listを作成する(ステップ１０７)。そして、ｎ＝１に設定し(ステップ１０８)、送信部１６ａより、作成されたDelivery Address Listのｎ番目(最初は１番目)のメールアドレスを宛先として、送信要求受付部１１で受け付けた電子メールを送信する(ステップ１０９)。そして、所定時間の経過を待って(ステップ１１０)、送信した電子メールに対する返信(確認メール、Confirmation)が受信部１６ｂで受信されたか否かを判断する(ステップ１１１)。ここで、Confirmationが受信されていない場合は、ｎ＝ｎ＋１に設定し(ステップ１１２)、ステップ１０９へと戻る。つまり、作成されたDelivery Address Listの次の順位のメールアドレスを宛先として同じ内容の電子メールを送信することになる。
【００２８】
一方、ステップ１１１においてConfirmationが受信された場合には、メール送信を中止し（ステップ１１３）、Count記憶部１７が、送信希望条件毎の電子メール送信回数とConfirmation受信回数(電子メール送信回数およびConfirmation受信回数をまとめてCount値という)とを更新し(ステップ１１４)、記憶する。そして、Score作成記憶部１８では、理論値作成記憶部１９から取得した現状の送信希望条件の理論値とCount記憶部１７に格納されるCount値とに基づいて、各送信希望条件におけるScoreが計算される(ステップ１１５)。次に、計算した結果、各送信希望条件のScore中に同値のScoreが存在するか否かを判断し(ステップ１１６)、同値のScoreが存在する場合には、Priority List記憶部１８ａに格納されるPriority Listに基づいて同値のScoreの順位を付ける(ステップ１１７)。一方、同値のScoreが存在しない場合は、そのまま次のステップ１１８へと進む。そして、理論値作成記憶部１９において、Score作成記憶部１８より取得したScoreに基づいて各送信希望条件における理論値を修正、記憶する(ステップ１１８)。その後、プロセスを終了するか否かを判断し(ステップ１１９)、続行する場合はステップ１０１へと戻り、続行しない場合は処理を終了する。
【００２９】
次に、具体例を参照しながら、上述した電子メール送信処理をさらに詳細に説明する。なお、ここでは、図１に示す電子メール送信端末１ａから送信対象者Ａに対して電子メールを送信する例について説明を行う。また、送信対象者Ａは、図５に示すフローチャートに基づき、表１(ａ)〜(ｃ)に示す送信希望条件および表１(ｄ)に示すPriority Listを設定しているものとする。
【００３０】
【表１】
【００３１】
【表２】
【００３２】
表２は、ステップ１０１で電子メール送信端末１ａから送信対象者Ａに対する電子メールの送信を受け付けたことにより、ステップ１０２において取得された送信対象者ＡのPersonal Conditionを示している。すなわち、Time(時刻)は17:30、送信対象者Ａが滞在していると想定される場所はTokyo(東京)、天候はFine(晴れ)である。
【００３３】
【表３】
【００３４】
表３は、ステップ１０３において取得されたレコードに基づき、ステップ１０４において作成されたTheoretical Delivery Address Listを示している。この例では、Time/Dateの条件(17:30)に合致する送信希望条件T2(07:00−18:00)、Locationの条件(Tokyo)に合致する送信希望条件L3(Others)、Weatherの条件(Fine)の条件に合致する送信希望条件W1(Fine)が選択される。なお、Locationの「Tokyo」は、「School」でも「Parents Home」でもないため、「Others」が選択されている。
【００３５】
【表４】
【００３６】
表４(ａ)は、初期状態において、理論値作成記憶部１９に格納される理論値を示している。本例では、送信対象者Ａによって登録されたPriority List(表１(ｄ)および表４(ｂ)参照)に基づき、各送信希望条件に対し、Priorityが１番のTimeの関連項目には理論値として３が、２番のLocationの関連項目には理論値として２が、３番のWeatherの関連項目には理論値として１が、それぞれ与えられる。
【００３７】
【表５】
【００３８】
【表６】
【００３９】
表５は、ステップ１０５で取得される理論値を示し、表６は、ステップ１０５で取得した理論値を用いて、ステップ１０６において作成されたDelivery Address Listを示している。本例では、取得された理論値の大きい順、つまり、送信希望条件Ｔ２(ＰＣ(Office)３２、メールアドレスＡ２)を第１位、送信希望条件Ｌ３(ＰＣ(Home)３３、メールアドレスＡ３)を第２位、送信希望条件Ｗ１(ＰＤＡ３１、メールアドレスＡ１)を第３位としたDelivery Address Listが作成される。
【００４０】
【表７】
【００４１】
表７は、初期状態において、Count記憶部１７に格納されるCount値を示している。表７において、Count欄のスラッシュ(/)の右側は対応する送信希望条件における電子メールの送信試行回数を意味し、左側は電子メールを送信した際に確認メール(Confirmation)を受け取った受信回数を意味している。つまり、送信試行回数および受信回数の数値が近いほど、送信対象者Ａに対して電子メールが届きやすいことを意味している。Count値は、この表から明らかなように、初期状態においてはすべて０となっている。
【００４２】
【表８】
【００４３】
表８は、ステップ１１４において更新されるCount値を示している。本例では、上述のようにして作成されたDelivery Address Listに基づき、送信対象者Ａに対して電子メールを送ったところ、Delivery Address Listの１番目にあったＰＣ(Office)３２(メールアドレスＡ２)ではなく、Delivery Address Listの２番目にあったＰＣ(Home)３３(メールアドレスＡ３)よりConfirmationが送られている。つまり、今回のPersonal Condition(表２参照)では、送信対象者Ａの初期登録内容(送信希望条件Ｔ２(ＰＣ(Office)３２)を送信希望条件Ｌ３(ＰＣ(Home)３３)よりも優先する)に対し、実際は、送信希望条件Ｌ３を送信希望条件Ｔ２よりも優先した方が、送信対象者Ａに情報がより早く届きやすかったということになる。このとき、送信希望条件Ｔ２のカウント値は０／１(１回送信中返信(受信)０回)となり、送信希望条件Ｌ３のカウント値は１／１(１回送信中返信(受信)１回)となる。また、本例では、Delivery Address Listの３番目にあったＰＤＡ３１に電子メールを送信する前に、ＰＣ(Home)３３よりConfirmationが返ってきているので、ＰＤＡ３１にはメールの送信を行っていない。このため、送信希望条件Ｗ１のカウント値はそのままである。
【００４４】
【表９】
【００４５】
表９は、初期状態において、Score作成記憶部１８に格納されるScoreを示している。本例では、送信対象者Ａによって登録されたPriority List(表１(ｄ)参照)に基づき、各送信希望条件に対し、Priorityが１番のTimeの関連項目にはScoreとして−１が、２番のLocationの関連項目にはScoreとして−２が、３番のWeatherの関連項目にはScoreとして−３が、それぞれ与えられるようになっている。
【００４６】
【表１０】
【００４７】
表１０は、ステップ１１５で計算されるScoreを示している。本例では、各送信希望条件の理論値と更新されたCount値とをかけ算することで、新たなScoreを作成している。本例では、確認メールの返信がなかった送信希望条件Ｔ２のScoreが０に、確認メールの返信があった送信希望条件Ｌ３のScoreが２となる。なお、送信を行っていない送信希望条件Ｗ１については、何もせずにそのままの値を残している。
【００４８】
【表１１】
【００４９】
【表１２】
【００５０】
表１１は、ステップ１１８で修正された理論値を示し、表１２は、修正によって理論値作成記憶部１９に更新格納された理論値を示している。本例では、Scoreが増加した送信希望条件の理論値を最高点の３に変更し、Scoreが減少した送信希望条件の理論値を１だけ減少させることで、理論値の修正を行っている。従って、送信を行ったものの返信のなかった送信希望条件Ｔ２は理論値が３から２となり、送信を行って返信のあった送信希望条件Ｌ３は理論値が２から３となり、何も行わなかった送信希望条件Ｗ１は理論値が１のままとなっている。
【００５１】
【表１３】
【００５２】
表１３は、ステップ１０１で電子メール送信端末１ａから送信対象者Ａに対する電子メールの送信を受け付けたことにより、ステップ１０２において取得された送信対象者ＡのPersonal Conditionを示している。すなわち、Time(時刻)は16:30、送信対象者Ａが滞在していると想定される場所はTokyo(東京)、天候はOthers(その他)である。
【００５３】
【表１４】
【００５４】
表１４は、ステップ１０５で取得される理論値を示している。今回の場合は、前とは異なり、送信希望条件Ｔ２よりも送信希望条件Ｌ３の方の理論値が大きくなっていることがわかる。つまり、ステップ１０７でDelivery Address Listを作成する際に、送信希望条件Ｌ３を第１位、送信希望条件Ｔ２を第２位としたDelivery Address Listが作成されることになる。
【００５５】
このようなプロセスを繰り返し行うことで、送信対象者Ａに対して的確に情報が届けられる可能性、つまり、送信対象者Ａが電子メールを受け取り得る電子メール受信端末に対して優先的に電子メールを送信できる確率を上げていくことができる。このため、本実施の形態では、送信対象者Ａが最初に登録したTheoretical Delivery Address Listに多少誤りがあったとしても、実際の使用状況に基づいてDelivery Address Listの最適化を図ることができる。また、送信対象者Ａのプライバシー保護の観点から、Context DataBase部１３に登録するレコードや、Personal Conditionとして提供される情報が少ないような場合にも、送信対象者Ａの行動パターンを把握することができ、最適で有効な情報の伝達を行うことができる。さらに、本実施の形態では、Delivery Address Listの上位のメールアドレスから順に電子メールを送信しているが、送信対象者からConfirmationがあったときはそれ以降の電子メールの送信を中止しているので、トラフィック量の無用な増加を抑制することができる。
【００５６】
なお、本実施の形態では、電子メール送信端末１ａから送信対象者Ａに対する電子メール送信処理について説明を行ったが、送信対象者Ｂに対しても同様の手法を用いることでDelivery Address Listを最適化し、的確に情報を届ける可能性を高めることができる。同様に、他の電子メール送信端末１ｂ〜１ｅより送信対象者ＡやＢに対して電子メールを送信する際にも同様に適用できる。この場合、電子メール送信端末１ｂ〜１ｅは、電子メール送信端末１ａから電子メールを送信した際に得られた理論値を共用して利用することができ、送信対象者に対する情報の伝達をより的確に行うことができる。
【００５７】
また、本実施の形態では、送信対象者が最初に設定する項目として、Time/Date、Location、Weatherを挙げていたが、これに限られるものではなく、項目数については増減可能である。その他に考えられる項目としては、例えば送信対象者が仕事中(Business)か仕事外(Private)かや、送信対象者がおかれる環境(Environment)等が挙げられる。なお、送信対象者がおかれる環境としては、例えば、交通情報から、送信対象者が勤務する会社への通勤経路が渋滞だった場合は自宅勤務にする、株価情報から、送信対象者が担当している株券の値がある値以上になったら証券会社へ行く、等が挙げられる。
【００５８】
さらに、本実施の形態では、デリバリーサーバ１０から電子メールの送信を行うようにしていたが、これに限られるものではなく、電子メールの要求を受け付けた場合に、Delivery Address Listを作成して電子メール送信端末１ａ〜１ｅのいずれか(電子メールを送信しようとする端末)にこのDelivery Address Listを返信するようにしてもよい。つまり、電子メール送信端末群１に対して送信対象者の連絡先を案内するものであってもよい。この場合は、連絡先として、電子メールアドレス以外に電話番号(固定電話、携帯電話)、ファクシミリ番号などを案内するようにしてもよい。また、連絡先については、例えば送信対象者の隣人の電子メールアドレス、電話番号、ファクシミリ番号等もあり得る。
【００５９】
次に、上述したプロセスの効果を確かめるべく、シュミレーションを行った結果について説明する。
シュミレーションを行うにあたり、以下のような前提条件をおいた。
１)送信対象者は電子メール受信端末(Device)を５つ(デバイス０、１、２、３、４)持っている。
２)送信対象者は、０→１→２→３→４の順でPriority Listを作成している。
３)使用時に各デバイスから返されるConfirmationの確率を以下のように設定する。
デバイス２：１/２
デバイス０：１/４
デバイス３：１/１６
デバイス１：１/２５６
デバイス４：１/６５５３６
【００６０】
従って、上述した前提条件３)から、送信対象者が設定したPriority List
・０→１→２→３→４
が、
・２→０→３→１→４
となることが期待される。
【００６１】
このシュミレーションでは、各デバイス０〜４に返信されるConfirmationが上述した確率で生成されるような０から４までの乱数を５００個生成させた。生成させた乱数の一部を表１５に示す。
【００６２】
【表１５】
【００６３】
表１５は、１回目のＣｏｎｆｉｒｍａｔｉｏｎはデバイス２から、２回目もデバイス２から、３回目はデバイス０から返信された、という状態を表している。その結果、Ｃｏｎｆｉｒｍａｔｉｏｎが返信されたデバイスの番号の合計は次の通りとなった。
デバイス２：３１１個
デバイス０：１５２個
デバイス３：３５個
デバイス１：２個
デバイス４：０個
【００６４】
表１６は、上述したシュミレーションを行った結果の一覧を示している。なお、表１６において、「No」はConfirmationが返信されたデバイスの番号を意味している。
【００６５】
【表１６】
【００６６】
表１６は、次のことを示している。
１回目、電子メールを送信する順番は、送信対象者が設定した初期値０→１→２→３→４となっている。しかしながら、実際に電子メールを送った結果では、デバイス０、１からは返信(Confirmation)がなく、デバイス２から返信があった。このことから、デバイス０、１のCount値は０/１となり、Scoreは０.０となる。一方、デバイス２では、Count値が１/１となり、Scoreは２.０となる。なお、デバイス３、４には電子メールの送信を行っていないので、Count値は０/０のままであり、Scoreは０.０である。
２回目、電子メールを送信する順番は、１回目の結果から２→０→１→３→４となっている。実際に電子メールを送信した結果では、デバイス２から返信があった。このことからデバイス２は、Count値が２/２となり、Scoreは４.０となる。なお、デバイス０、１には電子メールの送信を行っていないので、Count値は０/１と変わらず、Scoreも０.０のままである。また、デバイス３、４にも電子メールの送信を行っていないので、これらのCount値およびScoreに変化はない。
３回目、電子メールを送信する順番は、２回目の結果から２→０→１→３→４となっている。実際に電子メールを送った結果では、デバイス０から返信があった。このことからデバイス０は、Count値が１/２となり、Scoreは２.０となる。一方、デバイス２はCount値が２/３となり、Scoreは２.６６７へと低下する。また、デバイス１、３、４には電子メールの送信を行っていないので、これらのCount値およびScoreに変化はない。
【００６７】
図８は、このようにしてシュミレーションを行って得られた電子メール送信試行回数(回数)と得られたScoreとの関係を示すグラフ図である。同図より、電子メールの送信回数が多くなっていくにつれ、送信対象者が設定したPriority Listである０→１→２→３→４から、実際の状況２→０→３→１→４に収束していくことが理解される。
【００６８】
【発明の効果】
以上説明したように、本発明によれば、複数のメールアドレスや連絡先を有する対象者に対して、的確に情報を伝達することができる。
【図面の簡単な説明】
【図１】 実施の一形態に係る電子メール送信システムの概要を説明するブロック図である。
【図２】 デリバリーサーバを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示す図である。
【図３】 デリバリーサーバの機能を説明するブロック図である。
【図４】 ＰＤＡのメール送受信機能を説明するブロック図である。
【図５】 送信対象者によるレコードおよびPriority Listの入力プロセスを説明するフローチャートである。
【図６】 電子メール送信処理の基本的な流れを示すフローチャートである。
【図７】 電子メール送信処理の基本的な流れを示すフローチャート(つづき)である。
【図８】 シュミレーションを行って得られた電子メール送信試行回数(回数)と得られたScoreとの関係を示すグラフ図である。
【符号の説明】
１…電子メール送信端末群、１ａ〜１ｅ…電子メール送信端末、１０…デリバリーサーバ、１１…送信要求受付部、１２…Personal Condition取得部、１３…Context DataBase部、１４…Theoretical Delivery Address List作成部、１５…Delivery Address List作成部、１６ａ…送信部、１６ｂ…受信部、１７…Count記憶部、１８…Score作成記憶部、１９…理論値作成記憶部、２０…インターネット、３０…第一の電子メール受信端末群、３１…ＰＤＡ、３２…ＰＣ(Office)、３３…ＰＣ(Home)、３４…ＰＣ(Parents)、４０…第二の電子メール受信端末群、４１…ＰＣ(Home)、４２…ＷＡＰ
【発明の属する技術分野】
本発明は、対象者に対して電子メール等を用いて情報を伝達するための手法に係り、特に、複数の連絡先(例えばメールアドレス)を所有する対象者に対してより的確に情報を伝達するための手法に関する。
【０００２】
【従来の技術】
近年、個人が所有する情報受信手段は多岐にわたっている。この種の情報受信手段として電子メールを例にとると、会社のＰＣ(Personal Computer)で使用するメールアドレス、自宅のＰＣで使用するメールアドレス、携帯電話やＰＤＡで使用するメールアドレス等がある。そして、個人が所有する情報受信端末の数が増えるほど、使用可能なメールアドレスも増大していく傾向にある。
【０００３】
このような状況の中で、情報発信者(連絡者)は、情報受信者(送信対象者)に対して適切に情報を送信することが要求される。例えば連絡者が送信対象者の自宅のＰＣに設定されたメールアドレスを宛先として電子メールを送信したとしても、そのときに送信対象者が自宅にいなければ、送信対象者が送信された電子メールを直ちに受け取ることはできない。また、情報発信者が送信対象者の所有しているすべてのメールアドレスを宛先として情報を送信した場合には、確かに、送信対象者が送信された電子メールを直ちに受け取ることは可能かもしれないが、情報のトラフィック量が増大してしまうという問題がある。
このような複数のメールアドレスを所有する送信対象者に対して電子メールを送信する技術としては、従来、特許文献１に記載される技術が提案されている。なお、特許文献１には、送信先のメールアドレスが所定期間使用されていないときに、このメールアドレスを削除する点が開示されている。
【０００４】
【特許文献１】
特開２００２−２６９６１号公報(第１１頁、図９)
【０００５】
【発明が解決しようとする課題】
しかしながら、所定期間使用されていないメールアドレスを削除したとしても、情報のトラフィック量の増大を根本的に解決することは困難である。
また、特許文献１には、連絡者の現在位置情報と送信対象者の現在位置情報とに基づいて対象者のメールアドレスを選択する技術が記載されているが、送信対象者の現在位置に誤りがあった場合には、送信対象者に情報を伝達できなくなるという問題がある。
【０００６】
本発明は、以上の技術的課題を解決するためになされたものであって、その目的とするところは、複数のメールアドレスや連絡先を有する対象者に対して、的確に情報を伝達することにある。
本発明の他の目的は、情報のトラフィック量の増大を抑えつつ、対象者に対して的確に情報を伝達することにある。
本発明のさらに他の目的は、対象者から得られる現在位置情報等の送信対象者の現在の状況を示す情報が少ない場合にも、対象者に対して的確に情報を伝達することにある。
【０００７】
【課題を解決するための手段】
かかる目的のもと、本発明は、複数のメールアドレスを所有する送信対象者に対して、この送信対象者が電子メールを受け取れる可能性が高い順に電子メールを送信することを提案する。また、電子メールの送信結果、すなわち、どの電子メールアドレスで送信対象者が電子メールを受け取ったかという結果を、次に電子メールを送信する際の送信順序に反映させることを提案する。
すなわち、本発明の電子メール送信装置は、複数のメールアドレスを所有する送信対象者に対して電子メールを送信する電子メール送信装置であって、送信対象者の状況とメールアドレスとが対応付けされて格納される記憶手段と、送信対象者に対して電子メールを送信する際に送信対象者がおかれている状況を予測する予測手段と、予測された状況に基づいて、記憶手段から所定数のメールアドレスを取り出すと共に、取り出した所定数のメールアドレスを順位付けする順位付け手段と、順位付けがなされた所定数のメールアドレスを用いて、電子メールを順次送信する送信手段とを含んでいる。
【０００８】
ここで、予測手段は、送信対象者のスケジュールを取得し、取得したスケジュールに基づいて状況を予測することを特徴とすることができる。また、送信手段によって送信された電子メールに対して、所定のメールアドレスから返信された受け取り確認を受信する受信手段をさらに含み、送信手段は、受け取り確認を受信した場合に電子メールの送信を中止することを特徴とすることができる。さらに、送信手段によって送信された電子メールに対して、所定のメールアドレスから返信された受け取り確認を受信する受信手段をさらに含み、順位付け手段は、次の順位付けにおいて所定のメールアドレスの順位を変更することを特徴とすることができる。さらにまた、順位付け手段は、予測手段によって予測された状況に合致するメールアドレスを記憶手段から取り出すことを特徴とすることができる。
【０００９】
また、他の観点から捉えると、本発明の電子メール送信装置は、複数のメールアドレスを所有する送信対象者に対して電子メールを送信する電子メール送信装置であって、送信対象者の送信希望条件と送信対象者が送信を希望するメールアドレスとを関連付けたレコードを記憶する記憶手段と、送信対象者に対して電子メールを送信する際に送信対象者がおかれると想定される状況を取得する状況取得手段と、状況取得手段によって取得された状況に適合するレコードを記憶手段より取得して送信希望リストを作成する送信リスト作成手段と、送信対象者に対する電子メールの届きやすさに関する理論値を作成する理論値作成手段と、理論値作成手段によって作成された理論値に基づいて、送信リスト作成手段で作成された送信リスト中のメールアドレスを順位付けして送信優先順位リストを作成する送信優先順位リスト作成手段と、送信優先順位リスト作成手段によって作成された送信優先順位リストに基づいて、優先順位の高いメールアドレスから順に電子メールを送信する送信手段とを含んでいる。
【００１０】
この電子メール送信装置では、送信手段によって送信された電子メールの受け取り確認を受信する受信手段をさらに含み、理論値作成手段は、受信手段によって受信された受け取り確認に基づいて理論値を修正することを特徴とすることができる。また、送信希望条件と、送信手段による電子メールの送信試行回数および受信手段による受け取り確認回数とを関連付けて格納するカウント格納手段と、カウント格納手段に格納されたカウント値に基づいて、各送信希望条件に対応する期待値を作成する期待値作成手段とをさらに備え、理論値作成手段は、期待値作成手段で作成された期待値に基づいて理論値を修正することができる。さらに、予め送信対象者によって設定された送信希望条件の優先順位のリストを格納する初期優先順位格納手段をさらに含み、理論値作成手段は、初期優先順位格納手段より取得した初期優先順位リストに基づいて最初の理論値を決定することを特徴とすることができる。
【００１１】
また、本発明は、上述した電子メール送信装置の他、連絡先案内装置としても捉えることができる。
すなわち、本発明の連絡先案内装置は、複数の連絡先を有する対象者に対して連絡を行う際に、連絡者に連絡先を案内する連絡先案内装置であって、対象者の状況と連絡先との対応関係を取得する取得手段と、対象者に対して連絡を行う際に対象者がおかれる状況を予測する予測手段と、予測された状況に基づいて、取得手段により所定数の連絡先を取得すると共に、取得した所定数の連絡先を順位付けする順位付け手段とを含んでいる。
【００１２】
この連絡先案内装置において、取得手段によって取得される連絡先は、電子メールアドレス、電話番号、ファクシミリ番号の少なくともいずれか一つを含むことを特徴とすることができる。また、順位付け手段は、順位付けに基づいて連絡を行った結果を次の順位付けに反映させることを特徴とすることができる。
【００１３】
また、本発明はコンピュータに、所定の送信対象者に対する複数のメールアドレスが格納された記憶装置から、特定のメールアドレスに対して電子メールを送信させるプログラムであって、送信対象者に対して電子メールを送信する際に送信対象者がおかれた状況を予測する機能と、記憶装置から複数のメールアドレスを取り出すと共に、予測された状況に基づいて複数のメールアドレスを順位付けする機能と、順位付けに基づいて、電子メールを順次送信する機能とを実現させるプログラムとして把握することができる。
【００１４】
これらのコンピュータに実行させるプログラムは、このコンピュータが読み取り可能に記憶した記憶媒体に格納される形態がある。この記憶媒体としては、例えばＣＤ−ＲＯＭ媒体等が該当し、コンピュータにおけるＣＤ−ＲＯＭ読取装置によってプログラムが読み取られ、例えば、コンピュータにおけるハードディスク等の各種メモリにこのプログラムが格納され、実行される形態が考えられる。また、これらのプログラムは、例えば、プログラム伝送装置によってネットワークを介してノートＰＣや携帯端末に提供される形態が考えられる。このようなプログラム伝送装置としては、プログラムを格納するメモリと、ネットワークを介してプログラムを提供するプログラム伝送手段とを備えていれば足りる。
【００１５】
また、本発明は、上述したプログラムの発明における各機能をステップで表現した方法の発明として把握することもできる。
【００１６】
【発明の実施の形態】
以下、添付図面を参照して、実施の形態について詳細に説明する。
図１は、実施の一形態に係る電子メール送信システムの概要を説明するブロック図である。この電子メール送信システムは、複数の電子メール送信端末１ａ〜１ｅを有する電子メール送信端末群１、これら電子メール送信端末群１に接続される電子メール送信装置としてのデリバリーサーバ１０、デリバリーサーバ１０に通信ネットワークとしてのインターネット２０を介して接続される第一の電子メール受信端末群３０および第二の電子メール受信端末群４０を有している。ここで、第一の電子メール受信端末群３０は、デリバリーサーバ１０に登録された送信対象者Ａが保有あるいは使用可能な複数の電子メール受信端末であって、本例では、携帯可能なＰＤＡ３１、仕事先に設置されたＰＣ(以下、ＰＣ(Office)と称する)３２、自宅に設置されたＰＣ(以下、ＰＣ(Home)と称する)３３、両親宅に設置されたＰＣ(以下、ＰＣ(Parents)と称する)３４がある。そして、これらＰＤＡ３１、ＰＣ(Office)３２、ＰＣ(Home)３３、ＰＣ(Parents)３４には、それぞれ送信対象者ＡのメールアドレスＡ１、Ａ２、Ａ３、Ａ４が個別に設定されている。一方、第二の電子メール受信端末群４０は、デリバリーサーバ１０に登録された送信対象者Ｂが保有あるいは使用可能な複数の電子メール受信端末であって、本例では、自宅に設置されたＰＣ(Home)４１、携帯可能なＷＡＰ(Wireless Application Protocol Phone：以後の説明ではＷＡＰと称する)４２がある。そして、第二の電子メール受信端末群４０を構成するＰＣ(Home)４１、ＷＡＰ４２には、それぞれ送信対象者ＢのメールアドレスＢ１、Ｂ２が個別に設定されている。
【００１７】
図２は、本実施の形態におけるデリバリーサーバ１０を実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示したものである。
図２に示すコンピュータ装置は、演算手段であるＣＰＵ（Central Processing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２及びＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２及びＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、このビデオカード１０４を介して接続される表示装置１０５と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続されたハードディスク１０６、ネットワークインターフェイス１０７及びＵＳＢポート１０８と、さらにこのＰＣＩバスからブリッジ回路１０９及びＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１１０及びキーボード／マウス１１１とを備える。
尚、図２は本実施の形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、ＡＴＡ（AT Attachment）などのインターフェイスを介してＣＤ−ＲＯＭ（Compact Disc Read Only Memory）やＤＶＤ−ＲＯＭ（Digital Versatile Disc Read Only Memory）のドライブを設けても良い。
【００１８】
また、電子メール送信端末群１、第一の電子メール受信端末群３０および第二の電子メール受信端末群４０についても、図２に示すコンピュータ装置のハードウェア構成を有するものを用いることが可能である。ただし、これら電子メール送信端末群１、第一の電子メール受信端末群３０および第二の電子メール受信端末群４０については、後述するように少なくとも電子メールを送受信できる機能を有していればよく、もっと簡易な構成であってもよい。
【００１９】
図３は、デリバリーサーバ１０の機能を説明するブロック図である。デリバリーサーバ１０は、送信要求受付部１１、状況取得手段あるいは予測手段としてのPersonal Condition取得部１２、記憶手段としてのContext DataBase部１３、送信リスト作成手段としてのTheoretical Delivery Address List作成部１４、優先順位リスト作成手段としてのDelivery Address List作成部１５、送信手段としての送信部１６ａ、受信手段としての受信部１６ｂ、理論値作成手段としてのCount記憶部１７、Score作成記憶部１８および理論値作成記憶部１９を有している。なお、Score作成記憶部１８にはPriority List記憶部１８ａが接続されている。また、Theoretical Delivery Address List作成部１４およびDelivery Address List作成部１５は順位付け手段として機能する。
【００２０】
送信要求受付部１１は、電子メール送信端末群１(図１参照)から電子メールの送信要求を受け付け、送信部１６ａに対して受け付けた電子メールの送信要求を出す。Personal Condition取得部１２は、送信要求受付部１１で送信要求を受け付けた電子メールの送信対象者(本例ではＡまたはＢ)が、現在おかれると想定される状況(Personal Condition)を取得する。具体的には、時計から現在の時刻／日付(Time/Date)、記憶装置(図示せず)に格納される送信対象者のスケジュール表から予定滞在場所(Location)、Ｗｅｂ情報から送信対象者の予定滞在場所の天候(Weather)を取得する。なお、時計については、デリバリーサーバ１０に内蔵されるものであってもよいし、外部に設けられるものであってもよい。また、送信対象者のスケジュールは、予め送信対象者が登録を行う。ここで、取得されるPersonal Conditionは送信対象者の実際の現在の状況ではなく、あくまで事前情報に基づいて予測された状況である。従って、Personal Condition取得部１２は、送信対象者の状況を予測する機能を有していると言える。Context DataBase部１３には、送信対象者によって予め登録されたレコード(送信希望条件と送信希望メール受信端末とを関連付けたデータ)が格納される。これを具体的に説明すると、Context DataBase部１３は、時刻／日付と電子メールの送信を希望する電子メール受信端末(device)とを関連付けて格納するTime/Date-device格納部１３ａと、送信対象者の居場所と電子メールの送信を希望する電子メール受信端末とを関連付けて格納するLocation-device格納部１３ｂと、送信対象者の居場所における天候と電子メールの送信を希望する電子メール受信端末とを関連付けて格納するWeather-device格納部１３ｃとを備えている。なお、Context DataBase部１３には、各電子メール受信端末に対応するメールアドレスもそれぞれ関連付けて記憶される。
【００２１】
Theoretical Delivery Address List作成部１４は、Context DataBase部１３より、Personal Condition取得部１２によって取得された送信対象者のPersonal Conditionと合致する送信希望条件およびこれに対応するレコードを読み出して理論的な送信アドレスリスト(Theoretical Delivery Address List)を作成する。Delivery Address List作成部１５は、Theoretical Delivery Address List作成部１４によって作成されたTheoretical Delivery Address Listを基本に、後述する理論値作成記憶部１９から取得した送信希望条件の理論値を加味して重み付けを行い、送信対象者に届きやすいと想定される電子メール受信端末(メールアドレス)順に順位付けを行った送信アドレスリスト(Delivery Address List)を作成する。
【００２２】
送信部１６ａは、Delivery Address List作成部１５によって作成されたDelivery Address Listに基づいて、リストの上位から順に送信先のメールアドレスを設定し、電子メール送信端末群１(図１参照)から送信要求のあった電子メールをインターネット２０を介して送信する。具体的な電子メールの送信手順については後述する。受信部１６ｂは、送信部１６ａから送信された電子メールを送信対象者が確認することによって送信対象者から返信された確認メール(Confirmation)を受信する。Count記憶部１７は、各送信希望条件において、送信部１６ａから電子メールを送信した回数と受信部１６ｂで確認メールを受信した回数とをそれぞれカウントして記憶する。Score作成記憶部１８は、理論値作成記憶部１９に格納される送信希望条件の理論値とCount記憶部１７に格納されるCount値とに基づいて、期待値(以下、必要に応じてScoreという)を作成して記憶する。理論値作成記憶部１９は、Score作成記憶部１８で作成されたScoreに基づいて送信希望条件の理論値を作成して記憶する。また、Priority List記憶部１８ａは、送信希望条件の優先順位(Priority List)を記憶する。このPriority Listは、予め送信対象者が登録を行う。
【００２３】
ここで、Personal Condition取得部１２、Context DataBase部１３、Theoretical Delivery Address List作成部１４、Delivery Address List作成部１５、Count記憶部１７、Score作成記憶部１８、Priority List記憶部１８ａ、 理論値作成記憶部１９は、図２に示したプログラム制御されたＣＰＵ１０１にて実現されるソフトウェアブロックであり、ＣＰＵ１０１を制御してこれらの機能を実現するプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記憶媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供され、メインメモリ１０３に読み込まれる。また、送信要求受付部１１、送信部１６ａ、受信部１６ｂは、ネットワークインターフェイス１０７によって実現される。尚、メインメモリ１０３に保持されるデータやプログラムは、必要に応じてハードディスク１０６などの記憶装置に待避させることができる。
【００２４】
図４は、ＰＤＡ３１のメール送受信機能を説明するブロック図である。このＰＤＡ３１は、インターネット２０を介して電子メールを受信する受信部３１ａと、この受信部３１ａによって受信した電子メールを閲覧すると共に、電子メールの作成を実行可能なメール読み書き部３１ｂと、メール読み書き部３１ｂで作成した電子メールをインターネット２０を介して送信する送信部３１ｃとを有している。なお、ＰＤＡ３１の他、第一の電子メール受信端末群３０を構成するＰＣ(Office)３２、ＰＣ(Home)３３、ＰＣ(Parents)３４や、第二の電子メール受信端末群４０を構成するＰＣ(Home)４１およびＷＡＰ４２も、同様の構成を有している。また、電子メール送信端末群１を構成する電子メール送信端末１ａ〜１ｅも、同様の構成を有している。
【００２５】
図５は、本実施の形態にかかる電子メール送信システムにおいて、送信対象者によるレコードおよびPriority Listの入力プロセスを説明するフローチャートである。
送信対象者は、まず、Time/Dateに対するメールアドレス(Address)を入力する(ステップ１１)。具体的には、一日を複数の時間帯(例えば朝、昼、晩など)に区切って、各時間帯において電子メールの送信を希望する電子メール受信端末(device)およびそのメールアドレスを入力する。入力された時間に関するレコードは、Context DataBase部１３のTime/Date-device格納部１３ａに格納される。送信対象者は、次に、Locationに対するメールアドレスを入力する(ステップ１２)。具体的には、複数の居場所(自宅、会社、外など)に分け、各居場所において電子メールの送信を希望する電子メール受信端末(device)およびそのメールアドレスを入力する。入力された居場所に関するレコードは、Context DataBase部１３のLocation-device格納部１３ｂに格納される。送信対象者は、さらに、Weatherに対するメールアドレスを入力する(ステップ１３)。具体的には、複数の天候(晴れ、曇り、雨など)に分け、各天候において電子メールの送信を希望する電子メール受信端末(device)およびそのメールアドレスを入力する。入力された天候に関するレコードは、Context DataBase部１３のWeather-device格納部１３ｃに格納される。送信対象者は、最後に、Time/Date、Location、WeatherのPriorityを入力する(ステップ１４)。つまり、これら各送信希望条件(Time/Date、Location、Weather)のうち、どの条件を優先するかを順位付けする。入力された優先順位(Priority List)は、Priority List記憶部１８ａに格納される。これら送信希望条件およびPriority Listは、送信対象者(本例ではＡ、Ｂ)毎にContext DataBase部１３およびPriority List記憶部１８ａにそれぞれ格納される。
【００２６】
図６および図７は、本実施の形態における電子メール送信処理の基本的な流れを示すフローチャートである。次に、図６および図７を参照して、本実施の形態に係る電子メール送信処理について説明する。
本処理は、送信要求受付部１１が電子メール送信端末群１より電子メールの送信要求を受け付けることによって開始される(ステップ１０１)。電子メールの送信要求があった場合は、Personal Condition取得部１２が、受け付けた電子メールの宛先に基づいて送信対象者がＡであるかＢであるかを特定し、特定した送信対象者のPersonal Conditionを取得する(ステップ１０２)。一方、電子メールの送信要求がない場合は、ステップ１０１に戻って電子メールの送信要求を待つ。次に、Theoretical Delivery Address List作成部１４が、Context DataBase部１３に保存されているContext DataBaseより、送信対象者のPersonal Conditionに合致する希望送信条件およびこれに対応するレコードを取得し(ステップ１０３)、これら取得したPersonal ConditionおよびレコードよりTheoretical Delivery Address Listを作成する(ステップ１０４)。
【００２７】
次に、Delivery Address List作成部１５が、理論値作成記憶部１９で作成、記憶された送信希望条件の理論値を取得し(ステップ１０５)、取得された送信希望条件の理論値に基づき、Theoretical Delivery Address List作成部１４から取得した送信希望リストを順位付けし(ステップ１０６)、Delivery Address Listを作成する(ステップ１０７)。そして、ｎ＝１に設定し(ステップ１０８)、送信部１６ａより、作成されたDelivery Address Listのｎ番目(最初は１番目)のメールアドレスを宛先として、送信要求受付部１１で受け付けた電子メールを送信する(ステップ１０９)。そして、所定時間の経過を待って(ステップ１１０)、送信した電子メールに対する返信(確認メール、Confirmation)が受信部１６ｂで受信されたか否かを判断する(ステップ１１１)。ここで、Confirmationが受信されていない場合は、ｎ＝ｎ＋１に設定し(ステップ１１２)、ステップ１０９へと戻る。つまり、作成されたDelivery Address Listの次の順位のメールアドレスを宛先として同じ内容の電子メールを送信することになる。
【００２８】
一方、ステップ１１１においてConfirmationが受信された場合には、メール送信を中止し（ステップ１１３）、Count記憶部１７が、送信希望条件毎の電子メール送信回数とConfirmation受信回数(電子メール送信回数およびConfirmation受信回数をまとめてCount値という)とを更新し(ステップ１１４)、記憶する。そして、Score作成記憶部１８では、理論値作成記憶部１９から取得した現状の送信希望条件の理論値とCount記憶部１７に格納されるCount値とに基づいて、各送信希望条件におけるScoreが計算される(ステップ１１５)。次に、計算した結果、各送信希望条件のScore中に同値のScoreが存在するか否かを判断し(ステップ１１６)、同値のScoreが存在する場合には、Priority List記憶部１８ａに格納されるPriority Listに基づいて同値のScoreの順位を付ける(ステップ１１７)。一方、同値のScoreが存在しない場合は、そのまま次のステップ１１８へと進む。そして、理論値作成記憶部１９において、Score作成記憶部１８より取得したScoreに基づいて各送信希望条件における理論値を修正、記憶する(ステップ１１８)。その後、プロセスを終了するか否かを判断し(ステップ１１９)、続行する場合はステップ１０１へと戻り、続行しない場合は処理を終了する。
【００２９】
次に、具体例を参照しながら、上述した電子メール送信処理をさらに詳細に説明する。なお、ここでは、図１に示す電子メール送信端末１ａから送信対象者Ａに対して電子メールを送信する例について説明を行う。また、送信対象者Ａは、図５に示すフローチャートに基づき、表１(ａ)〜(ｃ)に示す送信希望条件および表１(ｄ)に示すPriority Listを設定しているものとする。
【００３０】
【表１】
【表２】
表２は、ステップ１０１で電子メール送信端末１ａから送信対象者Ａに対する電子メールの送信を受け付けたことにより、ステップ１０２において取得された送信対象者ＡのPersonal Conditionを示している。すなわち、Time(時刻)は17:30、送信対象者Ａが滞在していると想定される場所はTokyo(東京)、天候はFine(晴れ)である。
【００３３】
【表３】
表３は、ステップ１０３において取得されたレコードに基づき、ステップ１０４において作成されたTheoretical Delivery Address Listを示している。この例では、Time/Dateの条件(17:30)に合致する送信希望条件T2(07:00−18:00)、Locationの条件(Tokyo)に合致する送信希望条件L3(Others)、Weatherの条件(Fine)の条件に合致する送信希望条件W1(Fine)が選択される。なお、Locationの「Tokyo」は、「School」でも「Parents Home」でもないため、「Others」が選択されている。
【００３５】
【表４】
表４(ａ)は、初期状態において、理論値作成記憶部１９に格納される理論値を示している。本例では、送信対象者Ａによって登録されたPriority List(表１(ｄ)および表４(ｂ)参照)に基づき、各送信希望条件に対し、Priorityが１番のTimeの関連項目には理論値として３が、２番のLocationの関連項目には理論値として２が、３番のWeatherの関連項目には理論値として１が、それぞれ与えられる。
【００３７】
【表５】
【表６】
表５は、ステップ１０５で取得される理論値を示し、表６は、ステップ１０５で取得した理論値を用いて、ステップ１０６において作成されたDelivery Address Listを示している。本例では、取得された理論値の大きい順、つまり、送信希望条件Ｔ２(ＰＣ(Office)３２、メールアドレスＡ２)を第１位、送信希望条件Ｌ３(ＰＣ(Home)３３、メールアドレスＡ３)を第２位、送信希望条件Ｗ１(ＰＤＡ３１、メールアドレスＡ１)を第３位としたDelivery Address Listが作成される。
【００４０】
【表７】
表７は、初期状態において、Count記憶部１７に格納されるCount値を示している。表７において、Count欄のスラッシュ(/)の右側は対応する送信希望条件における電子メールの送信試行回数を意味し、左側は電子メールを送信した際に確認メール(Confirmation)を受け取った受信回数を意味している。つまり、送信試行回数および受信回数の数値が近いほど、送信対象者Ａに対して電子メールが届きやすいことを意味している。Count値は、この表から明らかなように、初期状態においてはすべて０となっている。
【００４２】
【表８】
表８は、ステップ１１４において更新されるCount値を示している。本例では、上述のようにして作成されたDelivery Address Listに基づき、送信対象者Ａに対して電子メールを送ったところ、Delivery Address Listの１番目にあったＰＣ(Office)３２(メールアドレスＡ２)ではなく、Delivery Address Listの２番目にあったＰＣ(Home)３３(メールアドレスＡ３)よりConfirmationが送られている。つまり、今回のPersonal Condition(表２参照)では、送信対象者Ａの初期登録内容(送信希望条件Ｔ２(ＰＣ(Office)３２)を送信希望条件Ｌ３(ＰＣ(Home)３３)よりも優先する)に対し、実際は、送信希望条件Ｌ３を送信希望条件Ｔ２よりも優先した方が、送信対象者Ａに情報がより早く届きやすかったということになる。このとき、送信希望条件Ｔ２のカウント値は０／１(１回送信中返信(受信)０回)となり、送信希望条件Ｌ３のカウント値は１／１(１回送信中返信(受信)１回)となる。また、本例では、Delivery Address Listの３番目にあったＰＤＡ３１に電子メールを送信する前に、ＰＣ(Home)３３よりConfirmationが返ってきているので、ＰＤＡ３１にはメールの送信を行っていない。このため、送信希望条件Ｗ１のカウント値はそのままである。
【００４４】
【表９】
表９は、初期状態において、Score作成記憶部１８に格納されるScoreを示している。本例では、送信対象者Ａによって登録されたPriority List(表１(ｄ)参照)に基づき、各送信希望条件に対し、Priorityが１番のTimeの関連項目にはScoreとして−１が、２番のLocationの関連項目にはScoreとして−２が、３番のWeatherの関連項目にはScoreとして−３が、それぞれ与えられるようになっている。
【００４６】
【表１０】
表１０は、ステップ１１５で計算されるScoreを示している。本例では、各送信希望条件の理論値と更新されたCount値とをかけ算することで、新たなScoreを作成している。本例では、確認メールの返信がなかった送信希望条件Ｔ２のScoreが０に、確認メールの返信があった送信希望条件Ｌ３のScoreが２となる。なお、送信を行っていない送信希望条件Ｗ１については、何もせずにそのままの値を残している。
【００４８】
【表１１】
【表１２】
表１１は、ステップ１１８で修正された理論値を示し、表１２は、修正によって理論値作成記憶部１９に更新格納された理論値を示している。本例では、Scoreが増加した送信希望条件の理論値を最高点の３に変更し、Scoreが減少した送信希望条件の理論値を１だけ減少させることで、理論値の修正を行っている。従って、送信を行ったものの返信のなかった送信希望条件Ｔ２は理論値が３から２となり、送信を行って返信のあった送信希望条件Ｌ３は理論値が２から３となり、何も行わなかった送信希望条件Ｗ１は理論値が１のままとなっている。
【００５１】
【表１３】
表１３は、ステップ１０１で電子メール送信端末１ａから送信対象者Ａに対する電子メールの送信を受け付けたことにより、ステップ１０２において取得された送信対象者ＡのPersonal Conditionを示している。すなわち、Time(時刻)は16:30、送信対象者Ａが滞在していると想定される場所はTokyo(東京)、天候はOthers(その他)である。
【００５３】
【表１４】
表１４は、ステップ１０５で取得される理論値を示している。今回の場合は、前とは異なり、送信希望条件Ｔ２よりも送信希望条件Ｌ３の方の理論値が大きくなっていることがわかる。つまり、ステップ１０７でDelivery Address Listを作成する際に、送信希望条件Ｌ３を第１位、送信希望条件Ｔ２を第２位としたDelivery Address Listが作成されることになる。
【００５５】
このようなプロセスを繰り返し行うことで、送信対象者Ａに対して的確に情報が届けられる可能性、つまり、送信対象者Ａが電子メールを受け取り得る電子メール受信端末に対して優先的に電子メールを送信できる確率を上げていくことができる。このため、本実施の形態では、送信対象者Ａが最初に登録したTheoretical Delivery Address Listに多少誤りがあったとしても、実際の使用状況に基づいてDelivery Address Listの最適化を図ることができる。また、送信対象者Ａのプライバシー保護の観点から、Context DataBase部１３に登録するレコードや、Personal Conditionとして提供される情報が少ないような場合にも、送信対象者Ａの行動パターンを把握することができ、最適で有効な情報の伝達を行うことができる。さらに、本実施の形態では、Delivery Address Listの上位のメールアドレスから順に電子メールを送信しているが、送信対象者からConfirmationがあったときはそれ以降の電子メールの送信を中止しているので、トラフィック量の無用な増加を抑制することができる。
【００５６】
なお、本実施の形態では、電子メール送信端末１ａから送信対象者Ａに対する電子メール送信処理について説明を行ったが、送信対象者Ｂに対しても同様の手法を用いることでDelivery Address Listを最適化し、的確に情報を届ける可能性を高めることができる。同様に、他の電子メール送信端末１ｂ〜１ｅより送信対象者ＡやＢに対して電子メールを送信する際にも同様に適用できる。この場合、電子メール送信端末１ｂ〜１ｅは、電子メール送信端末１ａから電子メールを送信した際に得られた理論値を共用して利用することができ、送信対象者に対する情報の伝達をより的確に行うことができる。
【００５７】
また、本実施の形態では、送信対象者が最初に設定する項目として、Time/Date、Location、Weatherを挙げていたが、これに限られるものではなく、項目数については増減可能である。その他に考えられる項目としては、例えば送信対象者が仕事中(Business)か仕事外(Private)かや、送信対象者がおかれる環境(Environment)等が挙げられる。なお、送信対象者がおかれる環境としては、例えば、交通情報から、送信対象者が勤務する会社への通勤経路が渋滞だった場合は自宅勤務にする、株価情報から、送信対象者が担当している株券の値がある値以上になったら証券会社へ行く、等が挙げられる。
【００５８】
さらに、本実施の形態では、デリバリーサーバ１０から電子メールの送信を行うようにしていたが、これに限られるものではなく、電子メールの要求を受け付けた場合に、Delivery Address Listを作成して電子メール送信端末１ａ〜１ｅのいずれか(電子メールを送信しようとする端末)にこのDelivery Address Listを返信するようにしてもよい。つまり、電子メール送信端末群１に対して送信対象者の連絡先を案内するものであってもよい。この場合は、連絡先として、電子メールアドレス以外に電話番号(固定電話、携帯電話)、ファクシミリ番号などを案内するようにしてもよい。また、連絡先については、例えば送信対象者の隣人の電子メールアドレス、電話番号、ファクシミリ番号等もあり得る。
【００５９】
次に、上述したプロセスの効果を確かめるべく、シュミレーションを行った結果について説明する。
シュミレーションを行うにあたり、以下のような前提条件をおいた。
１)送信対象者は電子メール受信端末(Device)を５つ(デバイス０、１、２、３、４)持っている。
２)送信対象者は、０→１→２→３→４の順でPriority Listを作成している。
３)使用時に各デバイスから返されるConfirmationの確率を以下のように設定する。
デバイス２：１/２
デバイス０：１/４
デバイス３：１/１６
デバイス１：１/２５６
デバイス４：１/６５５３６
【００６０】
従って、上述した前提条件３)から、送信対象者が設定したPriority List
・０→１→２→３→４
が、
・２→０→３→１→４
となることが期待される。
【００６１】
このシュミレーションでは、各デバイス０〜４に返信されるConfirmationが上述した確率で生成されるような０から４までの乱数を５００個生成させた。生成させた乱数の一部を表１５に示す。
【００６２】
【表１５】
表１５は、１回目のＣｏｎｆｉｒｍａｔｉｏｎはデバイス２から、２回目もデバイス２から、３回目はデバイス０から返信された、という状態を表している。その結果、Ｃｏｎｆｉｒｍａｔｉｏｎが返信されたデバイスの番号の合計は次の通りとなった。
デバイス２：３１１個
デバイス０：１５２個
デバイス３：３５個
デバイス１：２個
デバイス４：０個
【００６４】
表１６は、上述したシュミレーションを行った結果の一覧を示している。なお、表１６において、「No」はConfirmationが返信されたデバイスの番号を意味している。
【００６５】
【表１６】
表１６は、次のことを示している。
１回目、電子メールを送信する順番は、送信対象者が設定した初期値０→１→２→３→４となっている。しかしながら、実際に電子メールを送った結果では、デバイス０、１からは返信(Confirmation)がなく、デバイス２から返信があった。このことから、デバイス０、１のCount値は０/１となり、Scoreは０.０となる。一方、デバイス２では、Count値が１/１となり、Scoreは２.０となる。なお、デバイス３、４には電子メールの送信を行っていないので、Count値は０/０のままであり、Scoreは０.０である。
２回目、電子メールを送信する順番は、１回目の結果から２→０→１→３→４となっている。実際に電子メールを送信した結果では、デバイス２から返信があった。このことからデバイス２は、Count値が２/２となり、Scoreは４.０となる。なお、デバイス０、１には電子メールの送信を行っていないので、Count値は０/１と変わらず、Scoreも０.０のままである。また、デバイス３、４にも電子メールの送信を行っていないので、これらのCount値およびScoreに変化はない。
３回目、電子メールを送信する順番は、２回目の結果から２→０→１→３→４となっている。実際に電子メールを送った結果では、デバイス０から返信があった。このことからデバイス０は、Count値が１/２となり、Scoreは２.０となる。一方、デバイス２はCount値が２/３となり、Scoreは２.６６７へと低下する。また、デバイス１、３、４には電子メールの送信を行っていないので、これらのCount値およびScoreに変化はない。
【００６７】
図８は、このようにしてシュミレーションを行って得られた電子メール送信試行回数(回数)と得られたScoreとの関係を示すグラフ図である。同図より、電子メールの送信回数が多くなっていくにつれ、送信対象者が設定したPriority Listである０→１→２→３→４から、実際の状況２→０→３→１→４に収束していくことが理解される。
【００６８】
【発明の効果】
以上説明したように、本発明によれば、複数のメールアドレスや連絡先を有する対象者に対して、的確に情報を伝達することができる。
【図面の簡単な説明】
【図１】 実施の一形態に係る電子メール送信システムの概要を説明するブロック図である。
【図２】 デリバリーサーバを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示す図である。
【図３】 デリバリーサーバの機能を説明するブロック図である。
【図４】 ＰＤＡのメール送受信機能を説明するブロック図である。
【図５】 送信対象者によるレコードおよびPriority Listの入力プロセスを説明するフローチャートである。
【図６】 電子メール送信処理の基本的な流れを示すフローチャートである。
【図７】 電子メール送信処理の基本的な流れを示すフローチャート(つづき)である。
【図８】 シュミレーションを行って得られた電子メール送信試行回数(回数)と得られたScoreとの関係を示すグラフ図である。
【符号の説明】
１…電子メール送信端末群、１ａ〜１ｅ…電子メール送信端末、１０…デリバリーサーバ、１１…送信要求受付部、１２…Personal Condition取得部、１３…Context DataBase部、１４…Theoretical Delivery Address List作成部、１５…Delivery Address List作成部、１６ａ…送信部、１６ｂ…受信部、１７…Count記憶部、１８…Score作成記憶部、１９…理論値作成記憶部、２０…インターネット、３０…第一の電子メール受信端末群、３１…ＰＤＡ、３２…ＰＣ(Office)、３３…ＰＣ(Home)、３４…ＰＣ(Parents)、４０…第二の電子メール受信端末群、４１…ＰＣ(Home)、４２…ＷＡＰ
Claims (3)
- 複数のメールアドレスを所有する送信対象者に対して電子メールを送信する電子メール送信装置であって、
複数の送信希望条件と送信対象者が送信を希望するメールアドレスとを関連付けたレコードを記憶する記憶手段と、
送信対象者に対して電子メールを送信する際に送信対象者がおかれると想定される状況を取得する状況取得手段と、
前記状況取得手段によって取得された前記状況に適合するレコードを前記記憶手段より取得して送信希望リストを作成する送信リスト作成手段と、
予め送信対象者によって設定された複数の前記送信希望条件の初期優先順位を格納する初期優先順位格納手段と、
前記初期優先順位格納手段に格納される前記初期優先順位にしたがって、前記送信希望リスト中の複数のメールアドレスを順位付けするのに用いる理論値を作成する理論値作成手段と、
前記理論値作成手段によって作成された前記理論値に基づいて、前記送信リスト作成手段で作成された前記送信希望リスト中のメールアドレスを順位付けして送信優先順位リストを作成する送信優先順位リスト作成手段と、
前記送信優先順位リスト作成手段によって作成された前記送信優先順位リストに基づいて、優先順位の高いメールアドレスから順に電子メールを送信する送信手段と、
前記送信手段によって送信された電子メールの受け取り確認を受信する受信手段と、
複数の前記送信希望条件と、前記送信手段による電子メールの送信試行回数および前記受信手段による受け取り確認回数の関係を表すカウント値とを関連付けて格納するカウント格納手段と、
前記理論値作成手段によって作成された前記理論値に対し、前記カウント格納手段に格納された前記カウント値に基づく重み付けを行い、各送信希望条件に対する期待値を作成する期待値作成手段とを含み、
前記理論値作成手段は、前記期待値作成手段によって作成された前記期待値を用いて、前記初期優先順位に基づいて作成された前記理論値を修正すること
を特徴とする電子メール送信装置。 - 前記状況取得手段は、予め送信対象者によって設定された送信対象者のスケジュールから前記状況を取得することを特徴とする請求項１記載の電子メール送信装置。
- 前記送信手段は、前記受信手段が前記受け取り確認を受信した場合に電子メールの送信を中止することを特徴とする請求項１記載の電子メール送信装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003042585A JP3982622B2 (ja) | 2003-02-20 | 2003-02-20 | 電子メール送信装置 |
| US10/742,085 US20080172466A1 (en) | 2003-02-20 | 2003-12-19 | E-mail delivery device, contact point guiding device, and e-mail delivery method and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003042585A JP3982622B2 (ja) | 2003-02-20 | 2003-02-20 | 電子メール送信装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004252724A JP2004252724A (ja) | 2004-09-09 |
| JP3982622B2 true JP3982622B2 (ja) | 2007-09-26 |
Family
ID=33025826
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003042585A Expired - Lifetime JP3982622B2 (ja) | 2003-02-20 | 2003-02-20 | 電子メール送信装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20080172466A1 (ja) |
| JP (1) | JP3982622B2 (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4633651B2 (ja) * | 2006-02-28 | 2011-02-16 | 株式会社大和証券グループ本社 | 通知システム及びプログラム |
| JP4157890B2 (ja) * | 2006-03-29 | 2008-10-01 | 東日本電信電話株式会社 | 電子メール配送システム及び電子メール配送プログラム |
| JP4820225B2 (ja) * | 2006-07-12 | 2011-11-24 | 京セラ株式会社 | 携帯電話機 |
| US7885948B2 (en) * | 2007-06-28 | 2011-02-08 | Microsoft Corporation | Automatically managing incoming communications between sender and recipient, analyzing factors, selectively applying observed behavior, performing designated action |
| US7966329B1 (en) | 2007-08-02 | 2011-06-21 | Intuit Inc. | Method and system for recognition and categorization of financial transactions |
| US20090037461A1 (en) * | 2007-08-02 | 2009-02-05 | Intuit Inc. | Method and system for automatic recognition and categorization of transactions |
| US8924497B2 (en) * | 2007-11-16 | 2014-12-30 | Hewlett-Packard Development Company, L.P. | Managing delivery of electronic messages |
| JP2010224627A (ja) * | 2009-03-19 | 2010-10-07 | Sharp Corp | プリントシステム |
| EP2320363A1 (en) * | 2009-10-30 | 2011-05-11 | Research In Motion Limited | A method for predicting messaging addresses for an electronic message composed on an electronic device |
| US8341230B2 (en) | 2009-10-30 | 2012-12-25 | Research In Motion Limited | Method for predicting messaging addresses for an electronic message composed on an electronic device |
| US9230245B1 (en) * | 2012-06-21 | 2016-01-05 | Amazon Technologies, Inc. | Deliverability-based e-mail sending |
| US9824377B1 (en) * | 2012-06-21 | 2017-11-21 | Amazon Technologies, Inc. | Round-robin e-mail scheduling |
| US9071565B2 (en) * | 2012-11-05 | 2015-06-30 | Qualcomm Incorporated | Optimizing offline message (network history) delivery for users accessing an application from a single device |
| JP2014174961A (ja) * | 2013-03-13 | 2014-09-22 | Nippon Telegr & Teleph Corp <Ntt> | メッセージ配信システム及びメッセージ配信方法 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1165960A (ja) * | 1997-08-27 | 1999-03-09 | Matsushita Electric Ind Co Ltd | ディレクトリ管理を用いたメッセージサーバ装置 |
| US20020087649A1 (en) * | 2000-03-16 | 2002-07-04 | Horvitz Eric J. | Bounded-deferral policies for reducing the disruptiveness of notifications |
| WO2002045344A2 (en) * | 2000-11-30 | 2002-06-06 | Message Machines, Inc. | Systems and methods for routing messages to communications devices |
| US7269627B2 (en) * | 2001-07-27 | 2007-09-11 | Intel Corporation | Routing messages using presence information |
| US7185059B2 (en) * | 2002-09-17 | 2007-02-27 | Bellsouth Intellectual Property Corp | Multi-system instant messaging (IM) |
| US7474741B2 (en) * | 2003-01-20 | 2009-01-06 | Avaya Inc. | Messaging advise in presence-aware networks |
-
2003
- 2003-02-20 JP JP2003042585A patent/JP3982622B2/ja not_active Expired - Lifetime
- 2003-12-19 US US10/742,085 patent/US20080172466A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004252724A (ja) | 2004-09-09 |
| US20080172466A1 (en) | 2008-07-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3982622B2 (ja) | 電子メール送信装置 | |
| US7389349B2 (en) | Electronic messaging system for adjusting computer polling period based on user's predicted messaging activity | |
| US8880613B2 (en) | System and method for managing mail messages | |
| CN1702668A (zh) | 用于社会交往的系统和方法 | |
| JP4380686B2 (ja) | 電子メール送信端末装置、電子メール送信方法、及び電子メール送信プログラム | |
| JP2015510647A (ja) | 時間管理される電子メール・メッセージ | |
| CN1849789A (zh) | 可利用无线网络连接到邮件服务器和利用本地链路同步连接到pc的手持式装置 | |
| EP1096744B1 (en) | Electronic mail system | |
| US20030096599A1 (en) | Message distribution system and method for selecting the device where a recipient is most likelly to recognize a message | |
| EP3973417A1 (en) | Efficient freshness crawl scheduling | |
| JP2004341803A (ja) | メッセージ送受信最適化方法、メッセージ送受信最適化システム | |
| JP5611952B2 (ja) | ウェブアプリケーションのための非同期待ち行列型メッセージング | |
| JP4585957B2 (ja) | 電子メールシステム | |
| JP5375585B2 (ja) | 電子メール返信時間予測装置、電子メール返信時間予測方法、プログラム | |
| WO2002069568A1 (en) | Group-independent message transfer method and system lending specified application module | |
| JP2003223383A (ja) | データ送信方法およびデータ格納方法、情報処理装置、並びにプログラム | |
| US20120233270A1 (en) | Method for transmitting and receiving messages | |
| JP4807251B2 (ja) | メールゲートウェイ装置、メールシステムおよびメール受信状況の提示方法 | |
| JP4644147B2 (ja) | 通信管理装置、通信管理方法、及びプログラム | |
| JP3714137B2 (ja) | メールサーバ及び記録媒体 | |
| JP2002366492A (ja) | 送信装置および方法、受信装置および方法、通信システム、記録媒体、並びにプログラム | |
| JP3606262B2 (ja) | 電子メールサーバ及びその制御方法 | |
| JP2002297516A (ja) | 受信装置および方法、送信装置および方法、通信システム、記録媒体、並びにプログラム | |
| KR100383741B1 (ko) | 카드 발송 스케줄을 관리할 수 있는 전자 카드 전송 방법및 시스템 | |
| JP4146584B2 (ja) | 相手にメッセージアドレスを知られることなくメッセージの送受信を行うことを可能にした通信網システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060911 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060919 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061219 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070206 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070507 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070611 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070626 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20070628 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070627 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100713 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |