JP2007140848A

JP2007140848A - 電子メール管理方法及び電子メールシステム

Info

Publication number: JP2007140848A
Application number: JP2005333085A
Authority: JP
Inventors: Yukihiro Takeuchi; 幸弘竹内
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2005-11-17
Filing date: 2005-11-17
Publication date: 2007-06-07
Anticipated expiration: 2025-11-17
Also published as: JP4585957B2

Abstract

【課題】送信先ユーザによる電子メールの開封時刻をある程度正確に予測することを可能にし、送信先のユーザがいつ開封するかわからないため、電話等でフォローしなければならないようなことを防止する。
【解決手段】開封予想時刻計算装置１０１は、メールサーバ１０５内に管理されている電子メールの宛先となるユーザ毎に、そのユーザの１週間の曜日毎、各１日の中の各１時間毎に、各時間の始まりで未読である電子メールの数と、その１時間の間に開封した電子メールの数とを特徴情報１０４として管理し、電子メール送信ユーザからの電子メールの開封時刻の予想要求に対して、前記特徴情報と、前記スケジュールサーバ１０７内に管理されている送信先ユーザのスケジュール情報とから送信先での電子メールの開封時刻を予想する。
【選択図】図１

Description

本発明は、電子メール管理方法及び電子メールシステムに係り、特に、送信先での電子メールの開封時刻を予想する電子メール管理方法及び電子メールシステムに関する。

従来、送信した電子メールの送信先での開封時刻の予想は、送信先のユーザのスケジュール情報を取得し、現在時刻から最短にある予定の入っていない時間（空き時間）を開封予想時刻とするという方法で行われていた。このような送信した電子メールの送信先での開封時刻を予想することを可能にした従来技術として、例えば、特許文献１等に記載された技術が知られている。
特開平６−２６８６７７号公報

前述した従来技術は、送信先ユーザのスケジュールの空き時間を開封予想時刻として示すものであるが、その時間にメールが開封されるとは限らず、また、送信先のユーザのスケジュール情報がない場合や、スケジュールに予定が未入力の場合、常に送信時刻を開封予想時刻とすることとしており、電子メールの送信者は、相手のメール開封時刻を正確には知ることができないという問題点を有している。

本発明の目的は、前述した従来技術の問題点を解決し、送信先ユーザによる電子メールの開封時刻をある程度正確に予測することを可能とした電子メール管理方法及び電子メールシステムを提供することにある。

本発明によれば前記目的は、送信先での電子メールの開封時刻を予想する電子メール管理方法において、電子メールの宛先となるユーザ毎に、そのユーザの１週間の曜日毎、各１日の中の各１時間毎に、各時間の始まりで未読である電子メールの数と、その１時間の間に開封した電子メールの数とを特徴情報として管理し、電子メール送信ユーザからの電子メールの開封時刻の予想要求に対して、前記特徴情報と、送信先ユーザのスケジュール情報とから送信先での電子メールの開封時刻を予想することにより達成される。

また、前記目的は、送信先での電子メールの開封時刻を予想する電子メールシステムにおいて、開封予想時刻計算装置と、メールサーバと、スケジュールサーバとを備え、前記開封予想時刻計算装置が、前記メールサーバ内に管理されている電子メールの宛先となるユーザ毎に、そのユーザの１週間の曜日毎、各１日の中の各１時間毎に、各時間の始まりで未読である電子メールの数と、その１時間の間に開封した電子メールの数とを特徴情報として管理する手段と、電子メール送信ユーザからの電子メールの開封時刻の予想要求に対して、前記特徴情報と、前記スケジュールサーバ内に管理されている送信先ユーザのスケジュール情報とから送信先での電子メールの開封時刻を予想する手段とを備えたことにより達成される。

本発明によれば、送信先ユーザによる電子メールの開封時刻をある程度正確に予測して開封予想時刻を知ることができるので、電話で開封を確認する等の無駄を省くことができ、また、開封予想時刻が遅かった場合に、他の連絡手段をとることができる。

以下、本発明による電子メール管理方法及び管理システムの実施形態を図面により詳細に説明する。

図１は本発明の一実施形態による電子メールシステムの構成を示すブロック図である。図１において、１０１は開封予想時刻計算装置、１０２は特徴情報更新部、１０３はデータベース、１０４は特徴情報テーブル、１０５はメールサーバ、１０６はメール情報、１０７はスケジュールサーバ、１０８はスケジュール、１０９はネットワーク、１１０はクライアント、１１１はカレンダーである。

本発明の実施形態による電子メールシステムは、インターネット等のネットワーク１０９に、開封予想時刻計算装置１０１と、メールサーバ１０５と、スケジュールサーバ１０７と、ユーザ側である複数のクライアント１１０とが接続されて構成されている。メールサーバ１０５は、その内部に複数のユーザのメール情報１０６を格納して、クライアント相互間での電子メールの送受信を制御する。スケジュールサーバ１０７は、その内部にメールサーバ１０５内にメール情報１０６を持つユーザのスケジュール１０８の情報と、カレンダー１１１とを有している。また、開封予想時刻計算装置１０１は、内部にデータベース１０３と、特徴情報更新部１０２とを有し、送信された電子メールの送信先での開封時刻の予測処理を行う。データベース１０３は、メールサーバ１０５内にメール情報１０６を持つ全ユーザの特徴情報テーブル１０４を格納している。

開封予想時刻計算装置１０１、メールサーバ１０５、スケジュールサーバ１０７、クライアント１１０のハードウェア構成は、図に示していないが、よく知られているように、ＣＰＵ、主記憶装置、ハードディスク装置等を備えて構成されるものであってよい。必要な処理のためのプログラムが、通常、ハードディスク装置に格納され、主記憶装置にロードされた後に、ＯＳの下でＣＰＵにより実行されることにより、本発明の実施形態での各種の処理を行う。

図２はあるユーザの受信メール情報から、２００５年７月２９日９時の時点で、既読、未読の受信メールを抽出した一覧である受信メール情報を説明する図である。

図２に示す受信メール情報２０９は、メールの１通２０８毎に、主題２０１、属性２０２、宛先タイプ２０３、送信者２０４、送信者の役職２０５、受信日時２０６、開封日時２０７の各情報を持って構成されている。属性２０２は、メール送信時に指定する至急、返信要求等のメールに付加された情報である。宛先タイプ２０３は、メール送信時にユーザ毎に指定されるＴＯ、ＣＣ、ＢＣＣの宛先のタイプである。開封日時２０７が空白のメールは、そのメールがまだ開封されていないことを示している。

図３はあるユーザの特徴情報テーブル１０４の一部の例を説明する図である。特徴情報テーブル１０４を構成するレコードは、時間帯３０４の１時間おきに、０時から２４時までの２４のレコードが存在する。１つのレコード３０５は、時間帯３０４の他に、宛先タイプ３０１と属性３０３と送信者の役職３０２とのすべての組み合わせの領域を持つ。またこの特徴情報テーブル１０４は、曜日毎に存在する。すなわち、１人のユーザに対して、図３示す特徴情報テーブル１０４が７つ存在している。

宛先タイプ３０１と属性３０３と送信者の役職３０２との組み合わせの各時間帯の領域には、特徴情報としての分数の値が格納される。この分数の分母は、レコードの宛先タイプ３０１、属性３０３、送信者の役職３０２と一致する宛先タイプ２０３、属性２０２、送信者の役職２０５を持つメールで、その時間帯の開始時刻で未読だったメールの数の合計である。また、分子は、レコードの宛先タイプ３０１、属性３０３、送信者の役職３０２と一致する宛先タイプ２０３、属性２０２、送信者の役職２０５を持つメールで、その時間帯の開始時刻で未読だったメールが、その時間帯中に読まれたメールの数の合計である。

図１に示す特徴情報更新部１０２は、自動的に、一時間おきにデータベース１０３に格納している全ユーザの特徴情報テーブル１０４内の特徴情報に対して、特徴情報更新処理行う。

図４は特徴情報更新部１０２が行う特徴情報更新処理の動作を説明するフローチャートであり、次に、これについて説明する。

（１）特徴情報更新部１０２は、まず、スケジュールサーバ１０７から、更新処理を行っているユーザの、今（Ｘ）時から（Ｘ＋１）時までの更新処理を行う１時間分のスケジュールを取得する（ステップ４０１）。

（２）Ｘ時〜（Ｘ＋１）時までの時間内にスケジュールがないか否かを判定し、スケジュールに予定が存在した場合、このユーザに対する特徴情報更新処理を行わず、ここでの処理を終了する（ステップ４０２）。

（３）ステップ４０２の判定で、Ｘ時〜（Ｘ＋１）時までの時間内のスケジュールに予定が存在しなかった場合、メールサーバ１０５から、現在更新を行っている一時間の開始時刻より後に開封されたメール、または、まだ開封されていないメールの一覧（図２）を取得する（ステップ４０３）。

（４）取得した全てのメールに対して、図５により後述するメール数カウント処理４０５を実行して、処理を終了する（ステップ４０４）。

図４により説明した特徴情報更新処理は、１時間おきではなく、一定時間おきに実行してもよい。そして、例えば、３時間おきに実行する場合、図４により説明した１時間分ずつの特徴情報更新処理を３回実行する。

図５は図４のフローでのメール数カウント処理４０５の処理動作を説明する図であり、次に、これについて説明する。なお、ここで説明する処理は、前述したフローのステップ４０４の処理で取得したメールの一覧にある全てのメールに対して実行される。

（１）まず、メールの受信日時２０６が現在更新を行っている１時間の時間帯の開始時刻より古いか否か、すなわち、受信時間≦Ｘであるか否かを判別し、受信時間≦Ｘでなかった場合、すなわち、開始時刻より新しかった場合、ここでのメール数カウント処理を終了する（ステップ５０１）。

（２）ステップ５０１の判定で、メールの受信日時２０６が現在更新を行っている１時間の時間帯の開始時刻より古かった場合、スケジュールサーバ１０７のカレンダー１１１から現在更新処理を行っている日付の曜日を取得する（ステップ５０２）。

（３）ステップ５０２の処理で取得した曜日のテーブルを取得し、更新処理を行っているユーザの特徴情報テーブル１０４から取得した曜日のテーブルを更新する。そのため、そのテーブルの更新を行っているＸ時〜（Ｘ＋１）時までの時間帯のレコードで、現在処理しているメールの宛先タイプ２０３、属性２０２、送信者の役職２０５と、宛先タイプ３０１、属性３０３、送信者の役職３０２とが一致する領域の分母に１を加える（ステップ５０３）。

（４）次に、メールの開封日時２０７が現在更新を行っている一時間の終了時刻より古いか否かを判別し、すなわち、開封時間≦Ｘ＋１であるか否かを判別し、開封時間≦Ｘ＋１でなかった場合、すなわち、終了時刻より新しかった場合、ここでのメール数カウント処理を終了する（ステップ５０４）。

（５）ステップ５０４の判定で、メールの開封日時２０７が現在更新を行っている一時間の終了時刻より古かった場合、更新を行っている時間帯のレコードで、現在処理しているメールの宛先タイプ２０３、属性２０２、送信者の役職２０５と、宛先タイプ３０１、属性３０３、送信者の役職３０２とが一致する領域の分子に１加え、ここでのメール数カウント処理を終了する（ステップ５０５）。

図６は開封時刻の予想計算に必要なデータと計算結果のデータとを示す図であり、次に、これについて説明する。

図６（ａ）は、開封予想時刻を計算するために必要とするデータ６０１の例を示しており、１つデータ６０６ａ（６０６ｂ）は、送信先６０２、宛先タイプ６０３、送信者の役職６１５、属性６０４、送信時間６０５の各情報を持っている。

図６（ｂ）は、送信先のユーザのスケジュール１０８の例を示しており、１つのスケジュール６１０（６１４）は、開始時間６０７、終了時間６０８、内容６０９の各情報を持っている。

図６（ｃ）は、開封予想時刻計算装置１０１が開封予想時刻を計算した結果のデータ６１２を示しており、１つの結果６１３ａ（６１３ｂ）は、開封予想時刻６１１を持っている。

開封予想時刻計算装置１０１に入力されるデータ６０１のレコードの数と計算の結果として出力される結果のデータ６１２のレコードの数と順序とは一致しており、入力されるデータの１つ目のレコード６０６ａの計算結果が、出力される結果のデータの１つ目のレコード６１３ａとなる。同様に、入力されるデータの２つ目のレコード６０６ｂの計算結果が、出力される結果のデータの２つ目のレコード６１３ｂとなる。

開封予想時刻計算装置１０１は、クライアントからデータが送られてくると、まず、送られてきたデータの送信先６０２を確認する。そして、送信先６０２のユーザの特徴情報テーブル１０４がデータベース１０３に存在しない場合、その入力データに対する開封予想時刻を空白とする。また、送られてきたデータ中で、特徴情報テーブル１０４内に特徴情報が存在する送信先６０２を持つレコードに対して、開封予想時刻を計算する。

図７は開封予想時刻計算装置１０１が送信された電子メールの送信先での開封時刻を予想する処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）開封予想時刻計算装置１０１は、最初に、スケジュールサーバ１０５から送信先６０２に指定されているユーザのスケジュールの開始時間６０７が送信日時６０５以降のスケジュールを取得すると共に、送信日時に進行中のスケジュールが存在した場合、それも取得し、送信日時を開封予想時刻として取敢えず設定する（ステップ７０１、７０７）。

（２）ステップ７０７で設定した開封予想時刻に進行中のスケジュールが存在するか否か、または、開封予想時刻に開始されるスケジュールが存在するか否かをチェックし、該当するスケジュールが存在した場合、開封予想時刻をそのスケジュールの終了時間６０８にセットし、ステップ７０２からの処理に戻って、再び、スケジュールのチェックからの処理を実行する（ステップ７０２、７０３）。

（３）ステップ７０２のチェックで、スケジュールが存在しなかった場合、特徴情報テーブルに記載されている分数の値の分子の合計をサンプル数として求め、その合計が予め定めた一定値Ｖを超えているか否かを判定し、分子の合計が予め定めた一定値Ｖを超えていなかった場合、すなわち、サンプル数が少なかった場合、開封時刻予想処理を終了して、ここまでの処理で算出した現在の開封予想時刻を含む時間帯を返す（ステップ７０８）。

（４）ステップ７０８の判定で、分子の合計が予め定めた一定値Ｖを超えていた場合、すなわち、サンプル数が充分であった場合、スケジュールサーバ１０７のカレンダー１１１から開封予想時刻の曜日を取得する。そして、送信先のユーザの曜日が一致する特徴情報テーブル１０４から開封予想時刻を含む時間帯３０４のレコードを取得し、現在処理中のメールデータの宛先タイプ６０３、属性６０４、送信者の役職６１５と、そのレコードの宛先タイプ３０１、属性３０３、送信者の役職３０２とが一致するカラムの値Ｙを取得する（ステップ７０４）。

（５）ステップ７０４で取得した値Ｙが予め定めた指定値Ｚを超えているか否かを判定し、超えていた場合、開封時刻予想処理を終了して、ここまでの処理で見出した現在の開封予想時刻を含む時間帯を返す（ステップ７０５）。

（６）ステップ７０５の判定で、値Ｙが予め定めた指定値Ｚを超えていなかった場合、ここまでの処理で算出した開封予想時刻に１時間加え、その値を新たな開封予想時刻として算出し、ステップ７０２からの処理に戻って処理を続ける（ステップ７０６）。

開封予想時刻計算装置１０１は、送られてきたデータの全てに対して、前述した処理を行って電子メールの開封予想時刻の計算を終了したら、クライアント１１０に開封予想時刻の計算結果６１２を返す。

図８は本発明の実施形態でのメール送信画面と開封予想時刻表示画面との例を示す図である。

図８（ａ）は本発明の実施形態による開封時刻予想を行うシステムでのメール送信画面の例である。このメール送信画面８０１は、送信ボタン８０２、開封時間予想ボタン８０３、至急チェックボックス８０４、ＴＯ宛先入力テキストエリア８０５、ＣＣ宛先入力テキストエリア８０６、主題入力エリア８０７、本文入力エリア８０８から構成される。図示８（ａ）の例では、Ａ課長とＡ担当とに主題「打ち合わせ」のメールを送信するものとしている
図示メール送信画面の例において、開封時間予想ボタン８０３が押下されると、クライアント１１０である端末装置は、メール送信画面８０１から必要な情報を抽出し、これらの情報に現在のクライアントのユーザの役職を加えて、開封予想時刻計算装置１０１に送信する。

いま、開封時間予想ボタン８０３が押下された時間を２００５年８月２日０時１５分とすると、開封予想時刻計算装置１０１に送る情報は、図６（ａ）に示して説明したようなものとなる。この情報を受信した開封予想時刻計算装置１０１は、１件目のデータ６０６ａの処理を図７により説明したフローに従って行う。

前述したような具体的な例で図７により説明した開封時刻予想処理を説明する。

まず、Ａ課長のスケジュール情報を取得する（ステップ７０１）。ここでは、Ａ課長のスケジュールを図６（ｂ）に示して説明したようなものとする。このスケジュールから開封予想時刻は、送信日時の２００５年８月２日０時１５分とされる（ステップ７０７）。

開封予想時刻の２００５年８月２日０時１５分のスケジュール６１４は帰宅中であるので（ステップ７０２）、開封予想時刻をこのスケジュールの終了時間２００５年８月２日８時００分とする（ステップ７０３）。２００５年８月２日８時００分に進行中のスケジュール、開始されるスケジュールは存在しないので、次の処理に進む。

ここで、特徴情報テーブルの分子の合計、つまり、サンプル数が充分であるか否かをチェックするが、ここではサンプル数が充分であったとする（ステップ７０８）。

次に、Ａ課長の特徴情報の中から２００５年８月２日の曜日にマッチするテーブルを取得する。取得したテーブルは、図３に示して説明したようなものとする。ここでの前述で仮に決定している開封予想時刻を含む時間帯は、図３の特徴情報テーブルに３０７として示しているように、８時００分〜８時５９分である。図３に示す特徴情報テーブルの中で、その時間帯の宛先タイプがＴＯで、送信者の役職が課長、属性が至急の領域３０８に記載されている値は、２／１０である（ステップ７０４）。

この値が指定値を超えていたら、８時００分〜８時５９分が開封予想時刻となるが、ここで、指定値Ｚの値を０．３とすると、２／１０は指定値よりも小さいと判定されるため（ステップ７０５）、前述の開封予想時刻に１時間加え、開封予想時刻は２００５年８月２日９時００分となる（ステップ７０６）。

この開封予想時刻に進行中のスケジュールも、開始されるスケジュールも存在せず、サンプル数も充分であるため、再び、特徴情報から値を取得する。この開封予想時刻を含む時間帯は、図３の特徴情報テーブルに３０９として示しているように、９時００分〜９時５９分である。図３に示す特徴テーブルの中で、その時間帯の宛先タイプがＴＯで、送信者の役職が課長、属性が至急の領域３１０の値は、１５／４０である。この値は、指定値Ｚ以上であるので、現在の開封予定時刻を含む時間帯２００５年８月２日９時００分〜９時５９分を返す。

同様の処理を２件目のデータ６０６ｂに対しても行い、このデータでの開封予想時刻が２００５年８月２日８時００分〜８時５９分だったとする。３件目のデータはないため、開封予想時刻計算の結果をクライアントに返す。このときにクライアントに返される開封予想時刻計算結果のデータは、図６（ｃ）により説明したようなものである。

クライアント１１０は、受け取った開封予想時刻計算結果のデータを画面に表示する。この場合の表示画面の例を図８（ｂ）に示している。この開封予想時刻表示画面８０９は属性８１０、宛先８１１、宛先タイプ８１２、開封予想時刻８１３と、閉じるボタン８１４を表示する。

属性８１０、宛先８１１、宛先タイプ８１２の各データは、図８（ａ）に示して説明したメール送信画面８０１から取得し、開封予想時刻８１３は、開封予想時刻計算装置１０１から返えされた結果６１２から取得する。

図９は送信済みメール一覧画面と開封予想時刻表示画面との例を示す図である。本発明の実施形態での送信済みメール一覧画面の例を図９（ａ）に示しており、この送信済みメール一覧画面９０１は、開封時間予想ボタン９０２、メール選択用チェックボックス９０３、属性９０９、主題９０４、宛先９０５、宛先タイプ９０６、送信日時９０７から構成されている。

図９（ａ）に示す送信済みメール一覧画面９０１で、ユーザが開封予想時間を知りたいメールを、メール選択用チェックボックス９０３に９０８として示すようにチェックを入れて選択し、開封時間予想ボタン９０２を押下すると、公知の開封確認機能を実行する。この開封確認の結果、Ａ担当は開封済みだったとすると、この場合、Ａ課長のデータのみが開封予想時刻計算装置１０１に送られる。

送信済みのメールに対して開封時刻予想を行う場合、開封予想時刻計算装置１０１に送信されるデータの送信日時６０５を、選択されたメールが実際に送信された日時ではなく、今、開封時間予想ボタンが押下された時間とする。開封予想時刻計算装置１０１での処理は、図７に示して説明したフローの場合と同様に行われる。

開封予想時刻計算装置１０１から返送されてきたデータを表示した開封予想時刻表示画面９０９９の例を図９（ｂ）に示している。このとき、前述の開封確認の結果が開封済みであったＡ担当の開封予想時刻には、開封済み９１０が表示される。

前述した本発明の実施形態での処理は、プログラムにより構成し、計算機が備えるＣＰＵに実行させることができ、また、それらのプログラムは、ＦＤ、ＣＤＲＯＭ、ＤＶＤ等の記録媒体に格納して提供することができ、また、ネットワークを介してディジタル情報により提供することができる。

本発明の一実施形態による電子メールシステムの構成を示すブロック図である。あるユーザの受信メール情報から、２００５年7月２９日９時の時点で、既読、未読の受信メールを抽出した一覧である受信メール情報を説明する図である。あるユーザの特徴情報テーブルの一部の例を説明する図である。特徴情報更新部が行う特徴情報更新処理の動作を説明するフローチャートである。図４のフローでのメール数カウント処理の処理動作を説明する図である。開封時刻の計算に必要なデータと計算結果のデータとを示す図である。開封予想時刻計算装置が送信された電子メールの送信先での開封時刻を予想する処理動作を説明するフローチャートである。本発明の実施形態でのメール送信画面と開封予想時刻表示画面との例を示す図である。送信済みメール一覧画面と開封予想時刻表示画面との例を示す図である。

符号の説明

１０１開封予想時刻計算装置
１０２特徴情報更新部
１０３データベース
１０４特徴情報テーブル
１０５メールサーバ
１０６メール情報
１０７スケジュールサーバ
１０８スケジュール
１０９ネットワーク
１１０クライアント
１１１カレンダー

Claims

送信先での電子メールの開封時刻を予想する電子メール管理方法において、電子メールの宛先となるユーザ毎に、そのユーザの１週間の曜日毎、各１日の中の各１時間毎に、各時間の始まりで未読である電子メールの数と、その１時間の間に開封した電子メールの数とを特徴情報として管理し、電子メール送信ユーザからの電子メールの開封時刻の予想要求に対して、前記特徴情報と、送信先ユーザのスケジュール情報とから送信先での電子メールの開封時刻を予想することを特徴とする電子メール管理方法。
前記特徴情報は、電子メールの宛先タイプ、電子メール送信者の役職、電子メールの属性の全ての組み合わせ毎に管理されていることを特徴とする請求項１記載の電子メール管理方法。
前記特徴情報は、電子メールの情報と送信先ユーザのスケジュール情報とにより一定時間毎に更新されることを特徴とする請求項１または２記載の電子メール管理方法。
前記送信先での電子メールの開封時刻は、送信先ユーザのスケジュールがなく、かつ、前記特徴情報の各１時間毎の各時間の始まりで未読である電子メールの数を分子としその１時間の間に開封した電子メールの数を分母とした分数の値が予め定めた指定値を超える値を持つ時間帯を電子メールの開封時刻として予想することを特徴とする請求項１、２または３記載の電子メール管理方法。
送信先での電子メールの開封時刻を予想する電子メールシステムにおいて、開封予想時刻計算装置と、メールサーバと、スケジュールサーバとを備え、前記開封予想時刻計算装置は、前記メールサーバ内に管理されている電子メールの宛先となるユーザ毎に、そのユーザの１週間の曜日毎、各１日の中の各１時間毎に、各時間の始まりで未読である電子メールの数と、その１時間の間に開封した電子メールの数とを特徴情報として管理する手段と、電子メール送信ユーザからの電子メールの開封時刻の予想要求に対して、前記特徴情報と、前記スケジュールサーバ内に管理されている送信先ユーザのスケジュール情報とから送信先での電子メールの開封時刻を予想する手段とを備えたことを特徴とする電子メールシステム。