(57)【要約】【課題】  メール送信時に宛先に意図しない宛先や、間違った宛先が指定されていることに気づきにくく、誤って送信してしまう問題がある。【解決手段】  本発明では、アドレス帳に登録されているグループの情報を利用してメール作成時の宛先指定を補助する宛先指定支援方法を提供する。  本発明で提供する宛先指定支援方法は、ユーザが登録したアドレス帳を保持する記憶装置と、グループ間の規則を保持する記憶装置を保持する。  返信メールの宛先指定時に、システムが自動的に宛先が所属するグループ、そのグループに関係する規則を参照し、警告を表示する。  これにより、受信メールを返信する場合においても、意図しない宛先が含まれていることに容易に気づくことができる。【選択図】  図１
2006309365.tif 000002
【特許請求の範囲】
【請求項１】
アドレス帳に登録されているグループの情報を利用してメール作成時にメッセージを表示することによって、指定宛先の確認や修正を促す宛先指定支援方法。
【請求項２】
請求項１の宛先指定支援方法において、グループ間で設定された条件によってメッセージを出力する手段を備えることを特徴とする宛先指定支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メールの送信時に指定する宛先入力を支援する方法およびそのシステムに関するものである。
【背景技術】
【０００２】
従来は、特開２０００−３０７６３０号公報に記載のように、アドレス帳にグループを作成してアドレスを登録していた。
【０００３】
アドレス帳に作成されるグループは、ユーザと関連のあるグループ単位で作成されることが一般的である。
【０００４】
【特許文献１】特開２０００−３０７６３０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
受信メールを返信する場合には、指定された宛先をそのまま利用する場合が多く、意図しない宛先が含まれている場合がある。
【０００６】
従来技術は、グループ名やアドレスからアドレス帳に登録されているアドレスを検索する機能を有しているが、アドレス帳に登録されているグループを容易に検索することができない欠点がある。そのため、意図しない宛先の確認に手間がかかってしまい、そのまま気づかずにメールを送信してしまう場合もある。
【０００７】
本発明が解決しようとする目的は、メール送信時に指定宛先の確認を容易にする宛先指定支援方法を提供することを最も主要な特徴とする。
【課題を解決するための手段】
【０００８】
本発明では、アドレス帳に登録されているグループの情報を利用してメール作成時の宛先指定を補助する宛先指定支援方法を提供する。
【０００９】
本発明で提供する宛先指定支援方法は、ユーザが登録したアドレス帳を保持する記憶装置と、グループ間の規則を保持する記憶装置を保持する。
【００１０】
返信メールの宛先指定時に、システムが自動的に宛先が所属するグループ、そのグループに関係する規則を参照し、警告を表示する。
【００１１】
これにより、受信メールを返信する場合においても、意図しない宛先が含まれていることに容易に気づくことができる。
【発明の効果】
【００１２】
本発明により、メール送信時の誤った宛先指定や、受信メール返信時の意図しない宛先が含まれていることに容易に気づくことができる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。
【００１４】
図１は、本発明を説明するための全体構成図である。クライアント１０１、メールサーバ１１６がネットワーク１１８で接続されている。
【００１５】
クライアント１０１の内部には、CPU１１０、HDD１１１、入出力装置１１４、通信制御部１１５、メモリ１１９が内部パス１１７で接続されている。
【００１６】
メモリ１１９内では、アドレス帳管理処理１０２、メール送受信処理１０６が動作している。アドレス帳管理処理１０２は、アドレス帳情報制御処理１０５、定義情報編集処理１０３、定義情報表示処理１０４を有している。メール送受信処理１０６は、受信メール表示処理１０７、新規メール作成処理１０８、メール送受信制御処理１０９を有している。
【００１７】
HDD１１１には、アドレス帳データ１１２、規則定義データ１１３が格納されている。
【００１８】
ユーザは、アドレス帳管理処理１０２内のアドレス帳情報制御処理１０５を利用して、アドレス帳データ１１２の参照および編集を実行することができる。
【００１９】
規則データ１１３は、アドレス帳内の登録されているグループ間で定義する規則に関するデータである。ユーザは、アドレス帳管理処理１０２内の定義情報編集処理１０３、定義情報表示処理１０４を利用して、規則データ１１３の参照および編集を実行することができる。
【００２０】
図２は、図１においてHDD１１内に格納されているアドレス帳データ１１２および規則定義データ１１３のデータ構成を示している。
【００２１】
図２(a)は、アドレス帳データ１１２のテーブルを示しており、グループ名２０１、宛先２０２で構成されている。レコード２０３は、宛先「User1@mail.net」がグループ「友達」の所属していることを示している。
【００２２】
図２(b)は、規則定義データ１１３のテーブルを示しており、チェック対象２０４、関連グループ２０５、規則２０６で構成されている。チェック対象２０４、関連グループ２０５には定義するグループ名を格納する。
【００２３】
レコード２０７aは、グループ「顧客（Ａ社）」の宛先に対して送信する場合は、グループ「上司」の宛先を含めることが必須であることを意味する。
【００２４】
レコード２０７ｂは、グループ「顧客（Ａ社）」の宛先に対して送信する場合は、グループ「仕事仲間」の宛先を含めることを推奨することを意味する。
【００２５】
レコード２０７ｃは、グループ「仕事仲間」の宛先に対して送信する場合、グループ「友達」の宛先を含まれると、警告をだし注意を促すことを意味する。
レコード２０７ｄは、グループ「顧客（Ｂ社）」の宛先に対して送信する場合は、警告をだし注意を促すことを意味する。
【００２６】
レコード２０７ｅは、グループ「顧客（Ａ社）」の宛先に対して送信する場合、グループ「顧客（Ａ社）」の宛先を一緒に指定することを禁止することを意味する。
【００２７】
レコード２０７ｆは、グループ「顧客（Ａ社）」の宛先を含む受信メールが重要であることを意味する。
【００２８】
レコード２０７ｇは、グループ「顧客（Ａ社）」の宛先を含む受信メールが、グループ「上司」の宛先を含んでいる場合に、受信メールが重要であることを意味する。
【００２９】
図３は、メール送受信処理１０６内の受信メール表示処理１０７の処理概要フローを示している。受信メール表示処理１０７では、まずメール送受信制御処理１０９を用いてメール受信処理を行う（３０１）。受信メールから処理に利用するための宛先情報の抽出を行う（３０２）。抽出した全ての宛先に対して、アドレス帳データテーブル１１２から宛先２０２を検索キーにして所属するグループ名２０１を検索する（３０３）。検索したグループに対して、関連する規則をチェックするための受信用規則チェック３０５を行う（３０４）。
【００３０】
図４は、図３における受信用規則チェック３０５の処理フローを示している。規則をチェックするために、処理するグループに該当する規則を規則定義データテーブル１１３から検索する（４１１）。該当する規則を検索する際は、規則定義データテーブル１１３のチェック対象２０４を検索キーにして該当する規則レコードを検索する。検索した規則定義に対してチェックを実行するためのループ処理としてカウンタを初期化する（４０１）。検索した規則定義の規則定義データテーブル１１３内の設定項目である規則２０６の設定値をチェックする（４０２）。受信用の規則は“重要”だけであるため、検索された規則定義の中で規則が“重要”に設定されている規則定義だけチェックする（４０３）。検索した規則定義の規則定義データテーブル１１３内の設定項目である関連グループ２０５の設定値をチェックする（４０４）。関連グループの設定値が“−”の場合は、関連グループに所属する宛先があるかをチェックしない（４０５）。規則定義データテーブル１１３内の規則定義レコード２０７ｆは、関連グループに所属する宛先があるかをチェックしないケースになる。関連グループの設定値が“−”以外の場合、関連グループに設定されているグループに所属する宛先が含まれているかをチェックする（４０６）。関連するグループに所属する宛先がない場合は、次の規則をチェックし、関連するグループに所属する宛先がない場合は、メッセージを表示する処理を実行する（４０７）。規則定義データテーブル１１３内の規則定義レコード２０７ｇは、関連するグループに所属する宛先があるかないかをチェックするケースになる。条件が該当する場合は、重要規則用のメッセージを表示する（４０８）。ループ処理のためのカウントアップを実行する（４０９）。全ての規則のチェックが終わっていない場合、ループ処理を続行する（４１０）。
【００３１】
図５は、メール送受信処理１０６内の新規メール作成処理１０８の処理概要フローを示している。新規メール作成処理１０８では、ユーザの入力によってメールを作成する（５０１）。送信制御のためのステータスを“送信可能”に設定する（５０２）。作成したメールの宛先情報を抽出する（５０３）。抽出した全ての宛先に対して、アドレス帳データテーブル１１２から宛先２０２を検索キーにして所属するグループ名２０１を検索する（５０４）。検索したグループに対して、関連する規則をチェックするための送信用規則のチェック５０６を行う（５０５）。送信用規則のチェック５０６によって設定されるステータスを確認する（５０７）。ステータスが“送信不可”に設定されている場合は、ユーザのメール入力処理に戻る（５０８）。ステータスが“送信不可”でない場合は、メール送受信処理１０９を利用してメール送信を行う（５０９）。
【００３２】
図５における送信用規則のチェック５０６の処理フローは、図６の規則のチェック、図７の禁止・警告規則のチェック、図８の必須・推奨規則のチェックに分かれる。送信用規則のチェック５０６は、まず図６の規則のチェックが実行された後に、図７の禁止・警告規則のチェック、または、図８の必須・推奨規則のチェックに分岐する。
【００３３】
図６のフローについて説明する。送信用規則のチェック５０６は、規則をチェックするために、処理するグループに該当する規則を規則定義データテーブル１１３から検索する（６１１）。該当する規則を検索する際は、規則定義データテーブル１１３のチェック対象２０４を検索キーにして該当する規則レコードを検索する。検索した規則定義に対してチェックを実行するためのループ処理としてカウンタを初期化する（６０１）。検索した規則定義の規則定義データテーブル１１３内の設定項目である規則２０６の設定値をチェックする（６０２）。規則“重要”は、受信メール用の規則であるため、規則が“重要”の場合は、次の規則のチェックに進む（６０３）。規則“重要”以外の場合は、検索した規則定義の規則定義データテーブル１１３内の設定項目である関連グループ２０５の設定値をチェックする（６０４）。関連グループの設定値が“−”の場合は、関連グループに所属する宛先があるかをチェックせず、禁止・警告規則のチェックの処理に続く（６０５）。禁止・警告規則のチェックの処理詳細については、図７で説明する。規則定義データテーブル１１３内の規則定義レコード２０７ｅは、関連グループに所属する宛先があるかをチェックしないケースになる。関連グループの設定値が“−”以外の場合、関連グループに設定されているグループに所属する宛先が含まれているかをチェックする（６０６）。関連グループに設定されているグループに所属する宛先が含まれている場合は、禁止・警告規則のチェックの処理に続き、関連グループに設定されているグループに所属する宛先が含まれている場合は、必須・推奨規則のチェックに続く（６０７）。必須・推奨規則のチェックの処理詳細については、図８で説明する。規則が“重要”の場合は、ループ処理のためのカウントアップを実行する（６０８）。全ての規則のチェックが終わっていない場合、ループ処理を続行する（６０９）。禁止・警告規則のチェックおよび、必須・推奨規則のチェックの結果、ユーザのメール作成を再度実行してもらう必要がある場合は、送信制御のためのステータスに“送信不可”を設定し、送信用規則チェック処理を抜ける（６１０）。
【００３４】
図７は、禁止・警告規則のチェックの処理フローを示している。図６のフローにおいて、規則に該当するグループまたは、グループのペアーが見つかった場合に、図７の禁止・警告規則のチェックの処理フローが処理される。
【００３５】
図７の禁止・警告規則のチェックの処理フローについて説明する。まず、該当する規則定義の規則定義データテーブル１１３内の設定項目である規則２０６の設定値をチェックする（７０１）。規則に“禁止”が設定されている場合は、禁止用のメッセージ表示処理に分岐する（７０２）。“禁止”規則に該当する場合は、宛先に指定できないグループが設定されていることを意味する禁止用のメッセージを表示し、図６のステータス設定処理６１０を行い、再度ユーザに新規メール作成を実行してもらう（７０３）。規則定義データテーブル１１３内の規則定義レコード２０７ｆは“禁止”規則に該当するケースになる。規則に“警告”が設定されている場合は、警告メッセージ表示処理に分岐し、規則に“警告”以外が設定されている場合は、次の規則のチェック処理に続く（７０４）。“警告”規則に該当する場合は、宛先に好ましくないグループが設定されていることを意味する警告用のメッセージを表示する（７０５）。メッセージ表示後、警告条件に合致するがメール送信を許すかどうかをユーザ入力によって指定しもらう（７０６）。ユーザの入力結果を確認する（７０７）。ユーザの入力結果が“ＯＫ”の場合は、次の規則のチェックに続き、“ＯＫ”でない場合は、図６のステータス設定処理６１０を行い、再度ユーザに新規メール作成を実行してもらう（７０８）。規則定義データテーブル１１３内の規則定義レコード２０７ｄおよび２０７ｅは“警告”規則に該当するケースになる。
【００３６】
図８は、必須・推奨規則のチェックの処理フローを示している。図６のフローにおいて、規則に該当するグループが見つかり、かつ関連グループに所属する宛先の指定がない場合に、図８の必須・推奨規則のチェックの処理フローが処理される。
【００３７】
図８の必須・推奨規則のチェックの処理フローについて説明する。まず、該当する規則定義の規則定義データテーブル１１３内の設定項目である規則２０６の設定値をチェックする（８０１）。規則に“必須”が設定されている場合は、必須用のメッセージ表示処理に分岐する（８０２）。“必須”規則に該当する場合は、一緒に指定する必要があるグループの指定がないことを意味する必須用のメッセージを表示し、図６のステータス設定処理６１０を行い、再度ユーザに新規メール作成を実行してもらう（８０３）。規則定義データテーブル１１３内の規則定義レコード２０７ａは“必須”規則に該当するケースになる。規則に“推奨”が設定されている場合は、推奨メッセージ表示処理に分岐し、規則に“推奨”以外が設定されている場合は、次の規則のチェック処理に続く（８０４）。“推奨”規則に該当する場合は、一緒に指定することが好ましいグループが設定されていないことを意味する推奨用のメッセージを表示する（８０５）。メッセージ表示後、推奨条件に合致するがメール送信を許すかどうかをユーザ入力によって指定しもらう（８０６）。ユーザの入力結果を確認する（８０７）。ユーザの入力結果が“ＯＫ”の場合は、次の規則のチェックに続き、“ＯＫ”でない場合は、図６のステータス設定処理６１０を行い、再度ユーザに新規メール作成を実行してもらう（８０８）。規則定義データテーブル１１３内の規則定義レコード２０７ｂは“推奨”規則に該当するケースになる。
【図面の簡単な説明】
【００３８】
【図１】本発明の実施方法の全体構成を示した説明図である。
【図２】アドレス帳データおよび規則定義データのテーブル構成を示した説明図である。
【図３】受信メールにおける規則のチェックの概要を示すフローチャートである。
【図４】受信用規則チェックの流れを示すフローチャートである。
【図５】新規メール作成における規則チェックの流れを示すフローチャートである。
【図６】送信用規則のチェックの流れを示すフローチャートである。
【図７】禁止・警告規則のチェックの流れを示すフローチャートである。
【図８】必須・推奨規則のチェックの流れを示すフローチャートである。
【符号の説明】
【００３９】
１０１…クライアント、１０２…アドレス帳管理処理、１０３…定義情報編集処理、１０４…定義情報表示処理、１０５…アドレス帳情報制御処理、１０６…メール送受信処理、１０７…受信メール表示処理、１０８…新規メール作成処理、１０９…メール送受信制御処理、１１０…CPU、１１１…HDD、１１２…アドレス帳データ、１１３…規則定義データ、１１４…入出力装置、１１５…通信制御部、１１６…メールサーバ、１１７…内部パス、１１８…ネットワーク、１１９…メモリ。
【図１】
2006309365.tif 000003
【図２】
2006309365.tif 000004
【図３】
2006309365.tif 000005
【図４】
2006309365.tif 000006
【図５】
2006309365.tif 000007
【図６】
2006309365.tif 000008
【図７】
2006309365.tif 000009
【図８】
2006309365.tif 000010